[ 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 <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]> Secrets of the Weird <[EMAIL
PROTECTED]>
---
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
