idnits 2.17.1 draft-ietf-dmarc-arc-protocol-11.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 is 1 instance of too long lines in the document, the longest one being 1 character 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 (January 22, 2018) is 2286 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'CFWS' is mentioned on line 492, but not defined -- Looks like a reference, but probably isn't: '2' on line 1556 -- Looks like a reference, but probably isn't: '1' on line 1554 == Missing Reference: 'I-D.ARC' is mentioned on line 1340, but not defined -- Looks like a reference, but probably isn't: '3' on line 1558 -- Looks like a reference, but probably isn't: '4' on line 2435 -- Looks like a reference, but probably isn't: '5' on line 2436 == Unused Reference: 'RFC1345' is defined on line 1416, but no explicit reference was found in the text == Unused Reference: 'RFC2142' is defined on line 1425, but no explicit reference was found in the text == Unused Reference: 'RFC2606' is defined on line 1429, but no explicit reference was found in the text == Unused Reference: 'RFC4686' is defined on line 1437, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 1441, but no explicit reference was found in the text == Unused Reference: 'RFC5321' is defined on line 1451, but no explicit reference was found in the text == Unused Reference: 'RFC5322' is defined on line 1455, but no explicit reference was found in the text == Unused Reference: 'RFC5585' is defined on line 1459, but no explicit reference was found in the text == Unused Reference: 'RFC5863' is defined on line 1468, but no explicit reference was found in the text == Unused Reference: 'RFC6651' is defined on line 1483, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 7601 (Obsoleted by RFC 8601) == 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-06 -- Duplicate reference: draft-ietf-dmarc-arc-protocol, mentioned in 'ARC-DRAFT-06', was also mentioned in 'ARC-DRAFT-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-06'. == Outdated reference: A later version (-03) exists of draft-ietf-dmarc-arc-multi-01 == Outdated reference: A later version (-09) exists of draft-ietf-dmarc-arc-usage-01 -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) Summary: 3 errors (**), 0 flaws (~~), 18 warnings (==), 9 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: July 26, 2018 Google 6 S. Jones, Ed. 7 TDP 8 S. Blank, Ed. 9 ValiMail 10 M. Kucherawy, Ed. 11 TDP 12 January 22, 2018 14 Authenticated Received Chain (ARC) Protocol 15 draft-ietf-dmarc-arc-protocol-11 17 Abstract 19 The Authenticated Received Chain (ARC) protocol creates a mechanism 20 whereby a series of handlers of an email message can conduct 21 authentication of the email message as it passes among them on the 22 way to its destination, and record the status of that authentication 23 at each step along the handling path, for use by the final recipient 24 in making choices about the disposition of the message. Changes in 25 the message that might break DKIM or DMARC can be identified through 26 the ARC set of header fields. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on July 26, 2018. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Definitions and Terminology . . . . . . . . . . . . . . . . . 6 65 3.1. Referenced Definitions . . . . . . . . . . . . . . . . . 6 66 4. Protocol Elements and Features . . . . . . . . . . . . . . . 7 67 4.1. Features of the ARC Protocol . . . . . . . . . . . . . . 8 68 4.1.1. Chain of Custody . . . . . . . . . . . . . . . . . . 8 69 4.1.2. Optional Participation . . . . . . . . . . . . . . . 8 70 4.1.3. Only one ARC Chain (One Chain to Rule Them All) . . . 9 71 4.1.4. All Failures are Permanent . . . . . . . . . . . . . 9 72 4.1.5. Benign nature of an ARC Set . . . . . . . . . . . . . 9 73 4.1.6. Key Management . . . . . . . . . . . . . . . . . . . 9 74 4.1.7. Trace Information . . . . . . . . . . . . . . . . . . 10 75 4.1.8. Instance Tags . . . . . . . . . . . . . . . . . . . . 10 76 4.1.9. Chain Validation Status . . . . . . . . . . . . . . . 10 77 5. The ARC Header Fields . . . . . . . . . . . . . . . . . . . . 10 78 5.1. Instance ('i=') Tag . . . . . . . . . . . . . . . . . . . 10 79 5.1.1. Valid Range for Instance Tags . . . . . . . . . . . . 10 80 5.2. ARC-Authentication-Results (AAR) . . . . . . . . . . . . 11 81 5.2.1. ptypes and properties for arc-info . . . . . . . . . 11 82 5.3. ARC-Message-Signature (AMS) . . . . . . . . . . . . . . . 12 83 5.4. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . . . 12 84 5.4.1. The 'cv' Tag . . . . . . . . . . . . . . . . . . . . 13 85 5.4.2. Implicit Header Fields . . . . . . . . . . . . . . . 13 86 6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . 14 87 6.1. Handling DNS Problems While Validating ARC . . . . . . . 15 88 6.2. Responding to ARC Validity Violations During the SMTP 89 Transaction . . . . . . . . . . . . . . . . . . . . . . . 15 90 7. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . 16 91 7.1. Marking and Sealing "cv=fail" (Invalid) Chains . . . . . 16 92 8. Usage of ARC and Chain Validity . . . . . . . . . . . . . . . 16 93 8.1. Relationship between DKIM-Signature and AMS signing 94 scopes . . . . . . . . . . . . . . . . . . . . . . . . . 16 95 8.2. Assessing Chain Validity Violations . . . . . . . . . . . 17 96 9. Recording and Reporting the Results of ARC Evaluation . . . . 17 97 9.1. Information from an ARC Evaluation . . . . . . . . . . . 17 98 9.2. Recording (local) ARC Evaluation Results . . . . . . . . 18 99 9.3. DMARC Reporting of ARC Findings - Interim . . . . . . . . 18 100 10. Supporting Alternate Signing Algorithms . . . . . . . . . . . 19 101 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 102 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 103 12.1. Authentication-Results Method Registry Update . . . . . 19 104 12.2. Definitions of the ARC header fields . . . . . . . . . . 20 105 13. Security Considerations . . . . . . . . . . . . . . . . . . . 21 106 13.1. Header Size . . . . . . . . . . . . . . . . . . . . . . 21 107 13.2. DNS Operations . . . . . . . . . . . . . . . . . . . . . 21 108 13.3. Message Content Suspicion . . . . . . . . . . . . . . . 22 109 14. Evaluating the Efficacy of the ARC Protocol . . . . . . . . . 22 110 14.1. Success Consideration . . . . . . . . . . . . . . . . . 23 111 14.2. Failure Considerations . . . . . . . . . . . . . . . . . 23 112 14.3. Open Questions . . . . . . . . . . . . . . . . . . . . . 23 113 14.3.1. Value of the ARC-Seal (AS) Header . . . . . . . . . 23 114 14.3.2. DNS Overhead . . . . . . . . . . . . . . . . . . . . 23 115 14.3.3. Distinguishing Valuable from Worthless Trace 116 Information . . . . . . . . . . . . . . . . . . . . 24 117 15. Implementation Status . . . . . . . . . . . . . . . . . . . . 24 118 15.1. GMail test reflector and incoming validation . . . . . . 25 119 15.2. AOL test reflector and internal tagging . . . . . . . . 25 120 15.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 26 121 15.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . 26 122 15.5. Mailman 3.2 patch . . . . . . . . . . . . . . . . . . . 27 123 15.6. Copernica/MailerQ web-based validation . . . . . . . . . 27 124 15.7. Rspamd . . . . . . . . . . . . . . . . . . . . . . . . . 28 125 15.8. PERL MAIL::DKIM module . . . . . . . . . . . . . . . . . 28 126 15.9. PERL Mail::Milter::Authentication module . . . . . . . . 29 127 15.10. Sympa List Manager . . . . . . . . . . . . . . . . . . . 29 128 15.11. Oracle Messaging Server . . . . . . . . . . . . . . . . 30 129 15.12. MessageSystems Momentum . . . . . . . . . . . . . . . . 30 130 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 131 16.1. Normative References . . . . . . . . . . . . . . . . . . 30 132 16.2. Informative References . . . . . . . . . . . . . . . . . 32 133 16.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 33 134 Appendix A. Appendix A - Design Requirements . . . . . . . . . . 34 135 A.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 34 136 A.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 34 137 Appendix B. Appendix B - Example Usage . . . . . . . . . . . . . 34 138 B.1. Example 1: Simple mailing list . . . . . . . . . . . . . 34 139 B.1.1. Here's the message as it exits the Origin: . . . . . 34 140 B.1.2. Message is then received at example.org . . . . . . . 35 141 B.1.3. Example 1: Message received by Recipient . . . . . . 37 142 B.2. Example 2: Mailing list to forwarded mailbox . . . . . . 38 143 B.2.1. Here's the message as it exits the Origin: . . . . . 38 144 B.2.2. Message is then received at example.org . . . . . . . 39 145 B.2.3. Example 2: Message received by Recipient . . . . . . 43 146 B.3. Example 3: Mailing list to forwarded mailbox with source 45 147 B.3.1. Here's the message as it exits the Origin: . . . . . 45 148 B.3.2. Message is then received at example.org . . . . . . . 46 149 B.3.3. Example 3: Message received by Recipient . . . . . . 51 150 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 53 151 Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 54 152 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 154 1. Introduction 156 Modern email authentication techniques such as the Sender Policy 157 Framework (SPF) [RFC7208] and DomainKeys Identified Mail (DKIM) 158 [RFC6376] have become common. 159 However, their end-to-end utility is limited by the effects of 160 intermediaries along the transmission path, which either are not 161 listed (for SPF) or which break digital signatures (for DKIM). These 162 issues are described in substantial detail in those protocols' 163 defining documents as well as in [RFC6377] and [RFC7960]. 165 Technologies that build upon the use of SPF and DKIM can reduce the 166 success of fraudulent email campaigns. To this end, Domain-based 167 Mail Authentication, Reporting and Compliance (DMARC) [RFC7489], 168 validates the domain of the RFC5322.From author header field. 169 However its use along email transmission paths that have independent 170 intermediaries, such as some forwarders and essentially all mailing 171 list services, produces false positive rejections that are 172 problematic, both for the message authors, the intermediary 173 service(s), and for those they are interacting with. 175 What is needed is a mechanism by which legitimate alteration of a 176 message, which invalidates associated SPF and DKIM information, does 177 not ultimately result in a rejection of an email message on delivery. 178 Authenticated Receive Chain (ARC) builds upon DKIM mechanisms to 179 provide a sequence of signatures that are more survivable than DKIM's 180 and that provide a view of the handling sequence for a message, 181 especially the points where alterations of the content might have 182 occurred. Equipped with this more complete information, the 183 recipient system(s) can make a more informed handling choice, 184 reducing or eliminating the false negatives inherent in use of DKIM 185 and/or SPF themselves. 187 2. Overview 189 In DKIM, every participating signing agent attaches a signature that 190 is based on the some of the content of the message, local policy, and 191 the domain name of the participating Administrative Management Domain 192 (ADMD). Any verifier can process such a signature; a verified 193 signature means that the domain referenced in the DKIM-Signture's 194 "d=" parameter has some responsibility for handling the message. An 195 artifact of using digital signature technology for this means that 196 verification also ensures that the message content that was "covered" 197 by the signature has not been altered since the signature was 198 applied. The signatures themselves are generally independent of one 199 another. 201 By contrast, an ARC signature conveys the following pieces of 202 information: 204 1. An assertion that, at the time that the intermediary ADMD 205 processed the message, the various assertions (DKIM-Signature(s) 206 and/or ARC sets) already attached to the message by other ADMDs 207 were or were not valid; 209 2. As with DKIM, an assertion that, for a validated signature, the 210 domain name in the signature takes some responsibility for 211 handling of the message and that the message is unchanged since 212 that signature was applied; 214 3. A further assertion that binds the ARC evaluation results into 215 the ARC chain sequence. 217 This protocol accomplishes each of these by adding a new header field 218 to the message for each of these pieces of information, as follows: 220 o ARC-Authentication-Results (referred to below as "AAR"): virtually 221 identical in syntax to an Authentication-Results field [RFC7601], 222 this field records the results of all message authentication 223 checks done by the recording ADMD at the time the message arrived. 224 Additional information is placed in this field compared to a 225 standard Authentication-Results field in order to support a more 226 complete DMARC report (see Section 5.2); 228 o ARC-Message-Signature (referred to below as "AMS"): virtually 229 identical in syntax to DKIM-Signature, this field contains the 230 signature about the message header and body as they existed at the 231 time of handling by the ADMD adding it; and 233 o ARC-Seal (referred to below as "AS"): highly similar in structure 234 and format to a DKIM-Signature, this field applies a digital 235 signature that protects the integrity of all three of these new 236 fields when they are added by an ADMD, plus all instances of these 237 fields added by prior ADMDs. 239 A distinguishing feature of all of these is that an ARC participant 240 always adds all of them before relaying a message to the next 241 handling agent en route to its destination. Moreover, as described 242 in Section 5.1, they each have an "instance" number that increases 243 with each ADMD in the handling chain so that their original order can 244 be preserved and the three related header fields can be processed as 245 a group. 247 3. Definitions and Terminology 249 This section defines terms used in the rest of the document. 251 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 252 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 253 document are to be interpreted as described in [RFC2119]. 255 Because many of the core concepts and definitions are found in 256 [RFC5598], readers SHOULD to be familiar with the contents of 257 [RFC5598], and in particular, the potential roles of intermediaries 258 in the delivery of email. 260 Syntax descriptions use Augmented BNF (ABNF) [RFC5234]. 262 o "ARC set" - A single group of the header fields introduced in 263 Section 2 is called an "ARC set". 265 o "ARC chain" - The complete sequence of these groups (ARC sets) is 266 called an "Authenticated Received Chain" or merely an "ARC chain". 267 Although the "Received" header field is typically not included in 268 the signed content, the name is based on the notion that this is 269 in essence a cryptographically signed series of header fields that 270 attest to the handling chain of a message much as Received fields 271 always have. 273 3.1. Referenced Definitions 275 The following terms are defined in other RFCs. Those definitions can 276 be found as follows: 278 o ADMD - [RFC5598], Section 2.3 280 o MTA - [RFC5598], Section 4.3.2 282 o MSA - [RFC5598], Section 4.3.1 283 o MDA - [RFC5598], Section 4.3.3 285 The three header fields that are part of this specification borrow 286 heavily from existing specifications. Rather than repeating all of 287 the formal definitions that are being reused in ARC, this document 288 only describes and specifies changes in syntax and semantics. 290 Language, syntax, and other details are imported from DKIM [RFC6376]. 291 Specific references can be found below. 293 4. Protocol Elements and Features 295 As with other domain authentication technologies (such as SPF, DKIM, 296 and DMARC), ARC makes no claims about the contents of the email 297 message it has sealed. However, for a valid and passing ARC chain, a 298 Final Receiver is able to ascertain: 300 o all (participating) domains that claim responsibility for handling 301 (and possibly) modifying the email message in transit; 303 o trace information, including: 305 * the [RFC7601] authentication results each participating ADMD 306 saw; and 308 * additional data needed to compile a DMARC report for the 309 sending domain. 311 Given this information, a Final Receiver is able to make a more- 312 informed local policy decision regarding message delivery to the end 313 user in spite of a DMARC failure. 315 Every participant in an ARC chain, except for the originating sender 316 and Final Receiver, is both an ARC Validator (when receiving) and 317 then an ARC Sealer (when sending a message onward). The validated 318 chain status as determined at message receipt must be passed to the 319 sealer function in order for sealing to occur properly; how this is 320 done is considered ADMD-specific and an implementation detail. 322 _INFORMATIONAL_: It is important to understand that validating and 323 then immediately sealing a message leaves no room for message 324 modification, and many early implementations of ARC did not initially 325 work because both operations were performed in a single pass over the 326 message. 328 4.1. Features of the ARC Protocol 330 The following protocol features are functional parts and design 331 decisions related the protocol that are not specific to either 332 Validators or Sealers, but ensure the ARC chain conveys this 333 information to a Final Receiver. 335 4.1.1. Chain of Custody 337 At a high level, an ARC chain represents a chain of custody of 338 authentication and other trace information (AAR) related to a 339 message, signed by each handler of the message. Each link in the 340 chain (AMS) is designed to be brittle, insofar as it survives only 341 until the next modification of the message. However, the sequence of 342 intermediaries in the handling chain (AS) is designed to remain 343 intact over the entirety of the chain. 345 The ARC chain can be conceptualized through an analogy with the chain 346 of custody for legal evidence. The material evidence itself is 347 sealed within an tamper-proof bag (AMS) each time. When handed to a 348 new party, that party both vouches for the state of the received 349 evidence container (AAR) and signs for the evidence on a chain of 350 custody report form (AS). As with all analogies, this one should not 351 be taken to interpretive extremes, but primarily used as a conceptual 352 framework. 354 An ARC chain that is valid and passing has the attributes listed 355 above in Section 4. 357 Recipients of an ARC chain that is invalid or does not pass SHOULD 358 NOT draw negative conclusions without a good understanding of the 359 wider handling context. Until ARC usage is widespread, 360 intermediaries will continue to modify messages without ARC seals. 361 As with a failing DKIM signature ([RFC6376] Section-6.3), a failing 362 ARC chain SHOULD be treated the same as a message with no ARC chain. 363 [[ NOTE TO WORKING GROUP: This paragraph probably is better placed in 364 Verifier actions. ]] 366 4.1.2. Optional Participation 368 Validating an existing chain and then adding your own ARC set to a 369 message allows you to claim responsibility for hanndling the message 370 and modifications, if any, done by your ADMD to benefit message 371 delivery downstream. However, no ADMD is obligated to perform these 372 actions. 374 4.1.3. Only one ARC Chain (One Chain to Rule Them All) 376 A message can have only one ARC chain on it at a time (see 377 Section 5.1). Once broken, the chain cannot be restarted, as the 378 chain of custody is no longer valid and responsibility for the 379 message has been lost. 381 4.1.4. All Failures are Permanent 383 Because ARC chains are transmitted across multiple intermediaries, 384 all errors, even temporary ones, become unrecoverable and are 385 considered permanent. 387 Any error validating or sealing a chain, for whatever reason, MUST 388 result in a "cv=fail" verdict. 390 4.1.5. Benign nature of an ARC Set 392 Even when an ARC chain is valid and passes, its value is limited to 393 very specific cases. An ARC chain is specifically designed to 394 provide value to a Final Receiver evaluating message delivery in the 395 context of a DMARC failure. An ARC chain in general, and each ARC 396 set in particular, provide additional information, and otherwise is 397 benign. Specifically: 399 o properly adding an ARC set to a message does not damage or 400 invalidate an existing chain, and 402 o validating a message exposes no new threat vectors (see 403 Section 13). 405 _INFORMATIONAL_: If an ADMD is unsure whether it will be re-emitting 406 and/or modifying a message, it may elect to seal all inbound mail. 407 For complex or nested ADMD relationships such as found in some hosted 408 mail solutions, this "inbound seal" can be used to facilitate 409 traversal of internal boundaries as well as properly conveying 410 incoming state to any egress MTAs that may need to assert a seal upon 411 exit from the ADMD. Since these internal relationships are highly 412 implementation dependent, this protocol definition can not usefully 413 explore such usage except to note that it is intentionally allowed 414 within the scope of this specification. 416 4.1.6. Key Management 418 The public keys for ARC header fields follow the same requirements, 419 syntax and semantics as those for DKIM signatures, described in 420 Section 3.6 of [RFC6376]. ARC places no requirements on the 421 selectors and/or domains used for the ARC header field signatures. 423 4.1.7. Trace Information 425 ARC includes trace information encoded in the AAR. While section 426 Section 5.2 defines what information must be provided, sealing ADMDs 427 may provide additional information, and validating receivers may use 428 or ignore this trace information as they wish. 430 4.1.8. Instance Tags 432 See section Section 5.1 434 4.1.9. Chain Validation Status 436 See section Section 5.4.1 438 5. The ARC Header Fields 440 5.1. Instance ('i=') Tag 442 The header fields comprising a single ARC set are identified by the 443 presence of a string in the value portion of the header field that 444 complies with the "tag-spec" ABNF found in Section 3.2 of [RFC6376]. 445 The tag-name is "i" and the value is the text representation of a 446 positive integer, indicating the position in the ARC sequence this 447 set occupies, where the first ARC set is numbered 1. In ABNF terms: 449 instance = [FWS] %x69 [FWS] "=" [FWS] position [FWS] ";" 450 position = 1*2DIGIT ; 1 - 50 452 Valid ARC sets must have exactly one instance of each header field 453 for a given position value and signing algorithm. (Initial 454 development of ARC is only being done with a single allowed signing 455 algorithm, but parallel work in the DCRUP working group 456 (https://datatracker.ietf.org/wg/dcrup/about/) is expanding that. 457 For handling multiple signing algorithms, see [ARC-MULTI].) 459 Because the AMS and AS header field values are made up of tag-spec 460 constructs, the i= tag may be found anywhere within the header field 461 value, but is represented throughout this spec in the initial 462 position for convenience. Implementers are encouraged to place the 463 i= tag at the beginning of the field value to facilitate human 464 inspection of the headers. 466 5.1.1. Valid Range for Instance Tags 468 The 'i' tag value can range from 1-50 (inclusive). 470 ARC implementations MUST support at least ten (10) ARC sets. 472 An effective operational maximum will have to be developed through 473 deployment experience in the field and will be documented within 474 [ARC-USAGE] once determined. 476 ARC chains with more than the defined operational maximum count MUST 477 be marked with "cv=fail". 479 5.2. ARC-Authentication-Results (AAR) 481 The ARC-Authentication-Results header field is syntactically and 482 semantically identical to an Authentication-Results header field 483 (defined in Section 2.2 of [RFC7601] (A-R)), except that several 484 optional data fields SHOULD be added. ([[ NOTE: these optional data 485 fields are being proposed as amendments to [RFC7601] through a "bis" 486 process. Depending on the sequencing for this specification and said 487 "7601bis" work, it may be possible to drop the noted sections from 488 this specification. ]]) The first element ("Authentication-Results:") 489 in authres-header is replaced with arc-authres-prefix as follows: 491 arc-authres-header-prefix = "ARC-Authentication-Results:" [CFWS] arc-info 492 arc-info = instance *([CFWS] propspec) [CFWS] ";" 494 The purpose of this header field is to transmit the results of any 495 authentication done on the message upstream to participating ADMDs 496 validating and continuing the chain. 498 The AAR MUST contain all A-R results from within the participating 499 ADMD, regardless of how many A-R headers are on the message. 501 5.2.1. ptypes and properties for arc-info 503 [[ NOTE: This section is being proposed as an amendment to [RFC7601] 504 through a "bis" process. Depending on the sequencing for this 505 specification and said "7601bis" work, it may be possible to this 506 section from this specification. ]] 508 Certain information pertinent to ascertaining message disposition can 509 be lost in transit when messages are handled by intermediaries. For 510 example, failing DKIM signatures are sometimes removed by MTAs, and 511 most DKIM signatures on messages modified by intermediaries will 512 fail. 514 The AAR, through these ptype-properties stamped in arc-info, provide 515 a mechanism for this information to survive transit. 517 The ptypes and properties defined in this section SHOULD be stamped 518 in the AAR: 520 o smtp.client-ip - The connecting client IP address from which the 521 message is received; 523 o header.s - Defined in [RFC6376] section 7.2 525 o arc.oldest-pass - The instance number of the oldest AMS that still 526 validates, or 0 if all pass. 528 5.3. ARC-Message-Signature (AMS) 530 The ARC-Message-Signature header field is syntactically and 531 semantically identical to a DKIM-Signature header field [RFC6376], 532 with the following exceptions: 534 o There is an "i" tag, as described in Section 5.1. 536 o There is no "v" tag. 538 ARC-Seal header fields MUST NOT be included in the content covered by 539 the signature in this header field. 541 The AMS SHOULD include any DKIM-Signature header fields already 542 present on the message in the header fields covered by this 543 signature. 545 The AMS header field MAY include (sign) the AAR header field(s). 547 Authentication-Results header fields SHOULD NOT be included since 548 they are likely to be deleted by downstream ADMDs (per Section XXX of 549 [RFC7601]), thereby breaking the AMS signature. 551 As with a DKIM-Signature, the purpose of this header field is to 552 allow the ADMD generating it to take some responsibility for handling 553 this message as it progresses toward delivery. 555 5.4. ARC-Seal (AS) 557 The ARC-Seal header field is syntactically and semantically similar 558 to a DKIM-Signature field, with the following exceptions: 560 o There is an "i" tag, as described in Section 5.1. 562 o The ARC-Seal covers none of the body content of the message. It 563 only covers specific header fields. (See below: Section 5.4.2.) 564 As a result, no body canonicalization is done. Further, only 565 "relaxed" header canonicalization (Section 3.4.2 of [RFC6376]) is 566 used. 568 o The only supported tags are "i" (Section 5.1 supercedes the 569 [RFC6376] definition), and "a", "b", "d, "s", "t". The latter 5 570 tag definitions are copied from Section 3.5 of [RFC6376]. 572 o An additional tag, "cv" is defined. (See below: Section 5.4.1) 574 5.4.1. The 'cv' Tag 576 A new tag "cv" (chain validation) indicates the the outcome of 577 evaluating the existing ARC chain upon arrival at the ADMD that is 578 adding this header field. It accepts one of three possible values: 580 o none: There was no chain on the message when it arrived for 581 validation; typically occurs when the message arrives at a Message 582 Transfer Agent (MTA) from a Message Submission Agent (MSA) or when 583 any upstream MTAs may not be participating in ARC handling; 585 o fail: The message has a chain whose validation failed; 587 o pass: The message has a chain whose validation succeeded. 589 In ABNF terms: 591 seal-cv-tag = %x63.76 [FWS] "=" [FWS] ("none" / "fail" / "pass") 593 5.4.2. Implicit Header Fields 595 The ARC-Seal signs a canonicalized form of the ARC set header values. 596 The ARC set header values are compiled in increasing instance order, 597 starting at 1, and inclue the set being added at the time of sealing 598 the message. 600 Within a set, the header fields are listed in the following order: 602 1. ARC-Authentication-Results 604 2. ARC-Message-Signature 606 3. ARC-Seal 608 Where the ARC-Seal is the one being generated, it is input to the 609 hash function in its final form except with an empty "b=" value, in 610 the same manner by which a DKIM-Signature signs itself. 612 Note that the signing scope for the ARC-Seal is modified in the 613 situation where a chain has failed validation (see Section 7.1). 615 6. Verifier Actions 617 A verifier takes the following steps to determine the state of the 618 ARC chain on a message (cv value). Canonicalization, hash functions, 619 and signature validation methods are imported from Section 5 of 620 [RFC6376]. 622 [[ Note: need markdown flag to have subordinate numbering distinction 623 ]] 625 1. Collect all ARC sets currently on the message. If there were 626 none, the ARC state is "none" and the algorithm stops here. 628 2. If the form of any ARC set is invalid (e.g., does not contain 629 exactly one of each of the three ARC-specific header fields), 630 then the chain state is "fail" and the algorithm stops here. 632 1. To avoid the overhead of unnecessary computation and delay 633 from crypto and DNS operations, the cv value for all ARC- 634 Seal(s) MAY be checked at this point. If any of the values 635 are "fail", then the overall state of the chain is "fail" and 636 the algorithm stops here. 638 3. Conduct verification of the ARC-Message-Signature header field 639 bearing the highest instance number. If this verification fails, 640 then the chain state is "fail" and the algorithm stops here. 642 4. For each ARC-Seal from the "N"th instance to the first, apply the 643 following logic: 645 1. If the value of the "cv" tag on that seal is "fail", the 646 chain state is "fail" and the algorithm stops here. (This 647 step SHOULD be skipped if the earlier step (2.1) was 648 performed) 650 2. In Boolean nomenclature: if ((i == 1 && cv != "none") or (cv 651 == "none" && i != 1)) then the chain state is "fail" and the 652 algorithm stops here (note that the ordering of the logic is 653 structured for short-circuit evaluation). 655 3. Initialize a hash function corresponding to the "a" tag of 656 the ARC-Seal. 658 4. Compute the canonicalized form of the ARC header fields, in 659 the order described in Section 5.4.2, using the "relaxed" 660 header canonicalization defined in Section 3.4.2 of 661 [RFC6376]. Pass the canonicalized result to the hash 662 function. 664 5. Retrieve the final digest from the hash function. 666 6. Retrieve the public key identified by the "s" and "d" tags in 667 the ARC-Seal, as described in Section 4.1.6. 669 7. Determine whether the signature portion ("b" tag) of the ARC- 670 Seal and the digest computed above are valid according to the 671 public key. (See also Section Section 6.1 for failure case 672 handling) 674 8. If the signature is not valid, the chain state is "fail" and 675 the algorithm stops here. 677 5. If all seals pass validation, then the chain state is "pass", and 678 the algorithm is complete. 680 [[ Note from Dave: possibly delete the following paragraph as it is 681 more usage/procedural than specification guidance. 683 KA: It was added to clarify the separation of the verification and 684 signing steps as some of the initial implementations failed to 685 realize that they were not necessarily done in one fell swoop. 687 KA (v-10): With the addition of the {protocol-elements} section, does 688 the WG think that this can be reasonably removed from this location? 689 ]] 691 The verifier should save the cv state for subsequent use by any 692 sealing which may be done later (potentially after message 693 modification) within the same trust boundary. The cv state may be 694 recorded by sealing at the time of verification in an initial ARC set 695 (for the ADMD) or may be recorded out of band depending on the 696 architecture of the ADMD. 698 6.1. Handling DNS Problems While Validating ARC 700 DNS-based failures to verify a chain are treated no differently than 701 any other ARC violation. They result in a "cv=fail" verdict. 703 6.2. Responding to ARC Validity Violations During the SMTP Transaction 705 If a receiver determines that the ARC chain has failed, the receiver 706 MAY signal the breakage through the extended SMTP response code 5.7.7 707 [RFC3463] "message integrity failure" [ENHANCED-STATUS] and 708 corresponding SMTP response code. 710 7. Signer Actions 712 [[ Note from Dave: This seems more like implementation guidance than 713 specification detail. KA: see explanation just above referring to 714 the previous note. ]] 716 This section includes a specification of the actions an ARC signer 717 takes when presented with a message. 719 The signer MUST undertake the following steps: 721 1. Before creating an ARC signature, perform any other, normal 722 authentication and/or signing, so that the ARC signature can 723 cover those results. 725 2. Build and attach the new ARC set: 727 1. If an ARC chain exists on the message, then set "N" equal to 728 the highest instance number found on the chain (i=); 729 otherwise set "N" equal to zero for the following steps. 731 2. Generate and attach to the message an ARC-Authentication- 732 Results header field using instance number N+1 and the same 733 content from the previous step. 735 3. Generate and attach to the message an ARC-Message-Signature 736 header field as defined in Section 5.3 above, using instance 737 number N+1. 739 4. Generate and attach to the message an ARC-Seal header field 740 using the general algorithm described in Section 5.4 above, 741 the chain validation status as determined in Section 6, and 742 instance number N+1. 744 7.1. Marking and Sealing "cv=fail" (Invalid) Chains 746 The header fields signed by the AS header field b= value in the case 747 of a chain failure MUST be only the matching 'i=' instance headers 748 created by the MTA which detected the malformed chain, as if this 749 newest ARC set was the only set present. 751 8. Usage of ARC and Chain Validity 753 8.1. Relationship between DKIM-Signature and AMS signing scopes 755 [[ SB-11: replace with "ARC MUST be the last signer of the message; 756 otherwise it cannot be validated on receipt." in the signer actions 757 section. KA: Concern that this still does not address the risk of 758 DKIM-Signatures covering ARC chains. This does not seem like it fits 759 in this section but it needs to go somewhere. ]] 761 DKIM-Signatures SHOULD never sign any ARC header fields. 763 [[ KA: Response to Dave's concern: If DKIM covers ARC and ARC covers 764 DKIM, which comes first? The chicken or the egg? I'm open to 765 alternate ways to phrase this without opening the "modifying the DKIM 766 spec" can of worms. ]] 768 8.2. Assessing Chain Validity Violations 770 [[ SB-11: move to protocol elements 772 KA: This seems a bit banal. I suspect that what receivers want is a 773 section on using ARC to override DMARC failures. Would that be to 774 brazen to insert here instead? Or do we relegate that to the 775 [ARC-USAGE] doc? ]] 777 Email transit can produce broken signatures for a wide variety of 778 benign reasons. This includes possibly breaking one or more ARC 779 signatures. Therefore, receivers need to be wary of ascribing motive 780 to such breakage although patterns of common behaviour may provide 781 some basis for adjusting local policy decisions. 783 ARC does not attempt to protect an entire message. There are various 784 ways that a message can still be problematic, in spite of having a 785 valid ARC chain. Consequently, all normal, content-based analysis 786 SHOULD still be performed on any message having a valid chain of ARC 787 header sets. 789 9. Recording and Reporting the Results of ARC Evaluation 791 The evaluation of an ARC chain provides information which will be 792 useful to both the receiver (or intermediary) and to the initial 793 sender of the message. This information should be preserved and 794 reported as follows. 796 9.1. Information from an ARC Evaluation 798 The evaluation of an ARC chain produces a list of domain names for 799 participating intermediaries which handled the message, to wit: 801 o A list of the "d=" domains found in the validated ARC-Seal header 802 fields 804 o The "d=" domain found in the most recent (highest instance number) 805 AMS header field (since that is the only one necessarily 806 validated) 808 In the case of a failed chain, only the terminal ARC set is covered 809 by the ARC-Seal so the reporting is limited to the findings in that 810 terminal ARC set. 812 9.2. Recording (local) ARC Evaluation Results 814 Receivers MAY add an "arc=[pass|fail|policy]" method annotation into 815 a locally-affixed Authentication-Results [RFC7601] header field along 816 with any salient comment(s). 818 Details of the ARC chain which was evaluated should be included in 819 the Authentication-Results and AAR headers per Section Section 5.2.1. 821 9.3. DMARC Reporting of ARC Findings - Interim 823 [[ Note: Discussion on the IETF DMARC-WG list has indicated some 824 interest in more substantial reporting for analytic purposes. To 825 support that effort, the following guidance is provided only as an 826 interim, minimal data set. A more complete reporting construct will 827 be specified in a related spec - TBD. (see the additional fields 828 specified in Section 5.2.1) ]] 830 Receivers SHOULD indicate situations in which ARC evaluation 831 influenced the results of their local policy determination. DMARC 832 reporting of ARC-informed decisions can be accomplished by adding a 833 local_policy comment explanation containing the list of data 834 discovered in the ARC evaluation (Section 9.1 and Section 5.2.1): 836 837 delivered 838 fail 839 fail source.ip=10.0.0.1 840 841 local_policy 842 arc=pass ams[2].d=d2.example ams[2].s=s1 as[2].d=d2.example 843 as[2].s=s2 as[1].d=d1.example as[1].s=s3 844 845 847 In the suggested sample, d2.example is the sealing domain for ARC[2] 848 and d1.example is the sealing domain for ARC[1]. 850 Mediators SHOULD generate DMARC reports on messages which transit 851 their system just like any other message which they receive. This 852 will result in multiple reports for each mediated message as they 853 transit the series of handlers. DMARC report consumers should be 854 aware of this behaviour and make the necessary accommodations. 856 10. Supporting Alternate Signing Algorithms 858 This section has been moved to [ARC-MULTI] 860 11. Privacy Considerations 862 The ARC chain provides a verifiable record of the handlers for a 863 message. Anonymous remailers will probably not find this compatible 864 with their operating goals. 866 12. IANA Considerations 868 This specification adds three new header fields as defined below. 870 12.1. Authentication-Results Method Registry Update 872 This draft adds one item to the IANA "Email Authentication Methods" 873 registry: 875 o Method : arc 877 Defined: [I-D.ARC] 879 ptype: header 881 Property: chain evaluation result 883 Value: chain evaluation result status (see Section 5.4) 885 Status: active 887 Version: 1 889 o Method : dkim 891 Defined: [I-D.ARC] 893 ptype: header 895 Property: selector 897 Value: value of signature "s" tag (see [RFC6376]) 899 Status: active 900 Version: 1 902 o Method : spf 904 Defined: [I-D.ARC] 906 ptype: smtp 908 Property: client-ip 910 Value: the connecting client IP address from which the message is 911 received 913 Status: active 915 Version: 1 917 o Method : arc 919 Defined: [I-D.ARC] 921 ptype: header 923 Property: oldest-pass 925 Value: the oldest instance with a still validating AMS signature 927 Status: active 929 Version: 1 931 12.2. Definitions of the ARC header fields 933 This specification adds three new header fields to the "Permanent 934 Message Header Field Registry", as follows: 936 o Header field name: ARC-Seal 938 Applicable protocol: mail 940 Status: draft 942 Author/Change controller: IETF 944 Specification document(s): [I-D.ARC] 946 Related information: [RFC6376] 948 o Header field name: ARC-Message-Signature 950 Applicable protocol: mail 952 Status: draft 954 Author/Change controller: IETF 956 Specification document(s): [I-D.ARC] 958 Related information: [RFC6376] 960 o Header field name: ARC-Authentication-Results 962 Applicable protocol: mail 964 Status: standard 966 Author/Change controller: IETF 968 Specification document(s): [I-D.ARC] 970 Related information: [RFC7601] 972 13. Security Considerations 974 The Security Considerations of [RFC6376] and [RFC7601] apply directly 975 to this specification. 977 13.1. Header Size 979 Inclusion of ARC sets in the header of emails may cause problems for 980 some older or more constrained MTAs if they are unable to accept the 981 greater size of the header. 983 13.2. DNS Operations 985 Operators who receive a message bearing N ARC sets have to complete 986 up to N+1 DNS queries to evaluate the chain (barring DNS redirection 987 mechanisms which can increase the lookups for a given target value). 988 This has at least two effects: 990 1. An attacker can send a message to an ARC partipant with a 991 concocted sequence of ARC sets bearing the domains of intended 992 victims, and all of them will be queried by the participant until 993 a failure is discovered. The difficulty of forging the signature 994 values should limit the extent of this load to domains under 995 control of the attacker. 997 2. DKIM only does one DNS check per signature, while this one can do 998 many (per chain). Absent caching, slow DNS responses can cause 999 SMTP timeouts; and backlogged delivery queues on mediating 1000 systems. This could be exploited as a DoS attack. 1002 13.3. Message Content Suspicion 1004 Recipients are cautioned to treat messages bearing ARC sets with the 1005 same suspicion that they apply to all other email messages. This 1006 includes appropriate content scanning and other checks for 1007 potentially malicious content. The handlers which are identified 1008 within the ARC chain may be used to provide input to local policy 1009 engines in cases where DMARC validation fails (due to mediation 1010 impacting SPF attribution, DKIM validity or alignment). 1012 Note that a passing ARC chain may not adequately mean that the 1013 message is safe because: 1015 1. You have to trust all signatories; and 1017 2. Even trusted systems may have become compromised or may not 1018 properly authenticate messages, so even with a chain of trusted 1019 participants, the message might still never have authenticated in 1020 the first place (which is why you have the AAR to inspect) or 1021 could have been subject to unintended modifications. 1023 14. Evaluating the Efficacy of the ARC Protocol 1025 The ARC protocol is designed to mitigate some of the most common 1026 failure conditions for email which transits intermediary handlers en 1027 route to the final recipient. Some of these problems have happened 1028 due to the adoption of the DMARC protocol [RFC7489] and are listed in 1029 [RFC6377] and [RFC7960]. 1031 As the ARC protocol becomes standardized and implemented amongst 1032 intermediary handlers, the following aspects should be evaluated in 1033 order to determine the success of the protocol in accomplishing the 1034 intended benefits. 1036 NOTE: Terminology within this section does NOT follow [RFC2119] 1037 interpretation. This section represents the current thoughts of the 1038 working group regarding unanswered questions related to the protocol. 1039 Wider deployment will inform these topics and probably expand them. 1041 14.1. Success Consideration 1043 Currently, many receivers have heuristically determined overrides in 1044 order to rescue mail from intermediary-caused failures. Many of 1045 those overrides rely on inferrence rather than direct evidence. 1047 ARC will be a success if, for ARC sealed messages, receivers are able 1048 to implment ARC-based algorithmic decisions based on the direct 1049 evidence found within the ARC chain. This is especially relevant for 1050 DMARC processing when the DKIM d= value is aligned with the 1051 rfc5322.From author domain. 1053 14.2. Failure Considerations 1055 The intent of ARC is to be at most value-add and at worst benign. If 1056 ARC opens up significant new vectors for abuse (see Section 13) then 1057 this protocol will be a failure. Note that weaknesses inherent in 1058 the mail protocols ARC is built upon (such as DKIM replay attacks and 1059 other known issues) are not new vectors which can be attributed to 1060 this specification. 1062 14.3. Open Questions 1064 The following open questions are academic and have no clear answer at 1065 the time of the development of the protocol. However, wide-spread 1066 deployment should be able to gather the necessary data to answer some 1067 or all of them. 1069 14.3.1. Value of the ARC-Seal (AS) Header 1071 Data should be collected to show if the ARC-Seal (AS) provides value 1072 beyond the ARC Message Signature (AMS) for either making delivery 1073 decisions or catching malicious actors trying to craft or replay 1074 malicious chains. 1076 14.3.2. DNS Overhead 1078 Longer ARC chains will require more queries to retrieve the keys for 1079 validating the chain. While this is not believed to be a security 1080 issue (see Section 13.2), it is unclear how much overhead will truly 1081 be added. This is similar to some of the initial processing and 1082 query load concerns which were debated at the time of the DKIM 1083 specification development. 1085 Data should be collected to better understand usable length and 1086 distribution of lengths found in valid ARC chains along with the the 1087 DNS impact of processing ARC chains. 1089 14.3.3. Distinguishing Valuable from Worthless Trace Information 1091 There are several edge cases where the information in the AAR can 1092 make the difference between message delivery or rejection. For 1093 example, if there is a well known mailing list that ARC seals but 1094 doesn't do its own initial DMARC enforcement, a Final Receiver with 1095 this knowledge could make a delivery decision based upon the 1096 authentication information it sees in the corresponding AAR header. 1098 Certain trace information in the AAR is useful/necessary in the 1099 construction of DMARC reports. It would be beneficial to identify 1100 the value-add of having intermediary-handled mail flow information 1101 added into the DMARC reports going back to senders. 1103 Certain receivers believe the entire set of trace information would 1104 be valuable to feed into machine learning systems to identify fraud 1105 and/or provide other signals related to message delivery. 1107 It is unclear what trace information will be valuable for all 1108 receivers, regardless of size. 1110 Data should be collected on what trace information receivers are 1111 using that provides useful signals that affect deliverability, and 1112 what portions of the trace data are left untouched or provide no 1113 useful information. 1115 Since many such systems are intentionly proprietary or confidential 1116 to prevent gaming by abusers, it may not be viable to reliably answer 1117 this particular question. The evolving nature of attacks can also 1118 shift the landscape of "useful" information over time. 1120 15. Implementation Status 1122 [[ Note: For minimizing section number references when the RFC editor 1123 removes this section, it has been moved to be the last section of the 1124 document before the Appendicies. ]] 1126 [[ Note to the RFC Editor: Please remove this section before 1127 publication along with the reference to [RFC6982]. ]] 1129 This section records the status of known implementations of the 1130 protocol defined by this specification at the time of posting of this 1131 Internet-Draft, and is based on a proposal described in [RFC6982]. 1132 The description of implementations in this section is intended to 1133 assist the IETF in its decision processes in progressing drafts to 1134 RFCs. Please note that the listing of any individual implementation 1135 here does not imply endorsement by the IETF. Furthermore, no effort 1136 has been spent to verify the information presented here that was 1137 supplied by IETF contributors. This is not intended as, and must not 1138 be construed to be, a catalog of available implementations or their 1139 features. Readers are advised to note that other implementations may 1140 exist. 1142 This information is known to be correct as of the seventh 1143 interoperability test event which was held on 2017-07-15 & 16 at 1144 IETF99. 1146 For a few of the implementations, later status information was 1147 available as of December 2017. 1149 15.1. GMail test reflector and incoming validation 1151 Organization: Google 1153 Description: Internal production implementation with both debug 1154 analysis and validating + sealing pass-through function 1156 Status of Operation: Production - Incoming Validation 1158 Coverage: Full spec implemented as of [ARC-DRAFT-06] 1160 Licensing: Proprietary - Internal only 1162 Implementation Notes: 1164 o Full functionality was demonstrated during the interop testing on 1165 2017-07-15. 1167 Contact Info: arc-discuss@dmarc.org [1] 1169 15.2. AOL test reflector and internal tagging 1171 Organization: AOL 1173 Description: Internal prototype implementation with both debug 1174 analysis and validating + sealing pass-through function 1176 Status of Operation: Beta 1178 Coverage: ARC chain validity status checking is operational, but only 1179 applied to email addresses enrolled in the test program. This system 1180 conforms to [ARC-DRAFT-06] 1182 Licensing: Proprietary - Internal only 1184 Implementation Notes: 1186 o 2017-07-15: Full functionality verified during the interop 1187 testing. 1189 Contact Info: arc-discuss@dmarc.org [2] 1191 15.3. dkimpy 1193 Organization: dkimpy developers/Scott Kitterman 1195 Description: Python DKIM package 1197 Status of Operation: Production 1199 Coverage: 1201 o 2017-07-15: The internal test suite is incomplete, but the command 1202 line developmental version of validator was demonstrated to 1203 interoperate with the Google and AOL implementations during the 1204 interop on 2017-07-15 and the released version passes the tests in 1205 [ARC-TEST] (https://github.com/ValiMail/arc_test_suite) with both 1206 python and python3. 1208 Licensing: Open/Other (same as dkimpy package = BCD version 2) 1210 Contact Info: https://launchpad.net/dkimpy 1212 15.4. OpenARC 1214 Organization: TDP/Murray Kucherawy 1216 Description: Implemention of milter functionality related to the 1217 OpenDKIM and OpenDMARC packages 1219 Status of Operation: Beta 1221 Coverage: Built to support [ARC-DRAFT-10] 1223 Licensing: Open/Other (same as OpenDKIM and OpenDMARC packages) 1225 Implementation Notes: 1227 o The build is FreeBSD oriented but some packages have been built 1228 for easier deployment on RedHat-based Linux platforms. 1230 o Some issues still exist when deploying in a chained milter 1231 arrangement (such as OpenSPF -> OpenDKIM -> OpenDMARC -> OpenARC) 1232 with coordination between the stages. When deployed in a 1233 "sandwich" configuration around an MLM, there is no effective 1234 mechanism to convey trust from the ingress (validator) to egress 1235 (signer) instances. (_NOTE_: this is expected to resolved with a 1236 new release of OpenDMARC expected in January 2018.) 1238 Contact Info: arc-discuss@dmarc.org [3] 1240 15.5. Mailman 3.2 patch 1242 Organization: Mailman development team 1244 Description: Integrated ARC capabilities within the Mailman 3.2 1245 package 1247 Status of Operation: Patch submitted 1249 Coverage: Based on OpenARC 1251 Licensing: Same as mailman package - GPL 1253 Implementation Notes: 1255 o Appears to work properly in at least one beta deployment, but 1256 waiting on acceptance of the pull request into the mainline of 1257 mailman development 1259 Contact Info: https://www.gnu.org/software/mailman/contact.html 1261 15.6. Copernica/MailerQ web-based validation 1263 Organization: Copernica 1265 Description: Web-based validation of ARC-signed messages 1267 Status of Operation: Beta 1269 Coverage: Built to support [ARC-DRAFT-05] 1271 Licensing: On-line usage only 1273 Implementation Notes: 1275 o Released 2016-10-24 1277 o Requires full message content to be pasted into a web form found 1278 at http://arc.mailerq.com/ (warning - https is not supported). 1280 o An additional instance of an ARC signature can be added if one is 1281 willing to paste a private key into an unsecured web form. 1283 o 2017-07-15: Testing shows that results match the other 1284 implementations listed in this section. 1286 Contact Info: https://www.copernica.com/ 1288 15.7. Rspamd 1290 Organization: Rspamd community 1292 Description: ARC signing and verification module 1294 Status of Operation: Production, though deployment usage is unknown 1296 Coverage: Built to support [ARC-DRAFT-06] 1298 Licensing: Open source 1300 Implementation Notes: 1302 o 2017-06-12: Released with version 1.6.0 1304 o 2017-07-15: Testing during the interop showed that the validation 1305 functionality interoperated with the Google, AOL, dkimpy and 1306 MailerQ implementations 1308 Contact Info: https://rspamd.com/doc/modules/arc.html and 1309 https://github.com/vstakhov/rspamd 1311 15.8. PERL MAIL::DKIM module 1313 Organization: FastMail 1315 Description: Email domain authentication (sign and/or verify) module, 1316 previously included SPF / DKIM / DMARC, now has ARC added 1318 Status of Operation: Production, deployment usage unknown 1320 Coverage: Built to support [ARC-DRAFT-10] 1322 Licensing: Open Source 1324 Implementation Notes: 1326 o 2017-12-15: v0.50 released with full test set passing for ARC 1328 Contact Info: http://search.cpan.org/~mbradshaw/Mail-DKIM-0.50/ 1330 15.9. PERL Mail::Milter::Authentication module 1332 Organization: FastMail 1334 Description: Email domain authentication milter, uses MAIL::DKIM (see 1335 above) 1337 Status of Operation: Intial validation completed during IETF99 1338 hackathon with some follow-on work during the week 1340 Coverage: Built to support [I-D.ARC] 1342 Licensing: Open Source 1344 Implementation Notes: 1346 o 2017-07-15: Validation functionality which interoperates with 1347 Gmail, AOL, dkimpy was demonstrated; later in the week of IETF99, 1348 the signing functionality was reported to be working 1350 o 2017-07-20: ARC functionality has not yet been pushed back to the 1351 github repo but should be showing up soon 1353 Contact Info: https://github.com/fastmail/authentication_milter 1355 15.10. Sympa List Manager 1357 Organization: Sympa Dev Community 1359 Description: Work in progress 1361 Status of Operation: Work in progress 1363 Coverage: unknown 1365 Licensing: open source 1367 Implementation Notes: 1369 o 2018-01-05: Tracked as https://github.com/sympa-community/sympa/ 1370 issues/153 1372 Contact Info: https://github.com/sympa-community 1374 15.11. Oracle Messaging Server 1376 Organization: Oracle 1378 Description: 1380 Status of Operation: Intial development work during IETF99 hackathon. 1381 Status since then unknown. 1383 Coverage: Built to support [ARC-DRAFT-06] 1385 Licensing: Unknown 1387 Implementation Notes: 1389 o Status since the work done in July 2017 is unknown. 1391 Contact Info: 1393 15.12. MessageSystems Momentum 1395 Organization: MessageSystems/SparkPost 1397 Description: OpenARC integration into the LUA-enabled Momentum 1398 processing space 1400 Status of Operation: Beta 1402 Coverage: Built to support [ARC-DRAFT-10] 1404 Licensing: Unknown 1406 Implementation Notes: 1408 o Initial deployments for validation expected in early 2018. 1410 Contact Info: 1412 16. References 1414 16.1. Normative References 1416 [RFC1345] Simonsen, K., "Character Mnemonics and Character Sets", 1417 RFC 1345, DOI 10.17487/RFC1345, June 1992, 1418 . 1420 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1421 Requirement Levels", BCP 14, RFC 2119, 1422 DOI 10.17487/RFC2119, March 1997, 1423 . 1425 [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and 1426 Functions", RFC 2142, DOI 10.17487/RFC2142, May 1997, 1427 . 1429 [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS 1430 Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999, 1431 . 1433 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", 1434 RFC 3463, DOI 10.17487/RFC3463, January 2003, 1435 . 1437 [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys 1438 Identified Mail (DKIM)", RFC 4686, DOI 10.17487/RFC4686, 1439 September 2006, . 1441 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1442 IANA Considerations Section in RFCs", RFC 5226, 1443 DOI 10.17487/RFC5226, May 2008, 1444 . 1446 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1447 Specifications: ABNF", STD 68, RFC 5234, 1448 DOI 10.17487/RFC5234, January 2008, 1449 . 1451 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1452 DOI 10.17487/RFC5321, October 2008, 1453 . 1455 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1456 DOI 10.17487/RFC5322, October 2008, 1457 . 1459 [RFC5585] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys 1460 Identified Mail (DKIM) Service Overview", RFC 5585, 1461 DOI 10.17487/RFC5585, July 2009, 1462 . 1464 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 1465 DOI 10.17487/RFC5598, July 2009, 1466 . 1468 [RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, 1469 "DomainKeys Identified Mail (DKIM) Development, 1470 Deployment, and Operations", RFC 5863, 1471 DOI 10.17487/RFC5863, May 2010, 1472 . 1474 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 1475 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 1476 RFC 6376, DOI 10.17487/RFC6376, September 2011, 1477 . 1479 [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and 1480 Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377, 1481 September 2011, . 1483 [RFC6651] Kucherawy, M., "Extensions to DomainKeys Identified Mail 1484 (DKIM) for Failure Reporting", RFC 6651, 1485 DOI 10.17487/RFC6651, June 2012, 1486 . 1488 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 1489 Authorizing Use of Domains in Email, Version 1", RFC 7208, 1490 DOI 10.17487/RFC7208, April 2014, 1491 . 1493 [RFC7601] Kucherawy, M., "Message Header Field for Indicating 1494 Message Authentication Status", RFC 7601, 1495 DOI 10.17487/RFC7601, August 2015, 1496 . 1498 16.2. Informative References 1500 [ARC-DRAFT-05] 1501 Andersen, K., "Authenticated Received Chain (ARC) Protocol 1502 (I-D-05)", n.d., . 1505 [ARC-DRAFT-06] 1506 Andersen, K., "Authenticated Received Chain (ARC) Protocol 1507 (I-D-06)", n.d., . 1510 [ARC-DRAFT-10] 1511 Andersen, K., "Authenticated Received Chain (ARC) Protocol 1512 (I-D-10)", n.d., . 1515 [ARC-MULTI] 1516 Andersen, K., "Using Multiple Signing Algorithms with 1517 ARC", January 2018, . 1520 [ARC-TEST] 1521 Blank, S., "ARC Test Suite", January 2017, 1522 . 1524 [ARC-USAGE] 1525 Jones, S., Adams, T., Rae-Grant, J., and K. Andersen, 1526 "Recommended Usage of the ARC Headers", December 2017, 1527 . 1530 [ENHANCED-STATUS] 1531 "IANA SMTP Enhanced Status Codes", n.d., 1532 . 1535 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1536 Code: The Implementation Status Section", RFC 6982, 1537 DOI 10.17487/RFC6982, July 2013, 1538 . 1540 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 1541 Message Authentication, Reporting, and Conformance 1542 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 1543 . 1545 [RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky, 1546 E., Ed., and K. Andersen, Ed., "Interoperability Issues 1547 between Domain-based Message Authentication, Reporting, 1548 and Conformance (DMARC) and Indirect Email Flows", 1549 RFC 7960, DOI 10.17487/RFC7960, September 2016, 1550 . 1552 16.3. URIs 1554 [1] mailto:arc-discuss@dmarc.org 1556 [2] mailto:arc-discuss@dmarc.org 1558 [3] mailto:arc-discuss@dmarc.org 1560 [4] mailto:dmarc@ietf.org 1562 [5] mailto:arc-discuss@dmarc.org 1564 Appendix A. Appendix A - Design Requirements 1566 (This section is re-inserted for background information from 1567 [ARC-DRAFT-06] and earlier versions.) 1569 The specification of the ARC framework is driven by the following 1570 high-level goals, security considerations, and practical operational 1571 requirements. 1573 A.1. Primary Design Criteria 1575 o Provide a verifiable "chain of custody" for email messages; 1577 o Not require changes for originators of email; 1579 o Support the verification of the ARC header field set by each hop 1580 in the handling chain; 1582 o Work at Internet scale; and 1584 o Provide a trustable mechanism for the communication of 1585 Authentication-Results across trust boundaries. 1587 A.2. Out of Scope 1589 ARC is not a trust framework. Users of the ARC header fields are 1590 cautioned against making unsubstantiated conclusions when 1591 encountering a "broken" ARC sequence. 1593 Appendix B. Appendix B - Example Usage 1595 [[ Note: The following examples were mocked up early in the 1596 definition process for the spec. They no longer reflect the current 1597 definition and need various updates which will be included in a 1598 future draft. ]] 1600 (Obsolete but retained for illustrative purposes) 1602 B.1. Example 1: Simple mailing list 1604 B.1.1. Here's the message as it exits the Origin: 1606 Return-Path: 1607 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 1608 (authenticated bits=0) 1609 by segv.d1.example with ESMTP id t0FN4a8O084569; 1610 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 1611 (envelope-from jqd@d1.example) 1612 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; 1613 s=20130426; t=1421363082; 1614 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 1615 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: 1616 Content-Transfer-Encoding; 1617 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw 1618 bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl 1619 gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 1620 Message-ID: <54B84785.1060301@d1.example> 1621 Date: Thu, 14 Jan 2015 15:00:01 -0800 1622 From: John Q Doe 1623 To: arc@dmarc.org 1624 Subject: Example 1 1626 Hey gang, 1627 This is a test message. 1628 --J. 1630 B.1.2. Message is then received at example.org 1632 B.1.2.1. Example 1, Step A: Message forwarded to list members 1634 Processing at example.org: 1636 o example.org performs authentication checks 1638 o No previous Authentication-Results or ARC-Seal headers are present 1640 o example.org adds ARC-Authentication-Results header 1642 o example.org adds Received: header 1644 o example.org adds a ARC-Seal header 1646 Here's the message as it exits example.org: 1648 Return-Path: 1649 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 1650 s=seal2015; d=example.org; cv=none; 1651 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 1652 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 1653 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 1654 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; 1655 d=example.org; s=clochette; t=1421363105; 1656 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; 1657 h=List-Id:List-Unsubscribe:List-Archive:List-Post: 1658 List-Help:List-Subscribe:Reply-To:DKIM-Signature; 1659 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1F5 1660 vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+m4bw 1661 a6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= 1662 Received: from segv.d1.example (segv.d1.example [72.52.75.15]) 1663 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 1664 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) 1665 (envelope-from jqd@d1.example) 1666 ARC-Authentication-Results: i=1; lists.example.org; 1667 spf=pass smtp.mfrom=jqd@d1.example; 1668 dkim=pass (1024-bit key) header.i=@d1.example; 1669 dmarc=pass 1670 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 1671 (authenticated bits=0) 1672 by segv.d1.example with ESMTP id t0FN4a8O084569; 1673 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 1674 (envelope-from jqd@d1.example) 1675 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; 1676 s=20130426; t=1421363082; 1677 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 1678 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: 1679 Content-Transfer-Encoding; 1680 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr 1681 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G 1682 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 1683 Message-ID: <54B84785.1060301@d1.example> 1684 Date: Thu, 14 Jan 2015 15:00:01 -0800 1685 From: John Q Doe 1686 To: arc@example.org 1687 Subject: [Lists] Example 1 1689 Hey gang, 1690 This is a test message. 1691 --J. 1693 B.1.3. Example 1: Message received by Recipient 1695 Let's say that the Recipient is example.com 1697 Processing at example.com: 1699 o example.com performs usual authentication checks 1701 o example.com adds Authentication-Results: header, Received header 1703 o Determines that message fails DMARC 1705 o Checks for ARC-Seal: header; finds one 1707 o Validates the signature in the ARC-Seal: header, which covers the 1708 ARC-Authentication-Results: header 1710 o example.com can use the ARC-Authentication-Results values or 1711 verify the DKIM-Signature from lists.example.org 1713 Here's what the message looks like at this point: 1715 Return-Path: 1716 Received: from example.org (example.org [208.69.40.157]) 1717 by clothilde.example.com with ESMTP id 1718 d200mr22663000ykb.93.1421363207 1719 for ; Thu, 14 Jan 2015 15:02:40 -0800 (PST) 1720 Authentication-Results: clothilde.example.com; spf=fail 1721 smtp.from=jqd@d1.example; dkim=pass (1024-bit key) 1722 header.i=@example.org; dmarc=fail; arc=pass 1723 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 1724 s=seal2015; d=example.org; cv=none; 1725 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 1726 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 1727 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 1728 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; 1729 d=example.org; s=clochette; t=1421363105; 1730 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; 1731 h=List-Id:List-Unsubscribe:List-Archive:List-Post: 1732 List-Help:List-Subscribe:Reply-To:DKIM-Signature; 1733 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF 1734 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3 1735 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= 1736 Received: from segv.d1.example (segv.d1.example [72.52.75.15]) 1737 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 1738 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) 1739 (envelope-from jqd@d1.example) 1740 ARC-Authentication-Results: i=1; lists.example.org; 1741 spf=pass smtp.mfrom=jqd@d1.example; 1742 dkim=pass (1024-bit key) header.i=@d1.example; 1743 dmarc=pass 1744 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 1745 (authenticated bits=0) 1746 by segv.d1.example with ESMTP id t0FN4a8O084569; 1747 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 1748 (envelope-from jqd@d1.example) 1749 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; 1750 s=20130426; t=1421363082; 1751 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 1752 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: 1753 Content-Transfer-Encoding; 1754 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw 1755 bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl 1756 gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 1757 Message-ID: <54B84785.1060301@d1.example> 1758 Date: Thu, 14 Jan 2015 15:00:01 -0800 1759 From: John Q Doe 1760 To: arc@example.org 1761 Subject: [Lists] Example 1 1763 Hey gang, 1764 This is a test message. 1765 --J. 1767 B.2. Example 2: Mailing list to forwarded mailbox 1769 B.2.1. Here's the message as it exits the Origin: 1771 Return-Path: 1772 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 1773 (authenticated bits=0) 1774 by segv.d1.example with ESMTP id t0FN4a8O084569; 1775 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 1776 (envelope-from jqd@d1.example) 1777 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; 1778 s=20130426; t=1421363082; 1779 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 1780 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: 1781 Content-Transfer-Encoding; 1782 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw 1783 bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl 1784 gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 1785 Message-ID: <54B84785.1060301@d1.example> 1786 Date: Thu, 14 Jan 2015 15:00:01 -0800 1787 From: John Q Doe 1788 To: arc@example.org 1789 Subject: Example 1 1791 Hey gang, 1792 This is a test message. 1793 --J. 1795 B.2.2. Message is then received at example.org 1797 B.2.2.1. Example 2, Step A: Message forwarded to list members 1799 Processing at example.org: 1801 o example.org performs authentication checks 1803 o example.org applies standard DKIM signature 1805 o No previous Authentication-Results or ARC-Seal headers are present 1807 o example.org adds ARC-Authentication-Results header 1809 o example.org adds usual Received: header 1811 o example.org adds a ARC-Seal header 1813 Here's the message as it exits Step A: 1815 Return-Path: 1816 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 1817 s=seal2015; d=example.org; cv=none; 1818 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6 1819 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L 1820 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 1821 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; 1822 d=example.org; s=clochette; t=1421363105; 1823 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; 1824 h=List-Id:List-Unsubscribe:List-Archive:List-Post: 1825 List-Help:List-Subscribe:Reply-To:DKIM-Signature; 1826 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF 1827 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3 1828 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= 1829 Received: from segv.d1.example (segv.d1.example [72.52.75.15]) 1830 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 1831 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) 1832 (envelope-from jqd@d1.example) 1833 ARC-Authentication-Results: i=1; lists.example.org; 1834 spf=pass smtp.mfrom=jqd@d1.example; 1835 dkim=pass (1024-bit key) header.i=@d1.example; 1836 dmarc=pass 1837 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 1838 (authenticated bits=0) 1839 by segv.d1.example with ESMTP id t0FN4a8O084569; 1840 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 1841 (envelope-from jqd@d1.example) 1842 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; 1843 s=20130426; t=1421363082; 1844 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 1845 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: 1846 Content-Transfer-Encoding; 1847 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr 1848 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G 1849 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 1850 Message-ID: <54B84785.1060301@d1.example> 1851 Date: Thu, 14 Jan 2015 15:00:01 -0800 1852 From: John Q Doe 1853 To: arc@example.org 1854 Subject: [Lists] Example 1 1856 Hey gang, 1857 This is a test message. 1858 --J. 1860 B.2.2.2. Example 2, Step B: Message from list forwarded 1862 The message is delivered to a mailbox at gmail.com 1863 Processing at gmail.com: 1865 o gmail.com performs usual authentication checks 1867 o gmail.com adds Authentication-Results: and Received: header 1869 o Determines that message fails DMARC 1871 o Checks for ARC-Seal: header; finds one 1873 o Validates the signature in the ARC-Seal: header, which covers the 1874 ARC-Authentication-Results: header 1876 o Uses the ARC-Authentication-Results: values, but: 1878 o Instead of delivering message, prepares to forward message per 1879 user settings 1881 o Applies usual DKIM signature 1883 o gmail.com adds it's own ARC-Seal: header, contents of which are 1885 * version 1887 * sequence number ("i=2") 1889 * hash algorithm (SHA256 as example) 1891 * timestamp ("t=") 1893 * selector for key ("s=notary01") 1895 * domain for key ("d=gmail.com") 1897 * headers included in hash ("h=ARC-Authentication-Results:ARC- 1898 Seal") 1900 * Note: algorithm requires only ARC-Seals with lower sequence # 1901 be included, in ascending order 1903 * signature of the header hash 1905 Here's what the message looks like at this point: 1907 Return-Path: 1908 ARC-Seal: i=2; a=rsa-sha256; t=1421363253; 1909 s=notary01; d=gmail.com; cv=pass; 1910 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDWR 1911 YbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/sut 1912 txO+RRNr0fCFw== 1913 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; 1914 d=gmail.com; s=20120806; 1915 h=mime-version:content-type:x-original-sender: 1916 x-original-authentication-results:precedence:mailing-list: 1917 list-id:list-post:list-help:list-archive:sender:reply-to: 1918 list-unsubscribe:DKIM-Signature; 1919 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=; 1920 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 1921 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 1922 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBmfhS 1923 LF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJRFeM 1924 KdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwDBJtXw 1925 bQoZyRtb6X6q0mYaszUB8kw== 1926 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10 1927 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST) 1928 Authentication-Results: i=2; gmail.com; spf=fail 1929 smtp.from=jqd@d1.example; dkim=pass (1024-bit key) 1930 header.i=@example.org; dmarc=fail; arc=pass 1931 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 1932 s=seal2015; d=example.org; cv=none: 1933 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 1934 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 1935 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 1936 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; 1937 d=example.org; s=clochette; t=1421363105; 1938 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; 1939 h=List-Id:List-Unsubscribe:List-Archive:List-Post: 1940 List-Help:List-Subscribe:Reply-To:DKIM-Signature; 1941 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF 1942 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3 1943 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= 1944 Received: from segv.d1.example (segv.d1.example [72.52.75.15]) 1945 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 1946 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) 1947 (envelope-from jqd@d1.example) 1948 ARC-Authentication-Results: i=1; lists.example.org; 1949 spf=pass smtp.mfrom=jqd@d1.example; 1950 dkim=pass (1024-bit key) header.i=@d1.example; 1951 dmarc=pass 1952 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 1953 (authenticated bits=0) 1954 by segv.d1.example with ESMTP id t0FN4a8O084569; 1955 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 1956 (envelope-from jqd@d1.example) 1957 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; 1958 s=20130426; t=1421363082; 1959 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 1960 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: 1961 Content-Transfer-Encoding; 1962 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr 1963 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G 1964 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 1965 Message-ID: <54B84785.1060301@d1.example> 1966 Date: Thu, 14 Jan 2015 15:00:01 -0800 1967 From: John Q Doe 1968 To: arc@example.org 1969 Subject: [Lists] Example 1 1971 Hey gang, 1972 This is a test message. 1973 --J. 1975 B.2.3. Example 2: Message received by Recipient 1977 Let's say that the Recipient is example.com 1978 Processing at example.com: 1980 o example.com performs usual authentication checks 1982 o example.com adds Authentication-Results: header, Received header 1984 o Determines that message fails DMARC 1986 o Checks for ARC-Seal: header; finds two 1988 o Validates the signature in the highest numbered ("i=2") ARC-Seal: 1989 header, which covers all previous ARC-Seal: and ARC- 1990 Authentication-Results: headers 1992 o Validates the other ARC-Seal header ("i=1"), which covers the ARC- 1993 Authentication-Results: header 1995 o example.com uses the ARC-Authentication-Results: values 1997 Here's what the message looks like at this point: 1999 Return-Path: 2000 Received: from mail-ob0-f188.google.com (mail-ob0-f188.google.com 2001 [208.69.40.157]) by clothilde.example.com with ESMTP id 2002 d200mr22663000ykb.93.1421363268 2003 for ; Thu, 14 Jan 2015 15:03:15 -0800 (PST) 2005 Authentication-Results: clothilde.example.com; spf=fail 2006 smtp.from=jqd@d1.example; dkim=pass (1024-bit key) 2007 header.i=@gmail.com; dmarc=fail; arc=pass 2008 ARC-Seal: i=2; a=rsa-sha256; t=1421363253; 2009 s=notary01; d=gmail.com; cv=pass; 2010 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDWR 2011 YbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/sut 2012 txO+RRNr0fCFw== 2013 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; 2014 d=gmail.com; s=20120806; 2015 h=mime-version:content-type:x-original-sender: 2016 x-original-authentication-results:precedence:mailing-list: 2017 list-id:list-post:list-help:list-archive:sender:reply-to: 2018 :list-unsubscribe:DKIM-Signature; 2019 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=; 2020 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 2021 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 2022 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBmfhS 2023 LF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJRFeM 2024 KdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwDBJtXw 2025 bQoZyRtb6X6q0mYaszUB8kw== 2026 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10 2027 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST) 2028 Authentication-Results: i=2; gmail.com; spf=fail 2029 smtp.from=jqd@d1.example; dkim=pass (1024-bit key) 2030 header.i=@example.org; dmarc=fail; arc=pass 2031 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 2032 s=seal2015; d=example.org; cv=none; 2033 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 2034 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 2035 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 2036 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; 2037 d=example.org; s=clochette; t=1421363105; 2038 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; 2039 h=List-Id:List-Unsubscribe:List-Archive:List-Post: 2040 List-Help:List-Subscribe:Reply-To:DKIM-Signature; 2041 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF 2042 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3 2043 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= 2044 Received: from segv.d1.example (segv.d1.example [72.52.75.15]) 2045 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 2046 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) 2047 (envelope-from jqd@d1.example) 2048 ARC-Authentication-Results: i=1; lists.example.org; 2049 spf=pass smtp.mfrom=jqd@d1.example; 2050 dkim=pass (1024-bit key) header.i=@d1.example; 2051 dmarc=pass 2052 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 2053 (authenticated bits=0) 2054 by segv.d1.example with ESMTP id t0FN4a8O084569; 2055 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 2056 (envelope-from jqd@d1.example) 2057 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; 2058 s=20130426; t=1421363082; 2059 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 2060 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: 2061 Content-Transfer-Encoding; 2062 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr 2063 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G 2064 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 2065 Message-ID: <54B84785.1060301@d1.example> 2066 Date: Thu, 14 Jan 2015 15:00:01 -0800 2067 From: John Q Doe 2068 To: arc@example.org 2069 Subject: [Lists] Example 1 2071 Hey gang, 2072 This is a test message. 2073 --J. 2075 B.3. Example 3: Mailing list to forwarded mailbox with source 2077 B.3.1. Here's the message as it exits the Origin: 2079 Return-Path: 2080 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 2081 (authenticated bits=0) 2082 by segv.d1.example with ESMTP id t0FN4a8O084569; 2083 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 2084 (envelope-from jqd@d1.example) 2085 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 2086 s=origin2015; d=d1.example; cv=none; 2087 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61T 2088 X6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69EU 2089 8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 2090 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; 2091 d=d1.example; s=20130426; t=1421363082; 2092 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 2093 h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding; 2094 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrv 2095 Qwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3 2096 TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 2097 Message-ID: <54B84785.1060301@d1.example> 2098 Date: Thu, 14 Jan 2015 15:00:01 -0800 2099 From: John Q Doe 2100 To: arc@example.org 2101 Subject: Example 1 2103 Hey gang, 2104 This is a test message. 2105 --J. 2107 B.3.2. Message is then received at example.org 2109 B.3.2.1. Example 3, Step A: Message forwarded to list members with 2110 source 2112 Processing at example.org: 2114 o example.org performs authentication checks 2116 o example.org applies standard DKIM signature 2118 o Checks for ARC-Seal: header; finds one (i=1) 2120 o Validates the signature in the ARC-Seal (i=1): header, which 2121 covers the d1.example ARC-Message-Signature: header 2123 o example.org adds ARC-Authentication-Results header 2125 o example.org adds usual Received: header 2126 o example.org adds a DKIM-Signature 2128 o example.org adds a ARC-Seal header, contents of which are 2130 * sequence number ("i=2") 2132 * hash algorithm (SHA256 as example) 2134 * timestamp ("t=") 2136 * chain validity ("cv=") 2138 * selector for key ("s=seal2015") 2140 * domain for key ("d=example.org") 2142 * signature ("b=") 2144 Here's the message as it exits Step A: 2146 Return-Path: 2147 ARC-Seal: i=2; a=rsa-sha256; t=1421363107; 2148 s=seal2015; d=example.org; cv=pass; 2149 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6 2150 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L 2151 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 2152 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; 2153 d=example.org; s=clochette; t=1421363105; 2154 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; 2155 h=List-Id:List-Unsubscribe:List-Archive:List-Post: 2156 List-Help:List-Subscribe:From:Reply-To:DKIM-Signature; 2157 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF 2158 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3 2159 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= 2160 Received: from segv.d1.example (segv.d1.example [72.52.75.15]) 2161 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 2162 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) 2163 (envelope-from jqd@d1.example) 2164 ARC-Authentication-Results: i=2; lists.example.org; 2165 spf=pass smtp.mfrom=jqd@d1.example; 2166 dkim=pass (1024-bit key) header.i=@d1.example; 2167 dmarc=pass 2168 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 2169 (authenticated bits=0) 2170 by segv.d1.example with ESMTP id t0FN4a8O084569; 2171 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 2172 (envelope-from jqd@d1.example) 2173 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 2174 s=origin2015; d=d1.example; cv=none; 2175 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 2176 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 2177 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 2178 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; 2179 d=d1.example; s=20130426; t=1421363082; 2180 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 2181 h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding; 2182 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr 2183 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G 2184 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 2185 Message-ID: <54B84785.1060301@d1.example> 2186 Date: Thu, 14 Jan 2015 15:00:01 -0800 2187 From: John Q Doe 2188 To: arc@example.org 2189 Subject: [Lists] Example 1 2191 Hey gang, 2192 This is a test message. 2193 --J. 2195 B.3.2.2. Example 3, Step B: Message from list forwarded with source 2197 The message is delivered to a mailbox at gmail.com 2198 Processing at gmail.com: 2200 o gmail.com performs usual authentication checks 2202 o gmail.com adds Authentication-Results: and Received: header 2204 o Determines that message fails DMARC 2206 o Checks for ARC-Seal: header; finds two 2208 o Validates the signature in the ARC-Seal (i=2): header, which 2209 covers the ARC-Authentication-Results: header 2211 o Validates the signature in the ARC-Seal (i=1): header, which 2212 covers the d1.example ARC-Message-Signature: header 2214 o Uses the ARC-Authentication-Results: values, but: 2216 o Instead of delivering message, prepares to forward message per 2217 user settings 2219 o Applies usual DKIM signature 2221 o gmail.com adds it's own ARC-Seal: header, contents of which are 2223 * version 2225 * sequence number ("i=2") 2227 * hash algorithm (SHA256 as example) 2229 * timestamp ("t=") 2231 * selector for key ("s=notary01") 2233 * domain for key ("d=gmail.com") 2235 * Note: algorithm requires only ARC-Seals with lower sequence # 2236 be included, in ascending order 2238 * signature of the chain 2240 Here's what the message looks like at this point: 2242 Return-Path: 2243 ARC-Seal: i=3; a=rsa-sha256; t=1421363253; 2244 s=notary01; d=gmail.com; cv=pass; 2245 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwD 2246 WRYbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF 2247 /suttxO+RRNr0fCFw== 2248 ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed; 2249 d=gmail.com; s=20120806; 2250 h=mime-version:content-type:x-original-sender 2251 :x-original-authentication-results:precedence:mailing-list 2252 :list-id:list-post:list-help:list-archive:sender 2253 :list-unsubscribe:reply-to; 2254 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=; 2255 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6 2256 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L 2257 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBm 2258 fhSLF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJ 2259 RFeMKdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwD 2260 BJtXwbQoZyRtb6X6q0mYaszUB8kw== 2261 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10 2262 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST) 2263 Authentication-Results: i=3; gmail.com; spf=fail 2264 smtp.from=jqd@d1.example; dkim=pass (1024-bit key) 2265 header.i=@example.org; dmarc=fail; arc=pass 2266 ARC-Seal: i=2; a=rsa-sha256; t=1421363107; 2267 s=seal2015; d=example.org; cv=pass; 2268 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 2269 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 2270 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 2271 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; 2272 d=example.org; s=clochette; t=1421363105; 2273 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; 2274 h=List-Id:List-Unsubscribe:List-Archive:List-Post: 2275 List-Help:List-Subscribe:Reply-To:DKIM-Signature; 2276 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1 2277 F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+ 2278 m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= 2279 Received: from segv.d1.example (segv.d1.example [72.52.75.15]) 2280 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 2281 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) 2282 (envelope-from jqd@d1.example) 2283 ARC-Authentication-Results: i=2; lists.example.org; 2284 spf=pass smtp.mfrom=jqd@d1.example; 2285 dkim=pass (1024-bit key) header.i=@d1.example; 2286 dmarc=pass 2287 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 2288 (authenticated bits=0) 2289 by segv.d1.example with ESMTP id t0FN4a8O084569; 2290 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 2291 (envelope-from jqd@d1.example) 2292 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 2293 s=origin2015; d=d1.example; cv=none; 2294 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 2295 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 2296 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 2297 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; 2298 d=d1.example; s=20130426; t=1421363082; 2299 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 2300 h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding; 2301 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYij 2302 rvQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD 2303 4Gd3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 2304 Message-ID: <54B84785.1060301@d1.example> 2305 Date: Thu, 14 Jan 2015 15:00:01 -0800 2306 From: John Q Doe 2307 To: arc@example.org 2308 Subject: [Lists] Example 1 2310 Hey gang, 2311 This is a test message. 2312 --J. 2314 B.3.3. Example 3: Message received by Recipient 2316 Let's say that the Recipient is example.com 2317 Processing at example.com: 2319 o example.com performs usual authentication checks 2321 o example.com adds Authentication-Results: header, Received header 2323 o Determines that message fails DMARC 2325 o Checks for ARC-Seal: header; finds three 2327 o Validates the signature in the highest numbered ("i=2") ARC-Seal: 2328 header, which covers all previous ARC-Seal: and ARC- 2329 Authentication-Results: headers 2331 o Validates the other ARC-Seal header ("i=2"), which covers the ARC- 2332 Authentication-Results: header 2334 o Validates the other ARC-Seal header ("i=1"), which covers the 2335 d1.example ARC-Message-Signature: header 2337 o example.com uses the ARC-Authentication-Results: values 2338 Here's what the message looks like at this point: 2340 Return-Path: 2341 Received: from mail-ob0-f188.google.com (mail-ob0-f188.google.com 2342 [208.69.40.157]) by clothilde.example.com with ESMTP id 2343 d200mr22663000ykb.93.1421363268 2344 for ; Thu, 14 Jan 2015 15:03:15 -0800 (PST) 2345 Authentication-Results: clothilde.example.com; spf=fail 2346 smtp.from=jqd@d1.example; dkim=pass (1024-bit key) 2347 header.i=@gmail.com; dmarc=fail; arc=pass 2348 ARC-Seal: i=3; a=rsa-sha256; t=1421363253; 2349 s=notary01; d=gmail.com; cv=pass; 2350 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDW 2351 RYbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/s 2352 uttxO+RRNr0fCFw== 2353 ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed; 2354 d=gmail.com; s=20120806; 2355 h=mime-version:content-type:x-original-sender 2356 :x-original-authentication-results:precedence 2357 :mailing-list:list-id:list-post:list-help:list-archive:sender 2358 :list-unsubscribe:reply-to; 2359 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=; 2360 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6 2361 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L 2362 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBm 2363 fhSLF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJ 2364 RFeMKdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwD 2365 BJtXwbQoZyRtb6X6q0mYaszUB8kw== 2366 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10 2367 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST) 2368 Authentication-Results: i=3; gmail.com; spf=fail 2369 smtp.from=jqd@d1.example; dkim=pass (1024-bit key) 2370 header.i=@example.org; dmarc=fail; arc=pass 2371 ARC-Seal: i=2; a=rsa-sha256; t=1421363107; 2372 s=seal2015; d=example.org; cv=pass; 2373 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6 2374 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L 2375 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 2376 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; 2377 d=example.org; s=clochette; t=1421363105; 2378 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; 2379 h=List-Id:List-Unsubscribe:List-Archive:List-Post: 2380 List-Help:List-Subscribe:Reply-To:DKIM-Signature; 2381 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1 2382 F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+ 2383 m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= 2384 Received: from segv.d1.example (segv.d1.example [72.52.75.15]) 2385 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 2386 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) 2387 (envelope-from jqd@d1.example) 2388 ARC-Authentication-Results: i=2; lists.example.org; 2389 spf=pass smtp.mfrom=jqd@d1.example; 2390 dkim=pass (1024-bit key) header.i=@d1.example; 2391 dmarc=pass 2392 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 2393 (authenticated bits=0) 2394 by segv.d1.example with ESMTP id t0FN4a8O084569; 2395 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 2396 (envelope-from jqd@d1.example) 2397 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 2398 s=origin2015; d=d1.example; cv=none; 2399 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 2400 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 2401 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 2402 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; 2403 d=d1.example; s=20130426; t=1421363082; 2404 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 2405 h=MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding; 2406 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr 2407 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G 2408 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 2409 Message-ID: <54B84785.1060301@d1.example> 2410 Date: Thu, 14 Jan 2015 15:00:01 -0800 2411 From: John Q Doe 2412 To: arc@example.org 2413 Subject: [Lists] Example 1 2415 Hey gang, 2416 This is a test message. 2417 --J. 2419 Appendix C. Acknowledgements 2421 This draft is the work of OAR-Dev Group. 2423 The authors thank all of the OAR-Dev group for the ongoing help and 2424 though-provoking discussions from all the participants, especially: 2425 Alex Brotman, Brandon Long, Dave Crocker, Elizabeth Zwicky, Franck 2426 Martin, Greg Colburn, J. Trent Adams, John Rae-Grant, Mike Hammer, 2427 Mike Jones, Steve Jones, Terry Zink, Tim Draegen. 2429 Grateful appreciation is extended to the people who provided feedback 2430 through the discuss mailing list. 2432 Appendix D. Comments and Feedback 2434 Please address all comments, discussions, and questions to 2435 dmarc@ietf.org [4]. Earlier discussions can be found at arc- 2436 discuss@dmarc.org [5]. 2438 Authors' Addresses 2440 Kurt Andersen 2441 LinkedIn 2442 1000 West Maude Ave 2443 Sunnyvale, California 94085 2444 USA 2446 Email: kurta@linkedin.com 2448 Brandon Long (editor) 2449 Google 2451 Email: blong@google.com 2453 Steven Jones (editor) 2454 TDP 2456 Email: smj@crash.com 2458 Seth Blank (editor) 2459 ValiMail 2461 Email: seth@valimail.com 2463 Murray Kucherawy (editor) 2464 TDP 2466 Email: superuser@gmail.com