exim Transactional Email Service
Open Source Mail Transfer Agent as Alternative to Sendmail
Exim is highly customizable open source mail transfer agent for email routing and delivery. It’s the number one choice for enterprise level organizations for its flexibility.
Overview
Communication via electronic mail has become primitive in our lives. To send emails from desktop, mobile or any other device is a day to day affair for most of the people. Simple Mail Transfer Protocol (SMTP) is the standard protocol used to send emails. IMAP and POP3 are the protocols to receive emails. IMAP has some advantages over the POP due to synchronization across the devices. So, a Mail transfer agent that open source and supports all these required protocols is crucial.
Running your mail transfer agent is a very tedious job and hence the choice you make for the MTA Software requires a deep analysis against your requirement matrix. Exim is one of the most flexible open source mail transfer agent which can be used as the replacement of the default mail transfer agent of the most UNIX systems..
Exim comes with a bundle of cutting edge features including Sendmail compatibility, cPanel Support, Flexible Configuration, and above all huge open source community support. Exim is like a framework with its application language to setup complex configurations. It has an advanced multi-step mail processing logic which helps it to solve complex use cases.
Sendmail is already lost to Postfix in all aspects, however, Postfix is less versatile then Exim. It has excellent integration support and it provides everything a system administrator can ask. Exim supports most of the Mail Transfer Agent features in some way or another.
System Requirements
Before building Exim, a local configuration file that specifies options independent of any operating system has to be created with the name Local/Makefile. A template for this file is supplied as the file src/EDITME, and it contains full descriptions of all the option settings therein. These descriptions are therefore not repeated here. If you are building Exim for the first time, the simplest thing to do is to copy src/EDITME to Local/Makefile, then read it and edit it appropriately.
There are three settings that you must supply, because Exim will not build without them. They are the location of the runtime configuration file (CONFIGURE_FILE), the directory in which Exim binaries will be installed (BIN_DIRECTORY), and the identity of the Exim user (EXIM_USER and maybe EXIM_GROUP as well). The value of CONFIGURE_FILE can in fact be a colon-separated list of filenames; Exim uses the first of them that exists.
There are a few other parameters that can be specified either at build time or at runtime, to enable the same binary to be used on a number of different machines. However, if the locations of Exim’s spool directory and log file directory (if not within the spool directory) are fixed, it is recommended that you specify them in Local/Makefile instead of at runtime, so that errors detected early in Exim’s execution (such as a malformed configuration file) can be logged.
Exim’s interfaces for calling virus and spam scanning software directly from access control lists are not compiled by default. If you want to include these facilities, you need to set
WITH_CONTENT_SCAN=yes
in your Local/Makefile. For details of the facilities themselves
If you are going to build the Exim monitor, a similar configuration process is required. The file exim_monitor/EDITME must be edited appropriately for your installation and saved under the name Local/eximon.conf. If you are happy with the default settings described in exim_monitor/EDITME, Local/eximon.conf can be empty, but it must exist.
This is all the configuration that is needed in straightforward cases for known operating systems. However, the building process is set up so that it is easy to override options that are set by default or by operating-system-specific configuration files, for example, to change the C compiler, which defaults to gcc.
Features
Exim supports all the modern features that you can imagine from top open source mail transfer agent software. These are some of the main features of Exim:
- Exim follows the same general approach of decentralized control that Smail 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.
- Many configuration options can be given as expansion strings, which are transformed in various ways when they are used. 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. The ultimate flexibility can be obtained (at a price) by running a Perl interpreter while expanding a string.
- Access to view historical messages.
- Access to view the full outgoing & incoming message queue.
- Exim has flexible retry algorithms, applicable to directing and routing addresses 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 have been delayed.
- Exim can be configured to do local deliveries immediately but to leave remote (SMTP) 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.
- Remote deliveries of the same message to different hosts can optionally be done in parallel.
- Incoming SMTP messages start delivery as soon as they are received, without waiting for the SMTP call to close.
- Exim has support for the SMTP AUTH extension for authenticating clients, and for the STARTTLS extension for setting up encrypted connections.
- Perl-compatible regular expressions are available in a number of configuration parameters.
- Domain lists can include file lookups, making it possible to support very large numbers of local domains.
- Exim supports optional checking of incoming return path (sender) and receiver addresses as they are received by SMTP.
- SMTP calls from specific machines, optionally from specific idents, can be locked out, and incoming SMTP messages from specific senders can also be locked out. Exim also supports the use of the Realtime Blocking List (RBL).
- Hosts that are permitted to relay mail through a machine to another external domain can be controlled by IP number or IP network number. Relay control by recipient domain and sender address is also available.
- Messages on the queue can be
frozen' and
thawed’ by the administrator. - Exim can handle a number of independent local domains on the same machine; each domain can have its own alias files, etc. This facility is sometimes known as `virtual domains'.
- Simple mailing lists can be handled directly by Exim itself (but for `serious’ mailing list operations, it is best to use it in conjunction with specialist mailing list software).
- Exim stats a user’s home directory before looking for a `.forward’ file, in order to detect the case of a missing NFS mount. Delivery is delayed if the directory is unavailable.
- Exim contains an optional built-in mail filtering facility. This can be configured to allow users to provide personal filter files, and it is also possible for a system-wide filter file to be applied to every message.
- 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. The warnings can be made conditional on the contents of the message.
- 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. There is support for the ETRN command in SMTP to interface to this.
- Exim can be configured to run as root all the time, except when performing local deliveries, which it always does in a separate process under an appropriate uid and gid. Alternatively, it 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. See chapter 55 for a discussion of security issues.
- 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. Alternative wording for these messages can be provided in a separate file.
- 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. However, all such actions are also available from the command line interface.
Installation Instructions
Installing Exim binaries and scripts
The command make install runs the exim_install script with no arguments. The script copies binaries and utility scripts into the directory whose name is specified by the BIN_DIRECTORY setting in Local/Makefile. The install script copies files only if they are newer than the files they are going to replace. The Exim binary is required to be owned by root and have the setuid bit set, for normal configurations. Therefore, you must run make install as root so that it can set up the Exim binary in this way. However, in some special situations (for example, if a host is doing no local deliveries) it may be possible to run Exim without making the binary setuid root (see chapter 56 for details).
Exim’s runtime configuration file is named by the CONFIGURE_FILE setting in Local/Makefile. If this names a single file, and the file does not exist, the default configuration file src/configure.default is copied there by the installation script. If a runtime configuration file already exists, it is left alone. If CONFIGURE_FILE is a colon-separated list, naming several alternative files, no default is installed.
One change is made to the default configuration file when it is installed: the default configuration contains a router that references a system aliases file. The path to this file is set to the value specified by SYSTEM_ALIASES_FILE in Local/Makefile (/etc/aliases by default). If the system aliases file does not exist, the installation script creates it, and outputs a comment to the user.
The created file contains no aliases, but it does contain comments about the aliases a site should normally have. Mail aliases have traditionally been kept in /etc/aliases. However, some operating systems are now using /etc/mail/aliases. You should check if yours is one of these, and change Exim’s configuration if necessary.
The default configuration uses the local host’s name as the only local domain, and is set up to do local deliveries into the shared directory /var/mail, running as the local user. System aliases and .forward files in users’ home directories are supported, but no NIS or NIS+ support is configured. Domains other than the name of the local host are routed using the DNS, with delivery over SMTP.
It is possible to install Exim for special purposes (such as building a binary distribution) in a private part of the file system. You can do this by a command such as
make DESTDIR=/some/directory/ install
This has the effect of pre-pending the specified directory to all the file paths, except the name of the system aliases file that appears in the default configuration. (If a default alias file is created, its name is modified.) For backwards compatibility, ROOT is used if DESTDIR is not set, but this usage is deprecated.
Running make install does not copy the Exim 4 conversion script convert4r4. You will probably run this only once if you are upgrading from Exim 3. None of the documentation files in the doc directory are copied, except for the info files when you have set INFO_DIRECTORY, as described in section 4.17 below.
For the utility programs, old versions are renamed by adding the suffix .O to their names. The Exim binary itself, however, is handled differently. It is installed under a name that includes the version number and the compile number, for example, exim-4.94-1. The script then arranges for a symbolic link called exim to point to the binary. If you are updating a previous version of Exim, the script takes care to ensure that the name exim is never absent from the directory (as seen by other processes).
If you want to see what the make install will do before running it for real, you can pass the -n option to the installation script by this command:
make INSTALL_ARG=-n install
The contents of the variable INSTALL_ARG are passed to the installation script. You do not need to be root to run this test. Alternatively, you can run the installation script directly, but this must be from within the build directory. For example, from the top-level Exim directory you could use this command:
(cd build-SunOS5-5.5.1-sparc; ../scripts/exim_install -n)
There are two other options that can be supplied to the installation script.
- -no_chown bypasses the call to change the owner of the installed binary to root, and the call to make it a setuid binary.
- -no_symlink bypasses the setting up of the symbolic link exim to the installed binary.
INSTALL_ARG can be used to pass these options to the script. For example:
make INSTALL_ARG=-no_symlink install
The installation script can also be given arguments specifying which files are to be copied. For example, to install just the Exim binary, and nothing else, without creating the symbolic link, you could use:
make INSTALL_ARG='-no_symlink exim' install
Installing info documentation
Not all systems use the GNU info system for documentation, and for this reason, the Texinfo source of Exim’s documentation is not included in the main distribution. Instead it is available separately from the FTP site (see section 1.5).
If you have defined INFO_DIRECTORY in Local/Makefile and the Texinfo source of the documentation is found in the source tree, running make install automatically builds the info files and installs them.