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?
> ----------------
> 2.3.7 Lines
>
> SMTP commands and, unless altered by a service extension, message
> data, are transmitted in "lines". Lines consist of zero or more data
> characters terminated by the sequence ASCII character "CR" (hex value
> 0D) followed immediately by ASCII character "LF" (hex value 0A).
> This termination sequence is denoted as <CRLF> in this document.
So <CRLF> is the line terminator, and anything preceding it is the line.
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.
> Conforming implementations MUST NOT recognize or generate any other
> character or character sequence as a line terminator. Limits MAY be
> imposed on line lengths by servers (see section 4.5.3).
If you were to change Exim to recognize <CR> as a line terminator and
then replace it with the transport terminator <CRLF>, you'd be in
violation of this mandate.
> 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. :-)
Ciao,
Sheldon.
