idnits 2.17.1 draft-ietf-dmarc-aggregate-reporting-05.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 three pr...' RFC 2119 keyword, line 191: '...-based data. Each report MUST contain...' RFC 2119 keyword, line 192: '...in. A single report MUST contain data...' RFC 2119 keyword, line 194: '...porting period, a reporting entity MAY...' RFC 2119 keyword, line 196: '... SHOULD note only the final configur...' (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 (20 April 2022) is 736 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 457, but not defined == Missing Reference: 'MIME' is mentioned on line 374, but not defined == Missing Reference: 'GZIP' is mentioned on line 384, but not defined == Missing Reference: 'URI' is mentioned on line 523, but not defined == Missing Reference: '0-9' is mentioned on line 910, but not defined == Missing Reference: '0-4' is mentioned on line 910, but not defined == Missing Reference: '0-5' is mentioned on line 910, 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) 20 April 2022 5 Intended status: Standards Track 6 Expires: 22 October 2022 8 DMARC Aggregate Reporting 9 draft-ietf-dmarc-aggregate-reporting-05 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 22 October 2022. 38 Copyright Notice 40 Copyright (c) 2022 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 . . . . . . . . . . . . . . . . . 24 79 10. Normative References . . . . . . . . . . . . . . . . . . . . 25 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 three primary sections; one 190 consisting of descriptive information (with two subsections), and the 191 other a set of IP-focused row-based data. Each report MUST contain 192 data for only one Author Domain. A single report MUST contain data 193 for one policy configuration. If multiple configurations were 194 observed during a single reporting period, a reporting entity MAY 195 choose to send multiple reports, otherwise the reporting entity 196 SHOULD note only the final configuration observed during the period. 197 See below for 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, testing, and 210 version_published. There MAY be an optional third section for 211 extensions. 213 Within the data section, the report will contain row(s) of data 214 stating which IPs were seen to have delivered messages for the Author 215 Domain to the receiving system. For each IP that is being reported, 216 there will be at least one record element, which will then have each 217 of a row, identifiers, and auth_results sub-element. Within the row 218 element, there MUST be source_ip and count. There MUST also exist a 219 policy_evaluated, with sub-elements of disposition, dkim, and spf. 220 There MAY be an element for reason, meant to include any notes the 221 reporter might want to include as to why the disposition policy does 222 not match the policy_published, such as a Local Policy override 223 (possible values listed in Appendix A). The dkim and spf elements 224 MUST be the evaluated values as they relate to DMARC, not the values 225 the receiver may have used when overriding the policy. Within the 226 identifiers element, there MUST exist the data that was used to apply 227 policy for the given IP. In most cases, this will be a header_from 228 element, which will contain the 5322.From domain from the message. 230 There MUST be an auth_results element within the 'record' element. 231 This will contain the data related to authenticating the messages 232 associated with this sending IP. The dkim sub-element is optional as 233 not all messages are signed, while there MUST be one spf sub-element. 234 These elements MUST have a domain that was used during validation, as 235 well as result. The dkim element MUST include a selector element 236 that was observed during validation. For the spf element, the result 237 element MUST contain a lower-case string where the value is one of 238 none/neutral/pass/fail/softfail/temperror/permerror. The dkim result 239 MUST contain a lower-case string where the value is one of 240 none/pass/fail/policy/neutral/temperror/permerror. Both the spf and 241 dkim results may optionally include a human_readable field meant for 242 the report to convey more descriptive information back to the domain 243 holder relating to evaluation failures. There MAY exist an optional 244 section for extensions. 246 2.1.1. Handling Domains in Reports 248 In the same report, there MUST be a single Policy Domain, though 249 there could be multiple 5322.From Domains. Each 5322.From domain 250 will create its own record within the report. Consider the case 251 where there are three domains with traffic volume to report: 252 example.com, foo.example.com, and bar.example.com. There will be 253 explicit DMARC records for example.com and bar.example.com, with 254 distinct policies. There is no explicit DMARC record for 255 foo.example.com, so it will be reliant on the policy described for 256 example.com. For a report period, there would now be two reports. 257 The first will be for bar.example.com, and contain only one record, 258 for bar.example.com. The second report would be for example domain 259 contain multiple record elements, one for example.com and one for 260 foo.example.com (and extensibly, other record elements for subdomains 261 which likewise did not have an explicit DMARC policy declared). 263 2.1.2. DKIM Signatures in Aggregate Report 265 Within a single message, the possibility exists that there could be 266 multiple DKIM signatures. When validation of the message occurs, 267 some signatures may pass, while some may not. As these pertain to 268 DMARC, and especially to aggregate reporting, reporters may not find 269 it clear which DKIM signatures they should include in a report. 270 Signatures, regardless of outcome, could help the report ingester 271 determine the source of a message. However, there is a preference as 272 to which signatures are included. 274 1. A signature that passes DKIM, in strict alignment with the 275 5322.From domain 277 2. A signature that passes DKIM, in relaxed alignment with the 278 5322.From domain 280 3. Any other DKIM signatures that pass 282 4. DKIM signatures that do not pass 283 A report SHOULD contain no more than 100 signatures for a given row, 284 in decreasing priority. 286 2.1.3. Unique Identifiers in Aggregate Reporting 288 There are a few places where a unique identifier is specified as part 289 of the body of the report, the subject, and so on. These unique 290 identifiers should be consistent per each report. Specified below, 291 the reader will see a msg-id, Report-ID, unique-id. These are the 292 fields that MUST be identical when used. 294 2.2. Extensions 296 There MAY be optional sections for extensions within the document. 297 The absence or existence of this section SHOULD NOT create an error 298 when processing reports. This will be covered in a separate section. 300 2.3. Changes in Policy During Reporting Period 302 Note that Domain Owners or their agents may change the published 303 DMARC policy for a domain or subdomain at any time. From a Mail 304 Receiver's perspective, this will occur during a reporting period and 305 may be noticed during that period, at the end of that period when 306 reports are generated, or during a subsequent reporting period, all 307 depending on the Mail Receiver's implementation. Under these 308 conditions, it is possible that a Mail Receiver could do any of the 309 following: 311 * generate for such a reporting period a single aggregate report 312 that includes message dispositions based on the old policy, or a 313 mix of the two policies, even though the report only contains a 314 single "policy_published" element; 316 * generate multiple reports for the same period, one for each 317 published policy occurring during the reporting period; 319 * generate a report whose end time occurs when the updated policy 320 was detected, regardless of any requested report interval. 322 Such policy changes are expected to be infrequent for any given 323 domain, whereas more stringent policy monitoring requirements on the 324 Mail Receiver would produce a very large burden at Internet scale. 325 Therefore, it is the responsibility of report consumers and Domain 326 Owners to be aware of this situation and allow for such mixed reports 327 during the propagation of the new policy to Mail Receivers. 329 2.4. Recommended Reporting Periods 331 Aggregate reports are most useful when they all cover a common time 332 period. By contrast, correlation of these reports from multiple 333 generators when they cover incongruent time periods is difficult or 334 impossible. Report generators SHOULD, wherever possible, adhere to 335 hour boundaries for the reporting period they are using. For 336 example, starting a per-day report at 00:00; starting per-hour 337 reports at 00:00, 01:00, 02:00; etc. Report generators using a 338 24-hour report period are strongly encouraged to begin that period at 339 00:00 UTC, regardless of local timezone or time of report production, 340 in order to facilitate correlation. 342 2.5. Report Request Discovery 344 A Mail Receiver discovers reporting requests when it looks up a DMARC 345 policy record that corresponds to an RFC5322.From domain on received 346 mail. The presence of the "rua" tag specifies where to send 347 feedback. 349 2.6. Transport 351 Where the URI specified in a "rua" tag does not specify otherwise, a 352 Mail Receiver generating a feedback report SHOULD employ a secure 353 transport mechanism. 355 The Mail Receiver, after preparing a report, MUST evaluate the 356 provided reporting URIs in the order given. Any reporting URI that 357 includes a size limitation exceeded by the generated report (after 358 compression and after any encoding required by the particular 359 transport mechanism) MUST NOT be used. An attempt MUST be made to 360 deliver an aggregate report to every remaining URI, up to the 361 Receiver's limits on supported URIs. 363 If transport is not possible because the services advertised by the 364 published URIs are not able to accept reports (e.g., the URI refers 365 to a service that is unreachable, or all provided URIs specify size 366 limits exceeded by the generated record), the Mail Receiver MAY send 367 a short report (see Section 7.2.2) indicating that a report is 368 available but could not be sent. The Mail Receiver MAY cache that 369 data and try again later, or MAY discard data that could not be sent. 371 2.6.1. Email 373 The message generated by the Mail Receiver MUST be a [MAIL] message 374 formatted per [MIME]. The aggregate report itself MUST be included 375 in one of the parts of the message. A human-readable portion MAY be 376 included as a MIME part (such as a text/plain part). 378 The aggregate data MUST be an XML file that SHOULD be subjected to 379 GZIP compression. Declining to apply compression can cause the 380 report to be too large for a receiver to process (a commonly observed 381 receiver limit is ten megabytes); doing the compression increases the 382 chances of acceptance of the report at some compute cost. The 383 aggregate data MUST be present using the media type "application/ 384 gzip" if compressed (see [GZIP]), and "text/xml" otherwise. The 385 filename MUST be constructed using the following ABNF: 387 filename = receiver "!" policy-domain "!" begin-timestamp 388 "!" end-timestamp [ "!" unique-id ] "." extension 390 receiver = domain 391 ; imported from [MAIL] 393 policy-domain = domain 395 begin-timestamp = 1*DIGIT 396 ; seconds since 00:00:00 UTC January 1, 1970 397 ; indicating start of the time range contained 398 ; in the report 400 end-timestamp = 1*DIGIT 401 ; seconds since 00:00:00 UTC January 1, 1970 402 ; indicating end of the time range contained 403 ; in the report 405 unique-id = 1*(ALPHA / DIGIT) 407 extension = "xml" / "xml.gz" 409 The extension MUST be "xml" for a plain XML file, or "xml.gz" for an 410 XML file compressed using GZIP. 412 "unique-id" allows an optional unique ID generated by the Mail 413 Receiver to distinguish among multiple reports generated 414 simultaneously by different sources within the same Domain Owner. 416 If a report generator needs to re-send a report, the system MUST use 417 the same filename as the original report. This would allow the 418 receiver to overwrite the data from the original, or discard second 419 instance of the report. 421 For example, this is a sample filename for the gzip file of a report 422 to the Domain Owner "example.com" from the Mail Receiver 423 "mail.receiver.example": 425 mail.receiver.example!example.com!1013662812!1013749130.gz 427 No specific MIME message structure is required. It is presumed that 428 the aggregate reporting address will be equipped to extract MIME 429 parts with the prescribed media type and filename and ignore the 430 rest. 432 Email streams carrying DMARC feedback data MUST conform to the DMARC 433 mechanism, thereby resulting in an aligned "pass" (see Section 3.1). 434 This practice minimizes the risk of report consumers processing 435 fraudulent reports. 437 The RFC5322.Subject field for individual report submissions MUST 438 conform to the following ABNF: 440 dmarc-subject = %x52.65.70.6f.72.74 1*FWS ; "Report" 441 %x44.6f.6d.61.69.6e.3a 1*FWS ; "Domain:" 442 domain-name 1*FWS ; from RFC 6376 443 %x53.75.62.6d.69.74.74.65.72.3a ; "Submitter:" 444 1*FWS domain-name 1*FWS 445 %x52.65.70.6f.72.74.2d.49.44.3a ; "Report-ID:" 446 msg-id ; from RFC 5322 448 The first domain-name indicates the DNS domain name about which the 449 report was generated. The second domain-name indicates the DNS 450 domain name representing the Mail Receiver generating the report. 451 The purpose of the Report-ID: portion of the field is to enable the 452 Domain Owner to identify and ignore duplicate reports that might be 453 sent by a Mail Receiver. 455 For instance, this is a possible Subject field for a report to the 456 Domain Owner "example.com" from the Mail Receiver 457 "mail.receiver.example". It is line-wrapped as allowed by [MAIL]: 459 Subject: Report Domain: example.com 460 Submitter: mail.receiver.example 461 Report-ID: <2002.02.15.1> 463 This transport mechanism potentially encounters a problem when 464 feedback data size exceeds maximum allowable attachment sizes for 465 either the generator or the consumer. See Section 7.2.2 for further 466 discussion. 468 Optionally, the report sender MAY choose to use the same msg-id as a 469 part or whole of the 5322.Message-Id header included with the report. 470 Doing so may help receivers distinguish when a message is a re- 471 transmission or duplicate report. 473 2.6.2. Other Methods 475 The specification as written allows for the addition of other 476 registered URI schemes to be supported in later versions. 478 2.6.3. Handling of Duplicates 480 There may be a situation where the report generator attempts to 481 deliver duplicate information to the receiver. This may manifest as 482 an exact duplicate of the report, or as duplicate information between 483 two reports. In these situations, the decision of how to handle the 484 duplicate data lies with the receiver. As noted above, the sender 485 MUST use the same unique identifiers when sending the report. This 486 allows the receiver to better understand when duplicates happen. A 487 few options on how to handle that duplicate information: 489 * Reject back to sender, ideally with a permfail error noting the 490 duplicate receipt 492 * Discard upon receipt 494 * Inspect the contents to evaluate the timestamps and reported data, 495 act as appropriate 497 * Accept the duplicate data 499 When accepting the data, that's likely in a situation where it's not 500 yet noticed, or a one-off experience. Long term, duplicate data is 501 not ideal. In the situation of a partial time frame overlap, there 502 is no clear way to distinguish the impact of the overlap. The 503 receiver would need to accept or reject the duplicate data in whole. 505 3. Verifying External Destinations 507 It is possible to specify destinations for the different reports that 508 are outside the authority of the Domain Owner making the request. 509 This allows domains that do not operate mail servers to request 510 reports and have them go someplace that is able to receive and 511 process them. 513 Without checks, this would allow a bad actor to publish a DMARC 514 policy record that requests that reports be sent to a victim address, 515 and then send a large volume of mail that will fail both DKIM and SPF 516 checks to a wide variety of destinations; the victim will in turn be 517 flooded with unwanted reports. Therefore, a verification mechanism 518 is included. 520 When a Mail Receiver discovers a DMARC policy in the DNS, and the 521 Organizational Domain at which that record was discovered is not 522 identical to the Organizational Domain of the host part of the 523 authority component of a [URI] specified in the "rua" or "ruf" tag, 524 the following verification steps MUST be taken: 526 1. Extract the host portion of the authority component of the URI. 527 Call this the "destination host", as it refers to a Report 528 Receiver. 530 2. Prepend the string "_report._dmarc". 532 3. Prepend the domain name from which the policy was retrieved, 533 after conversion to an A-label if needed. 535 4. Query the DNS for a TXT record at the constructed name. If the 536 result of this request is a temporary DNS error of some kind 537 (e.g., a timeout), the Mail Receiver MAY elect to temporarily 538 fail the delivery so the verification test can be repeated later. 540 5. For each record returned, parse the result as a series of 541 "tag=value" pairs, i.e., the same overall format as the policy 542 record (see Section 6.4). In particular, the "v=DMARC1" tag is 543 mandatory and MUST appear first in the list. Discard any that do 544 not pass this test. 546 6. If the result includes no TXT resource records that pass basic 547 parsing, a positive determination of the external reporting 548 relationship cannot be made; stop. 550 7. If at least one TXT resource record remains in the set after 551 parsing, then the external reporting arrangement was authorized 552 by the Report Receiver. 554 8. If a "rua" or "ruf" tag is thus discovered, replace the 555 corresponding value extracted from the domain's DMARC policy 556 record with the one found in this record. This permits the 557 Report Receiver to override the report destination. However, to 558 prevent loops or indirect abuse, the overriding URI MUST use the 559 same destination host from the first step. 561 For example, if a DMARC policy query for "blue.example.com" contained 562 "rua=mailto:reports@red.example.net", the host extracted from the 563 latter ("red.example.net") does not match "blue.example.com", so this 564 procedure is enacted. A TXT query for 565 "blue.example.com._report._dmarc.red.example.net" is issued. If a 566 single reply comes back containing a tag of "v=DMARC1", then the 567 relationship between the two is confirmed. Moreover, 568 "red.example.net" has the opportunity to override the report 569 destination requested by "blue.example.com" if needed. 571 Where the above algorithm fails to confirm that the external 572 reporting was authorized by the Report Receiver, the URI MUST be 573 ignored by the Mail Receiver generating the report. Further, if the 574 confirming record includes a URI whose host is again different than 575 the domain publishing that override, the Mail Receiver generating the 576 report MUST NOT generate a report to either the original or the 577 override URI. A Report Receiver publishes such a record in its DNS 578 if it wishes to receive reports for other domains. 580 A Report Receiver that is willing to receive reports for any domain 581 can use a wildcard DNS record. For example, a TXT resource record at 582 "*._report._dmarc.example.com" containing at least "v=DMARC1" 583 confirms that example.com is willing to receive DMARC reports for any 584 domain. 586 If the Report Receiver is overcome by volume, it can simply remove 587 the confirming DNS record. However, due to positive caching, the 588 change could take as long as the time-to-live (TTL) on the record to 589 go into effect. 591 A Mail Receiver might decide not to enact this procedure if, for 592 example, it relies on a local list of domains for which external 593 reporting addresses are permitted. 595 4. Extensible Reporting 597 A DMARC report should allow for some extensibility, as defined by 598 future documents that utilize DMARC as a foundation. These 599 extensions MUST be properly formatted XML and meant to exist within 600 the structure of a DMARC report. They MUST NOT alter the existing 601 DMARC structure, but instead exist self-contained within an 602 element. This element MUST be a child of the 603 element. 605 A DMARC report should allow for some extensibility, as defined by 606 future documents that utilize DMARC as a foundation. These 607 extensions MUST be properly formatted XML and meant to exist within 608 the structure of a DMARC report. Extensions MAY exist in one of two 609 places; within the record element, or in a separate extensions 610 element under the feedback element. In either case, the extensions 611 MUST contain a URI to the definition of the extension so that the 612 receiver understands how to interpret the data. 614 Within the record element: 616 ... 617 618 619 192.168.1.1 620 15 621 ... 622 623 624 ... 625 626 627 628 ... 630 Within the feedback element: 632 633 ... 634 635 636 ... 637 638 639 641 In both cases "extensionName" should be replaced with an appropriate 642 single-word title. 644 A DMARC report receiver SHOULD NOT generate a processing error when 645 this element is absent or empty. Furthermore, if a 646 processor is unable to handle an extension in a report, it SHOULD 647 ignore the data, and continue to the next extension. 649 5. IANA Considerations 651 TBD 653 6. Privacy Considerations 655 This section will discuss exposure related to DMARC aggregate 656 reporting. 658 6.1. Data Exposure Considerations 660 Aggregate reports are limited in scope to DMARC policy and 661 disposition results, to information pertaining to the underlying 662 authentication mechanisms, and to the identifiers involved in DMARC 663 validation. 665 Aggregate report may expose sender and recipient identifiers, 666 specifically the RFC5322.From addresses. 668 Domain Owners requesting reports will receive information about mail 669 claiming to be from them, which includes mail that was not, in fact, 670 from them. Information about the final destination of mail where it 671 might otherwise be obscured by intermediate systems will therefore be 672 exposed. 674 When message-forwarding arrangements exist, Domain Owners requesting 675 reports will also receive information about mail forwarded to domains 676 that were not originally part of their messages' recipient lists. 677 This means that destination domains previously unknown to the Domain 678 Owner may now become visible. 680 Disclosure of information about the messages is being requested by 681 the entity generating the email in the first place, i.e., the Domain 682 Owner and not the Mail Receiver, so this may not fit squarely within 683 existing privacy policy provisions. For some providers, aggregate 684 reporting is viewed as a function similar to complaint reporting 685 about spamming or phishing and are treated similarly under the 686 privacy policy. Report generators (i.e., Mail Receivers) are 687 encouraged to review their reporting limitations under such policies 688 before enabling DMARC reporting. 690 6.2. Report Recipients 692 A DMARC record can specify that reports should be sent to an 693 intermediary operating on behalf of the Domain Owner. This is done 694 when the Domain Owner contracts with an entity to monitor mail 695 streams for abuse and performance issues. Receipt by third parties 696 of such data may or may not be permitted by the Mail Receiver's 697 privacy policy, terms of use, or other similar governing document. 698 Domain Owners and Mail Receivers should both review and understand if 699 their own internal policies constrain the use and transmission of 700 DMARC reporting. 702 Some potential exists for report recipients to perform traffic 703 analysis, making it possible to obtain metadata about the Receiver's 704 traffic. In addition to verifying compliance with policies, 705 Receivers need to consider that before sending reports to a third 706 party. 708 6.3. Data Contained Within Reports (Tkt64) 710 Aggregate feedback reports contain aggregated data relating to 711 messages purportedly originating from the Domain Owner. The data 712 does not contain any identifying characteristics about individual 713 users. No personal information such as individual email addresses, 714 IP addresses of individuals, or the content of any messages, is 715 included in reports. 717 Mail Receivers should have no concerns in sending reports as they do 718 not contain personal information. In all cases, the data within the 719 reports relates to the domain-level authentication information 720 provided by mail servers sending messages on behalf of the Domain 721 Owner. This information is necessary to assist Domain Owners in 722 implementing and maintaining DMARC. 724 Domain Owners should have no concerns in receiving reports as they do 725 not contain personal information. The reports only contain 726 aggregated data related to the domain-level authentication details of 727 messages claiming to originate from their domain. This information 728 is essential for the proper implementation and operation of DMARC. 729 Domain Owners who are unable to receive reports for organizational 730 reasons, can choose to exclusively direct the reports to an external 731 processor. 733 7. Security Considerations 735 TBD 737 8. Appendix A. DMARC XML Schema 739 740 743 745 746 747 749 751 752 754 755 764 765 766 768 770 772 774 776 778 779 781 782 783 784 785 786 787 789 791 792 793 794 795 796 798 800 801 807 808 809 810 811 812 813 815 817 818 819 820 822 823 825 826 828 829 831 832 834 835 837 838 840 841 843 844 845 846 847 848 849 850 851 853 854 855 856 857 858 859 861 863 864 865 866 867 868 869 870 871 872 874 877 878 879 881 883 884 886 891 892 893 894 895 896 898 899 901 904 907 908 909 912 913 915 916 917 918 920 922 924 926 929 931 932 934 935 936 937 939 940 942 943 945 946 948 950 951 952 953 954 955 956 957 958 959 960 962 963 964 965 967 968 970 971 973 975 977 978 980 981 982 983 984 985 986 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1003 1004 1005 1006 1008 1009 1011 1012 1014 1022 1024 1025 1027 1029 1030 1031 1033 1035 1036 1038 1039 1041 1044 1045 1046 1047 1049 1051 1052 1054 1055 1056 1058 1059 1060 1061 1062 1063 1065 1068 1069 1070 1071 1072 1074 1077 1080 1082 1085 1086 1087 1088 1090 9. Appendix B. Sample Report 1092 1093 1094 2.0 1095 Sample Reporter 1096 report_sender@example-reporter.com 1097 ... 1098 3v98abbp8ya9n3va8yr8oa3ya 1099 1100 161212415 1101 161221511 1102 1103 1104 1105 example.com 1106

quarantine

1107 none 1108 n 1109 1110 1111 1112 192.168.4.4 1113 123 1114 1115 quarantine 1116 pass 1117 fail 1118 1119 1120 1121 example.com 1122 1123 1124 1125 example.com 1126 pass 1127 abc123 1128 1129 1130 example.com> 1131 fail 1132 1134 1135 1136 1137 1138 1139 1140 1142 10. Normative References 1144 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 1145 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 1146 RFC 6376, DOI 10.17487/RFC6376, September 2011, 1147 . 1149 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 1150 Authorizing Use of Domains in Email, Version 1", RFC 7208, 1151 DOI 10.17487/RFC7208, April 2014, 1152 . 1154 Author's Address 1156 Alex Brotman 1157 Comcast, Inc. 1158 Email: alex_brotman@comcast.com