File: spec_20.html

package info (click to toggle)
exim-html 3.20-1
links: PTS
area: main
in suites: etch, etch-m68k, sarge, woody
size: 2,868 kB
ctags: 4,188
sloc: makefile: 40; sh: 19
file content (837 lines) | stat: -rw-r--r-- 26,595 bytes
<HTML>
<HEAD>
<!-- This HTML file has been created by texi2html 1.52
     from spec on 25 November 2000 -->

<TITLE>Exim Specification - 20. Generic options common to both directors and routers</TITLE>
</HEAD>
<body bgcolor="#FFFFFF" text="#00005A" link="#FF6600" alink="#FF9933" vlink="#990000">
Go to the <A HREF="spec_1.html">first</A>, <A HREF="spec_19.html">previous</A>, <A HREF="spec_21.html">next</A>, <A HREF="spec_59.html">last</A> section, <A HREF="spec_toc.html">table of contents</A>.
<P><HR><P>


<H1><A NAME="SEC575" HREF="spec_toc.html#TOC575">20. Generic options common to both directors and routers</A></H1>
<P>
<A NAME="IDX1356"></A>
<A NAME="IDX1357"></A>
<A NAME="IDX1358"></A>
<A NAME="IDX1359"></A>

</P>
<P>
Directors and routers have sufficiently many generic options in common to make
it worth documenting them jointly in this chapter, to save duplication. Any of
these options can be used on any director or router. Subsequent chapters
describe the generic options that are specific either to directors or to
routers.

</P>

<P>

<P>
<A NAME="IDX1360"></A>


<H3><A NAME="SEC576" HREF="spec_toc.html#TOC576">condition (director or router)</A></H3>

<P>
Type: string, expanded<BR>
Default: unset

</P>
<P>
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, and the address is offered to
the next one. This provides a means of applying special-purpose conditions to
the running of directors and routers. The $<EM>home</EM> 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 <EM>condition</EM>.

</P>
<P>
<A NAME="IDX1361"></A>


<H3><A NAME="SEC577" HREF="spec_toc.html#TOC577">debug_print (director or router)</A></H3>

<P>
Type: string, expanded<BR>
Default: unset

</P>
<P>
<A NAME="IDX1362"></A>
If this option is set and debugging is enabled (see -<EM>d</EM>, -<EM>v</EM>, and
<EM>debug_level</EM>), the string is expanded and included in the debugging
output. This is to help with checking out the values of variables and so on
when debugging driver configurations. For example, if a <EM>condition</EM> option
appears not to be working, <EM>debug_print</EM> could be used to output the variables
it references. The output happens after checks for <EM>domains</EM>, <EM>local_parts</EM>,
<EM>suffix</EM> and <EM>prefix</EM>, but before checking <EM>require_files</EM> and <EM>condition</EM>. A
newline is added to the text if it does not end with one.

</P>

<P>
<A NAME="IDX1363"></A>


<H3><A NAME="SEC578" HREF="spec_toc.html#TOC578">domains (director or router)</A></H3>

<P>
Type: domain list, expanded<BR>
Default: unset

</P>
<P>
If this option is set, the string is expanded, and is then interpreted as a
colon-separated list. Because of the expansion, if any of the items contain
backslash or dollar characters, they must be escaped with a backslash. If the
string is given in quotes, backslashes have to be escaped a second time.
<font color=green>
<A NAME="IDX1364"></A>
However, a special case is made for the string `$key', which is commonly used
in query-style lookups. Because such lookups are individually re-expanded
later, when they are used, the string `$key' is passed unchanged through the
initial overall expansion.
</font>

</P>
<P>
The driver is skipped unless the current domain matches the list. If the match
is achieved by means of a file lookup, the data that the lookup returned for
the domain is placed in the $<EM>domain_data</EM> variable for use in string
expansions of the driver's private options. For directors, this option is the
means by which a host can handle several independent local domains. For
routers, it can be used to reduce the use of an expensive router such as
<EM>queryprogram</EM> by doing a preliminary plausibility check on the domain. Note
that the current domain may change as routing proceeds, as a router may replace
the original with a different one for subsequent routers to use.

</P>

<P>
<A NAME="IDX1365"></A>


<H3><A NAME="SEC579" HREF="spec_toc.html#TOC579">driver (director or router)</A></H3>

<P>
Type: string<BR>
Default: unset

</P>
<P>
This option must always be set. It specifies which of the available directors
or routers is to be used.

</P>

<P>
<A NAME="IDX1366"></A>


<H3><A NAME="SEC580" HREF="spec_toc.html#TOC580">errors_to (director or router)</A></H3>

<P>
Type: string, expanded<BR>
Default: unset

</P>
<P>
Delivery errors for any addresses handled or generated by the director or
router are sent to the address that results from expanding this string, if it
is set, and if it verifies as valid.
In other words, this option sets the value of the envelope sender address to be
used for deliveries associated with the driver. If it is unset, or fails to
verify,
the errors address associated with the incoming address (normally the sender)
is used. A typical use might be

<PRE>
errors_to = aliasmaster
</PRE>

<P>
The <EM>errors_to</EM> setting associated with an address can be overridden if it
subsequently passes through other directors or routers that have their own
<EM>errors_to</EM> settings.

</P>

<P>
<A NAME="IDX1367"></A>


<H3><A NAME="SEC581" HREF="spec_toc.html#TOC581">fail_verify (director or router)</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
Setting this option has the effect of setting both <EM>fail_verify_sender</EM> and
<EM>fail_verify_recipient</EM> to the same value.

</P>
<P>
<A NAME="IDX1368"></A>


<H3><A NAME="SEC582" HREF="spec_toc.html#TOC582">fail_verify_recipient (director or router)</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
If this option is true and an address is accepted by this driver when
verifying a recipient, verification fails. This option has no effect if
the <EM>verify_recipient</EM> option is false.

</P>
<P>
<A NAME="IDX1369"></A>


<H3><A NAME="SEC583" HREF="spec_toc.html#TOC583">fail_verify_sender (director or router)</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
If this option is true and an address is accepted by this driver when
verifying a sender, verification fails. This option has no effect if the
<EM>verify_sender</EM> option is false.

</P>

<P>
<A NAME="IDX1370"></A>


<H3><A NAME="SEC584" HREF="spec_toc.html#TOC584">fallback_hosts (director or router)</A></H3>

<P>
Type: string list<BR>
Default: unset

</P>
<P>
<A NAME="IDX1371"></A>
<A NAME="IDX1372"></A>
String expansion is not applied to this option. The argument must be a
colon-separated list of host names or IP addresses. If a driver queues an
address for a remote transport, this host list is associated with the address,
and used instead of the transport's fallback host list. See the
<EM>fallback_hosts</EM> option of the <EM>smtp</EM> transport for further details.

</P>
<P>
<A NAME="IDX1373"></A>


<H3><A NAME="SEC585" HREF="spec_toc.html#TOC585">group (director or router)</A></H3>

<P>
Type: string<BR>
Default: see below

</P>
<P>
<A NAME="IDX1374"></A>
<A NAME="IDX1375"></A>
<A NAME="IDX1376"></A>
If a driver queues an address for a local transport, and the transport does
not specify a group, 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 <EM>getgrnam()</EM>. For most directors and routers the default is
unset, but for the <EM>forwardfile</EM> director with <EM>check_local_user</EM> set, and
for the <EM>localuser</EM> director, the default is taken from the <EM>passwd</EM> file. See
also <EM>initgroups</EM> and <EM>user</EM> and the discussion in chapter 13.

</P>

<P>
<A NAME="IDX1377"></A>


<H3><A NAME="SEC586" HREF="spec_toc.html#TOC586">headers_add (director or router)</A></H3>

