The Authenticated Received Chain (ARC) Protocol
The Authenticated Received Chain (ARC) protocol provides an authenticated "chain of custody" for a message, allowing each entity that handles the message to see what entities handled it before and what the message's authentication assessment was at each step in the handling. ARC allows Internet Mail Handlers to attach assertions of message authentication assessment to individual messages. As messages traverse ARC-enabled Internet Mail Handlers, additional ARC assertions can be attached to messages to form ordered s
Experimental, not a standard. Published to be tried rather than relied on. Implementations may legitimately disagree.
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 14 must, 4 should, 6 may.
4.1.1 ARC-Authentication-Results (AAR)
- MUSTBecause there is only one AAR allowed per ARC Set, the AAR MUST contain the combined authres-payload with all of the authentication results from within the participating ADMD, regardless of how many Authentication-Results header fields are attached to the message.
4.1.2 ARC-Message-Signature (AMS)
- MUSTAs required for undefined tags (in [RFC6376]), if seen, a version tag MUST be ignored; and
- SHOULDAMS header fields SHOULD be attached so that any modifications made by the ADMD are included in the signature of the AMS header field.
- MUST NOTo Authentication-Results header fields MUST NOT be included in AMS signatures as they are likely to be deleted by downstream ADMDs (per [RFC8601], Section 5).
- MUST NOTo ARC-related header fields (ARC-Authentication-Results, ARC- Message-Signature, and ARC-Seal) MUST NOT be included in the list of header fields covered by the signature of the AMS header field.
- SHOULDTo preserve the ability to verify the integrity of a message, the signature of the AMS header field SHOULD include any DKIM-Signature header fields already present in the message.
4.1.3 ARC-Seal (AS)
- MUSTNote especially that the DKIM "h" tag is NOT allowed and, if found, MUST result in a cv status of "fail" (for more information, see Section 5.1.1); and
4.2.1 Instance Tags
- MUSTValid ARC Sets MUST have exactly one instance of each ARC header field (AAR, AMS, and AS) for a given instance value and signing algorithm.
5 Protocol Actions
- MAYWith this information, Internet Mail Handlers MAY inform local policy decisions regarding disposition of messages that experience authentication failure due to intermediate processing.
5.1 Sealer Actions
- MUSTAll message modifications (including adding a DKIM-Signature header field(s)) MUST be performed before sealing.
5.1.2 Marking and Sealing "cv=fail" (Invalid) Chains
- MUSTIn the case of a failed Authenticated Received Chain, the header fields included in the signature scope of the AS header field b= value MUST only include the ARC Set header fields created by the MTA that detected the malformed chain, as if this newest ARC Set was the only set present.
5.1.4 Broad Ability to Seal
- MAYAny Internet Mail Handler MAY seal a message by adding a complete ARC Set, whether or not they have modified or are aware of having modified the message.
5.2 Validator Actions
- MUSTEach ARC Set MUST contain exactly one each of the three ARC header fields (AAR, AMS, and AS).
- MUSTThe instance values of the ARC Sets MUST form a continuous sequence from 1..N with no gaps or repetition.
- MUST NOTThe "cv" value for all ARC-Seal header fields MUST NOT be "fail".
- MUSTFor ARC Sets with instance values > 1, the values MUST be "pass".
- MUSTFor the ARC Set with instance value = 1, the value MUST be "none".
- SHOULDThe end result of this validation algorithm SHOULD be included within the Authentication-Results header field for the ADMD.
- MUSTAs with a DKIM signature ([RFC6376], Section 6.3) that fails verification, a message with an Authenticated Received Chain with a Chain Validation Status of "fail" MUST be treated the same as a message with no Authenticated Received Chain.
5.2.2 Responding to ARC Validation Failures during the SMTP
- MAYIf an ARC Validator determines that the incoming message fails ARC validation, the Validator MAY signal the breakage through the extended SMTP response code 5.7.29 ("ARC validation failure") and the corresponding SMTP basic response code.
- MAYBecause ARC failures are likely only to be detected in the context of other underlying authentication mechanism failures, Validators MAY use the more general 5.7.26 ("Multiple authentication checks failed") instead of the ARC-specific code.
6 Communication of Validation Results
- SHOULDIf necessary data is available, the ptypes and properties defined in Section 10.2 SHOULD be recorded in an Authentication-Results header field:
7.2.1 DMARC Local Policy Overrides
- MAYAs a matter of local policy, a DMARC processor MAY choose to accept the authentication assessments provided by an Authenticated Received Chain when determining if a message is DMARC compliant.
7.2.2 DMARC Reporting
- MAYWhen an ARC-enabled handler generates a DMARC report, it MAY indicate the influence of ARC on their local policy decision(s) by adding a reason of "local_policy" with a comment string (per [RFC7489], Appendix C) containing a list of data discovered during ARC validation, which at a minimum includes: