draft-ietf-dmarc-arc-usage-02.txt   draft-ietf-dmarc-arc-usage-03.txt 
DMARC Working Group S. Jones DMARC Working Group S. Jones
Internet-Draft DMARC.org Internet-Draft DMARC.org
Intended status: Informational J. Rae-Grant Intended status: Informational K. Andersen
Expires: December 22, 2017 Google Expires: June 22, 2018 LinkedIn
T. Adams J. Rae-Grant
Google
T. Adams, Ed.
Paypal Paypal
K. Andersen, Ed. December 19, 2017
LinkedIn
June 20, 2017
Recommended Usage of the Authenticated Received Chain (ARC) Recommended Usage of the Authenticated Received Chain (ARC)
draft-ietf-dmarc-arc-usage-02 draft-ietf-dmarc-arc-usage-03
Abstract Abstract
The Authentication Received Chain (ARC) provides a means to preserve The Authentication Received Chain (ARC) provides a means to preserve
email authentication results and verify the identity of email message email authentication results and verify the identity of email message
handlers, each of which participates by inserting certain header handlers, each of which participates by inserting certain header
fields before passing the message on. But the specification does not fields before passing the message on. But the specification does not
indicate how intermediaries and receivers should interpret or utilize indicate how intermediaries and receivers should interpret or utilize
ARC. This document will provide guidance in these areas. ARC. This document will provide guidance in these areas.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 22, 2017. This Internet-Draft will expire on June 22, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. How does ARC work? . . . . . . . . . . . . . . . . . . . . . 3 2. How does ARC work? . . . . . . . . . . . . . . . . . . . . . 3
3. Guidance for Receivers/Validators . . . . . . . . . . . . . . 4 3. Evaluating the Efficacy of the ARC Protocol . . . . . . . . . 4
3.1. What is the significance of an intact ARC chain? . . . . 4 3.1. Success Consideration . . . . . . . . . . . . . . . . . . 4
3.2. What exactly is an "intact" ARC chain? . . . . . . . . . 4 3.2. Failure Considerations . . . . . . . . . . . . . . . . . 5
3.3. What is the significance of an invalid ("broken") ARC 3.3. Open Questions . . . . . . . . . . . . . . . . . . . . . 5
chain? . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3.1. Value of the ARC-Seal (AS) Header . . . . . . . . . . 5
3.4. What does the absence of an ARC chain in a message mean? 5 3.3.2. DNS Overhead . . . . . . . . . . . . . . . . . . . . 5
3.5. What reasonable conclusions can you draw based upon 3.3.3. Distinguishing Valuable from Worthless Trace
seeing lots of mail with ARC chains? . . . . . . . . . . 5 Information . . . . . . . . . . . . . . . . . . . . . 5
3.6. What if none of the intermediaries have been seen 4. Guidance for Receivers/Validators . . . . . . . . . . . . . . 6
previously? . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. What is the significance of an intact ARC chain? . . . . 6
3.7. What about ARC chains where some intermediaries are known 4.2. What exactly is an "intact" ARC chain? . . . . . . . . . 6
and others are not? . . . . . . . . . . . . . . . . . . . 6 4.3. What is the significance of an invalid ("broken") ARC
3.8. What should message handlers do when they detect chain? . . . . . . . . . . . . . . . . . . . . . . . . . 7
malicious content in messages where ARC is present? . . . 6 4.4. What does the absence of an ARC chain in a message mean? 7
3.9. What feedback does a sender or domain owner get about ARC 4.5. What reasonable conclusions can you draw based upon
when it is applied to their messages? . . . . . . . . . . 7 seeing lots of mail with ARC chains? . . . . . . . . . . 8
3.10. What prevents a malicious actor from removing the ARC 4.6. What if none of the intermediaries have been seen
previously? . . . . . . . . . . . . . . . . . . . . . . . 8
4.7. What about ARC chains where some intermediaries are known
and others are not? . . . . . . . . . . . . . . . . . . . 8
4.8. What should message handlers do when they detect
malicious content in messages where ARC is present? . . . 9
4.9. What feedback does a sender or domain owner get about ARC
when it is applied to their messages? . . . . . . . . . . 9
4.10. What prevents a malicious actor from removing the ARC
header fields, altering the content, and creating a new header fields, altering the content, and creating a new
ARC chain? . . . . . . . . . . . . . . . . . . . . . . . 7 ARC chain? . . . . . . . . . . . . . . . . . . . . . . . 9
4. Guidance for Intermediaries . . . . . . . . . . . . . . . . . 8 5. Guidance for Intermediaries . . . . . . . . . . . . . . . . . 10
4.1. What is an Intermediary under ARC? . . . . . . . . . . . 8 5.1. What is an Intermediary under ARC? . . . . . . . . . . . 10
4.2. What are the minimum requirements for an ARC 5.2. What are the minimum requirements for an ARC
Intermediary? . . . . . . . . . . . . . . . . . . . . . . 8 Intermediary? . . . . . . . . . . . . . . . . . . . . . . 10
4.2.1. More specifically a participating ARC intermediary 5.2.1. More specifically a participating ARC intermediary
must do the following: . . . . . . . . . . . . . . . 8 must do the following: . . . . . . . . . . . . . . . 10
4.3. Should every MTA be an ARC participant? . . . . . . . . . 8 5.3. Should every MTA be an ARC participant? . . . . . . . . . 11
4.4. What should an intermediary do in the case of an invalid 5.4. What should an intermediary do in the case of an invalid
or "broken" ARC chain? . . . . . . . . . . . . . . . . . 9 or "broken" ARC chain? . . . . . . . . . . . . . . . . . 11
4.5. What should I do in the case where there is no ARC chain 5.5. What should I do in the case where there is no ARC chain
present in a message? . . . . . . . . . . . . . . . . . . 9 present in a message? . . . . . . . . . . . . . . . . . . 11
4.6. How could ARC affect my reputation as an intermediary? . 9 5.6. How could ARC affect my reputation as an intermediary? . 11
4.7. What can I do to influence my reputation as an 5.7. What can I do to influence my reputation as an
intermediary? . . . . . . . . . . . . . . . . . . . . . . 9 intermediary? . . . . . . . . . . . . . . . . . . . . . . 12
5. Guidance for Originators . . . . . . . . . . . . . . . . . . 10 6. Guidance for Originators . . . . . . . . . . . . . . . . . . 12
5.1. Where can I find out more information? . . . . . . . . . 10 6.1. Where can I find out more information? . . . . . . . . . 12
5.2. How/where can I test interoperabililty for my 6.2. How/where can I test interoperabililty for my
implementation? . . . . . . . . . . . . . . . . . . . . . 10 implementation? . . . . . . . . . . . . . . . . . . . . . 12
6.3. How can ARC impact my email? . . . . . . . . . . . . . . 12
5.3. How can ARC impact my email? . . . . . . . . . . . . . . 10 6.4. How can ARC impact my reputation as a message sender? . . 13
5.4. How can ARC impact my reputation as a message sender? . . 10 6.5. Can I tell intermediaries not to use ARC? . . . . . . . . 13
5.5. Can I tell intermediaries not to use ARC? . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . 13
6.1. Normative References . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . 14
6.2. Informative References . . . . . . . . . . . . . . . . . 11 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Appendix A. GLOSSARY . . . . . . . . . . . . . . . . . . . . . . 14
Appendix A. GLOSSARY . . . . . . . . . . . . . . . . . . . . . . 12 Appendix B. References . . . . . . . . . . . . . . . . . . . . . 17
Appendix B. References . . . . . . . . . . . . . . . . . . . . . 15 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 17
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 15 Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 17
Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
[ARC] is intended to be used primarily by intermediaries, or message [ARC] is intended to be used primarily by intermediaries, or message
handlers - those parties who may forward or resend messages, with or handlers - those parties who may forward or resend messages, with or
without alterations, such that they will no longer pass the SPF, without alterations, such that they will no longer pass the SPF,
DKIM, and/or [RFC7489] authentication mechanisms. In such cases ARC DKIM, and/or [RFC7489] authentication mechanisms. In such cases ARC
may provide the final message recipient with useful information about may provide the final message recipient with useful information about
the original sender. the original sender.
skipping to change at page 4, line 23 skipping to change at page 4, line 31
When the message reaches the final receiving system, the SPF and DKIM When the message reaches the final receiving system, the SPF and DKIM
results will not satisfy the DMARC policy for the message author's results will not satisfy the DMARC policy for the message author's
domain. However if the receiving system implements ARC then it can domain. However if the receiving system implements ARC then it can
check for and validate an ARC chain and verify that the contents of check for and validate an ARC chain and verify that the contents of
the ARC-Authentication-Results header field were conveyed intact from the ARC-Authentication-Results header field were conveyed intact from
the mailing list operator. At that point the receiving system might the mailing list operator. At that point the receiving system might
choose to use those authentication results in the decision of whether choose to use those authentication results in the decision of whether
or not to deliver the message, even though it failed to pass the or not to deliver the message, even though it failed to pass the
usual authentication checks. usual authentication checks.
3. Guidance for Receivers/Validators 3. Evaluating the Efficacy of the ARC Protocol
3.1. What is the significance of an intact ARC chain? The ARC protocol is designed to mitigate some of the most common
failure conditions for email which transits intermediary handlers en
route to the final recipient. Some of these problems have happened
due to the adoption of the DMARC protocol [RFC7489] and are listed in
[RFC6377] and [RFC7960].
As the ARC protocol becomes standardized and implemented amongst
intermediary handlers, the following aspects should be evaluated in
order to determine the success of the protocol in accomplishing the
intended benefits.
3.1. Success Consideration
Currently, many receivers have heuristically determined overrides in
order to rescue mail from intermediary-caused failures. Many of
those overrides rely on inferrence rather than direct evidence.
ARC will be a success if, for ARC sealed messages, receivers are able
to implment ARC-based algorithmic decisions based on the direct
evidence found within the ARC chain. This is especially relevant for
DMARC processing when the DKIM d= value is aligned with the
rfc5322.From author domain.
3.2. Failure Considerations
The intent of ARC is to be at most value-add and at worst benign. If
ARC opens up significant new vectors for abuse (see [ARC] Security
Considerations) then this protocol will be a failure. Note that
weaknesses inherent in the mail protocols ARC is built upon (such as
DKIM replay attacks and other known issues) are not new vectors which
can be attributed to this specification.
3.3. Open Questions
The following open questions are academic and have no clear answer at
the time of the development of the protocol. However, wide-spread
deployment should be able to gather the necessary data to
conclusively answer some or all of them.
3.3.1. Value of the ARC-Seal (AS) Header
Data should be collected to show if the ARC-Seal (AS) provides value
beyond the ARC Message Signature (AMS) for either making delivery
decisions or catching malicious actors trying to craft or replay
malicious chains.
3.3.2. DNS Overhead
Longer ARC chains will require more queries to retrieve the keys for
validating the chain. While this is not believed to be a security
issue (see [ARC], Security Conditions -> DNS Attacks), it is unclear
how much overhead will truly be added. This is similar to some of
the initial processing and query load concerns which were debated at
the time of the DKIM specification development.
Data should be collected to better understand usable length and
distribution of lengths found in valid ARC chains along with the the
DNS impact of processing ARC chains.
3.3.3. Distinguishing Valuable from Worthless Trace Information
There are several edge cases where the information in the AAR can
make the difference between message delivery or rejection. For
example, if there is a well known mailing list that ARC seals but
doesn't do its own initial DMARC enforcement, a Final Receiver with
this knowledge could make a delivery decision based upon the
authentication information it sees in the corresponding AAR header.
Certain trace information in the AAR is useful/necessary in the
construction of DMARC reports. It would be beneficial to identify
the value-add of having intermediary-handled mail flow information
added into the DMARC reports going back to senders.
Certain receivers believe the entire set of trace information would
be valuable to feed into machine learning systems to identify fraud
and/or provide other signals related to message delivery.
It is unclear what trace information will be valuable for all
receivers, regardless of size.
Data should be collected on what trace information receivers are
using that provides useful signals that affect deliverability, and
what portions of the trace data are left untouched or provide no
useful information.
Since many such systems are intentionly proprietary or confidential
to prevent gaming by abusers, it may not be viable to reliably answer
this particular question. The evolving nature of attacks can also
shift the landscape of "useful" information over time.
4. Guidance for Receivers/Validators
4.1. What is the significance of an intact ARC chain?
An intact ARC chain conveys authentication results like SPF and DKIM An intact ARC chain conveys authentication results like SPF and DKIM
as observed by the first ARC participant. In cases where the message as observed by the first ARC participant. In cases where the message
no longer produces passing results for DKIM, SPF, or DMARC but an no longer produces passing results for DKIM, SPF, or DMARC but an
intact ARC chain is present, the message receiver may choose to use intact ARC chain is present, the message receiver may choose to use
the contents of the ARC-Authentication-Results header field in the contents of the ARC-Authentication-Results header field in
determining how to handle the message. determining how to handle the message.
3.2. What exactly is an "intact" ARC chain? 4.2. What exactly is an "intact" ARC chain?
Note that not all ADMDs will implement ARC, and receivers will see Note that not all ADMDs will implement ARC, and receivers will see
messages where one or more non-participating ADMDs handled a message messages where one or more non-participating ADMDs handled a message
before, after, or in between participating ADMDs. before, after, or in between participating ADMDs.
An intact ARC chain is one where the ARC header fields that are An intact ARC chain is one where the ARC header fields that are
present can be validated, and in particular the ARC-Message-Signature present can be validated, and in particular the ARC-Message-Signature
header field from the last ARC participant can still be validated. header field from the last ARC participant can still be validated.
This shows that, whether another ADMD handled the message after the This shows that, whether another ADMD handled the message after the
last ARC participant or not, the portions of the message covered by last ARC participant or not, the portions of the message covered by
skipping to change at page 5, line 22 skipping to change at page 7, line 24
with an intact ARC chain where a DMARC evaluation does not pass, but with an intact ARC chain where a DMARC evaluation does not pass, but
the ARC-Authentication-Results header field indicates a DKIM pass was the ARC-Authentication-Results header field indicates a DKIM pass was
reported by the first ARC intermediary that matches the domain in the reported by the first ARC intermediary that matches the domain in the
RFC5322.From header field, it will override a DMARC "p=reject" RFC5322.From header field, it will override a DMARC "p=reject"
policy. Another message receiver may decide to do so for intact ARC policy. Another message receiver may decide to do so for intact ARC
chains where the ARC-Authentication-Results header field indicates an chains where the ARC-Authentication-Results header field indicates an
SPF pass. A third message receiver may use very different criteria, SPF pass. A third message receiver may use very different criteria,
according to their requirements, while a fourth may choose not to according to their requirements, while a fourth may choose not to
take ARC information into account at all. take ARC information into account at all.
3.3. What is the significance of an invalid ("broken") ARC chain? 4.3. What is the significance of an invalid ("broken") ARC chain?
An ARC chain is not considered to be valid if the signatures in the An ARC chain is not considered to be valid if the signatures in the
ARC-Seal header fields cannot be verified. For example the remote ARC-Seal header fields cannot be verified. For example the remote
server delivering the message to the local ADMD is not reflected in server delivering the message to the local ADMD is not reflected in
any ARC header fields, perhaps because they have not implemented ARC, any ARC header fields, perhaps because they have not implemented ARC,
but they modified the message such that ARC and DKIM signatures but they modified the message such that ARC and DKIM signatures
already in the message were invalidated. already in the message were invalidated.
In such cases the ARC-Authentication-Results header field should not In such cases the ARC-Authentication-Results header field should not
have any influence on the disposition of the message. For example, a have any influence on the disposition of the message. For example, a
message that fails under DMARC and has an invalid ARC chain would be message that fails under DMARC and has an invalid ARC chain would be
subject to that DMARC policy, which may cause it to be quarantined or subject to that DMARC policy, which may cause it to be quarantined or
rejected. rejected.
3.4. What does the absence of an ARC chain in a message mean? 4.4. What does the absence of an ARC chain in a message mean?
The absence of an ARC chain means nothing. ARC is intended to allow The absence of an ARC chain means nothing. ARC is intended to allow
a participating message handler to preserve certain authentication a participating message handler to preserve certain authentication
results when a message is being forwarded and/or modified such that results when a message is being forwarded and/or modified such that
the final recipient can evaluate this information. If they are the final recipient can evaluate this information. If they are
absent, there is nothing extra that ARC requires the final recipient absent, there is nothing extra that ARC requires the final recipient
to do. to do.
3.5. What reasonable conclusions can you draw based upon seeing lots of 4.5. What reasonable conclusions can you draw based upon seeing lots of
mail with ARC chains? mail with ARC chains?
With sufficient history, ARC can be used to augment DMARC With sufficient history, ARC can be used to augment DMARC
authentication policy (i.e. a message could fail DMARC, but validated authentication policy (i.e. a message could fail DMARC, but validated
ARC information and therefore could be considered as validly ARC information and therefore could be considered as validly
authenticated as reported by the first ARC participant). authenticated as reported by the first ARC participant).
If the validator does content analysis and reputation tracking, the If the validator does content analysis and reputation tracking, the
ARC participants in a message can be credited or discredited for good ARC participants in a message can be credited or discredited for good
or bad content. By analyzing different ARC chains involved in "bad" or bad content. By analyzing different ARC chains involved in "bad"
messages, a validator might identify malicious participating messages, a validator might identify malicious participating
intermediaries. intermediaries.
With a valid chain and good reputations for all ARC participants, With a valid chain and good reputations for all ARC participants,
receivers may choose to apply a "local policy override" to the DMARC receivers may choose to apply a "local policy override" to the DMARC
policy assertion for the domain authentication evaluation, depending policy assertion for the domain authentication evaluation, depending
on the ARC-Authentication-Results header field value. Normal content on the ARC-Authentication-Results header field value. Normal content
analysis should never be skipped. analysis should never be skipped.
3.6. What if none of the intermediaries have been seen previously? 4.6. What if none of the intermediaries have been seen previously?
This has no impact on the operation of ARC, as ARC is not a This has no impact on the operation of ARC, as ARC is not a
reputation system. ARC conveys the results of other authentication reputation system. ARC conveys the results of other authentication
mechanisms such that the participating message handlers can be mechanisms such that the participating message handlers can be
positively identified. Final message recipients may or may not positively identified. Final message recipients may or may not
choose to examine these results when messages fail other choose to examine these results when messages fail other
authentication checks. They are more likely to override, say, a authentication checks. They are more likely to override, say, a
failing DMARC result in the presence of an intact ARC chain where the failing DMARC result in the presence of an intact ARC chain where the
participating ARC message handlers have been observed to not convey participating ARC message handlers have been observed to not convey
"bad" content in the past, and the initial ARC participant indicates "bad" content in the past, and the initial ARC participant indicates
the message they received had passed authentication checks. the message they received had passed authentication checks.
3.7. What about ARC chains where some intermediaries are known and 4.7. What about ARC chains where some intermediaries are known and
others are not? others are not?
Validators may choose to build reputation models for ARC message Validators may choose to build reputation models for ARC message
handlers they have observed. Generally speaking it is more feasible handlers they have observed. Generally speaking it is more feasible
to accrue positive reputation to intermediaries when they to accrue positive reputation to intermediaries when they
consistently send messages that are evaluated positively in terms of consistently send messages that are evaluated positively in terms of
content and ARC chains. When messages are received with ARC chains content and ARC chains. When messages are received with ARC chains
that are not intact, it is very difficult identify which that are not intact, it is very difficult identify which
intermediaries may have manipulated the message or injected bad intermediaries may have manipulated the message or injected bad
content. content.
3.8. What should message handlers do when they detect malicious content 4.8. What should message handlers do when they detect malicious content
in messages where ARC is present? in messages where ARC is present?
Message handlers should do what they normally do when they detect Message handlers should do what they normally do when they detect
malicious content in a message - hopefully that means quarantining or malicious content in a message - hopefully that means quarantining or
discarding the message. ARC information should never make malicious discarding the message. ARC information should never make malicious
content acceptable. content acceptable.
In such cases it is difficult to determine where the malicious In such cases it is difficult to determine where the malicious
content may have been injected. What ARC can do in such cases is content may have been injected. What ARC can do in such cases is
verify that a given intermediary or message handler did in fact verify that a given intermediary or message handler did in fact
handle the message as indicated in the header fields. In such cases handle the message as indicated in the header fields. In such cases
a message recipient who maintains a reputation system about email a message recipient who maintains a reputation system about email
senders may wish to incorporate this information as an additional senders may wish to incorporate this information as an additional
factor in the score for the intermediaries and sender in question. factor in the score for the intermediaries and sender in question.
However reputation systems are very complex, and usually unique to However reputation systems are very complex, and usually unique to
those organizations operating them, and therefore beyond the scope of those organizations operating them, and therefore beyond the scope of
this document. this document.
3.9. What feedback does a sender or domain owner get about ARC when it 4.9. What feedback does a sender or domain owner get about ARC when it
is applied to their messages? is applied to their messages?
ARC itself does not include any mechanism for feedback or reporting. ARC itself does not include any mechanism for feedback or reporting.
It does however recommend that message receiving systems that use ARC It does however recommend that message receiving systems that use ARC
to augment their delivery decisions, who use DMARC and decide to to augment their delivery decisions, who use DMARC and decide to
deliver a message because of ARC information, should include a deliver a message because of ARC information, should include a
notation to that effect in their normal DMARC reports. These notation to that effect in their normal DMARC reports. These
notations would be easily identifiable by report processors, so that notations would be easily identifiable by report processors, so that
senders and domain owners can see where ARC is being used to augment senders and domain owners can see where ARC is being used to augment
the deliverability of their messages. the deliverability of their messages.
3.10. What prevents a malicious actor from removing the ARC header 4.10. What prevents a malicious actor from removing the ARC header
fields, altering the content, and creating a new ARC chain? fields, altering the content, and creating a new ARC chain?
ARC does not prevent a malicious actor from doing this. Nor does it ARC does not prevent a malicious actor from doing this. Nor does it
prevent a malicious actor from removing all but the first ADMD's ARC prevent a malicious actor from removing all but the first ADMD's ARC
header fields and altering the message, eliminating intervening header fields and altering the message, eliminating intervening
participants from the ARC chain. Or similar variations. participants from the ARC chain. Or similar variations.
A valid ARC chain does not provide any automatic benefit. With an A valid ARC chain does not provide any automatic benefit. With an
intact ARC chain, the final message recipient may choose to use the intact ARC chain, the final message recipient may choose to use the
contents of the ARC-Authentication-Results header field in contents of the ARC-Authentication-Results header field in
skipping to change at page 8, line 5 skipping to change at page 10, line 15
already able to do without ARC involved, but now a signature linked already able to do without ARC involved, but now a signature linked
to the domain responsible for the manipulation is present. to the domain responsible for the manipulation is present.
Additionally in the second case it is possible some negative Additionally in the second case it is possible some negative
reputational impact might accrue to the first ARC participant left in reputational impact might accrue to the first ARC participant left in
place until more messages reveal the pattern of activity by the bad place until more messages reveal the pattern of activity by the bad
actor. But again, a bad actor can similarly manipulate a sequence of actor. But again, a bad actor can similarly manipulate a sequence of
RFC5322.Received header fields today without ARC, but with ARC that RFC5322.Received header fields today without ARC, but with ARC that
bad actor has verifiably identified themselves. bad actor has verifiably identified themselves.
4. Guidance for Intermediaries 5. Guidance for Intermediaries
4.1. What is an Intermediary under ARC? 5.1. What is an Intermediary under ARC?
In the context of ARC, an Intermediary is typically an Administrative In the context of ARC, an Intermediary is typically an Administrative
Management Domain [RFC5598] that is receiving a message, potentially Management Domain [RFC5598] that is receiving a message, potentially
manipulating or altering it, and then passing it on to another ADMD manipulating or altering it, and then passing it on to another ADMD
for delivery. Common examples of Intermediaries are mailing lists, for delivery. Common examples of Intermediaries are mailing lists,
alumni or professional email address providers that forward messages alumni or professional email address providers that forward messages
such as universities or professional organizations, et cetera. such as universities or professional organizations, et cetera.
4.2. What are the minimum requirements for an ARC Intermediary? 5.2. What are the minimum requirements for an ARC Intermediary?
A participating ARC intermediary must validate the ARC chain on a A participating ARC intermediary must validate the ARC chain on a
message it receives, if one is present. It then attaches its own ARC message it receives, if one is present. It then attaches its own ARC
seal and signature, including an indication if the chain failed to seal and signature, including an indication if the chain failed to
validate upon receipt. validate upon receipt.
4.2.1. More specifically a participating ARC intermediary must do the 5.2.1. More specifically a participating ARC intermediary must do the
following: following:
1. Validate that the ARC chain, if one is already present in the 1. Validate that the ARC chain, if one is already present in the
message, is intact and well-formed. message, is intact and well-formed.
2. Validate that the most recent sender matches the last entry in 2. Validate that the most recent sender matches the last entry in
the ARC chain (if present). the ARC chain (if present).
3. Validate that the most recent sender's DKIM signature is 3. Validate that the most recent sender's DKIM signature is
attached, and matches the reference to it in the ARC chain (if attached, and matches the reference to it in the ARC chain (if
present). present).
4. Generate a new ARC Signature and add it to the message according 4. Generate a new ARC Signature and add it to the message according
to the ARC specification. to the ARC specification.
5. Generate a new ARC Seal and add it to the message according to 5. Generate a new ARC Seal and add it to the message according to
the ARC specification. the ARC specification.
4.3. Should every MTA be an ARC participant? 5.3. Should every MTA be an ARC participant?
Generally speaking, ARC is designed to operate at the ADMD level. Generally speaking, ARC is designed to operate at the ADMD level.
When a message is first received by an ADMD, the traditional When a message is first received by an ADMD, the traditional
authentication results should be captured and preserved - this could authentication results should be captured and preserved - this could
be the common case of creating an Authentication-Results header be the common case of creating an Authentication-Results header
field. But when it is determined that the message is being sent on field. But when it is determined that the message is being sent on
outside of that ADMD, that is when the ADMD should add itself to the outside of that ADMD, that is when the ADMD should add itself to the
ARC chain - before sending the message outside of the ADMD. ARC chain - before sending the message outside of the ADMD.
Some organizations may operate multiple ADMDs, with more or less Some organizations may operate multiple ADMDs, with more or less
independence between them. While they should make a determination independence between them. While they should make a determination
based on their specific circumstances, it may be useful and based on their specific circumstances, it may be useful and
appropriate to have one or both ADMDs be ARC participants. appropriate to have one or both ADMDs be ARC participants.
4.4. What should an intermediary do in the case of an invalid or 5.4. What should an intermediary do in the case of an invalid or
"broken" ARC chain? "broken" ARC chain?
In general terms, a participating ARC intermediary will note that an In general terms, a participating ARC intermediary will note that an
ARC chain was present and invalid, or broken, when it attaches its ARC chain was present and invalid, or broken, when it attaches its
own ARC seal and signature. However the fact that the ARC chain was own ARC seal and signature. However the fact that the ARC chain was
invalid should have no impact on whether and how the message is invalid should have no impact on whether and how the message is
delivered. delivered.
4.5. What should I do in the case where there is no ARC chain present 5.5. What should I do in the case where there is no ARC chain present
in a message? in a message?
A participating ARC intermediary receiving a message with no ARC A participating ARC intermediary receiving a message with no ARC
chain, and which will be delivered outside its ADMD, should start an chain, and which will be delivered outside its ADMD, should start an
ARC chain according to the ARC specification. This will include ARC chain according to the ARC specification. This will include
capturing the normal email authentication results for the capturing the normal email authentication results for the
intermediary (SPF, DKIM, DMARC, etc), which will be conveyed as part intermediary (SPF, DKIM, DMARC, etc), which will be conveyed as part
of the ARC chain. of the ARC chain.
4.6. How could ARC affect my reputation as an intermediary? 5.6. How could ARC affect my reputation as an intermediary?
Message receivers often operate reputation systems, which build a Message receivers often operate reputation systems, which build a
behavioral profile of various message handlers and intermediaries. behavioral profile of various message handlers and intermediaries.
The presence or absence of ARC is yet another data point that may be The presence or absence of ARC is yet another data point that may be
used as an input to such reputation systems. Messages deemed to have used as an input to such reputation systems. Messages deemed to have
good content may provide a positive signal for the intermediaries good content may provide a positive signal for the intermediaries
that handled it, while messages with bad content may provide a that handled it, while messages with bad content may provide a
negative signal for the those intermediaries. Intact and valid ARC negative signal for the those intermediaries. Intact and valid ARC
elements may amplify or attenuate such signals, depending on the elements may amplify or attenuate such signals, depending on the
circumstances. circumstances.
Reputation systems are complex and usually specific to a given Reputation systems are complex and usually specific to a given
message receiver, and a meaningful discussion of such a broad topic message receiver, and a meaningful discussion of such a broad topic
is beyond the scope of this document. is beyond the scope of this document.
4.7. What can I do to influence my reputation as an intermediary? 5.7. What can I do to influence my reputation as an intermediary?
Today it is extremely simple for a malicious actor to construct a Today it is extremely simple for a malicious actor to construct a
message that includes your identity as an intermediary, even though message that includes your identity as an intermediary, even though
you never handled the message. It is possible that an intermediary you never handled the message. It is possible that an intermediary
implementing ARC on all traffic it handles might receive some implementing ARC on all traffic it handles might receive some
reputational benefit by making it easier to detect when their reputational benefit by making it easier to detect when their
involvement in conveying bad traffic has been "forged." involvement in conveying bad traffic has been "forged."
As mentioned previously reputation systems are very complex and As mentioned previously reputation systems are very complex and
usually specific to a given message receiver, and a meaningful usually specific to a given message receiver, and a meaningful
discussion of such a broad topic is beyond the scope of this discussion of such a broad topic is beyond the scope of this
document. document.
5. Guidance for Originators 6. Guidance for Originators
5.1. Where can I find out more information? 6.1. Where can I find out more information?
Please join the arc-discuss list at arc-discuss@dmarc.org Please join the arc-discuss list at arc-discuss@dmarc.org
[1][mailto:arc-discuss@dmarc.org]. [1][mailto:arc-discuss@dmarc.org].
To discuss the IETF spec itself, please join the dmarc working group To discuss the IETF spec itself, please join the dmarc working group
at [https://datatracker.ietf.org/wg/dmarc]. at [https://datatracker.ietf.org/wg/dmarc].
5.2. How/where can I test interoperabililty for my implementation? 6.2. How/where can I test interoperabililty for my implementation?
The arc-discuss list is the best place to stay in touch with work in The arc-discuss list is the best place to stay in touch with work in
progress. progress.
5.3. How can ARC impact my email? 6.3. How can ARC impact my email?
Prior to ARC, certain DMARC policies on a domain would cause messages Prior to ARC, certain DMARC policies on a domain would cause messages
using those domains in the RFC5322.From field, and which pass through using those domains in the RFC5322.From field, and which pass through
certain kinds of intermediaries (mailing lists, forwarding services), certain kinds of intermediaries (mailing lists, forwarding services),
to fail authentication checks at the message receiver. As a result to fail authentication checks at the message receiver. As a result
these messages might not be delivered to the intended recipient. these messages might not be delivered to the intended recipient.
ARC seeks to provide these so-called "indirect mailflows" with a ARC seeks to provide these so-called "indirect mailflows" with a
means to preserve email authentication results as recorded by means to preserve email authentication results as recorded by
participating intermediaries. Message receivers may accept validated participating intermediaries. Message receivers may accept validated
ARC information to supplement the information that DMARC provides, ARC information to supplement the information that DMARC provides,
potentially deciding to deliver the message even though a DMARC check potentially deciding to deliver the message even though a DMARC check
did not pass. did not pass.
The net result for domain owners and senders is that ARC may allow The net result for domain owners and senders is that ARC may allow
messages routed through participating ARC intermediaries to be messages routed through participating ARC intermediaries to be
delivered, even though those messages would not have been delivered delivered, even though those messages would not have been delivered
in the absence of ARC. in the absence of ARC.
5.4. How can ARC impact my reputation as a message sender? 6.4. How can ARC impact my reputation as a message sender?
Message receivers often operate reputation systems, which build a Message receivers often operate reputation systems, which build a
behavioral profile of various message senders (and perhaps behavioral profile of various message senders (and perhaps
intermediaries). The presence or absence of ARC is yet another data intermediaries). The presence or absence of ARC is yet another data
point that may be used as an input to such reputation systems. point that may be used as an input to such reputation systems.
Messages deemed to have good content may provide a positive signal Messages deemed to have good content may provide a positive signal
for the sending domain and the intermediaries that handled it, while for the sending domain and the intermediaries that handled it, while
messages with bad content may provide a negative signal for the messages with bad content may provide a negative signal for the
sending domain and the intermediaries that handled it. Intact and sending domain and the intermediaries that handled it. Intact and
valid ARC elements may amplify or attenuate such signals, depending valid ARC elements may amplify or attenuate such signals, depending
on the circumstances. on the circumstances.
Reputation systems are complex and usually specific to a given Reputation systems are complex and usually specific to a given
message receiver, and a meaningful discussion of such a broad topic message receiver, and a meaningful discussion of such a broad topic
is beyond the scope of this document. is beyond the scope of this document.
5.5. Can I tell intermediaries not to use ARC? 6.5. Can I tell intermediaries not to use ARC?
At present there is no way for a message sender to request that At present there is no way for a message sender to request that
intermediaries not employ ARC. intermediaries not employ ARC.
6. References 7. References
6.1. Normative References 7.1. Normative References
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
DOI 10.17487/RFC5321, October 2008, DOI 10.17487/RFC5321, October 2008,
<http://www.rfc-editor.org/info/rfc5321>. <https://www.rfc-editor.org/info/rfc5321>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008, DOI 10.17487/RFC5322, October 2008,
<http://www.rfc-editor.org/info/rfc5322>. <https://www.rfc-editor.org/info/rfc5322>.
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
DOI 10.17487/RFC5598, July 2009, DOI 10.17487/RFC5598, July 2009,
<http://www.rfc-editor.org/info/rfc5598>. <https://www.rfc-editor.org/info/rfc5598>.
[RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and
Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377,
September 2011, <https://www.rfc-editor.org/info/rfc6377>.
[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>. <https://www.rfc-editor.org/info/rfc7601>.
6.2. Informative References 7.2. Informative References
[ARC] Andersen, K., Rae-Grant, J., Long, B., Adams, T., and S. [ARC] Andersen, K., Rae-Grant, J., Long, B., and S. Jones,
Jones, "Authenticated Received Chain (ARC) Protocol", June "Authenticated Received Chain (ARC) Protocol", December
2017, <https://tools.ietf.org/html/draft-ietf-dmarc-arc- 2017, <https://tools.ietf.org/html/
protocol-04>. draft-ietf-dmarc-arc-protocol-10>.
[ENHANCED-STATUS] [ENHANCED-STATUS]
"IANA SMTP Enhanced Status Codes", n.d., "IANA SMTP Enhanced Status Codes", n.d.,
<http://www.iana.org/assignments/smtp-enhanced-status- <http://www.iana.org/assignments/smtp-enhanced-status-
codes/smtp-enhanced-status-codes.xhtml>. codes/smtp-enhanced-status-codes.xhtml>.
[OAR] Chew, M. and M. Kucherawy, "Original-Authentication- [OAR] Chew, M. and M. Kucherawy, "Original-Authentication-
Results Header Field", February 2012, Results Header Field", February 2012,
<https://tools.ietf.org/html/draft-kucherawy-original- <https://tools.ietf.org/html/
authres-00>. draft-kucherawy-original-authres-00>.
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
Message Authentication, Reporting, and Conformance Message Authentication, Reporting, and Conformance
(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
<http://www.rfc-editor.org/info/rfc7489>. <https://www.rfc-editor.org/info/rfc7489>.
[RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky, [RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky,
E., Ed., and K. Andersen, Ed., "Interoperability Issues E., Ed., and K. Andersen, Ed., "Interoperability Issues
between Domain-based Message Authentication, Reporting, between Domain-based Message Authentication, Reporting,
and Conformance (DMARC) and Indirect Email Flows", and Conformance (DMARC) and Indirect Email Flows",
RFC 7960, DOI 10.17487/RFC7960, September 2016, RFC 7960, DOI 10.17487/RFC7960, September 2016,
<http://www.rfc-editor.org/info/rfc7960>. <https://www.rfc-editor.org/info/rfc7960>.
6.3. URIs 7.3. URIs
[1] mailto:arc-discuss@dmarc.org [1] mailto:arc-discuss@dmarc.org
Appendix A. GLOSSARY Appendix A. GLOSSARY
ADMD Administrative Management Domain as used in [RFC5598] and ADMD Administrative Management Domain as used in [RFC5598] and
similar references refers to a single entity operating one or more similar references refers to a single entity operating one or more
computers within one or more domain names under said entity's computers within one or more domain names under said entity's
control. One example might be a small company with a single control. One example might be a small company with a single
server, handling email for that company's domain. Another example server, handling email for that company's domain. Another example
skipping to change at page 15, line 31 skipping to change at page 18, line 4
Please address all comments, discussions, and questions to the dmarc Please address all comments, discussions, and questions to the dmarc
working group at [https://datatracker.ietf.org/wg/dmarc]. working group at [https://datatracker.ietf.org/wg/dmarc].
Authors' Addresses Authors' Addresses
Steven Jones Steven Jones
DMARC.org DMARC.org
Email: smj@crash.com Email: smj@crash.com
Kurt Andersen
LinkedIn
2029 Stierlin Ct.
Mountain View, California 94043
USA
Email: kurta@linkedin.com
John Rae-Grant John Rae-Grant
Google Google
Email: johnrg@google.com Email: johnrg@google.com
J. Trent Adams J. Trent Adams (editor)
Paypal Paypal
Email: trent.adams@paypal.com Email: trent.adams@paypal.com
Kurt Andersen (editor)
LinkedIn
2029 Stierlin Ct.
Mountain View, California 94043
USA
Email: kurta@linkedin.com
 End of changes. 50 change blocks. 
102 lines changed or deleted 213 lines changed or added

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