RIPE Mailing Lists and DMARC

In addition to face-to-face meetings, mailing lists have long been used for discussion and coordination over a range of topics. First there was ripe-list@ripe.net, but other lists were soon set up for focussing on more specific topics. Now RIPE has ten active working groups, each with its own mailing lists.

Nowadays, the community also uses other communication channels, such as forums and social media - not to forget face-to-face discussions at RIPE meetings. However, the mailing lists remain one of the most important mediums for communication and cooperation. Ultimately, it is through discussion and input on the mailing lists that decisions get made. Indeed, the policy development process itself is conducted on the basis of consensus reached on the Address Policy Working Group mailing list.

It is for this reason that Mailman, the mailing list solution used for the RIPE mailing lists, is so important to RIPE. It is also why the RIPE NCC must work to continue to ensure that Mailman is accessible for all users.

DMARC

Recently we've noticed that some of the users on the RIPE community mailing lists have been affected by DMARC (Domain-based Message Authentication, Reporting & Conformance). DMARC is being deployed by more and more email providers, but at the moment it’s only effecting a small percentage of our mailing list users.

The DMARC RFC states that

“Originators of Internet Mail need to be able to associate reliable and authenticated domain identifiers with messages, communicate policies about messages that use those identifiers, and report about mail using those identifiers”

and therefore the domain of the mailing list should be inserted into the header of the email.

How does this impact users?

As it stands on the RIPE NCC managed mailing lists, if a mail is sent from an email provider who are implementing "p=reject" DMARC policies to a mailing list, then the recipients who are respecting the same DMARC policies will not receive the email.

Initially we deployed a community suggested fix, but this was only a temporary solution and some email clients were affected by this change.

One issue is that the DMARC RFC seems to contradict RFC 5321 which states

"When a message is delivered or forwarded to each address of an expanded list form, the return address in the envelope ("MAIL FROM:") MUST be changed to be the address of a person or other entity who administers the list. However, in this case, the message header section (RFC 5322 [4]) MUST be left unchanged; in particular, the "From" field of the header section is unaffected."

Therefore any DMARC related Mailman patch applied would break RFC 5321.

If we don’t apply a DMARC patch to our mailing list then there is possible that community may not receive emails from their subscribed mailing lists.

The solution 

At this time, there are two paths we could take. First, we can move ahead and do nothing. This would amount to knowingly accepting that emails sent by certain users will not be seen by certain others. Alternatively, we can upgrade our Mailman instance and ‘munge’ the from head to include the mailing list name, thus satisfying the DMARC rules and ensuring that any user previously affected user would receive emails from any other subscriber. The downside is that, in doing so, we would be breaking RFC 5321.

So what to do? Our solution for the time being is to accept what we see as the lesser of two evils. Rather than do nothing and risk not letting people be heard, our plan is to go ahead and upgrade our Mailman instance, despite the repercussions for RFC 5321. Of course, we very much hope that RFCs for mail header manipulation will eventually align with the RFCs for DMARC. We promise to publish our implementation plan after discussion with the RIPE working group chairs.