In the Exim Specification document:

In chapter:
                           5. THE EXIM COMMAND LINE

-bf <filename>
       Run Exim in filter testing mode; the file is the filter file to be
       tested, and a test message must be supplied on the standard input. If
       there are no message-dependent tests in the filter, an empty file can
       be supplied. If a system filter file is being tested, -bF should be
       used instead of -bf. If the test file does not begin with the special
       line

       then it is taken to be a normal .forward file, and is tested for
       validity under that interpretation. The result of this command, pro-
       vided no errors are detected, is a list of the actions that Exim would
       try to take if presented with the message for real. More details of
       filter testing are given in the separate document entitled "Exim's User
       interface to mail filtering".


In chapter:
                        44. AUTOMATIC MAIL PROCESSING

Users can cause their mail to be processed automatically by creating .forward
files, provided that Exim's configuration contains an appropriate forwardfile
director. Traditionally, such files contain just a list of forwarding
addresses, local files, and pipe commands, but if the forwardfile director has
the filter option set, users can access Exim's filtering facilities by
beginning a .forward file with the text '# Exim filter'. Details of the syntax
and semantics of filter files are described in a separate document entitled
"Exim's User interface to mail filtering"; this is intended for use by end
users.

The name .forward is purely conventional; a forwardfile director can be
configured to use any arbitrary name. As there are some finger daemons that
display the contents of users' .forward files, some sites might like to use a
different name when mail filtering is provided.


In chapter:
                       4. BUILDING AND INSTALLING EXIM

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,


In chapter:
                            8. REGULAR EXPRESSIONS

A program called pcretest forms part of the PCRE distribution and is built
with PCRE during the process of building Exim. It is primarily intended for
testing PCRE itself, but it can also be used for experimenting with regular
expressions. The binary can be found in the pcre sub-directory of the Exim
build directory. There is documentation of various options in src/pcre/README,
but for simple testing, none are needed. This is the output of a sample run of
pcretest:


In chapter:
                         22. THE FORWARDFILE DIRECTOR

    Although this option is off by default in the code, it is set in the
    default configuration file for handling users' .forward files. It is
    recommended for this use of the forwardfile director. When set, if a
    generated address is the same as any ancestor of the current address, then
    it is not used, but instead the current address gets passed on to
    subsequent directors. This helps in the case where local part A is aliased
    to B, and B has a .forward file pointing back to A, for example:
    'Joe.Bloggs' is aliased to 'jb' and ~jb/.forward contains:


In chapter:
                  UNIVERSITY OF CAMBRIDGE COMPUTING SERVICE


In chapter:
                           5. THE EXIM COMMAND LINE

-bt    Run in address testing mode, in which each argument is taken as an
       address to be tested. The results are written to the standard output.
       If no arguments are given, Exim runs in an interactive manner,
       prompting with a right angle bracket for addresses to be tested. Each
       address is handled as if it were the recipient address of a message and
       passed to the appropriate directors or routers (compare the -bv
       option); the result is written to the standard output. The return code
       is 2 if any address failed outright; it is 1 if no address failed
       outright but at least one could not be resolved for some reason. Return
       code 0 is given only when all addresses succeed.


In chapter:
             19. COMMON GENERIC OPTIONS FOR DIRECTORS AND ROUTERS

    The stat() function is normally run under the exim uid (or root if such is
    not defined). However, it is possible to arrange for this test to be run
    under a specific uid and gid (which is set by means of seteuid() and
    setegid()). If an item in a require_files list does not contain any
    forward slash characters, it is taken to be the user (and optional group,
    separated by a comma) to be used for testing subsequent files in the list.
    If no group is specified but the user is specified symbolically, then the
    gid associated with the uid is used; otherwise the gid is not changed. For
    example:


In chapter:
                 20. ADDITIONAL GENERIC OPTIONS FOR DIRECTORS

    The prefix facility is commonly used to handle local parts of the form
    owner-something. Another common use is to support local parts of the form
    real-username to bypass a user's .forward file - helpful when trying to
    tell a user their forwarding is broken - by placing a director like this
    one immediately before the director that handles .forward files:


In chapter:
                      34. THE DEFAULT CONFIGURATION FILE

  userforward:                                                                 |
    driver = forwardfile                                                       |
    file = .forward                                                            |
    no_verify                                                                  |
    no_expn                                                                    |
    check_ancestor                                                             |
  # filter                                                                     |
    file_transport = address_file                                              |
    pipe_transport = address_pipe                                              |
    reply_transport = address_reply                                            |

An attempt is made to look for a file called .forward in the home directory of
a local user. However, this director is skipped when verifying addresses or
running an SMTP EXPN command. The check_ancestor option prevents a .forward
file from turning a login name back into a previously-handled alias name. The
filter option is commented out in the default configuration. Thus .forward
files are treated in the conventional manner, but filtering can be enabled by
removing the # character.


In chapter:
                         35. MULTIPLE USER MAILBOXES

  userforward:
    driver = forwardfile
    file = .forward
    suffix = -*
    suffix_optional
    filter

  userforward:
    driver = forwardfile
    file = .forward${local_part_suffix}
    suffix = -*
    suffix_optional
    filter

If there is no suffix, .forward is used; if the suffix is "-special", for
example, then .forward-special is used. Once again, if the appropriate file
does not exist, or does not deal with the address, it is passed on to
subsequent directors, which could, if required, look for an unqualified
.forward file to use as a default.


In chapter:
                         49. SECURITY CONSIDERATIONS

If the seteuid() function is being used as described in the previous section,
so that Exim is not root when running the directors, then the forwardfile
director automatically uses seteuid() to become the local user when attempting
to read a .forward file in a user's home directory. If seteuid() is not being
used generally, but is available in the operating system, the forwardfile
director can be configured to make use of it when reading files in home
directories.


In chapter:
                           5. THE EXIM COMMAND LINE

       When testing a filter file, the envelope sender can be set by the -f
       option, or by a 'From ' line at the start of the test message. Various
       parameters that would normally be taken from the envelope recipient
       address of the message can be set by means of additional command line
       options. These are:

-bh <IP address>
       This option runs a fake SMTP session as if from the given IP address,
       using the standard input and output. Comments as to what is going on
       are written to the standard error file. These include lines beginning
       with 'LOG' for anything that would have been logged. This facility is
       for testing configuration options for blocking hosts and/or senders and
       for checking on relaying control. Messages supplied during the testing
       session are discarded, and nothing is written to any of the real log
       files. There may be pauses when DNS (and other) lookups are taking
       place, and of course these may time out. The -oMi option can be used to |
       specify a specific IP interface if this is important.                   |

       If any of the directors or routers in the configuration makes any tests
       on the sender address of a message, then you should use the -f option
       to set an appropriate sender when running -bt tests. Without it, the
       sender is assumed to be the calling user at the default qualifying
       domain.

       If any of the directors or routers in the configuration makes any tests
       on the sender address of a message, then you should use the -f option
       to set an appropriate sender when running -bv tests. Without it, the
       sender is assumed to be the calling user at the default qualifying
       domain.

-f <address>
       Set the address of the sender of a locally-generated message. This
       option can normally be used only by root or the Exim user or by one of
       the configured trusted users. However, anyone may use it when testing a
       filter file with -bf or when testing or verifying addresses using the
       -bt or -bv options. In other cases, the sender of a local message is
       always set up as the user who ran the exim command, and -f is ignored,
       with one exception. If the special setting -f <> is used by an
       untrusted user, it does not affect the sender for the purposes of
       managing the Sender: and From: headers, but it does have the effect of
       causing any SMTP transmissions to be sent out with


In chapter:
                             9. STRING EXPANSIONS

$address_file: When, as a result of aliasing or forwarding, a message is
  directed to a specific file, this variable holds the name of the file when
  the transport is running. For example, using the default configuration, if
  user r2d2 has a .forward file containing

$home: A home directory may be set during a local delivery, either by the
  transport or by the director that handled the address. When this is the
  case, $home contains its value and may be used in any expanded options for
  the transport. The forwardfile director also makes use of $home. Full
  details are given in chapter 22. When interpreting a user's filter file,
  Exim is normally configured so that $home contains the user's home direc-
  tory. When running a filter test via the -bf option, $home is set to the
  value of the environment variable HOME.

$original_domain: When a top-level address is being processed for delivery,
  this contains the same value as $domain. However, if a 'child' address (for
  example, generated by an alias, forward, or filter file) is being processed,
  this variable contains the domain of the original address. This differs from
  $parent_domain when there is more than one level of aliasing or forwarding.
  When more than one address is being delivered in a batch by a local or
  remote transport, $original_domain is not set.

$original_local_part: When a top-level address is being processed for
  delivery, this contains the same value as $local_part. However, if a 'child'
  address (for example, generated by an alias, forward, or filter file) is
  being processed, this variable contains the local part of the original
  address. This differs from $parent_local_part when there is more than one
  level of aliasing or forwarding. When more than one address is being
  delivered in a batch by a local or remote transport, $original_local_part is
  not set.


In chapter:
                         15. THE APPENDFILE TRANSPORT

Appendfile can be used by routers as a pseudo-remote transport for putting     |
messages into files for remote delivery by some means other than Exim, though  |
it is more commonly used by directors for local deliveries to users'           |
mailboxes. It is also used for delivering messages to files or directories     |
whose names are obtained directly from alias, forwarding, or filtering
operations. In these cases, $local_part contains the local part that was
aliased or forwarded, while $address_file contains the name of the file or
directory.


In chapter:
                            17. THE PIPE TRANSPORT

The pipe transport is used to deliver messages via a pipe to a command running
in another process. This can happen when when a director explicitly directs a
message to a pipe transport, and also when an address is expanded via an
alias, filter, or forward file that specifies a pipe command. In this case,
$local_part contains the local part that was aliased or forwarded, while
$address_pipe contains the text of the pipe command itself.


In chapter:
             19. COMMON GENERIC OPTIONS FOR DIRECTORS AND ROUTERS

    If this option is set, the driver is used only when verifying an address
    or testing with the -bv option, not when actually doing a delivery,
    testing with the -bt option, or running the SMTP EXPN command (see the
    expn generic option for directors). It can be further restricted to
    verifying only senders or recipients by means of verify_sender and
    verify_recipient.

 .   The sender of the message is not in agreement with senders. This test is  |
     done after checking for file existence so that sender lists can contain
     references to files whose existence is tested.


