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:
exim -bP log_file_path |
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 <= jack@vstout.vbrew.com H=vstout.vbrew.com [192.168.131.111] U=exim P=esmtp S=32100 id=38690D72.286F@vstout.vbrew.com 2000-01-30 15:46:37 12EwYe-0004WO-00 => jill <jill@vbrew.com> D=localuser T=local_delivery 2000-01-30 15:46:37 12EwYe-0004WO-00 Completed |
These entries show that a message from jack@vstout.vbrew.com to jill@vbrew.com 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 “**”:
2000-01-30 14:48:28 12EvcH-0003rC-00 ** bill@lager.vbrew.com R=lookuphost T=smtp: SMTP error from remote mailer after RCPT TO: <bill@lager.vbrew.com>: host lager.vbrew.com [192.168.157.2]: 550 <bill@lager.vbrew.com>... User unknown |
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 == jim@bitter.vbrew.com 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.