SMTP Service Extension for Authentication
This document defines a Simple Mail Transport Protocol (SMTP) extension whereby an SMTP client may indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions during this session. This extension includes a profile of the Simple Authentication and Security Layer (SASL) for SMTP. This document obsoletes RFC 2554. [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. 37 must, 20 should, 10 may.
3 The Authentication Service Extension
- MAYThe list of available mechanisms MAY change after a successful STARTTLS command [SMTP-TLS].
4 The AUTH Command
- MUSTIf present, this response MUST be encoded as described in Section 4 of [BASE64] or contain a single character "=".
- MUSTAfter a successful AUTH command completes, a server MUST reject any further AUTH commands with a 503 reply.
- MUSTAn AUTH command issued during a mail transaction MUST be rejected with a 503 reply.
- SHOULDIf the server supports the [ESMTP-CODES] extension, it SHOULD return a 5.5.4 enhanced response code.
- MUST NOTThis challenge MUST NOT contain any text other than the BASE64 encoded challenge.
- MUSTIf the server receives such a response, it MUST reject the AUTH command by sending a 501 reply.
- MUSTIf the initial response argument is omitted and the chosen mechanism requires an initial client response, the server MUST proceed as defined in Section 5.1 of [SASL].
- MUST NOTIf use of the initial response argument would cause the AUTH command to exceed this length, the client MUST NOT use the initial response parameter (and instead proceed as defined in Section 5.1 of [SASL]).
- MUSTIf the client is transmitting an initial response of zero length, it MUST instead transmit the response as a single equals sign ("=").
- MUSTIf the client uses an initial-response argument to the AUTH command with a SASL mechanism in which the client does not begin the authentication exchange, the server MUST reject the
- SHOULDServers using the enhanced status codes extension [ESMTP-CODES] SHOULD return an enhanced status code of 5.7.0 in this case.
- MUSTIf the server cannot [BASE64] decode any client response, it MUST reject the AUTH command with a 501 reply (and an enhanced status code of 5.5.2).
- MUSTIf the client cannot BASE64 decode any of the server's challenges, it MUST cancel the authentication using the "*" response.
- MUSTIn particular, servers and clients MUST reject (and not ignore) any character not explicitly allowed by the BASE64 alphabet, and MUST reject any sequence of BASE64 characters that contains the pad character ('=') anywhere other than the end of the string (e.g., "=AAA" and "AAA=BBB" are not allowed).
- MUSTClients and servers MUST be able to handle the maximum encoded size of challenges and responses generated by their supported authentication mechanisms.
- SHOULDServers using the enhanced status codes extension [ESMTP-CODES] SHOULD return an enhanced status code of 5.5.6 in this case.
- SHOULDThe authorization identity generated by this [SASL] exchange is a "simple username" (in the sense defined in [SASLprep]), and both client and server SHOULD (*) use the [SASLprep] profile of the [StringPrep] algorithm to prepare these names for transmission or comparison.
- MUSTIf preparation of the authorization identity fails or results in an empty string (unless it was transmitted as the empty string), the server MUST fail the authentication.
- MUST(*) Note: Future revision of this specification may change this requirement to MUST.
- SHOULDCurrently, the SHOULD is used in order to avoid breaking the majority of existing implementations.
- SHOULDIf the server is unable to authenticate the client, it SHOULD reject the AUTH command with a 535 reply unless a more specific error code is appropriate.
- MUSTThe server MUST discard any knowledge obtained from the client, such as the EHLO argument, which was not obtained from the SASL negotiation itself.
- MUSTLikewise, the client MUST discard any knowledge obtained from the server, such as the list of SMTP service extensions, which was not obtained from the SASL negotiation itself.
- MAY(Note that a client MAY compare the advertised SASL mechanisms before and after authentication in order to detect an active down- negotiation attack).
- SHOULDThe client SHOULD send an EHLO command as the first command after a successful SASL negotiation that results in the enabling of a security layer.
- MUSTWhen an entity (whether it is the client or the server end) is sending data, and both [TLS] and SASL security layers are in effect, the TLS encoding MUST be applied after the SASL encoding, regardless of the order in which the layers were negotiated.
- MAYIf an AUTH command fails, the client MAY proceed without authentication.
- MAYAlternatively, the client MAY try another authentication mechanism or present different credentials by issuing another AUTH
- MUSTNote: A server implementation MUST implement a configuration in which it does NOT permit any plaintext password mechanisms, unless either the STARTTLS [SMTP-TLS] command has been negotiated or some other mechanism that protects the session from password snooping has been provided.
- SHOULD NOTServer sites SHOULD NOT use any configuration which permits a plaintext password mechanism without such a protection mechanism against password snooping.
- MUSTTo ensure interoperability, client and server implementations of this extension MUST implement the [PLAIN] SASL mechanism running over TLS [TLS] [SMTP-TLS].
- MAYIn order to ensure interoperability with deployed software, new implementations MAY implement it; however, implementations should be aware that this SASL mechanism doesn't provide any server authentication.
- MUSTWhen the AUTH command is used together with the [PIPELINING] extension, it MUST be the last command in a pipelined group of commands.
5 The AUTH Parameter to the MAIL FROM command
- SHOULDIf the server trusts the authenticated identity of the client to assert that the message was originally submitted by the supplied <mailbox>, then the server SHOULD supply the same <mailbox> in an AUTH parameter when relaying the message to any other server which supports the AUTH extension.
- MUSTFor this reason, servers that advertise support for this extension MUST support the AUTH parameter to the MAIL FROM command even when the client has not authenticated itself to the server.
- MUST NOTThe server MUST NOT treat the message as having been originally submitted by the authenticated identity that resulted from the AUTH command.
- MAYIf the AUTH parameter to the MAIL FROM command is not supplied, the client has authenticated, and the server believes the message is an original submission, the server MAY generate a <mailbox> from the user's authenticated identity for use in an AUTH parameter when relaying the message to any server which supports the AUTH extension.
- MUSTThe generated <mailbox> is implementation specific, but it MUST conform to the syntax of [SMTP].
- MUSTIf the implementation cannot generate a valid <mailbox>, it MUST transmit AUTH=<> when relaying this message.
- MUSTIf the server does not sufficiently trust the authenticated identity of the client, or if the client is not authenticated, then the server MUST behave as if the AUTH=<> parameter was supplied.
- MAYThe server MAY, however, write the value of any supplied AUTH parameter to a log file.
- MUSTIf an AUTH=<> parameter was supplied, either explicitly or due to the requirement in the previous paragraph, then the server MUST supply the AUTH=<> parameter when relaying the message to any server which it has authenticated to using the AUTH extension.
- MAYA server MAY treat expansion of a mailing list as a new submission, setting the AUTH parameter to the mailing list address or mailing list administration address when relaying the message to list subscribers.
6 Status Codes
- SHOULDServers that return enhanced status codes [ESMTP-CODES] SHOULD use the enhanced codes suggested here.
- SHOULDThe selected mechanism SHOULD then work for authentications in subsequent sessions.
- SHOULD NOTThe client SHOULD NOT prompt the user for another password in this case, and should instead notify the user of server failure.
- SHOULDThe client SHOULD retry with a new authentication mechanism.
- SHOULDIn this case, the client SHOULD ask the user to supply new credentials (such as by presenting a password dialog box).
- SHOULDThis response SHOULD be returned by any command other than AUTH, EHLO, HELO, NOOP, RSET, or QUIT when server policy requires authentication in order to perform the requested action and authentication is not currently in force.
- SHOULD NOTModern implementations SHOULD NOT advertise mechanisms that are not permitted due to lack of encryption, unless an encryption layer of sufficient strength is currently being employed.
- SHOULDThis enhanced status code SHOULD be returned when the server fails the AUTH command due to the client sending a [BASE64] response which is longer than the maximum buffer size available for the currently selected SASL mechanism.
7 Additional Requirements on Servers
- MUSTAs described in Section 4.4 of [SMTP], an SMTP server that receives a message for delivery or further processing MUST insert the "Received:" header field at the beginning of the message content.
- SHOULDUpon successful authentication, a server SHOULD use the "ESMTPA" or the "ESMTPSA" [SMTP-TT] (when appropriate) keyword in the "with" clause of the Received header field.
8 Formal Syntax
- MUSTImplementations MUST accept these strings in a case-insensitive fashion.
- MUST;; ;; The decoded form of the xtext MUST be ;; either a <mailbox> or the two ;; characters "<>"
9 Security Considerations
- MUSTFor this reason, clients and servers MUST discard any knowledge obtained prior to the start of the SASL negotiation upon the establishment of a security layer.
- MAYServers MAY implement a policy whereby the connection is dropped after a number of failed authentication attempts.
- SHOULD NOTIf they do so, they SHOULD NOT drop the connection until at least 3 attempts to authenticate have failed.
- MUSTIf an implementation supports SASL mechanisms that are vulnerable to passive eavesdropping attacks (such as [PLAIN]), then the implementation MUST support at least one configuration where these SASL mechanisms are not advertised or used without the presence of an external security layer such as [TLS].
14 Additional Requirements When Using SASL PLAIN over TLS
- MUST NOTIf the server has not provided any certificate, or if the certificate verification fails, the client MUST NOT attempt to authenticate using the SASL PLAIN mechanism.
- MUSTAfter a successful [TLS] negotiation, the client MUST check its understanding of the server hostname against the server's identity as presented in the server Certificate message, in order to prevent man-in-the-middle attacks.
- MUST NOTIf the match fails, the client MUST NOT attempt to authenticate using the SASL PLAIN mechanism.
- MUSTThe client MUST use the server hostname it used to open the connection as the value to compare against the server name as expressed in the server certificate.
- SHOULDIf a subjectAltName extension of type dNSName is present in the certificate, it SHOULD be used as the source of the server's identity.
- MAYA "*" wildcard character MAY be used as the leftmost name component in the certificate.
15 Changes since RFC 2554
- MUSTClarified that servers MUST support the use of the AUTH=mailbox parameter to MAIL FROM, even when the client is not authenticated.