This chapter describes some of the ways in which incoming mail can be processed automatically, either on a system-wide basis, or as specified by individual users.
Simple re-addressing of messages can be handled by aliasfile or forwardfile directors. The particular case of mailing lists is covered in chapter 42. 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 configuration is:
unknownuser: driver = smartuser transport = unknownuser_pipe no_verify
This collects all the addresses whose local parts haven't been matched by any other director, and directs them to a special pipe transport, whose configuration is:
unknownuser_pipe: driver = pipe command = /opt/exim/util/baduser.sh ignore_status return_output user = nobody
The script is run as the user `nobody', and it can apply heuristics such as soundex search to the local part, in an attempt to produce a list of possible users for whom the message might have been intended. This is then included in a message that is written to its standard output; Exim picks this up and returns it to the sender as part of the delivery error message.
Chapter 47 describes how to arrange to run a system filter file once per message. Sometimes there is a requirement to set up similar automatic processing, but on a per-address basis, that is, the filter is run once for each address. This can be done by using a director such as the following:
filter_per_address: driver = forwardfile no_verify filter file = /etc/per-address-filter no_check_local_user user = nobody
See the separate document entitled Exim's 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.
Some installations have policies that require archive copies of all messages to be made. A single copy of each message can easily be taken by an appropriate command in a system filter, which could, for example, use a different file for each day's messages.
There is also a shadow transport mechanism that can be used to take copies of messages that are successfully delivered by local transports, one copy per delivery. This could be used, inter alia, to implement automatic notification of delivery by sites that insist on doing such things.
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 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.
What users may do in their `.forward' files can be constrained by various options of the forwardfile director:
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.
If delivery to specified files is permitted, the appendfile transport that is used (conventionally called address_file) can specify that the file must already exist, or can restrict the whereabouts of its creation by means of the create_file option.
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:
spqr, vacation-spqr
Another advantage of both these methods is that they both work even when the use of arbitrary pipes by users is locked out.
Go to the first, previous, next, last section, table of contents.