Exim writes four different log files called `mainlog', `rejectlog', `paniclog', and `processlog' into a sub-directory of its spool directory called `log', unless a compile-time option called LOG_FILE_PATH or a runtime option called `log_file_path' is defined to specify a different directory and template for the file names. The template has a wild portion which is replaced by `main', `reject', `panic', or `process' when writing to a log file. See the comments in `src/EDITME' for more details of this. In the text below, the default file names are used.
A utility script called `exicyclog' which renames and compresses the main and reject logs each time it is called is provided. The maximum number of old logs to keep can be set. It is suggested this is run as a daily `cron' job. A Perl script called `eximstats' which does simple analysis of main log files is also provided. See chapter "Exim utilities" for details of both these utilities.
An Exim delivery process opens the main log when it first needs to write to it, and it keeps the file open in case subsequent entries are required -- for example, if a number of different deliveries are being done for the same message. However, remote SMTP deliveries can take a long time, and this means that the file may be kept open long after it is renamed if `exicyclog' or something similar is being used to rename log files on a regular basis. To ensure that a switch of log files is noticed as soon as possible, Exim calls `stat()' on the main log's name before reusing an open file, and if the file does not exist, or its inode has changed, the old file is closed and Exim tries to open the main log from scratch. Thus, an old log file may remain open for quite some time, but no Exim processes should write to it once it has been renamed.
The format of the single-line entry in the main log that is written for every message received is shown in the example below, which is split over several lines in order to fit it on the page:
1995-10-31 08:57:53 0tACW1-0005MB-00 <= kryten@dwarf.fict.book H=mailer.fict.book [123.123.123.123] U=exim P=smtp S=5678 id=<incoming message id>
The H and U fields identify the remote host and record the RFC 1413 identity of the user that sent the message, if one was received. The number given in square brackets is the IP address of the sending host. If there is just a single host name in the H field, as above, it has been verified to correspond to the IP address (see the `host_lookup' option). If the name is in parentheses, it was the name quoted by the remote host in the SMTP HELO or EHLO command, and has not been verified. If verification yields a different name to that given for HELO or EHLO, then the verified name appears first, followed by the HELO or EHLO name in parentheses.
Misconfigured hosts (and mail forgers) sometimes put an IP address, with or without brackets, in the HELO or EHLO command, leading to entries in the log containing things like
H=(10.21.32.43) [123.99.8.34] H=([10.21.32.43]) [123.99.8.34]
which can be confusing. Only the final address in square brackets can be relied on. For locally generated messages, the H field is omitted, and the U field contains the login name of the caller of Exim.
For all messages, the P field specifies the protocol used to receive the message, and the id field records the existing message id, if present. The size of the received message is given by the S field. When the message is delivered, headers may get removed or added, so that the size of delivered copies of the message may not correspond with this value (and indeed may be different to each other).
If the `log_received_sender' option is on, the unrewritten original sender of a message is added to the end of the log line that records the message's arrival, after the word `from'. If the `log_received_recipients' option is on, a list of all the recipients of a message is added to the log line, preceded by the word `for'. This happens after any unqualified addresses are qualified, but before any rewriting is done. If the `log_subject' option is on, the subject of the message is added to the log line, preceded by `T=' (T for `topic', since S is already used for `size').
A delivery error message is shown with the sender address `<>', and if it is a locally-generated error message, this is normally followed by an item of the form
R=<message id>
which is a reference to the local identification of the message that caused the error message to be sent.
The format of the single-line entry in the main log that is written for every delivery is shown in one of the examples below, for local and remote deliveries, respectively. Each example has been split into two lines in order to fit it on the page:
1995-10-31 08:59:13 0tACW1-0005MB-00 => marv <marv@hitch.fict.book> D=localuser T=local_delivery 1995-10-31 09:00:10 0tACW1-0005MB-00 => monk@holistic.fict.book R=lookuphost T=smtp H=holistic.fict.book [234.234.234.234]
For ordinary local deliveries, the original address is given in angle brackets after the final delivery address, which might be a pipe or a file. If intermediate address(es) exist between the original and the final address, the last of these is given in parentheses after the final address. However, `log_all_parents' can be set to cause all intermediate addresses to be logged.
If a shadow transport was run after a successful local delivery, the log line for the successful delivery has an item added on the end, of the form
ST=<shadow transport name>
If the shadow transport did not succeed, the error message is put in parentheses afterwards.
When a local delivery occurs as a result of routing rather than directing (for example, messages are being batched up for transmission by some other means), the log entry looks more like that for a remote delivery.
For normal remote deliveries, if the `log_smtp_confirmation' option is on, the response to the final `.' in the SMTP transmission is added to the log line, preceded by `C='. If the final delivery address is not the same as the original address (owing to changes made by routers), the original is shown in angle brackets.
The generation of a reply message by a filter file gets logged as a `delivery' to the addressee, preceded by `>'. The D and T items record the director and transport. For remote deliveries, the router, transport, and host are recorded.
When more than one address is included in a single delivery (for example, two SMTP RCPT commands in one transaction) then the second and subsequent addresses are flagged with `->' instead of `=>'. When two or more messages are delivered down a single SMTP connection, an asterisk follows the IP address in the log lines for the second and subsequent messages.
When the `-N' debugging option is used to prevent delivery from actually occurring, log entries are flagged with `*>' instead of `=>'.
When a message is discarded as a result of the command `seen finish' being obeyed in a filter file which generates no deliveries, a log entry of the form
1998-12-10 00:50:49 0znuJc-0001UB-00 => discarded <low.club@trick4.bridge> D=userforward
is written, to record why no deliveries are logged.
When a delivery is deferred, a line of the following form is logged:
1995-12-19 16:20:23 0tRiQz-0002Q5-00 == marvin@endrest.book T=smtp defer (146): Connection refused
In the case of remote deliveries, the error is the one that was given for the last IP address that was tried. Details of individual SMTP failures are also written to the log, so the above line would be preceded by something like
1995-12-19 16:20:23 0tRiQz-0002Q5-00 Failed to connect to endrest.book [239.239.239.239]: Connection refused
When a deferred address is skipped because its retry time has not been reached, a message is written to the log, but this can be suppressed by changing the `log_level' option.
If a delivery fails, a line of the following form is logged:
1995-12-19 16:20:23 0tRiQz-0002Q5-00 ** jim@trek99.film <jimtrek99.film>: unknown mail domain
This is followed (eventually) by a line giving the address to which the delivery error has been sent.
A line of the form
1995-10-31 09:00:11 0tACW1-0005MB-00 Completed
is written to the main log when a message is about to be removed from the spool at the end of its processing.
Various other types of log entry are written from time to time. Most should be self-explanatory. Among the more common are:
The `log_level' configuration option controls the amount of data written to the main log. The higher the number, the more is written. A value of 6 causes all possible messages to appear, though higher levels may get defined in the future. Zero sets a minimal level of logging, with higher levels adding the following, successively:
1 rejections because of policy
re-addressing by the system filter
2 $t rejections because of message size
3 $t verification failures
4 $t SMTP timeouts
SMTP connection refusals because too busy
SMTP unexpected connection loss
SMTP (dis)connections when `log_smtp_connections' is set
SMTP syntax errors when `log_smtp_syntax_errors' is set
non-immediate delivery of SMTP messages because of load level,
or number of connections etc.
5 $t `retry time not reached [for any host]'
`spool file locked' (i.e. some other process is delivering the message)
`message is frozen' (when skipping it in a queue run)
`error message sent to ...'
6 invalid HELO and EHLO arguments (see `helo_verify')
The default log level is 5, which is on the verbose side. Rejection information is still written to the reject log in all cases.
In addition to the four main log files, Exim writes a log file for each message that it handles. The names of these per-message logs are the message ids, and they are kept in the `msglog' sub-directory of the spool directory. A single line is written to the message log for each delivery attempt for each address. It records either a successful delivery, or the reason (temporary or permanent) for failure. If the log level is 5 or higher, `retry time not reached' messages are also written to individual message logs. If the log level is 4 or less, they are suppressed after the first delivery attempt.
When a local part is expanded by aliasing or a forwarding file, a line is written to the message log when all its child deliveries are completed. SMTP connection failures for each remote host are also logged here. The log is deleted when processing of the message is complete, unless `preserve_message_logs' is set, but this should be used only with great care because they can fill up your disc very quickly.
Go to the first, previous, next, last section, table of contents.