idnits 2.17.1
draft-andersen-arc-05.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:
The ARC-Message-Signature field(s) MUST not include any of the
ARC-Seal header field(s) (from prior ARC sets) in their signing scope in
order maintain a separation of responsibilities. When adding an
ARC-Authentication-Results header field, it MUST be added before
computing the ARC-Message-Signature. When "sealing" the message, an
operator MUST create and attach the ARC-Message-Signature before the
ARC-Seal in order to reference it and embed the ARC-Message-Signature
within the ARC-Seal signature scope.
-- The document date (May 23, 2016) is 2888 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Missing Reference: 'I-D.ARC' is mentioned on line 705, but not defined
-- Looks like a reference, but probably isn't: '1' on line 1692
== Missing Reference: '-03' is mentioned on line 858, but not defined
== Missing Reference: 'Lists' is mentioned on line 1670, but not defined
== Unused Reference: 'RFC2142' is defined on line 755, but no explicit
reference was found in the text
== Unused Reference: 'RFC2606' is defined on line 759, but no explicit
reference was found in the text
== Unused Reference: 'RFC4686' is defined on line 767, but no explicit
reference was found in the text
== Unused Reference: 'RFC5226' is defined on line 771, but no explicit
reference was found in the text
== Unused Reference: 'RFC5585' is defined on line 789, but no explicit
reference was found in the text
== Unused Reference: 'RFC5863' is defined on line 798, but no explicit
reference was found in the text
== Unused Reference: 'RFC6377' is defined on line 809, but no explicit
reference was found in the text
== Unused Reference: 'RFC6651' is defined on line 813, 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 (~~), 13 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: November 24, 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 May 23, 2016
15 Authenticated Received Chain (ARC)
16 draft-andersen-arc-05
18 Abstract
20 Authenticated Received Chain (ARC) permits an organization which is
21 creating or handling email to indicate its involvement with the
22 handling process. It defines a set of cryptographically signed
23 header fields in a manner analagous to that of DKIM. Assertion of
24 responsibility is validated through a cryptographic signature and by
25 querying the Signer's domain directly to retrieve the appropriate
26 public key. Changes in the message that might break DKIM can be
27 identified 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 November 24, 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 . . . . . . . . . . . . . . . . 9
77 5.1.3. ARC-Authentication-Results . . . . . . . . . . . . . 10
78 5.2. Constructing the ARC-Seal Set . . . . . . . . . . . . . . 10
79 5.2.1. Handling Violations in the ARC Sets . . . . . . . . . 11
80 5.3. Key Management and Binding . . . . . . . . . . . . . . . 12
81 5.3.1. Namespace . . . . . . . . . . . . . . . . . . . . . . 12
82 6. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
83 6.1. Participation . . . . . . . . . . . . . . . . . . . . . . 12
84 6.2. Relationship between DKIM Signatures and ARC Headers . . 13
85 6.3. Validating the ARC Set of Header Fields . . . . . . . . . 13
86 6.4. ARC Set Validity . . . . . . . . . . . . . . . . . . . . 13
87 6.4.1. Assessing Chain Validity Violations . . . . . . . . . 13
88 6.4.2. Responding to ARC Validity Violations . . . . . . . . 13
89 6.4.3. Recording the Results of ARC Evaluation . . . . . . . 13
90 6.4.4. Output Data Points from ARC Evaluation . . . . . . . 13
91 6.4.5. Reporting ARC Effects for DMARC Local Policy . . . . 14
92 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14
93 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
94 8.1. Authentication-Results Method Registry Update . . . . . . 14
95 8.2. Definitions of the ARC header fields . . . . . . . . . . 15
96 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
97 9.1. Message Content Suspicion . . . . . . . . . . . . . . . . 16
98 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
99 10.1. Normative References . . . . . . . . . . . . . . . . . . 16
100 10.2. Informative References . . . . . . . . . . . . . . . . . 18
101 Appendix A. Appendix A - Example Usage . . . . . . . . . . . . . 19
102 A.1. Example 1: Simple mailing list . . . . . . . . . . . . . 19
103 A.1.1. Here's the message as it exits the Origin: . . . . . 19
104 A.1.2. Message is then received at example.org . . . . . . . 19
105 A.1.3. Example 1: Message received by Recipient . . . . . . 21
106 A.2. Example 2: Mailing list to forwarded mailbox . . . . . . 22
107 A.2.1. Here's the message as it exits the Origin: . . . . . 22
108 A.2.2. Message is then received at example.org . . . . . . . 23
109 A.2.3. Example 2: Message received by Recipient . . . . . . 27
110 A.3. Example 3: Mailing list to forwarded mailbox with source 29
111 A.3.1. Here's the message as it exits the Origin: . . . . . 29
112 A.3.2. Message is then received at example.org . . . . . . . 30
113 A.3.3. Example 3: Message received by Recipient . . . . . . 35
114 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 37
115 Appendix C. Comments and Feedback . . . . . . . . . . . . . . . 38
116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
118 1. Introduction
120 The development of strong domain authentication through Sender Policy
121 Framework (SPF) [RFC7208] and DomainKeys Identified Mail (DKIM)
122 [RFC6376] has led to the implementation of the DMARC framework
123 [RFC7489] which extends the authentication to the author's "From:"
124 (RFC5322.From) field and permits publishing policies for non-
125 compliant messages. Implicit within the DMARC framework is a
126 requirement that any intermediaries between the source system and
127 ultimate receiver system need to preserve the validity of the DKIM
128 signature; however, there are common legitimate email practices which
129 break the DKIM validation ([DMARC-INTEROP]). This specification
130 defines an Authenticated Received Chain (ARC). ARC addresses the
131 problems with the untrustworthiness of the standard Received header
132 field sequence. Through the information tracked in the ARC series of
133 headers, receivers can develop a more nuanced interpretation to guide
134 any local policies related to messages that arrive with broken domain
135 authentication (DMARC).
137 Forgery of the Received header fields is a common tactic used by bad
138 actors. One of the goals of this specification defines a comparable
139 set of trace header fields which can be relied upon by receivers,
140 assuming all ADministrative Management Domain (ADMD) intermediary
141 handlers of a message participate in ARC.
143 The Authentication-Results (A-R) mechanism [RFC7601] permits the
144 output of an email authentication evaluation process to be
145 transmitted from the evaluating agent to a consuming agent that uses
146 the information. On its own, A-R is believable only within a trust
147 domain. ARC provides a protection mechanism for the data, permiting
148 the communication to cross trust domain boundaries.
150 2. Requirements
152 The specification of the ARC framework is driven by the following
153 high-level goals, security considerations, and practical operational
154 requirements.
156 2.1. Primary Design Criteria
158 o Provide a verifiable "chain of custody" for email messages;
160 o Not require changes for originators of email;
162 o Support the verification of the ARC header field set by each hop
163 in the handling chain;
165 o Work at Internet scale; and
167 o Provide a trustable mechanism for the communication of
168 Authentication-Results across trust boundaries.
170 2.2. Out of Scope
172 ARC is not a trust framework. Users of the ARC header fields are
173 cautioned against making unsubstantiated conclusions when
174 encountering a "broken" ARC sequence.
176 2.3. Utility
178 The ARC-related set of header fields can be used (when validated) to
179 determine the path that an email message has taken between the
180 originating system and receiver. Subject to the cautions mentioned
181 in Section 9, this information can assist in determining any local
182 policy overrides to for violations of origination domain
183 authentication policies.
185 3. Terminology
187 This section defines terms used in the rest of the document.
189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
191 document are to be interpreted as described in [RFC2119].
193 Readers are encouraged to be familiar with the contents of [RFC5598],
194 and in particular, the potential roles of intermediaries in the
195 delivery of email.
197 Syntax descriptions use Augmented BNF (ABNF) [RFC5234].
199 4. Overview
201 When an email message is received without a properly validated
202 originating domain, the inability to believe the accuracy of a series
203 of Received header fields prevents receiving systems from having a
204 way to infer anything about the handling of the message by looking at
205 the ADMDs through which the message has traveled.
207 With ARC, participating ADMDs are able to securely register their
208 handling of an email message. If all mediators ([RFC5598])
209 participate in the ARC process, receivers will be able to rely upon
210 the chain and make local policy decisions informed by that
211 information.
213 The ARC set of header fields provides a method by which participating
214 intermediaries can indicate the hand-offs for email messages.
216 5. Definition
218 This specification defines three new header fields:
220 o Header field name: ARC-Seal (abbreviated below as AS)
222 o Header field name: ARC-Message-Signature (abbreviated below as
223 AMS)
225 o Header field name: ARC-Authentication-Results (abbreviated below
226 as AAR)
228 Collectively, these header fields form a connected set of attribution
229 information by which receivers can identify the handling path for a
230 message. As described below, a distinct set of these fields share a
231 common sequence number, identified in an "i=" tag. Such a correlated
232 group of header fields is referred to as an "ARC set".
234 Specific references to individual header fields use the header field
235 names to distinguish such references.
237 The ARC sets SHOULD be added at the top of a message header as it
238 transits MTAs that do authentication checks, so some idea of how far
239 away the checks were done can be inferred. They are therefore
240 considered to be a trace field as defined in [RFC5321], and all of
241 the related definitions in that document apply.
243 Relative ordering of different trace header fields (the ARC sets,
244 DKIM, Received, etc.) is unimportant for this specification. In
245 general, trace header fields, such as ARC, SHOULD be added at the top
246 of the email header fields, but receivers MUST be able to process the
247 header fields from wherever they are found in the message header.
248 Ordering amongst the individual ARC header fields and sets is
249 specified below and MUST be followed for proper canonicalized signing
250 and evaluation.
252 5.1. Description of the New Header Fields
254 5.1.1. ARC-Seal
256 ARC-Seal is a Structured Header Field as defined in Internet Message
257 Format ([RFC5322]). All of the related definitions in that document
258 apply.
260 The ARC-Seal makes use of Tag=Value Lists as defined in [RFC6376],
261 Section 3.2.
263 The value of the header field consists of an authentication sequence
264 identifier, and a series of statements and supporting data. The
265 statements indicate relevant data about the signing of the ARC set.
266 The header field can appear more than once in a single message, but
267 each instance MUST have a unique "i=" value.
269 The ARC-Seal header field includes a digital signature of all
270 preceding ARC message header fields on the message.
272 5.1.1.1. Tags in the ARC-Seal Header Field Value
274 The following tags are the only supported tags for an ARC-Seal field.
275 All of them MUST be present. Unknown tags MUST be ignored and do not
276 affect the validity of the header.
278 o a = hash algorithm; syntax is the same as the "a=" tag defined in
279 Section 3.5 of [RFC6376];
281 o b = digital signature; syntax is the same as the "b=" tag defined
282 in Section 3.5 of [RFC6376];
284 o cv = chain validation status: valid values:
286 * 'none' = no pre-existing chain;
288 * 'fail' = the chain as received does not validate; or
290 * 'pass' = valid chain received.
292 o d = domain for key; syntax is the same as the "d=" tag defined in
293 Section 3.5 of [RFC6376];
295 o i = "instance" or sequence number; monotonically increasing at
296 each "sealing" entity, beginning with '1', may not exceed '1024'
298 o s = selector for key; syntax is the same as the "s=" tag defined
299 in Section 3.5 of [RFC6376];
301 o t = timestamp; syntax is the same as the "t=" tag defined in
302 Section 3.5 of [RFC6376].
304 5.1.1.2. Differences between DKIM-Signature and ARC-Seal
306 No 'bh' value is defined for ARC-Seal, since only message header
307 fields are ever signed by the ARC-Seal.
309 ARC-Seal does not use the 'h' tag (the list of signed header fields)
310 that is defined for DKIM-Signatures because the list of applicable
311 header fields is fully determined by the construction rules (see
312 Section 5.1.1.3).
314 ARC-Seal does not use the 'c' (canonicalization) tag because only
315 'relaxed' canonicalization [RFC6376] is allowed for ARC-Seal header
316 field canonicalization.
318 5.1.1.3. Deterministic 'h' Value for ARC-Seal
320 In this section, the term "scope" is used to indicate those header
321 fields signed by an ARC-Seal header field. A number in parentheses
322 indicates the instance of that field, starting at 1. The suffix "-
323 no-b" is used with an ARC-Seal field to indicate that its "b" field
324 is empty at the time the signature is computed, as described in
325 Section 3.5 of [RFC6376]. "AAR" refers to ARC-Authentication-
326 Results, "AMS" to ARC- Message-Signature, "AS" to ARC-Seal, and "ASB"
327 to an ARC-Seal with an empty "b" tag.
329 Generally, the scope of an ARC set for a message containing "n" ARC
330 sets is the concatenation of the following, for x (instance number)
331 from 1 to n:
333 o AAR(x);
334 o AMS(x);
336 o ASB(x) if x = n, else AS(x)
338 Thus for a message with no seals (i.e., upon injection), the scope of
339 the first ARC set is AAR(1):AMS(1):ASB(1). The ARC set thus
340 generated would produce a first ARC-Seal with a "b" value. The next
341 ARC set would include in its signed content the prior scope, so it
342 would have a scope of AAR(1):AMS(1):AS(1):AAR(2):AMS(2):ASB(2).
344 Note: Typically header field sets appear within the header in
345 descending instance order.
347 5.1.1.4. Computing the 'b' Tag Value for ARC-Seal
349 The ARC-Seal generation process mirrors the procedure used for DKIM-
350 Signature fields described in Section 5 of [RFC6376] in that it is at
351 first generated with empty "b" field for the purpose of signature
352 generation, and then the "b" value is added just prior to adding the
353 ARC-Seal field to the message.
355 In particular, signing calculation MUST be done in bottom-up order as
356 specified in Section 5.4.2 of [RFC6376] and as illustrated above
357 Section 5.1.1.3.
359 5.1.1.5. Determining the 'cv' Tag Value for ARC-Seal
361 In order for a series of ARC sets to be considered valid, the
362 following statements MUST be satisfied:
364 1. All ARC-Seal header fields MUST validate;
366 2. All ARC-Seal header fields MUST have a chain value (cv=) status
367 of "pass" (except the first which MUST be "none"); and
369 3. The newest (highest instance number (i=)) AMS header field MUST
370 validate.
372 5.1.1.5.1. Pseudocode to Determine Chain Value Status:
374 In the algorith below, a "hop" is represented by the ARC set bearing
375 a particular instance number. The number of hops is the same as the
376 highest instance number found in the ARC sets, or 0 (zero) if there
377 are no ARC sets found within the header.
379 "Success" means that the signature found in the referenced header
380 validates when against the content which was signed.
382 if num_hops == 0:
383 return "none"
384 else:
385 if validate(latest_hop.AMS) != success:
386 return "fail"
388 for each hop (from highest instance to lowest):
389 if (hop_num > 1 and hop.ARC-Seal.cv == "pass") or
390 (hop_num == 1 and hop.ARC-Seal.cv == "none"):
391 if validate(hop.ARC-Seal) == success:
392 next
393 else:
394 return "fail"
396 return "pass"
398 5.1.2. ARC-Message-Signature
400 The ARC-Message-Signature header field is a special variant of a
401 DKIM-Signature [RFC6376], using only the relaxed header
402 canonicalization rules specified in [RFC6376].
404 The ARC-Message-Signature header field can appear multiple times in a
405 single message but each instance MUST have a unique "i=" value.
407 5.1.2.1. Differences between DKIM-Signature and ARC-Message-Signature
409 5.1.2.1.1. Header Fields Eligible For ARC-Message-Signature Inclusion
411 Participants may include any other header fields within the scope of
412 the ARC-Message-Signature signature except that they MUST NOT include
413 ARC-Seal headers fields. In particular, including all DKIM-Signature
414 header fields and all ARC-Authentication-Results header fields is
415 RECOMMENDED. The advice regarding headers to include or avoid for
416 ARC-Message-Signature is otherwise identical to that specified in
417 section 5.4 of [RFC6376].
419 5.1.2.1.2. Implicit Canonicalization: 'c'
421 The ARC-Message-Signature header field MUST be created using the
422 relaxed header and body canonicalization rules defined in
423 Section 3.4.2 of [RFC6376].
425 5.1.2.1.3. "Instance" 'i' Tag Value
427 Contrary to DKIM, the 'i' tag for ARC-Message-Signature identifies
428 the sequential instance of the field, thus indicating that it is part
429 of a particular ARC set. That is, an ARC-Message-Signature, ARC-
430 Seal, and ARC-Authentication-Results all bearing an "i=" tag with the
431 same value are part of the same ARC set (see Section 5.1.1.1).
433 5.1.2.1.4. 'v' Tag Value
435 There is no "v" tag for ARC-Message-Signature.
437 5.1.2.2. Computing the 'b' Tag Value for ARC-Message-Signature
439 As with DKIM-Signature and ARC-Seal header fields, the "b" tag of the
440 ARC-Message-Signature is empty until the signature is actually
441 computed, and only then is it added to the header field, before
442 affixing the ARC-Message-Signature to the message.
444 As with ARC-Seal and DKIM-Signature header fields, the order of
445 header fields signed MUST be done in bottom-up order.
447 5.1.3. ARC-Authentication-Results
449 ARC-Authentication-Results is a direct copy of the Authentication-
450 Results header field [RFC7601] created for archival purposes by the
451 each MTA outside of the trust boundary of the originating system
452 which is contributing to the chain of ARC header fields. The
453 corresponding instance ("i=") tag value MUST be prefixed to the
454 Authentication-Results.
456 The value of the header field (after removing comments) consists of
457 an instance identifier, an authentication identifier, and then a
458 series of statements and supporting data, as described in [RFC7601].
459 The header field can appear multiple times in a single message but
460 each instance MUST have a unique "i=" value.
462 5.1.3.1. 'i' Tag Value
464 ARC-Authentication-Results requires inclusion of an "i=" tag before
465 the "authserv-id" which indicates the ARC set to which it belongs as
466 described in the previous section (see Section 5.1.1.1).
468 5.2. Constructing the ARC-Seal Set
470 The ARC-Seal is built in the same fashion as the analogous DKIM-
471 Signature [RFC6376], using the relaxed header canonicalization rules
472 specified in that document but with a strict ordering component for
473 the header fields covered by the cryptographic signature:
475 1. The ARC sets MUST be ordered in descending instance (i=) order.
477 2. The referenced ARC-Message-Signatures (matching i= value) MUST
478 immediately follow the ARC-Seal instance which included the
479 reference.
481 3. The associated ARC-Authentication-Results header field (matching
482 i= value) MUST be the last item in the list for each set of ARC
483 header fields.
485 Thus, when prefixing ARC header fields to the existing header,
487 1. the AAR header would be prefixed first; then
489 2. the AMS would be calculated and prefixed;
491 3. lastly the AS would be calculated and prefixed.
493 The ARC-Message-Signature field(s) MUST not include any of the ARC-
494 Seal header field(s) (from prior ARC sets) in their signing scope in
495 order maintain a separation of responsibilities. When adding an ARC-
496 Authentication-Results header field, it MUST be added before
497 computing the ARC-Message-Signature. When "sealing" the message, an
498 operator MUST create and attach the ARC-Message-Signature before the
499 ARC-Seal in order to reference it and embed the ARC-Message-Signature
500 within the ARC-Seal signature scope.
502 Each ARC-Seal is connected to its respective ARC-Message-Signature
503 and ARC-Authentication-Results through the common value of the "i="
504 tag.
506 5.2.1. Handling Violations in the ARC Sets
508 When ordering the ARC header field sets, if there are gross
509 violations of this protocol (e.g., such as duplicated instance
510 numbers), such header field set(s) MUST be ordered as follows when
511 analyzing for validity or subsequent signing:
513 o Within each set, header fields are sorted as specified in
514 Section 5.2; then
516 o Any ARC sets that are complete duplicates are removed - leaving
517 only one instance of each unique ARC set; then
519 o Any remaining order dependencies between sets are be ordered as
520 follows:
522 1. (First) By descending order of i=; then
523 2. (Second) By descending order of t= (from the ARC-Seal header
524 field within the set); then
526 3. (Finally) By ascending US-ASCII [RFC1345] sort order for the
527 entire canonicalized header field set
529 The intent of specifying this ordering is to allow downstream message
530 handlers to add their own ARC sets in a deterministic manner and to
531 provide some resiliance against misbehaving downstream MTAs.
533 5.3. Key Management and Binding
535 The public keys for ARC header fields follow the same requirements
536 and semantics as those for DKIM-Signatures, described in Section 3.6
537 of [RFC6376]. Operators may use distinct selectors for the ARC
538 header fields at their own discretion.
540 5.3.1. Namespace
542 All ARC-related keys are stored in the same namespace as DKIM keys
543 [RFC6376]: "_domainkey" specifically by adding the "._domainkey"
544 suffix to the name of the key (the "selector"). For example, given
545 an ARC-Seal (or ARC-Message-Signature) field of a "d=" tag value of
546 "example.com" and an "s=" value of "foo.bar", the DNS query seeking
547 the public key will a query at the name
548 "foo.bar._domainkey.example.com".
550 6. Usage
552 For a more thorough treatment of the recommended usage of the ARC
553 header fields for both intermediaries and end receivers, please
554 consult [ARC-USAGE].
556 6.1. Participation
558 The inclusion of additional ARC sets is to be done whenever a trust
559 boundary is crossed, and especially when prior DKIM-Signatures might
560 not survive the handling being performed such as some mailing lists
561 that modify the content of messages or some gateway transformations.
562 Note that trust boundaries might or might not exactly correspond with
563 ADMD boundaries.
565 Each participating ADMD MUST validate the preceding ARC set as a part
566 of asserting their own seal. Even if the set is determined to be
567 invalid, a participating ADMD SHOULD apply their own seal because
568 this can help in analysis of breakage points in the chain.
570 6.2. Relationship between DKIM Signatures and ARC Headers
572 ARC-aware DKIM signers do not DKIM-sign any ARC header fields.
574 6.3. Validating the ARC Set of Header Fields
576 Determining the validity of a chain of ARC sets is defined above in
577 Section 5.1.1.5. Validation failures MUST be indicated with a "cv="
578 tag value of 'fail' when attaching a subsequent ARC-Seal header
579 field.
581 6.4. ARC Set Validity
583 6.4.1. Assessing Chain Validity Violations
585 There are a wide variety of ways in which the ARC set of header
586 fields can be broken. Receivers need to be wary of ascribing motive
587 to such breakage although patterns of common behaviour may provide
588 some basis for adjusting local policy decisions.
590 This specification is exclusively focused on well-behaved,
591 participating intermediaries that result in a valid chain of ARC-
592 related header fields. The value of such a well-formed, valid chain
593 needs to be interpreted with care since malicious content can be
594 easily introduced by otherwise well-intended senders through machine
595 or account compromises. All normal content-based analysis still
596 needs to be performed on any messages bearing a valid chain of ARC
597 header sets.
599 6.4.2. Responding to ARC Validity Violations
601 If a receiver determines that the ARC set of header fields has is
602 invalid, the receiver MAY signal the breakage through the extended
603 SMTP response code 5.7.7 [RFC3463] "message integrity failure"
604 [ENHANCED-STATUS] and corresponding SMTP response code.
606 6.4.3. Recording the Results of ARC Evaluation
608 Receivers MAY add an "arc=pass" or "arc=fail" method annotation into
609 a locally-affixed Authentication-Results [RFC7601] header field.
611 6.4.4. Output Data Points from ARC Evaluation
613 The evaluation of a series of ARC sets results in the following data
614 which MAY be used to inform local-policy decisions:
616 o A list of the "d=" domains found in the validated (all) ARC-Seal
617 header fields;
619 o The "d=" domain found in the most recent (highest instance number)
620 AMS header field (since that is the only one necessarily
621 validated)
623 6.4.5. Reporting ARC Effects for DMARC Local Policy
625 Receivers SHOULD indicate situations in which ARC evaluation
626 influenced the results of their local policy determination. DMARC
627 reporting of ARC-informed decisions is augmented by adding a
628 local_policy comment explanation as follows:
630
631 delivered
632 fail
633 fail
634
635 local_policy
636 arc=pass ams=d1.example d=d1.example,d2.example
637
638
640 7. Privacy Considerations
642 The ARC-Seal chain provides a verifiable record of the handlers for a
643 message. Anonymous remailers will probably not find this to match
644 their operating goals.
646 8. IANA Considerations
648 This specification adds three new header fields as defined below.
650 8.1. Authentication-Results Method Registry Update
652 This draft adds one item to the IANA "Email Authentication Methods"
653 registry:
655 o Method : arc
657 Defined: [I-D.ARC]
659 ptype: header
661 Property: chain evaluation result
663 Value: chain evaluation result status (see Section 5.1.1.1)
665 Status: active
666 Version: 1
668 8.2. Definitions of the ARC header fields
670 This specification adds three new header fields to the "Permanent
671 Message Header Field Registry", as follows:
673 o Header field name: ARC-Seal
675 Applicable protocol: mail
677 Status: draft
679 Author/Change controller: OAR-Dev Group
681 Specification document(s): [I-D.ARC]
683 Related information: [RFC6376]
685 o Header field name: ARC-Message-Signature
687 Applicable protocol: mail
689 Status: draft
691 Author/Change controller: OAR-Dev Group
693 Specification document(s): [I-D.ARC]
695 Related information: [RFC6376]
697 o Header field name: ARC-Authentication-Results
699 Applicable protocol: mail
701 Status: standard
703 Author/Change controller: IETF
705 Specification document(s): [I-D.ARC]
707 Related information: [RFC7601]
709 9. Security Considerations
711 The Security Considerations of [RFC6376] and [RFC7601] apply directly
712 to this specification.
714 Inclusion of ARC sets in the header of emails may cause problems for
715 some older or more constrained MTAs if they are unable to accept the
716 greater size of the header.
718 Operators who receive a message bearing N ARC sets has to complete
719 N+1 DNS queries to evaluate the chain (barring DNS redirection
720 mechanisms which can increase the lookups for a given target value).
721 This has at least two effects:
723 1. An attacker can send a message to an ARC partipant with a
724 concocted sequence of ARC sets bearing the domains of intended
725 victims, and all of them will be queried by the participant until
726 a failure is discovered.
728 2. DKIM only does one DNS check per signature, while this one can do
729 many. Absent caching, slow DNS responses can cause SMTP
730 timeouts; this could be exploited as a DoS attack.
732 9.1. Message Content Suspicion
734 Recipients are cautioned to treat messages bearing ARC sets with the
735 same suspicion that they apply to all other email messages. This
736 includes appropriate content scanning and other checks for
737 potentially malicious content. The handlers which are identified
738 within the ARC-Seal chain may be used to provide input to local
739 policy engines in cases where the sending system's DKIM-Signature
740 does not validate.
742 10. References
744 10.1. Normative References
746 [RFC1345] Simonsen, K., "Character Mnemonics and Character Sets",
747 RFC 1345, DOI 10.17487/RFC1345, June 1992,
748 .
750 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
751 Requirement Levels", BCP 14, RFC 2119,
752 DOI 10.17487/RFC2119, March 1997,
753 .
755 [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and
756 Functions", RFC 2142, DOI 10.17487/RFC2142, May 1997,
757 .
759 [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS
760 Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999,
761 .
763 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes",
764 RFC 3463, DOI 10.17487/RFC3463, January 2003,
765 .
767 [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys
768 Identified Mail (DKIM)", RFC 4686, DOI 10.17487/RFC4686,
769 September 2006, .
771 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
772 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
773 DOI 10.17487/RFC5226, May 2008,
774 .
776 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
777 Specifications: ABNF", STD 68, RFC 5234,
778 DOI 10.17487/RFC5234, January 2008,
779 .
781 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
782 DOI 10.17487/RFC5321, October 2008,
783 .
785 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
786 DOI 10.17487/RFC5322, October 2008,
787 .
789 [RFC5585] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys
790 Identified Mail (DKIM) Service Overview", RFC 5585,
791 DOI 10.17487/RFC5585, July 2009,
792 .
794 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
795 DOI 10.17487/RFC5598, July 2009,
796 .
798 [RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker,
799 "DomainKeys Identified Mail (DKIM) Development,
800 Deployment, and Operations", RFC 5863,
801 DOI 10.17487/RFC5863, May 2010,
802 .
804 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
805 "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
806 RFC 6376, DOI 10.17487/RFC6376, September 2011,
807 .
809 [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and
810 Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377,
811 September 2011, .
813 [RFC6651] Kucherawy, M., "Extensions to DomainKeys Identified Mail
814 (DKIM) for Failure Reporting", RFC 6651,
815 DOI 10.17487/RFC6651, June 2012,
816 .
818 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
819 Authorizing Use of Domains in Email, Version 1", RFC 7208,
820 DOI 10.17487/RFC7208, April 2014,
821 .
823 [RFC7601] Kucherawy, M., "Message Header Field for Indicating
824 Message Authentication Status", RFC 7601,
825 DOI 10.17487/RFC7601, August 2015,
826 .
828 10.2. Informative References
830 [ARC-USAGE]
831 Jones, S., Adams, T., Rae-Grant, J., and K. Andersen,
832 "Recommended Usage of the ARC Headers", April 2016,
833 .
835 [DMARC-INTEROP]
836 Martin, F., Lear, E., Draegen, T., Zwicky, E., and K.
837 Andersen, "Interoperability Issues Between DMARC and
838 Indirect Email Flows", January 2016,
839 .
842 [ENHANCED-STATUS]
843 "IANA SMTP Enhanced Status Codes", n.d.,
844 .
847 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
848 Message Authentication, Reporting, and Conformance
849 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
850 .
852 10.3. URIs
854 [1] mailto:arc-discuss@dmarc.org
856 Appendix A. Appendix A - Example Usage
858 [[ TODO [-03]: update these examples ]]
860 A.1. Example 1: Simple mailing list
862 A.1.1. Here's the message as it exits the Origin:
864 Return-Path:
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/vpVBRJnD4I2weEIyYijrvQw
876 bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl
877 gotsX4RkbNcUhlfnoQ0p+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@dmarc.org
882 Subject: Example 1
884 Hey gang,
885 This is a test message.
886 --J.
888 A.1.2. Message is then received at example.org
890 A.1.2.1. Example 1, Step A: Message forwarded to list members
892 Processing at example.org:
894 o example.org performs authentication checks
896 o No previous Auth-Results or ARC-Seal headers are present
898 o example.org adds ARC-Auth-Results header
900 o example.org adds Received: header
902 o example.org adds a ARC-Seal header
903 Here's the message as it exits example.org:
905 Return-Path:
906 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
907 s=seal2015; d=example.org; cv=none;
908 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
909 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
910 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
911 ARC-Message-Signature: i=1; a=rsa-sha256;
912 d=example.org; s=clochette; t=1421363105;
913 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
914 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
915 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
916 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1F5
917 vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+m4bw
918 a6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
919 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
920 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
921 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
922 (envelope-from jqd@d1.example)
923 ARC-Authentication-Results: i=1; lists.example.org;
924 spf=pass smtp.mfrom=jqd@d1.example;
925 dkim=pass (1024-bit key) header.i=@d1.example;
926 dmarc=pass
927 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
928 (authenticated bits=0)
929 by segv.d1.example with ESMTP id t0FN4a8O084569;
930 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
931 (envelope-from jqd@d1.example)
932 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
933 s=20130426; t=1421363082;
934 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
935 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
936 Content-Transfer-Encoding;
937 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
938 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
939 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
940 Message-ID: <54B84785.1060301@d1.example>
941 Date: Thu, 14 Jan 2015 15:00:01 -0800
942 From: John Q Doe
943 To: arc@example.org
944 Subject: [Lists] Example 1
946 Hey gang,
947 This is a test message.
948 --J.
950 A.1.3. Example 1: Message received by Recipient
952 Let's say that the Recipient is example.com
954 Processing at example.com:
956 o example.com performs usual authentication checks
958 o example.com adds Auth-Results: header, Received header
960 o Determines that message fails DMARC
962 o Checks for ARC-Seal: header; finds one
964 o Validates the signature in the ARC-Seal: header, which covers the
965 ARC-Authentication-Results: header
967 o example.com can use the ARC-Authentication-Results values or
968 verify the DKIM-Signature from lists.example.org
970 Here's what the message looks like at this point:
972 Return-Path:
973 Received: from example.org (example.org [208.69.40.157])
974 by clothilde.example.com with ESMTP id
975 d200mr22663000ykb.93.1421363207
976 for ; Thu, 14 Jan 2015 15:02:40 -0800 (PST)
977 Authentication-Results: clothilde.example.com; spf=fail
978 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
979 header.i=@example.org; dmarc=fail; arc=pass
980 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
981 s=seal2015; d=example.org; cv=none;
982 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
983 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
984 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
985 ARC-Message-Signature: i=1; a=rsa-sha256;
986 d=example.org; s=clochette; t=1421363105;
987 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
988 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
989 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
990 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
991 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
992 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
993 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
994 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
995 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
996 (envelope-from jqd@d1.example)
997 ARC-Authentication-Results: i=1; lists.example.org;
998 spf=pass smtp.mfrom=jqd@d1.example;
999 dkim=pass (1024-bit key) header.i=@d1.example;
1000 dmarc=pass
1001 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1002 (authenticated bits=0)
1003 by segv.d1.example with ESMTP id t0FN4a8O084569;
1004 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1005 (envelope-from jqd@d1.example)
1006 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
1007 s=20130426; t=1421363082;
1008 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1009 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
1010 Content-Transfer-Encoding;
1011 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw
1012 bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl
1013 gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1014 Message-ID: <54B84785.1060301@d1.example>
1015 Date: Thu, 14 Jan 2015 15:00:01 -0800
1016 From: John Q Doe
1017 To: arc@example.org
1018 Subject: [Lists] Example 1
1020 Hey gang,
1021 This is a test message.
1022 --J.
1024 A.2. Example 2: Mailing list to forwarded mailbox
1026 A.2.1. Here's the message as it exits the Origin:
1028 Return-Path:
1029 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1030 (authenticated bits=0)
1031 by segv.d1.example with ESMTP id t0FN4a8O084569;
1032 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1033 (envelope-from jqd@d1.example)
1034 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
1035 s=20130426; t=1421363082;
1036 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1037 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
1038 Content-Transfer-Encoding;
1039 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw
1040 bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl
1041 gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1042 Message-ID: <54B84785.1060301@d1.example>
1043 Date: Thu, 14 Jan 2015 15:00:01 -0800
1044 From: John Q Doe
1045 To: arc@example.org
1046 Subject: Example 1
1048 Hey gang,
1049 This is a test message.
1050 --J.
1052 A.2.2. Message is then received at example.org
1054 A.2.2.1. Example 2, Step A: Message forwarded to list members
1056 Processing at example.org:
1058 o example.org performs authentication checks
1060 o example.org applies standard DKIM signature
1062 o No previous Auth-Results or ARC-Seal headers are present
1064 o example.org adds ARC-Auth-Results header
1066 o example.org adds usual Received: header
1068 o example.org adds a ARC-Seal header
1070 Here's the message as it exits Step A:
1072 Return-Path:
1073 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1074 s=seal2015; d=example.org; cv=none;
1075 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
1076 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
1077 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1078 ARC-Message-Signature: i=1; a=rsa-sha256;
1079 d=example.org; s=clochette; t=1421363105;
1080 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
1081 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
1082 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
1083 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
1084 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
1085 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
1086 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
1087 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
1088 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
1089 (envelope-from jqd@d1.example)
1090 ARC-Authentication-Results: i=1; lists.example.org;
1091 spf=pass smtp.mfrom=jqd@d1.example;
1092 dkim=pass (1024-bit key) header.i=@d1.example;
1093 dmarc=pass
1094 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1095 (authenticated bits=0)
1096 by segv.d1.example with ESMTP id t0FN4a8O084569;
1097 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1098 (envelope-from jqd@d1.example)
1099 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
1100 s=20130426; t=1421363082;
1101 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1102 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
1103 Content-Transfer-Encoding;
1104 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
1105 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
1106 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1107 Message-ID: <54B84785.1060301@d1.example>
1108 Date: Thu, 14 Jan 2015 15:00:01 -0800
1109 From: John Q Doe
1110 To: arc@example.org
1111 Subject: [Lists] Example 1
1113 Hey gang,
1114 This is a test message.
1115 --J.
1117 A.2.2.2. Example 2, Step B: Message from list forwarded
1119 The message is delivered to a mailbox at gmail.com
1120 Processing at gmail.com:
1122 o gmail.com performs usual authentication checks
1124 o gmail.com adds Auth-Results: and Received: header
1126 o Determines that message fails DMARC
1128 o Checks for ARC-Seal: header; finds one
1130 o Validates the signature in the ARC-Seal: header, which covers the
1131 ARC-Authentication-Results: header
1133 o Uses the ARC-Auth-Results: values, but:
1135 o Instead of delivering message, prepares to forward message per
1136 user settings
1138 o Applies usual DKIM signature
1140 o gmail.com adds it's own ARC-Seal: header, contents of which are
1142 * version
1144 * sequence number ("i=2")
1146 * hash algorithm (SHA256 as example)
1148 * timestamp ("t=")
1150 * selector for key ("s=notary01")
1152 * domain for key ("d=gmail.com")
1154 * headers included in hash ("h=ARC-Authentication-Results:ARC-
1155 Seal")
1157 * Note: algorithm requires only ARC-Seals with lower sequence #
1158 be included, in ascending order
1160 * signature of the header hash
1162 Here's what the message looks like at this point:
1164 Return-Path:
1165 ARC-Seal: i=2; a=rsa-sha256; t=1421363253;
1166 s=notary01; d=gmail.com; cv=pass;
1167 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDWR
1168 YbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/sut
1169 txO+RRNr0fCFw==
1170 ARC-Message-Signature: i=2; a=rsa-sha256;
1171 d=gmail.com; s=20120806;
1172 h=mime-version:content-type:x-original-sender:
1173 x-original-authentication-results:precedence:mailing-list:
1174 list-id:list-post:list-help:list-archive:sender:reply-to:
1175 list-unsubscribe:DKIM-Signature;
1176 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=;
1177 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1178 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1179 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBmfhS
1180 LF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJRFeM
1181 KdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwDBJtXw
1182 bQoZyRtb6X6q0mYaszUB8kw==
1183 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10
1184 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST)
1185 Authentication-Results: i=2; gmail.com; spf=fail
1186 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
1187 header.i=@example.org; dmarc=fail; arc=pass
1188 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1189 s=seal2015; d=example.org; cv=none:
1190 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1191 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1192 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1193 ARC-Message-Signature: i=1; a=rsa-sha256;
1194 d=example.org; s=clochette; t=1421363105;
1195 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
1196 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
1197 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
1198 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
1199 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
1200 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
1201 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
1202 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
1203 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
1204 (envelope-from jqd@d1.example)
1205 ARC-Authentication-Results: i=1; lists.example.org;
1206 spf=pass smtp.mfrom=jqd@d1.example;
1207 dkim=pass (1024-bit key) header.i=@d1.example;
1208 dmarc=pass
1209 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1210 (authenticated bits=0)
1211 by segv.d1.example with ESMTP id t0FN4a8O084569;
1212 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1213 (envelope-from jqd@d1.example)
1214 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
1215 s=20130426; t=1421363082;
1216 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1217 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
1218 Content-Transfer-Encoding;
1219 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
1220 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
1221 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1222 Message-ID: <54B84785.1060301@d1.example>
1223 Date: Thu, 14 Jan 2015 15:00:01 -0800
1224 From: John Q Doe
1225 To: arc@example.org
1226 Subject: [Lists] Example 1
1228 Hey gang,
1229 This is a test message.
1230 --J.
1232 A.2.3. Example 2: Message received by Recipient
1234 Let's say that the Recipient is example.com
1235 Processing at example.com:
1237 o example.com performs usual authentication checks
1239 o example.com adds Auth-Results: header, Received header
1241 o Determines that message fails DMARC
1243 o Checks for ARC-Seal: header; finds two
1245 o Validates the signature in the highest numbered ("i=2") ARC-Seal:
1246 header, which covers all previous ARC-Seal: and ARC-
1247 Authentication-Results: headers
1249 o Validates the other ARC-Seal header ("i=1"), which covers the ARC-
1250 Authentication-Results: header
1252 o example.com uses the ARC-Authentication-Results: values
1254 Here's what the message looks like at this point:
1256 Return-Path:
1257 Received: from mail-ob0-f188.google.com (mail-ob0-f188.google.com
1258 [208.69.40.157]) by clothilde.example.com with ESMTP id
1259 d200mr22663000ykb.93.1421363268
1260 for ; Thu, 14 Jan 2015 15:03:15 -0800 (PST)
1262 Authentication-Results: clothilde.example.com; spf=fail
1263 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
1264 header.i=@gmail.com; dmarc=fail; arc=pass
1265 ARC-Seal: i=2; a=rsa-sha256; t=1421363253;
1266 s=notary01; d=gmail.com; cv=pass;
1267 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDWR
1268 YbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/sut
1269 txO+RRNr0fCFw==
1270 ARC-Message-Signature: i=2; a=rsa-sha256;
1271 d=gmail.com; s=20120806;
1272 h=mime-version:content-type:x-original-sender:
1273 x-original-authentication-results:precedence:mailing-list:
1274 list-id:list-post:list-help:list-archive:sender:reply-to:
1275 :list-unsubscribe:DKIM-Signature;
1276 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=;
1277 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1278 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1279 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBmfhS
1280 LF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJRFeM
1281 KdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwDBJtXw
1282 bQoZyRtb6X6q0mYaszUB8kw==
1283 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10
1284 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST)
1285 Authentication-Results: i=2; gmail.com; spf=fail
1286 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
1287 header.i=@example.org; dmarc=fail; arc=pass
1288 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1289 s=seal2015; d=example.org; cv=none;
1290 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1291 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1292 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1293 ARC-Message-Signature: i=1; a=rsa-sha256;
1294 d=example.org; s=clochette; t=1421363105;
1295 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
1296 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
1297 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
1298 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
1299 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
1300 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
1301 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
1302 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
1303 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
1304 (envelope-from jqd@d1.example)
1305 ARC-Authentication-Results: i=1; lists.example.org;
1306 spf=pass smtp.mfrom=jqd@d1.example;
1307 dkim=pass (1024-bit key) header.i=@d1.example;
1308 dmarc=pass
1309 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1310 (authenticated bits=0)
1311 by segv.d1.example with ESMTP id t0FN4a8O084569;
1312 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1313 (envelope-from jqd@d1.example)
1314 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
1315 s=20130426; t=1421363082;
1316 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1317 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
1318 Content-Transfer-Encoding;
1319 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
1320 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
1321 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1322 Message-ID: <54B84785.1060301@d1.example>
1323 Date: Thu, 14 Jan 2015 15:00:01 -0800
1324 From: John Q Doe
1325 To: arc@example.org
1326 Subject: [Lists] Example 1
1328 Hey gang,
1329 This is a test message.
1330 --J.
1332 A.3. Example 3: Mailing list to forwarded mailbox with source
1334 A.3.1. Here's the message as it exits the Origin:
1336 Return-Path:
1337 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1338 (authenticated bits=0)
1339 by segv.d1.example with ESMTP id t0FN4a8O084569;
1340 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1341 (envelope-from jqd@d1.example)
1342 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1343 s=origin2015; d=d1.example; cv=none;
1344 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61T
1345 X6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69EU
1346 8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1347 ARC-Message-Signature: i=1; a=rsa-sha256;
1348 d=d1.example; s=20130426; t=1421363082;
1349 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1350 h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding;
1351 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrv
1352 Qwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3
1353 TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1354 Message-ID: <54B84785.1060301@d1.example>
1355 Date: Thu, 14 Jan 2015 15:00:01 -0800
1356 From: John Q Doe
1357 To: arc@example.org
1358 Subject: Example 1
1360 Hey gang,
1361 This is a test message.
1362 --J.
1364 A.3.2. Message is then received at example.org
1366 A.3.2.1. Example 3, Step A: Message forwarded to list members with
1367 source
1369 Processing at example.org:
1371 o example.org performs authentication checks
1373 o example.org applies standard DKIM signature
1375 o Checks for ARC-Seal: header; finds one (i=1)
1377 o Validates the signature in the ARC-Seal (i=1): header, which
1378 covers the d1.example ARC-Message-Signature: header
1380 o example.org adds ARC-Auth-Results header
1382 o example.org adds usual Received: header
1383 o example.org adds a DKIM-Signature
1385 o example.org adds a ARC-Seal header, contents of which are
1387 * sequence number ("i=2")
1389 * hash algorithm (SHA256 as example)
1391 * timestamp ("t=")
1393 * chain validity ("cv=")
1395 * selector for key ("s=seal2015")
1397 * domain for key ("d=example.org")
1399 * signature ("b=")
1401 Here's the message as it exits Step A:
1403 Return-Path:
1404 ARC-Seal: i=2; a=rsa-sha256; t=1421363107;
1405 s=seal2015; d=example.org; cv=pass;
1406 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
1407 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
1408 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1409 ARC-Message-Signature: i=2; a=rsa-sha256;
1410 d=example.org; s=clochette; t=1421363105;
1411 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
1412 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
1413 List-Help:List-Subscribe:From:Reply-To:DKIM-Signature;
1414 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
1415 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
1416 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
1417 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
1418 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
1419 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
1420 (envelope-from jqd@d1.example)
1421 ARC-Authentication-Results: i=2; lists.example.org;
1422 spf=pass smtp.mfrom=jqd@d1.example;
1423 dkim=pass (1024-bit key) header.i=@d1.example;
1424 dmarc=pass
1425 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1426 (authenticated bits=0)
1427 by segv.d1.example with ESMTP id t0FN4a8O084569;
1428 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1429 (envelope-from jqd@d1.example)
1430 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1431 s=origin2015; d=d1.example; cv=none;
1432 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1433 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1434 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1435 ARC-Message-Signature: i=1; a=rsa-sha256;
1436 d=d1.example; s=20130426; t=1421363082;
1437 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1438 h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding;
1439 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
1440 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
1441 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1442 Message-ID: <54B84785.1060301@d1.example>
1443 Date: Thu, 14 Jan 2015 15:00:01 -0800
1444 From: John Q Doe
1445 To: arc@example.org
1446 Subject: [Lists] Example 1
1448 Hey gang,
1449 This is a test message.
1450 --J.
1452 A.3.2.2. Example 3, Step B: Message from list forwarded with source
1454 The message is delivered to a mailbox at gmail.com
1455 Processing at gmail.com:
1457 o gmail.com performs usual authentication checks
1459 o gmail.com adds Auth-Results: and Received: header
1461 o Determines that message fails DMARC
1463 o Checks for ARC-Seal: header; finds two
1465 o Validates the signature in the ARC-Seal (i=2): header, which
1466 covers the ARC-Authentication-Results: header
1468 o Validates the signature in the ARC-Seal (i=1): header, which
1469 covers the d1.example ARC-Message-Signature: header
1471 o Uses the ARC-Auth-Results: values, but:
1473 o Instead of delivering message, prepares to forward message per
1474 user settings
1476 o Applies usual DKIM signature
1478 o gmail.com adds it's own ARC-Seal: header, contents of which are
1480 * version
1482 * sequence number ("i=2")
1484 * hash algorithm (SHA256 as example)
1486 * timestamp ("t=")
1488 * selector for key ("s=notary01")
1490 * domain for key ("d=gmail.com")
1492 * Note: algorithm requires only ARC-Seals with lower sequence #
1493 be included, in ascending order
1495 * signature of the chain
1497 Here's what the message looks like at this point:
1499 Return-Path:
1500 ARC-Seal: i=3; a=rsa-sha256; t=1421363253;
1501 s=notary01; d=gmail.com; cv=pass;
1502 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwD
1503 WRYbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF
1504 /suttxO+RRNr0fCFw==
1505 ARC-Message-Signature: i=3; a=rsa-sha256;
1506 d=gmail.com; s=20120806;
1507 h=mime-version:content-type:x-original-sender
1508 :x-original-authentication-results:precedence:mailing-list
1509 :list-id:list-post:list-help:list-archive:sender
1510 :list-unsubscribe:reply-to;
1511 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=;
1512 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
1513 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
1514 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBm
1515 fhSLF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJ
1516 RFeMKdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwD
1517 BJtXwbQoZyRtb6X6q0mYaszUB8kw==
1518 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10
1519 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST)
1520 Authentication-Results: i=3; gmail.com; spf=fail
1521 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
1522 header.i=@example.org; dmarc=fail; arc=pass
1523 ARC-Seal: i=2; a=rsa-sha256; t=1421363107;
1524 s=seal2015; d=example.org; cv=pass;
1525 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1526 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1527 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1528 ARC-Message-Signature: i=2; a=rsa-sha256;
1529 d=example.org; s=clochette; t=1421363105;
1530 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
1531 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
1532 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
1533 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1
1534 F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+
1535 m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
1536 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
1537 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
1538 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
1539 (envelope-from jqd@d1.example)
1540 ARC-Authentication-Results: i=2; lists.example.org;
1541 spf=pass smtp.mfrom=jqd@d1.example;
1542 dkim=pass (1024-bit key) header.i=@d1.example;
1543 dmarc=pass
1544 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1545 (authenticated bits=0)
1546 by segv.d1.example with ESMTP id t0FN4a8O084569;
1547 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1548 (envelope-from jqd@d1.example)
1549 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1550 s=origin2015; d=d1.example; cv=none;
1551 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1552 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1553 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1554 ARC-Message-Signature: i=1; a=rsa-sha256;
1555 d=d1.example; s=20130426; t=1421363082;
1556 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1557 h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding;
1558 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYij
1559 rvQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD
1560 4Gd3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1561 Message-ID: <54B84785.1060301@d1.example>
1562 Date: Thu, 14 Jan 2015 15:00:01 -0800
1563 From: John Q Doe
1564 To: arc@example.org
1565 Subject: [Lists] Example 1
1567 Hey gang,
1568 This is a test message.
1569 --J.
1571 A.3.3. Example 3: Message received by Recipient
1573 Let's say that the Recipient is example.com
1574 Processing at example.com:
1576 o example.com performs usual authentication checks
1578 o example.com adds Auth-Results: header, Received header
1580 o Determines that message fails DMARC
1582 o Checks for ARC-Seal: header; finds three
1584 o Validates the signature in the highest numbered ("i=2") ARC-Seal:
1585 header, which covers all previous ARC-Seal: and ARC-
1586 Authentication-Results: headers
1588 o Validates the other ARC-Seal header ("i=2"), which covers the ARC-
1589 Authentication-Results: header
1591 o Validates the other ARC-Seal header ("i=1"), which covers the
1592 d1.example ARC-Message-Signature: header
1594 o example.com uses the ARC-Authentication-Results: values
1595 Here's what the message looks like at this point:
1597 Return-Path:
1598 Received: from mail-ob0-f188.google.com (mail-ob0-f188.google.com
1599 [208.69.40.157]) by clothilde.example.com with ESMTP id
1600 d200mr22663000ykb.93.1421363268
1601 for ; Thu, 14 Jan 2015 15:03:15 -0800 (PST)
1602 Authentication-Results: clothilde.example.com; spf=fail
1603 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
1604 header.i=@gmail.com; dmarc=fail; arc=pass
1605 ARC-Seal: i=3; a=rsa-sha256; t=1421363253;
1606 s=notary01; d=gmail.com; cv=pass;
1607 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDW
1608 RYbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/s
1609 uttxO+RRNr0fCFw==
1610 ARC-Message-Signature: i=3; a=rsa-sha256;
1611 d=gmail.com; s=20120806;
1612 h=mime-version:content-type:x-original-sender
1613 :x-original-authentication-results:precedence
1614 :mailing-list:list-id:list-post:list-help:list-archive:sender
1615 :list-unsubscribe:reply-to;
1616 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=;
1617 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
1618 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
1619 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBm
1620 fhSLF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJ
1621 RFeMKdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwD
1622 BJtXwbQoZyRtb6X6q0mYaszUB8kw==
1623 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10
1624 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST)
1625 Authentication-Results: i=3; gmail.com; spf=fail
1626 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
1627 header.i=@example.org; dmarc=fail; arc=pass
1628 ARC-Seal: i=2; a=rsa-sha256; t=1421363107;
1629 s=seal2015; d=example.org; cv=pass;
1630 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
1631 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
1632 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1633 ARC-Message-Signature: i=2; a=rsa-sha256;
1634 d=example.org; s=clochette; t=1421363105;
1635 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
1636 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
1637 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
1638 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1
1639 F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+
1640 m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
1641 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
1642 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
1643 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
1644 (envelope-from jqd@d1.example)
1645 ARC-Authentication-Results: i=2; lists.example.org;
1646 spf=pass smtp.mfrom=jqd@d1.example;
1647 dkim=pass (1024-bit key) header.i=@d1.example;
1648 dmarc=pass
1649 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1650 (authenticated bits=0)
1651 by segv.d1.example with ESMTP id t0FN4a8O084569;
1652 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1653 (envelope-from jqd@d1.example)
1654 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1655 s=origin2015; d=d1.example; cv=none;
1656 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1657 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1658 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1659 ARC-Message-Signature: i=1; a=rsa-sha256;
1660 d=d1.example; s=20130426; t=1421363082;
1661 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1662 h=MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding;
1663 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
1664 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
1665 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1666 Message-ID: <54B84785.1060301@d1.example>
1667 Date: Thu, 14 Jan 2015 15:00:01 -0800
1668 From: John Q Doe
1669 To: arc@example.org
1670 Subject: [Lists] Example 1
1672 Hey gang,
1673 This is a test message.
1674 --J.
1676 Appendix B. Acknowledgements
1678 This draft is the work of OAR-Dev Group.
1680 The authors thank all of the OAR-Dev group for the ongoing help and
1681 though-provoking discussions from all the participants, especially:
1682 Alex Brotman, Brandon Long, Dave Crocker, Elizabeth Zwicky, Franck
1683 Martin, Greg Colburn, J. Trent Adams, John Rae-Grant, Mike Hammer,
1684 Mike Jones, Steve Jones, Terry Zink, Tim Draegen.
1686 Grateful appreciation is extended to the people who provided feedback
1687 through the discuss mailing list.
1689 Appendix C. Comments and Feedback
1691 Please address all comments, discussions, and questions to arc-
1692 discuss@dmarc.org [1][mailto:arc-discuss@dmarc.org].
1694 Authors' Addresses
1696 OAR-DEV Group
1698 Email: arc-discuss@dmarc.org
1700 Kurt Andersen
1701 LinkedIn
1702 2029 Stierlin Ct.
1703 Mountain View, California 94043
1704 USA
1706 Email: kurta@linkedin.com
1708 John Rae-Grant (editor)
1709 Google
1711 Email: johnrg@google.com
1713 Brandon Long (editor)
1714 Google
1716 Email: blong@google.com
1718 J. Trent Adams (editor)
1719 Paypal
1721 Email: trent.adams@paypal.com
1723 Steven Jones (editor)
1724 TDP
1726 Email: smj@crash.com