Re: [art] not an erratum in RFC 6376, was Argh!!!! onto https://www.rfc-editor.org/errata.php

[Steffen Nurpmeso <[e-mail]>]

Hello.

(I take you off the address list since i now always seem to get

  <[e-mail]>: host mx1.taugh.com[64.57.183.56] said:
    554 5.6.0 Bare CR or LF not accepted. (in reply to end of DATA command)

even though i use postfix 3.9, .. and already before had those new
configuration settings.)

John Levine wrote in
 <[e-mail]>:
 |It appears that Steffen Nurpmeso  <[e-mail]> said:
 |>|No, it's correct as is.
 |>|
 |>|The first bullet on page 16 says to unfold all the lines, so the CR/LF
 |>|are gone before it does anything with WSP.
 |>
 |>But *that* unfolding refers to exactly CRLF alone, because only
 |>this combination is allowed by RFC 5322.
 |>I .. now you make me a bit unsure, but i really think i did test
 |>both, removing lone CR and LF, as well as treating them literally.
 |
 |Since unpaired CR and LF are not valid in a 5322 message, if you see a
 |message that contains one of them, you can do whatever you want. My
 |preference would be to have the signature fail since there is no
 |reason to expect that the other end will do the same thing you do.
 |
 |We quite deliberately did not speculate about what one might do with
 |a block of text that is sort of like a 5322 message but isn't one.

But .. that is what happens in real life software?  Maybe one
should even add a paragraph stating that, and mention the Sendmail
milter protocol, which possibly is the culprit of what happens.
(Though _why_ that is, since the other possibilities would have
worked out just equally well?  Ie, literal bytes or simple
stripping.  I cannot tell, i was not around anything email around
2006-2011 when that seems to have been developed.)

I did ask on -dkim@ and implemented as written and said, but DKIM
verification fails for such multiline headers from milter
communication if RFC 6376 is followed exactly.  (Thankfully DKIM
has a certificate test mode built-in, otherwise some reputation
downgrade (if at all possible in my case) would surely have kicked
in!  It is a great standard!)

I mean, i am not the best person to add an errata.  It is not
a real errata in that sense, but a change to the standard, as
i said on -dkim.  But it is reality, and the OpenDKIM code i have
(now had) was from 2015.  Sure, any new implementor will sooner or
later stumble over failed verifications, and then figure out what
is going on.  But intentionally keeping the standard "as-is" seems
broken behaviour, imho.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)