← RFC Reference

RFC 4954: SMTP AUTH Extension

Why This Exists

Original SMTP (RFC 5321) had no concept of sender authentication. Any client could connect to any server and send mail as anyone. This design worked in the early internet where all participants were trusted, but it became the foundation of the spam problem.

RFC 4954 defines the AUTH extension to SMTP, providing a standardized way for clients to authenticate with a mail server before submitting messages. It uses the SASL (Simple Authentication and Security Layer) framework, allowing multiple authentication mechanisms to be plugged in without changing the SMTP protocol itself.

This RFC obsoleted RFC 2554 (1999), fixing security issues and clarifying the interaction between AUTH and other SMTP extensions like STARTTLS.

How It Works

The AUTH Negotiation

1. The client connects and issues EHLO.
2. The server advertises 250-AUTH followed by a list of supported SASL mechanisms.
3. The client picks a mechanism and sends AUTH <mechanism>, optionally with an initial response.
4. The server and client exchange one or more challenge/response rounds (mechanism-dependent).
5. The server responds with 235 (authentication successful) or 535 (authentication failed).

SMTP Transcript: AUTH PLAIN

The PLAIN mechanism sends credentials in a single Base64-encoded string containing the authorization identity, authentication identity, and password:

SMTP Transcript: AUTH LOGIN

The LOGIN mechanism uses a separate challenge/response for username and password:

SMTP Transcript: AUTH Failed

Key Technical Details

SASL Mechanisms

RFC 4954 does not define authentication mechanisms directly. It provides the framework; mechanisms come from the SASL registry. The most commonly used ones in SMTP:

The AUTH PLAIN Credential Format

The PLAIN mechanism encodes three fields separated by null bytes (\0), then Base64-encodes the result:

The Initial Response Optimization

RFC 4954 allows the client to send the initial SASL response on the same line as the AUTH command (as shown in the PLAIN example above). This saves one round-trip compared to the older two-step approach where the server first sends an empty challenge. For mechanisms like PLAIN where the client speaks first, this optimization is standard.

Interaction with STARTTLS

RFC 4954 strongly recommends that servers not advertise AUTH until after TLS is established. This prevents clients from accidentally sending credentials in cleartext. The typical flow is:

1. Connect → EHLO → server advertises STARTTLS but not AUTH
2. STARTTLS → TLS handshake
3. EHLO again → server now advertises AUTH (STARTTLS no longer listed)
4. AUTH → submit messages

Response Codes

AUTH and MAIL FROM Identity

After successful authentication, the server associates the connection with the authenticated identity. The MSA can then enforce that the MAIL FROM and header From: addresses match (or are authorized for) the authenticated user. This prevents authenticated users from spoofing arbitrary sender addresses.

Common Mistakes

• Sending AUTH before STARTTLS. If the server advertises AUTH on a cleartext connection (some misconfigured servers do), your credentials still travel in the clear. Always establish TLS before authenticating. With implicit TLS on port 465, this is automatic.
• Confusing Base64 encoding with encryption. Base64 is an encoding, not encryption. AUTH PLAIN sends credentials in a trivially decodable format. The protection comes from the TLS layer, not from Base64.
• Not handling 535 errors. A failed AUTH means the server rejected your credentials. Retrying the same credentials in a loop will get your IP rate-limited or blocked. Check the credentials and fail gracefully.
• Hardcoding AUTH LOGIN when PLAIN is available. LOGIN is a non-standard mechanism with inconsistent implementations. If the server supports PLAIN, prefer it. If it supports XOAUTH2 or SCRAM, prefer those.
• Not re-issuing EHLO after STARTTLS. The capability list changes after TLS is established. AUTH may only appear in the post-TLS EHLO response. Skipping the second EHLO means your client never discovers AUTH support.
• Ignoring the initial response optimization. Sending AUTH PLAIN without the inline credentials forces an unnecessary extra round-trip. Most modern servers support the initial response.
• Using CRAM-MD5 for "security." CRAM-MD5 avoids sending the plaintext password, but it uses MD5 (broken), does not protect against replay attacks, and requires the server to store the password in a recoverable form. PLAIN over TLS is strictly superior.

Deliverability Impact

• Required for message submission. Every modern email service requires SMTP AUTH for submission (RFC 6409). Without authentication, the server will reject your messages with a 530 (authentication required) response.
• Enables sender identity binding. Authentication ties each message to a known account. This lets the email service enforce sending policies, apply DKIM signatures, and track reputation per authenticated sender.
• Prevents open relay abuse. By requiring authentication before accepting messages for delivery, servers avoid being exploited as open relays — which would quickly result in IP blacklisting and delivery failure for all users on the server.
• OAuth2 for modern integrations. Services like Gmail and Microsoft 365 are deprecating password-based AUTH in favor of XOAUTH2. Migrating to token-based authentication avoids service disruptions when basic auth is disabled.
• Rate limiting and abuse prevention. Authenticated sessions allow per-user rate limiting. If one account is compromised, the service can throttle or disable that account without affecting other senders on the same infrastructure.

Related RFCs