DMARC A. Brotman (ed) Internet-Draft Comcast, Inc. Obsoletes: 7489 (if approved) November 11, 2020 Intended status: Standards Track Expires: May 15, 2021 DMARC Aggregate Reporting draft-ietf-dmarc-aggregate-reporting-00 Abstract DMARC allows for domain holders to request aggregate reports from receivers. This report is an XML document, and contains extensible elements that allow for other types of data to be specified later. The aggregate reports can be submitted to the domain holder's specified destination as supported by the receiver. This document (along with others) obsoletes RFC7489. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 15, 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Brotman (ed) Expires May 15, 2021 [Page 1] Internet-Draft DMARC Aggregate Reporting November 2020 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 2. DMARC Feedback . . . . . . . . . . . . . . . . . . . . . . . 2 2.1. Verifying External Destinations . . . . . . . . . . . . . 3 2.2. Aggregate Reports . . . . . . . . . . . . . . . . . . . . 3 2.2.1. Transport . . . . . . . . . . . . . . . . . . . . . . 5 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. Appendix A. DMARC XML Schema . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Normative References . . . . . . . . . . . . . . . . . . 13 6.2. Informative References . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction A key component of DMARC is the ability for domain holders to request that receivers provide various types of reports. These reports allow domain holders to have insight into which IP addresses are sending on their behalf, and some insight into whether or not the volume may be legitimate. These reports expose information relating to the DMARC policy, as well as the outcome of SPF [RFC7208] & DKIM [RFC6376] validation. 1.1. Terminology The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119]. 2. DMARC Feedback Providing Domain Owners with visibility into how Mail Receivers implement and enforce the DMARC mechanism in the form of feedback is critical to establishing and maintaining accurate authentication deployments. When Domain Owners can see what effect their policies and practices are having, they are better willing and able to use quarantine and reject policies. Brotman (ed) Expires May 15, 2021 [Page 2] Internet-Draft DMARC Aggregate Reporting November 2020 2.1. Verifying External Destinations [] 2.2. Aggregate Reports The DMARC aggregate feedback report is designed to provide Domain Owners with precise insight into: o authentication results, o corrective action that needs to be taken by Domain Owners, and o the effect of Domain Owner DMARC policy on email streams processed by Mail Receivers. Aggregate DMARC feedback provides visibility into real-world email streams that Domain Owners need to make informed decisions regarding the publication of DMARC policy. When Domain Owners know what legitimate mail they are sending, what the authentication results are on that mail, and what forged mail receivers are getting, they can make better decisions about the policies they need and the steps they need to take to enable those policies. When Domain Owners set policies appropriately and understand their effects, Mail Receivers can act on them confidently. Visibility comes in the form of daily (or more frequent) Mail Receiver-originated feedback reports that contain aggregate data on message streams relevant to the Domain Owner. This information includes data about messages that passed DMARC authentication as well as those that did not. The format for these reports is defined in Appendix C. The report SHOULD include the following data: o The DMARC policy discovered and applied, if any o The selected message disposition o The identifier evaluated by SPF and the SPF result, if any o The identifier evaluated by DKIM and the DKIM result, if any o For both DKIM and SPF, an indication of whether the identifier was in alignment Brotman (ed) Expires May 15, 2021 [Page 3] Internet-Draft DMARC Aggregate Reporting November 2020 o Data for each Domain Owner's subdomain separately from mail from the sender's Organizational Domain, even if there is no explicit subdomain policy o Sending and receiving domains o The policy requested by the Domain Owner and the policy actually applied (if different) o The number of successful authentications o The counts of messages based on all messages received, even if their delivery is ultimately blocked by other filtering agents Note that Domain Owners or their agents may change the published DMARC policy for a domain or subdomain at any time. From a Mail Receiver's perspective, this will occur during a reporting period and may be noticed during that period, at the end of that period when reports are generated, or during a subsequent reporting period, all depending on the Mail Receiver's implementation. Under these conditions, it is possible that a Mail Receiver could do any of the following: o generate for such a reporting period a single aggregate report that includes message dispositions based on the old policy, or a mix of the two policies, even though the report only contains a single "policy_published" element; o generate multiple reports for the same period, one for each published policy occurring during the reporting period; o generate a report whose end time occurs when the updated policy was detected, regardless of any requested report interval. The report SHOULD include the following data: o The DMARC policy discovered and applied, if any o The selected message disposition o The identifier evaluated by SPF and the SPF result, if any o The identifier evaluated by DKIM and the DKIM result, if any o For both DKIM and SPF, an indication of whether the identifier was in alignment Brotman (ed) Expires May 15, 2021 [Page 4] Internet-Draft DMARC Aggregate Reporting November 2020 o Data for each Domain Owner's subdomain separately from mail from the sender's Organizational Domain, even if there is no explicit subdomain policy o Sending and receiving domains o The policy requested by the Domain Owner and the policy actually applied (if different) o The number of successful authentications o The counts of messages based on all messages received, even if their delivery is ultimately blocked by other filtering agents Note that Domain Owners or their agents may change the published DMARC policy for a domain or subdomain at any time. From a Mail Receiver's perspective, this will occur during a reporting period and may be noticed during that period, at the end of that period when reports are generated, or during a subsequent reporting period, all depending on the Mail Receiver's implementation. Under these conditions, it is possible that a Mail Receiver could do any of the following: o generate for such a reporting period a single aggregate report that includes message dispositions based on the old policy, or a mix of the two policies, even though the report only contains a single "policy_published" element; o generate multiple reports for the same period, one for each published policy occurring during the reporting period; o generate a report whose end time occurs when the updated policy was detected, regardless of any requested report interval. 2.2.1. Transport Where the URI specified in a "rua" tag does not specify otherwise, a Mail Receiver generating a feedback report SHOULD employ a secure transport mechanism. The Mail Receiver, after preparing a report, MUST evaluate the provided reporting URIs in the order given. Any reporting URI that includes a size limitation exceeded by the generated report (after compression and after any encoding required by the particular transport mechanism) MUST NOT be used. An attempt MUST be made to deliver an aggregate report to every remaining URI, up to the Receiver's limits on supported URIs. Brotman (ed) Expires May 15, 2021 [Page 5] Internet-Draft DMARC Aggregate Reporting November 2020 If transport is not possible because the services advertised by the published URIs are not able to accept reports (e.g., the URI refers to a service that is unreachable, or all provided URIs specify size limits exceeded by the generated record), the Mail Receiver SHOULD send a short report (see Section 7.2.2) indicating that a report is available but could not be sent. The Mail Receiver MAY cache that data and try again later, or MAY discard data that could not be sent. 2.2.1.1. Email The message generated by the Mail Receiver MUST be a [MAIL] message formatted per [MIME]. The aggregate report itself MUST be included in one of the parts of the message. A human-readable portion MAY be included as a MIME part (such as a text/plain part). The aggregate data MUST be an XML file that SHOULD be subjected to GZIP compression. Declining to apply compression can cause the report to be too large for a receiver to process (a commonly observed receiver limit is ten megabytes); doing the compression increases the chances of acceptance of the report at some compute cost. The aggregate data SHOULD be present using the media type "application/ gzip" if compressed (see [GZIP]), and "text/xml" otherwise. The filename is typically constructed using the following ABNF: filename = receiver "!" policy-domain "!" begin-timestamp "!" end-timestamp [ "!" unique-id ] "." extension unique-id = 1*(ALPHA / DIGIT) receiver = domain ; imported from [MAIL] policy-domain = domain begin-timestamp = 1*DIGIT ; seconds since 00:00:00 UTC January 1, 1970 ; indicating start of the time range contained ; in the report end-timestamp = 1*DIGIT ; seconds since 00:00:00 UTC January 1, 1970 ; indicating end of the time range contained ; in the report extension = "xml" / "xml.gz" The extension MUST be "xml" for a plain XML file, or "xml.gz" for an XML file compressed using GZIP. Brotman (ed) Expires May 15, 2021 [Page 6] Internet-Draft DMARC Aggregate Reporting November 2020 "unique-id" allows an optional unique ID generated by the Mail Receiver to distinguish among multiple reports generated simultaneously by different sources within the same Domain Owner. For example, this is a possible filename for the gzip file of a report to the Domain Owner "example.com" from the Mail Receiver "mail.receiver.example": mail.receiver.example!example.com!1013662812!1013749130.gz No specific MIME message structure is required. It is presumed that the aggregate reporting address will be equipped to extract MIME parts with the prescribed media type and filename and ignore the rest. Email streams carrying DMARC feedback data MUST conform to the DMARC mechanism, thereby resulting in an aligned "pass" (see Section 3.1). This practice minimizes the risk of report consumers processing fraudulent reports. The RFC5322.Subject field for individual report submissions SHOULD conform to the following ABNF: dmarc-subject = %x52.65.70.6f.72.74 1*FWS ; "Report" %x44.6f.6d.61.69.6e.3a 1*FWS ; "Domain:" domain-name 1*FWS ; from RFC 6376 %x53.75.62.6d.69.74.74.65.72.3a ; "Submitter:" 1*FWS domain-name 1*FWS %x52.65.70.6f.72.74.2d.49.44.3a ; "Report-ID:" msg-id ; from RFC 5322 The first domain-name indicates the DNS domain name about which the report was generated. The second domain-name indicates the DNS domain name representing the Mail Receiver generating the report. The purpose of the Report-ID: portion of the field is to enable the Domain Owner to identify and ignore duplicate reports that might be sent by a Mail Receiver. For instance, this is a possible Subject field for a report to the Domain Owner "example.com" from the Mail Receiver "mail.receiver.example". It is line-wrapped as allowed by [MAIL]: Subject: Report Domain: example.com Submitter: mail.receiver.example Report-ID: <2002.02.15.1> This transport mechanism potentially encounters a problem when feedback data size exceeds maximum allowable attachment sizes for Brotman (ed) Expires May 15, 2021 [Page 7] Internet-Draft DMARC Aggregate Reporting November 2020 either the generator or the consumer. See Section 7.2.2 for further discussion. 2.2.1.2. Other Methods The specification as written allows for the addition of other registered URI schemes to be supported in later versions. 3. Security Considerations TBD 4. IANA Considerations TBD 5. Appendix A. DMARC XML Schema Brotman (ed) Expires May 15, 2021 [Page 8] Internet-Draft DMARC Aggregate Reporting November 2020 Brotman (ed) Expires May 15, 2021 [Page 9] Internet-Draft DMARC Aggregate Reporting November 2020 Brotman (ed) Expires May 15, 2021 [Page 10] Internet-Draft DMARC Aggregate Reporting November 2020 Brotman (ed) Expires May 15, 2021 [Page 11] Internet-Draft DMARC Aggregate Reporting November 2020 6. References 6.1. Normative References Brotman (ed) Expires May 15, 2021 [Page 13] Internet-Draft DMARC Aggregate Reporting November 2020 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, . [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, . 6.2. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Author's Address Alex Brotman Comcast, Inc. Email: alex_brotman@comcast.com Brotman (ed) Expires May 15, 2021 [Page 14]