SMTP Service Extension for Authentication
obsoletes
- rfc-2554 — SMTP Service Extension for Authentication
updated by
- rfc-5248 — A Registry for SMTP Enhanced Mail System Status Codes
updates
- rfc-3463 — Enhanced Mail System Status Codes
Extracted elements (29)
SASLprep for authorization identities is specified as SHOULD rather than MUST to avoid breaking the majority of existing implementations. The specification notes that a future revision may upgrade this to MUST.
The 538 response code (encryption required for authentication mechanism) is deprecated. Modern implementations SHOULD NOT advertise mechanisms that are not permitted due to lack of encryption; instead, they should only advertise mechanisms when a sufficient encryption layer is already in place.
Many existing implementations support CRAM-MD5. New implementations MAY implement it for interoperability with deployed software, but should be aware that CRAM-MD5 provides no server authentication. The SASL Working Group was developing replacement mechanisms at time of writing.
The list of available SASL mechanisms advertised in the EHLO response MAY change after a successful STARTTLS command, allowing mechanisms requiring encryption to appear only after the TLS layer is established.
A server MUST implement a configuration in which plaintext password mechanisms are not permitted unless STARTTLS or an equivalent protection against password snooping has been negotiated. Server sites SHOULD NOT permit plaintext password mechanisms without such protection.
After a successful AUTH command, the server MUST reject any further AUTH commands in the same session with a 503 reply. An AUTH command issued during an active mail transaction MUST also be rejected with a 503 reply.
Client and server implementations MUST implement the PLAIN SASL mechanism running over TLS as a mandatory-to-implement baseline to ensure interoperability.
Client and server SHOULD use the SASLprep profile of the StringPrep algorithm to prepare authorization identity strings for transmission or comparison. If preparation fails or results in an empty string (unless originally transmitted empty), the server MUST fail authentication.
If an authentication exchange line exceeds the server's buffer, the server MUST fail the AUTH command with a 500 reply (enhanced status code 5.5.6). Clients and servers MUST be able to handle the maximum encoded size of challenges and responses generated by their supported mechanisms; 12288 octets is noted as sufficient at time of writing.
If the client sends a single '*' to cancel the authentication exchange, the server MUST reject the AUTH command with a 501 reply. If the client uses an initial-response argument with a SASL mechanism where the client does not begin the exchange, the server MUST also reject with a 501 reply.
Servers and clients MUST reject any character not explicitly allowed by the BASE64 alphabet, and MUST reject any BASE64 sequence containing the pad character '=' anywhere other than the end of the string. If the server cannot BASE64-decode a client response, it MUST reject the AUTH command with a 501 reply (enhanced status code 5.5.2).
Servers that advertise support for this extension MUST support the AUTH parameter to the MAIL FROM command even when the client has not authenticated. If the server does not sufficiently trust the client, or if AUTH=<> was supplied, the server MUST supply AUTH=<> when relaying the message to any server it has authenticated to using the AUTH extension.
Upon successful authentication, a server SHOULD use the 'ESMTPA' or 'ESMTPSA' keyword (as appropriate) in the 'with' clause of the generated Received header field, as defined in RFC 3848.
When a SASL security layer is negotiated, the SMTP protocol is reset to its initial state. The server MUST discard any knowledge obtained from the client (e.g., EHLO argument) not derived from the SASL negotiation itself, and the client MUST likewise discard server-provided knowledge such as the list of service extensions.
When AUTH is used with the SMTP PIPELINING extension, it MUST be the last command in a pipelined group, except when the initial response is for a mechanism that allows the client to send data first, completes in one round-trip, and no security layer is negotiated.
When 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.
When using SASL PLAIN over TLS, the client MUST verify the server certificate per RFC 3280 and MUST check the server hostname against the server's identity in the certificate (using subjectAltName dNSName if present, with wildcard and case-insensitive matching) before attempting authentication. If either check fails, the client MUST NOT attempt PLAIN authentication.
Status codes defined or referenced: 235 (authentication succeeded), 432 (password transition needed), 454 (temporary authentication failure), 534 5.7.9 (mechanism too weak), 535 5.7.8 (credentials invalid), 500 5.5.6 (exchange line too long), 530 5.7.0 (authentication required), and 538 5.7.11 (encryption required, deprecated for new implementations).
The AUTH command takes a mandatory SASL mechanism name and an optional initial-response encoded in BASE64 or the single character '='. A server challenge is sent as a 334 reply whose text part contains only the BASE64-encoded challenge string; the complete response line when no data is present is '334 ' (with a trailing space).
The AUTH parameter to the MAIL FROM command carries a <mailbox> (encoded in xtext) representing the identity that originally submitted the message, or the two-character sequence '<>' when that identity is unknown or insufficiently authenticated. This allows cooperating agents in a trusted environment to propagate submission identity across relay hops.
The SMTP Authentication extension adds the EHLO keyword 'AUTH', whose parameter is a space-separated list of available SASL mechanism names. A new SMTP verb 'AUTH' is defined, and an optional 'AUTH' parameter is added to the MAIL FROM command, extending its maximum line length by 500 characters.
IANA updated the 'smtp' SASL protocol name entry to point to this document, and updated the registration of the Authentication SMTP service extension in the mail-parameters registry. New enhanced status codes 5.7.8, 5.7.9, 5.7.11, and X.5.6 were added to the Enhanced Mail System Status Codes registry.
A client MAY compare the advertised SASL mechanisms before and after authentication to detect an active downgrade (down-negotiation) attack that strips stronger mechanisms from the advertised list.
Before SASL negotiation begins, all protocol interactions are in the clear and may be modified by an active attacker. Clients and servers MUST discard any knowledge obtained prior to the start of SASL negotiation upon establishment of a security layer, preventing injection of pre-authentication data.
Servers MAY drop the connection after repeated authentication failures, but SHOULD NOT do so until at least 3 authentication attempts have failed, to avoid denial-of-service through overly aggressive disconnection.
This extension is not a replacement for end-to-end message signature and encryption systems such as S/MIME or PGP. It authenticates message submission to the next hop within a trusted enclave, not authorship of message content; it protects the envelope, not the body.
BASE64 encoding uses the standard alphabet (ALPHA / DIGIT / '+' / '/'), is case-sensitive, and terminates with either two base64-chars followed by '==' or three base64-chars followed by '='. A zero-length initial response MUST be transmitted as the single character '='.
The auth-command ABNF is: 'AUTH' SP sasl-mech [SP initial-response] *(CRLF [base64]) [CRLF cancel-response] CRLF. The initial-response is base64 or '='. The continue-req (server challenge) is: '334' SP [base64] CRLF. The cancel-response is a single '*'.
The AUTH parameter to MAIL FROM uses xtext encoding: xchar is US-ASCII excluding '+', '=', SP, and CTL; hexchar is '+' followed by two hex digits. The decoded xtext value MUST be either a <mailbox> or the two characters '<>'.