idnits 2.17.1 draft-ietf-dmarc-aggregate-reporting-03.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 187: '...ggregate Reports MUST contain two prim...' RFC 2119 keyword, line 189: '...ta. Each report MUST contain data for...' RFC 2119 keyword, line 190: '... A single report MUST contain data for...' RFC 2119 keyword, line 192: '... a reporting entity MAY choose to send...' RFC 2119 keyword, line 193: '... reporting entity SHOULD note only the...' (51 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (18 August 2021) is 975 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 118, but not defined == Missing Reference: 'RFC8174' is mentioned on line 118, but not defined == Missing Reference: 'RefNeeded' is mentioned on line 202, but not defined == Missing Reference: 'MAIL' is mentioned on line 433, but not defined == Missing Reference: 'MIME' is mentioned on line 350, but not defined == Missing Reference: 'GZIP' is mentioned on line 360, but not defined == Missing Reference: 'URI' is mentioned on line 467, but not defined == Missing Reference: '0-9' is mentioned on line 845, but not defined == Missing Reference: '0-4' is mentioned on line 845, but not defined == Missing Reference: '0-5' is mentioned on line 845, 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) 18 August 2021 5 Intended status: Standards Track 6 Expires: 19 February 2022 8 DMARC Aggregate Reporting 9 draft-ietf-dmarc-aggregate-reporting-03 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 19 February 2022. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. DMARC Feedback . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Aggregate Reports . . . . . . . . . . . . . . . . . . . . 3 58 2.1.1. DKIM Signatures in Aggregate Report . . . . . . . . . 6 59 2.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . 6 60 2.3. Changes in Policy During Reporting Period . . . . . . . . 7 61 2.4. Recommended Reporting Periods . . . . . . . . . . . . . . 7 62 2.5. Report Request Discovery . . . . . . . . . . . . . . . . 7 63 2.6. Transport . . . . . . . . . . . . . . . . . . . . . . . . 8 64 2.6.1. Email . . . . . . . . . . . . . . . . . . . . . . . . 8 65 2.6.2. Other Methods . . . . . . . . . . . . . . . . . . . . 10 66 3. Verifying External Destinations . . . . . . . . . . . . . . . 10 67 4. Extensible Reporting . . . . . . . . . . . . . . . . . . . . 12 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 69 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 70 6.1. Data Exposure Considerations . . . . . . . . . . . . . . 14 71 6.2. Report Recipients . . . . . . . . . . . . . . . . . . . . 14 72 6.3. Data Contained Within Reports (Tkt64) . . . . . . . . . . 15 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 74 8. Appendix A. DMARC XML Schema . . . . . . . . . . . . . . . . 15 75 9. Appendix B. Sample Report . . . . . . . . . . . . . . . . . 22 76 10. Normative References . . . . . . . . . . . . . . . . . . . . 23 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23 79 1. Introduction 81 A key component of DMARC is the ability for domain holders to request 82 that receivers provide various types of reports. These reports allow 83 domain holders to have insight into which IP addresses are sending on 84 their behalf, and some insight into whether or not the volume may be 85 legitimate. These reports expose information relating to the DMARC 86 policy, as well as the outcome of SPF [RFC7208] & DKIM [RFC6376] 87 validation. 89 1.1. Terminology 91 In many IETF documents, several words, when they are in all capitals 92 as shown below, are used to signify the requirements in the 93 specification. These capitalized words can bring significant clarity 94 and consistency to documents because their meanings are well defined. 95 This document defines how those words are interpreted in IETF 96 documents when the words are in all capitals. 98 * These words can be used as defined here, but using them is not 99 required. Specifically, normative text does not require the use 100 of these key words. They are used for clarity and consistency 101 when that is what's wanted, but a lot of normative text does not 102 use them and is still normative. 104 * The words have the meanings specified herein only when they are in 105 all capitals. 107 * When these words are not capitalized, they have their normal 108 English meanings and are not affected by this document. 110 Authors who follow these guidelines should incorporate this phrase 111 near the beginning of their document: 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 114 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", 115 "MAY", and "OPTIONAL" in this document are to be interpreted as 116 described in BCP 14 [RFC2119] [RFC8174] when, and only when, they 117 appear in all capitals, as shown here. 119 2. DMARC Feedback 121 Providing Domain Owners with visibility into how Mail Receivers 122 implement and enforce the DMARC mechanism in the form of feedback is 123 critical to establishing and maintaining accurate authentication 124 deployments. When Domain Owners can see what effect their policies 125 and practices are having, they are better willing and able to use 126 quarantine and reject policies. 128 2.1. Aggregate Reports 130 The DMARC aggregate feedback report is designed to provide Domain 131 Owners with precise insight into: 133 * authentication results, 135 * corrective action that needs to be taken by Domain Owners, and 136 * the effect of Domain Owner DMARC policy on email streams processed 137 by Mail Receivers. 139 Aggregate DMARC feedback provides visibility into real-world email 140 streams that Domain Owners need to make informed decisions regarding 141 the publication of DMARC policy. When Domain Owners know what 142 legitimate mail they are sending, what the authentication results are 143 on that mail, and what forged mail receivers are getting, they can 144 make better decisions about the policies they need and the steps they 145 need to take to enable those policies. When Domain Owners set 146 policies appropriately and understand their effects, Mail Receivers 147 can act on them confidently. 149 Visibility comes in the form of daily (or more frequent) Mail 150 Receiver-originated feedback reports that contain aggregate data on 151 message streams relevant to the Domain Owner. This information 152 includes data about messages that passed DMARC authentication as well 153 as those that did not. 155 The report may include the following data: 157 * The DMARC policy discovered and applied, if any 159 * The selected message disposition 161 * The identifier evaluated by SPF and the SPF result, if any 163 * The identifier evaluated by DKIM and the DKIM result, if any 165 * For both DKIM and SPF, an indication of whether the identifier was 166 in alignment 168 * A separate report should be generated for each 5322.From 169 subdomain, regardless of which policy domain was used during 170 receipt of messages. In the case where the 5322.From domain does 171 not have its own DMARC record and uses the Organizational Domain 172 record, those should be included in the report for the 173 Organizational Domain. 175 * Sending and receiving domains 177 * The policy requested by the Domain Owner and the policy actually 178 applied (if different) 180 * The number of successful authentications 182 * The counts of messages based on all messages received, even if 183 their delivery is ultimately blocked by other filtering agents. 185 The format for these reports is defined in Appendix A. 187 DMARC Aggregate Reports MUST contain two primary sections; one 188 consisting of descriptive information and the other a set of IP- 189 focused row-based data. Each report MUST contain data for only one 190 Author Domain. A single report MUST contain data for one policy 191 configuration. If multiple configurations were observed during a 192 single reporting period, a reporting entity MAY choose to send 193 multiple reports, otherwise the reporting entity SHOULD note only the 194 final configuration observed during the period. See below for 195 further information. 197 The informative section MUST contain two sub-sections. One will be 198 the metadata section which MUST contain the fields related to 199 "org_name", "email", "report_id", and "date_range". Optional fields 200 MAY include "extra_contact_info", an "error" field, and an optional 201 "version" field. The version field, if present, MUST contain a "1.0" 202 [!@RFC7489] or "2.0" [RefNeeded], noting to which version of the 203 aggregate reporting specification the report adheres. The 204 "date_range" section which will note "begin" and "end" values as 205 epoch timestamps. The other sub-section will be the 206 "policy_published", and record the policy configuration observed by 207 the receiving system. Mandatory fields are "domain", "p", "sp", 208 "pct". Optional fields are "fo", "adkim", "aspf". There MAY be an 209 optional third section for "extensions". 211 Within the data section, the report will contain row(s) of data 212 stating which IPs were seen to have delivered messages for the Author 213 Domain to the receiving system. For each IP that is being reported, 214 there will be a "record" element, which will then have each of a 215 "row", "identifiers", and "auth_results" sub-element. Within the 216 "row" element, there MUST be "source_ip" and "count". There MUST 217 also exist a "policy_evaluated", with subelements of "disposition", 218 "dkim", and "spf". There MAY be an element for "reason", meant to 219 include any notes the reporter might want to include as to why the 220 "disposition" policy does not match the "policy_published", such as a 221 Local Policy override (possible values listed in Appendix A). The 222 "dkim" and "spf" elements MUST be the evaluated values as they relate 223 to DMARC, not the values the receiver may have used when overriding 224 the policy. Within the "identifiers" element, there MUST exist the 225 data that was used to apply policy for the given IP. In most cases, 226 this will be a "header_from" element, which will contain the 227 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 232 as not all messages are signed, while there MUST be one "spf" 233 subelement. These elements MUST have a "domain" that was used during 234 validation, as well as "result". The "dkim" element MUST include a 235 "selector" element that was observed during validation. For the 236 "spf" element, the "result" element MUST contain a lower-case string 237 where the value is one of none/neutral/pass/fail/softfail/temperror/ 238 permerror. The "dkim" result MUST contain a lower-case string where 239 the value is one of none/pass/fail/policy/neutral/temperror/ 240 permerror. Both the "spf" and "dkim" results may optionally include 241 a "human_readable" field meant for the report to convey more 242 descriptive information back to the domain holder relating to 243 evaluation failures. There MAY exist an optional section for 244 "extensions". 246 2.1.1. DKIM Signatures in Aggregate Report 248 Within a single message, the possibility exists that there could be 249 multiple DKIM signatures. When validation of the message occurs, 250 some signatures may pass, while some may not. As these pertain to 251 DMARC, and especially to aggregate reporting, reporters may not find 252 it clear which DKIM signatures they should include in a report. 253 Signatures, regardless of outcome, could help the report ingester 254 determine the source of a message. However, there is a preference as 255 to which signatures are included. 257 1. A signature that passes DKIM, in strict alignment with the 258 5322.From domain 260 2. A signature that passes DKIM, in relaxed alignment with the 261 5322.From domain 263 3. Any other DKIM signatures that pass 265 4. DKIM signatures that do not pass 267 A report SHOULD contain no more than 100 signatures for a given 268 "row", in decreasing priority. 270 2.2. Extensions 272 There MAY be optional sections for extensions within the document. 273 The absence or existence of this section SHOULD NOT create an error 274 when processing reports. This will be covered in a separate section. 276 2.3. Changes in Policy During Reporting Period 278 Note that Domain Owners or their agents may change the published 279 DMARC policy for a domain or subdomain at any time. From a Mail 280 Receiver's perspective, this will occur during a reporting period and 281 may be noticed during that period, at the end of that period when 282 reports are generated, or during a subsequent reporting period, all 283 depending on the Mail Receiver's implementation. Under these 284 conditions, it is possible that a Mail Receiver could do any of the 285 following: 287 * generate for such a reporting period a single aggregate report 288 that includes message dispositions based on the old policy, or a 289 mix of the two policies, even though the report only contains a 290 single "policy_published" element; 292 * generate multiple reports for the same period, one for each 293 published policy occurring during the reporting period; 295 * generate a report whose end time occurs when the updated policy 296 was detected, regardless of any requested report interval. 298 Such policy changes are expected to be infrequent for any given 299 domain, whereas more stringent policy monitoring requirements on the 300 Mail Receiver would produce a very large burden at Internet scale. 301 Therefore, it is the responsibility of report consumers and Domain 302 Owners to be aware of this situation and allow for such mixed reports 303 during the propagation of the new policy to Mail Receivers. 305 2.4. Recommended Reporting Periods 307 Aggregate reports are most useful when they all cover a common time 308 period. By contrast, correlation of these reports from multiple 309 generators when they cover incongruent time periods is difficult or 310 impossible. Report generators SHOULD, wherever possible, adhere to 311 hour boundaries for the reporting period they are using. For 312 example, starting a per-day report at 00:00; starting per-hour 313 reports at 00:00, 01:00, 02:00; etc. Report generators using a 314 24-hour report period are strongly encouraged to begin that period at 315 00:00 UTC, regardless of local timezone or time of report production, 316 in order to facilitate correlation. 318 2.5. Report Request Discovery 320 A Mail Receiver discovers reporting requests when it looks up a DMARC 321 policy record that corresponds to an RFC5322.From domain on received 322 mail. The presence of the "rua" tag specifies where to send 323 feedback. 325 2.6. Transport 327 Where the URI specified in a "rua" tag does not specify otherwise, a 328 Mail Receiver generating a feedback report SHOULD employ a secure 329 transport mechanism. 331 The Mail Receiver, after preparing a report, MUST evaluate the 332 provided reporting URIs in the order given. Any reporting URI that 333 includes a size limitation exceeded by the generated report (after 334 compression and after any encoding required by the particular 335 transport mechanism) MUST NOT be used. An attempt MUST be made to 336 deliver an aggregate report to every remaining URI, up to the 337 Receiver's limits on supported URIs. 339 If transport is not possible because the services advertised by the 340 published URIs are not able to accept reports (e.g., the URI refers 341 to a service that is unreachable, or all provided URIs specify size 342 limits exceeded by the generated record), the Mail Receiver MAY send 343 a short report (see Section 7.2.2) indicating that a report is 344 available but could not be sent. The Mail Receiver MAY cache that 345 data and try again later, or MAY discard data that could not be sent. 347 2.6.1. Email 349 The message generated by the Mail Receiver MUST be a [MAIL] message 350 formatted per [MIME]. The aggregate report itself MUST be included 351 in one of the parts of the message. A human-readable portion MAY be 352 included as a MIME part (such as a text/plain part). 354 The aggregate data MUST be an XML file that SHOULD be subjected to 355 GZIP compression. Declining to apply compression can cause the 356 report to be too large for a receiver to process (a commonly observed 357 receiver limit is ten megabytes); doing the compression increases the 358 chances of acceptance of the report at some compute cost. The 359 aggregate data MUST be present using the media type "application/ 360 gzip" if compressed (see [GZIP]), and "text/xml" otherwise. The 361 filename MUST be constructed using the following ABNF: 363 filename = receiver "!" policy-domain "!" begin-timestamp 364 "!" end-timestamp [ "!" unique-id ] "." extension 366 receiver = domain 367 ; imported from [MAIL] 369 policy-domain = domain 371 begin-timestamp = 1*DIGIT 372 ; seconds since 00:00:00 UTC January 1, 1970 373 ; indicating start of the time range contained 374 ; in the report 376 end-timestamp = 1*DIGIT 377 ; seconds since 00:00:00 UTC January 1, 1970 378 ; indicating end of the time range contained 379 ; in the report 381 unique-id = 1*(ALPHA / DIGIT) 383 extension = "xml" / "xml.gz" 385 The extension MUST be "xml" for a plain XML file, or "xml.gz" for an 386 XML file compressed using GZIP. 388 "unique-id" allows an optional unique ID generated by the Mail 389 Receiver to distinguish among multiple reports generated 390 simultaneously by different sources within the same Domain Owner. 392 If a report generator needs to re-send a report, the system SHOULD 393 use the same filename as the original report. This would allow the 394 receiver to overwrite the data from the original, or discard second 395 instance of the report. 397 For example, this is a sample filename for the gzip file of a report 398 to the Domain Owner "example.com" from the Mail Receiver 399 "mail.receiver.example": 401 mail.receiver.example!example.com!1013662812!1013749130.gz 403 No specific MIME message structure is required. It is presumed that 404 the aggregate reporting address will be equipped to extract MIME 405 parts with the prescribed media type and filename and ignore the 406 rest. 408 Email streams carrying DMARC feedback data MUST conform to the DMARC 409 mechanism, thereby resulting in an aligned "pass" (see Section 3.1). 410 This practice minimizes the risk of report consumers processing 411 fraudulent reports. 413 The RFC5322.Subject field for individual report submissions MUST 414 conform to the following ABNF: 416 dmarc-subject = %x52.65.70.6f.72.74 1*FWS ; "Report" 417 %x44.6f.6d.61.69.6e.3a 1*FWS ; "Domain:" 418 domain-name 1*FWS ; from RFC 6376 419 %x53.75.62.6d.69.74.74.65.72.3a ; "Submitter:" 420 1*FWS domain-name 1*FWS 421 %x52.65.70.6f.72.74.2d.49.44.3a ; "Report-ID:" 422 msg-id ; from RFC 5322 424 The first domain-name indicates the DNS domain name about which the 425 report was generated. The second domain-name indicates the DNS 426 domain name representing the Mail Receiver generating the report. 427 The purpose of the Report-ID: portion of the field is to enable the 428 Domain Owner to identify and ignore duplicate reports that might be 429 sent by a Mail Receiver. 431 For instance, this is a possible Subject field for a report to the 432 Domain Owner "example.com" from the Mail Receiver 433 "mail.receiver.example". It is line-wrapped as allowed by [MAIL]: 435 Subject: Report Domain: example.com 436 Submitter: mail.receiver.example 437 Report-ID: <2002.02.15.1> 439 This transport mechanism potentially encounters a problem when 440 feedback data size exceeds maximum allowable attachment sizes for 441 either the generator or the consumer. See Section 7.2.2 for further 442 discussion. 444 2.6.2. Other Methods 446 The specification as written allows for the addition of other 447 registered URI schemes to be supported in later versions. 449 3. Verifying External Destinations 451 It is possible to specify destinations for the different reports that 452 are outside the authority of the Domain Owner making the request. 453 This allows domains that do not operate mail servers to request 454 reports and have them go someplace that is able to receive and 455 process them. 457 Without checks, this would allow a bad actor to publish a DMARC 458 policy record that requests that reports be sent to a victim address, 459 and then send a large volume of mail that will fail both DKIM and SPF 460 checks to a wide variety of destinations; the victim will in turn be 461 flooded with unwanted reports. Therefore, a verification mechanism 462 is included. 464 When a Mail Receiver discovers a DMARC policy in the DNS, and the 465 Organizational Domain at which that record was discovered is not 466 identical to the Organizational Domain of the host part of the 467 authority component of a [URI] specified in the "rua" or "ruf" tag, 468 the following verification steps MUST be taken: 470 1. Extract the host portion of the authority component of the URI. 471 Call this the "destination host", as it refers to a Report 472 Receiver. 474 2. Prepend the string "_report._dmarc". 476 3. Prepend the domain name from which the policy was retrieved, 477 after conversion to an A-label if needed. 479 4. Query the DNS for a TXT record at the constructed name. If the 480 result of this request is a temporary DNS error of some kind 481 (e.g., a timeout), the Mail Receiver MAY elect to temporarily 482 fail the delivery so the verification test can be repeated later. 484 5. For each record returned, parse the result as a series of 485 "tag=value" pairs, i.e., the same overall format as the policy 486 record (see Section 6.4). In particular, the "v=DMARC1" tag is 487 mandatory and MUST appear first in the list. Discard any that do 488 not pass this test. 490 6. If the result includes no TXT resource records that pass basic 491 parsing, a positive determination of the external reporting 492 relationship cannot be made; stop. 494 7. If at least one TXT resource record remains in the set after 495 parsing, then the external reporting arrangement was authorized 496 by the Report Receiver. 498 8. If a "rua" or "ruf" tag is thus discovered, replace the 499 corresponding value extracted from the domain's DMARC policy 500 record with the one found in this record. This permits the 501 Report Receiver to override the report destination. However, to 502 prevent loops or indirect abuse, the overriding URI MUST use the 503 same destination host from the first step. 505 For example, if a DMARC policy query for "blue.example.com" contained 506 "rua=mailto:reports@red.example.net", the host extracted from the 507 latter ("red.example.net") does not match "blue.example.com", so this 508 procedure is enacted. A TXT query for 509 "blue.example.com._report._dmarc.red.example.net" is issued. If a 510 single reply comes back containing a tag of "v=DMARC1", then the 511 relationship between the two is confirmed. Moreover, 512 "red.example.net" has the opportunity to override the report 513 destination requested by "blue.example.com" if needed. 515 Where the above algorithm fails to confirm that the external 516 reporting was authorized by the Report Receiver, the URI MUST be 517 ignored by the Mail Receiver generating the report. Further, if the 518 confirming record includes a URI whose host is again different than 519 the domain publishing that override, the Mail Receiver generating the 520 report MUST NOT generate a report to either the original or the 521 override URI. A Report Receiver publishes such a record in its DNS 522 if it wishes to receive reports for other domains. 524 A Report Receiver that is willing to receive reports for any domain 525 can use a wildcard DNS record. For example, a TXT resource record at 526 "*._report._dmarc.example.com" containing at least "v=DMARC1" 527 confirms that example.com is willing to receive DMARC reports for any 528 domain. 530 If the Report Receiver is overcome by volume, it can simply remove 531 the confirming DNS record. However, due to positive caching, the 532 change could take as long as the time-to-live (TTL) on the record to 533 go into effect. 535 A Mail Receiver might decide not to enact this procedure if, for 536 example, it relies on a local list of domains for which external 537 reporting addresses are permitted. 539 4. Extensible Reporting 541 A DMARC report should allow for some extensibility, as defined by 542 future documents that utilize DMARC as a foundation. These 543 extensions MUST be properly formatted XML and meant to exist within 544 the structure of a DMARC report. They MUST NOT alter the existing 545 DMARC structure, but instead exist self-contained within an 546 "" element. This element MUST be a child of the 547 "" element. 549 A DMARC report should allow for some extensibility, as defined by 550 future documents that utilize DMARC as a foundation. These 551 extensions MUST be properly formatted XML and meant to exist within 552 the structure of a DMARC report. Extensions MAY exist in one of two 553 places; within the "record" element, or in a separate "extensions" 554 element under the "feedback" element. In either case, the extensions 555 MUST contain a URI to the definition of the extension so that the 556 receiver understands how to interpret the data. 558 Within the "record" element: 560 ... 561 562 563 192.168.1.1 564 15 565 ... 566 567 568 ... 569 570 571 572 ... 574 Within the "feedback" element: 576 577 ... 578 579 580 ... 581 582 583 585 In both cases "extensionName" should be replaced with an appropriate 586 single-word title. 588 A DMARC report receiver SHOULD NOT generate a processing error when 589 this "" element is absent or empty. Furthermore, if a 590 processor is unable to handle an extension in a report, it SHOULD 591 ignore the data, and continue to the next extension. 593 5. IANA Considerations 595 TBD 597 6. Privacy Considerations 599 This section will discuss exposure related to DMARC aggregate 600 reporting. 602 6.1. Data Exposure Considerations 604 Aggregate reports are limited in scope to DMARC policy and 605 disposition results, to information pertaining to the underlying 606 authentication mechanisms, and to the identifiers involved in DMARC 607 validation. 609 Aggregate report may expose sender and recipient identifiers, 610 specifically the RFC5322.From addresses. 612 Domain Owners requesting reports will receive information about mail 613 claiming to be from them, which includes mail that was not, in fact, 614 from them. Information about the final destination of mail where it 615 might otherwise be obscured by intermediate systems will therefore be 616 exposed. 618 When message-forwarding arrangements exist, Domain Owners requesting 619 reports will also receive information about mail forwarded to domains 620 that were not originally part of their messages' recipient lists. 621 This means that destination domains previously unknown to the Domain 622 Owner may now become visible. 624 Disclosure of information about the messages is being requested by 625 the entity generating the email in the first place, i.e., the Domain 626 Owner and not the Mail Receiver, so this may not fit squarely within 627 existing privacy policy provisions. For some providers, aggregate 628 reporting is viewed as a function similar to complaint reporting 629 about spamming or phishing and are treated similarly under the 630 privacy policy. Report generators (i.e., Mail Receivers) are 631 encouraged to review their reporting limitations under such policies 632 before enabling DMARC reporting. 634 6.2. Report Recipients 636 A DMARC record can specify that reports should be sent to an 637 intermediary operating on behalf of the Domain Owner. This is done 638 when the Domain Owner contracts with an entity to monitor mail 639 streams for abuse and performance issues. Receipt by third parties 640 of such data may or may not be permitted by the Mail Receiver's 641 privacy policy, terms of use, or other similar governing document. 642 Domain Owners and Mail Receivers should both review and understand if 643 their own internal policies constrain the use and transmission of 644 DMARC reporting. 646 Some potential exists for report recipients to perform traffic 647 analysis, making it possible to obtain metadata about the Receiver's 648 traffic. In addition to verifying compliance with policies, 649 Receivers need to consider that before sending reports to a third 650 party. 652 6.3. Data Contained Within Reports (Tkt64) 654 Aggregate feedback reports contain aggregated data relating to 655 messages purportedly originating from the Domain Owner. The data 656 does not contain any identifying characteristics about individual 657 users. No personal information such as individual email addresses, 658 IP addresses of individuals, or the content of any messages, is 659 included in reports. 661 Mail Receivers should have no concerns in sending reports as they do 662 not contain personal information. In all cases, the data within the 663 reports relates to the domain-level authentication information 664 provided by mail servers sending messages on behalf of the Domain 665 Owner. This information is necessary to assist Domain Owners in 666 implementing and maintaining DMARC. 668 Domain Owners should have no concerns in receiving reports as they do 669 not contain personal information. The reports only contain 670 aggregated data related to the domain-level authentication details of 671 messages claiming to originate from their domain. This information 672 is essential for the proper implementation and operation of DMARC. 673 Domain Owners who are unable to receive reports for organizational 674 reasons, can choose to exclusively direct the reports to an external 675 processor. 677 7. Security Considerations 679 TBD 681 8. Appendix A. DMARC XML Schema 683 684 687 689 690 691 693 695 696 698 699 708 709 710 712 714 716 718 720 722 723 725 726 727 728 729 730 731 733 735 736 737 738 739 740 742 744 745 751 752 753 754 755 756 757 759 761 762 763 764 766 767 769 770 772 773 775 776 778 779 781 782 784 785 787 788 789 790 791 792 793 794 795 797 799 800 801 802 803 804 805 806 807 808 810 813 814 815 817 819 820 822 827 828 829 830 831 832 834 835 836 839 842 843 844 847 848 850 851 852 853 855 857 859 861 864 865 867 868 869 870 872 873 875 876 878 879 881 883 884 885 886 887 888 889 890 891 892 893 895 896 897 898 900 901 903 904 906 908 910 911 913 914 915 916 917 918 919 921 922 923 924 925 926 927 928 929 930 931 932 933 934 936 937 938 939 941 942 944 945 947 955 957 958 960 962 963 964 966 968 969 971 972 974 977 978 979 980 982 984 985 987 990 991 992 993 994 996 999 1002 1004 1005 1006 1007 1009 9. Appendix B. Sample Report 1011 1012 1013 2.0 1014 Sample Reporter 1015 report_sender@example-reporter.com 1016 ... 1017 3v98abbp8ya9n3va8yr8oa3ya 1018 1019 161212415 1020 161221511 1021 1022 1023 1024 example.com 1025

quarantine

1026 none 1027 100 1028 1029 1030 1031 192.168.4.4 1032 123 1033 1034 quarantine 1035 pass 1036 fail 1037 1038 1039 1040 example.com 1041 1042 1043 1044 example.com 1045 pass 1046 abc123 1047 1048 1049 example.com> 1050 fail 1051 1052 1053 1054 1055 1056 1057 1058 1060 10. Normative References 1062 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 1063 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 1064 RFC 6376, DOI 10.17487/RFC6376, September 2011, 1065 . 1067 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 1068 Authorizing Use of Domains in Email, Version 1", RFC 7208, 1069 DOI 10.17487/RFC7208, April 2014, 1070 . 1072 Author's Address 1073 Alex Brotman 1074 Comcast, Inc. 1076 Email: alex_brotman@comcast.com