In chapter:
                 20. ADDITIONAL GENERIC OPTIONS FOR DIRECTORS

    If this option is turned off, the director is skipped when testing an
    address as a result of processing an SMTP EXPN command. You might, for
    example, want to turn it off on a director for users' .forward files,
    while leaving it on for the system alias file. The use of the SMTP EXPN
    command is permitted only from hosts that match the smtp_expn_hosts main
    configuration option.


In chapter:
                         22. THE FORWARDFILE DIRECTOR

The forwardfile director can be used for two different but related operations.
Its effect is to replace a local part with a list of addresses, file names, or
pipe commands, taken from a single file. It gets its name from the common case
where the file is in a user's home directory and is called .forward, but
another common use is for expanding mailing lists, which are discussed in more
detail in chapter 36.

     in spqr's forward file fails on an incoming message addressed to
     Sam.Reman, because the aliasfile director does not process Sam.Reman the
     second time round, having previously done so. The forward file should
     really contain

When a message cannot be delivered to all of its recipients immediately,
leading to two or more delivery attempts, forwarding expansion is carried out
afresh each time for those addresses whose children were not all previously
delivered. If a forward file is being used as a mailing list, this can lead to
new members of the list receiving copies of old messages. The one_time option
can be used to avoid this.

As an alternative to treating the file as a simple list of addresses, the
forwardfile director can be configured, by means of the filter option, to read
a file and interpret it as a list of "filtering" instructions if it conforms
to a specific format. The instructions can specify various actions such as
appending the message to certain mail folders, or forwarding it to other
users, predicated on the content of the message. Details of the syntax and
semantics of filter files are described in a separate document entitled
"Exim's User interface to mail filtering"; this is intended for use by end
users. If filters are permitted to generate mail messages (see forbid_reply)   |
then the reply_transport option must be set.                                   |

    Without the check_ancestor setting, either local part ('jb' or
    'joe.bloggs') gets processed once by each director and so ends up as it
    was originally. If 'jb' is the real mailbox name, then mail to 'jb' gets
    delivered (having been turned into 'joe.bloggs' by the .forward file and
    back to 'jb' by the alias), while mail to 'joe.bloggs' fails. Setting
    check_ancestor on the forwardfile director prevents it from turning 'jb'
    back into 'joe.bloggs' when that was the original address.

      file = .forward
      file = $home/.forward

      file_directory = /usr/forwards
      file = ${local_part}.forward

    If this option is set, and the forward file starts with the text '# Exim
    filter', then it is interpreted as a set of filtering commands instead of
    a list of forwarding addresses. Details of the syntax and semantics of
    filter files are described in a separate document entitled "Exim's User
    interface to mail filtering"; this is intended for use by end users.

    If this option is set, it associates a home directory with any address
    that forwardfile directs to a local transport because it specifies a file
    name or pipe command. The option string is expanded and set as the home
    directory during the delivery process (that is, at transport time), unless
    overridden by a setting on the transport. If home_directory is not set,
    then the directory specified by file_directory, or if that is not set, the
    home directory obtained from check_local_user is associated with the
    address during delivery. See chapter 13 for details of the local delivery
    environment. This option has no effect during the running of the
    forwardfile director.

    If this option is set and an attempt to open the forward file yields the
    EACCES error (permission denied) then forwardfile behaves as if the file
    did not exist.

    If this option is set and an attempt to open the forward file yields the
    ENOTDIR error (something on the path is not a directory) then forwardfile
    behaves as if the file did not exist.

    If one_time is set and any addresses generated by the director fail to
    deliver at the first attempt, the failing addresses are added to the
    message as 'top level' addresses, and the parent address that generated
    them is marked 'delivered'. Thus expansion via the forward file does not
    happen again at the next delivery attempt. To ensure that forwardfile
    generates only addresses (as opposed to pipe or file deliveries or
    autoreplies) forbid_file and forbid_pipe must also be set, as must
    forbid_reply if filter is set.


In chapter:
                           31. RETRY CONFIGURATION

For remote domains, when looking for a retry rule after a routing attempt has
failed (for example, after a DNS timeout), each line in the retry configur-
ation is tested only against the domain in the address. However, when looking
for a retry rule after a remote delivery attempt has failed (for example, a
connection timeout), each line in the retry configuration is first tested
against the remote host name, and then against the domain name in the address.
For example, if the MX records for a.b.c.d are


In chapter:
                         35. MULTIPLE USER MAILBOXES

runs a user's .forward file for all local parts of the form "username-*".
Within the filter file the user can distinguish different cases by testing the
variable $local_part_suffix. For example:


In chapter:
                    36. USING EXIM TO HANDLE MAILING LISTS

If an entry in a forward file contains a syntax error, Exim normally defers
delivery of the entire message. This may not be appropriate when the list is
being maintained automatically from address texts supplied by users. If the
skip_syntax_errors option is set on the forwardfile director, it just skips
entries that fail to parse, noting the incident in the log. If in addition
syntax_errors_to is set to a verifyable address, messages about skipped
addresses are sent to it.


In chapter:
                             37. VIRTUAL DOMAINS

To send all mail for a domain to a particular local part at a given host,
define the domain as local, then process it with a smartuser director that
sets the new delivery address and passes the message to an smtp transport
which specifies the host. Alternatively, use a forwardfile director pointing
to a fixed file name; the file can contain any number of addresses to which
each message is forwarded.


In chapter:
                        44. AUTOMATIC MAIL PROCESSING

See the separate document entitled "Exim's User interface to mail filtering"
which describes the available filtering commands. Care should be taken to
ensure that none of the commands in the filter file specify a significant
delivery if the message is to go on to be delivered to its intended recipient.
The director will not then claim to have dealt with the address, so it will be
passed on to subsequent directors to be delivered in the normal way. Note that
a traditional (non-filter) .forward file does not have this property, so
cannot be used in this way, though you could use it to forward all mail for a
particular domain to a single recipient in a different domain.

What users may do in their .forward files can be constrained by various
options of the forwardfile director:


In chapter:
                         49. SECURITY CONSIDERATIONS

 .   When reading a user's .forward file, Exim uses seteuid() to become that
     user. This is necessary when the file is not publicly readable and is on
     a remote NFS file system that is mounted without root privilege. If this
     is the case on a system without seteuid(), the .forward file cannot be
     read.

When forward files are read from users' home directories and those home
directories are NFS mounted without root privilege, even a program running as
root cannot read a forward file that does not have world read access.

Forward files are permitted to contain :include: items unless forbidden by
setting forbid_include in the director. If seteuid() is being used to read the
forward file, then any included files are read as the same user. Otherwise
Exim is running as root, and it insists that any included files are within the
same directory as the forward file, and that there are no symbolic links below
the directory. If no directory is specified (either explicitly or by looking
up a local user's home directory) then included files are not permitted when
seteuid() is not in use.


In chapter:
                  UNIVERSITY OF CAMBRIDGE COMPUTING SERVICE


In chapter:
                               1. INTRODUCTION

I am indebted to my colleague Piete Brooks for suggesting and implementing the
scheme for building Exim for multiple architectures and operating systems, for
porting Exim to several different versions of Unix, and for numerous sugges-
tions when I was first developing it. Many other 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.

The list is also forwarded to http://www.egroups.com/list/exim-users, which is
an archiving system with searching capabilities.

 .   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.


In chapter:
                          3. HOW EXIM DELIVERS MAIL

 .   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.

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
36) it is common to direct failure reports to the manager of the list.


In chapter:
                       4. BUILDING AND INSTALLING EXIM

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

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.8 below for details of how to
do this.

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.

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. 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.

  This is a test message.
  ^D

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.


In chapter:
                           5. THE EXIM COMMAND LINE

-bF <filename>
       This option is the same as -bf except that it assumes that the filter
       being tested is a system filter. The additional commands that are
       available only in system filters are recognized.

       The recipients of the message (taken from the envelope, not the
       headers) are displayed on subsequent lines. Those addresses to which
       the message has already been delivered are marked with the letter D. If
       an original address gets expanded into several addresses via an alias
       or forward file, the original is displayed with a D only when
       deliveries for all of its child addresses are complete.

-bpa   This option operates like -bp, but in addition it shows delivered
       addresses that were generated from the original top level address(es)
       in each message by alias or forwarding operations. These addresses are
       flagged with '+D' instead of just 'D'.

-bpu   This option operates like -bp but shows only undelivered top-level
       addresses for each message displayed. Addresses generated by aliasing
       or forwarding are not shown, unless the message was deferred after
       processing by a director with the one_time option set.

-brt   This option is for testing retry rules, and it must be followed by up
       to three arguments. It causes Exim to look for a retry rule that
       matches the values and to write it to the standard output. For example:

-brw   This option is for testing address rewriting rules, and it must be
       followed by a single argument, consisting of either a local part
       without a domain, or a complete address with a fully qualified domain.
       Exim outputs how this address would be rewritten for each possible
       place it might appear. See chapter 32 for further details.

-bv    Verify the addresses that are given as the arguments to the command,
       and write the results to the standard output. Verification differs from
       address testing (the -bt option) in that directors and routers that
       have no_verify set are skipped, and if the address is accepted by a
       director or router that has fail_verify set, verification fails. This
       is the same logic that is used when verifying addresses of incoming
       messages (see chapter 39). The address is verified as a recipient if
       -bv is used; to verify as for a sender address, -bvs should be used.

       If the -v (or -d) option is not set, the output consists of a single
       line for each address, stating whether it was verified or not, and
       giving a reason in the latter case. Otherwise, more details are given
       of how the address has been handled, and in the case of aliases or
       forwarding, the generated addresses are also considered.

-C <filename>
       Read the runtime configuration from the given file instead of from the
       default file specified by the CONFIGURE_FILE compile-time setting. When
       this option is used by an unprivileged caller and the file name given
       is different from the compiled-in name, Exim gives up its root
       privilege immediately, and runs with the real and effective uid and gid
       set to those of the caller, to avoid any security exposure. It does not
       do this if the caller is root or the exim user. The facility is useful
       for ensuring that configuration files are syntactically correct, but
       cannot be used for test deliveries, unless the caller is privileged, or
       unless it's an exotic configuration that does not require privilege. No
       check is made on the owner or group of the file specified by this
       option.

-Mc    The arguments are interpreted as a list of message ids, and Exim runs a
       delivery attempt on each message in turn, but unlike the -M option, it
       does check for retry hints, and respects any that are found. This
       option is not very useful to external callers (except for testing). It
       is provided for internal use by Exim when it needs to re-invoke itself
       in order to regain root privilege for a delivery (see chapter 49).

