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

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

--On Saturday, June 6, 2020 16:06 -0400 Valdis Klētnieks
<[e-mail]> 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

   foo
      bar

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.

   john