RFC 8617

The Authenticated Received Chain (ARC) Protocol

📅 published July 2019, from ietf

The Authenticated Received Chain (ARC) Protocol 🎀

Part 1 of 6, bestie! 🦋 This is RFC 8617, published in July 2019 by the IETF. It's an Experimental document (not a Standards Track one), and it's ISSN 2070-1721. The authors are K. Andersen (LinkedIn), B. Long, Ed. (Google), S. Blank, Ed. (Valimail), and M. Kucherawy, Ed. (TDP). The title block doesn't list anything it obsoletes or updates, so it stands on its own. 💅

Abstract ✨

ARC gives a message a verifiable "chain of custody" 🔗 Every handler that touches the message can see who handled it before and what the authentication assessment was at each step along the way. It's giving accountability, no cap.

ARC lets Internet Mail Handlers attach assertions of message authentication assessment to individual messages. As a message moves through ARC-enabled handlers, more ARC assertions get attached, building ordered sets that record the authentication assessment at each step of the path the message took.

ARC-enabled Internet Mail Handlers can look at those sets to help make message disposition decisions 📬, spot handlers that might break existing authentication mechanisms 👀, and pass original authentication assessments across trust boundaries 🛡️. Literally so useful.

Status of This Memo 📝

This document isn't an Internet Standards Track specification. It's published so people can examine it, try it out experimentally, and evaluate it. 🧪

It defines an Experimental Protocol for the Internet community. It's a product of the Internet Engineering Task Force (IETF) and reflects the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you're curious about that. 🤓

For info on the current status of this document, any errata, and how to send feedback, check https://www.rfc-editor.org/info/rfc8617. 💌

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components extracted from this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License. 📜

Table of Contents 🗂️

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  General Concepts  . . . . . . . . . . . . . . . . . . . . . .   5
     2.1.  Evidence  . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.2.  Custody . . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.3.  Chain of Custody  . . . . . . . . . . . . . . . . . . . .   6
     2.4.  Validation of Chain of Custody  . . . . . . . . . . . . .   6
   3.  Terminology and Definitions . . . . . . . . . . . . . . . . .   6
     3.1.  ARC Set . . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.2.  Authenticated Received Chain (ARC)  . . . . . . . . . . .   7
     3.3.  Internet Mail Handlers / Intermediaries . . . . . . . . .   7
     3.4.  Authentication Assessment . . . . . . . . . . . . . . . .   7
     3.5.  Signing vs. Sealing . . . . . . . . . . . . . . . . . . .   8
     3.6.  Sealer  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     3.7.  Validator . . . . . . . . . . . . . . . . . . . . . . . .   8
     3.8.  Imported ABNF Tokens  . . . . . . . . . . . . . . . . . .   8
     3.9.  Common ABNF Tokens  . . . . . . . . . . . . . . . . . . .   8
   4.  Protocol Elements . . . . . . . . . . . . . . . . . . . . . .   9
     4.1.  ARC Header Fields . . . . . . . . . . . . . . . . . . . .   9
       4.1.1.  ARC-Authentication-Results (AAR)  . . . . . . . . . .   9
       4.1.2.  ARC-Message-Signature (AMS) . . . . . . . . . . . . .   9
       4.1.3.  ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . .  11
       4.1.4.  Internationalized Email (EAI) . . . . . . . . . . . .  12
     4.2.  ARC Set . . . . . . . . . . . . . . . . . . . . . . . . .  12
       4.2.1.  Instance Tags . . . . . . . . . . . . . . . . . . . .  12
     4.3.  Authenticated Received Chain  . . . . . . . . . . . . . .  13
     4.4.  Chain Validation Status . . . . . . . . . . . . . . . . .  13
   5.  Protocol Actions  . . . . . . . . . . . . . . . . . . . . . .  14
     5.1.  Sealer Actions  . . . . . . . . . . . . . . . . . . . . .  14
       5.1.1.  Header Fields to Include in ARC-Seal Signatures . . .  15
       5.1.2.  Marking and Sealing "cv=fail" (Invalid) Chains  . . .  15
       5.1.3.  Only One Authenticated Received Chain per Message . .  16
       5.1.4.  Broad Ability to Seal . . . . . . . . . . . . . . . .  16
       5.1.5.  Sealing Is Always Safe  . . . . . . . . . . . . . . .  16
     5.2.  Validator Actions . . . . . . . . . . . . . . . . . . . .  17
       5.2.1.  All Failures Are Permanent  . . . . . . . . . . . . .  18
       5.2.2.  Responding to ARC Validation Failures during the SMTP
               Transaction . . . . . . . . . . . . . . . . . . . . .  19
   6.  Communication of Validation Results . . . . . . . . . . . . .  19
   7.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .  19
     7.1.  Communicate Authentication Assessment across Trust
           Boundaries  . . . . . . . . . . . . . . . . . . . . . . .  19
       7.1.1.  Message-Scanning Services . . . . . . . . . . . . . .  20
       7.1.2.  Multi-tier MTA Processing . . . . . . . . . . . . . .  20
       7.1.3.  Mailing Lists . . . . . . . . . . . . . . . . . . . .  20
     7.2.  Inform Message Disposition Decisions  . . . . . . . . . .  21
       7.2.1.  DMARC Local Policy Overrides  . . . . . . . . . . . .  21
       7.2.2.  DMARC Reporting . . . . . . . . . . . . . . . . . . .  22
   8.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  22
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  23
     9.1.  Increased Header Field Size . . . . . . . . . . . . . . .  23
     9.2.  DNS Operations  . . . . . . . . . . . . . . . . . . . . .  23
     9.3.  Message Content Suspicion . . . . . . . . . . . . . . . .  24
     9.4.  Message Sealer Suspicion  . . . . . . . . . . . . . . . .  24
     9.5.  Replay Attacks  . . . . . . . . . . . . . . . . . . . . .  24
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  25
     10.1.  Update to Email Authentication Result Names Registry . .  25
     10.2.  Update to Email Authentication Methods Registry  . . . .  25
     10.3.  New Header Fields in Permanent Message Header Field
            Registry . . . . . . . . . . . . . . . . . . . . . . . .  26
     10.4.  New Status Code in Enumerated Status Codes Registry  . .  26
   11. Experimental Considerations . . . . . . . . . . . . . . . . .  27
     11.1.  Success Consideration  . . . . . . . . . . . . . . . . .  27
     11.2.  Failure Considerations . . . . . . . . . . . . . . . . .  27
     11.3.  Open Questions . . . . . . . . . . . . . . . . . . . . .  27
       11.3.1.  Value of the ARC-Seal (AS) Header Field  . . . . . .  27
       11.3.2.  Usage and/or Signals from Multiple Selectors and/or
                Domains in ARC Sets  . . . . . . . . . . . . . . . .  28
       11.3.3.  DNS Overhead . . . . . . . . . . . . . . . . . . . .  28
       11.3.4.  What Trace Information Is Valuable?  . . . . . . . .  28
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  29
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  29
     12.2.  Informative References . . . . . . . . . . . . . . . . .  30
   Appendix A.  Design Requirements  . . . . . . . . . . . . . . . .  32
     A.1.  Primary Design Criteria . . . . . . . . . . . . . . . . .  32
     A.2.  Out of Scope  . . . . . . . . . . . . . . . . . . . . . .  32
   Appendix B.  Example Usage  . . . . . . . . . . . . . . . . . . .  32
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  35
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  35

