Hello 3APA3A!
The Bat! v1.42 Beta/10 released Sat, 21 Apr 2001 fixes CR handling
that you've described. It is now strict to line endings. Only
<CR><LF>.<CR><LF> is now treated as end of message.
Mon, 23 Apr 2001 12:46:23 +0400, you wrote:
mfb>> This is not a bug of The Bat! but a bug of MTA (POP3/SMTP servers)
mfb>> that allow such odd messages. The proposed "bad-message"
mfb>> (http://www.security.nnov.ru/files/badmess.zip) is not
mfb>> RFC-compliant. Any RFC-compliant POP3/SMTP server must either bounce
mfb>> or cure it. I've used a proposed example to send the message to
mfb>> myself, on a FreeBSD server with Sendmail 8.11.1 I've typed
mfb>> cat badmess | sendmail -U [EMAIL PROTECTED]
3> You're wrong. This message _is_ RFC 822 and RFC 1251 compliant. In
3> fact, RFC 822 absolutely clear allows <CR> and <LF> even in some
3> message headers:
3> text = <any CHAR, including bare ; => atoms, specials,
3> CR & bare LF, but NOT ; comments and
3> including CRLF> ; quoted-strings are
3> ; NOT recognized.
3> _any_ pop3 server shouldn't change this message, because RFC 1939
3> follows RFC 822 for message standard.
3> RFC 821 (SMTP) simply says "The mail data may contain any of the 128
3> ASCII character codes".
3> RFC 1251 allow message to contains any binary data and strings of any
3> length. In fact, sendmail allows any characters (including NULL) to be
3> in message body. "badmess" was tested with sendmail 8.9.3 + mail.local
3> + UW-pop3d 7.59.
3> P.S. I didn't tested The Bat! with NULL characters in message body...
3> If something like
3> <CR><LF>NULL.<CR><LF>-ERR
3> in message body hurts The Bat! badly RitLabs better patch it right now
3> :)
--
Maxim Masiutin
Vice President, Ritlabs S.R.L.
http://www.ritlabs.com/
