idnits 2.17.1
draft-ietf-dmarc-arc-protocol-14.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 8 characters 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).
-- The document date (April 23, 2018) is 2194 days in the past. Is this
intentional?
Checking references for intended status: Experimental
----------------------------------------------------------------------------
-- Looks like a reference, but probably isn't: '1' on line 1405
-- Looks like a reference, but probably isn't: '2' on line 1407
== Missing Reference: 'I-D.ARC' is mentioned on line 1238, but not defined
-- Looks like a reference, but probably isn't: '3' on line 1409
-- Looks like a reference, but probably isn't: '4' on line 1411
-- Looks like a reference, but probably isn't: '5' on line 1413
-- Looks like a reference, but probably isn't: '6' on line 1455
-- Looks like a reference, but probably isn't: '7' on line 2292
-- Looks like a reference, but probably isn't: '8' on line 2293
== Unused Reference: 'RFC5322' is defined on line 1312, but no explicit
reference was found in the text
** 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 (~~), 9 warnings (==), 12 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: October 25, 2018 Google
6 S. Jones, Ed.
7 TDP
8 S. Blank, Ed.
9 Valimail
10 M. Kucherawy, Ed.
11 TDP
12 April 23, 2018
14 Authenticated Received Chain (ARC) Protocol
15 draft-ietf-dmarc-arc-protocol-14
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 October 25, 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. General Concepts . . . . . . . . . . . . . . . . . . . . 5
65 1.2. Differences Between ARC and DKIM . . . . . . . . . . . . 5
66 1.3. Definitions and Terminology . . . . . . . . . . . . . . . 6
67 1.3.1. Terms defined and used in this document . . . . . . . 6
68 1.3.2. Referenced Definitions . . . . . . . . . . . . . . . 7
69 2. Protocol Elements and Features . . . . . . . . . . . . . . . 7
70 2.1. The "ARC Set" of Header Fields . . . . . . . . . . . . . 8
71 2.1.1. Instance Tags . . . . . . . . . . . . . . . . . . . . 9
72 2.2. Chain Validation Status . . . . . . . . . . . . . . . . . 9
73 2.3. Trace Information . . . . . . . . . . . . . . . . . . . . 9
74 2.4. Key Management . . . . . . . . . . . . . . . . . . . . . 9
75 2.5. All Failures are Permanent . . . . . . . . . . . . . . . 10
76 2.6. Chain of Custody . . . . . . . . . . . . . . . . . . . . 10
77 2.7. Optional Participation . . . . . . . . . . . . . . . . . 10
78 2.8. Broad Responsibility to Seal . . . . . . . . . . . . . . 10
79 2.9. One Chain to Rule Them All . . . . . . . . . . . . . . . 11
80 2.10. Sealing is Always Safe . . . . . . . . . . . . . . . . . 11
81 3. The ARC Header Fields . . . . . . . . . . . . . . . . . . . . 11
82 3.1. Instance ('i=') Tag . . . . . . . . . . . . . . . . . . . 11
83 3.2. ARC-Authentication-Results (AAR) . . . . . . . . . . . . 12
84 3.3. ARC-Message-Signature (AMS) . . . . . . . . . . . . . . . 12
85 3.4. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . . . 13
86 3.4.1. Covered Header Fields . . . . . . . . . . . . . . . . 13
87 3.4.2. The 'cv' Tag . . . . . . . . . . . . . . . . . . . . 14
88 4. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . 14
89 4.1. Authentication-Results Information . . . . . . . . . . . 15
90 4.2. Handling DNS Problems While Validating ARC . . . . . . . 16
91 4.3. Responding to ARC Validity Violations During the SMTP
92 Transaction . . . . . . . . . . . . . . . . . . . . . . . 16
93 5. Sealer Actions . . . . . . . . . . . . . . . . . . . . . . . 16
94 5.1. Marking and Sealing "cv=fail" (Invalid) Chains . . . . . 17
95 6. Recording and Reporting the Results of ARC Evaluation . . . . 17
96 6.1. Information from an ARC Evaluation . . . . . . . . . . . 17
97 6.2. Recording (local) ARC Evaluation Results . . . . . . . . 17
98 6.3. DMARC Reporting of ARC Findings - Interim . . . . . . . . 18
99 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18
100 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
101 8.1. Authentication-Results Method Registry Update . . . . . . 19
102 8.2. Email Authentication Result Names Registry Update . . . . 19
103 8.3. Definitions of the ARC header fields . . . . . . . . . . 19
104 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
105 9.1. Header Size . . . . . . . . . . . . . . . . . . . . . . . 20
106 9.2. DNS Operations . . . . . . . . . . . . . . . . . . . . . 20
107 9.3. Message Content Suspicion . . . . . . . . . . . . . . . . 21
108 10. Evaluating the Efficacy of the ARC Protocol (Experimental
109 Considerations) . . . . . . . . . . . . . . . . . . . . . . . 21
110 10.1. Success Consideration . . . . . . . . . . . . . . . . . 21
111 10.2. Failure Considerations . . . . . . . . . . . . . . . . . 22
112 10.3. Open Questions . . . . . . . . . . . . . . . . . . . . . 22
113 10.3.1. Value of the ARC-Seal (AS) Header . . . . . . . . . 22
114 10.3.2. DNS Overhead . . . . . . . . . . . . . . . . . . . . 22
115 10.3.3. Distinguishing Valuable from Worthless Trace
116 Information . . . . . . . . . . . . . . . . . . . . 22
117 11. Implementation Status . . . . . . . . . . . . . . . . . . . . 23
118 11.1. GMail test reflector and incoming validation . . . . . . 24
119 11.2. AOL test reflector and internal tagging . . . . . . . . 24
120 11.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 24
121 11.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . 25
122 11.5. Mailman 3.2 patch . . . . . . . . . . . . . . . . . . . 25
123 11.6. Copernica/MailerQ web-based validation . . . . . . . . . 25
124 11.7. Rspamd . . . . . . . . . . . . . . . . . . . . . . . . . 26
125 11.8. PERL MAIL::DKIM module . . . . . . . . . . . . . . . . . 26
126 11.9. PERL Mail::Milter::Authentication module . . . . . . . . 27
127 11.10. Sympa List Manager . . . . . . . . . . . . . . . . . . . 27
128 11.11. Oracle Messaging Server . . . . . . . . . . . . . . . . 27
129 11.12. MessageSystems Momentum and PowerMTA platforms . . . . . 28
130 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
131 12.1. Normative References . . . . . . . . . . . . . . . . . . 28
132 12.2. Informative References . . . . . . . . . . . . . . . . . 29
133 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 30
134 Appendix A. Appendix A - Design Requirements . . . . . . . . . . 31
135 A.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 31
136 A.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 31
137 Appendix B. Appendix B - Example Usage . . . . . . . . . . . . . 31
138 B.1. Example 1: Simple mailing list . . . . . . . . . . . . . 31
139 B.1.1. Here's the message as it exits the Origin: . . . . . 31
140 B.1.2. Message is then received at example.org . . . . . . . 32
141 B.1.3. Example 1: Message received by Recipient . . . . . . 34
143 B.2. Example 2: Mailing list to forwarded mailbox . . . . . . 35
144 B.2.1. Here's the message as it exits the Origin: . . . . . 35
145 B.2.2. Message is then received at example.org . . . . . . . 36
146 B.2.3. Example 2: Message received by Recipient . . . . . . 40
147 B.3. Example 3: Mailing list to forwarded mailbox with source 42
148 B.3.1. Here's the message as it exits the Origin: . . . . . 42
149 B.3.2. Message is then received at example.org . . . . . . . 43
150 B.3.3. Example 3: Message received by Recipient . . . . . . 48
151 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 50
152 Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 51
153 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
155 1. Introduction
157 Modern email authentication techniques such as the Sender Policy
158 Framework (SPF) [RFC7208] and DomainKeys Identified Mail (DKIM)
159 [RFC6376] have become common. However, their end-to-end utility is
160 limited by the effects of intermediaries along the transmission path,
161 which either are not listed (for SPF) or which break digital
162 signatures (for DKIM). These issues are described in substantial
163 detail in those protocols' defining documents as well as in [RFC6377]
164 and [RFC7960].
166 Technologies that build upon the use of SPF and DKIM can reduce the
167 success of fraudulent email campaigns. To this end, Domain-based
168 Mail Authentication, Reporting and Conformance (DMARC) [RFC7489],
169 validates the domain of the RFC5322.From header field. However its
170 use along email transmission paths that have independent
171 intermediaries, such as some forwarders and essentially all mailing
172 list services, produces false positive rejections that are
173 problematic, both for the message authors, the intermediary
174 service(s), and for those they are interacting with.
176 [RFC7960] documented the need for a mechanism which would survive
177 legitimate alteration of a message, in spite of breaking the
178 associated SPF and DKIM information so that the end receiver
179 system(s) can avoid those false positive rejections on delivery.
180 Authenticated Received Chain (ARC) builds upon DKIM mechanisms to
181 provide a sequence of signatures that provide a view of the handling
182 sequence for a message, especially the points where alterations of
183 the content might have occurred. Equipped with this more complete
184 information, the recipient system(s) can make a more informed
185 handling choice, reducing or eliminating the rejections that would
186 occur with the use of DKIM and/or SPF alone.
188 1.1. General Concepts
190 ARC provides a "chain of custody" for a message, allowing each entity
191 that handles the message to see what entities handled it before, and
192 to see what the authentication status of the message was at each step
193 in the handling. The handling entity can then put its own entry into
194 the chain of custody and then relay the message to the next handler.
196 When the message reaches final delivery, the decision to accept and
197 deliver the message, or, alternatively, to reject, discard, or
198 quarantine it, can take the chain of custody into account, applying
199 local policy in addition to policies advertised by the (purported)
200 sending domain. Consider, for example, this scenario:
202 1. A sender from mysender.example posts a message to a mailing list
203 hosted at listmania.example;
205 2. The mailing list modifies the message by prepending the list name
206 to the subject line, then sends it to the subscribers;
208 3. One of the subscribers is alice@mail.service.example, which
209 receives the message from listmania.example.
211 Assuming the original message was DKIM-signed and mysender.example
212 published an SPF record, the handling by the mailing list will break
213 the DKIM signature because of the message modification, and the
214 forwarding will cause the SPF check to fail in the next step. But
215 listmania.example can add ARC headers to the message to add itself to
216 the document's chain of custody. When mail.service.example sees the
217 message, it can see that SPF and DKIM validation fail, but it can
218 also see that both of these succeeded when they were checked by
219 listmania.example, and can verify listmania's assertion.
221 As part of its evaluation of the message for delivery,
222 mail.service.example can see that mysender.example publishes a DMARC
223 policy asking that unauthenticated messages be rejected. But is can
224 also see the assertion by listmania.example that the message was
225 correctly authenticated when the message arrived there, and if it
226 accepts that assertion, it can accept the message for further
227 processing, rather than reject it, based on the additional
228 information that ARC has provided.
230 1.2. Differences Between ARC and DKIM
232 In DKIM, every participating signing agent attaches a signature that
233 is based on some of the content of the message, local policy, and the
234 domain name of the signing agent's Administrative Management Domain
235 (ADMD). Any verifier can process such a signature; a verified
236 signature means that the domain referenced in the signature's "d="
237 parameter has some responsibility for handling the message. An
238 artifact of using digital signature technology for this means that
239 verification also ensures that the portion of the message that was
240 "covered" by the signature has not been altered since the signature
241 was applied. The signatures themselves are generally independent of
242 one another.
244 In contrast, a validated ARC Set conveys the following pieces of
245 information:
247 1. An assertion that, at the time that the intermediary ADMD
248 processed the message, the various assertions (such as SPF, DKIM-
249 Signature(s) and/or ARC Chain) already attached to the message by
250 other ADMDs were or were not valid;
252 2. As with DKIM, an assertion that, for a validated ARC signature,
253 the domain name in the signature takes some responsibility for
254 handling of the message and that the covered content of the
255 message is unchanged since that signature was applied;
257 3. A further assertion that binds the ARC evaluation results into
258 the ARC Chain sequence.
260 1.3. Definitions and Terminology
262 This section defines terms used in the rest of the document.
264 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
265 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
266 "OPTIONAL" in this document are to be interpreted as described in
267 BCP14 ([RFC2119][RFC8174]).
269 Because many of the core concepts and definitions are found in
270 [RFC5598], readers should to be familiar with the contents of
271 [RFC5598], and in particular, the potential roles of intermediaries
272 in the delivery of email.
274 Syntax descriptions use Augmented BNF (ABNF) [RFC5234].
276 1.3.1. Terms defined and used in this document
278 o "ARC-Authentication-Results" (AAR) - an ARC header field described
279 in Section 3.2.
281 o "ARC-Message-Signature" (AMS) - an ARC header field described in
282 Section 3.3.
284 o "ARC-Seal" (AS) - an ARC header field described in Section 3.4.
286 o "ARC Set" - A single group of the header fields introduced in
287 Section 2.1 is called an "ARC Set".
289 o "ARC Chain" - the complete sequence of ARC Sets for a message.
290 The ARC Chain represents a "chain of custody" for the message,
291 recording its authentication status at each ARC-participating ADMD
292 that handled the message.
294 1.3.2. Referenced Definitions
296 The following terms are defined in other RFCs. Those definitions can
297 be found as follows:
299 o ADMD - [RFC5598], Section 2.3
301 o MTA - [RFC5598], Section 4.3.2
303 o MSA - [RFC5598], Section 4.3.1
305 o MDA - [RFC5598], Section 4.3.3
307 The three header fields that are part of this specification borrow
308 heavily from existing specifications. Rather than repeating all of
309 the formal definitions that are being reused in ARC, this document
310 only describes and specifies changes in syntax and semantics.
312 Language, syntax, and other details are imported from DKIM [RFC6376].
313 Specific references can be found below.
315 2. Protocol Elements and Features
317 As with other domain authentication technologies (such as SPF, DKIM,
318 and DMARC), ARC makes no claims about the contents of the email
319 message it has sealed. However, for a valid and passing ARC Chain, a
320 Final Receiver is able to ascertain:
322 o all (participating) domains that claim responsibility for handling
323 (and possibly modifying) the email message in transit;
325 o trace information, including:
327 * the [RFC7601] Authentication-Results each participating ADMD
328 saw; and
330 * additional data needed to compile a DMARC report for the
331 sending domain.
333 Given this information, each receiver is able to make a more informed
334 local policy decision regarding message processing and, ultimately,
335 delivery to the end user in spite of authentication failure(s) and to
336 inform the message orgination system(s) through the DMARC report(s).
338 Every participant in an ARC Chain, except for the originating sender
339 and Final Receiver, is both an ARC Validator (when receiving) and
340 then an ARC Sealer (when sending a message onward).
342 _INFORMATIONAL_: It is important to understand that validating and
343 then immediately sealing a message leaves no room for message
344 modification, and many early implementations of ARC did not initially
345 work because both operations were performed in a single pass over the
346 message.
348 The following protocol features are functional parts and design
349 decisions related the protocol that are not specific to either
350 Validators or Sealers, but ensure that the ARC Chain conveys this
351 information to a Final Receiver.
353 2.1. The "ARC Set" of Header Fields
355 Each "ARC Set" consists of the following three new header fields:
357 1. ARC-Authentication-Results (referred to below as "AAR"):
358 virtually identical in syntax to an Authentication-Results field
359 [RFC7601], this field records the results of all message
360 authentication checks done by the recording ADMD at the time the
361 message arrived. Additional information is placed in this field
362 compared to a standard Authentication-Results field in order to
363 support a more complete DMARC report;
365 2. ARC-Message-Signature (referred to below as "AMS"): virtually
366 identical in syntax to DKIM-Signature, this field contains the
367 signature about the message header and body as they existed at
368 the time of handling by the ADMD adding it (including any
369 modifications made by the sealing ADMD); and
371 3. ARC-Seal (referred to below as "AS"): highly similar in structure
372 and format to a DKIM-Signature, this field applies a digital
373 signature that protects the integrity of all three of these new
374 fields when they are added by an ADMD, plus all instances of
375 these fields added by prior ADMDs.
377 An ARC participant always adds all of these header fields before
378 relaying a message to the next handling agent _en route_ to its
379 destination. Moreover, they each have an "instance number" that
380 increases with each ARC Set in the handling chain so that their
381 original order can be preserved and the three related header fields
382 can be processed as a set.
384 2.1.1. Instance Tags
386 ARC includes an indicator in its header fields to show the order in
387 which the header fields comprising an ARC Chain were added, and the
388 specific members of each ARC Set. This is known as the "instance",
389 and the indicator is an "i=" tag/value. That is, the members of the
390 first ARC Set affixed to a message will all include "i=1". This is
391 described in detail in section Section 3.1.
393 2.2. Chain Validation Status
395 ARC includes a mechanism which denotes the state of the ARC Chain at
396 each step. The "chain validation status" ("cv" tag/value) is used to
397 communicate the current chain status within the ARC Chain and also
398 through Authentication-Results and ARC-Authentication-Results stamps
399 as well as DMARC reporting.
401 The chain validation status has one of three possible values:
403 o none: There was no chain on the message when it arrived for
404 validation; typically occurs when the message arrives at a Message
405 Transfer Agent (MTA) or mediator from a Message Submission Agent
406 (MSA) or when any upstream handlers may not be participating in
407 ARC handling;
409 o fail: The message has a chain whose validation failed;
411 o pass: The message has a chain whose validation succeeded.
413 2.3. Trace Information
415 ARC includes trace information encoded in the AAR. While section
416 Section 3.2 defines what information must be provided, sealing ADMDs
417 may provide additional information, and validating receivers may use
418 this trace information as they find it useful.
420 2.4. Key Management
422 The public keys for ARC header fields follow the same requirements,
423 syntax and semantics as those for DKIM signatures, described in
424 Section 3.6 of [RFC6376]. ARC places no requirements on the
425 selectors and/or domains used for the ARC header field signatures.
427 2.5. All Failures are Permanent
429 Because ARC Chains are transmitted across multiple intermediaries,
430 all errors, even temporary ones, become unrecoverable and are
431 considered permanent.
433 Any error validating or sealing a chain, for whatever reason, MUST
434 result in a "cv=fail" verdict as documented in Section 3.4.2.
436 2.6. Chain of Custody
438 At a high level, an ARC Chain represents a chain of custody of
439 authentication and other trace information (AAR) related to a
440 message, signed by each handler of the message. Each link in the
441 chain (AMS) is designed to be brittle, insofar as it survives only
442 until the next modification of the message. However, the sequence of
443 intermediaries in the handling chain (AS) is designed to remain
444 intact over the entirety of the chain.
446 The ARC Chain can be conceptualized through an analogy with the chain
447 of custody for legal evidence. The material evidence itself is
448 sealed within an tamper-proof bag (AMS) each time. When handed to a
449 new party, that party both vouches for the state of the received
450 evidence container (AAR) and signs for the evidence on a chain of
451 custody report form (AS). As with all analogies, this one should not
452 be taken to interpretive extremes, but primarily used as a conceptual
453 framework.
455 An ARC Chain that is valid and passing has the attributes listed
456 above in Section 2.
458 2.7. Optional Participation
460 Validating an existing chain and then adding your own ARC Set to a
461 message allows you to claim responsibility for handling the message
462 and modifications, if any, done by your ADMD to benefit message
463 delivery downstream. However, no ADMD is obligated to perform these
464 actions.
466 2.8. Broad Responsibility to Seal
468 Any mediator ([RFC5598], section 5) that modifies a message may seal
469 its own changes. ARC is not solely intended for perimeter MTAs.
471 2.9. One Chain to Rule Them All
473 A message can have only one ARC Chain on it at a time (see
474 Section 3.1). Once broken, the chain cannot be continued, as the
475 chain of custody is no longer valid and responsibility for the
476 message has been lost. For further discussion of this topic and the
477 designed restriction which prevents chain continuation or re-
478 establishment, see [ARC-USAGE].
480 2.10. Sealing is Always Safe
482 Even when an ARC Chain is valid and passes, its value is limited to
483 very specific cases. An ARC Chain is specifically designed to
484 provide additional information to a receiver evaluating message
485 delivery in the context of an authentication failure and otherwise be
486 benign. Specifically:
488 o properly adding an ARC Set to a message does not damage or
489 invalidate an existing chain,
491 o sealing a chain when you did not modify a message does not
492 negatively affect the chain, and
494 o validating a message exposes no new threat vectors (see
495 Section 9).
497 _INFORMATIONAL_: If an ADMD is unsure whether it will be re-emitting
498 and/or modifying a message, it may elect to seal all inbound mail.
499 For complex or nested ADMD relationships such as found in some hosted
500 mail solutions, this "inbound seal" can be used to facilitate
501 traversal of internal boundaries as well as properly conveying
502 incoming state to any egress MTAs that may need to assert a seal upon
503 exit from the ADMD. Since these internal relationships are highly
504 implementation dependent, this protocol definition can not usefully
505 explore such usage except to note that it is intentionally allowed
506 within the scope of this specification.
508 3. The ARC Header Fields
510 3.1. Instance ('i=') Tag
512 The header fields comprising a single ARC Set are identified by a
513 common "instance" tag value. The instance tag is a string in each
514 header field value that complies with the "tag-spec" ABNF found in
515 Section 3.2 of [RFC6376]. The tag-name is "i" and the value is the
516 text representation of a positive integer, indicating the position in
517 the ARC sequence this set occupies, where the first ARC Set is
518 numbered 1. In ABNF terms:
520 position = 1*2DIGIT ; 1 - 50
521 instance = [FWS] %x69 [FWS] "=" [FWS] position [FWS] ";"
523 Valid ARC Sets MUST have exactly one instance of each header field
524 (of three) for a given instance value and signing algorithm.
526 (_INFORMATIONAL:_ Initial development of ARC is only being done with
527 a single allowed signing algorithm, but parallel work in the DCRUP
528 working group [1] is expanding that. For handling multiple signing
529 algorithms, see [ARC-MULTI].)
531 The 'i' tag value can range from 1-50 (inclusive).
533 ARC Chains longer than the defined maximum count MUST be marked as
534 failed.
536 _INFORMATIONAL_: Because the AMS and AS header field values are made
537 up of tag-spec constructs, the i= tag may be found anywhere within
538 the header field value, but is represented throughout this spec in
539 the initial position for convenience. Implementers are encouraged to
540 place the i= tag at the beginning of the field value to facilitate
541 human inspection of the headers.
543 3.2. ARC-Authentication-Results (AAR)
545 The ARC-Authentication-Results header field is syntactically and
546 semantically identical, except for the header field name itself and
547 its instance tag, to an Authentication-Results header field (defined
548 in Section 2.2 of [I-D-7601bis]).
550 Formally, the header field is specified as follows using ABNF
551 [RFC5234]:
553 arc-info = instance [CFWS] ";" authres-payload
554 arc-authres-header = "ARC-Authentication-Results:" [CFWS] arc-info
556 The AAR MUST contain all Authentication-Results from within the
557 participating ADMD, regardless of how many Authentication-Results
558 headers are on the message.
560 3.3. ARC-Message-Signature (AMS)
562 The ARC-Message-Signature header field is simplified version of a
563 DKIM-Signature header field [RFC6376], with the following
564 modifications:
566 o There is an "i" tag, as described in Section 3.1.
568 o There is no "v" tag defined for the AMS header. As required for
569 undefined tags (in [RFC6376]), if seen, it MUST be ignored.
571 ARC-related header fields (ARC-Seal, ARC-Message-Signture, ARC-
572 Authentication-Results) MUST NOT be included in the content covered
573 by the signature in the signature in this header field.
575 The AMS SHOULD include any DKIM-Signature header fields already
576 present on the message in the header fields covered by this
577 signature.
579 Authentication-Results header fields MUST NOT be included since they
580 are likely to be deleted by downstream ADMDs (per Section 5 of
581 [RFC7601]), thereby breaking the AMS signature.
583 3.4. ARC-Seal (AS)
585 The ARC-Seal header field is syntactically and semantically similar
586 to a DKIM-Signature field, with the following exceptions:
588 o There is an "i" tag, as described in Section 3.1.
590 o The ARC-Seal covers none of the body content of the message. It
591 only covers specific header fields as defined below:
592 Section 3.4.1. No body canonicalization is done.
594 o Only "relaxed" header canonicalization (Section 3.4.2 of
595 [RFC6376]) is used.
597 o The only supported tags are "i" (from Section 3.1 of this
598 document), and "a", "b", "d, "s", "t" from Section 3.5 of
599 [RFC6376].
601 o An additional tag, "cv" is defined in Section 3.4.2
603 3.4.1. Covered Header Fields
605 The ARC-Seal signs a specific canonicalized form of the ARC Set
606 header values. The ARC set header values are compiled in increasing
607 instance order, starting at 1, and include the set being added at the
608 time of sealing the message.
610 Within a set, the header fields are listed in the following order:
612 1. ARC-Authentication-Results
614 2. ARC-Message-Signature
615 3. ARC-Seal
617 Where the ARC-Seal is the one being generated, it is input to the
618 hash function in its final form except with an empty "b=" value, in
619 the same manner by which a DKIM-Signature signs itself ([RFC6376],
620 section 3.7).
622 Note that the signing scope for the ARC-Seal is modified in the
623 situation where a chain has failed validation (see Section 5.1).
625 3.4.2. The 'cv' Tag
627 A new tag "cv" (chain validation) indicates the outcome of evaluating
628 the existing ARC Chain upon arrival at the ADMD that is adding this
629 header field. The values are defined per Section Section 2.2.
631 In ABNF terms:
633 chain-status = ("none" / "fail" / "pass")
634 seal-cv-tag = %x63.76 [FWS] "=" [FWS] chain-status
636 4. Verifier Actions
638 A verifier takes the following steps to validate the ARC Chain.
639 Canonicalization, hash functions, and signature validation methods
640 are imported from Section 5 of [RFC6376].
642 1. Collect all ARC Sets currently on the message. If there were
643 none, the ARC state is "none" and the algorithm stops here.
645 2. Check the morphology of the ARC Chain. If any of these
646 conditions are not met, the chain state is "fail" and the
647 algorithm stops here:
649 1. Each ARC Set must be complete (e.g., contains exactly one of
650 each of the three ARC-specific header fields);
652 2. The instance values must form a continuous sequence from 1..N
653 with no gaps or repeats;
655 3. The cv value for all ARC-Seal(s) must be non-failing:
657 1. For i > 1, the value must be "pass";
659 2. For i = 1, the value must be "none".
661 3. For each ARC-Message-Signature from the "N"th instance to the
662 first, validate the AMS:
664 1. If the "N"th instance (most recent) signature fails, then the
665 chain state is "fail" and the algorithm stops here.
667 2. If one of the prior AMS signatures fails to validate (for
668 instance "M"), then set the oldest-pass value to the lowest
669 AMS instance number which passed (M+1) and go onto the next
670 step (there is no need to check any other (older) AMS
671 signatures). This does not affect the validity of the chain.
673 3. If all AMS signatures verify, set the oldest-pass value to
674 zero (0).
676 4. For each ARC-Seal from the "N"th instance to the first, validate
677 the seal.
679 1. If any seal is not valid, the chain state is "fail" and the
680 algorithm stops here.
682 2. If all seals pass validation, then the chain state is "pass",
683 and the algorithm is complete.
685 The end result of the verifier's checks via this algorithm MUST be
686 added into the Authentication-Results header(s) for the ADMD.
688 _INFORMATIONAL_: Recipients of an ARC Chain that is invalid or does
689 not pass SHOULD NOT draw negative conclusions without a good
690 understanding of the wider handling context. Until ARC usage is
691 widespread, intermediaries will continue to modify messages without
692 ARC seals.
694 As with a failing DKIM signature ([RFC6376] Section-6.3), a message
695 with a failing ARC Chain MUST be treated the same as a message with
696 no ARC Chain.
698 4.1. Authentication-Results Information
700 Certain information pertinent to ascertaining message disposition can
701 be lost in transit when messages are handled by intermediaries. For
702 example, failing DKIM signatures are sometimes removed by MTAs, and
703 most DKIM signatures on messages modified by intermediaries will
704 fail. Recording the following information in the Authentication-
705 Results stamped as part of the ARC evaluation provides a mechanism
706 for this information to survive transit through a particular ADMD.
708 Stamped ARC evaluation results is limited to the Chain Validation
709 status (cv) from Section 2.2.
711 The ptypes and properties defined in this section SHOULD be recorded
712 in the Authentication-Results:
714 o smtp.client-ip - The connecting client IP address from which the
715 message is received;
717 o header.oldest-pass - The instance number of the oldest AMS that
718 still validates, or 0 if all pass.
720 4.2. Handling DNS Problems While Validating ARC
722 DNS-based failures to verify a chain are treated no differently than
723 any other ARC violation. They result in a "cv=fail" verdict.
725 4.3. Responding to ARC Validity Violations During the SMTP Transaction
727 If a receiver determines that the ARC Chain has failed, the receiver
728 MAY signal the breakage through the extended SMTP response code 5.7.7
729 [RFC3463] "message integrity failure" [ENHANCED-STATUS] and
730 corresponding SMTP response code.
732 5. Sealer Actions
734 An ARC sealer MUST take the following actions when presented with a
735 message:
737 1. Before creating an ARC signature, perform any other, normal
738 authentication and/or signing, so that the ARC signature can
739 cover those results.
741 2. Build and attach the new ARC Set:
743 1. If an ARC Chain exists on the message, then set "N" equal to
744 the highest instance number found on the chain (i=);
745 otherwise set "N" equal to zero for the following steps.
747 2. Generate and attach to the message an ARC-Authentication-
748 Results header field as defined in Section Section 3.2, using
749 instance number N+1 and the same content from the previous
750 step.
752 3. Generate and attach to the message an ARC-Message-Signature
753 header field as defined in Section 3.3 above, using instance
754 number N+1.
756 4. Generate and attach to the message an ARC-Seal header field
757 using the general algorithm described in Section 3.4 above,
758 the chain validation status as determined in Section 4, and
759 instance number N+1.
761 5.1. Marking and Sealing "cv=fail" (Invalid) Chains
763 The header fields signed by the AS header field b= value in the case
764 of a chain failure MUST be only the matching instance headers created
765 by the MTA which detected the malformed chain, as if this newest ARC
766 Set was the only set present.
768 _INFORMATIONAL:_ In the case of a malformed or otherwise invalid
769 chain there is no way to generate a deterministic set of AS header
770 fields ({#implicit_as_h}) so this approach is mandated.
772 6. Recording and Reporting the Results of ARC Evaluation
774 The evaluation of an ARC Chain provides information which will be
775 useful to both the receiver (or intermediary) and to the initial
776 sender of the message. This information should be preserved and
777 reported as follows.
779 6.1. Information from an ARC Evaluation
781 The evaluation of an ARC Chain produces a list of domain names for
782 participating intermediaries which handled the message, to wit:
784 o A list of the "d=" domains found in the validated ARC-Seal header
785 fields
787 o The "d=" domain found in the most recent (highest instance number)
788 AMS header field (since that is the only one necessarily
789 validated)
791 In the case of a failed chain, only the terminal ARC Set is covered
792 by the ARC-Seal so the reporting is limited to the findings in that
793 terminal ARC Set.
795 6.2. Recording (local) ARC Evaluation Results
797 Receivers who process an attached ARC Chain SHOULD add an
798 "arc=[pass|fail|policy]" method annotation into a locally-affixed
799 Authentication-Results [RFC7601] header field along with any salient
800 comment(s).
802 Details of the ARC Chain which was evaluated should be included in
803 the Authentication-Results and AAR headers per Section Section 4.1.
805 6.3. DMARC Reporting of ARC Findings - Interim
807 Receivers SHOULD indicate situations in which ARC evaluation
808 influenced the results of their local policy determination. DMARC
809 reporting of ARC-informed decisions can be accomplished by adding a
810 local_policy comment explanation containing the list of data
811 discovered in the ARC evaluation, which at a minimum SHOULD include:
812 * the Chain Validation status, * the domain and selector for each AS,
813 * the IP addresses of the mail originating ADMD:
815
816 none
817 fail
818 fail
819
820 local_policy
821 arc=pass ams[2].d=d2.example ams[2].s=s1 as[2].d=d2.example
822 as[2].s=s2 as[1].d=d1.example as[1].s=s3 client-ip[1]=10.10.10.13
823
824
826 In the sample above, d2.example is the sealing domain for ARC[2] and
827 d1.example is the sealing domain for ARC[1].
829 Intermediary message handlers SHOULD generate DMARC reports on
830 messages which transit their system just like any other message which
831 they receive. This will result in multiple reports for each mediated
832 message as they transit the series of handlers. DMARC report
833 consumers should be aware of this behaviour and make the necessary
834 accommodations.
836 7. Privacy Considerations
838 The ARC Chain provides a verifiable record of the handlers for a
839 message. Anonymous remailers will probably not find this compatible
840 with their operating goals.
842 8. IANA Considerations
844 [[ Note to the RFC Editors: Some of these fields are defined both
845 here and in [I-D-7601bis]. Please delete the overlap from whichever
846 document goes through the publication process after the other. ]]
848 This specification adds three new header fields as defined below.
850 8.1. Authentication-Results Method Registry Update
852 This draft adds one item to the IANA "Email Authentication Methods"
853 registry:
855 o Method : arc
856 Defined: [I-D.ARC]
857 ptype: header
858 Property: chain evaluation result
859 Value: chain evaluation result status (see Section 3.4)
860 Status: active
862 8.2. Email Authentication Result Names Registry Update
864 This draft updates the Email Authentication Results registry, most
865 recently defined in [I-D-7601bis], with one new authentication method
866 and several status codes, all defined by this document:
868 o Auth Method : arc
869 Code: "none", "pass", "fail"
870 Specification: [I-D.ARC] Section 3.4.2 Status: active
872 o Method : spf
873 Defined: [I-D.ARC]
874 ptype: smtp
875 Property: client-ip
876 Value: the connecting client IP address from which the message is
877 received
878 Status: active
880 o Method : arc
881 Defined: [I-D.ARC]
882 ptype: header
883 Property: oldest-pass
884 Value: the oldest instance with a still validating AMS signature
885 Status: active
887 8.3. Definitions of the ARC header fields
889 This specification adds three new header fields to the "Permanent
890 Message Header Field Registry", as follows:
892 o Header field name: ARC-Seal
893 Applicable protocol: mail
894 Status: draft
895 Author/Change controller: IETF
896 Specification document(s): [I-D.ARC]
897 Related information: [RFC6376]
899 o Header field name: ARC-Message-Signature
900 Applicable protocol: mail
901 Status: draft
902 Author/Change controller: IETF
903 Specification document(s): [I-D.ARC]
904 Related information: [RFC6376]
906 o Header field name: ARC-Authentication-Results
907 Applicable protocol: mail
908 Status: standard
909 Author/Change controller: IETF
910 Specification document(s): [I-D.ARC]
911 Related information: [RFC7601]
913 9. Security Considerations
915 The Security Considerations of [RFC6376] and [RFC7601] apply directly
916 to this specification.
918 9.1. Header Size
920 Inclusion of ARC Sets in the header of emails may cause problems for
921 some older or more constrained MTAs if they are unable to accept the
922 greater size of the header.
924 9.2. DNS Operations
926 Operators who receive a message bearing N ARC Sets have to complete
927 up to N+1 DNS queries to evaluate the chain (barring DNS redirection
928 mechanisms which can increase the lookups for a given target value).
929 This has at least two effects:
931 1. An attacker can send a message to an ARC participant with a
932 concocted sequence of ARC Sets bearing the domains of intended
933 victims, and all of them will be queried by the participant until
934 a failure is discovered. The difficulty of forging the signature
935 values should limit the extent of this load to domains under
936 control of the attacker.
938 2. DKIM only does one DNS check per signature, while this one can do
939 many (per chain). Absent caching, slow DNS responses can cause
940 SMTP timeouts; and backlogged delivery queues on mediating
941 systems. This could be exploited as a DoS attack.
943 9.3. Message Content Suspicion
945 Recipients are cautioned to treat messages bearing ARC Sets with the
946 same suspicion that they apply to all other email messages. This
947 includes appropriate content scanning and other checks for
948 potentially malicious content. The handlers which are identified
949 within the ARC Chain may be used to provide input to local policy
950 engines in cases where DMARC validation fails (due to mediation
951 impacting SPF attribution, DKIM validity or alignment).
953 Note that a passing ARC Chain may not adequately mean that the
954 message is safe because:
956 1. You have to trust all signatories; and
958 2. Even trusted systems may have become compromised or may not
959 properly authenticate messages, so even with a chain of trusted
960 participants, the message might still never have authenticated in
961 the first place (which is why you have the AAR to inspect) or
962 could have been subject to unintended modifications.
964 10. Evaluating the Efficacy of the ARC Protocol (Experimental
965 Considerations)
967 The ARC protocol is designed to mitigate some of the most common
968 failure conditions for email which transits intermediary handlers en
969 route to the final recipient. Some of these problems have happened
970 due to the adoption of the DMARC protocol [RFC7489] and are listed in
971 [RFC6377] and [RFC7960].
973 As the ARC protocol becomes standardized and implemented amongst
974 intermediary handlers, the following aspects should be evaluated in
975 order to determine the success of the protocol in accomplishing the
976 intended benefits.
978 NOTE: Terminology within this section does NOT follow [RFC2119]
979 interpretation. This section represents the current thoughts of the
980 working group regarding unanswered questions related to the protocol.
981 Wider deployment will inform these topics and probably expand them.
983 10.1. Success Consideration
985 Currently, many receivers have heuristically determined overrides in
986 order to rescue mail from intermediary-caused failures. Many of
987 those overrides rely on inferrence rather than direct evidence.
989 ARC will be a success if, for ARC sealed messages, receivers are able
990 to implment ARC-based algorithmic decisions based on the direct
991 evidence found within the ARC Chain. This is especially relevant for
992 DMARC processing when the DKIM d= value is aligned with the
993 rfc5322.From author domain.
995 10.2. Failure Considerations
997 The intent of ARC is to be at most value-add and at worst benign. If
998 ARC opens up significant new vectors for abuse (see Section 9) then
999 this protocol will be a failure. Note that weaknesses inherent in
1000 the mail protocols ARC is built upon (such as DKIM replay attacks and
1001 other known issues) are not new vectors which can be attributed to
1002 this specification.
1004 10.3. Open Questions
1006 The following open questions are academic and have no clear answer at
1007 the time of the development of the protocol. However, wide-spread
1008 deployment should be able to gather the necessary data to answer some
1009 or all of them.
1011 10.3.1. Value of the ARC-Seal (AS) Header
1013 Data should be collected to show if the ARC-Seal (AS) provides value
1014 beyond the ARC Message Signature (AMS) for either making delivery
1015 decisions or catching malicious actors trying to craft or replay
1016 malicious chains.
1018 10.3.2. DNS Overhead
1020 Longer ARC Chains will require more queries to retrieve the keys for
1021 validating the chain. While this is not believed to be a security
1022 issue (see Section 9.2), it is unclear how much overhead will truly
1023 be added. This is similar to some of the initial processing and
1024 query load concerns which were debated at the time of the DKIM
1025 specification development.
1027 Data should be collected to better understand usable length and
1028 distribution of lengths found in valid ARC Chains along with the the
1029 DNS impact of processing ARC Chains.
1031 An effective operational maximum will have to be developed through
1032 deployment experience in the field.
1034 10.3.3. Distinguishing Valuable from Worthless Trace Information
1036 There are several edge cases where the information in the AAR can
1037 make the difference between message delivery or rejection. For
1038 example, if there is a well known mailing list that ARC seals but
1039 doesn't do its own initial DMARC enforcement, a Final Receiver with
1040 this knowledge could make a delivery decision based upon the
1041 authentication information it sees in the corresponding AAR header.
1043 Certain trace information in the AAR is useful/necessary in the
1044 construction of DMARC reports. It would be beneficial to identify
1045 the value-add of having intermediary-handled mail flow information
1046 added into the DMARC reports going back to senders.
1048 Certain receivers believe the entire set of trace information would
1049 be valuable to feed into machine learning systems to identify fraud
1050 and/or provide other signals related to message delivery.
1052 It is unclear what trace information will be valuable for all
1053 receivers, regardless of size.
1055 Data should be collected on what trace information receivers are
1056 using that provides useful signals that affect deliverability, and
1057 what portions of the trace data are left untouched or provide no
1058 useful information.
1060 Since many such systems are intentionally proprietary or confidential
1061 to prevent gaming by abusers, it may not be viable to reliably answer
1062 this particular question. The evolving nature of attacks can also
1063 shift the landscape of "useful" information over time.
1065 11. Implementation Status
1067 [[ Note to the RFC Editor: Please remove this section before
1068 publication along with the reference to [RFC6982]. ]]
1070 This section records the status of known implementations of the
1071 protocol defined by this specification at the time of posting of this
1072 Internet-Draft, and is based on a proposal described in [RFC6982].
1073 The description of implementations in this section is intended to
1074 assist the IETF in its decision processes in progressing drafts to
1075 RFCs. Please note that the listing of any individual implementation
1076 here does not imply endorsement by the IETF. Furthermore, no effort
1077 has been spent to verify the information presented here that was
1078 supplied by IETF contributors. This is not intended as, and must not
1079 be construed to be, a catalog of available implementations or their
1080 features. Readers are advised to note that other implementations may
1081 exist.
1083 This information is known to be correct as of the seventh
1084 interoperability test event which was held on 2017-07-15 & 16 at
1085 IETF99.
1087 For a few of the implementations, later status information was
1088 available as of December 2017.
1090 11.1. GMail test reflector and incoming validation
1092 Organization: Google
1093 Description: Internal production implementation with both debug
1094 analysis and validating + sealing pass-through function
1095 Status of Operation: Production - Incoming Validation
1096 Coverage: Full spec implemented as of [ARC-DRAFT-06]
1097 Licensing: Proprietary - Internal only
1098 Implementation Notes:
1100 o Full functionality was demonstrated during the interop testing on
1101 2017-07-15.
1103 Contact Info: arc-discuss@dmarc.org [2]
1105 11.2. AOL test reflector and internal tagging
1107 Organization: AOL
1108 Description: Internal prototype implementation with both debug
1109 analysis and validating + sealing pass-through function
1110 Status of Operation: Beta
1111 Coverage: ARC Chain validity status checking is operational, but only
1112 applied to email addresses enrolled in the test program.
1113 This system conforms to [ARC-DRAFT-06]
1114 Licensing: Proprietary - Internal only
1115 Implementation Notes:
1117 o 2017-07-15: Full functionality verified during the interop
1118 testing.
1120 Contact Info: arc-discuss@dmarc.org [3]
1122 11.3. dkimpy
1124 Organization: dkimpy developers/Scott Kitterman
1125 Description: Python DKIM package
1126 Status of Operation: Production
1127 Coverage:
1129 o 2017-07-15: The internal test suite is incomplete, but the command
1130 line developmental version of validator was demonstrated to
1131 interoperate with the Google and AOL implementations during the
1132 interop on 2017-07-15 and the released version passes the tests in
1133 [ARC-TEST] arc_test_suite [4] with both python and python3.
1135 Licensing: Open/Other (same as dkimpy package = BCD version 2)
1136 Contact Info: https://launchpad.net/dkimpy
1138 11.4. OpenARC
1140 Organization: TDP/Murray Kucherawy
1141 Description: Implemention of milter functionality related to the
1142 OpenDKIM and OpenDMARC packages
1143 Status of Operation: Beta
1144 Coverage: Built to support [ARC-DRAFT-10]
1145 Licensing: Open/Other (same as OpenDKIM and OpenDMARC packages)
1146 Implementation Notes:
1148 o The build is FreeBSD oriented but some packages have been built
1149 for easier deployment on RedHat-based Linux platforms.
1151 o Some issues still exist when deploying in a chained milter
1152 arrangement (such as OpenSPF -> OpenDKIM -> OpenDMARC -> OpenARC)
1153 with coordination between the stages. When deployed in a
1154 "sandwich" configuration around an MLM, there is no effective
1155 mechanism to convey trust from the ingress (validator) to egress
1156 (signer) instances. (_NOTE_: this is expected to resolved with a
1157 new release of OpenDMARC expected in January 2018.)
1159 Contact Info: arc-discuss@dmarc.org [5]
1161 11.5. Mailman 3.2 patch
1163 Organization: Mailman development team
1164 Description: Integrated ARC capabilities within the Mailman 3.2
1165 package
1166 Status of Operation: Patch submitted
1167 Coverage: Based on OpenARC
1168 Licensing: Same as mailman package - GPL
1169 Implementation Notes:
1171 o Appears to work properly in at least one beta deployment, but
1172 waiting on acceptance of the pull request into the mainline of
1173 mailman development
1175 Contact Info: https://www.gnu.org/software/mailman/contact.html
1177 11.6. Copernica/MailerQ web-based validation
1179 Organization: Copernica
1180 Description: Web-based validation of ARC-signed messages
1181 Status of Operation: Beta
1182 Coverage: Built to support [ARC-DRAFT-05]
1183 Licensing: On-line usage only
1184 Implementation Notes:
1186 o Released 2016-10-24
1188 o Requires full message content to be pasted into a web form found
1189 at http://arc.mailerq.com/ (warning - https is not supported).
1191 o An additional instance of an ARC signature can be added if one is
1192 willing to paste a private key into an unsecured web form.
1194 o 2017-07-15: Testing shows that results match the other
1195 implementations listed in this section.
1197 Contact Info: https://www.copernica.com/
1199 11.7. Rspamd
1201 Organization: Rspamd community
1202 Description: ARC signing and verification module
1203 Status of Operation: Production, though deployment usage is unknown
1204 Coverage: Built to support [ARC-DRAFT-06]
1205 Licensing: Open source
1206 Implementation Notes:
1208 o 2017-06-12: Released with version 1.6.0
1210 o 2017-07-15: Testing during the interop showed that the validation
1211 functionality interoperated with the Google, AOL, dkimpy and
1212 MailerQ implementations
1214 Contact Info: https://rspamd.com/doc/modules/arc.html and
1215 https://github.com/vstakhov/rspamd
1217 11.8. PERL MAIL::DKIM module
1219 Organization: FastMail
1220 Description: Email domain authentication (sign and/or verify) module,
1221 previously included SPF / DKIM / DMARC, now has ARC added
1222 Status of Operation: Production, deployment usage unknown
1223 Coverage: Built to support [ARC-DRAFT-10]
1224 Licensing: Open Source
1225 Implementation Notes:
1227 o 2017-12-15: v0.50 released with full test set passing for ARC
1229 Contact Info: http://search.cpan.org/~mbradshaw/Mail-DKIM-0.50/
1231 11.9. PERL Mail::Milter::Authentication module
1233 Organization: FastMail
1234 Description: Email domain authentication milter, uses MAIL::DKIM (see
1235 above)
1236 Status of Operation: Intial validation completed during IETF99
1237 hackathon with some follow-on work during the week
1238 Coverage: Built to support [I-D.ARC]
1239 Licensing: Open Source
1240 Implementation Notes:
1242 o 2017-07-15: Validation functionality which interoperates with
1243 Gmail, AOL, dkimpy was demonstrated; later in the week of IETF99,
1244 the signing functionality was reported to be working
1246 o 2017-07-20: ARC functionality has not yet been pushed back to the
1247 github repo but should be showing up soon
1249 Contact Info: https://github.com/fastmail/authentication_milter
1251 11.10. Sympa List Manager
1253 Organization: Sympa Dev Community
1254 Description: Work in progress
1255 Status of Operation: Work in progress
1256 Coverage: unknown
1257 Licensing: open source
1258 Implementation Notes:
1260 o 2018-01-05: Tracked as https://github.com/sympa-community/sympa/
1261 issues/153
1263 Contact Info: https://github.com/sympa-community
1265 11.11. Oracle Messaging Server
1267 Organization: Oracle
1268 Description:
1269 Status of Operation: Intial development work during IETF99 hackathon.
1270 Status since then unknown.
1271 Coverage: Work in progress
1272 Licensing: Unknown
1273 Implementation Notes:
1275 o 2018-03: Protocol handling components are completed, but crypto is
1276 not yet functional.
1278 Contact Info: Chris Newman
1280 11.12. MessageSystems Momentum and PowerMTA platforms
1282 Organization: MessageSystems/SparkPost
1283 Description: OpenARC integration into the LUA-enabled Momentum
1284 processing space
1285 Status of Operation: Beta
1286 Coverage: Built to support [ARC-DRAFT-10]
1287 Licensing: Unknown
1288 Implementation Notes:
1290 o Initial deployments for validation expected in mid-2018.
1292 Contact Info:
1294 12. References
1296 12.1. Normative References
1298 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1299 Requirement Levels", BCP 14, RFC 2119,
1300 DOI 10.17487/RFC2119, March 1997,
1301 .
1303 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes",
1304 RFC 3463, DOI 10.17487/RFC3463, January 2003,
1305 .
1307 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
1308 Specifications: ABNF", STD 68, RFC 5234,
1309 DOI 10.17487/RFC5234, January 2008,
1310 .
1312 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
1313 DOI 10.17487/RFC5322, October 2008,
1314 .
1316 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
1317 DOI 10.17487/RFC5598, July 2009,
1318 .
1320 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
1321 "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
1322 RFC 6376, DOI 10.17487/RFC6376, September 2011,
1323 .
1325 [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and
1326 Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377,
1327 September 2011, .
1329 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
1330 Authorizing Use of Domains in Email, Version 1", RFC 7208,
1331 DOI 10.17487/RFC7208, April 2014,
1332 .
1334 [RFC7601] Kucherawy, M., "Message Header Field for Indicating
1335 Message Authentication Status", RFC 7601,
1336 DOI 10.17487/RFC7601, August 2015,
1337 .
1339 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1340 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1341 May 2017, .
1343 12.2. Informative References
1345 [ARC-DRAFT-05]
1346 Andersen, K., "Authenticated Received Chain (ARC) Protocol
1347 (I-D-05)", n.d., .
1350 [ARC-DRAFT-06]
1351 Andersen, K., "Authenticated Received Chain (ARC) Protocol
1352 (I-D-06)", n.d., .
1355 [ARC-DRAFT-10]
1356 Andersen, K., "Authenticated Received Chain (ARC) Protocol
1357 (I-D-10)", n.d., .
1360 [ARC-MULTI]
1361 Andersen, K., "Using Multiple Signing Algorithms with
1362 ARC", January 2018, .
1365 [ARC-TEST]
1366 Blank, S., "ARC Test Suite", January 2017,
1367 .
1369 [ARC-USAGE]
1370 Jones, S., Adams, T., Rae-Grant, J., and K. Andersen,
1371 "Recommended Usage of the ARC Headers", December 2017,
1372 .
1375 [ENHANCED-STATUS]
1376 "IANA SMTP Enhanced Status Codes", n.d.,
1377 .
1380 [I-D-7601bis]
1381 Kucherawy, M., "Message Header Field for Indicating
1382 Message Authentication Status", February 2018,
1383 .
1386 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
1387 Code: The Implementation Status Section", RFC 6982,
1388 DOI 10.17487/RFC6982, July 2013,
1389 .
1391 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
1392 Message Authentication, Reporting, and Conformance
1393 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
1394 .
1396 [RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky,
1397 E., Ed., and K. Andersen, Ed., "Interoperability Issues
1398 between Domain-based Message Authentication, Reporting,
1399 and Conformance (DMARC) and Indirect Email Flows",
1400 RFC 7960, DOI 10.17487/RFC7960, September 2016,
1401 .
1403 12.3. URIs
1405 [1] https://datatracker.ietf.org/wg/dcrup/about/
1407 [2] mailto:arc-discuss@dmarc.org
1409 [3] mailto:arc-discuss@dmarc.org
1411 [4] https://github.com/Valimail/arc_test_suite
1413 [5] mailto:arc-discuss@dmarc.org
1415 [6] https://trac.ietf.org/trac/dmarc/ticket/17
1417 [7] mailto:dmarc@ietf.org
1419 [8] mailto:arc-discuss@dmarc.org
1421 Appendix A. Appendix A - Design Requirements
1423 (This section is re-inserted for background information from
1424 [ARC-DRAFT-06] and earlier versions.)
1426 The specification of the ARC framework is driven by the following
1427 high-level goals, security considerations, and practical operational
1428 requirements.
1430 A.1. Primary Design Criteria
1432 o Provide a verifiable "chain of custody" for email messages;
1434 o Not require changes for originators of email;
1436 o Support the verification of the ARC header field set by each hop
1437 in the handling chain;
1439 o Work at Internet scale; and
1441 o Provide a trustable mechanism for the communication of
1442 Authentication-Results across trust boundaries.
1444 A.2. Out of Scope
1446 ARC is not a trust framework. Users of the ARC header fields are
1447 cautioned against making unsubstantiated conclusions when
1448 encountering a "broken" ARC sequence.
1450 Appendix B. Appendix B - Example Usage
1452 [[ Note: The following examples were mocked up early in the
1453 definition process for the spec. They no longer reflect the current
1454 definition and need various updates which will be included in a
1455 future draft. Issue 17 [6] ]]
1457 (Obsolete but retained for illustrative purposes)
1459 B.1. Example 1: Simple mailing list
1461 B.1.1. Here's the message as it exits the Origin:
1463 Return-Path:
1464 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1465 (authenticated bits=0)
1466 by segv.d1.example with ESMTP id t0FN4a8O084569;
1467 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1468 (envelope-from jqd@d1.example)
1469 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
1470 s=20130426; t=1421363082;
1471 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1472 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
1473 Content-Transfer-Encoding;
1474 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw
1475 bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl
1476 gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1477 Message-ID: <54B84785.1060301@d1.example>
1478 Date: Thu, 14 Jan 2015 15:00:01 -0800
1479 From: John Q Doe
1480 To: arc@dmarc.org
1481 Subject: Example 1
1483 Hey gang,
1484 This is a test message.
1485 --J.
1487 B.1.2. Message is then received at example.org
1489 B.1.2.1. Example 1, Step A: Message forwarded to list members
1491 Processing at example.org:
1493 o example.org performs authentication checks
1495 o No previous Authentication-Results or ARC-Seal headers are present
1497 o example.org adds ARC-Authentication-Results header
1499 o example.org adds Received: header
1501 o example.org adds a ARC-Seal header
1503 Here's the message as it exits example.org:
1505 Return-Path:
1506 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1507 s=seal2015; d=example.org; cv=none;
1508 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1509 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1510 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1511 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
1512 d=example.org; s=clochette; t=1421363105;
1513 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
1514 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
1515 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
1516 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1F5
1517 vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+m4bw
1518 a6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
1519 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
1520 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
1521 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
1522 (envelope-from jqd@d1.example)
1523 ARC-Authentication-Results: i=1; lists.example.org;
1524 spf=pass smtp.mfrom=jqd@d1.example;
1525 dkim=pass (1024-bit key) header.i=@d1.example;
1526 dmarc=pass
1527 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1528 (authenticated bits=0)
1529 by segv.d1.example with ESMTP id t0FN4a8O084569;
1530 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1531 (envelope-from jqd@d1.example)
1532 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
1533 s=20130426; t=1421363082;
1534 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1535 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
1536 Content-Transfer-Encoding;
1537 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
1538 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
1539 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1540 Message-ID: <54B84785.1060301@d1.example>
1541 Date: Thu, 14 Jan 2015 15:00:01 -0800
1542 From: John Q Doe
1543 To: arc@example.org
1544 Subject: [Lists] Example 1
1546 Hey gang,
1547 This is a test message.
1548 --J.
1550 B.1.3. Example 1: Message received by Recipient
1552 Let's say that the Recipient is example.com
1554 Processing at example.com:
1556 o example.com performs usual authentication checks
1558 o example.com adds Authentication-Results: header, Received header
1560 o Determines that message fails DMARC
1562 o Checks for ARC-Seal: header; finds one
1564 o Validates the signature in the ARC-Seal: header, which covers the
1565 ARC-Authentication-Results: header
1567 o example.com can use the ARC-Authentication-Results values or
1568 verify the DKIM-Signature from lists.example.org
1570 Here's what the message looks like at this point:
1572 Return-Path:
1573 Received: from example.org (example.org [208.69.40.157])
1574 by clothilde.example.com with ESMTP id
1575 d200mr22663000ykb.93.1421363207
1576 for ; Thu, 14 Jan 2015 15:02:40 -0800 (PST)
1577 Authentication-Results: clothilde.example.com; spf=fail
1578 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
1579 header.i=@example.org; dmarc=fail; arc=pass
1580 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1581 s=seal2015; d=example.org; cv=none;
1582 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1583 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1584 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1585 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
1586 d=example.org; s=clochette; t=1421363105;
1587 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
1588 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
1589 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
1590 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
1591 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
1592 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
1593 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
1594 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
1595 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
1596 (envelope-from jqd@d1.example)
1597 ARC-Authentication-Results: i=1; lists.example.org;
1598 spf=pass smtp.mfrom=jqd@d1.example;
1599 dkim=pass (1024-bit key) header.i=@d1.example;
1600 dmarc=pass
1601 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1602 (authenticated bits=0)
1603 by segv.d1.example with ESMTP id t0FN4a8O084569;
1604 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1605 (envelope-from jqd@d1.example)
1606 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
1607 s=20130426; t=1421363082;
1608 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1609 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
1610 Content-Transfer-Encoding;
1611 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw
1612 bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl
1613 gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1614 Message-ID: <54B84785.1060301@d1.example>
1615 Date: Thu, 14 Jan 2015 15:00:01 -0800
1616 From: John Q Doe
1617 To: arc@example.org
1618 Subject: [Lists] Example 1
1620 Hey gang,
1621 This is a test message.
1622 --J.
1624 B.2. Example 2: Mailing list to forwarded mailbox
1626 B.2.1. Here's the message as it exits the Origin:
1628 Return-Path:
1629 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1630 (authenticated bits=0)
1631 by segv.d1.example with ESMTP id t0FN4a8O084569;
1632 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1633 (envelope-from jqd@d1.example)
1634 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
1635 s=20130426; t=1421363082;
1636 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1637 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
1638 Content-Transfer-Encoding;
1639 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw
1640 bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl
1641 gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1642 Message-ID: <54B84785.1060301@d1.example>
1643 Date: Thu, 14 Jan 2015 15:00:01 -0800
1644 From: John Q Doe
1645 To: arc@example.org
1646 Subject: Example 1
1648 Hey gang,
1649 This is a test message.
1650 --J.
1652 B.2.2. Message is then received at example.org
1654 B.2.2.1. Example 2, Step A: Message forwarded to list members
1656 Processing at example.org:
1658 o example.org performs authentication checks
1660 o example.org applies standard DKIM signature
1662 o No previous Authentication-Results or ARC-Seal headers are present
1664 o example.org adds ARC-Authentication-Results header
1666 o example.org adds usual Received: header
1668 o example.org adds a ARC-Seal header
1670 Here's the message as it exits Step A:
1672 Return-Path:
1673 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1674 s=seal2015; d=example.org; cv=none;
1675 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
1676 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
1677 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1678 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
1679 d=example.org; s=clochette; t=1421363105;
1680 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
1681 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
1682 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
1683 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
1684 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
1685 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
1686 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
1687 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
1688 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
1689 (envelope-from jqd@d1.example)
1690 ARC-Authentication-Results: i=1; lists.example.org;
1691 spf=pass smtp.mfrom=jqd@d1.example;
1692 dkim=pass (1024-bit key) header.i=@d1.example;
1693 dmarc=pass
1694 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1695 (authenticated bits=0)
1696 by segv.d1.example with ESMTP id t0FN4a8O084569;
1697 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1698 (envelope-from jqd@d1.example)
1699 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
1700 s=20130426; t=1421363082;
1701 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1702 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
1703 Content-Transfer-Encoding;
1704 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
1705 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
1706 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1707 Message-ID: <54B84785.1060301@d1.example>
1708 Date: Thu, 14 Jan 2015 15:00:01 -0800
1709 From: John Q Doe
1710 To: arc@example.org
1711 Subject: [Lists] Example 1
1713 Hey gang,
1714 This is a test message.
1715 --J.
1717 B.2.2.2. Example 2, Step B: Message from list forwarded
1719 The message is delivered to a mailbox at gmail.com
1720 Processing at gmail.com:
1722 o gmail.com performs usual authentication checks
1724 o gmail.com adds Authentication-Results: and Received: header
1726 o Determines that message fails DMARC
1728 o Checks for ARC-Seal: header; finds one
1730 o Validates the signature in the ARC-Seal: header, which covers the
1731 ARC-Authentication-Results: header
1733 o Uses the ARC-Authentication-Results: values, but:
1735 o Instead of delivering message, prepares to forward message per
1736 user settings
1738 o Applies usual DKIM signature
1740 o gmail.com adds it's own ARC-Seal: header, contents of which are
1742 * version
1744 * sequence number ("i=2")
1746 * hash algorithm (SHA256 as example)
1748 * timestamp ("t=")
1750 * selector for key ("s=notary01")
1752 * domain for key ("d=gmail.com")
1754 * headers included in hash ("h=ARC-Authentication-Results:ARC-
1755 Seal")
1757 * Note: algorithm requires only ARC-Seals with lower sequence #
1758 be included, in ascending order
1760 * signature of the header hash
1762 Here's what the message looks like at this point:
1764 Return-Path:
1765 ARC-Seal: i=2; a=rsa-sha256; t=1421363253;
1766 s=notary01; d=gmail.com; cv=pass;
1767 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDWR
1768 YbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/sut
1769 txO+RRNr0fCFw==
1770 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed;
1771 d=gmail.com; s=20120806;
1772 h=mime-version:content-type:x-original-sender:
1773 x-original-authentication-results:precedence:mailing-list:
1774 list-id:list-post:list-help:list-archive:sender:reply-to:
1775 list-unsubscribe:DKIM-Signature;
1776 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=;
1777 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1778 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1779 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBmfhS
1780 LF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJRFeM
1781 KdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwDBJtXw
1782 bQoZyRtb6X6q0mYaszUB8kw==
1783 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10
1784 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST)
1785 Authentication-Results: i=2; gmail.com; spf=fail
1786 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
1787 header.i=@example.org; dmarc=fail; arc=pass
1788 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1789 s=seal2015; d=example.org; cv=none:
1790 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1791 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1792 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1793 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
1794 d=example.org; s=clochette; t=1421363105;
1795 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
1796 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
1797 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
1798 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
1799 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
1800 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
1801 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
1802 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
1803 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
1804 (envelope-from jqd@d1.example)
1805 ARC-Authentication-Results: i=1; lists.example.org;
1806 spf=pass smtp.mfrom=jqd@d1.example;
1807 dkim=pass (1024-bit key) header.i=@d1.example;
1808 dmarc=pass
1809 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1810 (authenticated bits=0)
1811 by segv.d1.example with ESMTP id t0FN4a8O084569;
1812 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1813 (envelope-from jqd@d1.example)
1814 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
1815 s=20130426; t=1421363082;
1816 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1817 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
1818 Content-Transfer-Encoding;
1819 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
1820 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
1821 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1822 Message-ID: <54B84785.1060301@d1.example>
1823 Date: Thu, 14 Jan 2015 15:00:01 -0800
1824 From: John Q Doe
1825 To: arc@example.org
1826 Subject: [Lists] Example 1
1828 Hey gang,
1829 This is a test message.
1830 --J.
1832 B.2.3. Example 2: Message received by Recipient
1834 Let's say that the Recipient is example.com
1835 Processing at example.com:
1837 o example.com performs usual authentication checks
1839 o example.com adds Authentication-Results: header, Received header
1841 o Determines that message fails DMARC
1843 o Checks for ARC-Seal: header; finds two
1845 o Validates the signature in the highest numbered ("i=2") ARC-Seal:
1846 header, which covers all previous ARC-Seal: and ARC-
1847 Authentication-Results: headers
1849 o Validates the other ARC-Seal header ("i=1"), which covers the ARC-
1850 Authentication-Results: header
1852 o example.com uses the ARC-Authentication-Results: values
1854 Here's what the message looks like at this point:
1856 Return-Path:
1857 Received: from mail-ob0-f188.google.com (mail-ob0-f188.google.com
1858 [208.69.40.157]) by clothilde.example.com with ESMTP id
1859 d200mr22663000ykb.93.1421363268
1860 for ; Thu, 14 Jan 2015 15:03:15 -0800 (PST)
1862 Authentication-Results: clothilde.example.com; spf=fail
1863 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
1864 header.i=@gmail.com; dmarc=fail; arc=pass
1865 ARC-Seal: i=2; a=rsa-sha256; t=1421363253;
1866 s=notary01; d=gmail.com; cv=pass;
1867 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDWR
1868 YbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/sut
1869 txO+RRNr0fCFw==
1870 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed;
1871 d=gmail.com; s=20120806;
1872 h=mime-version:content-type:x-original-sender:
1873 x-original-authentication-results:precedence:mailing-list:
1874 list-id:list-post:list-help:list-archive:sender:reply-to:
1875 :list-unsubscribe:DKIM-Signature;
1876 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=;
1877 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1878 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1879 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBmfhS
1880 LF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJRFeM
1881 KdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwDBJtXw
1882 bQoZyRtb6X6q0mYaszUB8kw==
1883 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10
1884 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST)
1885 Authentication-Results: i=2; gmail.com; spf=fail
1886 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
1887 header.i=@example.org; dmarc=fail; arc=pass
1888 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1889 s=seal2015; d=example.org; cv=none;
1890 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1891 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1892 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1893 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
1894 d=example.org; s=clochette; t=1421363105;
1895 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
1896 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
1897 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
1898 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
1899 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
1900 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
1901 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
1902 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
1903 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
1904 (envelope-from jqd@d1.example)
1905 ARC-Authentication-Results: i=1; lists.example.org;
1906 spf=pass smtp.mfrom=jqd@d1.example;
1907 dkim=pass (1024-bit key) header.i=@d1.example;
1908 dmarc=pass
1909 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1910 (authenticated bits=0)
1911 by segv.d1.example with ESMTP id t0FN4a8O084569;
1912 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1913 (envelope-from jqd@d1.example)
1914 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
1915 s=20130426; t=1421363082;
1916 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1917 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
1918 Content-Transfer-Encoding;
1919 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
1920 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
1921 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1922 Message-ID: <54B84785.1060301@d1.example>
1923 Date: Thu, 14 Jan 2015 15:00:01 -0800
1924 From: John Q Doe
1925 To: arc@example.org
1926 Subject: [Lists] Example 1
1928 Hey gang,
1929 This is a test message.
1930 --J.
1932 B.3. Example 3: Mailing list to forwarded mailbox with source
1934 B.3.1. Here's the message as it exits the Origin:
1936 Return-Path:
1937 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1938 (authenticated bits=0)
1939 by segv.d1.example with ESMTP id t0FN4a8O084569;
1940 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1941 (envelope-from jqd@d1.example)
1942 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1943 s=origin2015; d=d1.example; cv=none;
1944 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61T
1945 X6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69EU
1946 8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1947 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
1948 d=d1.example; s=20130426; t=1421363082;
1949 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1950 h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding;
1951 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrv
1952 Qwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3
1953 TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1954 Message-ID: <54B84785.1060301@d1.example>
1955 Date: Thu, 14 Jan 2015 15:00:01 -0800
1956 From: John Q Doe
1957 To: arc@example.org
1958 Subject: Example 1
1960 Hey gang,
1961 This is a test message.
1962 --J.
1964 B.3.2. Message is then received at example.org
1966 B.3.2.1. Example 3, Step A: Message forwarded to list members with
1967 source
1969 Processing at example.org:
1971 o example.org performs authentication checks
1973 o example.org applies standard DKIM signature
1975 o Checks for ARC-Seal: header; finds one (i=1)
1977 o Validates the signature in the ARC-Seal (i=1): header, which
1978 covers the d1.example ARC-Message-Signature: header
1980 o example.org adds ARC-Authentication-Results header
1982 o example.org adds usual Received: header
1983 o example.org adds a DKIM-Signature
1985 o example.org adds a ARC-Seal header, contents of which are
1987 * sequence number ("i=2")
1989 * hash algorithm (SHA256 as example)
1991 * timestamp ("t=")
1993 * chain validity ("cv=")
1995 * selector for key ("s=seal2015")
1997 * domain for key ("d=example.org")
1999 * signature ("b=")
2001 Here's the message as it exits Step A:
2003 Return-Path:
2004 ARC-Seal: i=2; a=rsa-sha256; t=1421363107;
2005 s=seal2015; d=example.org; cv=pass;
2006 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
2007 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
2008 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
2009 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed;
2010 d=example.org; s=clochette; t=1421363105;
2011 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
2012 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
2013 List-Help:List-Subscribe:From:Reply-To:DKIM-Signature;
2014 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
2015 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
2016 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
2017 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
2018 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
2019 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
2020 (envelope-from jqd@d1.example)
2021 ARC-Authentication-Results: i=2; lists.example.org;
2022 spf=pass smtp.mfrom=jqd@d1.example;
2023 dkim=pass (1024-bit key) header.i=@d1.example;
2024 dmarc=pass
2025 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
2026 (authenticated bits=0)
2027 by segv.d1.example with ESMTP id t0FN4a8O084569;
2028 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
2029 (envelope-from jqd@d1.example)
2030 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
2031 s=origin2015; d=d1.example; cv=none;
2032 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
2033 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
2034 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
2035 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
2036 d=d1.example; s=20130426; t=1421363082;
2037 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
2038 h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding;
2039 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
2040 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
2041 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
2042 Message-ID: <54B84785.1060301@d1.example>
2043 Date: Thu, 14 Jan 2015 15:00:01 -0800
2044 From: John Q Doe
2045 To: arc@example.org
2046 Subject: [Lists] Example 1
2048 Hey gang,
2049 This is a test message.
2050 --J.
2052 B.3.2.2. Example 3, Step B: Message from list forwarded with source
2054 The message is delivered to a mailbox at gmail.com
2055 Processing at gmail.com:
2057 o gmail.com performs usual authentication checks
2059 o gmail.com adds Authentication-Results: and Received: header
2061 o Determines that message fails DMARC
2063 o Checks for ARC-Seal: header; finds two
2065 o Validates the signature in the ARC-Seal (i=2): header, which
2066 covers the ARC-Authentication-Results: header
2068 o Validates the signature in the ARC-Seal (i=1): header, which
2069 covers the d1.example ARC-Message-Signature: header
2071 o Uses the ARC-Authentication-Results: values, but:
2073 o Instead of delivering message, prepares to forward message per
2074 user settings
2076 o Applies usual DKIM signature
2078 o gmail.com adds it's own ARC-Seal: header, contents of which are
2080 * version
2082 * sequence number ("i=2")
2084 * hash algorithm (SHA256 as example)
2086 * timestamp ("t=")
2088 * selector for key ("s=notary01")
2090 * domain for key ("d=gmail.com")
2092 * Note: algorithm requires only ARC-Seals with lower sequence #
2093 be included, in ascending order
2095 * signature of the chain
2097 Here's what the message looks like at this point:
2099 Return-Path:
2100 ARC-Seal: i=3; a=rsa-sha256; t=1421363253;
2101 s=notary01; d=gmail.com; cv=pass;
2102 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwD
2103 WRYbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF
2104 /suttxO+RRNr0fCFw==
2105 ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed;
2106 d=gmail.com; s=20120806;
2107 h=mime-version:content-type:x-original-sender
2108 :x-original-authentication-results:precedence:mailing-list
2109 :list-id:list-post:list-help:list-archive:sender
2110 :list-unsubscribe:reply-to;
2111 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=;
2112 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
2113 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
2114 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBm
2115 fhSLF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJ
2116 RFeMKdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwD
2117 BJtXwbQoZyRtb6X6q0mYaszUB8kw==
2118 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10
2119 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST)
2120 Authentication-Results: i=3; gmail.com; spf=fail
2121 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
2122 header.i=@example.org; dmarc=fail; arc=pass
2123 ARC-Seal: i=2; a=rsa-sha256; t=1421363107;
2124 s=seal2015; d=example.org; cv=pass;
2125 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
2126 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
2127 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
2128 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed;
2129 d=example.org; s=clochette; t=1421363105;
2130 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
2131 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
2132 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
2133 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1
2134 F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+
2135 m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
2136 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
2137 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
2138 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
2139 (envelope-from jqd@d1.example)
2140 ARC-Authentication-Results: i=2; lists.example.org;
2141 spf=pass smtp.mfrom=jqd@d1.example;
2142 dkim=pass (1024-bit key) header.i=@d1.example;
2143 dmarc=pass
2144 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
2145 (authenticated bits=0)
2146 by segv.d1.example with ESMTP id t0FN4a8O084569;
2147 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
2148 (envelope-from jqd@d1.example)
2149 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
2150 s=origin2015; d=d1.example; cv=none;
2151 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
2152 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
2153 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
2154 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
2155 d=d1.example; s=20130426; t=1421363082;
2156 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
2157 h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding;
2158 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYij
2159 rvQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD
2160 4Gd3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
2161 Message-ID: <54B84785.1060301@d1.example>
2162 Date: Thu, 14 Jan 2015 15:00:01 -0800
2163 From: John Q Doe
2164 To: arc@example.org
2165 Subject: [Lists] Example 1
2167 Hey gang,
2168 This is a test message.
2169 --J.
2171 B.3.3. Example 3: Message received by Recipient
2173 Let's say that the Recipient is example.com
2174 Processing at example.com:
2176 o example.com performs usual authentication checks
2178 o example.com adds Authentication-Results: header, Received header
2180 o Determines that message fails DMARC
2182 o Checks for ARC-Seal: header; finds three
2184 o Validates the signature in the highest numbered ("i=2") ARC-Seal:
2185 header, which covers all previous ARC-Seal: and ARC-
2186 Authentication-Results: headers
2188 o Validates the other ARC-Seal header ("i=2"), which covers the ARC-
2189 Authentication-Results: header
2191 o Validates the other ARC-Seal header ("i=1"), which covers the
2192 d1.example ARC-Message-Signature: header
2194 o example.com uses the ARC-Authentication-Results: values
2195 Here's what the message looks like at this point:
2197 Return-Path:
2198 Received: from mail-ob0-f188.google.com (mail-ob0-f188.google.com
2199 [208.69.40.157]) by clothilde.example.com with ESMTP id
2200 d200mr22663000ykb.93.1421363268
2201 for ; Thu, 14 Jan 2015 15:03:15 -0800 (PST)
2202 Authentication-Results: clothilde.example.com; spf=fail
2203 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
2204 header.i=@gmail.com; dmarc=fail; arc=pass
2205 ARC-Seal: i=3; a=rsa-sha256; t=1421363253;
2206 s=notary01; d=gmail.com; cv=pass;
2207 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDW
2208 RYbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/s
2209 uttxO+RRNr0fCFw==
2210 ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed;
2211 d=gmail.com; s=20120806;
2212 h=mime-version:content-type:x-original-sender
2213 :x-original-authentication-results:precedence
2214 :mailing-list:list-id:list-post:list-help:list-archive:sender
2215 :list-unsubscribe:reply-to;
2216 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=;
2217 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
2218 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
2219 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBm
2220 fhSLF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJ
2221 RFeMKdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwD
2222 BJtXwbQoZyRtb6X6q0mYaszUB8kw==
2223 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10
2224 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST)
2225 Authentication-Results: i=3; gmail.com; spf=fail
2226 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
2227 header.i=@example.org; dmarc=fail; arc=pass
2228 ARC-Seal: i=2; a=rsa-sha256; t=1421363107;
2229 s=seal2015; d=example.org; cv=pass;
2230 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
2231 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
2232 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
2233 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed;
2234 d=example.org; s=clochette; t=1421363105;
2235 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
2236 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
2237 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
2238 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1
2239 F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+
2240 m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
2241 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
2242 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
2243 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
2244 (envelope-from jqd@d1.example)
2245 ARC-Authentication-Results: i=2; lists.example.org;
2246 spf=pass smtp.mfrom=jqd@d1.example;
2247 dkim=pass (1024-bit key) header.i=@d1.example;
2248 dmarc=pass
2249 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
2250 (authenticated bits=0)
2251 by segv.d1.example with ESMTP id t0FN4a8O084569;
2252 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
2253 (envelope-from jqd@d1.example)
2254 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
2255 s=origin2015; d=d1.example; cv=none;
2256 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
2257 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
2258 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
2259 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
2260 d=d1.example; s=20130426; t=1421363082;
2261 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
2262 h=MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding;
2263 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
2264 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
2265 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
2266 Message-ID: <54B84785.1060301@d1.example>
2267 Date: Thu, 14 Jan 2015 15:00:01 -0800
2268 From: John Q Doe
2269 To: arc@example.org
2270 Subject: [Lists] Example 1
2272 Hey gang,
2273 This is a test message.
2274 --J.
2276 Appendix C. Acknowledgements
2278 This draft originated with the work of OAR-Dev Group.
2280 The authors thank all of the OAR-Dev group for the ongoing help and
2281 though-provoking discussions from all the participants, especially:
2282 Alex Brotman, Brandon Long, Dave Crocker, Elizabeth Zwicky, Franck
2283 Martin, Greg Colburn, J. Trent Adams, John Rae-Grant, Mike Hammer,
2284 Mike Jones, Steve Jones, Terry Zink, Tim Draegen.
2286 Grateful appreciation is extended to the people who provided feedback
2287 through the discuss mailing list.
2289 Appendix D. Comments and Feedback
2291 Please address all comments, discussions, and questions to
2292 dmarc@ietf.org [7]. Earlier discussions can be found at arc-
2293 discuss@dmarc.org [8].
2295 Authors' Addresses
2297 Kurt Andersen
2298 LinkedIn
2299 1000 West Maude Ave
2300 Sunnyvale, California 94085
2301 USA
2303 Email: kurta@linkedin.com
2305 Brandon Long (editor)
2306 Google
2308 Email: blong@google.com
2310 Steven Jones (editor)
2311 TDP
2313 Email: smj@crash.com
2315 Seth Blank (editor)
2316 Valimail
2318 Email: seth@valimail.com
2320 Murray Kucherawy (editor)
2321 TDP
2323 Email: superuser@gmail.com