Simple Mail Transfer Protocol
RFC 821 and RFC 822, published in August 1982, define the Simple Mail Transfer Protocol, more commonly abbreviated to SMTP. The opening words of RFC 821 summarize the purpose of this protocol quite succinctly…"The objective of the Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently." (RFC 821)
There are three main areas of messaging which SMTP standardizes. These are address format, message content and message delivery.
Address format has changed little since the original RFC which specified that senders and receivers should be identified by a user name and domain name in the format
username@domainname, as in
As for content, the original specification stated that messages should contain no more than 1000 characters and that these should all be 7-bit ASCII characters (i.e. the letters, numbers and punctuation that form the American English character set). The increasing need to transmit messages to users who did not use American English caused e-mail vendors to supplement the specification by providing support for additional character sets. At the same time, the desire to send longer messages – and to send attachments with the message – meant that vendors added support for programs such as UUENCODE which is able to convert binary data such as bitmaps or executable files into and out of text format for transmission.
One of the major problems with this solution was the fact that attachments encoded in a format such as UUENCODE could not pass through gateways to X.400 systems. The X.400 standard stated that attachments should be converted to (not encoded in) a text format or else be discarded. To address this and other limitations with existing 7-bit encoding methods, a newer technique, called Multipurpose Internet Mail Extensions (MIME), was developed in 1992. Defined by RFC 1521, this standard has now been adopted by many vendors.
To understand the delivery mechanism employed by SMTP, have a look at the diagram below which illustrates the SMTP model.
A user makes a mail request and this causes an SMTP sender to initiate a two-way transmission channel to an SMTP receiver on TCP Port 25. The SMTP sender sends a number of commands to the SMTP receiver and this in turn sends back replies in response to these commands. The sequence of commands and responses is described below:
The first command sent by the SMTP sender is a HELO command, indicating the sender's domain. The receiver acknowledges this with an OK.
Next, a MAIL command is sent to indicate the sender of the mail message. If the receiver can accept mail it returns an OK reply.
Then, the SMTP sender issues one or more RCPT commands indicating the recipients of the message. The SMTP receiver responds to each of these commands in turn indicating whether or not it can accept messages for each of the recipients.
The next stage is the transmission of the message data which ends with a special closure sequence. If the SMTP receiver was able to process the data successfully it responds with another OK reply.
- Finally, the sender terminates the connection with a QUIT command. That's all there is to it!
The sequence below shows the commands and responses sent between the sender and receiver for a typical SMTP message. (Bold text indicates commands sent from the sender).
<connection made on port 25> 220 exserver.microsoft.com ESMTP Server (Microsoft Exchange Internet Mail Servic e 5.5.1960.3) ready HELO test.com 250 OK MAIL FROM: email@example.com 250 OK - mail from <firstname.lastname@example.org> RCPT TO: email@example.com 250 OK - Recipient <firstname.lastname@example.org> DATA 354 Send data. End with CRLF.CRLF You owe me $50 250 OK QUIT 221 closing connection
The SMTP model works well for transferring messages between servers and also for transferring messages between servers and clients on a local area network. However, it is not very good for transferring messages to clients connecting to the Internet by modem. There are several reasons for this, but one of the most significant is that SMTP, by itself, does not provide for any storage mechanism. Consequently, the recipient of the mail message must be connected when the SMTP sender sends the mail for the mail to be delivered correctly. In order to solve this problem, Post Office Protocol version 3 was developed.