gnu.org mailing lists and DMARC

[Reuben Thomas]

For a couple of years now, the domain from which I'm writing
(sc3d.org) has had a strict DMARC configuration, with p=reject. This
interacts badly with mailing lists that rewrite messages sent out with
the From address of the original author: such message should be
bounced by recipients' systems, which can cause mailman to
automatically unsubscribe them. Eli noticed this in one case where an
active contributor was unsubscribed from a list.

Some major email providers have set DMARC p=reject for all their
users, including Yahoo! and AOL. Others have announced plans to do so,
such as Google and Microsoft. (Google already uses p=quarantine for
googlemail.com, which mean that emails to gnu.org lists coming from
@googlemail.com will be marked as spam by most recipients.)

There are two main ways to deal with this problem:

1. Forbid email addresses that use DMARC p={quarantine,reject} from
subscribing to gnu.org lists. Users would be forced to resubscribe
with a different address; in practise, some won't know how to do that
conveniently, and others wouldn't bother. Also, it will get harder to
obtain such an alternative address: gmail.com currently sets p=none,
but Google has announced its intention to change that. (Also, a
gnu.org list can hardly recommend "get a GMail address": we'd have to
find a suitable service to recommend to our users; I have no idea
whether one even exists.)

2. Reconfigure mailman to work with DMARC. This is what the Debian
project did in 2015 by reconfiguring mailman for their lists to not
rewrite the Subject or modify the message body (in particular this
means not adding a message footer). The relevant bug (with a long
discussion) is here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752084

Options for dealing with DMARC in mailman are documented here:

https://wiki.list.org/DEV/DMARC

I hope you're able to find a good solution for GNU mailing lists: if
it's not possible to reconfigure mailman globally, then list
administrators should at least be warned of the problem and offered
solutions; obviously, if different gnu.org lists end up working
differently, that will create other problems.

-- 
https://rrt.sc3d.org