-R <string>
       The white space between -R and the string is optional. This option is
       similar to -q with no time value, except that, when scanning the
       messages on the queue, Exim processes only those that are not frozen    |
       and have at least one undelivered address containing the given string,  |
       which is checked in a case-independent way. However, once a message is
       selected, all its addresses are processed. For the first message
       containing a matching address, Exim overrides any retry information and
       forces a delivery attempt. This makes it straightforward to initiate
       delivery of all messages to a given domain after a host has been down
       for some time. When the SMTP command ETRN is permitted (see the
       smtp_etrn options), its default effect is to run Exim with the -R
       option.


In chapter:
                         6. FILE AND DATABASE LOOKUPS

     The cdb distribution is not needed in order to build Exim with cdb
     support, as the code for reading cdb files is included directly in Exim
     itself. However, no means of building or testing cdb files is provided
     with Exim because these are available within the cdb distribution.

 .   testdb: This is a lookup type which is for use in debugging Exim. It is
     not likely to be useful in normal operation.


In chapter:
                        7. THE EXIM CONFIGURATION FILE

     The query is expanded before use, and the expansion substitution $key can
     be used to insert the domain that is being tested into the query. There   |
     are cases where a domain list is the result of an earlier string          |
     expansion, for example the domains option in routers and directors. In    |
     these cases you must use \$key to delay the substitution of the variable  |
     until the second expansion, and a double backslash is needed if the whole |
     domain list is in quotes.                                                 |

Note the necessary doubling of the backslashes in the regular expression.
There are obvious processing trade-offs among the various matching modes.
Using an asterisk is faster than a regular expression, and listing a few names
explicitly probably is too. The use of a file or database lookup is expensive,
but may be the only option if hundreds of names are required. Because the
patterns are tested in order, it makes sense to put the most commonly matched
patterns earlier in the string.

     If an IPv4 host calls an IPv6 host, the incoming address actually appears |
     in the IPv6 host as '::ffff:<v4address>'. When such an address is tested  |
     against a host list, it is converted into a traditional IPv4 address      |
     first.                                                                    |

 .   If the item is a plain domain name, then Exim calls gethostbyname() to    |
     find its IP address(es). This typically causes a forward DNS lookup of    |
     the name. The result is compared with the IP address of the subject host. |


In chapter:
                            8. REGULAR EXPRESSIONS

After the 're>' prompt, a regular expression enclosed in delimiters is
expected. If this compiles without error, 'data>' prompts are given for
strings against which the expression is matched. An empty data line causes a
new regular expression to be read. If the match is successful, the captured
substring values (that is, what would be in the variables $0, $1, $2, etc.)
are shown. The above example tests for an email address whose domain ends with
either 'ac' or 'edu' followed by a two-character top-level domain that is not
'kr'. The local part is captured in $1 and the 'ac' or 'edu' in $2.


In chapter:
                             9. STRING EXPANSIONS

A program to test string expansions can be compiled by obeying the command

  make test_expand

once Exim has been successfully compiled. This makes a binary called
test_expand in the build directory. When run, it reads lines from the standard
input, runs them through the string expansion code, and writes the results to
the standard output. Since no message is being processed, variables such as
$local_part have no value, but the program can be used for checking out file
and database lookups, and the use of expansion operators such as substr and
hash.

   Upper-case and lower-case letters are synonymous in header names. If the
   following character is white space, the terminating colon may be omitted.
   The white space is included in the expanded string. If the message does not
   contain the given header, the expansion item is replaced by an empty
   string. (See the def condition in section 9.4 for a means of testing for
   the existence of a header.) If there is more than one header with the same
   name, they are all concatenated to form the substitution string, with a
   newline character between each of them. However, if the length of this      |
   string exceeds 64K, any further headers of the same name are ignored.       |

The following conditions are available for testing while expanding strings:

   Note that the general negation operator provides for inequality testing.
   The two strings must take the form of optionally signed decimal integers,
   optionally followed by one of the letters 'K' or 'M' (in either case),
   signifying multiplication by 1024 or 1024*1024, respectively.

   The substring is first expanded and then interpreted as an absolute path.
   The condition is true if the named file (or directory) exists. The
   existence test is done by calling the stat() function.

   The condition is true if the regular expression match succeeds. At the
   start of an "if" expansion the values of the numeric variable substitutions
   $1 etc. are remembered. Obeying a "match" condition that succeeds causes
   them to be reset to the substrings of that condition and they will have
   these values during the expansion of the success string. At the end of the
   "if" expansion, the previous values are restored. After testing a combi-
   nation of conditions using "or", the subsequent values of the numeric
   variables are those of the condition that succeeded.

$address_pipe: When, as a result of aliasing or forwarding, a message is
  directed to a pipe, this variable holds the pipe command when the transport
  is running.

  When a message is being delivered to a pipe, file, or autoreply transport as
  a result of aliasing or forwarding, $local_part is set to the local part of
  the parent address.

$parent_domain: This variable is empty, except when a 'child' address (gener-
  ated by aliasing or forwarding, for example) is being processed, in which
  case it contains the domain of the immediately preceding parent address.

$parent_local_part: This variable is empty, except when a 'child' address
  (generated by aliasing or forwarding, for example) is being processed, in
  which case it contains the local part of the immediately preceding parent
  address.

$sn0 - $sn9: These variables are copies of the values of the $n0 - $n9
  accumulators that were current at the end of the system filter file. This
  allows a system filter file to set values that can be tested in users'
  filter files. For example, a system filter could set a value indicating how
  likely it is that a message is junk mail.


In chapter:
                            11. MAIN CONFIGURATION

    For non-SMTP input and for batched SMTP input, the test is done at start-
    up; on failure a message is written to stderr and Exim exits with a non-
    zero code, as it obviously cannot send an error message of any kind.

    This option is intended as a temporary operational measure for delaying    |
    the delivery of mail while some problem is being sorted out, or some new   |
    configuration tested. It does not override Exim's message clearing away    |
    code, which removes messages from the queue if they have been there longer |
    than the longest retry time in any retry rule. If you want to hold         |
    messages for longer than the normal retry times, insert a dummy retry rule |
    with a long retry time.                                                    |

    An MTA is said to "relay" a message if it receives it from some host and   |
    delivers it directly to another host as a result of a remote address       |
    contained in it. Expanding a local address via an alias or forward file    |
    and then passing the message to another host is not relaying, but a re-    |
    direction as a result of the 'percent hack' is.                            |

    A check for unwanted relaying is made on the domains of recipient          |
    addresses in messages received from other hosts. If the 'percent hack' is  |
    in use, the test is applied to the domains of the transformed addresses.   |
    The check is done at the time of the RCPT command in the SMTP dialogue.    |

    This option can be set to a colon-separated list of absolute path names,
    each one optionally preceded by 'remote' or 'smtp'. When it is receiving a
    message, Exim tests for the existence of each listed path using a call to
    stat(), and if this succeeds, the corresponding queuing option is set. If
    there is no prefix to the path, queue_only is set; 'remote' corresponds to
    queue_remote and 'smtp' to queue_smtp. So, for example,

    When a message is to be delivered, the number of Received: headers is
    counted, and if it is greater than this parameter, a mail loop is assumed
    to have occurred, the delivery is abandoned, and an error message is
    generated. This applies to both local and remote deliveries. Earlier
    versions of Exim did this test only for remote deliveries, but because
    local deliveries (as Exim sees them) may in fact still cause a message to
    be transported to a remote host, it was changed.

    The SMTP EXPN command is supported only if the calling host matches
    smtp_expn_hosts. You must add 'localhost' explicitly if you want calls to
    127.0.0.1 to be able to use it. A single-level expansion of the address is
    done, as if the address were being tested using the -bt option. If an
    unqualified local part is given, it is qualified with qualify_domain.
    There is a generic option for directors which permits them to be skipped
    when processing an EXPN command (compare with verification).

    Even with a compiled-in path, however, this option makes it possible to
    run testing configurations of Exim without using the standard spool.


In chapter:
                 13. ENVIRONMENT FOR RUNNING LOCAL TRANSPORTS

The forwardfile director's check_local_user option causes a password file
lookup for the local part of an address. The uid and gid obtained from this
lookup are used for any directly generated local deliveries, but they can be
overridden by the group and user options of the director. As for aliasfile,
these values are not used for generated addresses that are processed
independently.

The aliasfile, forwardfile, and localuser directors all have current_directory
and home_directory options, which are associated with any addresses they
explicitly direct to a local transport.

For forwardfile, if home_directory is not set and there is a file_directory
value, that is used instead. If it too is not set, but check_local_user is
set, the user's home directory is used. For localuser, if home_directory is
not set, the home directory is taken from the password file entry that this
director looks up. There are no defaults for current_directory in the
directors, because it defaults to the value of home_directory if it is not set
at transport time.


In chapter:
                      14. GENERIC OPTIONS FOR TRANSPORTS

    If this option is true, an Envelope-to: header is added to the message.
    This gives the original address(es) in the incoming envelope that caused
    this delivery to happen. More than one address may be present if batch or
    bsmtp is set on transports that support them, or if more than one original
    address was aliased or forwarded to the same final address. As this is not
    a standard header, Exim has a configuration option (envelope_to_remove)
    which requests its removal from incoming messages, so that delivered
    messages can safely be resent to other recipients.


In chapter:
                         15. THE APPENDFILE TRANSPORT

    This option constrains the location of files that are created by this
    transport. It must be set to one of the words 'anywhere', 'inhome', or
    'belowhome'. In the second and third cases, a home directory must have
    been set up for the address by the director that handled it. This option
    isn't useful when an explicit file name is given for normal mailbox
    deliveries; it is intended for the case when file names have been
    generated from user's .forward files, which are usually handled by an
    appendfile transport called address_file. See also file_must_exist.

    This option need not be set when appendfile is being used to deliver to
    files whose names are obtained from forwarding, filtering, or aliasing
    address expansions (by default under the instance name address_file), as
    in those cases the file name is associated with the address. Otherwise,
    the file option must be set unless the directory option is set. Either
    use_fcntl_lock or use_lockfile (or both) must be set with file. If you are
    using more than one host to deliver over NFS into the same mailboxes, you
    should always use lock files.

    The string value is expanded for each delivery, and must yield an absolute
    path. If the expansion contains a reference to the local_part variable,
    this is checked to ensure that it does not contain a forward slash
    character - to prevent an unexpected change of directory. The most common
    settings of this option are variations on one of these examples:

    If there is no file name, or the expansion fails, or a local part contains
    a forward slash character, a delivery error occurs.

    The group option is commonly set for local deliveries on systems where the
    set of user mailboxes is in a single directory owned by a group such as
    'mail'. Note that it should not be set on the instance of appendfile that  |
    is used for deliveries to files specified by users in their forward files  |
    (called address_file in the default configuration), because such deliver-  |
    ies should take place under the individual users' personal uids and gids.  |

 .   If opening fails because the file exists, obey the tests given above for
     existing files. However, to avoid looping in a situation where the file
     is being continuously created and destroyed, the exists/not-exists loop
     is broken after 10 repetitions, and the message is then frozen.

     If maildir_tag is set, the string is expanded for each delivery. If the
     expansion is forced to fail, the tag is ignored, but a non-forced failure
     causes delivery to be deferred. Each maildir file that is created has a
     colon followed by the expanded string added to its name. The tag is
     restricted to the alphanumeric characters plus full stop, comma, colon,
     hyphen, and underscore. Any other characters in the string are ignored;
     if the resulting string is empty, no tag is added. If the tag takes the
     length of the name to the point where the test stat() call fails with
     ENAMETOOLONG, then the tag is dropped and the maildir file is created
     with no tag.


