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