The SMTP Procedures

Welcome to the tutorial guide.  The tutorial will provide a user with advise and guidance about the descriptions of the procedures used in SMTP:

  • session initiation,
  • the mail transaction,
  • forwarding mail,
  • verifying mailbox names and expanding mailing lists, and the opening and
    closing exchanges. 

Session Initiation

A user should note that SMTP session is initiated when a client opens a connection to a server and the server responds with an opening message.

SMTP server implementations can include identification of their software and version information in the connection greeting reply after the 220 code, a practice that permits more efficient isolation and repair of any problems.  Implementations MAY make provision for SMTP servers to disable the software and version announcement where it causes security concerns.  While some systems also identify their contact point for mail problems, this is not a substitute for maintaining the required “postmaster” address. 

The SMTP protocol allows a server to formally reject a transaction while still allowing the initial connection as follows:

a 554 response can be given in the initial connection opening message nstead of the 220.  A server taking this approach should wait for the client to send a QUIT before closing the connection and SHOULD respond to any intervening commands with “503 bad sequence of commands”.  Since an attempt to make an SMTP connection to such a system is probably in error, a server returning a 554 response on connection opening SHOULD provide enough information in the reply text to facilitate debugging of the sending system.

Client Initiation

After the server has sent the welcoming message and the client has received it, the client normally sends the EHLO command to the server, indicating the client’s identity.  In addition to opening the session, use of EHLO indicates that the client is able to process service extensions and requests that the server provide a list of the extensions it supports.  Older SMTP systems which are unable to support service extensions and contemporary clients which do not require service extensions in the mail session being initiated can use HELO instead of EHLO.  Servers should not return the extended EHLO-style response to a HELO command.  For a particular connection attempt, if the server returns a “command not recognized” response to EHLO, the client should be able to fall back and send HELO.

In the EHLO command the host sending the command identifies itself;

the command may be interpreted as saying “Hello, I am <domain>” (and, in the case of EHLO, “and I support service extension requests”).

Mail Transactions

There are three steps to SMTP mail transactions.  The transaction starts with a MAIL command which gives the sender identification.  A series of one or more RCPT commands follows giving the receiver information.  Then a DATA command initiates transfer of the mail data and is terminated by the “end of mail” data indicator, which also confirms the transaction.

The first step in the procedure is the MAIL command.

      MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>

This command tells the SMTP-receiver that a new mail transaction is  starting and to reset all its state tables and buffers, including any recipients or mail data.  The <reverse-path> portion of the first or only argument contains the source mailbox (between “<” and “>” brackets), which can be used to report errors.  If accepted, the SMTP server returns a 250 OK reply.  If the mailbox specification is not acceptable for some reason, the server MUST return a reply indicating whether the failure is permanent (i.e., will occur again if the client tries to send the same address again) or temporary (i.e., the address might be accepted if the client tries again later).  Despite the apparent scope of this requirement, there are circumstances in which the acceptability of the reverse-path may not be determined until one or more forward-paths (in RCPT commands) can be examined.  In those cases, the server MAY reasonably accept the reverse-path (with a 250 reply) and then report problems after the forward-paths are received and examined.  Normally, failures produce 550 or 553 replies.

A user should note that historically, the <reverse-path> can contain more than just a mailbox, however, contemporary systems SHOULD NOT use source routing.  The optional <mail-parameters> are associated with negotiated SMTP service extensions. 

The second step in the procedure is the RCPT command.

      RCPT TO:<forward-path> [ SP <rcpt-parameters> ] <CRLF>

The first or only argument to this command includes a forward-path  (normally a mailbox and domain, always surrounded by “<” and “>” brackets) identifying one recipient.  If accepted, the SMTP server
returns a 250 OK reply and stores the forward-path.  If the recipient is known not to be a deliverable address, the SMTP server returns a 550 reply, typically with a string such as “no such user – ” and the mailbox name (other circumstances and reply codes are possible).

This step of the procedure can be repeated any number of times.  The <forward-path> can contain more than just a mailbox. Historically, the <forward-path> can be a source routing list of hosts and the destination mailbox, however, contemporary SMTP clients should not utilize source routes.  Servers MUST be prepared to encounter a list of source routes in the forward path, but SHOULD ignore the routes or MAY decline to support the relaying they imply.  Similarly, servers MAY decline to accept mail that is destined for other hosts or systems.  These restrictions make a server useless as a relay for clients that do not support full SMTP functionality.  Consequently, restricted-capability clients MUST NOT assume that any SMTP server on the Internet can be used as their mail processing (relaying) site.  If a RCPT command appears without a
previous MAIL command, the server MUST return a 503 “Bad sequence of commands” response.  The optional <rcpt-parameters> are associated with negotiated SMTP service extensions.

The third step in the procedure is the DATA command (or some alternative specified in a service extension).


If accepted, the SMTP server returns a 354 Intermediate reply and considers all succeeding lines up to but not including the end of mail data indicator to be the message text.  When the end of text is successfully received and stored the SMTP-receiver sends a 250 OK reply.

Since the mail data is sent on the transmission channel, the end of mail data must be indicated so that the command and reply dialog can be resumed.  SMTP indicates the end of the mail data by sending a line containing only a “.” (period or full stop).  A transparency procedure is used to prevent this from interfering with the user’s text.

The end of mail data indicator also confirms the mail transaction and tells the SMTP server to now process the stored recipients and mail data.  If accepted, the SMTP server returns a 250 OK reply.  The DATA    command can fail at only two points in the protocol exchange:

-  If there was no MAIL, or no RCPT, command, or all such commands were rejected, the server MAY return a “command out of sequence” (503) or “no valid recipients” (554) reply in response to the DATA command.  If one of those replies (or any other 5yz reply) is received, the client MUST NOT send the message data; more generally, message data MUST NOT be sent unless a 354 reply is received.

-  If the verb is initially accepted and the 354 reply issued, the DATA command should fail only if the mail transaction was incomplete (for example, no recipients), or if resources were unavailable (including, of course, the server unexpectedly becoming unavailable), or if the server determines that the message should be rejected for policy or other reasons.

A user will note that in practice, some servers do not perform recipient verification until after the message text is received.  These servers SHOULD treat a failure for one or more recipients as a “subsequent
failure” and return a mail message.  If a user is using a “550 mailbox not found” (or equivalent) reply code after the data are accepted makes it difficult or impossible for the client to determine which recipients failed.

When RFC 822 format [7, 32] is being used, the mail data include the memo header items such as Date, Subject, To, Cc, From.  Server SMTP systems SHOULD NOT reject messages based on perceived defects in the RFC 822 or MIME [12] message header or message body.  In particular, they MUST NOT reject messages in which the numbers of Resent-fields do not match or Resent-to appears without Resent-from and/or Resent-date.

Forwarding for Address Correction or Updating

Forwarding support is most often required to consolidate and simplify addresses within, or relative to, some enterprise and less frequently to establish addresses to link a person’s prior address with current one.  Silent forwarding of messages (without server notification to the sender), for security or non-disclosure purposes, is common in the contemporary Internet.

In both the enterprise and the “new address” cases, information hiding (and sometimes security) considerations argue against exposure of the “final” address through the SMTP protocol as a side-effect of the forwarding activity.  This may be especially important when the final address may not even be reachable by the sender.

In particular:

*  Servers MAY forward messages when they are aware of an address change.  When they do so, they MAY either provide address-updating information with a 251 code, or may forward “silently” and return a 250 code.  But, if a 251 code is used, they MUST NOT assume that the client will actually update address information or even return that information to the user.

Alternately, *  Servers MAY reject or bounce messages when they are not deliverable when addressed.  When they do so, they MAY either provide address-updating information with a 551 code, or may
reject the message as undeliverable with a 550 code and no address-specific information.  But, if a 551 code is used, they MUST NOT assume that the client will actually update address information or even return that information to the user.

SMTP server implementations that support the 251 and/or 551 reply codes are strongly encouraged to provide configuration mechanisms so that sites which conclude that they w ould undesirably disclose
information can disable or restrict their use.

If you read and followed the tutorial guide then you would have learnt about the STMP procedures.

What is Simple Mail Transfer Protocol (SMTP)

The objective of the Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently.

SMTP is independent of the particular transmission subsystem and requires only a reliable ordered data stream channel.  While this document specifically discusses transport over TCP, other transports
are possible.  Please note that an important feature of SMTP is its capability to transport mail
across networks, usually referred to as “SMTP mail relaying”. 

A network consists of the mutually-TCP-accessible hosts on the public Internet, the mutually-TCP-accessible hosts on a firewall-isolated TCP/IP Intranet, or hosts in some other LAN or WAN
environment utilizing a non-TCP transport-level protocol.

By using SMTP, a process can transfer mail to another process on the same network or to some other network via a relay or gateway process accessible to both networks.

In this way, a mail message may pass through a number of intermediate relay or gateway hosts on its path from sender to ultimate recipient.  The Mail eXchanger mechanisms of the domain name system [22, 27]  are used to identify the appropriate next-hop destination for a message being transported.