RFC7960], Section 3.2.3. Mailing list services can implement ARC to convey the authentication assessment of posted messages sent to the list's subscriber base. The ADMDs of the mailing list subscribers can then use the Authenticated Received Chain to determine the authentication assessment of the original message before mailing list handling.
RFC7960]. Authenticated Received Chains allow DMARC processors to consider authentication assessments provided by other ADMDs. As a matter of local policy, a DMARC processor MAY choose to accept the authentication assessments provided by an Authenticated Received Chain when determining if a message is DMARC compliant. When an Authenticated Received Chain is used to determine message disposition, the DMARC processor can communicate this local policy decision to Domain Owners as described in Section 7.2.2.
RFC7489], Appendix C) containing a list of data discovered during ARC validation, which at a minimum includes: o the Chain Validation Status, o the domain and selector for each AS, and o the originating IP address from the first ARC Set. EXAMPLE: <policy_evaluated> <disposition>none</disposition> <dkim>fail</dkim> <spf>fail</spf> <reason> <type>local_policy</type> <comment>arc=pass as.d=d2.example as.s=s2 as.d=d1.example as.s=s3 remote-ip=2001:DB8::1A</comment> </reason> </policy_evaluated> In the example DMARC XML reporting fragment above, data relating to specific validated ARC Sets are enumerated using array syntax (e.g., "as" means an AS header field with an instance value of 2). d2.example is the sealing domain for ARC Set #2 (i=2), and d1.example is the sealing domain for ARC Set #1 (i=1). Depending on the reporting practices of intermediate message handlers, Domain Owners may receive multiple DMARC reports for a single message. Receivers of DMARC reports should be aware of this behavior and make the necessary accommodations.
RFC6376] and [RFC8601] apply directly to this specification. As with other domain-based authentication technologies (such as SPF, DKIM, and DMARC), ARC makes no claims about the semantic content of messages. A received message with a validated ARC Chain provides evidence (at instance N) that: 1. the sealing domain (ARC-Seal[N] d=) emitted the message with this body, 2. the authentication assessment reported in the ARC-Authentication- Results was determined upon receipt of the corresponding message at the sealing domain, and 3. the preceding ARC Chain (1..N-1) (with the validation status as reported in the cv field) existed on the message that was received and assessed.
2. DKIM only performs one DNS query per signature, while ARC can introduce many (per chain). Absent caching, slow DNS responses can cause SMTP timeouts and backlogged delivery queues on validating systems. This could be exploited as a DoS attack. RFC6376], Section 8.6 is potentially amplified by ARC's chained statuses. In an ARC replay attack, a malicious actor would take an intact and passing ARC Chain and resend it to many recipients without making any modifications that invalidate the latest AMS or AS. The impact to a receiver would be more DNS lookups and signature evaluations. The scope of this attack can be limited by caching DNS queries and following the same signing scope guidance from [RFC6376], Section 5.4.1.
Section 10.1), new ptypes and properties (Section 10.2), three new headers fields (Section 10.3), and a new enumerated status code (Section 10.4). Section 4.4 Status: active RFC8601]: o Method: arc Definition: RFC 8617, Section 6 ptype: smtp Property: remote-ip Value: IP address (v4 or v6) of originating SMTP connection Status: active Version: 1 o Method: arc Definition: RFC 8617, Section 6 ptype: header Property: oldest-pass Value: The instance id of the oldest validating AMS or 0 if they all pass (see Section 5.2) Status: active Version: 1
RFC 6376 o Header field name: ARC-Message-Signature Applicable protocol: mail Status: experimental Author/Change controller: IETF Specification document(s): RFC 8617 Related information: RFC 6376 o Header field name: ARC-Authentication-Results Applicable protocol: mail Status: experimental Author/Change controller: IETF Specification document(s): RFC 8617 Related information: RFC 8601
RFC6377] and [RFC7960]. As the ARC protocol is implemented by Internet Mail Handlers over time, the following should be evaluated in order to determine the success of the protocol in accomplishing the intended benefits. Section 9). If unforeseen vectors are enabled by ARC, this protocol will be a failure. Note that the weaknesses inherent in the mail protocols ARC is built upon (such as DKIM replay attacks and other known issues) are not new vectors that can be attributed to this specification.
Section 9.2), it is unclear how much overhead will truly be added. This is similar to some of the initial processing and query load concerns that 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 Authenticated Received Chains along with the DNS impact of processing Authenticated Received Chains. An effective operational maximum will have to be developed through deployment experience in the field.
Further, 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. At this point, however, 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 intentionally 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. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>. [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-editor.org/info/rfc5322>. [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, DOI 10.17487/RFC5598, July 2009, <https://www.rfc-editor.org/info/rfc5598>. [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, <https://www.rfc-editor.org/info/rfc6376>. [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377, September 2011, <https://www.rfc-editor.org/info/rfc6377>.
[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, DOI 10.17487/RFC6532, February 2012, <https://www.rfc-editor.org/info/rfc6532>. [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, <https://www.rfc-editor.org/info/rfc7208>. [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, DOI 10.17487/RFC7405, December 2014, <https://www.rfc-editor.org/info/rfc7405>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [RFC8601] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 8601, DOI 10.17487/RFC8601, May 2019, <https://www.rfc-editor.org/info/rfc8601>. [RFC8616] Levine, J., "Email Authentication for Internationalized Mail", RFC 8616, DOI 10.17487/RFC8616, June 2019, <https://www.rfc-editor.org/info/rfc8616>. [ARC-MULTI] Andersen, K., Blank, S., Ed., and J. Levine, Ed., "Using Multiple Signing Algorithms with the ARC (Authenticated Received Chain) Protocol", Work in Progress, draft-ietf- dmarc-arc-multi-03, March 2019. [ARC-USAGE] Jones, S., Ed. and K. Andersen, "Recommended Usage of the Authenticated Received Chain (ARC)", Work in Progress, draft-ietf-dmarc-arc-usage-07, April 2019. [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, <https://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, <https://www.rfc-editor.org/info/rfc7960>.
9WSqI9s9DfyKDfWg== ARC-Authentication-Results: i=2; gmail.example; spf=fail firstname.lastname@example.org; dkim=fail (512-bit key) email@example.com; dmarc=fail; arc=pass (as.1.lists.example.org=pass, ams.1.lists.example.org=pass) ARC-Seal: i=1; a=rsa-sha256; cv=none; d=lists.example.org; s=dk-lists; t=12345; b=TlCCKzgk3TrAa+G77gYYO8Fxk4q/Ml0biqduZJeOYh6+0zhwQ8u/ lHxLi21pxu347isLSuNtvIagIvAQna9a5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d= lists.example.org; h=message-id:date:from:to:subject; s= dk-lists; t=12345; bh=KWSe46TZKCcDbH4klJPo+tjk5LWJnVRlP5pvjXFZYL Q=; b=DsoD3n3hiwlrN1ma8IZQFgZx8EDO7Wah3hUjIEsYKuShRKYB4LwGUiKD5Y yHgcIwGHhSc/4+ewYqHMWDnuFxiQ== ARC-Authentication-Results: i=1; lists.example.org; spf=pass firstname.lastname@example.org; dkim=pass (512-bit key) email@example.com; dmarc=pass DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=d1.example; h= message-id:date:from:to:subject; s=origin2015; bh=bIxxaeIQvmOBdT AitYfSNFgzPP4=; b=qKjd5fYibKXWWIcMKCgRYuo1vJ2fD+IAQPjX+uamXIGY2Q 0HjQ+Lq3/yHzG3JHJp6780/nKQPOWt2UDJQrJkEA== Message-ID: <54B84785.firstname.lastname@example.org> Date: Thu, 14 Jan 2015 15:00:01 -0800 From: John Q Doe <email@example.com> To: firstname.lastname@example.org Subject: [List 2] Example 1 Hey gang, This is a test message. --J.