Tobias Herkula wrote in <fryp281mb21560aef635f24cbefb57a19ea...@fryp281mb2156.deup281.prod.OUTLO\ OK.COM>: |I don't think we need additional complexity here of the nd= or now \
Sorry people, but i cannot resist. It is for a good cause. Yes, i read it via web archive occasionally. |pp= fields, as we already have a best practice on how to delegate sending \ |privileges to third parties, that are well understood. In the Bulk \ ... Because noone ever, despite all the, as the word was heard, intelligent people on this list, went "the christian way" when the OpenPGP aka *email*security* people came over with the unobtrusive signatures, and read between the lines. As far as i could read in between the lines of the posts of the thread. It was only about the normalization algorithm, .. funnily? So, sorry, but please just let me place this picture thus. So: what about the header protection of what then became RFC 9788 (one more reason to believe simply adding acdc= as a tag to the DKIM-Signature is doable). If we had an ideal world we not only would have DNS(SEC)- detectable TLS for SMTP, S/MIME and OpenPGP, and (therefore, more and more) header obscured. Or removed. Please see RFC 9788, shall you not have read it yet, and incrementally search "obscur". For example, "3.4.1. Offering More Ambitious Header Confidentiality": [.]implement an HCP that removes the To and Cc Header Fields entirely, relying on the SMTP envelope to ensure proper routing[.] Now the *email*security* people have fought for many years (i locally have draft-melnikov-smime-header-signing-02.txt downloaded on April 4th, 2015, for example), finally there is RFC 9788, which is a great thing (thank you!!!), and i long to get enough time for implementing that in the MUA i maintain in some distant, but sought for future. And then noticable members of this DKIM WG come over, and turn the SMTP envelope in a public field for long time storage, with deep track chains over (as) many hops (as will be, and which do not mitigate). I do not get it. IMHO this is not the holistic email strategy that we need, that is little by little, everyone for his (not her) own satisfaction. Hey, Can't by me love, wasn't this the Rolling Stones. I consider listening to the Tiger Lillies, Piss on your grave, for more "stabbing in the back" occasions. My pathetic english aside, my pathetic DKIM-WG abstinence aside, but there are so many aspects which were not covered by the group of leaders here. Given that Dave Crocker said "all intelligent people on this list", i therefore assume that, instead, all you know about RFC 9788, and that the entire month long "single recipient is ok" thread already included all the rat tail of logical consequences that the other draft implies for the SMTP infrastructure (i just did not realize it from what was written). The conclusion: the other approach always requires single recipient delivery -- despite that it now can multi-recipient because it was seen "how Microsoft does it" --, because on the SMTP level aka DKIM software noone has a notion of whether a message is RFC 9788 treated or not (if detectable at all), because the envisioned DKIM2 turns public circumstances that RFC 9788 carefully tries to hide. What a mess. And that all over speculatively tried, or HTTP detected, SMTP/STARTTLS (no Implicit TLS -- oh no, tears are falling, Beth (RIP, Mr. Frehey)). So, excuse me please, but in hindsight to hundreds of thousands of flight miles, and get-togethers at famous (and expensive) locations, and all-in-all centuries of specialist experiences. That just sucks. I am thankful Mr. Herkula spoke against this one idea. I said similar in lesser spread aka competent words before. Yes: to come to ACDC, it creates point-to-point DKIM-AC access control headers, and despite in-the-middle hops, shall they exist at all (and then: likely detectably so), noone will ever see them. Noone will see the envelope data as part of the RFC 5322 IMF message except those which see the RFC 5321 SMTP envelope anyway. It is possible to address all, or at least many, recipients of a domain with a single SMTP transaction. As i often said, we do not put constraints on neither the SMTP protocol of which we are a helper of, nor to the IMF content, and i hope also not on such accompanies as RFC 9788. Whether you like safe and performant email, and user right protection, or not. Freedom to email! Security for email! Hasta la Victoria siempre!! Ciao from Germany, P.S.: ACDC does not require the BSDiff algorithm for creating DKIM-DC header field patch data. No need to tease binary diff algorithms. As long as the patch content (schedule) can be worked, any algorithm works. The nice thing of the binary schedule is that no ascii-to-string conversion is needed, and that, by only reading the header bytes, lots of verification etc is possible, lesser is needed for data (it is anyway already "a valid integer"). There can be perfectly spaced allocations etc. It all massively reduces bug surface, and likely runtime cost. --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 -- [email protected] To unsubscribe send an email to [email protected]
