draft-ietf-dmarc-arc-protocol-00.txt   draft-ietf-dmarc-arc-protocol-01.txt 
DMARC Working Group K. Andersen DMARC Working Group K. Andersen
Internet-Draft LinkedIn Internet-Draft LinkedIn
Obsoletes: draft-andersen-arc-17 (if J. Rae-Grant, Ed. Intended status: Standards Track J. Rae-Grant, Ed.
approved) B. Long, Ed. Expires: June 4, 2017 B. Long, Ed.
Intended status: Standards Track Google Google
Expires: December 27, 2016 T. Adams, Ed. T. Adams, Ed.
Paypal Paypal
S. Jones, Ed. S. Jones, Ed.
TDP TDP
June 25, 2016 December 01, 2016
Authenticated Received Chain (ARC) Protocol Authenticated Received Chain (ARC) Protocol
draft-ietf-dmarc-arc-protocol-00 draft-ietf-dmarc-arc-protocol-01
Abstract Abstract
Authenticated Received Chain (ARC) permits an organization which is Authenticated Received Chain (ARC) permits an organization which is
creating or handling email to indicate its involvement with the creating or handling email to indicate its involvement with the
handling process. It defines a set of cryptographically signed handling process. It defines a set of cryptographically signed
header fields in a manner analagous to that of DKIM. Assertion of header fields in a manner analagous to that of DKIM. Assertion of
responsibility is validated through a cryptographic signature and by responsibility is validated through a cryptographic signature and by
querying the Signer's domain directly to retrieve the appropriate querying the Signer's domain directly to retrieve the appropriate
public key. Changes in the message that might break DKIM can be public key. Changes in the message that might break DKIM can be
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 27, 2016. This Internet-Draft will expire on June 4, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 22 skipping to change at page 2, line 22
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 4 2.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 4
2.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Utility . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Utility . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Definition . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Definition . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Description of the New Header Fields . . . . . . . . . . 6 5.1. Description of the New Header Fields . . . . . . . . . . 6
5.1.1. ARC-Seal . . . . . . . . . . . . . . . . . . . . . . 6 5.1.1. ARC-Seal . . . . . . . . . . . . . . . . . . . . . . 6
5.1.2. ARC-Message-Signature . . . . . . . . . . . . . . . . 9 5.1.2. ARC-Message-Signature . . . . . . . . . . . . . . . . 9
5.1.3. ARC-Authentication-Results . . . . . . . . . . . . . 10 5.1.3. ARC-Authentication-Results . . . . . . . . . . . . . 10
5.2. Constructing the ARC-Seal Set . . . . . . . . . . . . . . 10 5.2. Constructing the ARC-Seal Set . . . . . . . . . . . . . . 11
5.2.1. Handling Violations in the ARC Sets . . . . . . . . . 11 5.2.1. Handling Violations in the ARC Sets . . . . . . . . . 12
5.3. Key Management and Binding . . . . . . . . . . . . . . . 12 5.3. Key Management and Binding . . . . . . . . . . . . . . . 12
5.3.1. Namespace . . . . . . . . . . . . . . . . . . . . . . 12 5.3.1. Namespace . . . . . . . . . . . . . . . . . . . . . . 12
6. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Participation . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Participation . . . . . . . . . . . . . . . . . . . . . . 13
6.2. Relationship between DKIM Signatures and ARC Headers . . 13 6.2. Relationship between DKIM Signatures and ARC Headers . . 13
6.3. Validating the ARC Set of Header Fields . . . . . . . . . 13 6.3. Validating the ARC Set of Header Fields . . . . . . . . . 13
6.4. ARC Set Validity . . . . . . . . . . . . . . . . . . . . 13 6.4. ARC Set Validity . . . . . . . . . . . . . . . . . . . . 13
6.4.1. Assessing Chain Validity Violations . . . . . . . . . 13 6.4.1. Assessing Chain Validity Violations . . . . . . . . . 13
6.4.2. Responding to ARC Validity Violations . . . . . . . . 13 6.4.2. Responding to ARC Validity Violations . . . . . . . . 14
6.4.3. Recording the Results of ARC Evaluation . . . . . . . 13 6.4.3. Recording the Results of ARC Evaluation . . . . . . . 14
6.4.4. Output Data Points from ARC Evaluation . . . . . . . 14 6.4.4. Output Data Points from ARC Evaluation . . . . . . . 14
6.4.5. Reporting ARC Effects for DMARC Local Policy . . . . 14 6.4.5. Reporting ARC Effects for DMARC Local Policy . . . . 14
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8.1. Authentication-Results Method Registry Update . . . . . . 14 8.1. Authentication-Results Method Registry Update . . . . . . 15
8.2. Definitions of the ARC header fields . . . . . . . . . . 15 8.2. Definitions of the ARC header fields . . . . . . . . . . 15
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 16 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9.1. GMail test reflector . . . . . . . . . . . . . . . . . . 17
10.1. Message Content Suspicion . . . . . . . . . . . . . . . 19 9.2. AOL test reflector and internal tagging . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.3. dkimpy patch . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . 19 9.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . 21 9.5. Mailman addition . . . . . . . . . . . . . . . . . . . . 19
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 22 9.6. Copernica/MailerQ web-based validation . . . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10.1. Message Content Suspicion . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . 22
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Appendix A. Appendix A - Example Usage (Obsolete but retained Appendix A. Appendix A - Example Usage (Obsolete but retained
for illustrative purposes) . . . . . . . . . . . . . 22 for illustrative purposes) . . . . . . . . . . . . . 23
A.1. Example 1: Simple mailing list . . . . . . . . . . . . . 22 A.1. Example 1: Simple mailing list . . . . . . . . . . . . . 23
A.1.1. Here's the message as it exits the Origin: . . . . . 22 A.1.1. Here's the message as it exits the Origin: . . . . . 23
A.1.2. Message is then received at example.org . . . . . . . 23 A.1.2. Message is then received at example.org . . . . . . . 24
A.1.3. Example 1: Message received by Recipient . . . . . . 25 A.1.3. Example 1: Message received by Recipient . . . . . . 26
A.2. Example 2: Mailing list to forwarded mailbox . . . . . . 26 A.2. Example 2: Mailing list to forwarded mailbox . . . . . . 27
A.2.1. Here's the message as it exits the Origin: . . . . . 26 A.2.1. Here's the message as it exits the Origin: . . . . . 27
A.2.2. Message is then received at example.org . . . . . . . 27 A.2.2. Message is then received at example.org . . . . . . . 28
A.2.3. Example 2: Message received by Recipient . . . . . . 31 A.2.3. Example 2: Message received by Recipient . . . . . . 32
A.3. Example 3: Mailing list to forwarded mailbox with source 33 A.3. Example 3: Mailing list to forwarded mailbox with source 34
A.3.1. Here's the message as it exits the Origin: . . . . . 33 A.3.1. Here's the message as it exits the Origin: . . . . . 34
A.3.2. Message is then received at example.org . . . . . . . 34 A.3.2. Message is then received at example.org . . . . . . . 35
A.3.3. Example 3: Message received by Recipient . . . . . . 39 A.3.3. Example 3: Message received by Recipient . . . . . . 40
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 41 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 42
Appendix C. Comments and Feedback . . . . . . . . . . . . . . . 42 Appendix C. Comments and Feedback . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
The development of strong domain authentication through Sender Policy The development of strong domain authentication through Sender Policy
Framework (SPF) [RFC7208] and DomainKeys Identified Mail (DKIM) Framework (SPF) [RFC7208] and DomainKeys Identified Mail (DKIM)
[RFC6376] has led to the implementation of the DMARC framework [RFC6376] has led to the implementation of the DMARC framework
[RFC7489] which extends the authentication to the author's "From:" [RFC7489] which extends the authentication to the author's "From:"
(RFC5322.From) field and permits publishing policies for non- (RFC5322.From) field and permits publishing policies for non-
compliant messages. Implicit within the DMARC framework is a compliant messages. Implicit within the DMARC framework is a
requirement that any intermediaries between the source system and requirement that any intermediaries between the source system and
skipping to change at page 7, line 42 skipping to change at page 7, line 50
field canonicalization. field canonicalization.
5.1.1.3. Deterministic 'h' Value for ARC-Seal 5.1.1.3. Deterministic 'h' Value for ARC-Seal
In this section, the term "scope" is used to indicate those header In this section, the term "scope" is used to indicate those header
fields signed by an ARC-Seal header field. A number in parentheses fields signed by an ARC-Seal header field. A number in parentheses
indicates the instance of that field, starting at 1. The suffix "- indicates the instance of that field, starting at 1. The suffix "-
no-b" is used with an ARC-Seal field to indicate that its "b" field no-b" is used with an ARC-Seal field to indicate that its "b" field
is empty at the time the signature is computed, as described in is empty at the time the signature is computed, as described in
Section 3.5 of [RFC6376]. "AAR" refers to ARC-Authentication- Section 3.5 of [RFC6376]. "AAR" refers to ARC-Authentication-
Results, "AMS" to ARC- Message-Signature, "AS" to ARC-Seal, and "ASB" Results, "AMS" to ARC-Message-Signature, "AS" to ARC-Seal, and "ASB"
to an ARC-Seal with an empty "b" tag. to an ARC-Seal with an empty "b" tag.
Generally, the scope of an ARC set for a message containing "n" ARC Generally, the scope of an ARC set for a message containing "n" ARC
sets is the concatenation of the following, for x (instance number) sets is the concatenation of the following, for x (instance number)
from 1 to n: from 1 to n:
o AAR(x); o AAR(x);
o AMS(x); o AMS(x);
o ASB(x) if x = n, else AS(x) o ASB(x) if x = n, else AS(x)
Thus for a message with no seals (i.e., upon injection), the scope of Thus for a message with no seals (i.e., upon injection), the scope of
the first ARC set is AAR(1):AMS(1):ASB(1). The ARC set thus the first ARC set is AAR(1):AMS(1):ASB(1). The ARC set thus
generated would produce a first ARC-Seal with a "b" value. The next generated would produce a first ARC-Seal with a "b" value. The next
ARC set would include in its signed content the prior scope, so it ARC set would include in its signed content the prior scope, so it
would have a scope of AAR(1):AMS(1):AS(1):AAR(2):AMS(2):ASB(2). would have a scope of AAR(1):AMS(1):AS(1):AAR(2):AMS(2):ASB(2).
Note: Typically header field sets appear within the header in Note: Typically header field sets appear within the header in
descending instance order. descending instance order.
skipping to change at page 9, line 5 skipping to change at page 9, line 15
5.1.1.5.1. Pseudocode to Determine Chain Value Status: 5.1.1.5.1. Pseudocode to Determine Chain Value Status:
In the algorith below, a "hop" is represented by the ARC set bearing In the algorith below, a "hop" is represented by the ARC set bearing
a particular instance number. The number of hops is the same as the a particular instance number. The number of hops is the same as the
highest instance number found in the ARC sets, or 0 (zero) if there highest instance number found in the ARC sets, or 0 (zero) if there
are no ARC sets found within the header. are no ARC sets found within the header.
"Success" means that the signature found in the referenced header "Success" means that the signature found in the referenced header
validates when against the content which was signed. validates when against the content which was signed.
if num_hops == 0: if (num_hops == 0) {
return "none" return "none"
else: } else {
if validate(latest_hop.AMS) != success: if (validate(latest_hop.AMS) != success) {
return "fail" return "fail"
} else {
for each hop (from highest instance to lowest): // note that instance is always >= 1 by definition
if (hop_num > 1 and hop.ARC-Seal.cv == "pass") or for each hop (from highest instance to lowest) {
(hop_num == 1 and hop.ARC-Seal.cv == "none"): if ((hop_num > 1 and hop.ARC-Seal.cv == "pass") or
if validate(hop.ARC-Seal) == success: (hop_num == 1 and hop.ARC-Seal.cv == "none")) {
next if (validate(hop.ARC-Seal) != success) {
else: return "fail"
}
} else {
return "fail" return "fail"
}
}
}
return "pass" return "pass"
}
5.1.2. ARC-Message-Signature 5.1.2. ARC-Message-Signature
The ARC-Message-Signature header field is a special variant of a The ARC-Message-Signature header field is a special variant of a
DKIM-Signature [RFC6376], using only the relaxed header DKIM-Signature [RFC6376], using only the relaxed header
canonicalization rules specified in [RFC6376]. canonicalization rules specified in [RFC6376].
The ARC-Message-Signature header field can appear multiple times in a The ARC-Message-Signature header field can appear multiple times in a
single message but each instance MUST have a unique "i=" value. single message but each instance MUST have a unique "i=" value.
skipping to change at page 10, line 36 skipping to change at page 11, line 5
5.1.3. ARC-Authentication-Results 5.1.3. ARC-Authentication-Results
ARC-Authentication-Results is a direct copy of the Authentication- ARC-Authentication-Results is a direct copy of the Authentication-
Results header field [RFC7601] created for archival purposes by the Results header field [RFC7601] created for archival purposes by the
each MTA outside of the trust boundary of the originating system each MTA outside of the trust boundary of the originating system
which is contributing to the chain of ARC header fields. The which is contributing to the chain of ARC header fields. The
corresponding instance ("i=") tag value MUST be prefixed to the corresponding instance ("i=") tag value MUST be prefixed to the
Authentication-Results. Authentication-Results.
The instance identifier MUST be separated from the rest of the
Authentication-Results value contents with a semi-colon (';', 0x3b).
The value of the header field (after removing comments) consists of The value of the header field (after removing comments) consists of
an instance identifier, an authentication identifier, and then a an instance identifier, an authentication identifier, and then a
series of statements and supporting data, as described in [RFC7601]. series of statements and supporting data, as described in [RFC7601].
The header field can appear multiple times in a single message but The header field can appear multiple times in a single message but
each instance MUST have a unique "i=" value. each instance MUST have a unique "i=" value.
5.1.3.1. 'i' Tag Value 5.1.3.1. 'i' Tag Value
ARC-Authentication-Results requires inclusion of an "i=" tag before ARC-Authentication-Results requires inclusion of an "i=" tag before
the "authserv-id" which indicates the ARC set to which it belongs as the "authserv-id" which indicates the ARC set to which it belongs as
described in the previous section (see Section 5.1.1.1). described in the previous section (see Section 5.1.1.1).
The "i=" tag MUST be separated from the rest of the Authentication-
Results value contents with a semi-colon (';', 0x3b).
5.2. Constructing the ARC-Seal Set 5.2. Constructing the ARC-Seal Set
The ARC-Seal is built in the same fashion as the analogous DKIM- The ARC-Seal is built in the same fashion as the analogous DKIM-
Signature [RFC6376], using the relaxed header canonicalization rules Signature [RFC6376], using the relaxed header canonicalization rules
specified in that document but with a strict ordering component for specified in that document but with a strict ordering component for
the header fields covered by the cryptographic signature: the header fields covered by the cryptographic signature:
1. The ARC sets MUST be ordered in descending instance (i=) order. 1. The ARC sets MUST be ordered in descending instance (i=) order.
2. The referenced ARC-Message-Signatures (matching i= value) MUST 2. The referenced ARC-Message-Signatures (matching i= value) MUST
skipping to change at page 16, line 34 skipping to change at page 17, line 8
According to [RFC6982], "this will allow reviewers and working groups According to [RFC6982], "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature. and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as It is up to the individual working groups to use this information as
they see fit". they see fit".
This information is known to be correct as of the third This information is known to be correct as of the third
interoperability test event which was held on 2016-06-17. interoperability test event which was held on 2016-06-17.
o GMail test reflector 9.1. GMail test reflector
Organization: Google Organization: Google
Description: Internal prototype implementation with both debug Description: Internal prototype implementation with both debug
analysis and validating + sealing pass-through function analysis and validating + sealing pass-through function
Status of Operation: Beta Status of Operation: Beta
Coverage: Full spec implemented as of [ARC-DRAFT] Coverage: Full spec implemented as of [ARC-DRAFT]
Licensing: Proprietary - Internal only Licensing: Proprietary - Internal only
Implementation Notes: Full functionality was demonstrated during Implementation Notes: Full functionality was demonstrated during the
the interop testing on 2016-06-17 interop testing on 2016-06-17
Contact Info: arc-discuss@dmarc.org [1] In place for reporting usage only as of 2016-11-21 on all GMail
flows.
o AOL test reflector Contact Info: arc-discuss@dmarc.org [1]
Organization: AOL 9.2. AOL test reflector and internal tagging
Description: Internal prototype implementation with both debug Organization: AOL
analysis and validating + sealing pass-through function
Status of Operation: Alpha Description: Internal prototype implementation with both debug
analysis and validating + sealing pass-through function
Coverage: ARC chain validity status checking is not operational, Status of Operation: Alpha
but otherwise this system conforms to [ARC-DRAFT]
Licensing: Proprietary - Internal only Coverage: ARC chain validity status checking is not operational, but
otherwise this system conforms to [ARC-DRAFT]
Implementation Notes: Full functionality with the exception of Licensing: Proprietary - Internal only
chain validity checking was demonstrated during the interop
testing on 2016-06-17
Contact Info: arc-discuss@dmarc.org [2] Implementation Notes: Full functionality with the exception of chain
validity checking was demonstrated during the interop testing on
2016-06-17
o dkimpy patch Available for production mail via selected account whitelisting for
test validation only.
Organization: OAR-DEV Contact Info: arc-discuss@dmarc.org [2]
Description: Patches to the dkimpy (Python DKIM) package 9.3. dkimpy patch
[https://launchpad.net/dkimpy] to add ARC functionality
Status of Operation: Beta Organization: OAR-DEV
Coverage: The test suite is incomplete, but the command line Description: Patches to the dkimpy (Python DKIM) package
validator was demonstrated to interoperate with the Google and AOL [https://code.launchpad.net/~dkimpy-hackers/dkimpy/trunk] to add ARC
implementations during the interop on 2016-06-17 functionality
Licensing: Open/Other (same as dkimpy package) Status of Operation: Beta
Implementation Notes: The patch has been submitted to the dkimpy Coverage: The test suite is incomplete, but the command line
maintainer for inclusion into the official package. validator was demonstrated to interoperate with the Google and AOL
implementations during the interop on 2016-06-17
Contact Info: arc-discuss@dmarc.org [3] Licensing: Open/Other (same as dkimpy package)
o OpenARC Implementation Notes: The patch has been submitted to the dkimpy
maintainer for inclusion into the official package.
Organization: TDP/Murray Kucherawy Released to the community as of 2016-11-12 at
[https://code.launchpad.net/~dkimpy-hackers/dkimpy/trunk]
Description: Implemention of milter functionality related to the Contact Info: arc-discuss@dmarc.org [3]
OpenDKIM and OpenDMARC packages
Status of Operation: Alpha 9.4. OpenARC
Coverage: Built to support [ARC-DRAFT]
Licensing: Open/Other (same as OpenDKIM and OpenDMARC packages) Organization: TDP/Murray Kucherawy
Implementation Notes: The build is FreeBSD oriented and takes some Description: Implemention of milter functionality related to the
tweaks to build on RedHat-based Linux platforms. Initial testing OpenDKIM and OpenDMARC packages
during the interop event on 2016-06-17 showed that it can be
operational, but the documentation regarding configuration
settings is unclear and the generated signature values do not
validate when compared to the Google, AOL or dkimpy
implementations.
Contact Info: arc-discuss@dmarc.org [4] Status of Operation: Alpha
o Mailman addition Coverage: Built to support [ARC-DRAFT]
Organization: Mailman development team Licensing: Open/Other (same as OpenDKIM and OpenDMARC packages)
Description: Integrated ARC capabilities within the Mailman Implementation Notes: The build is FreeBSD oriented and takes some
package tweaks to build on RedHat-based Linux platforms. Initial testing
during the interop event on 2016-06-17 showed that it can be
operational, but the documentation regarding configuration settings
is unclear and the generated signature values do not validate when
compared to the Google, AOL or dkimpy implementations.
Status of Operation: Implementation in progress Contact Info: arc-discuss@dmarc.org [4]
Coverage: Unknown 9.5. Mailman addition
Licensing: Same as mailman package - GPL Organization: Mailman development team
Implementation Notes: Incomplete at this time Description: Integrated ARC capabilities within the Mailman package
Contact Info: [https://www.gnu.org/software/mailman/contact.html] Status of Operation: Implementation in progress
Coverage: Unknown
Licensing: Same as mailman package - GPL
Implementation Notes: Incomplete at this time
Contact Info: [https://www.gnu.org/software/mailman/contact.html]
9.6. Copernica/MailerQ web-based validation
Organization: Copernica
Description: Web-based validation of ARC-signed messages
Status of Operation: Beta
Coverage: Built to support [ARC-DRAFT]
Licensing: On-line usage only,
Implementation Notes: Released 2016-10-24
Requires full message content to be pasted into a web form found at
[http://arc.mailerq.com/] (warning - https is not supported).
An additional instance of an ARC signature can be added if one is
willing to paste a private key into an unsecured web form.
Initial testing shows that results match the other implementations
listed in this section.
Contact Info: [https://www.copernica.com/]
10. Security Considerations 10. Security Considerations
The Security Considerations of [RFC6376] and [RFC7601] apply directly The Security Considerations of [RFC6376] and [RFC7601] apply directly
to this specification. to this specification.
Inclusion of ARC sets in the header of emails may cause problems for Inclusion of ARC sets in the header of emails may cause problems for
some older or more constrained MTAs if they are unable to accept the some older or more constrained MTAs if they are unable to accept the
greater size of the header. greater size of the header.
skipping to change at page 21, line 21 skipping to change at page 22, line 30
Message Authentication Status", RFC 7601, Message Authentication Status", RFC 7601,
DOI 10.17487/RFC7601, August 2015, DOI 10.17487/RFC7601, August 2015,
<http://www.rfc-editor.org/info/rfc7601>. <http://www.rfc-editor.org/info/rfc7601>.
11.2. Informative References 11.2. Informative References
[ARC-DRAFT] [ARC-DRAFT]
Andersen, K., Rae-Grant, J., Long, B., Adams, T., and S. Andersen, K., Rae-Grant, J., Long, B., Adams, T., and S.
Jones, "Authenticated Received Chain (ARC) Protocol Jones, "Authenticated Received Chain (ARC) Protocol
(I-D-05)", June 2016, <https://tools.ietf.org/html/draft- (I-D-05)", June 2016, <https://tools.ietf.org/html/draft-
andersen-arc-05>. ietf-dmarc-arc-protocol-00>.
[ARC-USAGE] [ARC-USAGE]
Jones, S., Adams, T., Rae-Grant, J., and K. Andersen, Jones, S., Adams, T., Rae-Grant, J., and K. Andersen,
"Recommended Usage of the ARC Headers", June 2016, "Recommended Usage of the ARC Headers", June 2016,
<https://tools.ietf.org/html/draft-ietf-dmarc-arc-usage- <https://tools.ietf.org/html/draft-ietf-dmarc-arc-usage-
00>. 00>.
[DMARC-INTEROP] [DMARC-INTEROP]
Martin, F., Lear, E., Draegen, T., Zwicky, E., and K. Martin, F., Lear, E., Draegen, T., Zwicky, E., and K.
Andersen, "Interoperability Issues Between DMARC and Andersen, "Interoperability Issues Between DMARC and
 End of changes. 60 change blocks. 
109 lines changed or deleted 162 lines changed or added

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