Tracking a Message Across the Various Log Files

The following describes how a message flows through the system, and at what point information gets written to the various log files. This description is meant to aid you in your understanding of how to use Message Server’s log files to troubleshoot and resolve problems. See Figure 8–2 to follow along.

1. A remote host makes a connection to the TCP socket on your messaging host, requesting SMTP service.

2. The MTA dispatcher responds to the request, and hands off the connection to your messaging host’s SMTP service.

   As the MTA is modular in design, it consists of a set of processes, including the job controller and the SMTP service dispatcher. The dispatcher takes the incoming TCP connection and sends it to the SMTP service. The SMTP service writes the message to disk to a channel area. The SMTP service understands the message’s envelope parameters, such as sender and recipient. Configuration entries in the system tell what destination channel it belongs to.

3. The dispatcher writes to the dispatcher.log file that it forked a thread and made the thread available to incoming connection from a certain IP address.

4. The SMTP server writes to its tcp_smtp_server.log file, recording the dialog of what happens when the remote host connected to it and sent a message. This log file gets created when dispatcher hands off to SMTP server on the host’s IP.

5. The SMTP server writes the message to a queue area on disk for a channel program such as tcp_intranet, and informs the job controller.

6. The job controller contacts the channel program.

7. The channel program delivers the message.

   Each channel has its own log file. However, these logs usually show the starting and stopping of the channel. To get more information, you need to enable debug level for the channel. However, as this can slow down your system and actually make problems more obscure if left on, you should only enable debug level when an actual problem is occurring.

   ---

   Note –

   For efficiency, if a channel is already running for an existing process, and a new message comes in, the system does not spawn a new channel process. The currently running process picks up the new message.

   ---

8. The message is delivered to its next hop, which could be another host, another TCP connection, and so forth. This information is written in the connection.log file.

   At the same time that the SMTP server writes the message to a queue area on disk, the channel responsible for the message writes a record in the mail.log_current, or mail.log file. The record shows such information as the date and time the message was enqueued, the sender, the recipient, so forth. See MTA Message Logging Examples for more information. The most useful file for tracing the message is the mail.log_current file.