paul(_at_)pscs(_dot_)co(_dot_)uk (Paul Smith) wrote on 22.05.01 in
<5(_dot_)1(_dot_)0(_dot_)14(_dot_)2(_dot_)20010522204602(_dot_)0669c590(_at_)192(_dot_)168(_dot_)57(_dot_)100>:
The MTA is one we wrote ourselves, so we'll add an option to it to either
accept ONLY CRLF as line terminators in messages (the new default) or
accept any combination of LF, CR, CRLF (or even LFCR which we've seen in
one instance from an MUA a couple of years ago..)
We may make this a bit smarter in the future. One thing we've spotted in
this case is that the message header is all formatted correctly, but the
message body has bare CRs in it, so we may say that if the header is
correct then we'll assume the rest of the message should be, but if the
header uses just CRs or just LFs then we'll assume the rest of the message
is the same as well.
One technique I've seen mentioned in a previous thread about this, and
which at least looks as if it should work well, was to look at the SMTP
commands the client sends.
If those are terminated with CRLF, probably so will the rest of the
exchange; similar for naked CR or LF. What's more, in this case you can
argue that you *only* use the different behaviour after seeing clearly
incorrect client behaviour, so a correct client can never run afoul of
that behaviour.
You could even tell the client, so someone developing a new client will
notice early he's doing something wrong. Maybe like this:
220 foo.com MTA here
HELO bad.client.org
250 I see you're using naked CRs, which is a bug; I'll try to compensate (but
see RFC 2821!)
(Keep it on one line: buggy clients may have more than one bug, and
another might be inability to cope with multiline respondes.)
MfG Kai