idnits 2.17.1 draft-ietf-dmarc-arc-protocol-13.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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 'SHOULD not' in this paragraph: The AMS header field SHOULD not include (sign) the AAR header field(s). (Early drafts of this protocol and some older examples included the AAR header(s) within the signing scope for the AMS, but ambiguity regarding which of the potentially multiple AAR headers (one per ARC set) argues against such practice.) -- The document date (March 21, 2018) is 2221 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 1539 -- Looks like a reference, but probably isn't: '2' on line 1541 == Missing Reference: 'CFWS' is mentioned on line 559, but not defined -- Looks like a reference, but probably isn't: '3' on line 1543 -- Looks like a reference, but probably isn't: '4' on line 1545 -- Looks like a reference, but probably isn't: '5' on line 1547 -- Looks like a reference, but probably isn't: '6' on line 1549 -- Looks like a reference, but probably isn't: '7' on line 1551 -- Looks like a reference, but probably isn't: '8' on line 1553 -- Looks like a reference, but probably isn't: '9' on line 1555 -- Looks like a reference, but probably isn't: '10' on line 1557 -- Looks like a reference, but probably isn't: '11' on line 1559 == Missing Reference: 'I-D.ARC' is mentioned on line 1360, but not defined -- Looks like a reference, but probably isn't: '12' on line 1561 -- Looks like a reference, but probably isn't: '13' on line 1563 -- Looks like a reference, but probably isn't: '14' on line 1565 -- Looks like a reference, but probably isn't: '15' on line 1567 -- Looks like a reference, but probably isn't: '16' on line 1609 -- Looks like a reference, but probably isn't: '17' on line 2445 -- Looks like a reference, but probably isn't: '18' on line 2446 ** 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: 2 errors (**), 0 flaws (~~), 10 warnings (==), 22 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: September 22, 2018 Google 6 S. Jones, Ed. 7 TDP 8 S. Blank, Ed. 9 ValiMail 10 M. Kucherawy, Ed. 11 TDP 12 March 21, 2018 14 Authenticated Received Chain (ARC) Protocol 15 draft-ietf-dmarc-arc-protocol-13 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 create an attached, authenticated record 23 of the status at each step along the handling path, for use by the 24 final recipient in making choices about the disposition of the 25 message. Changes in the message that might break existing 26 authentication mechanisms can be identified through the ARC set of 27 header fields. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 22, 2018. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 65 1.1.1. High Level Summary . . . . . . . . . . . . . . . . . 5 66 1.1.2. Technical Summary . . . . . . . . . . . . . . . . . . 7 67 1.2. Definitions and Terminology . . . . . . . . . . . . . . . 7 68 1.2.1. Terms defined and used in this document . . . . . . . 7 69 1.2.2. Referenced Definitions . . . . . . . . . . . . . . . 8 70 2. Protocol Elements and Features . . . . . . . . . . . . . . . 8 71 2.1. Features of the ARC Protocol . . . . . . . . . . . . . . 9 72 2.1.1. Chain of Custody . . . . . . . . . . . . . . . . . . 9 73 2.1.2. Optional Participation . . . . . . . . . . . . . . . 10 74 2.1.3. Only one ARC Chain (One Chain to Rule Them All) . . . 10 75 2.1.4. All Failures are Permanent . . . . . . . . . . . . . 10 76 2.1.5. Benign nature of an ARC Set . . . . . . . . . . . . . 10 77 2.1.6. Key Management . . . . . . . . . . . . . . . . . . . 11 78 2.1.7. Trace Information . . . . . . . . . . . . . . . . . . 11 79 2.1.8. Instance Tags . . . . . . . . . . . . . . . . . . . . 11 80 2.1.9. Chain Validation Status . . . . . . . . . . . . . . . 11 81 3. The ARC Header Fields . . . . . . . . . . . . . . . . . . . . 11 82 3.1. Instance ('i=') Tag . . . . . . . . . . . . . . . . . . . 11 83 3.1.1. Valid Range for Instance Tags . . . . . . . . . . . . 12 84 3.2. ARC-Authentication-Results (AAR) . . . . . . . . . . . . 12 85 3.3. ARC-Message-Signature (AMS) . . . . . . . . . . . . . . . 13 86 3.4. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . . . 13 87 3.4.1. The 'cv' Tag . . . . . . . . . . . . . . . . . . . . 14 88 3.4.2. Implicit Header Fields . . . . . . . . . . . . . . . 14 89 4. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . 14 90 4.1. ARC Authentication-Results Information . . . . . . . . . 16 91 4.2. Handling DNS Problems While Validating ARC . . . . . . . 16 92 4.3. Responding to ARC Validity Violations During the SMTP 93 Transaction . . . . . . . . . . . . . . . . . . . . . . . 17 95 5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . 17 96 5.1. Marking and Sealing "cv=fail" (Invalid) Chains . . . . . 17 97 6. Usage of ARC and Chain Validity . . . . . . . . . . . . . . . 18 98 6.1. Relationship between DKIM-Signature and AMS signing 99 scopes . . . . . . . . . . . . . . . . . . . . . . . . . 18 100 6.2. Assessing Chain Validity Violations . . . . . . . . . . . 18 101 7. Recording and Reporting the Results of ARC Evaluation . . . . 18 102 7.1. Information from an ARC Evaluation . . . . . . . . . . . 18 103 7.2. Recording (local) ARC Evaluation Results . . . . . . . . 19 104 7.3. DMARC Reporting of ARC Findings - Interim . . . . . . . . 19 105 8. Supporting Alternate Signing Algorithms . . . . . . . . . . . 19 106 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 107 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 108 10.1. Authentication-Results Method Registry Update . . . . . 20 109 10.2. Definitions of the ARC header fields . . . . . . . . . . 21 110 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22 111 11.1. Header Size . . . . . . . . . . . . . . . . . . . . . . 22 112 11.2. DNS Operations . . . . . . . . . . . . . . . . . . . . . 22 113 11.3. Message Content Suspicion . . . . . . . . . . . . . . . 22 114 12. Evaluating the Efficacy of the ARC Protocol . . . . . . . . . 23 115 12.1. Success Consideration . . . . . . . . . . . . . . . . . 23 116 12.2. Failure Considerations . . . . . . . . . . . . . . . . . 24 117 12.3. Open Questions . . . . . . . . . . . . . . . . . . . . . 24 118 12.3.1. Value of the ARC-Seal (AS) Header . . . . . . . . . 24 119 12.3.2. DNS Overhead . . . . . . . . . . . . . . . . . . . . 24 120 12.3.3. Distinguishing Valuable from Worthless Trace 121 Information . . . . . . . . . . . . . . . . . . . . 24 122 13. Implementation Status . . . . . . . . . . . . . . . . . . . . 25 123 13.1. GMail test reflector and incoming validation . . . . . . 26 124 13.2. AOL test reflector and internal tagging . . . . . . . . 26 125 13.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 26 126 13.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . 27 127 13.5. Mailman 3.2 patch . . . . . . . . . . . . . . . . . . . 27 128 13.6. Copernica/MailerQ web-based validation . . . . . . . . . 28 129 13.7. Rspamd . . . . . . . . . . . . . . . . . . . . . . . . . 28 130 13.8. PERL MAIL::DKIM module . . . . . . . . . . . . . . . . . 29 131 13.9. PERL Mail::Milter::Authentication module . . . . . . . . 29 132 13.10. Sympa List Manager . . . . . . . . . . . . . . . . . . . 30 133 13.11. Oracle Messaging Server . . . . . . . . . . . . . . . . 30 134 13.12. MessageSystems Momentum . . . . . . . . . . . . . . . . 31 135 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 136 14.1. Normative References . . . . . . . . . . . . . . . . . . 31 137 14.2. Informative References . . . . . . . . . . . . . . . . . 32 138 14.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 33 139 Appendix A. Appendix A - Design Requirements . . . . . . . . . . 34 140 A.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 34 141 A.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 35 142 Appendix B. Appendix B - Example Usage . . . . . . . . . . . . . 35 143 B.1. Example 1: Simple mailing list . . . . . . . . . . . . . 35 144 B.1.1. Here's the message as it exits the Origin: . . . . . 35 145 B.1.2. Message is then received at example.org . . . . . . . 35 146 B.1.3. Example 1: Message received by Recipient . . . . . . 38 147 B.2. Example 2: Mailing list to forwarded mailbox . . . . . . 39 148 B.2.1. Here's the message as it exits the Origin: . . . . . 39 149 B.2.2. Message is then received at example.org . . . . . . . 40 150 B.2.3. Example 2: Message received by Recipient . . . . . . 44 151 B.3. Example 3: Mailing list to forwarded mailbox with source 46 152 B.3.1. Here's the message as it exits the Origin: . . . . . 46 153 B.3.2. Message is then received at example.org . . . . . . . 47 154 B.3.3. Example 3: Message received by Recipient . . . . . . 52 155 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 54 156 Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 55 157 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55 159 1. Introduction 161 Modern email authentication techniques such as the Sender Policy 162 Framework (SPF) [RFC7208] and DomainKeys Identified Mail (DKIM) 163 [RFC6376] have become common. However, their end-to-end utility is 164 limited by the effects of intermediaries along the transmission path, 165 which either are not listed (for SPF) or which break digital 166 signatures (for DKIM). These issues are described in substantial 167 detail in those protocols' defining documents as well as in [RFC6377] 168 and [RFC7960]. 170 Technologies that build upon the use of SPF and DKIM can reduce the 171 success of fraudulent email campaigns. To this end, Domain-based 172 Mail Authentication, Reporting and Compliance (DMARC) [RFC7489], 173 validates the domain of the RFC5322.From author header field. 174 However its use along email transmission paths that have independent 175 intermediaries, such as some forwarders and essentially all mailing 176 list services, produces false positive rejections that are 177 problematic, both for the message authors, the intermediary 178 service(s), and for those they are interacting with. 180 What is needed is a mechanism by which legitimate alteration of a 181 message, which invalidates associated SPF and DKIM information, does 182 not ultimately result in a rejection of an email message on delivery. 183 Authenticated Receive Chain (ARC) builds upon DKIM mechanisms to 184 provide a sequence of signatures that provide a view of the handling 185 sequence for a message, especially the points where alterations of 186 the content might have occurred. Equipped with this more complete 187 information, the recipient system(s) can make a more informed 188 handling choice, reducing or eliminating the rejections that would 189 occur with the use of DKIM and/or SPF alone. 191 1.1. Overview 193 ARC provides a "chain of custody" for a message, allowing each entity 194 that handles the message to see what entities handled it before, and 195 to see what the authentication status of the message was at each step 196 in the handling. The handling entity can then put its own entry into 197 the chain of custody and then relay the message to the next handler. 199 When the message reaches final delivery, the decision to accept and 200 deliver the message, or, alternatively, to reject, discard, or 201 quarantine it, can take the chain of custody into account, applying 202 local policy in addition to policies advertised by the (purported) 203 sending domain. Consider, for example, this scenario: 205 1. A sender from mysender.example posts a message to a mailing list 206 hosted at listmania.example; 208 2. The mailing list modifies the message by prepending the list name 209 to the subject line, then sends it to the subscribers; 211 3. One of the subscribers is alice@mail.service.example, which 212 receives the message from listmania.example. 214 Assuming the original message was DKIM-signed and mysender.example 215 published an SPF record, the handling by the mailing list will break 216 the DKIM signature because of the message modification, and the 217 forwarding will cause the SPF check to fail in the next step. But 218 listmania.example can add ARC headers to the message to add itself to 219 the document's chain of custody. When mail.service.example sees the 220 message, it can see that SPF and DKIM validation fail, but it can 221 also see that both of these succeeded when they were checked by 222 listmania.example, and can verify listmania's assertion. 224 As part of its evaluation of the message for delivery, 225 mail.service.example can see that mysender.example publishes a DMARC 226 policy asking that unauthenticated messages be rejected. But is can 227 also see the assertion by listmania.example that the message was 228 correctly authenticated when the message arrived there, and if it 229 accepts that assertion and that modifications made were benign, it 230 can deliver the message, rather than reject it, based on the 231 additional information that ARC has provided. 233 1.1.1. High Level Summary 235 In DKIM, every participating signing agent attaches a signature that 236 is based on the some of the content of the message, local policy, and 237 the domain name of the signing agent's Administrative Management 238 Domain (ADMD). Any verifier can process such a signature; a verified 239 signature means that the domain referenced in the signature's "d=" 240 parameter has some responsibility for handling the message. An 241 artifact of using digital signature technology for this means that 242 verification also ensures that the portion of the message that was 243 "covered" by the signature has not been altered since the signature 244 was applied. The signatures themselves are generally independent of 245 one another. 247 In contrast, a validated ARC signature conveys the following pieces 248 of information: 250 1. An assertion that, at the time that the intermediary ADMD 251 processed the message, the various assertions (SPF, DKIM- 252 Signature(s) and/or ARC sets) already attached to the message by 253 other ADMDs were or were not valid; 255 2. As with DKIM, an assertion that, for a validated ARC signature, 256 the domain name in the signature takes some responsibility for 257 handling of the message and that the covered content of message 258 is unchanged since that signature was applied; 260 3. A further assertion that binds the ARC evaluation results into 261 the ARC chain sequence. 263 The ARC protocol accomplishes this by adding an "ARC Set" of three 264 new header fields to the message as follows: 266 1. ARC-Authentication-Results (referred to below as "AAR"): 267 virtually identical in syntax to an Authentication-Results field 268 [RFC7601], this field records the results of all message 269 authentication checks done by the recording ADMD at the time the 270 message arrived. Additional information is placed in this field 271 compared to a standard Authentication-Results field in order to 272 support a more complete DMARC report (see Section 3.2); 274 2. ARC-Message-Signature (referred to below as "AMS"): virtually 275 identical in syntax to DKIM-Signature, this field contains the 276 signature about the message header and body as they existed at 277 the time of handling by the ADMD adding it (including any 278 modifications made by the sealing ADMD); and 280 3. ARC-Seal (referred to below as "AS"): highly similar in structure 281 and format to a DKIM-Signature, this field applies a digital 282 signature that protects the integrity of all three of these new 283 fields when they are added by an ADMD, plus all instances of 284 these fields added by prior ADMDs. 286 An ARC participant always adds all of these header fields before 287 relaying a message to the next handling agent _en route_ to its 288 destination. Moreover, as described in Section 3.1, they each have 289 an "instance number" that increases with each ADMD in the handling 290 chain so that their original order can be preserved and the three 291 related header fields can be processed as a set. 293 1.1.2. Technical Summary 295 [[ possibly including a diagram - this may not be needed any more ]] 297 1.2. Definitions and Terminology 299 This section defines terms used in the rest of the document. 301 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 302 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 303 "OPTIONAL" in this document are to be interpreted as described in 304 BCP14 ([RFC2119][RFC8174]). 306 Because many of the core concepts and definitions are found in 307 [RFC5598], readers should to be familiar with the contents of 308 [RFC5598], and in particular, the potential roles of intermediaries 309 in the delivery of email. 311 Syntax descriptions use Augmented BNF (ABNF) [RFC5234]. 313 1.2.1. Terms defined and used in this document 315 o "ARC-Authentication-Results" (AAR) - an ARC header field described 316 in Section 3.2. 318 o "ARC-Message-Signature" (AMS) - an ARC header field described in 319 Section 3.3. 321 o "ARC-Seal" (AS) - an ARC header field described in Section 3.4. 323 o "ARC Set" - A single group of the header fields introduced in 324 Section 1.1 is called an "ARC Set". 326 o "ARC Chain" - the complete sequence of ARC Sets for a message. 327 The ARC Chain represents a "chain of custody" for the message, 328 recording its authentication status at each ARC-compliant ADMD 329 that handled the message. 331 1.2.2. Referenced Definitions 333 The following terms are defined in other RFCs. Those definitions can 334 be found as follows: 336 o ADMD - [RFC5598], Section 2.3 338 o MTA - [RFC5598], Section 4.3.2 340 o MSA - [RFC5598], Section 4.3.1 342 o MDA - [RFC5598], Section 4.3.3 344 The three header fields that are part of this specification borrow 345 heavily from existing specifications. Rather than repeating all of 346 the formal definitions that are being reused in ARC, this document 347 only describes and specifies changes in syntax and semantics. 349 Language, syntax, and other details are imported from DKIM [RFC6376]. 350 Specific references can be found below. 352 2. Protocol Elements and Features 354 As with other domain authentication technologies (such as SPF, DKIM, 355 and DMARC), ARC makes no claims about the contents of the email 356 message it has sealed. However, for a valid and passing ARC chain, a 357 Final Receiver is able to ascertain: 359 o all (participating) domains that claim responsibility for handling 360 (and possibly modifying) the email message in transit; 362 o trace information, including: 364 * the [RFC7601] authentication results each participating ADMD 365 saw; and 367 * additional data needed to compile a DMARC report for the 368 sending domain. 370 Given this information, a Final Receiver is able to make a more- 371 informed local policy decision regarding message delivery to the end 372 user in spite of an authentication failure. 374 Every participant in an ARC chain, except for the originating sender 375 and Final Receiver, is both an ARC Validator (when receiving) and 376 then an ARC Sealer (when sending a message onward). The validated 377 chain status as determined at message receipt must be passed to the 378 sealer function in order for sealing to occur properly; how this is 379 done is considered ADMD-specific and an implementation detail. 381 _INFORMATIONAL_: It is important to understand that validating and 382 then immediately sealing a message leaves no room for message 383 modification, and many early implementations of ARC did not initially 384 work because both operations were performed in a single pass over the 385 message. 387 2.1. Features of the ARC Protocol 389 The following protocol features are functional parts and design 390 decisions related the protocol that are not specific to either 391 Validators or Sealers, but ensure the ARC chain conveys this 392 information to a Final Receiver. 394 2.1.1. Chain of Custody 396 At a high level, an ARC chain represents a chain of custody of 397 authentication and other trace information (AAR) related to a 398 message, signed by each handler of the message. Each link in the 399 chain (AMS) is designed to be brittle, insofar as it survives only 400 until the next modification of the message. However, the sequence of 401 intermediaries in the handling chain (AS) is designed to remain 402 intact over the entirety of the chain. 404 The ARC chain can be conceptualized through an analogy with the chain 405 of custody for legal evidence. The material evidence itself is 406 sealed within an tamper-proof bag (AMS) each time. When handed to a 407 new party, that party both vouches for the state of the received 408 evidence container (AAR) and signs for the evidence on a chain of 409 custody report form (AS). As with all analogies, this one should not 410 be taken to interpretive extremes, but primarily used as a conceptual 411 framework. 413 An ARC chain that is valid and passing has the attributes listed 414 above in Section 2. 416 Recipients of an ARC chain that is invalid or does not pass SHOULD 417 NOT draw negative conclusions without a good understanding of the 418 wider handling context. Until ARC usage is widespread, 419 intermediaries will continue to modify messages without ARC seals. 420 As with a failing DKIM signature ([RFC6376] Section-6.3), a failing 421 ARC chain SHOULD be treated the same as a message with no ARC chain. 422 [[ NOTE TO WORKING GROUP: This paragraph probably is better placed in 423 Verifier actions. Ref issue 10 [1] ]] 425 2.1.2. Optional Participation 427 Validating an existing chain and then adding your own ARC set to a 428 message allows you to claim responsibility for handling the message 429 and modifications, if any, done by your ADMD to benefit message 430 delivery downstream. However, no ADMD is obligated to perform these 431 actions. 433 2.1.3. Only one ARC Chain (One Chain to Rule Them All) 435 A message can have only one ARC chain on it at a time (see 436 Section 3.1). Once broken, the chain cannot be continued, as the 437 chain of custody is no longer valid and responsibility for the 438 message has been lost. For further discussion of this topic and the 439 designed restriction which prevents chain continuation or re- 440 establishment, see [ARC-USAGE]. 442 2.1.4. All Failures are Permanent 444 Because ARC chains are transmitted across multiple intermediaries, 445 all errors, even temporary ones, become unrecoverable and are 446 considered permanent. 448 Any error validating or sealing a chain, for whatever reason, MUST 449 result in a "cv=fail" verdict. 451 2.1.5. Benign nature of an ARC Set 453 Even when an ARC chain is valid and passes, its value is limited to 454 very specific cases. An ARC chain is specifically designed to 455 provide value to a Final Receiver evaluating message delivery in the 456 context of an authentication failure. An ARC chain in general, and 457 each ARC set in particular, provide additional information, and 458 otherwise is benign. Specifically: 460 o properly adding an ARC set to a message does not damage or 461 invalidate an existing chain, and 463 o validating a message exposes no new threat vectors (see 464 Section 11). 466 _INFORMATIONAL_: If an ADMD is unsure whether it will be re-emitting 467 and/or modifying a message, it may elect to seal all inbound mail. 468 For complex or nested ADMD relationships such as found in some hosted 469 mail solutions, this "inbound seal" can be used to facilitate 470 traversal of internal boundaries as well as properly conveying 471 incoming state to any egress MTAs that may need to assert a seal upon 472 exit from the ADMD. Since these internal relationships are highly 473 implementation dependent, this protocol definition can not usefully 474 explore such usage except to note that it is intentionally allowed 475 within the scope of this specification. 477 2.1.6. Key Management 479 The public keys for ARC header fields follow the same requirements, 480 syntax and semantics as those for DKIM signatures, described in 481 Section 3.6 of [RFC6376]. ARC places no requirements on the 482 selectors and/or domains used for the ARC header field signatures. 484 2.1.7. Trace Information 486 ARC includes trace information encoded in the AAR. While section 487 Section 3.2 defines what information must be provided, sealing ADMDs 488 may provide additional information, and validating receivers may use 489 or ignore this trace information as they wish. 491 2.1.8. Instance Tags 493 ARC introduces an indicator to its header fields to show the order in 494 which the header fields comprising an ARC set were added, and the 495 specific members of an ARC Set. This is known as an "instance", and 496 the indicator is an "i=". That is, the members of the first ARC set 497 affixed to a message will all include "i=1". This is described in 498 detail in section Section 3.1. 500 2.1.9. Chain Validation Status 502 ARC introduces a mechanism, also via a new tag, which indicates the 503 state of the ARC Chain at each step. This is the "chain validation 504 status". This is described in detail in section Section 3.4.1. 506 3. The ARC Header Fields 508 3.1. Instance ('i=') Tag 510 The header fields comprising a single ARC set are identified by the 511 presence of a string in the value portion of the header field that 512 complies with the "tag-spec" ABNF found in Section 3.2 of [RFC6376]. 513 The tag-name is "i" and the value is the text representation of a 514 positive integer, indicating the position in the ARC sequence this 515 set occupies, where the first ARC set is numbered 1. In ABNF terms: 517 instance = [FWS] %x69 [FWS] "=" [FWS] position [FWS] ";" 518 position = 1*2DIGIT ; 1 - 50 520 Valid ARC sets must have exactly one instance of each header field 521 for a given position value and signing algorithm. (Initial 522 development of ARC is only being done with a single allowed signing 523 algorithm, but parallel work in the DCRUP working group [2] is 524 expanding that. For handling multiple signing algorithms, see 525 [ARC-MULTI].) 527 Because the AMS and AS header field values are made up of tag-spec 528 constructs, the i= tag may be found anywhere within the header field 529 value, but is represented throughout this spec in the initial 530 position for convenience. Implementers are encouraged to place the 531 i= tag at the beginning of the field value to facilitate human 532 inspection of the headers. 534 3.1.1. Valid Range for Instance Tags 536 The 'i' tag value can range from 1-50 (inclusive). 538 ARC implementations MUST support at least ten (10) ARC sets. 540 An effective operational maximum will have to be developed through 541 deployment experience in the field and will be documented within 542 [ARC-USAGE] once determined. 544 ARC chains with more than the defined operational maximum count MUST 545 be marked with "cv=fail". 547 3.2. ARC-Authentication-Results (AAR) 549 The ARC-Authentication-Results header field is syntactically and 550 semantically identical to an Authentication-Results header field 551 (defined in Section 2.2 of [I-D-7601bis] (A-R)). Note that several 552 optional data fields SHOULD be added (smtp.client-ip, dkim header.s, 553 arc.oldest-pass) to enable completeness for DMARC reporting. 555 Formally, the header field is specified as follows using ABNF 556 [RFC5234]: 558 arc-authres-header-prefix = "ARC-Authentication-Results:" [CFWS] arc-info 559 arc-info = instance *([CFWS] propspec) [CFWS] ";" authres-payload 561 The purpose of this header field is to transmit the results of any 562 authentication done on the message downstream to participating ADMDs 563 validating and continuing the chain. 565 The AAR MUST contain all A-R results from within the participating 566 ADMD, regardless of how many A-R headers are on the message. 568 3.3. ARC-Message-Signature (AMS) 570 The ARC-Message-Signature header field is syntactically and 571 semantically identical to a DKIM-Signature header field [RFC6376], 572 with the following exceptions: 574 o There is an "i" tag, as described in Section 3.1. 576 o There is no "v" tag defined for the AMS header. As required for 577 undefined tags, if seen, it MUST be ignored. 579 ARC-Seal header fields MUST NOT be included in the content covered by 580 the signature in this header field. 582 The AMS SHOULD include any DKIM-Signature header fields already 583 present on the message in the header fields covered by this 584 signature. 586 The AMS header field SHOULD not include (sign) the AAR header 587 field(s). (Early drafts of this protocol and some older examples 588 included the AAR header(s) within the signing scope for the AMS, but 589 ambiguity regarding which of the potentially multiple AAR headers 590 (one per ARC set) argues against such practice.) 592 Authentication-Results header fields SHOULD NOT be included since 593 they are likely to be deleted by downstream ADMDs (per Section XXX of 594 [RFC7601]), thereby breaking the AMS signature. 596 As with a DKIM-Signature, the purpose of this header field is to 597 allow the ADMD generating it to take some responsibility for handling 598 this message as it progresses toward delivery. 600 3.4. ARC-Seal (AS) 602 The ARC-Seal header field is syntactically and semantically similar 603 to a DKIM-Signature field, with the following exceptions: 605 o There is an "i" tag, as described in Section 3.1. 607 o The ARC-Seal covers none of the body content of the message. It 608 only covers specific header fields. (See below: Section 3.4.2.) 609 As a result, no body canonicalization is done. Further, only 610 "relaxed" header canonicalization (Section 3.4.2 of [RFC6376]) is 611 used. 613 o The only supported tags are "i" (Section 3.1 supercedes the 614 [RFC6376] definition), and "a", "b", "d, "s", "t". The latter 5 615 tag definitions are copied from Section 3.5 of [RFC6376]. 617 o An additional tag, "cv" is defined. (See below: Section 3.4.1) 619 3.4.1. The 'cv' Tag 621 A new tag "cv" (chain validation) indicates the the outcome of 622 evaluating the existing ARC chain upon arrival at the ADMD that is 623 adding this header field. It accepts one of three possible values: 625 o none: There was no chain on the message when it arrived for 626 validation; typically occurs when the message arrives at a Message 627 Transfer Agent (MTA) from a Message Submission Agent (MSA) or when 628 any upstream MTAs may not be participating in ARC handling; 630 o fail: The message has a chain whose validation failed; 632 o pass: The message has a chain whose validation succeeded. 634 In ABNF terms: 636 seal-cv-tag = %x63.76 [FWS] "=" [FWS] ("none" / "fail" / "pass") 638 3.4.2. Implicit Header Fields 640 The ARC-Seal signs a canonicalized form of the ARC set header values. 641 The ARC set header values are compiled in increasing instance order, 642 starting at 1, and inclue the set being added at the time of sealing 643 the message. 645 Within a set, the header fields are listed in the following order: 647 1. ARC-Authentication-Results 649 2. ARC-Message-Signature 651 3. ARC-Seal 653 Where the ARC-Seal is the one being generated, it is input to the 654 hash function in its final form except with an empty "b=" value, in 655 the same manner by which a DKIM-Signature signs itself. 657 Note that the signing scope for the ARC-Seal is modified in the 658 situation where a chain has failed validation (see Section 5.1). 660 4. Verifier Actions 662 A verifier takes the following steps to determine the state of the 663 ARC chain on a message (cv value). Canonicalization, hash functions, 664 and signature validation methods are imported from Section 5 of 665 [RFC6376]. 667 [[ Note: need markdown flag to have subordinate numbering distinction 668 issue 11 [3] ]] 670 1. Collect all ARC sets currently on the message. If there were 671 none, the ARC state is "none" and the algorithm stops here. 673 2. If the form of any ARC set is invalid (e.g., does not contain 674 exactly one of each of the three ARC-specific header fields), 675 then the chain state is "fail" and the algorithm stops here. a. 676 To avoid the overhead of unnecessary computation and delay from 677 crypto and DNS operations, the cv value for all ARC-Seal(s) MAY 678 be checked at this point. If any of the values are "fail", then 679 the overall state of the chain is "fail" and the algorithm stops 680 here. 682 3. Conduct verification of the ARC-Message-Signature header field 683 bearing the highest instance number. If this verification fails, 684 then the chain state is "fail" and the algorithm stops here. 686 4. For each ARC-Seal from the "N"th instance to the first, apply the 687 following logic: a. If the value of the "cv" tag on that seal is 688 "fail", the chain state is "fail" and the algorithm stops here. 689 (This step SHOULD be skipped if the earlier step (2.1) was 690 performed) b. In Boolean nomenclature: if ((i == 1 && cv != 691 "none") or (cv == "none" && i != 1)) then the chain state is 692 "fail" and the algorithm stops here (note that the ordering of 693 the logic is structured for short-circuit evaluation). c. 694 Initialize a hash function corresponding to the "a" tag of the 695 ARC-Seal. d. Compute the canonicalized form of the ARC header 696 fields, in the order described in Section 3.4.2, using the 697 "relaxed" header canonicalization defined in Section 3.4.2 of 698 [RFC6376]. Pass the canonicalized result to the hash function. 699 e. Retrieve the final digest from the hash function. f. 700 Retrieve the public key identified by the "s" and "d" tags in the 701 ARC-Seal, as described in Section 2.1.6. g. Determine whether 702 the signature portion ("b" tag) of the ARC-Seal and the digest 703 computed above are valid according to the public key. (See also 704 Section Section 4.2 for failure case handling) h. If the 705 signature is not valid, the chain state is "fail" and the 706 algorithm stops here. 708 5. If all seals pass validation, then the chain state is "pass", and 709 the algorithm is complete. 711 6. Results from the determination of this algorithm SHOULD be 712 recorded in the Authentication-Results header 714 Whatever the end result of the verifier's checks via the algorithm 715 specified above, the results MUST be added into the Authentication- 716 Results header(s) for the ADMD. 718 [[ See issue 12 [4] regarding the final paragraph ]] 720 The verifier should save the cv state for subsequent use by any 721 sealing which may be done later (potentially after message 722 modification) within the same trust boundary. The cv state may be 723 recorded by sealing at the time of verification in an initial ARC set 724 (for the ADMD) or may be recorded out of band depending on the 725 architecture of the ADMD. 727 4.1. ARC Authentication-Results Information 729 Certain information pertinent to ascertaining message disposition can 730 be lost in transit when messages are handled by intermediaries. For 731 example, failing DKIM signatures are sometimes removed by MTAs, and 732 most DKIM signatures on messages modified by intermediaries will 733 fail. Recording the following information in the A-R provides a 734 mechanism for this information to survive transit. 736 The ptypes and properties defined in this section SHOULD be recorded 737 in the AR: 739 o smtp.client-ip - The connecting client IP address from which the 740 message is received; 742 o header.s - Defined in [RFC6376] section 7.2 744 o arc.oldest-pass - The instance number of the oldest AMS that still 745 validates, or 0 if all pass. 747 [[ Also see issue 20 [5] for another possible field to be added and 748 issue 21 [6] re which document should define these for IANA action. 749 ]] 751 4.2. Handling DNS Problems While Validating ARC 753 DNS-based failures to verify a chain are treated no differently than 754 any other ARC violation. They result in a "cv=fail" verdict. 756 4.3. Responding to ARC Validity Violations During the SMTP Transaction 758 If a receiver determines that the ARC chain has failed, the receiver 759 MAY signal the breakage through the extended SMTP response code 5.7.7 760 [RFC3463] "message integrity failure" [ENHANCED-STATUS] and 761 corresponding SMTP response code. 763 5. Signer Actions 765 [[ See issue 13 [7] for critique ]] 767 This section includes a specification of the actions an ARC signer 768 takes when presented with a message. 770 The signer MUST undertake the following steps: 772 1. Before creating an ARC signature, perform any other, normal 773 authentication and/or signing, so that the ARC signature can 774 cover those results. 776 2. Build and attach the new ARC set: 778 1. If an ARC chain exists on the message, then set "N" equal to 779 the highest instance number found on the chain (i=); 780 otherwise set "N" equal to zero for the following steps. 782 2. Generate and attach to the message an ARC-Authentication- 783 Results header field using instance number N+1 and the same 784 content from the previous step. 786 3. Generate and attach to the message an ARC-Message-Signature 787 header field as defined in Section 3.3 above, using instance 788 number N+1. 790 4. Generate and attach to the message an ARC-Seal header field 791 using the general algorithm described in Section 3.4 above, 792 the chain validation status as determined in Section 4, and 793 instance number N+1. 795 5.1. Marking and Sealing "cv=fail" (Invalid) Chains 797 The header fields signed by the AS header field b= value in the case 798 of a chain failure MUST be only the matching instance headers created 799 by the MTA which detected the malformed chain, as if this newest ARC 800 set was the only set present. 802 6. Usage of ARC and Chain Validity 804 6.1. Relationship between DKIM-Signature and AMS signing scopes 806 [[ See issue 14 [8] for critique of this section ]] 808 DKIM-Signatures SHOULD never sign any ARC header fields. 810 6.2. Assessing Chain Validity Violations 812 [[ Issue 15 [9] ]] 814 Email transit can produce broken signatures for a wide variety of 815 benign reasons. This includes possibly breaking one or more ARC 816 signatures. Therefore, receivers need to be wary of ascribing motive 817 to such breakage although patterns of common behaviour may provide 818 some basis for adjusting local policy decisions. 820 ARC does not attempt to protect an entire message. There are various 821 ways that a message can still be problematic, in spite of having a 822 valid ARC chain. Consequently, all normal, content-based analysis 823 SHOULD still be performed on any message having a valid chain of ARC 824 header sets. 826 7. Recording and Reporting the Results of ARC Evaluation 828 The evaluation of an ARC chain provides information which will be 829 useful to both the receiver (or intermediary) and to the initial 830 sender of the message. This information should be preserved and 831 reported as follows. 833 7.1. Information from an ARC Evaluation 835 The evaluation of an ARC chain produces a list of domain names for 836 participating intermediaries which handled the message, to wit: 838 o A list of the "d=" domains found in the validated ARC-Seal header 839 fields 841 o The "d=" domain found in the most recent (highest instance number) 842 AMS header field (since that is the only one necessarily 843 validated) 845 In the case of a failed chain, only the terminal ARC set is covered 846 by the ARC-Seal so the reporting is limited to the findings in that 847 terminal ARC set. 849 7.2. Recording (local) ARC Evaluation Results 851 Receivers MAY add an "arc=[pass|fail|policy]" method annotation into 852 a locally-affixed Authentication-Results [RFC7601] header field along 853 with any salient comment(s). 855 Details of the ARC chain which was evaluated should be included in 856 the Authentication-Results and AAR headers per Section Section 4.1. 858 7.3. DMARC Reporting of ARC Findings - Interim 860 [[ Note: Move to separate document? [10] (see the additional fields 861 specified in Section 4.1) ]] 863 Receivers SHOULD indicate situations in which ARC evaluation 864 influenced the results of their local policy determination. DMARC 865 reporting of ARC-informed decisions can be accomplished by adding a 866 local_policy comment explanation containing the list of data 867 discovered in the ARC evaluation (Section 7.1 and Section 4.1): 869 870 delivered 871 fail 872 fail source.ip=10.0.0.1 873 874 local_policy 875 arc=pass ams[2].d=d2.example ams[2].s=s1 as[2].d=d2.example 876 as[2].s=s2 as[1].d=d1.example as[1].s=s3 877 878 880 In the suggested sample, d2.example is the sealing domain for ARC[2] 881 and d1.example is the sealing domain for ARC[1]. 883 Mediators SHOULD generate DMARC reports on messages which transit 884 their system just like any other message which they receive. This 885 will result in multiple reports for each mediated message as they 886 transit the series of handlers. DMARC report consumers should be 887 aware of this behaviour and make the necessary accommodations. 889 8. Supporting Alternate Signing Algorithms 891 This section has been moved to [ARC-MULTI] 893 9. Privacy Considerations 895 The ARC chain provides a verifiable record of the handlers for a 896 message. Anonymous remailers will probably not find this compatible 897 with their operating goals. 899 10. IANA Considerations 901 [[ See issue 21 [11] regarding which document should be definitive 902 for these fields. ]] 904 This specification adds three new header fields as defined below. 906 10.1. Authentication-Results Method Registry Update 908 This draft adds one item to the IANA "Email Authentication Methods" 909 registry: 911 o Method : arc 913 Defined: [I-D.ARC] 915 ptype: header 917 Property: chain evaluation result 919 Value: chain evaluation result status (see Section 3.4) 921 Status: active 923 o Method : dkim 925 Defined: [I-D.ARC] 927 ptype: header 929 Property: selector 931 Value: value of signature "s" tag (see [RFC6376]) 933 Status: active 935 o Method : spf 937 Defined: [I-D.ARC] 939 ptype: smtp 940 Property: client-ip 942 Value: the connecting client IP address from which the message is 943 received 945 Status: active 947 o Method : arc 949 Defined: [I-D.ARC] 951 ptype: header 953 Property: oldest-pass 955 Value: the oldest instance with a still validating AMS signature 957 Status: active 959 10.2. Definitions of the ARC header fields 961 This specification adds three new header fields to the "Permanent 962 Message Header Field Registry", as follows: 964 o Header field name: ARC-Seal 966 Applicable protocol: mail 968 Status: draft 970 Author/Change controller: IETF 972 Specification document(s): [I-D.ARC] 974 Related information: [RFC6376] 976 o Header field name: ARC-Message-Signature 978 Applicable protocol: mail 980 Status: draft 982 Author/Change controller: IETF 984 Specification document(s): [I-D.ARC] 986 Related information: [RFC6376] 988 o Header field name: ARC-Authentication-Results 990 Applicable protocol: mail 992 Status: standard 994 Author/Change controller: IETF 996 Specification document(s): [I-D.ARC] 998 Related information: [RFC7601] 1000 11. Security Considerations 1002 The Security Considerations of [RFC6376] and [RFC7601] apply directly 1003 to this specification. 1005 11.1. Header Size 1007 Inclusion of ARC sets in the header of emails may cause problems for 1008 some older or more constrained MTAs if they are unable to accept the 1009 greater size of the header. 1011 11.2. DNS Operations 1013 Operators who receive a message bearing N ARC sets have to complete 1014 up to N+1 DNS queries to evaluate the chain (barring DNS redirection 1015 mechanisms which can increase the lookups for a given target value). 1016 This has at least two effects: 1018 1. An attacker can send a message to an ARC partipant with a 1019 concocted sequence of ARC sets bearing the domains of intended 1020 victims, and all of them will be queried by the participant until 1021 a failure is discovered. The difficulty of forging the signature 1022 values should limit the extent of this load to domains under 1023 control of the attacker. 1025 2. DKIM only does one DNS check per signature, while this one can do 1026 many (per chain). Absent caching, slow DNS responses can cause 1027 SMTP timeouts; and backlogged delivery queues on mediating 1028 systems. This could be exploited as a DoS attack. 1030 11.3. Message Content Suspicion 1032 Recipients are cautioned to treat messages bearing ARC sets with the 1033 same suspicion that they apply to all other email messages. This 1034 includes appropriate content scanning and other checks for 1035 potentially malicious content. The handlers which are identified 1036 within the ARC chain may be used to provide input to local policy 1037 engines in cases where DMARC validation fails (due to mediation 1038 impacting SPF attribution, DKIM validity or alignment). 1040 Note that a passing ARC chain may not adequately mean that the 1041 message is safe because: 1043 1. You have to trust all signatories; and 1045 2. Even trusted systems may have become compromised or may not 1046 properly authenticate messages, so even with a chain of trusted 1047 participants, the message might still never have authenticated in 1048 the first place (which is why you have the AAR to inspect) or 1049 could have been subject to unintended modifications. 1051 12. Evaluating the Efficacy of the ARC Protocol 1053 The ARC protocol is designed to mitigate some of the most common 1054 failure conditions for email which transits intermediary handlers en 1055 route to the final recipient. Some of these problems have happened 1056 due to the adoption of the DMARC protocol [RFC7489] and are listed in 1057 [RFC6377] and [RFC7960]. 1059 As the ARC protocol becomes standardized and implemented amongst 1060 intermediary handlers, the following aspects should be evaluated in 1061 order to determine the success of the protocol in accomplishing the 1062 intended benefits. 1064 NOTE: Terminology within this section does NOT follow [RFC2119] 1065 interpretation. This section represents the current thoughts of the 1066 working group regarding unanswered questions related to the protocol. 1067 Wider deployment will inform these topics and probably expand them. 1069 12.1. Success Consideration 1071 Currently, many receivers have heuristically determined overrides in 1072 order to rescue mail from intermediary-caused failures. Many of 1073 those overrides rely on inferrence rather than direct evidence. 1075 ARC will be a success if, for ARC sealed messages, receivers are able 1076 to implment ARC-based algorithmic decisions based on the direct 1077 evidence found within the ARC chain. This is especially relevant for 1078 DMARC processing when the DKIM d= value is aligned with the 1079 rfc5322.From author domain. 1081 12.2. Failure Considerations 1083 The intent of ARC is to be at most value-add and at worst benign. If 1084 ARC opens up significant new vectors for abuse (see Section 11) then 1085 this protocol will be a failure. Note that weaknesses inherent in 1086 the mail protocols ARC is built upon (such as DKIM replay attacks and 1087 other known issues) are not new vectors which can be attributed to 1088 this specification. 1090 12.3. Open Questions 1092 The following open questions are academic and have no clear answer at 1093 the time of the development of the protocol. However, wide-spread 1094 deployment should be able to gather the necessary data to answer some 1095 or all of them. 1097 12.3.1. Value of the ARC-Seal (AS) Header 1099 Data should be collected to show if the ARC-Seal (AS) provides value 1100 beyond the ARC Message Signature (AMS) for either making delivery 1101 decisions or catching malicious actors trying to craft or replay 1102 malicious chains. 1104 12.3.2. DNS Overhead 1106 Longer ARC chains will require more queries to retrieve the keys for 1107 validating the chain. While this is not believed to be a security 1108 issue (see Section 11.2), it is unclear how much overhead will truly 1109 be added. This is similar to some of the initial processing and 1110 query load concerns which were debated at the time of the DKIM 1111 specification development. 1113 Data should be collected to better understand usable length and 1114 distribution of lengths found in valid ARC chains along with the the 1115 DNS impact of processing ARC chains. 1117 12.3.3. Distinguishing Valuable from Worthless Trace Information 1119 There are several edge cases where the information in the AAR can 1120 make the difference between message delivery or rejection. For 1121 example, if there is a well known mailing list that ARC seals but 1122 doesn't do its own initial DMARC enforcement, a Final Receiver with 1123 this knowledge could make a delivery decision based upon the 1124 authentication information it sees in the corresponding AAR header. 1126 Certain trace information in the AAR is useful/necessary in the 1127 construction of DMARC reports. It would be beneficial to identify 1128 the value-add of having intermediary-handled mail flow information 1129 added into the DMARC reports going back to senders. 1131 Certain receivers believe the entire set of trace information would 1132 be valuable to feed into machine learning systems to identify fraud 1133 and/or provide other signals related to message delivery. 1135 It is unclear what trace information will be valuable for all 1136 receivers, regardless of size. 1138 Data should be collected on what trace information receivers are 1139 using that provides useful signals that affect deliverability, and 1140 what portions of the trace data are left untouched or provide no 1141 useful information. 1143 Since many such systems are intentionly proprietary or confidential 1144 to prevent gaming by abusers, it may not be viable to reliably answer 1145 this particular question. The evolving nature of attacks can also 1146 shift the landscape of "useful" information over time. 1148 13. Implementation Status 1150 [[ Note to the RFC Editor: Please remove this section before 1151 publication along with the reference to [RFC6982]. ]] 1153 This section records the status of known implementations of the 1154 protocol defined by this specification at the time of posting of this 1155 Internet-Draft, and is based on a proposal described in [RFC6982]. 1156 The description of implementations in this section is intended to 1157 assist the IETF in its decision processes in progressing drafts to 1158 RFCs. Please note that the listing of any individual implementation 1159 here does not imply endorsement by the IETF. Furthermore, no effort 1160 has been spent to verify the information presented here that was 1161 supplied by IETF contributors. This is not intended as, and must not 1162 be construed to be, a catalog of available implementations or their 1163 features. Readers are advised to note that other implementations may 1164 exist. 1166 This information is known to be correct as of the seventh 1167 interoperability test event which was held on 2017-07-15 & 16 at 1168 IETF99. 1170 For a few of the implementations, later status information was 1171 available as of December 2017. 1173 13.1. GMail test reflector and incoming validation 1175 Organization: Google 1177 Description: Internal production implementation with both debug 1178 analysis and validating + sealing pass-through function 1180 Status of Operation: Production - Incoming Validation 1182 Coverage: Full spec implemented as of [ARC-DRAFT-06] 1184 Licensing: Proprietary - Internal only 1186 Implementation Notes: 1188 o Full functionality was demonstrated during the interop testing on 1189 2017-07-15. 1191 Contact Info: arc-discuss@dmarc.org [12] 1193 13.2. AOL test reflector and internal tagging 1195 Organization: AOL 1197 Description: Internal prototype implementation with both debug 1198 analysis and validating + sealing pass-through function 1200 Status of Operation: Beta 1202 Coverage: ARC chain validity status checking is operational, but only 1203 applied to email addresses enrolled in the test program. This system 1204 conforms to [ARC-DRAFT-06] 1206 Licensing: Proprietary - Internal only 1208 Implementation Notes: 1210 o 2017-07-15: Full functionality verified during the interop 1211 testing. 1213 Contact Info: arc-discuss@dmarc.org [13] 1215 13.3. dkimpy 1217 Organization: dkimpy developers/Scott Kitterman 1219 Description: Python DKIM package 1220 Status of Operation: Production 1222 Coverage: 1224 o 2017-07-15: The internal test suite is incomplete, but the command 1225 line developmental version of validator was demonstrated to 1226 interoperate with the Google and AOL implementations during the 1227 interop on 2017-07-15 and the released version passes the tests in 1228 [ARC-TEST] arc_test_suite [14] with both python and python3. 1230 Licensing: Open/Other (same as dkimpy package = BCD version 2) 1232 Contact Info: https://launchpad.net/dkimpy 1234 13.4. OpenARC 1236 Organization: TDP/Murray Kucherawy 1238 Description: Implemention of milter functionality related to the 1239 OpenDKIM and OpenDMARC packages 1241 Status of Operation: Beta 1243 Coverage: Built to support [ARC-DRAFT-10] 1245 Licensing: Open/Other (same as OpenDKIM and OpenDMARC packages) 1247 Implementation Notes: 1249 o The build is FreeBSD oriented but some packages have been built 1250 for easier deployment on RedHat-based Linux platforms. 1252 o Some issues still exist when deploying in a chained milter 1253 arrangement (such as OpenSPF -> OpenDKIM -> OpenDMARC -> OpenARC) 1254 with coordination between the stages. When deployed in a 1255 "sandwich" configuration around an MLM, there is no effective 1256 mechanism to convey trust from the ingress (validator) to egress 1257 (signer) instances. (_NOTE_: this is expected to resolved with a 1258 new release of OpenDMARC expected in January 2018.) 1260 Contact Info: arc-discuss@dmarc.org [15] 1262 13.5. Mailman 3.2 patch 1264 Organization: Mailman development team 1266 Description: Integrated ARC capabilities within the Mailman 3.2 1267 package 1268 Status of Operation: Patch submitted 1270 Coverage: Based on OpenARC 1272 Licensing: Same as mailman package - GPL 1274 Implementation Notes: 1276 o Appears to work properly in at least one beta deployment, but 1277 waiting on acceptance of the pull request into the mainline of 1278 mailman development 1280 Contact Info: https://www.gnu.org/software/mailman/contact.html 1282 13.6. Copernica/MailerQ web-based validation 1284 Organization: Copernica 1286 Description: Web-based validation of ARC-signed messages 1288 Status of Operation: Beta 1290 Coverage: Built to support [ARC-DRAFT-05] 1292 Licensing: On-line usage only 1294 Implementation Notes: 1296 o Released 2016-10-24 1298 o Requires full message content to be pasted into a web form found 1299 at http://arc.mailerq.com/ (warning - https is not supported). 1301 o An additional instance of an ARC signature can be added if one is 1302 willing to paste a private key into an unsecured web form. 1304 o 2017-07-15: Testing shows that results match the other 1305 implementations listed in this section. 1307 Contact Info: https://www.copernica.com/ 1309 13.7. Rspamd 1311 Organization: Rspamd community 1313 Description: ARC signing and verification module 1315 Status of Operation: Production, though deployment usage is unknown 1316 Coverage: Built to support [ARC-DRAFT-06] 1318 Licensing: Open source 1320 Implementation Notes: 1322 o 2017-06-12: Released with version 1.6.0 1324 o 2017-07-15: Testing during the interop showed that the validation 1325 functionality interoperated with the Google, AOL, dkimpy and 1326 MailerQ implementations 1328 Contact Info: https://rspamd.com/doc/modules/arc.html and 1329 https://github.com/vstakhov/rspamd 1331 13.8. PERL MAIL::DKIM module 1333 Organization: FastMail 1335 Description: Email domain authentication (sign and/or verify) module, 1336 previously included SPF / DKIM / DMARC, now has ARC added 1338 Status of Operation: Production, deployment usage unknown 1340 Coverage: Built to support [ARC-DRAFT-10] 1342 Licensing: Open Source 1344 Implementation Notes: 1346 o 2017-12-15: v0.50 released with full test set passing for ARC 1348 Contact Info: http://search.cpan.org/~mbradshaw/Mail-DKIM-0.50/ 1350 13.9. PERL Mail::Milter::Authentication module 1352 Organization: FastMail 1354 Description: Email domain authentication milter, uses MAIL::DKIM (see 1355 above) 1357 Status of Operation: Intial validation completed during IETF99 1358 hackathon with some follow-on work during the week 1360 Coverage: Built to support [I-D.ARC] 1362 Licensing: Open Source 1363 Implementation Notes: 1365 o 2017-07-15: Validation functionality which interoperates with 1366 Gmail, AOL, dkimpy was demonstrated; later in the week of IETF99, 1367 the signing functionality was reported to be working 1369 o 2017-07-20: ARC functionality has not yet been pushed back to the 1370 github repo but should be showing up soon 1372 Contact Info: https://github.com/fastmail/authentication_milter 1374 13.10. Sympa List Manager 1376 Organization: Sympa Dev Community 1378 Description: Work in progress 1380 Status of Operation: Work in progress 1382 Coverage: unknown 1384 Licensing: open source 1386 Implementation Notes: 1388 o 2018-01-05: Tracked as https://github.com/sympa-community/sympa/ 1389 issues/153 1391 Contact Info: https://github.com/sympa-community 1393 13.11. Oracle Messaging Server 1395 Organization: Oracle 1397 Description: 1399 Status of Operation: Intial development work during IETF99 hackathon. 1400 Status since then unknown. 1402 Coverage: Built to support [ARC-DRAFT-06] 1404 Licensing: Unknown 1406 Implementation Notes: 1408 o 2018-01: Protocol handling components are completed, but crypto is 1409 not yet functional. 1411 Contact Info: Chris Newman 1413 13.12. MessageSystems Momentum 1415 Organization: MessageSystems/SparkPost 1417 Description: OpenARC integration into the LUA-enabled Momentum 1418 processing space 1420 Status of Operation: Beta 1422 Coverage: Built to support [ARC-DRAFT-10] 1424 Licensing: Unknown 1426 Implementation Notes: 1428 o Initial deployments for validation expected in mid-2018. 1430 Contact Info: 1432 14. References 1434 14.1. Normative References 1436 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1437 Requirement Levels", BCP 14, RFC 2119, 1438 DOI 10.17487/RFC2119, March 1997, 1439 . 1441 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", 1442 RFC 3463, DOI 10.17487/RFC3463, January 2003, 1443 . 1445 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1446 Specifications: ABNF", STD 68, RFC 5234, 1447 DOI 10.17487/RFC5234, January 2008, 1448 . 1450 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 1451 DOI 10.17487/RFC5598, July 2009, 1452 . 1454 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 1455 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 1456 RFC 6376, DOI 10.17487/RFC6376, September 2011, 1457 . 1459 [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and 1460 Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377, 1461 September 2011, . 1463 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 1464 Authorizing Use of Domains in Email, Version 1", RFC 7208, 1465 DOI 10.17487/RFC7208, April 2014, 1466 . 1468 [RFC7601] Kucherawy, M., "Message Header Field for Indicating 1469 Message Authentication Status", RFC 7601, 1470 DOI 10.17487/RFC7601, August 2015, 1471 . 1473 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1474 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1475 May 2017, . 1477 14.2. Informative References 1479 [ARC-DRAFT-05] 1480 Andersen, K., "Authenticated Received Chain (ARC) Protocol 1481 (I-D-05)", n.d., . 1484 [ARC-DRAFT-06] 1485 Andersen, K., "Authenticated Received Chain (ARC) Protocol 1486 (I-D-06)", n.d., . 1489 [ARC-DRAFT-10] 1490 Andersen, K., "Authenticated Received Chain (ARC) Protocol 1491 (I-D-10)", n.d., . 1494 [ARC-MULTI] 1495 Andersen, K., "Using Multiple Signing Algorithms with 1496 ARC", January 2018, . 1499 [ARC-TEST] 1500 Blank, S., "ARC Test Suite", January 2017, 1501 . 1503 [ARC-USAGE] 1504 Jones, S., Adams, T., Rae-Grant, J., and K. Andersen, 1505 "Recommended Usage of the ARC Headers", December 2017, 1506 . 1509 [ENHANCED-STATUS] 1510 "IANA SMTP Enhanced Status Codes", n.d., 1511 . 1514 [I-D-7601bis] 1515 Kucherawy, M., "Message Header Field for Indicating 1516 Message Authentication Status", February 2018, 1517 . 1520 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1521 Code: The Implementation Status Section", RFC 6982, 1522 DOI 10.17487/RFC6982, July 2013, 1523 . 1525 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 1526 Message Authentication, Reporting, and Conformance 1527 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 1528 . 1530 [RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky, 1531 E., Ed., and K. Andersen, Ed., "Interoperability Issues 1532 between Domain-based Message Authentication, Reporting, 1533 and Conformance (DMARC) and Indirect Email Flows", 1534 RFC 7960, DOI 10.17487/RFC7960, September 2016, 1535 . 1537 14.3. URIs 1539 [1] https://trac.ietf.org/trac/dmarc/ticket/10 1541 [2] https://datatracker.ietf.org/wg/dcrup/about/ 1543 [3] https://trac.ietf.org/trac/dmarc/ticket/11 1545 [4] https://trac.ietf.org/trac/dmarc/ticket/12 1547 [5] https://trac.ietf.org/trac/dmarc/ticket/20 1549 [6] https://trac.ietf.org/trac/dmarc/ticket/21 1551 [7] https://trac.ietf.org/trac/dmarc/ticket/13 1553 [8] https://trac.ietf.org/trac/dmarc/ticket/14 1555 [9] https://trac.ietf.org/trac/dmarc/ticket/15 1557 [10] https://trac.ietf.org/trac/dmarc/ticket/16 1559 [11] https://trac.ietf.org/trac/dmarc/ticket/21 1561 [12] mailto:arc-discuss@dmarc.org 1563 [13] mailto:arc-discuss@dmarc.org 1565 [14] https://github.com/ValiMail/arc_test_suite 1567 [15] mailto:arc-discuss@dmarc.org 1569 [16] https://trac.ietf.org/trac/dmarc/ticket/17 1571 [17] mailto:dmarc@ietf.org 1573 [18] mailto:arc-discuss@dmarc.org 1575 Appendix A. Appendix A - Design Requirements 1577 (This section is re-inserted for background information from 1578 [ARC-DRAFT-06] and earlier versions.) 1580 The specification of the ARC framework is driven by the following 1581 high-level goals, security considerations, and practical operational 1582 requirements. 1584 A.1. Primary Design Criteria 1586 o Provide a verifiable "chain of custody" for email messages; 1588 o Not require changes for originators of email; 1590 o Support the verification of the ARC header field set by each hop 1591 in the handling chain; 1593 o Work at Internet scale; and 1595 o Provide a trustable mechanism for the communication of 1596 Authentication-Results across trust boundaries. 1598 A.2. Out of Scope 1600 ARC is not a trust framework. Users of the ARC header fields are 1601 cautioned against making unsubstantiated conclusions when 1602 encountering a "broken" ARC sequence. 1604 Appendix B. Appendix B - Example Usage 1606 [[ Note: The following examples were mocked up early in the 1607 definition process for the spec. They no longer reflect the current 1608 definition and need various updates which will be included in a 1609 future draft. Issue 17 [16] ]] 1611 (Obsolete but retained for illustrative purposes) 1613 B.1. Example 1: Simple mailing list 1615 B.1.1. Here's the message as it exits the Origin: 1617 Return-Path: 1618 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 1619 (authenticated bits=0) 1620 by segv.d1.example with ESMTP id t0FN4a8O084569; 1621 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 1622 (envelope-from jqd@d1.example) 1623 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; 1624 s=20130426; t=1421363082; 1625 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 1626 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: 1627 Content-Transfer-Encoding; 1628 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw 1629 bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl 1630 gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 1631 Message-ID: <54B84785.1060301@d1.example> 1632 Date: Thu, 14 Jan 2015 15:00:01 -0800 1633 From: John Q Doe 1634 To: arc@dmarc.org 1635 Subject: Example 1 1637 Hey gang, 1638 This is a test message. 1639 --J. 1641 B.1.2. Message is then received at example.org 1642 B.1.2.1. Example 1, Step A: Message forwarded to list members 1644 Processing at example.org: 1646 o example.org performs authentication checks 1648 o No previous Authentication-Results or ARC-Seal headers are present 1650 o example.org adds ARC-Authentication-Results header 1652 o example.org adds Received: header 1654 o example.org adds a ARC-Seal header 1656 Here's the message as it exits example.org: 1658 Return-Path: 1659 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 1660 s=seal2015; d=example.org; cv=none; 1661 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 1662 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 1663 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 1664 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; 1665 d=example.org; s=clochette; t=1421363105; 1666 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; 1667 h=List-Id:List-Unsubscribe:List-Archive:List-Post: 1668 List-Help:List-Subscribe:Reply-To:DKIM-Signature; 1669 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1F5 1670 vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+m4bw 1671 a6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= 1672 Received: from segv.d1.example (segv.d1.example [72.52.75.15]) 1673 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 1674 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) 1675 (envelope-from jqd@d1.example) 1676 ARC-Authentication-Results: i=1; lists.example.org; 1677 spf=pass smtp.mfrom=jqd@d1.example; 1678 dkim=pass (1024-bit key) header.i=@d1.example; 1679 dmarc=pass 1680 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 1681 (authenticated bits=0) 1682 by segv.d1.example with ESMTP id t0FN4a8O084569; 1683 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 1684 (envelope-from jqd@d1.example) 1685 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; 1686 s=20130426; t=1421363082; 1687 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 1688 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: 1689 Content-Transfer-Encoding; 1690 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr 1691 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G 1692 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 1693 Message-ID: <54B84785.1060301@d1.example> 1694 Date: Thu, 14 Jan 2015 15:00:01 -0800 1695 From: John Q Doe 1696 To: arc@example.org 1697 Subject: [Lists] Example 1 1699 Hey gang, 1700 This is a test message. 1701 --J. 1703 B.1.3. Example 1: Message received by Recipient 1705 Let's say that the Recipient is example.com 1707 Processing at example.com: 1709 o example.com performs usual authentication checks 1711 o example.com adds Authentication-Results: header, Received header 1713 o Determines that message fails DMARC 1715 o Checks for ARC-Seal: header; finds one 1717 o Validates the signature in the ARC-Seal: header, which covers the 1718 ARC-Authentication-Results: header 1720 o example.com can use the ARC-Authentication-Results values or 1721 verify the DKIM-Signature from lists.example.org 1723 Here's what the message looks like at this point: 1725 Return-Path: 1726 Received: from example.org (example.org [208.69.40.157]) 1727 by clothilde.example.com with ESMTP id 1728 d200mr22663000ykb.93.1421363207 1729 for ; Thu, 14 Jan 2015 15:02:40 -0800 (PST) 1730 Authentication-Results: clothilde.example.com; spf=fail 1731 smtp.from=jqd@d1.example; dkim=pass (1024-bit key) 1732 header.i=@example.org; dmarc=fail; arc=pass 1733 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 1734 s=seal2015; d=example.org; cv=none; 1735 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 1736 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 1737 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 1738 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; 1739 d=example.org; s=clochette; t=1421363105; 1740 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; 1741 h=List-Id:List-Unsubscribe:List-Archive:List-Post: 1742 List-Help:List-Subscribe:Reply-To:DKIM-Signature; 1743 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF 1744 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3 1745 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= 1746 Received: from segv.d1.example (segv.d1.example [72.52.75.15]) 1747 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 1748 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) 1749 (envelope-from jqd@d1.example) 1750 ARC-Authentication-Results: i=1; lists.example.org; 1751 spf=pass smtp.mfrom=jqd@d1.example; 1752 dkim=pass (1024-bit key) header.i=@d1.example; 1753 dmarc=pass 1754 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 1755 (authenticated bits=0) 1756 by segv.d1.example with ESMTP id t0FN4a8O084569; 1757 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 1758 (envelope-from jqd@d1.example) 1759 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; 1760 s=20130426; t=1421363082; 1761 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 1762 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: 1763 Content-Transfer-Encoding; 1764 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw 1765 bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl 1766 gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 1767 Message-ID: <54B84785.1060301@d1.example> 1768 Date: Thu, 14 Jan 2015 15:00:01 -0800 1769 From: John Q Doe 1770 To: arc@example.org 1771 Subject: [Lists] Example 1 1773 Hey gang, 1774 This is a test message. 1775 --J. 1777 B.2. Example 2: Mailing list to forwarded mailbox 1779 B.2.1. Here's the message as it exits the Origin: 1781 Return-Path: 1782 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 1783 (authenticated bits=0) 1784 by segv.d1.example with ESMTP id t0FN4a8O084569; 1785 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 1786 (envelope-from jqd@d1.example) 1787 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; 1788 s=20130426; t=1421363082; 1789 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 1790 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: 1791 Content-Transfer-Encoding; 1792 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw 1793 bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl 1794 gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 1795 Message-ID: <54B84785.1060301@d1.example> 1796 Date: Thu, 14 Jan 2015 15:00:01 -0800 1797 From: John Q Doe 1798 To: arc@example.org 1799 Subject: Example 1 1801 Hey gang, 1802 This is a test message. 1803 --J. 1805 B.2.2. Message is then received at example.org 1807 B.2.2.1. Example 2, Step A: Message forwarded to list members 1809 Processing at example.org: 1811 o example.org performs authentication checks 1813 o example.org applies standard DKIM signature 1815 o No previous Authentication-Results or ARC-Seal headers are present 1817 o example.org adds ARC-Authentication-Results header 1819 o example.org adds usual Received: header 1821 o example.org adds a ARC-Seal header 1823 Here's the message as it exits Step A: 1825 Return-Path: 1826 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 1827 s=seal2015; d=example.org; cv=none; 1828 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6 1829 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L 1830 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 1831 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; 1832 d=example.org; s=clochette; t=1421363105; 1833 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; 1834 h=List-Id:List-Unsubscribe:List-Archive:List-Post: 1835 List-Help:List-Subscribe:Reply-To:DKIM-Signature; 1836 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF 1837 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3 1838 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= 1839 Received: from segv.d1.example (segv.d1.example [72.52.75.15]) 1840 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 1841 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) 1842 (envelope-from jqd@d1.example) 1843 ARC-Authentication-Results: i=1; lists.example.org; 1844 spf=pass smtp.mfrom=jqd@d1.example; 1845 dkim=pass (1024-bit key) header.i=@d1.example; 1846 dmarc=pass 1847 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 1848 (authenticated bits=0) 1849 by segv.d1.example with ESMTP id t0FN4a8O084569; 1850 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 1851 (envelope-from jqd@d1.example) 1852 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; 1853 s=20130426; t=1421363082; 1854 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 1855 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: 1856 Content-Transfer-Encoding; 1857 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr 1858 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G 1859 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 1860 Message-ID: <54B84785.1060301@d1.example> 1861 Date: Thu, 14 Jan 2015 15:00:01 -0800 1862 From: John Q Doe 1863 To: arc@example.org 1864 Subject: [Lists] Example 1 1866 Hey gang, 1867 This is a test message. 1868 --J. 1870 B.2.2.2. Example 2, Step B: Message from list forwarded 1872 The message is delivered to a mailbox at gmail.com 1873 Processing at gmail.com: 1875 o gmail.com performs usual authentication checks 1877 o gmail.com adds Authentication-Results: and Received: header 1879 o Determines that message fails DMARC 1881 o Checks for ARC-Seal: header; finds one 1883 o Validates the signature in the ARC-Seal: header, which covers the 1884 ARC-Authentication-Results: header 1886 o Uses the ARC-Authentication-Results: values, but: 1888 o Instead of delivering message, prepares to forward message per 1889 user settings 1891 o Applies usual DKIM signature 1893 o gmail.com adds it's own ARC-Seal: header, contents of which are 1895 * version 1897 * sequence number ("i=2") 1899 * hash algorithm (SHA256 as example) 1901 * timestamp ("t=") 1903 * selector for key ("s=notary01") 1905 * domain for key ("d=gmail.com") 1907 * headers included in hash ("h=ARC-Authentication-Results:ARC- 1908 Seal") 1910 * Note: algorithm requires only ARC-Seals with lower sequence # 1911 be included, in ascending order 1913 * signature of the header hash 1915 Here's what the message looks like at this point: 1917 Return-Path: 1918 ARC-Seal: i=2; a=rsa-sha256; t=1421363253; 1919 s=notary01; d=gmail.com; cv=pass; 1920 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDWR 1921 YbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/sut 1922 txO+RRNr0fCFw== 1923 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; 1924 d=gmail.com; s=20120806; 1925 h=mime-version:content-type:x-original-sender: 1926 x-original-authentication-results:precedence:mailing-list: 1927 list-id:list-post:list-help:list-archive:sender:reply-to: 1928 list-unsubscribe:DKIM-Signature; 1929 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=; 1930 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 1931 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 1932 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBmfhS 1933 LF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJRFeM 1934 KdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwDBJtXw 1935 bQoZyRtb6X6q0mYaszUB8kw== 1936 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10 1937 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST) 1938 Authentication-Results: i=2; gmail.com; spf=fail 1939 smtp.from=jqd@d1.example; dkim=pass (1024-bit key) 1940 header.i=@example.org; dmarc=fail; arc=pass 1941 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 1942 s=seal2015; d=example.org; cv=none: 1943 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 1944 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 1945 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 1946 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; 1947 d=example.org; s=clochette; t=1421363105; 1948 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; 1949 h=List-Id:List-Unsubscribe:List-Archive:List-Post: 1950 List-Help:List-Subscribe:Reply-To:DKIM-Signature; 1951 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF 1952 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3 1953 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= 1954 Received: from segv.d1.example (segv.d1.example [72.52.75.15]) 1955 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 1956 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) 1957 (envelope-from jqd@d1.example) 1958 ARC-Authentication-Results: i=1; lists.example.org; 1959 spf=pass smtp.mfrom=jqd@d1.example; 1960 dkim=pass (1024-bit key) header.i=@d1.example; 1961 dmarc=pass 1962 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 1963 (authenticated bits=0) 1964 by segv.d1.example with ESMTP id t0FN4a8O084569; 1965 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 1966 (envelope-from jqd@d1.example) 1967 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; 1968 s=20130426; t=1421363082; 1969 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 1970 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: 1971 Content-Transfer-Encoding; 1972 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr 1973 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G 1974 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 1975 Message-ID: <54B84785.1060301@d1.example> 1976 Date: Thu, 14 Jan 2015 15:00:01 -0800 1977 From: John Q Doe 1978 To: arc@example.org 1979 Subject: [Lists] Example 1 1981 Hey gang, 1982 This is a test message. 1983 --J. 1985 B.2.3. Example 2: Message received by Recipient 1987 Let's say that the Recipient is example.com 1988 Processing at example.com: 1990 o example.com performs usual authentication checks 1992 o example.com adds Authentication-Results: header, Received header 1994 o Determines that message fails DMARC 1996 o Checks for ARC-Seal: header; finds two 1998 o Validates the signature in the highest numbered ("i=2") ARC-Seal: 1999 header, which covers all previous ARC-Seal: and ARC- 2000 Authentication-Results: headers 2002 o Validates the other ARC-Seal header ("i=1"), which covers the ARC- 2003 Authentication-Results: header 2005 o example.com uses the ARC-Authentication-Results: values 2007 Here's what the message looks like at this point: 2009 Return-Path: 2010 Received: from mail-ob0-f188.google.com (mail-ob0-f188.google.com 2011 [208.69.40.157]) by clothilde.example.com with ESMTP id 2012 d200mr22663000ykb.93.1421363268 2013 for ; Thu, 14 Jan 2015 15:03:15 -0800 (PST) 2015 Authentication-Results: clothilde.example.com; spf=fail 2016 smtp.from=jqd@d1.example; dkim=pass (1024-bit key) 2017 header.i=@gmail.com; dmarc=fail; arc=pass 2018 ARC-Seal: i=2; a=rsa-sha256; t=1421363253; 2019 s=notary01; d=gmail.com; cv=pass; 2020 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDWR 2021 YbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/sut 2022 txO+RRNr0fCFw== 2023 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; 2024 d=gmail.com; s=20120806; 2025 h=mime-version:content-type:x-original-sender: 2026 x-original-authentication-results:precedence:mailing-list: 2027 list-id:list-post:list-help:list-archive:sender:reply-to: 2028 :list-unsubscribe:DKIM-Signature; 2029 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=; 2030 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 2031 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 2032 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBmfhS 2033 LF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJRFeM 2034 KdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwDBJtXw 2035 bQoZyRtb6X6q0mYaszUB8kw== 2036 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10 2037 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST) 2038 Authentication-Results: i=2; gmail.com; spf=fail 2039 smtp.from=jqd@d1.example; dkim=pass (1024-bit key) 2040 header.i=@example.org; dmarc=fail; arc=pass 2041 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 2042 s=seal2015; d=example.org; cv=none; 2043 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 2044 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 2045 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 2046 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; 2047 d=example.org; s=clochette; t=1421363105; 2048 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; 2049 h=List-Id:List-Unsubscribe:List-Archive:List-Post: 2050 List-Help:List-Subscribe:Reply-To:DKIM-Signature; 2051 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF 2052 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3 2053 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= 2054 Received: from segv.d1.example (segv.d1.example [72.52.75.15]) 2055 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 2056 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) 2057 (envelope-from jqd@d1.example) 2058 ARC-Authentication-Results: i=1; lists.example.org; 2059 spf=pass smtp.mfrom=jqd@d1.example; 2060 dkim=pass (1024-bit key) header.i=@d1.example; 2061 dmarc=pass 2062 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 2063 (authenticated bits=0) 2064 by segv.d1.example with ESMTP id t0FN4a8O084569; 2065 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 2066 (envelope-from jqd@d1.example) 2067 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; 2068 s=20130426; t=1421363082; 2069 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 2070 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: 2071 Content-Transfer-Encoding; 2072 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr 2073 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G 2074 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 2075 Message-ID: <54B84785.1060301@d1.example> 2076 Date: Thu, 14 Jan 2015 15:00:01 -0800 2077 From: John Q Doe 2078 To: arc@example.org 2079 Subject: [Lists] Example 1 2081 Hey gang, 2082 This is a test message. 2083 --J. 2085 B.3. Example 3: Mailing list to forwarded mailbox with source 2087 B.3.1. Here's the message as it exits the Origin: 2089 Return-Path: 2090 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 2091 (authenticated bits=0) 2092 by segv.d1.example with ESMTP id t0FN4a8O084569; 2093 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 2094 (envelope-from jqd@d1.example) 2095 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 2096 s=origin2015; d=d1.example; cv=none; 2097 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61T 2098 X6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69EU 2099 8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 2100 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; 2101 d=d1.example; s=20130426; t=1421363082; 2102 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 2103 h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding; 2104 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrv 2105 Qwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3 2106 TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 2107 Message-ID: <54B84785.1060301@d1.example> 2108 Date: Thu, 14 Jan 2015 15:00:01 -0800 2109 From: John Q Doe 2110 To: arc@example.org 2111 Subject: Example 1 2113 Hey gang, 2114 This is a test message. 2115 --J. 2117 B.3.2. Message is then received at example.org 2119 B.3.2.1. Example 3, Step A: Message forwarded to list members with 2120 source 2122 Processing at example.org: 2124 o example.org performs authentication checks 2126 o example.org applies standard DKIM signature 2128 o Checks for ARC-Seal: header; finds one (i=1) 2130 o Validates the signature in the ARC-Seal (i=1): header, which 2131 covers the d1.example ARC-Message-Signature: header 2133 o example.org adds ARC-Authentication-Results header 2135 o example.org adds usual Received: header 2136 o example.org adds a DKIM-Signature 2138 o example.org adds a ARC-Seal header, contents of which are 2140 * sequence number ("i=2") 2142 * hash algorithm (SHA256 as example) 2144 * timestamp ("t=") 2146 * chain validity ("cv=") 2148 * selector for key ("s=seal2015") 2150 * domain for key ("d=example.org") 2152 * signature ("b=") 2154 Here's the message as it exits Step A: 2156 Return-Path: 2157 ARC-Seal: i=2; a=rsa-sha256; t=1421363107; 2158 s=seal2015; d=example.org; cv=pass; 2159 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6 2160 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L 2161 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 2162 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; 2163 d=example.org; s=clochette; t=1421363105; 2164 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; 2165 h=List-Id:List-Unsubscribe:List-Archive:List-Post: 2166 List-Help:List-Subscribe:From:Reply-To:DKIM-Signature; 2167 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF 2168 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3 2169 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= 2170 Received: from segv.d1.example (segv.d1.example [72.52.75.15]) 2171 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 2172 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) 2173 (envelope-from jqd@d1.example) 2174 ARC-Authentication-Results: i=2; lists.example.org; 2175 spf=pass smtp.mfrom=jqd@d1.example; 2176 dkim=pass (1024-bit key) header.i=@d1.example; 2177 dmarc=pass 2178 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 2179 (authenticated bits=0) 2180 by segv.d1.example with ESMTP id t0FN4a8O084569; 2181 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 2182 (envelope-from jqd@d1.example) 2183 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 2184 s=origin2015; d=d1.example; cv=none; 2185 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 2186 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 2187 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 2188 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; 2189 d=d1.example; s=20130426; t=1421363082; 2190 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 2191 h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding; 2192 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr 2193 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G 2194 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 2195 Message-ID: <54B84785.1060301@d1.example> 2196 Date: Thu, 14 Jan 2015 15:00:01 -0800 2197 From: John Q Doe 2198 To: arc@example.org 2199 Subject: [Lists] Example 1 2201 Hey gang, 2202 This is a test message. 2203 --J. 2205 B.3.2.2. Example 3, Step B: Message from list forwarded with source 2207 The message is delivered to a mailbox at gmail.com 2208 Processing at gmail.com: 2210 o gmail.com performs usual authentication checks 2212 o gmail.com adds Authentication-Results: and Received: header 2214 o Determines that message fails DMARC 2216 o Checks for ARC-Seal: header; finds two 2218 o Validates the signature in the ARC-Seal (i=2): header, which 2219 covers the ARC-Authentication-Results: header 2221 o Validates the signature in the ARC-Seal (i=1): header, which 2222 covers the d1.example ARC-Message-Signature: header 2224 o Uses the ARC-Authentication-Results: values, but: 2226 o Instead of delivering message, prepares to forward message per 2227 user settings 2229 o Applies usual DKIM signature 2231 o gmail.com adds it's own ARC-Seal: header, contents of which are 2233 * version 2235 * sequence number ("i=2") 2237 * hash algorithm (SHA256 as example) 2239 * timestamp ("t=") 2241 * selector for key ("s=notary01") 2243 * domain for key ("d=gmail.com") 2245 * Note: algorithm requires only ARC-Seals with lower sequence # 2246 be included, in ascending order 2248 * signature of the chain 2250 Here's what the message looks like at this point: 2252 Return-Path: 2253 ARC-Seal: i=3; a=rsa-sha256; t=1421363253; 2254 s=notary01; d=gmail.com; cv=pass; 2255 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwD 2256 WRYbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF 2257 /suttxO+RRNr0fCFw== 2258 ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed; 2259 d=gmail.com; s=20120806; 2260 h=mime-version:content-type:x-original-sender 2261 :x-original-authentication-results:precedence:mailing-list 2262 :list-id:list-post:list-help:list-archive:sender 2263 :list-unsubscribe:reply-to; 2264 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=; 2265 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6 2266 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L 2267 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBm 2268 fhSLF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJ 2269 RFeMKdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwD 2270 BJtXwbQoZyRtb6X6q0mYaszUB8kw== 2271 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10 2272 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST) 2273 Authentication-Results: i=3; gmail.com; spf=fail 2274 smtp.from=jqd@d1.example; dkim=pass (1024-bit key) 2275 header.i=@example.org; dmarc=fail; arc=pass 2276 ARC-Seal: i=2; a=rsa-sha256; t=1421363107; 2277 s=seal2015; d=example.org; cv=pass; 2278 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 2279 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 2280 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 2281 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; 2282 d=example.org; s=clochette; t=1421363105; 2283 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; 2284 h=List-Id:List-Unsubscribe:List-Archive:List-Post: 2285 List-Help:List-Subscribe:Reply-To:DKIM-Signature; 2286 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1 2287 F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+ 2288 m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= 2289 Received: from segv.d1.example (segv.d1.example [72.52.75.15]) 2290 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 2291 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) 2292 (envelope-from jqd@d1.example) 2293 ARC-Authentication-Results: i=2; lists.example.org; 2294 spf=pass smtp.mfrom=jqd@d1.example; 2295 dkim=pass (1024-bit key) header.i=@d1.example; 2296 dmarc=pass 2297 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 2298 (authenticated bits=0) 2299 by segv.d1.example with ESMTP id t0FN4a8O084569; 2300 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 2301 (envelope-from jqd@d1.example) 2302 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 2303 s=origin2015; d=d1.example; cv=none; 2304 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 2305 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 2306 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 2307 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; 2308 d=d1.example; s=20130426; t=1421363082; 2309 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 2310 h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding; 2311 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYij 2312 rvQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD 2313 4Gd3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 2314 Message-ID: <54B84785.1060301@d1.example> 2315 Date: Thu, 14 Jan 2015 15:00:01 -0800 2316 From: John Q Doe 2317 To: arc@example.org 2318 Subject: [Lists] Example 1 2320 Hey gang, 2321 This is a test message. 2322 --J. 2324 B.3.3. Example 3: Message received by Recipient 2326 Let's say that the Recipient is example.com 2327 Processing at example.com: 2329 o example.com performs usual authentication checks 2331 o example.com adds Authentication-Results: header, Received header 2333 o Determines that message fails DMARC 2335 o Checks for ARC-Seal: header; finds three 2337 o Validates the signature in the highest numbered ("i=2") ARC-Seal: 2338 header, which covers all previous ARC-Seal: and ARC- 2339 Authentication-Results: headers 2341 o Validates the other ARC-Seal header ("i=2"), which covers the ARC- 2342 Authentication-Results: header 2344 o Validates the other ARC-Seal header ("i=1"), which covers the 2345 d1.example ARC-Message-Signature: header 2347 o example.com uses the ARC-Authentication-Results: values 2348 Here's what the message looks like at this point: 2350 Return-Path: 2351 Received: from mail-ob0-f188.google.com (mail-ob0-f188.google.com 2352 [208.69.40.157]) by clothilde.example.com with ESMTP id 2353 d200mr22663000ykb.93.1421363268 2354 for ; Thu, 14 Jan 2015 15:03:15 -0800 (PST) 2355 Authentication-Results: clothilde.example.com; spf=fail 2356 smtp.from=jqd@d1.example; dkim=pass (1024-bit key) 2357 header.i=@gmail.com; dmarc=fail; arc=pass 2358 ARC-Seal: i=3; a=rsa-sha256; t=1421363253; 2359 s=notary01; d=gmail.com; cv=pass; 2360 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDW 2361 RYbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/s 2362 uttxO+RRNr0fCFw== 2363 ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed; 2364 d=gmail.com; s=20120806; 2365 h=mime-version:content-type:x-original-sender 2366 :x-original-authentication-results:precedence 2367 :mailing-list:list-id:list-post:list-help:list-archive:sender 2368 :list-unsubscribe:reply-to; 2369 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=; 2370 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6 2371 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L 2372 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBm 2373 fhSLF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJ 2374 RFeMKdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwD 2375 BJtXwbQoZyRtb6X6q0mYaszUB8kw== 2376 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10 2377 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST) 2378 Authentication-Results: i=3; gmail.com; spf=fail 2379 smtp.from=jqd@d1.example; dkim=pass (1024-bit key) 2380 header.i=@example.org; dmarc=fail; arc=pass 2381 ARC-Seal: i=2; a=rsa-sha256; t=1421363107; 2382 s=seal2015; d=example.org; cv=pass; 2383 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6 2384 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L 2385 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 2386 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; 2387 d=example.org; s=clochette; t=1421363105; 2388 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; 2389 h=List-Id:List-Unsubscribe:List-Archive:List-Post: 2390 List-Help:List-Subscribe:Reply-To:DKIM-Signature; 2391 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1 2392 F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+ 2393 m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= 2394 Received: from segv.d1.example (segv.d1.example [72.52.75.15]) 2395 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 2396 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) 2397 (envelope-from jqd@d1.example) 2398 ARC-Authentication-Results: i=2; lists.example.org; 2399 spf=pass smtp.mfrom=jqd@d1.example; 2400 dkim=pass (1024-bit key) header.i=@d1.example; 2401 dmarc=pass 2402 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 2403 (authenticated bits=0) 2404 by segv.d1.example with ESMTP id t0FN4a8O084569; 2405 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 2406 (envelope-from jqd@d1.example) 2407 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 2408 s=origin2015; d=d1.example; cv=none; 2409 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 2410 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 2411 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 2412 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; 2413 d=d1.example; s=20130426; t=1421363082; 2414 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 2415 h=MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding; 2416 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr 2417 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G 2418 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 2419 Message-ID: <54B84785.1060301@d1.example> 2420 Date: Thu, 14 Jan 2015 15:00:01 -0800 2421 From: John Q Doe 2422 To: arc@example.org 2423 Subject: [Lists] Example 1 2425 Hey gang, 2426 This is a test message. 2427 --J. 2429 Appendix C. Acknowledgements 2431 This draft is the work of OAR-Dev Group. 2433 The authors thank all of the OAR-Dev group for the ongoing help and 2434 though-provoking discussions from all the participants, especially: 2435 Alex Brotman, Brandon Long, Dave Crocker, Elizabeth Zwicky, Franck 2436 Martin, Greg Colburn, J. Trent Adams, John Rae-Grant, Mike Hammer, 2437 Mike Jones, Steve Jones, Terry Zink, Tim Draegen. 2439 Grateful appreciation is extended to the people who provided feedback 2440 through the discuss mailing list. 2442 Appendix D. Comments and Feedback 2444 Please address all comments, discussions, and questions to 2445 dmarc@ietf.org [17]. Earlier discussions can be found at arc- 2446 discuss@dmarc.org [18]. 2448 Authors' Addresses 2450 Kurt Andersen 2451 LinkedIn 2452 1000 West Maude Ave 2453 Sunnyvale, California 94085 2454 USA 2456 Email: kurta@linkedin.com 2458 Brandon Long (editor) 2459 Google 2461 Email: blong@google.com 2463 Steven Jones (editor) 2464 TDP 2466 Email: smj@crash.com 2468 Seth Blank (editor) 2469 ValiMail 2471 Email: seth@valimail.com 2473 Murray Kucherawy (editor) 2474 TDP 2476 Email: superuser@gmail.com