idnits 2.17.1 draft-ietf-dmarc-arc-protocol-21.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 15 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 7, 2018) is 1968 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '2' on line 1658 -- Looks like a reference, but probably isn't: '1' on line 1656 -- Looks like a reference, but probably isn't: '3' on line 1660 -- Looks like a reference, but probably isn't: '4' on line 1662 -- Looks like a reference, but probably isn't: '5' on line 1664 -- Looks like a reference, but probably isn't: '6' on line 1796 -- Looks like a reference, but probably isn't: '7' on line 1797 -- Looks like a reference, but probably isn't: '8' on line 1798 -- Looks like a reference, but probably isn't: '9' on line 1801 == Outdated reference: A later version (-23) exists of draft-ietf-dmarc-arc-protocol-05 == Outdated reference: A later version (-23) exists of draft-ietf-dmarc-arc-protocol-10 -- Duplicate reference: draft-ietf-dmarc-arc-protocol, mentioned in 'ARC-DRAFT-10', was also mentioned in 'ARC-DRAFT-05'. == Outdated reference: A later version (-23) exists of draft-ietf-dmarc-arc-protocol-13 -- Duplicate reference: draft-ietf-dmarc-arc-protocol, mentioned in 'ARC-DRAFT-13', was also mentioned in 'ARC-DRAFT-10'. == Outdated reference: A later version (-23) exists of draft-ietf-dmarc-arc-protocol-14 -- Duplicate reference: draft-ietf-dmarc-arc-protocol, mentioned in 'ARC-DRAFT-14', was also mentioned in 'ARC-DRAFT-13'. == Outdated reference: A later version (-03) exists of draft-ietf-dmarc-arc-multi-02 == Outdated reference: A later version (-09) exists of draft-ietf-dmarc-arc-usage-05 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMARC Working Group K. Andersen 3 Internet-Draft LinkedIn 4 Intended status: Experimental B. Long, Ed. 5 Expires: May 11, 2019 Google 6 S. Blank, Ed. 7 Valimail 8 M. Kucherawy, Ed. 9 TDP 10 November 7, 2018 12 Authenticated Received Chain (ARC) Protocol 13 draft-ietf-dmarc-arc-protocol-21 15 Abstract 17 The Authenticated Received Chain (ARC) protocol provides an 18 authenticated "chain of custody" for a message, allowing each entity 19 that handles the message to see what entities handled it before, and 20 to see what the message's authentication assessment was at each step 21 in the handling. 23 ARC allows Internet Mail Handlers to attach assertions of message 24 authentication assessment to individual messages. As messages 25 traverse ARC-enabled Internet Mail Handlers, additional ARC 26 assertions can be attached to messages to form ordered sets of ARC 27 assertions that represent the authentication assessment at each step 28 of message handling paths. 30 ARC-enabled Internet Mail Handlers can process sets of ARC assertions 31 to inform message disposition decisions, to identify Internet Mail 32 Handlers that might break existing authentication mechanisms, and to 33 convey original authentication assessments across trust boundaries. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on May 11, 2019. 51 Copyright Notice 53 Copyright (c) 2018 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. General Concepts . . . . . . . . . . . . . . . . . . . . . . 5 70 2.1. Evidence . . . . . . . . . . . . . . . . . . . . . . . . 5 71 2.2. Custody . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 2.3. Chain of Custody . . . . . . . . . . . . . . . . . . . . 5 73 2.4. Validation of Chain of Custody . . . . . . . . . . . . . 5 74 3. Terminology and Definitions . . . . . . . . . . . . . . . . . 6 75 3.1. ARC Set . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 3.2. Authenticated Received Chain (ARC) . . . . . . . . . . . 7 77 3.3. Internet Mail Handlers / Intermediaries . . . . . . . . . 7 78 3.4. Authentication Assessment . . . . . . . . . . . . . . . . 7 79 3.5. Signing vs Sealing . . . . . . . . . . . . . . . . . . . 7 80 3.6. Sealer . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 3.7. Validator . . . . . . . . . . . . . . . . . . . . . . . . 8 82 3.8. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . 8 83 3.9. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . 8 84 4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 8 85 4.1. ARC Header Fields . . . . . . . . . . . . . . . . . . . . 8 86 4.1.1. ARC-Authentication-Results (AAR) . . . . . . . . . . 9 87 4.1.2. ARC-Message-Signature (AMS) . . . . . . . . . . . . . 9 88 4.1.3. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . 10 89 4.1.4. Internationalized Email (EAI) . . . . . . . . . . . . 11 90 4.2. ARC Set . . . . . . . . . . . . . . . . . . . . . . . . . 12 91 4.2.1. Instance Tags . . . . . . . . . . . . . . . . . . . . 12 92 4.3. Authenticated Received Chain . . . . . . . . . . . . . . 12 93 4.4. Chain Validation Status . . . . . . . . . . . . . . . . . 13 94 5. Protocol Actions . . . . . . . . . . . . . . . . . . . . . . 13 95 5.1. Sealer Actions . . . . . . . . . . . . . . . . . . . . . 14 96 5.1.1. Header Fields To Include In ARC-Seal Signatures . . . 15 97 5.1.2. Marking and Sealing "cv=fail" (Invalid) Chains . . . 15 98 5.1.3. Only One Authenticated Received Chain Per Message . . 15 99 5.1.4. Broad Ability to Seal . . . . . . . . . . . . . . . . 16 100 5.1.5. Sealing is Always Safe . . . . . . . . . . . . . . . 16 101 5.2. Validator Actions . . . . . . . . . . . . . . . . . . . . 16 102 5.2.1. All Failures Are Permanent . . . . . . . . . . . . . 18 103 5.2.2. Responding to ARC Validation Failures During the SMTP 104 Transaction . . . . . . . . . . . . . . . . . . . . . 18 105 6. Communication of Validation Results . . . . . . . . . . . . . 18 106 7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 19 107 7.1. Communicate Authentication Assessment Across Trust 108 Boundaries . . . . . . . . . . . . . . . . . . . . . . . 19 109 7.1.1. Message Scanning Services . . . . . . . . . . . . . . 19 110 7.1.2. Multi-tier MTA Processing . . . . . . . . . . . . . . 19 111 7.1.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 20 112 7.2. Inform Message Disposition Decisions . . . . . . . . . . 20 113 7.2.1. DMARC Local Policy Overrides . . . . . . . . . . . . 20 114 7.2.2. DMARC Reporting . . . . . . . . . . . . . . . . . . . 21 115 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 116 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 117 9.1. Increased Header Field Size . . . . . . . . . . . . . . . 22 118 9.2. DNS Operations . . . . . . . . . . . . . . . . . . . . . 22 119 9.3. Message Content Suspicion . . . . . . . . . . . . . . . . 23 120 9.4. Message Sealer Suspicion . . . . . . . . . . . . . . . . 23 121 9.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 23 122 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 123 10.1. Email Authentication Results Names Registry Update . . . 24 124 10.2. Email Authentication Methods Registry Update . . . . . . 24 125 10.3. Definitions of the ARC header fields . . . . . . . . . . 24 126 10.4. New Enhanced Status Code - ARC Validation . . . . . . . 25 127 11. Experimental Considerations . . . . . . . . . . . . . . . . . 25 128 11.1. Success Consideration . . . . . . . . . . . . . . . . . 25 129 11.2. Failure Considerations . . . . . . . . . . . . . . . . . 26 130 11.3. Open Questions . . . . . . . . . . . . . . . . . . . . . 26 131 11.3.1. Value of the ARC-Seal (AS) Header Field . . . . . . 26 132 11.3.2. Usage and/or signals from multiple selectors and/or 133 domains in ARC sets . . . . . . . . . . . . . . . . 26 134 11.3.3. DNS Overhead . . . . . . . . . . . . . . . . . . . . 26 135 11.3.4. What Trace Information is Valuable . . . . . . . . . 27 136 12. Implementation Status . . . . . . . . . . . . . . . . . . . . 27 137 12.1. GMail test reflector and incoming validation . . . . . . 28 138 12.2. AOL test reflector and internal tagging . . . . . . . . 28 139 12.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 29 140 12.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . 29 141 12.5. Mailman 3.x patch . . . . . . . . . . . . . . . . . . . 29 142 12.6. Copernica/MailerQ web-based validation . . . . . . . . . 30 143 12.7. Rspamd . . . . . . . . . . . . . . . . . . . . . . . . . 30 144 12.8. PERL MAIL::DKIM module . . . . . . . . . . . . . . . . . 31 145 12.9. PERL Mail::Milter::Authentication module . . . . . . . . 31 146 12.10. Sympa List Manager . . . . . . . . . . . . . . . . . . . 31 147 12.11. Oracle Messaging Server . . . . . . . . . . . . . . . . 32 148 12.12. MessageSystems Momentum and PowerMTA platforms . . . . . 32 149 12.13. Exim . . . . . . . . . . . . . . . . . . . . . . . . . . 32 150 12.14. Halon MTA . . . . . . . . . . . . . . . . . . . . . . . 32 151 12.15. IIJ . . . . . . . . . . . . . . . . . . . . . . . . . . 33 152 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 153 13.1. Normative References . . . . . . . . . . . . . . . . . . 33 154 13.2. Informative References . . . . . . . . . . . . . . . . . 34 155 13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 35 156 Appendix A. Design Requirements . . . . . . . . . . . . . . . . 36 157 A.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 36 158 A.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 36 159 Appendix B. Example Usage . . . . . . . . . . . . . . . . . . . 36 160 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 38 161 Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 38 162 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 164 1. Introduction 166 The utility of widely deployed email authentication technologies such 167 as Sender Policy Framework (SPF) [RFC7208] and DomainKeys Identified 168 Mail (DKIM) [RFC6376] is impacted by the processing of Internet Mail 169 by intermediate handlers. This impact is thoroughly documented in 170 the defining documents for SPF and DKIM and further discussed in 171 [RFC6377] and [RFC7960]. 173 DMARC [RFC7489] also relies upon SPF and DKIM authentication 174 mechanisms. Failures of authentication caused by the actions of 175 intermediate handlers can cause legitimate mail to be incorrectly 176 rejected or misdirected. 178 Authenticated Received Chain (ARC) creates a mechanism for individual 179 Internet Mail Handlers to add their authentication assessment to a 180 message's ordered set of handling results. ARC encapsulates the 181 authentication assessment in a DKIM signature derivative to grant 182 other handlers the ability to verify the authenticity of the 183 individual assessment assertion as well as the aggregate set and 184 sequence of results. 186 Ordered sets of authentication assessments can be used by ARC-enabled 187 Internet Mail Handlers to inform message handling disposition, to 188 identify where alteration of message content might have occurred, and 189 to provide additional trace information for use in understanding 190 message handling paths. 192 2. General Concepts 194 ARC is loosely based on concepts from evidence collection. Evidence 195 is usually collected, labeled, stored, and transported in specific 196 ways to preserve the state of evidence and to document all processing 197 steps. 199 2.1. Evidence 201 In ARC's situation, the "evidence" is a message's authentication 202 assessment at any point along the delivery path between origination 203 and final delivery. Determination of message authentication can be 204 affected when intermediate handlers modify message content (header 205 fields and/or body content), route messages through unforeseen paths, 206 or change envelope information. 208 The authentication assessment for a message is determined upon 209 receipt of a message and documented in the Authentication-Results 210 header field(s). ARC extends this mechanism to survive transit 211 through intermediary ADMDs. 213 Because the first-hand determination of an authentication assessment 214 can never be reproduced by other handlers, the assertion of the 215 authentication assessment is more akin to testimony by a verifiable 216 party than hard evidence which can be independently evaluated. 218 2.2. Custody 220 "Custody" refers to when an Internet Mail Handler processes a 221 message. When a handler takes custody of a message, the handler 222 becomes a custodian and attaches their own evidence (authentication 223 assessment upon receipt) to the message if they are ARC-enabled. 224 Evidence is added in such a way so that future handlers can verify 225 the authenticity of both evidence and custody. 227 2.3. Chain of Custody 229 The "chain of custody" of ARC is the entire set of evidence and 230 custody that travels with a message. 232 2.4. Validation of Chain of Custody 234 Any ARC-enabled Internet Mail Handler can validate the entire set of 235 custody and the authentication assessments asserted by each party to 236 yield a valid Chain of Custody. If the evidence-supplying custodians 237 can be trusted, then the validated Chain of Custody describes the 238 (possibly changing) authentication assessment as the message traveled 239 through various custodians. 241 Even though a message's authentication assessment might have changed, 242 the validated chain of custody can be used to determine if the 243 changes (and the custodians responsible for the changes) can be 244 tolerated. 246 3. Terminology and Definitions 248 This section defines terms used in the rest of the document. 250 Readers should to be familiar with the contents, core concepts, and 251 definitions found in [RFC5598]. The potential roles of transit 252 services in the delivery of email are directly relevant. 254 Language, syntax (including some ABNF constructs), and concepts are 255 imported from DKIM [RFC6376]. Specific references to DKIM are made 256 throughout this document. The following terms are imported from 257 [RFC5598]: 259 o ADministrative Management Domain (ADMD), Section 2.3 261 o Message Transfer Agents (MTA), Section 4.3.2 263 o Message Submission Agent (MSA), Section 4.3.1 265 o Message Delivery Agent (MDA), Section 4.3.3 267 Syntax descriptions use Augmented BNF (ABNF) [RFC5234] and [RFC7405]. 269 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 270 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 271 "OPTIONAL" in this document are to be interpreted as described in 272 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 273 capitals, as shown here. These words may also appear in this 274 document in lower case as plain English words, absent their normative 275 meanings. 277 3.1. ARC Set 279 Section 4.1 introduces three (3) ARC header fields which are added to 280 a message by an ARC-enabled internet mail handler. Together, these 281 three header fields compose a single "ARC Set". An ARC Set provides 282 the means for an Internet Mail Handler to attach an authentication 283 assessment to a message in a manner that can be verified by future 284 handlers. A single message can contain multiple ARC Sets. 286 In general concept terms, an ARC Set represents Evidence and Custody. 288 3.2. Authenticated Received Chain (ARC) 290 The sequence of ARC Sets attached to a message at a given time is 291 called the Authenticated Received Chain. An Authenticated Received 292 Chain is the record of individual authentication assessments as a 293 message traverses through ARC-participating ADMDs. 295 The first attachment of an ARC Set to a message causes an 296 Authenticated Received Chain to be created. Additional attachments 297 of ARC Sets cause the Authenticated Received Chain to be extended. 299 In General concept terms, an Authenticated Received Chain represents 300 Chain of Custody. 302 3.3. Internet Mail Handlers / Intermediaries 304 Internet Mail Handlers process and deliver messages across the 305 Internet and include MSAs, MTAs, MDAs, gateways, and mailing lists as 306 defined in [RFC5598]. 308 Throughout this document the term "intermediaries" refers to the both 309 regular MTAs as well as delivery/reposting agents such as mailing 310 lists covered within the scope of [RFC5598]'s transit services. 312 "Intermediaries" and "Internet Mail Handlers" are used synonymously 313 throughout this document. 315 3.4. Authentication Assessment 317 The Authentication Assessment which is affixed to a message as part 318 of each ARC Set consists of the "authres-payload" [I-D-7601bis]. For 319 the integrity of an ARC Set, the Authentication Assessment only needs 320 to be properly encapsulated within the ARC Set as defined below 321 Section 4.1. The accuracy or syntax of the authres-payload field 322 does not affect the validity of the ARC chain itself. 324 3.5. Signing vs Sealing 326 Signing is the process of affixing a digital signature to a message 327 as a header field, such as when a DKIM-Signature (as in [RFC6376] 328 section 2.1), or an AMS or AS is added. Sealing is when an ADMD 329 affixes a complete and valid ARC Set to a message creating or 330 continuing an Authenticated Received Chain. 332 3.6. Sealer 334 A Sealer is an Internet Mail Handler that attaches a complete and 335 valid ARC Set to a message. 337 In general concept terms, a Sealer adds its testimony (assertion of 338 authentication assessment) and proof of custody to the Chain of 339 Custody. 341 3.7. Validator 343 A Validator is an ARC-enabled Internet Mail Handler that evaluates an 344 Authenticated Received Chain for validity and content. The process 345 of evaluation of the individual ARC Sets that compose an 346 Authenticated Received Chain is described in Section 5.2. 348 In general concept terms, a Validator inspects the Chain of Custody 349 to determine the content and validity of individual Evidence supplied 350 by custodians. 352 3.8. Imported ABNF Tokens 354 The following ABNF tokens are imported: 356 o tag-list ([RFC6376] section 3.2) 358 o authres-payload ([I-D-7601bis] section 2.2) 360 o cfws ([RFC5322] section 3.2.2) 362 3.9. Common ABNF Tokens 364 The following ABNF tokens are used elsewhere in this document: 366 position = 1*2DIGIT ; 1 - 50 367 instance = [CFWS] %s"i" [CFWS] "=" 368 [CFWS] position 369 chain-status = ("none" / "fail" / "pass") 370 seal-cv-tag = %s"cv" [CFWS] "=" 371 [CFWS] chain-status 373 4. Protocol Elements 375 4.1. ARC Header Fields 377 ARC introduces three new header fields. Syntax for new header fields 378 adapts existing specifications. This document only describes where 379 ARC-specific changes in syntax and semantics differ from existing 380 specifications. 382 4.1.1. ARC-Authentication-Results (AAR) 384 The ARC-Authentication-Results (AAR) header field records the message 385 authentication assessment as processed by an ARC-participating ADMD 386 at message arrival time. 388 In general concept terms, the AAR header field is where Evidence is 389 recorded by a custodian. 391 The AAR header field is similar in syntax and semantics to an 392 Authentication-Results field [I-D-7601bis], with two (2) differences: 394 o the name of the header field itself; 396 o the presence of the "instance tag". Additional information on the 397 "instance tag" can be found in Section 4.2.1. 399 The formal ABNF for the AAR header field is: 401 arc-info = instance [CFWS] ";" authres-payload 402 arc-authres-header = "ARC-Authentication-Results:" [CFWS] arc-info 404 Because there is only one AAR allowed per ARC set, the AAR MUST 405 contain the combined authres-payload with all of the authentication 406 results from within the participating ADMD, regardless of how many 407 Authentication-Results header fields are attached to the message. 409 4.1.2. ARC-Message-Signature (AMS) 411 The ARC-Message-Signature (AMS) header field allows an ARC- 412 participating ADMD to convey some responsibility (custodianship) for 413 a message and possible message modifications to future ARC- 414 participating custodians. 416 In general concept terms, the AMS header field identifies a 417 custodian. 419 The AMS header field has the same syntax and semantics as the DKIM- 420 Signature field [RFC6376], with three (3) differences: 422 o the name of the header field itself; 424 o no version tag ("v") is defined for the AMS header field. As 425 required for undefined tags (in [RFC6376]), if seen, a version tag 426 MUST be ignored; 428 o the "i" (AUID) tag is not imported from DKIM; instead, this tag is 429 replaced by the "instance tag" as defined in Section 4.2.1; 431 ARC places no requirements on the selectors and/or domains used for 432 the AMS header field signatures. 434 The formal ABNF for the AMS header field is: 436 arc-ams-info = instance [CFWS] ";" tag-list 437 arc-message-signature = "ARC-Message-Signature:" [CFWS] arc-ams-info 439 To reduce the chances of accidental invalidation of AMS signatures: 441 o AMS header fields are added by ARC-participating ADMDs as messages 442 exit the ADMD. AMS header fields SHOULD be attached so that any 443 modifications made by the ADMD are included in the signature of 444 the AMS header field. 446 o Authentication-Results header fields MUST NOT be included in AMS 447 signatures as they are likely to be deleted by downstream ADMDs 448 (per [I-D-7601bis] Section 5). 450 o ARC-related header fields (ARC-Authentication-Results, ARC- 451 Message-Signature, ARC-Seal) MUST NOT be included in the list of 452 header fields covered by the signature of the AMS header field. 454 To preserve the ability to verify the integrity of a message, the 455 signature of the AMS header field SHOULD include any DKIM-Signature 456 header fields already present in the message. 458 4.1.3. ARC-Seal (AS) 460 The ARC-Seal (AS) header field permits ARC-participating ADMDs to 461 verify the integrity of AAR header fields and corresponding AMS 462 header fields. 464 In general concept terms, the AS header field is how custodians bind 465 their authentication assessments (testimonial) into a Chain of 466 Custody so that Validators can inspect individual evidence and 467 custodians. 469 The AS header field is similar in syntax and semantics to DKIM- 470 Signatures [RFC6376], with the following differences: 472 o the "i" (AUID) tag is not imported from DKIM; instead, this tag is 473 replaced by the "instance tag" as defined in Section 4.2.1; 475 o the signature of the AS header field does not cover the body of 476 the message and therefore there is no 'bh' tag. The signature of 477 the AS header field only covers specific header fields as defined 478 in Section 5.1.1; 480 o no body canonicalization is performed as the AS signature does not 481 cover the body of a message; 483 o only "relaxed" header field canonicalization ([RFC6376] section 484 3.4.2) is used; 486 o the only supported tags are "i" (from Section 4.2.1 of this 487 document), and "a", "b", "d, "s", "t" from [RFC6376] Section 3.5. 488 Note especially that the DKIM "h" tag is NOT allowed and if found, 489 MUST result in a cv status of "fail" (for more information see 490 Section 5.1.1); 492 o an additional tag, "cv" ("seal-cv-tag" in the ARC-Seal ABNF 493 definition) is used to communicate Chain Validation Status to 494 subsequent ADMDs. 496 ARC places no requirements on the selectors and/or domains used for 497 the AS header field signatures. 499 The formal ABNF for the AS header field is: 501 arc-as-info = instance [CFWS] ";" tag-list 502 arc-seal = "ARC-Seal:" [CFWS] arc-as-info 504 4.1.4. Internationalized Email (EAI) 506 In internationalized messages [RFC6532] many header fields can 507 contain UTF-8 as well as ASCII text. The changes for EAI are all 508 inherited from DKIM as updated by [draft-levine-eaiauth] and 509 Authentication-Results as updated in [I-D-7601bis], but are called 510 out here for emphasis. 512 In all ARC header fields, the d= s= tags can contain U-labels. In 513 all tags, non-ASCII characters need not be quoted in dkim-quoted- 514 printable. 516 The AAR header allows UTF-8 in the same places that A-R does, as 517 described in [I-D-7601bis]. 519 4.2. ARC Set 521 An "ARC Set" is a single collection of three ARC header fields (AAR, 522 AMS, and AS). ARC header fields of an ARC Set share the same 523 "instance" value. 525 By adding all ARC header fields to a message, an ARC Sealer adds an 526 ARC Set to a message. A description of how Sealers add an ARC Set to 527 a message is found in Section 5.1. 529 4.2.1. Instance Tags 531 Instance tags describe which ARC header fields belong to an ARC Set. 532 Each ARC header field of an ARC Set shares the same instance tag 533 value. 535 Instance tag values are integers that begin at 1 and are incremented 536 by each addition of an ARC Set. Through the incremental values of 537 instance tags, an ARC Validator can determine the order in which ARC 538 Sets were added to a message. 540 Instance tag values can range from 1-50 (inclusive). 542 _INFORMATIONAL:_ The upper limit of 50 was picked based on some 543 initial observations reported by early working group members. The 544 value was chosen so as to balance the risk of excessive header field 545 growth Section 9.1 against expert opinion regarding the probability 546 of long-tail but non-looping multiple-intermediary mail flows. 547 Longer ARC chains will also impose load on validators and DNS to 548 support additional verification steps. Observed quantities of 549 "Received" header fields was also considered in establishing this as 550 an experimental initial value. 552 Valid ARC Sets MUST have exactly one instance of each ARC header 553 field (AAR, AMS, and AS) for a given instance value and signing 554 algorithm. 556 For handling multiple signing algorithms, see [ARC-MULTI]. 558 4.3. Authenticated Received Chain 560 An Authenticated Received Chain is an ordered collection of ARC Sets. 561 As ARC Sets are enumerated sets of ARC header fields, an 562 Authenticated Received Chain represents the output of message 563 authentication assessments along the handling path of ARC-enabled 564 processors. 566 Authentication Assessments determined at each step of the ARC-enabled 567 handling path is present in an Authenticated Received Chain in the 568 form of AAR header fields. The ability to verify the identity of 569 message handlers and the integrity of message content is provided by 570 AMS header fields. AS header fields allow messages handlers to 571 validate the assertions, order and sequence of the Authenticated 572 Received Chain itself. 574 In general concept terms, an Authenticated Received Chain represents 575 a message's Chain of Custody. Validators can consult a message's 576 Chain of Custody to gain insight regarding each custodian of a 577 message and the Evidence collected by each custodian. 579 4.4. Chain Validation Status 581 The state of the Authenticated Received Chain at a specific 582 processing step is called the "Chain Validation Status". Chain 583 Validation Status information is communicated in several ways: 585 o the AS header field in the "cv" tag, and 587 o as part of Authentication-Results and AAR header field(s). 589 Chain Validation Status has one of three possible values: 591 o none: There was no Authenticated Received Chain on the message 592 when it arrived for validation. Typically, this occurs when a 593 message is received directly from a message's original Message 594 Transfer Agent (MTA) or Message Submission Agent (MSA), or from an 595 upstream Internet Mail Handler that is not participating in ARC 596 handling. 598 o fail: The message contains an Authenticated Received Chain whose 599 validation failed. 601 o pass: The message contains an Authenticated Received Chain whose 602 validation succeeded. 604 5. Protocol Actions 606 ARC-enabled Internet Mail Handlers generally act as both ARC 607 Validators (when receiving messages) and ARC Sealers (when sending 608 messages onward, not originated locally). 610 An Authenticated Received Chain with a Chain Validation Status of 611 "pass" (or "none") allows Internet Mail Handlers to ascertain: 613 o all ARC-participating ADMDs that claim responsibility for handling 614 (and possibly modifying) the message in transit; 616 o the authentication assessments of the message as determined by 617 each ADMD (from AAR header fields). 619 With this information, Internet Mail Handlers MAY inform local policy 620 decisions regarding disposition of messages that experience 621 authentication failure due to intermediate processing. 623 5.1. Sealer Actions 625 To "seal" a message, an ARC Sealer adds an ARC Set (the three ARC 626 header fields AAR, AMS, and AS) to a message. All ARC header fields 627 in an ARC Set share the same instance tag value. 629 To perform Sealing (aka to build and attach a new ARC Set), the 630 following actions must be taken by an ARC Sealer when presented with 631 a message: 633 1. All message modifications (including adding DKIM-Signature header 634 field(s)) MUST be performed before Sealing. 636 2. If the message already contains an Authenticated Received Chain 637 with the most recent AS reporting "cv=fail", then there is no 638 need to proceed and the algorithm stops here. 640 3. Calculate the instance value: if the message already contains an 641 Authenticated Received Chain, the instance value is 1 more than 642 the highest instance number found in the Authenticated Received 643 Chain. If no Authenticated Received Chain exists, the instance 644 value is 1. 646 4. Using the calculated instance value, generate and attach a 647 complete ARC set to the message as follows: 649 1. Generate and attach an ARC-Authentication-Results header 650 field as defined in Section 4.1.1. 652 2. Generate and attach an ARC-Message-Signature header field as 653 defined in Section 4.1.2. 655 3. Generate and attach an ARC-Seal header field using the AS 656 definition found in Section 4.1.3, the prescribed headers 657 defined in Section 5.1.1, and the Chain Validation Status as 658 determined during ARC Validation. 660 5.1.1. Header Fields To Include In ARC-Seal Signatures 662 The ARC-Seal is generated in a manner similar to how DKIM-Signatures 663 are added to messages ([RFC6376], section 3.7), with explicit 664 requirements on the header fields and ordering of those fields. 666 The signature of an AS header field signs a canonicalized form of the 667 ARC Set header field values. The ARC set header field values are 668 supplied to the hash function in increasing instance order, starting 669 at 1, and include the ARC Set being added at the time of Sealing the 670 message. 672 Within an ARC Set, header fields are supplied to the hash function in 673 the following order: 675 1. ARC-Authentication-Results 677 2. ARC-Message-Signature 679 3. ARC-Seal 681 Note that when an Authenticated Received Chain has failed validation, 682 the signing scope for the ARC-Seal is modified as specified in 683 Section 5.1.2. 685 5.1.2. Marking and Sealing "cv=fail" (Invalid) Chains 687 In the case of a failed Authenticated Received Chain, the header 688 fields included in the signature scope of the AS header field b= 689 value MUST only include the ARC Set header fields created by the MTA 690 which detected the malformed chain, as if this newest ARC Set was the 691 only set present. 693 _INFORMATIONAL_: This approach is mandated to handle the case of a 694 malformed or otherwise invalid Authenticated Received Chain. There 695 is no way to generate a deterministic set of AS header fields 696 (Section 5.1.1) in most cases of invalid chains. 698 5.1.3. Only One Authenticated Received Chain Per Message 700 A message can have only one Authenticated Received Chain on it at a 701 time. Once broken, the chain cannot be continued, as the chain of 702 custody is no longer valid and responsibility for the message has 703 been lost. For further discussion of this topic and the design 704 restriction which prevents chain continuation or re-establishment, 705 see [ARC-USAGE]. 707 5.1.4. Broad Ability to Seal 709 ARC is not solely intended for perimeter MTAs. Any Internet Mail 710 Handler MAY seal a message by adding a complete ARC set, whether or 711 not they have modified or are aware of having modified the message. 712 For additional information, see Section 7.1. 714 5.1.5. Sealing is Always Safe 716 The utility of an Authenticated Received Chain is limited to very 717 specific cases. Authenticated Received Chains are designed to 718 provide additional information to an Internet Mail Handler when 719 evaluating messages for delivery in the context of authentication 720 failures. Specifically: 722 o Properly adding an ARC Set to a message does not damage or 723 invalidate an existing Authenticated Received Chain. 725 o Sealing an Authenticated Received Chain when a message has not 726 been modified does not negatively affect the chain. 728 o Validating a message exposes no new threat vectors (see 729 Section 9). 731 o An ADMD may choose to Seal all inbound messages whether or not a 732 message has been modified or will be retransmitted. 734 5.2. Validator Actions 736 A validator performs the following steps, in sequence, to process an 737 Authenticated Received Chain. Canonicalization, hash functions, and 738 signature validation methods are imported from [RFC6376] section 5. 740 1. Collect all ARC Sets currently attached to the message. 742 * If there are none, the Chain Validation Status is "none" and 743 the algorithm stops here. 745 * The maximum number of ARC Sets that can be attached to a 746 message is 50. If more than the maximum number exist the 747 Chain Validation Status is "fail" and the algorithm stops 748 here. 750 * In the following algorithm, the maximum discovered ARC 751 instance value is referred to as "N". 753 2. If the Chain Validation Status of the highest instance value ARC 754 Set is "fail", then the Chain Validation status is "fail" and the 755 algorithm stops here. 757 3. Validate the structure of the Authenticated Received Chain. A 758 valid ARC has the following conditions: 760 1. Each ARC Set MUST contain exactly one each of the three ARC 761 header fields (AAR, AMS, and AS). 763 2. The instance values of the ARC Sets MUST form a continuous 764 sequence from 1..N with no gaps or repetition. 766 3. The "cv" value for all ARC-Seal header fields MUST NOT be 767 "fail". For ARC Sets with instance values > 1, the values 768 MUST be "pass". For the ARC Set with instance value = 1, the 769 value MUST be "none". 771 * If any of these conditions are not met, the Chain Validation 772 Status is "fail" and the algorithm stops here. 774 4. Validate the AMS with the greatest instance value (most recent). 775 If validation fails, then the Chain Validation Status is "fail" 776 and the algorithm stops here. 778 5. _OPTIONAL:_ Determine the "oldest-pass" value from the ARC Set by 779 validating each prior AMS beginning with the N-1 and proceeding 780 in decreasing order to the AMS with the instance value of 1: 782 1. If an AMS fails to validate (for instance value "M"), then 783 set the oldest-pass value to the lowest AMS instance value 784 which passed (M+1) and go to the next step (there is no need 785 to check any other (older) AMS header fields). This does not 786 affect the validity of the Authenticated Received Chain. 788 2. If all AMS header fields verify, set the oldest-pass value to 789 zero (0). 791 6. Validate each AS beginning with the greatest instance value and 792 proceeding in decreasing order to the AS with the instance value 793 of 1. If any AS fails to validate, the Chain Validation Status 794 is "fail" and the algorithm stops here. 796 7. If the algorithm reaches this step, then the Chain Validation 797 Status is "pass", and the algorithm is complete. 799 The end result of this Validation algorithm SHOULD be included within 800 the Authentication-Results header field for the ADMD. 802 As with a DKIM signature ([RFC6376] section 6.3) which fails 803 verification, a message with an Authenticated Received Chain with a 804 Chain Validation status of "fail" MUST be treated the same as a 805 message with no Authenticated Received Chain. 807 _INFORMATIONAL_: Recipients of an invalid or failing Authenticated 808 Received Chain can use that information as part of a wider handling 809 context. ARC adoption cannot be assumed by intermediaries; many 810 intermediaries will continue to modify messages without adding ARC 811 Seals. 813 5.2.1. All Failures Are Permanent 815 Authenticated Received Chains represent the traversal of messages 816 through one or more intermediaries. All errors, including DNS 817 failures, become unrecoverable and are considered permanent. 819 Any error validating an Authenticated Received Chain results in a 820 Chain Validation Status of "fail". For further discussion of this 821 topic and the design restriction which prevents chain continuation or 822 re-establishment, see [ARC-USAGE]. 824 5.2.2. Responding to ARC Validation Failures During the SMTP 825 Transaction 827 If an ARC Validator determines that the incoming message fails ARC 828 validation, the Validator MAY signal the breakage through the 829 extended SMTP response code 5.7.29 "ARC validation failure" and 830 corresponding SMTP basic response code. Because ARC failures are 831 likely only to be detected in the context of other underlying 832 authentication mechanism failures, validators MAY use the more 833 general 5.7.26 "Multiple authentication checks failed" instead of the 834 ARC-specific code. 836 6. Communication of Validation Results 838 Chain Validation Status (described in Section 4.4) is communicated 839 via Authentication-Results (and AAR) header fields using the auth 840 method "arc". This auth method is described in Section 10.1. 842 If necessary data is available, the ptypes and properties defined in 843 Section 10.2 SHOULD be recorded in an Authentication-Results header 844 field: 846 o smtp.remote-ip - The address of the connection-initiating SMTP 847 server, from which the message is being relayed. 849 o header.oldest-pass - The instance number of the oldest AMS that 850 still validates, or 0 if all pass. 852 7. Use Cases 854 This section explores several messaging handling use cases that are 855 addressed by ARC. 857 7.1. Communicate Authentication Assessment Across Trust Boundaries 859 When an intermediary ADMD adds an ARC Set to a message's 860 Authenticated Received Chain (or creates the initial ARC Set), the 861 ADMD communicates its authentication assessment to the next ARC- 862 participating ADMD in the message handling path. 864 If ARC-enabled ADMDs are trusted, Authenticated Received Chains can 865 be used to bridge administrative boundaries. 867 7.1.1. Message Scanning Services 869 Message services are available to perform anti-spam, anti-malware, 870 and anti-phishing scanning. Such services typically remove malicious 871 content, replace HTTP links in messages with sanitized links, and/or 872 attach footers to messages advertising the abilities of the message 873 scanning service. These modifications almost always break signature- 874 based authentication (such as DKIM). 876 Scanning services typically require clients to point MX records of an 877 Internet domain to the scanning service. Messages destined for the 878 Internet domain are initially delivered to the scanning service. 879 Once scanning is performed, messages are then routed to the client's 880 own mail handling infrastructure. Re-routing messages in this way 881 almost always breaks path-based authentication (such as SPF). 883 Message scanning services can attach Authenticated Received Chains to 884 messages to communicate authentication assessment into client ADMDs. 885 Clients can then benefit from the message scanning service while 886 processing messages as if the client's infrastructure were the 887 original destination of the Internet domain's MX record. 889 7.1.2. Multi-tier MTA Processing 891 Large message processing infrastructure is often divided into several 892 processing tiers that can break authentication information between 893 tiers. For example, a large site may maintain a cluster of MTAs 894 dedicated to connection handling and enforcement of IP-based 895 reputation filtering. A secondary cluster of MTAs may be dedicated 896 and optimized for content-based processing of messages. 898 Authenticated Received Chains can be used to communicate 899 authentication assessment between processing tiers. 901 7.1.3. Mailing Lists 903 Mailing lists take delivery of messages and re-post them to 904 subscribers. A full description of authentication-related mailing 905 list issues can be found in [RFC7960] Section 3.2.3. 907 Mailing list services can implement ARC to convey the authentication 908 assessment of posted messages sent to the list's subscriber base. 909 The ADMDs of the mailing list subscribers can then use the 910 Authenticated Received Chain to determine the authentication 911 assessment of the original message before mailing list handling. 913 7.2. Inform Message Disposition Decisions 915 Intermediaries often break authentication through content 916 modification, interfere with path-based authentication (such as SPF), 917 and strip authentication results (if an MTA removes Authentication- 918 Results header fields). 920 Authenticated Received Chains allow ARC Validators to: 922 1. identify ARC-enabled ADMDs that break authentication while 923 processing messages; 925 2. gain extended visibility into the authentication-preserving 926 abilities of ADMDs that relay messages into ARC-enabled ADMDs. 928 Through the collection of ARC-related data, an ADMD can identify 929 handling paths that have broken authentication. 931 An Authenticated Received Chain allows an Internet Mail Handler to 932 potentially base decisions of message disposition on authentication 933 assessments provided by different ADMDs. 935 7.2.1. DMARC Local Policy Overrides 937 DMARC introduces a policy model where Domain Owners can request email 938 receivers to reject or quarantine messages that fail DMARC alignment. 939 Interoperability issues between DMARC and indirect email flows are 940 documented in [RFC7960]. 942 Authenticated Received Chains allow DMARC processors to consider 943 authentication assessments provided by other ADMDs. As a matter of 944 local policy, a DMARC processor MAY choose to accept the 945 authentication assessments provided by an Authenticated Received 946 Chain when determining if a message is DMARC compliant. 948 When an Authenticated Received Chain is used to determine message 949 disposition, the DMARC processor can communicate this local policy 950 decision to Domain Owners as described in Section 7.2.2. 952 7.2.2. DMARC Reporting 954 DMARC-enabled receivers indicate when ARC Validation influences 955 DMARC-related local policy decisions. When an ARC-enabled handler 956 generates a DMARC report, it MAY indicate the influence of ARC on 957 their local policy decision(s) by adding a reason of "local_policy" 958 with a comment string (per [RFC7489] Appendix C) containing a list of 959 data discovered during ARC Validation, which at a minimum includes: 961 o the Chain Validation Status, 963 o the domain and selector for each AS, 965 o the originating IP address from the first ARC Set: 967 EXAMPLE: 969 970 none 971 fail 972 fail 973 974 local_policy 975 arc=pass as[2].d=d2.example as[2].s=s2 976 as[1].d=d1.example as[1].s=s3 977 remote-ip[1]=10.10.10.13 978 979 981 In the above example DMARC XML reporting fragment, data relating to 982 specific validated ARC Sets are enumerated using array syntax (eg, 983 "as[2]" means AS header field with instance value of 2). d2.example 984 is the Sealing domain for ARC Set #2 (i=2) and d1.example is the 985 Sealing domain for ARC Set #1 (i=1). 987 Depending on the reporting practices of intermediate message 988 handlers, Domain Owners may receive multiple DMARC reports for a 989 single message. Receivers of DMARC reports should be aware of this 990 behaviour and make the necessary accommodations. 992 8. Privacy Considerations 994 The Authenticated Received Chain provides a verifiable record of the 995 handlers for a message. This record may include Personally 996 Identifiable Information such as IP address(es) and domain names. 997 Such information is also included in existing non-ARC related header 998 fields such as the "Received" header fields. 1000 9. Security Considerations 1002 The Security Considerations of [RFC6376] and [I-D-7601bis] apply 1003 directly to this specification. 1005 As with other domain authentication technologies (such as SPF, DKIM, 1006 and DMARC), ARC makes no claims about the semantic content of 1007 messages. 1009 9.1. Increased Header Field Size 1011 Inclusion of Authenticated Received Chains into messages may cause 1012 issues for older or constrained MTAs due to increased total header 1013 field size. Large header field blocks, in general, may cause 1014 failures to deliver or other outage scenarios for such MTAs. ARC 1015 itself would not cause problems. 1017 9.2. DNS Operations 1019 The validation of an Authenticated Received Chain composed of N ARC 1020 Sets can require up to 2*N DNS queries (not including any DNS 1021 redirection mechanisms which can increase the total number of 1022 queries). This leads to two considerations: 1024 1. An attacker can send a message to an ARC participant with a 1025 concocted sequence of ARC Sets bearing the domains of intended 1026 victims, and all of them will be queried by the participant until 1027 a failure is discovered. DNS caching and the difficulty of 1028 forging the signature values should limit the extent of this load 1029 to domains under control of the attacker. Query traffic pattern 1030 analysis may expose information about downstream validating ADMD 1031 infrastructure. 1033 2. DKIM only performs one DNS query per signature, while ARC can 1034 introduce many (per chain). Absent caching, slow DNS responses 1035 can cause SMTP timeouts; and backlogged delivery queues on 1036 Validating systems. This could be exploited as a DoS attack. 1038 9.3. Message Content Suspicion 1040 Recipients are cautioned to treat messages bearing Authenticated 1041 Received Chains with the same suspicion applied to all other 1042 messages. This includes appropriate content scanning and other 1043 checks for potentially malicious content. 1045 ARC authenticates the identity of some email handling actors. It 1046 does not make any assessment of their trustworthiness. 1048 Just as passing message authentication is not an indication of 1049 message safety, forwarding that information through the mechanism of 1050 ARC is also not an indication of message safety. Even if all ARC- 1051 enabled ADMDs are trusted, ADMDs may have become compromised, may 1052 miss unsafe content, or may not properly authenticate messages. 1054 9.4. Message Sealer Suspicion 1056 Recipients are cautioned to treat every Sealer of the ARC Chain with 1057 suspicion. Just as with a validated DKIM signature, responsibility 1058 for message handling is attributed to the Sealing domain, but whether 1059 or not that Sealer is a malicious actor is out of scope of the 1060 authentication mechanism. Since ARC aids message delivery in the 1061 event of an authentication failure, ARC Sealers should be treated 1062 with suspicion, so that a malicious actor cannot Seal spam or other 1063 fraudulent messages to aid their delivery, too. 1065 9.5. Replay Attacks 1067 Since ARC inherits heavily from DKIM, it has similar attack vectors. 1068 In particular, the Replay Attack described in [RFC6376] section 8.6 1069 is potentially amplified by ARC's chained statuses. In an ARC replay 1070 attack, a malicious actor would take an intact and passing ARC Chain, 1071 and then resend it to many recipients without making any 1072 modifications that invalidate the latest AMS or AS. The impact to a 1073 receiver would be more DNS lookups and signature evaluations. This 1074 scope of this attack can be limited by caching DNS queries and 1075 following the same signing scope guidance from [RFC6376] section 1076 5.4.1. 1078 10. IANA Considerations 1080 [[ *Note to the RFC Editors:* "dkim - header - s" is defined in 1081 [I-D-7601bis]. Please adjust the list below as appropriate. ]] 1083 This draft introduces three new headers fields and updates the Email 1084 Authentication Parameters registry with one new authentication method 1085 and several status codes. 1087 10.1. Email Authentication Results Names Registry Update 1089 This draft adds one Auth Method with three Codes to the IANA "Email 1090 Authentication Result Names" registry: 1092 o Auth Method : arc 1093 Code: "none", "pass", "fail" 1094 Specification: this document 2.2 1095 Status: active 1097 10.2. Email Authentication Methods Registry Update 1099 This draft adds several new items to the Email Authentication Methods 1100 registry, most recently defined in [I-D-7601bis]: 1102 o Method: arc 1103 Definition: this document 1104 ptype: smtp 1105 Property: remote-ip 1106 Value: IP address of originating SMTP connection 1107 Status: active 1108 Version: 1 1110 o Method: arc 1111 Definition: this document 1112 ptype: header 1113 Property: oldest-pass 1114 Value: The instance id of the oldest validating AMS, or 0 if they 1115 all pass (see Section 5.2) 1116 Status: active 1117 Version: 1 1119 o Method: dkim 1120 Definition: [I-D-7601bis] 1121 ptype: header 1122 Property: s 1123 Value: value of signature "s" tag 1124 Status: active 1125 Version: 1 1127 10.3. Definitions of the ARC header fields 1129 This specification adds three new header fields to the "Permanent 1130 Message Header Field Registry", as follows: 1132 o Header field name: ARC-Seal 1133 Applicable protocol: mail 1134 Status: Experimental 1135 Author/Change controller: IETF 1136 Specification document(s): this document 1137 Related information: [RFC6376] 1139 o Header field name: ARC-Message-Signature 1140 Applicable protocol: mail 1141 Status: Experimental 1142 Author/Change controller: IETF 1143 Specification document(s): this document 1144 Related information: [RFC6376] 1146 o Header field name: ARC-Authentication-Results 1147 Applicable protocol: mail 1148 Status: Experimental 1149 Author/Change controller: IETF 1150 Specification document(s): this document 1151 Related information: [I-D-7601bis] 1153 10.4. New Enhanced Status Code - ARC Validation 1155 The following value should be added to the [ENHANCED-STATUS] 1156 registry, as follows: 1158 o Code: X.7.29 1159 Sample Text: ARC validation failure 1160 Associated basic status code: 550 1161 Description: This status code may be returned when a message fails 1162 ARC validation 1163 Reference: this document 1164 Submitter: K. Andersen 1165 Change controller: IESG 1167 11. Experimental Considerations 1169 The ARC protocol is designed to address common interoperability 1170 issues introduced by intermediate message handlers. Interoperability 1171 issues are described in [RFC6377] and [RFC7960]. 1173 As the ARC protocol is implemented by Internet Mail Handlers over 1174 time, the following should be evaluated in order to determine the 1175 success of the protocol in accomplishing the intended benefits. 1177 11.1. Success Consideration 1179 In an attempt to deliver legitimate messages that users desire, many 1180 receivers use heuristic-based methods to identify messages that 1181 arrive via indirect delivery paths. 1183 ARC will be a success if the presence of Authenticated Received 1184 Chains allows for improved decision making when processing legitimate 1185 messages, specifically resulting in equal or better delivery rates 1186 than achieve through the use of heuristic approaches. 1188 11.2. Failure Considerations 1190 ARC should function without introducing significant new vectors for 1191 abuse (see Section 9). If unforeseen vectors are enabled by ARC, 1192 then this protocol will be a failure. Note that weaknesses inherent 1193 in the mail protocols ARC is built upon (such as DKIM replay attacks 1194 and other known issues) are not new vectors which can be attributed 1195 to this specification. 1197 11.3. Open Questions 1199 The following open questions are academic and have no clear answer at 1200 the time of the development of the protocol. However, additional 1201 deployments should be able to gather the necessary data to answer 1202 some or all of them. 1204 11.3.1. Value of the ARC-Seal (AS) Header Field 1206 Data should be collected to show if the ARC-Seal (AS) provides value 1207 beyond the ARC Message Signature (AMS) for either making delivery 1208 decisions or catching malicious actors trying to craft or replay 1209 malicious chains. 1211 11.3.2. Usage and/or signals from multiple selectors and/or domains in 1212 ARC sets 1214 Any selectors and/or (sub)domains (under the control of the sealing 1215 ADMD) may be used for ARC header field signatures. 1217 While implementers may choose to use various selectors and/or domains 1218 for ARC set header fields, no compelling argument for or against such 1219 usage has been made within the working group. As such we have chosen 1220 to allow maximum freedom for the experimental definition of this 1221 protocol. 1223 Wider deployment experience and higher volumes of traffic may show 1224 whether this is useful. 1226 11.3.3. DNS Overhead 1228 Longer Authenticated Received Chains will require more queries to 1229 retrieve the keys for validating the chain. While this is not 1230 believed to be a security issue (see Section 9.2), it is unclear how 1231 much overhead will truly be added. This is similar to some of the 1232 initial processing and query load concerns which were debated at the 1233 time of the DKIM specification development. 1235 Data should be collected to better understand usable length and 1236 distribution of lengths found in valid Authenticated Received Chains 1237 along with the DNS impact of processing Authenticated Received 1238 Chains. 1240 An effective operational maximum will have to be developed through 1241 deployment experience in the field. 1243 11.3.4. What Trace Information is Valuable 1245 There are several edge cases where the information in the AAR can 1246 make the difference between message delivery or rejection. For 1247 example, if there is a well known mailing list that seals with ARC 1248 but doesn't do its own initial DMARC enforcement, an Internet Mail 1249 Handler with this knowledge could make a delivery decision based upon 1250 the authentication information it sees in the corresponding AAR 1251 header field. 1253 Certain trace information in the AAR is useful/necessary in the 1254 construction of DMARC reports. 1256 Further, certain receivers believe the entire set of trace 1257 information would be valuable to feed into machine learning systems 1258 to identify fraud and/or provide other signals related to message 1259 delivery. 1261 At this point, however, it is unclear what trace information will be 1262 valuable for all receivers, regardless of size. 1264 Data should be collected on what trace information receivers are 1265 using that provides useful signals that affect deliverability, and 1266 what portions of the trace data are left untouched or provide no 1267 useful information. 1269 Since many such systems are intentionally proprietary or confidential 1270 to prevent gaming by abusers, it may not be viable to reliably answer 1271 this particular question. The evolving nature of attacks can also 1272 shift the landscape of "useful" information over time. 1274 12. Implementation Status 1276 [[ Note to the RFC Editor: Please remove this section before 1277 publication along with the reference to [RFC7942]. ]] 1278 This section records the status of known implementations of the 1279 protocol defined by this specification at the time of posting of this 1280 Internet-Draft, and is based on a proposal described in [RFC7942]. 1281 The description of implementations in this section is intended to 1282 assist the IETF in its decision processes in progressing drafts to 1283 RFCs. Please note that the listing of any individual implementation 1284 here does not imply endorsement by the IETF. Furthermore, no effort 1285 has been spent to verify the information presented here that was 1286 supplied by IETF contributors. This is not intended as, and must not 1287 be construed to be, a catalog of available implementations or their 1288 features. Readers are advised to note that other implementations may 1289 exist. 1291 This information is known to be correct as of the eighth 1292 interoperability test event which was held on 2018-03-17 at IETF101. 1294 For a few of the implementations, later status information was 1295 available as of August 2018. 1297 12.1. GMail test reflector and incoming validation 1299 Organization: Google 1300 Description: Internal production implementation with both debug 1301 analysis and validating + sealing pass-through function 1302 Status of Operation: Production - Incoming Validation 1303 Coverage: Full spec implemented as of [ARC-DRAFT-14] 1304 Licensing: Proprietary - Internal only 1305 Implementation Notes: 1307 o Full functionality was demonstrated during the interop testing on 1308 2018-03-17. 1310 Contact Info: arc-discuss@dmarc.org [1] 1312 12.2. AOL test reflector and internal tagging 1314 Organization: AOL 1315 Description: Internal prototype implementation with both debug 1316 analysis and validating + sealing pass-through function 1317 Status of Operation: Beta 1318 Coverage: ARC Chain validity status checking is operational, but only 1319 applied to email addresses enrolled in the test program. This system 1320 conforms to [ARC-DRAFT-05] 1321 Licensing: Proprietary - Internal only 1322 Implementation Notes: 1324 o 2017-07-15: Full functionality verified during the interop 1325 testing. 1327 o 2018-06: Partially retired but still accessible by special request 1328 due to the in process evolution of the AOL mail infrastructure to 1329 the integrated OATH environment. The implementation was based on 1330 the Apache James DKIM code base and may be contributed back to 1331 that project in the future. 1333 Contact Info: arc-discuss@dmarc.org [2] 1335 12.3. dkimpy 1337 Organization: dkimpy developers/Scott Kitterman 1338 Description: Python DKIM package 1339 Status of Operation: Production 1340 Coverage: 1342 o 2017-07-15: The internal test suite is incomplete, but the command 1343 line developmental version of validator was demonstrated to 1344 interoperate with the Google and AOL implementations during the 1345 interop on 2017-07-15 and the released version passes the tests in 1346 [ARC-TEST] arc_test_suite [3] with both python and python3. 1348 Licensing: Open/Other (same as dkimpy package = BCD version 2) 1349 Contact Info: https://launchpad.net/dkimpy 1351 12.4. OpenARC 1353 Organization: TDP/Murray Kucherawy 1354 Description: Implementation of milter functionality related to the 1355 OpenDKIM and OpenDMARC packages 1356 Status of Operation: Beta 1357 Coverage: Built to support [ARC-DRAFT-14] 1358 Licensing: Open/Other (same as OpenDKIM and OpenDMARC packages) 1359 Implementation Notes: 1361 o Known issues have been resolved with release X 1363 Contact Info: arc-discuss@dmarc.org [4], openarc-users@openarc.org 1364 [5] 1366 12.5. Mailman 3.x patch 1368 Organization: Mailman development team 1369 Description: Integrated ARC capabilities within the Mailman 3.2 1370 package 1371 Status of Operation: Patch submitted 1372 Coverage: Based on OpenARC 1373 Licensing: Same as mailman package - GPL 1374 Implementation Notes: 1376 o Appears to work properly in at least one beta deployment, but 1377 waiting on acceptance of the pull request into the mainline of 1378 mailman development 1380 Contact Info: https://www.gnu.org/software/mailman/contact.html 1382 12.6. Copernica/MailerQ web-based validation 1384 Organization: Copernica 1385 Description: Web-based validation of ARC-signed messages 1386 Status of Operation: Beta 1387 Coverage: Built to support [ARC-DRAFT-05] 1388 Licensing: On-line usage only 1389 Implementation Notes: 1391 o Released 2016-10-24 1393 o Requires full message content to be pasted into a web form found 1394 at http://arc.mailerq.com/ (warning - https is not supported). 1396 o An additional instance of an ARC signature can be added if one is 1397 willing to paste a private key into an unsecured web form. 1399 o 2017-07-15: Testing shows that results match the other 1400 implementations listed in this section. 1402 Contact Info: https://www.copernica.com/ 1404 12.7. Rspamd 1406 Organization: Rspamd community 1407 Description: ARC signing and verification module 1408 Status of Operation: Production, though deployment usage is unknown 1409 Coverage: Built to support [ARC-DRAFT-14] 1410 Licensing: Open source 1411 Implementation Notes: 1413 o 2017-06-12: Released with version 1.6.0 1415 o 2017-07-15: Testing during the interop showed that the validation 1416 functionality interoperated with the Google, AOL, dkimpy and 1417 MailerQ implementations 1419 Contact Info: https://rspamd.com/doc/modules/arc.html and 1420 https://github.com/vstakhov/rspamd 1422 12.8. PERL MAIL::DKIM module 1424 Organization: FastMail 1425 Description: Email domain authentication (sign and/or verify) module, 1426 previously included SPF / DKIM / DMARC, now has ARC added 1427 Status of Operation: Production, deployment usage unknown 1428 Coverage: Built to support [ARC-DRAFT-10] 1429 Licensing: Open Source 1430 Implementation Notes: 1432 o 2017-12-15: v0.50 released with full test set passing for ARC 1434 Contact Info: http://search.cpan.org/~mbradshaw/Mail-DKIM-0.50/ 1436 12.9. PERL Mail::Milter::Authentication module 1438 Organization: FastMail 1439 Description: Email domain authentication milter, uses MAIL::DKIM (see 1440 above) 1441 Status of Operation: Initial validation completed during IETF99 1442 hackathon with some follow-on work during the week 1443 Coverage: Built to support [ARC-DRAFT-14] 1444 Licensing: Open Source 1445 Implementation Notes: 1447 o 2017-07-15: Validation functionality which interoperates with 1448 Gmail, AOL, dkimpy was demonstrated; later in the week of IETF99, 1449 the signing functionality was reported to be working 1451 o 2017-07-20: ARC functionality has not yet been pushed back to the 1452 github repo but should be showing up soon 1454 Contact Info: https://github.com/fastmail/authentication_milter 1456 12.10. Sympa List Manager 1458 Organization: Sympa Dev Community 1459 Description: Work in progress 1460 Status of Operation: Work in progress 1461 Coverage: unknown 1462 Licensing: open source 1463 Implementation Notes: 1465 o 2018-01-05: Tracked as https://github.com/sympa-community/sympa/ 1466 issues/153 1468 Contact Info: https://github.com/sympa-community 1470 12.11. Oracle Messaging Server 1472 Organization: Oracle 1473 Description: 1474 Status of Operation: Initial development work during IETF99 1475 hackathon. Framework code is complete, crypto functionality requires 1476 integration with libsodium 1477 Coverage: Work in progress 1478 Licensing: Unknown 1479 Implementation Notes: 1481 o 2018-03: Protocol handling components are completed, but crypto is 1482 not yet functional. 1484 Contact Info: Chris Newman, Oracle 1486 12.12. MessageSystems Momentum and PowerMTA platforms 1488 Organization: MessageSystems/SparkPost 1489 Description: OpenARC integration into the LUA-enabled Momentum 1490 processing space 1491 Status of Operation: Beta 1492 Coverage: Same as OpenARC 1493 Licensing: Unknown 1494 Implementation Notes: 1496 o Initial deployments for validation expected in mid-2018. 1498 Contact Info: TBD 1500 12.13. Exim 1502 Organization: Exim developers 1503 Status of Operation: Operational; requires specific enabling for 1504 compile. 1505 Coverage: Full spec implemented as of [ARC-DRAFT-13] 1506 Licensing: GPL 1507 Contact Info: exim-users@exim.org 1508 Implementation notes: 1510 o Implemented as of Exim 4.91 1512 12.14. Halon MTA 1514 Organization: Halon 1515 Status of Operation: Operational as of May 2018 1516 Coverage: Full spec implemented as of [ARC-DRAFT-14] 1517 Licensing: Commercial, trial version available for download 1518 Contact Info: https://halon.io 1519 Implementation notes: 1521 o GPL'd library with ARC capabilities: https://github.com/halon/ 1522 libdkimpp 1524 12.15. IIJ 1526 Organization: Internet Initiative Japan (IIJ) Status of Operation: 1527 Operational as of October 2018 1528 Coverage: Full spec implemented as of this document 1529 Licensing: Internal 1530 Contact Info: https://www.iij.ad.jp/en/ 1531 Implementation notes: 1533 o Internal MTA implementation validated during the ARC interop 1534 exercise in mid-October 2018 1536 13. References 1538 13.1. Normative References 1540 [draft-levine-eaiauth] 1541 Levine, J., "E-mail Authentication for Internationalized 1542 Mail", August 2018, . 1545 [I-D-7601bis] 1546 Kucherawy, M., "Message Header Field for Indicating 1547 Message Authentication Status", February 2018, 1548 . 1551 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1552 Requirement Levels", BCP 14, RFC 2119, 1553 DOI 10.17487/RFC2119, March 1997, 1554 . 1556 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1557 Specifications: ABNF", STD 68, RFC 5234, 1558 DOI 10.17487/RFC5234, January 2008, 1559 . 1561 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1562 DOI 10.17487/RFC5322, October 2008, 1563 . 1565 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 1566 DOI 10.17487/RFC5598, July 2009, 1567 . 1569 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 1570 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 1571 RFC 6376, DOI 10.17487/RFC6376, September 2011, 1572 . 1574 [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and 1575 Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377, 1576 September 2011, . 1578 [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized 1579 Email Headers", RFC 6532, DOI 10.17487/RFC6532, February 1580 2012, . 1582 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 1583 Authorizing Use of Domains in Email, Version 1", RFC 7208, 1584 DOI 10.17487/RFC7208, April 2014, 1585 . 1587 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 1588 RFC 7405, DOI 10.17487/RFC7405, December 2014, 1589 . 1591 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1592 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1593 May 2017, . 1595 13.2. Informative References 1597 [ARC-DRAFT-05] 1598 Andersen, K., "Authenticated Received Chain (ARC) Protocol 1599 (I-D-05)", n.d., . 1602 [ARC-DRAFT-10] 1603 Andersen, K., "Authenticated Received Chain (ARC) Protocol 1604 (I-D-10)", n.d., . 1607 [ARC-DRAFT-13] 1608 Andersen, K., "Authenticated Received Chain (ARC) Protocol 1609 (I-D-13)", n.d., . 1612 [ARC-DRAFT-14] 1613 Andersen, K., "Authenticated Received Chain (ARC) Protocol 1614 (I-D-14)", n.d., . 1617 [ARC-MULTI] 1618 Andersen, K., "Using Multiple Signing Algorithms with 1619 ARC", June 2018, . 1622 [ARC-TEST] 1623 Blank, S., "ARC Test Suite", January 2017, 1624 . 1626 [ARC-USAGE] 1627 Jones, S., Adams, T., Rae-Grant, J., and K. Andersen, 1628 "Recommended Usage of the ARC Headers", April 2018, 1629 . 1632 [ENHANCED-STATUS] 1633 "IANA SMTP Enhanced Status Codes", n.d., 1634 . 1637 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 1638 Message Authentication, Reporting, and Conformance 1639 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 1640 . 1642 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1643 Code: The Implementation Status Section", BCP 205, 1644 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1645 . 1647 [RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky, 1648 E., Ed., and K. Andersen, Ed., "Interoperability Issues 1649 between Domain-based Message Authentication, Reporting, 1650 and Conformance (DMARC) and Indirect Email Flows", 1651 RFC 7960, DOI 10.17487/RFC7960, September 2016, 1652 . 1654 13.3. URIs 1656 [1] mailto:arc-discuss@dmarc.org 1658 [2] mailto:arc-discuss@dmarc.org 1660 [3] https://github.com/Valimail/arc_test_suite 1662 [4] mailto:arc-discuss@dmarc.org 1664 [5] mailto:openarc-users@openarc.org 1666 [6] mailto:dmarc@ietf.org 1668 [7] mailto:arc-discuss@dmarc.org 1670 [8] mailto:arc-interop@dmarc.org 1672 [9] https://arc-spec.org 1674 Appendix A. Design Requirements 1676 The specification of the ARC framework is driven by the following 1677 high-level goals, security considerations, and practical operational 1678 requirements. 1680 A.1. Primary Design Criteria 1682 o Provide a verifiable "chain of custody" for email messages; 1684 o Not require changes for originators of email; 1686 o Support the verification of the ARC header field set by each hop 1687 in the handling chain; 1689 o Work at Internet scale; and 1691 o Provide a trustable mechanism for the communication of 1692 Authentication-Results across trust boundaries. 1694 A.2. Out of Scope 1696 ARC is not a trust framework. Users of the ARC header fields are 1697 cautioned against making unsubstantiated conclusions when 1698 encountering a "broken" ARC sequence. 1700 Appendix B. Example Usage 1702 The following message is an example of one which has passed through 1703 several intermediary handlers, some of which have modified the 1704 message and others which have not: 1706 Return-Path: 1707 Received: from example.org (example.org [208.69.40.157]) 1708 by gmail.example with ESMTP id d200mr22663000ykb.93.1421363207 1709 for ; Thu, 14 Jan 2015 15:02:40 -0800 (PST) 1710 Received: from segv.d1.example (segv.d1.example [72.52.75.15]) 1711 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 1712 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) 1713 (envelope-from jqd@d1.example) 1714 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 1715 (authenticated bits=0) 1716 by segv.d1.example with ESMTP id t0FN4a8O084569; 1717 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 1718 (envelope-from jqd@d1.example) 1719 Received: from mail-ob0-f188.google.example (mail-ob0-f188.google.example 1720 [208.69.40.157]) by clochette.example.org with ESMTP id 1721 d200mr22663000ykb.93.1421363268 1722 for ; Thu, 14 Jan 2015 15:03:15 -0800 (PST) 1723 ARC-Seal: i=3; a=rsa-sha256; cv=pass; d=clochette.example.org; s= 1724 clochette; t=12345; b=CU87XzXlNlk5X/yW4l73UvPUcP9ivwYWxyBWcVrRs7 1725 +HPx3K05nJhny2fvymbReAmOA9GTH/y+k9kEc59hAKVg== 1726 ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed; d= 1727 clochette.example.org; h=message-id:date:from:to:subject; s= 1728 clochette; t=12345; bh=KWSe46TZKCcDbH4klJPo+tjk5LWJnVRlP5pvjXFZY 1729 LQ=; b=o71vwyLsK+Wm4cOSlirXoRwzEvi0vqIjd/2/GkYFYlSd/GGfKzkAgPqxf 1730 K7ccBMP7Zjb/mpeggswHjEMS8x5NQ== 1731 ARC-Authentication-Results: i=3; clochette.example.org; spf=fail 1732 smtp.from=jqd@d1.example; dkim=fail (512-bit key) 1733 header.i=@d1.example; dmarc=fail; arc=pass (as.2.gmail.example=pass, 1734 ams.2.gmail.example=pass, as.1.lists.example.org=pass, 1735 ams.1.lists.example.org=fail (message has been altered)) 1736 Authentication-Results: clochette.example.org; spf=fail 1737 smtp.from=jqd@d1.example; dkim=fail (512-bit key) 1738 header.i=@d1.example; dmarc=fail; arc=pass (as.2.gmail.example=pass, 1739 ams.2.gmail.example=pass, as.1.lists.example.org=pass, 1740 ams.1.lists.example.org=fail (message has been altered)) 1741 ARC-Seal: i=2; a=rsa-sha256; cv=pass; d=gmail.example; s=20120806; t= 1742 12345; b=Zpukh/kJL4Q7Kv391FKwTepgS56dgHIcdhhJZjsalhqkFIQQAJ4T9BE 1743 8jjLXWpRNuh81yqnT1/jHn086RwezGw== 1744 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d= 1745 gmail.example; h=message-id:date:from:to:subject; s=20120806; t= 1746 12345; bh=KWSe46TZKCcDbH4klJPo+tjk5LWJnVRlP5pvjXFZYLQ=; b=CVoG44 1747 cVZvoSs2mMig2wwqPaJ4OZS5XGMCegWqQs1wvRZJS894tJM0xO1RJLgCPsBOxdA5 1748 9WSqI9s9DfyKDfWg== 1749 ARC-Authentication-Results: i=2; gmail.example; spf=fail 1750 smtp.from=jqd@d1.example; dkim=fail (512-bit key) 1751 header.i=@example.org; dmarc=fail; arc=pass (as.1.lists.example.org=pass, 1752 ams.1.lists.example.org=pass) 1753 ARC-Seal: i=1; a=rsa-sha256; cv=none; d=lists.example.org; s=dk-lists; 1754 t=12345; b=TlCCKzgk3TrAa+G77gYYO8Fxk4q/Ml0biqduZJeOYh6+0zhwQ8u/ 1755 lHxLi21pxu347isLSuNtvIagIvAQna9a5A== 1757 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d= 1758 lists.example.org; h=message-id:date:from:to:subject; s= 1759 dk-lists; t=12345; bh=KWSe46TZKCcDbH4klJPo+tjk5LWJnVRlP5pvjXFZYL 1760 Q=; b=DsoD3n3hiwlrN1ma8IZQFgZx8EDO7Wah3hUjIEsYKuShRKYB4LwGUiKD5Y 1761 yHgcIwGHhSc/4+ewYqHMWDnuFxiQ== 1762 ARC-Authentication-Results: i=1; lists.example.org; spf=pass smtp.mfrom=jqd@d1.example; 1763 dkim=pass (512-bit key) header.i=@d1.example; 1764 dmarc=pass 1765 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=d1.example; h= 1766 message-id:date:from:to:subject; s=origin2015; bh=bIxxaeIQvmOBdT 1767 AitYfSNFgzPP4=; b=qKjd5fYibKXWWIcMKCgRYuo1vJ2fD+IAQPjX+uamXIGY2Q 1768 0HjQ+Lq3/yHzG3JHJp6780/nKQPOWt2UDJQrJkEA== 1769 Message-ID: <54B84785.1060301@d1.example> 1770 Date: Thu, 14 Jan 2015 15:00:01 -0800 1771 From: John Q Doe 1772 To: arc@dmarc.example 1773 Subject: [List 2] Example 1 1775 Hey gang, 1776 This is a test message. 1777 --J. 1779 Appendix C. Acknowledgements 1781 This draft originated with the work of OAR-Dev Group. 1783 The authors thank all of the OAR-Dev and the subsequent DMARC-WG 1784 group for the ongoing help and though-provoking discussions from all 1785 the participants, especially: Alex Brotman, Brandon Long, Dave 1786 Crocker, Elizabeth Zwicky, Franck Martin, Greg Colburn, J. Trent 1787 Adams, John Rae-Grant, Mike Hammer, Mike Jones, Steve Jones, Terry 1788 Zink, Tim Draegen, Gene Shuman, Scott Kitterman, Bron Gondwana. 1790 Grateful appreciation is extended to the people who provided feedback 1791 through the discuss mailing list. 1793 Appendix D. Comments and Feedback 1795 Please address all comments, discussions, and questions to 1796 dmarc@ietf.org [6]. Earlier discussions can be found at arc- 1797 discuss@dmarc.org [7]. Interop discussions planning can be found at 1798 arc-interop@dmarc.org [8]. 1800 Some introductory material for less technical people can be found at 1801 https://arc-spec.org [9]. 1803 Authors' Addresses 1805 Kurt Andersen 1806 LinkedIn 1807 1000 West Maude Ave 1808 Sunnyvale, California 94085 1809 USA 1811 Email: kurt+ietf@drkurt.com 1813 Brandon Long (editor) 1814 Google 1816 Email: blong@google.com 1818 Seth Blank (editor) 1819 Valimail 1821 Email: seth@valimail.com 1823 Murray Kucherawy (editor) 1824 TDP 1826 Email: superuser@gmail.com