> In the DMARC draft, I noticed this:
> > Descriptions of the PolicyOverrideTypes:
> ...
> > mailing_list: Local heuristics determined that the message arrived
> > via a mailing list, and thus authentication of the original
> > message was not expected to succeed.
> Could somebody explain what that means and whether it can be used to
> mitigate the current issue?
"mailing_list" is an indicator that a Receiver has chosen to override the
policy the Domain Owner specified for a failed DMARC check, on the basis that
the Receiver has knowledge that the message was forwarded by a mailing list and
thus the DMARC failure is expected. A whitelisting mechansism, in other words.
This is viable mitigation in theory, but not in practice, because it assumes
that Receviers are aware of and can verify mail they receive from every
possible legitimate mailing list out there. That's clearly not possible.
> Or are substantial changes needed
> in the fundamentals of DMARC?
The underlying technical issue is that the two technologies DMARC is built on -
DKIM and SPF - both attach additional/restrictive semantics to longstanding mail
system fields. (Broadly speaking, From: for DKIM and MAIL FROM for SPF.)
An unavoidable consequence of doing this is that longstanding email mechanisms
that depend on the semantics of those fields are going to be affected. (Mailing
lists are the obvious example for DKIM, autoforwarers the obvious one for SPF.)
And when you couple this with an unforgiving policy choice, things break badly.
If you're expecting any of this to be fixable by some technical change to
DMARC, DKIM, or SPF, you can forget it. The design constraints in the space are
very tight, and if you "fix" them to address the issues they cause, you ruin
their effectiveness.
> I assume the authors will be adding a discussion of this issue to the draft.
You're really looking at the wrong draft. draft-crocker-dmarc-bcp-03 talks about
when p=reject should be used, and has this to say:
DMARC provides protection against some forms of email domain name
abuse. Its restricted policy form (p=quarantine or p=reject) is not
intended for all use cases, and is beneficial only in the presence of
an actual spoofing problem. You may, however, want to protect
mailboxes by checking inbound mail, and you may want information
about how your domains are showing up at recipients by publishing a
p=none record.
It goes on to discuss the use of p=reject with domains that only send
transactional. AFAICT there is no discussion of when *not* to use p=reject, and
why. Nor, for that matter is there substantive discussion of mailing_list,
and why it's not a general solution to the problems caused by p=reject.
More generally, I have to say I find myself in substantive agrement with Miles
Fidelman and Hector Santos on this matter. There has been a cascade failure
leading to a colossal screwup. And while Yahoo is clearly the primary malfeasor
here, as is always the case in a cascade failure, there's blame aplenty to go
around.
Like it or not, the IETF published a draft that defines certain mechanisms
which, if used improperly by a large provider, cause serious problems for a
large number of people. The text describing the consequences of the use of
those mechansisms in the drafts is, IMO, entirely inadequate.
And it's not like we didn't know. As others have pointed out, this issue
existed in the earlier ADSP proposal. It was given insufficient attention there
as well.
The clear discrepancy between the fine print regarding intended status in the
specifications (which only engineers read) and what's on the DMARC web site
(which is what managers read) is also nothing short of deplorable.
Of course the IETF can fall back on the usual excuses, including, but not
limited to:
Yahoo, of all ISPs, should have known better
We don't tell people what to do
It was just a draft
It was never intended to be a standard
We're not the Internet Protocol Police
etc.
I'm sorry, but this time none of these dogs are hunting for me. An attractive
nuisance is an attractive nuisance, and this is what the IETF has, albeit with
the best of intentions, managed to create.
The real question we should be discussing is what options the IETF has to try
and address this.
Ned