In chapter:
                            17. THE PIPE TRANSPORT

As pipe is a local transport, it is always run in a separate process, normally
under a non-privileged uid and gid. In the common case, these are the uid and
gid belonging to the user whose .forward file directed the message at the
pipe. In other cases the uid and gid have to be specified explicitly, either
on the transport or on the director or router that handled the address.
Current and 'home' directories are also controllable. See chapter 13 for
details of the local delivery environment.

String expansion is applied to the command line except when it comes from a
traditional .forward file (commands from a filter file are expanded). The
expansion is applied to each argument in turn rather than to the whole line.
Thus the number of arguments cannot be changed as a result of string
expansion, and quotes or backslashes in inserted variables do not interact
with external quoting.

Not running the command under a shell (by default) lessens the security risks  |
in cases when a command from a user's filter file is built out of data that
was taken from an incoming message. If a shell is required, it can of course
be explicitly specified as the command to be run. However, there are
circumstances where existing commands (for example, in .forward files) expect
to be run under a shell and cannot easily be modified. To allow for these
cases, there is an option called use_shell, which changes the way the pipe
transport works. Instead of breaking up the command line as just described, it
expands it as a single string and passes the result to /bin/sh. The
restrict_to_path option and the $pipe_addresses facility cannot be used with
use_shell, and the whole mechanism is inherently less secure.

When a pipe transport is called directly from (for example) a smartuser
director, then LOCAL_PART is set to the local part of the address. When it is
called as a result of a forward or alias expansion, LOCAL_PART is set to the
local part of the address that was expanded. LOGNAME and USER are set to the
same value as LOCAL_PART for compatibility with other MTAs.

    When this option is set, any command name not listed in allow_commands
    must contain no slashes. The command is searched for only in the
    directories listed in the path option. This option is intended for use in
    the case when a pipe command has been generated from a user's .forward
    file. This is usually handled by a pipe transport called address_pipe.


In chapter:
                            18. THE SMTP TRANSPORT

    For testing purposes, this value can be overridden by the -oB command line
    option.


In chapter:
             19. COMMON GENERIC OPTIONS FOR DIRECTORS AND ROUTERS

    This option specifies a test that has to succeed for the driver to be
    called. The string is expanded, and if the result is a forced failure or
    an empty string or one of the strings '0' or 'no' or 'false' (checked
    without regard to the case of the letters), the driver is not run. This
    provides a means of applying special-purpose conditions to the running of
    directors and routers. The $home variable is available in the expansion
    for directors that set it up. If the expansion fails, it causes Exim to
    panic. Some of the other options below are common special cases that could
    in fact be specified using condition.

    If a driver queues an address for a local transport, and the transport
    does not specify a group, then the group given here is used when running
    the delivery process. If the string contains no $ characters, it is
    resolved when Exim starts up. Otherwise, the string is expanded at the
    time the director or router is run, and must yield either a digit string
    or a name which can be looked up using getgrnam(). For most directors and
    routers the default is unset, but for the forwardfile director with
    check_local_user set, and for the localuser director, the default is taken
    from the passwd file. See also initgroups and user and the discussion in
    chapter 13.

    The driver is run only if the local part of the address matches the list,  |
    which is tested in the same way as a domain list and which may therefore   |
    include plain file names, file lookups, and negation. Because the string   |
    is expanded, it is possible to make it depend on the domain, for example:  |

    The value of this option is first expanded and then interpreted as a
    colon-separated list of strings. If the option is used on a localuser
    director, or on a forwardfile director that has either of the
    check_local_user or file_directory options set, then the expansion vari-
    able $home may appear in the list, referring to the home directory of the
    user whose name is that of the local part of the address.

    If any string is empty, it is ignored. Otherwise, except as described
    below, each string must be a fully qualified file path, optionally
    preceded by '!'. The paths are passed to the stat() function to test for
    the existence of the files or directories. The driver is skipped if any
    paths not preceded by '!' do not exist, or if any paths preceded by '!' do
    exist.

    There are issues concerning verification when the running of directors or
    routers is dependent on the sender. When Exim is verifying an errors_to
    setting in either forwardfile or aliasfile, it sets the sender to the null
    string. If using the -bt option to check a configuration file, it is
    necessary also to use the -f option to set an appropriate sender. For
    incoming mail, the sender is unset when verifying the sender, but is
    available when verifying any recipients. If the SMTP VRFY command is
    enabled, it must be used after MAIL if the sender address matters.

    For most directors and routers the default for user is unset, but for the
    forwardfile director with check_local_user set, and for the localuser
    director, the default is taken from the passwd file. See also initgroups
    and group and the discussion in chapter 13.

In the case of directors, there are some additional conditions that are tested
here (see section 20.1).


In chapter:
                 20. ADDITIONAL GENERIC OPTIONS FOR DIRECTORS

    This option is specific to directors because EXPN applies only to local
    addresses, so no address that is an argument to EXPN is ever passed to any
    router. When Exim is running an EXPN command, it is similar to testing an
    address with -bt. Compare VRFY, whose counterpart is -bv.

    Sometimes an administrator knows that it is pointless to reprocess
    addresses generated from alias or forward files with the same director
    again. For example, if an alias file translates real names into login ids
    there is no point searching the alias file again, especially if it is a
    large file.

 .   The address was generated by aliasing or forwarding and is identical to
     an ancestor address that was processed by this director. This restriction
     breaks addressing loops.


In chapter:
                          21. THE ALIASFILE DIRECTOR

     is treated as an address. For a file name, a transport must be specified  |
     using the file_transport option. However, if the generated path name ends |
     with a forward slash character, it is interpreted as a directory name     |
     rather than a file name, and directory_transport is used instead. If it   |
     ends with two slashes, directory2_transport is required. This makes it    |
     possible to support two different kinds of directory delivery             |
     simultaneously.                                                           |

       X.Employee:  :fail: Gone away, no forwarding address

    When this option is set, if a generated address is the same as any
    ancestor of the current address, then it is not used, but instead the
    current address gets passed on to subsequent directors. In the default
    case, this happens only if the ancestor was processed by the current
    director. See the check_ancestor option on the forwardfile director for
    more details.

    Sometimes the fact that Exim re-evaluates aliases each time it tries to
    deliver a message causes problems. This is particularly true in the case
    of mailing lists and so is more likely to be a problem with forward files
    than with alias files.


In chapter:
                         22. THE FORWARDFILE DIRECTOR

When handling a user's .forward file, a uid, gid, and home directory are
commonly obtained from the password file by calling getpwnam(). However, these
may alternatively be specified by options to the director, in which case
getpwnam() is not called.

 .   An address item may safely be the same local part as the one currently
     under consideration, because a director is automatically skipped if any
     ancestor has the same local part and was processed by that director. Thus
     a user with login name spqr who wants to preserve a copy of mail and also
     forward it somewhere else can set up a file such as

     is treated as an address. For a file name, a transport must be specified  |
     using the file_transport option. However, if the generated path name ends |
     with a forward slash character, it is interpreted as a directory name     |
     rather than a file name, and directory_transport is used instead. If it   |
     ends with two slashes, directory2_transport is required. This makes it    |
     possible to support two different kinds of directory delivery             |
     simultaneously.                                                           |

     may appear, in which case a list of addresses is taken from the given
     file and included at that point, unless the forbid_include option is set.
     There are some security considerations when such an item is included in a
     user's .forward file:

22.2 Repeated forwarding expansion

22.3 Errors in forward files

If skip_syntax_errors is set, a malformed address that causes a parsing error
is skipped, and an entry is written to the main log. This may be useful for
mailing lists that are automatically managed, but note the inherent danger.
The option should never be set for users' .forward files. Otherwise, if any
error is detected while generating the list of new addresses, the message is
frozen, except for the special case of inability to open an included file when
no_freeze_missing_include is set. In this case, delivery is simply deferred.

