How to Enable and Interpret the Smtp.log File (155455)

MORE INFORMATION

The remainder of this article is organized into two sections: "SMTP Basics" and "Interpreting the Smtp.log File."

SMTP Basics

This section includes a general introduction to SMTP design, connections, and session commands and syntax.

For information about how to enable the SMTP log in Outlook Express, please see the following article in the Microsoft Knowledge Base:

• SMTP Design

The Simple Mail Transfer Protocol (SMTP) is a text-based protocol using the US ASCII set of characters, a subset of the ASCII character set containing octet values 00h-7Fh (0d-127d) inclusive. It provides message transport services across end-to-end reliable networks. Its sole requirements for a network-layer transport mechanism are ordered, reliable packet delivery.

SMTP is used by email clients to send messages to an SMTP server, and by SMTP servers to transport messages between intermediate 'hops' before delivery to a POP3 mailbox. The POP3 protocol, not covered in this article, is used to retrieve messages from a mailbox. For more information on POP3 and its use with Microsoft products, please see the following article in the Microsoft Knowledge Base: Because messages regularly contain information that contains values not within this range, there have been facilities designed to handle non-US ASCII data. When a message has content not defined within US ASCII (such as audio samples or bitmaps), a multiple-object facility, such as MIME, is used to encode it prior to transmission.

Support for any form of encoding is contained within the mail client. If a mail client receives a message containing encoded information, and the client does not support content encoding, the user will generally see gibberish.

NOTE: There is an update to the existing SMTP specification known as the Extension to SMTP (ESMTP). Not all mail servers on the Internet are ESMTP- capable, however they are becoming increasingly more common.

SMTP transfers involve a sender-receiver model where each participant can send, receive, and interpret session status messages from the other. The sender can connect directly to the terminal destination of the message or an intermediary.

The SMTP session is initiated by the sender and can be terminated by either the sender or the receiver.

• SMTP Connections

An SMTP server, typically implemented as a daemon process on a computer running a UNIX-based operating system, listens for traffic on TCP port 25. Although this port assignment is standard, many client software packages have a user-configurable option to change the port number to compensate for non-standard server implementations.

NOTE: To change this value in Microsoft Internet Mail and News (IMN), use the following steps:

1. On the Mail menu, click Options.
2. Click the Server tab, and then click Advanced Settings.
3. Enter the appropriate value in the Outgoing Mail (SMTP) Server box.
4. Click OK.

To change the SMTP server name, use the following steps:

1. On the Mail menu, click Options.
2. Click the Server tab.
3. Enter the appropriate value in the Outgoing Mail (SMTP) box.
4. Click OK.

• SMTP Session Commands & Syntax

For the purpose of discussion, the peers in an SMTP session will be differentiated into SMTP-sender and SMTP-receiver. The sender is assumed to be either mail client software or another SMTP server. The receiver is always an SMTP server, except in the case where an SMTP server is delivering mail to a POP3 mailbox.

Certain semantics are always followed in SMTP connections. One is that any command issued from the SMTP-sender will always receive a response. Responses are both meta-linguistic and numeric and take two basic forms: OK(250) and an error or failure code followed by appropriate verbiage.

It is stated explicitly in RFC821 that all command-response sequences occur one at a time. Progress from one command to another is not possible until a response to a previous command has been received. For a complete list of error codes, see RFC821.

In addition, the scope of this article covers the commands most likely to be seen while examining the Smtp.log produced by IMN. For a complete listing and explanation of SMTP and ESMTP commands, see the respective RFCs.

The order of the commands presented below does not imply that there are no other possible sequences of commands. The following commands and explanations outline a simple connection.

The following abbreviations are used in this article:

SP : SPACE <ASCII 20h (32d)>

CRLF : CARRIAGE RETURN+LINEFEED <ASCII 0Dh+0Ah (13d+10d)>

The following notation is used when explaining reply codes:

nnn : numeric reply code
<...> : code meaning
() : text message may be present, wording varies
[...] : comments

