idnits 2.17.1 draft-ietf-dmarc-aggregate-reporting-00.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (November 11, 2020) is 1260 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: 'MAIL' is mentioned on line 325, but not defined == Missing Reference: 'MIME' is mentioned on line 247, but not defined == Missing Reference: 'GZIP' is mentioned on line 257, but not defined == Missing Reference: '0-9' is mentioned on line 473, but not defined == Missing Reference: '0-4' is mentioned on line 473, but not defined == Missing Reference: '0-5' is mentioned on line 473, but not defined Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMARC A. Brotman (ed) 3 Internet-Draft Comcast, Inc. 4 Obsoletes: 7489 (if approved) November 11, 2020 5 Intended status: Standards Track 6 Expires: May 15, 2021 8 DMARC Aggregate Reporting 9 draft-ietf-dmarc-aggregate-reporting-00 11 Abstract 13 DMARC allows for domain holders to request aggregate reports from 14 receivers. This report is an XML document, and contains extensible 15 elements that allow for other types of data to be specified later. 16 The aggregate reports can be submitted to the domain holder's 17 specified destination as supported by the receiver. 19 This document (along with others) obsoletes RFC7489. 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 May 15, 2021. 38 Copyright Notice 40 Copyright (c) 2020 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 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. DMARC Feedback . . . . . . . . . . . . . . . . . . . . . . . 2 58 2.1. Verifying External Destinations . . . . . . . . . . . . . 3 59 2.2. Aggregate Reports . . . . . . . . . . . . . . . . . . . . 3 60 2.2.1. Transport . . . . . . . . . . . . . . . . . . . . . . 5 61 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 63 5. Appendix A. DMARC XML Schema . . . . . . . . . . . . . . . . 8 64 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 65 6.1. Normative References . . . . . . . . . . . . . . . . . . 13 66 6.2. Informative References . . . . . . . . . . . . . . . . . 14 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 69 1. Introduction 71 A key component of DMARC is the ability for domain holders to request 72 that receivers provide various types of reports. These reports allow 73 domain holders to have insight into which IP addresses are sending on 74 their behalf, and some insight into whether or not the volume may be 75 legitimate. These reports expose information relating to the DMARC 76 policy, as well as the outcome of SPF [RFC7208] & DKIM [RFC6376] 77 validation. 79 1.1. Terminology 81 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 82 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 83 document, are to be interpreted as described in [RFC2119]. 85 2. DMARC Feedback 87 Providing Domain Owners with visibility into how Mail Receivers 88 implement and enforce the DMARC mechanism in the form of feedback is 89 critical to establishing and maintaining accurate authentication 90 deployments. When Domain Owners can see what effect their policies 91 and practices are having, they are better willing and able to use 92 quarantine and reject policies. 94 2.1. Verifying External Destinations 96 [] 98 2.2. Aggregate Reports 100 The DMARC aggregate feedback report is designed to provide Domain 101 Owners with precise insight into: 103 o authentication results, 105 o corrective action that needs to be taken by Domain Owners, and 107 o the effect of Domain Owner DMARC policy on email streams processed 108 by Mail Receivers. 110 Aggregate DMARC feedback provides visibility into real-world email 111 streams that Domain Owners need to make informed decisions regarding 112 the publication of DMARC policy. When Domain Owners know what 113 legitimate mail they are sending, what the authentication results are 114 on that mail, and what forged mail receivers are getting, they can 115 make better decisions about the policies they need and the steps they 116 need to take to enable those policies. When Domain Owners set 117 policies appropriately and understand their effects, Mail Receivers 118 can act on them confidently. 120 Visibility comes in the form of daily (or more frequent) Mail 121 Receiver-originated feedback reports that contain aggregate data on 122 message streams relevant to the Domain Owner. This information 123 includes data about messages that passed DMARC authentication as well 124 as those that did not. 126 The format for these reports is defined in Appendix C. 128 The report SHOULD include the following data: 130 o The DMARC policy discovered and applied, if any 132 o The selected message disposition 134 o The identifier evaluated by SPF and the SPF result, if any 136 o The identifier evaluated by DKIM and the DKIM result, if any 138 o For both DKIM and SPF, an indication of whether the identifier was 139 in alignment 141 o Data for each Domain Owner's subdomain separately from mail from 142 the sender's Organizational Domain, even if there is no explicit 143 subdomain policy 145 o Sending and receiving domains 147 o The policy requested by the Domain Owner and the policy actually 148 applied (if different) 150 o The number of successful authentications 152 o The counts of messages based on all messages received, even if 153 their delivery is ultimately blocked by other filtering agents 155 Note that Domain Owners or their agents may change the published 156 DMARC policy for a domain or subdomain at any time. From a Mail 157 Receiver's perspective, this will occur during a reporting period and 158 may be noticed during that period, at the end of that period when 159 reports are generated, or during a subsequent reporting period, all 160 depending on the Mail Receiver's implementation. Under these 161 conditions, it is possible that a Mail Receiver could do any of the 162 following: 164 o generate for such a reporting period a single aggregate report 165 that includes message dispositions based on the old policy, or a 166 mix of the two policies, even though the report only contains a 167 single "policy_published" element; 169 o generate multiple reports for the same period, one for each 170 published policy occurring during the reporting period; 172 o generate a report whose end time occurs when the updated policy 173 was detected, regardless of any requested report interval. 175 The report SHOULD include the following data: 177 o The DMARC policy discovered and applied, if any 179 o The selected message disposition 181 o The identifier evaluated by SPF and the SPF result, if any 183 o The identifier evaluated by DKIM and the DKIM result, if any 185 o For both DKIM and SPF, an indication of whether the identifier was 186 in alignment 188 o Data for each Domain Owner's subdomain separately from mail from 189 the sender's Organizational Domain, even if there is no explicit 190 subdomain policy 192 o Sending and receiving domains 194 o The policy requested by the Domain Owner and the policy actually 195 applied (if different) 197 o The number of successful authentications 199 o The counts of messages based on all messages received, even if 200 their delivery is ultimately blocked by other filtering agents 202 Note that Domain Owners or their agents may change the published 203 DMARC policy for a domain or subdomain at any time. From a Mail 204 Receiver's perspective, this will occur during a reporting period and 205 may be noticed during that period, at the end of that period when 206 reports are generated, or during a subsequent reporting period, all 207 depending on the Mail Receiver's implementation. Under these 208 conditions, it is possible that a Mail Receiver could do any of the 209 following: 211 o generate for such a reporting period a single aggregate report 212 that includes message dispositions based on the old policy, or a 213 mix of the two policies, even though the report only contains a 214 single "policy_published" element; 216 o generate multiple reports for the same period, one for each 217 published policy occurring during the reporting period; 219 o generate a report whose end time occurs when the updated policy 220 was detected, regardless of any requested report interval. 222 2.2.1. Transport 224 Where the URI specified in a "rua" tag does not specify otherwise, a 225 Mail Receiver generating a feedback report SHOULD employ a secure 226 transport mechanism. 228 The Mail Receiver, after preparing a report, MUST evaluate the 229 provided reporting URIs in the order given. Any reporting URI that 230 includes a size limitation exceeded by the generated report (after 231 compression and after any encoding required by the particular 232 transport mechanism) MUST NOT be used. An attempt MUST be made to 233 deliver an aggregate report to every remaining URI, up to the 234 Receiver's limits on supported URIs. 236 If transport is not possible because the services advertised by the 237 published URIs are not able to accept reports (e.g., the URI refers 238 to a service that is unreachable, or all provided URIs specify size 239 limits exceeded by the generated record), the Mail Receiver SHOULD 240 send a short report (see Section 7.2.2) indicating that a report is 241 available but could not be sent. The Mail Receiver MAY cache that 242 data and try again later, or MAY discard data that could not be sent. 244 2.2.1.1. Email 246 The message generated by the Mail Receiver MUST be a [MAIL] message 247 formatted per [MIME]. The aggregate report itself MUST be included 248 in one of the parts of the message. A human-readable portion MAY be 249 included as a MIME part (such as a text/plain part). 251 The aggregate data MUST be an XML file that SHOULD be subjected to 252 GZIP compression. Declining to apply compression can cause the 253 report to be too large for a receiver to process (a commonly observed 254 receiver limit is ten megabytes); doing the compression increases the 255 chances of acceptance of the report at some compute cost. The 256 aggregate data SHOULD be present using the media type "application/ 257 gzip" if compressed (see [GZIP]), and "text/xml" otherwise. The 258 filename is typically constructed using the following ABNF: 260 filename = receiver "!" policy-domain "!" begin-timestamp 261 "!" end-timestamp [ "!" unique-id ] "." extension 263 unique-id = 1*(ALPHA / DIGIT) 265 receiver = domain 266 ; imported from [MAIL] 268 policy-domain = domain 270 begin-timestamp = 1*DIGIT 271 ; seconds since 00:00:00 UTC January 1, 1970 272 ; indicating start of the time range contained 273 ; in the report 275 end-timestamp = 1*DIGIT 276 ; seconds since 00:00:00 UTC January 1, 1970 277 ; indicating end of the time range contained 278 ; in the report 280 extension = "xml" / "xml.gz" 282 The extension MUST be "xml" for a plain XML file, or "xml.gz" for an 283 XML file compressed using GZIP. 285 "unique-id" allows an optional unique ID generated by the Mail 286 Receiver to distinguish among multiple reports generated 287 simultaneously by different sources within the same Domain Owner. 289 For example, this is a possible filename for the gzip file of a 290 report to the Domain Owner "example.com" from the Mail Receiver 291 "mail.receiver.example": 293 mail.receiver.example!example.com!1013662812!1013749130.gz 295 No specific MIME message structure is required. It is presumed that 296 the aggregate reporting address will be equipped to extract MIME 297 parts with the prescribed media type and filename and ignore the 298 rest. 300 Email streams carrying DMARC feedback data MUST conform to the DMARC 301 mechanism, thereby resulting in an aligned "pass" (see Section 3.1). 302 This practice minimizes the risk of report consumers processing 303 fraudulent reports. 305 The RFC5322.Subject field for individual report submissions SHOULD 306 conform to the following ABNF: 308 dmarc-subject = %x52.65.70.6f.72.74 1*FWS ; "Report" 309 %x44.6f.6d.61.69.6e.3a 1*FWS ; "Domain:" 310 domain-name 1*FWS ; from RFC 6376 311 %x53.75.62.6d.69.74.74.65.72.3a ; "Submitter:" 312 1*FWS domain-name 1*FWS 313 %x52.65.70.6f.72.74.2d.49.44.3a ; "Report-ID:" 314 msg-id ; from RFC 5322 316 The first domain-name indicates the DNS domain name about which the 317 report was generated. The second domain-name indicates the DNS 318 domain name representing the Mail Receiver generating the report. 319 The purpose of the Report-ID: portion of the field is to enable the 320 Domain Owner to identify and ignore duplicate reports that might be 321 sent by a Mail Receiver. 323 For instance, this is a possible Subject field for a report to the 324 Domain Owner "example.com" from the Mail Receiver 325 "mail.receiver.example". It is line-wrapped as allowed by [MAIL]: 327 Subject: Report Domain: example.com 328 Submitter: mail.receiver.example 329 Report-ID: <2002.02.15.1> 331 This transport mechanism potentially encounters a problem when 332 feedback data size exceeds maximum allowable attachment sizes for 333 either the generator or the consumer. See Section 7.2.2 for further 334 discussion. 336 2.2.1.2. Other Methods 338 The specification as written allows for the addition of other 339 registered URI schemes to be supported in later versions. 341 3. Security Considerations 343 TBD 345 4. IANA Considerations 347 TBD 349 5. Appendix A. DMARC XML Schema 351 352 355 357 358 359 360 361 362 364 365 366 367 368 369 371 372 373 375 376 378 379 380 381 382 383 384 386 388 389 390 391 392 393 394 396 398 399 400 401 402 403 405 406 408 409 410 411 412 413 414 415 416 417 419 420 421 422 423 424 425 427 430 431 432 433 434 435 436 437 438 439 441 444 445 446 447 449 450 452 454 455 456 457 458 459 461 462 464 467 470 471 472 475 476 477 478 479 480 481 482 483 485 488 489 491 492 493 494 496 497 499 500 502 503 505 507 508 509 510 511 512 513 514 515 516 517 519 520 521 522 524 525 527 528 530 532 534 535 537 538 539 540 541 542 543 545 546 547 548 549 550 551 552 553 554 555 556 557 558 560 561 562 563 564 565 566 567 569 570 572 574 575 576 578 580 581 583 584 586 589 590 591 592 593 594 595 597 598 599 600 601 603 605 607 609 610 611 612 614 6. References 616 6.1. Normative References 618 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 619 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 620 RFC 6376, DOI 10.17487/RFC6376, September 2011, 621 . 623 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 624 Authorizing Use of Domains in Email, Version 1", RFC 7208, 625 DOI 10.17487/RFC7208, April 2014, 626 . 628 6.2. Informative References 630 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 631 Requirement Levels", BCP 14, RFC 2119, 632 DOI 10.17487/RFC2119, March 1997, 633 . 635 Author's Address 637 Alex Brotman 638 Comcast, Inc. 640 Email: alex_brotman@comcast.com