File: spec_28.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 (829 lines) | stat: -rw-r--r-- 26,100 bytes
<HTML>
<HEAD>
<!-- This HTML file has been created by texi2html 1.52
     from spec on 25 November 2000 -->

<TITLE>Exim Specification - 28. The domainlist router</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_27.html">previous</A>, <A HREF="spec_29.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="SEC691" HREF="spec_toc.html#TOC691">28. The domainlist router</A></H1>
<P>
<A NAME="IDX1591"></A>
The <EM>domainlist</EM> router compares a list of domain patterns with the domain it
is trying to route. When a match is found, the information associated with the
pattern can specify several different actions:

</P>

<UL>

<LI>

The message can be sent to a specific host, or one of a number of hosts.

<LI>

The domain name can be replaced by a new name, which can be


<OL>

<LI>

passed to the next router; or

<LI>

looked up directly in the DNS, with or without MX processing; or

<LI>

looked up using <EM>gethostbyname()</EM>.
</OL>

Of course, <EM>gethostbyname()</EM> may well do its own DNS lookup, but it does not do
MX processing, and it may also reference other sources of information, such as
<EM>/etc/hosts</EM>. When Exim is compiled with IPv6 support, if a host that is looked
up in the DNS has both A and AAAA
<font color=green>
or A6
</font>
records, all the addresses are used.
</UL>

<P>
The list of patterns can be specified as an option string, or looked up in a
file or database, or both; at least one of <EM>route_list</EM>, <EM>route_file</EM>,
<EM>route_query</EM>,
or <EM>route_queries</EM>
must be set. A transport must be set when the routing is completed by this
router, that is, when the address is not passed on to subsequent routers,
unless <EM>verify_only</EM> is set.
Each routing entry can specify its own transport, with the generic <EM>transport</EM>
option acting as a default for those that don't.

</P>

<P>

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

</P>

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


<H3><A NAME="SEC692" HREF="spec_toc.html#TOC692">host_find_failed (domainlist)</A></H3>

<P>
Type: string<BR>
Default: "freeze"

</P>
<P>
This option controls what happens if a host which <EM>domainlist</EM> tries to look up
because an address has been specifically routed to it does not exist. The
option can be set to one of
<font color=green>

<PRE>
freeze
defer
pass
fail
</PRE>

<P>
The default assumes that this state is a serious configuration error. The
difference between `pass' and `fail' is that the former causes the
address to be passed to the next router,
<A NAME="IDX1594"></A>
overriding <EM>no_more</EM>, while the latter does not, causing the address to fail
completely.

</P>
<P>
In earlier versions of Exim <EM>fail_soft</EM> and <EM>fail_hard</EM> were used instead of
<EM>pass</EM> and <EM>fail</EM>. They will remain as synonyms for some time.
</font>

