The main log records the arrival of each message and each delivery in a single line in each case. The format is as compact as possible, in an attempt to keep down the size of log files. Two-character flag sequences make it easy to pick out these lines. A number of other events are recorded in the main log. Some of them are optional, in which case the log_selector option controls whether they are included or not. A Perl script called eximstats, which does simple analysis of main log files, is provided in the Exim distribution (see section 53.7).
The reject log records information from messages that are rejected as a result of a configuration option (that is, for policy reasons). The first line of each rejection is a copy of the line that is also written to the main log. Then, if the message’s header has been read at the time the log is written, its contents are written to this log. Only the original header lines are available; header lines added by ACLs are not logged. You can use the reject log to check that your policy controls are working correctly; on a busy host this may be easier than scanning the main log for rejection messages. You can suppress the writing of the reject log by setting write_rejectlog false.
When certain serious errors occur, Exim writes entries to its panic log. If the error is sufficiently disastrous, Exim bombs out afterwards. Panic log entries are usually written to the main log as well, but can get lost amid the mass of other entries. The panic log should be empty under normal circumstances. It is therefore a good idea to check it (or to have a cron script check it) regularly, in order to become aware of any problems. When Exim cannot open its panic log, it tries as a last resort to write to the system log (syslog). This is opened with LOG_PID+LOG_CONS and the facility code of LOG_MAIL. The message itself is written at priority LOG_CRIT.
the timestamps will be in UTC (aka GMT).
Exim does not include its process id in log lines by default, but you can request that it does so by specifying the pid log selector (see section 52.15). When this is set, the process id is output, in square brackets, immediately after the time and date.
The logs may be written to local files, or to syslog, or both. However, it should be noted that many syslog implementations use UDP as a transport, and are therefore unreliable in the sense that messages are not guaranteed to arrive at the loghost, nor is the ordering of messages necessarily maintained. It has also been reported that on large log files (tens of megabytes) you may need to tweak syslog to prevent it syncing the file with each write – on Linux this has been seen to make syslog take 90% plus of CPU time.
It is generally advisable, however, to set the string in Local/Makefile rather than at run time, because then the setting is available right from the start of Exim’s execution. Otherwise, if there’s something it wants to log before it has read the configuration file (for example, an error in the configuration file) it will not use the path you want, and may not be able to log at all.
The value of LOG_FILE_PATH or log_file_path is a colon-separated list, currently limited to at most two items. This is one option where the facility for changing a list separator may not be used. The list must always be colon-separated. If an item in the list is “syslog” then syslog is used; otherwise the item must either be an absolute path, containing %s at the point where “main”, “reject”, or “panic” is to be inserted, or be empty, implying the use of a default path.
If you do not specify anything at build time or run time, or if you unset the option at run time (i.e. log_file_path = ), that is where the logs are written.
A log file path may also contain %D or %M if datestamped log file names are in use – see section 52.3 below.
If there are more than two paths in the list, the first is used and a panic error is logged.
Some operating systems provide centralized and standardized methods for cycling log files. For those that do not, a utility script called exicyclog is provided (see section 53.6). This renames and compresses the main and reject logs each time it is called. The maximum number of old logs to keep can be set. It is suggested this script is run as a daily cron job.
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.
When this form of log file is specified, Exim automatically switches to new files at midnight. It does not make any attempt to compress old logs; you will need to write your own script if you require this. You should not run exicyclog with this form of logging.
Many log lines are written to both mainlog and rejectlog, and some are written to both mainlog and paniclog, so there will be duplicates if these are routed by syslog to the same place. You can suppress this duplication by setting syslog_duplication false.
in Local/Makefile before building Exim. That stops Exim from splitting long lines, but it still splits at internal newlines in reject log entries.
Log lines that are neither too long nor contain newlines are written to syslog without modification.
If only syslog is being used, the Exim monitor is unable to provide a log tail display, unless syslog is routing mainlog to a file on the local host and the environment variable EXIMON_LOG_FILE_PATH is set to tell the monitor where it is.
which is a reference to the message that caused the bounce to be sent.
For messages from other hosts, 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 a single, unparenthesized 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, the verified name appears first, followed by the HELO or EHLO name in parentheses.
This can be confusing. Only the final address in square brackets can be relied on.
For locally generated messages (that is, messages not received over TCP/IP), 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. This is the value that is stored in $received_protocol. In the case of incoming SMTP messages, the value indicates whether or not any SMTP extensions (ESMTP), encryption, or authentication were used. If the SMTP session was encrypted, there is an additional X field that records the cipher suite that was used.
The protocol is set to “esmtpsa” or “esmtpa” for messages received from hosts that have authenticated themselves using the SMTP AUTH command. The first value is used when the SMTP connection was encrypted (“secure”). In this case there is an additional item A= followed by the name of the authenticator that was used. If an authenticated identification was set up by the authenticator’s server_set_id option, this is logged too, separated by a colon from the authenticator name.
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 be 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).
The log_selector option can be used to request the logging of additional data when a message is received. See section 52.15 below.
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. The R and T fields record the router and transport that were used to process the address.
If SMTP AUTH was used for the delivery there is an additional item A= followed by the name of the authenticator that was used. If an authenticated identification was set up by the authenticator’s client_set_id option, this is logged too, separated by a colon from the authenticator name.
If the shadow transport did not succeed, the error message is put in parentheses afterwards.
When more than one address is included in a single delivery (for example, two SMTP RCPT commands in one transaction) 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 two or more messages are delivered down a single TLS connection, the DNS and some TLS-related information logged for the first message delivered will not be present in the log lines for the second and subsequent messages. TLS cipher information is still available.
When delivery is done in cutthrough mode it is flagged with >> and the log line precedes the reception line, since cutthrough waits for a possible rejection from the destination in case it can reject the sourced item.
The generation of a reply message by a filter file gets logged as a “delivery” to the addressee, preceded by “>”.
The log_selector option can be used to request the logging of additional data when a message is delivered. See section 52.15 below.
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 setting an appropriate value in log_selector.
The word “pipelined” indicates that the SMTP PIPELINING extension was being used. See hosts_avoid_esmtp in the smtp transport for a way of disabling PIPELINING. The log lines for all forms of delivery failure are flagged with **.
If a delivery does not actually take place because the -N option has been used to suppress it, a normal delivery line is written to the log, except that “=>” is replaced by “*>”.
is written to the main log when a message is about to be removed from the spool at the end of its processing.
retry time not reached An address previously suffered a temporary error during routing or local delivery, and the time to retry has not yet arrived. This message is not written to an individual message log file unless it happens during the first delivery attempt.
retry time not reached for any host An address previously suffered temporary errors during remote delivery, and the retry time has not yet arrived for any of the hosts to which it is routed.
spool file locked An attempt to deliver a message cannot proceed because some other Exim process is already working on the message. This can be quite common if queue running processes are started at frequent intervals. The exiwhat utility script can be used to find out what Exim processes are doing.
Exim failed to deliver a bounce message whose age was greater than ignore_bounce_errors_after. The bounce was discarded.
A filter file set up a delivery using the “noerror” option, and the delivery failed. The delivery was discarded.
failed. The delivery was discarded.
DKIM: d= Verbose results of a DKIM verification attempt, if enabled for logging and the message has a DKIM signature header.
8bitmime: This causes Exim to log any 8BITMIME status of received messages, which may help in tracking down interoperability issues with ancient MTAs that are not 8bit clean. This is added to the “<=” line, tagged with M8S= and a value of 0, 7 or 8, corresponding to "not given", 7BIT and 8BITMIME respectively.
acl_warn_skipped: When an ACL warn statement is skipped because one of its conditions cannot be evaluated, a log line to this effect is written if this log selector is set.
address_rewrite: This applies both to global rewrites and per-transport rewrites, but not to rewrites in filters run as an unprivileged user (because such users cannot access the log).
all_parents: Normally only the original and final addresses are logged on delivery lines; with this selector, intermediate parents are given in parentheses between them.
arguments: This causes Exim to write the arguments with which it was called to the main log, preceded by the current working directory. This is a debugging feature, added to make it easier to find out how certain MUAs call /usr/sbin/sendmail. The logging does not happen if Exim has given up root privilege because it was called with the -C or -D options. Arguments that are empty or that contain white space are quoted. Non-printing characters are shown as escape sequences. This facility cannot log unrecognized arguments, because the arguments are checked before the configuration file is read. The only way to log such cases is to interpose a script such as util/logargs.sh between the caller and Exim.
connection_reject: A log entry is written whenever an incoming SMTP connection is rejected, for whatever reason.
delay_delivery: A log entry is written whenever a delivery process is not started for an incoming message because the load is too high or too many messages were received on one connection. Logging does not occur if no delivery process is started because queue_only is set or -odq was used.
deliver_time: For each delivery, the amount of real time it has taken to perform the actual delivery is logged as DT=<time>, for example, DT=1s. If millisecond logging is enabled, short times will be shown with greater precision, eg. DT=0.304s.
delivery_size: For each delivery, the size of message delivered is added to the “=>” line, tagged with S=.
dkim: For message acceptance log lines, when an DKIM signature in the header verifies successfully a tag of DKIM is added, with one of the verified domains.
dkim_verbose: A log entry is written for each attempted DKIM verification.
dnslist_defer: A log entry is written if an attempt to look up a host in a DNS black list suffers a temporary error.
dnssec: For message acceptance and (attempted) delivery log lines, when dns lookups gave secure results a tag of DS is added. For acceptance this covers the reverse and forward lookups for host name verification. It does not cover helo-name verification. For delivery this covers the SRV, MX, A and/or AAAA lookups.
etrn: Every valid ETRN command that is received is logged, before the ACL is run to determine whether or not it is actually accepted. An invalid ETRN command, or one received within a message transaction is not logged by this selector (see smtp_syntax_error and smtp_protocol_error).
host_lookup_failed: When a lookup of a host’s IP addresses fails to find any addresses, or when a lookup of an IP address fails to find a host name, a log line is written. This logging does not apply to direct DNS lookups when routing email addresses, but it does apply to “byname” lookups.
ident_timeout: A log line is written whenever an attempt to connect to a client’s ident port times out.
incoming_interface: The interface on which a message was received is added to the “<=” line as an IP address in square brackets, tagged by I= and followed by a colon and the port number. The local interface and port are also added to other SMTP log lines, for example “SMTP connection from”, to rejection lines, and (despite the name) to outgoing “=>” and “->” lines. The latter can be disabled by turning off the outgoing_interface option.
proxy: The internal (closest to the system running Exim) IP address of the proxy, tagged by PRX=, on the “<=” line for a message accepted on a proxied connection or the “=>” line for a message delivered on a proxied connection. See 58.1 for more information.
incoming_port: The remote port number from which a message was received is added to log entries and Received: header lines, following the IP address in square brackets, and separated from it by a colon. This is implemented by changing the value that is put in the $sender_fullhost and $sender_rcvhost variables. Recording the remote port number has become more important with the widening use of NAT (see RFC 2505).
lost_incoming_connection: A log line is written when an incoming SMTP connection is unexpectedly dropped.
millisec: Timestamps have a period and three decimal places of finer granularity appended to the seconds value.
outgoing_interface: If incoming_interface is turned on, then the interface on which a message was sent is added to delivery lines as an I= tag followed by IP address in square brackets. You can disable this by turning off the outgoing_interface option.
outgoing_port: The remote port number is added to delivery log lines (those containing => tags) following the IP address. The local port is also added if incoming_interface and outgoing_interface are both enabled. This option is not included in the default setting, because for most ordinary configurations, the remote port number is always 25 (the SMTP port), and the local port is a random ephemeral port.
pid: The current process id is added to every log line, in square brackets, immediately after the time and date.
queue_run: The start and end of every queue run are logged.
queue_time: The amount of time the message has been in the queue on the local host is logged as QT=<time> on delivery (=>) lines, for example, QT=3m45s. The clock starts when Exim starts to receive the message, so it includes reception time as well as the delivery time for the current address. This means that it may be longer than the difference between the arrival and delivery log line times, because the arrival log line is not written until the message has been successfully received. If millisecond logging is enabled, short times will be shown with greater precision, eg. QT=1.578s.
queue_time_overall: The amount of time the message has been in the queue on the local host is logged as QT=<time> on “Completed” lines, for example, QT=3m45s. The clock starts when Exim starts to receive the message, so it includes reception time as well as the total delivery time.
receive_time: For each message, the amount of real time it has taken to perform the reception is logged as RT=<time>, for example, RT=1s. If millisecond logging is enabled, short times will be shown with greater precision, eg. RT=0.204s.
received_recipients: The recipients of a message are listed in the main log as soon as the message is received. The list appears at the end of the log line that is written when a message is received, preceded by the word “for”. The addresses are listed after they have been qualified, but before any rewriting has taken place. Recipients that were discarded by an ACL for MAIL or RCPT do not appear in the list.
received_sender: 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” (before the recipients if received_recipients is also set).
rejected_header: If a message’s header has been received at the time a rejection is written to the reject log, the complete header is added to the log. Header logging can be turned off individually for messages that are rejected by the local_scan() function (see section 45.2).
retry_defer: A log line is written if a delivery is deferred because a retry time has not yet been reached. However, this “retry time not reached” message is always omitted from individual message logs after the first delivery attempt.
return_path_on_delivery: The return path that is being transmitted with the message is included in delivery and bounce lines, using the tag P=. This is omitted if no delivery actually happens, for example, if routing fails, or if delivery is to /dev/null or to :blackhole:.
sender_on_delivery: The message’s sender address is added to every delivery and bounce line, tagged by F= (for “from”). This is the original sender that was received with the message; it is not necessarily the same as the outgoing return path.
sender_verify_fail: If this selector is unset, the separate log line that gives details of a sender verification failure is not written. Log lines for the rejection of SMTP commands contain just “sender verify failed”, so some detail is lost.
size_reject: A log line is written whenever a message is rejected because it is too big.
skip_delivery: A log line is written whenever a message is skipped during a queue run because it is frozen or because another process is already delivering it. The message that is written is “spool file is locked”.
smtp_confirmation: The response to the final “.” in the SMTP or LMTP dialogue for outgoing messages is added to delivery log lines in the form C=<text>. A number of MTAs (including Exim) return an identifying string in this response.
smtp_connection: A log line is written whenever an incoming SMTP connection is established or closed, unless the connection is from a host that matches hosts_connection_nolog. (In contrast, lost_incoming_connection applies only when the closure is unexpected.) This applies to connections from local processes that use -bs as well as to TCP/IP connections. If a connection is dropped in the middle of a message, a log line is always written, whether or not this selector is set, but otherwise nothing is written at the start and end of connections unless this selector is enabled.
For TCP/IP connections to an Exim daemon, the current number of connections is included in the log message for each new connection, but note that the count is reset if the daemon is restarted. Also, because connections are closed (and the closure is logged) in subprocesses, the count may not include connections that have been closed but whose termination the daemon has not yet noticed. Thus, while it is possible to match up the opening and closing of connections in the log, the value of the logged counts may not be entirely accurate.
smtp_incomplete_transaction: When a mail transaction is aborted by RSET, QUIT, loss of connection, or otherwise, the incident is logged, and the message sender plus any accepted recipients are included in the log line. This can provide evidence of dictionary attacks.
smtp_no_mail: A line is written to the main log whenever an accepted SMTP connection terminates without having issued a MAIL command. This includes both the case when the connection is dropped, and the case when QUIT is used. It does not include cases where the connection is rejected right at the start (by an ACL, or because there are too many connections, or whatever). These cases already have their own log lines.
The log line that is written contains the identity of the client in the usual way, followed by D= and a time, which records the duration of the connection. If the connection was authenticated, this fact is logged exactly as it is for an incoming message, with an A= item. If the connection was encrypted, CV=, DN=, and X= items may appear as they do for an incoming message, controlled by the same logging options.
shows that the client issued QUIT straight after EHLO. If there were fewer than 20 commands, they are all listed. If there were more than 20 commands, the last 20 are listed, preceded by “...”. However, with the default setting of 10 for smtp_accept_max_nonmail, the connection will in any case have been aborted before 20 non-mail commands are processed.
smtp_mailauth: A third subfield with the authenticated sender, colon-separated, is appended to the A= item for a message arrival or delivery log line, if an AUTH argument to the SMTP MAIL command (see 33.2) was accepted or used.
smtp_protocol_error: A log line is written for every SMTP protocol error encountered. Exim does not have perfect detection of all protocol errors because of transmission delays and the use of pipelining. If PIPELINING has been advertised to a client, an Exim server assumes that the client will use it, and therefore it does not count “expected” errors (for example, RCPT received after rejecting MAIL) as protocol errors.
smtp_syntax_error: A log line is written for every SMTP syntax error encountered. An unrecognized command is treated as a syntax error. For an external connection, the host identity is given; for an internal connection using -bs the sender identification (normally the calling user) is given.
subject: The subject of the message is added to the arrival log line, preceded by “T=” (T for “topic”, since S is already used for “size”). Any MIME “words” in the subject are decoded. The print_topbitchars option specifies whether characters with values greater than 127 should be logged unchanged, or whether they should be rendered as escape sequences.
tls_cipher: When a message is sent or received over an encrypted connection, the cipher suite used is added to the log line, preceded by X=.
tls_peerdn: When a message is sent or received over an encrypted connection, and a certificate is supplied by the remote host, the peer DN is added to the log line, preceded by DN=.
tls_sni: When a message is received over an encrypted connection, and the remote host provided the Server Name Indication extension, the SNI is added to the log line, preceded by SNI=.
unknown_in_list: This setting causes a log entry to be written when the result of a list match is failure because a DNS lookup failed.
In addition to the general 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. Each message log contains copies of the log lines that apply to the message. This makes it easier to inspect the status of an individual message without having to search the main log. A message 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 disk very quickly.
On a heavily loaded system, it may be desirable to disable the use of per-message logs, in order to reduce disk I/O. This can be done by setting the message_logs option false.