--- 1/draft-ietf-dmarc-arc-usage-00.txt 2016-12-27 15:13:12.608291473 -0800 +++ 2/draft-ietf-dmarc-arc-usage-01.txt 2016-12-27 15:13:12.644292313 -0800 @@ -1,23 +1,23 @@ DMARC Working Group S. Jones Internet-Draft DMARC.org Obsoletes: draft-jones-arc-usage-01 (if J. Rae-Grant approved) Google Intended status: Informational T. Adams -Expires: December 27, 2016 Paypal +Expires: May 29, 2016 Paypal K. Andersen, Ed. LinkedIn - June 25, 2016 + December 27, 2016 Recommended Usage of the Authenticated Received Chain (ARC) - draft-ietf-dmarc-arc-usage-00 + draft-ietf-dmarc-arc-usage-01 Abstract The Authentication Received Chain (ARC) provides a means to preserve email authentication results and verify the identity of email message handlers, each of which participates by inserting certain header fields before passing the message on. But the specification does not indicate how intermediaries and receivers should interpret or utilize ARC. This document will provide guidance in these areas. @@ -29,21 +29,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on December 27, 2016. + This Internet-Draft will expire on May 29, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -189,21 +189,21 @@ Message receivers may make local policy decisions about whether to use the contents of the ARC-Authentication-Results header field in 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 local policy decision. So for example one message receiver may decide that, for messages with an intact ARC chain where a DMARC evaluation does not pass, but the ARC-Authentication-Results header field indicates a DKIM pass was - reported that matches the domain in the RFC5322.From header field, it + reported by the first ARC intermediary that matches the domain in the RFC5322.From header field, it will override a DMARC "p=reject" policy. Another message receiver may decide to do so for intact ARC chains where the ARC- Authentication-Results header field indicates an SPF pass. A third message receiver may use very different criteria, 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? An ARC chain is not considered to be valid if the signatures in the @@ -217,29 +217,29 @@ 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 subject to that DMARC policy, which may cause it to be quarantined or rejected. 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 a participating message handler to preserve certain authentication results when a message is being forwarded and/or modified such that - the final recipient can evaluate the source. If they are absent, + the final recipient can evaluate this information. If they are 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 mail with ARC chains? With sufficient history, ARC can be used to augment DMARC - authentication policy (i.e. a message could fail DMARC, but pass ARC - and therefore could be considered as validly authenticated as + authentication policy (i.e. a message could fail DMARC, but validated ARC + information could be considered to show the message was authenticated as reported by the first ARC participant). If the validator does content analysis and reputation tracking, the ARC participants in a message can be credited or discredited for good or bad content. By analyzing different ARC chains involved in "bad" messages, a validator might identify malicious participating intermediaries. With a valid chain and good reputations for all ARC participants, receivers may choose to apply a "local policy override" to the DMARC @@ -297,47 +297,45 @@ ARC itself does not include any mechanism for feedback or reporting. It does however recommend that message receiving systems that use ARC to augment their delivery decisions, who use DMARC and decide to deliver a message because of ARC information, should include a notation to that effect in their normal DMARC reports. These notations would be easily identifiable by report processors, so that senders and domain owners can see where ARC is being used to augment the deliverability of their messages. 3.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 prevent a malicious actor from removing all but the first ADMD's ARC header fields and altering the message, eliminating intervening participants from the ARC chain. Or similar variations. A valid ARC chain does not provide any automatic benefit. With an intact ARC chain, the final message recipient may choose to use the contents of the ARC-Authentication-Results header field in determining how to handle the message. The decision to use the ARC- Authentication-Results header field is dependent on evaluation of those ARC intermediaries. In the first case, the bad actor has succeeded in manipulating the message but they have attached a verifiable signature identifying themselves. While not an ideal situation, it is something they are - already able to do without ARC involved, but now a strong link to the + already able to do without ARC involved, but now a signature linked to the domain responsible for the manipulation is present. Additionally in the second case it is possible some negative reputational impact might accrue to the first ARC participant left in place until more messages reveal the pattern of activity by the bad actor. But again, a bad actor can similarly manipulate a sequence of - RFC5322.Received header fields today without ARC, and with ARC that + RFC5322.Received header fields today without ARC, but with ARC that bad actor has verifiably identified themselves. 4. Guidance for Intermediaries 4.1. What is an Intermediary under ARC? In the context of ARC, an Intermediary is typically an Administrative Management Domain [RFC5598] that is receiving a message, potentially manipulating or altering it, and then passing it on to another ADMD for delivery. Common examples of Intermediaries are mailing lists, @@ -447,23 +445,23 @@ 5.3. How can ARC impact my email? Prior to ARC, certain DMARC policies on a domain would cause messages using those domains in the RFC5322.From field, and which pass through certain kinds of intermediaries (mailing lists, forwarding services), to fail authentication checks at the message receiver. As a result these messages might not be delivered to the intended recipient. ARC seeks to provide these so-called "indirect mailflows" with a - means to preserve email authentication results as seen by - participating intermediaries. Message receivers may accept ARC - results to supplement the information that DMARC provides, + means to preserve email authentication results as recorded by + participating intermediaries. Message receivers may accept validated ARC + information to supplement the information that DMARC provides, potentially deciding to deliver the message even though a DMARC check did not pass. The net result for domain owners and senders is that ARC may allow messages routed through participating ARC intermediaries to be delivered, even though those messages would not have been delivered in the absence of ARC. 5.4. How can ARC impact my reputation as a message sender? @@ -504,25 +502,25 @@ . [RFC7601] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 7601, DOI 10.17487/RFC7601, August 2015, . 6.2. Informative References [ARC] Andersen, K., Rae-Grant, J., Long, B., Adams, T., and S. - Jones, "Authenticated Received Chain (ARC) Protocol", June + Jones, "Authenticated Received Chain (ARC) Protocol", December 2016, . + protocol-01>. - [DMARC-INTEROP] + [RFC7960] Martin, F., Lear, E., Draegen, T., Zwicky, E., and K. Andersen, "Interoperability Issues Between DMARC and Indirect Email Flows", June 2016, . [ENHANCED-STATUS] "IANA SMTP Enhanced Status Codes", n.d., .