draft-ietf-dmarc-arc-protocol-07.txt   draft-ietf-dmarc-arc-protocol-08.txt 
skipping to change at page 1, line 13 skipping to change at page 1, line 13
DMARC Working Group K. Andersen DMARC Working Group K. Andersen
Internet-Draft LinkedIn Internet-Draft LinkedIn
Intended status: Standards Track B. Long, Ed. Intended status: Standards Track B. Long, Ed.
Expires: January 22, 2018 Google Expires: January 22, 2018 Google
S. Jones, Ed. S. Jones, Ed.
M. Kucherawy, Ed. M. Kucherawy, Ed.
TDP TDP
July 21, 2017 July 21, 2017
Authenticated Received Chain (ARC) Protocol Authenticated Received Chain (ARC) Protocol
draft-ietf-dmarc-arc-protocol-07 draft-ietf-dmarc-arc-protocol-08
Abstract Abstract
The Authenticated Received Chain (ARC) protocol creates a mechanism The Authenticated Received Chain (ARC) protocol creates a mechanism
whereby a series of handlers of a message can conduct authentication whereby a series of handlers of a message can conduct authentication
of a message as it passes among them on the way to its destination, of a message as it passes among them on the way to its destination,
and record the status of that authentication at each step along the and record the status of that authentication at each step along the
handling path, for use by the final recipient in making choices about handling path, for use by the final recipient in making choices about
the disposition of the message. the disposition of the message.
skipping to change at page 2, line 19 skipping to change at page 2, line 19
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Instance ('i=') Tags . . . . . . . . . . . . . . . . . . . . 5 4. Instance ('i=') Tags . . . . . . . . . . . . . . . . . . . . 5
4.1. Valid Range for Instance Tags . . . . . . . . . . . . . . 6 4.1. Valid Range for Instance Tags . . . . . . . . . . . . . . 6
5. The ARC Header Fields . . . . . . . . . . . . . . . . . . . . 6 5. The ARC Header Fields . . . . . . . . . . . . . . . . . . . . 6
5.1. ARC-Authentication-Results (AAR) . . . . . . . . . . . . 6 5.1. ARC-Authentication-Results (AAR) . . . . . . . . . . . . 6
5.1.1. Additional Information for the AAR Header . . . . . . 7
5.2. ARC-Message-Signature (AMS) . . . . . . . . . . . . . . . 7 5.2. ARC-Message-Signature (AMS) . . . . . . . . . . . . . . . 7
5.3. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . . . 7 5.3. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . . . 8
5.3.1. The 'cv' Tag . . . . . . . . . . . . . . . . . . . . 8 5.3.1. The 'cv' Tag . . . . . . . . . . . . . . . . . . . . 9
5.3.2. Selected Header Fields . . . . . . . . . . . . . . . 8 5.3.2. Selected Header Fields . . . . . . . . . . . . . . . 9
6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . 9 6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . 9
7. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . 10 7. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . 11
8. Key Management . . . . . . . . . . . . . . . . . . . . . . . 11 8. Key Management . . . . . . . . . . . . . . . . . . . . . . . 12
9. Usage of Chain Validity . . . . . . . . . . . . . . . . . . . 11 9. Usage of ARC and Chain Validity . . . . . . . . . . . . . . . 12
9.1. Assessing Chain Validity Violations . . . . . . . . . . . 11 9.1. Relationship between DKIM-Signature and AMS signing
9.2. Marking and Sealing Invalid Chains . . . . . . . . . . . 11 scopes . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.3. Handling DNS Problems While Validating ARC . . . . . . . 12 9.2. Assessing Chain Validity Violations . . . . . . . . . . . 12
9.4. Responding to ARC Validity Violations . . . . . . . . . . 12 9.3. Marking and Sealing "cv=fail" (Invalid) Chains . . . . . 12
9.5. Recording the Results of ARC Evaluation . . . . . . . . . 12 9.4. Handling DNS Problems While Validating ARC . . . . . . . 13
9.5.1. Output Information from an ARC Evaluation . . . . . . 12 9.5. Responding to ARC Validity Violations . . . . . . . . . . 13
9.5.2. Reporting ARC Effects for DMARC Local Policy - 9.6. Recording the Results of ARC Evaluation . . . . . . . . . 13
Interim . . . . . . . . . . . . . . . . . . . . . . . 13 9.6.1. Output Information from an ARC Evaluation . . . . . . 13
10. Supporting Alternate Signing Algorithms . . . . . . . . . . . 13 9.6.2. Reporting ARC Effects for DMARC Local Policy -
10.1. Introductory Period . . . . . . . . . . . . . . . . . . 14 Interim . . . . . . . . . . . . . . . . . . . . . . . 14
10.2. Co-Existence Period . . . . . . . . . . . . . . . . . . 14 10. Supporting Alternate Signing Algorithms . . . . . . . . . . . 14
10.3. Deprecation Period . . . . . . . . . . . . . . . . . . . 14 10.1. Introductory Period . . . . . . . . . . . . . . . . . . 15
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14 10.2. Co-Existence Period . . . . . . . . . . . . . . . . . . 15
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10.3. Deprecation Period . . . . . . . . . . . . . . . . . . . 15
12.1. Authentication-Results Method Registry Update . . . . . 14 10.4. Obsolescence Period . . . . . . . . . . . . . . . . . . 15
12.2. Definitions of the ARC header fields . . . . . . . . . . 15 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15
13. Implementation Status . . . . . . . . . . . . . . . . . . . . 15 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
13.1. GMail test reflector and incoming validation . . . . . . 16 12.1. Authentication-Results Method Registry Update . . . . . 15
13.2. AOL test reflector and internal tagging . . . . . . . . 16 12.2. Definitions of the ARC header fields . . . . . . . . . . 16
13.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 17 13. Implementation Status . . . . . . . . . . . . . . . . . . . . 17
13.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . 17 13.1. GMail test reflector and incoming validation . . . . . . 17
13.5. Mailman addition . . . . . . . . . . . . . . . . . . . . 18 13.2. AOL test reflector and internal tagging . . . . . . . . 18
13.6. Copernica/MailerQ web-based validation . . . . . . . . . 18 13.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 18
13.7. Rspamd . . . . . . . . . . . . . . . . . . . . . . . . . 19 13.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . 18
13.8. PERL Mail::Milter::Authentication module . . . . . . . . 19 13.5. Mailman 3.1+ patch . . . . . . . . . . . . . . . . . . . 19
13.6. Copernica/MailerQ web-based validation . . . . . . . . . 20
14. Security Considerations . . . . . . . . . . . . . . . . . . . 20 13.7. Rspamd . . . . . . . . . . . . . . . . . . . . . . . . . 20
14.1. Message Content Suspicion . . . . . . . . . . . . . . . 20 13.8. PERL Mail::Milter::Authentication module . . . . . . . . 21
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 14. Security Considerations . . . . . . . . . . . . . . . . . . . 21
15.1. Normative References . . . . . . . . . . . . . . . . . . 20 14.1. Message Content Suspicion . . . . . . . . . . . . . . . 22
15.2. Informative References . . . . . . . . . . . . . . . . . 22 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 23 15.1. Normative References . . . . . . . . . . . . . . . . . . 22
15.2. Informative References . . . . . . . . . . . . . . . . . 24
15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Appendix A. Appendix A - Example Usage (Obsolete but retained Appendix A. Appendix A - Example Usage (Obsolete but retained
for illustrative purposes) . . . . . . . . . . . . . 23 for illustrative purposes) . . . . . . . . . . . . . 25
A.1. Example 1: Simple mailing list . . . . . . . . . . . . . 23 A.1. Example 1: Simple mailing list . . . . . . . . . . . . . 25
A.1.1. Here's the message as it exits the Origin: . . . . . 23 A.1.1. Here's the message as it exits the Origin: . . . . . 25
A.1.2. Message is then received at example.org . . . . . . . 24 A.1.2. Message is then received at example.org . . . . . . . 26
A.1.3. Example 1: Message received by Recipient . . . . . . 26 A.1.3. Example 1: Message received by Recipient . . . . . . 28
A.2. Example 2: Mailing list to forwarded mailbox . . . . . . 27 A.2. Example 2: Mailing list to forwarded mailbox . . . . . . 29
A.2.1. Here's the message as it exits the Origin: . . . . . 27 A.2.1. Here's the message as it exits the Origin: . . . . . 29
A.2.2. Message is then received at example.org . . . . . . . 28 A.2.2. Message is then received at example.org . . . . . . . 30
A.2.3. Example 2: Message received by Recipient . . . . . . 32 A.2.3. Example 2: Message received by Recipient . . . . . . 34
A.3. Example 3: Mailing list to forwarded mailbox with source 34 A.3. Example 3: Mailing list to forwarded mailbox with source 36
A.3.1. Here's the message as it exits the Origin: . . . . . 34 A.3.1. Here's the message as it exits the Origin: . . . . . 36
A.3.2. Message is then received at example.org . . . . . . . 35 A.3.2. Message is then received at example.org . . . . . . . 37
A.3.3. Example 3: Message received by Recipient . . . . . . 40 A.3.3. Example 3: Message received by Recipient . . . . . . 42
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 42 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 44
Appendix C. Comments and Feedback . . . . . . . . . . . . . . . 43 Appendix C. Comments and Feedback . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
1. Introduction 1. Introduction
Modern email authentication techniques such as the Sender Policy Modern email authentication techniques such as the Sender Policy
Framework (SPF) [RFC7208] and DomainKeys Identified Mail (DKIM) Framework (SPF) [RFC7208] and DomainKeys Identified Mail (DKIM)
[RFC6376] have become ubiquitious. However, they are stymied by a [RFC6376] have become ubiquitious. However, they are stymied by a
small number of common applications, most notably mailing list small number of common applications, most notably mailing list
managers, as these applications have handling properties that prevent managers, as these applications have handling properties that prevent
these authentication schemes from universal effectiveness. These these authentication schemes from universal effectiveness. These
issues are described in substantial detail in those protocols' issues are described in substantial detail in those protocols'
defining documents as well as in [RFC6377]. defining documents as well as in [RFC6377] and [RFC7960].
In an effort to reduce the success of fraudulent email campaigns, In an effort to reduce the success of fraudulent email campaigns,
there has been an effort to develop and deploy technologies that use there has been an effort to develop and deploy technologies that use
SPF and DKIM to assure legitimate use of the identity of the apparent SPF and DKIM to assure legitimate use of the identity of the apparent
message author, i.e., the visible "From:" field in a message. To message author, i.e., the visible "From:" field in a message. To
this end, Domain-based Mail Authentication, Reporting and Compliance this end, Domain-based Mail Authentication, Reporting and Compliance
(DMARC) [RFC7489] has been developed and deployed. However, its (DMARC) [RFC7489] has been developed and deployed. However, its
deployment in environments where mailing lists are used has had the deployment in environments where mailing lists are used has had the
negative impacts predicted in the documents listed above. negative impacts predicted in the documents listed above.
What is needed is a mechanism by which legitimate alteration of a What is needed is a mechanism by which legitimate alteration of a
message, invalidating SPF and DKIM, does not ultimately result in a message, invalidating SPF and DKIM, does not ultimately result in a
rejection of an email message on delivery. An Authenticated Received rejection of an email message on delivery. An Authenticated Received
Chain (ARC), described here, provides a superset of the functionality Chain (ARC), described here, provides a superset of the functionality
of DKIM in order to provide to the final message recipient a more of DKIM in order to provide to the message recipient system(s) a more
complete view into the handling chain of a message and the points in complete view into the handling chain of a message and the points in
that chain where alterations of the content may have occurred. that chain where alterations of the content may have occurred.
Equipped with this more compelte information, the final recipient can Equipped with this more complete information, the recipient system(s)
make a more informed handling choice, reducing or eliminating the can make a more informed handling choice, reducing or eliminating the
false postives inherent in use of DKIM and/or SPF themselves. false postives inherent in use of DKIM and/or SPF themselves.
2. Overview 2. Overview
In DKIM, every participating signing agent attaches a signature that In DKIM, every participating signing agent attaches a signature that
is based on the content of the message, local policy, and the domain is based on the content of the message, local policy, and the domain
name of the participating Administrative Management Domain (ADMD). name of the participating Administrative Management Domain (ADMD).
Any verifier can process such a signature; a verified signature means Any verifier can process such a signature; a verified signature means
the message content that was "covered" by the signature has not been the message content that was "covered" by the signature has not been
altered since the signature was applied. The signatures themselves altered since the signature was applied. The signatures themselves
are generally independent of one another. are generally independent of one another.
By contrast, this protocol seeks to have each signature be able to By contrast, this protocol seeks to have each signature be able to
convey the following pieces of information: convey the following pieces of information:
1. As with DKIM, an assertion that, for a passing signature, the 1. An assertion that, at the time that the intermediary ADMD
processed the message, the various assertions already attached to
the message by other ADMDs were or were not valid;
2. As with DKIM, an assertion that, for a passing signature, the
domain name in the signature takes some responsibility for domain name in the signature takes some responsibility for
handling of the message and that the message is unchanged since handling of the message and that the message is unchanged since
that signature was applied; that signature was applied;
2. A further assertion that, at the time that same ADMD processed
the message, the various assertions already attached to the
message by other ADMDs were or were not valid;
3. A further assertion that combines and protects the above against 3. A further assertion that combines and protects the above against
alteration by later handlers. alteration by later handlers.
This protocol accomplishes each of these by adding a new header field This protocol accomplishes each of these by adding a new header field
to the message for each of them, as follows: to the message for each of them, as follows:
o ARC-Authentication-Results: (referred to below as "AAR") virtually o ARC-Authentication-Results (referred to below as "AAR"): virtually
identical in syntax to an Authentication-Results field [RFC7601], identical in syntax to an Authentication-Results field [RFC7601],
this field records the results of all message authentication this field records the results of all message authentication
checks done by the recording ADMD at the time the message arrived; checks done by the recording ADMD at the time the message arrived.
Additional information is added to this field compared to a
standard Authentication-Results field in order to support a more
complete DMARC report (see Section 5.1);
o ARC-Message-Signature: (referred to below as "AMS") virtually o ARC-Message-Signature (referred to below as "AMS"): virtually
identical in syntax to DKIM-Signature, this field contains the identical in syntax to DKIM-Signature, this field contains the
assertions about the message header and body as they existed at assertions about the message header and body as they existed at
the time of handling by the ADMD adding it; and the time of handling by the ADMD adding it; and
o ARC-Seal: (referred to below as "AS") highly similar in structure o ARC-Seal (referred to below as "AS"): highly similar in structure
and format to a DKIM-Signature, this field applies a digital and format to a DKIM-Signature, this field applies a digital
signature that protects the integrity of all three of these new signature that protects the integrity of all three of these new
fields when they are added by an ADMD, plus all instances of these fields when they are added by an ADMD, plus all instances of these
fields added by prior ADMDs. fields added by prior ADMDs.
A distinguishing feature of all of these is that an ARC participant A distinguishing feature of all of these is that an ARC participant
always adds all of them before relaying a message to the next always adds all of them before relaying a message to the next
handling agent en route to its destination. Moreover, as described handling agent en route to its destination. Moreover, as described
in Section 4, they each have an "instance" number that increases with in Section 4, they each have an "instance" number that increases with
each ADMD in the handling chain so that their original order can be each ADMD in the handling chain so that their original order can be
skipping to change at page 5, line 29 skipping to change at page 5, line 38
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Readers are encouraged to be familiar with the contents of [RFC5598], Readers are encouraged to be familiar with the contents of [RFC5598],
and in particular, the potential roles of intermediaries in the and in particular, the potential roles of intermediaries in the
delivery of email. delivery of email.
Syntax descriptions use Augmented BNF (ABNF) [RFC5234]. Syntax descriptions use Augmented BNF (ABNF) [RFC5234].
A single group of the header fields introduced in Section 2 is called A single group of the header fields introduced in Section 2 is called
an "ARC Set", and the complete sequence of these groups is called an an "ARC set", and the complete sequence of these groups is called an
"Authenticated Received Chain" or merely an "ARC chain". Although "Authenticated Received Chain" or merely an "ARC chain". Although
the "Received" header field is typically not included in the signed the "Received" header field is typically not included in the signed
content, the name is based on the notion that this is in essence a content, the name is based on the notion that this is in essence a
cryptographically signed series of header fields that attest to the cryptographically signed series of header fields that attest to the
handling chain of a message much as Received fields always have. handling chain of a message much as Received fields always have.
4. Instance ('i=') Tags 4. Instance ('i=') Tags
The header fields comprising a single ARC set are identified by the The header fields comprising a single ARC set are identified by the
presence of a string in the value portion of the header field that presence of a string in the value portion of the header field that
complies with the "tag-spec" ABNF found in Section 3.2 of [RFC6376]. complies with the "tag-spec" ABNF found in Section 3.2 of [RFC6376].
The tag-name is always the single character "i" and the value is the The tag-name is always the single character "i" and the value is the
text representation of a positive integer, indicating the position in text representation of a positive integer, indicating the position in
the ARC sequence this set occupies, where the first ARC set is the ARC sequence this set occupies, where the first ARC set is
numbered 1. In ABNF terms: numbered 1. In ABNF terms:
instance = [FWS] %x69 [FWS] "=" [FWS] 1*DIGIT [FWS] ";" instance = [FWS] %x69 [FWS] "=" [FWS] 1*DIGIT [FWS] ";"
At any delivery stage, it is an error if any ARC set is invalid At any delivery stage, it is an error if any ARC set is invalid
(i.e., does not contain exactly one of the three header fields (i.e., does not contain exactly one of the three header fields
defined by this protocol). defined by this protocol). (Note that when multiple algorithms are
supported, there is some nuance to this statement - see Section 10.)
Note that because the AMS and AS header field values are made up of Note that because the AMS and AS header field values are made up of
tag-spec constructs, the i= tag may be found anywhere within the tag-spec constructs, the i= tag may be found anywhere within the
header field value, but is represented throughout this spec in the header field value, but is represented throughout this spec in the
initial position for convenience. Implementers SHOULD seek to start initial position for convenience. Implementers SHOULD seek to start
with the i= tag to facilitate human inspection of the headers. with the i= tag to facilitate human inspection of the headers.
4.1. Valid Range for Instance Tags 4.1. Valid Range for Instance Tags
The 'i' tag value can range from 1-1024 (inclusive). The 'i' tag value can range from 1-1024 (inclusive).
skipping to change at page 6, line 26 skipping to change at page 6, line 35
steps. steps.
More than fifty (50) intermediaries is considered extremely unlikely More than fifty (50) intermediaries is considered extremely unlikely
so ARC chains with more than fifty intermediaries may be marked with so ARC chains with more than fifty intermediaries may be marked with
"cv=fail". "cv=fail".
5. The ARC Header Fields 5. The ARC Header Fields
The three header fields that are part of this specification borrow The three header fields that are part of this specification borrow
heavily from existing specifications. Rather than repeating all of heavily from existing specifications. Rather than repeating all of
the formal definitions that are being recycled in ARC, this document the formal definitions that are being reused in ARC, this document
instead only describes and specifies changes in syntax and semantics. only describes and specifies changes in syntax and semantics.
5.1. ARC-Authentication-Results (AAR) 5.1. ARC-Authentication-Results (AAR)
The ARC-Authentication-Results header field is defined. It is The ARC-Authentication-Results header field is defined. It is
syntactically and semantically identical to an Authentication-Results syntactically and semantically identical to an Authentication-Results
header field [RFC7601] (A-R), as is the mechanism by which it is header field [RFC7601] (A-R), as is the mechanism by which it is
constructed, with the following exception: constructed, with the following exception:
o There is an "i" tag, as described in Section 4. o There is an "i" tag, as described in Section 4; and
o Two (or more) additional pieces of information MAY be added (see
Section 5.1.1).
The instance identifier MUST be separated from the rest of the The instance identifier MUST be separated from the rest of the
Authentication-Results value contents with a semi-colon (';', 0x3b). Authentication-Results value contents with a semi-colon (';', 0x3b).
The purpose of this header field is to incorporate into the record
the success or failure of any authentication done on the message
upstream of the participating ADMD, to validate and continue the
authentication chain.
In processing, some architectures will generate multiple A-R records
for the same authserv-id. In such cases, the resinfo value from each
of the A-R records should be concatenated into a single record just
as they would have been if they were generated in a single A-R
record.
5.1.1. Additional Information for the AAR Header
An ARC signer generates this field in the same way that a An ARC signer generates this field in the same way that a
conventional A-R field would be generated. Because the AAR is conventional A-R field would be generated. Because the AAR is
designed for machine-based consumption over the course of a message's designed for machine-based consumption over the course of a message's
transit through a series of mediators and to facilitate transit through a series of mediators and to facilitate
troubleshooting of problematic sources by sending organizations, two troubleshooting of problematic sources by sending organizations,
additional fields of data SHOULD be added to the normal A-R content, three additional fields of data SHOULD be added to the normal A-R
if available to the A-R generating system: content, dependent on the presence of DKIM-Signature and/or ARC
set(s) and if available to the ADMD which is recording the A-R:
o source.ip - The connecting client IP address from which the o source.ip - The connecting client IP address from which the
message is received; and message is received; and
o header.s - The selector value associated with each dkim signature o header.s - The selector value associated with each dkim signature
(added to the dkim or arc data sections of the A-R/AAR record (added to the dkim data sections of the A-R/AAR record)
The purpose of this header field is to incorporate into the record o ARC-related data (added to the arc data sections of the A-R/AAR
the success or failure of any authentication done on the message record):
upstream of the participating ADMD, to validate and continue the
authentication chain.
In processing, some architectures will generate multiple A-R records * ams[N].d - The domain value associated with the 'N'th ARC set's
for the same authserv-id. In such cases, the resinfo value from each AMS header
of the A-R records should be concatenated into a single record just
as they would have been if they were generated in a single A-R * ams[N].s - The selector associated with the 'N'th ARC set's AMS
record. header
* as[N].d - The domain value associated with the 'N'th ARC set's
AS header
* as[N].s - The selector associated with the 'N'th ARC set's AS
header
5.2. ARC-Message-Signature (AMS) 5.2. ARC-Message-Signature (AMS)
The ARC-Message-Signature header field is defined. It is The ARC-Message-Signature header field is defined. It is
syntactically and semantically identical to a DKIM-Signature header syntactically and semantically identical to a DKIM-Signature header
field [RFC6376], as is the mechanism by which it is constructed, with field [RFC6376], as is the mechanism by which it is constructed, with
the following exceptions: the following exceptions:
o There is an "i" tag, as described in Section 4. o There is an "i" tag, as described in Section 4.
o There is no "v" tag. o There is no "v" tag.
o ARC-Seal header fields MUST never be included in the content ARC-Seal header fields MUST never be included in the content covered
covered by the signature in this header field. by the signature in this header field.
The AMS SHOULD include any DKIM-Signature header fields already The AMS SHOULD include any DKIM-Signature header fields already
present on the message in the header fields covered by this present on the message in the header fields covered by this
signature. signature.
The AMS header field MAY inclue (sign) the AAR header field(s).
Authentication-Results header fields SHOULD NOT be included since Authentication-Results header fields SHOULD NOT be included since
they are likely to be deleted by downstream ADMDs, thereby breaking they are likely to be deleted by downstream ADMDs (per Section XXX of
the AMS signature. [RFC7601]), thereby breaking the AMS signature.
As with a DKIM-Signature, the purpose of this header field is to As with a DKIM-Signature, the purpose of this header field is to
allow the ADMD generating it to take some responsibility for handling allow the ADMD generating it to take some responsibility for handling
this message as it progresses toward delivery. this message as it progresses toward delivery.
5.3. ARC-Seal (AS) 5.3. ARC-Seal (AS)
The ARC-Seal header field is defined. It is syntactically and The ARC-Seal header field is defined. It is syntactically and
semantically similar to a DKIM-Signature field, with the following semantically similar to a DKIM-Signature field, with the following
exceptions: exceptions:
skipping to change at page 8, line 25 skipping to change at page 9, line 9
o An additional tag, "cv" is defined. (See below: Section 5.3.1) o An additional tag, "cv" is defined. (See below: Section 5.3.1)
The purpose of this field is to assure the integrity of the ARC set The purpose of this field is to assure the integrity of the ARC set
being added by the ADMD generating this header field, and moreover to being added by the ADMD generating this header field, and moreover to
ensure no tampering with the ARC overall. ensure no tampering with the ARC overall.
5.3.1. The 'cv' Tag 5.3.1. The 'cv' Tag
A new tag "cv" (chain validation) is defined, which indicates the A new tag "cv" (chain validation) is defined, which indicates the
state of the ARC chain as evaluated when it arrived at the ADMD state of the ARC chain as evaluated when it arrived at the ADMD
adding this header field. It includes one of three possible values: adding this header field. It accepts one of three possible values:
o none: There was no chain on the message when it arrived for o none: There was no chain on the message when it arrived for
validation; typically occurs when the message arrives at a Message validation; typically occurs when the message arrives at a Message
Transfer Agent (MTA) from a Message Submission Agent (MSA) or when Transfer Agent (MTA) from a Message Submission Agent (MSA) or when
any upstream MTAs may not be participating in ARC handling; any upstream MTAs may not be participating in ARC handling;
o fail: The message has a chain whose validation failed; o fail: The message has a chain whose validation failed;
o pass: The message has a chain whose validation succeeded. o pass: The message has a chain whose validation succeeded.
In ABNF terms: In ABNF terms:
seal-cv-tag = %x63.76 [FWS] "=" [FWS] seal-cv-tag = %x63.76 [FWS] "=" [FWS] ("none" / "fail" / "pass")
("none" / "fail" / "pass")
5.3.2. Selected Header Fields 5.3.2. Selected Header Fields
The ARC-Seal signature is an encryption of the hash of the The ARC-Seal signature is an encryption of the hash of the
concatenation of the canonicalized form of the ARC sets present on concatenation of the canonicalized form of the ARC sets present on
the message at the time of sealing, in increasing instance order, the message at the time of sealing, in increasing instance order,
starting at 1, including the one being added at the time of sealing starting at 1, including the one being added at the time of sealing
the message. the message.
Within a set, the header fields are presented in the following order: Within a set, the header fields are presented in the following order:
skipping to change at page 9, line 4 skipping to change at page 9, line 35
The ARC-Seal signature is an encryption of the hash of the The ARC-Seal signature is an encryption of the hash of the
concatenation of the canonicalized form of the ARC sets present on concatenation of the canonicalized form of the ARC sets present on
the message at the time of sealing, in increasing instance order, the message at the time of sealing, in increasing instance order,
starting at 1, including the one being added at the time of sealing starting at 1, including the one being added at the time of sealing
the message. the message.
Within a set, the header fields are presented in the following order: Within a set, the header fields are presented in the following order:
1. ARC-Authentication-Results 1. ARC-Authentication-Results
2. ARC-Message-Signature 2. ARC-Message-Signature
3. ARC-Seal 3. ARC-Seal
Where the ARC-Seal is the one being generated, it is presented to the Where the ARC-Seal is the one being generated, it is presented to the
hash function in its final form except with an empty "b=" value, in hash function in its final form except with an empty "b=" value, in
the same manner by which a DKIM-Signature signs itself. the same manner by which a DKIM-Signature signs itself.
Note that the signing scope for the ARC-Seal is modified in the
situation where a chain has failed validation (see Section 9.3).
6. Verifier Actions 6. Verifier Actions
The verifier takes the following steps to determine the current state The verifier takes the following steps to determine the current state
of the ARC on the message: of the ARC on the message:
1. Collect all ARC sets currently on the message. If there were 1. Collect all ARC sets currently on the message. If there were
none, the ARC state is "none" and the algorithm stops here. none, the ARC state is "none" and the algorithm stops here.
2. If any ARC set is invalid (e.g., does not contain exactly one of 2. If any ARC set is invalid (e.g., does not contain exactly one of
each of the three ARC-specific header fields), then the chain each of the three ARC-specific header fields), then the chain
state is "fail" and the algorithm stops here. state is "fail" and the algorithm stops here.
1. To bypass all cryto and DNS operations, the cv value for all
ARC-Seal(s) MAY be checked at this point. If any of the
values are "fail", then the overall state of the chain is
"fail" and the algorithm stops here.
3. Conduct verification of the ARC-Message-Signature header field 3. Conduct verification of the ARC-Message-Signature header field
bearing the highest instance number. If this verification fails, bearing the highest instance number. If this verification fails,
then the chain state is "fail" and the algorithm stops here. then the chain state is "fail" and the algorithm stops here.
4. For each ARC-Seal from the "N"th instance to the first, apply the 4. For each ARC-Seal from the "N"th instance to the first, apply the
following logic: following logic:
1. If the value of the "cv" tag on that seal is "fail", the 1. If the value of the "cv" tag on that seal is "fail", the
chain state is "fail" and the algorithm stops here. chain state is "fail" and the algorithm stops here. (note
that this duplicates step 2.1)
2. If the instance number being processed is greater than 1 and
the value of the "cv" tag is "none", the chain state is
"fail" and the algorithm stops here.
3. If the instance number being processed is 1 and the value of 2. In Boolean nomenclature: if ((i == 1 && cv != "none") or (cv
the "cv" tag is not "none", the chain state is "fail" and the == "none" && i != 1)) then the chain state is "fail" and the
algorithm stops here. algorithm stops here.
4. Prepare a hash function corresponding to the "a" tag of the 3. Prepare a hash function corresponding to the "a" tag of the
ARC-Seal. ARC-Seal.
5. Compute the canonicalized form of the ARC header fields, in 4. Compute the canonicalized form of the ARC header fields, in
the order described in Section 5.3.2, using the "relaxed" the order described in Section 5.3.2, using the "relaxed"
header canonicalization defined in (Section 3.4.2 of header canonicalization defined in Section 3.4.2 of
[RFC6376]. Pass them to the hash function. [RFC6376]. Pass them to the hash function.
6. Retrieve the final digest from the hash function. 5. Retrieve the final digest from the hash function.
7. Retrieve the public key identified by the "s" and "d" tags in 6. Retrieve the public key identified by the "s" and "d" tags in
the ARC-Seal, as described in Section 8. the ARC-Seal, as described in Section 8.
8. Determine whether the signature portion ("b" tag) of the ARC- 7. Determine whether the signature portion ("b" tag) of the ARC-
Seal and the digest computed above are valid according to the Seal and the digest computed above are valid according to the
public key. public key.
9. If the signature is not valid, the chain state is "fail" and 8. If the signature is not valid, the chain state is "fail" and
the algorithm stops here. the algorithm stops here.
5. If all seals pass validation, then the chain state is "pass", and 5. If all seals pass validation, then the chain state is "pass", and
the algorithm is complete. the algorithm is complete.
The verifier should record the cv state for subsequent use by any The verifier should record the cv state for subsequent use by any
sealing which may be done later (potentially after message sealing which may be done later (potentially after message
modification) within the same trust boundary. The cv state may be modification) within the same trust boundary. The cv state may be
recorded by sealing at the time of verification in an additional ARC recorded by sealing at the time of verification in an initial ARC set
set or may be recorded out of band depending on the architecture of (for the ADMD) or may be recorded out of band depending on the
the ADMD. architecture of the ADMD.
7. Signer Actions 7. Signer Actions
This section includes a walk-through of the actions an ARC signing This section includes a walk-through of the actions an ARC signing
implementation takes when presented with a message. implementation takes when presented with a message.
The signing agent should undertake the following steps: The signing agent should undertake the following steps:
1. Do any authentication steps that the ADMD normally does: 1. Do any authentication steps that the ADMD normally does:
1. If a message is traveling within the same trust boundary, 1. If a message is traveling within the same trust boundary,
this would include any transitive trust conveyance with the this would include any internal trust conveyed with the
message; message;
2. If a message is coming from outside the same trust boundary, 2. If a message is coming from outside the same trust boundary,
this would include any SPF / DKIM / DMARC / other this would include any SPF / DKIM / DMARC / other
authentication evaluation steps. authentication evaluation steps.
2. Do any DKIM signing or authentication assertion steps that the 2. Do any DKIM signing or authentication assertion steps that the
ADMD normally does. ADMD normally does.
3. Generate and optionally attach to the message an Authentication- 3. Generate and optionally attach to the message an Authentication-
Results header field using the ADMD's authserv-id (see Results header field using the ADMD's authserv-id (see
Section 2.5 of [RFC7601]) indicating whatever authentication Section 2.5 of [RFC7601]) indicating whatever authentication
might have been done by the MTA, or possibly indicate that none might have been done by the MTA, or possibly indicate that none
was done. was done.
4. Build and attach the new ARC set:
1. If an ARC chain exists on the message, then set "N" equal to 1. If an ARC chain exists on the message, then set "N" equal to
the highest instance number found on the chain (i=); the highest instance number found on the chain (i=);
otherwise set "N" equal to zero for the following steps. otherwise set "N" equal to zero for the following steps.
4. Generate and attach to the message an ARC-Authentication-Results 2. Generate and attach to the message an ARC-Authentication-
header field using instance number N+1 and the same content from Results header field using instance number N+1 and the same
the previous step. content from the previous step.
5. Generate and attach to the message an ARC-Message-Signature 3. Generate and attach to the message an ARC-Message-Signature
header field using the general algorithm described in Section 5 header field using the general algorithm described in
of [RFC6376] and as modified in Section 5.1 above, using instance Section 5 of [RFC6376] and as modified in Section 5.1 above,
number N+1. using instance number N+1.
6. Generate and attach to the message an ARC-Seal header field using 4. Generate and attach to the message an ARC-Seal header field
the general algorithm described in Section 5.3 above, using a using the general algorithm described in Section 5.3 above,
chain validation status as determined in Section 6 and instance the chain validation status as determined in Section 6, and
number N+1. instance number N+1.
8. Key Management 8. Key Management
The public keys for ARC header fields follow the same requirements, The public keys for ARC header fields follow the same requirements,
syntax and semantics as those for DKIM signatures, described in syntax and semantics as those for DKIM signatures, described in
Section 3.6 of [RFC6376]. Operators may use distinct selectors and/ Section 3.6 of [RFC6376]. Operators may use distinct selectors and/
or domains for the ARC header fields at their own discretion. or domains for the ARC header fields at their own discretion.
9. Usage of Chain Validity 9. Usage of ARC and Chain Validity
9.1. Assessing Chain Validity Violations 9.1. Relationship between DKIM-Signature and AMS signing scopes
DKIM-Signatures SHOULD never sign any ARC header fields.
9.2. Assessing Chain Validity Violations
There are a wide variety of ways in which the ARC set of header There are a wide variety of ways in which the ARC set of header
fields can be broken. Receivers need to be wary of ascribing motive fields can be broken. Receivers need to be wary of ascribing motive
to such breakage although patterns of common behaviour may provide to such breakage although patterns of common behaviour may provide
some basis for adjusting local policy decisions. some basis for adjusting local policy decisions.
This specification is exclusively focused on well-behaved, This specification is exclusively focused on well-behaved,
participating intermediaries that result in a valid chain of ARC- participating intermediaries that result in a valid chain of ARC-
related header fields. The value of such a well-formed, valid chain related header fields. The value of such a well-formed, valid chain
needs to be interpreted with care since malicious content can be needs to be interpreted with care since malicious content can be
easily introduced by otherwise well-intended senders through machine easily introduced by otherwise well-intended senders through machine
or account compromises. All normal content-based analysis still or account compromises. All normal content-based analysis still
needs to be performed on any messages bearing a valid chain of ARC needs to be performed on any messages bearing a valid chain of ARC
header sets. header sets.
9.2. Marking and Sealing Invalid Chains 9.3. Marking and Sealing "cv=fail" (Invalid) Chains
The header fields signed by the AS header field b= value in the case The header fields signed by the AS header field b= value in the case
of a major violation MUST be only the matching 'i=' instance headers of a chain failure MUST be only the matching 'i=' instance headers
created by the MTA which detected the malformed chain, as if this created by the MTA which detected the malformed chain, as if this
newest ARC set was the only set present. (This is the same procedure newest ARC set was the only set present.
required for handling major/structural validity problems.)
9.3. Handling DNS Problems While Validating ARC 9.4. Handling DNS Problems While Validating ARC
DNS failures to resolve or return data which is needed for ARC DNS failures to resolve or return data which is needed for ARC
validation SHOULD result in a 421 tempfail during the SMTP validation SHOULD result in a 421 tempfail during the SMTP
conversation with the sending system. Temporary or intermittent DNS conversation with the sending system. Temporary or intermittent DNS
problems will generally not be sufficiently transitory to allow a problems will generally not be sufficiently transitory to allow a
mediator to obtain a different result during the ordinary transit mediator to obtain a different result during the ordinary transit
duration so it is better to have the source system queue the duration so it is better to have the source system queue the
problematic message(s) than to generate (potential) backscatter. problematic message(s) than to generate (potential) backscatter.
Operators of systems which mediate mail should be aware that broken
DNS records (or malfunctioning name servers) will result in
undeliverable mail to any downstream ARC-verifying ADMDs.
DNS-based failures to verify a chain are treated no differently than DNS-based failures to verify a chain are treated no differently than
any other ARC violation. They result in a cv=fail verdict. any other ARC violation. They result in a "cv=fail" verdict.
9.4. Responding to ARC Validity Violations 9.5. Responding to ARC Validity Violations
If a receiver determines that the ARC chain has failed, the receiver If a receiver determines that the ARC chain has failed, the receiver
MAY signal the breakage through the extended SMTP response code 5.7.7 MAY signal the breakage through the extended SMTP response code 5.7.7
[RFC3463] "message integrity failure" [ENHANCED-STATUS] and [RFC3463] "message integrity failure" [ENHANCED-STATUS] and
corresponding SMTP response code. corresponding SMTP response code.
9.5. Recording the Results of ARC Evaluation 9.6. Recording the Results of ARC Evaluation
Receivers MAY add an "arc=[pass|fail|policy]" method annotation into Receivers MAY add an "arc=[pass|fail|policy]" method annotation into
a locally-affixed Authentication-Results [RFC7601] header field along a locally-affixed Authentication-Results [RFC7601] header field along
with any salient comment(s). with any salient comment(s).
9.5.1. Output Information from an ARC Evaluation 9.6.1. Output Information from an ARC Evaluation
The evaluation of a series of ARC sets results in the following data The evaluation of a series of ARC sets results in the following data
which MAY be used to inform local-policy decisions: which MAY be used to inform local-policy decisions:
o A list of the "d=" domains found in the validated (== all) ARC- o A list of the "d=" domains found in the validated ARC-Seal header
Seal header fields; fields;
o The "d=" domain found in the most recent (highest instance number) o The "d=" domain found in the most recent (highest instance number)
AMS header field (since that is the only one necessarily AMS header field (since that is the only one necessarily
validated) validated)
In the case of a failed chain, only the terminal ARC set is covered In the case of a failed chain, only the terminal ARC set is covered
by the ARC-Seal so the reporting is limited to the findings in that by the ARC-Seal so the reporting is limited to the findings in that
terminal ARC set. terminal ARC set.
9.5.2. Reporting ARC Effects for DMARC Local Policy - Interim 9.6.2. Reporting ARC Effects for DMARC Local Policy - Interim
[[ Note: Discussion on the IETF DMARC-WG list has indicated some [[ Note: Discussion on the IETF DMARC-WG list has indicated some
interest in more substantial reporting for analytic purposes. To interest in more substantial reporting for analytic purposes. To
support that effort, the following guidance is provided only as an support that effort, the following guidance is provided only as an
interim, minimal data set. A more complete reporting construct will interim, minimal data set. A more complete reporting construct will
be specified in a related spec - TBD. (see also the note at be specified in a related spec - TBD. (see the additional fields
Section 5.1) ]] specified in Section 5.1.1) ]]
Receivers SHOULD indicate situations in which ARC evaluation Receivers SHOULD indicate situations in which ARC evaluation
influenced the results of their local policy determination. DMARC influenced the results of their local policy determination. DMARC
reporting of ARC-informed decisions is augmented by adding a reporting of ARC-informed decisions is augmented by adding a
local_policy comment explanation containing the list of data local_policy comment explanation containing the list of data
discovered in the ARC evaluation (Section 9.5.1): discovered in the ARC evaluation (Section 9.6.1 and Section 5.1.1):
<policy_evaluated> <policy_evaluated>
<disposition>delivered</disposition> <disposition>delivered</disposition>
<dkim>fail</dkim> <dkim>fail</dkim>
<spf>fail</spf> <spf>fail <comment>source.ip=10.0.0.1</comment></spf>
<reason> <reason>
<type>local_policy</type> <type>local_policy</type>
<comment>arc=pass ams=d2.example d=d2.example,d1.example</comment> <comment>arc=pass ams[2].d=d2.example ams[2].s=s1 as[2].d=d2.example
</reason> as[2].s=s2 as[1].d=d1.example as[1].s=s3</comment>
</policy_evaluated> </reason>
</policy_evaluated>
In the suggested sample, d2.example is the sealing domain for ARC[2] In the suggested sample, d2.example is the sealing domain for ARC[2]
and d1.example is the sealing domain for ARC[1]. and d1.example is the sealing domain for ARC[1].
Mediators SHOULD generate DMARC reports on messages which transit Mediators SHOULD generate DMARC reports on messages which transit
their system just like any other message which they receive. This their system just like any other message which they receive. This
will result in multiple reports for each mediated message as they will result in multiple reports for each mediated message as they
transit the series of handlers. DMARC report consumers should be transit the series of handlers. DMARC report consumers should be
aware of this behaviour and make the necessary accommodations. aware of this behaviour and make the necessary accommodations.
skipping to change at page 14, line 22 skipping to change at page 15, line 24
10.2. Co-Existence Period 10.2. Co-Existence Period
Intermediaries MUST be able to validate ARC chains build with either Intermediaries MUST be able to validate ARC chains build with either
algorithm and MUST create ARC sets with both algorithms. Chains algorithm and MUST create ARC sets with both algorithms. Chains
ending with either algorithm may be used for the result. ending with either algorithm may be used for the result.
10.3. Deprecation Period 10.3. Deprecation Period
ARC sets built with algorithms that are being deprecated MAY be ARC sets built with algorithms that are being deprecated MAY be
considered valid within an ARC chain, however, intermediaries MUST considered valid within an ARC chain, however, intermediaries MUST
not create additional sets with the deprecated algorithm. NOT create additional sets with the deprecated algorithm.
The deprecation period should be at least two (2) years. The deprecation period should be at least two (2) years.
10.4. Obsolescence Period
ARC sets built with algorithms that are obsolete MUST NOT be
considered valid within an ARC chain. Intermediaries MUST NOT create
any sets with any obsoleted algorithm.
11. Privacy Considerations 11. Privacy Considerations
The ARC chain provides a verifiable record of the handlers for a The ARC chain provides a verifiable record of the handlers for a
message. Anonymous remailers will probably not find this to match message. Anonymous remailers will probably not find this to match
their operating goals. their operating goals.
12. IANA Considerations 12. IANA Considerations
This specification adds three new header fields as defined below. This specification adds three new header fields as defined below.
skipping to change at page 16, line 25 skipping to change at page 17, line 32
exist. exist.
This information is known to be correct as of the seventh This information is known to be correct as of the seventh
interoperability test event which was held on 2017-07-15 & 16 at interoperability test event which was held on 2017-07-15 & 16 at
IETF99. IETF99.
13.1. GMail test reflector and incoming validation 13.1. GMail test reflector and incoming validation
Organization: Google Organization: Google
Description: Internal prototype implementation with both debug Description: Internal production implementation with both debug
analysis and validating + sealing pass-through function analysis and validating + sealing pass-through function
Status of Operation: Production - Incoming Validation Status of Operation: Production - Incoming Validation
Coverage: Full spec implemented as of [ARC-DRAFT-03] Coverage: Full spec implemented as of [ARC-DRAFT-06]
Licensing: Proprietary - Internal only Licensing: Proprietary - Internal only
Implementation Notes: Full functionality was demonstrated during the Implementation Notes:
interop testing on 2016-06-17
In place for reporting usage only as of 2016-11-21 on all GMail
flows.
Rechecked general incoming validation as of 2017-02-24 interop event. o Full functionality was demonstrated during the interop testing on
2017-07-15.
Contact Info: arc-discuss@dmarc.org [1] Contact Info: arc-discuss@dmarc.org [1]
13.2. AOL test reflector and internal tagging 13.2. AOL test reflector and internal tagging
Organization: AOL Organization: AOL
Description: Internal prototype implementation with both debug Description: Internal prototype implementation with both debug
analysis and validating + sealing pass-through function analysis and validating + sealing pass-through function
Status of Operation: Beta Status of Operation: Beta
Coverage: ARC chain validity status checking is not operational, but
otherwise this system conforms to [ARC-DRAFT-03]
Licensing: Proprietary - Internal only Coverage: ARC chain validity status checking is operational, but only
applied to email addresses enrolled in the test program. This system
conforms to [ARC-DRAFT-06]
Implementation Notes: Full functionality with the exception of chain Licensing: Proprietary - Internal only
validity checking was demonstrated during the interop testing on
2016-06-17
Available for production mail via selected account whitelisting for Implementation Notes:
test validation only.
Intermittent stability problems discovered at the interop event on o 2017-07-15: Full functionality verified during the interop
2017-02-24. Remediation underway as of the publication of this testing.
draft.
Contact Info: arc-discuss@dmarc.org [2] Contact Info: arc-discuss@dmarc.org [2]
13.3. dkimpy 13.3. dkimpy
Organization: dkimpy developers Organization: dkimpy developers/Scott Kitterman
Description: Python DKIM package Description: Python DKIM package
Status of Operation: Production Status of Operation: Production
Coverage: The internal test suite is incomplete, but the command line Coverage:
developmental version of validator was demonstrated to interoperate
with the Google and AOL implementations during the interop on
2016-06-17 and the released version passes the tests in [ARC-TEST]
https://github.com/ValiMail/arc_test_suite with both python and
python3.
Licensing: Open/Other (same as dkimpy package) o 2017-07-15: The internal test suite is incomplete, but the command
line developmental version of validator was demonstrated to
interoperate with the Google and AOL implementations during the
interop on 2017-07-15 and the released version passes the tests in
[ARC-TEST] (https://github.com/ValiMail/arc_test_suite) with both
python and python3.
Licensing: Open/Other (same as dkimpy package = BCD version 2)
Contact Info: https://launchpad.net/dkimpy Contact Info: https://launchpad.net/dkimpy
13.4. OpenARC 13.4. OpenARC
Organization: TDP/Murray Kucherawy Organization: TDP/Murray Kucherawy
Description: Implemention of milter functionality related to the Description: Implemention of milter functionality related to the
OpenDKIM and OpenDMARC packages OpenDKIM and OpenDMARC packages
Status of Operation: Beta Status of Operation: Beta
Coverage: Built to support [ARC-DRAFT-03] Coverage: Built to support [ARC-DRAFT-06]
Licensing: Open/Other (same as OpenDKIM and OpenDMARC packages) Licensing: Open/Other (same as OpenDKIM and OpenDMARC packages)
Implementation Notes: The build is FreeBSD oriented and takes some Implementation Notes:
tweaks to build on RedHat-based Linux platforms.
Initial testing during the o The build is FreeBSD oriented but some packages have been built
interop event on 2016-06-17 showed that it can be operational, but the for easier deployment on RedHat-based Linux platforms.
documentation regarding configuration settings is unclear and the
generated signature values do not validate when compared to the Google,
AOL or dkimpy implementations.
Testing during the 2017-02-24 interop event showed that some of the o 2017-07-15: Testing showed problems with the hash calculation for
problems have been fixed, but there are still interoperability problems the AMS header b= field. Several other bugs were discovered and
when trying to use OpenARC in a "sandwich" configuration around a MLM. were either fixed during the following week of IETF meetings or
are under active repair.
o Some issues still exist when deploying in a chained milter
arrangement (such as OpenSPF -> OpenDKIM -> OpenDMARC -> OpenARC)
with coordination between the stages. When deployed in a
"sandwich" configuration around an MLM, there is no effective
mechanism to convey trust from the ingress (validator) to egress
(signer) instances.
Contact Info: arc-discuss@dmarc.org [3] Contact Info: arc-discuss@dmarc.org [3]
13.5. Mailman addition 13.5. Mailman 3.1+ patch
Organization: Mailman development team Organization: Mailman development team
Description: Integrated ARC capabilities within the Mailman package Description: Integrated ARC capabilities within the Mailman 3.1+
package
Status of Operation: Patch submitted Status of Operation: Patch submitted
Coverage: Unknown Coverage: Unknown
Licensing: Same as mailman package - GPL Licensing: Same as mailman package - GPL
Implementation Notes: Incomplete at this time Implementation Notes:
o Appears to work properly in at least one beta deployment, but
waiting on acceptance of the pull request into the mainline of
mailman development
Contact Info: https://www.gnu.org/software/mailman/contact.html Contact Info: https://www.gnu.org/software/mailman/contact.html
13.6. Copernica/MailerQ web-based validation 13.6. Copernica/MailerQ web-based validation
Organization: Copernica Organization: Copernica
Description: Web-based validation of ARC-signed messages Description: Web-based validation of ARC-signed messages
Status of Operation: Beta Status of Operation: Beta
Coverage: Built to support [ARC-DRAFT-03] Coverage: Built to support [ARC-DRAFT-05]
Licensing: On-line usage only Licensing: On-line usage only
Implementation Notes: Released 2016-10-24 Implementation Notes:
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 o Released 2016-10-24
willing to paste a private key into an unsecured web form.
Initial testing shows that results match the other implementations o Requires full message content to be pasted into a web form found
listed in this section. at http://arc.mailerq.com/ (warning - https is not supported).
Contact Info: [https://www.copernica.com/] o An additional instance of an ARC signature can be added if one is
willing to paste a private key into an unsecured web form.
o 2017-07-15: Testing shows that results match the other
implementations listed in this section.
Contact Info: https://www.copernica.com/
13.7. Rspamd 13.7. Rspamd
Organization: Rspamd community Organization: Rspamd community
Description: ARC signing and verification module Description: ARC signing and verification module
Status of Operation: Production, though deployment usage is unknown Status of Operation: Production, though deployment usage is unknown
Coverage: Built to support [ARC-DRAFT-03] Coverage: Built to support [ARC-DRAFT-06]
Licensing: Open source Licensing: Open source
Implementation Notes: Released with version 1.6.0 on 2017-06-12 Implementation Notes:
Contact Info: [https://rspamd.com/doc/modules/arc.html] and o 2017-06-12: Released with version 1.6.0
[https://github.com/vstakhov/rspamd]
o 2017-07-15: Testing during the interop showed that the validation
functionality interoperated with the Google, AOL, dkimpy and
MailerQ implementations
Contact Info: https://rspamd.com/doc/modules/arc.html and
https://github.com/vstakhov/rspamd
13.8. PERL Mail::Milter::Authentication module 13.8. PERL Mail::Milter::Authentication module
Organization: FastMail Organization: FastMail
Description: Email domain authentication milter, previously included Description: Email domain authentication milter, previously included
SPF / DKIM / DMARC, now has ARC added SPF / DKIM / DMARC, now has ARC added
Status of Operation: Intial validation completed during IETF99 Status of Operation: Intial validation completed during IETF99
hackathon with some follow-on work during the week hackathon with some follow-on work during the week
Coverage: Built to support [I-D.ARC] Coverage: Built to support [I-D.ARC]
Licensing: Open Source Licensing: Open Source
Implementation Notes: Implementation Notes:
o 2017-07-15: Validation functionality which interoperates with
Gmail, AOL, dkimpy was demonstrated; later in the week of IETF99,
the signing functionality was reported to be working
o 2017-07-20: ARC functionality has not yet been pushed back to the
github repo but should be showing up soon
Contact Info: https://github.com/fastmail/authentication_milter Contact Info: https://github.com/fastmail/authentication_milter
14. Security Considerations 14. 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.
Operators who receive a message bearing N ARC sets has to complete Operators who receive a message bearing N ARC sets have to complete
N+1 DNS queries to evaluate the chain (barring DNS redirection up to N+1 DNS queries to evaluate the chain (barring DNS redirection
mechanisms which can increase the lookups for a given target value). mechanisms which can increase the lookups for a given target value).
This has at least two effects: This has at least two effects:
1. An attacker can send a message to an ARC partipant with a 1. An attacker can send a message to an ARC partipant with a
concocted sequence of ARC sets bearing the domains of intended concocted sequence of ARC sets bearing the domains of intended
victims, and all of them will be queried by the participant until victims, and all of them will be queried by the participant until
a failure is discovered. a failure is discovered. The difficulty of forging the signature
values should limit the extent of this load to domains under
control of the attacker.
2. DKIM only does one DNS check per signature, while this one can do 2. DKIM only does one DNS check per signature, while this one can do
many. Absent caching, slow DNS responses can cause SMTP many (per chain). Absent caching, slow DNS responses can cause
timeouts; this could be exploited as a DoS attack. SMTP timeouts; and backlogged delivery queues on mediating
systems. This could be exploited as a DoS attack.
14.1. Message Content Suspicion 14.1. Message Content Suspicion
Recipients are cautioned to treat messages bearing ARC sets with the Recipients are cautioned to treat messages bearing ARC sets with the
same suspicion that they apply to all other email messages. This same suspicion that they apply to all other email messages. This
includes appropriate content scanning and other checks for includes appropriate content scanning and other checks for
potentially malicious content. The handlers which are identified potentially malicious content. The handlers which are identified
within the ARC-Seal chain may be used to provide input to local within the ARC chain may be used to provide input to local policy
policy engines in cases where the sending system's DKIM-Signature engines in cases where DMARC validation fails (due to mediation
does not validate. impacting SPF attribution, DKIM validity or alignment).
15. References 15. References
15.1. Normative References 15.1. Normative References
[RFC1345] Simonsen, K., "Character Mnemonics and Character Sets", [RFC1345] Simonsen, K., "Character Mnemonics and Character Sets",
RFC 1345, DOI 10.17487/RFC1345, June 1992, RFC 1345, DOI 10.17487/RFC1345, June 1992,
<http://www.rfc-editor.org/info/rfc1345>. <http://www.rfc-editor.org/info/rfc1345>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 22, line 31 skipping to change at page 24, line 12
DOI 10.17487/RFC7208, April 2014, DOI 10.17487/RFC7208, April 2014,
<http://www.rfc-editor.org/info/rfc7208>. <http://www.rfc-editor.org/info/rfc7208>.
[RFC7601] Kucherawy, M., "Message Header Field for Indicating [RFC7601] Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", RFC 7601, Message Authentication Status", RFC 7601,
DOI 10.17487/RFC7601, August 2015, DOI 10.17487/RFC7601, August 2015,
<http://www.rfc-editor.org/info/rfc7601>. <http://www.rfc-editor.org/info/rfc7601>.
15.2. Informative References 15.2. Informative References
[ARC-DRAFT-03] [ARC-DRAFT-05]
Andersen, K., Rae-Grant, J., Long, B., Adams, T., and S. Andersen, K., Long, B., and S. Jones, "Authenticated
Jones, "Authenticated Received Chain (ARC) Protocol Received Chain (ARC) Protocol (I-D-06)", n.d.,
(I-D-03)", April 2017, <https://tools.ietf.org/html/draft- <https://tools.ietf.org/html/draft-ietf-dmarc-arc-
ietf-dmarc-arc-protocol-03>. protocol-06>.
[ARC-DRAFT-06]
Andersen, K., Long, B., and S. Jones, "Authenticated
Received Chain (ARC) Protocol (I-D-05)", n.d.,
<https://tools.ietf.org/html/draft-ietf-dmarc-arc-
protocol-05>.
[ARC-TEST] [ARC-TEST]
Blank, S., "ARC Test Suite", January 2017, Blank, S., "ARC Test Suite", January 2017,
<https://github.com/ValiMail/arc_test_suite>. <https://github.com/ValiMail/arc_test_suite>.
[ARC-USAGE] [ARC-USAGE]
Jones, S., Adams, T., Rae-Grant, J., and K. Andersen, Jones, S., Adams, T., Rae-Grant, J., and K. Andersen,
"Recommended Usage of the ARC Headers", December 2017, "Recommended Usage of the ARC Headers", December 2017,
<https://tools.ietf.org/html/draft-ietf-dmarc-arc-usage- <https://tools.ietf.org/html/draft-ietf-dmarc-arc-usage-
01>. 01>.
skipping to change at page 23, line 39 skipping to change at page 25, line 29
[4] mailto:dmarc@ietf.org [4] mailto:dmarc@ietf.org
[5] mailto:arc-discuss@dmarc.org [5] mailto:arc-discuss@dmarc.org
Appendix A. Appendix A - Example Usage (Obsolete but retained for Appendix A. Appendix A - Example Usage (Obsolete but retained for
illustrative purposes) illustrative purposes)
[[ Note: The following examples were mocked up early in the [[ Note: The following examples were mocked up early in the
definition process for the spec. They no longer reflect the current definition process for the spec. They no longer reflect the current
definition and need various updates which will be included in draft definition and need various updates which will be included in the
-08. ]] next draft. ]]
A.1. Example 1: Simple mailing list A.1. Example 1: Simple mailing list
A.1.1. Here's the message as it exits the Origin: A.1.1. Here's the message as it exits the Origin:
Return-Path: <jqd@d1.example> Return-Path: <jqd@d1.example>
Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
(authenticated bits=0) (authenticated bits=0)
by segv.d1.example with ESMTP id t0FN4a8O084569; by segv.d1.example with ESMTP id t0FN4a8O084569;
Thu, 14 Jan 2015 15:00:01 -0800 (PST) Thu, 14 Jan 2015 15:00:01 -0800 (PST)
 End of changes. 99 change blocks. 
219 lines changed or deleted 299 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/