SMTP – Simple Mail Transfer Protocol

SMTP – Simple Mail Transfer Protocol

SMTP, defined in RFC 5321, is at the heart of internet electronic mail. As mentioned above, SMTP transfers messages from sender’s mail servers to the recipient’s mail servers. SMTP is much older than HTTP. (The original SMTP RFC dates back to 1982, and SMTP was around long before that.) Although SMTP has numerous wonderful qualities, as evidenced by its ubiquity in the internet, it is nevertheless a legacy technology that possesses certain archaic characteristics. For example, it restricts the body (not just the headers) of all mail messages to simple-7 bit ASCII. This restriction made sense in early 1980s when transmission capacity was scarce and no one was e-mailing large attachments or large image, audio, or video files. But today, in the multimedia era, the 7-bit ASCII restriction is a bit of a pain – it requires binary multimedia data to be encoded to ASCII before being sent over SMTP; and it requires the corresponding ASCII message to be decoded back to binary after SMTP transport. HTTP does not require multimedia data to be ASCII encoded before transfer.

To illustrate the basic operation of SMTP, let’s walk through a common scenario. Suppose Alice wants to send Bob a simple ASCII message.

  1. Alice invokes her user agent for e-mail, provides Bob’s e-mail address (for example,, composes a message, and instructs the user agent to send the message.
  2. Alice’s user agent sends the message to her mail server, where it is places in a message queue
  3. The client side of SMTP, running on Alice’s mail server, sees the message in the message queue. It opens a TCP connection to an SMTP server, running on Bob’s mail server.
  4. After some initial SMTP handshaking, the SMTP client sends Alice’s message into the TCP connection.
  5. At Bob’s mail server, the server side of SMTP receives the message. Bob’s mail server then places the message in Bob’s mailbox.
  6. Bob invokes his user agent to read the message at his convenience.

The scenario is summarized in figure 2.17

It is important to observe that SMTP does not normally use intermediate mail servers for sending mail, even when the two mail servers are located at opposite ends of the world. If Alice’s server is in Hong Kong and Bob’s server is in St. Louis, the TCP connection is a direct connection between the Hong Kong and St. Louis servers. In particular, if Bob’s mail server is down, the message remains in Alice’s mail server and waits for a new attempt – the message does not get placed in some intermediate mail server.

Let’s now take a closer look at how SMTP transfers a message from a sending mail server to a receiving mail server. We will see that the SMTP protocol has many similarities with protocols that are used for face-to-face human interaction. First, the client SMTP (running on the sending mail server host) has TCP establish a connection to port 25 at the server SMTP (running on the receiving mail server host). If the server is down, the client tries again later. Once this connection is established, the server and client perform some application-layer handshaking – just as humans often introduce themselves before transferring information from one to another, SMTP clients and servers introduce themselves before transferring information. During this SMTP handshaking phase, the SMTP client indicates the e-mail address of the sender (the person who generated the message) and the e-mail address of the recipient. Once the SMTP client and the server have introduced themselves to each other, the client sends the message. SMTP can count on the reliable data transfer service of TCP to get the message to the server without errors. The client then repeats this process over the same TCP connection it has other messages to send to the server; otherwise , it instructs TCP to close the connection.

Let’s next take a look at an example transcript of messages exchanges between an SMTP client (c) and an SMTP server (s) .The hostname of the client is and the hostname of the server is The ASCII text lines prefaced with C: are exactly the lines the server sends into its TCP socket. The following transcript begins as soon as the TCP connection is established.

S: 220


S: 250 Hello, pleased to meet you


S: 250 …Sender ok

C: RCPT TO: <>

S: 250 … Recipient ok


S: 354 Enter mail, end with “.” on a line by itself

C: Do you like ketchup?

C: How about pickles?


S: 250 Message accepted for delivery


S: 221 closing connection

In the example above, the client sends a message (“Do you like ketchup? How about pickles?”) from mail server to mail server As part of the dialogue, the client issues five commands: HELO (an abbreviation for HELLO), MAIL, FROM, RCPT TO, DATA and QUIT. These commands are self-explanatory. The client also sends a line consisting of a single period, which indicates the send of the message to the server. (In ASCII jargon, each message ends with CRLF.CRLF, where CR and LF stand for carriage return and line feed, respectively.) The server issues replies to each command, with each reply having a reply code and some (optional) English-language explanation. We mention here that SMTP uses persistent connections: If the sending mail server has several messages to send to the same receiving mail server, it can send all of the messages over the same TCP connection. For each message, the client beings the process with a new MAIL FROM:, designates the end of message with an isolated period, and issues QUIT only after all messages have been sent.

It is highly recommended that you use Telnet to carry out a direct dialogue with an SMTP server. To do this, issue

telnet serverName 25

where serverName is the name of a local mail server. When you do this, you are simply establishing a TCP connection between your local host and the mail server. After typing this line, you should immediately receive the 220 reply from the server. Then issue the SMTP commands HELO, MAIL FROM, RCPT TO, DATA, CRLF.CRLF, and QUIT at the appropriate times.