Dave Crocker wrote in <[email protected]>: | |I've drafted a specification intended to provide a DKIM-based means of |controlling DKIM Replay, based on community discussions of what is |needed. The spec also includes the return address coverage that has |been discussed, though I am not yet clear enough about its use to have |attempted detailed explanation of how it works. | |As with most initial specs I do, I believe the design is reasonable, but |am quite sure that the details will be somewhere between deficient and |terrible. Please adjust comments and suggestions accordingly, with |attempts to avoid declaring the mere fact of either condition being |appreciated. | |d/ ... |URL: https://www.ietf.org/archive/id/draft-crocker-dkor-00.txt
I read it and it went in as fluent and refined as only decade long experience can do. "Master[l]y" we call this in Germany (at least traditionally there was a craftsmanship heritage to protect). The technical spec as such i like in parts. I like it much better than the hand-in-hand stuff taken from the Google draft that is part of the other edkim proposal (i call it edkim henceforth with the words of Jeremy Harris on i think ietf-smtp@, it sounds rhymeful also), and it will work even without the entire world being changed at front. Exposing the SMTP envelope data is against what "i" see (with my granted tiny point of view "with my own eyes only"), even trace headers become anonymized, maybe even "more and more". I do not like single recipient at all. If at least all these recipients of a domain were bundled which are also part of the public address list of the transported message! Then only Bcc: aka hidden recipients would need the single recipient mode. Into the same notch, i do not really like generating the data always, becoming single recipient alongside, even if no consumer is interested in the data at all. This especially given that at least today SMTP is more or less a single-hop protocol. SPF will fail otherwise. You need SRS aka sender rewriting to work around. This changes envelope data, and the draft does not (i read it once on late Saturday night / Sunday morning) tell what to do about that. (Likely the same headers produced *if* the DKIM software knows about them.) Unfortunately i now lead over to my DKIM v1 proposal ACDC (edkim, too). You may stop reading here. It will ask the recipient(s) domain whether replay protection is desired (aka DNS lookup). If so it will generate per-recipient-domain subsignatures, bundling all recipients that belong to a domain; as this subsignature is removed again by the destination domain, also Bcc: recipients can be included in the subsignature. The message and the DKIM signature are valid even with the subsignature removed: verification will still succeed! Ok the subsignature will only be generated if the recipient domain announces so, intermediate hops will thus not be able to verify the SMTP envelope if that is not the case, but in the modern internet as it is today this problem seems niche. (Especially so if ie alias expansion and mailing-list indeed "cause a new message", as they change the envelope.) --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]