1. Introduction 🌸

Okay so, email authentication is a big deal 💖 Tools like Sender Policy Framework (SPF) [RFC7208] and DomainKeys Identified Mail (DKIM) [RFC6376] are only as good as what happens to mail on its way through the internet. Intermediate handlers process Internet Mail along the way, and that processing can mess with those checks. This is written up in detail in the defining documents for SPF and DKIM, and it gets more discussion in [RFC6377] and [RFC7960]. 🧐

Domain-based Message Authentication, Reporting, and Conformance (DMARC) [RFC7489] leans on SPF and DKIM too, so when intermediate handlers cause authentication failures, legit mail can get wrongly rejected or sent to the wrong place. Not it. 😭

So ARC gives each individual Internet Mail Handler a way to add its own authentication assessment to the message's ordered set of handling results. ARC wraps that assessment in a DKIM signature derivative 🎁 This means other handlers can verify that each individual assessment is authentic, and they can also verify the whole set and the order it came in. Super iconic. ✨

Ordered sets of authentication assessments can help ARC-enabled Internet Mail Handlers make message-handling decisions 🧠 They can also reveal where message content might have been altered, and they add trace information that's useful for understanding how a message got routed. 🗺️

2. General Concepts 🦋

ARC is loosely based on ideas from evidence collection 🔍 In that world, evidence is usually collected, labeled, stored, and transported in specific ways. That keeps the evidence intact and documents every processing step. Very forensic, very organized, very slay.

2.1. Evidence 🔎

For ARC, the "evidence" is a message's authentication assessment at any point between origination and final delivery. Intermediate handlers can change the outcome of message authentication when they modify message content (header fields and/or body content), send messages through paths nobody planned for, or change envelope information. Plot twist, right? 🙈

The authentication assessment for a message is figured out when the message is received, and it gets recorded in the Authentication-Results header field(s). ARC extends that system so the assessment can survive a trip through intermediary Administrative Management Domains (ADMDs). 🚀

Here's the tea: a first-hand authentication assessment can never be reproduced by other handlers. So an assertion of that assessment is more like testimony from a verifiable witness than hard evidence that anyone can independently re-check. It's the difference between "trust me, I saw it" and "here's the receipt." 🧾

2.2. Custody 🫶

"Custody" is the moment an Internet Mail Handler processes a message. When a handler takes custody, it becomes a custodian, and if it's ARC enabled, it attaches its own evidence (its authentication assessment upon receipt) to the message. The evidence gets added in a way that lets future handlers verify both the evidence itself and the custody that goes with it. Chain of custody energy, bestie. 🔗💅

2.3. Chain of Custody 🔗✨

Okay bestie, the "chain of custody" of ARC is basically the whole collection of evidence and custody that travels along with a message 🎀. All of it, together, as one bundle.

2.4. Validation of Chain of Custody 💅

Any ARC-enabled Internet Mail Handler can check the entire set of custody and the authentication assessments that each party asserted, and from that it gets a valid chain of custody 👑. So, if the evidence-supplying custodians can be trusted, the validated chain tells the story of the (possibly changing) authentication assessment as the message moved through the different custodians 🦋.

Even though a message's authentication assessment might have changed, the validated chain of custody can be used to figure out whether those changes, and the custodians responsible for them, are tolerable 🫶. Main character energy for the receipts! 🧾

3. Terminology and Definitions 📖

This section defines the terms used in the rest of the document 🌸.

Readers should be familiar with the contents, core concepts, and definitions found in [RFC5598]. The potential roles of transit services in the delivery of email are directly relevant, so don't skip that part 👀.

Language, syntax (including some ABNF constructs), and concepts are imported from DKIM [RFC6376]. Specific references to DKIM are made throughout this document. The following terms are imported from [RFC5598]:

  • Administrative Management Domain (ADMD), Section 2.3
  • Message Transfer Agent (MTA), Section 4.3.2
  • Message Submission Agent (MSA), Section 4.3.1
  • Message Delivery Agent (MDA), Section 4.3.3

Syntax descriptions use ABNF [RFC5234] [RFC7405].

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 🙈

3.1. ARC Set 🧁

Section 4.1 introduces three (3) ARC header fields that get added to a message by an ARC-enabled Internet Mail Handler. Together, those three header fields make up a single "ARC Set" 💖. An ARC Set gives an Internet Mail Handler a way to attach an authentication assessment to a message, in a manner that future handlers can verify. A single message can contain multiple ARC Sets, so it's giving stacked 📚.

In general concept terms, an ARC Set represents Evidence and Custody.

3.2. Authenticated Received Chain (ARC) 🪢

The sequence of ARC Sets attached to a message at a given time is called the "Authenticated Received Chain" or "ARC". An Authenticated Received Chain is the record of individual authentication assessments as a message traverses ARC-participating ADMDs 🚶‍♀️.

The first attachment of an ARC Set to a message causes an Authenticated Received Chain to be created. Additional attachments of ARC Sets cause the Authenticated Received Chain to be extended ✨.

In general concept terms, an Authenticated Received Chain represents a chain of custody.

3.3. Internet Mail Handlers / Intermediaries 📬

Internet Mail Handlers process and deliver messages across the Internet, and they include MSAs, MTAs, MDAs, gateways, and mailing lists as defined in [RFC5598] 🛵.

Throughout this document, the term "intermediaries" refers to both regular MTAs and delivery/reposting agents such as mailing lists, which are covered within the scope of transit services per [RFC5598] 🌈.

"Intermediaries" and "Internet Mail Handlers" are used synonymously throughout this document. Same energy, different name tags 🏷️.

3.4. Authentication Assessment 🕵️‍♀️

The authentication assessment that is affixed to a message as part of each ARC Set consists of the "authres-payload" [RFC8601]. For the integrity of an ARC Set, the authentication assessment only needs to be properly encapsulated within the ARC Set as defined in Section 4.1. The accuracy or syntax of the authres-payload field does not affect the validity of the ARC Chain itself. So the ARC Chain stays valid even if the payload text is a little messy 🙃.

3.5. Signing vs. Sealing ✍️

Signing is the process of affixing a digital signature to a message as a header field, such as when a DKIM-Signature (as in [RFC6376], Section 2.1), an AMS, or an AS is added 🖋️. Sealing is when an ADMD affixes a complete and valid ARC Set to a message to create or continue an Authenticated Received Chain 🔏.

3.6. Sealer 🦭

A Sealer is an Internet Mail Handler that attaches a complete and valid ARC Set to a message 💌.

In general concept terms, a Sealer adds its testimony (assertion of authentication assessment) and proof of custody to the chain of custody.

3.7. Validator 🔍

A Validator is an ARC-enabled Internet Mail Handler that evaluates an Authenticated Received Chain for validity and content. The process of evaluating the individual ARC Sets that make up an Authenticated Received Chain is described in Section 5.2 🧐.

In general concept terms, a Validator inspects the chain of custody to determine the content and validity of the individual evidence supplied by custodians.

3.8. Imported ABNF Tokens 📦

The following ABNF tokens are imported:

  • tag-list ([RFC6376], Section 3.2)
  • authres-payload ([RFC8601], Section 2.2)
  • CFWS ([RFC5322], Section 3.2.2)

3.9. Common ABNF Tokens 🧩

The following ABNF tokens are used elsewhere in this document:

position     = 1*2DIGIT                         ; 1 - 50
instance     = [CFWS] %s"i" [CFWS] "="
               [CFWS] position
chain-status = ("none" / "fail" / "pass")
seal-cv-tag  = %s"cv" [CFWS] "="
               [CFWS] chain-status

4. Protocol Elements 🎀

4.1. ARC Header Fields 💌

ARC introduces three new header fields. The syntax for these new header fields adapts existing specifications 🪄. This document only describes where ARC-specific changes in syntax and semantics differ from existing specifications, so you only need to read the differences 🤓.

4.1.1. ARC-Authentication-Results (AAR) 📝

The ARC-Authentication-Results (AAR) header field records the message authentication assessment as processed by an ARC-participating ADMD at message arrival time ⏰.

In general concept terms, the AAR header field is where evidence is recorded by a custodian.

The AAR header field is similar in syntax and semantics to an Authentication-Results field [RFC8601], with two (2) differences:

  • the name of the header field itself, and
  • the presence of the instance tag. Additional information on the instance tag can be found in Section 4.2.1.

The formal ABNF for the AAR header field is:

arc-info = instance [CFWS] ";" authres-payload
arc-authres-header = "ARC-Authentication-Results:" [CFWS] arc-info

Because 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) 🖊️

The ARC-Message-Signature (AMS) header field lets an ARC-participating ADMD pass some responsibility (custodianship) for a message, along with any possible message modifications, on to future ARC-participating custodians 🤝.

In general concept terms, the AMS header field identifies a custodian.

The AMS header field has the same syntax and semantics as the DKIM-Signature field [RFC6376], with three (3) differences:

  • the name of the header field itself;
  • no version tag ("v") is defined for the AMS header field. As required for undefined tags (in [RFC6376]), if seen, a version tag MUST be ignored; and
  • the "i" (Agent or User Identifier (AUID)) tag is not imported from DKIM. Instead, this tag is replaced by the instance tag as defined in Section 4.2.1.

ARC places no requirements on the selectors and/or domains used for the AMS header field signatures 🗝️.

The formal ABNF for the AMS header field is:

arc-ams-info = instance [CFWS] ";" tag-list
arc-message-signature = "ARC-Message-Signature:" [CFWS] arc-ams-info

To reduce the chances of accidental invalidation of AMS signatures:

  • AMS header fields are added by ARC-participating ADMDs as messages exit the ADMD. AMS header fields SHOULD be attached so that any modifications made by the ADMD are included in the signature of the AMS header field.
  • 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). 🗑️
  • 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.

To 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) 🦭🔏

The AS header field permits ARC-participating ADMDs to verify the integrity of AAR header fields and corresponding AMS header fields 🛡️.

In general concept terms, the AS header field is how custodians bind their authentication assessments (testimonials) into a chain of custody, so that Validators can inspect individual evidence and custodians 🕊️.

The AS header field is similar in syntax and semantics to DKIM-Signature header fields [RFC6376], with the following differences:

  • the "i" (AUID) tag is not imported from DKIM. Instead, this tag is replaced by the instance tag as defined in Section 4.2.1;
  • the signature of the AS header field does not cover the body of the message; therefore, there is no "bh" tag. The signature of the AS header field only covers specific header fields as defined in Section 5.1.1;
  • no body canonicalization is performed, as the AS signature does not cover the body of a message;
  • only "relaxed" header field canonicalization ([RFC6376], Section 3.4.2) is used;
  • the only supported tags are "i" (from Section 4.2.1 of this document), and "a", "b", "d", "s", and "t" from [RFC6376], Section 3.5. Note 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
  • an additional tag, "cv" ("seal-cv-tag" in the ARC-Seal ABNF definition), is used to communicate the Chain Validation Status to subsequent ADMDs 📣.

ARC places no requirements on the selectors and/or domains used for the AS header field signatures 🌷.

The formal ABNF for the AS header field is:

arc-as-info = instance [CFWS] ";" tag-list
arc-seal = "ARC-Seal:" [CFWS] arc-as-info

4.1.4. Internationalized Email (EAI) 🌍

In internationalized messages [RFC6532], many header fields can contain UTF-8 as well as ASCII text. The changes for EAI are all inherited from DKIM as updated by [RFC8616] and from Authentication-Results (A-R) as updated in [RFC8601], but they're called out here for emphasis 📢.

In all ARC header fields, the d= and s= tags can contain U-labels. In all tags, non-ASCII characters need not be quoted in dkim-quoted-printable 🈴.

The AAR header allows UTF-8 in the same places that Authentication-Results does, as described in [RFC8601] 💬.

4.2. ARC Set 🎁

An "ARC Set" is a single collection of three ARC header fields (AAR, AMS, and AS). The ARC header fields of an ARC Set share the same "instance" value, so they all stay matched up 💕.

By adding all of the ARC header fields to a message, an ARC Sealer adds an ARC Set to that message. A description of how Sealers add an ARC Set to a message is found in Section 5.1 🌟.

4.2.1. Instance Tags ✨

okay so instance tags are how ARC figures out which ARC header fields belong together 🫶 Every ARC header field in an ARC Set shares the same instance tag value, no cap.

Instance tag values are integers that start at 1 and go up by one every time another ARC Set gets added 🔢 So a Validator can totally tell what order the ARC Sets were added to a message just by reading the numbers. Main character sorting energy 💅

Instance tag values can range from 1-50 (inclusive) 🌈

_INFORMATIONAL_: The upper limit of 50 was picked based on some early observations shared by early working group members 🧚 It's a balance between the risk of header fields getting too big (see Section 9.1) and expert opinion on how likely long, but non-looping, multi-intermediary mail flows are. Longer ARC Chains also put more load on Validators and DNS, since they need extra verification steps. The number of "Received" header fields observed in practice was considered too, so 50 is an experimental starting value 🌸

Valid ARC Sets MUST have exactly one instance of each ARC header field (AAR, AMS, and AS) for a given instance value and signing algorithm 🎀

For handling multiple signing algorithms, see [ARC-MULTI] 🦋

4.3. Authenticated Received Chain 🔗

An Authenticated Received Chain is an ordered collection of ARC Sets 📚 Since ARC Sets are enumerated sets of ARC header fields, an Authenticated Received Chain shows the results of message authentication checks along the handling path of ARC-enabled processors. It's giving receipts 🧾

The authentication assessments made at each step of the ARC-enabled handling path show up in an Authenticated Received Chain as AAR header fields 💌 The ability to verify who the message handlers are, and whether the message content is intact, comes from AMS header fields 🔐 And AS header fields let message handlers check the assertions, the order, and the sequence of the Authenticated Received Chain itself 🫠

In general terms, an Authenticated Received Chain is a message's chain of custody 🕵️‍♀️ Validators can look at it to learn about each custodian of a message and the evidence each one collected. Iconic detective work 🍓

4.4. Chain Validation Status 🚦

The state of the Authenticated Received Chain at a specific processing step is called the "Chain Validation Status" 💜 Chain Validation Status gets communicated in a couple of ways:

  • as the AS header field in the cv tag and
  • as part of the Authentication-Results and AAR header field(s).

Chain Validation Status has one of three possible values:

  • none: There was no Authenticated Received Chain on the message when it arrived for validation. This usually happens when a message comes straight from the original Message Transfer Agent (MTA) or Message Submission Agent (MSA), or from an upstream Internet Mail Handler that isn't participating in ARC handling 📭
  • fail: The message has an Authenticated Received Chain, and its validation failed 💀
  • pass: The message has an Authenticated Received Chain, and its validation succeeded ✅

5. Protocol Actions 👑

ARC-enabled Internet Mail Handlers generally act as both ARC Validators (when receiving messages) and ARC Sealers (when sending messages onward, not originated locally) 🔁 Double duty, iconic 💅

An Authenticated Received Chain with a Chain Validation Status of "pass" (or "none") lets Internet Mail Handlers figure out:

  • all ARC-participating ADMDs that claim responsibility for handling (and possibly modifying) the message in transit, and
  • the authentication assessments of the message as determined by each ADMD (from AAR header fields) 📋

With this info, Internet Mail Handlers MAY inform local policy decisions about what to do with messages that hit authentication failure because of intermediate processing 🫶

5.1. Sealer Actions 🦭

To "seal" a message, an ARC Sealer adds an ARC Set (the three ARC header fields AAR, AMS, and AS) to it 💌 All ARC header fields in an ARC Set share the same instance tag value.

To perform sealing (aka to build and attach a new ARC Set), the following actions must be taken by an ARC Sealer when it's handed a message 🧁

  1. All message modifications (including adding DKIM-Signature header field(s)) MUST be performed before sealing 🎀
  2. If the message already has an Authenticated Received Chain whose most recent AS reports cv=fail, there's no need to keep going, and the algorithm stops right here 🛑
  3. Calculate the instance value. If the message already has an Authenticated Received Chain, the instance value is 1 more than the highest instance number found in that chain. If there's no Authenticated Received Chain, the instance value is 1 🔢
  4. Using the calculated instance value, generate and attach a complete ARC Set to the message as follows:
    • A. Generate and attach an ARC-Authentication-Results header field as defined in Section 4.1.1.
    • B. Generate and attach an ARC-Message-Signature header field as defined in Section 4.1.2.
    • C. Generate and attach an ARC-Seal header field using the AS definition found in Section 4.1.3, the prescribed headers defined in Section 5.1.1, and the Chain Validation Status as determined during ARC validation ✨

5.1.1. Header Fields to Include in ARC-Seal Signatures 🖋️

The ARC-Seal gets generated in a way that's similar to how DKIM-Signature header fields are added to messages ([RFC6376], Section 3.7), with explicit requirements on the header fields and the ordering of those fields 📏

The signature of an AS header field signs a canonicalized form of the ARC Set header field values. These values go into the hash function in increasing instance order, starting at 1, and include the ARC Set being added at the time the message is sealed 🔢

Within an ARC Set, header fields go into the hash function in this order:

  1. ARC-Authentication-Results
  2. ARC-Message-Signature
  3. ARC-Seal

Note that when an Authenticated Received Chain has failed validation, the signing scope for the ARC-Seal is modified as specified in Section 5.1.2 🙈

5.1.2. Marking and Sealing "cv=fail" (Invalid) Chains 💔

When an Authenticated Received Chain has failed, 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 were the only set present 🥹

_INFORMATIONAL_: This approach is mandated for the case of a malformed or otherwise invalid Authenticated Received Chain 😭 In most invalid-chain cases there's no way to generate a deterministic set of AS header fields (Section 5.1.1), so this is the move.

5.1.3. Only One Authenticated Received Chain per Message 🔒

A message can have only one Authenticated Received Chain on it at a time 💅 Once it's broken, the chain can't be continued, because the chain of custody is no longer valid and responsibility for the message has been lost 🫠 For more on this topic, and on the design restriction that stops chain continuation or re-establishment, see [ARC-USAGE] 📖

5.1.4. Broad Ability to Seal 🌍

ARC isn't only for perimeter MTAs, bestie 🙌 Any Internet Mail Handler MAY seal a message by adding a complete ARC Set, whether or not it has modified the message or is even aware of having modified it. For more info, see Section 7.1 🦋

5.1.5. Sealing Is Always Safe 🛡️

The utility of an Authenticated Received Chain is limited to very specific cases ✨ Authenticated Received Chains are designed to give an Internet Mail Handler extra info when evaluating messages for delivery in the context of authentication failures. Specifically:

  • Properly adding an ARC Set to a message does not damage or invalidate an existing Authenticated Received Chain 💖
  • Sealing an Authenticated Received Chain when a message has not been modified does not negatively affect the chain 🌸
  • Validating a message exposes no new threat vectors (see Section 9) 🔐
  • An ADMD may choose to seal all inbound messages, whether or not a message has been modified or will be retransmitted 🫶

5.2. Validator Actions 🔍✨

Okay bestie, this is the Validator's checklist 💅. A Validator runs these steps in sequence to process an Authenticated Received Chain. The canonicalization, hash functions, and signature validation methods all get borrowed from [RFC6376], Section 5, so nothing new to learn there 🫶.

  1. Collect all ARC Sets currently attached to the message. 📎
    • If there are none, the Chain Validation Status is "none", and the algorithm stops here.
    • The maximum number of ARC Sets that can be attached to a message is 50. If more than the maximum number exist, the Chain Validation Status is "fail", and the algorithm stops here.
    • In the following algorithm, the maximum discovered ARC instance value is referred to as "N". 🔢
  2. If the Chain Validation Status of the highest instance value ARC Set is "fail", then the Chain Validation Status is "fail", and the algorithm stops here. 🚫
  3. Validate the structure of the Authenticated Received Chain. A valid ARC has these conditions, and they're giving strict 💀:

A. Each ARC Set MUST contain exactly one each of the three ARC header fields (AAR, AMS, and AS).

B. The instance values of the ARC Sets MUST form a continuous sequence from 1..N with no gaps or repetition.

C. The "cv" value for all ARC-Seal header fields MUST NOT be "fail". For ARC Sets with instance values > 1, the values MUST be "pass". For the ARC Set with instance value = 1, the value MUST be "none".

If any of these conditions are not met, the Chain Validation Status is "fail", and the algorithm stops here. 🛑

  1. Validate the AMS with the greatest instance value (most recent). If validation fails, then the Chain Validation Status is "fail", and the algorithm stops here. 🕵️‍♀️
  2. OPTIONAL: Determine the "oldest-pass" value from the ARC Set by validating each prior AMS, starting with N-1 and going in decreasing order down to the AMS with the instance value of 1. This step is optional, so you can skip it if you want 🫠:

A. If an AMS fails to validate (for instance value "M"), then set the oldest-pass value to the lowest AMS instance value that passed (M+1), and go to the next step (there is no need to check any other (older) AMS header fields). This does not affect the validity of the Authenticated Received Chain. ✨

B. If all AMS header fields verify, set the oldest-pass value to zero (0). 🌸

  1. Validate each AS, starting with the greatest instance value and proceeding in decreasing order to the AS with the instance value of 1. If any AS fails to validate, the Chain Validation Status is "fail", and the algorithm stops here. 🥀
  2. If the algorithm reaches this step, then the Chain Validation Status is "pass", and the algorithm is complete. 🎉👑

The end result of this validation algorithm SHOULD be included within the Authentication-Results header field for the ADMD. That's the receipt, babe 🧾💖.

As 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. Harsh but fair 😭.

INFORMATIONAL: Recipients of an invalid or failing Authenticated Received Chain can use that information as part of a wider handling context. ARC adoption cannot be assumed by intermediaries, because lots of them will keep modifying messages without adding ARC seals. Not everybody's on the ARC train yet 🚂🥲.

5.2.1. All Failures Are Permanent 💔

Authenticated Received Chains represent the traversal of messages through one or more intermediaries. All errors, including DNS failures, become unrecoverable and are considered permanent. No second chances in this house 🙈.

Any error validating an Authenticated Received Chain results in a Chain Validation Status of "fail". If you want the deeper tea on why chains can't be continued or re-established, check out [ARC-USAGE] 📚.

5.2.2. Responding to ARC Validation Failures during the SMTP Transaction 📨

If 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. Because 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. So it's a choice, and the general one is totally valid 💅✨.

6. Communication of Validation Results 📣

Chain Validation Status (described in Section 4.4) gets communicated via Authentication-Results (and AAR) header fields using the authentication method "arc". This authentication method is described in Section 10.1. Spill the results, honestly 🫶.

If necessary data is available, the ptypes and properties defined in Section 10.2 SHOULD be recorded in an Authentication-Results header field:

  • smtp.remote-ip - The address of the connection-initiating SMTP server, from which the message is being relayed. 🌐
  • header.oldest-pass - The instance number of the oldest AMS that still validates, or 0 if all pass. 🍓

7. Use Cases 🌈

This section explores several message handling use cases that ARC is literally built to handle. Let's go 💖.

7.1. Communicate Authentication Assessment across Trust Boundaries 🤝

When an intermediary ADMD adds an ARC Set to a message's Authenticated Received Chain (or creates the initial ARC Set), the ADMD communicates its authentication assessment to the next ARC-participating ADMD in the message-handling path. It's basically passing a note in class 📝.

If ARC-enabled ADMDs are trusted, Authenticated Received Chains can be used to bridge administrative boundaries. Trust is the whole vibe here 🫶.

7.1.1. Message-Scanning Services 🛡️

Message services are available to perform anti-spam, anti-malware, and anti-phishing scanning. Such services typically remove malicious content, replace HTTP links in messages with sanitized links, and/or attach footers to messages advertising the abilities of the message-scanning service. These modifications almost always break signature-based authentication (such as DKIM). Rude 💀.

Scanning services typically require clients to point MX records of an Internet domain to the scanning service. Messages destined for the Internet domain are initially delivered to the scanning service. Once scanning is performed, messages are then routed to the client's own mail-handling infrastructure. Rerouting messages in this way almost always breaks path-based authentication (such as SPF). Ugh, the plot twist 🙃.

Message-scanning services can attach Authenticated Received Chains to messages to communicate authentication assessment into client ADMDs. Clients can then benefit from the message-scanning service while processing messages as if the client's infrastructure were the original destination of the Internet domain's MX record. Main character energy for the scanner 💅🦋.

7.1.2. Multi-tier MTA Processing 🏗️

A large message-processing infrastructure is often divided into several processing tiers that can break authentication information between tiers. For example, a large site may maintain a cluster of MTAs dedicated to connection handling and enforcement of IP-based reputation filtering. A secondary cluster of MTAs may be dedicated and optimized for content-based processing of messages. Teamwork makes the dream work 👯‍♀️.

Authenticated Received Chains can be used to communicate authentication assessment between processing tiers. So the tiers stop losing track of each other 🧚.

7.1.3. Mailing Lists 📬

Mailing lists take delivery of messages and repost them to subscribers. A full description of authentication-related mailing list issues can be found in [RFC7960], Section 3.2.3. Go read that one if you're curious 👀.

Mailing list services can implement ARC to convey the authentication assessment of posted messages sent to the list's subscriber base. The ADMDs of the mailing list subscribers can then use the Authenticated Received Chain to determine the authentication assessment of the original message before mailing list handling. Receipts from before the reposting, iykyk 🌸.

7.2. Inform Message Disposition Decisions ⚖️

Intermediaries often break authentication through content modification, interfere with path-based authentication (such as SPF), and strip authentication results (if an MTA removes Authentication-Results header fields). Chaotic behavior, honestly 😭.

Authenticated Received Chains allow ARC Validators to:

  1. identify ARC-enabled ADMDs that break authentication while processing messages and
  2. gain extended visibility into the authentication-preserving abilities of ADMDs that relay messages into ARC-enabled ADMDs.

Through the collection of ARC-related data, an ADMD can identify handling paths that have broken authentication. Detective mode activated 🔎.

An Authenticated Received Chain allows an Internet Mail Handler to potentially base decisions of message disposition on authentication assessments provided by different ADMDs. Big brain decisions, all from the chain 🧠💜.

7.2.1. DMARC Local Policy Overrides 🎀

DMARC introduces a policy model where Domain Owners can request email receivers to reject or quarantine messages that fail DMARC alignment. Interoperability issues between DMARC and indirect email flows are documented in [RFC7960].

Authenticated Received Chains allow DMARC processors to consider authentication assessments provided by other ADMDs. As 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. It's the processor's call, bestie 💅.

When an Authenticated Received Chain is used to determine message disposition, the DMARC processor can communicate this local policy decision to Domain Owners as described in Section 7.2.2. Keep the receipts flowing 🧾.

7.2.2. DMARC Reporting 📊

DMARC-enabled receivers indicate when ARC validation influences DMARC-related local policy decisions. When 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:

  • the Chain Validation Status,
  • the domain and selector for each AS, and
  • the originating IP address from the first ARC Set.

EXAMPLE:

<policy_evaluated>
  <disposition>none</disposition>
  <dkim>fail</dkim>
  <spf>fail</spf>
  <reason>
   <type>local_policy</type>
   <comment>arc=pass as[2].d=d2.example as[2].s=s2
     as[1].d=d1.example as[1].s=s3
     remote-ip[1]=2001:DB8::1A</comment>
  </reason>
</policy_evaluated>

In the example DMARC XML reporting fragment above, data relating to specific validated ARC Sets are enumerated using array syntax (e.g., "as[2]" means an AS header field with an instance value of 2). d2.example is the sealing domain for ARC Set #2 (i=2), and d1.example is the sealing domain for ARC Set #1 (i=1). Array syntax is giving very organized energy 📋💖.

Depending on the reporting practices of intermediate message handlers, Domain Owners may receive multiple DMARC reports for a single message. Receivers of DMARC reports should be aware of this behavior and make the necessary accommodations. Expect duplicate reports and don't panic 🙈.

8. Privacy Considerations 🔐

The Authenticated Received Chain provides a verifiable record of the handlers for a message. This record may include personally identifiable information such as an IP address(es) and domain names. Such information is also included in existing non-ARC-related header fields such as the "Received" header fields. Receipts have receipts, so be mindful of what's in there 🫣🌸.

9. Security Considerations 🔐💀

okay bestie, this is the spooky section and it's giving serious. The Security Considerations of [RFC6376] and [RFC8601] apply directly to this spec, so those are required reading too 📚

As with other domain-based authentication technologies (such as SPF, DKIM, and DMARC), ARC makes no claims about the semantic content of messages. ✨ A received message with a validated ARC Chain provides evidence (at instance N) that:

  1. the sealing domain (ARC-Seal[N] d=) emitted the message with this body,
  2. the authentication assessment reported in the ARC-Authentication-Results was determined upon receipt of the corresponding message at the sealing domain, and
  3. the preceding ARC Chain (1..N-1) (with the validation status as reported in the cv field) existed on the message that was received and assessed.

9.1. Increased Header Field Size 📦

Okay so putting Authenticated Received Chains into messages can cause issues for older or constrained MTAs, because the total header field size gets bigger 😩 Big header field blocks in general can lead to failed deliveries or other outage scenarios for those MTAs. ARC itself would not cause problems, though 💖

9.2. DNS Operations 🌐

Validating an Authenticated Received Chain made of N ARC Sets can take up to 2*N DNS queries. This doesn't count any DNS redirection mechanisms, which can push the total number of queries even higher. So there are two big considerations here 👀

  1. An attacker can send a message to an ARC participant with a concocted sequence of ARC Sets bearing the domains of intended victims. The participant will query all of them until it finds a failure. DNS caching and the difficulty of forging the signature values should limit how much of this load lands on domains under the attacker's control. Query traffic pattern analysis may expose information about a downstream validating ADMD infrastructure, which is a lot 🫣
  2. DKIM only does one DNS query per signature, but ARC can introduce many per chain. Without caching, slow DNS responses can cause SMTP timeouts and backlogged delivery queues on validating systems. This could be exploited as a DoS attack 😱

9.3. Message Content Suspicion 🕵️‍♀️

Recipients are cautioned to treat messages bearing Authenticated Received Chains with the same suspicion they give every other message. That includes proper content scanning and other checks for potentially malicious content 🧐

ARC authenticates the identity of some email-handling actors. It does not make any assessment of how trustworthy they are 🙃

Just like passing message authentication isn't a sign that a message is safe, forwarding that information through ARC doesn't mean the message is safe either. Even if every ARC-enabled ADMD is trusted, those ADMDs may have been compromised, may miss unsafe content, or may not authenticate messages properly. Not me trusting a chain just because it has a lot of seals 💀

9.4. Message Sealer Suspicion 🦹

Recipients are cautioned to treat every Sealer of the ARC Chain with suspicion. Same energy as a validated DKIM signature: responsibility for message handling goes to the sealing domain, but whether that Sealer is a malicious actor is out of scope for the authentication mechanism. ARC helps messages get delivered when authentication fails, so ARC Sealers should be treated with suspicion. That way a malicious actor can't seal spam or other fraudulent messages to get them delivered too 🚫

9.5. Replay Attacks 🔁

ARC inherits a lot from DKIM, so it has similar attack vectors 🫠 The replay attack described in [RFC6376], Section 8.6 is potentially amplified by ARC's chained statuses. In an ARC replay attack, a malicious actor takes an intact, passing ARC Chain and resends it to many recipients without changing anything that would invalidate the latest AMS or AS. The impact on a receiver would be more DNS lookups and signature evaluations. The scope of this attack can be limited by caching DNS queries and following the same signing scope guidance from [RFC6376], Section 5.4.1 💜

10. IANA Considerations 📋

This document defines one new authentication method and several status codes (Section 10.1), new ptypes and properties (Section 10.2), three new header fields (Section 10.3), and a new enumerated status code (Section 10.4). Lots of new registry stuff, bestie 🎀

10.1. Update to Email Authentication Result Names Registry 🏷️

Per this document, IANA has added one authentication method with three codes to the IANA "Email Authentication Result Names" registry:

o  Auth Method: arc
   Code: "none", "pass", "fail"
   Specification: RFC 8617, Section 4.4
   Status: active

10.2. Update to Email Authentication Methods Registry 🧩

Per this document, IANA has added the following to the "Email Authentication Methods" registry, which is defined in [RFC8601]:

o  Method: arc
   Definition: RFC 8617, Section 6
   ptype: smtp
   Property: remote-ip
   Value: IP address (v4 or v6) of originating SMTP connection
   Status: active
   Version: 1

o  Method: arc
   Definition: RFC 8617, Section 6
   ptype: header
   Property: oldest-pass
   Value: The instance id of the oldest validating AMS or 0 if they
   all pass (see Section 5.2)
   Status: active
   Version: 1

10.3. New Header Fields in Permanent Message Header Field Registry 💌

Per this document, IANA has added the following three new header fields to the "Permanent Message Header Field Names" registry:

o  Header field name: ARC-Seal
   Applicable protocol: mail
   Status: experimental
   Author/Change controller: IETF
   Specification document(s): RFC 8617
   Related information: RFC 6376

