draft-ietf-dmarc-arc-protocol-11.txt   draft-ietf-dmarc-arc-protocol-12.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: July 26, 2018 Google Expires: September 19, 2018 Google
S. Jones, Ed. S. Jones, Ed.
TDP TDP
S. Blank, Ed. S. Blank, Ed.
ValiMail ValiMail
M. Kucherawy, Ed. M. Kucherawy, Ed.
TDP TDP
January 22, 2018 March 18, 2018
Authenticated Received Chain (ARC) Protocol Authenticated Received Chain (ARC) Protocol
draft-ietf-dmarc-arc-protocol-11 draft-ietf-dmarc-arc-protocol-12
Abstract Abstract
The Authenticated Received Chain (ARC) protocol creates a mechanism The Authenticated Received Chain (ARC) protocol creates a mechanism
whereby a series of handlers of an email message can conduct whereby a series of handlers of an email message can conduct
authentication of the email message as it passes among them on the authentication of the email message as it passes among them on the
way to its destination, and record the status of that authentication way to its destination, and create an attached, authenticated record
at each step along the handling path, for use by the final recipient of the status at each step along the handling path, for use by the
in making choices about the disposition of the message. Changes in final recipient in making choices about the disposition of the
the message that might break DKIM or DMARC can be identified through message. Changes in the message that might break existing
the ARC set of header fields. authentication mechanisms can be identified through the ARC set of
header fields.
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 July 26, 2018. This Internet-Draft will expire on September 19, 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
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Definitions and Terminology . . . . . . . . . . . . . . . . . 6 1.1.1. High Level Summary . . . . . . . . . . . . . . . . . 5
3.1. Referenced Definitions . . . . . . . . . . . . . . . . . 6 1.1.2. Technical Summary . . . . . . . . . . . . . . . . . . 7
4. Protocol Elements and Features . . . . . . . . . . . . . . . 7 1.2. Definitions and Terminology . . . . . . . . . . . . . . . 7
4.1. Features of the ARC Protocol . . . . . . . . . . . . . . 8 1.3. Referenced Definitions . . . . . . . . . . . . . . . . . 7
4.1.1. Chain of Custody . . . . . . . . . . . . . . . . . . 8 2. Protocol Elements and Features . . . . . . . . . . . . . . . 8
4.1.2. Optional Participation . . . . . . . . . . . . . . . 8 2.1. Features of the ARC Protocol . . . . . . . . . . . . . . 8
4.1.3. Only one ARC Chain (One Chain to Rule Them All) . . . 9 2.1.1. Chain of Custody . . . . . . . . . . . . . . . . . . 9
4.1.4. All Failures are Permanent . . . . . . . . . . . . . 9 2.1.2. Optional Participation . . . . . . . . . . . . . . . 9
4.1.5. Benign nature of an ARC Set . . . . . . . . . . . . . 9 2.1.3. Only one ARC Chain (One Chain to Rule Them All) . . . 9
4.1.6. Key Management . . . . . . . . . . . . . . . . . . . 9 2.1.4. All Failures are Permanent . . . . . . . . . . . . . 10
4.1.7. Trace Information . . . . . . . . . . . . . . . . . . 10 2.1.5. Benign nature of an ARC Set . . . . . . . . . . . . . 10
4.1.8. Instance Tags . . . . . . . . . . . . . . . . . . . . 10 2.1.6. Key Management . . . . . . . . . . . . . . . . . . . 10
4.1.9. Chain Validation Status . . . . . . . . . . . . . . . 10 2.1.7. Trace Information . . . . . . . . . . . . . . . . . . 11
5. The ARC Header Fields . . . . . . . . . . . . . . . . . . . . 10 2.1.8. Instance Tags . . . . . . . . . . . . . . . . . . . . 11
5.1. Instance ('i=') Tag . . . . . . . . . . . . . . . . . . . 10 2.1.9. Chain Validation Status . . . . . . . . . . . . . . . 11
5.1.1. Valid Range for Instance Tags . . . . . . . . . . . . 10 3. The ARC Header Fields . . . . . . . . . . . . . . . . . . . . 11
5.2. ARC-Authentication-Results (AAR) . . . . . . . . . . . . 11 3.1. Instance ('i=') Tag . . . . . . . . . . . . . . . . . . . 11
5.2.1. ptypes and properties for arc-info . . . . . . . . . 11 3.1.1. Valid Range for Instance Tags . . . . . . . . . . . . 12
5.3. ARC-Message-Signature (AMS) . . . . . . . . . . . . . . . 12 3.2. ARC-Authentication-Results (AAR) . . . . . . . . . . . . 12
5.4. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . . . 12 3.3. ARC-Message-Signature (AMS) . . . . . . . . . . . . . . . 12
5.4.1. The 'cv' Tag . . . . . . . . . . . . . . . . . . . . 13 3.4. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . . . 13
5.4.2. Implicit Header Fields . . . . . . . . . . . . . . . 13 3.4.1. The 'cv' Tag . . . . . . . . . . . . . . . . . . . . 13
6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . 14 3.4.2. Implicit Header Fields . . . . . . . . . . . . . . . 14
6.1. Handling DNS Problems While Validating ARC . . . . . . . 15 4. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . 14
6.2. Responding to ARC Validity Violations During the SMTP 4.1. ARC Authentication-Results Stamp . . . . . . . . . . . . 16
Transaction . . . . . . . . . . . . . . . . . . . . . . . 15 4.2. Handling DNS Problems While Validating ARC . . . . . . . 16
7. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . 16 4.3. Responding to ARC Validity Violations During the SMTP
7.1. Marking and Sealing "cv=fail" (Invalid) Chains . . . . . 16 Transaction . . . . . . . . . . . . . . . . . . . . . . . 16
8. Usage of ARC and Chain Validity . . . . . . . . . . . . . . . 16 5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Relationship between DKIM-Signature and AMS signing 5.1. Marking and Sealing "cv=fail" (Invalid) Chains . . . . . 17
scopes . . . . . . . . . . . . . . . . . . . . . . . . . 16 6. Usage of ARC and Chain Validity . . . . . . . . . . . . . . . 17
8.2. Assessing Chain Validity Violations . . . . . . . . . . . 17 6.1. Relationship between DKIM-Signature and AMS signing
9. Recording and Reporting the Results of ARC Evaluation . . . . 17 scopes . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Information from an ARC Evaluation . . . . . . . . . . . 17 6.2. Assessing Chain Validity Violations . . . . . . . . . . . 17
9.2. Recording (local) ARC Evaluation Results . . . . . . . . 18 7. Recording and Reporting the Results of ARC Evaluation . . . . 18
9.3. DMARC Reporting of ARC Findings - Interim . . . . . . . . 18 7.1. Information from an ARC Evaluation . . . . . . . . . . . 18
10. Supporting Alternate Signing Algorithms . . . . . . . . . . . 19 7.2. Recording (local) ARC Evaluation Results . . . . . . . . 18
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 7.3. DMARC Reporting of ARC Findings - Interim . . . . . . . . 18
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. Supporting Alternate Signing Algorithms . . . . . . . . . . . 19
12.1. Authentication-Results Method Registry Update . . . . . 19 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
12.2. Definitions of the ARC header fields . . . . . . . . . . 20 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
13. Security Considerations . . . . . . . . . . . . . . . . . . . 21 10.1. Authentication-Results Method Registry Update . . . . . 19
13.1. Header Size . . . . . . . . . . . . . . . . . . . . . . 21 10.2. Definitions of the ARC header fields . . . . . . . . . . 21
13.2. DNS Operations . . . . . . . . . . . . . . . . . . . . . 21 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21
13.3. Message Content Suspicion . . . . . . . . . . . . . . . 22 11.1. Header Size . . . . . . . . . . . . . . . . . . . . . . 22
14. Evaluating the Efficacy of the ARC Protocol . . . . . . . . . 22 11.2. DNS Operations . . . . . . . . . . . . . . . . . . . . . 22
14.1. Success Consideration . . . . . . . . . . . . . . . . . 23 11.3. Message Content Suspicion . . . . . . . . . . . . . . . 22
14.2. Failure Considerations . . . . . . . . . . . . . . . . . 23 12. Evaluating the Efficacy of the ARC Protocol . . . . . . . . . 23
14.3. Open Questions . . . . . . . . . . . . . . . . . . . . . 23 12.1. Success Consideration . . . . . . . . . . . . . . . . . 23
14.3.1. Value of the ARC-Seal (AS) Header . . . . . . . . . 23 12.2. Failure Considerations . . . . . . . . . . . . . . . . . 23
14.3.2. DNS Overhead . . . . . . . . . . . . . . . . . . . . 23 12.3. Open Questions . . . . . . . . . . . . . . . . . . . . . 23
14.3.3. Distinguishing Valuable from Worthless Trace 12.3.1. Value of the ARC-Seal (AS) Header . . . . . . . . . 24
12.3.2. DNS Overhead . . . . . . . . . . . . . . . . . . . . 24
12.3.3. Distinguishing Valuable from Worthless Trace
Information . . . . . . . . . . . . . . . . . . . . 24 Information . . . . . . . . . . . . . . . . . . . . 24
15. Implementation Status . . . . . . . . . . . . . . . . . . . . 24 13. Implementation Status . . . . . . . . . . . . . . . . . . . . 25
15.1. GMail test reflector and incoming validation . . . . . . 25 13.1. GMail test reflector and incoming validation . . . . . . 25
15.2. AOL test reflector and internal tagging . . . . . . . . 25 13.2. AOL test reflector and internal tagging . . . . . . . . 26
15.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 26 13.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 26
15.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . 26 13.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . 26
15.5. Mailman 3.2 patch . . . . . . . . . . . . . . . . . . . 27 13.5. Mailman 3.2 patch . . . . . . . . . . . . . . . . . . . 27
15.6. Copernica/MailerQ web-based validation . . . . . . . . . 27 13.6. Copernica/MailerQ web-based validation . . . . . . . . . 27
15.7. Rspamd . . . . . . . . . . . . . . . . . . . . . . . . . 28 13.7. Rspamd . . . . . . . . . . . . . . . . . . . . . . . . . 28
15.8. PERL MAIL::DKIM module . . . . . . . . . . . . . . . . . 28 13.8. PERL MAIL::DKIM module . . . . . . . . . . . . . . . . . 29
15.9. PERL Mail::Milter::Authentication module . . . . . . . . 29 13.9. PERL Mail::Milter::Authentication module . . . . . . . . 29
15.10. Sympa List Manager . . . . . . . . . . . . . . . . . . . 29 13.10. Sympa List Manager . . . . . . . . . . . . . . . . . . . 30
15.11. Oracle Messaging Server . . . . . . . . . . . . . . . . 30 13.11. Oracle Messaging Server . . . . . . . . . . . . . . . . 30
15.12. MessageSystems Momentum . . . . . . . . . . . . . . . . 30 13.12. MessageSystems Momentum . . . . . . . . . . . . . . . . 30
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
16.1. Normative References . . . . . . . . . . . . . . . . . . 30 14.1. Normative References . . . . . . . . . . . . . . . . . . 31
16.2. Informative References . . . . . . . . . . . . . . . . . 32 14.2. Informative References . . . . . . . . . . . . . . . . . 32
16.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 33 14.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Appendix A. Appendix A - Design Requirements . . . . . . . . . . 34 Appendix A. Appendix A - Design Requirements . . . . . . . . . . 34
A.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 34 A.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 34
A.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 34 A.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 34
Appendix B. Appendix B - Example Usage . . . . . . . . . . . . . 34 Appendix B. Appendix B - Example Usage . . . . . . . . . . . . . 34
B.1. Example 1: Simple mailing list . . . . . . . . . . . . . 34 B.1. Example 1: Simple mailing list . . . . . . . . . . . . . 35
B.1.1. Here's the message as it exits the Origin: . . . . . 34 B.1.1. Here's the message as it exits the Origin: . . . . . 35
B.1.2. Message is then received at example.org . . . . . . . 35 B.1.2. Message is then received at example.org . . . . . . . 35
B.1.3. Example 1: Message received by Recipient . . . . . . 37 B.1.3. Example 1: Message received by Recipient . . . . . . 37
B.2. Example 2: Mailing list to forwarded mailbox . . . . . . 38 B.2. Example 2: Mailing list to forwarded mailbox . . . . . . 38
B.2.1. Here's the message as it exits the Origin: . . . . . 38 B.2.1. Here's the message as it exits the Origin: . . . . . 38
B.2.2. Message is then received at example.org . . . . . . . 39 B.2.2. Message is then received at example.org . . . . . . . 39
B.2.3. Example 2: Message received by Recipient . . . . . . 43 B.2.3. Example 2: Message received by Recipient . . . . . . 43
B.3. Example 3: Mailing list to forwarded mailbox with source 45 B.3. Example 3: Mailing list to forwarded mailbox with source 45
B.3.1. Here's the message as it exits the Origin: . . . . . 45 B.3.1. Here's the message as it exits the Origin: . . . . . 45
B.3.2. Message is then received at example.org . . . . . . . 46 B.3.2. Message is then received at example.org . . . . . . . 46
B.3.3. Example 3: Message received by Recipient . . . . . . 51 B.3.3. Example 3: Message received by Recipient . . . . . . 51
skipping to change at page 4, line 42 skipping to change at page 4, line 44
However its use along email transmission paths that have independent However its use along email transmission paths that have independent
intermediaries, such as some forwarders and essentially all mailing intermediaries, such as some forwarders and essentially all mailing
list services, produces false positive rejections that are list services, produces false positive rejections that are
problematic, both for the message authors, the intermediary problematic, both for the message authors, the intermediary
service(s), and for those they are interacting with. service(s), and for those they are interacting with.
What is needed is a mechanism by which legitimate alteration of a What is needed is a mechanism by which legitimate alteration of a
message, which invalidates associated SPF and DKIM information, does message, which invalidates associated SPF and DKIM information, does
not ultimately result in a rejection of an email message on delivery. not ultimately result in a rejection of an email message on delivery.
Authenticated Receive Chain (ARC) builds upon DKIM mechanisms to Authenticated Receive Chain (ARC) builds upon DKIM mechanisms to
provide a sequence of signatures that are more survivable than DKIM's provide a sequence of signatures that provide a view of the handling
and that provide a view of the handling sequence for a message, sequence for a message, especially the points where alterations of
especially the points where alterations of the content might have the content might have occurred. Equipped with this more complete
occurred. Equipped with this more complete information, the information, the recipient system(s) can make a more informed
recipient system(s) can make a more informed handling choice, handling choice, reducing or eliminating the false negatives inherent
reducing or eliminating the false negatives inherent in use of DKIM in use of DKIM and/or SPF themselves.
and/or SPF themselves.
2. Overview 1.1. Overview
ARC provides a "chain of custody" for a message, allowing each entity
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
deliver the message, or, alternatively, to reject, discard, or
quarantine it, can take the chain of custody into account, applying
local policy in addition to policies advertised by the (purported)
sending domain. Consider, for example, this scenario:
1. A sender from mysender.example posts a message to a mailing list
hosted at listmania.example;
2. The mailing list modifies the message by prepending the list name
to the subject line, then sends it to the subscribers;
3. One of the subscribers is alice@mail.service.example, which
receives the message from listmania.example.
Assuming the original message was DKIM-signed and mysender.example
published an SPF record, the handling by the mailing list will break
the DKIM signature because of the message modification, and the
forwarding will cause SPF check to fail in the next step. But
listmania.example can add ARC headers to the message to add itself to
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,
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 and that modifications made were benign, it
can deliver the message, rather than reject it, based on the
additional information that ARC has provided.
1.1.1. High Level Summary
In DKIM, every participating signing agent attaches a signature that In DKIM, every participating signing agent attaches a signature that
is based on the some of the content of the message, local policy, and is based on the some of the content of the message, local policy, and
the domain name of the participating Administrative Management Domain the domain name of the participating Administrative Management Domain
(ADMD). Any verifier can process such a signature; a verified (ADMD). Any verifier can process such a signature; a verified
signature means that the domain referenced in the DKIM-Signture's signature means that the domain referenced in the DKIM's "d="
"d=" parameter has some responsibility for handling the message. An parameter has some responsibility for handling the message. An
artifact of using digital signature technology for this means that artifact of using digital signature technology for this means that
verification also ensures that the message content that was "covered" verification also ensures that the portion of the message that was
by the signature has not been altered since the signature was "covered" by the signature has not been altered since the signature
applied. The signatures themselves are generally independent of one was applied. The signatures themselves are generally independent of
another. one another.
By contrast, an ARC signature conveys the following pieces of By contrast, an ARC signature conveys the following pieces of
information: information:
1. An assertion that, at the time that the intermediary ADMD 1. An assertion that, at the time that the intermediary ADMD
processed the message, the various assertions (DKIM-Signature(s) processed the message, the various assertions (DKIM-Signature(s)
and/or ARC sets) already attached to the message by other ADMDs and/or ARC sets) already attached to the message by other ADMDs
were or were not valid; were or were not valid;
2. As with DKIM, an assertion that, for a validated signature, the 2. As with DKIM, an assertion that, for a validated ARC signature,
domain name in the signature takes some responsibility for the domain name in the signature takes some responsibility for
handling of the message and that the message is unchanged since handling of the message and that the message is unchanged since
that signature was applied; that signature was applied;
3. A further assertion that binds the ARC evaluation results into 3. A further assertion that binds the ARC evaluation results into
the ARC chain sequence. the ARC chain sequence.
This protocol accomplishes each of these by adding a new header field This protocol accomplishes each of these by adding new header fields
to the message for each of these pieces of information, as follows: to the message with these pieces of information:
o ARC-Authentication-Results (referred to below as "AAR"): virtually o ARC-Authentication-Results (referred to below as "AAR"): virtually
identical in syntax to an Authentication-Results field [RFC7601], identical in syntax to an Authentication-Results field [RFC7601],
this field records the results of all message authentication this field records the results of all message authentication
checks done by the recording ADMD at the time the message arrived. checks done by the recording ADMD at the time the message arrived.
Additional information is placed in this field compared to a Additional information is placed in this field compared to a
standard Authentication-Results field in order to support a more standard Authentication-Results field in order to support a more
complete DMARC report (see Section 5.2); complete DMARC report (see Section 3.2);
o ARC-Message-Signature (referred to below as "AMS"): virtually o ARC-Message-Signature (referred to below as "AMS"): virtually
identical in syntax to DKIM-Signature, this field contains the identical in syntax to DKIM-Signature, this field contains the
signature about the message header and body as they existed at the signature about the message header and body as they existed at the
time of handling by the ADMD adding it; and time of handling by the ADMD adding it; and
o ARC-Seal (referred to below as "AS"): highly similar in structure o ARC-Seal (referred to below as "AS"): highly similar in structure
and format to a DKIM-Signature, this field applies a digital and format to a DKIM-Signature, this field applies a digital
signature that protects the integrity of all three of these new 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 when they are added by an ADMD, plus all instances of these
fields added by prior ADMDs. fields added by prior ADMDs.
A distinguishing feature of all of these is that an ARC participant A distinguishing feature of all of these is that an ARC participant
always adds all of them before relaying a message to the next always adds all of them before relaying a message to the next
handling agent en route to its destination. Moreover, as described handling agent en route to its destination. Moreover, as described
in Section 5.1, they each have an "instance" number that increases in Section 3.1, they each have an "instance" number that increases
with each ADMD in the handling chain so that their original order can with each ADMD in the handling chain so that their original order can
be preserved and the three related header fields can be processed as be preserved and the three related header fields can be processed as
a group. a group.
3. Definitions and Terminology 1.1.2. Technical Summary
[[ possibly including a diagram - this may not be needed any more ]]
1.2. Definitions and Terminology
This section defines terms used in the rest of the document. This section defines terms used in the rest of the document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119][RFC8174].
Because many of the core concepts and definitions are found in Because many of the core concepts and definitions are found in
[RFC5598], readers SHOULD to be familiar with the contents of [RFC5598], readers SHOULD to be familiar with the contents of
[RFC5598], and in particular, the potential roles of intermediaries [RFC5598], and in particular, the potential roles of intermediaries
in the delivery of email. in the delivery of email.
Syntax descriptions use Augmented BNF (ABNF) [RFC5234]. Syntax descriptions use Augmented BNF (ABNF) [RFC5234].
o "ARC set" - A single group of the header fields introduced in o "ARC set" - A single group of the header fields introduced in
Section 2 is called an "ARC set". Section 1.1 is called an "ARC set".
o "ARC chain" - The complete sequence of these groups (ARC sets) is o "ARC chain" - The complete sequence of these groups (ARC sets) is
called an "Authenticated Received Chain" or merely an "ARC chain". called an "ARC chain". Although the "Received" header field is
Although the "Received" header field is typically not included in typically not included in the signed content, the name is based on
the signed content, the name is based on the notion that this is the notion that this is in essence a cryptographically signed
in essence a cryptographically signed series of header fields that series of header fields that attest to the handling chain of a
attest to the handling chain of a message much as Received fields message much as Received fields always have.
always have.
3.1. Referenced Definitions 1.3. Referenced Definitions
The following terms are defined in other RFCs. Those definitions can The following terms are defined in other RFCs. Those definitions can
be found as follows: be found as follows:
o ADMD - [RFC5598], Section 2.3 o ADMD - [RFC5598], Section 2.3
o MTA - [RFC5598], Section 4.3.2 o MTA - [RFC5598], Section 4.3.2
o MSA - [RFC5598], Section 4.3.1 o MSA - [RFC5598], Section 4.3.1
o MDA - [RFC5598], Section 4.3.3
o MDA - [RFC5598], Section 4.3.3
The three header fields that are part of this specification borrow The three header fields that are part of this specification borrow
heavily from existing specifications. Rather than repeating all of heavily from existing specifications. Rather than repeating all of
the formal definitions that are being reused in ARC, this document the formal definitions that are being reused in ARC, this document
only describes and specifies changes in syntax and semantics. only describes and specifies changes in syntax and semantics.
Language, syntax, and other details are imported from DKIM [RFC6376]. Language, syntax, and other details are imported from DKIM [RFC6376].
Specific references can be found below. Specific references can be found below.
4. Protocol Elements and Features 2. Protocol Elements and Features
As with other domain authentication technologies (such as SPF, DKIM, As with other domain authentication technologies (such as SPF, DKIM,
and DMARC), ARC makes no claims about the contents of the email 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 message it has sealed. However, for a valid and passing ARC chain, a
Final Receiver is able to ascertain: Final Receiver is able to ascertain:
o all (participating) domains that claim responsibility for handling o all (participating) domains that claim responsibility for handling
(and possibly) modifying the email message in transit; (and possibly modifying) the email message in transit;
o trace information, including: o trace information, including:
* the [RFC7601] authentication results each participating ADMD * the [RFC7601] authentication results each participating ADMD
saw; and saw; and
* additional data needed to compile a DMARC report for the * additional data needed to compile a DMARC report for the
sending domain. sending domain.
Given this information, a Final Receiver is able to make a more- Given this information, a Final Receiver is able to make a more-
informed local policy decision regarding message delivery to the end informed local policy decision regarding message delivery to the end
user in spite of a DMARC failure. user in spite of an authentication failure.
Every participant in an ARC chain, except for the originating sender Every participant in an ARC chain, except for the originating sender
and Final Receiver, is both an ARC Validator (when receiving) and and Final Receiver, is both an ARC Validator (when receiving) and
then an ARC Sealer (when sending a message onward). The validated then an ARC Sealer (when sending a message onward). The validated
chain status as determined at message receipt must be passed to the chain status as determined at message receipt must be passed to the
sealer function in order for sealing to occur properly; how this is sealer function in order for sealing to occur properly; how this is
done is considered ADMD-specific and an implementation detail. done is considered ADMD-specific and an implementation detail.
_INFORMATIONAL_: It is important to understand that validating and _INFORMATIONAL_: It is important to understand that validating and
then immediately sealing a message leaves no room for message then immediately sealing a message leaves no room for message
modification, and many early implementations of ARC did not initially modification, and many early implementations of ARC did not initially
work because both operations were performed in a single pass over the work because both operations were performed in a single pass over the
message. message.
4.1. Features of the ARC Protocol 2.1. Features of the ARC Protocol
The following protocol features are functional parts and design The following protocol features are functional parts and design
decisions related the protocol that are not specific to either decisions related the protocol that are not specific to either
Validators or Sealers, but ensure the ARC chain conveys this Validators or Sealers, but ensure the ARC chain conveys this
information to a Final Receiver. information to a Final Receiver.
4.1.1. Chain of Custody 2.1.1. Chain of Custody
At a high level, an ARC chain represents a chain of custody of At a high level, an ARC chain represents a chain of custody of
authentication and other trace information (AAR) related to a authentication and other trace information (AAR) related to a
message, signed by each handler of the message. Each link in the message, signed by each handler of the message. Each link in the
chain (AMS) is designed to be brittle, insofar as it survives only chain (AMS) is designed to be brittle, insofar as it survives only
until the next modification of the message. However, the sequence of until the next modification of the message. However, the sequence of
intermediaries in the handling chain (AS) is designed to remain intermediaries in the handling chain (AS) is designed to remain
intact over the entirety of the chain. intact over the entirety of the chain.
The ARC chain can be conceptualized through an analogy with the chain The ARC chain can be conceptualized through an analogy with the chain
of custody for legal evidence. The material evidence itself is of custody for legal evidence. The material evidence itself is
sealed within an tamper-proof bag (AMS) each time. When handed to a sealed within an tamper-proof bag (AMS) each time. When handed to a
new party, that party both vouches for the state of the received new party, that party both vouches for the state of the received
evidence container (AAR) and signs for the evidence on a chain of evidence container (AAR) and signs for the evidence on a chain of
custody report form (AS). As with all analogies, this one should not custody report form (AS). As with all analogies, this one should not
be taken to interpretive extremes, but primarily used as a conceptual be taken to interpretive extremes, but primarily used as a conceptual
framework. framework.
An ARC chain that is valid and passing has the attributes listed An ARC chain that is valid and passing has the attributes listed
above in Section 4. above in Section 2.
Recipients of an ARC chain that is invalid or does not pass SHOULD Recipients of an ARC chain that is invalid or does not pass SHOULD
NOT draw negative conclusions without a good understanding of the NOT draw negative conclusions without a good understanding of the
wider handling context. Until ARC usage is widespread, wider handling context. Until ARC usage is widespread,
intermediaries will continue to modify messages without ARC seals. intermediaries will continue to modify messages without ARC seals.
As with a failing DKIM signature ([RFC6376] Section-6.3), a failing As with a failing DKIM signature ([RFC6376] Section-6.3), a failing
ARC chain SHOULD be treated the same as a message with no ARC chain. ARC chain SHOULD be treated the same as a message with no ARC chain.
[[ NOTE TO WORKING GROUP: This paragraph probably is better placed in [[ NOTE TO WORKING GROUP: This paragraph probably is better placed in
Verifier actions. ]] Verifier actions. Ref issue 10 [1] ]]
4.1.2. Optional Participation 2.1.2. Optional Participation
Validating an existing chain and then adding your own ARC set to a Validating an existing chain and then adding your own ARC set to a
message allows you to claim responsibility for hanndling the message message allows you to claim responsibility for handling the message
and modifications, if any, done by your ADMD to benefit message and modifications, if any, done by your ADMD to benefit message
delivery downstream. However, no ADMD is obligated to perform these delivery downstream. However, no ADMD is obligated to perform these
actions. actions.
4.1.3. Only one ARC Chain (One Chain to Rule Them All) 2.1.3. Only one ARC Chain (One Chain to Rule Them All)
A message can have only one ARC chain on it at a time (see A message can have only one ARC chain on it at a time (see
Section 5.1). Once broken, the chain cannot be restarted, as the Section 3.1). Once broken, the chain cannot be continued, as the
chain of custody is no longer valid and responsibility for the chain of custody is no longer valid and responsibility for the
message has been lost. message has been lost. For further discussion of this topic and the
designed restriction which prevents chain continuation or re-
establishment, see [ARC-USAGE].
4.1.4. All Failures are Permanent 2.1.4. All Failures are Permanent
Because ARC chains are transmitted across multiple intermediaries, Because ARC chains are transmitted across multiple intermediaries,
all errors, even temporary ones, become unrecoverable and are all errors, even temporary ones, become unrecoverable and are
considered permanent. considered permanent.
Any error validating or sealing a chain, for whatever reason, MUST Any error validating or sealing a chain, for whatever reason, MUST
result in a "cv=fail" verdict. result in a "cv=fail" verdict.
4.1.5. Benign nature of an ARC Set 2.1.5. Benign nature of an ARC Set
Even when an ARC chain is valid and passes, its value is limited to Even when an ARC chain is valid and passes, its value is limited to
very specific cases. An ARC chain is specifically designed to very specific cases. An ARC chain is specifically designed to
provide value to a Final Receiver evaluating message delivery in the provide value to a Final Receiver evaluating message delivery in the
context of a DMARC failure. An ARC chain in general, and each ARC context of an authentication failure. An ARC chain in general, and
set in particular, provide additional information, and otherwise is each ARC set in particular, provide additional information, and
benign. Specifically: otherwise is benign. Specifically:
o properly adding an ARC set to a message does not damage or o properly adding an ARC set to a message does not damage or
invalidate an existing chain, and invalidate an existing chain, and
o validating a message exposes no new threat vectors (see o validating a message exposes no new threat vectors (see
Section 13). Section 11).
_INFORMATIONAL_: If an ADMD is unsure whether it will be re-emitting _INFORMATIONAL_: If an ADMD is unsure whether it will be re-emitting
and/or modifying a message, it may elect to seal all inbound mail. and/or modifying a message, it may elect to seal all inbound mail.
For complex or nested ADMD relationships such as found in some hosted For complex or nested ADMD relationships such as found in some hosted
mail solutions, this "inbound seal" can be used to facilitate mail solutions, this "inbound seal" can be used to facilitate
traversal of internal boundaries as well as properly conveying traversal of internal boundaries as well as properly conveying
incoming state to any egress MTAs that may need to assert a seal upon incoming state to any egress MTAs that may need to assert a seal upon
exit from the ADMD. Since these internal relationships are highly exit from the ADMD. Since these internal relationships are highly
implementation dependent, this protocol definition can not usefully implementation dependent, this protocol definition can not usefully
explore such usage except to note that it is intentionally allowed explore such usage except to note that it is intentionally allowed
within the scope of this specification. within the scope of this specification.
4.1.6. Key Management 2.1.6. Key Management
The public keys for ARC header fields follow the same requirements, The public keys for ARC header fields follow the same requirements,
syntax and semantics as those for DKIM signatures, described in syntax and semantics as those for DKIM signatures, described in
Section 3.6 of [RFC6376]. ARC places no requirements on the Section 3.6 of [RFC6376]. ARC places no requirements on the
selectors and/or domains used for the ARC header field signatures. selectors and/or domains used for the ARC header field signatures.
4.1.7. Trace Information 2.1.7. Trace Information
ARC includes trace information encoded in the AAR. While section ARC includes trace information encoded in the AAR. While section
Section 5.2 defines what information must be provided, sealing ADMDs Section 3.2 defines what information must be provided, sealing ADMDs
may provide additional information, and validating receivers may use may provide additional information, and validating receivers may use
or ignore this trace information as they wish. or ignore this trace information as they wish.
4.1.8. Instance Tags 2.1.8. Instance Tags
See section Section 5.1 ARC introduces an indicator to its header fields to show the order in
which the header fields comprising an ARC set were added, and the
specific members of an ARC Set. This is known as an "instance", and
the indicator is an "i=". 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.
4.1.9. Chain Validation Status 2.1.9. Chain Validation Status
See section Section 5.4.1 ARC introduces a mechanism, also via a new tag, which indicates the
state of the ARC Chain at each step. This is the "chain validation
status". This is described in detail in section Section 3.4.1.
5. The ARC Header Fields 3. The ARC Header Fields
5.1. Instance ('i=') Tag 3.1. Instance ('i=') Tag
The header fields comprising a single ARC set are identified by the The header fields comprising a single ARC set are identified by the
presence of a string in the value portion of the header field that presence of a string in the value portion of the header field that
complies with the "tag-spec" ABNF found in Section 3.2 of [RFC6376]. 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 The tag-name is "i" and the value is the text representation of a
positive integer, indicating the position in the ARC sequence this positive integer, indicating the position in the ARC sequence this
set occupies, where the first ARC set is numbered 1. In ABNF terms: set occupies, where the first ARC set is numbered 1. In ABNF terms:
instance = [FWS] %x69 [FWS] "=" [FWS] position [FWS] ";" instance = [FWS] %x69 [FWS] "=" [FWS] position [FWS] ";"
position = 1*2DIGIT ; 1 - 50 position = 1*2DIGIT ; 1 - 50
Valid ARC sets must have exactly one instance of each header field Valid ARC sets must have exactly one instance of each header field
for a given position value and signing algorithm. (Initial for a given position value and signing algorithm. (Initial
development of ARC is only being done with a single allowed signing development of ARC is only being done with a single allowed signing
algorithm, but parallel work in the DCRUP working group algorithm, but parallel work in the DCRUP working group [2] is
(https://datatracker.ietf.org/wg/dcrup/about/) is expanding that. expanding that. For handling multiple signing algorithms, see
For handling multiple signing algorithms, see [ARC-MULTI].) [ARC-MULTI].)
Because the AMS and AS header field values are made up of tag-spec Because the AMS and AS header field values are made up of tag-spec
constructs, the i= tag may be found anywhere within the header field constructs, the i= tag may be found anywhere within the header field
value, but is represented throughout this spec in the initial value, but is represented throughout this spec in the initial
position for convenience. Implementers are encouraged to place the position for convenience. Implementers are encouraged to place the
i= tag at the beginning of the field value to facilitate human i= tag at the beginning of the field value to facilitate human
inspection of the headers. inspection of the headers.
5.1.1. Valid Range for Instance Tags 3.1.1. Valid Range for Instance Tags
The 'i' tag value can range from 1-50 (inclusive). The 'i' tag value can range from 1-50 (inclusive).
ARC implementations MUST support at least ten (10) ARC sets. ARC implementations MUST support at least ten (10) ARC sets.
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 and will be documented within deployment experience in the field and will be documented within
[ARC-USAGE] once determined. [ARC-USAGE] once determined.
ARC chains with more than the defined operational maximum count MUST ARC chains with more than the defined operational maximum count MUST
be marked with "cv=fail". be marked with "cv=fail".
5.2. ARC-Authentication-Results (AAR) 3.2. ARC-Authentication-Results (AAR)
The ARC-Authentication-Results header field is syntactically and The ARC-Authentication-Results header field is syntactically and
semantically identical to an Authentication-Results header field semantically identical to an Authentication-Results header field
(defined in Section 2.2 of [RFC7601] (A-R)), except that several (defined in Section 2.2 of [I-D-7601bis] (A-R)). Note that several
optional data fields SHOULD be added. ([[ NOTE: these optional data optional data fields SHOULD be added (smtp.client-ip, dkim header.s,
fields are being proposed as amendments to [RFC7601] through a "bis" arc.oldest-pass) to enable completeness for DMARC reporting.
process. Depending on the sequencing for this specification and said
"7601bis" work, it may be possible to drop the noted sections from Formally, the header field is specified as follows using ABNF
this specification. ]]) The first element ("Authentication-Results:") [RFC5234]:
in authres-header is replaced with arc-authres-prefix as follows:
arc-authres-header-prefix = "ARC-Authentication-Results:" [CFWS] arc-info arc-authres-header-prefix = "ARC-Authentication-Results:" [CFWS] arc-info
arc-info = instance *([CFWS] propspec) [CFWS] ";" arc-info = instance *([CFWS] propspec) [CFWS] ";" authres-payload
The purpose of this header field is to transmit the results of any The purpose of this header field is to transmit the results of any
authentication done on the message upstream to participating ADMDs authentication done on the message downstream to participating ADMDs
validating and continuing the chain. validating and continuing the chain.
The AAR MUST contain all A-R results from within the participating The AAR MUST contain all A-R results from within the participating
ADMD, regardless of how many A-R headers are on the message. ADMD, regardless of how many A-R headers are on the message.
5.2.1. ptypes and properties for arc-info 3.3. ARC-Message-Signature (AMS)
[[ NOTE: This section is being proposed as an amendment to [RFC7601]
through a "bis" process. Depending on the sequencing for this
specification and said "7601bis" work, it may be possible to this
section from this specification. ]]
Certain information pertinent to ascertaining message disposition can
be lost in transit when messages are handled by intermediaries. For
example, failing DKIM signatures are sometimes removed by MTAs, and
most DKIM signatures on messages modified by intermediaries will
fail.
The AAR, through these ptype-properties stamped in arc-info, provide
a mechanism for this information to survive transit.
The ptypes and properties defined in this section SHOULD be stamped
in the AAR:
o smtp.client-ip - The connecting client IP address from which the
message is received;
o header.s - Defined in [RFC6376] section 7.2
o arc.oldest-pass - The instance number of the oldest AMS that still
validates, or 0 if all pass.
5.3. ARC-Message-Signature (AMS)
The ARC-Message-Signature header field is syntactically and The ARC-Message-Signature header field is syntactically and
semantically identical to a DKIM-Signature header field [RFC6376], semantically identical to a DKIM-Signature header field [RFC6376],
with the following exceptions: with the following exceptions:
o There is an "i" tag, as described in Section 5.1. o There is an "i" tag, as described in Section 3.1.
o There is no "v" tag. o There is no "v" tag defined for the AMS header. As required for
undefined tags, if seen, it MUST be ignored.
ARC-Seal header fields MUST NOT be included in the content covered by ARC-Seal header fields MUST NOT be included in the content covered by
the signature in this header field. the signature in this header field.
The AMS SHOULD include any DKIM-Signature header fields already The AMS SHOULD include any DKIM-Signature header fields already
present on the message in the header fields covered by this present on the message in the header fields covered by this
signature. signature.
The AMS header field MAY include (sign) the AAR header field(s). The AMS header field SHOULD not include (sign) the AAR header
field(s). (Early drafts of this protocol and some older examples
included the AAR header(s) within the signing scope for the AMS, but
ambiguity regarding which of the potentially multiple AAR headers
(one per ARC set) argues against such practice.)
Authentication-Results header fields SHOULD NOT be included since Authentication-Results header fields SHOULD NOT be included since
they are likely to be deleted by downstream ADMDs (per Section XXX of they are likely to be deleted by downstream ADMDs (per Section XXX of
[RFC7601]), thereby breaking the AMS signature. [RFC7601]), thereby breaking the AMS signature.
As with a DKIM-Signature, the purpose of this header field is to As with a DKIM-Signature, the purpose of this header field is to
allow the ADMD generating it to take some responsibility for handling allow the ADMD generating it to take some responsibility for handling
this message as it progresses toward delivery. this message as it progresses toward delivery.
5.4. ARC-Seal (AS) 3.4. ARC-Seal (AS)
The ARC-Seal header field is syntactically and semantically similar The ARC-Seal header field is syntactically and semantically similar
to a DKIM-Signature field, with the following exceptions: to a DKIM-Signature field, with the following exceptions:
o There is an "i" tag, as described in Section 5.1. o There is an "i" tag, as described in Section 3.1.
o The ARC-Seal covers none of the body content of the message. It o The ARC-Seal covers none of the body content of the message. It
only covers specific header fields. (See below: Section 5.4.2.) only covers specific header fields. (See below: Section 3.4.2.)
As a result, no body canonicalization is done. Further, only As a result, no body canonicalization is done. Further, only
"relaxed" header canonicalization (Section 3.4.2 of [RFC6376]) is "relaxed" header canonicalization (Section 3.4.2 of [RFC6376]) is
used. used.
o The only supported tags are "i" (Section 5.1 supercedes the o The only supported tags are "i" (Section 3.1 supercedes the
[RFC6376] definition), and "a", "b", "d, "s", "t". The latter 5 [RFC6376] definition), and "a", "b", "d, "s", "t". The latter 5
tag definitions are copied from Section 3.5 of [RFC6376]. tag definitions are copied from Section 3.5 of [RFC6376].
o An additional tag, "cv" is defined. (See below: Section 5.4.1) o An additional tag, "cv" is defined. (See below: Section 3.4.1)
5.4.1. The 'cv' Tag 3.4.1. The 'cv' Tag
A new tag "cv" (chain validation) indicates the the outcome of A new tag "cv" (chain validation) indicates the the outcome of
evaluating the existing ARC chain upon arrival at the ADMD that is evaluating the existing ARC chain upon arrival at the ADMD that is
adding this header field. It accepts one of three possible values: adding this header field. It accepts one of three possible values:
o none: There was no chain on the message when it arrived for o none: There was no chain on the message when it arrived for
validation; typically occurs when the message arrives at a Message validation; typically occurs when the message arrives at a Message
Transfer Agent (MTA) from a Message Submission Agent (MSA) or when Transfer Agent (MTA) from a Message Submission Agent (MSA) or when
any upstream MTAs may not be participating in ARC handling; any upstream MTAs may not be participating in ARC handling;
o fail: The message has a chain whose validation failed; o fail: The message has a chain whose validation failed;
o pass: The message has a chain whose validation succeeded. o pass: The message has a chain whose validation succeeded.
In ABNF terms: In ABNF terms:
seal-cv-tag = %x63.76 [FWS] "=" [FWS] ("none" / "fail" / "pass") seal-cv-tag = %x63.76 [FWS] "=" [FWS] ("none" / "fail" / "pass")
5.4.2. Implicit Header Fields 3.4.2. Implicit Header Fields
The ARC-Seal signs a canonicalized form of the ARC set header values. The ARC-Seal signs a canonicalized form of the ARC set header values.
The ARC set header values are compiled in increasing instance order, The ARC set header values are compiled in increasing instance order,
starting at 1, and inclue the set being added at the time of sealing starting at 1, and inclue the set being added at the time of sealing
the message. the message.
Within a set, the header fields are listed in the following order: Within a set, the header fields are listed 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 Where the ARC-Seal is the one being generated, it is input to the
hash function in its final form except with an empty "b=" value, in hash function in its final form except with an empty "b=" value, in
the same manner by which a DKIM-Signature signs itself. the same manner by which a DKIM-Signature signs itself.
Note that the signing scope for the ARC-Seal is modified in the Note that the signing scope for the ARC-Seal is modified in the
situation where a chain has failed validation (see Section 7.1). situation where a chain has failed validation (see Section 5.1).
6. Verifier Actions 4. Verifier Actions
A verifier takes the following steps to determine the state of the A verifier takes the following steps to determine the state of the
ARC chain on a message (cv value). Canonicalization, hash functions, ARC chain on a message (cv value). Canonicalization, hash functions,
and signature validation methods are imported from Section 5 of and signature validation methods are imported from Section 5 of
[RFC6376]. [RFC6376].
[[ Note: need markdown flag to have subordinate numbering distinction [[ Note: need markdown flag to have subordinate numbering distinction
]] issue 11 [3] ]]
1. Collect all ARC sets currently on the message. If there were 1. Collect all ARC sets currently on the message. If there were
none, the ARC state is "none" and the algorithm stops here. none, the ARC state is "none" and the algorithm stops here.
2. If the form of any ARC set is invalid (e.g., does not contain 2. If the form of any ARC set is invalid (e.g., does not contain
exactly one of each of the three ARC-specific header fields), exactly one of each of the three ARC-specific header fields),
then the chain state is "fail" and the algorithm stops here. then the chain state is "fail" and the algorithm stops here. a.
To avoid the overhead of unnecessary computation and delay from
1. To avoid the overhead of unnecessary computation and delay crypto and DNS operations, the cv value for all ARC-Seal(s) MAY
from crypto and DNS operations, the cv value for all ARC- be checked at this point. If any of the values are "fail", then
Seal(s) MAY be checked at this point. If any of the values the overall state of the chain is "fail" and the algorithm stops
are "fail", then the overall state of the chain is "fail" and here.
the algorithm stops here.
3. Conduct verification of the ARC-Message-Signature header field 3. Conduct verification of the ARC-Message-Signature header field
bearing the highest instance number. If this verification fails, bearing the highest instance number. If this verification fails,
then the chain state is "fail" and the algorithm stops here. then the chain state is "fail" and the algorithm stops here.
4. For each ARC-Seal from the "N"th instance to the first, apply the 4. For each ARC-Seal from the "N"th instance to the first, apply the
following logic: following logic: a. If the value of the "cv" tag on that seal is
"fail", the chain state is "fail" and the algorithm stops here.
1. If the value of the "cv" tag on that seal is "fail", the (This step SHOULD be skipped if the earlier step (2.1) was
chain state is "fail" and the algorithm stops here. (This performed) b. In Boolean nomenclature: if ((i == 1 && cv !=
step SHOULD be skipped if the earlier step (2.1) was "none") or (cv == "none" && i != 1)) then the chain state is
performed) "fail" and the algorithm stops here (note that the ordering of
the logic is structured for short-circuit evaluation). c.
2. In Boolean nomenclature: if ((i == 1 && cv != "none") or (cv Initialize a hash function corresponding to the "a" tag of the
== "none" && i != 1)) then the chain state is "fail" and the ARC-Seal. d. Compute the canonicalized form of the ARC header
algorithm stops here (note that the ordering of the logic is fields, in the order described in Section 3.4.2, using the
structured for short-circuit evaluation). "relaxed" header canonicalization defined in Section 3.4.2 of
[RFC6376]. Pass the canonicalized result to the hash function.
3. Initialize a hash function corresponding to the "a" tag of e. Retrieve the final digest from the hash function. f.
the ARC-Seal. Retrieve the public key identified by the "s" and "d" tags in the
ARC-Seal, as described in Section 2.1.6. g. Determine whether
4. Compute the canonicalized form of the ARC header fields, in the signature portion ("b" tag) of the ARC-Seal and the digest
the order described in Section 5.4.2, using the "relaxed" computed above are valid according to the public key. (See also
header canonicalization defined in Section 3.4.2 of Section Section 4.2 for failure case handling) h. If the
[RFC6376]. Pass the canonicalized result to the hash signature is not valid, the chain state is "fail" and the
function. algorithm stops here.
5. Retrieve the final digest from the hash function.
6. Retrieve the public key identified by the "s" and "d" tags in
the ARC-Seal, as described in Section 4.1.6.
7. Determine whether the signature portion ("b" tag) of the ARC-
Seal and the digest computed above are valid according to the
public key. (See also Section Section 6.1 for failure case
handling)
8. If the signature is not valid, the chain state is "fail" and
the algorithm stops here.
5. If all seals pass validation, then the chain state is "pass", and 5. If all seals pass validation, then the chain state is "pass", and
the algorithm is complete. the algorithm is complete.
[[ Note from Dave: possibly delete the following paragraph as it is 6. Results from the determination of this algorithm SHOULD be
more usage/procedural than specification guidance. recorded in the Authentication-Results header
KA: It was added to clarify the separation of the verification and Whatever the end result of the verifier's checks via the algorithm
signing steps as some of the initial implementations failed to specified above, the results MUST be added into the Authentication-
realize that they were not necessarily done in one fell swoop. Results header(s) for the ADMD.
KA (v-10): With the addition of the {protocol-elements} section, does [[ See issue 12 [4] regarding the final paragraph ]]
the WG think that this can be reasonably removed from this location?
]]
The verifier should save the cv state for subsequent use by any The verifier should save the cv state for subsequent use by any
sealing which may be done later (potentially after message sealing which may be done later (potentially after message
modification) within the same trust boundary. The cv state may be modification) within the same trust boundary. The cv state may be
recorded by sealing at the time of verification in an initial ARC set recorded by sealing at the time of verification in an initial ARC set
(for the ADMD) or may be recorded out of band depending on the (for the ADMD) or may be recorded out of band depending on the
architecture of the ADMD. architecture of the ADMD.
6.1. Handling DNS Problems While Validating ARC 4.1. ARC Authentication-Results Stamp
Certain information pertinent to ascertaining message disposition can
be lost in transit when messages are handled by intermediaries. For
example, failing DKIM signatures are sometimes removed by MTAs, and
most DKIM signatures on messages modified by intermediaries will
fail. Stamping the following information in the A-R provides a
mechanism for this information to survive transit.
The ptypes and properties defined in this section SHOULD be recorded
in the AR:
o smtp.client-ip - The connecting client IP address from which the
message is received;
o header.s - Defined in [RFC6376] section 7.2
o arc.oldest-pass - The instance number of the oldest AMS that still
validates, or 0 if all pass.
4.2. Handling DNS Problems While Validating ARC
DNS-based failures to verify a chain are treated no differently than DNS-based failures to verify a chain are treated no differently than
any other ARC violation. They result in a "cv=fail" verdict. any other ARC violation. They result in a "cv=fail" verdict.
6.2. Responding to ARC Validity Violations During the SMTP Transaction 4.3. Responding to ARC Validity Violations During the SMTP Transaction
If a receiver determines that the ARC chain has failed, the receiver If a receiver determines that the ARC chain has failed, the receiver
MAY signal the breakage through the extended SMTP response code 5.7.7 MAY signal the breakage through the extended SMTP response code 5.7.7
[RFC3463] "message integrity failure" [ENHANCED-STATUS] and [RFC3463] "message integrity failure" [ENHANCED-STATUS] and
corresponding SMTP response code. corresponding SMTP response code.
7. Signer Actions 5. Signer Actions
[[ Note from Dave: This seems more like implementation guidance than [[ See issue 13 [5] for critique ]]
specification detail. KA: see explanation just above referring to
the previous note. ]]
This section includes a specification of the actions an ARC signer This section includes a specification of the actions an ARC signer
takes when presented with a message. takes when presented with a message.
The signer MUST undertake the following steps: The signer MUST undertake the following steps:
1. Before creating an ARC signature, perform any other, normal 1. Before creating an ARC signature, perform any other, normal
authentication and/or signing, so that the ARC signature can authentication and/or signing, so that the ARC signature can
cover those results. cover those results.
skipping to change at page 16, line 31 skipping to change at page 17, line 16
1. If an ARC chain exists on the message, then set "N" equal to 1. If an ARC chain exists on the message, then set "N" equal to
the highest instance number found on the chain (i=); the highest instance number found on the chain (i=);
otherwise set "N" equal to zero for the following steps. otherwise set "N" equal to zero for the following steps.
2. Generate and attach to the message an ARC-Authentication- 2. Generate and attach to the message an ARC-Authentication-
Results header field using instance number N+1 and the same Results header field using instance number N+1 and the same
content from the previous step. content from the previous step.
3. Generate and attach to the message an ARC-Message-Signature 3. Generate and attach to the message an ARC-Message-Signature
header field as defined in Section 5.3 above, using instance header field as defined in Section 3.3 above, using instance
number N+1. number N+1.
4. Generate and attach to the message an ARC-Seal header field 4. Generate and attach to the message an ARC-Seal header field
using the general algorithm described in Section 5.4 above, using the general algorithm described in Section 3.4 above,
the chain validation status as determined in Section 6, and the chain validation status as determined in Section 4, and
instance number N+1. instance number N+1.
7.1. Marking and Sealing "cv=fail" (Invalid) Chains 5.1. Marking and Sealing "cv=fail" (Invalid) Chains
The header fields signed by the AS header field b= value in the case The header fields signed by the AS header field b= value in the case
of a chain failure MUST be only the matching 'i=' instance headers of a chain failure MUST be only the matching 'i=' instance headers
created by the MTA which detected the malformed chain, as if this created by the MTA which detected the malformed chain, as if this
newest ARC set was the only set present. newest ARC set was the only set present.
8. Usage of ARC and Chain Validity 6. Usage of ARC and Chain Validity
8.1. Relationship between DKIM-Signature and AMS signing scopes 6.1. Relationship between DKIM-Signature and AMS signing scopes
[[ SB-11: replace with "ARC MUST be the last signer of the message; [[ See issue 14 [6] for critique of this section ]]
otherwise it cannot be validated on receipt." in the signer actions
section. KA: Concern that this still does not address the risk of
DKIM-Signatures covering ARC chains. This does not seem like it fits
in this section but it needs to go somewhere. ]]
DKIM-Signatures SHOULD never sign any ARC header fields. DKIM-Signatures SHOULD never sign any ARC header fields.
[[ KA: Response to Dave's concern: If DKIM covers ARC and ARC covers 6.2. Assessing Chain Validity Violations
DKIM, which comes first? The chicken or the egg? I'm open to
alternate ways to phrase this without opening the "modifying the DKIM
spec" can of worms. ]]
8.2. Assessing Chain Validity Violations
[[ SB-11: move to protocol elements
KA: This seems a bit banal. I suspect that what receivers want is a [[ Issue 15 [7] ]]
section on using ARC to override DMARC failures. Would that be to
brazen to insert here instead? Or do we relegate that to the
[ARC-USAGE] doc? ]]
Email transit can produce broken signatures for a wide variety of Email transit can produce broken signatures for a wide variety of
benign reasons. This includes possibly breaking one or more ARC benign reasons. This includes possibly breaking one or more ARC
signatures. Therefore, receivers need to be wary of ascribing motive signatures. Therefore, receivers need to be wary of ascribing motive
to such breakage although patterns of common behaviour may provide to such breakage although patterns of common behaviour may provide
some basis for adjusting local policy decisions. some basis for adjusting local policy decisions.
ARC does not attempt to protect an entire message. There are various ARC does not attempt to protect an entire message. There are various
ways that a message can still be problematic, in spite of having a ways that a message can still be problematic, in spite of having a
valid ARC chain. Consequently, all normal, content-based analysis valid ARC chain. Consequently, all normal, content-based analysis
SHOULD still be performed on any message having a valid chain of ARC SHOULD still be performed on any message having a valid chain of ARC
header sets. header sets.
9. Recording and Reporting the Results of ARC Evaluation 7. Recording and Reporting the Results of ARC Evaluation
The evaluation of an ARC chain provides information which will be The evaluation of an ARC chain provides information which will be
useful to both the receiver (or intermediary) and to the initial useful to both the receiver (or intermediary) and to the initial
sender of the message. This information should be preserved and sender of the message. This information should be preserved and
reported as follows. reported as follows.
9.1. Information from an ARC Evaluation 7.1. Information from an ARC Evaluation
The evaluation of an ARC chain produces a list of domain names for The evaluation of an ARC chain produces a list of domain names for
participating intermediaries which handled the message, to wit: participating intermediaries which handled the message, to wit:
o A list of the "d=" domains found in the validated ARC-Seal header o A list of the "d=" domains found in the validated ARC-Seal header
fields fields
o The "d=" domain found in the most recent (highest instance number) o The "d=" domain found in the most recent (highest instance number)
AMS header field (since that is the only one necessarily AMS header field (since that is the only one necessarily
validated) validated)
In the case of a failed chain, only the terminal ARC set is covered In the case of a failed chain, only the terminal ARC set is covered
by the ARC-Seal so the reporting is limited to the findings in that by the ARC-Seal so the reporting is limited to the findings in that
terminal ARC set. terminal ARC set.
9.2. Recording (local) ARC Evaluation Results 7.2. Recording (local) ARC Evaluation Results
Receivers MAY add an "arc=[pass|fail|policy]" method annotation into Receivers MAY add an "arc=[pass|fail|policy]" method annotation into
a locally-affixed Authentication-Results [RFC7601] header field along a locally-affixed Authentication-Results [RFC7601] header field along
with any salient comment(s). with any salient comment(s).
Details of the ARC chain which was evaluated should be included in Details of the ARC chain which was evaluated should be included in
the Authentication-Results and AAR headers per Section Section 5.2.1. the Authentication-Results and AAR headers per Section Section 4.1.
9.3. DMARC Reporting of ARC Findings - Interim 7.3. DMARC Reporting of ARC Findings - Interim
[[ Note: Discussion on the IETF DMARC-WG list has indicated some [[ Note: Move to separate document? [8] (see the additional fields
interest in more substantial reporting for analytic purposes. To specified in Section 4.1) ]]
support that effort, the following guidance is provided only as an
interim, minimal data set. A more complete reporting construct will
be specified in a related spec - TBD. (see the additional fields
specified in Section 5.2.1) ]]
Receivers SHOULD indicate situations in which ARC evaluation Receivers SHOULD indicate situations in which ARC evaluation
influenced the results of their local policy determination. DMARC influenced the results of their local policy determination. DMARC
reporting of ARC-informed decisions can be accomplished by adding a reporting of ARC-informed decisions can be accomplished by adding a
local_policy comment explanation containing the list of data local_policy comment explanation containing the list of data
discovered in the ARC evaluation (Section 9.1 and Section 5.2.1): discovered in the ARC evaluation (Section 7.1 and Section 4.1):
<policy_evaluated> <policy_evaluated>
<disposition>delivered</disposition> <disposition>delivered</disposition>
<dkim>fail</dkim> <dkim>fail</dkim>
<spf>fail <comment>source.ip=10.0.0.1</comment></spf> <spf>fail <comment>source.ip=10.0.0.1</comment></spf>
<reason> <reason>
<type>local_policy</type> <type>local_policy</type>
<comment>arc=pass ams[2].d=d2.example ams[2].s=s1 as[2].d=d2.example <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</comment> as[2].s=s2 as[1].d=d1.example as[1].s=s3</comment>
</reason> </reason>
skipping to change at page 19, line 8 skipping to change at page 19, line 25
In the suggested sample, d2.example is the sealing domain for ARC[2] In the suggested sample, d2.example is the sealing domain for ARC[2]
and d1.example is the sealing domain for ARC[1]. and d1.example is the sealing domain for ARC[1].
Mediators SHOULD generate DMARC reports on messages which transit Mediators SHOULD generate DMARC reports on messages which transit
their system just like any other message which they receive. This their system just like any other message which they receive. This
will result in multiple reports for each mediated message as they will result in multiple reports for each mediated message as they
transit the series of handlers. DMARC report consumers should be transit the series of handlers. DMARC report consumers should be
aware of this behaviour and make the necessary accommodations. aware of this behaviour and make the necessary accommodations.
10. Supporting Alternate Signing Algorithms 8. Supporting Alternate Signing Algorithms
This section has been moved to [ARC-MULTI] This section has been moved to [ARC-MULTI]
11. Privacy Considerations 9. Privacy Considerations
The ARC chain provides a verifiable record of the handlers for a The ARC chain provides a verifiable record of the handlers for a
message. Anonymous remailers will probably not find this compatible message. Anonymous remailers will probably not find this compatible
with their operating goals. with their operating goals.
12. IANA Considerations 10. IANA Considerations
This specification adds three new header fields as defined below. This specification adds three new header fields as defined below.
12.1. Authentication-Results Method Registry Update 10.1. Authentication-Results Method Registry Update
This draft adds one item to the IANA "Email Authentication Methods" This draft adds one item to the IANA "Email Authentication Methods"
registry: registry:
o Method : arc o Method : arc
Defined: [I-D.ARC] Defined: [I-D.ARC]
ptype: header ptype: header
Property: chain evaluation result Property: chain evaluation result
Value: chain evaluation result status (see Section 5.4) Value: chain evaluation result status (see Section 3.4)
Status: active Status: active
Version: 1 Version: 1
o Method : dkim o Method : dkim
Defined: [I-D.ARC] Defined: [I-D.ARC]
ptype: header ptype: header
skipping to change at page 20, line 35 skipping to change at page 21, line 5
ptype: header ptype: header
Property: oldest-pass Property: oldest-pass
Value: the oldest instance with a still validating AMS signature Value: the oldest instance with a still validating AMS signature
Status: active Status: active
Version: 1 Version: 1
12.2. Definitions of the ARC header fields 10.2. Definitions of the ARC header fields
This specification adds three new header fields to the "Permanent This specification adds three new header fields to the "Permanent
Message Header Field Registry", as follows: Message Header Field Registry", as follows:
o Header field name: ARC-Seal o Header field name: ARC-Seal
Applicable protocol: mail Applicable protocol: mail
Status: draft Status: draft
skipping to change at page 21, line 29 skipping to change at page 21, line 46
Applicable protocol: mail Applicable protocol: mail
Status: standard Status: standard
Author/Change controller: IETF Author/Change controller: IETF
Specification document(s): [I-D.ARC] Specification document(s): [I-D.ARC]
Related information: [RFC7601] Related information: [RFC7601]
13. Security Considerations 11. Security Considerations
The Security Considerations of [RFC6376] and [RFC7601] apply directly The Security Considerations of [RFC6376] and [RFC7601] apply directly
to this specification. to this specification.
13.1. Header Size 11.1. Header Size
Inclusion of ARC sets in the header of emails may cause problems for Inclusion of ARC sets in the header of emails may cause problems for
some older or more constrained MTAs if they are unable to accept the some older or more constrained MTAs if they are unable to accept the
greater size of the header. greater size of the header.
13.2. DNS Operations 11.2. DNS Operations
Operators who receive a message bearing N ARC sets have to complete Operators who receive a message bearing N ARC sets have to complete
up to N+1 DNS queries to evaluate the chain (barring DNS redirection up to N+1 DNS queries to evaluate the chain (barring DNS redirection
mechanisms which can increase the lookups for a given target value). mechanisms which can increase the lookups for a given target value).
This has at least two effects: This has at least two effects:
1. An attacker can send a message to an ARC partipant with a 1. An attacker can send a message to an ARC partipant 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.
2. DKIM only does one DNS check per signature, while this one can do 2. DKIM only does one DNS check per signature, while this one can do
many (per chain). Absent caching, slow DNS responses can cause many (per chain). Absent caching, slow DNS responses can cause
SMTP timeouts; and backlogged delivery queues on mediating SMTP timeouts; and backlogged delivery queues on mediating
systems. This could be exploited as a DoS attack. systems. This could be exploited as a DoS attack.
13.3. Message Content Suspicion 11.3. Message Content Suspicion
Recipients are cautioned to treat messages bearing ARC sets with the Recipients are cautioned to treat messages bearing ARC sets with the
same suspicion that they apply to all other email messages. This same suspicion that they apply to all other email messages. This
includes appropriate content scanning and other checks for includes appropriate content scanning and other checks for
potentially malicious content. The handlers which are identified potentially malicious content. The handlers which are identified
within the ARC chain may be used to provide input to local policy within the ARC chain may be used to provide input to local policy
engines in cases where DMARC validation fails (due to mediation engines in cases where DMARC validation fails (due to mediation
impacting SPF attribution, DKIM validity or alignment). impacting SPF attribution, DKIM validity or alignment).
Note that a passing ARC chain may not adequately mean that the Note that a passing ARC chain may not adequately mean that the
message is safe because: message is safe because:
1. You have to trust all signatories; and 1. You have to trust all signatories; and
2. Even trusted systems may have become compromised or may not 2. Even trusted systems may have become compromised or may not
properly authenticate messages, so even with a chain of trusted properly authenticate messages, so even with a chain of trusted
participants, the message might still never have authenticated in participants, the message might still never have authenticated in
the first place (which is why you have the AAR to inspect) or the first place (which is why you have the AAR to inspect) or
could have been subject to unintended modifications. could have been subject to unintended modifications.
14. Evaluating the Efficacy of the ARC Protocol 12. Evaluating the Efficacy of the ARC Protocol
The ARC protocol is designed to mitigate some of the most common The ARC protocol is designed to mitigate some of the most common
failure conditions for email which transits intermediary handlers en failure conditions for email which transits intermediary handlers en
route to the final recipient. Some of these problems have happened route to the final recipient. Some of these problems have happened
due to the adoption of the DMARC protocol [RFC7489] and are listed in due to the adoption of the DMARC protocol [RFC7489] and are listed in
[RFC6377] and [RFC7960]. [RFC6377] and [RFC7960].
As the ARC protocol becomes standardized and implemented amongst As the ARC protocol becomes standardized and implemented amongst
intermediary handlers, the following aspects should be evaluated in intermediary handlers, the following aspects should be evaluated in
order to determine the success of the protocol in accomplishing the order to determine the success of the protocol in accomplishing the
intended benefits. intended benefits.
NOTE: Terminology within this section does NOT follow [RFC2119] NOTE: Terminology within this section does NOT follow [RFC2119]
interpretation. This section represents the current thoughts of the interpretation. This section represents the current thoughts of the
working group regarding unanswered questions related to the protocol. working group regarding unanswered questions related to the protocol.
Wider deployment will inform these topics and probably expand them. Wider deployment will inform these topics and probably expand them.
14.1. Success Consideration 12.1. Success Consideration
Currently, many receivers have heuristically determined overrides in Currently, many receivers have heuristically determined overrides in
order to rescue mail from intermediary-caused failures. Many of order to rescue mail from intermediary-caused failures. Many of
those overrides rely on inferrence rather than direct evidence. those overrides rely on inferrence rather than direct evidence.
ARC will be a success if, for ARC sealed messages, receivers are able ARC will be a success if, for ARC sealed messages, receivers are able
to implment ARC-based algorithmic decisions based on the direct to implment ARC-based algorithmic decisions based on the direct
evidence found within the ARC chain. This is especially relevant for evidence found within the ARC chain. This is especially relevant for
DMARC processing when the DKIM d= value is aligned with the DMARC processing when the DKIM d= value is aligned with the
rfc5322.From author domain. rfc5322.From author domain.
14.2. Failure Considerations 12.2. Failure Considerations
The intent of ARC is to be at most value-add and at worst benign. If The intent of ARC is to be at most value-add and at worst benign. If
ARC opens up significant new vectors for abuse (see Section 13) then ARC opens up significant new vectors for abuse (see Section 11) then
this protocol will be a failure. Note that weaknesses inherent in this protocol will be a failure. Note that weaknesses inherent in
the mail protocols ARC is built upon (such as DKIM replay attacks and 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 other known issues) are not new vectors which can be attributed to
this specification. this specification.
14.3. Open Questions 12.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, wide-spread
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.
14.3.1. Value of the ARC-Seal (AS) Header 12.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.
14.3.2. DNS Overhead 12.3.2. DNS Overhead
Longer ARC chains will require more queries to retrieve the keys for Longer ARC chains will require more queries to retrieve the keys for
validating the chain. While this is not believed to be a security validating the chain. While this is not believed to be a security
issue (see Section 13.2), it is unclear how much overhead will truly issue (see Section 11.2), it is unclear how much overhead will truly
be added. This is similar to some of the initial processing and be added. This is similar to some of the initial processing and
query load concerns which were debated at the time of the DKIM query load concerns which were debated at the time of the DKIM
specification development. 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 ARC chains along with the the
DNS impact of processing ARC chains. DNS impact of processing ARC chains.
14.3.3. Distinguishing Valuable from Worthless Trace Information 12.3.3. Distinguishing Valuable from Worthless Trace Information
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 ARC seals but
doesn't do its own initial DMARC enforcement, a Final Receiver with doesn't do its own initial DMARC enforcement, a Final Receiver with
this knowledge could make a delivery decision based upon the this knowledge could make a delivery decision based upon the
authentication information it sees in the corresponding AAR header. 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. It would be beneficial to identify
skipping to change at page 24, line 36 skipping to change at page 25, line 7
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 intentionly proprietary or confidential Since many such systems are intentionly 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.
15. Implementation Status 13. Implementation Status
[[ Note: For minimizing section number references when the RFC editor
removes this section, it has been moved to be the last section of the
document before the Appendicies. ]]
[[ 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
skipping to change at page 25, line 16 skipping to change at page 25, line 32
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 seventh
interoperability test event which was held on 2017-07-15 & 16 at interoperability test event which was held on 2017-07-15 & 16 at
IETF99. 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 December 2017.
15.1. GMail test reflector and incoming validation 13.1. GMail test reflector and incoming validation
Organization: Google Organization: Google
Description: Internal production implementation with both debug Description: Internal production implementation with both debug
analysis and validating + sealing pass-through function analysis and validating + sealing pass-through function
Status of Operation: Production - Incoming Validation Status of Operation: Production - Incoming Validation
Coverage: Full spec implemented as of [ARC-DRAFT-06] Coverage: Full spec implemented as of [ARC-DRAFT-06]
Licensing: Proprietary - Internal only Licensing: Proprietary - Internal only
Implementation Notes: 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. 2017-07-15.
Contact Info: arc-discuss@dmarc.org [1] Contact Info: arc-discuss@dmarc.org [9]
15.2. AOL test reflector and internal tagging 13.2. AOL test reflector and internal tagging
Organization: AOL Organization: AOL
Description: Internal prototype implementation with both debug Description: Internal prototype implementation with both debug
analysis and validating + sealing pass-through function analysis and validating + sealing pass-through function
Status of Operation: Beta Status of Operation: Beta
Coverage: ARC chain validity status checking is operational, but only Coverage: ARC chain validity status checking is operational, but only
applied to email addresses enrolled in the test program. This system applied to email addresses enrolled in the test program. This system
conforms to [ARC-DRAFT-06] conforms to [ARC-DRAFT-06]
Licensing: Proprietary - Internal only Licensing: Proprietary - Internal only
Implementation Notes: 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 [2] Contact Info: arc-discuss@dmarc.org [10]
15.3. dkimpy 13.3. dkimpy
Organization: dkimpy developers/Scott Kitterman Organization: dkimpy developers/Scott Kitterman
Description: Python DKIM package Description: Python DKIM package
Status of Operation: Production Status of Operation: Production
Coverage: 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] (https://github.com/ValiMail/arc_test_suite) with both [ARC-TEST] arc_test_suite [11] with both python and python3.
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
15.4. OpenARC 13.4. OpenARC
Organization: TDP/Murray Kucherawy Organization: TDP/Murray Kucherawy
Description: Implemention of milter functionality related to the Description: Implemention of milter functionality related to the
OpenDKIM and OpenDMARC packages OpenDKIM and OpenDMARC packages
Status of Operation: Beta Status of Operation: Beta
Coverage: Built to support [ARC-DRAFT-10] 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.
skipping to change at page 27, line 8 skipping to change at page 27, line 23
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 January 2018.)
Contact Info: arc-discuss@dmarc.org [3] Contact Info: arc-discuss@dmarc.org [12]
15.5. Mailman 3.2 patch 13.5. Mailman 3.2 patch
Organization: Mailman development team Organization: Mailman development team
Description: Integrated ARC capabilities within the Mailman 3.2 Description: Integrated ARC capabilities within the Mailman 3.2
package package
Status of Operation: Patch submitted Status of Operation: Patch submitted
Coverage: Based on OpenARC Coverage: Based on OpenARC
Licensing: Same as mailman package - GPL Licensing: Same as mailman package - GPL
Implementation Notes: Implementation Notes:
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
15.6. Copernica/MailerQ web-based validation 13.6. Copernica/MailerQ web-based validation
Organization: Copernica Organization: Copernica
Description: Web-based validation of ARC-signed messages Description: Web-based validation of ARC-signed messages
Status of Operation: Beta Status of Operation: Beta
Coverage: Built to support [ARC-DRAFT-05] Coverage: Built to support [ARC-DRAFT-05]
Licensing: On-line usage only Licensing: On-line usage only
Implementation Notes: Implementation Notes:
o Released 2016-10-24 o Released 2016-10-24
skipping to change at page 28, line 10 skipping to change at page 28, line 25
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/
15.7. Rspamd 13.7. Rspamd
Organization: Rspamd community Organization: Rspamd community
Description: ARC signing and verification module Description: ARC signing and verification module
Status of Operation: Production, though deployment usage is unknown Status of Operation: Production, though deployment usage is unknown
Coverage: Built to support [ARC-DRAFT-06] Coverage: Built to support [ARC-DRAFT-06]
Licensing: Open source Licensing: Open source
skipping to change at page 28, line 33 skipping to change at page 29, line 5
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
15.8. PERL MAIL::DKIM module 13.8. PERL MAIL::DKIM module
Organization: FastMail Organization: FastMail
Description: Email domain authentication (sign and/or verify) module, Description: Email domain authentication (sign and/or verify) module,
previously included SPF / DKIM / DMARC, now has ARC added previously included SPF / DKIM / DMARC, now has ARC added
Status of Operation: Production, deployment usage unknown Status of Operation: Production, deployment usage unknown
Coverage: Built to support [ARC-DRAFT-10] Coverage: Built to support [ARC-DRAFT-10]
Licensing: Open Source Licensing: Open Source
Implementation Notes: 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/
15.9. PERL Mail::Milter::Authentication module 13.9. PERL Mail::Milter::Authentication module
Organization: FastMail Organization: FastMail
Description: Email domain authentication milter, uses MAIL::DKIM (see Description: Email domain authentication milter, uses MAIL::DKIM (see
above) above)
Status of Operation: Intial validation completed during IETF99 Status of Operation: Intial validation completed during IETF99
hackathon with some follow-on work during the week hackathon with some follow-on work during the week
Coverage: Built to support [I-D.ARC] Coverage: Built to support [I-D.ARC]
skipping to change at page 29, line 30 skipping to change at page 30, line 5
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
15.10. Sympa List Manager 13.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 Status of Operation: Work in progress
Coverage: unknown Coverage: unknown
Licensing: open source Licensing: open source
Implementation Notes: 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
15.11. Oracle Messaging Server 13.11. Oracle Messaging Server
Organization: Oracle Organization: Oracle
Description: Description:
Status of Operation: Intial development work during IETF99 hackathon. Status of Operation: Intial development work during IETF99 hackathon.
Status since then unknown. Status since then unknown.
Coverage: Built to support [ARC-DRAFT-06] Coverage: Built to support [ARC-DRAFT-06]
Licensing: Unknown Licensing: Unknown
Implementation Notes: Implementation Notes:
o Status since the work done in July 2017 is unknown. o 2018-01: Protocol handling components are completed, but crypto is
not yet functional.
Contact Info: Contact Info: Chris Newman
15.12. MessageSystems Momentum 13.12. MessageSystems Momentum
Organization: MessageSystems/SparkPost Organization: MessageSystems/SparkPost
Description: OpenARC integration into the LUA-enabled Momentum Description: OpenARC integration into the LUA-enabled Momentum
processing space processing space
Status of Operation: Beta Status of Operation: Beta
Coverage: Built to support [ARC-DRAFT-10] Coverage: Built to support [ARC-DRAFT-10]
Licensing: Unknown Licensing: Unknown
Implementation Notes: Implementation Notes:
o Initial deployments for validation expected in early 2018. o Initial deployments for validation expected in early 2018.
Contact Info: Contact Info:
skipping to change at page 30, line 43 skipping to change at page 31, line 14
Coverage: Built to support [ARC-DRAFT-10] Coverage: Built to support [ARC-DRAFT-10]
Licensing: Unknown Licensing: Unknown
Implementation Notes: Implementation Notes:
o Initial deployments for validation expected in early 2018. o Initial deployments for validation expected in early 2018.
Contact Info: Contact Info:
16. References 14. References
16.1. Normative References
[RFC1345] Simonsen, K., "Character Mnemonics and Character Sets", 14.1. Normative References
RFC 1345, DOI 10.17487/RFC1345, June 1992,
<https://www.rfc-editor.org/info/rfc1345>.
[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>.
[RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and
Functions", RFC 2142, DOI 10.17487/RFC2142, May 1997,
<https://www.rfc-editor.org/info/rfc2142>.
[RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS
Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999,
<https://www.rfc-editor.org/info/rfc2606>.
[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>.
[RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys
Identified Mail (DKIM)", RFC 4686, DOI 10.17487/RFC4686,
September 2006, <https://www.rfc-editor.org/info/rfc4686>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<https://www.rfc-editor.org/info/rfc5226>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
DOI 10.17487/RFC5321, October 2008,
<https://www.rfc-editor.org/info/rfc5321>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>.
[RFC5585] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys
Identified Mail (DKIM) Service Overview", RFC 5585,
DOI 10.17487/RFC5585, July 2009,
<https://www.rfc-editor.org/info/rfc5585>.
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
DOI 10.17487/RFC5598, July 2009, DOI 10.17487/RFC5598, July 2009,
<https://www.rfc-editor.org/info/rfc5598>. <https://www.rfc-editor.org/info/rfc5598>.
[RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker,
"DomainKeys Identified Mail (DKIM) Development,
Deployment, and Operations", RFC 5863,
DOI 10.17487/RFC5863, May 2010,
<https://www.rfc-editor.org/info/rfc5863>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76, "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011, RFC 6376, DOI 10.17487/RFC6376, September 2011,
<https://www.rfc-editor.org/info/rfc6376>. <https://www.rfc-editor.org/info/rfc6376>.
[RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and
Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377, Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377,
September 2011, <https://www.rfc-editor.org/info/rfc6377>. September 2011, <https://www.rfc-editor.org/info/rfc6377>.
[RFC6651] Kucherawy, M., "Extensions to DomainKeys Identified Mail
(DKIM) for Failure Reporting", RFC 6651,
DOI 10.17487/RFC6651, June 2012,
<https://www.rfc-editor.org/info/rfc6651>.
[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>.
[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>.
16.2. Informative References [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
14.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] [ARC-DRAFT-06]
Andersen, K., "Authenticated Received Chain (ARC) Protocol Andersen, K., "Authenticated Received Chain (ARC) Protocol
(I-D-06)", n.d., <https://tools.ietf.org/html/ (I-D-06)", n.d., <https://tools.ietf.org/html/
draft-ietf-dmarc-arc-protocol-06>. draft-ietf-dmarc-arc-protocol-06>.
skipping to change at page 33, line 25 skipping to change at page 33, line 5
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", December 2017,
<https://tools.ietf.org/html/ <https://tools.ietf.org/html/
draft-ietf-dmarc-arc-usage-01>. draft-ietf-dmarc-arc-usage-01>.
[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]
Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", February 2018,
<https://datatracker.ietf.org/doc/
draft-ietf-dmarc-rfc7601bis/>.
[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", RFC 6982, Code: The Implementation Status Section", RFC 6982,
DOI 10.17487/RFC6982, July 2013, DOI 10.17487/RFC6982, July 2013,
<https://www.rfc-editor.org/info/rfc6982>. <https://www.rfc-editor.org/info/rfc6982>.
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
Message Authentication, Reporting, and Conformance Message Authentication, Reporting, and Conformance
(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
<https://www.rfc-editor.org/info/rfc7489>. <https://www.rfc-editor.org/info/rfc7489>.
[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>.
16.3. URIs 14.3. URIs
[1] mailto:arc-discuss@dmarc.org [1] https://trac.ietf.org/trac/dmarc/ticket/10
[2] mailto:arc-discuss@dmarc.org [2] https://datatracker.ietf.org/wg/dcrup/about/
[3] mailto:arc-discuss@dmarc.org [3] https://trac.ietf.org/trac/dmarc/ticket/11
[4] mailto:dmarc@ietf.org [4] https://trac.ietf.org/trac/dmarc/ticket/12
[5] mailto:arc-discuss@dmarc.org [5] https://trac.ietf.org/trac/dmarc/ticket/13
[6] https://trac.ietf.org/trac/dmarc/ticket/14
[7] https://trac.ietf.org/trac/dmarc/ticket/15
[8] https://trac.ietf.org/trac/dmarc/ticket/16
[9] mailto:arc-discuss@dmarc.org
[10] mailto:arc-discuss@dmarc.org
[11] https://github.com/ValiMail/arc_test_suite
[12] mailto:arc-discuss@dmarc.org
[13] https://trac.ietf.org/trac/dmarc/ticket/17
[14] mailto:dmarc@ietf.org
[15] mailto:arc-discuss@dmarc.org
Appendix A. Appendix A - Design Requirements Appendix A. Appendix A - Design Requirements
(This section is re-inserted for background information from (This section is re-inserted for background information from
[ARC-DRAFT-06] and earlier versions.) [ARC-DRAFT-06] and earlier versions.)
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.
skipping to change at page 34, line 39 skipping to change at page 34, line 45
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. ]] future draft. Issue 17 [13] ]]
(Obsolete but retained for illustrative purposes) (Obsolete but retained for illustrative purposes)
B.1. Example 1: Simple mailing list B.1. Example 1: Simple mailing list
B.1.1. Here's the message as it exits the Origin: B.1.1. Here's the message as it exits the Origin:
Return-Path: <jqd@d1.example> Return-Path: <jqd@d1.example>
Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
(authenticated bits=0) (authenticated bits=0)
skipping to change at page 54, line 8 skipping to change at page 54, line 8
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 [4]. Earlier discussions can be found at arc- dmarc@ietf.org [14]. Earlier discussions can be found at arc-
discuss@dmarc.org [5]. discuss@dmarc.org [15].
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
 End of changes. 150 change blocks. 
387 lines changed or deleted 381 lines changed or added

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