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 identifier(s) ("names") of the

domain(s) to which mail messages are to be transferred, is a local

matter, and is not addressed by this document. In some cases, the

designated domain(s), or those determined by an SMTP client, will

identify the final destination(s) of the mail message. In other

cases, common with SMTP clients associated with implementations of

the POP (RFC 937, RFC 1939) or IMAP (RFC 3501)

protocols, or when the SMTP client is inside an isolated transport

service environment, the domain determined will identify an

intermediate destination through which all mail messages are to be

relayed. SMTP clients that transfer all traffic regardless of the

target domains associated with the individual messages, or that do

not maintain queues for retrying message transmissions that initially

cannot be completed, may otherwise conform to this specification but

are not considered fully-capable. Fully-capable SMTP

implementations, including the relays used by these less capable

ones, and their destinations, are expected to support all of the

queuing, retrying, and alternate address functions discussed in this

specification. In many situations and configurations, the less-

capable clients discussed above SHOULD be using the message

submission protocol (RFC 4409) rather than SMTP.

The means by which an SMTP client, once it has determined a target

domain, determines the identity of an SMTP server to which a copy of

a message is to be transferred, and then performs that transfer, is

covered by this document. To effect a mail transfer to an SMTP

server, an SMTP client establishes a two-way transmission channel to

that SMTP server. An SMTP client determines the address of an

appropriate host running an SMTP server by resolving a destination

domain name to either an intermediate Mail eXchanger host or a final

target host.

An SMTP server may be either the ultimate destination or an

intermediate "relay" (that is, it may assume the role of an SMTP

client after receiving the message) or "gateway" (that is, it may

transport the message further using some 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.

In other words, message transfer can occur in a single connection

between the original SMTP-sender and the final SMTP-recipient, or can

occur in a series of hops through intermediary systems. In either

case, once the server has issued a success response at the end of the

mail data, a formal handoff of responsibility for the message occurs:

the protocol requires that a server MUST accept responsibility for

either delivering the message or properly reporting the failure to do

so (see Sections 6.1, 6.2, and 7.8, below).

Once the transmission channel is established and initial handshaking

is completed, the SMTP client normally initiates a mail transaction.

Such a transaction consists of a series of commands to specify the

originator and destination of the mail and transmission of the

message content (including any lines in the header section or other

structure) itself. When the same message is sent to multiple

recipients, this protocol encourages the transmission of only one

copy of the data for all recipients at the same destination (or

intermediate relay) host.

The server responds to each command with a reply; replies may

indicate that the command was accepted, that additional commands are

expected, or that a temporary or permanent error condition exists.

Commands specifying the sender or recipients may include server-

permitted SMTP service extension requests, as discussed in

Section 2.2. The dialog is purposely lock-step, one-at-a-time,

although this can be modified by mutually agreed upon extension

requests such as command pipelining (RFC 2920).

Once a given mail message has been transmitted, the client may either

request that the connection be shut down or may initiate other mail

transactions. In addition, an SMTP client may use a connection to an

SMTP server for ancillary services such as verification of email

addresses or retrieval of mailing list subscriber addresses.

As suggested above, this protocol provides mechanisms for the

transmission of mail. Historically, this transmission normally

occurred directly from the sending user's host to the receiving

user's host when the two hosts are connected to the same transport

service. When they are not connected to the same transport service,

transmission occurs via one or more relay SMTP servers. A very

common case in the Internet today involves submission of the original

message to an intermediate, "message submission" server, which is

similar to a relay but has some additional properties; such servers

are discussed in Section 2.3.10 and at some length in RFC 4409 [18].

An intermediate host that acts as either an SMTP relay or as a

gateway into some other transmission environment is usually selected

through the use of the domain name service (DNS) Mail eXchanger

mechanism.

Usually, intermediate hosts are determined via the DNS MX record, not

by explicit "source" routing (see Section 5 and Appendix C and

Appendix F.2).