idnits 2.17.1
draft-ietf-dmarc-arc-protocol-13.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 seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords -- however, there's a paragraph with
a matching beginning. Boilerplate error?
(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires).
== Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please
use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
mean).
Found 'SHOULD not' in this paragraph:
The AMS header field SHOULD not include (sign) the AAR header
field(s). (Early drafts of this protocol and some older examples
included the AAR header(s) within the signing scope for the AMS, but
ambiguity regarding which of the potentially multiple AAR headers (one
per ARC set) argues against such practice.)
-- The document date (March 21, 2018) is 2221 days in the past. Is this
intentional?
Checking references for intended status: Experimental
----------------------------------------------------------------------------
-- Looks like a reference, but probably isn't: '1' on line 1539
-- Looks like a reference, but probably isn't: '2' on line 1541
== Missing Reference: 'CFWS' is mentioned on line 559, but not defined
-- Looks like a reference, but probably isn't: '3' on line 1543
-- Looks like a reference, but probably isn't: '4' on line 1545
-- Looks like a reference, but probably isn't: '5' on line 1547
-- Looks like a reference, but probably isn't: '6' on line 1549
-- Looks like a reference, but probably isn't: '7' on line 1551
-- Looks like a reference, but probably isn't: '8' on line 1553
-- Looks like a reference, but probably isn't: '9' on line 1555
-- Looks like a reference, but probably isn't: '10' on line 1557
-- Looks like a reference, but probably isn't: '11' on line 1559
== Missing Reference: 'I-D.ARC' is mentioned on line 1360, but not defined
-- Looks like a reference, but probably isn't: '12' on line 1561
-- Looks like a reference, but probably isn't: '13' on line 1563
-- Looks like a reference, but probably isn't: '14' on line 1565
-- Looks like a reference, but probably isn't: '15' on line 1567
-- Looks like a reference, but probably isn't: '16' on line 1609
-- Looks like a reference, but probably isn't: '17' on line 2445
-- Looks like a reference, but probably isn't: '18' on line 2446
** 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: 2 errors (**), 0 flaws (~~), 10 warnings (==), 22 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: September 22, 2018 Google
6 S. Jones, Ed.
7 TDP
8 S. Blank, Ed.
9 ValiMail
10 M. Kucherawy, Ed.
11 TDP
12 March 21, 2018
14 Authenticated Received Chain (ARC) Protocol
15 draft-ietf-dmarc-arc-protocol-13
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 create an attached, authenticated record
23 of the status at each step along the handling path, for use by the
24 final recipient in making choices about the disposition of the
25 message. Changes in the message that might break existing
26 authentication mechanisms can be identified through the ARC set of
27 header fields.
29 Status of This Memo
31 This Internet-Draft is submitted in full conformance with the
32 provisions of BCP 78 and BCP 79.
34 Internet-Drafts are working documents of the Internet Engineering
35 Task Force (IETF). Note that other groups may also distribute
36 working documents as Internet-Drafts. The list of current Internet-
37 Drafts is at https://datatracker.ietf.org/drafts/current/.
39 Internet-Drafts are draft documents valid for a maximum of six months
40 and may be updated, replaced, or obsoleted by other documents at any
41 time. It is inappropriate to use Internet-Drafts as reference
42 material or to cite them other than as "work in progress."
44 This Internet-Draft will expire on September 22, 2018.
46 Copyright Notice
48 Copyright (c) 2018 IETF Trust and the persons identified as the
49 document authors. All rights reserved.
51 This document is subject to BCP 78 and the IETF Trust's Legal
52 Provisions Relating to IETF Documents
53 (https://trustee.ietf.org/license-info) in effect on the date of
54 publication of this document. Please review these documents
55 carefully, as they describe your rights and restrictions with respect
56 to this document. Code Components extracted from this document must
57 include Simplified BSD License text as described in Section 4.e of
58 the Trust Legal Provisions and are provided without warranty as
59 described in the Simplified BSD License.
61 Table of Contents
63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
64 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
65 1.1.1. High Level Summary . . . . . . . . . . . . . . . . . 5
66 1.1.2. Technical Summary . . . . . . . . . . . . . . . . . . 7
67 1.2. Definitions and Terminology . . . . . . . . . . . . . . . 7
68 1.2.1. Terms defined and used in this document . . . . . . . 7
69 1.2.2. Referenced Definitions . . . . . . . . . . . . . . . 8
70 2. Protocol Elements and Features . . . . . . . . . . . . . . . 8
71 2.1. Features of the ARC Protocol . . . . . . . . . . . . . . 9
72 2.1.1. Chain of Custody . . . . . . . . . . . . . . . . . . 9
73 2.1.2. Optional Participation . . . . . . . . . . . . . . . 10
74 2.1.3. Only one ARC Chain (One Chain to Rule Them All) . . . 10
75 2.1.4. All Failures are Permanent . . . . . . . . . . . . . 10
76 2.1.5. Benign nature of an ARC Set . . . . . . . . . . . . . 10
77 2.1.6. Key Management . . . . . . . . . . . . . . . . . . . 11
78 2.1.7. Trace Information . . . . . . . . . . . . . . . . . . 11
79 2.1.8. Instance Tags . . . . . . . . . . . . . . . . . . . . 11
80 2.1.9. Chain Validation Status . . . . . . . . . . . . . . . 11
81 3. The ARC Header Fields . . . . . . . . . . . . . . . . . . . . 11
82 3.1. Instance ('i=') Tag . . . . . . . . . . . . . . . . . . . 11
83 3.1.1. Valid Range for Instance Tags . . . . . . . . . . . . 12
84 3.2. ARC-Authentication-Results (AAR) . . . . . . . . . . . . 12
85 3.3. ARC-Message-Signature (AMS) . . . . . . . . . . . . . . . 13
86 3.4. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . . . 13
87 3.4.1. The 'cv' Tag . . . . . . . . . . . . . . . . . . . . 14
88 3.4.2. Implicit Header Fields . . . . . . . . . . . . . . . 14
89 4. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . 14
90 4.1. ARC Authentication-Results Information . . . . . . . . . 16
91 4.2. Handling DNS Problems While Validating ARC . . . . . . . 16
92 4.3. Responding to ARC Validity Violations During the SMTP
93 Transaction . . . . . . . . . . . . . . . . . . . . . . . 17
95 5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . 17
96 5.1. Marking and Sealing "cv=fail" (Invalid) Chains . . . . . 17
97 6. Usage of ARC and Chain Validity . . . . . . . . . . . . . . . 18
98 6.1. Relationship between DKIM-Signature and AMS signing
99 scopes . . . . . . . . . . . . . . . . . . . . . . . . . 18
100 6.2. Assessing Chain Validity Violations . . . . . . . . . . . 18
101 7. Recording and Reporting the Results of ARC Evaluation . . . . 18
102 7.1. Information from an ARC Evaluation . . . . . . . . . . . 18
103 7.2. Recording (local) ARC Evaluation Results . . . . . . . . 19
104 7.3. DMARC Reporting of ARC Findings - Interim . . . . . . . . 19
105 8. Supporting Alternate Signing Algorithms . . . . . . . . . . . 19
106 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20
107 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
108 10.1. Authentication-Results Method Registry Update . . . . . 20
109 10.2. Definitions of the ARC header fields . . . . . . . . . . 21
110 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22
111 11.1. Header Size . . . . . . . . . . . . . . . . . . . . . . 22
112 11.2. DNS Operations . . . . . . . . . . . . . . . . . . . . . 22
113 11.3. Message Content Suspicion . . . . . . . . . . . . . . . 22
114 12. Evaluating the Efficacy of the ARC Protocol . . . . . . . . . 23
115 12.1. Success Consideration . . . . . . . . . . . . . . . . . 23
116 12.2. Failure Considerations . . . . . . . . . . . . . . . . . 24
117 12.3. Open Questions . . . . . . . . . . . . . . . . . . . . . 24
118 12.3.1. Value of the ARC-Seal (AS) Header . . . . . . . . . 24
119 12.3.2. DNS Overhead . . . . . . . . . . . . . . . . . . . . 24
120 12.3.3. Distinguishing Valuable from Worthless Trace
121 Information . . . . . . . . . . . . . . . . . . . . 24
122 13. Implementation Status . . . . . . . . . . . . . . . . . . . . 25
123 13.1. GMail test reflector and incoming validation . . . . . . 26
124 13.2. AOL test reflector and internal tagging . . . . . . . . 26
125 13.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 26
126 13.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . 27
127 13.5. Mailman 3.2 patch . . . . . . . . . . . . . . . . . . . 27
128 13.6. Copernica/MailerQ web-based validation . . . . . . . . . 28
129 13.7. Rspamd . . . . . . . . . . . . . . . . . . . . . . . . . 28
130 13.8. PERL MAIL::DKIM module . . . . . . . . . . . . . . . . . 29
131 13.9. PERL Mail::Milter::Authentication module . . . . . . . . 29
132 13.10. Sympa List Manager . . . . . . . . . . . . . . . . . . . 30
133 13.11. Oracle Messaging Server . . . . . . . . . . . . . . . . 30
134 13.12. MessageSystems Momentum . . . . . . . . . . . . . . . . 31
135 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
136 14.1. Normative References . . . . . . . . . . . . . . . . . . 31
137 14.2. Informative References . . . . . . . . . . . . . . . . . 32
138 14.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 33
139 Appendix A. Appendix A - Design Requirements . . . . . . . . . . 34
140 A.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 34
141 A.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 35
142 Appendix B. Appendix B - Example Usage . . . . . . . . . . . . . 35
143 B.1. Example 1: Simple mailing list . . . . . . . . . . . . . 35
144 B.1.1. Here's the message as it exits the Origin: . . . . . 35
145 B.1.2. Message is then received at example.org . . . . . . . 35
146 B.1.3. Example 1: Message received by Recipient . . . . . . 38
147 B.2. Example 2: Mailing list to forwarded mailbox . . . . . . 39
148 B.2.1. Here's the message as it exits the Origin: . . . . . 39
149 B.2.2. Message is then received at example.org . . . . . . . 40
150 B.2.3. Example 2: Message received by Recipient . . . . . . 44
151 B.3. Example 3: Mailing list to forwarded mailbox with source 46
152 B.3.1. Here's the message as it exits the Origin: . . . . . 46
153 B.3.2. Message is then received at example.org . . . . . . . 47
154 B.3.3. Example 3: Message received by Recipient . . . . . . 52
155 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 54
156 Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 55
157 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55
159 1. Introduction
161 Modern email authentication techniques such as the Sender Policy
162 Framework (SPF) [RFC7208] and DomainKeys Identified Mail (DKIM)
163 [RFC6376] have become common. However, their end-to-end utility is
164 limited by the effects of intermediaries along the transmission path,
165 which either are not listed (for SPF) or which break digital
166 signatures (for DKIM). These issues are described in substantial
167 detail in those protocols' defining documents as well as in [RFC6377]
168 and [RFC7960].
170 Technologies that build upon the use of SPF and DKIM can reduce the
171 success of fraudulent email campaigns. To this end, Domain-based
172 Mail Authentication, Reporting and Compliance (DMARC) [RFC7489],
173 validates the domain of the RFC5322.From author header field.
174 However its use along email transmission paths that have independent
175 intermediaries, such as some forwarders and essentially all mailing
176 list services, produces false positive rejections that are
177 problematic, both for the message authors, the intermediary
178 service(s), and for those they are interacting with.
180 What is needed is a mechanism by which legitimate alteration of a
181 message, which invalidates associated SPF and DKIM information, does
182 not ultimately result in a rejection of an email message on delivery.
183 Authenticated Receive Chain (ARC) builds upon DKIM mechanisms to
184 provide a sequence of signatures that provide a view of the handling
185 sequence for a message, especially the points where alterations of
186 the content might have occurred. Equipped with this more complete
187 information, the recipient system(s) can make a more informed
188 handling choice, reducing or eliminating the rejections that would
189 occur with the use of DKIM and/or SPF alone.
191 1.1. Overview
193 ARC provides a "chain of custody" for a message, allowing each entity
194 that handles the message to see what entities handled it before, and
195 to see what the authentication status of the message was at each step
196 in the handling. The handling entity can then put its own entry into
197 the chain of custody and then relay the message to the next handler.
199 When the message reaches final delivery, the decision to accept and
200 deliver the message, or, alternatively, to reject, discard, or
201 quarantine it, can take the chain of custody into account, applying
202 local policy in addition to policies advertised by the (purported)
203 sending domain. Consider, for example, this scenario:
205 1. A sender from mysender.example posts a message to a mailing list
206 hosted at listmania.example;
208 2. The mailing list modifies the message by prepending the list name
209 to the subject line, then sends it to the subscribers;
211 3. One of the subscribers is alice@mail.service.example, which
212 receives the message from listmania.example.
214 Assuming the original message was DKIM-signed and mysender.example
215 published an SPF record, the handling by the mailing list will break
216 the DKIM signature because of the message modification, and the
217 forwarding will cause the SPF check to fail in the next step. But
218 listmania.example can add ARC headers to the message to add itself to
219 the document's chain of custody. When mail.service.example sees the
220 message, it can see that SPF and DKIM validation fail, but it can
221 also see that both of these succeeded when they were checked by
222 listmania.example, and can verify listmania's assertion.
224 As part of its evaluation of the message for delivery,
225 mail.service.example can see that mysender.example publishes a DMARC
226 policy asking that unauthenticated messages be rejected. But is can
227 also see the assertion by listmania.example that the message was
228 correctly authenticated when the message arrived there, and if it
229 accepts that assertion and that modifications made were benign, it
230 can deliver the message, rather than reject it, based on the
231 additional information that ARC has provided.
233 1.1.1. High Level Summary
235 In DKIM, every participating signing agent attaches a signature that
236 is based on the some of the content of the message, local policy, and
237 the domain name of the signing agent's Administrative Management
238 Domain (ADMD). Any verifier can process such a signature; a verified
239 signature means that the domain referenced in the signature's "d="
240 parameter has some responsibility for handling the message. An
241 artifact of using digital signature technology for this means that
242 verification also ensures that the portion of the message that was
243 "covered" by the signature has not been altered since the signature
244 was applied. The signatures themselves are generally independent of
245 one another.
247 In contrast, a validated ARC signature conveys the following pieces
248 of information:
250 1. An assertion that, at the time that the intermediary ADMD
251 processed the message, the various assertions (SPF, DKIM-
252 Signature(s) and/or ARC sets) already attached to the message by
253 other ADMDs were or were not valid;
255 2. As with DKIM, an assertion that, for a validated ARC signature,
256 the domain name in the signature takes some responsibility for
257 handling of the message and that the covered content of message
258 is unchanged since that signature was applied;
260 3. A further assertion that binds the ARC evaluation results into
261 the ARC chain sequence.
263 The ARC protocol accomplishes this by adding an "ARC Set" of three
264 new header fields to the message as follows:
266 1. ARC-Authentication-Results (referred to below as "AAR"):
267 virtually identical in syntax to an Authentication-Results field
268 [RFC7601], this field records the results of all message
269 authentication checks done by the recording ADMD at the time the
270 message arrived. Additional information is placed in this field
271 compared to a standard Authentication-Results field in order to
272 support a more complete DMARC report (see Section 3.2);
274 2. ARC-Message-Signature (referred to below as "AMS"): virtually
275 identical in syntax to DKIM-Signature, this field contains the
276 signature about the message header and body as they existed at
277 the time of handling by the ADMD adding it (including any
278 modifications made by the sealing ADMD); and
280 3. ARC-Seal (referred to below as "AS"): highly similar in structure
281 and format to a DKIM-Signature, this field applies a digital
282 signature that protects the integrity of all three of these new
283 fields when they are added by an ADMD, plus all instances of
284 these fields added by prior ADMDs.
286 An ARC participant always adds all of these header fields before
287 relaying a message to the next handling agent _en route_ to its
288 destination. Moreover, as described in Section 3.1, they each have
289 an "instance number" that increases with each ADMD in the handling
290 chain so that their original order can be preserved and the three
291 related header fields can be processed as a set.
293 1.1.2. Technical Summary
295 [[ possibly including a diagram - this may not be needed any more ]]
297 1.2. Definitions and Terminology
299 This section defines terms used in the rest of the document.
301 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
302 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
303 "OPTIONAL" in this document are to be interpreted as described in
304 BCP14 ([RFC2119][RFC8174]).
306 Because many of the core concepts and definitions are found in
307 [RFC5598], readers should to be familiar with the contents of
308 [RFC5598], and in particular, the potential roles of intermediaries
309 in the delivery of email.
311 Syntax descriptions use Augmented BNF (ABNF) [RFC5234].
313 1.2.1. Terms defined and used in this document
315 o "ARC-Authentication-Results" (AAR) - an ARC header field described
316 in Section 3.2.
318 o "ARC-Message-Signature" (AMS) - an ARC header field described in
319 Section 3.3.
321 o "ARC-Seal" (AS) - an ARC header field described in Section 3.4.
323 o "ARC Set" - A single group of the header fields introduced in
324 Section 1.1 is called an "ARC Set".
326 o "ARC Chain" - the complete sequence of ARC Sets for a message.
327 The ARC Chain represents a "chain of custody" for the message,
328 recording its authentication status at each ARC-compliant ADMD
329 that handled the message.
331 1.2.2. Referenced Definitions
333 The following terms are defined in other RFCs. Those definitions can
334 be found as follows:
336 o ADMD - [RFC5598], Section 2.3
338 o MTA - [RFC5598], Section 4.3.2
340 o MSA - [RFC5598], Section 4.3.1
342 o MDA - [RFC5598], Section 4.3.3
344 The three header fields that are part of this specification borrow
345 heavily from existing specifications. Rather than repeating all of
346 the formal definitions that are being reused in ARC, this document
347 only describes and specifies changes in syntax and semantics.
349 Language, syntax, and other details are imported from DKIM [RFC6376].
350 Specific references can be found below.
352 2. Protocol Elements and Features
354 As with other domain authentication technologies (such as SPF, DKIM,
355 and DMARC), ARC makes no claims about the contents of the email
356 message it has sealed. However, for a valid and passing ARC chain, a
357 Final Receiver is able to ascertain:
359 o all (participating) domains that claim responsibility for handling
360 (and possibly modifying) the email message in transit;
362 o trace information, including:
364 * the [RFC7601] authentication results each participating ADMD
365 saw; and
367 * additional data needed to compile a DMARC report for the
368 sending domain.
370 Given this information, a Final Receiver is able to make a more-
371 informed local policy decision regarding message delivery to the end
372 user in spite of an authentication failure.
374 Every participant in an ARC chain, except for the originating sender
375 and Final Receiver, is both an ARC Validator (when receiving) and
376 then an ARC Sealer (when sending a message onward). The validated
377 chain status as determined at message receipt must be passed to the
378 sealer function in order for sealing to occur properly; how this is
379 done is considered ADMD-specific and an implementation detail.
381 _INFORMATIONAL_: It is important to understand that validating and
382 then immediately sealing a message leaves no room for message
383 modification, and many early implementations of ARC did not initially
384 work because both operations were performed in a single pass over the
385 message.
387 2.1. Features of the ARC Protocol
389 The following protocol features are functional parts and design
390 decisions related the protocol that are not specific to either
391 Validators or Sealers, but ensure the ARC chain conveys this
392 information to a Final Receiver.
394 2.1.1. Chain of Custody
396 At a high level, an ARC chain represents a chain of custody of
397 authentication and other trace information (AAR) related to a
398 message, signed by each handler of the message. Each link in the
399 chain (AMS) is designed to be brittle, insofar as it survives only
400 until the next modification of the message. However, the sequence of
401 intermediaries in the handling chain (AS) is designed to remain
402 intact over the entirety of the chain.
404 The ARC chain can be conceptualized through an analogy with the chain
405 of custody for legal evidence. The material evidence itself is
406 sealed within an tamper-proof bag (AMS) each time. When handed to a
407 new party, that party both vouches for the state of the received
408 evidence container (AAR) and signs for the evidence on a chain of
409 custody report form (AS). As with all analogies, this one should not
410 be taken to interpretive extremes, but primarily used as a conceptual
411 framework.
413 An ARC chain that is valid and passing has the attributes listed
414 above in Section 2.
416 Recipients of an ARC chain that is invalid or does not pass SHOULD
417 NOT draw negative conclusions without a good understanding of the
418 wider handling context. Until ARC usage is widespread,
419 intermediaries will continue to modify messages without ARC seals.
420 As with a failing DKIM signature ([RFC6376] Section-6.3), a failing
421 ARC chain SHOULD be treated the same as a message with no ARC chain.
422 [[ NOTE TO WORKING GROUP: This paragraph probably is better placed in
423 Verifier actions. Ref issue 10 [1] ]]
425 2.1.2. Optional Participation
427 Validating an existing chain and then adding your own ARC set to a
428 message allows you to claim responsibility for handling the message
429 and modifications, if any, done by your ADMD to benefit message
430 delivery downstream. However, no ADMD is obligated to perform these
431 actions.
433 2.1.3. Only one ARC Chain (One Chain to Rule Them All)
435 A message can have only one ARC chain on it at a time (see
436 Section 3.1). Once broken, the chain cannot be continued, as the
437 chain of custody is no longer valid and responsibility for the
438 message has been lost. For further discussion of this topic and the
439 designed restriction which prevents chain continuation or re-
440 establishment, see [ARC-USAGE].
442 2.1.4. All Failures are Permanent
444 Because ARC chains are transmitted across multiple intermediaries,
445 all errors, even temporary ones, become unrecoverable and are
446 considered permanent.
448 Any error validating or sealing a chain, for whatever reason, MUST
449 result in a "cv=fail" verdict.
451 2.1.5. Benign nature of an ARC Set
453 Even when an ARC chain is valid and passes, its value is limited to
454 very specific cases. An ARC chain is specifically designed to
455 provide value to a Final Receiver evaluating message delivery in the
456 context of an authentication failure. An ARC chain in general, and
457 each ARC set in particular, provide additional information, and
458 otherwise is benign. Specifically:
460 o properly adding an ARC set to a message does not damage or
461 invalidate an existing chain, and
463 o validating a message exposes no new threat vectors (see
464 Section 11).
466 _INFORMATIONAL_: If an ADMD is unsure whether it will be re-emitting
467 and/or modifying a message, it may elect to seal all inbound mail.
468 For complex or nested ADMD relationships such as found in some hosted
469 mail solutions, this "inbound seal" can be used to facilitate
470 traversal of internal boundaries as well as properly conveying
471 incoming state to any egress MTAs that may need to assert a seal upon
472 exit from the ADMD. Since these internal relationships are highly
473 implementation dependent, this protocol definition can not usefully
474 explore such usage except to note that it is intentionally allowed
475 within the scope of this specification.
477 2.1.6. Key Management
479 The public keys for ARC header fields follow the same requirements,
480 syntax and semantics as those for DKIM signatures, described in
481 Section 3.6 of [RFC6376]. ARC places no requirements on the
482 selectors and/or domains used for the ARC header field signatures.
484 2.1.7. Trace Information
486 ARC includes trace information encoded in the AAR. While section
487 Section 3.2 defines what information must be provided, sealing ADMDs
488 may provide additional information, and validating receivers may use
489 or ignore this trace information as they wish.
491 2.1.8. Instance Tags
493 ARC introduces an indicator to its header fields to show the order in
494 which the header fields comprising an ARC set were added, and the
495 specific members of an ARC Set. This is known as an "instance", and
496 the indicator is an "i=". That is, the members of the first ARC set
497 affixed to a message will all include "i=1". This is described in
498 detail in section Section 3.1.
500 2.1.9. Chain Validation Status
502 ARC introduces a mechanism, also via a new tag, which indicates the
503 state of the ARC Chain at each step. This is the "chain validation
504 status". This is described in detail in section Section 3.4.1.
506 3. The ARC Header Fields
508 3.1. Instance ('i=') Tag
510 The header fields comprising a single ARC set are identified by the
511 presence of a string in the value portion of the header field that
512 complies with the "tag-spec" ABNF found in Section 3.2 of [RFC6376].
513 The tag-name is "i" and the value is the text representation of a
514 positive integer, indicating the position in the ARC sequence this
515 set occupies, where the first ARC set is numbered 1. In ABNF terms:
517 instance = [FWS] %x69 [FWS] "=" [FWS] position [FWS] ";"
518 position = 1*2DIGIT ; 1 - 50
520 Valid ARC sets must have exactly one instance of each header field
521 for a given position value and signing algorithm. (Initial
522 development of ARC is only being done with a single allowed signing
523 algorithm, but parallel work in the DCRUP working group [2] is
524 expanding that. For handling multiple signing algorithms, see
525 [ARC-MULTI].)
527 Because the AMS and AS header field values are made up of tag-spec
528 constructs, the i= tag may be found anywhere within the header field
529 value, but is represented throughout this spec in the initial
530 position for convenience. Implementers are encouraged to place the
531 i= tag at the beginning of the field value to facilitate human
532 inspection of the headers.
534 3.1.1. Valid Range for Instance Tags
536 The 'i' tag value can range from 1-50 (inclusive).
538 ARC implementations MUST support at least ten (10) ARC sets.
540 An effective operational maximum will have to be developed through
541 deployment experience in the field and will be documented within
542 [ARC-USAGE] once determined.
544 ARC chains with more than the defined operational maximum count MUST
545 be marked with "cv=fail".
547 3.2. ARC-Authentication-Results (AAR)
549 The ARC-Authentication-Results header field is syntactically and
550 semantically identical to an Authentication-Results header field
551 (defined in Section 2.2 of [I-D-7601bis] (A-R)). Note that several
552 optional data fields SHOULD be added (smtp.client-ip, dkim header.s,
553 arc.oldest-pass) to enable completeness for DMARC reporting.
555 Formally, the header field is specified as follows using ABNF
556 [RFC5234]:
558 arc-authres-header-prefix = "ARC-Authentication-Results:" [CFWS] arc-info
559 arc-info = instance *([CFWS] propspec) [CFWS] ";" authres-payload
561 The purpose of this header field is to transmit the results of any
562 authentication done on the message downstream to participating ADMDs
563 validating and continuing the chain.
565 The AAR MUST contain all A-R results from within the participating
566 ADMD, regardless of how many A-R headers are on the message.
568 3.3. ARC-Message-Signature (AMS)
570 The ARC-Message-Signature header field is syntactically and
571 semantically identical to a DKIM-Signature header field [RFC6376],
572 with the following exceptions:
574 o There is an "i" tag, as described in Section 3.1.
576 o There is no "v" tag defined for the AMS header. As required for
577 undefined tags, if seen, it MUST be ignored.
579 ARC-Seal header fields MUST NOT be included in the content covered by
580 the signature in this header field.
582 The AMS SHOULD include any DKIM-Signature header fields already
583 present on the message in the header fields covered by this
584 signature.
586 The AMS header field SHOULD not include (sign) the AAR header
587 field(s). (Early drafts of this protocol and some older examples
588 included the AAR header(s) within the signing scope for the AMS, but
589 ambiguity regarding which of the potentially multiple AAR headers
590 (one per ARC set) argues against such practice.)
592 Authentication-Results header fields SHOULD NOT be included since
593 they are likely to be deleted by downstream ADMDs (per Section XXX of
594 [RFC7601]), thereby breaking the AMS signature.
596 As with a DKIM-Signature, the purpose of this header field is to
597 allow the ADMD generating it to take some responsibility for handling
598 this message as it progresses toward delivery.
600 3.4. ARC-Seal (AS)
602 The ARC-Seal header field is syntactically and semantically similar
603 to a DKIM-Signature field, with the following exceptions:
605 o There is an "i" tag, as described in Section 3.1.
607 o The ARC-Seal covers none of the body content of the message. It
608 only covers specific header fields. (See below: Section 3.4.2.)
609 As a result, no body canonicalization is done. Further, only
610 "relaxed" header canonicalization (Section 3.4.2 of [RFC6376]) is
611 used.
613 o The only supported tags are "i" (Section 3.1 supercedes the
614 [RFC6376] definition), and "a", "b", "d, "s", "t". The latter 5
615 tag definitions are copied from Section 3.5 of [RFC6376].
617 o An additional tag, "cv" is defined. (See below: Section 3.4.1)
619 3.4.1. The 'cv' Tag
621 A new tag "cv" (chain validation) indicates the the outcome of
622 evaluating the existing ARC chain upon arrival at the ADMD that is
623 adding this header field. It accepts one of three possible values:
625 o none: There was no chain on the message when it arrived for
626 validation; typically occurs when the message arrives at a Message
627 Transfer Agent (MTA) from a Message Submission Agent (MSA) or when
628 any upstream MTAs may not be participating in ARC handling;
630 o fail: The message has a chain whose validation failed;
632 o pass: The message has a chain whose validation succeeded.
634 In ABNF terms:
636 seal-cv-tag = %x63.76 [FWS] "=" [FWS] ("none" / "fail" / "pass")
638 3.4.2. Implicit Header Fields
640 The ARC-Seal signs a canonicalized form of the ARC set header values.
641 The ARC set header values are compiled in increasing instance order,
642 starting at 1, and inclue the set being added at the time of sealing
643 the message.
645 Within a set, the header fields are listed in the following order:
647 1. ARC-Authentication-Results
649 2. ARC-Message-Signature
651 3. ARC-Seal
653 Where the ARC-Seal is the one being generated, it is input to the
654 hash function in its final form except with an empty "b=" value, in
655 the same manner by which a DKIM-Signature signs itself.
657 Note that the signing scope for the ARC-Seal is modified in the
658 situation where a chain has failed validation (see Section 5.1).
660 4. Verifier Actions
662 A verifier takes the following steps to determine the state of the
663 ARC chain on a message (cv value). Canonicalization, hash functions,
664 and signature validation methods are imported from Section 5 of
665 [RFC6376].
667 [[ Note: need markdown flag to have subordinate numbering distinction
668 issue 11 [3] ]]
670 1. Collect all ARC sets currently on the message. If there were
671 none, the ARC state is "none" and the algorithm stops here.
673 2. If the form of any ARC set is invalid (e.g., does not contain
674 exactly one of each of the three ARC-specific header fields),
675 then the chain state is "fail" and the algorithm stops here. a.
676 To avoid the overhead of unnecessary computation and delay from
677 crypto and DNS operations, the cv value for all ARC-Seal(s) MAY
678 be checked at this point. If any of the values are "fail", then
679 the overall state of the chain is "fail" and the algorithm stops
680 here.
682 3. Conduct verification of the ARC-Message-Signature header field
683 bearing the highest instance number. If this verification fails,
684 then the chain state is "fail" and the algorithm stops here.
686 4. For each ARC-Seal from the "N"th instance to the first, apply the
687 following logic: a. If the value of the "cv" tag on that seal is
688 "fail", the chain state is "fail" and the algorithm stops here.
689 (This step SHOULD be skipped if the earlier step (2.1) was
690 performed) b. In Boolean nomenclature: if ((i == 1 && cv !=
691 "none") or (cv == "none" && i != 1)) then the chain state is
692 "fail" and the algorithm stops here (note that the ordering of
693 the logic is structured for short-circuit evaluation). c.
694 Initialize a hash function corresponding to the "a" tag of the
695 ARC-Seal. d. Compute the canonicalized form of the ARC header
696 fields, in the order described in Section 3.4.2, using the
697 "relaxed" header canonicalization defined in Section 3.4.2 of
698 [RFC6376]. Pass the canonicalized result to the hash function.
699 e. Retrieve the final digest from the hash function. f.
700 Retrieve the public key identified by the "s" and "d" tags in the
701 ARC-Seal, as described in Section 2.1.6. g. Determine whether
702 the signature portion ("b" tag) of the ARC-Seal and the digest
703 computed above are valid according to the public key. (See also
704 Section Section 4.2 for failure case handling) h. If the
705 signature is not valid, the chain state is "fail" and the
706 algorithm stops here.
708 5. If all seals pass validation, then the chain state is "pass", and
709 the algorithm is complete.
711 6. Results from the determination of this algorithm SHOULD be
712 recorded in the Authentication-Results header
714 Whatever the end result of the verifier's checks via the algorithm
715 specified above, the results MUST be added into the Authentication-
716 Results header(s) for the ADMD.
718 [[ See issue 12 [4] regarding the final paragraph ]]
720 The verifier should save the cv state for subsequent use by any
721 sealing which may be done later (potentially after message
722 modification) within the same trust boundary. The cv state may be
723 recorded by sealing at the time of verification in an initial ARC set
724 (for the ADMD) or may be recorded out of band depending on the
725 architecture of the ADMD.
727 4.1. ARC Authentication-Results Information
729 Certain information pertinent to ascertaining message disposition can
730 be lost in transit when messages are handled by intermediaries. For
731 example, failing DKIM signatures are sometimes removed by MTAs, and
732 most DKIM signatures on messages modified by intermediaries will
733 fail. Recording the following information in the A-R provides a
734 mechanism for this information to survive transit.
736 The ptypes and properties defined in this section SHOULD be recorded
737 in the AR:
739 o smtp.client-ip - The connecting client IP address from which the
740 message is received;
742 o header.s - Defined in [RFC6376] section 7.2
744 o arc.oldest-pass - The instance number of the oldest AMS that still
745 validates, or 0 if all pass.
747 [[ Also see issue 20 [5] for another possible field to be added and
748 issue 21 [6] re which document should define these for IANA action.
749 ]]
751 4.2. Handling DNS Problems While Validating ARC
753 DNS-based failures to verify a chain are treated no differently than
754 any other ARC violation. They result in a "cv=fail" verdict.
756 4.3. Responding to ARC Validity Violations During the SMTP Transaction
758 If a receiver determines that the ARC chain has failed, the receiver
759 MAY signal the breakage through the extended SMTP response code 5.7.7
760 [RFC3463] "message integrity failure" [ENHANCED-STATUS] and
761 corresponding SMTP response code.
763 5. Signer Actions
765 [[ See issue 13 [7] for critique ]]
767 This section includes a specification of the actions an ARC signer
768 takes when presented with a message.
770 The signer MUST undertake the following steps:
772 1. Before creating an ARC signature, perform any other, normal
773 authentication and/or signing, so that the ARC signature can
774 cover those results.
776 2. Build and attach the new ARC set:
778 1. If an ARC chain exists on the message, then set "N" equal to
779 the highest instance number found on the chain (i=);
780 otherwise set "N" equal to zero for the following steps.
782 2. Generate and attach to the message an ARC-Authentication-
783 Results header field using instance number N+1 and the same
784 content from the previous step.
786 3. Generate and attach to the message an ARC-Message-Signature
787 header field as defined in Section 3.3 above, using instance
788 number N+1.
790 4. Generate and attach to the message an ARC-Seal header field
791 using the general algorithm described in Section 3.4 above,
792 the chain validation status as determined in Section 4, and
793 instance number N+1.
795 5.1. Marking and Sealing "cv=fail" (Invalid) Chains
797 The header fields signed by the AS header field b= value in the case
798 of a chain failure MUST be only the matching instance headers created
799 by the MTA which detected the malformed chain, as if this newest ARC
800 set was the only set present.
802 6. Usage of ARC and Chain Validity
804 6.1. Relationship between DKIM-Signature and AMS signing scopes
806 [[ See issue 14 [8] for critique of this section ]]
808 DKIM-Signatures SHOULD never sign any ARC header fields.
810 6.2. Assessing Chain Validity Violations
812 [[ Issue 15 [9] ]]
814 Email transit can produce broken signatures for a wide variety of
815 benign reasons. This includes possibly breaking one or more ARC
816 signatures. Therefore, receivers need to be wary of ascribing motive
817 to such breakage although patterns of common behaviour may provide
818 some basis for adjusting local policy decisions.
820 ARC does not attempt to protect an entire message. There are various
821 ways that a message can still be problematic, in spite of having a
822 valid ARC chain. Consequently, all normal, content-based analysis
823 SHOULD still be performed on any message having a valid chain of ARC
824 header sets.
826 7. Recording and Reporting the Results of ARC Evaluation
828 The evaluation of an ARC chain provides information which will be
829 useful to both the receiver (or intermediary) and to the initial
830 sender of the message. This information should be preserved and
831 reported as follows.
833 7.1. Information from an ARC Evaluation
835 The evaluation of an ARC chain produces a list of domain names for
836 participating intermediaries which handled the message, to wit:
838 o A list of the "d=" domains found in the validated ARC-Seal header
839 fields
841 o The "d=" domain found in the most recent (highest instance number)
842 AMS header field (since that is the only one necessarily
843 validated)
845 In the case of a failed chain, only the terminal ARC set is covered
846 by the ARC-Seal so the reporting is limited to the findings in that
847 terminal ARC set.
849 7.2. Recording (local) ARC Evaluation Results
851 Receivers MAY add an "arc=[pass|fail|policy]" method annotation into
852 a locally-affixed Authentication-Results [RFC7601] header field along
853 with any salient comment(s).
855 Details of the ARC chain which was evaluated should be included in
856 the Authentication-Results and AAR headers per Section Section 4.1.
858 7.3. DMARC Reporting of ARC Findings - Interim
860 [[ Note: Move to separate document? [10] (see the additional fields
861 specified in Section 4.1) ]]
863 Receivers SHOULD indicate situations in which ARC evaluation
864 influenced the results of their local policy determination. DMARC
865 reporting of ARC-informed decisions can be accomplished by adding a
866 local_policy comment explanation containing the list of data
867 discovered in the ARC evaluation (Section 7.1 and Section 4.1):
869
870 delivered
871 fail
872 fail source.ip=10.0.0.1
873
874 local_policy
875 arc=pass ams[2].d=d2.example ams[2].s=s1 as[2].d=d2.example
876 as[2].s=s2 as[1].d=d1.example as[1].s=s3
877
878
880 In the suggested sample, d2.example is the sealing domain for ARC[2]
881 and d1.example is the sealing domain for ARC[1].
883 Mediators SHOULD generate DMARC reports on messages which transit
884 their system just like any other message which they receive. This
885 will result in multiple reports for each mediated message as they
886 transit the series of handlers. DMARC report consumers should be
887 aware of this behaviour and make the necessary accommodations.
889 8. Supporting Alternate Signing Algorithms
891 This section has been moved to [ARC-MULTI]
893 9. Privacy Considerations
895 The ARC chain provides a verifiable record of the handlers for a
896 message. Anonymous remailers will probably not find this compatible
897 with their operating goals.
899 10. IANA Considerations
901 [[ See issue 21 [11] regarding which document should be definitive
902 for these fields. ]]
904 This specification adds three new header fields as defined below.
906 10.1. Authentication-Results Method Registry Update
908 This draft adds one item to the IANA "Email Authentication Methods"
909 registry:
911 o Method : arc
913 Defined: [I-D.ARC]
915 ptype: header
917 Property: chain evaluation result
919 Value: chain evaluation result status (see Section 3.4)
921 Status: active
923 o Method : dkim
925 Defined: [I-D.ARC]
927 ptype: header
929 Property: selector
931 Value: value of signature "s" tag (see [RFC6376])
933 Status: active
935 o Method : spf
937 Defined: [I-D.ARC]
939 ptype: smtp
940 Property: client-ip
942 Value: the connecting client IP address from which the message is
943 received
945 Status: active
947 o Method : arc
949 Defined: [I-D.ARC]
951 ptype: header
953 Property: oldest-pass
955 Value: the oldest instance with a still validating AMS signature
957 Status: active
959 10.2. Definitions of the ARC header fields
961 This specification adds three new header fields to the "Permanent
962 Message Header Field Registry", as follows:
964 o Header field name: ARC-Seal
966 Applicable protocol: mail
968 Status: draft
970 Author/Change controller: IETF
972 Specification document(s): [I-D.ARC]
974 Related information: [RFC6376]
976 o Header field name: ARC-Message-Signature
978 Applicable protocol: mail
980 Status: draft
982 Author/Change controller: IETF
984 Specification document(s): [I-D.ARC]
986 Related information: [RFC6376]
988 o Header field name: ARC-Authentication-Results
990 Applicable protocol: mail
992 Status: standard
994 Author/Change controller: IETF
996 Specification document(s): [I-D.ARC]
998 Related information: [RFC7601]
1000 11. Security Considerations
1002 The Security Considerations of [RFC6376] and [RFC7601] apply directly
1003 to this specification.
1005 11.1. Header Size
1007 Inclusion of ARC sets in the header of emails may cause problems for
1008 some older or more constrained MTAs if they are unable to accept the
1009 greater size of the header.
1011 11.2. DNS Operations
1013 Operators who receive a message bearing N ARC sets have to complete
1014 up to N+1 DNS queries to evaluate the chain (barring DNS redirection
1015 mechanisms which can increase the lookups for a given target value).
1016 This has at least two effects:
1018 1. An attacker can send a message to an ARC partipant with a
1019 concocted sequence of ARC sets bearing the domains of intended
1020 victims, and all of them will be queried by the participant until
1021 a failure is discovered. The difficulty of forging the signature
1022 values should limit the extent of this load to domains under
1023 control of the attacker.
1025 2. DKIM only does one DNS check per signature, while this one can do
1026 many (per chain). Absent caching, slow DNS responses can cause
1027 SMTP timeouts; and backlogged delivery queues on mediating
1028 systems. This could be exploited as a DoS attack.
1030 11.3. Message Content Suspicion
1032 Recipients are cautioned to treat messages bearing ARC sets with the
1033 same suspicion that they apply to all other email messages. This
1034 includes appropriate content scanning and other checks for
1035 potentially malicious content. The handlers which are identified
1036 within the ARC chain may be used to provide input to local policy
1037 engines in cases where DMARC validation fails (due to mediation
1038 impacting SPF attribution, DKIM validity or alignment).
1040 Note that a passing ARC chain may not adequately mean that the
1041 message is safe because:
1043 1. You have to trust all signatories; and
1045 2. Even trusted systems may have become compromised or may not
1046 properly authenticate messages, so even with a chain of trusted
1047 participants, the message might still never have authenticated in
1048 the first place (which is why you have the AAR to inspect) or
1049 could have been subject to unintended modifications.
1051 12. Evaluating the Efficacy of the ARC Protocol
1053 The ARC protocol is designed to mitigate some of the most common
1054 failure conditions for email which transits intermediary handlers en
1055 route to the final recipient. Some of these problems have happened
1056 due to the adoption of the DMARC protocol [RFC7489] and are listed in
1057 [RFC6377] and [RFC7960].
1059 As the ARC protocol becomes standardized and implemented amongst
1060 intermediary handlers, the following aspects should be evaluated in
1061 order to determine the success of the protocol in accomplishing the
1062 intended benefits.
1064 NOTE: Terminology within this section does NOT follow [RFC2119]
1065 interpretation. This section represents the current thoughts of the
1066 working group regarding unanswered questions related to the protocol.
1067 Wider deployment will inform these topics and probably expand them.
1069 12.1. Success Consideration
1071 Currently, many receivers have heuristically determined overrides in
1072 order to rescue mail from intermediary-caused failures. Many of
1073 those overrides rely on inferrence rather than direct evidence.
1075 ARC will be a success if, for ARC sealed messages, receivers are able
1076 to implment ARC-based algorithmic decisions based on the direct
1077 evidence found within the ARC chain. This is especially relevant for
1078 DMARC processing when the DKIM d= value is aligned with the
1079 rfc5322.From author domain.
1081 12.2. Failure Considerations
1083 The intent of ARC is to be at most value-add and at worst benign. If
1084 ARC opens up significant new vectors for abuse (see Section 11) then
1085 this protocol will be a failure. Note that weaknesses inherent in
1086 the mail protocols ARC is built upon (such as DKIM replay attacks and
1087 other known issues) are not new vectors which can be attributed to
1088 this specification.
1090 12.3. Open Questions
1092 The following open questions are academic and have no clear answer at
1093 the time of the development of the protocol. However, wide-spread
1094 deployment should be able to gather the necessary data to answer some
1095 or all of them.
1097 12.3.1. Value of the ARC-Seal (AS) Header
1099 Data should be collected to show if the ARC-Seal (AS) provides value
1100 beyond the ARC Message Signature (AMS) for either making delivery
1101 decisions or catching malicious actors trying to craft or replay
1102 malicious chains.
1104 12.3.2. DNS Overhead
1106 Longer ARC chains will require more queries to retrieve the keys for
1107 validating the chain. While this is not believed to be a security
1108 issue (see Section 11.2), it is unclear how much overhead will truly
1109 be added. This is similar to some of the initial processing and
1110 query load concerns which were debated at the time of the DKIM
1111 specification development.
1113 Data should be collected to better understand usable length and
1114 distribution of lengths found in valid ARC chains along with the the
1115 DNS impact of processing ARC chains.
1117 12.3.3. Distinguishing Valuable from Worthless Trace Information
1119 There are several edge cases where the information in the AAR can
1120 make the difference between message delivery or rejection. For
1121 example, if there is a well known mailing list that ARC seals but
1122 doesn't do its own initial DMARC enforcement, a Final Receiver with
1123 this knowledge could make a delivery decision based upon the
1124 authentication information it sees in the corresponding AAR header.
1126 Certain trace information in the AAR is useful/necessary in the
1127 construction of DMARC reports. It would be beneficial to identify
1128 the value-add of having intermediary-handled mail flow information
1129 added into the DMARC reports going back to senders.
1131 Certain receivers believe the entire set of trace information would
1132 be valuable to feed into machine learning systems to identify fraud
1133 and/or provide other signals related to message delivery.
1135 It is unclear what trace information will be valuable for all
1136 receivers, regardless of size.
1138 Data should be collected on what trace information receivers are
1139 using that provides useful signals that affect deliverability, and
1140 what portions of the trace data are left untouched or provide no
1141 useful information.
1143 Since many such systems are intentionly proprietary or confidential
1144 to prevent gaming by abusers, it may not be viable to reliably answer
1145 this particular question. The evolving nature of attacks can also
1146 shift the landscape of "useful" information over time.
1148 13. Implementation Status
1150 [[ Note to the RFC Editor: Please remove this section before
1151 publication along with the reference to [RFC6982]. ]]
1153 This section records the status of known implementations of the
1154 protocol defined by this specification at the time of posting of this
1155 Internet-Draft, and is based on a proposal described in [RFC6982].
1156 The description of implementations in this section is intended to
1157 assist the IETF in its decision processes in progressing drafts to
1158 RFCs. Please note that the listing of any individual implementation
1159 here does not imply endorsement by the IETF. Furthermore, no effort
1160 has been spent to verify the information presented here that was
1161 supplied by IETF contributors. This is not intended as, and must not
1162 be construed to be, a catalog of available implementations or their
1163 features. Readers are advised to note that other implementations may
1164 exist.
1166 This information is known to be correct as of the seventh
1167 interoperability test event which was held on 2017-07-15 & 16 at
1168 IETF99.
1170 For a few of the implementations, later status information was
1171 available as of December 2017.
1173 13.1. GMail test reflector and incoming validation
1175 Organization: Google
1177 Description: Internal production implementation with both debug
1178 analysis and validating + sealing pass-through function
1180 Status of Operation: Production - Incoming Validation
1182 Coverage: Full spec implemented as of [ARC-DRAFT-06]
1184 Licensing: Proprietary - Internal only
1186 Implementation Notes:
1188 o Full functionality was demonstrated during the interop testing on
1189 2017-07-15.
1191 Contact Info: arc-discuss@dmarc.org [12]
1193 13.2. AOL test reflector and internal tagging
1195 Organization: AOL
1197 Description: Internal prototype implementation with both debug
1198 analysis and validating + sealing pass-through function
1200 Status of Operation: Beta
1202 Coverage: ARC chain validity status checking is operational, but only
1203 applied to email addresses enrolled in the test program. This system
1204 conforms to [ARC-DRAFT-06]
1206 Licensing: Proprietary - Internal only
1208 Implementation Notes:
1210 o 2017-07-15: Full functionality verified during the interop
1211 testing.
1213 Contact Info: arc-discuss@dmarc.org [13]
1215 13.3. dkimpy
1217 Organization: dkimpy developers/Scott Kitterman
1219 Description: Python DKIM package
1220 Status of Operation: Production
1222 Coverage:
1224 o 2017-07-15: The internal test suite is incomplete, but the command
1225 line developmental version of validator was demonstrated to
1226 interoperate with the Google and AOL implementations during the
1227 interop on 2017-07-15 and the released version passes the tests in
1228 [ARC-TEST] arc_test_suite [14] with both python and python3.
1230 Licensing: Open/Other (same as dkimpy package = BCD version 2)
1232 Contact Info: https://launchpad.net/dkimpy
1234 13.4. OpenARC
1236 Organization: TDP/Murray Kucherawy
1238 Description: Implemention of milter functionality related to the
1239 OpenDKIM and OpenDMARC packages
1241 Status of Operation: Beta
1243 Coverage: Built to support [ARC-DRAFT-10]
1245 Licensing: Open/Other (same as OpenDKIM and OpenDMARC packages)
1247 Implementation Notes:
1249 o The build is FreeBSD oriented but some packages have been built
1250 for easier deployment on RedHat-based Linux platforms.
1252 o Some issues still exist when deploying in a chained milter
1253 arrangement (such as OpenSPF -> OpenDKIM -> OpenDMARC -> OpenARC)
1254 with coordination between the stages. When deployed in a
1255 "sandwich" configuration around an MLM, there is no effective
1256 mechanism to convey trust from the ingress (validator) to egress
1257 (signer) instances. (_NOTE_: this is expected to resolved with a
1258 new release of OpenDMARC expected in January 2018.)
1260 Contact Info: arc-discuss@dmarc.org [15]
1262 13.5. Mailman 3.2 patch
1264 Organization: Mailman development team
1266 Description: Integrated ARC capabilities within the Mailman 3.2
1267 package
1268 Status of Operation: Patch submitted
1270 Coverage: Based on OpenARC
1272 Licensing: Same as mailman package - GPL
1274 Implementation Notes:
1276 o Appears to work properly in at least one beta deployment, but
1277 waiting on acceptance of the pull request into the mainline of
1278 mailman development
1280 Contact Info: https://www.gnu.org/software/mailman/contact.html
1282 13.6. Copernica/MailerQ web-based validation
1284 Organization: Copernica
1286 Description: Web-based validation of ARC-signed messages
1288 Status of Operation: Beta
1290 Coverage: Built to support [ARC-DRAFT-05]
1292 Licensing: On-line usage only
1294 Implementation Notes:
1296 o Released 2016-10-24
1298 o Requires full message content to be pasted into a web form found
1299 at http://arc.mailerq.com/ (warning - https is not supported).
1301 o An additional instance of an ARC signature can be added if one is
1302 willing to paste a private key into an unsecured web form.
1304 o 2017-07-15: Testing shows that results match the other
1305 implementations listed in this section.
1307 Contact Info: https://www.copernica.com/
1309 13.7. Rspamd
1311 Organization: Rspamd community
1313 Description: ARC signing and verification module
1315 Status of Operation: Production, though deployment usage is unknown
1316 Coverage: Built to support [ARC-DRAFT-06]
1318 Licensing: Open source
1320 Implementation Notes:
1322 o 2017-06-12: Released with version 1.6.0
1324 o 2017-07-15: Testing during the interop showed that the validation
1325 functionality interoperated with the Google, AOL, dkimpy and
1326 MailerQ implementations
1328 Contact Info: https://rspamd.com/doc/modules/arc.html and
1329 https://github.com/vstakhov/rspamd
1331 13.8. PERL MAIL::DKIM module
1333 Organization: FastMail
1335 Description: Email domain authentication (sign and/or verify) module,
1336 previously included SPF / DKIM / DMARC, now has ARC added
1338 Status of Operation: Production, deployment usage unknown
1340 Coverage: Built to support [ARC-DRAFT-10]
1342 Licensing: Open Source
1344 Implementation Notes:
1346 o 2017-12-15: v0.50 released with full test set passing for ARC
1348 Contact Info: http://search.cpan.org/~mbradshaw/Mail-DKIM-0.50/
1350 13.9. PERL Mail::Milter::Authentication module
1352 Organization: FastMail
1354 Description: Email domain authentication milter, uses MAIL::DKIM (see
1355 above)
1357 Status of Operation: Intial validation completed during IETF99
1358 hackathon with some follow-on work during the week
1360 Coverage: Built to support [I-D.ARC]
1362 Licensing: Open Source
1363 Implementation Notes:
1365 o 2017-07-15: Validation functionality which interoperates with
1366 Gmail, AOL, dkimpy was demonstrated; later in the week of IETF99,
1367 the signing functionality was reported to be working
1369 o 2017-07-20: ARC functionality has not yet been pushed back to the
1370 github repo but should be showing up soon
1372 Contact Info: https://github.com/fastmail/authentication_milter
1374 13.10. Sympa List Manager
1376 Organization: Sympa Dev Community
1378 Description: Work in progress
1380 Status of Operation: Work in progress
1382 Coverage: unknown
1384 Licensing: open source
1386 Implementation Notes:
1388 o 2018-01-05: Tracked as https://github.com/sympa-community/sympa/
1389 issues/153
1391 Contact Info: https://github.com/sympa-community
1393 13.11. Oracle Messaging Server
1395 Organization: Oracle
1397 Description:
1399 Status of Operation: Intial development work during IETF99 hackathon.
1400 Status since then unknown.
1402 Coverage: Built to support [ARC-DRAFT-06]
1404 Licensing: Unknown
1406 Implementation Notes:
1408 o 2018-01: Protocol handling components are completed, but crypto is
1409 not yet functional.
1411 Contact Info: Chris Newman
1413 13.12. MessageSystems Momentum
1415 Organization: MessageSystems/SparkPost
1417 Description: OpenARC integration into the LUA-enabled Momentum
1418 processing space
1420 Status of Operation: Beta
1422 Coverage: Built to support [ARC-DRAFT-10]
1424 Licensing: Unknown
1426 Implementation Notes:
1428 o Initial deployments for validation expected in mid-2018.
1430 Contact Info:
1432 14. References
1434 14.1. Normative References
1436 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1437 Requirement Levels", BCP 14, RFC 2119,
1438 DOI 10.17487/RFC2119, March 1997,
1439 .
1441 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes",
1442 RFC 3463, DOI 10.17487/RFC3463, January 2003,
1443 .
1445 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
1446 Specifications: ABNF", STD 68, RFC 5234,
1447 DOI 10.17487/RFC5234, January 2008,
1448 .
1450 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
1451 DOI 10.17487/RFC5598, July 2009,
1452 .
1454 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
1455 "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
1456 RFC 6376, DOI 10.17487/RFC6376, September 2011,
1457 .
1459 [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and
1460 Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377,
1461 September 2011, .
1463 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
1464 Authorizing Use of Domains in Email, Version 1", RFC 7208,
1465 DOI 10.17487/RFC7208, April 2014,
1466 .
1468 [RFC7601] Kucherawy, M., "Message Header Field for Indicating
1469 Message Authentication Status", RFC 7601,
1470 DOI 10.17487/RFC7601, August 2015,
1471 .
1473 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1474 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1475 May 2017, .
1477 14.2. Informative References
1479 [ARC-DRAFT-05]
1480 Andersen, K., "Authenticated Received Chain (ARC) Protocol
1481 (I-D-05)", n.d., .
1484 [ARC-DRAFT-06]
1485 Andersen, K., "Authenticated Received Chain (ARC) Protocol
1486 (I-D-06)", n.d., .
1489 [ARC-DRAFT-10]
1490 Andersen, K., "Authenticated Received Chain (ARC) Protocol
1491 (I-D-10)", n.d., .
1494 [ARC-MULTI]
1495 Andersen, K., "Using Multiple Signing Algorithms with
1496 ARC", January 2018, .
1499 [ARC-TEST]
1500 Blank, S., "ARC Test Suite", January 2017,
1501 .
1503 [ARC-USAGE]
1504 Jones, S., Adams, T., Rae-Grant, J., and K. Andersen,
1505 "Recommended Usage of the ARC Headers", December 2017,
1506 .
1509 [ENHANCED-STATUS]
1510 "IANA SMTP Enhanced Status Codes", n.d.,
1511 .
1514 [I-D-7601bis]
1515 Kucherawy, M., "Message Header Field for Indicating
1516 Message Authentication Status", February 2018,
1517 .
1520 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
1521 Code: The Implementation Status Section", RFC 6982,
1522 DOI 10.17487/RFC6982, July 2013,
1523 .
1525 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
1526 Message Authentication, Reporting, and Conformance
1527 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
1528 .
1530 [RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky,
1531 E., Ed., and K. Andersen, Ed., "Interoperability Issues
1532 between Domain-based Message Authentication, Reporting,
1533 and Conformance (DMARC) and Indirect Email Flows",
1534 RFC 7960, DOI 10.17487/RFC7960, September 2016,
1535 .
1537 14.3. URIs
1539 [1] https://trac.ietf.org/trac/dmarc/ticket/10
1541 [2] https://datatracker.ietf.org/wg/dcrup/about/
1543 [3] https://trac.ietf.org/trac/dmarc/ticket/11
1545 [4] https://trac.ietf.org/trac/dmarc/ticket/12
1547 [5] https://trac.ietf.org/trac/dmarc/ticket/20
1549 [6] https://trac.ietf.org/trac/dmarc/ticket/21
1551 [7] https://trac.ietf.org/trac/dmarc/ticket/13
1553 [8] https://trac.ietf.org/trac/dmarc/ticket/14
1555 [9] https://trac.ietf.org/trac/dmarc/ticket/15
1557 [10] https://trac.ietf.org/trac/dmarc/ticket/16
1559 [11] https://trac.ietf.org/trac/dmarc/ticket/21
1561 [12] mailto:arc-discuss@dmarc.org
1563 [13] mailto:arc-discuss@dmarc.org
1565 [14] https://github.com/ValiMail/arc_test_suite
1567 [15] mailto:arc-discuss@dmarc.org
1569 [16] https://trac.ietf.org/trac/dmarc/ticket/17
1571 [17] mailto:dmarc@ietf.org
1573 [18] mailto:arc-discuss@dmarc.org
1575 Appendix A. Appendix A - Design Requirements
1577 (This section is re-inserted for background information from
1578 [ARC-DRAFT-06] and earlier versions.)
1580 The specification of the ARC framework is driven by the following
1581 high-level goals, security considerations, and practical operational
1582 requirements.
1584 A.1. Primary Design Criteria
1586 o Provide a verifiable "chain of custody" for email messages;
1588 o Not require changes for originators of email;
1590 o Support the verification of the ARC header field set by each hop
1591 in the handling chain;
1593 o Work at Internet scale; and
1595 o Provide a trustable mechanism for the communication of
1596 Authentication-Results across trust boundaries.
1598 A.2. Out of Scope
1600 ARC is not a trust framework. Users of the ARC header fields are
1601 cautioned against making unsubstantiated conclusions when
1602 encountering a "broken" ARC sequence.
1604 Appendix B. Appendix B - Example Usage
1606 [[ Note: The following examples were mocked up early in the
1607 definition process for the spec. They no longer reflect the current
1608 definition and need various updates which will be included in a
1609 future draft. Issue 17 [16] ]]
1611 (Obsolete but retained for illustrative purposes)
1613 B.1. Example 1: Simple mailing list
1615 B.1.1. Here's the message as it exits the Origin:
1617 Return-Path:
1618 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1619 (authenticated bits=0)
1620 by segv.d1.example with ESMTP id t0FN4a8O084569;
1621 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1622 (envelope-from jqd@d1.example)
1623 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
1624 s=20130426; t=1421363082;
1625 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1626 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
1627 Content-Transfer-Encoding;
1628 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw
1629 bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl
1630 gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1631 Message-ID: <54B84785.1060301@d1.example>
1632 Date: Thu, 14 Jan 2015 15:00:01 -0800
1633 From: John Q Doe
1634 To: arc@dmarc.org
1635 Subject: Example 1
1637 Hey gang,
1638 This is a test message.
1639 --J.
1641 B.1.2. Message is then received at example.org
1642 B.1.2.1. Example 1, Step A: Message forwarded to list members
1644 Processing at example.org:
1646 o example.org performs authentication checks
1648 o No previous Authentication-Results or ARC-Seal headers are present
1650 o example.org adds ARC-Authentication-Results header
1652 o example.org adds Received: header
1654 o example.org adds a ARC-Seal header
1656 Here's the message as it exits example.org:
1658 Return-Path:
1659 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1660 s=seal2015; d=example.org; cv=none;
1661 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1662 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1663 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1664 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
1665 d=example.org; s=clochette; t=1421363105;
1666 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
1667 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
1668 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
1669 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1F5
1670 vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+m4bw
1671 a6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
1672 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
1673 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
1674 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
1675 (envelope-from jqd@d1.example)
1676 ARC-Authentication-Results: i=1; lists.example.org;
1677 spf=pass smtp.mfrom=jqd@d1.example;
1678 dkim=pass (1024-bit key) header.i=@d1.example;
1679 dmarc=pass
1680 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1681 (authenticated bits=0)
1682 by segv.d1.example with ESMTP id t0FN4a8O084569;
1683 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1684 (envelope-from jqd@d1.example)
1685 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
1686 s=20130426; t=1421363082;
1687 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1688 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
1689 Content-Transfer-Encoding;
1690 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
1691 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
1692 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1693 Message-ID: <54B84785.1060301@d1.example>
1694 Date: Thu, 14 Jan 2015 15:00:01 -0800
1695 From: John Q Doe
1696 To: arc@example.org
1697 Subject: [Lists] Example 1
1699 Hey gang,
1700 This is a test message.
1701 --J.
1703 B.1.3. Example 1: Message received by Recipient
1705 Let's say that the Recipient is example.com
1707 Processing at example.com:
1709 o example.com performs usual authentication checks
1711 o example.com adds Authentication-Results: header, Received header
1713 o Determines that message fails DMARC
1715 o Checks for ARC-Seal: header; finds one
1717 o Validates the signature in the ARC-Seal: header, which covers the
1718 ARC-Authentication-Results: header
1720 o example.com can use the ARC-Authentication-Results values or
1721 verify the DKIM-Signature from lists.example.org
1723 Here's what the message looks like at this point:
1725 Return-Path:
1726 Received: from example.org (example.org [208.69.40.157])
1727 by clothilde.example.com with ESMTP id
1728 d200mr22663000ykb.93.1421363207
1729 for ; Thu, 14 Jan 2015 15:02:40 -0800 (PST)
1730 Authentication-Results: clothilde.example.com; spf=fail
1731 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
1732 header.i=@example.org; dmarc=fail; arc=pass
1733 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1734 s=seal2015; d=example.org; cv=none;
1735 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1736 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1737 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1738 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
1739 d=example.org; s=clochette; t=1421363105;
1740 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
1741 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
1742 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
1743 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
1744 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
1745 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
1746 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
1747 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
1748 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
1749 (envelope-from jqd@d1.example)
1750 ARC-Authentication-Results: i=1; lists.example.org;
1751 spf=pass smtp.mfrom=jqd@d1.example;
1752 dkim=pass (1024-bit key) header.i=@d1.example;
1753 dmarc=pass
1754 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1755 (authenticated bits=0)
1756 by segv.d1.example with ESMTP id t0FN4a8O084569;
1757 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1758 (envelope-from jqd@d1.example)
1759 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
1760 s=20130426; t=1421363082;
1761 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1762 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
1763 Content-Transfer-Encoding;
1764 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw
1765 bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl
1766 gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1767 Message-ID: <54B84785.1060301@d1.example>
1768 Date: Thu, 14 Jan 2015 15:00:01 -0800
1769 From: John Q Doe
1770 To: arc@example.org
1771 Subject: [Lists] Example 1
1773 Hey gang,
1774 This is a test message.
1775 --J.
1777 B.2. Example 2: Mailing list to forwarded mailbox
1779 B.2.1. Here's the message as it exits the Origin:
1781 Return-Path:
1782 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1783 (authenticated bits=0)
1784 by segv.d1.example with ESMTP id t0FN4a8O084569;
1785 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1786 (envelope-from jqd@d1.example)
1787 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
1788 s=20130426; t=1421363082;
1789 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1790 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
1791 Content-Transfer-Encoding;
1792 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw
1793 bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl
1794 gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1795 Message-ID: <54B84785.1060301@d1.example>
1796 Date: Thu, 14 Jan 2015 15:00:01 -0800
1797 From: John Q Doe
1798 To: arc@example.org
1799 Subject: Example 1
1801 Hey gang,
1802 This is a test message.
1803 --J.
1805 B.2.2. Message is then received at example.org
1807 B.2.2.1. Example 2, Step A: Message forwarded to list members
1809 Processing at example.org:
1811 o example.org performs authentication checks
1813 o example.org applies standard DKIM signature
1815 o No previous Authentication-Results or ARC-Seal headers are present
1817 o example.org adds ARC-Authentication-Results header
1819 o example.org adds usual Received: header
1821 o example.org adds a ARC-Seal header
1823 Here's the message as it exits Step A:
1825 Return-Path:
1826 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1827 s=seal2015; d=example.org; cv=none;
1828 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
1829 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
1830 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1831 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
1832 d=example.org; s=clochette; t=1421363105;
1833 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
1834 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
1835 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
1836 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
1837 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
1838 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
1839 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
1840 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
1841 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
1842 (envelope-from jqd@d1.example)
1843 ARC-Authentication-Results: i=1; lists.example.org;
1844 spf=pass smtp.mfrom=jqd@d1.example;
1845 dkim=pass (1024-bit key) header.i=@d1.example;
1846 dmarc=pass
1847 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1848 (authenticated bits=0)
1849 by segv.d1.example with ESMTP id t0FN4a8O084569;
1850 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1851 (envelope-from jqd@d1.example)
1852 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
1853 s=20130426; t=1421363082;
1854 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1855 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
1856 Content-Transfer-Encoding;
1857 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
1858 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
1859 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1860 Message-ID: <54B84785.1060301@d1.example>
1861 Date: Thu, 14 Jan 2015 15:00:01 -0800
1862 From: John Q Doe
1863 To: arc@example.org
1864 Subject: [Lists] Example 1
1866 Hey gang,
1867 This is a test message.
1868 --J.
1870 B.2.2.2. Example 2, Step B: Message from list forwarded
1872 The message is delivered to a mailbox at gmail.com
1873 Processing at gmail.com:
1875 o gmail.com performs usual authentication checks
1877 o gmail.com adds Authentication-Results: and Received: header
1879 o Determines that message fails DMARC
1881 o Checks for ARC-Seal: header; finds one
1883 o Validates the signature in the ARC-Seal: header, which covers the
1884 ARC-Authentication-Results: header
1886 o Uses the ARC-Authentication-Results: values, but:
1888 o Instead of delivering message, prepares to forward message per
1889 user settings
1891 o Applies usual DKIM signature
1893 o gmail.com adds it's own ARC-Seal: header, contents of which are
1895 * version
1897 * sequence number ("i=2")
1899 * hash algorithm (SHA256 as example)
1901 * timestamp ("t=")
1903 * selector for key ("s=notary01")
1905 * domain for key ("d=gmail.com")
1907 * headers included in hash ("h=ARC-Authentication-Results:ARC-
1908 Seal")
1910 * Note: algorithm requires only ARC-Seals with lower sequence #
1911 be included, in ascending order
1913 * signature of the header hash
1915 Here's what the message looks like at this point:
1917 Return-Path:
1918 ARC-Seal: i=2; a=rsa-sha256; t=1421363253;
1919 s=notary01; d=gmail.com; cv=pass;
1920 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDWR
1921 YbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/sut
1922 txO+RRNr0fCFw==
1923 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed;
1924 d=gmail.com; s=20120806;
1925 h=mime-version:content-type:x-original-sender:
1926 x-original-authentication-results:precedence:mailing-list:
1927 list-id:list-post:list-help:list-archive:sender:reply-to:
1928 list-unsubscribe:DKIM-Signature;
1929 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=;
1930 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1931 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1932 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBmfhS
1933 LF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJRFeM
1934 KdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwDBJtXw
1935 bQoZyRtb6X6q0mYaszUB8kw==
1936 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10
1937 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST)
1938 Authentication-Results: i=2; gmail.com; spf=fail
1939 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
1940 header.i=@example.org; dmarc=fail; arc=pass
1941 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1942 s=seal2015; d=example.org; cv=none:
1943 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1944 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1945 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1946 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
1947 d=example.org; s=clochette; t=1421363105;
1948 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
1949 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
1950 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
1951 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
1952 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
1953 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
1954 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
1955 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
1956 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
1957 (envelope-from jqd@d1.example)
1958 ARC-Authentication-Results: i=1; lists.example.org;
1959 spf=pass smtp.mfrom=jqd@d1.example;
1960 dkim=pass (1024-bit key) header.i=@d1.example;
1961 dmarc=pass
1962 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1963 (authenticated bits=0)
1964 by segv.d1.example with ESMTP id t0FN4a8O084569;
1965 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1966 (envelope-from jqd@d1.example)
1967 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
1968 s=20130426; t=1421363082;
1969 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1970 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
1971 Content-Transfer-Encoding;
1972 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
1973 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
1974 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1975 Message-ID: <54B84785.1060301@d1.example>
1976 Date: Thu, 14 Jan 2015 15:00:01 -0800
1977 From: John Q Doe
1978 To: arc@example.org
1979 Subject: [Lists] Example 1
1981 Hey gang,
1982 This is a test message.
1983 --J.
1985 B.2.3. Example 2: Message received by Recipient
1987 Let's say that the Recipient is example.com
1988 Processing at example.com:
1990 o example.com performs usual authentication checks
1992 o example.com adds Authentication-Results: header, Received header
1994 o Determines that message fails DMARC
1996 o Checks for ARC-Seal: header; finds two
1998 o Validates the signature in the highest numbered ("i=2") ARC-Seal:
1999 header, which covers all previous ARC-Seal: and ARC-
2000 Authentication-Results: headers
2002 o Validates the other ARC-Seal header ("i=1"), which covers the ARC-
2003 Authentication-Results: header
2005 o example.com uses the ARC-Authentication-Results: values
2007 Here's what the message looks like at this point:
2009 Return-Path:
2010 Received: from mail-ob0-f188.google.com (mail-ob0-f188.google.com
2011 [208.69.40.157]) by clothilde.example.com with ESMTP id
2012 d200mr22663000ykb.93.1421363268
2013 for ; Thu, 14 Jan 2015 15:03:15 -0800 (PST)
2015 Authentication-Results: clothilde.example.com; spf=fail
2016 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
2017 header.i=@gmail.com; dmarc=fail; arc=pass
2018 ARC-Seal: i=2; a=rsa-sha256; t=1421363253;
2019 s=notary01; d=gmail.com; cv=pass;
2020 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDWR
2021 YbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/sut
2022 txO+RRNr0fCFw==
2023 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed;
2024 d=gmail.com; s=20120806;
2025 h=mime-version:content-type:x-original-sender:
2026 x-original-authentication-results:precedence:mailing-list:
2027 list-id:list-post:list-help:list-archive:sender:reply-to:
2028 :list-unsubscribe:DKIM-Signature;
2029 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=;
2030 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
2031 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
2032 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBmfhS
2033 LF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJRFeM
2034 KdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwDBJtXw
2035 bQoZyRtb6X6q0mYaszUB8kw==
2036 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10
2037 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST)
2038 Authentication-Results: i=2; gmail.com; spf=fail
2039 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
2040 header.i=@example.org; dmarc=fail; arc=pass
2041 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
2042 s=seal2015; d=example.org; cv=none;
2043 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
2044 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
2045 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
2046 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
2047 d=example.org; s=clochette; t=1421363105;
2048 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
2049 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
2050 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
2051 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
2052 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
2053 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
2054 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
2055 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
2056 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
2057 (envelope-from jqd@d1.example)
2058 ARC-Authentication-Results: i=1; lists.example.org;
2059 spf=pass smtp.mfrom=jqd@d1.example;
2060 dkim=pass (1024-bit key) header.i=@d1.example;
2061 dmarc=pass
2062 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
2063 (authenticated bits=0)
2064 by segv.d1.example with ESMTP id t0FN4a8O084569;
2065 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
2066 (envelope-from jqd@d1.example)
2067 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
2068 s=20130426; t=1421363082;
2069 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
2070 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
2071 Content-Transfer-Encoding;
2072 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
2073 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
2074 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
2075 Message-ID: <54B84785.1060301@d1.example>
2076 Date: Thu, 14 Jan 2015 15:00:01 -0800
2077 From: John Q Doe
2078 To: arc@example.org
2079 Subject: [Lists] Example 1
2081 Hey gang,
2082 This is a test message.
2083 --J.
2085 B.3. Example 3: Mailing list to forwarded mailbox with source
2087 B.3.1. Here's the message as it exits the Origin:
2089 Return-Path:
2090 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
2091 (authenticated bits=0)
2092 by segv.d1.example with ESMTP id t0FN4a8O084569;
2093 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
2094 (envelope-from jqd@d1.example)
2095 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
2096 s=origin2015; d=d1.example; cv=none;
2097 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61T
2098 X6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69EU
2099 8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
2100 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
2101 d=d1.example; s=20130426; t=1421363082;
2102 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
2103 h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding;
2104 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrv
2105 Qwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3
2106 TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
2107 Message-ID: <54B84785.1060301@d1.example>
2108 Date: Thu, 14 Jan 2015 15:00:01 -0800
2109 From: John Q Doe
2110 To: arc@example.org
2111 Subject: Example 1
2113 Hey gang,
2114 This is a test message.
2115 --J.
2117 B.3.2. Message is then received at example.org
2119 B.3.2.1. Example 3, Step A: Message forwarded to list members with
2120 source
2122 Processing at example.org:
2124 o example.org performs authentication checks
2126 o example.org applies standard DKIM signature
2128 o Checks for ARC-Seal: header; finds one (i=1)
2130 o Validates the signature in the ARC-Seal (i=1): header, which
2131 covers the d1.example ARC-Message-Signature: header
2133 o example.org adds ARC-Authentication-Results header
2135 o example.org adds usual Received: header
2136 o example.org adds a DKIM-Signature
2138 o example.org adds a ARC-Seal header, contents of which are
2140 * sequence number ("i=2")
2142 * hash algorithm (SHA256 as example)
2144 * timestamp ("t=")
2146 * chain validity ("cv=")
2148 * selector for key ("s=seal2015")
2150 * domain for key ("d=example.org")
2152 * signature ("b=")
2154 Here's the message as it exits Step A:
2156 Return-Path:
2157 ARC-Seal: i=2; a=rsa-sha256; t=1421363107;
2158 s=seal2015; d=example.org; cv=pass;
2159 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
2160 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
2161 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
2162 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed;
2163 d=example.org; s=clochette; t=1421363105;
2164 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
2165 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
2166 List-Help:List-Subscribe:From:Reply-To:DKIM-Signature;
2167 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
2168 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
2169 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
2170 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
2171 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
2172 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
2173 (envelope-from jqd@d1.example)
2174 ARC-Authentication-Results: i=2; lists.example.org;
2175 spf=pass smtp.mfrom=jqd@d1.example;
2176 dkim=pass (1024-bit key) header.i=@d1.example;
2177 dmarc=pass
2178 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
2179 (authenticated bits=0)
2180 by segv.d1.example with ESMTP id t0FN4a8O084569;
2181 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
2182 (envelope-from jqd@d1.example)
2183 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
2184 s=origin2015; d=d1.example; cv=none;
2185 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
2186 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
2187 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
2188 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
2189 d=d1.example; s=20130426; t=1421363082;
2190 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
2191 h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding;
2192 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
2193 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
2194 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
2195 Message-ID: <54B84785.1060301@d1.example>
2196 Date: Thu, 14 Jan 2015 15:00:01 -0800
2197 From: John Q Doe
2198 To: arc@example.org
2199 Subject: [Lists] Example 1
2201 Hey gang,
2202 This is a test message.
2203 --J.
2205 B.3.2.2. Example 3, Step B: Message from list forwarded with source
2207 The message is delivered to a mailbox at gmail.com
2208 Processing at gmail.com:
2210 o gmail.com performs usual authentication checks
2212 o gmail.com adds Authentication-Results: and Received: header
2214 o Determines that message fails DMARC
2216 o Checks for ARC-Seal: header; finds two
2218 o Validates the signature in the ARC-Seal (i=2): header, which
2219 covers the ARC-Authentication-Results: header
2221 o Validates the signature in the ARC-Seal (i=1): header, which
2222 covers the d1.example ARC-Message-Signature: header
2224 o Uses the ARC-Authentication-Results: values, but:
2226 o Instead of delivering message, prepares to forward message per
2227 user settings
2229 o Applies usual DKIM signature
2231 o gmail.com adds it's own ARC-Seal: header, contents of which are
2233 * version
2235 * sequence number ("i=2")
2237 * hash algorithm (SHA256 as example)
2239 * timestamp ("t=")
2241 * selector for key ("s=notary01")
2243 * domain for key ("d=gmail.com")
2245 * Note: algorithm requires only ARC-Seals with lower sequence #
2246 be included, in ascending order
2248 * signature of the chain
2250 Here's what the message looks like at this point:
2252 Return-Path:
2253 ARC-Seal: i=3; a=rsa-sha256; t=1421363253;
2254 s=notary01; d=gmail.com; cv=pass;
2255 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwD
2256 WRYbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF
2257 /suttxO+RRNr0fCFw==
2258 ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed;
2259 d=gmail.com; s=20120806;
2260 h=mime-version:content-type:x-original-sender
2261 :x-original-authentication-results:precedence:mailing-list
2262 :list-id:list-post:list-help:list-archive:sender
2263 :list-unsubscribe:reply-to;
2264 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=;
2265 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
2266 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
2267 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBm
2268 fhSLF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJ
2269 RFeMKdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwD
2270 BJtXwbQoZyRtb6X6q0mYaszUB8kw==
2271 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10
2272 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST)
2273 Authentication-Results: i=3; gmail.com; spf=fail
2274 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
2275 header.i=@example.org; dmarc=fail; arc=pass
2276 ARC-Seal: i=2; a=rsa-sha256; t=1421363107;
2277 s=seal2015; d=example.org; cv=pass;
2278 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
2279 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
2280 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
2281 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed;
2282 d=example.org; s=clochette; t=1421363105;
2283 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
2284 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
2285 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
2286 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1
2287 F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+
2288 m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
2289 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
2290 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
2291 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
2292 (envelope-from jqd@d1.example)
2293 ARC-Authentication-Results: i=2; lists.example.org;
2294 spf=pass smtp.mfrom=jqd@d1.example;
2295 dkim=pass (1024-bit key) header.i=@d1.example;
2296 dmarc=pass
2297 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
2298 (authenticated bits=0)
2299 by segv.d1.example with ESMTP id t0FN4a8O084569;
2300 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
2301 (envelope-from jqd@d1.example)
2302 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
2303 s=origin2015; d=d1.example; cv=none;
2304 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
2305 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
2306 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
2307 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
2308 d=d1.example; s=20130426; t=1421363082;
2309 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
2310 h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding;
2311 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYij
2312 rvQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD
2313 4Gd3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
2314 Message-ID: <54B84785.1060301@d1.example>
2315 Date: Thu, 14 Jan 2015 15:00:01 -0800
2316 From: John Q Doe
2317 To: arc@example.org
2318 Subject: [Lists] Example 1
2320 Hey gang,
2321 This is a test message.
2322 --J.
2324 B.3.3. Example 3: Message received by Recipient
2326 Let's say that the Recipient is example.com
2327 Processing at example.com:
2329 o example.com performs usual authentication checks
2331 o example.com adds Authentication-Results: header, Received header
2333 o Determines that message fails DMARC
2335 o Checks for ARC-Seal: header; finds three
2337 o Validates the signature in the highest numbered ("i=2") ARC-Seal:
2338 header, which covers all previous ARC-Seal: and ARC-
2339 Authentication-Results: headers
2341 o Validates the other ARC-Seal header ("i=2"), which covers the ARC-
2342 Authentication-Results: header
2344 o Validates the other ARC-Seal header ("i=1"), which covers the
2345 d1.example ARC-Message-Signature: header
2347 o example.com uses the ARC-Authentication-Results: values
2348 Here's what the message looks like at this point:
2350 Return-Path:
2351 Received: from mail-ob0-f188.google.com (mail-ob0-f188.google.com
2352 [208.69.40.157]) by clothilde.example.com with ESMTP id
2353 d200mr22663000ykb.93.1421363268
2354 for ; Thu, 14 Jan 2015 15:03:15 -0800 (PST)
2355 Authentication-Results: clothilde.example.com; spf=fail
2356 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
2357 header.i=@gmail.com; dmarc=fail; arc=pass
2358 ARC-Seal: i=3; a=rsa-sha256; t=1421363253;
2359 s=notary01; d=gmail.com; cv=pass;
2360 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDW
2361 RYbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/s
2362 uttxO+RRNr0fCFw==
2363 ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed;
2364 d=gmail.com; s=20120806;
2365 h=mime-version:content-type:x-original-sender
2366 :x-original-authentication-results:precedence
2367 :mailing-list:list-id:list-post:list-help:list-archive:sender
2368 :list-unsubscribe:reply-to;
2369 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=;
2370 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
2371 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
2372 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBm
2373 fhSLF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJ
2374 RFeMKdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwD
2375 BJtXwbQoZyRtb6X6q0mYaszUB8kw==
2376 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10
2377 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST)
2378 Authentication-Results: i=3; gmail.com; spf=fail
2379 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
2380 header.i=@example.org; dmarc=fail; arc=pass
2381 ARC-Seal: i=2; a=rsa-sha256; t=1421363107;
2382 s=seal2015; d=example.org; cv=pass;
2383 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
2384 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
2385 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
2386 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed;
2387 d=example.org; s=clochette; t=1421363105;
2388 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
2389 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
2390 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
2391 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1
2392 F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+
2393 m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
2394 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
2395 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
2396 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
2397 (envelope-from jqd@d1.example)
2398 ARC-Authentication-Results: i=2; lists.example.org;
2399 spf=pass smtp.mfrom=jqd@d1.example;
2400 dkim=pass (1024-bit key) header.i=@d1.example;
2401 dmarc=pass
2402 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
2403 (authenticated bits=0)
2404 by segv.d1.example with ESMTP id t0FN4a8O084569;
2405 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
2406 (envelope-from jqd@d1.example)
2407 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
2408 s=origin2015; d=d1.example; cv=none;
2409 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
2410 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
2411 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
2412 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
2413 d=d1.example; s=20130426; t=1421363082;
2414 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
2415 h=MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding;
2416 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
2417 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
2418 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
2419 Message-ID: <54B84785.1060301@d1.example>
2420 Date: Thu, 14 Jan 2015 15:00:01 -0800
2421 From: John Q Doe
2422 To: arc@example.org
2423 Subject: [Lists] Example 1
2425 Hey gang,
2426 This is a test message.
2427 --J.
2429 Appendix C. Acknowledgements
2431 This draft is the work of OAR-Dev Group.
2433 The authors thank all of the OAR-Dev group for the ongoing help and
2434 though-provoking discussions from all the participants, especially:
2435 Alex Brotman, Brandon Long, Dave Crocker, Elizabeth Zwicky, Franck
2436 Martin, Greg Colburn, J. Trent Adams, John Rae-Grant, Mike Hammer,
2437 Mike Jones, Steve Jones, Terry Zink, Tim Draegen.
2439 Grateful appreciation is extended to the people who provided feedback
2440 through the discuss mailing list.
2442 Appendix D. Comments and Feedback
2444 Please address all comments, discussions, and questions to
2445 dmarc@ietf.org [17]. Earlier discussions can be found at arc-
2446 discuss@dmarc.org [18].
2448 Authors' Addresses
2450 Kurt Andersen
2451 LinkedIn
2452 1000 West Maude Ave
2453 Sunnyvale, California 94085
2454 USA
2456 Email: kurta@linkedin.com
2458 Brandon Long (editor)
2459 Google
2461 Email: blong@google.com
2463 Steven Jones (editor)
2464 TDP
2466 Email: smj@crash.com
2468 Seth Blank (editor)
2469 ValiMail
2471 Email: seth@valimail.com
2473 Murray Kucherawy (editor)
2474 TDP
2476 Email: superuser@gmail.com