Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

19.4. Mail Delivery Modes

As noted previously, Exim is able to deliver messages immediately or queue them for later processing. All incoming mail is stored in the input directory below /var/spool/exim. When queueing is not in operation, a delivery process is started for each message as soon as it arrives. Otherwise, it is left on the queue until a queue-runner process picks it up. Queueing can be made unconditional by setting queue_only in the configuration file, or it can be conditional on the 1-minute system load by a setting such as:
queue_only_load = 4
which causes messages to be queued if the system load exceeds 4.[1]

If your host is not permanently connected to the Internet, you may want to turn on queueing for remote addresses, while allowing Exim to perform local deliveries immediately. You can do this by setting:
queue_remote_domains = *
in the configuration file.

If you turn on any form of queuing, you have to make sure the queues are checked regularly, probably every 10 or 15 minutes. Even without any explicit queueing options, the queues need to be checked for messages that have been deferred because of temporary delivery failures. If you run Exim in daemon mode, you must add the –q15m option on the command line to process the queue every 15 minutes. You can also invoke exim –q from cron at these intervals.

You can display the current mail queue by invoking Exim with the –bp option. Equivalently, you can make mailq a link to Exim, and invoke mailq :
$ mailq
 2h   52K 12EwGE-0005jD-00 <[email protected]>
        D [email protected]
          [email protected]  

This shows a single message from [email protected] to two recipients sitting in the message queue. It has been successfully delivered to [email protected], but has not yet been delivered to [email protected], though it has been on the queue for two hours. The size of the message is 52K, and the ID by which Exim identifies this message is 12EwGE-0005jD-00. You can find out why the delivery is not yet complete by looking at the message's individual log file, which is kept in the msglog directory in Exim's spool directory. The –Mvl option is an easy way of doing this:
$ exim –Mvl 12EwGE-0005jD-00
2000-01-30 17:28:13 example.net [192.168.8.2]: Connection timed out
2000-01-30 17:28:13 [email protected]: remote_smtp transport deferred: 
  Connection timed out
Individual log files keep a copy of log entries for each message so you can easily inspect them. The same information could have been extracted from the main log file using the exigrep utility:
$ exigrep 12EwGE-0005jD-00 /var/log/exim/exim_mainlog
That would take longer, especially on a busy system where the log files can get quite big. The exigrep utility comes into its own when looking for information about more than one message. Its first argument is a regular expression, and it picks out all the log lines concerned with any messages that have at least one log line that matches the expression. Thus it can be used to pick out all messages for one specific address, or all those to or from a specific host.

You can keep a general watch on what a running Exim is doing by running tail on its main log file. Another way of doing this is to run the eximon utility that comes with Exim. This is an X11 application that puts up a scrolling display of the main log, and also shows a list of messages that are awaiting delivery, as well as some stripcharts about delivery activity.

Notes

[1]

The system load is a standard Unix measure of the average number of processes that are queued up, waiting to run. The uptime shows load averages taken over the previous 1, 5, and 15 minutes.

 
 
  Published under the terms of the Creative Commons License Design by Interspire