idnits 2.17.1 draft-ietf-dmarc-aggregate-reporting-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (21 February 2021) is 1160 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: 'URI' is mentioned on line 117, but not defined == Missing Reference: 'MAIL' is mentioned on line 453, but not defined == Missing Reference: 'MIME' is mentioned on line 375, but not defined == Missing Reference: 'GZIP' is mentioned on line 385, but not defined == Missing Reference: '0-9' is mentioned on line 702, but not defined == Missing Reference: '0-4' is mentioned on line 702, but not defined == Missing Reference: '0-5' is mentioned on line 702, but not defined Summary: 0 errors (**), 0 flaws (~~), 9 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) 21 February 2021 5 Intended status: Standards Track 6 Expires: 25 August 2021 8 DMARC Aggregate Reporting 9 draft-ietf-dmarc-aggregate-reporting-01 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 25 August 2021. 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 . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. DMARC Feedback . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Verifying External Destinations . . . . . . . . . . . . . 3 58 2.2. Aggregate Reports . . . . . . . . . . . . . . . . . . . . 5 59 2.3. Extensions . . . . . . . . . . . . . . . . . . . . . . . 7 60 2.3.1. Transport . . . . . . . . . . . . . . . . . . . . . . 8 61 3. Extensible Reporting . . . . . . . . . . . . . . . . . . . . 11 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 63 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11 64 5.1. Data Exposure Considerations . . . . . . . . . . . . . . 11 65 5.2. Report Recipients . . . . . . . . . . . . . . . . . . . . 12 66 5.3. Data Contained Within Reports (Tkt64) . . . . . . . . . . 12 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 68 7. Appendix A. DMARC XML Schema . . . . . . . . . . . . . . . . 13 69 8. Appendix B. Sample Report . . . . . . . . . . . . . . . . . 18 70 9. Normative References . . . . . . . . . . . . . . . . . . . . 19 71 10. Informative References . . . . . . . . . . . . . . . . . . . 20 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 74 1. Introduction 76 A key component of DMARC is the ability for domain holders to request 77 that receivers provide various types of reports. These reports allow 78 domain holders to have insight into which IP addresses are sending on 79 their behalf, and some insight into whether or not the volume may be 80 legitimate. These reports expose information relating to the DMARC 81 policy, as well as the outcome of SPF [RFC7208] & DKIM [RFC6376] 82 validation. 84 1.1. Terminology 86 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 87 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 88 document, are to be interpreted as described in [RFC2119]. 90 2. DMARC Feedback 92 Providing Domain Owners with visibility into how Mail Receivers 93 implement and enforce the DMARC mechanism in the form of feedback is 94 critical to establishing and maintaining accurate authentication 95 deployments. When Domain Owners can see what effect their policies 96 and practices are having, they are better willing and able to use 97 quarantine and reject policies. 99 2.1. Verifying External Destinations 101 It is possible to specify destinations for the different reports that 102 are outside the authority of the Domain Owner making the request. 103 This allows domains that do not operate mail servers to request 104 reports and have them go someplace that is able to receive and 105 process them. 107 Without checks, this would allow a bad actor to publish a DMARC 108 policy record that requests that reports be sent to a victim address, 109 and then send a large volume of mail that will fail both DKIM and SPF 110 checks to a wide variety of destinations; the victim will in turn be 111 flooded with unwanted reports. Therefore, a verification mechanism 112 is included. 114 When a Mail Receiver discovers a DMARC policy in the DNS, and the 115 Organizational Domain at which that record was discovered is not 116 identical to the Organizational Domain of the host part of the 117 authority component of a [URI] specified in the "rua" or "ruf" tag, 118 the following verification steps are to be taken: 120 1. Extract the host portion of the authority component of the URI. 121 Call this the "destination host", as it refers to a Report 122 Receiver. 124 2. Prepend the string "_report._dmarc". 126 3. Prepend the domain name from which the policy was retrieved, 127 after conversion to an A-label if needed. 129 4. Query the DNS for a TXT record at the constructed name. If the 130 result of this request is a temporary DNS error of some kind 131 (e.g., a timeout), the Mail Receiver MAY elect to temporarily 132 fail the delivery so the verification test can be repeated later. 134 5. For each record returned, parse the result as a series of 135 "tag=value" pairs, i.e., the same overall format as the policy 136 record (see Section 6.4). In particular, the "v=DMARC1" tag is 137 mandatory and MUST appear first in the list. Discard any that do 138 not pass this test. 140 6. If the result includes no TXT resource records that pass basic 141 parsing, a positive determination of the external reporting 142 relationship cannot be made; stop. 144 7. If at least one TXT resource record remains in the set after 145 parsing, then the external reporting arrangement was authorized 146 by the Report Receiver. 148 8. If a "rua" or "ruf" tag is thus discovered, replace the 149 corresponding value extracted from the domain's DMARC policy 150 record with the one found in this record. This permits the 151 Report Receiver to override the report destination. However, to 152 prevent loops or indirect abuse, the overriding URI MUST use the 153 same destination host from the first step. 155 For example, if a DMARC policy query for "blue.example.com" contained 156 "rua=mailto:reports@red.example.net", the host extracted from the 157 latter ("red.example.net") does not match "blue.example.com", so this 158 procedure is enacted. A TXT query for 159 "blue.example.com._report._dmarc.red.example.net" is issued. If a 160 single reply comes back containing a tag of "v=DMARC1", then the 161 relationship between the two is confirmed. Moreover, 162 "red.example.net" has the opportunity to override the report 163 destination requested by "blue.example.com" if needed. 165 Where the above algorithm fails to confirm that the external 166 reporting was authorized by the Report Receiver, the URI MUST be 167 ignored by the Mail Receiver generating the report. Further, if the 168 confirming record includes a URI whose host is again different than 169 the domain publishing that override, the Mail Receiver generating the 170 report MUST NOT generate a report to either the original or the 171 override URI. A Report Receiver publishes such a record in its DNS 172 if it wishes to receive reports for other domains. 174 A Report Receiver that is willing to receive reports for any domain 175 can use a wildcard DNS record. For example, a TXT resource record at 176 "*._report._dmarc.example.com" containing at least "v=DMARC1" 177 confirms that example.com is willing to receive DMARC reports for any 178 domain. 180 If the Report Receiver is overcome by volume, it can simply remove 181 the confirming DNS record. However, due to positive caching, the 182 change could take as long as the time-to-live (TTL) on the record to 183 go into effect. 185 A Mail Receiver might decide not to enact this procedure if, for 186 example, it relies on a local list of domains for which external 187 reporting addresses are permitted. 189 2.2. Aggregate Reports 191 The DMARC aggregate feedback report is designed to provide Domain 192 Owners with precise insight into: 194 * authentication results, 196 * corrective action that needs to be taken by Domain Owners, and 198 * the effect of Domain Owner DMARC policy on email streams processed 199 by Mail Receivers. 201 Aggregate DMARC feedback provides visibility into real-world email 202 streams that Domain Owners need to make informed decisions regarding 203 the publication of DMARC policy. When Domain Owners know what 204 legitimate mail they are sending, what the authentication results are 205 on that mail, and what forged mail receivers are getting, they can 206 make better decisions about the policies they need and the steps they 207 need to take to enable those policies. When Domain Owners set 208 policies appropriately and understand their effects, Mail Receivers 209 can act on them confidently. 211 Visibility comes in the form of daily (or more frequent) Mail 212 Receiver-originated feedback reports that contain aggregate data on 213 message streams relevant to the Domain Owner. This information 214 includes data about messages that passed DMARC authentication as well 215 as those that did not. 217 The format for these reports is defined in Appendix A. 219 The report SHOULD include the following data: 221 * The DMARC policy discovered and applied, if any 223 * The selected message disposition 225 * The identifier evaluated by SPF and the SPF result, if any 227 * The identifier evaluated by DKIM and the DKIM result, if any 228 * For both DKIM and SPF, an indication of whether the identifier was 229 in alignment 231 * A separate report should be generated for each 5322.From 232 subdomain, regardless of which policy domain was used during 233 receipt of messages 235 * Sending and receiving domains 237 * The policy requested by the Domain Owner and the policy actually 238 applied (if different) 240 * The number of successful authentications 242 * The counts of messages based on all messages received, even if 243 their delivery is ultimately blocked by other filtering agents 245 ProposedAddition: [[ 247 DMARC Aggregate Reports MUST contain two primary sections; one 248 consisting of descriptive information and the other a set of IP- 249 focused row-based data. Each report MUST contain data for only one 250 Author Domain. A single report SHOULD contain data for one policy 251 configuration. If multiple configurations were observed during a 252 single reporting period, a reporting entity MAY choose to send 253 multiple reports, otherwise the reporting entity SHOULD note only the 254 final configuration observed during the period. See below for 255 further information. 257 The informative section MUST contain two sub-sections. One will be 258 the metadata section which MUST contain the fields related to 259 "org_name", "email", "report_id", and "date_range". Optional fields 260 MAY include "extra_contact_info" and an "error" field. The 261 "date_range" section which will note "begin" and "end" values as 262 epoch timestamps. The other sub-section will be the 263 "policy_published", and record the policy configuration observed by 264 the receiving system. Mandatory fields are "domain", "p", "sp", 265 "pct". Optional fields are "fo", "adkim", "aspf". 267 Within the data section, the report will contain row(s) of data 268 stating which IPs were seen to have delivered messages for the Author 269 Domain to the receiving system. For each IP that is being reported, 270 there will be a "record" element, which will then have each of a 271 "row", "identifiers", and "auth_results" sub-element. Within the 272 "row" element, there MUST be "source_ip" and "count". There MUST 273 also exist a "policy_evaluated", with subelements of "disposition", 274 "dkim", and "spf". There MAY be an element for "reason", meant to 275 include any notes the reporter might want to include as to why the 276 "disposition" policy does not match the "policy_published", such as a 277 Local Policy override (possible values listed in Appendex A). The 278 "dkim" and "spf" elements MUST be the evaluated values as they relate 279 to DMARC, not the values the receiver may have used when overriding 280 the policy. Within the "identifiers" element, there MUST exist the 281 data that was used to apply policy for the given IP. In most cases, 282 this will be a "header_from" element, which will contain the 283 5322.From domain from the message. 285 There MUST be an "auth_results" element within the 'record' element. 286 This will contain the data related to authenticating the messages 287 associated with this sending IP. The "dkim" subelement is optional 288 as not all messages are signed, while there MUST be at least one 289 "spf" subelement. These elements MUST have a "domain" that was used 290 during validation, as well as "result". Optionally, the "dkim" 291 element MAY include a "selector" element that was observed during 292 validation. For the "spf" element, the "result" element MUST contain 293 a lower-case string where the value is one of 294 none/neutral/pass/fail/softfail/temperror/permerror. The "dkim" 295 result MUST contain a lower-case string where the value is one of 296 none/pass/fail/policy/neutral/temperror/permerror. 298 2.3. Extensions 300 There MAY be an optional section for extensions within the "feedback" 301 element. The absence or existence of this section SHOULD NOT create 302 an error when processing reports. This will be covered in a separate 303 section. 305 ]] 307 Note that Domain Owners or their agents may change the published 308 DMARC policy for a domain or subdomain at any time. From a Mail 309 Receiver's perspective, this will occur during a reporting period and 310 may be noticed during that period, at the end of that period when 311 reports are generated, or during a subsequent reporting period, all 312 depending on the Mail Receiver's implementation. Under these 313 conditions, it is possible that a Mail Receiver could do any of the 314 following: 316 * generate for such a reporting period a single aggregate report 317 that includes message dispositions based on the old policy, or a 318 mix of the two policies, even though the report only contains a 319 single "policy_published" element; 321 * generate multiple reports for the same period, one for each 322 published policy occurring during the reporting period; 324 * generate a report whose end time occurs when the updated policy 325 was detected, regardless of any requested report interval. 327 Such policy changes are expected to be infrequent for any given 328 domain, whereas more stringent policy monitoring requirements on the 329 Mail Receiver would produce a very large burden at Internet scale. 330 Therefore, it is the responsibility of report consumers and Domain 331 Owners to be aware of this situation and allow for such mixed reports 332 during the propagation of the new policy to Mail Receivers. 334 Aggregate reports are most useful when they all cover a common time 335 period. By contrast, correlation of these reports from multiple 336 generators when they cover incongruent time periods is difficult or 337 impossible. Report generators SHOULD, wherever possible, adhere to 338 hour boundaries for the reporting period they are using. For 339 example, starting a per-day report at 00:00; starting per-hour 340 reports at 00:00, 01:00, 02:00; etc. Report generators using a 341 24-hour report period are strongly encouraged to begin that period at 342 00:00 UTC, regardless of local timezone or time of report production, 343 in order to facilitate correlation. 345 A Mail Receiver discovers reporting requests when it looks up a DMARC 346 policy record that corresponds to an RFC5322.From domain on received 347 mail. The presence of the "rua" tag specifies where to send 348 feedback. 350 2.3.1. Transport 352 Where the URI specified in a "rua" tag does not specify otherwise, a 353 Mail Receiver generating a feedback report SHOULD employ a secure 354 transport mechanism. 356 The Mail Receiver, after preparing a report, MUST evaluate the 357 provided reporting URIs in the order given. Any reporting URI that 358 includes a size limitation exceeded by the generated report (after 359 compression and after any encoding required by the particular 360 transport mechanism) MUST NOT be used. An attempt MUST be made to 361 deliver an aggregate report to every remaining URI, up to the 362 Receiver's limits on supported URIs. 364 If transport is not possible because the services advertised by the 365 published URIs are not able to accept reports (e.g., the URI refers 366 to a service that is unreachable, or all provided URIs specify size 367 limits exceeded by the generated record), the Mail Receiver SHOULD 368 send a short report (see Section 7.2.2) indicating that a report is 369 available but could not be sent. The Mail Receiver MAY cache that 370 data and try again later, or MAY discard data that could not be sent. 372 2.3.1.1. Email 374 The message generated by the Mail Receiver MUST be a [MAIL] message 375 formatted per [MIME]. The aggregate report itself MUST be included 376 in one of the parts of the message. A human-readable portion MAY be 377 included as a MIME part (such as a text/plain part). 379 The aggregate data MUST be an XML file that SHOULD be subjected to 380 GZIP compression. Declining to apply compression can cause the 381 report to be too large for a receiver to process (a commonly observed 382 receiver limit is ten megabytes); doing the compression increases the 383 chances of acceptance of the report at some compute cost. The 384 aggregate data SHOULD be present using the media type "application/ 385 gzip" if compressed (see [GZIP]), and "text/xml" otherwise. The 386 filename is typically constructed using the following ABNF: 388 filename = receiver "!" policy-domain "!" begin-timestamp 389 "!" end-timestamp [ "!" unique-id ] "." extension 391 unique-id = 1*(ALPHA / DIGIT) 393 receiver = domain 394 ; imported from [MAIL] 396 policy-domain = domain 398 begin-timestamp = 1*DIGIT 399 ; seconds since 00:00:00 UTC January 1, 1970 400 ; indicating start of the time range contained 401 ; in the report 403 end-timestamp = 1*DIGIT 404 ; seconds since 00:00:00 UTC January 1, 1970 405 ; indicating end of the time range contained 406 ; in the report 408 extension = "xml" / "xml.gz" 410 The extension MUST be "xml" for a plain XML file, or "xml.gz" for an 411 XML file compressed using GZIP. 413 "unique-id" allows an optional unique ID generated by the Mail 414 Receiver to distinguish among multiple reports generated 415 simultaneously by different sources within the same Domain Owner. 417 For example, this is a possible filename for the gzip file of a 418 report to the Domain Owner "example.com" from the Mail Receiver 419 "mail.receiver.example": 421 mail.receiver.example!example.com!1013662812!1013749130.gz 423 No specific MIME message structure is required. It is presumed that 424 the aggregate reporting address will be equipped to extract MIME 425 parts with the prescribed media type and filename and ignore the 426 rest. 428 Email streams carrying DMARC feedback data MUST conform to the DMARC 429 mechanism, thereby resulting in an aligned "pass" (see Section 3.1). 430 This practice minimizes the risk of report consumers processing 431 fraudulent reports. 433 The RFC5322.Subject field for individual report submissions SHOULD 434 conform to the following ABNF: 436 dmarc-subject = %x52.65.70.6f.72.74 1*FWS ; "Report" 437 %x44.6f.6d.61.69.6e.3a 1*FWS ; "Domain:" 438 domain-name 1*FWS ; from RFC 6376 439 %x53.75.62.6d.69.74.74.65.72.3a ; "Submitter:" 440 1*FWS domain-name 1*FWS 441 %x52.65.70.6f.72.74.2d.49.44.3a ; "Report-ID:" 442 msg-id ; from RFC 5322 444 The first domain-name indicates the DNS domain name about which the 445 report was generated. The second domain-name indicates the DNS 446 domain name representing the Mail Receiver generating the report. 447 The purpose of the Report-ID: portion of the field is to enable the 448 Domain Owner to identify and ignore duplicate reports that might be 449 sent by a Mail Receiver. 451 For instance, this is a possible Subject field for a report to the 452 Domain Owner "example.com" from the Mail Receiver 453 "mail.receiver.example". It is line-wrapped as allowed by [MAIL]: 455 Subject: Report Domain: example.com 456 Submitter: mail.receiver.example 457 Report-ID: <2002.02.15.1> 459 This transport mechanism potentially encounters a problem when 460 feedback data size exceeds maximum allowable attachment sizes for 461 either the generator or the consumer. See Section 7.2.2 for further 462 discussion. 464 2.3.1.2. Other Methods 466 The specification as written allows for the addition of other 467 registered URI schemes to be supported in later versions. 469 3. Extensible Reporting 471 A DMARC report should allow for some extensibility, as defined by 472 future documents that utilize DMARC as a foundation. These 473 extensions MUST be properly formatted XML and meant to exist within 474 the structure of a DMARC report. They MUST NOT alter the existing 475 DMARC structure, but instead exist self-contained within an 476 "" element. This element MUST be a child of the 477 "" element. 479 480 ... 481 482 483 ... 484 485 486 488 A DMARC report receiver SHOULD NOT generate a processing error when 489 this "" element is absent or empty. Furthermore, if a 490 processor is unable to handle an extension in a report, it SHOULD 491 ignore the data, and continue to the next extension. 493 4. IANA Considerations 495 TBD 497 5. Privacy Considerations 499 This section will discuss exposure related to DMARC aggregate 500 reporting. 502 5.1. Data Exposure Considerations 504 Aggregate reports are limited in scope to DMARC policy and 505 disposition results, to information pertaining to the underlying 506 authentication mechanisms, and to the identifiers involved in DMARC 507 validation. 509 Aggregate report may expose sender and recipient identifiers, 510 specifically the RFC5322.From addresses. 512 Domain Owners requesting reports will receive information about mail 513 claiming to be from them, which includes mail that was not, in fact, 514 from them. Information about the final destination of mail where it 515 might otherwise be obscured by intermediate systems will therefore be 516 exposed. 518 When message-forwarding arrangements exist, Domain Owners requesting 519 reports will also receive information about mail forwarded to domains 520 that were not originally part of their messages' recipient lists. 521 This means that destination domains previously unknown to the Domain 522 Owner may now become visible. 524 Disclosure of information about the messages is being requested by 525 the entity generating the email in the first place, i.e., the Domain 526 Owner and not the Mail Receiver, so this may not fit squarely within 527 existing privacy policy provisions. For some providers, aggregate 528 reporting is viewed as a function similar to complaint reporting 529 about spamming or phishing and are treated similarly under the 530 privacy policy. Report generators (i.e., Mail Receivers) are 531 encouraged to review their reporting limitations under such policies 532 before enabling DMARC reporting. 534 5.2. Report Recipients 536 A DMARC record can specify that reports should be sent to an 537 intermediary operating on behalf of the Domain Owner. This is done 538 when the Domain Owner contracts with an entity to monitor mail 539 streams for abuse and performance issues. Receipt by third parties 540 of such data may or may not be permitted by the Mail Receiver's 541 privacy policy, terms of use, or other similar governing document. 542 Domain Owners and Mail Receivers should both review and understand if 543 their own internal policies constrain the use and transmission of 544 DMARC reporting. 546 Some potential exists for report recipients to perform traffic 547 analysis, making it possible to obtain metadata about the Receiver's 548 traffic. In addition to verifying compliance with policies, 549 Receivers need to consider that before sending reports to a third 550 party. 552 5.3. Data Contained Within Reports (Tkt64) 554 Aggregate feedback reports contain aggregated data relating to 555 messages purportedly originating from the Domain Owner. The data 556 does not contain any identifying characteristics about individual 557 users. No personal information such as individual email addresses, 558 IP addresses of individuals, or the content of any messages, is 559 included in reports. 561 Mail Receivers should have no concerns in sending reports as they do 562 not contain personal information. In all cases, the data within the 563 reports relates to the domain-level authentication information 564 provided by mail servers sending messages on behalf of the Domain 565 Owner. This information is necessary to assist Domain Owners in 566 implementing and maintaining DMARC. 568 Domain Owners should have no concerns in receiving reports as they do 569 not contain personal information. The reports only contain 570 aggregated data related to the domain-level authentication details of 571 messages claiming to originate from their domain. This information 572 is essential for the proper implementation and operation of DMARC. 573 Domain Owners who are unable to receive reports for organizational 574 reasons, can choose to exclusively direct the reports to an external 575 processor. 577 6. Security Considerations 579 TBD 581 7. Appendix A. DMARC XML Schema 583 584 587 589 590 591 592 593 594 596 597 598 599 600 601 603 604 605 607 608 609 610 611 612 613 614 615 617 619 620 621 622 623 624 625 627 629 630 631 632 633 634 636 637 639 640 641 642 643 644 645 646 647 648 650 651 652 653 654 655 656 657 659 660 661 662 663 664 665 666 667 668 670 673 674 675 676 678 679 681 683 684 685 686 687 688 690 691 693 696 699 700 701 704 706 708 709 710 711 712 713 714 716 719 720 722 723 724 725 727 728 730 731 733 734 736 738 739 740 741 742 743 744 745 746 747 748 750 751 752 753 755 756 758 759 761 763 765 766 768 769 770 771 772 773 774 776 777 778 779 780 781 782 783 784 785 786 787 788 789 791 792 793 794 795 796 797 798 800 801 802 804 805 806 808 810 811 813 814 816 819 820 821 822 823 824 825 827 828 829 830 831 833 835 837 839 840 841 842 844 8. Appendix B. Sample Report 845 846 847 Sample Reporter 848 report_sender@example-reporter.com 849 ... 850 3v98abbp8ya9n3va8yr8oa3ya 851 852 161212415 853 161221511 854 855 856 857 example.com 858

quarantine

859 none 860 100 861 862 863 864 192.168.4.4 865 123 866 867 quarantine 868 pass 869 fail 870 871 872 873 example.com 874 875 876 877 example.com 878 pass 879 abc123 880 881 882 example.com> 883 fail 884 885 886 887 889 9. Normative References 891 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 892 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 893 RFC 6376, DOI 10.17487/RFC6376, September 2011, 894 . 896 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 897 Authorizing Use of Domains in Email, Version 1", RFC 7208, 898 DOI 10.17487/RFC7208, April 2014, 899 . 901 10. Informative References 903 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 904 Requirement Levels", BCP 14, RFC 2119, 905 DOI 10.17487/RFC2119, March 1997, 906 . 908 Author's Address 910 Alex Brotman 911 Comcast, Inc. 913 Email: alex_brotman@comcast.com