</P>
<P>
This option applies only to a definite `does not exist' state; if a host lookup
gets a temporary error, delivery is deferred unless the generic
<EM>pass_on_timeout</EM> option is set.

</P>
<P>
<font color=green>
<A NAME="IDX1595"></A>


<H3><A NAME="SEC693" HREF="spec_toc.html#TOC693">hosts_randomize (domainlist)</A></H3>

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

</P>
<P>
<A NAME="IDX1596"></A>
<A NAME="IDX1597"></A>
If this option is set, the order of the items in a host list in a routing rule
is randomized each time it is used. This can be used to do crude load sharing.
However, there is a complication when a message has more than one address that
is routed by the same rule. Without randomization, each such address ends up
with an identical host list, and so they are all eligible for batching and
sending in a single SMTP transaction. When the host order is randomized, the
addresses won't all end up with the same host list, and so they will not be
batched in the same way.

</P>
<P>
If there are only two hosts in the list, this probably doesn't matter too much,
because, on average, 50% of addresses will have them one way round, and 50% the
other, so you just get two SMTP calls instead of one, however many addresses
there are. With more than two hosts, however, the number of permutations
increases very rapidly, leading to very many more SMTP calls being made. The
way to solve this problem is to put a single, dummy host in the routing rule,
and route the addresses to a special <EM>smtp</EM> transport, which has <EM>hosts</EM>,
<EM>hosts_randomize</EM>, and <EM>hosts_override</EM> set. Now all the addresses can be
batched up and sent to the transport together.
</font>

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


<H3><A NAME="SEC694" HREF="spec_toc.html#TOC694">modemask (domainlist)</A></H3>

<P>
Type: octal integer<BR>
Default: 022

</P>
<P>
This specifies mode bits which must not be set for the route file.
If they are set, delivery is deferred and the message is frozen.

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


<H3><A NAME="SEC695" HREF="spec_toc.html#TOC695">owners (domainlist)</A></H3>

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

</P>
<P>
This specifies a list of permitted owners for the route file. If it is unset,
no check on the ownership is done. If the file is not owned by a user in the
list, delivery is deferred and the message is frozen.

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


<H3><A NAME="SEC696" HREF="spec_toc.html#TOC696">owngroups (domainlist)</A></H3>

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

</P>
<P>
This specifies a list of permitted groups for the route file. If it is unset,
no check on the file's group is done. If the file's group is not in the list,
delivery is deferred and the message is frozen.

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


<H3><A NAME="SEC697" HREF="spec_toc.html#TOC697">qualify_single (domainlist)</A></H3>

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

</P>
<P>
For any domain that is looked up in the DNS, the resolver option that causes it
to qualify single-component names with the default domain (RES_DEFNAMES)
is set. For example, on a machine called <EM>dictionary.ref.book</EM>, looking up the
domain <EM>thesaurus</EM> would cause the name <EM>thesaurus.ref.book</EM> to be looked up.

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


<H3><A NAME="SEC698" HREF="spec_toc.html#TOC698">route_file (domainlist)</A></H3>

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

</P>
<P>
If this option is set, <EM>search_type</EM> must be set to one of the single-key
lookup types, and <EM>route_query</EM> must not be set. See chapter 6
for details of file and database lookups. The domain being routed is used as
the key for the lookup, and the resulting data must be a
<font color=green>
routing rule,
</font>
in the form described below. The file name is expanded before use.

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


<H3><A NAME="SEC699" HREF="spec_toc.html#TOC699">route_list (domainlist)</A></H3>

<P>
Type: string list, semicolon-separated<BR>
Default: unset

</P>
<P>
This string is a list of routing rules, in the form defined below. Note that,
unlike most string lists, the items are separated by semicolons. This is so
that they may contain colon-separated host lists. The list is not expanded as a
whole, but host lists within it are expanded during processing.

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


<H3><A NAME="SEC700" HREF="spec_toc.html#TOC700">route_queries (domainlist)</A></H3>

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

</P>
<P>
This option is an alternative to <EM>route_query</EM>; the two options are mutually
exclusive. The difference is that <EM>route_queries</EM> contains a colon-separated
list of queries, which are tried in order until one succeeds or defers, or all
fail. Any colon characters actually required in an individual query must be
doubled, in order that they not be treated as query separators.

</P>

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


<H3><A NAME="SEC701" HREF="spec_toc.html#TOC701">route_query (domainlist)</A></H3>

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

</P>
<P>
If this option is set, <EM>search_type</EM> must be set to a query-style lookup type,
and <EM>route_file</EM> must not be set. See chapter 6 for details of
file and database lookups. The query is expanded before use, and the expansion
variable $<EM>domain</EM> contains the domain being routed. The data returned from the
lookup must be a
<font color=green>
routing rule,
</font>
in the form described below.

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


<H3><A NAME="SEC702" HREF="spec_toc.html#TOC702">search_parents (domainlist)</A></H3>

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

</P>
<P>
For any domain that is looked up in the DNS, the resolver option that causes it
to search parent domains (RES_DNSRCH) is set if this option is true. This
is different from the <EM>qualify_single</EM> option in that it applies to domains
containing dots. For example, on a machine in the <EM>fict.book</EM> domain, when
looking up <EM>teaparty.wonderland</EM> initially fails, the resolver automatically
tries <EM>teaparty.wonderland.fict.book</EM> if this option is set.

</P>

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


<H3><A NAME="SEC703" HREF="spec_toc.html#TOC703">search_type (domainlist)</A></H3>

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

</P>
<P>
This option is mandatory when <EM>route_file</EM>, <EM>route_query</EM>, or
<EM>route_queries</EM> is specified. It must be set to one of the supported search
types (for example, <EM>lsearch</EM>). See chapter 6.

</P>
<P>
<A NAME="IDX1608"></A>
<A NAME="IDX1609"></A>
For single-file lookups, the name may be preceded by <TT>`partial-'</TT>, indicating
a simple wildcard file lookup that works as follows:

