On 12/9/2022 9:36 AM, Michael Thomas wrote:
A lot of the early motivation for DKIM was that it might be helpful
for combating phishing.
At the time tons of email providers were open relay sewers. What DKIM
allowed is that you could at least determine which domain was sending
it if they signed. Ideally you want to catch the phishing before it
hits the inbox, but obviously some of it is going to get through. A
user might not realize for weeks or months that a message was an
attack and that's doubly true if it was successful. One of the
original goals was that the sending domain could theoretically take
responsibility for sending the mail. It was never defined what that
might entail but since a protocol was never envisioned for this to
happen in transit, it was tacitly assumed that it was some out of band
mechanism, like oh say, sending mail to abuse@ or something like that.
They could then see that it was really from them and take action on
the user who sent it. That's especially true when submission became
the norm.
If the signature was stripped out of the mail, it gives an easy out
for the sending domain to disclaim its involvement. That defeats the
entire utility of taking responsibility. That's a problem, and we
shouldn't be stripping out perfectly valid functionality.
DKIM's motivation was (and is) to create a noise-free channel, by
reliably associating an accurate identifier to a message stream. This
permits a receiver to evaluate the messages in that stream, without
concern that it has been polluting by other (unauthorized) sources using
that identifier.
The specification's language about "some responsibility" is
intentionally vague about the nature and degree of that responsibility.
So, for example, the semantics of DKIM do not at all mean that the
identifier that is attached is the (or even 'a') sender, per se. Not
the author, not the originating MTA, and not necessarily any other
relay. That the identifier is often associated with one or another such
entity is something entirely outside of the DKIM specification.
The concern was and is generally about the broad messaging category
called spam, and not specifically or solely the sub-category called
phishing.
The above reference to things happening in transit and some out of band
mechanism sound interesting, but don't have much to do with the original
DKIM work, which really was only about giving receivers a noise-free
basis for evaluating messages associated with an identifier.
The concern for post-delivery evaluation and some sort of follow-on
actions associated with 'taking responsibility' were not part of the
DKIM development effort. There is nothing in DKIM's development that
was intended -- nor do I recall discussion -- for post-delivery
forensics or non-repudiation. And article I cited, as well as the
replay problem, demonstrate basic problems with such a use of it.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
