Double Carriage return breaks header ..

[Patrik Henningsson]

Greg A. Woods wrote:
> [ On Monday, May 30, 2005 at 22:32:37 (+0200), John Fawcett wrote: ]
> 
>>Subject: Re: Double Carriage return breaks header ..
>>
>>Greg A. Woods wrote:
>>
>>>Really your MTA should be correcting it long before it gets passed on.
>>
>>is there a basis for this?
> 
> 
> Well, maybe.  :-)
> 
> 
> 
>>>As has been noted, it's not valid SMTP content.
>>
>>is it correct for cyrus to interpret bare \r as an end of header line
>>rather than just reject the message?
> 
> 
> Well actually on deeper reading of RFC 2821 I think a bare <CR> should
> just be treated as a bare <CR> -- i.e. another ordinary character in the
> message content that should be preserved transparently.
> 
> This is indeed how Smail deals with bare <CR>, regardless of whether it
> appears prior to a <CRLF> pair or not.
> 
> However with both Cyrus v2.1.15 and v2.2.12 I find that in my
> configurations with Smail the bare <CR> before a <CRLF> is stripped by
> Cyrus (but preserved by Smail).
> 
> Here's the tail of the test message as delivered by mail.local to
> /var/mail/gwoods (note the <CRLF> pairs have, of course, been reduced to
> <LF> in order to conform to the Unix mailbox syntax, but the extra <CR>
> at the end of the "Subject:" header, and at the end of the line "crline"
> both remain):
> 
> # od -c /var/mail/gwoods | tail 
> 0002100    t   e   :       M   o   n   ,       3   0       M   a   y    
> 0002120    2   0   0   5       1   7   :   3   9   :   1   5       -   0
> 0002140    4   0   0       (   E   D   T   )  \n   F   r   o   m   :    
> 0002160    <   w   o   o   d   s   @   w   e   i   r   d   .   c   o   m
> 0002200    >  \n   T   o   :       g   w   o   o   d   s   @   m   a   i
> 0002220    l   .   a   c   i   .   o   n   .   c   a  \n   S   u   b   j
> 0002240    e   c   t   :       T   E   S   T  \r  \n   X   -   h   e   a
> 0002260    d   e   r   :       b   a   r  \n  \n   c   r   l   i   n   e
> 0002300   \r  \n   f   o   o  \n  \n  \n                                
> 0002310
> 
> 
> And here's the tail of the exact same test message as delivered through
> "deliver" to Cyrus:
> 
> # od -c 118. | tail             
> 0001140    M   a   y       2   0   0   5       1   7   :   3   9   :   3
> 0001160    3       -   0   4   0   0       (   E   D   T   )  \r  \n   F
> 0001200    r   o   m   :       <   w   o   o   d   s   @   w   e   i   r
> 0001220    d   .   c   o   m   >  \r  \n   T   o   :       g   w   o   o
> 0001240    d   s   @   m   a   i   l   .   a   c   i   .   o   n   .   c
> 0001260    a  \r  \n   S   u   b   j   e   c   t   :       T   E   S   T
> 0001300   \r  \n   X   -   h   e   a   d   e   r   :       b   a   r  \r
> 0001320   \n  \r  \n   c   r   l   i   n   e  \r  \n   f   o   o  \r  \n
> 0001340   \r  \n  \r  \n                                                
> 0001344
> 
> 
> Note though that in my current configuration Smail feeds the exact same
> data to both "deliver" and "mail.local".  I.e. the <CRLF> pairs have
> been reduced to just <LF> before "deliver" sees them.
> 
> So, in these cases I can only assume that I cannot reproduce the problem
> because I'm not using LMTP directly and so I've revealed what may be yet
> another bug -- deliver isn't properly turning _every_ <LF> back into a
> <CRLF>, but instead is still leaving what it sees as existing <CRLF>
> pairs alone.
> 
> I'll have to do some more extensive experiments -- I should be able to
> configure Smail to preserve the original <CRLF> pairs (and bare <CR>s)
> when feeding the message to "deliver".....  (I need to re-install
> current versions on my test machine before I bugger up a production
> machine though! :-)
> 
> 
> In any case I think I'll revert to blaming Cyrus for the observed
> behaviour that was originally reported.  It should not be stuffing an
> extra newline in front of a bare <CR> -- rather it should simply be
> passing it through transparently as a bare <CR>.  I.e. contrary to
> whomever said <CR><CRLF> wasn't valid SMTP, well it is, perfectly
> valid as per RFC 2821.
> 

Great to see some commitment.
So now we know that Cyrus presumably is doing wrong, any brave soul 
contribute with a patch?

/PH
---
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html