o  Header field name: ARC-Message-Signature
   Applicable protocol: mail
   Status: experimental
   Author/Change controller: IETF
   Specification document(s): RFC 8617
   Related information: RFC 6376

o  Header field name: ARC-Authentication-Results
   Applicable protocol: mail
   Status: experimental
   Author/Change controller: IETF
   Specification document(s): RFC 8617
   Related information: RFC 8601

10.4. New Status Code in Enumerated Status Codes Registry 🔢

Per this document, IANA has added the following value to the "Enumerated Status Codes" registry:

o  Code: X.7.29
   Sample Text: ARC validation failure
   Associated basic status code: 550
   Description: This status code may be returned when a message fails
   ARC validation.
   Reference: RFC 8617
   Submitter: K. Andersen
   Change controller: IESG

11. Experimental Considerations 🧪

The ARC protocol is designed to address common interoperability issues introduced by intermediate message handlers. Those interoperability issues are described in [RFC6377] and [RFC7960] 🤝

As Internet Mail Handlers implement the ARC protocol over time, the following should be evaluated to determine whether the protocol is succeeding at its intended benefits 📈

11.1. Success Consideration 🏆

Many receivers use heuristic-based methods to identify messages that arrive via indirect delivery paths, all in an effort to deliver the legitimate messages users actually want 💅

ARC will be a success if the presence of Authenticated Received Chains allows for better decision making when processing legitimate messages. Specifically, that means equal or better delivery rates than heuristic approaches achieve 🌟

11.2. Failure Considerations 💥

ARC should function without introducing significant new vectors for abuse (see Section 9). If unforeseen vectors get enabled by ARC, this protocol will be a failure 😭 Also, the weaknesses inherent in the mail protocols ARC is built on (such as DKIM replay attacks and other known issues) are not new vectors that can be pinned on this specification. So don't blame ARC for DKIM's drama 🙄

11.3. Open Questions 🤔

The following open questions are academic and had no clear answer when this document was published. Additional deployments should be able to gather the data needed to answer some or all of them 📊

11.3.1. Value of the ARC-Seal (AS) Header Field 🔍

Data should be collected to show whether the AS provides value beyond the AMS, either for making delivery decisions or for catching malicious actors trying to craft or replay malicious chains 🕵️

11.3.2. Usage and/or Signals from Multiple Selectors and/or Domains in ARC Sets 🎭

Any selectors and/or (sub)domains under the control of the sealing ADMD may be used for ARC header field signatures.

While implementers may choose to use various selectors and/or domains for ARC Set header fields, the working group hasn't made a compelling argument for or against that usage. So we chose to allow maximum freedom for the experimental definition of this protocol 🦋

Wider deployment experience and higher volumes of traffic may show whether this is useful 📡

11.3.3. DNS Overhead 🐢

Longer Authenticated Received Chains will require more queries to retrieve the keys needed to validate the chain. While this is not believed to be a security issue (see Section 9.2), it's unclear how much overhead will actually get added. This is similar to some of the initial processing and query load concerns that were debated when the DKIM specification was being developed 🫠

Data should be collected to better understand the usable length and distribution of lengths in valid Authenticated Received Chains, along with the DNS impact of processing them 📉

An effective operational maximum will have to be developed through deployment experience in the field 🛠️

11.3.4. What Trace Information Is Valuable? 🕰️

There are several edge cases where the information in the AAR can make the difference between message delivery and rejection. For example, if a well-known mailing list seals with ARC but doesn't do its own initial DMARC enforcement, an Internet Mail Handler that knows this could make a delivery decision based on the authentication information in the corresponding AAR header field 🎯

Certain trace information in the AAR is useful, or even necessary, when building DMARC reports 📝

Certain receivers also believe the entire set of trace information would be valuable to feed into machine learning systems to identify fraud and/or provide other signals related to message delivery 🤖

Right now, though, it's unclear what trace information will be valuable for all receivers, regardless of size 🤷‍♀️

Data should be collected on which trace information receivers use to get signals that affect deliverability, and which portions of the trace data are left untouched or provide no useful information 🔬

Since many such systems are intentionally proprietary or confidential to prevent gaming by abusers, it may not be viable to reliably answer this particular question. The evolving nature of attacks can also shift what counts as "useful" information over time 🌀

12. References 📚✨

12.1. Normative References ✨

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. 💖