• Connection Established

When an SMTP-sender wishes to send mail, it first opens a connection to TCP port 25 on the SMTP-receiver.

When the connection is established, the SMTP-receiver responds with the system-ready reply code: 220-<domain name>. When troubleshooting SMTP connections, if upon connection a system-ready response is not received, the server may be malfunctioning or down.

For more information on troubleshooting SMTP connections, please see the following article in the Microsoft Knowledge Base:

• HELLO Command

After 220-<domain> is received, the SMTP-sender starts the session by issuing one of two HELLO commands. The type of HELLO command determines if SMTP or ESMTP will be used:

Not only does the HELLO command start a session, it also verifies that both the sender and receiver are in the initial states. Being in the 'initial' state simply means that there are no transactions-in-progress, or that the receiver has not 'hung.' Expected responses to the HELLO command are:

 For HELO : 250-<requested mail action okay, completed> (receiver name)

 For EHLO : 250-<requested mail action okay, completed> (receiver name)
            250-(extended services supported...)
            250-(...end-of-list)
				

            502-<command not implemented>
            504-<command parameter not implemented> [ESMTP not supported]

 For Both : 421-<service not available, closing channel> (domain)
            500-<syntax error, command unrecognized>
            501-<syntax error in arguments> (suggested use) [not likely]
				

If the SMTP-receiver gets an error response to the EHLO command, it must either issue the HELO or QUIT commands.

NOTE: The 421 reply can be used in response to any command if the server knows that the SMTP service is not available or if the server is about to shut down.

• MAIL Command

After a 250 response is received from the HELLO command, the MAIL command is used to initiate a mail transaction. The command is issued as follows:

   MAIL FROM: <reverse-path> CRLF
				

The <reverse-path> value is passed as an argument, and can be either 'user@host.dom' or just 'user.' In the event 'user' is what is passed to the server, the server's domain name will be tacked onto the end. The <reverse-path> is the address to which any response will go.

For example, "MAIL FROM: jdoe@somewhere.com" would be a valid MAIL command. By the same token, "MAIL FROM: jdoe" would also work. If the MAIL command has been received correctly,

   250-<requested mail action okay, completed> ()
				

is expected in reply. Expected alternate responses to the MAIL command are:

• RECIPIENT Command

The RECIPIENT command follows a 250 response from the MAIL command. It is used to specify either a single recipient, multiple recipients, or a mailing list. The command is issued as follows:

   RCPT TO: <forward-path> CRLF
				

The <forward-path> value is passed as an argument, and can be either 'user@host.dom' or just 'user.' In the event 'user' is what is passed to the server, the server's domain name will be tacked onto the end. The <forward-path> is the address to which the message will be delivered.

The forward-path value can contain two different types of addressing data:

   Destination address : USER@HOST2.DOM or USER
   Source route        : @HOST1.DOM:USER@HOST2.DOM
				

Most RCPT TO: entries will be observed with the destination address version of the forward-path value. For more information on the handling of source routes, please see RFC821.

For example, "RCPT TO: janed@elsewhere.com" would be a valid RECIPIENT command. By the same token, "RCPT TO: janed" would also work, provided that user's POP3 mailbox is on the same server that originated the message. If the RECIPIENT command has been received correctly, we expect:

   250-<requested mail action okay, completed> ()

in reply. Expected alternate responses to the RECIPIENT command are:

   Error   : 421-<SMTP service not available; server shutdown imminent>
             500-<syntax error, command unrecognized>
             501-<syntax error in arguments> ()
             503-<bad sequence of commands>

   Failure : 450-<req. mail action not taken: mailbox unavailable>
             451-<req. action aborted: local error in processing>
             452-<req. action not taken: insufficient system storage>
             550-<req. action not taken: mailbox unavailable>
             551-<user not local; please try <forward-path>>
             552-<req. mail action aborted: exceeded storage allocation>
             553-<req. action not taken: mailbox name not allowed>
				

