8617
EXPERIMENTAL
The Authenticated Received Chain (ARC) Protocol
Authors: K. Andersen, B. Long, S. Blank, M. Kucherawy
Date: July 2019
Area: art
Working Group: dmarc
Stream: IETF
Abstract
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 sets of ARC assertions that represent the authentication assessment at each step of the message-handling paths.
ARC-enabled Internet Mail Handlers can process sets of ARC assertions to inform message disposition decisions, identify Internet Mail Handlers that might break existing authentication mechanisms, and convey original authentication assessments across trust boundaries.
RFC 8617
EXPERIMENTAL
Errata Exist
Internet Engineering Task Force (IETF) K. Andersen
Request for Comments: 8617 LinkedIn
Category: Experimental B. Long, Ed.
ISSN: 2070-1721 Google
S. Blank, Ed.
Valimail
M. Kucherawy, Ed.
TDP
July 2019
<span class="h1">The Authenticated Received Chain (ARC) Protocol</span>
Abstract
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 sets of ARC
assertions that represent the authentication assessment at each step
of the message-handling paths.
ARC-enabled Internet Mail Handlers can process sets of ARC assertions
to inform message disposition decisions, identify Internet Mail
Handlers that might break existing authentication mechanisms, and
convey original authentication assessments across trust boundaries.
<span class="grey">Andersen, et al. Experimental [Page 1]</span><span id="page-2" ></span>
<span class="grey"><a href="./rfc8617">RFC 8617</a> The ARC Protocol July 2019</span>
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for examination, experimental implementation, and
evaluation.
This document defines an Experimental Protocol for the Internet
community. This document is a product of the Internet Engineering
Task Force (IETF). It represents the consensus of the IETF
community. It has received public review and has been approved for
publication by the Internet Engineering Steering Group (IESG). Not
all documents approved by the IESG are candidates for any level of
Internet Standard; see <a href="./rfc7841#section-2">Section 2 of RFC 7841</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="https://www.rfc-editor.org/info/rfc8617">https://www.rfc-editor.org/info/rfc8617</a>.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to 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 are provided without warranty as
described in the Simplified BSD License.
<span class="grey">Andersen, et al. Experimental [Page 2]</span><span id="page-3" ></span>
<span class="grey"><a href="./rfc8617">RFC 8617</a> The ARC Protocol July 2019</span>
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2">2</a>. General Concepts . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-2.1">2.1</a>. Evidence . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-2.2">2.2</a>. Custody . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-2.3">2.3</a>. Chain of Custody . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-2.4">2.4</a>. Validation of Chain of Custody . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3">3</a>. Terminology and Definitions . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3.1">3.1</a>. ARC Set . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3.2">3.2</a>. Authenticated Received Chain (ARC) . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3.3">3.3</a>. Internet Mail Handlers / Intermediaries . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3.4">3.4</a>. Authentication Assessment . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3.5">3.5</a>. Signing vs. Sealing . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-3.6">3.6</a>. Sealer . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-3.7">3.7</a>. Validator . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-3.8">3.8</a>. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-3.9">3.9</a>. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-4">4</a>. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-4.1">4.1</a>. ARC Header Fields . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-4.1.1">4.1.1</a>. ARC-Authentication-Results (AAR) . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-4.1.2">4.1.2</a>. ARC-Message-Signature (AMS) . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-4.1.3">4.1.3</a>. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-4.1.4">4.1.4</a>. Internationalized Email (EAI) . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-4.2">4.2</a>. ARC Set . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-4.2.1">4.2.1</a>. Instance Tags . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-4.3">4.3</a>. Authenticated Received Chain . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-4.4">4.4</a>. Chain Validation Status . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-5">5</a>. Protocol Actions . . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-5.1">5.1</a>. Sealer Actions . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-5.1.1">5.1.1</a>. Header Fields to Include in ARC-Seal Signatures . . . <a href="#page-15">15</a>
<a href="#section-5.1.2">5.1.2</a>. Marking and Sealing "cv=fail" (Invalid) Chains . . . <a href="#page-15">15</a>
<a href="#section-5.1.3">5.1.3</a>. Only One Authenticated Received Chain per Message . . <a href="#page-16">16</a>
<a href="#section-5.1.4">5.1.4</a>. Broad Ability to Seal . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-5.1.5">5.1.5</a>. Sealing Is Always Safe . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-5.2">5.2</a>. Validator Actions . . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-5.2.1">5.2.1</a>. All Failures Are Permanent . . . . . . . . . . . . . <a href="#page-18">18</a>
5.2.2. Responding to ARC Validation Failures during the SMTP
Transaction . . . . . . . . . . . . . . . . . . . . . <a href="#page-19">19</a>
<a href="#section-6">6</a>. Communication of Validation Results . . . . . . . . . . . . . <a href="#page-19">19</a>
<a href="#section-7">7</a>. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-19">19</a>
7.1. Communicate Authentication Assessment across Trust
Boundaries . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-19">19</a>
<a href="#section-7.1.1">7.1.1</a>. Message-Scanning Services . . . . . . . . . . . . . . <a href="#page-20">20</a>
<a href="#section-7.1.2">7.1.2</a>. Multi-tier MTA Processing . . . . . . . . . . . . . . <a href="#page-20">20</a>
<a href="#section-7.1.3">7.1.3</a>. Mailing Lists . . . . . . . . . . . . . . . . . . . . <a href="#page-20">20</a>
<a href="#section-7.2">7.2</a>. Inform Message Disposition Decisions . . . . . . . . . . <a href="#page-21">21</a>
<a href="#section-7.2.1">7.2.1</a>. DMARC Local Policy Overrides . . . . . . . . . . . . <a href="#page-21">21</a>
<span class="grey">Andersen, et al. Experimental [Page 3]</span><span id="page-4" ></span>
<span class="grey"><a href="./rfc8617">RFC 8617</a> The ARC Protocol July 2019</span>
<a href="#section-7.2.2">7.2.2</a>. DMARC Reporting . . . . . . . . . . . . . . . . . . . <a href="#page-22">22</a>
<a href="#section-8">8</a>. Privacy Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-22">22</a>
<a href="#section-9">9</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-23">23</a>
<a href="#section-9.1">9.1</a>. Increased Header Field Size . . . . . . . . . . . . . . . <a href="#page-23">23</a>
<a href="#section-9.2">9.2</a>. DNS Operations . . . . . . . . . . . . . . . . . . . . . <a href="#page-23">23</a>
<a href="#section-9.3">9.3</a>. Message Content Suspicion . . . . . . . . . . . . . . . . <a href="#page-24">24</a>
<a href="#section-9.4">9.4</a>. Message Sealer Suspicion . . . . . . . . . . . . . . . . <a href="#page-24">24</a>
<a href="#section-9.5">9.5</a>. Replay Attacks . . . . . . . . . . . . . . . . . . . . . <a href="#page-24">24</a>
<a href="#section-10">10</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-25">25</a>
<a href="#section-10.1">10.1</a>. Update to Email Authentication Result Names Registry . . <a href="#page-25">25</a>
<a href="#section-10.2">10.2</a>. Update to Email Authentication Methods Registry . . . . <a href="#page-25">25</a>
10.3. New Header Fields in Permanent Message Header Field
Registry . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-26">26</a>
<a href="#section-10.4">10.4</a>. New Status Code in Enumerated Status Codes Registry . . <a href="#page-26">26</a>
<a href="#section-11">11</a>. Experimental Considerations . . . . . . . . . . . . . . . . . <a href="#page-27">27</a>
<a href="#section-11.1">11.1</a>. Success Consideration . . . . . . . . . . . . . . . . . <a href="#page-27">27</a>
<a href="#section-11.2">11.2</a>. Failure Considerations . . . . . . . . . . . . . . . . . <a href="#page-27">27</a>
<a href="#section-11.3">11.3</a>. Open Questions . . . . . . . . . . . . . . . . . . . . . <a href="#page-27">27</a>
<a href="#section-11.3.1">11.3.1</a>. Value of the ARC-Seal (AS) Header Field . . . . . . <a href="#page-27">27</a>
11.3.2. Usage and/or Signals from Multiple Selectors and/or
Domains in ARC Sets . . . . . . . . . . . . . . . . <a href="#page-28">28</a>
<a href="#section-11.3.3">11.3.3</a>. DNS Overhead . . . . . . . . . . . . . . . . . . . . <a href="#page-28">28</a>
<a href="#section-11.3.4">11.3.4</a>. What Trace Information Is Valuable? . . . . . . . . <a href="#page-28">28</a>
<a href="#section-12">12</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-29">29</a>
<a href="#section-12.1">12.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-29">29</a>
<a href="#section-12.2">12.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-30">30</a>
<a href="#appendix-A">Appendix A</a>. Design Requirements . . . . . . . . . . . . . . . . <a href="#page-32">32</a>
<a href="#appendix-A.1">A.1</a>. Primary Design Criteria . . . . . . . . . . . . . . . . . <a href="#page-32">32</a>
<a href="#appendix-A.2">A.2</a>. Out of Scope . . . . . . . . . . . . . . . . . . . . . . <a href="#page-32">32</a>
<a href="#appendix-B">Appendix B</a>. Example Usage . . . . . . . . . . . . . . . . . . . <a href="#page-32">32</a>
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-35">35</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-35">35</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The utility of widely deployed email authentication technologies such
as Sender Policy Framework (SPF) [<a href="./rfc7208" title=""Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1"">RFC7208</a>] and DomainKeys Identified
Mail (DKIM) [<a href="./rfc6376" title=""DomainKeys Identified Mail (DKIM) Signatures"">RFC6376</a>] is impacted by the processing of Internet Mail
by intermediate handlers. This impact is thoroughly documented in
the defining documents for SPF and DKIM and further discussed in
[<a href="./rfc6377" title=""DomainKeys Identified Mail (DKIM) and Mailing Lists"">RFC6377</a>] and [<a href="./rfc7960" title=""Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows"">RFC7960</a>].
Domain-based Message Authentication, Reporting, and Conformance
(DMARC) [<a href="./rfc7489" title=""Domain-based Message Authentication, Reporting, and Conformance (DMARC)"">RFC7489</a>] also relies upon SPF and DKIM authentication
mechanisms. Failures of authentication caused by the actions of
intermediate handlers can cause legitimate mail to be incorrectly
rejected or misdirected.
<span class="grey">Andersen, et al. Experimental [Page 4]</span><span id="page-5" ></span>
<span class="grey"><a href="./rfc8617">RFC 8617</a> The ARC Protocol July 2019</span>
Authenticated Received Chain (ARC) creates a mechanism for individual
Internet Mail Handlers to add their authentication assessment to a
message's ordered set of handling results. ARC encapsulates the
authentication assessment in a DKIM signature derivative to grant
other handlers the ability to verify the authenticity of the
individual assessment assertion as well as the aggregate set and
sequence of results.
Ordered sets of authentication assessments can be used by ARC-enabled
Internet Mail Handlers to inform message-handling disposition,
identify where alteration of message content might have occurred, and
provide additional trace information for use in understanding
message-handling paths.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. General Concepts</span>
ARC is loosely based on concepts from evidence collection. Evidence
is usually collected, labeled, stored, and transported in specific
ways to preserve the state of evidence and to document all processing
steps.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Evidence</span>
In ARC's situation, the "evidence" is a message's authentication
assessment at any point along the delivery path between origination
and final delivery. Determination of message authentication can be
affected when intermediate handlers modify message content (header
fields and/or body content), route messages through unforeseen paths,
or change envelope information.
The authentication assessment for a message is determined upon
receipt of a message and documented in the Authentication-Results
header field(s). ARC extends this mechanism to survive transit
through intermediary Administrative Management Domains (ADMDs).
Because the first-hand determination of an authentication assessment
can never be reproduced by other handlers, the assertion of the
authentication assessment is more akin to testimony by a verifiable
party than to hard evidence, which can be independently evaluated.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Custody</span>
"Custody" refers to when an Internet Mail Handler processes a
message. When a handler takes custody of a message, the handler
becomes a custodian and attaches its own evidence (authentication
assessment upon receipt) to the message if it is ARC enabled.
Evidence is added in such a way that future handlers can verify the
authenticity of both evidence and custody.
<span class="grey">Andersen, et al. Experimental [Page 5]</span><span id="page-6" ></span>
<span class="grey"><a href="./rfc8617">RFC 8617</a> The ARC Protocol July 2019</span>
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. Chain of Custody</span>
The "chain of custody" of ARC is the entire set of evidence and
custody that travels with a message.
<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>. Validation of Chain of Custody</span>
Any ARC-enabled Internet Mail Handler can validate the entire set of
custody and the authentication assessments asserted by each party to
yield a valid chain of custody. If the evidence-supplying custodians
can be trusted, then the validated chain of custody describes the
(possibly changing) authentication assessment as the message traveled
through various custodians.
Even though a message's authentication assessment might have changed,
the validated chain of custody can be used to determine if the
changes (and the custodians responsible for the changes) can be
tolerated.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Terminology and Definitions</span>
This section defines terms used in the rest of the document.
Readers should to be familiar with the contents, core concepts, and
definitions found in [<a href="./rfc5598" title=""Internet Mail Architecture"">RFC5598</a>]. The potential roles of transit
services in the delivery of email are directly relevant.
Language, syntax (including some ABNF constructs), and concepts are
imported from DKIM [<a href="./rfc6376" title=""DomainKeys Identified Mail (DKIM) Signatures"">RFC6376</a>]. Specific references to DKIM are made
throughout this document. The following terms are imported from
[<a href="./rfc5598" title=""Internet Mail Architecture"">RFC5598</a>]:
o Administrative Management Domain (ADMD), <a href="#section-2.3">Section 2.3</a>
o Message Transfer Agent (MTA), <a href="#section-4.3.2">Section 4.3.2</a>
o Message Submission Agent (MSA), <a href="#section-4.3.1">Section 4.3.1</a>
o Message Delivery Agent (MDA), <a href="#section-4.3.3">Section 4.3.3</a>
Syntax descriptions use ABNF [<a href="./rfc5234" title=""Augmented BNF for Syntax Specifications: ABNF"">RFC5234</a>] [<a href="./rfc7405" title=""Case-Sensitive String Support in ABNF"">RFC7405</a>].
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
<a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>] [<a href="./rfc8174" title=""Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"">RFC8174</a>] when, and only when, they appear in all
capitals, as shown here.
<span class="grey">Andersen, et al. Experimental [Page 6]</span><span id="page-7" ></span>
<span class="grey"><a href="./rfc8617">RFC 8617</a> The ARC Protocol July 2019</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. ARC Set</span>
<a href="#section-4.1">Section 4.1</a> introduces three (3) ARC header fields that are added to
a message by an ARC-enabled Internet Mail Handler. Together, these
three header fields compose a single "ARC Set". An ARC Set provides
the means for an Internet Mail Handler to attach an authentication
assessment to a message in a manner that can be verified by future
handlers. A single message can contain multiple ARC Sets.
In general concept terms, an ARC Set represents Evidence and Custody.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Authenticated Received Chain (ARC)</span>
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 through 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.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Internet Mail Handlers / Intermediaries</span>
Internet Mail Handlers process and deliver messages across the
Internet and include MSAs, MTAs, MDAs, gateways, and mailing lists as
defined in [<a href="./rfc5598" title=""Internet Mail Architecture"">RFC5598</a>].
Throughout this document, the term "intermediaries" refers to both
regular MTAs as well as delivery/reposting agents such as mailing
lists covered within the scope of transit services per [<a href="./rfc5598" title=""Internet Mail Architecture"">RFC5598</a>].
"Intermediaries" and "Internet Mail Handlers" are used synonymously
throughout this document.
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Authentication Assessment</span>
The authentication assessment that is affixed to a message as part of
each ARC Set consists of the "authres-payload" [<a href="./rfc8601" title=""Message Header Field for Indicating Message Authentication Status"">RFC8601</a>]. For the
integrity of an ARC Set, the authentication assessment only needs to
be properly encapsulated within the ARC Set as defined in
<a href="#section-4.1">Section 4.1</a>. The accuracy or syntax of the authres-payload field
does not affect the validity of the ARC Chain itself.
<span class="grey">Andersen, et al. Experimental [Page 7]</span><span id="page-8" ></span>
<span class="grey"><a href="./rfc8617">RFC 8617</a> The ARC Protocol July 2019</span>
<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>. Signing vs. Sealing</span>
Signing is the process of affixing a digital signature to a message
as a header field, such as when a DKIM-Signature (as in <a href="./rfc6376#section-2.1">[RFC6376],
Section 2.1</a>), 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.
<span class="h3"><a class="selflink" id="section-3.6" href="#section-3.6">3.6</a>. Sealer</span>
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.
<span class="h3"><a class="selflink" id="section-3.7" href="#section-3.7">3.7</a>. Validator</span>
A Validator is an ARC-enabled Internet Mail Handler that evaluates an
Authenticated Received Chain for validity and content. The process
of evaluation of the individual ARC Sets that compose an
Authenticated Received Chain is described in <a href="#section-5.2">Section 5.2</a>.
In general concept terms, a Validator inspects the chain of custody
to determine the content and validity of individual evidence supplied
by custodians.
<span class="h3"><a class="selflink" id="section-3.8" href="#section-3.8">3.8</a>. Imported ABNF Tokens</span>
The following ABNF tokens are imported:
o tag-list (<a href="./rfc6376#section-3.2">[RFC6376], Section 3.2</a>)
o authres-payload (<a href="./rfc8601#section-2.2">[RFC8601], Section 2.2</a>)
o CFWS (<a href="./rfc5322#section-3.2.2">[RFC5322], Section 3.2.2</a>)
<span class="h3"><a class="selflink" id="section-3.9" href="#section-3.9">3.9</a>. Common ABNF Tokens</span>
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
<span class="grey">Andersen, et al. Experimental [Page 8]</span><span id="page-9" ></span>
<span class="grey"><a href="./rfc8617">RFC 8617</a> The ARC Protocol July 2019</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Protocol Elements</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. ARC Header Fields</span>
ARC introduces three new header fields. The syntax for new header
fields adapts existing specifications. This document only describes
where ARC-specific changes in syntax and semantics differ from
existing specifications.
<span class="h4"><a class="selflink" id="section-4.1.1" href="#section-4.1.1">4.1.1</a>. ARC-Authentication-Results (AAR)</span>
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 [<a href="./rfc8601" title=""Message Header Field for Indicating Message Authentication Status"">RFC8601</a>], with two (2) differences:
o the name of the header field itself and
o the presence of the instance tag. Additional information on the
instance tag can be found in <a href="#section-4.2.1">Section 4.2.1</a>.
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.
<span class="h4"><a class="selflink" id="section-4.1.2" href="#section-4.1.2">4.1.2</a>. ARC-Message-Signature (AMS)</span>
The ARC-Message-Signature (AMS) header field allows an ARC-
participating ADMD to convey some responsibility (custodianship) for
a message and possible message modifications to future ARC-
participating custodians.
In general concept terms, the AMS header field identifies a
custodian.
<span class="grey">Andersen, et al. Experimental [Page 9]</span><span id="page-10" ></span>
<span class="grey"><a href="./rfc8617">RFC 8617</a> The ARC Protocol July 2019</span>
The AMS header field has the same syntax and semantics as the DKIM-
Signature field [<a href="./rfc6376" title=""DomainKeys Identified Mail (DKIM) Signatures"">RFC6376</a>], with three (3) differences:
o the name of the header field itself;
o no version tag ("v") is defined for the AMS header field. As
required for undefined tags (in [<a href="./rfc6376" title=""DomainKeys Identified Mail (DKIM) Signatures"">RFC6376</a>]), if seen, a version tag
MUST be ignored; and
o 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 <a href="#section-4.2.1">Section 4.2.1</a>.
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:
o 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.
o Authentication-Results header fields MUST NOT be included in AMS
signatures as they are likely to be deleted by downstream ADMDs
(per <a href="./rfc8601#section-5">[RFC8601], Section 5</a>).
o 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.
<span class="grey">Andersen, et al. Experimental [Page 10]</span><span id="page-11" ></span>
<span class="grey"><a href="./rfc8617">RFC 8617</a> The ARC Protocol July 2019</span>
<span class="h4"><a class="selflink" id="section-4.1.3" href="#section-4.1.3">4.1.3</a>. ARC-Seal (AS)</span>
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 [<a href="./rfc6376" title=""DomainKeys Identified Mail (DKIM) Signatures"">RFC6376</a>], with the following differences:
o the "i" (AUID) tag is not imported from DKIM; instead, this tag is
replaced by the instance tag as defined in <a href="#section-4.2.1">Section 4.2.1</a>;
o 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 <a href="#section-5.1.1">Section 5.1.1</a>;
o no body canonicalization is performed as the AS signature does not
cover the body of a message;
o only "relaxed" header field canonicalization (<a href="./rfc6376#section-3.4.2">[RFC6376],
Section 3.4.2</a>) is used;
o the only supported tags are "i" (from <a href="#section-4.2.1">Section 4.2.1</a> of this
document), and "a", "b", "d", "s", and "t" from <a href="./rfc6376#section-3.5">[RFC6376],
Section 3.5</a>. 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 <a href="#section-5.1.1">Section 5.1.1</a>); and
o 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
<span class="grey">Andersen, et al. Experimental [Page 11]</span><span id="page-12" ></span>
<span class="grey"><a href="./rfc8617">RFC 8617</a> The ARC Protocol July 2019</span>
<span class="h4"><a class="selflink" id="section-4.1.4" href="#section-4.1.4">4.1.4</a>. Internationalized Email (EAI)</span>
In internationalized messages [<a href="./rfc6532" title=""Internationalized Email Headers"">RFC6532</a>], many header fields can
contain UTF-8 as well as ASCII text. The changes for EAI are all
inherited from DKIM as updated by [<a href="./rfc8616" title=""Email Authentication for Internationalized Mail"">RFC8616</a>] and Authentication-
Results (A-R) as updated in [<a href="./rfc8601" title=""Message Header Field for Indicating Message Authentication Status"">RFC8601</a>], but they are 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 [<a href="./rfc8601" title=""Message Header Field for Indicating Message Authentication Status"">RFC8601</a>].
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. ARC Set</span>
An "ARC Set" is a single collection of three ARC header fields (AAR,
AMS, and AS). ARC header fields of an ARC Set share the same
"instance" value.
By adding all ARC header fields to a message, an ARC Sealer adds an
ARC Set to a message. A description of how Sealers add an ARC Set to
a message is found in <a href="#section-5.1">Section 5.1</a>.
<span class="h4"><a class="selflink" id="section-4.2.1" href="#section-4.2.1">4.2.1</a>. Instance Tags</span>
Instance tags describe which ARC header fields belong to an ARC Set.
Each ARC header field of an ARC Set shares the same instance tag
value.
Instance tag values are integers that begin at 1 and are incremented
by each addition of an ARC Set. Through the incremental values of
instance tags, an ARC Validator can determine the order in which ARC
Sets were added to a message.
Instance tag values can range from 1-50 (inclusive).
_INFORMATIONAL_: The upper limit of 50 was picked based on some
initial observations reported by early working group members. The
value was chosen to balance the risk of excessive header field growth
(see <a href="#section-9.1">Section 9.1</a>) against expert opinion regarding the probability of
long-tail, but non-looping, multiple-intermediary mail flows. Longer
ARC Chains will also impose a load on Validators and DNS to support
additional verification steps. Observed quantities of "Received"
header fields were also considered in establishing this as an
experimental initial value.
<span class="grey">Andersen, et al. Experimental [Page 12]</span><span id="page-13" ></span>
<span class="grey"><a href="./rfc8617">RFC 8617</a> The ARC Protocol July 2019</span>
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 [<a href="#ref-ARC-MULTI">ARC-MULTI</a>].
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Authenticated Received Chain</span>
An Authenticated Received Chain is an ordered collection of ARC Sets.
As ARC Sets are enumerated sets of ARC header fields, an
Authenticated Received Chain represents the output of message
authentication assessments along the handling path of ARC-enabled
processors.
Authentication assessments determined at each step of the ARC-enabled
handling path are present in an Authenticated Received Chain in the
form of AAR header fields. The ability to verify the identity of
message handlers and the integrity of message content is provided by
AMS header fields. AS header fields allow message handlers to
validate the assertions, order, and sequence of the Authenticated
Received Chain itself.
In general concept terms, an Authenticated Received Chain represents
a message's chain of custody. Validators can consult a message's
chain of custody to gain insight regarding each custodian of a
message and the evidence collected by each custodian.
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. Chain Validation Status</span>
The state of the Authenticated Received Chain at a specific
processing step is called the "Chain Validation Status". Chain
Validation Status information is communicated in several ways:
o as the AS header field in the "cv" tag and
o as part of the Authentication-Results and AAR header field(s).
Chain Validation Status has one of three possible values:
o none: There was no Authenticated Received Chain on the message
when it arrived for validation. Typically, this occurs when a
message is received directly from a message's original Message
Transfer Agent (MTA) or Message Submission Agent (MSA), or from an
upstream Internet Mail Handler that is not participating in ARC
handling.
o fail: The message contains an Authenticated Received Chain whose
validation failed.
<span class="grey">Andersen, et al. Experimental [Page 13]</span><span id="page-14" ></span>
<span class="grey"><a href="./rfc8617">RFC 8617</a> The ARC Protocol July 2019</span>
o pass: The message contains an Authenticated Received Chain whose
validation succeeded.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Protocol Actions</span>
ARC-enabled Internet Mail Handlers generally act as both ARC
Validators (when receiving messages) and ARC Sealers (when sending
messages onward, not originated locally).
An Authenticated Received Chain with a Chain Validation Status of
"pass" (or "none") allows Internet Mail Handlers to ascertain:
o all ARC-participating ADMDs that claim responsibility for handling
(and possibly modifying) the message in transit and
o the authentication assessments of the message as determined by
each ADMD (from AAR header fields).
With this information, Internet Mail Handlers MAY inform local policy
decisions regarding disposition of messages that experience
authentication failure due to intermediate processing.
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Sealer Actions</span>
To "seal" a message, an ARC Sealer adds an ARC Set (the three ARC
header fields AAR, AMS, and AS) to a message. 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 presented with
a message:
1. All message modifications (including adding a DKIM-Signature
header field(s)) MUST be performed before sealing.
2. If the message already contains an Authenticated Received Chain
with the most recent AS reporting "cv=fail", there is no need to
proceed and the algorithm stops here.
3. Calculate the instance value. If the message already contains an
Authenticated Received Chain, the instance value is 1 more than
the highest instance number found in the Authenticated Received
Chain. If no Authenticated Received Chain exists, the instance
value is 1.
<span class="grey">Andersen, et al. Experimental [Page 14]</span><span id="page-15" ></span>
<span class="grey"><a href="./rfc8617">RFC 8617</a> The ARC Protocol July 2019</span>
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 <a href="#section-4.1.1">Section 4.1.1</a>.
B. Generate and attach an ARC-Message-Signature header field as
defined in <a href="#section-4.1.2">Section 4.1.2</a>.
C. Generate and attach an ARC-Seal header field using the AS
definition found in <a href="#section-4.1.3">Section 4.1.3</a>, the prescribed headers
defined in <a href="#section-5.1.1">Section 5.1.1</a>, and the Chain Validation Status as
determined during ARC validation.
<span class="h4"><a class="selflink" id="section-5.1.1" href="#section-5.1.1">5.1.1</a>. Header Fields to Include in ARC-Seal Signatures</span>
The ARC-Seal is generated in a manner similar to how DKIM-Signature
header fields are added to messages (<a href="./rfc6376#section-3.7">[RFC6376], Section 3.7</a>), with
explicit requirements on the header fields and ordering of those
fields.
The signature of an AS header field signs a canonicalized form of the
ARC Set header field values. The ARC Set header field values are
supplied to the hash function in increasing instance order, starting
at 1, and include the ARC Set being added at the time of sealing the
message.
Within an ARC Set, header fields are supplied to the hash function in
the following 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
<a href="#section-5.1.2">Section 5.1.2</a>.
<span class="h4"><a class="selflink" id="section-5.1.2" href="#section-5.1.2">5.1.2</a>. Marking and Sealing "cv=fail" (Invalid) Chains</span>
In 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.
<span class="grey">Andersen, et al. Experimental [Page 15]</span><span id="page-16" ></span>
<span class="grey"><a href="./rfc8617">RFC 8617</a> The ARC Protocol July 2019</span>
_INFORMATIONAL_: This approach is mandated to handle the case of a
malformed or otherwise invalid Authenticated Received Chain. There
is no way to generate a deterministic set of AS header fields
(<a href="#section-5.1.1">Section 5.1.1</a>) in most cases of invalid chains.
<span class="h4"><a class="selflink" id="section-5.1.3" href="#section-5.1.3">5.1.3</a>. Only One Authenticated Received Chain per Message</span>
A message can have only one Authenticated Received Chain on it at a
time. Once broken, the chain cannot be continued, as the chain of
custody is no longer valid, and responsibility for the message has
been lost. For further discussion of this topic and the design
restriction that prevents chain continuation or re-establishment, see
[<a href="#ref-ARC-USAGE">ARC-USAGE</a>].
<span class="h4"><a class="selflink" id="section-5.1.4" href="#section-5.1.4">5.1.4</a>. Broad Ability to Seal</span>
ARC is not solely intended for perimeter MTAs. Any 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.
For additional information, see <a href="#section-7.1">Section 7.1</a>.
<span class="h4"><a class="selflink" id="section-5.1.5" href="#section-5.1.5">5.1.5</a>. Sealing Is Always Safe</span>
The utility of an Authenticated Received Chain is limited to very
specific cases. Authenticated Received Chains are designed to
provide additional information to an Internet Mail Handler when
evaluating messages for delivery in the context of authentication
failures. Specifically:
o Properly adding an ARC Set to a message does not damage or
invalidate an existing Authenticated Received Chain.
o Sealing an Authenticated Received Chain when a message has not
been modified does not negatively affect the chain.
o Validating a message exposes no new threat vectors (see
<a href="#section-9">Section 9</a>).
o An ADMD may choose to seal all inbound messages whether or not a
message has been modified or will be retransmitted.
<span class="grey">Andersen, et al. Experimental [Page 16]</span><span id="page-17" ></span>
<span class="grey"><a href="./rfc8617">RFC 8617</a> The ARC Protocol July 2019</span>
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Validator Actions</span>
A Validator performs the following steps, in sequence, to process an
Authenticated Received Chain. Canonicalization, hash functions, and
signature validation methods are imported from <a href="./rfc6376#section-5">[RFC6376], Section 5</a>.
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 the following conditions:
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.
4. 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.
<span class="grey">Andersen, et al. Experimental [Page 17]</span><span id="page-18" ></span>
<span class="grey"><a href="./rfc8617">RFC 8617</a> The ARC Protocol July 2019</span>
5. _OPTIONAL_: Determine the "oldest-pass" value from the ARC Set by
validating each prior AMS beginning with N-1 and proceeding in
decreasing order to the AMS with the instance value of 1:
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).
6. Validate each AS beginning 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.
7. 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.
As with a DKIM signature (<a href="./rfc6376#section-6.3">[RFC6376], Section 6.3</a>) 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.
_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; many
intermediaries will continue to modify messages without adding ARC
seals.
<span class="h4"><a class="selflink" id="section-5.2.1" href="#section-5.2.1">5.2.1</a>. All Failures Are Permanent</span>
Authenticated Received Chains represent the traversal of messages
through one or more intermediaries. All errors, including DNS
failures, become unrecoverable and are considered permanent.
Any error validating an Authenticated Received Chain results in a
Chain Validation Status of "fail". For further discussion of this
topic and the design restriction that prevents chain continuation or
re-establishment, see [<a href="#ref-ARC-USAGE">ARC-USAGE</a>].
<span class="grey">Andersen, et al. Experimental [Page 18]</span><span id="page-19" ></span>
<span class="grey"><a href="./rfc8617">RFC 8617</a> The ARC Protocol July 2019</span>
<span class="h4"><a class="selflink" id="section-5.2.2" href="#section-5.2.2">5.2.2</a>. Responding to ARC Validation Failures during the SMTP</span>
<span class="h4"> Transaction</span>
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.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Communication of Validation Results</span>
Chain Validation Status (described in <a href="#section-4.4">Section 4.4</a>) is communicated
via Authentication-Results (and AAR) header fields using the
authentication method "arc". This authentication method is described
in <a href="#section-10.1">Section 10.1</a>.
If necessary data is available, the ptypes and properties defined in
<a href="#section-10.2">Section 10.2</a> SHOULD be recorded in an Authentication-Results header
field:
o smtp.remote-ip - The address of the connection-initiating SMTP
server, from which the message is being relayed.
o header.oldest-pass - The instance number of the oldest AMS that
still validates, or 0 if all pass.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Use Cases</span>
This section explores several message handling use cases that are
addressed by ARC.
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Communicate Authentication Assessment across Trust Boundaries</span>
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.
If ARC-enabled ADMDs are trusted, Authenticated Received Chains can
be used to bridge administrative boundaries.
<span class="grey">Andersen, et al. Experimental [Page 19]</span><span id="page-20" ></span>
<span class="grey"><a href="./rfc8617">RFC 8617</a> The ARC Protocol July 2019</span>
<span class="h4"><a class="selflink" id="section-7.1.1" href="#section-7.1.1">7.1.1</a>. Message-Scanning Services</span>
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).
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).
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.
<span class="h4"><a class="selflink" id="section-7.1.2" href="#section-7.1.2">7.1.2</a>. Multi-tier MTA Processing</span>
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.
Authenticated Received Chains can be used to communicate
authentication assessment between processing tiers.
<span class="h4"><a class="selflink" id="section-7.1.3" href="#section-7.1.3">7.1.3</a>. Mailing Lists</span>
Mailing lists take delivery of messages and repost them to
subscribers. A full description of authentication-related mailing
list issues can be found in <a href="./rfc7960#section-3.2.3">[RFC7960], Section 3.2.3</a>.
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.
<span class="grey">Andersen, et al. Experimental [Page 20]</span><span id="page-21" ></span>
<span class="grey"><a href="./rfc8617">RFC 8617</a> The ARC Protocol July 2019</span>
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Inform Message Disposition Decisions</span>
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).
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.
An Authenticated Received Chain allows an Internet Mail Handler to
potentially base decisions of message disposition on authentication
assessments provided by different ADMDs.
<span class="h4"><a class="selflink" id="section-7.2.1" href="#section-7.2.1">7.2.1</a>. DMARC Local Policy Overrides</span>
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 [<a href="./rfc7960" title=""Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows"">RFC7960</a>].
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.
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 <a href="#section-7.2.2">Section 7.2.2</a>.
<span class="grey">Andersen, et al. Experimental [Page 21]</span><span id="page-22" ></span>
<span class="grey"><a href="./rfc8617">RFC 8617</a> The ARC Protocol July 2019</span>
<span class="h4"><a class="selflink" id="section-7.2.2" href="#section-7.2.2">7.2.2</a>. DMARC Reporting</span>
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 <a href="./rfc7489#appendix-C">[RFC7489], Appendix C</a>) containing a list
of data discovered during ARC validation, which at a minimum
includes:
o the Chain Validation Status,
o the domain and selector for each AS, and
o 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).
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.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Privacy Considerations</span>
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.
<span class="grey">Andersen, et al. Experimental [Page 22]</span><span id="page-23" ></span>
<span class="grey"><a href="./rfc8617">RFC 8617</a> The ARC Protocol July 2019</span>
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Security Considerations</span>
The Security Considerations of [<a href="./rfc6376" title=""DomainKeys Identified Mail (DKIM) Signatures"">RFC6376</a>] and [<a href="./rfc8601" title=""Message Header Field for Indicating Message Authentication Status"">RFC8601</a>] apply directly
to this specification.
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.
<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>. Increased Header Field Size</span>
Inclusion of Authenticated Received Chains into messages may cause
issues for older or constrained MTAs due to increased total header
field size. Large header field blocks, in general, may cause
failures to deliver or other outage scenarios for such MTAs. ARC
itself would not cause problems.
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. DNS Operations</span>
The validation of an Authenticated Received Chain composed of N ARC
Sets can require up to 2*N DNS queries (not including any DNS
redirection mechanisms that can increase the total number of
queries). This leads to two considerations:
1. An attacker can send a message to an ARC participant with a
concocted sequence of ARC Sets bearing the domains of intended
victims, and all of them will be queried by the participant until
a failure is discovered. DNS caching and the difficulty of
forging the signature values should limit the extent of this load
to domains under control of the attacker. Query traffic pattern
analysis may expose information about a downstream validating
ADMD infrastructure.
<span class="grey">Andersen, et al. Experimental [Page 23]</span><span id="page-24" ></span>
<span class="grey"><a href="./rfc8617">RFC 8617</a> The ARC Protocol July 2019</span>
2. DKIM only performs one DNS query per signature, while ARC can
introduce many (per chain). Absent caching, slow DNS responses
can cause SMTP timeouts and backlogged delivery queues on
validating systems. This could be exploited as a DoS attack.
<span class="h3"><a class="selflink" id="section-9.3" href="#section-9.3">9.3</a>. Message Content Suspicion</span>
Recipients are cautioned to treat messages bearing Authenticated
Received Chains with the same suspicion applied to all other
messages. This includes appropriate 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 their trustworthiness.
Just as passing message authentication is not an indication of
message safety, forwarding that information through the mechanism of
ARC is also not an indication of message safety. Even if all ARC-
enabled ADMDs are trusted, ADMDs may have become compromised, may
miss unsafe content, or may not properly authenticate messages.
<span class="h3"><a class="selflink" id="section-9.4" href="#section-9.4">9.4</a>. Message Sealer Suspicion</span>
Recipients are cautioned to treat every Sealer of the ARC Chain with
suspicion. Just as with a validated DKIM signature, responsibility
for message handling is attributed to the sealing domain, but whether
or not that Sealer is a malicious actor is out of scope of the
authentication mechanism. Since ARC aids message delivery in the
event of an authentication failure, ARC Sealers should be treated
with suspicion, so that a malicious actor cannot seal spam or other
fraudulent messages to aid their delivery, too.
<span class="h3"><a class="selflink" id="section-9.5" href="#section-9.5">9.5</a>. Replay Attacks</span>
Since ARC inherits heavily from DKIM, it has similar attack vectors.
In particular, the replay attack described in <a href="./rfc6376#section-8.6">[RFC6376], Section 8.6</a>
is potentially amplified by ARC's chained statuses. In an ARC replay
attack, a malicious actor would take an intact and passing ARC Chain
and resend it to many recipients without making any modifications
that invalidate the latest AMS or AS. The impact to 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 <a href="./rfc6376#section-5.4.1">[RFC6376], Section 5.4.1</a>.
<span class="grey">Andersen, et al. Experimental [Page 24]</span><span id="page-25" ></span>
<span class="grey"><a href="./rfc8617">RFC 8617</a> The ARC Protocol July 2019</span>
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. IANA Considerations</span>
This document defines one new authentication method and several
status codes (<a href="#section-10.1">Section 10.1</a>), new ptypes and properties
(<a href="#section-10.2">Section 10.2</a>), three new headers fields (<a href="#section-10.3">Section 10.3</a>), and a new
enumerated status code (<a href="#section-10.4">Section 10.4</a>).
<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>. Update to Email Authentication Result Names Registry</span>
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: <a href="./rfc8617#section-4.4">RFC 8617, Section 4.4</a>
Status: active
<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>. Update to Email Authentication Methods Registry</span>
Per this document, IANA has added the following to the "Email
Authentication Methods" registry, which is defined in [<a href="./rfc8601" title=""Message Header Field for Indicating Message Authentication Status"">RFC8601</a>]:
o Method: arc
Definition: <a href="./rfc8617#section-6">RFC 8617, Section 6</a>
ptype: smtp
Property: remote-ip
Value: IP address (v4 or v6) of originating SMTP connection
Status: active
Version: 1
o Method: arc
Definition: <a href="./rfc8617#section-6">RFC 8617, Section 6</a>
ptype: header
Property: oldest-pass
Value: The instance id of the oldest validating AMS or 0 if they
all pass (see <a href="#section-5.2">Section 5.2</a>)
Status: active
Version: 1
<span class="grey">Andersen, et al. Experimental [Page 25]</span><span id="page-26" ></span>
<span class="grey"><a href="./rfc8617">RFC 8617</a> The ARC Protocol July 2019</span>
<span class="h3"><a class="selflink" id="section-10.3" href="#section-10.3">10.3</a>. New Header Fields in Permanent Message Header Field Registry</span>
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): <a href="./rfc8617">RFC 8617</a>
Related information: <a href="./rfc6376">RFC 6376</a>
o Header field name: ARC-Message-Signature
Applicable protocol: mail
Status: experimental
Author/Change controller: IETF
Specification document(s): <a href="./rfc8617">RFC 8617</a>
Related information: <a href="./rfc6376">RFC 6376</a>
o Header field name: ARC-Authentication-Results
Applicable protocol: mail
Status: experimental
Author/Change controller: IETF
Specification document(s): <a href="./rfc8617">RFC 8617</a>
Related information: <a href="./rfc8601">RFC 8601</a>
<span class="h3"><a class="selflink" id="section-10.4" href="#section-10.4">10.4</a>. New Status Code in Enumerated Status Codes Registry</span>
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: <a href="./rfc8617">RFC 8617</a>
Submitter: K. Andersen
Change controller: IESG
<span class="grey">Andersen, et al. Experimental [Page 26]</span><span id="page-27" ></span>
<span class="grey"><a href="./rfc8617">RFC 8617</a> The ARC Protocol July 2019</span>
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. Experimental Considerations</span>
The ARC protocol is designed to address common interoperability
issues introduced by intermediate message handlers. Interoperability
issues are described in [<a href="./rfc6377" title=""DomainKeys Identified Mail (DKIM) and Mailing Lists"">RFC6377</a>] and [<a href="./rfc7960" title=""Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows"">RFC7960</a>].
As the ARC protocol is implemented by Internet Mail Handlers over
time, the following should be evaluated in order to determine the
success of the protocol in accomplishing the intended benefits.
<span class="h3"><a class="selflink" id="section-11.1" href="#section-11.1">11.1</a>. Success Consideration</span>
In an attempt to deliver legitimate messages that users desire, many
receivers use heuristic-based methods to identify messages that
arrive via indirect delivery paths.
ARC will be a success if the presence of Authenticated Received
Chains allows for improved decision making when processing legitimate
messages, specifically resulting in equal or better delivery rates
than achieved through the use of heuristic approaches.
<span class="h3"><a class="selflink" id="section-11.2" href="#section-11.2">11.2</a>. Failure Considerations</span>
ARC should function without introducing significant new vectors for
abuse (see <a href="#section-9">Section 9</a>). If unforeseen vectors are enabled by ARC,
this protocol will be a failure. Note that the weaknesses inherent
in the mail protocols ARC is built upon (such as DKIM replay attacks
and other known issues) are not new vectors that can be attributed to
this specification.
<span class="h3"><a class="selflink" id="section-11.3" href="#section-11.3">11.3</a>. Open Questions</span>
The following open questions are academic and have no clear answer at
the time this document was published. However, additional
deployments should be able to gather the necessary data to answer
some or all of them.
<span class="h4"><a class="selflink" id="section-11.3.1" href="#section-11.3.1">11.3.1</a>. Value of the ARC-Seal (AS) Header Field</span>
Data should be collected to show if the AS provides value beyond the
AMS for either making delivery decisions or catching malicious actors
trying to craft or replay malicious chains.
<span class="grey">Andersen, et al. Experimental [Page 27]</span><span id="page-28" ></span>
<span class="grey"><a href="./rfc8617">RFC 8617</a> The ARC Protocol July 2019</span>
<span class="h4"><a class="selflink" id="section-11.3.2" href="#section-11.3.2">11.3.2</a>. Usage and/or Signals from Multiple Selectors and/or Domains in</span>
<span class="h4"> ARC Sets</span>
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, no compelling argument for or against such
usage has been made within the working group. As such, we have
chosen 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.
<span class="h4"><a class="selflink" id="section-11.3.3" href="#section-11.3.3">11.3.3</a>. DNS Overhead</span>
Longer Authenticated Received Chains will require more queries to
retrieve the keys for validating the chain. While this is not
believed to be a security issue (see <a href="#section-9.2">Section 9.2</a>), it is unclear how
much overhead will truly be added. This is similar to some of the
initial processing and query load concerns that were debated at the
time of the DKIM specification development.
Data should be collected to better understand usable length and
distribution of lengths found in valid Authenticated Received Chains
along with the DNS impact of processing Authenticated Received
Chains.
An effective operational maximum will have to be developed through
deployment experience in the field.
<span class="h4"><a class="selflink" id="section-11.3.4" href="#section-11.3.4">11.3.4</a>. What Trace Information Is Valuable?</span>
There are several edge cases where the information in the AAR can
make the difference between message delivery or rejection. For
example, if there is a well-known mailing list that seals with ARC
but doesn't do its own initial DMARC enforcement, an Internet Mail
Handler with this knowledge could make a delivery decision based upon
the authentication information it sees in the corresponding AAR
header field.
Certain trace information in the AAR is useful/necessary in the
construction of DMARC reports.
<span class="grey">Andersen, et al. Experimental [Page 28]</span><span id="page-29" ></span>
<span class="grey"><a href="./rfc8617">RFC 8617</a> The ARC Protocol July 2019</span>
Further, certain receivers 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.
At this point, however, it is unclear what trace information will be
valuable for all receivers, regardless of size.
Data should be collected on what trace information receivers are
using that provides useful signals that affect deliverability and
what 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 the landscape of "useful" information over time.
<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>. References</span>
<span class="h3"><a class="selflink" id="section-12.1" href="#section-12.1">12.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
DOI 10.17487/RFC2119, March 1997,
<<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC5234">RFC5234</a>] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, <a href="./rfc5234">RFC 5234</a>,
DOI 10.17487/RFC5234, January 2008,
<<a href="https://www.rfc-editor.org/info/rfc5234">https://www.rfc-editor.org/info/rfc5234</a>>.
[<a id="ref-RFC5322">RFC5322</a>] Resnick, P., Ed., "Internet Message Format", <a href="./rfc5322">RFC 5322</a>,
DOI 10.17487/RFC5322, October 2008,
<<a href="https://www.rfc-editor.org/info/rfc5322">https://www.rfc-editor.org/info/rfc5322</a>>.
[<a id="ref-RFC5598">RFC5598</a>] Crocker, D., "Internet Mail Architecture", <a href="./rfc5598">RFC 5598</a>,
DOI 10.17487/RFC5598, July 2009,
<<a href="https://www.rfc-editor.org/info/rfc5598">https://www.rfc-editor.org/info/rfc5598</a>>.
[<a id="ref-RFC6376">RFC6376</a>] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
<a href="./rfc6376">RFC 6376</a>, DOI 10.17487/RFC6376, September 2011,
<<a href="https://www.rfc-editor.org/info/rfc6376">https://www.rfc-editor.org/info/rfc6376</a>>.
[<a id="ref-RFC6377">RFC6377</a>] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and
Mailing Lists", <a href="https://www.rfc-editor.org/bcp/bcp167">BCP 167</a>, <a href="./rfc6377">RFC 6377</a>, DOI 10.17487/RFC6377,
September 2011, <<a href="https://www.rfc-editor.org/info/rfc6377">https://www.rfc-editor.org/info/rfc6377</a>>.
<span class="grey">Andersen, et al. Experimental [Page 29]</span><span id="page-30" ></span>
<span class="grey"><a href="./rfc8617">RFC 8617</a> The ARC Protocol July 2019</span>
[<a id="ref-RFC6532">RFC6532</a>] Yang, A., Steele, S., and N. Freed, "Internationalized
Email Headers", <a href="./rfc6532">RFC 6532</a>, DOI 10.17487/RFC6532, February
2012, <<a href="https://www.rfc-editor.org/info/rfc6532">https://www.rfc-editor.org/info/rfc6532</a>>.
[<a id="ref-RFC7208">RFC7208</a>] Kitterman, S., "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1", <a href="./rfc7208">RFC 7208</a>,
DOI 10.17487/RFC7208, April 2014,
<<a href="https://www.rfc-editor.org/info/rfc7208">https://www.rfc-editor.org/info/rfc7208</a>>.
[<a id="ref-RFC7405">RFC7405</a>] Kyzivat, P., "Case-Sensitive String Support in ABNF",
<a href="./rfc7405">RFC 7405</a>, DOI 10.17487/RFC7405, December 2014,
<<a href="https://www.rfc-editor.org/info/rfc7405">https://www.rfc-editor.org/info/rfc7405</a>>.
[<a id="ref-RFC8174">RFC8174</a>] Leiba, B., "Ambiguity of Uppercase vs Lowercase in <a href="./rfc2119">RFC</a>
<a href="./rfc2119">2119</a> Key Words", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc8174">RFC 8174</a>, DOI 10.17487/RFC8174,
May 2017, <<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>>.
[<a id="ref-RFC8601">RFC8601</a>] Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", <a href="./rfc8601">RFC 8601</a>,
DOI 10.17487/RFC8601, May 2019,
<<a href="https://www.rfc-editor.org/info/rfc8601">https://www.rfc-editor.org/info/rfc8601</a>>.
[<a id="ref-RFC8616">RFC8616</a>] Levine, J., "Email Authentication for Internationalized
Mail", <a href="./rfc8616">RFC 8616</a>, DOI 10.17487/RFC8616, June 2019,
<<a href="https://www.rfc-editor.org/info/rfc8616">https://www.rfc-editor.org/info/rfc8616</a>>.
<span class="h3"><a class="selflink" id="section-12.2" href="#section-12.2">12.2</a>. Informative References</span>
[<a id="ref-ARC-MULTI">ARC-MULTI</a>]
Andersen, K., Blank, S., Ed., and J. Levine, Ed., "Using
Multiple Signing Algorithms with the ARC (Authenticated
Received Chain) Protocol", Work in Progress, <a href="./draft-ietf-dmarc-arc-multi-03">draft-ietf-</a>
<a href="./draft-ietf-dmarc-arc-multi-03">dmarc-arc-multi-03</a>, March 2019.
[<a id="ref-ARC-USAGE">ARC-USAGE</a>]
Jones, S., Ed. and K. Andersen, "Recommended Usage of the
Authenticated Received Chain (ARC)", Work in Progress,
<a href="./draft-ietf-dmarc-arc-usage-07">draft-ietf-dmarc-arc-usage-07</a>, April 2019.
[<a id="ref-RFC7489">RFC7489</a>] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
Message Authentication, Reporting, and Conformance
(DMARC)", <a href="./rfc7489">RFC 7489</a>, DOI 10.17487/RFC7489, March 2015,
<<a href="https://www.rfc-editor.org/info/rfc7489">https://www.rfc-editor.org/info/rfc7489</a>>.
<span class="grey">Andersen, et al. Experimental [Page 30]</span><span id="page-31" ></span>
<span class="grey"><a href="./rfc8617">RFC 8617</a> The ARC Protocol July 2019</span>
[<a id="ref-RFC7960">RFC7960</a>] 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",
<a href="./rfc7960">RFC 7960</a>, DOI 10.17487/RFC7960, September 2016,
<<a href="https://www.rfc-editor.org/info/rfc7960">https://www.rfc-editor.org/info/rfc7960</a>>.
<span class="grey">Andersen, et al. Experimental [Page 31]</span><span id="page-32" ></span>
<span class="grey"><a href="./rfc8617">RFC 8617</a> The ARC Protocol July 2019</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Design Requirements</span>
The specification of the ARC framework is driven by the following
high-level goals, security considerations, and practical operational
requirements.
<span class="h3"><a class="selflink" id="appendix-A.1" href="#appendix-A.1">A.1</a>. Primary Design Criteria</span>
o Provide a verifiable "chain of custody" for email messages;
o Not require changes for originators of email;
o Support the verification of the ARC header field set by each hop
in the handling chain;
o Work at Internet scale; and
o Provide a trustable mechanism for the communication of
Authentication-Results across trust boundaries.
<span class="h3"><a class="selflink" id="appendix-A.2" href="#appendix-A.2">A.2</a>. Out of Scope</span>
ARC is not a trust framework. Users of the ARC header fields are
cautioned against making unsubstantiated conclusions when
encountering a "broken" ARC sequence.
<span class="grey">Andersen, et al. Experimental [Page 32]</span><span id="page-33" ></span>
<span class="grey"><a href="./rfc8617">RFC 8617</a> The ARC Protocol July 2019</span>
<span class="h2"><a class="selflink" id="appendix-B" href="#appendix-B">Appendix B</a>. Example Usage</span>
The following message is an example of one that has passed through
several intermediary handlers, some of which have modified the
message and others which have not:
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 [email protected])
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 [email protected])
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
[email protected]; dkim=fail (512-bit key)
[email protected]; 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
[email protected]; dkim=fail (512-bit key)
[email protected]; 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
<span class="grey">Andersen, et al. Experimental [Page 33]</span><span id="page-34" ></span>
<span class="grey"><a href="./rfc8617">RFC 8617</a> The ARC Protocol July 2019</span>
9WSqI9s9DfyKDfWg==
ARC-Authentication-Results: i=2; gmail.example; spf=fail
[email protected]; dkim=fail (512-bit key)
[email protected]; 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
[email protected]; dkim=pass (512-bit key)
[email protected]; 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: [email protected]
Subject: [List 2] Example 1
Hey gang,
This is a test message.
--J.
<span class="grey">Andersen, et al. Experimental [Page 34]</span><span id="page-35" ></span>
<span class="grey"><a href="./rfc8617">RFC 8617</a> The ARC Protocol July 2019</span>
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: [email protected]
Brandon Long (editor)
Google
Email: [email protected]
Seth Blank (editor)
Valimail
Email: [email protected]
Murray Kucherawy (editor)
TDP
Email: [email protected]
Andersen, et al. Experimental [Page 35]
Annotations
Select text to annotate