draft-ietf-dmarc-arc-usage-01.txt   draft-ietf-dmarc-arc-usage-02.txt 
DMARC Working Group S. Jones DMARC Working Group S. Jones
Internet-Draft DMARC.org Internet-Draft DMARC.org
Obsoletes: draft-jones-arc-usage-01 (if J. Rae-Grant Intended status: Informational J. Rae-Grant
approved) Google Expires: December 22, 2017 Google
Intended status: Informational T. Adams T. Adams
Expires: May 29, 2016 Paypal Paypal
K. Andersen, Ed. K. Andersen, Ed.
LinkedIn LinkedIn
December 27, 2016 June 20, 2017
Recommended Usage of the Authenticated Received Chain (ARC) Recommended Usage of the Authenticated Received Chain (ARC)
draft-ietf-dmarc-arc-usage-01 draft-ietf-dmarc-arc-usage-02
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.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 29, 2017. This Internet-Draft will expire on December 22, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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 (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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
skipping to change at page 2, line 32 skipping to change at page 2, line 32
seeing lots of mail with ARC chains? . . . . . . . . . . 5 seeing lots of mail with ARC chains? . . . . . . . . . . 5
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? . . . . . . . . . . . . . . . . . . . . . . . 6
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? . . . . . . . . . . . . . . . . . . . 6
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? . . . 6 malicious content in messages where ARC is present? . . . 6
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? . . . . . . . . . . 7
3.10. What prevents a malicious actor from removing the ARC 3.10. What prevents a malicious actor from removing the ARC
header fields, . . . . . . . . . . . . . . . . . . . . . 7 header fields, altering the content, and creating a new
ARC chain? . . . . . . . . . . . . . . . . . . . . . . . 7
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? . . . . . . . . . . . . . . . . . . . . . . 8
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: . . . . . . . . . . . . . . . 8
4.3. Should every MTA be an ARC participant? . . . . . . . . . 8 4.3. Should every MTA be an ARC participant? . . . . . . . . . 8
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
skipping to change at page 5, line 10 skipping to change at page 5, line 14
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 indicates a DKIM pass was
reported by the first ARC intermediary that matches the domain in the RFC5322.From header field, it reported by the first ARC intermediary that matches the domain in the
will override a DMARC "p=reject" policy. Another message receiver RFC5322.From header field, it will override a DMARC "p=reject"
may decide to do so for intact ARC chains where the ARC- policy. Another message receiver may decide to do so for intact ARC
Authentication-Results header field indicates an SPF pass. A third chains where the ARC-Authentication-Results header field indicates an
message receiver may use very different criteria, according to their SPF pass. A third message receiver may use very different criteria,
requirements, while a fourth may choose not to take ARC information according to their requirements, while a fourth may choose not to
into account at all. 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 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.
skipping to change at page 5, line 38 skipping to change at page 5, line 42
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? 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 absent, the final recipient can evaluate this information. If they are
there is nothing extra that ARC requires the final recipient to do. absent, there is nothing extra that ARC requires the final recipient
to do.
3.5. What reasonable conclusions can you draw based upon seeing lots of 3.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 ARC authentication policy (i.e. a message could fail DMARC, but validated
information could be considered to show the message was authenticated as ARC information and therefore could be considered as validly
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
skipping to change at page 7, line 39 skipping to change at page 7, line 42
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
determining how to handle the message. The decision to use the ARC- determining how to handle the message. The decision to use the ARC-
Authentication-Results header field is dependent on evaluation of Authentication-Results header field is dependent on evaluation of
those ARC intermediaries. those ARC intermediaries.
In the first case, the bad actor has succeeded in manipulating the In the first case, the bad actor has succeeded in manipulating the
message but they have attached a verifiable signature identifying message but they have attached a verifiable signature identifying
themselves. While not an ideal situation, it is something they are themselves. While not an ideal situation, it is something they are
already able to do without ARC involved, but now a signature linked to the already able to do without ARC involved, but now a signature linked
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 4. Guidance for Intermediaries
skipping to change at page 10, line 16 skipping to change at page 10, line 16
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]. [1][mailto:arc-discuss@dmarc.org].
To discuss the IETF spec itself, please join the dmarc working group
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?
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 ARC participating intermediaries. Message receivers may accept validated
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? 5.4. How can ARC impact my reputation as a message sender?
skipping to change at page 11, line 40 skipping to change at page 11, line 42
<http://www.rfc-editor.org/info/rfc5598>. <http://www.rfc-editor.org/info/rfc5598>.
[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>.
6.2. Informative References 6.2. Informative References
[ARC] Andersen, K., Rae-Grant, J., Long, B., Adams, T., and S. [ARC] Andersen, K., Rae-Grant, J., Long, B., Adams, T., and S.
Jones, "Authenticated Received Chain (ARC) Protocol", December Jones, "Authenticated Received Chain (ARC) Protocol", June
2016, <https://tools.ietf.org/html/draft-ietf-dmarc-arc- 2017, <https://tools.ietf.org/html/draft-ietf-dmarc-arc-
protocol-01>. protocol-04>.
[RFC7960]
Martin, F., Lear, E., Draegen, T., Zwicky, E., and K.
Andersen, "Interoperability Issues Between DMARC and
Indirect Email Flows", June 2016,
<https://tools.ietf.org/html/draft-ietf-dmarc-
interoperability-17>.
[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/draft-kucherawy-original-
authres-00>. 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>. <http://www.rfc-editor.org/info/rfc7489>.
[RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky,
E., Ed., and K. Andersen, Ed., "Interoperability Issues
between Domain-based Message Authentication, Reporting,
and Conformance (DMARC) and Indirect Email Flows",
RFC 7960, DOI 10.17487/RFC7960, September 2016,
<http://www.rfc-editor.org/info/rfc7960>.
6.3. URIs 6.3. URIs
[1] mailto:arc-discuss@dmarc.org [1] mailto:arc-discuss@dmarc.org
[2] 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 13, line 28 skipping to change at page 13, line 28
a vendor or partner firm that sends mail on behalf of another a vendor or partner firm that sends mail on behalf of another
company. They may use email addresses in Internet domains company. They may use email addresses in Internet domains
belonging to the client or partner firm in various [RFC5321] belonging to the client or partner firm in various [RFC5321]
fields or [RFC5322] message header fields of the messages they fields or [RFC5322] message header fields of the messages they
send on their behalf. send on their behalf.
Intermediary In the context of [ARC], an Intermediary is typically Intermediary In the context of [ARC], an Intermediary is typically
an Administrative Management Domain (per [RFC5598]) that is an Administrative Management Domain (per [RFC5598]) that is
receiving a message, potentially manipulating or altering it, and receiving a message, potentially manipulating or altering it, and
then passing it on to another ADMD for delivery. Also see then passing it on to another ADMD for delivery. Also see
[DMARC-INTEROP] for more information and discussion. Common [RFC7960] for more information and discussion. Common examples of
examples of Intermediaries are mailing lists, alumni or Intermediaries are mailing lists, alumni or professional email
professional email address providers like universities or address providers like universities or professional organizations,
professional organizations, et cetera. et cetera.
Mail/Message Transfer Agent (MTA) This refers to software that sends Mail/Message Transfer Agent (MTA) This refers to software that sends
and receives email messsages across a network with other MTAs. and receives email messsages across a network with other MTAs.
Often run on dedicated servers, common examples are Exim, Often run on dedicated servers, common examples are Exim,
Microsoft Exchange, Postfix, and Sendmail. Microsoft Exchange, Postfix, and Sendmail.
Mailflow A group of messages that share features in common. Typical Mailflow A group of messages that share features in common. Typical
examples would be all messages sent by a given Message Sender to a examples would be all messages sent by a given Message Sender to a
Message Receiver, related to a particular announcement, a given Message Receiver, related to a particular announcement, a given
mailing list, et cetera. mailing list, et cetera.
skipping to change at page 15, line 22 skipping to change at page 15, line 22
This draft is the work of OAR-Dev Group. This draft is the work of OAR-Dev Group.
The authors thanks the entire OAR-Dev group for the ongoing help, The authors thanks 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 arc- Please address all comments, discussions, and questions to the dmarc
discuss@dmarc.org [2][mailto:arc-discuss@dmarc.org]. 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
John Rae-Grant John Rae-Grant
Google Google
 End of changes. 17 change blocks. 
43 lines changed or deleted 46 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/