The home expansion variable can be used in a number of local options for
forwardfile. Its value depends on the way the options are set up, as follows:

 .   If check_local_user is set without file_directory, then the user's home
     directory is set in the home expansion variable when expanding the file
     option that specifies a forward or filter file.

    Setting this option permits the use of freeze and fail in filter files.
    This should not be set on the director for users' .forward files, but can
    be useful if you want to run a system-wide filter for each address, as
    opposed to the system filter, which runs just once per message. See
    chapter 41.

    When this option is set, the local user is always one of the permitted
    owners of the file, and the local user's uid is used when reading the
    forward file if the seteuid option is set or if the global security
    setting is not 'setuid'. In addition the uid and gid read from the passwd
    file are used as defaults for the generic user and group options.

    This option associates a current directory with any address that
    forwardfile directs to a local transport because it specifies a file name,
    pipe command, or autoreply. The option string is expanded and is set as
    the current directory during the delivery process, that is, at transport
    time, unless overridden by a setting on the transport. See chapter 13 for
    details of the local delivery environment.

    A forwardfile director sets up a direct delivery to a directory when a
    path name ending with a slash is specified as a new 'address'. The         |
    transport used is specified by this option, which, after expansion, must   |
    be the name of a configured transport.                                     |

    A forwardfile director sets up a direct delivery to a directory when a
    path name ending with two slashes is specified as a new 'address'. The     |
    transport used is specified by this option, which, after expansion, must   |
    be the name of a configured transport.                                     |

    The string is expanded before use - see above for a discussion of the home
    expansion variable. The option sets a directory path which is used if the
    file option does not specify an absolute path. This on its own is not very
    useful, since the directory string could just as well be prepended to the
    file string. However, if a separate directory is given, it is treated like
    a directory obtained from check_local_user, and its existence is tested
    before trying to open the file. If the directory appears not to exist,
    delivery is deferred. Thus, a setting such as

    defers delivery if /usr/forwards appears not to exist. This can be useful
    if the directory is NFS mounted. If check_local_user is also set,
    file_directory takes precedence in determining the directory name for non-
    absolute files.

    If forwardfile sets up a delivery to a file or a pipe command and the
    home_directory option is not set, then the directory specified by
    file_directory, or if that is not set, the home directory obtained from
    check_local_user is associated with the address during delivery.

    A forwardfile director sets up a direct delivery to a file when a path
    name not ending in a slash is specified as a new 'address'. The transport  |
    used is specified by this option, which, after expansion, must be the name |
    of a configured transport.                                                 |

    If this option is true, use of the logging facility in filter files is not
    permitted. This is in any case available only if the filter is being run
    under some unprivileged uid, which is normally the case for ordinary
    users' .forward files on a system with seteuid() available.

    If this option is true, then this director may not generate an automatic
    reply message. If it attempts to do so, a delivery failure occurs.
    Automatic replies can be generated only from filter files, not from
    traditional forward files.

    In installations where users' .forward files are not kept in their home
    directories, both check_local_user and file_directory may be set, which
    leads to the file_directory value being used as the default. It is no good
    specifying

    This specifies mode bits which must not be set for the forward file. If
    they are set, the director defers.

    Sometimes the fact that Exim re-processes forward files each time it tries
    to deliver a message causes problems. This is particularly true in the
    case of mailing lists (see chapter 36).

    A forwardfile director sets up a direct delivery to a pipe when a string
    starting with a vertical bar character is specified as a new 'address'.    |
    The transport used is specified by this option, which, after expansion,    |
    must be the name of a configured transport.                                |

    A forwardfile director sets up a delivery to an autoreply transport when a
    mail or vacation command is used in a filter file. The transport used is   |
    specified by this option, which, after expansion, must be the name of a    |
    configured transport.                                                      |

    The forwardfile director can detect the first of these cases, and it
    always uses seteuid(), regardless of the setting of this option, since it
    does not make sense to do otherwise.

    On a system without the seteuid() function, but with NFS home directories
    that do not export root, it is necessary for forward files to be world-
    readable.

    If skip_syntax_errors is set for a non-filter forward file, a malformed
    address that causes a parsing error is skipped, and an entry is written to
    the main log. This may be useful for mailing lists that are automatically
    managed, but note the inherent danger. If all the addresses in the list
    are malformed, the original address is passed on to subsequent directors.

    If skip_syntax_errors is set for the director that handles users' .forward
    files, it should normally be done in conjunction with

    in order to pass the error report back to the owner of the .forward file.
    Additional locally-written explanation can be included by setting
    syntax_errors_text.


In chapter:
                          24. THE SMARTUSER DIRECTOR

    If no transport is specified, new_address is required, and the new address
    is processed by the directors and routers in the normal way, as if it were
    the result of aliasing or forwarding. In particular, if it is a duplicate
    of any other address in the message, it is discarded.


In chapter:
                          26. THE DOMAINLIST ROUTER

     The DNS would be set up with an MX record for dict.ref.book pointing to
     the mail hub, which would then then forward mail for dict.ref.book to one
     of the two specified machines, looking up their addresses using
     gethostbyname().

 .   The domainlist router can also be used to forward all non-local mail to a
     "smart host" by using a configuration like


In chapter:
                           31. RETRY CONFIGURATION

The fifth part of the configuration file contains a list of retry rules which
control how often Exim tries to deliver messages that cannot be delivered at
the first attempt. If there are no retry rules, Exim gives up after the first
failure. The -brt command line option can be used to test which retry rule
will be used for a given address or domain.

The second field in a retry rule is the name of a particular error, or an
asterisk, which matches any error. The errors that can be tested for are:


In chapter:
                            32. ADDRESS REWRITING

 .   Rewriting rules for envelope addresses are also applied to new addresses
     that are generated by aliasing or forwarding operations, unless
     no_rewrite is set on the relevant directors.

Exim's rewriting configuration appears as the sixth part of the runtime
configuration file. It can be tested by the -brw command line option. This
takes an address (which can be a full RFC 822 address) as its argument. The
output is a list of how the address would be transformed by the rewriting
rules for each of the different places it might appear, that is, for each
different header and for the envelope sender and recipient fields. For
example,

