Please allow me an addendum. John Levine wrote in <20240201180340.852b68205...@ary.qy>: |It appears that Murray S. Kucherawy <superu...@gmail.com> said: |>-=-=-=-=-=- |>On Wed, Jan 31, 2024 at 5:44 PM Steffen Nurpmeso <stef...@sdaoden.eu> \ |>wrote: |> |>> But i cannot read this from RFC 6376. |> |>Sections 2.8 and 3.4.4 don't answer this? | |Not really. They say what to do with CRLF but not with a lone CR or \ |lone LF. | |RFC5322 says: | | o CR and LF MUST only occur together as CRLF; they MUST NOT appear | independently in the body. | |So I think the answer is that a thing with a lone CR or LF is not a |valid message so signers shouldn't sign them and validators shouldn't |validate them. If you want to allow them, OK, but no promises that |anyone at the other end will treat the brokenness the same way you |dod. | |We can get into some theological arguments about BINARYMIME which |allows arbitrary bytes in a MIME part but I expect that DKIM |canonicalization code will choke on other stuff in binary MIME before |it gets to a \x0a or \x0d.
So i implemented DKIM as of 6376, and my emails were dkim=pass. *Except* when there were headers with continuation lines. It turned out that my (quarter-of-a-century++ old, and very widely used MTA!) uses "\n" for line endings of header continuations (just like the MUA i maintain does for everything). This "literal LF" caused Google and other software to fail the DKIM test. The same picture if i stripped it. So this evening i changed the code to treat any CR or LF that does not appear as part of a CRLF tuple as real whitespace (ie, in "relaxed" normalization terms), and now Google and other software say dkim=pass for multiline headers signed by my software. That is why i like email. All involved parties do it falsely, and in the end it just works like a clockword! Very nice. Here is what the worldwide acknowledged, very honourable developer of the MTA i use said to this: [..] systems have been signing with Milters since [..] Milter support was added in 2006. I'm just surprised that the non-canoncal line endings in a multiline header have not been a problem before. This is where over-engineering, let me just beat onto this, and autism work firmly together, i would say. I would think that the DKIM standard needs to be changed to honour WSP + CR + LF as whitespace, because this is what happens in practice. Of course. It could be i am wrong. --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) _______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
