idnits 2.17.1 draft-ietf-dmarc-failure-reporting-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) -- The draft header indicates that this document obsoletes RFC7489, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (21 August 2021) is 978 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'CFWS' is mentioned on line 184, but not defined == Outdated reference: A later version (-30) exists of draft-ietf-dmarc-dmarcbis-03 == Outdated reference: A later version (-14) exists of draft-ietf-dmarc-aggregate-reporting-03 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMARC Working Group S. M. Jones, Ed. 3 Internet-Draft DMARC.org 4 Obsoletes: 7489 (if approved) A. Vesely, Ed. 5 Intended status: Standards Track Tana 6 Expires: 22 February 2022 21 August 2021 8 Domain-based Message Authentication, Reporting, and Conformance (DMARC) 9 Failure Reporting 10 draft-ietf-dmarc-failure-reporting-02 12 Abstract 14 Domain-based Message Authentication, Reporting, and Conformance 15 (DMARC) is a scalable mechanism by which a domain owner can request 16 feedback about email messages using their domain in the From: address 17 field. This document describes "failure reports," or "failed message 18 reports," which provide details about individual messages that failed 19 to authenticate according to the DMARC mechanism. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 22 February 2022. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 2 56 3. Failure Reports . . . . . . . . . . . . . . . . . . . . . . . 3 57 3.1. Reporting Format Update . . . . . . . . . . . . . . . . . 4 58 3.2. Verifying External Destinations . . . . . . . . . . . . . 5 59 3.3. Transport . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5 61 4.1. Data Exposure Considerations . . . . . . . . . . . . . . 5 62 4.2. Report Recipients . . . . . . . . . . . . . . . . . . . . 6 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 6. Normative References . . . . . . . . . . . . . . . . . . . . 7 65 7. Informative References . . . . . . . . . . . . . . . . . . . 7 66 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 7 67 A.1. Entire Domain, Monitoring Only, Per-Message Reports . . . 7 68 A.2. Per-Message Failure Reports Directed to Third Party . . . 8 69 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 10 70 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 73 1. Introduction 75 Domain-based Message Authentication, Reporting, and Conformance 76 (DMARC) [I-D.ietf-dmarc-dmarcbis] is a scalable mechanism by which a 77 mail-originating organization can express domain-level policies and 78 preferences for message validation, disposition, and reporting, that 79 a mail-receiving organization can use to improve mail handling. This 80 document focuses on one type of reporting that can be requested under 81 DMARC. 83 Failure reports provide detailed information about the failure of a 84 single message or a group of similar messages failing for the same 85 reason. They are meant to aid in cases where a domain owner is 86 unable to detect why failures reported in aggregate form did occur. 87 It is important to note these reports can contain either the header 88 or the entire content of a failed message, which in turn may contain 89 personally identifiable information, which should be considered when 90 deciding whether to generate such reports. 92 2. Terminology and Definitions 94 This section defines terms used in the rest of the document. 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 98 "OPTIONAL" in this document are to be interpreted as described in BCP 99 14 [RFC2119] [RFC8174] when, and only when, they appear in all 100 capitals, as shown here. 102 Readers are expected to be familiar with the contents of 103 [I-D.ietf-dmarc-dmarcbis], specifically the terminology and 104 definitions section. 106 3. Failure Reports 108 Failure reports can supply more detailed information about messages 109 that failed to authenticate, enabling the Domain Owner to determine 110 exactly what might be causing those specific failures. 112 Failure reports are normally generated and sent almost immediately 113 after the Mail Receiver detects a DMARC failure. Rather than waiting 114 for an aggregate report, these reports are useful for quickly 115 notifying the Domain Owners when there is an authentication failure. 116 Whether the failure is due to an infrastructure problem or the 117 message is inauthentic, failure reports also provide more information 118 about the failed message than is available in an aggregate report. 120 These reports should include as much of the message header and body 121 as possible, consistent with the reporting party's privacy policies, 122 to enable the Domain Owner to diagnose the authentication failure. 124 When a Domain Owner requests failure reports for the purpose of 125 forensic analysis, and the Mail Receiver is willing to provide such 126 reports, the Mail Receiver generates and sends a message using the 127 format described in [RFC6591]; this document updates that reporting 128 format, as described in Section 3.1. 130 The destination(s) and nature of the reports are defined by the "ruf" 131 and "fo" tags as defined in Section 6.3 of [I-D.ietf-dmarc-dmarcbis]. 133 Where multiple URIs are selected to receive failure reports, the 134 report generator MUST make an attempt to deliver to each of them. 136 An obvious consideration is the denial-of-service attack that can be 137 perpetrated by an attacker who sends numerous messages purporting to 138 be from the intended victim Domain Owner but that fail both SPF and 139 DKIM; this would cause participating Mail Receivers to send failure 140 reports to the Domain Owner or its delegate in potentially huge 141 volumes. Accordingly, participating Mail Receivers are encouraged to 142 aggregate these reports as much as is practical, using the Incidents 143 field of the Abuse Reporting Format ([RFC5965]). Indeed, the aim is 144 not to count each and every failure, but rather to report different 145 failure paths. Various aggregation techniques are possible, 146 including the following: 148 * only send a report to the first recipient of multi-recipient 149 messages; 151 * store reports for a period of time before sending them, allowing 152 detection, collection, and reporting of like incidents; 154 * apply rate limiting, such as a maximum number of reports per 155 minute that will be generated (and the remainder discarded). 157 3.1. Reporting Format Update 159 Operators implementing this specification also implement an augmented 160 version of [RFC6591] as follows: 162 1. A DMARC failure report includes the following ARF header fields, 163 with the indicated normative requirement levels: 165 * Identity-Alignment (REQUIRED; defined below) 167 * Delivery-Result (OPTIONAL) 169 * DKIM-Domain, DKIM-Identity, DKIM-Selector (REQUIRED if the 170 message was signed by DKIM) 172 * DKIM-Canonicalized-Header, DKIM-Canonicalized-Body (OPTIONAL 173 if the message was signed by DKIM) 175 * SPF-DNS (REQUIRED) 177 2. The "Identity-Alignment" field is defined to contain a comma- 178 separated list of authentication mechanism names that produced an 179 aligned identity, or the keyword "none" if none did. ABNF: 181 id-align = "Identity-Alignment:" [CFWS] 182 ( "none" / 183 dmarc-method *( [CFWS] "," [CFWS] dmarc-method ) ) 184 [CFWS] 186 dmarc-method = ( "dkim" / "spf" ) 187 ; each may appear at most once in an id-align 189 3. Authentication Failure Type "dmarc" is defined, which is to be 190 used when a failure report is generated because some or all of 191 the authentication mechanisms failed to produce aligned 192 identifiers. Note that a failure report generator MAY also 193 independently produce an AFRF message for any or all of the 194 underlying authentication methods. 196 3.2. Verifying External Destinations 198 The procedure described for aggragate reports Section 2.1 of 199 [I-D.ietf-dmarc-aggregate-reporting] applies to failure reports as 200 well. 202 3.3. Transport 204 Email streams carrying DMARC failure reports SHOULD provide DMARC- 205 based authentication, so as to produce "dmarc=pass". This 206 requirement is a MUST in case the report is sent through a host 207 having a DMARC record with a ruf= tag. Indeed, special care must be 208 taken of authentication in that case, as failure to authenticate 209 failure reports may result in mail loops. 211 Reporters SHOULD rate limit the number of failure reports sent to any 212 recipient to avoid overloading recipient systems. Again, in case the 213 reports being sent are in turn at risk of being reported for DMARC 214 authentication failure, reporters MUST make sure that possible mail 215 loop are stopped. 217 4. Privacy Considerations 219 This section discusses issues specific to private data that may be 220 included in the DMARC reporting functions. 222 4.1. Data Exposure Considerations 224 Failed-message reporting provides message-specific details pertaining 225 to authentication failures. Individual reports can contain message 226 content as well as trace header fields. Domain Owners are able to 227 analyze individual reports and attempt to determine root causes of 228 authentication mechanism failures, gain insight into 229 misconfigurations or other problems with email and network 230 infrastructure, or inspect messages for insight into abusive 231 practices. 233 These reports may expose sender and recipient identifiers (e.g., 234 RFC5322.From addresses), and although the [RFC6591] format used for 235 failed-message reporting supports redaction, failed-message reporting 236 is capable of exposing the entire message to the report recipient. 238 Domain Owners requesting reports will receive information about mail 239 claiming to be from them, which includes mail that was not, in fact, 240 from them. Information about the final destination of mail where it 241 might otherwise be obscured by intermediate systems will therefore be 242 exposed. 244 When message-forwarding arrangements exist, Domain Owners requesting 245 reports will also receive information about mail forwarded to domains 246 that were not originally part of their messages' recipient lists. 247 This means that destination domains previously unknown to the Domain 248 Owner may now become visible. 250 Disclosure of information about the messages is being requested by 251 the entity generating the email in the first place, i.e., the Domain 252 Owner and not the Mail Receiver, so this may not fit squarely within 253 existing privacy policy provisions. For some providers, failed- 254 message reporting is viewed as a function similar to complaint 255 reporting about spamming or phishing and is treated similarly under 256 the privacy policy. Report generators (i.e., Mail Receivers) are 257 encouraged to review their reporting limitations under such policies 258 before enabling DMARC reporting. 260 4.2. Report Recipients 262 A DMARC record can specify that reports should be sent to an 263 intermediary operating on behalf of the Domain Owner. This is done 264 when the Domain Owner contracts with an entity to monitor mail 265 streams for abuse and performance issues. Receipt by third parties 266 of such data may or may not be permitted by the Mail Receiver's 267 privacy policy, terms of use, or other similar governing document. 268 Domain Owners and Mail Receivers should both review and understand if 269 their own internal policies constrain the use and transmission of 270 DMARC reporting. 272 Some potential exists for report recipients to perform traffic 273 analysis, making it possible to obtain metadata about the Receiver's 274 traffic. In addition to verifying compliance with policies, 275 Receivers need to consider that before sending reports to a third 276 party. 278 5. Security Considerations 280 Considerations discussed in Section 11 of [I-D.ietf-dmarc-dmarcbis] 281 apply. 283 In addition, note that Organizational Domains are only an 284 approximation to actual domain ownership. Therefore, reports may be 285 sent to someone unrelated to the actual sender or domain owner. That 286 makes considerations in Section 4.1 all the more relevant. 288 6. Normative References 290 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 291 Requirement Levels", BCP 14, RFC 2119, 292 DOI 10.17487/RFC2119, March 1997, 293 . 295 [RFC6591] Fontana, H., "Authentication Failure Reporting Using the 296 Abuse Reporting Format", RFC 6591, DOI 10.17487/RFC6591, 297 April 2012, . 299 [I-D.ietf-dmarc-dmarcbis] 300 Herr, T. M. and J. Levine, "Domain-based Message 301 Authentication, Reporting, and Conformance (DMARC)", Work 302 in Progress, Internet-Draft, draft-ietf-dmarc-dmarcbis-03, 303 18 August 2021, . 306 [I-D.ietf-dmarc-aggregate-reporting] 307 Brotman, A., "DMARC Aggregate Reporting", Work in 308 Progress, Internet-Draft, draft-ietf-dmarc-aggregate- 309 reporting-03, 18 August 2021, 310 . 313 7. Informative References 315 [RFC5965] Shafranovich, Y., Levine, J., and M. Kucherawy, "An 316 Extensible Format for Email Feedback Reports", RFC 5965, 317 DOI 10.17487/RFC5965, August 2010, 318 . 320 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 321 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 322 May 2017, . 324 Appendix A. Examples 326 This section presents some examples related to the use of DMARC 327 reporting functions. 329 A.1. Entire Domain, Monitoring Only, Per-Message Reports 331 The owners of the domain "example.com" have deployed SPF and DKIM on 332 their messaging infrastructure. As described in, Appendix B.2.1 of 333 [I-D.ietf-dmarc-aggregate-reporting] they have used the aggregate 334 reporting to discover some messaging systems that had not yet 335 implemented DKIM correctly. However, they are still seeing periodic 336 authentication failures. In order to diagnose these intermittent 337 problems, they wish to request per-message failure reports when 338 authentication failures occur. 340 Not all Receivers will honor such a request, but the Domain Owner 341 feels that any reports it does receive will be helpful enough to 342 justify publishing this record. The default per-message report 343 format ([RFC6591]) meets the Domain Owner's needs in this scenario. 345 The Domain Owner accomplishes this by adding the following to its 346 policy record: 348 * Per-message failure reports should be sent via email to the 349 address "auth-reports@example.com" ("ruf=mailto:auth- 350 reports@example.com") 352 The updated DMARC policy record might look like this when retrieved 353 using a common command-line tool (the output shown would appear on a 354 single line but is wrapped here for publication): 356 % dig +short TXT _dmarc.example.com. 357 "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com; 358 ruf=mailto:auth-reports@example.com" 360 To publish such a record, the DNS administrator for the Domain Owner 361 might create an entry like the following in the appropriate zone file 362 (following the conventional zone file format): 364 ; DMARC record for the domain example.com 366 _dmarc IN TXT ( "v=DMARC1; p=none; " 367 "rua=mailto:dmarc-feedback@example.com; " 368 "ruf=mailto:auth-reports@example.com" ) 370 A.2. Per-Message Failure Reports Directed to Third Party 372 The Domain Owner from the previous example is maintaining the same 373 policy but now wishes to have a third party receive and process the 374 per-message failure reports. Again, not all Receivers will honor 375 this request, but those that do may implement additional checks to 376 validate that the third party wishes to receive the failure reports 377 for this domain. 379 The Domain Owner needs to alter its policy record from Appendix A.1 380 as follows: 382 * Per-message failure reports should be sent via email to the 383 address "auth-reports@thirdparty.example.net" ("ruf=mailto:auth- 384 reports@thirdparty.example.net") 386 The DMARC policy record might look like this when retrieved using a 387 common command-line tool (the output shown would appear on a single 388 line but is wrapped here for publication): 390 % dig +short TXT _dmarc.example.com. 391 "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com; 392 ruf=mailto:auth-reports@thirdparty.example.net" 394 To publish such a record, the DNS administrator for the Domain Owner 395 might create an entry like the following in the appropriate zone file 396 (following the conventional zone file format): 398 ; DMARC record for the domain example.com 400 _dmarc IN TXT ( "v=DMARC1; p=none; " 401 "rua=mailto:dmarc-feedback@example.com; " 402 "ruf=mailto:auth-reports@thirdparty.example.net" ) 404 Because the address used in the "ruf" tag is outside the 405 Organizational Domain in which this record is published, conforming 406 Receivers will implement additional checks as described in 407 Section 3.2 of this document. In order to pass these additional 408 checks, the third party will need to publish an additional DNS record 409 as follows: 411 * Given the DMARC record published by the Domain Owner at 412 "_dmarc.example.com", the DNS administrator for the third party 413 will need to publish a TXT resource record at 414 "example.com._report._dmarc.thirdparty.example.net" with the value 415 "v=DMARC1;". 417 The resulting DNS record might look like this when retrieved using a 418 common command-line tool (the output shown would appear on a single 419 line but is wrapped here for publication): 421 % dig +short TXT example.com._report._dmarc.thirdparty.example.net 422 "v=DMARC1;" 424 To publish such a record, the DNS administrator for example.net might 425 create an entry like the following in the appropriate zone file 426 (following the conventional zone file format): 428 ; zone file for thirdparty.example.net 429 ; Accept DMARC failure reports on behalf of example.com 431 example.com._report._dmarc IN TXT "v=DMARC1;" 433 Intermediaries and other third parties should refer to Section 3.2 434 for the full details of this mechanism. 436 Appendix B. Change Log 438 [RFC Editor: Please remove this section prior to publication.] 440 00 to 01 * Replace references to RFC7489 with references to I- 441 D.ietf-dmarc-dmarcbis. 443 * Replace the 2nd paragraph in the Introduction with the 444 text proposed by Ned for Ticket #55, which enjoys some 445 consensus: 446 https://mailarchive.ietf.org/arch/msg/dmarc/ 447 HptVyJ9SgrfxWRbeGwORagPrhCw 449 * Strike a spurious sentence about criticality of 450 feedback, which was meant for feedback in general, not failure 451 reports. In fact, failure reports are not critical to 452 establishing and maintaining accurate authentication 453 deployments. Still attributable to Ticket #55. 455 * Remove the content of section "Verifying External 456 Destinations" and refer to I-D.ietf-dmarc-aggregate-reporting. 458 * Remove the content of section "Security Considerations" 459 and refer to I-D.ietf-dmarc-dmarcbis. 461 * Slightly tweak the wording of the example in 462 Appendix A.1 so that it makes sense standing alone. 464 * Remove the sentence containing "must include any 465 URI(s)", as the issue arose 466 https://mailarchive.ietf.org/arch/msg/dmarc/ 467 mFk0qiTCy8tzghRvcxus01W_Blw. 469 * Add paragraph in Security Considerations, noting that 470 note that Organizational Domains are only an approximation... 472 * Add a Transport section, mentioning DMARC conformance 473 and failure report mail loops (Ticket #28). 475 01 to 02 * Add a sentence to make clear that counting failures is 476 not the aim. 478 Acknowledgements 480 DMARC and the draft version of this document submitted to the 481 Independent Submission Editor were the result of lengthy efforts by 482 an informal industry consortium: DMARC.org (see http://dmarc.org 483 (http://dmarc.org)). Participating companies included Agari, 484 American Greetings, AOL, Bank of America, Cloudmark, Comcast, 485 Facebook, Fidelity Investments, Google, JPMorgan Chase & Company, 486 LinkedIn, Microsoft, Netease, PayPal, ReturnPath, The Trusted Domain 487 Project, and Yahoo!. Although the contributors and supporters are 488 too numerous to mention, notable individual contributions were made 489 by J. Trent Adams, Michael Adkins, Monica Chew, Dave Crocker, Tim 490 Draegen, Steve Jones, Franck Martin, Brett McDowell, and Paul Midgen. 491 The contributors would also like to recognize the invaluable input 492 and guidance that was provided early on by J.D. Falk. 494 Additional contributions within the IETF context were made by Kurt 495 Anderson, Michael Jack Assels, Les Barstow, Anne Bennett, Jim Fenton, 496 J. Gomez, Mike Jones, Scott Kitterman, Eliot Lear, John Levine, S. 497 Moonesamy, Rolf Sonneveld, Henry Timmes, and Stephen J. Turnbull. 499 Authors' Addresses 501 Steven M Jones (editor) 502 DMARC.org 504 Email: smj@dmarc.org 506 Alessandro Vesely (editor) 507 Tana 509 Email: vesely@tana.it