ActiveXperts Network Monitor can check SMTP mail servers by establishing a connection on the remote TCP port (usually port 25) and do a handshake. By handshaking, ActiveXperts Network Monitor can verify that the remote server's SMTP protocol is working well.
An SMTP Mail Server rule requires the following parameters:
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 firstname.lastname@example.org:
TO: Spyros Sakellariadis <email@example.com> FROM: Judy <firstname.lastname@example.org> 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 (email@example.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 <firstname.lastname@example.org> FROM: Judy <email@example.com> DATE: Sat 22 Jun 1996 12:11:11 -0400 SUBJECT: Basic SMTP message X-Info: Evaluation version at pop3.dcnw.com Message-Id: <firstname.lastname@example.org> 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 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 email@example.com sends a message to firstname.lastname@example.org, 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 <email@example.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 <firstname.lastname@example.org>
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: