> On Aug 13, 2023, at 20:31, Jesse Thompson <z...@fastmail.com> wrote:
>
> If I understand based on my limited view of history, DKIM was designed for
> authentication between two hops. Signature survival across intermediaries was
> only achievable by encouraging intermediaries to not make any changes to the
> message "inside the envelope" such as standards-allowed MIME re-encoding
> (which, notably, prevents intermediaries from improving MIME
> interoperability).
I'm not the first to say it, but it was the opposite. The original statement
from the Domain Keys folks from Yahoo was that when your bank sends an email to
you, your ISP can know that, even though it's bounced through your alumni
association. It was *specifically* a three-hop thing in the distilled elevator
pitch.
Remember as well that for two-hop sending, SPF was a preferred thing and there
was a lot of conversation that tried to put them as competitors. We argued
against that. I think it's pretty obvious that the two together are much better
than either alone.
Here's a vastly oversimplified case. Consider someone who runs email on a
small, NATted network. Under SPF, if a spammer sends a message from any host
outward, it has the same path and thus passes SPF despite being spam.
DKIM is domain-to-domain authentication, not user-to-user, because user
relationships are complex. Here's a not-uncommon example:
Incoming email sent to info@domain goes into Alice's mailbox, via something
akin to virtual users in Postfix. From time to time Alice sends a message from
info@, without there being an actual user. The DKIM edge MTA signs it. That
means that the mail architecture has to deal with the gap between Alice and
that signing MTA. Any given setup is either a bug or a feature that they, not
we, have to manage. Delegated email is a thing.
Pulling in what you said above that:
> [...] If DKIM is what is used by ESPs to authenticate message submissions,
> and the fallback for non-DKIM signed mail is to allow the submission, then
> certainly that is something spammers would leverage. That seems like an
> unlikely scenario since ESPs require other forms of authenticating message
> submission.
I'm not sure I really understand your case here.
DKIM authenticates the "administrative domain" of the sender, not the user. As
noted above, the domain has to do a bunch of user management that's outside the
scope of DKIM. That management can be strict (any user can only send email with
their own From on it) or loose (any user can just telnet to port 25 and start
sending emails from anything) or anything in between, and any decision has
consequences the sysadmins have to adapt on their own.
I think you're saying more or less what I was saying, but I'm not sure.
As a last note, internal signatures like OpenPGP, and S/MIME, and anything else
are inside the message and thus orthogonal to DKIM (and SPF).
Thus, SPF is a verification of the network path. DKIM is an authentication of
the sending MTA. S/MIME etc. is an authentication of the sender. Each has its
own failure modes, and each has weird edge conditions and gray areas. I look at
it as they go up a stack of sorts -- network -> domain -> user.
Jon
_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
