[Top] [All Lists]

[ietf-smtp] Stray <LF> in the middle of messages

2020-06-06 12:06:55
Hello world,

I am in the process of writing an SMTP server, which obviously is going
to be the best of all SMTP servers ever written and that will ever be
written in our eon.

However, in the process of taking over the world, I am facing something
that surprises me.

I read, in RFC5321, §2.3.8, this paragraph:

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).

Which appear to clearly indicate that <LF> is not a valid line

However, I notice that every single time I have tried to use `netcat` to
send emails for demo purposes, it succeeded *without* sending <CRLF> and
by sending only <LF>. While `telnet` does appear to convert typed <LF>
into <CRLF>, it looks like (my version of) `netcat` does not. So most of
the SMTP servers I have met with appear to consider <LF> as a valid line

This, in most cases, is not a big deal, because <LF> is not a valid
character in SMTP commands, so saying that receiving an <LF> is
equivalent to receiving a <CRLF> is not that big a problem.

However, there is one case where the semantics is important: should one
escape the <LF>. sequence while in a DATA block?

I would guess that the fact that other SMTP servers appear to usually
accept <LF>.<LF> as a terminator indicates that <LF>. should be escaped
even though it is not strictly conforming with the RFC, but… I wanted to
have the opinion of other people on this, before diving too deep in the

The following paragraph also makes me wonder:

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>

Should I understand this paragraph as meaning that if I ever receive
such an ill-formed message, I… can? should? must? accept it and… can?
should? must? convert the <LF> into proper <CRLF>?

Thank you in advance for any thoughts you may have!

PS: If you really want to, you can find the current code of said SMTP
server here, but it's still quite far from completion and I'm a hopeless
perfectionist, so don't hold your hopes too high even if the design
described in the book appeals to you — even though I'd be happy to hear
your thoughts about it too!

ietf-smtp mailing list