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

[John C Klensin <[e-mail]>]

Actually, the comment in his last paragraph notwithstanding and
other histories of disagreement, I completely agree with Dave.
I would add one additional cautionary note: we now have several
security-related tools, in difference degrees of active use,
that digitally sign message bodies, headers, or both.  If
something sees a bare LF and converts it after those signatures
are computed. testing them will typically fail.  That is just
one more reason for observing Dave's (and Postel's) advice: be
really careful that what you send (or allow to be sent) out
conforms to a narrow reading of the standard.  How much
deviation you want to accept in something you receive depends on
your circumstances.

    john


--On Saturday, June 6, 2020 10:22 -0700 Dave Crocker
<[e-mail]> wrote:

> On 6/6/2020 10:06 AM, Leo Gaspard wrote:
>>> 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.
>> 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>?
> 
> 
> 
> Encountering practice that differs from theory -- or, in this
> case, specification -- can be an excellent teachable moment.
> 
> I think your opportunity, here, is to appreciate the
> pragmatics of Postel's Law.  It is often taken to mean that
> one can send whatever one wants, but Jon was never that
> sloppy.  You should try to generate only according to the
> strictest interpretation of the spec.
> 
> But there are realities of different interpretations and some
> tolerable sloppiness that apply to this case, given a long
> history of systems that do use LF as line terminator and
> network software that fails to map it to the network standard
> CRLF.
> 
> I believe systems still vary on how they respond to an
> incoming LF.  I even suspect there are arguments for treating
> it only as data and arguments for treating it as newline.  I
> suspect, therefore, the answer to your question will be how
> you assess the benefits and detriments of each choice.
> 
> This being an IETF list, we should expect strong, differing
> comments from others.
> 
> d/