Skip to main content

2. The SMTP Model

2.1. Basic Structure​

The SMTP design can be pictured as:

                  +----------+                +----------+
      +------+    |          |                |          |
      | User |`<-->`|          |      SMTP      |          |
      +------+    |  Client- |Commands/Replies| Server-  |
      +------+    |   SMTP   |`<-------------->`|    SMTP  |    +------+
      | File |`<-->`|          |    and Mail    |          |`<-->`| File |
      |System|    |          |                |          |    |System|
      +------+    +----------+                +----------+    +------+
                   SMTP client                SMTP server

When an SMTP client has a message to transmit, it establishes a two-way transmission channel to an SMTP server. The responsibility of an SMTP client is to transfer mail messages to one or more SMTP servers, or report its failure to do so.

The means by which a mail message is presented to an SMTP client, and how that client determines the domain(s) to which mail messages are to be transferred, is a local matter not addressed by this document.

SMTP clients that transfer all traffic regardless of target domains, or that do not maintain queues for retrying message transmissions, may conform to this specification but are not considered fully-capable. Fully-capable SMTP implementations are expected to support all queuing, retrying, and alternate address functions discussed in this specification.

An SMTP server may be either the ultimate destination or an intermediate "relay" (assuming the role of an SMTP client after receiving the message) or "gateway" (transporting the message using a protocol other than SMTP). SMTP commands are generated by the SMTP client and sent to the SMTP server. SMTP replies are sent from the SMTP server to the SMTP client in response to the commands.

Once the server issues a success response at the end of mail data, a formal handoff of responsibility occurs: the protocol requires that a server MUST accept responsibility for either delivering the message or properly reporting the failure to do so.

2.2. The Extension Model​

2.2.1. Background​

Starting in 1990, the protocol was modified with a "service extensions" model that permits the client and server to agree to utilize shared functionality beyond the original SMTP requirements.

Contemporary SMTP implementations MUST support the basic extension mechanisms. Servers MUST support the EHLO command even if they do not implement any specific extensions, and clients SHOULD preferentially utilize EHLO rather than HELO. However, for compatibility with older conforming implementations, SMTP clients and servers MUST support the original HELO mechanisms as a fallback.

2.2.2. Definition and Registration of Extensions​

The SMTP extension mechanism defines a means whereby an extended SMTP client and server may recognize each other, and the server can inform the client as to the service extensions it supports.

2.2.3. Special Issues with Extensions​

Extensions MUST NOT change the basic SMTP model and MUST be upward-compatible with the existing standard.

2.3. SMTP Terminology​

2.3.1. Mail Objects​

SMTP transports a mail object consisting of:

  • An envelope containing transmission parameters
  • Header section
  • Body (content)

2.3.2. Senders and Receivers​

The party that originates a mail message is called the "sender" or "originator." The party to whom mail is delivered is called the "receiver" or "recipient."

2.3.3. Mail Agents and Message Stores​

Mail User Agent (MUA): Provides user interface for reading and composing mail.

Mail Submission Agent (MSA): Accepts messages from MUAs and enforces local site policy.

Mail Transfer Agent (MTA): Transfers mail from one system to another.

Mail Delivery Agent (MDA): Delivers mail to the recipient's mailbox.

2.3.4. Host​

A computer system attached to the Internet (or other network).

2.3.5. Domain Names​

Domain names as described in RFC 1034, RFC 1035, and RFC 1123.

2.3.6. Buffer and State Table​

SMTP sessions are stateful. The server must remember session information and the current state of the protocol.

2.3.7. Commands and Replies​

Commands are requests sent from client to server. Replies are responses sent from server to client.

2.3.8. Lines​

SMTP data is transmitted in lines terminated by CRLF (Carriage Return, Line Feed: \r\n).

2.3.9. Message Content and Mail Data​

The message content is transmitted using the DATA command. The end of message data is indicated by a line containing only a period (.).

2.3.10. Originator, Delivery, Relay, and Gateway Systems​

  • Originator: Creates the original message
  • Delivery: Final destination system
  • Relay: Intermediate system forwarding using SMTP
  • Gateway: Intermediate system using different protocol

2.3.11. Mailbox and Address​

A mailbox is a destination for email messages. An address specifies a mailbox location in the form local-part@domain.

2.4. General Syntax Principles and Transaction Model​

SMTP commands and replies follow specific syntax rules:

  • Commands are 4 letter words (some extended to 8)
  • Replies are 3-digit codes with optional text
  • All commands and replies are case-insensitive
  • Lines must not exceed specified length limits

The basic mail transaction consists of:

  1. Connection establishment
  2. Client greeting (EHLO/HELO)
  3. MAIL command (specify sender)
  4. RCPT command (specify recipient, may be repeated)
  5. DATA command (transmit message)
  6. QUIT command (close connection)
Last updated on