idnits 2.17.1 draft-ietf-dmarc-arc-protocol-07.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: ARC sets built with algorithms that are being deprecated MAY be considered valid within an ARC chain, however, intermediaries MUST not create additional sets with the deprecated algorithm. -- The document date (July 21, 2017) is 2470 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '2' on line 1064 -- Looks like a reference, but probably isn't: '1' on line 1062 == Missing Reference: 'I-D.ARC' is mentioned on line 893, but not defined -- Looks like a reference, but probably isn't: '3' on line 1066 -- Looks like a reference, but probably isn't: '4' on line 1913 -- Looks like a reference, but probably isn't: '5' on line 1914 == Unused Reference: 'RFC1345' is defined on line 938, but no explicit reference was found in the text == Unused Reference: 'RFC2142' is defined on line 947, but no explicit reference was found in the text == Unused Reference: 'RFC2606' is defined on line 951, but no explicit reference was found in the text == Unused Reference: 'RFC4686' is defined on line 959, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 963, but no explicit reference was found in the text == Unused Reference: 'RFC5321' is defined on line 973, but no explicit reference was found in the text == Unused Reference: 'RFC5322' is defined on line 977, but no explicit reference was found in the text == Unused Reference: 'RFC5585' is defined on line 981, but no explicit reference was found in the text == Unused Reference: 'RFC5863' is defined on line 990, but no explicit reference was found in the text == Unused Reference: 'RFC6651' is defined on line 1005, but no explicit reference was found in the text == Unused Reference: 'ARC-USAGE' is defined on line 1032, but no explicit reference was found in the text == Unused Reference: 'RFC7960' is defined on line 1053, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1345 ** Downref: Normative reference to an Informational RFC: RFC 4686 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Downref: Normative reference to an Informational RFC: RFC 5585 ** Downref: Normative reference to an Informational RFC: RFC 5598 ** Downref: Normative reference to an Informational RFC: RFC 5863 ** Obsolete normative reference: RFC 7601 (Obsoleted by RFC 8601) -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) Summary: 7 errors (**), 0 flaws (~~), 15 warnings (==), 7 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: Standards Track B. Long, Ed. 5 Expires: January 22, 2018 Google 6 S. Jones, Ed. 7 M. Kucherawy, Ed. 8 TDP 9 July 21, 2017 11 Authenticated Received Chain (ARC) Protocol 12 draft-ietf-dmarc-arc-protocol-07 14 Abstract 16 The Authenticated Received Chain (ARC) protocol creates a mechanism 17 whereby a series of handlers of a message can conduct authentication 18 of a message as it passes among them on the way to its destination, 19 and record the status of that authentication at each step along the 20 handling path, for use by the final recipient in making choices about 21 the disposition of the message. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 22, 2018. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Instance ('i=') Tags . . . . . . . . . . . . . . . . . . . . 5 61 4.1. Valid Range for Instance Tags . . . . . . . . . . . . . . 6 62 5. The ARC Header Fields . . . . . . . . . . . . . . . . . . . . 6 63 5.1. ARC-Authentication-Results (AAR) . . . . . . . . . . . . 6 64 5.2. ARC-Message-Signature (AMS) . . . . . . . . . . . . . . . 7 65 5.3. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . . . 7 66 5.3.1. The 'cv' Tag . . . . . . . . . . . . . . . . . . . . 8 67 5.3.2. Selected Header Fields . . . . . . . . . . . . . . . 8 68 6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . 9 69 7. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . 10 70 8. Key Management . . . . . . . . . . . . . . . . . . . . . . . 11 71 9. Usage of Chain Validity . . . . . . . . . . . . . . . . . . . 11 72 9.1. Assessing Chain Validity Violations . . . . . . . . . . . 11 73 9.2. Marking and Sealing Invalid Chains . . . . . . . . . . . 11 74 9.3. Handling DNS Problems While Validating ARC . . . . . . . 12 75 9.4. Responding to ARC Validity Violations . . . . . . . . . . 12 76 9.5. Recording the Results of ARC Evaluation . . . . . . . . . 12 77 9.5.1. Output Information from an ARC Evaluation . . . . . . 12 78 9.5.2. Reporting ARC Effects for DMARC Local Policy - 79 Interim . . . . . . . . . . . . . . . . . . . . . . . 13 80 10. Supporting Alternate Signing Algorithms . . . . . . . . . . . 13 81 10.1. Introductory Period . . . . . . . . . . . . . . . . . . 14 82 10.2. Co-Existence Period . . . . . . . . . . . . . . . . . . 14 83 10.3. Deprecation Period . . . . . . . . . . . . . . . . . . . 14 84 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14 85 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 86 12.1. Authentication-Results Method Registry Update . . . . . 14 87 12.2. Definitions of the ARC header fields . . . . . . . . . . 15 88 13. Implementation Status . . . . . . . . . . . . . . . . . . . . 15 89 13.1. GMail test reflector and incoming validation . . . . . . 16 90 13.2. AOL test reflector and internal tagging . . . . . . . . 16 91 13.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 17 92 13.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . 17 93 13.5. Mailman addition . . . . . . . . . . . . . . . . . . . . 18 94 13.6. Copernica/MailerQ web-based validation . . . . . . . . . 18 95 13.7. Rspamd . . . . . . . . . . . . . . . . . . . . . . . . . 19 96 13.8. PERL Mail::Milter::Authentication module . . . . . . . . 19 98 14. Security Considerations . . . . . . . . . . . . . . . . . . . 20 99 14.1. Message Content Suspicion . . . . . . . . . . . . . . . 20 100 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 101 15.1. Normative References . . . . . . . . . . . . . . . . . . 20 102 15.2. Informative References . . . . . . . . . . . . . . . . . 22 103 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 23 104 Appendix A. Appendix A - Example Usage (Obsolete but retained 105 for illustrative purposes) . . . . . . . . . . . . . 23 106 A.1. Example 1: Simple mailing list . . . . . . . . . . . . . 23 107 A.1.1. Here's the message as it exits the Origin: . . . . . 23 108 A.1.2. Message is then received at example.org . . . . . . . 24 109 A.1.3. Example 1: Message received by Recipient . . . . . . 26 110 A.2. Example 2: Mailing list to forwarded mailbox . . . . . . 27 111 A.2.1. Here's the message as it exits the Origin: . . . . . 27 112 A.2.2. Message is then received at example.org . . . . . . . 28 113 A.2.3. Example 2: Message received by Recipient . . . . . . 32 114 A.3. Example 3: Mailing list to forwarded mailbox with source 34 115 A.3.1. Here's the message as it exits the Origin: . . . . . 34 116 A.3.2. Message is then received at example.org . . . . . . . 35 117 A.3.3. Example 3: Message received by Recipient . . . . . . 40 118 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 42 119 Appendix C. Comments and Feedback . . . . . . . . . . . . . . . 43 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 122 1. Introduction 124 Modern email authentication techniques such as the Sender Policy 125 Framework (SPF) [RFC7208] and DomainKeys Identified Mail (DKIM) 126 [RFC6376] have become ubiquitious. However, they are stymied by a 127 small number of common applications, most notably mailing list 128 managers, as these applications have handling properties that prevent 129 these authentication schemes from universal effectiveness. These 130 issues are described in substantial detail in those protocols' 131 defining documents as well as in [RFC6377]. 133 In an effort to reduce the success of fraudulent email campaigns, 134 there has been an effort to develop and deploy technologies that use 135 SPF and DKIM to assure legitimate use of the identity of the apparent 136 message author, i.e., the visible "From:" field in a message. To 137 this end, Domain-based Mail Authentication, Reporting and Compliance 138 (DMARC) [RFC7489] has been developed and deployed. However, its 139 deployment in environments where mailing lists are used has had the 140 negative impacts predicted in the documents listed above. 142 What is needed is a mechanism by which legitimate alteration of a 143 message, invalidating SPF and DKIM, does not ultimately result in a 144 rejection of an email message on delivery. An Authenticated Received 145 Chain (ARC), described here, provides a superset of the functionality 146 of DKIM in order to provide to the final message recipient a more 147 complete view into the handling chain of a message and the points in 148 that chain where alterations of the content may have occurred. 149 Equipped with this more compelte information, the final recipient can 150 make a more informed handling choice, reducing or eliminating the 151 false postives inherent in use of DKIM and/or SPF themselves. 153 2. Overview 155 In DKIM, every participating signing agent attaches a signature that 156 is based on the content of the message, local policy, and the domain 157 name of the participating Administrative Management Domain (ADMD). 158 Any verifier can process such a signature; a verified signature means 159 the message content that was "covered" by the signature has not been 160 altered since the signature was applied. The signatures themselves 161 are generally independent of one another. 163 By contrast, this protocol seeks to have each signature be able to 164 convey the following pieces of information: 166 1. As with DKIM, an assertion that, for a passing signature, the 167 domain name in the signature takes some responsibility for 168 handling of the message and that the message is unchanged since 169 that signature was applied; 171 2. A further assertion that, at the time that same ADMD processed 172 the message, the various assertions already attached to the 173 message by other ADMDs were or were not valid; 175 3. A further assertion that combines and protects the above against 176 alteration by later handlers. 178 This protocol accomplishes each of these by adding a new header field 179 to the message for each of them, as follows: 181 o ARC-Authentication-Results: (referred to below as "AAR") virtually 182 identical in syntax to an Authentication-Results field [RFC7601], 183 this field records the results of all message authentication 184 checks done by the recording ADMD at the time the message arrived; 186 o ARC-Message-Signature: (referred to below as "AMS") virtually 187 identical in syntax to DKIM-Signature, this field contains the 188 assertions about the message header and body as they existed at 189 the time of handling by the ADMD adding it; and 191 o ARC-Seal: (referred to below as "AS") highly similar in structure 192 and format to a DKIM-Signature, this field applies a digital 193 signature that protects the integrity of all three of these new 194 fields when they are added by an ADMD, plus all instances of these 195 fields added by prior ADMDs. 197 A distinguishing feature of all of these is that an ARC participant 198 always adds all of them before relaying a message to the next 199 handling agent en route to its destination. Moreover, as described 200 in Section 4, they each have an "instance" number that increases with 201 each ADMD in the handling chain so that their original order can be 202 preserved and the three of them can be processed as a group. 204 3. Terminology 206 This section defines terms used in the rest of the document. 208 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 209 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 210 document are to be interpreted as described in [RFC2119]. 212 Readers are encouraged to be familiar with the contents of [RFC5598], 213 and in particular, the potential roles of intermediaries in the 214 delivery of email. 216 Syntax descriptions use Augmented BNF (ABNF) [RFC5234]. 218 A single group of the header fields introduced in Section 2 is called 219 an "ARC Set", and the complete sequence of these groups is called an 220 "Authenticated Received Chain" or merely an "ARC chain". Although 221 the "Received" header field is typically not included in the signed 222 content, the name is based on the notion that this is in essence a 223 cryptographically signed series of header fields that attest to the 224 handling chain of a message much as Received fields always have. 226 4. Instance ('i=') Tags 228 The header fields comprising a single ARC set are identified by the 229 presence of a string in the value portion of the header field that 230 complies with the "tag-spec" ABNF found in Section 3.2 of [RFC6376]. 231 The tag-name is always the single character "i" and the value is the 232 text representation of a positive integer, indicating the position in 233 the ARC sequence this set occupies, where the first ARC set is 234 numbered 1. In ABNF terms: 236 instance = [FWS] %x69 [FWS] "=" [FWS] 1*DIGIT [FWS] ";" 238 At any delivery stage, it is an error if any ARC set is invalid 239 (i.e., does not contain exactly one of the three header fields 240 defined by this protocol). 242 Note that because the AMS and AS header field values are made up of 243 tag-spec constructs, the i= tag may be found anywhere within the 244 header field value, but is represented throughout this spec in the 245 initial position for convenience. Implementers SHOULD seek to start 246 with the i= tag to facilitate human inspection of the headers. 248 4.1. Valid Range for Instance Tags 250 The 'i' tag value can range from 1-1024 (inclusive). 252 ARC implementations MUST support at least ten (10) intermediary 253 steps. 255 More than fifty (50) intermediaries is considered extremely unlikely 256 so ARC chains with more than fifty intermediaries may be marked with 257 "cv=fail". 259 5. The ARC Header Fields 261 The three header fields that are part of this specification borrow 262 heavily from existing specifications. Rather than repeating all of 263 the formal definitions that are being recycled in ARC, this document 264 instead only describes and specifies changes in syntax and semantics. 266 5.1. ARC-Authentication-Results (AAR) 268 The ARC-Authentication-Results header field is defined. It is 269 syntactically and semantically identical to an Authentication-Results 270 header field [RFC7601] (A-R), as is the mechanism by which it is 271 constructed, with the following exception: 273 o There is an "i" tag, as described in Section 4. 275 The instance identifier MUST be separated from the rest of the 276 Authentication-Results value contents with a semi-colon (';', 0x3b). 278 An ARC signer generates this field in the same way that a 279 conventional A-R field would be generated. Because the AAR is 280 designed for machine-based consumption over the course of a message's 281 transit through a series of mediators and to facilitate 282 troubleshooting of problematic sources by sending organizations, two 283 additional fields of data SHOULD be added to the normal A-R content, 284 if available to the A-R generating system: 286 o source.ip - The connecting client IP address from which the 287 message is received; and 289 o header.s - The selector value associated with each dkim signature 290 (added to the dkim or arc data sections of the A-R/AAR record 292 The purpose of this header field is to incorporate into the record 293 the success or failure of any authentication done on the message 294 upstream of the participating ADMD, to validate and continue the 295 authentication chain. 297 In processing, some architectures will generate multiple A-R records 298 for the same authserv-id. In such cases, the resinfo value from each 299 of the A-R records should be concatenated into a single record just 300 as they would have been if they were generated in a single A-R 301 record. 303 5.2. ARC-Message-Signature (AMS) 305 The ARC-Message-Signature header field is defined. It is 306 syntactically and semantically identical to a DKIM-Signature header 307 field [RFC6376], as is the mechanism by which it is constructed, with 308 the following exceptions: 310 o There is an "i" tag, as described in Section 4. 312 o There is no "v" tag. 314 o ARC-Seal header fields MUST never be included in the content 315 covered by the signature in this header field. 317 The AMS SHOULD include any DKIM-Signature header fields already 318 present on the message in the header fields covered by this 319 signature. 321 Authentication-Results header fields SHOULD NOT be included since 322 they are likely to be deleted by downstream ADMDs, thereby breaking 323 the AMS signature. 325 As with a DKIM-Signature, the purpose of this header field is to 326 allow the ADMD generating it to take some responsibility for handling 327 this message as it progresses toward delivery. 329 5.3. ARC-Seal (AS) 331 The ARC-Seal header field is defined. It is syntactically and 332 semantically similar to a DKIM-Signature field, with the following 333 exceptions: 335 o There is an "i" tag, as described in Section 4. 337 o The ARC-Seal covers none of the body content of the message. It 338 only covers specific header fields. (See below: Section 5.3.2.) 339 As a result, no body canonicalization is done. Further, only 340 "relaxed" header canonicalization (Section 3.4.2 of [RFC6376]) is 341 used. 343 o The only supported tags are "i" (Section 4 supercedes the 344 [RFC6376] definition), and "a", "b", "d, "s", "t". The latter 5 345 tag definitions are copied from Section 3.5 of [RFC6376]. 347 o An additional tag, "cv" is defined. (See below: Section 5.3.1) 349 The purpose of this field is to assure the integrity of the ARC set 350 being added by the ADMD generating this header field, and moreover to 351 ensure no tampering with the ARC overall. 353 5.3.1. The 'cv' Tag 355 A new tag "cv" (chain validation) is defined, which indicates the 356 state of the ARC chain as evaluated when it arrived at the ADMD 357 adding this header field. It includes one of three possible values: 359 o none: There was no chain on the message when it arrived for 360 validation; typically occurs when the message arrives at a Message 361 Transfer Agent (MTA) from a Message Submission Agent (MSA) or when 362 any upstream MTAs may not be participating in ARC handling; 364 o fail: The message has a chain whose validation failed; 366 o pass: The message has a chain whose validation succeeded. 368 In ABNF terms: 370 seal-cv-tag = %x63.76 [FWS] "=" [FWS] 371 ("none" / "fail" / "pass") 373 5.3.2. Selected Header Fields 375 The ARC-Seal signature is an encryption of the hash of the 376 concatenation of the canonicalized form of the ARC sets present on 377 the message at the time of sealing, in increasing instance order, 378 starting at 1, including the one being added at the time of sealing 379 the message. 381 Within a set, the header fields are presented in the following order: 383 1. ARC-Authentication-Results 384 2. ARC-Message-Signature 386 3. ARC-Seal 388 Where the ARC-Seal is the one being generated, it is presented to the 389 hash function in its final form except with an empty "b=" value, in 390 the same manner by which a DKIM-Signature signs itself. 392 6. Verifier Actions 394 The verifier takes the following steps to determine the current state 395 of the ARC on the message: 397 1. Collect all ARC sets currently on the message. If there were 398 none, the ARC state is "none" and the algorithm stops here. 400 2. If any ARC set is invalid (e.g., does not contain exactly one of 401 each of the three ARC-specific header fields), then the chain 402 state is "fail" and the algorithm stops here. 404 3. Conduct verification of the ARC-Message-Signature header field 405 bearing the highest instance number. If this verification fails, 406 then the chain state is "fail" and the algorithm stops here. 408 4. For each ARC-Seal from the "N"th instance to the first, apply the 409 following logic: 411 1. If the value of the "cv" tag on that seal is "fail", the 412 chain state is "fail" and the algorithm stops here. 414 2. If the instance number being processed is greater than 1 and 415 the value of the "cv" tag is "none", the chain state is 416 "fail" and the algorithm stops here. 418 3. If the instance number being processed is 1 and the value of 419 the "cv" tag is not "none", the chain state is "fail" and the 420 algorithm stops here. 422 4. Prepare a hash function corresponding to the "a" tag of the 423 ARC-Seal. 425 5. Compute the canonicalized form of the ARC header fields, in 426 the order described in Section 5.3.2, using the "relaxed" 427 header canonicalization defined in (Section 3.4.2 of 428 [RFC6376]. Pass them to the hash function. 430 6. Retrieve the final digest from the hash function. 432 7. Retrieve the public key identified by the "s" and "d" tags in 433 the ARC-Seal, as described in Section 8. 435 8. Determine whether the signature portion ("b" tag) of the ARC- 436 Seal and the digest computed above are valid according to the 437 public key. 439 9. If the signature is not valid, the chain state is "fail" and 440 the algorithm stops here. 442 5. If all seals pass validation, then the chain state is "pass", and 443 the algorithm is complete. 445 The verifier should record the cv state for subsequent use by any 446 sealing which may be done later (potentially after message 447 modification) within the same trust boundary. The cv state may be 448 recorded by sealing at the time of verification in an additional ARC 449 set or may be recorded out of band depending on the architecture of 450 the ADMD. 452 7. Signer Actions 454 This section includes a walk-through of the actions an ARC signing 455 implementation takes when presented with a message. 457 The signing agent should undertake the following steps: 459 1. Do any authentication steps that the ADMD normally does: 461 1. If a message is traveling within the same trust boundary, 462 this would include any transitive trust conveyance with the 463 message; 465 2. If a message is coming from outside the same trust boundary, 466 this would include any SPF / DKIM / DMARC / other 467 authentication evaluation steps. 469 2. Do any DKIM signing or authentication assertion steps that the 470 ADMD normally does. 472 3. Generate and optionally attach to the message an Authentication- 473 Results header field using the ADMD's authserv-id (see 474 Section 2.5 of [RFC7601]) indicating whatever authentication 475 might have been done by the MTA, or possibly indicate that none 476 was done. 478 1. If an ARC chain exists on the message, then set "N" equal to 479 the highest instance number found on the chain (i=); 480 otherwise set "N" equal to zero for the following steps. 482 4. Generate and attach to the message an ARC-Authentication-Results 483 header field using instance number N+1 and the same content from 484 the previous step. 486 5. Generate and attach to the message an ARC-Message-Signature 487 header field using the general algorithm described in Section 5 488 of [RFC6376] and as modified in Section 5.1 above, using instance 489 number N+1. 491 6. Generate and attach to the message an ARC-Seal header field using 492 the general algorithm described in Section 5.3 above, using a 493 chain validation status as determined in Section 6 and instance 494 number N+1. 496 8. Key Management 498 The public keys for ARC header fields follow the same requirements, 499 syntax and semantics as those for DKIM signatures, described in 500 Section 3.6 of [RFC6376]. Operators may use distinct selectors and/ 501 or domains for the ARC header fields at their own discretion. 503 9. Usage of Chain Validity 505 9.1. Assessing Chain Validity Violations 507 There are a wide variety of ways in which the ARC set of header 508 fields can be broken. Receivers need to be wary of ascribing motive 509 to such breakage although patterns of common behaviour may provide 510 some basis for adjusting local policy decisions. 512 This specification is exclusively focused on well-behaved, 513 participating intermediaries that result in a valid chain of ARC- 514 related header fields. The value of such a well-formed, valid chain 515 needs to be interpreted with care since malicious content can be 516 easily introduced by otherwise well-intended senders through machine 517 or account compromises. All normal content-based analysis still 518 needs to be performed on any messages bearing a valid chain of ARC 519 header sets. 521 9.2. Marking and Sealing Invalid Chains 523 The header fields signed by the AS header field b= value in the case 524 of a major violation MUST be only the matching 'i=' instance headers 525 created by the MTA which detected the malformed chain, as if this 526 newest ARC set was the only set present. (This is the same procedure 527 required for handling major/structural validity problems.) 529 9.3. Handling DNS Problems While Validating ARC 531 DNS failures to resolve or return data which is needed for ARC 532 validation SHOULD result in a 421 tempfail during the SMTP 533 conversation with the sending system. Temporary or intermittent DNS 534 problems will generally not be sufficiently transitory to allow a 535 mediator to obtain a different result during the ordinary transit 536 duration so it is better to have the source system queue the 537 problematic message(s) than to generate (potential) backscatter. 539 DNS-based failures to verify a chain are treated no differently than 540 any other ARC violation. They result in a cv=fail verdict. 542 9.4. Responding to ARC Validity Violations 544 If a receiver determines that the ARC chain has failed, the receiver 545 MAY signal the breakage through the extended SMTP response code 5.7.7 546 [RFC3463] "message integrity failure" [ENHANCED-STATUS] and 547 corresponding SMTP response code. 549 9.5. Recording the Results of ARC Evaluation 551 Receivers MAY add an "arc=[pass|fail|policy]" method annotation into 552 a locally-affixed Authentication-Results [RFC7601] header field along 553 with any salient comment(s). 555 9.5.1. Output Information from an ARC Evaluation 557 The evaluation of a series of ARC sets results in the following data 558 which MAY be used to inform local-policy decisions: 560 o A list of the "d=" domains found in the validated (== all) ARC- 561 Seal header fields; 563 o The "d=" domain found in the most recent (highest instance number) 564 AMS header field (since that is the only one necessarily 565 validated) 567 In the case of a failed chain, only the terminal ARC set is covered 568 by the ARC-Seal so the reporting is limited to the findings in that 569 terminal ARC set. 571 9.5.2. Reporting ARC Effects for DMARC Local Policy - Interim 573 [[ Note: Discussion on the IETF DMARC-WG list has indicated some 574 interest in more substantial reporting for analytic purposes. To 575 support that effort, the following guidance is provided only as an 576 interim, minimal data set. A more complete reporting construct will 577 be specified in a related spec - TBD. (see also the note at 578 Section 5.1) ]] 580 Receivers SHOULD indicate situations in which ARC evaluation 581 influenced the results of their local policy determination. DMARC 582 reporting of ARC-informed decisions is augmented by adding a 583 local_policy comment explanation containing the list of data 584 discovered in the ARC evaluation (Section 9.5.1): 586 587 delivered 588 fail 589 fail 590 591 local_policy 592 arc=pass ams=d2.example d=d2.example,d1.example 593 594 596 In the suggested sample, d2.example is the sealing domain for ARC[2] 597 and d1.example is the sealing domain for ARC[1]. 599 Mediators SHOULD generate DMARC reports on messages which transit 600 their system just like any other message which they receive. This 601 will result in multiple reports for each mediated message as they 602 transit the series of handlers. DMARC report consumers should be 603 aware of this behaviour and make the necessary accommodations. 605 10. Supporting Alternate Signing Algorithms 607 [[ Note: Some additional development of this section is needed. ]] 609 In the following branch diagrams, each algorithm is represented by an 610 'A' or 'B' at each hop to depict the ARC chain that develops over a 611 five hop scenario. 'x' represents a hop that does not support that 612 algorithm. 614 Note that during a transitional period where multiple algorithms are 615 allowed, all of the statements in this spec which refer to "exactly 616 one set of ARC headers per instance" need to be understood as "at 617 least one set per instance and no more than one instance-set per 618 algorithm". 620 10.1. Introductory Period 622 Intermediaries MUST be able to validate ARC chains build with either 623 algorithm but MAY create ARC sets with either (or both) algorithm. 625 The introductory period should be at least six (6) months. 627 10.2. Co-Existence Period 629 Intermediaries MUST be able to validate ARC chains build with either 630 algorithm and MUST create ARC sets with both algorithms. Chains 631 ending with either algorithm may be used for the result. 633 10.3. Deprecation Period 635 ARC sets built with algorithms that are being deprecated MAY be 636 considered valid within an ARC chain, however, intermediaries MUST 637 not create additional sets with the deprecated algorithm. 639 The deprecation period should be at least two (2) years. 641 11. Privacy Considerations 643 The ARC chain provides a verifiable record of the handlers for a 644 message. Anonymous remailers will probably not find this to match 645 their operating goals. 647 12. IANA Considerations 649 This specification adds three new header fields as defined below. 651 12.1. Authentication-Results Method Registry Update 653 This draft adds one item to the IANA "Email Authentication Methods" 654 registry: 656 o Method : arc 658 Defined: [I-D.ARC] 660 ptype: header 662 Property: chain evaluation result 664 Value: chain evaluation result status (see Section 5.3) 666 Status: active 667 Version: 1 669 12.2. Definitions of the ARC header fields 671 This specification adds three new header fields to the "Permanent 672 Message Header Field Registry", as follows: 674 o Header field name: ARC-Seal 676 Applicable protocol: mail 678 Status: draft 680 Author/Change controller: IETF 682 Specification document(s): [I-D.ARC] 684 Related information: [RFC6376] 686 o Header field name: ARC-Message-Signature 688 Applicable protocol: mail 690 Status: draft 692 Author/Change controller: IETF 694 Specification document(s): [I-D.ARC] 696 Related information: [RFC6376] 698 o Header field name: ARC-Authentication-Results 700 Applicable protocol: mail 702 Status: standard 704 Author/Change controller: IETF 706 Specification document(s): [I-D.ARC] 708 Related information: [RFC7601] 710 13. Implementation Status 712 [[ Note to the RFC Editor: Please remove this section before 713 publication along with the reference to [RFC6982]. ]] 714 This section records the status of known implementations of the 715 protocol defined by this specification at the time of posting of this 716 Internet-Draft, and is based on a proposal described in [RFC6982]. 717 The description of implementations in this section is intended to 718 assist the IETF in its decision processes in progressing drafts to 719 RFCs. Please note that the listing of any individual implementation 720 here does not imply endorsement by the IETF. Furthermore, no effort 721 has been spent to verify the information presented here that was 722 supplied by IETF contributors. This is not intended as, and must not 723 be construed to be, a catalog of available implementations or their 724 features. Readers are advised to note that other implementations may 725 exist. 727 This information is known to be correct as of the seventh 728 interoperability test event which was held on 2017-07-15 & 16 at 729 IETF99. 731 13.1. GMail test reflector and incoming validation 733 Organization: Google 735 Description: Internal prototype implementation with both debug 736 analysis and validating + sealing pass-through function 738 Status of Operation: Production - Incoming Validation 740 Coverage: Full spec implemented as of [ARC-DRAFT-03] 742 Licensing: Proprietary - Internal only 744 Implementation Notes: Full functionality was demonstrated during the 745 interop testing on 2016-06-17 747 In place for reporting usage only as of 2016-11-21 on all GMail 748 flows. 750 Rechecked general incoming validation as of 2017-02-24 interop event. 752 Contact Info: arc-discuss@dmarc.org [1] 754 13.2. AOL test reflector and internal tagging 756 Organization: AOL 758 Description: Internal prototype implementation with both debug 759 analysis and validating + sealing pass-through function 761 Status of Operation: Beta 762 Coverage: ARC chain validity status checking is not operational, but 763 otherwise this system conforms to [ARC-DRAFT-03] 765 Licensing: Proprietary - Internal only 767 Implementation Notes: Full functionality with the exception of chain 768 validity checking was demonstrated during the interop testing on 769 2016-06-17 771 Available for production mail via selected account whitelisting for 772 test validation only. 774 Intermittent stability problems discovered at the interop event on 775 2017-02-24. Remediation underway as of the publication of this 776 draft. 778 Contact Info: arc-discuss@dmarc.org [2] 780 13.3. dkimpy 782 Organization: dkimpy developers 784 Description: Python DKIM package 786 Status of Operation: Production 788 Coverage: The internal test suite is incomplete, but the command line 789 developmental version of validator was demonstrated to interoperate 790 with the Google and AOL implementations during the interop on 791 2016-06-17 and the released version passes the tests in [ARC-TEST] 792 https://github.com/ValiMail/arc_test_suite with both python and 793 python3. 795 Licensing: Open/Other (same as dkimpy package) 797 Contact Info: https://launchpad.net/dkimpy 799 13.4. OpenARC 801 Organization: TDP/Murray Kucherawy 803 Description: Implemention of milter functionality related to the 804 OpenDKIM and OpenDMARC packages 806 Status of Operation: Beta 808 Coverage: Built to support [ARC-DRAFT-03] 809 Licensing: Open/Other (same as OpenDKIM and OpenDMARC packages) 811 Implementation Notes: The build is FreeBSD oriented and takes some 812 tweaks to build on RedHat-based Linux platforms. 814 Initial testing during the 815 interop event on 2016-06-17 showed that it can be operational, but the 816 documentation regarding configuration settings is unclear and the 817 generated signature values do not validate when compared to the Google, 818 AOL or dkimpy implementations. 820 Testing during the 2017-02-24 interop event showed that some of the 821 problems have been fixed, but there are still interoperability problems 822 when trying to use OpenARC in a "sandwich" configuration around a MLM. 824 Contact Info: arc-discuss@dmarc.org [3] 826 13.5. Mailman addition 828 Organization: Mailman development team 830 Description: Integrated ARC capabilities within the Mailman package 832 Status of Operation: Patch submitted 834 Coverage: Unknown 836 Licensing: Same as mailman package - GPL 838 Implementation Notes: Incomplete at this time 840 Contact Info: https://www.gnu.org/software/mailman/contact.html 842 13.6. Copernica/MailerQ web-based validation 844 Organization: Copernica 846 Description: Web-based validation of ARC-signed messages 848 Status of Operation: Beta 850 Coverage: Built to support [ARC-DRAFT-03] 852 Licensing: On-line usage only 854 Implementation Notes: Released 2016-10-24 855 Requires full message content to be pasted into a web form found at 856 http://arc.mailerq.com/ (warning - https is not supported). 858 An additional instance of an ARC signature can be added if one is 859 willing to paste a private key into an unsecured web form. 861 Initial testing shows that results match the other implementations 862 listed in this section. 864 Contact Info: [https://www.copernica.com/] 866 13.7. Rspamd 868 Organization: Rspamd community 870 Description: ARC signing and verification module 872 Status of Operation: Production, though deployment usage is unknown 874 Coverage: Built to support [ARC-DRAFT-03] 876 Licensing: Open source 878 Implementation Notes: Released with version 1.6.0 on 2017-06-12 880 Contact Info: [https://rspamd.com/doc/modules/arc.html] and 881 [https://github.com/vstakhov/rspamd] 883 13.8. PERL Mail::Milter::Authentication module 885 Organization: FastMail 887 Description: Email domain authentication milter, previously included 888 SPF / DKIM / DMARC, now has ARC added 890 Status of Operation: Intial validation completed during IETF99 891 hackathon with some follow-on work during the week 893 Coverage: Built to support [I-D.ARC] 895 Licensing: Open Source 897 Implementation Notes: 899 Contact Info: https://github.com/fastmail/authentication_milter 901 14. Security Considerations 903 The Security Considerations of [RFC6376] and [RFC7601] apply directly 904 to this specification. 906 Inclusion of ARC sets in the header of emails may cause problems for 907 some older or more constrained MTAs if they are unable to accept the 908 greater size of the header. 910 Operators who receive a message bearing N ARC sets has to complete 911 N+1 DNS queries to evaluate the chain (barring DNS redirection 912 mechanisms which can increase the lookups for a given target value). 913 This has at least two effects: 915 1. An attacker can send a message to an ARC partipant with a 916 concocted sequence of ARC sets bearing the domains of intended 917 victims, and all of them will be queried by the participant until 918 a failure is discovered. 920 2. DKIM only does one DNS check per signature, while this one can do 921 many. Absent caching, slow DNS responses can cause SMTP 922 timeouts; this could be exploited as a DoS attack. 924 14.1. Message Content Suspicion 926 Recipients are cautioned to treat messages bearing ARC sets with the 927 same suspicion that they apply to all other email messages. This 928 includes appropriate content scanning and other checks for 929 potentially malicious content. The handlers which are identified 930 within the ARC-Seal chain may be used to provide input to local 931 policy engines in cases where the sending system's DKIM-Signature 932 does not validate. 934 15. References 936 15.1. Normative References 938 [RFC1345] Simonsen, K., "Character Mnemonics and Character Sets", 939 RFC 1345, DOI 10.17487/RFC1345, June 1992, 940 . 942 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 943 Requirement Levels", BCP 14, RFC 2119, 944 DOI 10.17487/RFC2119, March 1997, 945 . 947 [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and 948 Functions", RFC 2142, DOI 10.17487/RFC2142, May 1997, 949 . 951 [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS 952 Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999, 953 . 955 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", 956 RFC 3463, DOI 10.17487/RFC3463, January 2003, 957 . 959 [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys 960 Identified Mail (DKIM)", RFC 4686, DOI 10.17487/RFC4686, 961 September 2006, . 963 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 964 IANA Considerations Section in RFCs", RFC 5226, 965 DOI 10.17487/RFC5226, May 2008, 966 . 968 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 969 Specifications: ABNF", STD 68, RFC 5234, 970 DOI 10.17487/RFC5234, January 2008, 971 . 973 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 974 DOI 10.17487/RFC5321, October 2008, 975 . 977 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 978 DOI 10.17487/RFC5322, October 2008, 979 . 981 [RFC5585] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys 982 Identified Mail (DKIM) Service Overview", RFC 5585, 983 DOI 10.17487/RFC5585, July 2009, 984 . 986 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 987 DOI 10.17487/RFC5598, July 2009, 988 . 990 [RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, 991 "DomainKeys Identified Mail (DKIM) Development, 992 Deployment, and Operations", RFC 5863, 993 DOI 10.17487/RFC5863, May 2010, 994 . 996 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 997 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 998 RFC 6376, DOI 10.17487/RFC6376, September 2011, 999 . 1001 [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and 1002 Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377, 1003 September 2011, . 1005 [RFC6651] Kucherawy, M., "Extensions to DomainKeys Identified Mail 1006 (DKIM) for Failure Reporting", RFC 6651, 1007 DOI 10.17487/RFC6651, June 2012, 1008 . 1010 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 1011 Authorizing Use of Domains in Email, Version 1", RFC 7208, 1012 DOI 10.17487/RFC7208, April 2014, 1013 . 1015 [RFC7601] Kucherawy, M., "Message Header Field for Indicating 1016 Message Authentication Status", RFC 7601, 1017 DOI 10.17487/RFC7601, August 2015, 1018 . 1020 15.2. Informative References 1022 [ARC-DRAFT-03] 1023 Andersen, K., Rae-Grant, J., Long, B., Adams, T., and S. 1024 Jones, "Authenticated Received Chain (ARC) Protocol 1025 (I-D-03)", April 2017, . 1028 [ARC-TEST] 1029 Blank, S., "ARC Test Suite", January 2017, 1030 . 1032 [ARC-USAGE] 1033 Jones, S., Adams, T., Rae-Grant, J., and K. Andersen, 1034 "Recommended Usage of the ARC Headers", December 2017, 1035 . 1038 [ENHANCED-STATUS] 1039 "IANA SMTP Enhanced Status Codes", n.d., 1040 . 1043 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1044 Code: The Implementation Status Section", RFC 6982, 1045 DOI 10.17487/RFC6982, July 2013, 1046 . 1048 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 1049 Message Authentication, Reporting, and Conformance 1050 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 1051 . 1053 [RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky, 1054 E., Ed., and K. Andersen, Ed., "Interoperability Issues 1055 between Domain-based Message Authentication, Reporting, 1056 and Conformance (DMARC) and Indirect Email Flows", 1057 RFC 7960, DOI 10.17487/RFC7960, September 2016, 1058 . 1060 15.3. URIs 1062 [1] mailto:arc-discuss@dmarc.org 1064 [2] mailto:arc-discuss@dmarc.org 1066 [3] mailto:arc-discuss@dmarc.org 1068 [4] mailto:dmarc@ietf.org 1070 [5] mailto:arc-discuss@dmarc.org 1072 Appendix A. Appendix A - Example Usage (Obsolete but retained for 1073 illustrative purposes) 1075 [[ Note: The following examples were mocked up early in the 1076 definition process for the spec. They no longer reflect the current 1077 definition and need various updates which will be included in draft 1078 -08. ]] 1080 A.1. Example 1: Simple mailing list 1082 A.1.1. Here's the message as it exits the Origin: 1084 Return-Path: 1085 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 1086 (authenticated bits=0) 1087 by segv.d1.example with ESMTP id t0FN4a8O084569; 1088 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 1089 (envelope-from jqd@d1.example) 1090 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; 1091 s=20130426; t=1421363082; 1092 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 1093 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: 1094 Content-Transfer-Encoding; 1095 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw 1096 bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl 1097 gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 1098 Message-ID: <54B84785.1060301@d1.example> 1099 Date: Thu, 14 Jan 2015 15:00:01 -0800 1100 From: John Q Doe 1101 To: arc@dmarc.org 1102 Subject: Example 1 1104 Hey gang, 1105 This is a test message. 1106 --J. 1108 A.1.2. Message is then received at example.org 1110 A.1.2.1. Example 1, Step A: Message forwarded to list members 1112 Processing at example.org: 1114 o example.org performs authentication checks 1116 o No previous Auth-Results or ARC-Seal headers are present 1118 o example.org adds ARC-Auth-Results header 1120 o example.org adds Received: header 1122 o example.org adds a ARC-Seal header 1124 Here's the message as it exits example.org: 1126 Return-Path: 1127 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 1128 s=seal2015; d=example.org; cv=none; 1129 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 1130 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 1131 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 1132 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; 1133 d=example.org; s=clochette; t=1421363105; 1134 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; 1135 h=List-Id:List-Unsubscribe:List-Archive:List-Post: 1136 List-Help:List-Subscribe:Reply-To:DKIM-Signature; 1137 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1F5 1138 vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+m4bw 1139 a6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= 1140 Received: from segv.d1.example (segv.d1.example [72.52.75.15]) 1141 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 1142 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) 1143 (envelope-from jqd@d1.example) 1144 ARC-Authentication-Results: i=1; lists.example.org; 1145 spf=pass smtp.mfrom=jqd@d1.example; 1146 dkim=pass (1024-bit key) header.i=@d1.example; 1147 dmarc=pass 1148 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 1149 (authenticated bits=0) 1150 by segv.d1.example with ESMTP id t0FN4a8O084569; 1151 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 1152 (envelope-from jqd@d1.example) 1153 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; 1154 s=20130426; t=1421363082; 1155 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 1156 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: 1157 Content-Transfer-Encoding; 1158 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr 1159 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G 1160 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 1161 Message-ID: <54B84785.1060301@d1.example> 1162 Date: Thu, 14 Jan 2015 15:00:01 -0800 1163 From: John Q Doe 1164 To: arc@example.org 1165 Subject: [Lists] Example 1 1167 Hey gang, 1168 This is a test message. 1169 --J. 1171 A.1.3. Example 1: Message received by Recipient 1173 Let's say that the Recipient is example.com 1175 Processing at example.com: 1177 o example.com performs usual authentication checks 1179 o example.com adds Auth-Results: header, Received header 1181 o Determines that message fails DMARC 1183 o Checks for ARC-Seal: header; finds one 1185 o Validates the signature in the ARC-Seal: header, which covers the 1186 ARC-Authentication-Results: header 1188 o example.com can use the ARC-Authentication-Results values or 1189 verify the DKIM-Signature from lists.example.org 1191 Here's what the message looks like at this point: 1193 Return-Path: 1194 Received: from example.org (example.org [208.69.40.157]) 1195 by clothilde.example.com with ESMTP id 1196 d200mr22663000ykb.93.1421363207 1197 for ; Thu, 14 Jan 2015 15:02:40 -0800 (PST) 1198 Authentication-Results: clothilde.example.com; spf=fail 1199 smtp.from=jqd@d1.example; dkim=pass (1024-bit key) 1200 header.i=@example.org; dmarc=fail; arc=pass 1201 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 1202 s=seal2015; d=example.org; cv=none; 1203 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 1204 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 1205 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 1206 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; 1207 d=example.org; s=clochette; t=1421363105; 1208 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; 1209 h=List-Id:List-Unsubscribe:List-Archive:List-Post: 1210 List-Help:List-Subscribe:Reply-To:DKIM-Signature; 1211 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF 1212 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3 1213 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= 1214 Received: from segv.d1.example (segv.d1.example [72.52.75.15]) 1215 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 1216 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) 1217 (envelope-from jqd@d1.example) 1218 ARC-Authentication-Results: i=1; lists.example.org; 1219 spf=pass smtp.mfrom=jqd@d1.example; 1220 dkim=pass (1024-bit key) header.i=@d1.example; 1221 dmarc=pass 1222 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 1223 (authenticated bits=0) 1224 by segv.d1.example with ESMTP id t0FN4a8O084569; 1225 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 1226 (envelope-from jqd@d1.example) 1227 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; 1228 s=20130426; t=1421363082; 1229 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 1230 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: 1231 Content-Transfer-Encoding; 1232 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw 1233 bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl 1234 gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 1235 Message-ID: <54B84785.1060301@d1.example> 1236 Date: Thu, 14 Jan 2015 15:00:01 -0800 1237 From: John Q Doe 1238 To: arc@example.org 1239 Subject: [Lists] Example 1 1241 Hey gang, 1242 This is a test message. 1243 --J. 1245 A.2. Example 2: Mailing list to forwarded mailbox 1247 A.2.1. Here's the message as it exits the Origin: 1249 Return-Path: 1250 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 1251 (authenticated bits=0) 1252 by segv.d1.example with ESMTP id t0FN4a8O084569; 1253 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 1254 (envelope-from jqd@d1.example) 1255 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; 1256 s=20130426; t=1421363082; 1257 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 1258 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: 1259 Content-Transfer-Encoding; 1260 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw 1261 bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl 1262 gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 1263 Message-ID: <54B84785.1060301@d1.example> 1264 Date: Thu, 14 Jan 2015 15:00:01 -0800 1265 From: John Q Doe 1266 To: arc@example.org 1267 Subject: Example 1 1269 Hey gang, 1270 This is a test message. 1271 --J. 1273 A.2.2. Message is then received at example.org 1275 A.2.2.1. Example 2, Step A: Message forwarded to list members 1277 Processing at example.org: 1279 o example.org performs authentication checks 1281 o example.org applies standard DKIM signature 1283 o No previous Auth-Results or ARC-Seal headers are present 1285 o example.org adds ARC-Auth-Results header 1287 o example.org adds usual Received: header 1289 o example.org adds a ARC-Seal header 1291 Here's the message as it exits Step A: 1293 Return-Path: 1294 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 1295 s=seal2015; d=example.org; cv=none; 1296 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6 1297 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L 1298 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 1299 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; 1300 d=example.org; s=clochette; t=1421363105; 1301 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; 1302 h=List-Id:List-Unsubscribe:List-Archive:List-Post: 1303 List-Help:List-Subscribe:Reply-To:DKIM-Signature; 1304 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF 1305 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3 1306 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= 1307 Received: from segv.d1.example (segv.d1.example [72.52.75.15]) 1308 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 1309 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) 1310 (envelope-from jqd@d1.example) 1311 ARC-Authentication-Results: i=1; lists.example.org; 1312 spf=pass smtp.mfrom=jqd@d1.example; 1313 dkim=pass (1024-bit key) header.i=@d1.example; 1314 dmarc=pass 1315 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 1316 (authenticated bits=0) 1317 by segv.d1.example with ESMTP id t0FN4a8O084569; 1318 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 1319 (envelope-from jqd@d1.example) 1320 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; 1321 s=20130426; t=1421363082; 1322 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 1323 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: 1324 Content-Transfer-Encoding; 1325 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr 1326 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G 1327 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 1328 Message-ID: <54B84785.1060301@d1.example> 1329 Date: Thu, 14 Jan 2015 15:00:01 -0800 1330 From: John Q Doe 1331 To: arc@example.org 1332 Subject: [Lists] Example 1 1334 Hey gang, 1335 This is a test message. 1336 --J. 1338 A.2.2.2. Example 2, Step B: Message from list forwarded 1340 The message is delivered to a mailbox at gmail.com 1341 Processing at gmail.com: 1343 o gmail.com performs usual authentication checks 1345 o gmail.com adds Auth-Results: and Received: header 1347 o Determines that message fails DMARC 1349 o Checks for ARC-Seal: header; finds one 1351 o Validates the signature in the ARC-Seal: header, which covers the 1352 ARC-Authentication-Results: header 1354 o Uses the ARC-Auth-Results: values, but: 1356 o Instead of delivering message, prepares to forward message per 1357 user settings 1359 o Applies usual DKIM signature 1361 o gmail.com adds it's own ARC-Seal: header, contents of which are 1363 * version 1365 * sequence number ("i=2") 1367 * hash algorithm (SHA256 as example) 1369 * timestamp ("t=") 1371 * selector for key ("s=notary01") 1373 * domain for key ("d=gmail.com") 1375 * headers included in hash ("h=ARC-Authentication-Results:ARC- 1376 Seal") 1378 * Note: algorithm requires only ARC-Seals with lower sequence # 1379 be included, in ascending order 1381 * signature of the header hash 1383 Here's what the message looks like at this point: 1385 Return-Path: 1386 ARC-Seal: i=2; a=rsa-sha256; t=1421363253; 1387 s=notary01; d=gmail.com; cv=pass; 1388 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDWR 1389 YbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/sut 1390 txO+RRNr0fCFw== 1391 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; 1392 d=gmail.com; s=20120806; 1393 h=mime-version:content-type:x-original-sender: 1394 x-original-authentication-results:precedence:mailing-list: 1395 list-id:list-post:list-help:list-archive:sender:reply-to: 1396 list-unsubscribe:DKIM-Signature; 1397 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=; 1398 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 1399 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 1400 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBmfhS 1401 LF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJRFeM 1402 KdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwDBJtXw 1403 bQoZyRtb6X6q0mYaszUB8kw== 1404 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10 1405 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST) 1406 Authentication-Results: i=2; gmail.com; spf=fail 1407 smtp.from=jqd@d1.example; dkim=pass (1024-bit key) 1408 header.i=@example.org; dmarc=fail; arc=pass 1409 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 1410 s=seal2015; d=example.org; cv=none: 1411 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 1412 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 1413 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 1414 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; 1415 d=example.org; s=clochette; t=1421363105; 1416 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; 1417 h=List-Id:List-Unsubscribe:List-Archive:List-Post: 1418 List-Help:List-Subscribe:Reply-To:DKIM-Signature; 1419 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF 1420 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3 1421 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= 1422 Received: from segv.d1.example (segv.d1.example [72.52.75.15]) 1423 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 1424 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) 1425 (envelope-from jqd@d1.example) 1426 ARC-Authentication-Results: i=1; lists.example.org; 1427 spf=pass smtp.mfrom=jqd@d1.example; 1428 dkim=pass (1024-bit key) header.i=@d1.example; 1429 dmarc=pass 1430 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 1431 (authenticated bits=0) 1432 by segv.d1.example with ESMTP id t0FN4a8O084569; 1433 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 1434 (envelope-from jqd@d1.example) 1435 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; 1436 s=20130426; t=1421363082; 1437 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 1438 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: 1439 Content-Transfer-Encoding; 1440 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr 1441 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G 1442 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 1443 Message-ID: <54B84785.1060301@d1.example> 1444 Date: Thu, 14 Jan 2015 15:00:01 -0800 1445 From: John Q Doe 1446 To: arc@example.org 1447 Subject: [Lists] Example 1 1449 Hey gang, 1450 This is a test message. 1451 --J. 1453 A.2.3. Example 2: Message received by Recipient 1455 Let's say that the Recipient is example.com 1456 Processing at example.com: 1458 o example.com performs usual authentication checks 1460 o example.com adds Auth-Results: header, Received header 1462 o Determines that message fails DMARC 1464 o Checks for ARC-Seal: header; finds two 1466 o Validates the signature in the highest numbered ("i=2") ARC-Seal: 1467 header, which covers all previous ARC-Seal: and ARC- 1468 Authentication-Results: headers 1470 o Validates the other ARC-Seal header ("i=1"), which covers the ARC- 1471 Authentication-Results: header 1473 o example.com uses the ARC-Authentication-Results: values 1475 Here's what the message looks like at this point: 1477 Return-Path: 1478 Received: from mail-ob0-f188.google.com (mail-ob0-f188.google.com 1479 [208.69.40.157]) by clothilde.example.com with ESMTP id 1480 d200mr22663000ykb.93.1421363268 1481 for ; Thu, 14 Jan 2015 15:03:15 -0800 (PST) 1483 Authentication-Results: clothilde.example.com; spf=fail 1484 smtp.from=jqd@d1.example; dkim=pass (1024-bit key) 1485 header.i=@gmail.com; dmarc=fail; arc=pass 1486 ARC-Seal: i=2; a=rsa-sha256; t=1421363253; 1487 s=notary01; d=gmail.com; cv=pass; 1488 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDWR 1489 YbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/sut 1490 txO+RRNr0fCFw== 1491 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; 1492 d=gmail.com; s=20120806; 1493 h=mime-version:content-type:x-original-sender: 1494 x-original-authentication-results:precedence:mailing-list: 1495 list-id:list-post:list-help:list-archive:sender:reply-to: 1496 :list-unsubscribe:DKIM-Signature; 1497 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=; 1498 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 1499 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 1500 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBmfhS 1501 LF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJRFeM 1502 KdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwDBJtXw 1503 bQoZyRtb6X6q0mYaszUB8kw== 1504 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10 1505 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST) 1506 Authentication-Results: i=2; gmail.com; spf=fail 1507 smtp.from=jqd@d1.example; dkim=pass (1024-bit key) 1508 header.i=@example.org; dmarc=fail; arc=pass 1509 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 1510 s=seal2015; d=example.org; cv=none; 1511 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 1512 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 1513 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 1514 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; 1515 d=example.org; s=clochette; t=1421363105; 1516 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; 1517 h=List-Id:List-Unsubscribe:List-Archive:List-Post: 1518 List-Help:List-Subscribe:Reply-To:DKIM-Signature; 1519 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF 1520 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3 1521 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= 1522 Received: from segv.d1.example (segv.d1.example [72.52.75.15]) 1523 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 1524 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) 1525 (envelope-from jqd@d1.example) 1526 ARC-Authentication-Results: i=1; lists.example.org; 1527 spf=pass smtp.mfrom=jqd@d1.example; 1528 dkim=pass (1024-bit key) header.i=@d1.example; 1529 dmarc=pass 1530 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 1531 (authenticated bits=0) 1532 by segv.d1.example with ESMTP id t0FN4a8O084569; 1533 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 1534 (envelope-from jqd@d1.example) 1535 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; 1536 s=20130426; t=1421363082; 1537 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 1538 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: 1539 Content-Transfer-Encoding; 1540 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr 1541 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G 1542 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 1543 Message-ID: <54B84785.1060301@d1.example> 1544 Date: Thu, 14 Jan 2015 15:00:01 -0800 1545 From: John Q Doe 1546 To: arc@example.org 1547 Subject: [Lists] Example 1 1549 Hey gang, 1550 This is a test message. 1551 --J. 1553 A.3. Example 3: Mailing list to forwarded mailbox with source 1555 A.3.1. Here's the message as it exits the Origin: 1557 Return-Path: 1558 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 1559 (authenticated bits=0) 1560 by segv.d1.example with ESMTP id t0FN4a8O084569; 1561 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 1562 (envelope-from jqd@d1.example) 1563 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 1564 s=origin2015; d=d1.example; cv=none; 1565 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61T 1566 X6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69EU 1567 8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 1568 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; 1569 d=d1.example; s=20130426; t=1421363082; 1570 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 1571 h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding; 1572 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrv 1573 Qwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3 1574 TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 1575 Message-ID: <54B84785.1060301@d1.example> 1576 Date: Thu, 14 Jan 2015 15:00:01 -0800 1577 From: John Q Doe 1578 To: arc@example.org 1579 Subject: Example 1 1581 Hey gang, 1582 This is a test message. 1583 --J. 1585 A.3.2. Message is then received at example.org 1587 A.3.2.1. Example 3, Step A: Message forwarded to list members with 1588 source 1590 Processing at example.org: 1592 o example.org performs authentication checks 1594 o example.org applies standard DKIM signature 1596 o Checks for ARC-Seal: header; finds one (i=1) 1598 o Validates the signature in the ARC-Seal (i=1): header, which 1599 covers the d1.example ARC-Message-Signature: header 1601 o example.org adds ARC-Auth-Results header 1603 o example.org adds usual Received: header 1604 o example.org adds a DKIM-Signature 1606 o example.org adds a ARC-Seal header, contents of which are 1608 * sequence number ("i=2") 1610 * hash algorithm (SHA256 as example) 1612 * timestamp ("t=") 1614 * chain validity ("cv=") 1616 * selector for key ("s=seal2015") 1618 * domain for key ("d=example.org") 1620 * signature ("b=") 1622 Here's the message as it exits Step A: 1624 Return-Path: 1625 ARC-Seal: i=2; a=rsa-sha256; t=1421363107; 1626 s=seal2015; d=example.org; cv=pass; 1627 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6 1628 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L 1629 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 1630 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; 1631 d=example.org; s=clochette; t=1421363105; 1632 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; 1633 h=List-Id:List-Unsubscribe:List-Archive:List-Post: 1634 List-Help:List-Subscribe:From:Reply-To:DKIM-Signature; 1635 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF 1636 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3 1637 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= 1638 Received: from segv.d1.example (segv.d1.example [72.52.75.15]) 1639 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 1640 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) 1641 (envelope-from jqd@d1.example) 1642 ARC-Authentication-Results: i=2; lists.example.org; 1643 spf=pass smtp.mfrom=jqd@d1.example; 1644 dkim=pass (1024-bit key) header.i=@d1.example; 1645 dmarc=pass 1646 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 1647 (authenticated bits=0) 1648 by segv.d1.example with ESMTP id t0FN4a8O084569; 1649 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 1650 (envelope-from jqd@d1.example) 1651 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 1652 s=origin2015; d=d1.example; cv=none; 1653 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 1654 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 1655 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 1656 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; 1657 d=d1.example; s=20130426; t=1421363082; 1658 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 1659 h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding; 1660 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr 1661 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G 1662 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 1663 Message-ID: <54B84785.1060301@d1.example> 1664 Date: Thu, 14 Jan 2015 15:00:01 -0800 1665 From: John Q Doe 1666 To: arc@example.org 1667 Subject: [Lists] Example 1 1669 Hey gang, 1670 This is a test message. 1671 --J. 1673 A.3.2.2. Example 3, Step B: Message from list forwarded with source 1675 The message is delivered to a mailbox at gmail.com 1676 Processing at gmail.com: 1678 o gmail.com performs usual authentication checks 1680 o gmail.com adds Auth-Results: and Received: header 1682 o Determines that message fails DMARC 1684 o Checks for ARC-Seal: header; finds two 1686 o Validates the signature in the ARC-Seal (i=2): header, which 1687 covers the ARC-Authentication-Results: header 1689 o Validates the signature in the ARC-Seal (i=1): header, which 1690 covers the d1.example ARC-Message-Signature: header 1692 o Uses the ARC-Auth-Results: values, but: 1694 o Instead of delivering message, prepares to forward message per 1695 user settings 1697 o Applies usual DKIM signature 1699 o gmail.com adds it's own ARC-Seal: header, contents of which are 1701 * version 1703 * sequence number ("i=2") 1705 * hash algorithm (SHA256 as example) 1707 * timestamp ("t=") 1709 * selector for key ("s=notary01") 1711 * domain for key ("d=gmail.com") 1713 * Note: algorithm requires only ARC-Seals with lower sequence # 1714 be included, in ascending order 1716 * signature of the chain 1718 Here's what the message looks like at this point: 1720 Return-Path: 1721 ARC-Seal: i=3; a=rsa-sha256; t=1421363253; 1722 s=notary01; d=gmail.com; cv=pass; 1723 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwD 1724 WRYbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF 1725 /suttxO+RRNr0fCFw== 1726 ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed; 1727 d=gmail.com; s=20120806; 1728 h=mime-version:content-type:x-original-sender 1729 :x-original-authentication-results:precedence:mailing-list 1730 :list-id:list-post:list-help:list-archive:sender 1731 :list-unsubscribe:reply-to; 1732 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=; 1733 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6 1734 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L 1735 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBm 1736 fhSLF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJ 1737 RFeMKdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwD 1738 BJtXwbQoZyRtb6X6q0mYaszUB8kw== 1739 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10 1740 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST) 1741 Authentication-Results: i=3; gmail.com; spf=fail 1742 smtp.from=jqd@d1.example; dkim=pass (1024-bit key) 1743 header.i=@example.org; dmarc=fail; arc=pass 1744 ARC-Seal: i=2; a=rsa-sha256; t=1421363107; 1745 s=seal2015; d=example.org; cv=pass; 1746 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 1747 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 1748 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 1749 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; 1750 d=example.org; s=clochette; t=1421363105; 1751 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; 1752 h=List-Id:List-Unsubscribe:List-Archive:List-Post: 1753 List-Help:List-Subscribe:Reply-To:DKIM-Signature; 1754 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1 1755 F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+ 1756 m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= 1757 Received: from segv.d1.example (segv.d1.example [72.52.75.15]) 1758 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 1759 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) 1760 (envelope-from jqd@d1.example) 1761 ARC-Authentication-Results: i=2; lists.example.org; 1762 spf=pass smtp.mfrom=jqd@d1.example; 1763 dkim=pass (1024-bit key) header.i=@d1.example; 1764 dmarc=pass 1765 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 1766 (authenticated bits=0) 1767 by segv.d1.example with ESMTP id t0FN4a8O084569; 1768 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 1769 (envelope-from jqd@d1.example) 1770 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 1771 s=origin2015; d=d1.example; cv=none; 1772 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 1773 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 1774 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 1775 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; 1776 d=d1.example; s=20130426; t=1421363082; 1777 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 1778 h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding; 1779 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYij 1780 rvQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD 1781 4Gd3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 1782 Message-ID: <54B84785.1060301@d1.example> 1783 Date: Thu, 14 Jan 2015 15:00:01 -0800 1784 From: John Q Doe 1785 To: arc@example.org 1786 Subject: [Lists] Example 1 1788 Hey gang, 1789 This is a test message. 1790 --J. 1792 A.3.3. Example 3: Message received by Recipient 1794 Let's say that the Recipient is example.com 1795 Processing at example.com: 1797 o example.com performs usual authentication checks 1799 o example.com adds Auth-Results: header, Received header 1801 o Determines that message fails DMARC 1803 o Checks for ARC-Seal: header; finds three 1805 o Validates the signature in the highest numbered ("i=2") ARC-Seal: 1806 header, which covers all previous ARC-Seal: and ARC- 1807 Authentication-Results: headers 1809 o Validates the other ARC-Seal header ("i=2"), which covers the ARC- 1810 Authentication-Results: header 1812 o Validates the other ARC-Seal header ("i=1"), which covers the 1813 d1.example ARC-Message-Signature: header 1815 o example.com uses the ARC-Authentication-Results: values 1816 Here's what the message looks like at this point: 1818 Return-Path: 1819 Received: from mail-ob0-f188.google.com (mail-ob0-f188.google.com 1820 [208.69.40.157]) by clothilde.example.com with ESMTP id 1821 d200mr22663000ykb.93.1421363268 1822 for ; Thu, 14 Jan 2015 15:03:15 -0800 (PST) 1823 Authentication-Results: clothilde.example.com; spf=fail 1824 smtp.from=jqd@d1.example; dkim=pass (1024-bit key) 1825 header.i=@gmail.com; dmarc=fail; arc=pass 1826 ARC-Seal: i=3; a=rsa-sha256; t=1421363253; 1827 s=notary01; d=gmail.com; cv=pass; 1828 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDW 1829 RYbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/s 1830 uttxO+RRNr0fCFw== 1831 ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed; 1832 d=gmail.com; s=20120806; 1833 h=mime-version:content-type:x-original-sender 1834 :x-original-authentication-results:precedence 1835 :mailing-list:list-id:list-post:list-help:list-archive:sender 1836 :list-unsubscribe:reply-to; 1837 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=; 1838 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6 1839 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L 1840 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBm 1841 fhSLF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJ 1842 RFeMKdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwD 1843 BJtXwbQoZyRtb6X6q0mYaszUB8kw== 1844 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10 1845 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST) 1846 Authentication-Results: i=3; gmail.com; spf=fail 1847 smtp.from=jqd@d1.example; dkim=pass (1024-bit key) 1848 header.i=@example.org; dmarc=fail; arc=pass 1849 ARC-Seal: i=2; a=rsa-sha256; t=1421363107; 1850 s=seal2015; d=example.org; cv=pass; 1851 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6 1852 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L 1853 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 1854 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; 1855 d=example.org; s=clochette; t=1421363105; 1856 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; 1857 h=List-Id:List-Unsubscribe:List-Archive:List-Post: 1858 List-Help:List-Subscribe:Reply-To:DKIM-Signature; 1859 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1 1860 F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+ 1861 m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= 1862 Received: from segv.d1.example (segv.d1.example [72.52.75.15]) 1863 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 1864 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) 1865 (envelope-from jqd@d1.example) 1866 ARC-Authentication-Results: i=2; lists.example.org; 1867 spf=pass smtp.mfrom=jqd@d1.example; 1868 dkim=pass (1024-bit key) header.i=@d1.example; 1869 dmarc=pass 1870 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 1871 (authenticated bits=0) 1872 by segv.d1.example with ESMTP id t0FN4a8O084569; 1873 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 1874 (envelope-from jqd@d1.example) 1875 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 1876 s=origin2015; d=d1.example; cv=none; 1877 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 1878 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 1879 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 1880 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; 1881 d=d1.example; s=20130426; t=1421363082; 1882 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 1883 h=MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding; 1884 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr 1885 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G 1886 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 1887 Message-ID: <54B84785.1060301@d1.example> 1888 Date: Thu, 14 Jan 2015 15:00:01 -0800 1889 From: John Q Doe 1890 To: arc@example.org 1891 Subject: [Lists] Example 1 1893 Hey gang, 1894 This is a test message. 1895 --J. 1897 Appendix B. Acknowledgements 1899 This draft is the work of OAR-Dev Group. 1901 The authors thank all of the OAR-Dev group for the ongoing help and 1902 though-provoking discussions from all the participants, especially: 1903 Alex Brotman, Brandon Long, Dave Crocker, Elizabeth Zwicky, Franck 1904 Martin, Greg Colburn, J. Trent Adams, John Rae-Grant, Mike Hammer, 1905 Mike Jones, Steve Jones, Terry Zink, Tim Draegen. 1907 Grateful appreciation is extended to the people who provided feedback 1908 through the discuss mailing list. 1910 Appendix C. Comments and Feedback 1912 Please address all comments, discussions, and questions to 1913 dmarc@ietf.org [4]. Earlier discussions can be found at arc- 1914 discuss@dmarc.org [5]. 1916 Authors' Addresses 1918 Kurt Andersen 1919 LinkedIn 1920 1000 West Maude Ave 1921 Sunnyvale, California 94085 1922 USA 1924 Email: kurta@linkedin.com 1926 Brandon Long (editor) 1927 Google 1929 Email: blong@google.com 1931 Steven Jones (editor) 1932 TDP 1934 Email: smj@crash.com 1936 Murray Kucherawy (editor) 1937 TDP 1939 Email: superuser@gmail.com