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