SMTP Require TLS Option
The SMTP STARTTLS option, used in negotiating transport-level encryption of SMTP connections, is not as useful from a security standpoint as it might be because of its opportunistic nature; message delivery is, by default, prioritized over security. This document describes an SMTP service extension, REQUIRETLS, and a message header field, TLS-Required. If the REQUIRETLS option or TLS-Required message header field is used when sending a message, it asserts a request on the part of the message sender to override the
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 28 must, 6 should, 2 may.
1 Introduction
- MUSTThe service extension is used to specify that a given message sent during a particular session MUST be sent over a TLS-protected session with specified security characteristics.
2 The REQUIRETLS Service Extension
- MUSTThis option MUST only be specified in the context of an SMTP session meeting the security requirements of REQUIRETLS:
- MUST* The session itself MUST employ TLS transmission.
- MUST* If the SMTP server to which the message is being transmitted is identified through an MX record lookup, its name MUST be validated via a DNSSEC signature on the recipient domain's MX record, or the MX hostname MUST be validated by an MTA-STS policy as described in Section 4.1 of [RFC8461].
- MUST* The certificate presented by the SMTP server either MUST be verified successfully by a trust chain leading to a certificate trusted by the SMTP client, or it MUST be verified successfully using DANE, as specified in [RFC7672].
- MUST* Following the negotiation of STARTTLS, the SMTP server MUST advertise in the subsequent EHLO response that it supports REQUIRETLS.
3 The TLS-Required Header Field
- REQUIREDThe TLS-Required header field has a single REQUIRED parameter:
- SHOULD* No - The SMTP client SHOULD attempt to send the message regardless of its ability to negotiate STARTTLS with the SMTP server, ignoring policy-based mechanisms (including MTA-STS and DANE), if any, asserted by the recipient domain.
- SHOULDNevertheless, the client SHOULD negotiate STARTTLS with the server if available.
- MUST NOTMore than one instance of the TLS-Required header field MUST NOT appear in a given message.
4.1 REQUIRETLS Receipt Requirements
- MUSTUpon receipt of the REQUIRETLS option on a MAIL FROM command during the receipt of a message, an SMTP server MUST tag that message as needing REQUIRETLS handling.
- MUSTUpon receipt of a message not specifying the REQUIRETLS option on its MAIL FROM command but containing the TLS-Required header field in its message header, an SMTP server implementing this specification MUST tag that message with the option specified in the TLS-Required header field.
- MUSTIf the REQUIRETLS MAIL FROM parameter is specified, the TLS- Required header field MUST be ignored but MAY be included in the onward relay of the message.
- MUSTIf the message is being locally aliased and redistributed to multiple addresses, all instances of the message MUST be tagged in the same manner.
4.2.1 Sending with TLS Required
- MUSTWhen sending a message tagged as requiring TLS for which the MAIL FROM return-path is not empty (an empty MAIL FROM return-path indicating a bounce message), the sending (client) MTA MUST:
- MUSTIf the server lookup is accomplished via the recipient domain's MX record (the usual case) and is not accompanied by a valid DNSSEC signature, the client MUST also validate the SMTP server name using MTA-STS, as described in [RFC8461], Section 4.1.
- MUSTThe hostname from the MX record lookup (or the domain name in the absence of an MX record where an A record is used directly) MUST match the DNS-ID or CN- ID of the certificate presented by the server.
- SHOULDThe SMTP client SHOULD follow the recommendations in [RFC7525] or its successor with respect to negotiation of the TLS session.
- MUSTIf any of the above steps fail, the client MUST issue a QUIT to the server and repeat steps 2-5 with each host on the recipient domain's list of MX hosts in an attempt to find a mail path that meets the sender's requirements.
- MAYThe client MAY send other, unprotected messages to that server if it has any such messages prior to issuing the QUIT.
- MUST NOTIf there are no more MX hosts, the client MUST NOT transmit the message to the domain.
- MUSTFollowing such a failure, the SMTP client MUST send a non-delivery notification to the reverse-path of the failed message, as described in Section 3.6 of [RFC5321].
- SHOULDThe following status codes [RFC5248] SHOULD be used:
4.2.2 Sending with TLS Optional
- MUSTWhen sending such a message, the sending (client) MTA MUST:
- MUSTA non-delivery notification MUST be returned to the sender if message relay fails due to an inability to negotiate STARTTLS when required by the server.
4.3 REQUIRETLS Submission
- MUSTIf TLS is to be required, it MUST do so by negotiating STARTTLS and REQUIRETLS and including the REQUIRETLS option on the MAIL FROM command, as is done for message relay.
- MUSTWhen TLS is not to be required, the sender MUST include the TLS- Required header field in the message.
- MUSTSMTP servers implementing this specification MUST interpret this header field as described in Section 4.1.
- MAYIn either case, the decision whether to specify REQUIRETLS MAY be done based on a user interface selection or based on a ruleset or other policy.
4.4 Delivery of REQUIRETLS messages
- SHOULDMail delivery agents supporting the REQUIRETLS SMTP option SHOULD observe the guidelines in [RFC8314].
5 Non-delivery Message Handling
- MUSTThey therefore MUST be protected in the same manner as the original message.
- MUSTAll non-delivery messages resulting from messages with the REQUIRETLS SMTP option, whether resulting from a REQUIRETLS error or some other issue, MUST also specify the REQUIRETLS SMTP option unless redacted as described below.
- MUSTIf a REQUIRETLS message is bounced, the server MUST behave as if RET=HDRS was present, as described in [RFC3461].
- MUSTIf both RET=FULL and REQUIRETLS are present, the RET=FULL MUST be disregarded.
- SHOULD NOTWhen the MAIL FROM return- path is empty, the REQUIRETLS parameter SHOULD NOT cause a bounce message to be discarded even if the next-hop relay does not advertise REQUIRETLS.
8.3 Bad-Actor MTAs
- MUSTMessages containing sensitive information that MTAs should not have access to MUST be sent using end-to-end content encryption such as OpenPGP [RFC4880] or S/MIME [RFC8551].