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
