responding to DMARC breakage
mfidelman at meetinghouse.net
Sat Apr 12 14:12:09 UTC 2014
It occurs to me that Yahoo's deployment of DMARC p=reject, and the
choice of several big mail operators to honor that, has created a
situation not unlike a really routing table or nameserver, snafu ---
someone's published information that's caused lots of things to break.
At an operational level, this comes down to Yahoo publishing a DMARC
record into their nameservers containing "p=reject." As a result,
Yahoo, and several other very large mail systems, are bouncing huge
amounts of mail.
We see, and react to, routing and nameserver snafus all the time. The
response is usually an immediate, cooperative response to fix the
problem as quickly as possible. Sometimes an operational problem
uncovers a software bug, or vulnerability, or a protocol failure mode -
which triggers various responses (CERT alert, software patches, protocol
revisions via the IETF).
Running a mail system and providing some hosting and list services, most
of the operational issues I've run into involve nameserver corruption,
over-aggressive spam blockers (and, of course, ongoing barrages of spam
and persistent cracking threats). In most cases, problems are easy to
resolve, and all involved are cooeprative (if sometimes slow). About
the closest analogy I've encountered, to the current situation, are the
more aggressive of the anti-spam blocklists (remember when someone would
an entire subnet, with intent, when one host on that subnet generated
some spam, or the operators who would extort payment for "expedited
removal?"). By and large, market pressure has largely driven the worst
actors into oblivion - but there don't seem to be any measures, with
teeth, for dealing with bad actors.
It strikes me that this situation is analogous:
- several very big players have put a protocol into production that is,
charitably, immature (DMARC is an informational internet-draft, not even
an RFC, much less a standards-track RFC - and its backers have pretty
much ignored any input from mailing list operators)
- Yahoo published a dns record that triggers a protocol mode that
results in huge amounts of mail bounces and operational disruption.
- Yahoo (operationally) and the DMARC authors are intentionally
un-responsive (as are hotmail, comcast, a few others; gmail, I note is
not bouncing mail)
How do we respond as operators, beyond late-night, ad-hoc patches to
list software, that only partially resolve the problem?
What kind of responses are available? In the broader scope of things,
what kinds of responses are typical if someone publishes corrupted
information and then doesn't cooperate in fixing the situation - be that
through obliviousness, incompetence, lack of resources, laziness, or
active intent (criminal or not)?
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra
More information about the NANOG