draft-ietf-dmarc-arc-protocol-23.txt   rfc8617.txt 
DMARC Working Group K. Andersen Internet Engineering Task Force (IETF) K. Andersen
Internet-Draft LinkedIn Request for Comments: 8617 LinkedIn
Intended status: Experimental B. Long, Ed. Category: Experimental B. Long, Ed.
Expires: June 21, 2019 Google ISSN: 2070-1721 Google
S. Blank, Ed. S. Blank, Ed.
Valimail Valimail
M. Kucherawy, Ed. M. Kucherawy, Ed.
TDP TDP
December 18, 2018 July 2019
Authenticated Received Chain (ARC) Protocol The Authenticated Received Chain (ARC) Protocol
draft-ietf-dmarc-arc-protocol-23
Abstract Abstract
The Authenticated Received Chain (ARC) protocol provides an The Authenticated Received Chain (ARC) protocol provides an
authenticated "chain of custody" for a message, allowing each entity authenticated "chain of custody" for a message, allowing each entity
that handles the message to see what entities handled it before, and that handles the message to see what entities handled it before and
to see what the message's authentication assessment was at each step what the message's authentication assessment was at each step in the
in the handling. handling.
ARC allows Internet Mail Handlers to attach assertions of message ARC allows Internet Mail Handlers to attach assertions of message
authentication assessment to individual messages. As messages authentication assessment to individual messages. As messages
traverse ARC-enabled Internet Mail Handlers, additional ARC traverse ARC-enabled Internet Mail Handlers, additional ARC
assertions can be attached to messages to form ordered sets of ARC assertions can be attached to messages to form ordered sets of ARC
assertions that represent the authentication assessment at each step assertions that represent the authentication assessment at each step
of message handling paths. of the message-handling paths.
ARC-enabled Internet Mail Handlers can process sets of ARC assertions ARC-enabled Internet Mail Handlers can process sets of ARC assertions
to inform message disposition decisions, to identify Internet Mail to inform message disposition decisions, identify Internet Mail
Handlers that might break existing authentication mechanisms, and to Handlers that might break existing authentication mechanisms, and
convey original authentication assessments across trust boundaries. convey original authentication assessments across trust boundaries.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for examination, experimental implementation, and
evaluation.
Internet-Drafts are working documents of the Internet Engineering This document defines an Experimental Protocol for the Internet
Task Force (IETF). Note that other groups may also distribute community. This document is a product of the Internet Engineering
working documents as Internet-Drafts. The list of current Internet- Task Force (IETF). It represents the consensus of the IETF
Drafts is at https://datatracker.ietf.org/drafts/current/. 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 Section 2 of RFC 7841.
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference https://www.rfc-editor.org/info/rfc8617.
material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 21, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. General Concepts . . . . . . . . . . . . . . . . . . . . . . 5 2. General Concepts . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Evidence . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Evidence . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Custody . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Custody . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Chain of Custody . . . . . . . . . . . . . . . . . . . . 5 2.3. Chain of Custody . . . . . . . . . . . . . . . . . . . . 6
2.4. Validation of Chain of Custody . . . . . . . . . . . . . 5 2.4. Validation of Chain of Custody . . . . . . . . . . . . . 6
3. Terminology and Definitions . . . . . . . . . . . . . . . . . 6 3. Terminology and Definitions . . . . . . . . . . . . . . . . . 6
3.1. ARC Set . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. ARC Set . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Authenticated Received Chain (ARC) . . . . . . . . . . . 7 3.2. Authenticated Received Chain (ARC) . . . . . . . . . . . 7
3.3. Internet Mail Handlers / Intermediaries . . . . . . . . . 7 3.3. Internet Mail Handlers / Intermediaries . . . . . . . . . 7
3.4. Authentication Assessment . . . . . . . . . . . . . . . . 7 3.4. Authentication Assessment . . . . . . . . . . . . . . . . 7
3.5. Signing vs Sealing . . . . . . . . . . . . . . . . . . . 7 3.5. Signing vs. Sealing . . . . . . . . . . . . . . . . . . . 8
3.6. Sealer . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.6. Sealer . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.7. Validator . . . . . . . . . . . . . . . . . . . . . . . . 8 3.7. Validator . . . . . . . . . . . . . . . . . . . . . . . . 8
3.8. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . 8 3.8. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . 8
3.9. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . 8 3.9. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . 8
4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 8 4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 9
4.1. ARC Header Fields . . . . . . . . . . . . . . . . . . . . 8 4.1. ARC Header Fields . . . . . . . . . . . . . . . . . . . . 9
4.1.1. ARC-Authentication-Results (AAR) . . . . . . . . . . 9 4.1.1. ARC-Authentication-Results (AAR) . . . . . . . . . . 9
4.1.2. ARC-Message-Signature (AMS) . . . . . . . . . . . . . 9 4.1.2. ARC-Message-Signature (AMS) . . . . . . . . . . . . . 9
4.1.3. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . 10 4.1.3. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . 11
4.1.4. Internationalized Email (EAI) . . . . . . . . . . . . 11 4.1.4. Internationalized Email (EAI) . . . . . . . . . . . . 12
4.2. ARC Set . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2. ARC Set . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.1. Instance Tags . . . . . . . . . . . . . . . . . . . . 12 4.2.1. Instance Tags . . . . . . . . . . . . . . . . . . . . 12
4.3. Authenticated Received Chain . . . . . . . . . . . . . . 12 4.3. Authenticated Received Chain . . . . . . . . . . . . . . 13
4.4. Chain Validation Status . . . . . . . . . . . . . . . . . 13 4.4. Chain Validation Status . . . . . . . . . . . . . . . . . 13
5. Protocol Actions . . . . . . . . . . . . . . . . . . . . . . 13 5. Protocol Actions . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Sealer Actions . . . . . . . . . . . . . . . . . . . . . 14 5.1. Sealer Actions . . . . . . . . . . . . . . . . . . . . . 14
5.1.1. Header Fields To Include In ARC-Seal Signatures . . . 15 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.2. Marking and Sealing "cv=fail" (Invalid) Chains . . . 15
5.1.3. Only One Authenticated Received Chain Per Message . . 15 5.1.3. Only One Authenticated Received Chain per Message . . 16
5.1.4. Broad Ability to Seal . . . . . . . . . . . . . . . . 16 5.1.4. Broad Ability to Seal . . . . . . . . . . . . . . . . 16
5.1.5. Sealing is Always Safe . . . . . . . . . . . . . . . 16 5.1.5. Sealing Is Always Safe . . . . . . . . . . . . . . . 16
5.2. Validator Actions . . . . . . . . . . . . . . . . . . . . 16 5.2. Validator Actions . . . . . . . . . . . . . . . . . . . . 17
5.2.1. All Failures Are Permanent . . . . . . . . . . . . . 18 5.2.1. All Failures Are Permanent . . . . . . . . . . . . . 18
5.2.2. Responding to ARC Validation Failures During the SMTP 5.2.2. Responding to ARC Validation Failures during the SMTP
Transaction . . . . . . . . . . . . . . . . . . . . . 18 Transaction . . . . . . . . . . . . . . . . . . . . . 19
6. Communication of Validation Results . . . . . . . . . . . . . 18 6. Communication of Validation Results . . . . . . . . . . . . . 19
7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Communicate Authentication Assessment Across Trust 7.1. Communicate Authentication Assessment across Trust
Boundaries . . . . . . . . . . . . . . . . . . . . . . . 19 Boundaries . . . . . . . . . . . . . . . . . . . . . . . 19
7.1.1. Message Scanning Services . . . . . . . . . . . . . . 19 7.1.1. Message-Scanning Services . . . . . . . . . . . . . . 20
7.1.2. Multi-tier MTA Processing . . . . . . . . . . . . . . 19 7.1.2. Multi-tier MTA Processing . . . . . . . . . . . . . . 20
7.1.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 20 7.1.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 20
7.2. Inform Message Disposition Decisions . . . . . . . . . . 20 7.2. Inform Message Disposition Decisions . . . . . . . . . . 21
7.2.1. DMARC Local Policy Overrides . . . . . . . . . . . . 20 7.2.1. DMARC Local Policy Overrides . . . . . . . . . . . . 21
7.2.2. DMARC Reporting . . . . . . . . . . . . . . . . . . . 21 7.2.2. DMARC Reporting . . . . . . . . . . . . . . . . . . . 22
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
9.1. Increased Header Field Size . . . . . . . . . . . . . . . 22 9.1. Increased Header Field Size . . . . . . . . . . . . . . . 23
9.2. DNS Operations . . . . . . . . . . . . . . . . . . . . . 22 9.2. DNS Operations . . . . . . . . . . . . . . . . . . . . . 23
9.3. Message Content Suspicion . . . . . . . . . . . . . . . . 23 9.3. Message Content Suspicion . . . . . . . . . . . . . . . . 24
9.4. Message Sealer Suspicion . . . . . . . . . . . . . . . . 23 9.4. Message Sealer Suspicion . . . . . . . . . . . . . . . . 24
9.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 23 9.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
10.1. Email Authentication Results Names Registry Update . . . 24 10.1. Update to Email Authentication Result Names Registry . . 25
10.2. Email Authentication Methods Registry Update . . . . . . 24 10.2. Update to Email Authentication Methods Registry . . . . 25
10.3. Definitions of the ARC header fields . . . . . . . . . . 24 10.3. New Header Fields in Permanent Message Header Field
10.4. New Enhanced Status Code - ARC Validation . . . . . . . 25 Registry . . . . . . . . . . . . . . . . . . . . . . . . 26
11. Experimental Considerations . . . . . . . . . . . . . . . . . 25 10.4. New Status Code in Enumerated Status Codes Registry . . 26
11.1. Success Consideration . . . . . . . . . . . . . . . . . 25 11. Experimental Considerations . . . . . . . . . . . . . . . . . 27
11.2. Failure Considerations . . . . . . . . . . . . . . . . . 26 11.1. Success Consideration . . . . . . . . . . . . . . . . . 27
11.3. Open Questions . . . . . . . . . . . . . . . . . . . . . 26 11.2. Failure Considerations . . . . . . . . . . . . . . . . . 27
11.3.1. Value of the ARC-Seal (AS) Header Field . . . . . . 26 11.3. Open Questions . . . . . . . . . . . . . . . . . . . . . 27
11.3.2. Usage and/or signals from multiple selectors and/or 11.3.1. Value of the ARC-Seal (AS) Header Field . . . . . . 27
domains in ARC sets . . . . . . . . . . . . . . . . 26 11.3.2. Usage and/or Signals from Multiple Selectors and/or
11.3.3. DNS Overhead . . . . . . . . . . . . . . . . . . . . 26 Domains in ARC Sets . . . . . . . . . . . . . . . . 28
11.3.4. What Trace Information is Valuable . . . . . . . . . 27 11.3.3. DNS Overhead . . . . . . . . . . . . . . . . . . . . 28
12. Implementation Status . . . . . . . . . . . . . . . . . . . . 27 11.3.4. What Trace Information Is Valuable? . . . . . . . . 28
12.1. GMail test reflector and incoming validation . . . . . . 28 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
12.2. AOL test reflector and internal tagging . . . . . . . . 28 12.1. Normative References . . . . . . . . . . . . . . . . . . 29
12.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 29 12.2. Informative References . . . . . . . . . . . . . . . . . 30
12.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . 29 Appendix A. Design Requirements . . . . . . . . . . . . . . . . 32
12.5. Mailman 3.x patch . . . . . . . . . . . . . . . . . . . 29 A.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 32
12.6. Copernica/MailerQ web-based validation . . . . . . . . . 30 A.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 32
12.7. Rspamd . . . . . . . . . . . . . . . . . . . . . . . . . 30 Appendix B. Example Usage . . . . . . . . . . . . . . . . . . . 32
12.8. PERL MAIL::DKIM module . . . . . . . . . . . . . . . . . 31 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 35
12.9. PERL Mail::Milter::Authentication module . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
12.10. Sympa List Manager . . . . . . . . . . . . . . . . . . . 32
12.11. Oracle Messaging Server . . . . . . . . . . . . . . . . 32
12.12. MessageSystems Momentum and PowerMTA platforms . . . . . 32
12.13. Exim . . . . . . . . . . . . . . . . . . . . . . . . . . 33
12.14. Halon MTA . . . . . . . . . . . . . . . . . . . . . . . 33
12.15. IIJ . . . . . . . . . . . . . . . . . . . . . . . . . . 33
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
13.1. Normative References . . . . . . . . . . . . . . . . . . 33
13.2. Informative References . . . . . . . . . . . . . . . . . 35
13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Appendix A. Design Requirements . . . . . . . . . . . . . . . . 36
A.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 36
A.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 37
Appendix B. Example Usage . . . . . . . . . . . . . . . . . . . 37
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 39
Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
The utility of widely deployed email authentication technologies such The utility of widely deployed email authentication technologies such
as Sender Policy Framework (SPF) [RFC7208] and DomainKeys Identified as Sender Policy Framework (SPF) [RFC7208] and DomainKeys Identified
Mail (DKIM) [RFC6376] is impacted by the processing of Internet Mail Mail (DKIM) [RFC6376] is impacted by the processing of Internet Mail
by intermediate handlers. This impact is thoroughly documented in by intermediate handlers. This impact is thoroughly documented in
the defining documents for SPF and DKIM and further discussed in the defining documents for SPF and DKIM and further discussed in
[RFC6377] and [RFC7960]. [RFC6377] and [RFC7960].
DMARC [RFC7489] also relies upon SPF and DKIM authentication Domain-based Message Authentication, Reporting, and Conformance
(DMARC) [RFC7489] also relies upon SPF and DKIM authentication
mechanisms. Failures of authentication caused by the actions of mechanisms. Failures of authentication caused by the actions of
intermediate handlers can cause legitimate mail to be incorrectly intermediate handlers can cause legitimate mail to be incorrectly
rejected or misdirected. rejected or misdirected.
Authenticated Received Chain (ARC) creates a mechanism for individual Authenticated Received Chain (ARC) creates a mechanism for individual
Internet Mail Handlers to add their authentication assessment to a Internet Mail Handlers to add their authentication assessment to a
message's ordered set of handling results. ARC encapsulates the message's ordered set of handling results. ARC encapsulates the
authentication assessment in a DKIM signature derivative to grant authentication assessment in a DKIM signature derivative to grant
other handlers the ability to verify the authenticity of the other handlers the ability to verify the authenticity of the
individual assessment assertion as well as the aggregate set and individual assessment assertion as well as the aggregate set and
sequence of results. sequence of results.
Ordered sets of authentication assessments can be used by ARC-enabled Ordered sets of authentication assessments can be used by ARC-enabled
Internet Mail Handlers to inform message handling disposition, to Internet Mail Handlers to inform message-handling disposition,
identify where alteration of message content might have occurred, and identify where alteration of message content might have occurred, and
to provide additional trace information for use in understanding provide additional trace information for use in understanding
message handling paths. message-handling paths.
2. General Concepts 2. General Concepts
ARC is loosely based on concepts from evidence collection. Evidence ARC is loosely based on concepts from evidence collection. Evidence
is usually collected, labeled, stored, and transported in specific is usually collected, labeled, stored, and transported in specific
ways to preserve the state of evidence and to document all processing ways to preserve the state of evidence and to document all processing
steps. steps.
2.1. Evidence 2.1. Evidence
In ARC's situation, the "evidence" is a message's authentication In ARC's situation, the "evidence" is a message's authentication
assessment at any point along the delivery path between origination assessment at any point along the delivery path between origination
and final delivery. Determination of message authentication can be and final delivery. Determination of message authentication can be
affected when intermediate handlers modify message content (header affected when intermediate handlers modify message content (header
fields and/or body content), route messages through unforeseen paths, fields and/or body content), route messages through unforeseen paths,
or change envelope information. or change envelope information.
The authentication assessment for a message is determined upon The authentication assessment for a message is determined upon
receipt of a message and documented in the Authentication-Results receipt of a message and documented in the Authentication-Results
header field(s). ARC extends this mechanism to survive transit header field(s). ARC extends this mechanism to survive transit
through intermediary ADMDs. through intermediary Administrative Management Domains (ADMDs).
Because the first-hand determination of an authentication assessment Because the first-hand determination of an authentication assessment
can never be reproduced by other handlers, the assertion of the can never be reproduced by other handlers, the assertion of the
authentication assessment is more akin to testimony by a verifiable authentication assessment is more akin to testimony by a verifiable
party than hard evidence which can be independently evaluated. party than to hard evidence, which can be independently evaluated.
2.2. Custody 2.2. Custody
"Custody" refers to when an Internet Mail Handler processes a "Custody" refers to when an Internet Mail Handler processes a
message. When a handler takes custody of a message, the handler message. When a handler takes custody of a message, the handler
becomes a custodian and attaches their own evidence (authentication becomes a custodian and attaches its own evidence (authentication
assessment upon receipt) to the message if they are ARC-enabled. assessment upon receipt) to the message if it is ARC enabled.
Evidence is added in such a way so that future handlers can verify Evidence is added in such a way that future handlers can verify the
the authenticity of both evidence and custody. authenticity of both evidence and custody.
2.3. Chain of Custody 2.3. Chain of Custody
The "chain of custody" of ARC is the entire set of evidence and The "chain of custody" of ARC is the entire set of evidence and
custody that travels with a message. custody that travels with a message.
2.4. Validation of Chain of Custody 2.4. Validation of Chain of Custody
Any ARC-enabled Internet Mail Handler can validate the entire set of Any ARC-enabled Internet Mail Handler can validate the entire set of
custody and the authentication assessments asserted by each party to custody and the authentication assessments asserted by each party to
yield a valid Chain of Custody. If the evidence-supplying custodians yield a valid chain of custody. If the evidence-supplying custodians
can be trusted, then the validated Chain of Custody describes the can be trusted, then the validated chain of custody describes the
(possibly changing) authentication assessment as the message traveled (possibly changing) authentication assessment as the message traveled
through various custodians. through various custodians.
Even though a message's authentication assessment might have changed, Even though a message's authentication assessment might have changed,
the validated chain of custody can be used to determine if the the validated chain of custody can be used to determine if the
changes (and the custodians responsible for the changes) can be changes (and the custodians responsible for the changes) can be
tolerated. tolerated.
3. Terminology and Definitions 3. Terminology and Definitions
skipping to change at page 6, line 23 skipping to change at page 6, line 37
Readers should to be familiar with the contents, core concepts, and Readers should to be familiar with the contents, core concepts, and
definitions found in [RFC5598]. The potential roles of transit definitions found in [RFC5598]. The potential roles of transit
services in the delivery of email are directly relevant. services in the delivery of email are directly relevant.
Language, syntax (including some ABNF constructs), and concepts are Language, syntax (including some ABNF constructs), and concepts are
imported from DKIM [RFC6376]. Specific references to DKIM are made imported from DKIM [RFC6376]. Specific references to DKIM are made
throughout this document. The following terms are imported from throughout this document. The following terms are imported from
[RFC5598]: [RFC5598]:
o ADministrative Management Domain (ADMD), Section 2.3 o Administrative Management Domain (ADMD), Section 2.3
o Message Transfer Agents (MTA), Section 4.3.2 o Message Transfer Agent (MTA), Section 4.3.2
o Message Submission Agent (MSA), Section 4.3.1 o Message Submission Agent (MSA), Section 4.3.1
o Message Delivery Agent (MDA), Section 4.3.3 o Message Delivery Agent (MDA), Section 4.3.3
Syntax descriptions use Augmented BNF (ABNF) [RFC5234] and [RFC7405]. Syntax descriptions use ABNF [RFC5234] [RFC7405].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. These words may also appear in this capitals, as shown here.
document in lower case as plain English words, absent their normative
meanings.
3.1. ARC Set 3.1. ARC Set
Section 4.1 introduces three (3) ARC header fields which are added to Section 4.1 introduces three (3) ARC header fields that are added to
a message by an ARC-enabled internet mail handler. Together, these a message by an ARC-enabled Internet Mail Handler. Together, these
three header fields compose a single "ARC Set". An ARC Set provides three header fields compose a single "ARC Set". An ARC Set provides
the means for an Internet Mail Handler to attach an authentication the means for an Internet Mail Handler to attach an authentication
assessment to a message in a manner that can be verified by future assessment to a message in a manner that can be verified by future
handlers. A single message can contain multiple ARC Sets. handlers. A single message can contain multiple ARC Sets.
In general concept terms, an ARC Set represents Evidence and Custody. In general concept terms, an ARC Set represents Evidence and Custody.
3.2. Authenticated Received Chain (ARC) 3.2. Authenticated Received Chain (ARC)
The sequence of ARC Sets attached to a message at a given time is The sequence of ARC Sets attached to a message at a given time is
called the Authenticated Received Chain. An Authenticated Received called the "Authenticated Received Chain" or "ARC". An Authenticated
Chain is the record of individual authentication assessments as a Received Chain is the record of individual authentication assessments
message traverses through ARC-participating ADMDs. as a message traverses through ARC-participating ADMDs.
The first attachment of an ARC Set to a message causes an The first attachment of an ARC Set to a message causes an
Authenticated Received Chain to be created. Additional attachments Authenticated Received Chain to be created. Additional attachments
of ARC Sets cause the Authenticated Received Chain to be extended. of ARC Sets cause the Authenticated Received Chain to be extended.
In General concept terms, an Authenticated Received Chain represents In general concept terms, an Authenticated Received Chain represents
Chain of Custody. a chain of custody.
3.3. Internet Mail Handlers / Intermediaries 3.3. Internet Mail Handlers / Intermediaries
Internet Mail Handlers process and deliver messages across the Internet Mail Handlers process and deliver messages across the
Internet and include MSAs, MTAs, MDAs, gateways, and mailing lists as Internet and include MSAs, MTAs, MDAs, gateways, and mailing lists as
defined in [RFC5598]. defined in [RFC5598].
Throughout this document the term "intermediaries" refers to the both Throughout this document, the term "intermediaries" refers to both
regular MTAs as well as delivery/reposting agents such as mailing regular MTAs as well as delivery/reposting agents such as mailing
lists covered within the scope of [RFC5598]'s transit services. lists covered within the scope of transit services per [RFC5598].
"Intermediaries" and "Internet Mail Handlers" are used synonymously "Intermediaries" and "Internet Mail Handlers" are used synonymously
throughout this document. throughout this document.
3.4. Authentication Assessment 3.4. Authentication Assessment
The Authentication Assessment which is affixed to a message as part The authentication assessment that is affixed to a message as part of
of each ARC Set consists of the "authres-payload" [I-D-7601bis]. For each ARC Set consists of the "authres-payload" [RFC8601]. For the
the integrity of an ARC Set, the Authentication Assessment only needs integrity of an ARC Set, the authentication assessment only needs to
to be properly encapsulated within the ARC Set as defined below be properly encapsulated within the ARC Set as defined in
Section 4.1. The accuracy or syntax of the authres-payload field Section 4.1. The accuracy or syntax of the authres-payload field
does not affect the validity of the ARC chain itself. does not affect the validity of the ARC Chain itself.
3.5. Signing vs Sealing 3.5. Signing vs. Sealing
Signing is the process of affixing a digital signature to a message 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] as a header field, such as when a DKIM-Signature (as in [RFC6376],
section 2.1), or an AMS or AS is added. Sealing is when an ADMD 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 creating or affixes a complete and valid ARC Set to a message to create or
continuing an Authenticated Received Chain. continue an Authenticated Received Chain.
3.6. Sealer 3.6. Sealer
A Sealer is an Internet Mail Handler that attaches a complete and A Sealer is an Internet Mail Handler that attaches a complete and
valid ARC Set to a message. valid ARC Set to a message.
In general concept terms, a Sealer adds its testimony (assertion of In general concept terms, a Sealer adds its testimony (assertion of
authentication assessment) and proof of custody to the Chain of authentication assessment) and proof of custody to the chain of
Custody. custody.
3.7. Validator 3.7. Validator
A Validator is an ARC-enabled Internet Mail Handler that evaluates an A Validator is an ARC-enabled Internet Mail Handler that evaluates an
Authenticated Received Chain for validity and content. The process Authenticated Received Chain for validity and content. The process
of evaluation of the individual ARC Sets that compose an of evaluation of the individual ARC Sets that compose an
Authenticated Received Chain is described in Section 5.2. Authenticated Received Chain is described in Section 5.2.
In general concept terms, a Validator inspects the Chain of Custody In general concept terms, a Validator inspects the chain of custody
to determine the content and validity of individual Evidence supplied to determine the content and validity of individual evidence supplied
by custodians. by custodians.
3.8. Imported ABNF Tokens 3.8. Imported ABNF Tokens
The following ABNF tokens are imported: The following ABNF tokens are imported:
o tag-list ([RFC6376] section 3.2) o tag-list ([RFC6376], Section 3.2)
o authres-payload ([I-D-7601bis] section 2.2) o authres-payload ([RFC8601], Section 2.2)
o cfws ([RFC5322] section 3.2.2) o CFWS ([RFC5322], Section 3.2.2)
3.9. Common ABNF Tokens 3.9. Common ABNF Tokens
The following ABNF tokens are used elsewhere in this document: The following ABNF tokens are used elsewhere in this document:
position = 1*2DIGIT ; 1 - 50 position = 1*2DIGIT ; 1 - 50
instance = [CFWS] %s"i" [CFWS] "=" instance = [CFWS] %s"i" [CFWS] "="
[CFWS] position [CFWS] position
chain-status = ("none" / "fail" / "pass") chain-status = ("none" / "fail" / "pass")
seal-cv-tag = %s"cv" [CFWS] "=" seal-cv-tag = %s"cv" [CFWS] "="
[CFWS] chain-status [CFWS] chain-status
4. Protocol Elements 4. Protocol Elements
4.1. ARC Header Fields 4.1. ARC Header Fields
ARC introduces three new header fields. Syntax for new header fields ARC introduces three new header fields. The syntax for new header
adapts existing specifications. This document only describes where fields adapts existing specifications. This document only describes
ARC-specific changes in syntax and semantics differ from existing where ARC-specific changes in syntax and semantics differ from
specifications. existing specifications.
4.1.1. ARC-Authentication-Results (AAR) 4.1.1. ARC-Authentication-Results (AAR)
The ARC-Authentication-Results (AAR) header field records the message The ARC-Authentication-Results (AAR) header field records the message
authentication assessment as processed by an ARC-participating ADMD authentication assessment as processed by an ARC-participating ADMD
at message arrival time. at message arrival time.
In general concept terms, the AAR header field is where Evidence is In general concept terms, the AAR header field is where evidence is
recorded by a custodian. recorded by a custodian.
The AAR header field is similar in syntax and semantics to an The AAR header field is similar in syntax and semantics to an
Authentication-Results field [I-D-7601bis], with two (2) differences: Authentication-Results field [RFC8601], with two (2) differences:
o the name of the header field itself; o the name of the header field itself and
o the presence of the "instance tag". Additional information on the o the presence of the instance tag. Additional information on the
"instance tag" can be found in Section 4.2.1. instance tag can be found in Section 4.2.1.
The formal ABNF for the AAR header field is: The formal ABNF for the AAR header field is:
arc-info = instance [CFWS] ";" authres-payload arc-info = instance [CFWS] ";" authres-payload
arc-authres-header = "ARC-Authentication-Results:" [CFWS] arc-info arc-authres-header = "ARC-Authentication-Results:" [CFWS] arc-info
Because there is only one AAR allowed per ARC set, the AAR MUST Because there is only one AAR allowed per ARC Set, the AAR MUST
contain the combined authres-payload with all of the authentication contain the combined authres-payload with all of the authentication
results from within the participating ADMD, regardless of how many results from within the participating ADMD, regardless of how many
Authentication-Results header fields are attached to the message. Authentication-Results header fields are attached to the message.
4.1.2. ARC-Message-Signature (AMS) 4.1.2. ARC-Message-Signature (AMS)
The ARC-Message-Signature (AMS) header field allows an ARC- The ARC-Message-Signature (AMS) header field allows an ARC-
participating ADMD to convey some responsibility (custodianship) for participating ADMD to convey some responsibility (custodianship) for
a message and possible message modifications to future ARC- a message and possible message modifications to future ARC-
participating custodians. participating custodians.
skipping to change at page 9, line 51 skipping to change at page 10, line 12
In general concept terms, the AMS header field identifies a In general concept terms, the AMS header field identifies a
custodian. custodian.
The AMS header field has the same syntax and semantics as the DKIM- The AMS header field has the same syntax and semantics as the DKIM-
Signature field [RFC6376], with three (3) differences: Signature field [RFC6376], with three (3) differences:
o the name of the header field itself; o the name of the header field itself;
o no version tag ("v") is defined for the AMS header field. As o no version tag ("v") is defined for the AMS header field. As
required for undefined tags (in [RFC6376]), if seen, a version tag required for undefined tags (in [RFC6376]), if seen, a version tag
MUST be ignored; MUST be ignored; and
o the "i" (AUID) tag is not imported from DKIM; instead, this tag is o the "i" (Agent or User Identifier (AUID)) tag is not imported from
replaced by the "instance tag" as defined in Section 4.2.1; 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 ARC places no requirements on the selectors and/or domains used for
the AMS header field signatures. the AMS header field signatures.
The formal ABNF for the AMS header field is: The formal ABNF for the AMS header field is:
arc-ams-info = instance [CFWS] ";" tag-list arc-ams-info = instance [CFWS] ";" tag-list
arc-message-signature = "ARC-Message-Signature:" [CFWS] arc-ams-info arc-message-signature = "ARC-Message-Signature:" [CFWS] arc-ams-info
To reduce the chances of accidental invalidation of AMS signatures: To reduce the chances of accidental invalidation of AMS signatures:
o AMS header fields are added by ARC-participating ADMDs as messages o AMS header fields are added by ARC-participating ADMDs as messages
exit the ADMD. AMS header fields SHOULD be attached so that any exit the ADMD. AMS header fields SHOULD be attached so that any
modifications made by the ADMD are included in the signature of modifications made by the ADMD are included in the signature of
the AMS header field. the AMS header field.
o Authentication-Results header fields MUST NOT be included in AMS o Authentication-Results header fields MUST NOT be included in AMS
signatures as they are likely to be deleted by downstream ADMDs signatures as they are likely to be deleted by downstream ADMDs
(per [I-D-7601bis] Section 5). (per [RFC8601], Section 5).
o ARC-related header fields (ARC-Authentication-Results, ARC- o ARC-related header fields (ARC-Authentication-Results, ARC-
Message-Signature, ARC-Seal) MUST NOT be included in the list of Message-Signature, and ARC-Seal) MUST NOT be included in the list
header fields covered by the signature of the AMS header field. of header fields covered by the signature of the AMS header field.
To preserve the ability to verify the integrity of a message, the To preserve the ability to verify the integrity of a message, the
signature of the AMS header field SHOULD include any DKIM-Signature signature of the AMS header field SHOULD include any DKIM-Signature
header fields already present in the message. header fields already present in the message.
4.1.3. ARC-Seal (AS) 4.1.3. ARC-Seal (AS)
The ARC-Seal (AS) header field permits ARC-participating ADMDs to The AS header field permits ARC-participating ADMDs to verify the
verify the integrity of AAR header fields and corresponding AMS integrity of AAR header fields and corresponding AMS header fields.
header fields.
In general concept terms, the AS header field is how custodians bind In general concept terms, the AS header field is how custodians bind
their authentication assessments (testimonial) into a Chain of their authentication assessments (testimonials) into a chain of
Custody so that Validators can inspect individual evidence and custody so that Validators can inspect individual evidence and
custodians. custodians.
The AS header field is similar in syntax and semantics to DKIM- The AS header field is similar in syntax and semantics to DKIM-
Signatures [RFC6376], with the following differences: Signature header fields [RFC6376], with the following differences:
o the "i" (AUID) tag is not imported from DKIM; instead, this tag is o 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; replaced by the instance tag as defined in Section 4.2.1;
o the signature of the AS header field does not cover the body of o the signature of the AS header field does not cover the body of
the message and therefore there is no 'bh' tag. The signature of the message; therefore, there is no "bh" tag. The signature of
the AS header field only covers specific header fields as defined the AS header field only covers specific header fields as defined
in Section 5.1.1; in Section 5.1.1;
o no body canonicalization is performed as the AS signature does not o no body canonicalization is performed as the AS signature does not
cover the body of a message; cover the body of a message;
o only "relaxed" header field canonicalization ([RFC6376] section o only "relaxed" header field canonicalization ([RFC6376],
3.4.2) is used; Section 3.4.2) is used;
o the only supported tags are "i" (from Section 4.2.1 of this o the only supported tags are "i" (from Section 4.2.1 of this
document), and "a", "b", "d, "s", "t" from [RFC6376] Section 3.5. document), and "a", "b", "d", "s", and "t" from [RFC6376],
Note especially that the DKIM "h" tag is NOT allowed and if found, Section 3.5. Note especially that the DKIM "h" tag is NOT allowed
MUST result in a cv status of "fail" (for more information see and, if found, MUST result in a cv status of "fail" (for more
Section 5.1.1); information, see Section 5.1.1); and
o an additional tag, "cv" ("seal-cv-tag" in the ARC-Seal ABNF o an additional tag, "cv" ("seal-cv-tag" in the ARC-Seal ABNF
definition) is used to communicate Chain Validation Status to definition), is used to communicate the Chain Validation Status to
subsequent ADMDs. subsequent ADMDs.
ARC places no requirements on the selectors and/or domains used for ARC places no requirements on the selectors and/or domains used for
the AS header field signatures. the AS header field signatures.
The formal ABNF for the AS header field is: The formal ABNF for the AS header field is:
arc-as-info = instance [CFWS] ";" tag-list arc-as-info = instance [CFWS] ";" tag-list
arc-seal = "ARC-Seal:" [CFWS] arc-as-info arc-seal = "ARC-Seal:" [CFWS] arc-as-info
4.1.4. Internationalized Email (EAI) 4.1.4. Internationalized Email (EAI)
In internationalized messages [RFC6532] many header fields can In internationalized messages [RFC6532], many header fields can
contain UTF-8 as well as ASCII text. The changes for EAI are all contain UTF-8 as well as ASCII text. The changes for EAI are all
inherited from DKIM as updated by [draft-levine-eaiauth] and inherited from DKIM as updated by [RFC8616] and Authentication-
Authentication-Results as updated in [I-D-7601bis], but are called Results (A-R) as updated in [RFC8601], but they are called out here
out here for emphasis. for emphasis.
In all ARC header fields, the d= s= tags can contain U-labels. In In all ARC header fields, the d= and s= tags can contain U-labels.
all tags, non-ASCII characters need not be quoted in dkim-quoted- In all tags, non-ASCII characters need not be quoted in dkim-quoted-
printable. printable.
The AAR header allows UTF-8 in the same places that A-R does, as The AAR header allows UTF-8 in the same places that Authentication-
described in [I-D-7601bis]. Results does, as described in [RFC8601].
4.2. ARC Set 4.2. ARC Set
An "ARC Set" is a single collection of three ARC header fields (AAR, 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 AMS, and AS). ARC header fields of an ARC Set share the same
"instance" value. "instance" value.
By adding all ARC header fields to a message, an ARC Sealer adds an 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 ARC Set to a message. A description of how Sealers add an ARC Set to
a message is found in Section 5.1. a message is found in Section 5.1.
4.2.1. Instance Tags 4.2.1. Instance Tags
Instance tags describe which ARC header fields belong to an ARC Set. 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 Each ARC header field of an ARC Set shares the same instance tag
value. value.
Instance tag values are integers that begin at 1 and are incremented Instance tag values are integers that begin at 1 and are incremented
by each addition of an ARC Set. Through the incremental values of by each addition of an ARC Set. Through the incremental values of
instance tags, an ARC Validator can determine the order in which ARC instance tags, an ARC Validator can determine the order in which ARC
Sets were added to a message. Sets were added to a message.
Instance tag values can range from 1-50 (inclusive). Instance tag values can range from 1-50 (inclusive).
_INFORMATIONAL:_ The upper limit of 50 was picked based on some _INFORMATIONAL_: The upper limit of 50 was picked based on some
initial observations reported by early working group members. The initial observations reported by early working group members. The
value was chosen so as to balance the risk of excessive header field value was chosen to balance the risk of excessive header field growth
growth Section 9.1 against expert opinion regarding the probability (see Section 9.1) against expert opinion regarding the probability of
of long-tail but non-looping multiple-intermediary mail flows. long-tail, but non-looping, multiple-intermediary mail flows. Longer
Longer ARC chains will also impose load on validators and DNS to ARC Chains will also impose a load on Validators and DNS to support
support additional verification steps. Observed quantities of additional verification steps. Observed quantities of "Received"
"Received" header fields was also considered in establishing this as header fields were also considered in establishing this as an
an experimental initial value. experimental initial value.
Valid ARC Sets MUST have exactly one instance of each ARC header Valid ARC Sets MUST have exactly one instance of each ARC header
field (AAR, AMS, and AS) for a given instance value and signing field (AAR, AMS, and AS) for a given instance value and signing
algorithm. algorithm.
For handling multiple signing algorithms, see [ARC-MULTI]. For handling multiple signing algorithms, see [ARC-MULTI].
4.3. Authenticated Received Chain 4.3. Authenticated Received Chain
An Authenticated Received Chain is an ordered collection of ARC Sets. An Authenticated Received Chain is an ordered collection of ARC Sets.
As ARC Sets are enumerated sets of ARC header fields, an As ARC Sets are enumerated sets of ARC header fields, an
Authenticated Received Chain represents the output of message Authenticated Received Chain represents the output of message
authentication assessments along the handling path of ARC-enabled authentication assessments along the handling path of ARC-enabled
processors. processors.
Authentication Assessments determined at each step of the ARC-enabled Authentication assessments determined at each step of the ARC-enabled
handling path is present in an Authenticated Received Chain in the handling path are present in an Authenticated Received Chain in the
form of AAR header fields. The ability to verify the identity of form of AAR header fields. The ability to verify the identity of
message handlers and the integrity of message content is provided by message handlers and the integrity of message content is provided by
AMS header fields. AS header fields allow messages handlers to AMS header fields. AS header fields allow message handlers to
validate the assertions, order and sequence of the Authenticated validate the assertions, order, and sequence of the Authenticated
Received Chain itself. Received Chain itself.
In general concept terms, an Authenticated Received Chain represents In general concept terms, an Authenticated Received Chain represents
a message's Chain of Custody. Validators can consult a message's a message's chain of custody. Validators can consult a message's
Chain of Custody to gain insight regarding each custodian of a chain of custody to gain insight regarding each custodian of a
message and the Evidence collected by each custodian. message and the evidence collected by each custodian.
4.4. Chain Validation Status 4.4. Chain Validation Status
The state of the Authenticated Received Chain at a specific The state of the Authenticated Received Chain at a specific
processing step is called the "Chain Validation Status". Chain processing step is called the "Chain Validation Status". Chain
Validation Status information is communicated in several ways: Validation Status information is communicated in several ways:
o the AS header field in the "cv" tag, and o as the AS header field in the "cv" tag and
o as part of Authentication-Results and AAR header field(s). o as part of the Authentication-Results and AAR header field(s).
Chain Validation Status has one of three possible values: Chain Validation Status has one of three possible values:
o none: There was no Authenticated Received Chain on the message o none: There was no Authenticated Received Chain on the message
when it arrived for validation. Typically, this occurs when a when it arrived for validation. Typically, this occurs when a
message is received directly from a message's original Message message is received directly from a message's original Message
Transfer Agent (MTA) or Message Submission Agent (MSA), or from an Transfer Agent (MTA) or Message Submission Agent (MSA), or from an
upstream Internet Mail Handler that is not participating in ARC upstream Internet Mail Handler that is not participating in ARC
handling. handling.
skipping to change at page 14, line 6 skipping to change at page 14, line 18
5. Protocol Actions 5. Protocol Actions
ARC-enabled Internet Mail Handlers generally act as both ARC ARC-enabled Internet Mail Handlers generally act as both ARC
Validators (when receiving messages) and ARC Sealers (when sending Validators (when receiving messages) and ARC Sealers (when sending
messages onward, not originated locally). messages onward, not originated locally).
An Authenticated Received Chain with a Chain Validation Status of An Authenticated Received Chain with a Chain Validation Status of
"pass" (or "none") allows Internet Mail Handlers to ascertain: "pass" (or "none") allows Internet Mail Handlers to ascertain:
o all ARC-participating ADMDs that claim responsibility for handling o all ARC-participating ADMDs that claim responsibility for handling
(and possibly modifying) the message in transit; (and possibly modifying) the message in transit and
o the authentication assessments of the message as determined by o the authentication assessments of the message as determined by
each ADMD (from AAR header fields). each ADMD (from AAR header fields).
With this information, Internet Mail Handlers MAY inform local policy With this information, Internet Mail Handlers MAY inform local policy
decisions regarding disposition of messages that experience decisions regarding disposition of messages that experience
authentication failure due to intermediate processing. authentication failure due to intermediate processing.
5.1. Sealer Actions 5.1. Sealer Actions
To "seal" a message, an ARC Sealer adds an ARC Set (the three ARC 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 header fields AAR, AMS, and AS) to a message. All ARC header fields
in an ARC Set share the same instance tag value. in an ARC Set share the same instance tag value.
To perform Sealing (aka to build and attach a new ARC Set), the 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 following actions must be taken by an ARC Sealer when presented with
a message: a message:
1. All message modifications (including adding DKIM-Signature header 1. All message modifications (including adding a DKIM-Signature
field(s)) MUST be performed before Sealing. header field(s)) MUST be performed before sealing.
2. If the message already contains an Authenticated Received Chain 2. If the message already contains an Authenticated Received Chain
with the most recent AS reporting "cv=fail", then there is no with the most recent AS reporting "cv=fail", there is no need to
need to proceed and the algorithm stops here. proceed and the algorithm stops here.
3. Calculate the instance value: if the message already contains an 3. Calculate the instance value. If the message already contains an
Authenticated Received Chain, the instance value is 1 more than Authenticated Received Chain, the instance value is 1 more than
the highest instance number found in the Authenticated Received the highest instance number found in the Authenticated Received
Chain. If no Authenticated Received Chain exists, the instance Chain. If no Authenticated Received Chain exists, the instance
value is 1. value is 1.
4. Using the calculated instance value, generate and attach a 4. Using the calculated instance value, generate and attach a
complete ARC set to the message as follows: complete ARC Set to the message as follows:
1. Generate and attach an ARC-Authentication-Results header A. Generate and attach an ARC-Authentication-Results header
field as defined in Section 4.1.1. field as defined in Section 4.1.1.
2. Generate and attach an ARC-Message-Signature header field as B. Generate and attach an ARC-Message-Signature header field as
defined in Section 4.1.2. defined in Section 4.1.2.
3. Generate and attach an ARC-Seal header field using the AS C. Generate and attach an ARC-Seal header field using the AS
definition found in Section 4.1.3, the prescribed headers definition found in Section 4.1.3, the prescribed headers
defined in Section 5.1.1, and the Chain Validation Status as defined in Section 5.1.1, and the Chain Validation Status as
determined during ARC Validation. determined during ARC validation.
5.1.1. Header Fields To Include In ARC-Seal Signatures 5.1.1. Header Fields to Include in ARC-Seal Signatures
The ARC-Seal is generated in a manner similar to how DKIM-Signatures The ARC-Seal is generated in a manner similar to how DKIM-Signature
are added to messages ([RFC6376], section 3.7), with explicit header fields are added to messages ([RFC6376], Section 3.7), with
requirements on the header fields and ordering of those fields. explicit requirements on the header fields and ordering of those
fields.
The signature of an AS header field signs a canonicalized form of the 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 ARC Set header field values. The ARC Set header field values are
supplied to the hash function in increasing instance order, starting 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 at 1, and include the ARC Set being added at the time of sealing the
message. message.
Within an ARC Set, header fields are supplied to the hash function in Within an ARC Set, header fields are supplied to the hash function in
the following order: the following order:
1. ARC-Authentication-Results 1. ARC-Authentication-Results
2. ARC-Message-Signature 2. ARC-Message-Signature
3. ARC-Seal 3. ARC-Seal
Note that when an Authenticated Received Chain has failed validation, Note that when an Authenticated Received Chain has failed validation,
the signing scope for the ARC-Seal is modified as specified in the signing scope for the ARC-Seal is modified as specified in
Section 5.1.2. Section 5.1.2.
5.1.2. Marking and Sealing "cv=fail" (Invalid) Chains 5.1.2. Marking and Sealing "cv=fail" (Invalid) Chains
In the case of a failed Authenticated Received Chain, the header In the case of a failed Authenticated Received Chain, the header
fields included in the signature scope of the AS header field b= 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 value MUST only include the ARC Set header fields created by the MTA
which detected the malformed chain, as if this newest ARC Set was the that detected the malformed chain, as if this newest ARC Set was the
only set present. only set present.
_INFORMATIONAL_: This approach is mandated to handle the case of a _INFORMATIONAL_: This approach is mandated to handle the case of a
malformed or otherwise invalid Authenticated Received Chain. There malformed or otherwise invalid Authenticated Received Chain. There
is no way to generate a deterministic set of AS header fields is no way to generate a deterministic set of AS header fields
(Section 5.1.1) in most cases of invalid chains. (Section 5.1.1) in most cases of invalid chains.
5.1.3. Only One Authenticated Received Chain Per Message 5.1.3. Only One Authenticated Received Chain per Message
A message can have only one Authenticated Received Chain on it at a 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 time. Once broken, the chain cannot be continued, as the chain of
custody is no longer valid and responsibility for the message has custody is no longer valid, and responsibility for the message has
been lost. For further discussion of this topic and the design been lost. For further discussion of this topic and the design
restriction which prevents chain continuation or re-establishment, restriction that prevents chain continuation or re-establishment, see
see [ARC-USAGE]. [ARC-USAGE].
5.1.4. Broad Ability to Seal 5.1.4. Broad Ability to Seal
ARC is not solely intended for perimeter MTAs. Any Internet Mail ARC is not solely intended for perimeter MTAs. Any Internet Mail
Handler MAY seal a message by adding a complete ARC set, whether or 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. not they have modified or are aware of having modified the message.
For additional information, see Section 7.1. For additional information, see Section 7.1.
5.1.5. Sealing is Always Safe 5.1.5. Sealing Is Always Safe
The utility of an Authenticated Received Chain is limited to very The utility of an Authenticated Received Chain is limited to very
specific cases. Authenticated Received Chains are designed to specific cases. Authenticated Received Chains are designed to
provide additional information to an Internet Mail Handler when provide additional information to an Internet Mail Handler when
evaluating messages for delivery in the context of authentication evaluating messages for delivery in the context of authentication
failures. Specifically: failures. Specifically:
o Properly adding an ARC Set to a message does not damage or o Properly adding an ARC Set to a message does not damage or
invalidate an existing Authenticated Received Chain. invalidate an existing Authenticated Received Chain.
o Sealing an Authenticated Received Chain when a message has not o Sealing an Authenticated Received Chain when a message has not
been modified does not negatively affect the chain. been modified does not negatively affect the chain.
o Validating a message exposes no new threat vectors (see o Validating a message exposes no new threat vectors (see
Section 9). Section 9).
o An ADMD may choose to Seal all inbound messages whether or not a o An ADMD may choose to seal all inbound messages whether or not a
message has been modified or will be retransmitted. message has been modified or will be retransmitted.
5.2. Validator Actions 5.2. Validator Actions
A validator performs the following steps, in sequence, to process an A Validator performs the following steps, in sequence, to process an
Authenticated Received Chain. Canonicalization, hash functions, and Authenticated Received Chain. Canonicalization, hash functions, and
signature validation methods are imported from [RFC6376] section 5. signature validation methods are imported from [RFC6376], Section 5.
1. Collect all ARC Sets currently attached to the message. 1. Collect all ARC Sets currently attached to the message.
* If there are none, the Chain Validation Status is "none" and * If there are none, the Chain Validation Status is "none", and
the algorithm stops here. the algorithm stops here.
* The maximum number of ARC Sets that can be attached to a * The maximum number of ARC Sets that can be attached to a
message is 50. If more than the maximum number exist the message is 50. If more than the maximum number exist, the
Chain Validation Status is "fail" and the algorithm stops Chain Validation Status is "fail", and the algorithm stops
here. here.
* In the following algorithm, the maximum discovered ARC * In the following algorithm, the maximum discovered ARC
instance value is referred to as "N". instance value is referred to as "N".
2. If the Chain Validation Status of the highest instance value ARC 2. If the Chain Validation Status of the highest instance value ARC
Set is "fail", then the Chain Validation status is "fail" and the Set is "fail", then the Chain Validation Status is "fail", and
algorithm stops here. the algorithm stops here.
3. Validate the structure of the Authenticated Received Chain. A 3. Validate the structure of the Authenticated Received Chain. A
valid ARC has the following conditions: valid ARC has the following conditions:
1. Each ARC Set MUST contain exactly one each of the three ARC A. Each ARC Set MUST contain exactly one each of the three ARC
header fields (AAR, AMS, and AS). header fields (AAR, AMS, and AS).
2. The instance values of the ARC Sets MUST form a continuous B. The instance values of the ARC Sets MUST form a continuous
sequence from 1..N with no gaps or repetition. sequence from 1..N with no gaps or repetition.
3. The "cv" value for all ARC-Seal header fields MUST NOT be C. The "cv" value for all ARC-Seal header fields MUST NOT be
"fail". For ARC Sets with instance values > 1, the values "fail". For ARC Sets with instance values > 1, the values
MUST be "pass". For the ARC Set with instance value = 1, the MUST be "pass". For the ARC Set with instance value = 1, the
value MUST be "none". value MUST be "none".
* If any of these conditions are not met, the Chain Validation * If any of these conditions are not met, the Chain Validation
Status is "fail" and the algorithm stops here. Status is "fail", and the algorithm stops here.
4. Validate the AMS with the greatest instance value (most recent). 4. Validate the AMS with the greatest instance value (most recent).
If validation fails, then the Chain Validation Status is "fail" If validation fails, then the Chain Validation Status is "fail",
and the algorithm stops here. and the algorithm stops here.
5. _OPTIONAL:_ Determine the "oldest-pass" value from the ARC Set by 5. _OPTIONAL_: Determine the "oldest-pass" value from the ARC Set by
validating each prior AMS beginning with the N-1 and proceeding validating each prior AMS beginning with N-1 and proceeding in
in decreasing order to the AMS with the instance value of 1: decreasing order to the AMS with the instance value of 1:
1. If an AMS fails to validate (for instance value "M"), then A. If an AMS fails to validate (for instance value "M"), then
set the oldest-pass value to the lowest AMS instance value set the oldest-pass value to the lowest AMS instance value
which passed (M+1) and go to the next step (there is no need 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 to check any other (older) AMS header fields). This does not
affect the validity of the Authenticated Received Chain. affect the validity of the Authenticated Received Chain.
2. If all AMS header fields verify, set the oldest-pass value to B. If all AMS header fields verify, set the oldest-pass value to
zero (0). zero (0).
6. Validate each AS beginning with the greatest instance value and 6. Validate each AS beginning with the greatest instance value and
proceeding in decreasing order to the AS with the instance value proceeding in decreasing order to the AS with the instance value
of 1. If any AS fails to validate, the Chain Validation Status of 1. If any AS fails to validate, the Chain Validation Status
is "fail" and the algorithm stops here. is "fail", and the algorithm stops here.
7. If the algorithm reaches this step, then the Chain Validation 7. If the algorithm reaches this step, then the Chain Validation
Status is "pass", and the algorithm is complete. Status is "pass", and the algorithm is complete.
The end result of this Validation algorithm SHOULD be included within The end result of this validation algorithm SHOULD be included within
the Authentication-Results header field for the ADMD. the Authentication-Results header field for the ADMD.
As with a DKIM signature ([RFC6376] section 6.3) which fails As with a DKIM signature ([RFC6376], Section 6.3) that fails
verification, a message with an Authenticated Received Chain with a verification, a message with an Authenticated Received Chain with a
Chain Validation status of "fail" MUST be treated the same as a Chain Validation Status of "fail" MUST be treated the same as a
message with no Authenticated Received Chain. message with no Authenticated Received Chain.
_INFORMATIONAL_: Recipients of an invalid or failing Authenticated _INFORMATIONAL_: Recipients of an invalid or failing Authenticated
Received Chain can use that information as part of a wider handling Received Chain can use that information as part of a wider handling
context. ARC adoption cannot be assumed by intermediaries; many context. ARC adoption cannot be assumed by intermediaries; many
intermediaries will continue to modify messages without adding ARC intermediaries will continue to modify messages without adding ARC
Seals. seals.
5.2.1. All Failures Are Permanent 5.2.1. All Failures Are Permanent
Authenticated Received Chains represent the traversal of messages Authenticated Received Chains represent the traversal of messages
through one or more intermediaries. All errors, including DNS through one or more intermediaries. All errors, including DNS
failures, become unrecoverable and are considered permanent. failures, become unrecoverable and are considered permanent.
Any error validating an Authenticated Received Chain results in a Any error validating an Authenticated Received Chain results in a
Chain Validation Status of "fail". For further discussion of this Chain Validation Status of "fail". For further discussion of this
topic and the design restriction which prevents chain continuation or topic and the design restriction that prevents chain continuation or
re-establishment, see [ARC-USAGE]. re-establishment, see [ARC-USAGE].
5.2.2. Responding to ARC Validation Failures During the SMTP 5.2.2. Responding to ARC Validation Failures during the SMTP
Transaction Transaction
If an ARC Validator determines that the incoming message fails ARC If an ARC Validator determines that the incoming message fails ARC
validation, the Validator MAY signal the breakage through the validation, the Validator MAY signal the breakage through the
extended SMTP response code 5.7.29 "ARC validation failure" and extended SMTP response code 5.7.29 ("ARC validation failure") and the
corresponding SMTP basic response code. Because ARC failures are corresponding SMTP basic response code. Because ARC failures are
likely only to be detected in the context of other underlying likely only to be detected in the context of other underlying
authentication mechanism failures, validators MAY use the more authentication mechanism failures, Validators MAY use the more
general 5.7.26 "Multiple authentication checks failed" instead of the general 5.7.26 ("Multiple authentication checks failed") instead of
ARC-specific code. the ARC-specific code.
6. Communication of Validation Results 6. Communication of Validation Results
Chain Validation Status (described in Section 4.4) is communicated Chain Validation Status (described in Section 4.4) is communicated
via Authentication-Results (and AAR) header fields using the auth via Authentication-Results (and AAR) header fields using the
method "arc". This auth method is described in Section 10.1. authentication method "arc". This authentication method is described
in Section 10.1.
If necessary data is available, the ptypes and properties defined in If necessary data is available, the ptypes and properties defined in
Section 10.2 SHOULD be recorded in an Authentication-Results header Section 10.2 SHOULD be recorded in an Authentication-Results header
field: field:
o smtp.remote-ip - The address of the connection-initiating SMTP o smtp.remote-ip - The address of the connection-initiating SMTP
server, from which the message is being relayed. server, from which the message is being relayed.
o header.oldest-pass - The instance number of the oldest AMS that o header.oldest-pass - The instance number of the oldest AMS that
still validates, or 0 if all pass. still validates, or 0 if all pass.
7. Use Cases 7. Use Cases
This section explores several messaging handling use cases that are This section explores several message handling use cases that are
addressed by ARC. addressed by ARC.
7.1. Communicate Authentication Assessment Across Trust Boundaries 7.1. Communicate Authentication Assessment across Trust Boundaries
When an intermediary ADMD adds an ARC Set to a message's When an intermediary ADMD adds an ARC Set to a message's
Authenticated Received Chain (or creates the initial ARC Set), the Authenticated Received Chain (or creates the initial ARC Set), the
ADMD communicates its authentication assessment to the next ARC- ADMD communicates its authentication assessment to the next ARC-
participating ADMD in the message handling path. participating ADMD in the message-handling path.
If ARC-enabled ADMDs are trusted, Authenticated Received Chains can If ARC-enabled ADMDs are trusted, Authenticated Received Chains can
be used to bridge administrative boundaries. be used to bridge administrative boundaries.
7.1.1. Message Scanning Services 7.1.1. Message-Scanning Services
Message services are available to perform anti-spam, anti-malware, Message services are available to perform anti-spam, anti-malware,
and anti-phishing scanning. Such services typically remove malicious and anti-phishing scanning. Such services typically remove malicious
content, replace HTTP links in messages with sanitized links, and/or content, replace HTTP links in messages with sanitized links, and/or
attach footers to messages advertising the abilities of the message attach footers to messages advertising the abilities of the message-
scanning service. These modifications almost always break signature- scanning service. These modifications almost always break signature-
based authentication (such as DKIM). based authentication (such as DKIM).
Scanning services typically require clients to point MX records of an Scanning services typically require clients to point MX records of an
Internet domain to the scanning service. Messages destined for the Internet domain to the scanning service. Messages destined for the
Internet domain are initially delivered to the scanning service. Internet domain are initially delivered to the scanning service.
Once scanning is performed, messages are then routed to the client's Once scanning is performed, messages are then routed to the client's
own mail handling infrastructure. Re-routing messages in this way own mail-handling infrastructure. Rerouting messages in this way
almost always breaks path-based authentication (such as SPF). almost always breaks path-based authentication (such as SPF).
Message scanning services can attach Authenticated Received Chains to Message-scanning services can attach Authenticated Received Chains to
messages to communicate authentication assessment into client ADMDs. messages to communicate authentication assessment into client ADMDs.
Clients can then benefit from the message scanning service while Clients can then benefit from the message-scanning service while
processing messages as if the client's infrastructure were the processing messages as if the client's infrastructure were the
original destination of the Internet domain's MX record. original destination of the Internet domain's MX record.
7.1.2. Multi-tier MTA Processing 7.1.2. Multi-tier MTA Processing
Large message processing infrastructure is often divided into several A large message-processing infrastructure is often divided into
processing tiers that can break authentication information between several processing tiers that can break authentication information
tiers. For example, a large site may maintain a cluster of MTAs between tiers. For example, a large site may maintain a cluster of
dedicated to connection handling and enforcement of IP-based MTAs dedicated to connection handling and enforcement of IP-based
reputation filtering. A secondary cluster of MTAs may be dedicated reputation filtering. A secondary cluster of MTAs may be dedicated
and optimized for content-based processing of messages. and optimized for content-based processing of messages.
Authenticated Received Chains can be used to communicate Authenticated Received Chains can be used to communicate
authentication assessment between processing tiers. authentication assessment between processing tiers.
7.1.3. Mailing Lists 7.1.3. Mailing Lists
Mailing lists take delivery of messages and re-post them to Mailing lists take delivery of messages and repost them to
subscribers. A full description of authentication-related mailing subscribers. A full description of authentication-related mailing
list issues can be found in [RFC7960] Section 3.2.3. list issues can be found in [RFC7960], Section 3.2.3.
Mailing list services can implement ARC to convey the authentication Mailing list services can implement ARC to convey the authentication
assessment of posted messages sent to the list's subscriber base. assessment of posted messages sent to the list's subscriber base.
The ADMDs of the mailing list subscribers can then use the The ADMDs of the mailing list subscribers can then use the
Authenticated Received Chain to determine the authentication Authenticated Received Chain to determine the authentication
assessment of the original message before mailing list handling. assessment of the original message before mailing list handling.
7.2. Inform Message Disposition Decisions 7.2. Inform Message Disposition Decisions
Intermediaries often break authentication through content Intermediaries often break authentication through content
modification, interfere with path-based authentication (such as SPF), modification, interfere with path-based authentication (such as SPF),
and strip authentication results (if an MTA removes Authentication- and strip authentication results (if an MTA removes Authentication-
Results header fields). Results header fields).
Authenticated Received Chains allow ARC Validators to: Authenticated Received Chains allow ARC Validators to:
1. identify ARC-enabled ADMDs that break authentication while 1. identify ARC-enabled ADMDs that break authentication while
processing messages; processing messages and
2. gain extended visibility into the authentication-preserving 2. gain extended visibility into the authentication-preserving
abilities of ADMDs that relay messages into ARC-enabled ADMDs. abilities of ADMDs that relay messages into ARC-enabled ADMDs.
Through the collection of ARC-related data, an ADMD can identify Through the collection of ARC-related data, an ADMD can identify
handling paths that have broken authentication. handling paths that have broken authentication.
An Authenticated Received Chain allows an Internet Mail Handler to An Authenticated Received Chain allows an Internet Mail Handler to
potentially base decisions of message disposition on authentication potentially base decisions of message disposition on authentication
assessments provided by different ADMDs. assessments provided by different ADMDs.
skipping to change at page 21, line 13 skipping to change at page 22, line 7
local policy, a DMARC processor MAY choose to accept the local policy, a DMARC processor MAY choose to accept the
authentication assessments provided by an Authenticated Received authentication assessments provided by an Authenticated Received
Chain when determining if a message is DMARC compliant. Chain when determining if a message is DMARC compliant.
When an Authenticated Received Chain is used to determine message When an Authenticated Received Chain is used to determine message
disposition, the DMARC processor can communicate this local policy disposition, the DMARC processor can communicate this local policy
decision to Domain Owners as described in Section 7.2.2. decision to Domain Owners as described in Section 7.2.2.
7.2.2. DMARC Reporting 7.2.2. DMARC Reporting
DMARC-enabled receivers indicate when ARC Validation influences DMARC-enabled receivers indicate when ARC validation influences
DMARC-related local policy decisions. When an ARC-enabled handler DMARC-related local policy decisions. When an ARC-enabled handler
generates a DMARC report, it MAY indicate the influence of ARC on generates a DMARC report, it MAY indicate the influence of ARC on
their local policy decision(s) by adding a reason of "local_policy" their local policy decision(s) by adding a reason of "local_policy"
with a comment string (per [RFC7489] Appendix C) containing a list of with a comment string (per [RFC7489], Appendix C) containing a list
data discovered during ARC Validation, which at a minimum includes: of data discovered during ARC validation, which at a minimum
includes:
o the Chain Validation Status, o the Chain Validation Status,
o the domain and selector for each AS, o the domain and selector for each AS, and
o the originating IP address from the first ARC Set: o the originating IP address from the first ARC Set.
EXAMPLE: EXAMPLE:
<policy_evaluated> <policy_evaluated>
<disposition>none</disposition> <disposition>none</disposition>
<dkim>fail</dkim> <dkim>fail</dkim>
<spf>fail</spf> <spf>fail</spf>
<reason> <reason>
<type>local_policy</type> <type>local_policy</type>
<comment>arc=pass as[2].d=d2.example as[2].s=s2 <comment>arc=pass as[2].d=d2.example as[2].s=s2
as[1].d=d1.example as[1].s=s3 as[1].d=d1.example as[1].s=s3
remote-ip[1]=2001:DB8::1A</comment> remote-ip[1]=2001:DB8::1A</comment>
</reason> </reason>
</policy_evaluated> </policy_evaluated>
In the above example DMARC XML reporting fragment, data relating to In the example DMARC XML reporting fragment above, data relating to
specific validated ARC Sets are enumerated using array syntax (eg, specific validated ARC Sets are enumerated using array syntax (e.g.,
"as[2]" means AS header field with instance value of 2). d2.example "as[2]" means an AS header field with an instance value of 2).
is the Sealing domain for ARC Set #2 (i=2) and d1.example is the d2.example is the sealing domain for ARC Set #2 (i=2), and d1.example
Sealing domain for ARC Set #1 (i=1). is the sealing domain for ARC Set #1 (i=1).
Depending on the reporting practices of intermediate message Depending on the reporting practices of intermediate message
handlers, Domain Owners may receive multiple DMARC reports for a handlers, Domain Owners may receive multiple DMARC reports for a
single message. Receivers of DMARC reports should be aware of this single message. Receivers of DMARC reports should be aware of this
behaviour and make the necessary accommodations. behavior and make the necessary accommodations.
8. Privacy Considerations 8. Privacy Considerations
The Authenticated Received Chain provides a verifiable record of the The Authenticated Received Chain provides a verifiable record of the
handlers for a message. This record may include Personally handlers for a message. This record may include personally
Identifiable Information such as IP address(es) and domain names. identifiable information such as an IP address(es) and domain names.
Such information is also included in existing non-ARC related header Such information is also included in existing non-ARC-related header
fields such as the "Received" header fields. fields such as the "Received" header fields.
9. Security Considerations 9. Security Considerations
The Security Considerations of [RFC6376] and [I-D-7601bis] apply The Security Considerations of [RFC6376] and [RFC8601] apply directly
directly to this specification. to this specification.
As with other domain authentication technologies (such as SPF, DKIM, As with other domain-based authentication technologies (such as SPF,
and DMARC), ARC makes no claims about the semantic content of DKIM, and DMARC), ARC makes no claims about the semantic content of
messages. messages. A received message with a validated ARC Chain provides
A received message with an ARC chain provides evidence (at instance evidence (at instance N) that:
N) that: The sealing domain (ARC-Seal d=) processed a message with
this body, determined the authentication assessment reported in the 1. the sealing domain (ARC-Seal[N] d=) emitted the message with this
ARC-Authentication-Results, and the ARC chain 1..N-1 (with the body,
validation status as reported in the cv field).
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 9.1. Increased Header Field Size
Inclusion of Authenticated Received Chains into messages may cause Inclusion of Authenticated Received Chains into messages may cause
issues for older or constrained MTAs due to increased total header issues for older or constrained MTAs due to increased total header
field size. Large header field blocks, in general, may cause field size. Large header field blocks, in general, may cause
failures to deliver or other outage scenarios for such MTAs. ARC failures to deliver or other outage scenarios for such MTAs. ARC
itself would not cause problems. itself would not cause problems.
9.2. DNS Operations 9.2. DNS Operations
The validation of an Authenticated Received Chain composed of N ARC The validation of an Authenticated Received Chain composed of N ARC
Sets can require up to 2*N DNS queries (not including any DNS Sets can require up to 2*N DNS queries (not including any DNS
redirection mechanisms which can increase the total number of redirection mechanisms that can increase the total number of
queries). This leads to two considerations: queries). This leads to two considerations:
1. An attacker can send a message to an ARC participant with a 1. An attacker can send a message to an ARC participant with a
concocted sequence of ARC Sets bearing the domains of intended concocted sequence of ARC Sets bearing the domains of intended
victims, and all of them will be queried by the participant until victims, and all of them will be queried by the participant until
a failure is discovered. DNS caching and the difficulty of a failure is discovered. DNS caching and the difficulty of
forging the signature values should limit the extent of this load forging the signature values should limit the extent of this load
to domains under control of the attacker. Query traffic pattern to domains under control of the attacker. Query traffic pattern
analysis may expose information about downstream validating ADMD analysis may expose information about a downstream validating
infrastructure. ADMD infrastructure.
2. DKIM only performs one DNS query per signature, while ARC can 2. DKIM only performs one DNS query per signature, while ARC can
introduce many (per chain). Absent caching, slow DNS responses introduce many (per chain). Absent caching, slow DNS responses
can cause SMTP timeouts; and backlogged delivery queues on can cause SMTP timeouts and backlogged delivery queues on
Validating systems. This could be exploited as a DoS attack. validating systems. This could be exploited as a DoS attack.
9.3. Message Content Suspicion 9.3. Message Content Suspicion
Recipients are cautioned to treat messages bearing Authenticated Recipients are cautioned to treat messages bearing Authenticated
Received Chains with the same suspicion applied to all other Received Chains with the same suspicion applied to all other
messages. This includes appropriate content scanning and other messages. This includes appropriate content scanning and other
checks for potentially malicious content. checks for potentially malicious content.
ARC authenticates the identity of some email handling actors. It ARC authenticates the identity of some email-handling actors. It
does not make any assessment of their trustworthiness. does not make any assessment of their trustworthiness.
Just as passing message authentication is not an indication of Just as passing message authentication is not an indication of
message safety, forwarding that information through the mechanism of message safety, forwarding that information through the mechanism of
ARC is also not an indication of message safety. Even if all ARC- ARC is also not an indication of message safety. Even if all ARC-
enabled ADMDs are trusted, ADMDs may have become compromised, may enabled ADMDs are trusted, ADMDs may have become compromised, may
miss unsafe content, or may not properly authenticate messages. miss unsafe content, or may not properly authenticate messages.
9.4. Message Sealer Suspicion 9.4. Message Sealer Suspicion
Recipients are cautioned to treat every Sealer of the ARC Chain with Recipients are cautioned to treat every Sealer of the ARC Chain with
suspicion. Just as with a validated DKIM signature, responsibility suspicion. Just as with a validated DKIM signature, responsibility
for message handling is attributed to the Sealing domain, but whether 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 or not that Sealer is a malicious actor is out of scope of the
authentication mechanism. Since ARC aids message delivery in the authentication mechanism. Since ARC aids message delivery in the
event of an authentication failure, ARC Sealers should be treated event of an authentication failure, ARC Sealers should be treated
with suspicion, so that a malicious actor cannot Seal spam or other with suspicion, so that a malicious actor cannot seal spam or other
fraudulent messages to aid their delivery, too. fraudulent messages to aid their delivery, too.
9.5. Replay Attacks 9.5. Replay Attacks
Since ARC inherits heavily from DKIM, it has similar attack vectors. Since ARC inherits heavily from DKIM, it has similar attack vectors.
In particular, the Replay Attack described in [RFC6376] section 8.6 In particular, the replay attack described in [RFC6376], Section 8.6
is potentially amplified by ARC's chained statuses. In an ARC replay is potentially amplified by ARC's chained statuses. In an ARC replay
attack, a malicious actor would take an intact and passing ARC Chain, attack, a malicious actor would take an intact and passing ARC Chain
and then resend it to many recipients without making any and resend it to many recipients without making any modifications
modifications that invalidate the latest AMS or AS. The impact to a that invalidate the latest AMS or AS. The impact to a receiver would
receiver would be more DNS lookups and signature evaluations. This be more DNS lookups and signature evaluations. The scope of this
scope of this attack can be limited by caching DNS queries and attack can be limited by caching DNS queries and following the same
following the same signing scope guidance from [RFC6376] section signing scope guidance from [RFC6376], Section 5.4.1.
5.4.1.
10. IANA Considerations 10. IANA Considerations
[[ *Note to the RFC Editors:* "dkim - header - s" is defined in This document defines one new authentication method and several
[I-D-7601bis]. Please adjust the list below as appropriate. ]] status codes (Section 10.1), new ptypes and properties
This draft introduces three new headers fields and updates the Email (Section 10.2), three new headers fields (Section 10.3), and a new
Authentication Parameters registry with one new authentication method enumerated status code (Section 10.4).
and several status codes.
10.1. Email Authentication Results Names Registry Update 10.1. Update to Email Authentication Result Names Registry
This draft adds one Auth Method with three Codes to the IANA "Email Per this document, IANA has added one authentication method with
Authentication Result Names" registry: three codes to the IANA "Email Authentication Result Names" registry:
o Auth Method : arc o Auth Method: arc
Code: "none", "pass", "fail" Code: "none", "pass", "fail"
Specification: this document 2.2 Specification: RFC 8617, Section 4.4
Status: active Status: active
10.2. Email Authentication Methods Registry Update 10.2. Update to Email Authentication Methods Registry
This draft adds several new items to the Email Authentication Methods Per this document, IANA has added the following to the "Email
registry, most recently defined in [I-D-7601bis]: Authentication Methods" registry, which is defined in [RFC8601]:
o Method: arc o Method: arc
Definition: this document section 6 Definition: RFC 8617, Section 6
ptype: smtp ptype: smtp
Property: remote-ip Property: remote-ip
Value: IP address (v4 or v6) of originating SMTP connection Value: IP address (v4 or v6) of originating SMTP connection
Status: active Status: active
Version: 1 Version: 1
o Method: arc o Method: arc
Definition: this document section 6 Definition: RFC 8617, Section 6
ptype: header ptype: header
Property: oldest-pass Property: oldest-pass
Value: The instance id of the oldest validating AMS, or 0 if they Value: The instance id of the oldest validating AMS or 0 if they
all pass (see Section 5.2) all pass (see Section 5.2)
Status: active Status: active
Version: 1 Version: 1
10.3. Definitions of the ARC header fields 10.3. New Header Fields in Permanent Message Header Field Registry
This specification adds three new header fields to the "Permanent Per this document, IANA has added the following three new header
Message Header Field Registry", as follows: fields to the "Permanent Message Header Field Names" registry:
o Header field name: ARC-Seal o Header field name: ARC-Seal
Applicable protocol: mail Applicable protocol: mail
Status: Experimental Status: experimental
Author/Change controller: IETF Author/Change controller: IETF
Specification document(s): this document Specification document(s): RFC 8617
Related information: [RFC6376] Related information: RFC 6376
o Header field name: ARC-Message-Signature o Header field name: ARC-Message-Signature
Applicable protocol: mail Applicable protocol: mail
Status: Experimental Status: experimental
Author/Change controller: IETF Author/Change controller: IETF
Specification document(s): this document Specification document(s): RFC 8617
Related information: [RFC6376] Related information: RFC 6376
o Header field name: ARC-Authentication-Results o Header field name: ARC-Authentication-Results
Applicable protocol: mail Applicable protocol: mail
Status: Experimental Status: experimental
Author/Change controller: IETF Author/Change controller: IETF
Specification document(s): this document Specification document(s): RFC 8617
Related information: [I-D-7601bis] Related information: RFC 8601
10.4. New Enhanced Status Code - ARC Validation 10.4. New Status Code in Enumerated Status Codes Registry
The following value should be added to the [ENHANCED-STATUS] Per this document, IANA has added the following value to the
registry, as follows: "Enumerated Status Codes" registry:
o Code: X.7.29 o Code: X.7.29
Sample Text: ARC validation failure Sample Text: ARC validation failure
Associated basic status code: 550 Associated basic status code: 550
Description: This status code may be returned when a message fails Description: This status code may be returned when a message fails
ARC validation ARC validation.
Reference: this document Reference: RFC 8617
Submitter: K. Andersen Submitter: K. Andersen
Change controller: IESG Change controller: IESG
11. Experimental Considerations 11. Experimental Considerations
The ARC protocol is designed to address common interoperability The ARC protocol is designed to address common interoperability
issues introduced by intermediate message handlers. Interoperability issues introduced by intermediate message handlers. Interoperability
issues are described in [RFC6377] and [RFC7960]. issues are described in [RFC6377] and [RFC7960].
As the ARC protocol is implemented by Internet Mail Handlers over As the ARC protocol is implemented by Internet Mail Handlers over
time, the following should be evaluated in order to determine the time, the following should be evaluated in order to determine the
skipping to change at page 25, line 52 skipping to change at page 27, line 24
11.1. Success Consideration 11.1. Success Consideration
In an attempt to deliver legitimate messages that users desire, many In an attempt to deliver legitimate messages that users desire, many
receivers use heuristic-based methods to identify messages that receivers use heuristic-based methods to identify messages that
arrive via indirect delivery paths. arrive via indirect delivery paths.
ARC will be a success if the presence of Authenticated Received ARC will be a success if the presence of Authenticated Received
Chains allows for improved decision making when processing legitimate Chains allows for improved decision making when processing legitimate
messages, specifically resulting in equal or better delivery rates messages, specifically resulting in equal or better delivery rates
than achieve through the use of heuristic approaches. than achieved through the use of heuristic approaches.
11.2. Failure Considerations 11.2. Failure Considerations
ARC should function without introducing significant new vectors for ARC should function without introducing significant new vectors for
abuse (see Section 9). If unforeseen vectors are enabled by ARC, abuse (see Section 9). If unforeseen vectors are enabled by ARC,
then this protocol will be a failure. Note that weaknesses inherent this protocol will be a failure. Note that the weaknesses inherent
in the mail protocols ARC is built upon (such as DKIM replay attacks in the mail protocols ARC is built upon (such as DKIM replay attacks
and other known issues) are not new vectors which can be attributed and other known issues) are not new vectors that can be attributed to
to this specification. this specification.
11.3. Open Questions 11.3. Open Questions
The following open questions are academic and have no clear answer at The following open questions are academic and have no clear answer at
the time of the development of the protocol. However, additional the time this document was published. However, additional
deployments should be able to gather the necessary data to answer deployments should be able to gather the necessary data to answer
some or all of them. some or all of them.
11.3.1. Value of the ARC-Seal (AS) Header Field 11.3.1. Value of the ARC-Seal (AS) Header Field
Data should be collected to show if the ARC-Seal (AS) provides value Data should be collected to show if the AS provides value beyond the
beyond the ARC Message Signature (AMS) for either making delivery AMS for either making delivery decisions or catching malicious actors
decisions or catching malicious actors trying to craft or replay trying to craft or replay malicious chains.
malicious chains.
11.3.2. Usage and/or signals from multiple selectors and/or domains in 11.3.2. Usage and/or Signals from Multiple Selectors and/or Domains in
ARC sets ARC Sets
Any selectors and/or (sub)domains (under the control of the sealing Any selectors and/or (sub)domains (under the control of the sealing
ADMD) may be used for ARC header field signatures. ADMD) may be used for ARC header field signatures.
While implementers may choose to use various selectors and/or domains While implementers may choose to use various selectors and/or domains
for ARC set header fields, no compelling argument for or against such 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 usage has been made within the working group. As such, we have
to allow maximum freedom for the experimental definition of this chosen to allow maximum freedom for the experimental definition of
protocol. this protocol.
Wider deployment experience and higher volumes of traffic may show Wider deployment experience and higher volumes of traffic may show
whether this is useful. whether this is useful.
11.3.3. DNS Overhead 11.3.3. DNS Overhead
Longer Authenticated Received Chains will require more queries to Longer Authenticated Received Chains will require more queries to
retrieve the keys for validating the chain. While this is not retrieve the keys for validating the chain. While this is not
believed to be a security issue (see Section 9.2), it is unclear how believed to be a security issue (see Section 9.2), it is unclear how
much overhead will truly be added. This is similar to some of the much overhead will truly be added. This is similar to some of the
initial processing and query load concerns which were debated at the initial processing and query load concerns that were debated at the
time of the DKIM specification development. time of the DKIM specification development.
Data should be collected to better understand usable length and Data should be collected to better understand usable length and
distribution of lengths found in valid Authenticated Received Chains distribution of lengths found in valid Authenticated Received Chains
along with the DNS impact of processing Authenticated Received along with the DNS impact of processing Authenticated Received
Chains. Chains.
An effective operational maximum will have to be developed through An effective operational maximum will have to be developed through
deployment experience in the field. deployment experience in the field.
11.3.4. What Trace Information is Valuable 11.3.4. What Trace Information Is Valuable?
There are several edge cases where the information in the AAR can There are several edge cases where the information in the AAR can
make the difference between message delivery or rejection. For make the difference between message delivery or rejection. For
example, if there is a well known mailing list that seals with ARC 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 but doesn't do its own initial DMARC enforcement, an Internet Mail
Handler with this knowledge could make a delivery decision based upon Handler with this knowledge could make a delivery decision based upon
the authentication information it sees in the corresponding AAR the authentication information it sees in the corresponding AAR
header field. header field.
Certain trace information in the AAR is useful/necessary in the Certain trace information in the AAR is useful/necessary in the
construction of DMARC reports. construction of DMARC reports.
Further, certain receivers believe the entire set of trace Further, certain receivers believe the entire set of trace
information would be valuable to feed into machine learning systems information would be valuable to feed into machine learning systems
to identify fraud and/or provide other signals related to message to identify fraud and/or provide other signals related to message
delivery. delivery.
At this point, however, it is unclear what trace information will be At this point, however, it is unclear what trace information will be
valuable for all receivers, regardless of size. valuable for all receivers, regardless of size.
Data should be collected on what trace information receivers are Data should be collected on what trace information receivers are
using that provides useful signals that affect deliverability, and using that provides useful signals that affect deliverability and
what portions of the trace data are left untouched or provide no what portions of the trace data are left untouched or provide no
useful information. useful information.
Since many such systems are intentionally proprietary or confidential Since many such systems are intentionally proprietary or confidential
to prevent gaming by abusers, it may not be viable to reliably answer to prevent gaming by abusers, it may not be viable to reliably answer
this particular question. The evolving nature of attacks can also this particular question. The evolving nature of attacks can also
shift the landscape of "useful" information over time. shift the landscape of "useful" information over time.
12. Implementation Status 12. References
[[ Note to the RFC Editor: Please remove this section before
publication along with the reference to [RFC7942]. ]]
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
This information is known to be correct as of the eighth
interoperability test event which was held on 2018-03-17 at IETF101.
For a few of the implementations, later status information was
available as of August 2018.
12.1. GMail test reflector and incoming validation
Organization: Google
Description: Internal production implementation with both debug
analysis and validating + sealing pass-through function
Status of Operation: Production - Incoming Validation
Coverage: Full spec implemented as of this document
Licensing: Internal only
Implementation Notes:
o Full functionality was demonstrated during the interop testing on
2018-03-17 and 2018-10-12. All traffic going into GSuite, Google
Groups, or GMail mailboxes will have ARC validation and sealing.
Contact Info: arc-discuss@dmarc.org [1]
12.2. AOL test reflector and internal tagging
Organization: AOL
Description: Internal prototype implementation with both debug
analysis and validating + sealing pass-through function
Status of Operation: Beta
Coverage: ARC Chain validity status checking is operational, but only
applied to email addresses enrolled in the test program. This system
conforms to [ARC-DRAFT-05]
Licensing: Proprietary - Internal only
Implementation Notes:
o 2017-07-15: Full functionality verified during the interop
testing.
o 2018-06: Partially retired but still accessible by special request
due to the in process evolution of the AOL mail infrastructure to
the integrated OATH environment. The implementation was based on
the Apache James DKIM code base.
o 2018-10: No longer available due to infrastucture changes at AOL/
Yahoo!/Oath.
Contact Info: arc-discuss@dmarc.org [2]
12.3. dkimpy
Organization: dkimpy developers/Scott Kitterman
Description: Python DKIM package
Status of Operation: Production
Coverage: Full spec implemented as of this document
o 2017-07-15: The internal test suite is incomplete, but the command
line developmental version of validator was demonstrated to
interoperate with the Google and AOL implementations during the
interop on 2017-07-15 and the released version passes the tests in
[ARC-TEST] arc_test_suite [3] with both python and python3.
o 2018-10: Re-validated in the interop
Licensing: Open/Other (same as dkimpy package = BCD version 2)
Contact Info: https://launchpad.net/dkimpy
12.4. OpenARC
Organization: TDP/Murray Kucherawy
Description: Implementation of milter functionality related to the
OpenDKIM and OpenDMARC packages
Status of Operation: Beta
Coverage: Built to support this document
Licensing: Open/Other (same as OpenDKIM and OpenDMARC packages)
Implementation Notes:
o 2018-10: Validated with one bug discovered during interop
o 2018-11: Known issues have been resolved with release 1.0.0-Beta2
Contact Info: arc-discuss@dmarc.org [4], openarc-users@openarc.org
[5]
12.5. Mailman 3.x patch
Organization: Mailman development team
Description: Integrated ARC capabilities within the Mailman 3.2
package
Status of Operation: Patch submitted
Coverage: Based on OpenARC
Licensing: Same as mailman package - GPL
Implementation Notes:
o Appears to work properly in at least one beta deployment, but
waiting on acceptance of the pull request into the mainline of
mailman development
o Discussions continuing with Mailman team to get this integrated
Contact Info: https://www.gnu.org/software/mailman/contact.html
12.6. Copernica/MailerQ web-based validation
Organization: Copernica
Description: Web-based validation of ARC-signed messages
Status of Operation: Beta
Coverage: Built to support [ARC-DRAFT-05]
Licensing: On-line usage only
Implementation Notes:
o Released 2016-10-24
o Requires full message content to be pasted into a web form found
at http://arc.mailerq.com/ (warning - https is not supported).
o An additional instance of an ARC signature can be added if one is
willing to paste a private key into an unsecured web form.
o 2017-07-15: Testing shows that results match the other
implementations listed in this section.
o 2018-10: not tested during interop
Contact Info: https://www.copernica.com/
12.7. Rspamd
Organization: Rspamd community
Description: ARC signing and verification module
Status of Operation: Production, though deployment usage is unknown
Coverage: Built to support [ARC-DRAFT-14]
Licensing: Open source
Implementation Notes:
o 2017-06-12: Released with version 1.6.0
o 2017-07-15: Testing during the interop showed that the validation
functionality interoperated with the Google, AOL, dkimpy and
MailerQ implementations
o 2018-10: Re-validated during the interop
Contact Info: https://rspamd.com/doc/modules/arc.html and
https://github.com/vstakhov/rspamd
12.8. PERL MAIL::DKIM module
Organization: FastMail
Description: Email domain authentication (sign and/or verify) module,
previously included SPF / DKIM / DMARC, now has ARC added
Status of Operation: Production, deployment usage unknown
Coverage: Built to support [ARC-DRAFT-10]
Licensing: Open Source
Implementation Notes:
o 2017-12-15: v0.50 released with full test set passing for ARC
o 2018-10: Revalidated during the interop and used for the creation
of the Appendix B example
Contact Info: http://search.cpan.org/~mbradshaw/Mail-DKIM-0.50/
12.9. PERL Mail::Milter::Authentication module
Organization: FastMail
Description: Email domain authentication milter, uses MAIL::DKIM (see
above)
Status of Operation: Initial validation completed during IETF99
hackathon with some follow-on work during the week
Coverage: Built to support [ARC-DRAFT-14]
Licensing: Open Source
Implementation Notes:
o 2017-07-15: Validation functionality which interoperates with
Gmail, AOL, dkimpy was demonstrated; later in the week of IETF99,
the signing functionality was reported to be working
o 2017-07-20: ARC functionality has not yet been pushed back to the
github repo but should be showing up soon
o 2018-10: Revalidated during the interop
Contact Info: https://github.com/fastmail/authentication_milter
12.10. Sympa List Manager
Organization: Sympa Dev Community
Description: Beta released Status of Operation: Beta released
Coverage: Built to support this document, based on Mail::DKIM module
Licensing: open source
Implementation Notes:
o 2018-01-05: Tracked as https://github.com/sympa-community/sympa/
issues/153
o 2018-12-08: Sympa 6.2.37 beta 3 incorporates ARC support,
scheduled for stable release 6.2.38 on 2018-12-21
Contact Info: https://github.com/sympa-community
12.11. Oracle Messaging Server
Organization: Oracle
Description:
Status of Operation: Initial development work during IETF99
hackathon. Framework code is complete, crypto functionality requires
integration with libsodium
Coverage: Work in progress
Licensing: Unknown
Implementation Notes:
o 2018-03: Protocol handling components are completed, but crypto is
not yet functional.
Contact Info: Chris Newman, Oracle
12.12. MessageSystems Momentum and PowerMTA platforms
Organization: MessageSystems/SparkPost
Description: OpenARC integration into the LUA-enabled Momentum
processing space
Status of Operation: Beta
Coverage: Same as OpenARC
Licensing: Unknown
Implementation Notes:
o 2018-10: Beta version in private evaluation, not tested during
interop.
Contact Info: TBD
12.13. Exim
Organization: Exim developers
Status of Operation: Operational; requires specific enabling for
compile.
Coverage: Full spec implemented as of [ARC-DRAFT-13]
Licensing: GPL
Contact Info: exim-users@exim.org
Implementation notes:
o Implemented as of Exim 4.91
12.14. Halon MTA
Organization: Halon
Status of Operation: Operational as of May 2018
Coverage: Full spec implemented as of this document Licensing:
Commercial, trial version available for download
Contact Info: https://halon.io
Implementation notes:
o GPL'd library with ARC capabilities: https://github.com/halon/
libdkimpp
o 2018-10: Validated during interop
12.15. IIJ
Organization: Internet Initiative Japan (IIJ) Status of Operation:
Operational as of October 2018
Coverage: Full spec implemented as of this document
Licensing: Internal
Contact Info: https://www.iij.ad.jp/en/
Implementation notes:
o 2018-10: Internal MTA implementation validated during the ARC
interop
13. References
13.1. Normative References
[draft-levine-eaiauth]
Levine, J., "E-mail Authentication for Internationalized
Mail", August 2018, <https://tools.ietf.org/html/
draft-levine-appsarea-eaiauth-03>.
[I-D-7601bis] 12.1. Normative References
Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", February 2018,
<https://datatracker.ietf.org/doc/
draft-ietf-dmarc-rfc7601bis/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
skipping to change at page 35, line 9 skipping to change at page 30, line 22
<https://www.rfc-editor.org/info/rfc7208>. <https://www.rfc-editor.org/info/rfc7208>.
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
RFC 7405, DOI 10.17487/RFC7405, December 2014, RFC 7405, DOI 10.17487/RFC7405, December 2014,
<https://www.rfc-editor.org/info/rfc7405>. <https://www.rfc-editor.org/info/rfc7405>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
13.2. Informative References [RFC8601] Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", RFC 8601,
[ARC-DRAFT-05] DOI 10.17487/RFC8601, May 2019,
Andersen, K., "Authenticated Received Chain (ARC) Protocol <https://www.rfc-editor.org/info/rfc8601>.
(I-D-05)", n.d., <https://tools.ietf.org/html/
draft-ietf-dmarc-arc-protocol-05>.
[ARC-DRAFT-10]
Andersen, K., "Authenticated Received Chain (ARC) Protocol
(I-D-10)", n.d., <https://tools.ietf.org/html/
draft-ietf-dmarc-arc-protocol-10>.
[ARC-DRAFT-13] [RFC8616] Levine, J., "Email Authentication for Internationalized
Andersen, K., "Authenticated Received Chain (ARC) Protocol Mail", RFC 8616, DOI 10.17487/RFC8616, June 2019,
(I-D-13)", n.d., <https://tools.ietf.org/html/ <https://www.rfc-editor.org/info/rfc8616>.
draft-ietf-dmarc-arc-protocol-13>.
[ARC-DRAFT-14] 12.2. Informative References
Andersen, K., "Authenticated Received Chain (ARC) Protocol
(I-D-14)", n.d., <https://tools.ietf.org/html/
draft-ietf-dmarc-arc-protocol-14>.
[ARC-MULTI] [ARC-MULTI]
Andersen, K., "Using Multiple Signing Algorithms with Andersen, K., Blank, S., Ed., and J. Levine, Ed., "Using
ARC", June 2018, <https://tools.ietf.org/html/ Multiple Signing Algorithms with the ARC (Authenticated
draft-ietf-dmarc-arc-multi-02>. Received Chain) Protocol", Work in Progress, draft-ietf-
dmarc-arc-multi-03, March 2019.
[ARC-TEST]
Blank, S., "ARC Test Suite", January 2017,
<https://github.com/Valimail/arc_test_suite>.
[ARC-USAGE] [ARC-USAGE]
Jones, S., Adams, T., Rae-Grant, J., and K. Andersen, Jones, S., Ed. and K. Andersen, "Recommended Usage of the
"Recommended Usage of the ARC Headers", April 2018, Authenticated Received Chain (ARC)", Work in Progress,
<https://tools.ietf.org/html/ draft-ietf-dmarc-arc-usage-07, April 2019.
draft-ietf-dmarc-arc-usage-05>.
[ENHANCED-STATUS]
"IANA SMTP Enhanced Status Codes", n.d.,
<http://www.iana.org/assignments/smtp-enhanced-status-
codes/smtp-enhanced-status-codes.xhtml>.
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
Message Authentication, Reporting, and Conformance Message Authentication, Reporting, and Conformance
(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
<https://www.rfc-editor.org/info/rfc7489>. <https://www.rfc-editor.org/info/rfc7489>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky, [RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky,
E., Ed., and K. Andersen, Ed., "Interoperability Issues E., Ed., and K. Andersen, Ed., "Interoperability Issues
between Domain-based Message Authentication, Reporting, between Domain-based Message Authentication, Reporting,
and Conformance (DMARC) and Indirect Email Flows", and Conformance (DMARC) and Indirect Email Flows",
RFC 7960, DOI 10.17487/RFC7960, September 2016, RFC 7960, DOI 10.17487/RFC7960, September 2016,
<https://www.rfc-editor.org/info/rfc7960>. <https://www.rfc-editor.org/info/rfc7960>.
13.3. URIs
[1] mailto:arc-discuss@dmarc.org
[2] mailto:arc-discuss@dmarc.org
[3] https://github.com/Valimail/arc_test_suite
[4] mailto:arc-discuss@dmarc.org
[5] mailto:openarc-users@openarc.org
[6] mailto:dmarc@ietf.org
[7] mailto:arc-discuss@dmarc.org
[8] mailto:arc-interop@dmarc.org
[9] https://arc-spec.org
Appendix A. Design Requirements Appendix A. Design Requirements
The specification of the ARC framework is driven by the following The specification of the ARC framework is driven by the following
high-level goals, security considerations, and practical operational high-level goals, security considerations, and practical operational
requirements. requirements.
A.1. Primary Design Criteria A.1. Primary Design Criteria
o Provide a verifiable "chain of custody" for email messages; o Provide a verifiable "chain of custody" for email messages;
skipping to change at page 37, line 20 skipping to change at page 33, line 7
Authentication-Results across trust boundaries. Authentication-Results across trust boundaries.
A.2. Out of Scope A.2. Out of Scope
ARC is not a trust framework. Users of the ARC header fields are ARC is not a trust framework. Users of the ARC header fields are
cautioned against making unsubstantiated conclusions when cautioned against making unsubstantiated conclusions when
encountering a "broken" ARC sequence. encountering a "broken" ARC sequence.
Appendix B. Example Usage Appendix B. Example Usage
The following message is an example of one which has passed through The following message is an example of one that has passed through
several intermediary handlers, some of which have modified the several intermediary handlers, some of which have modified the
message and others which have not: message and others which have not:
Return-Path: <jqd@d1.example> Return-Path: <jqd@d1.example>
Received: from example.org (example.org [208.69.40.157]) Received: from example.org (example.org [208.69.40.157])
by gmail.example with ESMTP id d200mr22663000ykb.93.1421363207 by gmail.example with ESMTP id d200mr22663000ykb.93.1421363207
for <fmartin@example.com>; Thu, 14 Jan 2015 15:02:40 -0800 (PST) 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]) 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 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) for <arc@example.org>; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
skipping to change at page 39, line 5 skipping to change at page 35, line 5
Message-ID: <54B84785.1060301@d1.example> Message-ID: <54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800 Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe <jqd@d1.example> From: John Q Doe <jqd@d1.example>
To: arc@dmarc.example To: arc@dmarc.example
Subject: [List 2] Example 1 Subject: [List 2] Example 1
Hey gang, Hey gang,
This is a test message. This is a test message.
--J. --J.
Appendix C. Acknowledgements Acknowledgments
This draft originated with the work of OAR-Dev Group. This document originated with the work of OAR-Dev Group.
The authors thank all of the OAR-Dev and the subsequent DMARC-WG The authors thank all of the OAR-Dev and the subsequent DMARC WG for
group for the ongoing help and though-provoking discussions from all the ongoing help and thought-provoking discussions from all the
the participants, especially: Alex Brotman, Brandon Long, Dave participants, especially J. Trent Adams, Marc Bradshaw, Alex Brotman,
Crocker, Elizabeth Zwicky, Franck Martin, Greg Colburn, J. Trent Greg Colburn, Dave Crocker, Tim Draegen, Mark Eissler, Peter
Adams, John Rae-Grant, Mike Hammer, Mike Jones, Steve Jones, Terry Goldstein, Bron Gondwana, Mike Hammer, Mike Jones, Steve Jones, Scott
Zink, Tim Draegen, Gene Shuman, Scott Kitterman, Bron Gondwana. 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 Grateful appreciation is extended to the people who provided feedback
through the discuss mailing list. through the arc-discuss mailing list.
Appendix D. Comments and Feedback
Please address all comments, discussions, and questions to
dmarc@ietf.org [6]. Earlier discussions can be found at arc-
discuss@dmarc.org [7]. Interop discussions planning can be found at
arc-interop@dmarc.org [8].
Some introductory material for less technical people can be found at
https://arc-spec.org [9].
Authors' Addresses Authors' Addresses
Kurt Andersen Kurt Andersen
LinkedIn LinkedIn
1000 West Maude Ave 1000 West Maude Ave
Sunnyvale, California 94085 Sunnyvale, California 94085
USA United States of America
Email: kurt+ietf@drkurt.com Email: kurt+ietf@drkurt.com
Brandon Long (editor) Brandon Long (editor)
Google Google
Email: blong@google.com Email: blong@google.com
Seth Blank (editor) Seth Blank (editor)
Valimail Valimail
 End of changes. 201 change blocks. 
740 lines changed or deleted 380 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/