[Mailman-Developers] MM3 DMARC mitigations

[Stephen J. Turnbull]

Removing known MM-DEV subscribers, the CC list is getting long.

David Andrews writes:
 > At 11:06 AM 11/5/2016, Mark Sapiro wrote:
 > 
 > >However, I've just become aware that Microsoft has implemented another
 > >"feature". [...] one of the tests is the To: and
 > >From: addresses are the same. That means that any message To: a list
 > >with DMARC mitigations applied will be sent From: the list and any
 > >recipients using these Microsoft services will see that warning in the
 > >list message[1].

The fact is, every time we work around the actual semantics of
"p=reject" (described in the block quote below), the spammers can hide
behind our usage, I expect they will, and those tricks will be given
spam (or worse, phish) points.

Maybe it's time to default to rejecting posts from p=reject domains,
with the explanatory message:

    Your domain publishes a "p=reject" DMARC policy, which is a
    statement to recipients that they allow you to send only
    authenticated direct mail.  This is a mailing list which re-sends
    your mail after processing, and therefore you are not allowed to
    post according to your email provider's policy.  Please repost
    from an address which allows you to post to full service mailing
    lists.

    Note: A few large providers claim to permit posting to mailing
    lists, but publish "p=reject" anyway.  They privately acknowledge
    doing so to protect users from spammers and phishers who have
    stolen millions of address books and other private information of
    users from them.

Of course this could be conditional on the presence of a header OR a
footer OR Subject-munging in the list config.  I'm semi-serious, but
more likely is a "pass-through" tactic: ie, no headers, footers, or
Subject-munging on posts from "p=reject" sites.  The point is that
spammers can omit those things, but they can't emulate the valid
authentication on posts from DMARC sites.  Unfortunately, some lists
do need to add disclaimers and the like, so can't use the pass-through
approach.

The only tactics that actually work in the sense that spammers can't
use them are (1) ARC (but that requires cooperation from receiving
hosts that is unlikely[1]), (2) "pass-through" operation, and (3)
preemptive rejection/discard.

 > This message has started appearing on messages on a list I subscribe 
 > to at work, the state of MN, and they use hosted office 365 etc., and 
 > the messages are almost always from legitimate senders, so going to 
 > be a problem.

My condolences.

Footnotes: 
[1]  It needs to be *all* receiving hosts.  Some of them will
undoubtedly be sufficiently lacking in email expertise that they
delegate these decisions to Office 365 etc.