Every SMTP transaction is a structured conversation between client and server. This conversation follows precise rules, using a defined set of commands issued by the client and response codes returned by the server. Mastering this vocabulary is essential for anyone implementing, debugging, or securing email systems.

Unlike casual human conversation, SMTP dialogues are strictly ordered and predictable. Each command serves a specific purpose in establishing the email envelope, transferring message content, or managing the session. Understanding these commands transforms email from a mysterious "it just works" service into a transparent, debuggable system.

SMTP commands follow a simple, consistent structure designed for both human readability and machine parsing. Understanding this structure is fundamental to working with the protocol.

Command Syntax:

Every SMTP command consists of:

1. A command keyword (verb) — 4 characters, case-insensitive by specification but conventionally uppercase
2. Optional parameters — separated from the keyword by a single space (SP)
3. A terminator — carriage return + line feed (CRLF, or \r )

COMMAND [SP parameter [SP parameter...]] CRLF

Critical Syntax Rules:

Parameter Encoding:

Email addresses in SMTP commands use a specific format called a "reverse-path" or "forward-path":

MAIL FROM:<sender@example.com>
RCPT TO:<recipient@example.com>

The angle brackets are mandatory in strict SMTP. Some implementations accept bare addresses (MAIL FROM:sender@example.com), but this violates the specification and can cause interoperability issues.

Extended Parameters (ESMTP):

When using Extended SMTP (ESMTP), commands can include additional keyword-value parameters:

MAIL FROM:<sender@example.com> SIZE=1048576 BODY=8BITMIME
RCPT TO:<recipient@example.com> NOTIFY=SUCCESS,FAILURE

These extensions enable features like message size declaration, delivery status notifications, and internationalized email addresses.

After every command, the SMTP server returns a response consisting of a three-digit numeric code and a human-readable message. Understanding this response system is crucial for proper client behavior and error handling.

Response Structure:

XYZ [SP text] CRLF

• X (first digit): Response category (success, failure type)
• Y (second digit): Response subcategory
• Z (third digit): Specific condition
• text: Human-readable explanation (for humans, not programmatic use)

Multi-line Responses:

Servers can send multi-line responses for extended information. In multi-line responses, all lines except the last use a hyphen after the code instead of a space:

250-mail.example.com Hello client.example.org
250-SIZE 52428800
250-8BITMIME
250-STARTTLS
250-AUTH LOGIN PLAIN
250 HELP

Enhanced Status Codes (RFC 3463):

Modern SMTP servers often include enhanced status codes providing more detail:

550 5.1.1 <unknown@example.com>: Recipient address rejected: User unknown

The 5.1.1 is the enhanced code, where:

• 5 = Permanent failure
• 1 = Addressing status (second group)
• 1 = Bad destination mailbox address (third group)

Every SMTP session begins with the client identifying itself to the server. This identification phase uses either the original HELO command or the extended EHLO command, which enables additional protocol features.

HELO — Original Greeting Command

The HELO command is the original SMTP greeting from RFC 821. It provides a simple client identification:

C: HELO sender.example.org
S: 250 mail.receiver.com Hello sender.example.org

Syntax: HELO <domain>

• The <domain> should be the fully qualified domain name (FQDN) of the client
• If no FQDN is available, an IP address in brackets is acceptable: HELO [192.168.1.100]
• Upon receiving HELO, the server enters "HELO state" with basic SMTP capabilities only

EHLO — Extended SMTP Greeting

The EHLO (Extended HELO) command, introduced in RFC 1869, is the modern greeting that negotiates extended capabilities:

C: EHLO sender.example.org
S: 250-mail.receiver.com Hello sender.example.org
S: 250-SIZE 52428800
S: 250-8BITMIME
S: 250-STARTTLS
S: 250-ENHANCEDSTATUSCODES
S: 250-PIPELINING
S: 250-CHUNKING
S: 250-AUTH LOGIN PLAIN CRAM-MD5
S: 250 SMTPUTF8

Syntax: EHLO <domain>

The server's multi-line response lists all supported extensions. The client can then use extensions that appear in this list.

The envelope of an email message—distinct from the message headers—is established using two critical commands: MAIL FROM and RCPT TO. These commands define the actual routing information used by SMTP servers, which may differ from what appears in the message headers.

The Envelope vs. Headers Distinction:

This is a crucial concept many email users don't understand:

