idnits 2.17.1 draft-andersen-arc-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: ARC-Seal headers MUST not be included in the signing scope of any ARC-Message-Signature headers. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The ARC-Message-Signature header field MUST be created using the relaxed header canonicalization rules [RFC6376]. The "c=" field MUST not be included in the ARC-Message-Signature. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Any DKIM-Signatures SHOULD not include any of the ARC-Seal, ARC-Message-Signature, or ARC-Authentication-Results header fields in the scope of their header list. -- The document date (April 04, 2016) is 2938 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.ARC' is mentioned on line 653, but not defined -- Looks like a reference, but probably isn't: '1' on line 1630 == Missing Reference: '-03' is mentioned on line 796, but not defined == Missing Reference: 'Lists' is mentioned on line 1608, but not defined == Unused Reference: 'RFC2142' is defined on line 693, but no explicit reference was found in the text == Unused Reference: 'RFC2606' is defined on line 697, but no explicit reference was found in the text == Unused Reference: 'RFC4686' is defined on line 705, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 709, but no explicit reference was found in the text == Unused Reference: 'RFC5585' is defined on line 727, but no explicit reference was found in the text == Unused Reference: 'RFC5863' is defined on line 736, but no explicit reference was found in the text == Unused Reference: 'RFC6377' is defined on line 747, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 7601 (Obsoleted by RFC 8601) Summary: 2 errors (**), 0 flaws (~~), 14 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 independent . OAR-DEV Group 3 Internet-Draft OAR-DEV Group 4 Intended status: Informational K. Andersen 5 Expires: October 6, 2016 LinkedIn 6 J. Rae-Grant, Ed. 7 B. Long, Ed. 8 Google 9 T. Adams, Ed. 10 Paypal 11 S. Jones, Ed. 12 TDP 13 April 04, 2016 15 Authenticated Received Chain (ARC) 16 draft-andersen-arc-03 18 Abstract 20 Authenticated Received Chain (ARC) permits an organization which is 21 creating or handling email to indicate their involvement with the 22 handling process by adding a set of cryptographically signed header 23 fields in a manner analagous to that of DomainKeys Identified Mail 24 (DKIM). Assertion of responsibility is validated through a 25 cryptographic signature and by querying the Signer's domain directly 26 to retrieve the appropriate public key. Changes in the message which 27 may break DKIM, may be tracked through the ARC set of 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 http://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 6, 2016. 46 Copyright Notice 48 Copyright (c) 2016 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 (http://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 This document may not be modified, and derivative works of it may not 62 be created, and it may not be published except as an Internet-Draft. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 4 69 2.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 4 70 2.3. Utility . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 5. Definition . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 5.1. Description of the new header fields . . . . . . . . . . 6 75 5.1.1. ARC-Seal . . . . . . . . . . . . . . . . . . . . . . 6 76 5.1.2. ARC-Message-Signature . . . . . . . . . . . . . . . . 8 77 5.1.3. ARC-Authentication-Results . . . . . . . . . . . . . 9 78 5.2. Constructing the ARC-Seal Header Set . . . . . . . . . . 10 79 5.2.1. Handling Violations in the ARC Header Field Set . . . 10 80 5.3. Key Management and Binding . . . . . . . . . . . . . . . 11 81 5.3.1. Namespace . . . . . . . . . . . . . . . . . . . . . . 11 82 6. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 6.1. Participation . . . . . . . . . . . . . . . . . . . . . . 11 84 6.2. Relationship between DKIM Signatures and ARC Headers . . 12 85 6.3. Relationship of ARC-Message-Signatures and ARC-Seals . . 12 86 6.4. Validating the ARC set of header fields . . . . . . . . . 12 87 6.5. Assessing violations of ARC set validity . . . . . . . . 12 88 6.6. Reporting violations of ARC set validity . . . . . . . . 13 89 6.7. Recording results of ARC evaluation . . . . . . . . . . . 13 90 6.7.1. RFC6651 Failure Reporting for ARC . . . . . . . . . . 13 91 6.7.2. Reporting ARC Effects for DMARC Local Policy . . . . 13 92 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 93 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 94 8.1. Update to RFC7601 header field method list . . . . . . . 14 95 8.2. Definitions of the ARC header fields . . . . . . . . . . 14 96 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 97 9.1. Preventing Repurposing of ARC Headers . . . . . . . . . . 15 98 9.2. Messages Which Transit the Same ADMD More Than Once . . . 15 99 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 100 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 101 10.2. Informative References . . . . . . . . . . . . . . . . . 17 102 Appendix A. Appendix A - Example Usage . . . . . . . . . . . . . 18 103 A.1. Example 1: Simple mailing list . . . . . . . . . . . . . 18 104 A.1.1. Here's the message as it exits the Origin: . . . . . 18 105 A.1.2. Message is then received at example.org . . . . . . . 18 106 A.1.3. Example 1: Message received by Recipient . . . . . . 20 107 A.2. Example 2: Mailing list to forwarded mailbox . . . . . . 21 108 A.2.1. Here's the message as it exits the Origin: . . . . . 21 109 A.2.2. Message is then received at example.org . . . . . . . 22 110 A.2.3. Example 2: Message received by Recipient . . . . . . 26 111 A.3. Example 3: Mailing list to forwarded mailbox with source 28 112 A.3.1. Here's the message as it exits the Origin: . . . . . 28 113 A.3.2. Message is then received at example.org . . . . . . . 29 114 A.3.3. Example 3: Message received by Recipient . . . . . . 34 115 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 36 116 Appendix C. Comments and Feedback . . . . . . . . . . . . . . . 37 117 Appendix D. Historical Note . . . . . . . . . . . . . . . . . . 37 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 120 1. Introduction 122 The development of strong domain authentication through SPF and DKIM 123 has led to the implementation of the DMARC framework [RFC7489]. 124 Implicit within the DMARC framework is a requirement that any 125 intermediaries between the source system and ultimate receiver system 126 must preserve the validity of the DKIM signature; however, there are 127 common email practices which break the DKIM validation 128 ([DMARC-INTEROP]). This proposal is intended to define an 129 Authenticated Received Chain (ARC) to address the problems with the 130 untrustworthiness of the standard Received header field sequence so 131 that receivers can develop a more nuanced interpretation to guide any 132 local policies related to messages which arrive with broken domain 133 authentication. 135 Forgery of the Received header fields is a common tactic for bad 136 actors. One of the goals of this proposal is to define a comparable 137 set of trace header fields which can be relied upon by receivers in 138 so far as all ADMD (ADministrative Management Domain) handlers of a 139 message participate in the ARC chain. 141 The Authentication-Results (A-R) mechanism [RFC7601] permits the 142 output of an email authentication evaluation process to be 143 transmitted from the evaluating host to a consuming host that uses 144 the information. On its own, A-R operates within a trust domain. 145 ARC provides a protection mechanism for the data, permiting the 146 communication to cross trust domain boundaries. 148 2. Requirements 150 The specification of the ARC framework is driven by the following 151 high-level goals, security considerations, and practical operational 152 requirements. 154 2.1. Primary Design Criteria 156 o Provide a method by which a "chain of custody" can be documented 157 for email messages 159 o Not require changes for senders of email 161 o Support the complete verification of the ARC header field set by 162 each hop in the handling chain 164 o Work at internet scale 166 o Provide a trustable mechanism for the communication of 167 Authentication-Results across trust boundaries. 169 2.2. Out of Scope 171 ARC is not a trust framework. Users of the ARC header fields are 172 cautioned against making unsubstantiated conclusions when 173 encountering a "broken" ARC sequence. 175 2.3. Utility 177 The ARC-related set of header fields can be used (when validated) to 178 determine the path that an email message has taken between the 179 sending system and receiver. Subject to the cautions mentioned below 180 under Section 9, this information can assist in determining any local 181 policy overrides to for violations of sender domain authentication 182 policies. 184 3. Terminology 186 This section defines terms used in the rest of the document. 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 190 document are to be interpreted as described in [RFC2119]. 192 Readers are encouraged to be familiar with the contents of [RFC5598], 193 and in particular, the potential roles of intermediaries in the 194 delivery of email. 196 Syntax descriptions use Augmented BNF (ABNF) [RFC5234]. 198 4. Overview 200 When an email is received without a properly valildated domain 201 author, the inability to believe the accuracy of a series of Received 202 header fields prevents receiving systems from having a way to infer 203 anything about the handling of the message by looking at the ADMD's 204 through which the message has traveled. 206 With the implementation of this proposal, participating ADMDs would 207 be able to securely register their handling of an email message. If 208 all intermediaries participate in the ARC process, then receivers 209 will be able to rely upon the chain and make local policy decisions 210 informed by that information. 212 The ARC set of header fields provides a method by which participating 213 intermediaries can indicate the hand-offs for email messages. 215 5. Definition 217 This proposal defines three new header fields: 219 o Header field name: ARC-Seal (abbreviated below as AS) 221 o Header field name: ARC-Message-Signature (abbreviated below as 222 AMS) 224 o Header field name: ARC-Authentication-Results (abbreviated below 225 as AAR) 227 Collectively, these header fields form a connected set of attribution 228 information by which receivers can identify the handling path for a 229 message. The collective group is referred to in this document as the 230 "ARC header [field]s" or "set of ARC header [field]s". 232 Specific references to individual header fields use the header field 233 names to distinguish such references. 235 The ARC header sets SHOULD be added at the top of a message as it 236 transits MTAs that do authentication checks, so some idea of how far 237 away the checks were done can be inferred. They are therefore 238 considered to be a trace field as defined in [RFC5321], and all of 239 the related definitions in that document apply. 241 Relative ordering of different trace header fields (the ARC sets, 242 DKIM, Received, etc.) is unimportant for this specification. In 243 general, trace header fields, such as ARC, SHOULD be added at the top 244 of the email header fields, but receivers MUST be able to process the 245 header fields from wherever they are found in the message header. 246 Ordering amongst the individual ARC header fields and header field 247 sets is specified below and MUST be followed for proper canonicalized 248 signing and evaluation. 250 5.1. Description of the new header fields 252 5.1.1. ARC-Seal 254 ARC-Seal is a Structured Header Field as defined in Internet Message 255 Format ([RFC5322]). All of the related definitions in that document 256 apply. 258 The ARC-Seal makes use of the "tag=value" construction as defined in 259 [RFC6376], section 3.2. 261 The value of the header field consists of an authentication 262 identifier, and a series of statements and supporting data. The 263 statements are of the form "tag=value" and indicate relevant data 264 about the signing of the ARC set of header fields. The header field 265 can appear more than once in a single message, but each instance must 266 have a unique "i=" value. 268 The ARC-Seal header field only signs across the (earlier) ARC-Seal, 269 (and all) ARC-Message-Signature, and ARC-Authentication-Results 270 header fields. 272 5.1.1.1. Tags in the ARC-Seal header field value 274 5.1.1.1.1. Mandatory 276 o i = instance or sequence number; monotonically increasing at each 277 "sealing" entity beginning with '1' 279 o a = hash algorithm (SHA256 as example) (as per [RFC6376] "a" tag) 281 o t = timestamp (seconds since Unix epoch) (as per [RFC6376] "t" 282 tag) 284 o s = Selector for key ("s=seal2015") (as per [RFC6376] "s" tag) 286 o d = domain for key ("d=example.com") (as per [RFC6376] "d" tag) 288 o b = signature of the header field hash (as per [RFC6376] "b" tag) 290 o cv = chain validation status: values = 292 * 'V' = valid chain received; 294 * 'N' = no pre-existing chain; 296 * 'P' = permanent error, the chain as received does not validate; 298 * 'T' = temporary error, such as a DNS lookup error 300 5.1.1.2. Differences between DKIM-Signature and ARC-Seal 302 No 'bh' value is defined for ARC-Seal. 304 ARC-Seal does not use the 'h' list of header fields that is defined 305 for DKIM-Signatures because the list of applicable header fields is 306 fully determined by the construction rules (see Section 5.2). 308 ARC-Seal does not use the 'c' (canonicalization) tag because only 309 'relaxed' canonicalization [RFC6376] is allowed for ARC-Seal header 310 field canonicalization. 312 5.1.1.3. Implicit 'h' Value for ARC-Seal 314 5.1.1.3.1. First instance 316 The ARC-Seal's (AS(1)) effective "h" scope would be 317 AAR(1):AMS(1):AS(1-no-b). 319 5.1.1.3.2. Second instance 321 The ARC-Seal's (AS(2)) effective "h" scope would be 322 AAR(1):AMS(1):AS(1):AAR(2):AMS(2):AS(2-no-b). 324 5.1.1.3.3. Third instance 326 The ARC-Seal's (AS(3)) effective "h" scope would be 327 AAR(1):AMS(1):AS(1):AAR(2):AMS(2):AS(2):AAR(3):AMS(3):AS(3-no-b). 329 5.1.1.4. Computing the 'b' signature value for ARC-Seal 331 The ARC-Seal instance with an empty 'b' field shall be affixed when 332 computing the signature and the 'b' value added afterward just as in 333 the procedure for DKIM-Signature calculations (section 3.5 of 334 [RFC6376]). 336 Signing calculation MUST be done in bottom-up order as specified in 337 section 5.4.2 of [RFC6376] and as illustrated above Section 5.1.1.3. 339 5.1.2. ARC-Message-Signature 341 The ARC-Message-Signature header field is a special variant of a 342 DKIM-Signature [RFC6376], using only the relaxed header 343 canonicalization rules specified in [RFC6376]. 345 The ARC-Message-Signature header field can appear multiple times in a 346 single message but each instance must have a unique "i=" value. 348 5.1.2.1. Differences between DKIM-Signature and ARC-Message-Signature 350 5.1.2.1.1. 'h' value 352 [[ Note: As of -03, the concept of implicit headers included in the 353 signature is eliminated. ]] 355 5.1.2.1.1.1. Header Fields Excluded From ARC-Message-Signature 'h' 357 ARC-Seal headers MUST not be included in the signing scope of any 358 ARC-Message-Signature headers. 360 5.1.2.1.1.2. Header Fields Eligible For ARC-Message-Signature 'h' 362 Participants may include any other header fields within the scope of 363 the ARC-Message-Signature signature except ARC-Seal headers. In 364 particular, all DKIM-Signature header fields are highly recommended 365 to be included. The advice regarding headers to avoid is found in 366 section 5.4 of [RFC6376] and should be observed for ARC-Message- 367 Signatures just as they are for DKIM-Signature exclusion. ARC- 368 Authentication-Results SHOULD be included explicitly within the scope 369 of ARC-Message-Signature headers. 371 5.1.2.1.2. Implicit Canonicalization: 'c' 373 The ARC-Message-Signature header field MUST be created using the 374 relaxed header canonicalization rules [RFC6376]. The "c=" field MUST 375 not be included in the ARC-Message-Signature. 377 5.1.2.1.3. 'i' value 379 For the ARC-Message-Signature, the 'i' value is the corresponding 380 instance which matches the 'i' value of the related ARC-Seal (see 381 Section 5.1.1.1.1). 383 5.1.2.1.4. 'v' 385 'v' is not defined for an ARC-Message-Signature and is not allowed. 387 5.1.2.2. Computing the 'b' value for ARC-Message-Signature 389 The ARC-Message-Signature instance with an empty 'b' field shall be 390 affixed when computing the signature and the 'b' value added 391 afterward just as in the procedure for DKIM-Signature calculations 392 (section 3.5 of [RFC6376]). 394 Header signing MUST be done in bottom-up order as specified in 395 section 5.4.2 of [RFC6376]. 397 5.1.3. ARC-Authentication-Results 399 ARC-Authentication-Results is a direct copy of the Authentication- 400 Results header field [RFC7601] created for archival purposes by the 401 each MTA outside of the trust boundary of the originating system 402 which is contributing to the chain of ARC header fields. (See also 403 [OAR] for a similar usage.) The corresponding instance ("i=") value 404 MUST be prefixed to the Authentication-Results. 406 The value of the header field (after removing comments) consists of 407 an instance identifier, an authentication identifier, and then a 408 series of statements and supporting data. The statements are of the 409 form "method=result" and indicate which authentication method(s) were 410 applied and their respective results. For each such statement, the 411 supporting data can include a "reason" string and one or more 412 "property=value" statements indicating which message properties were 413 evaluated to reach that conclusion. The header field can appear 414 multiple times in a single message but each instance must have a 415 unique "i=" value. 417 5.1.3.1. 'i' value 419 For the ARC-Authentication-Results, the 'i' value is the 420 corresponding instance which matches the 'i' value of the related 421 ARC-Seal (see Section 5.1.1.1.1). 423 5.2. Constructing the ARC-Seal Header Set 425 The ARC-Seal is built in the same fashion as the analogous DKIM- 426 Signature [RFC6376], using the relaxed header canonicalization rules 427 specified in [RFC6376] but with a strict ordering component for the 428 header fields which are covered by the cryptographic signature: 430 1. The ARC header fields MUST be ordered in descending instance (i=) 431 order. 433 2. The referenced ARC-Message-Signatures (matching i= value) MUST 434 immediately follow the ARC-Seal instance which included the 435 reference. 437 3. The associated ARC-Authentication-Results header field (matching 438 i= value) MUST be the last item in the list for each set of ARC 439 header fields. 441 Thus, when prefixing ARC header fields to the beginning part of the 442 header block, 444 1. the AAR header would be prefixed first; then 446 2. the AMS would be calculated and prefixed; 448 3. lastly the AS would be calculated and prefixed. 450 5.2.1. Handling Violations in the ARC Header Field Set 452 When ordering the ARC set header fields, if there are gross 453 violations of this protocol, such as duplicated instance numbers, 454 such header field set(s) shall be ordered as follows (when analyzing 455 for validity or subsequent signing): 457 o Within each set, header fields shall be sorted as specified in 458 Section 5.2. 460 o Any header field sets which are complete duplicates shall be 461 deduplicated - leaving only one instance of each unique header 462 field set; then any remaining order dependencies between sets 463 shall be ordered as follows: 465 1. (First) By descending order of i= 467 2. (First) By descending order of t= (from the ARC-Seal header field 468 within the set) 470 3. (Finally) By ascending US-ASCII [RFC1345] sort order for the 471 entire canonicalized header field set 473 The intent of specifying this ordering is to allow downstream message 474 handlers to add their own ARC header field sets in a deterministic 475 manner and to provide some resiliance against mis-behaving downstream 476 MTAs. Participants who wish to have ARC information accrue to their 477 benefit are advised to ensure proper implementation so that this 478 section would never need to be invoked for their ARC header fields. 480 5.3. Key Management and Binding 482 The public keys for ARC-Seals follow the same requirements and 483 semantics as those for DKIM-Signatures [RFC6376]. Operators may use 484 distinct selectors for the ARC-Seals at their own discretion. 486 5.3.1. Namespace 488 All ARC-Seal keys are stored in the same subdomain as DKIM keys 489 [RFC6376]: "_domainkey". Given an ARC-Seal field with a "d=" tag of 490 "example.com" and an "s=" tag of "foo.bar", the DNS query will be for 491 "foo.bar._domainkey.example.com". 493 6. Usage 495 For a more thorough treatment of the recommended usage of the ARC 496 header fields for both intermediaries and end receivers, please 497 consult [ARC-USAGE]. 499 6.1. Participation 501 The inclusion of additional ARC header field sets should be done 502 whenever a trust boundary is crossed and especially when prior DKIM- 503 Signatures may not survive the handling which is being performed 504 (such as some mailing lists which modify the content of messages or 505 some gateway transformations). Note that trust boundaries may or may 506 not exactly correspond with ADMD boundaries. 508 Each participating ADMD MUST validate the preceding ARC set of header 509 fields as a part of asserting their own seal. Even if the set is 510 determined to be invalid, a participating ADMD SHOULD apply their own 511 seal because this can help in analysis of breakage points in the 512 chain. 514 6.2. Relationship between DKIM Signatures and ARC Headers 516 Any DKIM-Signatures SHOULD not include any of the ARC-Seal, ARC- 517 Message-Signature, or ARC-Authentication-Results header fields in the 518 scope of their header list. 520 ARC-Message-Signatures SHOULD include all DKIM-Signatures within 521 their scope. 523 6.3. Relationship of ARC-Message-Signatures and ARC-Seals 525 The ARC-Message-Signature(s) should not include any of the ARC-Seal 526 header fields in their coverage scope in order maintain a separation 527 of responsibilities. When adding an ARC-Authentication-Results 528 header field, it should be added before computing the ARC-Message- 529 Signature. When "sealing" the message, an operator must create the 530 ARC-Message-Signature before the ARC-Seal in order to reference it 531 and embed the ARC-Message-Signature within the ARC-Seal signature 532 scope. (Also refer to Section 5.2) 534 Each ARC-Seal is connected to its respective ARC-Message-Signature 535 through the i= field. 537 6.4. Validating the ARC set of header fields 539 Validation of the ARC header fields can be performed step-wise by 540 building up the sequence in order as defined in Section 5.2 and 541 evaluating the correctness of the b= signature at each step. If a 542 violation of the construction rules is found, for instance missing or 543 repeated instance numbers or an otherwise invalid ARC-Seal header 544 field, validation fails and should be indicated as 'P'(ermanent 545 error). 547 6.5. Assessing violations of ARC set validity 549 There are a wide variety of ways in which the ARC set of header 550 fields can be broken. Receivers should be wary of ascribing motive 551 to such breakage although patterns of common behaviour may provide 552 some basis for adjusting local policy decisions. 554 This proposal is exclusively focused on well-behaved, participating 555 intermediaries that result in a valid chain of ARC-related header 556 fields. The presence of such a well-formed valid chain should also 557 not be over-interpreted since malicious content can be easily 558 introduced by otherwise well-intended senders through machine or 559 account compromises. All normal content-based analysis should still 560 be performed on any messages bearing an ARC sequence. 562 6.6. Reporting violations of ARC set validity 564 If a receiver determines that the ARC set of header fields has a 565 permanent error, the receiver MAY signal the breakage through the 566 extended SMTP response code 5.7.7 [RFC3463] "message integrity 567 failure" [ENHANCED-STATUS]. 569 The extended SMTP response code should be paired with a 550 reply 570 code. (550 = Requested action not taken: mailbox unavailable (e.g., 571 mailbox not found, no access, or command rejected for policy reasons) 572 [RFC5321]) 574 6.7. Recording results of ARC evaluation 576 Receivers may add an "arc=pass" or "arc=fail" method annotation into 577 their local Authentication-Results [RFC7601] header field. 579 6.7.1. RFC6651 Failure Reporting for ARC 581 Due to very limited adoption, ARC evaluation results are not 582 recommended for failure reporting as described for DKIM in [RFC6651]. 584 6.7.2. Reporting ARC Effects for DMARC Local Policy 586 Receivers SHOULD indicate situations in which ARC evaluation 587 influenced the results of their local policy determination. Usage in 588 the DMARC reporting may look something like (utilizing a list of the 589 ARC participants that were found): 591 592 delivered 593 fail 594 fail 595 596 local_policy 597 arc=pass d=d1.example,d2.example 598 599 601 7. Privacy Considerations 603 The ARC-Seal chain provides a verifiable record of the handlers for a 604 message. Anonymous remailers will probably not find this to match 605 their operating goals. 607 8. IANA Considerations 609 This proposal adds three new header fields as defined below. 611 8.1. Update to RFC7601 header field method list 613 This proposal adds a new method to the [RFC7601] header field: "arc=" 614 for recording the results of the ARC header field validation. 616 8.2. Definitions of the ARC header fields 618 This proposal adds three new header fields to the "Permanent Message 619 Header Field Registry", as follows: 621 o Header field name: ARC-Seal 623 Applicable protocol: mail 625 Status: draft 627 Author/Change controller: OAR-Dev Group 629 Specification document(s): [I-D.ARC] 631 Related information: [RFC6376] 633 o Header field name: ARC-Message-Signature 635 Applicable protocol: mail 637 Status: draft 639 Author/Change controller: OAR-Dev Group 641 Specification document(s): [I-D.ARC] 643 Related information: [RFC6376] 645 o Header field name: ARC-Authentication-Results 647 Applicable protocol: mail 649 Status: standard 651 Author/Change controller: IETF 653 Specification document(s): [I-D.ARC] 654 Related information: [RFC7601] [OAR] 656 9. Security Considerations 658 Recipients are cautioned to treat messages bearing ARC-Seal chains 659 with the same suspicion that they apply to all other email messages. 660 This includes appropriate content scanning and other checks for 661 potentially malicious content. The handlers which are identified 662 within the ARC-Seal chain may be used to provide input to local 663 policy engines in cases where the sending system's DKIM-Signature 664 does not validate. 666 9.1. Preventing Repurposing of ARC Headers 668 ARC headers can not be re-used as DKIM-Signatures because the header 669 field names are incorporated in the signed content of both the AMS 670 and AS header fields. 672 9.2. Messages Which Transit the Same ADMD More Than Once 674 Messages which loop in and out of an ADMD may lead to confusion about 675 the scope of a particular set of ARC header fields. The use of 676 coordinated instance (i=) values and the non-confusability of the 677 ARC-Message-Signature vs. a DKIM-Signature are designed to prevent 678 misunderstandings. 680 10. References 682 10.1. Normative References 684 [RFC1345] Simonsen, K., "Character Mnemonics and Character Sets", 685 RFC 1345, DOI 10.17487/RFC1345, June 1992, 686 . 688 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 689 Requirement Levels", BCP 14, RFC 2119, 690 DOI 10.17487/RFC2119, March 1997, 691 . 693 [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and 694 Functions", RFC 2142, DOI 10.17487/RFC2142, May 1997, 695 . 697 [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS 698 Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999, 699 . 701 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", 702 RFC 3463, DOI 10.17487/RFC3463, January 2003, 703 . 705 [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys 706 Identified Mail (DKIM)", RFC 4686, DOI 10.17487/RFC4686, 707 September 2006, . 709 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 710 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 711 DOI 10.17487/RFC5226, May 2008, 712 . 714 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 715 Specifications: ABNF", STD 68, RFC 5234, 716 DOI 10.17487/RFC5234, January 2008, 717 . 719 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 720 DOI 10.17487/RFC5321, October 2008, 721 . 723 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 724 DOI 10.17487/RFC5322, October 2008, 725 . 727 [RFC5585] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys 728 Identified Mail (DKIM) Service Overview", RFC 5585, 729 DOI 10.17487/RFC5585, July 2009, 730 . 732 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 733 DOI 10.17487/RFC5598, July 2009, 734 . 736 [RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, 737 "DomainKeys Identified Mail (DKIM) Development, 738 Deployment, and Operations", RFC 5863, 739 DOI 10.17487/RFC5863, May 2010, 740 . 742 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 743 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 744 RFC 6376, DOI 10.17487/RFC6376, September 2011, 745 . 747 [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and 748 Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377, 749 September 2011, . 751 [RFC6651] Kucherawy, M., "Extensions to DomainKeys Identified Mail 752 (DKIM) for Failure Reporting", RFC 6651, 753 DOI 10.17487/RFC6651, June 2012, 754 . 756 [RFC7601] Kucherawy, M., "Message Header Field for Indicating 757 Message Authentication Status", RFC 7601, 758 DOI 10.17487/RFC7601, August 2015, 759 . 761 10.2. Informative References 763 [ARC-USAGE] 764 Jones, S., Adams, T., Rae-Grant, J., and K. Andersen, 765 "Recommended Usage of the ARC Headers", October 2015, 766 . 768 [DMARC-INTEROP] 769 Martin, F., Lear, E., Draegen, T., Zwicky, E., and K. 770 Andersen, "Interoperability Issues Between DMARC and 771 Indirect Email Flows", January 2016, 772 . 775 [ENHANCED-STATUS] 776 "IANA SMTP Enhanced Status Codes", n.d., 777 . 780 [OAR] Chew, M. and M. Kucherawy, "Original-Authentication- 781 Results Header Field", February 2012, 782 . 785 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 786 Message Authentication, Reporting, and Conformance 787 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 788 . 790 10.3. URIs 792 [1] mailto:arc-discuss@dmarc.org 794 Appendix A. Appendix A - Example Usage 796 [[ TODO [-03]: update these examples ]] 798 A.1. Example 1: Simple mailing list 800 A.1.1. Here's the message as it exits the Origin: 802 Return-Path: 803 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 804 (authenticated bits=0) 805 by segv.d1.example with ESMTP id t0FN4a8O084569; 806 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 807 (envelope-from jqd@d1.example) 808 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; 809 s=20130426; t=1421363082; 810 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 811 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: 812 Content-Transfer-Encoding; 813 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw 814 bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl 815 gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 816 Message-ID: <54B84785.1060301@d1.example> 817 Date: Thu, 14 Jan 2015 15:00:01 -0800 818 From: John Q Doe 819 To: arc@dmarc.org 820 Subject: Example 1 822 Hey gang, 823 This is a test message. 824 --J. 826 A.1.2. Message is then received at example.org 828 A.1.2.1. Example 1, Step A: Message forwarded to list members 830 Processing at example.org: 832 o example.org performs authentication checks 834 o No previous Auth-Results or ARC-Seal headers are present 836 o example.org adds ARC-Auth-Results header 838 o example.org adds Received: header 840 o example.org adds a ARC-Seal header 841 Here's the message as it exits example.org: 843 Return-Path: 844 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 845 s=seal2015; d=example.org; cv=N; 846 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 847 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 848 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 849 ARC-Message-Signature: i=1; a=rsa-sha256; 850 d=example.org; s=clochette; t=1421363105; 851 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; 852 h=List-Id:List-Unsubscribe:List-Archive:List-Post: 853 List-Help:List-Subscribe:Reply-To:DKIM-Signature; 854 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1F5 855 vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+m4bw 856 a6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= 857 Received: from segv.d1.example (segv.d1.example [72.52.75.15]) 858 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 859 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) 860 (envelope-from jqd@d1.example) 861 ARC-Authentication-Results: i=1; lists.example.org; 862 spf=pass smtp.mfrom=jqd@d1.example; 863 dkim=pass (1024-bit key) header.i=@d1.example; 864 dmarc=pass 865 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 866 (authenticated bits=0) 867 by segv.d1.example with ESMTP id t0FN4a8O084569; 868 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 869 (envelope-from jqd@d1.example) 870 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; 871 s=20130426; t=1421363082; 872 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 873 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: 874 Content-Transfer-Encoding; 875 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr 876 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G 877 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 878 Message-ID: <54B84785.1060301@d1.example> 879 Date: Thu, 14 Jan 2015 15:00:01 -0800 880 From: John Q Doe 881 To: arc@example.org 882 Subject: [Lists] Example 1 884 Hey gang, 885 This is a test message. 886 --J. 888 A.1.3. Example 1: Message received by Recipient 890 Let's say that the Recipient is example.com 892 Processing at example.com: 894 o example.com performs usual authentication checks 896 o example.com adds Auth-Results: header, Received header 898 o Determines that message fails DMARC 900 o Checks for ARC-Seal: header; finds one 902 o Validates the signature in the ARC-Seal: header, which covers the 903 ARC-Authentication-Results: header 905 o example.com can use the ARC-Authentication-Results values or 906 verify the DKIM-Signature from lists.example.org 908 Here's what the message looks like at this point: 910 Return-Path: 911 Received: from example.org (example.org [208.69.40.157]) 912 by clothilde.example.com with ESMTP id 913 d200mr22663000ykb.93.1421363207 914 for ; Thu, 14 Jan 2015 15:02:40 -0800 (PST) 915 Authentication-Results: clothilde.example.com; spf=fail 916 smtp.from=jqd@d1.example; dkim=pass (1024-bit key) 917 header.i=@example.org; dmarc=fail; arc=pass 918 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 919 s=seal2015; d=example.org; cv=N; 920 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 921 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 922 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 923 ARC-Message-Signature: i=1; a=rsa-sha256; 924 d=example.org; s=clochette; t=1421363105; 925 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; 926 h=List-Id:List-Unsubscribe:List-Archive:List-Post: 927 List-Help:List-Subscribe:Reply-To:DKIM-Signature; 928 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF 929 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3 930 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= 931 Received: from segv.d1.example (segv.d1.example [72.52.75.15]) 932 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 933 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) 934 (envelope-from jqd@d1.example) 935 ARC-Authentication-Results: i=1; lists.example.org; 936 spf=pass smtp.mfrom=jqd@d1.example; 937 dkim=pass (1024-bit key) header.i=@d1.example; 938 dmarc=pass 939 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 940 (authenticated bits=0) 941 by segv.d1.example with ESMTP id t0FN4a8O084569; 942 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 943 (envelope-from jqd@d1.example) 944 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; 945 s=20130426; t=1421363082; 946 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 947 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: 948 Content-Transfer-Encoding; 949 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw 950 bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl 951 gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 952 Message-ID: <54B84785.1060301@d1.example> 953 Date: Thu, 14 Jan 2015 15:00:01 -0800 954 From: John Q Doe 955 To: arc@example.org 956 Subject: [Lists] Example 1 958 Hey gang, 959 This is a test message. 960 --J. 962 A.2. Example 2: Mailing list to forwarded mailbox 964 A.2.1. Here's the message as it exits the Origin: 966 Return-Path: 967 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 968 (authenticated bits=0) 969 by segv.d1.example with ESMTP id t0FN4a8O084569; 970 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 971 (envelope-from jqd@d1.example) 972 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; 973 s=20130426; t=1421363082; 974 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 975 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: 976 Content-Transfer-Encoding; 977 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw 978 bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl 979 gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 980 Message-ID: <54B84785.1060301@d1.example> 981 Date: Thu, 14 Jan 2015 15:00:01 -0800 982 From: John Q Doe 983 To: arc@example.org 984 Subject: Example 1 986 Hey gang, 987 This is a test message. 988 --J. 990 A.2.2. Message is then received at example.org 992 A.2.2.1. Example 2, Step A: Message forwarded to list members 994 Processing at example.org: 996 o example.org performs authentication checks 998 o example.org applies standard DKIM signature 1000 o No previous Auth-Results or ARC-Seal headers are present 1002 o example.org adds ARC-Auth-Results header 1004 o example.org adds usual Received: header 1006 o example.org adds a ARC-Seal header 1008 Here's the message as it exits Step A: 1010 Return-Path: 1011 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 1012 s=seal2015; d=example.org; cv=N; 1013 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6 1014 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L 1015 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 1016 ARC-Message-Signature: i=1; a=rsa-sha256; 1017 d=example.org; s=clochette; t=1421363105; 1018 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; 1019 h=List-Id:List-Unsubscribe:List-Archive:List-Post: 1020 List-Help:List-Subscribe:Reply-To:DKIM-Signature; 1021 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF 1022 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3 1023 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= 1024 Received: from segv.d1.example (segv.d1.example [72.52.75.15]) 1025 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 1026 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) 1027 (envelope-from jqd@d1.example) 1028 ARC-Authentication-Results: i=1; lists.example.org; 1029 spf=pass smtp.mfrom=jqd@d1.example; 1030 dkim=pass (1024-bit key) header.i=@d1.example; 1031 dmarc=pass 1032 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 1033 (authenticated bits=0) 1034 by segv.d1.example with ESMTP id t0FN4a8O084569; 1035 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 1036 (envelope-from jqd@d1.example) 1037 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; 1038 s=20130426; t=1421363082; 1039 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 1040 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: 1041 Content-Transfer-Encoding; 1042 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr 1043 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G 1044 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 1045 Message-ID: <54B84785.1060301@d1.example> 1046 Date: Thu, 14 Jan 2015 15:00:01 -0800 1047 From: John Q Doe 1048 To: arc@example.org 1049 Subject: [Lists] Example 1 1051 Hey gang, 1052 This is a test message. 1053 --J. 1055 A.2.2.2. Example 2, Step B: Message from list forwarded 1057 The message is delivered to a mailbox at gmail.com 1058 Processing at gmail.com: 1060 o gmail.com performs usual authentication checks 1062 o gmail.com adds Auth-Results: and Received: header 1064 o Determines that message fails DMARC 1066 o Checks for ARC-Seal: header; finds one 1068 o Validates the signature in the ARC-Seal: header, which covers the 1069 ARC-Authentication-Results: header 1071 o Uses the ARC-Auth-Results: values, but: 1073 o Instead of delivering message, prepares to forward message per 1074 user settings 1076 o Applies usual DKIM signature 1078 o gmail.com adds it's own ARC-Seal: header, contents of which are 1080 * version 1082 * sequence number ("i=2") 1084 * hash algorithm (SHA256 as example) 1086 * timestamp ("t=") 1088 * selector for key ("s=notary01") 1090 * domain for key ("d=gmail.com") 1092 * headers included in hash ("h=ARC-Authentication-Results:ARC- 1093 Seal") 1095 * Note: algorithm requires only ARC-Seals with lower sequence # 1096 be included, in ascending order 1098 * signature of the header hash 1100 Here's what the message looks like at this point: 1102 Return-Path: 1103 ARC-Seal: i=2; a=rsa-sha256; t=1421363253; 1104 s=notary01; d=gmail.com; cv=V; 1105 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDWR 1106 YbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/sut 1107 txO+RRNr0fCFw== 1108 ARC-Message-Signature: i=2; a=rsa-sha256; 1109 d=gmail.com; s=20120806; 1110 h=mime-version:content-type:x-original-sender: 1111 x-original-authentication-results:precedence:mailing-list: 1112 list-id:list-post:list-help:list-archive:sender:reply-to: 1113 list-unsubscribe:DKIM-Signature; 1114 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=; 1115 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 1116 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 1117 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBmfhS 1118 LF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJRFeM 1119 KdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwDBJtXw 1120 bQoZyRtb6X6q0mYaszUB8kw== 1121 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10 1122 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST) 1123 Authentication-Results: i=2; gmail.com; spf=fail 1124 smtp.from=jqd@d1.example; dkim=pass (1024-bit key) 1125 header.i=@example.org; dmarc=fail; arc=pass 1126 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 1127 s=seal2015; d=example.org; cv=N: 1128 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 1129 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 1130 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 1131 ARC-Message-Signature: i=1; a=rsa-sha256; 1132 d=example.org; s=clochette; t=1421363105; 1133 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; 1134 h=List-Id:List-Unsubscribe:List-Archive:List-Post: 1135 List-Help:List-Subscribe:Reply-To:DKIM-Signature; 1136 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF 1137 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3 1138 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= 1139 Received: from segv.d1.example (segv.d1.example [72.52.75.15]) 1140 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 1141 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) 1142 (envelope-from jqd@d1.example) 1143 ARC-Authentication-Results: i=1; lists.example.org; 1144 spf=pass smtp.mfrom=jqd@d1.example; 1145 dkim=pass (1024-bit key) header.i=@d1.example; 1146 dmarc=pass 1147 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 1148 (authenticated bits=0) 1149 by segv.d1.example with ESMTP id t0FN4a8O084569; 1150 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 1151 (envelope-from jqd@d1.example) 1152 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; 1153 s=20130426; t=1421363082; 1154 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 1155 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: 1156 Content-Transfer-Encoding; 1157 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr 1158 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G 1159 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 1160 Message-ID: <54B84785.1060301@d1.example> 1161 Date: Thu, 14 Jan 2015 15:00:01 -0800 1162 From: John Q Doe 1163 To: arc@example.org 1164 Subject: [Lists] Example 1 1166 Hey gang, 1167 This is a test message. 1168 --J. 1170 A.2.3. Example 2: Message received by Recipient 1172 Let's say that the Recipient is example.com 1173 Processing at example.com: 1175 o example.com performs usual authentication checks 1177 o example.com adds Auth-Results: header, Received header 1179 o Determines that message fails DMARC 1181 o Checks for ARC-Seal: header; finds two 1183 o Validates the signature in the highest numbered ("i=2") ARC-Seal: 1184 header, which covers all previous ARC-Seal: and ARC- 1185 Authentication-Results: headers 1187 o Validates the other ARC-Seal header ("i=1"), which covers the ARC- 1188 Authentication-Results: header 1190 o example.com uses the ARC-Authentication-Results: values 1192 Here's what the message looks like at this point: 1194 Return-Path: 1195 Received: from mail-ob0-f188.google.com (mail-ob0-f188.google.com 1196 [208.69.40.157]) by clothilde.example.com with ESMTP id 1197 d200mr22663000ykb.93.1421363268 1198 for ; Thu, 14 Jan 2015 15:03:15 -0800 (PST) 1200 Authentication-Results: clothilde.example.com; spf=fail 1201 smtp.from=jqd@d1.example; dkim=pass (1024-bit key) 1202 header.i=@gmail.com; dmarc=fail; arc=pass 1203 ARC-Seal: i=2; a=rsa-sha256; t=1421363253; 1204 s=notary01; d=gmail.com; cv=V; 1205 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDWR 1206 YbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/sut 1207 txO+RRNr0fCFw== 1208 ARC-Message-Signature: i=2; a=rsa-sha256; 1209 d=gmail.com; s=20120806; 1210 h=mime-version:content-type:x-original-sender: 1211 x-original-authentication-results:precedence:mailing-list: 1212 list-id:list-post:list-help:list-archive:sender:reply-to: 1213 :list-unsubscribe:DKIM-Signature; 1214 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=; 1215 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 1216 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 1217 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBmfhS 1218 LF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJRFeM 1219 KdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwDBJtXw 1220 bQoZyRtb6X6q0mYaszUB8kw== 1221 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10 1222 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST) 1223 Authentication-Results: i=2; gmail.com; spf=fail 1224 smtp.from=jqd@d1.example; dkim=pass (1024-bit key) 1225 header.i=@example.org; dmarc=fail; arc=pass 1226 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 1227 s=seal2015; d=example.org; cv=N; 1228 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 1229 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 1230 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 1231 ARC-Message-Signature: i=1; a=rsa-sha256; 1232 d=example.org; s=clochette; t=1421363105; 1233 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; 1234 h=List-Id:List-Unsubscribe:List-Archive:List-Post: 1235 List-Help:List-Subscribe:Reply-To:DKIM-Signature; 1236 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF 1237 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3 1238 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= 1239 Received: from segv.d1.example (segv.d1.example [72.52.75.15]) 1240 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 1241 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) 1242 (envelope-from jqd@d1.example) 1243 ARC-Authentication-Results: i=1; lists.example.org; 1244 spf=pass smtp.mfrom=jqd@d1.example; 1245 dkim=pass (1024-bit key) header.i=@d1.example; 1246 dmarc=pass 1247 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 1248 (authenticated bits=0) 1249 by segv.d1.example with ESMTP id t0FN4a8O084569; 1250 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 1251 (envelope-from jqd@d1.example) 1252 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; 1253 s=20130426; t=1421363082; 1254 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 1255 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: 1256 Content-Transfer-Encoding; 1257 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr 1258 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G 1259 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 1260 Message-ID: <54B84785.1060301@d1.example> 1261 Date: Thu, 14 Jan 2015 15:00:01 -0800 1262 From: John Q Doe 1263 To: arc@example.org 1264 Subject: [Lists] Example 1 1266 Hey gang, 1267 This is a test message. 1268 --J. 1270 A.3. Example 3: Mailing list to forwarded mailbox with source 1272 A.3.1. Here's the message as it exits the Origin: 1274 Return-Path: 1275 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 1276 (authenticated bits=0) 1277 by segv.d1.example with ESMTP id t0FN4a8O084569; 1278 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 1279 (envelope-from jqd@d1.example) 1280 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 1281 s=origin2015; d=d1.example; cv=N; 1282 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61T 1283 X6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69EU 1284 8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 1285 ARC-Message-Signature: i=1; a=rsa-sha256; 1286 d=d1.example; s=20130426; t=1421363082; 1287 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 1288 h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding; 1289 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrv 1290 Qwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3 1291 TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 1292 Message-ID: <54B84785.1060301@d1.example> 1293 Date: Thu, 14 Jan 2015 15:00:01 -0800 1294 From: John Q Doe 1295 To: arc@example.org 1296 Subject: Example 1 1298 Hey gang, 1299 This is a test message. 1300 --J. 1302 A.3.2. Message is then received at example.org 1304 A.3.2.1. Example 3, Step A: Message forwarded to list members with 1305 source 1307 Processing at example.org: 1309 o example.org performs authentication checks 1311 o example.org applies standard DKIM signature 1313 o Checks for ARC-Seal: header; finds one (i=1) 1315 o Validates the signature in the ARC-Seal (i=1): header, which 1316 covers the d1.example ARC-Message-Signature: header 1318 o example.org adds ARC-Auth-Results header 1320 o example.org adds usual Received: header 1321 o example.org adds a DKIM-Signature 1323 o example.org adds a ARC-Seal header, contents of which are 1325 * sequence number ("i=2") 1327 * hash algorithm (SHA256 as example) 1329 * timestamp ("t=") 1331 * chain validity ("cv=") 1333 * selector for key ("s=seal2015") 1335 * domain for key ("d=example.org") 1337 * signature ("b=") 1339 Here's the message as it exits Step A: 1341 Return-Path: 1342 ARC-Seal: i=2; a=rsa-sha256; t=1421363107; 1343 s=seal2015; d=example.org; cv=V; 1344 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6 1345 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L 1346 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 1347 ARC-Message-Signature: i=2; a=rsa-sha256; 1348 d=example.org; s=clochette; t=1421363105; 1349 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; 1350 h=List-Id:List-Unsubscribe:List-Archive:List-Post: 1351 List-Help:List-Subscribe:From:Reply-To:DKIM-Signature; 1352 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF 1353 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3 1354 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= 1355 Received: from segv.d1.example (segv.d1.example [72.52.75.15]) 1356 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 1357 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) 1358 (envelope-from jqd@d1.example) 1359 ARC-Authentication-Results: i=2; lists.example.org; 1360 spf=pass smtp.mfrom=jqd@d1.example; 1361 dkim=pass (1024-bit key) header.i=@d1.example; 1362 dmarc=pass 1363 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 1364 (authenticated bits=0) 1365 by segv.d1.example with ESMTP id t0FN4a8O084569; 1366 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 1367 (envelope-from jqd@d1.example) 1368 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 1369 s=origin2015; d=d1.example; cv=N; 1370 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 1371 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 1372 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 1373 ARC-Message-Signature: i=1; a=rsa-sha256; 1374 d=d1.example; s=20130426; t=1421363082; 1375 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 1376 h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding; 1377 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr 1378 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G 1379 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 1380 Message-ID: <54B84785.1060301@d1.example> 1381 Date: Thu, 14 Jan 2015 15:00:01 -0800 1382 From: John Q Doe 1383 To: arc@example.org 1384 Subject: [Lists] Example 1 1386 Hey gang, 1387 This is a test message. 1388 --J. 1390 A.3.2.2. Example 3, Step B: Message from list forwarded with source 1392 The message is delivered to a mailbox at gmail.com 1393 Processing at gmail.com: 1395 o gmail.com performs usual authentication checks 1397 o gmail.com adds Auth-Results: and Received: header 1399 o Determines that message fails DMARC 1401 o Checks for ARC-Seal: header; finds two 1403 o Validates the signature in the ARC-Seal (i=2): header, which 1404 covers the ARC-Authentication-Results: header 1406 o Validates the signature in the ARC-Seal (i=1): header, which 1407 covers the d1.example ARC-Message-Signature: header 1409 o Uses the ARC-Auth-Results: values, but: 1411 o Instead of delivering message, prepares to forward message per 1412 user settings 1414 o Applies usual DKIM signature 1416 o gmail.com adds it's own ARC-Seal: header, contents of which are 1418 * version 1420 * sequence number ("i=2") 1422 * hash algorithm (SHA256 as example) 1424 * timestamp ("t=") 1426 * selector for key ("s=notary01") 1428 * domain for key ("d=gmail.com") 1430 * Note: algorithm requires only ARC-Seals with lower sequence # 1431 be included, in ascending order 1433 * signature of the chain 1435 Here's what the message looks like at this point: 1437 Return-Path: 1438 ARC-Seal: i=3; a=rsa-sha256; t=1421363253; 1439 s=notary01; d=gmail.com; cv=V; 1440 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwD 1441 WRYbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF 1442 /suttxO+RRNr0fCFw== 1443 ARC-Message-Signature: i=3; a=rsa-sha256; 1444 d=gmail.com; s=20120806; 1445 h=mime-version:content-type:x-original-sender 1446 :x-original-authentication-results:precedence:mailing-list 1447 :list-id:list-post:list-help:list-archive:sender 1448 :list-unsubscribe:reply-to; 1449 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=; 1450 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6 1451 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L 1452 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBm 1453 fhSLF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJ 1454 RFeMKdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwD 1455 BJtXwbQoZyRtb6X6q0mYaszUB8kw== 1456 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10 1457 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST) 1458 Authentication-Results: i=3; gmail.com; spf=fail 1459 smtp.from=jqd@d1.example; dkim=pass (1024-bit key) 1460 header.i=@example.org; dmarc=fail; arc=pass 1461 ARC-Seal: i=2; a=rsa-sha256; t=1421363107; 1462 s=seal2015; d=example.org; cv=V; 1463 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 1464 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 1465 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 1466 ARC-Message-Signature: i=2; a=rsa-sha256; 1467 d=example.org; s=clochette; t=1421363105; 1468 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; 1469 h=List-Id:List-Unsubscribe:List-Archive:List-Post: 1470 List-Help:List-Subscribe:Reply-To:DKIM-Signature; 1471 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1 1472 F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+ 1473 m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= 1474 Received: from segv.d1.example (segv.d1.example [72.52.75.15]) 1475 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 1476 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) 1477 (envelope-from jqd@d1.example) 1478 ARC-Authentication-Results: i=2; lists.example.org; 1479 spf=pass smtp.mfrom=jqd@d1.example; 1480 dkim=pass (1024-bit key) header.i=@d1.example; 1481 dmarc=pass 1482 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 1483 (authenticated bits=0) 1484 by segv.d1.example with ESMTP id t0FN4a8O084569; 1485 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 1486 (envelope-from jqd@d1.example) 1487 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 1488 s=origin2015; d=d1.example; cv=N; 1489 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 1490 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 1491 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 1492 ARC-Message-Signature: i=1; a=rsa-sha256; 1493 d=d1.example; s=20130426; t=1421363082; 1494 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 1495 h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding; 1496 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYij 1497 rvQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD 1498 4Gd3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 1499 Message-ID: <54B84785.1060301@d1.example> 1500 Date: Thu, 14 Jan 2015 15:00:01 -0800 1501 From: John Q Doe 1502 To: arc@example.org 1503 Subject: [Lists] Example 1 1505 Hey gang, 1506 This is a test message. 1507 --J. 1509 A.3.3. Example 3: Message received by Recipient 1511 Let's say that the Recipient is example.com 1512 Processing at example.com: 1514 o example.com performs usual authentication checks 1516 o example.com adds Auth-Results: header, Received header 1518 o Determines that message fails DMARC 1520 o Checks for ARC-Seal: header; finds three 1522 o Validates the signature in the highest numbered ("i=2") ARC-Seal: 1523 header, which covers all previous ARC-Seal: and ARC- 1524 Authentication-Results: headers 1526 o Validates the other ARC-Seal header ("i=2"), which covers the ARC- 1527 Authentication-Results: header 1529 o Validates the other ARC-Seal header ("i=1"), which covers the 1530 d1.example ARC-Message-Signature: header 1532 o example.com uses the ARC-Authentication-Results: values 1533 Here's what the message looks like at this point: 1535 Return-Path: 1536 Received: from mail-ob0-f188.google.com (mail-ob0-f188.google.com 1537 [208.69.40.157]) by clothilde.example.com with ESMTP id 1538 d200mr22663000ykb.93.1421363268 1539 for ; Thu, 14 Jan 2015 15:03:15 -0800 (PST) 1540 Authentication-Results: clothilde.example.com; spf=fail 1541 smtp.from=jqd@d1.example; dkim=pass (1024-bit key) 1542 header.i=@gmail.com; dmarc=fail; arc=pass 1543 ARC-Seal: i=3; a=rsa-sha256; t=1421363253; 1544 s=notary01; d=gmail.com; cv=V; 1545 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDW 1546 RYbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/s 1547 uttxO+RRNr0fCFw== 1548 ARC-Message-Signature: i=3; a=rsa-sha256; 1549 d=gmail.com; s=20120806; 1550 h=mime-version:content-type:x-original-sender 1551 :x-original-authentication-results:precedence 1552 :mailing-list:list-id:list-post:list-help:list-archive:sender 1553 :list-unsubscribe:reply-to; 1554 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=; 1555 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6 1556 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L 1557 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBm 1558 fhSLF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJ 1559 RFeMKdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwD 1560 BJtXwbQoZyRtb6X6q0mYaszUB8kw== 1561 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10 1562 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST) 1563 Authentication-Results: i=3; gmail.com; spf=fail 1564 smtp.from=jqd@d1.example; dkim=pass (1024-bit key) 1565 header.i=@example.org; dmarc=fail; arc=pass 1566 ARC-Seal: i=2; a=rsa-sha256; t=1421363107; 1567 s=seal2015; d=example.org; cv=V; 1568 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6 1569 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L 1570 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 1571 ARC-Message-Signature: i=2; a=rsa-sha256; 1572 d=example.org; s=clochette; t=1421363105; 1573 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; 1574 h=List-Id:List-Unsubscribe:List-Archive:List-Post: 1575 List-Help:List-Subscribe:Reply-To:DKIM-Signature; 1576 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1 1577 F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+ 1578 m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= 1579 Received: from segv.d1.example (segv.d1.example [72.52.75.15]) 1580 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 1581 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) 1582 (envelope-from jqd@d1.example) 1583 ARC-Authentication-Results: i=2; lists.example.org; 1584 spf=pass smtp.mfrom=jqd@d1.example; 1585 dkim=pass (1024-bit key) header.i=@d1.example; 1586 dmarc=pass 1587 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 1588 (authenticated bits=0) 1589 by segv.d1.example with ESMTP id t0FN4a8O084569; 1590 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 1591 (envelope-from jqd@d1.example) 1592 ARC-Seal: i=1; a=rsa-sha256; t=1421363107; 1593 s=origin2015; d=d1.example; cv=N; 1594 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 1595 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 1596 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= 1597 ARC-Message-Signature: i=1; a=rsa-sha256; 1598 d=d1.example; s=20130426; t=1421363082; 1599 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 1600 h=MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding; 1601 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr 1602 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G 1603 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 1604 Message-ID: <54B84785.1060301@d1.example> 1605 Date: Thu, 14 Jan 2015 15:00:01 -0800 1606 From: John Q Doe 1607 To: arc@example.org 1608 Subject: [Lists] Example 1 1610 Hey gang, 1611 This is a test message. 1612 --J. 1614 Appendix B. Acknowledgements 1616 This draft is the work of OAR-Dev Group. 1618 The authors thank all of the OAR-Dev group for the ongoing help and 1619 though-provoking discussions from all the participants, especially: 1620 Alex Brotman, Brandon Long, Dave Crocker, Elizabeth Zwicky, Franck 1621 Martin, Greg Colburn, J. Trent Adams, John Rae-Grant, Mike Hammer, 1622 Mike Jones, Steve Jones, Terry Zink, Tim Draegen. 1624 Grateful appreciation is extended to the people who provided feedback 1625 through the discuss mailing list. 1627 Appendix C. Comments and Feedback 1629 Please address all comments, discussions, and questions to arc- 1630 discuss@dmarc.org [1][mailto:arc-discuss@dmarc.org]. 1632 Appendix D. Historical Note 1634 The ARC-Authentication-Results header is a direct copy of the normal 1635 Authentication-Results header ([RFC7601]) used in a similar fashion 1636 as that proposed in [OAR] but has the instance (i=) value added to 1637 provide correlation within the set of ARC headers. 1639 Authors' Addresses 1641 OAR-DEV Group 1643 Email: arc-discuss@dmarc.org 1645 Kurt Andersen 1646 LinkedIn 1647 2029 Stierlin Ct. 1648 Mountain View, California 94043 1649 USA 1651 Email: kurta@linkedin.com 1653 John Rae-Grant (editor) 1654 Google 1656 Email: johnrg@google.com 1658 Brandon Long (editor) 1659 Google 1661 Email: blong@google.com 1663 J. Trent Adams (editor) 1664 Paypal 1666 Email: trent.adams@paypal.com 1667 Steven Jones (editor) 1668 TDP 1670 Email: smj@crash.com