9.12 SMTP logging

---

You enable logging on an SMTP virtual server to gain an insight into how Exchange conducts SMTP conversations with other servers or as an aid to debug a problem. After you enable logging for a virtual server, Exchange records details of communications generated by all the connectors that use the virtual server.

You have to enable logging separately for each SMTP virtual server. To start logging, select the virtual server and view its properties, then check the box and select the log format, as shown in Figure 9.44. Afterward, stop and restart the virtual server to begin the logging process. You do not need a restart if you change logging properties afterward-for example, if you decide to change the interval for log file rollover from hourly to daily. Note that you need to stop and restart the virtual server through the cluster administration tool if Exchange is running on a cluster.

Figure 9.44: Enabling logging for the default SMTP virtual server.

By default, you find SMTP logs C:\WINNT\SYSTEM32\LOGFILES\ SMTPSVCx\, where "x" is the number of the server that you want to work with. The default SMTP virtual server is 1. Exchange can generate SMTP logs in four formats: IIS Log File Format, NCSA Common Log File Format, and W3C Extended Log File Format are all text-based formats. ODBC Logging requires a connection to an ODBC-compliant database, such as SQL, which then generates a small additional load on the server. The major advantage of using a database is its ability to handle very large amounts of data, which is useful if you want to analyze data captured from a very busy server, which can easily amount to several hundred megabytes. Most of the servers in use today can comfortably support the load generated by directing logging data to a database, but you may not want to get involved in the additional complexity of configuring the database. Unless you really need to capture data in ODBC format, use a text format-preferably W3C, since this gives you maximum control over the fields written into the log through the Extended Property page (Figure 9.45). The other text formats supply a predefined set of data that you cannot change.

Figure 9.45: Extended properties for an SMTP log.

Even if you begin logging with a text format, it is possible to convert a log file into a database to perform analysis. Indeed, administrators often use Excel for this purpose, because it will read any of the text formats; it is sometimes easier to use Excel to navigate large quantities of data than to simply edit it with a text editor.

Any production Exchange server generates a lot of SMTP traffic, so it is unwise to keep the log files on the same drive as the Windows binaries. Select another drive that handles little I/O and has sufficient free disk space. A server that handles email and public folder replication traffic can generate 500 MB or more of logs daily (any of the text formats). While logging stops if disk space is exhausted, so does everything else that uses the same disk. This is the fundamental reason not to use the same drive as Windows. Note that neither Exchange nor Windows purges these logs, so this is another manual task.

You can configure when Exchange switches log files through the General property page. The most common option is daily, using local time to control file naming and rollover. This means that Exchange creates a new log file at midnight and names it according to the selected file format. For example, the file ex030101.log is a daily log in W3C format for January 1, 2003, whereas in030101.log is from the same date in IIS format. Hourly logs add the hour number (in 24-hour format) to the end of the log file name. For example, ex03010113.log is the log file beginning at 1:00 P.M. on January 1, 2003.

If you elect not to use local time, the rollover time differs depending on format. W3C uses midnight GMT, while IIS and NCSA use local midnight. To avoid confusion and to ensure that you have a good idea where to look for data if you need to trace a specific connection, use the same log format and rollover time throughout the organization. The fields written into a W3C format log file are controlled through the Extended Properties page, as shown in Figure 9.45. Since virtual servers run under IIS, some of these fields do not hold useful data for tracing SMTP communications.

Figure 9.46 illustrates sample data that you can expect to capture in an SMTP log. In this case, the DBOEXCVS1 server initiates a connection to the DEMEXB12 server with the EHLO command. DEMEXB12 responds and the two servers establish a secure connection using the GSSAPI command. The certificate data used follows the GSSAPI command. After successful authentication, DBOEXCVS1 issues an X-LINK2STATE command to exchange link state data, so we know that this connection is between two Exchange 2000/2003 servers across a routing group or SMTP connector. After the exchange of link state information, DBOEXCVS1 begins to send a new message by issuing the MAIL FROM command, following with an XEXCH50 command to establish that the receiving server can accept Exchange-specific data (MAPI properties). Finally, Exchange uses the BDAT command to send a stream of binary data containing the message content, followed by the QUIT command to terminate the message.

Figure 9.46: Examining an SMTP log file.

Note that an SMTP virtual server can handle concurrent transactions from multiple sources and write data from all transactions into the log as they occur. Thus, you end up with a log containing interleaved transactions rather than a set of clearly segregated transactions. As it happens, the extract shown in Figure 9.46 refers to a single message from the initial EHLO to the BDAT command that sends the message content. Dealing with interleaved content is not a major problem as long as you know that this is the case, but it can sometimes be confusing when you attempt to follow the exact steps that a transaction has taken. To avoid confusion, try to use a known fact about the message that you want to track (such as the sender, the originating server, the time when the message was sent) to ensure that any particular entry belongs to the targeted message. It is also a good idea to work through some sample data taken from test servers that relate to well- understood scenarios (e.g., a message going to recipients in another routing group) before you attempt to interpret logs from production servers. Apart from anything else, you will have a known reference point to consult if you ever meet entries that you do not understand.

As mentioned earlier, SMTP logs occupy lots of space, so you should not enable logging on a production server unless necessary. Use data recorded by test servers to understand the normal flow of messages and to know what you expect to see in a log. This will make it much easier to debug problems when the need arises.

---