idnits 2.17.1
draft-ietf-dmarc-arc-protocol-08.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
-- The document date (July 21, 2017) is 2471 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)
== Missing Reference: 'N' is mentioned on line 328, but not defined
-- Looks like a reference, but probably isn't: '2' on line 1144
-- Looks like a reference, but probably isn't: '1' on line 1142
== Missing Reference: 'I-D.ARC' is mentioned on line 957, but not defined
-- Looks like a reference, but probably isn't: '3' on line 1146
-- Looks like a reference, but probably isn't: '4' on line 1993
-- Looks like a reference, but probably isn't: '5' on line 1994
== Unused Reference: 'RFC1345' is defined on line 1012, but no explicit
reference was found in the text
== Unused Reference: 'RFC2142' is defined on line 1021, but no explicit
reference was found in the text
== Unused Reference: 'RFC2606' is defined on line 1025, but no explicit
reference was found in the text
== Unused Reference: 'RFC4686' is defined on line 1033, but no explicit
reference was found in the text
== Unused Reference: 'RFC5226' is defined on line 1037, but no explicit
reference was found in the text
== Unused Reference: 'RFC5321' is defined on line 1047, but no explicit
reference was found in the text
== Unused Reference: 'RFC5322' is defined on line 1051, but no explicit
reference was found in the text
== Unused Reference: 'RFC5585' is defined on line 1055, but no explicit
reference was found in the text
== Unused Reference: 'RFC5863' is defined on line 1064, but no explicit
reference was found in the text
== Unused Reference: 'RFC6651' is defined on line 1079, but no explicit
reference was found in the text
== Unused Reference: 'ARC-USAGE' is defined on line 1112, 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 (~~), 14 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-08
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.1.1. Additional Information for the AAR Header . . . . . . 7
65 5.2. ARC-Message-Signature (AMS) . . . . . . . . . . . . . . . 7
66 5.3. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . . . 8
67 5.3.1. The 'cv' Tag . . . . . . . . . . . . . . . . . . . . 9
68 5.3.2. Selected Header Fields . . . . . . . . . . . . . . . 9
69 6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . 9
70 7. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . 11
71 8. Key Management . . . . . . . . . . . . . . . . . . . . . . . 12
72 9. Usage of ARC and Chain Validity . . . . . . . . . . . . . . . 12
73 9.1. Relationship between DKIM-Signature and AMS signing
74 scopes . . . . . . . . . . . . . . . . . . . . . . . . . 12
75 9.2. Assessing Chain Validity Violations . . . . . . . . . . . 12
76 9.3. Marking and Sealing "cv=fail" (Invalid) Chains . . . . . 12
77 9.4. Handling DNS Problems While Validating ARC . . . . . . . 13
78 9.5. Responding to ARC Validity Violations . . . . . . . . . . 13
79 9.6. Recording the Results of ARC Evaluation . . . . . . . . . 13
80 9.6.1. Output Information from an ARC Evaluation . . . . . . 13
81 9.6.2. Reporting ARC Effects for DMARC Local Policy -
82 Interim . . . . . . . . . . . . . . . . . . . . . . . 14
83 10. Supporting Alternate Signing Algorithms . . . . . . . . . . . 14
84 10.1. Introductory Period . . . . . . . . . . . . . . . . . . 15
85 10.2. Co-Existence Period . . . . . . . . . . . . . . . . . . 15
86 10.3. Deprecation Period . . . . . . . . . . . . . . . . . . . 15
87 10.4. Obsolescence Period . . . . . . . . . . . . . . . . . . 15
88 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15
89 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
90 12.1. Authentication-Results Method Registry Update . . . . . 15
91 12.2. Definitions of the ARC header fields . . . . . . . . . . 16
92 13. Implementation Status . . . . . . . . . . . . . . . . . . . . 17
93 13.1. GMail test reflector and incoming validation . . . . . . 17
94 13.2. AOL test reflector and internal tagging . . . . . . . . 18
95 13.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 18
96 13.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . 18
97 13.5. Mailman 3.1+ patch . . . . . . . . . . . . . . . . . . . 19
98 13.6. Copernica/MailerQ web-based validation . . . . . . . . . 20
99 13.7. Rspamd . . . . . . . . . . . . . . . . . . . . . . . . . 20
100 13.8. PERL Mail::Milter::Authentication module . . . . . . . . 21
101 14. Security Considerations . . . . . . . . . . . . . . . . . . . 21
102 14.1. Message Content Suspicion . . . . . . . . . . . . . . . 22
103 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
104 15.1. Normative References . . . . . . . . . . . . . . . . . . 22
105 15.2. Informative References . . . . . . . . . . . . . . . . . 24
106 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25
107 Appendix A. Appendix A - Example Usage (Obsolete but retained
108 for illustrative purposes) . . . . . . . . . . . . . 25
109 A.1. Example 1: Simple mailing list . . . . . . . . . . . . . 25
110 A.1.1. Here's the message as it exits the Origin: . . . . . 25
111 A.1.2. Message is then received at example.org . . . . . . . 26
112 A.1.3. Example 1: Message received by Recipient . . . . . . 28
113 A.2. Example 2: Mailing list to forwarded mailbox . . . . . . 29
114 A.2.1. Here's the message as it exits the Origin: . . . . . 29
115 A.2.2. Message is then received at example.org . . . . . . . 30
116 A.2.3. Example 2: Message received by Recipient . . . . . . 34
117 A.3. Example 3: Mailing list to forwarded mailbox with source 36
118 A.3.1. Here's the message as it exits the Origin: . . . . . 36
119 A.3.2. Message is then received at example.org . . . . . . . 37
120 A.3.3. Example 3: Message received by Recipient . . . . . . 42
121 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 44
122 Appendix C. Comments and Feedback . . . . . . . . . . . . . . . 45
123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
125 1. Introduction
127 Modern email authentication techniques such as the Sender Policy
128 Framework (SPF) [RFC7208] and DomainKeys Identified Mail (DKIM)
129 [RFC6376] have become ubiquitious. However, they are stymied by a
130 small number of common applications, most notably mailing list
131 managers, as these applications have handling properties that prevent
132 these authentication schemes from universal effectiveness. These
133 issues are described in substantial detail in those protocols'
134 defining documents as well as in [RFC6377] and [RFC7960].
136 In an effort to reduce the success of fraudulent email campaigns,
137 there has been an effort to develop and deploy technologies that use
138 SPF and DKIM to assure legitimate use of the identity of the apparent
139 message author, i.e., the visible "From:" field in a message. To
140 this end, Domain-based Mail Authentication, Reporting and Compliance
141 (DMARC) [RFC7489] has been developed and deployed. However, its
142 deployment in environments where mailing lists are used has had the
143 negative impacts predicted in the documents listed above.
145 What is needed is a mechanism by which legitimate alteration of a
146 message, invalidating SPF and DKIM, does not ultimately result in a
147 rejection of an email message on delivery. An Authenticated Received
148 Chain (ARC), described here, provides a superset of the functionality
149 of DKIM in order to provide to the message recipient system(s) a more
150 complete view into the handling chain of a message and the points in
151 that chain where alterations of the content may have occurred.
152 Equipped with this more complete information, the recipient system(s)
153 can make a more informed handling choice, reducing or eliminating the
154 false postives inherent in use of DKIM and/or SPF themselves.
156 2. Overview
158 In DKIM, every participating signing agent attaches a signature that
159 is based on the content of the message, local policy, and the domain
160 name of the participating Administrative Management Domain (ADMD).
161 Any verifier can process such a signature; a verified signature means
162 the message content that was "covered" by the signature has not been
163 altered since the signature was applied. The signatures themselves
164 are generally independent of one another.
166 By contrast, this protocol seeks to have each signature be able to
167 convey the following pieces of information:
169 1. An assertion that, at the time that the intermediary ADMD
170 processed the message, the various assertions already attached to
171 the message by other ADMDs were or were not valid;
173 2. As with DKIM, an assertion that, for a passing signature, the
174 domain name in the signature takes some responsibility for
175 handling of the message and that the message is unchanged since
176 that signature was applied;
178 3. A further assertion that combines and protects the above against
179 alteration by later handlers.
181 This protocol accomplishes each of these by adding a new header field
182 to the message for each of them, as follows:
184 o ARC-Authentication-Results (referred to below as "AAR"): virtually
185 identical in syntax to an Authentication-Results field [RFC7601],
186 this field records the results of all message authentication
187 checks done by the recording ADMD at the time the message arrived.
188 Additional information is added to this field compared to a
189 standard Authentication-Results field in order to support a more
190 complete DMARC report (see Section 5.1);
192 o ARC-Message-Signature (referred to below as "AMS"): virtually
193 identical in syntax to DKIM-Signature, this field contains the
194 assertions about the message header and body as they existed at
195 the time of handling by the ADMD adding it; and
197 o ARC-Seal (referred to below as "AS"): highly similar in structure
198 and format to a DKIM-Signature, this field applies a digital
199 signature that protects the integrity of all three of these new
200 fields when they are added by an ADMD, plus all instances of these
201 fields added by prior ADMDs.
203 A distinguishing feature of all of these is that an ARC participant
204 always adds all of them before relaying a message to the next
205 handling agent en route to its destination. Moreover, as described
206 in Section 4, they each have an "instance" number that increases with
207 each ADMD in the handling chain so that their original order can be
208 preserved and the three of them can be processed as a group.
210 3. Terminology
212 This section defines terms used in the rest of the document.
214 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
215 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
216 document are to be interpreted as described in [RFC2119].
218 Readers are encouraged to be familiar with the contents of [RFC5598],
219 and in particular, the potential roles of intermediaries in the
220 delivery of email.
222 Syntax descriptions use Augmented BNF (ABNF) [RFC5234].
224 A single group of the header fields introduced in Section 2 is called
225 an "ARC set", and the complete sequence of these groups is called an
226 "Authenticated Received Chain" or merely an "ARC chain". Although
227 the "Received" header field is typically not included in the signed
228 content, the name is based on the notion that this is in essence a
229 cryptographically signed series of header fields that attest to the
230 handling chain of a message much as Received fields always have.
232 4. Instance ('i=') Tags
234 The header fields comprising a single ARC set are identified by the
235 presence of a string in the value portion of the header field that
236 complies with the "tag-spec" ABNF found in Section 3.2 of [RFC6376].
237 The tag-name is always the single character "i" and the value is the
238 text representation of a positive integer, indicating the position in
239 the ARC sequence this set occupies, where the first ARC set is
240 numbered 1. In ABNF terms:
242 instance = [FWS] %x69 [FWS] "=" [FWS] 1*DIGIT [FWS] ";"
244 At any delivery stage, it is an error if any ARC set is invalid
245 (i.e., does not contain exactly one of the three header fields
246 defined by this protocol). (Note that when multiple algorithms are
247 supported, there is some nuance to this statement - see Section 10.)
249 Note that because the AMS and AS header field values are made up of
250 tag-spec constructs, the i= tag may be found anywhere within the
251 header field value, but is represented throughout this spec in the
252 initial position for convenience. Implementers SHOULD seek to start
253 with the i= tag to facilitate human inspection of the headers.
255 4.1. Valid Range for Instance Tags
257 The 'i' tag value can range from 1-1024 (inclusive).
259 ARC implementations MUST support at least ten (10) intermediary
260 steps.
262 More than fifty (50) intermediaries is considered extremely unlikely
263 so ARC chains with more than fifty intermediaries may be marked with
264 "cv=fail".
266 5. The ARC Header Fields
268 The three header fields that are part of this specification borrow
269 heavily from existing specifications. Rather than repeating all of
270 the formal definitions that are being reused in ARC, this document
271 only describes and specifies changes in syntax and semantics.
273 5.1. ARC-Authentication-Results (AAR)
275 The ARC-Authentication-Results header field is defined. It is
276 syntactically and semantically identical to an Authentication-Results
277 header field [RFC7601] (A-R), as is the mechanism by which it is
278 constructed, with the following exception:
280 o There is an "i" tag, as described in Section 4; and
282 o Two (or more) additional pieces of information MAY be added (see
283 Section 5.1.1).
285 The instance identifier MUST be separated from the rest of the
286 Authentication-Results value contents with a semi-colon (';', 0x3b).
288 The purpose of this header field is to incorporate into the record
289 the success or failure of any authentication done on the message
290 upstream of the participating ADMD, to validate and continue the
291 authentication chain.
293 In processing, some architectures will generate multiple A-R records
294 for the same authserv-id. In such cases, the resinfo value from each
295 of the A-R records should be concatenated into a single record just
296 as they would have been if they were generated in a single A-R
297 record.
299 5.1.1. Additional Information for the AAR Header
301 An ARC signer generates this field in the same way that a
302 conventional A-R field would be generated. Because the AAR is
303 designed for machine-based consumption over the course of a message's
304 transit through a series of mediators and to facilitate
305 troubleshooting of problematic sources by sending organizations,
306 three additional fields of data SHOULD be added to the normal A-R
307 content, dependent on the presence of DKIM-Signature and/or ARC
308 set(s) and if available to the ADMD which is recording the A-R:
310 o source.ip - The connecting client IP address from which the
311 message is received; and
313 o header.s - The selector value associated with each dkim signature
314 (added to the dkim data sections of the A-R/AAR record)
316 o ARC-related data (added to the arc data sections of the A-R/AAR
317 record):
319 * ams[N].d - The domain value associated with the 'N'th ARC set's
320 AMS header
322 * ams[N].s - The selector associated with the 'N'th ARC set's AMS
323 header
325 * as[N].d - The domain value associated with the 'N'th ARC set's
326 AS header
328 * as[N].s - The selector associated with the 'N'th ARC set's AS
329 header
331 5.2. ARC-Message-Signature (AMS)
333 The ARC-Message-Signature header field is defined. It is
334 syntactically and semantically identical to a DKIM-Signature header
335 field [RFC6376], as is the mechanism by which it is constructed, with
336 the following exceptions:
338 o There is an "i" tag, as described in Section 4.
340 o There is no "v" tag.
342 ARC-Seal header fields MUST never be included in the content covered
343 by the signature in this header field.
345 The AMS SHOULD include any DKIM-Signature header fields already
346 present on the message in the header fields covered by this
347 signature.
349 The AMS header field MAY inclue (sign) the AAR header field(s).
351 Authentication-Results header fields SHOULD NOT be included since
352 they are likely to be deleted by downstream ADMDs (per Section XXX of
353 [RFC7601]), thereby breaking the AMS signature.
355 As with a DKIM-Signature, the purpose of this header field is to
356 allow the ADMD generating it to take some responsibility for handling
357 this message as it progresses toward delivery.
359 5.3. ARC-Seal (AS)
361 The ARC-Seal header field is defined. It is syntactically and
362 semantically similar to a DKIM-Signature field, with the following
363 exceptions:
365 o There is an "i" tag, as described in Section 4.
367 o The ARC-Seal covers none of the body content of the message. It
368 only covers specific header fields. (See below: Section 5.3.2.)
369 As a result, no body canonicalization is done. Further, only
370 "relaxed" header canonicalization (Section 3.4.2 of [RFC6376]) is
371 used.
373 o The only supported tags are "i" (Section 4 supercedes the
374 [RFC6376] definition), and "a", "b", "d, "s", "t". The latter 5
375 tag definitions are copied from Section 3.5 of [RFC6376].
377 o An additional tag, "cv" is defined. (See below: Section 5.3.1)
379 The purpose of this field is to assure the integrity of the ARC set
380 being added by the ADMD generating this header field, and moreover to
381 ensure no tampering with the ARC overall.
383 5.3.1. The 'cv' Tag
385 A new tag "cv" (chain validation) is defined, which indicates the
386 state of the ARC chain as evaluated when it arrived at the ADMD
387 adding this header field. It accepts one of three possible values:
389 o none: There was no chain on the message when it arrived for
390 validation; typically occurs when the message arrives at a Message
391 Transfer Agent (MTA) from a Message Submission Agent (MSA) or when
392 any upstream MTAs may not be participating in ARC handling;
394 o fail: The message has a chain whose validation failed;
396 o pass: The message has a chain whose validation succeeded.
398 In ABNF terms:
400 seal-cv-tag = %x63.76 [FWS] "=" [FWS] ("none" / "fail" / "pass")
402 5.3.2. Selected Header Fields
404 The ARC-Seal signature is an encryption of the hash of the
405 concatenation of the canonicalized form of the ARC sets present on
406 the message at the time of sealing, in increasing instance order,
407 starting at 1, including the one being added at the time of sealing
408 the message.
410 Within a set, the header fields are presented in the following order:
412 1. ARC-Authentication-Results
414 2. ARC-Message-Signature
416 3. ARC-Seal
418 Where the ARC-Seal is the one being generated, it is presented to the
419 hash function in its final form except with an empty "b=" value, in
420 the same manner by which a DKIM-Signature signs itself.
422 Note that the signing scope for the ARC-Seal is modified in the
423 situation where a chain has failed validation (see Section 9.3).
425 6. Verifier Actions
427 The verifier takes the following steps to determine the current state
428 of the ARC on the message:
430 1. Collect all ARC sets currently on the message. If there were
431 none, the ARC state is "none" and the algorithm stops here.
433 2. If any ARC set is invalid (e.g., does not contain exactly one of
434 each of the three ARC-specific header fields), then the chain
435 state is "fail" and the algorithm stops here.
437 1. To bypass all cryto and DNS operations, the cv value for all
438 ARC-Seal(s) MAY be checked at this point. If any of the
439 values are "fail", then the overall state of the chain is
440 "fail" and the algorithm stops here.
442 3. Conduct verification of the ARC-Message-Signature header field
443 bearing the highest instance number. If this verification fails,
444 then the chain state is "fail" and the algorithm stops here.
446 4. For each ARC-Seal from the "N"th instance to the first, apply the
447 following logic:
449 1. If the value of the "cv" tag on that seal is "fail", the
450 chain state is "fail" and the algorithm stops here. (note
451 that this duplicates step 2.1)
453 2. In Boolean nomenclature: if ((i == 1 && cv != "none") or (cv
454 == "none" && i != 1)) then the chain state is "fail" and the
455 algorithm stops here.
457 3. Prepare a hash function corresponding to the "a" tag of the
458 ARC-Seal.
460 4. Compute the canonicalized form of the ARC header fields, in
461 the order described in Section 5.3.2, using the "relaxed"
462 header canonicalization defined in Section 3.4.2 of
463 [RFC6376]. Pass them to the hash function.
465 5. Retrieve the final digest from the hash function.
467 6. Retrieve the public key identified by the "s" and "d" tags in
468 the ARC-Seal, as described in Section 8.
470 7. Determine whether the signature portion ("b" tag) of the ARC-
471 Seal and the digest computed above are valid according to the
472 public key.
474 8. If the signature is not valid, the chain state is "fail" and
475 the algorithm stops here.
477 5. If all seals pass validation, then the chain state is "pass", and
478 the algorithm is complete.
480 The verifier should record the cv state for subsequent use by any
481 sealing which may be done later (potentially after message
482 modification) within the same trust boundary. The cv state may be
483 recorded by sealing at the time of verification in an initial ARC set
484 (for the ADMD) or may be recorded out of band depending on the
485 architecture of the ADMD.
487 7. Signer Actions
489 This section includes a walk-through of the actions an ARC signing
490 implementation takes when presented with a message.
492 The signing agent should undertake the following steps:
494 1. Do any authentication steps that the ADMD normally does:
496 1. If a message is traveling within the same trust boundary,
497 this would include any internal trust conveyed with the
498 message;
500 2. If a message is coming from outside the same trust boundary,
501 this would include any SPF / DKIM / DMARC / other
502 authentication evaluation steps.
504 2. Do any DKIM signing or authentication assertion steps that the
505 ADMD normally does.
507 3. Generate and optionally attach to the message an Authentication-
508 Results header field using the ADMD's authserv-id (see
509 Section 2.5 of [RFC7601]) indicating whatever authentication
510 might have been done by the MTA, or possibly indicate that none
511 was done.
513 4. Build and attach the new ARC set:
515 1. If an ARC chain exists on the message, then set "N" equal to
516 the highest instance number found on the chain (i=);
517 otherwise set "N" equal to zero for the following steps.
519 2. Generate and attach to the message an ARC-Authentication-
520 Results header field using instance number N+1 and the same
521 content from the previous step.
523 3. Generate and attach to the message an ARC-Message-Signature
524 header field using the general algorithm described in
525 Section 5 of [RFC6376] and as modified in Section 5.1 above,
526 using instance number N+1.
528 4. Generate and attach to the message an ARC-Seal header field
529 using the general algorithm described in Section 5.3 above,
530 the chain validation status as determined in Section 6, and
531 instance number N+1.
533 8. Key Management
535 The public keys for ARC header fields follow the same requirements,
536 syntax and semantics as those for DKIM signatures, described in
537 Section 3.6 of [RFC6376]. Operators may use distinct selectors and/
538 or domains for the ARC header fields at their own discretion.
540 9. Usage of ARC and Chain Validity
542 9.1. Relationship between DKIM-Signature and AMS signing scopes
544 DKIM-Signatures SHOULD never sign any ARC header fields.
546 9.2. Assessing Chain Validity Violations
548 There are a wide variety of ways in which the ARC set of header
549 fields can be broken. Receivers need to be wary of ascribing motive
550 to such breakage although patterns of common behaviour may provide
551 some basis for adjusting local policy decisions.
553 This specification is exclusively focused on well-behaved,
554 participating intermediaries that result in a valid chain of ARC-
555 related header fields. The value of such a well-formed, valid chain
556 needs to be interpreted with care since malicious content can be
557 easily introduced by otherwise well-intended senders through machine
558 or account compromises. All normal content-based analysis still
559 needs to be performed on any messages bearing a valid chain of ARC
560 header sets.
562 9.3. Marking and Sealing "cv=fail" (Invalid) Chains
564 The header fields signed by the AS header field b= value in the case
565 of a chain failure MUST be only the matching 'i=' instance headers
566 created by the MTA which detected the malformed chain, as if this
567 newest ARC set was the only set present.
569 9.4. Handling DNS Problems While Validating ARC
571 DNS failures to resolve or return data which is needed for ARC
572 validation SHOULD result in a 421 tempfail during the SMTP
573 conversation with the sending system. Temporary or intermittent DNS
574 problems will generally not be sufficiently transitory to allow a
575 mediator to obtain a different result during the ordinary transit
576 duration so it is better to have the source system queue the
577 problematic message(s) than to generate (potential) backscatter.
579 Operators of systems which mediate mail should be aware that broken
580 DNS records (or malfunctioning name servers) will result in
581 undeliverable mail to any downstream ARC-verifying ADMDs.
583 DNS-based failures to verify a chain are treated no differently than
584 any other ARC violation. They result in a "cv=fail" verdict.
586 9.5. Responding to ARC Validity Violations
588 If a receiver determines that the ARC chain has failed, the receiver
589 MAY signal the breakage through the extended SMTP response code 5.7.7
590 [RFC3463] "message integrity failure" [ENHANCED-STATUS] and
591 corresponding SMTP response code.
593 9.6. Recording the Results of ARC Evaluation
595 Receivers MAY add an "arc=[pass|fail|policy]" method annotation into
596 a locally-affixed Authentication-Results [RFC7601] header field along
597 with any salient comment(s).
599 9.6.1. Output Information from an ARC Evaluation
601 The evaluation of a series of ARC sets results in the following data
602 which MAY be used to inform local-policy decisions:
604 o A list of the "d=" domains found in the validated ARC-Seal header
605 fields;
607 o The "d=" domain found in the most recent (highest instance number)
608 AMS header field (since that is the only one necessarily
609 validated)
611 In the case of a failed chain, only the terminal ARC set is covered
612 by the ARC-Seal so the reporting is limited to the findings in that
613 terminal ARC set.
615 9.6.2. Reporting ARC Effects for DMARC Local Policy - Interim
617 [[ Note: Discussion on the IETF DMARC-WG list has indicated some
618 interest in more substantial reporting for analytic purposes. To
619 support that effort, the following guidance is provided only as an
620 interim, minimal data set. A more complete reporting construct will
621 be specified in a related spec - TBD. (see the additional fields
622 specified in Section 5.1.1) ]]
624 Receivers SHOULD indicate situations in which ARC evaluation
625 influenced the results of their local policy determination. DMARC
626 reporting of ARC-informed decisions is augmented by adding a
627 local_policy comment explanation containing the list of data
628 discovered in the ARC evaluation (Section 9.6.1 and Section 5.1.1):
630
631 delivered
632 fail
633 fail source.ip=10.0.0.1
634
635 local_policy
636 arc=pass ams[2].d=d2.example ams[2].s=s1 as[2].d=d2.example
637 as[2].s=s2 as[1].d=d1.example as[1].s=s3
638
639
641 In the suggested sample, d2.example is the sealing domain for ARC[2]
642 and d1.example is the sealing domain for ARC[1].
644 Mediators SHOULD generate DMARC reports on messages which transit
645 their system just like any other message which they receive. This
646 will result in multiple reports for each mediated message as they
647 transit the series of handlers. DMARC report consumers should be
648 aware of this behaviour and make the necessary accommodations.
650 10. Supporting Alternate Signing Algorithms
652 [[ Note: Some additional development of this section is needed. ]]
654 In the following branch diagrams, each algorithm is represented by an
655 'A' or 'B' at each hop to depict the ARC chain that develops over a
656 five hop scenario. 'x' represents a hop that does not support that
657 algorithm.
659 Note that during a transitional period where multiple algorithms are
660 allowed, all of the statements in this spec which refer to "exactly
661 one set of ARC headers per instance" need to be understood as "at
662 least one set per instance and no more than one instance-set per
663 algorithm".
665 10.1. Introductory Period
667 Intermediaries MUST be able to validate ARC chains build with either
668 algorithm but MAY create ARC sets with either (or both) algorithm.
670 The introductory period should be at least six (6) months.
672 10.2. Co-Existence Period
674 Intermediaries MUST be able to validate ARC chains build with either
675 algorithm and MUST create ARC sets with both algorithms. Chains
676 ending with either algorithm may be used for the result.
678 10.3. Deprecation Period
680 ARC sets built with algorithms that are being deprecated MAY be
681 considered valid within an ARC chain, however, intermediaries MUST
682 NOT create additional sets with the deprecated algorithm.
684 The deprecation period should be at least two (2) years.
686 10.4. Obsolescence Period
688 ARC sets built with algorithms that are obsolete MUST NOT be
689 considered valid within an ARC chain. Intermediaries MUST NOT create
690 any sets with any obsoleted algorithm.
692 11. Privacy Considerations
694 The ARC chain provides a verifiable record of the handlers for a
695 message. Anonymous remailers will probably not find this to match
696 their operating goals.
698 12. IANA Considerations
700 This specification adds three new header fields as defined below.
702 12.1. Authentication-Results Method Registry Update
704 This draft adds one item to the IANA "Email Authentication Methods"
705 registry:
707 o Method : arc
709 Defined: [I-D.ARC]
710 ptype: header
712 Property: chain evaluation result
714 Value: chain evaluation result status (see Section 5.3)
716 Status: active
718 Version: 1
720 12.2. Definitions of the ARC header fields
722 This specification adds three new header fields to the "Permanent
723 Message Header Field Registry", as follows:
725 o Header field name: ARC-Seal
727 Applicable protocol: mail
729 Status: draft
731 Author/Change controller: IETF
733 Specification document(s): [I-D.ARC]
735 Related information: [RFC6376]
737 o Header field name: ARC-Message-Signature
739 Applicable protocol: mail
741 Status: draft
743 Author/Change controller: IETF
745 Specification document(s): [I-D.ARC]
747 Related information: [RFC6376]
749 o Header field name: ARC-Authentication-Results
751 Applicable protocol: mail
753 Status: standard
755 Author/Change controller: IETF
757 Specification document(s): [I-D.ARC]
758 Related information: [RFC7601]
760 13. Implementation Status
762 [[ Note to the RFC Editor: Please remove this section before
763 publication along with the reference to [RFC6982]. ]]
765 This section records the status of known implementations of the
766 protocol defined by this specification at the time of posting of this
767 Internet-Draft, and is based on a proposal described in [RFC6982].
768 The description of implementations in this section is intended to
769 assist the IETF in its decision processes in progressing drafts to
770 RFCs. Please note that the listing of any individual implementation
771 here does not imply endorsement by the IETF. Furthermore, no effort
772 has been spent to verify the information presented here that was
773 supplied by IETF contributors. This is not intended as, and must not
774 be construed to be, a catalog of available implementations or their
775 features. Readers are advised to note that other implementations may
776 exist.
778 This information is known to be correct as of the seventh
779 interoperability test event which was held on 2017-07-15 & 16 at
780 IETF99.
782 13.1. GMail test reflector and incoming validation
784 Organization: Google
786 Description: Internal production implementation with both debug
787 analysis and validating + sealing pass-through function
789 Status of Operation: Production - Incoming Validation
791 Coverage: Full spec implemented as of [ARC-DRAFT-06]
793 Licensing: Proprietary - Internal only
795 Implementation Notes:
797 o Full functionality was demonstrated during the interop testing on
798 2017-07-15.
800 Contact Info: arc-discuss@dmarc.org [1]
802 13.2. AOL test reflector and internal tagging
804 Organization: AOL
806 Description: Internal prototype implementation with both debug
807 analysis and validating + sealing pass-through function
809 Status of Operation: Beta
811 Coverage: ARC chain validity status checking is operational, but only
812 applied to email addresses enrolled in the test program. This system
813 conforms to [ARC-DRAFT-06]
815 Licensing: Proprietary - Internal only
817 Implementation Notes:
819 o 2017-07-15: Full functionality verified during the interop
820 testing.
822 Contact Info: arc-discuss@dmarc.org [2]
824 13.3. dkimpy
826 Organization: dkimpy developers/Scott Kitterman
828 Description: Python DKIM package
830 Status of Operation: Production
832 Coverage:
834 o 2017-07-15: The internal test suite is incomplete, but the command
835 line developmental version of validator was demonstrated to
836 interoperate with the Google and AOL implementations during the
837 interop on 2017-07-15 and the released version passes the tests in
838 [ARC-TEST] (https://github.com/ValiMail/arc_test_suite) with both
839 python and python3.
841 Licensing: Open/Other (same as dkimpy package = BCD version 2)
843 Contact Info: https://launchpad.net/dkimpy
845 13.4. OpenARC
847 Organization: TDP/Murray Kucherawy
848 Description: Implemention of milter functionality related to the
849 OpenDKIM and OpenDMARC packages
851 Status of Operation: Beta
853 Coverage: Built to support [ARC-DRAFT-06]
855 Licensing: Open/Other (same as OpenDKIM and OpenDMARC packages)
857 Implementation Notes:
859 o The build is FreeBSD oriented but some packages have been built
860 for easier deployment on RedHat-based Linux platforms.
862 o 2017-07-15: Testing showed problems with the hash calculation for
863 the AMS header b= field. Several other bugs were discovered and
864 were either fixed during the following week of IETF meetings or
865 are under active repair.
867 o Some issues still exist when deploying in a chained milter
868 arrangement (such as OpenSPF -> OpenDKIM -> OpenDMARC -> OpenARC)
869 with coordination between the stages. When deployed in a
870 "sandwich" configuration around an MLM, there is no effective
871 mechanism to convey trust from the ingress (validator) to egress
872 (signer) instances.
874 Contact Info: arc-discuss@dmarc.org [3]
876 13.5. Mailman 3.1+ patch
878 Organization: Mailman development team
880 Description: Integrated ARC capabilities within the Mailman 3.1+
881 package
883 Status of Operation: Patch submitted
885 Coverage: Unknown
887 Licensing: Same as mailman package - GPL
889 Implementation Notes:
891 o Appears to work properly in at least one beta deployment, but
892 waiting on acceptance of the pull request into the mainline of
893 mailman development
895 Contact Info: https://www.gnu.org/software/mailman/contact.html
897 13.6. Copernica/MailerQ web-based validation
899 Organization: Copernica
901 Description: Web-based validation of ARC-signed messages
903 Status of Operation: Beta
905 Coverage: Built to support [ARC-DRAFT-05]
907 Licensing: On-line usage only
909 Implementation Notes:
911 o Released 2016-10-24
913 o Requires full message content to be pasted into a web form found
914 at http://arc.mailerq.com/ (warning - https is not supported).
916 o An additional instance of an ARC signature can be added if one is
917 willing to paste a private key into an unsecured web form.
919 o 2017-07-15: Testing shows that results match the other
920 implementations listed in this section.
922 Contact Info: https://www.copernica.com/
924 13.7. Rspamd
926 Organization: Rspamd community
928 Description: ARC signing and verification module
930 Status of Operation: Production, though deployment usage is unknown
932 Coverage: Built to support [ARC-DRAFT-06]
934 Licensing: Open source
936 Implementation Notes:
938 o 2017-06-12: Released with version 1.6.0
940 o 2017-07-15: Testing during the interop showed that the validation
941 functionality interoperated with the Google, AOL, dkimpy and
942 MailerQ implementations
944 Contact Info: https://rspamd.com/doc/modules/arc.html and
945 https://github.com/vstakhov/rspamd
947 13.8. PERL Mail::Milter::Authentication module
949 Organization: FastMail
951 Description: Email domain authentication milter, previously included
952 SPF / DKIM / DMARC, now has ARC added
954 Status of Operation: Intial validation completed during IETF99
955 hackathon with some follow-on work during the week
957 Coverage: Built to support [I-D.ARC]
959 Licensing: Open Source
961 Implementation Notes:
963 o 2017-07-15: Validation functionality which interoperates with
964 Gmail, AOL, dkimpy was demonstrated; later in the week of IETF99,
965 the signing functionality was reported to be working
967 o 2017-07-20: ARC functionality has not yet been pushed back to the
968 github repo but should be showing up soon
970 Contact Info: https://github.com/fastmail/authentication_milter
972 14. Security Considerations
974 The Security Considerations of [RFC6376] and [RFC7601] apply directly
975 to this specification.
977 Inclusion of ARC sets in the header of emails may cause problems for
978 some older or more constrained MTAs if they are unable to accept the
979 greater size of the header.
981 Operators who receive a message bearing N ARC sets have to complete
982 up to N+1 DNS queries to evaluate the chain (barring DNS redirection
983 mechanisms which can increase the lookups for a given target value).
984 This has at least two effects:
986 1. An attacker can send a message to an ARC partipant with a
987 concocted sequence of ARC sets bearing the domains of intended
988 victims, and all of them will be queried by the participant until
989 a failure is discovered. The difficulty of forging the signature
990 values should limit the extent of this load to domains under
991 control of the attacker.
993 2. DKIM only does one DNS check per signature, while this one can do
994 many (per chain). Absent caching, slow DNS responses can cause
995 SMTP timeouts; and backlogged delivery queues on mediating
996 systems. This could be exploited as a DoS attack.
998 14.1. Message Content Suspicion
1000 Recipients are cautioned to treat messages bearing ARC sets with the
1001 same suspicion that they apply to all other email messages. This
1002 includes appropriate content scanning and other checks for
1003 potentially malicious content. The handlers which are identified
1004 within the ARC chain may be used to provide input to local policy
1005 engines in cases where DMARC validation fails (due to mediation
1006 impacting SPF attribution, DKIM validity or alignment).
1008 15. References
1010 15.1. Normative References
1012 [RFC1345] Simonsen, K., "Character Mnemonics and Character Sets",
1013 RFC 1345, DOI 10.17487/RFC1345, June 1992,
1014 .
1016 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1017 Requirement Levels", BCP 14, RFC 2119,
1018 DOI 10.17487/RFC2119, March 1997,
1019 .
1021 [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and
1022 Functions", RFC 2142, DOI 10.17487/RFC2142, May 1997,
1023 .
1025 [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS
1026 Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999,
1027 .
1029 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes",
1030 RFC 3463, DOI 10.17487/RFC3463, January 2003,
1031 .
1033 [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys
1034 Identified Mail (DKIM)", RFC 4686, DOI 10.17487/RFC4686,
1035 September 2006, .
1037 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
1038 IANA Considerations Section in RFCs", RFC 5226,
1039 DOI 10.17487/RFC5226, May 2008,
1040 .
1042 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
1043 Specifications: ABNF", STD 68, RFC 5234,
1044 DOI 10.17487/RFC5234, January 2008,
1045 .
1047 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
1048 DOI 10.17487/RFC5321, October 2008,
1049 .
1051 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
1052 DOI 10.17487/RFC5322, October 2008,
1053 .
1055 [RFC5585] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys
1056 Identified Mail (DKIM) Service Overview", RFC 5585,
1057 DOI 10.17487/RFC5585, July 2009,
1058 .
1060 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
1061 DOI 10.17487/RFC5598, July 2009,
1062 .
1064 [RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker,
1065 "DomainKeys Identified Mail (DKIM) Development,
1066 Deployment, and Operations", RFC 5863,
1067 DOI 10.17487/RFC5863, May 2010,
1068 .
1070 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
1071 "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
1072 RFC 6376, DOI 10.17487/RFC6376, September 2011,
1073 .
1075 [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and
1076 Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377,
1077 September 2011, .
1079 [RFC6651] Kucherawy, M., "Extensions to DomainKeys Identified Mail
1080 (DKIM) for Failure Reporting", RFC 6651,
1081 DOI 10.17487/RFC6651, June 2012,
1082 .
1084 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
1085 Authorizing Use of Domains in Email, Version 1", RFC 7208,
1086 DOI 10.17487/RFC7208, April 2014,
1087 .
1089 [RFC7601] Kucherawy, M., "Message Header Field for Indicating
1090 Message Authentication Status", RFC 7601,
1091 DOI 10.17487/RFC7601, August 2015,
1092 .
1094 15.2. Informative References
1096 [ARC-DRAFT-05]
1097 Andersen, K., Long, B., and S. Jones, "Authenticated
1098 Received Chain (ARC) Protocol (I-D-06)", n.d.,
1099 .
1102 [ARC-DRAFT-06]
1103 Andersen, K., Long, B., and S. Jones, "Authenticated
1104 Received Chain (ARC) Protocol (I-D-05)", n.d.,
1105 .
1108 [ARC-TEST]
1109 Blank, S., "ARC Test Suite", January 2017,
1110 .
1112 [ARC-USAGE]
1113 Jones, S., Adams, T., Rae-Grant, J., and K. Andersen,
1114 "Recommended Usage of the ARC Headers", December 2017,
1115 .
1118 [ENHANCED-STATUS]
1119 "IANA SMTP Enhanced Status Codes", n.d.,
1120 .
1123 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
1124 Code: The Implementation Status Section", RFC 6982,
1125 DOI 10.17487/RFC6982, July 2013,
1126 .
1128 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
1129 Message Authentication, Reporting, and Conformance
1130 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
1131 .
1133 [RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky,
1134 E., Ed., and K. Andersen, Ed., "Interoperability Issues
1135 between Domain-based Message Authentication, Reporting,
1136 and Conformance (DMARC) and Indirect Email Flows",
1137 RFC 7960, DOI 10.17487/RFC7960, September 2016,
1138 .
1140 15.3. URIs
1142 [1] mailto:arc-discuss@dmarc.org
1144 [2] mailto:arc-discuss@dmarc.org
1146 [3] mailto:arc-discuss@dmarc.org
1148 [4] mailto:dmarc@ietf.org
1150 [5] mailto:arc-discuss@dmarc.org
1152 Appendix A. Appendix A - Example Usage (Obsolete but retained for
1153 illustrative purposes)
1155 [[ Note: The following examples were mocked up early in the
1156 definition process for the spec. They no longer reflect the current
1157 definition and need various updates which will be included in the
1158 next draft. ]]
1160 A.1. Example 1: Simple mailing list
1162 A.1.1. Here's the message as it exits the Origin:
1164 Return-Path:
1165 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1166 (authenticated bits=0)
1167 by segv.d1.example with ESMTP id t0FN4a8O084569;
1168 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1169 (envelope-from jqd@d1.example)
1170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
1171 s=20130426; t=1421363082;
1172 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1173 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
1174 Content-Transfer-Encoding;
1175 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw
1176 bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl
1177 gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1178 Message-ID: <54B84785.1060301@d1.example>
1179 Date: Thu, 14 Jan 2015 15:00:01 -0800
1180 From: John Q Doe
1181 To: arc@dmarc.org
1182 Subject: Example 1
1184 Hey gang,
1185 This is a test message.
1186 --J.
1188 A.1.2. Message is then received at example.org
1190 A.1.2.1. Example 1, Step A: Message forwarded to list members
1192 Processing at example.org:
1194 o example.org performs authentication checks
1196 o No previous Auth-Results or ARC-Seal headers are present
1198 o example.org adds ARC-Auth-Results header
1200 o example.org adds Received: header
1202 o example.org adds a ARC-Seal header
1204 Here's the message as it exits example.org:
1206 Return-Path:
1207 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1208 s=seal2015; d=example.org; cv=none;
1209 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1210 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1211 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1212 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
1213 d=example.org; s=clochette; t=1421363105;
1214 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
1215 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
1216 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
1217 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1F5
1218 vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+m4bw
1219 a6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
1220 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
1221 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
1222 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
1223 (envelope-from jqd@d1.example)
1224 ARC-Authentication-Results: i=1; lists.example.org;
1225 spf=pass smtp.mfrom=jqd@d1.example;
1226 dkim=pass (1024-bit key) header.i=@d1.example;
1227 dmarc=pass
1228 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1229 (authenticated bits=0)
1230 by segv.d1.example with ESMTP id t0FN4a8O084569;
1231 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1232 (envelope-from jqd@d1.example)
1233 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
1234 s=20130426; t=1421363082;
1235 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1236 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
1237 Content-Transfer-Encoding;
1238 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
1239 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
1240 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1241 Message-ID: <54B84785.1060301@d1.example>
1242 Date: Thu, 14 Jan 2015 15:00:01 -0800
1243 From: John Q Doe
1244 To: arc@example.org
1245 Subject: [Lists] Example 1
1247 Hey gang,
1248 This is a test message.
1249 --J.
1251 A.1.3. Example 1: Message received by Recipient
1253 Let's say that the Recipient is example.com
1255 Processing at example.com:
1257 o example.com performs usual authentication checks
1259 o example.com adds Auth-Results: header, Received header
1261 o Determines that message fails DMARC
1263 o Checks for ARC-Seal: header; finds one
1265 o Validates the signature in the ARC-Seal: header, which covers the
1266 ARC-Authentication-Results: header
1268 o example.com can use the ARC-Authentication-Results values or
1269 verify the DKIM-Signature from lists.example.org
1271 Here's what the message looks like at this point:
1273 Return-Path:
1274 Received: from example.org (example.org [208.69.40.157])
1275 by clothilde.example.com with ESMTP id
1276 d200mr22663000ykb.93.1421363207
1277 for ; Thu, 14 Jan 2015 15:02:40 -0800 (PST)
1278 Authentication-Results: clothilde.example.com; spf=fail
1279 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
1280 header.i=@example.org; dmarc=fail; arc=pass
1281 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1282 s=seal2015; d=example.org; cv=none;
1283 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1284 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1285 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1286 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
1287 d=example.org; s=clochette; t=1421363105;
1288 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
1289 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
1290 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
1291 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
1292 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
1293 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
1294 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
1295 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
1296 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
1297 (envelope-from jqd@d1.example)
1298 ARC-Authentication-Results: i=1; lists.example.org;
1299 spf=pass smtp.mfrom=jqd@d1.example;
1300 dkim=pass (1024-bit key) header.i=@d1.example;
1301 dmarc=pass
1302 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1303 (authenticated bits=0)
1304 by segv.d1.example with ESMTP id t0FN4a8O084569;
1305 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1306 (envelope-from jqd@d1.example)
1307 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
1308 s=20130426; t=1421363082;
1309 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1310 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
1311 Content-Transfer-Encoding;
1312 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw
1313 bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl
1314 gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1315 Message-ID: <54B84785.1060301@d1.example>
1316 Date: Thu, 14 Jan 2015 15:00:01 -0800
1317 From: John Q Doe
1318 To: arc@example.org
1319 Subject: [Lists] Example 1
1321 Hey gang,
1322 This is a test message.
1323 --J.
1325 A.2. Example 2: Mailing list to forwarded mailbox
1327 A.2.1. Here's the message as it exits the Origin:
1329 Return-Path:
1330 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1331 (authenticated bits=0)
1332 by segv.d1.example with ESMTP id t0FN4a8O084569;
1333 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1334 (envelope-from jqd@d1.example)
1335 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
1336 s=20130426; t=1421363082;
1337 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1338 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
1339 Content-Transfer-Encoding;
1340 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw
1341 bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl
1342 gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1343 Message-ID: <54B84785.1060301@d1.example>
1344 Date: Thu, 14 Jan 2015 15:00:01 -0800
1345 From: John Q Doe
1346 To: arc@example.org
1347 Subject: Example 1
1349 Hey gang,
1350 This is a test message.
1351 --J.
1353 A.2.2. Message is then received at example.org
1355 A.2.2.1. Example 2, Step A: Message forwarded to list members
1357 Processing at example.org:
1359 o example.org performs authentication checks
1361 o example.org applies standard DKIM signature
1363 o No previous Auth-Results or ARC-Seal headers are present
1365 o example.org adds ARC-Auth-Results header
1367 o example.org adds usual Received: header
1369 o example.org adds a ARC-Seal header
1371 Here's the message as it exits Step A:
1373 Return-Path:
1374 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1375 s=seal2015; d=example.org; cv=none;
1376 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
1377 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
1378 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1379 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
1380 d=example.org; s=clochette; t=1421363105;
1381 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
1382 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
1383 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
1384 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
1385 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
1386 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
1387 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
1388 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
1389 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
1390 (envelope-from jqd@d1.example)
1391 ARC-Authentication-Results: i=1; lists.example.org;
1392 spf=pass smtp.mfrom=jqd@d1.example;
1393 dkim=pass (1024-bit key) header.i=@d1.example;
1394 dmarc=pass
1395 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1396 (authenticated bits=0)
1397 by segv.d1.example with ESMTP id t0FN4a8O084569;
1398 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1399 (envelope-from jqd@d1.example)
1400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
1401 s=20130426; t=1421363082;
1402 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1403 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
1404 Content-Transfer-Encoding;
1405 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
1406 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
1407 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1408 Message-ID: <54B84785.1060301@d1.example>
1409 Date: Thu, 14 Jan 2015 15:00:01 -0800
1410 From: John Q Doe
1411 To: arc@example.org
1412 Subject: [Lists] Example 1
1414 Hey gang,
1415 This is a test message.
1416 --J.
1418 A.2.2.2. Example 2, Step B: Message from list forwarded
1420 The message is delivered to a mailbox at gmail.com
1421 Processing at gmail.com:
1423 o gmail.com performs usual authentication checks
1425 o gmail.com adds Auth-Results: and Received: header
1427 o Determines that message fails DMARC
1429 o Checks for ARC-Seal: header; finds one
1431 o Validates the signature in the ARC-Seal: header, which covers the
1432 ARC-Authentication-Results: header
1434 o Uses the ARC-Auth-Results: values, but:
1436 o Instead of delivering message, prepares to forward message per
1437 user settings
1439 o Applies usual DKIM signature
1441 o gmail.com adds it's own ARC-Seal: header, contents of which are
1443 * version
1445 * sequence number ("i=2")
1447 * hash algorithm (SHA256 as example)
1449 * timestamp ("t=")
1451 * selector for key ("s=notary01")
1453 * domain for key ("d=gmail.com")
1455 * headers included in hash ("h=ARC-Authentication-Results:ARC-
1456 Seal")
1458 * Note: algorithm requires only ARC-Seals with lower sequence #
1459 be included, in ascending order
1461 * signature of the header hash
1463 Here's what the message looks like at this point:
1465 Return-Path:
1466 ARC-Seal: i=2; a=rsa-sha256; t=1421363253;
1467 s=notary01; d=gmail.com; cv=pass;
1468 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDWR
1469 YbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/sut
1470 txO+RRNr0fCFw==
1471 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed;
1472 d=gmail.com; s=20120806;
1473 h=mime-version:content-type:x-original-sender:
1474 x-original-authentication-results:precedence:mailing-list:
1475 list-id:list-post:list-help:list-archive:sender:reply-to:
1476 list-unsubscribe:DKIM-Signature;
1477 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=;
1478 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1479 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1480 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBmfhS
1481 LF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJRFeM
1482 KdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwDBJtXw
1483 bQoZyRtb6X6q0mYaszUB8kw==
1484 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10
1485 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST)
1486 Authentication-Results: i=2; gmail.com; spf=fail
1487 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
1488 header.i=@example.org; dmarc=fail; arc=pass
1489 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1490 s=seal2015; d=example.org; cv=none:
1491 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1492 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1493 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1494 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
1495 d=example.org; s=clochette; t=1421363105;
1496 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
1497 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
1498 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
1499 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
1500 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
1501 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
1502 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
1503 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
1504 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
1505 (envelope-from jqd@d1.example)
1506 ARC-Authentication-Results: i=1; lists.example.org;
1507 spf=pass smtp.mfrom=jqd@d1.example;
1508 dkim=pass (1024-bit key) header.i=@d1.example;
1509 dmarc=pass
1510 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1511 (authenticated bits=0)
1512 by segv.d1.example with ESMTP id t0FN4a8O084569;
1513 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1514 (envelope-from jqd@d1.example)
1515 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
1516 s=20130426; t=1421363082;
1517 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1518 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
1519 Content-Transfer-Encoding;
1520 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
1521 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
1522 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1523 Message-ID: <54B84785.1060301@d1.example>
1524 Date: Thu, 14 Jan 2015 15:00:01 -0800
1525 From: John Q Doe
1526 To: arc@example.org
1527 Subject: [Lists] Example 1
1529 Hey gang,
1530 This is a test message.
1531 --J.
1533 A.2.3. Example 2: Message received by Recipient
1535 Let's say that the Recipient is example.com
1536 Processing at example.com:
1538 o example.com performs usual authentication checks
1540 o example.com adds Auth-Results: header, Received header
1542 o Determines that message fails DMARC
1544 o Checks for ARC-Seal: header; finds two
1546 o Validates the signature in the highest numbered ("i=2") ARC-Seal:
1547 header, which covers all previous ARC-Seal: and ARC-
1548 Authentication-Results: headers
1550 o Validates the other ARC-Seal header ("i=1"), which covers the ARC-
1551 Authentication-Results: header
1553 o example.com uses the ARC-Authentication-Results: values
1555 Here's what the message looks like at this point:
1557 Return-Path:
1558 Received: from mail-ob0-f188.google.com (mail-ob0-f188.google.com
1559 [208.69.40.157]) by clothilde.example.com with ESMTP id
1560 d200mr22663000ykb.93.1421363268
1561 for ; Thu, 14 Jan 2015 15:03:15 -0800 (PST)
1563 Authentication-Results: clothilde.example.com; spf=fail
1564 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
1565 header.i=@gmail.com; dmarc=fail; arc=pass
1566 ARC-Seal: i=2; a=rsa-sha256; t=1421363253;
1567 s=notary01; d=gmail.com; cv=pass;
1568 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDWR
1569 YbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/sut
1570 txO+RRNr0fCFw==
1571 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed;
1572 d=gmail.com; s=20120806;
1573 h=mime-version:content-type:x-original-sender:
1574 x-original-authentication-results:precedence:mailing-list:
1575 list-id:list-post:list-help:list-archive:sender:reply-to:
1576 :list-unsubscribe:DKIM-Signature;
1577 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=;
1578 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1579 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1580 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBmfhS
1581 LF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJRFeM
1582 KdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwDBJtXw
1583 bQoZyRtb6X6q0mYaszUB8kw==
1584 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10
1585 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST)
1586 Authentication-Results: i=2; gmail.com; spf=fail
1587 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
1588 header.i=@example.org; dmarc=fail; arc=pass
1589 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1590 s=seal2015; d=example.org; cv=none;
1591 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1592 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1593 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1594 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
1595 d=example.org; s=clochette; t=1421363105;
1596 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
1597 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
1598 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
1599 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
1600 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
1601 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
1602 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
1603 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
1604 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
1605 (envelope-from jqd@d1.example)
1606 ARC-Authentication-Results: i=1; lists.example.org;
1607 spf=pass smtp.mfrom=jqd@d1.example;
1608 dkim=pass (1024-bit key) header.i=@d1.example;
1609 dmarc=pass
1610 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1611 (authenticated bits=0)
1612 by segv.d1.example with ESMTP id t0FN4a8O084569;
1613 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1614 (envelope-from jqd@d1.example)
1615 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
1616 s=20130426; t=1421363082;
1617 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1618 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
1619 Content-Transfer-Encoding;
1620 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
1621 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
1622 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1623 Message-ID: <54B84785.1060301@d1.example>
1624 Date: Thu, 14 Jan 2015 15:00:01 -0800
1625 From: John Q Doe
1626 To: arc@example.org
1627 Subject: [Lists] Example 1
1629 Hey gang,
1630 This is a test message.
1631 --J.
1633 A.3. Example 3: Mailing list to forwarded mailbox with source
1635 A.3.1. Here's the message as it exits the Origin:
1637 Return-Path:
1638 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1639 (authenticated bits=0)
1640 by segv.d1.example with ESMTP id t0FN4a8O084569;
1641 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1642 (envelope-from jqd@d1.example)
1643 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1644 s=origin2015; d=d1.example; cv=none;
1645 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61T
1646 X6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69EU
1647 8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1648 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
1649 d=d1.example; s=20130426; t=1421363082;
1650 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1651 h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding;
1652 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrv
1653 Qwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3
1654 TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1655 Message-ID: <54B84785.1060301@d1.example>
1656 Date: Thu, 14 Jan 2015 15:00:01 -0800
1657 From: John Q Doe
1658 To: arc@example.org
1659 Subject: Example 1
1661 Hey gang,
1662 This is a test message.
1663 --J.
1665 A.3.2. Message is then received at example.org
1667 A.3.2.1. Example 3, Step A: Message forwarded to list members with
1668 source
1670 Processing at example.org:
1672 o example.org performs authentication checks
1674 o example.org applies standard DKIM signature
1676 o Checks for ARC-Seal: header; finds one (i=1)
1678 o Validates the signature in the ARC-Seal (i=1): header, which
1679 covers the d1.example ARC-Message-Signature: header
1681 o example.org adds ARC-Auth-Results header
1683 o example.org adds usual Received: header
1684 o example.org adds a DKIM-Signature
1686 o example.org adds a ARC-Seal header, contents of which are
1688 * sequence number ("i=2")
1690 * hash algorithm (SHA256 as example)
1692 * timestamp ("t=")
1694 * chain validity ("cv=")
1696 * selector for key ("s=seal2015")
1698 * domain for key ("d=example.org")
1700 * signature ("b=")
1702 Here's the message as it exits Step A:
1704 Return-Path:
1705 ARC-Seal: i=2; a=rsa-sha256; t=1421363107;
1706 s=seal2015; d=example.org; cv=pass;
1707 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
1708 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
1709 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1710 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed;
1711 d=example.org; s=clochette; t=1421363105;
1712 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
1713 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
1714 List-Help:List-Subscribe:From:Reply-To:DKIM-Signature;
1715 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
1716 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
1717 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
1718 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
1719 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
1720 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
1721 (envelope-from jqd@d1.example)
1722 ARC-Authentication-Results: i=2; lists.example.org;
1723 spf=pass smtp.mfrom=jqd@d1.example;
1724 dkim=pass (1024-bit key) header.i=@d1.example;
1725 dmarc=pass
1726 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1727 (authenticated bits=0)
1728 by segv.d1.example with ESMTP id t0FN4a8O084569;
1729 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1730 (envelope-from jqd@d1.example)
1731 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1732 s=origin2015; d=d1.example; cv=none;
1733 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1734 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1735 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1736 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
1737 d=d1.example; s=20130426; t=1421363082;
1738 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1739 h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding;
1740 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
1741 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
1742 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1743 Message-ID: <54B84785.1060301@d1.example>
1744 Date: Thu, 14 Jan 2015 15:00:01 -0800
1745 From: John Q Doe
1746 To: arc@example.org
1747 Subject: [Lists] Example 1
1749 Hey gang,
1750 This is a test message.
1751 --J.
1753 A.3.2.2. Example 3, Step B: Message from list forwarded with source
1755 The message is delivered to a mailbox at gmail.com
1756 Processing at gmail.com:
1758 o gmail.com performs usual authentication checks
1760 o gmail.com adds Auth-Results: and Received: header
1762 o Determines that message fails DMARC
1764 o Checks for ARC-Seal: header; finds two
1766 o Validates the signature in the ARC-Seal (i=2): header, which
1767 covers the ARC-Authentication-Results: header
1769 o Validates the signature in the ARC-Seal (i=1): header, which
1770 covers the d1.example ARC-Message-Signature: header
1772 o Uses the ARC-Auth-Results: values, but:
1774 o Instead of delivering message, prepares to forward message per
1775 user settings
1777 o Applies usual DKIM signature
1779 o gmail.com adds it's own ARC-Seal: header, contents of which are
1781 * version
1783 * sequence number ("i=2")
1785 * hash algorithm (SHA256 as example)
1787 * timestamp ("t=")
1789 * selector for key ("s=notary01")
1791 * domain for key ("d=gmail.com")
1793 * Note: algorithm requires only ARC-Seals with lower sequence #
1794 be included, in ascending order
1796 * signature of the chain
1798 Here's what the message looks like at this point:
1800 Return-Path:
1801 ARC-Seal: i=3; a=rsa-sha256; t=1421363253;
1802 s=notary01; d=gmail.com; cv=pass;
1803 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwD
1804 WRYbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF
1805 /suttxO+RRNr0fCFw==
1806 ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed;
1807 d=gmail.com; s=20120806;
1808 h=mime-version:content-type:x-original-sender
1809 :x-original-authentication-results:precedence:mailing-list
1810 :list-id:list-post:list-help:list-archive:sender
1811 :list-unsubscribe:reply-to;
1812 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=;
1813 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
1814 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
1815 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBm
1816 fhSLF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJ
1817 RFeMKdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwD
1818 BJtXwbQoZyRtb6X6q0mYaszUB8kw==
1819 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10
1820 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST)
1821 Authentication-Results: i=3; gmail.com; spf=fail
1822 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
1823 header.i=@example.org; dmarc=fail; arc=pass
1824 ARC-Seal: i=2; a=rsa-sha256; t=1421363107;
1825 s=seal2015; d=example.org; cv=pass;
1826 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1827 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1828 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1829 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed;
1830 d=example.org; s=clochette; t=1421363105;
1831 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
1832 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
1833 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
1834 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1
1835 F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+
1836 m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
1837 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
1838 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
1839 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
1840 (envelope-from jqd@d1.example)
1841 ARC-Authentication-Results: i=2; lists.example.org;
1842 spf=pass smtp.mfrom=jqd@d1.example;
1843 dkim=pass (1024-bit key) header.i=@d1.example;
1844 dmarc=pass
1845 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1846 (authenticated bits=0)
1847 by segv.d1.example with ESMTP id t0FN4a8O084569;
1848 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1849 (envelope-from jqd@d1.example)
1850 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1851 s=origin2015; d=d1.example; cv=none;
1852 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1853 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1854 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1855 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
1856 d=d1.example; s=20130426; t=1421363082;
1857 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1858 h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding;
1859 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYij
1860 rvQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD
1861 4Gd3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1862 Message-ID: <54B84785.1060301@d1.example>
1863 Date: Thu, 14 Jan 2015 15:00:01 -0800
1864 From: John Q Doe
1865 To: arc@example.org
1866 Subject: [Lists] Example 1
1868 Hey gang,
1869 This is a test message.
1870 --J.
1872 A.3.3. Example 3: Message received by Recipient
1874 Let's say that the Recipient is example.com
1875 Processing at example.com:
1877 o example.com performs usual authentication checks
1879 o example.com adds Auth-Results: header, Received header
1881 o Determines that message fails DMARC
1883 o Checks for ARC-Seal: header; finds three
1885 o Validates the signature in the highest numbered ("i=2") ARC-Seal:
1886 header, which covers all previous ARC-Seal: and ARC-
1887 Authentication-Results: headers
1889 o Validates the other ARC-Seal header ("i=2"), which covers the ARC-
1890 Authentication-Results: header
1892 o Validates the other ARC-Seal header ("i=1"), which covers the
1893 d1.example ARC-Message-Signature: header
1895 o example.com uses the ARC-Authentication-Results: values
1896 Here's what the message looks like at this point:
1898 Return-Path:
1899 Received: from mail-ob0-f188.google.com (mail-ob0-f188.google.com
1900 [208.69.40.157]) by clothilde.example.com with ESMTP id
1901 d200mr22663000ykb.93.1421363268
1902 for ; Thu, 14 Jan 2015 15:03:15 -0800 (PST)
1903 Authentication-Results: clothilde.example.com; spf=fail
1904 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
1905 header.i=@gmail.com; dmarc=fail; arc=pass
1906 ARC-Seal: i=3; a=rsa-sha256; t=1421363253;
1907 s=notary01; d=gmail.com; cv=pass;
1908 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDW
1909 RYbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/s
1910 uttxO+RRNr0fCFw==
1911 ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed;
1912 d=gmail.com; s=20120806;
1913 h=mime-version:content-type:x-original-sender
1914 :x-original-authentication-results:precedence
1915 :mailing-list:list-id:list-post:list-help:list-archive:sender
1916 :list-unsubscribe:reply-to;
1917 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=;
1918 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
1919 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
1920 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBm
1921 fhSLF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJ
1922 RFeMKdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwD
1923 BJtXwbQoZyRtb6X6q0mYaszUB8kw==
1924 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10
1925 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST)
1926 Authentication-Results: i=3; gmail.com; spf=fail
1927 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
1928 header.i=@example.org; dmarc=fail; arc=pass
1929 ARC-Seal: i=2; a=rsa-sha256; t=1421363107;
1930 s=seal2015; d=example.org; cv=pass;
1931 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
1932 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
1933 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1934 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed;
1935 d=example.org; s=clochette; t=1421363105;
1936 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
1937 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
1938 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
1939 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1
1940 F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+
1941 m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
1942 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
1943 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
1944 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
1945 (envelope-from jqd@d1.example)
1946 ARC-Authentication-Results: i=2; lists.example.org;
1947 spf=pass smtp.mfrom=jqd@d1.example;
1948 dkim=pass (1024-bit key) header.i=@d1.example;
1949 dmarc=pass
1950 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1951 (authenticated bits=0)
1952 by segv.d1.example with ESMTP id t0FN4a8O084569;
1953 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1954 (envelope-from jqd@d1.example)
1955 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1956 s=origin2015; d=d1.example; cv=none;
1957 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1958 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1959 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1960 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
1961 d=d1.example; s=20130426; t=1421363082;
1962 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1963 h=MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding;
1964 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
1965 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
1966 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1967 Message-ID: <54B84785.1060301@d1.example>
1968 Date: Thu, 14 Jan 2015 15:00:01 -0800
1969 From: John Q Doe
1970 To: arc@example.org
1971 Subject: [Lists] Example 1
1973 Hey gang,
1974 This is a test message.
1975 --J.
1977 Appendix B. Acknowledgements
1979 This draft is the work of OAR-Dev Group.
1981 The authors thank all of the OAR-Dev group for the ongoing help and
1982 though-provoking discussions from all the participants, especially:
1983 Alex Brotman, Brandon Long, Dave Crocker, Elizabeth Zwicky, Franck
1984 Martin, Greg Colburn, J. Trent Adams, John Rae-Grant, Mike Hammer,
1985 Mike Jones, Steve Jones, Terry Zink, Tim Draegen.
1987 Grateful appreciation is extended to the people who provided feedback
1988 through the discuss mailing list.
1990 Appendix C. Comments and Feedback
1992 Please address all comments, discussions, and questions to
1993 dmarc@ietf.org [4]. Earlier discussions can be found at arc-
1994 discuss@dmarc.org [5].
1996 Authors' Addresses
1998 Kurt Andersen
1999 LinkedIn
2000 1000 West Maude Ave
2001 Sunnyvale, California 94085
2002 USA
2004 Email: kurta@linkedin.com
2006 Brandon Long (editor)
2007 Google
2009 Email: blong@google.com
2011 Steven Jones (editor)
2012 TDP
2014 Email: smj@crash.com
2016 Murray Kucherawy (editor)
2017 TDP
2019 Email: superuser@gmail.com