• Envelope MAIL FROM: The address to which bounces (non-delivery reports) are sent; used only by SMTP servers, never shown to recipients
• Header From: What recipients see as the sender; can be different from envelope sender
• Envelope RCPT TO: The actual delivery destination(s); determines where the message is routed
• Header To/Cc: What recipients see; may not match actual recipients (e.g., Bcc recipients)

MAIL FROM Command:

The MAIL FROM command initiates a mail transaction and specifies the return path for bounces.

Syntax: MAIL FROM:<reverse-path> [SP extension-params]

C: MAIL FROM:<alice@sender.example.org>
S: 250 2.1.0 Sender OK

Extension Parameters:

• SIZE=<bytes> — Declares message size upfront, allowing server to reject before data transfer
• BODY=7BIT|8BITMIME — Declares message body encoding
• RET=FULL|HDRS — For DSN: return full message or headers only on bounce
• ENVID=<xtext> — Envelope ID for tracking

C: MAIL FROM:<alice@example.org> SIZE=1048576 BODY=8BITMIME
S: 250 2.1.0 Sender OK

RCPT TO Command:

The RCPT TO command specifies a recipient. Each recipient requires a separate RCPT TO command.

Syntax: RCPT TO:<forward-path> [SP extension-params]

C: RCPT TO:<bob@receiver.example.com>
S: 250 2.1.5 Recipient OK

C: RCPT TO:<carol@receiver.example.com>
S: 250 2.1.5 Recipient OK

C: RCPT TO:<unknown@receiver.example.com>
S: 550 5.1.1 User unknown

Extension Parameters:

• NOTIFY=NEVER|SUCCESS|FAILURE|DELAY — DSN notification conditions
• ORCPT=<addr-type>;addr — Original recipient for DSN tracking

C: RCPT TO:<bob@example.com> NOTIFY=SUCCESS,FAILURE
S: 250 2.1.5 Recipient OK

The DATA command is where the actual message content—headers and body—is transmitted. This is the heart of SMTP, where the email message moves from sender to receiver.

DATA Command Protocol:

C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: From: Alice <alice@sender.example.org>
C: To: Bob <bob@receiver.example.com>
C: Subject: Meeting Tomorrow
C: Date: Mon, 15 Jan 2024 10:30:00 -0500
C: Message-ID: <unique-id@sender.example.org>
C: MIME-Version: 1.0
C: Content-Type: text/plain; charset=UTF-8
C:
C: Hi Bob,
C:
C: Let's meet tomorrow at 2pm.
C:
C: Thanks,
C: Alice
C: .
S: 250 2.0.0 Message accepted for delivery

The Dot-Stuffing Mechanism:

Since a line containing only . signals the end of data, lines in the message body that naturally start with a period must be escaped. This is called "dot stuffing":

Original message line: .This line starts with a period
Transmitted as:        ..This line starts with a period

Original message line: ...three periods
Transmitted as:        ....three periods

The receiving server removes the extra leading period, restoring the original content.

Transparency Procedure:

# Sender: Before transmitting each line
if line.startswith('.'):
    line = '.' + line

# Receiver: After receiving each line (except terminator)
if line.startswith('..'):
    line = line[1:]

Beyond the core mail transfer commands, SMTP includes commands for session management, debugging, and control flow. While some are rarely used in production, understanding them is essential for protocol completeness.

RSET — Reset Transaction State

The RSET command aborts the current mail transaction without closing the connection:

C: MAIL FROM:<alice@example.org>
S: 250 2.1.0 Sender OK
C: RCPT TO:<bob@example.com>
S: 250 2.1.5 Recipient OK
C: RSET
S: 250 2.0.0 OK
# Transaction cleared; can start fresh
C: MAIL FROM:<carol@example.org>
S: 250 2.1.0 Sender OK

Use Cases:

• Aborting a transaction when an error is detected
• Switching to a different sender without reconnecting
• Clearing state after a rejected recipient

NOOP — No Operation

The NOOP command does nothing except elicit a success response. It's used to:

• Keep connections alive (prevent timeout)
• Test connection health
• Pace command sequences

C: NOOP
S: 250 2.0.0 OK

QUIT — End Session

The QUIT command gracefully terminates the SMTP session:

C: QUIT
S: 221 2.0.0 Bye
# Connection closed

After QUIT, the server closes the connection. The client should also close its end. Failing to send QUIT before disconnecting is considered impolite but doesn't affect message delivery.

HELP — Request Help Information

The HELP command requests information about commands:

