idnits 2.17.1 draft-ietf-dmarc-arc-usage-05.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 Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 23, 2018) is 2196 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 557 == Unused Reference: 'RFC6377' is defined on line 517, but no explicit reference was found in the text == Unused Reference: 'RFC7601' is defined on line 521, but no explicit reference was found in the text == Unused Reference: 'ENHANCED-STATUS' is defined on line 533, but no explicit reference was found in the text == Unused Reference: 'OAR' is defined on line 538, 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-10 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMARC Working Group S. Jones 3 Internet-Draft DMARC.org 4 Intended status: Informational K. Andersen 5 Expires: October 25, 2018 LinkedIn 6 J. Rae-Grant 7 Google 8 T. Adams, Ed. 9 Paypal 10 April 23, 2018 12 Recommended Usage of the Authenticated Received Chain (ARC) 13 draft-ietf-dmarc-arc-usage-05 15 Abstract 17 The Authentication Received Chain (ARC) provides a means to preserve 18 email authentication results and verify the identity of email message 19 handlers, each of which participates by inserting certain header 20 fields before passing the message on. But the specification does not 21 indicate how intermediaries and receivers should interpret or utilize 22 ARC. This document will provide guidance in these areas. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on October 25, 2018. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. How does ARC work? . . . . . . . . . . . . . . . . . . . . . 3 60 3. Guidance for Receivers/Validators . . . . . . . . . . . . . . 4 61 3.1. What is the significance of an intact ARC chain? . . . . 4 62 3.2. What exactly is an "intact" ARC chain? . . . . . . . . . 4 63 3.3. What is the significance of an invalid ("broken") ARC 64 chain? . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.4. What does the absence of an ARC chain in a message mean? 5 66 3.5. What reasonable conclusions can you draw based upon 67 seeing lots of mail with ARC chains? . . . . . . . . . . 6 68 3.6. What if none of the intermediaries have been seen 69 previously? . . . . . . . . . . . . . . . . . . . . . . . 6 70 3.7. What about ARC chains where some intermediaries are known 71 and others are not? . . . . . . . . . . . . . . . . . . . 6 72 3.8. What should message handlers do when they detect 73 malicious content in messages where ARC is present? . . . 7 74 3.9. What feedback does a sender or domain owner get about ARC 75 when it is applied to their messages? . . . . . . . . . . 7 76 3.10. What prevents a malicious actor from removing the ARC 77 header fields, altering the content, and creating a new 78 ARC chain? . . . . . . . . . . . . . . . . . . . . . . . 7 79 4. Guidance for Intermediaries . . . . . . . . . . . . . . . . . 8 80 4.1. What is an Intermediary under ARC? . . . . . . . . . . . 8 81 4.2. What are the minimum requirements for an ARC 82 Intermediary? . . . . . . . . . . . . . . . . . . . . . . 8 83 4.2.1. More specifically a participating ARC intermediary 84 must do the following: . . . . . . . . . . . . . . . 8 85 4.3. Should every MTA be an ARC participant? . . . . . . . . . 9 86 4.4. What should an intermediary do in the case of an invalid 87 or "broken" ARC chain? . . . . . . . . . . . . . . . . . 9 88 4.5. What should I do in the case where there is no ARC chain 89 present in a message? . . . . . . . . . . . . . . . . . . 9 90 4.6. How could ARC affect my reputation as an intermediary? . 9 91 4.7. What can I do to influence my reputation as an 92 intermediary? . . . . . . . . . . . . . . . . . . . . . . 10 93 5. Guidance for Originators . . . . . . . . . . . . . . . . . . 10 94 5.1. Where can I find out more information? . . . . . . . . . 10 95 5.2. How/where can I test interoperabililty for my 96 implementation? . . . . . . . . . . . . . . . . . . . . . 10 98 5.3. How can ARC impact my email? . . . . . . . . . . . . . . 10 99 5.4. How can ARC impact my reputation as a message sender? . . 11 100 5.5. Can I tell intermediaries not to use ARC? . . . . . . . . 11 101 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 102 6.1. Normative References . . . . . . . . . . . . . . . . . . 11 103 6.2. Informative References . . . . . . . . . . . . . . . . . 12 104 6.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 12 105 Appendix A. GLOSSARY . . . . . . . . . . . . . . . . . . . . . . 12 106 Appendix B. References . . . . . . . . . . . . . . . . . . . . . 15 107 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 15 108 Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 15 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 111 1. Introduction 113 [ARC] is intended to be used primarily by intermediaries, or message 114 handlers - those parties who may forward or resend messages, with or 115 without alterations, such that they will no longer pass the SPF, 116 DKIM, and/or [RFC7489] authentication mechanisms. In such cases ARC 117 may provide the final message recipient with useful information about 118 the original sender. 120 2. How does ARC work? 122 Consider a mailing list as an example, where the message submitter's 123 domain publishes a DMARC policy other than "p=none". The message is 124 received, a prefix is added to the RFC5322.Subject header field, some 125 text is appended to the message body, and the message is sent to list 126 members with the original RFC5322.From address intact. In this case 127 SPF may pass because the mailing list operator uses their own domain 128 in the RFC5321.MailFrom header field, but this domain will not match 129 the RFC5322.From address, thus the DMARC SPF result cannot be a 130 "pass." Any DKIM signature from the message submitter's domain will 131 be broken as the message body has been altered (and if included in 132 the signature, the RFC5322.Subject header field). Again, the DMARC 133 DKIM result cannot be a "pass." And if the mailing list operator 134 inserted an Authentication-Results header field it was most likely 135 stripped and/or replaced by the next message receiver. 137 If the mailing list implemented ARC, it would record the contents of 138 the Authentication-Results header field in the ARC-Authentication- 139 Results header field. It would then create an an ARC-Message- 140 Signature header field, which includes a cryptographic signature of 141 the message itself, and then an ARC-Seal header field, which includes 142 a cryptographic signature of a few key message header fields - 143 including the other ARC header fields. 145 Any subsequent system participating in ARC that was not performing 146 final delivery of the message within its ADMD boundaries would also 147 generate and insert ARC header fields whose signatures cover all ARC 148 header fields inserted into the message by previous message handlers. 149 Thus the information from any previous ARC participants, including 150 the ARC-Authentication-Results header field from the mailing list 151 operator, would be signed at each ADMD that handled the message. 153 When the message reaches the final receiving system, the SPF and DKIM 154 results will not satisfy the DMARC policy for the message author's 155 domain. However if the receiving system implements ARC then it can 156 check for and validate an ARC chain and verify that the contents of 157 the ARC-Authentication-Results header field were conveyed intact from 158 the mailing list operator. At that point the receiving system might 159 choose to use those authentication results in the decision of whether 160 or not to deliver the message, even though it failed to pass the 161 usual authentication checks. 163 3. Guidance for Receivers/Validators 165 3.1. What is the significance of an intact ARC chain? 167 An intact ARC chain conveys authentication results like SPF and DKIM 168 as observed by the first ARC participant. In cases where the message 169 no longer produces passing results for DKIM, SPF, or DMARC but an 170 intact ARC chain is present, the message receiver may choose to use 171 the contents of the ARC-Authentication-Results header field in 172 determining how to handle the message. 174 3.2. What exactly is an "intact" ARC chain? 176 Note that not all ADMDs will implement ARC, and receivers will see 177 messages where one or more non-participating ADMDs handled a message 178 before, after, or in between participating ADMDs. 180 An intact ARC chain is one where the ARC header fields that are 181 present can be validated, and in particular the ARC-Message-Signature 182 header field from the last ARC participant can still be validated. 183 This shows that, whether another ADMD handled the message after the 184 last ARC participant or not, the portions of the message covered by 185 that signature were not altered. If any non-participating ADMDs 186 handled the message between ARC intermediaries but did not alter the 187 message in a way that invalidated the most recent ARC-Message- 188 Signature present at that time, the chain would still be considered 189 intact by the next ARC participant, and recorded as such in the ARC- 190 Seal header field they insert. 192 Message receivers may make local policy decisions about whether to 193 use the contents of the ARC-Authentication-Results header field in 194 cases where a message no longer passes DKIM, DMARC, and/or SPF 195 checks. Whether an ARC chain is intact can be used to inform that 196 local policy decision. 198 So for example one message receiver may decide that, for messages 199 with an intact ARC chain where a DMARC evaluation does not pass, but 200 the ARC-Authentication-Results header field indicates a DKIM pass was 201 reported by the first ARC intermediary that matches the domain in the 202 RFC5322.From header field, it will override a DMARC "p=reject" 203 policy. Another message receiver may decide to do so for intact ARC 204 chains where the ARC-Authentication-Results header field indicates an 205 SPF pass. A third message receiver may use very different criteria, 206 according to their requirements, while a fourth may choose not to 207 take ARC information into account at all. 209 3.3. What is the significance of an invalid ("broken") ARC chain? 211 An ARC chain is broken if the signatures in the ARC-Seal header 212 fields cannot be verified or if the most recent AMS can not be 213 verified. For example the remote server delivering the message to 214 the local ADMD is not reflected in any ARC header fields, perhaps 215 because they have not implemented ARC, but they modified the message 216 such that ARC and DKIM signatures already in the message were 217 invalidated. 219 In case of a broken ARC chain, the message should be treated the same 220 as if there was no ARC chain at all. For example, a message that 221 fails under DMARC and has an invalid ARC chain would be subject to 222 that DMARC policy, which may cause it to be quarantined or rejected. 224 Email transit can produce broken signatures for a wide variety of 225 benign reasons. This includes possibly breaking one or more ARC 226 signatures. Therefore, receivers need to be wary of ascribing motive 227 to such breakage although patterns of common behaviour may provide 228 some basis for adjusting local policy decisions. 230 3.4. What does the absence of an ARC chain in a message mean? 232 The absence of an ARC chain means nothing. ARC is intended to allow 233 a participating message handler to preserve certain authentication 234 results when a message is being forwarded and/or modified such that 235 the final recipient can evaluate this information. If they are 236 absent, there is nothing extra that ARC requires the final recipient 237 to do. 239 3.5. What reasonable conclusions can you draw based upon seeing lots of 240 mail with ARC chains? 242 With sufficient history, ARC can be used to augment DMARC 243 authentication policy (i.e. a message could fail DMARC, but validated 244 ARC information and therefore could be considered as validly 245 authenticated as reported by the first ARC participant). 247 If the validator does content analysis and reputation tracking, the 248 ARC participants in a message can be credited or discredited for good 249 or bad content. By analyzing different ARC chains involved in "bad" 250 messages, a validator might identify malicious participating 251 intermediaries. 253 With a valid chain and good reputations for all ARC participants, 254 receivers may choose to apply a "local policy override" to the DMARC 255 policy assertion for the domain authentication evaluation, depending 256 on the ARC-Authentication-Results header field value. Normal content 257 analysis should never be skipped. 259 3.6. What if none of the intermediaries have been seen previously? 261 This has no impact on the operation of ARC, as ARC is not a 262 reputation system. ARC conveys the results of other authentication 263 mechanisms such that the participating message handlers can be 264 positively identified. Final message recipients may or may not 265 choose to examine these results when messages fail other 266 authentication checks. They are more likely to override, say, a 267 failing DMARC result in the presence of an intact ARC chain where the 268 participating ARC message handlers have been observed to not convey 269 "bad" content in the past, and the initial ARC participant indicates 270 the message they received had passed authentication checks. 272 3.7. What about ARC chains where some intermediaries are known and 273 others are not? 275 Validators may choose to build reputation models for ARC message 276 handlers they have observed. Generally speaking it is more feasible 277 to accrue positive reputation to intermediaries when they 278 consistently send messages that are evaluated positively in terms of 279 content and ARC chains. When messages are received with ARC chains 280 that are not intact, it is very difficult identify which 281 intermediaries may have manipulated the message or injected bad 282 content. 284 3.8. What should message handlers do when they detect malicious content 285 in messages where ARC is present? 287 Message handlers should do what they normally do when they detect 288 malicious content in a message - hopefully that means quarantining or 289 discarding the message. ARC information should never make malicious 290 content acceptable. 292 In such cases it is difficult to determine where the malicious 293 content may have been injected. What ARC can do in such cases is 294 verify that a given intermediary or message handler did in fact 295 handle the message as indicated in the header fields. In such cases 296 a message recipient who maintains a reputation system about email 297 senders may wish to incorporate this information as an additional 298 factor in the score for the intermediaries and sender in question. 299 However reputation systems are very complex, and usually unique to 300 those organizations operating them, and therefore beyond the scope of 301 this document. 303 3.9. What feedback does a sender or domain owner get about ARC when it 304 is applied to their messages? 306 ARC itself does not include any mechanism for feedback or reporting. 307 It does however recommend that message receiving systems that use ARC 308 to augment their delivery decisions, who use DMARC and decide to 309 deliver a message because of ARC information, should include a 310 notation to that effect in their normal DMARC reports. These 311 notations would be easily identifiable by report processors, so that 312 senders and domain owners can see where ARC is being used to augment 313 the deliverability of their messages. 315 3.10. What prevents a malicious actor from removing the ARC header 316 fields, altering the content, and creating a new ARC chain? 318 ARC does not prevent a malicious actor from doing this. Nor does it 319 prevent a malicious actor from removing all but the first ADMD's ARC 320 header fields and altering the message, eliminating intervening 321 participants from the ARC chain. Or similar variations. 323 A valid ARC chain does not provide any automatic benefit. With an 324 intact ARC chain, the final message recipient may choose to use the 325 contents of the ARC-Authentication-Results header field in 326 determining how to handle the message. The decision to use the ARC- 327 Authentication-Results header field is dependent on evaluation of 328 those ARC intermediaries. 330 In the first case, the bad actor has succeeded in manipulating the 331 message but they have attached a verifiable signature identifying 332 themselves. While not an ideal situation, it is something they are 333 already able to do without ARC involved, but now a signature linked 334 to the domain responsible for the manipulation is present. 336 Additionally in the second case it is possible some negative 337 reputational impact might accrue to the first ARC participant left in 338 place until more messages reveal the pattern of activity by the bad 339 actor. But again, a bad actor can similarly manipulate a sequence of 340 RFC5322.Received header fields today without ARC, but with ARC that 341 bad actor has verifiably identified themselves. 343 4. Guidance for Intermediaries 345 4.1. What is an Intermediary under ARC? 347 In the context of ARC, an Intermediary is typically an Administrative 348 Management Domain [RFC5598] that is receiving a message, potentially 349 manipulating or altering it, and then passing it on to another ADMD 350 for delivery. Common examples of Intermediaries are mailing lists, 351 alumni or professional email address providers that forward messages 352 such as universities or professional organizations, et cetera. 354 4.2. What are the minimum requirements for an ARC Intermediary? 356 A participating ARC intermediary must validate the ARC chain on a 357 message it receives, if one is present. It then attaches its own ARC 358 seal and signature, including an indication if the chain failed to 359 validate upon receipt. 361 4.2.1. More specifically a participating ARC intermediary must do the 362 following: 364 1. Validate that the ARC chain, if one is already present in the 365 message, is intact and well-formed. 367 2. Validate that the most recent sender matches the last entry in 368 the ARC chain (if present). 370 3. Validate that the most recent sender's DKIM signature is 371 attached, and matches the reference to it in the ARC chain (if 372 present). 374 4. Generate a new ARC Signature and add it to the message according 375 to the ARC specification. 377 5. Generate a new ARC Seal and add it to the message according to 378 the ARC specification. 380 4.3. Should every MTA be an ARC participant? 382 Generally speaking, ARC is designed to operate at the ADMD level. 383 When a message is first received by an ADMD, the traditional 384 authentication results should be captured and preserved - this could 385 be the common case of creating an Authentication-Results header 386 field. But when it is determined that the message is being sent on 387 outside of that ADMD, that is when the ADMD should add itself to the 388 ARC chain - before sending the message outside of the ADMD. 390 Some organizations may operate multiple ADMDs, with more or less 391 independence between them. While they should make a determination 392 based on their specific circumstances, it may be useful and 393 appropriate to have one or both ADMDs be ARC participants. 395 4.4. What should an intermediary do in the case of an invalid or 396 "broken" ARC chain? 398 In general terms, a participating ARC intermediary will note that an 399 ARC chain was present and invalid, or broken, when it attaches its 400 own ARC seal and signature. However the fact that the ARC chain was 401 invalid should have no impact on whether and how the message is 402 delivered. 404 4.5. What should I do in the case where there is no ARC chain present 405 in a message? 407 A participating ARC intermediary receiving a message with no ARC 408 chain, and which will be delivered outside its ADMD, should start an 409 ARC chain according to the ARC specification. This will include 410 capturing the normal email authentication results for the 411 intermediary (SPF, DKIM, DMARC, etc), which will be conveyed as part 412 of the ARC chain. 414 4.6. How could ARC affect my reputation as an intermediary? 416 Message receivers often operate reputation systems, which build a 417 behavioral profile of various message handlers and intermediaries. 418 The presence or absence of ARC is yet another data point that may be 419 used as an input to such reputation systems. Messages deemed to have 420 good content may provide a positive signal for the intermediaries 421 that handled it, while messages with bad content may provide a 422 negative signal for the those intermediaries. Intact and valid ARC 423 elements may amplify or attenuate such signals, depending on the 424 circumstances. 426 Reputation systems are complex and usually specific to a given 427 message receiver, and a meaningful discussion of such a broad topic 428 is beyond the scope of this document. 430 4.7. What can I do to influence my reputation as an intermediary? 432 Today it is extremely simple for a malicious actor to construct a 433 message that includes your identity as an intermediary, even though 434 you never handled the message. It is possible that an intermediary 435 implementing ARC on all traffic it handles might receive some 436 reputational benefit by making it easier to detect when their 437 involvement in conveying bad traffic has been "forged." 439 As mentioned previously reputation systems are very complex and 440 usually specific to a given message receiver, and a meaningful 441 discussion of such a broad topic is beyond the scope of this 442 document. 444 5. Guidance for Originators 446 5.1. Where can I find out more information? 448 Please join the arc-discuss list at arc-discuss@dmarc.org 449 [1][mailto:arc-discuss@dmarc.org]. 451 To discuss the IETF spec itself, please join the dmarc working group 452 at [https://datatracker.ietf.org/wg/dmarc]. 454 5.2. How/where can I test interoperabililty for my implementation? 456 The arc-discuss list is the best place to stay in touch with work in 457 progress. 459 5.3. How can ARC impact my email? 461 Prior to ARC, certain DMARC policies on a domain would cause messages 462 using those domains in the RFC5322.From field, and which pass through 463 certain kinds of intermediaries (mailing lists, forwarding services), 464 to fail authentication checks at the message receiver. As a result 465 these messages might not be delivered to the intended recipient. 467 ARC seeks to provide these so-called "indirect mailflows" with a 468 means to preserve email authentication results as recorded by 469 participating intermediaries. Message receivers may accept validated 470 ARC information to supplement the information that DMARC provides, 471 potentially deciding to deliver the message even though a DMARC check 472 did not pass. 474 The net result for domain owners and senders is that ARC may allow 475 messages routed through participating ARC intermediaries to be 476 delivered, even though those messages would not have been delivered 477 in the absence of ARC. 479 5.4. How can ARC impact my reputation as a message sender? 481 Message receivers often operate reputation systems, which build a 482 behavioral profile of various message senders (and perhaps 483 intermediaries). The presence or absence of ARC is yet another data 484 point that may be used as an input to such reputation systems. 485 Messages deemed to have good content may provide a positive signal 486 for the sending domain and the intermediaries that handled it, while 487 messages with bad content may provide a negative signal for the 488 sending domain and the intermediaries that handled it. Intact and 489 valid ARC elements may amplify or attenuate such signals, depending 490 on the circumstances. 492 Reputation systems are complex and usually specific to a given 493 message receiver, and a meaningful discussion of such a broad topic 494 is beyond the scope of this document. 496 5.5. Can I tell intermediaries not to use ARC? 498 At present there is no way for a message sender to request that 499 intermediaries not employ ARC. 501 6. References 503 6.1. Normative References 505 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 506 DOI 10.17487/RFC5321, October 2008, 507 . 509 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 510 DOI 10.17487/RFC5322, October 2008, 511 . 513 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 514 DOI 10.17487/RFC5598, July 2009, 515 . 517 [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and 518 Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377, 519 September 2011, . 521 [RFC7601] Kucherawy, M., "Message Header Field for Indicating 522 Message Authentication Status", RFC 7601, 523 DOI 10.17487/RFC7601, August 2015, 524 . 526 6.2. Informative References 528 [ARC] Andersen, K., Rae-Grant, J., Long, B., and S. Jones, 529 "Authenticated Received Chain (ARC) Protocol", December 530 2017, . 533 [ENHANCED-STATUS] 534 "IANA SMTP Enhanced Status Codes", n.d., 535 . 538 [OAR] Chew, M. and M. Kucherawy, "Original-Authentication- 539 Results Header Field", February 2012, 540 . 543 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 544 Message Authentication, Reporting, and Conformance 545 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 546 . 548 [RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky, 549 E., Ed., and K. Andersen, Ed., "Interoperability Issues 550 between Domain-based Message Authentication, Reporting, 551 and Conformance (DMARC) and Indirect Email Flows", 552 RFC 7960, DOI 10.17487/RFC7960, September 2016, 553 . 555 6.3. URIs 557 [1] mailto:arc-discuss@dmarc.org 559 Appendix A. GLOSSARY 561 ADMD Administrative Management Domain as used in [RFC5598] and 562 similar references refers to a single entity operating one or more 563 computers within one or more domain names under said entity's 564 control. One example might be a small company with a single 565 server, handling email for that company's domain. Another example 566 might be a large university, operating many servers that fulfill 567 different roles, all handling email for several different domains 568 representing parts of the university. 570 ARC ARC is an acronym: Authentication Results Chain - see also [ARC] 572 ARC-Seal An [RFC5322] message header field formed in compliance with 573 the ARC specification. It includes certain content from all prior 574 ARC participants, if there are any. 576 ARC-Message-Signature (also abbreviated as "AMS") An [RFC5322] 577 message header field formed in compliance with the [ARC] 578 specification. It includes certain content about the message as 579 it was received and manipulated by the intermediary who inserted 580 it. 582 ARC-Authentication-Results (also abbreviated as "AAR") An [RFC5322] 583 message header field formed in compliance with the [ARC] 584 specification. It includes certain content about the message as 585 it was received by the intermediary. 587 Authentication Results Chain (ARC) A system that allows a Message 588 Receiver to identify Intermediaries or Message Handlers who have 589 conveyed a particular message. For more information see the 590 Abstract of this document, or refer to [ARC]. 592 Domain Naming System Block List (DNSBL) This is a system widely used 593 in email filtering services whereby information about the past 594 activity of a set of hosts or domains indicates that messages 595 should not be accepted from them, or at least should be subject to 596 greater scrutiny before being accepted. Common examples would be 597 SpamCop, Spamhaus.org, SORBS, etc. 599 Email Service Provider (ESP) An Email Service Provider is typically 600 a vendor or partner firm that sends mail on behalf of another 601 company. They may use email addresses in Internet domains 602 belonging to the client or partner firm in various [RFC5321] 603 fields or [RFC5322] message header fields of the messages they 604 send on their behalf. 606 Intermediary In the context of [ARC], an Intermediary is typically 607 an Administrative Management Domain (per [RFC5598]) that is 608 receiving a message, potentially manipulating or altering it, and 609 then passing it on to another ADMD for delivery. Also see 610 [RFC7960] for more information and discussion. Common examples of 611 Intermediaries are mailing lists, alumni or professional email 612 address providers like universities or professional organizations, 613 et cetera. 615 Mail/Message Transfer Agent (MTA) This refers to software that sends 616 and receives email messsages across a network with other MTAs. 618 Often run on dedicated servers, common examples are Exim, 619 Microsoft Exchange, Postfix, and Sendmail. 621 Mailflow A group of messages that share features in common. Typical 622 examples would be all messages sent by a given Message Sender to a 623 Message Receiver, related to a particular announcement, a given 624 mailing list, et cetera. 626 Malicious Actor A Malicious Actor is a party, often an Intermediary, 627 that will take actions that seek to exploit or defraud the 628 ultimate recipient of the message, or subvert the network controls 629 and infrastructure of the Message Receiver. Typical examples 630 would be a spammer who forges content or attributes of a message 631 in order to evade anti-spam measures, or an entity that adds an 632 attachment containing a virus to a message. 634 Message Handler A Message Handler is another name for an 635 Intermediary. 637 Message Receiver In the transmission of an email message from one 638 ADMD to another, this is the organization receiving the message on 639 behalf of the intended recipient or end user. The Message 640 Receiver may do this because the intended recipient is an employee 641 or member of the organization, or because the end user utilizes 642 email services provided by the Message Receiver (Comcast, GMail, 643 Yahoo, QQ, et cetera). 645 Message Sender In the transmission of an email message from one ADMD 646 to another, this is the organization sending the message on behalf 647 of the Originator or end user. 649 Originator This refers to the author of a given email message. In 650 different contexts it may refer to the end-user writing the 651 message, or the ADMD providing email services to that end-user. 653 Reputation In the larger context of email hygiene - blocking spam 654 and malicious messages - reputation generally refers to a wide 655 variety of techniques and mechanisms whereby a message receiver 656 uses the past actions of a sending host or domain to influence the 657 handling of messages received from them in the future. One of the 658 classic examples would be a Spamhaus-style DNSBL, where individual 659 IP addresses will be blocked from sending messages because they've 660 been identified as being bad actors. Very large message receivers 661 may build and maintain their own reputation systems of this kind, 662 whereas other organizations might choose to use commercial 663 products or free services. 665 Reputation Service Provider A Reputation Service Provider would be a 666 source of reputation information about a message sender. In this 667 context, the DNSBL services offered by Spamhaus would allow them 668 to be referred to as an RPS. Many spam and virus filtering 669 vendors incorporate similar functionality into their services. 671 Request For Comment (RFC) RFCs are memoranda that "contain technical 672 and organizational notes about the Internet." Created and managed 673 by the Internet Engineering Task Force (IETF), they are de facto 674 standards for various methods of communicating or collaborating 675 over the Internet. 677 RFC5321 - Simple Mail Transfer Protocol This document describes the 678 protocol used to transfer email messages between Message Transfer 679 Agents (MTA) over a network. Link: [RFC5321] 681 RFC5322 - Internet Message Format This document describes the format 682 of Internet email messages, including both the header fields 683 within the message and various types of content within the message 684 body. Link: [RFC5322] 686 Validator A Message Receiver that attempts to validate the ARC chain 687 in a message. 689 Appendix B. References 691 Appendix C. Acknowledgements 693 This draft is the work of OAR-Dev Group. 695 The authors thanks the entire OAR-Dev group for the ongoing help, 696 innumerable diagrams and discussions from all the participants, 697 especially: Alex Brotman, Brandon Long, Dave Crocker, Elizabeth 698 Zwicky, Franck Martin, Greg Colburn, J. Trent Adams, John Rae-Grant, 699 Mike Hammer, Mike Jones, Steve Jones, Terry Zink, Tim Draegen. 701 Appendix D. Comments and Feedback 703 Please address all comments, discussions, and questions to the dmarc 704 working group at [https://datatracker.ietf.org/wg/dmarc]. 706 Authors' Addresses 708 Steven Jones 709 DMARC.org 711 Email: smj@crash.com 712 Kurt Andersen 713 LinkedIn 714 2029 Stierlin Ct. 715 Mountain View, California 94043 716 USA 718 Email: kurta@linkedin.com 720 John Rae-Grant 721 Google 723 Email: johnrg@google.com 725 J. Trent Adams (editor) 726 Paypal 728 Email: trent.adams@paypal.com