we're seeing a lot of corrupted spam messages today, due to Exim's
handling of bare LF in an SMTP dialog. evidently, Exim will accept it
as a proper line ending, which isn't satisfactory behaviour.
the cause of this seems to be misconfigured hosts spewing spam, with a
linefeed in their name. this name is entered in the Received header,
like so:
Received: from [67.39.48.36] by rx359.net<LF>IP with HTTP;
Thu, 18 Dec 2003 00:48:15 +0400
since the rest of the line does not contain a colon, Exim will regard it
as the first line of the body, and the rest of the headers become part
of body as well.
so there are two issues here:
1) what to do with a bare LF.
one alternative is to change it into CRLF SPC, but I think it's better
to flatly reject the message with a reference to RFC 2822 section 2.2.
if you really, really want to support telnet sessions with no LF->CRLF
translation, you can make a note of what style of line ending was used
on the very first command (HELO or whatever).
2) what to do with a "header line" without a colon.
again, I favour rejecting the message. let's "force" people to follow
the standards. the good guys generally do, it's the quick "let's write
a visual basic program to spam millions of people" who get it wrong.
(I'd like to stress that the suggested behavioural change only pertains
to an SMTP dialogue. accepting bare LF as a line ending is fine when
the data comes from a pipe.)
--
Kjetil T.
