Exim: The Mail Transfer Agent: The Mail Transport Agent [Paperback]

You can do anything with sendmail, the saying goes, but why would you want to? The Exim mail-handling daemon, described in Philip Hazel's Exim: The Mail Transfer Agent, is just as capable as the old stalwart for handling everyday electronic mail duties, and is far easier to administer. Exim: The Mail Transfer Agent shows how to set up and use Exim with a style and polish that's typical of the blue-cover series of system-administration books from O'Reilly. You'll be very pleased with this book if you've chosen to work with Exim but require better information than the online documentation can provide. Philip Hazel has done a good job of combining a comprehensive set of details--including lots of command listings--with advice and practical examples that will make an administrator's life easier.

Typical of this approach is the treatment of methods for blocking traffic from bad hosts that attempt to mail to your Exim station. The book runs through alternative techniques--using a public blocking list, blocking hosts explicitly and so on--in series. Each technique is described in terms of what happens and why, and includes listings of the relevant configuration commands. Other sections, such as those concerned with SMTP configuration, are more reference-like. They contain long lists of commands and options, in which the purpose of each is explained. --David Wall

Topics covered: How to set up, configure and administer the Exim mail-handling agent. Directors, routers, transports, filters and the integration of Exim with Perl, shell scripts and database look-ups are covered.

'A good book, and one I found I could actually start at the beginning of and read through.' - Andrew Johnson, West Yorkshire Linux User Group 'As this book is written by Exim's author you would expect it to be both authoritative and accurate and it is both of those - there were no glaring errors or omissions in the text. In addition the book is well written and perfectly readable...I have no hesitation in recommending this book to anybody with a need to manage an Exim based mail system of any size.' - Tom Hughes, Cvu, April

Exim is the default mail transport agent installed on some Linux systems; it runs on many versions of Unix and is suitable for any TCP/IP network with any combination of hosts and end-user mail software. It is open source, scalable, rich in features, and--best of all--easy to configure. This official guide is written by Philip Hazel, the creator of Exim.

Chapter 3 - Exim Overview

Contents:
Exim Philosophy
Exim's Queue
Receiving and Delivering Messages
Exim Processes
Coordination Between Processes
How Exim Is Configured
How Exim Delivers Messages
Local and Remote Addresses
Processing an Address
A Simple Example
Complications While Directing and Routing
Complications During Delivery
Complications After Delivery
Use of Transports by Directors and Routers

In the previous chapter, the job of an MTA is described in general terms. In this chapter, we explain how Exim is organized to do this job, and the overall way in which it operates. Then in the next chapter, we cover the basics of Exim administration before launching into more details about the configuration.

Exim Philosophy
Exim is designed for use on a network where most messages can be delivered at the first attempt. This is true for most of the time over a large part of the Internet. Measurements taken in the author's environment (a British university) indicate that well over 90 percent of messages are delivered almost immediately under normal conditions. This means that there is no need for an elaborate centralized queuing mechanism through which all messages pass. When a message arrives, an immediate delivery attempt is likely to be successful; only for a small number of messages is it necessary to implement a holding and retrying mechanism.

Therefore, although it is possible to configure Exim otherwise, the normal action is to try an immediate delivery as soon as a message has been received. In many cases this is successful, and nothing more is needed to process the message. Nevertheless, some precautions must be taken to avoid system overload in times of stress. For example, if the system load rises above some threshold, or if there are a large number of simultaneous incoming SMTP connections, immediate delivery may be temporarily disabled. In these events, incoming messages wait on Exim's queue and are delivered later.

All operations are performed by a single Exim binary, which operates in different ways, depending on the arguments with which it is called. Although receiving and delivering messages are treated as entirely separate operations, the code for determining how to deliver to a specific address is needed in both cases, because during message reception, addresses are verified by checking whether it would be possible to deliver to them. For example, Exim verifies a remote sender address by looking up the domain in the DNS in exactly the same way as when setting up a delivery to that address.

Exim's Queue
The word queue is used for the set of messages that Exim has under its control at any one time, because this word is common in the context of mail transfer. However, Exim's queue is normally treated as a collection of messages with no implied ordering, more like a ''pool'' than a ''queue.'' Furthermore, Exim does not maintain separate queues for different domains or different remote hosts.

There is just a single collection of messages awaiting delivery, each of which may have several recipients. You can list the messages on the queue by running the command:

exim -bp

assuming that your path is set up to contain the directory where the Exim binary is located. Messages that are not delivered immediately on arrival are picked up later by queue runner processes that scan the entire queue and start a delivery process for each message in turn. A queue runner process waits for each delivery process to complete before starting the next one.

Receiving and Delivering Messages
Message reception and message delivery are two entirely separate operations in Exim, and their only connection is that Exim normally tries to deliver a message as soon as it has received it. Receiving a message consists of writing it to local spool files (''putting it on the queue'') and checking that the files have been successfully written before acknowledging reception to the sending host or local process. There is only one copy of each message, however many recipients it has, and the collection of spool files is the queue; there are no additional files or in-memory lists of messages.

A delivery operation gets all its data from the spool files. Each attempt at delivering a message processes every undelivered recipient address afresh. Exim does not normally retain previous alias, forwarding, or mailing list expansions from one delivery attempt to another.[1]

[1]There is, however, one exception to this: if the one_time option is set for a mailing list, the list's addresses are added to the original list of recipients at the first delivery attempt, and no re-expansion occurs at subsequent attempts.