<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><style xmlns="" type="text/css">
div.added { background-color: #ffff99; }
div.deleted { text-decoration: line-through;
background-color: #FF7F7F; }
div.changed { background-color: #99ff99; }
div.off { }
span.added { background-color: #ffff99; }
span.deleted { text-decoration: line-through;
background-color: #FF7F7F; }
span.changed { background-color: #99ff99; }
span.off { }
pre.literallayout {
background-color: #E8E8D0;
padding-left: 0.5cm;
padding-top: 5px;
padding-bottom: 5px;
}
div[class=changed] pre.literallayout {
background-color: #99ff99;
padding-left: 0.5cm;
padding-top: 5px;
padding-bottom: 5px;
}
div.literallayout {
background-color: #E8E8D0;
padding-left: 0.5cm;
padding-top: 5px;
padding-bottom: 5px;
}
div[class=changed] div.literallayout {
background-color: #99ff99;
padding-left: 0.5cm;
padding-top: 5px;
padding-bottom: 5px;
}
</style><title>49. Log files</title><meta name="generator" content="DocBook XSL Stylesheets V1.72.0" /><link rel="start" href="index.html" title="Specification of the Exim Mail Transfer Agent" /><link rel="up" href="index.html" title="Specification of the Exim Mail Transfer Agent" /><link rel="prev" href="ch48.html" title="48. Using Exim as a non-queueing client" /><link rel="next" href="ch50.html" title="50. Exim utilities" /></head><body><div class="navheader">
<table width="100%" summary="Navigation header"><tr><td width="20%" align="left"><a accesskey="p" href="ch48.html">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="ch50.html">Next</a></td></tr></table></div>
<div class="chapter" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title"><a href="index.html#toc0435" id="CHAPlog">49. Log files</a></h2></div>
</div>
</div>
<p>
<a id="IIDloggen" class="indexterm"></a>
<a id="id648823" class="indexterm"></a>
Exim writes three different logs, referred to as the main log, the reject log,
and the panic log:
</p>
<div class="itemizedlist">
<ul type="disc"><li><p>
<a id="id648846" class="indexterm"></a>
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 <span><strong class="option">log_selector</strong></span> option controls whether
they are included or not. A Perl script called <span class="emphasis"><em>eximstats</em></span>, which does simple
analysis of main log files, is provided in the Exim distribution (see section
<a href="ch50.html#SECTmailstat" title="50.7 Mail statistics (eximstats)">50.7</a>).
</p>
</li><li><p>
<a id="id648887" class="indexterm"></a>
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 <span><strong class="option">write_rejectlog</strong></span>
false.
</p>
</li><li><p>
<a id="id648908" class="indexterm"></a>
<a id="id648918" class="indexterm"></a>
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 <span class="emphasis"><em>cron</em></span> 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.
</p>
</li></ul></div>
<p>
Every log line starts with a timestamp, in the format shown in the following
example. Note that many of the examples shown in this chapter are line-wrapped.
In the log file, this would be all on one line:
</p>
<pre class="literallayout">2001-09-16 16:09:47 SMTP connection from [127.0.0.1] closed
by QUIT
</pre><p>
By default, the timestamps are in the local timezone. There are two
ways of changing this:
</p>
<div class="itemizedlist">
<ul type="disc"><li><p>
You can set the <span><strong class="option">timezone</strong></span> option to a different time zone; in particular, if
you set
</p>
<pre class="literallayout">timezone = UTC
</pre><p>
the timestamps will be in UTC (aka GMT).
</p>
</li><li><p>
If you set <span><strong class="option">log_timezone</strong></span> true, the time zone is added to the timestamp, for
example:
</p>
<pre class="literallayout">2003-04-25 11:17:07 +0100 Start queue run: pid=12762
</pre></li></ul></div>
<p>
<a id="id649016" class="indexterm"></a>
<a id="id649030" class="indexterm"></a>
Exim does not include its process id in log lines by default, but you can
request that it does so by specifying the <code class="literal">pid</code> log selector (see section
<a href="ch49.html#SECTlogselector" title="49.15 Reducing or increasing what is logged">49.15</a>). When this is set, the process id is output, in square
brackets, immediately after the time and date.
</p>
<div class="section" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 xmlns="" class="title"><a xmlns="http://www.w3.org/1999/xhtml" href="index.html#toc0436" id="SECTwhelogwri">49.1 Where the logs are written</a></h3></div>
</div>
</div>
<p>
<a id="id649072" class="indexterm"></a>
<a id="id649086" class="indexterm"></a>
<a id="id649100" class="indexterm"></a>
<a id="id649114" class="indexterm"></a>
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.
</p>
<p>
The destination for Exim’s logs is configured by setting LOG_FILE_PATH in
<em class="filename">Local/Makefile</em> or by setting <span><strong class="option">log_file_path</strong></span> in the run time
configuration. This latter string is expanded, so it can contain, for example,
references to the host name:
</p>
<pre class="literallayout">log_file_path = /var/log/$primary_hostname/exim_%slog
</pre><p>
It is generally advisable, however, to set the string in <em class="filename">Local/Makefile</em>
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.
</p>
<p>
The value of LOG_FILE_PATH or <span><strong class="option">log_file_path</strong></span> 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 “<span class="quote">syslog</span>” then syslog is used;
otherwise the item must either be an absolute path, containing <code class="literal">%s</code> at the
point where “<span class="quote">main</span>”, “<span class="quote">reject</span>”, or “<span class="quote">panic</span>” is to be inserted, or be empty,
implying the use of a default path.
</p>
<p>
When Exim encounters an empty item in the list, it searches the list defined by
LOG_FILE_PATH, and uses the first item it finds that is neither empty nor
“<span class="quote">syslog</span>”. This means that an empty item in <span><strong class="option">log_file_path</strong></span> can be used to
mean “<span class="quote">use the path specified at build time</span>”. It no such item exists, log
files are written in the <em class="filename">log</em> subdirectory of the spool directory. This is
equivalent to the setting:
</p>
<pre class="literallayout">log_file_path = $spool_directory/log/%slog
</pre><p>
If you do not specify anything at build time or run time, that is where the
logs are written.
</p>
<p>
A log file path may also contain <code class="literal">%D</code> if datestamped log file names are in
use – see section <a href="ch49.html#SECTdatlogfil" title="49.3 Datestamped log files">49.3</a> below.
</p>
<p>
Here are some examples of possible settings:
</p>
<div class="literallayout">
<code class="literal">LOG_FILE_PATH=syslog </code> syslog only<br />
<code class="literal">LOG_FILE_PATH=:syslog </code> syslog and default path<br />
<code class="literal">LOG_FILE_PATH=syslog : /usr/log/exim_%s </code> syslog and specified path<br />
<code class="literal">LOG_FILE_PATH=/usr/log/exim_%s </code> specified path only<br />
</div>
<p>
If there are more than two paths in the list, the first is used and a panic
error is logged.
</p>
</div>
<div class="section" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 xmlns="" class="title"><a xmlns="http://www.w3.org/1999/xhtml" href="index.html#toc0437" id="SECID285">49.2 Logging to local files that are periodically “<span xmlns="http://www.w3.org/1999/xhtml" class="quote">cycled</span>”</a></h3></div>
</div>
</div>
<p>
<a id="id649310" class="indexterm"></a>
<a id="id649324" class="indexterm"></a>
<a id="id649335" class="indexterm"></a>
<a id="id649347" class="indexterm"></a>
Some operating systems provide centralized and standardized methods for cycling
log files. For those that do not, a utility script called <span class="emphasis"><em>exicyclog</em></span> is
provided (see section <a href="ch50.html#SECTcyclogfil" title="50.6 Cycling log files (exicyclog)">50.6</a>). 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 <span class="emphasis"><em>cron</em></span> job.
</p>
<p>
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 <span class="emphasis"><em>exicyclog</em></span> 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
<em class="function">stat()</em> 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.
</p>
</div>
<div class="section" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 xmlns="" class="title"><a xmlns="http://www.w3.org/1999/xhtml" href="index.html#toc0438" id="SECTdatlogfil">49.3 Datestamped log files</a></h3></div>
</div>
</div>
<p>
<a id="id649416" class="indexterm"></a>
Instead of cycling the main and reject log files by renaming them
periodically, some sites like to use files whose names contain a datestamp,
for example, <em class="filename">mainlog-20031225</em>. The datestamp is in the form <em class="filename">yyyymmdd</em>.
Exim has support for this way of working. It is enabled by setting the
<span><strong class="option">log_file_path</strong></span> option to a path that includes <code class="literal">%D</code> at the point where the
datestamp is required. For example:
</p>
<pre class="literallayout">log_file_path = /var/spool/exim/log/%slog-%D
log_file_path = /var/log/exim-%s-%D.log
log_file_path = /var/spool/exim/log/%D-%slog
</pre><p>
As before, <code class="literal">%s</code> is replaced by “<span class="quote">main</span>” or “<span class="quote">reject</span>”; the following are
examples of names generated by the above examples:
</p>
<pre class="literallayout">/var/spool/exim/log/mainlog-20021225
/var/log/exim-reject-20021225.log
/var/spool/exim/log/20021225-mainlog
</pre><p>
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 <span class="emphasis"><em>exicyclog</em></span> with this form of logging.
</p>
<p>
The location of the panic log is also determined by <span><strong class="option">log_file_path</strong></span>, but it
is not datestamped, because rotation of the panic log does not make sense.
When generating the name of the panic log, <code class="literal">%D</code> is removed from the string.
In addition, if it immediately follows a slash, a following non-alphanumeric
character is removed; otherwise a preceding non-alphanumeric character is
removed. Thus, the three examples above would give these panic log names:
</p>
<pre class="literallayout">/var/spool/exim/log/paniclog
/var/log/exim-panic.log
/var/spool/exim/log/paniclog
</pre></div>
<div class="section" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 xmlns="" class="title"><a xmlns="http://www.w3.org/1999/xhtml" href="index.html#toc0439" id="SECID249">49.4 Logging to syslog</a></h3></div>
</div>
</div>
<p>
<a id="id649547" class="indexterm"></a>
The use of syslog does not change what Exim logs or the format of its messages,
except in one respect. If <span><strong class="option">syslog_timestamp</strong></span> is set false, the timestamps on
Exim’s log lines are omitted when these lines are sent to syslog. Apart from
that, the same strings are written to syslog as to log files. The syslog
“<span class="quote">facility</span>” is set to LOG_MAIL, and the program name to “<span class="quote">exim</span>”
by default, but you can change these by setting the <span><strong class="option">syslog_facility</strong></span> and
<span><strong class="option">syslog_processname</strong></span> options, respectively. If Exim was compiled with
SYSLOG_LOG_PID set in <em class="filename">Local/Makefile</em> (this is the default in
<em class="filename">src/EDITME</em>), then, on systems that permit it (all except ULTRIX), the
LOG_PID flag is set so that the <em class="function">syslog()</em> call adds the pid as well as
the time and host name to each line.
The three log streams are mapped onto syslog priorities as follows:
</p>
<div class="itemizedlist">
<ul type="disc"><li><p>
<span class="emphasis"><em>mainlog</em></span> is mapped to LOG_INFO
</p>
</li><li><p>
<span class="emphasis"><em>rejectlog</em></span> is mapped to LOG_NOTICE
</p>
</li><li><p>
<span class="emphasis"><em>paniclog</em></span> is mapped to LOG_ALERT
</p>
</li></ul></div>
<p>
Many log lines are written to both <span class="emphasis"><em>mainlog</em></span> and <span class="emphasis"><em>rejectlog</em></span>, and some are
written to both <span class="emphasis"><em>mainlog</em></span> and <span class="emphasis"><em>paniclog</em></span>, so there will be duplicates if
these are routed by syslog to the same place. You can suppress this duplication
by setting <span><strong class="option">syslog_duplication</strong></span> false.
</p>
<p>
Exim’s log lines can sometimes be very long, and some of its <span class="emphasis"><em>rejectlog</em></span>
entries contain multiple lines when headers are included. To cope with both
these cases, entries written to syslog are split into separate <em class="function">syslog()</em>
calls at each internal newline, and also after a maximum of
870 data characters. (This allows for a total syslog line length of 1024, when
additions such as timestamps are added.) If you are running a syslog
replacement that can handle lines longer than the 1024 characters allowed by
RFC 3164, you should set
</p>
<pre class="literallayout">SYSLOG_LONG_LINES=yes
</pre><p>
in <em class="filename">Local/Makefile</em> before building Exim. That stops Exim from splitting long
lines, but it still splits at internal newlines in <span class="emphasis"><em>reject</em></span> log entries.
</p>
<p>
To make it easy to re-assemble split lines later, each component of a split
entry starts with a string of the form [<<span class="emphasis"><em>n</em></span>>/<<span class="emphasis"><em>m</em></span>>] or [<<span class="emphasis"><em>n</em></span>>\<<span class="emphasis"><em>m</em></span>>]
where <<span class="emphasis"><em>n</em></span>> is the component number and <<span class="emphasis"><em>m</em></span>> is the total number of
components in the entry. The / delimiter is used when the line was split
because it was too long; if it was split because of an internal newline, the \
delimiter is used. For example, supposing the length limit to be 50 instead of
870, the following would be the result of a typical rejection message to
<span class="emphasis"><em>mainlog</em></span> (LOG_INFO), each line in addition being preceded by the time, host
name, and pid as added by syslog:
</p>
<pre class="literallayout">[1/5] 2002-09-16 16:09:43 16RdAL-0006pc-00 rejected from
[2/5] [127.0.0.1] (ph10): syntax error in 'From' header
[3/5] when scanning for sender: missing or malformed lo
[4/5] cal part in "<>" (envelope sender is <ph10@cam.exa
[5/5] mple>)
</pre><p>
The same error might cause the following lines to be written to “<span class="quote">rejectlog</span>”
(LOG_NOTICE):
</p>
<pre class="literallayout">[1/18] 2002-09-16 16:09:43 16RdAL-0006pc-00 rejected fro
[2/18] m [127.0.0.1] (ph10): syntax error in 'From' head
[3/18] er when scanning for sender: missing or malformed
[4/18] local part in "<>" (envelope sender is <ph10@cam
[5\18] .example>)
[6\18] Recipients: ph10@some.domain.cam.example
[7\18] P Received: from [127.0.0.1] (ident=ph10)
[8\18] by xxxxx.cam.example with smtp (Exim 4.00)
[9\18] id 16RdAL-0006pc-00
[10/18] for ph10@cam.example; Mon, 16 Sep 2002 16:
[11\18] 09:43 +0100
[12\18] F From: <>
[13\18] Subject: this is a test header
[18\18] X-something: this is another header
[15/18] I Message-Id: <E16RdAL-0006pc-00@xxxxx.cam.examp
[16\18] le>
[17\18] B Bcc:
[18/18] Date: Mon, 16 Sep 2002 16:09:43 +0100
</pre><p>
Log lines that are neither too long nor contain newlines are written to syslog
without modification.
</p>
<p>
If only syslog is being used, the Exim monitor is unable to provide a log tail
display, unless syslog is routing <span class="emphasis"><em>mainlog</em></span> to a file on the local host and
the environment variable EXIMON_LOG_FILE_PATH is set to tell the monitor
where it is.
</p>
</div>
<div class="section" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 xmlns="" class="title"><a xmlns="http://www.w3.org/1999/xhtml" href="index.html#toc0440" id="SECID250">49.5 Log line flags</a></h3></div>
</div>
</div>
<p>
One line is written to the main log for each message received, and for each
successful, unsuccessful, and delayed delivery. These lines can readily be
picked out by the distinctive two-character flags that immediately follow the
timestamp. The flags are:
</p>
<div class="literallayout">
<code class="literal"><=</code> message arrival<br />
<code class="literal">=></code> normal message delivery<br />
<code class="literal">-></code> additional address in same delivery<br />
<code class="literal">*></code> delivery suppressed by <span><strong class="option">-N</strong></span><br />
<code class="literal">**</code> delivery failed; address bounced<br />
<code class="literal">==</code> delivery deferred; temporary problem<br />
</div>
</div>
<div class="section" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 xmlns="" class="title"><a xmlns="http://www.w3.org/1999/xhtml" href="index.html#toc0441" id="SECID251">49.6 Logging message reception</a></h3></div>
</div>
</div>
<p>
<a id="id649877" class="indexterm"></a>
The format of the single-line entry in the main log that is written for every
message received is shown in the basic example below, which is split over
several lines in order to fit it on the page:
</p>
<pre class="literallayout">2002-10-31 08:57:53 16ZCW1-0005MB-00 <= kryten@dwarf.fict.example
H=mailer.fict.example [192.168.123.123] U=exim
P=smtp S=5678 id=<incoming message id>
</pre><p>
The address immediately following “<span class="quote"><=</span>” is the envelope sender address. A
bounce message is shown with the sender address “<span class="quote"><></span>”, and if it is locally
generated, this is followed by an item of the form
</p>
<pre class="literallayout">R=<message id>
</pre><p>
which is a reference to the message that caused the bounce to be sent.
</p>
<p>
<a id="id649938" class="indexterm"></a>
<a id="id649948" class="indexterm"></a>
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
<span><strong class="option">host_lookup</strong></span> 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.
</p>
<p>
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 text like these examples:
</p>
<pre class="literallayout">H=(10.21.32.43) [192.168.8.34]
H=([10.21.32.43]) [192.168.8.34]
</pre><p>
This can be confusing. Only the final address in square brackets can be relied
on.
</p>
<p>
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.
</p>
<p>
<a id="id649997" class="indexterm"></a>
<a id="id650012" class="indexterm"></a>
For all messages, the P field specifies the protocol used to receive the
message. This is the value that is stored in <em class="varname">$received_protocol</em>. 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.
</p>
<p>
The protocol is set to “<span class="quote">esmtpsa</span>” or “<span class="quote">esmtpa</span>” 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 (“<span class="quote">secure</span>”). 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
<span><strong class="option">server_set_id</strong></span> option, this is logged too, separated by a colon from the
authenticator name.
</p>
<p>
<a id="id650070" class="indexterm"></a>
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).
</p>
<p>
The <span><strong class="option">log_selector</strong></span> option can be used to request the logging of additional
data when a message is received. See section <a href="ch49.html#SECTlogselector" title="49.15 Reducing or increasing what is logged">49.15</a> below.
</p>
</div>
<div class="section" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 xmlns="" class="title"><a xmlns="http://www.w3.org/1999/xhtml" href="index.html#toc0442" id="SECID252">49.7 Logging deliveries</a></h3></div>
</div>
</div>
<p>
<a id="id650116" class="indexterm"></a>
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:
</p>
<pre class="literallayout">2002-10-31 08:59:13 16ZCW1-0005MB-00 => marv
<marv@hitch.fict.example> R=localuser T=local_delivery
2002-10-31 09:00:10 16ZCW1-0005MB-00 =>
monk@holistic.fict.example R=dnslookup T=remote_smtp
H=holistic.fict.example [192.168.234.234]
</pre><p>
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.
</p>
<p>
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
</p>
<div class="literallayout">
<code class="literal">ST=<</code><span class="emphasis"><em>shadow transport name</em></span><code class="literal">></code><br />
</div>
<p>
If the shadow transport did not succeed, the error message is put in
parentheses afterwards.
</p>
<p>
<a id="id650190" class="indexterm"></a>
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 <code class="literal">-></code> instead of <code class="literal">=></code>. 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.
</p>
<p>
The generation of a reply message by a filter file gets logged as a
“<span class="quote">delivery</span>” to the addressee, preceded by “<span class="quote">></span>”.
</p>
<p>
The <span><strong class="option">log_selector</strong></span> option can be used to request the logging of additional
data when a message is delivered. See section <a href="ch49.html#SECTlogselector" title="49.15 Reducing or increasing what is logged">49.15</a> below.
</p>
</div>
<div class="section" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 xmlns="" class="title"><a xmlns="http://www.w3.org/1999/xhtml" href="index.html#toc0443" id="SECID253">49.8 Discarded deliveries</a></h3></div>
</div>
</div>
<p>
<a id="id650262" class="indexterm"></a>
<a id="id650273" class="indexterm"></a>
<a id="id650287" class="indexterm"></a>
When a message is discarded as a result of the command “<span class="quote">seen finish</span>” being
obeyed in a filter file which generates no deliveries, a log entry of the form
</p>
<pre class="literallayout">2002-12-10 00:50:49 16auJc-0001UB-00 => discarded
<low.club@bridge.example> R=userforward
</pre><p>
is written, to record why no deliveries are logged. When a message is discarded
because it is aliased to “<span class="quote">:blackhole:</span>” the log line is like this:
</p>
<pre class="literallayout">1999-03-02 09:44:33 10HmaX-0005vi-00 => :blackhole:
<hole@nowhere.example> R=blackhole_router
</pre></div>
<div class="section" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 xmlns="" class="title"><a xmlns="http://www.w3.org/1999/xhtml" href="index.html#toc0444" id="SECID254">49.9 Deferred deliveries</a></h3></div>
</div>
</div>
<p>
When a delivery is deferred, a line of the following form is logged:
</p>
<pre class="literallayout">2002-12-19 16:20:23 16aiQz-0002Q5-00 == marvin@endrest.example
R=dnslookup T=smtp defer (146): Connection refused
</pre><p>
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
</p>
<pre class="literallayout">2002-12-19 16:20:23 16aiQz-0002Q5-00 Failed to connect to
mail1.endrest.example [192.168.239.239]: Connection refused
</pre><p>
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 <span><strong class="option">log_selector</strong></span>.
</p>
</div>
<div class="section" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 xmlns="" class="title"><a xmlns="http://www.w3.org/1999/xhtml" href="index.html#toc0445" id="SECID255">49.10 Delivery failures</a></h3></div>
</div>
</div>
<p>
<a id="id650404" class="indexterm"></a>
If a delivery fails because an address cannot be routed, a line of the
following form is logged:
</p>
<pre class="literallayout">1995-12-19 16:20:23 0tRiQz-0002Q5-00 ** jim@trek99.example
<jim@trek99.example>: unknown mail domain
</pre><p>
If a delivery fails at transport time, the router and transport are shown, and
the response from the remote host is included, as in this example:
</p>
<pre class="literallayout">2002-07-11 07:14:17 17SXDU-000189-00 ** ace400@pb.example
R=dnslookup T=remote_smtp: SMTP error from remote mailer
after pipelined RCPT TO:<ace400@pb.example>: host
pbmail3.py.example [192.168.63.111]: 553 5.3.0
<ace400@pb.example>...Addressee unknown
</pre><p>
The word “<span class="quote">pipelined</span>” indicates that the SMTP PIPELINING extension was being
used. See <span><strong class="option">hosts_avoid_esmtp</strong></span> in the <span><strong class="command">smtp</strong></span> transport for a way of
disabling PIPELINING. The log lines for all forms of delivery failure are
flagged with <code class="literal">**</code>.
</p>
</div>
<div class="section" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 xmlns="" class="title"><a xmlns="http://www.w3.org/1999/xhtml" href="index.html#toc0446" id="SECID256">49.11 Fake deliveries</a></h3></div>
</div>
</div>
<p>
<a id="id650487" class="indexterm"></a>
If a delivery does not actually take place because the <span><strong class="option">-N</strong></span> option has been
used to suppress it, a normal delivery line is written to the log, except that
“<span class="quote">=></span>” is replaced by “<span class="quote">*></span>”.
</p>
</div>
<div class="section" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 xmlns="" class="title"><a xmlns="http://www.w3.org/1999/xhtml" href="index.html#toc0447" id="SECID257">49.12 Completion</a></h3></div>
</div>
</div>
<p>
A line of the form
</p>
<pre class="literallayout">2002-10-31 09:00:11 16ZCW1-0005MB-00 Completed
</pre><p>
is written to the main log when a message is about to be removed from the spool
at the end of its processing.
</p>
</div>
<div class="section" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 xmlns="" class="title"><a xmlns="http://www.w3.org/1999/xhtml" href="index.html#toc0448" id="SECID258">49.13 Summary of Fields in Log Lines</a></h3></div>
</div>
</div>
<p>
<a id="id650557" class="indexterm"></a>
A summary of the field identifiers that are used in log lines is shown in
the following table:
</p>
<div class="literallayout">
<code class="literal">A </code> authenticator name (and optional id)<br />
<code class="literal">C </code> SMTP confirmation on delivery<br />
<code class="literal"> </code> command list for “<span class="quote">no mail in SMTP session</span>”<br />
<code class="literal">CV </code> certificate verification status<br />
<code class="literal">D </code> duration of “<span class="quote">no mail in SMTP session</span>”<br />
<code class="literal">DN </code> distinguished name from peer certificate<br />
<code class="literal">DT </code> on <code class="literal">=></code> lines: time taken for a delivery<br />
<code class="literal">F </code> sender address (on delivery lines)<br />
<code class="literal">H </code> host name and IP address<br />
<code class="literal">I </code> local interface used<br />
<code class="literal">id </code> message id for incoming message<br />
<code class="literal">P </code> on <code class="literal"><=</code> lines: protocol used<br />
<code class="literal"> </code> on <code class="literal">=></code> and <code class="literal">**</code> lines: return path<br />
<code class="literal">QT </code> on <code class="literal">=></code> lines: time spent on queue so far<br />
<code class="literal"> </code> on “<span class="quote">Completed</span>” lines: time spent on queue<br />
<code class="literal">R </code> on <code class="literal"><=</code> lines: reference for local bounce<br />
<code class="literal"> </code> on <code class="literal">=></code> <code class="literal">**</code> and <code class="literal">==</code> lines: router name<br />
<code class="literal">S </code> size of message<br />
<code class="literal">ST </code> shadow transport name<br />
<code class="literal">T </code> on <code class="literal"><=</code> lines: message subject (topic)<br />
<code class="literal"> </code> on <code class="literal">=></code> <code class="literal">**</code> and <code class="literal">==</code> lines: transport name<br />
<code class="literal">U </code> local user or RFC 1413 identity<br />
<code class="literal">X </code> TLS cipher suite<br />
</div>
</div>
<div class="section" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 xmlns="" class="title"><a xmlns="http://www.w3.org/1999/xhtml" href="index.html#toc0449" id="SECID259">49.14 Other log entries</a></h3></div>
</div>
</div>
<p>
Various other types of log entry are written from time to time. Most should be
self-explanatory. Among the more common are:
</p>
<div class="itemizedlist">
<ul type="disc"><li><p>
<a id="id650832" class="indexterm"></a>
<span class="emphasis"><em>retry time not reached</em></span> 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.
</p>
</li><li><p>
<span class="emphasis"><em>retry time not reached for any host</em></span> 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.
</p>
</li><li><p>
<a id="id650874" class="indexterm"></a>
<span class="emphasis"><em>spool file locked</em></span> 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
<span class="emphasis"><em>exiwhat</em></span> utility script can be used to find out what Exim processes are
doing.
</p>
</li><li><p>
<a id="id650907" class="indexterm"></a>
<span class="emphasis"><em>error ignored</em></span> There are several circumstances that give rise to this
message:
</p>
<div class="orderedlist">
<ol type="1"><li><p>
Exim failed to deliver a bounce message whose age was greater than
<span><strong class="option">ignore_bounce_errors_after</strong></span>. The bounce was discarded.
</p>
</li><li><p>
A filter file set up a delivery using the “<span class="quote">noerror</span>” option, and the delivery
failed. The delivery was discarded.
</p>
</li><li><p>
A delivery set up by a router configured with
</p>
<pre class="literallayout"> errors_to = <>
</pre><p>
failed. The delivery was discarded.
</p>
</li></ol></div>
</li></ul></div>
</div>
<div class="section" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 xmlns="" class="title"><a xmlns="http://www.w3.org/1999/xhtml" href="index.html#toc0450" id="SECTlogselector">49.15 Reducing or increasing what is logged</a></h3></div>
</div>
</div>
<p>
<a id="id650995" class="indexterm"></a>
By setting the <span><strong class="option">log_selector</strong></span> global option, you can disable some of Exim’s
default logging, or you can request additional logging. The value of
<span><strong class="option">log_selector</strong></span> is made up of names preceded by plus or minus characters. For
example:
</p>
<pre class="literallayout">log_selector = +arguments -retry_defer
</pre><p>
The list of optional log items is in the following table, with the default
selection marked by asterisks:
</p>
<div class="literallayout">
<code class="literal">*acl_warn_skipped </code> skipped <span><strong class="option">warn</strong></span> statement in ACL<br />
<code class="literal"> address_rewrite </code> address rewriting<br />
<code class="literal"> all_parents </code> all parents in => lines<br />
<code class="literal"> arguments </code> command line arguments<br />
<code class="literal">*connection_reject </code> connection rejections<br />
<code class="literal">*delay_delivery </code> immediate delivery delayed<br />
<code class="literal"> deliver_time </code> time taken to perform delivery<br />
<code class="literal"> delivery_size </code> add <code class="literal">S=</code><span class="emphasis"><em>nnn</em></span> to => lines<br />
<code class="literal">*dnslist_defer </code> defers of DNS list (aka RBL) lookups<br />
<code class="literal">*etrn </code> ETRN commands<br />
<code class="literal">*host_lookup_failed </code> as it says<br />
<code class="literal"> ident_timeout </code> timeout for ident connection<br />
<code class="literal"> incoming_interface </code> incoming interface on <= lines<br />
<code class="literal"> incoming_port </code> incoming port on <= lines<br />
<code class="literal">*lost_incoming_connection </code> as it says (includes timeouts)<br />
<code class="literal"> outgoing_port </code> add remote port to => lines<br />
<code class="literal">*queue_run </code> start and end queue runs<br />
<code class="literal"> queue_time </code> time on queue for one recipient<br />
<code class="literal"> queue_time_overall </code> time on queue for whole message<br />
<code class="literal"> pid </code> Exim process id<br />
<code class="literal"> received_recipients </code> recipients on <= lines<br />
<code class="literal"> received_sender </code> sender on <= lines<br />
<code class="literal">*rejected_header </code> header contents on reject log<br />
<code class="literal">*retry_defer </code> “<span class="quote">retry time not reached</span>”<br />
<code class="literal"> return_path_on_delivery </code> put return path on => and ** lines<br />
<code class="literal"> sender_on_delivery </code> add sender to => lines<br />
<code class="literal">*sender_verify_fail </code> sender verification failures<br />
<code class="literal">*size_reject </code> rejection because too big<br />
<code class="literal">*skip_delivery </code> delivery skipped in a queue run<br />
<code class="literal"> smtp_confirmation </code> SMTP confirmation on => lines<br />
<code class="literal"> smtp_connection </code> SMTP connections<br />
<code class="literal"> smtp_incomplete_transaction</code> incomplete SMTP transactions<br />
<code class="literal"> smtp_no_mail </code> session with no MAIL commands<br />
<code class="literal"> smtp_protocol_error </code> SMTP protocol errors<br />
<code class="literal"> smtp_syntax_error </code> SMTP syntax errors<br />
<code class="literal"> subject </code> contents of <span class="emphasis"><em>Subject:</em></span> on <= lines<br />
<code class="literal"> tls_certificate_verified </code> certificate verification status<br />
<code class="literal">*tls_cipher </code> TLS cipher suite on <= and => lines<br />
<code class="literal"> tls_peerdn </code> TLS peer DN on <= and => lines<br />
<code class="literal"> unknown_in_list </code> DNS lookup failed in list match<br />
<br />
<code class="literal"> all </code> all of the above<br />
</div>
<p>
More details on each of these items follows:
</p>
<div class="itemizedlist">
<ul type="disc"><li><p>
<a id="id651341" class="indexterm"></a>
<span><strong class="option">acl_warn_skipped</strong></span>: When an ACL <span><strong class="option">warn</strong></span> 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.
</p>
</li><li><p>
<a id="id651374" class="indexterm"></a>
<a id="id651388" class="indexterm"></a>
<span><strong class="option">address_rewrite</strong></span>: 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).
</p>
</li><li><p>
<a id="id651415" class="indexterm"></a>
<span><strong class="option">all_parents</strong></span>: Normally only the original and final addresses are logged on
delivery lines; with this selector, intermediate parents are given in
parentheses between them.
</p>
</li><li><p>
<a id="id651442" class="indexterm"></a>
<a id="id651456" class="indexterm"></a>
<span><strong class="option">arguments</strong></span>: 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
<em class="filename">/usr/sbin/sendmail</em>. The logging does not happen if Exim has given up root
privilege because it was called with the <span><strong class="option">-C</strong></span> or <span><strong class="option">-D</strong></span> 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 <em class="filename">util/logargs.sh</em>
between the caller and Exim.
</p>
</li><li><p>
<a id="id651507" class="indexterm"></a>
<span><strong class="option">connection_reject</strong></span>: A log entry is written whenever an incoming SMTP
connection is rejected, for whatever reason.
</p>
</li><li><p>
<a id="id651533" class="indexterm"></a>
<a id="id651548" class="indexterm"></a>
<span><strong class="option">delay_delivery</strong></span>: 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 <span><strong class="option">queue_only</strong></span> is set or <span><strong class="option">-odq</strong></span> was used.
</p>
</li><li><p>
<a id="id651580" class="indexterm"></a>
<span><strong class="option">deliver_time</strong></span>: For each delivery, the amount of real time it has taken to
perform the actual delivery is logged as DT=<<span class="emphasis"><em>time</em></span>>, for example, <code class="literal">DT=1s</code>.
</p>
</li><li><p>
<a id="id651618" class="indexterm"></a>
<a id="id651633" class="indexterm"></a>
<span><strong class="option">delivery_size</strong></span>: For each delivery, the size of message delivered is added to
the “<span class="quote">=></span>” line, tagged with S=.
</p>
</li><li><p>
<a id="id651662" class="indexterm"></a>
<a id="id651676" class="indexterm"></a>
<a id="id651691" class="indexterm"></a>
<span><strong class="option">dnslist_defer</strong></span>: A log entry is written if an attempt to look up a host in a
DNS black list suffers a temporary error.
</p>
</li><li><p>
<a id="id651714" class="indexterm"></a>
<a id="id651728" class="indexterm"></a>
<span><strong class="option">etrn</strong></span>: 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 <span><strong class="option">smtp_syntax_error</strong></span> and <span><strong class="option">smtp_protocol_error</strong></span>).
</p>
</li><li><p>
<a id="id651764" class="indexterm"></a>
<span><strong class="option">host_lookup_failed</strong></span>: 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 “<span class="quote">byname</span>” lookups.
</p>
</li><li><p>
<a id="id651792" class="indexterm"></a>
<a id="id651806" class="indexterm"></a>
<span><strong class="option">ident_timeout</strong></span>: A log line is written whenever an attempt to connect to a
client’s ident port times out.
</p>
</li><li><p>
<a id="id651834" class="indexterm"></a>
<a id="id651849" class="indexterm"></a>
<span><strong class="option">incoming_interface</strong></span>: The interface on which a message was received is added
to the “<span class="quote"><=</span>” 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 “<span class="quote">SMTP connection from</span>”, and to
rejection lines.
</p>
</li><li><p>
<a id="id651884" class="indexterm"></a>
<a id="id651898" class="indexterm"></a>
<a id="id651913" class="indexterm"></a>
<a id="id651928" class="indexterm"></a>
<a id="id651940" class="indexterm"></a>
<span><strong class="option">incoming_port</strong></span>: The remote port number from which a message was received is
added to log entries and <span class="emphasis"><em>Received:</em></span> 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 <em class="varname">$sender_fullhost</em> and
<em class="varname">$sender_rcvhost</em> variables. Recording the remote port number has become more
important with the widening use of NAT (see RFC 2505).
</p>
</li><li><p>
<a id="id651979" class="indexterm"></a>
<span><strong class="option">lost_incoming_connection</strong></span>: A log line is written when an incoming SMTP
connection is unexpectedly dropped.
</p>
</li><li><p>
<a id="id652005" class="indexterm"></a>
<a id="id652020" class="indexterm"></a>
<a id="id652034" class="indexterm"></a>
<span><strong class="option">outgoing_port</strong></span>: The remote port number is added to delivery log lines (those
containing => tags) following the IP address. This option is not included in
the default setting, because for most ordinary configurations, the remote port
number is always 25 (the SMTP port).
</p>
</li><li><p>
<a id="id652062" class="indexterm"></a>
<a id="id652076" class="indexterm"></a>
<span><strong class="option">pid</strong></span>: The current process id is added to every log line, in square brackets,
immediately after the time and date.
</p>
</li><li><p>
<a id="id652102" class="indexterm"></a>
<a id="id652116" class="indexterm"></a>
<span><strong class="option">queue_run</strong></span>: The start and end of every queue run are logged.
</p>
</li><li><p>
<a id="id652141" class="indexterm"></a>
<span><strong class="option">queue_time</strong></span>: The amount of time the message has been in the queue on the
local host is logged as QT=<<span class="emphasis"><em>time</em></span>> on delivery (<code class="literal">=></code>) lines, for example,
<code class="literal">QT=3m45s</code>. 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.
</p>
</li><li><p>
<span><strong class="option">queue_time_overall</strong></span>: The amount of time the message has been in the queue on
the local host is logged as QT=<<span class="emphasis"><em>time</em></span>> on “<span class="quote">Completed</span>” lines, for
example, <code class="literal">QT=3m45s</code>. The clock starts when Exim starts to receive the
message, so it includes reception time as well as the total delivery time.
</p>
</li><li><p>
<a id="id652218" class="indexterm"></a>
<span><strong class="option">received_recipients</strong></span>: 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 “<span class="quote">for</span>”. 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.
</p>
</li><li><p>
<a id="id652252" class="indexterm"></a>
<span><strong class="option">received_sender</strong></span>: 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
“<span class="quote">from</span>” (before the recipients if <span><strong class="option">received_recipients</strong></span> is also set).
</p>
</li><li><p>
<a id="id652288" class="indexterm"></a>
<span><strong class="option">rejected_header</strong></span>: 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 <em class="function">local_scan()</em> function (see section <a href="ch42.html#SECTapiforloc" title="42.2 API for local_scan()">42.2</a>).
</p>
</li><li><p>
<a id="id652332" class="indexterm"></a>
<span><strong class="option">retry_defer</strong></span>: A log line is written if a delivery is deferred because a
retry time has not yet been reached. However, this “<span class="quote">retry time not reached</span>”
message is always omitted from individual message logs after the first delivery
attempt.
</p>
</li><li><p>
<a id="id652362" class="indexterm"></a>
<span><strong class="option">return_path_on_delivery</strong></span>: 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 <em class="filename">/dev/null</em> or to <code class="literal">:blackhole:</code>.
</p>
</li><li><p>
<a id="id652402" class="indexterm"></a>
<span><strong class="option">sender_on_delivery</strong></span>: The message’s sender address is added to every delivery
and bounce line, tagged by F= (for “<span class="quote">from</span>”).
This is the original sender that was received with the message; it is not
necessarily the same as the outgoing return path.
</p>
</li><li><p>
<a id="id652437" class="indexterm"></a>
<span><strong class="option">sender_verify_fail</strong></span>: 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 “<span class="quote">sender verify failed</span>”, so some
detail is lost.
</p>
</li><li><p>
<a id="id652468" class="indexterm"></a>
<span><strong class="option">size_reject</strong></span>: A log line is written whenever a message is rejected because
it is too big.
</p>
</li><li><p>
<a id="id652493" class="indexterm"></a>
<a id="id652508" class="indexterm"></a>
<span><strong class="option">skip_delivery</strong></span>: 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.
<a id="id652529" class="indexterm"></a>
The message that is written is “<span class="quote">spool file is locked</span>”.
</p>
</li><li><p>
<a id="id652552" class="indexterm"></a>
<a id="id652566" class="indexterm"></a>
<span><strong class="option">smtp_confirmation</strong></span>: The response to the final “<span class="quote">.</span>” in the SMTP dialogue for
outgoing messages is added to delivery log lines in the form <code class="literal">C=</code><<span class="emphasis"><em>text</em></span>>.
A number of MTAs (including Exim) return an identifying string in this
response.
</p>
</li><li><p>
<a id="id652609" class="indexterm"></a>
<a id="id652623" class="indexterm"></a>
<span><strong class="option">smtp_connection</strong></span>: A log line is written whenever an SMTP connection is
established or closed, unless the connection is from a host that matches
<span><strong class="option">hosts_connection_nolog</strong></span>. (In contrast, <span><strong class="option">lost_incoming_connection</strong></span> applies
only when the closure is unexpected.) This applies to connections from local
processes that use <span><strong class="option">-bs</strong></span> 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.
</p>
<p>
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.
</p>
</li><li><p>
<a id="id652670" class="indexterm"></a>
<a id="id652685" class="indexterm"></a>
<span><strong class="option">smtp_incomplete_transaction</strong></span>: 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.
</p>
</li><li><p>
<a id="id652714" class="indexterm"></a>
<a id="id652728" class="indexterm"></a>
<span><strong class="option">smtp_no_mail</strong></span>: 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.
</p>
<p>
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.
</p>
<p>
Finally, if any SMTP commands were issued during the connection, a C= item
is added to the line, listing the commands that were used. For example,
</p>
<pre class="literallayout">C=EHLO,QUIT
</pre><p>
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 “<span class="quote">...</span>”. However, with the default
setting of 10 for <span><strong class="option">smtp_accep_max_nonmail</strong></span>, the connection will in any case
have been aborted before 20 non-mail commands are processed.
</p>
</li><li><p>
<a id="id652800" class="indexterm"></a>
<a id="id652814" class="indexterm"></a>
<span><strong class="option">smtp_protocol_error</strong></span>: 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 “<span class="quote">expected</span>” errors (for example, RCPT
received after rejecting MAIL) as protocol errors.
</p>
</li><li><p>
<a id="id652849" class="indexterm"></a>
<a id="id652864" class="indexterm"></a>
<a id="id652878" class="indexterm"></a>
<a id="id652893" class="indexterm"></a>
<a id="id652907" class="indexterm"></a>
<span><strong class="option">smtp_syntax_error</strong></span>: 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 <span><strong class="option">-bs</strong></span> the sender identification (normally the calling user) is given.
</p>
</li><li><p>
<a id="id652940" class="indexterm"></a>
<a id="id652954" class="indexterm"></a>
<span><strong class="option">subject</strong></span>: The subject of the message is added to the arrival log line,
preceded by “<span class="quote">T=</span>” (T for “<span class="quote">topic</span>”, since S is already used for “<span class="quote">size</span>”).
Any MIME “<span class="quote">words</span>” in the subject are decoded. The <span><strong class="option">print_topbitchars</strong></span> option
specifies whether characters with values greater than 127 should be logged
unchanged, or whether they should be rendered as escape sequences.
</p>
</li><li><p>
<a id="id652999" class="indexterm"></a>
<span><strong class="option">tls_certificate_verified</strong></span>: An extra item is added to <= and => log lines
when TLS is in use. The item is <code class="literal">CV=yes</code> if the peer’s certificate was
verified, and <code class="literal">CV=no</code> if not.
</p>
</li><li><p>
<a id="id653041" class="indexterm"></a>
<a id="id653055" class="indexterm"></a>
<span><strong class="option">tls_cipher</strong></span>: When a message is sent or received over an encrypted
connection, the cipher suite used is added to the log line, preceded by X=.
</p>
</li><li><p>
<a id="id653081" class="indexterm"></a>
<a id="id653096" class="indexterm"></a>
<span><strong class="option">tls_peerdn</strong></span>: 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=.
</p>
</li><li><p>
<a id="id653122" class="indexterm"></a>
<span><strong class="option">unknown_in_list</strong></span>: This setting causes a log entry to be written when the
result of a list match is failure because a DNS lookup failed.
</p>
</li></ul></div>
</div>
<div class="section" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 xmlns="" class="title"><a xmlns="http://www.w3.org/1999/xhtml" href="index.html#toc0451" id="SECID260">49.16 Message log</a></h3></div>
</div>
</div>
<p>
<a id="id653158" class="indexterm"></a>
<a id="id653172" class="indexterm"></a>
<a id="id653186" class="indexterm"></a>
<a id="id653202" class="indexterm"></a>
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 <em class="filename">msglog</em> 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 <span><strong class="option">preserve_message_logs</strong></span> is set, but this should be used
only with great care because they can fill up your disk very quickly.
</p>
<p>
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
<span><strong class="option">message_logs</strong></span> option false.
<a id="id653243" class="indexterm"></a>
</p>
</div>
</div>
<div class="navfooter">
<table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch48.html">Prev</a> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="ch50.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top"> </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> </td></tr></table></div>
</body></html>
