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?

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

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.

*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.

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.

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.

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.

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.

@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.

@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.