As we mentioned in the first post of this series, with the arrival of ARC, one of the biggest blockers to DMARC adoption up to now has been the inability to use it with mailing lists or forwarders. This limitation existed because messages delivered through 3rd party handlers would not pass DKIM or SPF (or both). This meant that in the past one either didn’t enforce DMARC or suffered the consequences of a certain level of undeliverable email.
The latest development in the DMARC story is the creation of Authenticated Received Chain (ARC) specification. This new protocol allows a series of message handlers to conduct authentication of a message and record this status as it passes among them, allowing the final recipient to make effective choices about the disposition of the message. This means organizations can now enforce DMARC, knowing that the intermediaries can pass their message along safely without failing DMARC.
How Does ARC Work?
Let’s consider an example of a mailing list forwarding from a sender that has published a DMARC policy. SPF will typically not pass in this case since the mailing list server is now seen as the sending source and your domain does not authorize that source. DKIM will also break in this example because the message body has been altered, causing the message to no longer match the DKIM digital signature.
With ARC specification implemented, however, an entry is recorded in the ARC-Authentication Results header and this is passed along. As the original SPF result is conveyed, the receiver then sees what the SPF entry was before the mailing list hop modified it. Also, an ARC-Message-Signature header field is created which includes a cryptographic signature of the message itself and this enables DKIM to pass.
Who Benefits?
The general answer to this question is everyone. It helps companies become more secure in two ways. First it provides an authentication chain for all cases of email forwarding and second, it helps drive adoption which is good for all parties. More specifically, smaller companies without large cloud email providers previously had no solution to email security when mailing lists were being used. Now with ARC these smaller organizations can reach their audience through practical methods without giving up the security benefits of DMARC.
This also helps the broader ecosystem in another way. Those companies that rely on DMARC for their services (and Agari is one of them) now have a more robust fabric on which to deliver this service.
What do Intermediaries Need to Do?
For intermediaries there are actions needed to enable ARC. First, a participating intermediary must validate the ARC chain on a message it receives (if one is present). Next it must attach its own ARC seal and signature; and provide an indication if the chain failed to validate.
ARC is designed to operate at the Administrative Management Domain (ADMD) level. When a message is received by an ADMD, the traditional authentication results should be captured. However, when it is determined that the message is being sent beyond that domain, this is when the ADMD should add itself to the ARC chain.
How Does this Affect Secure Email Gateways?
SEGs are free to make use of the ARC data or ignore it. The primary use case for ARC is when a message fails DMARC. So, based on this, the flow looks as follows:
- The SEG applies DMARC (which includes SPF and DKIM) and determines the message is a DMARC fail and the domain has a p=reject policy.
- The SEG notices the ARC header set and determines if it should reject the message or perform a local override of the policy based on the ARC data.
- The SEG then traverses the ARC chain assessing, at each hop, if it trusts the intermediary. It doesn’t have to trust the content but needs to trust that the intermediary isn’t going to forge prior links in the ARC chain. If any link isn’t trusted, it rejects the message (as DMARC did); if all links are trusted then the ARC results are presumed correct and DMARC is overridden; and the message is delivered.
(As a side note, Agari honors ARC both in our solution that is layered on top of an SEG as well as for advanced attack analytics.)
What ARC Can (and Can’t) Do
While ARC is a huge step in the right direction, there will never be a substitute for assessing the trust of the sender or intermediary. If an intermediary is willing to update the ARC chain, the next question becomes “do I trust this intermediary?” The ability to answer this question requires ARC implementations to maintain a DB or model for intermediary trust.
Adoption to Date
Even though the ARC spec is still in draft mode, Google has adopted it, and it is in the process of being rolled out at AOL and Verizon. The preliminary OpenARC code base was just published (version 0.1.0) recently, and the finalized spec (version 1.0) is likely to be published in the next month. Other ISPs and popular mailing list software packages like Mailman are in the process of adopting, and we estimate that adoption should increase as the draft stabilizes. Google has been very active in pushing for ARC. Unlike Yahoo and Hotmail who both published DMARC reject policies, Google has been hesitant to risk breaking mailing lists and appears to be under the presumption that ARC fixes DMARC for this application.
The DMARC Suite
In short, DMARC is a powerful tool and provides immense value to organizations who implement it—to the point of “enforcement”. Now with ARC included, it is stronger with fewer impediments to adoption.
There are a number of resources available for more details on ARC. The ARC RFP itself can be found on the IETF page here. Additional context on ARC usage can be found on the Propublica page here. In our next, and final blog entry on this topic we will cover the latest DKIM update called DCRUP.