--- 1/draft-ietf-dmarc-arc-usage-08.txt 2020-05-07 01:13:27.034420713 -0700 +++ 2/draft-ietf-dmarc-arc-usage-09.txt 2020-05-07 01:13:27.198424887 -0700 @@ -1,23 +1,23 @@ DMARC Working Group S. Jones, Ed. Internet-Draft DMARC.org Intended status: Informational K. Andersen -Expires: April 24, 2020 LinkedIn - October 22, 2019 +Expires: November 7, 2020 LinkedIn + May 06, 2020 Recommended Usage of the Authenticated Received Chain (ARC) - draft-ietf-dmarc-arc-usage-08 + draft-ietf-dmarc-arc-usage-09 Abstract - The Authentication Received Chain (ARC) provides an authenticated + The Authenticated Received Chain (ARC) provides an authenticated "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's authentication assessment was at each step in the handling. But the specification does not indicate how the entities 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 @@ -27,111 +27,115 @@ 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 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 April 24, 2020. + This Internet-Draft will expire on November 7, 2020. Copyright Notice - Copyright (c) 2019 IETF Trust and the persons identified as the + Copyright (c) 2020 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 (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. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. How does ARC work? . . . . . . . . . . . . . . . . . . . 3 2.2. What new headers are introduced by ARC? . . . . . . . . . 5 2.3. Does ARC support Internationalized Email (EAI)? . . . . . 5 2.4. Does ARC support multiple digital signature algorithms? . 5 - 3. Guidance for Receivers/Validators . . . . . . . . . . . . . . 5 - 3.1. What is the significance of an intact ARC chain? . . . . 5 + 3. Guidance for Receivers/Validators . . . . . . . . . . . . . . 6 + 3.1. What is the significance of an intact ARC chain? . . . . 6 3.2. What exactly is an "intact" ARC chain? . . . . . . . . . 6 3.3. What is the significance of an invalid ("broken") ARC chain? . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.4. What error code(s) should be returned if an invalid ARC chain is detected during an SMTP transaction? . . . . . . 7 3.5. What does the absence of an ARC chain in a message mean? 7 3.6. What reasonable conclusions can you draw based upon seeing lots of mail with ARC chains? . . . . . . . . . . 7 3.7. What if none of the intermediaries have been seen previously? . . . . . . . . . . . . . . . . . . . . . . . 8 3.8. What about ARC chains where some intermediaries are known and others are not? . . . . . . . . . . . . . . . . . . . 8 3.9. What should message handlers do when they detect malicious content in messages where ARC is present? . . . 8 3.10. What feedback does a sender or domain owner get about ARC when it is applied to their messages? . . . . . . . . . . 9 3.11. What prevents a malicious actor from removing the ARC header fields, altering the content, and creating a new ARC chain? . . . . . . . . . . . . . . . . . . . . . . . 9 - 4. Guidance for Intermediaries . . . . . . . . . . . . . . . . . 9 - 4.1. What is an Intermediary under ARC? . . . . . . . . . . . 9 + 3.12. What should an ARC Receiver/Validator do when multiple + digital signature algorithms are used in an ARC chain? . 10 + 4. Guidance for Intermediaries . . . . . . . . . . . . . . . . . 10 + 4.1. What is an Intermediary under ARC? . . . . . . . . . . . 10 4.2. What are the minimum requirements for an ARC Intermediary? . . . . . . . . . . . . . . . . . . . . . . 10 4.2.1. More specifically a participating ARC intermediary must do the following: . . . . . . . . . . . . . . . 10 4.3. Should every MTA be an ARC participant? . . . . . . . . . 10 4.4. What should an intermediary do in the case of an invalid - or "broken" ARC chain? . . . . . . . . . . . . . . . . . 10 + or "broken" ARC chain? . . . . . . . . . . . . . . . . . 11 4.5. What should I do in the case where there is no ARC chain present in a message? . . . . . . . . . . . . . . . . . . 11 4.6. How could ARC affect my reputation as an intermediary? . 11 4.7. What can I do to influence my reputation as an intermediary? . . . . . . . . . . . . . . . . . . . . . . 11 - - 5. Guidance for Originators . . . . . . . . . . . . . . . . . . 11 - 5.1. Where can I find out more information? . . . . . . . . . 11 + 4.8. How can an ARC Intermediary adopt a new digital signature + algorithm that other Intermediaries and Validators may + not support? . . . . . . . . . . . . . . . . . . . . . . 12 + 5. Guidance for Originators . . . . . . . . . . . . . . . . . . 12 + 5.1. Where can I find more information? . . . . . . . . . . . 12 5.2. How/where can I test interoperabililty for my implementation? . . . . . . . . . . . . . . . . . . . . . 12 5.3. How can ARC impact my email? . . . . . . . . . . . . . . 12 - 5.4. How can ARC impact my reputation as a message sender? . . 12 + 5.4. How can ARC impact my reputation as a message sender? . . 13 5.5. Can I tell intermediaries not to use ARC? . . . . . . . . 13 6. Considerations . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. IANA Considerations . . . . . . . . . . . . . . . . . . . 13 6.2. Security Considerations . . . . . . . . . . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 7.2. Informative References . . . . . . . . . . . . . . . . . 14 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 15 - Appendix A. Glossary . . . . . . . . . . . . . . . . . . . . . . 15 - Appendix B. References . . . . . . . . . . . . . . . . . . . . . 18 - Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 18 - Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 18 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 + Appendix A. Glossary . . . . . . . . . . . . . . . . . . . . . . 16 + Appendix B. References . . . . . . . . . . . . . . . . . . . . . 19 + Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 19 + Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 19 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction - [ARC] is intended to be used by Internet Mail Handlers who forward or - resend messages, with or without alterations, such that they will no - longer pass the SPF [RFC7208], DKIM [RFC6376], and/or DMARC [RFC7489] - mechanisms when evaluated by subsequent message handlers or the final - recipient. In such cases ARC may provide useful information about - the message before the forwarding and/or alterations took place, and - recipients may choose to use this information to influence delivery - decisions. + The Authenticated Received Chain (ARC) [RFC8617] is intended to be + used by Internet Mail Handlers who forward or resend messages, with + or without alterations, such that they will no longer pass the SPF + [RFC7208], DKIM [RFC6376], and/or DMARC [RFC7489] mechanisms when + evaluated by subsequent message handlers or the final recipient. In + such cases ARC may provide useful information about the message + before the forwarding and/or alterations took place, and recipients + may choose to use this information to influence delivery decisions. 2. Overview 2.1. How does ARC work? Consider a message sent to a mailing list. Assume that the message author's domain publishes an SPF record, signs messages with a DKIM signature that includes the RFC5322.Subject header and the message body, and publishes a DMARC policy of "p=reject". Finally, assume that the final recipient(s) of the message implement SPF, DKIM and @@ -193,49 +197,51 @@ 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. 2.2. What new headers are introduced by ARC? - The following new headers are defined in [ARC] Section 4.1, "ARC + The following new headers are defined in [RFC8617] Section 4.1, "ARC Header Fields": o ARC-Seal o ARC-Message-Signature o ARC-Athentication-Results Each time a message passes through an ARC Intermediary, an ARC Set consisting of these three headers will be attached to the message. - More information about ARC Sets can be found in [ARC] Section 4.2, - "ARC Set." The entire collection of ARC Sets in a message is - commonly referred to as the ARC Chain. + More information about ARC Sets can be found in [RFC8617] + Section 4.2, "ARC Set." The entire collection of ARC Sets in a + message is commonly referred to as the ARC Chain. 2.3. Does ARC support Internationalized Email (EAI)? Changes to support EAI are inherited from DKIM [RFC6376] as updated - by [draft-levine-eaiauth], and Authentication-Results as updated in - [I-D-7601bis]. For more details, please refer to [ARC] - Section 4.1.4, "Internationalized Email (EAI)." + by [RFC8616], and Authentication-Results as updated in [RFC8601]. + For more details, please refer to [RFC8617] Section 4.1.4, + "Internationalized Email (EAI)." 2.4. Does ARC support multiple digital signature algorithms? Originally ARC only supported a single signing algorithm, but the DCRUP working group https://datatracker.ietf.org/wg/dcrup/about [1] - is expanding the set of supported algorithms available to DKIM - [RFC6376] and derived protocols. [ARC-MULTI] is adapting this work - to extend [ARC] to support multiple algorithms. + expanded the set of supported algorithms available to DKIM [RFC6376] + and derived protocols. [RFC8463] is a standards track document that + adds the Edd25519-SHA256 signing algorithm to DKIM, and [ARC-MULTI] + is adapting this work to allow ARC to support multiple signing + algorithms. 3. Guidance for Receivers/Validators 3.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 first ARC-Authentication-Results header field in @@ -287,27 +293,27 @@ Email transit can produce broken signatures for a wide variety of benign reasons. This includes possibly breaking one or more ARC signatures. Therefore, receivers need to be wary of ascribing motive to such breakage, although patterns of common behaviour may provide some basis for adjusting local policy decisions. 3.4. What error code(s) should be returned if an invalid ARC chain is detected during an SMTP transaction? - According to [ARC] Section 5.2.2, a Validator MAY signal the breakage - during the SMTP transaction by returning the extended SMTP response - code 5.7.29 "ARC validation failure" and corresponding SMTP basic - response code. Since ARC failures are likely the be detected due to - other, underlying authentication failures, Validators may also choose - to return the more general 5.7.26 "Multiple authentication checks - failed instead of the ARC-specific code. + According to [RFC8617] Section 5.2.2, a Validator MAY signal the + breakage during the SMTP transaction by returning the extended SMTP + response code 5.7.29 "ARC validation failure" and corresponding SMTP + basic response code. Since ARC failures are likely the be detected + due to other, underlying authentication failures, Validators may also + choose to return the more general 5.7.26 "Multiple authentication + checks failed instead of the ARC-specific code. 3.5. 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. @@ -371,28 +377,28 @@ 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.10. 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. + ARC itself does not currently 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.11. 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 @@ -408,20 +414,28 @@ 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. +3.12. What should an ARC Receiver/Validator do when multiple digital + signature algorithms are used in an ARC chain? + + [ARC-MULTI] is adapting the output of the DCRUP working group + https://datatracker.ietf.org/wg/dcrup/about [2] for use in ARC. It + specifically covers how to create and validate ARC header sets and + chains that include mutliple signature algorithms. + 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, alumni or professional email address providers that forward messages such as universities or professional organizations, et cetera. @@ -430,27 +444,27 @@ 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 following: 1. Validate that the ARC chain, if one is already present in the - message, is intact and well-formed. ([ARC] Section 5.2, + message, is intact and well-formed. ([RFC8617] Section 5.2, "Validator Actions") 2. Record the ARC status in an Authentication-Results header - ([RFC7601]) + ([RFC8601]) - 3. Generate a new ARC set and add it to the message. ([ARC] + 3. Generate a new ARC set and add it to the message. ([RFC8617] Section 5.1, "Sealer Actions") 4.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 @@ -497,44 +511,53 @@ is beyond the scope of this document. 4.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. +4.8. How can an ARC Intermediary adopt a new digital signature + algorithm that other Intermediaries and Validators may not + support? + + [ARC-MULTI] is adapting the output of the DCRUP working group + https://datatracker.ietf.org/wg/dcrup/about [3] for use in ARC. It + specifically covers how to create and validate ARC header sets and + chains that include mutliple signature algorithms. + 5. Guidance for Originators -5.1. Where can I find out more information? +5.1. Where can I find more information? - Please visit the http://arc-spec.org [2] web site, or join the arc- + Please visit the http://arc-spec.org [4] web site, or join the arc- discuss mailing list at http://lists.dmarc.org/mailman/listinfo/arc- - discuss [3]. + discuss [5]. - To discuss the [ARC] specification itself, please join the DMARC - working group at https://datatracker.ietf.org/wg/dmarc [4]. + To discuss details of the [RFC8617] specification itself, especially + errata, please join the DMARC working group at + https://datatracker.ietf.org/wg/dmarc [6]. 5.2. How/where can I test interoperabililty for my implementation? There have been numerous interoperability tests during the - development of the [ARC] specification. These tests are usually - announced on both the arc-discuss mailing list at - http://lists.dmarc.org/mailman/listinfo/arc-discuss [5], and the - DMARC working group at https://datatracker/ietf.org/wg/dmarc [6]. + development of the ARC [RFC8617] specification. These tests are + usually announced on both the arc-discuss mailing list at + http://lists.dmarc.org/mailman/listinfo/arc-discuss [7], and the + DMARC working group at https://datatracker/ietf.org/wg/dmarc [8]. Join whichever body is most appropriate for you and/or your organization to receive future announcements. 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. @@ -593,160 +616,167 @@ . [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, . + [RFC8601] Kucherawy, M., "Message Header Field for Indicating + Message Authentication Status", RFC 8601, + DOI 10.17487/RFC8601, May 2019, + . - [RFC7601] Kucherawy, M., "Message Header Field for Indicating - Message Authentication Status", RFC 7601, - DOI 10.17487/RFC7601, August 2015, - . + [RFC8617] Andersen, K., Long, B., Ed., Blank, S., Ed., and M. + Kucherawy, Ed., "The Authenticated Received Chain (ARC) + Protocol", RFC 8617, DOI 10.17487/RFC8617, July 2019, + . 7.2. Informative References - [ARC] Andersen, K., Long, B., Blank, S., and M. Kucherawy, - "Authenticated Received Chain (ARC) Protocol", December - 2018, . - [ARC-MULTI] Andersen, K., Blank, S., and J. Levine, "Using Multiple - Signing Algorithms with ARC", June 2018, + Signing Algorithms with ARC", March 2019, . - - [draft-levine-eaiauth] - Levine, J., "E-mail Authentication for Internationalized - Mail", August 2018, . + 03>. [ENHANCED-STATUS] "IANA SMTP Enhanced Status Codes", n.d., . - [I-D-7601bis] - Kucherawy, M., "Message Header Field for Indicating - Message Authentication Status", February 2018, - . - [OAR] Chew, M. and M. Kucherawy, "Original-Authentication- Results Header Field", February 2012, . [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, . + [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and + Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377, + September 2011, . + [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, . [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, . + [RFC8301] Kitterman, S., "Cryptographic Algorithm and Key Usage + Update to DomainKeys Identified Mail (DKIM)", RFC 8301, + DOI 10.17487/RFC8301, January 2018, + . + + [RFC8463] Levine, J., "A New Cryptographic Signature Method for + DomainKeys Identified Mail (DKIM)", RFC 8463, + DOI 10.17487/RFC8463, September 2018, + . + + [RFC8616] Levine, J., "Email Authentication for Internationalized + Mail", RFC 8616, DOI 10.17487/RFC8616, June 2019, + . + 7.3. URIs [1] https://datatracker.ietf.org/wg/dcrup/about - [2] http://arc-spec.org + [2] https://datatracker.ietf.org/wg/dcrup/about - [3] http://lists.dmarc.org/mailman/listinfo/arc-discuss + [3] https://datatracker.ietf.org/wg/dcrup/about - [4] https://datatracker.ietf.org/wg/dmarc + [4] http://arc-spec.org [5] http://lists.dmarc.org/mailman/listinfo/arc-discuss - [6] https://datatracker/ietf.org/wg/dmarc + [6] https://datatracker.ietf.org/wg/dmarc - [7] mailto:arc-discuss@dmarc.org + [7] http://lists.dmarc.org/mailman/listinfo/arc-discuss - [8] https://datatracker.ietf.org/wg/dmarc + [8] https://datatracker/ietf.org/wg/dmarc - [9] https://arc-spec.org + [9] mailto:arc-discuss@dmarc.org - [10] mailto:arc-discuss@dmarc.org + [10] https://datatracker.ietf.org/wg/dmarc - [11] http://lists.dmarc.org/mailman/listinfo/arc-discuss + [11] https://arc-spec.org + + [12] mailto:arc-discuss@dmarc.org + + [13] http://lists.dmarc.org/mailman/listinfo/arc-discuss 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 might be a large university, operating many servers that fulfill different roles, all handling email for several different domains representing parts of the university. - ARC ARC is an acronym: Authentication Results Chain - see also [ARC] + ARC ARC is an acronym: Authenticated Received Chain - see [RFC8617] ARC-Seal An [RFC5322] message header field formed in compliance with the ARC specification. It includes certain content from all prior ARC participants, if there are any. ARC-Message-Signature (also abbreviated as "AMS") An [RFC5322] - message header field formed in compliance with the [ARC] + message header field formed in compliance with the [RFC8617] specification. It includes certain content about the message as it was received and manipulated by the intermediary who inserted it. ARC-Authentication-Results (also abbreviated as "AAR") An [RFC5322] - message header field formed in compliance with the [ARC] + message header field formed in compliance with the [RFC8617] specification. It includes certain content about the message as it was received by the intermediary. - Authentication Results Chain (ARC) A system that allows a Message + Authenticated Received Chain (ARC) A system that allows a Message Receiver to identify Intermediaries or Message Handlers who have conveyed a particular message. For more information see the - Abstract of this document, or refer to [ARC]. + Abstract of this document, or refer to [RFC8617]. Domain Naming System Block List (DNSBL) This is a system widely used in email filtering services whereby information about the past activity of a set of hosts or domains indicates that messages should not be accepted from them, or at least should be subject to greater scrutiny before being accepted. Common examples would be SpamCop, Spamhaus.org, SORBS, etc. Email Service Provider (ESP) An Email Service Provider is typically a vendor or partner firm that sends mail on behalf of another company. They may use email addresses in Internet domains belonging to the client or partner firm in various [RFC5321] fields or [RFC5322] message header fields of the messages they send on their behalf. - Intermediary In the context of [ARC], an Intermediary is typically - an Administrative Management Domain (per [RFC5598]) that is - receiving a message, potentially manipulating or altering it, and - then passing it on to another ADMD for delivery. Also see + Intermediary In the context of [RFC8617], an Intermediary is + typically an Administrative Management Domain (per [RFC5598]) that + is receiving a message, potentially manipulating or altering it, + and then passing it on to another ADMD for delivery. Also see [RFC7960] for more information and discussion. Common examples of Intermediaries are mailing lists, alumni or professional email address providers like universities or professional organizations, et cetera. Mail/Message Transfer Agent (MTA) This refers to software that sends and receives email messsages across a network with other MTAs. Often run on dedicated servers, common examples are Exim, Microsoft Exchange, Postfix, and Sendmail. @@ -815,44 +845,45 @@ within the message and various types of content within the message body. Link: [RFC5322] Validator A Message Receiver that attempts to validate the ARC chain in a message. Appendix B. References Appendix C. Acknowledgements - This draft is based on the work of OAR-Dev Group. + This document is based on the work of OAR-Dev Group. The authors thank the entire OAR-Dev group for the ongoing help, innumerable diagrams and discussions from all the participants, especially: Alex Brotman, Brandon Long, Dave Crocker, Elizabeth 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, Terry Zink, Tim Draegen. This document was influenced by questions posed in the arc- - discuss@dmarc.org [7] mailing list, and the authors thank all the + discuss@dmarc.org [9] mailing list, and the authors thank all the list participants for their input. Appendix D. Comments and Feedback Please address all comments, discussions, and questions about this - document, or about [ARC] itself, to the dmarc working group at - https://datatracker.ietf.org/wg/dmarc [8]. + document, or about [RFC8617] itself, to the DMARC Working Group at + https://datatracker.ietf.org/wg/dmarc [10]. Readers looking for general information about ARC may refer to the - website https://arc-spec.org [9], or to the arc-discuss@dmarc.org - [10] mailing list at http://lists.dmarc.org/mailman/listinfo/arc- - discuss [11]. + website https://arc-spec.org [11], or to the arc-discuss@dmarc.org + [12] mailing list at http://lists.dmarc.org/mailman/listinfo/arc- + discuss [13]. Authors' Addresses + Steven M Jones (editor) DMARC.org 2419 McGee Avenue Berkeley, California 94703 USA Email: smj@dmarc.org Kurt Andersen LinkedIn