responding to DMARC breakage

Sat Apr 12 14:12:09 UTC 2014

Hi Folks,

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

Miles Fidelman

-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra