SMTP Service Extension for Secure SMTP over TLS
obsoleted by
- rfc-3207 — SMTP Service Extension for Secure SMTP over Transport Layer Security
Extracted elements (20)
The EHLO service extension list after TLS handshake MAY differ from the pre-handshake list; for example, a server might only advertise certain SASL mechanisms after a client presents an appropriate certificate, allowing authentication-dependent capability advertisement.
A client certificate presented during TLS negotiation authenticates the SMTP client agent, not the original author of the email message; end-to-end author authentication requires every hop in the delivery chain to be authenticated (e.g., via SMTP-AUTH or MIME security).
A non-publicly-referenced SMTP server that requires TLS 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, preventing STARTTLS from damaging interoperability of the Internet's SMTP infrastructure.
After receiving a 220 response to STARTTLS, the client SHOULD start the TLS negotiation before giving any other SMTP commands.
After the TLS handshake completes, both parties MUST immediately decide whether to continue based on the authentication and privacy achieved.
Both client and server MUST know if a TLS session is active. A client MUST NOT attempt to start a TLS session if one is already active. A server MUST NOT return the TLS extension in an EHLO response after a TLS handshake has completed.
If the SMTP client finds the authentication or privacy level insufficient, it SHOULD issue an SMTP QUIT command immediately after TLS negotiation completes.
If the SMTP server finds the authentication or privacy level insufficient, it SHOULD reply to every SMTP command from the client (other than QUIT) with reply code 554.
If using pipelining (RFC 1854), the STARTTLS command MUST be the last command in a group.
The client SHOULD send an EHLO command as the first command after a successful TLS negotiation.
The server MUST discard any knowledge obtained from the client (e.g., EHLO argument) not obtained from TLS negotiation itself; the client MUST discard any knowledge obtained from the server (e.g., service extension list) not obtained from TLS negotiation itself.
When ENHANCEDSTATUSCODES is in use and a server requires STARTTLS first, the enhanced status code returned SHOULD be 5.7.0.
The STARTTLS command elicits one of three reply codes from the server: 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, with EHLO keyword STARTTLS (no parameters), and introduces a new SMTP verb STARTTLS with no parameters.
A man-in-the-middle attack can be launched by deleting the '250 STARTTLS' response from the server, causing the client to skip TLS. Clients can protect against this by recording that a server offered TLS in a prior session and alarming if it disappears; lack of TLS SHOULD NOT cause email to bounce.
Any protocol interactions before the TLS handshake are in the clear and may be modified by an active attacker. Therefore, clients and servers MUST discard knowledge obtained prior to the start of the TLS handshake upon its completion.
Both SMTP client and server must check the result of the TLS negotiation to verify acceptable authentication or privacy was achieved; ignoring this step completely invalidates using TLS for security.
SMTP is not an end-to-end mechanism; TLS between one client/server pair does not secure the entire delivery chain. Authentication of an SMTP client does not imply the client authenticated the mail it received from upstream.
Upon completion of the TLS handshake, the SMTP protocol is reset to initial state (equivalent to after a 220 service ready greeting). The server MUST discard pre-TLS client knowledge and the client MUST discard pre-TLS server knowledge.