C: HELP
S: 214-Commands supported:
S: 214-HELO EHLO MAIL RCPT DATA RSET
S: 214-NOOP QUIT VRFY HELP
S: 214 For more info use HELP <topic>

C: HELP MAIL
S: 214 MAIL FROM:<sender> [SP <parameters>]

Note: Many servers disable or limit HELP output for security reasons.

SMTP includes commands for verifying addresses and expanding mailing lists. However, these are rarely enabled in production due to security and privacy concerns.

VRFY — Verify Address

The VRFY command asks the server if a mailbox exists:

C: VRFY bob
S: 250 Bob Smith <bob@example.com>

C: VRFY unknown
S: 550 5.1.1 User unknown

C: VRFY amb
S: 553 Ambiguous; try BOB or AMBER

Why VRFY is Dangerous:

• Spam harvesting — Attackers use VRFY to discover valid email addresses
• Account enumeration — Reveals which usernames exist
• Privacy violation — Exposes user information without authorization

Modern Response:

Most servers either:

• Disable VRFY entirely: 502 VRFY command disabled
• Always return success: 252 Cannot VRFY user, but will accept message
• Always return failure: 550 VRFY not supported

EXPN — Expand Mailing List

The EXPN command expands a mailing list alias to its member addresses:

C: EXPN engineering
S: 250-Alice Smith <alice@example.com>
S: 250-Bob Jones <bob@example.com>
S: 250 Carol Chen <carol@example.com>

C: EXPN unknown-list
S: 550 No such list

Why EXPN is Even More Dangerous:

• Reveals all members of mailing lists
• Enables targeted phishing attacks
• Violates privacy of list subscribers
• Provides reconnaissance for social engineering

Modern Status:

EXPN is almost universally disabled. RFC 5321 explicitly notes that servers may refuse to implement these commands.

SMTP is a stateful protocol with a defined sequence of commands. Commands issued out of sequence trigger a 503 Bad sequence of commands error. Understanding this state machine is essential for correct client implementation.

SMTP State Machine:

Multiple Messages Per Session:

SMTP allows sending multiple messages over a single TCP connection. After a successful DATA transaction, the client can immediately begin a new transaction with MAIL FROM:

C: EHLO client.example.org
S: 250-server.example.com
S: 250 OK

# First message
C: MAIL FROM:<alice@example.org>
S: 250 OK
C: RCPT TO:<bob@example.com>
S: 250 OK
C: DATA
S: 354 Start input
C: [message content]
C: .
S: 250 OK Message 1 accepted

# Second message (same session)
C: MAIL FROM:<alice@example.org>
S: 250 OK
C: RCPT TO:<carol@example.com>
S: 250 OK
C: DATA
S: 354 Start input
C: [message content]
C: .
S: 250 OK Message 2 accepted

C: QUIT
S: 221 Bye

Traditional SMTP requires the client to wait for a response after each command before sending the next. On high-latency networks, this creates significant delays. The PIPELINING extension (RFC 2920) allows batching multiple commands without waiting for individual responses.

Without Pipelining (Traditional):

C: MAIL FROM:<alice@example.org>
   [wait ~100ms for response]
S: 250 OK
C: RCPT TO:<bob@example.com>
   [wait ~100ms for response]
S: 250 OK
C: RCPT TO:<carol@example.com>
   [wait ~100ms for response]
S: 250 OK
C: DATA
   [wait ~100ms for response]
S: 354 Start input
# Total overhead: ~400ms of round-trip latency

With Pipelining:

C: MAIL FROM:<alice@example.org>
RCPT TO:<bob@example.com>
RCPT TO:<carol@example.com>
DATA
   [single wait for all responses]
S: 250 OK
S: 250 OK
S: 250 OK
S: 354 Start input
# Total overhead: ~100ms (one round-trip)

Pipelining Rules:

1. Pipelining is only allowed if server advertises PIPELINING in EHLO response
2. Certain commands cannot be pipelined after:
   • EHLO/HELO — Must wait for response to learn capabilities
   • STARTTLS — Must wait for TLS negotiation
   • DATA (before body) — Must wait for 354 response before sending body
   • AUTH — Must wait for authentication challenges/responses
3. Clients must be prepared to handle responses to pipelined commands after failures

We've comprehensively explored the SMTP command vocabulary—the building blocks of every email transaction. Let's consolidate the essential knowledge:

What's Next:

With command knowledge in hand, we're ready to explore Mail Submission—how email clients authenticate with and submit messages to their organization's mail servers, including the authentication mechanisms and security requirements that protect against unauthorized email sending.