draft-ietf-dmarc-arc-usage-07.txt   draft-ietf-dmarc-arc-usage-08.txt 
DMARC Working Group S. Jones, Ed. 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, 2019 LinkedIn Expires: April 24, 2020 LinkedIn
April 23, 2019 October 22, 2019
Recommended Usage of the Authenticated Received Chain (ARC) Recommended Usage of the Authenticated Received Chain (ARC)
draft-ietf-dmarc-arc-usage-07 draft-ietf-dmarc-arc-usage-08
Abstract Abstract
The Authentication Received Chain (ARC) provides an authenticated The Authentication Received Chain (ARC) provides an authenticated
"chain of custody" for a message, allowing each entity that handles "chain of custody" for a message, allowing each entity that handles
the message to see what entities handled it before, and to see what the message to see what entities handled it before, and to see what
the message's authentication assessment was at each step in the the message's authentication assessment was at each step in the
handling. But the specification does not indicate how the entities handling. But the specification does not indicate how the entities
handling these messages should interpret or utilize ARC results in handling these messages should interpret or utilize ARC results in
making decisions about message disposition. This document will making decisions about message disposition. This document will
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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, 2019. This Internet-Draft will expire on April 24, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 8, line 26 skipping to change at page 8, line 26
the message they received had passed authentication checks. the message they received had passed authentication checks.
3.8. What about ARC chains where some intermediaries are known and 3.8. 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 to identify which
intermediaries may have manipulated the message or injected bad intermediaries may have manipulated the message or injected bad
content. content.
3.9. What should message handlers do when they detect malicious content 3.9. 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.
skipping to change at page 14, line 9 skipping to change at page 14, line 9
[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>.
7.2. Informative References 7.2. Informative References
[ARC] Andersen, K., Long, B., Blank, S., and M. Kucherawy, [ARC] Andersen, K., Long, B., Blank, S., and M. Kucherawy,
"Authenticated Received Chain (ARC) Protocol", December "Authenticated Received Chain (ARC) Protocol", December
2018, <https://tools.ietf.org/html/ 2018, <https://tools.ietf.org/html/draft-ietf-dmarc-arc-
draft-ietf-dmarc-arc-protocol-23>. protocol-23>.
[ARC-MULTI] [ARC-MULTI]
Andersen, K., Blank, S., and J. Levine, "Using Multiple Andersen, K., Blank, S., and J. Levine, "Using Multiple
Signing Algorithms with ARC", June 2018, Signing Algorithms with ARC", June 2018,
<https://tools.ietf.org/html/ <https://tools.ietf.org/html/draft-ietf-dmarc-arc-multi-
draft-ietf-dmarc-arc-multi-02>. 02>.
[draft-levine-eaiauth] [draft-levine-eaiauth]
Levine, J., "E-mail Authentication for Internationalized Levine, J., "E-mail Authentication for Internationalized
Mail", August 2018, <https://tools.ietf.org/html/ Mail", August 2018, <https://tools.ietf.org/html/draft-
draft-levine-appsarea-eaiauth-03>. levine-appsarea-eaiauth-03>.
[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>.
[I-D-7601bis] [I-D-7601bis]
Kucherawy, M., "Message Header Field for Indicating Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", February 2018, Message Authentication Status", February 2018,
<https://datatracker.ietf.org/doc/ <https://datatracker.ietf.org/doc/draft-ietf-dmarc-
draft-ietf-dmarc-rfc7601bis/>. rfc7601bis/>.
[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-
draft-kucherawy-original-authres-00>. authres-00>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76, "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011, RFC 6376, DOI 10.17487/RFC6376, September 2011,
<https://www.rfc-editor.org/info/rfc6376>. <https://www.rfc-editor.org/info/rfc6376>.
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1", RFC 7208, Authorizing Use of Domains in Email, Version 1", RFC 7208,
DOI 10.17487/RFC7208, April 2014, DOI 10.17487/RFC7208, April 2014,
<https://www.rfc-editor.org/info/rfc7208>. <https://www.rfc-editor.org/info/rfc7208>.
skipping to change at page 19, line 10 skipping to change at page 19, line 10
[10] mailing list at http://lists.dmarc.org/mailman/listinfo/arc- [10] mailing list at http://lists.dmarc.org/mailman/listinfo/arc-
discuss [11]. discuss [11].
Authors' Addresses Authors' Addresses
Steven M Jones (editor) Steven M Jones (editor)
DMARC.org DMARC.org
2419 McGee Avenue 2419 McGee Avenue
Berkeley, California 94703 Berkeley, California 94703
USA USA
Email: smj@crash.com Email: smj@dmarc.org
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
 End of changes. 10 change blocks. 
16 lines changed or deleted 16 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/