idnits 2.17.1 draft-ietf-dmarc-arc-protocol-14.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 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document 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). -- The document date (April 23, 2018) is 2194 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 1405 -- Looks like a reference, but probably isn't: '2' on line 1407 == Missing Reference: 'I-D.ARC' is mentioned on line 1238, but not defined -- Looks like a reference, but probably isn't: '3' on line 1409 -- Looks like a reference, but probably isn't: '4' on line 1411 -- Looks like a reference, but probably isn't: '5' on line 1413 -- Looks like a reference, but probably isn't: '6' on line 1455 -- Looks like a reference, but probably isn't: '7' on line 2292 -- Looks like a reference, but probably isn't: '8' on line 2293 == Unused Reference: 'RFC5322' is defined on line 1312, but no explicit reference was found in the text ** 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 (~~), 9 warnings (==), 12 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: October 25, 2018 Google 6 S. Jones, Ed. 7 TDP 8 S. Blank, Ed. 9 Valimail 10 M. Kucherawy, Ed. 11 TDP 12 April 23, 2018 14 Authenticated Received Chain (ARC) Protocol 15 draft-ietf-dmarc-arc-protocol-14 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 October 25, 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. General Concepts . . . . . . . . . . . . . . . . . . . . 5 65 1.2. Differences Between ARC and DKIM . . . . . . . . . . . . 5 66 1.3. Definitions and Terminology . . . . . . . . . . . . . . . 6 67 1.3.1. Terms defined and used in this document . . . . . . . 6 68 1.3.2. Referenced Definitions . . . . . . . . . . . . . . . 7 69 2. Protocol Elements and Features . . . . . . . . . . . . . . . 7 70 2.1. The "ARC Set" of Header Fields . . . . . . . . . . . . . 8 71 2.1.1. Instance Tags . . . . . . . . . . . . . . . . . . . . 9 72 2.2. Chain Validation Status . . . . . . . . . . . . . . . . . 9 73 2.3. Trace Information . . . . . . . . . . . . . . . . . . . . 9 74 2.4. Key Management . . . . . . . . . . . . . . . . . . . . . 9 75 2.5. All Failures are Permanent . . . . . . . . . . . . . . . 10 76 2.6. Chain of Custody . . . . . . . . . . . . . . . . . . . . 10 77 2.7. Optional Participation . . . . . . . . . . . . . . . . . 10 78 2.8. Broad Responsibility to Seal . . . . . . . . . . . . . . 10 79 2.9. One Chain to Rule Them All . . . . . . . . . . . . . . . 11 80 2.10. Sealing is Always Safe . . . . . . . . . . . . . . . . . 11 81 3. The ARC Header Fields . . . . . . . . . . . . . . . . . . . . 11 82 3.1. Instance ('i=') Tag . . . . . . . . . . . . . . . . . . . 11 83 3.2. ARC-Authentication-Results (AAR) . . . . . . . . . . . . 12 84 3.3. ARC-Message-Signature (AMS) . . . . . . . . . . . . . . . 12 85 3.4. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . . . 13 86 3.4.1. Covered Header Fields . . . . . . . . . . . . . . . . 13 87 3.4.2. The 'cv' Tag . . . . . . . . . . . . . . . . . . . . 14 88 4. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . 14 89 4.1. Authentication-Results Information . . . . . . . . . . . 15 90 4.2. Handling DNS Problems While Validating ARC . . . . . . . 16 91 4.3. Responding to ARC Validity Violations During the SMTP 92 Transaction . . . . . . . . . . . . . . . . . . . . . . . 16 93 5. Sealer Actions . . . . . . . . . . . . . . . . . . . . . . . 16 94 5.1. Marking and Sealing "cv=fail" (Invalid) Chains . . . . . 17 95 6. Recording and Reporting the Results of ARC Evaluation . . . . 17 96 6.1. Information from an ARC Evaluation . . . . . . . . . . . 17 97 6.2. Recording (local) ARC Evaluation Results . . . . . . . . 17 98 6.3. DMARC Reporting of ARC Findings - Interim . . . . . . . . 18 99 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 100 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 101 8.1. Authentication-Results Method Registry Update . . . . . . 19 102 8.2. Email Authentication Result Names Registry Update . . . . 19 103 8.3. Definitions of the ARC header fields . . . . . . . . . . 19 104 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 105 9.1. Header Size . . . . . . . . . . . . . . . . . . . . . . . 20 106 9.2. DNS Operations . . . . . . . . . . . . . . . . . . . . . 20 107 9.3. Message Content Suspicion . . . . . . . . . . . . . . . . 21 108 10. Evaluating the Efficacy of the ARC Protocol (Experimental 109 Considerations) . . . . . . . . . . . . . . . . . . . . . . . 21 110 10.1. Success Consideration . . . . . . . . . . . . . . . . . 21 111 10.2. Failure Considerations . . . . . . . . . . . . . . . . . 22 112 10.3. Open Questions . . . . . . . . . . . . . . . . . . . . . 22 113 10.3.1. Value of the ARC-Seal (AS) Header . . . . . . . . . 22 114 10.3.2. DNS Overhead . . . . . . . . . . . . . . . . . . . . 22 115 10.3.3. Distinguishing Valuable from Worthless Trace 116 Information . . . . . . . . . . . . . . . . . . . . 22 117 11. Implementation Status . . . . . . . . . . . . . . . . . . . . 23 118 11.1. GMail test reflector and incoming validation . . . . . . 24 119 11.2. AOL test reflector and internal tagging . . . . . . . . 24 120 11.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 24 121 11.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . 25 122 11.5. Mailman 3.2 patch . . . . . . . . . . . . . . . . . . . 25 123 11.6. Copernica/MailerQ web-based validation . . . . . . . . . 25 124 11.7. Rspamd . . . . . . . . . . . . . . . . . . . . . . . . . 26 125 11.8. PERL MAIL::DKIM module . . . . . . . . . . . . . . . . . 26 126 11.9. PERL Mail::Milter::Authentication module . . . . . . . . 27 127 11.10. Sympa List Manager . . . . . . . . . . . . . . . . . . . 27 128 11.11. Oracle Messaging Server . . . . . . . . . . . . . . . . 27 129 11.12. MessageSystems Momentum and PowerMTA platforms . . . . . 28 130 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 131 12.1. Normative References . . . . . . . . . . . . . . . . . . 28 132 12.2. Informative References . . . . . . . . . . . . . . . . . 29 133 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 30 134 Appendix A. Appendix A - Design Requirements . . . . . . . . . . 31 135 A.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 31 136 A.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 31 137 Appendix B. Appendix B - Example Usage . . . . . . . . . . . . . 31 138 B.1. Example 1: Simple mailing list . . . . . . . . . . . . . 31 139 B.1.1. Here's the message as it exits the Origin: . . . . . 31 140 B.1.2. Message is then received at example.org . . . . . . . 32 141 B.1.3. Example 1: Message received by Recipient . . . . . . 34 143 B.2. Example 2: Mailing list to forwarded mailbox . . . . . . 35 144 B.2.1. Here's the message as it exits the Origin: . . . . . 35 145 B.2.2. Message is then received at example.org . . . . . . . 36 146 B.2.3. Example 2: Message received by Recipient . . . . . . 40 147 B.3. Example 3: Mailing list to forwarded mailbox with source 42 148 B.3.1. Here's the message as it exits the Origin: . . . . . 42 149 B.3.2. Message is then received at example.org . . . . . . . 43 150 B.3.3. Example 3: Message received by Recipient . . . . . . 48 151 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 50 152 Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 51 153 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 155 1. Introduction 157 Modern email authentication techniques such as the Sender Policy 158 Framework (SPF) [RFC7208] and DomainKeys Identified Mail (DKIM) 159 [RFC6376] have become common. However, their end-to-end utility is 160 limited by the effects of intermediaries along the transmission path, 161 which either are not listed (for SPF) or which break digital 162 signatures (for DKIM). These issues are described in substantial 163 detail in those protocols' defining documents as well as in [RFC6377] 164 and [RFC7960]. 166 Technologies that build upon the use of SPF and DKIM can reduce the 167 success of fraudulent email campaigns. To this end, Domain-based 168 Mail Authentication, Reporting and Conformance (DMARC) [RFC7489], 169 validates the domain of the RFC5322.From header field. However its 170 use along email transmission paths that have independent 171 intermediaries, such as some forwarders and essentially all mailing 172 list services, produces false positive rejections that are 173 problematic, both for the message authors, the intermediary 174 service(s), and for those they are interacting with. 176 [RFC7960] documented the need for a mechanism which would survive 177 legitimate alteration of a message, in spite of breaking the 178 associated SPF and DKIM information so that the end receiver 179 system(s) can avoid those false positive rejections on delivery. 180 Authenticated Received Chain (ARC) builds upon DKIM mechanisms to 181 provide a sequence of signatures that provide a view of the handling 182 sequence for a message, especially the points where alterations of 183 the content might have occurred. Equipped with this more complete 184 information, the recipient system(s) can make a more informed 185 handling choice, reducing or eliminating the rejections that would 186 occur with the use of DKIM and/or SPF alone. 188 1.1. General Concepts 190 ARC provides a "chain of custody" for a message, allowing each entity 191 that handles the message to see what entities handled it before, and 192 to see what the authentication status of the message was at each step 193 in the handling. The handling entity can then put its own entry into 194 the chain of custody and then relay the message to the next handler. 196 When the message reaches final delivery, the decision to accept and 197 deliver the message, or, alternatively, to reject, discard, or 198 quarantine it, can take the chain of custody into account, applying 199 local policy in addition to policies advertised by the (purported) 200 sending domain. Consider, for example, this scenario: 202 1. A sender from mysender.example posts a message to a mailing list 203 hosted at listmania.example; 205 2. The mailing list modifies the message by prepending the list name 206 to the subject line, then sends it to the subscribers; 208 3. One of the subscribers is alice@mail.service.example, which 209 receives the message from listmania.example. 211 Assuming the original message was DKIM-signed and mysender.example 212 published an SPF record, the handling by the mailing list will break 213 the DKIM signature because of the message modification, and the 214 forwarding will cause the SPF check to fail in the next step. But 215 listmania.example can add ARC headers to the message to add itself to 216 the document's chain of custody. When mail.service.example sees the 217 message, it can see that SPF and DKIM validation fail, but it can 218 also see that both of these succeeded when they were checked by 219 listmania.example, and can verify listmania's assertion. 221 As part of its evaluation of the message for delivery, 222 mail.service.example can see that mysender.example publishes a DMARC 223 policy asking that unauthenticated messages be rejected. But is can 224 also see the assertion by listmania.example that the message was 225 correctly authenticated when the message arrived there, and if it 226 accepts that assertion, it can accept the message for further 227 processing, rather than reject it, based on the additional 228 information that ARC has provided. 230 1.2. Differences Between ARC and DKIM 232 In DKIM, every participating signing agent attaches a signature that 233 is based on some of the content of the message, local policy, and the 234 domain name of the signing agent's Administrative Management Domain 235 (ADMD). Any verifier can process such a signature; a verified 236 signature means that the domain referenced in the signature's "d=" 237 parameter has some responsibility for handling the message. An 238 artifact of using digital signature technology for this means that 239 verification also ensures that the portion of the message that was 240 "covered" by the signature has not been altered since the signature 241 was applied. The signatures themselves are generally independent of 242 one another. 244 In contrast, a validated ARC Set conveys the following pieces of 245 information: 247 1. An assertion that, at the time that the intermediary ADMD 248 processed the message, the various assertions (such as SPF, DKIM- 249 Signature(s) and/or ARC Chain) already attached to the message by 250 other ADMDs were or were not valid; 252 2. As with DKIM, an assertion that, for a validated ARC signature, 253 the domain name in the signature takes some responsibility for 254 handling of the message and that the covered content of the 255 message is unchanged since that signature was applied; 257 3. A further assertion that binds the ARC evaluation results into 258 the ARC Chain sequence. 260 1.3. Definitions and Terminology 262 This section defines terms used in the rest of the document. 264 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 265 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 266 "OPTIONAL" in this document are to be interpreted as described in 267 BCP14 ([RFC2119][RFC8174]). 269 Because many of the core concepts and definitions are found in 270 [RFC5598], readers should to be familiar with the contents of 271 [RFC5598], and in particular, the potential roles of intermediaries 272 in the delivery of email. 274 Syntax descriptions use Augmented BNF (ABNF) [RFC5234]. 276 1.3.1. Terms defined and used in this document 278 o "ARC-Authentication-Results" (AAR) - an ARC header field described 279 in Section 3.2. 281 o "ARC-Message-Signature" (AMS) - an ARC header field described in 282 Section 3.3. 284 o "ARC-Seal" (AS) - an ARC header field described in Section 3.4. 286 o "ARC Set" - A single group of the header fields introduced in 287 Section 2.1 is called an "ARC Set". 289 o "ARC Chain" - the complete sequence of ARC Sets for a message. 290 The ARC Chain represents a "chain of custody" for the message, 291 recording its authentication status at each ARC-participating ADMD 292 that handled the message. 294 1.3.2. Referenced Definitions 296 The following terms are defined in other RFCs. Those definitions can 297 be found as follows: 299 o ADMD - [RFC5598], Section 2.3 301 o MTA - [RFC5598], Section 4.3.2 303 o MSA - [RFC5598], Section 4.3.1 305 o MDA - [RFC5598], Section 4.3.3 307 The three header fields that are part of this specification borrow 308 heavily from existing specifications. Rather than repeating all of 309 the formal definitions that are being reused in ARC, this document 310 only describes and specifies changes in syntax and semantics. 312 Language, syntax, and other details are imported from DKIM [RFC6376]. 313 Specific references can be found below. 315 2. Protocol Elements and Features 317 As with other domain authentication technologies (such as SPF, DKIM, 318 and DMARC), ARC makes no claims about the contents of the email 319 message it has sealed. However, for a valid and passing ARC Chain, a 320 Final Receiver is able to ascertain: 322 o all (participating) domains that claim responsibility for handling 323 (and possibly modifying) the email message in transit; 325 o trace information, including: 327 * the [RFC7601] Authentication-Results each participating ADMD 328 saw; and 330 * additional data needed to compile a DMARC report for the 331 sending domain. 333 Given this information, each receiver is able to make a more informed 334 local policy decision regarding message processing and, ultimately, 335 delivery to the end user in spite of authentication failure(s) and to 336 inform the message orgination system(s) through the DMARC report(s). 338 Every participant in an ARC Chain, except for the originating sender 339 and Final Receiver, is both an ARC Validator (when receiving) and 340 then an ARC Sealer (when sending a message onward). 342 _INFORMATIONAL_: It is important to understand that validating and 343 then immediately sealing a message leaves no room for message 344 modification, and many early implementations of ARC did not initially 345 work because both operations were performed in a single pass over the 346 message. 348 The following protocol features are functional parts and design 349 decisions related the protocol that are not specific to either 350 Validators or Sealers, but ensure that the ARC Chain conveys this 351 information to a Final Receiver. 353 2.1. The "ARC Set" of Header Fields 355 Each "ARC Set" consists of the following three new header fields: 357 1. ARC-Authentication-Results (referred to below as "AAR"): 358 virtually identical in syntax to an Authentication-Results field 359 [RFC7601], this field records the results of all message 360 authentication checks done by the recording ADMD at the time the 361 message arrived. Additional information is placed in this field 362 compared to a standard Authentication-Results field in order to 363 support a more complete DMARC report; 365 2. ARC-Message-Signature (referred to below as "AMS"): virtually 366 identical in syntax to DKIM-Signature, this field contains the 367 signature about the message header and body as they existed at 368 the time of handling by the ADMD adding it (including any 369 modifications made by the sealing ADMD); and 371 3. ARC-Seal (referred to below as "AS"): highly similar in structure 372 and format to a DKIM-Signature, this field applies a digital 373 signature that protects the integrity of all three of these new 374 fields when they are added by an ADMD, plus all instances of 375 these fields added by prior ADMDs. 377 An ARC participant always adds all of these header fields before 378 relaying a message to the next handling agent _en route_ to its 379 destination. Moreover, they each have an "instance number" that 380 increases with each ARC Set in the handling chain so that their 381 original order can be preserved and the three related header fields 382 can be processed as a set. 384 2.1.1. Instance Tags 386 ARC includes an indicator in its header fields to show the order in 387 which the header fields comprising an ARC Chain were added, and the 388 specific members of each ARC Set. This is known as the "instance", 389 and the indicator is an "i=" tag/value. That is, the members of the 390 first ARC Set affixed to a message will all include "i=1". This is 391 described in detail in section Section 3.1. 393 2.2. Chain Validation Status 395 ARC includes a mechanism which denotes the state of the ARC Chain at 396 each step. The "chain validation status" ("cv" tag/value) is used to 397 communicate the current chain status within the ARC Chain and also 398 through Authentication-Results and ARC-Authentication-Results stamps 399 as well as DMARC reporting. 401 The chain validation status has one of three possible values: 403 o none: There was no chain on the message when it arrived for 404 validation; typically occurs when the message arrives at a Message 405 Transfer Agent (MTA) or mediator from a Message Submission Agent 406 (MSA) or when any upstream handlers may not be participating in 407 ARC handling; 409 o fail: The message has a chain whose validation failed; 411 o pass: The message has a chain whose validation succeeded. 413 2.3. Trace Information 415 ARC includes trace information encoded in the AAR. While section 416 Section 3.2 defines what information must be provided, sealing ADMDs 417 may provide additional information, and validating receivers may use 418 this trace information as they find it useful. 420 2.4. Key Management 422 The public keys for ARC header fields follow the same requirements, 423 syntax and semantics as those for DKIM signatures, described in 424 Section 3.6 of [RFC6376]. ARC places no requirements on the 425 selectors and/or domains used for the ARC header field signatures. 427 2.5. All Failures are Permanent 429 Because ARC Chains are transmitted across multiple intermediaries, 430 all errors, even temporary ones, become unrecoverable and are 431 considered permanent. 433 Any error validating or sealing a chain, for whatever reason, MUST 434 result in a "cv=fail" verdict as documented in Section 3.4.2. 436 2.6. Chain of Custody 438 At a high level, an ARC Chain represents a chain of custody of 439 authentication and other trace information (AAR) related to a 440 message, signed by each handler of the message. Each link in the 441 chain (AMS) is designed to be brittle, insofar as it survives only 442 until the next modification of the message. However, the sequence of 443 intermediaries in the handling chain (AS) is designed to remain 444 intact over the entirety of the chain. 446 The ARC Chain can be conceptualized through an analogy with the chain 447 of custody for legal evidence. The material evidence itself is 448 sealed within an tamper-proof bag (AMS) each time. When handed to a 449 new party, that party both vouches for the state of the received 450 evidence container (AAR) and signs for the evidence on a chain of 451 custody report form (AS). As with all analogies, this one should not 452 be taken to interpretive extremes, but primarily used as a conceptual 453 framework. 455 An ARC Chain that is valid and passing has the attributes listed 456 above in Section 2. 458 2.7. Optional Participation 460 Validating an existing chain and then adding your own ARC Set to a 461 message allows you to claim responsibility for handling the message 462 and modifications, if any, done by your ADMD to benefit message 463 delivery downstream. However, no ADMD is obligated to perform these 464 actions. 466 2.8. Broad Responsibility to Seal 468 Any mediator ([RFC5598], section 5) that modifies a message may seal 469 its own changes. ARC is not solely intended for perimeter MTAs. 471 2.9. One Chain to Rule Them All 473 A message can have only one ARC Chain on it at a time (see 474 Section 3.1). Once broken, the chain cannot be continued, as the 475 chain of custody is no longer valid and responsibility for the 476 message has been lost. For further discussion of this topic and the 477 designed restriction which prevents chain continuation or re- 478 establishment, see [ARC-USAGE]. 480 2.10. Sealing is Always Safe 482 Even when an ARC Chain is valid and passes, its value is limited to 483 very specific cases. An ARC Chain is specifically designed to 484 provide additional information to a receiver evaluating message 485 delivery in the context of an authentication failure and otherwise be 486 benign. Specifically: 488 o properly adding an ARC Set to a message does not damage or 489 invalidate an existing chain, 491 o sealing a chain when you did not modify a message does not 492 negatively affect the chain, and 494 o validating a message exposes no new threat vectors (see 495 Section 9). 497 _INFORMATIONAL_: If an ADMD is unsure whether it will be re-emitting 498 and/or modifying a message, it may elect to seal all inbound mail. 499 For complex or nested ADMD relationships such as found in some hosted 500 mail solutions, this "inbound seal" can be used to facilitate 501 traversal of internal boundaries as well as properly conveying 502 incoming state to any egress MTAs that may need to assert a seal upon 503 exit from the ADMD. Since these internal relationships are highly 504 implementation dependent, this protocol definition can not usefully 505 explore such usage except to note that it is intentionally allowed 506 within the scope of this specification. 508 3. The ARC Header Fields 510 3.1. Instance ('i=') Tag 512 The header fields comprising a single ARC Set are identified by a 513 common "instance" tag value. The instance tag is a string in each 514 header field value that complies with the "tag-spec" ABNF found in 515 Section 3.2 of [RFC6376]. The tag-name is "i" and the value is the 516 text representation of a positive integer, indicating the position in 517 the ARC sequence this set occupies, where the first ARC Set is 518 numbered 1. In ABNF terms: 520 position = 1*2DIGIT ; 1 - 50 521 instance = [FWS] %x69 [FWS] "=" [FWS] position [FWS] ";" 523 Valid ARC Sets MUST have exactly one instance of each header field 524 (of three) for a given instance value and signing algorithm. 526 (_INFORMATIONAL:_ Initial development of ARC is only being done with 527 a single allowed signing algorithm, but parallel work in the DCRUP 528 working group [1] is expanding that. For handling multiple signing 529 algorithms, see [ARC-MULTI].) 531 The 'i' tag value can range from 1-50 (inclusive). 533 ARC Chains longer than the defined maximum count MUST be marked as 534 failed. 536 _INFORMATIONAL_: Because the AMS and AS header field values are made 537 up of tag-spec constructs, the i= tag may be found anywhere within 538 the header field value, but is represented throughout this spec in 539 the initial position for convenience. Implementers are encouraged to 540 place the i= tag at the beginning of the field value to facilitate 541 human inspection of the headers. 543 3.2. ARC-Authentication-Results (AAR) 545 The ARC-Authentication-Results header field is syntactically and 546 semantically identical, except for the header field name itself and 547 its instance tag, to an Authentication-Results header field (defined 548 in Section 2.2 of [I-D-7601bis]). 550 Formally, the header field is specified as follows using ABNF 551 [RFC5234]: 553 arc-info = instance [CFWS] ";" authres-payload 554 arc-authres-header = "ARC-Authentication-Results:" [CFWS] arc-info 556 The AAR MUST contain all Authentication-Results from within the 557 participating ADMD, regardless of how many Authentication-Results 558 headers are on the message. 560 3.3. ARC-Message-Signature (AMS) 562 The ARC-Message-Signature header field is simplified version of a 563 DKIM-Signature header field [RFC6376], with the following 564 modifications: 566 o There is an "i" tag, as described in Section 3.1. 568 o There is no "v" tag defined for the AMS header. As required for 569 undefined tags (in [RFC6376]), if seen, it MUST be ignored. 571 ARC-related header fields (ARC-Seal, ARC-Message-Signture, ARC- 572 Authentication-Results) MUST NOT be included in the content covered 573 by the signature in the signature in this header field. 575 The AMS SHOULD include any DKIM-Signature header fields already 576 present on the message in the header fields covered by this 577 signature. 579 Authentication-Results header fields MUST NOT be included since they 580 are likely to be deleted by downstream ADMDs (per Section 5 of 581 [RFC7601]), thereby breaking the AMS signature. 583 3.4. ARC-Seal (AS) 585 The ARC-Seal header field is syntactically and semantically similar 586 to a DKIM-Signature field, with the following exceptions: 588 o There is an "i" tag, as described in Section 3.1. 590 o The ARC-Seal covers none of the body content of the message. It 591 only covers specific header fields as defined below: 592 Section 3.4.1. No body canonicalization is done. 594 o Only "relaxed" header canonicalization (Section 3.4.2 of 595 [RFC6376]) is used. 597 o The only supported tags are "i" (from Section 3.1 of this 598 document), and "a", "b", "d, "s", "t" from Section 3.5 of 599 [RFC6376]. 601 o An additional tag, "cv" is defined in Section 3.4.2 603 3.4.1. Covered Header Fields 605 The ARC-Seal signs a specific canonicalized form of the ARC Set 606 header values. The ARC set header values are compiled in increasing 607 instance order, starting at 1, and include the set being added at the 608 time of sealing the message. 610 Within a set, the header fields are listed in the following order: 612 1. ARC-Authentication-Results 614 2. ARC-Message-Signature 615 3. ARC-Seal 617 Where the ARC-Seal is the one being generated, it is input to the 618 hash function in its final form except with an empty "b=" value, in 619 the same manner by which a DKIM-Signature signs itself ([RFC6376], 620 section 3.7). 622 Note that the signing scope for the ARC-Seal is modified in the 623 situation where a chain has failed validation (see Section 5.1). 625 3.4.2. The 'cv' Tag 627 A new tag "cv" (chain validation) indicates the outcome of evaluating 628 the existing ARC Chain upon arrival at the ADMD that is adding this 629 header field. The values are defined per Section Section 2.2. 631 In ABNF terms: 633 chain-status = ("none" / "fail" / "pass") 634 seal-cv-tag = %x63.76 [FWS] "=" [FWS] chain-status 636 4. Verifier Actions 638 A verifier takes the following steps to validate the ARC Chain. 639 Canonicalization, hash functions, and signature validation methods 640 are imported from Section 5 of [RFC6376]. 642 1. Collect all ARC Sets currently on the message. If there were 643 none, the ARC state is "none" and the algorithm stops here. 645 2. Check the morphology of the ARC Chain. If any of these 646 conditions are not met, the chain state is "fail" and the 647 algorithm stops here: 649 1. Each ARC Set must be complete (e.g., contains exactly one of 650 each of the three ARC-specific header fields); 652 2. The instance values must form a continuous sequence from 1..N 653 with no gaps or repeats; 655 3. The cv value for all ARC-Seal(s) must be non-failing: 657 1. For i > 1, the value must be "pass"; 659 2. For i = 1, the value must be "none". 661 3. For each ARC-Message-Signature from the "N"th instance to the 662 first, validate the AMS: 664 1. If the "N"th instance (most recent) signature fails, then the 665 chain state is "fail" and the algorithm stops here. 667 2. If one of the prior AMS signatures fails to validate (for 668 instance "M"), then set the oldest-pass value to the lowest 669 AMS instance number which passed (M+1) and go onto the next 670 step (there is no need to check any other (older) AMS 671 signatures). This does not affect the validity of the chain. 673 3. If all AMS signatures verify, set the oldest-pass value to 674 zero (0). 676 4. For each ARC-Seal from the "N"th instance to the first, validate 677 the seal. 679 1. If any seal is not valid, the chain state is "fail" and the 680 algorithm stops here. 682 2. If all seals pass validation, then the chain state is "pass", 683 and the algorithm is complete. 685 The end result of the verifier's checks via this algorithm MUST be 686 added into the Authentication-Results header(s) for the ADMD. 688 _INFORMATIONAL_: Recipients of an ARC Chain that is invalid or does 689 not pass SHOULD NOT draw negative conclusions without a good 690 understanding of the wider handling context. Until ARC usage is 691 widespread, intermediaries will continue to modify messages without 692 ARC seals. 694 As with a failing DKIM signature ([RFC6376] Section-6.3), a message 695 with a failing ARC Chain MUST be treated the same as a message with 696 no ARC Chain. 698 4.1. Authentication-Results Information 700 Certain information pertinent to ascertaining message disposition can 701 be lost in transit when messages are handled by intermediaries. For 702 example, failing DKIM signatures are sometimes removed by MTAs, and 703 most DKIM signatures on messages modified by intermediaries will 704 fail. Recording the following information in the Authentication- 705 Results stamped as part of the ARC evaluation provides a mechanism 706 for this information to survive transit through a particular ADMD. 708 Stamped ARC evaluation results is limited to the Chain Validation 709 status (cv) from Section 2.2. 711 The ptypes and properties defined in this section SHOULD be recorded 712 in the Authentication-Results: 714 o smtp.client-ip - The connecting client IP address from which the 715 message is received; 717 o header.oldest-pass - The instance number of the oldest AMS that 718 still validates, or 0 if all pass. 720 4.2. Handling DNS Problems While Validating ARC 722 DNS-based failures to verify a chain are treated no differently than 723 any other ARC violation. They result in a "cv=fail" verdict. 725 4.3. Responding to ARC Validity Violations During the SMTP Transaction 727 If a receiver determines that the ARC Chain has failed, the receiver 728 MAY signal the breakage through the extended SMTP response code 5.7.7 729 [RFC3463] "message integrity failure" [ENHANCED-STATUS] and 730 corresponding SMTP response code. 732 5. Sealer Actions 734 An ARC sealer MUST take the following actions when presented with a 735 message: 737 1. Before creating an ARC signature, perform any other, normal 738 authentication and/or signing, so that the ARC signature can 739 cover those results. 741 2. Build and attach the new ARC Set: 743 1. If an ARC Chain exists on the message, then set "N" equal to 744 the highest instance number found on the chain (i=); 745 otherwise set "N" equal to zero for the following steps. 747 2. Generate and attach to the message an ARC-Authentication- 748 Results header field as defined in Section Section 3.2, using 749 instance number N+1 and the same content from the previous 750 step. 752 3. Generate and attach to the message an ARC-Message-Signature 753 header field as defined in Section 3.3 above, using instance 754 number N+1. 756 4. Generate and attach to the message an ARC-Seal header field 757 using the general algorithm described in Section 3.4 above, 758 the chain validation status as determined in Section 4, and 759 instance number N+1. 761 5.1. Marking and Sealing "cv=fail" (Invalid) Chains 763 The header fields signed by the AS header field b= value in the case 764 of a chain failure MUST be only the matching instance headers created 765 by the MTA which detected the malformed chain, as if this newest ARC 766 Set was the only set present. 768 _INFORMATIONAL:_ In the case of a malformed or otherwise invalid 769 chain there is no way to generate a deterministic set of AS header 770 fields ({#implicit_as_h}) so this approach is mandated. 772 6. Recording and Reporting the Results of ARC Evaluation 774 The evaluation of an ARC Chain provides information which will be 775 useful to both the receiver (or intermediary) and to the initial 776 sender of the message. This information should be preserved and 777 reported as follows. 779 6.1. Information from an ARC Evaluation 781 The evaluation of an ARC Chain produces a list of domain names for 782 participating intermediaries which handled the message, to wit: 784 o A list of the "d=" domains found in the validated ARC-Seal header 785 fields 787 o The "d=" domain found in the most recent (highest instance number) 788 AMS header field (since that is the only one necessarily 789 validated) 791 In the case of a failed chain, only the terminal ARC Set is covered 792 by the ARC-Seal so the reporting is limited to the findings in that 793 terminal ARC Set. 795 6.2. Recording (local) ARC Evaluation Results 797 Receivers who process an attached ARC Chain SHOULD add an 798 "arc=[pass|fail|policy]" method annotation into a locally-affixed 799 Authentication-Results [RFC7601] header field along with any salient 800 comment(s). 802 Details of the ARC Chain which was evaluated should be included in 803 the Authentication-Results and AAR headers per Section Section 4.1. 805 6.3. DMARC Reporting of ARC Findings - Interim 807 Receivers SHOULD indicate situations in which ARC evaluation 808 influenced the results of their local policy determination. DMARC 809 reporting of ARC-informed decisions can be accomplished by adding a 810 local_policy comment explanation containing the list of data 811 discovered in the ARC evaluation, which at a minimum SHOULD include: 812 * the Chain Validation status, * the domain and selector for each AS, 813 * the IP addresses of the mail originating ADMD: 815 816 none 817 fail 818 fail 819 820 local_policy 821 arc=pass ams[2].d=d2.example ams[2].s=s1 as[2].d=d2.example 822 as[2].s=s2 as[1].d=d1.example as[1].s=s3 client-ip[1]=10.10.10.13 823 824 826 In the sample above, d2.example is the sealing domain for ARC[2] and 827 d1.example is the sealing domain for ARC[1]. 829 Intermediary message handlers SHOULD generate DMARC reports on 830 messages which transit their system just like any other message which 831 they receive. This will result in multiple reports for each mediated 832 message as they transit the series of handlers. DMARC report 833 consumers should be aware of this behaviour and make the necessary 834 accommodations. 836 7. Privacy Considerations 838 The ARC Chain provides a verifiable record of the handlers for a 839 message. Anonymous remailers will probably not find this compatible 840 with their operating goals. 842 8. IANA Considerations 844 [[ Note to the RFC Editors: Some of these fields are defined both 845 here and in [I-D-7601bis]. Please delete the overlap from whichever 846 document goes through the publication process after the other. ]] 848 This specification adds three new header fields as defined below. 850 8.1. Authentication-Results Method Registry Update 852 This draft adds one item to the IANA "Email Authentication Methods" 853 registry: 855 o Method : arc 856 Defined: [I-D.ARC] 857 ptype: header 858 Property: chain evaluation result 859 Value: chain evaluation result status (see Section 3.4) 860 Status: active 862 8.2. Email Authentication Result Names Registry Update 864 This draft updates the Email Authentication Results registry, most 865 recently defined in [I-D-7601bis], with one new authentication method 866 and several status codes, all defined by this document: 868 o Auth Method : arc 869 Code: "none", "pass", "fail" 870 Specification: [I-D.ARC] Section 3.4.2 Status: active 872 o Method : spf 873 Defined: [I-D.ARC] 874 ptype: smtp 875 Property: client-ip 876 Value: the connecting client IP address from which the message is 877 received 878 Status: active 880 o Method : arc 881 Defined: [I-D.ARC] 882 ptype: header 883 Property: oldest-pass 884 Value: the oldest instance with a still validating AMS signature 885 Status: active 887 8.3. Definitions of the ARC header fields 889 This specification adds three new header fields to the "Permanent 890 Message Header Field Registry", as follows: 892 o Header field name: ARC-Seal 893 Applicable protocol: mail 894 Status: draft 895 Author/Change controller: IETF 896 Specification document(s): [I-D.ARC] 897 Related information: [RFC6376] 899 o Header field name: ARC-Message-Signature 900 Applicable protocol: mail 901 Status: draft 902 Author/Change controller: IETF 903 Specification document(s): [I-D.ARC] 904 Related information: [RFC6376] 906 o Header field name: ARC-Authentication-Results 907 Applicable protocol: mail 908 Status: standard 909 Author/Change controller: IETF 910 Specification document(s): [I-D.ARC] 911 Related information: [RFC7601] 913 9. Security Considerations 915 The Security Considerations of [RFC6376] and [RFC7601] apply directly 916 to this specification. 918 9.1. Header Size 920 Inclusion of ARC Sets in the header of emails may cause problems for 921 some older or more constrained MTAs if they are unable to accept the 922 greater size of the header. 924 9.2. DNS Operations 926 Operators who receive a message bearing N ARC Sets have to complete 927 up to N+1 DNS queries to evaluate the chain (barring DNS redirection 928 mechanisms which can increase the lookups for a given target value). 929 This has at least two effects: 931 1. An attacker can send a message to an ARC participant with a 932 concocted sequence of ARC Sets bearing the domains of intended 933 victims, and all of them will be queried by the participant until 934 a failure is discovered. The difficulty of forging the signature 935 values should limit the extent of this load to domains under 936 control of the attacker. 938 2. DKIM only does one DNS check per signature, while this one can do 939 many (per chain). Absent caching, slow DNS responses can cause 940 SMTP timeouts; and backlogged delivery queues on mediating 941 systems. This could be exploited as a DoS attack. 943 9.3. Message Content Suspicion 945 Recipients are cautioned to treat messages bearing ARC Sets with the 946 same suspicion that they apply to all other email messages. This 947 includes appropriate content scanning and other checks for 948 potentially malicious content. The handlers which are identified 949 within the ARC Chain may be used to provide input to local policy 950 engines in cases where DMARC validation fails (due to mediation 951 impacting SPF attribution, DKIM validity or alignment). 953 Note that a passing ARC Chain may not adequately mean that the 954 message is safe because: 956 1. You have to trust all signatories; and 958 2. Even trusted systems may have become compromised or may not 959 properly authenticate messages, so even with a chain of trusted 960 participants, the message might still never have authenticated in 961 the first place (which is why you have the AAR to inspect) or 962 could have been subject to unintended modifications. 964 10. Evaluating the Efficacy of the ARC Protocol (Experimental 965 Considerations) 967 The ARC protocol is designed to mitigate some of the most common 968 failure conditions for email which transits intermediary handlers en 969 route to the final recipient. Some of these problems have happened 970 due to the adoption of the DMARC protocol [RFC7489] and are listed in 971 [RFC6377] and [RFC7960]. 973 As the ARC protocol becomes standardized and implemented amongst 974 intermediary handlers, the following aspects should be evaluated in 975 order to determine the success of the protocol in accomplishing the 976 intended benefits. 978 NOTE: Terminology within this section does NOT follow [RFC2119] 979 interpretation. This section represents the current thoughts of the 980 working group regarding unanswered questions related to the protocol. 981 Wider deployment will inform these topics and probably expand them. 983 10.1. Success Consideration 985 Currently, many receivers have heuristically determined overrides in 986 order to rescue mail from intermediary-caused failures. Many of 987 those overrides rely on inferrence rather than direct evidence. 989 ARC will be a success if, for ARC sealed messages, receivers are able 990 to implment ARC-based algorithmic decisions based on the direct 991 evidence found within the ARC Chain. This is especially relevant for 992 DMARC processing when the DKIM d= value is aligned with the 993 rfc5322.From author domain. 995 10.2. Failure Considerations 997 The intent of ARC is to be at most value-add and at worst benign. If 998 ARC opens up significant new vectors for abuse (see Section 9) then 999 this protocol will be a failure. Note that weaknesses inherent in 1000 the mail protocols ARC is built upon (such as DKIM replay attacks and 1001 other known issues) are not new vectors which can be attributed to 1002 this specification. 1004 10.3. Open Questions 1006 The following open questions are academic and have no clear answer at 1007 the time of the development of the protocol. However, wide-spread 1008 deployment should be able to gather the necessary data to answer some 1009 or all of them. 1011 10.3.1. Value of the ARC-Seal (AS) Header 1013 Data should be collected to show if the ARC-Seal (AS) provides value 1014 beyond the ARC Message Signature (AMS) for either making delivery 1015 decisions or catching malicious actors trying to craft or replay 1016 malicious chains. 1018 10.3.2. DNS Overhead 1020 Longer ARC Chains will require more queries to retrieve the keys for 1021 validating the chain. While this is not believed to be a security 1022 issue (see Section 9.2), it is unclear how much overhead will truly 1023 be added. This is similar to some of the initial processing and 1024 query load concerns which were debated at the time of the DKIM 1025 specification development. 1027 Data should be collected to better understand usable length and 1028 distribution of lengths found in valid ARC Chains along with the the 1029 DNS impact of processing ARC Chains. 1031 An effective operational maximum will have to be developed through 1032 deployment experience in the field. 1034 10.3.3. Distinguishing Valuable from Worthless Trace Information 1036 There are several edge cases where the information in the AAR can 1037 make the difference between message delivery or rejection. For 1038 example, if there is a well known mailing list that ARC seals but 1039 doesn't do its own initial DMARC enforcement, a Final Receiver with 1040 this knowledge could make a delivery decision based upon the 1041 authentication information it sees in the corresponding AAR header. 1043 Certain trace information in the AAR is useful/necessary in the 1044 construction of DMARC reports. It would be beneficial to identify 1045 the value-add of having intermediary-handled mail flow information 1046 added into the DMARC reports going back to senders. 1048 Certain receivers believe the entire set of trace information would 1049 be valuable to feed into machine learning systems to identify fraud 1050 and/or provide other signals related to message delivery. 1052 It is unclear what trace information will be valuable for all 1053 receivers, regardless of size. 1055 Data should be collected on what trace information receivers are 1056 using that provides useful signals that affect deliverability, and 1057 what portions of the trace data are left untouched or provide no 1058 useful information. 1060 Since many such systems are intentionally proprietary or confidential 1061 to prevent gaming by abusers, it may not be viable to reliably answer 1062 this particular question. The evolving nature of attacks can also 1063 shift the landscape of "useful" information over time. 1065 11. Implementation Status 1067 [[ Note to the RFC Editor: Please remove this section before 1068 publication along with the reference to [RFC6982]. ]] 1070 This section records the status of known implementations of the 1071 protocol defined by this specification at the time of posting of this 1072 Internet-Draft, and is based on a proposal described in [RFC6982]. 1073 The description of implementations in this section is intended to 1074 assist the IETF in its decision processes in progressing drafts to 1075 RFCs. Please note that the listing of any individual implementation 1076 here does not imply endorsement by the IETF. Furthermore, no effort 1077 has been spent to verify the information presented here that was 1078 supplied by IETF contributors. This is not intended as, and must not 1079 be construed to be, a catalog of available implementations or their 1080 features. Readers are advised to note that other implementations may 1081 exist. 1083 This information is known to be correct as of the seventh 1084 interoperability test event which was held on 2017-07-15 & 16 at 1085 IETF99. 1087 For a few of the implementations, later status information was 1088 available as of December 2017. 1090 11.1. GMail test reflector and incoming validation 1092 Organization: Google 1093 Description: Internal production implementation with both debug 1094 analysis and validating + sealing pass-through function 1095 Status of Operation: Production - Incoming Validation 1096 Coverage: Full spec implemented as of [ARC-DRAFT-06] 1097 Licensing: Proprietary - Internal only 1098 Implementation Notes: 1100 o Full functionality was demonstrated during the interop testing on 1101 2017-07-15. 1103 Contact Info: arc-discuss@dmarc.org [2] 1105 11.2. AOL test reflector and internal tagging 1107 Organization: AOL 1108 Description: Internal prototype implementation with both debug 1109 analysis and validating + sealing pass-through function 1110 Status of Operation: Beta 1111 Coverage: ARC Chain validity status checking is operational, but only 1112 applied to email addresses enrolled in the test program. 1113 This system conforms to [ARC-DRAFT-06] 1114 Licensing: Proprietary - Internal only 1115 Implementation Notes: 1117 o 2017-07-15: Full functionality verified during the interop 1118 testing. 1120 Contact Info: arc-discuss@dmarc.org [3] 1122 11.3. dkimpy 1124 Organization: dkimpy developers/Scott Kitterman 1125 Description: Python DKIM package 1126 Status of Operation: Production 1127 Coverage: 1129 o 2017-07-15: The internal test suite is incomplete, but the command 1130 line developmental version of validator was demonstrated to 1131 interoperate with the Google and AOL implementations during the 1132 interop on 2017-07-15 and the released version passes the tests in 1133 [ARC-TEST] arc_test_suite [4] with both python and python3. 1135 Licensing: Open/Other (same as dkimpy package = BCD version 2) 1136 Contact Info: https://launchpad.net/dkimpy 1138 11.4. OpenARC 1140 Organization: TDP/Murray Kucherawy 1141 Description: Implemention of milter functionality related to the 1142 OpenDKIM and OpenDMARC packages 1143 Status of Operation: Beta 1144 Coverage: Built to support [ARC-DRAFT-10] 1145 Licensing: Open/Other (same as OpenDKIM and OpenDMARC packages) 1146 Implementation Notes: 1148 o The build is FreeBSD oriented but some packages have been built 1149 for easier deployment on RedHat-based Linux platforms. 1151 o Some issues still exist when deploying in a chained milter 1152 arrangement (such as OpenSPF -> OpenDKIM -> OpenDMARC -> OpenARC) 1153 with coordination between the stages. When deployed in a 1154 "sandwich" configuration around an MLM, there is no effective 1155 mechanism to convey trust from the ingress (validator) to egress 1156 (signer) instances. (_NOTE_: this is expected to resolved with a 1157 new release of OpenDMARC expected in January 2018.) 1159 Contact Info: arc-discuss@dmarc.org [5] 1161 11.5. Mailman 3.2 patch 1163 Organization: Mailman development team 1164 Description: Integrated ARC capabilities within the Mailman 3.2 1165 package 1166 Status of Operation: Patch submitted 1167 Coverage: Based on OpenARC 1168 Licensing: Same as mailman package - GPL 1169 Implementation Notes: 1171 o Appears to work properly in at least one beta deployment, but 1172 waiting on acceptance of the pull request into the mainline of 1173 mailman development 1175 Contact Info: https://www.gnu.org/software/mailman/contact.html 1177 11.6. Copernica/MailerQ web-based validation 1179 Organization: Copernica 1180 Description: Web-based validation of ARC-signed messages 1181 Status of Operation: Beta 1182 Coverage: Built to support [ARC-DRAFT-05] 1183 Licensing: On-line usage only 1184 Implementation Notes: 1186 o Released 2016-10-24 1188 o Requires full message content to be pasted into a web form found 1189 at http://arc.mailerq.com/ (warning - https is not supported). 1191 o An additional instance of an ARC signature can be added if one is 1192 willing to paste a private key into an unsecured web form. 1194 o 2017-07-15: Testing shows that results match the other 1195 implementations listed in this section. 1197 Contact Info: https://www.copernica.com/ 1199 11.7. Rspamd 1201 Organization: Rspamd community 1202 Description: ARC signing and verification module 1203 Status of Operation: Production, though deployment usage is unknown 1204 Coverage: Built to support [ARC-DRAFT-06] 1205 Licensing: Open source 1206 Implementation Notes: 1208 o 2017-06-12: Released with version 1.6.0 1210 o 2017-07-15: Testing during the interop showed that the validation 1211 functionality interoperated with the Google, AOL, dkimpy and 1212 MailerQ implementations 1214 Contact Info: https://rspamd.com/doc/modules/arc.html and 1215 https://github.com/vstakhov/rspamd 1217 11.8. PERL MAIL::DKIM module 1219 Organization: FastMail 1220 Description: Email domain authentication (sign and/or verify) module, 1221 previously included SPF / DKIM / DMARC, now has ARC added 1222 Status of Operation: Production, deployment usage unknown 1223 Coverage: Built to support [ARC-DRAFT-10] 1224 Licensing: Open Source 1225 Implementation Notes: 1227 o 2017-12-15: v0.50 released with full test set passing for ARC 1229 Contact Info: http://search.cpan.org/~mbradshaw/Mail-DKIM-0.50/ 1231 11.9. PERL Mail::Milter::Authentication module 1233 Organization: FastMail 1234 Description: Email domain authentication milter, uses MAIL::DKIM (see 1235 above) 1236 Status of Operation: Intial validation completed during IETF99 1237 hackathon with some follow-on work during the week 1238 Coverage: Built to support [I-D.ARC] 1239 Licensing: Open Source 1240 Implementation Notes: 1242 o 2017-07-15: Validation functionality which interoperates with 1243 Gmail, AOL, dkimpy was demonstrated; later in the week of IETF99, 1244 the signing functionality was reported to be working 1246 o 2017-07-20: ARC functionality has not yet been pushed back to the 1247 github repo but should be showing up soon 1249 Contact Info: https://github.com/fastmail/authentication_milter 1251 11.10. Sympa List Manager 1253 Organization: Sympa Dev Community 1254 Description: Work in progress 1255 Status of Operation: Work in progress 1256 Coverage: unknown 1257 Licensing: open source 1258 Implementation Notes: 1260 o 2018-01-05: Tracked as https://github.com/sympa-community/sympa/ 1261 issues/153 1263 Contact Info: https://github.com/sympa-community 1265 11.11. Oracle Messaging Server 1267 Organization: Oracle 1268 Description: 1269 Status of Operation: Intial development work during IETF99 hackathon. 1270 Status since then unknown. 1271 Coverage: Work in progress 1272 Licensing: Unknown 1273 Implementation Notes: 1275 o 2018-03: Protocol handling components are completed, but crypto is 1276 not yet functional. 1278 Contact Info: Chris Newman 1280 11.12. MessageSystems Momentum and PowerMTA platforms 1282 Organization: MessageSystems/SparkPost 1283 Description: OpenARC integration into the LUA-enabled Momentum 1284 processing space 1285 Status of Operation: Beta 1286 Coverage: Built to support [ARC-DRAFT-10] 1287 Licensing: Unknown 1288 Implementation Notes: 1290 o Initial deployments for validation expected in mid-2018. 1292 Contact Info: 1294 12. References 1296 12.1. Normative References 1298 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1299 Requirement Levels", BCP 14, RFC 2119, 1300 DOI 10.17487/RFC2119, March 1997, 1301 . 1303 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", 1304 RFC 3463, DOI 10.17487/RFC3463, January 2003, 1305 . 1307 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1308 Specifications: ABNF", STD 68, RFC 5234, 1309 DOI 10.17487/RFC5234, January 2008, 1310 . 1312 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1313 DOI 10.17487/RFC5322, October 2008, 1314 . 1316 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 1317 DOI 10.17487/RFC5598, July 2009, 1318 . 1320 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 1321 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 1322 RFC 6376, DOI 10.17487/RFC6376, September 2011, 1323 . 1325 [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and 1326 Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377, 1327 September 2011, . 1329 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 1330 Authorizing Use of Domains in Email, Version 1", RFC 7208, 1331 DOI 10.17487/RFC7208, April 2014, 1332 . 1334 [RFC7601] Kucherawy, M., "Message Header Field for Indicating 1335 Message Authentication Status", RFC 7601, 1336 DOI 10.17487/RFC7601, August 2015, 1337 . 1339 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1340 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1341 May 2017, . 1343 12.2. Informative References 1345 [ARC-DRAFT-05] 1346 Andersen, K., "Authenticated Received Chain (ARC) Protocol 1347 (I-D-05)", n.d., . 1350 [ARC-DRAFT-06] 1351 Andersen, K., "Authenticated Received Chain (ARC) Protocol 1352 (I-D-06)", n.d., . 1355 [ARC-DRAFT-10] 1356 Andersen, K., "Authenticated Received Chain (ARC) Protocol 1357 (I-D-10)", n.d., . 1360 [ARC-MULTI] 1361 Andersen, K., "Using Multiple Signing Algorithms with 1362 ARC", January 2018, . 1365 [ARC-TEST] 1366 Blank, S., "ARC Test Suite", January 2017, 1367 . 1369 [ARC-USAGE] 1370 Jones, S., Adams, T., Rae-Grant, J., and K. Andersen, 1371 "Recommended Usage of the ARC Headers", December 2017, 1372 . 1375 [ENHANCED-STATUS] 1376 "IANA SMTP Enhanced Status Codes", n.d., 1377 . 1380 [I-D-7601bis] 1381 Kucherawy, M., "Message Header Field for Indicating 1382 Message Authentication Status", February 2018, 1383 . 1386 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1387 Code: The Implementation Status Section", RFC 6982, 1388 DOI 10.17487/RFC6982, July 2013, 1389 . 1391 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 1392 Message Authentication, Reporting, and Conformance 1393 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 1394 . 1396 [RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky, 1397 E., Ed., and K. Andersen, Ed., "Interoperability Issues 1398 between Domain-based Message Authentication, Reporting, 1399 and Conformance (DMARC) and Indirect Email Flows", 1400 RFC 7960, DOI 10.17487/RFC7960, September 2016, 1401 . 1403 12.3. URIs 1405 [1] https://datatracker.ietf.org/wg/dcrup/about/ 1407 [2] mailto:arc-discuss@dmarc.org 1409 [3] mailto:arc-discuss@dmarc.org 1411 [4] https://github.com/Valimail/arc_test_suite 1413 [5] mailto:arc-discuss@dmarc.org 1415 [6] https://trac.ietf.org/trac/dmarc/ticket/17 1417 [7] mailto:dmarc@ietf.org 1419 [8] mailto:arc-discuss@dmarc.org 1421 Appendix A. Appendix A - Design Requirements 1423 (This section is re-inserted for background information from 1424 [ARC-DRAFT-06] and earlier versions.) 1426 The specification of the ARC framework is driven by the following 1427 high-level goals, security considerations, and practical operational 1428 requirements. 1430 A.1. Primary Design Criteria 1432 o Provide a verifiable "chain of custody" for email messages; 1434 o Not require changes for originators of email; 1436 o Support the verification of the ARC header field set by each hop 1437 in the handling chain; 1439 o Work at Internet scale; and 1441 o Provide a trustable mechanism for the communication of 1442 Authentication-Results across trust boundaries. 1444 A.2. Out of Scope 1446 ARC is not a trust framework. Users of the ARC header fields are 1447 cautioned against making unsubstantiated conclusions when 1448 encountering a "broken" ARC sequence. 1450 Appendix B. Appendix B - Example Usage 1452 [[ Note: The following examples were mocked up early in the 1453 definition process for the spec. They no longer reflect the current 1454 definition and need various updates which will be included in a 1455 future draft. Issue 17 [6] ]] 1457 (Obsolete but retained for illustrative purposes) 1459 B.1. Example 1: Simple mailing list 1461 B.1.1. Here's the message as it exits the Origin: 1463 Return-Path: 1464 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 1465 (authenticated bits=0) 1466 by segv.d1.example with ESMTP id t0FN4a8O084569; 1467 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 1468 (envelope-from jqd@d1.example) 1469 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; 1470 s=20130426; t=1421363082; 1471 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 1472 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: 1473 Content-Transfer-Encoding; 1474 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw 1475 bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl 1476 gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 1477 Message-ID: <54B84785.1060301@d1.example> 1478 Date: Thu, 14 Jan 2015 15:00:01 -0800 1479 From: John Q Doe 1480 To: arc@dmarc.org 1481 Subject: Example 1 1483 Hey gang, 1484 This is a test message. 1485 --J. 1487 B.1.2. Message is then received at example.org 1489 B.1.2.1. Example 1, Step A: Message forwarded to list members 1491 Processing at example.org: 1493 o example.org performs authentication checks 1495 o No previous Authentication-Results or ARC-Seal headers are present 1497 o example.org adds ARC-Authentication-Results header 1499 o example.org adds Received: header 1501 o example.org adds a ARC-Seal header 1503 Here's the message as it exits example.org: 1505 Return-Path: 1506 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 1507 s=seal2015; d=example.org; cv=none; 1508 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 1509 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 1510 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 1511 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; 1512 d=example.org; s=clochette; t=1421363105; 1513 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; 1514 h=List-Id:List-Unsubscribe:List-Archive:List-Post: 1515 List-Help:List-Subscribe:Reply-To:DKIM-Signature; 1516 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1F5 1517 vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+m4bw 1518 a6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= 1519 Received: from segv.d1.example (segv.d1.example [72.52.75.15]) 1520 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 1521 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) 1522 (envelope-from jqd@d1.example) 1523 ARC-Authentication-Results: i=1; lists.example.org; 1524 spf=pass smtp.mfrom=jqd@d1.example; 1525 dkim=pass (1024-bit key) header.i=@d1.example; 1526 dmarc=pass 1527 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 1528 (authenticated bits=0) 1529 by segv.d1.example with ESMTP id t0FN4a8O084569; 1530 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 1531 (envelope-from jqd@d1.example) 1532 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; 1533 s=20130426; t=1421363082; 1534 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 1535 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: 1536 Content-Transfer-Encoding; 1537 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr 1538 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G 1539 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 1540 Message-ID: <54B84785.1060301@d1.example> 1541 Date: Thu, 14 Jan 2015 15:00:01 -0800 1542 From: John Q Doe 1543 To: arc@example.org 1544 Subject: [Lists] Example 1 1546 Hey gang, 1547 This is a test message. 1548 --J. 1550 B.1.3. Example 1: Message received by Recipient 1552 Let's say that the Recipient is example.com 1554 Processing at example.com: 1556 o example.com performs usual authentication checks 1558 o example.com adds Authentication-Results: header, Received header 1560 o Determines that message fails DMARC 1562 o Checks for ARC-Seal: header; finds one 1564 o Validates the signature in the ARC-Seal: header, which covers the 1565 ARC-Authentication-Results: header 1567 o example.com can use the ARC-Authentication-Results values or 1568 verify the DKIM-Signature from lists.example.org 1570 Here's what the message looks like at this point: 1572 Return-Path: 1573 Received: from example.org (example.org [208.69.40.157]) 1574 by clothilde.example.com with ESMTP id 1575 d200mr22663000ykb.93.1421363207 1576 for ; Thu, 14 Jan 2015 15:02:40 -0800 (PST) 1577 Authentication-Results: clothilde.example.com; spf=fail 1578 smtp.from=jqd@d1.example; dkim=pass (1024-bit key) 1579 header.i=@example.org; dmarc=fail; arc=pass 1580 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 1581 s=seal2015; d=example.org; cv=none; 1582 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 1583 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 1584 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 1585 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; 1586 d=example.org; s=clochette; t=1421363105; 1587 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; 1588 h=List-Id:List-Unsubscribe:List-Archive:List-Post: 1589 List-Help:List-Subscribe:Reply-To:DKIM-Signature; 1590 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF 1591 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3 1592 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= 1593 Received: from segv.d1.example (segv.d1.example [72.52.75.15]) 1594 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 1595 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) 1596 (envelope-from jqd@d1.example) 1597 ARC-Authentication-Results: i=1; lists.example.org; 1598 spf=pass smtp.mfrom=jqd@d1.example; 1599 dkim=pass (1024-bit key) header.i=@d1.example; 1600 dmarc=pass 1601 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 1602 (authenticated bits=0) 1603 by segv.d1.example with ESMTP id t0FN4a8O084569; 1604 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 1605 (envelope-from jqd@d1.example) 1606 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; 1607 s=20130426; t=1421363082; 1608 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 1609 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: 1610 Content-Transfer-Encoding; 1611 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw 1612 bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl 1613 gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 1614 Message-ID: <54B84785.1060301@d1.example> 1615 Date: Thu, 14 Jan 2015 15:00:01 -0800 1616 From: John Q Doe 1617 To: arc@example.org 1618 Subject: [Lists] Example 1 1620 Hey gang, 1621 This is a test message. 1622 --J. 1624 B.2. Example 2: Mailing list to forwarded mailbox 1626 B.2.1. Here's the message as it exits the Origin: 1628 Return-Path: 1629 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 1630 (authenticated bits=0) 1631 by segv.d1.example with ESMTP id t0FN4a8O084569; 1632 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 1633 (envelope-from jqd@d1.example) 1634 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; 1635 s=20130426; t=1421363082; 1636 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 1637 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: 1638 Content-Transfer-Encoding; 1639 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw 1640 bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl 1641 gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 1642 Message-ID: <54B84785.1060301@d1.example> 1643 Date: Thu, 14 Jan 2015 15:00:01 -0800 1644 From: John Q Doe 1645 To: arc@example.org 1646 Subject: Example 1 1648 Hey gang, 1649 This is a test message. 1650 --J. 1652 B.2.2. Message is then received at example.org 1654 B.2.2.1. Example 2, Step A: Message forwarded to list members 1656 Processing at example.org: 1658 o example.org performs authentication checks 1660 o example.org applies standard DKIM signature 1662 o No previous Authentication-Results or ARC-Seal headers are present 1664 o example.org adds ARC-Authentication-Results header 1666 o example.org adds usual Received: header 1668 o example.org adds a ARC-Seal header 1670 Here's the message as it exits Step A: 1672 Return-Path: 1673 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 1674 s=seal2015; d=example.org; cv=none; 1675 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6 1676 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L 1677 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 1678 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; 1679 d=example.org; s=clochette; t=1421363105; 1680 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; 1681 h=List-Id:List-Unsubscribe:List-Archive:List-Post: 1682 List-Help:List-Subscribe:Reply-To:DKIM-Signature; 1683 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF 1684 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3 1685 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= 1686 Received: from segv.d1.example (segv.d1.example [72.52.75.15]) 1687 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 1688 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) 1689 (envelope-from jqd@d1.example) 1690 ARC-Authentication-Results: i=1; lists.example.org; 1691 spf=pass smtp.mfrom=jqd@d1.example; 1692 dkim=pass (1024-bit key) header.i=@d1.example; 1693 dmarc=pass 1694 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 1695 (authenticated bits=0) 1696 by segv.d1.example with ESMTP id t0FN4a8O084569; 1697 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 1698 (envelope-from jqd@d1.example) 1699 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; 1700 s=20130426; t=1421363082; 1701 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 1702 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: 1703 Content-Transfer-Encoding; 1704 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr 1705 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G 1706 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 1707 Message-ID: <54B84785.1060301@d1.example> 1708 Date: Thu, 14 Jan 2015 15:00:01 -0800 1709 From: John Q Doe 1710 To: arc@example.org 1711 Subject: [Lists] Example 1 1713 Hey gang, 1714 This is a test message. 1715 --J. 1717 B.2.2.2. Example 2, Step B: Message from list forwarded 1719 The message is delivered to a mailbox at gmail.com 1720 Processing at gmail.com: 1722 o gmail.com performs usual authentication checks 1724 o gmail.com adds Authentication-Results: and Received: header 1726 o Determines that message fails DMARC 1728 o Checks for ARC-Seal: header; finds one 1730 o Validates the signature in the ARC-Seal: header, which covers the 1731 ARC-Authentication-Results: header 1733 o Uses the ARC-Authentication-Results: values, but: 1735 o Instead of delivering message, prepares to forward message per 1736 user settings 1738 o Applies usual DKIM signature 1740 o gmail.com adds it's own ARC-Seal: header, contents of which are 1742 * version 1744 * sequence number ("i=2") 1746 * hash algorithm (SHA256 as example) 1748 * timestamp ("t=") 1750 * selector for key ("s=notary01") 1752 * domain for key ("d=gmail.com") 1754 * headers included in hash ("h=ARC-Authentication-Results:ARC- 1755 Seal") 1757 * Note: algorithm requires only ARC-Seals with lower sequence # 1758 be included, in ascending order 1760 * signature of the header hash 1762 Here's what the message looks like at this point: 1764 Return-Path: 1765 ARC-Seal: i=2; a=rsa-sha256; t=1421363253; 1766 s=notary01; d=gmail.com; cv=pass; 1767 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDWR 1768 YbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/sut 1769 txO+RRNr0fCFw== 1770 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; 1771 d=gmail.com; s=20120806; 1772 h=mime-version:content-type:x-original-sender: 1773 x-original-authentication-results:precedence:mailing-list: 1774 list-id:list-post:list-help:list-archive:sender:reply-to: 1775 list-unsubscribe:DKIM-Signature; 1776 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=; 1777 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 1778 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 1779 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBmfhS 1780 LF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJRFeM 1781 KdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwDBJtXw 1782 bQoZyRtb6X6q0mYaszUB8kw== 1783 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10 1784 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST) 1785 Authentication-Results: i=2; gmail.com; spf=fail 1786 smtp.from=jqd@d1.example; dkim=pass (1024-bit key) 1787 header.i=@example.org; dmarc=fail; arc=pass 1788 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 1789 s=seal2015; d=example.org; cv=none: 1790 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 1791 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 1792 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 1793 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; 1794 d=example.org; s=clochette; t=1421363105; 1795 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; 1796 h=List-Id:List-Unsubscribe:List-Archive:List-Post: 1797 List-Help:List-Subscribe:Reply-To:DKIM-Signature; 1798 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF 1799 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3 1800 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= 1801 Received: from segv.d1.example (segv.d1.example [72.52.75.15]) 1802 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 1803 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) 1804 (envelope-from jqd@d1.example) 1805 ARC-Authentication-Results: i=1; lists.example.org; 1806 spf=pass smtp.mfrom=jqd@d1.example; 1807 dkim=pass (1024-bit key) header.i=@d1.example; 1808 dmarc=pass 1809 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 1810 (authenticated bits=0) 1811 by segv.d1.example with ESMTP id t0FN4a8O084569; 1812 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 1813 (envelope-from jqd@d1.example) 1814 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; 1815 s=20130426; t=1421363082; 1816 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 1817 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: 1818 Content-Transfer-Encoding; 1819 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr 1820 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G 1821 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 1822 Message-ID: <54B84785.1060301@d1.example> 1823 Date: Thu, 14 Jan 2015 15:00:01 -0800 1824 From: John Q Doe 1825 To: arc@example.org 1826 Subject: [Lists] Example 1 1828 Hey gang, 1829 This is a test message. 1830 --J. 1832 B.2.3. Example 2: Message received by Recipient 1834 Let's say that the Recipient is example.com 1835 Processing at example.com: 1837 o example.com performs usual authentication checks 1839 o example.com adds Authentication-Results: header, Received header 1841 o Determines that message fails DMARC 1843 o Checks for ARC-Seal: header; finds two 1845 o Validates the signature in the highest numbered ("i=2") ARC-Seal: 1846 header, which covers all previous ARC-Seal: and ARC- 1847 Authentication-Results: headers 1849 o Validates the other ARC-Seal header ("i=1"), which covers the ARC- 1850 Authentication-Results: header 1852 o example.com uses the ARC-Authentication-Results: values 1854 Here's what the message looks like at this point: 1856 Return-Path: 1857 Received: from mail-ob0-f188.google.com (mail-ob0-f188.google.com 1858 [208.69.40.157]) by clothilde.example.com with ESMTP id 1859 d200mr22663000ykb.93.1421363268 1860 for ; Thu, 14 Jan 2015 15:03:15 -0800 (PST) 1862 Authentication-Results: clothilde.example.com; spf=fail 1863 smtp.from=jqd@d1.example; dkim=pass (1024-bit key) 1864 header.i=@gmail.com; dmarc=fail; arc=pass 1865 ARC-Seal: i=2; a=rsa-sha256; t=1421363253; 1866 s=notary01; d=gmail.com; cv=pass; 1867 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDWR 1868 YbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/sut 1869 txO+RRNr0fCFw== 1870 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; 1871 d=gmail.com; s=20120806; 1872 h=mime-version:content-type:x-original-sender: 1873 x-original-authentication-results:precedence:mailing-list: 1874 list-id:list-post:list-help:list-archive:sender:reply-to: 1875 :list-unsubscribe:DKIM-Signature; 1876 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=; 1877 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 1878 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 1879 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBmfhS 1880 LF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJRFeM 1881 KdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwDBJtXw 1882 bQoZyRtb6X6q0mYaszUB8kw== 1883 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10 1884 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST) 1885 Authentication-Results: i=2; gmail.com; spf=fail 1886 smtp.from=jqd@d1.example; dkim=pass (1024-bit key) 1887 header.i=@example.org; dmarc=fail; arc=pass 1888 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 1889 s=seal2015; d=example.org; cv=none; 1890 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 1891 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 1892 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 1893 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; 1894 d=example.org; s=clochette; t=1421363105; 1895 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; 1896 h=List-Id:List-Unsubscribe:List-Archive:List-Post: 1897 List-Help:List-Subscribe:Reply-To:DKIM-Signature; 1898 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF 1899 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3 1900 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= 1901 Received: from segv.d1.example (segv.d1.example [72.52.75.15]) 1902 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 1903 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) 1904 (envelope-from jqd@d1.example) 1905 ARC-Authentication-Results: i=1; lists.example.org; 1906 spf=pass smtp.mfrom=jqd@d1.example; 1907 dkim=pass (1024-bit key) header.i=@d1.example; 1908 dmarc=pass 1909 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 1910 (authenticated bits=0) 1911 by segv.d1.example with ESMTP id t0FN4a8O084569; 1912 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 1913 (envelope-from jqd@d1.example) 1914 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; 1915 s=20130426; t=1421363082; 1916 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 1917 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: 1918 Content-Transfer-Encoding; 1919 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr 1920 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G 1921 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 1922 Message-ID: <54B84785.1060301@d1.example> 1923 Date: Thu, 14 Jan 2015 15:00:01 -0800 1924 From: John Q Doe 1925 To: arc@example.org 1926 Subject: [Lists] Example 1 1928 Hey gang, 1929 This is a test message. 1930 --J. 1932 B.3. Example 3: Mailing list to forwarded mailbox with source 1934 B.3.1. Here's the message as it exits the Origin: 1936 Return-Path: 1937 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 1938 (authenticated bits=0) 1939 by segv.d1.example with ESMTP id t0FN4a8O084569; 1940 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 1941 (envelope-from jqd@d1.example) 1942 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 1943 s=origin2015; d=d1.example; cv=none; 1944 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61T 1945 X6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69EU 1946 8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 1947 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; 1948 d=d1.example; s=20130426; t=1421363082; 1949 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 1950 h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding; 1951 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrv 1952 Qwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3 1953 TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 1954 Message-ID: <54B84785.1060301@d1.example> 1955 Date: Thu, 14 Jan 2015 15:00:01 -0800 1956 From: John Q Doe 1957 To: arc@example.org 1958 Subject: Example 1 1960 Hey gang, 1961 This is a test message. 1962 --J. 1964 B.3.2. Message is then received at example.org 1966 B.3.2.1. Example 3, Step A: Message forwarded to list members with 1967 source 1969 Processing at example.org: 1971 o example.org performs authentication checks 1973 o example.org applies standard DKIM signature 1975 o Checks for ARC-Seal: header; finds one (i=1) 1977 o Validates the signature in the ARC-Seal (i=1): header, which 1978 covers the d1.example ARC-Message-Signature: header 1980 o example.org adds ARC-Authentication-Results header 1982 o example.org adds usual Received: header 1983 o example.org adds a DKIM-Signature 1985 o example.org adds a ARC-Seal header, contents of which are 1987 * sequence number ("i=2") 1989 * hash algorithm (SHA256 as example) 1991 * timestamp ("t=") 1993 * chain validity ("cv=") 1995 * selector for key ("s=seal2015") 1997 * domain for key ("d=example.org") 1999 * signature ("b=") 2001 Here's the message as it exits Step A: 2003 Return-Path: 2004 ARC-Seal: i=2; a=rsa-sha256; t=1421363107; 2005 s=seal2015; d=example.org; cv=pass; 2006 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6 2007 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L 2008 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 2009 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; 2010 d=example.org; s=clochette; t=1421363105; 2011 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; 2012 h=List-Id:List-Unsubscribe:List-Archive:List-Post: 2013 List-Help:List-Subscribe:From:Reply-To:DKIM-Signature; 2014 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF 2015 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3 2016 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= 2017 Received: from segv.d1.example (segv.d1.example [72.52.75.15]) 2018 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 2019 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) 2020 (envelope-from jqd@d1.example) 2021 ARC-Authentication-Results: i=2; lists.example.org; 2022 spf=pass smtp.mfrom=jqd@d1.example; 2023 dkim=pass (1024-bit key) header.i=@d1.example; 2024 dmarc=pass 2025 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 2026 (authenticated bits=0) 2027 by segv.d1.example with ESMTP id t0FN4a8O084569; 2028 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 2029 (envelope-from jqd@d1.example) 2030 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 2031 s=origin2015; d=d1.example; cv=none; 2032 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 2033 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 2034 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 2035 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; 2036 d=d1.example; s=20130426; t=1421363082; 2037 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 2038 h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding; 2039 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr 2040 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G 2041 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 2042 Message-ID: <54B84785.1060301@d1.example> 2043 Date: Thu, 14 Jan 2015 15:00:01 -0800 2044 From: John Q Doe 2045 To: arc@example.org 2046 Subject: [Lists] Example 1 2048 Hey gang, 2049 This is a test message. 2050 --J. 2052 B.3.2.2. Example 3, Step B: Message from list forwarded with source 2054 The message is delivered to a mailbox at gmail.com 2055 Processing at gmail.com: 2057 o gmail.com performs usual authentication checks 2059 o gmail.com adds Authentication-Results: and Received: header 2061 o Determines that message fails DMARC 2063 o Checks for ARC-Seal: header; finds two 2065 o Validates the signature in the ARC-Seal (i=2): header, which 2066 covers the ARC-Authentication-Results: header 2068 o Validates the signature in the ARC-Seal (i=1): header, which 2069 covers the d1.example ARC-Message-Signature: header 2071 o Uses the ARC-Authentication-Results: values, but: 2073 o Instead of delivering message, prepares to forward message per 2074 user settings 2076 o Applies usual DKIM signature 2078 o gmail.com adds it's own ARC-Seal: header, contents of which are 2080 * version 2082 * sequence number ("i=2") 2084 * hash algorithm (SHA256 as example) 2086 * timestamp ("t=") 2088 * selector for key ("s=notary01") 2090 * domain for key ("d=gmail.com") 2092 * Note: algorithm requires only ARC-Seals with lower sequence # 2093 be included, in ascending order 2095 * signature of the chain 2097 Here's what the message looks like at this point: 2099 Return-Path: 2100 ARC-Seal: i=3; a=rsa-sha256; t=1421363253; 2101 s=notary01; d=gmail.com; cv=pass; 2102 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwD 2103 WRYbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF 2104 /suttxO+RRNr0fCFw== 2105 ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed; 2106 d=gmail.com; s=20120806; 2107 h=mime-version:content-type:x-original-sender 2108 :x-original-authentication-results:precedence:mailing-list 2109 :list-id:list-post:list-help:list-archive:sender 2110 :list-unsubscribe:reply-to; 2111 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=; 2112 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6 2113 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L 2114 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBm 2115 fhSLF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJ 2116 RFeMKdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwD 2117 BJtXwbQoZyRtb6X6q0mYaszUB8kw== 2118 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10 2119 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST) 2120 Authentication-Results: i=3; gmail.com; spf=fail 2121 smtp.from=jqd@d1.example; dkim=pass (1024-bit key) 2122 header.i=@example.org; dmarc=fail; arc=pass 2123 ARC-Seal: i=2; a=rsa-sha256; t=1421363107; 2124 s=seal2015; d=example.org; cv=pass; 2125 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 2126 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 2127 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 2128 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; 2129 d=example.org; s=clochette; t=1421363105; 2130 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; 2131 h=List-Id:List-Unsubscribe:List-Archive:List-Post: 2132 List-Help:List-Subscribe:Reply-To:DKIM-Signature; 2133 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1 2134 F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+ 2135 m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= 2136 Received: from segv.d1.example (segv.d1.example [72.52.75.15]) 2137 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 2138 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) 2139 (envelope-from jqd@d1.example) 2140 ARC-Authentication-Results: i=2; lists.example.org; 2141 spf=pass smtp.mfrom=jqd@d1.example; 2142 dkim=pass (1024-bit key) header.i=@d1.example; 2143 dmarc=pass 2144 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 2145 (authenticated bits=0) 2146 by segv.d1.example with ESMTP id t0FN4a8O084569; 2147 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 2148 (envelope-from jqd@d1.example) 2149 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 2150 s=origin2015; d=d1.example; cv=none; 2151 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 2152 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 2153 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 2154 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; 2155 d=d1.example; s=20130426; t=1421363082; 2156 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 2157 h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding; 2158 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYij 2159 rvQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD 2160 4Gd3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 2161 Message-ID: <54B84785.1060301@d1.example> 2162 Date: Thu, 14 Jan 2015 15:00:01 -0800 2163 From: John Q Doe 2164 To: arc@example.org 2165 Subject: [Lists] Example 1 2167 Hey gang, 2168 This is a test message. 2169 --J. 2171 B.3.3. Example 3: Message received by Recipient 2173 Let's say that the Recipient is example.com 2174 Processing at example.com: 2176 o example.com performs usual authentication checks 2178 o example.com adds Authentication-Results: header, Received header 2180 o Determines that message fails DMARC 2182 o Checks for ARC-Seal: header; finds three 2184 o Validates the signature in the highest numbered ("i=2") ARC-Seal: 2185 header, which covers all previous ARC-Seal: and ARC- 2186 Authentication-Results: headers 2188 o Validates the other ARC-Seal header ("i=2"), which covers the ARC- 2189 Authentication-Results: header 2191 o Validates the other ARC-Seal header ("i=1"), which covers the 2192 d1.example ARC-Message-Signature: header 2194 o example.com uses the ARC-Authentication-Results: values 2195 Here's what the message looks like at this point: 2197 Return-Path: 2198 Received: from mail-ob0-f188.google.com (mail-ob0-f188.google.com 2199 [208.69.40.157]) by clothilde.example.com with ESMTP id 2200 d200mr22663000ykb.93.1421363268 2201 for ; Thu, 14 Jan 2015 15:03:15 -0800 (PST) 2202 Authentication-Results: clothilde.example.com; spf=fail 2203 smtp.from=jqd@d1.example; dkim=pass (1024-bit key) 2204 header.i=@gmail.com; dmarc=fail; arc=pass 2205 ARC-Seal: i=3; a=rsa-sha256; t=1421363253; 2206 s=notary01; d=gmail.com; cv=pass; 2207 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDW 2208 RYbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/s 2209 uttxO+RRNr0fCFw== 2210 ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed; 2211 d=gmail.com; s=20120806; 2212 h=mime-version:content-type:x-original-sender 2213 :x-original-authentication-results:precedence 2214 :mailing-list:list-id:list-post:list-help:list-archive:sender 2215 :list-unsubscribe:reply-to; 2216 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=; 2217 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6 2218 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L 2219 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBm 2220 fhSLF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJ 2221 RFeMKdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwD 2222 BJtXwbQoZyRtb6X6q0mYaszUB8kw== 2223 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10 2224 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST) 2225 Authentication-Results: i=3; gmail.com; spf=fail 2226 smtp.from=jqd@d1.example; dkim=pass (1024-bit key) 2227 header.i=@example.org; dmarc=fail; arc=pass 2228 ARC-Seal: i=2; a=rsa-sha256; t=1421363107; 2229 s=seal2015; d=example.org; cv=pass; 2230 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6 2231 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L 2232 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 2233 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; 2234 d=example.org; s=clochette; t=1421363105; 2235 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; 2236 h=List-Id:List-Unsubscribe:List-Archive:List-Post: 2237 List-Help:List-Subscribe:Reply-To:DKIM-Signature; 2238 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1 2239 F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+ 2240 m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= 2241 Received: from segv.d1.example (segv.d1.example [72.52.75.15]) 2242 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 2243 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) 2244 (envelope-from jqd@d1.example) 2245 ARC-Authentication-Results: i=2; lists.example.org; 2246 spf=pass smtp.mfrom=jqd@d1.example; 2247 dkim=pass (1024-bit key) header.i=@d1.example; 2248 dmarc=pass 2249 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 2250 (authenticated bits=0) 2251 by segv.d1.example with ESMTP id t0FN4a8O084569; 2252 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 2253 (envelope-from jqd@d1.example) 2254 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 2255 s=origin2015; d=d1.example; cv=none; 2256 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 2257 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 2258 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 2259 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; 2260 d=d1.example; s=20130426; t=1421363082; 2261 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 2262 h=MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding; 2263 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr 2264 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G 2265 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 2266 Message-ID: <54B84785.1060301@d1.example> 2267 Date: Thu, 14 Jan 2015 15:00:01 -0800 2268 From: John Q Doe 2269 To: arc@example.org 2270 Subject: [Lists] Example 1 2272 Hey gang, 2273 This is a test message. 2274 --J. 2276 Appendix C. Acknowledgements 2278 This draft originated with the work of OAR-Dev Group. 2280 The authors thank all of the OAR-Dev group for the ongoing help and 2281 though-provoking discussions from all the participants, especially: 2282 Alex Brotman, Brandon Long, Dave Crocker, Elizabeth Zwicky, Franck 2283 Martin, Greg Colburn, J. Trent Adams, John Rae-Grant, Mike Hammer, 2284 Mike Jones, Steve Jones, Terry Zink, Tim Draegen. 2286 Grateful appreciation is extended to the people who provided feedback 2287 through the discuss mailing list. 2289 Appendix D. Comments and Feedback 2291 Please address all comments, discussions, and questions to 2292 dmarc@ietf.org [7]. Earlier discussions can be found at arc- 2293 discuss@dmarc.org [8]. 2295 Authors' Addresses 2297 Kurt Andersen 2298 LinkedIn 2299 1000 West Maude Ave 2300 Sunnyvale, California 94085 2301 USA 2303 Email: kurta@linkedin.com 2305 Brandon Long (editor) 2306 Google 2308 Email: blong@google.com 2310 Steven Jones (editor) 2311 TDP 2313 Email: smj@crash.com 2315 Seth Blank (editor) 2316 Valimail 2318 Email: seth@valimail.com 2320 Murray Kucherawy (editor) 2321 TDP 2323 Email: superuser@gmail.com