Re: (forw) [BALUG-Admin] So, DMARC. A week ago.

Quoting Akkana Peck ([email protected]):

Afterthought:

> I looked through the XML but I'm not sure what the various fields mean
> (in some places it says SPF failed, others say it passed, and the same
> for DKIM)

This sort of thing troubles me, too.  The notion of an SMTP receiving
site failing linuxmafia.com's mail on DKIM grounds when I deliberately
don't do DKIM and _declare that_ in my DMARC reference record (DNS
record) seems like serious WTFery.  How much sense does it make to say
linuxmafia.com's mail fails a test that linuxmafia.com's own
authoritative DNS says is inapplicable?

Anyway, as I said, to be continued.

This followup is _mostly_ an opportunity to amplify on what I meant when
I referred to latter Mailman 2.7.x versions (and, I assume, Mailman 3) 
having "DMARC mitigations".  That's what they're called within Mailman's 
admin WebUI docs -- but, it seems to me, they're actually DKIM
mitigations.

I should explain.

The SPF antiforgery mechanism doesn't injure mailing list
deliverability, because it doesn't even look at the internals of
messages.  It's laser-focussed on the _SMTP envelope_, instead, and 
consists solely of a method to vet the envelope "From " header
(recorded in mbox format's leading "From " line that precedes the
SMTP headers proper, and also inserted into the message headers'
Return-Path header).

The idea of SPF is that you, the domain owner, declare in a TXT record
in your domain's address what are all of the authorized IP addresses
you deem to be legitimate senders of your domain's mail.  Then, other
sites that consent to _check_ SPF, if they are receiving a mail
purporting to be from your domain, will check the source IP address
(in the envelope "From " line) against your SPF declaration.  If 
the IP isn't authorized, then the receiving system can implement 
your recommendation (if you said this in your SPF record) to please
reject the mail as forged.

The great thing about this is its universality and simplicity.  Your
mailing list traffic will not run afoul of it, because the MLM 
(mailing list manager) sends out each subcriber's copy of a posting
with the sender's interior "From:" header unchanged, but with the MLM
host's IP and hostname in the envelope "From " header.  So, on the
retransmitted subscriber copy, the relevant SPF check (if any) upon 
arrival at end-destination is that of the MLM host's domain, not the
sender's.

I'm sure you're following so far, and I'm being tediously exact about
this to make sure I'm clear to most other readers.

But now, DKIM, which is a different kettle of fish.

DKIM is cryptographic signing at SMTP origin, and verification of that
signature at receiving systems, done at the level of the SMTP contents
(internal headers and body text).  This checking can foil tampering with
headers or message contents along the route of travel (by making it
tamper-evident).  It also can foil "spoofing" (forging) of a legitimate
site's addresses on mail from fraudulent sending systems trying to
imitate a real system's identity in forged mails, by reliance on
cryptographic signing verifiable at from a public key published in the
real domain stakeholder's DNS.  Since the fraudsters don't have the real
system's public-key keypair, they cannot believably DKIM-sign the forged
mail.

However, problem:  MLMs unavoidably edit, for purposes of generating
subscriber copies of a post, some of the original post's SMTP headers.
The idiots at Yahoo who designed DKIM either didn't know, or didn't
care, that this unavoidably causes DKIM verifiability to _break_ upon
transmission of that post through the MLM.

So, what's the "mitigation"?

It's an optional setting in each Mailman mailing list's admin WebUI:
On the General Options page, there is a setting called from_is_list that
can be set to "Mung From".  If the listadmin opts for this setting,
then, on outbound subscriber copies of posts from subscriber domains with
especially militant (explained in next paragraph) DMARC policies, the
sender's From: address will be auto-edited to the mailing list's
address.

This rather horrible kludge, the same general sort of awfulness that
notoriously broken, misbegotten "Reply-To munging" does, list email
address, gets applied _only_ if the subscriber's MTA has a "p=reject" or
"p=quarantine" DMARC policy.  Otherwise, happily, Mailman will leave the
user's SMTP headers alone, and not munge.

Why does the "munging" circumvent the problem?  Because, after munging, 
the sending domain (the internal "From: " SMTP header domain has been
changed, and therefore the original domain's DKIM conformance (or lack
thereof) is no longer relevant.

This is labelled "DMARC mitigation" on grounds that it's applied or not
applied based on the sender domain's DMARC record, _but_ the actual 
problem it circumvents is caused by the botched, mailing-list-hostile,
design of DKIM, the layer under DMARC.

And that, for now, is why I'm having nothing to do with DKIM (and got
dragged unwillingly into dealing with its Yahoo-defined superset DMARC).

Another of my sources of pique, in all this:  My best administrative
option, for now, in a DMARC policy appears to be "p=none" in my DMARC
record -- but, at the same time, I'm declaring that my domain does SPF,
which it has done for almost 20 years.  Before adding DMARC, it was a
simple situation: I hoped and expected that SMTP sites would check and
honour my SPF record.  But now, I _also_ have a DMARC record that says
"policy = none".  Does that mean sites reading the DMARC record will
_ignore_ my SPF record (until I change the policy to "p=reject")?  

I really have no idea.  It's a fscking bureaucratically designed 
mystery tour.

Screw Yahoo, seriously.  And their little AOL, too (those now being the
same dying company).

-- 
Cheers,                          "Mastodon: owned by nobody and/or everybody!
Rick Moen                        Seize the memes of production!"  -- jwz 
[email protected]              https://www.jwz.org/blog/2023/11/mastoversary/
McQ! (4x80)