--- 1/draft-ietf-dmarc-arc-usage-02.txt 2017-12-19 07:14:50.248121849 -0800 +++ 2/draft-ietf-dmarc-arc-usage-03.txt 2017-12-19 07:14:50.696132611 -0800 @@ -1,119 +1,126 @@ DMARC Working Group S. Jones Internet-Draft DMARC.org -Intended status: Informational J. Rae-Grant -Expires: December 22, 2017 Google - T. Adams +Intended status: Informational K. Andersen +Expires: June 22, 2018 LinkedIn + J. Rae-Grant + Google + T. Adams, Ed. Paypal - K. Andersen, Ed. - LinkedIn - June 20, 2017 + December 19, 2017 Recommended Usage of the Authenticated Received Chain (ARC) - draft-ietf-dmarc-arc-usage-02 + draft-ietf-dmarc-arc-usage-03 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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/. + Drafts is at https://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 22, 2017. + This Internet-Draft will expire on June 22, 2018. Copyright Notice Copyright (c) 2017 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 + (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. How does ARC work? . . . . . . . . . . . . . . . . . . . . . 3 - 3. Guidance for Receivers/Validators . . . . . . . . . . . . . . 4 - 3.1. What is the significance of an intact ARC chain? . . . . 4 - 3.2. What exactly is an "intact" ARC chain? . . . . . . . . . 4 - 3.3. What is the significance of an invalid ("broken") ARC - chain? . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 3.4. What does the absence of an ARC chain in a message mean? 5 - 3.5. What reasonable conclusions can you draw based upon - seeing lots of mail with ARC chains? . . . . . . . . . . 5 - 3.6. What if none of the intermediaries have been seen - previously? . . . . . . . . . . . . . . . . . . . . . . . 6 - 3.7. What about ARC chains where some intermediaries are known - and others are not? . . . . . . . . . . . . . . . . . . . 6 - 3.8. What should message handlers do when they detect - malicious content in messages where ARC is present? . . . 6 - 3.9. What feedback does a sender or domain owner get about ARC - when it is applied to their messages? . . . . . . . . . . 7 - 3.10. What prevents a malicious actor from removing the ARC + 3. Evaluating the Efficacy of the ARC Protocol . . . . . . . . . 4 + 3.1. Success Consideration . . . . . . . . . . . . . . . . . . 4 + 3.2. Failure Considerations . . . . . . . . . . . . . . . . . 5 + 3.3. Open Questions . . . . . . . . . . . . . . . . . . . . . 5 + 3.3.1. Value of the ARC-Seal (AS) Header . . . . . . . . . . 5 + 3.3.2. DNS Overhead . . . . . . . . . . . . . . . . . . . . 5 + 3.3.3. Distinguishing Valuable from Worthless Trace + Information . . . . . . . . . . . . . . . . . . . . . 5 + 4. Guidance for Receivers/Validators . . . . . . . . . . . . . . 6 + 4.1. What is the significance of an intact ARC chain? . . . . 6 + 4.2. What exactly is an "intact" ARC chain? . . . . . . . . . 6 + 4.3. What is the significance of an invalid ("broken") ARC + chain? . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 4.4. What does the absence of an ARC chain in a message mean? 7 + 4.5. What reasonable conclusions can you draw based upon + seeing lots of mail with ARC chains? . . . . . . . . . . 8 + 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 - ARC chain? . . . . . . . . . . . . . . . . . . . . . . . 7 - 4. Guidance for Intermediaries . . . . . . . . . . . . . . . . . 8 - 4.1. What is an Intermediary under ARC? . . . . . . . . . . . 8 - 4.2. What are the minimum requirements for an ARC - Intermediary? . . . . . . . . . . . . . . . . . . . . . . 8 - 4.2.1. More specifically a participating ARC intermediary - must do the following: . . . . . . . . . . . . . . . 8 - 4.3. Should every MTA be an ARC participant? . . . . . . . . . 8 - 4.4. What should an intermediary do in the case of an invalid - or "broken" ARC chain? . . . . . . . . . . . . . . . . . 9 - 4.5. What should I do in the case where there is no ARC chain - present in a message? . . . . . . . . . . . . . . . . . . 9 - 4.6. How could ARC affect my reputation as an intermediary? . 9 - 4.7. What can I do to influence my reputation as an - intermediary? . . . . . . . . . . . . . . . . . . . . . . 9 - 5. Guidance for Originators . . . . . . . . . . . . . . . . . . 10 - 5.1. Where can I find out more information? . . . . . . . . . 10 - 5.2. How/where can I test interoperabililty for my - implementation? . . . . . . . . . . . . . . . . . . . . . 10 - - 5.3. How can ARC impact my email? . . . . . . . . . . . . . . 10 - 5.4. How can ARC impact my reputation as a message sender? . . 10 - 5.5. Can I tell intermediaries not to use ARC? . . . . . . . . 11 - 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 6.1. Normative References . . . . . . . . . . . . . . . . . . 11 - 6.2. Informative References . . . . . . . . . . . . . . . . . 11 - 6.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - Appendix A. GLOSSARY . . . . . . . . . . . . . . . . . . . . . . 12 - Appendix B. References . . . . . . . . . . . . . . . . . . . . . 15 - Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 15 - Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 15 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 + ARC chain? . . . . . . . . . . . . . . . . . . . . . . . 9 + 5. Guidance for Intermediaries . . . . . . . . . . . . . . . . . 10 + 5.1. What is an Intermediary under ARC? . . . . . . . . . . . 10 + 5.2. What are the minimum requirements for an ARC + Intermediary? . . . . . . . . . . . . . . . . . . . . . . 10 + 5.2.1. More specifically a participating ARC intermediary + must do the following: . . . . . . . . . . . . . . . 10 + 5.3. Should every MTA be an ARC participant? . . . . . . . . . 11 + 5.4. What should an intermediary do in the case of an invalid + or "broken" ARC chain? . . . . . . . . . . . . . . . . . 11 + 5.5. What should I do in the case where there is no ARC chain + present in a message? . . . . . . . . . . . . . . . . . . 11 + 5.6. How could ARC affect my reputation as an intermediary? . 11 + 5.7. What can I do to influence my reputation as an + intermediary? . . . . . . . . . . . . . . . . . . . . . . 12 + 6. Guidance for Originators . . . . . . . . . . . . . . . . . . 12 + 6.1. Where can I find out more information? . . . . . . . . . 12 + 6.2. How/where can I test interoperabililty for my + implementation? . . . . . . . . . . . . . . . . . . . . . 12 + 6.3. How can ARC impact my email? . . . . . . . . . . . . . . 12 + 6.4. How can ARC impact my reputation as a message sender? . . 13 + 6.5. Can I tell intermediaries not to use ARC? . . . . . . . . 13 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 + 7.2. Informative References . . . . . . . . . . . . . . . . . 14 + 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + Appendix A. GLOSSARY . . . . . . . . . . . . . . . . . . . . . . 14 + Appendix B. References . . . . . . . . . . . . . . . . . . . . . 17 + Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 17 + Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 17 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction [ARC] is intended to be used primarily by intermediaries, or message handlers - those parties who may forward or resend messages, with or without alterations, such that they will no longer pass the SPF, DKIM, and/or [RFC7489] authentication mechanisms. In such cases ARC may provide the final message recipient with useful information about the original sender. @@ -153,32 +160,124 @@ When the message reaches the final receiving system, the SPF and DKIM results will not satisfy the DMARC policy for the message author's domain. However if the receiving system implements ARC then it can check for and validate an ARC chain and verify that the contents of the ARC-Authentication-Results header field were conveyed intact from the mailing list operator. At that point the receiving system might choose to use those authentication results in the decision of whether or not to deliver the message, even though it failed to pass the 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 as observed by the first ARC participant. In cases where the message no longer produces passing results for DKIM, SPF, or DMARC but an intact ARC chain is present, the message receiver may choose to use the contents of the ARC-Authentication-Results header field in 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 messages where one or more non-participating ADMDs handled a message before, after, or in between participating ADMDs. An intact ARC chain is one where the ARC header fields that are present can be validated, and in particular the ARC-Message-Signature header field from the last ARC participant can still be validated. This shows that, whether another ADMD handled the message after the last ARC participant or not, the portions of the message covered by @@ -199,121 +298,121 @@ 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 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? +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 ARC-Seal header fields cannot be verified. For example the remote server delivering the message to the local ADMD is not reflected in any ARC header fields, perhaps because they have not implemented ARC, but they modified the message such that ARC and DKIM signatures already in the message were invalidated. In such cases the ARC-Authentication-Results header field should not 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? +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 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 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 +4.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 validated ARC information and therefore could be considered as validly 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 policy assertion for the domain authentication evaluation, depending on the ARC-Authentication-Results header field value. Normal content 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 reputation system. ARC conveys the results of other authentication mechanisms such that the participating message handlers can be positively identified. Final message recipients may or may not choose to examine these results when messages fail other authentication checks. They are more likely to override, say, a failing DMARC result in the presence of an intact ARC chain where the participating ARC message handlers have been observed to not convey "bad" content in the past, and the initial ARC participant indicates 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? Validators may choose to build reputation models for ARC message handlers they have observed. Generally speaking it is more feasible to accrue positive reputation to intermediaries when they consistently send messages that are evaluated positively in terms of content and ARC chains. When messages are received with ARC chains that are not intact, it is very difficult identify which intermediaries may have manipulated the message or injected bad 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? Message handlers should do what they normally do when they detect malicious content in a message - hopefully that means quarantining or discarding the message. ARC information should never make malicious content acceptable. In such cases it is difficult to determine where the malicious content may have been injected. What ARC can do in such cases is verify that a given intermediary or message handler did in fact handle the message as indicated in the header fields. In such cases a message recipient who maintains a reputation system about email senders may wish to incorporate this information as an additional factor in the score for the intermediaries and sender in question. However reputation systems are very complex, and usually unique to those organizations operating them, and therefore beyond the scope of 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? 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 +4.10. What prevents a malicious actor from removing the ARC header 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 @@ -327,228 +426,233 @@ 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, but with ARC that 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 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, alumni or professional email address providers that forward messages 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 message it receives, if one is present. It then attaches its own ARC seal and signature, including an indication if the chain failed to 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: 1. Validate that the ARC chain, if one is already present in the message, is intact and well-formed. 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 to the ARC specification. 5. Generate a new ARC Seal and add it to the message according to 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. When a message is first received by an ADMD, the traditional authentication results should be captured and preserved - this could be the common case of creating an Authentication-Results header 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 ARC chain - before sending the message outside of the ADMD. Some organizations may operate multiple ADMDs, with more or less independence between them. While they should make a determination based on their specific circumstances, it may be useful and 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? In general terms, a participating ARC intermediary will note that an 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 invalid should have no impact on whether and how the message is 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? A participating ARC intermediary receiving a message with no ARC chain, and which will be delivered outside its ADMD, should start an ARC chain according to the ARC specification. This will include capturing the normal email authentication results for the intermediary (SPF, DKIM, DMARC, etc), which will be conveyed as part 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 behavioral profile of various message handlers and intermediaries. 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 good content may provide a positive signal for the intermediaries that handled it, while messages with bad content may provide a negative signal for the those intermediaries. Intact and valid ARC elements may amplify or attenuate such signals, depending on the circumstances. Reputation systems are complex and usually specific to a given message receiver, and a meaningful discussion of such a broad topic 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 message that includes your identity as an intermediary, even though you never handled the message. It is possible that an intermediary implementing ARC on all traffic it handles might receive some reputational benefit by making it easier to detect when their involvement in conveying bad traffic has been "forged." + As mentioned previously reputation systems are very complex and usually specific to a given message receiver, and a meaningful discussion of such a broad topic is beyond the scope of this 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 [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? +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 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 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 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? +6.4. How can ARC impact my reputation as a message sender? Message receivers often operate reputation systems, which build a behavioral profile of various message senders (and perhaps intermediaries). 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 good content may provide a positive signal for the sending domain and the intermediaries that handled it, while messages with bad content may provide a negative signal for the sending domain and the intermediaries that handled it. Intact and valid ARC elements may amplify or attenuate such signals, depending on the circumstances. Reputation systems are complex and usually specific to a given message receiver, and a meaningful discussion of such a broad topic 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 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, DOI 10.17487/RFC5321, October 2008, - . + . [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, - . + . [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, DOI 10.17487/RFC5598, July 2009, - . + . + + [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and + Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377, + September 2011, . [RFC7601] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 7601, DOI 10.17487/RFC7601, August 2015, - . + . -6.2. Informative References +7.2. Informative References - [ARC] Andersen, K., Rae-Grant, J., Long, B., Adams, T., and S. - Jones, "Authenticated Received Chain (ARC) Protocol", June - 2017, . + [ARC] Andersen, K., Rae-Grant, J., Long, B., and S. Jones, + "Authenticated Received Chain (ARC) Protocol", December + 2017, . [ENHANCED-STATUS] "IANA SMTP Enhanced Status Codes", n.d., . [OAR] Chew, M. and M. Kucherawy, "Original-Authentication- Results Header Field", February 2012, - . + . [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, - . + . [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, - . + . -6.3. URIs +7.3. URIs [1] mailto:arc-discuss@dmarc.org Appendix A. GLOSSARY ADMD Administrative Management Domain as used in [RFC5598] and similar references refers to a single entity operating one or more computers within one or more domain names under said entity's control. One example might be a small company with a single server, handling email for that company's domain. Another example @@ -690,28 +795,27 @@ Please address all comments, discussions, and questions to the dmarc working group at [https://datatracker.ietf.org/wg/dmarc]. Authors' Addresses Steven Jones DMARC.org Email: smj@crash.com + Kurt Andersen + LinkedIn + 2029 Stierlin Ct. + Mountain View, California 94043 + USA + + Email: kurta@linkedin.com John Rae-Grant Google Email: johnrg@google.com - J. Trent Adams + J. Trent Adams (editor) Paypal Email: trent.adams@paypal.com - - Kurt Andersen (editor) - LinkedIn - 2029 Stierlin Ct. - Mountain View, California 94043 - USA - - Email: kurta@linkedin.com