Hi,
Recently on the qmail mailing list there was a discussion about
problem some Outlook/Outlook Express users were having with messages
being stuck in the maildir when trying to receive them using POP3.
The problem was tracked down to messages that have lines terminated
with CR CR LF rather than the standard CR LF pair in the SMTP
conversation.  It was noted that ending a line with anything other
than CR LF is forbidden by the standard.  To wit in RFC2821:

2.3.7 Lines

   SMTP commands and, unless altered by a service extension, message
   data, are transmitted in "lines".  Lines consist of zero or more data
   characters terminated by the sequence ASCII character "CR" (hex value
   0D) followed immediately by ASCII character "LF" (hex value 0A).  This
   termination sequence is denoted as <CRLF> in this document.
   Conforming implementations MUST NOT recognize or generate any other
   character or character sequence as a line terminator.  Limits MAY be
   imposed on line lengths by servers (see section 4.5.3).

   In addition, the appearance of "bare" "CR" or "LF" characters in
   text (i.e., either without the other) has a long history of causing
   problems in mail implementations and applications that use the mail
   system as a tool.  SMTP client implementations MUST NOT transmit these
   characters except when they are intended as line terminators and then
   MUST, as indicated above, transmit them only as a <CRLF> sequence.

Now, qpsmtpd already rejects messages with bare LF, so I'm wondering
if this should be extended to rejecting any messages that do not
terminate their lines with the correct CR LF pair.  In other words,
are bare LF _and_ CR both grounds for rejection?  The RFC would seem
to imply this with the "conforming implementations MUST NOT
recognize..." statement, but I'm not really sure.  Would there be
catastrophic problems if messages containing lines ending with CR CR
LF are rejected at the SMTP level?

Comments?
        -- Robert

-- 
    Robert James Kaes    ---  Flarenet Inc.  ---    (519) 426-3782
                 http://www.flarenet.com/consulting/
      * Putting the Service Back in Internet Service Provider *

Attachment: pgp00000.pgp
Description: PGP signature

Reply via email to