http://coldfusion.com logo
#cfml-general
Title
# cfml-general
d

Dave Merrill

02/04/2022, 2:11 PM
Is there any documentation or community knowledge about what constructs aren't allowed in text format cfmail content, and how to escape the disallowed stuff? We've had pentesters banging on us for 3 days, requests with all kinds of hacky nonsense in the URL, and some of the emails we send for errors in production got stuck in Undelivr. We have code that automatically retries by moving them to Spool, which it did, but the send fails and get moved back to Undelivr again. Other emails go out fine. I could just delete them, since I've read their content and it's not news, but I'm wondering how to improve the process, by detecting "invalid" emails and ideally, fixing them. Thoughts? Other than that I should stop worrying about this, it's rare and dealable with by hand?
t

thisOldDave

02/04/2022, 2:25 PM
have you checked the logs to see what is actually causing the failures you will have a much better shot at prevention if you know the cause
d

Dave Merrill

02/04/2022, 3:21 PM
Only thing in the logs is some of these: javax.mail.MessagingException: Exception reading response; nested exception is: java.net.SocketException: Connection reset My guess is that the mail server cf is connecting to rejected some emails because they had hacky crap in them from the pentest URLs. So it's possible that it's not CF having the problem, it's the outside mail server. That said, my question about what if anything isn't allowed in cfmail content still stands.
a

Adam Cameron

02/04/2022, 3:53 PM
*cf*mail content, or just "in a mail message body"? Sounds to me more like the latter. In which case... there will be an RFC about what you need to escape etc. If it's the upstream mail server rejecting it,
<cfmail>
is not really relevant. It's just the mechanism to create a mail message and send it to the specified server, and the translate the response from the server back into something CFML can understand (response or exception) I'd perhaps try to send one of the undelivered emails by hand to the mail server in question, and see what its actual response is, before all of CF's abstraction layer gets hold of it.
There's also a chance the upstream mail server might be configured to reject emails based on rules that examine the content (I mean... I guess this is a thing). In which case... "the email being rejected for transmission" is probably a passing pen test.
t

thisOldDave

02/04/2022, 4:01 PM
as Adam says it is much more likely to be the relay agent rejecting the mail, the socket reset is a bye product, the relay agent logs are going to be your friends. Again as Adam says send the mail manually and and see if your client provides a more detailed message.
1
d

Dave Merrill

02/04/2022, 4:30 PM
I bet you folks are right, the problem isn't cfmail, it's the relay agent. Methinks this isn't worth banging on further. Our retry stuff will tell us when there's stuck mail, doesn't happen often, we'll just go look at them, move them out of Undelivr, and do whatever we need to do about getting the msgs to their recipients. It's rare outside of this situation. The immediate pentest emails thing isn't really something I need to deal with. We'll get their full report, and figure out what we need to do about handling these bent requests better, if we need to. They didn't harm the server (they were told not to), we'll see what they were able to do and find out. Thanks folks.
1
b

bhartsfield

02/04/2022, 4:49 PM
I'm not sure what your retry process looks like but if you really want the email sent, after a couple failures, zip the file and email that.
m

Matt Jones

02/04/2022, 4:53 PM
my 2 cents, If the pentest is able to modify content being sent in an email, it would likely by your responsibility to clean up that content. I regularly leverage jsoup's parseBodyFragment() then use .body().text() on items to extract the text. I also re-run when the result of the first call includes any <, because there are scenarios when turning to text becomes code. I would also ensure that the characters you allow are within the charset you have specified.
d

Dave Merrill

02/04/2022, 5:29 PM
@bhartsfield yes thought of that, but so far anyway, I don't think I need to go there. @Matt Jones valid points. The emails are the message and detail of errors thrown by cf, in this case caused by hacky URLs run by the pentesters. At first glance, it doesn't look like they're potentially harmful, but we'll be investigating further.
m

Matt Jones

02/04/2022, 6:25 PM
@Dave Merrill ahh, that makes sense. I'm unsure of a good (or even valid) encoding mechanism specifically for plaintext emails. I'd just ensure the characters are within the specified charset, and that the lines are no more than 997 chars.
3 Views