UNIVERSITY OF CAMBRIDGE COMPUTING SERVICE SPECIFICATION OF THE EXIM MAIL TRANSFER AGENT by Philip Hazel University Computing Service New Museums Site Pembroke Street Cambridge CB2 3QG United Kingdom phone: +44 1223 334600 fax: +44 1223 334679 email: ph10@cus.cam.ac.uk Edition for Exim 3.30, June 2001 Copyright (c) University of Cambridge 2001 CONTENTS 1. Introduction 1.1 Web site and Mailing list 1.2 Availability 1.3 Limitations 1.4 Features 1.5 Support for IPv6 1.6 Calling interface 1.7 Terminology 2. Incorporated code 3. How Exim delivers mail 3.1 Philosophy 3.2 Message reception 3.3 Life of a message 3.4 Drivers 3.5 Delivery in detail 3.6 Temporary delivery failures 4. Building and installing Exim 4.1 Unpacking 4.2 Multiple machine architectures and operating systems 4.3 DBM libraries 4.4 Pre-building configuration 4.5 Including TLS/SSL encryption support 4.6 Use of tcpwrappers 4.7 Including support for IPv6 4.8 The building process 4.9 Overriding build-time options for Exim 4.10 OS-specific header files 4.11 Overriding build-time options for the monitor 4.12 Installing commands and scripts 4.13 Installing info documentation 4.14 Setting up the spool directory 4.15 Testing 4.16 Switching Exim on 4.17 Exim on heavily loaded hosts 4.18 Stopping Exim on Solaris 5. The Exim command line 5.1 Setting options by program name 5.2 Trusted and admin users 5.3 Command line options 6. File and database lookups 6.1 Single-key lookup types 6.2 An lsearch file is not an item list 6.3 Query-style lookup types 6.4 Use of data lookups 6.5 Temporary errors in lookups 6.6 Default values in single-key lookups 6.7 Partial matching in single-key lookups 6.8 Lookup caching 6.9 Quoting lookup data 6.10 More about NIS+ 6.11 More about LDAP 6.12 More about MySQL and PostgreSQL 6.13 More about dnsdb 7. The Exim configuration file 7.1 Configuration file format 7.2 Macros in the configuration file 7.3 Common option syntax 7.4 Integer 7.5 Octal integer 7.6 Fixed point number 7.7 Time interval 7.8 String 7.9 Expanded strings 7.10 User and group names 7.11 List construction 7.12 Domain lists 7.13 Host lists 7.14 Mixing host names and addresses in host lists 7.15 Use of RFC 1413 identification in host lists 7.16 Address lists 7.17 Case of letters in address lists 8. Regular expressions 8.1 Testing regular expressions 9. String expansions 9.1 Testing string expansions 9.2 Expansion items 9.3 Expansion operators 9.4 Expansion conditions 9.5 Expansion variables 10. Embedded Perl 11. Main configuration 12. Driver specifications 13. Environment for running local transports 13.1 Uids and gids 13.2 Current and home directories 13.3 Expansion variables derived from the address 14. Generic options for transports 15. The appendfile transport 15.1 Private options for appendfile 15.2 Operational details for appending 15.3 Operational details for delivery to a new file 16. The autoreply transport 16.1 Private options for autoreply 17. The lmtp transport 18. The pipe transport 18.1 Returned status and data 18.2 How the command is run 18.3 Environment variables 18.4 Private options for pipe 18.5 Using an external local delivery agent 19. The smtp transport 20. Generic options common to both directors and routers 20.1 Skipping directors and routers 21. Additional generic options for directors 21.1 Skipping directors 22. Options common to the aliasfile and forwardfile directors 23. The aliasfile director 23.1 Specifying a transport for aliasfile 23.2 Alias file format 23.3 Types of alias item 23.4 Duplicate addresses 23.5 Repeated alias expansion 23.6 Errors in alias files 23.7 Aliasfile private options 24. The forwardfile director 24.1 Forward file items 24.2 Repeated forwarding expansion 24.3 Errors in forward files 24.4 Filter files 24.5 The home directory 24.6 Special treatment of home_directory and current_directory 24.7 Forwardfile private options 25. The localuser director 26. The smartuser director 27. Additional generic options for routers 28. The domainlist router 28.1 Routing rules 28.2 Host list format 28.3 Options format 28.4 Application of routing rules 28.5 Domainlist examples 29. The ipliteral router 30. The iplookup router 31. The lookuphost router 32. The queryprogram router 33. Retry configuration 33.1 Retry rules 33.2 Retry rule examples 33.3 Timeout of retry data 33.4 Long-term failures 33.5 Ultimate address timeout 34. Address rewriting 34.1 Testing the rewriting rules that apply on input 34.2 Rewriting rules 34.3 Rewriting patterns 34.4 Rewriting replacements 34.5 Rewriting flags 34.6 Flags specifying which headers and envelope addresses to rewrite 34.7 The SMTP-time rewriting flag 34.8 Flags controlling the rewriting process 34.9 The additional relay checking flag 34.10 Rewriting examples 35. SMTP authentication 35.1 Generic options for authenticators 35.2 Authentication on an Exim server 35.3 Testing server authentication 35.4 Authenticated senders 35.5 Authentication by an Exim client 36. The plaintext authenticator 36.1 Using plaintext in a server 36.2 Using plaintext in a client 37. The cram_md5 authenticator 37.1 Using cram_md5 as a server 37.2 Using cram_md5 as a client 38. Encrypted SMTP connections using TLS/SSL 38.1 Configuring Exim to use TLS as a server 38.2 Configuring Exim to use TLS as a client 38.3 Multiple messages on the same TCP/IP connection 38.4 Certificates and all that 39. Customizing error and warning messages 39.1 Customizing error messages 39.2 Customizing warning messages 40. The default configuration file 40.1 Main configuration settings 40.2 Transport configuration settings 40.3 Director configuration settings 40.4 Router configuration settings 40.5 Default retry rule 40.6 Rewriting configuration 40.7 Authenticators configuration 41. Multiple user mailboxes 42. Using Exim to handle mailing lists 42.1 Syntax errors in mailing lists 42.2 NFS-mounted mailing lists 42.3 Re-expansion of mailing lists 42.4 Closed mailing lists 43. Virtual domains 43.1 All mail to a given host 43.2 Virtual domains not preserving envelopes 43.3 Virtual domains preserving envelopes 44. Intermittently connected hosts 44.1 Exim on the upstream host 44.2 Exim on the intermittently connected host 44.3 Handling many intermittently connected hosts 45. Verification of incoming mail 45.1 Host verification 45.2 Sender verification 45.3 Sender verification with callback 45.4 Fixing bad senders 45.5 Header verification 45.6 Receiver verification 46. Other policy controls on incoming mail 46.1 Host checking using RBL 46.2 Other host checking 46.3 Sender checking 46.4 Control of relaying 46.5 Customizing prohibition messages 47. System-wide message filtering 47.1 The system message filter 47.2 Additional commands for system filters 47.3 Per-address filtering 48. SMTP processing 48.1 Outgoing SMTP over TCP/IP 48.2 Errors in outgoing SMTP 48.3 Variable Envelope Return Paths (VERP) 48.4 Incoming SMTP messages over TCP/IP 48.5 The VRFY, EXPN, and DEBUG commands 48.6 The ETRN command 48.7 Incoming local SMTP 48.8 Outgoing batched SMTP 48.9 Incoming batched SMTP 49. Message processing 49.1 Unqualified addresses 49.2 The UUCP From line 49.3 The Bcc: header 49.4 The Date: header 49.5 The Delivery-date: header 49.6 The Envelope-to: header 49.7 The From: header 49.8 The Message-id: header 49.9 The Received: header 49.10 The Return-path: header 49.11 The Sender: header 49.12 The To: header 49.13 Adding and removing headers 49.14 Constructed addresses 49.15 Case of local parts 49.16 Dots in local parts 49.17 Rewriting addresses 50. Automatic mail processing 50.1 System-wide automatic processing 50.2 Taking copies of mail 50.3 Automatic processing by users 50.4 Simplified vacation processing 51. Log files 51.1 Logging to local files 51.2 Logging to syslog 51.3 Logging message reception 51.4 Logging deliveries 51.5 Deferred deliveries 51.6 Delivery failures 51.7 Fake deliveries 51.8 Completion 51.9 Other log entries 51.10 Log level 51.11 Message log 52. Day-to-day management 52.1 The panic log 52.2 The reject log 52.3 Log cycling 52.4 Statistics 52.5 What is Exim doing? 52.6 Changing the configuration 52.7 Watching the queue 52.8 Holding domains 53. Exim utilities 53.1 Querying Exim processes 53.2 Summarising the queue 53.3 Extracting log information 53.4 Cycling log files 53.5 Making DBM files 53.6 Individual retry times 53.7 Database maintenance 53.8 Mail statistics 53.9 Mailbox maintenance 54. The Exim monitor 54.1 Running the monitor 54.2 The stripcharts 54.3 Main action buttons 54.4 The log display 54.5 The queue display 54.6 The queue menu 55. Security considerations 55.1 Root privilege 55.2 Running Exim without privilege 55.3 Alternate configurations and macros 55.4 Reading forward files 55.5 Delivering to local files 55.6 IPv4 source routing 55.7 The VRFY, EXPN, and ETRN commands in SMTP 55.8 Privileged users 55.9 Spool files 55.10 Use of argv[0] 55.11 Use of %f formatting 55.12 Embedded Exim path 55.13 Use of sprintf() 55.14 Use of debug_printf() and log_write() 55.15 Use of strcat() and strcpy() 56. Format of spool files 57. Adding new drivers or lookup types 1. INTRODUCTION "If I have seen further it is by standing on the shoulders of giants." (Isaac Newton) Exim is a mail transfer agent (MTA) for Unix systems connected to the Internet. Configuration files currently exist for the following operating systems: AIX, BSDI, Darwin (Mac OS X), DGUX, FreeBSD, GNU/Hurd, GNU/Linux, HI- | OSF (Hitachi), HP-UX, IRIX, MIPS RISCOS, NetBSD, OpenBSD, QNX, SCO, SCO SVR4.2 (aka UNIX-SV), Solaris (aka SunOS5), SunOS4, Tru64-Unix (formerly Digital UNIX, formerly DEC-OSF1), Ultrix, and Unixware. However, code is not available for determining system load averages under Ultrix. The terms and conditions for the use and distribution of Exim are contained in the file NOTICE. Exim is distributed under the terms of the GNU General Public Licence, a copy of which may be found in the file LICENCE. The use, supply or promotion of Exim for the purpose of sending bulk, unsolicited electronic mail is incompatible with the basic aims of the program, which revolve around the free provision of a service that enhances the quality of personal communications. The author of Exim regards indiscrimi- nate mass-mailing as an antisocial, irresponsible abuse of the Internet. 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 user interfaces were originally taken from Smail 3, though the actual code of Exim | is entirely new, and has developed far beyond the initial concept. | Many people, both in Cambridge and around the world, have contributed to the development and the testing of Exim, and to porting it to various operating systems. I am grateful to them all. This document is very much a reference manual; it is not a tutorial. Although there are some discussions and examples in places, the information is mostly organized in a way that makes it easy to look up, rather than in a natural order for sequential reading. Furthermore, the manual aims to cover every aspect of Exim in detail, including a number of rarely-used, special-purpose features that are unlikely to be of very wide interest. An 'easier' discussion of Exim which provides more in-depth explanatory, | introductory, and tutorial material can be found in my book Exim The Mail | Transport Agent, published by O'Reilly (ISBN 0-596-00098-7). Inevitably, | however, the book is unlikely to be fully up-to-date with the latest release. | This specification is the definitive reference. | This edition of the Exim specification applies to version 3.30 of Exim. Substantive changes from the 3.20 edition are marked by bars in the right-hand margin in the PostScript, PDF, and plain text versions of the document. Changes are not marked in the Texinfo version, because Texinfo doesn't support change bars. In the HTML version, a different colour is used. Minor correc- tions and rewordings are not marked. As the program is still developing, there may be features in later versions of the program that have not yet made it into this document, which is updated only when the most significant digit of the fractional part of the version number changes. However, all changes are noted briefly in the file called doc/ChangeLog, and specifications of new features that are not yet in this manual are placed in doc/NewStuff. Complete lists of options are maintained in doc/OptionsLists.txt. All these files can be found within the Exim source | distribution. | 1.1 Web site and Mailing list There is a web site at http://www.exim.org by courtesy of Energis Squared, | formerly Planet Online Ltd, who are situated in the UK. The site is mirrored | in the USA and a number of of other countries; links to the mirrors are listed on the home page. Energis also provide resources for the following mailing | lists: | exim-users@exim.org general discussion list exim-announce@exim.org moderated, low volume announcements list pop-imap@exim.org discussion of POP/IMAP issues You can subscribe to these lists, change your existing subscription, and view or search the archives via the 'mailing lists' link on the Exim home page. By courtesy of Martin Hamilton, there is also an archive of the exim-users list in plain text form at http://www.roads.lut.ac.uk/lists/exim-users/exim- users.archive and in HTML via Hypermail at http://www.roads.lut.ac.uk/lists/exim-users/. The list is also forwarded to http://www.egroups.com/list/exim-users, which is another archiving system with searching capabilities. 1.2 Availability The master ftp site for the Exim distribution is ftp://ftp.csx.cam.ac.uk/pub/software/email/exim Those mirror sites that I know about are listed in the file ftp://ftp.csx.cam.ac.uk/pub/software/email/exim/Mirrors The current release of Exim is always to be found in files called exim-n.nn.tar.gz and exim-n.nn.tar.bz2 where n.nn is the highest such version number in the directory. The two files contain identical data; the only difference is the type of compression. The .bz2 file is usually a lot smaller than the .gz file. When there is only a small amount of change from one version to the next, a patch file may be provided, with a final component name of the form exim-patch-n.nn-m.mm.gz For each released version, the log of changes is made separately available in the directory ftp://ftp.csx.cam.ac.uk/pub/software/email/exim/ChangeLogs so that it is possible to find out what has changed without having to download the entire distribution. The main distribution contains ASCII versions of this specification and other documentation; other formats of the documents are available in separate files: exim-html-n.nn.tar.gz exim-pdf-n.nn.tar.gz exim-postscript-n.nn.tar.gz exim-texinfo-n.nn.tar.gz These tar files contain only the /doc directory, not the complete distri- bution, and are also available in .bz2 as well as .gz forms. An FAQ is available in two different formats from ftp://ftp.csx.cam.ac.uk/pub/software/email/exim/FAQ.txt.gz ftp://ftp.csx.cam.ac.uk/pub/software/email/exim/FAQ.html.gz The FAQ and other HTML documentation is also available online at the web site and its mirrors. At the ftp site, there is a directory called ftp://ftp.csx.cam.ac.uk/pub/software/email/exim/Contrib/ which contains miscellaneous files contributed to the Exim community by Exim users, and there is also a collection of contributed configuration examples in ftp://ftp.csx.cam.ac.uk/pub/software/email/exim/config.samples.tar.gz 1.3 Limitations . 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 fourteen 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 straightfor- ward rewriting configuration. This restriction does not prevent Exim from being interfaced to UUCP, provided domain addresses are used. . 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. These are then qualified on arrival. . The only external transport currently implemented is an SMTP transport over a TCP/IP network (using sockets, including support for IPv6). However, a pipe transport is available, and there are facilities for writing messages to files and pipes, optionally in "batched SMTP" format; these facilities can be used to send messages to some other transport mechanism such as UUCP, provided it can handle domain-style addresses. Batched SMTP input is also catered for. . Exim is not designed for storing mail for dial-in hosts. When the volumes of such mail are large, it is better to get the messages 'delivered' into files (that is, off Exim's queue) and subsequently passed on to the dial- in hosts by other means. . It used not to be easy to set up Exim to rewrite addresses only in some copies of a message and not others, for example, to retain locally- meaningful addresses locally, but rewrite them for any copies of messages that are sent off-site. From release 3.20, doing this has been made a lot simpler by adding a facility for rewriting at transport time. 1.4 Features 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. . 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 con- figuration 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 Blackhole 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. 1.5 Support for IPv6 IPv6 is the next generation of IP protocol which will in time replace IPv4; it is currently in an experimental state. A number of vendors have already released IPv6 versions of their systems and networking libraries. If Exim is built with HAVE_IPV6 set, it uses the IPv6 API for TCP/IP input and output. IP addresses can be given in IPv6 as well as IPv4 notation; incoming IPv4 calls use the embedded IPv6 address notation. In the DNS, two new record types, A6 and AAAA, are used for finding IPv6 addresses. A6 records are supposed, in time, to supersede AAAA records. At present, to be on the safe side, when trying to find host addresses from the DNS, Exim looks for all three record types: A6, AAAA, and A, in that order, and builds a combined list of addresses found (dropping any duplicates). In future this may change (for example, to stop once one kind of address has been found). 1.6 Calling interface Like many MTAs, Exim has adopted the Sendmail interface so that it can be a straight replacement for /usr/lib/sendmail or /usr/sbin/sendmail when sending | mail. Other compatible options also exist, but those that produce output (for | example, -bp, which lists the messages on the queue) do so in Exim's own | format. All the relevant Sendmail options are implemented, with two reser- | vations. There are also some additional options that are compatible with Smail 3, and some further options that are new to Exim. The -t option, for taking a list of recipients from a message's headers, is documented (for several versions of Sendmail) as suppressing delivery to any addresses on the command line (see 'man' pages on a number of operating systems). However, it appears that this is not the case in practice. For this reason, Exim has an option called "extract_addresses_remove_arguments" which controls its behaviour in this regard. Sendmail uses the -bi option as a request to rebuild the alias file. As Exim does not have the concept of a single alias file, it cannot mimic this behaviour. It can be configured to run a particular script when this option is received; otherwise the option is ignored. The run time configuration is held in a single text 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. A default configuration file which is suitable for simple installations is provided in the distribution. 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 a menu interface to Exim's command line administration options. 1.7 Terminology The term "local part", which is taken from RFC 822, is used to refer to that part of an email address that precedes the @ sign. The part that follows the @ sign is called the "domain" or "mail domain". The word "domain" is sometimes used to mean all but the first component of a machine's name. It is not used in that sense here, where it normally refers to the part of an email address following the @ sign. "Local domains" are mail domains for which the current host is responsible for handling the entire address; in other words, it has special knowledge of what to do with messages sent to such domains, and normally that means using the local part of the address either to deliver the message on the local host or to transform the address using an alias file or something similar. All other domains are "remote domains", which normally cause the message to be transmit- ted to some other host. The distinction between local and remote domains is not always entirely clear- cut, since a host can have special knowledge about routing for remote domains, and messages for local domains may under some circumstances be passed to other hosts. The terms "local delivery" and "remote delivery" are used to distinguish delivery to a file or a pipe on the local machine from delivery by SMTP to some remote machine. The type of delivery does not necessarily correspond to the type of address. Mail for a local domain may get passed on to some other host, while mail for a remote domain might get delivered locally to a file or pipe for onward transmission by some other means. However, these are special cases. The term "default" appears frequently in this manual. It is used to qualify a value which is used in the absence of any setting in the configuration. It may also qualify an action which is taken unless a configuration setting specifies otherwise. The term "defer" is used when the delivery of a message to a specific destination cannot immediately take place for some reason (a remote host may be down, or a user's local mailbox may be full). Such deliveries are "deferred" until a later time. The term "mailmaster" is used to refer to the person in charge of maintaining the mail software on a given computer. Commonly this will be the same person who fulfils the postmaster role, but this may not always be the case. The term "queue" is used to refer to the set of messages awaiting delivery, because this term is in widespread use in the context of MTAs. However, in Exim's case the reality is more like a pool than a queue, because there is normally no ordering of waiting messages. The term "queue-runner" is used to describe a process that scans the queue and attempts to deliver those messages whose retry times have come. This term is used by other MTAs, and also relates to the command "runq", but in Exim the waiting messages are normally processed in an unpredictable order. 2. INCORPORATED CODE A number of pieces of external code are included in the Exim distribution. . Regular expressions are supported in the main Exim program and in the Exim monitor using the freely-distributable PCRE library, copyright (c) 2000 University of Cambridge. The source is distributed in the directory src/pcre. . RFC 1413 callbacks are supported in the main Exim program using the "libident" library made freely available by Peter Eriksson at ftp://ftp.lysator.liu.se. Some modifications have been made in order to support IPv6. The source is distributed in the directory called src/libident. . Support for the cdb (Constant DataBase) lookup method is provided by code contributed by Nigel Metheringham of Planet Online Ltd. which contains the following statements: _________________________________________________________________________ Copyright (c) 1998 Nigel Metheringham, Planet Online Ltd This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This code implements Dan Bernstein's Constant DataBase (cdb) spec. Information, the spec and sample code for cdb can be obtained from http://www.pobox.com/~djb/cdb.html. This implementation borrows some code from Dan Bernstein's implementation (which has no license restrictions applied to it). _________________________________________________________________________ The implementation is completely contained within the code of Exim. It does not link against an external cdb library. . The Exim Monitor program, which is an X-Window application, includes modified versions of the Athena StripChart and TextPop widgets. This code is copyright by DEC and MIT, and their permission notice appears below, in accordance with the conditions expressed therein. ______________________________________________________________________________ Copyright 1987, 1988 by Digital Equipment Corporation, Maynard, Massachusetts, and the Massachusetts Institute of Technology, Cambridge, Massachusetts. All Rights Reserved Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the names of Digital or MIT not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. DIGITAL DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL DIGITAL BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. ______________________________________________________________________________ 3. HOW EXIM DELIVERS MAIL 3.1 Philosophy Exim is designed to work efficiently on systems that are permanently connected to the Internet and are handling a general mix of mail. In such circumstances, most messages can be delivered immediately. Consequently, Exim does not maintain independent queues of messages for specific domains or hosts, though it does try to send several messages in a single SMTP connection after a host has been down, and it also maintains per-host retry information. 3.2 Message reception 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 envelope information consists of the address of the message's sender and the address(es) of the recipient(s). This information is entirely separate from any addresses contained in the headers. The status of the message includes a list of recipients who have already received the message. The format of the first spool file is described in chapter 56. Address rewriting that is specified in the rewrite section of the configur- ation (see chapter 34) is done once and for all on incoming addresses, both in the header and the envelope, at the time the message is received. If during the course of delivery additional addresses are generated (for example, via aliasing), these new addresses get rewritten as soon as they are generated. At the time a message is actually delivered (transported) further rewriting can take place; because this is a transport option, it can be different for different forms of delivery. It is also possible to specify the addition or removal of certain headers at the time the message is delivered (see chapters 14 and 20). Every message handled by Exim is given a "message id" which is sixteen characters long. It is divided into three parts, separated by hyphens. Each part is a sequence of letters and digits, representing a number in base 62: . The first six characters are the time the message was received, as a number in seconds - the normal Unix way of representing a time of day. If the clock goes backwards (due to resetting) in a process that is receiving more than one message, the later time is retained. . After the first hyphen, the next six characters are the id of the process that received the message. . The final two characters, after the second hyphen, are used to ensure uniqueness of the id. There are two different formats: (a) If the "localhost_number" option is not set, uniqueness is required only within the local host. This portion of the id is '00' except when a process receives more than one message in a single second, when the number is incremented for each additional message. (b) If the "localhost_number" option is set, uniqueness among a set of hosts is required. This portion of the id is set to the base 62 encoding of * 256 + where is the count of messages received by the current process within the current second. As the maximum value of the host number is 255, this allows for a maximum value of 14 for the sequence number. If this limit is reached, a delay of one second is imposed before reading the next message, in order to allow the clock to tick and the sequence number to get reset. The names of the two spool files consist of the message id, followed by -H for the file containing the envelope and headers, and -D for the data file. By default all these spool files are held in a single directory called input inside the general Exim spool directory. Some operating systems do not perform very well if the number of files in a directory gets very large; to improve performance in such cases, the "split_spool_directory" option can be used. This causes Exim to split up the input files into 62 sub-directories whose names are single letters or digits. Exim can be configured not to start a delivery process when a message is received; this can be unconditional, or depend on the number of incoming SMTP connections or the system load. In these situations, new messages wait on the queue until a queue-runner process picks them up. However, in standard configurations under normal conditions, delivery is started as soon as a message is received. 3.3 Life of a message 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. An administrator can 'thaw' such messages when the problem has been corrected, and can also freeze individual messages by hand if necessary. In addition, an administrator can force a delivery error, causing an error message to be sent. There is also an "auto_thaw" option, which can be used to cause Exim to retry frozen messages after a certain time. When this is set, no message will remain on the queue for ever, because the delivery timeout will eventually be reached. Delivery failure reports that reach this timeout are discarded. When an Exim process starts to deliver a message, it takes out a lock on the | -D file, to prevent any other Exim process from working on it. 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, and is normally deleted with the spool files when processing of a message is complete. However, Exim can be configured to retain it (a dangerous option, as the files can accumulate rapidly on a busy system). Exim also writes delivery messages to its main log file, whose contents are described in chapter 51. All the information Exim itself needs to set up a delivery is kept in the first spool file with the headers. When a successful delivery occurs, the address is immediately written at the end of a journal file, whose name is the message id followed by -J. At the end of a delivery run, if there are some addresses left to be tried again later, the first spool file (the -H file) is updated to indicate which these are, and the journal file is then deleted. Updating the spool file is done by writing a new file and renaming it, to minimize the possibility of data loss. Should the system or the program crash after a successful delivery but before the spool file has been updated, the journal is left lying around. The next time Exim attempts to deliver the message, it reads the journal file and updates the spool file before proceeding. This minimizes the chances of double deliveries caused by crashes. 3.4 Drivers The main delivery processing elements of Exim are called directors, routers, and transports, and collectively these are known as drivers. Code for a number of them is provided, compile-time options specify which ones are included in the binary, and run time options specify which ones are actually used. A transport is a driver that transmits a copy of the message from Exim's spool to some destination. There are two kinds of transport: for a local transport, the destination is a file or a pipe on the local host, whereas for a remote transport the destination is some other host. A message is passed to a specific transport as a result of successful directing or routing. If a message has several recipients, it may be passed to a number of different transports. A director is a driver that operates on a local address, either determining how its delivery should happen, or converting the address into one or more new addresses (for example, via an alias file). A local address is one whose domain matches an entry in the list given in the "local_domains" option, or has been determined to be local by a router - see below. The fact that an address is local does not imply that the message has to be delivered locally; it can be directed either to a local or to a remote transport. A router is a driver that operates on an apparently remote address, that is an address whose domain does not match anything in the list given in "local_domains". When a router succeeds it can route an address either to a local or to a remote transport, or it can change the domain, and pass the address on to subsequent routers. In exceptional cases, a router may determine that an address is local after all, and cause it to be passed to the directors. This happens automatically if a host lookup expands an abbreviated domain into one that is local. It can also be made to happen (optionally) if an MX record or other routing information points to the local host, though by default this situation is treated as a configuration error. This is the only case in which the directors are used to process an address that may not match anything in "local_domains". The diagram below illustrates the relationship between the three kinds of driver. address | |<---------- new address -------- V | ----------------- | | matches | | ------- no ----| local_domains |--- yes ------- | | | option? | | | V ----------------- V | ----------- ------------ | | routers |--- local after all ------------->| directors |--- ----------- ------------- | ------------- | ---------------->| transport |<---------------- | queues | ------------- As new features have been added to Exim, the distinction between routers and directors has become less clear-cut than it once was. It is possible that in some future release the difference will be abolished and they will be merged into one type of driver. However, at present, they remain distinct. 3.5 Delivery in detail When a message is to be delivered, the sequence of events is roughly as follows: . If a system-wide filter file is specified, the message is passed to it. The filter may add recipients to the message, replace the recipients, discard the message, cause a new message to be generated, or cause the message delivery to fail. The format of the filter file is the same as for user filter files, described in the separate document entitled "Exim's interface to mail filtering". Some additional features are available in system filters - see chapter 47 for details. Note that a message is passed to the system filter only once per delivery attempt, however many recipients it has. However, if there are several delivery attempts because one or more addresses could not be immediately delivered, the system filter is run each time. The filter condition "first_delivery" can be used to detect this. . Each recipient address is parsed and a check is made to see if it is local, by comparing the domain with the list in the "local_domains" option. This can contain wildcards and file lookups. . If an address is local, it is offered to each configured director in turn until one is able to handle it. When a director cannot handle an address, it is said to "decline". If no directors can handle the address, that is, if they all decline, the address is failed. Directors can be targeted at particular local domains, so several local domains can be processed entirely independently of each other. . A director that accepts an address may set up a local or a remote transport for it. The transport is not run at this time; the address is placed on a queue for the particular transport, to be run later. Alternatively, the director may generate one or more new addresses (typically from alias, forward, or filter files). New addresses are fed back into this process from the top, but in order to avoid loops, a director ignores any address which has an identically-named ancestor that was processed by itself. . If an address is not local, it is offered to each configured router in turn, until one is able to handle it. If none can, the address is failed. . A router that accepts an address may set up a transport for it, or may pass an altered address to subsequent routers, or it may discover that the address is a local address after all. This typically happens when a partial domain name is used and (for example) the DNS lookup is configured to try to extend such names. In this case, the address is passed to the directors. Exim can also be configured to do this for any domain whose lowest MX record or other routing information points to the local host. . Routers normally set up remote transports for messages that are to be delivered to other machines. However, a router can pass a message to a local transport, and by this means such messages can be routed to transport mechanisms other than SMTP by means of pipes or files. . When all the directing and routing is done, addresses that have been successfully handled are passed to their assigned transports. When local transports are doing real local deliveries, they handle only one address at a time, but if a local transport is being used as a pseudo-remote transport (for example, to collect batched SMTP messages for transmission by some other means) multiple addresses can be handled. Remote transports can always handle more than one address at once, but can be configured not to do so, or to restrict multiple addresses to the same domain. . Each local delivery runs in a separate process under a non-privileged uid, and they are run in sequence. Exim can be configured so that remote deliveries run under a uid that is private to Exim, instead of running as root. By default the remote deliveries run one at a time in the main Exim process, but a configuration option is available to allow multiple remote deliveries for a single message to be run simultaneously, each in its own sub-process. . When it is doing a queue run, Exim checks its retry database to see if there has been a previous temporary delivery failure for the address before running any local transport. If it finds one, it does not attempt a new delivery until the retry time for the address is reached. However, this happens only for delivery attempts that are part of a queue run. Local deliveries are always attempted when delivery immediately follows message reception. . Remote transports do their own retry handling, since an address may be deliverable to one of a number of hosts, each of which may have a different retry time. If there have been previous temporary failures and no host has reached its retry time, no delivery is attempted, whether in a queue run or not. See chapter 33 for details of retry strategies. . If there were any errors, a message is returned to an appropriate address (the sender in the common case), with details of the error for each failing address. Exim can be configured to send copies of error messages to other addresses. . If one or more addresses suffered a temporary failure, the message is left on the queue, to be tried again later. Otherwise the spool files and message log are deleted, though the message log can optionally be preserved if required. Delivery is said to be "deferred" when the message remains on the queue for a subsequent delivery attempt after a temporary failure. Such messages get processed again by queue-runner processes that are periodically started, either by an Exim daemon or via "cron" or by hand. Temporary failures may be detected during routing and directing as well as during the transport stage. Exim uses a set of configured rules to determine when next to retry the failing address (see chapter 33). These rules also specify when Exim should give up trying to deliver to the address, at which point it generates a failure report. When a delivery is not part of a queue run (typically an immediate delivery on receipt of a message), the directors are always run for local addresses, and local deliveries are always attempted, even if retry times are set for them. This makes for better behaviour if one particular message is causing problems (for example, causing quota overflow, or provoking an error in a filter file). If such a delivery suffers a temporary failure, the retry data gets updated as usual, for use by the next queue-runner process. When a message cannot be delivered to some or all of its intended recipients, a delivery failure report is generated. All the addresses that failed in a given delivery attempt are listed in a single failure report. If a message has many recipients, it is possible for some addresses to fail in one delivery attempt and others to fail subsequently, giving rise to more than one failure report for a single message. The wording of delivery failure reports can be customized by the administrator. See chapter 39 for details. Delivery failure messages contain an "X-Failed-Recipients:" header, listing all failed addresses, for the benefit of programs that try to analyse such messages automatically. A failure report is normally sent to the sender of the original message, as obtained from the message's envelope. For incoming SMTP messages, this is the address given in the MAIL command. However, when an address is expanded via a forward or alias file, an alternative address can be specified for delivery failures of the generated addresses. For a mailing list expansion (see chapter 42) it is common to direct failure reports to the manager of the list. If a failure report (either locally generated or received from a remote host) itself suffers a delivery failure, the message is left on the queue, but is 'frozen', awaiting the attention of an administrator. There are options which can be used to make Exim discard such failure reports, or to keep them for only a short time. 3.6 Temporary delivery failures There are many reasons why a message may not be immediately deliverable to a particular address. Failure to connect to a remote machine (because it, or the connection to it, is down) is one of the most common. Local deliveries may also be delayed if NFS files are unavailable, or if a mailbox is on a file system where the user is over quota. Exim can be configured to impose its own quotas on local mailboxes; where system quotas are set they will also apply. A machine that is connected to the Internet can normally deliver most mail straight away (the usual figure at Cambridge University is 98%). In its default configuration, Exim starts a delivery process whenever it receives a message, and usually this completes the entire delivery. This is a lightweight approach, avoiding the need for any centralized queue managing software. There are those who argue that a central message manager would be able to batch up messages for the same host and send them in a single SMTP call. I do not myself believe this would occur much in general, unless messages were significantly delayed in order to create a batch. However, if a host is unreachable for a period of time, a number of messages may be waiting for it by the time it recovers, and sending them in a single SMTP connection is clearly beneficial. Whenever a delivery to a remote host is deferred, Exim makes a note in its hints database, and whenever a successful SMTP delivery has happened, it looks to see if any other messages are waiting for the same host. If any are found, they are sent over the same SMTP connection, subject to a configuration limit as to the maximum number in any one connection. 4. BUILDING AND INSTALLING EXIM 4.1 Unpacking Exim is distributed as a gzipped or bzipped tar file which, when upacked, creates a directory with the name of the current release (for example, exim-3.30) into which the following files are placed: CHANGES contains a reference to where changes are documented 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. 4.2 Multiple machine architectures and operating systems 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. 4.3 DBM libraries 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, some versions of Linux have no default DBM library, and different distributors have chosen to bundle different libraries with their packaged versions. However, the more recent releases seem to have standardised on the Berkeley DB library. Different DBM libraries have different conventions for naming the files they use. When a program opens a file called dbmfile, there are four possibilities: (1) A traditional ndbm implementation, such as that supplied as part of Solaris 2, operates on two files called dbmfile.dir and dbmfile.pag. (2) The GNU library, "gdbm", operates on a single file, but makes two different hard links to it with names dbmfile.dir and dbmfile.pag. (3) The Berkeley DB package, if called via its ndbm compatibility interface, operates on a single file called dbmfile.db, but otherwise looks to the programmer exactly the same as the traditional ndbm implementation. (4) If the Berkeley package is used in its native mode, it operates on a single file called dbmfile; the programmer's interface is somewhat different to the traditional ndbm interface. (5) Yet another DBM library, called tdb, has become available from http://download.sourceforge.net/tdb It has its own interface, and also operates on a single file. 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 DB package in native mode, it is necessary to set USE_DB in an appropriate configuration file, and to use tdb you must set USETDB. It may also be necessary to set DBMLIB, as in one of these lines: DBMLIB = -ldb DBMLIB = -ltdb To complicate things further, there are now three very different versions of the Berkeley DB package. Version 1.85 has been stable for quite some time, releases 2.x were current for a while, but the latest versions are numbered 3.x. Releases 2 and 3 are very different internally and externally from the 1.85 release. All versions of Berkeley DB can be obtained from http://www.sleepycat.com/ but maintenance of version 1.85 has been phased out, and it may not compile on some systems. Maintenance for the 2.x releases will cease shortly. There is further discussion about the various DBM libraries in the file doc/dbm.discuss.txt. 4.4 Pre-building configuration 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. 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. Default values are supplied for everything except the settings that specify the locations of the run time configuration file and the directory for holding Exim binaries. These must be given, as Exim will not build without them. There are a few parameters that can be specified either at build time or at run time 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 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, 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 name of the C compiler, which defaults to "gcc". See section 4.9 below for details of how to do this. 4.5 Including TLS/SSL encryption support Exim can be built to support encrypted SMTP connections, using the STARTTLS command (RFC 2487). Before you can do this, you must install the OpenSSL library, which Exim uses for this purpose. There is no cryptographic code in Exim itself. Once OpenSSL is installed, you can set SUPPORT_TLS = yes TLS_LIBS=-lssl -lcrypto in Local/Makefile. You may also need to specify the locations of the OpenSSL library and include files. For example: SUPPORT_TLS = yes TLS_LIBS=-L/usr/local/openssl/lib -lssl -lcrypto TLS_INCLUDE=-I/usr/local/openssl/include/ You don't need to set TLS_INCLUDE if the relevant directory is already specified in INCLUDE. 4.6 Use of tcpwrappers 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, arrange for the file tcpd.h to be available at compile time, and also ensure that the library libwrap.a is available at link time, typically by including -lwrap in EXTRALIBS_EXIM. For example, if "tcpwrappers" is installed in /usr/local, you might have USE_TCP_WRAPPERS=yes CFLAGS=-O -I/usr/local/include EXTRALIBS_EXIM=-L/usr/local/lib -lwrap in Local/Makefile. The name to use in the "tcpwrappers" control files is 'exim'. For example, the line exim : LOCAL 192.168.0. .friendly.domain in your /etc/hosts.allow file allows connections from the local host, from the subnet 192.168.0.0/24, and from all hosts in "friendly.domain". All other connections are denied. Consult the "tcpwrappers" documentation for further details. 4.7 Including support for IPv6 Exim contains code for use on systems that have IPv6 support. 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 on systems where the IPv6 support is not fully integrated into the normal include and library files. 4.8 The building process 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 force a rebuild of the make file in the build directory, should this ever be necessary. If you have problems building Exim, check for any comments there may be in the README file concerning your operating system, and also take a look at the FAQ, where some common problems are covered. 4.9 Overriding build-time options for Exim 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- Local/Makefile Local/Makefile- Local/Makefile- Local/Makefile-- OS/Makefile-Base where is the operating system type and 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 and are obtained from scripts called scripts/os-type and scripts/arch-type respectively. If either of the environ- ment variables EXIM_OSTYPE or EXIM_ARCHTYPE is set, their values are used, thereby providing a means of forcing particular settings. Otherwise, the scripts try to get values from the "uname" command. If this fails, the shell variables OSTYPE and ARCHTYPE are inspected. A number of ad hoc transform- ations are then applied, to produce the standard names that Exim expects. 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-) 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-, 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, NIS+, and other kinds of file lookup, 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 and similar settings apply to the other lookup types. In most cases the relevant include files and interface libraries need to be installed before compiling Exim. However, in the case of cdb, which is included in the binary only if LOOKUP_CDB=yes is set, the code is entirely contained within Exim, and no external include files or libraries are required. When a lookup type is not included in the binary, attempts to configure Exim to use it cause configuration errors. Exim can be linked with an embedded Perl interpreter, allowing Perl subrou- tines to be called during string expansion. To enable this facility, EXIM_PERL=perl.o must be defined in Local/Makefile. Details of this facility are given in chapter 10. 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- 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. In contrast, EXTRALIBS_EXIM is used only on the command for linking the main Exim binary, and not for any associated utilities. There is also DBMLIB, which appears in the link commands for binaries that use DBM functions (see also section 4.3). 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. 4.10 OS-specific header files The OS directory contains a number of files with names of the form os.h-. 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. 4.11 Overriding build-time options for the monitor 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- Local/eximon.conf Local/eximon.conf- Local/eximon.conf- Local/eximon.conf-- As with Exim itself, the final three files need not exist, and in this case the OS/eximon.conf- 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. 4.12 Installing commands and scripts 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, for normal configurations. In some special cases (for example, if a host is doing no local deliveries) is is possible to run Exim in other ways. If the binary is run by a root process, the effect is the same as if it were setuid root. The install script tries to set root as the owner of the main binary, and to make it setuid. It 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-5.5.1-sparc; ../scripts/exim_install -n) Exim's run time configuration file is named by the CONFIGURE_FILE setting in Local/Makefile. If this file does not exist, the default configuration file src/configure.default is copied there by the installation script. If a run time configuration file already exists, it is left alone. 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. Aliases in /etc/aliases and .forward files in users' home directories are supported, but no NIS or NIS+ support is configured. Remote domains are routed using the DNS, with delivery over SMTP. 4.13 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.2). 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. 4.14 Setting up the spool directory 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. 4.15 Testing Having installed Exim, you can check that the run time configuration file is syntactically valid by running the command exim -bV 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, exim -v -bt should verify that it recognizes a local mailbox, and exim -v -bt 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: exim postmaster@your.domain From: user@your.domain To: postmaster@your.domain Subject: Testing Exim This is a test message. ^D 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 exim -d9 -M 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 15. 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. The -bh option can be used to check out any policy controls on incoming SMTP mail. 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 run time configuration, all other file and directory names that Exim uses can be altered, in order to keep it entirely clear of the production version. 4.16 Switching Exim on 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 either /usr/lib/sendmail, or /usr/sbin/sendmail (depending on the operating system), 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 or /usr/sbin/sendmail a symbolic link to the "exim" binary. It is a good idea to remove any setuid privilege and executable status from the old MTA. It is then necessary to stop and restart the mailer daemon, if one is running. You should consider what to tell your users about the change of MTA. Exim may | have different capabilities to what was previously running, and there are | various operational differences such as the text of messages produced by | command line options and in bounce messages. If you allow your users to make | use of Exim's filtering capabilities, you should make the document entitled | "Exim's interface to mail filtering" available to them. | 4.17 Exim on heavily loaded hosts If you are running Exim on a heavily loaded host you should consider installing a current release of "bind" (from http://www.isc.org) as caching nameserver, either locally or on a nearby host with a fast network connection. You should also consider enabling Exim's "split_spool_directory" if you expect to have large numbers of messages awaiting delivery. 4.18 Stopping Exim on Solaris The standard command for stopping the mailer daemon on Solaris 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. 5. THE EXIM COMMAND LINE Exim's command line takes the standard Unix form of a sequence of options, each starting with a hyphen character, followed by a number of arguments. The options are compatible with the main options of Sendmail, and there are also some additional options, some of which are compatible with Smail 3. Certain combinations of options do not make sense, and provoke an error if used. The form of the arguments depends on which options are set. 5.1 Setting options by program name If Exim is called under the name "mailq", it behaves as if the option -bp were present before any other options. This is for compatibility with some systems that contain a command of that name in one of the standard libraries, symbolically linked to /usr/lib/sendmail or /usr/sbin/sendmail. If Exim is called under the name "rsmtp" it behaves as if the option -bS were present before any other options, for compatibility with Smail. The -bS option is used for reading in a number of messages in batched SMTP format. If Exim is called under the name "rmail" it behaves as if the -i and -oee options were present before any other options, for compatibility with Smail. The name "rmail" is used as an interface by some UUCP systems. If Exim is called under the name "runq" it behaves as if the option -q were present before any other options, for compatibility with Smail. The -q option causes a single queue-runner process to be started. If Exim is called under the name "newaliases" it behaves as if the option -bi were present before any other options, for compatibility with Sendmail. This option is used for rebuilding Sendmail's alias file. Exim does not have the concept of a single alias file, but can be configured to run a given command if called with the -bi option. 5.2 Trusted and admin users Some Exim options are available only to "trusted users" and others are available only to "admin users". In the description below, the phrases 'Exim user' and 'Exim group' mean the user and group defined by EXIM_UID and EXIM_GID in Local/Makefile or set by the "exim_user" and "exim_group" options. These do not necessarily have to use the name 'exim'. . A trusted user is root or the Exim user or any user listed in the "trusted_users" configuration option, or any user for whom the currently set group is the Exim group (if defined) or whose current group or any supplementary group is one of those listed in the "trusted_groups" configuration option. Trusted users are always permitted to use the -f option or a leading 'From ' line to specify the envelope sender of a message that is passed to Exim through the local interface (see the -bm and -f options below). For a trusted user, there is never any check on the contents of the "From:" header line, and a "Sender:" line is never added. Furthermore, any existing "Sender:" line in incoming local (non-TCP/IP) messages is not removed. Trusted users may also specify a host name, host address, interface address, protocol name, and ident value. Thus they are able to insert messages into Exim's queue locally that have the characteristics of messages received from a remote host. Untrusted users may in some circumstances use -f, but can never set the other values that trusted users can. "From:" headers are not checked to see if "Sender:" is needed when the caller is trusted. . An admin user is root or the Exim user or any user that is a member of the Exim group (if defined), or of any group listed in the "admin_groups" configuration option. The current group does not have to be one of these groups. Admin users are permitted to operate on messages in the queue, for example, to force delivery failures. It is also necessary to be an admin user in order to see the full information provided by the Exim monitor, and full debugging output. By default, the use of the -M, -q, -R, and -S options to cause Exim to attempt delivery of messages on its queue is restricted to admin users. However, this restriction can be relaxed by setting the "prod_requires_admin" option false (that is, specifying "no_prod_requires_admin"). Similarly, the use of the -bp option to list all the messages in the queue is restricted to admin users unless "queue_list_requires_admin" is set false. 5.3 Command line options The command options are described in alphabetical order below. -- This is a pseudo-option whose only purpose is to terminate the options and therefore to cause subsequent command line items to be treated as arguments rather than options, even if they begin with hyphens. -B This is a Sendmail option for selecting 7 or 8 bit processing. Exim is entirely 8-bit clean; it ignores this option. -bd Run Exim as a daemon, awaiting incoming SMTP connections. This option can be used only by an admin user. If either of the -d or -dm options are set, the daemon does not disconnect from the controlling terminal. By default, Exim listens for incoming connections on all the host's interfaces, but it can be restricted to specific interfaces by setting the "local_interfaces" option in the configuration file. The standard SMTP port is used, but this can be varied by means of the "daemon_smtp_port" configuration option or the -oX command line option. Most commonly, the -bd option is combined with the -q