I buy this argument. You're quite correct, DKIM doesn't have any actual problems. It's perfect. It does exactly what it's specified to do.
DKIM is also insufficient for the purpose for which it's trying to be used. And there's an argument that "the purpose of a system is what it does". The purpose for which DKIM is trying to be used includes the kind of reputation and "quality of email coming from X domain" tracking that pretty much every medium-to-large email operator is doing - and it insufficient for that purpose. On that basis... On Sun, Apr 6, 2025, at 14:56, Dave Crocker wrote: > Stray, Sunday night thought for the working group to consider: > >> DKIM does not have any actual problems. Even DKIM Replay is not a DKIM >> problem. >> > Consider: > >> DKIM was designed to associate a domain name to a message, with the intent >> that no message will have that association without the 'approval' of the >> domain owner. The purpose is to create a noise-free channel, for reputation >> analysis of mail having that association. >> >> And indeed, that´s what DKIM does. >> >> Although Replay is a problem, it is not a DKIM problem, because the replayed >> messages really were associated with the domain name through regular DKIM >> authorization. (My noting that the Replay problem is an externalization of >> limitations to control and accountability of a platform's users is not meant >> as criticism, but to focus on the reality that, again, DKIM was never >> intended to deal with problems within the scope of control of the domain >> owner.) >> > The goals for the new effort are for a very different set of services. There > is nothing wrong with wanting those services, but really, they are not DKIM. > > The semantics of the new effort really are orthogonal to DKIM. (And that is > one of the reaon the technical errors in the Motivation draft demonstrate a > fundamental misunderstanding, rather than being minor distractions.) > > One of the reasons a new effort should adopt a different name is to help > people understand that the new effort is for something entirely different > from what DKIM intended to do. > I'm perfectly happy to call it something completely different - I'm to a large interest more interested in the tech than the branding... but let's be clear on my reasoning for using the name DKIM is "it is intended to plug into the same place in the stack as DKIM does; and reuse the key infrastructure of DKIM - meaning it will be more understandable to MOST people if it's called DKIM2 than if it's called e.g. SEEDS (Signed Explicit Email Destination and Source) - and that branding will assist with getting people to convert. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd br...@fastmailteam.com
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
