draft-ietf-dmarc-arc-protocol-12.txt   draft-ietf-dmarc-arc-protocol-13.txt 
DMARC Working Group K. Andersen DMARC Working Group K. Andersen
Internet-Draft LinkedIn Internet-Draft LinkedIn
Intended status: Experimental B. Long, Ed. Intended status: Experimental B. Long, Ed.
Expires: September 19, 2018 Google Expires: September 22, 2018 Google
S. Jones, Ed. S. Jones, Ed.
TDP TDP
S. Blank, Ed. S. Blank, Ed.
ValiMail ValiMail
M. Kucherawy, Ed. M. Kucherawy, Ed.
TDP TDP
March 18, 2018 March 21, 2018
Authenticated Received Chain (ARC) Protocol Authenticated Received Chain (ARC) Protocol
draft-ietf-dmarc-arc-protocol-12 draft-ietf-dmarc-arc-protocol-13
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 create an attached, authenticated record way to its destination, and create an attached, authenticated record
of the status at each step along the handling path, for use by the of the status at each step along the handling path, for use by the
final recipient in making choices about the disposition of the final recipient in making choices about the disposition of the
message. Changes in the message that might break existing message. Changes in the message that might break existing
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 September 19, 2018. This Internet-Draft will expire on September 22, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1.1. High Level Summary . . . . . . . . . . . . . . . . . 5 1.1.1. High Level Summary . . . . . . . . . . . . . . . . . 5
1.1.2. Technical Summary . . . . . . . . . . . . . . . . . . 7 1.1.2. Technical Summary . . . . . . . . . . . . . . . . . . 7
1.2. Definitions and Terminology . . . . . . . . . . . . . . . 7 1.2. Definitions and Terminology . . . . . . . . . . . . . . . 7
1.3. Referenced Definitions . . . . . . . . . . . . . . . . . 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. Protocol Elements and Features . . . . . . . . . . . . . . . 8
2.1. Features of the ARC Protocol . . . . . . . . . . . . . . 8 2.1. Features of the ARC Protocol . . . . . . . . . . . . . . 9
2.1.1. Chain of Custody . . . . . . . . . . . . . . . . . . 9 2.1.1. Chain of Custody . . . . . . . . . . . . . . . . . . 9
2.1.2. Optional Participation . . . . . . . . . . . . . . . 9 2.1.2. Optional Participation . . . . . . . . . . . . . . . 10
2.1.3. Only one ARC Chain (One Chain to Rule Them All) . . . 9 2.1.3. Only one ARC Chain (One Chain to Rule Them All) . . . 10
2.1.4. All Failures are Permanent . . . . . . . . . . . . . 10 2.1.4. All Failures are Permanent . . . . . . . . . . . . . 10
2.1.5. Benign nature of an ARC Set . . . . . . . . . . . . . 10 2.1.5. Benign nature of an ARC Set . . . . . . . . . . . . . 10
2.1.6. Key Management . . . . . . . . . . . . . . . . . . . 10 2.1.6. Key Management . . . . . . . . . . . . . . . . . . . 11
2.1.7. Trace Information . . . . . . . . . . . . . . . . . . 11 2.1.7. Trace Information . . . . . . . . . . . . . . . . . . 11
2.1.8. Instance Tags . . . . . . . . . . . . . . . . . . . . 11 2.1.8. Instance Tags . . . . . . . . . . . . . . . . . . . . 11
2.1.9. Chain Validation Status . . . . . . . . . . . . . . . 11 2.1.9. Chain Validation Status . . . . . . . . . . . . . . . 11
3. The ARC Header Fields . . . . . . . . . . . . . . . . . . . . 11 3. The ARC Header Fields . . . . . . . . . . . . . . . . . . . . 11
3.1. Instance ('i=') Tag . . . . . . . . . . . . . . . . . . . 11 3.1. Instance ('i=') Tag . . . . . . . . . . . . . . . . . . . 11
3.1.1. Valid Range for Instance Tags . . . . . . . . . . . . 12 3.1.1. Valid Range for Instance Tags . . . . . . . . . . . . 12
3.2. ARC-Authentication-Results (AAR) . . . . . . . . . . . . 12 3.2. ARC-Authentication-Results (AAR) . . . . . . . . . . . . 12
3.3. ARC-Message-Signature (AMS) . . . . . . . . . . . . . . . 12 3.3. ARC-Message-Signature (AMS) . . . . . . . . . . . . . . . 13
3.4. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . . . 13 3.4. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . . . 13
3.4.1. The 'cv' Tag . . . . . . . . . . . . . . . . . . . . 13 3.4.1. The 'cv' Tag . . . . . . . . . . . . . . . . . . . . 14
3.4.2. Implicit Header Fields . . . . . . . . . . . . . . . 14 3.4.2. Implicit Header Fields . . . . . . . . . . . . . . . 14
4. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . 14 4. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . 14
4.1. ARC Authentication-Results Stamp . . . . . . . . . . . . 16 4.1. ARC Authentication-Results Information . . . . . . . . . 16
4.2. Handling DNS Problems While Validating ARC . . . . . . . 16 4.2. Handling DNS Problems While Validating ARC . . . . . . . 16
4.3. Responding to ARC Validity Violations During the SMTP 4.3. Responding to ARC Validity Violations During the SMTP
Transaction . . . . . . . . . . . . . . . . . . . . . . . 16 Transaction . . . . . . . . . . . . . . . . . . . . . . . 17
5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . 16
5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Marking and Sealing "cv=fail" (Invalid) Chains . . . . . 17 5.1. Marking and Sealing "cv=fail" (Invalid) Chains . . . . . 17
6. Usage of ARC and Chain Validity . . . . . . . . . . . . . . . 17 6. Usage of ARC and Chain Validity . . . . . . . . . . . . . . . 18
6.1. Relationship between DKIM-Signature and AMS signing 6.1. Relationship between DKIM-Signature and AMS signing
scopes . . . . . . . . . . . . . . . . . . . . . . . . . 17 scopes . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.2. Assessing Chain Validity Violations . . . . . . . . . . . 17 6.2. Assessing Chain Validity Violations . . . . . . . . . . . 18
7. Recording and Reporting the Results of ARC Evaluation . . . . 18 7. Recording and Reporting the Results of ARC Evaluation . . . . 18
7.1. Information from an ARC Evaluation . . . . . . . . . . . 18 7.1. Information from an ARC Evaluation . . . . . . . . . . . 18
7.2. Recording (local) ARC Evaluation Results . . . . . . . . 18 7.2. Recording (local) ARC Evaluation Results . . . . . . . . 19
7.3. DMARC Reporting of ARC Findings - Interim . . . . . . . . 18 7.3. DMARC Reporting of ARC Findings - Interim . . . . . . . . 19
8. Supporting Alternate Signing Algorithms . . . . . . . . . . . 19 8. Supporting Alternate Signing Algorithms . . . . . . . . . . . 19
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10.1. Authentication-Results Method Registry Update . . . . . 19 10.1. Authentication-Results Method Registry Update . . . . . 20
10.2. Definitions of the ARC header fields . . . . . . . . . . 21 10.2. Definitions of the ARC header fields . . . . . . . . . . 21
11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22
11.1. Header Size . . . . . . . . . . . . . . . . . . . . . . 22 11.1. Header Size . . . . . . . . . . . . . . . . . . . . . . 22
11.2. DNS Operations . . . . . . . . . . . . . . . . . . . . . 22 11.2. DNS Operations . . . . . . . . . . . . . . . . . . . . . 22
11.3. Message Content Suspicion . . . . . . . . . . . . . . . 22 11.3. Message Content Suspicion . . . . . . . . . . . . . . . 22
12. Evaluating the Efficacy of the ARC Protocol . . . . . . . . . 23 12. Evaluating the Efficacy of the ARC Protocol . . . . . . . . . 23
12.1. Success Consideration . . . . . . . . . . . . . . . . . 23 12.1. Success Consideration . . . . . . . . . . . . . . . . . 23
12.2. Failure Considerations . . . . . . . . . . . . . . . . . 23 12.2. Failure Considerations . . . . . . . . . . . . . . . . . 24
12.3. Open Questions . . . . . . . . . . . . . . . . . . . . . 23 12.3. Open Questions . . . . . . . . . . . . . . . . . . . . . 24
12.3.1. Value of the ARC-Seal (AS) Header . . . . . . . . . 24 12.3.1. Value of the ARC-Seal (AS) Header . . . . . . . . . 24
12.3.2. DNS Overhead . . . . . . . . . . . . . . . . . . . . 24 12.3.2. DNS Overhead . . . . . . . . . . . . . . . . . . . . 24
12.3.3. Distinguishing Valuable from Worthless Trace 12.3.3. Distinguishing Valuable from Worthless Trace
Information . . . . . . . . . . . . . . . . . . . . 24 Information . . . . . . . . . . . . . . . . . . . . 24
13. Implementation Status . . . . . . . . . . . . . . . . . . . . 25 13. Implementation Status . . . . . . . . . . . . . . . . . . . . 25
13.1. GMail test reflector and incoming validation . . . . . . 25 13.1. GMail test reflector and incoming validation . . . . . . 26
13.2. AOL test reflector and internal tagging . . . . . . . . 26 13.2. AOL test reflector and internal tagging . . . . . . . . 26
13.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 26 13.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 26
13.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . 26 13.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . 27
13.5. Mailman 3.2 patch . . . . . . . . . . . . . . . . . . . 27 13.5. Mailman 3.2 patch . . . . . . . . . . . . . . . . . . . 27
13.6. Copernica/MailerQ web-based validation . . . . . . . . . 27 13.6. Copernica/MailerQ web-based validation . . . . . . . . . 28
13.7. Rspamd . . . . . . . . . . . . . . . . . . . . . . . . . 28 13.7. Rspamd . . . . . . . . . . . . . . . . . . . . . . . . . 28
13.8. PERL MAIL::DKIM module . . . . . . . . . . . . . . . . . 29 13.8. PERL MAIL::DKIM module . . . . . . . . . . . . . . . . . 29
13.9. PERL Mail::Milter::Authentication module . . . . . . . . 29 13.9. PERL Mail::Milter::Authentication module . . . . . . . . 29
13.10. Sympa List Manager . . . . . . . . . . . . . . . . . . . 30 13.10. Sympa List Manager . . . . . . . . . . . . . . . . . . . 30
13.11. Oracle Messaging Server . . . . . . . . . . . . . . . . 30 13.11. Oracle Messaging Server . . . . . . . . . . . . . . . . 30
13.12. MessageSystems Momentum . . . . . . . . . . . . . . . . 30 13.12. MessageSystems Momentum . . . . . . . . . . . . . . . . 31
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
14.1. Normative References . . . . . . . . . . . . . . . . . . 31 14.1. Normative References . . . . . . . . . . . . . . . . . . 31
14.2. Informative References . . . . . . . . . . . . . . . . . 32 14.2. Informative References . . . . . . . . . . . . . . . . . 32
14.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 33 14.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Appendix A. Appendix A - Design Requirements . . . . . . . . . . 34 Appendix A. Appendix A - Design Requirements . . . . . . . . . . 34
A.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 34 A.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 34
A.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 34 A.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 35
Appendix B. Appendix B - Example Usage . . . . . . . . . . . . . 34 Appendix B. Appendix B - Example Usage . . . . . . . . . . . . . 35
B.1. Example 1: Simple mailing list . . . . . . . . . . . . . 35 B.1. Example 1: Simple mailing list . . . . . . . . . . . . . 35
B.1.1. Here's the message as it exits the Origin: . . . . . 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.2. Message is then received at example.org . . . . . . . 35
B.1.3. Example 1: Message received by Recipient . . . . . . 37 B.1.3. Example 1: Message received by Recipient . . . . . . 38
B.2. Example 2: Mailing list to forwarded mailbox . . . . . . 38 B.2. Example 2: Mailing list to forwarded mailbox . . . . . . 39
B.2.1. Here's the message as it exits the Origin: . . . . . 38 B.2.1. Here's the message as it exits the Origin: . . . . . 39
B.2.2. Message is then received at example.org . . . . . . . 39 B.2.2. Message is then received at example.org . . . . . . . 40
B.2.3. Example 2: Message received by Recipient . . . . . . 43 B.2.3. Example 2: Message received by Recipient . . . . . . 44
B.3. Example 3: Mailing list to forwarded mailbox with source 45 B.3. Example 3: Mailing list to forwarded mailbox with source 46
B.3.1. Here's the message as it exits the Origin: . . . . . 45 B.3.1. Here's the message as it exits the Origin: . . . . . 46
B.3.2. Message is then received at example.org . . . . . . . 46 B.3.2. Message is then received at example.org . . . . . . . 47
B.3.3. Example 3: Message received by Recipient . . . . . . 51 B.3.3. Example 3: Message received by Recipient . . . . . . 52
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 53 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 54
Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 54 Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55
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
However, their end-to-end utility is limited by the effects of limited by the effects of intermediaries along the transmission path,
intermediaries along the transmission path, which either are not which either are not listed (for SPF) or which break digital
listed (for SPF) or which break digital signatures (for DKIM). These signatures (for DKIM). These issues are described in substantial
issues are described in substantial detail in those protocols' detail in those protocols' defining documents as well as in [RFC6377]
defining documents as well as in [RFC6377] and [RFC7960]. and [RFC7960].
Technologies that build upon the use of SPF and DKIM can reduce the Technologies that build upon the use of SPF and DKIM can reduce the
success of fraudulent email campaigns. To this end, Domain-based success of fraudulent email campaigns. To this end, Domain-based
Mail Authentication, Reporting and Compliance (DMARC) [RFC7489], Mail Authentication, Reporting and Compliance (DMARC) [RFC7489],
validates the domain of the RFC5322.From author header field. validates the domain of the RFC5322.From author header field.
However its use along email transmission paths that have independent However its use along email transmission paths that have independent
intermediaries, such as some forwarders and essentially all mailing intermediaries, such as some forwarders and essentially all mailing
list services, produces false positive rejections that are list services, produces false positive rejections that are
problematic, both for the message authors, the intermediary problematic, both for the message authors, the intermediary
service(s), and for those they are interacting with. service(s), and for those they are interacting with.
What is needed is a mechanism by which legitimate alteration of a What is needed is a mechanism by which legitimate alteration of a
message, which invalidates associated SPF and DKIM information, does message, which invalidates associated SPF and DKIM information, does
not ultimately result in a rejection of an email message on delivery. not ultimately result in a rejection of an email message on delivery.
Authenticated Receive Chain (ARC) builds upon DKIM mechanisms to Authenticated Receive Chain (ARC) builds upon DKIM mechanisms to
provide a sequence of signatures that provide a view of the handling provide a sequence of signatures that provide a view of the handling
sequence for a message, especially the points where alterations of sequence for a message, especially the points where alterations of
the content might have occurred. Equipped with this more complete the content might have occurred. Equipped with this more complete
information, the recipient system(s) can make a more informed information, the recipient system(s) can make a more informed
handling choice, reducing or eliminating the false negatives inherent handling choice, reducing or eliminating the rejections that would
in use of DKIM and/or SPF themselves. occur with the use of DKIM and/or SPF alone.
1.1. Overview 1.1. Overview
ARC provides a "chain of custody" for a message, allowing each entity ARC provides a "chain of custody" for a message, allowing each entity
that handles the message to see what entities handled it before, and 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 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 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. the chain of custody and then relay the message to the next handler.
When the message reaches final delivery, the decision to accept and When the message reaches final delivery, the decision to accept and
skipping to change at page 5, line 31 skipping to change at page 5, line 31
2. The mailing list modifies the message by prepending the list name 2. The mailing list modifies the message by prepending the list name
to the subject line, then sends it to the subscribers; to the subject line, then sends it to the subscribers;
3. One of the subscribers is alice@mail.service.example, which 3. One of the subscribers is alice@mail.service.example, which
receives the message from listmania.example. receives the message from listmania.example.
Assuming the original message was DKIM-signed and mysender.example Assuming the original message was DKIM-signed and mysender.example
published an SPF record, the handling by the mailing list will break published an SPF record, the handling by the mailing list will break
the DKIM signature because of the message modification, and the the DKIM signature because of the message modification, and the
forwarding will cause SPF check to fail in the next step. But forwarding will cause the SPF check to fail in the next step. But
listmania.example can add ARC headers to the message to add itself to listmania.example can add ARC headers to the message to add itself to
the document's chain of custody. When mail.service.example sees the 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 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 also see that both of these succeeded when they were checked by
listmania.example, and can verify listmania's assertion. listmania.example, and can verify listmania's assertion.
As part of its evaluation of the message for delivery, As part of its evaluation of the message for delivery,
mail.service.example can see that mysender.example publishes a DMARC mail.service.example can see that mysender.example publishes a DMARC
policy asking that unauthenticated messages be rejected. But is can policy asking that unauthenticated messages be rejected. But is can
also see the assertion by listmania.example that the message was also see the assertion by listmania.example that the message was
correctly authenticated when the message arrived there, and if it correctly authenticated when the message arrived there, and if it
accepts that assertion and that modifications made were benign, it accepts that assertion and that modifications made were benign, it
can deliver the message, rather than reject it, based on the can deliver the message, rather than reject it, based on the
additional information that ARC has provided. additional information that ARC has provided.
1.1.1. High Level Summary 1.1.1. High Level Summary
In DKIM, every participating signing agent attaches a signature that In DKIM, every participating signing agent attaches a signature that
is based on the some of the content of the message, local policy, and is based on the some of the content of the message, local policy, and
the domain name of the participating Administrative Management Domain the domain name of the signing agent's Administrative Management
(ADMD). Any verifier can process such a signature; a verified Domain (ADMD). Any verifier can process such a signature; a verified
signature means that the domain referenced in the DKIM's "d=" signature means that the domain referenced in the signature's "d="
parameter has some responsibility for handling the message. An parameter has some responsibility for handling the message. An
artifact of using digital signature technology for this means that artifact of using digital signature technology for this means that
verification also ensures that the portion of the message that was verification also ensures that the portion of the message that was
"covered" by the signature has not been altered since the signature "covered" by the signature has not been altered since the signature
was applied. The signatures themselves are generally independent of was applied. The signatures themselves are generally independent of
one another. one another.
By contrast, an ARC signature conveys the following pieces of In contrast, a validated ARC signature conveys the following pieces
information: of information:
1. An assertion that, at the time that the intermediary ADMD 1. An assertion that, at the time that the intermediary ADMD
processed the message, the various assertions (DKIM-Signature(s) processed the message, the various assertions (SPF, DKIM-
and/or ARC sets) already attached to the message by other ADMDs Signature(s) and/or ARC sets) already attached to the message by
were or were not valid; other ADMDs were or were not valid;
2. As with DKIM, an assertion that, for a validated ARC signature, 2. As with DKIM, an assertion that, for a validated ARC signature,
the domain name in the signature takes some responsibility for the domain name in the signature takes some responsibility for
handling of the message and that the message is unchanged since handling of the message and that the covered content of message
that signature was applied; is unchanged since that signature was applied;
3. A further assertion that binds the ARC evaluation results into 3. A further assertion that binds the ARC evaluation results into
the ARC chain sequence. the ARC chain sequence.
This protocol accomplishes each of these by adding new header fields The ARC protocol accomplishes this by adding an "ARC Set" of three
to the message with these pieces of information: new header fields to the message as follows:
o ARC-Authentication-Results (referred to below as "AAR"): virtually 1. ARC-Authentication-Results (referred to below as "AAR"):
identical in syntax to an Authentication-Results field [RFC7601], virtually identical in syntax to an Authentication-Results field
this field records the results of all message authentication [RFC7601], this field records the results of all message
checks done by the recording ADMD at the time the message arrived. authentication checks done by the recording ADMD at the time the
Additional information is placed in this field compared to a message arrived. Additional information is placed in this field
standard Authentication-Results field in order to support a more compared to a standard Authentication-Results field in order to
complete DMARC report (see Section 3.2); support a more complete DMARC report (see Section 3.2);
o ARC-Message-Signature (referred to below as "AMS"): virtually 2. ARC-Message-Signature (referred to below as "AMS"): virtually
identical in syntax to DKIM-Signature, this field contains the identical in syntax to DKIM-Signature, this field contains the
signature about the message header and body as they existed at the signature about the message header and body as they existed at
time of handling by the ADMD adding it; and the time of handling by the ADMD adding it (including any
modifications made by the sealing ADMD); and
o ARC-Seal (referred to below as "AS"): highly similar in structure 3. ARC-Seal (referred to below as "AS"): highly similar in structure
and format to a DKIM-Signature, this field applies a digital and format to a DKIM-Signature, this field applies a digital
signature that protects the integrity of all three of these new signature that protects the integrity of all three of these new
fields when they are added by an ADMD, plus all instances of these fields when they are added by an ADMD, plus all instances of
fields added by prior ADMDs. these fields added by prior ADMDs.
A distinguishing feature of all of these is that an ARC participant An ARC participant always adds all of these header fields before
always adds all of them before relaying a message to the next relaying a message to the next handling agent _en route_ to its
handling agent en route to its destination. Moreover, as described destination. Moreover, as described in Section 3.1, they each have
in Section 3.1, they each have an "instance" number that increases an "instance number" that increases with each ADMD in the handling
with each ADMD in the handling chain so that their original order can chain so that their original order can be preserved and the three
be preserved and the three related header fields can be processed as related header fields can be processed as a set.
a group.
1.1.2. Technical Summary 1.1.2. Technical Summary
[[ possibly including a diagram - this may not be needed any more ]] [[ possibly including a diagram - this may not be needed any more ]]
1.2. Definitions and Terminology 1.2. Definitions and Terminology
This section defines terms used in the rest of the document. This section defines terms used in the rest of the document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119][RFC8174]. "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 Because many of the core concepts and definitions are found in
[RFC5598], readers SHOULD to be familiar with the contents of [RFC5598], readers should to be familiar with the contents of
[RFC5598], and in particular, the potential roles of intermediaries [RFC5598], and in particular, the potential roles of intermediaries
in the delivery of email. in the delivery of email.
Syntax descriptions use Augmented BNF (ABNF) [RFC5234]. Syntax descriptions use Augmented BNF (ABNF) [RFC5234].
o "ARC set" - A single group of the header fields introduced in 1.2.1. Terms defined and used in this document
Section 1.1 is called an "ARC set".
o "ARC chain" - The complete sequence of these groups (ARC sets) is o "ARC-Authentication-Results" (AAR) - an ARC header field described
called an "ARC chain". Although the "Received" header field is in Section 3.2.
typically not included in the signed content, the name is based on
the notion that this is in essence a cryptographically signed
series of header fields that attest to the handling chain of a
message much as Received fields always have.
1.3. Referenced Definitions 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".
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
that handled the message.
1.2.2. Referenced Definitions
The following terms are defined in other RFCs. Those definitions can The following terms are defined in other RFCs. Those definitions can
be found as follows: be found as follows:
o ADMD - [RFC5598], Section 2.3 o ADMD - [RFC5598], Section 2.3
o MTA - [RFC5598], Section 4.3.2 o MTA - [RFC5598], Section 4.3.2
o MSA - [RFC5598], Section 4.3.1 o MSA - [RFC5598], Section 4.3.1
skipping to change at page 16, line 8 skipping to change at page 16, line 21
[[ See issue 12 [4] regarding the final paragraph ]] [[ See issue 12 [4] regarding the final paragraph ]]
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.
4.1. ARC Authentication-Results Stamp 4.1. ARC Authentication-Results Information
Certain information pertinent to ascertaining message disposition can Certain information pertinent to ascertaining message disposition can
be lost in transit when messages are handled by intermediaries. For be lost in transit when messages are handled by intermediaries. For
example, failing DKIM signatures are sometimes removed by MTAs, and example, failing DKIM signatures are sometimes removed by MTAs, and
most DKIM signatures on messages modified by intermediaries will most DKIM signatures on messages modified by intermediaries will
fail. Stamping the following information in the A-R provides a fail. Recording the following information in the A-R provides a
mechanism for this information to survive transit. mechanism for this information to survive transit.
The ptypes and properties defined in this section SHOULD be recorded The ptypes and properties defined in this section SHOULD be recorded
in the AR: in the AR:
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.s - Defined in [RFC6376] section 7.2 o header.s - Defined in [RFC6376] section 7.2
o arc.oldest-pass - The instance number of the oldest AMS that still o arc.oldest-pass - The instance number of the oldest AMS that still
validates, or 0 if all pass. 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.
]]
4.2. Handling DNS Problems While Validating ARC 4.2. Handling DNS Problems While Validating ARC
DNS-based failures to verify a chain are treated no differently than DNS-based failures to verify a chain are treated no differently than
any other ARC violation. They result in a "cv=fail" verdict. any other ARC violation. They result in a "cv=fail" verdict.
4.3. Responding to ARC Validity Violations During the SMTP Transaction 4.3. Responding to ARC Validity Violations During the SMTP Transaction
If a receiver determines that the ARC chain has failed, the receiver If a receiver determines that the ARC chain has failed, the receiver
MAY signal the breakage through the extended SMTP response code 5.7.7 MAY signal the breakage through the extended SMTP response code 5.7.7
[RFC3463] "message integrity failure" [ENHANCED-STATUS] and [RFC3463] "message integrity failure" [ENHANCED-STATUS] and
corresponding SMTP response code. corresponding SMTP response code.
5. Signer Actions 5. Signer Actions
[[ See issue 13 [5] for critique ]] [[ See issue 13 [7] for critique ]]
This section includes a specification of the actions an ARC signer This section includes a specification of the actions an ARC signer
takes when presented with a message. takes when presented with a message.
The signer MUST undertake the following steps: The signer MUST undertake the following steps:
1. Before creating an ARC signature, perform any other, normal 1. Before creating an ARC signature, perform any other, normal
authentication and/or signing, so that the ARC signature can authentication and/or signing, so that the ARC signature can
cover those results. cover those results.
skipping to change at page 17, line 27 skipping to change at page 17, line 47
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 3.4 above, using the general algorithm described in Section 3.4 above,
the chain validation status as determined in Section 4, and the chain validation status as determined in Section 4, and
instance number N+1. instance number N+1.
5.1. Marking and Sealing "cv=fail" (Invalid) Chains 5.1. Marking and Sealing "cv=fail" (Invalid) Chains
The header fields signed by the AS header field b= value in the case The header fields signed by the AS header field b= value in the case
of a chain failure MUST be only the matching 'i=' instance headers of a chain failure MUST be only the matching instance headers created
created by the MTA which detected the malformed chain, as if this by the MTA which detected the malformed chain, as if this newest ARC
newest ARC set was the only set present. set was the only set present.
6. Usage of ARC and Chain Validity 6. Usage of ARC and Chain Validity
6.1. Relationship between DKIM-Signature and AMS signing scopes 6.1. Relationship between DKIM-Signature and AMS signing scopes
[[ See issue 14 [6] for critique of this section ]] [[ See issue 14 [8] for critique of this section ]]
DKIM-Signatures SHOULD never sign any ARC header fields. DKIM-Signatures SHOULD never sign any ARC header fields.
6.2. Assessing Chain Validity Violations 6.2. Assessing Chain Validity Violations
[[ Issue 15 [7] ]] [[ Issue 15 [9] ]]
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
skipping to change at page 18, line 41 skipping to change at page 19, line 16
Receivers MAY add an "arc=[pass|fail|policy]" method annotation into Receivers MAY add an "arc=[pass|fail|policy]" method annotation into
a locally-affixed Authentication-Results [RFC7601] header field along a locally-affixed Authentication-Results [RFC7601] header field along
with any salient comment(s). with any salient comment(s).
Details of the ARC chain which was evaluated should be included in Details of the ARC chain which was evaluated should be included in
the Authentication-Results and AAR headers per Section Section 4.1. the Authentication-Results and AAR headers per Section Section 4.1.
7.3. DMARC Reporting of ARC Findings - Interim 7.3. DMARC Reporting of ARC Findings - Interim
[[ Note: Move to separate document? [8] (see the additional fields [[ Note: Move to separate document? [10] (see the additional fields
specified in Section 4.1) ]] specified in Section 4.1) ]]
Receivers SHOULD indicate situations in which ARC evaluation Receivers SHOULD indicate situations in which ARC evaluation
influenced the results of their local policy determination. DMARC influenced the results of their local policy determination. DMARC
reporting of ARC-informed decisions can be accomplished by adding a reporting of ARC-informed decisions can be accomplished by adding a
local_policy comment explanation containing the list of data local_policy comment explanation containing the list of data
discovered in the ARC evaluation (Section 7.1 and Section 4.1): discovered in the ARC evaluation (Section 7.1 and Section 4.1):
<policy_evaluated> <policy_evaluated>
<disposition>delivered</disposition> <disposition>delivered</disposition>
skipping to change at page 19, line 37 skipping to change at page 20, line 13
This section has been moved to [ARC-MULTI] This section has been moved to [ARC-MULTI]
9. Privacy Considerations 9. Privacy Considerations
The ARC chain provides a verifiable record of the handlers for a The ARC chain provides a verifiable record of the handlers for a
message. Anonymous remailers will probably not find this compatible message. Anonymous remailers will probably not find this compatible
with their operating goals. with their operating goals.
10. IANA Considerations 10. IANA Considerations
[[ See issue 21 [11] regarding which document should be definitive
for these fields. ]]
This specification adds three new header fields as defined below. This specification adds three new header fields as defined below.
10.1. Authentication-Results Method Registry Update 10.1. Authentication-Results Method Registry Update
This draft adds one item to the IANA "Email Authentication Methods" This draft adds one item to the IANA "Email Authentication Methods"
registry: registry:
o Method : arc o Method : arc
Defined: [I-D.ARC] Defined: [I-D.ARC]
ptype: header ptype: header
Property: chain evaluation result Property: chain evaluation result
Value: chain evaluation result status (see Section 3.4) Value: chain evaluation result status (see Section 3.4)
Status: active
Version: 1 Status: active
o Method : dkim o Method : dkim
Defined: [I-D.ARC] Defined: [I-D.ARC]
ptype: header ptype: header
Property: selector Property: selector
Value: value of signature "s" tag (see [RFC6376]) Value: value of signature "s" tag (see [RFC6376])
Status: active Status: active
Version: 1
o Method : spf o Method : spf
Defined: [I-D.ARC] Defined: [I-D.ARC]
ptype: smtp ptype: smtp
Property: client-ip Property: client-ip
Value: the connecting client IP address from which the message is Value: the connecting client IP address from which the message is
received received
Status: active Status: active
Version: 1
o Method : arc o Method : arc
Defined: [I-D.ARC] Defined: [I-D.ARC]
ptype: header ptype: header
Property: oldest-pass Property: oldest-pass
Value: the oldest instance with a still validating AMS signature Value: the oldest instance with a still validating AMS signature
Status: active Status: active
Version: 1
10.2. Definitions of the ARC header fields 10.2. Definitions of the ARC header fields
This specification adds three new header fields to the "Permanent This specification adds three new header fields to the "Permanent
Message Header Field Registry", as follows: Message Header Field Registry", as follows:
o Header field name: ARC-Seal o Header field name: ARC-Seal
Applicable protocol: mail Applicable protocol: mail
Status: draft Status: draft
skipping to change at page 25, line 50 skipping to change at page 26, line 23
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 [9] Contact Info: arc-discuss@dmarc.org [12]
13.2. AOL test reflector and internal tagging 13.2. AOL test reflector and internal tagging
Organization: AOL Organization: AOL
Description: Internal prototype implementation with both debug Description: Internal prototype implementation with both debug
analysis and validating + sealing pass-through function analysis and validating + sealing pass-through function
Status of Operation: Beta Status of Operation: Beta
skipping to change at page 26, line 25 skipping to change at page 26, line 45
applied to email addresses enrolled in the test program. This system applied to email addresses enrolled in the test program. This system
conforms to [ARC-DRAFT-06] conforms to [ARC-DRAFT-06]
Licensing: Proprietary - Internal only Licensing: Proprietary - Internal only
Implementation Notes: Implementation Notes:
o 2017-07-15: Full functionality verified during the interop o 2017-07-15: Full functionality verified during the interop
testing. testing.
Contact Info: arc-discuss@dmarc.org [10] Contact Info: arc-discuss@dmarc.org [13]
13.3. dkimpy 13.3. dkimpy
Organization: dkimpy developers/Scott Kitterman Organization: dkimpy developers/Scott Kitterman
Description: Python DKIM package Description: Python DKIM package
Status of Operation: Production Status of Operation: Production
Coverage: Coverage:
o 2017-07-15: The internal test suite is incomplete, but the command o 2017-07-15: The internal test suite is incomplete, but the command
line developmental version of validator was demonstrated to line developmental version of validator was demonstrated to
interoperate with the Google and AOL implementations during the interoperate with the Google and AOL implementations during the
interop on 2017-07-15 and the released version passes the tests in interop on 2017-07-15 and the released version passes the tests in
[ARC-TEST] arc_test_suite [11] with both python and python3. [ARC-TEST] arc_test_suite [14] with both python and python3.
Licensing: Open/Other (same as dkimpy package = BCD version 2) Licensing: Open/Other (same as dkimpy package = BCD version 2)
Contact Info: https://launchpad.net/dkimpy Contact Info: https://launchpad.net/dkimpy
13.4. OpenARC 13.4. OpenARC
Organization: TDP/Murray Kucherawy Organization: TDP/Murray Kucherawy
Description: Implemention of milter functionality related to the Description: Implemention of milter functionality related to the
skipping to change at page 27, line 23 skipping to change at page 27, line 44
for easier deployment on RedHat-based Linux platforms. for easier deployment on RedHat-based Linux platforms.
o Some issues still exist when deploying in a chained milter o Some issues still exist when deploying in a chained milter
arrangement (such as OpenSPF -> OpenDKIM -> OpenDMARC -> OpenARC) arrangement (such as OpenSPF -> OpenDKIM -> OpenDMARC -> OpenARC)
with coordination between the stages. When deployed in a with coordination between the stages. When deployed in a
"sandwich" configuration around an MLM, there is no effective "sandwich" configuration around an MLM, there is no effective
mechanism to convey trust from the ingress (validator) to egress mechanism to convey trust from the ingress (validator) to egress
(signer) instances. (_NOTE_: this is expected to resolved with a (signer) instances. (_NOTE_: this is expected to resolved with a
new release of OpenDMARC expected in January 2018.) new release of OpenDMARC expected in January 2018.)
Contact Info: arc-discuss@dmarc.org [12] Contact Info: arc-discuss@dmarc.org [15]
13.5. Mailman 3.2 patch 13.5. Mailman 3.2 patch
Organization: Mailman development team Organization: Mailman development team
Description: Integrated ARC capabilities within the Mailman 3.2 Description: Integrated ARC capabilities within the Mailman 3.2
package package
Status of Operation: Patch submitted Status of Operation: Patch submitted
Coverage: Based on OpenARC Coverage: Based on OpenARC
Licensing: Same as mailman package - GPL Licensing: Same as mailman package - GPL
Implementation Notes: Implementation Notes:
o Appears to work properly in at least one beta deployment, but o Appears to work properly in at least one beta deployment, but
waiting on acceptance of the pull request into the mainline of waiting on acceptance of the pull request into the mainline of
skipping to change at page 31, line 4 skipping to change at page 31, line 15
Contact Info: Chris Newman Contact Info: Chris Newman
13.12. MessageSystems Momentum 13.12. MessageSystems Momentum
Organization: MessageSystems/SparkPost Organization: MessageSystems/SparkPost
Description: OpenARC integration into the LUA-enabled Momentum Description: OpenARC integration into the LUA-enabled Momentum
processing space processing space
Status of Operation: Beta Status of Operation: Beta
Coverage: Built to support [ARC-DRAFT-10] Coverage: Built to support [ARC-DRAFT-10]
Licensing: Unknown Licensing: Unknown
Implementation Notes: Implementation Notes:
o Initial deployments for validation expected in early 2018. o Initial deployments for validation expected in mid-2018.
Contact Info: Contact Info:
14. References 14. References
14.1. Normative References 14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
skipping to change at page 33, line 38 skipping to change at page 33, line 49
14.3. URIs 14.3. URIs
[1] https://trac.ietf.org/trac/dmarc/ticket/10 [1] https://trac.ietf.org/trac/dmarc/ticket/10
[2] https://datatracker.ietf.org/wg/dcrup/about/ [2] https://datatracker.ietf.org/wg/dcrup/about/
[3] https://trac.ietf.org/trac/dmarc/ticket/11 [3] https://trac.ietf.org/trac/dmarc/ticket/11
[4] https://trac.ietf.org/trac/dmarc/ticket/12 [4] https://trac.ietf.org/trac/dmarc/ticket/12
[5] https://trac.ietf.org/trac/dmarc/ticket/13 [5] https://trac.ietf.org/trac/dmarc/ticket/20
[6] https://trac.ietf.org/trac/dmarc/ticket/14 [6] https://trac.ietf.org/trac/dmarc/ticket/21
[7] https://trac.ietf.org/trac/dmarc/ticket/15 [7] https://trac.ietf.org/trac/dmarc/ticket/13
[8] https://trac.ietf.org/trac/dmarc/ticket/16 [8] https://trac.ietf.org/trac/dmarc/ticket/14
[9] mailto:arc-discuss@dmarc.org [9] https://trac.ietf.org/trac/dmarc/ticket/15
[10] mailto:arc-discuss@dmarc.org [10] https://trac.ietf.org/trac/dmarc/ticket/16
[11] https://github.com/ValiMail/arc_test_suite [11] https://trac.ietf.org/trac/dmarc/ticket/21
[12] mailto:arc-discuss@dmarc.org [12] mailto:arc-discuss@dmarc.org
[13] https://trac.ietf.org/trac/dmarc/ticket/17 [13] mailto:arc-discuss@dmarc.org
[14] mailto:dmarc@ietf.org [14] https://github.com/ValiMail/arc_test_suite
[15] mailto:arc-discuss@dmarc.org [15] mailto:arc-discuss@dmarc.org
[16] https://trac.ietf.org/trac/dmarc/ticket/17
[17] mailto:dmarc@ietf.org
[18] mailto:arc-discuss@dmarc.org
Appendix A. Appendix A - Design Requirements Appendix A. Appendix A - Design Requirements
(This section is re-inserted for background information from (This section is re-inserted for background information from
[ARC-DRAFT-06] and earlier versions.) [ARC-DRAFT-06] and earlier versions.)
The specification of the ARC framework is driven by the following The specification of the ARC framework is driven by the following
high-level goals, security considerations, and practical operational high-level goals, security considerations, and practical operational
requirements. requirements.
A.1. Primary Design Criteria A.1. Primary Design Criteria
skipping to change at page 34, line 45 skipping to change at page 35, line 16
ARC is not a trust framework. Users of the ARC header fields are ARC is not a trust framework. Users of the ARC header fields are
cautioned against making unsubstantiated conclusions when cautioned against making unsubstantiated conclusions when
encountering a "broken" ARC sequence. encountering a "broken" ARC sequence.
Appendix B. Appendix B - Example Usage Appendix B. Appendix B - Example Usage
[[ Note: The following examples were mocked up early in the [[ Note: The following examples were mocked up early in the
definition process for the spec. They no longer reflect the current definition process for the spec. They no longer reflect the current
definition and need various updates which will be included in a definition and need various updates which will be included in a
future draft. Issue 17 [13] ]] future draft. Issue 17 [16] ]]
(Obsolete but retained for illustrative purposes) (Obsolete but retained for illustrative purposes)
B.1. Example 1: Simple mailing list B.1. Example 1: Simple mailing list
B.1.1. Here's the message as it exits the Origin: B.1.1. Here's the message as it exits the Origin:
Return-Path: <jqd@d1.example> Return-Path: <jqd@d1.example>
Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
(authenticated bits=0) (authenticated bits=0)
skipping to change at page 54, line 8 skipping to change at page 55, line 8
Alex Brotman, Brandon Long, Dave Crocker, Elizabeth Zwicky, Franck Alex Brotman, Brandon Long, Dave Crocker, Elizabeth Zwicky, Franck
Martin, Greg Colburn, J. Trent Adams, John Rae-Grant, Mike Hammer, Martin, Greg Colburn, J. Trent Adams, John Rae-Grant, Mike Hammer,
Mike Jones, Steve Jones, Terry Zink, Tim Draegen. Mike Jones, Steve Jones, Terry Zink, Tim Draegen.
Grateful appreciation is extended to the people who provided feedback Grateful appreciation is extended to the people who provided feedback
through the discuss mailing list. through the discuss mailing list.
Appendix D. Comments and Feedback Appendix D. Comments and Feedback
Please address all comments, discussions, and questions to Please address all comments, discussions, and questions to
dmarc@ietf.org [14]. Earlier discussions can be found at arc- dmarc@ietf.org [17]. Earlier discussions can be found at arc-
discuss@dmarc.org [15]. discuss@dmarc.org [18].
Authors' Addresses Authors' Addresses
Kurt Andersen Kurt Andersen
LinkedIn LinkedIn
1000 West Maude Ave 1000 West Maude Ave
Sunnyvale, California 94085 Sunnyvale, California 94085
USA USA
Email: kurta@linkedin.com Email: kurta@linkedin.com
 End of changes. 76 change blocks. 
136 lines changed or deleted 151 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/