</P>

<OL>

<LI>

Exim first tries to look up the domain exactly as given.

<LI>

If that fails, it adds `*.' on the front of the domain, and looks that up.

<LI>

If that fails, it replaces the first component of the domain with `*' and
tries that, and continues chopping off components in this way until either the
lookup succeeds, or there are fewer than two non-* components left.
</OL>

<P>
Thus, for example, if you put an entry keyed by <TT>`*.austen.fict.film'</TT> in your
database, that entry will be used for

</P>

<OL>

<LI>

<EM>austen.fict.film</EM> by rule (b) above, having failed on rule (a). (If you are
worried about the resource waste implied by this, you can always add an entry
for <EM>austen.fict.film</EM> as well.)

<LI>

<EM>emma.austen.fict.film</EM> at the first attempt in rule (c), having failed on
rules (a) and (b).
</OL>

<P>
A domain such as <TT>`jane.fict.film'</TT> will fail, having tried 3 lookups:
<TT>`jane.fict.film'</TT>, <TT>`*.jane.fict.film'</TT>, <TT>`*.fict.film'</TT>, but it won't waste
effort looking up <TT>`*.film'</TT> because that has only one non-* component. In
fact, the minimum number of components can be altered by including a number
immediately before the hyphen. For example, `partial4-dbm' specifies a minimum
of four non-* components.

</P>



<H2><A NAME="SEC704" HREF="spec_toc.html#TOC704">28.1 Routing rules</A></H2>

<P>
Routing rules specified in <EM>route_list</EM> are scanned before <EM>route_file</EM>,
<EM>route_query</EM> or <EM>route_queries</EM> are used. The contents of <EM>route_list</EM> is a
string consisting of a sequence of routing rules, separated by semicolons. If a
semicolon is needed in a rule, it can be entered as two semicolons. Empty
rules are ignored. The format of each rule is

<PRE>
&#60;<EM>domain pattern</EM>&#62;  &#60;<EM>host list</EM>&#62;  &#60;<EM>options</EM>&#62;
</PRE>

<P>
The following example contains a simple domain pattern and just one rule:

<PRE>
route_list = dict.ref.book mail-1.ref.book:mail-2.ref.book byname
</PRE>

<P>
The three parts of a rule are separated by white space. Each rule in a
<EM>route_list</EM> must start with a single domain pattern, which is the only
mandatory item in the rule. The pattern is in the same format as one item in a
domain list (see section 7.12), that is, it may be wildcarded or a
regular expression, or a file or database lookup
(with semicolons doubled, because of the use of semicolon as a separator in a
<EM>route_list</EM>).
The rules in <EM>route_list</EM> are searched in order until one of the patterns
matches the domain that is being routed. The host list and options are then
used as described below.

</P>
<P>
If no rule in <EM>route_list</EM> matches the domain, it is used as the key for
a lookup of the type specified by <EM>search_type</EM>, using <EM>route_file</EM>,
<EM>route_query</EM>, or <EM>route_queries</EM>, as appropriate. The data returned from a
successful lookup must be a string containing a host list and options,
separated by white space. For example, a line in a linearly searched route file
might be:

<PRE>
dict.ref.book:  mail-1.ref.book:mail-2.ref.book  byname
</PRE>

