Go to the first, previous, next, last section, table of contents.
This list of expansion variable substitutions contains those that are likely to
be of use in filter files. Others that are not relevant at filtering time, or
are of interest only to the system administrator, are omitted.
`$0', `$1', etc: When a `matches' expansion condition succeeds, these
variables contain the captured substrings identified by the regular expression
during subsequent processing of the success string of the containing "if"
expansion item. They may also be set externally by some other matching process
which precedes the expansion of the string. For example, the commands available
in Exim filter files include an "if" command with its own regular expression
matching condition.
`$domain': When an address is being directed, routed, or delivered on its own,
this variable contains the domain. In particular, it is set during
user filtering, but not during system filtering, since a message may have many
recipients and the system filter is called just once.
`$home':
This is set to the user's home directory when user filtering is configured in
the normal way.
When running a filter test via the `-bf' option, `$home' is set to the value
of the environment variable HOME.
`$local_part': When an address is being directed, routed, or delivered on its
own, this variable contains the local part. If a local part prefix or suffix
has been recognized, it is not included in the value.
`$local_part_prefix': When an address is being directed or delivered locally,
and a specific prefix for the local part was recognized, it is available in
this variable. Otherwise it is empty.
`$local_part_suffix': When an address is being directed or delivered locally,
and a specific suffix for the local part was recognized, it is available in
this variable. Otherwise it is empty.
`$key': When a domain list is being searched, this variable contains the value
of the key, so that it can be inserted into strings for query-style lookups.
See chapter "" for details. In other circumstances this variable is
empty.
`$message_body': This variable c
Exim Overview
The Exim Mail Transport Agent
Table of Contents
Date: 10 July 1997
Exim is a mail transport agent (MTA) developed at the University of Cambridge
for use on Unix systems connected to the Internet. It is freely available under
the terms of the GNU General Public Licence. In style it is similar to Smail 3,
but its facilities are more extensive, and in particular it has some defences
against mail bombs and unsolicited junk mail, in the form of options for
refusing messages from particular hosts, networks, or senders.
Exim is in production use on a number of sites that move tens of thousands of
messages per day. This document contains an overview description of the way
Exim works, with a certain amount of omission and simplification to keep it
fairly short. Please address any enquiries about Exim to Philip Hazel:
Email: <ph10@cus.cam.ac.uk>
Phone: +44 1223 334714
Fax: +44 1223 334679
University of Cambridge
Computer Laboratory
Pembroke Street
Cambridge CB2 3QG
United Kingdom
This document is copyright (c) University of Cambridge 1997, but copying
permission is granted to all.
-------------------------------------------------------------------------
"If I have seen further it is by standing on the shoulders of giants."
(Isaac Newton)
Exim owes a great deal to Smail 3 and its author, Ron Karr. Without the
experience of running and working on the Smail 3 code, I could never have
contemplated starting to write a new mailer. Many of the ideas and
configuration interfaces are taken from Smail 3, though the actual code of Exim
is entirely new.
My intention was to write a mailer that had more functionality than Smail 3,
but which retained the simple lightweight approach, as this seemed to me to be
all that was needed for systems directly connected to the Internet, where most
messages are delivered almost immediately.
The current distribution of Exim is available from
$st{ftp://ftp.cus.cam.ac.uk/pub/software/programs/exim/exim-$si{n.nn}.tar.gz}
where n.nn is the version number. The distribution contains an ASCII
copy of the documentation; other formats are available from
$st{ftp://ftp.cus.cam.ac.uk/pub/software/programs/exim/exim-postscript-$si{n.nn}.tar.gz}
$st{ftp://ftp.cus.cam.ac.uk/pub/software/programs/exim/exim-texinfo-$si{n.nn}.tar.gz}
The following operating systems are currently supported: AIX, BSDI, DGUX, FreeBSD,
HI-OSF (Hitachi), HP-UX, IRIX, Linux, MIPS RISCOS, NetBSD, OpenBSD, DEC OSF1
(aka Digital UNIX), SCO, SCO SVR4.2 (aka UNIX-SV), SunOS4, SunOS5, Ultrix, and
Unixware.
For the benefit of those reading this overview to see whether Exim is of
interest to them, its limitations are listed first.
-
Exim is written in ANSI C. This should not be much of a limitation these days.
However, to help with systems that lack a true ANSI C library, Exim avoids
making any use of the value returned by the `sprintf()' function, which is one
of the main incompatibilities. It has its own version of `strerror()' for use
with SunOS4 and any other system that lacks this function, and a macro can be
defined to turn `memmove()' into `bcopy()' if necessary.
-
Exim uses file names that are longer than 14 characters.
-
Exim is intended for use as an Internet mailer, and therefore handles addresses
in RFC 822 domain format only. It cannot handle `bang paths', though simple
two-component bang paths can be converted by a straightforward rewriting
configuration.
-
Exim insists that every address it handles has a domain attached. For incoming
local messages, domainless addresses are automatically qualified with a
configured domain value. Configuration options specify from which remote
systems unqualified addresses are acceptable.
-
The only external transport currently implemented is an SMTP transport over
a TCP/IP network (using sockets), suitable for machines on the Internet.
However, a pipe transport is available, and there are facilities for writing
messages to files in `batched SMTP' format; both of these can be used to send
messages to some other transport mechanism such as UUCP. Batched SMTP input is
also catered for.
Exim follows the same general approach of decentralized control that Smail 3
does. There is no central process doing overall management of mail delivery.
However, unlike Smail, the independent delivery processes share data in the
form of `hints', which makes delivery more efficient in some cases. The hints
are kept in a number of DBM files. If any of these files are lost, the only
effect is to change the pattern of delivery attempts and retries.
Here is a summary of Exim's main features. More details are given in the
sections which follow.
-
Many configuration options can be given as expansion strings, and as these can
include file lookups, much of Exim's operation can be made table-driven if
desired. For example, it is possible to do local delivery on a machine on which
the users do not have accounts.
-
Regular expressions are available in a number of configuration parameters.
-
Domain lists can include file lookups, making it possible to support a large
number of local domains.
-
Exim has flexible retry algorithms, applicable to mail routing as well as to
delivery.
-
Exim contains header and envelope rewriting facilities.
-
Unqualified addresses are accepted only from specified hosts or networks.
-
Exim can perform multiple deliveries down the same SMTP channel after deliveries
to a host have been delayed.
-
Exim can be configured to do local deliveries immediately but to leave remote
deliveries until the message is picked up by a queue-runner process. This
increases the likelihood of multiple messages being sent down a single SMTP
connection.
-
When copies of a message have to be delivered to more than one remote host, up
to a configured maximum number of remote deliveries can be done in parallel.
-
Exim supports optional checking of incoming return path (sender) and receiver
addresses as they are received by SMTP.
-
SMTP calls from specific hosts and networks, optionally from specific idents,
can be locked out, and incoming SMTP messages from specific senders can also be
locked out.
-
It is possible to control which hosts may use the Exim host as a relay for
onward transmission of mail; the control can be made to depend on the address
domain.
-
Messages on the queue can be `frozen' and `thawed' by the administrator.
-
The maximum size of message can be specified.
-
Exim can handle a number of independent local domains on the same machine; each
domain can have its own alias files, etc. These are commonly called virtual
domains.
-
Exim stats a user's home directory before looking for a `.forward' file, in
order to detect the case of a missing NFS mount.
-
Exim contains an optional built-in mail filtering facility. This enables users
to set up their own mail filtering in a straightfoward manner without the need
to run an external program. There can also be a system filter file that applies
to all messages.
-
There is support for multiple user mailboxes controlled by prefixes or suffixes
on the user name, either via the filter mechanism or through multiple
`.forward' files.
-
Periodic warnings are automatically sent to messages' senders when delivery is
delayed -- the time between warnings is configurable.
-
A queue run can be manually started to deliver just a particular portion of the
queue, or those messages with a recipient whose address contains a given string.
-
Exim can be configured to run as root only when needed; in particular, it need
not run as root when receiving incoming messages or when sending out messages
over SMTP. It always uses `setuid()' when doing local deliveries.
-
I have tried to make the wording of delivery failure messages clearer and
simpler, for the benefit of those less-experienced people who are now using
email.
-
Exim contains support for IPv6.
-
The Exim Monitor is an optional extra; it displays information about Exim's
processing in an X window, and an administrator can perform a number of control
actions from the window interface.
Although I did not specifically set out to write a high-performance MTA, Exim
does seem to be fairly efficient. The busiest site I know of is an mailing list
exploder that sometimes handles over 100,000 deliveries a day on a big Linux
box, the record being 177,000 deliveries (791MB in total). Up to 13,000
deliveries in an hour have been reported.
Like many MTAs, Exim has adopted the Sendmail interface so that it can be a
straight replacement for `/usr/lib/sendmail'. All the relevant Sendmail
options are implemented. There are also some additional options that are
compatible with Smail 3, and some further options that are new to Exim.
The runtime configuration interface is a single file which is divided into a
number of sections. The entries in this file consist of keywords and values, in
the style of Smail 3 configuration files.
Control of messages on the queue can be done via certain privileged command
line options. There is also an optional monitor program called `eximon', which
displays current information in an X window and contains interfaces to the
command line options.
When Exim receives a message, it writes two files in its spool directory. The
first contains the envelope information, the current status of the message,
and the headers, while the second contains the body of the message. The status
of the message includes a complete list of recipients and a list of those that
have already received the message. The header file gets updated during the
course of delivery if necessary.
A message remains in the spool directory until it is completely delivered to
its recipients or to an error address, or until it is deleted by an
administrator or by the user who originally created it. In cases when delivery
cannot proceed -- for example, when a message can neither be delivered to its
recipients nor returned to its sender, the message is marked `frozen' on the
spool, and no more deliveries are attempted. The administrator can thaw such
messages when the problem has been corrected, and can also freeze individual
messages by hand if necessary.
As delivery proceeds, Exim writes timestamped information about each address to a
per-message log file; this includes any delivery error messages. This log is
solely for the benefit of the administrator. All the information Exim itself
needs for delivery is kept in the header spool file. The message log file is
deleted with the spool files. If a message is delayed for more than a
configured time, a warning message is sent to the sender. This is repeated
whenever the same time elapses again without delivery being complete.
The main delivery processing elements of Exim are called directors,
routers, and transports. Code for a number of these is provided, and
compile-time options specify which ones are actually included in the binary.
Directors handle addresses that include one of the local domains, routers
handle remote addresses, and transports do actual deliveries.
When a message is to be delivered, the sequence of events is roughly as
follows:
-
If there is a system filter file, it is obeyed. This can check on the contents
of the message and its headers, and cause delivery to be abandoned or directed
to alternative or additional addresses.
-
Each address is parsed and a check is made to see if it is local or not, by
comparing the domain with the list of local domains, which can be wildcarded,
or even held in a file if there are a large number of them.
-
If an address is local, it is passed to each configured director in turn until
one is able to handle it. If none can, the address is failed. Directors can be
targeted at particular local domains, so several local domains can be processed
independently of each other.
-
A director that accepts an address may set up a local or a remote transport for
it, or it may generate one or