draft-ietf-dmarc-arc-usage-05.txt   draft-ietf-dmarc-arc-usage-06.txt 
DMARC Working Group S. Jones DMARC Working Group S. Jones, Ed.
Internet-Draft DMARC.org Internet-Draft DMARC.org
Intended status: Informational K. Andersen Intended status: Informational K. Andersen
Expires: October 25, 2018 LinkedIn Expires: April 25, 2019 LinkedIn
J. Rae-Grant J. Rae-Grant
Google Google
T. Adams, Ed. T. Adams
Paypal Paypal
April 23, 2018 October 22, 2018
Recommended Usage of the Authenticated Received Chain (ARC) Recommended Usage of the Authenticated Received Chain (ARC)
draft-ietf-dmarc-arc-usage-05 draft-ietf-dmarc-arc-usage-06
Abstract Abstract
The Authentication Received Chain (ARC) provides a means to preserve The Authentication Received Chain (ARC) provides an authenticated
email authentication results and verify the identity of email message "chain of custody" for a message, allowing each entity that handles
handlers, each of which participates by inserting certain header the message to see what entities handled it before, and to see what
fields before passing the message on. But the specification does not the message's authentication assessment was at each step in the
indicate how intermediaries and receivers should interpret or utilize handling. But the specification does not indicate how the entities
ARC. This document will provide guidance in these areas. handling these messages should interpret or utilize ARC results in
making decisions about message disposition. 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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 25, 2018. This Internet-Draft will expire on April 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. How does ARC work? . . . . . . . . . . . . . . . . . . . . . 3 2. How does ARC work? . . . . . . . . . . . . . . . . . . . . . 3
3. Guidance for Receivers/Validators . . . . . . . . . . . . . . 4 3. Guidance for Receivers/Validators . . . . . . . . . . . . . . 5
3.1. What is the significance of an intact ARC chain? . . . . 4 3.1. What is the significance of an intact ARC chain? . . . . 5
3.2. What exactly is an "intact" ARC chain? . . . . . . . . . 4 3.2. What exactly is an "intact" ARC chain? . . . . . . . . . 5
3.3. What is the significance of an invalid ("broken") ARC 3.3. What is the significance of an invalid ("broken") ARC
chain? . . . . . . . . . . . . . . . . . . . . . . . . . 5 chain? . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. What does the absence of an ARC chain in a message mean? 5 3.4. What does the absence of an ARC chain in a message mean? 6
3.5. What reasonable conclusions can you draw based upon 3.5. What reasonable conclusions can you draw based upon
seeing lots of mail with ARC chains? . . . . . . . . . . 6 seeing lots of mail with ARC chains? . . . . . . . . . . 6
3.6. What if none of the intermediaries have been seen 3.6. What if none of the intermediaries have been seen
previously? . . . . . . . . . . . . . . . . . . . . . . . 6 previously? . . . . . . . . . . . . . . . . . . . . . . . 7
3.7. What about ARC chains where some intermediaries are known 3.7. What about ARC chains where some intermediaries are known
and others are not? . . . . . . . . . . . . . . . . . . . 6 and others are not? . . . . . . . . . . . . . . . . . . . 7
3.8. What should message handlers do when they detect 3.8. What should message handlers do when they detect
malicious content in messages where ARC is present? . . . 7 malicious content in messages where ARC is present? . . . 7
3.9. What feedback does a sender or domain owner get about ARC 3.9. What feedback does a sender or domain owner get about ARC
when it is applied to their messages? . . . . . . . . . . 7 when it is applied to their messages? . . . . . . . . . . 8
3.10. What prevents a malicious actor from removing the ARC 3.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? . . . . . . . . . . . . . . . . . . . . . . . 8
4. Guidance for Intermediaries . . . . . . . . . . . . . . . . . 8 4. Guidance for Intermediaries . . . . . . . . . . . . . . . . . 8
4.1. What is an Intermediary under ARC? . . . . . . . . . . . 8 4.1. What is an Intermediary under ARC? . . . . . . . . . . . 8
4.2. What are the minimum requirements for an ARC 4.2. What are the minimum requirements for an ARC
Intermediary? . . . . . . . . . . . . . . . . . . . . . . 8 Intermediary? . . . . . . . . . . . . . . . . . . . . . . 9
4.2.1. More specifically a participating ARC intermediary 4.2.1. More specifically a participating ARC intermediary
must do the following: . . . . . . . . . . . . . . . 8 must do the following: . . . . . . . . . . . . . . . 9
4.3. Should every MTA be an ARC participant? . . . . . . . . . 9 4.3. Should every MTA be an ARC participant? . . . . . . . . . 9
4.4. What should an intermediary do in the case of an invalid 4.4. What should an intermediary do in the case of an invalid
or "broken" ARC chain? . . . . . . . . . . . . . . . . . 9 or "broken" ARC chain? . . . . . . . . . . . . . . . . . 9
4.5. What should I do in the case where there is no ARC chain 4.5. What should I do in the case where there is no ARC chain
present in a message? . . . . . . . . . . . . . . . . . . 9 present in a message? . . . . . . . . . . . . . . . . . . 10
4.6. How could ARC affect my reputation as an intermediary? . 9 4.6. How could ARC affect my reputation as an intermediary? . 10
4.7. What can I do to influence my reputation as an 4.7. What can I do to influence my reputation as an
intermediary? . . . . . . . . . . . . . . . . . . . . . . 10 intermediary? . . . . . . . . . . . . . . . . . . . . . . 10
5. Guidance for Originators . . . . . . . . . . . . . . . . . . 10 5. Guidance for Originators . . . . . . . . . . . . . . . . . . 10
5.1. Where can I find out more information? . . . . . . . . . 10 5.1. Where can I find out more information? . . . . . . . . . 10
5.2. How/where can I test interoperabililty for my 5.2. How/where can I test interoperabililty for my
implementation? . . . . . . . . . . . . . . . . . . . . . 10 implementation? . . . . . . . . . . . . . . . . . . . . . 11
5.3. How can ARC impact my email? . . . . . . . . . . . . . . 11
5.3. How can ARC impact my email? . . . . . . . . . . . . . . 10
5.4. How can ARC impact my reputation as a message sender? . . 11 5.4. How can ARC impact my reputation as a message sender? . . 11
5.5. Can I tell intermediaries not to use ARC? . . . . . . . . 11 5.5. Can I tell intermediaries not to use ARC? . . . . . . . . 11
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Considerations . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . 11 6.1. IANA Considerations . . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . 12 6.2. Security Considerations . . . . . . . . . . . . . . . . . 12
6.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
Appendix A. GLOSSARY . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . 12
Appendix B. References . . . . . . . . . . . . . . . . . . . . . 15 7.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 15 Appendix A. GLOSSARY . . . . . . . . . . . . . . . . . . . . . . 13
Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 15 Appendix B. References . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 16
Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
[ARC] is intended to be used primarily by intermediaries, or message [ARC] is intended to be used by Internet Mail Handlers who forward or
handlers - those parties who may forward or resend messages, with or resend messages, with or without alterations, such that they will no
without alterations, such that they will no longer pass the SPF, longer pass the SPF [RFC7208], DKIM [RFC6376], and/or DMARC [RFC7489]
DKIM, and/or [RFC7489] authentication mechanisms. In such cases ARC mechanisms when evaluated by subsequent message handlers or the final
may provide the final message recipient with useful information about recipient. In such cases ARC may provide useful information about
the original sender. the message before the forwarding and/or alterations took place, and
recipients may choose to use this information to influence delivery
decisions.
2. How does ARC work? 2. How does ARC work?
Consider a mailing list as an example, where the message submitter's Consider a message sent to a mailing list. Assume that the message
domain publishes a DMARC policy other than "p=none". The message is author's domain publishes an SPF record, signs messages with a DKIM
received, a prefix is added to the RFC5322.Subject header field, some signature that includes the RFC5322.Subject header and the message
text is appended to the message body, and the message is sent to list body, and publishes a DMARC policy of "p=reject". Finally, assume
members with the original RFC5322.From address intact. In this case that the final recipient(s) of the message implement SPF, DKIM and
SPF may pass because the mailing list operator uses their own domain DMARC authentication checks on incoming messages.
in the RFC5321.MailFrom header field, but this domain will not match
the RFC5322.From address, thus the DMARC SPF result cannot be a
"pass." Any DKIM signature from the message submitter's domain will
be broken as the message body has been altered (and if included in
the signature, the RFC5322.Subject header field). Again, the DMARC
DKIM result cannot be a "pass." And if the mailing list operator
inserted an Authentication-Results header field it was most likely
stripped and/or replaced by the next message receiver.
If the mailing list implemented ARC, it would record the contents of This message is received by the ADMD hosting the Mailing List Manager
the Authentication-Results header field in the ARC-Authentication- (MLM) software. Upon receipt from the message author's ADMD, the
Results header field. It would then create an an ARC-Message- results from any DKIM, DMARC, and SPF checks would be recorded in an
Signature header field, which includes a cryptographic signature of Authentication-Results header. Then as part of normal list operation
the message itself, and then an ARC-Seal header field, which includes the following changes are made to the message:
a cryptographic signature of a few key message header fields -
including the other ARC header fields.
Any subsequent system participating in ARC that was not performing o An address controlled by the MLM is substituted in the
final delivery of the message within its ADMD boundaries would also RFC5321.MailFrom address field, allowing it to receive
generate and insert ARC header fields whose signatures cover all ARC undeliverable messages
header fields inserted into the message by previous message handlers.
Thus the information from any previous ARC participants, including
the ARC-Authentication-Results header field from the mailing list
operator, would be signed at each ADMD that handled the message.
When the message reaches the final receiving system, the SPF and DKIM o A prefix is added to the message's RFC5322.Subject header
results will not satisfy the DMARC policy for the message author's
domain. However if the receiving system implements ARC then it can o Some text is appended to the message body
check for and validate an ARC chain and verify that the contents of
the ARC-Authentication-Results header field were conveyed intact from After these alterations have been made, the message is sent to list
the mailing list operator. At that point the receiving system might members.
choose to use those authentication results in the decision of whether
or not to deliver the message, even though it failed to pass the A list member's ADMD receiving the message will typically strip out
usual authentication checks. any existing Authentication-Results headers. It will then perform an
SPF check using the domain in the RFC5321.MailFrom address field, and
would find that the sending host is in the list of authorized senders
for the MLM's domain. However under DMARC, since this domain does
not match the domain in the RFC5322.From address field, the DMARC SPF
result is "fail."
The DKIM signature from the domain in the RFC5322.From address field
- the message author's domain - will fail to verify, because the
RFC5322.Subject header and the message body were altered by the MLM.
Therefore the DMARC DKIM result is also "fail," even if there is a
valid DKIM signature attached by the MLM's ADMD using its domain.
Since neither SPF or DKIM yield a "pass" under DMARC's alignment
rules, the DMARC result for this message is "fail." Therefore under
the DMARC policy published by the message author's domain, the list
member's ADMD should reject the message.
If the MLM implemented ARC, it would record the results of its email
authentication checks when receiving the message from the author's
ADMD in the Authentication-Results header, then perform the
alterations described above. It would then "seal" the message under
ARC, which includes the following steps.
It would record the contents of the Authentication-Results header(s)
in a newly created ARC-Authentication-Results header. It would
create an ARC-Message-Signature header, which includes a
cryptographic signature of the message itself very similar to a DKIM
signature, but excluding any ARC headers. Then it would create an
ARC-Seal header, which includes a cryptographic signature of all ARC
headers present in the message. The MLM's ADMD would then send the
ARC "sealed" message to the list members.
When the message reaches a list member's ADMD, the SPF and DKIM
results will still not pass the DMARC check. However if the
receiving ADMD implements ARC, it can check for and validate the ARC
chain in the message, and verify that the contents of the ARC-
Authentication-Results header were conveyed intact from the MLM's
ADMD. At that point the final recipient's ADMD might choose to use
those authentication results in the decision whether or not to
deliver the message, even though it failed to pass conventional SPF,
DKIM, and DMARC checks.
3. Guidance for Receivers/Validators 3. Guidance for Receivers/Validators
3.1. What is the significance of an intact ARC chain? 3.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 first 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? 3.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 headers that are present can
present can be validated, and in particular the ARC-Message-Signature be validated, and in particular the ARC-Message-Signature header from
header field from the last ARC participant can still be validated. the last ARC participant can still be validated. This shows that the
This shows that, whether another ADMD handled the message after the portions of the message covered by that signature were not altered.
last ARC participant or not, the portions of the message covered by If any non-participating ADMDs handled the message since the last ARC
that signature were not altered. If any non-participating ADMDs intermediary but did not alter the message in a way that invalidated
handled the message between ARC intermediaries but did not alter the the most recent ARC-Message-Signature present, the chain would still
message in a way that invalidated the most recent ARC-Message- be considered intact by the next ARC-enabled ADMD.
Signature present at that time, the chain would still be considered
intact by the next ARC participant, and recorded as such in the ARC-
Seal header field they insert.
Message receivers may make local policy decisions about whether to Message receivers may make local policy decisions about whether to
use the contents of the ARC-Authentication-Results header field in use the contents of the ARC-Authentication-Results header field in
cases where a message no longer passes DKIM, DMARC, and/or SPF cases where a message no longer passes DKIM, DMARC, and/or SPF
checks. Whether an ARC chain is intact can be used to inform that checks. Whether an ARC chain is intact can be used to inform that
local policy decision. local policy decision.
So for example one message receiver may decide that, for messages So for example one message receiver may decide that, for messages
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 from the first ARC
reported by the first ARC intermediary that matches the domain in the participant indicates a DKIM pass was reported that matches the
RFC5322.From header field, it will override a DMARC "p=reject" domain in the RFC5322.From header field, it may override a DMARC
policy. Another message receiver may decide to do so for intact ARC "p=reject" policy. Another message receiver may decide to do so only
chains where the ARC-Authentication-Results header field indicates an for a limited number of ARC-enabled ADMDs. A third message receiver
SPF pass. A third message receiver may use very different criteria, may choose not to take ARC information into account at all.
according to their requirements, while a fourth may choose not to
take ARC information into account at all.
3.3. What is the significance of an invalid ("broken") ARC chain? 3.3. What is the significance of an invalid ("broken") ARC chain?
An ARC chain is broken if the signatures in the ARC-Seal header An ARC chain is broken if the signatures in the ARC-Seal header
fields cannot be verified or if the most recent AMS can not be fields cannot be verified, or if the most recent AMS can not be
verified. For example the remote server delivering the message to verified. For example if a non-ARC-enabled ADMD delivers a message
the local ADMD is not reflected in any ARC header fields, perhaps with ARC header sets to the validating ADMD, but modified the message
because they have not implemented ARC, but they modified the message such that those ARC and DKIM signatures already in the message were
such that ARC and DKIM signatures already in the message were
invalidated. invalidated.
In case of a broken ARC chain, the message should be treated the same In case of a broken ARC chain, the message should be treated the same
as if there was no ARC chain at all. For example, a message that as if there was no ARC chain at all. For example, a message that
fails under DMARC and has an invalid ARC chain would be subject to fails under DMARC and has an invalid ARC chain would be subject to
that DMARC policy, which may cause it to be quarantined or rejected. that DMARC policy, which may cause it to be quarantined or rejected.
Email transit can produce broken signatures for a wide variety of Email transit can produce broken signatures for a wide variety of
benign reasons. This includes possibly breaking one or more ARC benign reasons. This includes possibly breaking one or more ARC
signatures. Therefore, receivers need to be wary of ascribing motive signatures. Therefore, receivers need to be wary of ascribing motive
to such breakage although patterns of common behaviour may provide to such breakage, although patterns of common behaviour may provide
some basis for adjusting local policy decisions. some basis for adjusting local policy decisions.
3.4. What does the absence of an ARC chain in a message mean? 3.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.
skipping to change at page 8, line 37 skipping to change at page 9, line 18
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 4.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. ([ARC] Section 5.2)
2. Validate that the most recent sender matches the last entry in
the ARC chain (if present).
3. Validate that the most recent sender's DKIM signature is
attached, and matches the reference to it in the ARC chain (if
present).
4. Generate a new ARC Signature and add it to the message according 2. Record the ARC status in an Authentication-Results header
to the ARC specification. ([RFC7601])
5. Generate a new ARC Seal and add it to the message according to 3. Generate a new ARC set and add it to the message. ([ARC]
the ARC specification. Section 5.1)
4.3. Should every MTA be an ARC participant? 4.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.
skipping to change at page 10, line 27 skipping to change at page 10, line 49
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 5. Guidance for Originators
5.1. Where can I find out more information? 5.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].
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? 5.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? 5.3. How can ARC impact my email?
skipping to change at page 11, line 32 skipping to change at page 12, line 5
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? 5.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 6. Considerations
6.1. Normative References 6.1. IANA Considerations
This document has no actions for IANA.
6.2. Security Considerations
This document does not have security considerations aside from those
raised in the main content.
7. 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,
<https://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,
<https://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,
skipping to change at page 12, line 10 skipping to change at page 12, line 41
[RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and
Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377, Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377,
September 2011, <https://www.rfc-editor.org/info/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,
<https://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., and S. Jones, [ARC] Andersen, K., Long, B., Blank, S., Kucherawy, M., and T.
"Authenticated Received Chain (ARC) Protocol", December Draegen, "Authenticated Received Chain (ARC) Protocol",
2017, <https://tools.ietf.org/html/ October 2018, <https://tools.ietf.org/html/
draft-ietf-dmarc-arc-protocol-10>. draft-ietf-dmarc-arc-protocol-18>.
[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/ <https://tools.ietf.org/html/
draft-kucherawy-original-authres-00>. draft-kucherawy-original-authres-00>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011,
<https://www.rfc-editor.org/info/rfc6376>.
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1", RFC 7208,
DOI 10.17487/RFC7208, April 2014,
<https://www.rfc-editor.org/info/rfc7208>.
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
Message Authentication, Reporting, and Conformance Message Authentication, Reporting, and Conformance
(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
<https://www.rfc-editor.org/info/rfc7489>. <https://www.rfc-editor.org/info/rfc7489>.
[RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky, [RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky,
E., Ed., and K. Andersen, Ed., "Interoperability Issues E., Ed., and K. Andersen, Ed., "Interoperability Issues
between Domain-based Message Authentication, Reporting, between Domain-based Message Authentication, Reporting,
and Conformance (DMARC) and Indirect Email Flows", and Conformance (DMARC) and Indirect Email Flows",
RFC 7960, DOI 10.17487/RFC7960, September 2016, RFC 7960, DOI 10.17487/RFC7960, September 2016,
<https://www.rfc-editor.org/info/rfc7960>. <https://www.rfc-editor.org/info/rfc7960>.
6.3. URIs
[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
might be a large university, operating many servers that fulfill might be a large university, operating many servers that fulfill
different roles, all handling email for several different domains different roles, all handling email for several different domains
representing parts of the university. representing parts of the university.
skipping to change at page 15, line 33 skipping to change at page 16, line 21
within the message and various types of content within the message within the message and various types of content within the message
body. Link: [RFC5322] body. Link: [RFC5322]
Validator A Message Receiver that attempts to validate the ARC chain Validator A Message Receiver that attempts to validate the ARC chain
in a message. in a message.
Appendix B. References Appendix B. References
Appendix C. Acknowledgements Appendix C. Acknowledgements
This draft is the work of OAR-Dev Group. This draft is based on the work of OAR-Dev Group.
The authors thanks the entire OAR-Dev group for the ongoing help, The authors thank the entire OAR-Dev group for the ongoing help,
innumerable diagrams and discussions from all the participants, innumerable diagrams and discussions from all the participants,
especially: Alex Brotman, Brandon Long, Dave Crocker, Elizabeth especially: Alex Brotman, Brandon Long, Dave Crocker, Elizabeth
Zwicky, Franck Martin, Greg Colburn, J. Trent Adams, John Rae-Grant, Zwicky, Franck Martin, Greg Colburn, J. Trent Adams, John Rae-Grant,
Mike Hammer, Mike Jones, Steve Jones, Terry Zink, Tim Draegen. Mike Hammer, Mike Jones, Steve Jones, Terry Zink, Tim Draegen.
Appendix D. Comments and Feedback Appendix D. Comments and Feedback
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 (editor)
DMARC.org DMARC.org
Email: smj@crash.com Email: smj@crash.com
Kurt Andersen Kurt Andersen
LinkedIn LinkedIn
2029 Stierlin Ct. 2029 Stierlin Ct.
Mountain View, California 94043 Mountain View, California 94043
USA USA
Email: kurta@linkedin.com Email: kurta@linkedin.com
John Rae-Grant John Rae-Grant
Google Google
Email: johnrg@google.com Email: johnrg@google.com
J. Trent Adams (editor) J. Trent Adams
Paypal Paypal
Email: trent.adams@paypal.com Email: trent.adams@paypal.com
 End of changes. 44 change blocks. 
136 lines changed or deleted 171 lines changed or added

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