idnits 2.17.1
draft-ietf-dmarc-arc-protocol-11.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 :
----------------------------------------------------------------------------
** There is 1 instance of too long lines in the document, the longest one
being 1 character in excess of 72.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (January 22, 2018) is 2286 days in the past. Is this
intentional?
Checking references for intended status: Experimental
----------------------------------------------------------------------------
== Missing Reference: 'CFWS' is mentioned on line 492, but not defined
-- Looks like a reference, but probably isn't: '2' on line 1556
-- Looks like a reference, but probably isn't: '1' on line 1554
== Missing Reference: 'I-D.ARC' is mentioned on line 1340, but not defined
-- Looks like a reference, but probably isn't: '3' on line 1558
-- Looks like a reference, but probably isn't: '4' on line 2435
-- Looks like a reference, but probably isn't: '5' on line 2436
== Unused Reference: 'RFC1345' is defined on line 1416, but no explicit
reference was found in the text
== Unused Reference: 'RFC2142' is defined on line 1425, but no explicit
reference was found in the text
== Unused Reference: 'RFC2606' is defined on line 1429, but no explicit
reference was found in the text
== Unused Reference: 'RFC4686' is defined on line 1437, but no explicit
reference was found in the text
== Unused Reference: 'RFC5226' is defined on line 1441, but no explicit
reference was found in the text
== Unused Reference: 'RFC5321' is defined on line 1451, but no explicit
reference was found in the text
== Unused Reference: 'RFC5322' is defined on line 1455, but no explicit
reference was found in the text
== Unused Reference: 'RFC5585' is defined on line 1459, but no explicit
reference was found in the text
== Unused Reference: 'RFC5863' is defined on line 1468, but no explicit
reference was found in the text
== Unused Reference: 'RFC6651' is defined on line 1483, but no explicit
reference was found in the text
** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126)
** Obsolete normative reference: RFC 7601 (Obsoleted by RFC 8601)
== Outdated reference: A later version (-23) exists of
draft-ietf-dmarc-arc-protocol-05
== Outdated reference: A later version (-23) exists of
draft-ietf-dmarc-arc-protocol-06
-- Duplicate reference: draft-ietf-dmarc-arc-protocol, mentioned in
'ARC-DRAFT-06', was also mentioned in 'ARC-DRAFT-05'.
== Outdated reference: A later version (-23) exists of
draft-ietf-dmarc-arc-protocol-10
-- Duplicate reference: draft-ietf-dmarc-arc-protocol, mentioned in
'ARC-DRAFT-10', was also mentioned in 'ARC-DRAFT-06'.
== Outdated reference: A later version (-03) exists of
draft-ietf-dmarc-arc-multi-01
== 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: 3 errors (**), 0 flaws (~~), 18 warnings (==), 9 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: Experimental B. Long, Ed.
5 Expires: July 26, 2018 Google
6 S. Jones, Ed.
7 TDP
8 S. Blank, Ed.
9 ValiMail
10 M. Kucherawy, Ed.
11 TDP
12 January 22, 2018
14 Authenticated Received Chain (ARC) Protocol
15 draft-ietf-dmarc-arc-protocol-11
17 Abstract
19 The Authenticated Received Chain (ARC) protocol creates a mechanism
20 whereby a series of handlers of an email message can conduct
21 authentication of the email message as it passes among them on the
22 way to its destination, and record the status of that authentication
23 at each step along the handling path, for use by the final recipient
24 in making choices about the disposition of the message. Changes in
25 the message that might break DKIM or DMARC can be identified through
26 the ARC set of header fields.
28 Status of This Memo
30 This Internet-Draft is submitted in full conformance with the
31 provisions of BCP 78 and BCP 79.
33 Internet-Drafts are working documents of the Internet Engineering
34 Task Force (IETF). Note that other groups may also distribute
35 working documents as Internet-Drafts. The list of current Internet-
36 Drafts is at https://datatracker.ietf.org/drafts/current/.
38 Internet-Drafts are draft documents valid for a maximum of six months
39 and may be updated, replaced, or obsoleted by other documents at any
40 time. It is inappropriate to use Internet-Drafts as reference
41 material or to cite them other than as "work in progress."
43 This Internet-Draft will expire on July 26, 2018.
45 Copyright Notice
47 Copyright (c) 2018 IETF Trust and the persons identified as the
48 document authors. All rights reserved.
50 This document is subject to BCP 78 and the IETF Trust's Legal
51 Provisions Relating to IETF Documents
52 (https://trustee.ietf.org/license-info) in effect on the date of
53 publication of this document. Please review these documents
54 carefully, as they describe your rights and restrictions with respect
55 to this document. Code Components extracted from this document must
56 include Simplified BSD License text as described in Section 4.e of
57 the Trust Legal Provisions and are provided without warranty as
58 described in the Simplified BSD License.
60 Table of Contents
62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
63 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
64 3. Definitions and Terminology . . . . . . . . . . . . . . . . . 6
65 3.1. Referenced Definitions . . . . . . . . . . . . . . . . . 6
66 4. Protocol Elements and Features . . . . . . . . . . . . . . . 7
67 4.1. Features of the ARC Protocol . . . . . . . . . . . . . . 8
68 4.1.1. Chain of Custody . . . . . . . . . . . . . . . . . . 8
69 4.1.2. Optional Participation . . . . . . . . . . . . . . . 8
70 4.1.3. Only one ARC Chain (One Chain to Rule Them All) . . . 9
71 4.1.4. All Failures are Permanent . . . . . . . . . . . . . 9
72 4.1.5. Benign nature of an ARC Set . . . . . . . . . . . . . 9
73 4.1.6. Key Management . . . . . . . . . . . . . . . . . . . 9
74 4.1.7. Trace Information . . . . . . . . . . . . . . . . . . 10
75 4.1.8. Instance Tags . . . . . . . . . . . . . . . . . . . . 10
76 4.1.9. Chain Validation Status . . . . . . . . . . . . . . . 10
77 5. The ARC Header Fields . . . . . . . . . . . . . . . . . . . . 10
78 5.1. Instance ('i=') Tag . . . . . . . . . . . . . . . . . . . 10
79 5.1.1. Valid Range for Instance Tags . . . . . . . . . . . . 10
80 5.2. ARC-Authentication-Results (AAR) . . . . . . . . . . . . 11
81 5.2.1. ptypes and properties for arc-info . . . . . . . . . 11
82 5.3. ARC-Message-Signature (AMS) . . . . . . . . . . . . . . . 12
83 5.4. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . . . 12
84 5.4.1. The 'cv' Tag . . . . . . . . . . . . . . . . . . . . 13
85 5.4.2. Implicit Header Fields . . . . . . . . . . . . . . . 13
86 6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . 14
87 6.1. Handling DNS Problems While Validating ARC . . . . . . . 15
88 6.2. Responding to ARC Validity Violations During the SMTP
89 Transaction . . . . . . . . . . . . . . . . . . . . . . . 15
90 7. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . 16
91 7.1. Marking and Sealing "cv=fail" (Invalid) Chains . . . . . 16
92 8. Usage of ARC and Chain Validity . . . . . . . . . . . . . . . 16
93 8.1. Relationship between DKIM-Signature and AMS signing
94 scopes . . . . . . . . . . . . . . . . . . . . . . . . . 16
95 8.2. Assessing Chain Validity Violations . . . . . . . . . . . 17
96 9. Recording and Reporting the Results of ARC Evaluation . . . . 17
97 9.1. Information from an ARC Evaluation . . . . . . . . . . . 17
98 9.2. Recording (local) ARC Evaluation Results . . . . . . . . 18
99 9.3. DMARC Reporting of ARC Findings - Interim . . . . . . . . 18
100 10. Supporting Alternate Signing Algorithms . . . . . . . . . . . 19
101 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
102 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
103 12.1. Authentication-Results Method Registry Update . . . . . 19
104 12.2. Definitions of the ARC header fields . . . . . . . . . . 20
105 13. Security Considerations . . . . . . . . . . . . . . . . . . . 21
106 13.1. Header Size . . . . . . . . . . . . . . . . . . . . . . 21
107 13.2. DNS Operations . . . . . . . . . . . . . . . . . . . . . 21
108 13.3. Message Content Suspicion . . . . . . . . . . . . . . . 22
109 14. Evaluating the Efficacy of the ARC Protocol . . . . . . . . . 22
110 14.1. Success Consideration . . . . . . . . . . . . . . . . . 23
111 14.2. Failure Considerations . . . . . . . . . . . . . . . . . 23
112 14.3. Open Questions . . . . . . . . . . . . . . . . . . . . . 23
113 14.3.1. Value of the ARC-Seal (AS) Header . . . . . . . . . 23
114 14.3.2. DNS Overhead . . . . . . . . . . . . . . . . . . . . 23
115 14.3.3. Distinguishing Valuable from Worthless Trace
116 Information . . . . . . . . . . . . . . . . . . . . 24
117 15. Implementation Status . . . . . . . . . . . . . . . . . . . . 24
118 15.1. GMail test reflector and incoming validation . . . . . . 25
119 15.2. AOL test reflector and internal tagging . . . . . . . . 25
120 15.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 26
121 15.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . 26
122 15.5. Mailman 3.2 patch . . . . . . . . . . . . . . . . . . . 27
123 15.6. Copernica/MailerQ web-based validation . . . . . . . . . 27
124 15.7. Rspamd . . . . . . . . . . . . . . . . . . . . . . . . . 28
125 15.8. PERL MAIL::DKIM module . . . . . . . . . . . . . . . . . 28
126 15.9. PERL Mail::Milter::Authentication module . . . . . . . . 29
127 15.10. Sympa List Manager . . . . . . . . . . . . . . . . . . . 29
128 15.11. Oracle Messaging Server . . . . . . . . . . . . . . . . 30
129 15.12. MessageSystems Momentum . . . . . . . . . . . . . . . . 30
130 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
131 16.1. Normative References . . . . . . . . . . . . . . . . . . 30
132 16.2. Informative References . . . . . . . . . . . . . . . . . 32
133 16.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 33
134 Appendix A. Appendix A - Design Requirements . . . . . . . . . . 34
135 A.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 34
136 A.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 34
137 Appendix B. Appendix B - Example Usage . . . . . . . . . . . . . 34
138 B.1. Example 1: Simple mailing list . . . . . . . . . . . . . 34
139 B.1.1. Here's the message as it exits the Origin: . . . . . 34
140 B.1.2. Message is then received at example.org . . . . . . . 35
141 B.1.3. Example 1: Message received by Recipient . . . . . . 37
142 B.2. Example 2: Mailing list to forwarded mailbox . . . . . . 38
143 B.2.1. Here's the message as it exits the Origin: . . . . . 38
144 B.2.2. Message is then received at example.org . . . . . . . 39
145 B.2.3. Example 2: Message received by Recipient . . . . . . 43
146 B.3. Example 3: Mailing list to forwarded mailbox with source 45
147 B.3.1. Here's the message as it exits the Origin: . . . . . 45
148 B.3.2. Message is then received at example.org . . . . . . . 46
149 B.3.3. Example 3: Message received by Recipient . . . . . . 51
150 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 53
151 Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 54
152 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
154 1. Introduction
156 Modern email authentication techniques such as the Sender Policy
157 Framework (SPF) [RFC7208] and DomainKeys Identified Mail (DKIM)
158 [RFC6376] have become common.
159 However, their end-to-end utility is limited by the effects of
160 intermediaries along the transmission path, which either are not
161 listed (for SPF) or which break digital signatures (for DKIM). These
162 issues are described in substantial detail in those protocols'
163 defining documents as well as in [RFC6377] and [RFC7960].
165 Technologies that build upon the use of SPF and DKIM can reduce the
166 success of fraudulent email campaigns. To this end, Domain-based
167 Mail Authentication, Reporting and Compliance (DMARC) [RFC7489],
168 validates the domain of the RFC5322.From author header field.
169 However its use along email transmission paths that have independent
170 intermediaries, such as some forwarders and essentially all mailing
171 list services, produces false positive rejections that are
172 problematic, both for the message authors, the intermediary
173 service(s), and for those they are interacting with.
175 What is needed is a mechanism by which legitimate alteration of a
176 message, which invalidates associated SPF and DKIM information, does
177 not ultimately result in a rejection of an email message on delivery.
178 Authenticated Receive Chain (ARC) builds upon DKIM mechanisms to
179 provide a sequence of signatures that are more survivable than DKIM's
180 and that provide a view of the handling sequence for a message,
181 especially the points where alterations of the content might have
182 occurred. Equipped with this more complete information, the
183 recipient system(s) can make a more informed handling choice,
184 reducing or eliminating the false negatives inherent in use of DKIM
185 and/or SPF themselves.
187 2. Overview
189 In DKIM, every participating signing agent attaches a signature that
190 is based on the some of the content of the message, local policy, and
191 the domain name of the participating Administrative Management Domain
192 (ADMD). Any verifier can process such a signature; a verified
193 signature means that the domain referenced in the DKIM-Signture's
194 "d=" parameter has some responsibility for handling the message. An
195 artifact of using digital signature technology for this means that
196 verification also ensures that the message content that was "covered"
197 by the signature has not been altered since the signature was
198 applied. The signatures themselves are generally independent of one
199 another.
201 By contrast, an ARC signature conveys the following pieces of
202 information:
204 1. An assertion that, at the time that the intermediary ADMD
205 processed the message, the various assertions (DKIM-Signature(s)
206 and/or ARC sets) already attached to the message by other ADMDs
207 were or were not valid;
209 2. As with DKIM, an assertion that, for a validated signature, the
210 domain name in the signature takes some responsibility for
211 handling of the message and that the message is unchanged since
212 that signature was applied;
214 3. A further assertion that binds the ARC evaluation results into
215 the ARC chain sequence.
217 This protocol accomplishes each of these by adding a new header field
218 to the message for each of these pieces of information, as follows:
220 o ARC-Authentication-Results (referred to below as "AAR"): virtually
221 identical in syntax to an Authentication-Results field [RFC7601],
222 this field records the results of all message authentication
223 checks done by the recording ADMD at the time the message arrived.
224 Additional information is placed in this field compared to a
225 standard Authentication-Results field in order to support a more
226 complete DMARC report (see Section 5.2);
228 o ARC-Message-Signature (referred to below as "AMS"): virtually
229 identical in syntax to DKIM-Signature, this field contains the
230 signature about the message header and body as they existed at the
231 time of handling by the ADMD adding it; and
233 o ARC-Seal (referred to below as "AS"): highly similar in structure
234 and format to a DKIM-Signature, this field applies a digital
235 signature that protects the integrity of all three of these new
236 fields when they are added by an ADMD, plus all instances of these
237 fields added by prior ADMDs.
239 A distinguishing feature of all of these is that an ARC participant
240 always adds all of them before relaying a message to the next
241 handling agent en route to its destination. Moreover, as described
242 in Section 5.1, they each have an "instance" number that increases
243 with each ADMD in the handling chain so that their original order can
244 be preserved and the three related header fields can be processed as
245 a group.
247 3. Definitions and Terminology
249 This section defines terms used in the rest of the document.
251 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
252 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
253 document are to be interpreted as described in [RFC2119].
255 Because many of the core concepts and definitions are found in
256 [RFC5598], readers SHOULD to be familiar with the contents of
257 [RFC5598], and in particular, the potential roles of intermediaries
258 in the delivery of email.
260 Syntax descriptions use Augmented BNF (ABNF) [RFC5234].
262 o "ARC set" - A single group of the header fields introduced in
263 Section 2 is called an "ARC set".
265 o "ARC chain" - The complete sequence of these groups (ARC sets) is
266 called an "Authenticated Received Chain" or merely an "ARC chain".
267 Although the "Received" header field is typically not included in
268 the signed content, the name is based on the notion that this is
269 in essence a cryptographically signed series of header fields that
270 attest to the handling chain of a message much as Received fields
271 always have.
273 3.1. Referenced Definitions
275 The following terms are defined in other RFCs. Those definitions can
276 be found as follows:
278 o ADMD - [RFC5598], Section 2.3
280 o MTA - [RFC5598], Section 4.3.2
282 o MSA - [RFC5598], Section 4.3.1
283 o MDA - [RFC5598], Section 4.3.3
285 The three header fields that are part of this specification borrow
286 heavily from existing specifications. Rather than repeating all of
287 the formal definitions that are being reused in ARC, this document
288 only describes and specifies changes in syntax and semantics.
290 Language, syntax, and other details are imported from DKIM [RFC6376].
291 Specific references can be found below.
293 4. Protocol Elements and Features
295 As with other domain authentication technologies (such as SPF, DKIM,
296 and DMARC), ARC makes no claims about the contents of the email
297 message it has sealed. However, for a valid and passing ARC chain, a
298 Final Receiver is able to ascertain:
300 o all (participating) domains that claim responsibility for handling
301 (and possibly) modifying the email message in transit;
303 o trace information, including:
305 * the [RFC7601] authentication results each participating ADMD
306 saw; and
308 * additional data needed to compile a DMARC report for the
309 sending domain.
311 Given this information, a Final Receiver is able to make a more-
312 informed local policy decision regarding message delivery to the end
313 user in spite of a DMARC failure.
315 Every participant in an ARC chain, except for the originating sender
316 and Final Receiver, is both an ARC Validator (when receiving) and
317 then an ARC Sealer (when sending a message onward). The validated
318 chain status as determined at message receipt must be passed to the
319 sealer function in order for sealing to occur properly; how this is
320 done is considered ADMD-specific and an implementation detail.
322 _INFORMATIONAL_: It is important to understand that validating and
323 then immediately sealing a message leaves no room for message
324 modification, and many early implementations of ARC did not initially
325 work because both operations were performed in a single pass over the
326 message.
328 4.1. Features of the ARC Protocol
330 The following protocol features are functional parts and design
331 decisions related the protocol that are not specific to either
332 Validators or Sealers, but ensure the ARC chain conveys this
333 information to a Final Receiver.
335 4.1.1. Chain of Custody
337 At a high level, an ARC chain represents a chain of custody of
338 authentication and other trace information (AAR) related to a
339 message, signed by each handler of the message. Each link in the
340 chain (AMS) is designed to be brittle, insofar as it survives only
341 until the next modification of the message. However, the sequence of
342 intermediaries in the handling chain (AS) is designed to remain
343 intact over the entirety of the chain.
345 The ARC chain can be conceptualized through an analogy with the chain
346 of custody for legal evidence. The material evidence itself is
347 sealed within an tamper-proof bag (AMS) each time. When handed to a
348 new party, that party both vouches for the state of the received
349 evidence container (AAR) and signs for the evidence on a chain of
350 custody report form (AS). As with all analogies, this one should not
351 be taken to interpretive extremes, but primarily used as a conceptual
352 framework.
354 An ARC chain that is valid and passing has the attributes listed
355 above in Section 4.
357 Recipients of an ARC chain that is invalid or does not pass SHOULD
358 NOT draw negative conclusions without a good understanding of the
359 wider handling context. Until ARC usage is widespread,
360 intermediaries will continue to modify messages without ARC seals.
361 As with a failing DKIM signature ([RFC6376] Section-6.3), a failing
362 ARC chain SHOULD be treated the same as a message with no ARC chain.
363 [[ NOTE TO WORKING GROUP: This paragraph probably is better placed in
364 Verifier actions. ]]
366 4.1.2. Optional Participation
368 Validating an existing chain and then adding your own ARC set to a
369 message allows you to claim responsibility for hanndling the message
370 and modifications, if any, done by your ADMD to benefit message
371 delivery downstream. However, no ADMD is obligated to perform these
372 actions.
374 4.1.3. Only one ARC Chain (One Chain to Rule Them All)
376 A message can have only one ARC chain on it at a time (see
377 Section 5.1). Once broken, the chain cannot be restarted, as the
378 chain of custody is no longer valid and responsibility for the
379 message has been lost.
381 4.1.4. All Failures are Permanent
383 Because ARC chains are transmitted across multiple intermediaries,
384 all errors, even temporary ones, become unrecoverable and are
385 considered permanent.
387 Any error validating or sealing a chain, for whatever reason, MUST
388 result in a "cv=fail" verdict.
390 4.1.5. Benign nature of an ARC Set
392 Even when an ARC chain is valid and passes, its value is limited to
393 very specific cases. An ARC chain is specifically designed to
394 provide value to a Final Receiver evaluating message delivery in the
395 context of a DMARC failure. An ARC chain in general, and each ARC
396 set in particular, provide additional information, and otherwise is
397 benign. Specifically:
399 o properly adding an ARC set to a message does not damage or
400 invalidate an existing chain, and
402 o validating a message exposes no new threat vectors (see
403 Section 13).
405 _INFORMATIONAL_: If an ADMD is unsure whether it will be re-emitting
406 and/or modifying a message, it may elect to seal all inbound mail.
407 For complex or nested ADMD relationships such as found in some hosted
408 mail solutions, this "inbound seal" can be used to facilitate
409 traversal of internal boundaries as well as properly conveying
410 incoming state to any egress MTAs that may need to assert a seal upon
411 exit from the ADMD. Since these internal relationships are highly
412 implementation dependent, this protocol definition can not usefully
413 explore such usage except to note that it is intentionally allowed
414 within the scope of this specification.
416 4.1.6. Key Management
418 The public keys for ARC header fields follow the same requirements,
419 syntax and semantics as those for DKIM signatures, described in
420 Section 3.6 of [RFC6376]. ARC places no requirements on the
421 selectors and/or domains used for the ARC header field signatures.
423 4.1.7. Trace Information
425 ARC includes trace information encoded in the AAR. While section
426 Section 5.2 defines what information must be provided, sealing ADMDs
427 may provide additional information, and validating receivers may use
428 or ignore this trace information as they wish.
430 4.1.8. Instance Tags
432 See section Section 5.1
434 4.1.9. Chain Validation Status
436 See section Section 5.4.1
438 5. The ARC Header Fields
440 5.1. Instance ('i=') Tag
442 The header fields comprising a single ARC set are identified by the
443 presence of a string in the value portion of the header field that
444 complies with the "tag-spec" ABNF found in Section 3.2 of [RFC6376].
445 The tag-name is "i" and the value is the text representation of a
446 positive integer, indicating the position in the ARC sequence this
447 set occupies, where the first ARC set is numbered 1. In ABNF terms:
449 instance = [FWS] %x69 [FWS] "=" [FWS] position [FWS] ";"
450 position = 1*2DIGIT ; 1 - 50
452 Valid ARC sets must have exactly one instance of each header field
453 for a given position value and signing algorithm. (Initial
454 development of ARC is only being done with a single allowed signing
455 algorithm, but parallel work in the DCRUP working group
456 (https://datatracker.ietf.org/wg/dcrup/about/) is expanding that.
457 For handling multiple signing algorithms, see [ARC-MULTI].)
459 Because the AMS and AS header field values are made up of tag-spec
460 constructs, the i= tag may be found anywhere within the header field
461 value, but is represented throughout this spec in the initial
462 position for convenience. Implementers are encouraged to place the
463 i= tag at the beginning of the field value to facilitate human
464 inspection of the headers.
466 5.1.1. Valid Range for Instance Tags
468 The 'i' tag value can range from 1-50 (inclusive).
470 ARC implementations MUST support at least ten (10) ARC sets.
472 An effective operational maximum will have to be developed through
473 deployment experience in the field and will be documented within
474 [ARC-USAGE] once determined.
476 ARC chains with more than the defined operational maximum count MUST
477 be marked with "cv=fail".
479 5.2. ARC-Authentication-Results (AAR)
481 The ARC-Authentication-Results header field is syntactically and
482 semantically identical to an Authentication-Results header field
483 (defined in Section 2.2 of [RFC7601] (A-R)), except that several
484 optional data fields SHOULD be added. ([[ NOTE: these optional data
485 fields are being proposed as amendments to [RFC7601] through a "bis"
486 process. Depending on the sequencing for this specification and said
487 "7601bis" work, it may be possible to drop the noted sections from
488 this specification. ]]) The first element ("Authentication-Results:")
489 in authres-header is replaced with arc-authres-prefix as follows:
491 arc-authres-header-prefix = "ARC-Authentication-Results:" [CFWS] arc-info
492 arc-info = instance *([CFWS] propspec) [CFWS] ";"
494 The purpose of this header field is to transmit the results of any
495 authentication done on the message upstream to participating ADMDs
496 validating and continuing the chain.
498 The AAR MUST contain all A-R results from within the participating
499 ADMD, regardless of how many A-R headers are on the message.
501 5.2.1. ptypes and properties for arc-info
503 [[ NOTE: This section is being proposed as an amendment to [RFC7601]
504 through a "bis" process. Depending on the sequencing for this
505 specification and said "7601bis" work, it may be possible to this
506 section from this specification. ]]
508 Certain information pertinent to ascertaining message disposition can
509 be lost in transit when messages are handled by intermediaries. For
510 example, failing DKIM signatures are sometimes removed by MTAs, and
511 most DKIM signatures on messages modified by intermediaries will
512 fail.
514 The AAR, through these ptype-properties stamped in arc-info, provide
515 a mechanism for this information to survive transit.
517 The ptypes and properties defined in this section SHOULD be stamped
518 in the AAR:
520 o smtp.client-ip - The connecting client IP address from which the
521 message is received;
523 o header.s - Defined in [RFC6376] section 7.2
525 o arc.oldest-pass - The instance number of the oldest AMS that still
526 validates, or 0 if all pass.
528 5.3. ARC-Message-Signature (AMS)
530 The ARC-Message-Signature header field is syntactically and
531 semantically identical to a DKIM-Signature header field [RFC6376],
532 with the following exceptions:
534 o There is an "i" tag, as described in Section 5.1.
536 o There is no "v" tag.
538 ARC-Seal header fields MUST NOT be included in the content covered by
539 the signature in this header field.
541 The AMS SHOULD include any DKIM-Signature header fields already
542 present on the message in the header fields covered by this
543 signature.
545 The AMS header field MAY include (sign) the AAR header field(s).
547 Authentication-Results header fields SHOULD NOT be included since
548 they are likely to be deleted by downstream ADMDs (per Section XXX of
549 [RFC7601]), thereby breaking the AMS signature.
551 As with a DKIM-Signature, the purpose of this header field is to
552 allow the ADMD generating it to take some responsibility for handling
553 this message as it progresses toward delivery.
555 5.4. ARC-Seal (AS)
557 The ARC-Seal header field is syntactically and semantically similar
558 to a DKIM-Signature field, with the following exceptions:
560 o There is an "i" tag, as described in Section 5.1.
562 o The ARC-Seal covers none of the body content of the message. It
563 only covers specific header fields. (See below: Section 5.4.2.)
564 As a result, no body canonicalization is done. Further, only
565 "relaxed" header canonicalization (Section 3.4.2 of [RFC6376]) is
566 used.
568 o The only supported tags are "i" (Section 5.1 supercedes the
569 [RFC6376] definition), and "a", "b", "d, "s", "t". The latter 5
570 tag definitions are copied from Section 3.5 of [RFC6376].
572 o An additional tag, "cv" is defined. (See below: Section 5.4.1)
574 5.4.1. The 'cv' Tag
576 A new tag "cv" (chain validation) indicates the the outcome of
577 evaluating the existing ARC chain upon arrival at the ADMD that is
578 adding this header field. It accepts one of three possible values:
580 o none: There was no chain on the message when it arrived for
581 validation; typically occurs when the message arrives at a Message
582 Transfer Agent (MTA) from a Message Submission Agent (MSA) or when
583 any upstream MTAs may not be participating in ARC handling;
585 o fail: The message has a chain whose validation failed;
587 o pass: The message has a chain whose validation succeeded.
589 In ABNF terms:
591 seal-cv-tag = %x63.76 [FWS] "=" [FWS] ("none" / "fail" / "pass")
593 5.4.2. Implicit Header Fields
595 The ARC-Seal signs a canonicalized form of the ARC set header values.
596 The ARC set header values are compiled in increasing instance order,
597 starting at 1, and inclue the set being added at the time of sealing
598 the message.
600 Within a set, the header fields are listed in the following order:
602 1. ARC-Authentication-Results
604 2. ARC-Message-Signature
606 3. ARC-Seal
608 Where the ARC-Seal is the one being generated, it is input to the
609 hash function in its final form except with an empty "b=" value, in
610 the same manner by which a DKIM-Signature signs itself.
612 Note that the signing scope for the ARC-Seal is modified in the
613 situation where a chain has failed validation (see Section 7.1).
615 6. Verifier Actions
617 A verifier takes the following steps to determine the state of the
618 ARC chain on a message (cv value). Canonicalization, hash functions,
619 and signature validation methods are imported from Section 5 of
620 [RFC6376].
622 [[ Note: need markdown flag to have subordinate numbering distinction
623 ]]
625 1. Collect all ARC sets currently on the message. If there were
626 none, the ARC state is "none" and the algorithm stops here.
628 2. If the form of any ARC set is invalid (e.g., does not contain
629 exactly one of each of the three ARC-specific header fields),
630 then the chain state is "fail" and the algorithm stops here.
632 1. To avoid the overhead of unnecessary computation and delay
633 from crypto and DNS operations, the cv value for all ARC-
634 Seal(s) MAY be checked at this point. If any of the values
635 are "fail", then the overall state of the chain is "fail" and
636 the algorithm stops here.
638 3. Conduct verification of the ARC-Message-Signature header field
639 bearing the highest instance number. If this verification fails,
640 then the chain state is "fail" and the algorithm stops here.
642 4. For each ARC-Seal from the "N"th instance to the first, apply the
643 following logic:
645 1. If the value of the "cv" tag on that seal is "fail", the
646 chain state is "fail" and the algorithm stops here. (This
647 step SHOULD be skipped if the earlier step (2.1) was
648 performed)
650 2. In Boolean nomenclature: if ((i == 1 && cv != "none") or (cv
651 == "none" && i != 1)) then the chain state is "fail" and the
652 algorithm stops here (note that the ordering of the logic is
653 structured for short-circuit evaluation).
655 3. Initialize a hash function corresponding to the "a" tag of
656 the ARC-Seal.
658 4. Compute the canonicalized form of the ARC header fields, in
659 the order described in Section 5.4.2, using the "relaxed"
660 header canonicalization defined in Section 3.4.2 of
661 [RFC6376]. Pass the canonicalized result to the hash
662 function.
664 5. Retrieve the final digest from the hash function.
666 6. Retrieve the public key identified by the "s" and "d" tags in
667 the ARC-Seal, as described in Section 4.1.6.
669 7. Determine whether the signature portion ("b" tag) of the ARC-
670 Seal and the digest computed above are valid according to the
671 public key. (See also Section Section 6.1 for failure case
672 handling)
674 8. If the signature is not valid, the chain state is "fail" and
675 the algorithm stops here.
677 5. If all seals pass validation, then the chain state is "pass", and
678 the algorithm is complete.
680 [[ Note from Dave: possibly delete the following paragraph as it is
681 more usage/procedural than specification guidance.
683 KA: It was added to clarify the separation of the verification and
684 signing steps as some of the initial implementations failed to
685 realize that they were not necessarily done in one fell swoop.
687 KA (v-10): With the addition of the {protocol-elements} section, does
688 the WG think that this can be reasonably removed from this location?
689 ]]
691 The verifier should save the cv state for subsequent use by any
692 sealing which may be done later (potentially after message
693 modification) within the same trust boundary. The cv state may be
694 recorded by sealing at the time of verification in an initial ARC set
695 (for the ADMD) or may be recorded out of band depending on the
696 architecture of the ADMD.
698 6.1. Handling DNS Problems While Validating ARC
700 DNS-based failures to verify a chain are treated no differently than
701 any other ARC violation. They result in a "cv=fail" verdict.
703 6.2. Responding to ARC Validity Violations During the SMTP Transaction
705 If a receiver determines that the ARC chain has failed, the receiver
706 MAY signal the breakage through the extended SMTP response code 5.7.7
707 [RFC3463] "message integrity failure" [ENHANCED-STATUS] and
708 corresponding SMTP response code.
710 7. Signer Actions
712 [[ Note from Dave: This seems more like implementation guidance than
713 specification detail. KA: see explanation just above referring to
714 the previous note. ]]
716 This section includes a specification of the actions an ARC signer
717 takes when presented with a message.
719 The signer MUST undertake the following steps:
721 1. Before creating an ARC signature, perform any other, normal
722 authentication and/or signing, so that the ARC signature can
723 cover those results.
725 2. Build and attach the new ARC set:
727 1. If an ARC chain exists on the message, then set "N" equal to
728 the highest instance number found on the chain (i=);
729 otherwise set "N" equal to zero for the following steps.
731 2. Generate and attach to the message an ARC-Authentication-
732 Results header field using instance number N+1 and the same
733 content from the previous step.
735 3. Generate and attach to the message an ARC-Message-Signature
736 header field as defined in Section 5.3 above, using instance
737 number N+1.
739 4. Generate and attach to the message an ARC-Seal header field
740 using the general algorithm described in Section 5.4 above,
741 the chain validation status as determined in Section 6, and
742 instance number N+1.
744 7.1. Marking and Sealing "cv=fail" (Invalid) Chains
746 The header fields signed by the AS header field b= value in the case
747 of a chain failure MUST be only the matching 'i=' instance headers
748 created by the MTA which detected the malformed chain, as if this
749 newest ARC set was the only set present.
751 8. Usage of ARC and Chain Validity
753 8.1. Relationship between DKIM-Signature and AMS signing scopes
755 [[ SB-11: replace with "ARC MUST be the last signer of the message;
756 otherwise it cannot be validated on receipt." in the signer actions
757 section. KA: Concern that this still does not address the risk of
758 DKIM-Signatures covering ARC chains. This does not seem like it fits
759 in this section but it needs to go somewhere. ]]
761 DKIM-Signatures SHOULD never sign any ARC header fields.
763 [[ KA: Response to Dave's concern: If DKIM covers ARC and ARC covers
764 DKIM, which comes first? The chicken or the egg? I'm open to
765 alternate ways to phrase this without opening the "modifying the DKIM
766 spec" can of worms. ]]
768 8.2. Assessing Chain Validity Violations
770 [[ SB-11: move to protocol elements
772 KA: This seems a bit banal. I suspect that what receivers want is a
773 section on using ARC to override DMARC failures. Would that be to
774 brazen to insert here instead? Or do we relegate that to the
775 [ARC-USAGE] doc? ]]
777 Email transit can produce broken signatures for a wide variety of
778 benign reasons. This includes possibly breaking one or more ARC
779 signatures. Therefore, receivers need to be wary of ascribing motive
780 to such breakage although patterns of common behaviour may provide
781 some basis for adjusting local policy decisions.
783 ARC does not attempt to protect an entire message. There are various
784 ways that a message can still be problematic, in spite of having a
785 valid ARC chain. Consequently, all normal, content-based analysis
786 SHOULD still be performed on any message having a valid chain of ARC
787 header sets.
789 9. Recording and Reporting the Results of ARC Evaluation
791 The evaluation of an ARC chain provides information which will be
792 useful to both the receiver (or intermediary) and to the initial
793 sender of the message. This information should be preserved and
794 reported as follows.
796 9.1. Information from an ARC Evaluation
798 The evaluation of an ARC chain produces a list of domain names for
799 participating intermediaries which handled the message, to wit:
801 o A list of the "d=" domains found in the validated ARC-Seal header
802 fields
804 o The "d=" domain found in the most recent (highest instance number)
805 AMS header field (since that is the only one necessarily
806 validated)
808 In the case of a failed chain, only the terminal ARC set is covered
809 by the ARC-Seal so the reporting is limited to the findings in that
810 terminal ARC set.
812 9.2. Recording (local) ARC Evaluation Results
814 Receivers MAY add an "arc=[pass|fail|policy]" method annotation into
815 a locally-affixed Authentication-Results [RFC7601] header field along
816 with any salient comment(s).
818 Details of the ARC chain which was evaluated should be included in
819 the Authentication-Results and AAR headers per Section Section 5.2.1.
821 9.3. DMARC Reporting of ARC Findings - Interim
823 [[ Note: Discussion on the IETF DMARC-WG list has indicated some
824 interest in more substantial reporting for analytic purposes. To
825 support that effort, the following guidance is provided only as an
826 interim, minimal data set. A more complete reporting construct will
827 be specified in a related spec - TBD. (see the additional fields
828 specified in Section 5.2.1) ]]
830 Receivers SHOULD indicate situations in which ARC evaluation
831 influenced the results of their local policy determination. DMARC
832 reporting of ARC-informed decisions can be accomplished by adding a
833 local_policy comment explanation containing the list of data
834 discovered in the ARC evaluation (Section 9.1 and Section 5.2.1):
836
837 delivered
838 fail
839 fail source.ip=10.0.0.1
840
841 local_policy
842 arc=pass ams[2].d=d2.example ams[2].s=s1 as[2].d=d2.example
843 as[2].s=s2 as[1].d=d1.example as[1].s=s3
844
845
847 In the suggested sample, d2.example is the sealing domain for ARC[2]
848 and d1.example is the sealing domain for ARC[1].
850 Mediators SHOULD generate DMARC reports on messages which transit
851 their system just like any other message which they receive. This
852 will result in multiple reports for each mediated message as they
853 transit the series of handlers. DMARC report consumers should be
854 aware of this behaviour and make the necessary accommodations.
856 10. Supporting Alternate Signing Algorithms
858 This section has been moved to [ARC-MULTI]
860 11. Privacy Considerations
862 The ARC chain provides a verifiable record of the handlers for a
863 message. Anonymous remailers will probably not find this compatible
864 with their operating goals.
866 12. IANA Considerations
868 This specification adds three new header fields as defined below.
870 12.1. Authentication-Results Method Registry Update
872 This draft adds one item to the IANA "Email Authentication Methods"
873 registry:
875 o Method : arc
877 Defined: [I-D.ARC]
879 ptype: header
881 Property: chain evaluation result
883 Value: chain evaluation result status (see Section 5.4)
885 Status: active
887 Version: 1
889 o Method : dkim
891 Defined: [I-D.ARC]
893 ptype: header
895 Property: selector
897 Value: value of signature "s" tag (see [RFC6376])
899 Status: active
900 Version: 1
902 o Method : spf
904 Defined: [I-D.ARC]
906 ptype: smtp
908 Property: client-ip
910 Value: the connecting client IP address from which the message is
911 received
913 Status: active
915 Version: 1
917 o Method : arc
919 Defined: [I-D.ARC]
921 ptype: header
923 Property: oldest-pass
925 Value: the oldest instance with a still validating AMS signature
927 Status: active
929 Version: 1
931 12.2. Definitions of the ARC header fields
933 This specification adds three new header fields to the "Permanent
934 Message Header Field Registry", as follows:
936 o Header field name: ARC-Seal
938 Applicable protocol: mail
940 Status: draft
942 Author/Change controller: IETF
944 Specification document(s): [I-D.ARC]
946 Related information: [RFC6376]
948 o Header field name: ARC-Message-Signature
950 Applicable protocol: mail
952 Status: draft
954 Author/Change controller: IETF
956 Specification document(s): [I-D.ARC]
958 Related information: [RFC6376]
960 o Header field name: ARC-Authentication-Results
962 Applicable protocol: mail
964 Status: standard
966 Author/Change controller: IETF
968 Specification document(s): [I-D.ARC]
970 Related information: [RFC7601]
972 13. Security Considerations
974 The Security Considerations of [RFC6376] and [RFC7601] apply directly
975 to this specification.
977 13.1. Header Size
979 Inclusion of ARC sets in the header of emails may cause problems for
980 some older or more constrained MTAs if they are unable to accept the
981 greater size of the header.
983 13.2. DNS Operations
985 Operators who receive a message bearing N ARC sets have to complete
986 up to N+1 DNS queries to evaluate the chain (barring DNS redirection
987 mechanisms which can increase the lookups for a given target value).
988 This has at least two effects:
990 1. An attacker can send a message to an ARC partipant with a
991 concocted sequence of ARC sets bearing the domains of intended
992 victims, and all of them will be queried by the participant until
993 a failure is discovered. The difficulty of forging the signature
994 values should limit the extent of this load to domains under
995 control of the attacker.
997 2. DKIM only does one DNS check per signature, while this one can do
998 many (per chain). Absent caching, slow DNS responses can cause
999 SMTP timeouts; and backlogged delivery queues on mediating
1000 systems. This could be exploited as a DoS attack.
1002 13.3. Message Content Suspicion
1004 Recipients are cautioned to treat messages bearing ARC sets with the
1005 same suspicion that they apply to all other email messages. This
1006 includes appropriate content scanning and other checks for
1007 potentially malicious content. The handlers which are identified
1008 within the ARC chain may be used to provide input to local policy
1009 engines in cases where DMARC validation fails (due to mediation
1010 impacting SPF attribution, DKIM validity or alignment).
1012 Note that a passing ARC chain may not adequately mean that the
1013 message is safe because:
1015 1. You have to trust all signatories; and
1017 2. Even trusted systems may have become compromised or may not
1018 properly authenticate messages, so even with a chain of trusted
1019 participants, the message might still never have authenticated in
1020 the first place (which is why you have the AAR to inspect) or
1021 could have been subject to unintended modifications.
1023 14. Evaluating the Efficacy of the ARC Protocol
1025 The ARC protocol is designed to mitigate some of the most common
1026 failure conditions for email which transits intermediary handlers en
1027 route to the final recipient. Some of these problems have happened
1028 due to the adoption of the DMARC protocol [RFC7489] and are listed in
1029 [RFC6377] and [RFC7960].
1031 As the ARC protocol becomes standardized and implemented amongst
1032 intermediary handlers, the following aspects should be evaluated in
1033 order to determine the success of the protocol in accomplishing the
1034 intended benefits.
1036 NOTE: Terminology within this section does NOT follow [RFC2119]
1037 interpretation. This section represents the current thoughts of the
1038 working group regarding unanswered questions related to the protocol.
1039 Wider deployment will inform these topics and probably expand them.
1041 14.1. Success Consideration
1043 Currently, many receivers have heuristically determined overrides in
1044 order to rescue mail from intermediary-caused failures. Many of
1045 those overrides rely on inferrence rather than direct evidence.
1047 ARC will be a success if, for ARC sealed messages, receivers are able
1048 to implment ARC-based algorithmic decisions based on the direct
1049 evidence found within the ARC chain. This is especially relevant for
1050 DMARC processing when the DKIM d= value is aligned with the
1051 rfc5322.From author domain.
1053 14.2. Failure Considerations
1055 The intent of ARC is to be at most value-add and at worst benign. If
1056 ARC opens up significant new vectors for abuse (see Section 13) then
1057 this protocol will be a failure. Note that weaknesses inherent in
1058 the mail protocols ARC is built upon (such as DKIM replay attacks and
1059 other known issues) are not new vectors which can be attributed to
1060 this specification.
1062 14.3. Open Questions
1064 The following open questions are academic and have no clear answer at
1065 the time of the development of the protocol. However, wide-spread
1066 deployment should be able to gather the necessary data to answer some
1067 or all of them.
1069 14.3.1. Value of the ARC-Seal (AS) Header
1071 Data should be collected to show if the ARC-Seal (AS) provides value
1072 beyond the ARC Message Signature (AMS) for either making delivery
1073 decisions or catching malicious actors trying to craft or replay
1074 malicious chains.
1076 14.3.2. DNS Overhead
1078 Longer ARC chains will require more queries to retrieve the keys for
1079 validating the chain. While this is not believed to be a security
1080 issue (see Section 13.2), it is unclear how much overhead will truly
1081 be added. This is similar to some of the initial processing and
1082 query load concerns which were debated at the time of the DKIM
1083 specification development.
1085 Data should be collected to better understand usable length and
1086 distribution of lengths found in valid ARC chains along with the the
1087 DNS impact of processing ARC chains.
1089 14.3.3. Distinguishing Valuable from Worthless Trace Information
1091 There are several edge cases where the information in the AAR can
1092 make the difference between message delivery or rejection. For
1093 example, if there is a well known mailing list that ARC seals but
1094 doesn't do its own initial DMARC enforcement, a Final Receiver with
1095 this knowledge could make a delivery decision based upon the
1096 authentication information it sees in the corresponding AAR header.
1098 Certain trace information in the AAR is useful/necessary in the
1099 construction of DMARC reports. It would be beneficial to identify
1100 the value-add of having intermediary-handled mail flow information
1101 added into the DMARC reports going back to senders.
1103 Certain receivers believe the entire set of trace information would
1104 be valuable to feed into machine learning systems to identify fraud
1105 and/or provide other signals related to message delivery.
1107 It is unclear what trace information will be valuable for all
1108 receivers, regardless of size.
1110 Data should be collected on what trace information receivers are
1111 using that provides useful signals that affect deliverability, and
1112 what portions of the trace data are left untouched or provide no
1113 useful information.
1115 Since many such systems are intentionly proprietary or confidential
1116 to prevent gaming by abusers, it may not be viable to reliably answer
1117 this particular question. The evolving nature of attacks can also
1118 shift the landscape of "useful" information over time.
1120 15. Implementation Status
1122 [[ Note: For minimizing section number references when the RFC editor
1123 removes this section, it has been moved to be the last section of the
1124 document before the Appendicies. ]]
1126 [[ Note to the RFC Editor: Please remove this section before
1127 publication along with the reference to [RFC6982]. ]]
1129 This section records the status of known implementations of the
1130 protocol defined by this specification at the time of posting of this
1131 Internet-Draft, and is based on a proposal described in [RFC6982].
1132 The description of implementations in this section is intended to
1133 assist the IETF in its decision processes in progressing drafts to
1134 RFCs. Please note that the listing of any individual implementation
1135 here does not imply endorsement by the IETF. Furthermore, no effort
1136 has been spent to verify the information presented here that was
1137 supplied by IETF contributors. This is not intended as, and must not
1138 be construed to be, a catalog of available implementations or their
1139 features. Readers are advised to note that other implementations may
1140 exist.
1142 This information is known to be correct as of the seventh
1143 interoperability test event which was held on 2017-07-15 & 16 at
1144 IETF99.
1146 For a few of the implementations, later status information was
1147 available as of December 2017.
1149 15.1. GMail test reflector and incoming validation
1151 Organization: Google
1153 Description: Internal production implementation with both debug
1154 analysis and validating + sealing pass-through function
1156 Status of Operation: Production - Incoming Validation
1158 Coverage: Full spec implemented as of [ARC-DRAFT-06]
1160 Licensing: Proprietary - Internal only
1162 Implementation Notes:
1164 o Full functionality was demonstrated during the interop testing on
1165 2017-07-15.
1167 Contact Info: arc-discuss@dmarc.org [1]
1169 15.2. AOL test reflector and internal tagging
1171 Organization: AOL
1173 Description: Internal prototype implementation with both debug
1174 analysis and validating + sealing pass-through function
1176 Status of Operation: Beta
1178 Coverage: ARC chain validity status checking is operational, but only
1179 applied to email addresses enrolled in the test program. This system
1180 conforms to [ARC-DRAFT-06]
1182 Licensing: Proprietary - Internal only
1184 Implementation Notes:
1186 o 2017-07-15: Full functionality verified during the interop
1187 testing.
1189 Contact Info: arc-discuss@dmarc.org [2]
1191 15.3. dkimpy
1193 Organization: dkimpy developers/Scott Kitterman
1195 Description: Python DKIM package
1197 Status of Operation: Production
1199 Coverage:
1201 o 2017-07-15: The internal test suite is incomplete, but the command
1202 line developmental version of validator was demonstrated to
1203 interoperate with the Google and AOL implementations during the
1204 interop on 2017-07-15 and the released version passes the tests in
1205 [ARC-TEST] (https://github.com/ValiMail/arc_test_suite) with both
1206 python and python3.
1208 Licensing: Open/Other (same as dkimpy package = BCD version 2)
1210 Contact Info: https://launchpad.net/dkimpy
1212 15.4. OpenARC
1214 Organization: TDP/Murray Kucherawy
1216 Description: Implemention of milter functionality related to the
1217 OpenDKIM and OpenDMARC packages
1219 Status of Operation: Beta
1221 Coverage: Built to support [ARC-DRAFT-10]
1223 Licensing: Open/Other (same as OpenDKIM and OpenDMARC packages)
1225 Implementation Notes:
1227 o The build is FreeBSD oriented but some packages have been built
1228 for easier deployment on RedHat-based Linux platforms.
1230 o Some issues still exist when deploying in a chained milter
1231 arrangement (such as OpenSPF -> OpenDKIM -> OpenDMARC -> OpenARC)
1232 with coordination between the stages. When deployed in a
1233 "sandwich" configuration around an MLM, there is no effective
1234 mechanism to convey trust from the ingress (validator) to egress
1235 (signer) instances. (_NOTE_: this is expected to resolved with a
1236 new release of OpenDMARC expected in January 2018.)
1238 Contact Info: arc-discuss@dmarc.org [3]
1240 15.5. Mailman 3.2 patch
1242 Organization: Mailman development team
1244 Description: Integrated ARC capabilities within the Mailman 3.2
1245 package
1247 Status of Operation: Patch submitted
1249 Coverage: Based on OpenARC
1251 Licensing: Same as mailman package - GPL
1253 Implementation Notes:
1255 o Appears to work properly in at least one beta deployment, but
1256 waiting on acceptance of the pull request into the mainline of
1257 mailman development
1259 Contact Info: https://www.gnu.org/software/mailman/contact.html
1261 15.6. Copernica/MailerQ web-based validation
1263 Organization: Copernica
1265 Description: Web-based validation of ARC-signed messages
1267 Status of Operation: Beta
1269 Coverage: Built to support [ARC-DRAFT-05]
1271 Licensing: On-line usage only
1273 Implementation Notes:
1275 o Released 2016-10-24
1277 o Requires full message content to be pasted into a web form found
1278 at http://arc.mailerq.com/ (warning - https is not supported).
1280 o An additional instance of an ARC signature can be added if one is
1281 willing to paste a private key into an unsecured web form.
1283 o 2017-07-15: Testing shows that results match the other
1284 implementations listed in this section.
1286 Contact Info: https://www.copernica.com/
1288 15.7. Rspamd
1290 Organization: Rspamd community
1292 Description: ARC signing and verification module
1294 Status of Operation: Production, though deployment usage is unknown
1296 Coverage: Built to support [ARC-DRAFT-06]
1298 Licensing: Open source
1300 Implementation Notes:
1302 o 2017-06-12: Released with version 1.6.0
1304 o 2017-07-15: Testing during the interop showed that the validation
1305 functionality interoperated with the Google, AOL, dkimpy and
1306 MailerQ implementations
1308 Contact Info: https://rspamd.com/doc/modules/arc.html and
1309 https://github.com/vstakhov/rspamd
1311 15.8. PERL MAIL::DKIM module
1313 Organization: FastMail
1315 Description: Email domain authentication (sign and/or verify) module,
1316 previously included SPF / DKIM / DMARC, now has ARC added
1318 Status of Operation: Production, deployment usage unknown
1320 Coverage: Built to support [ARC-DRAFT-10]
1322 Licensing: Open Source
1324 Implementation Notes:
1326 o 2017-12-15: v0.50 released with full test set passing for ARC
1328 Contact Info: http://search.cpan.org/~mbradshaw/Mail-DKIM-0.50/
1330 15.9. PERL Mail::Milter::Authentication module
1332 Organization: FastMail
1334 Description: Email domain authentication milter, uses MAIL::DKIM (see
1335 above)
1337 Status of Operation: Intial validation completed during IETF99
1338 hackathon with some follow-on work during the week
1340 Coverage: Built to support [I-D.ARC]
1342 Licensing: Open Source
1344 Implementation Notes:
1346 o 2017-07-15: Validation functionality which interoperates with
1347 Gmail, AOL, dkimpy was demonstrated; later in the week of IETF99,
1348 the signing functionality was reported to be working
1350 o 2017-07-20: ARC functionality has not yet been pushed back to the
1351 github repo but should be showing up soon
1353 Contact Info: https://github.com/fastmail/authentication_milter
1355 15.10. Sympa List Manager
1357 Organization: Sympa Dev Community
1359 Description: Work in progress
1361 Status of Operation: Work in progress
1363 Coverage: unknown
1365 Licensing: open source
1367 Implementation Notes:
1369 o 2018-01-05: Tracked as https://github.com/sympa-community/sympa/
1370 issues/153
1372 Contact Info: https://github.com/sympa-community
1374 15.11. Oracle Messaging Server
1376 Organization: Oracle
1378 Description:
1380 Status of Operation: Intial development work during IETF99 hackathon.
1381 Status since then unknown.
1383 Coverage: Built to support [ARC-DRAFT-06]
1385 Licensing: Unknown
1387 Implementation Notes:
1389 o Status since the work done in July 2017 is unknown.
1391 Contact Info:
1393 15.12. MessageSystems Momentum
1395 Organization: MessageSystems/SparkPost
1397 Description: OpenARC integration into the LUA-enabled Momentum
1398 processing space
1400 Status of Operation: Beta
1402 Coverage: Built to support [ARC-DRAFT-10]
1404 Licensing: Unknown
1406 Implementation Notes:
1408 o Initial deployments for validation expected in early 2018.
1410 Contact Info:
1412 16. References
1414 16.1. Normative References
1416 [RFC1345] Simonsen, K., "Character Mnemonics and Character Sets",
1417 RFC 1345, DOI 10.17487/RFC1345, June 1992,
1418 .
1420 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1421 Requirement Levels", BCP 14, RFC 2119,
1422 DOI 10.17487/RFC2119, March 1997,
1423 .
1425 [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and
1426 Functions", RFC 2142, DOI 10.17487/RFC2142, May 1997,
1427 .
1429 [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS
1430 Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999,
1431 .
1433 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes",
1434 RFC 3463, DOI 10.17487/RFC3463, January 2003,
1435 .
1437 [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys
1438 Identified Mail (DKIM)", RFC 4686, DOI 10.17487/RFC4686,
1439 September 2006, .
1441 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
1442 IANA Considerations Section in RFCs", RFC 5226,
1443 DOI 10.17487/RFC5226, May 2008,
1444 .
1446 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
1447 Specifications: ABNF", STD 68, RFC 5234,
1448 DOI 10.17487/RFC5234, January 2008,
1449 .
1451 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
1452 DOI 10.17487/RFC5321, October 2008,
1453 .
1455 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
1456 DOI 10.17487/RFC5322, October 2008,
1457 .
1459 [RFC5585] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys
1460 Identified Mail (DKIM) Service Overview", RFC 5585,
1461 DOI 10.17487/RFC5585, July 2009,
1462 .
1464 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
1465 DOI 10.17487/RFC5598, July 2009,
1466 .
1468 [RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker,
1469 "DomainKeys Identified Mail (DKIM) Development,
1470 Deployment, and Operations", RFC 5863,
1471 DOI 10.17487/RFC5863, May 2010,
1472 .
1474 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
1475 "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
1476 RFC 6376, DOI 10.17487/RFC6376, September 2011,
1477 .
1479 [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and
1480 Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377,
1481 September 2011, .
1483 [RFC6651] Kucherawy, M., "Extensions to DomainKeys Identified Mail
1484 (DKIM) for Failure Reporting", RFC 6651,
1485 DOI 10.17487/RFC6651, June 2012,
1486 .
1488 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
1489 Authorizing Use of Domains in Email, Version 1", RFC 7208,
1490 DOI 10.17487/RFC7208, April 2014,
1491 .
1493 [RFC7601] Kucherawy, M., "Message Header Field for Indicating
1494 Message Authentication Status", RFC 7601,
1495 DOI 10.17487/RFC7601, August 2015,
1496 .
1498 16.2. Informative References
1500 [ARC-DRAFT-05]
1501 Andersen, K., "Authenticated Received Chain (ARC) Protocol
1502 (I-D-05)", n.d., .
1505 [ARC-DRAFT-06]
1506 Andersen, K., "Authenticated Received Chain (ARC) Protocol
1507 (I-D-06)", n.d., .
1510 [ARC-DRAFT-10]
1511 Andersen, K., "Authenticated Received Chain (ARC) Protocol
1512 (I-D-10)", n.d., .
1515 [ARC-MULTI]
1516 Andersen, K., "Using Multiple Signing Algorithms with
1517 ARC", January 2018, .
1520 [ARC-TEST]
1521 Blank, S., "ARC Test Suite", January 2017,
1522 .
1524 [ARC-USAGE]
1525 Jones, S., Adams, T., Rae-Grant, J., and K. Andersen,
1526 "Recommended Usage of the ARC Headers", December 2017,
1527 .
1530 [ENHANCED-STATUS]
1531 "IANA SMTP Enhanced Status Codes", n.d.,
1532 .
1535 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
1536 Code: The Implementation Status Section", RFC 6982,
1537 DOI 10.17487/RFC6982, July 2013,
1538 .
1540 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
1541 Message Authentication, Reporting, and Conformance
1542 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
1543 .
1545 [RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky,
1546 E., Ed., and K. Andersen, Ed., "Interoperability Issues
1547 between Domain-based Message Authentication, Reporting,
1548 and Conformance (DMARC) and Indirect Email Flows",
1549 RFC 7960, DOI 10.17487/RFC7960, September 2016,
1550 .
1552 16.3. URIs
1554 [1] mailto:arc-discuss@dmarc.org
1556 [2] mailto:arc-discuss@dmarc.org
1558 [3] mailto:arc-discuss@dmarc.org
1560 [4] mailto:dmarc@ietf.org
1562 [5] mailto:arc-discuss@dmarc.org
1564 Appendix A. Appendix A - Design Requirements
1566 (This section is re-inserted for background information from
1567 [ARC-DRAFT-06] and earlier versions.)
1569 The specification of the ARC framework is driven by the following
1570 high-level goals, security considerations, and practical operational
1571 requirements.
1573 A.1. Primary Design Criteria
1575 o Provide a verifiable "chain of custody" for email messages;
1577 o Not require changes for originators of email;
1579 o Support the verification of the ARC header field set by each hop
1580 in the handling chain;
1582 o Work at Internet scale; and
1584 o Provide a trustable mechanism for the communication of
1585 Authentication-Results across trust boundaries.
1587 A.2. Out of Scope
1589 ARC is not a trust framework. Users of the ARC header fields are
1590 cautioned against making unsubstantiated conclusions when
1591 encountering a "broken" ARC sequence.
1593 Appendix B. Appendix B - Example Usage
1595 [[ Note: The following examples were mocked up early in the
1596 definition process for the spec. They no longer reflect the current
1597 definition and need various updates which will be included in a
1598 future draft. ]]
1600 (Obsolete but retained for illustrative purposes)
1602 B.1. Example 1: Simple mailing list
1604 B.1.1. Here's the message as it exits the Origin:
1606 Return-Path:
1607 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1608 (authenticated bits=0)
1609 by segv.d1.example with ESMTP id t0FN4a8O084569;
1610 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1611 (envelope-from jqd@d1.example)
1612 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
1613 s=20130426; t=1421363082;
1614 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1615 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
1616 Content-Transfer-Encoding;
1617 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw
1618 bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl
1619 gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1620 Message-ID: <54B84785.1060301@d1.example>
1621 Date: Thu, 14 Jan 2015 15:00:01 -0800
1622 From: John Q Doe
1623 To: arc@dmarc.org
1624 Subject: Example 1
1626 Hey gang,
1627 This is a test message.
1628 --J.
1630 B.1.2. Message is then received at example.org
1632 B.1.2.1. Example 1, Step A: Message forwarded to list members
1634 Processing at example.org:
1636 o example.org performs authentication checks
1638 o No previous Authentication-Results or ARC-Seal headers are present
1640 o example.org adds ARC-Authentication-Results header
1642 o example.org adds Received: header
1644 o example.org adds a ARC-Seal header
1646 Here's the message as it exits example.org:
1648 Return-Path:
1649 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1650 s=seal2015; d=example.org; cv=none;
1651 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1652 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1653 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1654 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
1655 d=example.org; s=clochette; t=1421363105;
1656 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
1657 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
1658 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
1659 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1F5
1660 vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+m4bw
1661 a6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
1662 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
1663 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
1664 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
1665 (envelope-from jqd@d1.example)
1666 ARC-Authentication-Results: i=1; lists.example.org;
1667 spf=pass smtp.mfrom=jqd@d1.example;
1668 dkim=pass (1024-bit key) header.i=@d1.example;
1669 dmarc=pass
1670 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1671 (authenticated bits=0)
1672 by segv.d1.example with ESMTP id t0FN4a8O084569;
1673 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1674 (envelope-from jqd@d1.example)
1675 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
1676 s=20130426; t=1421363082;
1677 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1678 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
1679 Content-Transfer-Encoding;
1680 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
1681 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
1682 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1683 Message-ID: <54B84785.1060301@d1.example>
1684 Date: Thu, 14 Jan 2015 15:00:01 -0800
1685 From: John Q Doe
1686 To: arc@example.org
1687 Subject: [Lists] Example 1
1689 Hey gang,
1690 This is a test message.
1691 --J.
1693 B.1.3. Example 1: Message received by Recipient
1695 Let's say that the Recipient is example.com
1697 Processing at example.com:
1699 o example.com performs usual authentication checks
1701 o example.com adds Authentication-Results: header, Received header
1703 o Determines that message fails DMARC
1705 o Checks for ARC-Seal: header; finds one
1707 o Validates the signature in the ARC-Seal: header, which covers the
1708 ARC-Authentication-Results: header
1710 o example.com can use the ARC-Authentication-Results values or
1711 verify the DKIM-Signature from lists.example.org
1713 Here's what the message looks like at this point:
1715 Return-Path:
1716 Received: from example.org (example.org [208.69.40.157])
1717 by clothilde.example.com with ESMTP id
1718 d200mr22663000ykb.93.1421363207
1719 for ; Thu, 14 Jan 2015 15:02:40 -0800 (PST)
1720 Authentication-Results: clothilde.example.com; spf=fail
1721 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
1722 header.i=@example.org; dmarc=fail; arc=pass
1723 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1724 s=seal2015; d=example.org; cv=none;
1725 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1726 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1727 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1728 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
1729 d=example.org; s=clochette; t=1421363105;
1730 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
1731 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
1732 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
1733 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
1734 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
1735 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
1736 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
1737 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
1738 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
1739 (envelope-from jqd@d1.example)
1740 ARC-Authentication-Results: i=1; lists.example.org;
1741 spf=pass smtp.mfrom=jqd@d1.example;
1742 dkim=pass (1024-bit key) header.i=@d1.example;
1743 dmarc=pass
1744 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1745 (authenticated bits=0)
1746 by segv.d1.example with ESMTP id t0FN4a8O084569;
1747 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1748 (envelope-from jqd@d1.example)
1749 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
1750 s=20130426; t=1421363082;
1751 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1752 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
1753 Content-Transfer-Encoding;
1754 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw
1755 bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl
1756 gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1757 Message-ID: <54B84785.1060301@d1.example>
1758 Date: Thu, 14 Jan 2015 15:00:01 -0800
1759 From: John Q Doe
1760 To: arc@example.org
1761 Subject: [Lists] Example 1
1763 Hey gang,
1764 This is a test message.
1765 --J.
1767 B.2. Example 2: Mailing list to forwarded mailbox
1769 B.2.1. Here's the message as it exits the Origin:
1771 Return-Path:
1772 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1773 (authenticated bits=0)
1774 by segv.d1.example with ESMTP id t0FN4a8O084569;
1775 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1776 (envelope-from jqd@d1.example)
1777 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
1778 s=20130426; t=1421363082;
1779 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1780 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
1781 Content-Transfer-Encoding;
1782 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw
1783 bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl
1784 gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1785 Message-ID: <54B84785.1060301@d1.example>
1786 Date: Thu, 14 Jan 2015 15:00:01 -0800
1787 From: John Q Doe
1788 To: arc@example.org
1789 Subject: Example 1
1791 Hey gang,
1792 This is a test message.
1793 --J.
1795 B.2.2. Message is then received at example.org
1797 B.2.2.1. Example 2, Step A: Message forwarded to list members
1799 Processing at example.org:
1801 o example.org performs authentication checks
1803 o example.org applies standard DKIM signature
1805 o No previous Authentication-Results or ARC-Seal headers are present
1807 o example.org adds ARC-Authentication-Results header
1809 o example.org adds usual Received: header
1811 o example.org adds a ARC-Seal header
1813 Here's the message as it exits Step A:
1815 Return-Path:
1816 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1817 s=seal2015; d=example.org; cv=none;
1818 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
1819 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
1820 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1821 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
1822 d=example.org; s=clochette; t=1421363105;
1823 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
1824 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
1825 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
1826 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
1827 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
1828 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
1829 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
1830 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
1831 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
1832 (envelope-from jqd@d1.example)
1833 ARC-Authentication-Results: i=1; lists.example.org;
1834 spf=pass smtp.mfrom=jqd@d1.example;
1835 dkim=pass (1024-bit key) header.i=@d1.example;
1836 dmarc=pass
1837 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1838 (authenticated bits=0)
1839 by segv.d1.example with ESMTP id t0FN4a8O084569;
1840 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1841 (envelope-from jqd@d1.example)
1842 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
1843 s=20130426; t=1421363082;
1844 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1845 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
1846 Content-Transfer-Encoding;
1847 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
1848 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
1849 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1850 Message-ID: <54B84785.1060301@d1.example>
1851 Date: Thu, 14 Jan 2015 15:00:01 -0800
1852 From: John Q Doe
1853 To: arc@example.org
1854 Subject: [Lists] Example 1
1856 Hey gang,
1857 This is a test message.
1858 --J.
1860 B.2.2.2. Example 2, Step B: Message from list forwarded
1862 The message is delivered to a mailbox at gmail.com
1863 Processing at gmail.com:
1865 o gmail.com performs usual authentication checks
1867 o gmail.com adds Authentication-Results: and Received: header
1869 o Determines that message fails DMARC
1871 o Checks for ARC-Seal: header; finds one
1873 o Validates the signature in the ARC-Seal: header, which covers the
1874 ARC-Authentication-Results: header
1876 o Uses the ARC-Authentication-Results: values, but:
1878 o Instead of delivering message, prepares to forward message per
1879 user settings
1881 o Applies usual DKIM signature
1883 o gmail.com adds it's own ARC-Seal: header, contents of which are
1885 * version
1887 * sequence number ("i=2")
1889 * hash algorithm (SHA256 as example)
1891 * timestamp ("t=")
1893 * selector for key ("s=notary01")
1895 * domain for key ("d=gmail.com")
1897 * headers included in hash ("h=ARC-Authentication-Results:ARC-
1898 Seal")
1900 * Note: algorithm requires only ARC-Seals with lower sequence #
1901 be included, in ascending order
1903 * signature of the header hash
1905 Here's what the message looks like at this point:
1907 Return-Path:
1908 ARC-Seal: i=2; a=rsa-sha256; t=1421363253;
1909 s=notary01; d=gmail.com; cv=pass;
1910 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDWR
1911 YbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/sut
1912 txO+RRNr0fCFw==
1913 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed;
1914 d=gmail.com; s=20120806;
1915 h=mime-version:content-type:x-original-sender:
1916 x-original-authentication-results:precedence:mailing-list:
1917 list-id:list-post:list-help:list-archive:sender:reply-to:
1918 list-unsubscribe:DKIM-Signature;
1919 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=;
1920 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1921 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1922 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBmfhS
1923 LF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJRFeM
1924 KdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwDBJtXw
1925 bQoZyRtb6X6q0mYaszUB8kw==
1926 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10
1927 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST)
1928 Authentication-Results: i=2; gmail.com; spf=fail
1929 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
1930 header.i=@example.org; dmarc=fail; arc=pass
1931 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1932 s=seal2015; d=example.org; cv=none:
1933 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1934 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1935 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1936 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
1937 d=example.org; s=clochette; t=1421363105;
1938 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
1939 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
1940 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
1941 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
1942 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
1943 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
1944 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
1945 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
1946 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
1947 (envelope-from jqd@d1.example)
1948 ARC-Authentication-Results: i=1; lists.example.org;
1949 spf=pass smtp.mfrom=jqd@d1.example;
1950 dkim=pass (1024-bit key) header.i=@d1.example;
1951 dmarc=pass
1952 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1953 (authenticated bits=0)
1954 by segv.d1.example with ESMTP id t0FN4a8O084569;
1955 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1956 (envelope-from jqd@d1.example)
1957 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
1958 s=20130426; t=1421363082;
1959 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1960 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
1961 Content-Transfer-Encoding;
1962 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
1963 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
1964 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1965 Message-ID: <54B84785.1060301@d1.example>
1966 Date: Thu, 14 Jan 2015 15:00:01 -0800
1967 From: John Q Doe
1968 To: arc@example.org
1969 Subject: [Lists] Example 1
1971 Hey gang,
1972 This is a test message.
1973 --J.
1975 B.2.3. Example 2: Message received by Recipient
1977 Let's say that the Recipient is example.com
1978 Processing at example.com:
1980 o example.com performs usual authentication checks
1982 o example.com adds Authentication-Results: header, Received header
1984 o Determines that message fails DMARC
1986 o Checks for ARC-Seal: header; finds two
1988 o Validates the signature in the highest numbered ("i=2") ARC-Seal:
1989 header, which covers all previous ARC-Seal: and ARC-
1990 Authentication-Results: headers
1992 o Validates the other ARC-Seal header ("i=1"), which covers the ARC-
1993 Authentication-Results: header
1995 o example.com uses the ARC-Authentication-Results: values
1997 Here's what the message looks like at this point:
1999 Return-Path:
2000 Received: from mail-ob0-f188.google.com (mail-ob0-f188.google.com
2001 [208.69.40.157]) by clothilde.example.com with ESMTP id
2002 d200mr22663000ykb.93.1421363268
2003 for ; Thu, 14 Jan 2015 15:03:15 -0800 (PST)
2005 Authentication-Results: clothilde.example.com; spf=fail
2006 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
2007 header.i=@gmail.com; dmarc=fail; arc=pass
2008 ARC-Seal: i=2; a=rsa-sha256; t=1421363253;
2009 s=notary01; d=gmail.com; cv=pass;
2010 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDWR
2011 YbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/sut
2012 txO+RRNr0fCFw==
2013 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed;
2014 d=gmail.com; s=20120806;
2015 h=mime-version:content-type:x-original-sender:
2016 x-original-authentication-results:precedence:mailing-list:
2017 list-id:list-post:list-help:list-archive:sender:reply-to:
2018 :list-unsubscribe:DKIM-Signature;
2019 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=;
2020 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
2021 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
2022 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBmfhS
2023 LF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJRFeM
2024 KdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwDBJtXw
2025 bQoZyRtb6X6q0mYaszUB8kw==
2026 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10
2027 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST)
2028 Authentication-Results: i=2; gmail.com; spf=fail
2029 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
2030 header.i=@example.org; dmarc=fail; arc=pass
2031 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
2032 s=seal2015; d=example.org; cv=none;
2033 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
2034 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
2035 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
2036 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
2037 d=example.org; s=clochette; t=1421363105;
2038 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
2039 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
2040 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
2041 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
2042 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
2043 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
2044 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
2045 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
2046 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
2047 (envelope-from jqd@d1.example)
2048 ARC-Authentication-Results: i=1; lists.example.org;
2049 spf=pass smtp.mfrom=jqd@d1.example;
2050 dkim=pass (1024-bit key) header.i=@d1.example;
2051 dmarc=pass
2052 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
2053 (authenticated bits=0)
2054 by segv.d1.example with ESMTP id t0FN4a8O084569;
2055 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
2056 (envelope-from jqd@d1.example)
2057 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
2058 s=20130426; t=1421363082;
2059 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
2060 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
2061 Content-Transfer-Encoding;
2062 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
2063 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
2064 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
2065 Message-ID: <54B84785.1060301@d1.example>
2066 Date: Thu, 14 Jan 2015 15:00:01 -0800
2067 From: John Q Doe
2068 To: arc@example.org
2069 Subject: [Lists] Example 1
2071 Hey gang,
2072 This is a test message.
2073 --J.
2075 B.3. Example 3: Mailing list to forwarded mailbox with source
2077 B.3.1. Here's the message as it exits the Origin:
2079 Return-Path:
2080 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
2081 (authenticated bits=0)
2082 by segv.d1.example with ESMTP id t0FN4a8O084569;
2083 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
2084 (envelope-from jqd@d1.example)
2085 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
2086 s=origin2015; d=d1.example; cv=none;
2087 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61T
2088 X6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69EU
2089 8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
2090 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
2091 d=d1.example; s=20130426; t=1421363082;
2092 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
2093 h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding;
2094 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrv
2095 Qwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3
2096 TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
2097 Message-ID: <54B84785.1060301@d1.example>
2098 Date: Thu, 14 Jan 2015 15:00:01 -0800
2099 From: John Q Doe
2100 To: arc@example.org
2101 Subject: Example 1
2103 Hey gang,
2104 This is a test message.
2105 --J.
2107 B.3.2. Message is then received at example.org
2109 B.3.2.1. Example 3, Step A: Message forwarded to list members with
2110 source
2112 Processing at example.org:
2114 o example.org performs authentication checks
2116 o example.org applies standard DKIM signature
2118 o Checks for ARC-Seal: header; finds one (i=1)
2120 o Validates the signature in the ARC-Seal (i=1): header, which
2121 covers the d1.example ARC-Message-Signature: header
2123 o example.org adds ARC-Authentication-Results header
2125 o example.org adds usual Received: header
2126 o example.org adds a DKIM-Signature
2128 o example.org adds a ARC-Seal header, contents of which are
2130 * sequence number ("i=2")
2132 * hash algorithm (SHA256 as example)
2134 * timestamp ("t=")
2136 * chain validity ("cv=")
2138 * selector for key ("s=seal2015")
2140 * domain for key ("d=example.org")
2142 * signature ("b=")
2144 Here's the message as it exits Step A:
2146 Return-Path:
2147 ARC-Seal: i=2; a=rsa-sha256; t=1421363107;
2148 s=seal2015; d=example.org; cv=pass;
2149 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
2150 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
2151 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
2152 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed;
2153 d=example.org; s=clochette; t=1421363105;
2154 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
2155 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
2156 List-Help:List-Subscribe:From:Reply-To:DKIM-Signature;
2157 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
2158 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
2159 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
2160 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
2161 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
2162 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
2163 (envelope-from jqd@d1.example)
2164 ARC-Authentication-Results: i=2; lists.example.org;
2165 spf=pass smtp.mfrom=jqd@d1.example;
2166 dkim=pass (1024-bit key) header.i=@d1.example;
2167 dmarc=pass
2168 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
2169 (authenticated bits=0)
2170 by segv.d1.example with ESMTP id t0FN4a8O084569;
2171 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
2172 (envelope-from jqd@d1.example)
2173 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
2174 s=origin2015; d=d1.example; cv=none;
2175 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
2176 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
2177 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
2178 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
2179 d=d1.example; s=20130426; t=1421363082;
2180 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
2181 h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding;
2182 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
2183 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
2184 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
2185 Message-ID: <54B84785.1060301@d1.example>
2186 Date: Thu, 14 Jan 2015 15:00:01 -0800
2187 From: John Q Doe
2188 To: arc@example.org
2189 Subject: [Lists] Example 1
2191 Hey gang,
2192 This is a test message.
2193 --J.
2195 B.3.2.2. Example 3, Step B: Message from list forwarded with source
2197 The message is delivered to a mailbox at gmail.com
2198 Processing at gmail.com:
2200 o gmail.com performs usual authentication checks
2202 o gmail.com adds Authentication-Results: and Received: header
2204 o Determines that message fails DMARC
2206 o Checks for ARC-Seal: header; finds two
2208 o Validates the signature in the ARC-Seal (i=2): header, which
2209 covers the ARC-Authentication-Results: header
2211 o Validates the signature in the ARC-Seal (i=1): header, which
2212 covers the d1.example ARC-Message-Signature: header
2214 o Uses the ARC-Authentication-Results: values, but:
2216 o Instead of delivering message, prepares to forward message per
2217 user settings
2219 o Applies usual DKIM signature
2221 o gmail.com adds it's own ARC-Seal: header, contents of which are
2223 * version
2225 * sequence number ("i=2")
2227 * hash algorithm (SHA256 as example)
2229 * timestamp ("t=")
2231 * selector for key ("s=notary01")
2233 * domain for key ("d=gmail.com")
2235 * Note: algorithm requires only ARC-Seals with lower sequence #
2236 be included, in ascending order
2238 * signature of the chain
2240 Here's what the message looks like at this point:
2242 Return-Path:
2243 ARC-Seal: i=3; a=rsa-sha256; t=1421363253;
2244 s=notary01; d=gmail.com; cv=pass;
2245 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwD
2246 WRYbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF
2247 /suttxO+RRNr0fCFw==
2248 ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed;
2249 d=gmail.com; s=20120806;
2250 h=mime-version:content-type:x-original-sender
2251 :x-original-authentication-results:precedence:mailing-list
2252 :list-id:list-post:list-help:list-archive:sender
2253 :list-unsubscribe:reply-to;
2254 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=;
2255 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
2256 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
2257 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBm
2258 fhSLF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJ
2259 RFeMKdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwD
2260 BJtXwbQoZyRtb6X6q0mYaszUB8kw==
2261 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10
2262 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST)
2263 Authentication-Results: i=3; gmail.com; spf=fail
2264 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
2265 header.i=@example.org; dmarc=fail; arc=pass
2266 ARC-Seal: i=2; a=rsa-sha256; t=1421363107;
2267 s=seal2015; d=example.org; cv=pass;
2268 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
2269 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
2270 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
2271 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed;
2272 d=example.org; s=clochette; t=1421363105;
2273 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
2274 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
2275 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
2276 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1
2277 F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+
2278 m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
2279 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
2280 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
2281 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
2282 (envelope-from jqd@d1.example)
2283 ARC-Authentication-Results: i=2; lists.example.org;
2284 spf=pass smtp.mfrom=jqd@d1.example;
2285 dkim=pass (1024-bit key) header.i=@d1.example;
2286 dmarc=pass
2287 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
2288 (authenticated bits=0)
2289 by segv.d1.example with ESMTP id t0FN4a8O084569;
2290 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
2291 (envelope-from jqd@d1.example)
2292 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
2293 s=origin2015; d=d1.example; cv=none;
2294 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
2295 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
2296 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
2297 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
2298 d=d1.example; s=20130426; t=1421363082;
2299 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
2300 h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding;
2301 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYij
2302 rvQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD
2303 4Gd3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
2304 Message-ID: <54B84785.1060301@d1.example>
2305 Date: Thu, 14 Jan 2015 15:00:01 -0800
2306 From: John Q Doe
2307 To: arc@example.org
2308 Subject: [Lists] Example 1
2310 Hey gang,
2311 This is a test message.
2312 --J.
2314 B.3.3. Example 3: Message received by Recipient
2316 Let's say that the Recipient is example.com
2317 Processing at example.com:
2319 o example.com performs usual authentication checks
2321 o example.com adds Authentication-Results: header, Received header
2323 o Determines that message fails DMARC
2325 o Checks for ARC-Seal: header; finds three
2327 o Validates the signature in the highest numbered ("i=2") ARC-Seal:
2328 header, which covers all previous ARC-Seal: and ARC-
2329 Authentication-Results: headers
2331 o Validates the other ARC-Seal header ("i=2"), which covers the ARC-
2332 Authentication-Results: header
2334 o Validates the other ARC-Seal header ("i=1"), which covers the
2335 d1.example ARC-Message-Signature: header
2337 o example.com uses the ARC-Authentication-Results: values
2338 Here's what the message looks like at this point:
2340 Return-Path:
2341 Received: from mail-ob0-f188.google.com (mail-ob0-f188.google.com
2342 [208.69.40.157]) by clothilde.example.com with ESMTP id
2343 d200mr22663000ykb.93.1421363268
2344 for ; Thu, 14 Jan 2015 15:03:15 -0800 (PST)
2345 Authentication-Results: clothilde.example.com; spf=fail
2346 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
2347 header.i=@gmail.com; dmarc=fail; arc=pass
2348 ARC-Seal: i=3; a=rsa-sha256; t=1421363253;
2349 s=notary01; d=gmail.com; cv=pass;
2350 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDW
2351 RYbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/s
2352 uttxO+RRNr0fCFw==
2353 ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed;
2354 d=gmail.com; s=20120806;
2355 h=mime-version:content-type:x-original-sender
2356 :x-original-authentication-results:precedence
2357 :mailing-list:list-id:list-post:list-help:list-archive:sender
2358 :list-unsubscribe:reply-to;
2359 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=;
2360 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
2361 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
2362 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBm
2363 fhSLF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJ
2364 RFeMKdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwD
2365 BJtXwbQoZyRtb6X6q0mYaszUB8kw==
2366 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10
2367 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST)
2368 Authentication-Results: i=3; gmail.com; spf=fail
2369 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
2370 header.i=@example.org; dmarc=fail; arc=pass
2371 ARC-Seal: i=2; a=rsa-sha256; t=1421363107;
2372 s=seal2015; d=example.org; cv=pass;
2373 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
2374 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
2375 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
2376 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed;
2377 d=example.org; s=clochette; t=1421363105;
2378 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
2379 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
2380 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
2381 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1
2382 F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+
2383 m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
2384 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
2385 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
2386 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
2387 (envelope-from jqd@d1.example)
2388 ARC-Authentication-Results: i=2; lists.example.org;
2389 spf=pass smtp.mfrom=jqd@d1.example;
2390 dkim=pass (1024-bit key) header.i=@d1.example;
2391 dmarc=pass
2392 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
2393 (authenticated bits=0)
2394 by segv.d1.example with ESMTP id t0FN4a8O084569;
2395 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
2396 (envelope-from jqd@d1.example)
2397 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
2398 s=origin2015; d=d1.example; cv=none;
2399 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
2400 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
2401 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
2402 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
2403 d=d1.example; s=20130426; t=1421363082;
2404 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
2405 h=MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding;
2406 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
2407 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
2408 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
2409 Message-ID: <54B84785.1060301@d1.example>
2410 Date: Thu, 14 Jan 2015 15:00:01 -0800
2411 From: John Q Doe
2412 To: arc@example.org
2413 Subject: [Lists] Example 1
2415 Hey gang,
2416 This is a test message.
2417 --J.
2419 Appendix C. Acknowledgements
2421 This draft is the work of OAR-Dev Group.
2423 The authors thank all of the OAR-Dev group for the ongoing help and
2424 though-provoking discussions from all the participants, especially:
2425 Alex Brotman, Brandon Long, Dave Crocker, Elizabeth Zwicky, Franck
2426 Martin, Greg Colburn, J. Trent Adams, John Rae-Grant, Mike Hammer,
2427 Mike Jones, Steve Jones, Terry Zink, Tim Draegen.
2429 Grateful appreciation is extended to the people who provided feedback
2430 through the discuss mailing list.
2432 Appendix D. Comments and Feedback
2434 Please address all comments, discussions, and questions to
2435 dmarc@ietf.org [4]. Earlier discussions can be found at arc-
2436 discuss@dmarc.org [5].
2438 Authors' Addresses
2440 Kurt Andersen
2441 LinkedIn
2442 1000 West Maude Ave
2443 Sunnyvale, California 94085
2444 USA
2446 Email: kurta@linkedin.com
2448 Brandon Long (editor)
2449 Google
2451 Email: blong@google.com
2453 Steven Jones (editor)
2454 TDP
2456 Email: smj@crash.com
2458 Seth Blank (editor)
2459 ValiMail
2461 Email: seth@valimail.com
2463 Murray Kucherawy (editor)
2464 TDP
2466 Email: superuser@gmail.com