The simple answer is "your MTA is wrong, but...".
RFC 2822 says only CRLF.CRLF should be accepted as the end of the
message. But some servers in the past would incorrectly use CR.CR or
LF.LF. So you can either refuse to accept their mail or do a workaround.
One of the servers I worked on in the past made the compromise by only
looking for such non-standard termination sequences after the read times
out. In other words, "we're just about to throw the message away because
we timed out without getting the CRLF.CRLF, so let's see if the other
side is screwed up and sending us the wrong termination sequence."
Tony Hansen
tony(_at_)att(_dot_)com
Paul Smith wrote:
I've recently had a problem with our MTA where a message line was received as
some text<CR><CR><CR>.<CR><CR>
some more text
(where the <CR>s are ASCII 0x0d, not '<CR>')
Our MTA interpreted the <CR>.<CR> as a message terminator, as it assumed
that the sending MTA was incorrectly using <CR> line terminators instead of
<CR><LF>. (We've seen some cases where they do that)
Comments please?
Is it our MTA which is incorrect by interpreting <CR>.<CR> as the same as
<CR><LF>.<CR><LF>
or is it the sending MTA/MUA which is incorrect by creating a message with
<CR>s in it and then not padding the '.'. (Surely if it really wants <CR>
characters rather than <CR><LF> line terminators, it should use
Quoted-Printable or Base64 encoding, not just put them in there as ASCII
0x0d characters)
Paul Smith