SMTP Service Extension for Secure SMTP over Transport Layer Security
This document describes an extension to the SMTP (Simple Mail Transfer Protocol) service that allows an SMTP server and client to use TLS (Transport Layer Security) to provide private, authenticated communication over the Internet. This gives SMTP agents the ability to protect some or all of their communications from eavesdroppers and attackers. [STANDARDS-TRACK]
This document is current and has been amended. 1 later RFC has changed part of it. Nothing on the RFC itself tells you this.
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 10 must, 7 should, 3 may.
4 The STARTTLS Command
- MUST NOTA publicly-referenced SMTP server MUST NOT require use of the STARTTLS extension in order to deliver mail locally.
- SHOULDIn this case, the server SHOULD return the reply code:
- SHOULDIf the client and server are using the ENHANCEDSTATUSCODES ESMTP extension [RFC2034], the status code to be returned SHOULD be 5.7.0.
- MUSTAfter receiving a 220 response to a STARTTLS command, the client MUST start the TLS negotiation before giving any other SMTP commands.
- SHOULDIf, after having issued the STARTTLS command, the client finds out that some failure prevents it from actually starting a TLS handshake, then it SHOULD abort the connection.
4.1 Processing After the STARTTLS Command
- MUSTAfter the TLS handshake has been completed, both parties MUST immediately decide whether or not to continue based on the authentication and privacy achieved.
- SHOULDIf the SMTP client decides that the level of authentication or privacy is not high enough for it to continue, it SHOULD issue an SMTP QUIT command immediately after the TLS negotiation is complete.
- SHOULDIf the SMTP server decides that the level of authentication or privacy is not high enough for it to continue, it SHOULD reply to every SMTP command from the client (other than a QUIT command) with the 554 reply code (with a possible text string such as "Command refused due to lack of security").
4.2 Result of the STARTTLS Command
- MUSTThe server MUST discard any knowledge obtained from the client, such as the argument to the EHLO command, which was not obtained from the TLS negotiation itself.
- MUSTThe client MUST discard any knowledge obtained from the server, such as the list of SMTP service extensions, which was not obtained from the TLS negotiation itself.
- SHOULDThe client SHOULD send an EHLO command as the first command after a successful TLS negotiation.
- MAYThe list of SMTP service extensions returned in response to an EHLO command received after the TLS handshake MAY be different than the list returned before the TLS handshake.
- MUSTBoth the client and the server MUST know if there is a TLS session active.
- MUST NOTA client MUST NOT attempt to start a TLS session if a TLS session is already active.
- MUST NOTA server MUST NOT return the STARTTLS extension in response to an EHLO command received after a TLS handshake has completed.
6 Security Considerations
- MUSTIn order to defend against such attacks both clients and servers MUST be able to be configured to require successful TLS negotiation of an appropriate cipher suite for selected hosts before messages can be successfully transferred.
- SHOULDThe additional option of using TLS when possible SHOULD also be provided.
- MAYAn implementation MAY provide the ability to record that TLS was used in communicating with a given peer and generating a warning if it is not used in a later session.
- MUSTFor this reason, clients and servers MUST discard any knowledge obtained prior to the start of the TLS handshake upon completion of the TLS handshake.
- MAYIn addition, the [SMTP-AUTH] proposal offers simpler and more flexible options to authenticate an SMTP client and the SASL EXTERNAL mechanism [SASL] MAY be used in conjunction with the STARTTLS command to provide an authorization identity.