For succinctness I shall call your proposal DKOR and ours DKIM2 below, acknowledging that the name DKIM2 does not have consensus.
On Sat, Apr 26, 2025, at 13:07, Dave Crocker wrote: > On 4/25/2025 8:13 PM, Bron Gondwana wrote: >> On Fri, Apr 25, 2025, at 12:31, Dave Crocker wrote: >>> Your approach requires changing the entire email infrastructure. When will >>> you achieve utility at scale? Not for a (very) long time as ARC and IPv6 >>> demonstrate. >> >> Agree, > Bron, > > Glad you agree that your proposals entail a massive barrier to adoption and > isn't likely to reach critical mass for a long time. > I agree to the first half of that, with a caveat that I shall expand upon below. >> - and has been socialised among many of the high traffic sites of the email >> infrastructure, such that the benefits of becoming interoperable will be >> high because the alternative is to lose the ability to send to "must send >> to" sites. In the same way that supporting HTTPS became necessary to access >> web sites at some point due to pressure from major sites. > HTTPS followed an incremental adoption path, not all that different from what > I've proposed, since there is utility for any pair of client and server that > adopted it. This is profoundly different from your proposal. > I disagree with your "profoundly different" assertion here. DKOR is a strict subset of the capabilities provided by DKIM2. DKOR provides benefits as soon as both a single sender and a single receiver implement it, for direct mail flows between those two systems. *DKIM2 also provides immediate benefits* as soon as two systems support it, for direct mail flows between those two systems. Both systems provide much less benefit if messages flow indirectly through a forwarder or mailing list that is not participating. DKIM2 provides an upgrade path where when the intermediate systems are upgraded to support DKIM2, every hop of the pathway is DKIM2 and you can eventually start requiring a full DKIM2 pathway to accept mail from more sites. I can anticipate a future DMARC-style technique for publishing a DNS record saying "do not accept messages from this domain that have exited the DKIM2 ecosystem at any point". DKOR, by my reading, can never reach that endpoint by itself. I agree that it's a potential stepping stone in the right direction, but by itself it's not sufficient. > As for all the socialization you've done, please refer to the 15 years of > government and corporate support OSI had. And IPv6. See how well that worked > for them? > True. Socialisation is a necessary but not sufficient condition for success. You can point to cases where it has failed and that doesn't invalidate the necessity. I can counter point to specifications that are technically good but failed to gain adoption. > Also, your referencing all that support seems to qualify as an attempted > appeal to authority, since your reference is quite vague, but claims broad > support. Also, other than very, very few folk, none of those supporters are > here. I'm sure you are not saying that the ones who /are/ here are the only > ones that matter. Right? > > > >>> When will mine achieve utility? As soon as any sender and their receivers >>> implement it. When will they achieve it at scale? As soon as more pairs >>> implement it. Incrementally. >>> >>> Your approach entails quite a lot of mechanism. Mine is utterly trivial. >>> That is not a minor difference. >>> >>> Your turn. >>> >> Our approach solves the whole problem enough to be worth the effort. > You keep saying that. I keep asking for detailed scenarios that show how. > You then keep coming back witht he same, generic claims. > OK - let's suppose that I had DKOR headers on this email. Presumably my system would send two messages with DKOR headers; one MAIL-FROM: [email protected] RCPT-TO: [email protected] the other MAIL-FROM: [email protected] RCPT-TO: [email protected] In the first case, it would travel directly from Fastmail's infrastructure to... Fastmail's infrastructure (I was legit unaware of that until I just did an MX lookup). Trivial case, clearly works fine. In the second case, there will be 297 copies sent on. 61 of them to gmail. Still containing those same MAIL-FROM and RCPT-TO headers. Probably also with modifications to subject header and body such that the original DKOR fails in multiple ways. It's unclear from your draft whether the IETF mailing list server is expected to add its own MAIL-FROM and RCPT to headers to each email or not, but regardless... there's no way for Gmail to know - if this was a spammy message, whether the spam was generated by me and sent to the IETF list, or whether the IETF list was a bad actor. It would need a reputation database. You've basically re-implemented the same problems that ARC has. ... With DKIM2, the second message would have on its copy from me: `DKIM2-Signature: i=1; mf=``[email protected]``; rt=``[email protected]``; d=fastmailteam.com` And then on its copies from the mailing list: DKIM2-Signature: i=2; [email protected]; [email protected]; d=ietf.org DKIM2-Signature: i=2; [email protected]; [email protected] <mailto:[email protected]>; d=ietf.org DKIM2-Signature: i=2; [email protected]; [email protected] <mailto:[email protected]>; d=ietf.org etc. Each with a separate signature, so they would be clearly not just a replay of a single message which was directed at the mailing list. Even more importantly, they would have delta header fields: DKIM2-Delta-Header: i=2; b=Content-Type,bXVsdGlwYXJ0L2FsdGVybmF0aXZlOyBib3VuZGFyeT0iXy0tLS0tLS0tLS09XzE3MjkwMDgzODQzMTE0NjAi; t=Reply-To; t=Subject,Re: [Ietf-dkim] Re: Fwd: New Version Notification for draft-crocker-dkor-00.txt; t=To,[email protected] DKIM2-Delta-Body: i=2; c=126-5231 Which would allow the gmail server to tell, if it didn't like content of the message, whether the badness had been introduced by the IETF server, or was present in the original message from me. And it could validate the first DKIM2-Signature (i=1) to be sure that the bad content had come from Fastmail's server. >> Yours brings some benefit, but the overall benefit is trivial > So, making it easy to detect DKIM Repaly is a trivial benefit? Wow. > If it detected DKIM Replay in the general case, it would not be trivial - however it only detects DKIM Replay in the direct case. It's still not possible to distinguish between an alumni forwarder and a DKIM replay; short of keeping a database of every alumni forwarder that points to you, and at scale that's decidedly non-trivial. >> because it doesn't close the forwarding hole and forwarding becomes even >> more of a poisoned chalice than it has already become (Wei showed evidence >> of this and a credible theory for why). > Scenarios, Bron. Show yours working in detail for all this extra benefit, so > others can a) evaluate what it will take to adopt it, b) evaluate its likely > efficacy, and c) consider being able to use different components that might > have superior characteristics. > See above a worked example. I'm happy to do more examples if that's still not clear enough. > To date, we get a constant refrain that has similar semantics to Love It or > Leave It rhetoric that strongly suggests you are looking for the IETFto do > nothing other than rubber stamp your proposal. While I doubt that's in your > head, it is what your behavior looks like to me. > I'm looking for IETFers to make an effort to understand the reasoning behind the design and the reason why the goals are there and maybe meet us in a discussion of the pros and cons of various design elements -- rather than demands of proof for everything which authors of the DKIM2-named drafts have seen in their operation of large-scale email systems, and minute-detail justification of the need to do something about them. >> This is my objection to your proposed approach. It's both trivial in its >> implementation, and trivial in its benefit. > Again, saying that making it easy to adopt and easy to use and effective for > finding Replay is a trivial benefit seems really quite surprising. > I reject the assertion that DKOR will be effective for finding Replay. It is indistinguishable from alumni forwarding or mailing lists, and provides no upgrade path to make it distinguishable. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd [email protected]
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
