Categories
Dmarc as a Service Email Authentication

Email Authentication and Mailing Lists Haven’t Worked Well Together Until Now

DMARC and email lists: BFFs at last. Photo source: Pixabay

One of the most common technical concerns we hear about email authentication through DMARC is that it doesn’t work with mailing lists.

The objection has some merit. Email messages that get forwarded by a mailing list will fail SPF authentication, because, to the receiving mail server, the most immediate sender (the list) doesn’t match any of the domains listed in the originating domain’s SPF record.

Similarly, a DKIM signature attached to a message will fail if the mailing list modifies the body of the message or any of the signed headers (for instance, by rewriting the subject line of the message to add a prefix for the mailing list), because then the content of the message no longer matches the cryptographically signed hash of the original message.

And messages failing SPF and DKIM will also fail DMARC authentication.

The problem is not just hypothetical: Shortly after Yahoo rolled out DMARC enforcement in 2014, many mailing list operators found that every Yahoo address was bouncing — because the messages were failing DMARC authentication.

Fortunately, there is now a way to address these issues: With a new standard called Authenticated Received Chain, or ARC for short.

ARC conveys authentication results from hop to hop, allowing each server in a series of forwarders (such as a mailing list server) to authenticate an incoming message and then add its “endorsement” of that authentication to the forwarded message. The receiving server can choose to trust the message or not, and make a delivery decision, by examining the cumulative reputation of the senders who have signed the message at each hop in its journey to that point. It’s also possible to examine each of the authentication steps along the way to reconstruct the authentication chain.

ARC allows mailing lists to modify the messages they forward (by adding a list-specific prefix to the subject line, for instance) without fear that this will cause the messages to fail authentication when they arrive.

The ARC standard is in a nearly-final state, with two RFCs in progress with the IETF, awaiting what we believe will be only minor changes. (See the proposed RFC for the ARC Protocol, and a second one for recommended usage of ARC.) Meanwhile, several large providers of email services have already started getting ready to use ARC. Google, for instance, is already adding headers indicating ARC authentication status to the messages it receives in Gmail.

Valimail is contributing to the ARC standard and has also set up an ARC test suite that interested parties can use to validate their ARC implementations. We are also working with the makers of Mailman, one of the world’s largest software packages for managing mailing lists, to get it ARC-ready (meaning that a future release of the Mailman software will include the ability to add ARC signatures to messages).

In short, ARC is close to deployment-ready and momentum is building behind the standard. The standard is close to final and there’s a complete suite of ARC software just around the corner. Major email gateways should start looking for ARC patches to their existing software, or start checking ARC headers themselves and, when forwarding messages, adding ARC signatures.

For other mail senders and receivers, this is also good news, because it means that the mailing list problem is on the verge of being solved — removing the last major technical objection to using DMARC and setting it to enforcement.

If you want to learn more, visit http://arc-spec.org/.