idnits 2.17.1
draft-andersen-arc-03.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
-- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii)
Publication Limitation clause. If this document is intended for
submission to the IESG for publication, this constitutes an error.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please
use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
mean).
Found 'MUST not' in this paragraph:
ARC-Seal headers MUST not be included in the signing scope of any
ARC-Message-Signature headers.
== Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please
use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
mean).
Found 'MUST not' in this paragraph:
The ARC-Message-Signature header field MUST be created using the
relaxed header canonicalization rules [RFC6376]. The "c=" field MUST not
be included in the ARC-Message-Signature.
== Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please
use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
mean).
Found 'SHOULD not' in this paragraph:
Any DKIM-Signatures SHOULD not include any of the ARC-Seal,
ARC-Message-Signature, or ARC-Authentication-Results header fields in the
scope of their header list.
-- The document date (April 04, 2016) is 2938 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Missing Reference: 'I-D.ARC' is mentioned on line 653, but not defined
-- Looks like a reference, but probably isn't: '1' on line 1630
== Missing Reference: '-03' is mentioned on line 796, but not defined
== Missing Reference: 'Lists' is mentioned on line 1608, but not defined
== Unused Reference: 'RFC2142' is defined on line 693, but no explicit
reference was found in the text
== Unused Reference: 'RFC2606' is defined on line 697, but no explicit
reference was found in the text
== Unused Reference: 'RFC4686' is defined on line 705, but no explicit
reference was found in the text
== Unused Reference: 'RFC5226' is defined on line 709, but no explicit
reference was found in the text
== Unused Reference: 'RFC5585' is defined on line 727, but no explicit
reference was found in the text
== Unused Reference: 'RFC5863' is defined on line 736, but no explicit
reference was found in the text
== Unused Reference: 'RFC6377' is defined on line 747, but no explicit
reference was found in the text
** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126)
** Obsolete normative reference: RFC 7601 (Obsoleted by RFC 8601)
Summary: 2 errors (**), 0 flaws (~~), 14 warnings (==), 3 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 independent . OAR-DEV Group
3 Internet-Draft OAR-DEV Group
4 Intended status: Informational K. Andersen
5 Expires: October 6, 2016 LinkedIn
6 J. Rae-Grant, Ed.
7 B. Long, Ed.
8 Google
9 T. Adams, Ed.
10 Paypal
11 S. Jones, Ed.
12 TDP
13 April 04, 2016
15 Authenticated Received Chain (ARC)
16 draft-andersen-arc-03
18 Abstract
20 Authenticated Received Chain (ARC) permits an organization which is
21 creating or handling email to indicate their involvement with the
22 handling process by adding a set of cryptographically signed header
23 fields in a manner analagous to that of DomainKeys Identified Mail
24 (DKIM). Assertion of responsibility is validated through a
25 cryptographic signature and by querying the Signer's domain directly
26 to retrieve the appropriate public key. Changes in the message which
27 may break DKIM, may be tracked through the ARC set of 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 http://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 6, 2016.
46 Copyright Notice
48 Copyright (c) 2016 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 (http://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 This document may not be modified, and derivative works of it may not
62 be created, and it may not be published except as an Internet-Draft.
64 Table of Contents
66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
67 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4
68 2.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 4
69 2.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 4
70 2.3. Utility . . . . . . . . . . . . . . . . . . . . . . . . . 4
71 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
72 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
73 5. Definition . . . . . . . . . . . . . . . . . . . . . . . . . 5
74 5.1. Description of the new header fields . . . . . . . . . . 6
75 5.1.1. ARC-Seal . . . . . . . . . . . . . . . . . . . . . . 6
76 5.1.2. ARC-Message-Signature . . . . . . . . . . . . . . . . 8
77 5.1.3. ARC-Authentication-Results . . . . . . . . . . . . . 9
78 5.2. Constructing the ARC-Seal Header Set . . . . . . . . . . 10
79 5.2.1. Handling Violations in the ARC Header Field Set . . . 10
80 5.3. Key Management and Binding . . . . . . . . . . . . . . . 11
81 5.3.1. Namespace . . . . . . . . . . . . . . . . . . . . . . 11
82 6. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
83 6.1. Participation . . . . . . . . . . . . . . . . . . . . . . 11
84 6.2. Relationship between DKIM Signatures and ARC Headers . . 12
85 6.3. Relationship of ARC-Message-Signatures and ARC-Seals . . 12
86 6.4. Validating the ARC set of header fields . . . . . . . . . 12
87 6.5. Assessing violations of ARC set validity . . . . . . . . 12
88 6.6. Reporting violations of ARC set validity . . . . . . . . 13
89 6.7. Recording results of ARC evaluation . . . . . . . . . . . 13
90 6.7.1. RFC6651 Failure Reporting for ARC . . . . . . . . . . 13
91 6.7.2. Reporting ARC Effects for DMARC Local Policy . . . . 13
92 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13
93 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
94 8.1. Update to RFC7601 header field method list . . . . . . . 14
95 8.2. Definitions of the ARC header fields . . . . . . . . . . 14
96 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
97 9.1. Preventing Repurposing of ARC Headers . . . . . . . . . . 15
98 9.2. Messages Which Transit the Same ADMD More Than Once . . . 15
99 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
100 10.1. Normative References . . . . . . . . . . . . . . . . . . 15
101 10.2. Informative References . . . . . . . . . . . . . . . . . 17
102 Appendix A. Appendix A - Example Usage . . . . . . . . . . . . . 18
103 A.1. Example 1: Simple mailing list . . . . . . . . . . . . . 18
104 A.1.1. Here's the message as it exits the Origin: . . . . . 18
105 A.1.2. Message is then received at example.org . . . . . . . 18
106 A.1.3. Example 1: Message received by Recipient . . . . . . 20
107 A.2. Example 2: Mailing list to forwarded mailbox . . . . . . 21
108 A.2.1. Here's the message as it exits the Origin: . . . . . 21
109 A.2.2. Message is then received at example.org . . . . . . . 22
110 A.2.3. Example 2: Message received by Recipient . . . . . . 26
111 A.3. Example 3: Mailing list to forwarded mailbox with source 28
112 A.3.1. Here's the message as it exits the Origin: . . . . . 28
113 A.3.2. Message is then received at example.org . . . . . . . 29
114 A.3.3. Example 3: Message received by Recipient . . . . . . 34
115 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 36
116 Appendix C. Comments and Feedback . . . . . . . . . . . . . . . 37
117 Appendix D. Historical Note . . . . . . . . . . . . . . . . . . 37
118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
120 1. Introduction
122 The development of strong domain authentication through SPF and DKIM
123 has led to the implementation of the DMARC framework [RFC7489].
124 Implicit within the DMARC framework is a requirement that any
125 intermediaries between the source system and ultimate receiver system
126 must preserve the validity of the DKIM signature; however, there are
127 common email practices which break the DKIM validation
128 ([DMARC-INTEROP]). This proposal is intended to define an
129 Authenticated Received Chain (ARC) to address the problems with the
130 untrustworthiness of the standard Received header field sequence so
131 that receivers can develop a more nuanced interpretation to guide any
132 local policies related to messages which arrive with broken domain
133 authentication.
135 Forgery of the Received header fields is a common tactic for bad
136 actors. One of the goals of this proposal is to define a comparable
137 set of trace header fields which can be relied upon by receivers in
138 so far as all ADMD (ADministrative Management Domain) handlers of a
139 message participate in the ARC chain.
141 The Authentication-Results (A-R) mechanism [RFC7601] permits the
142 output of an email authentication evaluation process to be
143 transmitted from the evaluating host to a consuming host that uses
144 the information. On its own, A-R operates within a trust domain.
145 ARC provides a protection mechanism for the data, permiting the
146 communication to cross trust domain boundaries.
148 2. Requirements
150 The specification of the ARC framework is driven by the following
151 high-level goals, security considerations, and practical operational
152 requirements.
154 2.1. Primary Design Criteria
156 o Provide a method by which a "chain of custody" can be documented
157 for email messages
159 o Not require changes for senders of email
161 o Support the complete verification of the ARC header field set by
162 each hop in the handling chain
164 o Work at internet scale
166 o Provide a trustable mechanism for the communication of
167 Authentication-Results across trust boundaries.
169 2.2. Out of Scope
171 ARC is not a trust framework. Users of the ARC header fields are
172 cautioned against making unsubstantiated conclusions when
173 encountering a "broken" ARC sequence.
175 2.3. Utility
177 The ARC-related set of header fields can be used (when validated) to
178 determine the path that an email message has taken between the
179 sending system and receiver. Subject to the cautions mentioned below
180 under Section 9, this information can assist in determining any local
181 policy overrides to for violations of sender domain authentication
182 policies.
184 3. Terminology
186 This section defines terms used in the rest of the document.
188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
190 document are to be interpreted as described in [RFC2119].
192 Readers are encouraged to be familiar with the contents of [RFC5598],
193 and in particular, the potential roles of intermediaries in the
194 delivery of email.
196 Syntax descriptions use Augmented BNF (ABNF) [RFC5234].
198 4. Overview
200 When an email is received without a properly valildated domain
201 author, the inability to believe the accuracy of a series of Received
202 header fields prevents receiving systems from having a way to infer
203 anything about the handling of the message by looking at the ADMD's
204 through which the message has traveled.
206 With the implementation of this proposal, participating ADMDs would
207 be able to securely register their handling of an email message. If
208 all intermediaries participate in the ARC process, then receivers
209 will be able to rely upon the chain and make local policy decisions
210 informed by that information.
212 The ARC set of header fields provides a method by which participating
213 intermediaries can indicate the hand-offs for email messages.
215 5. Definition
217 This proposal defines three new header fields:
219 o Header field name: ARC-Seal (abbreviated below as AS)
221 o Header field name: ARC-Message-Signature (abbreviated below as
222 AMS)
224 o Header field name: ARC-Authentication-Results (abbreviated below
225 as AAR)
227 Collectively, these header fields form a connected set of attribution
228 information by which receivers can identify the handling path for a
229 message. The collective group is referred to in this document as the
230 "ARC header [field]s" or "set of ARC header [field]s".
232 Specific references to individual header fields use the header field
233 names to distinguish such references.
235 The ARC header sets SHOULD be added at the top of a message as it
236 transits MTAs that do authentication checks, so some idea of how far
237 away the checks were done can be inferred. They are therefore
238 considered to be a trace field as defined in [RFC5321], and all of
239 the related definitions in that document apply.
241 Relative ordering of different trace header fields (the ARC sets,
242 DKIM, Received, etc.) is unimportant for this specification. In
243 general, trace header fields, such as ARC, SHOULD be added at the top
244 of the email header fields, but receivers MUST be able to process the
245 header fields from wherever they are found in the message header.
246 Ordering amongst the individual ARC header fields and header field
247 sets is specified below and MUST be followed for proper canonicalized
248 signing and evaluation.
250 5.1. Description of the new header fields
252 5.1.1. ARC-Seal
254 ARC-Seal is a Structured Header Field as defined in Internet Message
255 Format ([RFC5322]). All of the related definitions in that document
256 apply.
258 The ARC-Seal makes use of the "tag=value" construction as defined in
259 [RFC6376], section 3.2.
261 The value of the header field consists of an authentication
262 identifier, and a series of statements and supporting data. The
263 statements are of the form "tag=value" and indicate relevant data
264 about the signing of the ARC set of header fields. The header field
265 can appear more than once in a single message, but each instance must
266 have a unique "i=" value.
268 The ARC-Seal header field only signs across the (earlier) ARC-Seal,
269 (and all) ARC-Message-Signature, and ARC-Authentication-Results
270 header fields.
272 5.1.1.1. Tags in the ARC-Seal header field value
274 5.1.1.1.1. Mandatory
276 o i = instance or sequence number; monotonically increasing at each
277 "sealing" entity beginning with '1'
279 o a = hash algorithm (SHA256 as example) (as per [RFC6376] "a" tag)
281 o t = timestamp (seconds since Unix epoch) (as per [RFC6376] "t"
282 tag)
284 o s = Selector for key ("s=seal2015") (as per [RFC6376] "s" tag)
286 o d = domain for key ("d=example.com") (as per [RFC6376] "d" tag)
288 o b = signature of the header field hash (as per [RFC6376] "b" tag)
290 o cv = chain validation status: values =
292 * 'V' = valid chain received;
294 * 'N' = no pre-existing chain;
296 * 'P' = permanent error, the chain as received does not validate;
298 * 'T' = temporary error, such as a DNS lookup error
300 5.1.1.2. Differences between DKIM-Signature and ARC-Seal
302 No 'bh' value is defined for ARC-Seal.
304 ARC-Seal does not use the 'h' list of header fields that is defined
305 for DKIM-Signatures because the list of applicable header fields is
306 fully determined by the construction rules (see Section 5.2).
308 ARC-Seal does not use the 'c' (canonicalization) tag because only
309 'relaxed' canonicalization [RFC6376] is allowed for ARC-Seal header
310 field canonicalization.
312 5.1.1.3. Implicit 'h' Value for ARC-Seal
314 5.1.1.3.1. First instance
316 The ARC-Seal's (AS(1)) effective "h" scope would be
317 AAR(1):AMS(1):AS(1-no-b).
319 5.1.1.3.2. Second instance
321 The ARC-Seal's (AS(2)) effective "h" scope would be
322 AAR(1):AMS(1):AS(1):AAR(2):AMS(2):AS(2-no-b).
324 5.1.1.3.3. Third instance
326 The ARC-Seal's (AS(3)) effective "h" scope would be
327 AAR(1):AMS(1):AS(1):AAR(2):AMS(2):AS(2):AAR(3):AMS(3):AS(3-no-b).
329 5.1.1.4. Computing the 'b' signature value for ARC-Seal
331 The ARC-Seal instance with an empty 'b' field shall be affixed when
332 computing the signature and the 'b' value added afterward just as in
333 the procedure for DKIM-Signature calculations (section 3.5 of
334 [RFC6376]).
336 Signing calculation MUST be done in bottom-up order as specified in
337 section 5.4.2 of [RFC6376] and as illustrated above Section 5.1.1.3.
339 5.1.2. ARC-Message-Signature
341 The ARC-Message-Signature header field is a special variant of a
342 DKIM-Signature [RFC6376], using only the relaxed header
343 canonicalization rules specified in [RFC6376].
345 The ARC-Message-Signature header field can appear multiple times in a
346 single message but each instance must have a unique "i=" value.
348 5.1.2.1. Differences between DKIM-Signature and ARC-Message-Signature
350 5.1.2.1.1. 'h' value
352 [[ Note: As of -03, the concept of implicit headers included in the
353 signature is eliminated. ]]
355 5.1.2.1.1.1. Header Fields Excluded From ARC-Message-Signature 'h'
357 ARC-Seal headers MUST not be included in the signing scope of any
358 ARC-Message-Signature headers.
360 5.1.2.1.1.2. Header Fields Eligible For ARC-Message-Signature 'h'
362 Participants may include any other header fields within the scope of
363 the ARC-Message-Signature signature except ARC-Seal headers. In
364 particular, all DKIM-Signature header fields are highly recommended
365 to be included. The advice regarding headers to avoid is found in
366 section 5.4 of [RFC6376] and should be observed for ARC-Message-
367 Signatures just as they are for DKIM-Signature exclusion. ARC-
368 Authentication-Results SHOULD be included explicitly within the scope
369 of ARC-Message-Signature headers.
371 5.1.2.1.2. Implicit Canonicalization: 'c'
373 The ARC-Message-Signature header field MUST be created using the
374 relaxed header canonicalization rules [RFC6376]. The "c=" field MUST
375 not be included in the ARC-Message-Signature.
377 5.1.2.1.3. 'i' value
379 For the ARC-Message-Signature, the 'i' value is the corresponding
380 instance which matches the 'i' value of the related ARC-Seal (see
381 Section 5.1.1.1.1).
383 5.1.2.1.4. 'v'
385 'v' is not defined for an ARC-Message-Signature and is not allowed.
387 5.1.2.2. Computing the 'b' value for ARC-Message-Signature
389 The ARC-Message-Signature instance with an empty 'b' field shall be
390 affixed when computing the signature and the 'b' value added
391 afterward just as in the procedure for DKIM-Signature calculations
392 (section 3.5 of [RFC6376]).
394 Header signing MUST be done in bottom-up order as specified in
395 section 5.4.2 of [RFC6376].
397 5.1.3. ARC-Authentication-Results
399 ARC-Authentication-Results is a direct copy of the Authentication-
400 Results header field [RFC7601] created for archival purposes by the
401 each MTA outside of the trust boundary of the originating system
402 which is contributing to the chain of ARC header fields. (See also
403 [OAR] for a similar usage.) The corresponding instance ("i=") value
404 MUST be prefixed to the Authentication-Results.
406 The value of the header field (after removing comments) consists of
407 an instance identifier, an authentication identifier, and then a
408 series of statements and supporting data. The statements are of the
409 form "method=result" and indicate which authentication method(s) were
410 applied and their respective results. For each such statement, the
411 supporting data can include a "reason" string and one or more
412 "property=value" statements indicating which message properties were
413 evaluated to reach that conclusion. The header field can appear
414 multiple times in a single message but each instance must have a
415 unique "i=" value.
417 5.1.3.1. 'i' value
419 For the ARC-Authentication-Results, the 'i' value is the
420 corresponding instance which matches the 'i' value of the related
421 ARC-Seal (see Section 5.1.1.1.1).
423 5.2. Constructing the ARC-Seal Header Set
425 The ARC-Seal is built in the same fashion as the analogous DKIM-
426 Signature [RFC6376], using the relaxed header canonicalization rules
427 specified in [RFC6376] but with a strict ordering component for the
428 header fields which are covered by the cryptographic signature:
430 1. The ARC header fields MUST be ordered in descending instance (i=)
431 order.
433 2. The referenced ARC-Message-Signatures (matching i= value) MUST
434 immediately follow the ARC-Seal instance which included the
435 reference.
437 3. The associated ARC-Authentication-Results header field (matching
438 i= value) MUST be the last item in the list for each set of ARC
439 header fields.
441 Thus, when prefixing ARC header fields to the beginning part of the
442 header block,
444 1. the AAR header would be prefixed first; then
446 2. the AMS would be calculated and prefixed;
448 3. lastly the AS would be calculated and prefixed.
450 5.2.1. Handling Violations in the ARC Header Field Set
452 When ordering the ARC set header fields, if there are gross
453 violations of this protocol, such as duplicated instance numbers,
454 such header field set(s) shall be ordered as follows (when analyzing
455 for validity or subsequent signing):
457 o Within each set, header fields shall be sorted as specified in
458 Section 5.2.
460 o Any header field sets which are complete duplicates shall be
461 deduplicated - leaving only one instance of each unique header
462 field set; then any remaining order dependencies between sets
463 shall be ordered as follows:
465 1. (First) By descending order of i=
467 2. (First) By descending order of t= (from the ARC-Seal header field
468 within the set)
470 3. (Finally) By ascending US-ASCII [RFC1345] sort order for the
471 entire canonicalized header field set
473 The intent of specifying this ordering is to allow downstream message
474 handlers to add their own ARC header field sets in a deterministic
475 manner and to provide some resiliance against mis-behaving downstream
476 MTAs. Participants who wish to have ARC information accrue to their
477 benefit are advised to ensure proper implementation so that this
478 section would never need to be invoked for their ARC header fields.
480 5.3. Key Management and Binding
482 The public keys for ARC-Seals follow the same requirements and
483 semantics as those for DKIM-Signatures [RFC6376]. Operators may use
484 distinct selectors for the ARC-Seals at their own discretion.
486 5.3.1. Namespace
488 All ARC-Seal keys are stored in the same subdomain as DKIM keys
489 [RFC6376]: "_domainkey". Given an ARC-Seal field with a "d=" tag of
490 "example.com" and an "s=" tag of "foo.bar", the DNS query will be for
491 "foo.bar._domainkey.example.com".
493 6. Usage
495 For a more thorough treatment of the recommended usage of the ARC
496 header fields for both intermediaries and end receivers, please
497 consult [ARC-USAGE].
499 6.1. Participation
501 The inclusion of additional ARC header field sets should be done
502 whenever a trust boundary is crossed and especially when prior DKIM-
503 Signatures may not survive the handling which is being performed
504 (such as some mailing lists which modify the content of messages or
505 some gateway transformations). Note that trust boundaries may or may
506 not exactly correspond with ADMD boundaries.
508 Each participating ADMD MUST validate the preceding ARC set of header
509 fields as a part of asserting their own seal. Even if the set is
510 determined to be invalid, a participating ADMD SHOULD apply their own
511 seal because this can help in analysis of breakage points in the
512 chain.
514 6.2. Relationship between DKIM Signatures and ARC Headers
516 Any DKIM-Signatures SHOULD not include any of the ARC-Seal, ARC-
517 Message-Signature, or ARC-Authentication-Results header fields in the
518 scope of their header list.
520 ARC-Message-Signatures SHOULD include all DKIM-Signatures within
521 their scope.
523 6.3. Relationship of ARC-Message-Signatures and ARC-Seals
525 The ARC-Message-Signature(s) should not include any of the ARC-Seal
526 header fields in their coverage scope in order maintain a separation
527 of responsibilities. When adding an ARC-Authentication-Results
528 header field, it should be added before computing the ARC-Message-
529 Signature. When "sealing" the message, an operator must create the
530 ARC-Message-Signature before the ARC-Seal in order to reference it
531 and embed the ARC-Message-Signature within the ARC-Seal signature
532 scope. (Also refer to Section 5.2)
534 Each ARC-Seal is connected to its respective ARC-Message-Signature
535 through the i= field.
537 6.4. Validating the ARC set of header fields
539 Validation of the ARC header fields can be performed step-wise by
540 building up the sequence in order as defined in Section 5.2 and
541 evaluating the correctness of the b= signature at each step. If a
542 violation of the construction rules is found, for instance missing or
543 repeated instance numbers or an otherwise invalid ARC-Seal header
544 field, validation fails and should be indicated as 'P'(ermanent
545 error).
547 6.5. Assessing violations of ARC set validity
549 There are a wide variety of ways in which the ARC set of header
550 fields can be broken. Receivers should be wary of ascribing motive
551 to such breakage although patterns of common behaviour may provide
552 some basis for adjusting local policy decisions.
554 This proposal is exclusively focused on well-behaved, participating
555 intermediaries that result in a valid chain of ARC-related header
556 fields. The presence of such a well-formed valid chain should also
557 not be over-interpreted since malicious content can be easily
558 introduced by otherwise well-intended senders through machine or
559 account compromises. All normal content-based analysis should still
560 be performed on any messages bearing an ARC sequence.
562 6.6. Reporting violations of ARC set validity
564 If a receiver determines that the ARC set of header fields has a
565 permanent error, the receiver MAY signal the breakage through the
566 extended SMTP response code 5.7.7 [RFC3463] "message integrity
567 failure" [ENHANCED-STATUS].
569 The extended SMTP response code should be paired with a 550 reply
570 code. (550 = Requested action not taken: mailbox unavailable (e.g.,
571 mailbox not found, no access, or command rejected for policy reasons)
572 [RFC5321])
574 6.7. Recording results of ARC evaluation
576 Receivers may add an "arc=pass" or "arc=fail" method annotation into
577 their local Authentication-Results [RFC7601] header field.
579 6.7.1. RFC6651 Failure Reporting for ARC
581 Due to very limited adoption, ARC evaluation results are not
582 recommended for failure reporting as described for DKIM in [RFC6651].
584 6.7.2. Reporting ARC Effects for DMARC Local Policy
586 Receivers SHOULD indicate situations in which ARC evaluation
587 influenced the results of their local policy determination. Usage in
588 the DMARC reporting may look something like (utilizing a list of the
589 ARC participants that were found):
591
592 delivered
593 fail
594 fail
595
596 local_policy
597 arc=pass d=d1.example,d2.example
598
599
601 7. Privacy Considerations
603 The ARC-Seal chain provides a verifiable record of the handlers for a
604 message. Anonymous remailers will probably not find this to match
605 their operating goals.
607 8. IANA Considerations
609 This proposal adds three new header fields as defined below.
611 8.1. Update to RFC7601 header field method list
613 This proposal adds a new method to the [RFC7601] header field: "arc="
614 for recording the results of the ARC header field validation.
616 8.2. Definitions of the ARC header fields
618 This proposal adds three new header fields to the "Permanent Message
619 Header Field Registry", as follows:
621 o Header field name: ARC-Seal
623 Applicable protocol: mail
625 Status: draft
627 Author/Change controller: OAR-Dev Group
629 Specification document(s): [I-D.ARC]
631 Related information: [RFC6376]
633 o Header field name: ARC-Message-Signature
635 Applicable protocol: mail
637 Status: draft
639 Author/Change controller: OAR-Dev Group
641 Specification document(s): [I-D.ARC]
643 Related information: [RFC6376]
645 o Header field name: ARC-Authentication-Results
647 Applicable protocol: mail
649 Status: standard
651 Author/Change controller: IETF
653 Specification document(s): [I-D.ARC]
654 Related information: [RFC7601] [OAR]
656 9. Security Considerations
658 Recipients are cautioned to treat messages bearing ARC-Seal chains
659 with the same suspicion that they apply to all other email messages.
660 This includes appropriate content scanning and other checks for
661 potentially malicious content. The handlers which are identified
662 within the ARC-Seal chain may be used to provide input to local
663 policy engines in cases where the sending system's DKIM-Signature
664 does not validate.
666 9.1. Preventing Repurposing of ARC Headers
668 ARC headers can not be re-used as DKIM-Signatures because the header
669 field names are incorporated in the signed content of both the AMS
670 and AS header fields.
672 9.2. Messages Which Transit the Same ADMD More Than Once
674 Messages which loop in and out of an ADMD may lead to confusion about
675 the scope of a particular set of ARC header fields. The use of
676 coordinated instance (i=) values and the non-confusability of the
677 ARC-Message-Signature vs. a DKIM-Signature are designed to prevent
678 misunderstandings.
680 10. References
682 10.1. Normative References
684 [RFC1345] Simonsen, K., "Character Mnemonics and Character Sets",
685 RFC 1345, DOI 10.17487/RFC1345, June 1992,
686 .
688 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
689 Requirement Levels", BCP 14, RFC 2119,
690 DOI 10.17487/RFC2119, March 1997,
691 .
693 [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and
694 Functions", RFC 2142, DOI 10.17487/RFC2142, May 1997,
695 .
697 [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS
698 Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999,
699 .
701 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes",
702 RFC 3463, DOI 10.17487/RFC3463, January 2003,
703 .
705 [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys
706 Identified Mail (DKIM)", RFC 4686, DOI 10.17487/RFC4686,
707 September 2006, .
709 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
710 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
711 DOI 10.17487/RFC5226, May 2008,
712 .
714 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
715 Specifications: ABNF", STD 68, RFC 5234,
716 DOI 10.17487/RFC5234, January 2008,
717 .
719 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
720 DOI 10.17487/RFC5321, October 2008,
721 .
723 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
724 DOI 10.17487/RFC5322, October 2008,
725 .
727 [RFC5585] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys
728 Identified Mail (DKIM) Service Overview", RFC 5585,
729 DOI 10.17487/RFC5585, July 2009,
730 .
732 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
733 DOI 10.17487/RFC5598, July 2009,
734 .
736 [RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker,
737 "DomainKeys Identified Mail (DKIM) Development,
738 Deployment, and Operations", RFC 5863,
739 DOI 10.17487/RFC5863, May 2010,
740 .
742 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
743 "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
744 RFC 6376, DOI 10.17487/RFC6376, September 2011,
745 .
747 [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and
748 Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377,
749 September 2011, .
751 [RFC6651] Kucherawy, M., "Extensions to DomainKeys Identified Mail
752 (DKIM) for Failure Reporting", RFC 6651,
753 DOI 10.17487/RFC6651, June 2012,
754 .
756 [RFC7601] Kucherawy, M., "Message Header Field for Indicating
757 Message Authentication Status", RFC 7601,
758 DOI 10.17487/RFC7601, August 2015,
759 .
761 10.2. Informative References
763 [ARC-USAGE]
764 Jones, S., Adams, T., Rae-Grant, J., and K. Andersen,
765 "Recommended Usage of the ARC Headers", October 2015,
766 .
768 [DMARC-INTEROP]
769 Martin, F., Lear, E., Draegen, T., Zwicky, E., and K.
770 Andersen, "Interoperability Issues Between DMARC and
771 Indirect Email Flows", January 2016,
772 .
775 [ENHANCED-STATUS]
776 "IANA SMTP Enhanced Status Codes", n.d.,
777 .
780 [OAR] Chew, M. and M. Kucherawy, "Original-Authentication-
781 Results Header Field", February 2012,
782 .
785 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
786 Message Authentication, Reporting, and Conformance
787 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
788 .
790 10.3. URIs
792 [1] mailto:arc-discuss@dmarc.org
794 Appendix A. Appendix A - Example Usage
796 [[ TODO [-03]: update these examples ]]
798 A.1. Example 1: Simple mailing list
800 A.1.1. Here's the message as it exits the Origin:
802 Return-Path:
803 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
804 (authenticated bits=0)
805 by segv.d1.example with ESMTP id t0FN4a8O084569;
806 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
807 (envelope-from jqd@d1.example)
808 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
809 s=20130426; t=1421363082;
810 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
811 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
812 Content-Transfer-Encoding;
813 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw
814 bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl
815 gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
816 Message-ID: <54B84785.1060301@d1.example>
817 Date: Thu, 14 Jan 2015 15:00:01 -0800
818 From: John Q Doe
819 To: arc@dmarc.org
820 Subject: Example 1
822 Hey gang,
823 This is a test message.
824 --J.
826 A.1.2. Message is then received at example.org
828 A.1.2.1. Example 1, Step A: Message forwarded to list members
830 Processing at example.org:
832 o example.org performs authentication checks
834 o No previous Auth-Results or ARC-Seal headers are present
836 o example.org adds ARC-Auth-Results header
838 o example.org adds Received: header
840 o example.org adds a ARC-Seal header
841 Here's the message as it exits example.org:
843 Return-Path:
844 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
845 s=seal2015; d=example.org; cv=N;
846 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
847 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
848 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
849 ARC-Message-Signature: i=1; a=rsa-sha256;
850 d=example.org; s=clochette; t=1421363105;
851 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
852 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
853 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
854 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1F5
855 vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+m4bw
856 a6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
857 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
858 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
859 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
860 (envelope-from jqd@d1.example)
861 ARC-Authentication-Results: i=1; lists.example.org;
862 spf=pass smtp.mfrom=jqd@d1.example;
863 dkim=pass (1024-bit key) header.i=@d1.example;
864 dmarc=pass
865 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
866 (authenticated bits=0)
867 by segv.d1.example with ESMTP id t0FN4a8O084569;
868 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
869 (envelope-from jqd@d1.example)
870 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
871 s=20130426; t=1421363082;
872 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
873 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
874 Content-Transfer-Encoding;
875 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
876 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
877 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
878 Message-ID: <54B84785.1060301@d1.example>
879 Date: Thu, 14 Jan 2015 15:00:01 -0800
880 From: John Q Doe
881 To: arc@example.org
882 Subject: [Lists] Example 1
884 Hey gang,
885 This is a test message.
886 --J.
888 A.1.3. Example 1: Message received by Recipient
890 Let's say that the Recipient is example.com
892 Processing at example.com:
894 o example.com performs usual authentication checks
896 o example.com adds Auth-Results: header, Received header
898 o Determines that message fails DMARC
900 o Checks for ARC-Seal: header; finds one
902 o Validates the signature in the ARC-Seal: header, which covers the
903 ARC-Authentication-Results: header
905 o example.com can use the ARC-Authentication-Results values or
906 verify the DKIM-Signature from lists.example.org
908 Here's what the message looks like at this point:
910 Return-Path:
911 Received: from example.org (example.org [208.69.40.157])
912 by clothilde.example.com with ESMTP id
913 d200mr22663000ykb.93.1421363207
914 for ; Thu, 14 Jan 2015 15:02:40 -0800 (PST)
915 Authentication-Results: clothilde.example.com; spf=fail
916 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
917 header.i=@example.org; dmarc=fail; arc=pass
918 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
919 s=seal2015; d=example.org; cv=N;
920 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
921 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
922 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
923 ARC-Message-Signature: i=1; a=rsa-sha256;
924 d=example.org; s=clochette; t=1421363105;
925 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
926 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
927 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
928 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
929 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
930 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
931 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
932 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
933 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
934 (envelope-from jqd@d1.example)
935 ARC-Authentication-Results: i=1; lists.example.org;
936 spf=pass smtp.mfrom=jqd@d1.example;
937 dkim=pass (1024-bit key) header.i=@d1.example;
938 dmarc=pass
939 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
940 (authenticated bits=0)
941 by segv.d1.example with ESMTP id t0FN4a8O084569;
942 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
943 (envelope-from jqd@d1.example)
944 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
945 s=20130426; t=1421363082;
946 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
947 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
948 Content-Transfer-Encoding;
949 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw
950 bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl
951 gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
952 Message-ID: <54B84785.1060301@d1.example>
953 Date: Thu, 14 Jan 2015 15:00:01 -0800
954 From: John Q Doe
955 To: arc@example.org
956 Subject: [Lists] Example 1
958 Hey gang,
959 This is a test message.
960 --J.
962 A.2. Example 2: Mailing list to forwarded mailbox
964 A.2.1. Here's the message as it exits the Origin:
966 Return-Path:
967 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
968 (authenticated bits=0)
969 by segv.d1.example with ESMTP id t0FN4a8O084569;
970 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
971 (envelope-from jqd@d1.example)
972 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
973 s=20130426; t=1421363082;
974 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
975 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
976 Content-Transfer-Encoding;
977 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw
978 bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl
979 gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
980 Message-ID: <54B84785.1060301@d1.example>
981 Date: Thu, 14 Jan 2015 15:00:01 -0800
982 From: John Q Doe
983 To: arc@example.org
984 Subject: Example 1
986 Hey gang,
987 This is a test message.
988 --J.
990 A.2.2. Message is then received at example.org
992 A.2.2.1. Example 2, Step A: Message forwarded to list members
994 Processing at example.org:
996 o example.org performs authentication checks
998 o example.org applies standard DKIM signature
1000 o No previous Auth-Results or ARC-Seal headers are present
1002 o example.org adds ARC-Auth-Results header
1004 o example.org adds usual Received: header
1006 o example.org adds a ARC-Seal header
1008 Here's the message as it exits Step A:
1010 Return-Path:
1011 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1012 s=seal2015; d=example.org; cv=N;
1013 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
1014 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
1015 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1016 ARC-Message-Signature: i=1; a=rsa-sha256;
1017 d=example.org; s=clochette; t=1421363105;
1018 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
1019 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
1020 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
1021 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
1022 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
1023 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
1024 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
1025 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
1026 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
1027 (envelope-from jqd@d1.example)
1028 ARC-Authentication-Results: i=1; lists.example.org;
1029 spf=pass smtp.mfrom=jqd@d1.example;
1030 dkim=pass (1024-bit key) header.i=@d1.example;
1031 dmarc=pass
1032 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1033 (authenticated bits=0)
1034 by segv.d1.example with ESMTP id t0FN4a8O084569;
1035 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1036 (envelope-from jqd@d1.example)
1037 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
1038 s=20130426; t=1421363082;
1039 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1040 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
1041 Content-Transfer-Encoding;
1042 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
1043 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
1044 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1045 Message-ID: <54B84785.1060301@d1.example>
1046 Date: Thu, 14 Jan 2015 15:00:01 -0800
1047 From: John Q Doe
1048 To: arc@example.org
1049 Subject: [Lists] Example 1
1051 Hey gang,
1052 This is a test message.
1053 --J.
1055 A.2.2.2. Example 2, Step B: Message from list forwarded
1057 The message is delivered to a mailbox at gmail.com
1058 Processing at gmail.com:
1060 o gmail.com performs usual authentication checks
1062 o gmail.com adds Auth-Results: and Received: header
1064 o Determines that message fails DMARC
1066 o Checks for ARC-Seal: header; finds one
1068 o Validates the signature in the ARC-Seal: header, which covers the
1069 ARC-Authentication-Results: header
1071 o Uses the ARC-Auth-Results: values, but:
1073 o Instead of delivering message, prepares to forward message per
1074 user settings
1076 o Applies usual DKIM signature
1078 o gmail.com adds it's own ARC-Seal: header, contents of which are
1080 * version
1082 * sequence number ("i=2")
1084 * hash algorithm (SHA256 as example)
1086 * timestamp ("t=")
1088 * selector for key ("s=notary01")
1090 * domain for key ("d=gmail.com")
1092 * headers included in hash ("h=ARC-Authentication-Results:ARC-
1093 Seal")
1095 * Note: algorithm requires only ARC-Seals with lower sequence #
1096 be included, in ascending order
1098 * signature of the header hash
1100 Here's what the message looks like at this point:
1102 Return-Path:
1103 ARC-Seal: i=2; a=rsa-sha256; t=1421363253;
1104 s=notary01; d=gmail.com; cv=V;
1105 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDWR
1106 YbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/sut
1107 txO+RRNr0fCFw==
1108 ARC-Message-Signature: i=2; a=rsa-sha256;
1109 d=gmail.com; s=20120806;
1110 h=mime-version:content-type:x-original-sender:
1111 x-original-authentication-results:precedence:mailing-list:
1112 list-id:list-post:list-help:list-archive:sender:reply-to:
1113 list-unsubscribe:DKIM-Signature;
1114 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=;
1115 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1116 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1117 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBmfhS
1118 LF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJRFeM
1119 KdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwDBJtXw
1120 bQoZyRtb6X6q0mYaszUB8kw==
1121 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10
1122 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST)
1123 Authentication-Results: i=2; gmail.com; spf=fail
1124 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
1125 header.i=@example.org; dmarc=fail; arc=pass
1126 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1127 s=seal2015; d=example.org; cv=N:
1128 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1129 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1130 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1131 ARC-Message-Signature: i=1; a=rsa-sha256;
1132 d=example.org; s=clochette; t=1421363105;
1133 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
1134 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
1135 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
1136 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
1137 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
1138 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
1139 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
1140 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
1141 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
1142 (envelope-from jqd@d1.example)
1143 ARC-Authentication-Results: i=1; lists.example.org;
1144 spf=pass smtp.mfrom=jqd@d1.example;
1145 dkim=pass (1024-bit key) header.i=@d1.example;
1146 dmarc=pass
1147 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1148 (authenticated bits=0)
1149 by segv.d1.example with ESMTP id t0FN4a8O084569;
1150 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1151 (envelope-from jqd@d1.example)
1152 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
1153 s=20130426; t=1421363082;
1154 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1155 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
1156 Content-Transfer-Encoding;
1157 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
1158 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
1159 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1160 Message-ID: <54B84785.1060301@d1.example>
1161 Date: Thu, 14 Jan 2015 15:00:01 -0800
1162 From: John Q Doe
1163 To: arc@example.org
1164 Subject: [Lists] Example 1
1166 Hey gang,
1167 This is a test message.
1168 --J.
1170 A.2.3. Example 2: Message received by Recipient
1172 Let's say that the Recipient is example.com
1173 Processing at example.com:
1175 o example.com performs usual authentication checks
1177 o example.com adds Auth-Results: header, Received header
1179 o Determines that message fails DMARC
1181 o Checks for ARC-Seal: header; finds two
1183 o Validates the signature in the highest numbered ("i=2") ARC-Seal:
1184 header, which covers all previous ARC-Seal: and ARC-
1185 Authentication-Results: headers
1187 o Validates the other ARC-Seal header ("i=1"), which covers the ARC-
1188 Authentication-Results: header
1190 o example.com uses the ARC-Authentication-Results: values
1192 Here's what the message looks like at this point:
1194 Return-Path:
1195 Received: from mail-ob0-f188.google.com (mail-ob0-f188.google.com
1196 [208.69.40.157]) by clothilde.example.com with ESMTP id
1197 d200mr22663000ykb.93.1421363268
1198 for ; Thu, 14 Jan 2015 15:03:15 -0800 (PST)
1200 Authentication-Results: clothilde.example.com; spf=fail
1201 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
1202 header.i=@gmail.com; dmarc=fail; arc=pass
1203 ARC-Seal: i=2; a=rsa-sha256; t=1421363253;
1204 s=notary01; d=gmail.com; cv=V;
1205 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDWR
1206 YbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/sut
1207 txO+RRNr0fCFw==
1208 ARC-Message-Signature: i=2; a=rsa-sha256;
1209 d=gmail.com; s=20120806;
1210 h=mime-version:content-type:x-original-sender:
1211 x-original-authentication-results:precedence:mailing-list:
1212 list-id:list-post:list-help:list-archive:sender:reply-to:
1213 :list-unsubscribe:DKIM-Signature;
1214 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=;
1215 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1216 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1217 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBmfhS
1218 LF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJRFeM
1219 KdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwDBJtXw
1220 bQoZyRtb6X6q0mYaszUB8kw==
1221 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10
1222 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST)
1223 Authentication-Results: i=2; gmail.com; spf=fail
1224 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
1225 header.i=@example.org; dmarc=fail; arc=pass
1226 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1227 s=seal2015; d=example.org; cv=N;
1228 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1229 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1230 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1231 ARC-Message-Signature: i=1; a=rsa-sha256;
1232 d=example.org; s=clochette; t=1421363105;
1233 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
1234 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
1235 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
1236 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
1237 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
1238 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
1239 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
1240 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
1241 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
1242 (envelope-from jqd@d1.example)
1243 ARC-Authentication-Results: i=1; lists.example.org;
1244 spf=pass smtp.mfrom=jqd@d1.example;
1245 dkim=pass (1024-bit key) header.i=@d1.example;
1246 dmarc=pass
1247 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1248 (authenticated bits=0)
1249 by segv.d1.example with ESMTP id t0FN4a8O084569;
1250 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1251 (envelope-from jqd@d1.example)
1252 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
1253 s=20130426; t=1421363082;
1254 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1255 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
1256 Content-Transfer-Encoding;
1257 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
1258 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
1259 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1260 Message-ID: <54B84785.1060301@d1.example>
1261 Date: Thu, 14 Jan 2015 15:00:01 -0800
1262 From: John Q Doe
1263 To: arc@example.org
1264 Subject: [Lists] Example 1
1266 Hey gang,
1267 This is a test message.
1268 --J.
1270 A.3. Example 3: Mailing list to forwarded mailbox with source
1272 A.3.1. Here's the message as it exits the Origin:
1274 Return-Path:
1275 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1276 (authenticated bits=0)
1277 by segv.d1.example with ESMTP id t0FN4a8O084569;
1278 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1279 (envelope-from jqd@d1.example)
1280 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1281 s=origin2015; d=d1.example; cv=N;
1282 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61T
1283 X6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69EU
1284 8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1285 ARC-Message-Signature: i=1; a=rsa-sha256;
1286 d=d1.example; s=20130426; t=1421363082;
1287 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1288 h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding;
1289 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrv
1290 Qwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3
1291 TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1292 Message-ID: <54B84785.1060301@d1.example>
1293 Date: Thu, 14 Jan 2015 15:00:01 -0800
1294 From: John Q Doe
1295 To: arc@example.org
1296 Subject: Example 1
1298 Hey gang,
1299 This is a test message.
1300 --J.
1302 A.3.2. Message is then received at example.org
1304 A.3.2.1. Example 3, Step A: Message forwarded to list members with
1305 source
1307 Processing at example.org:
1309 o example.org performs authentication checks
1311 o example.org applies standard DKIM signature
1313 o Checks for ARC-Seal: header; finds one (i=1)
1315 o Validates the signature in the ARC-Seal (i=1): header, which
1316 covers the d1.example ARC-Message-Signature: header
1318 o example.org adds ARC-Auth-Results header
1320 o example.org adds usual Received: header
1321 o example.org adds a DKIM-Signature
1323 o example.org adds a ARC-Seal header, contents of which are
1325 * sequence number ("i=2")
1327 * hash algorithm (SHA256 as example)
1329 * timestamp ("t=")
1331 * chain validity ("cv=")
1333 * selector for key ("s=seal2015")
1335 * domain for key ("d=example.org")
1337 * signature ("b=")
1339 Here's the message as it exits Step A:
1341 Return-Path:
1342 ARC-Seal: i=2; a=rsa-sha256; t=1421363107;
1343 s=seal2015; d=example.org; cv=V;
1344 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
1345 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
1346 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1347 ARC-Message-Signature: i=2; a=rsa-sha256;
1348 d=example.org; s=clochette; t=1421363105;
1349 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
1350 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
1351 List-Help:List-Subscribe:From:Reply-To:DKIM-Signature;
1352 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
1353 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
1354 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
1355 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
1356 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
1357 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
1358 (envelope-from jqd@d1.example)
1359 ARC-Authentication-Results: i=2; lists.example.org;
1360 spf=pass smtp.mfrom=jqd@d1.example;
1361 dkim=pass (1024-bit key) header.i=@d1.example;
1362 dmarc=pass
1363 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1364 (authenticated bits=0)
1365 by segv.d1.example with ESMTP id t0FN4a8O084569;
1366 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1367 (envelope-from jqd@d1.example)
1368 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1369 s=origin2015; d=d1.example; cv=N;
1370 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1371 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1372 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1373 ARC-Message-Signature: i=1; a=rsa-sha256;
1374 d=d1.example; s=20130426; t=1421363082;
1375 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1376 h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding;
1377 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
1378 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
1379 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1380 Message-ID: <54B84785.1060301@d1.example>
1381 Date: Thu, 14 Jan 2015 15:00:01 -0800
1382 From: John Q Doe
1383 To: arc@example.org
1384 Subject: [Lists] Example 1
1386 Hey gang,
1387 This is a test message.
1388 --J.
1390 A.3.2.2. Example 3, Step B: Message from list forwarded with source
1392 The message is delivered to a mailbox at gmail.com
1393 Processing at gmail.com:
1395 o gmail.com performs usual authentication checks
1397 o gmail.com adds Auth-Results: and Received: header
1399 o Determines that message fails DMARC
1401 o Checks for ARC-Seal: header; finds two
1403 o Validates the signature in the ARC-Seal (i=2): header, which
1404 covers the ARC-Authentication-Results: header
1406 o Validates the signature in the ARC-Seal (i=1): header, which
1407 covers the d1.example ARC-Message-Signature: header
1409 o Uses the ARC-Auth-Results: values, but:
1411 o Instead of delivering message, prepares to forward message per
1412 user settings
1414 o Applies usual DKIM signature
1416 o gmail.com adds it's own ARC-Seal: header, contents of which are
1418 * version
1420 * sequence number ("i=2")
1422 * hash algorithm (SHA256 as example)
1424 * timestamp ("t=")
1426 * selector for key ("s=notary01")
1428 * domain for key ("d=gmail.com")
1430 * Note: algorithm requires only ARC-Seals with lower sequence #
1431 be included, in ascending order
1433 * signature of the chain
1435 Here's what the message looks like at this point:
1437 Return-Path:
1438 ARC-Seal: i=3; a=rsa-sha256; t=1421363253;
1439 s=notary01; d=gmail.com; cv=V;
1440 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwD
1441 WRYbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF
1442 /suttxO+RRNr0fCFw==
1443 ARC-Message-Signature: i=3; a=rsa-sha256;
1444 d=gmail.com; s=20120806;
1445 h=mime-version:content-type:x-original-sender
1446 :x-original-authentication-results:precedence:mailing-list
1447 :list-id:list-post:list-help:list-archive:sender
1448 :list-unsubscribe:reply-to;
1449 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=;
1450 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
1451 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
1452 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBm
1453 fhSLF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJ
1454 RFeMKdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwD
1455 BJtXwbQoZyRtb6X6q0mYaszUB8kw==
1456 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10
1457 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST)
1458 Authentication-Results: i=3; gmail.com; spf=fail
1459 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
1460 header.i=@example.org; dmarc=fail; arc=pass
1461 ARC-Seal: i=2; a=rsa-sha256; t=1421363107;
1462 s=seal2015; d=example.org; cv=V;
1463 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1464 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1465 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1466 ARC-Message-Signature: i=2; a=rsa-sha256;
1467 d=example.org; s=clochette; t=1421363105;
1468 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
1469 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
1470 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
1471 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1
1472 F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+
1473 m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
1474 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
1475 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
1476 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
1477 (envelope-from jqd@d1.example)
1478 ARC-Authentication-Results: i=2; lists.example.org;
1479 spf=pass smtp.mfrom=jqd@d1.example;
1480 dkim=pass (1024-bit key) header.i=@d1.example;
1481 dmarc=pass
1482 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1483 (authenticated bits=0)
1484 by segv.d1.example with ESMTP id t0FN4a8O084569;
1485 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1486 (envelope-from jqd@d1.example)
1487 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1488 s=origin2015; d=d1.example; cv=N;
1489 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1490 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1491 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1492 ARC-Message-Signature: i=1; a=rsa-sha256;
1493 d=d1.example; s=20130426; t=1421363082;
1494 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1495 h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding;
1496 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYij
1497 rvQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD
1498 4Gd3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1499 Message-ID: <54B84785.1060301@d1.example>
1500 Date: Thu, 14 Jan 2015 15:00:01 -0800
1501 From: John Q Doe
1502 To: arc@example.org
1503 Subject: [Lists] Example 1
1505 Hey gang,
1506 This is a test message.
1507 --J.
1509 A.3.3. Example 3: Message received by Recipient
1511 Let's say that the Recipient is example.com
1512 Processing at example.com:
1514 o example.com performs usual authentication checks
1516 o example.com adds Auth-Results: header, Received header
1518 o Determines that message fails DMARC
1520 o Checks for ARC-Seal: header; finds three
1522 o Validates the signature in the highest numbered ("i=2") ARC-Seal:
1523 header, which covers all previous ARC-Seal: and ARC-
1524 Authentication-Results: headers
1526 o Validates the other ARC-Seal header ("i=2"), which covers the ARC-
1527 Authentication-Results: header
1529 o Validates the other ARC-Seal header ("i=1"), which covers the
1530 d1.example ARC-Message-Signature: header
1532 o example.com uses the ARC-Authentication-Results: values
1533 Here's what the message looks like at this point:
1535 Return-Path:
1536 Received: from mail-ob0-f188.google.com (mail-ob0-f188.google.com
1537 [208.69.40.157]) by clothilde.example.com with ESMTP id
1538 d200mr22663000ykb.93.1421363268
1539 for ; Thu, 14 Jan 2015 15:03:15 -0800 (PST)
1540 Authentication-Results: clothilde.example.com; spf=fail
1541 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
1542 header.i=@gmail.com; dmarc=fail; arc=pass
1543 ARC-Seal: i=3; a=rsa-sha256; t=1421363253;
1544 s=notary01; d=gmail.com; cv=V;
1545 b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDW
1546 RYbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/s
1547 uttxO+RRNr0fCFw==
1548 ARC-Message-Signature: i=3; a=rsa-sha256;
1549 d=gmail.com; s=20120806;
1550 h=mime-version:content-type:x-original-sender
1551 :x-original-authentication-results:precedence
1552 :mailing-list:list-id:list-post:list-help:list-archive:sender
1553 :list-unsubscribe:reply-to;
1554 bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=;
1555 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
1556 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
1557 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBm
1558 fhSLF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJ
1559 RFeMKdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwD
1560 BJtXwbQoZyRtb6X6q0mYaszUB8kw==
1561 Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10
1562 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST)
1563 Authentication-Results: i=3; gmail.com; spf=fail
1564 smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
1565 header.i=@example.org; dmarc=fail; arc=pass
1566 ARC-Seal: i=2; a=rsa-sha256; t=1421363107;
1567 s=seal2015; d=example.org; cv=V;
1568 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
1569 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
1570 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1571 ARC-Message-Signature: i=2; a=rsa-sha256;
1572 d=example.org; s=clochette; t=1421363105;
1573 bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
1574 h=List-Id:List-Unsubscribe:List-Archive:List-Post:
1575 List-Help:List-Subscribe:Reply-To:DKIM-Signature;
1576 b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1
1577 F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+
1578 m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
1579 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
1580 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
1581 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
1582 (envelope-from jqd@d1.example)
1583 ARC-Authentication-Results: i=2; lists.example.org;
1584 spf=pass smtp.mfrom=jqd@d1.example;
1585 dkim=pass (1024-bit key) header.i=@d1.example;
1586 dmarc=pass
1587 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1588 (authenticated bits=0)
1589 by segv.d1.example with ESMTP id t0FN4a8O084569;
1590 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1591 (envelope-from jqd@d1.example)
1592 ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
1593 s=origin2015; d=d1.example; cv=N;
1594 b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
1595 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
1596 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
1597 ARC-Message-Signature: i=1; a=rsa-sha256;
1598 d=d1.example; s=20130426; t=1421363082;
1599 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1600 h=MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding;
1601 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
1602 vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
1603 d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1604 Message-ID: <54B84785.1060301@d1.example>
1605 Date: Thu, 14 Jan 2015 15:00:01 -0800
1606 From: John Q Doe
1607 To: arc@example.org
1608 Subject: [Lists] Example 1
1610 Hey gang,
1611 This is a test message.
1612 --J.
1614 Appendix B. Acknowledgements
1616 This draft is the work of OAR-Dev Group.
1618 The authors thank all of the OAR-Dev group for the ongoing help and
1619 though-provoking discussions from all the participants, especially:
1620 Alex Brotman, Brandon Long, Dave Crocker, Elizabeth Zwicky, Franck
1621 Martin, Greg Colburn, J. Trent Adams, John Rae-Grant, Mike Hammer,
1622 Mike Jones, Steve Jones, Terry Zink, Tim Draegen.
1624 Grateful appreciation is extended to the people who provided feedback
1625 through the discuss mailing list.
1627 Appendix C. Comments and Feedback
1629 Please address all comments, discussions, and questions to arc-
1630 discuss@dmarc.org [1][mailto:arc-discuss@dmarc.org].
1632 Appendix D. Historical Note
1634 The ARC-Authentication-Results header is a direct copy of the normal
1635 Authentication-Results header ([RFC7601]) used in a similar fashion
1636 as that proposed in [OAR] but has the instance (i=) value added to
1637 provide correlation within the set of ARC headers.
1639 Authors' Addresses
1641 OAR-DEV Group
1643 Email: arc-discuss@dmarc.org
1645 Kurt Andersen
1646 LinkedIn
1647 2029 Stierlin Ct.
1648 Mountain View, California 94043
1649 USA
1651 Email: kurta@linkedin.com
1653 John Rae-Grant (editor)
1654 Google
1656 Email: johnrg@google.com
1658 Brandon Long (editor)
1659 Google
1661 Email: blong@google.com
1663 J. Trent Adams (editor)
1664 Paypal
1666 Email: trent.adams@paypal.com
1667 Steven Jones (editor)
1668 TDP
1670 Email: smj@crash.com