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

John C Klensin <> Sat, 06 June 2020 21:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 212663A0DCA; Sat, 6 Jun 2020 14:52:27 -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 b7TK4QaCsy8N; Sat, 6 Jun 2020 14:52:25 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D600E3A0DC9; Sat, 6 Jun 2020 14:52:25 -0700 (PDT)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1jhgjl-000Mu1-EF; Sat, 06 Jun 2020 17:52:21 -0400
Date: Sat, 06 Jun 2020 17:52:15 -0400
From: John C Klensin <>
To: =?UTF-8?Q?Valdis_Kl=C4=93tnieks?= <>
cc:, Leo Gaspard <>,
Message-ID: <9039D9D02E9653D0708BA52F@PSB>
In-Reply-To: <444397.1591473993@turing-police>
References: <> <> <CECAD420DF51202689DE4E81@PSB> <444397.1591473993@turing-police>
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 21:52:27 -0000

--On Saturday, June 6, 2020 16:06 -0400 Valdis Klētnieks
<> wrote:

> On Sat, 06 Jun 2020 14:15:49 -0400, John C Klensin said:
>> 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.
> I'm unaware of anything that does digital signatures that
> doesn't already mandate the use of a canonical encoding that
> would prevent a bare LF from escaping.  I suppose that
> somewhere, somebody wrote a signature routine that was
> expecting canonical input and failed to check for same and
> flag an error
> On the other hand, the case can be made that causing the
> signature to invalidate isn't an error - and possibly even
> rises to a 2119 SHOULD fail.

I think this gets into the range of kicking of dead horses, but
the point is that sending bare LFs (or bare CRs) is looking for
trouble, whether it is misinterpretation of intended


sequences, messing up of signatures, or being confused with a
spammer (and/or complete idiot who hasn't managed to fix those
problems in nearly 40 years).   If a submission server has
private agreements with its clients about those things and how
to fix them, so be it as long as they get fixed.  But, for an
SMTP sender (or submission server) to send that stuff out not
only violates the spec if they intended to have LF interpreted
as CRLF but counts on whatever happens downstream to apply the
same interpretation... and they probably won't.