<P>
Type: string, expanded<BR>
Default: unset

</P>
<P>
<A NAME="IDX1378"></A>
This option specifies a string of text which is expanded at directing or
routing time, and associated with any addresses that are processed by the
driver. If the expanded string is empty, or if the expansion is forced to fail,
the option has no effect. Other expansion failures are treated as configuration
errors.

</P>
<P>
The expanded string must be in the form of one or more RFC 822 header lines,
separated by newlines (coded as `\n' inside a quoted string). For example:

<PRE>
headers_add = X-added-header: added by $primary_hostname
</PRE>

<P>
Exim does not check the syntax of these added headers, except that a newline is
supplied at the end if one is not present. If an address passes through several
directors and/or routers
as a result of aliasing or forwarding operations, any <EM>headers_add</EM> or
<EM>headers_remove</EM> specifications are cumulative. This does not apply for
multiple directors and/or routers that result from the use of `unseen'.

</P>
<P>
At transport time, for each address, all original headers listed in
<EM>headers_remove</EM> are removed, and those specified by <EM>headers_add</EM> are added,
in the order in which they were attached to the address. Then any additional
headers specified by the transport are added. It is not possible to remove
headers added to an address by <EM>headers_add</EM>.

</P>
<P>
Addresses with different <EM>headers_add</EM> or <EM>headers_remove</EM> settings cannot be
batched.

</P>

<P>
<A NAME="IDX1379"></A>


<H3><A NAME="SEC587" HREF="spec_toc.html#TOC587">headers_remove (director or router)</A></H3>

<P>
Type: string, expanded<BR>
Default: unset

</P>
<P>
<A NAME="IDX1380"></A>
The string is expanded at directing or routing time and is then associated with
any addresses that are processed by the driver.
If the expansion is forced to fail, the option has no effect. Other expansion
failures are treated as configuration errors.
After expansion, the string must consist of a colon-separated list of header
names, not including the terminating colon, for example:

<PRE>
headers_remove = return-receipt-to:acknowledge-to
</PRE>

<P>
It is used at transport time as described under <EM>headers_add</EM> above.

</P>

<P>
<A NAME="IDX1381"></A>
<A NAME="IDX1382"></A>
<A NAME="IDX1383"></A>
<A NAME="IDX1384"></A>
<A NAME="IDX1385"></A>


<H3><A NAME="SEC588" HREF="spec_toc.html#TOC588">initgroups (director or router)</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
If the driver queues an address for a local transport, and this option is true,
and the uid supplied by the router or director is not overridden by the
transport, the <EM>initgroups()</EM> function is called when running the
transport to ensure that any additional groups associated with the uid are set
up. See also <EM>group</EM> and <EM>user</EM> and the discussion in chapter
13.

</P>

<P>
<A NAME="IDX1386"></A>


<H3><A NAME="SEC589" HREF="spec_toc.html#TOC589">local_parts (director or router)</A></H3>

<P>
Type: string list, expanded<BR>
Default: unset

</P>
<P>
If this option is set, the string is expanded, and is then interpreted as a
colon-separated list. Because of the expansion, if any of the items contain
backslash or dollar characters, they must be escaped with a backslash.
<font color=green>
<A NAME="IDX1387"></A>
However, a special case is made for the string `$key', which is commonly used
in query-style lookups. Because such lookups are individually re-expanded
later, when they are used, the string `$key' is passed unchanged through the
initial overall expansion.
</font>

</P>

<P>
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:

<PRE>
local_parts = dbm;/usr/local/specials/$domain
</PRE>

<P>
If the match is achieved by a lookup, the data that the lookup returned
for the local part is placed in the variable $<EM>local_part_data</EM> for use in
expansions of the driver's private options. You might use this option, for
example, if you have a large number of local virtual domains, and you want to
send all postmaster mail to the same place without having to set up an alias in
each virtual domain:

<PRE>
postmaster:
  local_parts = postmaster
  driver = smartuser
  new_address = postmaster@real.dom.ain
</PRE>

<P>
<A NAME="IDX1388"></A>


<H3><A NAME="SEC590" HREF="spec_toc.html#TOC590">more (director or router)</A></H3>

<P>
Type: boolean<BR>
Default: true

</P>
<P>
If this option is false, and the driver declines to handle an address, no
further drivers are tried, and directing or routing fails. This applies even in
the case of address verification where the driver was not run because the
<EM>verify</EM> option was off (see section 20.1).
<A NAME="IDX1389"></A>
However, if a router explicitly passes an address to the following router by
means of the setting
<font color=green>

<PRE>
self = pass
</PRE>

<P>
or by some other means,
</font>
the setting of <EM>more</EM> is ignored.

</P>
<P>
<A NAME="IDX1390"></A>


<H3><A NAME="SEC591" HREF="spec_toc.html#TOC591">require_files (director or router)</A></H3>

<P>
Type: string list, expanded<BR>
Default: unset

</P>
<P>
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 <EM>localuser</EM>
director, or on a <EM>forwardfile</EM> director that has either of the
<EM>check_local_user</EM> or <EM>file_directory</EM> options set, the expansion variable
$<EM>home</EM> may appear in the list, referring to the home directory of the user
whose name is that of the local part of the address.

</P>
<P>
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 <EM>stat()</EM> 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.

</P>
<P>
<font color=green>
The <EM>stat()</EM> function is normally run under the exim uid (or root if such is
not defined). During the delivery of a message, it is possible to arrange for
this test to be run under a specific uid and gid (which is set by means of
<EM>seteuid()</EM> and <EM>setegid()</EM>).

</P>
<P>
<b>Warning</b>: Unfortunately, this is not possible when the driver is being run
to verify addresses for an incoming SMTP message, because at that time, Exim
has given up its root privilege. Therefore, this facility is useful only if you
can set <EM>no_verify</EM> on drivers that use it.
</font>

</P>
<P>
If an item in a <EM>require_files</EM> 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, the gid associated with
the uid is used; otherwise the gid is not changed. For example:

<PRE>
require_files = mail:/some/file
require_files = ${local_part}:${home}/.procmailrc
</PRE>

<P>
The second example works because the <EM>require_files</EM> string is expanded before
use.
<font color=green>
If a user or group name in a <EM>require_files</EM> list does not exist, the
<EM>require_files</EM> condition fails.
</font>

</P>
<P>
<A NAME="IDX1391"></A>
If <EM>stat()</EM> cannot determine whether a file exists or not, delivery of
the message is deferred. This can happen when NFS-mounted filesystems are
unavailable.

</P>
<P>
Sometimes <EM>stat()</EM> yields the error EACCES (`Permission denied'). This
means that the user is not permitted to read one of the directories on the
file's path. The default action is to consider this a configuration error, and
delivery is deferred because the existence or non-existence of the file cannot
be determined. However, in some circumstances it may be desirable to treat this
condition as if the file did not exist. If the file name (or the exclamation
mark that precedes the file name for non-existence) is preceded by a plus sign,
then the EACCES error is treated as if the file did not exist.
For example:

<PRE>
require_files = +/some/file
</PRE>

<P>
This option provides a general mechanism for predicating the running of a
director or router on the existence or non-existence of certain files or
directories. A failure to expand the string, or the presence of a
path within it that is not fully qualified causes a panic error.
This includes forced failure, because the whole string is expanded once, before
being interpreted as a list. If you want a particular variant of the expansion
to specify that no files are to be checked, you should cause it to yield an
empty string rather than forcing failure.

</P>
<P>
<A NAME="IDX1392"></A>


<H3><A NAME="SEC592" HREF="spec_toc.html#TOC592">senders (director or router)</A></H3>

<P>
Type: address list, expanded<BR>
Default: unset

</P>
<P>
The value of this option is expanded, and the result of the expansion must be
a colon-separated address list, in the same format as used for general options
like <EM>sender_reject</EM>. The driver is run only if the sender address matches
something in the <EM>senders</EM> list (when it is set).
Using this option on a director makes it possible to
<A NAME="IDX1393"></A>
<A NAME="IDX1394"></A>
implement closed mailing lists (see chapter 42).

</P>
<P>
There are issues concerning verification when the running of directors or
routers is dependent on the sender. When Exim is verifying an <EM>errors_to</EM>
setting in either <EM>forwardfile</EM> or <EM>aliasfile</EM>, it sets the sender to the null
string. If using the -<EM>bt</EM> option to check a configuration file, it is
necessary also to use the -<EM>f</EM> 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.

</P>
<P>
<A NAME="IDX1395"></A>


<H3><A NAME="SEC593" HREF="spec_toc.html#TOC593">transport (director or router)</A></H3>

<P>
Type: string, expanded<BR>
Default: unset

</P>
<P>
Some directors and routers require a transport to be supplied, except when
<EM>verify_only</EM> is set, where it is not relevant. Others require that a
transport not be supplied, and for some it is optional. The string must be the
name of a configured transport instance, or an expandable string, thus allowing
transports to be dynamically selected. At directing or routing time, when a
driver decides to accept an address, the string is expanded, and must yield the
name of an available transport. If it does not, delivery is deferred. This
isn't as safe as fixed transports, whose existence is checked at initialization
time.

</P>
<P>
<A NAME="IDX1396"></A>


<H3><A NAME="SEC594" HREF="spec_toc.html#TOC594">unseen (director or router)</A></H3>

<P>
Type: boolean<BR>
Default: false

</P>
<P>
Setting this option has a similar effect to the <EM>unseen</EM> command qualifier in
filter files.
It causes a copy of the incoming address to be passed on to subsequent drivers,
when the current one succeeds in handling it. It can be used to cause
<A NAME="IDX1397"></A>
copies of messages to be delivered elsewhere. The effect is to clone the
address before processing one copy of it, so options such as <EM>headers_add</EM> on
the current director do not affect the other copy.

</P>

<P>
<A NAME="IDX1398"></A>


<H3><A NAME="SEC595" HREF="spec_toc.html#TOC595">user (director or router)</A></H3>

<P>
Type: string<BR>
Default: see below

</P>
<P>
<A NAME="IDX1399"></A>
<A NAME="IDX1400"></A>
<A NAME="IDX1401"></A>
If the driver queues an address for a local transport, and the transport does
not specify a user, the user 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 <EM>getpwnam()</EM>. In the latter case, the group associated with the user is
used as a default for the <EM>group</EM> option.

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

</P>

<P>
<A NAME="IDX1402"></A>


<H3><A NAME="SEC596" HREF="spec_toc.html#TOC596">verify (director or router)</A></H3>

<P>
Type: boolean<BR>
Default: true

</P>
<P>
Setting this option has the effect of setting <EM>verify_sender</EM> and
<EM>verify_recipient</EM> to the same value.

</P>
<P>
<A NAME="IDX1403"></A>


<H3><A NAME="SEC597" HREF="spec_toc.html#TOC597">verify_only (director or router)</A></H3>

<P>
Type: boolean<BR>
Default: false

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

</P>
<P>
<A NAME="IDX1404"></A>


<H3><A NAME="SEC598" HREF="spec_toc.html#TOC598">verify_recipient (director or router)</A></H3>

<P>
Type: boolean<BR>
Default: true

</P>
<P>
If this option is false, this driver is skipped when verifying recipient
addresses. It is usual to set it false for instances of the <EM>smartuser</EM>
director
<font color=green>
that have no other conditions imposed on the address.
</font>

</P>
<P>
<A NAME="IDX1405"></A>


<H3><A NAME="SEC599" HREF="spec_toc.html#TOC599">verify_sender (director or router)</A></H3>

<P>
Type: boolean<BR>
Default: true

</P>
<P>
If this option is false, this driver is skipped when verifying sender
addresses. It is usual to set it false for instances of the <EM>smartuser</EM>
director
<font color=green>
that have no other conditions imposed on the address.
</font>

</P>



<H2><A NAME="SEC600" HREF="spec_toc.html#TOC600">20.1 Skipping directors and routers</A></H2>

<P>
<A NAME="IDX1406"></A>
<A NAME="IDX1407"></A>
<A NAME="IDX1408"></A>
<A NAME="IDX1409"></A>
A number of the generic options that are common to directors and routers are
concerned with controlling which drivers are run in particular circumstances.
They interact with each other in the following way:

</P>
<P>
If the domain and local part of an address are not in agreement with <EM>domains</EM>
and <EM>local_parts</EM> (when set), or if the <EM>condition</EM> option fails, or if
<EM>verify_only</EM> is set and verification is not happening, the director or
router is skipped and the next one is tried.

</P>
<P>
Otherwise, if the <EM>more</EM> option is false, no subsequent drivers are ever
called, except when a router explicitly passes an address that routes to the
local host on to the following driver, by means of the
<A NAME="IDX1410"></A>
generic <EM>self</EM> option or the <EM>host_find_failed</EM> option of the <EM>domainlist</EM>
router. The current driver is itself called unless

</P>

<UL>

<LI>

Verification is happening and its <EM>verify_sender</EM> or <EM>verify_recipient</EM>
option (as appropriate) is turned off, or

<LI>

The existence or non-existence of files listed in the <EM>require_files</EM> option
is not as expected, or

<LI>

The sender of the message is not in agreement with <EM>senders</EM>.
</UL>

<P>
Both the <EM>senders</EM> and <EM>condition</EM> tests are done after checking for file
existence, so that they can contain references to files whose existence is
tested. The order of testing the options which are expanded strings is:
<EM>domains</EM>, <EM>local_parts</EM>, <EM>require_files</EM>, <EM>senders</EM>, <EM>condition</EM>. When any
test fails, no further expansions are done.

</P>
<P>
In the case of directors, there are some additional conditions that are tested
here (see section 21.1).

</P>
<P>
The <EM>unseen</EM> option causes directing or routing to continue when it would
otherwise cease. This is the complementary action to <EM>no_more</EM>, which causes
it to cease when it would otherwise continue.

</P>
<P>
The <EM>verify</EM>, <EM>fail_verify</EM>, and <EM>verify_only</EM> options make it possible to
separate those addresses which correspond to a real delivery from those which
are recognized, but which do something else if actually encountered in a
message.

</P>
<P>
For example, a <EM>smartuser</EM> 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 directing failure. However, if (for example)
verification of senders is taking place (the <EM>sender_verify</EM> main
configuration option), you probably don't want
&#60;<EM>random-local-part@your.domain</EM>&#62; to be accepted. The solution is to set
<EM>no_verify</EM> or <EM>no_verify_sender</EM> on the <EM>smartuser</EM> director.

</P>
<P>
On our systems in Cambridge we can identify users whose accounts have recently
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 as
senders should fail, but just setting <EM>no_verify</EM> on the director doesn't
work, because the local part is then passed to a <EM>localuser</EM> director that may
still find it in the password file. (Initially, cancellation just resets the
password.) This is the sort of case for which <EM>fail_verify</EM> was invented. It
makes it possible to fail a set of local parts that is defined by what a
specific director matches.

</P>

<P><HR><P>
Go to the <A HREF="spec_1.html">first</A>, <A HREF="spec_19.html">previous</A>, <A HREF="spec_21.html">next</A>, <A HREF="spec_59.html">last</A> section, <A HREF="spec_toc.html">table of contents</A>.
</BODY>
</HTML>