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
