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>
According to RFC 2822, the answer is yes, your MTA should not be doing this. It
was probably done to interoperate with some broken client in the past. But most
MTAs that do this have controls to adjust the interpretation of bare CRs and
LFs. I suggest you check the documentation for your MTA and see if its
behavior can be adjusted.
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)
This is also quite true. If you want to use bare CRs you need to encode the
material containing them. Depending on how unencoded text is canonicalized for
local storage you are likely to either lose the CRs completely or have
them converted into CRLFs. So even if the message is successfully received
in its entirety it is likely to be damaged at some point.
Ned