idnits 2.17.1 draft-ietf-dmarc-arc-usage-07.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 297: '... According to [ARC] Section 5.2.2, a Validator MAY signal the breakage...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 23, 2019) is 1829 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 670 -- Looks like a reference, but probably isn't: '2' on line 672 -- Looks like a reference, but probably isn't: '3' on line 674 -- Looks like a reference, but probably isn't: '4' on line 676 -- Looks like a reference, but probably isn't: '5' on line 678 -- Looks like a reference, but probably isn't: '6' on line 680 -- Looks like a reference, but probably isn't: '7' on line 834 -- Looks like a reference, but probably isn't: '8' on line 841 -- Looks like a reference, but probably isn't: '9' on line 844 -- Looks like a reference, but probably isn't: '10' on line 845 -- Looks like a reference, but probably isn't: '11' on line 846 == Unused Reference: 'RFC6377' is defined on line 603, but no explicit reference was found in the text == Unused Reference: 'ENHANCED-STATUS' is defined on line 630, but no explicit reference was found in the text == Unused Reference: 'OAR' is defined on line 641, but no explicit reference was found in the text ** Obsolete normative reference: RFC 7601 (Obsoleted by RFC 8601) == Outdated reference: A later version (-03) exists of draft-ietf-dmarc-arc-multi-02 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMARC Working Group S. Jones, Ed. 3 Internet-Draft DMARC.org 4 Intended status: Informational K. Andersen 5 Expires: October 25, 2019 LinkedIn 6 April 23, 2019 8 Recommended Usage of the Authenticated Received Chain (ARC) 9 draft-ietf-dmarc-arc-usage-07 11 Abstract 13 The Authentication Received Chain (ARC) provides an authenticated 14 "chain of custody" for a message, allowing each entity that handles 15 the message to see what entities handled it before, and to see what 16 the message's authentication assessment was at each step in the 17 handling. But the specification does not indicate how the entities 18 handling these messages should interpret or utilize ARC results in 19 making decisions about message disposition. This document will 20 provide guidance in these areas. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on October 25, 2019. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. How does ARC work? . . . . . . . . . . . . . . . . . . . 3 59 2.2. What new headers are introduced by ARC? . . . . . . . . . 5 60 2.3. Does ARC support Internationalized Email (EAI)? . . . . . 5 61 2.4. Does ARC support multiple digital signature algorithms? . 5 62 3. Guidance for Receivers/Validators . . . . . . . . . . . . . . 5 63 3.1. What is the significance of an intact ARC chain? . . . . 5 64 3.2. What exactly is an "intact" ARC chain? . . . . . . . . . 6 65 3.3. What is the significance of an invalid ("broken") ARC 66 chain? . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.4. What error code(s) should be returned if an invalid ARC 68 chain is detected during an SMTP transaction? . . . . . . 7 69 3.5. What does the absence of an ARC chain in a message mean? 7 70 3.6. What reasonable conclusions can you draw based upon 71 seeing lots of mail with ARC chains? . . . . . . . . . . 7 72 3.7. What if none of the intermediaries have been seen 73 previously? . . . . . . . . . . . . . . . . . . . . . . . 8 74 3.8. What about ARC chains where some intermediaries are known 75 and others are not? . . . . . . . . . . . . . . . . . . . 8 76 3.9. What should message handlers do when they detect 77 malicious content in messages where ARC is present? . . . 8 78 3.10. What feedback does a sender or domain owner get about ARC 79 when it is applied to their messages? . . . . . . . . . . 9 80 3.11. What prevents a malicious actor from removing the ARC 81 header fields, altering the content, and creating a new 82 ARC chain? . . . . . . . . . . . . . . . . . . . . . . . 9 83 4. Guidance for Intermediaries . . . . . . . . . . . . . . . . . 9 84 4.1. What is an Intermediary under ARC? . . . . . . . . . . . 9 85 4.2. What are the minimum requirements for an ARC 86 Intermediary? . . . . . . . . . . . . . . . . . . . . . . 10 87 4.2.1. More specifically a participating ARC intermediary 88 must do the following: . . . . . . . . . . . . . . . 10 89 4.3. Should every MTA be an ARC participant? . . . . . . . . . 10 90 4.4. What should an intermediary do in the case of an invalid 91 or "broken" ARC chain? . . . . . . . . . . . . . . . . . 10 92 4.5. What should I do in the case where there is no ARC chain 93 present in a message? . . . . . . . . . . . . . . . . . . 11 94 4.6. How could ARC affect my reputation as an intermediary? . 11 95 4.7. What can I do to influence my reputation as an 96 intermediary? . . . . . . . . . . . . . . . . . . . . . . 11 98 5. Guidance for Originators . . . . . . . . . . . . . . . . . . 11 99 5.1. Where can I find out more information? . . . . . . . . . 11 100 5.2. How/where can I test interoperabililty for my 101 implementation? . . . . . . . . . . . . . . . . . . . . . 12 102 5.3. How can ARC impact my email? . . . . . . . . . . . . . . 12 103 5.4. How can ARC impact my reputation as a message sender? . . 12 104 5.5. Can I tell intermediaries not to use ARC? . . . . . . . . 13 105 6. Considerations . . . . . . . . . . . . . . . . . . . . . . . 13 106 6.1. IANA Considerations . . . . . . . . . . . . . . . . . . . 13 107 6.2. Security Considerations . . . . . . . . . . . . . . . . . 13 108 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 109 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 110 7.2. Informative References . . . . . . . . . . . . . . . . . 14 111 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 15 112 Appendix A. Glossary . . . . . . . . . . . . . . . . . . . . . . 15 113 Appendix B. References . . . . . . . . . . . . . . . . . . . . . 18 114 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 18 115 Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 18 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 118 1. Introduction 120 [ARC] is intended to be used by Internet Mail Handlers who forward or 121 resend messages, with or without alterations, such that they will no 122 longer pass the SPF [RFC7208], DKIM [RFC6376], and/or DMARC [RFC7489] 123 mechanisms when evaluated by subsequent message handlers or the final 124 recipient. In such cases ARC may provide useful information about 125 the message before the forwarding and/or alterations took place, and 126 recipients may choose to use this information to influence delivery 127 decisions. 129 2. Overview 131 2.1. How does ARC work? 133 Consider a message sent to a mailing list. Assume that the message 134 author's domain publishes an SPF record, signs messages with a DKIM 135 signature that includes the RFC5322.Subject header and the message 136 body, and publishes a DMARC policy of "p=reject". Finally, assume 137 that the final recipient(s) of the message implement SPF, DKIM and 138 DMARC authentication checks on incoming messages. 140 This message is received by the ADMD hosting the Mailing List Manager 141 (MLM) software. Upon receipt from the message author's ADMD, the 142 results from any DKIM, DMARC, and SPF checks would be recorded in an 143 Authentication-Results header. Then as part of normal list operation 144 the following changes are made to the message: 146 o An address controlled by the MLM is substituted in the 147 RFC5321.MailFrom address field, allowing it to receive 148 undeliverable messages 150 o A prefix is added to the message's RFC5322.Subject header 152 o Some text is appended to the message body 154 After these alterations have been made, the message is sent to list 155 members. 157 A list member's ADMD receiving the message will typically strip out 158 any existing Authentication-Results headers. It will then perform an 159 SPF check using the domain in the RFC5321.MailFrom address field, and 160 would find that the sending host is in the list of authorized senders 161 for the MLM's domain. However under DMARC, since this domain does 162 not match the domain in the RFC5322.From address field, the DMARC SPF 163 result is "fail." 165 The DKIM signature from the domain in the RFC5322.From address field 166 - the message author's domain - will fail to verify, because the 167 RFC5322.Subject header and the message body were altered by the MLM. 168 Therefore the DMARC DKIM result is also "fail," even if there is a 169 valid DKIM signature attached by the MLM's ADMD using its domain. 171 Since neither SPF or DKIM yield a "pass" under DMARC's alignment 172 rules, the DMARC result for this message is "fail." Therefore under 173 the DMARC policy published by the message author's domain, the list 174 member's ADMD should reject the message. 176 If the MLM implemented ARC, it would record the results of its email 177 authentication checks when receiving the message from the author's 178 ADMD in the Authentication-Results header, then perform the 179 alterations described above. It would then "seal" the message under 180 ARC, which includes the following steps. 182 It would record the contents of the Authentication-Results header(s) 183 in a newly created ARC-Authentication-Results header. It would 184 create an ARC-Message-Signature header, which includes a 185 cryptographic signature of the message itself very similar to a DKIM 186 signature, but excluding any ARC headers. Then it would create an 187 ARC-Seal header, which includes a cryptographic signature of all ARC 188 headers present in the message. The MLM's ADMD would then send the 189 ARC "sealed" message to the list members. 191 When the message reaches a list member's ADMD, the SPF and DKIM 192 results will still not pass the DMARC check. However if the 193 receiving ADMD implements ARC, it can check for and validate the ARC 194 chain in the message, and verify that the contents of the ARC- 195 Authentication-Results header were conveyed intact from the MLM's 196 ADMD. At that point the final recipient's ADMD might choose to use 197 those authentication results in the decision whether or not to 198 deliver the message, even though it failed to pass conventional SPF, 199 DKIM, and DMARC checks. 201 2.2. What new headers are introduced by ARC? 203 The following new headers are defined in [ARC] Section 4.1, "ARC 204 Header Fields": 206 o ARC-Seal 208 o ARC-Message-Signature 210 o ARC-Athentication-Results 212 Each time a message passes through an ARC Intermediary, an ARC Set 213 consisting of these three headers will be attached to the message. 214 More information about ARC Sets can be found in [ARC] Section 4.2, 215 "ARC Set." The entire collection of ARC Sets in a message is 216 commonly referred to as the ARC Chain. 218 2.3. Does ARC support Internationalized Email (EAI)? 220 Changes to support EAI are inherited from DKIM [RFC6376] as updated 221 by [draft-levine-eaiauth], and Authentication-Results as updated in 222 [I-D-7601bis]. For more details, please refer to [ARC] 223 Section 4.1.4, "Internationalized Email (EAI)." 225 2.4. Does ARC support multiple digital signature algorithms? 227 Originally ARC only supported a single signing algorithm, but the 228 DCRUP working group https://datatracker.ietf.org/wg/dcrup/about [1] 229 is expanding the set of supported algorithms available to DKIM 230 [RFC6376] and derived protocols. [ARC-MULTI] is adapting this work 231 to extend [ARC] to support multiple algorithms. 233 3. Guidance for Receivers/Validators 235 3.1. What is the significance of an intact ARC chain? 237 An intact ARC chain conveys authentication results like SPF and DKIM 238 as observed by the first ARC participant. In cases where the message 239 no longer produces passing results for DKIM, SPF, or DMARC but an 240 intact ARC chain is present, the message receiver may choose to use 241 the contents of the first ARC-Authentication-Results header field in 242 determining how to handle the message. 244 3.2. What exactly is an "intact" ARC chain? 246 Note that not all ADMDs will implement ARC, and receivers will see 247 messages where one or more non-participating ADMDs handled a message 248 before, after, or in between participating ADMDs. 250 An intact ARC chain is one where the ARC headers that are present can 251 be validated, and in particular the ARC-Message-Signature header from 252 the last ARC participant can still be validated. This shows that the 253 portions of the message covered by that signature were not altered. 254 If any non-participating ADMDs handled the message since the last ARC 255 intermediary but did not alter the message in a way that invalidated 256 the most recent ARC-Message-Signature present, the chain would still 257 be considered intact by the next ARC-enabled ADMD. 259 Message receivers may make local policy decisions about whether to 260 use the contents of the ARC-Authentication-Results header field in 261 cases where a message no longer passes DKIM, DMARC, and/or SPF 262 checks. Whether an ARC chain is intact can be used to inform that 263 local policy decision. 265 So for example one message receiver may decide that, for messages 266 with an intact ARC chain where a DMARC evaluation does not pass, but 267 the ARC-Authentication-Results header field from the first ARC 268 participant indicates a DKIM pass was reported that matches the 269 domain in the RFC5322.From header field, it may override a DMARC 270 "p=reject" policy. Another message receiver may decide to do so only 271 for a limited number of ARC-enabled ADMDs. A third message receiver 272 may choose not to take ARC information into account at all. 274 3.3. What is the significance of an invalid ("broken") ARC chain? 276 An ARC chain is broken if the signatures in the ARC-Seal header 277 fields cannot be verified, or if the most recent AMS can not be 278 verified. For example if a non-ARC-enabled ADMD delivers a message 279 with ARC header sets to the validating ADMD, but modified the message 280 such that those ARC and DKIM signatures already in the message were 281 invalidated. 283 In case of a broken ARC chain, the message should be treated the same 284 as if there was no ARC chain at all. For example, a message that 285 fails under DMARC and has an invalid ARC chain would be subject to 286 that DMARC policy, which may cause it to be quarantined or rejected. 288 Email transit can produce broken signatures for a wide variety of 289 benign reasons. This includes possibly breaking one or more ARC 290 signatures. Therefore, receivers need to be wary of ascribing motive 291 to such breakage, although patterns of common behaviour may provide 292 some basis for adjusting local policy decisions. 294 3.4. What error code(s) should be returned if an invalid ARC chain is 295 detected during an SMTP transaction? 297 According to [ARC] Section 5.2.2, a Validator MAY signal the breakage 298 during the SMTP transaction by returning the extended SMTP response 299 code 5.7.29 "ARC validation failure" and corresponding SMTP basic 300 response code. Since ARC failures are likely the be detected due to 301 other, underlying authentication failures, Validators may also choose 302 to return the more general 5.7.26 "Multiple authentication checks 303 failed instead of the ARC-specific code. 305 3.5. What does the absence of an ARC chain in a message mean? 307 The absence of an ARC chain means nothing. ARC is intended to allow 308 a participating message handler to preserve certain authentication 309 results when a message is being forwarded and/or modified such that 310 the final recipient can evaluate this information. If they are 311 absent, there is nothing extra that ARC requires the final recipient 312 to do. 314 3.6. What reasonable conclusions can you draw based upon seeing lots of 315 mail with ARC chains? 317 With sufficient history, ARC can be used to augment DMARC 318 authentication policy (i.e. a message could fail DMARC, but validated 319 ARC information and therefore could be considered as validly 320 authenticated as reported by the first ARC participant). 322 If the validator does content analysis and reputation tracking, the 323 ARC participants in a message can be credited or discredited for good 324 or bad content. By analyzing different ARC chains involved in "bad" 325 messages, a validator might identify malicious participating 326 intermediaries. 328 With a valid chain and good reputations for all ARC participants, 329 receivers may choose to apply a "local policy override" to the DMARC 330 policy assertion for the domain authentication evaluation, depending 331 on the ARC-Authentication-Results header field value. Normal content 332 analysis should never be skipped. 334 3.7. What if none of the intermediaries have been seen previously? 336 This has no impact on the operation of ARC, as ARC is not a 337 reputation system. ARC conveys the results of other authentication 338 mechanisms such that the participating message handlers can be 339 positively identified. Final message recipients may or may not 340 choose to examine these results when messages fail other 341 authentication checks. They are more likely to override, say, a 342 failing DMARC result in the presence of an intact ARC chain where the 343 participating ARC message handlers have been observed to not convey 344 "bad" content in the past, and the initial ARC participant indicates 345 the message they received had passed authentication checks. 347 3.8. What about ARC chains where some intermediaries are known and 348 others are not? 350 Validators may choose to build reputation models for ARC message 351 handlers they have observed. Generally speaking it is more feasible 352 to accrue positive reputation to intermediaries when they 353 consistently send messages that are evaluated positively in terms of 354 content and ARC chains. When messages are received with ARC chains 355 that are not intact, it is very difficult identify which 356 intermediaries may have manipulated the message or injected bad 357 content. 359 3.9. What should message handlers do when they detect malicious content 360 in messages where ARC is present? 362 Message handlers should do what they normally do when they detect 363 malicious content in a message - hopefully that means quarantining or 364 discarding the message. ARC information should never make malicious 365 content acceptable. 367 In such cases it is difficult to determine where the malicious 368 content may have been injected. What ARC can do in such cases is 369 verify that a given intermediary or message handler did in fact 370 handle the message as indicated in the header fields. In such cases 371 a message recipient who maintains a reputation system about email 372 senders may wish to incorporate this information as an additional 373 factor in the score for the intermediaries and sender in question. 374 However reputation systems are very complex, and usually unique to 375 those organizations operating them, and therefore beyond the scope of 376 this document. 378 3.10. What feedback does a sender or domain owner get about ARC when it 379 is applied to their messages? 381 ARC itself does not include any mechanism for feedback or reporting. 382 It does however recommend that message receiving systems that use ARC 383 to augment their delivery decisions, who use DMARC and decide to 384 deliver a message because of ARC information, should include a 385 notation to that effect in their normal DMARC reports. These 386 notations would be easily identifiable by report processors, so that 387 senders and domain owners can see where ARC is being used to augment 388 the deliverability of their messages. 390 3.11. What prevents a malicious actor from removing the ARC header 391 fields, altering the content, and creating a new ARC chain? 393 ARC does not prevent a malicious actor from doing this. Nor does it 394 prevent a malicious actor from removing all but the first ADMD's ARC 395 header fields and altering the message, eliminating intervening 396 participants from the ARC chain. Or similar variations. 398 A valid ARC chain does not provide any automatic benefit. With an 399 intact ARC chain, the final message recipient may choose to use the 400 contents of the ARC-Authentication-Results header field in 401 determining how to handle the message. The decision to use the ARC- 402 Authentication-Results header field is dependent on evaluation of 403 those ARC intermediaries. 405 In the first case, the bad actor has succeeded in manipulating the 406 message but they have attached a verifiable signature identifying 407 themselves. While not an ideal situation, it is something they are 408 already able to do without ARC involved, but now a signature linked 409 to the domain responsible for the manipulation is present. 411 Additionally in the second case it is possible some negative 412 reputational impact might accrue to the first ARC participant left in 413 place until more messages reveal the pattern of activity by the bad 414 actor. But again, a bad actor can similarly manipulate a sequence of 415 RFC5322.Received header fields today without ARC, but with ARC that 416 bad actor has verifiably identified themselves. 418 4. Guidance for Intermediaries 420 4.1. What is an Intermediary under ARC? 422 In the context of ARC, an Intermediary is typically an Administrative 423 Management Domain [RFC5598] that is receiving a message, potentially 424 manipulating or altering it, and then passing it on to another ADMD 425 for delivery. Common examples of Intermediaries are mailing lists, 426 alumni or professional email address providers that forward messages 427 such as universities or professional organizations, et cetera. 429 4.2. What are the minimum requirements for an ARC Intermediary? 431 A participating ARC intermediary must validate the ARC chain on a 432 message it receives, if one is present. It then attaches its own ARC 433 seal and signature, including an indication if the chain failed to 434 validate upon receipt. 436 4.2.1. More specifically a participating ARC intermediary must do the 437 following: 439 1. Validate that the ARC chain, if one is already present in the 440 message, is intact and well-formed. ([ARC] Section 5.2, 441 "Validator Actions") 443 2. Record the ARC status in an Authentication-Results header 444 ([RFC7601]) 446 3. Generate a new ARC set and add it to the message. ([ARC] 447 Section 5.1, "Sealer Actions") 449 4.3. Should every MTA be an ARC participant? 451 Generally speaking, ARC is designed to operate at the ADMD level. 452 When a message is first received by an ADMD, the traditional 453 authentication results should be captured and preserved - this could 454 be the common case of creating an Authentication-Results header 455 field. But when it is determined that the message is being sent on 456 outside of that ADMD, that is when the ADMD should add itself to the 457 ARC chain - before sending the message outside of the ADMD. 459 Some organizations may operate multiple ADMDs, with more or less 460 independence between them. While they should make a determination 461 based on their specific circumstances, it may be useful and 462 appropriate to have multiple ADMDs be ARC participants. 464 4.4. What should an intermediary do in the case of an invalid or 465 "broken" ARC chain? 467 In general terms, a participating ARC intermediary will note that an 468 ARC chain was present and invalid, or broken, when it attaches its 469 own ARC seal and signature. However the fact that the ARC chain was 470 invalid should have no impact on whether and how the message is 471 delivered. 473 4.5. What should I do in the case where there is no ARC chain present 474 in a message? 476 A participating ARC intermediary receiving a message with no ARC 477 chain, and which will be delivered outside its ADMD, should start an 478 ARC chain according to the ARC specification. This will include 479 capturing the normal email authentication results for the 480 intermediary (SPF, DKIM, DMARC, etc), which will be conveyed as part 481 of the ARC chain. 483 4.6. How could ARC affect my reputation as an intermediary? 485 Message receivers often operate reputation systems, which build a 486 behavioral profile of various message handlers and intermediaries. 487 The presence or absence of ARC is yet another data point that may be 488 used as an input to such reputation systems. Messages deemed to have 489 good content may provide a positive signal for the intermediaries 490 that handled it, while messages with bad content may provide a 491 negative signal for the those intermediaries. Intact and valid ARC 492 elements may amplify or attenuate such signals, depending on the 493 circumstances. 495 Reputation systems are complex and usually specific to a given 496 message receiver, and a meaningful discussion of such a broad topic 497 is beyond the scope of this document. 499 4.7. What can I do to influence my reputation as an intermediary? 501 Today it is extremely simple for a malicious actor to construct a 502 message that includes your identity as an intermediary, even though 503 you never handled the message. It is possible that an intermediary 504 implementing ARC on all traffic it handles might receive some 505 reputational benefit by making it easier to detect when their 506 involvement in conveying bad traffic has been "forged." 508 As mentioned previously reputation systems are very complex and 509 usually specific to a given message receiver, and a meaningful 510 discussion of such a broad topic is beyond the scope of this 511 document. 513 5. Guidance for Originators 515 5.1. Where can I find out more information? 517 Please visit the http://arc-spec.org [2] web site, or join the arc- 518 discuss mailing list at http://lists.dmarc.org/mailman/listinfo/arc- 519 discuss [3]. 521 To discuss the [ARC] specification itself, please join the DMARC 522 working group at https://datatracker.ietf.org/wg/dmarc [4]. 524 5.2. How/where can I test interoperabililty for my implementation? 526 There have been numerous interoperability tests during the 527 development of the [ARC] specification. These tests are usually 528 announced on both the arc-discuss mailing list at 529 http://lists.dmarc.org/mailman/listinfo/arc-discuss [5], and the 530 DMARC working group at https://datatracker/ietf.org/wg/dmarc [6]. 531 Join whichever body is most appropriate for you and/or your 532 organization to receive future announcements. 534 5.3. How can ARC impact my email? 536 Prior to ARC, certain DMARC policies on a domain would cause messages 537 using those domains in the RFC5322.From field, and which pass through 538 certain kinds of intermediaries (mailing lists, forwarding services), 539 to fail authentication checks at the message receiver. As a result 540 these messages might not be delivered to the intended recipient. 542 ARC seeks to provide these so-called "indirect mailflows" with a 543 means to preserve email authentication results as recorded by 544 participating intermediaries. Message receivers may accept validated 545 ARC information to supplement the information that DMARC provides, 546 potentially deciding to deliver the message even though a DMARC check 547 did not pass. 549 The net result for domain owners and senders is that ARC may allow 550 messages routed through participating ARC intermediaries to be 551 delivered, even though those messages would not have been delivered 552 in the absence of ARC. 554 5.4. How can ARC impact my reputation as a message sender? 556 Message receivers often operate reputation systems, which build a 557 behavioral profile of various message senders (and perhaps 558 intermediaries). The presence or absence of ARC is yet another data 559 point that may be used as an input to such reputation systems. 560 Messages deemed to have good content may provide a positive signal 561 for the sending domain and the intermediaries that handled it, while 562 messages with bad content may provide a negative signal for the 563 sending domain and the intermediaries that handled it. Intact and 564 valid ARC elements may amplify or attenuate such signals, depending 565 on the circumstances. 567 Reputation systems are complex and usually specific to a given 568 message receiver, and a meaningful discussion of such a broad topic 569 is beyond the scope of this document. 571 5.5. Can I tell intermediaries not to use ARC? 573 At present there is no way for a message sender to request that 574 intermediaries not employ ARC. 576 6. Considerations 578 6.1. IANA Considerations 580 This document has no actions for IANA. 582 6.2. Security Considerations 584 This document does not have security considerations aside from those 585 raised in the main content. 587 7. References 589 7.1. Normative References 591 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 592 DOI 10.17487/RFC5321, October 2008, 593 . 595 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 596 DOI 10.17487/RFC5322, October 2008, 597 . 599 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 600 DOI 10.17487/RFC5598, July 2009, 601 . 603 [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and 604 Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377, 605 September 2011, . 607 [RFC7601] Kucherawy, M., "Message Header Field for Indicating 608 Message Authentication Status", RFC 7601, 609 DOI 10.17487/RFC7601, August 2015, 610 . 612 7.2. Informative References 614 [ARC] Andersen, K., Long, B., Blank, S., and M. Kucherawy, 615 "Authenticated Received Chain (ARC) Protocol", December 616 2018, . 619 [ARC-MULTI] 620 Andersen, K., Blank, S., and J. Levine, "Using Multiple 621 Signing Algorithms with ARC", June 2018, 622 . 625 [draft-levine-eaiauth] 626 Levine, J., "E-mail Authentication for Internationalized 627 Mail", August 2018, . 630 [ENHANCED-STATUS] 631 "IANA SMTP Enhanced Status Codes", n.d., 632 . 635 [I-D-7601bis] 636 Kucherawy, M., "Message Header Field for Indicating 637 Message Authentication Status", February 2018, 638 . 641 [OAR] Chew, M. and M. Kucherawy, "Original-Authentication- 642 Results Header Field", February 2012, 643 . 646 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 647 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 648 RFC 6376, DOI 10.17487/RFC6376, September 2011, 649 . 651 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 652 Authorizing Use of Domains in Email, Version 1", RFC 7208, 653 DOI 10.17487/RFC7208, April 2014, 654 . 656 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 657 Message Authentication, Reporting, and Conformance 658 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 659 . 661 [RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky, 662 E., Ed., and K. Andersen, Ed., "Interoperability Issues 663 between Domain-based Message Authentication, Reporting, 664 and Conformance (DMARC) and Indirect Email Flows", 665 RFC 7960, DOI 10.17487/RFC7960, September 2016, 666 . 668 7.3. URIs 670 [1] https://datatracker.ietf.org/wg/dcrup/about 672 [2] http://arc-spec.org 674 [3] http://lists.dmarc.org/mailman/listinfo/arc-discuss 676 [4] https://datatracker.ietf.org/wg/dmarc 678 [5] http://lists.dmarc.org/mailman/listinfo/arc-discuss 680 [6] https://datatracker/ietf.org/wg/dmarc 682 [7] mailto:arc-discuss@dmarc.org 684 [8] https://datatracker.ietf.org/wg/dmarc 686 [9] https://arc-spec.org 688 [10] mailto:arc-discuss@dmarc.org 690 [11] http://lists.dmarc.org/mailman/listinfo/arc-discuss 692 Appendix A. Glossary 694 ADMD Administrative Management Domain as used in [RFC5598] and 695 similar references refers to a single entity operating one or more 696 computers within one or more domain names under said entity's 697 control. One example might be a small company with a single 698 server, handling email for that company's domain. Another example 699 might be a large university, operating many servers that fulfill 700 different roles, all handling email for several different domains 701 representing parts of the university. 703 ARC ARC is an acronym: Authentication Results Chain - see also [ARC] 705 ARC-Seal An [RFC5322] message header field formed in compliance with 706 the ARC specification. It includes certain content from all prior 707 ARC participants, if there are any. 709 ARC-Message-Signature (also abbreviated as "AMS") An [RFC5322] 710 message header field formed in compliance with the [ARC] 711 specification. It includes certain content about the message as 712 it was received and manipulated by the intermediary who inserted 713 it. 715 ARC-Authentication-Results (also abbreviated as "AAR") An [RFC5322] 716 message header field formed in compliance with the [ARC] 717 specification. It includes certain content about the message as 718 it was received by the intermediary. 720 Authentication Results Chain (ARC) A system that allows a Message 721 Receiver to identify Intermediaries or Message Handlers who have 722 conveyed a particular message. For more information see the 723 Abstract of this document, or refer to [ARC]. 725 Domain Naming System Block List (DNSBL) This is a system widely used 726 in email filtering services whereby information about the past 727 activity of a set of hosts or domains indicates that messages 728 should not be accepted from them, or at least should be subject to 729 greater scrutiny before being accepted. Common examples would be 730 SpamCop, Spamhaus.org, SORBS, etc. 732 Email Service Provider (ESP) An Email Service Provider is typically 733 a vendor or partner firm that sends mail on behalf of another 734 company. They may use email addresses in Internet domains 735 belonging to the client or partner firm in various [RFC5321] 736 fields or [RFC5322] message header fields of the messages they 737 send on their behalf. 739 Intermediary In the context of [ARC], an Intermediary is typically 740 an Administrative Management Domain (per [RFC5598]) that is 741 receiving a message, potentially manipulating or altering it, and 742 then passing it on to another ADMD for delivery. Also see 743 [RFC7960] for more information and discussion. Common examples of 744 Intermediaries are mailing lists, alumni or professional email 745 address providers like universities or professional organizations, 746 et cetera. 748 Mail/Message Transfer Agent (MTA) This refers to software that sends 749 and receives email messsages across a network with other MTAs. 750 Often run on dedicated servers, common examples are Exim, 751 Microsoft Exchange, Postfix, and Sendmail. 753 Mailflow A group of messages that share features in common. Typical 754 examples would be all messages sent by a given Message Sender to a 755 Message Receiver, related to a particular announcement, a given 756 mailing list, et cetera. 758 Malicious Actor A Malicious Actor is a party, often an Intermediary, 759 that will take actions that seek to exploit or defraud the 760 ultimate recipient of the message, or subvert the network controls 761 and infrastructure of the Message Receiver. Typical examples 762 would be a spammer who forges content or attributes of a message 763 in order to evade anti-spam measures, or an entity that adds an 764 attachment containing a virus to a message. 766 Message Handler A Message Handler is another name for an 767 Intermediary. 769 Message Receiver In the transmission of an email message from one 770 ADMD to another, this is the organization receiving the message on 771 behalf of the intended recipient or end user. The Message 772 Receiver may do this because the intended recipient is an employee 773 or member of the organization, or because the end user utilizes 774 email services provided by the Message Receiver (Comcast, GMail, 775 Yahoo, QQ, et cetera). 777 Message Sender In the transmission of an email message from one ADMD 778 to another, this is the organization sending the message on behalf 779 of the Originator or end user. 781 Originator This refers to the author of a given email message. In 782 different contexts it may refer to the end-user writing the 783 message, or the ADMD providing email services to that end-user. 785 Reputation In the larger context of email hygiene - blocking spam 786 and malicious messages - reputation generally refers to a wide 787 variety of techniques and mechanisms whereby a message receiver 788 uses the past actions of a sending host or domain to influence the 789 handling of messages received from them in the future. One of the 790 classic examples would be a Spamhaus-style DNSBL, where individual 791 IP addresses will be blocked from sending messages because they've 792 been identified as being bad actors. Very large message receivers 793 may build and maintain their own reputation systems of this kind, 794 whereas other organizations might choose to use commercial 795 products or free services. 797 Reputation Service Provider A Reputation Service Provider would be a 798 source of reputation information about a message sender. In this 799 context, the DNSBL services offered by Spamhaus would allow them 800 to be referred to as an RPS. Many spam and virus filtering 801 vendors incorporate similar functionality into their services. 803 Request For Comment (RFC) RFCs are memoranda that "contain technical 804 and organizational notes about the Internet." Created and managed 805 by the Internet Engineering Task Force (IETF), they are de facto 806 standards for various methods of communicating or collaborating 807 over the Internet. 809 RFC5321 - Simple Mail Transfer Protocol This document describes the 810 protocol used to transfer email messages between Message Transfer 811 Agents (MTA) over a network. Link: [RFC5321] 813 RFC5322 - Internet Message Format This document describes the format 814 of Internet email messages, including both the header fields 815 within the message and various types of content within the message 816 body. Link: [RFC5322] 818 Validator A Message Receiver that attempts to validate the ARC chain 819 in a message. 821 Appendix B. References 823 Appendix C. Acknowledgements 825 This draft is based on the work of OAR-Dev Group. 827 The authors thank the entire OAR-Dev group for the ongoing help, 828 innumerable diagrams and discussions from all the participants, 829 especially: Alex Brotman, Brandon Long, Dave Crocker, Elizabeth 830 Zwicky, Franck Martin, Greg Colburn, J. Trent Adams, John Rae-Grant, 831 Mike Hammer, Mike Jones, Steve Jones, Terry Zink, Tim Draegen. 833 This document was influenced by questions posed in the arc- 834 discuss@dmarc.org [7] mailing list, and the authors thank all the 835 list participants for their input. 837 Appendix D. Comments and Feedback 839 Please address all comments, discussions, and questions about this 840 document, or about [ARC] itself, to the dmarc working group at 841 https://datatracker.ietf.org/wg/dmarc [8]. 843 Readers looking for general information about ARC may refer to the 844 website https://arc-spec.org [9], or to the arc-discuss@dmarc.org 845 [10] mailing list at http://lists.dmarc.org/mailman/listinfo/arc- 846 discuss [11]. 848 Authors' Addresses 849 Steven M Jones (editor) 850 DMARC.org 851 2419 McGee Avenue 852 Berkeley, California 94703 853 USA 855 Email: smj@crash.com 857 Kurt Andersen 858 LinkedIn 859 2029 Stierlin Ct. 860 Mountain View, California 94043 861 USA 863 Email: kurta@linkedin.com