• DATA Command

When all the recipient addresses for a message have been entered, and the SMTP-receiver has issued a 250 reply, the next command to follow is the DATA command. The command syntax is:

   DATA CRLF
				

The SMTP-receiver will respond with

   354-<start mail input; end with <CRLF>.<CRLF>> ()
				

if the DATA command and the information sure to follow can be processed at that time. If the 354 reply is received, all of the information that comprises the message: headers, body text, encoding, etc. will be streamed to the SMTP-receiver. There are two times that we expect a response to the issuance of the DATA command: after it is issued, and when it completes. Completion of the DATA command is marked the SMTP-receiver's reception of the <CRLF>.<CRLF> sequence.

Expected alternate responses to issuance of the DATA command are:

   Success : 354-<start mail input; end with <CRLF>.<CRLF>> ()

   Error   : 421-<SMTP service not available; server shutdown imminent>
             500-<syntax error, command unrecognized>
             501-<syntax error in arguments> ()
             503-<bad sequence of commands>

   Failure : 451-<req. action aborted: local error in processing>
             554-<transaction failed>

Expected alternate responses to completion of the DATA command are:

   Success : 250-<requested mail action okay, completed> ()

   Failure : 451-<req. action aborted: local error in processing>
             452-<req. action not taken: insufficient system storage>
             552-<req. mail action aborted: exceeded storage allocation>
             554-<transaction failed>

 - RESET Command

When the RESET command is issued, all of the SMTP-receiver's buffers are
cleared. Typically, this command is issued upon connection, after the
HELLO command, to cancel a current MAIL command, or after a DATA command
is completed. Usage of the RESET command follows:

   RSET CRLF

The SMTP-receiver must respond with

   250-<requested mail action okay, completed> ()

Any other response would indicate that the command was entered improperly
(not likely when a program does it) or that there is a problem with the
SMTP-receiver. The possible responses are listed below.

 Error   : 421-<SMTP service not available; server shutdown imminent>
           500-<syntax error, command unrecognized>
           501-<syntax error in arguments> ()
           504-<command parameter not implemented>

 - NO OPERATION Command

The NO OPERATION command has no effect whatsoever on the connection. It
does not affect any of the SMTP-receiver's buffers, or any MAIL
transaction currently in progress. It can be used by the SMTP-sender to
keep the connection open in lieu of an SMTP-receiver timeout. Usage
follows:

   NOOP CRLF

The SMTP-receiver should send a 250 reply to the NO OPERATION command. The
only other possible responses are a 500 reply, indicating incorrect
command syntax, or the 421 reply, indicating that the SMTP service will be
shutting down shortly.

 - QUIT Command

The QUIT command is used by the SMTP-sender to request that the connection
between the itself and the SMTP-receiver be closed. This command can be
issued at any time. Command usage follows:

   QUIT CRLF

Upon reception of a QUIT command, the SMTP-receiver issues the following
response to the SMTP-sender:

   221-<<domain> service closing transmission channel>

The only other possible response is a 500 reply which indicates that the
syntax used was incorrect. This is not likely to occur.
				

Interpreting the Smtp.log File

SMTP logging is not enabled by default. To enable SMTP logging in Outlook Express, click Options on the Tools menu, click the Advanced tab, and then click the Mail Transport check box to select it. To enable SMTP logging in Internet Mail and News, you must add or change the following entries in the registry:

   HKEY_CURRENT_USER\Software\Microsoft\Internet Mail and News\Mail

   Value Name : "Log SMTP (0/1)"  (without quotes)
   Value Type : dword
   Value Data : 00000001

   Value Name : "Log File (SMTP)" (without quotes)
   Value Type : string
   Value Data : <path to log file>

In order to fit all the pertinent data for each entry on one line, the
'SMTP:' tag and the time stamp at the beginning of each line have been
removed.
				

Log Example

This is a fault-free connection in which one message is sent to an SMTP
server with ESMTP extensions enabled.

 01) Microsoft(r) Plus!  for  Windows(r)  95 4.70.1155
 02) SMTP Log started at Thu Aug 01 17:22:27

