--- 1/draft-ietf-dmarc-arc-protocol-13.txt 2018-04-23 20:13:11.926487526 -0700
+++ 2/draft-ietf-dmarc-arc-protocol-14.txt 2018-04-23 20:13:12.018489743 -0700
@@ -1,201 +1,198 @@
DMARC Working Group K. Andersen
Internet-Draft LinkedIn
Intended status: Experimental B. Long, Ed.
-Expires: September 22, 2018 Google
+Expires: October 25, 2018 Google
S. Jones, Ed.
TDP
S. Blank, Ed.
- ValiMail
+ Valimail
M. Kucherawy, Ed.
TDP
- March 21, 2018
+ April 23, 2018
Authenticated Received Chain (ARC) Protocol
- draft-ietf-dmarc-arc-protocol-13
+ draft-ietf-dmarc-arc-protocol-14
Abstract
The Authenticated Received Chain (ARC) protocol creates a mechanism
whereby a series of handlers of an email message can conduct
authentication of the email message as it passes among them on the
way to its destination, and create an attached, authenticated record
of the status at each step along the handling path, for use by the
final recipient in making choices about the disposition of the
message. Changes in the message that might break existing
- authentication mechanisms can be identified through the ARC set of
+ authentication mechanisms can be identified through the ARC Set of
header fields.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
- This Internet-Draft will expire on September 22, 2018.
+ This Internet-Draft will expire on October 25, 2018.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
- 1.1.1. High Level Summary . . . . . . . . . . . . . . . . . 5
- 1.1.2. Technical Summary . . . . . . . . . . . . . . . . . . 7
- 1.2. Definitions and Terminology . . . . . . . . . . . . . . . 7
- 1.2.1. Terms defined and used in this document . . . . . . . 7
- 1.2.2. Referenced Definitions . . . . . . . . . . . . . . . 8
- 2. Protocol Elements and Features . . . . . . . . . . . . . . . 8
- 2.1. Features of the ARC Protocol . . . . . . . . . . . . . . 9
- 2.1.1. Chain of Custody . . . . . . . . . . . . . . . . . . 9
- 2.1.2. Optional Participation . . . . . . . . . . . . . . . 10
- 2.1.3. Only one ARC Chain (One Chain to Rule Them All) . . . 10
- 2.1.4. All Failures are Permanent . . . . . . . . . . . . . 10
- 2.1.5. Benign nature of an ARC Set . . . . . . . . . . . . . 10
- 2.1.6. Key Management . . . . . . . . . . . . . . . . . . . 11
- 2.1.7. Trace Information . . . . . . . . . . . . . . . . . . 11
- 2.1.8. Instance Tags . . . . . . . . . . . . . . . . . . . . 11
- 2.1.9. Chain Validation Status . . . . . . . . . . . . . . . 11
+ 1.1. General Concepts . . . . . . . . . . . . . . . . . . . . 5
+ 1.2. Differences Between ARC and DKIM . . . . . . . . . . . . 5
+ 1.3. Definitions and Terminology . . . . . . . . . . . . . . . 6
+ 1.3.1. Terms defined and used in this document . . . . . . . 6
+ 1.3.2. Referenced Definitions . . . . . . . . . . . . . . . 7
+ 2. Protocol Elements and Features . . . . . . . . . . . . . . . 7
+ 2.1. The "ARC Set" of Header Fields . . . . . . . . . . . . . 8
+ 2.1.1. Instance Tags . . . . . . . . . . . . . . . . . . . . 9
+ 2.2. Chain Validation Status . . . . . . . . . . . . . . . . . 9
+ 2.3. Trace Information . . . . . . . . . . . . . . . . . . . . 9
+ 2.4. Key Management . . . . . . . . . . . . . . . . . . . . . 9
+ 2.5. All Failures are Permanent . . . . . . . . . . . . . . . 10
+ 2.6. Chain of Custody . . . . . . . . . . . . . . . . . . . . 10
+ 2.7. Optional Participation . . . . . . . . . . . . . . . . . 10
+ 2.8. Broad Responsibility to Seal . . . . . . . . . . . . . . 10
+ 2.9. One Chain to Rule Them All . . . . . . . . . . . . . . . 11
+ 2.10. Sealing is Always Safe . . . . . . . . . . . . . . . . . 11
3. The ARC Header Fields . . . . . . . . . . . . . . . . . . . . 11
3.1. Instance ('i=') Tag . . . . . . . . . . . . . . . . . . . 11
- 3.1.1. Valid Range for Instance Tags . . . . . . . . . . . . 12
3.2. ARC-Authentication-Results (AAR) . . . . . . . . . . . . 12
- 3.3. ARC-Message-Signature (AMS) . . . . . . . . . . . . . . . 13
+ 3.3. ARC-Message-Signature (AMS) . . . . . . . . . . . . . . . 12
3.4. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . . . 13
- 3.4.1. The 'cv' Tag . . . . . . . . . . . . . . . . . . . . 14
- 3.4.2. Implicit Header Fields . . . . . . . . . . . . . . . 14
+ 3.4.1. Covered Header Fields . . . . . . . . . . . . . . . . 13
+ 3.4.2. The 'cv' Tag . . . . . . . . . . . . . . . . . . . . 14
4. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . 14
- 4.1. ARC Authentication-Results Information . . . . . . . . . 16
+ 4.1. Authentication-Results Information . . . . . . . . . . . 15
4.2. Handling DNS Problems While Validating ARC . . . . . . . 16
4.3. Responding to ARC Validity Violations During the SMTP
- Transaction . . . . . . . . . . . . . . . . . . . . . . . 17
-
- 5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . 17
+ Transaction . . . . . . . . . . . . . . . . . . . . . . . 16
+ 5. Sealer Actions . . . . . . . . . . . . . . . . . . . . . . . 16
5.1. Marking and Sealing "cv=fail" (Invalid) Chains . . . . . 17
- 6. Usage of ARC and Chain Validity . . . . . . . . . . . . . . . 18
- 6.1. Relationship between DKIM-Signature and AMS signing
- scopes . . . . . . . . . . . . . . . . . . . . . . . . . 18
- 6.2. Assessing Chain Validity Violations . . . . . . . . . . . 18
- 7. Recording and Reporting the Results of ARC Evaluation . . . . 18
- 7.1. Information from an ARC Evaluation . . . . . . . . . . . 18
- 7.2. Recording (local) ARC Evaluation Results . . . . . . . . 19
- 7.3. DMARC Reporting of ARC Findings - Interim . . . . . . . . 19
- 8. Supporting Alternate Signing Algorithms . . . . . . . . . . . 19
- 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20
- 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
- 10.1. Authentication-Results Method Registry Update . . . . . 20
- 10.2. Definitions of the ARC header fields . . . . . . . . . . 21
- 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22
- 11.1. Header Size . . . . . . . . . . . . . . . . . . . . . . 22
- 11.2. DNS Operations . . . . . . . . . . . . . . . . . . . . . 22
- 11.3. Message Content Suspicion . . . . . . . . . . . . . . . 22
- 12. Evaluating the Efficacy of the ARC Protocol . . . . . . . . . 23
- 12.1. Success Consideration . . . . . . . . . . . . . . . . . 23
- 12.2. Failure Considerations . . . . . . . . . . . . . . . . . 24
- 12.3. Open Questions . . . . . . . . . . . . . . . . . . . . . 24
- 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
- 13. Implementation Status . . . . . . . . . . . . . . . . . . . . 25
- 13.1. GMail test reflector and incoming validation . . . . . . 26
- 13.2. AOL test reflector and internal tagging . . . . . . . . 26
- 13.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 26
- 13.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . 27
- 13.5. Mailman 3.2 patch . . . . . . . . . . . . . . . . . . . 27
- 13.6. Copernica/MailerQ web-based validation . . . . . . . . . 28
- 13.7. Rspamd . . . . . . . . . . . . . . . . . . . . . . . . . 28
- 13.8. PERL MAIL::DKIM module . . . . . . . . . . . . . . . . . 29
- 13.9. PERL Mail::Milter::Authentication module . . . . . . . . 29
- 13.10. Sympa List Manager . . . . . . . . . . . . . . . . . . . 30
- 13.11. Oracle Messaging Server . . . . . . . . . . . . . . . . 30
- 13.12. MessageSystems Momentum . . . . . . . . . . . . . . . . 31
- 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
- 14.1. Normative References . . . . . . . . . . . . . . . . . . 31
- 14.2. Informative References . . . . . . . . . . . . . . . . . 32
- 14.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 33
- Appendix A. Appendix A - Design Requirements . . . . . . . . . . 34
- A.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 34
- A.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 35
- Appendix B. Appendix B - Example Usage . . . . . . . . . . . . . 35
- B.1. Example 1: Simple mailing list . . . . . . . . . . . . . 35
- 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.3. Example 1: Message received by Recipient . . . . . . 38
- B.2. Example 2: Mailing list to forwarded mailbox . . . . . . 39
- B.2.1. Here's the message as it exits the Origin: . . . . . 39
- B.2.2. Message is then received at example.org . . . . . . . 40
- B.2.3. Example 2: Message received by Recipient . . . . . . 44
- B.3. Example 3: Mailing list to forwarded mailbox with source 46
- B.3.1. Here's the message as it exits the Origin: . . . . . 46
- B.3.2. Message is then received at example.org . . . . . . . 47
- B.3.3. Example 3: Message received by Recipient . . . . . . 52
- Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 54
- Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 55
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55
+ 6. Recording and Reporting the Results of ARC Evaluation . . . . 17
+ 6.1. Information from an ARC Evaluation . . . . . . . . . . . 17
+ 6.2. Recording (local) ARC Evaluation Results . . . . . . . . 17
+ 6.3. DMARC Reporting of ARC Findings - Interim . . . . . . . . 18
+ 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18
+ 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
+ 8.1. Authentication-Results Method Registry Update . . . . . . 19
+ 8.2. Email Authentication Result Names Registry Update . . . . 19
+ 8.3. Definitions of the ARC header fields . . . . . . . . . . 19
+ 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
+ 9.1. Header Size . . . . . . . . . . . . . . . . . . . . . . . 20
+ 9.2. DNS Operations . . . . . . . . . . . . . . . . . . . . . 20
+ 9.3. Message Content Suspicion . . . . . . . . . . . . . . . . 21
+ 10. Evaluating the Efficacy of the ARC Protocol (Experimental
+ Considerations) . . . . . . . . . . . . . . . . . . . . . . . 21
+ 10.1. Success Consideration . . . . . . . . . . . . . . . . . 21
+ 10.2. Failure Considerations . . . . . . . . . . . . . . . . . 22
+ 10.3. Open Questions . . . . . . . . . . . . . . . . . . . . . 22
+ 10.3.1. Value of the ARC-Seal (AS) Header . . . . . . . . . 22
+ 10.3.2. DNS Overhead . . . . . . . . . . . . . . . . . . . . 22
+ 10.3.3. Distinguishing Valuable from Worthless Trace
+ Information . . . . . . . . . . . . . . . . . . . . 22
+ 11. Implementation Status . . . . . . . . . . . . . . . . . . . . 23
+ 11.1. GMail test reflector and incoming validation . . . . . . 24
+ 11.2. AOL test reflector and internal tagging . . . . . . . . 24
+ 11.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 24
+ 11.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . 25
+ 11.5. Mailman 3.2 patch . . . . . . . . . . . . . . . . . . . 25
+ 11.6. Copernica/MailerQ web-based validation . . . . . . . . . 25
+ 11.7. Rspamd . . . . . . . . . . . . . . . . . . . . . . . . . 26
+ 11.8. PERL MAIL::DKIM module . . . . . . . . . . . . . . . . . 26
+ 11.9. PERL Mail::Milter::Authentication module . . . . . . . . 27
+ 11.10. Sympa List Manager . . . . . . . . . . . . . . . . . . . 27
+ 11.11. Oracle Messaging Server . . . . . . . . . . . . . . . . 27
+ 11.12. MessageSystems Momentum and PowerMTA platforms . . . . . 28
+ 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
+ 12.1. Normative References . . . . . . . . . . . . . . . . . . 28
+ 12.2. Informative References . . . . . . . . . . . . . . . . . 29
+ 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 30
+ Appendix A. Appendix A - Design Requirements . . . . . . . . . . 31
+ A.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 31
+ A.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 31
+ Appendix B. Appendix B - Example Usage . . . . . . . . . . . . . 31
+ B.1. Example 1: Simple mailing list . . . . . . . . . . . . . 31
+ B.1.1. Here's the message as it exits the Origin: . . . . . 31
+ B.1.2. Message is then received at example.org . . . . . . . 32
+ B.1.3. Example 1: Message received by Recipient . . . . . . 34
+
+ B.2. Example 2: Mailing list to forwarded mailbox . . . . . . 35
+ B.2.1. Here's the message as it exits the Origin: . . . . . 35
+ B.2.2. Message is then received at example.org . . . . . . . 36
+ B.2.3. Example 2: Message received by Recipient . . . . . . 40
+ B.3. Example 3: Mailing list to forwarded mailbox with source 42
+ B.3.1. Here's the message as it exits the Origin: . . . . . 42
+ B.3.2. Message is then received at example.org . . . . . . . 43
+ B.3.3. Example 3: Message received by Recipient . . . . . . 48
+ Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 50
+ Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 51
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
1. Introduction
Modern email authentication techniques such as the Sender Policy
Framework (SPF) [RFC7208] and DomainKeys Identified Mail (DKIM)
[RFC6376] have become common. However, their end-to-end utility is
limited by the effects of intermediaries along the transmission path,
which either are not listed (for SPF) or which break digital
signatures (for DKIM). These issues are described in substantial
detail in those protocols' defining documents as well as in [RFC6377]
and [RFC7960].
Technologies that build upon the use of SPF and DKIM can reduce the
success of fraudulent email campaigns. To this end, Domain-based
- Mail Authentication, Reporting and Compliance (DMARC) [RFC7489],
- validates the domain of the RFC5322.From author header field.
- However its use along email transmission paths that have independent
+ Mail Authentication, Reporting and Conformance (DMARC) [RFC7489],
+ validates the domain of the RFC5322.From header field. However its
+ use along email transmission paths that have independent
intermediaries, such as some forwarders and essentially all mailing
list services, produces false positive rejections that are
problematic, both for the message authors, the intermediary
service(s), and for those they are interacting with.
- What is needed is a mechanism by which legitimate alteration of a
- message, which invalidates associated SPF and DKIM information, does
- not ultimately result in a rejection of an email message on delivery.
- Authenticated Receive Chain (ARC) builds upon DKIM mechanisms to
+ [RFC7960] documented the need for a mechanism which would survive
+ legitimate alteration of a message, in spite of breaking the
+ associated SPF and DKIM information so that the end receiver
+ system(s) can avoid those false positive rejections on delivery.
+ Authenticated Received Chain (ARC) builds upon DKIM mechanisms to
provide a sequence of signatures that provide a view of the handling
sequence for a message, especially the points where alterations of
the content might have occurred. Equipped with this more complete
information, the recipient system(s) can make a more informed
handling choice, reducing or eliminating the rejections that would
occur with the use of DKIM and/or SPF alone.
-1.1. Overview
+1.1. General Concepts
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
@@ -219,123 +216,89 @@
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.
+ accepts that assertion, it can accept the message for further
+ processing, rather than reject it, based on the additional
+ information that ARC has provided.
-1.1.1. High Level Summary
+1.2. Differences Between ARC and DKIM
In DKIM, every participating signing agent attaches a signature that
- is based on the some of the content of the message, local policy, and
- the domain name of the signing agent's Administrative Management
- Domain (ADMD). Any verifier can process such a signature; a verified
+ is based on some of the content of the message, local policy, and the
+ domain name of the signing agent's Administrative Management Domain
+ (ADMD). Any verifier can process such a signature; a verified
signature means that the domain referenced in the signature's "d="
parameter has some responsibility for handling the message. An
artifact of using digital signature technology for this means that
verification also ensures that the portion of the message that was
"covered" by the signature has not been altered since the signature
was applied. The signatures themselves are generally independent of
one another.
- In contrast, a validated ARC signature conveys the following pieces
- of information:
+ In contrast, a validated ARC Set conveys the following pieces of
+ information:
1. An assertion that, at the time that the intermediary ADMD
- processed the message, the various assertions (SPF, DKIM-
- Signature(s) and/or ARC sets) already attached to the message by
+ processed the message, the various assertions (such as SPF, DKIM-
+ Signature(s) and/or ARC Chain) already attached to the message by
other ADMDs were or were not valid;
2. As with DKIM, an assertion that, for a validated ARC signature,
the domain name in the signature takes some responsibility for
- handling of the message and that the covered content of message
- is unchanged since that signature was applied;
+ handling of the message and that the covered content of the
+ message is unchanged since that signature was applied;
3. A further assertion that binds the ARC evaluation results into
- the ARC chain sequence.
-
- The ARC protocol accomplishes this by adding an "ARC Set" of three
- new header fields to the message as follows:
-
- 1. ARC-Authentication-Results (referred to below as "AAR"):
- virtually identical in syntax to an Authentication-Results field
- [RFC7601], this field records the results of all message
- authentication checks done by the recording ADMD at the time the
- message arrived. Additional information is placed in this field
- compared to a standard Authentication-Results field in order to
- support a more complete DMARC report (see Section 3.2);
-
- 2. ARC-Message-Signature (referred to below as "AMS"): virtually
- identical in syntax to DKIM-Signature, this field contains the
- signature about the message header and body as they existed at
- the time of handling by the ADMD adding it (including any
- modifications made by the sealing ADMD); and
-
- 3. ARC-Seal (referred to below as "AS"): highly similar in structure
- and format to a DKIM-Signature, this field applies a digital
- signature that protects the integrity of all three of these new
- fields when they are added by an ADMD, plus all instances of
- these fields added by prior ADMDs.
-
- An ARC participant always adds all of these header fields before
- relaying a message to the next handling agent _en route_ to its
- destination. Moreover, as described 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 be preserved and the three
- related header fields can be processed as a set.
-
-1.1.2. Technical Summary
-
- [[ possibly including a diagram - this may not be needed any more ]]
+ the ARC Chain sequence.
-1.2. Definitions and Terminology
+1.3. Definitions and Terminology
This section defines terms used in the rest of the document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP14 ([RFC2119][RFC8174]).
Because many of the core concepts and definitions are found in
[RFC5598], readers should to be familiar with the contents of
[RFC5598], and in particular, the potential roles of intermediaries
in the delivery of email.
Syntax descriptions use Augmented BNF (ABNF) [RFC5234].
-1.2.1. Terms defined and used in this document
+1.3.1. Terms defined and used in this document
o "ARC-Authentication-Results" (AAR) - an ARC header field described
in Section 3.2.
o "ARC-Message-Signature" (AMS) - an ARC header field described in
Section 3.3.
o "ARC-Seal" (AS) - an ARC header field described in Section 3.4.
o "ARC Set" - A single group of the header fields introduced in
- Section 1.1 is called an "ARC Set".
+ Section 2.1 is called an "ARC Set".
o "ARC Chain" - the complete sequence of ARC Sets for a message.
The ARC Chain represents a "chain of custody" for the message,
- recording its authentication status at each ARC-compliant ADMD
+ recording its authentication status at each ARC-participating ADMD
that handled the message.
-1.2.2. Referenced Definitions
+1.3.2. Referenced Definitions
The following terms are defined in other RFCs. Those definitions can
be found as follows:
o ADMD - [RFC5598], Section 2.3
o MTA - [RFC5598], Section 4.3.2
o MSA - [RFC5598], Section 4.3.1
@@ -346,782 +309,736 @@
the formal definitions that are being reused in ARC, this document
only describes and specifies changes in syntax and semantics.
Language, syntax, and other details are imported from DKIM [RFC6376].
Specific references can be found below.
2. Protocol Elements and Features
As with other domain authentication technologies (such as SPF, DKIM,
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:
o all (participating) domains that claim responsibility for handling
(and possibly modifying) the email message in transit;
o trace information, including:
- * the [RFC7601] authentication results each participating ADMD
+ * the [RFC7601] Authentication-Results each participating ADMD
saw; and
* additional data needed to compile a DMARC report for the
sending domain.
- Given this information, a Final Receiver is able to make a more-
- informed local policy decision regarding message delivery to the end
- user in spite of an authentication failure.
+ Given this information, each receiver is able to make a more informed
+ local policy decision regarding message processing and, ultimately,
+ delivery to the end user in spite of authentication failure(s) and to
+ inform the message orgination system(s) through the DMARC report(s).
- Every participant in an ARC chain, except for the originating sender
+ Every participant in an ARC Chain, except for the originating sender
and Final Receiver, is both an ARC Validator (when receiving) and
- then an ARC Sealer (when sending a message onward). The validated
- chain status as determined at message receipt must be passed to the
- sealer function in order for sealing to occur properly; how this is
- done is considered ADMD-specific and an implementation detail.
+ then an ARC Sealer (when sending a message onward).
_INFORMATIONAL_: It is important to understand that validating and
then immediately sealing a message leaves no room for message
modification, and many early implementations of ARC did not initially
work because both operations were performed in a single pass over the
message.
-2.1. Features of the ARC Protocol
-
The following protocol features are functional parts and design
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 that the ARC Chain conveys this
information to a Final Receiver.
-2.1.1. Chain of Custody
+2.1. The "ARC Set" of Header Fields
- At a high level, an ARC chain represents a chain of custody of
+ Each "ARC Set" consists of the following three new header fields:
+
+ 1. ARC-Authentication-Results (referred to below as "AAR"):
+ virtually identical in syntax to an Authentication-Results field
+ [RFC7601], this field records the results of all message
+ authentication checks done by the recording ADMD at the time the
+ message arrived. Additional information is placed in this field
+ compared to a standard Authentication-Results field in order to
+ support a more complete DMARC report;
+
+ 2. ARC-Message-Signature (referred to below as "AMS"): virtually
+ identical in syntax to DKIM-Signature, this field contains the
+ signature about the message header and body as they existed at
+ the time of handling by the ADMD adding it (including any
+ modifications made by the sealing ADMD); and
+
+ 3. ARC-Seal (referred to below as "AS"): highly similar in structure
+ and format to a DKIM-Signature, this field applies a digital
+ signature that protects the integrity of all three of these new
+ fields when they are added by an ADMD, plus all instances of
+ these fields added by prior ADMDs.
+
+ An ARC participant always adds all of these header fields before
+ relaying a message to the next handling agent _en route_ to its
+ destination. Moreover, they each have an "instance number" that
+ increases with each ARC Set in the handling chain so that their
+ original order can be preserved and the three related header fields
+ can be processed as a set.
+
+2.1.1. Instance Tags
+
+ ARC includes an indicator in its header fields to show the order in
+ which the header fields comprising an ARC Chain were added, and the
+ specific members of each ARC Set. This is known as the "instance",
+ and the indicator is an "i=" tag/value. That is, the members of the
+ first ARC Set affixed to a message will all include "i=1". This is
+ described in detail in section Section 3.1.
+
+2.2. Chain Validation Status
+
+ ARC includes a mechanism which denotes the state of the ARC Chain at
+ each step. The "chain validation status" ("cv" tag/value) is used to
+ communicate the current chain status within the ARC Chain and also
+ through Authentication-Results and ARC-Authentication-Results stamps
+ as well as DMARC reporting.
+
+ The chain validation status has one of three possible values:
+
+ o none: There was no chain on the message when it arrived for
+ validation; typically occurs when the message arrives at a Message
+ Transfer Agent (MTA) or mediator from a Message Submission Agent
+ (MSA) or when any upstream handlers may not be participating in
+ ARC handling;
+
+ o fail: The message has a chain whose validation failed;
+
+ o pass: The message has a chain whose validation succeeded.
+
+2.3. Trace Information
+
+ ARC includes trace information encoded in the AAR. While section
+ Section 3.2 defines what information must be provided, sealing ADMDs
+ may provide additional information, and validating receivers may use
+ this trace information as they find it useful.
+
+2.4. Key Management
+
+ The public keys for ARC header fields follow the same requirements,
+ syntax and semantics as those for DKIM signatures, described in
+ Section 3.6 of [RFC6376]. ARC places no requirements on the
+ selectors and/or domains used for the ARC header field signatures.
+
+2.5. All Failures are Permanent
+
+ Because ARC Chains are transmitted across multiple intermediaries,
+ all errors, even temporary ones, become unrecoverable and are
+ considered permanent.
+
+ Any error validating or sealing a chain, for whatever reason, MUST
+ result in a "cv=fail" verdict as documented in Section 3.4.2.
+
+2.6. Chain of Custody
+
+ At a high level, an ARC Chain represents a chain of custody of
authentication and other trace information (AAR) related to a
message, signed by each handler of the message. Each link in the
chain (AMS) is designed to be brittle, insofar as it survives only
until the next modification of the message. However, the sequence of
intermediaries in the handling chain (AS) is designed to remain
intact over the entirety of the chain.
- The ARC chain can be conceptualized through an analogy with the chain
+ The ARC Chain can be conceptualized through an analogy with the chain
of custody for legal evidence. The material evidence itself is
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
evidence container (AAR) and signs for the evidence on a chain of
custody report form (AS). As with all analogies, this one should not
be taken to interpretive extremes, but primarily used as a conceptual
framework.
- An ARC chain that is valid and passing has the attributes listed
+ An ARC Chain that is valid and passing has the attributes listed
above in Section 2.
- Recipients of an ARC chain that is invalid or does not pass SHOULD
- NOT draw negative conclusions without a good understanding of the
- wider handling context. Until ARC usage is widespread,
- intermediaries will continue to modify messages without ARC seals.
- As with a failing DKIM signature ([RFC6376] Section-6.3), a failing
- 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
- Verifier actions. Ref issue 10 [1] ]]
-
-2.1.2. Optional Participation
+2.7. 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 handling the message
and modifications, if any, done by your ADMD to benefit message
delivery downstream. However, no ADMD is obligated to perform these
actions.
-2.1.3. Only one ARC Chain (One Chain to Rule Them All)
+2.8. Broad Responsibility to Seal
- A message can have only one ARC chain on it at a time (see
+ Any mediator ([RFC5598], section 5) that modifies a message may seal
+ its own changes. ARC is not solely intended for perimeter MTAs.
+
+2.9. One Chain to Rule Them All
+
+ A message can have only one ARC Chain on it at a time (see
Section 3.1). Once broken, the chain cannot be continued, as the
chain of custody is no longer valid and responsibility for the
message has been lost. For further discussion of this topic and the
designed restriction which prevents chain continuation or re-
establishment, see [ARC-USAGE].
-2.1.4. All Failures are Permanent
-
- Because ARC chains are transmitted across multiple intermediaries,
- all errors, even temporary ones, become unrecoverable and are
- considered permanent.
-
- Any error validating or sealing a chain, for whatever reason, MUST
- result in a "cv=fail" verdict.
+2.10. Sealing is Always Safe
-2.1.5. Benign nature of an ARC Set
+ Even when an ARC Chain is valid and passes, its value is limited to
+ very specific cases. An ARC Chain is specifically designed to
+ provide additional information to a receiver evaluating message
+ delivery in the context of an authentication failure and otherwise be
+ benign. Specifically:
- Even when an ARC chain is valid and passes, its value is limited to
- very specific cases. An ARC chain is specifically designed to
- provide value to a Final Receiver evaluating message delivery in the
- context of an authentication failure. An ARC chain in general, and
- each ARC set in particular, provide additional information, and
- otherwise is benign. Specifically:
+ o properly adding an ARC Set to a message does not damage or
+ invalidate an existing chain,
- o properly adding an ARC set to a message does not damage or
- invalidate an existing chain, and
+ o sealing a chain when you did not modify a message does not
+ negatively affect the chain, and
o validating a message exposes no new threat vectors (see
- Section 11).
+ Section 9).
_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.
For complex or nested ADMD relationships such as found in some hosted
mail solutions, this "inbound seal" can be used to facilitate
traversal of internal boundaries as well as properly conveying
incoming state to any egress MTAs that may need to assert a seal upon
exit from the ADMD. Since these internal relationships are highly
implementation dependent, this protocol definition can not usefully
explore such usage except to note that it is intentionally allowed
within the scope of this specification.
-2.1.6. Key Management
-
- The public keys for ARC header fields follow the same requirements,
- syntax and semantics as those for DKIM signatures, described in
- Section 3.6 of [RFC6376]. ARC places no requirements on the
- selectors and/or domains used for the ARC header field signatures.
-
-2.1.7. Trace Information
-
- ARC includes trace information encoded in the AAR. While section
- Section 3.2 defines what information must be provided, sealing ADMDs
- may provide additional information, and validating receivers may use
- or ignore this trace information as they wish.
-
-2.1.8. Instance Tags
-
- 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.
-
-2.1.9. Chain Validation Status
-
- 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.
-
3. The ARC Header Fields
3.1. Instance ('i=') Tag
- 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
- complies with the "tag-spec" ABNF found in Section 3.2 of [RFC6376].
- The tag-name is "i" and the value is the text representation of a
- positive integer, indicating the position in the ARC sequence this
- set occupies, where the first ARC set is numbered 1. In ABNF terms:
+ The header fields comprising a single ARC Set are identified by a
+ common "instance" tag value. The instance tag is a string in each
+ header field value that complies with the "tag-spec" ABNF found in
+ Section 3.2 of [RFC6376]. The tag-name is "i" and the value is the
+ text representation of a positive integer, indicating the position in
+ the ARC sequence this set occupies, where the first ARC Set is
+ numbered 1. In ABNF terms:
- instance = [FWS] %x69 [FWS] "=" [FWS] position [FWS] ";"
position = 1*2DIGIT ; 1 - 50
+ instance = [FWS] %x69 [FWS] "=" [FWS] position [FWS] ";"
- Valid ARC sets must have exactly one instance of each header field
- for a given position value and signing algorithm. (Initial
- development of ARC is only being done with a single allowed signing
- algorithm, but parallel work in the DCRUP working group [2] is
- expanding that. For handling multiple signing algorithms, see
- [ARC-MULTI].)
-
- 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
- value, but is represented throughout this spec in the initial
- position for convenience. Implementers are encouraged to place the
- i= tag at the beginning of the field value to facilitate human
- inspection of the headers.
+ Valid ARC Sets MUST have exactly one instance of each header field
+ (of three) for a given instance value and signing algorithm.
-3.1.1. Valid Range for Instance Tags
+ (_INFORMATIONAL:_ Initial development of ARC is only being done with
+ a single allowed signing algorithm, but parallel work in the DCRUP
+ working group [1] is expanding that. For handling multiple signing
+ algorithms, see [ARC-MULTI].)
The 'i' tag value can range from 1-50 (inclusive).
- ARC implementations MUST support at least ten (10) ARC sets.
-
- An effective operational maximum will have to be developed through
- deployment experience in the field and will be documented within
- [ARC-USAGE] once determined.
+ ARC Chains longer than the defined maximum count MUST be marked as
+ failed.
- ARC chains with more than the defined operational maximum count MUST
- be marked with "cv=fail".
+ _INFORMATIONAL_: 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 value, but is represented throughout this spec in
+ the initial position for convenience. Implementers are encouraged to
+ place the i= tag at the beginning of the field value to facilitate
+ human inspection of the headers.
3.2. ARC-Authentication-Results (AAR)
The ARC-Authentication-Results header field is syntactically and
- semantically identical to an Authentication-Results header field
- (defined in Section 2.2 of [I-D-7601bis] (A-R)). Note that several
- optional data fields SHOULD be added (smtp.client-ip, dkim header.s,
- arc.oldest-pass) to enable completeness for DMARC reporting.
+ semantically identical, except for the header field name itself and
+ its instance tag, to an Authentication-Results header field (defined
+ in Section 2.2 of [I-D-7601bis]).
Formally, the header field is specified as follows using ABNF
[RFC5234]:
-arc-authres-header-prefix = "ARC-Authentication-Results:" [CFWS] arc-info
-arc-info = instance *([CFWS] propspec) [CFWS] ";" authres-payload
-
- The purpose of this header field is to transmit the results of any
- authentication done on the message downstream to participating ADMDs
- validating and continuing the chain.
+ arc-info = instance [CFWS] ";" authres-payload
+ arc-authres-header = "ARC-Authentication-Results:" [CFWS] arc-info
- The AAR MUST contain all A-R results from within the participating
- ADMD, regardless of how many A-R headers are on the message.
+ The AAR MUST contain all Authentication-Results from within the
+ participating ADMD, regardless of how many Authentication-Results
+ headers are on the message.
3.3. ARC-Message-Signature (AMS)
- The ARC-Message-Signature header field is syntactically and
- semantically identical to a DKIM-Signature header field [RFC6376],
- with the following exceptions:
+ The ARC-Message-Signature header field is simplified version of a
+ DKIM-Signature header field [RFC6376], with the following
+ modifications:
o There is an "i" tag, as described in Section 3.1.
o There is no "v" tag defined for the AMS header. As required for
- undefined tags, if seen, it MUST be ignored.
+ undefined tags (in [RFC6376]), if seen, it MUST be ignored.
- ARC-Seal header fields MUST NOT be included in the content covered by
- the signature in this header field.
+ ARC-related header fields (ARC-Seal, ARC-Message-Signture, ARC-
+ Authentication-Results) MUST NOT be included in the content covered
+ by the signature in the signature in this header field.
The AMS SHOULD include any DKIM-Signature header fields already
present on the message in the header fields covered by this
signature.
- 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
- they are likely to be deleted by downstream ADMDs (per Section XXX of
+ Authentication-Results header fields MUST NOT be included since they
+ are likely to be deleted by downstream ADMDs (per Section 5 of
[RFC7601]), thereby breaking the AMS signature.
- As with a DKIM-Signature, the purpose of this header field is to
- allow the ADMD generating it to take some responsibility for handling
- this message as it progresses toward delivery.
-
3.4. ARC-Seal (AS)
The ARC-Seal header field is syntactically and semantically similar
to a DKIM-Signature field, with the following exceptions:
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
- only covers specific header fields. (See below: Section 3.4.2.)
- As a result, no body canonicalization is done. Further, only
- "relaxed" header canonicalization (Section 3.4.2 of [RFC6376]) is
- used.
-
- o The only supported tags are "i" (Section 3.1 supercedes the
- [RFC6376] definition), and "a", "b", "d, "s", "t". The latter 5
- tag definitions are copied from Section 3.5 of [RFC6376].
-
- o An additional tag, "cv" is defined. (See below: Section 3.4.1)
-
-3.4.1. The 'cv' Tag
-
- A new tag "cv" (chain validation) indicates the the outcome of
- evaluating the existing ARC chain upon arrival at the ADMD that is
- adding this header field. It accepts one of three possible values:
-
- o none: There was no chain on the message when it arrived for
- validation; typically occurs when the message arrives at a Message
- Transfer Agent (MTA) from a Message Submission Agent (MSA) or when
- any upstream MTAs may not be participating in ARC handling;
-
- o fail: The message has a chain whose validation failed;
+ only covers specific header fields as defined below:
+ Section 3.4.1. No body canonicalization is done.
- o pass: The message has a chain whose validation succeeded.
+ o Only "relaxed" header canonicalization (Section 3.4.2 of
+ [RFC6376]) is used.
- In ABNF terms:
+ o The only supported tags are "i" (from Section 3.1 of this
+ document), and "a", "b", "d, "s", "t" from Section 3.5 of
+ [RFC6376].
- seal-cv-tag = %x63.76 [FWS] "=" [FWS] ("none" / "fail" / "pass")
+ o An additional tag, "cv" is defined in Section 3.4.2
-3.4.2. Implicit Header Fields
+3.4.1. Covered Header Fields
- The ARC-Seal signs a canonicalized form of the ARC set header values.
- 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
- the message.
+ The ARC-Seal signs a specific canonicalized form of the ARC Set
+ header values. The ARC set header values are compiled in increasing
+ instance order, starting at 1, and include the set being added at the
+ time of sealing the message.
Within a set, the header fields are listed in the following order:
1. ARC-Authentication-Results
2. ARC-Message-Signature
-
3. ARC-Seal
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
- the same manner by which a DKIM-Signature signs itself.
+ the same manner by which a DKIM-Signature signs itself ([RFC6376],
+ section 3.7).
Note that the signing scope for the ARC-Seal is modified in the
situation where a chain has failed validation (see Section 5.1).
-4. Verifier Actions
+3.4.2. The 'cv' Tag
- A verifier takes the following steps to determine the state of the
- ARC chain on a message (cv value). Canonicalization, hash functions,
- and signature validation methods are imported from Section 5 of
- [RFC6376].
+ A new tag "cv" (chain validation) indicates the outcome of evaluating
+ the existing ARC Chain upon arrival at the ADMD that is adding this
+ header field. The values are defined per Section Section 2.2.
- [[ Note: need markdown flag to have subordinate numbering distinction
- issue 11 [3] ]]
+ In ABNF terms:
- 1. Collect all ARC sets currently on the message. If there were
+ chain-status = ("none" / "fail" / "pass")
+ seal-cv-tag = %x63.76 [FWS] "=" [FWS] chain-status
+
+4. Verifier Actions
+
+ A verifier takes the following steps to validate the ARC Chain.
+ Canonicalization, hash functions, and signature validation methods
+ are imported from Section 5 of [RFC6376].
+
+ 1. Collect all ARC Sets currently on the message. If there were
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
- exactly one of each of the three ARC-specific header fields),
- then the chain state is "fail" and the algorithm stops here. a.
- To avoid the overhead of unnecessary computation and delay from
- crypto and DNS operations, the cv value for all ARC-Seal(s) MAY
- be checked at this point. If any of the values are "fail", then
- the overall state of the chain is "fail" and the algorithm stops
- here.
+ 2. Check the morphology of the ARC Chain. If any of these
+ conditions are not met, the chain state is "fail" and the
+ algorithm stops here:
- 3. Conduct verification of the ARC-Message-Signature header field
- bearing the highest instance number. If this verification fails,
- then the chain state is "fail" and the algorithm stops here.
+ 1. Each ARC Set must be complete (e.g., contains exactly one of
+ each of the three ARC-specific header fields);
- 4. For each ARC-Seal from the "N"th instance to the first, apply the
- 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.
- (This step SHOULD be skipped if the earlier step (2.1) was
- performed) b. In Boolean nomenclature: if ((i == 1 && cv !=
- "none") or (cv == "none" && i != 1)) then the chain state is
- "fail" and the algorithm stops here (note that the ordering of
- the logic is structured for short-circuit evaluation). c.
- Initialize a hash function corresponding to the "a" tag of the
- ARC-Seal. d. Compute the canonicalized form of the ARC header
- fields, in the order described in Section 3.4.2, using the
- "relaxed" header canonicalization defined in Section 3.4.2 of
- [RFC6376]. Pass the canonicalized result to the hash function.
- e. Retrieve the final digest from the hash function. f.
- 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
- 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 4.2 for failure case handling) h. If the
- signature is not valid, the chain state is "fail" and the
- algorithm stops here.
+ 2. The instance values must form a continuous sequence from 1..N
+ with no gaps or repeats;
- 5. If all seals pass validation, then the chain state is "pass", and
- the algorithm is complete.
+ 3. The cv value for all ARC-Seal(s) must be non-failing:
- 6. Results from the determination of this algorithm SHOULD be
- recorded in the Authentication-Results header
+ 1. For i > 1, the value must be "pass";
- Whatever the end result of the verifier's checks via the algorithm
- specified above, the results MUST be added into the Authentication-
- Results header(s) for the ADMD.
+ 2. For i = 1, the value must be "none".
- [[ See issue 12 [4] regarding the final paragraph ]]
+ 3. For each ARC-Message-Signature from the "N"th instance to the
+ first, validate the AMS:
- The verifier should save the cv state for subsequent use by any
- sealing which may be done later (potentially after message
- modification) within the same trust boundary. The cv state may be
- 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
- architecture of the ADMD.
+ 1. If the "N"th instance (most recent) signature fails, then the
+ chain state is "fail" and the algorithm stops here.
-4.1. ARC Authentication-Results Information
+ 2. If one of the prior AMS signatures fails to validate (for
+ instance "M"), then set the oldest-pass value to the lowest
+ AMS instance number which passed (M+1) and go onto the next
+ step (there is no need to check any other (older) AMS
+ signatures). This does not affect the validity of the chain.
+
+ 3. If all AMS signatures verify, set the oldest-pass value to
+ zero (0).
+
+ 4. For each ARC-Seal from the "N"th instance to the first, validate
+ the seal.
+
+ 1. If any seal is not valid, the chain state is "fail" and the
+ algorithm stops here.
+
+ 2. If all seals pass validation, then the chain state is "pass",
+ and the algorithm is complete.
+
+ The end result of the verifier's checks via this algorithm MUST be
+ added into the Authentication-Results header(s) for the ADMD.
+
+ _INFORMATIONAL_: Recipients of an ARC Chain that is invalid or does
+ not pass SHOULD NOT draw negative conclusions without a good
+ understanding of the wider handling context. Until ARC usage is
+ widespread, intermediaries will continue to modify messages without
+ ARC seals.
+
+ As with a failing DKIM signature ([RFC6376] Section-6.3), a message
+ with a failing ARC Chain MUST be treated the same as a message with
+ no ARC Chain.
+
+4.1. Authentication-Results Information
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. Recording the following information in the A-R provides a
- mechanism for this information to survive transit.
+ fail. Recording the following information in the Authentication-
+ Results stamped as part of the ARC evaluation provides a mechanism
+ for this information to survive transit through a particular ADMD.
+
+ Stamped ARC evaluation results is limited to the Chain Validation
+ status (cv) from Section 2.2.
The ptypes and properties defined in this section SHOULD be recorded
- in the AR:
+ in the Authentication-Results:
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.
-
- [[ Also see issue 20 [5] for another possible field to be added and
- issue 21 [6] re which document should define these for IANA action.
- ]]
+ o header.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
any other ARC violation. They result in a "cv=fail" verdict.
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
[RFC3463] "message integrity failure" [ENHANCED-STATUS] and
corresponding SMTP response code.
-5. Signer Actions
-
- [[ See issue 13 [7] for critique ]]
-
- This section includes a specification of the actions an ARC signer
- takes when presented with a message.
+5. Sealer Actions
- The signer MUST undertake the following steps:
+ An ARC sealer MUST take the following actions when presented with a
+ message:
1. Before creating an ARC signature, perform any other, normal
authentication and/or signing, so that the ARC signature can
cover those results.
- 2. Build and attach the new ARC set:
+ 2. Build and attach the new ARC Set:
- 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=);
otherwise set "N" equal to zero for the following steps.
2. Generate and attach to the message an ARC-Authentication-
- Results header field using instance number N+1 and the same
- content from the previous step.
+ Results header field as defined in Section Section 3.2, using
+ instance number N+1 and the same content from the previous
+ step.
3. Generate and attach to the message an ARC-Message-Signature
header field as defined in Section 3.3 above, using instance
number N+1.
4. Generate and attach to the message an ARC-Seal header field
using the general algorithm described in Section 3.4 above,
the chain validation status as determined in Section 4, and
instance number N+1.
5.1. Marking and Sealing "cv=fail" (Invalid) Chains
The header fields signed by the AS header field b= value in the case
of a chain failure MUST be only the matching instance headers created
by the MTA which detected the malformed chain, as if this newest ARC
- set was the only set present.
-
-6. Usage of ARC and Chain Validity
-
-6.1. Relationship between DKIM-Signature and AMS signing scopes
-
- [[ See issue 14 [8] for critique of this section ]]
-
- DKIM-Signatures SHOULD never sign any ARC header fields.
-
-6.2. Assessing Chain Validity Violations
-
- [[ Issue 15 [9] ]]
-
- Email transit can produce broken signatures for a wide variety of
- benign reasons. This includes possibly breaking one or more ARC
- signatures. Therefore, receivers need to be wary of ascribing motive
- to such breakage although patterns of common behaviour may provide
- some basis for adjusting local policy decisions.
+ Set was the only set present.
- 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
- valid ARC chain. Consequently, all normal, content-based analysis
- SHOULD still be performed on any message having a valid chain of ARC
- header sets.
+ _INFORMATIONAL:_ In the case of a malformed or otherwise invalid
+ chain there is no way to generate a deterministic set of AS header
+ fields ({#implicit_as_h}) so this approach is mandated.
-7. Recording and Reporting the Results of ARC Evaluation
+6. 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
sender of the message. This information should be preserved and
reported as follows.
-7.1. Information from an ARC Evaluation
+6.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:
o A list of the "d=" domains found in the validated ARC-Seal header
fields
o The "d=" domain found in the most recent (highest instance number)
AMS header field (since that is the only one necessarily
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
- terminal ARC set.
+ terminal ARC Set.
-7.2. Recording (local) ARC Evaluation Results
+6.2. Recording (local) ARC Evaluation Results
- Receivers MAY add an "arc=[pass|fail|policy]" method annotation into
- a locally-affixed Authentication-Results [RFC7601] header field along
- with any salient comment(s).
+ Receivers who process an attached ARC Chain SHOULD add an
+ "arc=[pass|fail|policy]" method annotation into a locally-affixed
+ Authentication-Results [RFC7601] header field along with any salient
+ comment(s).
- Details of the ARC chain which was evaluated should be included in
+ Details of the ARC Chain which was evaluated should be included in
the Authentication-Results and AAR headers per Section Section 4.1.
-7.3. DMARC Reporting of ARC Findings - Interim
-
- [[ Note: Move to separate document? [10] (see the additional fields
- specified in Section 4.1) ]]
+6.3. DMARC Reporting of ARC Findings - Interim
Receivers SHOULD indicate situations in which ARC evaluation
influenced the results of their local policy determination. DMARC
reporting of ARC-informed decisions can be accomplished by adding a
local_policy comment explanation containing the list of data
- discovered in the ARC evaluation (Section 7.1 and Section 4.1):
+ discovered in the ARC evaluation, which at a minimum SHOULD include:
+ * the Chain Validation status, * the domain and selector for each AS,
+ * the IP addresses of the mail originating ADMD:
- delivered
+ none
fail
- fail source.ip=10.0.0.1
+ fail
local_policy
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
+ as[2].s=s2 as[1].d=d1.example as[1].s=s3 client-ip[1]=10.10.10.13
- In the suggested sample, d2.example is the sealing domain for ARC[2]
- and d1.example is the sealing domain for ARC[1].
-
- Mediators SHOULD generate DMARC reports on messages which transit
- their system just like any other message which they receive. This
- will result in multiple reports for each mediated message as they
- transit the series of handlers. DMARC report consumers should be
- aware of this behaviour and make the necessary accommodations.
-
-8. Supporting Alternate Signing Algorithms
+ In the sample above, d2.example is the sealing domain for ARC[2] and
+ d1.example is the sealing domain for ARC[1].
- This section has been moved to [ARC-MULTI]
+ Intermediary message handlers SHOULD generate DMARC reports on
+ messages which transit their system just like any other message which
+ they receive. This will result in multiple reports for each mediated
+ message as they transit the series of handlers. DMARC report
+ consumers should be aware of this behaviour and make the necessary
+ accommodations.
-9. Privacy Considerations
+7. 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
with their operating goals.
-10. IANA Considerations
+8. IANA Considerations
- [[ See issue 21 [11] regarding which document should be definitive
- for these fields. ]]
+ [[ Note to the RFC Editors: Some of these fields are defined both
+ here and in [I-D-7601bis]. Please delete the overlap from whichever
+ document goes through the publication process after the other. ]]
This specification adds three new header fields as defined below.
-10.1. Authentication-Results Method Registry Update
+8.1. Authentication-Results Method Registry Update
This draft adds one item to the IANA "Email Authentication Methods"
registry:
o Method : arc
-
Defined: [I-D.ARC]
-
ptype: header
-
Property: chain evaluation result
-
Value: chain evaluation result status (see Section 3.4)
-
Status: active
- o Method : dkim
-
- Defined: [I-D.ARC]
-
- ptype: header
-
- Property: selector
+8.2. Email Authentication Result Names Registry Update
- Value: value of signature "s" tag (see [RFC6376])
+ This draft updates the Email Authentication Results registry, most
+ recently defined in [I-D-7601bis], with one new authentication method
+ and several status codes, all defined by this document:
- Status: active
+ o Auth Method : arc
+ Code: "none", "pass", "fail"
+ Specification: [I-D.ARC] Section 3.4.2 Status: active
o Method : spf
-
Defined: [I-D.ARC]
-
ptype: smtp
Property: client-ip
-
Value: the connecting client IP address from which the message is
received
-
Status: active
o Method : arc
-
Defined: [I-D.ARC]
-
ptype: header
-
Property: oldest-pass
-
Value: the oldest instance with a still validating AMS signature
-
Status: active
-10.2. Definitions of the ARC header fields
+8.3. Definitions of the ARC header fields
This specification adds three new header fields to the "Permanent
Message Header Field Registry", as follows:
o Header field name: ARC-Seal
-
Applicable protocol: mail
-
Status: draft
-
Author/Change controller: IETF
-
Specification document(s): [I-D.ARC]
-
Related information: [RFC6376]
o Header field name: ARC-Message-Signature
-
Applicable protocol: mail
-
Status: draft
-
Author/Change controller: IETF
-
Specification document(s): [I-D.ARC]
-
Related information: [RFC6376]
o Header field name: ARC-Authentication-Results
-
Applicable protocol: mail
-
Status: standard
-
Author/Change controller: IETF
-
Specification document(s): [I-D.ARC]
-
Related information: [RFC7601]
-11. Security Considerations
+9. Security Considerations
The Security Considerations of [RFC6376] and [RFC7601] apply directly
to this specification.
-11.1. Header Size
+9.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
greater size of the header.
-11.2. DNS Operations
+9.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
mechanisms which can increase the lookups for a given target value).
This has at least two effects:
- 1. An attacker can send a message to an ARC partipant with a
- concocted sequence of ARC sets bearing the domains of intended
+ 1. An attacker can send a message to an ARC participant with a
+ concocted sequence of ARC Sets bearing the domains of intended
victims, and all of them will be queried by the participant until
a failure is discovered. The difficulty of forging the signature
values should limit the extent of this load to domains under
control of the attacker.
2. DKIM only does one DNS check per signature, while this one can do
many (per chain). Absent caching, slow DNS responses can cause
SMTP timeouts; and backlogged delivery queues on mediating
systems. This could be exploited as a DoS attack.
-11.3. Message Content Suspicion
+9.3. Message Content Suspicion
- Recipients are cautioned to treat messages bearing ARC sets with the
+ Recipients are cautioned to treat messages bearing ARC Sets with the
same suspicion that they apply to all other email messages. This
includes appropriate content scanning and other checks for
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
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:
1. You have to trust all signatories; and
2. Even trusted systems may have become compromised or may not
properly authenticate messages, so even with a chain of trusted
participants, the message might still never have authenticated in
the first place (which is why you have the AAR to inspect) or
could have been subject to unintended modifications.
-12. Evaluating the Efficacy of the ARC Protocol
+10. Evaluating the Efficacy of the ARC Protocol (Experimental
+ Considerations)
The ARC protocol is designed to mitigate some of the most common
failure conditions for email which transits intermediary handlers en
route to the final recipient. Some of these problems have happened
due to the adoption of the DMARC protocol [RFC7489] and are listed in
[RFC6377] and [RFC7960].
As the ARC protocol becomes standardized and implemented amongst
intermediary handlers, the following aspects should be evaluated in
order to determine the success of the protocol in accomplishing the
intended benefits.
NOTE: Terminology within this section does NOT follow [RFC2119]
interpretation. This section represents the current thoughts of the
working group regarding unanswered questions related to the protocol.
Wider deployment will inform these topics and probably expand them.
-12.1. Success Consideration
+10.1. Success Consideration
Currently, many receivers have heuristically determined overrides in
order to rescue mail from intermediary-caused failures. Many of
those overrides rely on inferrence rather than direct evidence.
ARC will be a success if, for ARC sealed messages, receivers are able
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
rfc5322.From author domain.
-12.2. Failure Considerations
+10.2. Failure Considerations
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 11) then
+ ARC opens up significant new vectors for abuse (see Section 9) then
this protocol will be a failure. Note that weaknesses inherent in
the mail protocols ARC is built upon (such as DKIM replay attacks and
other known issues) are not new vectors which can be attributed to
this specification.
-12.3. Open Questions
+10.3. Open Questions
The following open questions are academic and have no clear answer at
the time of the development of the protocol. However, wide-spread
deployment should be able to gather the necessary data to answer some
or all of them.
-12.3.1. Value of the ARC-Seal (AS) Header
+10.3.1. Value of the ARC-Seal (AS) Header
Data should be collected to show if the ARC-Seal (AS) provides value
beyond the ARC Message Signature (AMS) for either making delivery
decisions or catching malicious actors trying to craft or replay
malicious chains.
-12.3.2. DNS Overhead
+10.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
- issue (see Section 11.2), it is unclear how much overhead will truly
+ issue (see Section 9.2), it is unclear how much overhead will truly
be added. This is similar to some of the initial processing and
query load concerns which were debated at the time of the DKIM
specification development.
Data should be collected to better understand usable length and
- distribution of lengths found in valid ARC chains along with the the
- DNS impact of processing ARC chains.
+ distribution of lengths found in valid ARC Chains along with the the
+ DNS impact of processing ARC Chains.
-12.3.3. Distinguishing Valuable from Worthless Trace Information
+ An effective operational maximum will have to be developed through
+ deployment experience in the field.
+
+10.3.3. Distinguishing Valuable from Worthless Trace Information
There are several edge cases where the information in the AAR can
make the difference between message delivery or rejection. For
example, if there is a well known mailing list that ARC seals but
doesn't do its own initial DMARC enforcement, a Final Receiver with
this knowledge could make a delivery decision based upon the
authentication information it sees in the corresponding AAR header.
Certain trace information in the AAR is useful/necessary in the
construction of DMARC reports. It would be beneficial to identify
@@ -1133,26 +1050,26 @@
and/or provide other signals related to message delivery.
It is unclear what trace information will be valuable for all
receivers, regardless of size.
Data should be collected on what trace information receivers are
using that provides useful signals that affect deliverability, and
what portions of the trace data are left untouched or provide no
useful information.
- Since many such systems are intentionly proprietary or confidential
+ Since many such systems are intentionally proprietary or confidential
to prevent gaming by abusers, it may not be viable to reliably answer
this particular question. The evolving nature of attacks can also
shift the landscape of "useful" information over time.
-13. Implementation Status
+11. Implementation Status
[[ Note to the RFC Editor: Please remove this section before
publication along with the reference to [RFC6982]. ]]
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC6982].
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
@@ -1163,94 +1080,76 @@
features. Readers are advised to note that other implementations may
exist.
This information is known to be correct as of the seventh
interoperability test event which was held on 2017-07-15 & 16 at
IETF99.
For a few of the implementations, later status information was
available as of December 2017.
-13.1. GMail test reflector and incoming validation
+11.1. GMail test reflector and incoming validation
Organization: Google
-
Description: Internal production implementation with both debug
analysis and validating + sealing pass-through function
-
Status of Operation: Production - Incoming Validation
-
Coverage: Full spec implemented as of [ARC-DRAFT-06]
-
Licensing: Proprietary - Internal only
-
Implementation Notes:
o Full functionality was demonstrated during the interop testing on
2017-07-15.
- Contact Info: arc-discuss@dmarc.org [12]
+ Contact Info: arc-discuss@dmarc.org [2]
-13.2. AOL test reflector and internal tagging
+11.2. AOL test reflector and internal tagging
Organization: AOL
-
Description: Internal prototype implementation with both debug
analysis and validating + sealing pass-through function
-
Status of Operation: Beta
-
- Coverage: ARC chain validity status checking is operational, but only
- applied to email addresses enrolled in the test program. This system
- conforms to [ARC-DRAFT-06]
-
+ Coverage: ARC Chain validity status checking is operational, but only
+ applied to email addresses enrolled in the test program.
+ This system conforms to [ARC-DRAFT-06]
Licensing: Proprietary - Internal only
-
Implementation Notes:
o 2017-07-15: Full functionality verified during the interop
testing.
- Contact Info: arc-discuss@dmarc.org [13]
+ Contact Info: arc-discuss@dmarc.org [3]
-13.3. dkimpy
+11.3. dkimpy
Organization: dkimpy developers/Scott Kitterman
-
Description: Python DKIM package
Status of Operation: Production
-
Coverage:
o 2017-07-15: The internal test suite is incomplete, but the command
line developmental version of validator was demonstrated to
interoperate with the Google and AOL implementations during the
interop on 2017-07-15 and the released version passes the tests in
- [ARC-TEST] arc_test_suite [14] with both python and python3.
+ [ARC-TEST] arc_test_suite [4] with both python and python3.
Licensing: Open/Other (same as dkimpy package = BCD version 2)
-
Contact Info: https://launchpad.net/dkimpy
-13.4. OpenARC
+11.4. OpenARC
Organization: TDP/Murray Kucherawy
-
Description: Implemention of milter functionality related to the
OpenDKIM and OpenDMARC packages
-
Status of Operation: Beta
-
Coverage: Built to support [ARC-DRAFT-10]
-
Licensing: Open/Other (same as OpenDKIM and OpenDMARC packages)
-
Implementation Notes:
o The build is FreeBSD oriented but some packages have been built
for easier deployment on RedHat-based Linux platforms.
o Some issues still exist when deploying in a chained milter
arrangement (such as OpenSPF -> OpenDKIM -> OpenDMARC -> OpenARC)
with coordination between the stages. When deployed in a
"sandwich" configuration around an MLM, there is no effective
mechanism to convey trust from the ingress (validator) to egress
@@ -1250,54 +1149,45 @@
for easier deployment on RedHat-based Linux platforms.
o Some issues still exist when deploying in a chained milter
arrangement (such as OpenSPF -> OpenDKIM -> OpenDMARC -> OpenARC)
with coordination between the stages. When deployed in a
"sandwich" configuration around an MLM, there is no effective
mechanism to convey trust from the ingress (validator) to egress
(signer) instances. (_NOTE_: this is expected to resolved with a
new release of OpenDMARC expected in January 2018.)
- Contact Info: arc-discuss@dmarc.org [15]
+ Contact Info: arc-discuss@dmarc.org [5]
-13.5. Mailman 3.2 patch
+11.5. Mailman 3.2 patch
Organization: Mailman development team
-
Description: Integrated ARC capabilities within the Mailman 3.2
package
Status of Operation: Patch submitted
-
Coverage: Based on OpenARC
-
Licensing: Same as mailman package - GPL
-
Implementation Notes:
o Appears to work properly in at least one beta deployment, but
waiting on acceptance of the pull request into the mainline of
mailman development
Contact Info: https://www.gnu.org/software/mailman/contact.html
-13.6. Copernica/MailerQ web-based validation
+11.6. Copernica/MailerQ web-based validation
Organization: Copernica
-
Description: Web-based validation of ARC-signed messages
-
Status of Operation: Beta
-
Coverage: Built to support [ARC-DRAFT-05]
-
Licensing: On-line usage only
-
Implementation Notes:
o Released 2016-10-24
o Requires full message content to be pasted into a web form found
at http://arc.mailerq.com/ (warning - https is not supported).
o An additional instance of an ARC signature can be added if one is
willing to paste a private key into an unsecured web form.
@@ -1299,31 +1189,27 @@
at http://arc.mailerq.com/ (warning - https is not supported).
o An additional instance of an ARC signature can be added if one is
willing to paste a private key into an unsecured web form.
o 2017-07-15: Testing shows that results match the other
implementations listed in this section.
Contact Info: https://www.copernica.com/
-13.7. Rspamd
+11.7. Rspamd
Organization: Rspamd community
-
Description: ARC signing and verification module
-
Status of Operation: Production, though deployment usage is unknown
Coverage: Built to support [ARC-DRAFT-06]
-
Licensing: Open source
-
Implementation Notes:
o 2017-06-12: Released with version 1.6.0
o 2017-07-15: Testing during the interop showed that the validation
functionality interoperated with the Google, AOL, dkimpy and
MailerQ implementations
Contact Info: https://rspamd.com/doc/modules/arc.html and
https://github.com/vstakhov/rspamd
@@ -1321,51 +1207,42 @@
o 2017-06-12: Released with version 1.6.0
o 2017-07-15: Testing during the interop showed that the validation
functionality interoperated with the Google, AOL, dkimpy and
MailerQ implementations
Contact Info: https://rspamd.com/doc/modules/arc.html and
https://github.com/vstakhov/rspamd
-13.8. PERL MAIL::DKIM module
+11.8. PERL MAIL::DKIM module
Organization: FastMail
-
Description: Email domain authentication (sign and/or verify) module,
previously included SPF / DKIM / DMARC, now has ARC added
-
Status of Operation: Production, deployment usage unknown
-
Coverage: Built to support [ARC-DRAFT-10]
-
Licensing: Open Source
-
Implementation Notes:
o 2017-12-15: v0.50 released with full test set passing for ARC
Contact Info: http://search.cpan.org/~mbradshaw/Mail-DKIM-0.50/
-13.9. PERL Mail::Milter::Authentication module
+11.9. PERL Mail::Milter::Authentication module
Organization: FastMail
-
Description: Email domain authentication milter, uses MAIL::DKIM (see
above)
-
Status of Operation: Intial validation completed during IETF99
hackathon with some follow-on work during the week
-
Coverage: Built to support [I-D.ARC]
-
Licensing: Open Source
Implementation Notes:
o 2017-07-15: Validation functionality which interoperates with
Gmail, AOL, dkimpy was demonstrated; later in the week of IETF99,
the signing functionality was reported to be working
o 2017-07-20: ARC functionality has not yet been pushed back to the
github repo but should be showing up soon
@@ -1364,96 +1241,85 @@
o 2017-07-15: Validation functionality which interoperates with
Gmail, AOL, dkimpy was demonstrated; later in the week of IETF99,
the signing functionality was reported to be working
o 2017-07-20: ARC functionality has not yet been pushed back to the
github repo but should be showing up soon
Contact Info: https://github.com/fastmail/authentication_milter
-13.10. Sympa List Manager
+11.10. Sympa List Manager
Organization: Sympa Dev Community
-
Description: Work in progress
-
Status of Operation: Work in progress
-
Coverage: unknown
-
Licensing: open source
-
Implementation Notes:
o 2018-01-05: Tracked as https://github.com/sympa-community/sympa/
issues/153
Contact Info: https://github.com/sympa-community
-13.11. Oracle Messaging Server
+11.11. Oracle Messaging Server
Organization: Oracle
-
Description:
-
Status of Operation: Intial development work during IETF99 hackathon.
Status since then unknown.
-
- Coverage: Built to support [ARC-DRAFT-06]
-
+ Coverage: Work in progress
Licensing: Unknown
-
Implementation Notes:
- o 2018-01: Protocol handling components are completed, but crypto is
+ o 2018-03: Protocol handling components are completed, but crypto is
not yet functional.
Contact Info: Chris Newman
-13.12. MessageSystems Momentum
+11.12. MessageSystems Momentum and PowerMTA platforms
Organization: MessageSystems/SparkPost
-
Description: OpenARC integration into the LUA-enabled Momentum
processing space
-
Status of Operation: Beta
-
Coverage: Built to support [ARC-DRAFT-10]
-
Licensing: Unknown
-
Implementation Notes:
o Initial deployments for validation expected in mid-2018.
Contact Info:
-14. References
+12. References
-14.1. Normative References
+12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
.
[RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes",
RFC 3463, DOI 10.17487/RFC3463, January 2003,
.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
.
+ [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
+ DOI 10.17487/RFC5322, October 2008,
+ .
+
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
DOI 10.17487/RFC5598, July 2009,
.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011,
.
[RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and
@@ -1467,21 +1333,21 @@
[RFC7601] Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", RFC 7601,
DOI 10.17487/RFC7601, August 2015,
.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, .
-14.2. Informative References
+12.2. Informative References
[ARC-DRAFT-05]
Andersen, K., "Authenticated Received Chain (ARC) Protocol
(I-D-05)", n.d., .
[ARC-DRAFT-06]
Andersen, K., "Authenticated Received Chain (ARC) Protocol
(I-D-06)", n.d., .
@@ -1491,21 +1357,21 @@
(I-D-10)", n.d., .
[ARC-MULTI]
Andersen, K., "Using Multiple Signing Algorithms with
ARC", January 2018, .
[ARC-TEST]
Blank, S., "ARC Test Suite", January 2017,
- .
+ .
[ARC-USAGE]
Jones, S., Adams, T., Rae-Grant, J., and K. Andersen,
"Recommended Usage of the ARC Headers", December 2017,
.
[ENHANCED-STATUS]
"IANA SMTP Enhanced Status Codes", n.d.,
.
[RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky,
E., Ed., and K. Andersen, Ed., "Interoperability Issues
between Domain-based Message Authentication, Reporting,
and Conformance (DMARC) and Indirect Email Flows",
RFC 7960, DOI 10.17487/RFC7960, September 2016,
.
-14.3. URIs
-
- [1] https://trac.ietf.org/trac/dmarc/ticket/10
-
- [2] https://datatracker.ietf.org/wg/dcrup/about/
-
- [3] https://trac.ietf.org/trac/dmarc/ticket/11
-
- [4] https://trac.ietf.org/trac/dmarc/ticket/12
-
- [5] https://trac.ietf.org/trac/dmarc/ticket/20
-
- [6] https://trac.ietf.org/trac/dmarc/ticket/21
-
- [7] https://trac.ietf.org/trac/dmarc/ticket/13
-
- [8] https://trac.ietf.org/trac/dmarc/ticket/14
-
- [9] https://trac.ietf.org/trac/dmarc/ticket/15
-
- [10] https://trac.ietf.org/trac/dmarc/ticket/16
+12.3. URIs
- [11] https://trac.ietf.org/trac/dmarc/ticket/21
+ [1] https://datatracker.ietf.org/wg/dcrup/about/
- [12] mailto:arc-discuss@dmarc.org
+ [2] mailto:arc-discuss@dmarc.org
- [13] mailto:arc-discuss@dmarc.org
+ [3] mailto:arc-discuss@dmarc.org
- [14] https://github.com/ValiMail/arc_test_suite
+ [4] https://github.com/Valimail/arc_test_suite
- [15] mailto:arc-discuss@dmarc.org
+ [5] mailto:arc-discuss@dmarc.org
- [16] https://trac.ietf.org/trac/dmarc/ticket/17
+ [6] https://trac.ietf.org/trac/dmarc/ticket/17
- [17] mailto:dmarc@ietf.org
+ [7] mailto:dmarc@ietf.org
- [18] mailto:arc-discuss@dmarc.org
+ [8] mailto:arc-discuss@dmarc.org
Appendix A. Appendix A - Design Requirements
(This section is re-inserted for background information from
[ARC-DRAFT-06] and earlier versions.)
The specification of the ARC framework is driven by the following
high-level goals, security considerations, and practical operational
requirements.
@@ -1599,21 +1445,21 @@
ARC is not a trust framework. Users of the ARC header fields are
cautioned against making unsubstantiated conclusions when
encountering a "broken" ARC sequence.
Appendix B. Appendix B - Example Usage
[[ Note: The following examples were mocked up early in the
definition process for the spec. They no longer reflect the current
definition and need various updates which will be included in a
- future draft. Issue 17 [16] ]]
+ future draft. Issue 17 [6] ]]
(Obsolete but retained for illustrative purposes)
B.1. Example 1: Simple mailing list
B.1.1. Here's the message as it exits the Origin:
Return-Path:
Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
(authenticated bits=0)
@@ -2421,36 +2268,36 @@
From: John Q Doe
To: arc@example.org
Subject: [Lists] Example 1
Hey gang,
This is a test message.
--J.
Appendix C. Acknowledgements
- This draft is the work of OAR-Dev Group.
+ This draft originated with the work of OAR-Dev Group.
The authors thank all of the OAR-Dev group for the ongoing help and
though-provoking discussions from all the participants, especially:
Alex Brotman, Brandon Long, Dave Crocker, Elizabeth Zwicky, Franck
Martin, Greg Colburn, J. Trent Adams, John Rae-Grant, Mike Hammer,
Mike Jones, Steve Jones, Terry Zink, Tim Draegen.
Grateful appreciation is extended to the people who provided feedback
through the discuss mailing list.
Appendix D. Comments and Feedback
Please address all comments, discussions, and questions to
- dmarc@ietf.org [17]. Earlier discussions can be found at arc-
- discuss@dmarc.org [18].
+ dmarc@ietf.org [7]. Earlier discussions can be found at arc-
+ discuss@dmarc.org [8].
Authors' Addresses
Kurt Andersen
LinkedIn
1000 West Maude Ave
Sunnyvale, California 94085
USA
Email: kurta@linkedin.com
@@ -2459,18 +2306,18 @@
Google
Email: blong@google.com
Steven Jones (editor)
TDP
Email: smj@crash.com
Seth Blank (editor)
- ValiMail
+ Valimail
Email: seth@valimail.com
Murray Kucherawy (editor)
TDP
Email: superuser@gmail.com