This document provide note and summary of RFC 4954, SMTP Service Extension for Authentication.
1. EHLO Extension
The EHLO keyword associated with this extension is "AUTH".
This extension provide one command "AUTH".
This extension add one optional parameter to MAIL FROM command: "AUTH"
This extension extends the maximum line length of the MAIL FROM command to 500 characters.
1.1. Common Response
530 5.7.0 Authentication required
This response SHOULD be returned by command MAIL, RCPT, DATA, VRFY, EXPN, and HELP, when server policy requires authentication in order to perform the requested action.
2. AUTH Command
"AUTH" mechanism ( initial-response / "=" ) CRLF mechanism = A string identifying a [SASL] authentication mechanism. initial-response = base64
Initial-response MUST be encoded in base64 and may or may not empty, depends on mechanism.
Initial-response "=" is response with zero length, to indicate that the response is present.
After a successful AUTH command completes, a server MUST reject any further AUTH commands with a 503 reply.
An AUTH command issued during a mail transaction MUST be rejected with a 503 reply.
There are two modes of AUTH handshakes: directly with initial-response and non-directly with initial-response in the second response.
2.1. Direct Handshake
In this mode, the $INITIAL_RESPONSE contains non empty text other than "=". This mode SHOULD be used when length of command line less than maximum (512 octets), to minimize round-trip to server.
; TLS handshake ; EHLO handshake C: AUTH $MECHANISM $INITIAL_RESPONSE S: 235 2.7.0 Authentication successful
2.2. Indirect Handshake
In this mode, the $INITIAL_RESPONSE is empty, which cost client additional step. This mode MUST be used when AUTH line is exceeding maximum command line (512 octets, see RFC 5321, section 4.5.3).
; TLS handshake ; EHLO handshake C: AUTH $MECHANISM S: "334" SP [ $SERVER_CHALLENGE ] CRLF C: $INITIAL_RESPONSE S: 235 2.7.0 Authentication successful
$SERVER_CHALLENGE is encoded in base64 and may or may not present depends on $MECHANISM.
2.3.1. Success Response
"235" SP "2.7.0 Authentication successful" CRLF
The client SHOULD send an EHLO command as the first command after a successful SASL negotiation that results in the enabling of a security layer.
2.3.2. Error Response
432 4.7.12 A password transition is needed
This response indicates that the user needs to transition to the selected authentication mechanism. This is typically done by authenticating once using the [PLAIN] authentication mechanism. The selected mechanism SHOULD then work for authentications in subsequent sessions.
454 4.7.0 Temporary authentication failure
This response indicates that the authentication failed due to a temporary server failure. The client SHOULD NOT prompt the user for another password in this case, and should instead notify the user of server failure.
500 5.5.6 Authentication Exchange line is too long
This response indicates that the authentication failed due to the client sending a [BASE64] response that is longer than the maximum buffer size available for the currently selected SASL mechanism.
501 Syntax error in parameters or arguments
This response indicates that client canceling authentication or server failed to decode base64 from handshake.
504 5.5.4 Command parameter not implemented
If the requested authentication mechanism is invalid (e.g., is not supported or requires an encryption layer).
534 5.7.9 Authentication mechanism is too weak
This response indicates that the selected authentication mechanism is weaker than server policy permits for that user. The client SHOULD retry with a new authentication mechanism.
535 5.7.8 Authentication credentials invalid
This response indicates that the authentication failed due to invalid or insufficient authentication credentials. The client SHOULD ask the user to supply new credentials (such as by presenting a password dialog box).
2.4. Canceling AUTH
Client can cancel authentication, for example when client can’t decode base64 from server, by sending,
and server MUST reject the AUTH by response with 501 status code.
3. AUTH Parameter for MAIL FROM Command
"AUTH=" (mailbox / "<>")
If 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. For 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.
A parameter of AUTH=<> indicates that the original submitter of the message is not known. The server MUST NOT treat the message as having been originally submitted by the authenticated identity that resulted from the AUTH command.
If the AUTH parameter is not supplied and 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. The generated <mailbox> is implementation specific, but it MUST conform to the syntax of [SMTP]. If the implementation cannot generate a valid <mailbox>, it MUST transmit AUTH=<> when relaying this message.
If 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. The server MAY, however, write the value of any supplied AUTH parameter to a log file.
If 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.
A 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.
4. Additional Requirements on Servers
Upon 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.
5. Security Considerations
Clients and servers MUST discard any knowledge obtained prior to the start of the SASL negotiation upon the establishment of a security layer.
Servers MAY implement a policy whereby the connection is dropped after a number of failed authentication attempts. If they do so, they SHOULD NOT drop the connection until at least 3 attempts to authenticate have failed.
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].
If an SMTP client is willing to use SASL PLAIN over TLS to authenticate to the SMTP server, the client verifies the server certificate according to the rules of [X509]. If 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.