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/[email protected] 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/[email protected] 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/[email protected]
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:
In other descriptions of
.forward files, you might
see the username at the start preceded by a backslash. This was
necessary in some older MTAs to stop a search for a
.forward for the new name, which could lead to
looping. The backslash is not necessary in Exim, which automatically
avoids loops of this kind.
[2]
However, a backslash is permitted, and in fact it does make a difference
in configurations where several domains are being handled at once.
Without a backslash, an unqualified username is qualified with a
default domain; with a backslash the incoming domain is preserved.
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:
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 |
When this director runs, the values of the
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.
