Skip to main content

3. The SMTP Procedures: An Overview

This section provides an overview of SMTP operations, covering session initiation, mail transactions, address verification, relaying, gateway processing, and session termination.

3.1. Session Initiation​

An SMTP session is initiated by a sending SMTP (client) establishing a two-way transmission channel to a receiving SMTP (server). The channel is fully asynchronous and has no data flow restrictions. After completing the TCP connection, the server typically sends a "220 Service ready" reply. The client usually initiates operations after receiving this greeting.

3.2. Client Initiation​

Once the transport service has provided the initialization channel and the server has sent the 220 service ready greeting, the client typically sends the EHLO command to identify itself and request that the server notify it of any available service extensions. If the server does not support extensions, it will respond to EHLO with a 500 error, and the client should fall back to the HELO command.

EHLO Command Example:

S: 220 smtp.example.com ESMTP Postfix
C: EHLO client.example.com
S: 250-smtp.example.com
S: 250-SIZE 52428800
S: 250-8BITMIME
S: 250-STARTTLS
S: 250 HELP

3.3. Mail Transactions​

A mail transaction consists of a series of commands that transfer a message from client to server. A mail transaction contains:

  1. MAIL command - Identifies the message originator
  2. One or more RCPT commands - Identifies the message recipient(s)
  3. DATA command - Transmits the message content

Complete Transaction Example:

C: MAIL FROM:``<[email protected]>``
S: 250 Ok
C: RCPT TO:``<[email protected]>``
S: 250 Ok
C: RCPT TO:``<[email protected]>``
S: 250 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: From: [email protected]
C: To: [email protected]
C: Subject: Test message
C: 
C: This is a test message.
C: .
S: 250 Ok: queued as 12345

The MAIL command begins a mail transaction. Upon successful completion of this command, the receiver clears all its buffers and state tables and prepares to receive RCPT commands.

The RCPT command identifies a single recipient of the mail. Multiple RCPT commands can be issued for a given message. A successful RCPT command adds the recipient to the buffer.

The DATA command causes subsequent lines to be treated as message text rather than commands. The message is terminated with a line containing only a period (.).

3.4. Forwarding for Address Correction or Updating​

Some servers may wish to forward mail to a corrected or updated address rather than the original recipient address. SMTP provides response codes 251 and 551 for this purpose. These codes allow the server to notify the client that the user address has changed, but the server will attempt to forward (251) or is unable to forward (551) the message.

3.5. Commands for Debugging Addresses​

3.5.1. Overview​

SMTP provides two commands for verifying usernames and mailing lists:

  • VRFY - Verify a username or mailbox
  • EXPN - Expand a mailing list

These commands are primarily for debugging purposes, and many servers disable or restrict them for security and privacy reasons.

3.5.2. VRFY Normal Response​

A successful response to the VRFY command is typically code 250, followed by text containing the user's full name and mailbox address.

Example:

C: VRFY Jones
S: 250 Fred Jones ``<[email protected]>``

3.5.3. Meaning of VRFY or EXPN Success Response​

A successful response to VRFY and EXPN commands does not guarantee that the address can receive mail or that mail will be delivered. It only indicates that the address is known to the server and is syntactically valid.

3.5.4. Semantics and Applications of EXPN​

The EXPN command is used to expand a mailing list or alias. It returns all addresses in the list.

Example:

C: EXPN staff
S: 250-Alice ``<[email protected]>``
S: 250-Bob ``<[email protected]>``
S: 250 Charlie ``<[email protected]>``

3.6. Relaying and Mail Routing​

3.6.1. Source Routes and Relaying​

Source routing (explicitly specifying the path through intermediate hosts) is deprecated in modern SMTP. Mail routing should rely on DNS MX records.

3.6.2. Mail eXchange Records and Relaying​

The DNS MX (Mail eXchanger) record system is used to identify the mail server(s) responsible for accepting mail for a domain. When delivering mail:

  1. Look up MX records for the destination domain
  2. Sort by priority (lower number = higher priority)
  3. Attempt delivery to servers in priority order
  4. If all MX records fail, attempt direct delivery to A/AAAA record

Example DNS MX Records:

example.com.  IN MX 10 mail1.example.com.
example.com.  IN MX 20 mail2.example.com.
example.com.  IN MX 30 mail3.example.com.

3.6.3. Message Submission Servers as Relays​

Message Submission Agents (MSAs) act as specialized relays that:

  • Accept mail from Mail User Agents (MUAs)
  • Enforce submission policies
  • Add required headers
  • Authenticate senders
  • Forward to appropriate MTAs

3.7. Mail Gatewaying​

A mail gateway connects SMTP infrastructure with other mail systems (e.g., X.400, UUCP). Gateways translate between protocols and formats.

3.7.1. Header Fields in Gatewaying​

Gateways MUST preserve essential header fields and MAY add gateway-specific fields. Translation must maintain semantic equivalence where possible.

3.7.2. Received Lines in Gatewaying​

Gateways MUST add Received header fields to track the message path, including:

  • Gateway identification
  • Timestamp
  • Protocol information

3.7.3. Addresses in Gatewaying​

Address translation is complex and gateway-specific. Gateways SHOULD:

  • Preserve original addressing information
  • Provide bidirectional address mapping
  • Document translation rules

3.7.4. Other Header Fields in Gatewaying​

Gateways must handle various header fields appropriately:

  • From, To, Cc, Bcc (address fields)
  • Subject, Keywords (text fields)
  • Date (timestamp conversion)
  • Message-ID (unique identifier preservation)

3.7.5. Envelopes in Gatewaying​

The SMTP envelope (MAIL FROM and RCPT TO) may differ from header addresses. Gateways must handle both correctly.

3.8. Terminating Sessions and Connections​

An SMTP session is terminated with the QUIT command:

C: QUIT
S: 221 smtp.example.com closing connection

After sending the 221 reply, the server closes the TCP connection. Clients SHOULD wait for the 221 reply before closing, but MUST be prepared for the server to close first.

Abnormal Termination: If severe errors occur, either party may close the connection immediately. The server may use reply code 421 to indicate service unavailability before closing.

3.9. Mailing Lists and Aliases​

3.9.1. Alias​

An alias is a mailbox name that, when resolved, refers to one or more other mailbox names. Alias expansion is transparent to the sender.

Example: [email protected] might be an alias for [email protected]

3.9.2. List​

A mailing list is similar to an alias but typically:

  • Managed by list management software
  • Allows subscription/unsubscription
  • May modify messages (add headers, footers)
  • Maintains subscriber database

When mail is sent to a list, it is expanded and delivered to all subscribers. The list software typically:

  • Adds list-specific headers (List-ID, List-Unsubscribe)
  • May require moderation
  • Handles bounce processing
  • Maintains archives
Last updated on