Lines 1 and 2 are plugged in every time Internet Mail and News is
launched.

 03) [db] Connecting to 'smtp.host.com'.
 04) [db] srv_addr = nnn.nnn.nnn.nnn

Lines 3 and 4 indicate the friendly name and the IP address of the SMTP
server specified in the Internet Mail and News configuration.

 05) [rx] 220 smtp.host.com ESMTP server ready Thu, 1 Aug 1996 15:24:22 -
          0700
 06) [tx] EHLO smtp-client
 07) [rx] 250-smtp.host.com
 08) [rx] 250-HELP
 09) [rx] 250-EXPN
 10) [rx] 250-XREMOTEQUEUE
 11) [rx] 250 PIPELINING
 12) [tx] RSET
 13) [rx] 250 Ok resetting state

Line 5 indicates that the communications channel between the SMTP sender
and receiver has been successfully opened. This prompts the EHLO command
to start an ESMTP session. Note that the EHLO command is followed by the
computer name of the client, not the user-id that is sending mail.

Lines 7-11 form the SMTP-receiver's response to the EHLO command. This
tells us that the server implements:

   a) the standard SMTP HELP and EXPN commands

   b) one nonstandard SMTP extension XREMOTEQUEUE

   c) one standard SMTP extension PIPELINING

The SMTP-sender issues the RSET command on Line 12 as a precautionary
measure to flush the SMTP-receiver's forward- and return-path, mail data,
and transaction buffers.

 14) [tx] MAIL FROM:<jdoe@somewhere.com>
 15) [rx] 250 Sender <jdoe@somewhere.com> Ok

Line 14 shows the MAIL command issued with the required <reverse-path>
argument. In Line 15, the SMTP-receiver send the 250 reply, re-stating the
SMTP-sender's reverse-path. Only the 250 reply is absolutely required, not
all SMTP servers will supply this information, or in the same format.

 16) [tx] RCPT TO:<janed@elsewhere.com>
 17) [rx] 250 Recipient <janed@elsewhere.com> Ok

In Line 16, the SMTP-sender issues the RECIPIENT command with the
<forward-path> argument. The SMTP-receiver returns the 250 reply
reiterating the destination address.

 18) [tx] DATA
 19) [rx] 354 Ok Send data ending with <CRLF>.<CRLF>
 20) [tx]
 21) .
 22) [rx] 250 Message received: 19960801222422078.AAA43@smtp-client

The SMTP-sender issues the DATA command in Line 18, gets the go-ahead from
the SMTP-receiver, and begins transmitting the content of the message.

Because messages that contain encoded objects can be several thousand
bytes in size, the log file does not display the transmitted data. Only
the <CRLF>.<CRLF> sequence (line 21) is shown.

In Line 22, the SMTP-receiver acknowledges the message, stamps it with an
SMTP-id, and transmits it.

 23) [tx] QUIT
 24) [rx] 221 smtp.host.com ESMTP server closing connection
 25) [db] Connection to 'smtp.host.com' closed.
				

The SMTP-sender issues the QUIT command. The 221 reply indicates that the SMTP-receiver has accepted the QUIT command and closed the connection, evidenced in Line 25.

This example is typical of most SMTP sessions. In the event that the SMTP- sender has more than one message queued in the Outbox, the session will recurse the RESET->MAIL->RECIPIENT->DATA sequence until all messages have been sent.

If the Smtp.log file you are examining contains any response other than the expected positive response for any of the commands issues (except EHLO in a non-ESMTP environment), refer to the section in this article dealing with that command.

This article is intended as a reference to be used when all other troubleshooting has failed. The majority of SMTP transmission errors are going to be related to either hardware configuration errors (modem, serial port, initialization string), TCP/IP connectivity problems, or client-side malfunction.

As a general rule, always rule out any other possible source of error before troubleshooting an odd log file entry.