SMTP TLS Reporting
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 p
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 19 must, 15 should, 8 may.
3 Reporting Policy
- MUSTo "v": This document defines version 1 of TLSRPT, for which this value MUST be equal to "TLSRPTv1".
- MAYReport submitters MAY ignore certificate validation errors when submitting reports via HTTPS POST.
- MUSTWhen 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.
- MUSTReports sent via SMTP MUST contain a valid DomainKeys Identified Mail (DKIM) [RFC6376] signature by the reporting domain.
- MUSTReports lacking such a signature MUST be ignored by the recipient.
- MUST NOTDKIM signatures MUST NOT use the "l=" attribute to limit the body length used in the signature.
- SHOULDThe DKIM TXT record SHOULD contain the appropriate service type declaration, "s=tlsrpt".
- MAYIf not present, the receiving system MAY ignore reports lacking that service type.
- MUSTtlsrpt-uri = URI ; "URI" is imported from [RFC3986]; ; commas (ASCII 0x2C), exclamation ; points (ASCII 0x21), and semicolons ; (ASCII 0x3B) MUST be encoded
- MUSTIf the number of resulting records is not one, senders MUST assume the recipient domain does not implement TLSRPT.
- MUSTIf 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.
- MAYThe 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.
- MAYA 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.
- MUSTParsers 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.
4 Reporting Schema
- MUSTBecause 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.
4.1 Report Time Frame
- SHOULDThe report SHOULD cover a full day, from 00:00-24:00 UTC.
4.3.1 Negotiation Failures
- SHOULDo "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.
- SHOULDWhen using this declaration, the reporting MTA SHOULD utilize the "failure-reason- code" to provide more information to the receiving entity.
4.3.3 General Failures
- SHOULDWhen a negotiation failure cannot be categorized into one of the "Negotiation Failures" stated above, the reporter SHOULD use the "validation-failure" category.
- SHOULDWhen this category is used, the reporter SHOULD also use "failure-reason-code" to give some feedback to the receiving entity.
4.4 JSON Report Schema
- MUSTIn the case of Internationalized Domain Names [RFC5891], the domain MUST consist of the Punycode-encoded A-labels [RFC3492] and not the U-labels.
5.1 Report Filename
- RECOMMENDEDThe filename is RECOMMENDED to be constructed using the following ABNF:
- MUST; In the case of Internationalized Domain ; Names [RFC5891], the domain MUST consist of ; the Punycode-encoded A-labels [RFC3492] and ; not the U-labels.
- MUSTpolicy-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.
- MUSTThe extension MUST be "json" for a plain JSON file or "json.gz" for a JSON file compressed using gzip.
5.2 Compression
- SHOULDThe report SHOULD be subjected to gzip [RFC1952] compression for both email and HTTPS transport.
5.3 Email Transport
- MAYThe report MAY be delivered by email.
- MUSTThe "TLS-Report-Submitter" value MUST match the value found in the domain [RFC5321] of the "contact-info" from the report body.
- MUSTThese 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]:
- SHOULDThese additional headers SHOULD be included in the DKIM [RFC6376] signature for the message.
- SHOULDThe RFC5322.Subject field for report submissions SHOULD conform to the following ABNF:
5.3.1 Example Report
- MUST NOTNote that, when sending failure reports via SMTP, Sending MTAs MUST NOT honor MTA-STS or DANE TLSA failures.
5.4 HTTPS Transport
- MAYThe report MAY be delivered by POST to HTTPS.
- SHOULDIf 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").
- MUSTThe receiving system MUST return a "successful" response from its HTTPS server, typically a 200 or 201 HTTP code [RFC7231].
- MAYThe 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
- SHOULDIn 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.
- SHOULDIf multiple retries are attempted, ideally they SHOULD be done with exponential backoff.
5.6 Metadata Variances
- MUSTIf any of the items declared via subject or filename disagree with the report, the report MUST be considered the authoritative source.
6.2 Report Type
- MAYThe suffix "+gzip" MAY be used with any media type whose representation follows that established for "application/gzip".
- SHOULDFragment identifier considerations: The syntax and semantics of fragment identifiers specified for +gzip SHOULD be as specified for "application/gzip".
- SHOULD(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: