Exim is distributed as a gzipped tar file which, when upacked, creates a directory with the name of the current release (for example, `exim-2.00') into which the following files are placed:
`LICENCE' the GNU General Public Licence `Makefile' top-level make file `NOTICE' conditions for the use of Exim `README' list of files, directories and simple build instructions
Other files whose names begin with `README' may also be present. The following subdirectories are created:
`OS' OS-specific files `doc' documentation files `exim_monitor' source files for the Exim monitor `scripts' scripts used in the build process `src' remaining source files `util' independent utilities
Some utilities are contained in the `src' directory, and are built with the Exim binary; those distributed in the `util' directory are things like the log file analyser, which do not depend on any compile-time configuration.
The building process for Exim is arranged to make it easy to build binaries for a number of different architectures and operating systems from the same set of source files. Compilation does not take place in the `src' directory. Instead, a build directory is created for each architecture and operating system. Symbolic links to the sources are installed in this directory, which is where the actual building takes place.
In most cases, Exim can discover the machine architecture and operating system for itself, but the defaults can be overridden if necessary.
Licensed versions of Unix normally contain a library of DBM functions operating via the `ndbm' interface, and this is what Exim expects by default. Free versions of Unix seem to vary in what they contain as standard. In particular, I understand that Linux has no default DBM library, and different distributors have chosen to bundle different libraries with their packaged versions.
Different DBM libraries have different conventions for naming the files they use. When a program opens a file called `dbmfile', there are four possibilities:
Exim and its utilities can be compiled to use any of these interfaces. By default it assumes an interface of type (1), though some operating system configuration files default to assuming (4). In order to use the Berkeley package in native mode, it is necessary to set USE_DB in an appropriate configuration file, and it may also be necessary to set DBMLIB, for example,
DBMLIB = -ldb
By avoiding the translation from one interface to another, some resources may be saved.
To complicate things further, there are now two very different versions of the Berkeley DB package. Version 1.85 has been stable for quite some time, but the latest versions are numbered 2.x. Release 2 is very different internally and externally from the 1.85 release. Both versions of Berkeley DB can be obtained from
http://www.bostic.com/db
but maintenance of version 1.85 is being phased out, and it may not compile on some systems. There is further discussion about the various DBM libraries in the file `doc/dbm.discuss.txt'.
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.
Default values are supplied for all of them except for those that specify the locations of the runtime configuration file and the directory for holding Exim binaries. These must be given, as Exim will not build without them. 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 run time so that errors detected early in Exim's execution (such as a malformed configuration file) can be logged.
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', then `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. See section "Overriding build-time options for Exim" below for details of how to do this.
Exim can be linked with the `tcpwrappers' library in order to check incoming SMTP calls using the `tcpwrappers' control files. This may be a convenient alternative to Exim's own checking facilities for installations that are already making use of `tcpwrappers' for other purposes. To do this, you should set USE_TCP_WRAPPERS in `Local/Makefile', and also ensure that the library is available at link time, typically be including it in EXTRALIBS.
Exim contains experimental code for use on systems that have IPv6 support. The file `README.IPV6' contains information on the current status of IPv6 in Exim. Setting HAVE_IPV6=YES in `Local/Makefile' causes the IPv6 code to be included; it may also be necessary to set IPV6_INCLUDE and IPV6_LIBS.
Once `Local/Makefile' (and `Local/eximon.conf', if required) have been created, run make at the top level. It determines the architecture and operating system types, and creates a build directory if one does not exist. For example, on a Sun system running Solaris 2.5.1, the directory `build-SunOS5-5.5.1-sparc' is created. Symbolic links to relevant source files are installed in the build directory.
If this is the first time make has been run, it calls a script which builds a make file inside the build directory, using the configuration files from the `Local' directory. The new make file is then passed to another instance of make which does the real work, building a number of utility scripts, and then compiling and linking the binaries for the Exim monitor (if configured), a number of utilities, and finally Exim itself. The command make makefile can be used to rebuild the make file in the build directory, should this ever be necessary.
On some operating systems there have been problems with this two-level running of make. A way of avoiding them is to run make makefile first and then run the main make. If you have other problems building Exim, check any comments there may be in the `README' file concerning your operating system.
The main make file that is created at the beginning of the building process consists of the concatenation of a number of files which set configuration values, followed by a fixed set of make instructions. If a value is set more than once, the last setting overrides any previous ones. This provides a convenient way of overriding defaults. The files that are concatenated are, in order:
OS/Makefile-Default OS/Makefile-<ostype> Local/Makefile Local/Makefile-<ostype> Local/Makefile-<archtype> Local/Makefile-<ostype>-<archtype> OS/Makefile-Base
where <ostype> is the operating system type and <archtype> is the architecture type. `Local/Makefile' is required to exist, and the building process fails if it is absent. The other three `Local' files are optional, and are often not needed.
The values used for <ostype> and <archtype> are obtained from scripts called `scripts/os-type' and `scripts/arch-type' respectively. If either of the environment variables OSTYPE or ARCHTYPE is set, their values are used, thereby providing a means of forcing particular settings. Otherwise, the scripts try various ad hoc methods of determining these values. You can run these scripts directly from the shell in order to find out what values are being used on your system.
`OS/Makefile-Default' contains comments about the variables that are set therein. Some (but not all) are mentioned below. If there is something that needs changing, review the contents of this file and the contents of the make file for your operating system (`OS/Makefile-<ostype>') to see what the default values are.
If you need to change any of the values that are set in `OS/Makefile-Default' or in `OS/Makefile-<ostype>', or to add any new definitions, do so by putting the new values in an appropriate `Local' file. For example, to specify that the C compiler is called `cc' rather than `gcc' when compiling in the OSF1 operating system, and that it is to be to be called with the flag `-std1', create a file called `Local/Makefile-OSF1' containing the lines
CC=cc CFLAGS=-std1
This makes it easy to transfer your configuration settings to new versions of Exim simply by copying the contents of the `Local' directory.
Exim contains support for doing LDAP, NIS, and NIS+ lookups, but not all systems have these components installed, so the default is not to include the relevant code in the binary. All the different kinds of file and database lookup that Exim supports are implemented as separate code modules which are included only if the relevant compile-time options are set. In the case of LDAP, NIS, and NIS+, the settings for `Local/Makefile' are:
LOOKUP_LDAP=yes LOOKUP_NIS=yes LOOKUP_NISPLUS=yes
In all cases the relevant include files and interface libraries need to be installed before compiling Exim. When a lookup type is not included in the binary, attempts to configure Exim to use it cause configuration errors.
Another optional lookup type is cdb, which is included in the binary only if
LOOKUP_CDB=yes
is set. In this case, the code is entirely contained within Exim, and no external include files or libraries are required.
The location of the X11 libraries is something that varies a lot between operating systems, and of course there are different versions of X11 to cope with. The following three variables are set in `OS/Makefile-Default':
X11=/usr/X11R5 XINCLUDE=-I$(X11)/include XLFLAGS=-L$(X11)/lib
These are overridden in some of the operating-system configuration files. For example, in `OS/Makefile-SunOS5' there is
X11=/usr/openwin XINCLUDE=-I$(X11)/include XLFLAGS=-L$(X11)/lib -R$(X11)/lib
If you need to override the default setting for your operating system, place a definition of all three of these variables into your `Local/Makefile-<ostype>' file.
If you need to add any extra libraries to the link steps, these can be put in a variable called EXTRALIBS, which appears in all the link commands, but by default is not defined. There is also DBMLIB, which appears in the link commands for binaries that use DBM functions (see also section "DBM libraries"). Finally, there is EXTRALIBS_EXIMON, which appears only in the link step for the Exim monitor binary, and which can be used, for example, to include additional X11 libraries.
Another variable which is not normally defined is STDERR_FILE. This defines a file to which debugging output is written if the `-df' flag is set, and is of use when running Exim under `inetd'.
Yet another variable which should not normally be needed is ERRNO_QUOTA. Exim needs to know which error the operating system gives when writing to a file fails because the user is over quota. POSIX specifies an error called EDQUOT and this is present in the latest versions of all the systems Exim has been ported to at the time of writing. However, it is not present in earlier versions of SunOS5, which use ENOSPC instead. The code of Exim defaults to using EDQUOT if it is defined, and ENOSPC otherwise. You should set ERRNO_QUOTA only if your system uses some completely different error code.
The make file copes with rebuilding Exim correctly if any of the configuration files are edited. However, if an optional configuration file is deleted, it is necessary to touch the associated non-optional file (that is, `Local/Makefile' or `Local/eximon.conf') before rebuilding.
The `OS' directory contains a number of files with names of the form `os.h-<ostype>'. These are system-specific C header files that should not normally need to be changed. There is a list of macro settings that are recognized in the file `OS/os.configuring', which should be consulted if you are porting Exim to a new operating system.
A similar process is used for overriding things when building the Exim monitor, where the files that are involved are
OS/eximon.conf-Default OS/eximon.conf-<ostype> Local/eximon.conf Local/eximon.conf-<ostype> Local/eximon.conf-<archtype> Local/eximon.conf-<ostype>-<archtype>
As with Exim itself, the final three files need not exist, and in this case the `OS/eximon.conf-<ostype>' file is also optional. The default values in `OS/eximon.conf-Default' can be overridden dynamically by setting environment variables of the same name, preceded by EXIMON_. For example, setting EXIMON_LOG_DEPTH in the environment overrides the value of LOG_DEPTH at run time.
The script `scripts/exim_install' copies binaries and utility scripts into the directory whose name is specified by the BIN_DIRECTORY setting in `Local/Makefile'. Files are copied only if they are newer than any versions already in the binary directory, and old versions are renamed by adding the suffix `.O' to their names.
The command "make install" runs the `exim_install' script with no arguments. It can be run independently with arguments specifying which files are to be copied, from within a build directory. For example,
(cd build-SunOS5-sparc; ../scripts/exim_install exim)
copies just the main binary file. The main `exim' binary is required to be owned by root and setuid. The script sets this up, and should therefore normally be run as root. If you want to see what the script will do before running it for real, use the `-n' option (for which root is not needed):
(cd build-SunOS5-sparc; ../scripts/exim_install -n)
Exim's runtime configuration file is named by the CONFIGURE_FILE setting in `Local/Makefile'. If this file does not exist, then 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.
When it starts up, Exim tries to create its spool directory if it does not exist. If a specific Exim uid and gid are specified, these are used for the owner and group of the spool directory. Sub-directories are automatically created in the spool directory as necessary.
Having installed Exim, you can check that the runtime configuration file is
syntactically valid by running the command
If there are any errors in the configuration file, Exim will output error
messages. Otherwise it just outputs the version number and build date. Some
simple routing tests can be done by using the address testing option. For
example,
should verify that it recognizes a local mailbox, and
a remote one. Then try getting it to deliver mail, both locally and remotely.
This can be done by passing messages directly to Exim, without going through a
user agent. For example:
If you encounter problems, look at Exim's log files (`mainlog' and `paniclog')
to see if there is any relevant information there. Another source of
information is running Exim with debugging turned on, by specifying the `-d'
option. The larger the number after `-d' (up to 9), the more information is
output. With `-d2', for example, the sequence of directors or routers that
process an address is output. If there's a message stuck on Exim's spool, you
can force a delivery with debugging turned on by a command of the form
One specific problem that has shown up on some sites is the inability to do
local deliveries into a single shared mailbox directory that does not have the
`sticky bit' set on it. By default, Exim tries to create a lock file before
writing to a mailbox file, and if it cannot create the lock file, the delivery
is deferred. You can get round this either by setting the `sticky bit' on the
directory, or by setting a specific group for local deliveries and allowing
that group to create files in the directory (see the comments above the
`local_delivery' transport in the default configuration file). Another
approach is to configure Exim not to use lock files, but just to rely on
`fcntl()' locking instead. However, you should do this only if all user agents
also use `fcntl()' locking. For further discussion of locking issues, see
chapter "The appendfile transport".
exim -bV
exim -v -bt <local username>
exim -v -bt <remote address>
exim postmaster@your.domain
From: user@your.domain
To: postmaster@your.domain
Subject: Testing Exim
This is a test message.
^D
exim -d9 -M <message-id>
One thing that cannot be tested on a system that is already running a mailer is the receipt of incoming SMTP mail on the standard SMTP port. However, the `-oX' option can be used to run an Exim daemon that listens on some other port, or `inetd' can be used to do this.
Testing a new version on a system that is already running Exim can most easily be done by building a binary with a different CONFIGURE_FILE setting. From within the runtime configuration, all other file and directory names that Exim uses can be altered, in order to keep it entirely clear of the production version.
For debugging purposes, code for a transport called `debug' is supplied, but is not by default included in the binary. It is recommended that this never be included as a matter of course, because it makes it possible to subvert mail deliveries. When this code is available, the `debug_transport' runtime configuration option can be set, and this suppresses normal mail delivery. Instead, information about each delivery is written to a file named by the `debug_transport' option. Further details are given in chapter "The debug transport".
Building and installing Exim does not of itself put it in general use. The name by which the system message transfer agent is called by mail user agents is `/usr/lib/sendmail', and it is necessary to make this name point to the `exim' binary in order to get them to use it. This is normally done by renaming any existing file and making `/usr/lib/sendmail' a symbolic link to the `exim' binary. It is then necessary to stop and restart the mailer daemon, if one is running.
The standard command for stopping the mailer daemon on Solaris 2 is
/etc/init.d/sendmail stop
If `/usr/lib/sendmail' has been turned into a symbolic link, this script fails to stop Exim because it uses the command `ps -e' and greps the output for the text `sendmail'; this is not present because the actual program name (that is, `exim') is given by the `ps' command with these options. A fix that appears to work on Solaris 2.5 and above is to change the script so that the `ps' command reads
ps -e -o pid,comm
which causes the name by which the daemon was started (that is, `/usr/lib/sendmail') to be output. However, this fails if the daemon has been restarted with SIGHUP because Exim restarts itself using the real file name. A better solution is to replace the line that finds the process id with something like
pid=`cat /var/spool/exim/exim-daemon.pid`
to obtain the daemon's pid directly from the file that Exim saves it in. See the description of the `-bd' option for details of where Exim writes the daemon's process id file.
Go to the first, previous, next, last section, table of contents.