 | This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Authenticated Received Chain" – news · newspapers · books · scholar · JSTOR (May 2024) (Learn how and when to remove this message) |
Authenticated Received Chain (ARC) is an email authentication system designed to allow an intermediate mail server like a mailing list or forwarding service to sign an email's original authentication results. This allows a receiving service to validate an email when the email's SPF and DKIM records are rendered invalid by an intermediate server's processing.
ARC is defined in RFC 8617, published in July 2019, as "Experimental".
Overview
DMARC allows a sender's domain to indicate that their emails are protected by SPF and/or DKIM, and tells a receiving service what to do if neither of those authentication methods passes - such as to reject the message. However, a strict DMARC policy may block legitimate emails sent through a mailing list or forwarder, as the DKIM signature will be invalidated if the message is modified, such as by adding a subject tag or footer, and the SPF check will either fail (if the forwarder didn't change the bounce address) or be aligned with the mailing list domain and not with the message author's domain (unless the mailing list rewrites the From: header field.)
ARC was devised to solve this problem by giving intermediate servers a way to sign the original message's validation results. Even if the SPF and DKIM validation fail, the receiving service can choose to validate the ARC chain. If it indicates that the original message passed the SPF and DKIM checks, and the only modifications were made by intermediaries trusted by the receiving service, the receiving service may choose to accept the email. Validating an ARC chain only makes sense if the receiver trusts the ARC signers. In fact, an ARC chain can be counterfeited, so ARC processing applies when receivers trust the good faith of ARC signers, but not so much their filtering practices.
Implementation
ARC defines three new mail headers:
- ARC-Authentication-Results (abbreviated AAR) - A combination of an instance number (i) and the results of the SPF, DKIM, and DMARC validation
- ARC-Seal (abbreviated AS) - A combination of an instance number (i), a DKIM-like signature of the previous ARC-Seal headers, and the validity of the prior ARC entries.
- ARC-Message-Signature (abbreviated AMS) - A combination of an instance number (i) and a DKIM-like signature of the entire message except for the ARC-Seal headers
To sign a modification, an intermediate server performs the following steps:
- Copies the Authentication-Results field into a new AAR field (starting with i=1) and prepends it to the message.
- Calculates the AMS for the message (with the AAR) and prepends it to the message.
- Calculates the AS for the previous Arc-Seal headers and prepends it to the message.
To validate an ARC, the recipient performs the following steps:
- Validates the chain of ARC-Seal headers (no missing entries, all ARC-Seal messages state that the prior ARC entries are valid, etc.)
- Validates the newest ARC-Message-Signature (based on the instance number)
References
- "Authenticated Received Chain Overview" (PDF). The Trusted Domain Project. 2016. Retrieved 2020-10-28.
- RFC 8617 - The Authenticated Received Chain (ARC) Protocol
- John Levine (14 June 2020). "why ARC". dmarc-ietf (Mailing list). Retrieved 13 October 2021.