Secure SMTP

Introduction SMTP has always been defined as an unencrypted protocol. The STARTTLS extension allows an optional upgrade to TLS within an existing session. Secure SMTP performs the TLS negotiation at the start of each session, so all traffic is encrypted.

Requirements Language 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 when, and only when, they appear in all capitals, as shown here.

Session protocol Secure SMTP uses port TBD. To start a session, a Secure SMTP client connects to that port and negotiates a TLS connection. The client MUST use MTA-STS or DANE for SMTP to verify that it has connected to the intended server. After the connection, the protocol is identical to SMTP.

Server discovery Once a Secure SMTP client identifies a domain to which mail is to be delivered, it MUST do a DNS lookup to locate an MX record for the domain. Secure SMTP servers are identified in an MX record by adding a _ssmtp prefix to the hostname of the server. The _ssmtp prefix is removed from the hostname before finding addresses associated with the secure SMTP server's address. bigcorp.example. IN MX 10 _ssmtp.mail1.bigcorp.example. IN MX 20 mail2.bigcorp.example. In the example above, mail1.bigcorp.example is a Secure SMTP server, and mail2.bigcorp.example is a conventional SMTP server. If a server provides both conventional and Secure SMTP, two records identify the two services: bigcorp.example. IN MX 10 _ssmtp.mail1.bigcorp.example. IN MX 10 mail1.bigcorp.example. The numerical priority is used to select a server in the same manner as conventional SMTP. If there is both a conventional and Secure SMTP server at the same priority, a client MAY prefer the Secure one, or it may do load levelling as it would for multiple conventional servers at the same priority. Unlike conventional SMTP, there is no fallback to A or AAAA address records. A domain MUST publish an MX record with a _ssmtp prefix on the host name, to indicate that it supports Secure SMTP. The prefix appears in the MX to identify the server but is not part of the server's hostname. Note that since hostnames cannot contain underscores, there is no conflict with conventional SMTP MX records.

Differences from SMTP Secure SMTP servers MUST present a signed certificate that can be verified with MTA-STS, or a certificate that can be verified with DANE for SMTP, or preferably either way. Secure SMTP allows all SMTP extensions except STARTTLS which is irrelevant. When a mail server adds a Received: header field to an incoming message, it identifies the protocol as "with SSMTP" or "with SUTF8SMTP" depending on whether the session used SMTPUTF8.

Security considerations Secure SMTP is functionally the same as conventional SMTP except that all sessions are encrypted with TLS and the servers' certificates are validated, which should deter interception and entity-in-the-middle attacks. Messages are still stored in the clear on servers, so the same considerations about message encryption apply as for conventional SMTP.

IANA Considerations IANA is requested to allocate a port number for Secure SMTP. IANA is requested to add the following entries to the Mail Transmission Types for the "Received:" Header Field Reference, in the WITH Protocol Types table: SSMTP Secure SMTP SUTF8SMTP Secure SMTP with SMTPUTF8 IANA is requested to add the following entry to the Underscored and Globally Scoped DNS Node Names registry. MX _ssmtp [this document]

Implementation Status Many MTAs provide secure submission on port 465. Often a configuation tweak will be enough to accept secure SMTP on a different port.