<P>
Note that there are two different uses of the colon character in this line. The
first one is the delimiter of the key in the file, while the second is the
normal list delimiter in the host list, which in this example consists of two
host names. As both the host list and the options are not compulsory in a
rule, the data returned from a lookup can legitimately be an empty string in
some circumstances (see <EM>Application of routing rules</EM> below).

</P>
<P>
If the domain does not match anything in <EM>route_list</EM> and looking it up using
<EM>route_file</EM>, <EM>route_query</EM> or <EM>route_queries</EM> also fails, the router
declines to handle the address, and it gets passed on to the next router, unless
<EM>no_more</EM> is set.

</P>


<H2><A NAME="SEC705" HREF="spec_toc.html#TOC705">28.2 Host list format</A></H2>

<P>
If a host list is present in the rule which matches the domain, it is expanded
before use.
<A NAME="IDX1610"></A>
If the pattern that matched the domain was a lookup item, the data that was
looked up is available in the expansion variable $<EM>value</EM>.

</P>
<P>
The result of the expansion must be a colon-separated list of host names and/or
IP addresses. Some string expansion items may contain white space, and if this
is the case, the host list must be enclosed in single or double quotes, because
otherwise white space terminates it. The numeric expansion variables are
available during host list expansion. These are mainly used when the domain is
matched against a regular expression domain pattern in a <EM>route_list</EM> string,
but $<EM>1</EM> is also set when partial matching is done in a file lookup, and $<EM>0</EM>
is always set to the entire domain.

</P>
<P>
The value of $<EM>domain</EM> is the original domain for the address. This may differ
from $<EM>0</EM> if the address has been processed by a previous <EM>domainlist</EM> router
which passed on a different routing domain.

