From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8460.txt | 1907 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1907 insertions(+) create mode 100644 doc/rfc/rfc8460.txt (limited to 'doc/rfc/rfc8460.txt') diff --git a/doc/rfc/rfc8460.txt b/doc/rfc/rfc8460.txt new file mode 100644 index 0000000..be3bc46 --- /dev/null +++ b/doc/rfc/rfc8460.txt @@ -0,0 +1,1907 @@ + + + + + + +Internet Engineering Task Force (IETF) D. Margolis +Request for Comments: 8460 Google, Inc. +Category: Standards Track A. Brotman +ISSN: 2070-1721 Comcast, Inc. + B. Ramakrishnan + Oath, Inc. + J. Jones + Microsoft, Inc. + M. Risher + Google, Inc. + September 2018 + + + SMTP TLS Reporting + +Abstract + + A number of protocols exist for establishing encrypted channels + between SMTP Mail Transfer Agents (MTAs), including STARTTLS, DNS- + Based Authentication of Named Entities (DANE) TLSA, and MTA Strict + Transport Security (MTA-STS). These protocols can fail due to + misconfiguration or active attack, leading to undelivered messages or + delivery over unencrypted or unauthenticated channels. This document + describes a reporting mechanism and format by which sending systems + can share statistics and specific information about potential + failures with recipient domains. Recipient domains can then use this + information to both detect potential attacks and diagnose + unintentional misconfigurations. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8460. + + + + + + + + + +Margolis, et al. Standards Track [Page 1] + +RFC 8460 SMTP TLS Reporting September 2018 + + +Copyright Notice + + Copyright (c) 2018 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 + 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Margolis, et al. Standards Track [Page 2] + +RFC 8460 SMTP TLS Reporting September 2018 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Related Technologies . . . . . . . . . . . . . . . . . . . . 5 + 3. Reporting Policy . . . . . . . . . . . . . . . . . . . . . . 6 + 3.1. Example Reporting Policy . . . . . . . . . . . . . . . . 8 + 3.1.1. Report Using MAILTO . . . . . . . . . . . . . . . . . 8 + 3.1.2. Report Using HTTPS . . . . . . . . . . . . . . . . . 8 + 4. Reporting Schema . . . . . . . . . . . . . . . . . . . . . . 8 + 4.1. Report Time Frame . . . . . . . . . . . . . . . . . . . . 9 + 4.2. Delivery Summary . . . . . . . . . . . . . . . . . . . . 10 + 4.2.1. Success Count . . . . . . . . . . . . . . . . . . . . 10 + 4.2.2. Failure Count . . . . . . . . . . . . . . . . . . . . 10 + 4.3. Result Types . . . . . . . . . . . . . . . . . . . . . . 10 + 4.3.1. Negotiation Failures . . . . . . . . . . . . . . . . 10 + 4.3.2. Policy Failures . . . . . . . . . . . . . . . . . . . 11 + 4.3.3. General Failures . . . . . . . . . . . . . . . . . . 11 + 4.3.4. Transient Failures . . . . . . . . . . . . . . . . . 12 + 4.4. JSON Report Schema . . . . . . . . . . . . . . . . . . . 12 + 4.5. Policy Samples . . . . . . . . . . . . . . . . . . . . . 15 + 5. Report Delivery . . . . . . . . . . . . . . . . . . . . . . . 15 + 5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 16 + 5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 17 + 5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 17 + 5.3.1. Example Report . . . . . . . . . . . . . . . . . . . 19 + 5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 19 + 5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 20 + 5.6. Metadata Variances . . . . . . . . . . . . . . . . . . . 20 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 + 6.1. Message Headers . . . . . . . . . . . . . . . . . . . . . 20 + 6.2. Report Type . . . . . . . . . . . . . . . . . . . . . . . 21 + 6.3. +gzip Media Type Suffix . . . . . . . . . . . . . . . . . 22 + 6.4. application/tlsrpt+json Media Type . . . . . . . . . . . 23 + 6.5. application/tlsrpt+gzip Media Type . . . . . . . . . . . 24 + 6.6. STARTTLS Validation Result Types . . . . . . . . . . . . 25 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 + 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 28 + 9.2. Informative References . . . . . . . . . . . . . . . . . 30 + Appendix A. Example Reporting Policy . . . . . . . . . . . . . . 32 + A.1. Report Using MAILTO . . . . . . . . . . . . . . . . . . . 32 + A.2. Report Using HTTPS . . . . . . . . . . . . . . . . . . . 32 + Appendix B. Example JSON Report . . . . . . . . . . . . . . . . 32 + Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 34 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 + + + + +Margolis, et al. Standards Track [Page 3] + +RFC 8460 SMTP TLS Reporting September 2018 + + +1. Introduction + + The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and + hosts to establish secure SMTP sessions over TLS. The protocol + design uses an approach that has come to be known as "Opportunistic + Security" (OS) [RFC7435]. This method maintains interoperability + with clients that do not support STARTTLS, but it means that any + attacker could potentially eavesdrop on a session. An attacker could + perform a downgrade or interception attack by deleting parts of the + SMTP session (such as the "250 STARTTLS" response) or redirect the + entire SMTP session (perhaps by overwriting the resolved MX record of + the delivery domain). + + Because such "downgrade attacks" are not necessarily apparent to the + receiving MTA, this document defines a mechanism for sending domains + to report on failures at multiple stages of the MTA-to-MTA + conversation. + + Recipient domains may also use the mechanisms defined by MTA-STS + [RFC8461] or DANE [RFC6698] to publish additional encryption and + authentication requirements; this document defines a mechanism for + sending domains that are compatible with MTA-STS or DANE to share + success and failure statistics with recipient domains. + + Specifically, this document defines a reporting schema that covers + failures in routing, DNS resolution, and STARTTLS negotiation; policy + validation errors for both DANE [RFC6698] and MTA-STS [RFC8461]; and + a standard TXT record that recipient domains can use to indicate + where reports in this format should be sent. The report can also + serve as a heartbeat to indicate that systems are successfully + negotiating TLS during sessions as expected. + + This document is intended as a companion to the specification for + SMTP MTA-STS [RFC8461] and adds reporting abilities for those + implementing DANE [RFC7672]. + +1.1. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + + + + + + + + +Margolis, et al. Standards Track [Page 4] + +RFC 8460 SMTP TLS Reporting September 2018 + + + We also define the following terms for further use in this document: + + o MTA-STS Policy: A mechanism by which administrators can specify + the expected TLS availability, presented identity, and desired + actions for a given email recipient domain. MTA-STS is defined in + [RFC8461]. + + o DANE Policy: A mechanism by which administrators can use DNSSEC to + commit an MTA to support STARTTLS and to publish criteria to be + used to validate its presented certificates. DANE for SMTP is + defined in [RFC7672], with the base specification defined in + [RFC6698] (and updated by [RFC7671]). + + o TLSRPT (TLS Reporting) Policy: A policy specifying the endpoint to + which Sending MTAs should deliver reports. + + o Policy Domain: The domain against which a TLSRPT, an MTA-STS, or a + DANE policy is defined. For TLSRPT and MTA-STS, this is typically + the same as the envelope recipient domain [RFC5321], but when mail + is routed to a "smarthost" gateway by local policy, the + "smarthost" domain name is used instead. For DANE, the Policy + Domain is the "TLSA base domain" of the receiving SMTP server as + described in Section 2.2.3 of RFC 7672 and Section 3 of RFC 6698. + + o Sending MTA: The MTA initiating the relay of an email message. + + o Aggregate Report URI (rua): A comma-separated list of locations + where the report is to be submitted. + + o ABNF: Augmented Backus-Naur Form, a syntax for formally specifying + syntax, defined in [RFC5234] and [RFC7405]. + +2. Related Technologies + + o This document is intended as a companion to the specification for + SMTP MTA-STS [RFC8461]. + + o SMTP TLSRPT defines a mechanism for sending domains that are + compatible with MTA-STS or DANE to share success and failure + statistics with recipient domains. DANE is defined in [RFC6698], + and MTA-STS is defined in [RFC8461]. + + + + + + + + + + +Margolis, et al. Standards Track [Page 5] + +RFC 8460 SMTP TLS Reporting September 2018 + + +3. Reporting Policy + + A domain publishes a record to its DNS indicating that it wishes to + receive reports. These SMTP TLSRPT policies are distributed via DNS + from the Policy Domain's zone as TXT records (similar to Domain-based + Message Authentication, Reporting, and Conformance (DMARC) policies) + under the name "_smtp._tls". For example, for the Policy Domain + "example.com", the recipient's TLSRPT policy can be retrieved from + "_smtp._tls.example.com". + + Policies consist of the following directives: + + o "v": This document defines version 1 of TLSRPT, for which this + value MUST be equal to "TLSRPTv1". Other versions may be defined + in later documents. + + o "rua": A URI specifying the endpoint to which aggregate + information about policy validation results should be sent (see + Section 4, "Reporting Schema", for more information). Two URI + schemes are supported: "mailto" and "https". As with DMARC + [RFC7489], the Policy Domain can specify a comma-separated list of + URIs. + + o In the case of "https", reports should be submitted via POST + [RFC7231] to the specified URI. Report submitters MAY ignore + certificate validation errors when submitting reports via HTTPS + POST. + + o In the case of "mailto", reports should be submitted to the + specified email address [RFC6068]. When sending failure reports + via SMTP, Sending MTAs MUST deliver reports despite any TLS- + related failures and SHOULD NOT include this SMTP session in the + next report. This may mean that the reports are delivered + unencrypted. Reports sent via SMTP MUST contain a valid + DomainKeys Identified Mail (DKIM) [RFC6376] signature by the + reporting domain. Reports lacking such a signature MUST be + ignored by the recipient. DKIM signatures MUST NOT use the "l=" + attribute to limit the body length used in the signature. This + ensures attackers cannot append extraneous or misleading data to a + report without breaking the signature. The DKIM TXT record SHOULD + contain the appropriate service type declaration, "s=tlsrpt". If + not present, the receiving system MAY ignore reports lacking that + service type. + + Sample DKIM record: + + dkim_selector._domainkey.example.com TXT + "v=DKIM1;k=rsa;s=tlsrpt;p=Mlf4qwSZfase4fa==" + + + +Margolis, et al. Standards Track [Page 6] + +RFC 8460 SMTP TLS Reporting September 2018 + + + The formal definition of the "_smtp._tls" TXT record, defined using + [RFC5234] and [RFC7405], is as follows: + + tlsrpt-record = tlsrpt-version 1*(field-delim tlsrpt-field) + [field-delim] + + field-delim = *WSP ";" *WSP + + tlsrpt-field = tlsrpt-rua / ; Note that the + tlsrpt-extension ; tlsrpt-rua record is + ; required. + + tlsrpt-version = %s"v=TLSRPTv1" + + tlsrpt-rua = %s"rua=" + tlsrpt-uri *(*WSP "," *WSP tlsrpt-uri) + + tlsrpt-uri = URI + ; "URI" is imported from [RFC3986]; + ; commas (ASCII 0x2C), exclamation + ; points (ASCII 0x21), and semicolons + ; (ASCII 0x3B) MUST be encoded + + tlsrpt-extension = tlsrpt-ext-name "=" tlsrpt-ext-value + + tlsrpt-ext-name = (ALPHA / DIGIT) *31(ALPHA / + DIGIT / "_" / "-" / ".") + + tlsrpt-ext-value = 1*(%x21-3A / %x3C / %x3E-7E) + ; chars excluding "=", ";", SP, and control + ; chars + + If multiple TXT records for "_smtp._tls" are returned by the + resolver, records that do not begin with "v=TLSRPTv1;" are discarded. + If the number of resulting records is not one, senders MUST assume + the recipient domain does not implement TLSRPT. If the resulting TXT + record contains multiple strings (as described in Section 3.3 of + [RFC7208]), then the record MUST be treated as if those strings are + concatenated without adding spaces. + + The record supports the ability to declare more than one rua, and if + there exists more than one, the reporter MAY attempt to deliver to + each of the supported rua destinations. A receiver MAY opt to only + attempt delivery to one of the endpoints; however, the report SHOULD + NOT be considered successfully delivered until one of the endpoints + accepts delivery of the report. + + + + + +Margolis, et al. Standards Track [Page 7] + +RFC 8460 SMTP TLS Reporting September 2018 + + + Parsers MUST accept TXT records that are syntactically valid (i.e., + valid key/value pairs separated by semicolons) and implement a + superset of this specification, in which case unknown fields SHALL be + ignored. + +3.1. Example Reporting Policy + +3.1.1. Report Using MAILTO + + _smtp._tls.example.com. IN TXT \ + "v=TLSRPTv1;rua=mailto:reports@example.com" + +3.1.2. Report Using HTTPS + + _smtp._tls.example.com. IN TXT \ + "v=TLSRPTv1; \ + rua=https://reporting.example.com/v1/tlsrpt" + +4. Reporting Schema + + The report is composed as a plaintext file encoded in the Internet + JSON (I-JSON) format [RFC7493]. + + Aggregate reports contain the following fields: + + o Report metadata: + + * The organization responsible for the report + + * Contact information for one or more responsible parties for the + contents of the report + + * A unique identifier for the report + + * The reporting date range for the report + + o Policy, consisting of: + + * One of the following policy types: (1) the MTA-STS Policy + applied (as a string), (2) the DANE TLSA record applied (as a + string, with each RR entry of the RRset listed and separated by + a semicolon), and (3) the literal string "no-policy-found", if + neither a DANE nor MTA-STS Policy could be found. + + * The domain for which the policy is applied + + * The MX host + + + + +Margolis, et al. Standards Track [Page 8] + +RFC 8460 SMTP TLS Reporting September 2018 + + + o Aggregate counts, comprising result type, Sending MTA IP, + receiving MTA hostname, session count, and an optional additional + information field containing a URI for recipients to review + further information on a failure type. + + Note that the failure types are non-exclusive; an aggregate report + may contain overlapping "counts" of failure types when a single send + attempt encountered multiple errors. Reporters may report multiple + applied policies (for example, an MTA-STS Policy and a DANE TLSA + record for the same domain and MX). Because of this, even in the + case where only a single policy was applied, the "policies" field of + the report body MUST be an array and not a singular value. + + In the case of multiple failure types, the "failure-details" array + would contain multiple entries. Each entry would have its own set of + information pertaining to that failure type. + +4.1. Report Time Frame + + The report SHOULD cover a full day, from 00:00-24:00 UTC. This + should allow for easier correlation of failure events. To avoid + unintentionally overloading the system processing the reports, the + reports should be delivered after some delay, perhaps several hours. + + As an example, a sending site might want to introduce a random delay + of up to four hours: + + func generate_sleep_delay() { + min_delay = 1 + max_delay = 14400 + rand = random(min_delay, max_delay) + return rand + } + + func generate_report(policy_domain) { + do_rpt_work(policy_domain) + send_rpt(policy_domain) + } + + func generate_tlsrpt() { + sleep(generate_sleep_delay()) + for policy_domain in list_of_tlsrpt_enabled_domains { + generate_report(policy_domain) + } + } + + + + + + +Margolis, et al. Standards Track [Page 9] + +RFC 8460 SMTP TLS Reporting September 2018 + + +4.2. Delivery Summary + +4.2.1. Success Count + + o "total-successful-session-count": This indicates that the Sending + MTA was able to successfully negotiate a policy-compliant TLS + connection and serves to provide a "heartbeat" to receiving + domains that signifies reporting is functional and tabulating + correctly. This field contains an aggregate count of successful + connections for the reporting system. + +4.2.2. Failure Count + + o "total-failure-session-count": This indicates that the Sending MTA + was unable to successfully establish a connection with the + receiving platform. Section 4.3, "Result Types", will elaborate + on the failed negotiation attempts. This field contains an + aggregate count of failed connections. + +4.3. Result Types + + The list of result types will start with the minimal set below and is + expected to grow over time based on real-world experience. The + initial set is outlined in Sections 4.3.1 to 4.3.4: + +4.3.1. Negotiation Failures + + o "starttls-not-supported": This indicates that the recipient MX did + not support STARTTLS. + + o "certificate-host-mismatch": This indicates that the certificate + presented did not adhere to the constraints specified in the MTA- + STS or DANE policy, e.g., if the MX hostname does not match any + identities listed in the subject alternative name (SAN) [RFC5280]. + + o "certificate-expired": This indicates that the certificate has + expired. + + o "certificate-not-trusted": This is a label that covers multiple + certificate-related failures that include, but are not limited to, + errors such as untrusted/unknown certification authorities (CAs), + certificate name constraints, certificate chain errors, etc. When + using this declaration, the reporting MTA SHOULD utilize the + "failure-reason-code" to provide more information to the receiving + entity. + + + + + + +Margolis, et al. Standards Track [Page 10] + +RFC 8460 SMTP TLS Reporting September 2018 + + + o "validation-failure": This indicates a general failure for a + reason not matching a category above. When using this + declaration, the reporting MTA SHOULD utilize the "failure-reason- + code" to provide more information to the receiving entity. + +4.3.2. Policy Failures + +4.3.2.1. DANE-Specific Policy Failures + + o "tlsa-invalid": This indicates a validation error in the TLSA + record associated with a DANE policy. None of the records in the + RRset were found to be valid. + + o "dnssec-invalid": This indicates that no valid records were + returned from the recursive resolver. + + o "dane-required": This indicates that the sending system is + configured to require DANE TLSA records for all the MX hosts of + the destination domain, but no DNSSEC-validated TLSA records were + present for the MX host that is the subject of the report. + Mandatory DANE for SMTP is described in Section 6 of [RFC7672]. + Such policies may be created by mutual agreement between two + organizations that frequently exchange sensitive content via + email. + +4.3.2.2. MTA-STS-specific Policy Failures + + o "sts-policy-fetch-error": This indicates a failure to retrieve an + MTA-STS policy, for example, because the policy host is + unreachable. + + o "sts-policy-invalid": This indicates a validation error for the + overall MTA-STS Policy. + + o "sts-webpki-invalid": This indicates that the MTA-STS Policy could + not be authenticated using PKIX validation. + +4.3.3. General Failures + + When a negotiation failure cannot be categorized into one of the + "Negotiation Failures" stated above, the reporter SHOULD use the + "validation-failure" category. As TLS grows and becomes more + complex, new mechanisms may not be easily categorized. This allows + for a generic feedback category. When this category is used, the + reporter SHOULD also use "failure-reason-code" to give some feedback + to the receiving entity. This is intended to be a short text field, + and the contents of the field should be an error code or error text, + such as "X509_V_ERR_UNHANDLED_CRITICAL_CRL_EXTENSION". + + + +Margolis, et al. Standards Track [Page 11] + +RFC 8460 SMTP TLS Reporting September 2018 + + +4.3.4. Transient Failures + + Transient errors due to too-busy networks, TCP timeouts, etc., are + not required to be reported. + +4.4. JSON Report Schema + + The JSON schema is derived from the HTTP Public Key Pinning (HPKP) + JSON schema; see Section 3 of [RFC7469]. + + { + "organization-name": organization-name, + "date-range": { + "start-datetime": date-time, + "end-datetime": date-time + }, + "contact-info": email-address, + "report-id": report-id, + "policies": [{ + "policy": { + "policy-type": policy-type, + "policy-string": policy-string, + "policy-domain": domain, + "mx-host": mx-host-pattern + }, + "summary": { + "total-successful-session-count": total-successful-session-count, + "total-failure-session-count": total-failure-session-count + }, + "failure-details": [ + { + "result-type": result-type, + "sending-mta-ip": ip-address, + "receiving-mx-hostname": receiving-mx-hostname, + "receiving-mx-helo": receiving-mx-helo, + "receiving-ip": receiving-ip, + "failed-session-count": failed-session-count, + "additional-information": additional-info-uri, + "failure-reason-code": failure-reason-code + } + ] + } + ] + } + + + JSON Report Format + + + + +Margolis, et al. Standards Track [Page 12] + +RFC 8460 SMTP TLS Reporting September 2018 + + + o "organization-name": The name of the organization responsible for + the report. It is provided as a string. + + o "date-time": The date-time indicates the start and end times for + the report range. It is provided as a string formatted according + to "Internet Date/Time Format", Section 5.6 of [RFC3339]. The + report should be for a full UTC day, 00:00-24:00. + + o "email-address": The contact information for the party responsible + for the report. It is provided as a string formatted according to + "Addr-Spec Specification", Section 3.4.1 of [RFC5322]. + + o "report-id": A unique identifier for the report. Report authors + may use whatever scheme they prefer to generate a unique + identifier. It is provided as a string. + + o "policy-type": The type of policy that was applied by the sending + domain. Presently, the only three valid choices are "tlsa", + "sts", and the literal string "no-policy-found". It is provided + as a string. + + o "policy-string": An encoding of the applied policy as a JSON array + of strings, whether it's a TLSA record ([RFC6698], Section 2.3) or + an MTA-STS Policy. Examples follow in the next section. + + o "domain": The Policy Domain against which the MTA-STS or DANE + policy is defined. In the case of Internationalized Domain Names + [RFC5891], the domain MUST consist of the Punycode-encoded + A-labels [RFC3492] and not the U-labels. + + o "mx-host-pattern": In the case where "policy-type" is "sts", it's + the pattern of MX hostnames from the applied policy. It is + provided as a JSON array of strings and is interpreted in the same + manner as the rules in "MX Host Validation"; see Section 4.1 of + [RFC8461]. In the case of Internationalized Domain Names + [RFC5891], the domain MUST consist of the Punycode-encoded + A-labels [RFC3492] and not the U-labels. + + o "result-type": A value from Section 4.3, "Result Types", above. + + o "ip-address": The IP address of the Sending MTA that attempted the + STARTTLS connection. It is provided as a string representation of + an IPv4 (see below) or IPv6 [RFC5952] address in dot-decimal or + colon-hexadecimal notation. + + o "receiving-mx-hostname": The hostname of the receiving MTA MX + record with which the Sending MTA attempted to negotiate a + STARTTLS connection. + + + +Margolis, et al. Standards Track [Page 13] + +RFC 8460 SMTP TLS Reporting September 2018 + + + o "receiving-mx-helo" (optional): The HELLO (HELO) or Extended HELLO + (EHLO) string from the banner announced during the reported + session. + + o "receiving-ip": The destination IP address that was used when + creating the outbound session. It is provided as a string + representation of an IPv4 (see below) or IPv6 [RFC5952] address in + dot-decimal or colon-hexadecimal notation. + + o "total-successful-session-count": The aggregate count (an integer, + encoded as a JSON number) of successfully negotiated TLS-enabled + connections to the receiving site. + + o "total-failure-session-count": The aggregate count (an integer, + encoded as a JSON number) of failures to negotiate a TLS-enabled + connection to the receiving site. + + o "failed-session-count": The number of (attempted) sessions that + match the relevant "result-type" for this section (an integer, + encoded as a JSON number). + + o "additional-info-uri" (optional): A URI [RFC3986] that points to + additional information around the relevant "result-type". For + example, this URI might host the complete certificate chain + presented during an attempted STARTTLS session. + + o "failure-reason-code": A text field to include a TLS-related error + code or error message. + + For report purposes, an IPv4 address is defined via the following + ABNF: + + IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet + dec-octet = DIGIT ; 0-9 + / %x31-39 DIGIT ; 10-99 + / "1" 2DIGIT ; 100-199 + / "2" %x30-34 DIGIT ; 200-249 + / "25" %x30-35 ; 250-255 + + And an IPv6 address is defined via the following ABNF: + + + IPv6address = + + + + + + + + +Margolis, et al. Standards Track [Page 14] + +RFC 8460 SMTP TLS Reporting September 2018 + + +4.5. Policy Samples + + Part of the report body includes the policy that is applied when + attempting relay to the destination. + + For DANE TLSA policies, this is a JSON array of strings each + representing the RDATA of a single TLSA resource record as a space- + separated list of its four TLSA fields; the fields are in + presentation format (defined in [RFC6698], Section 2.2) with no + internal spaces or grouping parentheses: + + [ + "3 0 1 1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513 + D747D1D085D", + "3 0 1 12350A337E6DB9C6123522D136A475638CC43E1ED424F8EEC8513 + D747D1D1234" + ] + + For MTA-STS policies, this is an array of JSON strings that + represents the policy that is declared by the receiving site, + including any errors that may be present. Note that where there are + multiple "mx" values, they must be listed as separate "mx" elements + in the policy array rather than as a single nested "mx" sub-array. + + [ + "version: STSv1", + "mode: testing", + "mx: mx1.example.com", + "mx: mx2.example.com", + "mx: mx.backup-example.com", + "max_age: 604800" + ] + +5. Report Delivery + + Reports can be delivered either via SMTP (as an email message) or via + HTTP POST. + + + + + + + + + + + + + + +Margolis, et al. Standards Track [Page 15] + +RFC 8460 SMTP TLS Reporting September 2018 + + +5.1. Report Filename + + The filename is RECOMMENDED to be constructed using the following + ABNF: + + filename = sender "!" policy-domain "!" begin-timestamp + "!" end-timestamp [ "!" unique-id ] "." extension + + unique-id = 1*(ALPHA / DIGIT) + + sender = domain ; from [RFC5321] -- this is used + ; as the domain for the `contact-info` + ; address in the report body. + ; In the case of Internationalized Domain + ; Names [RFC5891], the domain MUST consist of + ; the Punycode-encoded A-labels [RFC3492] and + ; not the U-labels. + + policy-domain = domain + ; In the case of Internationalized Domain + ; Names [RFC5891], the domain MUST consist of + ; the Punycode-encoded A-labels [RFC3492] and + ; not the U-labels. + + 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 = "json" / "json.gz" + + + The extension MUST be "json" for a plain JSON file or "json.gz" for a + JSON file compressed using gzip. + + "unique-id" allows an optional unique ID generated by the Sending MTA + to distinguish among multiple reports generated simultaneously by + different sources for the same Policy Domain. For example, this is a + possible filename for a compressed report to the Policy Domain + "example.net" from the Sending MTA "mail.sndr.example.com": + + "mail.sndr.example.com!example.net!1470013207!1470186007!001.json.gz" + + + + +Margolis, et al. Standards Track [Page 16] + +RFC 8460 SMTP TLS Reporting September 2018 + + +5.2. Compression + + The report SHOULD be subjected to gzip [RFC1952] compression for both + email and HTTPS transport. 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); compressing the file + increases the chances of acceptance of the report at some + computational cost. + +5.3. Email Transport + + The report MAY be delivered by email. To make the reports machine- + parsable for the receivers, we define a top-level media type + "multipart/report" with a new parameter "report-type="tlsrpt"". + Inside it, there are two parts: The first part is human readable, + typically "text/plain", and the second part is machine readable with + a new media type defined called "application/tlsrpt+json". If + compressed, the report should use the media type "application/ + tlsrpt+gzip". + + In addition, the following two new top-level message header fields + are defined: + + "TLS-Report-Domain: Receiver-Domain" + + "TLS-Report-Submitter: Sender-Domain" + + The "TLS-Report-Submitter" value MUST match the value found in the + domain [RFC5321] of the "contact-info" from the report body. These + message header fields MUST be included and should allow for easy + searching for all reports submitted by a reporting domain or a + particular submitter, for example, in IMAP [RFC3501]: + + "s SEARCH HEADER "TLS-Report-Domain" "example.com"" + + It is presumed that the aggregate reporting address will be equipped + to process new message header fields and extract MIME parts with the + prescribed media type and filename, and ignore the rest. These + additional headers SHOULD be included in the DKIM [RFC6376] signature + for the message. + + + + + + + + + + + +Margolis, et al. Standards Track [Page 17] + +RFC 8460 SMTP TLS Reporting September 2018 + + + The RFC5322.Subject field for report submissions SHOULD conform to + the following ABNF: + + tlsrpt-subject = %s"Report" FWS ; "Report" + %s"Domain:" FWS ; "Domain:" + domain-name FWS ; per [RFC6376] + %s"Submitter:" FWS ; "Submitter:" + domain-name FWS ; per [RFC6376] + %s"Report-ID:" FWS ; "Report-ID: + "<" id-left "@" id-right ">" ; per [RFC5322] + [CFWS] ; per [RFC5322] + ; (as with FWS) + + 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 Sending MTA generating the report. The + purpose of the "Report-ID:" portion of the field is to enable the + Policy Domain to identify and ignore duplicate reports that might be + sent by a Sending MTA. + + For instance, this is a possible Subject field for a report to the + Policy Domain "example.net" from the Sending MTA + "mail.sender.example.com". It is line-wrapped as allowed by + [RFC5322]: + + Subject: Report Domain: example.net + Submitter: mail.sender.example.com + Report-ID: <735ff.e317+bf22029@mailexample.net> + + + + + + + + + + + + + + + + + + + + + + + +Margolis, et al. Standards Track [Page 18] + +RFC 8460 SMTP TLS Reporting September 2018 + + +5.3.1. Example Report + + From: tlsrpt@mail.sender.example.com + Date: Fri, May 09 2017 16:54:30 -0800 + To: mts-sts-tlsrpt@example.net + Subject: Report Domain: example.net + Submitter: mail.sender.example.com + Report-ID: <735ff.e317+bf22029@example.net> + TLS-Report-Domain: example.net + TLS-Report-Submitter: mail.sender.example.com + MIME-Version: 1.0 + Content-Type: multipart/report; report-type="tlsrpt"; + boundary="----=_NextPart_000_024E_01CC9B0A.AFE54C00" + Content-Language: en-us + + This is a multipart message in MIME format. + + ------=_NextPart_000_024E_01CC9B0A.AFE54C00 + Content-Type: text/plain; charset="us-ascii" + Content-Transfer-Encoding: 7bit + + This is an aggregate TLS report from mail.sender.example.com + + ------=_NextPart_000_024E_01CC9B0A.AFE54C00 + Content-Type: application/tlsrpt+gzip + Content-Transfer-Encoding: base64 + Content-Disposition: attachment; + filename="mail.sender.example!example.com! + 1013662812!1013749130.json.gz" + + + + ------=_NextPart_000_024E_01CC9B0A.AFE54C00-- + ... + + Note that, when sending failure reports via SMTP, Sending MTAs MUST + NOT honor MTA-STS or DANE TLSA failures. + +5.4. HTTPS Transport + + The report MAY be delivered by POST to HTTPS. If compressed, the + report SHOULD use the media type "application/tlsrpt+gzip"; otherwise + it SHOULD use the media type "application/tlsrpt+json" (see + Section 6, "IANA Considerations"). + + The receiving system MUST return a "successful" response from its + HTTPS server, typically a 200 or 201 HTTP code [RFC7231]. Other + codes could indicate a delivery failure and may be retried as per + + + +Margolis, et al. Standards Track [Page 19] + +RFC 8460 SMTP TLS Reporting September 2018 + + + local sender policy. The receiving system is not expected to process + reports at receipt time and MAY store them for processing at a later + time. + +5.5. Delivery Retry + + In the event of a delivery failure, regardless of the delivery + method, a sender SHOULD attempt redelivery for up to 24 hours after + the initial attempt. As previously stated, the reports are optional, + so while it is ideal to attempt redelivery, it is not required. If + multiple retries are attempted, ideally they SHOULD be done with + exponential backoff. + +5.6. Metadata Variances + + As stated above, there are a variable number of ways to declare + information about the data therein. If any of the items declared via + subject or filename disagree with the report, the report MUST be + considered the authoritative source. + +6. IANA Considerations + + The following are the IANA considerations discussed in this document. + +6.1. Message Headers + + Below is the Internet Assigned Numbers Authority (IANA) Permanent + Message Header Field registration information per [RFC3864]. + + Header field name: TLS-Report-Domain + Applicable protocol: mail + Status: standard + Author/Change controller: IETF + Specification document(s): RFC 8460 + + + Header field name: TLS-Report-Submitter + Applicable protocol: mail + Status: standard + Author/Change controller: IETF + Specification document(s): RFC 8460 + + + + + + + + + + +Margolis, et al. Standards Track [Page 20] + +RFC 8460 SMTP TLS Reporting September 2018 + + +6.2. Report Type + + This document creates a new registry for the "report-type" parameter + to the Content-Type header field for the "multipart/report" top-level + media type defined in [RFC6522]. + + The registry name is "Report Type Registry", and the procedure for + updating the registry will be "Specification Required" [RFC8126]. + + An entry in this registry should contain: + + o the report-type being registered + + o one or more registered media types that can be used with this + report-type + + o the document containing the registration action + + o an optional comment + + The initial entries are: + + Report-Type: tlsrpt + Media Type: application/tlsrpt+gzip, application/tlsrpt+json + Registered By: [RFC8460] + Comment: Media types suitable for use with this report-type are + defined in Sections 6.4 and 6.5 of [RFC8460] + + Report-Type: disposition-notification + Media Type: message/disposition-notification + Registered By: [RFC8098], Section 10 + + Report-Type: disposition-notification + Media Type: message/global-disposition-notification + Registered By: [RFC6533], Section 6 + + Report-Type: delivery-status + Media Type: message/delivery-status + Registered By: [RFC3464], Section 6.2 + + Report-Type: delivery-status + Media Type: message/global-delivery-status + Registered By: [RFC6533], Section 6 + + + + + + + + +Margolis, et al. Standards Track [Page 21] + +RFC 8460 SMTP TLS Reporting September 2018 + + +6.3. +gzip Media Type Suffix + + This document registers a new media type suffix "+gzip". The gzip + format is a public domain, cross-platform, interoperable file storage + and transfer format, specified in [RFC1952]; it supports compression + and is used as the underlying representation by a variety of file + formats. The media type "application/gzip" has been registered for + such files. The suffix "+gzip" MAY be used with any media type whose + representation follows that established for "application/gzip". The + registration form for the structured syntax suffix for use with media + types is as follows: + + Type name: gzip file storage and transfer format. + + +suffix: +gzip + + References: [RFC1952] [RFC6713] + + Encoding considerations: gzip is a binary encoding. + + Fragment identifier considerations: The syntax and semantics of + fragment identifiers specified for +gzip SHOULD be as specified for + "application/gzip". (At publication of this document, there is no + fragment identification syntax defined for "application/gzip".) The + syntax and semantics for fragment identifiers for a specific "xxx/ + yyy+gzip" SHOULD be processed as follows: + + For cases defined in +gzip, where the fragment identifier + resolves per the +gzip rules, process as specified in + +gzip. + + For cases defined in +gzip, where the fragment identifier does + not resolve per the +gzip rules, process as specified in + "xxx/yyy+gzip". + + For cases not defined in +gzip, process as specified in + "xxx/yyy+gzip". + + Interoperability considerations: N/A + + Security considerations: gzip format doesn't provide confidentiality + protection. Integrity protection is provided by an Adler-32 + checksum, which is not cryptographically strong. See also the + security considerations of [RFC6713]. Each individual media type + registered with a +gzip suffix can have additional security + considerations. Additionally, gzip objects can contain multiple + + + + + +Margolis, et al. Standards Track [Page 22] + +RFC 8460 SMTP TLS Reporting September 2018 + + + files and associated paths. File paths must be validated when the + files are extracted; a malicious file path could otherwise cause the + extractor to overwrite application or system files. + + Contact: art@ietf.org + + Author/Change controller: Internet Engineering Task Force + (iesg@ietf.org). + +6.4. application/tlsrpt+json Media Type + + This document registers multiple media types, beginning with Table 1 + below. + + +-------------+----------------+-------------+-------------------+ + | Type | Subtype | File Ext | Specification | + +-------------+----------------+-------------+-------------------+ + | application | tlsrpt+json | .json | Section 5.3 | + +-------------+----------------+-------------+-------------------+ + + Table 1: SMTP TLS Reporting Media Type + + Type name: application + + Subtype name: tlsrpt+json + + Required parameters: N/A + + Optional parameters: N/A + + Encoding considerations: Encoding considerations are identical to + those specified for the "application/json" media type. See + [RFC7493]. + + Security considerations: Security considerations relating to SMTP TLS + Reporting are discussed in Section 7. + + Interoperability considerations: This document specifies the format + of conforming messages and the interpretation thereof. + + Published specification: Section 5.3 of RFC 8460. + + Applications that use this media type: Mail User Agents (MUAs) and + Mail Transfer Agents. + + + + + + + +Margolis, et al. Standards Track [Page 23] + +RFC 8460 SMTP TLS Reporting September 2018 + + + Additional information: + + Deprecated alias names for this type: N/A + + Magic number(s): N/A + + File extension(s): ".json" + + Macintosh file type code(s): N/A + + Person & email address to contact for further information: + See the Authors' Addresses section. + + Intended usage: COMMON + + Restrictions on usage: N/A + + Author: See the Authors' Addresses section. + + Change controller: Internet Engineering Task Force (iesg@ietf.org). + +6.5. application/tlsrpt+gzip Media Type + + +-------------+----------------+-------------+-------------------+ + | Type | Subtype | File Ext | Specification | + +-------------+----------------+-------------+-------------------+ + | application | tlsrpt+gzip | .gz | Section 5.3 | + +-------------+----------------+-------------+-------------------+ + + Table 2: SMTP TLS Reporting Media Type + + Type name: application + + Subtype name: tlsrpt+gzip + + Required parameters: N/A + + Optional parameters: N/A + + Encoding considerations: Binary + + Security considerations: Security considerations relating to SMTP TLS + Reporting are discussed in Section 7. Security considerations + related to gzip compression are discussed in RFC 6713. + + Interoperability considerations: This document specifies the format + of conforming messages and the interpretation thereof. + + + + +Margolis, et al. Standards Track [Page 24] + +RFC 8460 SMTP TLS Reporting September 2018 + + + Published specification: Section 5.3 of RFC 8460. + + Applications that use this media type: Mail User Agents (MUAs) and + Mail Transfer Agents. + + Additional information: + + Deprecated alias names for this type: N/A + + Magic number(s): The first two bytes are 0x1f, 0x8b. + + File extension(s): ".gz" + + Macintosh file type code(s): N/A + + Person & email address to contact for further information: + See the Authors' Addresses section. + + Intended usage: COMMON + + Restrictions on usage: N/A + + Author: See the Authors' Addresses section. + + Change controller: Internet Engineering Task Force (iesg@ietf.org). + +6.6. STARTTLS Validation Result Types + + This document creates a new registry, "STARTTLS Validation Result + Types". The initial entries in the registry are: + + +-----------------------------+--------------+ + | Result Type | Description | + +-----------------------------+--------------+ + | starttls-not-supported | Section 4.3 | + | certificate-host-mismatch | Section 4.3 | + | certificate-expired | Section 4.3 | + | tlsa-invalid | Section 4.3 | + | dnssec-invalid | Section 4.3 | + | dane-required | Section 4.3 | + | certificate-not-trusted | Section 4.3 | + | sts-policy-invalid | Section 4.3 | + | sts-webpki-invalid | Section 4.3 | + | validation-failure | Section 4.3 | + | sts-policy-fetch-error | Section 4.3 | + +-----------------------------+--------------+ + + + + + +Margolis, et al. Standards Track [Page 25] + +RFC 8460 SMTP TLS Reporting September 2018 + + + The above entries are described in Section 4.3, "Result Types". New + result types can be added to this registry using the "Expert Review" + IANA registration policy. + +7. Security Considerations + + SMTP TLS Reporting provides visibility into misconfigurations or + attempts to intercept or tamper with mail between hosts who support + STARTTLS. There are several security risks presented by the + existence of this reporting channel: + + o Flooding of the Aggregate Report URI (rua) endpoint: An attacker + could flood the endpoint with excessive reporting traffic and + prevent the receiving domain from accepting additional reports. + This type of Denial-of-Service attack would limit visibility into + STARTTLS failures, leaving the receiving domain blind to an + ongoing attack. + + o Untrusted content: An attacker could inject malicious code into + the report, exploiting any vulnerabilities in the report-handling + systems of the receiving domain. Implementers are advised to take + precautions against evaluating the contents of the report. + + o Report snooping: An attacker could create a bogus TLSRPT record to + receive statistics about a domain the attacker does not own. + Since an attacker that is able to poison DNS is already able to + receive counts of SMTP connections (and, absent DANE or MTA-STS + policies, actual SMTP message payloads), this does not present a + significant new vulnerability. + + o Ignoring HTTPS validation when submitting reports: When reporting + benign misconfigurations, it is likely that a misconfigured SMTP + server may also mean a misconfigured HTTPS server; as a result, + reporters who require HTTPS validity on the reporting endpoint may + fail to alert administrators about such misconfigurations. + Conversely, in the event of an actual attack, an attacker who + wishes to create a gap in reporting and could intercept HTTPS + reports could, just as easily, simply thwart the resolution of the + TLSRPT TXT record or establishment of the TCP session to the HTTPS + endpoint. Furthermore, such a man-in-the-middle attacker could + discover most or all of the metadata exposed in a report merely + through passive observation. As a result, we consider the risks + of failure to deliver reports on misconfigurations to outweigh + those of attackers intercepting reports. + + + + + + + +Margolis, et al. Standards Track [Page 26] + +RFC 8460 SMTP TLS Reporting September 2018 + + + o Reports as DDoS: TLSRPT allows specifying destinations for the + reports that are outside the authority of the Policy Domain, which + allows domains to delegate processing of reports to a partner + organization. However, an attacker who controls the Policy Domain + DNS could also use this mechanism to direct the reports to an + unwitting victim, flooding that victim with excessive reports. + DMARC [RFC7489] defines a solution for verifying delegation to + avoid such attacks; the need for this is greater with DMARC, + however, because DMARC allows an attacker to trigger reports to a + target from an innocent third party by sending mail to that third + party (which triggers a report from the third party to the + target). In the case of TLSRPT, the attacker would have to induce + the third party to send mail to the attacker in order to trigger + reports from the third party to the victim; this reduces the risk + of such an attack and the need for a verification mechanism. + + Finally, because TLSRPT is intended to help administrators discover + man-in-the-middle attacks against transport-layer encryption, + including attacks designed to thwart negotiation of encrypted + connections (by downgrading opportunistic encryption or, in the case + of MTA-STS, preventing discovery of a new MTA-STS Policy), we must + also consider the risk that an adversary who can induce such a + downgrade attack can also prevent discovery of the TLSRPT TXT record + (and thus prevent discovery of the successful downgrade attack). + Administrators are thus encouraged to deploy TLSRPT TXT records with + a large TTL (reducing the window for successful application of + transient attacks against DNS resolution of the record) or to deploy + DNSSEC on the deploying zone. + +8. Privacy Considerations + + MTAs are generally considered public knowledge; however, the + internals of how those MTAs are configured and the users of those + MTAs may not be as public. It should be noted that providing a + receiving site with information about TLS failures may reveal + information about the sender's configuration or even information + about the senders themselves. For example, sending a report may + disclose what TLS implementation the sender uses, as the inability to + negotiate a session may be a known incompatibility between two + implementations. This may, indirectly, leak information on the + reporter's operating system or even region, if, for example, a rare + TLS implementation is popular among certain users or in certain + locations. + + + + + + + + +Margolis, et al. Standards Track [Page 27] + +RFC 8460 SMTP TLS Reporting September 2018 + + +9. References + +9.1. Normative References + + [RFC1952] Deutsch, P., "GZIP file format specification version 4.3", + RFC 1952, DOI 10.17487/RFC1952, May 1996, + . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: + Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, + . + + [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode + for Internationalized Domain Names in Applications + (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003, + . + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, + RFC 3986, DOI 10.17487/RFC3986, January 2005, + . + + [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, + DOI 10.17487/RFC5234, January 2008, + . + + [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., + Housley, R., and W. Polk, "Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation List + (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, + . + + [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, + DOI 10.17487/RFC5321, October 2008, + . + + [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, + DOI 10.17487/RFC5322, October 2008, + . + + + + + + +Margolis, et al. Standards Track [Page 28] + +RFC 8460 SMTP TLS Reporting September 2018 + + + [RFC5891] Klensin, J., "Internationalized Domain Names in + Applications (IDNA): Protocol", RFC 5891, + DOI 10.17487/RFC5891, August 2010, + . + + [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 + Address Text Representation", RFC 5952, + DOI 10.17487/RFC5952, August 2010, + . + + [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' + URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010, + . + + [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, + . + + [RFC6522] Kucherawy, M., Ed., "The Multipart/Report Media Type for + the Reporting of Mail System Administrative Messages", + STD 73, RFC 6522, DOI 10.17487/RFC6522, January 2012, + . + + [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication + of Named Entities (DANE) Transport Layer Security (TLS) + Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August + 2012, . + + [RFC6713] Levine, J., "The 'application/zlib' and 'application/gzip' + Media Types", RFC 6713, DOI 10.17487/RFC6713, August 2012, + . + + [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for + Authorizing Use of Domains in Email, Version 1", RFC 7208, + DOI 10.17487/RFC7208, April 2014, + . + + [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Semantics and Content", RFC 7231, + DOI 10.17487/RFC7231, June 2014, + . + + [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", + RFC 7405, DOI 10.17487/RFC7405, December 2014, + . + + + + + +Margolis, et al. Standards Track [Page 29] + +RFC 8460 SMTP TLS Reporting September 2018 + + + [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, + DOI 10.17487/RFC7493, March 2015, + . + + [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based + Authentication of Named Entities (DANE) Protocol: Updates + and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, + October 2015, . + + [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via + Opportunistic DNS-Based Authentication of Named Entities + (DANE) Transport Layer Security (TLS)", RFC 7672, + DOI 10.17487/RFC7672, October 2015, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [RFC8461] Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A., + and J. Jones, "SMTP MTA Strict Transport Security (MTA- + STS)", RFC 8461, DOI 10.17487/RFC8461, September 2018, + . + +9.2. Informative References + + [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over + Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, + February 2002, . + + [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format + for Delivery Status Notifications", RFC 3464, + DOI 10.17487/RFC3464, January 2003, + . + + [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION + 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, + . + + [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration + Procedures for Message Header Fields", BCP 90, RFC 3864, + DOI 10.17487/RFC3864, September 2004, + . + + [RFC6533] Hansen, T., Ed., Newman, C., and A. Melnikov, + "Internationalized Delivery Status and Disposition + Notifications", RFC 6533, DOI 10.17487/RFC6533, February + 2012, . + + + +Margolis, et al. Standards Track [Page 30] + +RFC 8460 SMTP TLS Reporting September 2018 + + + [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection + Most of the Time", RFC 7435, DOI 10.17487/RFC7435, + December 2014, . + + [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning + Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April + 2015, . + + [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based + Message Authentication, Reporting, and Conformance + (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, + . + + [RFC8098] Hansen, T., Ed. and A. Melnikov, Ed., "Message Disposition + Notification", STD 85, RFC 8098, DOI 10.17487/RFC8098, + February 2017, . + + [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for + Writing an IANA Considerations Section in RFCs", BCP 26, + RFC 8126, DOI 10.17487/RFC8126, June 2017, + . + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Margolis, et al. Standards Track [Page 31] + +RFC 8460 SMTP TLS Reporting September 2018 + + +Appendix A. Example Reporting Policy + +A.1. Report Using MAILTO + + _smtp._tls.mail.example.com. IN TXT \ + "v=TLSRPTv1;rua=mailto:reports@example.com" + +A.2. Report Using HTTPS + + _smtp._tls.mail.example.com. IN TXT \ + "v=TLSRPTv1; \ + rua=https://reporting.example.com/v1/tlsrpt" + +Appendix B. Example JSON Report + + Below is an example JSON report for messages from Company-X to + Company-Y, where 100 sessions were attempted to Company-Y servers + with an expired certificate, and 200 sessions were attempted to + Company-Y servers that did not successfully respond to the "STARTTLS" + command. Additionally, 3 sessions failed due to + "X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED". + + { + "organization-name": "Company-X", + "date-range": { + "start-datetime": "2016-04-01T00:00:00Z", + "end-datetime": "2016-04-01T23:59:59Z" + }, + "contact-info": "sts-reporting@company-x.example", + "report-id": "5065427c-23d3-47ca-b6e0-946ea0e8c4be", + "policies": [{ + "policy": { + "policy-type": "sts", + "policy-string": ["version: STSv1","mode: testing", + "mx: *.mail.company-y.example","max_age: 86400"], + "policy-domain": "company-y.example", + "mx-host": "*.mail.company-y.example" + }, + "summary": { + "total-successful-session-count": 5326, + "total-failure-session-count": 303 + }, + "failure-details": [{ + "result-type": "certificate-expired", + "sending-mta-ip": "2001:db8:abcd:0012::1", + "receiving-mx-hostname": "mx1.mail.company-y.example", + "failed-session-count": 100 + }, { + + + +Margolis, et al. Standards Track [Page 32] + +RFC 8460 SMTP TLS Reporting September 2018 + + + "result-type": "starttls-not-supported", + "sending-mta-ip": "2001:db8:abcd:0013::1", + "receiving-mx-hostname": "mx2.mail.company-y.example", + "receiving-ip": "203.0.113.56", + "failed-session-count": 200, + "additional-information": "https://reports.company-x.example/ + report_info ? id = 5065427 c - 23 d3# StarttlsNotSupported " + }, { + "result-type": "validation-failure", + "sending-mta-ip": "198.51.100.62", + "receiving-ip": "203.0.113.58", + "receiving-mx-hostname": "mx-backup.mail.company-y.example", + "failed-session-count": 3, + "failure-reason-code": "X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED" + }] + }] + } + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Margolis, et al. Standards Track [Page 33] + +RFC 8460 SMTP TLS Reporting September 2018 + + +Contributors + + Laetitia Baudoin + Google, Inc. + lbaudoin@google.com + +Authors' Addresses + + Daniel Margolis + Google, Inc. + + Email: dmargolis@google.com + + + Alexander Brotman + Comcast, Inc. + + Email: alex_brotman@comcast.com + + + Binu Ramakrishnan + Oath, Inc. + + Email: prbinu@yahoo.com + + + Janet Jones + Microsoft, Inc. + + Email: janet.jones@microsoft.com + + + Mark Risher + Google, Inc. + + Email: risher@google.com + + + + + + + + + + + + + + + +Margolis, et al. Standards Track [Page 34] + -- cgit v1.2.3