draft-ietf-dmarc-arc-protocol-10.txt   draft-ietf-dmarc-arc-protocol-11.txt 
DMARC Working Group K. Andersen DMARC Working Group K. Andersen
Internet-Draft LinkedIn Internet-Draft LinkedIn
Intended status: Standards Track B. Long, Ed. Intended status: Experimental B. Long, Ed.
Expires: June 22, 2018 Google Expires: July 26, 2018 Google
S. Jones, Ed. S. Jones, Ed.
TDP TDP
S. Blank, Ed. S. Blank, Ed.
ValiMail ValiMail
December 19, 2017 M. Kucherawy, Ed.
TDP
January 22, 2018
Authenticated Received Chain (ARC) Protocol Authenticated Received Chain (ARC) Protocol
draft-ietf-dmarc-arc-protocol-10 draft-ietf-dmarc-arc-protocol-11
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 record the status of that authentication
at each step along the handling path, for use by the final recipient at each step along the handling path, for use by the final recipient
in making choices about the disposition of the message. Changes in in making choices about the disposition of the message. Changes in
the message that might break DKIM or DMARC can be identified through the message that might break DKIM or DMARC can be identified through
skipping to change at page 1, line 42 skipping to change at page 1, line 44
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 June 22, 2018. This Internet-Draft will expire on July 26, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Definitions and Terminology . . . . . . . . . . . . . . . . . 6 3. Definitions and Terminology . . . . . . . . . . . . . . . . . 6
3.1. Referenced Definitions . . . . . . . . . . . . . . . . . 6 3.1. Referenced Definitions . . . . . . . . . . . . . . . . . 6
4. Protocol Elements and Features . . . . . . . . . . . . . . . 7 4. Protocol Elements and Features . . . . . . . . . . . . . . . 7
4.1. Features of the ARC Protocol . . . . . . . . . . . . . . 7 4.1. Features of the ARC Protocol . . . . . . . . . . . . . . 8
4.1.1. Chain of Custody . . . . . . . . . . . . . . . . . . 7 4.1.1. Chain of Custody . . . . . . . . . . . . . . . . . . 8
4.1.2. Optional Participation . . . . . . . . . . . . . . . 8 4.1.2. Optional Participation . . . . . . . . . . . . . . . 8
4.1.3. Only one ARC Chain (One Chain to Rule Them All) . . . 8 4.1.3. Only one ARC Chain (One Chain to Rule Them All) . . . 9
4.1.4. All Failures are Permanent . . . . . . . . . . . . . 8 4.1.4. All Failures are Permanent . . . . . . . . . . . . . 9
4.1.5. Benign nature of an ARC Set . . . . . . . . . . . . . 9 4.1.5. Benign nature of an ARC Set . . . . . . . . . . . . . 9
4.1.6. Key Management . . . . . . . . . . . . . . . . . . . 9 4.1.6. Key Management . . . . . . . . . . . . . . . . . . . 9
4.1.7. Trace Information . . . . . . . . . . . . . . . . . . 9 4.1.7. Trace Information . . . . . . . . . . . . . . . . . . 10
5. The ARC Header Fields . . . . . . . . . . . . . . . . . . . . 9 4.1.8. Instance Tags . . . . . . . . . . . . . . . . . . . . 10
5.1. Instance ('i=') Tag . . . . . . . . . . . . . . . . . . . 9 4.1.9. Chain Validation Status . . . . . . . . . . . . . . . 10
5. The ARC Header Fields . . . . . . . . . . . . . . . . . . . . 10
5.1. Instance ('i=') Tag . . . . . . . . . . . . . . . . . . . 10
5.1.1. Valid Range for Instance Tags . . . . . . . . . . . . 10 5.1.1. Valid Range for Instance Tags . . . . . . . . . . . . 10
5.2. ARC-Authentication-Results (AAR) . . . . . . . . . . . . 10 5.2. ARC-Authentication-Results (AAR) . . . . . . . . . . . . 11
5.2.1. ptypes and properties for arc-info . . . . . . . . . 11 5.2.1. ptypes and properties for arc-info . . . . . . . . . 11
5.3. ARC-Message-Signature (AMS) . . . . . . . . . . . . . . . 11 5.3. ARC-Message-Signature (AMS) . . . . . . . . . . . . . . . 12
5.4. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . . . 12 5.4. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . . . 12
5.4.1. The 'cv' Tag . . . . . . . . . . . . . . . . . . . . 12 5.4.1. The 'cv' Tag . . . . . . . . . . . . . . . . . . . . 13
5.4.2. Implicit Header Fields . . . . . . . . . . . . . . . 13 5.4.2. Implicit Header Fields . . . . . . . . . . . . . . . 13
6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . 13 6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . 14
7. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Handling DNS Problems While Validating ARC . . . . . . . 15
6.2. Responding to ARC Validity Violations During the SMTP
Transaction . . . . . . . . . . . . . . . . . . . . . . . 15
7. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Marking and Sealing "cv=fail" (Invalid) Chains . . . . . 16
8. Usage of ARC and Chain Validity . . . . . . . . . . . . . . . 16 8. Usage of ARC and Chain Validity . . . . . . . . . . . . . . . 16
8.1. Relationship between DKIM-Signature and AMS signing 8.1. Relationship between DKIM-Signature and AMS signing
scopes . . . . . . . . . . . . . . . . . . . . . . . . . 16 scopes . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.2. Assessing Chain Validity Violations . . . . . . . . . . . 16 8.2. Assessing Chain Validity Violations . . . . . . . . . . . 17
8.3. Marking and Sealing "cv=fail" (Invalid) Chains . . . . . 16
8.4. Handling DNS Problems While Validating ARC . . . . . . . 16
8.5. Responding to ARC Validity Violations . . . . . . . . . . 16
9. Recording and Reporting the Results of ARC Evaluation . . . . 17 9. Recording and Reporting the Results of ARC Evaluation . . . . 17
9.1. Information from an ARC Evaluation . . . . . . . . . . . 17 9.1. Information from an ARC Evaluation . . . . . . . . . . . 17
9.2. Recording (local) ARC Evaluation Results . . . . . . . . 17 9.2. Recording (local) ARC Evaluation Results . . . . . . . . 18
9.3. DMARC Reporting of ARC Findings - Interim . . . . . . . . 17 9.3. DMARC Reporting of ARC Findings - Interim . . . . . . . . 18
10. Supporting Alternate Signing Algorithms . . . . . . . . . . . 18 10. Supporting Alternate Signing Algorithms . . . . . . . . . . . 19
10.1. Introductory Period . . . . . . . . . . . . . . . . . . 18
10.2. Co-Existence Period . . . . . . . . . . . . . . . . . . 18
10.3. Deprecation Period . . . . . . . . . . . . . . . . . . . 19
10.4. Obsolescence Period . . . . . . . . . . . . . . . . . . 19
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
12.1. Authentication-Results Method Registry Update . . . . . 19 12.1. Authentication-Results Method Registry Update . . . . . 19
12.2. Definitions of the ARC header fields . . . . . . . . . . 19 12.2. Definitions of the ARC header fields . . . . . . . . . . 20
13. Security Considerations . . . . . . . . . . . . . . . . . . . 20 13. Security Considerations . . . . . . . . . . . . . . . . . . . 21
13.1. Header Size . . . . . . . . . . . . . . . . . . . . . . 20 13.1. Header Size . . . . . . . . . . . . . . . . . . . . . . 21
13.2. DNS Operations . . . . . . . . . . . . . . . . . . . . . 21 13.2. DNS Operations . . . . . . . . . . . . . . . . . . . . . 21
13.3. Message Content Suspicion . . . . . . . . . . . . . . . 21 13.3. Message Content Suspicion . . . . . . . . . . . . . . . 22
14. Implementation Status . . . . . . . . . . . . . . . . . . . . 21 14. Evaluating the Efficacy of the ARC Protocol . . . . . . . . . 22
14.1. GMail test reflector and incoming validation . . . . . . 22 14.1. Success Consideration . . . . . . . . . . . . . . . . . 23
14.2. AOL test reflector and internal tagging . . . . . . . . 22 14.2. Failure Considerations . . . . . . . . . . . . . . . . . 23
14.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 23 14.3. Open Questions . . . . . . . . . . . . . . . . . . . . . 23
14.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . 23 14.3.1. Value of the ARC-Seal (AS) Header . . . . . . . . . 23
14.5. Mailman 3.1+ patch . . . . . . . . . . . . . . . . . . . 24 14.3.2. DNS Overhead . . . . . . . . . . . . . . . . . . . . 23
14.6. Copernica/MailerQ web-based validation . . . . . . . . . 24 14.3.3. Distinguishing Valuable from Worthless Trace
14.7. Rspamd . . . . . . . . . . . . . . . . . . . . . . . . . 25 Information . . . . . . . . . . . . . . . . . . . . 24
14.8. PERL Mail::Milter::Authentication module . . . . . . . . 25 15. Implementation Status . . . . . . . . . . . . . . . . . . . . 24
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 15.1. GMail test reflector and incoming validation . . . . . . 25
15.1. Normative References . . . . . . . . . . . . . . . . . . 26 15.2. AOL test reflector and internal tagging . . . . . . . . 25
15.2. Informative References . . . . . . . . . . . . . . . . . 27 15.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 26
15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 29 15.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . 26
Appendix A. Appendix A - Design Requirements . . . . . . . . . . 29 15.5. Mailman 3.2 patch . . . . . . . . . . . . . . . . . . . 27
A.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 29 15.6. Copernica/MailerQ web-based validation . . . . . . . . . 27
A.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 29 15.7. Rspamd . . . . . . . . . . . . . . . . . . . . . . . . . 28
Appendix B. Appendix B - Example Usage . . . . . . . . . . . . . 29 15.8. PERL MAIL::DKIM module . . . . . . . . . . . . . . . . . 28
B.1. Example 1: Simple mailing list . . . . . . . . . . . . . 30 15.9. PERL Mail::Milter::Authentication module . . . . . . . . 29
B.1.1. Here's the message as it exits the Origin: . . . . . 30 15.10. Sympa List Manager . . . . . . . . . . . . . . . . . . . 29
B.1.2. Message is then received at example.org . . . . . . . 30 15.11. Oracle Messaging Server . . . . . . . . . . . . . . . . 30
B.1.3. Example 1: Message received by Recipient . . . . . . 32 15.12. MessageSystems Momentum . . . . . . . . . . . . . . . . 30
B.2. Example 2: Mailing list to forwarded mailbox . . . . . . 33 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
B.2.1. Here's the message as it exits the Origin: . . . . . 33 16.1. Normative References . . . . . . . . . . . . . . . . . . 30
B.2.2. Message is then received at example.org . . . . . . . 34 16.2. Informative References . . . . . . . . . . . . . . . . . 32
B.2.3. Example 2: Message received by Recipient . . . . . . 38 16.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 33
B.3. Example 3: Mailing list to forwarded mailbox with source 40 Appendix A. Appendix A - Design Requirements . . . . . . . . . . 34
B.3.1. Here's the message as it exits the Origin: . . . . . 40 A.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 34
B.3.2. Message is then received at example.org . . . . . . . 41 A.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 34
B.3.3. Example 3: Message received by Recipient . . . . . . 46 Appendix B. Appendix B - Example Usage . . . . . . . . . . . . . 34
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 48 B.1. Example 1: Simple mailing list . . . . . . . . . . . . . 34
Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 49 B.1.1. Here's the message as it exits the Origin: . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 B.1.2. Message is then received at example.org . . . . . . . 35
B.1.3. Example 1: Message received by Recipient . . . . . . 37
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.2. Message is then received at example.org . . . . . . . 39
B.2.3. Example 2: Message received by Recipient . . . . . . 43
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.2. Message is then received at example.org . . . . . . . 46
B.3.3. Example 3: Message received by Recipient . . . . . . 51
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 53
Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
1. Introduction 1. Introduction
Modern email authentication techniques such as the Sender Policy Modern email authentication techniques such as the Sender Policy
Framework (SPF) [RFC7208] and DomainKeys Identified Mail (DKIM) Framework (SPF) [RFC7208] and DomainKeys Identified Mail (DKIM)
[RFC6376] have become common. [RFC6376] have become common.
However, their end-to-end utility is limited by the effects of However, their end-to-end utility is limited by the effects of
intermediaries along the transmission path, which either are not intermediaries along the transmission path, which either are not
listed (for SPF) or which break digital signatures (for DKIM). These listed (for SPF) or which break digital signatures (for DKIM). These
issues are described in substantial detail in those protocols' issues are described in substantial detail in those protocols'
skipping to change at page 8, line 39 skipping to change at page 9, line 7
4.1.2. Optional Participation 4.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 hanndling 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) 4.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. Once broken, A message can have only one ARC chain on it at a time (see
the chain cannot be restarted, as the chain of custody is no longer Section 5.1). Once broken, the chain cannot be restarted, as the
valid and responsibility for the message has been lost. chain of custody is no longer valid and responsibility for the
message has been lost.
4.1.4. All Failures are Permanent 4.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.
skipping to change at page 9, line 45 skipping to change at page 10, line 12
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 4.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 5.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
See section Section 5.1
4.1.9. Chain Validation Status
See section Section 5.4.1
5. The ARC Header Fields 5. The ARC Header Fields
5.1. Instance ('i=') Tag 5.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. (Note that when multiple algorithms are for a given position value and signing algorithm. (Initial
supported, there is some nuance to this statement - see Section 10.) development of ARC is only being done with a single allowed signing
algorithm, but parallel work in the DCRUP working group
(https://datatracker.ietf.org/wg/dcrup/about/) 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 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 5.1.1. Valid Range for Instance Tags
skipping to change at page 11, line 30 skipping to change at page 12, line 8
The AAR, through these ptype-properties stamped in arc-info, provide The AAR, through these ptype-properties stamped in arc-info, provide
a mechanism for this information to survive transit. a mechanism for this information to survive transit.
The ptypes and properties defined in this section SHOULD be stamped The ptypes and properties defined in this section SHOULD be stamped
in the AAR: in the AAR:
o smtp.client-ip - The connecting client IP address from which the o smtp.client-ip - The connecting client IP address from which the
message is received; message is received;
o header.ds - The domain/selector pair for each DKIM signature on o header.s - Defined in [RFC6376] section 7.2
the message (header.ds=example.com,selector). Note that this is a
concatenation of the header.d and header.s field values from [[
TODO: reference DKIM A-R method spec ]] separated by the comma
character (0x2c). These values are joined into a single arc-info
field value in order to avoid indexing and correlation ambiguity
between the possible multiple DKIM signatures which may be found
on any given message;
o arc.closest-fail - The hop number of the most recent AS that fails o arc.oldest-pass - The instance number of the oldest AMS that still
to validate, or 0 if all hops pass. validates, or 0 if all pass.
5.3. ARC-Message-Signature (AMS) 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 5.1.
o There is no "v" tag. o There is no "v" tag.
skipping to change at page 13, line 30 skipping to change at page 13, line 50
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 8.3). situation where a chain has failed validation (see Section 7.1).
6. Verifier Actions 6. Verifier Actions
The verifier takes the following steps to determine the current state A verifier takes the following steps to determine the state of the
of the ARC chain on the message. 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
]] ]]
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
skipping to change at page 14, line 40 skipping to change at page 15, line 12
[RFC6376]. Pass the canonicalized result to the hash [RFC6376]. Pass the canonicalized result to the hash
function. function.
5. Retrieve the final digest from the hash function. 5. Retrieve the final digest from the hash function.
6. Retrieve the public key identified by the "s" and "d" tags in 6. Retrieve the public key identified by the "s" and "d" tags in
the ARC-Seal, as described in Section 4.1.6. the ARC-Seal, as described in Section 4.1.6.
7. Determine whether the signature portion ("b" tag) of the ARC- 7. Determine whether the signature portion ("b" tag) of the ARC-
Seal and the digest computed above are valid according to the Seal and the digest computed above are valid according to the
public key. (See also Section Section 8.4 for failure case public key. (See also Section Section 6.1 for failure case
handling) handling)
8. If the signature is not valid, the chain state is "fail" and 8. If the signature is not valid, the chain state is "fail" and
the algorithm stops here. 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 [[ Note from Dave: possibly delete the following paragraph as it is
more usage/procedural than specification guidance. more usage/procedural than specification guidance.
skipping to change at page 15, line 20 skipping to change at page 15, line 39
the WG think that this can be reasonably removed from this location? 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
DNS-based failures to verify a chain are treated no differently than
any other ARC violation. They result in a "cv=fail" verdict.
6.2. Responding to ARC Validity Violations During the SMTP Transaction
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.
7. Signer Actions 7. Signer Actions
[[ Note from Dave: This seems more like implementation guidance than [[ Note from Dave: This seems more like implementation guidance than
specification detail. KA: see explanation just above referring to specification detail. KA: see explanation just above referring to
the previous note. ]] 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:
skipping to change at page 16, line 5 skipping to change at page 16, line 39
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 5.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 5.4 above,
the chain validation status as determined in Section 6, and the chain validation status as determined in Section 6, and
instance number N+1. instance number N+1.
7.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 'i=' instance headers
created by the MTA which detected the malformed chain, as if this
newest ARC set was the only set present.
8. Usage of ARC and Chain Validity 8. Usage of ARC and Chain Validity
8.1. Relationship between DKIM-Signature and AMS signing scopes 8.1. Relationship between DKIM-Signature and AMS signing scopes
[[ SB-11: replace with "ARC MUST be the last signer of the message;
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 [[ KA: Response to Dave's concern: If DKIM covers ARC and ARC covers
DKIM, which comes first? The chicken or the egg? I'm open to DKIM, which comes first? The chicken or the egg? I'm open to
alternate ways to phrase this without opening the "modifying the DKIM alternate ways to phrase this without opening the "modifying the DKIM
spec" can of worms. ]] spec" can of worms. ]]
8.2. Assessing Chain Validity Violations 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
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.
8.3. 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 'i=' instance headers
created by the MTA which detected the malformed chain, as if this
newest ARC set was the only set present.
8.4. 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.
8.5. Responding to ARC Validity Violations
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.
9. Recording and Reporting the Results of ARC Evaluation 9. 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 9.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
skipping to change at page 18, line 27 skipping to change at page 19, line 10
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 10. Supporting Alternate Signing Algorithms
[[ Note: Some additional development of this section is needed. ]] This section has been moved to [ARC-MULTI]
In the following branch diagrams, each algorithm is represented by an 11. Privacy Considerations
'A' or 'B' at each hop to depict the ARC chain that develops over a
five hop scenario. 'x' represents a hop that does not support that
algorithm.
Note that during a transitional period where multiple algorithms are The ARC chain provides a verifiable record of the handlers for a
allowed, all of the statements in this spec which refer to "exactly message. Anonymous remailers will probably not find this compatible
one set of ARC headers per instance" need to be understood as "at with their operating goals.
least one set per instance and no more than one instance-set per
algorithm".
10.1. Introductory Period 12. IANA Considerations
Intermediaries MUST be able to validate ARC chains built with either This specification adds three new header fields as defined below.
algorithm but MAY create ARC sets with either (or both) algorithm.
The introductory period should be at least six (6) months. 12.1. Authentication-Results Method Registry Update
10.2. Co-Existence Period This draft adds one item to the IANA "Email Authentication Methods"
registry:
Intermediaries MUST be able to validate ARC chains build with either o Method : arc
algorithm and MUST create ARC sets with both algorithms. Chains
ending with either algorithm may be used for the result.
10.3. Deprecation Period Defined: [I-D.ARC]
ARC sets built with algorithms that are being deprecated MAY be ptype: header
considered valid within an ARC chain, however, intermediaries MUST
NOT create additional sets with the deprecated algorithm.
The deprecation period should be at least two (2) years. Property: chain evaluation result
10.4. Obsolescence Period Value: chain evaluation result status (see Section 5.4)
ARC sets built with algorithms that are obsolete MUST NOT be Status: active
considered valid within an ARC chain. Intermediaries MUST NOT create
any sets with any obsoleted algorithm.
11. Privacy Considerations Version: 1
The ARC chain provides a verifiable record of the handlers for a o Method : dkim
message. Anonymous remailers will probably not find this compatible
with their operating goals.
12. IANA Considerations Defined: [I-D.ARC]
This specification adds three new header fields as defined below. ptype: header
12.1. Authentication-Results Method Registry Update Property: selector
This draft adds one item to the IANA "Email Authentication Methods" Value: value of signature "s" tag (see [RFC6376])
registry:
Status: active
Version: 1
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
Version: 1
o Method : arc o Method : arc
Defined: [I-D.ARC] Defined: [I-D.ARC]
ptype: header ptype: header
Property: chain evaluation result Property: oldest-pass
Value: chain evaluation result status (see Section 5.4) 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 12.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:
skipping to change at page 21, line 34 skipping to change at page 22, line 20
13.3. Message Content Suspicion 13.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).
14. Implementation Status 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.
14. Evaluating the Efficacy of the ARC Protocol
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.
14.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
DMARC processing when the DKIM d= value is aligned with the
rfc5322.From author domain.
14.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 13) 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.
14.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.
14.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.
14.3.2. DNS Overhead
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 13.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.
14.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
the value-add of having intermediary-handled mail flow information
added into the DMARC reports going back to senders.
Certain receivers believe the entire set of trace information would
be valuable to feed into machine learning systems to identify fraud
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
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.
15. Implementation Status
[[ Note: For minimizing section number references when the RFC editor [[ Note: For minimizing section number references when the RFC editor
removes this section, it has been moved to be the last section of the removes this section, it has been moved to be the last section of the
document before the Appendicies. ]] 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
skipping to change at page 22, line 11 skipping to change at page 25, line 13
has been spent to verify the information presented here that was has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may features. Readers are advised to note that other implementations may
exist. exist.
This information is known to be correct as of the seventh This information is known to be correct as of the 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.
14.1. GMail test reflector and incoming validation For a few of the implementations, later status information was
available as of December 2017.
15.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 [1]
14.2. AOL test reflector and internal tagging 15.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
skipping to change at page 23, line 5 skipping to change at page 26, line 10
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 [2]
14.3. dkimpy 15.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] (https://github.com/ValiMail/arc_test_suite) 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
14.4. OpenARC 15.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-06] Coverage: Built to support [ARC-DRAFT-10]
Licensing: Open/Other (same as OpenDKIM and OpenDMARC packages) Licensing: Open/Other (same as OpenDKIM and OpenDMARC packages)
Implementation Notes: Implementation Notes:
o The build is FreeBSD oriented but some packages have been built o The build is FreeBSD oriented but some packages have been built
for easier deployment on RedHat-based Linux platforms. for easier deployment on RedHat-based Linux platforms.
o 2017-07-15: Testing showed problems with the hash calculation for
the AMS header b= field. Several other bugs were discovered and
were either fixed during the following week of IETF meetings or
are under active repair.
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. (signer) instances. (_NOTE_: this is expected to resolved with a
new release of OpenDMARC expected in January 2018.)
Contact Info: arc-discuss@dmarc.org [3] Contact Info: arc-discuss@dmarc.org [3]
14.5. Mailman 3.1+ patch 15.5. Mailman 3.2 patch
Organization: Mailman development team Organization: Mailman development team
Description: Integrated ARC capabilities within the Mailman 3.1+ Description: Integrated ARC capabilities within the Mailman 3.2
package package
Status of Operation: Patch submitted Status of Operation: Patch submitted
Coverage: Unknown 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
14.6. Copernica/MailerQ web-based validation 15.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
skipping to change at page 25, line 10 skipping to change at page 28, line 10
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/
14.7. Rspamd 15.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 25, line 33 skipping to change at page 28, line 33
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
14.8. PERL Mail::Milter::Authentication module 15.8. PERL MAIL::DKIM module
Organization: FastMail Organization: FastMail
Description: Email domain authentication milter, previously included Description: Email domain authentication (sign and/or verify) module,
SPF / DKIM / DMARC, now has ARC added 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/
15.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 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]
Licensing: Open Source Licensing: Open Source
Implementation Notes: Implementation Notes:
o 2017-07-15: Validation functionality which interoperates with o 2017-07-15: Validation functionality which interoperates with
Gmail, AOL, dkimpy was demonstrated; later in the week of IETF99, Gmail, AOL, dkimpy was demonstrated; later in the week of IETF99,
the signing functionality was reported to be working the signing functionality was reported to be working
o 2017-07-20: ARC functionality has not yet been pushed back to the o 2017-07-20: ARC functionality has not yet been pushed back to the
github repo but should be showing up soon github repo but should be showing up soon
Contact Info: https://github.com/fastmail/authentication_milter Contact Info: https://github.com/fastmail/authentication_milter
15. References 15.10. Sympa List Manager
15.1. Normative References 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
15.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]
Licensing: Unknown
Implementation Notes:
o Status since the work done in July 2017 is unknown.
Contact Info:
15.12. MessageSystems Momentum
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 early 2018.
Contact Info:
16. References
16.1. Normative References
[RFC1345] Simonsen, K., "Character Mnemonics and Character Sets", [RFC1345] Simonsen, K., "Character Mnemonics and Character Sets",
RFC 1345, DOI 10.17487/RFC1345, June 1992, RFC 1345, DOI 10.17487/RFC1345, June 1992,
<https://www.rfc-editor.org/info/rfc1345>. <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>.
skipping to change at page 27, line 48 skipping to change at page 32, line 35
[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>.
15.2. Informative References 16.2. Informative References
[ARC-DRAFT-05] [ARC-DRAFT-05]
Andersen, K., Long, B., and S. Jones, "Authenticated Andersen, K., "Authenticated Received Chain (ARC) Protocol
Received Chain (ARC) Protocol (I-D-06)", n.d., (I-D-05)", n.d., <https://tools.ietf.org/html/
<https://tools.ietf.org/html/ draft-ietf-dmarc-arc-protocol-05>.
draft-ietf-dmarc-arc-protocol-06>.
[ARC-DRAFT-06] [ARC-DRAFT-06]
Andersen, K., Long, B., and S. Jones, "Authenticated Andersen, K., "Authenticated Received Chain (ARC) Protocol
Received Chain (ARC) Protocol (I-D-05)", n.d., (I-D-06)", n.d., <https://tools.ietf.org/html/
<https://tools.ietf.org/html/ draft-ietf-dmarc-arc-protocol-06>.
draft-ietf-dmarc-arc-protocol-05>.
[ARC-DRAFT-10]
Andersen, K., "Authenticated Received Chain (ARC) Protocol
(I-D-10)", n.d., <https://tools.ietf.org/html/
draft-ietf-dmarc-arc-protocol-10>.
[ARC-MULTI]
Andersen, K., "Using Multiple Signing Algorithms with
ARC", January 2018, <https://tools.ietf.org/html/
draft-ietf-dmarc-arc-multi-01>.
[ARC-TEST] [ARC-TEST]
Blank, S., "ARC Test Suite", January 2017, Blank, S., "ARC Test Suite", January 2017,
<https://github.com/ValiMail/arc_test_suite>. <https://github.com/ValiMail/arc_test_suite>.
[ARC-USAGE] [ARC-USAGE]
Jones, S., Adams, T., Rae-Grant, J., and K. Andersen, Jones, S., Adams, T., Rae-Grant, J., and K. Andersen,
"Recommended Usage of the ARC Headers", December 2017, "Recommended Usage of the ARC Headers", December 2017,
<https://tools.ietf.org/html/ <https://tools.ietf.org/html/
draft-ietf-dmarc-arc-usage-01>. draft-ietf-dmarc-arc-usage-01>.
skipping to change at page 29, line 5 skipping to change at page 33, line 42
(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>.
15.3. URIs 16.3. URIs
[1] mailto:arc-discuss@dmarc.org [1] mailto:arc-discuss@dmarc.org
[2] mailto:arc-discuss@dmarc.org [2] mailto:arc-discuss@dmarc.org
[3] mailto:arc-discuss@dmarc.org [3] mailto:arc-discuss@dmarc.org
[4] mailto:dmarc@ietf.org [4] mailto:dmarc@ietf.org
[5] mailto:arc-discuss@dmarc.org [5] mailto:arc-discuss@dmarc.org
skipping to change at line 2235 skipping to change at page 54, line 35
Steven Jones (editor) Steven Jones (editor)
TDP TDP
Email: smj@crash.com Email: smj@crash.com
Seth Blank (editor) Seth Blank (editor)
ValiMail ValiMail
Email: seth@valimail.com Email: seth@valimail.com
Murray Kucherawy (editor)
TDP
Email: superuser@gmail.com
 End of changes. 73 change blocks. 
174 lines changed or deleted 400 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/