Re: is it just me or...

[Michael Thomas via NANOG <nanog () lists nanog org>]

On 5/25/25 2:20 AM, Tom Ivar Helbekkmo via NANOG wrote:
> 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 wasn't really the first. Both DKIM and SPF arose pretty much at the 
same time.


> 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.

It's never been especially clear to me why these two piece of policy 
needed to be unified -- it's certainly caused a huge amount of grief and 
a near-infinite amount of standards churn trying to do so as evidenced 
by it taking 10+ years to get to a still non-PS rfc, afaik. SPF had its 
own policy mechanism, DKIM its own too (ADSP nee SSP). Why DMARC is 
"better" is still pretty much a mystery, and my suspicion is it's mainly 
politics.


> 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),

There is no requirement that a mailing list honor or even care about 
DMARC. That's true of all of this: it's purely informational to the 
receiver to use as they will (or not). Expecting mailing lists to do 
anything in particular is a mistake.

> 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.
It would be nice if this were more uniformly true, but alas I don't 
think you can really count on it. Even IETF mailing lists don't resign 
(somebody has claimed this is a bug, but it's been a bug for a very long 
time, from what I can tell).

> 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.

More likely is that the receiving domain (ie, the mailbox provider) is 
the ones doing that. Obviously individual mailboxes don't scale very well.

> 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!

I don't expect that the soi-dissant DKIM2 will do much to help, and it 
seems to be a lot of wheel reinvention for its own sake. The closest 
thing for mailing list traversal is the so-called "modification algebra" 
but it's not really much different than what is already available with 
DKIM (ie, z= and l=), and it unfortunately requires active participation 
of the mailing list software which is going to be dodgy for probably a 
long, long time (this is unlike z= and l= which are under the control of 
the originating domain). Nobody but me, it seemed, cared about using 
that capability with DKIM so anything new imo is too little too late. If 
people started using the current DKIM capabilities as standardized in 
STD 76 I might have a different opinion, but to my knowledge either 
nobody or very few are.

There isn't a silver bullet here and anything that claims so is peddling 
snake oil, IMO.

Mike
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/C7Y5HTODB4YZNKD3E56KYPXNH5OO2EXD/