DMARC is an anti-phishing technique that AOL and Yahoo repurposed last year to help them deal with the consequences of spam to (and apparently from) addresses in stolen address books. Since DMARC cannot tell mail sent through complex paths like mailing lists from phishes, this had the unfortunate side effect of screwing up nearly every discussion list on the planet.

Last week the DMARC group published a proposal called ARC, for Authenticated Received Chain, that is intended to mitigate the damage. What is it, and how likely is it to work?

When the DMARC list problems started last year, a frequently proposed workaround was for receivers to whitelist mail from known lists. Large mail providers already have a pretty good idea of where the lists are, so this would be relatively simple to do. Smaller systems might combine their data into shared whitelists. But this whitelisting didn’t happen, for reasons discussed below.

Mailing list messages typically take one of these paths:

sender.com → list.org → recipient
sender.com → list.org → forwarder.edu → recipient

The list is a mailing list run by something like Mailman or Sympa. When there’s an extra forwarder, that’s generally a permanent address provided by an alumni association or professional society. (For example, I’m uucp@computer.org.)

The sender adds a DKIM signature which the list can verify. Then the list does what lists do, such as adding subject tags or message footers, adds its own DKIM signature, and sends it along. At this point, the original DKIM signature is often no longer valid due to the message changes, but the list’s signature is valid. If there’s another forwarder, it adds its own signature and may or may not make changes that invalidate the list’s signature.

The original plan with DKIM was that the recipient would look at the signatures, see that the list’s signature was valid, look in its reputation database and see that the list sends generally desirable mail, and deliver the message.

People at large mail systems told me that it’s surprisingly common for a mailing list to send nice clean mail for a while, then start spewing spam when a subscriber is compromised, or bad guys pretend to be a subscriber. ARC helps deal with this last situation.

ARC adds more DKIM-like signatures that give the recipient an idea of where the message actually came from. Before ARC, the DKIM signatures on the message would be something like this:

DKIM-Signature: ... d=list.org ...
... other stuff ...
DKIM-Signature: ... d=sender.com ...
From: [email protected]
... rest of the message ...

Each signature is added at the top of the message so they appear from most to least recently added.

But by the time the message arrives at the recipient, the d=sender signature is no longer good, and the recipient can’t tell whether it was good when it arrived at the list. ARC is intended to fix that:

ARC-Seal: i=1; d=list.org; ...
ARC-Message-Signature: ... d=list.org ...
ARC-Authentication-Results: list.org; dkim=pass [email protected]; dmarc=pass
DKIM-Signature: ... d=list.org ...
... other stuff ...
DKIM-Signature: ... d=sender.com ...
From: [email protected]
... rest of the message ...

The ARC-Seal is a simplified DKIM signature that signs the ARC-Message-Signature and the ARC-Authentication-Results, so the recipient can see they’re all good (or bad) as a group. If the message went through multiple forwarders, each one adds its own ARC- header group with ARC-Seals with i=2, i=3, and so forth. Since nothing should change the ARC- headers, all of the ARC-Seal signature should be valid when the message is finally received, and reading from the top of the message the i= numbers in the seals should be in reverse order down to i=1 for the oldest one. (If not, the message is probably not what it purports to be.)

The ARC-Message-Signature is a modified DKIM signature that covers a fixed set of headers (Message-ID, Date, From, To, Subject) and the message body. The most recent ARC-Message-Signature should be valid, previous ones may or may not be if forwarders have changed the message.

The ARC-Authentication-Results header is a copy of the standard Authentication-Results header (see RFC 5451) which among other things says which DKIM signatures were valid and whether the message passed DMARC validation. Again, if the message is forwarded several times, there will be several of these.

So when a recipient gets a message from a mailing list or other forwarder, and sees ARC-Seal and ARC-Message-Signature headers with valid signatures, it can make some reasonable assumptions. The ARC-Authentication-Results header shows whether the message originally passed DMARC validation. If it did, and the list has a good reputation, it’s likely a real message from the putative sender, and it’s safe to skip recipient DMARC checks. If the original message didn’t pass DMARC, and its domain asserts a DMARC policy of quarantine or reject, it’s more likely that the incoming message was a fake and so the recipient system might reject it or put it in the spam folder.

If a message has multiple groups of ARC- signatures the recipient can check that the ARC-Seals are all valid, and look at the seals and ARC-Authentication-Results to see whether the message originally passed DMARC.

A malicious forwarder could of course put in fake authentication results, so ARC is only useful for forwarders with good reputations. This puts us more or less back where we started, whitelisting mail from known lists, but with a tweak that gives recipients a better idea whether the original message actually came from its putative source.

This is intended to plug the hole in which lists pass along mail from bad guys faking list member addresses. People at large mail systems have told me this should let them deliver list mail despite DMARC problems. I certainly hope so, and will report back as we find out.