SMTP MTA Strict Transport Security (MTA-STS)
SMTP MTA Strict Transport Security (MTA-STS) is a mechanism enabling mail service providers (SPs) to declare their ability to receive Transport Layer Security (TLS) secure SMTP connections and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted server certificate.
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 30 must, 14 should, 7 may.
2 Related Technologies
- MUST NOTHowever, MTA-STS is designed not to interfere with DANE deployments when the two overlap; in particular, senders who implement MTA-STS validation MUST NOT allow MTA-STS Policy validation to override a failing DANE validation.
3.1 MTA-STS TXT Records
- MUSTMTA-STS TXT records MUST be US-ASCII, semicolon-separated key/value pairs containing the following fields:
- MUSTThis string MUST uniquely identify a given instance of a policy, such that senders can determine when the policy has been updated by comparing to the "id" of a previously seen policy.
- MUSTThe TXT record MUST begin with the sts-version field; the order of other fields is not significant.
- MUSTIf the number of resulting records is not one, or if the resulting record is syntactically invalid, senders MUST assume the recipient domain does not have an available MTA-STS
- MUST(Note that the absence of a usable TXT record is not by itself sufficient to remove a sender's previously cached policy for the Policy Domain, as discussed in Section 5.1, "Policy Application Control Flow".) If the resulting TXT record contains multiple strings, then the record MUST be treated as if those strings are concatenated without adding spaces.
- MAYThe "_mta-sts" record MAY return a CNAME that points (directly or via other CNAMEs) to a TXT record, in which case senders MUST follow the CNAME pointers.
3.2 MTA-STS Policies
- SHOULDWhen fetching a policy, senders SHOULD validate that the media type is "text/plain" to guard against cases where web servers allow untrusted users to host non-text content (typically, HTML or images) at a user-defined path.
- SHOULDWell-behaved clients SHOULD cache a policy for up to this value from the last policy fetch time.
- MUSTIf a policy specifies more than one MX, each MX MUST have its own "mx:" key, and each MX key/value pair MUST be on its own line in the policy file.
- MUSTIn the case of Internationalized Domain Names [RFC5891], the "mx" value MUST specify the Punycode-encoded A-label [RFC3492] to match against, and not the Unicode-encoded U-label.
- MUSTParsers MUST accept TXT records and policy files that are syntactically valid (i.e., valid key/value pairs separated by semicolons for TXT records), possibly containing additional key/value pairs not specified in this document, in which case unknown fields SHALL be ignored.
- SHALLIf any non-repeated field -- i.e., all fields excepting "mx" -- is duplicated, all entries except for the first SHALL be ignored.
3.3 HTTPS Policy Fetching
- MUSTDuring the TLS handshake initiated to fetch a new or updated policy from the Policy Host, the Policy Host HTTPS server MUST present an X.509 certificate that is valid for the "mta-sts" DNS-ID [RFC6125] (e.g., "mta-sts.example.com") as described below, chain to a root CA that is trusted by the Sending MTA, and be non- expired.
- MAYo DNS domain names in server certificates MAY contain the wildcard character '*' as the complete left-most label within the identifier.
- MAYThe certificate MAY be checked for revocation via the Online Certificate Status Protocol (OCSP) [RFC6960], certificate revocation lists (CRLs), or some other mechanism.
- MUST NOTHTTP 3xx redirects MUST NOT be followed, and HTTP caching (as specified in [RFC7234]) MUST NOT be used.
- SHOULDIn the case where the HTTPS GET fails, implementers SHOULD limit further attempts to a period of five minutes or longer per version ID, to avoid overwhelming resource-constrained recipients with cascading failures.
- MAYSenders MAY impose a timeout on the HTTPS GET and/or a limit on the maximum size of the response body to avoid long delays or resource exhaustion during attempted policy updates.
- SHOULDA suggested timeout is one minute, and a suggested maximum policy size is 64 kilobytes; Policy Hosts SHOULD respond to requests with a complete policy body within that timeout and size limit.
- MUSTIf a valid TXT record is found but no policy can be fetched via HTTPS (for any reason), and there is no valid (non-expired) previously cached policy, senders MUST continue with delivery as though the domain has not implemented MTA-STS.
- MUSTConversely, if no "live" policy can be discovered via DNS or fetched via HTTPS, but a valid (non-expired) policy exists in the sender's cache, the sender MUST apply that cached policy.
- SHOULDFinally, to mitigate the risk of persistent interference with policy refresh, as discussed in-depth in Section 10, MTAs SHOULD proactively refresh cached policies before they expire; a suggested refresh frequency is once per day.
- SHOULDTo enable administrators to discover problems with policy refresh, MTAs SHOULD alert administrators (through the use of logs or similar) when such attempts fail, unless the cached policy mode is "none".
3.4 Policy Selection for Smart Hosts and Subdomains
- MUSTWhen sending mail via a "smart host" -- an administratively configured intermediate SMTP relay, which is different from the message recipient's server as determined from DNS -- compliant senders MUST treat the smart host domain as the Policy Domain for the purposes of policy discovery and application.
- MUST NOTWhen sending mail to a mailbox at a subdomain, compliant senders MUST NOT attempt to fetch a policy from the parent zone.
4 Policy Validation
- MUSTWhen sending to an MX at a domain for which the sender has a valid and non-expired MTA-STS Policy, a Sending MTA honoring MTA-STS MUST check whether:
4.2 Recipient MTA Certificate Validation
- MUSTThe certificate presented by the receiving MTA MUST not be expired and MUST chain to a root CA that is trusted by the Sending MTA.
- MUSTThe certificate MUST have a subject alternative name (SAN) [RFC5280] with a DNS-ID [RFC6125] matching the hostname, per the rules given in [RFC6125].
- MAYThe MX's certificate MAY also be checked for revocation via OCSP [RFC6960], CRLs [RFC6818], or some other mechanism.
5 Policy Application
- MUST NOT"enforce": In this mode, Sending MTAs MUST NOT deliver the message to hosts that fail MX matching or certificate validation or that do not support STARTTLS.
- MUST NOTWhen a message fails to deliver due to an "enforce" policy, a compliant MTA MUST NOT permanently fail to deliver messages before checking, via DNS, for the presence of an updated policy at the Policy Domain.
- SHOULD(In all cases, MTAs SHOULD treat such failures as transient errors and retry delivery later.) This allows implementing domains to update long-lived policies on the fly.
5.1 Policy Application Control Flow
- MUST NOTA message delivery attempt MUST NOT be permanently failed until the sender has first checked for the presence of a new policy (as indicated by the "id" field in the "_mta-sts" TXT record).
6 Reporting Failures
- SHOULDAs such, senders that also implement TLSRPT SHOULD treat the following events as reportable failures:
7.1 SNI Support
- MUSTTo ensure that the server sends the right certificate chain, the SMTP client MUST have support for the TLS Server Name Indication (SNI) extension [RFC6066].
- MUSTWhen connecting to an HTTP server to retrieve the MTA-STS Policy, the SNI extension MUST contain the name of the Policy Host (e.g., "mta-sts.example.com").
- MUSTWhen connecting to an SMTP server, the SNI extension MUST contain the MX hostname.
- MAYHTTP servers used to deliver MTA-STS policies MAY rely on SNI to determine which certificate chain to present to the client.
- MUSTHTTP servers MUST respond with a certificate chain that matches the policy hostname or abort the TLS handshake if unable to do so.
- MAYSMTP servers MAY rely on SNI to determine which certificate chain to present to the client.
- MUST NOTServers MUST NOT enforce the use of SNI by clients, as the client may be using unauthenticated opportunistic TLS and may not expect any particular certificate from the server.
- MUSTIf the client sends no SNI extension or sends an SNI extension for an unsupported server name, the server MUST simply send a fallback certificate chain of its choice.
7.2 Minimum TLS Version Support
- MUSTMTAs supporting MTA-STS MUST have support for TLS 1.2 [RFC5246] or TLS 1.3 [RFC8446] or higher.
- SHOULDThe general TLS usage guidance in [RFC7525] SHOULD be followed.
8.1 Policy Updates
- SHOULDRecipients SHOULD therefore ensure that old policies continue to work for message delivery during this period of time, or risk message delays.
- SHOULDRecipients SHOULD also update the HTTPS policy body before updating the TXT record; this ordering avoids the risk that senders, seeing a new TXT record, mistakenly cache the old policy from HTTPS.
8.2 Policy Delegation
- MUST NOTNote that while Sending MTAs MUST NOT use HTTP caching when fetching policies via HTTPS, such caching may nonetheless be useful to a reverse proxy configured as described in this section.
10.2 Preventing Policy Discovery
- SHOULDSince this attack depends upon intercepting initial policy discovery, implementers SHOULD prefer policy "max_age" values to be as long as is practical.
- SHOULD NOTBecause this attack is also possible upon refresh of a cached policy, implementers SHOULD NOT wait until a cached policy has expired before checking for an update; if senders attempt to refresh the cache regularly (for example, by fetching the current live policy in a background task that runs daily or weekly, regardless of the state of the "_mta-sts" TXT record, and updating their cache's "max age" accordingly), an attacker would have to foil policy discovery consistently over the lifetime of a cached policy to prevent a successful refresh.
- SHOULDAdditionally, MTAs SHOULD alert administrators to repeated policy refresh failures long before cached policies expire (through warning logs or similar applicable mechanisms), allowing administrators to detect such a persistent attack on policy refresh.