[Savannah-hackers-public] DMARC related changes starting this week for FSF hosted Mailman lists

[Ian Kelling]

Over the next few days, the Free Software Foundation will be making
changes to our GNU Mailman systems, including lists.gnu.org,
lists.nongnu.org, lists.libreplanet.org, lists.fsf.org, and
lists.endsoftwarepatents.org, in order to address mailing list
deliverability issues reported by many users.

Messages sent from users with strict DMARC policy domains like yahoo.com
are often being rejected when sent to list subscribers by Mailman. See
the end of this email for a technical overview of DMARC and DKIM. There
are two ways to fix the issue by changing Mailman list settings.

The first option, and the preferable way for discussion lists, is what
we call the "unmodified message fix." There are Mailman list settings
which modify the messages by adding a subject prefix (e.g. [list-name])
or a footer. Modifying the message breaks DKIM message signatures and
thus DMARC. Following this option, we would turn those settings
off. Many lists are already this way and there is no change for
them. Instead of using the subject prefix to identify a list,
subscribers should use the "List-Id" header, To, and Cc.  List footer
information can also be be put in the welcome email to subscribers and
the list information page by list administrators.

Related to this, on June 7th, we upgraded the version Mailman that we
run. This fixed a bug where we were breaking the DKIM signature of any
reply message.

The second option is for lists which want or need to continue to modify
the message, for example with subject prefix or footer settings. We
would enable a Mailman list setting called dmarc_moderation_action:
"Munge From". With this setting, if a strict DMARC sender sends to the
list, we alter the headers of that message like so:


A message sent to the list:

To: address@hidden
From: Anne Example Person <address@hidden>
Subject: Hi, I have a suggestion to improve x

The message Mailman sends to list subscribers:

To: address@hidden
From: Anne Example Person via Alist <address@hidden>
Reply-To: Anne Example Person <address@hidden>
Subject: [alist] Hi, I have a suggestion to improve X

Without going into all of the details, here's a few points about why we
concluded the unmodified message fix is better for discussion
lists. Email clients don't all treat munged messages the same way as
unmunged, and humans read these headers so it can confuse people,
causing messages not to be sent to the expected recipients. GNU Mailman
has an option to do "Munge From" always, but does not recommend using
it[1]. While we're not bound by what others do, it's worth noting that
other very large free software communities like Debian GNU/Linux have
adopted the unmodified message fix[2]. The unmodified messages fix
avoids breaking DKIM cryptographic signatures, which show the message was
authorized by the signing domain.

New discussion lists' default settings will be to send unmodified
messages. Existing discussion lists that add subject prefixes or footers
will have "Munge From" turned on, and then we will email the list
administrators and moderators asking if they are ok with changing to
unmodified messages. If they do not object within 1 month, we will
change their list settings to send unmodified messages. Sometimes the
list administrators and moderators emails goes out of date. If you have
the administration password for a list, please log in and check that
they are up to date at the top of the "General Options" section of the
list administration interface.

For announcement lists that do not have discussion, munging does not
have nearly as bad an impact. Announce lists with subject prefixes or
footers will get "Munge From" applied. I will email the list owners and
moderators to let them know about this issue and they can change to
using unmodified messages if they want. Announce lists created in the
future will send unmodified messages by default.

Debbugs lists prepend a bug # to the subject. These will get "Munge
From" applied. An example of a debbugs list is bug-gnu-emacs[3]. Debbugs
maintainers can consider if there are any other changes they want.

For -commit lists, commit messages are created by a program running on a
single server, not the authors in the from headers. This means they cannot have
valid DKIM signatures and so they will get "Munge From" applied and
always need it. An example of a -commit list is gnuastro-commits[4].

For any Mailman list administrator who wants to change or look over the
relevant settings: The dmarc_moderation_action setting is under "Privacy
Options" subsection "Sender Filters". The only options that should be
selected are "Accept" or "Munge From", along with corresponding changes
to the subject_prefix option under "General Options", and msg_footer is
under "Non-digest options".


A short DMARC technical overview:

DMARC policy is a DNS txt record at a _dmarc subdomain. For example:

$ host -t txt _dmarc.yahoo.com
_dmarc.yahoo.com descriptive text "v=DMARC1; p=reject; pct=100; 
rua=mailto:address@hidden;";

The only important thing there for our purpose is p=reject. p=reject
means that conforming mail servers that receive mail with a from header
of *@yahoo.com will reject that email unless it was either 1. sent from
Yahoo's email servers, or 2. its DKIM signature is verified. A DKIM
signature[5] is a public key cryptographic signature of the email body
and some headers included in the message header "DKIM-Signature". A
verified DKIM signature means that email body and signed headers have
not been modified.

Comprehensive resources about DMARC tend to downplay or ignore its
problems, but some that have helped me are Wikipedia[6], the Mailman
wiki[1], dmarc.org wiki[7], and the DMARC rfc[8].

[1]: https://wiki.list.org/DEV/DMARC
[2]: https://lists.debian.org/debian-devel-announce/2015/08/msg00003.html
[3]: https://lists.gnu.org/archive/html/bug-gnu-emacs/2019-06/threads.html
[4]: https://lists.gnu.org/archive/html/gnuastro-commits/2019-06/threads.html
[5]: https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail
[6]: https://en.wikipedia.org/wiki/DMARC
[7]: https://dmarc.org/wiki/FAQ#senders
[8]: https://tools.ietf.org/html/rfc7489

--
Ian Kelling | Senior Systems Administrator, Free Software Foundation
GPG Key: B125 F60B 7B28 7FF6 A2B7  DF8F 170A F0E2 9542 95DF
https://fsf.org | https://gnu.org