</P>
<P>
If the expansion of the host list is forced to fail (by using the `fail' item
in a conditional construction), the router just declines to handle the address,
and (unless <EM>no_more</EM> is set) it gets passed on to the next router. If
expansion fails for some other reason, the message is frozen, since this
is considered to be a configuration error.

</P>



<H2><A NAME="SEC706" HREF="spec_toc.html#TOC706">28.3 Options format</A></H2>

<P>
Options can be present only if there is a host list. They are a sequence of
words, but in practice no more than two are ever present. One of the words can
be the name of one of the configured transports, and this overrides the
<EM>transport</EM> option on the router for this particular routing rule only.
The other word (if present) specifies how the IP addresses of the hosts in the
host list are to be found:

</P>

<UL>

<LI>

<EM>byname</EM>: use <EM>gethostbyname()</EM>, or use literal IP addresses if present.
Literal IP addresses are written without any surrounding square brackets.

<LI>

<EM>bydns</EM>: use the DNS, doing the full MX and A record processing.

<LI>

<EM>bydns_a</EM>: look up A records for the host(s) in the DNS; fail if there are
none.

<LI>

<EM>bydns_mx</EM>: look up MX records for the host(s) in the DNS; fail if there are
none.
</UL>

<P>
The <EM>qualify_single</EM> and <EM>search_parents</EM> options apply to any DNS lookups
that are done.
If no IP address for a host can be found, what happens is controlled by the
<EM>host_find_failed</EM> option.

</P>



<H2><A NAME="SEC707" HREF="spec_toc.html#TOC707">28.4 Application of routing rules</A></H2>

<P>
When a rule has been found that matches the current domain, either by matching
one of the rules in <EM>route_list</EM>, or by a successful lookup in <EM>route_file</EM>
or using <EM>route_query</EM> or <EM>route_queries</EM>, the host list and options are used
in a number of different ways, depending on which are present and on whether a
transport has been specified.

</P>

<UL>

<LI>

If there is no host list (and therefore necessarily no options either), a
local transport (that is, not an SMTP transport) must be specified for the
router via the generic <EM>transport</EM> option,
unless the driver is being used only for verification (<EM>verify_only</EM> is set).
In this case, if there is no transport and no host list, the address is taken
as verified. Otherwise, failure to specify a local transport in the absence of
a host list
is a configuration error. The address is routed to the transport. In all other
cases, a host list must be provided.

<LI>

If there is a host list, and a local transport is specified either by the
generic <EM>transport</EM> option, or by an option item in the rule, the host
list must contain just a single host name which is passed to the transport in
the $<EM>host</EM> variable. Any <EM>by<EM>xxx</EM></EM> options are ignored.

<LI>

If no <EM>by<EM>xxx</EM></EM> option is present, any remote transport setting is
ignored, and there must be just one name in the host list. The address is
passed on to the next router,
<font color=green>
overriding <EM>no_more</EM>,
</font>
with the domain being routed being replaced by the name from the host list.
However if the expansion variable $<EM>domain</EM> is used in any subsequent router,
it still refers to the original domain.

<LI>

Otherwise, a remote (that is, SMTP) transport must be specified,
unless the driver is being used only for verification (<EM>verify_only</EM> is set),
<font color=green>
or the routing rule specifies the local host, and the generic <EM>self</EM> option is
set to something other than `send'.
</font>

The transport is specified either via the generic <EM>transport</EM> option or by a
transport name as an option setting, and there may be many hosts in the list.
Their IP addresses are looked up according to the <EM>by<EM>xxx</EM></EM> option. If any
of them are found to be the local host, that one and all those that follow it
are discarded. If the first host is found to be the local host, the generic
<EM>self</EM> option specifies what happens. Otherwise, the address is passed to the
specified transport, along with the ordered list of hosts. The transport will
try delivering to each host in turn, until one accepts the message.

<font color=green>
If the attempt to look an IP address for a host fails, the <EM>host_find_failed</EM>
option controls what happens.
</font>
</UL>

<P>
The various different possibilities for configuring the <EM>domainlist</EM> router
make it possible to use it for a number of different routing requirements, as
shown in the examples in the next section.

</P>



<H2><A NAME="SEC708" HREF="spec_toc.html#TOC708">28.5 Domainlist examples</A></H2>

<P>
In some of the examples that follow, the presence of the <EM>remote_smtp</EM>
transport, as defined in the default configuration file, is assumed.

</P>


<UL>

<LI>

<A NAME="IDX1611"></A>
<A NAME="IDX1612"></A>
<A NAME="IDX1613"></A>
Routing to a gateway to another mail environment can be set up using a
wildcarded domain pattern that matches some pseudo top-level domain. For
example, to route certain addresses to UUCP and Bitnet gateways:

<PRE>
uucp_bitnet:
  driver = domainlist
  route_list = *.uucp   uugateway.fict.book; \
               *.bitnet bngateway.ref.book
</PRE>

The two rules match domains ending in <EM>.uucp</EM> and <EM>.bitnet</EM> respectively, and
because no options or transport are specified in either case, the name of the
appropriate gateway domain is taken from the host list and passed to
subsequent routers for further routing. So, for example, mail addressed to
<EM>user@faraway.uucp</EM> is routed by applying subsequent routers to the domain
<EM>uugateway.fict.book</EM> to determine where to send it.

If there are two hosts servicing one of these domains and they are not
connected to a single domain name (by MX records for example), you may want to
quote two names in the host list portion of a rule. In this case, you have to
specify one of the <EM>by<EM>xxx</EM></EM> options, to get the names looked up by
<EM>domainlist</EM>, since it can pass on only a single domain name to other routers.
A transport must also be provided:

<PRE>
uucp:
  driver = domainlist
  transport = remote_smtp
  route_list = \
    *.uucp uugate1.fict.book:uugate2.fict.book byname
</PRE>

In this case, no further routers are called.

<LI>

<A NAME="IDX1614"></A>
<A NAME="IDX1615"></A>
A host that is itself a gateway can `deliver' messages to pipes or into
files in batched SMTP format for onward transportation by some other means. In
this case, the route list entry can be as simple as a single domain name in a
configuration like this:

<PRE>
route_append:
  driver = domainlist
  transport = batchsmtp_appendfile
  route_list = gated.domain
</PRE>

though often a pattern is used to pick up more than one domain. If there are
several domains or groups of domains with different transport requirements,
different transports can be listed in the routing information:

<PRE>
route_append:
  driver = domainlist
  route_list = \
    *.gated.domain1  $domain  batch_appendfile; \
    *.gated.domain2  \
      ${lookup{$domain}dbm{/domain2/hosts}{$value}fail} \
      batch_pipe
</PRE>

The first of these just passes the domain in the $<EM>host</EM> variable, which
doesn't achieve much (since it is also in $<EM>domain</EM>) but the second does a
file lookup to find a value to pass, causing the router to decline to handle the
address if the lookup fails.

<LI>

<A NAME="IDX1616"></A>
Routing mail directly to UUCP software is a specific case of the use of
<EM>domainlist</EM> in a gateway to another mail environment. This is an example of
one way it can be done, taken from a real configuration:

<PRE>
# Transport
uucp:
  driver = pipe
  user = nobody
  command = /usr/local/bin/uux -r - \
    ${substr_-5:$host}!rmail ${local_part}
  return_fail_output = true
</PRE>


<PRE>
# Router
uucphost:
  transport = uucp
  driver = domainlist
  route_file = /usr/local/exim/uucphosts
  search_type = lsearch
</PRE>

The file <EM>/usr/local/exim/uucphosts</EM> contains entries like

<PRE>
darksite.ethereal.ru:           darksite.UUCP
</PRE>

It can be set up more simply without adding and removing `.UUCP' but this way
makes clear the distinction between the domain name <EM>darksite.ethereal.ru</EM> and
the UUCP host name <EM>darksite</EM>.

<LI>

<A NAME="IDX1617"></A>
<A NAME="IDX1618"></A>
A <EM>mail hub</EM> is a machine which receives mail for a number of domains via MX
records in the DNS and delivers it via its own private routing mechanism. Often
the final destinations are behind a firewall, with the mail hub being the one
machine that can connect to machines both inside and outside the firewall. The
<EM>domainlist</EM> router can be set up for this kind of purpose:

<PRE>
through_firewall:
  driver = domainlist
  transport = remote_smtp
  route_file = /internal/host/routes
  search_type = lsearch
</PRE>

For a small number of cases, the routing could be inline, using the
<EM>route_list</EM> option, but for a larger number a file lookup would be easier to
manage, and the file containing the internal routing might contain lines like
this:

<PRE>
dict.ref.book:  mail-1.ref.book:mail-2.ref.book  byname
</PRE>

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

If the domain names are in fact the names of the machines to which the mail is
to be sent by the mail hub, the configuration can be quite simple. For
example,

<PRE>
hub_route:
  driver = domainlist
  transport = remote_smtp
  route_list = *.rhodes.tvs  $domain  byname
</PRE>

This configuration routes domains that match <TT>`*.rhodes.tvs'</TT> by calling
<EM>gethostbyname()</EM> on the domain that matched. A similar approach can be taken if
the host name can be obtained from the domain name by simple manipulation that
the expansion facilities can handle.

<LI>

<A NAME="IDX1619"></A>
The <EM>domainlist</EM> router can also be used to forward all non-local mail to a
<EM>smart host</EM> by using a configuration like

<PRE>
smart_route:
  driver = domainlist
  transport = remote_smtp
  route_list = *  smarthost.ref.book  bydns_a
</PRE>

which causes all messages containing remote addresses to be sent to the single
host <EM>smarthost.ref.book</EM>, whose address (in this example) is obtained from its
DNS address record. If a colon-separated list of smart hosts is given, they are
tried in order. A router like this should be the last one in the configuration
file, since it will route any domain whatsoever.

<LI>

A <EM>domainlist</EM> router can be used to force success or failure on verification
of remote addresses by setting <EM>verify_only</EM> (and <EM>verify_sender</EM> or
<EM>verify_recipient</EM> if required). If failure is wanted, set <EM>fail_verify</EM>. No
transports or hosts need be defined.
</UL>

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