Re: [art] Argh!!!! onto https://www.rfc-editor.org/errata.php

[Steffen Nurpmeso <[e-mail]>]

Murray S. Kucherawy wrote in
 <[e-mail]>:
 |On Wed, Mar 20, 2024 at 10:30 AM Steffen Nurpmeso <[e-mail]>
 |wrote:
 |> WSP has to be replaced with "WSP, CR and LF", unless something
 |> more lengthy is desired.
 |
 |I concur with John, that CR and LF are gone in something that has already
 |been "unfolded", so this change wouldn't mean anything.

I do not, sorry.  In the meantime i made the great and posted an
errata.  It says

  Due to de-facto implementation practice, the term WSP of the
  following two items, as well as in the part that refers to after
  the separating colon (the field body) in the third, has to be
  interpreted differently, and must include all US-ASCII
  whitespace characters, namely %d9 (HT), %d10 (LF), %d11 (VT),
  %d12 (FF), %d12 (CR) as well as %d32 (SP) [?](the isspace(3) set
  of characters in the ISO C "C" locale)[/?]
  [rest unchanged]

and

  As written.  The behaviour *could* originate in a partial
  misunderstanding of the Sendmail milter protocol, which is often
  used to implement DKIM; this protocol *may* send header
  continuation lines separated by lone LF bytes, instead of CRLF.
  (Thanks to Claus Assmann of esmtp.org for this
  in-between-the-lines reading.)

 |Yes, there are some things in OpenDKIM that have to do with the way values
 |are passed in via the milter API, but the intent was to keep those inside
 |the filter code, separate from the library.  The library is supposed to be
 |generic.

I do not know about OpenDKIM, even though i had the tarball laying
around since some years.  (I have read the manual page, for
example.) I only grep(1)ped for canonicalization.

But regardless, the thing is that Google, Microsoft, "amavisd",
rspamd, they all require exactly this behaviour to make the
signature verify!  What do you mean by "generic"?

 |Btw, why does RFC 8601 refer to RFC 2045 *only* for the backing of
 |> authserv-id, as the field is not MIME encoded itself, is it (?),
 |> why is RFC 2045 "value" and "tspecials" any better than "specials"
 |> from RFC 5322 and obs-NO-WS-CTL (or what it actually is; atext?
 |> I just started with that) from the same document?
 |>
 |
 |It basically borrows ABNF tokens from RFC 2045 because we wanted to use the
 |same mechanisms for expressing and encoding values.  The field itself
 |doesn't need to be MIME encoded (whatever that means) to accomplish its
 |goals.

I meant content-transfer-encoded with this.
Ok, thank you.  Well, i extend my newly written, delicate RFC 5322
parser to parse structured headers as quoted-string OR phrase (or,
optionally, dot-atom-text instead of phrase).  This i will use for
my DKIM signer to parse A-R headers.  Doesn't mean a thing if
Microsoft generates A-R without any authserv-id, as posted on
-dkim, anyhow.

Thank you!

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