idnits 2.17.1
draft-ietf-dmarc-arc-protocol-09.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 (September 06, 2017) is 2425 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 1172
-- Looks like a reference, but probably isn't: '1' on line 1170
== Missing Reference: 'I-D.ARC' is mentioned on line 1021, but not defined
-- Looks like a reference, but probably isn't: '3' on line 1174
-- Looks like a reference, but probably isn't: '4' on line 2050
-- Looks like a reference, but probably isn't: '5' on line 2051
== Unused Reference: 'RFC1345' is defined on line 1040, but no explicit
reference was found in the text
== Unused Reference: 'RFC2142' is defined on line 1049, but no explicit
reference was found in the text
== Unused Reference: 'RFC2606' is defined on line 1053, but no explicit
reference was found in the text
== Unused Reference: 'RFC4686' is defined on line 1061, but no explicit
reference was found in the text
== Unused Reference: 'RFC5226' is defined on line 1065, but no explicit
reference was found in the text
== Unused Reference: 'RFC5321' is defined on line 1075, but no explicit
reference was found in the text
== Unused Reference: 'RFC5322' is defined on line 1079, but no explicit
reference was found in the text
== Unused Reference: 'RFC5585' is defined on line 1083, but no explicit
reference was found in the text
== Unused Reference: 'RFC5863' is defined on line 1092, but no explicit
reference was found in the text
== Unused Reference: 'RFC6651' is defined on line 1107, 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)
== Outdated reference: A later version (-23) exists of
draft-ietf-dmarc-arc-protocol-06
== Outdated reference: A later version (-23) exists of
draft-ietf-dmarc-arc-protocol-05
-- Duplicate reference: draft-ietf-dmarc-arc-protocol, mentioned in
'ARC-DRAFT-06', was also mentioned in 'ARC-DRAFT-05'.
== Outdated reference: A later version (-09) exists of
draft-ietf-dmarc-arc-usage-01
-- Obsolete informational reference (is this intentional?): RFC 6982
(Obsoleted by RFC 7942)
Summary: 7 errors (**), 0 flaws (~~), 15 warnings (==), 8 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: March 10, 2018 Google
6 S. Jones, Ed.
7 M. Kucherawy, Ed.
8 TDP
9 September 06, 2017
11 Authenticated Received Chain (ARC) Protocol
12 draft-ietf-dmarc-arc-protocol-09
14 Abstract
16 The Authenticated Received Chain (ARC) protocol creates a mechanism
17 whereby a series of handlers of an email message can conduct
18 authentication of the email message as it passes among them on the
19 way to its destination, and record the status of that authentication
20 at each step along the handling path, for use by the final recipient
21 in making choices about the disposition of the message. Changes in
22 the message that might break DKIM or DMARC can be identified through
23 the ARC set of header fields.
25 Status of This Memo
27 This Internet-Draft is submitted in full conformance with the
28 provisions of BCP 78 and BCP 79.
30 Internet-Drafts are working documents of the Internet Engineering
31 Task Force (IETF). Note that other groups may also distribute
32 working documents as Internet-Drafts. The list of current Internet-
33 Drafts is at https://datatracker.ietf.org/drafts/current/.
35 Internet-Drafts are draft documents valid for a maximum of six months
36 and may be updated, replaced, or obsoleted by other documents at any
37 time. It is inappropriate to use Internet-Drafts as reference
38 material or to cite them other than as "work in progress."
40 This Internet-Draft will expire on March 10, 2018.
42 Copyright Notice
44 Copyright (c) 2017 IETF Trust and the persons identified as the
45 document authors. All rights reserved.
47 This document is subject to BCP 78 and the IETF Trust's Legal
48 Provisions Relating to IETF Documents
49 (https://trustee.ietf.org/license-info) in effect on the date of
50 publication of this document. Please review these documents
51 carefully, as they describe your rights and restrictions with respect
52 to this document. Code Components extracted from this document must
53 include Simplified BSD License text as described in Section 4.e of
54 the Trust Legal Provisions and are provided without warranty as
55 described in the Simplified BSD License.
57 Table of Contents
59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
60 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
61 3. Definitions and Terminology . . . . . . . . . . . . . . . . . 5
62 3.1. Referenced Definitions . . . . . . . . . . . . . . . . . 6
63 4. Instance ('i=') Tag . . . . . . . . . . . . . . . . . . . . . 6
64 4.1. Valid Range for Instance Tags . . . . . . . . . . . . . . 7
65 5. The ARC Header Fields . . . . . . . . . . . . . . . . . . . . 7
66 5.1. ARC-Authentication-Results (AAR) . . . . . . . . . . . . 7
67 5.1.1. Additional Information for the AAR Header . . . . . . 7
68 5.2. ARC-Message-Signature (AMS) . . . . . . . . . . . . . . . 8
69 5.3. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . . . 8
70 5.3.1. The 'cv' Tag . . . . . . . . . . . . . . . . . . . . 9
71 5.3.2. Selected Header Fields . . . . . . . . . . . . . . . 9
72 6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . 10
73 7. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . 11
74 8. Key Management . . . . . . . . . . . . . . . . . . . . . . . 12
75 9. Usage of ARC and Chain Validity . . . . . . . . . . . . . . . 12
76 9.1. Relationship between DKIM-Signature and AMS signing
77 scopes . . . . . . . . . . . . . . . . . . . . . . . . . 12
78 9.2. Assessing Chain Validity Violations . . . . . . . . . . . 12
79 9.3. Marking and Sealing "cv=fail" (Invalid) Chains . . . . . 13
80 9.4. Handling DNS Problems While Validating ARC . . . . . . . 13
81 9.5. Responding to ARC Validity Violations . . . . . . . . . . 13
82 10. Recording and Reporting the Results of ARC Evaluation . . . . 13
83 10.1. Information from an ARC Evaluation . . . . . . . . . . . 13
84 10.2. Recording (local) ARC Evaluation Results . . . . . . . . 14
85 10.3. DMARC Reporting of ARC Findings - Interim . . . . . . . 14
86 11. Supporting Alternate Signing Algorithms . . . . . . . . . . . 15
87 11.1. Introductory Period . . . . . . . . . . . . . . . . . . 15
88 11.2. Co-Existence Period . . . . . . . . . . . . . . . . . . 15
89 11.3. Deprecation Period . . . . . . . . . . . . . . . . . . . 15
90 11.4. Obsolescence Period . . . . . . . . . . . . . . . . . . 15
91 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15
92 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
93 13.1. Authentication-Results Method Registry Update . . . . . 16
94 13.2. Definitions of the ARC header fields . . . . . . . . . . 16
95 14. Security Considerations . . . . . . . . . . . . . . . . . . . 17
96 14.1. Message Content Suspicion . . . . . . . . . . . . . . . 17
98 15. Implementation Status . . . . . . . . . . . . . . . . . . . . 18
99 15.1. GMail test reflector and incoming validation . . . . . . 18
100 15.2. AOL test reflector and internal tagging . . . . . . . . 19
101 15.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 19
102 15.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . 20
103 15.5. Mailman 3.1+ patch . . . . . . . . . . . . . . . . . . . 20
104 15.6. Copernica/MailerQ web-based validation . . . . . . . . . 21
105 15.7. Rspamd . . . . . . . . . . . . . . . . . . . . . . . . . 21
106 15.8. PERL Mail::Milter::Authentication module . . . . . . . . 22
107 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
108 16.1. Normative References . . . . . . . . . . . . . . . . . . 22
109 16.2. Informative References . . . . . . . . . . . . . . . . . 24
110 16.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25
111 Appendix A. Appendix A - Design Requirements . . . . . . . . . . 25
112 A.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 25
113 A.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 26
114 Appendix B. Appendix B - Example Usage . . . . . . . . . . . . . 26
115 B.1. Example 1: Simple mailing list . . . . . . . . . . . . . 26
116 B.1.1. Here's the message as it exits the Origin: . . . . . 26
117 B.1.2. Message is then received at example.org . . . . . . . 27
118 B.1.3. Example 1: Message received by Recipient . . . . . . 29
119 B.2. Example 2: Mailing list to forwarded mailbox . . . . . . 30
120 B.2.1. Here's the message as it exits the Origin: . . . . . 30
121 B.2.2. Message is then received at example.org . . . . . . . 31
122 B.2.3. Example 2: Message received by Recipient . . . . . . 35
123 B.3. Example 3: Mailing list to forwarded mailbox with source 37
124 B.3.1. Here's the message as it exits the Origin: . . . . . 37
125 B.3.2. Message is then received at example.org . . . . . . . 38
126 B.3.3. Example 3: Message received by Recipient . . . . . . 43
127 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 45
128 Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 46
129 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
131 1. Introduction
133 Modern email authentication techniques such as the Sender Policy
134 Framework (SPF) [RFC7208] and DomainKeys Identified Mail (DKIM)
135 [RFC6376] have become common.
136 However, their end-to-end utility is limited by the effects of
137 intermediaries along the transmission path, which either are not
138 listed (for SPF) or which break digital signatures (for DKIM). These
139 issues are described in substantial detail in those protocols'
140 defining documents as well as in [RFC6377] and [RFC7960].
142 Technologies that build upon the use of SPF and DKIM can reduce the
143 success of fraudulent email campaigns. To this end, Domain-based
144 Mail Authentication, Reporting and Compliance (DMARC) [RFC7489],
145 validates the domain of the RFC5322.From author header field.
147 However its use along email transmission paths that have independent
148 intermediaries, such as some forwarders and essentially all mailing
149 list services, produces false positive rejections that are
150 problematic, both for the message authors, the intermediary
151 service(s), and for those they are interacting with.
153 What is needed is a mechanism by which legitimate alteration of a
154 message, which invalidates associated SPF and DKIM information, does
155 not ultimately result in a rejection of an email message on delivery.
156 Authenticated Receive Chain (ARC) builds upon DKIM mechanisms to
157 provide a sequence of signatures that are more survivable than DKIM's
158 and that provide a view of the handling sequence for a message,
159 especially the points where alterations of the content might have
160 occurred. Equipped with this more complete information, the
161 recipient system(s) can make a more informed handling choice,
162 reducing or eliminating the false negatives inherent in use of DKIM
163 and/or SPF themselves.
165 2. Overview
167 In DKIM, every participating signing agent attaches a signature that
168 is based on the some of the content of the message, local policy, and
169 the domain name of the participating Administrative Management Domain
170 (ADMD). Any verifier can process such a signature; a verified
171 signature means that the domain referenced in the DKIM-Signture's
172 "d=" parameter has some responsibility for handling the message. An
173 artifact of using digital signature technology for this means that
174 verification also ensures that the message content that was "covered"
175 by the signature has not been altered since the signature was
176 applied. The signatures themselves are generally independent of one
177 another.
179 By contrast, an ARC signature conveys the following pieces of
180 information:
182 1. An assertion that, at the time that the intermediary ADMD
183 processed the message, the various assertions (DKIM-Signature(s)
184 and/or ARC sets) already attached to the message by other ADMDs
185 were or were not valid;
187 2. As with DKIM, an assertion that, for a validated signature, the
188 domain name in the signature takes some responsibility for
189 handling of the message and that the message is unchanged since
190 that signature was applied;
192 3. A further assertion that binds the ARC evaluation results into
193 the ARC chain sequence.
195 This protocol accomplishes each of these by adding a new header field
196 to the message for each of these pieces of information, as follows:
198 o ARC-Authentication-Results (referred to below as "AAR"): virtually
199 identical in syntax to an Authentication-Results field [RFC7601],
200 this field records the results of all message authentication
201 checks done by the recording ADMD at the time the message arrived.
202 Additional information is placed in this field compared to a
203 standard Authentication-Results field in order to support a more
204 complete DMARC report (see Section 5.1);
206 o ARC-Message-Signature (referred to below as "AMS"): virtually
207 identical in syntax to DKIM-Signature, this field contains the
208 signature about the message header and body as they existed at the
209 time of handling by the ADMD adding it; and
211 o ARC-Seal (referred to below as "AS"): highly similar in structure
212 and format to a DKIM-Signature, this field applies a digital
213 signature that protects the integrity of all three of these new
214 fields when they are added by an ADMD, plus all instances of these
215 fields added by prior ADMDs.
217 A distinguishing feature of all of these is that an ARC participant
218 always adds all of them before relaying a message to the next
219 handling agent en route to its destination. Moreover, as described
220 in Section 4, they each have an "instance" number that increases with
221 each ADMD in the handling chain so that their original order can be
222 preserved and the three related header fields can be processed as a
223 group.
225 3. Definitions and Terminology
227 This section defines terms used in the rest of the document.
229 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
230 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
231 document are to be interpreted as described in [RFC2119].
233 Because many of the core concepts and definitions are found in
234 [RFC5598], readers SHOULD to be familiar with the contents of
235 [RFC5598], and in particular, the potential roles of intermediaries
236 in the delivery of email.
238 Syntax descriptions use Augmented BNF (ABNF) [RFC5234].
240 o "ARC set" - A single group of the header fields introduced in
241 Section 2 is called an "ARC set".
243 o "ARC chain" - The complete sequence of these groups (ARC sets) is
244 called an "Authenticated Received Chain" or merely an "ARC chain".
245 Although the "Received" header field is typically not included in
246 the signed content, the name is based on the notion that this is
247 in essence a cryptographically signed series of header fields that
248 attest to the handling chain of a message much as Received fields
249 always have.
251 3.1. Referenced Definitions
253 The following terms are defined in other RFCs. Those definitions can
254 be found as follows:
256 o ADMD - [RFC5598], Section 2.3
258 o MTA - [RFC5598], Section 4.3.2
260 o MSA - [RFC5598], Section 4.3.1
262 o MDA - [RFC5598], Section 4.3.3
264 The three header fields that are part of this specification borrow
265 heavily from existing specifications. Rather than repeating all of
266 the formal definitions that are being reused in ARC, this document
267 only describes and specifies changes in syntax and semantics.
269 Language, syntax, and other details are imported from DKIM [RFC6376].
270 Specific references can be found below.
272 4. Instance ('i=') Tag
274 The header fields comprising a single ARC set are identified by the
275 presence of a string in the value portion of the header field that
276 complies with the "tag-spec" ABNF found in Section 3.2 of [RFC6376].
277 The tag-name is "i" and the value is the text representation of a
278 positive integer, indicating the position in the ARC sequence this
279 set occupies, where the first ARC set is numbered 1. In ABNF terms:
281 instance = [FWS] %x69 [FWS] "=" [FWS] position [FWS] ";"
282 position = 1*DIGIT
284 Valid ARC sets must have exactly one instance of each header field
285 for a given position value. (Note that when multiple algorithms are
286 supported, there is some nuance to this statement - see Section 11.)
288 Because the AMS and AS header field values are made up of tag-spec
289 constructs, the i= tag may be found anywhere within the header field
290 value, but is represented throughout this spec in the initial
291 position for convenience. Implementers are encouraged to place the
292 i= tag at the beginning of the field value to facilitate human
293 inspection of the headers.
295 4.1. Valid Range for Instance Tags
297 The 'i' tag value can range from 1-1024 (inclusive).
299 ARC implementations MUST support at least ten (10) ARC sets.
301 An effective operational maximum will have to be developed through
302 deployment experience in the field and will be documented within
303 [ARC-USAGE] once determined.
305 ARC chains with more than the defined operational maximum count MAY
306 be marked with "cv=fail".
308 5. The ARC Header Fields
310 5.1. ARC-Authentication-Results (AAR)
312 The ARC-Authentication-Results header field is syntactically and
313 semantically identical to an Authentication-Results header field
314 (defined in Section 2.2 of [RFC7601] (A-R)), except for one mandatory
315 addition and several optional data fields. These deviations are:
317 o There is an "i" tag, as described in Section 4; and
319 o Two (or more) additional pieces of information MAY be added (see
320 Section 5.1.1).
322 The instance identifier MUST be separated from the rest of the
323 Authentication-Results value contents with a semi-colon (';', 0x3b).
325 The purpose of this header field is to incorporate into the record
326 the success or failure of any authentication done on the message
327 upstream of the participating ADMD that is validating and continuing
328 the authentication chain.
330 The AAR MUST contain all A-R results from within the participating
331 ADMD, regardless of how many A-R headers are on the message.
333 5.1.1. Additional Information for the AAR Header
335 An ARC signer generates this field in the same way that a
336 conventional A-R field would be generated. Because the AAR is
337 designed for machine-based consumption over the course of a message's
338 transit through a series of mediators and to facilitate
339 troubleshooting of problematic sources by sending organizations,
340 three additional fields of data SHOULD be added to the normal A-R
341 content, dependent on the presence of DKIM-Signature and/or ARC
342 set(s) and if available to the ADMD which is recording the A-R:
344 o smtp.client_id - The connecting client IP address from which the
345 message was received;
347 o header.ds - The domain/selector pair for each dkim signature on
348 the message (header.ds=example.com,selector)
350 o arc.closest_fail - The hop number of the most recent AMS that
351 fails to validate, or 0 if all hops pass.
353 5.2. ARC-Message-Signature (AMS)
355 The ARC-Message-Signature header field is syntactically and
356 semantically identical to a DKIM-Signature header field [RFC6376],
357 with the following exceptions:
359 o There is an "i" tag, as described in Section 4.
361 o There is no "v" tag.
363 ARC-Seal header fields MUST NOT be included in the content covered by
364 the signature in this header field.
366 The AMS SHOULD include any DKIM-Signature header fields already
367 present on the message in the header fields covered by this
368 signature.
370 The AMS header field MAY include (sign) the AAR header field(s).
372 Authentication-Results header fields SHOULD NOT be included since
373 they are likely to be deleted by downstream ADMDs (per Section XXX of
374 [RFC7601]), thereby breaking the AMS signature.
376 As with a DKIM-Signature, the purpose of this header field is to
377 allow the ADMD generating it to take some responsibility for handling
378 this message as it progresses toward delivery.
380 5.3. ARC-Seal (AS)
382 The ARC-Seal header field is syntactically and semantically similar
383 to a DKIM-Signature field, with the following exceptions:
385 o There is an "i" tag, as described in Section 4.
387 o The ARC-Seal covers none of the body content of the message. It
388 only covers specific header fields. (See below: Section 5.3.2.)
389 As a result, no body canonicalization is done. Further, only
390 "relaxed" header canonicalization (Section 3.4.2 of [RFC6376]) is
391 used.
393 o The only supported tags are "i" (Section 4 supercedes the
394 [RFC6376] definition), and "a", "b", "d, "s", "t". The latter 5
395 tag definitions are copied from Section 3.5 of [RFC6376].
397 o An additional tag, "cv" is defined. (See below: Section 5.3.1)
399 5.3.1. The 'cv' Tag
401 A new tag "cv" (chain validation) indicates the the outcome of
402 evaluating the existing ARC chain upon arrival at the ADMD that is
403 adding this header field. It accepts one of three possible values:
405 o none: There was no chain on the message when it arrived for
406 validation; typically occurs when the message arrives at a Message
407 Transfer Agent (MTA) from a Message Submission Agent (MSA) or when
408 any upstream MTAs may not be participating in ARC handling;
410 o fail: The message has a chain whose validation failed;
412 o pass: The message has a chain whose validation succeeded.
414 In ABNF terms:
416 seal-cv-tag = %x63.76 [FWS] "=" [FWS] ("none" / "fail" / "pass")
418 5.3.2. Selected Header Fields
420 [[ Note: reword sentence 1 per Dave's comments ]]
422 The ARC-Seal signature is a signature of the hash of the
423 concatenation of the canonicalized form of the ARC sets present on
424 the message at the time of sealing, in increasing instance order,
425 starting at 1, including the one being added at the time of sealing
426 the message.
428 Within a set, the header fields are listed in the following order:
430 1. ARC-Authentication-Results
432 2. ARC-Message-Signature
434 3. ARC-Seal
435 Where the ARC-Seal is the one being generated, it is input to the
436 hash function in its final form except with an empty "b=" value, in
437 the same manner by which a DKIM-Signature signs itself.
439 Note that the signing scope for the ARC-Seal is modified in the
440 situation where a chain has failed validation (see Section 9.3).
442 6. Verifier Actions
444 The verifier takes the following steps to determine the current state
445 of the ARC chain on the message. Canonicalization, hash functions,
446 and signature validation methods are imported from Section 5 of
447 [RFC6376].
449 [[ Note: need markdown flag to have subordinate numbering distinction
450 ]]
452 1. Collect all ARC sets currently on the message. If there were
453 none, the ARC state is "none" and the algorithm stops here.
455 2. If the form of any ARC set is invalid (e.g., does not contain
456 exactly one of each of the three ARC-specific header fields),
457 then the chain state is "fail" and the algorithm stops here.
459 1. To avoid the overhead of unnecessary computation and delay
460 from crypto and DNS operations, the cv value for all ARC-
461 Seal(s) MAY be checked at this point. If any of the values
462 are "fail", then the overall state of the chain is "fail" and
463 the algorithm stops here.
465 3. Conduct verification of the ARC-Message-Signature header field
466 bearing the highest instance number. If this verification fails,
467 then the chain state is "fail" and the algorithm stops here.
469 4. For each ARC-Seal from the "N"th instance to the first, apply the
470 following logic:
472 1. If the value of the "cv" tag on that seal is "fail", the
473 chain state is "fail" and the algorithm stops here. (This
474 step SHOULD be skipped if the earlier step (2.1) was
475 performed)
477 2. In Boolean nomenclature: if ((i == 1 && cv != "none") or (cv
478 == "none" && i != 1)) then the chain state is "fail" and the
479 algorithm stops here (note that the ordering of the logic is
480 structured for short-circuit evaluation).
482 3. Initialize a hash function corresponding to the "a" tag of
483 the ARC-Seal.
485 4. Compute the canonicalized form of the ARC header fields, in
486 the order described in Section 5.3.2, using the "relaxed"
487 header canonicalization defined in Section 3.4.2 of
488 [RFC6376]. Pass the canonicalized result to the hash
489 function.
491 5. Retrieve the final digest from the hash function.
493 6. Retrieve the public key identified by the "s" and "d" tags in
494 the ARC-Seal, as described in Section 8.
496 7. Determine whether the signature portion ("b" tag) of the ARC-
497 Seal and the digest computed above are valid according to the
498 public key. (See also Section Section 9.4 for failure case
499 handling)
501 8. If the signature is not valid, the chain state is "fail" and
502 the algorithm stops here.
504 5. If all seals pass validation, then the chain state is "pass", and
505 the algorithm is complete.
507 [[ Note from Dave: possibly delete the following paragraph as it is
508 more usage/procedural than specification guidance. KA: It was added
509 to clarify the separation of the verification and signing steps as
510 some of the initial implementations failed to realize that they were
511 not necessarily done in one fell swoop. ]]
513 The verifier should save the cv state for subsequent use by any
514 sealing which may be done later (potentially after message
515 modification) within the same trust boundary. The cv state may be
516 recorded by sealing at the time of verification in an initial ARC set
517 (for the ADMD) or may be recorded out of band depending on the
518 architecture of the ADMD.
520 7. Signer Actions
522 [[ Note from Dave: This seems more like implementation guidance than
523 specification detail. KA: see explanation just above referring to
524 the previous note. ]]
526 This section includes a specification of the actions an ARC signer
527 takes when presented with a message.
529 The signer MUST undertake the following steps:
531 1. Before creating an ARC signature, perform any other, normal
532 authentication and/or signing, so that the ARC signature can
533 cover those results.
535 2. Build and attach the new ARC set:
537 1. If an ARC chain exists on the message, then set "N" equal to
538 the highest instance number found on the chain (i=);
539 otherwise set "N" equal to zero for the following steps.
541 2. Generate and attach to the message an ARC-Authentication-
542 Results header field using instance number N+1 and the same
543 content from the previous step.
545 3. Generate and attach to the message an ARC-Message-Signature
546 header field as defined in Section 5.2 above, using instance
547 number N+1.
549 4. Generate and attach to the message an ARC-Seal header field
550 using the general algorithm described in Section 5.3 above,
551 the chain validation status as determined in Section 6, and
552 instance number N+1.
554 8. Key Management
556 The public keys for ARC header fields follow the same requirements,
557 syntax and semantics as those for DKIM signatures, described in
558 Section 3.6 of [RFC6376]. For operational convenience, signers MAY
559 choose to use selectors and/or domains for the ARC header field
560 signatures that are distinct from those used in DKIM signing.
562 9. Usage of ARC and Chain Validity
564 9.1. Relationship between DKIM-Signature and AMS signing scopes
566 DKIM-Signatures SHOULD never sign any ARC header fields.
568 [[ KA: Response to Dave's concern: If DKIM covers ARC and ARC covers
569 DKIM, which comes first? The chicken or the egg? I'm open to
570 alternate ways to phrase this without opening the "modifying the DKIM
571 spec" can of worms. ]]
573 9.2. Assessing Chain Validity Violations
575 Email transit can produce broken signatures for a wide variety of
576 benign reasons. This includes possibly breaking one or more ARC
577 signatures. Therefore, receivers need to be wary of ascribing motive
578 to such breakage although patterns of common behaviour may provide
579 some basis for adjusting local policy decisions.
581 ARC does not attempt to protect an entire message. There are various
582 ways that a message can still be problematic, in spite of having a
583 valid ARC chain. Consequently, all normal, content-based analysis
584 SHOULD still be performed on any message having a valid chain of ARC
585 header sets.
587 9.3. Marking and Sealing "cv=fail" (Invalid) Chains
589 The header fields signed by the AS header field b= value in the case
590 of a chain failure MUST be only the matching 'i=' instance headers
591 created by the MTA which detected the malformed chain, as if this
592 newest ARC set was the only set present.
594 9.4. Handling DNS Problems While Validating ARC
596 DNS-based failures to verify a chain are treated no differently than
597 any other ARC violation. They result in a "cv=fail" verdict.
599 9.5. Responding to ARC Validity Violations
601 If a receiver determines that the ARC chain has failed, the receiver
602 MAY signal the breakage through the extended SMTP response code 5.7.7
603 [RFC3463] "message integrity failure" [ENHANCED-STATUS] and
604 corresponding SMTP response code.
606 10. Recording and Reporting the Results of ARC Evaluation
608 The evaluation of an ARC chain provides information which will be
609 useful to both the receiver (or intermediary) and to the initial
610 sender of the message. This information should be preserved and
611 reported as follows.
613 10.1. Information from an ARC Evaluation
615 The evaluation of an ARC chain produces a list of domain names for
616 participating intermediaries which handled the message, to wit:
618 o A list of the "d=" domains found in the validated ARC-Seal header
619 fields
621 o The "d=" domain found in the most recent (highest instance number)
622 AMS header field (since that is the only one necessarily
623 validated)
625 In the case of a failed chain, only the terminal ARC set is covered
626 by the ARC-Seal so the reporting is limited to the findings in that
627 terminal ARC set.
629 10.2. Recording (local) ARC Evaluation Results
631 Receivers MAY add an "arc=[pass|fail|policy]" method annotation into
632 a locally-affixed Authentication-Results [RFC7601] header field along
633 with any salient comment(s).
635 Details of the ARC chain which was evaluated should be included in
636 the Authentication-Results and AAR headers per Section Section 5.1.1.
638 10.3. DMARC Reporting of ARC Findings - Interim
640 [[ Note: Discussion on the IETF DMARC-WG list has indicated some
641 interest in more substantial reporting for analytic purposes. To
642 support that effort, the following guidance is provided only as an
643 interim, minimal data set. A more complete reporting construct will
644 be specified in a related spec - TBD. (see the additional fields
645 specified in Section 5.1.1) ]]
647 Receivers SHOULD indicate situations in which ARC evaluation
648 influenced the results of their local policy determination. DMARC
649 reporting of ARC-informed decisions can be accomplished by adding a
650 local_policy comment explanation containing the list of data
651 discovered in the ARC evaluation (Section 10.1 and Section 5.1.1):
653
654 delivered
655 fail
656 fail source.ip=10.0.0.1
657
658 local_policy
659 arc=pass ams[2].d=d2.example ams[2].s=s1 as[2].d=d2.example
660 as[2].s=s2 as[1].d=d1.example as[1].s=s3
661
662
664 In the suggested sample, d2.example is the sealing domain for ARC[2]
665 and d1.example is the sealing domain for ARC[1].
667 Mediators SHOULD generate DMARC reports on messages which transit
668 their system just like any other message which they receive. This
669 will result in multiple reports for each mediated message as they
670 transit the series of handlers. DMARC report consumers should be
671 aware of this behaviour and make the necessary accommodations.
673 11. Supporting Alternate Signing Algorithms
675 [[ Note: Some additional development of this section is needed. ]]
677 In the following branch diagrams, each algorithm is represented by an
678 'A' or 'B' at each hop to depict the ARC chain that develops over a
679 five hop scenario. 'x' represents a hop that does not support that
680 algorithm.
682 Note that during a transitional period where multiple algorithms are
683 allowed, all of the statements in this spec which refer to "exactly
684 one set of ARC headers per instance" need to be understood as "at
685 least one set per instance and no more than one instance-set per
686 algorithm".
688 11.1. Introductory Period
690 Intermediaries MUST be able to validate ARC chains built with either
691 algorithm but MAY create ARC sets with either (or both) algorithm.
693 The introductory period should be at least six (6) months.
695 11.2. Co-Existence Period
697 Intermediaries MUST be able to validate ARC chains build with either
698 algorithm and MUST create ARC sets with both algorithms. Chains
699 ending with either algorithm may be used for the result.
701 11.3. Deprecation Period
703 ARC sets built with algorithms that are being deprecated MAY be
704 considered valid within an ARC chain, however, intermediaries MUST
705 NOT create additional sets with the deprecated algorithm.
707 The deprecation period should be at least two (2) years.
709 11.4. Obsolescence Period
711 ARC sets built with algorithms that are obsolete MUST NOT be
712 considered valid within an ARC chain. Intermediaries MUST NOT create
713 any sets with any obsoleted algorithm.
715 12. Privacy Considerations
717 The ARC chain provides a verifiable record of the handlers for a
718 message. Anonymous remailers will probably not find this compatible
719 with their operating goals.
721 13. IANA Considerations
723 This specification adds three new header fields as defined below.
725 13.1. Authentication-Results Method Registry Update
727 This draft adds one item to the IANA "Email Authentication Methods"
728 registry:
730 o Method : arc
732 Defined: [I-D.ARC]
734 ptype: header
736 Property: chain evaluation result
738 Value: chain evaluation result status (see Section 5.3)
740 Status: active
742 Version: 1
744 13.2. Definitions of the ARC header fields
746 This specification adds three new header fields to the "Permanent
747 Message Header Field Registry", as follows:
749 o Header field name: ARC-Seal
751 Applicable protocol: mail
753 Status: draft
755 Author/Change controller: IETF
757 Specification document(s): [I-D.ARC]
759 Related information: [RFC6376]
761 o Header field name: ARC-Message-Signature
763 Applicable protocol: mail
765 Status: draft
767 Author/Change controller: IETF
768 Specification document(s): [I-D.ARC]
770 Related information: [RFC6376]
772 o Header field name: ARC-Authentication-Results
774 Applicable protocol: mail
776 Status: standard
778 Author/Change controller: IETF
780 Specification document(s): [I-D.ARC]
782 Related information: [RFC7601]
784 14. Security Considerations
786 The Security Considerations of [RFC6376] and [RFC7601] apply directly
787 to this specification.
789 Inclusion of ARC sets in the header of emails may cause problems for
790 some older or more constrained MTAs if they are unable to accept the
791 greater size of the header.
793 Operators who receive a message bearing N ARC sets have to complete
794 up to N+1 DNS queries to evaluate the chain (barring DNS redirection
795 mechanisms which can increase the lookups for a given target value).
796 This has at least two effects:
798 1. An attacker can send a message to an ARC partipant with a
799 concocted sequence of ARC sets bearing the domains of intended
800 victims, and all of them will be queried by the participant until
801 a failure is discovered. The difficulty of forging the signature
802 values should limit the extent of this load to domains under
803 control of the attacker.
805 2. DKIM only does one DNS check per signature, while this one can do
806 many (per chain). Absent caching, slow DNS responses can cause
807 SMTP timeouts; and backlogged delivery queues on mediating
808 systems. This could be exploited as a DoS attack.
810 14.1. Message Content Suspicion
812 Recipients are cautioned to treat messages bearing ARC sets with the
813 same suspicion that they apply to all other email messages. This
814 includes appropriate content scanning and other checks for
815 potentially malicious content. The handlers which are identified
816 within the ARC chain may be used to provide input to local policy
817 engines in cases where DMARC validation fails (due to mediation
818 impacting SPF attribution, DKIM validity or alignment).
820 15. Implementation Status
822 [[ Note: For minimizing section number references when the RFC editor
823 removes this section, it has been moved to be the last section of the
824 document before the Appendicies. ]]
826 [[ Note to the RFC Editor: Please remove this section before
827 publication along with the reference to [RFC6982]. ]]
829 This section records the status of known implementations of the
830 protocol defined by this specification at the time of posting of this
831 Internet-Draft, and is based on a proposal described in [RFC6982].
832 The description of implementations in this section is intended to
833 assist the IETF in its decision processes in progressing drafts to
834 RFCs. Please note that the listing of any individual implementation
835 here does not imply endorsement by the IETF. Furthermore, no effort
836 has been spent to verify the information presented here that was
837 supplied by IETF contributors. This is not intended as, and must not
838 be construed to be, a catalog of available implementations or their
839 features. Readers are advised to note that other implementations may
840 exist.
842 This information is known to be correct as of the seventh
843 interoperability test event which was held on 2017-07-15 & 16 at
844 IETF99.
846 15.1. GMail test reflector and incoming validation
848 Organization: Google
850 Description: Internal production implementation with both debug
851 analysis and validating + sealing pass-through function
853 Status of Operation: Production - Incoming Validation
855 Coverage: Full spec implemented as of [ARC-DRAFT-06]
857 Licensing: Proprietary - Internal only
859 Implementation Notes:
861 o Full functionality was demonstrated during the interop testing on
862 2017-07-15.
864 Contact Info: arc-discuss@dmarc.org [1]
866 15.2. AOL test reflector and internal tagging
868 Organization: AOL
870 Description: Internal prototype implementation with both debug
871 analysis and validating + sealing pass-through function
873 Status of Operation: Beta
875 Coverage: ARC chain validity status checking is operational, but only
876 applied to email addresses enrolled in the test program. This system
877 conforms to [ARC-DRAFT-06]
879 Licensing: Proprietary - Internal only
881 Implementation Notes:
883 o 2017-07-15: Full functionality verified during the interop
884 testing.
886 Contact Info: arc-discuss@dmarc.org [2]
888 15.3. dkimpy
890 Organization: dkimpy developers/Scott Kitterman
892 Description: Python DKIM package
894 Status of Operation: Production
896 Coverage:
898 o 2017-07-15: The internal test suite is incomplete, but the command
899 line developmental version of validator was demonstrated to
900 interoperate with the Google and AOL implementations during the
901 interop on 2017-07-15 and the released version passes the tests in
902 [ARC-TEST] (https://github.com/ValiMail/arc_test_suite) with both
903 python and python3.
905 Licensing: Open/Other (same as dkimpy package = BCD version 2)
907 Contact Info: https://launchpad.net/dkimpy
909 15.4. OpenARC
911 Organization: TDP/Murray Kucherawy
913 Description: Implemention of milter functionality related to the
914 OpenDKIM and OpenDMARC packages
916 Status of Operation: Beta
918 Coverage: Built to support [ARC-DRAFT-06]
920 Licensing: Open/Other (same as OpenDKIM and OpenDMARC packages)
922 Implementation Notes:
924 o The build is FreeBSD oriented but some packages have been built
925 for easier deployment on RedHat-based Linux platforms.
927 o 2017-07-15: Testing showed problems with the hash calculation for
928 the AMS header b= field. Several other bugs were discovered and
929 were either fixed during the following week of IETF meetings or
930 are under active repair.
932 o Some issues still exist when deploying in a chained milter
933 arrangement (such as OpenSPF -> OpenDKIM -> OpenDMARC -> OpenARC)
934 with coordination between the stages. When deployed in a
935 "sandwich" configuration around an MLM, there is no effective
936 mechanism to convey trust from the ingress (validator) to egress
937 (signer) instances.
939 Contact Info: arc-discuss@dmarc.org [3]
941 15.5. Mailman 3.1+ patch
943 Organization: Mailman development team
945 Description: Integrated ARC capabilities within the Mailman 3.1+
946 package
948 Status of Operation: Patch submitted
950 Coverage: Unknown
952 Licensing: Same as mailman package - GPL
954 Implementation Notes:
956 o Appears to work properly in at least one beta deployment, but
957 waiting on acceptance of the pull request into the mainline of
958 mailman development
960 Contact Info: https://www.gnu.org/software/mailman/contact.html
962 15.6. Copernica/MailerQ web-based validation
964 Organization: Copernica
966 Description: Web-based validation of ARC-signed messages
968 Status of Operation: Beta
970 Coverage: Built to support [ARC-DRAFT-05]
972 Licensing: On-line usage only
974 Implementation Notes:
976 o Released 2016-10-24
978 o Requires full message content to be pasted into a web form found
979 at http://arc.mailerq.com/ (warning - https is not supported).
981 o An additional instance of an ARC signature can be added if one is
982 willing to paste a private key into an unsecured web form.
984 o 2017-07-15: Testing shows that results match the other
985 implementations listed in this section.
987 Contact Info: https://www.copernica.com/
989 15.7. Rspamd
991 Organization: Rspamd community
993 Description: ARC signing and verification module
995 Status of Operation: Production, though deployment usage is unknown
997 Coverage: Built to support [ARC-DRAFT-06]
999 Licensing: Open source
1001 Implementation Notes:
1003 o 2017-06-12: Released with version 1.6.0
1004 o 2017-07-15: Testing during the interop showed that the validation
1005 functionality interoperated with the Google, AOL, dkimpy and
1006 MailerQ implementations
1008 Contact Info: https://rspamd.com/doc/modules/arc.html and
1009 https://github.com/vstakhov/rspamd
1011 15.8. PERL Mail::Milter::Authentication module
1013 Organization: FastMail
1015 Description: Email domain authentication milter, previously included
1016 SPF / DKIM / DMARC, now has ARC added
1018 Status of Operation: Intial validation completed during IETF99
1019 hackathon with some follow-on work during the week
1021 Coverage: Built to support [I-D.ARC]
1023 Licensing: Open Source
1025 Implementation Notes:
1027 o 2017-07-15: Validation functionality which interoperates with
1028 Gmail, AOL, dkimpy was demonstrated; later in the week of IETF99,
1029 the signing functionality was reported to be working
1031 o 2017-07-20: ARC functionality has not yet been pushed back to the
1032 github repo but should be showing up soon
1034 Contact Info: https://github.com/fastmail/authentication_milter
1036 16. References
1038 16.1. Normative References
1040 [RFC1345] Simonsen, K., "Character Mnemonics and Character Sets",
1041 RFC 1345, DOI 10.17487/RFC1345, June 1992,
1042 .
1044 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1045 Requirement Levels", BCP 14, RFC 2119,
1046 DOI 10.17487/RFC2119, March 1997,
1047 .
1049 [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and
1050 Functions", RFC 2142, DOI 10.17487/RFC2142, May 1997,
1051 .
1053 [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS
1054 Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999,
1055 .
1057 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes",
1058 RFC 3463, DOI 10.17487/RFC3463, January 2003,
1059 .
1061 [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys
1062 Identified Mail (DKIM)", RFC 4686, DOI 10.17487/RFC4686,
1063 September 2006, .
1065 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
1066 IANA Considerations Section in RFCs", RFC 5226,
1067 DOI 10.17487/RFC5226, May 2008,
1068 .
1070 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
1071 Specifications: ABNF", STD 68, RFC 5234,
1072 DOI 10.17487/RFC5234, January 2008,
1073 .
1075 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
1076 DOI 10.17487/RFC5321, October 2008,
1077 .
1079 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
1080 DOI 10.17487/RFC5322, October 2008,
1081 .
1083 [RFC5585] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys
1084 Identified Mail (DKIM) Service Overview", RFC 5585,
1085 DOI 10.17487/RFC5585, July 2009,
1086 .
1088 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
1089 DOI 10.17487/RFC5598, July 2009,
1090 .
1092 [RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker,
1093 "DomainKeys Identified Mail (DKIM) Development,
1094 Deployment, and Operations", RFC 5863,
1095 DOI 10.17487/RFC5863, May 2010,
1096 .
1098 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
1099 "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
1100 RFC 6376, DOI 10.17487/RFC6376, September 2011,
1101 .
1103 [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and
1104 Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377,
1105 September 2011, .
1107 [RFC6651] Kucherawy, M., "Extensions to DomainKeys Identified Mail
1108 (DKIM) for Failure Reporting", RFC 6651,
1109 DOI 10.17487/RFC6651, June 2012,
1110 .
1112 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
1113 Authorizing Use of Domains in Email, Version 1", RFC 7208,
1114 DOI 10.17487/RFC7208, April 2014,
1115 .
1117 [RFC7601] Kucherawy, M., "Message Header Field for Indicating
1118 Message Authentication Status", RFC 7601,
1119 DOI 10.17487/RFC7601, August 2015,
1120 .
1122 16.2. Informative References
1124 [ARC-DRAFT-05]
1125 Andersen, K., Long, B., and S. Jones, "Authenticated
1126 Received Chain (ARC) Protocol (I-D-06)", n.d.,
1127 .
1130 [ARC-DRAFT-06]
1131 Andersen, K., Long, B., and S. Jones, "Authenticated
1132 Received Chain (ARC) Protocol (I-D-05)", n.d.,
1133 .
1136 [ARC-TEST]
1137 Blank, S., "ARC Test Suite", January 2017,
1138 .
1140 [ARC-USAGE]
1141 Jones, S., Adams, T., Rae-Grant, J., and K. Andersen,
1142 "Recommended Usage of the ARC Headers", December 2017,
1143 .
1146 [ENHANCED-STATUS]
1147 "IANA SMTP Enhanced Status Codes", n.d.,
1148 .
1151 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
1152 Code: The Implementation Status Section", RFC 6982,
1153 DOI 10.17487/RFC6982, July 2013,
1154 .
1156 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
1157 Message Authentication, Reporting, and Conformance
1158 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
1159 .
1161 [RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky,
1162 E., Ed., and K. Andersen, Ed., "Interoperability Issues
1163 between Domain-based Message Authentication, Reporting,
1164 and Conformance (DMARC) and Indirect Email Flows",
1165 RFC 7960, DOI 10.17487/RFC7960, September 2016,
1166 .
1168 16.3. URIs
1170 [1] mailto:arc-discuss@dmarc.org
1172 [2] mailto:arc-discuss@dmarc.org
1174 [3] mailto:arc-discuss@dmarc.org
1176 [4] mailto:dmarc@ietf.org
1178 [5] mailto:arc-discuss@dmarc.org
1180 Appendix A. Appendix A - Design Requirements
1182 (This section is re-inserted for background information from
1183 [ARC-DRAFT-06] and earlier versions.)
1185 The specification of the ARC framework is driven by the following
1186 high-level goals, security considerations, and practical operational
1187 requirements.
1189 A.1. Primary Design Criteria
1191 o Provide a verifiable "chain of custody" for email messages;
1193 o Not require changes for originators of email;
1194 o Support the verification of the ARC header field set by each hop
1195 in the handling chain;
1197 o Work at Internet scale; and
1199 o Provide a trustable mechanism for the communication of
1200 Authentication-Results across trust boundaries.
1202 A.2. Out of Scope
1204 ARC is not a trust framework. Users of the ARC header fields are
1205 cautioned against making unsubstantiated conclusions when
1206 encountering a "broken" ARC sequence.
1208 Appendix B. Appendix B - Example Usage
1210 [[ Note: The following examples were mocked up early in the
1211 definition process for the spec. They no longer reflect the current
1212 definition and need various updates which will be included in a
1213 future draft. ]]
1215 (Obsolete but retained for illustrative purposes)
1217 B.1. Example 1: Simple mailing list
1219 B.1.1. Here's the message as it exits the Origin:
1221 Return-Path:
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@dmarc.org
1239 Subject: Example 1
1241 Hey gang,
1242 This is a test message.
1243 --J.
1245 B.1.2. Message is then received at example.org
1247 B.1.2.1. Example 1, Step A: Message forwarded to list members
1249 Processing at example.org:
1251 o example.org performs authentication checks
1253 o No previous Authentication-Results or ARC-Seal headers are present
1255 o example.org adds ARC-Authentication-Results header
1257 o example.org adds Received: header
1259 o example.org adds a ARC-Seal header
1261 Here's the message as it exits example.org:
1263 Return-Path:
1264 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1265 s=seal2015; d=example.org; cv=none;
1266 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1267 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1268 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1269 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
1270 d=example.org; s=clochette; t=1421363105;
1271 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
1272 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
1273 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
1274 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1F5
1275 vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+m4bw
1276 a6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
1277 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
1278 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
1279 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
1280 (envelope-from jqd@d1.example)
1281 ARC-Authentication-Results: i=1; lists.example.org;
1282 spf=pass smtp.mfrom=jqd@d1.example;
1283 dkim=pass (1024-bit key) header.i=@d1.example;
1284 dmarc=pass
1285 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1286 (authenticated bits=0)
1287 by segv.d1.example with ESMTP id t0FN4a8O084569;
1288 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1289 (envelope-from jqd@d1.example)
1290 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
1291 s=20130426; t=1421363082;
1292 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1293 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
1294 Content-Transfer-Encoding;
1295 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
1296 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
1297 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1298 Message-ID: <54B84785.1060301@d1.example>
1299 Date: Thu, 14 Jan 2015 15:00:01 -0800
1300 From: John Q Doe
1301 To: arc@example.org
1302 Subject: [Lists] Example 1
1304 Hey gang,
1305 This is a test message.
1306 --J.
1308 B.1.3. Example 1: Message received by Recipient
1310 Let's say that the Recipient is example.com
1312 Processing at example.com:
1314 o example.com performs usual authentication checks
1316 o example.com adds Authentication-Results: header, Received header
1318 o Determines that message fails DMARC
1320 o Checks for ARC-Seal: header; finds one
1322 o Validates the signature in the ARC-Seal: header, which covers the
1323 ARC-Authentication-Results: header
1325 o example.com can use the ARC-Authentication-Results values or
1326 verify the DKIM-Signature from lists.example.org
1328 Here's what the message looks like at this point:
1330 Return-Path:
1331 Received: from example.org (example.org [208.69.40.157])
1332 by clothilde.example.com with ESMTP id
1333 d200mr22663000ykb.93.1421363207
1334 for ; Thu, 14 Jan 2015 15:02:40 -0800 (PST)
1335 Authentication-Results: clothilde.example.com; spf=fail
1336 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
1337 header.i=@example.org; dmarc=fail; arc=pass
1338 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1339 s=seal2015; d=example.org; cv=none;
1340 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1341 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1342 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1343 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
1344 d=example.org; s=clochette; t=1421363105;
1345 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
1346 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
1347 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
1348 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
1349 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
1350 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
1351 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
1352 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
1353 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
1354 (envelope-from jqd@d1.example)
1355 ARC-Authentication-Results: i=1; lists.example.org;
1356 spf=pass smtp.mfrom=jqd@d1.example;
1357 dkim=pass (1024-bit key) header.i=@d1.example;
1358 dmarc=pass
1359 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1360 (authenticated bits=0)
1361 by segv.d1.example with ESMTP id t0FN4a8O084569;
1362 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1363 (envelope-from jqd@d1.example)
1364 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
1365 s=20130426; t=1421363082;
1366 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1367 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
1368 Content-Transfer-Encoding;
1369 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw
1370 bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl
1371 gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1372 Message-ID: <54B84785.1060301@d1.example>
1373 Date: Thu, 14 Jan 2015 15:00:01 -0800
1374 From: John Q Doe
1375 To: arc@example.org
1376 Subject: [Lists] Example 1
1378 Hey gang,
1379 This is a test message.
1380 --J.
1382 B.2. Example 2: Mailing list to forwarded mailbox
1384 B.2.1. Here's the message as it exits the Origin:
1386 Return-Path:
1387 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1388 (authenticated bits=0)
1389 by segv.d1.example with ESMTP id t0FN4a8O084569;
1390 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1391 (envelope-from jqd@d1.example)
1392 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
1393 s=20130426; t=1421363082;
1394 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1395 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
1396 Content-Transfer-Encoding;
1397 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw
1398 bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl
1399 gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1400 Message-ID: <54B84785.1060301@d1.example>
1401 Date: Thu, 14 Jan 2015 15:00:01 -0800
1402 From: John Q Doe
1403 To: arc@example.org
1404 Subject: Example 1
1406 Hey gang,
1407 This is a test message.
1408 --J.
1410 B.2.2. Message is then received at example.org
1412 B.2.2.1. Example 2, Step A: Message forwarded to list members
1414 Processing at example.org:
1416 o example.org performs authentication checks
1418 o example.org applies standard DKIM signature
1420 o No previous Authentication-Results or ARC-Seal headers are present
1422 o example.org adds ARC-Authentication-Results header
1424 o example.org adds usual Received: header
1426 o example.org adds a ARC-Seal header
1428 Here's the message as it exits Step A:
1430 Return-Path:
1431 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1432 s=seal2015; d=example.org; cv=none;
1433 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
1434 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
1435 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1436 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
1437 d=example.org; s=clochette; t=1421363105;
1438 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
1439 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
1440 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
1441 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
1442 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
1443 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
1444 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
1445 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
1446 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
1447 (envelope-from jqd@d1.example)
1448 ARC-Authentication-Results: i=1; lists.example.org;
1449 spf=pass smtp.mfrom=jqd@d1.example;
1450 dkim=pass (1024-bit key) header.i=@d1.example;
1451 dmarc=pass
1452 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1453 (authenticated bits=0)
1454 by segv.d1.example with ESMTP id t0FN4a8O084569;
1455 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1456 (envelope-from jqd@d1.example)
1457 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
1458 s=20130426; t=1421363082;
1459 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1460 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
1461 Content-Transfer-Encoding;
1462 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
1463 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
1464 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1465 Message-ID: <54B84785.1060301@d1.example>
1466 Date: Thu, 14 Jan 2015 15:00:01 -0800
1467 From: John Q Doe
1468 To: arc@example.org
1469 Subject: [Lists] Example 1
1471 Hey gang,
1472 This is a test message.
1473 --J.
1475 B.2.2.2. Example 2, Step B: Message from list forwarded
1477 The message is delivered to a mailbox at gmail.com
1478 Processing at gmail.com:
1480 o gmail.com performs usual authentication checks
1482 o gmail.com adds Authentication-Results: and Received: header
1484 o Determines that message fails DMARC
1486 o Checks for ARC-Seal: header; finds one
1488 o Validates the signature in the ARC-Seal: header, which covers the
1489 ARC-Authentication-Results: header
1491 o Uses the ARC-Authentication-Results: values, but:
1493 o Instead of delivering message, prepares to forward message per
1494 user settings
1496 o Applies usual DKIM signature
1498 o gmail.com adds it's own ARC-Seal: header, contents of which are
1500 * version
1502 * sequence number ("i=2")
1504 * hash algorithm (SHA256 as example)
1506 * timestamp ("t=")
1508 * selector for key ("s=notary01")
1510 * domain for key ("d=gmail.com")
1512 * headers included in hash ("h=ARC-Authentication-Results:ARC-
1513 Seal")
1515 * Note: algorithm requires only ARC-Seals with lower sequence #
1516 be included, in ascending order
1518 * signature of the header hash
1520 Here's what the message looks like at this point:
1522 Return-Path:
1523 ARC-Seal: i=2; a=rsa-sha256; t=1421363253;
1524 s=notary01; d=gmail.com; cv=pass;
1525 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDWR
1526 YbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/sut
1527 txO+RRNr0fCFw==
1528 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed;
1529 d=gmail.com; s=20120806;
1530 h=mime-version:content-type:x-original-sender:
1531 x-original-authentication-results:precedence:mailing-list:
1532 list-id:list-post:list-help:list-archive:sender:reply-to:
1533 list-unsubscribe:DKIM-Signature;
1534 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=;
1535 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1536 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1537 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBmfhS
1538 LF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJRFeM
1539 KdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwDBJtXw
1540 bQoZyRtb6X6q0mYaszUB8kw==
1541 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10
1542 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST)
1543 Authentication-Results: i=2; gmail.com; spf=fail
1544 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
1545 header.i=@example.org; dmarc=fail; arc=pass
1546 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1547 s=seal2015; d=example.org; cv=none:
1548 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1549 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1550 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1551 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
1552 d=example.org; s=clochette; t=1421363105;
1553 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
1554 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
1555 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
1556 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
1557 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
1558 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
1559 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
1560 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
1561 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
1562 (envelope-from jqd@d1.example)
1563 ARC-Authentication-Results: i=1; lists.example.org;
1564 spf=pass smtp.mfrom=jqd@d1.example;
1565 dkim=pass (1024-bit key) header.i=@d1.example;
1566 dmarc=pass
1567 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1568 (authenticated bits=0)
1569 by segv.d1.example with ESMTP id t0FN4a8O084569;
1570 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1571 (envelope-from jqd@d1.example)
1572 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
1573 s=20130426; t=1421363082;
1574 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1575 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
1576 Content-Transfer-Encoding;
1577 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
1578 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
1579 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1580 Message-ID: <54B84785.1060301@d1.example>
1581 Date: Thu, 14 Jan 2015 15:00:01 -0800
1582 From: John Q Doe
1583 To: arc@example.org
1584 Subject: [Lists] Example 1
1586 Hey gang,
1587 This is a test message.
1588 --J.
1590 B.2.3. Example 2: Message received by Recipient
1592 Let's say that the Recipient is example.com
1593 Processing at example.com:
1595 o example.com performs usual authentication checks
1597 o example.com adds Authentication-Results: header, Received header
1599 o Determines that message fails DMARC
1601 o Checks for ARC-Seal: header; finds two
1603 o Validates the signature in the highest numbered ("i=2") ARC-Seal:
1604 header, which covers all previous ARC-Seal: and ARC-
1605 Authentication-Results: headers
1607 o Validates the other ARC-Seal header ("i=1"), which covers the ARC-
1608 Authentication-Results: header
1610 o example.com uses the ARC-Authentication-Results: values
1612 Here's what the message looks like at this point:
1614 Return-Path:
1615 Received: from mail-ob0-f188.google.com (mail-ob0-f188.google.com
1616 [208.69.40.157]) by clothilde.example.com with ESMTP id
1617 d200mr22663000ykb.93.1421363268
1618 for ; Thu, 14 Jan 2015 15:03:15 -0800 (PST)
1620 Authentication-Results: clothilde.example.com; spf=fail
1621 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
1622 header.i=@gmail.com; dmarc=fail; arc=pass
1623 ARC-Seal: i=2; a=rsa-sha256; t=1421363253;
1624 s=notary01; d=gmail.com; cv=pass;
1625 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDWR
1626 YbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/sut
1627 txO+RRNr0fCFw==
1628 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed;
1629 d=gmail.com; s=20120806;
1630 h=mime-version:content-type:x-original-sender:
1631 x-original-authentication-results:precedence:mailing-list:
1632 list-id:list-post:list-help:list-archive:sender:reply-to:
1633 :list-unsubscribe:DKIM-Signature;
1634 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=;
1635 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1636 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1637 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBmfhS
1638 LF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJRFeM
1639 KdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwDBJtXw
1640 bQoZyRtb6X6q0mYaszUB8kw==
1641 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10
1642 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST)
1643 Authentication-Results: i=2; gmail.com; spf=fail
1644 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
1645 header.i=@example.org; dmarc=fail; arc=pass
1646 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1647 s=seal2015; d=example.org; cv=none;
1648 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1649 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1650 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1651 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
1652 d=example.org; s=clochette; t=1421363105;
1653 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
1654 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
1655 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
1656 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
1657 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
1658 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
1659 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
1660 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
1661 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
1662 (envelope-from jqd@d1.example)
1663 ARC-Authentication-Results: i=1; lists.example.org;
1664 spf=pass smtp.mfrom=jqd@d1.example;
1665 dkim=pass (1024-bit key) header.i=@d1.example;
1666 dmarc=pass
1667 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1668 (authenticated bits=0)
1669 by segv.d1.example with ESMTP id t0FN4a8O084569;
1670 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1671 (envelope-from jqd@d1.example)
1672 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
1673 s=20130426; t=1421363082;
1674 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1675 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
1676 Content-Transfer-Encoding;
1677 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
1678 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
1679 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1680 Message-ID: <54B84785.1060301@d1.example>
1681 Date: Thu, 14 Jan 2015 15:00:01 -0800
1682 From: John Q Doe
1683 To: arc@example.org
1684 Subject: [Lists] Example 1
1686 Hey gang,
1687 This is a test message.
1688 --J.
1690 B.3. Example 3: Mailing list to forwarded mailbox with source
1692 B.3.1. Here's the message as it exits the Origin:
1694 Return-Path:
1695 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1696 (authenticated bits=0)
1697 by segv.d1.example with ESMTP id t0FN4a8O084569;
1698 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1699 (envelope-from jqd@d1.example)
1700 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1701 s=origin2015; d=d1.example; cv=none;
1702 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61T
1703 X6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69EU
1704 8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1705 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
1706 d=d1.example; s=20130426; t=1421363082;
1707 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1708 h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding;
1709 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrv
1710 Qwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3
1711 TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1712 Message-ID: <54B84785.1060301@d1.example>
1713 Date: Thu, 14 Jan 2015 15:00:01 -0800
1714 From: John Q Doe
1715 To: arc@example.org
1716 Subject: Example 1
1718 Hey gang,
1719 This is a test message.
1720 --J.
1722 B.3.2. Message is then received at example.org
1724 B.3.2.1. Example 3, Step A: Message forwarded to list members with
1725 source
1727 Processing at example.org:
1729 o example.org performs authentication checks
1731 o example.org applies standard DKIM signature
1733 o Checks for ARC-Seal: header; finds one (i=1)
1735 o Validates the signature in the ARC-Seal (i=1): header, which
1736 covers the d1.example ARC-Message-Signature: header
1738 o example.org adds ARC-Authentication-Results header
1740 o example.org adds usual Received: header
1741 o example.org adds a DKIM-Signature
1743 o example.org adds a ARC-Seal header, contents of which are
1745 * sequence number ("i=2")
1747 * hash algorithm (SHA256 as example)
1749 * timestamp ("t=")
1751 * chain validity ("cv=")
1753 * selector for key ("s=seal2015")
1755 * domain for key ("d=example.org")
1757 * signature ("b=")
1759 Here's the message as it exits Step A:
1761 Return-Path:
1762 ARC-Seal: i=2; a=rsa-sha256; t=1421363107;
1763 s=seal2015; d=example.org; cv=pass;
1764 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
1765 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
1766 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1767 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed;
1768 d=example.org; s=clochette; t=1421363105;
1769 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
1770 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
1771 List-Help:List-Subscribe:From:Reply-To:DKIM-Signature;
1772 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
1773 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
1774 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
1775 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
1776 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
1777 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
1778 (envelope-from jqd@d1.example)
1779 ARC-Authentication-Results: i=2; lists.example.org;
1780 spf=pass smtp.mfrom=jqd@d1.example;
1781 dkim=pass (1024-bit key) header.i=@d1.example;
1782 dmarc=pass
1783 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1784 (authenticated bits=0)
1785 by segv.d1.example with ESMTP id t0FN4a8O084569;
1786 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1787 (envelope-from jqd@d1.example)
1788 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1789 s=origin2015; d=d1.example; cv=none;
1790 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1791 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1792 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1793 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
1794 d=d1.example; s=20130426; t=1421363082;
1795 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1796 h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding;
1797 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
1798 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
1799 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1800 Message-ID: <54B84785.1060301@d1.example>
1801 Date: Thu, 14 Jan 2015 15:00:01 -0800
1802 From: John Q Doe
1803 To: arc@example.org
1804 Subject: [Lists] Example 1
1806 Hey gang,
1807 This is a test message.
1808 --J.
1810 B.3.2.2. Example 3, Step B: Message from list forwarded with source
1812 The message is delivered to a mailbox at gmail.com
1813 Processing at gmail.com:
1815 o gmail.com performs usual authentication checks
1817 o gmail.com adds Authentication-Results: and Received: header
1819 o Determines that message fails DMARC
1821 o Checks for ARC-Seal: header; finds two
1823 o Validates the signature in the ARC-Seal (i=2): header, which
1824 covers the ARC-Authentication-Results: header
1826 o Validates the signature in the ARC-Seal (i=1): header, which
1827 covers the d1.example ARC-Message-Signature: header
1829 o Uses the ARC-Authentication-Results: values, but:
1831 o Instead of delivering message, prepares to forward message per
1832 user settings
1834 o Applies usual DKIM signature
1836 o gmail.com adds it's own ARC-Seal: header, contents of which are
1838 * version
1840 * sequence number ("i=2")
1842 * hash algorithm (SHA256 as example)
1844 * timestamp ("t=")
1846 * selector for key ("s=notary01")
1848 * domain for key ("d=gmail.com")
1850 * Note: algorithm requires only ARC-Seals with lower sequence #
1851 be included, in ascending order
1853 * signature of the chain
1855 Here's what the message looks like at this point:
1857 Return-Path:
1858 ARC-Seal: i=3; a=rsa-sha256; t=1421363253;
1859 s=notary01; d=gmail.com; cv=pass;
1860 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwD
1861 WRYbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF
1862 /suttxO+RRNr0fCFw==
1863 ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed;
1864 d=gmail.com; s=20120806;
1865 h=mime-version:content-type:x-original-sender
1866 :x-original-authentication-results:precedence:mailing-list
1867 :list-id:list-post:list-help:list-archive:sender
1868 :list-unsubscribe:reply-to;
1869 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=;
1870 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
1871 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
1872 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBm
1873 fhSLF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJ
1874 RFeMKdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwD
1875 BJtXwbQoZyRtb6X6q0mYaszUB8kw==
1876 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10
1877 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST)
1878 Authentication-Results: i=3; gmail.com; spf=fail
1879 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
1880 header.i=@example.org; dmarc=fail; arc=pass
1881 ARC-Seal: i=2; a=rsa-sha256; t=1421363107;
1882 s=seal2015; d=example.org; cv=pass;
1883 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1884 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1885 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1886 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed;
1887 d=example.org; s=clochette; t=1421363105;
1888 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
1889 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
1890 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
1891 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1
1892 F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+
1893 m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
1894 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
1895 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
1896 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
1897 (envelope-from jqd@d1.example)
1898 ARC-Authentication-Results: i=2; lists.example.org;
1899 spf=pass smtp.mfrom=jqd@d1.example;
1900 dkim=pass (1024-bit key) header.i=@d1.example;
1901 dmarc=pass
1902 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1903 (authenticated bits=0)
1904 by segv.d1.example with ESMTP id t0FN4a8O084569;
1905 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1906 (envelope-from jqd@d1.example)
1907 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1908 s=origin2015; d=d1.example; cv=none;
1909 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1910 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1911 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1912 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
1913 d=d1.example; s=20130426; t=1421363082;
1914 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1915 h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding;
1916 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYij
1917 rvQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD
1918 4Gd3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1919 Message-ID: <54B84785.1060301@d1.example>
1920 Date: Thu, 14 Jan 2015 15:00:01 -0800
1921 From: John Q Doe
1922 To: arc@example.org
1923 Subject: [Lists] Example 1
1925 Hey gang,
1926 This is a test message.
1927 --J.
1929 B.3.3. Example 3: Message received by Recipient
1931 Let's say that the Recipient is example.com
1932 Processing at example.com:
1934 o example.com performs usual authentication checks
1936 o example.com adds Authentication-Results: header, Received header
1938 o Determines that message fails DMARC
1940 o Checks for ARC-Seal: header; finds three
1942 o Validates the signature in the highest numbered ("i=2") ARC-Seal:
1943 header, which covers all previous ARC-Seal: and ARC-
1944 Authentication-Results: headers
1946 o Validates the other ARC-Seal header ("i=2"), which covers the ARC-
1947 Authentication-Results: header
1949 o Validates the other ARC-Seal header ("i=1"), which covers the
1950 d1.example ARC-Message-Signature: header
1952 o example.com uses the ARC-Authentication-Results: values
1953 Here's what the message looks like at this point:
1955 Return-Path:
1956 Received: from mail-ob0-f188.google.com (mail-ob0-f188.google.com
1957 [208.69.40.157]) by clothilde.example.com with ESMTP id
1958 d200mr22663000ykb.93.1421363268
1959 for ; Thu, 14 Jan 2015 15:03:15 -0800 (PST)
1960 Authentication-Results: clothilde.example.com; spf=fail
1961 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
1962 header.i=@gmail.com; dmarc=fail; arc=pass
1963 ARC-Seal: i=3; a=rsa-sha256; t=1421363253;
1964 s=notary01; d=gmail.com; cv=pass;
1965 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDW
1966 RYbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/s
1967 uttxO+RRNr0fCFw==
1968 ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed;
1969 d=gmail.com; s=20120806;
1970 h=mime-version:content-type:x-original-sender
1971 :x-original-authentication-results:precedence
1972 :mailing-list:list-id:list-post:list-help:list-archive:sender
1973 :list-unsubscribe:reply-to;
1974 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=;
1975 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
1976 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
1977 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBm
1978 fhSLF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJ
1979 RFeMKdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwD
1980 BJtXwbQoZyRtb6X6q0mYaszUB8kw==
1981 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10
1982 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST)
1983 Authentication-Results: i=3; gmail.com; spf=fail
1984 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
1985 header.i=@example.org; dmarc=fail; arc=pass
1986 ARC-Seal: i=2; a=rsa-sha256; t=1421363107;
1987 s=seal2015; d=example.org; cv=pass;
1988 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
1989 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
1990 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1991 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed;
1992 d=example.org; s=clochette; t=1421363105;
1993 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
1994 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
1995 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
1996 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1
1997 F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+
1998 m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
1999 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
2000 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
2001 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
2002 (envelope-from jqd@d1.example)
2003 ARC-Authentication-Results: i=2; lists.example.org;
2004 spf=pass smtp.mfrom=jqd@d1.example;
2005 dkim=pass (1024-bit key) header.i=@d1.example;
2006 dmarc=pass
2007 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
2008 (authenticated bits=0)
2009 by segv.d1.example with ESMTP id t0FN4a8O084569;
2010 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
2011 (envelope-from jqd@d1.example)
2012 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
2013 s=origin2015; d=d1.example; cv=none;
2014 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
2015 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
2016 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
2017 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
2018 d=d1.example; s=20130426; t=1421363082;
2019 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
2020 h=MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding;
2021 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
2022 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
2023 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
2024 Message-ID: <54B84785.1060301@d1.example>
2025 Date: Thu, 14 Jan 2015 15:00:01 -0800
2026 From: John Q Doe
2027 To: arc@example.org
2028 Subject: [Lists] Example 1
2030 Hey gang,
2031 This is a test message.
2032 --J.
2034 Appendix C. Acknowledgements
2036 This draft is the work of OAR-Dev Group.
2038 The authors thank all of the OAR-Dev group for the ongoing help and
2039 though-provoking discussions from all the participants, especially:
2040 Alex Brotman, Brandon Long, Dave Crocker, Elizabeth Zwicky, Franck
2041 Martin, Greg Colburn, J. Trent Adams, John Rae-Grant, Mike Hammer,
2042 Mike Jones, Steve Jones, Terry Zink, Tim Draegen.
2044 Grateful appreciation is extended to the people who provided feedback
2045 through the discuss mailing list.
2047 Appendix D. Comments and Feedback
2049 Please address all comments, discussions, and questions to
2050 dmarc@ietf.org [4]. Earlier discussions can be found at arc-
2051 discuss@dmarc.org [5].
2053 Authors' Addresses
2055 Kurt Andersen
2056 LinkedIn
2057 1000 West Maude Ave
2058 Sunnyvale, California 94085
2059 USA
2061 Email: kurta@linkedin.com
2063 Brandon Long (editor)
2064 Google
2066 Email: blong@google.com
2068 Steven Jones (editor)
2069 TDP
2071 Email: smj@crash.com
2073 Murray Kucherawy (editor)
2074 TDP
2076 Email: superuser@gmail.com