Double Carriage return breaks header ..

[Greg A. Woods]

[ 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.

-- 
						Greg A. Woods

H:+1 416 218-0098  W:+1 416 489-5852 x122  VE3TCP  RoboHack <woods at robohack.ca>
Planix, Inc. <woods at planix.com>          Secrets of the Weird <woods at weird.com>
---
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