idnits 2.17.1
draft-ietf-dmarc-arc-protocol-15.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 :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (June 24, 2018) is 2133 days in the past. Is this
intentional?
Checking references for intended status: Experimental
----------------------------------------------------------------------------
-- Looks like a reference, but probably isn't: '2' on line 1483
-- Looks like a reference, but probably isn't: '1' on line 1481
== Missing Reference: 'I-D.ARC' is mentioned on line 1057, but not defined
-- Looks like a reference, but probably isn't: '3' on line 1485
-- Looks like a reference, but probably isn't: '4' on line 1487
-- Looks like a reference, but probably isn't: '5' on line 1532
-- Looks like a reference, but probably isn't: '6' on line 1556
-- Looks like a reference, but probably isn't: '7' on line 1557
-- Looks like a reference, but probably isn't: '8' on line 1558
-- Looks like a reference, but probably isn't: '9' on line 1561
== Unused Reference: 'RFC7601' is defined on line 1405, but no explicit
reference was found in the text
** Obsolete normative reference: RFC 7601 (Obsoleted by RFC 8601)
== Outdated reference: A later version (-23) exists of
draft-ietf-dmarc-arc-protocol-05
== Outdated reference: A later version (-23) exists of
draft-ietf-dmarc-arc-protocol-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-01
== Outdated reference: A later version (-09) exists of
draft-ietf-dmarc-arc-usage-05
-- Obsolete informational reference (is this intentional?): RFC 6982
(Obsoleted by RFC 7942)
Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 14 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: December 26, 2018 Google
6 S. Blank, Ed.
7 Valimail
8 M. Kucherawy, Ed.
9 TDP
10 T. Draegon, Ed.
11 dmarcian
12 June 24, 2018
14 Authenticated Received Chain (ARC) Protocol
15 draft-ietf-dmarc-arc-protocol-15
17 Abstract
19 The Authenticated Received Chain (ARC) protocol allows Internet Mail
20 Handlers to attach assertions of message authentication state to
21 individual messages. As messages traverse ARC-enabled Internet Mail
22 Handlers, additional ARC assertions can be attached to messages to
23 form ordered sets of ARC assertions that represent authentication
24 state along each step of message handling paths.
26 ARC-enabled Internet Mail Handlers can process sets of ARC assertions
27 to inform message disposition decisions, to identify Internet Mail
28 Handlers that might break existing authentication mechanisms, and to
29 convey original authentication state across trust boundaries.
31 Status of This Memo
33 This Internet-Draft is submitted in full conformance with the
34 provisions of BCP 78 and BCP 79.
36 Internet-Drafts are working documents of the Internet Engineering
37 Task Force (IETF). Note that other groups may also distribute
38 working documents as Internet-Drafts. The list of current Internet-
39 Drafts is at https://datatracker.ietf.org/drafts/current/.
41 Internet-Drafts are draft documents valid for a maximum of six months
42 and may be updated, replaced, or obsoleted by other documents at any
43 time. It is inappropriate to use Internet-Drafts as reference
44 material or to cite them other than as "work in progress."
46 This Internet-Draft will expire on December 26, 2018.
48 Copyright Notice
50 Copyright (c) 2018 IETF Trust and the persons identified as the
51 document authors. All rights reserved.
53 This document is subject to BCP 78 and the IETF Trust's Legal
54 Provisions Relating to IETF Documents
55 (https://trustee.ietf.org/license-info) in effect on the date of
56 publication of this document. Please review these documents
57 carefully, as they describe your rights and restrictions with respect
58 to this document. Code Components extracted from this document must
59 include Simplified BSD License text as described in Section 4.e of
60 the Trust Legal Provisions and are provided without warranty as
61 described in the Simplified BSD License.
63 Table of Contents
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
66 1.1. Note to Reviewers in the DMARC WG . . . . . . . . . . . . 4
67 2. General Concepts . . . . . . . . . . . . . . . . . . . . . . 5
68 2.1. Evidence . . . . . . . . . . . . . . . . . . . . . . . . 5
69 2.2. Custody . . . . . . . . . . . . . . . . . . . . . . . . . 5
70 2.3. Chain of Custody . . . . . . . . . . . . . . . . . . . . 5
71 2.4. Validation of Chain of Custody . . . . . . . . . . . . . 5
72 3. Terminology and Definitions . . . . . . . . . . . . . . . . . 6
73 3.1. ARC Set . . . . . . . . . . . . . . . . . . . . . . . . . 6
74 3.2. Authenticated Received Chain (ARC) . . . . . . . . . . . 7
75 3.3. Sealer . . . . . . . . . . . . . . . . . . . . . . . . . 7
76 3.4. Validator . . . . . . . . . . . . . . . . . . . . . . . . 7
77 3.5. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . 7
78 3.6. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . 7
79 4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 8
80 4.1. ARC Headers . . . . . . . . . . . . . . . . . . . . . . . 8
81 4.1.1. ARC-Authentication-Results (AAR) . . . . . . . . . . 8
82 4.1.2. ARC-Message-Signature (AMS) . . . . . . . . . . . . . 8
83 4.1.3. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . 9
84 4.2. ARC Set . . . . . . . . . . . . . . . . . . . . . . . . . 10
85 4.2.1. Instance Tags . . . . . . . . . . . . . . . . . . . . 11
86 4.3. Authenticated Received Chain . . . . . . . . . . . . . . 11
87 4.4. Chain Validation Status . . . . . . . . . . . . . . . . . 11
88 5. Protocol Actions . . . . . . . . . . . . . . . . . . . . . . 12
89 5.1. Sealer Actions . . . . . . . . . . . . . . . . . . . . . 12
90 5.1.1. Header Fields To Include In ARC-Seal Signatures . . . 13
91 5.1.2. Marking and Sealing "cv=fail" (Invalid) Chains . . . 13
92 5.1.3. Only One Authenticated Received Chain Per Message . . 14
93 5.1.4. Broad Ability to Seal . . . . . . . . . . . . . . . . 14
94 5.1.5. Sealing is Always Safe . . . . . . . . . . . . . . . 14
95 5.1.6. Signing vs Sealing . . . . . . . . . . . . . . . . . 14
97 5.2. Validator Actions . . . . . . . . . . . . . . . . . . . . 14
98 5.2.1. All Failures Are Permanent . . . . . . . . . . . . . 16
99 5.2.2. Responding to ARC Validation Failures During the SMTP
100 Transaction . . . . . . . . . . . . . . . . . . . . . 16
101 5.3. Result of Validation . . . . . . . . . . . . . . . . . . 16
102 6. Communication of Validation Results . . . . . . . . . . . . . 17
103 7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 17
104 7.1. Communicate Authentication Results Across Trust
105 Boundaries . . . . . . . . . . . . . . . . . . . . . . . 17
106 7.1.1. Message Scanning Services . . . . . . . . . . . . . . 18
107 7.1.2. Multi-tier MTA Processing . . . . . . . . . . . . . . 18
108 7.1.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 18
109 7.2. Inform Message Disposition Decisions . . . . . . . . . . 19
110 7.2.1. DMARC Local Policy Overrides . . . . . . . . . . . . 19
111 7.2.2. DMARC Reporting . . . . . . . . . . . . . . . . . . . 19
112 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20
113 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
114 9.1. Increased Header Size . . . . . . . . . . . . . . . . . . 21
115 9.2. DNS Operations . . . . . . . . . . . . . . . . . . . . . 21
116 9.3. Message Content Suspicion . . . . . . . . . . . . . . . . 21
117 9.4. Message Sealer Suspicion . . . . . . . . . . . . . . . . 22
118 9.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 22
119 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
120 10.1. Email Authentication Results Names Registry Update . . . 22
121 10.2. Email Authentication Methods Registry Update . . . . . . 22
122 10.3. Definitions of the ARC header fields . . . . . . . . . . 23
123 11. Experimental Considerations . . . . . . . . . . . . . . . . . 23
124 11.1. Success Consideration . . . . . . . . . . . . . . . . . 23
125 11.2. Failure Considerations . . . . . . . . . . . . . . . . . 24
126 11.3. Open Questions . . . . . . . . . . . . . . . . . . . . . 24
127 11.3.1. Value of the ARC-Seal (AS) Header . . . . . . . . . 24
128 11.3.2. DNS Overhead . . . . . . . . . . . . . . . . . . . . 24
129 11.3.3. What Trace Information is Valuable . . . . . . . . . 24
130 12. Implementation Status . . . . . . . . . . . . . . . . . . . . 25
131 12.1. GMail test reflector and incoming validation . . . . . . 26
132 12.2. AOL test reflector and internal tagging . . . . . . . . 26
133 12.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 26
134 12.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . 27
135 12.5. Mailman 3.x patch . . . . . . . . . . . . . . . . . . . 27
136 12.6. Copernica/MailerQ web-based validation . . . . . . . . . 27
137 12.7. Rspamd . . . . . . . . . . . . . . . . . . . . . . . . . 28
138 12.8. PERL MAIL::DKIM module . . . . . . . . . . . . . . . . . 28
139 12.9. PERL Mail::Milter::Authentication module . . . . . . . . 28
140 12.10. Sympa List Manager . . . . . . . . . . . . . . . . . . . 29
141 12.11. Oracle Messaging Server . . . . . . . . . . . . . . . . 29
142 12.12. MessageSystems Momentum and PowerMTA platforms . . . . . 29
143 12.13. Exim . . . . . . . . . . . . . . . . . . . . . . . . . . 29
144 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
145 13.1. Normative References . . . . . . . . . . . . . . . . . . 30
146 13.2. Informative References . . . . . . . . . . . . . . . . . 31
147 13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 32
148 Appendix A. Appendix A - Design Requirements . . . . . . . . . . 32
149 A.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 33
150 A.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 33
151 Appendix B. Appendix B - Example Usage . . . . . . . . . . . . . 33
152 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 33
153 Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 34
154 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
156 1. Introduction
158 The utility of widely deployed email authentication technologies such
159 as Sender Policy Framework (SPF) [RFC7208] and DomainKeys Identified
160 Mail (DKIM) [RFC6376] is impacted by the processing of Internet Mail
161 by intermediate handlers. This impact is thoroughly documented in
162 the defining documents for SPF and DKIM and further discussed in
163 [RFC6377] and [RFC7960].
165 The utility of technologies that build upon SPF and DKIM (such as
166 DMARC [RFC7489]) is similarly impacted by intermediate handlers. The
167 disruption of authentication mechanisms for legitimate messages by
168 intermediate handlers can impact all aspects of Internet Mail -
169 message authors, message recipients, and even the intermediary
170 handler itself.
172 Authenticated Received Chain (ARC) creates a mechanism for individual
173 Internet Mail Handlers to add their authentication processing results
174 to a message's ordered set of processing results. ARC encapsulates
175 processing results in a DKIM signature derivative to grant other
176 handlers the ability to verify the authenticity of each individual
177 processing results as well as the aggregate set and sequence of
178 results.
180 Ordered sets of processing results can be used by ARC-enabled
181 Internet Mail Handlers to inform message handling disposition, to
182 identify where alteration of message content might have occurred, and
183 to provide additional trace information for use in understanding
184 message handling paths.
186 1.1. Note to Reviewers in the DMARC WG
188 [[ Note: This section is editorial to the WG. Will be removed for
189 final version. ]]
190 This version of the draft has been extensively reorganized for
191 readability. No changes to the wire protocol or specification are
192 intended from [ARC-DRAFT-14].
194 2. General Concepts
196 ARC is loosely based on concepts from evidence collection. Evidence
197 is usually collected, labeled, stored, and transported in specific
198 ways to preserve the state of evidence and to document all processing
199 steps.
201 2.1. Evidence
203 In ARC's situation, the "evidence" is a message's authentication
204 state at any point along the delivery path between origination and
205 final delivery. Authentication state can change when intermediate
206 handlers modify message content, route messages through unforeseen
207 paths, or change envelope information.
209 2.2. Custody
211 "Custody" refers to when an ARC-enabled Internet Mail Handler
212 processes a message. When a handler takes custody of a message, the
213 handler becomes a Custodian and attaches their own evidence
214 (authentication state upon receipt) to the message. Evidence is
215 added in such a way so that future handlers can verify the
216 authenticity of both evidence and custody.
218 2.3. Chain of Custody
220 The "chain of custody" of ARC is the entire set of evidence and
221 custody that travels with a message.
223 2.4. Validation of Chain of Custody
225 Any ARC-enabled Internet Mail Handler can validate the entire set of
226 evidence and custody to yield a valid Chain of Custody. If the
227 evidence-supplying Custodians can be trusted, then the validated
228 Chain of Custody describes the (possibly changing) authentication
229 state as the message traveled through various Custodians.
231 Even though a message's authentication state might have changed, the
232 validated chain of custody can be used to determine if the changes
233 (and the Custodians responsible for the changes) can be tolerated.
235 3. Terminology and Definitions
237 This section defines terms used in the rest of the document.
239 Readers should to be familiar with the contents, core concepts, and
240 definitions found in [RFC5598]. The potential roles of
241 intermediaries in the delivery of email is directly relevant.
243 Language, syntax (including some ABNF constructs), and concepts are
244 imported from DKIM [RFC6376]. Specific references to DKIM are made
245 throughout this document. The following terms are imported from
246 [RFC5598]:
248 o ADministrative Management Domain (ADMD), Section 2.3
250 o Message Transfer Agents (MTA), Section 4.3.2
252 o Message Submission Agent (MSA), Section 4.3.1
254 o Message Delivery Agent (MDA), Section 4.3.3
256 Internet Mail Handlers process and deliver messages across the
257 Internet and include MSAs, MTAs, MDAs, gateways, and mailing lists.
259 Syntax descriptions use Augmented BNF (ABNF) [RFC5234] and [RFC7405].
261 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
262 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
263 "OPTIONAL" in this document are to be interpreted as described in
264 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
265 capitals, as shown here. These words may also appear in this
266 document in lower case as plain English words, absent their normative
267 meanings.
269 3.1. ARC Set
271 Section Section 4.1 introduces three (3) ARC header fields.
272 Together, the 3 header fields compose a single "ARC Set". An ARC Set
273 provides the means for an Internet Mail Handler to attach
274 authentication state to a message in a manner that can be verified by
275 future handlers. A single message can contain multiple ARC Sets.
277 In General Concept terms, an ARC Set represents Evidence and Custody.
279 3.2. Authenticated Received Chain (ARC)
281 The complete sequence of ARC Sets attached to a message is called the
282 Authenticated Received Chain. An Authenticated Received Chain is a
283 recording of individual authentication states as a message traverses
284 through ARC-participating ADMDs.
286 The first attachment of an ARC Set to a message causes an
287 Authenticated Received Chain to be created. Additional attachments
288 of ARC Sets cause the Authenticated Received Chain to be extended.
290 In General Concept terms, an Authenticated Received Chain represents
291 Chain of Custody.
293 3.3. Sealer
295 A Sealer is an Internet Mail Handler that attaches a complete and
296 valid ARC Set to a message.
298 In General Concept terms, a Sealer adds Evidence and proof of Custody
299 to the Chain of Custody.
301 3.4. Validator
303 A Validator is an ARC-enabled Internet Mail Handler that evaluates an
304 Authenticated Received Chain for validity and content. The process
305 of evaluation of the individual ARC Sets that compose an
306 Authenticated Received Chain is described in Section Section 5.2.
308 In General Concept terms, a Validator inspects the Chain of Custody
309 to determine the content and validity of individual Evidence supplied
310 by Custodians.
312 3.5. Imported ABNF Tokens
314 The following ABNF tokens are imported:
316 o tag-list ([RFC6376] section 3.2)
318 o authres-payload ([I-D-7601bis] section 2.2)
320 o cfws ([RFC5322] section 3.2.2)
322 3.6. Common ABNF Tokens
324 The following ABNF tokens are used elsewhere in this document:
326 position = 1*2DIGIT ; 1 - 50
327 instance = [CFWS] %s"i" [CFWS] "=" [CFWS] position [CFWS] ";"
328 chain-status = ("none" / "fail" / "pass")
329 seal-cv-tag = %s"cv" [CFWS] "=" [CFWS] chain-status
331 4. Protocol Elements
333 4.1. ARC Headers
335 ARC introduces three new header fields. Syntax for new header fields
336 borrows heavily from existing specifications. This document only
337 describes where ARC-specific changes in syntax and semantics differ
338 from existing specifications.
340 4.1.1. ARC-Authentication-Results (AAR)
342 The ARC-Authentication-Results (AAR) header field records the message
343 authentication state as processed by an ARC-participating ADMD at
344 message arrival time.
346 In General Concept terms, the AAR header field is where Evidence is
347 recorded by a Custodian.
349 The AAR header field is similar in syntax and semantics to an
350 Authentication-Results field [I-D-7601bis], with two (2) differences:
352 o the name of the header field itself;
354 o the presence of the "instance tag". Additional information on the
355 "instance tag" can be found in Section Section 4.2.1.
357 The formal ABNF for the AAR header field is:
359 arc-info = instance [CFWS] ";" authres-payload
360 arc-authres-header = "ARC-Authentication-Results:" [CFWS] arc-info
362 Because there is only one AAR allowed per ARC set, the AAR MUST
363 contain all authentication results from within the participating
364 ADMD, regardless of how many Authentication-Results headers are
365 attached to the message.
367 4.1.2. ARC-Message-Signature (AMS)
369 The ARC-Message-Signature (AMS) header field allows an ARC-
370 participating ADMD to convey some responsibility (custodianship) for
371 a message and possible message modifications to future ARC-
372 participating Custodians.
374 In General Concept terms, the AMS header field identifies a
375 Custodian.
377 The AMS header field is similar in syntax and semantics to a DKIM-
378 Signature field [RFC6376], with three (3) differences:
380 o the name of the header field itself;
382 o no version tag ("v") is defined for the AMS header. As required
383 for undefined tags (in [RFC6376]), if seen, a version tag MUST be
384 ignored;
386 o the presence of the "instance tag". Additional information on the
387 "instance tag" can be found in Section Section 4.2.1. The
388 instance tag replaces the DKIM "AUID" tag.
390 ARC places no requirements on the selectors and/or domains used for
391 the AMS header field signatures.
393 The formal ABNF for the AMS header field is:
395 arc-ams-info = instance [CFWS] ";" tag-list
396 arc-message-signature = "ARC-Message-Signature:" [CFWS] arc-ams-info
398 To avoid unwanted invalidation of AMS signatures:
400 o AMS header fields are added by ARC-participating ADMDs as messages
401 exit the ADMD. AMS header fields should be attached so that any
402 modifications made by the ADMD are included in the signature of
403 the AMS header field.
405 o Authentication-Results header fields MUST NOT be included in AMS
406 signatures as they are likely to be deleted by downstream ADMDs
407 (per Section 5 of [I-D-7601bis]).
409 o ARC-related header fields (ARC-Authentication-Results, ARC-
410 Message-Signature, ARC-Seal) MUST NOT be included in the list of
411 header fields covered by the signature of the AMS header field.
413 To preserve the ability to verify the integrity of a message, the
414 signature of the AMS header field SHOULD include any DKIM-Signature
415 header fields already present in the message.
417 4.1.3. ARC-Seal (AS)
419 The ARC-Seal (AS) header field is the mechanism by which ARC-
420 participating ADMDs can verify the integrity of AAR header fields and
421 corresponding AMS header fields.
423 In General Concept terms, the AS header field is how Custodians bind
424 Evidence into a Chain of Custody so that Validators can inspect
425 individual Evidence and Custodians.
427 The AS header field is similar in syntax and semantics to DKIM-
428 Signatures [RFC6376], with the following differences:
430 o the presence of the "instance tag". Additional information on the
431 "instance tag" can be found in Section Section 4.2.1.
433 o the signature of the AS header field does not cover the body of
434 the message and therefore there is no 'bh' tag. The signature of
435 the AS header field only covers specific header fields as defined
436 in Section Section 5.1.1.
438 o no body canonicalization is performed as the AS signature does not
439 cover the body of a message.
441 o only "relaxed" header canonicalization ([RFC6376] section 3.4.2)
442 is used.
444 o the only supported tags are "i" (from Section Section 4.2.1 of
445 this document), and "a", "b", "d, "s", "t" from Section 3.5 of
446 [RFC6376]. Note especially that the DKIM "h" header is NOT
447 allowed and if found, MUST result in a cv status of "fail" (for
448 more information see Section 5.1.1;
450 o an additional tag, "cv" ("seal-cv-tag" in the ARC-Seal ABNF
451 definition) is used to communicate Chain Validation Status to
452 subsequent ADMDs.
454 ARC places no requirements on the selectors and/or domains used for
455 the AS header field signatures.
457 The formal ABNF for the AS header field is:
459 arc-as-info = instance [CFWS] ";" tag-list
460 arc-seal = "ARC-Seal:" [CFWS] arc-as-info
462 4.2. ARC Set
464 An "ARC Set" is a single collection of three ARC Headers (AAR, AMS,
465 and AS). ARC Headers of an ARC Set share the same "instance" value.
467 By adding all ARC Headers to a message, an ARC Sealer adds an ARC Set
468 to a message. A description of how Sealers add an ARC Set to a
469 message is found in Section Section 5.1.
471 4.2.1. Instance Tags
473 Instance tags describe which ARC Headers belong to an ARC Set. Each
474 ARC Header of an ARC Set shares the same instance tag value.
476 Instance tag values are integers that begin at 1 and are incremented
477 by each addition of an ARC Set. Through the incremental values of
478 instance tags, an ARC Validator can determine the order in which ARC
479 Sets were added to a message.
481 Instance tag values can range from 1-50 (inclusive).
483 Valid ARC Sets MUST have exactly one instance of each ARC Header
484 field (AAR, AMS, and AS) for a given instance value and signing
485 algorithm.
487 _INFORMATIONAL:_ Initial development of ARC is only being done with a
488 single allowed signing algorithm, but parallel work in the DCRUP
489 working group is expanding that. For handling multiple signing
490 algorithms, see [ARC-MULTI].
492 4.3. Authenticated Received Chain
494 An Authenticated Received Chain is an ordered collection of ARC Sets.
495 As ARC Sets are enumerated sets of ARC Headers, an Authenticated
496 Received Chain represents the output of message authentication state
497 along the handling path of ARC-enabled processors.
499 Results of message authentication processing along each step of the
500 ARC-enabled handling path is present in an Authenticated Received
501 Chain in the form of AAR header fields. The ability to verify the
502 identity of message handlers and the integrity of message content is
503 provided by AMS header fields. AS header fields allow messages
504 handlers to validate the assertions, order and sequence of the
505 Authenticated Received Chain itself.
507 In General Concept terms, an Authenticated Received Chain represents
508 a message's Chain of Custody. Validators can consult a message's
509 Chain of Custody to gain insight regarding each Custodian of a
510 message and the Evidence collected by each Custodian.
512 4.4. Chain Validation Status
514 The state of the Authenticated Received Chain at a specific
515 processing step is called the "Chain Validation Status". Chain
516 Validation Status information is communicated in several ways:
518 o the AS header field in the "cv" tag, and
519 o as part of Authentication-Results and AAR headers.
521 Chain Validation Status has one of three possible values:
523 o none: There was no Authenticated Received Chain on the message
524 when it arrived for validation. Typically this occurs when a
525 message is received directly from a message's original Message
526 Transfer Agent (MTA) or Message Submission Agent (MSA), or from an
527 upstream Internet Mail Handler that is not participating in ARC
528 handling.
530 o fail: The message contains an Authenticated Received Chain whose
531 validation failed.
533 o pass: The message contains an Authenticated Received Chain whose
534 validation succeeded.
536 5. Protocol Actions
538 ARC-enabled Internet Mail Handlers generally act as both ARC Sealers
539 (when sending messages) and ARC Validators (when receiving messages).
541 5.1. Sealer Actions
543 To "seal" a message, an ARC Sealer adds an ARC Set (the three ARC
544 header fields AAR, AMS, and AS) to a message. All ARC header fields
545 in an ARC Set share the same instance tag value.
547 To perform Sealing (aka to build and attach a new ARC Set), the
548 following actions must be taken by an ARC Sealer when presented with
549 a message:
551 1. All message modifications (including adding DKIM-Signatures) MUST
552 be performed before Sealing.
554 2. Calculate the instance value: if the message contains an
555 Authenticated Received Chain, the instance value is 1 more than
556 the highest instance number found in the Authenticated Received
557 Chain. If no Authenticated Received Chain exists, the instance
558 value is 1.
560 3. Using the calculated instance value, generate and attach to the
561 message in the following order:
563 4. An ARC-Authentication-Results header field as defined in
564 Section Section 4.1.1.
566 5. An ARC-Message-Signature header field as defined in
567 Section Section 4.1.2.
569 6. An ARC-Seal header field using the AS definition found in
570 Section Section 4.1.3, the method described in
571 Section Section 5.1.1, and the Chain Validation Status as
572 determined during ARC validation.
574 5.1.1. Header Fields To Include In ARC-Seal Signatures
576 The signature of an AS header field signs a specific canonicalized
577 form of the ARC Set header values. The ARC set header values are
578 supplied to the hash function in increasing instance order, starting
579 at 1, and include the ARC Set being added at the time of Sealing the
580 message.
582 Within an ARC Set, header fields are supplied to the hash function in
583 the following order:
585 1. ARC-Authentication-Results
587 2. ARC-Message-Signature
589 3. ARC-Seal
591 The ARC-Seal is generated in a manner similar to when DKIM-Signatures
592 are added to messages ([RFC6376], section 3.7).
594 Note that when an Authenticated Received Chain has failed validation,
595 the signing scope for the ARC-Seal is modified (see
596 Section Section 5.1.2).
598 5.1.2. Marking and Sealing "cv=fail" (Invalid) Chains
600 In the case of a failed Authenticated Received Chain, the header
601 fields included in the signature scope of the AS header field b=
602 value MUST only include the ARC Set headers created by the MTA which
603 detected the malformed chain, as if this newest ARC Set was the only
604 set present.
606 _INFORMATIONAL_: This approach is mandated to handle the case of a
607 malformed or otherwise invalid Authenticated Received Chain. There
608 is no way to generate a deterministic set of AS header fields
609 (Section 5.1.1) in most cases of invalid chains.
611 5.1.3. Only One Authenticated Received Chain Per Message
613 A message can have only one Authenticated Received Chain on it at a
614 time. Once broken, the chain cannot be continued, as the chain of
615 custody is no longer valid and responsibility for the message has
616 been lost. For further discussion of this topic and the designed
617 restriction which prevents chain continuation or re-establishment,
618 see [ARC-USAGE].
620 5.1.4. Broad Ability to Seal
622 ARC is not solely intended for perimeter MTAs. Any mediator
623 ([RFC5598], section 5) that modifies a message may Seal its own
624 changes. For additional information, see Section Section 7.1.
626 5.1.5. Sealing is Always Safe
628 The utility of an Authenticated Received Chain is limited to very
629 specific cases. Authenticated Received Chains are designed to
630 provide additional information to an Internet Mail Handler when
631 evaluating messages for delivery in the context of authentication
632 failures. Specifically:
634 o Properly adding an ARC Set to a message does not damage or
635 invalidate an existing Authenticated Received Chain.
637 o Sealing an Authenticated Received Chain when a message has not
638 been modified does not negatively affect the chain.
640 o Validating a message exposes no new threat vectors (see
641 Section Section 9).
643 o An ADMD may choose to Seal all inbound messages whether or not a
644 message has been modified or will be retransmitted.
646 5.1.6. Signing vs Sealing
648 Signing is the process of affixing a digital signature to a message
649 as a header, such as when a DKIM-Signature (as in [RFC6376] section
650 2.1), or an AMS or AS is added. Sealing is when an ADMD affixes a
651 complete and valid ARC Set to a message creating or continuing an
652 Authenticated Received Chain.
654 5.2. Validator Actions
656 A validator performs the following steps, in sequence, to process an
657 Authenticated Received Chain. Canonicalization, hash functions, and
658 signature validation methods are imported from [RFC6376] section 5.
660 1. Collect all ARC Sets currently attached to the message. If there
661 are none, the Chain Validation Status is "none" and the algorithm
662 stops here. The maximum number of ARC Sets that can be attached
663 to a message is 50. If more than the maximum number exist the
664 Chain Validation Status is "fail" and the algorithm stops here.
665 In the following algorithm, the maximum ARC instance value is
666 referred to as "N".
668 2. If the Chain Validation Status of the highest instance value ARC
669 Set is "fail", then the Chain Validation status is "fail" and the
670 algorithm stops here.
672 3. Validate the structure of the Authenticated Received Chain. A
673 valid ARC has the following conditions:
675 1. Each ARC Set MUST contain exactly one each of the three ARC
676 header fields (AAR, AMS, and AS).
678 2. The instance values of the ARC Sets MUST form a continuous
679 sequence from 1..N with no gaps or repetition.
681 3. The "cv" value for all ARC-Seal header fields must be non-
682 failing. For instance values > 1, the value must be "pass".
683 For instance value = 1, the value must be "none".
685 * If any of these conditions are not met, the Chain Validation
686 Status is "fail" and the algorithm stops here.
688 4. Validate the AMS with the greatest instance value (most recent).
689 If validation fails, then the Chain Validation Status is "fail"
690 and the algorithm stops here.
692 5. _OPTIONAL:_ Determine the "oldest-pass" value from the ARC Set by
693 validating each prior AMS beginning with the N-1 and proceeding
694 in decreasing order to the AMS with the instance value of 1:
696 6. If an AMS fails to validate (for instance value "M"), then set
697 the oldest-pass value to the lowest AMS instance value which
698 passed (M+1) and go to the next step (there is no need to check
699 any other (older) AMS headers). This does not affect the
700 validity of the Authenticated Received Chain.
702 7. If all AMS headers verify, set the oldest-pass value to zero (0).
704 8. Validate each AS beginning with the greatest instance value and
705 proceeding in decreasing order to the AS with the instance value
706 of 1. If any AS fails to validate, the Chain Validation Status
707 is "fail" and the algorithm stops here.
709 9. If the algorithm reaches this step, then the Chain Validation
710 Status is "pass", and the algorithm is complete.
712 The end result of this Validation algorithm is added into the
713 Authentication-Results header for the ADMD.
715 As with a failing DKIM signature ([RFC6376] section 6.3), a message
716 with a failing Authenticated Received Chain MUST be treated the same
717 as a message with no Authenticated Received Chain.
719 _INFORMATIONAL_: Recipients of an invalid or failing Authenticated
720 Received Chain can use that information as part of a wider handling
721 context. ARC adoption cannot be assumed by intermediaries; many
722 intermediaries will continue to modify messages without adding ARC
723 Seals.
725 5.2.1. All Failures Are Permanent
727 Authenticated Received Chains represent the traversal of messages
728 through one or more intermediaries. All errors, including DNS
729 failures, become unrecoverable and are considered permanent.
731 Any error Validating an Authenticated Received Chain results in a
732 failed Chain Validation Status. For further discussion of this topic
733 and the design restriction which prevents chain continuation or re-
734 establishment, see [ARC-USAGE].
736 5.2.2. Responding to ARC Validation Failures During the SMTP
737 Transaction
739 If an ARC Validator determines that the Authenticated Received Chain
740 has failed, the Validator MAY signal the breakage through the
741 extended SMTP response code 5.7.7 [RFC3463] "message integrity
742 failure" [ENHANCED-STATUS] and corresponding SMTP response code.
744 5.3. Result of Validation
746 An Authenticated Received Chain with a Chain Validation Status of
747 "pass" allows Internet Mail Handlers to ascertain:
749 o all ARC-participating ADMDs that claim responsibility for handling
750 (and possibly modifying) the message in transit;
752 o the authentication state of the message as perceived by each ADMD
753 (from Authentication-Results header fields).
755 Given this information, handlers can inform local policy decisions
756 regarding disposition of messages that experience authentication
757 failure due to intermediate processing.
759 6. Communication of Validation Results
761 Chain Validation Status (described in Section Section 4.4) is
762 communicated via Authentication-Results (and AAR) headers using the
763 auth method "arc". This auth method is described in
764 Section Section 10.1.
766 If necessary data is available, the ptypes and properties defined in
767 Section Section 10.2 SHOULD be recorded in an Authentication-Results
768 header field:
770 o smtp.client-ip - The connecting client IP address from which the
771 message is received.
773 o header.oldest-pass - The instance number of the oldest AMS that
774 still validates, or 0 if all pass.
776 Upon Sealing of a message, this Authentication-Results information
777 along with all other Authentications-Results added by the ADMD will
778 be recorded into the AAR as defined in section Section 4.1.1.
780 In General Concept terms, the information recorded in the ARC-
781 Authentication-Results header field is the Evidence that gets
782 attached to a message.
784 7. Use Cases
786 This section explores several messaging handling use cases that are
787 addressed by ARC.
789 7.1. Communicate Authentication Results Across Trust Boundaries
791 When an intermediary ADMD adds an ARC Set to a message's
792 Authenticated Received Chain (or creates the initial ARC Set), the
793 ADMD communicates authentication state to the next ADMD in the
794 message handling path.
796 If ARC-enabled ADMDs are trusted, Authenticated Received Chains can
797 be used to bridge administrative boundaries.
799 7.1.1. Message Scanning Services
801 Message services are available to perform anti-spam, anti-malware,
802 and anti-phishing scanning. Such services typically remove malicious
803 content, replace HTTP links in messages with sanitized links, and/or
804 attach footers to messages advertising the abilities of the message
805 scanning service. These modifications almost always break signature-
806 based authentication (such as DKIM).
808 Scanning services typically require clients to point MX records of an
809 Internet domain to the scanning service. Messages destined for the
810 Internet domain are initially delivered to the scanning service.
811 Once scanning is performed, messages are then routed to the client's
812 own mail handling infrastructure. Re-routing messages in this way
813 almost always breaks path-based authentication (such as SPF).
815 Message scanning services can attach Authenticated Received Chains to
816 messages to communicate authentication results into client ADMDs.
817 Clients can then benefit from the message scanning service while
818 processing messages as if the client's infrastructure were the
819 original destination of the Internet domain's MX record.
821 7.1.2. Multi-tier MTA Processing
823 Large message processing infrastructure is often divided into several
824 processing tiers that can break authentication information between
825 tiers. For example, a large site may maintain a cluster of MTAs
826 dedicated to connection handling and enforcement of IP-based
827 reputation filtering. A secondary cluster of MTAs may be dedicated
828 and optimized for content-based processing of messages.
830 Authenticated Received Chains can be used to communicated
831 authentication state between processing tiers.
833 7.1.3. Mailing Lists
835 Mailing lists resend posted messages to subscribers. A full
836 description of authentication-related mailing list issues can be
837 found in [RFC7960] Section 3.2.3.
839 Mailing list services can implement ARC to convey the original
840 authentication state of posted messages sent to the list's subscriber
841 base. The ADMDs of the mailing list subscribers can then use the
842 Authenticated Received Chain to determine the authentication state of
843 the original message before mailing list handling.
845 7.2. Inform Message Disposition Decisions
847 ARC functionality allows Internet Mail Handlers to reliably identify
848 intermediary ADMDs and for ADMDs to expose authentication state that
849 can survive additional intermediary handling.
851 Intermediaries often break authentication through content
852 modification, interfere with path-based authentication (such as SPF),
853 and strip authentication results (if an MTA removes Authentication-
854 Results headers).
856 Authenticated Received Chains allow ARC Validators to:
858 1. identify ARC-enabled ADMDs that break authentication while
859 processing messages;
861 2. gain extended visibility into the authentication-preserving
862 abilities of ADMDs that relay messages into ARC-enabled ADMDs.
864 Through the collection of ARC-related data, an ADMD can identify
865 handling paths that have broken authentication.
867 An Authenticated Received Chain allows an Internet Mail Handler to
868 potentially base decisions of message disposition on authentication
869 state provided by different ADMDs.
871 7.2.1. DMARC Local Policy Overrides
873 DMARC introduces a policy model where Domain Owners can request email
874 receivers to reject or quarantine messages that fail DMARC alignment.
875 Interoperability issues between DMARC and indirect email flows are
876 documented in [RFC7960].
878 Authenticated Received Chains allow DMARC processors to consider
879 authentication states provided by other ADMDs. As a matter of local
880 policy, a DMARC processor may choose to accept the authentication
881 state provided by an Authenticated Received Chain when determining if
882 a message is DMARC compliant.
884 When an Authenticated Received Chain is used to determine message
885 disposition, the DMARC processor can communicate this local policy
886 decision to Domain Owners as described in Section Section 7.2.2.
888 7.2.2. DMARC Reporting
890 DMARC-enabled receivers indicate when ARC Validation influences
891 DMARC-related local policy decisions. DMARC reporting of ARC-
892 influenced decisions is accomplished by adding a local_policy comment
893 containing a list of data discovered during ARC Validation, which at
894 a minimum includes:
896 o the Chain Validation Status,
898 o the domain and selector for each AS,
900 o the originating IP address from the first ARC Set:
902 EXAMPLE:
904
905 none
906 fail
907 fail
908
909 local_policy
910 arc=pass ams[2].d=d2.example ams[2].s=s1
911 as[2].d=d2.example as[2].s=s2 as[1].d=d1.example
912 as[1].s=s3 client-ip[1]=10.10.10.13
913
914
916 In the above example DMARC XML reporting fragment, data relating to
917 specific validated ARC Sets are enumerated using array syntax (eg,
918 "ams[2]" means AMS header field with instance value of 2). d2.example
919 is the Sealing domain for ARC Set #2 (i=2) and d1.example is the
920 Sealing domain for ARC Set #1 (i=1).
922 Depending on the reporting practices of intermediate message
923 handlers, Domain Owners may receive multiple DMARC reports for a
924 single message. DMARC report processors should be aware of this
925 behaviour and make the necessary accommodations.
927 8. Privacy Considerations
929 The Authenticated Received Chain provides a verifiable record of the
930 handlers for a message. This record may include Personally
931 Identifiable Information such as IP address and domain names. Such
932 information is also including in existing header fields such as the
933 "Received" header field.
935 9. Security Considerations
937 The Security Considerations of [RFC6376] and [I-D-7601bis] apply
938 directly to this specification.
940 As with other domain authentication technologies (such as SPF, DKIM,
941 and DMARC), ARC makes no claims about the semantic content of
942 messages.
944 9.1. Increased Header Size
946 Inclusion of Authenticated Received Chains into messages may cause
947 issues for older or constrained MTAs due to increased total header
948 size.
950 9.2. DNS Operations
952 The validation of an Authenticated Received Chain composed of N ARC
953 Sets can require up to 2*N DNS queries (not including any DNS
954 redirection mechanisms which can increase the total number of
955 queries). This leads to two considerations:
957 1. An attacker can send a message to an ARC participant with a
958 concocted sequence of ARC Sets bearing the domains of intended
959 victims, and all of them will be queried by the participant until
960 a failure is discovered. The difficulty of forging the signature
961 values should limit the extent of this load to domains under
962 control of the attacker. Query traffic pattern analysis may
963 expose information about downstream validating ADMD
964 infrastructure.
966 2. DKIM only performs one DNS query per signature, while ARC can
967 introduce many (per chain). Absent caching, slow DNS responses
968 can cause SMTP timeouts; and backlogged delivery queues on
969 Validating systems. This could be exploited as a DoS attack.
971 9.3. Message Content Suspicion
973 Recipients are cautioned to treat messages bearing Authenticated
974 Received Chains with the same suspicion applied to all other
975 messages. This includes appropriate content scanning and other
976 checks for potentially malicious content.
978 Just as passing message authentication is not an indication of
979 message safety, forwarding that information through the mechanism of
980 ARC is also not an indication of message safety. Even if all ARC-
981 enabled ADMDs are trusted, ADMDs may have become compromised, may
982 miss unsafe content, or may not properly authenticate messages.
984 9.4. Message Sealer Suspicion
986 Recipients are cautioned to treat every Sealer of the ARC Chain with
987 suspicion. Just as with a validated DKIM signature, responsibility
988 for message handling is attributed to the signing domain, but whether
989 or not that signer is a malicious actor is out of scope of the
990 authentication mechanism. Since ARC aids message delivery in the
991 event of an authentication failure, ARC Sealers should be treated
992 with suspicion, so that a malicious actor cannot Seal spam or other
993 fraudulent messages to aid their delivery, too.
995 9.5. Replay Attacks
997 Since ARC inherits heavily from DKIM, it has similar attack vectors.
998 In particular, the Replay Attack described in [RFC6376] section 8.6
999 is potentially amplified by ARC's chained statuses. In an ARC replay
1000 attack, a malicious actor would take an intact and passing ARC Chain,
1001 and then resend it to many recipients without making any
1002 modifications that invalidate the latest AMS or AS. The impact to a
1003 receiver would be more DNS lookups and signature evaluations. This
1004 scope of this attack can be limited by caching DNS queries and
1005 following the same signing scope guidance from [RFC6376] section
1006 5.4.1.
1008 10. IANA Considerations
1010 [[ *Note to the RFC Editors:* dkim header.s is defined both here and
1011 in [I-D-7601bis]. Please delete the overlap from whichever document
1012 goes through the publication process after the other. ]]
1014 This draft introduces three new headers fields and updates the Email
1015 Authentication Parameters registry with one new authentication method
1016 and several status codes.
1018 10.1. Email Authentication Results Names Registry Update
1020 This draft adds one Auth Method with three Codes to the IANA "Email
1021 Authentication Result Names" registry:
1023 o Auth Method : arc Code: "none", "pass", "fail" Specification:
1024 [I-D.ARC] Section 2.2 Status: active
1026 10.2. Email Authentication Methods Registry Update
1028 This draft adds several new items to the Email Authentication Methods
1029 registry, most recently defined in [I-D-7601bis]:
1031 o Method: arc Definition: [I-D.ARC] ptype: smtp Property: client-ip
1032 Value: IP address of originating SMTP connection Status: active
1033 Version: 1
1035 o Method: arc Definition: [I-D.ARC] ptype: header Property: oldest-
1036 pass Value: The instance id of the oldest validating AMS, or 0 if
1037 they all pass (see Sectionn 4) Status: active Version: 1
1039 o Method: dkim Definition: [RFC6376] ptype: header Property: s
1040 Value: value of signature "s" tag Status: active Version: 1
1042 10.3. Definitions of the ARC header fields
1044 This specification adds three new header fields to the "Permanent
1045 Message Header Field Registry", as follows:
1047 o Header field name: ARC-Seal Applicable protocol: mail Status:
1048 draft Author/Change controller: IETF Specification document(s):
1049 [I-D.ARC] Related information: [RFC6376]
1051 o Header field name: ARC-Message-Signature Applicable protocol: mail
1052 Status: draft Author/Change controller: IETF Specification
1053 document(s): [I-D.ARC] Related information: [RFC6376]
1055 o Header field name: ARC-Authentication-Results Applicable protocol:
1056 mail Status: standard Author/Change controller: IETF Specification
1057 document(s): [I-D.ARC] Related information: [I-D-7601bis]
1059 11. Experimental Considerations
1061 The ARC protocol is designed to address common interoperability
1062 issues introduced by intermediate message handlers. Interoperability
1063 issues are described in [RFC6377] and [RFC7960].
1065 As the ARC protocol is implemented by intermediary handlers over
1066 time, the following should be evaluated in order to determine the
1067 success of the protocol in accomplishing the intended benefits.
1069 11.1. Success Consideration
1071 In an attempt to deliver legitimate messages that users desire, many
1072 receivers use heuristic-based methods to identify messages that
1073 arrive via indirect delivery paths.
1075 ARC will be a success if the presence of Authenticated Received
1076 Chains allows for improved decision making when processing legitimate
1077 messages.
1079 11.2. Failure Considerations
1081 ARC should function without introducing significant new vectors for
1082 abuse (see Section Section 9). If unforseen vectors are enabled by
1083 ARC, then this protocol will be a failure. Note that weaknesses
1084 inherent in the mail protocols ARC is built upon (such as DKIM replay
1085 attacks and other known issues) are not new vectors which can be
1086 attributed to this specification.
1088 11.3. Open Questions
1090 The following open questions are academic and have no clear answer at
1091 the time of the development of the protocol. However, additional
1092 deployment should be able to gather the necessary data to answer some
1093 or all of them.
1095 11.3.1. Value of the ARC-Seal (AS) Header
1097 Data should be collected to show if the ARC-Seal (AS) provides value
1098 beyond the ARC Message Signature (AMS) for either making delivery
1099 decisions or catching malicious actors trying to craft or replay
1100 malicious chains.
1102 11.3.2. DNS Overhead
1104 Longer Authenticated Received Chains will require more queries to
1105 retrieve the keys for validating the chain. While this is not
1106 believed to be a security issue (see Section Section 9.2), it is
1107 unclear how much overhead will truly be added. This is similar to
1108 some of the initial processing and query load concerns which were
1109 debated at the time of the DKIM specification development.
1111 Data should be collected to better understand usable length and
1112 distribution of lengths found in valid Authenticated Received Chains
1113 along with the the DNS impact of processing Authenticated Received
1114 Chains.
1116 An effective operational maximum will have to be developed through
1117 deployment experience in the field.
1119 11.3.3. What Trace Information is Valuable
1121 There are several edge cases where the information in the AAR can
1122 make the difference between message delivery or rejection. For
1123 example, if there is a well known mailing list that seals with ARC
1124 but doesn't do its own initial DMARC enforcement, an Internet Mail
1125 Handler with this knowledge could make a delivery decision based upon
1126 the authentication information it sees in the corresponding AAR
1127 header.
1129 Certain trace information in the AAR is useful/necessary in the
1130 construction of DMARC reports.
1132 Certain receivers believe the entire set of trace information would
1133 be valuable to feed into machine learning systems to identify fraud
1134 and/or provide other signals related to message delivery.
1136 It is unclear what trace information will be valuable for all
1137 receivers, regardless of size.
1139 Data should be collected on what trace information receivers are
1140 using that provides useful signals that affect deliverability, and
1141 what portions of the trace data are left untouched or provide no
1142 useful information.
1144 Since many such systems are intentionally proprietary or confidential
1145 to prevent gaming by abusers, it may not be viable to reliably answer
1146 this particular question. The evolving nature of attacks can also
1147 shift the landscape of "useful" information over time.
1149 12. Implementation Status
1151 [[ Note to the RFC Editor: Please remove this section before
1152 publication along with the reference to [RFC6982]. ]]
1154 This section records the status of known implementations of the
1155 protocol defined by this specification at the time of posting of this
1156 Internet-Draft, and is based on a proposal described in [RFC6982].
1157 The description of implementations in this section is intended to
1158 assist the IETF in its decision processes in progressing drafts to
1159 RFCs. Please note that the listing of any individual implementation
1160 here does not imply endorsement by the IETF. Furthermore, no effort
1161 has been spent to verify the information presented here that was
1162 supplied by IETF contributors. This is not intended as, and must not
1163 be construed to be, a catalog of available implementations or their
1164 features. Readers are advised to note that other implementations may
1165 exist.
1167 This information is known to be correct as of the eighth
1168 interoperability test event which was held on 2018-03-17 at IETF101.
1170 For a few of the implementations, later status information was
1171 available as of June 2018.
1173 12.1. GMail test reflector and incoming validation
1175 Organization: Google Description: Internal production implementation
1176 with both debug analysis and validating + sealing pass-through
1177 function Status of Operation: Production - Incoming Validation
1178 Coverage: Full spec implemented as of [ARC-DRAFT-14] Licensing:
1179 Proprietary - Internal only Implementation Notes:
1181 o Full functionality was demonstrated during the interop testing on
1182 2018-03-17.
1184 Contact Info: arc-discuss@dmarc.org [1]
1186 12.2. AOL test reflector and internal tagging
1188 Organization: AOL Description: Internal prototype implementation with
1189 both debug analysis and validating + sealing pass-through function
1190 Status of Operation: Beta Coverage: ARC Chain validity status
1191 checking is operational, but only applied to email addresses enrolled
1192 in the test program. This system conforms to [ARC-DRAFT-05]
1193 Licensing: Proprietary - Internal only Implementation Notes:
1195 o 2017-07-15: Full functionality verified during the interop
1196 testing.
1198 o 2018-06: Partially retired but still accessible by special request
1199 due to the in process evolution of the AOL mail infrastructure to
1200 the integrated OATH environment. The implementation was based on
1201 the Apache James DKIM code base and may be contributed back to
1202 that project in the future.
1204 Contact Info: arc-discuss@dmarc.org [2]
1206 12.3. dkimpy
1208 Organization: dkimpy developers/Scott Kitterman Description: Python
1209 DKIM package Status of Operation: Production Coverage:
1211 o 2017-07-15: The internal test suite is incomplete, but the command
1212 line developmental version of validator was demonstrated to
1213 interoperate with the Google and AOL implementations during the
1214 interop on 2017-07-15 and the released version passes the tests in
1215 [ARC-TEST] arc_test_suite [3] with both python and python3.
1217 Licensing: Open/Other (same as dkimpy package = BCD version 2)
1218 Contact Info: https://launchpad.net/dkimpy
1220 12.4. OpenARC
1222 Organization: TDP/Murray Kucherawy Description: Implemention of
1223 milter functionality related to the OpenDKIM and OpenDMARC packages
1224 Status of Operation: Beta Coverage: Built to support [ARC-DRAFT-14]
1225 Licensing: Open/Other (same as OpenDKIM and OpenDMARC packages)
1226 Implementation Notes:
1228 o The build is FreeBSD oriented but some packages have been built
1229 for easier deployment on RedHat-based Linux platforms.
1231 o Some issues still exist when deploying in a chained milter
1232 arrangement (such as OpenSPF -> OpenDKIM -> OpenDMARC -> OpenARC)
1233 with coordination between the stages. When deployed in a
1234 "sandwich" configuration around an MLM, there is no effective
1235 mechanism to convey trust from the ingress (validator) to egress
1236 (signer) instances. (_NOTE_: this is expected to resolved with a
1237 new release of OpenDMARC expected in mid-2018.)
1239 Contact Info: arc-discuss@dmarc.org [4]
1241 12.5. Mailman 3.x patch
1243 Organization: Mailman development team Description: Integrated ARC
1244 capabilities within the Mailman 3.2 package Status of Operation:
1245 Patch submitted Coverage: Based on OpenARC Licensing: Same as mailman
1246 package - GPL Implementation Notes:
1248 o Appears to work properly in at least one beta deployment, but
1249 waiting on acceptance of the pull request into the mainline of
1250 mailman development
1252 Contact Info: https://www.gnu.org/software/mailman/contact.html
1254 12.6. Copernica/MailerQ web-based validation
1256 Organization: Copernica Description: Web-based validation of ARC-
1257 signed messages Status of Operation: Beta Coverage: Built to support
1258 [ARC-DRAFT-05] Licensing: On-line usage only Implementation Notes:
1260 o Released 2016-10-24
1262 o Requires full message content to be pasted into a web form found
1263 at http://arc.mailerq.com/ (warning - https is not supported).
1265 o An additional instance of an ARC signature can be added if one is
1266 willing to paste a private key into an unsecured web form.
1268 o 2017-07-15: Testing shows that results match the other
1269 implementations listed in this section.
1271 Contact Info: https://www.copernica.com/
1273 12.7. Rspamd
1275 Organization: Rspamd community Description: ARC signing and
1276 verification module Status of Operation: Production, though
1277 deployment usage is unknown Coverage: Built to support [ARC-DRAFT-14]
1278 Licensing: Open source Implementation Notes:
1280 o 2017-06-12: Released with version 1.6.0
1282 o 2017-07-15: Testing during the interop showed that the validation
1283 functionality interoperated with the Google, AOL, dkimpy and
1284 MailerQ implementations
1286 Contact Info: https://rspamd.com/doc/modules/arc.html and
1287 https://github.com/vstakhov/rspamd
1289 12.8. PERL MAIL::DKIM module
1291 Organization: FastMail Description: Email domain authentication (sign
1292 and/or verify) module, previously included SPF / DKIM / DMARC, now
1293 has ARC added Status of Operation: Production, deployment usage
1294 unknown Coverage: Built to support [ARC-DRAFT-10] Licensing: Open
1295 Source Implementation Notes:
1297 o 2017-12-15: v0.50 released with full test set passing for ARC
1299 Contact Info: http://search.cpan.org/~mbradshaw/Mail-DKIM-0.50/
1301 12.9. PERL Mail::Milter::Authentication module
1303 Organization: FastMail Description: Email domain authentication
1304 milter, uses MAIL::DKIM (see above) Status of Operation: Intial
1305 validation completed during IETF99 hackathon with some follow-on work
1306 during the week Coverage: Built to support [ARC-DRAFT-14] Licensing:
1307 Open Source Implementation Notes:
1309 o 2017-07-15: Validation functionality which interoperates with
1310 Gmail, AOL, dkimpy was demonstrated; later in the week of IETF99,
1311 the signing functionality was reported to be working
1313 o 2017-07-20: ARC functionality has not yet been pushed back to the
1314 github repo but should be showing up soon
1316 Contact Info: https://github.com/fastmail/authentication_milter
1318 12.10. Sympa List Manager
1320 Organization: Sympa Dev Community Description: Work in progress
1321 Status of Operation: Work in progress Coverage: unknown Licensing:
1322 open source Implementation Notes:
1324 o 2018-01-05: Tracked as https://github.com/sympa-community/sympa/
1325 issues/153
1327 Contact Info: https://github.com/sympa-community
1329 12.11. Oracle Messaging Server
1331 Organization: Oracle Description: Status of Operation: Intial
1332 development work during IETF99 hackathon. Framework code is
1333 complete, crypto functionality requires integration with libsodium
1334 Coverage: Work in progress Licensing: Unknown Implementation Notes:
1336 o 2018-03: Protocol handling components are completed, but crypto is
1337 not yet functional.
1339 Contact Info: Chris Newman, Oracle
1341 12.12. MessageSystems Momentum and PowerMTA platforms
1343 Organization: MessageSystems/SparkPost Description: OpenARC
1344 integration into the LUA-enabled Momentum processing space Status of
1345 Operation: Beta Coverage: Same as OpenARC Licensing: Unknown
1346 Implementation Notes:
1348 o Initial deployments for validation expected in mid-2018.
1350 Contact Info: TBD
1352 12.13. Exim
1354 Organization: Exim developers Status of Operation: Operational;
1355 requires specific enabling for compile. Coverage: Full spec
1356 implemented as of [ARC-DRAFT-13] Licensing: GPL Contact Info: exim-
1357 users@exim.org Implementation notes:
1359 o Exim 4.91
1361 13. References
1363 13.1. Normative References
1365 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1366 Requirement Levels", BCP 14, RFC 2119,
1367 DOI 10.17487/RFC2119, March 1997,
1368 .
1370 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes",
1371 RFC 3463, DOI 10.17487/RFC3463, January 2003,
1372 .
1374 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
1375 Specifications: ABNF", STD 68, RFC 5234,
1376 DOI 10.17487/RFC5234, January 2008,
1377 .
1379 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
1380 DOI 10.17487/RFC5322, October 2008,
1381 .
1383 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
1384 DOI 10.17487/RFC5598, July 2009,
1385 .
1387 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
1388 "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
1389 RFC 6376, DOI 10.17487/RFC6376, September 2011,
1390 .
1392 [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and
1393 Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377,
1394 September 2011, .
1396 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
1397 Authorizing Use of Domains in Email, Version 1", RFC 7208,
1398 DOI 10.17487/RFC7208, April 2014,
1399 .
1401 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
1402 RFC 7405, DOI 10.17487/RFC7405, December 2014,
1403 .
1405 [RFC7601] Kucherawy, M., "Message Header Field for Indicating
1406 Message Authentication Status", RFC 7601,
1407 DOI 10.17487/RFC7601, August 2015,
1408 .
1410 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1411 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1412 May 2017, .
1414 13.2. Informative References
1416 [ARC-DRAFT-05]
1417 Andersen, K., "Authenticated Received Chain (ARC) Protocol
1418 (I-D-05)", n.d., .
1421 [ARC-DRAFT-10]
1422 Andersen, K., "Authenticated Received Chain (ARC) Protocol
1423 (I-D-10)", n.d., .
1426 [ARC-DRAFT-13]
1427 Andersen, K., "Authenticated Received Chain (ARC) Protocol
1428 (I-D-13)", n.d., .
1431 [ARC-DRAFT-14]
1432 Andersen, K., "Authenticated Received Chain (ARC) Protocol
1433 (I-D-14)", n.d., .
1436 [ARC-MULTI]
1437 Andersen, K., "Using Multiple Signing Algorithms with
1438 ARC", January 2018, .
1441 [ARC-TEST]
1442 Blank, S., "ARC Test Suite", January 2017,
1443 .
1445 [ARC-USAGE]
1446 Jones, S., Adams, T., Rae-Grant, J., and K. Andersen,
1447 "Recommended Usage of the ARC Headers", April 2018,
1448 .
1451 [ENHANCED-STATUS]
1452 "IANA SMTP Enhanced Status Codes", n.d.,
1453 .
1456 [I-D-7601bis]
1457 Kucherawy, M., "Message Header Field for Indicating
1458 Message Authentication Status", February 2018,
1459 .
1462 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
1463 Code: The Implementation Status Section", RFC 6982,
1464 DOI 10.17487/RFC6982, July 2013,
1465 .
1467 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
1468 Message Authentication, Reporting, and Conformance
1469 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
1470 .
1472 [RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky,
1473 E., Ed., and K. Andersen, Ed., "Interoperability Issues
1474 between Domain-based Message Authentication, Reporting,
1475 and Conformance (DMARC) and Indirect Email Flows",
1476 RFC 7960, DOI 10.17487/RFC7960, September 2016,
1477 .
1479 13.3. URIs
1481 [1] mailto:arc-discuss@dmarc.org
1483 [2] mailto:arc-discuss@dmarc.org
1485 [3] https://github.com/Valimail/arc_test_suite
1487 [4] mailto:arc-discuss@dmarc.org
1489 [5] https://trac.ietf.org/trac/dmarc/ticket/17
1491 [6] mailto:dmarc@ietf.org
1493 [7] mailto:arc-discuss@dmarc.org
1495 [8] mailto:arc-interop@dmarc.org
1497 [9] https://arc-spec.org
1499 Appendix A. Appendix A - Design Requirements
1501 [[ Note: This section is re-inserted for background information from
1502 early versions of the spec. ]]
1503 The specification of the ARC framework is driven by the following
1504 high-level goals, security considerations, and practical operational
1505 requirements.
1507 A.1. Primary Design Criteria
1509 o Provide a verifiable "chain of custody" for email messages;
1511 o Not require changes for originators of email;
1513 o Support the verification of the ARC header field set by each hop
1514 in the handling chain;
1516 o Work at Internet scale; and
1518 o Provide a trustable mechanism for the communication of
1519 Authentication-Results across trust boundaries.
1521 A.2. Out of Scope
1523 ARC is not a trust framework. Users of the ARC header fields are
1524 cautioned against making unsubstantiated conclusions when
1525 encountering a "broken" ARC sequence.
1527 Appendix B. Appendix B - Example Usage
1529 [[ Note: The following examples were mocked up early in the
1530 definition process for the spec. They no longer reflect the current
1531 definition and need various updates which will be included in a
1532 future draft. Issue 17 [5] ]]
1534 [[ Note: Need input from the WG as to what sort of sequence of
1535 examples would be considered useful - otherwise we'll just drop this
1536 section entirely. ]]
1538
1540 Appendix C. Acknowledgements
1542 This draft originated with the work of OAR-Dev Group.
1544 The authors thank all of the OAR-Dev group for the ongoing help and
1545 though-provoking discussions from all the participants, especially:
1546 Alex Brotman, Brandon Long, Dave Crocker, Elizabeth Zwicky, Franck
1547 Martin, Greg Colburn, J. Trent Adams, John Rae-Grant, Mike Hammer,
1548 Mike Jones, Steve Jones, Terry Zink, Tim Draegen.
1550 Grateful appreciation is extended to the people who provided feedback
1551 through the discuss mailing list.
1553 Appendix D. Comments and Feedback
1555 Please address all comments, discussions, and questions to
1556 dmarc@ietf.org [6]. Earlier discussions can be found at arc-
1557 discuss@dmarc.org [7]. Interop discussions planning can be found at
1558 arc-interop@dmarc.org [8].
1560 Some introductory material for less technical people can be found at
1561 https://arc-spec.org [9].
1563 Authors' Addresses
1565 Kurt Andersen
1566 LinkedIn
1567 1000 West Maude Ave
1568 Sunnyvale, California 94085
1569 USA
1571 Email: kurta@linkedin.com
1573 Brandon Long (editor)
1574 Google
1576 Email: blong@google.com
1578 Seth Blank (editor)
1579 Valimail
1581 Email: seth@valimail.com
1583 Murray Kucherawy (editor)
1584 TDP
1586 Email: superuser@gmail.com
1588 Tim Draegon (editor)
1589 dmarcian
1591 Email: tim@dmarcian.com