The following additional generic options apply to all directors, in addition to the common generic options for both directors and routers which are described in chapter "Common generic options for directors and routers". Directors are concerned with addresses whose domains match something in `local_domains', or which have been explicitly determined to be local by a router.
Option: expn
Type: boolean
Default: true
If this option is turned off, the director is skipped when verifying 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' or `smtp_expn_nets' general options.
Option: new_director
Type: string
Default: unset
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 `new_director' option can be set to the name of any director instance. It causes the directing of any generated local addresses to start at the named director instead of the first director. The named director can be any configured director. This option has no effect if the director in which it is set does not generate new addresses, or if such addresses are not in local domains.
Option: prefix
Type: string-list
Default: unset
If this option is set, the director is skipped unless the local part starts with one of the given strings, or the `prefix_optional' option is true. A limited form of wildcard is available; if the prefix begins with an asterisk, it matches the longest possible sequence of arbitrary characters at the start of the local part. An asterisk should therefore always be followed by some character that does not occur in normal local parts. Wildcarding can be used to set up multiple user mailboxes, as described in chapter "Multiple user mailboxes".
While the director is running, the prefix is removed from the local part, and is available in the expansion variable `local_part_prefix'. If the director succeeds, this remains true during subsequent delivery.
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:
real_localuser: driver = localuser transport = local_delivery prefix = real-
If both `prefix' and `suffix' are set for a director, both conditions must be met if not optional. Care must be taken if wildcards are used in both a prefix and a suffix on the same director. Different separator characters must be used to avoid ambiguity.
Option: prefix_optional
Type: boolean
Default: false
See `prefix' above.
Option: suffix
Type: string-list
Default: unset
This option operates in the same way as `prefix', except that the local part must end (rather than start) with the given string, the `suffix_optional' option determines whether the suffix is mandatory, and the wildcard * character, if present, must be the last character of the suffix. This option facility is commonly used to handle local parts of the form `something-request' and multiple user mailboxes of the form `username-foo'.
Option: suffix_optional
Type: boolean
Default: false
See `suffix' above.
The `new_director' generic option causes the directing of a generated local address to start at a particular director, thus skipping those above it. A number of other generic options can cause directors to be skipped for particular cases. They interact with each other in the following way:
If the domain and local part are not in agreement with `domains', `except_domains', `local_parts', and `except_local_parts' (when set), or if the `condition' option fails, or if `verify_only' is set and verification is not happening, then the director is skipped and the next one is tried. None of the other options are inspected.
Otherwise, if the `more' option is not set, no subsequent directors are ever called, in any circumstances. The current director is itself called unless
The `unseen' option causes directing to continue when it would otherwise cease, the complementary action to `no_more', which causes it to cease when it would otherwise continue.
The `verify', `fail_verify', and `verify_only' options make it possible to separate those local parts which correspond to a real local delivery from those which are recognized, but which do something else if actually encountered in a message.
For example, a `smartuser' director might be used to pass all unrecognized local parts to a script that tries to generate a helpful error message, or to a different machine that might be able to handle them. This means that no local part will ever cause a delivery failure. However, if (for example) verification of senders is taking place (the `sender_verify' main configuration option), you probably don't want <random-local-part@your.domain> to be accepted. The solution is to set `no_verify' or `no_verify_sender' on the `smartuser' director.
On our systems in Cambridge we keep a list of users whose accounts have been cancelled, and their mail is piped to a script which sends back a more helpful message than `user unknown'. Verification of such local parts should fail, but just setting `no_verify' on the director doesn't work, because the local part is then passed to a `localuser' director that may still find it in the password file. (Initially, cancellation just resets the password.) This is the sort of case for which `fail_verify' was invented. It makes it possible to fail an explicit list of local parts.
Go to the first, previous, next, last section, table of contents.