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

[Valdis Kl ē tnieks <[e-mail]>]

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