MTA transaction logging

The MTA&#x27;s optional logging of message traffic is enabled via the   channel option. Enabling  causes the MTA to write an entry to a    file each time a message passes through an MTA  channel. Such log entries can be useful if you wish to get statistics on how many messages are passing through the MTA (or through particular  channels), or when investigating other questions such as whether and  when a message was sent or delivered.

If you are only interested in gathering statistics on the number of messages passing through a few particular MTA channels, then you may  wish to enable the   channel option on just those  MTA channels of main interest. But more generally, many sites prefer to enable logging on all MTA channels; in particular, if you are trying to  track down problems, the first step in diagnosing some problems is to  notice that messages are not going to the channel you expected or  intended, and having logging enabled for all channels can help you spot  such issues.

In addition to the basic information always provided when   is enabled, additional, optional informational fields may also be logged in the   files,  controlled via various    MTA options. Particularly likely to be of interest are the ,   ,   ,   ,   , and    options.



 Enabling   allows correlation of  which entries relate to which message. 

 Enabling   allows  easier correlation of which entries from   files  from different systems correspond to the same message at the SMTP  level. 

 Enabling   makes it easier to  immediately spot how  many times delivery of a particular message file has been retried, and  can be useful in understanding when the MTA does or does not split a  message to multiple recipients into separate message file copies on  disk. 

 Enabling    causes the MTA to log TCP/IP connections, as  well as message traffic, to the   files by default;  alternatively, the     option may be used to  specify that connection log entries instead be written to    files. 

 When using   to cause  generation of TCP/IP connection entries, additionally enabling     allows correlation of which connection entries correspond  to which message entries. 

 is mostly of interest in the case of users who authenticate their message submission using the SMTP  AUTH command; in such cases,    causes logging of the  user identity (prefixed with an asterisk character if the identity was established by authentication). As of the 8.0 release, the  option can also be used to log the primary mail address associated with the authenticated identity and in the case of "U" connection log entries, the authentication mechanism used. 



The  and   entries may optionally be duplicated to syslog  via the    and     options.

See also:
 * logging Option
 * Transaction logging MTA options
 * Managing the MTA transaction log files
 * MTA transaction log entry format
 * Triggering effects from transaction logging with LOG_ACTION
 * log_messages_syslog MTA Option
 * log_connections_syslog MTA Option
 * log_syslog_prefix MTA Option
 * Monitoring the MTA
 * The MTA