Monitor SMTP | ActiveXperts Network Monitor and Internet Protocols

Introduction to SMTP

RFC 822 - MESSAGE HEADER AND BODY

RFC 822, Format of ARPA Internet Text Messages, was issued in August 1982. It defines the basic format for the message headers and the message body in all SMTP messages. This shows a basic Internet mail message sent by a user Judy with e-mail address judy@dcnw.com:

TO: Spyros Sakellariadis <spyros@patmos.sakes.com>
FROM: Judy <judy@dcnw.com>
DATE: Sat 22 Jun 1996 12:11:11 -0400
SUBJECT: Basic SMTP message

Hello!

This message is sent to Spyros Sakellariadis, with an e-mail address in the domain patmos.sakes.com (spyros@patmos.sakes.com). The header content is analyzed by the mail system receiving the message, and the message is delivered to Spyros’s mailbox. The message was sent by Judy in the e-mail domain dcnw.com. The header in this message is very simple, and the body of the message is simpler still - Spyros will receive a message that says "Hello!"

The example above has four header fields: TO, FROM, DATE, and SUBJECT. The field names were supplied automatically by Judy’s SMTP mailing system. The field bodies, supplied by Judy, are followed by a carriage return and line feed, and the four header fields are followed by a single blank line that separates them from the body of the message.

The minimum required header is three fields: DATE, FROM, and either a TO field or a BCC field. The example above clearly satisfies this minimum requirement. RFC 822 allows other header fields, including SUBJECT, CC, and COMMENT.

Several headers are added in the following sample:

TO: Spyros Sakellariadis <spyros@patmos.sakes.com>
FROM: Judy <judy@dcnw.com>
DATE: Sat 22 Jun 1996 12:11:11 -0400
SUBJECT: Basic SMTP message
X-Info: Evaluation version at pop3.dcnw.com
Message-Id: <18143885500034@dcnw.com>

Hello!

To the original headers, Judy's mail server added two more, the X-Info and the Message-Id headers. These headers comply with RFC 822 and are added by SMTP mailers to let the recipients trace the messages and know what type of systems handled the message along the way. In this case, the X-Info was added by the NTMail server based on a configuration parameter entered in the NTMail administrator, and the Message-Id was added automatically for identification purposes.

RFC 821 - SMTP COMMANDS

RFC 821 defines how SMTP hosts on the Internet transfer mail. SMTP operates at the application layer of the OSI model, and only over TCP/IP. To effect an SMTP transfer, one messaging system makes a connection to TCP port 25 of another messaging system and sends it a series of codes and data. For example, if judy@dcnw.com sends a message to spyros@patmos.sakes.com, then Judy's messaging server contacts Spyros's messaging server and sends it the information. SMTP refers to the interaction between the two messaging servers.

Once the transmission channel is established, the SMTP-sender sends a MAIL command indicating the sender of the mail. If the SMTP-receiver can accept mail it responds with an OK reply. The SMTP-sender then sends a RCPT command identifying a recipient of the mail. If the SMTP-receiver can accept mail for that recipient it responds with an OK reply; if not, it responds with a reply rejecting that recipient (but not the whole mail transaction). The SMTP-sender and SMTP-receiver may negotiate several recipients. When the recipients have been negotiated the SMTP-sender sends the mail data, terminating with a special sequence. If the SMTP-receiver successfully processes the mail data it responds with an OK reply. The dialog is purposely lock-step, one-at-a-time.

Judy's messaging server contacts Spyros's server; Spyros's server replies. Judy's says it wants to send mail; Spyros's replies that it is ready to accept mail. Judy's indicates who the mail is from; Spyros's acknowledges, and so forth. The actual commands are defined in Section 4 of the RFC and include

HELO
MAIL FROM
RCPT TO
VRFY
DATA
QUIT

We will see how each of these commands is used shortly. (For a complete list of the commands, download the RFC from the Internet at the address given at the end of this section.)

Each dispatched command includes some sort of data. For example, the sender may issue the command

RCPT TO: Spyros <spyros@patmos.sakes.com>

This command tells the receiver that mail should be delivered to the mail server for the domain patmos.sakes.com. If the receiver is the correct system, it accepts the message and saves it to the mailbox for Spyros; otherwise, it may reject or forward the message.

The receiver acknowledges every command from the sender with a numeric code - called a result code - and, optionally, some text. For example, the receiver might reply to the above RCPT TO command with

250 OK - Recipient Spyros <spyros@patmos.sakes.com>

This reply does not necessarily mean that the mailbox for Spyros is a valid one; it only indicates that the syntax of the sender’s command was correct:

• The sending server (host pop3.dcnw.com) initiates a TCP connection to port 25 of the receiver (host chora.sakes.com). The receiving server sends back code 220 if it is ready to receive mail.
• The sender requests an SMTP session by sending a HELO command, followed, optionally, by its name. The receiver returns an OK message if it accepts the session.
• The sender forwards the identity of the user sending the message (judy@dcnw.com) using the MAIL FROM command. Note that the domain name (dcnw.com) is not the same as the specific host relaying the mail (pop3.dcnw.com). The receiver returns an OK message if the syntax is correct.
• The sender sends a list of one or more recipients (spyros@patmos.sakes.com) of the message. If the message is addressed to multiple recipients (e.g., TO: Spots <spots@patmos.sakes.com>, Maria <maria@patmos.sakes.com>), the sender splits this address into multiple RCPT TO lines. Note again that the mail domain (patmos.sakes.com) does not have to be the same as the receiver’s host name (chora.sakes.com).
• The sender informs the receiver it is about to send the mail message by issuing the DATA command. The receiver confirms it can receive the data.
• The sender transmits the data as an RFC 822 message in 7-bit ASCII characters. To signal the end of the message, the sender puts a single "." on a line by itself, and the receiver confirms receipt by sending an OK message.
• After the data has been sent successfully, the sender repeats the process if it has another message to send; otherwise, the sender terminates the process by sending a QUIT message.