Re: [Exim] CRLF input through pipe causes mangled headers

トップ ページ
このメッセージを削除
このメッセージに返信
著者: Barry Pederson
日付:  
To: exim-users
題目: Re: [Exim] CRLF input through pipe causes mangled headers
Sheldon Hearn wrote:
> On (2003/07/22 10:31), Barry Pederson wrote:
>
>
>>I think this section from RFC 2822 pretty clearly states that Exim's current
>>behavior of potentially transmitting CRCRLF or just CR is pretty much
>>(excepting for service extensions) wrong.
>
>
> Exim doesn't transmit "just CR", does it?


I haven't tried it, but from what I looked at while coming up with my patch,
it looked like it could happen if that's what was in the message body. So
that was a bit hypothetical.



> That means "This is a line.<CRCRLF>" should be interpreted (in transit)
> as a line with value "This is a line.<CR>".
>
> If that's the value of the line in the email message itself, then Exim
> is doing the right thing.


No no no, in this case with Cyrus, the bare <CR>s (not paired with an LF) are
not in the lines of the email message itself, *EXIM* puts them there, that
can't be the right thing. Exim takes: "This is a line.<CRLF>", and
transmits it as: "This is a line.<CRCRLF>". The standard is very clear here,
that sequence <CRCRLF> MUST NOT be transmitted:

>> 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.
>
>
> This is where the standard gets stupid. For a start, this
> recommendation blows up the holy grail of 8-bit transmission. :-)


I thought the general idea of 8-bit transmission had to do with not stripping
off the most significant bit - so that things like accented Latin-1
characters, which are printable text, pass through unchanged. I don't think
it necessarily means exact line-terminator preservation or binary-data
transmission, that's what base64 and so on are for.

I'm not going to argue whether the standard is stupid or not, but it *is* the
standard, and if you start ignoring the parts you don't like, that's where
the weird incompatibilities start popping up.

    Barry