draft-ietf-dmarc-arc-protocol-16.txt   draft-ietf-dmarc-arc-protocol-17.txt 
DMARC Working Group K. Andersen DMARC Working Group K. Andersen
Internet-Draft LinkedIn Internet-Draft LinkedIn
Intended status: Experimental B. Long, Ed. Intended status: Experimental B. Long, Ed.
Expires: January 18, 2019 Google Expires: April 4, 2019 Google
S. Blank, Ed. S. Blank, Ed.
Valimail Valimail
M. Kucherawy, Ed. M. Kucherawy, Ed.
TDP TDP
T. Draegen, Ed. October 1, 2018
dmarcian
July 17, 2018
Authenticated Received Chain (ARC) Protocol Authenticated Received Chain (ARC) Protocol
draft-ietf-dmarc-arc-protocol-16 draft-ietf-dmarc-arc-protocol-17
Abstract Abstract
The Authenticated Received Chain (ARC) protocol allows Internet Mail The Authenticated Received Chain (ARC) protocol provides an
Handlers to attach assertions of message authentication state to authenticated "chain of custody" for a message, allowing each entity
individual messages. As messages traverse ARC-enabled Internet Mail that handles the message to see what entities handled it before, and
Handlers, additional ARC assertions can be attached to messages to to see what the message's authentication assessment was at each step
form ordered sets of ARC assertions that represent authentication in the handling.
state along each step of message handling paths.
ARC allows Internet Mail Handlers to attach assertions of message
authentication assessment to individual messages. As messages
traverse ARC-enabled Internet Mail Handlers, additional ARC
assertions can be attached to messages to form ordered sets of ARC
assertions that represent the authentication assessment at each step
of 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, to identify Internet Mail
Handlers that might break existing authentication mechanisms, and to Handlers that might break existing authentication mechanisms, and to
convey original authentication state 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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 4, 2019.
This Internet-Draft will expire on January 18, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . 5
2.4. Validation of Chain of Custody . . . . . . . . . . . . . 5 2.4. Validation of Chain of Custody . . . . . . . . . . . . . 5
3. Terminology and Definitions . . . . . . . . . . . . . . . . . 5 3. Terminology and Definitions . . . . . . . . . . . . . . . . . 6
3.1. ARC Set . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. ARC Set . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Authenticated Received Chain (ARC) . . . . . . . . . . . 6 3.2. Authenticated Received Chain (ARC) . . . . . . . . . . . 7
3.3. Sealer . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Internet Mail Handlers / Intermediaries . . . . . . . . . 7
3.4. Validator . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Authentication Assessment . . . . . . . . . . . . . . . . 7
3.5. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . 7 3.5. Signing vs Sealing . . . . . . . . . . . . . . . . . . . 7
3.6. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . 7 3.6. Sealer . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 7 3.7. Validator . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. ARC Headers . . . . . . . . . . . . . . . . . . . . . . . 7 3.8. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . 8
4.1.1. ARC-Authentication-Results (AAR) . . . . . . . . . . 8 3.9. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . 8
4.1.2. ARC-Message-Signature (AMS) . . . . . . . . . . . . . 8 4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 8
4.1.3. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . 9 4.1. ARC Header Fields . . . . . . . . . . . . . . . . . . . . 8
4.2. ARC Set . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1.1. ARC-Authentication-Results (AAR) . . . . . . . . . . 9
4.2.1. Instance Tags . . . . . . . . . . . . . . . . . . . . 10 4.1.2. ARC-Message-Signature (AMS) . . . . . . . . . . . . . 9
4.3. Authenticated Received Chain . . . . . . . . . . . . . . 11 4.1.3. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . 10
4.4. Chain Validation Status . . . . . . . . . . . . . . . . . 11 4.1.4. Internationalized Email (EAI) . . . . . . . . . . . . 11
5. Protocol Actions . . . . . . . . . . . . . . . . . . . . . . 12 4.2. ARC Set . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Sealer Actions . . . . . . . . . . . . . . . . . . . . . 12 4.2.1. Instance Tags . . . . . . . . . . . . . . . . . . . . 12
5.1.1. Header Fields To Include In ARC-Seal Signatures . . . 13 4.3. Authenticated Received Chain . . . . . . . . . . . . . . 12
5.1.2. Marking and Sealing "cv=fail" (Invalid) Chains . . . 13 4.4. Chain Validation Status . . . . . . . . . . . . . . . . . 13
5.1.3. Only One Authenticated Received Chain Per Message . . 13 5. Protocol Actions . . . . . . . . . . . . . . . . . . . . . . 13
5.1.4. Broad Ability to Seal . . . . . . . . . . . . . . . . 14 5.1. Sealer Actions . . . . . . . . . . . . . . . . . . . . . 14
5.1.5. Sealing is Always Safe . . . . . . . . . . . . . . . 14 5.1.1. Header Fields To Include In ARC-Seal Signatures . . . 15
5.1.6. Signing vs Sealing . . . . . . . . . . . . . . . . . 14 5.1.2. Marking and Sealing "cv=fail" (Invalid) Chains . . . 15
5.2. Validator Actions . . . . . . . . . . . . . . . . . . . . 14 5.1.3. Only One Authenticated Received Chain Per Message . . 15
5.2.1. All Failures Are Permanent . . . . . . . . . . . . . 16 5.1.4. Broad Ability to Seal . . . . . . . . . . . . . . . . 16
5.1.5. Sealing is Always Safe . . . . . . . . . . . . . . . 16
5.2. Validator Actions . . . . . . . . . . . . . . . . . . . . 16
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 . . . . . . . . . . . . . . . . . . . . . 16 Transaction . . . . . . . . . . . . . . . . . . . . . 18
5.3. Result of Validation . . . . . . . . . . . . . . . . . . 16 6. Communication of Validation Results . . . . . . . . . . . . . 18
6. Communication of Validation Results . . . . . . . . . . . . . 17 7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.1. Communicate Authentication Assessment Across Trust
7.1. Communicate Authentication Results Across Trust Boundaries . . . . . . . . . . . . . . . . . . . . . . . 19
Boundaries . . . . . . . . . . . . . . . . . . . . . . . 17 7.1.1. Message Scanning Services . . . . . . . . . . . . . . 19
7.1.1. Message Scanning Services . . . . . . . . . . . . . . 17 7.1.2. Multi-tier MTA Processing . . . . . . . . . . . . . . 19
7.1.2. Multi-tier MTA Processing . . . . . . . . . . . . . . 18 7.1.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 20
7.1.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 18 7.2. Inform Message Disposition Decisions . . . . . . . . . . 20
7.2. Inform Message Disposition Decisions . . . . . . . . . . 18 7.2.1. DMARC Local Policy Overrides . . . . . . . . . . . . 20
7.2.1. DMARC Local Policy Overrides . . . . . . . . . . . . 19 7.2.2. DMARC Reporting . . . . . . . . . . . . . . . . . . . 21
7.2.2. DMARC Reporting . . . . . . . . . . . . . . . . . . . 19 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 9.1. Increased Header Field Size . . . . . . . . . . . . . . . 22
9.1. Increased Header Size . . . . . . . . . . . . . . . . . . 20 9.2. DNS Operations . . . . . . . . . . . . . . . . . . . . . 22
9.2. DNS Operations . . . . . . . . . . . . . . . . . . . . . 21 9.3. Message Content Suspicion . . . . . . . . . . . . . . . . 23
9.3. Message Content Suspicion . . . . . . . . . . . . . . . . 21 9.4. Message Sealer Suspicion . . . . . . . . . . . . . . . . 23
9.4. Message Sealer Suspicion . . . . . . . . . . . . . . . . 21 9.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 23
9.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 22 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 10.1. Email Authentication Results Names Registry Update . . . 24
10.1. Email Authentication Results Names Registry Update . . . 22 10.2. Email Authentication Methods Registry Update . . . . . . 24
10.2. Email Authentication Methods Registry Update . . . . . . 22 10.3. Definitions of the ARC header fields . . . . . . . . . . 24
10.3. Definitions of the ARC header fields . . . . . . . . . . 23 10.4. New Enhanced Status Code - ARC Validation . . . . . . . 25
11. Experimental Considerations . . . . . . . . . . . . . . . . . 23 11. Experimental Considerations . . . . . . . . . . . . . . . . . 25
11.1. Success Consideration . . . . . . . . . . . . . . . . . 24 11.1. Success Consideration . . . . . . . . . . . . . . . . . 25
11.2. Failure Considerations . . . . . . . . . . . . . . . . . 24 11.2. Failure Considerations . . . . . . . . . . . . . . . . . 26
11.3. Open Questions . . . . . . . . . . . . . . . . . . . . . 24 11.3. Open Questions . . . . . . . . . . . . . . . . . . . . . 26
11.3.1. Value of the ARC-Seal (AS) Header . . . . . . . . . 24 11.3.1. Value of the ARC-Seal (AS) Header Field . . . . . . 26
11.3.2. DNS Overhead . . . . . . . . . . . . . . . . . . . . 24 11.3.2. Usage and/or signals from multiple selectors and/or
11.3.3. What Trace Information is Valuable . . . . . . . . . 25 domains in ARC sets . . . . . . . . . . . . . . . . 26
12. Implementation Status . . . . . . . . . . . . . . . . . . . . 25 11.3.3. DNS Overhead . . . . . . . . . . . . . . . . . . . . 26
12.1. GMail test reflector and incoming validation . . . . . . 26 11.3.4. What Trace Information is Valuable . . . . . . . . . 27
12.2. AOL test reflector and internal tagging . . . . . . . . 26 12. Implementation Status . . . . . . . . . . . . . . . . . . . . 27
12.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 27 12.1. GMail test reflector and incoming validation . . . . . . 28
12.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . 27 12.2. AOL test reflector and internal tagging . . . . . . . . 28
12.5. Mailman 3.x patch . . . . . . . . . . . . . . . . . . . 27 12.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 29
12.6. Copernica/MailerQ web-based validation . . . . . . . . . 28 12.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . 29
12.7. Rspamd . . . . . . . . . . . . . . . . . . . . . . . . . 28 12.5. Mailman 3.x patch . . . . . . . . . . . . . . . . . . . 29
12.8. PERL MAIL::DKIM module . . . . . . . . . . . . . . . . . 29 12.6. Copernica/MailerQ web-based validation . . . . . . . . . 30
12.9. PERL Mail::Milter::Authentication module . . . . . . . . 29 12.7. Rspamd . . . . . . . . . . . . . . . . . . . . . . . . . 30
12.10. Sympa List Manager . . . . . . . . . . . . . . . . . . . 29 12.8. PERL MAIL::DKIM module . . . . . . . . . . . . . . . . . 31
12.11. Oracle Messaging Server . . . . . . . . . . . . . . . . 30 12.9. PERL Mail::Milter::Authentication module . . . . . . . . 31
12.12. MessageSystems Momentum and PowerMTA platforms . . . . . 30 12.10. Sympa List Manager . . . . . . . . . . . . . . . . . . . 31
12.13. Exim . . . . . . . . . . . . . . . . . . . . . . . . . . 30 12.11. Oracle Messaging Server . . . . . . . . . . . . . . . . 32
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 12.12. MessageSystems Momentum and PowerMTA platforms . . . . . 32
13.1. Normative References . . . . . . . . . . . . . . . . . . 31 12.13. Exim . . . . . . . . . . . . . . . . . . . . . . . . . . 32
13.2. Informative References . . . . . . . . . . . . . . . . . 32 12.14. Halon MTA . . . . . . . . . . . . . . . . . . . . . . . 32
13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 33 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
Appendix A. Appendix A - Design Requirements . . . . . . . . . . 33 13.1. Normative References . . . . . . . . . . . . . . . . . . 33
A.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 34 13.2. Informative References . . . . . . . . . . . . . . . . . 34
A.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 34 13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Appendix B. Appendix B - Example Usage . . . . . . . . . . . . . 34 Appendix A. Appendix A - Design Requirements . . . . . . . . . . 36
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 34 A.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 36
Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 35 A.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 Appendix B. Appendix B - Example Usage . . . . . . . . . . . . . 36
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 37
Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
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].
The utility of technologies that build upon SPF and DKIM (such as DMARC [RFC7489] also relies upon SPF and DKIM authentication
DMARC [RFC7489]) is similarly impacted by intermediate handlers. The mechanisms. Failures of authentication caused by the actions of
disruption of authentication mechanisms for legitimate messages by intermediate handlers can cause legitimate mail to be incorrectly
intermediate handlers can impact all aspects of Internet Mail - rejected or misdirected.
message authors, message recipients, and even the intermediary
handler itself.
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 processing results Internet Mail Handlers to add their authentication assessment to a
to a message's ordered set of processing results. ARC encapsulates message's ordered set of handling results. ARC encapsulates the
processing results in a DKIM signature derivative to grant other authentication assessment in a DKIM signature derivative to grant
handlers the ability to verify the authenticity of the individual other handlers the ability to verify the authenticity of the
processing results as well as the aggregate set and sequence of individual assessment assertion as well as the aggregate set and
results. sequence of results.
Ordered sets of processing results 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, to
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 to 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
state at any point along the delivery path between origination and assessment at any point along the delivery path between origination
final delivery. Authentication state can change when intermediate and final delivery. Determination of message authentication can be
handlers modify message content (headers and/or body content), route affected when intermediate handlers modify message content (header
messages through unforeseen paths, or change envelope information. fields and/or body content), route messages through unforeseen paths,
or change envelope information.
The authentication state of a message is determined upon receipt of a The authentication assessment for a message is determined upon
message and documented in the Authentication-Results header field(s). receipt of a message and documented in the Authentication-Results
ARC extends this mechanism to survive transit through intermediary header field(s). ARC extends this mechanism to survive transit
ADMDs. through intermediary ADMDs.
Because the first-hand determination of an authentication assessment
can never be reproduced by other handlers, the assertion of the
authentication assessment is more akin to testimony by a verifiable
party than hard evidence which can be independently evaluated.
2.2. Custody 2.2. Custody
"Custody" refers to when an ARC-enabled Internet Mail Handler "Custody" refers to when an Internet Mail Handler processes a
processes a message. When a handler takes custody of a message, the message. When a handler takes custody of a message, the handler
handler becomes a Custodian and attaches their own evidence becomes a custodian and attaches their own evidence (authentication
(authentication state upon receipt) to the message. Evidence is assessment upon receipt) to the message if they are ARC-enabled.
added in such a way so that future handlers can verify the Evidence is added in such a way so that future handlers can verify
authenticity of both evidence and custody. the 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
evidence and custody to yield a valid Chain of Custody. If the custody and the authentication assessments asserted by each party to
evidence-supplying Custodians can be trusted, then the validated yield a valid Chain of Custody. If the evidence-supplying custodians
Chain of Custody describes the (possibly changing) authentication can be trusted, then the validated Chain of Custody describes the
state as the message traveled through various Custodians. (possibly changing) authentication assessment as the message traveled
through various custodians.
Even though a message's authentication state might have changed, the Even though a message's authentication assessment might have changed,
validated chain of custody can be used to determine if the changes the validated chain of custody can be used to determine if the
(and the Custodians responsible for the changes) can be tolerated. changes (and the custodians responsible for the changes) can be
tolerated.
3. Terminology and Definitions 3. Terminology and Definitions
This section defines terms used in the rest of the document. This section defines terms used in the rest of the document.
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 definitions found in [RFC5598]. The potential roles of transit
intermediaries 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 Agents (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
Internet Mail Handlers process and deliver messages across the
Internet and include MSAs, MTAs, MDAs, gateways, and mailing lists.
Syntax descriptions use Augmented BNF (ABNF) [RFC5234] and [RFC7405]. Syntax descriptions use Augmented BNF (ABNF) [RFC5234] and [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. These words may also appear in this
document in lower case as plain English words, absent their normative document in lower case as plain English words, absent their normative
meanings. meanings.
3.1. ARC Set 3.1. ARC Set
Section 4.1 introduces three (3) ARC header fields. Together, the 3 Section 4.1 introduces three (3) ARC header fields which are added to
header fields compose a single "ARC Set". An ARC Set provides the a message by an ARC-enabled internet mail handler. Together, these
means for an Internet Mail Handler to attach authentication state to three header fields compose a single "ARC Set". An ARC Set provides
a message in a manner that can be verified by future handlers. A the means for an Internet Mail Handler to attach an authentication
single message can contain multiple ARC Sets. assessment to a message in a manner that can be verified by future
handlers. A single message can contain multiple ARC Sets.
In General Concept terms, an ARC Set represents Evidence and Custody. In general concept terms, an ARC Set represents Evidence and Custody.
3.2. Authenticated Received Chain (ARC) 3.2. Authenticated Received Chain (ARC)
The complete sequence of ARC Sets attached to a message is called the The sequence of ARC Sets attached to a message at a given time is
Authenticated Received Chain. An Authenticated Received Chain is a called the Authenticated Received Chain. An Authenticated Received
recording of individual authentication states as a message traverses Chain is the record of individual authentication assessments as a
through ARC-participating ADMDs. 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. Chain of Custody.
3.3. Sealer 3.3. Internet Mail Handlers / Intermediaries
Internet Mail Handlers process and deliver messages across the
Internet and include MSAs, MTAs, MDAs, gateways, and mailing lists as
defined in [RFC5598].
Throughout this document the term "intermediaries" refers to the both
regular MTAs as well as delivery/reposting agents such as mailing
lists covered within the scope of [RFC5598]'s transit services.
"Intermediaries" and "Internet Mail Handlers" are used synonomously
throughout this document.
3.4. Authentication Assessment
The Authentication Assessment which is affixed to a message as part
of each ARC Set consists of the "authres-payload" [I-D-7601bis]. For
the integrity of an ARC Set, the Authentication Assessment only needs
to be properly encapsulated within the ARC Set as defined below
Section 4.1. The accuracy or syntax of the authres-payload field
does not affect the validity of the ARC chain itself.
3.5. Signing vs Sealing
Signing is the process of affixing a digital signature to a message
as a header field, such as when a DKIM-Signature (as in [RFC6376]
section 2.1), or an AMS or AS is added. Sealing is when an ADMD
affixes a complete and valid ARC Set to a message creating or
continuing an Authenticated Received Chain.
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 Evidence and proof of Custody In general concept terms, a Sealer adds its testimony (assertion of
to the Chain of Custody. authentication assessment) and proof of custody to the Chain of
Custody.
3.4. 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.5. 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 ([I-D-7601bis] section 2.2)
o cfws ([RFC5322] section 3.2.2) o cfws ([RFC5322] section 3.2.2)
3.6. 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] "=" [CFWS] position [CFWS] ";" instance = [CFWS] %s"i" [CFWS] "="
[CFWS] position
chain-status = ("none" / "fail" / "pass") chain-status = ("none" / "fail" / "pass")
seal-cv-tag = %s"cv" [CFWS] "=" [CFWS] chain-status seal-cv-tag = %s"cv" [CFWS] "="
[CFWS] chain-status
4. Protocol Elements 4. Protocol Elements
4.1. ARC Headers 4.1. ARC Header Fields
ARC introduces three new header fields. Syntax for new header fields ARC introduces three new header fields. Syntax for new header fields
borrows heavily from existing specifications. This document only adapts existing specifications. This document only describes where
describes where ARC-specific changes in syntax and semantics differ ARC-specific changes in syntax and semantics differ from existing
from existing specifications. 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 state as processed by an ARC-participating ADMD at authentication assessment as processed by an ARC-participating ADMD
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 [I-D-7601bis], with two (2) differences:
o the name of the header field itself; o the name of the header field itself;
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 all authentication results from within the participating contain the combined authres-payload with all of the authentication
ADMD, regardless of how many Authentication-Results headers are results from within the participating ADMD, regardless of how many
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.
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 is similar in syntax and semantics to a 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;
o the presence of the "instance tag". Additional information on the o the "i" (AUID) tag is not imported from DKIM; instead, this tag is
"instance tag" can be found in Section 4.2.1. The instance tag replaced by the "instance tag" as defined in Section 4.2.1;
replaces the DKIM "AUID" tag;
o when building the header field list to be signed, ARC-related
headers MUST be submitted to the hash function in increasing
instance order.
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 avoid unwanted 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 [I-D-7601bis] 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, ARC-Seal) MUST NOT be included in the list of
header fields covered by the signature of the AMS header field. 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 is the mechanism by which ARC- The ARC-Seal (AS) header field permits ARC-participating ADMDs to
participating ADMDs can verify the integrity of AAR header fields and verify the integrity of AAR header fields and corresponding AMS
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
Evidence into a Chain of Custody so that Validators can inspect their authentication assessments (testimonial) into a Chain of
individual Evidence and Custodians. Custody so that Validators can inspect individual evidence and
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: Signatures [RFC6376], with the following differences:
o the presence of the "instance tag". Additional information on the o the "i" (AUID) tag is not imported from DKIM; instead, this tag is
"instance tag" can be found 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 and 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 canonicalization ([RFC6376] section 3.4.2) o only "relaxed" header field canonicalization ([RFC6376] section
is used. 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", "t" from [RFC6376] Section 3.5.
Note especially that the DKIM "h" tag is NOT allowed and if found, Note especially that the DKIM "h" tag is NOT allowed and if found,
MUST result in a cv status of "fail" (for more information see MUST result in a cv status of "fail" (for more information see
Section 5.1.1); Section 5.1.1);
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 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)
In internationalized messages [RFC6532] many header fields can
contain UTF-8 as well as ASCII text. The changes for EAI are all
inherited from DKIM as updated by [draft-levine-eaiauth] and
Authentication-Results as updated in [I-D-7601bis], but are called
out here for emphasis.
In all ARC header fields, the d= s= tags can contain U-labels. In
all tags, non-ASCII characters need not be quoted in dkim-quoted-
printable.
The AAR header allows UTF-8 in the same places that A-R does, as
described in [I-D-7601bis].
4.2. ARC Set 4.2. ARC Set
An "ARC Set" is a single collection of three ARC Headers (AAR, AMS, An "ARC Set" is a single collection of three ARC header fields (AAR,
and AS). ARC Headers of an ARC Set share the same "instance" value. AMS, and AS). ARC header fields of an ARC Set share the same
"instance" value.
By adding all ARC Headers to a message, an ARC Sealer adds an ARC Set By adding all ARC header fields to a message, an ARC Sealer adds an
to a message. A description of how Sealers add an ARC Set to a ARC Set to a message. A description of how Sealers add an ARC Set to
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 Headers belong to an ARC Set. Each Instance tags describe which ARC header fields belong to an ARC Set.
ARC Header of an ARC Set shares the same instance tag value. Each ARC header field of an ARC Set shares the same instance tag
value.
Instance tag values are integers that begin at 1 and are incremented 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 with a initial observations reported by early working group members. The
safety margin multiple added on top to support the vast majority of value was chosen so as to balance the risk of excessive header field
all intermediary mail flows. growth Section 9.1 against expert opinion regarding the probability
of long-tail but non-looping multiple-intermediary mail flows.
Longer ARC chains will also impose load on validators and DNS to
support additional verification steps. Observed quantities of
"Received" header fields was also considered in establishing this as
an 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.
_INFORMATIONAL:_ Initial development of ARC is only being done with a For handling multiple signing algorithms, see [ARC-MULTI].
single allowed signing algorithm, but parallel work in the DCRUP
working group is expanding that. 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 Headers, an Authenticated As ARC Sets are enumerated sets of ARC header fields, an
Received Chain represents the output of message authentication state Authenticated Received Chain represents the output of message
along the handling path of ARC-enabled processors. authentication assessments along the handling path of ARC-enabled
processors.
Results of message authentication processing along each step of the Authentication Assessments determined at each step of the ARC-enabled
ARC-enabled handling path is present in an Authenticated Received handling path is present in an Authenticated Received Chain in the
Chain in the form of AAR header fields. The ability to verify the form of AAR header fields. The ability to verify the identity of
identity of message handlers and the integrity of message content is message handlers and the integrity of message content is provided by
provided by AMS header fields. AS header fields allow messages AMS header fields. AS header fields allow messages handlers to
handlers to validate the assertions, order and sequence of the validate the assertions, order and sequence of the Authenticated
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 the AS header field in the "cv" tag, and
o as part of Authentication-Results and AAR headers. o as part of 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.
o fail: The message contains an Authenticated Received Chain whose o fail: The message contains an Authenticated Received Chain whose
validation failed. validation failed.
o pass: The message contains an Authenticated Received Chain whose o pass: The message contains an Authenticated Received Chain whose
validation succeeded. validation succeeded.
5. Protocol Actions 5. Protocol Actions
ARC-enabled Internet Mail Handlers generally act as both ARC Sealers ARC-enabled Internet Mail Handlers generally act as both ARC
(when sending messages) and ARC Validators (when receiving messages). Validators (when receiving messages) and ARC Sealers (when sending
messages onward, not originated locally).
An Authenticated Received Chain with a Chain Validation Status of
"pass" (or "none") allows Internet Mail Handlers to ascertain:
o all ARC-participating ADMDs that claim responsibility for handling
(and possibly modifying) the message in transit;
o the authentication assessments of the message as determined by
each ADMD (from AAR header fields).
With this information, Internet Mail Handlers MAY inform local policy
decisions regarding disposition of messages that experience
authentication failure due to intermediate processing.
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-Signatures) MUST 1. All message modifications (including adding DKIM-Signature header
be performed before Sealing. field(s)) MUST be performed before Sealing.
2. Calculate the instance value: if the message contains an 2. If the message already contains an Authenticated Received Chain
with the most recent AS reporting "cv=fail", then there is no
need to proceed and the algorithm stops here.
3. Calculate the instance value: if the message already contains an
Authenticated Received Chain, the instance value is 1 more than 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.
3. Using the calculated instance value, generate and attach to the 4. Using the calculated instance value, generate and attach a
message in the following order: complete ARC set to the message as follows:
4. An ARC-Authentication-Results header field as defined in 1. Generate and attach an ARC-Authentication-Results header
Section 4.1.1. field as defined in Section 4.1.1.
5. An ARC-Message-Signature header field as defined in 2. Generate and attach an ARC-Message-Signature header field as
Section 4.1.2. defined in Section 4.1.2.
6. An ARC-Seal header field using the AS definition found in 3. Generate and attach an ARC-Seal header field using the AS
Section 4.1.3, the method described in Section 5.1.1, and the definition found in Section 4.1.3, the prescribed headers
Chain Validation Status as determined during ARC validation. defined in Section 5.1.1, and the Chain Validation Status as
determined during ARC Validation.
5.1.1. Header Fields To Include In ARC-Seal Signatures 5.1.1. Header Fields To Include In ARC-Seal Signatures
The signature of an AS header field signs a specific canonicalized The ARC-Seal is generated in a manner similar to how DKIM-Signatures
form of the ARC Set header values. The ARC set header values are are added to messages ([RFC6376], section 3.7), with explicit
requirements on the header fields and ordering of those fields.
The signature of an AS header field signs a canonicalized form of the
ARC Set header field values. The ARC set header field values are
supplied to the hash function in increasing instance order, starting 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
The ARC-Seal is generated in a manner similar to when DKIM-Signatures
are added to messages ([RFC6376], section 3.7).
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 (see Section 5.1.2). the signing scope for the ARC-Seal is modified as specified in
Section 5.1.2.
5.1.2. Marking and Sealing "cv=fail" (Invalid) Chains 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 headers created by the MTA which value MUST only include the ARC Set header fields created by the MTA
detected the malformed chain, as if this newest ARC Set was the only which detected the malformed chain, as if this newest ARC Set was the
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 designed been lost. For further discussion of this topic and the design
restriction which prevents chain continuation or re-establishment, restriction which prevents chain continuation or re-establishment,
see [ARC-USAGE]. see [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 mediator ARC is not solely intended for perimeter MTAs. Any Internet Mail
([RFC5598], section 5) that modifies a message may Seal its own Handler MAY seal a message by adding a complete ARC set, whether or
changes. For additional information, see Section 7.1. not they have modified or are aware of having modified the message.
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
skipping to change at page 14, line 31 skipping to change at page 16, line 32
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.1.6. Signing vs Sealing
Signing is the process of affixing a digital signature to a message
as a header, such as when a DKIM-Signature (as in [RFC6376] section
2.1), or an AMS or AS is added. Sealing is when an ADMD affixes a
complete and valid ARC Set to a message creating or continuing an
Authenticated Received Chain.
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. If there 1. Collect all ARC Sets currently attached to the message.
are none, the Chain Validation Status is "none" and the algorithm
stops here. The maximum number of ARC Sets that can be attached * If there are none, the Chain Validation Status is "none" and
to a message is 50. If more than the maximum number exist the the algorithm stops here.
Chain Validation Status is "fail" and the algorithm stops here.
In the following algorithm, the maximum ARC instance value is * The maximum number of ARC Sets that can be attached to a
referred to as "N". message is 50. If more than the maximum number exist the
Chain Validation Status is "fail" and the algorithm stops
here.
* In the following algorithm, the maximum discovered ARC
instance value is referred to as "N".
2. If the Chain Validation Status of the highest instance value ARC 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 the
algorithm stops here. 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 1. 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 2. 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 be non- 3. The "cv" value for all ARC-Seal header fields MUST NOT be
failing. For instance values > 1, the value must be "pass". "fail". For ARC Sets with instance values > 1, the values
For instance value = 1, the value must be "none". MUST be "pass". For the ARC Set with instance value = 1, the
value MUST be "none".
* If any of these conditions are not met, the Chain Validation * 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 the N-1 and proceeding
in decreasing order to the AMS with the instance value of 1: in decreasing order to the AMS with the instance value of 1:
6. If an AMS fails to validate (for instance value "M"), then set 1. If an AMS fails to validate (for instance value "M"), then
the oldest-pass value to the lowest AMS instance value which set the oldest-pass value to the lowest AMS instance value
passed (M+1) and go to the next step (there is no need to check which passed (M+1) and go to the next step (there is no need
any other (older) AMS headers). This does not affect the to check any other (older) AMS header fields). This does not
validity of the Authenticated Received Chain. affect the validity of the Authenticated Received Chain.
7. If all AMS headers verify, set the oldest-pass value to zero (0). 2. If all AMS header fields verify, set the oldest-pass value to
zero (0).
8. 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.
9. 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 is added into the The end result of this Validation algorithm SHOULD be included within
Authentication-Results header for the ADMD. the Authentication-Results header field for the ADMD.
As with a failing DKIM signature ([RFC6376] section 6.3), a message As with a DKIM signature ([RFC6376] section 6.3) which fails
with a failing Authenticated Received Chain MUST be treated the same verification, a message with an Authenticated Received Chain with a
as a message with no Authenticated Received Chain. Chain Validation status of "fail" MUST be treated the same as a
message with no Authenticated Received Chain.
_INFORMATIONAL_: Recipients of an invalid or failing Authenticated _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
failed Chain Validation Status. For further discussion of this topic Chain Validation Status of "fail". For further discussion of this
and the design restriction which prevents chain continuation or re- topic and the design restriction which prevents chain continuation or
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 If an ARC Validator determines that the incoming message fails
authentication checks (potentially including ARC validation), the authentication checks (potentially including ARC validation), the
Validator MAY signal the breakage through the extended SMTP response Validator MAY signal the breakage through the extended SMTP response
code 5.7.7 [RFC3463] "message integrity failure" [ENHANCED-STATUS] code 5.7.29 "ARC validation failure" and corresponding SMTP basic
and corresponding SMTP response code. response code. Validators MAY use the more general 5.7.28 "Multiple
authentication checks failed" instead.
5.3. Result of Validation
An Authenticated Received Chain with a Chain Validation Status of
"pass" allows Internet Mail Handlers to ascertain:
o all ARC-participating ADMDs that claim responsibility for handling
(and possibly modifying) the message in transit;
o the authentication state of the message as perceived by each ADMD
(from Authentication-Results header fields).
Given this information, handlers can inform local policy decisions
regarding disposition of messages that experience authentication
failure due to intermediate processing.
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) headers using the auth method via Authentication-Results (and AAR) header fields using the auth
"arc". This auth method is described in Section 10.1. method "arc". This auth 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.client-ip - The connecting client IP address from which the o smtp.remote-ip - The address of the connection-initiating SMTP
message is received. 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.
Upon Sealing of a message, this Authentication-Results information
along with all other Authentications-Results added by the ADMD will
be recorded into the AAR as defined in section Section 4.1.1.
In General Concept terms, the information recorded in the ARC-
Authentication-Results header field is the Evidence that gets
attached to a message.
7. Use Cases 7. Use Cases
This section explores several messaging handling use cases that are This section explores several messaging handling use cases that are
addressed by ARC. addressed by ARC.
7.1. Communicate Authentication Results 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 authentication state to the next ADMD in the ADMD communicates its authentication assessment to the next ARC-
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
skipping to change at page 18, line 13 skipping to change at page 19, line 37
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. Re-routing 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 results 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 Large message processing infrastructure is often divided into several
processing tiers that can break authentication information between processing tiers that can break authentication information between
tiers. For example, a large site may maintain a cluster of MTAs tiers. For example, a large site may maintain a cluster of MTAs
dedicated to connection handling and enforcement of IP-based 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 communicated Authenticated Received Chains can be used to communicate
authentication state between processing tiers. authentication assessment between processing tiers.
7.1.3. Mailing Lists 7.1.3. Mailing Lists
Mailing lists resend posted messages to subscribers. A full Mailing lists take delivery of messages and re-post them to
description of authentication-related mailing list issues can be subscribers. A full description of authentication-related mailing
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 original Mailing list services can implement ARC to convey the authentication
authentication state of posted messages sent to the list's subscriber assessment of posted messages sent to the list's subscriber base.
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 state of Authenticated Received Chain to determine the authentication
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
ARC functionality allows Internet Mail Handlers to reliably identify
intermediary ADMDs and for ADMDs to expose authentication state that
can survive additional intermediary handling.
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 headers). 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;
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
state provided by different ADMDs. assessments provided by different ADMDs.
7.2.1. DMARC Local Policy Overrides 7.2.1. DMARC Local Policy Overrides
DMARC introduces a policy model where Domain Owners can request email DMARC introduces a policy model where Domain Owners can request email
receivers to reject or quarantine messages that fail DMARC alignment. receivers to reject or quarantine messages that fail DMARC alignment.
Interoperability issues between DMARC and indirect email flows are Interoperability issues between DMARC and indirect email flows are
documented in [RFC7960]. documented in [RFC7960].
Authenticated Received Chains allow DMARC processors to consider Authenticated Received Chains allow DMARC processors to consider
authentication states provided by other ADMDs. As a matter of local authentication assessments provided by other ADMDs. As a matter of
policy, a DMARC processor may choose to accept the authentication local policy, a DMARC processor MAY choose to accept the
state provided by an Authenticated Received Chain when determining if authentication assessments provided by an Authenticated Received
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. DMARC reporting of ARC- DMARC-related local policy decisions. When an ARC-enabled handler
influenced decisions is accomplished by adding a local_policy comment generates a DMARC report, it MAY indicate the influence of ARC on
containing a list of data discovered during ARC Validation, which at their local policy decision(s) by adding a reason of "local_policy"
a minimum includes: with a comment string (per [RFC7489] Appendix C) containing a list 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,
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 ams[2].d=d2.example ams[2].s=s1 <comment>arc=pass as[2].d=d2.example as[2].s=s2
as[2].d=d2.example as[2].s=s2 as[1].d=d1.example as[1].d=d1.example as[1].s=s3
as[1].s=s3 client-ip[1]=10.10.10.13</comment> remote-ip[1]=10.10.10.13</comment>
</reason> </reason>
</policy_evaluated> </policy_evaluated>
In the above example DMARC XML reporting fragment, data relating to In the above example DMARC XML reporting fragment, data relating to
specific validated ARC Sets are enumerated using array syntax (eg, specific validated ARC Sets are enumerated using array syntax (eg,
"ams[2]" means AMS header field with instance value of 2). d2.example "as[2]" means AS header field with instance value of 2). d2.example
is the Sealing domain for ARC Set #2 (i=2) and d1.example is the is the Sealing domain for ARC Set #2 (i=2) and d1.example is the
Sealing domain for ARC Set #1 (i=1). 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. DMARC report processors should be aware of this single message. Receivers of DMARC reports should be aware of this
behaviour and make the necessary accommodations. behaviour 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 and domain names. Such Identifiable Information such as IP address(es) and domain names.
information is also including in existing header fields such as the Such information is also included in existing non-ARC related header
"Received" header field. 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 [I-D-7601bis] apply
directly to this specification. directly to this specification.
As with other domain authentication technologies (such as SPF, DKIM, As with other domain authentication technologies (such as SPF, DKIM,
and DMARC), ARC makes no claims about the semantic content of and DMARC), ARC makes no claims about the semantic content of
messages. messages.
9.1. Increased Header 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
size. Large header blocks, in general, may cause failures to deliver field size. Large header field blocks, in general, may cause
or other outage scenarios for such MTAs. ARC itself would not cause failures to deliver or other outage scenarios for such MTAs. ARC
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 which 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. The difficulty of forging the signature a failure is discovered. DNS caching and the difficulty of
values should limit the extent of this load to domains under forging the signature values should limit the extent of this load
control of the attacker. Query traffic pattern analysis may to domains under control of the attacker. Query traffic pattern
expose information about downstream validating ADMD analysis may expose information about downstream validating ADMD
infrastructure. 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
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 signing domain, but whether for message handling is attributed to the Sealing domain, but whether
or not that signer 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 then resend it to many recipients without making any
modifications that invalidate the latest AMS or AS. The impact to a modifications that invalidate the latest AMS or AS. The impact to a
receiver would be more DNS lookups and signature evaluations. This receiver would be more DNS lookups and signature evaluations. This
scope of this attack can be limited by caching DNS queries and scope of this attack can be limited by caching DNS queries and
following the same signing scope guidance from [RFC6376] section following the same 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 both [[ *Note to the RFC Editors:* "dkim - header - s" is defined in
here and in [I-D-7601bis]. Please delete the overlap from whichever [I-D-7601bis]. Please adjust the list below as appropriate. ]]
document goes through the publication process after the other. ]]
This draft introduces three new headers fields and updates the Email This draft introduces three new headers fields and updates the Email
Authentication Parameters registry with one new authentication method Authentication Parameters registry with one new authentication method
and several status codes. and several status codes.
10.1. Email Authentication Results Names Registry Update 10.1. Email Authentication Results Names Registry Update
This draft adds one Auth Method with three Codes to the IANA "Email This draft adds one Auth Method with three Codes to the IANA "Email
Authentication Result Names" registry: Authentication Result Names" registry:
skipping to change at page 23, line 12 skipping to change at page 24, line 38
o Method: arc o Method: arc
Definition: [I-D.ARC] Definition: [I-D.ARC]
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
o Method: dkim o Method: dkim
Definition: [RFC6376] Definition: [I-D-7601bis]
ptype: header ptype: header
Property: s Property: s
Value: value of signature "s" tag Value: value of signature "s" tag
Status: active Status: active
Version: 1 Version: 1
10.3. Definitions of the ARC header fields 10.3. Definitions of the ARC header fields
This specification adds three new header fields to the "Permanent This specification adds three new header fields to the "Permanent
Message Header Field Registry", as follows: Message Header Field Registry", as follows:
skipping to change at page 23, line 45 skipping to change at page 25, line 22
Specification document(s): [I-D.ARC] Specification document(s): [I-D.ARC]
Related information: [RFC6376] Related information: [RFC6376]
o Header field name: ARC-Authentication-Results o Header field name: ARC-Authentication-Results
Applicable protocol: mail Applicable protocol: mail
Status: standard Status: standard
Author/Change controller: IETF Author/Change controller: IETF
Specification document(s): [I-D.ARC] Specification document(s): [I-D.ARC]
Related information: [I-D-7601bis] Related information: [I-D-7601bis]
10.4. New Enhanced Status Code - ARC Validation
o Code: X.7.29 Sample Text: ARC validation failure Associated basic
status code: 550 Description: This status code may be returned
when a message fails multiple authentication checks, including ARC
validation Reference: [I-D.ARC] Submitter: K. Andersen 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 intermediary 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
success of the protocol in accomplishing the intended benefits. success of the protocol in accomplishing the intended benefits.
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. messages, specifically resulting in equal or better delivery rates
than achieve 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 unforseen vectors are enabled by ARC, then abuse (see Section 9). If unforeseen vectors are enabled by ARC,
this protocol will be a failure. Note that weaknesses inherent in then this protocol will be a failure. Note that weaknesses inherent
the mail protocols ARC is built upon (such as DKIM replay attacks and in the mail protocols ARC is built upon (such as DKIM replay attacks
other known issues) are not new vectors which can be attributed to and other known issues) are not new vectors which can be attributed
this specification. to 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 of the development of the protocol. However, additional
deployment should be able to gather the necessary data to answer some deployments should be able to gather the necessary data to answer
or all of them. some or all of them.
11.3.1. Value of the ARC-Seal (AS) Header 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 ARC-Seal (AS) provides value
beyond the ARC Message Signature (AMS) for either making delivery beyond the ARC Message Signature (AMS) for either making delivery
decisions or catching malicious actors trying to craft or replay decisions or catching malicious actors trying to craft or replay
malicious chains. malicious chains.
11.3.2. DNS Overhead 11.3.2. Usage and/or signals from multiple selectors and/or domains in
ARC sets
Any selectors and/or (sub)domains (under the control of the sealing
ADMD) may be used for ARC header field signatures.
While implementers may choose to use various selectors and/or domains
for ARC set header fields, no compelling argument for or against such
usage has been made within the working group. As such we have chosen
to allow maximum freedom for the experimental definition of this
protocol.
Wider deployment experience and higher volumes of traffic may show
whether this is useful.
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 which 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 the DNS impact of processing Authenticated Received along with the 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.3. 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. 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.
Certain receivers believe the entire set of trace information would Further, certain receivers believe the entire set of trace
be valuable to feed into machine learning systems to identify fraud information would be valuable to feed into machine learning systems
and/or provide other signals related to message delivery. to identify fraud and/or provide other signals related to message
delivery.
It is unclear what trace information will be valuable for all At this point, however, it is unclear what trace information will be
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.
skipping to change at page 26, line 14 skipping to change at page 28, line 17
has been spent to verify the information presented here that was has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may features. Readers are advised to note that other implementations may
exist. exist.
This information is known to be correct as of the eighth This information is known to be correct as of the eighth
interoperability test event which was held on 2018-03-17 at IETF101. interoperability test event which was held on 2018-03-17 at IETF101.
For a few of the implementations, later status information was For a few of the implementations, later status information was
available as of June 2018. available as of August 2018.
12.1. GMail test reflector and incoming validation 12.1. GMail test reflector and incoming validation
Organization: Google Organization: Google
Description: Internal production implementation with both debug Description: Internal production implementation with both debug
analysis and validating + sealing pass-through function analysis and validating + sealing pass-through function
Status of Operation: Production - Incoming Validation Status of Operation: Production - Incoming Validation
Coverage: Full spec implemented as of [ARC-DRAFT-14] Coverage: Full spec implemented as of [ARC-DRAFT-14]
Licensing: Proprietary - Internal only Licensing: Proprietary - Internal only
Implementation Notes: Implementation Notes:
skipping to change at page 27, line 26 skipping to change at page 29, line 28
interoperate with the Google and AOL implementations during the interoperate with the Google and AOL implementations during the
interop on 2017-07-15 and the released version passes the tests in interop on 2017-07-15 and the released version passes the tests in
[ARC-TEST] arc_test_suite [3] with both python and python3. [ARC-TEST] arc_test_suite [3] with both python and python3.
Licensing: Open/Other (same as dkimpy package = BCD version 2) Licensing: Open/Other (same as dkimpy package = BCD version 2)
Contact Info: https://launchpad.net/dkimpy Contact Info: https://launchpad.net/dkimpy
12.4. OpenARC 12.4. OpenARC
Organization: TDP/Murray Kucherawy Organization: TDP/Murray Kucherawy
Description: Implemention of milter functionality related to the Description: Implementation of milter functionality related to the
OpenDKIM and OpenDMARC packages OpenDKIM and OpenDMARC packages
Status of Operation: Beta Status of Operation: Beta
Coverage: Built to support [ARC-DRAFT-14] Coverage: Built to support [ARC-DRAFT-14]
Licensing: Open/Other (same as OpenDKIM and OpenDMARC packages) Licensing: Open/Other (same as OpenDKIM and OpenDMARC packages)
Implementation Notes: Implementation Notes:
o The build is FreeBSD oriented but some packages have been built o Known issues have been resolved with release X
for easier deployment on RedHat-based Linux platforms.
o Some issues still exist when deploying in a chained milter
arrangement (such as OpenSPF -> OpenDKIM -> OpenDMARC -> OpenARC)
with coordination between the stages. When deployed in a
"sandwich" configuration around an MLM, there is no effective
mechanism to convey trust from the ingress (validator) to egress
(signer) instances. (_NOTE_: this is expected to resolved with a
new release of OpenDMARC expected in mid-2018.)
Contact Info: arc-discuss@dmarc.org [4] Contact Info: arc-discuss@dmarc.org [4], openarc-users@openarc.org
[5]
12.5. Mailman 3.x patch 12.5. Mailman 3.x patch
Organization: Mailman development team Organization: Mailman development team
Description: Integrated ARC capabilities within the Mailman 3.2 Description: Integrated ARC capabilities within the Mailman 3.2
package package
Status of Operation: Patch submitted Status of Operation: Patch submitted
Coverage: Based on OpenARC Coverage: Based on OpenARC
Licensing: Same as mailman package - GPL Licensing: Same as mailman package - GPL
Implementation Notes: Implementation Notes:
skipping to change at page 30, line 47 skipping to change at page 32, line 47
Organization: Exim developers Organization: Exim developers
Status of Operation: Operational; requires specific enabling for Status of Operation: Operational; requires specific enabling for
compile. compile.
Coverage: Full spec implemented as of [ARC-DRAFT-13] Coverage: Full spec implemented as of [ARC-DRAFT-13]
Licensing: GPL Licensing: GPL
Contact Info: exim-users@exim.org Contact Info: exim-users@exim.org
Implementation notes: Implementation notes:
o Implemented as of Exim 4.91 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 [ARC-DRAFT-14]
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
13. References 13. References
13.1. Normative References 13.1. Normative References
[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>.
[RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes",
RFC 3463, DOI 10.17487/RFC3463, January 2003,
<https://www.rfc-editor.org/info/rfc3463>.
[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>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008, DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>. <https://www.rfc-editor.org/info/rfc5322>.
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
skipping to change at page 31, line 37 skipping to change at page 33, line 41
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76, "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011, RFC 6376, DOI 10.17487/RFC6376, September 2011,
<https://www.rfc-editor.org/info/rfc6376>. <https://www.rfc-editor.org/info/rfc6376>.
[RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and
Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377, Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377,
September 2011, <https://www.rfc-editor.org/info/rfc6377>. September 2011, <https://www.rfc-editor.org/info/rfc6377>.
[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized
Email Headers", RFC 6532, DOI 10.17487/RFC6532, February
2012, <https://www.rfc-editor.org/info/rfc6532>.
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1", RFC 7208, Authorizing Use of Domains in Email, Version 1", RFC 7208,
DOI 10.17487/RFC7208, April 2014, DOI 10.17487/RFC7208, April 2014,
<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>.
[RFC7601] Kucherawy, M., "Message Header Field for Indicating [RFC7601] Kucherawy, M., "Message Header Field for Indicating
skipping to change at page 32, line 46 skipping to change at page 35, line 11
[ARC-TEST] [ARC-TEST]
Blank, S., "ARC Test Suite", January 2017, Blank, S., "ARC Test Suite", January 2017,
<https://github.com/Valimail/arc_test_suite>. <https://github.com/Valimail/arc_test_suite>.
[ARC-USAGE] [ARC-USAGE]
Jones, S., Adams, T., Rae-Grant, J., and K. Andersen, Jones, S., Adams, T., Rae-Grant, J., and K. Andersen,
"Recommended Usage of the ARC Headers", April 2018, "Recommended Usage of the ARC Headers", April 2018,
<https://tools.ietf.org/html/ <https://tools.ietf.org/html/
draft-ietf-dmarc-arc-usage-05>. draft-ietf-dmarc-arc-usage-05>.
[draft-levine-eaiauth]
Levine, J., "E-mail Authentication for Internationalized
Mail", August 2018, <https://tools.ietf.org/html/
draft-levine-appsarea-eaiauth-03>.
[ENHANCED-STATUS] [ENHANCED-STATUS]
"IANA SMTP Enhanced Status Codes", n.d., "IANA SMTP Enhanced Status Codes", n.d.,
<http://www.iana.org/assignments/smtp-enhanced-status- <http://www.iana.org/assignments/smtp-enhanced-status-
codes/smtp-enhanced-status-codes.xhtml>. codes/smtp-enhanced-status-codes.xhtml>.
[I-D-7601bis] [I-D-7601bis]
Kucherawy, M., "Message Header Field for Indicating Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", February 2018, Message Authentication Status", February 2018,
<https://datatracker.ietf.org/doc/ <https://datatracker.ietf.org/doc/
draft-ietf-dmarc-rfc7601bis/>. draft-ietf-dmarc-rfc7601bis/>.
skipping to change at page 33, line 38 skipping to change at page 36, line 5
13.3. URIs 13.3. URIs
[1] mailto:arc-discuss@dmarc.org [1] mailto:arc-discuss@dmarc.org
[2] mailto:arc-discuss@dmarc.org [2] mailto:arc-discuss@dmarc.org
[3] https://github.com/Valimail/arc_test_suite [3] https://github.com/Valimail/arc_test_suite
[4] mailto:arc-discuss@dmarc.org [4] mailto:arc-discuss@dmarc.org
[5] https://trac.ietf.org/trac/dmarc/ticket/17 [5] mailto:openarc-users@openarc.org
[6] mailto:dmarc@ietf.org [6] https://trac.ietf.org/trac/dmarc/ticket/17
[7] mailto:arc-discuss@dmarc.org [7] mailto:dmarc@ietf.org
[8] mailto:arc-interop@dmarc.org [8] mailto:arc-discuss@dmarc.org
[9] https://arc-spec.org [9] mailto:arc-interop@dmarc.org
[10] https://arc-spec.org
Appendix A. Appendix A - Design Requirements Appendix A. Appendix A - Design Requirements
[[ Note: This section is re-inserted for background information from
early versions of the spec. ]]
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;
o Not require changes for originators of email; o Not require changes for originators of email;
skipping to change at page 34, line 30 skipping to change at page 36, line 45
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. Appendix B - Example Usage Appendix B. Appendix B - Example Usage
[[ Note: The following examples were mocked up early in the [[ TODO: There have been several small changes to the spec that have
definition process for the spec. They no longer reflect the current invalidated all the old examples. Those old examples have been
definition and need various updates which will be included in a removed to prevent confusion. New examples will be forthcoming
future draft. Issue 17 [5] ]] shortly (early October, 2018) as existing software comes up to date
with the spec and can independently generate and validate the
[[ Note: Need input from the WG as to what sort of sequence of examples. Issue 17 [6] ]]
examples would be considered useful - otherwise we'll just drop this
section entirely. ]]
<removed for now to reduce confusion> <removed for now to reduce confusion>
Appendix C. Acknowledgements Appendix C. Acknowledgements
This draft originated with the work of OAR-Dev Group. This draft originated with the work of OAR-Dev Group.
The authors thank all of the OAR-Dev group for the ongoing help and The authors thank all of the OAR-Dev group for the ongoing help and
though-provoking discussions from all the participants, especially: though-provoking discussions from all the participants, especially:
Alex Brotman, Brandon Long, Dave Crocker, Elizabeth Zwicky, Franck Alex Brotman, Brandon Long, Dave Crocker, Elizabeth Zwicky, Franck
Martin, Greg Colburn, J. Trent Adams, John Rae-Grant, Mike Hammer, Martin, Greg Colburn, J. Trent Adams, John Rae-Grant, Mike Hammer,
Mike Jones, Steve Jones, Terry Zink, Tim Draegen. Mike Jones, Steve Jones, Terry Zink, Tim Draegen, Gene Shuman, Scott
Kitterman, Bron Gondwana.
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 discuss mailing list.
Appendix D. Comments and Feedback Appendix D. Comments and Feedback
Please address all comments, discussions, and questions to Please address all comments, discussions, and questions to
dmarc@ietf.org [6]. Earlier discussions can be found at arc- dmarc@ietf.org [7]. Earlier discussions can be found at arc-
discuss@dmarc.org [7]. Interop discussions planning can be found at discuss@dmarc.org [8]. Interop discussions planning can be found at
arc-interop@dmarc.org [8]. arc-interop@dmarc.org [9].
Some introductory material for less technical people can be found at Some introductory material for less technical people can be found at
https://arc-spec.org [9]. https://arc-spec.org [10].
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 USA
Email: kurta@linkedin.com Email: kurta@linkedin.com
skipping to change at page 35, line 37 skipping to change at page 38, line 4
Brandon Long (editor) Brandon Long (editor)
Google Google
Email: blong@google.com Email: blong@google.com
Seth Blank (editor) Seth Blank (editor)
Valimail Valimail
Email: seth@valimail.com Email: seth@valimail.com
Murray Kucherawy (editor) Murray Kucherawy (editor)
TDP TDP
Email: superuser@gmail.com Email: superuser@gmail.com
Tim Draegen (editor)
dmarcian
Email: tim@dmarcian.com
 End of changes. 142 change blocks. 
417 lines changed or deleted 511 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/