[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>. 🎀

[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-editor.org/info/rfc5322>. 🦋

[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, DOI 10.17487/RFC5598, July 2009, <https://www.rfc-editor.org/info/rfc5598>. 🌸

[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, <https://www.rfc-editor.org/info/rfc6376>. 🔑

[RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377, September 2011, <https://www.rfc-editor.org/info/rfc6377>. 📬

[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, DOI 10.17487/RFC6532, February 2012, <https://www.rfc-editor.org/info/rfc6532>. 🌈

[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, <https://www.rfc-editor.org/info/rfc7208>. ⭐

[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, DOI 10.17487/RFC7405, December 2014, <https://www.rfc-editor.org/info/rfc7405>. 🧚

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. 🍓

[RFC8601] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 8601, DOI 10.17487/RFC8601, May 2019, <https://www.rfc-editor.org/info/rfc8601>. 💜

[RFC8616] Levine, J., "Email Authentication for Internationalized Mail", RFC 8616, DOI 10.17487/RFC8616, June 2019, <https://www.rfc-editor.org/info/rfc8616>. 👑

12.2. Informative References 🌸

[ARC-MULTI] Andersen, K., Blank, S., Ed., and J. Levine, Ed., "Using Multiple Signing Algorithms with the ARC (Authenticated Received Chain) Protocol", Work in Progress, draft-ietf-dmarc-arc-multi-03, March 2019. 🧩

[ARC-USAGE] Jones, S., Ed. and K. Andersen, "Recommended Usage of the Authenticated Received Chain (ARC)", Work in Progress, draft-ietf-dmarc-arc-usage-07, April 2019. 📝

[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, <https://www.rfc-editor.org/info/rfc7489>. 🛡️

[RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky, E., Ed., and K. Andersen, Ed., "Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows", RFC 7960, DOI 10.17487/RFC7960, September 2016, <https://www.rfc-editor.org/info/rfc7960>. 💌

Appendix A. Design Requirements 🎀

okay so this part is the big-picture wishlist 📋 the ARC framework was built around some high-level goals, security considerations, and practical operational needs, and honestly it's giving very intentional design energy 💅

A.1. Primary Design Criteria ✨

  • Provide a verifiable "chain of custody" for email messages; 🔗
  • Not require changes for originators of email; 💌
  • Support the verification of the ARC header field set by each hop in the handling chain; 🦋
  • Work at Internet scale; and 🌍
  • Provide a trustable mechanism for the communication of Authentication-Results across trust boundaries. 🫶

A.2. Out of Scope 🙈

ARC is not a trust framework. ngl this is a really important boundary, bestie 🚧 People who read the ARC header fields are warned not to jump to unsubstantiated conclusions when they run into a "broken" ARC sequence. 💀

Appendix B. Example Usage 💜

okay so here's a vibe check 🔍 The following message is an example of one that has passed through several intermediary handlers 🔁 some of them changed the message and some of them didn't, and you can see all of it below 👀

Return-Path: <jqd@d1.example>
Received: from example.org (example.org [208.69.40.157])
    by gmail.example with ESMTP id d200mr22663000ykb.93.1421363207
    for <fmartin@example.com>; Thu, 14 Jan 2015 15:02:40 -0800 (PST)
Received: from segv.d1.example (segv.d1.example [72.52.75.15])
    by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
    for <arc@example.org>; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
    (envelope-from jqd@d1.example)
Received: from [2001:DB8::1A] (w-x-y-z.dsl.static.isp.example [w.x.y.z])
    (authenticated bits=0)
    by segv.d1.example with ESMTP id t0FN4a8O084569;
    Thu, 14 Jan 2015 15:00:01 -0800 (PST)
    (envelope-from jqd@d1.example)
Received: from mail-ob0-f188.google.example
    (mail-ob0-f188.google.example [208.69.40.157]) by
    clochette.example.org with ESMTP id d200mr22663000ykb.93.1421363268
    for <fmartin@example.org>; Thu, 14 Jan 2015 15:03:15 -0800 (PST)
ARC-Seal: i=3; a=rsa-sha256; cv=pass; d=clochette.example.org; s=
        clochette; t=12345; b=CU87XzXlNlk5X/yW4l73UvPUcP9ivwYWxyBWcVrRs7
        +HPx3K05nJhny2fvymbReAmOA9GTH/y+k9kEc59hAKVg==
ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed; d=
        clochette.example.org; h=message-id:date:from:to:subject; s=
        clochette; t=12345; bh=KWSe46TZKCcDbH4klJPo+tjk5LWJnVRlP5pvjXFZY
        LQ=; b=o71vwyLsK+Wm4cOSlirXoRwzEvi0vqIjd/2/GkYFYlSd/GGfKzkAgPqxf
        K7ccBMP7Zjb/mpeggswHjEMS8x5NQ==
ARC-Authentication-Results: i=3; clochette.example.org; spf=fail
    smtp.from=jqd@d1.example; dkim=fail (512-bit key)
    header.i=@d1.example; dmarc=fail; arc=pass (as.2.gmail.example=pass,
    ams.2.gmail.example=pass, as.1.lists.example.org=pass,
    ams.1.lists.example.org=fail (message has been altered))
Authentication-Results: clochette.example.org; spf=fail
    smtp.from=jqd@d1.example; dkim=fail (512-bit key)
    header.i=@d1.example; dmarc=fail; arc=pass (as.2.gmail.example=pass,
    ams.2.gmail.example=pass, as.1.lists.example.org=pass,
    ams.1.lists.example.org=fail (message has been altered))
ARC-Seal: i=2; a=rsa-sha256; cv=pass; d=gmail.example; s=20120806; t=
        12345; b=Zpukh/kJL4Q7Kv391FKwTepgS56dgHIcdhhJZjsalhqkFIQQAJ4T9BE
        8jjLXWpRNuh81yqnT1/jHn086RwezGw==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=
        gmail.example; h=message-id:date:from:to:subject; s=20120806; t=
        12345; bh=KWSe46TZKCcDbH4klJPo+tjk5LWJnVRlP5pvjXFZYLQ=; b=CVoG44
        cVZvoSs2mMig2wwqPaJ4OZS5XGMCegWqQs1wvRZJS894tJM0xO1RJLgCPsBOxdA5
        9WSqI9s9DfyKDfWg==
ARC-Authentication-Results: i=2; gmail.example; spf=fail
    smtp.from=jqd@d1.example; dkim=fail (512-bit key)
    header.i=@example.org; dmarc=fail; arc=pass
    (as.1.lists.example.org=pass, ams.1.lists.example.org=pass)
ARC-Seal: i=1; a=rsa-sha256; cv=none; d=lists.example.org; s=dk-lists;
         t=12345; b=TlCCKzgk3TrAa+G77gYYO8Fxk4q/Ml0biqduZJeOYh6+0zhwQ8u/
        lHxLi21pxu347isLSuNtvIagIvAQna9a5A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=
        lists.example.org; h=message-id:date:from:to:subject; s=
        dk-lists; t=12345; bh=KWSe46TZKCcDbH4klJPo+tjk5LWJnVRlP5pvjXFZYL
        Q=; b=DsoD3n3hiwlrN1ma8IZQFgZx8EDO7Wah3hUjIEsYKuShRKYB4LwGUiKD5Y
        yHgcIwGHhSc/4+ewYqHMWDnuFxiQ==
ARC-Authentication-Results: i=1; lists.example.org; spf=pass
    smtp.mfrom=jqd@d1.example; dkim=pass (512-bit key)
    header.i=@d1.example; dmarc=pass
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=d1.example; h=
        message-id:date:from:to:subject; s=origin2015; bh=bIxxaeIQvmOBdT
        AitYfSNFgzPP4=; b=qKjd5fYibKXWWIcMKCgRYuo1vJ2fD+IAQPjX+uamXIGY2Q
        0HjQ+Lq3/yHzG3JHJp6780/nKQPOWt2UDJQrJkEA==
Message-ID: <54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe <jqd@d1.example>
To: arc@dmarc.example
Subject: [List 2] Example 1

Hey gang,
This is a test message.
--J.

Acknowledgments 🫶

This document originated with the work of OAR-Dev Group. 🌱

The authors thank all of the OAR-Dev and the subsequent DMARC WG for the ongoing help and thought-provoking discussions from all the participants, especially J. Trent Adams, Marc Bradshaw, Alex Brotman, Greg Colburn, Dave Crocker, Tim Draegen, Mark Eissler, Peter Goldstein, Bron Gondwana, Mike Hammer, Mike Jones, Steve Jones, Scott Kitterman, Barry Leiba, Franck Martin, John Rae-Grant, Paul Rock, Gene Shuman, Terry Zink, and Elizabeth Zwicky. 🥹💖

Grateful appreciation is extended to the people who provided feedback through the arc-discuss mailing list. 🌸

Authors' Addresses ✨

Kurt Andersen LinkedIn 1000 West Maude Ave Sunnyvale, California 94085 United States of America

Email: kurt+ietf@drkurt.com 🦋

Brandon Long (editor) Google

Email: blong@google.com 🎀

Seth Blank (editor) Valimail

Email: seth@valimail.com 💜

Murray Kucherawy (editor) TDP

Email: superuser@gmail.com 👑

That's the whole spec, bestie! 🌈🦋✨

📦 where this page comes from