draft-ietf-dmarc-arc-protocol-15.txt   draft-ietf-dmarc-arc-protocol-16.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: December 26, 2018 Google Expires: January 18, 2019 Google
S. Blank, Ed. S. Blank, Ed.
Valimail Valimail
M. Kucherawy, Ed. M. Kucherawy, Ed.
TDP TDP
T. Draegon, Ed. T. Draegen, Ed.
dmarcian dmarcian
June 24, 2018 July 17, 2018
Authenticated Received Chain (ARC) Protocol Authenticated Received Chain (ARC) Protocol
draft-ietf-dmarc-arc-protocol-15 draft-ietf-dmarc-arc-protocol-16
Abstract Abstract
The Authenticated Received Chain (ARC) protocol allows Internet Mail The Authenticated Received Chain (ARC) protocol allows Internet Mail
Handlers to attach assertions of message authentication state to Handlers to attach assertions of message authentication state to
individual messages. As messages traverse ARC-enabled Internet Mail individual messages. As messages traverse ARC-enabled Internet Mail
Handlers, additional ARC assertions can be attached to messages to Handlers, additional ARC assertions can be attached to messages to
form ordered sets of ARC assertions that represent authentication form ordered sets of ARC assertions that represent authentication
state along each step of message handling paths. state along each step of message handling paths.
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 December 26, 2018. This Internet-Draft will expire on January 18, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Note to Reviewers in the DMARC WG . . . . . . . . . . . . 4 2. General Concepts . . . . . . . . . . . . . . . . . . . . . . 4
2. General Concepts . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Evidence . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Evidence . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Custody . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Custody . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Chain of Custody . . . . . . . . . . . . . . . . . . . . 5 2.3. Chain of Custody . . . . . . . . . . . . . . . . . . . . 5
2.4. Validation of Chain of Custody . . . . . . . . . . . . . 5 2.4. Validation of Chain of Custody . . . . . . . . . . . . . 5
3. Terminology and Definitions . . . . . . . . . . . . . . . . . 6 3. Terminology and Definitions . . . . . . . . . . . . . . . . . 5
3.1. ARC Set . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. ARC Set . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Authenticated Received Chain (ARC) . . . . . . . . . . . 7 3.2. Authenticated Received Chain (ARC) . . . . . . . . . . . 6
3.3. Sealer . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Sealer . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Validator . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Validator . . . . . . . . . . . . . . . . . . . . . . . . 7
3.5. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . 7 3.5. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . 7
3.6. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . 7 3.6. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . 7
4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 8 4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 7
4.1. ARC Headers . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. ARC Headers . . . . . . . . . . . . . . . . . . . . . . . 7
4.1.1. ARC-Authentication-Results (AAR) . . . . . . . . . . 8 4.1.1. ARC-Authentication-Results (AAR) . . . . . . . . . . 8
4.1.2. ARC-Message-Signature (AMS) . . . . . . . . . . . . . 8 4.1.2. ARC-Message-Signature (AMS) . . . . . . . . . . . . . 8
4.1.3. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . 9 4.1.3. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . 9
4.2. ARC Set . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. ARC Set . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.1. Instance Tags . . . . . . . . . . . . . . . . . . . . 11 4.2.1. Instance Tags . . . . . . . . . . . . . . . . . . . . 10
4.3. Authenticated Received Chain . . . . . . . . . . . . . . 11 4.3. Authenticated Received Chain . . . . . . . . . . . . . . 11
4.4. Chain Validation Status . . . . . . . . . . . . . . . . . 11 4.4. Chain Validation Status . . . . . . . . . . . . . . . . . 11
5. Protocol Actions . . . . . . . . . . . . . . . . . . . . . . 12 5. Protocol Actions . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Sealer Actions . . . . . . . . . . . . . . . . . . . . . 12 5.1. Sealer Actions . . . . . . . . . . . . . . . . . . . . . 12
5.1.1. Header Fields To Include In ARC-Seal Signatures . . . 13 5.1.1. Header Fields To Include In ARC-Seal Signatures . . . 13
5.1.2. Marking and Sealing "cv=fail" (Invalid) Chains . . . 13 5.1.2. Marking and Sealing "cv=fail" (Invalid) Chains . . . 13
5.1.3. Only One Authenticated Received Chain Per Message . . 14 5.1.3. Only One Authenticated Received Chain Per Message . . 13
5.1.4. Broad Ability to Seal . . . . . . . . . . . . . . . . 14 5.1.4. Broad Ability to Seal . . . . . . . . . . . . . . . . 14
5.1.5. Sealing is Always Safe . . . . . . . . . . . . . . . 14 5.1.5. Sealing is Always Safe . . . . . . . . . . . . . . . 14
5.1.6. Signing vs Sealing . . . . . . . . . . . . . . . . . 14 5.1.6. Signing vs Sealing . . . . . . . . . . . . . . . . . 14
5.2. Validator Actions . . . . . . . . . . . . . . . . . . . . 14 5.2. Validator Actions . . . . . . . . . . . . . . . . . . . . 14
5.2.1. All Failures Are Permanent . . . . . . . . . . . . . 16 5.2.1. All Failures Are Permanent . . . . . . . . . . . . . 16
5.2.2. Responding to ARC Validation Failures During the SMTP 5.2.2. Responding to ARC Validation Failures During the SMTP
Transaction . . . . . . . . . . . . . . . . . . . . . 16 Transaction . . . . . . . . . . . . . . . . . . . . . 16
5.3. Result of Validation . . . . . . . . . . . . . . . . . . 16 5.3. Result of Validation . . . . . . . . . . . . . . . . . . 16
6. Communication of Validation Results . . . . . . . . . . . . . 17 6. Communication of Validation Results . . . . . . . . . . . . . 17
7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Communicate Authentication Results Across Trust 7.1. Communicate Authentication Results Across Trust
Boundaries . . . . . . . . . . . . . . . . . . . . . . . 17 Boundaries . . . . . . . . . . . . . . . . . . . . . . . 17
7.1.1. Message Scanning Services . . . . . . . . . . . . . . 18 7.1.1. Message Scanning Services . . . . . . . . . . . . . . 17
7.1.2. Multi-tier MTA Processing . . . . . . . . . . . . . . 18 7.1.2. Multi-tier MTA Processing . . . . . . . . . . . . . . 18
7.1.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 18 7.1.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 18
7.2. Inform Message Disposition Decisions . . . . . . . . . . 19 7.2. Inform Message Disposition Decisions . . . . . . . . . . 18
7.2.1. DMARC Local Policy Overrides . . . . . . . . . . . . 19 7.2.1. DMARC Local Policy Overrides . . . . . . . . . . . . 19
7.2.2. DMARC Reporting . . . . . . . . . . . . . . . . . . . 19 7.2.2. DMARC Reporting . . . . . . . . . . . . . . . . . . . 19
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9.1. Increased Header Size . . . . . . . . . . . . . . . . . . 21 9.1. Increased Header Size . . . . . . . . . . . . . . . . . . 20
9.2. DNS Operations . . . . . . . . . . . . . . . . . . . . . 21 9.2. DNS Operations . . . . . . . . . . . . . . . . . . . . . 21
9.3. Message Content Suspicion . . . . . . . . . . . . . . . . 21 9.3. Message Content Suspicion . . . . . . . . . . . . . . . . 21
9.4. Message Sealer Suspicion . . . . . . . . . . . . . . . . 22 9.4. Message Sealer Suspicion . . . . . . . . . . . . . . . . 21
9.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 22 9.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 22
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
10.1. Email Authentication Results Names Registry Update . . . 22 10.1. Email Authentication Results Names Registry Update . . . 22
10.2. Email Authentication Methods Registry Update . . . . . . 22 10.2. Email Authentication Methods Registry Update . . . . . . 22
10.3. Definitions of the ARC header fields . . . . . . . . . . 23 10.3. Definitions of the ARC header fields . . . . . . . . . . 23
11. Experimental Considerations . . . . . . . . . . . . . . . . . 23 11. Experimental Considerations . . . . . . . . . . . . . . . . . 23
11.1. Success Consideration . . . . . . . . . . . . . . . . . 23 11.1. Success Consideration . . . . . . . . . . . . . . . . . 24
11.2. Failure Considerations . . . . . . . . . . . . . . . . . 24 11.2. Failure Considerations . . . . . . . . . . . . . . . . . 24
11.3. Open Questions . . . . . . . . . . . . . . . . . . . . . 24 11.3. Open Questions . . . . . . . . . . . . . . . . . . . . . 24
11.3.1. Value of the ARC-Seal (AS) Header . . . . . . . . . 24 11.3.1. Value of the ARC-Seal (AS) Header . . . . . . . . . 24
11.3.2. DNS Overhead . . . . . . . . . . . . . . . . . . . . 24 11.3.2. DNS Overhead . . . . . . . . . . . . . . . . . . . . 24
11.3.3. What Trace Information is Valuable . . . . . . . . . 24 11.3.3. What Trace Information is Valuable . . . . . . . . . 25
12. Implementation Status . . . . . . . . . . . . . . . . . . . . 25 12. Implementation Status . . . . . . . . . . . . . . . . . . . . 25
12.1. GMail test reflector and incoming validation . . . . . . 26 12.1. GMail test reflector and incoming validation . . . . . . 26
12.2. AOL test reflector and internal tagging . . . . . . . . 26 12.2. AOL test reflector and internal tagging . . . . . . . . 26
12.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 26 12.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 27
12.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . 27 12.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . 27
12.5. Mailman 3.x patch . . . . . . . . . . . . . . . . . . . 27 12.5. Mailman 3.x patch . . . . . . . . . . . . . . . . . . . 27
12.6. Copernica/MailerQ web-based validation . . . . . . . . . 27 12.6. Copernica/MailerQ web-based validation . . . . . . . . . 28
12.7. Rspamd . . . . . . . . . . . . . . . . . . . . . . . . . 28 12.7. Rspamd . . . . . . . . . . . . . . . . . . . . . . . . . 28
12.8. PERL MAIL::DKIM module . . . . . . . . . . . . . . . . . 28 12.8. PERL MAIL::DKIM module . . . . . . . . . . . . . . . . . 29
12.9. PERL Mail::Milter::Authentication module . . . . . . . . 28 12.9. PERL Mail::Milter::Authentication module . . . . . . . . 29
12.10. Sympa List Manager . . . . . . . . . . . . . . . . . . . 29 12.10. Sympa List Manager . . . . . . . . . . . . . . . . . . . 29
12.11. Oracle Messaging Server . . . . . . . . . . . . . . . . 29 12.11. Oracle Messaging Server . . . . . . . . . . . . . . . . 30
12.12. MessageSystems Momentum and PowerMTA platforms . . . . . 29 12.12. MessageSystems Momentum and PowerMTA platforms . . . . . 30
12.13. Exim . . . . . . . . . . . . . . . . . . . . . . . . . . 29 12.13. Exim . . . . . . . . . . . . . . . . . . . . . . . . . . 30
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
13.1. Normative References . . . . . . . . . . . . . . . . . . 30 13.1. Normative References . . . . . . . . . . . . . . . . . . 31
13.2. Informative References . . . . . . . . . . . . . . . . . 31 13.2. Informative References . . . . . . . . . . . . . . . . . 32
13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 32 13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Appendix A. Appendix A - Design Requirements . . . . . . . . . . 32 Appendix A. Appendix A - Design Requirements . . . . . . . . . . 33
A.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 33 A.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 34
A.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 33 A.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 34
Appendix B. Appendix B - Example Usage . . . . . . . . . . . . . 33 Appendix B. Appendix B - Example Usage . . . . . . . . . . . . . 34
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 33 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 34
Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 34 Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
The utility of widely deployed email authentication technologies such The utility of widely deployed email authentication technologies such
as Sender Policy Framework (SPF) [RFC7208] and DomainKeys Identified as Sender Policy Framework (SPF) [RFC7208] and DomainKeys Identified
Mail (DKIM) [RFC6376] is impacted by the processing of Internet Mail Mail (DKIM) [RFC6376] is impacted by the processing of Internet Mail
by intermediate handlers. This impact is thoroughly documented in by intermediate handlers. This impact is thoroughly documented in
the defining documents for SPF and DKIM and further discussed in the defining documents for SPF and DKIM and further discussed in
[RFC6377] and [RFC7960]. [RFC6377] and [RFC7960].
skipping to change at page 4, line 35 skipping to change at page 4, line 34
DMARC [RFC7489]) is similarly impacted by intermediate handlers. The DMARC [RFC7489]) is similarly impacted by intermediate handlers. The
disruption of authentication mechanisms for legitimate messages by disruption of authentication mechanisms for legitimate messages by
intermediate handlers can impact all aspects of Internet Mail - intermediate handlers can impact all aspects of Internet Mail -
message authors, message recipients, and even the intermediary message authors, message recipients, and even the intermediary
handler itself. handler itself.
Authenticated Received Chain (ARC) creates a mechanism for individual Authenticated Received Chain (ARC) creates a mechanism for individual
Internet Mail Handlers to add their authentication processing results Internet Mail Handlers to add their authentication processing results
to a message's ordered set of processing results. ARC encapsulates to a message's ordered set of processing results. ARC encapsulates
processing results in a DKIM signature derivative to grant other processing results in a DKIM signature derivative to grant other
handlers the ability to verify the authenticity of each individual handlers the ability to verify the authenticity of the individual
processing results as well as the aggregate set and sequence of processing results as well as the aggregate set and sequence of
results. results.
Ordered sets of processing results can be used by ARC-enabled Ordered sets of processing results can be used by ARC-enabled
Internet Mail Handlers to inform message handling disposition, to Internet Mail Handlers to inform message handling disposition, to
identify where alteration of message content might have occurred, and identify where alteration of message content might have occurred, and
to provide additional trace information for use in understanding to provide additional trace information for use in understanding
message handling paths. message handling paths.
1.1. Note to Reviewers in the DMARC WG
[[ Note: This section is editorial to the WG. Will be removed for
final version. ]]
This version of the draft has been extensively reorganized for
readability. No changes to the wire protocol or specification are
intended from [ARC-DRAFT-14].
2. General Concepts 2. General Concepts
ARC is loosely based on concepts from evidence collection. Evidence ARC is loosely based on concepts from evidence collection. Evidence
is usually collected, labeled, stored, and transported in specific is usually collected, labeled, stored, and transported in specific
ways to preserve the state of evidence and to document all processing ways to preserve the state of evidence and to document all processing
steps. steps.
2.1. Evidence 2.1. Evidence
In ARC's situation, the "evidence" is a message's authentication In ARC's situation, the "evidence" is a message's authentication
state at any point along the delivery path between origination and state at any point along the delivery path between origination and
final delivery. Authentication state can change when intermediate final delivery. Authentication state can change when intermediate
handlers modify message content, route messages through unforeseen handlers modify message content (headers and/or body content), route
paths, or change envelope information. messages through unforeseen paths, or change envelope information.
The authentication state of a message is determined upon receipt of a
message and documented in the Authentication-Results header field(s).
ARC extends this mechanism to survive transit through intermediary
ADMDs.
2.2. Custody 2.2. Custody
"Custody" refers to when an ARC-enabled Internet Mail Handler "Custody" refers to when an ARC-enabled Internet Mail Handler
processes a message. When a handler takes custody of a message, the processes a message. When a handler takes custody of a message, the
handler becomes a Custodian and attaches their own evidence handler becomes a Custodian and attaches their own evidence
(authentication state upon receipt) to the message. Evidence is (authentication state upon receipt) to the message. Evidence is
added in such a way so that future handlers can verify the added in such a way so that future handlers can verify the
authenticity of both evidence and custody. authenticity of both evidence and custody.
skipping to change at page 6, line 11 skipping to change at page 5, line 50
Even though a message's authentication state might have changed, the Even though a message's authentication state might have changed, the
validated chain of custody can be used to determine if the changes validated chain of custody can be used to determine if the changes
(and the Custodians responsible for the changes) can be tolerated. (and the Custodians responsible for the changes) can be tolerated.
3. Terminology and Definitions 3. Terminology and Definitions
This section defines terms used in the rest of the document. This section defines terms used in the rest of the document.
Readers should to be familiar with the contents, core concepts, and Readers should to be familiar with the contents, core concepts, and
definitions found in [RFC5598]. The potential roles of definitions found in [RFC5598]. The potential roles of
intermediaries in the delivery of email is directly relevant. intermediaries in the delivery of email are directly relevant.
Language, syntax (including some ABNF constructs), and concepts are Language, syntax (including some ABNF constructs), and concepts are
imported from DKIM [RFC6376]. Specific references to DKIM are made imported from DKIM [RFC6376]. Specific references to DKIM are made
throughout this document. The following terms are imported from throughout this document. The following terms are imported from
[RFC5598]: [RFC5598]:
o ADministrative Management Domain (ADMD), Section 2.3 o ADministrative Management Domain (ADMD), Section 2.3
o Message Transfer Agents (MTA), Section 4.3.2 o Message Transfer Agents (MTA), Section 4.3.2
skipping to change at page 6, line 41 skipping to change at page 6, line 33
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. These words may also appear in this capitals, as shown here. These words may also appear in this
document in lower case as plain English words, absent their normative document in lower case as plain English words, absent their normative
meanings. meanings.
3.1. ARC Set 3.1. ARC Set
Section Section 4.1 introduces three (3) ARC header fields. Section 4.1 introduces three (3) ARC header fields. Together, the 3
Together, the 3 header fields compose a single "ARC Set". An ARC Set header fields compose a single "ARC Set". An ARC Set provides the
provides the means for an Internet Mail Handler to attach means for an Internet Mail Handler to attach authentication state to
authentication state to a message in a manner that can be verified by a message in a manner that can be verified by future handlers. A
future handlers. A single message can contain multiple ARC Sets. single message can contain multiple ARC Sets.
In General Concept terms, an ARC Set represents Evidence and Custody. In General Concept terms, an ARC Set represents Evidence and Custody.
3.2. Authenticated Received Chain (ARC) 3.2. Authenticated Received Chain (ARC)
The complete sequence of ARC Sets attached to a message is called the The complete sequence of ARC Sets attached to a message is called the
Authenticated Received Chain. An Authenticated Received Chain is a Authenticated Received Chain. An Authenticated Received Chain is a
recording of individual authentication states as a message traverses recording of individual authentication states as a message traverses
through ARC-participating ADMDs. through ARC-participating ADMDs.
skipping to change at page 7, line 32 skipping to change at page 7, line 21
valid ARC Set to a message. valid ARC Set to a message.
In General Concept terms, a Sealer adds Evidence and proof of Custody In General Concept terms, a Sealer adds Evidence and proof of Custody
to the Chain of Custody. to the Chain of Custody.
3.4. Validator 3.4. Validator
A Validator is an ARC-enabled Internet Mail Handler that evaluates an A Validator is an ARC-enabled Internet Mail Handler that evaluates an
Authenticated Received Chain for validity and content. The process Authenticated Received Chain for validity and content. The process
of evaluation of the individual ARC Sets that compose an of evaluation of the individual ARC Sets that compose an
Authenticated Received Chain is described in Section Section 5.2. Authenticated Received Chain is described in Section 5.2.
In General Concept terms, a Validator inspects the Chain of Custody In General Concept terms, a Validator inspects the Chain of Custody
to determine the content and validity of individual Evidence supplied to determine the content and validity of individual Evidence supplied
by Custodians. by Custodians.
3.5. Imported ABNF Tokens 3.5. Imported ABNF Tokens
The following ABNF tokens are imported: The following ABNF tokens are imported:
o tag-list ([RFC6376] section 3.2) o tag-list ([RFC6376] section 3.2)
skipping to change at page 8, line 34 skipping to change at page 8, line 22
In General Concept terms, the AAR header field is where Evidence is In General Concept terms, the AAR header field is where Evidence is
recorded by a Custodian. recorded by a Custodian.
The AAR header field is similar in syntax and semantics to an The AAR header field is similar in syntax and semantics to an
Authentication-Results field [I-D-7601bis], with two (2) differences: Authentication-Results field [I-D-7601bis], with two (2) differences:
o the name of the header field itself; o the name of the header field itself;
o the presence of the "instance tag". Additional information on the o the presence of the "instance tag". Additional information on the
"instance tag" can be found in Section Section 4.2.1. "instance tag" can be found in Section 4.2.1.
The formal ABNF for the AAR header field is: The formal ABNF for the AAR header field is:
arc-info = instance [CFWS] ";" authres-payload arc-info = instance [CFWS] ";" authres-payload
arc-authres-header = "ARC-Authentication-Results:" [CFWS] arc-info arc-authres-header = "ARC-Authentication-Results:" [CFWS] arc-info
Because there is only one AAR allowed per ARC set, the AAR MUST Because there is only one AAR allowed per ARC set, the AAR MUST
contain all authentication results from within the participating contain all authentication results from within the participating
ADMD, regardless of how many Authentication-Results headers are ADMD, regardless of how many Authentication-Results headers are
attached to the message. attached to the message.
skipping to change at page 9, line 13 skipping to change at page 8, line 49
participating Custodians. participating Custodians.
In General Concept terms, the AMS header field identifies a In General Concept terms, the AMS header field identifies a
Custodian. Custodian.
The AMS header field is similar in syntax and semantics to a DKIM- The AMS header field is similar in syntax and semantics to a DKIM-
Signature field [RFC6376], with three (3) differences: Signature field [RFC6376], with three (3) differences:
o the name of the header field itself; o the name of the header field itself;
o no version tag ("v") is defined for the AMS header. As required o no version tag ("v") is defined for the AMS header field. As
for undefined tags (in [RFC6376]), if seen, a version tag MUST be required for undefined tags (in [RFC6376]), if seen, a version tag
ignored; MUST be ignored;
o the presence of the "instance tag". Additional information on the o the presence of the "instance tag". Additional information on the
"instance tag" can be found in Section Section 4.2.1. The "instance tag" can be found in Section 4.2.1. The instance tag
instance tag replaces the DKIM "AUID" tag. replaces the DKIM "AUID" tag;
o when building the header field list to be signed, ARC-related
headers MUST be submitted to the hash function in increasing
instance order.
ARC places no requirements on the selectors and/or domains used for ARC places no requirements on the selectors and/or domains used for
the AMS header field signatures. the AMS header field signatures.
The formal ABNF for the AMS header field is: The formal ABNF for the AMS header field is:
arc-ams-info = instance [CFWS] ";" tag-list arc-ams-info = instance [CFWS] ";" tag-list
arc-message-signature = "ARC-Message-Signature:" [CFWS] arc-ams-info arc-message-signature = "ARC-Message-Signature:" [CFWS] arc-ams-info
To avoid unwanted invalidation of AMS signatures: To avoid unwanted invalidation of AMS signatures:
o AMS header fields are added by ARC-participating ADMDs as messages o AMS header fields are added by ARC-participating ADMDs as messages
exit the ADMD. AMS header fields should be attached so that any exit the ADMD. AMS header fields SHOULD be attached so that any
modifications made by the ADMD are included in the signature of modifications made by the ADMD are included in the signature of
the AMS header field. the AMS header field.
o Authentication-Results header fields MUST NOT be included in AMS o Authentication-Results header fields MUST NOT be included in AMS
signatures as they are likely to be deleted by downstream ADMDs signatures as they are likely to be deleted by downstream ADMDs
(per Section 5 of [I-D-7601bis]). (per [I-D-7601bis] Section 5).
o ARC-related header fields (ARC-Authentication-Results, ARC- o ARC-related header fields (ARC-Authentication-Results, ARC-
Message-Signature, ARC-Seal) MUST NOT be included in the list of Message-Signature, ARC-Seal) MUST NOT be included in the list of
header fields covered by the signature of the AMS header field. header fields covered by the signature of the AMS header field.
To preserve the ability to verify the integrity of a message, the To preserve the ability to verify the integrity of a message, the
signature of the AMS header field SHOULD include any DKIM-Signature signature of the AMS header field SHOULD include any DKIM-Signature
header fields already present in the message. header fields already present in the message.
4.1.3. ARC-Seal (AS) 4.1.3. ARC-Seal (AS)
skipping to change at page 10, line 13 skipping to change at page 10, line 6
corresponding AMS header fields. corresponding AMS header fields.
In General Concept terms, the AS header field is how Custodians bind In General Concept terms, the AS header field is how Custodians bind
Evidence into a Chain of Custody so that Validators can inspect Evidence into a Chain of Custody so that Validators can inspect
individual Evidence and Custodians. individual Evidence and Custodians.
The AS header field is similar in syntax and semantics to DKIM- The AS header field is similar in syntax and semantics to DKIM-
Signatures [RFC6376], with the following differences: Signatures [RFC6376], with the following differences:
o the presence of the "instance tag". Additional information on the o the presence of the "instance tag". Additional information on the
"instance tag" can be found in Section Section 4.2.1. "instance tag" can be found in Section 4.2.1.
o the signature of the AS header field does not cover the body of o the signature of the AS header field does not cover the body of
the message and therefore there is no 'bh' tag. The signature of the message and therefore there is no 'bh' tag. The signature of
the AS header field only covers specific header fields as defined the AS header field only covers specific header fields as defined
in Section Section 5.1.1. in Section 5.1.1.
o no body canonicalization is performed as the AS signature does not o no body canonicalization is performed as the AS signature does not
cover the body of a message. cover the body of a message.
o only "relaxed" header canonicalization ([RFC6376] section 3.4.2) o only "relaxed" header canonicalization ([RFC6376] section 3.4.2)
is used. is used.
o the only supported tags are "i" (from Section Section 4.2.1 of o the only supported tags are "i" (from Section 4.2.1 of this
this document), and "a", "b", "d, "s", "t" from Section 3.5 of document), and "a", "b", "d, "s", "t" from [RFC6376] Section 3.5.
[RFC6376]. Note especially that the DKIM "h" header is NOT Note especially that the DKIM "h" tag is NOT allowed and if found,
allowed and if found, MUST result in a cv status of "fail" (for MUST result in a cv status of "fail" (for more information see
more information see Section 5.1.1; Section 5.1.1);
o an additional tag, "cv" ("seal-cv-tag" in the ARC-Seal ABNF o an additional tag, "cv" ("seal-cv-tag" in the ARC-Seal ABNF
definition) is used to communicate Chain Validation Status to definition) is used to communicate Chain Validation Status to
subsequent ADMDs. subsequent ADMDs.
ARC places no requirements on the selectors and/or domains used for ARC places no requirements on the selectors and/or domains used for
the AS header field signatures. the AS header field signatures.
The formal ABNF for the AS header field is: The formal ABNF for the AS header field is:
arc-as-info = instance [CFWS] ";" tag-list arc-as-info = instance [CFWS] ";" tag-list
arc-seal = "ARC-Seal:" [CFWS] arc-as-info arc-seal = "ARC-Seal:" [CFWS] arc-as-info
4.2. ARC Set 4.2. ARC Set
An "ARC Set" is a single collection of three ARC Headers (AAR, AMS, An "ARC Set" is a single collection of three ARC Headers (AAR, AMS,
and AS). ARC Headers of an ARC Set share the same "instance" value. and AS). ARC Headers of an ARC Set share the same "instance" value.
By adding all ARC Headers to a message, an ARC Sealer adds an ARC Set By adding all ARC Headers to a message, an ARC Sealer adds an ARC Set
to a message. A description of how Sealers add an ARC Set to a to a message. A description of how Sealers add an ARC Set to a
message is found in Section Section 5.1. message is found in Section 5.1.
4.2.1. Instance Tags 4.2.1. Instance Tags
Instance tags describe which ARC Headers belong to an ARC Set. Each Instance tags describe which ARC Headers belong to an ARC Set. Each
ARC Header of an ARC Set shares the same instance tag value. ARC Header of an ARC Set shares the same instance tag value.
Instance tag values are integers that begin at 1 and are incremented Instance tag values are integers that begin at 1 and are incremented
by each addition of an ARC Set. Through the incremental values of by each addition of an ARC Set. Through the incremental values of
instance tags, an ARC Validator can determine the order in which ARC instance tags, an ARC Validator can determine the order in which ARC
Sets were added to a message. Sets were added to a message.
Instance tag values can range from 1-50 (inclusive). Instance tag values can range from 1-50 (inclusive).
_INFORMATIONAL:_ The upper limit of 50 was picked based on some
initial observations reported by early working group members with a
safety margin multiple added on top to support the vast majority of
all intermediary mail flows.
Valid ARC Sets MUST have exactly one instance of each ARC Header Valid ARC Sets MUST have exactly one instance of each ARC Header
field (AAR, AMS, and AS) for a given instance value and signing field (AAR, AMS, and AS) for a given instance value and signing
algorithm. algorithm.
_INFORMATIONAL:_ Initial development of ARC is only being done with a _INFORMATIONAL:_ Initial development of ARC is only being done with a
single allowed signing algorithm, but parallel work in the DCRUP single allowed signing algorithm, but parallel work in the DCRUP
working group is expanding that. For handling multiple signing working group is expanding that. For handling multiple signing
algorithms, see [ARC-MULTI]. algorithms, see [ARC-MULTI].
4.3. Authenticated Received Chain 4.3. Authenticated Received Chain
skipping to change at page 12, line 49 skipping to change at page 12, line 48
2. Calculate the instance value: if the message contains an 2. Calculate the instance value: if the message contains an
Authenticated Received Chain, the instance value is 1 more than Authenticated Received Chain, the instance value is 1 more than
the highest instance number found in the Authenticated Received the highest instance number found in the Authenticated Received
Chain. If no Authenticated Received Chain exists, the instance Chain. If no Authenticated Received Chain exists, the instance
value is 1. value is 1.
3. Using the calculated instance value, generate and attach to the 3. Using the calculated instance value, generate and attach to the
message in the following order: message in the following order:
4. An ARC-Authentication-Results header field as defined in 4. An ARC-Authentication-Results header field as defined in
Section Section 4.1.1. Section 4.1.1.
5. An ARC-Message-Signature header field as defined in 5. An ARC-Message-Signature header field as defined in
Section Section 4.1.2. Section 4.1.2.
6. An ARC-Seal header field using the AS definition found in 6. An ARC-Seal header field using the AS definition found in
Section Section 4.1.3, the method described in Section 4.1.3, the method described in Section 5.1.1, and the
Section Section 5.1.1, and the Chain Validation Status as Chain Validation Status as determined during ARC validation.
determined during ARC validation.
5.1.1. Header Fields To Include In ARC-Seal Signatures 5.1.1. Header Fields To Include In ARC-Seal Signatures
The signature of an AS header field signs a specific canonicalized The signature of an AS header field signs a specific canonicalized
form of the ARC Set header values. The ARC set header values are form of the ARC Set header values. The ARC set header values are
supplied to the hash function in increasing instance order, starting supplied to the hash function in increasing instance order, starting
at 1, and include the ARC Set being added at the time of Sealing the at 1, and include the ARC Set being added at the time of Sealing the
message. message.
Within an ARC Set, header fields are supplied to the hash function in Within an ARC Set, header fields are supplied to the hash function in
skipping to change at page 13, line 34 skipping to change at page 13, line 30
1. ARC-Authentication-Results 1. ARC-Authentication-Results
2. ARC-Message-Signature 2. ARC-Message-Signature
3. ARC-Seal 3. ARC-Seal
The ARC-Seal is generated in a manner similar to when DKIM-Signatures The ARC-Seal is generated in a manner similar to when DKIM-Signatures
are added to messages ([RFC6376], section 3.7). are added to messages ([RFC6376], section 3.7).
Note that when an Authenticated Received Chain has failed validation, Note that when an Authenticated Received Chain has failed validation,
the signing scope for the ARC-Seal is modified (see the signing scope for the ARC-Seal is modified (see Section 5.1.2).
Section Section 5.1.2).
5.1.2. Marking and Sealing "cv=fail" (Invalid) Chains 5.1.2. Marking and Sealing "cv=fail" (Invalid) Chains
In the case of a failed Authenticated Received Chain, the header In the case of a failed Authenticated Received Chain, the header
fields included in the signature scope of the AS header field b= fields included in the signature scope of the AS header field b=
value MUST only include the ARC Set headers created by the MTA which value MUST only include the ARC Set headers created by the MTA which
detected the malformed chain, as if this newest ARC Set was the only detected the malformed chain, as if this newest ARC Set was the only
set present. set present.
_INFORMATIONAL_: This approach is mandated to handle the case of a _INFORMATIONAL_: This approach is mandated to handle the case of a
skipping to change at page 14, line 18 skipping to change at page 14, line 9
time. Once broken, the chain cannot be continued, as the chain of time. Once broken, the chain cannot be continued, as the chain of
custody is no longer valid and responsibility for the message has custody is no longer valid and responsibility for the message has
been lost. For further discussion of this topic and the designed been lost. For further discussion of this topic and the designed
restriction which prevents chain continuation or re-establishment, restriction which prevents chain continuation or re-establishment,
see [ARC-USAGE]. see [ARC-USAGE].
5.1.4. Broad Ability to Seal 5.1.4. Broad Ability to Seal
ARC is not solely intended for perimeter MTAs. Any mediator ARC is not solely intended for perimeter MTAs. Any mediator
([RFC5598], section 5) that modifies a message may Seal its own ([RFC5598], section 5) that modifies a message may Seal its own
changes. For additional information, see Section Section 7.1. changes. For additional information, see Section 7.1.
5.1.5. Sealing is Always Safe 5.1.5. Sealing is Always Safe
The utility of an Authenticated Received Chain is limited to very The utility of an Authenticated Received Chain is limited to very
specific cases. Authenticated Received Chains are designed to specific cases. Authenticated Received Chains are designed to
provide additional information to an Internet Mail Handler when provide additional information to an Internet Mail Handler when
evaluating messages for delivery in the context of authentication evaluating messages for delivery in the context of authentication
failures. Specifically: failures. Specifically:
o Properly adding an ARC Set to a message does not damage or o Properly adding an ARC Set to a message does not damage or
invalidate an existing Authenticated Received Chain. invalidate an existing Authenticated Received Chain.
o Sealing an Authenticated Received Chain when a message has not o Sealing an Authenticated Received Chain when a message has not
been modified does not negatively affect the chain. been modified does not negatively affect the chain.
o Validating a message exposes no new threat vectors (see o Validating a message exposes no new threat vectors (see
Section Section 9). Section 9).
o An ADMD may choose to Seal all inbound messages whether or not a o An ADMD may choose to Seal all inbound messages whether or not a
message has been modified or will be retransmitted. message has been modified or will be retransmitted.
5.1.6. Signing vs Sealing 5.1.6. Signing vs Sealing
Signing is the process of affixing a digital signature to a message Signing is the process of affixing a digital signature to a message
as a header, such as when a DKIM-Signature (as in [RFC6376] section as a header, such as when a DKIM-Signature (as in [RFC6376] section
2.1), or an AMS or AS is added. Sealing is when an ADMD affixes a 2.1), or an AMS or AS is added. Sealing is when an ADMD affixes a
complete and valid ARC Set to a message creating or continuing an complete and valid ARC Set to a message creating or continuing an
skipping to change at page 16, line 35 skipping to change at page 16, line 29
failures, become unrecoverable and are considered permanent. failures, become unrecoverable and are considered permanent.
Any error Validating an Authenticated Received Chain results in a Any error Validating an Authenticated Received Chain results in a
failed Chain Validation Status. For further discussion of this topic failed Chain Validation Status. For further discussion of this topic
and the design restriction which prevents chain continuation or re- and the design restriction which prevents chain continuation or re-
establishment, see [ARC-USAGE]. establishment, see [ARC-USAGE].
5.2.2. Responding to ARC Validation Failures During the SMTP 5.2.2. Responding to ARC Validation Failures During the SMTP
Transaction Transaction
If an ARC Validator determines that the Authenticated Received Chain If an ARC Validator determines that the incoming message fails
has failed, the Validator MAY signal the breakage through the authentication checks (potentially including ARC validation), the
extended SMTP response code 5.7.7 [RFC3463] "message integrity Validator MAY signal the breakage through the extended SMTP response
failure" [ENHANCED-STATUS] and corresponding SMTP response code. code 5.7.7 [RFC3463] "message integrity failure" [ENHANCED-STATUS]
and corresponding SMTP response code.
5.3. Result of Validation 5.3. Result of Validation
An Authenticated Received Chain with a Chain Validation Status of An Authenticated Received Chain with a Chain Validation Status of
"pass" allows Internet Mail Handlers to ascertain: "pass" allows Internet Mail Handlers to ascertain:
o all ARC-participating ADMDs that claim responsibility for handling o all ARC-participating ADMDs that claim responsibility for handling
(and possibly modifying) the message in transit; (and possibly modifying) the message in transit;
o the authentication state of the message as perceived by each ADMD o the authentication state of the message as perceived by each ADMD
(from Authentication-Results header fields). (from Authentication-Results header fields).
Given this information, handlers can inform local policy decisions Given this information, handlers can inform local policy decisions
regarding disposition of messages that experience authentication regarding disposition of messages that experience authentication
failure due to intermediate processing. failure due to intermediate processing.
6. Communication of Validation Results 6. Communication of Validation Results
Chain Validation Status (described in Section Section 4.4) is Chain Validation Status (described in Section 4.4) is communicated
communicated via Authentication-Results (and AAR) headers using the via Authentication-Results (and AAR) headers using the auth method
auth method "arc". This auth method is described in "arc". This auth method is described in Section 10.1.
Section Section 10.1.
If necessary data is available, the ptypes and properties defined in If necessary data is available, the ptypes and properties defined in
Section Section 10.2 SHOULD be recorded in an Authentication-Results Section 10.2 SHOULD be recorded in an Authentication-Results header
header field: field:
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.oldest-pass - The instance number of the oldest AMS that o header.oldest-pass - The instance number of the oldest AMS that
still validates, or 0 if all pass. still validates, or 0 if all pass.
Upon Sealing of a message, this Authentication-Results information Upon Sealing of a message, this Authentication-Results information
along with all other Authentications-Results added by the ADMD will along with all other Authentications-Results added by the ADMD will
be recorded into the AAR as defined in section Section 4.1.1. be recorded into the AAR as defined in section Section 4.1.1.
skipping to change at page 19, line 46 skipping to change at page 19, line 35
documented in [RFC7960]. documented in [RFC7960].
Authenticated Received Chains allow DMARC processors to consider Authenticated Received Chains allow DMARC processors to consider
authentication states provided by other ADMDs. As a matter of local authentication states provided by other ADMDs. As a matter of local
policy, a DMARC processor may choose to accept the authentication policy, a DMARC processor may choose to accept the authentication
state provided by an Authenticated Received Chain when determining if state provided by an Authenticated Received Chain when determining if
a message is DMARC compliant. a message is DMARC compliant.
When an Authenticated Received Chain is used to determine message When an Authenticated Received Chain is used to determine message
disposition, the DMARC processor can communicate this local policy disposition, the DMARC processor can communicate this local policy
decision to Domain Owners as described in Section Section 7.2.2. decision to Domain Owners as described in Section 7.2.2.
7.2.2. DMARC Reporting 7.2.2. DMARC Reporting
DMARC-enabled receivers indicate when ARC Validation influences DMARC-enabled receivers indicate when ARC Validation influences
DMARC-related local policy decisions. DMARC reporting of ARC- DMARC-related local policy decisions. DMARC reporting of ARC-
influenced decisions is accomplished by adding a local_policy comment influenced decisions is accomplished by adding a local_policy comment
containing a list of data discovered during ARC Validation, which at containing a list of data discovered during ARC Validation, which at
a minimum includes: a minimum includes:
o the Chain Validation Status, o the Chain Validation Status,
skipping to change at page 21, line 13 skipping to change at page 20, line 51
directly to this specification. directly to this specification.
As with other domain authentication technologies (such as SPF, DKIM, As with other domain authentication technologies (such as SPF, DKIM,
and DMARC), ARC makes no claims about the semantic content of and DMARC), ARC makes no claims about the semantic content of
messages. messages.
9.1. Increased Header Size 9.1. Increased Header Size
Inclusion of Authenticated Received Chains into messages may cause Inclusion of Authenticated Received Chains into messages may cause
issues for older or constrained MTAs due to increased total header issues for older or constrained MTAs due to increased total header
size. size. Large header blocks, in general, may cause failures to deliver
or other outage scenarios for such MTAs. ARC itself would not cause
problems.
9.2. DNS Operations 9.2. DNS Operations
The validation of an Authenticated Received Chain composed of N ARC The validation of an Authenticated Received Chain composed of N ARC
Sets can require up to 2*N DNS queries (not including any DNS Sets can require up to 2*N DNS queries (not including any DNS
redirection mechanisms which can increase the total number of redirection mechanisms which can increase the total number of
queries). This leads to two considerations: queries). This leads to two considerations:
1. An attacker can send a message to an ARC participant with a 1. An attacker can send a message to an ARC participant with a
concocted sequence of ARC Sets bearing the domains of intended concocted sequence of ARC Sets bearing the domains of intended
skipping to change at page 22, line 31 skipping to change at page 22, line 20
attack, a malicious actor would take an intact and passing ARC Chain, attack, a malicious actor would take an intact and passing ARC Chain,
and then resend it to many recipients without making any and then resend it to many recipients without making any
modifications that invalidate the latest AMS or AS. The impact to a modifications that invalidate the latest AMS or AS. The impact to a
receiver would be more DNS lookups and signature evaluations. This receiver would be more DNS lookups and signature evaluations. This
scope of this attack can be limited by caching DNS queries and scope of this attack can be limited by caching DNS queries and
following the same signing scope guidance from [RFC6376] section following the same signing scope guidance from [RFC6376] section
5.4.1. 5.4.1.
10. IANA Considerations 10. IANA Considerations
[[ *Note to the RFC Editors:* dkim header.s is defined both here and [[ *Note to the RFC Editors:* "dkim - header - s" is defined both
in [I-D-7601bis]. Please delete the overlap from whichever document here and in [I-D-7601bis]. Please delete the overlap from whichever
goes through the publication process after the other. ]] document goes through the publication process after the other. ]]
This draft introduces three new headers fields and updates the Email This draft introduces three new headers fields and updates the Email
Authentication Parameters registry with one new authentication method Authentication Parameters registry with one new authentication method
and several status codes. and several status codes.
10.1. Email Authentication Results Names Registry Update 10.1. Email Authentication Results Names Registry Update
This draft adds one Auth Method with three Codes to the IANA "Email This draft adds one Auth Method with three Codes to the IANA "Email
Authentication Result Names" registry: Authentication Result Names" registry:
o Auth Method : arc Code: "none", "pass", "fail" Specification: o Auth Method : arc
[I-D.ARC] Section 2.2 Status: active Code: "none", "pass", "fail"
Specification: [I-D.ARC] 2.2
Status: active
10.2. Email Authentication Methods Registry Update 10.2. Email Authentication Methods Registry Update
This draft adds several new items to the Email Authentication Methods This draft adds several new items to the Email Authentication Methods
registry, most recently defined in [I-D-7601bis]: registry, most recently defined in [I-D-7601bis]:
o Method: arc Definition: [I-D.ARC] ptype: smtp Property: client-ip o Method: arc
Value: IP address of originating SMTP connection Status: active Definition: [I-D.ARC]
ptype: smtp
Property: client-ip
Value: IP address of originating SMTP connection
Status: active
Version: 1 Version: 1
o Method: arc Definition: [I-D.ARC] ptype: header Property: oldest- o Method: arc
pass Value: The instance id of the oldest validating AMS, or 0 if Definition: [I-D.ARC]
they all pass (see Sectionn 4) Status: active Version: 1 ptype: header
Property: oldest-pass
Value: The instance id of the oldest validating AMS, or 0 if they
all pass (see Section 5.2)
Status: active
Version: 1
o Method: dkim Definition: [RFC6376] ptype: header Property: s o Method: dkim
Value: value of signature "s" tag Status: active Version: 1 Definition: [RFC6376]
ptype: header
Property: s
Value: value of signature "s" tag
Status: active
Version: 1
10.3. Definitions of the ARC header fields 10.3. 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 Applicable protocol: mail Status: o Header field name: ARC-Seal
draft Author/Change controller: IETF Specification document(s): Applicable protocol: mail
[I-D.ARC] Related information: [RFC6376] Status: draft
Author/Change controller: IETF
Specification document(s): [I-D.ARC]
Related information: [RFC6376]
o Header field name: ARC-Message-Signature Applicable protocol: mail o Header field name: ARC-Message-Signature
Status: draft Author/Change controller: IETF Specification Applicable protocol: mail
document(s): [I-D.ARC] Related information: [RFC6376] Status: draft
Author/Change controller: IETF
Specification document(s): [I-D.ARC]
Related information: [RFC6376]
o Header field name: ARC-Authentication-Results Applicable protocol: o Header field name: ARC-Authentication-Results
mail Status: standard Author/Change controller: IETF Specification Applicable protocol: mail
document(s): [I-D.ARC] Related information: [I-D-7601bis] Status: standard
Author/Change controller: IETF
Specification document(s): [I-D.ARC]
Related information: [I-D-7601bis]
11. Experimental Considerations 11. Experimental Considerations
The ARC protocol is designed to address common interoperability The ARC protocol is designed to address common interoperability
issues introduced by intermediate message handlers. Interoperability issues introduced by intermediate message handlers. Interoperability
issues are described in [RFC6377] and [RFC7960]. issues are described in [RFC6377] and [RFC7960].
As the ARC protocol is implemented by intermediary handlers over As the ARC protocol is implemented by intermediary handlers over
time, the following should be evaluated in order to determine the time, the following should be evaluated in order to determine the
success of the protocol in accomplishing the intended benefits. success of the protocol in accomplishing the intended benefits.
skipping to change at page 24, line 8 skipping to change at page 24, line 22
receivers use heuristic-based methods to identify messages that receivers use heuristic-based methods to identify messages that
arrive via indirect delivery paths. arrive via indirect delivery paths.
ARC will be a success if the presence of Authenticated Received ARC will be a success if the presence of Authenticated Received
Chains allows for improved decision making when processing legitimate Chains allows for improved decision making when processing legitimate
messages. messages.
11.2. Failure Considerations 11.2. Failure Considerations
ARC should function without introducing significant new vectors for ARC should function without introducing significant new vectors for
abuse (see Section Section 9). If unforseen vectors are enabled by abuse (see Section 9). If unforseen vectors are enabled by ARC, then
ARC, then this protocol will be a failure. Note that weaknesses this protocol will be a failure. Note that weaknesses inherent in
inherent in the mail protocols ARC is built upon (such as DKIM replay the mail protocols ARC is built upon (such as DKIM replay attacks and
attacks and other known issues) are not new vectors which can be other known issues) are not new vectors which can be attributed to
attributed to this specification. this specification.
11.3. Open Questions 11.3. Open Questions
The following open questions are academic and have no clear answer at The following open questions are academic and have no clear answer at
the time of the development of the protocol. However, additional the time of the development of the protocol. However, additional
deployment should be able to gather the necessary data to answer some deployment should be able to gather the necessary data to answer some
or all of them. or all of them.
11.3.1. Value of the ARC-Seal (AS) Header 11.3.1. Value of the ARC-Seal (AS) Header
Data should be collected to show if the ARC-Seal (AS) provides value Data should be collected to show if the ARC-Seal (AS) provides value
beyond the ARC Message Signature (AMS) for either making delivery beyond the ARC Message Signature (AMS) for either making delivery
decisions or catching malicious actors trying to craft or replay decisions or catching malicious actors trying to craft or replay
malicious chains. malicious chains.
11.3.2. DNS Overhead 11.3.2. DNS Overhead
Longer Authenticated Received Chains will require more queries to Longer Authenticated Received Chains will require more queries to
retrieve the keys for validating the chain. While this is not retrieve the keys for validating the chain. While this is not
believed to be a security issue (see Section Section 9.2), it is believed to be a security issue (see Section 9.2), it is unclear how
unclear how much overhead will truly be added. This is similar to much overhead will truly be added. This is similar to some of the
some of the initial processing and query load concerns which were initial processing and query load concerns which were debated at the
debated at the time of the DKIM specification development. time of the DKIM specification development.
Data should be collected to better understand usable length and Data should be collected to better understand usable length and
distribution of lengths found in valid Authenticated Received Chains distribution of lengths found in valid Authenticated Received Chains
along with the the DNS impact of processing Authenticated Received along with the the DNS impact of processing Authenticated Received
Chains. Chains.
An effective operational maximum will have to be developed through An effective operational maximum will have to be developed through
deployment experience in the field. deployment experience in the field.
11.3.3. What Trace Information is Valuable 11.3.3. What Trace Information is Valuable
skipping to change at page 25, line 30 skipping to change at page 25, line 43
useful information. useful information.
Since many such systems are intentionally proprietary or confidential Since many such systems are intentionally proprietary or confidential
to prevent gaming by abusers, it may not be viable to reliably answer to prevent gaming by abusers, it may not be viable to reliably answer
this particular question. The evolving nature of attacks can also this particular question. The evolving nature of attacks can also
shift the landscape of "useful" information over time. shift the landscape of "useful" information over time.
12. Implementation Status 12. Implementation Status
[[ Note to the RFC Editor: Please remove this section before [[ Note to the RFC Editor: Please remove this section before
publication along with the reference to [RFC6982]. ]] publication along with the reference to [RFC7942]. ]]
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC6982]. Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may features. Readers are advised to note that other implementations may
exist. exist.
This information is known to be correct as of the eighth This information is known to be correct as of the eighth
interoperability test event which was held on 2018-03-17 at IETF101. interoperability test event which was held on 2018-03-17 at IETF101.
For a few of the implementations, later status information was For a few of the implementations, later status information was
available as of June 2018. available as of June 2018.
12.1. GMail test reflector and incoming validation 12.1. GMail test reflector and incoming validation
Organization: Google Description: Internal production implementation Organization: Google
with both debug analysis and validating + sealing pass-through Description: Internal production implementation with both debug
function Status of Operation: Production - Incoming Validation analysis and validating + sealing pass-through function
Coverage: Full spec implemented as of [ARC-DRAFT-14] Licensing: Status of Operation: Production - Incoming Validation
Proprietary - Internal only Implementation Notes: Coverage: Full spec implemented as of [ARC-DRAFT-14]
Licensing: Proprietary - Internal only
Implementation Notes:
o Full functionality was demonstrated during the interop testing on o Full functionality was demonstrated during the interop testing on
2018-03-17. 2018-03-17.
Contact Info: arc-discuss@dmarc.org [1] Contact Info: arc-discuss@dmarc.org [1]
12.2. AOL test reflector and internal tagging 12.2. AOL test reflector and internal tagging
Organization: AOL Description: Internal prototype implementation with Organization: AOL
both debug analysis and validating + sealing pass-through function Description: Internal prototype implementation with both debug
Status of Operation: Beta Coverage: ARC Chain validity status analysis and validating + sealing pass-through function
checking is operational, but only applied to email addresses enrolled Status of Operation: Beta
in the test program. This system conforms to [ARC-DRAFT-05] Coverage: ARC Chain validity status checking is operational, but only
Licensing: Proprietary - Internal only Implementation Notes: applied to email addresses enrolled in the test program. This system
conforms to [ARC-DRAFT-05]
Licensing: Proprietary - Internal only
Implementation Notes:
o 2017-07-15: Full functionality verified during the interop o 2017-07-15: Full functionality verified during the interop
testing. testing.
o 2018-06: Partially retired but still accessible by special request o 2018-06: Partially retired but still accessible by special request
due to the in process evolution of the AOL mail infrastructure to due to the in process evolution of the AOL mail infrastructure to
the integrated OATH environment. The implementation was based on the integrated OATH environment. The implementation was based on
the Apache James DKIM code base and may be contributed back to the Apache James DKIM code base and may be contributed back to
that project in the future. that project in the future.
Contact Info: arc-discuss@dmarc.org [2] Contact Info: arc-discuss@dmarc.org [2]
12.3. dkimpy 12.3. dkimpy
Organization: dkimpy developers/Scott Kitterman Description: Python Organization: dkimpy developers/Scott Kitterman
DKIM package Status of Operation: Production Coverage: Description: Python DKIM package
Status of Operation: Production
Coverage:
o 2017-07-15: The internal test suite is incomplete, but the command o 2017-07-15: The internal test suite is incomplete, but the command
line developmental version of validator was demonstrated to line developmental version of validator was demonstrated to
interoperate with the Google and AOL implementations during the interoperate with the Google and AOL implementations during the
interop on 2017-07-15 and the released version passes the tests in interop on 2017-07-15 and the released version passes the tests in
[ARC-TEST] arc_test_suite [3] with both python and python3. [ARC-TEST] arc_test_suite [3] with both python and python3.
Licensing: Open/Other (same as dkimpy package = BCD version 2) Licensing: Open/Other (same as dkimpy package = BCD version 2)
Contact Info: https://launchpad.net/dkimpy Contact Info: https://launchpad.net/dkimpy
12.4. OpenARC 12.4. OpenARC
Organization: TDP/Murray Kucherawy Description: Implemention of Organization: TDP/Murray Kucherawy
milter functionality related to the OpenDKIM and OpenDMARC packages Description: Implemention of milter functionality related to the
Status of Operation: Beta Coverage: Built to support [ARC-DRAFT-14] OpenDKIM and OpenDMARC packages
Status of Operation: Beta
Coverage: Built to support [ARC-DRAFT-14]
Licensing: Open/Other (same as OpenDKIM and OpenDMARC packages) Licensing: Open/Other (same as OpenDKIM and OpenDMARC packages)
Implementation Notes: Implementation Notes:
o The build is FreeBSD oriented but some packages have been built o The build is FreeBSD oriented but some packages have been built
for easier deployment on RedHat-based Linux platforms. for easier deployment on RedHat-based Linux platforms.
o Some issues still exist when deploying in a chained milter o Some issues still exist when deploying in a chained milter
arrangement (such as OpenSPF -> OpenDKIM -> OpenDMARC -> OpenARC) arrangement (such as OpenSPF -> OpenDKIM -> OpenDMARC -> OpenARC)
with coordination between the stages. When deployed in a with coordination between the stages. When deployed in a
"sandwich" configuration around an MLM, there is no effective "sandwich" configuration around an MLM, there is no effective
mechanism to convey trust from the ingress (validator) to egress mechanism to convey trust from the ingress (validator) to egress
(signer) instances. (_NOTE_: this is expected to resolved with a (signer) instances. (_NOTE_: this is expected to resolved with a
new release of OpenDMARC expected in mid-2018.) new release of OpenDMARC expected in mid-2018.)
Contact Info: arc-discuss@dmarc.org [4] Contact Info: arc-discuss@dmarc.org [4]
12.5. Mailman 3.x patch 12.5. Mailman 3.x patch
Organization: Mailman development team Description: Integrated ARC Organization: Mailman development team
capabilities within the Mailman 3.2 package Status of Operation: Description: Integrated ARC capabilities within the Mailman 3.2
Patch submitted Coverage: Based on OpenARC Licensing: Same as mailman package
package - GPL Implementation Notes: Status of Operation: Patch submitted
Coverage: Based on OpenARC
Licensing: Same as mailman package - GPL
Implementation Notes:
o Appears to work properly in at least one beta deployment, but 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
12.6. Copernica/MailerQ web-based validation 12.6. Copernica/MailerQ web-based validation
Organization: Copernica Description: Web-based validation of ARC- Organization: Copernica
signed messages Status of Operation: Beta Coverage: Built to support Description: Web-based validation of ARC-signed messages
[ARC-DRAFT-05] Licensing: On-line usage only Implementation Notes: Status of Operation: Beta
Coverage: Built to support [ARC-DRAFT-05]
Licensing: On-line usage only
Implementation Notes:
o Released 2016-10-24 o Released 2016-10-24
o Requires full message content to be pasted into a web form found o Requires full message content to be pasted into a web form found
at http://arc.mailerq.com/ (warning - https is not supported). at http://arc.mailerq.com/ (warning - https is not supported).
o An additional instance of an ARC signature can be added if one is o An additional instance of an ARC signature can be added if one is
willing to paste a private key into an unsecured web form. willing to paste a private key into an unsecured web form.
o 2017-07-15: Testing shows that results match the other o 2017-07-15: Testing shows that results match the other
implementations listed in this section. implementations listed in this section.
Contact Info: https://www.copernica.com/ Contact Info: https://www.copernica.com/
12.7. Rspamd 12.7. Rspamd
Organization: Rspamd community Description: ARC signing and Organization: Rspamd community
verification module Status of Operation: Production, though Description: ARC signing and verification module
deployment usage is unknown Coverage: Built to support [ARC-DRAFT-14] Status of Operation: Production, though deployment usage is unknown
Licensing: Open source Implementation Notes: Coverage: Built to support [ARC-DRAFT-14]
Licensing: Open source
Implementation Notes:
o 2017-06-12: Released with version 1.6.0 o 2017-06-12: Released with version 1.6.0
o 2017-07-15: Testing during the interop showed that the validation o 2017-07-15: Testing during the interop showed that the validation
functionality interoperated with the Google, AOL, dkimpy and functionality interoperated with the Google, AOL, dkimpy and
MailerQ implementations MailerQ implementations
Contact Info: https://rspamd.com/doc/modules/arc.html and Contact Info: https://rspamd.com/doc/modules/arc.html and
https://github.com/vstakhov/rspamd https://github.com/vstakhov/rspamd
12.8. PERL MAIL::DKIM module 12.8. PERL MAIL::DKIM module
Organization: FastMail Description: Email domain authentication (sign Organization: FastMail
and/or verify) module, previously included SPF / DKIM / DMARC, now Description: Email domain authentication (sign and/or verify) module,
has ARC added Status of Operation: Production, deployment usage previously included SPF / DKIM / DMARC, now has ARC added
unknown Coverage: Built to support [ARC-DRAFT-10] Licensing: Open Status of Operation: Production, deployment usage unknown
Source Implementation Notes: 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 o 2017-12-15: v0.50 released with full test set passing for ARC
Contact Info: http://search.cpan.org/~mbradshaw/Mail-DKIM-0.50/ Contact Info: http://search.cpan.org/~mbradshaw/Mail-DKIM-0.50/
12.9. PERL Mail::Milter::Authentication module 12.9. PERL Mail::Milter::Authentication module
Organization: FastMail Description: Email domain authentication Organization: FastMail
milter, uses MAIL::DKIM (see above) Status of Operation: Intial Description: Email domain authentication milter, uses MAIL::DKIM (see
validation completed during IETF99 hackathon with some follow-on work above)
during the week Coverage: Built to support [ARC-DRAFT-14] Licensing: Status of Operation: Intial validation completed during IETF99
Open Source Implementation Notes: hackathon with some follow-on work during the week
Coverage: Built to support [ARC-DRAFT-14]
Licensing: Open Source
Implementation Notes:
o 2017-07-15: Validation functionality which interoperates with o 2017-07-15: Validation functionality which interoperates with
Gmail, AOL, dkimpy was demonstrated; later in the week of IETF99, Gmail, AOL, dkimpy was demonstrated; later in the week of IETF99,
the signing functionality was reported to be working the signing functionality was reported to be working
o 2017-07-20: ARC functionality has not yet been pushed back to the o 2017-07-20: ARC functionality has not yet been pushed back to the
github repo but should be showing up soon github repo but should be showing up soon
Contact Info: https://github.com/fastmail/authentication_milter Contact Info: https://github.com/fastmail/authentication_milter
12.10. Sympa List Manager 12.10. Sympa List Manager
Organization: Sympa Dev Community Description: Work in progress Organization: Sympa Dev Community
Status of Operation: Work in progress Coverage: unknown Licensing: Description: Work in progress
open source Implementation Notes: 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/ o 2018-01-05: Tracked as https://github.com/sympa-community/sympa/
issues/153 issues/153
Contact Info: https://github.com/sympa-community Contact Info: https://github.com/sympa-community
12.11. Oracle Messaging Server 12.11. Oracle Messaging Server
Organization: Oracle Description: Status of Operation: Intial Organization: Oracle
development work during IETF99 hackathon. Framework code is Description:
complete, crypto functionality requires integration with libsodium Status of Operation: Intial development work during IETF99 hackathon.
Coverage: Work in progress Licensing: Unknown Implementation Notes: Framework code is complete, crypto functionality requires integration
with libsodium
Coverage: Work in progress
Licensing: Unknown
Implementation Notes:
o 2018-03: Protocol handling components are completed, but crypto is o 2018-03: Protocol handling components are completed, but crypto is
not yet functional. not yet functional.
Contact Info: Chris Newman, Oracle Contact Info: Chris Newman, Oracle
12.12. MessageSystems Momentum and PowerMTA platforms 12.12. MessageSystems Momentum and PowerMTA platforms
Organization: MessageSystems/SparkPost Description: OpenARC Organization: MessageSystems/SparkPost
integration into the LUA-enabled Momentum processing space Status of Description: OpenARC integration into the LUA-enabled Momentum
Operation: Beta Coverage: Same as OpenARC Licensing: Unknown processing space
Status of Operation: Beta
Coverage: Same as OpenARC
Licensing: Unknown
Implementation Notes: Implementation Notes:
o Initial deployments for validation expected in mid-2018. o Initial deployments for validation expected in mid-2018.
Contact Info: TBD Contact Info: TBD
12.13. Exim 12.13. Exim
Organization: Exim developers Status of Operation: Operational; Organization: Exim developers
requires specific enabling for compile. Coverage: Full spec Status of Operation: Operational; requires specific enabling for
implemented as of [ARC-DRAFT-13] Licensing: GPL Contact Info: exim- compile.
users@exim.org Implementation notes: Coverage: Full spec implemented as of [ARC-DRAFT-13]
Licensing: GPL
Contact Info: exim-users@exim.org
Implementation notes:
o Exim 4.91 o Implemented as of Exim 4.91
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes",
RFC 3463, DOI 10.17487/RFC3463, January 2003, RFC 3463, DOI 10.17487/RFC3463, January 2003,
<https://www.rfc-editor.org/info/rfc3463>. <https://www.rfc-editor.org/info/rfc3463>.
skipping to change at page 32, line 11 skipping to change at page 33, line 11
"IANA SMTP Enhanced Status Codes", n.d., "IANA SMTP Enhanced Status Codes", n.d.,
<http://www.iana.org/assignments/smtp-enhanced-status- <http://www.iana.org/assignments/smtp-enhanced-status-
codes/smtp-enhanced-status-codes.xhtml>. codes/smtp-enhanced-status-codes.xhtml>.
[I-D-7601bis] [I-D-7601bis]
Kucherawy, M., "Message Header Field for Indicating Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", February 2018, Message Authentication Status", February 2018,
<https://datatracker.ietf.org/doc/ <https://datatracker.ietf.org/doc/
draft-ietf-dmarc-rfc7601bis/>. draft-ietf-dmarc-rfc7601bis/>.
[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", RFC 6982,
DOI 10.17487/RFC6982, July 2013,
<https://www.rfc-editor.org/info/rfc6982>.
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
Message Authentication, Reporting, and Conformance Message Authentication, Reporting, and Conformance
(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
<https://www.rfc-editor.org/info/rfc7489>. <https://www.rfc-editor.org/info/rfc7489>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[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>.
13.3. URIs 13.3. URIs
[1] mailto:arc-discuss@dmarc.org [1] mailto:arc-discuss@dmarc.org
skipping to change at page 34, line 43 skipping to change at page 35, line 43
Seth Blank (editor) Seth Blank (editor)
Valimail Valimail
Email: seth@valimail.com Email: seth@valimail.com
Murray Kucherawy (editor) Murray Kucherawy (editor)
TDP TDP
Email: superuser@gmail.com Email: superuser@gmail.com
Tim Draegon (editor) Tim Draegen (editor)
dmarcian dmarcian
Email: tim@dmarcian.com Email: tim@dmarcian.com
 End of changes. 80 change blocks. 
183 lines changed or deleted 246 lines changed or added

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