[Top] [All Lists]

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

2020-06-06 16:52:40

--On Saturday, June 6, 2020 16:06 -0400 Valdis Klētnieks
<valdis(_dot_)kletnieks(_at_)vt(_dot_)edu> 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

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.


ietf-smtp mailing list