SMTP Service Extension for Secure SMTP over Transport Layer Security
obsoletes
- rfc-2487 — SMTP Service Extension for Secure SMTP over TLS
updated by
- rfc-7817 — Updated Transport Layer Security (TLS) Server Identity Check Procedure for Email-Related Protocols
Extracted elements (25)
After TLS handshake completion the SMTP session is reset to its initial state and both sides must discard pre-TLS knowledge, because pre-handshake communications were unprotected and could have been tampered with by an attacker.
Publicly-referenced SMTP servers are prohibited from requiring STARTTLS for local mail delivery to preserve the interoperability of the existing Internet SMTP infrastructure, ensuring that not all mail servers need to support TLS for the email system to function.
The post-TLS EHLO response MAY differ from the pre-TLS response, allowing servers to conditionally advertise capabilities (e.g., certain SASL mechanisms) only after a client has presented an appropriate certificate, enabling authentication-conditional feature advertisement.
If using ENHANCEDSTATUSCODES (RFC 2034), the enhanced status code accompanying the 530 'Must issue a STARTTLS command first' response SHOULD be 5.7.0.
STARTTLS is a valid ESMTP extension when used on the Submission port (RFC 2476). Because the submission port is by definition not a publicly referenced SMTP server, STARTTLS can require authentication and security for that service.
A client MUST NOT attempt to start a TLS session if a TLS session is already active. A server MUST NOT return the STARTTLS extension in response to an EHLO command received after a TLS handshake has completed.
A non-publicly-referenced SMTP server that requires TLS negotiation before accepting commands SHOULD return reply code 530 ('Must issue a STARTTLS command first') to every command other than NOOP, EHLO, STARTTLS, or QUIT.
A publicly-referenced SMTP server MUST NOT require use of the STARTTLS extension in order to deliver mail locally, to prevent damage to the interoperability of the Internet's SMTP infrastructure.
After receiving a 220 response to a STARTTLS command, the client MUST start the TLS negotiation before giving any other SMTP commands. If the client cannot actually start the TLS handshake, it SHOULD abort the connection.
After TLS handshake completion, both parties MUST immediately decide whether to continue based on the authentication and privacy achieved.
If ENHANCEDSTATUSCODES is in use and the server requires STARTTLS first, the enhanced status code returned SHOULD be 5.7.0.
If the SMTP client finds the level of authentication or privacy insufficient, it SHOULD issue a QUIT command immediately after TLS negotiation completes. If the server finds it insufficient, it SHOULD reply with 554 to every subsequent client command except QUIT.
The client SHOULD send an EHLO command as the first command after a successful TLS negotiation, since the server's advertised extensions may differ post-TLS.
The server MUST discard knowledge obtained from the client before the TLS handshake (e.g., EHLO argument), and the client MUST discard knowledge obtained from the server (e.g., list of SMTP service extensions) that was not obtained from the TLS negotiation itself.
When using pipelining (RFC 2920), the STARTTLS command must be the last command in a pipeline group.
After a successful TLS handshake, the server's EHLO extension list MAY differ from the pre-TLS list; for example, a SASL mechanism might only be advertised after the client provides an appropriate client certificate during TLS.
The STARTTLS command takes no parameters. After the client issues STARTTLS, the server responds with 220 (Ready to start TLS), 501 (Syntax error, no parameters allowed), or 454 (TLS not available due to temporary reason).
The STARTTLS extension defines a new SMTP service extension named 'STARTTLS', associated EHLO keyword 'STARTTLS' (with no parameters), and a new SMTP verb 'STARTTLS' with no parameters.
A man-in-the-middle attack can strip the '250 STARTTLS' response to prevent TLS negotiation, or allow the STARTTLS advertisement but alter the upgrade request/response. To defend against this, both clients and servers MUST be configurable to require successful TLS negotiation with an appropriate cipher suite for selected hosts.
An implementation SHOULD provide the option of using TLS when possible, and MAY record that TLS was used with a given peer and generate a warning if it is not used in a later session.
Both client and server must check the TLS negotiation result for acceptable authentication and privacy. Ignoring this step completely invalidates TLS security. If the negotiation yields insufficient privacy or authentication, either party should terminate the session.
Clients and servers MUST discard any knowledge obtained prior to the start of the TLS handshake upon completion of the TLS handshake, because pre-handshake interactions are in the clear and may be modified by an active attacker.
SMTP is not an end-to-end mechanism; TLS between one client/server pair does not secure the entire delivery chain. A single mail delivery may traverse multiple SMTP servers, and TLS on one hop does not imply TLS on all hops.
STARTTLS is not suitable for authenticating the author of an email message unless every hop in the delivery chain, including submission to the first SMTP server, is authenticated. SMTP-AUTH and MIME security multiparts are alternatives for message-level authentication.
Upon TLS handshake completion, the SMTP protocol is reset to the initial state (equivalent to after the server issues a 220 service ready greeting). The server MUST discard pre-TLS client knowledge (e.g., EHLO argument) and the client MUST discard pre-TLS server knowledge (e.g., service extension list).