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

John C Klensin <> Sat, 06 June 2020 18:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 497873A095F; Sat, 6 Jun 2020 11:16:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PgjIY2i1qTvj; Sat, 6 Jun 2020 11:16:03 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F3A8E3A095D; Sat, 6 Jun 2020 11:15:58 -0700 (PDT)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1jhdMI-000Lo0-T4; Sat, 06 Jun 2020 14:15:54 -0400
Date: Sat, 06 Jun 2020 14:15:49 -0400
From: John C Klensin <>
To:, Leo Gaspard <>
Message-ID: <CECAD420DF51202689DE4E81@PSB>
In-Reply-To: <>
References: <> <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
Subject: Re: [ietf-smtp] Stray <LF> in the middle of messages
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 06 Jun 2020 18:16:06 -0000

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.


--On Saturday, June 6, 2020 10:22 -0700 Dave Crocker
<> 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
> 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/