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.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @dcrocker@mastodon.social
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
