Re: is it just me or...

[Tom Ivar Helbekkmo via NANOG <nanog () lists nanog org>]

Rich Kulawiec via NANOG <nanog () lists nanog org> writes:

> On Fri, May 23, 2025 at 01:49:07PM -0700, William Herrin via NANOG wrote:

> > I understand this has to do with DKIM crappiness where if any trace of
> > the original email address remains in the From: header, the message
> > may be rejected.
>
> I believe it's DMARC, but: also crappiness.
> [...]
> But all this DMARC and DKIM complexity and bag-on-the-side-of-a-bag ad
> hackery must be worth it, because surely they have solved the spam problem
> (narrator: NO!) and forgery problem (narrator: NO, AYFKM?!).

These misunderstandings are rather common, so I'd like to point out a
couple of things.

First: SPF/DKIM/DMARC are not about spam, so that part is irrelevant.
What they are about is protection against forged email.

Next: no, these mechanisms do not totally solve the problem of forged
email.  As with every other problem faced by humanity, there is no
silver bullet that alone fixes the whole thing.  But they significantly
improve the situation, and that's why they're used.

A few words about each of these, from the point of view of a domain
owner who wants to make it difficult for an attacker to forge email to
look like it came from within that domain:

SPF was the first.  It lets you publish, through DNS, a list of the
addresses of the mail servers that you have authorized to send email
from your domain.  When some mail server tries to deliver email
purporting to be from your domain, you're asking the recipient mail
server to check that list, and accept the email if the delivering mail
server is on it, but refuse if it is not.

SPF broke forwarding, both for individual recipients, and through email
distribution lists, because the forwarding server wasn't on the list.

DKIM was next.  It lets you publish, again through DNS, the public key
of a public/private pair.  You then use the private key to create a
cryptographic fingerprint of the message, using the body and a few
selected headers (To:, Cc:, From:, and Subject: normally included).
When a mail server out there receives the email, it can use your public
key to verify the fingerprint.  A match implies that the email has not
been modified since it left the signing server.  If the domain in the
"From:" header matches the domain where the public key is stored, the
recipient knows that the email was DKIM signed by a mail server trusted
by the sending domain (since it must have the private key).  It can,
therefore, assume that the email really is from the "From:" address, and
has not been modified along the way.

DMARC, finally, ties these things together.  It lets you publish, once
again using DNS, a few policy options for the handling of SPF and DKIM,
for what you want done with the email, and for reporting back to you
what was done, and why.  DMARC requires either SPF or DKIM to pass, and
you can choose whether you want the recipient system to quarantine or
simply refuse email that fails to pass at least one of them.

A modern mailing list is not a simple forwarder.  It sends out copies of
the received email item (which, then, will have passed the DMARC
requirements of the sending domain, if specified, or it wouldn't reach
the mailing list software in the first place), but it will typically
modify it before sending it out.  This can be by adding a tag to the
"Subject:" header (to help recipients direct the mail into a folder), by
adding a footer that says which list this came from, and giving a link
you can use to unsubscribe, or by making any of a number of other
modifications list software sometimes makes.  This will break DKIM - and
SPF, of course, is already broken.

So mailing list software today typically checks the originating domain's
DMARC configuration.  If that has a policy other than "none" (which says
to deliver email even if it fails both SPF and DKIM), it will send the
email "From:" the list, and not the originator.  The email then nicely
passes the mailing list's own SPF, of course.  Additionally, the mail
server sending it out from the list software will normally DKIM sign the
outgoing email, so it ends up properly authenticating as coming from the
mailing list software.  This means that members of the list can choose
to trust the mailing list owner to have configured everything so that
they've properly verified the originating sender, and are not passing on
something that is a forgery.  If their own mail server is properly
configured to check SPF/DKIM/DMARC, they can trust that the email is
really arriving from the (trusted) mailing list.

This stuff isn't perfect, of course.  As is obvious from what I wrote
toward the end of the last paragraph, transitive trust is a problem that
it would be nice to have a good solution for.  ARC is an attempt at
this, but has failed to gain traction.  Let's hope that DKIM2 (which
John Levine mentioned in another post in this thread), by attacking the
problem from another angle, does better!

-tih
-- 
The creation of the state of Israel was a regrettable mistake.  It is
time to undo this mistake, and finally re-establish a free Palestine.
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/B6PDVENGYF4T2YBG4KTPSUS44EMX6FQ2/