Steven Chamberlain wrote:
> Hi,
>
> I originally thought this was a bug in libdomainkeys but I now believe
> Exim's DK validator may be at fault. The text below is mostly copied
> from my libdomainkeys bug report.
>
> The attached file is a transcript of a SMTPS (TLS) session, initiated
> using 'openssl s_client -connect smtp.pyro.eu.org:smtps'. Without the
> '-crlf' option, the message is received by Exim with LF (\n) instead of
> CRLF (\r\n) line endings, triggering the bug. I've not yet been able to
> reproduce this via standard (plain-text) SMTP.
>
Is this really a bug considering RFC2821 says:
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.
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).
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.
