You are here: Home > Publications > RIPE Labs > Adam Castle > RIPE Mailing Lists and DMARC

RIPE Mailing Lists and DMARC

Adam Castle — 18 Jul 2017
The RIPE community has existed for almost 30 years. In all that time, one of the chief missions of RIPE has been to provide a platform that allows network operators and others interested in networking to coordinate their activities and agree on best current practices. Therefore, since day one, it has been essential that we have in place functioning channels along which to carry out effective communication.

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 _at_ ripe _dot_ 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.

1 Comment

john jones says:
19 Jul, 2017 09:01 AM
while many have been confused its not really an issue...

simply put DMARC is effectively cryptographically signing emails hence if you change the email then the cryptographic signature has been broken.

If you are changing the email header and body then clearly the signatures are going to break, good email practice would be to identify where the email came from and to sign it then your domains reputation can be calculated, spam identified and problems reported in a structured way.

Clearly with no SPF and DMARC policy its going to be an issue...

I would advise using DANE to secure the TLS portion as well as implementing a SPF and DMARC policy !

https://tools.ietf.org/html/rfc7672
http://www.postfix.org/TLS_README.html#client_tls_secure

regards

John Jones
Add comment

You can add a comment by filling out the form below. Comments are moderated so they won't appear immediately. If you have a RIPE NCC Access account, we would like you to log in.