A user came on IRC today with a weird error. He was receiving an email from hotmail with a jpeg attached, but it was bombing midstream and exim was complaining about SMTP errors in the conversation. He posted a packet dump that I looked at with wireshark.
In packet 4172, exim replied "250 OK id=blah". So I looked before that to see if there was a CR LF . CR LF sequence, but didn't find one. On a whim, I searched for LF . LF and found it: In packet 4100 was the sequence 0a 2e 0a, i.e. just line feeds, no carriage returns. Confused, I looked through the code in read_message_data_smtp() and found these comments: <snip> If any line begins with a dot, that character is skipped. The input should only be successfully terminated by CR LF . CR LF unless it is local (non-network) SMTP, in which case the CRs are optional, but... FUDGE: It seems that sites on the net send out messages with just LF terminators, despite the warnings in the RFCs, and other MTAs handle this. So we make the CRs optional in all cases. </snip> So the sequence 0a 2e 0a does in fact get treated by exim as an end of the DATA phase. Maybe we need an option to say that the CR is not optional? The old drop_cr option is opposite of what seems to be needed (in this particular case). What's maybe needed is the ability to say CR LF . CR LF is required for +hostlist. Someone else has opened a bug in the bug tracker. Shouldn't we bring exim back to a strict interpretation of the RFCs? ...Todd -- SOPA: Any attempt to [use legal means to] reverse technological advances is doomed. --Leo Leporte -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
