A number of features are available for troubleshooting installation problems.
The first place to check is Exim's log files. On Linux systems they are
normally kept in /var/log/exim/log and are named
exim_mainlog, exim_rejectlog, and
exim_paniclog. On other operating systems, they are
often kept in /var/spool/exim/log. You can find out
where the log files are by running the command:
The main log lists all transactions, the reject log contains details of
messages that were rejected for policy reasons, and the panic log is
for messages related to configuration errors and the like.
Typical entries in the main log are shown below. Each entry in the log itself
is a single line of text, starting with a date and time. They have
been split into several lines here in order to fit them on the page:
2000-01-30 15:46:37 12EwYe-0004WO-00 <= [email protected]
H=vstout.vbrew.com [192.168.131.111] U=exim P=esmtp S=32100
[email protected]
2000-01-30 15:46:37 12EwYe-0004WO-00 => jill <[email protected]>
D=localuser T=local_delivery
2000-01-30 15:46:37 12EwYe-0004WO-00 Completed |
These entries show that a message from
[email protected]
to [email protected] was
successfully delivered to a mailbox on the local host. Message arrivals
are flagged with <=, and deliveries with
=>.
There are two kinds of delivery errors: permanent and temporary. A permanent
delivery error is recorded in a log entry like this, flagged with
“**”:
After a failure like this, Exim sends a delivery failure report, often called a
bounce message back to the sender.
Temporary errors are
flagged with “==”:
2000-01-30 12:50:50 12E9Un-0004Wq-00 == [email protected]
T=smtp defer (145): Connection timed out |
This error is typical for a situation in which Exim properly recognizes
that the message should be delivered to a remote host, but is not able to
connect to the SMTP service on that host. The host may be down or there
could be a network problem. Whenever a message is
deferred like this, it remains on Exim's queue and is
retried at intervals. However, if it fails to be delivered for a sufficiently
long time (usually several days), a permanent error occurs and the message is
bounced.
If you are unable to locate your problem from the error message Exim
generates, you may want to turn on debugging messages. You can do this
using the –d flag, optionally followed by a number
specifying the level of verbosity (a value of 9 gives maximum information).
Exim then displays a report of its operation on the screen, which may
give you more hints about what is going wrong.
