[Mailman-Users] options for dealing with DMARC

[Stephen J. Turnbull]

Jordan Brown writes:

 > per se.  I don't want to turn on any domain-global rejection of
 > "failing" mail, because I wouldn't want to reject messages sent to the
 > non-mailing-list addresses.

You should think twice about that.  The reason why AOL and Yahoo! have
turned on the reject policy is that they leaked hundreds of millions
of address books, and the spammers were sending "recommendation from a
friend" spam apparently from the address book to their contacts.

Apparently, every "campaign" using this technique involved hundreds of
millions of messages to Yahoo! addresses alone.  Since p=reject, the
spammers try every once in a while to see if (a) p=reject is off or
(b) recipients are not respecting it.

 > It would be OK to add a "failed DMARC" header to the message and
 > then have Mailman reject on the basis of that header.

If you have a DMARC-capable MTA, you may already have one, and if not,
you probably can turn it on.  It's called the Authentication-Results
field (documented in RFC 7601).

In Mailman 3 you will soon (Mailman 3 from gitlab, mid-January?) be
able to do better in some cases.  We have several implementations of
the ARC protocol, which does check the various security protocols (SPF
-- almost guaranteed to fail, DKIM, and DMARC), and adds a signed
field to inform the next hop that you checked and what passed.

(Of course it's better to have your MTA do the ARC stuff.)

Some of the big providers (GMail and Yahoo!, I think) are already
implementing ARC.  I'm not sure if there's a way to determine if a
provider implements ARC automatically, so we may have to add a
whitelist for known ARC sites and suppress decorations or From munge
on the rest.

(What I'd like to do is tell everybody to let it fail and tell the
subscribers to request that their providers implement ARC }:^}, but
that's not really fair to you list owners.)