idnits 2.17.1
draft-ietf-dmarc-arc-protocol-21.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 are 3 instances of too long lines in the document, the longest one
being 15 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 date (November 7, 2018) is 1968 days in the past. Is this
intentional?
Checking references for intended status: Experimental
----------------------------------------------------------------------------
-- Looks like a reference, but probably isn't: '2' on line 1658
-- Looks like a reference, but probably isn't: '1' on line 1656
-- Looks like a reference, but probably isn't: '3' on line 1660
-- Looks like a reference, but probably isn't: '4' on line 1662
-- Looks like a reference, but probably isn't: '5' on line 1664
-- Looks like a reference, but probably isn't: '6' on line 1796
-- Looks like a reference, but probably isn't: '7' on line 1797
-- Looks like a reference, but probably isn't: '8' on line 1798
-- Looks like a reference, but probably isn't: '9' on line 1801
== 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-10
-- Duplicate reference: draft-ietf-dmarc-arc-protocol, mentioned in
'ARC-DRAFT-10', was also mentioned in 'ARC-DRAFT-05'.
== Outdated reference: A later version (-23) exists of
draft-ietf-dmarc-arc-protocol-13
-- Duplicate reference: draft-ietf-dmarc-arc-protocol, mentioned in
'ARC-DRAFT-13', was also mentioned in 'ARC-DRAFT-10'.
== Outdated reference: A later version (-23) exists of
draft-ietf-dmarc-arc-protocol-14
-- Duplicate reference: draft-ietf-dmarc-arc-protocol, mentioned in
'ARC-DRAFT-14', was also mentioned in 'ARC-DRAFT-13'.
== Outdated reference: A later version (-03) exists of
draft-ietf-dmarc-arc-multi-02
== Outdated reference: A later version (-09) exists of
draft-ietf-dmarc-arc-usage-05
Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 13 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: May 11, 2019 Google
6 S. Blank, Ed.
7 Valimail
8 M. Kucherawy, Ed.
9 TDP
10 November 7, 2018
12 Authenticated Received Chain (ARC) Protocol
13 draft-ietf-dmarc-arc-protocol-21
15 Abstract
17 The Authenticated Received Chain (ARC) protocol provides an
18 authenticated "chain of custody" for a message, allowing each entity
19 that handles the message to see what entities handled it before, and
20 to see what the message's authentication assessment was at each step
21 in the handling.
23 ARC allows Internet Mail Handlers to attach assertions of message
24 authentication assessment to individual messages. As messages
25 traverse ARC-enabled Internet Mail Handlers, additional ARC
26 assertions can be attached to messages to form ordered sets of ARC
27 assertions that represent the authentication assessment at each step
28 of message handling paths.
30 ARC-enabled Internet Mail Handlers can process sets of ARC assertions
31 to inform message disposition decisions, to identify Internet Mail
32 Handlers that might break existing authentication mechanisms, and to
33 convey original authentication assessments across trust boundaries.
35 Status of This Memo
37 This Internet-Draft is submitted in full conformance with the
38 provisions of BCP 78 and BCP 79.
40 Internet-Drafts are working documents of the Internet Engineering
41 Task Force (IETF). Note that other groups may also distribute
42 working documents as Internet-Drafts. The list of current Internet-
43 Drafts is at https://datatracker.ietf.org/drafts/current/.
45 Internet-Drafts are draft documents valid for a maximum of six months
46 and may be updated, replaced, or obsoleted by other documents at any
47 time. It is inappropriate to use Internet-Drafts as reference
48 material or to cite them other than as "work in progress."
49 This Internet-Draft will expire on May 11, 2019.
51 Copyright Notice
53 Copyright (c) 2018 IETF Trust and the persons identified as the
54 document authors. All rights reserved.
56 This document is subject to BCP 78 and the IETF Trust's Legal
57 Provisions Relating to IETF Documents
58 (https://trustee.ietf.org/license-info) in effect on the date of
59 publication of this document. Please review these documents
60 carefully, as they describe your rights and restrictions with respect
61 to this document. Code Components extracted from this document must
62 include Simplified BSD License text as described in Section 4.e of
63 the Trust Legal Provisions and are provided without warranty as
64 described in the Simplified BSD License.
66 Table of Contents
68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
69 2. General Concepts . . . . . . . . . . . . . . . . . . . . . . 5
70 2.1. Evidence . . . . . . . . . . . . . . . . . . . . . . . . 5
71 2.2. Custody . . . . . . . . . . . . . . . . . . . . . . . . . 5
72 2.3. Chain of Custody . . . . . . . . . . . . . . . . . . . . 5
73 2.4. Validation of Chain of Custody . . . . . . . . . . . . . 5
74 3. Terminology and Definitions . . . . . . . . . . . . . . . . . 6
75 3.1. ARC Set . . . . . . . . . . . . . . . . . . . . . . . . . 6
76 3.2. Authenticated Received Chain (ARC) . . . . . . . . . . . 7
77 3.3. Internet Mail Handlers / Intermediaries . . . . . . . . . 7
78 3.4. Authentication Assessment . . . . . . . . . . . . . . . . 7
79 3.5. Signing vs Sealing . . . . . . . . . . . . . . . . . . . 7
80 3.6. Sealer . . . . . . . . . . . . . . . . . . . . . . . . . 8
81 3.7. Validator . . . . . . . . . . . . . . . . . . . . . . . . 8
82 3.8. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . 8
83 3.9. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . 8
84 4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 8
85 4.1. ARC Header Fields . . . . . . . . . . . . . . . . . . . . 8
86 4.1.1. ARC-Authentication-Results (AAR) . . . . . . . . . . 9
87 4.1.2. ARC-Message-Signature (AMS) . . . . . . . . . . . . . 9
88 4.1.3. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . 10
89 4.1.4. Internationalized Email (EAI) . . . . . . . . . . . . 11
90 4.2. ARC Set . . . . . . . . . . . . . . . . . . . . . . . . . 12
91 4.2.1. Instance Tags . . . . . . . . . . . . . . . . . . . . 12
92 4.3. Authenticated Received Chain . . . . . . . . . . . . . . 12
93 4.4. Chain Validation Status . . . . . . . . . . . . . . . . . 13
94 5. Protocol Actions . . . . . . . . . . . . . . . . . . . . . . 13
95 5.1. Sealer Actions . . . . . . . . . . . . . . . . . . . . . 14
96 5.1.1. Header Fields To Include In ARC-Seal Signatures . . . 15
97 5.1.2. Marking and Sealing "cv=fail" (Invalid) Chains . . . 15
98 5.1.3. Only One Authenticated Received Chain Per Message . . 15
99 5.1.4. Broad Ability to Seal . . . . . . . . . . . . . . . . 16
100 5.1.5. Sealing is Always Safe . . . . . . . . . . . . . . . 16
101 5.2. Validator Actions . . . . . . . . . . . . . . . . . . . . 16
102 5.2.1. All Failures Are Permanent . . . . . . . . . . . . . 18
103 5.2.2. Responding to ARC Validation Failures During the SMTP
104 Transaction . . . . . . . . . . . . . . . . . . . . . 18
105 6. Communication of Validation Results . . . . . . . . . . . . . 18
106 7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 19
107 7.1. Communicate Authentication Assessment Across Trust
108 Boundaries . . . . . . . . . . . . . . . . . . . . . . . 19
109 7.1.1. Message Scanning Services . . . . . . . . . . . . . . 19
110 7.1.2. Multi-tier MTA Processing . . . . . . . . . . . . . . 19
111 7.1.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 20
112 7.2. Inform Message Disposition Decisions . . . . . . . . . . 20
113 7.2.1. DMARC Local Policy Overrides . . . . . . . . . . . . 20
114 7.2.2. DMARC Reporting . . . . . . . . . . . . . . . . . . . 21
115 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22
116 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
117 9.1. Increased Header Field Size . . . . . . . . . . . . . . . 22
118 9.2. DNS Operations . . . . . . . . . . . . . . . . . . . . . 22
119 9.3. Message Content Suspicion . . . . . . . . . . . . . . . . 23
120 9.4. Message Sealer Suspicion . . . . . . . . . . . . . . . . 23
121 9.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 23
122 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
123 10.1. Email Authentication Results Names Registry Update . . . 24
124 10.2. Email Authentication Methods Registry Update . . . . . . 24
125 10.3. Definitions of the ARC header fields . . . . . . . . . . 24
126 10.4. New Enhanced Status Code - ARC Validation . . . . . . . 25
127 11. Experimental Considerations . . . . . . . . . . . . . . . . . 25
128 11.1. Success Consideration . . . . . . . . . . . . . . . . . 25
129 11.2. Failure Considerations . . . . . . . . . . . . . . . . . 26
130 11.3. Open Questions . . . . . . . . . . . . . . . . . . . . . 26
131 11.3.1. Value of the ARC-Seal (AS) Header Field . . . . . . 26
132 11.3.2. Usage and/or signals from multiple selectors and/or
133 domains in ARC sets . . . . . . . . . . . . . . . . 26
134 11.3.3. DNS Overhead . . . . . . . . . . . . . . . . . . . . 26
135 11.3.4. What Trace Information is Valuable . . . . . . . . . 27
136 12. Implementation Status . . . . . . . . . . . . . . . . . . . . 27
137 12.1. GMail test reflector and incoming validation . . . . . . 28
138 12.2. AOL test reflector and internal tagging . . . . . . . . 28
139 12.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 29
140 12.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . 29
141 12.5. Mailman 3.x patch . . . . . . . . . . . . . . . . . . . 29
142 12.6. Copernica/MailerQ web-based validation . . . . . . . . . 30
143 12.7. Rspamd . . . . . . . . . . . . . . . . . . . . . . . . . 30
144 12.8. PERL MAIL::DKIM module . . . . . . . . . . . . . . . . . 31
145 12.9. PERL Mail::Milter::Authentication module . . . . . . . . 31
146 12.10. Sympa List Manager . . . . . . . . . . . . . . . . . . . 31
147 12.11. Oracle Messaging Server . . . . . . . . . . . . . . . . 32
148 12.12. MessageSystems Momentum and PowerMTA platforms . . . . . 32
149 12.13. Exim . . . . . . . . . . . . . . . . . . . . . . . . . . 32
150 12.14. Halon MTA . . . . . . . . . . . . . . . . . . . . . . . 32
151 12.15. IIJ . . . . . . . . . . . . . . . . . . . . . . . . . . 33
152 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
153 13.1. Normative References . . . . . . . . . . . . . . . . . . 33
154 13.2. Informative References . . . . . . . . . . . . . . . . . 34
155 13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 35
156 Appendix A. Design Requirements . . . . . . . . . . . . . . . . 36
157 A.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 36
158 A.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 36
159 Appendix B. Example Usage . . . . . . . . . . . . . . . . . . . 36
160 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 38
161 Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 38
162 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
164 1. Introduction
166 The utility of widely deployed email authentication technologies such
167 as Sender Policy Framework (SPF) [RFC7208] and DomainKeys Identified
168 Mail (DKIM) [RFC6376] is impacted by the processing of Internet Mail
169 by intermediate handlers. This impact is thoroughly documented in
170 the defining documents for SPF and DKIM and further discussed in
171 [RFC6377] and [RFC7960].
173 DMARC [RFC7489] also relies upon SPF and DKIM authentication
174 mechanisms. Failures of authentication caused by the actions of
175 intermediate handlers can cause legitimate mail to be incorrectly
176 rejected or misdirected.
178 Authenticated Received Chain (ARC) creates a mechanism for individual
179 Internet Mail Handlers to add their authentication assessment to a
180 message's ordered set of handling results. ARC encapsulates the
181 authentication assessment in a DKIM signature derivative to grant
182 other handlers the ability to verify the authenticity of the
183 individual assessment assertion as well as the aggregate set and
184 sequence of results.
186 Ordered sets of authentication assessments can be used by ARC-enabled
187 Internet Mail Handlers to inform message handling disposition, to
188 identify where alteration of message content might have occurred, and
189 to provide additional trace information for use in understanding
190 message handling paths.
192 2. General Concepts
194 ARC is loosely based on concepts from evidence collection. Evidence
195 is usually collected, labeled, stored, and transported in specific
196 ways to preserve the state of evidence and to document all processing
197 steps.
199 2.1. Evidence
201 In ARC's situation, the "evidence" is a message's authentication
202 assessment at any point along the delivery path between origination
203 and final delivery. Determination of message authentication can be
204 affected when intermediate handlers modify message content (header
205 fields and/or body content), route messages through unforeseen paths,
206 or change envelope information.
208 The authentication assessment for a message is determined upon
209 receipt of a message and documented in the Authentication-Results
210 header field(s). ARC extends this mechanism to survive transit
211 through intermediary ADMDs.
213 Because the first-hand determination of an authentication assessment
214 can never be reproduced by other handlers, the assertion of the
215 authentication assessment is more akin to testimony by a verifiable
216 party than hard evidence which can be independently evaluated.
218 2.2. Custody
220 "Custody" refers to when an Internet Mail Handler processes a
221 message. When a handler takes custody of a message, the handler
222 becomes a custodian and attaches their own evidence (authentication
223 assessment upon receipt) to the message if they are ARC-enabled.
224 Evidence is added in such a way so that future handlers can verify
225 the authenticity of both evidence and custody.
227 2.3. Chain of Custody
229 The "chain of custody" of ARC is the entire set of evidence and
230 custody that travels with a message.
232 2.4. Validation of Chain of Custody
234 Any ARC-enabled Internet Mail Handler can validate the entire set of
235 custody and the authentication assessments asserted by each party to
236 yield a valid Chain of Custody. If the evidence-supplying custodians
237 can be trusted, then the validated Chain of Custody describes the
238 (possibly changing) authentication assessment as the message traveled
239 through various custodians.
241 Even though a message's authentication assessment might have changed,
242 the validated chain of custody can be used to determine if the
243 changes (and the custodians responsible for the changes) can be
244 tolerated.
246 3. Terminology and Definitions
248 This section defines terms used in the rest of the document.
250 Readers should to be familiar with the contents, core concepts, and
251 definitions found in [RFC5598]. The potential roles of transit
252 services in the delivery of email are directly relevant.
254 Language, syntax (including some ABNF constructs), and concepts are
255 imported from DKIM [RFC6376]. Specific references to DKIM are made
256 throughout this document. The following terms are imported from
257 [RFC5598]:
259 o ADministrative Management Domain (ADMD), Section 2.3
261 o Message Transfer Agents (MTA), Section 4.3.2
263 o Message Submission Agent (MSA), Section 4.3.1
265 o Message Delivery Agent (MDA), Section 4.3.3
267 Syntax descriptions use Augmented BNF (ABNF) [RFC5234] and [RFC7405].
269 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
270 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
271 "OPTIONAL" in this document are to be interpreted as described in
272 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
273 capitals, as shown here. These words may also appear in this
274 document in lower case as plain English words, absent their normative
275 meanings.
277 3.1. ARC Set
279 Section 4.1 introduces three (3) ARC header fields which are added to
280 a message by an ARC-enabled internet mail handler. Together, these
281 three header fields compose a single "ARC Set". An ARC Set provides
282 the means for an Internet Mail Handler to attach an authentication
283 assessment to a message in a manner that can be verified by future
284 handlers. A single message can contain multiple ARC Sets.
286 In general concept terms, an ARC Set represents Evidence and Custody.
288 3.2. Authenticated Received Chain (ARC)
290 The sequence of ARC Sets attached to a message at a given time is
291 called the Authenticated Received Chain. An Authenticated Received
292 Chain is the record of individual authentication assessments as a
293 message traverses through ARC-participating ADMDs.
295 The first attachment of an ARC Set to a message causes an
296 Authenticated Received Chain to be created. Additional attachments
297 of ARC Sets cause the Authenticated Received Chain to be extended.
299 In General concept terms, an Authenticated Received Chain represents
300 Chain of Custody.
302 3.3. Internet Mail Handlers / Intermediaries
304 Internet Mail Handlers process and deliver messages across the
305 Internet and include MSAs, MTAs, MDAs, gateways, and mailing lists as
306 defined in [RFC5598].
308 Throughout this document the term "intermediaries" refers to the both
309 regular MTAs as well as delivery/reposting agents such as mailing
310 lists covered within the scope of [RFC5598]'s transit services.
312 "Intermediaries" and "Internet Mail Handlers" are used synonymously
313 throughout this document.
315 3.4. Authentication Assessment
317 The Authentication Assessment which is affixed to a message as part
318 of each ARC Set consists of the "authres-payload" [I-D-7601bis]. For
319 the integrity of an ARC Set, the Authentication Assessment only needs
320 to be properly encapsulated within the ARC Set as defined below
321 Section 4.1. The accuracy or syntax of the authres-payload field
322 does not affect the validity of the ARC chain itself.
324 3.5. Signing vs Sealing
326 Signing is the process of affixing a digital signature to a message
327 as a header field, such as when a DKIM-Signature (as in [RFC6376]
328 section 2.1), or an AMS or AS is added. Sealing is when an ADMD
329 affixes a complete and valid ARC Set to a message creating or
330 continuing an Authenticated Received Chain.
332 3.6. Sealer
334 A Sealer is an Internet Mail Handler that attaches a complete and
335 valid ARC Set to a message.
337 In general concept terms, a Sealer adds its testimony (assertion of
338 authentication assessment) and proof of custody to the Chain of
339 Custody.
341 3.7. Validator
343 A Validator is an ARC-enabled Internet Mail Handler that evaluates an
344 Authenticated Received Chain for validity and content. The process
345 of evaluation of the individual ARC Sets that compose an
346 Authenticated Received Chain is described in Section 5.2.
348 In general concept terms, a Validator inspects the Chain of Custody
349 to determine the content and validity of individual Evidence supplied
350 by custodians.
352 3.8. Imported ABNF Tokens
354 The following ABNF tokens are imported:
356 o tag-list ([RFC6376] section 3.2)
358 o authres-payload ([I-D-7601bis] section 2.2)
360 o cfws ([RFC5322] section 3.2.2)
362 3.9. Common ABNF Tokens
364 The following ABNF tokens are used elsewhere in this document:
366 position = 1*2DIGIT ; 1 - 50
367 instance = [CFWS] %s"i" [CFWS] "="
368 [CFWS] position
369 chain-status = ("none" / "fail" / "pass")
370 seal-cv-tag = %s"cv" [CFWS] "="
371 [CFWS] chain-status
373 4. Protocol Elements
375 4.1. ARC Header Fields
377 ARC introduces three new header fields. Syntax for new header fields
378 adapts existing specifications. This document only describes where
379 ARC-specific changes in syntax and semantics differ from existing
380 specifications.
382 4.1.1. ARC-Authentication-Results (AAR)
384 The ARC-Authentication-Results (AAR) header field records the message
385 authentication assessment as processed by an ARC-participating ADMD
386 at message arrival time.
388 In general concept terms, the AAR header field is where Evidence is
389 recorded by a custodian.
391 The AAR header field is similar in syntax and semantics to an
392 Authentication-Results field [I-D-7601bis], with two (2) differences:
394 o the name of the header field itself;
396 o the presence of the "instance tag". Additional information on the
397 "instance tag" can be found in Section 4.2.1.
399 The formal ABNF for the AAR header field is:
401 arc-info = instance [CFWS] ";" authres-payload
402 arc-authres-header = "ARC-Authentication-Results:" [CFWS] arc-info
404 Because there is only one AAR allowed per ARC set, the AAR MUST
405 contain the combined authres-payload with all of the authentication
406 results from within the participating ADMD, regardless of how many
407 Authentication-Results header fields are attached to the message.
409 4.1.2. ARC-Message-Signature (AMS)
411 The ARC-Message-Signature (AMS) header field allows an ARC-
412 participating ADMD to convey some responsibility (custodianship) for
413 a message and possible message modifications to future ARC-
414 participating custodians.
416 In general concept terms, the AMS header field identifies a
417 custodian.
419 The AMS header field has the same syntax and semantics as the DKIM-
420 Signature field [RFC6376], with three (3) differences:
422 o the name of the header field itself;
424 o no version tag ("v") is defined for the AMS header field. As
425 required for undefined tags (in [RFC6376]), if seen, a version tag
426 MUST be ignored;
428 o the "i" (AUID) tag is not imported from DKIM; instead, this tag is
429 replaced by the "instance tag" as defined in Section 4.2.1;
431 ARC places no requirements on the selectors and/or domains used for
432 the AMS header field signatures.
434 The formal ABNF for the AMS header field is:
436 arc-ams-info = instance [CFWS] ";" tag-list
437 arc-message-signature = "ARC-Message-Signature:" [CFWS] arc-ams-info
439 To reduce the chances of accidental invalidation of AMS signatures:
441 o AMS header fields are added by ARC-participating ADMDs as messages
442 exit the ADMD. AMS header fields SHOULD be attached so that any
443 modifications made by the ADMD are included in the signature of
444 the AMS header field.
446 o Authentication-Results header fields MUST NOT be included in AMS
447 signatures as they are likely to be deleted by downstream ADMDs
448 (per [I-D-7601bis] Section 5).
450 o ARC-related header fields (ARC-Authentication-Results, ARC-
451 Message-Signature, ARC-Seal) MUST NOT be included in the list of
452 header fields covered by the signature of the AMS header field.
454 To preserve the ability to verify the integrity of a message, the
455 signature of the AMS header field SHOULD include any DKIM-Signature
456 header fields already present in the message.
458 4.1.3. ARC-Seal (AS)
460 The ARC-Seal (AS) header field permits ARC-participating ADMDs to
461 verify the integrity of AAR header fields and corresponding AMS
462 header fields.
464 In general concept terms, the AS header field is how custodians bind
465 their authentication assessments (testimonial) into a Chain of
466 Custody so that Validators can inspect individual evidence and
467 custodians.
469 The AS header field is similar in syntax and semantics to DKIM-
470 Signatures [RFC6376], with the following differences:
472 o the "i" (AUID) tag is not imported from DKIM; instead, this tag is
473 replaced by the "instance tag" as defined in Section 4.2.1;
475 o the signature of the AS header field does not cover the body of
476 the message and therefore there is no 'bh' tag. The signature of
477 the AS header field only covers specific header fields as defined
478 in Section 5.1.1;
480 o no body canonicalization is performed as the AS signature does not
481 cover the body of a message;
483 o only "relaxed" header field canonicalization ([RFC6376] section
484 3.4.2) is used;
486 o the only supported tags are "i" (from Section 4.2.1 of this
487 document), and "a", "b", "d, "s", "t" from [RFC6376] Section 3.5.
488 Note especially that the DKIM "h" tag is NOT allowed and if found,
489 MUST result in a cv status of "fail" (for more information see
490 Section 5.1.1);
492 o an additional tag, "cv" ("seal-cv-tag" in the ARC-Seal ABNF
493 definition) is used to communicate Chain Validation Status to
494 subsequent ADMDs.
496 ARC places no requirements on the selectors and/or domains used for
497 the AS header field signatures.
499 The formal ABNF for the AS header field is:
501 arc-as-info = instance [CFWS] ";" tag-list
502 arc-seal = "ARC-Seal:" [CFWS] arc-as-info
504 4.1.4. Internationalized Email (EAI)
506 In internationalized messages [RFC6532] many header fields can
507 contain UTF-8 as well as ASCII text. The changes for EAI are all
508 inherited from DKIM as updated by [draft-levine-eaiauth] and
509 Authentication-Results as updated in [I-D-7601bis], but are called
510 out here for emphasis.
512 In all ARC header fields, the d= s= tags can contain U-labels. In
513 all tags, non-ASCII characters need not be quoted in dkim-quoted-
514 printable.
516 The AAR header allows UTF-8 in the same places that A-R does, as
517 described in [I-D-7601bis].
519 4.2. ARC Set
521 An "ARC Set" is a single collection of three ARC header fields (AAR,
522 AMS, and AS). ARC header fields of an ARC Set share the same
523 "instance" value.
525 By adding all ARC header fields to a message, an ARC Sealer adds an
526 ARC Set to a message. A description of how Sealers add an ARC Set to
527 a message is found in Section 5.1.
529 4.2.1. Instance Tags
531 Instance tags describe which ARC header fields belong to an ARC Set.
532 Each ARC header field of an ARC Set shares the same instance tag
533 value.
535 Instance tag values are integers that begin at 1 and are incremented
536 by each addition of an ARC Set. Through the incremental values of
537 instance tags, an ARC Validator can determine the order in which ARC
538 Sets were added to a message.
540 Instance tag values can range from 1-50 (inclusive).
542 _INFORMATIONAL:_ The upper limit of 50 was picked based on some
543 initial observations reported by early working group members. The
544 value was chosen so as to balance the risk of excessive header field
545 growth Section 9.1 against expert opinion regarding the probability
546 of long-tail but non-looping multiple-intermediary mail flows.
547 Longer ARC chains will also impose load on validators and DNS to
548 support additional verification steps. Observed quantities of
549 "Received" header fields was also considered in establishing this as
550 an experimental initial value.
552 Valid ARC Sets MUST have exactly one instance of each ARC header
553 field (AAR, AMS, and AS) for a given instance value and signing
554 algorithm.
556 For handling multiple signing algorithms, see [ARC-MULTI].
558 4.3. Authenticated Received Chain
560 An Authenticated Received Chain is an ordered collection of ARC Sets.
561 As ARC Sets are enumerated sets of ARC header fields, an
562 Authenticated Received Chain represents the output of message
563 authentication assessments along the handling path of ARC-enabled
564 processors.
566 Authentication Assessments determined at each step of the ARC-enabled
567 handling path is present in an Authenticated Received Chain in the
568 form of AAR header fields. The ability to verify the identity of
569 message handlers and the integrity of message content is provided by
570 AMS header fields. AS header fields allow messages handlers to
571 validate the assertions, order and sequence of the Authenticated
572 Received Chain itself.
574 In general concept terms, an Authenticated Received Chain represents
575 a message's Chain of Custody. Validators can consult a message's
576 Chain of Custody to gain insight regarding each custodian of a
577 message and the Evidence collected by each custodian.
579 4.4. Chain Validation Status
581 The state of the Authenticated Received Chain at a specific
582 processing step is called the "Chain Validation Status". Chain
583 Validation Status information is communicated in several ways:
585 o the AS header field in the "cv" tag, and
587 o as part of Authentication-Results and AAR header field(s).
589 Chain Validation Status has one of three possible values:
591 o none: There was no Authenticated Received Chain on the message
592 when it arrived for validation. Typically, this occurs when a
593 message is received directly from a message's original Message
594 Transfer Agent (MTA) or Message Submission Agent (MSA), or from an
595 upstream Internet Mail Handler that is not participating in ARC
596 handling.
598 o fail: The message contains an Authenticated Received Chain whose
599 validation failed.
601 o pass: The message contains an Authenticated Received Chain whose
602 validation succeeded.
604 5. Protocol Actions
606 ARC-enabled Internet Mail Handlers generally act as both ARC
607 Validators (when receiving messages) and ARC Sealers (when sending
608 messages onward, not originated locally).
610 An Authenticated Received Chain with a Chain Validation Status of
611 "pass" (or "none") allows Internet Mail Handlers to ascertain:
613 o all ARC-participating ADMDs that claim responsibility for handling
614 (and possibly modifying) the message in transit;
616 o the authentication assessments of the message as determined by
617 each ADMD (from AAR header fields).
619 With this information, Internet Mail Handlers MAY inform local policy
620 decisions regarding disposition of messages that experience
621 authentication failure due to intermediate processing.
623 5.1. Sealer Actions
625 To "seal" a message, an ARC Sealer adds an ARC Set (the three ARC
626 header fields AAR, AMS, and AS) to a message. All ARC header fields
627 in an ARC Set share the same instance tag value.
629 To perform Sealing (aka to build and attach a new ARC Set), the
630 following actions must be taken by an ARC Sealer when presented with
631 a message:
633 1. All message modifications (including adding DKIM-Signature header
634 field(s)) MUST be performed before Sealing.
636 2. If the message already contains an Authenticated Received Chain
637 with the most recent AS reporting "cv=fail", then there is no
638 need to proceed and the algorithm stops here.
640 3. Calculate the instance value: if the message already contains an
641 Authenticated Received Chain, the instance value is 1 more than
642 the highest instance number found in the Authenticated Received
643 Chain. If no Authenticated Received Chain exists, the instance
644 value is 1.
646 4. Using the calculated instance value, generate and attach a
647 complete ARC set to the message as follows:
649 1. Generate and attach an ARC-Authentication-Results header
650 field as defined in Section 4.1.1.
652 2. Generate and attach an ARC-Message-Signature header field as
653 defined in Section 4.1.2.
655 3. Generate and attach an ARC-Seal header field using the AS
656 definition found in Section 4.1.3, the prescribed headers
657 defined in Section 5.1.1, and the Chain Validation Status as
658 determined during ARC Validation.
660 5.1.1. Header Fields To Include In ARC-Seal Signatures
662 The ARC-Seal is generated in a manner similar to how DKIM-Signatures
663 are added to messages ([RFC6376], section 3.7), with explicit
664 requirements on the header fields and ordering of those fields.
666 The signature of an AS header field signs a canonicalized form of the
667 ARC Set header field values. The ARC set header field values are
668 supplied to the hash function in increasing instance order, starting
669 at 1, and include the ARC Set being added at the time of Sealing the
670 message.
672 Within an ARC Set, header fields are supplied to the hash function in
673 the following order:
675 1. ARC-Authentication-Results
677 2. ARC-Message-Signature
679 3. ARC-Seal
681 Note that when an Authenticated Received Chain has failed validation,
682 the signing scope for the ARC-Seal is modified as specified in
683 Section 5.1.2.
685 5.1.2. Marking and Sealing "cv=fail" (Invalid) Chains
687 In the case of a failed Authenticated Received Chain, the header
688 fields included in the signature scope of the AS header field b=
689 value MUST only include the ARC Set header fields created by the MTA
690 which detected the malformed chain, as if this newest ARC Set was the
691 only set present.
693 _INFORMATIONAL_: This approach is mandated to handle the case of a
694 malformed or otherwise invalid Authenticated Received Chain. There
695 is no way to generate a deterministic set of AS header fields
696 (Section 5.1.1) in most cases of invalid chains.
698 5.1.3. Only One Authenticated Received Chain Per Message
700 A message can have only one Authenticated Received Chain on it at a
701 time. Once broken, the chain cannot be continued, as the chain of
702 custody is no longer valid and responsibility for the message has
703 been lost. For further discussion of this topic and the design
704 restriction which prevents chain continuation or re-establishment,
705 see [ARC-USAGE].
707 5.1.4. Broad Ability to Seal
709 ARC is not solely intended for perimeter MTAs. Any Internet Mail
710 Handler MAY seal a message by adding a complete ARC set, whether or
711 not they have modified or are aware of having modified the message.
712 For additional information, see Section 7.1.
714 5.1.5. Sealing is Always Safe
716 The utility of an Authenticated Received Chain is limited to very
717 specific cases. Authenticated Received Chains are designed to
718 provide additional information to an Internet Mail Handler when
719 evaluating messages for delivery in the context of authentication
720 failures. Specifically:
722 o Properly adding an ARC Set to a message does not damage or
723 invalidate an existing Authenticated Received Chain.
725 o Sealing an Authenticated Received Chain when a message has not
726 been modified does not negatively affect the chain.
728 o Validating a message exposes no new threat vectors (see
729 Section 9).
731 o An ADMD may choose to Seal all inbound messages whether or not a
732 message has been modified or will be retransmitted.
734 5.2. Validator Actions
736 A validator performs the following steps, in sequence, to process an
737 Authenticated Received Chain. Canonicalization, hash functions, and
738 signature validation methods are imported from [RFC6376] section 5.
740 1. Collect all ARC Sets currently attached to the message.
742 * If there are none, the Chain Validation Status is "none" and
743 the algorithm stops here.
745 * The maximum number of ARC Sets that can be attached to a
746 message is 50. If more than the maximum number exist the
747 Chain Validation Status is "fail" and the algorithm stops
748 here.
750 * In the following algorithm, the maximum discovered ARC
751 instance value is referred to as "N".
753 2. If the Chain Validation Status of the highest instance value ARC
754 Set is "fail", then the Chain Validation status is "fail" and the
755 algorithm stops here.
757 3. Validate the structure of the Authenticated Received Chain. A
758 valid ARC has the following conditions:
760 1. Each ARC Set MUST contain exactly one each of the three ARC
761 header fields (AAR, AMS, and AS).
763 2. The instance values of the ARC Sets MUST form a continuous
764 sequence from 1..N with no gaps or repetition.
766 3. The "cv" value for all ARC-Seal header fields MUST NOT be
767 "fail". For ARC Sets with instance values > 1, the values
768 MUST be "pass". For the ARC Set with instance value = 1, the
769 value MUST be "none".
771 * If any of these conditions are not met, the Chain Validation
772 Status is "fail" and the algorithm stops here.
774 4. Validate the AMS with the greatest instance value (most recent).
775 If validation fails, then the Chain Validation Status is "fail"
776 and the algorithm stops here.
778 5. _OPTIONAL:_ Determine the "oldest-pass" value from the ARC Set by
779 validating each prior AMS beginning with the N-1 and proceeding
780 in decreasing order to the AMS with the instance value of 1:
782 1. If an AMS fails to validate (for instance value "M"), then
783 set the oldest-pass value to the lowest AMS instance value
784 which passed (M+1) and go to the next step (there is no need
785 to check any other (older) AMS header fields). This does not
786 affect the validity of the Authenticated Received Chain.
788 2. If all AMS header fields verify, set the oldest-pass value to
789 zero (0).
791 6. Validate each AS beginning with the greatest instance value and
792 proceeding in decreasing order to the AS with the instance value
793 of 1. If any AS fails to validate, the Chain Validation Status
794 is "fail" and the algorithm stops here.
796 7. If the algorithm reaches this step, then the Chain Validation
797 Status is "pass", and the algorithm is complete.
799 The end result of this Validation algorithm SHOULD be included within
800 the Authentication-Results header field for the ADMD.
802 As with a DKIM signature ([RFC6376] section 6.3) which fails
803 verification, a message with an Authenticated Received Chain with a
804 Chain Validation status of "fail" MUST be treated the same as a
805 message with no Authenticated Received Chain.
807 _INFORMATIONAL_: Recipients of an invalid or failing Authenticated
808 Received Chain can use that information as part of a wider handling
809 context. ARC adoption cannot be assumed by intermediaries; many
810 intermediaries will continue to modify messages without adding ARC
811 Seals.
813 5.2.1. All Failures Are Permanent
815 Authenticated Received Chains represent the traversal of messages
816 through one or more intermediaries. All errors, including DNS
817 failures, become unrecoverable and are considered permanent.
819 Any error validating an Authenticated Received Chain results in a
820 Chain Validation Status of "fail". For further discussion of this
821 topic and the design restriction which prevents chain continuation or
822 re-establishment, see [ARC-USAGE].
824 5.2.2. Responding to ARC Validation Failures During the SMTP
825 Transaction
827 If an ARC Validator determines that the incoming message fails ARC
828 validation, the Validator MAY signal the breakage through the
829 extended SMTP response code 5.7.29 "ARC validation failure" and
830 corresponding SMTP basic response code. Because ARC failures are
831 likely only to be detected in the context of other underlying
832 authentication mechanism failures, validators MAY use the more
833 general 5.7.26 "Multiple authentication checks failed" instead of the
834 ARC-specific code.
836 6. Communication of Validation Results
838 Chain Validation Status (described in Section 4.4) is communicated
839 via Authentication-Results (and AAR) header fields using the auth
840 method "arc". This auth method is described in Section 10.1.
842 If necessary data is available, the ptypes and properties defined in
843 Section 10.2 SHOULD be recorded in an Authentication-Results header
844 field:
846 o smtp.remote-ip - The address of the connection-initiating SMTP
847 server, from which the message is being relayed.
849 o header.oldest-pass - The instance number of the oldest AMS that
850 still validates, or 0 if all pass.
852 7. Use Cases
854 This section explores several messaging handling use cases that are
855 addressed by ARC.
857 7.1. Communicate Authentication Assessment Across Trust Boundaries
859 When an intermediary ADMD adds an ARC Set to a message's
860 Authenticated Received Chain (or creates the initial ARC Set), the
861 ADMD communicates its authentication assessment to the next ARC-
862 participating ADMD in the message handling path.
864 If ARC-enabled ADMDs are trusted, Authenticated Received Chains can
865 be used to bridge administrative boundaries.
867 7.1.1. Message Scanning Services
869 Message services are available to perform anti-spam, anti-malware,
870 and anti-phishing scanning. Such services typically remove malicious
871 content, replace HTTP links in messages with sanitized links, and/or
872 attach footers to messages advertising the abilities of the message
873 scanning service. These modifications almost always break signature-
874 based authentication (such as DKIM).
876 Scanning services typically require clients to point MX records of an
877 Internet domain to the scanning service. Messages destined for the
878 Internet domain are initially delivered to the scanning service.
879 Once scanning is performed, messages are then routed to the client's
880 own mail handling infrastructure. Re-routing messages in this way
881 almost always breaks path-based authentication (such as SPF).
883 Message scanning services can attach Authenticated Received Chains to
884 messages to communicate authentication assessment into client ADMDs.
885 Clients can then benefit from the message scanning service while
886 processing messages as if the client's infrastructure were the
887 original destination of the Internet domain's MX record.
889 7.1.2. Multi-tier MTA Processing
891 Large message processing infrastructure is often divided into several
892 processing tiers that can break authentication information between
893 tiers. For example, a large site may maintain a cluster of MTAs
894 dedicated to connection handling and enforcement of IP-based
895 reputation filtering. A secondary cluster of MTAs may be dedicated
896 and optimized for content-based processing of messages.
898 Authenticated Received Chains can be used to communicate
899 authentication assessment between processing tiers.
901 7.1.3. Mailing Lists
903 Mailing lists take delivery of messages and re-post them to
904 subscribers. A full description of authentication-related mailing
905 list issues can be found in [RFC7960] Section 3.2.3.
907 Mailing list services can implement ARC to convey the authentication
908 assessment of posted messages sent to the list's subscriber base.
909 The ADMDs of the mailing list subscribers can then use the
910 Authenticated Received Chain to determine the authentication
911 assessment of the original message before mailing list handling.
913 7.2. Inform Message Disposition Decisions
915 Intermediaries often break authentication through content
916 modification, interfere with path-based authentication (such as SPF),
917 and strip authentication results (if an MTA removes Authentication-
918 Results header fields).
920 Authenticated Received Chains allow ARC Validators to:
922 1. identify ARC-enabled ADMDs that break authentication while
923 processing messages;
925 2. gain extended visibility into the authentication-preserving
926 abilities of ADMDs that relay messages into ARC-enabled ADMDs.
928 Through the collection of ARC-related data, an ADMD can identify
929 handling paths that have broken authentication.
931 An Authenticated Received Chain allows an Internet Mail Handler to
932 potentially base decisions of message disposition on authentication
933 assessments provided by different ADMDs.
935 7.2.1. DMARC Local Policy Overrides
937 DMARC introduces a policy model where Domain Owners can request email
938 receivers to reject or quarantine messages that fail DMARC alignment.
939 Interoperability issues between DMARC and indirect email flows are
940 documented in [RFC7960].
942 Authenticated Received Chains allow DMARC processors to consider
943 authentication assessments provided by other ADMDs. As a matter of
944 local policy, a DMARC processor MAY choose to accept the
945 authentication assessments provided by an Authenticated Received
946 Chain when determining if a message is DMARC compliant.
948 When an Authenticated Received Chain is used to determine message
949 disposition, the DMARC processor can communicate this local policy
950 decision to Domain Owners as described in Section 7.2.2.
952 7.2.2. DMARC Reporting
954 DMARC-enabled receivers indicate when ARC Validation influences
955 DMARC-related local policy decisions. When an ARC-enabled handler
956 generates a DMARC report, it MAY indicate the influence of ARC on
957 their local policy decision(s) by adding a reason of "local_policy"
958 with a comment string (per [RFC7489] Appendix C) containing a list of
959 data discovered during ARC Validation, which at a minimum includes:
961 o the Chain Validation Status,
963 o the domain and selector for each AS,
965 o the originating IP address from the first ARC Set:
967 EXAMPLE:
969
970 none
971 fail
972 fail
973
974 local_policy
975 arc=pass as[2].d=d2.example as[2].s=s2
976 as[1].d=d1.example as[1].s=s3
977 remote-ip[1]=10.10.10.13
978
979
981 In the above example DMARC XML reporting fragment, data relating to
982 specific validated ARC Sets are enumerated using array syntax (eg,
983 "as[2]" means AS header field with instance value of 2). d2.example
984 is the Sealing domain for ARC Set #2 (i=2) and d1.example is the
985 Sealing domain for ARC Set #1 (i=1).
987 Depending on the reporting practices of intermediate message
988 handlers, Domain Owners may receive multiple DMARC reports for a
989 single message. Receivers of DMARC reports should be aware of this
990 behaviour and make the necessary accommodations.
992 8. Privacy Considerations
994 The Authenticated Received Chain provides a verifiable record of the
995 handlers for a message. This record may include Personally
996 Identifiable Information such as IP address(es) and domain names.
997 Such information is also included in existing non-ARC related header
998 fields such as the "Received" header fields.
1000 9. Security Considerations
1002 The Security Considerations of [RFC6376] and [I-D-7601bis] apply
1003 directly to this specification.
1005 As with other domain authentication technologies (such as SPF, DKIM,
1006 and DMARC), ARC makes no claims about the semantic content of
1007 messages.
1009 9.1. Increased Header Field Size
1011 Inclusion of Authenticated Received Chains into messages may cause
1012 issues for older or constrained MTAs due to increased total header
1013 field size. Large header field blocks, in general, may cause
1014 failures to deliver or other outage scenarios for such MTAs. ARC
1015 itself would not cause problems.
1017 9.2. DNS Operations
1019 The validation of an Authenticated Received Chain composed of N ARC
1020 Sets can require up to 2*N DNS queries (not including any DNS
1021 redirection mechanisms which can increase the total number of
1022 queries). This leads to two considerations:
1024 1. An attacker can send a message to an ARC participant with a
1025 concocted sequence of ARC Sets bearing the domains of intended
1026 victims, and all of them will be queried by the participant until
1027 a failure is discovered. DNS caching and the difficulty of
1028 forging the signature values should limit the extent of this load
1029 to domains under control of the attacker. Query traffic pattern
1030 analysis may expose information about downstream validating ADMD
1031 infrastructure.
1033 2. DKIM only performs one DNS query per signature, while ARC can
1034 introduce many (per chain). Absent caching, slow DNS responses
1035 can cause SMTP timeouts; and backlogged delivery queues on
1036 Validating systems. This could be exploited as a DoS attack.
1038 9.3. Message Content Suspicion
1040 Recipients are cautioned to treat messages bearing Authenticated
1041 Received Chains with the same suspicion applied to all other
1042 messages. This includes appropriate content scanning and other
1043 checks for potentially malicious content.
1045 ARC authenticates the identity of some email handling actors. It
1046 does not make any assessment of their trustworthiness.
1048 Just as passing message authentication is not an indication of
1049 message safety, forwarding that information through the mechanism of
1050 ARC is also not an indication of message safety. Even if all ARC-
1051 enabled ADMDs are trusted, ADMDs may have become compromised, may
1052 miss unsafe content, or may not properly authenticate messages.
1054 9.4. Message Sealer Suspicion
1056 Recipients are cautioned to treat every Sealer of the ARC Chain with
1057 suspicion. Just as with a validated DKIM signature, responsibility
1058 for message handling is attributed to the Sealing domain, but whether
1059 or not that Sealer is a malicious actor is out of scope of the
1060 authentication mechanism. Since ARC aids message delivery in the
1061 event of an authentication failure, ARC Sealers should be treated
1062 with suspicion, so that a malicious actor cannot Seal spam or other
1063 fraudulent messages to aid their delivery, too.
1065 9.5. Replay Attacks
1067 Since ARC inherits heavily from DKIM, it has similar attack vectors.
1068 In particular, the Replay Attack described in [RFC6376] section 8.6
1069 is potentially amplified by ARC's chained statuses. In an ARC replay
1070 attack, a malicious actor would take an intact and passing ARC Chain,
1071 and then resend it to many recipients without making any
1072 modifications that invalidate the latest AMS or AS. The impact to a
1073 receiver would be more DNS lookups and signature evaluations. This
1074 scope of this attack can be limited by caching DNS queries and
1075 following the same signing scope guidance from [RFC6376] section
1076 5.4.1.
1078 10. IANA Considerations
1080 [[ *Note to the RFC Editors:* "dkim - header - s" is defined in
1081 [I-D-7601bis]. Please adjust the list below as appropriate. ]]
1083 This draft introduces three new headers fields and updates the Email
1084 Authentication Parameters registry with one new authentication method
1085 and several status codes.
1087 10.1. Email Authentication Results Names Registry Update
1089 This draft adds one Auth Method with three Codes to the IANA "Email
1090 Authentication Result Names" registry:
1092 o Auth Method : arc
1093 Code: "none", "pass", "fail"
1094 Specification: this document 2.2
1095 Status: active
1097 10.2. Email Authentication Methods Registry Update
1099 This draft adds several new items to the Email Authentication Methods
1100 registry, most recently defined in [I-D-7601bis]:
1102 o Method: arc
1103 Definition: this document
1104 ptype: smtp
1105 Property: remote-ip
1106 Value: IP address of originating SMTP connection
1107 Status: active
1108 Version: 1
1110 o Method: arc
1111 Definition: this document
1112 ptype: header
1113 Property: oldest-pass
1114 Value: The instance id of the oldest validating AMS, or 0 if they
1115 all pass (see Section 5.2)
1116 Status: active
1117 Version: 1
1119 o Method: dkim
1120 Definition: [I-D-7601bis]
1121 ptype: header
1122 Property: s
1123 Value: value of signature "s" tag
1124 Status: active
1125 Version: 1
1127 10.3. Definitions of the ARC header fields
1129 This specification adds three new header fields to the "Permanent
1130 Message Header Field Registry", as follows:
1132 o Header field name: ARC-Seal
1133 Applicable protocol: mail
1134 Status: Experimental
1135 Author/Change controller: IETF
1136 Specification document(s): this document
1137 Related information: [RFC6376]
1139 o Header field name: ARC-Message-Signature
1140 Applicable protocol: mail
1141 Status: Experimental
1142 Author/Change controller: IETF
1143 Specification document(s): this document
1144 Related information: [RFC6376]
1146 o Header field name: ARC-Authentication-Results
1147 Applicable protocol: mail
1148 Status: Experimental
1149 Author/Change controller: IETF
1150 Specification document(s): this document
1151 Related information: [I-D-7601bis]
1153 10.4. New Enhanced Status Code - ARC Validation
1155 The following value should be added to the [ENHANCED-STATUS]
1156 registry, as follows:
1158 o Code: X.7.29
1159 Sample Text: ARC validation failure
1160 Associated basic status code: 550
1161 Description: This status code may be returned when a message fails
1162 ARC validation
1163 Reference: this document
1164 Submitter: K. Andersen
1165 Change controller: IESG
1167 11. Experimental Considerations
1169 The ARC protocol is designed to address common interoperability
1170 issues introduced by intermediate message handlers. Interoperability
1171 issues are described in [RFC6377] and [RFC7960].
1173 As the ARC protocol is implemented by Internet Mail Handlers over
1174 time, the following should be evaluated in order to determine the
1175 success of the protocol in accomplishing the intended benefits.
1177 11.1. Success Consideration
1179 In an attempt to deliver legitimate messages that users desire, many
1180 receivers use heuristic-based methods to identify messages that
1181 arrive via indirect delivery paths.
1183 ARC will be a success if the presence of Authenticated Received
1184 Chains allows for improved decision making when processing legitimate
1185 messages, specifically resulting in equal or better delivery rates
1186 than achieve through the use of heuristic approaches.
1188 11.2. Failure Considerations
1190 ARC should function without introducing significant new vectors for
1191 abuse (see Section 9). If unforeseen vectors are enabled by ARC,
1192 then this protocol will be a failure. Note that weaknesses inherent
1193 in the mail protocols ARC is built upon (such as DKIM replay attacks
1194 and other known issues) are not new vectors which can be attributed
1195 to this specification.
1197 11.3. Open Questions
1199 The following open questions are academic and have no clear answer at
1200 the time of the development of the protocol. However, additional
1201 deployments should be able to gather the necessary data to answer
1202 some or all of them.
1204 11.3.1. Value of the ARC-Seal (AS) Header Field
1206 Data should be collected to show if the ARC-Seal (AS) provides value
1207 beyond the ARC Message Signature (AMS) for either making delivery
1208 decisions or catching malicious actors trying to craft or replay
1209 malicious chains.
1211 11.3.2. Usage and/or signals from multiple selectors and/or domains in
1212 ARC sets
1214 Any selectors and/or (sub)domains (under the control of the sealing
1215 ADMD) may be used for ARC header field signatures.
1217 While implementers may choose to use various selectors and/or domains
1218 for ARC set header fields, no compelling argument for or against such
1219 usage has been made within the working group. As such we have chosen
1220 to allow maximum freedom for the experimental definition of this
1221 protocol.
1223 Wider deployment experience and higher volumes of traffic may show
1224 whether this is useful.
1226 11.3.3. DNS Overhead
1228 Longer Authenticated Received Chains will require more queries to
1229 retrieve the keys for validating the chain. While this is not
1230 believed to be a security issue (see Section 9.2), it is unclear how
1231 much overhead will truly be added. This is similar to some of the
1232 initial processing and query load concerns which were debated at the
1233 time of the DKIM specification development.
1235 Data should be collected to better understand usable length and
1236 distribution of lengths found in valid Authenticated Received Chains
1237 along with the DNS impact of processing Authenticated Received
1238 Chains.
1240 An effective operational maximum will have to be developed through
1241 deployment experience in the field.
1243 11.3.4. What Trace Information is Valuable
1245 There are several edge cases where the information in the AAR can
1246 make the difference between message delivery or rejection. For
1247 example, if there is a well known mailing list that seals with ARC
1248 but doesn't do its own initial DMARC enforcement, an Internet Mail
1249 Handler with this knowledge could make a delivery decision based upon
1250 the authentication information it sees in the corresponding AAR
1251 header field.
1253 Certain trace information in the AAR is useful/necessary in the
1254 construction of DMARC reports.
1256 Further, certain receivers believe the entire set of trace
1257 information would be valuable to feed into machine learning systems
1258 to identify fraud and/or provide other signals related to message
1259 delivery.
1261 At this point, however, it is unclear what trace information will be
1262 valuable for all receivers, regardless of size.
1264 Data should be collected on what trace information receivers are
1265 using that provides useful signals that affect deliverability, and
1266 what portions of the trace data are left untouched or provide no
1267 useful information.
1269 Since many such systems are intentionally proprietary or confidential
1270 to prevent gaming by abusers, it may not be viable to reliably answer
1271 this particular question. The evolving nature of attacks can also
1272 shift the landscape of "useful" information over time.
1274 12. Implementation Status
1276 [[ Note to the RFC Editor: Please remove this section before
1277 publication along with the reference to [RFC7942]. ]]
1278 This section records the status of known implementations of the
1279 protocol defined by this specification at the time of posting of this
1280 Internet-Draft, and is based on a proposal described in [RFC7942].
1281 The description of implementations in this section is intended to
1282 assist the IETF in its decision processes in progressing drafts to
1283 RFCs. Please note that the listing of any individual implementation
1284 here does not imply endorsement by the IETF. Furthermore, no effort
1285 has been spent to verify the information presented here that was
1286 supplied by IETF contributors. This is not intended as, and must not
1287 be construed to be, a catalog of available implementations or their
1288 features. Readers are advised to note that other implementations may
1289 exist.
1291 This information is known to be correct as of the eighth
1292 interoperability test event which was held on 2018-03-17 at IETF101.
1294 For a few of the implementations, later status information was
1295 available as of August 2018.
1297 12.1. GMail test reflector and incoming validation
1299 Organization: Google
1300 Description: Internal production implementation with both debug
1301 analysis and validating + sealing pass-through function
1302 Status of Operation: Production - Incoming Validation
1303 Coverage: Full spec implemented as of [ARC-DRAFT-14]
1304 Licensing: Proprietary - Internal only
1305 Implementation Notes:
1307 o Full functionality was demonstrated during the interop testing on
1308 2018-03-17.
1310 Contact Info: arc-discuss@dmarc.org [1]
1312 12.2. AOL test reflector and internal tagging
1314 Organization: AOL
1315 Description: Internal prototype implementation with both debug
1316 analysis and validating + sealing pass-through function
1317 Status of Operation: Beta
1318 Coverage: ARC Chain validity status checking is operational, but only
1319 applied to email addresses enrolled in the test program. This system
1320 conforms to [ARC-DRAFT-05]
1321 Licensing: Proprietary - Internal only
1322 Implementation Notes:
1324 o 2017-07-15: Full functionality verified during the interop
1325 testing.
1327 o 2018-06: Partially retired but still accessible by special request
1328 due to the in process evolution of the AOL mail infrastructure to
1329 the integrated OATH environment. The implementation was based on
1330 the Apache James DKIM code base and may be contributed back to
1331 that project in the future.
1333 Contact Info: arc-discuss@dmarc.org [2]
1335 12.3. dkimpy
1337 Organization: dkimpy developers/Scott Kitterman
1338 Description: Python DKIM package
1339 Status of Operation: Production
1340 Coverage:
1342 o 2017-07-15: The internal test suite is incomplete, but the command
1343 line developmental version of validator was demonstrated to
1344 interoperate with the Google and AOL implementations during the
1345 interop on 2017-07-15 and the released version passes the tests in
1346 [ARC-TEST] arc_test_suite [3] with both python and python3.
1348 Licensing: Open/Other (same as dkimpy package = BCD version 2)
1349 Contact Info: https://launchpad.net/dkimpy
1351 12.4. OpenARC
1353 Organization: TDP/Murray Kucherawy
1354 Description: Implementation of milter functionality related to the
1355 OpenDKIM and OpenDMARC packages
1356 Status of Operation: Beta
1357 Coverage: Built to support [ARC-DRAFT-14]
1358 Licensing: Open/Other (same as OpenDKIM and OpenDMARC packages)
1359 Implementation Notes:
1361 o Known issues have been resolved with release X
1363 Contact Info: arc-discuss@dmarc.org [4], openarc-users@openarc.org
1364 [5]
1366 12.5. Mailman 3.x patch
1368 Organization: Mailman development team
1369 Description: Integrated ARC capabilities within the Mailman 3.2
1370 package
1371 Status of Operation: Patch submitted
1372 Coverage: Based on OpenARC
1373 Licensing: Same as mailman package - GPL
1374 Implementation Notes:
1376 o Appears to work properly in at least one beta deployment, but
1377 waiting on acceptance of the pull request into the mainline of
1378 mailman development
1380 Contact Info: https://www.gnu.org/software/mailman/contact.html
1382 12.6. Copernica/MailerQ web-based validation
1384 Organization: Copernica
1385 Description: Web-based validation of ARC-signed messages
1386 Status of Operation: Beta
1387 Coverage: Built to support [ARC-DRAFT-05]
1388 Licensing: On-line usage only
1389 Implementation Notes:
1391 o Released 2016-10-24
1393 o Requires full message content to be pasted into a web form found
1394 at http://arc.mailerq.com/ (warning - https is not supported).
1396 o An additional instance of an ARC signature can be added if one is
1397 willing to paste a private key into an unsecured web form.
1399 o 2017-07-15: Testing shows that results match the other
1400 implementations listed in this section.
1402 Contact Info: https://www.copernica.com/
1404 12.7. Rspamd
1406 Organization: Rspamd community
1407 Description: ARC signing and verification module
1408 Status of Operation: Production, though deployment usage is unknown
1409 Coverage: Built to support [ARC-DRAFT-14]
1410 Licensing: Open source
1411 Implementation Notes:
1413 o 2017-06-12: Released with version 1.6.0
1415 o 2017-07-15: Testing during the interop showed that the validation
1416 functionality interoperated with the Google, AOL, dkimpy and
1417 MailerQ implementations
1419 Contact Info: https://rspamd.com/doc/modules/arc.html and
1420 https://github.com/vstakhov/rspamd
1422 12.8. PERL MAIL::DKIM module
1424 Organization: FastMail
1425 Description: Email domain authentication (sign and/or verify) module,
1426 previously included SPF / DKIM / DMARC, now has ARC added
1427 Status of Operation: Production, deployment usage unknown
1428 Coverage: Built to support [ARC-DRAFT-10]
1429 Licensing: Open Source
1430 Implementation Notes:
1432 o 2017-12-15: v0.50 released with full test set passing for ARC
1434 Contact Info: http://search.cpan.org/~mbradshaw/Mail-DKIM-0.50/
1436 12.9. PERL Mail::Milter::Authentication module
1438 Organization: FastMail
1439 Description: Email domain authentication milter, uses MAIL::DKIM (see
1440 above)
1441 Status of Operation: Initial validation completed during IETF99
1442 hackathon with some follow-on work during the week
1443 Coverage: Built to support [ARC-DRAFT-14]
1444 Licensing: Open Source
1445 Implementation Notes:
1447 o 2017-07-15: Validation functionality which interoperates with
1448 Gmail, AOL, dkimpy was demonstrated; later in the week of IETF99,
1449 the signing functionality was reported to be working
1451 o 2017-07-20: ARC functionality has not yet been pushed back to the
1452 github repo but should be showing up soon
1454 Contact Info: https://github.com/fastmail/authentication_milter
1456 12.10. Sympa List Manager
1458 Organization: Sympa Dev Community
1459 Description: Work in progress
1460 Status of Operation: Work in progress
1461 Coverage: unknown
1462 Licensing: open source
1463 Implementation Notes:
1465 o 2018-01-05: Tracked as https://github.com/sympa-community/sympa/
1466 issues/153
1468 Contact Info: https://github.com/sympa-community
1470 12.11. Oracle Messaging Server
1472 Organization: Oracle
1473 Description:
1474 Status of Operation: Initial development work during IETF99
1475 hackathon. Framework code is complete, crypto functionality requires
1476 integration with libsodium
1477 Coverage: Work in progress
1478 Licensing: Unknown
1479 Implementation Notes:
1481 o 2018-03: Protocol handling components are completed, but crypto is
1482 not yet functional.
1484 Contact Info: Chris Newman, Oracle
1486 12.12. MessageSystems Momentum and PowerMTA platforms
1488 Organization: MessageSystems/SparkPost
1489 Description: OpenARC integration into the LUA-enabled Momentum
1490 processing space
1491 Status of Operation: Beta
1492 Coverage: Same as OpenARC
1493 Licensing: Unknown
1494 Implementation Notes:
1496 o Initial deployments for validation expected in mid-2018.
1498 Contact Info: TBD
1500 12.13. Exim
1502 Organization: Exim developers
1503 Status of Operation: Operational; requires specific enabling for
1504 compile.
1505 Coverage: Full spec implemented as of [ARC-DRAFT-13]
1506 Licensing: GPL
1507 Contact Info: exim-users@exim.org
1508 Implementation notes:
1510 o Implemented as of Exim 4.91
1512 12.14. Halon MTA
1514 Organization: Halon
1515 Status of Operation: Operational as of May 2018
1516 Coverage: Full spec implemented as of [ARC-DRAFT-14]
1517 Licensing: Commercial, trial version available for download
1518 Contact Info: https://halon.io
1519 Implementation notes:
1521 o GPL'd library with ARC capabilities: https://github.com/halon/
1522 libdkimpp
1524 12.15. IIJ
1526 Organization: Internet Initiative Japan (IIJ) Status of Operation:
1527 Operational as of October 2018
1528 Coverage: Full spec implemented as of this document
1529 Licensing: Internal
1530 Contact Info: https://www.iij.ad.jp/en/
1531 Implementation notes:
1533 o Internal MTA implementation validated during the ARC interop
1534 exercise in mid-October 2018
1536 13. References
1538 13.1. Normative References
1540 [draft-levine-eaiauth]
1541 Levine, J., "E-mail Authentication for Internationalized
1542 Mail", August 2018, .
1545 [I-D-7601bis]
1546 Kucherawy, M., "Message Header Field for Indicating
1547 Message Authentication Status", February 2018,
1548 .
1551 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1552 Requirement Levels", BCP 14, RFC 2119,
1553 DOI 10.17487/RFC2119, March 1997,
1554 .
1556 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
1557 Specifications: ABNF", STD 68, RFC 5234,
1558 DOI 10.17487/RFC5234, January 2008,
1559 .
1561 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
1562 DOI 10.17487/RFC5322, October 2008,
1563 .
1565 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
1566 DOI 10.17487/RFC5598, July 2009,
1567 .
1569 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
1570 "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
1571 RFC 6376, DOI 10.17487/RFC6376, September 2011,
1572 .
1574 [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and
1575 Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377,
1576 September 2011, .
1578 [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized
1579 Email Headers", RFC 6532, DOI 10.17487/RFC6532, February
1580 2012, .
1582 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
1583 Authorizing Use of Domains in Email, Version 1", RFC 7208,
1584 DOI 10.17487/RFC7208, April 2014,
1585 .
1587 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
1588 RFC 7405, DOI 10.17487/RFC7405, December 2014,
1589 .
1591 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1592 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1593 May 2017, .
1595 13.2. Informative References
1597 [ARC-DRAFT-05]
1598 Andersen, K., "Authenticated Received Chain (ARC) Protocol
1599 (I-D-05)", n.d., .
1602 [ARC-DRAFT-10]
1603 Andersen, K., "Authenticated Received Chain (ARC) Protocol
1604 (I-D-10)", n.d., .
1607 [ARC-DRAFT-13]
1608 Andersen, K., "Authenticated Received Chain (ARC) Protocol
1609 (I-D-13)", n.d., .
1612 [ARC-DRAFT-14]
1613 Andersen, K., "Authenticated Received Chain (ARC) Protocol
1614 (I-D-14)", n.d., .
1617 [ARC-MULTI]
1618 Andersen, K., "Using Multiple Signing Algorithms with
1619 ARC", June 2018, .
1622 [ARC-TEST]
1623 Blank, S., "ARC Test Suite", January 2017,
1624 .
1626 [ARC-USAGE]
1627 Jones, S., Adams, T., Rae-Grant, J., and K. Andersen,
1628 "Recommended Usage of the ARC Headers", April 2018,
1629 .
1632 [ENHANCED-STATUS]
1633 "IANA SMTP Enhanced Status Codes", n.d.,
1634 .
1637 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
1638 Message Authentication, Reporting, and Conformance
1639 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
1640 .
1642 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
1643 Code: The Implementation Status Section", BCP 205,
1644 RFC 7942, DOI 10.17487/RFC7942, July 2016,
1645 .
1647 [RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky,
1648 E., Ed., and K. Andersen, Ed., "Interoperability Issues
1649 between Domain-based Message Authentication, Reporting,
1650 and Conformance (DMARC) and Indirect Email Flows",
1651 RFC 7960, DOI 10.17487/RFC7960, September 2016,
1652 .
1654 13.3. URIs
1656 [1] mailto:arc-discuss@dmarc.org
1658 [2] mailto:arc-discuss@dmarc.org
1660 [3] https://github.com/Valimail/arc_test_suite
1662 [4] mailto:arc-discuss@dmarc.org
1664 [5] mailto:openarc-users@openarc.org
1666 [6] mailto:dmarc@ietf.org
1668 [7] mailto:arc-discuss@dmarc.org
1670 [8] mailto:arc-interop@dmarc.org
1672 [9] https://arc-spec.org
1674 Appendix A. Design Requirements
1676 The specification of the ARC framework is driven by the following
1677 high-level goals, security considerations, and practical operational
1678 requirements.
1680 A.1. Primary Design Criteria
1682 o Provide a verifiable "chain of custody" for email messages;
1684 o Not require changes for originators of email;
1686 o Support the verification of the ARC header field set by each hop
1687 in the handling chain;
1689 o Work at Internet scale; and
1691 o Provide a trustable mechanism for the communication of
1692 Authentication-Results across trust boundaries.
1694 A.2. Out of Scope
1696 ARC is not a trust framework. Users of the ARC header fields are
1697 cautioned against making unsubstantiated conclusions when
1698 encountering a "broken" ARC sequence.
1700 Appendix B. Example Usage
1702 The following message is an example of one which has passed through
1703 several intermediary handlers, some of which have modified the
1704 message and others which have not:
1706 Return-Path:
1707 Received: from example.org (example.org [208.69.40.157])
1708 by gmail.example with ESMTP id d200mr22663000ykb.93.1421363207
1709 for ; Thu, 14 Jan 2015 15:02:40 -0800 (PST)
1710 Received: from segv.d1.example (segv.d1.example [72.52.75.15])
1711 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
1712 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
1713 (envelope-from jqd@d1.example)
1714 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1715 (authenticated bits=0)
1716 by segv.d1.example with ESMTP id t0FN4a8O084569;
1717 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1718 (envelope-from jqd@d1.example)
1719 Received: from mail-ob0-f188.google.example (mail-ob0-f188.google.example
1720 [208.69.40.157]) by clochette.example.org with ESMTP id
1721 d200mr22663000ykb.93.1421363268
1722 for ; Thu, 14 Jan 2015 15:03:15 -0800 (PST)
1723 ARC-Seal: i=3; a=rsa-sha256; cv=pass; d=clochette.example.org; s=
1724 clochette; t=12345; b=CU87XzXlNlk5X/yW4l73UvPUcP9ivwYWxyBWcVrRs7
1725 +HPx3K05nJhny2fvymbReAmOA9GTH/y+k9kEc59hAKVg==
1726 ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed; d=
1727 clochette.example.org; h=message-id:date:from:to:subject; s=
1728 clochette; t=12345; bh=KWSe46TZKCcDbH4klJPo+tjk5LWJnVRlP5pvjXFZY
1729 LQ=; b=o71vwyLsK+Wm4cOSlirXoRwzEvi0vqIjd/2/GkYFYlSd/GGfKzkAgPqxf
1730 K7ccBMP7Zjb/mpeggswHjEMS8x5NQ==
1731 ARC-Authentication-Results: i=3; clochette.example.org; spf=fail
1732 smtp.from=jqd@d1.example; dkim=fail (512-bit key)
1733 header.i=@d1.example; dmarc=fail; arc=pass (as.2.gmail.example=pass,
1734 ams.2.gmail.example=pass, as.1.lists.example.org=pass,
1735 ams.1.lists.example.org=fail (message has been altered))
1736 Authentication-Results: clochette.example.org; spf=fail
1737 smtp.from=jqd@d1.example; dkim=fail (512-bit key)
1738 header.i=@d1.example; dmarc=fail; arc=pass (as.2.gmail.example=pass,
1739 ams.2.gmail.example=pass, as.1.lists.example.org=pass,
1740 ams.1.lists.example.org=fail (message has been altered))
1741 ARC-Seal: i=2; a=rsa-sha256; cv=pass; d=gmail.example; s=20120806; t=
1742 12345; b=Zpukh/kJL4Q7Kv391FKwTepgS56dgHIcdhhJZjsalhqkFIQQAJ4T9BE
1743 8jjLXWpRNuh81yqnT1/jHn086RwezGw==
1744 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=
1745 gmail.example; h=message-id:date:from:to:subject; s=20120806; t=
1746 12345; bh=KWSe46TZKCcDbH4klJPo+tjk5LWJnVRlP5pvjXFZYLQ=; b=CVoG44
1747 cVZvoSs2mMig2wwqPaJ4OZS5XGMCegWqQs1wvRZJS894tJM0xO1RJLgCPsBOxdA5
1748 9WSqI9s9DfyKDfWg==
1749 ARC-Authentication-Results: i=2; gmail.example; spf=fail
1750 smtp.from=jqd@d1.example; dkim=fail (512-bit key)
1751 header.i=@example.org; dmarc=fail; arc=pass (as.1.lists.example.org=pass,
1752 ams.1.lists.example.org=pass)
1753 ARC-Seal: i=1; a=rsa-sha256; cv=none; d=lists.example.org; s=dk-lists;
1754 t=12345; b=TlCCKzgk3TrAa+G77gYYO8Fxk4q/Ml0biqduZJeOYh6+0zhwQ8u/
1755 lHxLi21pxu347isLSuNtvIagIvAQna9a5A==
1757 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=
1758 lists.example.org; h=message-id:date:from:to:subject; s=
1759 dk-lists; t=12345; bh=KWSe46TZKCcDbH4klJPo+tjk5LWJnVRlP5pvjXFZYL
1760 Q=; b=DsoD3n3hiwlrN1ma8IZQFgZx8EDO7Wah3hUjIEsYKuShRKYB4LwGUiKD5Y
1761 yHgcIwGHhSc/4+ewYqHMWDnuFxiQ==
1762 ARC-Authentication-Results: i=1; lists.example.org; spf=pass smtp.mfrom=jqd@d1.example;
1763 dkim=pass (512-bit key) header.i=@d1.example;
1764 dmarc=pass
1765 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=d1.example; h=
1766 message-id:date:from:to:subject; s=origin2015; bh=bIxxaeIQvmOBdT
1767 AitYfSNFgzPP4=; b=qKjd5fYibKXWWIcMKCgRYuo1vJ2fD+IAQPjX+uamXIGY2Q
1768 0HjQ+Lq3/yHzG3JHJp6780/nKQPOWt2UDJQrJkEA==
1769 Message-ID: <54B84785.1060301@d1.example>
1770 Date: Thu, 14 Jan 2015 15:00:01 -0800
1771 From: John Q Doe
1772 To: arc@dmarc.example
1773 Subject: [List 2] Example 1
1775 Hey gang,
1776 This is a test message.
1777 --J.
1779 Appendix C. Acknowledgements
1781 This draft originated with the work of OAR-Dev Group.
1783 The authors thank all of the OAR-Dev and the subsequent DMARC-WG
1784 group for the ongoing help and though-provoking discussions from all
1785 the participants, especially: Alex Brotman, Brandon Long, Dave
1786 Crocker, Elizabeth Zwicky, Franck Martin, Greg Colburn, J. Trent
1787 Adams, John Rae-Grant, Mike Hammer, Mike Jones, Steve Jones, Terry
1788 Zink, Tim Draegen, Gene Shuman, Scott Kitterman, Bron Gondwana.
1790 Grateful appreciation is extended to the people who provided feedback
1791 through the discuss mailing list.
1793 Appendix D. Comments and Feedback
1795 Please address all comments, discussions, and questions to
1796 dmarc@ietf.org [6]. Earlier discussions can be found at arc-
1797 discuss@dmarc.org [7]. Interop discussions planning can be found at
1798 arc-interop@dmarc.org [8].
1800 Some introductory material for less technical people can be found at
1801 https://arc-spec.org [9].
1803 Authors' Addresses
1805 Kurt Andersen
1806 LinkedIn
1807 1000 West Maude Ave
1808 Sunnyvale, California 94085
1809 USA
1811 Email: kurt+ietf@drkurt.com
1813 Brandon Long (editor)
1814 Google
1816 Email: blong@google.com
1818 Seth Blank (editor)
1819 Valimail
1821 Email: seth@valimail.com
1823 Murray Kucherawy (editor)
1824 TDP
1826 Email: superuser@gmail.com