ARC: Authenticated Received Chain

On Friday I talked a little about DMARC being a negative assertion rather than an authentication method, and also about how and when it could be deployed without causing problems. Today, how DMARC went wrong and a partial fix for it that is coming down the standards pipeline.
What breaks?

DMARC (with p=reject) risks causing problems any time mail with the protected domain in the From: field is either sent from a mailserver that is not under the control of the protected domain, or forwarded by a mailserver not under the control of the protected domain (and modified, however trivially, as it’s forwarded). “Problems” meaning the email is silently discarded.
This table summarizes some of the mail forwarding situations and what they break – but only from the original sender’s perspective. (If forwarding mail from a users mailbox on provider A to their mailbox on provider-Y breaks because of a DMARC policy on provider-A that’s the user’s problem, or maybe provider-A or provider-Y, but not the original sender’s.)

Use case	SPF	DKIM	DMARC
alias forwarding	❌	✔	✔
procmail forwarding	❌	?*	?
discussion mailing list	❌	❌	❌
recipient vanity domain forwarding	❌	✔	✔
recipient forwarding service (e.g. alumni domains)	❌	✔	✔
recipient forwarding e.g. yahoo to gmail	❌	✔*	✔
recipient mailbox forwarding via POP	✔	✔	✔
consumer email addresses using other mailbox providers	❌	❌	❌
consumer email addresses sending from ESPs	❌	❌	❌
consumer email addresses using, e.g. zendesk	❌	❌	❌

(* some situations may modify the body or headers of the message, breaking the DKIM signature and causing DMARC failures)
(If you’re diagnosing – or trying to avoid – DMARC issues it’s worth remembering that DKIM signatures can break, apparently randomly, due to issues with how the original email was constructed. If the mail wasn’t forwarded the SPF will be valid and you might not notice the broader DKIM issue.)
Where does it break?
The issues that break DMARC tend only to apply to “loosely controlled” domains – domains that don’t have full control over their mail streams, or which have humans who feel they own addresses in those domains and so want to use them outside the limits DMARC places on them. AOL, Yahoo and LinkedIn are some domains who’ve done that.
There’ve been some rather hacky workarounds for some specific situations. Some discussion mailing lists put a fake email address in the From header, rather than the original author (which prevents DMARC policy triggered bounces, but causes problems for others on the mailing list). AOL added C0nstant Contact, Sailthru and Zendesk to their SPF record.
DMARC doesn’t force receiving ISPs to take any particular action – it’s just advice. Some ISPs treat it naively and discard or reject any mail with a DMARC p=reject domain in the From: header that fails authentication.
Others take a more realistic approach and acknowledge that, for example, a mailing list server with a good reputation that’s emitting unauthenticated email from users at AOL or Yahoo is far more likely to be breaking authentication for legitimate email it’s forwarding than to be an evil phisher.
What can we mitigate?
It would be really nice to be able to say “I trust the forwarder that sent this to me, and I trust them when they tell me that the mail authenticated correctly when they received it” in a more mechanical manner than “I trust this long list of mailing list servers”.
That’s the plan behind Authenticated Received Chain (ARC).
Authenticated Received Chain
In much the same way that regular Received: headers record the series of mailservers that an email passes through as it’s delivered, ARC’s ARC-Seal: headers record the series of administrative domains a company passes through.
An administrative domain is, pretty much, a single company or single email system. While an email going through Microsoft might go through give different mailservers with each mailserver adding a new Received: header the same email would have just on ARC-Seal: header recording it entering the microsoft.com email system.
Other than that, they record where an email has gone, just like a Received: header. Unlike a Received: header, though, they’re cryptographically authenticated so that the organization adding the header can take responsibility for that email at that point in the delivery. If you think that sounds similar to the DKIM concept of taking responsibility for an email as it’s sent, you’re right. An ARC-Seal: header is like a simplified, stripped-down DKIM signature that signs just the ARC-related headers of the message.
Each ARC-Seal header can also have a couple of other ARC headers associated with it.
One is ARC-Message-Signature:. It’s pretty much the same as a DKIM-Signature: header, letting each hop of the delivery add a new DKIM-esque signature of the body of the message and the headers of the message as they send it on.
The other is ARC-Authentication-Results:. It contains the same information as an Authentication-Results: header added by that hop would – did SPF validation pass? was the DKIM signature valid? (and potentially all sorts of other authentication results, from authentication methods that are obsolete or are yet to be invented).
A recipient can step through the series of ARC-Seal: headers and as long as they trust each participant they have authenticated information about the content of the message and the authentication status of that message as it was received by that participant.
This lets an ISP – if they invest in the reputation tracking needed to make the “trust” decision about each participant – identify email that would have been validly authenticated if it hadn’t been through a forwarder or a mailing list and treat that mail as though it were validly authenticated, for making decisions about rejecting it due to DMARC policies.
Who does this affect?
If you’re a user at a domain that publishes DMARC p=reject then ARC has the potential for making your use of forwarders and mailing lists much, much more reliable.
If you’re a participant in discussion mailing lists then as long as the mailing list manager deploys ARC and your ISP is ARC aware you’re less likely to see messages vanish due to DMARC issues, and your mailing list manager will (hopefully) remove some of the gross workarounds they’ve previously put into place to mitigate those problems.
If you develop mailing list management software, or anything that forwards email, you should be reading the ARC specs and following the ARC mailing list and be thinking about how you’re going to implement this.
If you use mailing list software, you should check up on whether it’s implementing ARC. If they are, deploy it when you can. If they’re not, ask them to.
If you’re a mailbox provider you should probably find out more. ARC is something you’re going to want to plug in to your existing reputation based filters.
If you’re a typical ESP and you send email on behalf of your customers who provide the content to you via a web interface or an API and who want to send “From” their consumer email address then ARC is not going to help you. This is not the fix for “individuals and small businesses with consumer email addresses want to run mailing lists” you were looking for. Sorry.
Senders of all flavours. There’s nothing you need to change. As ARC is rolled out it will make some forms of authentication breakage less common, and that may affect your decisions as to whether or when to deploy DMARC reject or quarantine policies. If you’re using DMARC p=none with reporting today you might see those changes happening over then next year or so.
Status
AOL and Gmail are showing ARC results today.
Gmail is adding ARC headers to mail they send or forward.
There are interoperable implementations of the core algorithms in python, C, milter and perl. And a test suite.
Mailman and Sympa are actively adding support.
Want to know more?
ARC home page: arc-spec.org
ARC specification: draft-ietf-dmarc-arc-protocol-03
Recommended usage: draft-ietf-dmarc-arc-usage-01
Mailing list: subscribe or read the archives