The basic of Simple Mail Transfer Protocol (SMTP)

Simple Mail Transfer Protocol (SMTP) is an Internet standard for e-mail transmission across TCP/IP networks. It was first defined by RFC 821 by Jonathan Postel in 1982, and last updated in RFC 5321 which includes the extended SMTP (ESMTP) additions. Even with multimedia attachments and HTML encoding prevalent in e-mail messages today, the technology behind message transfer has not changed significantly since early 1980s. This article is compiled with the purpose of providing basic introduction on SMTP so that the reader can follow reasonable technical discussions.

While e-mail servers and other mail transfer agents use SMTP to send and receive mail messages, user-level client mail applications typically only use SMTP for sending messages to a mail server for relaying. This is due to SMTP is a delivery protocol only. It cannot pull messages from a remote server on demand. For receiving messages, client applications usually use either the Post Office Protocol (POP) or the Internet Message Access Protocol (IMAP) or a proprietary system (such as Microsoft Exchange or Lotus Notes/Domino) to access their mail box accounts on a mail server.

The three parts to e-mail message transfer are the Mail Transfer Agent (MTA), the Mail Delivery Agent (MDA), and the Mail User Agent (MUA). When an e-mail is sent, the message is routed from server to server, all the way to the recipient's e-mail server.

When e-mail is submitted by a e-mail client (MUA) to a mail server tasked with transporting e-mails (MTA) using SMTP on TCP port 25, MTA uses the Domain name system (DNS) to look up the mail exchanger record (MX record) for the recipient's domain. The returned MX record contains the name of the destination SMTP server. Once the destination server is known, MTA initiates an SMTP transaction with the other end to send the mail. The mail is sent, and subsequently processed by the destination server. It then does one of several things with the mail, ranging from storing the e-mail for later collection via POP3 or IMAP by authenticated mail clients (MUAs), to forwarding the message on to another address, to discarding the message if it not for a valid recipient. The exact actions depend on the configuration on the destination server for that particular address.

SMTP is a connection-oriented protocol. It operates by sending lines of text back and forth between the client and the server. The client sends commands and eventually the e-mail message, and the server sends back responses to tell the client if the server accepted the command or if something went wrong. A session may include zero or more SMTP transactions. An SMTP transaction consists of three command/reply sequences. They are:

1. MAIL command: indicates who is sending the mail. For example,
   MAIL FROM: <taro@gmail.com>

   Any returned mail will be sent back to this address.

2. RCPT command: indicates who is recieving the mail. For example,
   RCPT TO: <fuji@gmail.com>.
 
   You can indicate more than one user by issuing multiple RCPT commands.

3. DATA to send the message text. This is the content of the message, as opposed to its envelope. It consists of a message header and a message body separated by an empty line. DATA is actually a group of commands, and the server replies twice: once to the DATA command, to acknowledge that it is ready to receive the text, and the second time after the end-of-data sequence, to either accept or reject the entire message. The mail data may contain any of the 128 ASCII character codes, although experience has indicated that use of control characters other than SP, HT, CR, and LF may cause problems and SHOULD be avoided when possible. It is terminated by a line containing only a period, that is, the character sequence "<CR><LF>.<CR><LF>"

Besides the intermediate reply for DATA, each server's reply can be either positive (2xx reply codes) or negative. Negative replies can be permanent (5xx codes) or temporary (4xx codes). A reject is a permanent failure by an SMTP server; in this case the SMTP client should send a bounce message.

SMTP transport example

In SMTP context, the client is the computer that is sending e-mail, and the server is the computer that is receiving it. Thus we say SMTP clients (or SMTP senders) send e-mail to SMTP servers, although the machines involved may both be servers in the general sense.
The following SMTP communication example was modified from RFC 821 showing mail sent by Smith at host Alpha.ARPA, to Jones, Green, and Brown at host Beta.ARPA. Host Alpha is assumed to contact host Beta directly. The client (C) notifies the server (S) of the originating e-mail address of the message in a MAIL FROM command. Each successful reception and execution of a command is acknowledged by the server with a result code and response message (e.g., 250 Ok).

    C: MAIL FROM:<Smith@Alpha.ARPA>
    S: 250 OK

    C: RCPT TO:<Jones@Beta.ARPA>
    S: 250 OK

    C: RCPT TO:<Green@Beta.ARPA>
    S: 550 No such user here

    C: RCPT TO:<Brown@Beta.ARPA>
    S: 250 OK

    C: DATA
    S: 354 Start mail input; end with <CRLF>.<CRLF>
    C: Blah blah blah...
    C: ...etc. etc. etc.
    C: .
    S: 250 Ok: queued as 12345
    C: QUIT
    S: 221 Bye

The transmission of the body of the mail message is initiated with a DATA command after which it is transmitted verbatim line by line and is terminated with an end-of-data sequence. This sequence consists of a new-line (<CR><LF>), a single full stop (period), followed by another new-line.

If you like to try the above example in your computer systems, simply open your telnet program in a command prompt. For example:

---
C:\>telnet gmail-smtp-in.l.google.com 25
220 mx.google.com ESMTP mo5si6627890pbc.358
mail from: <kiki@gmail.com>
250 2.1.0 OK r8si4926545pay.11
...
---

Hopefully you now have learned something to follow discussions of SMTP e-mail delivery. SMTP is a very easy protocol to learn and once you understand it's architecture, you can use it in your scripts and everything else. There are many more interesting features available in SMTP. It is good to read through the original RFC 821 to understand better about the original concepts of this TCP/IP fundamental protocol.