Exim splits up mail delivery into three different tasks: routing, directing, and transporting. There are a number of code modules of each type, and each is separately configurable. Usually a number of different routers, directors, and transports are set up in the configuration file.
Routers resolve remote addresses, determining which host the message should be sent to and which transport should be used. In Internet-connected hosts there is often just one router, which does the resolution by looking up the domain in the DNS. Alternatively, there may be one router that handles addresses destined for hosts on a local LAN, and a second to send any other addresses to a single smart host ; for example, an ISP's mail server.
Local addresses are given to the directors, of which there are normally several, to handle aliasing and forwarding as well as identifying local mailboxes. Mailing lists can be handled by aliasing or forwarding directors. If an address gets aliased or forwarded, any generated addresses are handled independently by the routers or directors, as necessary. By far the most common case will be delivery to a mailbox, but messages may also be piped into a command or appended to a file other than the default mailbox.
A transport is responsible for implementing a method of delivery; for example, sending the message over an SMTP connection or adding it to a specific mailbox. Routers and directors select which transport to use for each recipient address. If a transport fails, Exim either generates a bounce message or defers the address for a later retry.
With Exim, you have a lot of freedom in configuring these tasks. For each of them, a number of drivers are available, from which you can choose those you need. You describe them to Exim in different sections of its configuration file. The transports are defined first, followed by the directors, and then the routers. There are no built-in defaults, though Exim is distributed with a default configuration file that covers simple cases. If you want to change Exim's routing policy or modify a transport, it is easiest to start from the default configuration and make changes rather than attempt to set up a complete configuration from scratch.
When given an address to deliver, Exim first checks whether the domain is one that is handled on the local host by matching it against a list in the local_domains configuration variable. If this option is not set, the local host name is used as the only local domain. If the domain is local, the address is handed to the directors. Otherwise, it is handed to the routers to find out which host to forward a message to.[1]
Most commonly, a local address is just a user's login name, in which case the message is delivered to the user's mailbox, /var/spool/mail/user-name. Other cases include aliases, mailing list names, and mail forwarding by the user. In these cases, the local address expands to a new list of addresses, which may be either local or remote.
Apart from these “normal” addresses, Exim can handle other types of local message destinations, like filenames and pipe commands. When delivering to a file, Exim appends the message, creating the file if necessary. File and pipe destinations are not addresses in their own right, so you can't send mail to, say, /etc/passwd@vbrew.com and expect to overwrite the password file; deliveries to a specific file are valid only if they come from forwarding or alias files. Note, however, that /etc/passwd@vbrew.com is a syntactically valid email address, but if Exim received it, it would (typically) search for a user whose login name was /etc/passwd, fail to find one, and bounce the message.
In an alias list or forwarding file, a filename is anything that begins with a slash (/ ) that does not parse as a fully qualified email address. For example, /tmp/junk in a forwarding or alias file is interpreted as a file name, but /tmp/junk@vbrew.com is an email address, though it is not likely to be a very useful one. However, valid addresses of this type are seen when sending mail through X.400 gateways, because X.400 addresses start with a slash.
Similarly, a pipe command may be any Unix command preceded by the pipe symbol (|), unless the string parses as a valid email address complete with domain. Unless you have changed the configuration, Exim does not use a shell to run the command; instead, it splits it up into a command name, arguments itself, and runs it directly. The message is fed to the command on its standard input.
For example, to gate a mailing list into a local newsgroup, you might use a shell script named gateit, and set up a local alias that delivers all messages from this mailing list to the script using |gateit. If the command line contains a comma, it and the preceding pipe symbol must be enclosed in double quotes.
A local address most commonly denotes a user's mailbox. This is normally located in /var/spool/mail and has the name of the user, who also owns the file. If it does not exist, it is created by Exim.
In some configurations, the group is set to the user's group and the mode is 0600. In these cases, delivery processes are run as the user, and the user may delete the mailbox entirely. In other configurations, the mailbox's group is mail, and it has mode 660; delivery processes are run under a system uid and group mail, and users cannot delete their mailbox files, though they can empty them.
Note that although /var/spool/mail is currently the standard place to put the mailbox files, some mail software may be compiled to use different paths, for example, /usr/spool/mail. If delivery to users on your machine fails consistently, you should see if it helps to make this a symbolic link to /var/spool/mail.
The addresses MAILER-DAEMON and postmaster should normally appear in your alias file, expanding into the email address of the system administrator. MAILER-DAEMON is used by Exim as the sender address in bounce messages. It is also recommended that root be set up as an alias for an administrator, especially when deliveries are being run under the permissions of the recipient users, in order to avoid running any delivery as root.
Users can redirect their mail to alternative addresses by creating a .forward file in their home directories. This contains a list of recipients separated by commas and/or newlines. All lines of the file are read and interpreted. Any type of address may be used. A practical example of a .forward file for vacations might be:
janet, "|vacation" |
The first address in the forward file delivers the incoming message to janet's mailbox, while the vacation command returns a short notification to the sender.[3]
In addition to supporting “traditional” forwarding files, Exim can be configured to allow more complex files called filters. Instead of being just a list of forwarding addresses, a filter file can contain tests on the contents of the incoming message so that, for example, messages could be forwarded only if the subject contained the message “urgent.” The system administrator must decide whether to allow users this flexibility.
Exim is able to handle alias files compatible with Berkeley's sendmail alias files. Entries in the alias file can have the following form:
alias: recipients |
recipients is a comma-separated list of addresses that will be substituted for the alias. The recipient list may be continued across newlines if the next line begins with whitespace.
A special feature allows Exim to handle mailing lists that are held separately from the alias file: if you specify :include:filename as a recipient, Exim reads the specified file and substitutes its contents as a list of recipients. An alternative to handling mailing lists is shown later in this chapter in Section 19.6.4.”
The main aliases file is /etc/aliases. If you
make this file world-writable or group-writeable, Exim will refuse to
use it and will defer local deliveries. You can control the test it
applies to the file's permissions by setting modemask
in the system_aliases director.
This is a sample aliases file:
# vbrew.com /etc/aliases file
hostmaster: janet
postmaster: janet
usenet: phil
# The development mailing list.
development: joe, sue, mark, biff,
/var/mail/log/development
owner-development: joe
# Announcements of general interest are mailed to all
# of the staff
announce: :include: /etc/Exim/staff,
/var/mail/log/announce
owner-announce: root
# gate the ppp mailing list to a local newsgroup
ppp-list: "|/usr/local/bin/gateit local.lists.ppp" |
When there are file names and pipe commands in an alias file, as here,
Exim needs to be told which userid to run the deliveries under. The
user option (and possibly group,
too) must be set in Exim's configuration file, either on the director
that is handling the aliases, or on the transports to which it directs
these items.
If an error occurs while delivering to an address generated from the
aliases file, Exim will send a bounce message to
the sender of the message, as usual, but this might not be
appropriate. The errors_to option can be used to
specify that bounce messages are to be sent elsewhere; for example, to
the postmaster.
Instead of the aliases file, mailing lists may also be managed by means a forwardfile director. The lists are all kept in a single directory such as /etc/exim/lists/, and a mailing list named nag-bugs is described by the file lists/nag-bugs. This should contain the members' addresses separated by commas or newlines. Lines beginning with a hash sign (#) are treated as comments. A simple director to use such data is as follows:
lists:
driver = forwardfile
file = /etc/exim/lists/${local_part}
no_check_local_user
errors_to = ${local_part}-request |
file and
errors_to options are expanded.
Expansion causes certain portions of the strings beginning with dollar
characters to be replaced every time the string is used. The simplest
kind of expansion is the insertion of the value of one of Exim's
variables, and this is what is happening here. The substring
${local_ part} substitutes the value of the
$local_ part, which is the local part of the address
that is being processed.For each mailing list, a user (or alias or mailing list) named listname-request should exist; any errors occurring when resolving an address or delivering to a list member are reported to this address.
| [1] | This is a simplification. It is possible for directors to pass addresses to transports that deliver to remote hosts, and similarly, it is possible for routers to pass addresses to local transports that write the messsage to a file or a pipe. It is also possible for routers to pass addresses to the directors in some circumstances. |
| [2] | A director is skipped if the address it is about to process is one that it has previously processed in the course of generating the present address. |
| [3] | Please, if you choose to use a vacation program, make sure it will not reply to messages sent from mailing lists! It is very annoying to discover that someone has gone on vacation and find a vacation message for every message they've received. Mailing list administrators: this is a good example of why it is bad practice to force the Reply-To: field of mailing list messages to that of the list submission address. |