idnits 2.17.1 draft-ietf-dmarc-aggregate-reporting-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 189: '...ggregate Reports MUST contain two prim...' RFC 2119 keyword, line 191: '...ta. Each report MUST contain data for...' RFC 2119 keyword, line 192: '... A single report MUST contain data for...' RFC 2119 keyword, line 194: '... a reporting entity MAY choose to send...' RFC 2119 keyword, line 195: '... reporting entity SHOULD note only the...' (55 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (13 December 2021) is 862 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: 'RFC2119' is mentioned on line 121, but not defined == Missing Reference: 'RFC8174' is mentioned on line 121, but not defined == Missing Reference: 'RefNeeded' is mentioned on line 204, but not defined == Missing Reference: 'MAIL' is mentioned on line 456, but not defined == Missing Reference: 'MIME' is mentioned on line 373, but not defined == Missing Reference: 'GZIP' is mentioned on line 383, but not defined == Missing Reference: 'URI' is mentioned on line 522, but not defined == Missing Reference: '0-9' is mentioned on line 909, but not defined == Missing Reference: '0-4' is mentioned on line 909, but not defined == Missing Reference: '0-5' is mentioned on line 909, but not defined Summary: 1 error (**), 0 flaws (~~), 11 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) 13 December 2021 5 Intended status: Standards Track 6 Expires: 16 June 2022 8 DMARC Aggregate Reporting 9 draft-ietf-dmarc-aggregate-reporting-04 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 16 June 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 Revised BSD License text as 49 described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Revised BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. DMARC Feedback . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Aggregate Reports . . . . . . . . . . . . . . . . . . . . 3 58 2.1.1. Handling Domains in Reports . . . . . . . . . . . . . 6 59 2.1.2. DKIM Signatures in Aggregate Report . . . . . . . . . 6 60 2.1.3. Unique Identifiers in Aggregate Reporting . . . . . . 7 61 2.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . 7 62 2.3. Changes in Policy During Reporting Period . . . . . . . . 7 63 2.4. Recommended Reporting Periods . . . . . . . . . . . . . . 8 64 2.5. Report Request Discovery . . . . . . . . . . . . . . . . 8 65 2.6. Transport . . . . . . . . . . . . . . . . . . . . . . . . 8 66 2.6.1. Email . . . . . . . . . . . . . . . . . . . . . . . . 8 67 2.6.2. Other Methods . . . . . . . . . . . . . . . . . . . . 11 68 2.6.3. Handling of Duplicates . . . . . . . . . . . . . . . 11 69 3. Verifying External Destinations . . . . . . . . . . . . . . . 11 70 4. Extensible Reporting . . . . . . . . . . . . . . . . . . . . 13 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 72 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14 73 6.1. Data Exposure Considerations . . . . . . . . . . . . . . 15 74 6.2. Report Recipients . . . . . . . . . . . . . . . . . . . . 15 75 6.3. Data Contained Within Reports (Tkt64) . . . . . . . . . . 16 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 77 8. Appendix A. DMARC XML Schema . . . . . . . . . . . . . . . . 16 78 9. Appendix B. Sample Report . . . . . . . . . . . . . . . . . 23 79 10. Normative References . . . . . . . . . . . . . . . . . . . . 24 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25 82 1. Introduction 84 A key component of DMARC is the ability for domain holders to request 85 that receivers provide various types of reports. These reports allow 86 domain holders to have insight into which IP addresses are sending on 87 their behalf, and some insight into whether or not the volume may be 88 legitimate. These reports expose information relating to the DMARC 89 policy, as well as the outcome of SPF [RFC7208] & DKIM [RFC6376] 90 validation. 92 1.1. Terminology 94 In many IETF documents, several words, when they are in all capitals 95 as shown below, are used to signify the requirements in the 96 specification. These capitalized words can bring significant clarity 97 and consistency to documents because their meanings are well defined. 98 This document defines how those words are interpreted in IETF 99 documents when the words are in all capitals. 101 * These words can be used as defined here, but using them is not 102 required. Specifically, normative text does not require the use 103 of these key words. They are used for clarity and consistency 104 when that is what's wanted, but a lot of normative text does not 105 use them and is still normative. 107 * The words have the meanings specified herein only when they are in 108 all capitals. 110 * When these words are not capitalized, they have their normal 111 English meanings and are not affected by this document. 113 Authors who follow these guidelines should incorporate this phrase 114 near the beginning of their document: 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 117 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", 118 "MAY", and "OPTIONAL" in this document are to be interpreted as 119 described in BCP 14 [RFC2119] [RFC8174] when, and only when, they 120 appear in all capitals, as shown here. 122 2. DMARC Feedback 124 Providing Domain Owners with visibility into how Mail Receivers 125 implement and enforce the DMARC mechanism in the form of feedback is 126 critical to establishing and maintaining accurate authentication 127 deployments. When Domain Owners can see what effect their policies 128 and practices are having, they are better willing and able to use 129 quarantine and reject policies. 131 2.1. Aggregate Reports 133 The DMARC aggregate feedback report is designed to provide Domain 134 Owners with precise insight into: 136 * authentication results, 138 * corrective action that needs to be taken by Domain Owners, and 139 * the effect of Domain Owner DMARC policy on email streams processed 140 by Mail Receivers. 142 Aggregate DMARC feedback provides visibility into real-world email 143 streams that Domain Owners need to make informed decisions regarding 144 the publication of DMARC policy. When Domain Owners know what 145 legitimate mail they are sending, what the authentication results are 146 on that mail, and what forged mail receivers are getting, they can 147 make better decisions about the policies they need and the steps they 148 need to take to enable those policies. When Domain Owners set 149 policies appropriately and understand their effects, Mail Receivers 150 can act on them confidently. 152 Visibility comes in the form of daily (or more frequent) Mail 153 Receiver-originated feedback reports that contain aggregate data on 154 message streams relevant to the Domain Owner. This information 155 includes data about messages that passed DMARC authentication as well 156 as those that did not. 158 The report may include the following data: 160 * The DMARC policy discovered and applied, if any 162 * The selected message disposition 164 * The identifier evaluated by SPF and the SPF result, if any 166 * The identifier evaluated by DKIM and the DKIM result, if any 168 * For both DKIM and SPF, an indication of whether the identifier was 169 in alignment 171 * A separate report should be generated for each Policy Domain 172 encountered during the reporting period. If there are multiple 173 5322.From domains that are included, those should result in 174 distinct records within the report. See below for further 175 explanation in "Handling Domains in Reports". 177 * Sending and receiving domains 179 * The policy requested by the Domain Owner and the policy actually 180 applied (if different) 182 * The number of successful authentications 184 * The counts of messages based on all messages received, even if 185 their delivery is ultimately blocked by other filtering agents. 187 The format for these reports is defined in Appendix A. 189 DMARC Aggregate Reports MUST contain two primary sections; one 190 consisting of descriptive information and the other a set of IP- 191 focused row-based data. Each report MUST contain data for only one 192 Author Domain. A single report MUST contain data for one policy 193 configuration. If multiple configurations were observed during a 194 single reporting period, a reporting entity MAY choose to send 195 multiple reports, otherwise the reporting entity SHOULD note only the 196 final configuration observed during the period. See below for 197 further information. 199 The informative section MUST contain two sub-sections. One will be 200 the metadata section which MUST contain the fields related to 201 org_name, email, report_id, and date_range. Optional fields MAY 202 include extra_contact_info, an error field, and an optional version 203 field. The version field, if present, MUST contain a 1.0 [!@RFC7489] 204 or 2.0 [RefNeeded], noting to which version of the aggregate 205 reporting specification the report adheres. The date_range section 206 which will note begin and end values as epoch timestamps. The other 207 sub-section will be the policy_published, and record the policy 208 configuration observed by the receiving system. Mandatory fields are 209 domain, p, sp. Optional fields are fo, adkim, aspf, and testing. 210 There MAY be an optional third section for extensions. 212 Within the data section, the report will contain row(s) of data 213 stating which IPs were seen to have delivered messages for the Author 214 Domain to the receiving system. For each IP that is being reported, 215 there will be at least one record element, which will then have each 216 of a row, identifiers, and auth_results sub-element. Within the row 217 element, there MUST be source_ip and count. There MUST also exist a 218 policy_evaluated, with subelements of disposition, dkim, and spf. 219 There MAY be an element for reason, meant to include any notes the 220 reporter might want to include as to why the disposition policy does 221 not match the policy_published, such as a Local Policy override 222 (possible values listed in Appendix A). The dkim and spf elements 223 MUST be the evaluated values as they relate to DMARC, not the values 224 the receiver may have used when overriding the policy. Within the 225 identifiers element, there MUST exist the data that was used to apply 226 policy for the given IP. In most cases, this will be a header_from 227 element, which will contain the 5322.From domain from the message. 229 There MUST be an auth_results element within the 'record' element. 230 This will contain the data related to authenticating the messages 231 associated with this sending IP. The dkim subelement is optional as 232 not all messages are signed, while there MUST be one spf subelement. 233 These elements MUST have a domain that was used during validation, as 234 well as result. The dkim element MUST include a selector element 235 that was observed during validation. For the spf element, the result 236 element MUST contain a lower-case string where the value is one of 237 none/neutral/pass/fail/softfail/temperror/permerror. The dkim result 238 MUST contain a lower-case string where the value is one of 239 none/pass/fail/policy/neutral/temperror/permerror. Both the spf and 240 dkim results may optionally include a human_readable field meant for 241 the report to convey more descriptive information back to the domain 242 holder relating to evaluation failures. There MAY exist an optional 243 section for extensions. 245 2.1.1. Handling Domains in Reports 247 In the same report, there MUST be a single Policy Domain, though 248 there could be multiple 5322.From Domains. Each 5322.From domain 249 will create its own record within the report. Consider the case 250 where there are three domains with traffic volume to report: 251 example.com, foo.example.com, and bar.example.com. There will be 252 explicit DMARC records for example.com and bar.example.com, with 253 distinct policies. There is no explicit DMARC record for 254 foo.example.com, so it will be reliant on the policy described for 255 example.com. For a report period, there would now be two reports. 256 The first will be for bar.example.com, and contain only one record, 257 for bar.example.com. The second report would be for example comain 258 contain multiple record elements, one for example.com and one for 259 foo.example.com (and extensibly, other record elements for subdomains 260 which likewise did not have an explicit DMARC policy declared). 262 2.1.2. DKIM Signatures in Aggregate Report 264 Within a single message, the possibility exists that there could be 265 multiple DKIM signatures. When validation of the message occurs, 266 some signatures may pass, while some may not. As these pertain to 267 DMARC, and especially to aggregate reporting, reporters may not find 268 it clear which DKIM signatures they should include in a report. 269 Signatures, regardless of outcome, could help the report ingester 270 determine the source of a message. However, there is a preference as 271 to which signatures are included. 273 1. A signature that passes DKIM, in strict alignment with the 274 5322.From domain 276 2. A signature that passes DKIM, in relaxed alignment with the 277 5322.From domain 279 3. Any other DKIM signatures that pass 281 4. DKIM signatures that do not pass 282 A report SHOULD contain no more than 100 signatures for a given row, 283 in decreasing priority. 285 2.1.3. Unique Identifiers in Aggregate Reporting 287 There are a few places where a unique identifier is specified as part 288 of the body of the report, the subject, and so on. These unique 289 identifiers should be consistent per each report. Specified below, 290 the reader will see a msg-id, Report-ID, unique-id. These are the 291 fields that MUST be identical when used. 293 2.2. Extensions 295 There MAY be optional sections for extensions within the document. 296 The absence or existence of this section SHOULD NOT create an error 297 when processing reports. This will be covered in a separate section. 299 2.3. Changes in Policy During Reporting Period 301 Note that Domain Owners or their agents may change the published 302 DMARC policy for a domain or subdomain at any time. From a Mail 303 Receiver's perspective, this will occur during a reporting period and 304 may be noticed during that period, at the end of that period when 305 reports are generated, or during a subsequent reporting period, all 306 depending on the Mail Receiver's implementation. Under these 307 conditions, it is possible that a Mail Receiver could do any of the 308 following: 310 * generate for such a reporting period a single aggregate report 311 that includes message dispositions based on the old policy, or a 312 mix of the two policies, even though the report only contains a 313 single "policy_published" element; 315 * generate multiple reports for the same period, one for each 316 published policy occurring during the reporting period; 318 * generate a report whose end time occurs when the updated policy 319 was detected, regardless of any requested report interval. 321 Such policy changes are expected to be infrequent for any given 322 domain, whereas more stringent policy monitoring requirements on the 323 Mail Receiver would produce a very large burden at Internet scale. 324 Therefore, it is the responsibility of report consumers and Domain 325 Owners to be aware of this situation and allow for such mixed reports 326 during the propagation of the new policy to Mail Receivers. 328 2.4. Recommended Reporting Periods 330 Aggregate reports are most useful when they all cover a common time 331 period. By contrast, correlation of these reports from multiple 332 generators when they cover incongruent time periods is difficult or 333 impossible. Report generators SHOULD, wherever possible, adhere to 334 hour boundaries for the reporting period they are using. For 335 example, starting a per-day report at 00:00; starting per-hour 336 reports at 00:00, 01:00, 02:00; etc. Report generators using a 337 24-hour report period are strongly encouraged to begin that period at 338 00:00 UTC, regardless of local timezone or time of report production, 339 in order to facilitate correlation. 341 2.5. Report Request Discovery 343 A Mail Receiver discovers reporting requests when it looks up a DMARC 344 policy record that corresponds to an RFC5322.From domain on received 345 mail. The presence of the "rua" tag specifies where to send 346 feedback. 348 2.6. Transport 350 Where the URI specified in a "rua" tag does not specify otherwise, a 351 Mail Receiver generating a feedback report SHOULD employ a secure 352 transport mechanism. 354 The Mail Receiver, after preparing a report, MUST evaluate the 355 provided reporting URIs in the order given. Any reporting URI that 356 includes a size limitation exceeded by the generated report (after 357 compression and after any encoding required by the particular 358 transport mechanism) MUST NOT be used. An attempt MUST be made to 359 deliver an aggregate report to every remaining URI, up to the 360 Receiver's limits on supported URIs. 362 If transport is not possible because the services advertised by the 363 published URIs are not able to accept reports (e.g., the URI refers 364 to a service that is unreachable, or all provided URIs specify size 365 limits exceeded by the generated record), the Mail Receiver MAY send 366 a short report (see Section 7.2.2) indicating that a report is 367 available but could not be sent. The Mail Receiver MAY cache that 368 data and try again later, or MAY discard data that could not be sent. 370 2.6.1. Email 372 The message generated by the Mail Receiver MUST be a [MAIL] message 373 formatted per [MIME]. The aggregate report itself MUST be included 374 in one of the parts of the message. A human-readable portion MAY be 375 included as a MIME part (such as a text/plain part). 377 The aggregate data MUST be an XML file that SHOULD be subjected to 378 GZIP compression. Declining to apply compression can cause the 379 report to be too large for a receiver to process (a commonly observed 380 receiver limit is ten megabytes); doing the compression increases the 381 chances of acceptance of the report at some compute cost. The 382 aggregate data MUST be present using the media type "application/ 383 gzip" if compressed (see [GZIP]), and "text/xml" otherwise. The 384 filename MUST be constructed using the following ABNF: 386 filename = receiver "!" policy-domain "!" begin-timestamp 387 "!" end-timestamp [ "!" unique-id ] "." extension 389 receiver = domain 390 ; imported from [MAIL] 392 policy-domain = domain 394 begin-timestamp = 1*DIGIT 395 ; seconds since 00:00:00 UTC January 1, 1970 396 ; indicating start of the time range contained 397 ; in the report 399 end-timestamp = 1*DIGIT 400 ; seconds since 00:00:00 UTC January 1, 1970 401 ; indicating end of the time range contained 402 ; in the report 404 unique-id = 1*(ALPHA / DIGIT) 406 extension = "xml" / "xml.gz" 408 The extension MUST be "xml" for a plain XML file, or "xml.gz" for an 409 XML file compressed using GZIP. 411 "unique-id" allows an optional unique ID generated by the Mail 412 Receiver to distinguish among multiple reports generated 413 simultaneously by different sources within the same Domain Owner. 415 If a report generator needs to re-send a report, the system MUST use 416 the same filename as the original report. This would allow the 417 receiver to overwrite the data from the original, or discard second 418 instance of the report. 420 For example, this is a sample filename for the gzip file of a report 421 to the Domain Owner "example.com" from the Mail Receiver 422 "mail.receiver.example": 424 mail.receiver.example!example.com!1013662812!1013749130.gz 426 No specific MIME message structure is required. It is presumed that 427 the aggregate reporting address will be equipped to extract MIME 428 parts with the prescribed media type and filename and ignore the 429 rest. 431 Email streams carrying DMARC feedback data MUST conform to the DMARC 432 mechanism, thereby resulting in an aligned "pass" (see Section 3.1). 433 This practice minimizes the risk of report consumers processing 434 fraudulent reports. 436 The RFC5322.Subject field for individual report submissions MUST 437 conform to the following ABNF: 439 dmarc-subject = %x52.65.70.6f.72.74 1*FWS ; "Report" 440 %x44.6f.6d.61.69.6e.3a 1*FWS ; "Domain:" 441 domain-name 1*FWS ; from RFC 6376 442 %x53.75.62.6d.69.74.74.65.72.3a ; "Submitter:" 443 1*FWS domain-name 1*FWS 444 %x52.65.70.6f.72.74.2d.49.44.3a ; "Report-ID:" 445 msg-id ; from RFC 5322 447 The first domain-name indicates the DNS domain name about which the 448 report was generated. The second domain-name indicates the DNS 449 domain name representing the Mail Receiver generating the report. 450 The purpose of the Report-ID: portion of the field is to enable the 451 Domain Owner to identify and ignore duplicate reports that might be 452 sent by a Mail Receiver. 454 For instance, this is a possible Subject field for a report to the 455 Domain Owner "example.com" from the Mail Receiver 456 "mail.receiver.example". It is line-wrapped as allowed by [MAIL]: 458 Subject: Report Domain: example.com 459 Submitter: mail.receiver.example 460 Report-ID: <2002.02.15.1> 462 This transport mechanism potentially encounters a problem when 463 feedback data size exceeds maximum allowable attachment sizes for 464 either the generator or the consumer. See Section 7.2.2 for further 465 discussion. 467 Optionally, the report sender MAY choose to use the same msg-id as a 468 part or whole of the 5322.Message-Id header included with the report. 469 Doing so may help receivers distinguish when a message is a re- 470 transmission or duplicate report. 472 2.6.2. Other Methods 474 The specification as written allows for the addition of other 475 registered URI schemes to be supported in later versions. 477 2.6.3. Handling of Duplicates 479 There may be a situation where the report generator attempts to 480 deliver duplicate information to the receiver. This may manifest as 481 an exact duplicate of the report, or as duplicate information between 482 two reports. In these situations, the decision of how to handle the 483 duplicate data lies with the receiver. As noted above, the sender 484 MUST use the same unique identifiers when sending the report. This 485 allows the receiver to better understand when duplicates happen. A 486 few options on how to handle that duplicate information: 488 * Reject back to sender, ideally with a permfail error noting the 489 duplicate receipt 491 * Discard upon receipt 493 * Inspect the contents to evaluate the timestamps and reported data, 494 act as appropriate 496 * Accept the duplicate data 498 When accepting the data, that's likely in a situation where it's not 499 yet noticed, or a one-off experience. Long term, duplicate data is 500 not ideal. In the situation of a partial timeframe overlap, there is 501 no clear way to distinguish the impact of the overlap. The receiver 502 would need to accept or reject the duplicate data in whole. 504 3. Verifying External Destinations 506 It is possible to specify destinations for the different reports that 507 are outside the authority of the Domain Owner making the request. 508 This allows domains that do not operate mail servers to request 509 reports and have them go someplace that is able to receive and 510 process them. 512 Without checks, this would allow a bad actor to publish a DMARC 513 policy record that requests that reports be sent to a victim address, 514 and then send a large volume of mail that will fail both DKIM and SPF 515 checks to a wide variety of destinations; the victim will in turn be 516 flooded with unwanted reports. Therefore, a verification mechanism 517 is included. 519 When a Mail Receiver discovers a DMARC policy in the DNS, and the 520 Organizational Domain at which that record was discovered is not 521 identical to the Organizational Domain of the host part of the 522 authority component of a [URI] specified in the "rua" or "ruf" tag, 523 the following verification steps MUST be taken: 525 1. Extract the host portion of the authority component of the URI. 526 Call this the "destination host", as it refers to a Report 527 Receiver. 529 2. Prepend the string "_report._dmarc". 531 3. Prepend the domain name from which the policy was retrieved, 532 after conversion to an A-label if needed. 534 4. Query the DNS for a TXT record at the constructed name. If the 535 result of this request is a temporary DNS error of some kind 536 (e.g., a timeout), the Mail Receiver MAY elect to temporarily 537 fail the delivery so the verification test can be repeated later. 539 5. For each record returned, parse the result as a series of 540 "tag=value" pairs, i.e., the same overall format as the policy 541 record (see Section 6.4). In particular, the "v=DMARC1" tag is 542 mandatory and MUST appear first in the list. Discard any that do 543 not pass this test. 545 6. If the result includes no TXT resource records that pass basic 546 parsing, a positive determination of the external reporting 547 relationship cannot be made; stop. 549 7. If at least one TXT resource record remains in the set after 550 parsing, then the external reporting arrangement was authorized 551 by the Report Receiver. 553 8. If a "rua" or "ruf" tag is thus discovered, replace the 554 corresponding value extracted from the domain's DMARC policy 555 record with the one found in this record. This permits the 556 Report Receiver to override the report destination. However, to 557 prevent loops or indirect abuse, the overriding URI MUST use the 558 same destination host from the first step. 560 For example, if a DMARC policy query for "blue.example.com" contained 561 "rua=mailto:reports@red.example.net", the host extracted from the 562 latter ("red.example.net") does not match "blue.example.com", so this 563 procedure is enacted. A TXT query for 564 "blue.example.com._report._dmarc.red.example.net" is issued. If a 565 single reply comes back containing a tag of "v=DMARC1", then the 566 relationship between the two is confirmed. Moreover, 567 "red.example.net" has the opportunity to override the report 568 destination requested by "blue.example.com" if needed. 570 Where the above algorithm fails to confirm that the external 571 reporting was authorized by the Report Receiver, the URI MUST be 572 ignored by the Mail Receiver generating the report. Further, if the 573 confirming record includes a URI whose host is again different than 574 the domain publishing that override, the Mail Receiver generating the 575 report MUST NOT generate a report to either the original or the 576 override URI. A Report Receiver publishes such a record in its DNS 577 if it wishes to receive reports for other domains. 579 A Report Receiver that is willing to receive reports for any domain 580 can use a wildcard DNS record. For example, a TXT resource record at 581 "*._report._dmarc.example.com" containing at least "v=DMARC1" 582 confirms that example.com is willing to receive DMARC reports for any 583 domain. 585 If the Report Receiver is overcome by volume, it can simply remove 586 the confirming DNS record. However, due to positive caching, the 587 change could take as long as the time-to-live (TTL) on the record to 588 go into effect. 590 A Mail Receiver might decide not to enact this procedure if, for 591 example, it relies on a local list of domains for which external 592 reporting addresses are permitted. 594 4. Extensible Reporting 596 A DMARC report should allow for some extensibility, as defined by 597 future documents that utilize DMARC as a foundation. These 598 extensions MUST be properly formatted XML and meant to exist within 599 the structure of a DMARC report. They MUST NOT alter the existing 600 DMARC structure, but instead exist self-contained within an 601 element. This element MUST be a child of the 602 element. 604 A DMARC report should allow for some extensibility, as defined by 605 future documents that utilize DMARC as a foundation. These 606 extensions MUST be properly formatted XML and meant to exist within 607 the structure of a DMARC report. Extensions MAY exist in one of two 608 places; within the record element, or in a separate extensions 609 element under the feedback element. In either case, the extensions 610 MUST contain a URI to the definition of the extension so that the 611 receiver understands how to interpret the data. 613 Within the record element: 615 ... 616 617 618 192.168.1.1 619 15 620 ... 621 622 623 ... 624 625 626 627 ... 629 Within the feedback element: 631 632 ... 633 634 635 ... 636 637 638 640 In both cases "extensionName" should be replaced with an appropriate 641 single-word title. 643 A DMARC report receiver SHOULD NOT generate a processing error when 644 this element is absent or empty. Furthermore, if a 645 processor is unable to handle an extension in a report, it SHOULD 646 ignore the data, and continue to the next extension. 648 5. IANA Considerations 650 TBD 652 6. Privacy Considerations 654 This section will discuss exposure related to DMARC aggregate 655 reporting. 657 6.1. Data Exposure Considerations 659 Aggregate reports are limited in scope to DMARC policy and 660 disposition results, to information pertaining to the underlying 661 authentication mechanisms, and to the identifiers involved in DMARC 662 validation. 664 Aggregate report may expose sender and recipient identifiers, 665 specifically the RFC5322.From addresses. 667 Domain Owners requesting reports will receive information about mail 668 claiming to be from them, which includes mail that was not, in fact, 669 from them. Information about the final destination of mail where it 670 might otherwise be obscured by intermediate systems will therefore be 671 exposed. 673 When message-forwarding arrangements exist, Domain Owners requesting 674 reports will also receive information about mail forwarded to domains 675 that were not originally part of their messages' recipient lists. 676 This means that destination domains previously unknown to the Domain 677 Owner may now become visible. 679 Disclosure of information about the messages is being requested by 680 the entity generating the email in the first place, i.e., the Domain 681 Owner and not the Mail Receiver, so this may not fit squarely within 682 existing privacy policy provisions. For some providers, aggregate 683 reporting is viewed as a function similar to complaint reporting 684 about spamming or phishing and are treated similarly under the 685 privacy policy. Report generators (i.e., Mail Receivers) are 686 encouraged to review their reporting limitations under such policies 687 before enabling DMARC reporting. 689 6.2. Report Recipients 691 A DMARC record can specify that reports should be sent to an 692 intermediary operating on behalf of the Domain Owner. This is done 693 when the Domain Owner contracts with an entity to monitor mail 694 streams for abuse and performance issues. Receipt by third parties 695 of such data may or may not be permitted by the Mail Receiver's 696 privacy policy, terms of use, or other similar governing document. 697 Domain Owners and Mail Receivers should both review and understand if 698 their own internal policies constrain the use and transmission of 699 DMARC reporting. 701 Some potential exists for report recipients to perform traffic 702 analysis, making it possible to obtain metadata about the Receiver's 703 traffic. In addition to verifying compliance with policies, 704 Receivers need to consider that before sending reports to a third 705 party. 707 6.3. Data Contained Within Reports (Tkt64) 709 Aggregate feedback reports contain aggregated data relating to 710 messages purportedly originating from the Domain Owner. The data 711 does not contain any identifying characteristics about individual 712 users. No personal information such as individual email addresses, 713 IP addresses of individuals, or the content of any messages, is 714 included in reports. 716 Mail Receivers should have no concerns in sending reports as they do 717 not contain personal information. In all cases, the data within the 718 reports relates to the domain-level authentication information 719 provided by mail servers sending messages on behalf of the Domain 720 Owner. This information is necessary to assist Domain Owners in 721 implementing and maintaining DMARC. 723 Domain Owners should have no concerns in receiving reports as they do 724 not contain personal information. The reports only contain 725 aggregated data related to the domain-level authentication details of 726 messages claiming to originate from their domain. This information 727 is essential for the proper implementation and operation of DMARC. 728 Domain Owners who are unable to receive reports for organizational 729 reasons, can choose to exclusively direct the reports to an external 730 processor. 732 7. Security Considerations 734 TBD 736 8. Appendix A. DMARC XML Schema 738 739 742 744 745 746 748 750 751 753 754 763 764 765 767 769 771 773 775 777 778 780 781 782 783 784 785 786 788 790 791 792 793 794 795 797 799 800 806 807 808 809 810 811 812 814 816 817 818 819 821 822 824 825 827 828 830 831 833 834 836 837 839 840 842 843 844 845 846 847 848 849 850 852 853 854 855 856 857 858 860 862 863 864 865 866 867 868 869 870 871 873 876 877 878 880 882 883 885 890 891 892 893 894 895 897 898 900 903 906 907 908 911 912 914 915 916 917 919 921 923 925 928 929 931 932 933 934 936 937 939 940 942 943 945 947 948 949 950 951 952 953 954 955 956 957 959 960 961 962 964 965 967 968 970 972 974 975 977 978 979 980 981 982 983 985 986 987 988 989 990 991 992 993 994 995 996 997 998 1000 1001 1002 1003 1005 1006 1008 1009 1011 1019 1021 1022 1024 1026 1027 1028 1030 1032 1033 1035 1037 1039 1042 1043 1044 1045 1047 1049 1050 1052 1055 1056 1057 1058 1059 1061 1064 1067 1069 1070 1071 1072 1074 9. Appendix B. Sample Report 1076 1077 1078 2.0 1079 Sample Reporter 1080 report_sender@example-reporter.com 1081 ... 1082 3v98abbp8ya9n3va8yr8oa3ya 1083 1084 161212415 1085 161221511 1086 1087 1088 1089 example.com 1090

quarantine

1091 none 1092 n 1093 1094 1095 1096 192.168.4.4 1097 123 1098 1099 quarantine 1100 pass 1101 fail 1102 1103 1104 1105 example.com 1106 1107 1108 1109 example.com 1110 pass 1111 abc123 1112 1113 1114 example.com> 1115 fail 1116 1117 1118 1119 1120 1121 1122 1123 1125 10. Normative References 1127 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 1128 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 1129 RFC 6376, DOI 10.17487/RFC6376, September 2011, 1130 . 1132 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 1133 Authorizing Use of Domains in Email, Version 1", RFC 7208, 1134 DOI 10.17487/RFC7208, April 2014, 1135 . 1137 Author's Address 1139 Alex Brotman 1140 Comcast, Inc. 1142 Email: alex_brotman@comcast.com