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

Valdis Kl ē tnieks <> Sat, 06 June 2020 18:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B78573A090A for <>; Sat, 6 Jun 2020 11:30:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1w2U2WBuQWEY for <>; Sat, 6 Jun 2020 11:30:37 -0700 (PDT)
Received: from ( [IPv6:2607:b400:92:8300:0:c6:2117:b0e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2E8F33A0909 for <>; Sat, 6 Jun 2020 11:30:37 -0700 (PDT)
Received: from ( [IPv6:2607:b400:92:8500:0:af:2d00:4488]) by (8.14.4/8.14.4) with ESMTP id 056IUYRY008620 for <>; Sat, 6 Jun 2020 14:30:34 -0400
Received: from ( []) by (8.14.7/8.14.7) with ESMTP id 056IUTAQ024156 for <>; Sat, 6 Jun 2020 14:30:34 -0400
Received: by with SMTP id s15so10426447qvo.6 for <>; Sat, 06 Jun 2020 11:30:34 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:in-reply-to:references :mime-version:content-transfer-encoding:date:message-id; bh=1FLGHlw9wzLpHZ5e/rpa4coSZNoquYvWPGFwKCHMz+w=; b=Aly/2gWPKw2tazCs6Kda7Sak7sKbPTWHL3qhXTDw+bN3MNDI9HiJZWrnv/eOlBWHsW fmXfJHUxrjkNqRpSVlKCymmAQeSxVlm2Rj/chUKeUBrBelzDl26+bNZHzxNH6OEFi4ko 1yHIzM1vEdw9Ln/LSeQp/WbHa7xqKtzJyww5sG5zOEUenndP3N/3upYTIIcJPJBMDljg 77T9DnbElk8Dv/T9m9EZgeB4VnB1OmUK3hBmL7W0g6vQs/pa5bej/YU/D+bnfTOGQuzt wGpaPwQjsMiQHr85m5AX/Vpt+yHJOA+/Y+o66m7yo/1+AY/XUU0eGIUSUngjc0dBJxT+ WMAQ==
X-Gm-Message-State: AOAM531VWsatkiolXD0bSQXJA6cTRi8pBJRERpJfJLSQ0goKiAD+Q+g+ wSTAjI4IOOeIu8S8IDJwYIMzOZrWKbzNK/wRp4ilX6xj2by4qbr/yoOph0WvHnMr00R87v/M+Wu 15qcNVJQRFX7tdDip4clV9Q==
X-Received: by 2002:a37:4f52:: with SMTP id d79mr15503019qkb.330.1591468228393; Sat, 06 Jun 2020 11:30:28 -0700 (PDT)
X-Google-Smtp-Source: ABdhPJxjgd5yB8ghB22zifanZbTbFj7JmGUdqSoAVjlrQXabw9SvitcWn3SQr34WQheUNPh1/UtEbA==
X-Received: by 2002:a37:4f52:: with SMTP id d79mr15502994qkb.330.1591468227963; Sat, 06 Jun 2020 11:30:27 -0700 (PDT)
Received: from turing-police ([2601:5c0:c001:c9e1::359]) by with ESMTPSA id c191sm2980214qke.114.2020. (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 06 Jun 2020 11:30:26 -0700 (PDT)
Sender: Valdis Kletnieks <>
From: "Valdis Kl=?utf-8?Q?=c4=93?=tnieks" <>
X-Google-Original-From: "Valdis Kl=?utf-8?Q?=c4=93?=tnieks" <>
X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev
To: Leo Gaspard <>
In-Reply-To: <>
References: <>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_1591468224_5575P"; micalg=pgp-sha1; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Sat, 06 Jun 2020 14:30:24 -0400
Message-ID: <439598.1591468224@turing-police>
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:30:39 -0000

On Sat, 06 Jun 2020 19:06:29 +0200, Leo Gaspard said:

> 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>?

To add to what Dave Crocker just said:

Unless you have insight into *why* you got a bare <LF> (for example,
you know *for a fact* that the other end of the connection is that ancient
creeping horror over in the Receiving department that has Known Bug XYZ),
there is in general no guaranteed "correct" way to deal with the situation.

Although smashing a bare <LF> into a <CRLF> is probably the most
expedient way to recover, that *does* have the (probably small) risk
of data corruption if the sending end actually *did* mean to have a bare
<LF> in the data.

However, it's 2020, and quoted-printable and friends are approaching
3 decades in age.  I'm fairly sure that for the vast majority of MTAs.
the code that accepts and converts <LF> is equally as old, and has
stayed in the code base just in case somebody is using netcat or similar
tool to talk to the receiving MTA.  I doubt there's anything out there
that claims to be an actual MTA that still generates bare <LF> anymore.

The scary part is, of course, what *ELSE* that creeping horror MTA might
be doing wrong.

The equally scary part is my "probably not anything out there" claim,
because I really *should* know better... :)

Back in the 90s, I had an AIX workstation at work that was advertised as
a open-access NTP server I was running on a volunteer basis. In 1998, our networking
group started a production NTP service for the enterprise, and I removed
the workstation from the official clocks.txt file.  In July 1999, I migrated from
AIX to a Linux box with a different hostname, and the AIX box was powered
down, the name removed from DNS, and the IP address flagged as "do not use"
in our management system (to prevent some poor soul getting the address and
going nuts when their firewall rules exploded).

Every few years, I'd play some ifconfig/iptables/tcpdump games to see
what inbound traffic was still there. As of July 2018, there were *still* well
over 500 separate IP addresses sending NTP traffic to that address, even
though nothing had actually answered packets for almost 2 decades.

And a lot of those hosts were sending NTPv4 packets, which implies they
had at least 1 software upgrade after I shut that service down....