idnits 2.17.1 draft-kucherawy-dmarc-base-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 5, 2015) is 3366 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'CFWS' is mentioned on line 1685, but not defined == Missing Reference: 'THIS MEMO' is mentioned on line 2093, but not defined == Missing Reference: '0-9' is mentioned on line 3145, but not defined == Missing Reference: '0-4' is mentioned on line 3145, but not defined == Missing Reference: '0-5' is mentioned on line 3145, but not defined -- Obsolete informational reference (is this intentional?): RFC 5451 (ref. 'AUTH-RESULTS') (Obsoleted by RFC 7001) -- Obsolete informational reference (is this intentional?): RFC 5226 (ref. 'IANA-CONSIDERATIONS') (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Kucherawy, Ed. 3 Internet-Draft 4 Intended status: Informational E. Zwicky, Ed. 5 Expires: August 9, 2015 Yahoo! 6 February 5, 2015 8 Domain-based Message Authentication, Reporting and Conformance (DMARC) 9 draft-kucherawy-dmarc-base-13 11 Abstract 13 Domain-based Message Authentication, Reporting and Conformance 14 (DMARC) is a scalable mechanism by which a mail-originating 15 organization can express domain-level policies and preferences for 16 message validation, disposition, and reporting, that a mail receiving 17 organization can use to improve mail handling. 19 Originators of Internet Mail need to be able to associate reliable 20 and authenticated domain identifiers with messages, communicate 21 policies about messages that use those identifiers, and report about 22 mail using those identifiers. These abilities have several benefits: 23 Receivers can provide feedback to domain owners about the use of 24 their domains, which can provide valuable insight about the 25 management of internal operations and the presence of external domain 26 name abuse. 28 DMARC does not produce or encourage elevated delivery privilege of 29 authenticated email. DMARC is a mechanism for policy distribution 30 that enables increasingly strict handling of messages that fail 31 authentication checks, ranging from no action, through altered 32 delivery, up to message rejection. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on August 9, 2015. 50 Copyright Notice 52 Copyright (c) 2015 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 2.1. High-Level Goals . . . . . . . . . . . . . . . . . . . . . 7 70 2.2. Out Of Scope . . . . . . . . . . . . . . . . . . . . . . . 7 71 2.3. Scalability . . . . . . . . . . . . . . . . . . . . . . . 7 72 2.4. Anti-Phishing . . . . . . . . . . . . . . . . . . . . . . 8 73 3. Terminology and Definitions . . . . . . . . . . . . . . . . . 8 74 3.1. Identifier Alignment . . . . . . . . . . . . . . . . . . . 9 75 3.2. Organizational Domain . . . . . . . . . . . . . . . . . . 12 76 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 4.1. Authentication Mechanisms . . . . . . . . . . . . . . . . 13 78 4.2. Key Concepts . . . . . . . . . . . . . . . . . . . . . . . 13 79 4.3. Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . 14 80 5. Use of RFC5322.From . . . . . . . . . . . . . . . . . . . . . 16 81 6. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 82 6.1. DMARC Policy Record . . . . . . . . . . . . . . . . . . . 17 83 6.2. DMARC URIs . . . . . . . . . . . . . . . . . . . . . . . . 17 84 6.3. General Record Format . . . . . . . . . . . . . . . . . . 18 85 6.4. Formal Definition . . . . . . . . . . . . . . . . . . . . 22 86 6.5. Domain Owner Actions . . . . . . . . . . . . . . . . . . . 23 87 6.6. Mail Receiver Actions . . . . . . . . . . . . . . . . . . 23 88 6.7. Policy Enforcement Considerations . . . . . . . . . . . . 27 89 7. DMARC Feedback . . . . . . . . . . . . . . . . . . . . . . . . 28 90 7.1. Verifying External Destinations . . . . . . . . . . . . . 28 91 7.2. Aggregate Reports . . . . . . . . . . . . . . . . . . . . 30 92 7.3. Failure Reports . . . . . . . . . . . . . . . . . . . . . 36 93 8. Minimum Implementations . . . . . . . . . . . . . . . . . . . 38 94 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 38 95 9.1. Data Exposure Considerations . . . . . . . . . . . . . . . 38 96 9.2. Report Recipients . . . . . . . . . . . . . . . . . . . . 39 97 10. Other Topics . . . . . . . . . . . . . . . . . . . . . . . . . 40 98 10.1. Issues Specific to SPF . . . . . . . . . . . . . . . . . . 40 99 10.2. DNS Load and Caching . . . . . . . . . . . . . . . . . . . 40 100 10.3. Rejecting Messages . . . . . . . . . . . . . . . . . . . . 41 101 10.4. Identifier Alignment Considerations . . . . . . . . . . . 42 102 10.5. Interoperability Issues . . . . . . . . . . . . . . . . . 42 103 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 104 11.1. Authentication-Results Method Registry Update . . . . . . 42 105 11.2. Authentication-Results Result Registry Update . . . . . . 43 106 11.3. Feedback Report Header Fields Registry Update . . . . . . 44 107 11.4. DMARC Tag Registry . . . . . . . . . . . . . . . . . . . . 45 108 11.5. DMARC Report Format Registry . . . . . . . . . . . . . . . 46 109 12. Security Considerations . . . . . . . . . . . . . . . . . . . 47 110 12.1. Authentication Methods . . . . . . . . . . . . . . . . . . 47 111 12.2. Attacks on Reporting URIs . . . . . . . . . . . . . . . . 47 112 12.3. DNS Security . . . . . . . . . . . . . . . . . . . . . . . 47 113 12.4. Display Name Attacks . . . . . . . . . . . . . . . . . . . 48 114 12.5. External Reporting Addresses . . . . . . . . . . . . . . . 49 115 12.6. Secure Protocols . . . . . . . . . . . . . . . . . . . . . 49 116 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50 117 13.1. Normative References . . . . . . . . . . . . . . . . . . . 50 118 13.2. Informative References . . . . . . . . . . . . . . . . . . 51 119 Appendix A. Technology Considerations . . . . . . . . . . . . . . 52 120 A.1. S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . . 52 121 A.2. Method Exclusion . . . . . . . . . . . . . . . . . . . . . 53 122 A.3. Sender Header Field . . . . . . . . . . . . . . . . . . . 53 123 A.4. Domain Existence Test . . . . . . . . . . . . . . . . . . 54 124 A.5. Issues With ADSP In Operation . . . . . . . . . . . . . . 54 125 A.6. Organizational Domain Discovery Issues . . . . . . . . . . 55 126 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 56 127 B.1. Identifier Alignment examples . . . . . . . . . . . . . . 56 128 B.2. Domain Owner example . . . . . . . . . . . . . . . . . . . 58 129 B.3. Mail Receiver Example . . . . . . . . . . . . . . . . . . 63 130 B.4. Utilization of Aggregate Feedback example . . . . . . . . 65 131 B.5. mailto Transport example . . . . . . . . . . . . . . . . . 65 132 Appendix C. DMARC XML Schema . . . . . . . . . . . . . . . . . . 66 133 Appendix D. Public Discussion . . . . . . . . . . . . . . . . . . 73 134 Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 73 135 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 73 137 1. Introduction 139 The Sender Policy Framework ([SPF]) and DomainKeys Identified Mail 140 ([DKIM]) provide domain-level authentication. They enable 141 cooperating email receivers to detect mail authorized to use the 142 domain name, which can permit differential handling. (A detailed 143 discussion of the threats these systems attempt to address can be 144 found in [DKIM-THREATS].) However, there has been no single widely 145 accepted or publicly available mechanism to communication of domain- 146 specific message handling policiies for receivers, or to request 147 reporting of authentication and disposition of received mail. Absent 148 the ability to obtain feedback reports, originators who have 149 implemented email authentication have difficulty determining how 150 effective their authentication is. As a consequence, use of 151 authentication failures to filter mail typically does not succeed. 153 Over time, one-on-one relationships were established between select 154 senders and receivers with privately communicated means to assert 155 policy and receive message traffic and authentication disposition 156 reporting. Although these ad hoc practices have been generally 157 successful, they require significant manual coordination between 158 parties, and this model does not scale for general use on the 159 Internet. 161 This document defines Domain-based Message Authentication, Reporting 162 and Conformance (DMARC), a mechanism by which email operators 163 leverage existing authentication and policy advertisement 164 technologies to enable both message-stream feedback and enforcement 165 of policies against unauthenticated email. 167 DMARC allows domain owners and receivers to collaborate by: 169 1. Providing receivers with assertions about domain owners' policies 171 2. Providing feedback to senders so they can monitor authentication 172 and judge threats 174 The basic outline of DMARC is: 176 1. Domain owners publish policy assertions about domains via the 177 DNS. 179 2. Receivers compare the RFC5322 From: address in the mail to the 180 SPF and DKIM results, if present, and the DMARC policy in DNS. 182 3. These receivers can use these results to determine how the mail 183 should be handled. 185 4. The receiver sends reports to the domain owner or its designee 186 about mail claiming to be from their domain. 188 Security terms used in this document are defined in [SEC-TERMS]. 190 DMARC differs from previous approaches to policy advertisement (e.g., 191 [SPF] and [ADSP]) in that: 193 o Authentication technologies are: 195 1. decoupled from any technology-specific policy mechanisms; and 197 2. used solely to establish reliable per-message domain-level 198 identifiers. 200 o Multiple authentication technologies are used to: 202 1. reduce the impact of transient authentication errors 204 2. reduce the impact of site-specific configuration errors and 205 deployment gaps 207 3. enable more use cases than any individual technology supports 208 alone 210 o Receiver-generated feedback is supported, allowing senders to 211 establish confidence in authentication practices. 213 o The domain name extracted from a message's RFC5322.From field is 214 the primary identifier in the DMARC mechanism. This identifier is 215 used in conjunction with the results of the underlying 216 authentication technologies to evaluate results under DMARC. 218 Experience with DMARC has revealed some issues of interoperability 219 with email in general that require due consideration before 220 deployment, particularly with configurations that can cause mail to 221 be rejected. These are discussed in Section 10. 223 2. Requirements 225 Specification of DMARC is guided by the following high-level goals, 226 security dependencies, detailed requirements, and items that are 227 documented as out-of-scope. 229 2.1. High-Level Goals 231 DMARC has the following high-level goals: 233 o Allow Domain Owners to assert the preferred handling of 234 authentication failures, for messages purporting to have 235 authorship within the domain. 237 o Allow Domain Owners to verify their authentication deployment. 239 o Minimize implementation complexity for both senders and receivers, 240 as well as the impact on handling and delivery of legitimate 241 messages. 243 o Reduce the amount of successfully delivered spoofed email. 245 o Work at Internet scale. 247 2.2. Out Of Scope 249 Several topics and issues are specifically out of scope for the 250 initial version of this work. This includes the following: 252 o different treatment of messages that are not authenticated versus 253 those that fail authentication; 255 o evaluation of anything other than RFC5322.From; 257 o multiple reporting formats; 259 o publishing policy other than via the DNS; 261 o reporting or otherwise evaluating other than the last-hop IP 262 address; 264 o attacks in the RFC5322.From field, also known as "display-name" 265 attacks; 267 o authentication of entities other than domains, since DMARC is 268 built upon SPF and DKIM which authenticate domains; and 270 o content analysis. 272 2.3. Scalability 274 Scalability is a major issue for systems that need to operate in a 275 system as widely deployed as current SMTP email. For this reason, 276 DMARC seeks to avoid the need for third parties or pre-sending 277 agreements between senders and receivers. This preserves the 278 positive aspects of the current email infrastructure. 280 Although DMARC does not introduce third party senders (namely 281 external agents authorized to send on behalf of an operator) to the 282 email handling flow, it also does not preclude them. Such third 283 parties are free to provide services in conjunction with DMARC. 285 2.4. Anti-Phishing 287 DMARC is designed to prevent bad actors from sending mail that claims 288 to come from legitimate senders, particularly senders of 289 transactional email (official mail that is about business 290 transactions). One of the primary uses of this kind of spoofed mail 291 is phishing (enticing users to provide information by pretending to 292 be the legitimate service requesting the information). Thus, DMARC 293 is significantly informed by ongoing efforts to enact large-scale, 294 Internet-wide, anti-phishing measures. 296 Although DMARC can only be used to combat specific forms of exact- 297 domain spoofing directly, the DMARC mechanism has been found to be 298 useful in the creation of reliable and defensible message streams. 300 DMARC does not attempt to solve all problems with spoofed or 301 otherwise fraudulent email. In particular, it does not address the 302 use of visually similar domain names ("cousin domains") or abuse of 303 the RFC5322 [MAIL].From human readable . 305 3. Terminology and Definitions 307 This section defines terms used in the rest of the document. 309 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 310 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 311 document are to be interpreted as described in [KEYWORDS]. 313 Readers are encouraged to be familiar with the contents of 314 [EMAIL-ARCH]. In particular, that document defines various roles in 315 the messaging infrastructure that can appear the same or separate in 316 various contexts. For example, a Domain Owner could, via the 317 messaging security mechanisms on which DMARC is based, delegate the 318 ability to send mail as the Domain Owner to a third party with 319 another role. This document does not address the distinctions among 320 such roles; the reader is encouraged to become familiar with that 321 material before continuing. 323 The following terms are also used: 325 Authenticated Identifiers: Domain-level identifiers that are 326 validated using authentication technologies are referred to as 327 "Authenticated Identifiers". See Section 4.1 for details about 328 the supported mechanisms. 330 Author Domain: The domain name of the apparent author, as extracted 331 from the RFC5322.From field. 333 Domain Owner: An entity or organization that owns a DNS domain. The 334 term "owns" here indicates that the entity or organization being 335 referenced holds the registration of that DNS domain. Domain 336 Owners range from complex, globally-distributed organizations, to 337 service providers working on behalf of non-technical clients, to 338 individuals responsible for maintaining personal domains. This 339 specification uses this term as analogous to an Administrative 340 Management Domain as defined in [EMAIL-ARCH]. It can also refer 341 to delegates, such as Report Receivers, when those are outside of 342 their immediate management domain. 344 Identifier Alignment: When the domain in the RFC5322.From address 345 matches a domain validated by SPF or DKIM (or both), it has 346 Identifier Alignment. 348 Mail Receiver: The entity or organization that receives and 349 processes email. Mail Receivers operate one or more Internet- 350 facing Mail Transport Agents (MTAs). 352 Organizational Domain: The domain that was registered with a domain 353 name registrar. In the absence of more accurate methods, 354 heuristics are used to determine this, since it is not always the 355 case that the registered domain name is simply a top-level DNS 356 domain plus one component (e.g., "example.com", where "com" is a 357 top-level domain). The Organizational Domain is determined by 358 applying the algorithm found in Section 3.2. 360 Report Receiver: An operator that receives reports from another 361 operator implementing the reporting mechanism described in this 362 document. Such an operator might be receiving reports about its 363 own messages, or reports about messages related to another 364 operator. This term applies collectively to the system components 365 that receive and process these reports and the organizations that 366 operate them. 368 3.1. Identifier Alignment 370 Email authentication technologies authenticate various (and 371 disparate) aspects of an individual message. For example, [DKIM] 372 authenticates the domain that affixed a signature to the message, 373 while [SPF] can authenticate either the domain that appears in the 374 RFC5321.MailFrom portion of [SMTP] or the RFC5321.EHLO/HELO domain, 375 or both. These may be different domains, and they are typically not 376 visible to the end user. 378 DMARC authenticates use of the RFC5322 [MAIL].From domain by 379 requiring that it matches (is aligned with) an Authenticated 380 Identifier. The RFC5322 [MAIL].From domain was selected as the 381 central identity of the DMARC mechanism because it is a required 382 message header field and therefore guaranteed to be present in 383 compliant messages, and most MUAs represent the RFC5322 [MAIL].From 384 field as the originator of the message and render some or all of this 385 header field's content to end users. 387 Thus, this field is the one used by end users to identify the source 388 of the message, and therefore is a prime target for abuse. Many 389 high-profile email sources, such as email service providers, require 390 that the sending agent have authenticated before email can be 391 generated. Thus, for these mailboxes, the mechanism described in 392 this document provides recipient end users with strong evidence that 393 the message was indeed originated by the agent they associate with 394 that mailbox, if the end user knows that these various protections 395 have been provided. 397 Domain names in this context are to be compared in a case-insensitive 398 manner, per [DNS-CASE]. 400 It is important to note that identifier alignment cannot occur with a 401 message that is not valid per [MAIL], particularly one with a 402 malformed, absent, or repeated RFC5322.From field, since in that case 403 there is no reliable way to determine a DMARC policy that applies to 404 the message. Accordingly, DMARC operation is predicated on the input 405 being a valid RFC5322 message object, and handling of such non- 406 compliant cases is outside of the scope of this specification. 407 Further discussion of this can be found in Section 6.6.1. 409 Each of the underlying authentication technologies that DMARC takes 410 as input yield authenticated domains as their outputs when they 411 succeed. From the perspective of DMARC, each can be operated in a 412 "strict" mode or a "relaxed" mode. A Domain Owner would normally 413 select "strict" mode if it wanted Mail Receivers to apply DMARC 414 processing only to messages bearing an RFC5322.From domain exactly 415 matching the domains those mechanisms will verify. Using "relaxed" 416 mode can be used when the operator also wishes to affect message 417 flows bearing subdomains of the verified domains. 419 3.1.1. DKIM-authenticated Identifiers 421 DMARC permits identifier alignment, based on the result of a DKIM 422 authentication, to be strict or relaxed. (Note that these are not 423 related to DKIM's "simple" and "relaxed" canonicalization modes.) 425 In relaxed mode, the Organizational Domains of both the [DKIM]- 426 authenticated signing domain (taken from the value of the "d=" tag in 427 the signature) and that of the RFC5322.From domain must be equal if 428 the identifiers are to be considered aligned. In strict mode, only 429 an exact match between both of the Fully Qualified Domain Names 430 (FQDN) is considered to produce identifier alignment. 432 To illustrate, in relaxed mode, if a validated DKIM signature 433 successfully verifies with a "d=" domain of "example.com", and the 434 RFC5322.From address is "alerts@news.example.com", the DKIM "d=" 435 domain and the RFC5322.From domain are considered to be "in 436 alignment". In strict mode, this test would fail since the "d=" 437 domain does not exactly match the FQDN of the address. 439 However, a DKIM signature bearing a value of "d=com" would never 440 allow an "in alignment" result as "com" should appear on all public 441 suffix lists (see Appendix A.6.1), and therefore cannot be an 442 Organizational Domain. 444 Identifier alignment is required because a message can bear a valid 445 signature from any domain, including domains used by a mailing list 446 or even a bad actor. Therefore, merely bearing a valid signature is 447 not enough to infer authenticity of the Author Domain. 449 Note that a single email can contain multiple DKIM signatures, and it 450 is considered to be a DMARC "pass" if any DKIM signature is aligned 451 and verifies. 453 3.1.2. SPF-authenticated Identifiers 455 DMARC permits identifier alignment, based on the result of an SPF 456 authentication, to be strict or relaxed. 458 In relaxed mode, the [SPF]-authenticated domain and RFC5322.From 459 domain must have the same Organizational Domain. In strict mode, 460 only an exact DNS domain match is considered to produce identifier 461 alignment. 463 Note that the RFC5321.HELO identity is not typically used in the 464 context of DMARC (except when required to "fake" an otherwise null 465 reverse-path), even though a "pure SPF" implementation according to 466 [SPF] would check that identifier. 468 For example, if a message passes an SPF check with an 469 RFC5321.MailFrom domain of "cbg.bounces.example.com", and the address 470 portion of the RFC5322.From field contains "payments@example.com", 471 the Authenticated RFC5321.MailFrom domain identifier and the 472 RFC5322.From domain are considered to be "in alignment" in relaxed 473 mode, but not in strict mode. 475 3.1.3. Alignment and Extension Technologies 477 If in the future DMARC is extended to include the use of other 478 authentication mechanisms, the extensions will need to allow for 479 domain identifier extraction so that alignment with the RFC5322.From 480 domain can be verified. 482 3.2. Organizational Domain 484 The Organizational Domain is determined using the following 485 algorithm: 487 1. Acquire a "public suffix" list, i.e., a list of DNS domain names 488 reserved for registrations. Some country TLDs make specific 489 registration requirements, e.g. the United Kingdom places company 490 registrations under ".co.uk"; other TLDs such as ".com" appear in 491 the IANA registry of top-level DNS domains. A public suffix list 492 is the union of all of these. Appendix A.6.1 contains some 493 discussion about obtaining a public suffix list. 495 2. Break the subject DNS domain name into a set of "n" ordered 496 labels. Number these labels from right-to-left; e.g. for 497 "example.com", "com" would be label 1 and "example" would be 498 label 2. 500 3. Search the public suffix list for the name that matches the 501 largest number of labels found in the subject DNS domain. Let 502 that number be "x". 504 4. Construct a new DNS domain name using the name that matched from 505 the public suffix list and prefixing to it the "x+1"th label from 506 the subject domain. This new name is the Organizational Domain. 508 Thus, since "com" is an IANA-registered TLD, a subject domain of 509 "a.b.c.d.example.com" would have an Organizational Domain of 510 "example.com". 512 The process of determining a suffix is currently a heuristic one. No 513 list is guaranteed to be accurate or current. 515 4. Overview 517 This section provides a general overview of the design and operation 518 of the DMARC environment. 520 4.1. Authentication Mechanisms 522 The following mechanisms for determining Authenticated Identifiers 523 are supported in this version of DMARC: 525 o [DKIM], which provides a domain-level identifier in the content of 526 the "d=" tag of a validated DKIM-Signature header field. 528 o [SPF], which can authenticate both the domain found in an [SMTP] 529 HELO/EHLO command (the HELO identity) and the domain found in an 530 SMTP MAIL command (the MAIL FROM identity). DMARC uses the result 531 of SPF authentication of the MAIL FROM identity. Section 2.4 of 532 [SPF] describes MAIL FROM processing for cases in which the MAIL 533 command has a null path. 535 4.2. Key Concepts 537 DMARC policies are published by the Domain Owner, and retrieved by 538 the Mail Receiver during the SMTP session, via the DNS. 540 DMARC's filtering function is based on whether the RFC5322.From field 541 domain is aligned with (matches) an authenticated domain name from 542 SPF or DKIM. When a DMARC policy is published for the domain name 543 found in the RFC5322.From field, and that domain name is not 544 validated through SPF or DKIM, the disposition of that message can be 545 affected by that DMARC policy when delivered to a participating 546 receiver. 548 It is important to note that the authentication mechanisms employed 549 by DMARC authenticate only a DNS domain, and do not authenticate the 550 local-part of any email address identifier found in a message, nor 551 does it validate the legitimacy of message content. 553 DMARC's feedback component involves the collection of information 554 about received messages claiming to be from the Organizational Domain 555 for periodic aggregate reports to the Domain Owner. The parameters 556 and format for such reports are discussed in later sections of this 557 document. 559 A DMARC-enabled Mail Receiver might also generate per-message reports 560 that contain information related to individual messages that fail SPF 561 and/or DKIM. Per-message failure reports are a useful source of 562 information when debugging deployments (if messages can be determined 563 to be legitimate even though failing authentication) or in analyzing 564 attacks. The capability for such services is enabled by DMARC but 565 defined in other referenced material such as [AFRF]. 567 A message satisfies the DMARC checks if at least one of the supported 568 authentication mechanisms: 570 1. produces a "pass" result; and 572 2. produces that result based on an identifier that is in alignment, 573 as defined in Section 3. 575 4.3. Flow Diagram 577 +---------------+ 578 | Author Domain |< . . . . . . . . . . . . . . . . . . . . . . . 579 +---------------+ . . . 580 | . . . 581 V V V . 582 +-----------+ +--------+ +----------+ +----------+ . 583 | MSA |<***>| DKIM | | DKIM | | SPF | . 584 | Service | | Signer | | Verifier | | Verifier | . 585 +-----------+ +--------+ +----------+ +----------+ . 586 | ^ ^ . 587 | ************** . 588 V * . 589 +------+ (~~~~~~~~~~~~) +------+ * . 590 | sMTA |------->( other MTAs )----->| rMTA | * . 591 +------+ (~~~~~~~~~~~~) +------+ * . 592 | * ........ 593 | * . 594 V * . 595 +-----------+ V V 596 +---------+ | MDA | +----------+ 597 | User |<--| Filtering |<***>| DMARC | 598 | Mailbox | | Engine | | Verifier | 599 +---------+ +-----------+ +----------+ 601 The above diagram shows a simple flow of messages through a DMARC- 602 aware system. Solid lines denote the actual message flow, dotted 603 lines involve Domain Name System queries used to retrieve message 604 policy related to the supported message authentication schemes, and 605 asterisk lines indicate data exchange between message handling 606 modules and message authentication modules. "sMTA" is the sending 607 MTA, and "rMTA" is the receiving MTA. 609 In essence the steps are as follows: 611 1. Domain Owner constructs an SPF policy and publishes it in its 612 DNS database as per [SPF]. Domain Owner also configures its 613 system for DKIM signing as described in [DKIM]. Finally, Domain 614 Owner publishes via the DNS a DMARC message handling policy. 616 2. Author generates a message and hands the message to Domain 617 Owner's designated mail submission service. 619 3. Submission service passes relevant details to the DKIM signing 620 module in order to generate a DKIM signature to be applied to 621 the message. 623 4. Submission service relays the now-signed message to its 624 designated transport service for routing to its intended 625 recipient(s). 627 5. Message may pass through other relays, but eventually arrives at 628 a recipient's transport service. 630 6. Recipient delivery service conducts SPF and DKIM authentication 631 checks by passing the necessary data to their respective 632 modules, each of which require queries to the Author Domain's 633 DNS data (when identifiers are aligned; see below). 635 7. The results of these are passed to the DMARC module along with 636 the Author's domain. The DMARC module attempts to retrieve a 637 policy from the DNS for that domain. If none is found, the 638 DMARC module determines the Organizational Domain and repeats 639 the attempt to retrieve a policy from the DNS. (This is 640 described in further detail in Section 6.6.3.) 642 8. If a policy is found, it is combined with the Author's domain 643 and the SPF and DKIM results to produce a DMARC policy result (a 644 "pass" or "fail"), and can optionally cause one of two kinds of 645 reports to be generated (not shown). 647 9. Recipient transport service either delivers the message to the 648 recipient inbox, or takes other local policy action based on the 649 DMARC result (not shown). 651 10. When requested, Recipient transport service collects data from 652 the message delivery session to be used in providing feedback 653 (see Section 7). 655 5. Use of RFC5322.From 657 One of the most obvious points of security scrutiny for DMARC is the 658 choice to focus on an identifier, namely the RFC5322.From address, 659 which is part of a body of data that has been trivially forged 660 throughout the history of email. 662 Several points suggest it is the most correct and safest thing to do 663 in this context: 665 o Of all the identifiers that are part of the message itself, this 666 is the only one guaranteed to be present. 668 o It seems the best choice of an identifier on which to focus as 669 most MUAs display some or all of the contents of that field in a 670 manner strongly suggesting those data as reflective of the true 671 originator of the message. 673 The absence of a single, properly-formed RFC5322.From field renders 674 the message invalid. Handling of such a message is outside of the 675 scope of this specification. 677 Since the sorts of mail typically protected by DMARC participants 678 tend to only have single Authors, DMARC participants generally 679 operate under a slightly restricted profile of RFC5322 with respect 680 to the expected syntax of this field. See Section 6.6 for details. 682 6. Policy 684 DMARC policies are published by Domain Owners and applied by Mail 685 Receivers. 687 A Domain Owner advertises DMARC participation of one or more of its 688 domains by adding a DNS TXT record (described in Section 6.1) to 689 those domains. In doing so, Domain Owners make specific requests of 690 Mail Receivers regarding the disposition of messages purporting to be 691 from one of the Domain Owner's domains and the provision of feedback 692 about those messages. 694 A Domain Owner may choose not to participate in DMARC evaluation by 695 Mail Receivers. In this case, the Domain Owner simply declines to 696 advertise participation in those schemes. For example, if the 697 results of path authorization checks ought not be considered as part 698 of the overall DMARC result for a given Author Domain, then the 699 Domain Owner does not publish an SPF policy record that can produce 700 an SPF pass result. 702 A Mail Receiver implementing the DMARC mechanism SHOULD make a best- 703 effort attempt to adhere to the Domain Owner's published DMARC policy 704 when a message fails the DMARC test. Since email streams can be 705 complicated (due to forwarding, existing RFC5322.From domain-spoofing 706 services, etc.), Mail Receivers MAY deviate from a Domain Owner's 707 published policy during message processing and SHOULD make available 708 the fact of and reason for the deviation to the Domain Owner via 709 feedback reporting, specifically using the "PolicyOverride" feature 710 of the aggregate report (see Section 7.2). 712 6.1. DMARC Policy Record 714 Domain Owner DMARC preferences are stored as DNS TXT records in 715 subdomains named "_dmarc". For example, the Domain Owner of 716 "example.com" would post DMARC preferences in a TXT record at 717 "_dmarc.example.com". Similarly, a Mail Receiver wishing to query 718 for DMARC preferences regarding mail with an RFC5322.From domain of 719 "example.com" would issue a TXT query to the DNS for the subdomain of 720 "_dmarc.example.com". The DNS-located DMARC preference data will 721 hereafter be called the "DMARC record". 723 DMARC's use of the Domain Name Service is driven by DMARC's use of 724 domain names and the nature of the query it performs. The query 725 requirement matches with the DNS, for obtaining simple parametric 726 information. It uses an established method of storing the 727 information, associated with the target domain name, namely an 728 isolated TXT record that is restricted to the DMARC context. Use of 729 the DNS as the query service has the benefit of re-using an extremely 730 well-established operations, administration and management 731 infrastructure, rather than creating a new one. 733 Per [DNS], a TXT record can comprise several "character-string" 734 objects. Where this is the case, the module performing DMARC 735 evaluation MUST concatenate these strings by joining together the 736 objects in order and parsing the result as a single string. 738 6.2. DMARC URIs 740 [URI] defines a generic syntax for identifying a resource. The DMARC 741 mechanism uses this as the format by which a Domain Owner specifies 742 the destination for the two report types (RUA and RUF) that are 743 supported. 745 The place such URIs are specified (see Section 6.3) allows a list of 746 these to be provided. A report is normally sent to each listed URI 747 in the order provided by the Domain Owner. Receivers MAY impose a 748 limit on the number of URIs to which they will send reports, but MUST 749 support the ability to send to at least two. The list of URIs is 750 separated by commas (ASCII 0x2C). 752 Each URI can have associated with it a maximum report size that may 753 be sent to it. This is accomplished by appending an exclamation 754 point (ASCII 0x21), followed by a maximum size indication, before a 755 separating comma or terminating semi-colon. 757 Thus, a DMARC URI is a URI within which any commas or exclamation 758 points are percent-encoded per [URI], followed by an OPTIONAL 759 exclamation point and a maximum size specification, and, if there are 760 additional reporting URIs in the list, a comma and the next URI. 762 For example, the URI "mailto:reports@example.com!50m" would request a 763 report be sent via email to "reports@example.com" so long as the 764 report payload does not exceed 50 megabytes. 766 A formal definition is provided in Section 6.4. 768 6.3. General Record Format 770 DMARC records follow the extensible "tag-value" syntax for DNS-based 771 key records defined in DKIM [DKIM]. 773 Section 11 creates a registry for known DMARC tags and registers the 774 initial set defined in this document. Only tags defined in this 775 document or in later extensions, and thus added to that registry, are 776 to be processed; unknown tags MUST be ignored. 778 The following tags are introduced as the initial valid DMARC tags: 780 adkim: (plain-text; OPTIONAL, default is "r".) Indicates whether 781 strict or relaxed DKIM identifier alignment mode is required by 782 the Domain Owner. See Section 3.1.1 for details. Valid values 783 are as follows: 785 r: relaxed mode 787 s: strict mode 789 aspf: (plain-text; OPTIONAL, default is "r".) Indicates whether 790 strict or relaxed SPF identifier alignment mode is required by the 791 Domain Owner. See Section 3.1.2 for details. Valid values are as 792 follows: 794 r: relaxed mode 795 s: strict mode 797 fo: Failure reporting options (plain-text; OPTIONAL, default "0") 798 Provides requested options for generation of failure reports. 799 Report generators MAY choose to adhere to the requested options. 800 This tag's content MUST be ignored if a "ruf" tag (below) is not 801 also specified. The value of this tag is a colon-separated list 802 of characters that indicate failure reporting options as follows: 804 0: Generate a DMARC failure report if all underlying 805 authentication mechanisms fail to produce an aligned "pass" 806 result. 808 1: Generate a DMARC failure report if any underlying 809 authentication mechanism produced something other than an 810 aligned "pass" result. 812 d: Generate a DKIM failure report if the message had a signature 813 that failed evaluation, regardless of its alignment. DKIM- 814 specific reporting is described in [AFRF-DKIM]. 816 s: Generate an SPF failure report if the message failed SPF 817 evaluation, regardless of its alignment. SPF-specific 818 reporting is described in [AFRF-SPF]. 820 p: Requested Mail Receiver policy (plain-text; REQUIRED for policy 821 records). Indicates the policy to be enacted by the Receiver at 822 the request of the Domain Owner. Policy applies to the domain 823 queried and to sub-domains unless sub-domain policy is explicitly 824 described using the "sp" tag. This tag is mandatory for policy 825 records only, but not for third-party reporting records (see 826 Section 7.1). Possible values are as follows: 828 none: The Domain Owner requests no specific action be taken 829 regarding delivery of messages. 831 quarantine: The Domain Owner wishes to have email that fails the 832 DMARC mechanism check to be treated by Mail Receivers as 833 suspicious. Depending on the capabilities of the Mail 834 Receiver, this can mean "place into spam folder", "scrutinize 835 with additional intensity", and/or "flag as suspicious". 837 reject: The Domain Owner wishes for Mail Receivers to reject 838 email that fails the DMARC mechanism check. Rejection SHOULD 839 occur during the SMTP transaction. See Section 10.3 for some 840 discussion of SMTP rejection methods and their implications. 842 pct: (plain-text integer between 0 and 100, inclusive; OPTIONAL; 843 default is 100). Percentage of messages from the Domain Owner's 844 mail stream to which the DMARC policy is to be applied. However, 845 this MUST NOT be applied to the DMARC-generated reports, all of 846 which must be sent and received unhindered. The purpose of the 847 "pct" tag is to allow Domain Owners to enact a slow rollout 848 enforcement of the DMARC mechanism. The prospect of "all or 849 nothing" is recognized as preventing many organizations from 850 experimenting with strong authentication-based mechanisms. See 851 Section 6.6.4 for details. Note that random selection based on 852 this percentage, such as the following pseudocode, is adequate: 854 if (random mod 100) < pct then 855 selected = true 856 else 857 selected = false 859 rf: Format to be used for message-specific failure reports (colon- 860 separated plain-text list of values; OPTIONAL; default "afrf"). 861 The value of this tag is a list of one or more report formats as 862 requested by the Domain Owner to be used when a message fails both 863 [SPF] and [DKIM] tests to report details of the individual 864 failure. The values MUST be present in the registry of reporting 865 formats defined in Section 11; a Mail Receiver observing a 866 different value SHOULD ignore it, or MAY ignore the entire DMARC 867 record. For this version, only "afrf" (defined in [AFRF]) is 868 presently supported. See Section 7.3 for details. For 869 interoperability, the AFRF format MUST be supported. 871 ri: Interval requested between aggregate reports (plain-text, 32-bit 872 unsigned integer; OPTIONAL; default 86400). Indicates a request 873 to Receivers to generate aggregate reports separated by no more 874 than the requested number of seconds. DMARC implementations MUST 875 be able to provide daily reports and SHOULD be able to provide 876 hourly reports when requested. However, anything other than a 877 daily report is understood to be accommodated on a best-effort 878 basis. 880 rua: Addresses to which aggregate feedback is to be sent (comma- 881 separated plain-text list of DMARC URIs; OPTIONAL). A comma or 882 exclamation point that is part of such a DMARC URI MUST be encoded 883 per Section 2.1 of [URI] so as to distinguish it from the list 884 delimiter or an OPTIONAL size limit. Section 7.1 discusses 885 considerations that apply when the domain name of a URI differs 886 from that of the domain advertising the policy. See Section 12.5 887 for additional considerations. Any valid URI can be specified. A 888 Mail Receiver MUST implement support for a "mailto:" URI, i.e. the 889 ability to send a DMARC report via electronic mail. If not 890 provided, Mail Receivers MUST NOT generate aggregate feedback 891 reports. URIs not supported by Mail Receivers MUST be ignored. 892 The aggregate feedback report format is described in Section 7.2. 894 ruf: Addresses to which message-specific failure information is to 895 be reported (comma-separated plain-text list of DMARC URIs; 896 OPTIONAL). If present, the Domain Owner is requesting Mail 897 Receivers to send detailed failure reports about messages that 898 fail the DMARC evaluation in specific ways (see the "fo" tag 899 above). The format of the message to be generated MUST follow 900 that specified in the "rf" tag. Section 7.1 discusses 901 considerations that apply when the domain name of a URI differs 902 from that of the domain advertising the policy. A Mail Receiver 903 MUST implement support for a "mailto:" URI, i.e. the ability to 904 send a DMARC report via electronic mail. If not provided, Mail 905 Receivers MUST NOT generate failure reports. See Section 12.5 for 906 additional considerations. 908 sp: Requested Mail Receiver policy for all subdomains (plain-text; 909 OPTIONAL). Indicates the policy to be enacted by the Receiver at 910 the request of the Domain Owner. It applies only to subdomains of 911 the domain queried and not to the domain itself. Its syntax is 912 identical to that of the "p" tag defined above. If absent, the 913 policy specified by the "p" tag MUST be applied for subdomains. 914 Note that "sp" will be ignored for DMARC records published on sub- 915 domains of Organizational Domains due to the effect of the DMARC 916 Policy Discovery mechanism described in Section 6.6.3. 918 v: Version (plain-text; REQUIRED). Identifies the record retrieved 919 as a DMARC record. It MUST have the value of "DMARC1". The value 920 of this tag MUST match precisely; if it does not or it is absent, 921 the entire retrieved record MUST be ignored. It MUST be the first 922 tag in the list. 924 A DMARC policy record MUST comply with the formal specification found 925 in Section 6.4 in that the "v" and "p" tags MUST be present and MUST 926 appear in that order. Unknown tags MUST be ignored. Syntax errors 927 in the remainder of the record SHOULD be discarded in favor of 928 default values (if any) or ignored outright. 930 Note that given the rules of the previous paragraph, addition of a 931 new tag into the registered list of tags does not itself require a 932 new version of DMARC to be generated (with a corresponding change to 933 the "v" tag's value), but a change to any existing tags does require 934 a new version of DMARC. 936 6.4. Formal Definition 938 The formal definition of the DMARC format using [ABNF] is as follows: 940 dmarc-uri = URI [ "!" 1*DIGIT [ "k" / "m" / "g" / "t" ] ] 941 ; "URI" is imported from [URI]; commas (ASCII 942 ; 0x2c) and exclamation points (ASCII 0x21) 943 ; MUST be encoded; the numeric portion MUST fit 944 ; within an unsigned 64-bit integer 946 dmarc-record = dmarc-version dmarc-sep 947 [dmarc-request] 948 [dmarc-sep dmarc-srequest] 949 [dmarc-sep dmarc-auri] 950 [dmarc-sep dmarc-furi] 951 [dmarc-sep dmarc-adkim] 952 [dmarc-sep dmarc-aspf] 953 [dmarc-sep dmarc-ainterval] 954 [dmarc-sep dmarc-fo] 955 [dmarc-sep dmarc-rfmt] 956 [dmarc-sep dmarc-percent] 957 [dmarc-sep] 958 ; components other than dmarc-version and 959 ; dmarc-request may appear in any order 961 dmarc-version = "v" *WSP "=" *WSP %x44 %x4d %x41 %x52 %x43 %x31 963 dmarc-sep = *WSP %3b *WSP 965 dmarc-request = "p" *WSP "=" *WSP 966 ( "none" / "quarantine" / "reject" ) 968 dmarc-srequest = "sp" *WSP "=" *WSP 969 ( "none" / "quarantine" / "reject" ) 971 dmarc-auri = "rua" *WSP "=" *WSP 972 dmarc-uri *(*WSP "," *WSP dmarc-uri) 974 dmarc-furi = "ruf" *WSP "=" *WSP 975 dmarc-uri *(*WSP "," *WSP dmarc-uri) 977 dmarc-adkim = "adkim" *WSP "=" *WSP 978 ( "r" / "s" ) 980 dmarc-aspf = "aspf" *WSP "=" *WSP 981 ( "r" / "s" ) 983 dmarc-ainterval = "ri" *WSP "=" *WSP 1*DIGIT 984 dmarc-fo = "fo" *WSP "=" *WSP 985 ( "0" / "1" / "d" / "s" ) 986 *(*WSP ":" *WSP ( "0" / "1" / "d" / "s" )) 988 dmarc-rfmt = "rf" *WSP "=" *WSP Keyword *(*WSP ":" Keyword) 989 ; registered reporting formats only 991 dmarc-percent = "pct" *WSP "=" *WSP 992 1*3DIGIT 994 "Keyword" is imported from Section 4.1.2 of [SMTP]. 996 A size limitation in a dmarc-uri, if provided, is interpreted as a 997 count of units followed by an OPTIONAL unit size ("k" for kilobytes, 998 "m" for megabytes, "g" for gigabytes, "t" for terabytes). Without a 999 unit, the number is presumed to be a basic byte count. Note that the 1000 units are considered to be powers of two; a kilobyte is 2^10, a 1001 megabyte is 2^20, etc. 1003 6.5. Domain Owner Actions 1005 To implement the DMARC mechanism, the only action required of a 1006 Domain Owner is the creation of the DMARC policy record in the DNS. 1007 However, in order to make meaningful use of DMARC, a Domain Owner 1008 must at minimum either establish an address to receive reports, or 1009 deploy authentication technologies and ensure identifier alignment. 1010 Most Domain Owners will want to do both. 1012 DMARC reports will be of significant size and the addresses that 1013 receive them are publicly visible, so we encourage Domain Owners to 1014 set up dedicated email addresses to receive and process reports, and 1015 to deploy abuse countermeasures on those email addresses as 1016 appropriate. 1018 Authentication technologies are discussed in [DKIM] (see also 1019 [DKIM-OVERVIEW] and [DKIM-DEPLOYMENT]) and [SPF]. 1021 6.6. Mail Receiver Actions 1023 This section describes receiver actions in the DMARC environment. 1025 6.6.1. Extract Author Domain 1027 The domain in the RFC5322.From field is extracted as the domain to be 1028 evaluated by DMARC. If the domain is encoded with UTF-8, the domain 1029 name must be converted to an A-label, as described in Section 2.3 of 1030 [IDNA], for further processing. 1032 In order to be processed by DMARC, a message typically needs to 1033 contain exactly one RFC5322 From: domain (a single From: field with a 1034 single domain in it). Not all messages meet this requirement, and 1035 handling of them is outside of the scope of this document. Typical 1036 exceptions, and they way they have been historically handled by DMARC 1037 participants, are as follows: 1039 o Messages with multiple RFC5322.From fields are typically rejected 1040 since that form is forbidden under RFC 5322 [MAIL]; 1042 o Messages bearing a single RFC5322.From field containing multiple 1043 addresses (and, thus, multiple domain names to be evaluated) are 1044 typically rejected because the sorts of mail normally protected by 1045 DMARC do not use this format; 1047 o Messages that have no RFC5322.From field at all are typically 1048 rejected since that form is forbidden under RFC 5322 [MAIL]; 1050 o Messages with an RFC5322.From field that contains no meaningful 1051 domains, such as RFC 5322 [MAIL]'s "group" syntax are typically 1052 ignored. 1054 The case of a syntactically valid multi-valued RFC5322.From field 1055 presents a particular challenge. The process in this case is to 1056 apply the DMARC check using each of those domains found in the 1057 RFC5322.From field as the Author Domain, and apply the most strict 1058 policy selected among the checks that fail. 1060 6.6.2. Determine Handling Policy 1062 To arrive at a policy for an individual message, Mail Receivers MUST 1063 perform the following actions or their semantic equivalents. Steps 1064 2-4 MAY be done in parallel, whereas steps 5 and 6 require input from 1065 previous steps. 1067 The steps are as follows: 1069 1. Extract the RFC5322.From domain from the message (as above). 1071 2. Query the DNS for a DMARC policy record. Continue if one is 1072 found, or terminate DMARC evaluation otherwise. See 1073 Section 6.6.3 for details. 1075 3. Perform DKIM signature verification checks. A single email could 1076 contain multiple DKIM signatures. The results of this step are 1077 passed to the remainder of the algorithm and MUST include the 1078 value of the "d=" tag from each checked DKIM signature. 1080 4. Perform SPF validation checks. The results of this step are 1081 passed to the remainder of the algorithm and MUST include the 1082 domain name used to complete the SPF check. 1084 5. Conduct identifier alignment checks. With authentication checks 1085 and policy discovery performed, the Mail Receiver checks if 1086 Authenticated Identifiers fall into alignment as described in 1087 Section 3. If one or more of the Authenticated Identifiers align 1088 with the RFC5322.From domain, the message is considered to pass 1089 the DMARC mechanism check. All other conditions (authentication 1090 failures, identifier mismatches) are considered to be DMARC 1091 mechanism check failures. 1093 6. Apply policy. Emails that fail the DMARC mechanism check are 1094 disposed of in accordance with the discovered DMARC policy of the 1095 Domain Owner. See Section 6.3 for details. 1097 Heuristics applied in the absence of use by a Domain Owner of either 1098 SPF or DKIM (e.g., [Best-Guess-SPF]) SHOULD NOT be used, as it may be 1099 the case that the Domain Owner wishes a Message Receiver not to 1100 consider the results of that underlying authentication protocol at 1101 all. 1103 DMARC evaluation can only yield a "pass" result after one of the 1104 underlying authentication mechanisms passes for an aligned 1105 identifier. If neither passes and one or both of them fails due to a 1106 temporary error, the Receiver evaluating the message is unable to 1107 conclude that the DMARC mechanism had a permanent failure; they 1108 therefore cannot apply the advertised DMARC policy. When otherwise 1109 appropriate, Receivers MAY send feedback reports regarding temporary 1110 errors. 1112 Handling of messages for which SPF and/or DKIM evaluation encounters 1113 a permanent DNS error is left to the discretion of the Mail Receiver. 1115 6.6.3. Policy Discovery 1117 As stated above, the DMARC mechanism uses DNS TXT records to 1118 advertise policy. Policy discovery is accomplished via a method 1119 similar to the method used for SPF records. This method and the 1120 important differences between DMARC and SPF mechanisms are discussed 1121 below. 1123 To balance the conflicting requirements of supporting wildcarding, 1124 allowing subdomain policy overrides, and limiting DNS query load, the 1125 following DNS lookup scheme is employed: 1127 1. Mail Receivers MUST query the DNS for a DMARC TXT record at the 1128 DNS domain matching the one found in the RFC5322.From domain in 1129 the message. A possibly empty set of records is returned. 1131 2. Records that do not start with a "v=" tag that identifies the 1132 current version of DMARC are discarded. 1134 3. If the set is now empty, the Mail Receiver MUST query the DNS for 1135 a DMARC TXT record at the DNS domain matching the Organizational 1136 Domain in place of the RFC5322.From domain in the message (if 1137 different). This record can contain policy to be asserted for 1138 subdomains of the Organizational Domain. A possibly empty set of 1139 records is returned. 1141 4. Records that do not start with a "v=" tag that identifies the 1142 current version of DMARC are discarded. 1144 5. If the remaining set contains multiple records or no records, 1145 policy discovery terminates and DMARC processing is not applied 1146 to this message. 1148 6. If a retrieved policy record does not contain a valid "p" tag, or 1149 contains an "sp" tag that is not valid, then: 1151 1. if an "rua" tag is present and contains at least one 1152 syntactically valid reporting URI, the Mail Receiver SHOULD 1153 act as if a record containing a valid "v" tag and "p=none" 1154 was retrieved, and continue processing; 1156 2. otherwise, the Mail Receiver applies no DMARC processing to 1157 this message. 1159 If the set produced by the mechanism above contains no DMARC policy 1160 record (i.e., any indication that there is no such record as opposed 1161 to a transient DNS error), Mail Receivers SHOULD NOT apply the DMARC 1162 mechanism to the message. 1164 Handling of DNS errors when querying for the DMARC policy record is 1165 left to the discretion of the Mail Receiver. For example, to ensure 1166 minimal disruption of mail flow, transient errors could result in 1167 delivery of the message ("fail open"), or they could result in the 1168 message being temporarily rejected (i.e., an SMTP 4yx reply) which 1169 invites the sending MTA to try again after the condition has possibly 1170 cleared, allowing a definite DMARC conclusion to be reached ("fail 1171 closed"). 1173 6.6.4. Message Sampling 1175 If the "pct" tag is present in the policy record, the Mail Receiver 1176 MUST NOT enact the requested policy ("p" tag or "sp" tag") on more 1177 than the stated percent of the totality of affected messages. 1178 However, regardless of whether or not the "pct" tag is present, the 1179 Mail Receiver MUST include all relevant message data in any reports 1180 produced. 1182 If email is subject to the DMARC policy of "quarantine", the Mail 1183 Receiver SHOULD quarantine the message. If the email is not subject 1184 to the "quarantine" policy (due to the "pct" tag), the Mail Receiver 1185 SHOULD apply local message classification as normal. 1187 If email is subject to the DMARC policy of "reject", the Mail 1188 Receiver SHOULD reject the message (see Section 10.3). If the email 1189 is not subject to the "reject" policy (due to the "pct" tag), the 1190 Mail Receiver SHOULD treat the email as though the "quarantine" 1191 policy applies. This behavior allows senders to experiment with 1192 progressively stronger policies without relaxing existing policy. 1194 Mail receivers implement "pct" via statistical mechanisms that 1195 achieve a close approximation to the requested percentage and provide 1196 a representative sample across a reporting period. 1198 6.6.5. Store Results of DMARC Processing 1200 The results of Mail Receiver-based DMARC processing should be stored 1201 for eventual presentation back to the Domain Owner in the form of 1202 aggregate feedback reports. Section 6.1 and Section 7.2 discuss 1203 aggregate feedback. 1205 6.7. Policy Enforcement Considerations 1207 Mail Receivers MAY choose to reject or quarantine email even if email 1208 passes the DMARC mechanism check. The DMARC mechanism does not 1209 inform Mail Receivers whether an email stream is "good". Mail 1210 Receivers are encouraged to maintain anti-abuse technologies to 1211 combat the possibility of DMARC-enabled criminal campaigns. 1213 Mail Receivers MAY choose to accept email that fails the DMARC 1214 mechanism check even if the Domain Owner has published a "reject" 1215 policy. Mail Receivers need to make a best effort not to increase 1216 the likelihood of accepting abusive mail if they choose not to comply 1217 with a Domain Owner's reject, against policy. At a minimum, addition 1218 of the Authentication-Results header field (see [AUTH-RESULTS]) is 1219 RECOMMENDED when delivery of failing mail is done. When this is 1220 done, the DNS domain name thus recorded MUST be encoded as an 1221 A-label. 1223 Mail Receivers are only obligated to report reject or quarantine 1224 policy actions in aggregate feedback reports that are due to DMARC 1225 policy. They are not required to report reject or quarantine actions 1226 that are the result of local policy. If local policy information is 1227 exposed, abusers can gain insight into the effectiveness and delivery 1228 rates of spam campaigns. 1230 Final disposition of a message is always a matter of local policy. 1231 An operator that wishes to favor DMARC policy over SPF policy, for 1232 example, will disregard the SPF policy since enacting an SPF- 1233 determined rejection prevents evaluation of DKIM; DKIM might 1234 otherwise pass, satisfying the DMARC evaluation. There is a trade- 1235 off to doing so, namely acceptance and processing of the entire 1236 message body in exchange for the enhanced protection DMARC provides. 1238 DMARC-compliant Mail Receivers typically disregard any mail handling 1239 directive discovered as part of an authentication mechanism (e.g., 1240 ADSP, SPF) where a DMARC record is also discovered that specifies a 1241 policy other than "none". Deviating from this practice introduces 1242 inconsistency among DMARC operators in terms of handling of the 1243 message. However, such deviation is not proscribed. 1245 To enable Domain Owners to receive DMARC feedback without impacting 1246 existing mail processing, discovered policies of "p=none" SHOULD NOT 1247 modify existing mail disposition processing. 1249 Mail Receivers SHOULD also implement reporting instructions of DMARC, 1250 even in the absence of a request for DKIM reporting [AFRF-DKIM] or 1251 SPF reporting [AFRF-SPF]. Furthermore, the presence of such requests 1252 SHOULD NOT affect DMARC reporting. 1254 7. DMARC Feedback 1256 Providing Domain Owners with visibility into how Mail Receivers 1257 implement and enforce the DMARC mechanism in the form of feedback is 1258 critical to establishing and maintaining accurate authentication 1259 deployments. When Domain Owners can see what effect their policies 1260 and practices are having, they are better willing and able to use 1261 quarantine and reject policies. 1263 7.1. Verifying External Destinations 1265 It is possible to specify destinations for the different reports that 1266 are outside the authority of the Domain Owner making the request. 1267 This allows domains that do not operate mail servers to request 1268 reports and have them go someplace that is able to receive and 1269 process them. 1271 Without checks, this would allow a bad actor to publish a DMARC 1272 policy record that requests reports be sent to a victim address, and 1273 then send a large volume of mail that will fail both DKIM and SPF 1274 checks to a wide variety of destinations, which will in turn flood 1275 the victim with unwanted reports. Therefore, a verification 1276 mechanism is included. 1278 When a Mail Receiver discovers a DMARC policy in the DNS, and the 1279 Organizational Domain at which that record was discovered is not 1280 identical to the Organizational Domain of the host part of the 1281 authority component of a [URI] specified in the "rua" or "ruf" tag, 1282 the following verification steps are to be taken: 1284 1. Extract the host portion of the authority component of the URI. 1285 Call this the "destination host", as it refers to a Report 1286 Receiver. 1288 2. Prepend the string "_report._dmarc". 1290 3. Prepend the domain name from which the policy was retrieved, 1291 after conversion to an A-label if needed. 1293 4. Query the DNS for a TXT record at the constructed name. If the 1294 result of this request is a temporary DNS error of some kind 1295 (e.g., a timeout), the Mail Receiver MAY elect to temporarily 1296 fail the delivery so the verification test can be repeated later. 1298 5. For each record returned, parse the result as a series of 1299 "tag=value" pairs, i.e., the same overall format as the policy 1300 record (see Section 6.4). In particular, the "v=DMARC1" tag is 1301 mandatory and MUST appear first in the list. Discard any that do 1302 not pass this test. 1304 6. If the result includes no TXT resource records that pass basic 1305 parsing, a positive determination of the external reporting 1306 relationship cannot be made; stop. 1308 7. If at least one TXT resource record remains in the set after 1309 parsing, then the external reporting arrangement was authorized 1310 by the Report Receiver. 1312 8. If a "rua" or "ruf" tag is thus discovered, replace the 1313 corresponding value extracted from the domain's DMARC policy 1314 record with the one found in this record. This permits the 1315 Report Receiver to override the report destination. However, to 1316 prevent loops or indirect abuse, the overriding URI MUST use the 1317 same destination host from the first step. 1319 For example, if a DMARC policy query for "blue.example.com" contained 1320 "rua=mailto:reports@red.example.net", the host extracted from the 1321 latter ("red.example.net") does not match "blue.example.com", so this 1322 procedure is enacted. A TXT query for 1323 "blue.example.com._report._dmarc.red.example.net" is issued. If a 1324 single reply comes back containing a tag of "v=DMARC1", then the 1325 relationship between the two is confirmed. Moreover, 1326 "red.example.net" has the opportunity to override the report 1327 destination requested by "blue.example.com" if needed. 1329 Where the above algorithm fails to confirm that the external 1330 reporting was authorized by the Report Receiver, the URI MUST be 1331 ignored by the Mail Receiver generating the report. Further, if the 1332 confirming record includes a URI whose host is again different than 1333 the domain publishing that override, the Mail Receiver generating the 1334 report MUST NOT generate a report to either the original or the 1335 override URI. 1337 A Report Receiver publishes such a record in its DNS if it wishes to 1338 receive reports for other domains. 1340 A Report Receiver that is willing to receive reports for any domain 1341 can use a wildcard DNS record. For example, a TXT resource record at 1342 "*._report._dmarc.example.com" containing at least "v=DMARC1" 1343 confirms that example.com is willing to receive DMARC reports for any 1344 domain. 1346 If the Report Receiver is overcome by volume, it can simply remove 1347 the confirming DNS record. However, due to positive caching, the 1348 change could take as long as the time-to-live on the record to go 1349 into effect. 1351 A Mail Receiver might decide not to enact this procedure if, for 1352 example, it relies on a local list of domains for which external 1353 reporting addresses are permitted. 1355 7.2. Aggregate Reports 1357 The DMARC aggregate feedback report is designed to provide Domain 1358 Owners with precise insight into: 1360 o authentication results 1362 o corrective action that needs to be taken by Domain Owners, and 1363 o the effect of Domain Owner DMARC policy on email streams processed 1364 by Mail Receivers. 1366 Aggregate DMARC feedback provides visibility into real-world email 1367 streams that Domain Owners need to make informed decisions regarding 1368 the publication of DMARC policy. When Domain Owners know what 1369 legitimate mail they are sending, what the authentication results are 1370 on that mail, and what forged mail receivers are getting, they can 1371 make better decisions about the policies they need and the steps they 1372 need to take to enable those policies. When Domain Owners set 1373 policies appropriately and understand their effects, Mail Receivers 1374 can act on them confidently. 1376 Visibility comes in the form of daily (or more frequent) Mail 1377 Receiver-originated feedback reports that contain aggregate data on 1378 message streams relevant to the Domain Owner. This information 1379 includes data about messages that passed DMARC authentication as well 1380 as those that did not. 1382 The format for these reports is defined in Appendix C. 1384 The report SHOULD include the following data: 1386 o The DMARC policy discovered and applied, if any 1388 o The selected message disposition 1390 o The identifier evaluated by SPF and the SPF result, if any 1392 o The identifier evaluated by DKIM and the DKIM result, if any 1394 o For both DKIM and SPF, in indication of whether the identifier was 1395 in alignment 1397 o Data for each sender subdomain separately from mail from the 1398 sender's organizational domain, even if there is no explicit 1399 subdomain policy. 1401 o Sending and receiving domains 1403 o The policy requested by the Domain Owner and the policy actually 1404 applied (if different) 1406 o The number of successful authentications 1408 o The counts of messages based on all messages received even if 1409 their delivery is ultimately blocked by other filtering agents 1411 Note that Domain Owners or their agents may change the published 1412 DMARC policy for a domain or subdomain at any time. From a Mail 1413 Receiver's perspective this will occur during a reporting period and 1414 may be noticed during that period, at the end of that period when 1415 reports are generated, or during a subsequent reporting period, all 1416 depending on the Mail Receiver's implementation. Under these 1417 conditions it is possible that a Mail Receiver could do any of the 1418 following: 1420 o generate a single aggregate report for such a reporting period 1421 that includes message dispositions based on the old policy, or a 1422 mix of the two policies, even though the report only contains a 1423 single "policy_published" element; 1425 o generate multiple reports for the same period, one for each 1426 published policy occurring during the reporting period; 1428 o generate a report whose end time occurs when the updated policy 1429 was detected, regardless of any requested report interval. 1431 Such policy changes are expected to be infrequent for any given 1432 domain, whereas more stringent policy monitoring requirements on the 1433 Mail Receiver would produce a very large burden at Internet scale. 1434 Therefore it is the responsibility of report consumers and Domain 1435 Owners to be aware of this situation and allow for such mixed reports 1436 during the propagation of the new policy to Mail Receivers. 1438 Aggregate reports are most useful when they all cover a common time 1439 period. By contrast, correlation of these reports from multiple 1440 generators when they cover incongruent time periods is difficult or 1441 impossible. Report generators SHOULD, wherever possible, adhere to 1442 hour boundaries for the reporting period they are using. For 1443 example, starting a per-day report at 00:00; starting per-hour 1444 reports at 00:00, 01:00, 02:00; et cetera. Report Generators using a 1445 24-hour report period are strongly encouraged to begin that period at 1446 00:00 UTC, regardless of local timezone or time of report production, 1447 in order to facilitate correlation. 1449 A Mail Receiver discovers reporting requests when it looks up a DMARC 1450 policy record that corresponds to a RFC5322 From: domain on received 1451 mail. The presence of the "rua" tag specifies where to send 1452 feedback. 1454 7.2.1. Transport 1456 Where the URI specified in an "rua" tag does not specify otherwise, a 1457 Mail Receiver generating a feedback report SHOULD employ a secure 1458 transport mechanism. 1460 The Mail Receiver, after preparing a report, MUST evaluate the 1461 provided reporting URIs in the order given. Any reporting URI that 1462 includes a size limitation exceeded by the generated report (after 1463 compression and after any encoding required by the particular 1464 transport mechanism) MUST NOT be used. An attempt MUST be made to 1465 deliver an aggregate report to every remaining URI, up to the 1466 receiver's limits on supported URIs. 1468 If transport is not possible because the services advertised by the 1469 published URIs are not able to accept reports (e.g., the URI refers 1470 to a service that is unreachable, or all provided URIs specify size 1471 limits exceeded by the generated record), the Mail Receiver SHOULD 1472 send a short report (see Section 7.2.2) indicating that a report is 1473 available but could not be sent. The Mail Receiver MAY cache that 1474 data and try again later, or MAY discard data that could not be sent. 1476 7.2.1.1. Email 1478 The message generated by the Mail Receiver MUST be a [MIME] formatted 1479 [MAIL] message. The aggregate report itself MUST be included in one 1480 of the parts of the message. A human-readable portion MAY be 1481 included as a MIME part (such as a text/plain part). 1483 The aggregate data MUST be an XML file that SHOULD be subjected to 1484 GZIP compression. Declining to apply compression can cause the 1485 report to be too large for a receiver to process (a commonly-observed 1486 receiver limit is ten megabytes); doing the compression increases the 1487 chances of acceptance of the report at some compute cost. The 1488 aggregate data SHOULD be present using the media type "application/ 1489 gzip" if compressed (see [GZIP]), and "text/xml" otherwise. The 1490 filename is typically constructed using the following ABNF: 1492 filename = receiver "!" policy-domain "!" begin-timestamp 1493 "!" end-timestamp [ "!" unique-id ] "." extension 1495 unique-id = 1*(ALPHA | DIGIT) 1497 receiver = domain 1498 ; imported from [MAIL] 1500 policy-domain = domain 1502 begin-timestamp = 1*DIGIT 1503 ; seconds since 00:00:00 UTC January 1, 1970 1504 ; indicating start of the time range contained 1505 ; in the report 1507 end-timestamp = 1*DIGIT 1508 ; seconds since 00:00:00 UTC January 1, 1970 1509 ; indicating end of the time range contained 1510 ; in the report 1512 extension = "xml" / "xml.gz" 1514 The extension MUST be "xml" for a plain XML file, or "xml.gz" for an 1515 XML file compressed using GZIP. 1517 "unique-id" allows an optional unique ID generated by the Mail 1518 Receiver to distinguish among multiple reports generated 1519 simultaneously by different sources within the same Domain Owner. 1521 For example, this is a possible filename for the gzip file of a 1522 report to the Domain Owner "example.com" from the Mail Receiver 1523 "mail.receiver.example". 1525 mail.receiver.example!example.com!1013662812!1013749130.gz 1527 No specific MIME message structure is required. It is presumed that 1528 the aggregate reporting address will be equipped to extract MIME 1529 parts with the prescribed media type and filename and ignore the 1530 rest. 1532 Email streams carrying DMARC feedback data MUST conform to the DMARC 1533 mechanism, thereby resulting in an aligned "pass" (see Section 3.1). 1534 This practice minimizes the risk of report consumers processing 1535 fraudulent reports. 1537 The RFC5322.Subject field for individual report submissions SHOULD 1538 conform to the following ABNF: 1540 dmarc-subject = %x52.65.70.6f.72.74 1*FWS ; "Report" 1541 %x44.6f.6d.61.69.6e.3a 1*FWS ; "Domain:" 1542 domain-name 1*FWS ; from RFC6376 1543 %x53.75.62.6d.69.74.74.65.72.3a ; "Submitter:" 1544 1*FWS domain-name 1*FWS 1545 %x52.65.70.6f.72.74.2d.49.44.3a ; "Report-ID:" 1546 msg-id ; from RFC5322 1548 The first domain-name indicates the DNS domain name about which the 1549 report was generated. The second domain-name indicates the DNS 1550 domain name representing the Mail Receiver generating the report. 1551 The purpose of the Report-ID: portion of the field is to enable the 1552 Domain Owner to identify and ignore duplicate reports that might be 1553 sent by a Mail Receiver. 1555 For instance, this is a possible Subject field for a report to the 1556 Domain Owner "example.com" from the Mail Receiver 1557 "mail.receiver.example". It is line-wrapped as allowed by [MAIL]. 1559 Subject: Report Domain: example.com 1560 Submitter: mail.receiver.example 1561 Report-ID: <2002.02.15.1> 1563 This transport mechanism potentially encounters a problem when 1564 feedback data size exceeds maximum allowable attachment sizes for 1565 either the generator or the consumer. See Section 7.2.2 for further 1566 discussion. 1568 7.2.1.2. Other Methods 1570 The specification as written allows for the addition of other 1571 registered URI schemes to be supported in later versions. 1573 7.2.2. Error Reports 1575 When a Mail Receiver is unable to complete delivery of a report via 1576 any of the URIs listed by the Domain Owner, the Mail Receiver SHOULD 1577 generate an error message. An attempt MUST be made to send this 1578 report to all listed "mailto" URIs and it MAY also be sent to any or 1579 all other listed URIs. 1581 The error report MUST be formatted per [MIME]. A text/plain part 1582 MUST be included that contains field-value pairs such as those found 1583 in Section 2 of [DSN]. The fields required, which may appear in any 1584 order, are: 1586 Report-Date: A [MAIL]-formatted date expression indicating when the 1587 transport failure occurred. 1589 Report-Domain: The domain-name about which the failed report was 1590 generated. 1592 Report-ID: The Report-ID: that the report tried to use. 1594 Report-Size: The size, in bytes, of the report that was unable to be 1595 sent. This MUST represent the number of bytes that the Mail 1596 Receiver attempted to send. Where more than one transport system 1597 was attempted, the sizes may be different; in such cases, separate 1598 error reports MUST be generated so that this value matches the 1599 actual attempt that was made. 1601 Submitter: The domain-name representing the Mail Receiver that 1602 generated, but was unable to submit, the report. 1604 Submitting-URI: The URI(s) to which the Mail Receiver tried, but 1605 failed, to submit the report. 1607 An additional text/plain part MAY be included that gives a human- 1608 readable explanation of the above, and MAY also include a URI that 1609 can be used to seek assistance. 1611 7.3. Failure Reports 1613 Failure reports are normally generated and sent almost immediately 1614 after the Mail Receiver detects a DMARC failure. Rather than waiting 1615 for an aggregate report, these reports are useful for quickly 1616 notifying the Domain Owners when there is an authentication failure. 1617 Whether the failure is due to an infrastructure problem or the 1618 message is inauthentic, failure reports also provide more information 1619 about the failed message than is available in an aggregate report. 1621 These reports SHOULD include any URI(s) from the message that failed 1622 authentication. These reports SHOULD include as much of the message 1623 and message header as is reasonable to support the Domain Owner's 1624 investigation into what caused the message to fail authentication and 1625 track down the sender. 1627 When a Domain Owner requests failure reports for the purpose of 1628 forensic analysis, and the Mail Receiver is willing to provide such 1629 reports, the Mail Receiver generates and sends a message using the 1630 format described in [AFRF]. This document updates the AFRF format as 1631 described in Section 7.3.1. 1633 The destination(s) and nature of the reports are defined by the "ruf" 1634 and "fo" tags as defined in Section 6.3. 1636 Where multiple URIs are selected to receive failure reports the 1637 report generator MUST make an attempt to deliver to each of them. 1639 An obvious consideration is the denial of service attack that can be 1640 perpetrated by an attacker who sends numerous messages purporting to 1641 be from the intended victim Domain Owner but which fail both SPF and 1642 DKIM; this would cause participating Mail Receivers to send failure 1643 reports to the Domain Owner or its delegate in potentially huge 1644 volumes. Accordingly, participating Mail Receivers are encouraged to 1645 aggregate these reports as much as is practical, using the Incidents 1646 field of the Abuse Reporting Format ([ARF]). Various aggregation 1647 techniques are possible, including: 1649 o only send a report to the first recipient of multi-recipient 1650 messages; 1652 o store reports for a period of time before sending them, allowing 1653 detection, collection, and reporting of like incidents; 1655 o apply rate limiting, such as a maximum number of reports per 1656 minute that will be generated (and the remainder discarded). 1658 7.3.1. Reporting Format Update 1660 Operators implementing this specification also implement an augmented 1661 version of [AFRF] as follows: 1663 1. A DMARC failure report includes the following ARF header fields, 1664 with the indicated normative requirement levels: 1666 * Identity-Alignment (REQUIRED; defined below) 1668 * Delivery-Result (OPTIONAL) 1670 * DKIM-Domain, DKIM-Identity, DKIM-Selector (REQUIRED if the 1671 message was signed by DKIM) 1673 * DKIM-Canonicalized-Header, DKIM-Canonicalized-Body (OPTIONAL 1674 if the message was signed by DKIM) 1676 * SPF-DNS (REQUIRED) 1678 2. The "Identity-Alignment" field is defined to contain a comma- 1679 separated list of authentication mechanism names that produced an 1680 aligned identity, or the keyword "none" if none did. ABNF: 1682 id-align = "Identity-Alignment:" [CFWS] 1683 ( "none" / 1684 dmarc-method *( [CFWS] "," [CFWS] dmarc-method ) ) 1685 [CFWS] 1687 dmarc-method = ( "dkim" / "spf" ) 1688 ; each may appear at most once in an id-align 1690 3. Authentication Failure Type "dmarc" is defined, which is to be 1691 used when a failure report is generated because some or all of 1692 the authentication mechanisms failed to produce aligned 1693 identifiers. Note that a failure report generator MAY also 1694 independently produce an AFRF message for any or all of the 1695 underlying authentication methods. 1697 8. Minimum Implementations 1699 A minimum implementation of DMARC has the following characteristics: 1701 o Is able to send and/or receive reports at least daily; 1703 o Is able to send and/or receive reports using "mailto" URIs; 1705 o Other than in exceptional circumstances such as resource 1706 exhaustion, can generate or accept a report up to ten megabytes in 1707 size; 1709 o If acting as a Mail Receiver, fully implements the provisions of 1710 Section 6.6. 1712 9. Privacy Considerations 1714 This section discusses security issues specific to private data that 1715 may be included in the interactions that are part of DMARC. 1717 9.1. Data Exposure Considerations 1719 Aggregate reports are limited in scope to DMARC policy and 1720 disposition results, to information pertaining to the underlying 1721 authentication mechanisms, and to the identifiers involved in DMARC 1722 validation. 1724 Failed message reporting provides message-specific details pertaining 1725 to authentication failures. Individual reports can contain message 1726 content as well as trace header fields. Domain Owners are able to 1727 analyze individual reports and attempt to determine root causes of 1728 authentication mechanism failures, gain insight into 1729 misconfigurations or other problems with email and network 1730 infrastructure, or inspect messages for insight into abusive 1731 practices. 1733 Both report types may expose sender and recipient identifiers (e.g., 1734 RFC5322.From addresses), and although the [AFRF] format used for 1735 failed message reporting supports redaction, failed message reporting 1736 is capable of exposing the entire message to the report recipient. 1738 Domain Owners requesting reports will receive information about mail 1739 claiming to be from them, which includes mail that was not, in fact, 1740 from them. Information about the final destination of mail where it 1741 might otherwise be obscured by intermediate systems will therefore be 1742 exposed. 1744 When message forwarding arrangements exist, Domain Owners requesting 1745 reports will also receive information about mail forwarded to domains 1746 that were not originally part of their messages' recipient lists. 1747 This means destination domains previously unknown to the Domain Owner 1748 may now become visible. 1750 Disclosure of information about the messages is being requested by 1751 the entity generating the email in the first place, i.e., the Domain 1752 Owner and not the Mail Receiver, so this may not fit squarely within 1753 existing privacy policy provisions. For some providers, aggregate 1754 and failed message reporting are viewed as a function similar to 1755 complaint reporting about spamming or phishing, and treated similarly 1756 under the privacy policy. Report generators (i.e., Mail Receivers) 1757 are encouraged to review their reporting limitations under such 1758 policies before enabling DMARC reporting. 1760 9.2. Report Recipients 1762 A DMARC record can specify that reports should be sent to an 1763 intermediary operating on behalf of the Domain Owner. This is done 1764 when the Domain Owner contracts with an entity to monitor mail- 1765 streams for abuse and performance issues. Receipt by third parties 1766 of such data may or may not be permitted by the Mail Receiver's 1767 privacy policy, terms of use, or other similar governing document. 1768 Domain Owners and Mail Receivers should both review and understand if 1769 their own internal policies constrain the use and transmission of 1770 DMARC reporting. 1772 Some potential exists for report recipients to perform traffic 1773 analysis, making it possible to obtain metadata about the receiver's 1774 traffic. In addition to verifying compliance with policies, 1775 receivers need to consider that before sending reports to a third 1776 party. 1778 10. Other Topics 1780 This section discusses some topics regarding choices made in the 1781 development of DMARC, largely to commit the history to record. 1783 10.1. Issues Specific to SPF 1785 Though DMARC does not inherently change the semantics of an SPF 1786 policy record, historically lax enforcement of such policies has led 1787 many to publish extremely broad records containing many large network 1788 ranges. Domain Owners are strongly encouraged to carefully review 1789 their SPF records to understand which networks are authorized to send 1790 on behalf of the Domain Owner before publishing a DMARC record. 1792 Some receiver architectures might implement SPF in advance of any 1793 DMARC operations. This means a "-" prefix on a Sender's SPF 1794 mechanism, such as "-all", could cause that rejection go into effect 1795 early in handling, causing message rejection before any DMARC 1796 processing takes place. Operators choosing to use "-all" should be 1797 aware of this. 1799 10.2. DNS Load and Caching 1801 DMARC policies are communicated using the DNS, and therefore inherit 1802 a number of considerations related to DNS caching. The inherent 1803 conflict between freshness and the impact of caching on the reduction 1804 of DNS-lookup overhead should be considered from the Mail Receiver's 1805 point of view. Should Domain Owners publish a DNS record with a very 1806 short TTL, Mail Receivers can be provoked through the injection of 1807 large volumes of messages to overwhelm the Domain Owner's DNS. 1808 Although this is not a concern specific to DMARC, the implications of 1809 a very short TTL should be considered when publishing DMARC policies. 1811 Conversely, long TTLs will cause records to be cached for long 1812 periods of time. This can cause a critical change to DMARC 1813 parameters advertised by a Domain Owner to go unnoticed for the 1814 length of the TTL (while waiting for DNS caches to expire). Avoiding 1815 this problem can mean shorter TTLs, with the potential problems 1816 described above. A balance should be sought to maintain 1817 responsiveness of DMARC preference changes while preserving the 1818 benefits of DNS caching. 1820 10.3. Rejecting Messages 1822 This proposal calls for rejection of a message during the SMTP 1823 session under certain circumstances. This is preferable to 1824 generation of a Delivery Status notification ([DSN]) since fraudulent 1825 messages caught and rejected using DMARC would then result in 1826 annoying generation of such failure reports that go back to the 1827 RFC5321.MailFrom address. 1829 This synchronous rejection is typically done in one of two ways: 1831 o Full rejection, wherein the SMTP server issues a 5xy reply code as 1832 an indication to the SMTP client that the transaction failed; the 1833 SMTP client is then responsible for generating notification that 1834 delivery failed (see Section 4.2.5 of [SMTP]). 1836 o A "silent discard", wherein the SMTP server returns a 2xy reply 1837 code implying to the client that delivery (or, at least, relay) 1838 was successfully completed, but then simply discarding the message 1839 with no further action. 1841 Each of these has a cost. For instance, a silent discard can help to 1842 prevent backscatter, but it also effectively means the SMTP server 1843 has to be programmed to give a false result, which can confound 1844 external debugging efforts. 1846 Similarly, the text portion of the SMTP reply may be important to 1847 consider. For example, when rejecting a message, revealing the 1848 reason for the rejection might give an attacker enough information to 1849 bypass those efforts on a later attempt, though it might also assist 1850 a legitimate client to determine the source of some local issue that 1851 caused the rejection. 1853 In the latter case, when doing an SMTP rejection, providing a clear 1854 hint can be useful in resolving issues. A receiver might indicate in 1855 plain text the reason for the rejection by using the word "DMARC" 1856 somewhere in the reply text. Many systems are able to scan the SMTP 1857 reply text to determine the nature of the rejection, thus providing a 1858 machine-detectable reason for rejection allows automated sorting of 1859 rejection causes so they can be properly addressed. For example: 1861 550 5.7.1 Email rejected per DMARC policy for example.com 1863 If a Mail Receiver elects to defer delivery due to inability to 1864 retrieve or apply DMARC policy, this is best done with a 4xy SMTP 1865 reply code. 1867 10.4. Identifier Alignment Considerations 1869 The DMARC mechanism allows both DKIM and SPF-authenticated 1870 identifiers to authenticate email on behalf of a Domain Owner and, 1871 possibly, on behalf of different subdomains. If malicious or unaware 1872 users can gain control of the SPF record or DKIM selector records for 1873 a subdomain, the subdomain can be used to generate DMARC-passing 1874 email on behalf of the Organizational Domain. 1876 For example, an attacker who controls the SPF record for 1877 "evil.example.com" can send mail with an RFC5322.From field 1878 containing "foo@example.com" that can pass both authentication and 1879 the DMARC check against "example.com". 1881 The Organizational Domain administrator should be careful not to 1882 delegate control of sub-domains if this is an issue, and to consider 1883 using the "strict" Identifier Alignment option if appropriate. 1885 10.5. Interoperability Issues 1887 DMARC limits which end-to-end scenarios can achieve a "pass" result. 1889 Because DMARC relies on [SPF] and/or [DKIM] to achieve a "pass", 1890 their limitations also apply. 1892 Additional DMARC constraints occur when a message is processed by 1893 some Mediators, such as mailing lists. Transiting a Mediator often 1894 causes either the authentication to fail or identity alignment to be 1895 lost. These transformations may conform to standards but will still 1896 prevent a DMARC "pass". 1898 In addition to Mediators, mail that is sent by authorized, 1899 independent third-parties might not be sent with Identifier 1900 Alignment, also preventing a "pass" result. 1902 Issues specific to the use of policy mechanisms alongside DKIM are 1903 further discussed in [DKIM-LISTS], particularly Section 5.2. 1905 11. IANA Considerations 1907 This section describes actions requested of IANA. 1909 11.1. Authentication-Results Method Registry Update 1911 IANA is requested to add the following to the Email Authentication 1912 Method Name Registry: 1914 Method: dmarc 1916 Defined In: [this document] 1918 ptype: header 1920 property: from 1922 Value: the domain portion of the RFC5322.From field 1924 Status: active 1926 Version: 1 1928 11.2. Authentication-Results Result Registry Update 1930 IANA has added the following in the Email Authentication Result Name 1931 Registry: 1933 Code: none 1935 Existing/New Code: existing 1937 Defined In: [AUTH-RESULTS] 1939 Auth Method: dmarc (added) 1941 Meaning: No DMARC policy record was published for the aligned 1942 identifier, or no aligned identifier could be extracted. 1944 Status: active 1946 Code: pass 1948 Existing/New Code: existing 1950 Defined In: [AUTH-RESULTS] 1952 Auth Method: dmarc (added) 1954 Meaning: A DMARC policy record was published for the aligned 1955 identifier, and at least one of the authentication mechanisms 1956 passed. 1958 Status: active 1959 Code: fail 1961 Existing/New Code: existing 1963 Defined In: [AUTH-RESULTS] 1965 Auth Method: dmarc (added) 1967 Meaning: A DMARC policy record was published for the aligned 1968 identifier, and none of the authentication mechanisms passed. 1970 Status: active 1972 Code: temperror 1974 Existing/New Code: existing 1976 Defined In: [AUTH-RESULTS] 1978 Auth Method: dmarc (added) 1980 Meaning: A temporary error occurred during DMARC evaluation. A 1981 later attempt might produce a final result. 1983 Status: active 1985 Code: permerror 1987 Existing/New Code: existing 1989 Defined In: [AUTH-RESULTS] 1991 Auth Method: dmarc (added) 1993 Meaning: A permanent error occurred during DMARC evaluation, such as 1994 encountering a syntactically incorrect DMARC record. A later 1995 attempt is unlikely to produce a final result. 1997 Status: active 1999 11.3. Feedback Report Header Fields Registry Update 2001 The following is added to the Feedback Report Header Fields Registry: 2003 Field Name: Identity-Alignment 2004 Description: indicates whether the message about which a report is 2005 being generated had any identifiers in alignment as defined in 2006 [this RFC] 2008 Multiple Appearances: no 2010 Related "Feedback-Type": auth-failure 2012 Published In: [this RFC] 2014 Status: current 2016 11.4. DMARC Tag Registry 2018 A new registry tree called "Domain-based Message Authentication, 2019 Reporting and Conformance (DMARC) Parameters" is to be created. 2020 Within it, a new sub-registry called the "DMARC Tag Registry" is also 2021 to be created. 2023 Names of DMARC tags must be registered with IANA in this new sub- 2024 registry. New entries are assigned only for values that have been 2025 documented in a manner that satisfies the terms of Specification 2026 Required, per [IANA-CONSIDERATIONS]. Each registration must include 2027 the tag name, the specification that defines it, a brief description, 2028 and its status which must be one of "current", "experimental" or 2029 "historic". The Designated Expert needs to confirm that the provided 2030 specification adequately describes the new tag and clearly presents 2031 how it would be used within the DMARC context by Domain Owners and 2032 Mail Receivers. 2034 To avoid version compatibility issues, tags added to the DMARC 2035 specification are to avoid changing the semantics of existing records 2036 when processed by implementations conforming to prior specifications. 2038 The initial set of entries in this registry is as follows: 2040 +----------+-------------+---------+------------------------------+ 2041 | Tag Name | Defined | Status | Description | 2042 +----------+-------------+---------+------------------------------+ 2043 | adkim | [THIS MEMO] | current | DKIM alignment mode | 2044 +----------+-------------+---------+------------------------------+ 2045 | aspf | [THIS MEMO] | current | SPF alignment mode | 2046 +----------+-------------+---------+------------------------------+ 2047 | fo | [THIS MEMO] | current | Failure reporting options | 2048 +----------+-------------+---------+------------------------------+ 2049 | pct | [THIS MEMO] | current | Sampling rate | 2050 +----------+-------------+---------+------------------------------+ 2051 | p | [THIS MEMO] | current | Requested handling policy | 2052 +----------+-------------+---------+------------------------------+ 2053 | rf | [THIS MEMO] | current | Failure reporting format(s) | 2054 +----------+-------------+---------+------------------------------+ 2055 | ri | [THIS MEMO] | current | Aggregate Reporting interval | 2056 +----------+-------------+---------+------------------------------+ 2057 | rua | [THIS MEMO] | current | Reporting URI(s) for | 2058 | | | | aggregate data | 2059 +----------+-------------+---------+------------------------------+ 2060 | ruf | [THIS MEMO] | current | Reporting URI(s) for | 2061 | | | | failure data | 2062 +----------+-------------+---------+------------------------------+ 2063 | sp | [THIS MEMO] | current | Requested handling policy | 2064 | | | | for subdomains | 2065 +----------+-------------+---------+------------------------------+ 2066 | v | [THIS MEMO] | current | Specification version | 2067 +----------+-------------+---------+------------------------------+ 2069 11.5. DMARC Report Format Registry 2071 Also within "Domain-based Message Authentication, Reporting and 2072 Conformance (DMARC) Parameters", a new sub-registry called "DMARC 2073 Report Format Registry" is to be created. 2075 Names of DMARC failure reporting formats must be registered with IANA 2076 in this registry. New entries are assigned only for values that 2077 satisfy the definition of Specification Required, per 2078 [IANA-CONSIDERATIONS]. In addition to a reference to a permanent 2079 specification, each registration must include the tag name, the 2080 specification that defines it, a brief description, and its status 2081 which must be one of "current", "experimental" or "historic". The 2082 Designated Expert needs to confirm that the provided specification 2083 adequately describes the report format and clearly presents how it 2084 would be used within the DMARC context by Domain Owners and Mail 2085 Receivers. 2087 The initial set of entries in this registry is as follows: 2089 +--------+-------------+---------+-----------------------------+ 2090 | Format | Defined | Status | Description | 2091 | Name | | | | 2092 +--------+-------------+---------+-----------------------------+ 2093 | afrf | [THIS MEMO] | current | Authentication Failure | 2094 | | | | Reporting Format (see | 2095 | | | | [AFRF]) | 2096 +--------+-------------+---------+-----------------------------+ 2098 12. Security Considerations 2100 This section discusses security issues and possible remediations 2101 (where available) for DMARC. 2103 12.1. Authentication Methods 2105 Security considerations from the authentication methods used by DMARC 2106 are incorporated here by reference. 2108 12.2. Attacks on Reporting URIs 2110 URIs published in DNS TXT records are well-understood possible 2111 targets for attack. Specifications such as [DNS] and [ROLES] either 2112 expose or cause the exposure of email addresses that could be flooded 2113 by an attacker, for example; MX, NS and other records found in the 2114 DNS advertise potential attack destinations; common DNS names such as 2115 "www" plainly identify the locations at which particular services can 2116 be found, providing destinations for targeted denial-of-service or 2117 penetration attacks. 2119 Thus, Domain Owners will need to harden these addresses against 2120 various attacks, including but not limited to: 2122 o high-volume denial-of-service attacks; 2124 o deliberate construction of malformed reports intended to identify 2125 or exploit parsing or processing vulnerabilities; 2127 o deliberate construction of reports containing false claims for the 2128 Submitter or Reported-Domain fields, including the possibility of 2129 false data from compromised but known Mail Receivers. 2131 12.3. DNS Security 2133 The DMARC mechanism and its underlying technologies (SPF, DKIM) 2134 depend on the security of the DNS. To reduce the risk of subversion 2135 of the DMARC mechanism due to DNS-based exploits, serious 2136 consideration should be given to the deployment of DNSSEC in parallel 2137 with the deployment of DMARC by both Domain Owners and Mail 2138 Receivers. 2140 Publication of data using DNSSEC is relevant to Domain Owners and 2141 third-party Report Receivers. DNSSEC-aware resolution is relevant to 2142 Mail Receivers and Report Receivers. 2144 12.4. Display Name Attacks 2146 A common attack in messaging abuse is the presentation of false 2147 information in the display-name portion of the RFC5322.From field. 2148 For example, it is possible for the email address in that field to be 2149 an arbitrary address or domain name, while containing a well-known 2150 name (a person, brand, role, etc.) in the display name, intending to 2151 fool the end user into believing that the name is used legitimately. 2152 The attack is predicated on the notion that most common MUAs will 2153 show the display name and not the email address when both are 2154 available. 2156 Generally, display name attacks are out of scope for DMARC as further 2157 exploration of possible defenses against these attacks needs to be 2158 undertaken. 2160 There are a few possible mechanisms that attempt mitigation of these 2161 attacks, such as: 2163 o If the display name is found to include an email address (as 2164 specified in [MAIL]), execute the DMARC mechanism on the domain 2165 name found there rather than the domain name discovered 2166 originally. However, this addresses only a very specific attack 2167 space and is easily circumvented by spoofers simply by not using 2168 an email address in the display name. There are also known cases 2169 of legitimate uses of an email address in the display name with a 2170 domain different from the one in the address portion, e.g.: 2172 From: "user@example.org via Bug Tracker" 2174 o In the MUA, only show the display name if the DMARC mechanism 2175 succeeds. This too is easily defeated, as an attacker could 2176 arrange to pass the DMARC tests while fraudulently using another 2177 domain name in the display name. 2179 o In the MUA, only show the display name if the DMARC mechanism 2180 passes and the email address thus validated matches one found in 2181 the receiving user's list of known addresses. 2183 12.5. External Reporting Addresses 2185 To avoid abuse by bad actors, reporting addresses generally have to 2186 be inside the domains about which reports are requested. In order to 2187 accommodate special cases such as a need to get reports about domains 2188 that cannot actually receive mail, Section 7.1 describes a DNS-based 2189 mechanism for verifying approved external reporting. 2191 The obvious consideration here is an increased DNS load against 2192 domains that are claimed as external recipients. Negative caching 2193 will mitigate this problem, but only to a limited extent, mostly 2194 dependent on the default time-to-live in the domain's SOA record. 2196 Where possible, external reporting is best achieved by having the 2197 report be directed to domains that can receive mail and simply having 2198 it automatically forwarded to the desired external destination. 2200 Note that the addresses shown in the "ruf" tag receive more 2201 information that might be considered private data, since it is 2202 possible for actual email content to appear in the failure reports. 2203 The URIs identified there are thus more attractive targets for 2204 intrusion attempts than those found in the "rua" tag. Moreover, 2205 attacking the DNS of the subject domain to cause failure data to be 2206 routed fraudulently to an attacker's systems may be an attractive 2207 prospect. Deployment of [DNSSEC] is advisable if this is a concern. 2209 The verification mechanism presented in Section 7.1 is currently not 2210 mandatory ("MUST") but strongly recommended ("SHOULD"). It is 2211 possible that it would be elevated to a "MUST" by later security 2212 review. 2214 12.6. Secure Protocols 2216 This document encourages use of secure transport mechanisms to 2217 prevent loss of private data to third parties that may be able to 2218 monitor such transmissions. Unencrypted mechanisms should be 2219 avoided. 2221 In particular, a message that was originally encrypted or otherwise 2222 secured might appear in a report that is not sent securely, which 2223 could reveal private information. 2225 13. References 2226 13.1. Normative References 2228 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2229 Specifications: ABNF", RFC 5234, January 2008. 2231 [AFRF] Fontana, H., "Authentication Failure Reporting using the 2232 Abuse Report Format", RFC 6591, April 2012. 2234 [AFRF-DKIM] 2235 Kucherawy, M., "Extensions to DomainKeys Identified Mail 2236 (DKIM) for Failure Reporting", RFC 6651, June 2012. 2238 [AFRF-SPF] 2239 Kitterman, S., "Sender Policy Framework (SPF) 2240 Authentication Failure Reporting Using the Abuse Reporting 2241 Format", RFC 6652, June 2012. 2243 [DKIM] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys 2244 Identified Mail (DKIM) Signatures", RFC 6376, 2245 September 2011. 2247 [DNS] Mockapetris, P., "Domain names - implementation and 2248 specification", STD 13, RFC 1035, November 1987. 2250 [DNS-CASE] 2251 Eastlake, D., "Domain Name System (DNS) Case Insensitivity 2252 Clarification", RFC 4343, January 2006. 2254 [GZIP] Levine, J., "The 'application/zlib' and 'application/gzip' 2255 Media Types", RFC 6713, August 2012. 2257 [IDNA] Klensin, J., "Internationalized Domain Names for 2258 Applications (IDNA): Definitions and Document Framework", 2259 RFC 5890, August 2000. 2261 [KEYWORDS] 2262 Bradner, S., "Key words for use in RFCs to Indicate 2263 Requirement Levels", BCP 14, RFC 2119, March 1997. 2265 [MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, 2266 October 2008. 2268 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 2269 Extensions (MIME) Part One: Format of Internet Message 2270 Bodies", RFC 2045, November 1996. 2272 [SEC-TERMS] 2273 Shirey, R., "Internet Security Glossary, Version 2", 2274 RFC 4949, August 2007. 2276 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 2277 October 2008. 2279 [SPF] Kitterman, S., "Sender Policy Framework (SPF) for 2280 Authorizing Use of Domains in E-Mail, Version 1", 2281 RFC 7208, April 2014. 2283 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2284 Resource Identifier (URI): Generic Syntax", RFC 3986, 2285 January 2005. 2287 13.2. Informative References 2289 [ADSP] Allman, E., Fenton, J., Delany, M., and J. Levine, 2290 "DomainKeys Identified Mail (DKIM) Author Domain Signing 2291 Practices (ADSP)", RFC 5617, August 2009. 2293 [ARF] Shafranovich, Y., Levine, J., and M. Kucherawy, "An 2294 Extensible Format for Email Feedback Reports", RFC 5965, 2295 August 2010. 2297 [AUTH-RESULTS] 2298 Kucherawy, M., "Message Header Field for Indicating 2299 Message Authentication Status", RFC 5451, April 2009. 2301 [Best-Guess-SPF] 2302 Kitterman, S., "Sender Policy Framework: Best guess record 2303 (FAQ entry)", May 2010, 2304 . 2306 [DKIM-DEPLOYMENT] 2307 Hansen, T., Siegel, E., Crocker, D., and P. Hallam-Baker, 2308 "DomainKeys Identified Mail (DKIM) Development, 2309 Deployment, and Operations", RFC 5863, May 2010. 2311 [DKIM-LISTS] 2312 Kucherawy, M., "DomainKeys Identified Mail (DKIM) and 2313 Mailing Lists", RFC 6377, September 2011. 2315 [DKIM-OVERVIEW] 2316 Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys 2317 Identified Mail (DKIM) Service Overview", RFC 5585, 2318 July 2009. 2320 [DKIM-THREATS] 2321 Fenton, J., "Analysis of Threats Motivating DomainKeys 2322 Identified Mail (DKIM)", RFC 4686, September 2006. 2324 [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. 2325 Rose, "DNS Security Introduction and Requirements", 2326 RFC 4033, March 2005. 2328 [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format 2329 for Delivery Status Notifications", RFC 3464, 2330 January 2003. 2332 [EMAIL-ARCH] 2333 Crocker, D., "Internet Mail Architecture", RFC 5598, 2334 July 2009. 2336 [IANA-CONSIDERATIONS] 2337 Narten, T. and H. Alvestrand, "Guidelines for Writing an 2338 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2339 May 2008. 2341 [ROLES] Crocker, D., "Mailbox Names for Common Services, Roles and 2342 Functions", RFC 2142, May 1997. 2344 URIs 2346 [1] 2348 Appendix A. Technology Considerations 2350 This section documents some design decisions that were made in the 2351 development of DMARC. Specifically, addressed here are some 2352 suggestions that were considered but not included in the design. 2353 This text is included to explain why they were considered and not 2354 included in this version. 2356 A.1. S/MIME 2358 S/MIME, or Secure Multipurpose Internet Mail Extensions, is a 2359 standard for encryption and signing of MIME data in a message. This 2360 was suggested and considered as a third security protocol for 2361 authenticating the source of a message. 2363 DMARC is focused on authentication at the domain level (i.e., the 2364 Domain Owner taking responsibility for the message), while S/MIME is 2365 really intended for user-to-user authentication and encryption. This 2366 alone appears to make it a bad fit for DMARC's goals. 2368 S/MIME also suffers from the heavyweight problem of Public Key 2369 Infrastructure, which means distribution of keys used to verify 2370 signatures needs to be incorporated. In many instances, this alone 2371 is a showstopper. There have been consistent promises that PKI 2372 usability and deployment will improve, but these have yet to 2373 materialize. DMARC can revisit this choice after those barriers are 2374 addressed. 2376 S/MIME has extensive deployment in specific market segments 2377 (government, for example), but does not enjoy similar widespread 2378 deployment over the general Internet, and this shows no signs of 2379 changing. DKIM and SPF both are deployed widely over the general 2380 Internet and their adoption rates continue to be positive. 2382 Finally, experiments have shown that including S/MIME support in the 2383 initial version of DMARC would neither cause nor enable a substantial 2384 increase in the accuracy of the overall mechanism. 2386 A.2. Method Exclusion 2388 It was suggested that DMARC include a mechanism by which a Domain 2389 Owner could tell Message Receivers not to attempt validation by one 2390 of the supported methods (e.g., "check DKIM, but not SPF"). 2392 Specifically, consider a Domain Owner that has deployed one of the 2393 technologies, and that technology fails for some messages, but such 2394 failures don't cause enforcement action. Deploying DMARC would cause 2395 enforcement action for policies other than "none", which would appear 2396 to exclude participation by that Domain Owner. 2398 The DMARC development team evaluated the idea of policy exception 2399 mechanisms on several occasions and invariably concluded that there 2400 was not a strong enough use case to include them. The specific 2401 target audience for DMARC does not appear to have concerns about the 2402 failure modes of one or the other being a barrier to DMARC's 2403 adoption. 2405 In the scenario described above, the Domain Owner has a few options: 2407 1. Tighten up its infrastructure to minimize the failure modes of 2408 the single deployed technology. 2410 2. Deploy the other supported authentication mechanism, to offset 2411 the failure modes of the first. 2413 3. Deploy DMARC in a reporting-only mode. 2415 A.3. Sender Header Field 2417 It has been suggested in several message authentication efforts that 2418 the Sender header field be checked for an identifier of interest, as 2419 the standards indicate this as the proper way to indicate a re- 2420 mailing of content such as through a mailing list. Most recently, it 2421 was a protocol-level option for DomainKeys, but on evolution to DKIM, 2422 this property was removed. 2424 The DMARC development team considered this and decided not to include 2425 support for doing so, for the following reasons: 2427 1. The main user protection approach is to be concerned with what 2428 the user sees when a message is rendered. There is no consistent 2429 behavior among MUAs regarding what to do with the content of the 2430 Sender field, if present. Accordingly, supporting checking of 2431 the Sender identifier would mean applying policy to an identifier 2432 the end user might never actually see, which can create a vector 2433 for attack against end users by simply forging a Sender field 2434 containing some identifier that DMARC will like. 2436 2. Although it is certainly true that this is what Sender is for, 2437 its use in this way is also unreliable, making it a poor 2438 candidate for inclusion in the DMARC evaluation algorithm. 2440 3. Allowing multiple ways to discover policy introduces unacceptable 2441 ambiguity into the DMARC evaluation algorithm in terms of which 2442 policy is to be applied and when. 2444 A.4. Domain Existence Test 2446 A common practice among MTA operators, and indeed one documented in 2447 [ADSP], is a test to determine domain existence prior to any more 2448 expensive processing. This is typically done by querying the DNS for 2449 MX, A or AAAA resource records for the name being evaluated, and 2450 assuming the domain is non-existent if it could be determined that no 2451 such records were published for that domain name. 2453 The original pre-standardization version of this protocol included a 2454 mandatory check of this nature. It was ultimately removed, as the 2455 method's error rate was too high without substantial manual tuning 2456 and heuristic work. There are indeed use cases this work needs to 2457 address where such a method would return a negative result about a 2458 domain for which reporting is desired, such as a registered domain 2459 name that never sends legitimate mail and thus has none of these 2460 records present in the DNS. 2462 A.5. Issues With ADSP In Operation 2464 DMARC has been characterized as a "super-ADSP" of sorts. 2466 Contributors to DMARC have compiled a list of issues associated with 2467 ADSP, gained from operational experience, that have influenced the 2468 direction of DMARC: 2470 1. ADSP has no support for subdomains, i.e., the ADSP record for 2471 example.com does not explicitly or implicitly apply to 2472 subdomain.example.com. If wildcarding is not applied, then 2473 spammers can trivially bypass ADSP by sending from a subdomain 2474 with no ADSP record. 2476 2. Non-existent subdomains are explicitly out of scope in ADSP. 2477 There is nothing in ADSP that states receivers should simply 2478 reject mail from NXDOMAINs regardless of ADSP policy (which of 2479 course allows spammers to trivially bypass ADSP by sending email 2480 from non-existent subdomains). 2482 3. ADSP has no operational advice on when to look up the ADSP 2483 record. 2485 4. ADSP has no support for using SPF as an auxiliary mechanism to 2486 DKIM. 2488 5. ADSP has no support for a slow roll-out, i.e., no way to 2489 configure a percentage of email on which the receiver should 2490 apply the policy. This is important for large-volume senders. 2492 6. ADSP has no explicit support for an intermediate phase where the 2493 receiver quarantines (e.g., sends to the recipient's "spam" 2494 folder) rather than rejects the email. 2496 7. The binding between the "From" header domain and DKIM is too 2497 tight for ADSP; they must match exactly. 2499 A.6. Organizational Domain Discovery Issues 2501 Although protocols like ADSP are useful for "protecting" a specific 2502 domain name, they are not helpful at protecting subdomains. If one 2503 wished to protect "example.com" by requiring via ADSP that all mail 2504 bearing an RFC5322.From domain of "example.com" be signed, this would 2505 "protect" that domain; however, one could then craft an email whose 2506 RFC5322.From domain is "security.example.com", and ADSP would not 2507 provide any protection. One could use a DNS wildcard, but this can 2508 undesirably interfere with other DNS activity; one could add ADSP 2509 records as fraudulent domains are discovered, but this solution does 2510 not scale and is a purely reactive measure against abuse. 2512 The DNS does not provide a method by which the "domain of record", or 2513 the domain that was actually registered with a domain registrar, can 2514 be determined given an arbitrary domain name. Suggestions have been 2515 made that attempt to glean such information from SOA or NS resource 2516 records, but these too are not fully reliable as the partitioning of 2517 the DNS is not always done at administrative boundaries. 2519 When seeking domain-specific policy based on an arbitrary domain 2520 name, one could "climb the tree", dropping labels off the left end of 2521 the name until the root is reached or a policy is discovered, but 2522 then one could craft a name that has a large number of nonsense 2523 labels; this would cause a Mail Receiver to attempt a large number of 2524 queries in search of a policy record. Sending many such messages 2525 constitutes an amplified denial-of-service attack. 2527 The Organizational Domain mechanism is a necessary component to the 2528 goals of DMARC. The method described in Section 3.2 is far from 2529 perfect, but serves this purpose reasonably well without adding undue 2530 burden or semantics to the DNS. If a method is created to do so that 2531 is more reliable and secure than the use of a public suffix list, 2532 DMARC should be amended to use that method as soon as it is generally 2533 available. 2535 A.6.1. Public Suffix Lists 2537 A public suffix list for the purposes of determining the 2538 Organizational Domain can be obtained from various sources. The most 2539 common one is maintained by the Mozilla Foundation and made public at 2540 http://publicsuffix.org. License terms governing the use of that 2541 list are available at that URI. 2543 Note that if operators use a variety of public suffix lists, 2544 interoperability will be difficult or impossible to guarantee. 2546 Appendix B. Examples 2548 This section illustrates both the Domain Owner side and the Mail 2549 Receiver side of a DMARC exchange. 2551 B.1. Identifier Alignment examples 2553 The following examples illustrate the DMARC mechanism's use of 2554 Identifier Alignment. For brevity's sake, only message headers are 2555 shown as message bodies are not considered when conducting DMARC 2556 checks. 2558 B.1.1. SPF 2560 The following SPF examples assume that SPF produces a passing result. 2562 Example 1: SPF in alignment: 2564 MAIL FROM: 2566 From: sender@example.com 2567 Date: Fri, Feb 15 2002 16:54:30 -0800 2568 To: receiver@example.org 2569 Subject: here's a sample 2570 SPF In Alignment 2572 In this case, the RFC5321.MailFrom parameter and the RFC5322.From 2573 field have identical DNS domains. Thus, the identifiers are in 2574 alignment. 2576 Example 2: SPF in alignment (parent): 2578 MAIL FROM: 2580 From: sender@example.com 2581 Date: Fri, Feb 15 2002 16:54:30 -0800 2582 To: receiver@example.org 2583 Subject: here's a sample 2584 SPF In Alignment (Parent) 2586 In this case, the RFC5322.From parameter includes a DNS domain that 2587 is a parent of the RFC5321.MailFrom domain. Thus, the identifiers 2588 are in alignment if "relaxed" SPF mode is requested by the Domain 2589 Owner, and not in alignment if "strict" SPF mode is requested. 2591 Example 3: SPF not in alignment: 2593 MAIL FROM: 2595 From: sender@child.example.com 2596 Date: Fri, Feb 15 2002 16:54:30 -0800 2597 To: receiver@example.org 2598 Subject: here's a sample 2599 SPF Not In Alignment 2601 In this case, the RFC5321.MailFrom parameter includes a DNS domain 2602 that is neither the same as nor a parent of the RFC5322.From domain. 2603 Thus, the identifiers are not in alignment. 2605 B.1.2. DKIM 2607 The examples below assume the DKIM signatures pass verification. 2608 Alignment cannot exist with a DKIM signature that does not verify. 2610 Example 1: DKIM in alignment: 2612 DKIM-Signature: v=1; ...; d=example.com; ... 2613 From: sender@example.com 2614 Date: Fri, Feb 15 2002 16:54:30 -0800 2615 To: receiver@example.org 2616 Subject: here's a sample 2617 DKIM In Alignment 2619 In this case, the DKIM "d=" parameter and the RFC5322.From field have 2620 identical DNS domains. Thus, the identifiers are in alignment. 2622 Example 2: DKIM in alignment (parent): 2624 DKIM-Signature: v=1; ...; d=example.com; ... 2625 From: sender@child.example.com 2626 Date: Fri, Feb 15 2002 16:54:30 -0800 2627 To: receiver@example.org 2628 Subject: here's a sample 2629 DKIM In Alignment (Parent) 2631 In this case, the DKIM signature's "d=" parameter includes a DNS 2632 domain that is a parent of the RFC5322.From domain. Thus, the 2633 identifiers are in alignment for "relaxed" mode, but not for "strict" 2634 mode. 2636 Example 3: DKIM not in alignment: 2638 DKIM-Signature: v=1; ...; d=sample.net; ... 2639 From: sender@child.example.com 2640 Date: Fri, Feb 15 2002 16:54:30 -0800 2641 To: receiver@example.org 2642 Subject: here's a sample 2643 DKIM Not In Alignment 2645 In this case, the DKIM signature's "d=" parameter includes a DNS 2646 domain that is neither the same as nor a parent of the RFC5322.From 2647 domain. Thus, the identifiers are not in alignment. 2649 B.2. Domain Owner example 2651 A Domain Owner that wants to use DMARC should have already deployed 2652 and tested SPF and DKIM. The next step is to publish a DNS record 2653 that advertises a DMARC policy for the Domain Owner's organizational 2654 domain. 2656 B.2.1. Entire Domain, Monitoring Only 2658 The owner of the domain "example.com" has deployed SPF and DKIM on 2659 its messaging infrastructure. The owner wishes to begin using DMARC 2660 with a policy that will solicit aggregate feedback from receivers 2661 without affecting how the messages are processed, in order to: 2663 o Confirm that its legitimate messages are authenticating correctly 2665 o Verify that all authorized message sources have implemented 2666 authentication measures 2668 o Determine how many messages from other sources would be affected 2669 by a blocking policy 2671 The Domain Owner accomplishes this by constructing a policy record 2672 indicating that: 2674 o The version of DMARC being used is "DMARC1" ("v=DMARC1") 2676 o Receivers should not alter how they treat these messages because 2677 of this DMARC policy record ("p=none") 2679 o Aggregate feedback reports should be sent via email to the address 2680 "dmarc-feedback@example.com" 2681 ("rua=mailto:dmarc-feedback@example.com") 2683 o All messages from this organizational domain are subject to this 2684 policy (no "pct" tag present, so the default of 100% applies) 2686 The DMARC policy record might look like this when retrieved using a 2687 common command-line tool: 2689 % dig +short TXT _dmarc.example.com. 2690 "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com" 2692 To publish such a record, the DNS administrator for the Domain Owner 2693 creates an entry like the following in the appropriate zone file 2694 (following the conventional zone file format): 2696 ; DMARC record for the domain example.com 2698 _dmarc IN TXT ( "v=DMARC1; p=none; " 2699 "rua=mailto:dmarc-feedback@example.com" ) 2701 B.2.2. Entire Domain, Monitoring Only, Per-Message Reports 2703 The Domain Owner from the previous example has used the aggregate 2704 reporting to discover some messaging systems that had not yet 2705 implemented DKIM correctly, but they are still seeing periodic 2706 authentication failures. In order to diagnose these intermittent 2707 problems they wish to request per-message failure reports when 2708 authentication failures occur. 2710 Not all Receivers will honor such a request, but the Domain Owner 2711 feels that any reports it does receive will be helpful enough to 2712 justify publishing this record. The default per-message report 2713 format ([AFRF]) meets the Domain Owner's needs in this scenario. 2715 The Domain Owner accomplishes this by adding the following to its 2716 policy record from Appendix B.2): 2718 o Per-message failure reports should be sent via email to the 2719 address "auth-reports@example.com" 2720 ("ruf=mailto:auth-reports@example.com") 2722 The DMARC policy record might look like this when retrieved using a 2723 common command-line tool (the output shown would appear on a single 2724 line, but is wrapped here for publication): 2726 % dig +short TXT _dmarc.example.com. 2727 "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com; 2728 ruf=mailto:auth-reports@example.com" 2730 To publish such a record, the DNS administrator for the Domain Owner 2731 might create an entry like the following in the appropriate zone file 2732 (following the conventional zone file format): 2734 ; DMARC record for the domain example.com 2736 _dmarc IN TXT ( "v=DMARC1; p=none; " 2737 "rua=mailto:dmarc-feedback@example.com; " 2738 "ruf=mailto:auth-reports@example.com" ) 2740 B.2.3. Per-Message Failure Reports Directed to Third Party 2742 The Domain Owner from the previous example is maintaining the same 2743 policy, but now wishes to have a third party receive and process the 2744 per-message failure reports. Again, not all Receivers will honor 2745 this request, but those that do may implement additional checks to 2746 validate that the third party wishes to receive the failure reports 2747 for this domain. 2749 The Domain Owner needs to alter its policy record from Appendix B.2.2 2750 as follows: 2752 o Per message failure reports should be send via email to the 2753 address "auth-reports@thirdparty.example.net" 2754 ("ruf=mailto:auth-reports@thirdparty.example.net") 2756 The DMARC policy record might look like this when retrieved using a 2757 common command-line tool (the output shown would appear on a single 2758 line, but is wrapped here for publication): 2760 % dig +short TXT _dmarc.example.com. 2761 "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com; 2762 ruf=mailto:auth-reports@thirdparty.example.net" 2764 To publish such a record, the DNS administrator for the Domain Owner 2765 might create an entry like the following in the appropriate zone file 2766 (following the conventional zone file format): 2768 ; DMARC record for the domain example.com 2770 _dmarc IN TXT ( "v=DMARC1; p=none; " 2771 "rua=mailto:dmarc-feedback@example.com; " 2772 "ruf=mailto:auth-reports@thirdparty.example.net" ) 2774 Because the address used in the "ruf" tag is outside the 2775 Organizational Domain in which this record is published, conforming 2776 Receivers will implement additional checks as described in 2777 Section 7.1 of this document. In order to pass these additional 2778 checks, the third party will need to publish an additional DNS record 2779 as follows: 2781 o Given the DMARC record published by the Domain Owner at 2782 "_dmarc.example.com", the DNS administrator for the third party 2783 will need to publish a TXT resource record at 2784 "example.com._report._dmarc.thirdparty.example.net" with the value 2785 "v=DMARC1". 2787 The resulting DNS record might look like this when retrieved using a 2788 common command-line tool (the output shown would appear on a single 2789 line, but is wrapped here for publication): 2791 % dig +short TXT example.com._report._dmarc.thirdparty.example.net 2792 "v=DMARC1" 2794 To publish such a record, the DNS administrator for example.net might 2795 create an entry like the following in the appropriate zone file 2796 (following the conventional zone file format): 2798 ; zone file for thirdparty.example.net 2799 ; Accept DMARC failure reports on behalf of example.com 2801 example.com._report._dmarc IN TXT "v=DMARC1" 2803 Intermediaries and other third parties should refer to Section 7.1 2804 for the full details of this mechanism. 2806 B.2.4. Sub-Domain, Sampling, and Multiple Aggregate Report URIs 2808 The Domain Owner has implemented SPF and DKIM in a sub-domain used 2809 for pre-production testing of messaging services. It now wishes to 2810 request that participating receivers act to reject messages from this 2811 sub-domain that fail to authenticate. 2813 As a first step it will ask that a portion (1/4 in this example) of 2814 failing messages be quarantined, enabling examination of messages 2815 sent to mailboxes hosted by participating receivers. Aggregate 2816 feedback reports will be sent to a mailbox within the Organizational 2817 Domain, and to a mailbox at a third party selected and authorized to 2818 receive same by the Domain Owner. Aggregate reports sent to the 2819 third party are limited to a maximum size of ten megabytes. 2821 The Domain Owner will accomplish this by constructing a policy record 2822 indicating that: 2824 o The version of DMARC being used is "DMARC1" ("v=DMARC1") 2826 o It is applied only to this sub-domain (record is published at 2827 "_dmarc.test.example.com" and not "_dmarc.example.com") 2829 o Receivers should quarantine messages from this organizational 2830 domain that fail to authenticate ("p=quarantine") 2832 o Aggregate feedback reports should be sent via email to the 2833 addresses "dmarc-feedback@example.com" and 2834 "example-tld-test@thirdparty.example.net", with the latter 2835 subjected to a maximum size limit ("rua=mailto:dmarc-feedback@ 2836 example.com,mailto:tld-test@thirdparty.example.net!10m") 2838 o 25% of messages from this Organizational Domain are subject to 2839 action based on this policy ("pct=25") 2841 The DMARC policy record might look like this when retrieved using a 2842 common command-line tool (the output shown would appear on a single 2843 line, but is wrapped here for publication): 2845 % dig +short TXT _dmarc.test.example.com 2846 "v=DMARC1; p=quarantine; rua=mailto:dmarc-feedback@example.com, 2847 mailto:tld-test@thirdparty.example.net!10m; pct=25" 2849 To publish such a record, the DNS administrator for the Domain Owner 2850 might create an entry like the following in the appropriate zone 2851 file: 2853 ; DMARC record for the domain example.com 2855 _dmarc IN TXT ( "v=DMARC1; p=quarantine; " 2856 "rua=mailto:dmarc-feedback@example.com," 2857 "mailto:tld-test@thirdparty.example.net!10m; " 2858 "pct=25" ) 2860 B.3. Mail Receiver Example 2862 A Mail Receiver that wants to use DMARC should already be checking 2863 SPF and DKIM, and possess the ability to collect relevant information 2864 from various email processing stages to provide feedback to Domain 2865 Owners (possibly via Report Receivers). 2867 B.3.1. SMTP-time Processing 2869 An optimal DMARC-enabled Mail Receiver performs authentication and 2870 identifier alignment checking during the [SMTP] conversation. 2872 Prior to returning a final reply to the DATA command, the Mail 2873 Receiver's MTA has performed: 2875 1. An SPF check to determine an SPF-authenticated Identifier. 2877 2. DKIM checks that yield one or more DKIM-authenticated 2878 Identifiers. 2880 3. A DMARC policy lookup. 2882 The presence of an Author Domain DMARC record indicates that the Mail 2883 Receiver should continue with DMARC-specific processing before 2884 returning a reply to the DATA command. 2886 Given a DMARC record and the set of Authenticated Identifiers, the 2887 Mail Receiver checks to see if the Authenticated Identifiers align 2888 with the Author Domain (taking into consideration any "strict" vs 2889 "relaxed" options found in the DMARC record). 2891 For example, the following sample data is considered to be from a 2892 piece of email originating from the Domain Owner of "example.com": 2894 Author Domain: example.com 2895 SPF-authenticated Identifier: mail.example.com 2896 DKIM-authenticated Identifier: example.com 2897 DMARC record: 2898 "v=DMARC1; p=reject; aspf=r; 2899 rua=mailto:dmarc-feedback@example.com" 2901 In the above sample, both the SPF and the DKIM-authenticated 2902 Identifiers align with the Author Domain. The Mail Receiver 2903 considers the above email to pass the DMARC check, avoiding the 2904 "reject" policy that is to be applied to email that fails to pass the 2905 DMARC check. 2907 If no Authenticated Identifiers align with the Author Domain, then 2908 the Mail Receiver applies the DMARC-record-specified policy. 2909 However, before this action is taken, the Mail Receiver can consult 2910 external information to override the Domain Owner's policy. For 2911 example, if the Mail Receiver knows that this particular email came 2912 from a known and trusted forwarder (that happens to break both SPF 2913 and DKIM), then the Mail Receiver may choose to ignore the Domain 2914 Owner's policy. 2916 The Mail Receiver is now ready to reply to the DATA command. If the 2917 DMARC check yields that the message is to be rejected, then the Mail 2918 Receiver replies with a 5xy code to inform the sender of failure. If 2919 the DMARC check cannot be resolved due to transient network errors, 2920 then the Mail Receiver replies with a 4xy code to inform the sender 2921 as to the need to reattempt delivery later. If the DMARC check 2922 yields a passing message, then the Mail Receiver continues on with 2923 email processing, perhaps using the result of the DMARC check as an 2924 input to additional processing modules such as a domain reputation 2925 query. 2927 Before exiting DMARC-specific processing, the Mail Receiver checks to 2928 see if the Author Domain DMARC record requests AFRF-based reporting. 2929 If so, then the Mail Receiver can emit an AFRF to the reporting 2930 address supplied in the DMARC record. 2932 At the exit of DMARC-specific processing, the Mail Receiver captures 2933 (through logging or direct insertion into a data store) the result of 2934 DMARC processing. Captured information is used to build feedback for 2935 Domain Owner consumption. This is not necessary if the Domain Owner 2936 has not requested aggregate reports, i.e., no "rua" tag was found in 2937 the policy record. 2939 B.4. Utilization of Aggregate Feedback example 2941 Aggregate feedback is consumed by Domain Owners to verify the Domain 2942 Owners understanding of how the Domain Owner's Domain is being 2943 processed by the Mail Receiver. Aggregate reporting data on emails 2944 that pass all DMARC-supporting authentication checks is used by 2945 Domain Owners to verify that authentication practices remain 2946 accurate. For example, if a third party is sending on behalf of a 2947 Domain Owner, the Domain Owner can use aggregate report data to 2948 verify ongoing authentication practices of the third party. 2950 Data on email that only partially passes underlying authentication 2951 checks provides visibility into problems that need to be addressed by 2952 the Domain Owner. For example, if either SPF or DKIM fail to pass, 2953 the Domain Owner is provided with enough information to either 2954 directly correct the problem or to understand where authentication- 2955 breaking changes are being introduced in the email transmission path. 2956 If authentication-breaking changes due to email transmission path 2957 cannot be directly corrected, then the Domain Owner at least 2958 maintains an understanding of the effect of DMARC-based policies upon 2959 the Domain Owner's email. 2961 Data on email that fails all underlying authentication checks 2962 provides baseline visibility on how the Domain Owner's Domain is 2963 being received at the Mail Receiver. Based on this visibility, the 2964 Domain Owner can begin deployment of authentication technologies 2965 across uncovered email sources. Additionally, the Domain Owner may 2966 come to an understanding of how its Domain is being misused. 2968 B.5. mailto Transport example 2970 A DMARC record can contain a "mailto" reporting address, such as: 2972 mailto:dmarc-feedback@example.com 2974 A sample aggregate report from the Mail Receiver at 2975 mail.receiver.example follows: 2977 DKIM-Signature: v=1; ...; d=mail.receiver.example; ... 2978 From: dmarc-reporting@mail.receiver.example 2979 Date: Fri, Feb 15 2002 16:54:30 -0800 2980 To: dmarc-feedback@example.com 2981 Subject: Report Domain: example.com 2982 Submitter: mail.receiver.example 2983 Report-ID: <2002.02.15.1> 2984 MIME-Version: 1.0 2985 Content-Type: multipart/alternative; 2986 boundary="----=_NextPart_000_024E_01CC9B0A.AFE54C00" 2987 Content-Language: en-us 2989 This is a multipart message in MIME format. 2991 ------=_NextPart_000_024E_01CC9B0A.AFE54C00 2992 Content-Type: text/plain; charset="us-ascii" 2993 Content-Transfer-Encoding: 7bit 2995 This is an aggregate report from mail.receiver.example. 2997 ------=_NextPart_000_024E_01CC9B0A.AFE54C00 2998 Content-Type: application/gzip 2999 Content-Transfer-Encoding: base64 3000 Content-Disposition: attachment; 3001 filename="mail.receiver.example!example.com! 3002 1013662812!1013749130.gz" 3004 3006 ------=_NextPart_000_024E_01CC9B0A.AFE54C00-- 3008 Not shown in the above example is that the Mail Receiver's feedback 3009 should be authenticated using SPF. Also, the value of the "filename" 3010 MIME parameter is wrapped for printing in this specification but 3011 would normally appear as one continuous string. 3013 Appendix C. DMARC XML Schema 3015 The following is the proposed initial schema for producing XML 3016 formatted aggregate reports as described in this document. 3018 NOTE: Per the definition of XML, unless otherwise specified in the 3019 schema below, the minOccurs and maxOccurs values for each element is 3020 set to 1. 3022 3023 3026 3028 3029 3030 3031 3032 3033 3035 3036 3037 3038 3039 3040 3042 3043 3044 3046 3047 3049 3051 3052 3053 3054 3055 3056 3058 3060 3061 3062 3063 3064 3065 3066 3068 3070 3071 3072 3073 3074 3075 3077 3078 3080 3081 3082 3083 3084 3085 3086 3087 3088 3089 3091 3092 3093 3094 3095 3096 3097 3099 3101 3102 3103 3104 3105 3106 3107 3108 3109 3110 3112 3115 3116 3117 3118 3121 3122 3124 3126 3127 3128 3129 3130 3131 3133 3134 3136 3139 3142 3143 3144 3147 3148 3150 3151 3152 3153 3154 3155 3156 3158 3161 3162 3164 3165 3166 3167 3170 3171 3173 3174 3176 3177 3179 3181 3182 3183 3184 3185 3186 3187 3188 3189 3190 3191 3193 3194 3195 3196 3198 3199 3201 3202 3204 3206 3208 3209 3211 3212 3213 3214 3215 3216 3217 3218 3219 3220 3221 3222 3223 3224 3225 3226 3227 3228 3229 3230 3231 3233 3234 3235 3236 3237 3238 3239 3240 3242 3243 3245 3247 3248 3249 3251 3253 3254 3256 3257 3259 3262 3263 3264 3265 3266 3267 3268 3270 3271 3272 3273 3274 3276 3278 3280 3282 3283 3284 3285 3287 Descriptions of the PolicyOverrideTypes: 3289 forwarded: Message was relayed via a known forwarder, or local 3290 heuristics identified the message as likely having been forwarded. 3291 There is no expectation that authentication would pass. 3293 local_policy: The Mail Receiver's local policy exempted the message 3294 from being subjected to the Domain Owner's requested policy 3295 action. 3297 mailing_list: Local heuristics determined that the message arrived 3298 via a mailing list, and thus authentication of the original 3299 message was not expected to succeed. 3301 other: Some policy exception not covered by the other entries in 3302 this list occurred. Additional detail can be found in the 3303 PolicyOverrideReason's "comment" field. 3305 sampled_out: Message was exempted from application of policy by the 3306 "pct" setting in the DMARC policy record. 3308 trusted_forwarder: Message authentication failure was anticipated by 3309 other evidence linking the message to a locally-maintained list of 3310 known and trusted forwarders. 3312 The "version" for reports generated per this specification MUST be 3313 the value 1.0. 3315 Appendix D. Public Discussion 3317 Public discussion of the DMARC proposal documents is taking place on 3318 the dmarc-discuss@dmarc.org mailing list. Subscription is available 3319 at http://www.dmarc.org/mailman/listinfo/dmarc-discuss. 3321 [RFC Editor: Please remove this section prior to publication.] 3323 Appendix E. Acknowledgements 3325 DMARC and the version of this document submitted to the IETF were the 3326 result of lengthy efforts by an informal industry consortium: 3327 DMARC.org [1]. Participating companies included: Agari, American 3328 Greetings, AOL, Bank of America, Cloudmark, Comcast, Facebook, 3329 Fidelity Investments, Google, JPMorgan Chase & Company, LinkedIn, 3330 Microsoft, Netease, PayPal, ReturnPath, The Trusted Domain Project, 3331 and Yahoo!. Although the number of contributors and supporters are 3332 too numerous to mention, notable individual contributions were made 3333 by J. Trent Adams, Michael Adkins, Monica Chew, Dave Crocker, Tim 3334 Draegen, Steve Jones, Franck Martin, Brett McDowell, and Paul Midgen. 3335 The contributors would also like to recognize the invaluable input 3336 and guidance that was provided early on by J.D. Falk. 3338 Additional contributions within the IETF context were made by Kurt 3339 Anderson, Michael Jack Assels, Les Barstow, Anne Bennett, Jim Fenton, 3340 J. Gomez, Mike Jones, Scott Kitterman, Eliot Lear, John Levine, S. 3341 Moonesamy, Rolf Sonneveld, Henry Timmes, and Stephen J. Turnbull. 3343 Authors' Addresses 3345 Murray S. Kucherawy (editor) 3347 Email: superuser@gmail.com 3349 Elizabeth Zwicky (editor) 3350 Yahoo! 3352 Email: zwicky@yahoo-inc.com