7Internet Engineering Task Force (IETF) D. Margolis
8Request for Comments: 8460 Google, Inc.
9Category: Standards Track A. Brotman
10ISSN: 2070-1721 Comcast, Inc.
24 A number of protocols exist for establishing encrypted channels
25 between SMTP Mail Transfer Agents (MTAs), including STARTTLS, DNS-
26 Based Authentication of Named Entities (DANE) TLSA, and MTA Strict
27 Transport Security (MTA-STS). These protocols can fail due to
28 misconfiguration or active attack, leading to undelivered messages or
29 delivery over unencrypted or unauthenticated channels. This document
30 describes a reporting mechanism and format by which sending systems
31 can share statistics and specific information about potential
32 failures with recipient domains. Recipient domains can then use this
33 information to both detect potential attacks and diagnose
34 unintentional misconfigurations.
38 This is an Internet Standards Track document.
40 This document is a product of the Internet Engineering Task Force
41 (IETF). It represents the consensus of the IETF community. It has
42 received public review and has been approved for publication by the
43 Internet Engineering Steering Group (IESG). Further information on
44 Internet Standards is available in Section 2 of RFC 7841.
46 Information about the current status of this document, any errata,
47 and how to provide feedback on it may be obtained at
48 https://www.rfc-editor.org/info/rfc8460.
58Margolis, et al. Standards Track [Page 1]
60RFC 8460 SMTP TLS Reporting September 2018
65 Copyright (c) 2018 IETF Trust and the persons identified as the
66 document authors. All rights reserved.
68 This document is subject to BCP 78 and the IETF Trust's Legal
69 Provisions Relating to IETF Documents
70 (https://trustee.ietf.org/license-info) in effect on the date of
71 publication of this document. Please review these documents
72 carefully, as they describe your rights and restrictions with respect
73 to this document. Code Components extracted from this document must
74 include Simplified BSD License text as described in Section 4.e of
75 the Trust Legal Provisions and are provided without warranty as
76 described in the Simplified BSD License.
114Margolis, et al. Standards Track [Page 2]
116RFC 8460 SMTP TLS Reporting September 2018
121 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
122 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
123 2. Related Technologies . . . . . . . . . . . . . . . . . . . . 5
124 3. Reporting Policy . . . . . . . . . . . . . . . . . . . . . . 6
125 3.1. Example Reporting Policy . . . . . . . . . . . . . . . . 8
126 3.1.1. Report Using MAILTO . . . . . . . . . . . . . . . . . 8
127 3.1.2. Report Using HTTPS . . . . . . . . . . . . . . . . . 8
128 4. Reporting Schema . . . . . . . . . . . . . . . . . . . . . . 8
129 4.1. Report Time Frame . . . . . . . . . . . . . . . . . . . . 9
130 4.2. Delivery Summary . . . . . . . . . . . . . . . . . . . . 10
131 4.2.1. Success Count . . . . . . . . . . . . . . . . . . . . 10
132 4.2.2. Failure Count . . . . . . . . . . . . . . . . . . . . 10
133 4.3. Result Types . . . . . . . . . . . . . . . . . . . . . . 10
134 4.3.1. Negotiation Failures . . . . . . . . . . . . . . . . 10
135 4.3.2. Policy Failures . . . . . . . . . . . . . . . . . . . 11
136 4.3.3. General Failures . . . . . . . . . . . . . . . . . . 11
137 4.3.4. Transient Failures . . . . . . . . . . . . . . . . . 12
138 4.4. JSON Report Schema . . . . . . . . . . . . . . . . . . . 12
139 4.5. Policy Samples . . . . . . . . . . . . . . . . . . . . . 15
140 5. Report Delivery . . . . . . . . . . . . . . . . . . . . . . . 15
141 5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 16
142 5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 17
143 5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 17
144 5.3.1. Example Report . . . . . . . . . . . . . . . . . . . 19
145 5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 19
146 5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 20
147 5.6. Metadata Variances . . . . . . . . . . . . . . . . . . . 20
148 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
149 6.1. Message Headers . . . . . . . . . . . . . . . . . . . . . 20
150 6.2. Report Type . . . . . . . . . . . . . . . . . . . . . . . 21
151 6.3. +gzip Media Type Suffix . . . . . . . . . . . . . . . . . 22
152 6.4. application/tlsrpt+json Media Type . . . . . . . . . . . 23
153 6.5. application/tlsrpt+gzip Media Type . . . . . . . . . . . 24
154 6.6. STARTTLS Validation Result Types . . . . . . . . . . . . 25
155 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
156 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27
157 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
158 9.1. Normative References . . . . . . . . . . . . . . . . . . 28
159 9.2. Informative References . . . . . . . . . . . . . . . . . 30
160 Appendix A. Example Reporting Policy . . . . . . . . . . . . . . 32
161 A.1. Report Using MAILTO . . . . . . . . . . . . . . . . . . . 32
162 A.2. Report Using HTTPS . . . . . . . . . . . . . . . . . . . 32
163 Appendix B. Example JSON Report . . . . . . . . . . . . . . . . 32
164 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 34
165 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
170Margolis, et al. Standards Track [Page 3]
172RFC 8460 SMTP TLS Reporting September 2018
177 The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and
178 hosts to establish secure SMTP sessions over TLS. The protocol
179 design uses an approach that has come to be known as "Opportunistic
180 Security" (OS) [RFC7435]. This method maintains interoperability
181 with clients that do not support STARTTLS, but it means that any
182 attacker could potentially eavesdrop on a session. An attacker could
183 perform a downgrade or interception attack by deleting parts of the
184 SMTP session (such as the "250 STARTTLS" response) or redirect the
185 entire SMTP session (perhaps by overwriting the resolved MX record of
186 the delivery domain).
188 Because such "downgrade attacks" are not necessarily apparent to the
189 receiving MTA, this document defines a mechanism for sending domains
190 to report on failures at multiple stages of the MTA-to-MTA
193 Recipient domains may also use the mechanisms defined by MTA-STS
194 [RFC8461] or DANE [RFC6698] to publish additional encryption and
195 authentication requirements; this document defines a mechanism for
196 sending domains that are compatible with MTA-STS or DANE to share
197 success and failure statistics with recipient domains.
199 Specifically, this document defines a reporting schema that covers
200 failures in routing, DNS resolution, and STARTTLS negotiation; policy
201 validation errors for both DANE [RFC6698] and MTA-STS [RFC8461]; and
202 a standard TXT record that recipient domains can use to indicate
203 where reports in this format should be sent. The report can also
204 serve as a heartbeat to indicate that systems are successfully
205 negotiating TLS during sessions as expected.
207 This document is intended as a companion to the specification for
208 SMTP MTA-STS [RFC8461] and adds reporting abilities for those
209 implementing DANE [RFC7672].
213 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
214 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
215 "OPTIONAL" in this document are to be interpreted as described in
216 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
217 capitals, as shown here.
226Margolis, et al. Standards Track [Page 4]
228RFC 8460 SMTP TLS Reporting September 2018
231 We also define the following terms for further use in this document:
233 o MTA-STS Policy: A mechanism by which administrators can specify
234 the expected TLS availability, presented identity, and desired
235 actions for a given email recipient domain. MTA-STS is defined in
238 o DANE Policy: A mechanism by which administrators can use DNSSEC to
239 commit an MTA to support STARTTLS and to publish criteria to be
240 used to validate its presented certificates. DANE for SMTP is
241 defined in [RFC7672], with the base specification defined in
242 [RFC6698] (and updated by [RFC7671]).
244 o TLSRPT (TLS Reporting) Policy: A policy specifying the endpoint to
245 which Sending MTAs should deliver reports.
247 o Policy Domain: The domain against which a TLSRPT, an MTA-STS, or a
248 DANE policy is defined. For TLSRPT and MTA-STS, this is typically
249 the same as the envelope recipient domain [RFC5321], but when mail
250 is routed to a "smarthost" gateway by local policy, the
252 Domain is the "TLSA base domain" of the receiving SMTP server as
253 described in Section 2.2.3 of RFC 7672 and Section 3 of RFC 6698.
255 o Sending MTA: The MTA initiating the relay of an email message.
257 o Aggregate Report URI (rua): A comma-separated list of locations
258 where the report is to be submitted.
260 o ABNF: Augmented Backus-Naur Form, a syntax for formally specifying
261 syntax, defined in [RFC5234] and [RFC7405].
2632. Related Technologies
265 o This document is intended as a companion to the specification for
266 SMTP MTA-STS [RFC8461].
268 o SMTP TLSRPT defines a mechanism for sending domains that are
269 compatible with MTA-STS or DANE to share success and failure
270 statistics with recipient domains. DANE is defined in [RFC6698],
271 and MTA-STS is defined in [RFC8461].
282Margolis, et al. Standards Track [Page 5]
284RFC 8460 SMTP TLS Reporting September 2018
289 A domain publishes a record to its DNS indicating that it wishes to
290 receive reports. These SMTP TLSRPT policies are distributed via DNS
291 from the Policy Domain's zone as TXT records (similar to Domain-based
292 Message Authentication, Reporting, and Conformance (DMARC) policies)
293 under the name "_smtp._tls". For example, for the Policy Domain
294 "example.com", the recipient's TLSRPT policy can be retrieved from
295 "_smtp._tls.example.com".
297 Policies consist of the following directives:
299 o "v": This document defines version 1 of TLSRPT, for which this
300 value MUST be equal to "TLSRPTv1". Other versions may be defined
303 o "rua": A URI specifying the endpoint to which aggregate
304 information about policy validation results should be sent (see
305 Section 4, "Reporting Schema", for more information). Two URI
306 schemes are supported: "mailto" and "https". As with DMARC
307 [RFC7489], the Policy Domain can specify a comma-separated list of
311 [RFC7231] to the specified URI. Report submitters MAY ignore
312 certificate validation errors when submitting reports via HTTPS
315 o In the case of "mailto", reports should be submitted to the
319 next report. This may mean that the reports are delivered
321 DomainKeys Identified Mail (DKIM) [RFC6376] signature by the
323 ignored by the recipient. DKIM signatures MUST NOT use the "l="
324 attribute to limit the body length used in the signature. This
325 ensures attackers cannot append extraneous or misleading data to a
327 contain the appropriate service type declaration, "s=tlsrpt". If
328 not present, the receiving system MAY ignore reports lacking that
333 dkim_selector._domainkey.example.com TXT
334 "v=DKIM1;k=rsa;s=tlsrpt;p=Mlf4qwSZfase4fa=="
338Margolis, et al. Standards Track [Page 6]
340RFC 8460 SMTP TLS Reporting September 2018
343 The formal definition of the "_smtp._tls" TXT record, defined using
344 [RFC5234] and [RFC7405], is as follows:
346 tlsrpt-record = tlsrpt-version 1*(field-delim tlsrpt-field)
349 field-delim = *WSP ";" *WSP
351 tlsrpt-field = tlsrpt-rua / ; Note that the
352 tlsrpt-extension ; tlsrpt-rua record is
355 tlsrpt-version = %s"v=TLSRPTv1"
357 tlsrpt-rua = %s"rua="
361 ; "URI" is imported from [RFC3986];
362 ; commas (ASCII 0x2C), exclamation
363 ; points (ASCII 0x21), and semicolons
364 ; (ASCII 0x3B) MUST be encoded
366 tlsrpt-extension = tlsrpt-ext-name "=" tlsrpt-ext-value
369 DIGIT / "_" / "-" / ".")
372 ; chars excluding "=", ";", SP, and control
376 resolver, records that do not begin with "v=TLSRPTv1;" are discarded.
377 If the number of resulting records is not one, senders MUST assume
378 the recipient domain does not implement TLSRPT. If the resulting TXT
379 record contains multiple strings (as described in Section 3.3 of
380 [RFC7208]), then the record MUST be treated as if those strings are
381 concatenated without adding spaces.
384 there exists more than one, the reporter MAY attempt to deliver to
385 each of the supported rua destinations. A receiver MAY opt to only
386 attempt delivery to one of the endpoints; however, the report SHOULD
387 NOT be considered successfully delivered until one of the endpoints
388 accepts delivery of the report.
394Margolis, et al. Standards Track [Page 7]
396RFC 8460 SMTP TLS Reporting September 2018
400 valid key/value pairs separated by semicolons) and implement a
401 superset of this specification, in which case unknown fields SHALL be
4043.1. Example Reporting Policy
4063.1.1. Report Using MAILTO
408 _smtp._tls.example.com. IN TXT \
409 "v=TLSRPTv1;rua=mailto:reports@example.com"
4113.1.2. Report Using HTTPS
413 _smtp._tls.example.com. IN TXT \
415 rua=https://reporting.example.com/v1/tlsrpt"
419 The report is composed as a plaintext file encoded in the Internet
420 JSON (I-JSON) format [RFC7493].
422 Aggregate reports contain the following fields:
426 * The organization responsible for the report
428 * Contact information for one or more responsible parties for the
429 contents of the report
431 * A unique identifier for the report
433 * The reporting date range for the report
435 o Policy, consisting of:
438 applied (as a string), (2) the DANE TLSA record applied (as a
439 string, with each RR entry of the RRset listed and separated by
443 * The domain for which the policy is applied
450Margolis, et al. Standards Track [Page 8]
452RFC 8460 SMTP TLS Reporting September 2018
455 o Aggregate counts, comprising result type, Sending MTA IP,
456 receiving MTA hostname, session count, and an optional additional
457 information field containing a URI for recipients to review
458 further information on a failure type.
460 Note that the failure types are non-exclusive; an aggregate report
461 may contain overlapping "counts" of failure types when a single send
462 attempt encountered multiple errors. Reporters may report multiple
464 record for the same domain and MX). Because of this, even in the
465 case where only a single policy was applied, the "policies" field of
466 the report body MUST be an array and not a singular value.
468 In the case of multiple failure types, the "failure-details" array
469 would contain multiple entries. Each entry would have its own set of
470 information pertaining to that failure type.
4724.1. Report Time Frame
475 should allow for easier correlation of failure events. To avoid
476 unintentionally overloading the system processing the reports, the
477 reports should be delivered after some delay, perhaps several hours.
482 func generate_sleep_delay() {
485 rand = random(min_delay, max_delay)
489 func generate_report(policy_domain) {
490 do_rpt_work(policy_domain)
491 send_rpt(policy_domain)
494 func generate_tlsrpt() {
495 sleep(generate_sleep_delay())
496 for policy_domain in list_of_tlsrpt_enabled_domains {
497 generate_report(policy_domain)
506Margolis, et al. Standards Track [Page 9]
508RFC 8460 SMTP TLS Reporting September 2018
516 MTA was able to successfully negotiate a policy-compliant TLS
517 connection and serves to provide a "heartbeat" to receiving
518 domains that signifies reporting is functional and tabulating
519 correctly. This field contains an aggregate count of successful
520 connections for the reporting system.
525 was unable to successfully establish a connection with the
526 receiving platform. Section 4.3, "Result Types", will elaborate
527 on the failed negotiation attempts. This field contains an
528 aggregate count of failed connections.
532 The list of result types will start with the minimal set below and is
533 expected to grow over time based on real-world experience. The
534 initial set is outlined in Sections 4.3.1 to 4.3.4:
5364.3.1. Negotiation Failures
539 not support STARTTLS.
542 presented did not adhere to the constraints specified in the MTA-
543 STS or DANE policy, e.g., if the MX hostname does not match any
544 identities listed in the subject alternative name (SAN) [RFC5280].
550 certificate-related failures that include, but are not limited to,
551 errors such as untrusted/unknown certification authorities (CAs),
552 certificate name constraints, certificate chain errors, etc. When
553 using this declaration, the reporting MTA SHOULD utilize the
554 "failure-reason-code" to provide more information to the receiving
562Margolis, et al. Standards Track [Page 10]
564RFC 8460 SMTP TLS Reporting September 2018
568 reason not matching a category above. When using this
569 declaration, the reporting MTA SHOULD utilize the "failure-reason-
570 code" to provide more information to the receiving entity.
5724.3.2. Policy Failures
5744.3.2.1. DANE-Specific Policy Failures
577 record associated with a DANE policy. None of the records in the
578 RRset were found to be valid.
581 returned from the recursive resolver.
583 o "dane-required": This indicates that the sending system is
584 configured to require DANE TLSA records for all the MX hosts of
585 the destination domain, but no DNSSEC-validated TLSA records were
586 present for the MX host that is the subject of the report.
587 Mandatory DANE for SMTP is described in Section 6 of [RFC7672].
588 Such policies may be created by mutual agreement between two
589 organizations that frequently exchange sensitive content via
5924.3.2.2. MTA-STS-specific Policy Failures
595 MTA-STS policy, for example, because the policy host is
599 overall MTA-STS Policy.
602 not be authenticated using PKIX validation.
6044.3.3. General Failures
606 When a negotiation failure cannot be categorized into one of the
607 "Negotiation Failures" stated above, the reporter SHOULD use the
608 "validation-failure" category. As TLS grows and becomes more
609 complex, new mechanisms may not be easily categorized. This allows
611 reporter SHOULD also use "failure-reason-code" to give some feedback
612 to the receiving entity. This is intended to be a short text field,
613 and the contents of the field should be an error code or error text,
614 such as "X509_V_ERR_UNHANDLED_CRITICAL_CRL_EXTENSION".
618Margolis, et al. Standards Track [Page 11]
620RFC 8460 SMTP TLS Reporting September 2018
6234.3.4. Transient Failures
626 not required to be reported.
630 The JSON schema is derived from the HTTP Public Key Pinning (HPKP)
631 JSON schema; see Section 3 of [RFC7469].
634 "organization-name": organization-name,
636 "start-datetime": date-time,
637 "end-datetime": date-time
639 "contact-info": email-address,
640 "report-id": report-id,
643 "policy-type": policy-type,
644 "policy-string": policy-string,
645 "policy-domain": domain,
646 "mx-host": mx-host-pattern
649 "total-successful-session-count": total-successful-session-count,
650 "total-failure-session-count": total-failure-session-count
654 "result-type": result-type,
655 "sending-mta-ip": ip-address,
656 "receiving-mx-hostname": receiving-mx-hostname,
657 "receiving-mx-helo": receiving-mx-helo,
658 "receiving-ip": receiving-ip,
659 "failed-session-count": failed-session-count,
660 "additional-information": additional-info-uri,
661 "failure-reason-code": failure-reason-code
674Margolis, et al. Standards Track [Page 12]
676RFC 8460 SMTP TLS Reporting September 2018
679 o "organization-name": The name of the organization responsible for
680 the report. It is provided as a string.
683 the report range. It is provided as a string formatted according
684 to "Internet Date/Time Format", Section 5.6 of [RFC3339]. The
685 report should be for a full UTC day, 00:00-24:00.
687 o "email-address": The contact information for the party responsible
688 for the report. It is provided as a string formatted according to
689 "Addr-Spec Specification", Section 3.4.1 of [RFC5322].
692 may use whatever scheme they prefer to generate a unique
693 identifier. It is provided as a string.
695 o "policy-type": The type of policy that was applied by the sending
696 domain. Presently, the only three valid choices are "tlsa",
700 o "policy-string": An encoding of the applied policy as a JSON array
701 of strings, whether it's a TLSA record ([RFC6698], Section 2.3) or
702 an MTA-STS Policy. Examples follow in the next section.
704 o "domain": The Policy Domain against which the MTA-STS or DANE
705 policy is defined. In the case of Internationalized Domain Names
706 [RFC5891], the domain MUST consist of the Punycode-encoded
707 A-labels [RFC3492] and not the U-labels.
709 o "mx-host-pattern": In the case where "policy-type" is "sts", it's
710 the pattern of MX hostnames from the applied policy. It is
711 provided as a JSON array of strings and is interpreted in the same
712 manner as the rules in "MX Host Validation"; see Section 4.1 of
713 [RFC8461]. In the case of Internationalized Domain Names
714 [RFC5891], the domain MUST consist of the Punycode-encoded
715 A-labels [RFC3492] and not the U-labels.
717 o "result-type": A value from Section 4.3, "Result Types", above.
720 STARTTLS connection. It is provided as a string representation of
721 an IPv4 (see below) or IPv6 [RFC5952] address in dot-decimal or
722 colon-hexadecimal notation.
724 o "receiving-mx-hostname": The hostname of the receiving MTA MX
725 record with which the Sending MTA attempted to negotiate a
730Margolis, et al. Standards Track [Page 13]
732RFC 8460 SMTP TLS Reporting September 2018
735 o "receiving-mx-helo" (optional): The HELLO (HELO) or Extended HELLO
736 (EHLO) string from the banner announced during the reported
739 o "receiving-ip": The destination IP address that was used when
740 creating the outbound session. It is provided as a string
741 representation of an IPv4 (see below) or IPv6 [RFC5952] address in
742 dot-decimal or colon-hexadecimal notation.
744 o "total-successful-session-count": The aggregate count (an integer,
745 encoded as a JSON number) of successfully negotiated TLS-enabled
746 connections to the receiving site.
748 o "total-failure-session-count": The aggregate count (an integer,
749 encoded as a JSON number) of failures to negotiate a TLS-enabled
750 connection to the receiving site.
752 o "failed-session-count": The number of (attempted) sessions that
753 match the relevant "result-type" for this section (an integer,
754 encoded as a JSON number).
756 o "additional-info-uri" (optional): A URI [RFC3986] that points to
757 additional information around the relevant "result-type". For
758 example, this URI might host the complete certificate chain
759 presented during an attempted STARTTLS session.
761 o "failure-reason-code": A text field to include a TLS-related error
762 code or error message.
764 For report purposes, an IPv4 address is defined via the following
767 IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet
768 dec-octet = DIGIT ; 0-9
769 / %x31-39 DIGIT ; 10-99
770 / "1" 2DIGIT ; 100-199
771 / "2" %x30-34 DIGIT ; 200-249
772 / "25" %x30-35 ; 250-255
774 And an IPv6 address is defined via the following ABNF:
777 IPv6address = <as defined in [RFC5954]>
786Margolis, et al. Standards Track [Page 14]
788RFC 8460 SMTP TLS Reporting September 2018
793 Part of the report body includes the policy that is applied when
794 attempting relay to the destination.
796 For DANE TLSA policies, this is a JSON array of strings each
797 representing the RDATA of a single TLSA resource record as a space-
798 separated list of its four TLSA fields; the fields are in
799 presentation format (defined in [RFC6698], Section 2.2) with no
800 internal spaces or grouping parentheses:
803 "3 0 1 1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513
805 "3 0 1 12350A337E6DB9C6123522D136A475638CC43E1ED424F8EEC8513
809 For MTA-STS policies, this is an array of JSON strings that
810 represents the policy that is declared by the receiving site,
811 including any errors that may be present. Note that where there are
812 multiple "mx" values, they must be listed as separate "mx" elements
813 in the policy array rather than as a single nested "mx" sub-array.
818 "mx: mx1.example.com",
819 "mx: mx2.example.com",
820 "mx: mx.backup-example.com",
826 Reports can be delivered either via SMTP (as an email message) or via
842Margolis, et al. Standards Track [Page 15]
844RFC 8460 SMTP TLS Reporting September 2018
852 filename = sender "!" policy-domain "!" begin-timestamp
853 "!" end-timestamp [ "!" unique-id ] "." extension
855 unique-id = 1*(ALPHA / DIGIT)
857 sender = domain ; from [RFC5321] -- this is used
858 ; as the domain for the `contact-info`
859 ; address in the report body.
860 ; In the case of Internationalized Domain
861 ; Names [RFC5891], the domain MUST consist of
862 ; the Punycode-encoded A-labels [RFC3492] and
865 policy-domain = domain
866 ; In the case of Internationalized Domain
867 ; Names [RFC5891], the domain MUST consist of
868 ; the Punycode-encoded A-labels [RFC3492] and
871 begin-timestamp = 1*DIGIT
872 ; seconds since 00:00:00 UTC January 1, 1970
873 ; indicating start of the time range contained
876 end-timestamp = 1*DIGIT
877 ; seconds since 00:00:00 UTC January 1, 1970
878 ; indicating end of the time range contained
881 extension = "json" / "json.gz"
884 The extension MUST be "json" for a plain JSON file or "json.gz" for a
885 JSON file compressed using gzip.
887 "unique-id" allows an optional unique ID generated by the Sending MTA
888 to distinguish among multiple reports generated simultaneously by
889 different sources for the same Policy Domain. For example, this is a
890 possible filename for a compressed report to the Policy Domain
891 "example.net" from the Sending MTA "mail.sndr.example.com":
893 "mail.sndr.example.com!example.net!1470013207!1470186007!001.json.gz"
898Margolis, et al. Standards Track [Page 16]
900RFC 8460 SMTP TLS Reporting September 2018
906 email and HTTPS transport. Declining to apply compression can cause
907 the report to be too large for a receiver to process (a commonly
908 observed receiver limit is ten megabytes); compressing the file
909 increases the chances of acceptance of the report at some
914 The report MAY be delivered by email. To make the reports machine-
915 parsable for the receivers, we define a top-level media type
918 typically "text/plain", and the second part is machine readable with
919 a new media type defined called "application/tlsrpt+json". If
920 compressed, the report should use the media type "application/
923 In addition, the following two new top-level message header fields
928 "TLS-Report-Submitter: Sender-Domain"
930 The "TLS-Report-Submitter" value MUST match the value found in the
931 domain [RFC5321] of the "contact-info" from the report body. These
932 message header fields MUST be included and should allow for easy
933 searching for all reports submitted by a reporting domain or a
934 particular submitter, for example, in IMAP [RFC3501]:
936 "s SEARCH HEADER "TLS-Report-Domain" "example.com""
938 It is presumed that the aggregate reporting address will be equipped
939 to process new message header fields and extract MIME parts with the
941 additional headers SHOULD be included in the DKIM [RFC6376] signature
954Margolis, et al. Standards Track [Page 17]
956RFC 8460 SMTP TLS Reporting September 2018
962 tlsrpt-subject = %s"Report" FWS ; "Report"
963 %s"Domain:" FWS ; "Domain:"
964 domain-name FWS ; per [RFC6376]
965 %s"Submitter:" FWS ; "Submitter:"
966 domain-name FWS ; per [RFC6376]
967 %s"Report-ID:" FWS ; "Report-ID:
969 [CFWS] ; per [RFC5322]
972 The first domain-name indicates the DNS domain name about which the
973 report was generated. The second domain-name indicates the DNS
974 domain name representing the Sending MTA generating the report. The
975 purpose of the "Report-ID:" portion of the field is to enable the
976 Policy Domain to identify and ignore duplicate reports that might be
977 sent by a Sending MTA.
979 For instance, this is a possible Subject field for a report to the
980 Policy Domain "example.net" from the Sending MTA
981 "mail.sender.example.com". It is line-wrapped as allowed by
984 Subject: Report Domain: example.net
985 Submitter: mail.sender.example.com
986 Report-ID: <735ff.e317+bf22029@mailexample.net>
1010Margolis, et al. Standards Track [Page 18]
1012RFC 8460 SMTP TLS Reporting September 2018
1018 Date: Fri, May 09 2017 16:54:30 -0800
1019 To: mts-sts-tlsrpt@example.net
1020 Subject: Report Domain: example.net
1021 Submitter: mail.sender.example.com
1022 Report-ID: <735ff.e317+bf22029@example.net>
1023 TLS-Report-Domain: example.net
1024 TLS-Report-Submitter: mail.sender.example.com
1026 Content-Type: multipart/report; report-type="tlsrpt";
1027 boundary="----=_NextPart_000_024E_01CC9B0A.AFE54C00"
1028 Content-Language: en-us
1030 This is a multipart message in MIME format.
1032 ------=_NextPart_000_024E_01CC9B0A.AFE54C00
1033 Content-Type: text/plain; charset="us-ascii"
1034 Content-Transfer-Encoding: 7bit
1036 This is an aggregate TLS report from mail.sender.example.com
1038 ------=_NextPart_000_024E_01CC9B0A.AFE54C00
1039 Content-Type: application/tlsrpt+gzip
1040 Content-Transfer-Encoding: base64
1041 Content-Disposition: attachment;
1042 filename="mail.sender.example!example.com!
1043 1013662812!1013749130.json.gz"
1045 <gzipped content of report>
1047 ------=_NextPart_000_024E_01CC9B0A.AFE54C00--
1051 NOT honor MTA-STS or DANE TLSA failures.
1056 report SHOULD use the media type "application/tlsrpt+gzip"; otherwise
1057 it SHOULD use the media type "application/tlsrpt+json" (see
1058 Section 6, "IANA Considerations").
1060 The receiving system MUST return a "successful" response from its
1061 HTTPS server, typically a 200 or 201 HTTP code [RFC7231]. Other
1062 codes could indicate a delivery failure and may be retried as per
1066Margolis, et al. Standards Track [Page 19]
1068RFC 8460 SMTP TLS Reporting September 2018
1071 local sender policy. The receiving system is not expected to process
1072 reports at receipt time and MAY store them for processing at a later
1078 method, a sender SHOULD attempt redelivery for up to 24 hours after
1079 the initial attempt. As previously stated, the reports are optional,
1080 so while it is ideal to attempt redelivery, it is not required. If
1081 multiple retries are attempted, ideally they SHOULD be done with
1082 exponential backoff.
10845.6. Metadata Variances
1086 As stated above, there are a variable number of ways to declare
1087 information about the data therein. If any of the items declared via
1088 subject or filename disagree with the report, the report MUST be
1089 considered the authoritative source.
10916. IANA Considerations
1093 The following are the IANA considerations discussed in this document.
1097 Below is the Internet Assigned Numbers Authority (IANA) Permanent
1098 Message Header Field registration information per [RFC3864].
1100 Header field name: TLS-Report-Domain
1101 Applicable protocol: mail
1103 Author/Change controller: IETF
1104 Specification document(s): RFC 8460
1107 Header field name: TLS-Report-Submitter
1108 Applicable protocol: mail
1110 Author/Change controller: IETF
1111 Specification document(s): RFC 8460
1122Margolis, et al. Standards Track [Page 20]
1124RFC 8460 SMTP TLS Reporting September 2018
1129 This document creates a new registry for the "report-type" parameter
1130 to the Content-Type header field for the "multipart/report" top-level
1131 media type defined in [RFC6522].
1133 The registry name is "Report Type Registry", and the procedure for
1134 updating the registry will be "Specification Required" [RFC8126].
1136 An entry in this registry should contain:
1138 o the report-type being registered
1140 o one or more registered media types that can be used with this
1143 o the document containing the registration action
1145 o an optional comment
1147 The initial entries are:
1150 Media Type: application/tlsrpt+gzip, application/tlsrpt+json
1151 Registered By: [RFC8460]
1152 Comment: Media types suitable for use with this report-type are
1153 defined in Sections 6.4 and 6.5 of [RFC8460]
1155 Report-Type: disposition-notification
1156 Media Type: message/disposition-notification
1157 Registered By: [RFC8098], Section 10
1159 Report-Type: disposition-notification
1160 Media Type: message/global-disposition-notification
1161 Registered By: [RFC6533], Section 6
1163 Report-Type: delivery-status
1164 Media Type: message/delivery-status
1165 Registered By: [RFC3464], Section 6.2
1167 Report-Type: delivery-status
1168 Media Type: message/global-delivery-status
1169 Registered By: [RFC6533], Section 6
1178Margolis, et al. Standards Track [Page 21]
1180RFC 8460 SMTP TLS Reporting September 2018
11836.3. +gzip Media Type Suffix
1185 This document registers a new media type suffix "+gzip". The gzip
1186 format is a public domain, cross-platform, interoperable file storage
1187 and transfer format, specified in [RFC1952]; it supports compression
1188 and is used as the underlying representation by a variety of file
1189 formats. The media type "application/gzip" has been registered for
1190 such files. The suffix "+gzip" MAY be used with any media type whose
1191 representation follows that established for "application/gzip". The
1192 registration form for the structured syntax suffix for use with media
1193 types is as follows:
1195 Type name: gzip file storage and transfer format.
1199 References: [RFC1952] [RFC6713]
1201 Encoding considerations: gzip is a binary encoding.
1203 Fragment identifier considerations: The syntax and semantics of
1204 fragment identifiers specified for +gzip SHOULD be as specified for
1205 "application/gzip". (At publication of this document, there is no
1206 fragment identification syntax defined for "application/gzip".) The
1207 syntax and semantics for fragment identifiers for a specific "xxx/
1208 yyy+gzip" SHOULD be processed as follows:
1210 For cases defined in +gzip, where the fragment identifier
1211 resolves per the +gzip rules, process as specified in
1214 For cases defined in +gzip, where the fragment identifier does
1215 not resolve per the +gzip rules, process as specified in
1218 For cases not defined in +gzip, process as specified in
1221 Interoperability considerations: N/A
1223 Security considerations: gzip format doesn't provide confidentiality
1224 protection. Integrity protection is provided by an Adler-32
1225 checksum, which is not cryptographically strong. See also the
1226 security considerations of [RFC6713]. Each individual media type
1227 registered with a +gzip suffix can have additional security
1228 considerations. Additionally, gzip objects can contain multiple
1234Margolis, et al. Standards Track [Page 22]
1236RFC 8460 SMTP TLS Reporting September 2018
1239 files and associated paths. File paths must be validated when the
1240 files are extracted; a malicious file path could otherwise cause the
1241 extractor to overwrite application or system files.
1243 Contact: art@ietf.org
1245 Author/Change controller: Internet Engineering Task Force
12486.4. application/tlsrpt+json Media Type
1250 This document registers multiple media types, beginning with Table 1
1253 +-------------+----------------+-------------+-------------------+
1254 | Type | Subtype | File Ext | Specification |
1255 +-------------+----------------+-------------+-------------------+
1256 | application | tlsrpt+json | .json | Section 5.3 |
1257 +-------------+----------------+-------------+-------------------+
1259 Table 1: SMTP TLS Reporting Media Type
1261 Type name: application
1263 Subtype name: tlsrpt+json
1265 Required parameters: N/A
1267 Optional parameters: N/A
1269 Encoding considerations: Encoding considerations are identical to
1270 those specified for the "application/json" media type. See
1273 Security considerations: Security considerations relating to SMTP TLS
1274 Reporting are discussed in Section 7.
1276 Interoperability considerations: This document specifies the format
1277 of conforming messages and the interpretation thereof.
1279 Published specification: Section 5.3 of RFC 8460.
1281 Applications that use this media type: Mail User Agents (MUAs) and
1282 Mail Transfer Agents.
1290Margolis, et al. Standards Track [Page 23]
1292RFC 8460 SMTP TLS Reporting September 2018
1295 Additional information:
1297 Deprecated alias names for this type: N/A
1299 Magic number(s): N/A
1301 File extension(s): ".json"
1303 Macintosh file type code(s): N/A
1305 Person & email address to contact for further information:
1306 See the Authors' Addresses section.
1308 Intended usage: COMMON
1310 Restrictions on usage: N/A
1312 Author: See the Authors' Addresses section.
1314 Change controller: Internet Engineering Task Force (iesg@ietf.org).
13166.5. application/tlsrpt+gzip Media Type
1318 +-------------+----------------+-------------+-------------------+
1319 | Type | Subtype | File Ext | Specification |
1320 +-------------+----------------+-------------+-------------------+
1321 | application | tlsrpt+gzip | .gz | Section 5.3 |
1322 +-------------+----------------+-------------+-------------------+
1324 Table 2: SMTP TLS Reporting Media Type
1326 Type name: application
1328 Subtype name: tlsrpt+gzip
1330 Required parameters: N/A
1332 Optional parameters: N/A
1334 Encoding considerations: Binary
1336 Security considerations: Security considerations relating to SMTP TLS
1337 Reporting are discussed in Section 7. Security considerations
1338 related to gzip compression are discussed in RFC 6713.
1340 Interoperability considerations: This document specifies the format
1341 of conforming messages and the interpretation thereof.
1346Margolis, et al. Standards Track [Page 24]
1348RFC 8460 SMTP TLS Reporting September 2018
1351 Published specification: Section 5.3 of RFC 8460.
1353 Applications that use this media type: Mail User Agents (MUAs) and
1354 Mail Transfer Agents.
1356 Additional information:
1358 Deprecated alias names for this type: N/A
1360 Magic number(s): The first two bytes are 0x1f, 0x8b.
1362 File extension(s): ".gz"
1364 Macintosh file type code(s): N/A
1366 Person & email address to contact for further information:
1367 See the Authors' Addresses section.
1369 Intended usage: COMMON
1371 Restrictions on usage: N/A
1373 Author: See the Authors' Addresses section.
1375 Change controller: Internet Engineering Task Force (iesg@ietf.org).
1379 This document creates a new registry, "STARTTLS Validation Result
1380 Types". The initial entries in the registry are:
1382 +-----------------------------+--------------+
1383 | Result Type | Description |
1384 +-----------------------------+--------------+
1385 | starttls-not-supported | Section 4.3 |
1386 | certificate-host-mismatch | Section 4.3 |
1387 | certificate-expired | Section 4.3 |
1388 | tlsa-invalid | Section 4.3 |
1389 | dnssec-invalid | Section 4.3 |
1390 | dane-required | Section 4.3 |
1391 | certificate-not-trusted | Section 4.3 |
1392 | sts-policy-invalid | Section 4.3 |
1393 | sts-webpki-invalid | Section 4.3 |
1394 | validation-failure | Section 4.3 |
1395 | sts-policy-fetch-error | Section 4.3 |
1396 +-----------------------------+--------------+
1402Margolis, et al. Standards Track [Page 25]
1404RFC 8460 SMTP TLS Reporting September 2018
1407 The above entries are described in Section 4.3, "Result Types". New
1408 result types can be added to this registry using the "Expert Review"
1409 IANA registration policy.
14117. Security Considerations
1413 SMTP TLS Reporting provides visibility into misconfigurations or
1414 attempts to intercept or tamper with mail between hosts who support
1415 STARTTLS. There are several security risks presented by the
1416 existence of this reporting channel:
1418 o Flooding of the Aggregate Report URI (rua) endpoint: An attacker
1419 could flood the endpoint with excessive reporting traffic and
1420 prevent the receiving domain from accepting additional reports.
1421 This type of Denial-of-Service attack would limit visibility into
1422 STARTTLS failures, leaving the receiving domain blind to an
1425 o Untrusted content: An attacker could inject malicious code into
1426 the report, exploiting any vulnerabilities in the report-handling
1427 systems of the receiving domain. Implementers are advised to take
1428 precautions against evaluating the contents of the report.
1430 o Report snooping: An attacker could create a bogus TLSRPT record to
1431 receive statistics about a domain the attacker does not own.
1432 Since an attacker that is able to poison DNS is already able to
1433 receive counts of SMTP connections (and, absent DANE or MTA-STS
1434 policies, actual SMTP message payloads), this does not present a
1435 significant new vulnerability.
1437 o Ignoring HTTPS validation when submitting reports: When reporting
1438 benign misconfigurations, it is likely that a misconfigured SMTP
1439 server may also mean a misconfigured HTTPS server; as a result,
1440 reporters who require HTTPS validity on the reporting endpoint may
1441 fail to alert administrators about such misconfigurations.
1442 Conversely, in the event of an actual attack, an attacker who
1443 wishes to create a gap in reporting and could intercept HTTPS
1444 reports could, just as easily, simply thwart the resolution of the
1445 TLSRPT TXT record or establishment of the TCP session to the HTTPS
1446 endpoint. Furthermore, such a man-in-the-middle attacker could
1447 discover most or all of the metadata exposed in a report merely
1448 through passive observation. As a result, we consider the risks
1449 of failure to deliver reports on misconfigurations to outweigh
1450 those of attackers intercepting reports.
1458Margolis, et al. Standards Track [Page 26]
1460RFC 8460 SMTP TLS Reporting September 2018
1464 reports that are outside the authority of the Policy Domain, which
1465 allows domains to delegate processing of reports to a partner
1466 organization. However, an attacker who controls the Policy Domain
1467 DNS could also use this mechanism to direct the reports to an
1468 unwitting victim, flooding that victim with excessive reports.
1469 DMARC [RFC7489] defines a solution for verifying delegation to
1470 avoid such attacks; the need for this is greater with DMARC,
1471 however, because DMARC allows an attacker to trigger reports to a
1472 target from an innocent third party by sending mail to that third
1473 party (which triggers a report from the third party to the
1474 target). In the case of TLSRPT, the attacker would have to induce
1475 the third party to send mail to the attacker in order to trigger
1476 reports from the third party to the victim; this reduces the risk
1477 of such an attack and the need for a verification mechanism.
1479 Finally, because TLSRPT is intended to help administrators discover
1480 man-in-the-middle attacks against transport-layer encryption,
1481 including attacks designed to thwart negotiation of encrypted
1482 connections (by downgrading opportunistic encryption or, in the case
1483 of MTA-STS, preventing discovery of a new MTA-STS Policy), we must
1484 also consider the risk that an adversary who can induce such a
1485 downgrade attack can also prevent discovery of the TLSRPT TXT record
1486 (and thus prevent discovery of the successful downgrade attack).
1487 Administrators are thus encouraged to deploy TLSRPT TXT records with
1488 a large TTL (reducing the window for successful application of
1489 transient attacks against DNS resolution of the record) or to deploy
1490 DNSSEC on the deploying zone.
14928. Privacy Considerations
1494 MTAs are generally considered public knowledge; however, the
1495 internals of how those MTAs are configured and the users of those
1496 MTAs may not be as public. It should be noted that providing a
1497 receiving site with information about TLS failures may reveal
1498 information about the sender's configuration or even information
1499 about the senders themselves. For example, sending a report may
1500 disclose what TLS implementation the sender uses, as the inability to
1501 negotiate a session may be a known incompatibility between two
1502 implementations. This may, indirectly, leak information on the
1503 reporter's operating system or even region, if, for example, a rare
1504 TLS implementation is popular among certain users or in certain
1514Margolis, et al. Standards Track [Page 27]
1516RFC 8460 SMTP TLS Reporting September 2018
15219.1. Normative References
1523 [RFC1952] Deutsch, P., "GZIP file format specification version 4.3",
1524 RFC 1952, DOI 10.17487/RFC1952, May 1996,
1525 <https://www.rfc-editor.org/info/rfc1952>.
1527 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1528 Requirement Levels", BCP 14, RFC 2119,
1529 DOI 10.17487/RFC2119, March 1997,
1530 <https://www.rfc-editor.org/info/rfc2119>.
1532 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
1533 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
1534 <https://www.rfc-editor.org/info/rfc3339>.
1536 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
1537 for Internationalized Domain Names in Applications
1538 (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003,
1539 <https://www.rfc-editor.org/info/rfc3492>.
1541 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
1542 Resource Identifier (URI): Generic Syntax", STD 66,
1543 RFC 3986, DOI 10.17487/RFC3986, January 2005,
1544 <https://www.rfc-editor.org/info/rfc3986>.
1546 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
1547 Specifications: ABNF", STD 68, RFC 5234,
1548 DOI 10.17487/RFC5234, January 2008,
1549 <https://www.rfc-editor.org/info/rfc5234>.
1551 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
1552 Housley, R., and W. Polk, "Internet X.509 Public Key
1553 Infrastructure Certificate and Certificate Revocation List
1554 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
1555 <https://www.rfc-editor.org/info/rfc5280>.
1557 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
1558 DOI 10.17487/RFC5321, October 2008,
1559 <https://www.rfc-editor.org/info/rfc5321>.
1561 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
1562 DOI 10.17487/RFC5322, October 2008,
1563 <https://www.rfc-editor.org/info/rfc5322>.
1570Margolis, et al. Standards Track [Page 28]
1572RFC 8460 SMTP TLS Reporting September 2018
1575 [RFC5891] Klensin, J., "Internationalized Domain Names in
1576 Applications (IDNA): Protocol", RFC 5891,
1577 DOI 10.17487/RFC5891, August 2010,
1578 <https://www.rfc-editor.org/info/rfc5891>.
1580 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
1581 Address Text Representation", RFC 5952,
1582 DOI 10.17487/RFC5952, August 2010,
1583 <https://www.rfc-editor.org/info/rfc5952>.
1585 [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
1586 URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010,
1587 <https://www.rfc-editor.org/info/rfc6068>.
1589 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
1590 "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
1591 RFC 6376, DOI 10.17487/RFC6376, September 2011,
1592 <https://www.rfc-editor.org/info/rfc6376>.
1594 [RFC6522] Kucherawy, M., Ed., "The Multipart/Report Media Type for
1595 the Reporting of Mail System Administrative Messages",
1596 STD 73, RFC 6522, DOI 10.17487/RFC6522, January 2012,
1597 <https://www.rfc-editor.org/info/rfc6522>.
1599 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
1600 of Named Entities (DANE) Transport Layer Security (TLS)
1601 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
1602 2012, <https://www.rfc-editor.org/info/rfc6698>.
1604 [RFC6713] Levine, J., "The 'application/zlib' and 'application/gzip'
1605 Media Types", RFC 6713, DOI 10.17487/RFC6713, August 2012,
1606 <https://www.rfc-editor.org/info/rfc6713>.
1608 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
1609 Authorizing Use of Domains in Email, Version 1", RFC 7208,
1610 DOI 10.17487/RFC7208, April 2014,
1611 <https://www.rfc-editor.org/info/rfc7208>.
1613 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1614 Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
1615 DOI 10.17487/RFC7231, June 2014,
1616 <https://www.rfc-editor.org/info/rfc7231>.
1618 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
1619 RFC 7405, DOI 10.17487/RFC7405, December 2014,
1620 <https://www.rfc-editor.org/info/rfc7405>.
1626Margolis, et al. Standards Track [Page 29]
1628RFC 8460 SMTP TLS Reporting September 2018
1631 [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
1632 DOI 10.17487/RFC7493, March 2015,
1633 <https://www.rfc-editor.org/info/rfc7493>.
1635 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based
1636 Authentication of Named Entities (DANE) Protocol: Updates
1637 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671,
1638 October 2015, <https://www.rfc-editor.org/info/rfc7671>.
1640 [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via
1641 Opportunistic DNS-Based Authentication of Named Entities
1642 (DANE) Transport Layer Security (TLS)", RFC 7672,
1643 DOI 10.17487/RFC7672, October 2015,
1644 <https://www.rfc-editor.org/info/rfc7672>.
1646 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1647 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1648 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
1650 [RFC8461] Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A.,
1651 and J. Jones, "SMTP MTA Strict Transport Security (MTA-
1652 STS)", RFC 8461, DOI 10.17487/RFC8461, September 2018,
1653 <https://www.rfc-editor.org/info/rfc8461>.
16559.2. Informative References
1657 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
1658 Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207,
1659 February 2002, <https://www.rfc-editor.org/info/rfc3207>.
1661 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format
1662 for Delivery Status Notifications", RFC 3464,
1663 DOI 10.17487/RFC3464, January 2003,
1664 <https://www.rfc-editor.org/info/rfc3464>.
1666 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
1667 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
1668 <https://www.rfc-editor.org/info/rfc3501>.
1670 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
1671 Procedures for Message Header Fields", BCP 90, RFC 3864,
1672 DOI 10.17487/RFC3864, September 2004,
1673 <https://www.rfc-editor.org/info/rfc3864>.
1675 [RFC6533] Hansen, T., Ed., Newman, C., and A. Melnikov,
1676 "Internationalized Delivery Status and Disposition
1677 Notifications", RFC 6533, DOI 10.17487/RFC6533, February
1678 2012, <https://www.rfc-editor.org/info/rfc6533>.
1682Margolis, et al. Standards Track [Page 30]
1684RFC 8460 SMTP TLS Reporting September 2018
1687 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
1688 Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
1689 December 2014, <https://www.rfc-editor.org/info/rfc7435>.
1691 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
1692 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April
1693 2015, <https://www.rfc-editor.org/info/rfc7469>.
1695 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
1696 Message Authentication, Reporting, and Conformance
1697 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
1698 <https://www.rfc-editor.org/info/rfc7489>.
1700 [RFC8098] Hansen, T., Ed. and A. Melnikov, Ed., "Message Disposition
1701 Notification", STD 85, RFC 8098, DOI 10.17487/RFC8098,
1702 February 2017, <https://www.rfc-editor.org/info/rfc8098>.
1704 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
1705 Writing an IANA Considerations Section in RFCs", BCP 26,
1706 RFC 8126, DOI 10.17487/RFC8126, June 2017,
1707 <https://www.rfc-editor.org/info/rfc8126>.
1738Margolis, et al. Standards Track [Page 31]
1740RFC 8460 SMTP TLS Reporting September 2018
1743Appendix A. Example Reporting Policy
1745A.1. Report Using MAILTO
1747 _smtp._tls.mail.example.com. IN TXT \
1748 "v=TLSRPTv1;rua=mailto:reports@example.com"
1750A.2. Report Using HTTPS
1752 _smtp._tls.mail.example.com. IN TXT \
1754 rua=https://reporting.example.com/v1/tlsrpt"
1758 Below is an example JSON report for messages from Company-X to
1759 Company-Y, where 100 sessions were attempted to Company-Y servers
1760 with an expired certificate, and 200 sessions were attempted to
1761 Company-Y servers that did not successfully respond to the "STARTTLS"
1762 command. Additionally, 3 sessions failed due to
1763 "X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED".
1766 "organization-name": "Company-X",
1768 "start-datetime": "2016-04-01T00:00:00Z",
1771 "contact-info": "sts-reporting@company-x.example",
1775 "policy-type": "sts",
1776 "policy-string": ["version: STSv1","mode: testing",
1777 "mx: *.mail.company-y.example","max_age: 86400"],
1778 "policy-domain": "company-y.example",
1782 "total-successful-session-count": 5326,
1783 "total-failure-session-count": 303
1785 "failure-details": [{
1786 "result-type": "certificate-expired",
1787 "sending-mta-ip": "2001:db8:abcd:0012::1",
1788 "receiving-mx-hostname": "mx1.mail.company-y.example",
1789 "failed-session-count": 100
1794Margolis, et al. Standards Track [Page 32]
1796RFC 8460 SMTP TLS Reporting September 2018
1799 "result-type": "starttls-not-supported",
1800 "sending-mta-ip": "2001:db8:abcd:0013::1",
1801 "receiving-mx-hostname": "mx2.mail.company-y.example",
1802 "receiving-ip": "203.0.113.56",
1803 "failed-session-count": 200,
1804 "additional-information": "https://reports.company-x.example/
1805 report_info ? id = 5065427 c - 23 d3# StarttlsNotSupported "
1807 "result-type": "validation-failure",
1808 "sending-mta-ip": "198.51.100.62",
1809 "receiving-ip": "203.0.113.58",
1810 "receiving-mx-hostname": "mx-backup.mail.company-y.example",
1811 "failed-session-count": 3,
1812 "failure-reason-code": "X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED"
1850Margolis, et al. Standards Track [Page 33]
1852RFC 8460 SMTP TLS Reporting September 2018
1866 Email: dmargolis@google.com
1872 Email: alex_brotman@comcast.com
1878 Email: prbinu@yahoo.com
1884 Email: janet.jones@microsoft.com
1890 Email: risher@google.com
1906Margolis, et al. Standards Track [Page 34]