draft-ietf-dmarc-arc-protocol-14.txt   draft-ietf-dmarc-arc-protocol-15.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: October 25, 2018 Google Expires: December 26, 2018 Google
S. Jones, Ed.
TDP
S. Blank, Ed. S. Blank, Ed.
Valimail Valimail
M. Kucherawy, Ed. M. Kucherawy, Ed.
TDP TDP
April 23, 2018 T. Draegon, Ed.
dmarcian
June 24, 2018
Authenticated Received Chain (ARC) Protocol Authenticated Received Chain (ARC) Protocol
draft-ietf-dmarc-arc-protocol-14 draft-ietf-dmarc-arc-protocol-15
Abstract Abstract
The Authenticated Received Chain (ARC) protocol creates a mechanism The Authenticated Received Chain (ARC) protocol allows Internet Mail
whereby a series of handlers of an email message can conduct Handlers to attach assertions of message authentication state to
authentication of the email message as it passes among them on the individual messages. As messages traverse ARC-enabled Internet Mail
way to its destination, and create an attached, authenticated record Handlers, additional ARC assertions can be attached to messages to
of the status at each step along the handling path, for use by the form ordered sets of ARC assertions that represent authentication
final recipient in making choices about the disposition of the state along each step of message handling paths.
message. Changes in the message that might break existing
authentication mechanisms can be identified through the ARC Set of ARC-enabled Internet Mail Handlers can process sets of ARC assertions
header fields. to inform message disposition decisions, to identify Internet Mail
Handlers that might break existing authentication mechanisms, and to
convey original authentication state 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 October 25, 2018. This Internet-Draft will expire on December 26, 2018.
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
1.1. General Concepts . . . . . . . . . . . . . . . . . . . . 5 1.1. Note to Reviewers in the DMARC WG . . . . . . . . . . . . 4
1.2. Differences Between ARC and DKIM . . . . . . . . . . . . 5 2. General Concepts . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Definitions and Terminology . . . . . . . . . . . . . . . 6 2.1. Evidence . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1. Terms defined and used in this document . . . . . . . 6 2.2. Custody . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.2. Referenced Definitions . . . . . . . . . . . . . . . 7 2.3. Chain of Custody . . . . . . . . . . . . . . . . . . . . 5
2. Protocol Elements and Features . . . . . . . . . . . . . . . 7 2.4. Validation of Chain of Custody . . . . . . . . . . . . . 5
2.1. The "ARC Set" of Header Fields . . . . . . . . . . . . . 8 3. Terminology and Definitions . . . . . . . . . . . . . . . . . 6
2.1.1. Instance Tags . . . . . . . . . . . . . . . . . . . . 9 3.1. ARC Set . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Chain Validation Status . . . . . . . . . . . . . . . . . 9 3.2. Authenticated Received Chain (ARC) . . . . . . . . . . . 7
2.3. Trace Information . . . . . . . . . . . . . . . . . . . . 9 3.3. Sealer . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4. Key Management . . . . . . . . . . . . . . . . . . . . . 9 3.4. Validator . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5. All Failures are Permanent . . . . . . . . . . . . . . . 10 3.5. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . 7
2.6. Chain of Custody . . . . . . . . . . . . . . . . . . . . 10 3.6. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . 7
2.7. Optional Participation . . . . . . . . . . . . . . . . . 10 4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 8
2.8. Broad Responsibility to Seal . . . . . . . . . . . . . . 10 4.1. ARC Headers . . . . . . . . . . . . . . . . . . . . . . . 8
2.9. One Chain to Rule Them All . . . . . . . . . . . . . . . 11 4.1.1. ARC-Authentication-Results (AAR) . . . . . . . . . . 8
2.10. Sealing is Always Safe . . . . . . . . . . . . . . . . . 11 4.1.2. ARC-Message-Signature (AMS) . . . . . . . . . . . . . 8
3. The ARC Header Fields . . . . . . . . . . . . . . . . . . . . 11 4.1.3. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . 9
3.1. Instance ('i=') Tag . . . . . . . . . . . . . . . . . . . 11 4.2. ARC Set . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. ARC-Authentication-Results (AAR) . . . . . . . . . . . . 12 4.2.1. Instance Tags . . . . . . . . . . . . . . . . . . . . 11
3.3. ARC-Message-Signature (AMS) . . . . . . . . . . . . . . . 12 4.3. Authenticated Received Chain . . . . . . . . . . . . . . 11
3.4. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . . . 13 4.4. Chain Validation Status . . . . . . . . . . . . . . . . . 11
3.4.1. Covered Header Fields . . . . . . . . . . . . . . . . 13 5. Protocol Actions . . . . . . . . . . . . . . . . . . . . . . 12
3.4.2. The 'cv' Tag . . . . . . . . . . . . . . . . . . . . 14 5.1. Sealer Actions . . . . . . . . . . . . . . . . . . . . . 12
4. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . 14 5.1.1. Header Fields To Include In ARC-Seal Signatures . . . 13
4.1. Authentication-Results Information . . . . . . . . . . . 15 5.1.2. Marking and Sealing "cv=fail" (Invalid) Chains . . . 13
4.2. Handling DNS Problems While Validating ARC . . . . . . . 16 5.1.3. Only One Authenticated Received Chain Per Message . . 14
4.3. Responding to ARC Validity Violations During the SMTP 5.1.4. Broad Ability to Seal . . . . . . . . . . . . . . . . 14
Transaction . . . . . . . . . . . . . . . . . . . . . . . 16 5.1.5. Sealing is Always Safe . . . . . . . . . . . . . . . 14
5. Sealer Actions . . . . . . . . . . . . . . . . . . . . . . . 16 5.1.6. Signing vs Sealing . . . . . . . . . . . . . . . . . 14
5.1. Marking and Sealing "cv=fail" (Invalid) Chains . . . . . 17
6. Recording and Reporting the Results of ARC Evaluation . . . . 17 5.2. Validator Actions . . . . . . . . . . . . . . . . . . . . 14
6.1. Information from an ARC Evaluation . . . . . . . . . . . 17 5.2.1. All Failures Are Permanent . . . . . . . . . . . . . 16
6.2. Recording (local) ARC Evaluation Results . . . . . . . . 17 5.2.2. Responding to ARC Validation Failures During the SMTP
6.3. DMARC Reporting of ARC Findings - Interim . . . . . . . . 18 Transaction . . . . . . . . . . . . . . . . . . . . . 16
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 5.3. Result of Validation . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6. Communication of Validation Results . . . . . . . . . . . . . 17
8.1. Authentication-Results Method Registry Update . . . . . . 19 7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.2. Email Authentication Result Names Registry Update . . . . 19 7.1. Communicate Authentication Results Across Trust
8.3. Definitions of the ARC header fields . . . . . . . . . . 19 Boundaries . . . . . . . . . . . . . . . . . . . . . . . 17
7.1.1. Message Scanning Services . . . . . . . . . . . . . . 18
7.1.2. Multi-tier MTA Processing . . . . . . . . . . . . . . 18
7.1.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 18
7.2. Inform Message Disposition Decisions . . . . . . . . . . 19
7.2.1. DMARC Local Policy Overrides . . . . . . . . . . . . 19
7.2.2. DMARC Reporting . . . . . . . . . . . . . . . . . . . 19
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9.1. Header Size . . . . . . . . . . . . . . . . . . . . . . . 20 9.1. Increased Header Size . . . . . . . . . . . . . . . . . . 21
9.2. DNS Operations . . . . . . . . . . . . . . . . . . . . . 20 9.2. DNS Operations . . . . . . . . . . . . . . . . . . . . . 21
9.3. Message Content Suspicion . . . . . . . . . . . . . . . . 21 9.3. Message Content Suspicion . . . . . . . . . . . . . . . . 21
10. Evaluating the Efficacy of the ARC Protocol (Experimental 9.4. Message Sealer Suspicion . . . . . . . . . . . . . . . . 22
Considerations) . . . . . . . . . . . . . . . . . . . . . . . 21 9.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 22
10.1. Success Consideration . . . . . . . . . . . . . . . . . 21 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
10.2. Failure Considerations . . . . . . . . . . . . . . . . . 22 10.1. Email Authentication Results Names Registry Update . . . 22
10.3. Open Questions . . . . . . . . . . . . . . . . . . . . . 22 10.2. Email Authentication Methods Registry Update . . . . . . 22
10.3.1. Value of the ARC-Seal (AS) Header . . . . . . . . . 22 10.3. Definitions of the ARC header fields . . . . . . . . . . 23
10.3.2. DNS Overhead . . . . . . . . . . . . . . . . . . . . 22 11. Experimental Considerations . . . . . . . . . . . . . . . . . 23
10.3.3. Distinguishing Valuable from Worthless Trace 11.1. Success Consideration . . . . . . . . . . . . . . . . . 23
Information . . . . . . . . . . . . . . . . . . . . 22 11.2. Failure Considerations . . . . . . . . . . . . . . . . . 24
11. Implementation Status . . . . . . . . . . . . . . . . . . . . 23 11.3. Open Questions . . . . . . . . . . . . . . . . . . . . . 24
11.1. GMail test reflector and incoming validation . . . . . . 24 11.3.1. Value of the ARC-Seal (AS) Header . . . . . . . . . 24
11.2. AOL test reflector and internal tagging . . . . . . . . 24 11.3.2. DNS Overhead . . . . . . . . . . . . . . . . . . . . 24
11.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 24 11.3.3. What Trace Information is Valuable . . . . . . . . . 24
11.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . 25 12. Implementation Status . . . . . . . . . . . . . . . . . . . . 25
11.5. Mailman 3.2 patch . . . . . . . . . . . . . . . . . . . 25 12.1. GMail test reflector and incoming validation . . . . . . 26
11.6. Copernica/MailerQ web-based validation . . . . . . . . . 25 12.2. AOL test reflector and internal tagging . . . . . . . . 26
11.7. Rspamd . . . . . . . . . . . . . . . . . . . . . . . . . 26 12.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.8. PERL MAIL::DKIM module . . . . . . . . . . . . . . . . . 26 12.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . 27
11.9. PERL Mail::Milter::Authentication module . . . . . . . . 27 12.5. Mailman 3.x patch . . . . . . . . . . . . . . . . . . . 27
11.10. Sympa List Manager . . . . . . . . . . . . . . . . . . . 27 12.6. Copernica/MailerQ web-based validation . . . . . . . . . 27
11.11. Oracle Messaging Server . . . . . . . . . . . . . . . . 27 12.7. Rspamd . . . . . . . . . . . . . . . . . . . . . . . . . 28
11.12. MessageSystems Momentum and PowerMTA platforms . . . . . 28 12.8. PERL MAIL::DKIM module . . . . . . . . . . . . . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 12.9. PERL Mail::Milter::Authentication module . . . . . . . . 28
12.1. Normative References . . . . . . . . . . . . . . . . . . 28 12.10. Sympa List Manager . . . . . . . . . . . . . . . . . . . 29
12.2. Informative References . . . . . . . . . . . . . . . . . 29 12.11. Oracle Messaging Server . . . . . . . . . . . . . . . . 29
12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 30 12.12. MessageSystems Momentum and PowerMTA platforms . . . . . 29
Appendix A. Appendix A - Design Requirements . . . . . . . . . . 31 12.13. Exim . . . . . . . . . . . . . . . . . . . . . . . . . . 29
A.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 31 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
A.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 31 13.1. Normative References . . . . . . . . . . . . . . . . . . 30
Appendix B. Appendix B - Example Usage . . . . . . . . . . . . . 31 13.2. Informative References . . . . . . . . . . . . . . . . . 31
B.1. Example 1: Simple mailing list . . . . . . . . . . . . . 31 13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 32
B.1.1. Here's the message as it exits the Origin: . . . . . 31 Appendix A. Appendix A - Design Requirements . . . . . . . . . . 32
B.1.2. Message is then received at example.org . . . . . . . 32 A.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 33
B.1.3. Example 1: Message received by Recipient . . . . . . 34 A.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 33
Appendix B. Appendix B - Example Usage . . . . . . . . . . . . . 33
B.2. Example 2: Mailing list to forwarded mailbox . . . . . . 35 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 33
B.2.1. Here's the message as it exits the Origin: . . . . . 35 Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 34
B.2.2. Message is then received at example.org . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
B.2.3. Example 2: Message received by Recipient . . . . . . 40
B.3. Example 3: Mailing list to forwarded mailbox with source 42
B.3.1. Here's the message as it exits the Origin: . . . . . 42
B.3.2. Message is then received at example.org . . . . . . . 43
B.3.3. Example 3: Message received by Recipient . . . . . . 48
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 50
Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
1. Introduction 1. Introduction
Modern email authentication techniques such as the Sender Policy The utility of widely deployed email authentication technologies such
Framework (SPF) [RFC7208] and DomainKeys Identified Mail (DKIM) as Sender Policy Framework (SPF) [RFC7208] and DomainKeys Identified
[RFC6376] have become common. However, their end-to-end utility is Mail (DKIM) [RFC6376] is impacted by the processing of Internet Mail
limited by the effects of intermediaries along the transmission path, by intermediate handlers. This impact is thoroughly documented in
which either are not listed (for SPF) or which break digital the defining documents for SPF and DKIM and further discussed in
signatures (for DKIM). These issues are described in substantial [RFC6377] and [RFC7960].
detail in those protocols' defining documents as well as in [RFC6377]
and [RFC7960].
Technologies that build upon the use of SPF and DKIM can reduce the The utility of technologies that build upon SPF and DKIM (such as
success of fraudulent email campaigns. To this end, Domain-based DMARC [RFC7489]) is similarly impacted by intermediate handlers. The
Mail Authentication, Reporting and Conformance (DMARC) [RFC7489], disruption of authentication mechanisms for legitimate messages by
validates the domain of the RFC5322.From header field. However its intermediate handlers can impact all aspects of Internet Mail -
use along email transmission paths that have independent message authors, message recipients, and even the intermediary
intermediaries, such as some forwarders and essentially all mailing handler itself.
list services, produces false positive rejections that are
problematic, both for the message authors, the intermediary
service(s), and for those they are interacting with.
[RFC7960] documented the need for a mechanism which would survive Authenticated Received Chain (ARC) creates a mechanism for individual
legitimate alteration of a message, in spite of breaking the Internet Mail Handlers to add their authentication processing results
associated SPF and DKIM information so that the end receiver to a message's ordered set of processing results. ARC encapsulates
system(s) can avoid those false positive rejections on delivery. processing results in a DKIM signature derivative to grant other
Authenticated Received Chain (ARC) builds upon DKIM mechanisms to handlers the ability to verify the authenticity of each individual
provide a sequence of signatures that provide a view of the handling processing results as well as the aggregate set and sequence of
sequence for a message, especially the points where alterations of results.
the content might have occurred. Equipped with this more complete
information, the recipient system(s) can make a more informed
handling choice, reducing or eliminating the rejections that would
occur with the use of DKIM and/or SPF alone.
1.1. General Concepts Ordered sets of processing results can be used by ARC-enabled
Internet Mail Handlers to inform message handling disposition, to
identify where alteration of message content might have occurred, and
to provide additional trace information for use in understanding
message handling paths.
ARC provides a "chain of custody" for a message, allowing each entity 1.1. Note to Reviewers in the DMARC WG
that handles the message to see what entities handled it before, and
to see what the authentication status of the message was at each step
in the handling. The handling entity can then put its own entry into
the chain of custody and then relay the message to the next handler.
When the message reaches final delivery, the decision to accept and [[ Note: This section is editorial to the WG. Will be removed for
deliver the message, or, alternatively, to reject, discard, or final version. ]]
quarantine it, can take the chain of custody into account, applying This version of the draft has been extensively reorganized for
local policy in addition to policies advertised by the (purported) readability. No changes to the wire protocol or specification are
sending domain. Consider, for example, this scenario: intended from [ARC-DRAFT-14].
1. A sender from mysender.example posts a message to a mailing list 2. General Concepts
hosted at listmania.example;
2. The mailing list modifies the message by prepending the list name ARC is loosely based on concepts from evidence collection. Evidence
to the subject line, then sends it to the subscribers; is usually collected, labeled, stored, and transported in specific
ways to preserve the state of evidence and to document all processing
steps.
3. One of the subscribers is alice@mail.service.example, which 2.1. Evidence
receives the message from listmania.example.
Assuming the original message was DKIM-signed and mysender.example In ARC's situation, the "evidence" is a message's authentication
published an SPF record, the handling by the mailing list will break state at any point along the delivery path between origination and
the DKIM signature because of the message modification, and the final delivery. Authentication state can change when intermediate
forwarding will cause the SPF check to fail in the next step. But handlers modify message content, route messages through unforeseen
listmania.example can add ARC headers to the message to add itself to paths, or change envelope information.
the document's chain of custody. When mail.service.example sees the
message, it can see that SPF and DKIM validation fail, but it can
also see that both of these succeeded when they were checked by
listmania.example, and can verify listmania's assertion.
As part of its evaluation of the message for delivery, 2.2. Custody
mail.service.example can see that mysender.example publishes a DMARC
policy asking that unauthenticated messages be rejected. But is can
also see the assertion by listmania.example that the message was
correctly authenticated when the message arrived there, and if it
accepts that assertion, it can accept the message for further
processing, rather than reject it, based on the additional
information that ARC has provided.
1.2. Differences Between ARC and DKIM "Custody" refers to when an ARC-enabled Internet Mail Handler
processes a message. When a handler takes custody of a message, the
handler becomes a Custodian and attaches their own evidence
(authentication state upon receipt) to the message. Evidence is
added in such a way so that future handlers can verify the
authenticity of both evidence and custody.
In DKIM, every participating signing agent attaches a signature that 2.3. Chain of Custody
is based on some of the content of the message, local policy, and the
domain name of the signing agent's Administrative Management Domain
(ADMD). Any verifier can process such a signature; a verified
signature means that the domain referenced in the signature's "d="
parameter has some responsibility for handling the message. An
artifact of using digital signature technology for this means that
verification also ensures that the portion of the message that was
"covered" by the signature has not been altered since the signature
was applied. The signatures themselves are generally independent of
one another.
In contrast, a validated ARC Set conveys the following pieces of The "chain of custody" of ARC is the entire set of evidence and
information: custody that travels with a message.
1. An assertion that, at the time that the intermediary ADMD 2.4. Validation of Chain of Custody
processed the message, the various assertions (such as SPF, DKIM-
Signature(s) and/or ARC Chain) already attached to the message by
other ADMDs were or were not valid;
2. As with DKIM, an assertion that, for a validated ARC signature, Any ARC-enabled Internet Mail Handler can validate the entire set of
the domain name in the signature takes some responsibility for evidence and custody to yield a valid Chain of Custody. If the
handling of the message and that the covered content of the evidence-supplying Custodians can be trusted, then the validated
message is unchanged since that signature was applied; Chain of Custody describes the (possibly changing) authentication
state as the message traveled through various Custodians.
3. A further assertion that binds the ARC evaluation results into Even though a message's authentication state might have changed, the
the ARC Chain sequence. validated chain of custody can be used to determine if the changes
(and the Custodians responsible for the changes) can be tolerated.
1.3. Definitions and Terminology 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
definitions found in [RFC5598]. The potential roles of
intermediaries in the delivery of email is directly relevant.
Language, syntax (including some ABNF constructs), and concepts are
imported from DKIM [RFC6376]. Specific references to DKIM are made
throughout this document. The following terms are imported from
[RFC5598]:
o ADministrative Management Domain (ADMD), Section 2.3
o Message Transfer Agents (MTA), Section 4.3.2
o Message Submission Agent (MSA), Section 4.3.1
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].
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
BCP14 ([RFC2119][RFC8174]). BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. These words may also appear in this
document in lower case as plain English words, absent their normative
meanings.
Because many of the core concepts and definitions are found in 3.1. ARC Set
[RFC5598], readers should to be familiar with the contents of
[RFC5598], and in particular, the potential roles of intermediaries
in the delivery of email.
Syntax descriptions use Augmented BNF (ABNF) [RFC5234]. Section Section 4.1 introduces three (3) ARC header fields.
Together, the 3 header fields compose a single "ARC Set". An ARC Set
provides the means for an Internet Mail Handler to attach
authentication state to a message in a manner that can be verified by
future handlers. A single message can contain multiple ARC Sets.
1.3.1. Terms defined and used in this document In General Concept terms, an ARC Set represents Evidence and Custody.
o "ARC-Authentication-Results" (AAR) - an ARC header field described 3.2. Authenticated Received Chain (ARC)
in Section 3.2.
o "ARC-Message-Signature" (AMS) - an ARC header field described in The complete sequence of ARC Sets attached to a message is called the
Section 3.3. Authenticated Received Chain. An Authenticated Received Chain is a
recording of individual authentication states as a message traverses
through ARC-participating ADMDs.
o "ARC-Seal" (AS) - an ARC header field described in Section 3.4. The first attachment of an ARC Set to a message causes an
Authenticated Received Chain to be created. Additional attachments
of ARC Sets cause the Authenticated Received Chain to be extended.
o "ARC Set" - A single group of the header fields introduced in In General Concept terms, an Authenticated Received Chain represents
Section 2.1 is called an "ARC Set". Chain of Custody.
o "ARC Chain" - the complete sequence of ARC Sets for a message. 3.3. Sealer
The ARC Chain represents a "chain of custody" for the message,
recording its authentication status at each ARC-participating ADMD
that handled the message.
1.3.2. Referenced Definitions A Sealer is an Internet Mail Handler that attaches a complete and
valid ARC Set to a message.
The following terms are defined in other RFCs. Those definitions can In General Concept terms, a Sealer adds Evidence and proof of Custody
be found as follows: to the Chain of Custody.
o ADMD - [RFC5598], Section 2.3 3.4. Validator
o MTA - [RFC5598], Section 4.3.2 A Validator is an ARC-enabled Internet Mail Handler that evaluates an
Authenticated Received Chain for validity and content. The process
of evaluation of the individual ARC Sets that compose an
Authenticated Received Chain is described in Section Section 5.2.
o MSA - [RFC5598], Section 4.3.1 In General Concept terms, a Validator inspects the Chain of Custody
to determine the content and validity of individual Evidence supplied
by Custodians.
o MDA - [RFC5598], Section 4.3.3 3.5. Imported ABNF Tokens
The three header fields that are part of this specification borrow The following ABNF tokens are imported:
heavily from existing specifications. Rather than repeating all of
the formal definitions that are being reused in ARC, this document
only describes and specifies changes in syntax and semantics.
Language, syntax, and other details are imported from DKIM [RFC6376]. o tag-list ([RFC6376] section 3.2)
Specific references can be found below.
2. Protocol Elements and Features o authres-payload ([I-D-7601bis] section 2.2)
As with other domain authentication technologies (such as SPF, DKIM, o cfws ([RFC5322] section 3.2.2)
and DMARC), ARC makes no claims about the contents of the email
message it has sealed. However, for a valid and passing ARC Chain, a
Final Receiver is able to ascertain:
o all (participating) domains that claim responsibility for handling 3.6. Common ABNF Tokens
(and possibly modifying) the email message in transit;
o trace information, including: The following ABNF tokens are used elsewhere in this document:
* the [RFC7601] Authentication-Results each participating ADMD position = 1*2DIGIT ; 1 - 50
saw; and instance = [CFWS] %s"i" [CFWS] "=" [CFWS] position [CFWS] ";"
chain-status = ("none" / "fail" / "pass")
seal-cv-tag = %s"cv" [CFWS] "=" [CFWS] chain-status
* additional data needed to compile a DMARC report for the 4. Protocol Elements
sending domain.
Given this information, each receiver is able to make a more informed 4.1. ARC Headers
local policy decision regarding message processing and, ultimately,
delivery to the end user in spite of authentication failure(s) and to
inform the message orgination system(s) through the DMARC report(s).
Every participant in an ARC Chain, except for the originating sender ARC introduces three new header fields. Syntax for new header fields
and Final Receiver, is both an ARC Validator (when receiving) and borrows heavily from existing specifications. This document only
then an ARC Sealer (when sending a message onward). describes where ARC-specific changes in syntax and semantics differ
from existing specifications.
_INFORMATIONAL_: It is important to understand that validating and 4.1.1. ARC-Authentication-Results (AAR)
then immediately sealing a message leaves no room for message
modification, and many early implementations of ARC did not initially
work because both operations were performed in a single pass over the
message.
The following protocol features are functional parts and design The ARC-Authentication-Results (AAR) header field records the message
decisions related the protocol that are not specific to either authentication state as processed by an ARC-participating ADMD at
Validators or Sealers, but ensure that the ARC Chain conveys this message arrival time.
information to a Final Receiver.
2.1. The "ARC Set" of Header Fields In General Concept terms, the AAR header field is where Evidence is
recorded by a Custodian.
Each "ARC Set" consists of the following three new header fields: The AAR header field is similar in syntax and semantics to an
Authentication-Results field [I-D-7601bis], with two (2) differences:
1. ARC-Authentication-Results (referred to below as "AAR"): o the name of the header field itself;
virtually identical in syntax to an Authentication-Results field
[RFC7601], this field records the results of all message
authentication checks done by the recording ADMD at the time the
message arrived. Additional information is placed in this field
compared to a standard Authentication-Results field in order to
support a more complete DMARC report;
2. ARC-Message-Signature (referred to below as "AMS"): virtually o the presence of the "instance tag". Additional information on the
identical in syntax to DKIM-Signature, this field contains the "instance tag" can be found in Section Section 4.2.1.
signature about the message header and body as they existed at
the time of handling by the ADMD adding it (including any
modifications made by the sealing ADMD); and
3. ARC-Seal (referred to below as "AS"): highly similar in structure The formal ABNF for the AAR header field is:
and format to a DKIM-Signature, this field applies a digital
signature that protects the integrity of all three of these new
fields when they are added by an ADMD, plus all instances of
these fields added by prior ADMDs.
An ARC participant always adds all of these header fields before arc-info = instance [CFWS] ";" authres-payload
relaying a message to the next handling agent _en route_ to its arc-authres-header = "ARC-Authentication-Results:" [CFWS] arc-info
destination. Moreover, they each have an "instance number" that
increases with each ARC Set in the handling chain so that their
original order can be preserved and the three related header fields
can be processed as a set.
2.1.1. Instance Tags Because there is only one AAR allowed per ARC set, the AAR MUST
contain all authentication results from within the participating
ADMD, regardless of how many Authentication-Results headers are
attached to the message.
ARC includes an indicator in its header fields to show the order in 4.1.2. ARC-Message-Signature (AMS)
which the header fields comprising an ARC Chain were added, and the
specific members of each ARC Set. This is known as the "instance",
and the indicator is an "i=" tag/value. That is, the members of the
first ARC Set affixed to a message will all include "i=1". This is
described in detail in section Section 3.1.
2.2. Chain Validation Status The ARC-Message-Signature (AMS) header field allows an ARC-
participating ADMD to convey some responsibility (custodianship) for
a message and possible message modifications to future ARC-
participating Custodians.
ARC includes a mechanism which denotes the state of the ARC Chain at In General Concept terms, the AMS header field identifies a
each step. The "chain validation status" ("cv" tag/value) is used to Custodian.
communicate the current chain status within the ARC Chain and also
through Authentication-Results and ARC-Authentication-Results stamps
as well as DMARC reporting.
The chain validation status has one of three possible values: The AMS header field is similar in syntax and semantics to a DKIM-
Signature field [RFC6376], with three (3) differences:
o none: There was no chain on the message when it arrived for o the name of the header field itself;
validation; typically occurs when the message arrives at a Message
Transfer Agent (MTA) or mediator from a Message Submission Agent
(MSA) or when any upstream handlers may not be participating in
ARC handling;
o fail: The message has a chain whose validation failed; o no version tag ("v") is defined for the AMS header. As required
for undefined tags (in [RFC6376]), if seen, a version tag MUST be
ignored;
o pass: The message has a chain whose validation succeeded. o the presence of the "instance tag". Additional information on the
"instance tag" can be found in Section Section 4.2.1. The
instance tag replaces the DKIM "AUID" tag.
2.3. Trace Information ARC places no requirements on the selectors and/or domains used for
the AMS header field signatures.
ARC includes trace information encoded in the AAR. While section The formal ABNF for the AMS header field is:
Section 3.2 defines what information must be provided, sealing ADMDs
may provide additional information, and validating receivers may use
this trace information as they find it useful.
2.4. Key Management arc-ams-info = instance [CFWS] ";" tag-list
arc-message-signature = "ARC-Message-Signature:" [CFWS] arc-ams-info
The public keys for ARC header fields follow the same requirements, To avoid unwanted invalidation of AMS signatures:
syntax and semantics as those for DKIM signatures, described in
Section 3.6 of [RFC6376]. ARC places no requirements on the
selectors and/or domains used for the ARC header field signatures.
2.5. All Failures are Permanent o AMS header fields are added by ARC-participating ADMDs as messages
exit the ADMD. AMS header fields should be attached so that any
modifications made by the ADMD are included in the signature of
the AMS header field.
Because ARC Chains are transmitted across multiple intermediaries, o Authentication-Results header fields MUST NOT be included in AMS
all errors, even temporary ones, become unrecoverable and are signatures as they are likely to be deleted by downstream ADMDs
considered permanent. (per Section 5 of [I-D-7601bis]).
Any error validating or sealing a chain, for whatever reason, MUST o ARC-related header fields (ARC-Authentication-Results, ARC-
result in a "cv=fail" verdict as documented in Section 3.4.2. Message-Signature, ARC-Seal) MUST NOT be included in the list of
header fields covered by the signature of the AMS header field.
2.6. Chain of Custody To preserve the ability to verify the integrity of a message, the
signature of the AMS header field SHOULD include any DKIM-Signature
header fields already present in the message.
At a high level, an ARC Chain represents a chain of custody of 4.1.3. ARC-Seal (AS)
authentication and other trace information (AAR) related to a
message, signed by each handler of the message. Each link in the
chain (AMS) is designed to be brittle, insofar as it survives only
until the next modification of the message. However, the sequence of
intermediaries in the handling chain (AS) is designed to remain
intact over the entirety of the chain.
The ARC Chain can be conceptualized through an analogy with the chain The ARC-Seal (AS) header field is the mechanism by which ARC-
of custody for legal evidence. The material evidence itself is participating ADMDs can verify the integrity of AAR header fields and
sealed within an tamper-proof bag (AMS) each time. When handed to a corresponding AMS header fields.
new party, that party both vouches for the state of the received
evidence container (AAR) and signs for the evidence on a chain of
custody report form (AS). As with all analogies, this one should not
be taken to interpretive extremes, but primarily used as a conceptual
framework.
An ARC Chain that is valid and passing has the attributes listed In General Concept terms, the AS header field is how Custodians bind
above in Section 2. Evidence into a Chain of Custody so that Validators can inspect
individual Evidence and Custodians.
2.7. Optional Participation The AS header field is similar in syntax and semantics to DKIM-
Signatures [RFC6376], with the following differences:
Validating an existing chain and then adding your own ARC Set to a o the presence of the "instance tag". Additional information on the
message allows you to claim responsibility for handling the message "instance tag" can be found in Section Section 4.2.1.
and modifications, if any, done by your ADMD to benefit message
delivery downstream. However, no ADMD is obligated to perform these
actions.
2.8. Broad Responsibility to Seal 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 AS header field only covers specific header fields as defined
in Section Section 5.1.1.
Any mediator ([RFC5598], section 5) that modifies a message may seal o no body canonicalization is performed as the AS signature does not
its own changes. ARC is not solely intended for perimeter MTAs. cover the body of a message.
2.9. One Chain to Rule Them All o only "relaxed" header canonicalization ([RFC6376] section 3.4.2)
is used.
A message can have only one ARC Chain on it at a time (see o the only supported tags are "i" (from Section Section 4.2.1 of
Section 3.1). Once broken, the chain cannot be continued, as the this document), and "a", "b", "d, "s", "t" from Section 3.5 of
chain of custody is no longer valid and responsibility for the [RFC6376]. Note especially that the DKIM "h" header is NOT
message has been lost. For further discussion of this topic and the allowed and if found, MUST result in a cv status of "fail" (for
designed restriction which prevents chain continuation or re- more information see Section 5.1.1;
establishment, see [ARC-USAGE].
2.10. Sealing is Always Safe o an additional tag, "cv" ("seal-cv-tag" in the ARC-Seal ABNF
definition) is used to communicate Chain Validation Status to
subsequent ADMDs.
Even when an ARC Chain is valid and passes, its value is limited to ARC places no requirements on the selectors and/or domains used for
very specific cases. An ARC Chain is specifically designed to the AS header field signatures.
provide additional information to a receiver evaluating message
delivery in the context of an authentication failure and otherwise be
benign. Specifically:
o properly adding an ARC Set to a message does not damage or The formal ABNF for the AS header field is:
invalidate an existing chain,
o sealing a chain when you did not modify a message does not arc-as-info = instance [CFWS] ";" tag-list
negatively affect the chain, and arc-seal = "ARC-Seal:" [CFWS] arc-as-info
o validating a message exposes no new threat vectors (see 4.2. ARC Set
Section 9).
_INFORMATIONAL_: If an ADMD is unsure whether it will be re-emitting An "ARC Set" is a single collection of three ARC Headers (AAR, AMS,
and/or modifying a message, it may elect to seal all inbound mail. and AS). ARC Headers of an ARC Set share the same "instance" value.
For complex or nested ADMD relationships such as found in some hosted
mail solutions, this "inbound seal" can be used to facilitate
traversal of internal boundaries as well as properly conveying
incoming state to any egress MTAs that may need to assert a seal upon
exit from the ADMD. Since these internal relationships are highly
implementation dependent, this protocol definition can not usefully
explore such usage except to note that it is intentionally allowed
within the scope of this specification.
3. The ARC Header Fields By adding all ARC Headers to a message, an ARC Sealer adds an ARC Set
to a message. A description of how Sealers add an ARC Set to a
message is found in Section Section 5.1.
3.1. Instance ('i=') Tag 4.2.1. Instance Tags
The header fields comprising a single ARC Set are identified by a Instance tags describe which ARC Headers belong to an ARC Set. Each
common "instance" tag value. The instance tag is a string in each ARC Header of an ARC Set shares the same instance tag value.
header field value that complies with the "tag-spec" ABNF found in
Section 3.2 of [RFC6376]. The tag-name is "i" and the value is the
text representation of a positive integer, indicating the position in
the ARC sequence this set occupies, where the first ARC Set is
numbered 1. In ABNF terms:
position = 1*2DIGIT ; 1 - 50 Instance tag values are integers that begin at 1 and are incremented
instance = [FWS] %x69 [FWS] "=" [FWS] position [FWS] ";" by each addition of an ARC Set. Through the incremental values of
instance tags, an ARC Validator can determine the order in which ARC
Sets were added to a message.
Valid ARC Sets MUST have exactly one instance of each header field Instance tag values can range from 1-50 (inclusive).
(of three) for a given instance value and signing algorithm.
(_INFORMATIONAL:_ Initial development of ARC is only being done with Valid ARC Sets MUST have exactly one instance of each ARC Header
a single allowed signing algorithm, but parallel work in the DCRUP field (AAR, AMS, and AS) for a given instance value and signing
working group [1] is expanding that. For handling multiple signing algorithm.
algorithms, see [ARC-MULTI].)
The 'i' tag value can range from 1-50 (inclusive). _INFORMATIONAL:_ Initial development of ARC is only being done with a
single allowed signing algorithm, but parallel work in the DCRUP
working group is expanding that. For handling multiple signing
algorithms, see [ARC-MULTI].
ARC Chains longer than the defined maximum count MUST be marked as 4.3. Authenticated Received Chain
failed.
_INFORMATIONAL_: Because the AMS and AS header field values are made An Authenticated Received Chain is an ordered collection of ARC Sets.
up of tag-spec constructs, the i= tag may be found anywhere within As ARC Sets are enumerated sets of ARC Headers, an Authenticated
the header field value, but is represented throughout this spec in Received Chain represents the output of message authentication state
the initial position for convenience. Implementers are encouraged to along the handling path of ARC-enabled processors.
place the i= tag at the beginning of the field value to facilitate
human inspection of the headers.
3.2. ARC-Authentication-Results (AAR) Results of message authentication processing along each step of the
ARC-enabled handling path is present in an Authenticated Received
Chain in the form of AAR header fields. The ability to verify the
identity of message handlers and the integrity of message content is
provided by AMS header fields. AS header fields allow messages
handlers to validate the assertions, order and sequence of the
Authenticated Received Chain itself.
The ARC-Authentication-Results header field is syntactically and In General Concept terms, an Authenticated Received Chain represents
semantically identical, except for the header field name itself and a message's Chain of Custody. Validators can consult a message's
its instance tag, to an Authentication-Results header field (defined Chain of Custody to gain insight regarding each Custodian of a
in Section 2.2 of [I-D-7601bis]). message and the Evidence collected by each Custodian.
Formally, the header field is specified as follows using ABNF 4.4. Chain Validation Status
[RFC5234]:
arc-info = instance [CFWS] ";" authres-payload The state of the Authenticated Received Chain at a specific
arc-authres-header = "ARC-Authentication-Results:" [CFWS] arc-info processing step is called the "Chain Validation Status". Chain
Validation Status information is communicated in several ways:
The AAR MUST contain all Authentication-Results from within the o the AS header field in the "cv" tag, and
participating ADMD, regardless of how many Authentication-Results o as part of Authentication-Results and AAR headers.
headers are on the message.
3.3. ARC-Message-Signature (AMS) Chain Validation Status has one of three possible values:
The ARC-Message-Signature header field is simplified version of a o none: There was no Authenticated Received Chain on the message
DKIM-Signature header field [RFC6376], with the following when it arrived for validation. Typically this occurs when a
modifications: message is received directly from a message's original Message
Transfer Agent (MTA) or Message Submission Agent (MSA), or from an
upstream Internet Mail Handler that is not participating in ARC
handling.
o There is an "i" tag, as described in Section 3.1. o fail: The message contains an Authenticated Received Chain whose
validation failed.
o There is no "v" tag defined for the AMS header. As required for o pass: The message contains an Authenticated Received Chain whose
undefined tags (in [RFC6376]), if seen, it MUST be ignored. validation succeeded.
ARC-related header fields (ARC-Seal, ARC-Message-Signture, ARC- 5. Protocol Actions
Authentication-Results) MUST NOT be included in the content covered
by the signature in the signature in this header field.
The AMS SHOULD include any DKIM-Signature header fields already ARC-enabled Internet Mail Handlers generally act as both ARC Sealers
present on the message in the header fields covered by this (when sending messages) and ARC Validators (when receiving messages).
signature.
Authentication-Results header fields MUST NOT be included since they 5.1. Sealer Actions
are likely to be deleted by downstream ADMDs (per Section 5 of
[RFC7601]), thereby breaking the AMS signature.
3.4. ARC-Seal (AS) To "seal" a message, an ARC Sealer adds an ARC Set (the three ARC
header fields AAR, AMS, and AS) to a message. All ARC header fields
in an ARC Set share the same instance tag value.
The ARC-Seal header field is syntactically and semantically similar To perform Sealing (aka to build and attach a new ARC Set), the
to a DKIM-Signature field, with the following exceptions: following actions must be taken by an ARC Sealer when presented with
a message:
o There is an "i" tag, as described in Section 3.1. 1. All message modifications (including adding DKIM-Signatures) MUST
be performed before Sealing.
o The ARC-Seal covers none of the body content of the message. It 2. Calculate the instance value: if the message contains an
only covers specific header fields as defined below: Authenticated Received Chain, the instance value is 1 more than
Section 3.4.1. No body canonicalization is done. the highest instance number found in the Authenticated Received
Chain. If no Authenticated Received Chain exists, the instance
value is 1.
o Only "relaxed" header canonicalization (Section 3.4.2 of 3. Using the calculated instance value, generate and attach to the
[RFC6376]) is used. message in the following order:
o The only supported tags are "i" (from Section 3.1 of this 4. An ARC-Authentication-Results header field as defined in
document), and "a", "b", "d, "s", "t" from Section 3.5 of Section Section 4.1.1.
[RFC6376].
o An additional tag, "cv" is defined in Section 3.4.2 5. An ARC-Message-Signature header field as defined in
Section Section 4.1.2.
3.4.1. Covered Header Fields 6. An ARC-Seal header field using the AS definition found in
Section Section 4.1.3, the method described in
Section Section 5.1.1, and the Chain Validation Status as
determined during ARC validation.
The ARC-Seal signs a specific canonicalized form of the ARC Set 5.1.1. Header Fields To Include In ARC-Seal Signatures
header values. The ARC set header values are compiled in increasing
instance order, starting at 1, and include the set being added at the
time of sealing the message.
Within a set, the header fields are listed in the following order: The signature of an AS header field signs a specific canonicalized
form of the ARC Set header values. The ARC set header values are
supplied to the hash function in increasing instance order, starting
at 1, and include the ARC Set being added at the time of Sealing the
message.
Within an ARC Set, header fields are supplied to the hash function in
the following order:
1. ARC-Authentication-Results 1. ARC-Authentication-Results
2. ARC-Message-Signature 2. ARC-Message-Signature
3. ARC-Seal 3. ARC-Seal
Where the ARC-Seal is the one being generated, it is input to the The ARC-Seal is generated in a manner similar to when DKIM-Signatures
hash function in its final form except with an empty "b=" value, in are added to messages ([RFC6376], section 3.7).
the same manner by which a DKIM-Signature signs itself ([RFC6376],
section 3.7).
Note that the signing scope for the ARC-Seal is modified in the Note that when an Authenticated Received Chain has failed validation,
situation where a chain has failed validation (see Section 5.1). the signing scope for the ARC-Seal is modified (see
Section Section 5.1.2).
3.4.2. The 'cv' Tag 5.1.2. Marking and Sealing "cv=fail" (Invalid) Chains
A new tag "cv" (chain validation) indicates the outcome of evaluating In the case of a failed Authenticated Received Chain, the header
the existing ARC Chain upon arrival at the ADMD that is adding this fields included in the signature scope of the AS header field b=
header field. The values are defined per Section Section 2.2. value MUST only include the ARC Set headers created by the MTA which
detected the malformed chain, as if this newest ARC Set was the only
set present.
In ABNF terms: _INFORMATIONAL_: This approach is mandated to handle the case of a
malformed or otherwise invalid Authenticated Received Chain. There
is no way to generate a deterministic set of AS header fields
(Section 5.1.1) in most cases of invalid chains.
chain-status = ("none" / "fail" / "pass") 5.1.3. Only One Authenticated Received Chain Per Message
seal-cv-tag = %x63.76 [FWS] "=" [FWS] chain-status
4. Verifier Actions A message can have only one Authenticated Received Chain on it at a
time. Once broken, the chain cannot be continued, as the chain of
custody is no longer valid and responsibility for the message has
been lost. For further discussion of this topic and the designed
restriction which prevents chain continuation or re-establishment,
see [ARC-USAGE].
A verifier takes the following steps to validate the ARC Chain. 5.1.4. Broad Ability to Seal
Canonicalization, hash functions, and signature validation methods
are imported from Section 5 of [RFC6376].
1. Collect all ARC Sets currently on the message. If there were ARC is not solely intended for perimeter MTAs. Any mediator
none, the ARC state is "none" and the algorithm stops here. ([RFC5598], section 5) that modifies a message may Seal its own
changes. For additional information, see Section Section 7.1.
2. Check the morphology of the ARC Chain. If any of these 5.1.5. Sealing is Always Safe
conditions are not met, the chain state is "fail" and the
algorithm stops here:
1. Each ARC Set must be complete (e.g., contains exactly one of The utility of an Authenticated Received Chain is limited to very
each of the three ARC-specific header fields); specific cases. Authenticated Received Chains are designed to
provide additional information to an Internet Mail Handler when
evaluating messages for delivery in the context of authentication
failures. Specifically:
2. The instance values must form a continuous sequence from 1..N o Properly adding an ARC Set to a message does not damage or
with no gaps or repeats; invalidate an existing Authenticated Received Chain.
3. The cv value for all ARC-Seal(s) must be non-failing: o Sealing an Authenticated Received Chain when a message has not
been modified does not negatively affect the chain.
1. For i > 1, the value must be "pass"; o Validating a message exposes no new threat vectors (see
Section Section 9).
2. For i = 1, the value must be "none". o An ADMD may choose to Seal all inbound messages whether or not a
message has been modified or will be retransmitted.
3. For each ARC-Message-Signature from the "N"th instance to the 5.1.6. Signing vs Sealing
first, validate the AMS:
1. If the "N"th instance (most recent) signature fails, then the Signing is the process of affixing a digital signature to a message
chain state is "fail" and the algorithm stops here. 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.
2. If one of the prior AMS signatures fails to validate (for 5.2. Validator Actions
instance "M"), then set the oldest-pass value to the lowest
AMS instance number which passed (M+1) and go onto the next
step (there is no need to check any other (older) AMS
signatures). This does not affect the validity of the chain.
3. If all AMS signatures verify, set the oldest-pass value to A validator performs the following steps, in sequence, to process an
zero (0). Authenticated Received Chain. Canonicalization, hash functions, and
signature validation methods are imported from [RFC6376] section 5.
4. For each ARC-Seal from the "N"th instance to the first, validate 1. Collect all ARC Sets currently attached to the message. If there
the seal. are none, the Chain Validation Status is "none" and the algorithm
stops here. The maximum number of ARC Sets that can be attached
to a message is 50. If more than the maximum number exist the
Chain Validation Status is "fail" and the algorithm stops here.
In the following algorithm, the maximum ARC instance value is
referred to as "N".
1. If any seal is not valid, the chain state is "fail" and the 2. If the Chain Validation Status of the highest instance value ARC
algorithm stops here. Set is "fail", then the Chain Validation status is "fail" and the
algorithm stops here.
2. If all seals pass validation, then the chain state is "pass", 3. Validate the structure of the Authenticated Received Chain. A
and the algorithm is complete. valid ARC has the following conditions:
The end result of the verifier's checks via this algorithm MUST be 1. Each ARC Set MUST contain exactly one each of the three ARC
added into the Authentication-Results header(s) for the ADMD. header fields (AAR, AMS, and AS).
_INFORMATIONAL_: Recipients of an ARC Chain that is invalid or does 2. The instance values of the ARC Sets MUST form a continuous
not pass SHOULD NOT draw negative conclusions without a good sequence from 1..N with no gaps or repetition.
understanding of the wider handling context. Until ARC usage is
widespread, intermediaries will continue to modify messages without
ARC seals.
As with a failing DKIM signature ([RFC6376] Section-6.3), a message 3. The "cv" value for all ARC-Seal header fields must be non-
with a failing ARC Chain MUST be treated the same as a message with failing. For instance values > 1, the value must be "pass".
no ARC Chain. For instance value = 1, the value must be "none".
4.1. Authentication-Results Information * If any of these conditions are not met, the Chain Validation
Status is "fail" and the algorithm stops here.
Certain information pertinent to ascertaining message disposition can 4. Validate the AMS with the greatest instance value (most recent).
be lost in transit when messages are handled by intermediaries. For If validation fails, then the Chain Validation Status is "fail"
example, failing DKIM signatures are sometimes removed by MTAs, and and the algorithm stops here.
most DKIM signatures on messages modified by intermediaries will
fail. Recording the following information in the Authentication-
Results stamped as part of the ARC evaluation provides a mechanism
for this information to survive transit through a particular ADMD.
Stamped ARC evaluation results is limited to the Chain Validation 5. _OPTIONAL:_ Determine the "oldest-pass" value from the ARC Set by
status (cv) from Section 2.2. validating each prior AMS beginning with the N-1 and proceeding
in decreasing order to the AMS with the instance value of 1:
The ptypes and properties defined in this section SHOULD be recorded 6. If an AMS fails to validate (for instance value "M"), then set
in the Authentication-Results: the oldest-pass value to the lowest AMS instance value which
passed (M+1) and go to the next step (there is no need to check
any other (older) AMS headers). This does not affect the
validity of the Authenticated Received Chain.
o smtp.client-ip - The connecting client IP address from which the 7. If all AMS headers verify, set the oldest-pass value to zero (0).
message is received;
o header.oldest-pass - The instance number of the oldest AMS that 8. Validate each AS beginning with the greatest instance value and
still validates, or 0 if all pass. proceeding in decreasing order to the AS with the instance value
of 1. If any AS fails to validate, the Chain Validation Status
is "fail" and the algorithm stops here.
4.2. Handling DNS Problems While Validating ARC 9. If the algorithm reaches this step, then the Chain Validation
Status is "pass", and the algorithm is complete.
DNS-based failures to verify a chain are treated no differently than The end result of this Validation algorithm is added into the
any other ARC violation. They result in a "cv=fail" verdict. Authentication-Results header for the ADMD.
4.3. Responding to ARC Validity Violations During the SMTP Transaction As with a failing DKIM signature ([RFC6376] section 6.3), a message
with a failing Authenticated Received Chain MUST be treated the same
as a message with no Authenticated Received Chain.
If a receiver determines that the ARC Chain has failed, the receiver _INFORMATIONAL_: Recipients of an invalid or failing Authenticated
MAY signal the breakage through the extended SMTP response code 5.7.7 Received Chain can use that information as part of a wider handling
[RFC3463] "message integrity failure" [ENHANCED-STATUS] and context. ARC adoption cannot be assumed by intermediaries; many
corresponding SMTP response code. intermediaries will continue to modify messages without adding ARC
Seals.
5. Sealer Actions 5.2.1. All Failures Are Permanent
An ARC sealer MUST take the following actions when presented with a Authenticated Received Chains represent the traversal of messages
message: through one or more intermediaries. All errors, including DNS
failures, become unrecoverable and are considered permanent.
1. Before creating an ARC signature, perform any other, normal Any error Validating an Authenticated Received Chain results in a
authentication and/or signing, so that the ARC signature can failed Chain Validation Status. For further discussion of this topic
cover those results. and the design restriction which prevents chain continuation or re-
establishment, see [ARC-USAGE].
2. Build and attach the new ARC Set: 5.2.2. Responding to ARC Validation Failures During the SMTP
Transaction
1. If an ARC Chain exists on the message, then set "N" equal to If an ARC Validator determines that the Authenticated Received Chain
the highest instance number found on the chain (i=); has failed, the Validator MAY signal the breakage through the
otherwise set "N" equal to zero for the following steps. extended SMTP response code 5.7.7 [RFC3463] "message integrity
failure" [ENHANCED-STATUS] and corresponding SMTP response code.
2. Generate and attach to the message an ARC-Authentication- 5.3. Result of Validation
Results header field as defined in Section Section 3.2, using
instance number N+1 and the same content from the previous
step.
3. Generate and attach to the message an ARC-Message-Signature An Authenticated Received Chain with a Chain Validation Status of
header field as defined in Section 3.3 above, using instance "pass" allows Internet Mail Handlers to ascertain:
number N+1.
4. Generate and attach to the message an ARC-Seal header field o all ARC-participating ADMDs that claim responsibility for handling
using the general algorithm described in Section 3.4 above, (and possibly modifying) the message in transit;
the chain validation status as determined in Section 4, and
instance number N+1.
5.1. Marking and Sealing "cv=fail" (Invalid) Chains o the authentication state of the message as perceived by each ADMD
(from Authentication-Results header fields).
The header fields signed by the AS header field b= value in the case Given this information, handlers can inform local policy decisions
of a chain failure MUST be only the matching instance headers created regarding disposition of messages that experience authentication
by the MTA which detected the malformed chain, as if this newest ARC failure due to intermediate processing.
Set was the only set present.
_INFORMATIONAL:_ In the case of a malformed or otherwise invalid 6. Communication of Validation Results
chain there is no way to generate a deterministic set of AS header
fields ({#implicit_as_h}) so this approach is mandated.
6. Recording and Reporting the Results of ARC Evaluation Chain Validation Status (described in Section Section 4.4) is
communicated via Authentication-Results (and AAR) headers using the
auth method "arc". This auth method is described in
Section Section 10.1.
The evaluation of an ARC Chain provides information which will be If necessary data is available, the ptypes and properties defined in
useful to both the receiver (or intermediary) and to the initial Section Section 10.2 SHOULD be recorded in an Authentication-Results
sender of the message. This information should be preserved and header field:
reported as follows.
6.1. Information from an ARC Evaluation o smtp.client-ip - The connecting client IP address from which the
message is received.
The evaluation of an ARC Chain produces a list of domain names for o header.oldest-pass - The instance number of the oldest AMS that
participating intermediaries which handled the message, to wit: still validates, or 0 if all pass.
o A list of the "d=" domains found in the validated ARC-Seal header Upon Sealing of a message, this Authentication-Results information
fields along with all other Authentications-Results added by the ADMD will
be recorded into the AAR as defined in section Section 4.1.1.
o The "d=" domain found in the most recent (highest instance number) In General Concept terms, the information recorded in the ARC-
AMS header field (since that is the only one necessarily Authentication-Results header field is the Evidence that gets
validated) attached to a message.
In the case of a failed chain, only the terminal ARC Set is covered 7. Use Cases
by the ARC-Seal so the reporting is limited to the findings in that
terminal ARC Set.
6.2. Recording (local) ARC Evaluation Results This section explores several messaging handling use cases that are
addressed by ARC.
Receivers who process an attached ARC Chain SHOULD add an 7.1. Communicate Authentication Results Across Trust Boundaries
"arc=[pass|fail|policy]" method annotation into a locally-affixed
Authentication-Results [RFC7601] header field along with any salient
comment(s).
Details of the ARC Chain which was evaluated should be included in When an intermediary ADMD adds an ARC Set to a message's
the Authentication-Results and AAR headers per Section Section 4.1. Authenticated Received Chain (or creates the initial ARC Set), the
ADMD communicates authentication state to the next ADMD in the
message handling path.
6.3. DMARC Reporting of ARC Findings - Interim If ARC-enabled ADMDs are trusted, Authenticated Received Chains can
be used to bridge administrative boundaries.
Receivers SHOULD indicate situations in which ARC evaluation 7.1.1. Message Scanning Services
influenced the results of their local policy determination. DMARC
reporting of ARC-informed decisions can be accomplished by adding a
local_policy comment explanation containing the list of data
discovered in the ARC evaluation, which at a minimum SHOULD include:
* the Chain Validation status, * the domain and selector for each AS,
* the IP addresses of the mail originating ADMD:
<policy_evaluated> Message services are available to perform anti-spam, anti-malware,
<disposition>none</disposition> and anti-phishing scanning. Such services typically remove malicious
<dkim>fail</dkim> content, replace HTTP links in messages with sanitized links, and/or
<spf>fail</spf> attach footers to messages advertising the abilities of the message
<reason> scanning service. These modifications almost always break signature-
<type>local_policy</type> based authentication (such as DKIM).
<comment>arc=pass ams[2].d=d2.example ams[2].s=s1 as[2].d=d2.example
as[2].s=s2 as[1].d=d1.example as[1].s=s3 client-ip[1]=10.10.10.13</comment>
</reason>
</policy_evaluated>
In the sample above, d2.example is the sealing domain for ARC[2] and Scanning services typically require clients to point MX records of an
d1.example is the sealing domain for ARC[1]. Internet domain to the scanning service. Messages destined for the
Internet domain are initially delivered to the scanning service.
Once scanning is performed, messages are then routed to the client's
own mail handling infrastructure. Re-routing messages in this way
almost always breaks path-based authentication (such as SPF).
Intermediary message handlers SHOULD generate DMARC reports on Message scanning services can attach Authenticated Received Chains to
messages which transit their system just like any other message which messages to communicate authentication results into client ADMDs.
they receive. This will result in multiple reports for each mediated Clients can then benefit from the message scanning service while
message as they transit the series of handlers. DMARC report processing messages as if the client's infrastructure were the
consumers should be aware of this behaviour and make the necessary original destination of the Internet domain's MX record.
accommodations.
7. Privacy Considerations 7.1.2. Multi-tier MTA Processing
The ARC Chain provides a verifiable record of the handlers for a Large message processing infrastructure is often divided into several
message. Anonymous remailers will probably not find this compatible processing tiers that can break authentication information between
with their operating goals. tiers. For example, a large site may maintain a cluster of MTAs
dedicated to connection handling and enforcement of IP-based
reputation filtering. A secondary cluster of MTAs may be dedicated
and optimized for content-based processing of messages.
8. IANA Considerations Authenticated Received Chains can be used to communicated
authentication state between processing tiers.
[[ Note to the RFC Editors: Some of these fields are defined both 7.1.3. Mailing Lists
here and in [I-D-7601bis]. Please delete the overlap from whichever
document goes through the publication process after the other. ]]
This specification adds three new header fields as defined below. Mailing lists resend posted messages to subscribers. A full
description of authentication-related mailing list issues can be
found in [RFC7960] Section 3.2.3.
8.1. Authentication-Results Method Registry Update Mailing list services can implement ARC to convey the original
authentication state of posted messages sent to the list's subscriber
base. The ADMDs of the mailing list subscribers can then use the
Authenticated Received Chain to determine the authentication state of
the original message before mailing list handling.
This draft adds one item to the IANA "Email Authentication Methods" 7.2. Inform Message Disposition Decisions
registry:
o Method : arc ARC functionality allows Internet Mail Handlers to reliably identify
Defined: [I-D.ARC] intermediary ADMDs and for ADMDs to expose authentication state that
ptype: header can survive additional intermediary handling.
Property: chain evaluation result
Value: chain evaluation result status (see Section 3.4)
Status: active
8.2. Email Authentication Result Names Registry Update Intermediaries often break authentication through content
modification, interfere with path-based authentication (such as SPF),
and strip authentication results (if an MTA removes Authentication-
Results headers).
This draft updates the Email Authentication Results registry, most Authenticated Received Chains allow ARC Validators to:
recently defined in [I-D-7601bis], with one new authentication method
and several status codes, all defined by this document:
o Auth Method : arc 1. identify ARC-enabled ADMDs that break authentication while
Code: "none", "pass", "fail" processing messages;
Specification: [I-D.ARC] Section 3.4.2 Status: active
o Method : spf 2. gain extended visibility into the authentication-preserving
Defined: [I-D.ARC] abilities of ADMDs that relay messages into ARC-enabled ADMDs.
ptype: smtp
Property: client-ip
Value: the connecting client IP address from which the message is
received
Status: active
o Method : arc Through the collection of ARC-related data, an ADMD can identify
Defined: [I-D.ARC] handling paths that have broken authentication.
ptype: header
Property: oldest-pass
Value: the oldest instance with a still validating AMS signature
Status: active
8.3. Definitions of the ARC header fields An Authenticated Received Chain allows an Internet Mail Handler to
potentially base decisions of message disposition on authentication
state provided by different ADMDs.
This specification adds three new header fields to the "Permanent 7.2.1. DMARC Local Policy Overrides
Message Header Field Registry", as follows:
o Header field name: ARC-Seal DMARC introduces a policy model where Domain Owners can request email
Applicable protocol: mail receivers to reject or quarantine messages that fail DMARC alignment.
Status: draft Interoperability issues between DMARC and indirect email flows are
Author/Change controller: IETF documented in [RFC7960].
Specification document(s): [I-D.ARC]
Related information: [RFC6376]
o Header field name: ARC-Message-Signature Authenticated Received Chains allow DMARC processors to consider
Applicable protocol: mail authentication states provided by other ADMDs. As a matter of local
Status: draft policy, a DMARC processor may choose to accept the authentication
Author/Change controller: IETF state provided by an Authenticated Received Chain when determining if
Specification document(s): [I-D.ARC] a message is DMARC compliant.
Related information: [RFC6376]
o Header field name: ARC-Authentication-Results When an Authenticated Received Chain is used to determine message
Applicable protocol: mail disposition, the DMARC processor can communicate this local policy
Status: standard decision to Domain Owners as described in Section Section 7.2.2.
Author/Change controller: IETF
Specification document(s): [I-D.ARC] 7.2.2. DMARC Reporting
Related information: [RFC7601]
DMARC-enabled receivers indicate when ARC Validation influences
DMARC-related local policy decisions. DMARC reporting of ARC-
influenced decisions is accomplished by adding a local_policy comment
containing a list of data discovered during ARC Validation, which at
a minimum includes:
o the Chain Validation Status,
o the domain and selector for each AS,
o the originating IP address from the first ARC Set:
EXAMPLE:
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
<reason>
<type>local_policy</type>
<comment>arc=pass ams[2].d=d2.example ams[2].s=s1
as[2].d=d2.example as[2].s=s2 as[1].d=d1.example
as[1].s=s3 client-ip[1]=10.10.10.13</comment>
</reason>
</policy_evaluated>
In the above example DMARC XML reporting fragment, data relating to
specific validated ARC Sets are enumerated using array syntax (eg,
"ams[2]" means AMS header field with instance value of 2). d2.example
is the Sealing domain for ARC Set #2 (i=2) and d1.example is the
Sealing domain for ARC Set #1 (i=1).
Depending on the reporting practices of intermediate message
handlers, Domain Owners may receive multiple DMARC reports for a
single message. DMARC report processors should be aware of this
behaviour and make the necessary accommodations.
8. Privacy Considerations
The Authenticated Received Chain provides a verifiable record of the
handlers for a message. This record may include Personally
Identifiable Information such as IP address and domain names. Such
information is also including in existing header fields such as the
"Received" header field.
9. Security Considerations 9. Security Considerations
The Security Considerations of [RFC6376] and [RFC7601] apply directly The Security Considerations of [RFC6376] and [I-D-7601bis] apply
to this specification. directly to this specification.
9.1. Header Size As with other domain authentication technologies (such as SPF, DKIM,
and DMARC), ARC makes no claims about the semantic content of
messages.
Inclusion of ARC Sets in the header of emails may cause problems for 9.1. Increased Header Size
some older or more constrained MTAs if they are unable to accept the
greater size of the header. Inclusion of Authenticated Received Chains into messages may cause
issues for older or constrained MTAs due to increased total header
size.
9.2. DNS Operations 9.2. DNS Operations
Operators who receive a message bearing N ARC Sets have to complete The validation of an Authenticated Received Chain composed of N ARC
up to N+1 DNS queries to evaluate the chain (barring DNS redirection Sets can require up to 2*N DNS queries (not including any DNS
mechanisms which can increase the lookups for a given target value). redirection mechanisms which can increase the total number of
This has at least two effects: 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. The difficulty of forging the signature
values should limit the extent of this load to domains under values should limit the extent of this load to domains under
control of the attacker. control of the attacker. Query traffic pattern analysis may
expose information about downstream validating ADMD
infrastructure.
2. DKIM only does one DNS check per signature, while this one can do 2. DKIM only performs one DNS query per signature, while ARC can
many (per chain). Absent caching, slow DNS responses can cause introduce many (per chain). Absent caching, slow DNS responses
SMTP timeouts; and backlogged delivery queues on mediating can cause SMTP timeouts; and backlogged delivery queues on
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 ARC Sets with the Recipients are cautioned to treat messages bearing Authenticated
same suspicion that they apply to all other email messages. This Received Chains with the same suspicion applied to all other
includes appropriate content scanning and other checks for messages. This includes appropriate content scanning and other
potentially malicious content. The handlers which are identified checks for potentially malicious content.
within the ARC Chain may be used to provide input to local policy
engines in cases where DMARC validation fails (due to mediation
impacting SPF attribution, DKIM validity or alignment).
Note that a passing ARC Chain may not adequately mean that the Just as passing message authentication is not an indication of
message is safe because: message safety, forwarding that information through the mechanism of
ARC is also not an indication of message safety. Even if all ARC-
enabled ADMDs are trusted, ADMDs may have become compromised, may
miss unsafe content, or may not properly authenticate messages.
1. You have to trust all signatories; and 9.4. Message Sealer Suspicion
2. Even trusted systems may have become compromised or may not Recipients are cautioned to treat every Sealer of the ARC Chain with
properly authenticate messages, so even with a chain of trusted suspicion. Just as with a validated DKIM signature, responsibility
participants, the message might still never have authenticated in for message handling is attributed to the signing domain, but whether
the first place (which is why you have the AAR to inspect) or or not that signer is a malicious actor is out of scope of the
could have been subject to unintended modifications. authentication mechanism. Since ARC aids message delivery in the
event of an authentication failure, ARC Sealers should be treated
with suspicion, so that a malicious actor cannot Seal spam or other
fraudulent messages to aid their delivery, too.
10. Evaluating the Efficacy of the ARC Protocol (Experimental 9.5. Replay Attacks
Considerations)
The ARC protocol is designed to mitigate some of the most common Since ARC inherits heavily from DKIM, it has similar attack vectors.
failure conditions for email which transits intermediary handlers en In particular, the Replay Attack described in [RFC6376] section 8.6
route to the final recipient. Some of these problems have happened is potentially amplified by ARC's chained statuses. In an ARC replay
due to the adoption of the DMARC protocol [RFC7489] and are listed in attack, a malicious actor would take an intact and passing ARC Chain,
[RFC6377] and [RFC7960]. and then resend it to many recipients without making any
modifications that invalidate the latest AMS or AS. The impact to a
receiver would be more DNS lookups and signature evaluations. This
scope of this attack can be limited by caching DNS queries and
following the same signing scope guidance from [RFC6376] section
5.4.1.
As the ARC protocol becomes standardized and implemented amongst 10. IANA Considerations
intermediary handlers, the following aspects should be evaluated in
order to determine the success of the protocol in accomplishing the
intended benefits.
NOTE: Terminology within this section does NOT follow [RFC2119] [[ *Note to the RFC Editors:* dkim header.s is defined both here and
interpretation. This section represents the current thoughts of the in [I-D-7601bis]. Please delete the overlap from whichever document
working group regarding unanswered questions related to the protocol. goes through the publication process after the other. ]]
Wider deployment will inform these topics and probably expand them.
10.1. Success Consideration This draft introduces three new headers fields and updates the Email
Authentication Parameters registry with one new authentication method
and several status codes.
Currently, many receivers have heuristically determined overrides in 10.1. Email Authentication Results Names Registry Update
order to rescue mail from intermediary-caused failures. Many of
those overrides rely on inferrence rather than direct evidence.
ARC will be a success if, for ARC sealed messages, receivers are able This draft adds one Auth Method with three Codes to the IANA "Email
to implment ARC-based algorithmic decisions based on the direct Authentication Result Names" registry:
evidence found within the ARC Chain. This is especially relevant for
DMARC processing when the DKIM d= value is aligned with the
rfc5322.From author domain.
10.2. Failure Considerations o Auth Method : arc Code: "none", "pass", "fail" Specification:
[I-D.ARC] Section 2.2 Status: active
The intent of ARC is to be at most value-add and at worst benign. If 10.2. Email Authentication Methods Registry Update
ARC opens up significant new vectors for abuse (see Section 9) then
this protocol will be a failure. Note that weaknesses inherent in
the mail protocols ARC is built upon (such as DKIM replay attacks and
other known issues) are not new vectors which can be attributed to
this specification.
10.3. Open Questions This draft adds several new items to the Email Authentication Methods
registry, most recently defined in [I-D-7601bis]:
o Method: arc Definition: [I-D.ARC] ptype: smtp Property: client-ip
Value: IP address of originating SMTP connection Status: active
Version: 1
o Method: arc Definition: [I-D.ARC] ptype: header Property: oldest-
pass Value: The instance id of the oldest validating AMS, or 0 if
they all pass (see Sectionn 4) Status: active Version: 1
o Method: dkim Definition: [RFC6376] ptype: header Property: s
Value: value of signature "s" tag Status: active Version: 1
10.3. Definitions of the ARC header fields
This specification adds three new header fields to the "Permanent
Message Header Field Registry", as follows:
o Header field name: ARC-Seal Applicable protocol: mail Status:
draft Author/Change controller: IETF Specification document(s):
[I-D.ARC] Related information: [RFC6376]
o Header field name: ARC-Message-Signature Applicable protocol: mail
Status: draft Author/Change controller: IETF Specification
document(s): [I-D.ARC] Related information: [RFC6376]
o Header field name: ARC-Authentication-Results Applicable protocol:
mail Status: standard Author/Change controller: IETF Specification
document(s): [I-D.ARC] Related information: [I-D-7601bis]
11. Experimental Considerations
The ARC protocol is designed to address common interoperability
issues introduced by intermediate message handlers. Interoperability
issues are described in [RFC6377] and [RFC7960].
As the ARC protocol is implemented by intermediary handlers over
time, the following should be evaluated in order to determine the
success of the protocol in accomplishing the intended benefits.
11.1. Success Consideration
In an attempt to deliver legitimate messages that users desire, many
receivers use heuristic-based methods to identify messages that
arrive via indirect delivery paths.
ARC will be a success if the presence of Authenticated Received
Chains allows for improved decision making when processing legitimate
messages.
11.2. Failure Considerations
ARC should function without introducing significant new vectors for
abuse (see Section Section 9). If unforseen vectors are enabled by
ARC, then this protocol will be a failure. Note that weaknesses
inherent in the mail protocols ARC is built upon (such as DKIM replay
attacks and other known issues) are not new vectors which can be
attributed to this specification.
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, wide-spread the time of the development of the protocol. However, additional
deployment should be able to gather the necessary data to answer some deployment should be able to gather the necessary data to answer some
or all of them. or all of them.
10.3.1. Value of the ARC-Seal (AS) Header 11.3.1. Value of the ARC-Seal (AS) Header
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.
10.3.2. DNS Overhead 11.3.2. DNS Overhead
Longer ARC Chains will require more queries to retrieve the keys for Longer Authenticated Received Chains will require more queries to
validating the chain. While this is not believed to be a security retrieve the keys for validating the chain. While this is not
issue (see Section 9.2), it is unclear how much overhead will truly believed to be a security issue (see Section Section 9.2), it is
be added. This is similar to some of the initial processing and unclear how much overhead will truly be added. This is similar to
query load concerns which were debated at the time of the DKIM some of the initial processing and query load concerns which were
specification development. debated at the 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 ARC Chains along with the the distribution of lengths found in valid Authenticated Received Chains
DNS impact of processing ARC Chains. along with the the DNS impact of processing Authenticated Received
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.
10.3.3. Distinguishing Valuable from Worthless Trace Information 11.3.3. 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 ARC seals but example, if there is a well known mailing list that seals with ARC
doesn't do its own initial DMARC enforcement, a Final Receiver with but doesn't do its own initial DMARC enforcement, an Internet Mail
this knowledge could make a delivery decision based upon the Handler with this knowledge could make a delivery decision based upon
authentication information it sees in the corresponding AAR header. the authentication information it sees in the corresponding AAR
header.
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. It would be beneficial to identify construction of DMARC reports.
the value-add of having intermediary-handled mail flow information
added into the DMARC reports going back to senders.
Certain receivers believe the entire set of trace information would Certain receivers believe the entire set of trace information would
be valuable to feed into machine learning systems to identify fraud be valuable to feed into machine learning systems to identify fraud
and/or provide other signals related to message delivery. and/or provide other signals related to message delivery.
It is unclear what trace information will be valuable for all It is unclear what trace information will be valuable for all
receivers, regardless of size. 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.
11. Implementation Status 12. Implementation Status
[[ Note to the RFC Editor: Please remove this section before [[ Note to the RFC Editor: Please remove this section before
publication along with the reference to [RFC6982]. ]] publication along with the reference to [RFC6982]. ]]
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC6982]. Internet-Draft, and is based on a proposal described in [RFC6982].
The description of implementations in this section is intended to The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort here does not imply endorsement by the IETF. Furthermore, no effort
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 seventh This information is known to be correct as of the eighth
interoperability test event which was held on 2017-07-15 & 16 at interoperability test event which was held on 2018-03-17 at IETF101.
IETF99.
For a few of the implementations, later status information was For a few of the implementations, later status information was
available as of December 2017. available as of June 2018.
11.1. GMail test reflector and incoming validation 12.1. GMail test reflector and incoming validation
Organization: Google Organization: Google Description: Internal production implementation
Description: Internal production implementation with both debug with both debug analysis and validating + sealing pass-through
analysis and validating + sealing pass-through function function Status of Operation: Production - Incoming Validation
Status of Operation: Production - Incoming Validation Coverage: Full spec implemented as of [ARC-DRAFT-14] Licensing:
Coverage: Full spec implemented as of [ARC-DRAFT-06] Proprietary - Internal only Implementation Notes:
Licensing: Proprietary - Internal only
Implementation Notes:
o Full functionality was demonstrated during the interop testing on o Full functionality was demonstrated during the interop testing on
2017-07-15. 2018-03-17.
Contact Info: arc-discuss@dmarc.org [2] Contact Info: arc-discuss@dmarc.org [1]
11.2. AOL test reflector and internal tagging 12.2. AOL test reflector and internal tagging
Organization: AOL Organization: AOL Description: Internal prototype implementation with
Description: Internal prototype implementation with both debug both debug analysis and validating + sealing pass-through function
analysis and validating + sealing pass-through function Status of Operation: Beta Coverage: ARC Chain validity status
Status of Operation: Beta checking is operational, but only applied to email addresses enrolled
Coverage: ARC Chain validity status checking is operational, but only in the test program. This system conforms to [ARC-DRAFT-05]
applied to email addresses enrolled in the test program. Licensing: Proprietary - Internal only Implementation Notes:
This system conforms to [ARC-DRAFT-06]
Licensing: Proprietary - Internal only
Implementation Notes:
o 2017-07-15: Full functionality verified during the interop o 2017-07-15: Full functionality verified during the interop
testing. testing.
Contact Info: arc-discuss@dmarc.org [3] o 2018-06: Partially retired but still accessible by special request
due to the in process evolution of the AOL mail infrastructure to
the integrated OATH environment. The implementation was based on
the Apache James DKIM code base and may be contributed back to
that project in the future.
11.3. dkimpy Contact Info: arc-discuss@dmarc.org [2]
Organization: dkimpy developers/Scott Kitterman 12.3. dkimpy
Description: Python DKIM package
Status of Operation: Production Organization: dkimpy developers/Scott Kitterman Description: Python
Coverage: DKIM package Status of Operation: Production Coverage:
o 2017-07-15: The internal test suite is incomplete, but the command o 2017-07-15: The internal test suite is incomplete, but the command
line developmental version of validator was demonstrated to line developmental version of validator was demonstrated to
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 [4] 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
11.4. OpenARC 12.4. OpenARC
Organization: TDP/Murray Kucherawy Organization: TDP/Murray Kucherawy Description: Implemention of
Description: Implemention of milter functionality related to the milter functionality related to the OpenDKIM and OpenDMARC packages
OpenDKIM and OpenDMARC packages Status of Operation: Beta Coverage: Built to support [ARC-DRAFT-14]
Status of Operation: Beta
Coverage: Built to support [ARC-DRAFT-10]
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 The build is FreeBSD oriented but some packages have been built
for easier deployment on RedHat-based Linux platforms. for easier deployment on RedHat-based Linux platforms.
o Some issues still exist when deploying in a chained milter o Some issues still exist when deploying in a chained milter
arrangement (such as OpenSPF -> OpenDKIM -> OpenDMARC -> OpenARC) arrangement (such as OpenSPF -> OpenDKIM -> OpenDMARC -> OpenARC)
with coordination between the stages. When deployed in a with coordination between the stages. When deployed in a
"sandwich" configuration around an MLM, there is no effective "sandwich" configuration around an MLM, there is no effective
mechanism to convey trust from the ingress (validator) to egress mechanism to convey trust from the ingress (validator) to egress
(signer) instances. (_NOTE_: this is expected to resolved with a (signer) instances. (_NOTE_: this is expected to resolved with a
new release of OpenDMARC expected in January 2018.) new release of OpenDMARC expected in mid-2018.)
Contact Info: arc-discuss@dmarc.org [5] Contact Info: arc-discuss@dmarc.org [4]
11.5. Mailman 3.2 patch 12.5. Mailman 3.x patch
Organization: Mailman development team Organization: Mailman development team Description: Integrated ARC
Description: Integrated ARC capabilities within the Mailman 3.2 capabilities within the Mailman 3.2 package Status of Operation:
package Patch submitted Coverage: Based on OpenARC Licensing: Same as mailman
Status of Operation: Patch submitted package - GPL Implementation Notes:
Coverage: Based on OpenARC
Licensing: Same as mailman package - GPL
Implementation Notes:
o Appears to work properly in at least one beta deployment, but o Appears to work properly in at least one beta deployment, but
waiting on acceptance of the pull request into the mainline of waiting on acceptance of the pull request into the mainline of
mailman development mailman development
Contact Info: https://www.gnu.org/software/mailman/contact.html Contact Info: https://www.gnu.org/software/mailman/contact.html
11.6. Copernica/MailerQ web-based validation 12.6. Copernica/MailerQ web-based validation
Organization: Copernica Organization: Copernica Description: Web-based validation of ARC-
Description: Web-based validation of ARC-signed messages signed messages Status of Operation: Beta Coverage: Built to support
Status of Operation: Beta [ARC-DRAFT-05] Licensing: On-line usage only Implementation Notes:
Coverage: Built to support [ARC-DRAFT-05]
Licensing: On-line usage only
Implementation Notes:
o Released 2016-10-24 o Released 2016-10-24
o Requires full message content to be pasted into a web form found o Requires full message content to be pasted into a web form found
at http://arc.mailerq.com/ (warning - https is not supported). at http://arc.mailerq.com/ (warning - https is not supported).
o An additional instance of an ARC signature can be added if one is o An additional instance of an ARC signature can be added if one is
willing to paste a private key into an unsecured web form. willing to paste a private key into an unsecured web form.
o 2017-07-15: Testing shows that results match the other o 2017-07-15: Testing shows that results match the other
implementations listed in this section. implementations listed in this section.
Contact Info: https://www.copernica.com/ Contact Info: https://www.copernica.com/
11.7. Rspamd 12.7. Rspamd
Organization: Rspamd community Organization: Rspamd community Description: ARC signing and
Description: ARC signing and verification module verification module Status of Operation: Production, though
Status of Operation: Production, though deployment usage is unknown deployment usage is unknown Coverage: Built to support [ARC-DRAFT-14]
Coverage: Built to support [ARC-DRAFT-06] Licensing: Open source Implementation Notes:
Licensing: Open source
Implementation Notes:
o 2017-06-12: Released with version 1.6.0 o 2017-06-12: Released with version 1.6.0
o 2017-07-15: Testing during the interop showed that the validation o 2017-07-15: Testing during the interop showed that the validation
functionality interoperated with the Google, AOL, dkimpy and functionality interoperated with the Google, AOL, dkimpy and
MailerQ implementations MailerQ implementations
Contact Info: https://rspamd.com/doc/modules/arc.html and Contact Info: https://rspamd.com/doc/modules/arc.html and
https://github.com/vstakhov/rspamd https://github.com/vstakhov/rspamd
11.8. PERL MAIL::DKIM module 12.8. PERL MAIL::DKIM module
Organization: FastMail Organization: FastMail Description: Email domain authentication (sign
Description: Email domain authentication (sign and/or verify) module, and/or verify) module, previously included SPF / DKIM / DMARC, now
previously included SPF / DKIM / DMARC, now has ARC added has ARC added Status of Operation: Production, deployment usage
Status of Operation: Production, deployment usage unknown unknown Coverage: Built to support [ARC-DRAFT-10] Licensing: Open
Coverage: Built to support [ARC-DRAFT-10] Source Implementation Notes:
Licensing: Open Source
Implementation Notes:
o 2017-12-15: v0.50 released with full test set passing for ARC o 2017-12-15: v0.50 released with full test set passing for ARC
Contact Info: http://search.cpan.org/~mbradshaw/Mail-DKIM-0.50/ Contact Info: http://search.cpan.org/~mbradshaw/Mail-DKIM-0.50/
11.9. PERL Mail::Milter::Authentication module 12.9. PERL Mail::Milter::Authentication module
Organization: FastMail Organization: FastMail Description: Email domain authentication
Description: Email domain authentication milter, uses MAIL::DKIM (see milter, uses MAIL::DKIM (see above) Status of Operation: Intial
above) validation completed during IETF99 hackathon with some follow-on work
Status of Operation: Intial validation completed during IETF99 during the week Coverage: Built to support [ARC-DRAFT-14] Licensing:
hackathon with some follow-on work during the week Open Source Implementation Notes:
Coverage: Built to support [I-D.ARC]
Licensing: Open Source
Implementation Notes:
o 2017-07-15: Validation functionality which interoperates with o 2017-07-15: Validation functionality which interoperates with
Gmail, AOL, dkimpy was demonstrated; later in the week of IETF99, Gmail, AOL, dkimpy was demonstrated; later in the week of IETF99,
the signing functionality was reported to be working the signing functionality was reported to be working
o 2017-07-20: ARC functionality has not yet been pushed back to the o 2017-07-20: ARC functionality has not yet been pushed back to the
github repo but should be showing up soon github repo but should be showing up soon
Contact Info: https://github.com/fastmail/authentication_milter Contact Info: https://github.com/fastmail/authentication_milter
11.10. Sympa List Manager 12.10. Sympa List Manager
Organization: Sympa Dev Community Organization: Sympa Dev Community Description: Work in progress
Description: Work in progress Status of Operation: Work in progress Coverage: unknown Licensing:
Status of Operation: Work in progress open source Implementation Notes:
Coverage: unknown
Licensing: open source
Implementation Notes:
o 2018-01-05: Tracked as https://github.com/sympa-community/sympa/ o 2018-01-05: Tracked as https://github.com/sympa-community/sympa/
issues/153 issues/153
Contact Info: https://github.com/sympa-community Contact Info: https://github.com/sympa-community
11.11. Oracle Messaging Server 12.11. Oracle Messaging Server
Organization: Oracle Organization: Oracle Description: Status of Operation: Intial
Description: development work during IETF99 hackathon. Framework code is
Status of Operation: Intial development work during IETF99 hackathon. complete, crypto functionality requires integration with libsodium
Status since then unknown. Coverage: Work in progress Licensing: Unknown Implementation Notes:
Coverage: Work in progress
Licensing: Unknown
Implementation Notes:
o 2018-03: Protocol handling components are completed, but crypto is o 2018-03: Protocol handling components are completed, but crypto is
not yet functional. not yet functional.
Contact Info: Chris Newman Contact Info: Chris Newman, Oracle
11.12. MessageSystems Momentum and PowerMTA platforms 12.12. MessageSystems Momentum and PowerMTA platforms
Organization: MessageSystems/SparkPost Organization: MessageSystems/SparkPost Description: OpenARC
Description: OpenARC integration into the LUA-enabled Momentum integration into the LUA-enabled Momentum processing space Status of
processing space Operation: Beta Coverage: Same as OpenARC Licensing: Unknown
Status of Operation: Beta
Coverage: Built to support [ARC-DRAFT-10]
Licensing: Unknown
Implementation Notes: Implementation Notes:
o Initial deployments for validation expected in mid-2018. o Initial deployments for validation expected in mid-2018.
Contact Info: Contact Info: TBD
12. References 12.13. Exim
12.1. Normative References Organization: Exim developers Status of Operation: Operational;
requires specific enabling for compile. Coverage: Full spec
implemented as of [ARC-DRAFT-13] Licensing: GPL Contact Info: exim-
users@exim.org Implementation notes:
o Exim 4.91
13. 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", [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes",
RFC 3463, DOI 10.17487/RFC3463, January 2003, RFC 3463, DOI 10.17487/RFC3463, January 2003,
<https://www.rfc-editor.org/info/rfc3463>. <https://www.rfc-editor.org/info/rfc3463>.
skipping to change at page 29, line 10 skipping to change at page 30, line 45
[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>.
[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",
RFC 7405, DOI 10.17487/RFC7405, December 2014,
<https://www.rfc-editor.org/info/rfc7405>.
[RFC7601] Kucherawy, M., "Message Header Field for Indicating [RFC7601] Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", RFC 7601, Message Authentication Status", RFC 7601,
DOI 10.17487/RFC7601, August 2015, DOI 10.17487/RFC7601, August 2015,
<https://www.rfc-editor.org/info/rfc7601>. <https://www.rfc-editor.org/info/rfc7601>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
12.2. Informative References 13.2. Informative References
[ARC-DRAFT-05] [ARC-DRAFT-05]
Andersen, K., "Authenticated Received Chain (ARC) Protocol Andersen, K., "Authenticated Received Chain (ARC) Protocol
(I-D-05)", n.d., <https://tools.ietf.org/html/ (I-D-05)", n.d., <https://tools.ietf.org/html/
draft-ietf-dmarc-arc-protocol-05>. draft-ietf-dmarc-arc-protocol-05>.
[ARC-DRAFT-06]
Andersen, K., "Authenticated Received Chain (ARC) Protocol
(I-D-06)", n.d., <https://tools.ietf.org/html/
draft-ietf-dmarc-arc-protocol-06>.
[ARC-DRAFT-10] [ARC-DRAFT-10]
Andersen, K., "Authenticated Received Chain (ARC) Protocol Andersen, K., "Authenticated Received Chain (ARC) Protocol
(I-D-10)", n.d., <https://tools.ietf.org/html/ (I-D-10)", n.d., <https://tools.ietf.org/html/
draft-ietf-dmarc-arc-protocol-10>. draft-ietf-dmarc-arc-protocol-10>.
[ARC-DRAFT-13]
Andersen, K., "Authenticated Received Chain (ARC) Protocol
(I-D-13)", n.d., <https://tools.ietf.org/html/
draft-ietf-dmarc-arc-protocol-13>.
[ARC-DRAFT-14]
Andersen, K., "Authenticated Received Chain (ARC) Protocol
(I-D-14)", n.d., <https://tools.ietf.org/html/
draft-ietf-dmarc-arc-protocol-14>.
[ARC-MULTI] [ARC-MULTI]
Andersen, K., "Using Multiple Signing Algorithms with Andersen, K., "Using Multiple Signing Algorithms with
ARC", January 2018, <https://tools.ietf.org/html/ ARC", January 2018, <https://tools.ietf.org/html/
draft-ietf-dmarc-arc-multi-01>. draft-ietf-dmarc-arc-multi-01>.
[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", December 2017, "Recommended Usage of the ARC Headers", April 2018,
<https://tools.ietf.org/html/ <https://tools.ietf.org/html/
draft-ietf-dmarc-arc-usage-01>. draft-ietf-dmarc-arc-usage-05>.
[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/
skipping to change at page 30, line 33 skipping to change at page 32, line 28
(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
<https://www.rfc-editor.org/info/rfc7489>. <https://www.rfc-editor.org/info/rfc7489>.
[RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky, [RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky,
E., Ed., and K. Andersen, Ed., "Interoperability Issues E., Ed., and K. Andersen, Ed., "Interoperability Issues
between Domain-based Message Authentication, Reporting, between Domain-based Message Authentication, Reporting,
and Conformance (DMARC) and Indirect Email Flows", and Conformance (DMARC) and Indirect Email Flows",
RFC 7960, DOI 10.17487/RFC7960, September 2016, RFC 7960, DOI 10.17487/RFC7960, September 2016,
<https://www.rfc-editor.org/info/rfc7960>. <https://www.rfc-editor.org/info/rfc7960>.
12.3. URIs 13.3. URIs
[1] https://datatracker.ietf.org/wg/dcrup/about/ [1] mailto:arc-discuss@dmarc.org
[2] mailto:arc-discuss@dmarc.org [2] mailto:arc-discuss@dmarc.org
[3] mailto:arc-discuss@dmarc.org [3] https://github.com/Valimail/arc_test_suite
[4] https://github.com/Valimail/arc_test_suite [4] mailto:arc-discuss@dmarc.org
[5] mailto:arc-discuss@dmarc.org [5] https://trac.ietf.org/trac/dmarc/ticket/17
[6] https://trac.ietf.org/trac/dmarc/ticket/17 [6] mailto:dmarc@ietf.org
[7] mailto:dmarc@ietf.org [7] mailto:arc-discuss@dmarc.org
[8] mailto:arc-discuss@dmarc.org [8] mailto:arc-interop@dmarc.org
Appendix A. Appendix A - Design Requirements [9] https://arc-spec.org
(This section is re-inserted for background information from Appendix A. Appendix A - Design Requirements
[ARC-DRAFT-06] and earlier versions.)
[[ 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 31, line 39 skipping to change at page 33, line 33
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 [[ Note: The following examples were mocked up early in the
definition process for the spec. They no longer reflect the current definition process for the spec. They no longer reflect the current
definition and need various updates which will be included in a definition and need various updates which will be included in a
future draft. Issue 17 [6] ]] future draft. Issue 17 [5] ]]
(Obsolete but retained for illustrative purposes)
B.1. Example 1: Simple mailing list
B.1.1. Here's the message as it exits the Origin:
Return-Path: <jqd@d1.example>
Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
(authenticated bits=0)
by segv.d1.example with ESMTP id t0FN4a8O084569;
Thu, 14 Jan 2015 15:00:01 -0800 (PST)
(envelope-from jqd@d1.example)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
s=20130426; t=1421363082;
bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
Content-Transfer-Encoding;
b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw
bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl
gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
Message-ID: <54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe <jqd@d1.example>
To: arc@dmarc.org
Subject: Example 1
Hey gang,
This is a test message.
--J.
B.1.2. Message is then received at example.org
B.1.2.1. Example 1, Step A: Message forwarded to list members
Processing at example.org:
o example.org performs authentication checks
o No previous Authentication-Results or ARC-Seal headers are present
o example.org adds ARC-Authentication-Results header
o example.org adds Received: header
o example.org adds a ARC-Seal header
Here's the message as it exits example.org:
Return-Path: <jqd@d1.example>
ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
s=seal2015; d=example.org; cv=none;
b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
d=example.org; s=clochette; t=1421363105;
bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
h=List-Id:List-Unsubscribe:List-Archive:List-Post:
List-Help:List-Subscribe:Reply-To:DKIM-Signature;
b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1F5
vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+m4bw
a6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
Received: from segv.d1.example (segv.d1.example [72.52.75.15])
by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
for <arc@example.org>; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
(envelope-from jqd@d1.example)
ARC-Authentication-Results: i=1; lists.example.org;
spf=pass smtp.mfrom=jqd@d1.example;
dkim=pass (1024-bit key) header.i=@d1.example;
dmarc=pass
Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
(authenticated bits=0)
by segv.d1.example with ESMTP id t0FN4a8O084569;
Thu, 14 Jan 2015 15:00:01 -0800 (PST)
(envelope-from jqd@d1.example)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
s=20130426; t=1421363082;
bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
Content-Transfer-Encoding;
b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
Message-ID: <54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe <jqd@d1.example>
To: arc@example.org
Subject: [Lists] Example 1
Hey gang,
This is a test message.
--J.
B.1.3. Example 1: Message received by Recipient
Let's say that the Recipient is example.com
Processing at example.com:
o example.com performs usual authentication checks
o example.com adds Authentication-Results: header, Received header
o Determines that message fails DMARC
o Checks for ARC-Seal: header; finds one
o Validates the signature in the ARC-Seal: header, which covers the
ARC-Authentication-Results: header
o example.com can use the ARC-Authentication-Results values or
verify the DKIM-Signature from lists.example.org
Here's what the message looks like at this point:
Return-Path: <jqd@d1.example>
Received: from example.org (example.org [208.69.40.157])
by clothilde.example.com with ESMTP id
d200mr22663000ykb.93.1421363207
for <fmartin@example.com>; Thu, 14 Jan 2015 15:02:40 -0800 (PST)
Authentication-Results: clothilde.example.com; spf=fail
smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
header.i=@example.org; dmarc=fail; arc=pass
ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
s=seal2015; d=example.org; cv=none;
b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
d=example.org; s=clochette; t=1421363105;
bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
h=List-Id:List-Unsubscribe:List-Archive:List-Post:
List-Help:List-Subscribe:Reply-To:DKIM-Signature;
b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
Received: from segv.d1.example (segv.d1.example [72.52.75.15])
by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
for <arc@example.org>; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
(envelope-from jqd@d1.example)
ARC-Authentication-Results: i=1; lists.example.org;
spf=pass smtp.mfrom=jqd@d1.example;
dkim=pass (1024-bit key) header.i=@d1.example;
dmarc=pass
Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
(authenticated bits=0)
by segv.d1.example with ESMTP id t0FN4a8O084569;
Thu, 14 Jan 2015 15:00:01 -0800 (PST)
(envelope-from jqd@d1.example)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
s=20130426; t=1421363082;
bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
Content-Transfer-Encoding;
b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw
bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl
gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
Message-ID: <54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe <jqd@d1.example>
To: arc@example.org
Subject: [Lists] Example 1
Hey gang,
This is a test message.
--J.
B.2. Example 2: Mailing list to forwarded mailbox
B.2.1. Here's the message as it exits the Origin:
Return-Path: <jqd@d1.example>
Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
(authenticated bits=0)
by segv.d1.example with ESMTP id t0FN4a8O084569;
Thu, 14 Jan 2015 15:00:01 -0800 (PST)
(envelope-from jqd@d1.example)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
s=20130426; t=1421363082;
bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
Content-Transfer-Encoding;
b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw
bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl
gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
Message-ID: <54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe <jqd@d1.example>
To: arc@example.org
Subject: Example 1
Hey gang,
This is a test message.
--J.
B.2.2. Message is then received at example.org
B.2.2.1. Example 2, Step A: Message forwarded to list members
Processing at example.org:
o example.org performs authentication checks
o example.org applies standard DKIM signature
o No previous Authentication-Results or ARC-Seal headers are present
o example.org adds ARC-Authentication-Results header
o example.org adds usual Received: header
o example.org adds a ARC-Seal header
Here's the message as it exits Step A:
Return-Path: <jqd@d1.example>
ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
s=seal2015; d=example.org; cv=none;
b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
d=example.org; s=clochette; t=1421363105;
bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
h=List-Id:List-Unsubscribe:List-Archive:List-Post:
List-Help:List-Subscribe:Reply-To:DKIM-Signature;
b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
Received: from segv.d1.example (segv.d1.example [72.52.75.15])
by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
for <arc@example.org>; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
(envelope-from jqd@d1.example)
ARC-Authentication-Results: i=1; lists.example.org;
spf=pass smtp.mfrom=jqd@d1.example;
dkim=pass (1024-bit key) header.i=@d1.example;
dmarc=pass
Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
(authenticated bits=0)
by segv.d1.example with ESMTP id t0FN4a8O084569;
Thu, 14 Jan 2015 15:00:01 -0800 (PST)
(envelope-from jqd@d1.example)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
s=20130426; t=1421363082;
bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
Content-Transfer-Encoding;
b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
Message-ID: <54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe <jqd@d1.example>
To: arc@example.org
Subject: [Lists] Example 1
Hey gang,
This is a test message.
--J.
B.2.2.2. Example 2, Step B: Message from list forwarded
The message is delivered to a mailbox at gmail.com
Processing at gmail.com:
o gmail.com performs usual authentication checks
o gmail.com adds Authentication-Results: and Received: header
o Determines that message fails DMARC
o Checks for ARC-Seal: header; finds one
o Validates the signature in the ARC-Seal: header, which covers the
ARC-Authentication-Results: header
o Uses the ARC-Authentication-Results: values, but:
o Instead of delivering message, prepares to forward message per
user settings
o Applies usual DKIM signature
o gmail.com adds it's own ARC-Seal: header, contents of which are
* version
* sequence number ("i=2")
* hash algorithm (SHA256 as example)
* timestamp ("t=")
* selector for key ("s=notary01")
* domain for key ("d=gmail.com")
* headers included in hash ("h=ARC-Authentication-Results:ARC-
Seal")
* Note: algorithm requires only ARC-Seals with lower sequence #
be included, in ascending order
* signature of the header hash
Here's what the message looks like at this point:
Return-Path: <jqd@d1.example>
ARC-Seal: i=2; a=rsa-sha256; t=1421363253;
s=notary01; d=gmail.com; cv=pass;
b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDWR
YbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/sut
txO+RRNr0fCFw==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120806;
h=mime-version:content-type:x-original-sender:
x-original-authentication-results:precedence:mailing-list:
list-id:list-post:list-help:list-archive:sender:reply-to:
list-unsubscribe:DKIM-Signature;
bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=;
b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBmfhS
LF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJRFeM
KdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwDBJtXw
bQoZyRtb6X6q0mYaszUB8kw==
Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10
for <mailbox@gmail.com>; Thu, 14 Jan 2015 15:02:45 -0800 (PST)
Authentication-Results: i=2; gmail.com; spf=fail
smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
header.i=@example.org; dmarc=fail; arc=pass
ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
s=seal2015; d=example.org; cv=none:
b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
d=example.org; s=clochette; t=1421363105;
bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
h=List-Id:List-Unsubscribe:List-Archive:List-Post:
List-Help:List-Subscribe:Reply-To:DKIM-Signature;
b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
Received: from segv.d1.example (segv.d1.example [72.52.75.15])
by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
for <arc@example.org>; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
(envelope-from jqd@d1.example)
ARC-Authentication-Results: i=1; lists.example.org;
spf=pass smtp.mfrom=jqd@d1.example;
dkim=pass (1024-bit key) header.i=@d1.example;
dmarc=pass
Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
(authenticated bits=0)
by segv.d1.example with ESMTP id t0FN4a8O084569;
Thu, 14 Jan 2015 15:00:01 -0800 (PST)
(envelope-from jqd@d1.example)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
s=20130426; t=1421363082;
bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
Content-Transfer-Encoding;
b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
Message-ID: <54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe <jqd@d1.example>
To: arc@example.org
Subject: [Lists] Example 1
Hey gang,
This is a test message.
--J.
B.2.3. Example 2: Message received by Recipient
Let's say that the Recipient is example.com
Processing at example.com:
o example.com performs usual authentication checks
o example.com adds Authentication-Results: header, Received header
o Determines that message fails DMARC
o Checks for ARC-Seal: header; finds two
o Validates the signature in the highest numbered ("i=2") ARC-Seal:
header, which covers all previous ARC-Seal: and ARC-
Authentication-Results: headers
o Validates the other ARC-Seal header ("i=1"), which covers the ARC-
Authentication-Results: header
o example.com uses the ARC-Authentication-Results: values
Here's what the message looks like at this point:
Return-Path: <jqd@d1.example>
Received: from mail-ob0-f188.google.com (mail-ob0-f188.google.com
[208.69.40.157]) by clothilde.example.com with ESMTP id
d200mr22663000ykb.93.1421363268
for <fmartin@example.com>; Thu, 14 Jan 2015 15:03:15 -0800 (PST)
Authentication-Results: clothilde.example.com; spf=fail
smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
header.i=@gmail.com; dmarc=fail; arc=pass
ARC-Seal: i=2; a=rsa-sha256; t=1421363253;
s=notary01; d=gmail.com; cv=pass;
b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDWR
YbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/sut
txO+RRNr0fCFw==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120806;
h=mime-version:content-type:x-original-sender:
x-original-authentication-results:precedence:mailing-list:
list-id:list-post:list-help:list-archive:sender:reply-to:
:list-unsubscribe:DKIM-Signature;
bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=;
b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBmfhS
LF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJRFeM
KdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwDBJtXw
bQoZyRtb6X6q0mYaszUB8kw==
Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10
for <mailbox@gmail.com>; Thu, 14 Jan 2015 15:02:45 -0800 (PST)
Authentication-Results: i=2; gmail.com; spf=fail
smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
header.i=@example.org; dmarc=fail; arc=pass
ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
s=seal2015; d=example.org; cv=none;
b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
d=example.org; s=clochette; t=1421363105;
bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
h=List-Id:List-Unsubscribe:List-Archive:List-Post:
List-Help:List-Subscribe:Reply-To:DKIM-Signature;
b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
Received: from segv.d1.example (segv.d1.example [72.52.75.15])
by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
for <arc@example.org>; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
(envelope-from jqd@d1.example)
ARC-Authentication-Results: i=1; lists.example.org;
spf=pass smtp.mfrom=jqd@d1.example;
dkim=pass (1024-bit key) header.i=@d1.example;
dmarc=pass
Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
(authenticated bits=0)
by segv.d1.example with ESMTP id t0FN4a8O084569;
Thu, 14 Jan 2015 15:00:01 -0800 (PST)
(envelope-from jqd@d1.example)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
s=20130426; t=1421363082;
bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
Content-Transfer-Encoding;
b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
Message-ID: <54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe <jqd@d1.example>
To: arc@example.org
Subject: [Lists] Example 1
Hey gang,
This is a test message.
--J.
B.3. Example 3: Mailing list to forwarded mailbox with source
B.3.1. Here's the message as it exits the Origin:
Return-Path: <jqd@d1.example>
Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
(authenticated bits=0)
by segv.d1.example with ESMTP id t0FN4a8O084569;
Thu, 14 Jan 2015 15:00:01 -0800 (PST)
(envelope-from jqd@d1.example)
ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
s=origin2015; d=d1.example; cv=none;
b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61T
X6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69EU
8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
d=d1.example; s=20130426; t=1421363082;
bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding;
b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrv
Qwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3
TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
Message-ID: <54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe <jqd@d1.example>
To: arc@example.org
Subject: Example 1
Hey gang,
This is a test message.
--J.
B.3.2. Message is then received at example.org
B.3.2.1. Example 3, Step A: Message forwarded to list members with
source
Processing at example.org:
o example.org performs authentication checks
o example.org applies standard DKIM signature
o Checks for ARC-Seal: header; finds one (i=1)
o Validates the signature in the ARC-Seal (i=1): header, which
covers the d1.example ARC-Message-Signature: header
o example.org adds ARC-Authentication-Results header
o example.org adds usual Received: header
o example.org adds a DKIM-Signature
o example.org adds a ARC-Seal header, contents of which are
* sequence number ("i=2")
* hash algorithm (SHA256 as example)
* timestamp ("t=")
* chain validity ("cv=")
* selector for key ("s=seal2015")
* domain for key ("d=example.org")
* signature ("b=")
Here's the message as it exits Step A:
Return-Path: <jqd@d1.example>
ARC-Seal: i=2; a=rsa-sha256; t=1421363107;
s=seal2015; d=example.org; cv=pass;
b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed;
d=example.org; s=clochette; t=1421363105;
bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
h=List-Id:List-Unsubscribe:List-Archive:List-Post:
List-Help:List-Subscribe:From:Reply-To:DKIM-Signature;
b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
Received: from segv.d1.example (segv.d1.example [72.52.75.15])
by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
for <arc@example.org>; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
(envelope-from jqd@d1.example)
ARC-Authentication-Results: i=2; lists.example.org;
spf=pass smtp.mfrom=jqd@d1.example;
dkim=pass (1024-bit key) header.i=@d1.example;
dmarc=pass
Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
(authenticated bits=0)
by segv.d1.example with ESMTP id t0FN4a8O084569;
Thu, 14 Jan 2015 15:00:01 -0800 (PST)
(envelope-from jqd@d1.example)
ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
s=origin2015; d=d1.example; cv=none;
b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
d=d1.example; s=20130426; t=1421363082;
bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding;
b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
Message-ID: <54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe <jqd@d1.example>
To: arc@example.org
Subject: [Lists] Example 1
Hey gang,
This is a test message.
--J.
B.3.2.2. Example 3, Step B: Message from list forwarded with source
The message is delivered to a mailbox at gmail.com
Processing at gmail.com:
o gmail.com performs usual authentication checks
o gmail.com adds Authentication-Results: and Received: header
o Determines that message fails DMARC
o Checks for ARC-Seal: header; finds two
o Validates the signature in the ARC-Seal (i=2): header, which
covers the ARC-Authentication-Results: header
o Validates the signature in the ARC-Seal (i=1): header, which
covers the d1.example ARC-Message-Signature: header
o Uses the ARC-Authentication-Results: values, but:
o Instead of delivering message, prepares to forward message per
user settings
o Applies usual DKIM signature
o gmail.com adds it's own ARC-Seal: header, contents of which are
* version
* sequence number ("i=2")
* hash algorithm (SHA256 as example)
* timestamp ("t=")
* selector for key ("s=notary01")
* domain for key ("d=gmail.com")
* Note: algorithm requires only ARC-Seals with lower sequence #
be included, in ascending order
* signature of the chain
Here's what the message looks like at this point:
Return-Path: <jqd@d1.example>
ARC-Seal: i=3; a=rsa-sha256; t=1421363253;
s=notary01; d=gmail.com; cv=pass;
b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwD
WRYbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF
/suttxO+RRNr0fCFw==
ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120806;
h=mime-version:content-type:x-original-sender
:x-original-authentication-results:precedence:mailing-list
:list-id:list-post:list-help:list-archive:sender
:list-unsubscribe:reply-to;
bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=;
b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBm
fhSLF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJ
RFeMKdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwD
BJtXwbQoZyRtb6X6q0mYaszUB8kw==
Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10
for <mailbox@gmail.com>; Thu, 14 Jan 2015 15:02:45 -0800 (PST)
Authentication-Results: i=3; gmail.com; spf=fail
smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
header.i=@example.org; dmarc=fail; arc=pass
ARC-Seal: i=2; a=rsa-sha256; t=1421363107;
s=seal2015; d=example.org; cv=pass;
b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed;
d=example.org; s=clochette; t=1421363105;
bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
h=List-Id:List-Unsubscribe:List-Archive:List-Post:
List-Help:List-Subscribe:Reply-To:DKIM-Signature;
b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1
F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+
m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
Received: from segv.d1.example (segv.d1.example [72.52.75.15])
by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
for <arc@example.org>; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
(envelope-from jqd@d1.example)
ARC-Authentication-Results: i=2; lists.example.org;
spf=pass smtp.mfrom=jqd@d1.example;
dkim=pass (1024-bit key) header.i=@d1.example;
dmarc=pass
Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
(authenticated bits=0)
by segv.d1.example with ESMTP id t0FN4a8O084569;
Thu, 14 Jan 2015 15:00:01 -0800 (PST)
(envelope-from jqd@d1.example)
ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
s=origin2015; d=d1.example; cv=none;
b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
d=d1.example; s=20130426; t=1421363082;
bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding;
b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYij
rvQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD
4Gd3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
Message-ID: <54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe <jqd@d1.example>
To: arc@example.org
Subject: [Lists] Example 1
Hey gang,
This is a test message.
--J.
B.3.3. Example 3: Message received by Recipient
Let's say that the Recipient is example.com
Processing at example.com:
o example.com performs usual authentication checks
o example.com adds Authentication-Results: header, Received header
o Determines that message fails DMARC
o Checks for ARC-Seal: header; finds three
o Validates the signature in the highest numbered ("i=2") ARC-Seal:
header, which covers all previous ARC-Seal: and ARC-
Authentication-Results: headers
o Validates the other ARC-Seal header ("i=2"), which covers the ARC-
Authentication-Results: header
o Validates the other ARC-Seal header ("i=1"), which covers the
d1.example ARC-Message-Signature: header
o example.com uses the ARC-Authentication-Results: values
Here's what the message looks like at this point:
Return-Path: <jqd@d1.example> [[ Note: Need input from the WG as to what sort of sequence of
Received: from mail-ob0-f188.google.com (mail-ob0-f188.google.com examples would be considered useful - otherwise we'll just drop this
[208.69.40.157]) by clothilde.example.com with ESMTP id section entirely. ]]
d200mr22663000ykb.93.1421363268
for <fmartin@example.com>; Thu, 14 Jan 2015 15:03:15 -0800 (PST)
Authentication-Results: clothilde.example.com; spf=fail
smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
header.i=@gmail.com; dmarc=fail; arc=pass
ARC-Seal: i=3; a=rsa-sha256; t=1421363253;
s=notary01; d=gmail.com; cv=pass;
b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDW
RYbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/s
uttxO+RRNr0fCFw==
ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120806;
h=mime-version:content-type:x-original-sender
:x-original-authentication-results:precedence
:mailing-list:list-id:list-post:list-help:list-archive:sender
:list-unsubscribe:reply-to;
bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=;
b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBm
fhSLF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJ
RFeMKdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwD
BJtXwbQoZyRtb6X6q0mYaszUB8kw==
Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10
for <mailbox@gmail.com>; Thu, 14 Jan 2015 15:02:45 -0800 (PST)
Authentication-Results: i=3; gmail.com; spf=fail
smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
header.i=@example.org; dmarc=fail; arc=pass
ARC-Seal: i=2; a=rsa-sha256; t=1421363107;
s=seal2015; d=example.org; cv=pass;
b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed;
d=example.org; s=clochette; t=1421363105;
bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
h=List-Id:List-Unsubscribe:List-Archive:List-Post:
List-Help:List-Subscribe:Reply-To:DKIM-Signature;
b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1
F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+
m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
Received: from segv.d1.example (segv.d1.example [72.52.75.15])
by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
for <arc@example.org>; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
(envelope-from jqd@d1.example)
ARC-Authentication-Results: i=2; lists.example.org;
spf=pass smtp.mfrom=jqd@d1.example;
dkim=pass (1024-bit key) header.i=@d1.example;
dmarc=pass
Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
(authenticated bits=0)
by segv.d1.example with ESMTP id t0FN4a8O084569;
Thu, 14 Jan 2015 15:00:01 -0800 (PST)
(envelope-from jqd@d1.example)
ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
s=origin2015; d=d1.example; cv=none;
b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
d=d1.example; s=20130426; t=1421363082;
bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
h=MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding;
b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
Message-ID: <54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe <jqd@d1.example>
To: arc@example.org
Subject: [Lists] Example 1
Hey gang, <removed for now to reduce confusion>
This is a test message.
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.
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 [7]. Earlier discussions can be found at arc- dmarc@ietf.org [6]. Earlier discussions can be found at arc-
discuss@dmarc.org [8]. discuss@dmarc.org [7]. Interop discussions planning can be found at
arc-interop@dmarc.org [8].
Some introductory material for less technical people can be found at
https://arc-spec.org [9].
Authors' Addresses Authors' Addresses
Kurt Andersen Kurt Andersen
LinkedIn LinkedIn
1000 West Maude Ave 1000 West Maude Ave
Sunnyvale, California 94085 Sunnyvale, California 94085
USA USA
Email: kurta@linkedin.com Email: kurta@linkedin.com
Brandon Long (editor) Brandon Long (editor)
Google Google
Email: blong@google.com Email: blong@google.com
Steven Jones (editor)
TDP
Email: smj@crash.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 Draegon (editor)
dmarcian
Email: tim@dmarcian.com
 End of changes. 290 change blocks. 
1686 lines changed or deleted 950 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/