Rewriting can be made conditional on a number of tests, by making use of ${if  |
in the expansion item. For example, to apply a rewriting rule only to messages |
that originate outside the local host:                                         |


In chapter:
                      34. THE DEFAULT CONFIGURATION FILE

This transport is used by Exim when a local part that is expanded via an alias |
or forward file causes delivery to a pipe. Any output from the pipe is         |
returned to the sender of the message. The third local transport is

This transport is used by Exim when a local part that is expanded via an alias |
or forward file causes delivery to a specified file (by generating a path name |
not ending in '/'). The final local transport is                               |

If forwarding or filtering generates a file, pipe, or autoreply delivery, the  |
address_file, address_pipe, or address_reply transport is used, as appropri-   |
ate. The final director is                                                     |


In chapter:
                         35. MULTIPLE USER MAILBOXES

Alternatively, a suffix can be used to trigger the use of a different .forward
file - which is the way a similar facility is implemented in another MTA:


In chapter:
                    36. USING EXIM TO HANDLE MAILING LISTS

The forwardfile director can be used to handle mailing lists where each list
is maintained in a separate file, which can therefore be managed by an
independent manager. The domains director option can be used to run these
lists in a separate domain from normal mail. For example:

  lists:
    driver = forwardfile
    domains = lists.ref.book
    no_more
    file = /opt/lists/${local_part}
    no_check_local_user
    forbid_pipe
    forbid_file
    errors_to = ${local_part}-request@lists.ref.book

If this behaviour is felt to be undesirable, the one_time option can be set on
the forwardfile director. If this is done, any addresses generated by the
director that fail to deliver at the first attempt are added to the message as
'top level' addresses, and the parent address that generated them is marked
'delivered'. Thus expansion of the mailing list does not happen again at the
subsequent delivery attempts. The disadvantage of this is that if any of the
failing addresses are incorrect, correcting them in the file has no effect on
pre-existing messages.

  lists_request:
    driver = forwardfile
    domains = lists.ref.book
    suffix = -request
    file = /opt/lists/${local_part}${local_part_suffix}
    no_check_local_user

  lists:
    driver = forwardfile
    domains = lists.ref.book
    no_more
    require_files = /opt/lists/${local_part}
    senders = lsearch;opt/lists/${local_part}
    file = /opt/lists/${local_part}
    no_check_local_user
    forbid_pipe
    forbid_file
    one_time
    skip_syntax_errors
    errors_to = ${local_part}-request@lists.ref.book


In chapter:
                      39. VERIFICATION OF INCOMING MAIL

Exim always checks the syntax of SMTP commands, and rejects any that are
invalid. There are a number of options that cause Exim to verify the semantic
validity of the data in an incoming SMTP message. Verification failures can
cause the message to be rejected, or they can just be logged. Other types of
control over incoming mail are discussed in subsequent chapters. The -bh
command line option can be used to run fake SMTP sessions for the purpose of
testing verification options.


In chapter:
                  40. OTHER POLICY CONTROLS ON INCOMING MAIL

An MTA is said to "relay" a message if it receives it from some host and
delivers it directly to another host as a result of a remote address contained
within it. Expanding a local address via an alias or forward file and then
passing the message on to a remote host does not count as relaying. There are
special options for controlling which remote hosts may use the local host as a
relay.

These checks are all in addition to any verification that may be enabled. The
following sections give details of the various checking options. The -bh
command line option can be used to run fake SMTP sessions for the purpose of
testing them.

In addition to the test on the host, if sender_address_relay is set, the
sender's address from the MAIL command must match one of its patterns to allow
outgoing relaying to an arbitrary domain. Also, if there are any rewriting
rules with the 'X' flag set, such an address is rewritten using those rules,
and the result (if different) must verify successfully. See section 32.8 for
an example of how this can be used.

Both relay_domains and host_accept_relay are unset by default, which means     |
that no relaying of any kind is enabled. This does not prevent a local user    |
from setting up forwarding to some external system, but it does prevent the    |
'percent hack' from working even when percent_hack_domains is set.             |

If the recipient address is an RFC 821 source routed address, that is, an
address of the form <@hop1,@hop2:user@domain>, it is the final domain which is
tested. By default, however, Exim will send the message to the hop1 domain,
unless it is a local domain. The collapse_source_routes option can be used to
prevent this.


In chapter:
                      41. SYSTEM-WIDE MESSAGE FILTERING

As well as the additional commands, there is also an extra expansion variable,
$recipients, containing a list of all the recipients of the message, separated
by commas and white space. The extra commands and variable are not available
in ordinary users' filter files. They are faulted in normal use and in testing
via -bf, but not if -bF is used.

  central_filter:
    driver = forwardfile
    file = /central/filters/${local_part}
    no_check_local_user
    no_verify
    filter
    allow_system_actions


In chapter:
                             42. SMTP PROCESSING

The SMTP command EXPN is is permitted only if the calling host matches
smtp_expn_hosts (add 'localhost' if you want calls to 127.0.0.1 to be able to
use it). A single-level expansion of the address is done. EXPN is treated as
an 'address test' (similar to the -bt option) rather than a verification (the
-bv option). If an unqualified local part is given as the argument to EXPN, it
is qualified with qualify_domain.


In chapter:
                        44. AUTOMATIC MAIL PROCESSING

Simple re-addressing of messages can be handled by aliasfile or forwardfile
directors. The particular case of mailing lists is covered in chapter 36.
Other kinds of automatic processing can be handled by suitable configurations
of directors and transports. As an example, here is an extract from the
configuration of a system which tries to send back helpful information when a
message is received for an unknown user. The last director in the configur-
ation is:

  filter_per_address:
    driver = forwardfile
    no_verify
    filter
    file = /etc/per-address-filter
    no_check_local_user
    user = nobody

 .   If the filter option is not set, then only traditional .forward files are
     permitted.

 .   If the forbid_file option is set, then neither a traditional .forward
     file, nor a filter file may direct that a message be appended to a
     particular local file. An attempt to do so causes a delivery error.

 .   If the forbid_pipe option is set, then neither a traditional .forward
     file, nor a filter file may direct that a message be piped to a user-
     specified command. An attempt to do so causes a delivery error.

If piping is permitted, the pipe transport that is used (conventionally called
address_pipe) can constrain the command to be taken from a particular set of
files. Pipe commands generated from traditional .forward files are not string-
expanded, but when a pipe command is generated in a filter file, each argument
is separately expanded.

The traditional way of running the "vacation" program is for a user to set up
a pipe command in a .forward file. This is prone to error by inexperienced
users. There are two features of Exim that can be used to make this process
simpler for users:

 .   A local part prefix such as 'vacation-' can be specified on a director
     which causes the message to be delivered directly to the "vacation"
     program, or uses Exim's autoreply transport. The contents of a user's
     .forward file are then much simpler. For example:


In chapter:
                                45. LOG FILES

  1998-12-10 00:50:49 0znuJc-0001UB-00 => discarded
    <low.club@trick4.bridge> D=userforward

When a local part is expanded by aliasing or a forwarding file, a line is
written to the message log when all its child deliveries are completed. SMTP
connection failures for each remote host are also logged here. The log is
deleted when processing of the message is complete, unless preserve_message_
logs is set, but this should be used only with great care because they can
fill up your disc very quickly.


In chapter:
                          46. DAY-TO-DAY MANAGEMENT

The option hold_domains allows mail for particular domains to be held on the
queue manually. This option is intended as a temporary operational measure for
delaying the delivery of mail while some problem is being sorted out, or some
new configuration tested.


In chapter:
                              47. EXIM UTILITIES

The output of "exim -bp" is based on the original addresses in the message, so
no addresses generated by aliasing or forwarding are included. Consequently
this applies also to the output from exiqsumm.

The exim_fixdb program is a utility for interactively modifying databases. Its
main use is for testing Exim, but it might also be occasionally useful for
getting round problems in a live system. It has no options, and its interface
is somewhat crude. On entry, it prompts for input with a right angle-bracket.
A key of a database record can then be entered, and the data for that record
is displayed.


In chapter:
                             48. THE EXIM MONITOR

Searches of the text in the log window can be carried out by means of the ^R
and ^S keystrokes, which default to a reverse and forwards search respect-
ively. The search covers only the text that is displayed in the window. It
cannot go further back up the log.

Pressing ^R or ^S pops up a window into which the search text can be typed.
There are buttons for selecting forward or reverse searching, for carrying out
the search, and for cancelling. If the 'Search' button is pressed, the search
happens and the window remains so that further searches can be done. If the
'Return' key is pressed, a single search is done and the window is closed. If
^C is pressed the search is cancelled.


In chapter:
                         49. SECURITY CONSIDERATIONS

 .   To be able to change uid and gid in order to read forward files and
     perform local deliveries as the receiving user or as specified in the
     configuration.

49.2 Reading forward files

The forwardfile director does not necessarily have to read from users' home
directories as obtained from getpwnam(). It can be given a directory
explicitly, and a specific associated user and group. The above remarks are
applicable in this case also.

On systems that do not have seteuid(), the only way to support forward files
on NFS file systems that do not export root is to insist that the files be
world readable.

When the filtering option is enabled for forward files, users can construct
pipe commands that contain data from the incoming message by quoting variables
such as $sender_address. To prevent the contents of inserted data from
interfering with a command, the string expansion is done after the command
line is split up into separate arguments, and the command is run directly
instead of passing the command line to a shell.


In chapter:
                          50. FORMAT OF SPOOL FILES

Following the options are those addresses to which the message is not to be
delivered. This set of addresses is initialized from the command line when the
-t option is used and extract_addresses_remove_arguments is set; otherwise it
starts out empty. Whenever a successful delivery is made, the address is added
to this set. The addresses are kept internally as a balanced binary tree, and
it is a representation of that tree which is written to the spool file. If an
address is expanded via an alias or forward file, the original address is
added to the tree when deliveries to all its child addresses are completed.

However, when a child address has been added to the top-level addresses as a
result of the use of the one_time option on an aliasfile or forwardfile
director, each line is of the following form:

In the Exim Filter Specification document:
Most Unix mail transport agents (programs that deliver mail) permit
individual users to specify automatic forwarding of their mail, usually by
placing a list of forwarding addresses in a file called .forward in their
home directories. Exim extends this facility by allowing the forwarding
instructions to be a set of rules rather than just a list of addresses, in
effect providing '.forward with conditions'. Operating the set of rules is
called filtering, and the file that contains them is called a filter file.

Filter files, especially the more complicated ones, should always be
tested, as it is easy to make mistakes. Exim provides a facility for
preliminary testing of a filter file before installing it. This tests the
syntax of the file and its basic operation, and can also be used with
ordinary .forward files.

Because a filter can do tests on the content of messages, a test message is
required. Suppose you have a new filter file called "new-filter" and a test
message called "test-message". Assuming that Exim is installed with the
conventional path name /usr/lib/sendmail, the following command can be
used:

The -bf option tells Exim that the following item on the command line is
the name of a filter file which is to be tested, and the test message is
supplied on the standard input. If there are no message-dependent tests in
the filter, then an empty file can be used. A supplied message must start
with header lines or the 'From' message separator line which is found in
many multi-message folder files. Note that blank lines at the start
terminate the header lines. A warning is given if no headers are read.

The actions themselves are not attempted while testing a filter file in
this way; there is no check, for example, that any forwarding addresses are
valid. If you want to know why a particular action is being taken, add the
-v option to the command. This causes Exim to output the results of any
conditional tests and to indent its output according to the depth if
nesting of if commands. Further additional output from a filter test can be
generated by the testprint command, which is described below.

This is what distinguishes it from a conventional .forward file. If the
file does not have this initial line it is treated as a conventional
.forward file, both when delivering mail and when using the -bf testing
mechanism. The white space in the line is optional, and any capitalization
may be used. Further text on the same line is treated as a comment. For
example, you could have

  add              increment a user variable (11)
  deliver          deliver to an email address (12)
  finish           end processing (17)
  if               test condition(s) (18)
  logfile          define log file (16)
  logwrite         write to log file (16)
  mail             send a reply message (15)
  pipe             pipe to a command (14)
  save             save to a file (13)
  testprint        print while testing (17)
  vacation         tailored form of mail (15)

A filter file is normally installed under the name .forward in your home
directory - it is distinguished from a conventional .forward file by its
first line (described below). However, the file name is configurable, and
some system administrators may choose to use some different name or
location for filter files.

as the first filter command, at least while testing. This causes filtering
to be abandoned for a delivery failure message, and since no destinations
are generated, the message goes on to get delivered to the original
address. Unless there is a good reason for not doing so, it is recommended
that the above test be left in all filter files.

This provides a forwarding operation. The message is sent on to the given
address, exactly as happens if the address had appeared in a traditional
.forward file. To deliver a copy of the message to your normal mailbox,
your login name can be given. Once a message has been processed by the
filtering mechanism, it will not be so processed again, so doing this does
not cause a loop.

However, if you have a mail alias, you should not refer to it here. For
example, if the mail address "L.Gulliver" is aliased to "lg103" then all
references in Gulliver's .forward file should be to "lg103". A reference to
the alias will not work for messages that are addressed to that alias,
since, like .forward file processing, aliasing is performed only once on an
address, in order to avoid looping.

       testprint <text>
  e.g. testprint "home=$home reply_address=$reply_address"

It is quite common for people who have mail accounts on a number of
different systems to forward all their mail to one system, and in this case
a check for personal mail should test all their various mail addresses. To
allow for this, the personal condition keyword can be followed by

There are two possible ways in which this can be set up. The first
possibility is the use of multiple .forward files. In this case, mail to
lg103-foo, for example, is handled by looking for a file called .forward-
foo in lg103's home directory. If such a file does not exist, delivery
fails and the message is returned to its sender.

It is possible to configure Exim to support both schemes at once. In this
case, a specific .forward-foo file is first sought; if it is not found, the
basic .forward file is used.

$original_domain: When a top-level address is being processed for delivery,
  this contains the same value as $domain. However, if a 'child' address
  (for example, generated by an alias, forward, or filter file) is being
  processed, this variable contains the domain of the original address.
  This differs from $parent_domain when there is more than one level of
  aliasing or forwarding.

$original_local_part: When a top-level address is being processed for
  delivery, this contains the same value as $local_part. However, if a
  'child' address (for example, generated by an alias, forward, or filter
  file) is being processed, this variable contains the local part of the
  original address. This differs from $parent_local_part when there is more
  than one level of aliasing or forwarding.

It is important to realize that no deliveries are actually made while a
filter file is being processed. The result of filtering is a list of
destinations to which a message should be delivered - the deliveries
themselves take place later, along with all other deliveries for the
message. This means that it is not possible to test for successful
deliveries while filtering. It also means that duplicate addresses gener-
ated by filtering are dropped, as with any other duplicate addresses.

  /usr/lib/sendmail -bf new-filter <test-message

When Exim is outputting a list of the actions it would take, if any text
strings are included in the output, non-printing characters therein are
converted to escape sequences. In particular, if any text string contains a
newline character, this is shown as '\n' in the testing output.

When testing a filter in this way, Exim makes up an 'envelope' for the
message. The recipient is by default the user running the command, and so
is the sender, but the command can be run with the -f option to supply a
different sender. For example,

/usr/lib/sendmail -bf new-filter -f islington@neverwhere <test-message

The 'return path' is the same as the envelope sender, unless the message
contains a "Return-path:" header, in which case it is taken from there. You
need not worry about any of this unless you want to test out features of a
filter file that rely on the sender address or the return path.

It is possible to change the envelope recipient by specifying further
options. The -bfd option changes the domain of the recipient address, while
the -bfl option changes the 'local part', that is, the part before the @
sign. An adviser could make use of these to test someone else's filter
file.

Testing a filter file before installation cannot find every potential
problem; for example, it does not actually run commands to which messages
are piped. Some 'live' tests should therefore also be done once a filter is
installed.

If at all possible, test your filter file by sending messages from some
OTHER account. If you send a message to yourself from the filtered account,
and delivery fails, the error message will be sent back to the same
account, which may cause another delivery failure. It won't cause an
infinite sequence of such messages, because delivery failure messages do
not themselves generate further messages. However, it does mean that the
failure won't be returned to you, and also that the postmaster will have to
investigate the stuck message.

If you have to test a filter from the same account, then a sensible
precaution is to include the line

$original_local_part: When a top-level address is being processed, this
contains the same value as local_part. However, if an address generated by
an alias, forward, or filter file is being processed, this variable
contains the local part of the original address.

You can test for the presence or absence of a header by means of the 'def'
condition, which is described in section 33.

Several lines of text can be supplied to "text" by including the escape
sequence '\n' in the string where newlines are required. If the command is
output during filter file testing, newlines in the text are shown as '\n'.

Note that the keyword for creating a "Reply-to:" header is reply_to,
because Exim keywords may contain underscores, but not hyphens. If the from
keyword is present and the given address does not match the user who owns
the forward file, Exim adds a Sender: header to the message.

It is sometimes helpful to be able to print out the values of variables
when testing filter files. The command

does nothing when mail is being delivered. However, when the filtering code
is being tested by means of the -bf option, the value of the string is
written to the standard output.

Most of the power of filtering comes from the ability to test conditions
and obey different commands depending on the outcome. The "if" command is
used to specify conditional execution, and its general form is

19. String testing conditions

There are a number of conditions that operate on text strings, using the
words 'begins', 'ends', 'is', 'contains' and 'matches'. If the condition
names are written in lower-case, the testing of letters is done without
regard to case; if they are written in upper-case (for example, 'CONTAINS')
then the case of letters is significant.

A 'begins' test checks for the presence of the second string at the start
of the first, both strings having been expanded.

An 'ends' test checks for the presence of the second string at the end of
the first, both strings having been expanded.

An 'is' test does an exact match between the strings, having first expanded
both strings.

A 'contains' test does a partial string match, having expanded both
strings.

For a 'matches' test, after expansion of both strings, the second one is
interpreted as a regular expression. Exim uses the PCRE regular expression
library, which provides regular expressions that are compatible with Perl.

Care must be taken if you need a backslash in a regular expression, because
backslashes are interpreted as escape characters both by the string
expansion code and by Exim's normal string reading code. For example, if
you want to test the sender address for a domain ending in ".com" the
regular expression is

If the regular expression contains bracketed sub-expressions, then numeric
variable substitutions such as $1 can be used in the subsequent actions
after a successful match. If the match fails, the values of the numeric
variables remain unchanged. Previous values are not restored after "endif"
- in other words, only one set of values is ever available. If the
condition contains several sub-conditions connected by "and" or "or", it is
the strings extracted from the last successful match that are available in
subsequent actions. Numeric variables from any one sub-condition are also
available for use in subsequent sub-conditions, since string expansion of a
condition occurs just before it is tested.

20. Numeric testing conditions

The following conditions are available for performing numerical tests:

The variable "local_part" contains the local part of the mail address of
the user whose filter file is being run - it is normally your login id. The
"domain" variable contains the mail domain. This condition tests for the
appearance of the current user in the "To:" header, checks that the sender
is not the current user or one of a number of common daemons, and checks
the content of the "Subject:" and "Precedence:" headers.

If prefixes or suffixes are in use for local parts - something which
depends on the configuration of Exim (see section 26 below) - then the
first two tests above are also done with

instead of just $local_part. If the system is configured to rewrite local
parts of mail addresses, for example, to rewrite 'dag46' as 'Dirk.Gently',
then the rewritten form of the address is also used in the tests.

Whether or not any previously obeyed filter commands have resulted in a
significant delivery can be tested by the condition "delivered", for
example:

There are two conditions which are intended mainly for use in system filter
files, but which are available in users' filter files as well. The
condition "first_delivery" is true if this is the first attempt to deliver
the message, and false otherwise. In a user filter file it will be false
only if there was previously an error in the filter, or if a delivery for
the user failed due to, for example, a quota error, or forwarding to a
remote address that was deferred for some reason.

If there are no valid addresses in the list, the whole condition is false.
If the internal condition is true for any one address, the overall
condition is true and the loop ends. If the internal condition is false for
all addresses in the list, the overall condition is false. This example
tests for the presence of an eight-digit local part in any address in a To:
header:

The alternative approach is to pass all messages through a single .forward
file, which must be a filter file in order to distinguish between the
different cases by referencing the variables local_part_prefix or
local_part_suffix, as in the final example in section 28 below. If the
filter file does not handle a prefixed or suffixed address, delivery fails
and the message is returned to its sender.

The "personal" test (see section 21) includes prefixes and suffixes in its
checking.

As was explained above, filtering just sets up addresses for delivery - no
deliveries are actually done while a filter file is active. If any of the
generated addresses subsequently suffers a delivery failure, an error
message is generated in the normal way. However, if the filter command
which sets up a delivery is preceded by the word "noerror", then errors for
that delivery, and any deliveries consequent on it (that is, from alias,
forwarding, or filter files it invokes) are ignored.

Simple forwarding:

   Upper-case and lower-case letters are synonymous in header names. If the
   following character is white space, the terminating colon may be
   omitted. The white space is included in the expanded string. If the
   message does not contain the given header, the expansion item is
   replaced by an empty string. (See the def condition in section 33 for a
   means of testing for the existence of a header.) If there is more than
   one header with the same name, they are all concatenated to form the
   substitution string, with a newline character between each of them.       |
   However, if the length of this string exceeds 64K, any further headers    |
   of the same name are ignored.                                             |

The following conditions are available for testing while expanding strings:

   Note that the general negation operator provides for inequality testing.
   The two strings must take the form of optionally signed decimal
   integers, optionally followed by one of the letters 'K' or 'M' (in
   either case), signifying multiplication by 1024 or 1024*1024,
   respectively.

   The substring is first expanded and then interpreted as an absolute
   path. The condition is true if the named file (or directory) exists. The
   existence test is done by calling the stat() function.

   The condition is true if the regular expression match succeeds. At the
   start of an "if" expansion the values of the numeric variable substitu-
   tions $1 etc. are remembered. Obeying a "match" condition that succeeds
   causes them to be reset to the substrings of that condition and they
   will have these values during the expansion of the success string. At
   the end of the "if" expansion, the previous values are restored. After
   testing a combination of conditions using "or", the subsequent values of
   the numeric variables are those of the condition that succeeded.

$home: This is set to the user's home directory when user filtering is
  configured in the normal way. When running a filter test via the -bf
  option, $home is set to the value of the environment variable HOME.

$parent_domain: This variable is empty, except when a 'child' address
  (generated by aliasing or forwarding, for example) is being processed, in
  which case it contains the domain of the immediately preceding parent
  address.

$parent_local_part: This variable is empty, except when a 'child' address
  (generated by aliasing or forwarding, for example) is being processed, in
  which case it contains the local part of the immediately preceding parent
  address.

$sn0 - $sn9: These variables are copies of the values of the $n0 - $n9
  accumulators that were current at the end of the system filter file. This
  allows a system filter file to set values that can be tested in users'
  filter files. For example, a system filter could set a value indicating
  how likely it is that a message is junk mail.

In the Exim FAQ document:
       (C) I investigated the RFCs which describe the DSN (delivery status
       notification) system, and there is even a bit of code in there (excluded
       by #ifdef) for handling some of the data. However, I was unable to
       specify any sensible way of actually doing anything with the data. There
       were comments on the mailing list at the time; many people, including
       me, conclude that DSN is in practice unworkable. The killer problem is
       with forwarding and aliasing. Do you propagate the DSN data with the
       generated addresses? Do you send back a "reached end of the DSN world"
       or "expanded" message? Do you do this differently for different kinds of
       aliasing/forwarding? For a user who has a .forward file with a single
       address in, this might seem easy - just propagate the data. But what if
       there are several forwardings? If you propagate the DSN data, the sender
       may get back several DSN messages - and should the sender really know
       about the detail of the receiver's forwarding arrangements? There isn't
       really any way to distinguish between a .forward file that is forwarding
       and one that is a mini mailing list. And so on, and so on. There are so
       many questions that don't have obvious answers.

Q0420: Why am I seeing the error "bad mode (100664) for /home/test/.forward
       (userforward director)"? I've looked through the documentation but can't
       see anything to suggest that exim has to do anything other than read the
       .forward file.

Q0422: When a user's .forward file is syntactially invalid, Exim defers
       delivery of all messages to that user, which sometimes include the
       user's own test messages. Can it be told to ignore the .forward file
       and/or inform the user of the error?

         1998-08-10 16:55:32 0z5y2W-0000B8-00 == xxxx@yyy.zzz <xxxx@yyy.zz>
           D=userforward defer (-1): failed to open /home/xxxx/.forward
           (userforward director): Permission denied (euid=1234 egid=101)

A5033: Exim filters and procmail provide different facilities. Exim filters run
       at directing time, before *any* deliveries are done. A filter is like a
       ".forward file with conditions". One of the benefits is de-duplication.
       Another is that if you forward, you are forwarding the original message.

A2000: The author of Exim believes that it is Y2K-compliant, as long as the
       underlying operating system and C library are. Exim does not parse dates
       or times at all. Internally, it makes some use of binary timestamps in
       Unix format (number of seconds since 1-Jan-1970) and uses C library
       services to convert these to printing forms (e.g. for logging). The
       printing forms all use 4-digit years. Some people have tried various
       tests. No problems have been reported, but details of what tests have
       been done are not available.

       In earlier versions, low cunning can be used to achieve certain
       kinds of test. For example, to test if the message size is less than
       or equal to 1000000:

A0422: Setting skip_syntax_errors on the forwardfile director causes syntax
       errors to be skipped. When dealing with users' .forward files it is best
       to combine this with a setting of syntax_errors_to in order to send
       a message about the error to the user. However, to avoid an infinite
       cascade of messages, you have to be able to send to an address that
       bypasses .forward file processing. This can be done by including a
       director like this one

       *before* the forwardfile director. This will do an ordinary local
       delivery without .forward processing, if the local part is prefixed by
       "real-". You can then set something like the following options on the
       forwardfile director:

A5022: That is because -R matches only original recipient addresses, not those
       produced as a result of expansion, because these are not (by default)
       preserved from delivery to delivery. You can get round this by setting
       one_time on the forwardfile director, but you are not allowed to have
       expansions to pipes or files on directors that have one_time set.
       Therefore, you will have to have a separate director for mailing lists
       (with one_time set) to the one used for normal forward files that might
       specify pipe or file deliveries. However, the problem will then still be
       present for any user who sets up a .forward file to redirect to any of
       the ETRN domains. See the last 3 paragraphs of A0521 for a discussion of
       an alternative approach.

A0804: The -bh option allows you to run a testing SMTP session as if from a
       given address. You need to know a blocked IP address with which to test.
       Such a testing address is kindly provided by Russell Nelson:

A0409: Set the seteuid option on the forwardfile director so that Exim
       "becomes" the user before trying to read the file. However, if your
       operating system does not support the seteuid() function, you cannot do
       this. In that circumstance, if you cannot persuade your users to make
       their .forward files world readable, you can set the ignore_eacces
       option, which causes Exim to ignore unreadable files.

       to allow a .forward file to be used as an Exim filter. If you are not
       trying to use an Exim filter, then you have put a malformed address in
       the .forward file.

A0418: The test on local parts and domains is done early on, and only if they
       match is supplementary processing such as prefix and suffix recognition
       done. There is a section of the manual called "Skipping directors" which
       gives details. If you want to ignore a prefix or suffix in the initial
       test of the local part, you can do so by replacing "local_parts" with a
       setting of the "condition" option. For example, suppose you wanted to
       look up the basic local part in a file, and run the director if it is
       found:

       You can also send mail to nelson@linux.crynwr.com from the server
       whose RBL block you are testing. The robot that receives that email
       will attempt to send a piece of test email in reply. If your RBL block
       didn't work, you get a message to that effect. Regardless of whether the
       RBL block succeeds or not it emails you the results of the SMTP
       conversation from a host that is not on the RBL, so you can see how your
       server looks from the view of someone on the RBL.

A5003: This isn't straightforward in versions of Exim prior to 2.10, because
       there were no arithmetic operators in expansion strings. In version
       2.10 or later you can write, straightforwardly,

A5034: Exim does not keep this information. It saves only the top-level
       addresses and the list of addresses that are finished with. At each
       delivery attempt, generated addresses are recomputed from scratch. This
       makes it possible to correct errors in .forward and alias files that are
       causing delivery delays. However, there is an option you can set on an
       aliasfile or forwardfile director that changes things. It is called
       one_time, and if it is set, the list of generated addresses gets added
       to the top-level list at the first delivery attempt, and is never
       regenerated. Because top-level address lists must be real email
       addresses, this option cannot be used if any of the generated addresses
       are pipes, files, or autoreplies.

A0001: Exim should never crash. The author is always keen to know about
       crashes, so that they can be diagnosed and fixed. However, before you
       start sending email, please check that you are running the latest
       release of Exim, in case the problem has already been fixed. The
       techniques described below can also be useful in trying to pin down
       exactly which circumstances caused the crash and what Exim was trying to
       do at the time. If the crash is reproducable (by a particular message,
       say) keep a copy of that message. If there is a core file (in Exim's
       spool directory), see if you can get any information from it.

       You can test the link using pings of large packets and see what works:

       (B) If the domain is one for which the local host is providing a
           forwarding service (called "mail hubbing"), possibly as part of a
           firewall, then you need to set up a router to tell Exim where to
           send messages addressed to this domain, since the DNS directs them
           to the local host. The routers section of your configuration file
           should look something like this:

Q0310: How can I configure Exim on a firewall machine so that if mail arrives
       addressed to a domain whose MX points to the firewall, it is forwarded
       to the internal mail server?

       This first tests for a locally-submitted message, by ensuring there is
       no sending host address, and then it checks the identity of the user
       that ran the submitting process.

Q0406: Some of my users are using the .forward to pipe to a shell command which
       appends to the user's INBOX. How can I forbid this?

       If a user simply wants to choose a specific file for the delivery of
       messages, this can be done by putting a file name in a .forward file
       rather than using a pipe, or by using the "save" command in an Exim
       filter file.

       You can set forbid_pipe on the forwardfile director, but that will
       prevent them from running any pipe commands at all. Alternatively, you
       can restrict which commands they may run in their pipes by setting the
       allow_commands and/or restrict_to_path options in the address_pipe
       transport.

Q0409: We've got users who chmod their home to 750, and home is NFS-mounted
       without root privilege, so Exim cannot access ~user/.forward.

Q0414: What does the error message "error in forward file (filtering not
       enabled): missing or malformed local part ..." mean?

A0414: If you are trying to use an Exim filter, you have forgotten to enable
       the facility, which is disabled by default. In the forwardfile director
       (in the Exim configuration file) you need to set

A0419: The problem is in your operating system. Exim just calls the getpwnam()
       function to test a local part for being a local login name. It does not
       presume to guess the maximum length of user name for the underlying
       operating system. Many operating systems correctly reject names that are
       longer than the maximum length; yours is apparently deficient in this
       regard. To cope with such systems, Exim has an option called
       max_user_name_length which you can set to the maximum allowed length.

A0420: For security, Exim checks for mode bits that shouldn't be set, by
       default 022. You can change this by setting the "modemask" option of the
       forwardfile director.

         skip_syntax_errors
         syntax_errors_to = real-$local_part@$domain
         syntax_errors_text = "\
           This is an automatically generated message. An error has been \
           found\nin your .forward file. Details of the error are reported \
           below. While\nthis error persists, messages addressed to you will \
           get delivered into\nyour normal mailbox and you will receive a \
           copy of this message for\neach one."

A0425: (A) If you can set up an LDAP interface to your SQL database, then this
       is relatively straightforward to do, since Exim contains LDAP support.
       It does not at present contain direct SQL support. Sample configuration
       C009 shows you how to lookup users in /etc/passwd/whatever instead of
       /etc/passwd. Modifying this to use LDAP instead of looking in a file
       would be easy.

Q0427: Can I use my existing alias files and forward files as well as procmail
       and effectively drop in exim in place of Sendmail ?

A0427: Yes, as long as your alias/forward files don't assume that pipes are
       going to run under a shell. If they do, you either have to change them,
       or configure Exim to use a shell (which it doesn't by default).

Q0430: I am building some largish mailing lists with Majordomo, and was
       wondering if it worth leaving the actually list expansion to the
       aliasfile :include: mechanism or should I consider using the forwardfile
       transport? Is there any real difference in terms of facilities and/or
       performance, and are the expansions basically the same code anyway?

Q0431: What do I need to do to make Exim handle /usr/ucb/vacation processing
       automatically, so that people could just create a .vacation.msg file in
       their home directory and not have to edit their .forward file?

A0501: Whenever Exim does a local delivery, it runs a process under a specific
       user and group id (uid and gid). For deliveries into mailboxes, and to
       pipes and files set up by .forwarding, it normally picks up the uid/gid
       of the receiving user. However, if an address is directed to a pipe or a
       file by some other means, such an entry in the system alias file of the
       form

       then Exim has to be told what uid/gid to use for the delivery. This can
       be done either on the director that handled the address, or on the
       transport that actually does the delivery. If a pipe is going to run a
       setuid program, then it doesn't matter what uid Exim starts it out with,
       and so the most straightforward thing is to put

Q0506: Whenever Exim tries to do a local delivery, it gives a permission denied
       error for the .forward file, like this:

A0511: The following shell commands test for the interface being up and then
       run the queue:

Q0522: If email has been deferred to a member on a local mailing list
       (implemented through forward files), and one of our ETRN clients is on
       this mailing list, the -R won't "flush" the mailing list message for
       that client.

A0601: There are several possibilities. One straightforward way is to set up
       a domainlist router which matches the UUCP domains and routes to a
       suitable transport. Sample configuration C003 is such a configuration,
       while C004 shows another way to do it, by defining the domains as local
       and using a smartuser director.

Q0803: How can I test that my spam blocks are working?

A0803: The -bh option allows you to run a testing SMTP session as if from a
       given IP address. For example,

       In addition to the normal SMTP replies, it outputs commentary about
       which tests have succeeded or failed.

Q0804: How can I test that Exim is correctly configured to use the Realtime
       Blocking List (RBL)?

A0815: Did you remember to HUP or restart the Exim daemon after changing
       the configuration? You can get information as to what options Exim is
       checking by using the -bh option to test how it would handle mail from
       a specific host.

A0821: This could be done by arranging for a quota check to happen during the
       verification of the address after RCPT, but without hacking Exim you
       would have to use the embedded Perl facility to get it to run a Perl
       script to do the test.

       (1) Set up the normal configuration (in the configuration file whose
           name is screwed into the binary) such that it does local deliveries
           as required, but forwards a copy of the message for non-local
           recipients to a different incarnation of Exim via a private SMTP
           port. For example, use this transport and router:

A1007: In general, this is not possible, because a message may have more than
       one recipient and Exim keeps just a single copy of each message. You can
       do an incomplete job by using a regular expression match in a rewrite
       rule to test, for example, the contents of the To: header. This would
       work except in cases of multiple recipients. See also Q1003.

A1203: It will check 127.0.0.1 (not very useful). The point of the RBL is to
       keep messages from black-listed hosts out of your machine. If you are
       using fetchmail, you have got the messages into your machine before you
       approach Exim. That kind of defeats the purpose of the RBL. The right
       way to do this would be for the host from which you fetchmail to do the
       RBL checking and insert some kind of warning header for you to test, as
       Exim does if you run RBL checks in warning mode.

Q5003: How can I test for a message's size being greater or less than a given
       value in an expansion string?

       Don't try to block mail where envelope from and the header from differ.
       There are common legitimate cases where this happens, for example,
       messages forwarded from mailing lists and delivery failure reports.

       Procmail runs at delivery time. This is for one recipient only, and so
       it can change headers, run pipes and check the results, etc. However, if
       it wants to forward, it has to created a new message containing a copy
       of the original message.

Q5036: When I try "exim -bf" to test a system filter, I received the following
       error message: "Filter error: unavailable filtering command "fail" near
       line 8 of filter file".

A5036: Use the -bF option to test system filters. This gives you access to the
       freeze and fail actions.

       Alternatively, there is an Inst-able port of exim for Irix at
       http://freeware.sgi.com, but it is not likely to be the latest release.

           The first item in this list is empty, to match the empty sender.
           This is necessary because bounce messages have null senders. The
           second item is a regular expression that matches any address whose
           domain is *not* your domain. This caters for cases when mail from
           an external user has arrived for a local user who has forwarding
           set up to some outside address.

       (B) If your local users are in many domains, it may be easier to use a
           "condition" option to test the domain and local part independently,
           along these lines:

           Obviously other means of testing the domain and local part could be
           substituted, for example, by having separate files of valid local
           parts for each local domain.

       This filter makes a copy of every message, except for delivery failure
       reports. To make a copy of outgoing messages only requires a definition
       of "outgoing". Because a message may have many recipients, simply
       testing for your own domain in both the From: and the To: headers is not
       enough. You can craft your own conditions, but here is one suggestion:

         if
           first_delivery and <tests for appropriate addresses>
         then
           unseen save
             /mail/archive/${substr_0_10:$tod_log}
         endif

Q9815: I need an alias, say "fakeaddress" that should receive a message,
       strip all reply-to: headers present, substitute another one pointing to
       "otheraddress" and forward a message to "realaddress".

C017:  "I have gotten the new VERP feature of Exim 2.054 working in test, along
       with some supporting programs to handle bounces that do come back."

