<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html401/loose.dtd">
<html>
<!-- Created on September, 10 2009 by texi2html 1.78 -->
<!--
Written by: Lionel Cons <Lionel.Cons@cern.ch> (original author)
Karl Berry <karl@freefriends.org>
Olaf Bachmann <obachman@mathematik.uni-kl.de>
and many others.
Maintained by: Many creative people.
Send bugs and suggestions to <texi2html-bug@nongnu.org>
-->
<head>
<title>Specification of the Exim Mail Transfer Agent: 10. Domain, host, address, and local part lists</title>
<meta name="description" content="Specification of the Exim Mail Transfer Agent: 10. Domain, host, address, and local part lists">
<meta name="keywords" content="Specification of the Exim Mail Transfer Agent: 10. Domain, host, address, and local part lists">
<meta name="resource-type" content="document">
<meta name="distribution" content="global">
<meta name="Generator" content="texi2html 1.78">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css">
<!--
a.summary-letter {text-decoration: none}
pre.display {font-family: serif}
pre.format {font-family: serif}
pre.menu-comment {font-family: serif}
pre.menu-preformatted {font-family: serif}
pre.smalldisplay {font-family: serif; font-size: smaller}
pre.smallexample {font-size: smaller}
pre.smallformat {font-family: serif; font-size: smaller}
pre.smalllisp {font-size: smaller}
span.roman {font-family:serif; font-weight:normal;}
span.sansserif {font-family:sans-serif; font-weight:normal;}
ul.toc {list-style: none}
-->
</style>
</head>
<body lang="en" bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#800080" alink="#FF0000">
<a name="Domain_003b-host_003b-and-address-lists"></a>
<a name="SEC115"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="spec_9.html#SEC114" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC116" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec_9.html#SEC89" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_11.html#SEC137" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<h1 class="chapter"> 10. Domain, host, address, and local part lists </h1>
<p>A number of Exim configuration options contain lists of domains, hosts,
email addresses, or local parts. For example, the <code>hold_domains</code> option
contains a list of domains whose delivery is currently suspended. These lists
are also used as data in ACL statements (see chapter <a href="spec_40.html#SEC308">Access control lists</a>), and as
arguments to expansion conditions such as <code>match_domain</code>.
</p>
<p>Each item in one of these lists is a pattern to be matched against a domain,
host, email address, or local part, respectively. In the sections below, the
different types of pattern for each case are described, but first we cover some
general facilities that apply to all four kinds of list.
</p>
<table class="menu" border="0" cellspacing="0">
<tr><td align="left" valign="top"><a href="#SEC116">10.1 Expansion of lists</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC117">10.2 Negated items in lists</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC118">10.3 File names in lists</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC119">10.4 An lsearch file is not an out-of-line list</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC120">10.5 Named lists</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC121">10.6 Named lists compared with macros</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC122">10.7 Named list caching</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC123">10.8 Domain lists</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC124">10.9 Host lists</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC125">10.10 Special host list patterns</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC126">10.11 Host list patterns that match by IP address</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC127">10.12 Host list patterns for single-key lookups by host address</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC128">10.13 Host list patterns that match by host name</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC129">10.14 Behaviour when an IP address or name cannot be found</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC130">10.15 Temporary DNS errors when looking up host information</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC131">10.16 Host list patterns for single-key lookups by host name</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC132">10.17 Host list patterns for query-style lookups</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC133">10.18 Mixing wildcarded host names and addresses in host lists</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC134">10.19 Address lists</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC135">10.20 Case of letters in address lists</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC136">10.21 Local part lists</a></td><td> </td><td align="left" valign="top">
</td></tr>
</table>
<hr size="6">
<a name="Expansion-of-lists"></a>
<a name="SEC116"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC115" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC117" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC115" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC115" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_11.html#SEC137" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<h2 class="section"> 10.1 Expansion of lists </h2>
<p>Each list is expanded as a single string before it is used. The result of
expansion must be a list, possibly containing empty items, which is split up
into separate items for matching. By default, colon is the separator character,
but this can be varied if necessary. See sections <a href="spec_6.html#SEC75">List construction</a> and
<a href="spec_6.html#SEC77">Empty items in lists</a> for details of the list syntax; the second of these
discusses the way to specify empty list items.
</p>
<p>If the string expansion is forced to fail, Exim behaves as if the item it is
testing (domain, host, address, or local part) is not in the list. Other
expansion failures cause temporary errors.
</p>
<p>If an item in a list is a regular expression, backslashes, dollars and possibly
other special characters in the expression must be protected against
misinterpretation by the string expander. The easiest way to do this is to use
the ‘<samp>\N</samp>’ expansion feature to indicate that the contents of the regular
expression should not be expanded. For example, in an ACL you might have:
</p>
<table><tr><td> </td><td><pre class="example">deny senders = \N^\d{8}\w@.*\.baddomain\.example$\N : \
${lookup{$domain}lsearch{/badsenders/bydomain}}
</pre></td></tr></table>
<p>The first item is a regular expression that is protected from expansion by
‘<samp>\N</samp>’, whereas the second uses the expansion to obtain a list of unwanted
senders based on the receiving domain.
</p>
<hr size="6">
<a name="Negated-items-in-lists"></a>
<a name="SEC117"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC116" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC118" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC115" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC115" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_11.html#SEC137" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<h2 class="section"> 10.2 Negated items in lists </h2>
<p>Items in a list may be positive or negative. Negative items are indicated by a
leading exclamation mark, which may be followed by optional white space. A list
defines a set of items (domains, etc). When Exim processes one of these lists,
it is trying to find out whether a domain, host, address, or local part
(respectively) is in the set that is defined by the list. It works like this:
</p>
<p>The list is scanned from left to right. If a positive item is matched, the
subject that is being checked is in the set; if a negative item is matched, the
subject is not in the set. If the end of the list is reached without the
subject having matched any of the patterns, it is in the set if the last item
was a negative one, but not if it was a positive one. For example, the list in
</p>
<table><tr><td> </td><td><pre class="example">domainlist relay_domains = !a.b.c : *.b.c
</pre></td></tr></table>
<p>matches any domain ending in <em>.b.c</em> except for <em>a.b.c</em>. Domains that match
neither <em>a.b.c</em> nor <em>*.b.c</em> do not match, because the last item in the
list is positive. However, if the setting were
</p>
<table><tr><td> </td><td><pre class="example">domainlist relay_domains = !a.b.c
</pre></td></tr></table>
<p>then all domains other than <em>a.b.c</em> would match because the last item in the
list is negative. In other words, a list that ends with a negative item behaves
as if it had an extra item ‘<samp>:*</samp>’ on the end.
</p>
<p>Another way of thinking about positive and negative items in lists is to read
the connector as "or" after a positive item and as "and" after a negative
item.
</p>
<hr size="6">
<a name="File-names-in-lists"></a>
<a name="SEC118"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC117" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC119" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC115" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC115" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_11.html#SEC137" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<h2 class="section"> 10.3 File names in lists </h2>
<p>If an item in a domain, host, address, or local part list is an absolute file
name (beginning with a slash character), each line of the file is read and
processed as if it were an independent item in the list, except that further
file names are not allowed,
and no expansion of the data from the file takes place.
Empty lines in the file are ignored, and the file may also contain comment
lines:
</p>
<ul class="toc">
<li>
For domain and host lists, if a # character appears anywhere in a line of the
file, it and all following characters are ignored.
</li><li>
Because local parts may legitimately contain # characters, a comment in an
address list or local part list file is recognized only if # is preceded by
white space or the start of the line. For example:
<table><tr><td> </td><td><pre class="example">not#comment@x.y.z # but this is a comment
</pre></td></tr></table>
</li></ul>
<p>Putting a file name in a list has the same effect as inserting each line of the
file as an item in the list (blank lines and comments excepted). However, there
is one important difference: the file is read each time the list is processed,
so if its contents vary over time, Exim's behaviour changes.
</p>
<p>If a file name is preceded by an exclamation mark, the sense of any match
within the file is inverted. For example, if
</p>
<table><tr><td> </td><td><pre class="example">hold_domains = !/etc/nohold-domains
</pre></td></tr></table>
<p>and the file contains the lines
</p>
<table><tr><td> </td><td><pre class="example">!a.b.c
*.b.c
</pre></td></tr></table>
<p>then <em>a.b.c</em> is in the set of domains defined by <code>hold_domains</code>, whereas
any domain matching ‘<samp>*.b.c</samp>’ is not.
</p>
<hr size="6">
<a name="An-lsearch-file-is-not-an-out_002dof_002dline-list"></a>
<a name="SEC119"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC118" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC120" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC115" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC115" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_11.html#SEC137" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<h2 class="section"> 10.4 An lsearch file is not an out-of-line list </h2>
<p>As will be described in the sections that follow, lookups can be used in lists
to provide indexed methods of checking list membership. There has been some
confusion about the way <code>lsearch</code> lookups work in lists. Because
an <code>lsearch</code> file contains plain text and is scanned sequentially, it is
sometimes thought that it is allowed to contain wild cards and other kinds of
non-constant pattern. This is not the case. The keys in an <code>lsearch</code> file are
always fixed strings, just as for any other single-key lookup type.
</p>
<p>If you want to use a file to contain wild-card patterns that form part of a
list, just give the file name on its own, without a search type, as described
in the previous section. You could also use the <code>wildlsearch</code> or
<code>nwildlsearch</code>, but there is no advantage in doing this.
</p>
<hr size="6">
<a name="Named-lists"></a>
<a name="SEC120"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC119" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC121" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC115" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC115" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_11.html#SEC137" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<h2 class="section"> 10.5 Named lists </h2>
<p>A list of domains, hosts, email addresses, or local parts can be given a name
which is then used to refer to the list elsewhere in the configuration. This is
particularly convenient if the same list is required in several different
places. It also allows lists to be given meaningful names, which can improve
the readability of the configuration. For example, it is conventional to define
a domain list called <em>local_domains</em> for all the domains that are handled
locally on a host, using a configuration line such as
</p>
<table><tr><td> </td><td><pre class="example">domainlist local_domains = localhost:my.dom.example
</pre></td></tr></table>
<p>Named lists are referenced by giving their name preceded by a plus sign, so,
for example, a router that is intended to handle local domains would be
configured with the line
</p>
<table><tr><td> </td><td><pre class="example">domains = +local_domains
</pre></td></tr></table>
<p>The first router in a configuration is often one that handles all domains
except the local ones, using a configuration with a negated item like this:
</p>
<table><tr><td> </td><td><pre class="example">dnslookup:
driver = dnslookup
domains = ! +local_domains
transport = remote_smtp
no_more
</pre></td></tr></table>
<p>The four kinds of named list are created by configuration lines starting with
the words <code>domainlist</code>, <code>hostlist</code>, <code>addresslist</code>, or <code>localpartlist</code>,
respectively. Then there follows the name that you are defining, followed by an
equals sign and the list itself. For example:
</p>
<table><tr><td> </td><td><pre class="example">hostlist relay_hosts = 192.168.23.0/24 : my.friend.example
addresslist bad_senders = cdb;/etc/badsenders
</pre></td></tr></table>
<p>A named list may refer to other named lists:
</p>
<table><tr><td> </td><td><pre class="example">domainlist dom1 = first.example : second.example
domainlist dom2 = +dom1 : third.example
domainlist dom3 = fourth.example : +dom2 : fifth.example
</pre></td></tr></table>
<p><strong>Warning</strong>: If the last item in a referenced list is a negative one, the
effect may not be what you intended, because the negation does not propagate
out to the higher level. For example, consider:
</p>
<table><tr><td> </td><td><pre class="example">domainlist dom1 = !a.b
domainlist dom2 = +dom1 : *.b
</pre></td></tr></table>
<p>The second list specifies "either in the <code>dom1</code> list or <em>*.b</em>". The first
list specifies just "not <em>a.b</em>", so the domain <em>x.y</em> matches it. That
means it matches the second list as well. The effect is not the same as
</p>
<table><tr><td> </td><td><pre class="example">domainlist dom2 = !a.b : *.b
</pre></td></tr></table>
<p>where <em>x.y</em> does not match. It's best to avoid negation altogether in
referenced lists if you can.
</p>
<p>Named lists may have a performance advantage. When Exim is routing an
address or checking an incoming message, it caches the result of tests on named
lists. So, if you have a setting such as
</p>
<table><tr><td> </td><td><pre class="example">domains = +local_domains
</pre></td></tr></table>
<p>on several of your routers
or in several ACL statements,
the actual test is done only for the first one. However, the caching works only
if there are no expansions within the list itself or any sublists that it
references. In other words, caching happens only for lists that are known to be
the same each time they are referenced.
</p>
<p>By default, there may be up to 16 named lists of each type. This limit can be
extended by changing a compile-time variable. The use of domain and host lists
is recommended for concepts such as local domains, relay domains, and relay
hosts. The default configuration is set up like this.
</p>
<hr size="6">
<a name="Named-lists-compared-with-macros"></a>
<a name="SEC121"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC120" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC122" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC115" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC115" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_11.html#SEC137" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<h2 class="section"> 10.6 Named lists compared with macros </h2>
<p>At first sight, named lists might seem to be no different from macros in the
configuration file. However, macros are just textual substitutions. If you
write
</p>
<table><tr><td> </td><td><pre class="example">ALIST = host1 : host2
auth_advertise_hosts = !ALIST
</pre></td></tr></table>
<p>it probably won't do what you want, because that is exactly the same as
</p>
<table><tr><td> </td><td><pre class="example">auth_advertise_hosts = !host1 : host2
</pre></td></tr></table>
<p>Notice that the second host name is not negated. However, if you use a host
list, and write
</p>
<table><tr><td> </td><td><pre class="example">hostlist alist = host1 : host2
auth_advertise_hosts = ! +alist
</pre></td></tr></table>
<p>the negation applies to the whole list, and so that is equivalent to
</p>
<table><tr><td> </td><td><pre class="example">auth_advertise_hosts = !host1 : !host2
</pre></td></tr></table>
<hr size="6">
<a name="Named-list-caching"></a>
<a name="SEC122"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC121" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC123" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC115" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC115" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_11.html#SEC137" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<h2 class="section"> 10.7 Named list caching </h2>
<p>While processing a message, Exim caches the result of checking a named list if
it is sure that the list is the same each time. In practice, this means that
the cache operates only if the list contains no $ characters, which guarantees
that it will not change when it is expanded. Sometimes, however, you may have
an expanded list that you know will be the same each time within a given
message. For example:
</p>
<table><tr><td> </td><td><pre class="example">domainlist special_domains = \
${lookup{$sender_host_address}cdb{/some/file}}
</pre></td></tr></table>
<p>This provides a list of domains that depends only on the sending host's IP
address. If this domain list is referenced a number of times (for example,
in several ACL lines, or in several routers) the result of the check is not
cached by default, because Exim does not know that it is going to be the
same list each time.
</p>
<p>By appending ‘<samp>_cache</samp>’ to ‘<samp>domainlist</samp>’ you can tell Exim to go ahead and
cache the result anyway. For example:
</p>
<table><tr><td> </td><td><pre class="example">domainlist_cache special_domains = ${lookup{...
</pre></td></tr></table>
<p>If you do this, you should be absolutely sure that caching is going to do
the right thing in all cases. When in doubt, leave it out.
</p>
<hr size="6">
<a name="Domain-lists"></a>
<a name="SEC123"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC122" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC124" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC115" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC115" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_11.html#SEC137" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<h2 class="section"> 10.8 Domain lists </h2>
<p>Domain lists contain patterns that are to be matched against a mail domain.
The following types of item may appear in domain lists:
</p>
<ul class="toc">
<li>
<a name="IDX579"></a>
<a name="IDX580"></a>
<a name="IDX581"></a>
<a name="IDX582"></a>
<a name="IDX583"></a>
If a pattern consists of a single @ character, it matches the local host name,
as set by the <code>primary_hostname</code> option (or defaulted). This makes it
possible to use the same configuration file on several different hosts that
differ only in their names.
</li><li>
<a name="IDX584"></a>
<a name="IDX585"></a>
<a name="IDX586"></a>
If a pattern consists of the string ‘<samp>@[]</samp>’ it matches an IP address enclosed
in square brackets (as in an email address that contains a domain literal), but
only if that IP address is recognized as local for email routing purposes. The
<code>local_interfaces</code> and <code>extra_local_interfaces</code> options can be used to
control which of a host's several IP addresses are treated as local.
In today's Internet, the use of domain literals is controversial.
</li><li>
<a name="IDX587"></a>
<a name="IDX588"></a>
<a name="IDX589"></a>
<a name="IDX590"></a>
If a pattern consists of the string ‘<samp>@mx_any</samp>’ it matches any domain that
has an MX record pointing to the local host or to any host that is listed in
<a name="IDX591"></a>
<code>hosts_treat_as_local</code>. The items ‘<samp>@mx_primary</samp>’ and ‘<samp>@mx_secondary</samp>’
are similar, except that the first matches only when a primary MX target is the
local host, and the second only when no primary MX target is the local host,
but a secondary MX target is. "Primary" means an MX record with the lowest
preference value - there may of course be more than one of them.
<p>The MX lookup that takes place when matching a pattern of this type is
performed with the resolver options for widening names turned off. Thus, for
example, a single-component domain will <em>not</em> be expanded by adding the
resolver's default domain. See the <code>qualify_single</code> and <code>search_parents</code>
options of the <code>dnslookup</code> router for a discussion of domain widening.
</p>
<p>Sometimes you may want to ignore certain IP addresses when using one of these
patterns. You can specify this by following the pattern with ‘<samp>/ignore=</samp>’<<em>ip
list</em>>, where <<em>ip list</em>> is a list of IP addresses. These addresses are
ignored when processing the pattern (compare the <code>ignore_target_hosts</code> option
on a router). For example:
</p>
<table><tr><td> </td><td><pre class="example">domains = @mx_any/ignore=127.0.0.1
</pre></td></tr></table>
<p>This example matches any domain that has an MX record pointing to one of
the local host's IP addresses other than 127.0.0.1.
</p>
<p>The list of IP addresses is in fact processed by the same code that processes
host lists, so it may contain CIDR-coded network specifications and it may also
contain negative items.
</p>
<p>Because the list of IP addresses is a sublist within a domain list, you have to
be careful about delimiters if there is more than one address. Like any other
list, the default delimiter can be changed. Thus, you might have:
</p>
<table><tr><td> </td><td><pre class="example">domains = @mx_any/ignore=<;127.0.0.1;0.0.0.0 : \
an.other.domain : ...
</pre></td></tr></table>
<p>so that the sublist uses semicolons for delimiters. When IPv6 addresses are
involved, it is easiest to change the delimiter for the main list as well:
</p>
<table><tr><td> </td><td><pre class="example">domains = <? @mx_any/ignore=<;127.0.0.1;::1 ? \
an.other.domain ? ...
</pre></td></tr></table>
</li><li>
<a name="IDX592"></a>
<a name="IDX593"></a>
<a name="IDX594"></a>
If a pattern starts with an asterisk, the remaining characters of the pattern
are compared with the terminating characters of the domain. The use of "*" in
domain lists differs from its use in partial matching lookups. In a domain
list, the character following the asterisk need not be a dot, whereas partial
matching works only in terms of dot-separated components. For example, a domain
list item such as ‘<samp>*key.ex</samp>’ matches <em>donkey.ex</em> as well as
<em>cipher.key.ex</em>.
</li><li>
<a name="IDX595"></a>
<a name="IDX596"></a>
If a pattern starts with a circumflex character, it is treated as a regular
expression, and matched against the domain using a regular expression matching
function. The circumflex is treated as part of the regular expression.
Email domains are case-independent, so this regular expression match is by
default case-independent, but you can make it case-dependent by starting it
with ‘<samp>(?-i)</samp>’. References to descriptions of the syntax of regular expressions
are given in chapter <a href="spec_8.html#SEC87">Regular expressions</a>.
<p><strong>Warning</strong>: Because domain lists are expanded before being processed, you
must escape any backslash and dollar characters in the regular expression, or
use the special ‘<samp>\N</samp>’ sequence (see chapter <a href="spec_11.html#SEC137">String expansions</a>) to specify that
it is not to be expanded (unless you really do want to build a regular
expression by expansion, of course).
</p>
</li><li>
<a name="IDX597"></a>
<a name="IDX598"></a>
If a pattern starts with the name of a single-key lookup type followed by a
semicolon (for example, "dbm;" or "lsearch;"), the remainder of the pattern
must be a file name in a suitable format for the lookup type. For example, for
"cdb;" it must be an absolute path:
<table><tr><td> </td><td><pre class="example">domains = cdb;/etc/mail/local_domains.cdb
</pre></td></tr></table>
<p>The appropriate type of lookup is done on the file using the domain name as the
key. In most cases, the data that is looked up is not used; Exim is interested
only in whether or not the key is present in the file. However, when a lookup
is used for the <code>domains</code> option on a router
or a <code>domains</code> condition in an ACL statement, the data is preserved in the
<code>$domain_data</code> variable and can be referred to in other router options or
other statements in the same ACL.
</p>
</li><li>
Any of the single-key lookup type names may be preceded by
‘<samp>partial</samp>’<<em>n</em>>‘<samp>-</samp>’, where the <<em>n</em>> is optional, for example,
<table><tr><td> </td><td><pre class="example">domains = partial-dbm;/partial/domains
</pre></td></tr></table>
<p>This causes partial matching logic to be invoked; a description of how this
works is given in section <a href="spec_9.html#SEC96">Partial matching in single-key lookups</a>.
</p>
</li><li>
<a name="IDX599"></a>
Any of the single-key lookup types may be followed by an asterisk. This causes
a default lookup for a key consisting of a single asterisk to be done if the
original lookup fails. This is not a useful feature when using a domain list to
select particular domains (because any domain would match), but it might have
value if the result of the lookup is being used via the <code>$domain_data</code>
expansion variable.
</li><li>
If the pattern starts with the name of a query-style lookup type followed by a
semicolon (for example, "nisplus;" or "ldap;"), the remainder of the
pattern must be an appropriate query for the lookup type, as described in
chapter <a href="spec_9.html#SEC89">File and database lookups</a>. For example:
<table><tr><td> </td><td><pre class="example">hold_domains = mysql;select domain from holdlist \
where domain = '$domain';
</pre></td></tr></table>
<p>In most cases, the data that is looked up is not used (so for an SQL query, for
example, it doesn't matter what field you select). Exim is interested only in
whether or not the query succeeds. However, when a lookup is used for the
<code>domains</code> option on a router, the data is preserved in the <code>$domain_data</code>
variable and can be referred to in other options.
</p>
</li><li>
<a name="IDX600"></a>
If none of the above cases apply, a caseless textual comparison is made
between the pattern and the domain.
</li></ul>
<p>Here is an example that uses several different kinds of pattern:
</p>
<table><tr><td> </td><td><pre class="example">domainlist funny_domains = \
@ : \
lib.unseen.edu : \
*.foundation.fict.example : \
\N^[1-2]\d{3}\.fict\.example$\N : \
partial-dbm;/opt/data/penguin/book : \
nis;domains.byname : \
nisplus;[name=$domain,status=local],domains.org_dir
</pre></td></tr></table>
<p>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.
</p>
<hr size="6">
<a name="Host-lists"></a>
<a name="SEC124"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC123" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC125" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC115" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC115" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_11.html#SEC137" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<h2 class="section"> 10.9 Host lists </h2>
<p>Host lists are used to control what remote hosts are allowed to do. For
example, some hosts may be allowed to use the local host as a relay, and some
may be permitted to use the SMTP ETRN command. Hosts can be identified in
two different ways, by name or by IP address. In a host list, some types of
pattern are matched to a host name, and some are matched to an IP address.
You need to be particularly careful with this when single-key lookups are
involved, to ensure that the right value is being used as the key.
</p>
<hr size="6">
<a name="Special-host-list-patterns"></a>
<a name="SEC125"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC124" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC126" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC115" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC115" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_11.html#SEC137" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<h2 class="section"> 10.10 Special host list patterns </h2>
<p>If a host list item is the empty string, it matches only when no remote host is
involved. This is the case when a message is being received from a local
process using SMTP on the standard input, that is, when a TCP/IP connection is
not used.
</p>
<a name="IDX601"></a>
<p>The special pattern "*" in a host list matches any host or no host. Neither
the IP address nor the name is actually inspected.
</p>
<hr size="6">
<a name="Host-list-patterns-that-match-by-IP-address"></a>
<a name="SEC126"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC125" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC127" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC115" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC115" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_11.html#SEC137" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<h2 class="section"> 10.11 Host list patterns that match by IP address </h2>
<p>If an IPv4 host calls an IPv6 host and the call is accepted on an IPv6 socket,
the incoming address actually appears in the IPv6 host as
‘<samp>::ffff:</samp>’<<em>v4address</em>>. When such an address is tested against a host
list, it is converted into a traditional IPv4 address first. (Not all operating
systems accept IPv4 calls on IPv6 sockets, as there have been some security
concerns.)
</p>
<p>The following types of pattern in a host list check the remote host by
inspecting its IP address:
</p>
<ul class="toc">
<li>
If the pattern is a plain domain name (not a regular expression, not starting
with *, not a lookup of any kind), Exim calls the operating system function
to find the associated IP address(es). Exim uses the newer
<code>getipnodebyname()</code> function when available, otherwise <code>gethostbyname()</code>.
This typically causes a forward DNS lookup of the name. The result is compared
with the IP address of the subject host.
<p>If there is a temporary problem (such as a DNS timeout) with the host name
lookup, a temporary error occurs. For example, if the list is being used in an
ACL condition, the ACL gives a "defer" response, usually leading to a
temporary SMTP error code. If no IP address can be found for the host name,
what happens is described in section <a href="#SEC129">Behaviour when an IP address or name cannot be found</a> below.
</p>
</li><li>
<a name="IDX602"></a>
If the pattern is "@", the primary host name is substituted and used as a
domain name, as just described.
</li><li>
If the pattern is an IP address, it is matched against the IP address of the
subject host. IPv4 addresses are given in the normal "dotted-quad" notation.
IPv6 addresses can be given in colon-separated format, but the colons have to
be doubled so as not to be taken as item separators when the default list
separator is used. IPv6 addresses are recognized even when Exim is compiled
without IPv6 support. This means that if they appear in a host list on an
IPv4-only host, Exim will not treat them as host names. They are just addresses
that can never match a client host.
</li><li>
<a name="IDX603"></a>
If the pattern is "@[]", it matches the IP address of any IP interface on
the local host. For example, if the local host is an IPv4 host with one
interface address 10.45.23.56, these two ACL statements have the same effect:
<table><tr><td> </td><td><pre class="example">accept hosts = 127.0.0.1 : 10.45.23.56
accept hosts = @[]
</pre></td></tr></table>
</li><li>
<a name="IDX604"></a>
If the pattern is an IP address followed by a slash and a mask length (for
example 10.11.42.0/24), it is matched against the IP address of the subject
host under the given mask. This allows, an entire network of hosts to be
included (or excluded) by a single item. The mask uses CIDR notation; it
specifies the number of address bits that must match, starting from the most
significant end of the address.
<p><strong>Note</strong>: The mask is <em>not</em> a count of addresses, nor is it the high number
of a range of addresses. It is the number of bits in the network portion of the
address. The above example specifies a 24-bit netmask, so it matches all 256
addresses in the 10.11.42.0 network. An item such as
</p>
<table><tr><td> </td><td><pre class="example">192.168.23.236/31
</pre></td></tr></table>
<p>matches just two addresses, 192.168.23.236 and 192.168.23.237. A mask value of
32 for an IPv4 address is the same as no mask at all; just a single address
matches.
</p>
<p>Here is another example which shows an IPv4 and an IPv6 network:
</p>
<table><tr><td> </td><td><pre class="example">recipient_unqualified_hosts = 192.168.0.0/16: \
3ffe::ffff::836f::::/48
</pre></td></tr></table>
<p>The doubling of list separator characters applies only when these items
appear inline in a host list. It is not required when indirecting via a file.
For example:
</p>
<table><tr><td> </td><td><pre class="example">recipient_unqualified_hosts = /opt/exim/unqualnets
</pre></td></tr></table>
<p>could make use of a file containing
</p>
<table><tr><td> </td><td><pre class="example">172.16.0.0/12
3ffe:ffff:836f::/48
</pre></td></tr></table>
<p>to have exactly the same effect as the previous example. When listing IPv6
addresses inline, it is usually more convenient to use the facility for
changing separator characters. This list contains the same two networks:
</p>
<table><tr><td> </td><td><pre class="example">recipient_unqualified_hosts = <; 172.16.0.0/12; \
3ffe:ffff:836f::/48
</pre></td></tr></table>
<p>The separator is changed to semicolon by the leading "<;" at the start of the
list.
</p></li></ul>
<hr size="6">
<a name="Host-list-patterns-for-single_002dkey-lookups-by-host-address"></a>
<a name="SEC127"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC126" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC128" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC115" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC115" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_11.html#SEC137" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<h2 class="section"> 10.12 Host list patterns for single-key lookups by host address </h2>
<p>When a host is to be identified by a single-key lookup of its complete IP
address, the pattern takes this form:
</p>
<table><tr><td> </td><td><pre class="display">net-<single-key-search-type>;<search-data>
</pre></td></tr></table>
<p>For example:
</p>
<table><tr><td> </td><td><pre class="example">hosts_lookup = net-cdb;/hosts-by-ip.db
</pre></td></tr></table>
<p>The text form of the IP address of the subject host is used as the lookup key.
IPv6 addresses are converted to an unabbreviated form, using lower case
letters, with dots as separators because colon is the key terminator in
<code>lsearch</code> files. [Colons can in fact be used in keys in <code>lsearch</code> files by
quoting the keys, but this is a facility that was added later.] The data
returned by the lookup is not used.
</p>
<a name="IDX605"></a>
<a name="IDX606"></a>
<p>Single-key lookups can also be performed using masked IP addresses, using
patterns of this form:
</p>
<table><tr><td> </td><td><pre class="display">net<number>-<single-key-search-type>;<search-data>
</pre></td></tr></table>
<p>For example:
</p>
<table><tr><td> </td><td><pre class="example">net24-dbm;/networks.db
</pre></td></tr></table>
<p>The IP address of the subject host is masked using <<em>number</em>> as the mask
length. A textual string is constructed from the masked value, followed by the
mask, and this is used as the lookup key. For example, if the host's IP address
is 192.168.34.6, the key that is looked up for the above example is
"192.168.34.0/24".
</p>
<p>When an IPv6 address is converted to a string, dots are normally used instead
of colons, so that keys in <code>lsearch</code> files need not contain colons (which
terminate <code>lsearch</code> keys). This was implemented some time before the ability
to quote keys was made available in <code>lsearch</code> files. However, the more
recently implemented <code>iplsearch</code> files do require colons in IPv6 keys
(notated using the quoting facility) so as to distinguish them from IPv4 keys.
For this reason, when the lookup type is <code>iplsearch</code>, IPv6 addresses are
converted using colons and not dots. In all cases, full, unabbreviated IPv6
addresses are always used.
</p>
<p>Ideally, it would be nice to tidy up this anomalous situation by changing to
colons in all cases, given that quoting is now available for <code>lsearch</code>.
However, this would be an incompatible change that might break some existing
configurations.
</p>
<p><strong>Warning</strong>: Specifying <code>net32-</code> (for an IPv4 address) or <code>net128-</code> (for an
IPv6 address) is not the same as specifying just <code>net-</code> without a number. In
the former case the key strings include the mask value, whereas in the latter
case the IP address is used on its own.
</p>
<hr size="6">
<a name="Host-list-patterns-that-match-by-host-name"></a>
<a name="SEC128"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC127" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC129" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC115" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC115" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_11.html#SEC137" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<h2 class="section"> 10.13 Host list patterns that match by host name </h2>
<p>There are several types of pattern that require Exim to know the name of the
remote host. These are either wildcard patterns or lookups by name. (If a
complete hostname is given without any wildcarding, it is used to find an IP
address to match against, as described in the section <a href="#SEC126">Host list patterns that match by IP address</a>
above.)
</p>
<p>If the remote host name is not already known when Exim encounters one of these
patterns, it has to be found from the IP address.
Although many sites on the Internet are conscientious about maintaining reverse
DNS data for their hosts, there are also many that do not do this.
Consequently, a name cannot always be found, and this may lead to unwanted
effects. Take care when configuring host lists with wildcarded name patterns.
Consider what will happen if a name cannot be found.
</p>
<p>Because of the problems of determining host names from IP addresses, matching
against host names is not as common as matching against IP addresses.
</p>
<p>By default, in order to find a host name, Exim first does a reverse DNS lookup;
if no name is found in the DNS, the system function (<code>gethostbyaddr()</code> or
<code>getipnodebyaddr()</code> if available) is tried. The order in which these lookups
are done can be changed by setting the <code>host_lookup_order</code> option. For
security, once Exim has found one or more names, it looks up the IP addresses
for these names and compares them with the IP address that it started with.
Only those names whose IP addresses match are accepted. Any other names are
discarded. If no names are left, Exim behaves as if the host name cannot be
found. In the most common case there is only one name and one IP address.
</p>
<p>There are some options that control what happens if a host name cannot be
found. These are described in section <a href="#SEC129">Behaviour when an IP address or name cannot be found</a> below.
</p>
<a name="IDX607"></a>
<a name="IDX608"></a>
<p>As a result of aliasing, hosts may have more than one name. When processing any
of the following types of pattern, all the host's names are checked:
</p>
<ul class="toc">
<li>
<a name="IDX609"></a>
If a pattern starts with "*" the remainder of the item must match the end of
the host name. For example, ‘<samp>*.b.c</samp>’ matches all hosts whose names end in
<em>.b.c</em>. This special simple form is provided because this is a very common
requirement. Other kinds of wildcarding require the use of a regular
expression.
</li><li>
<a name="IDX610"></a>
<a name="IDX611"></a>
If the item starts with "^" it is taken to be a regular expression which is
matched against the host name. Host names are case-independent, so this regular
expression match is by default case-independent, but you can make it
case-dependent by starting it with ‘<samp>(?-i)</samp>’. References to descriptions of the
syntax of regular expressions are given in chapter <a href="spec_8.html#SEC87">Regular expressions</a>. For
example,
<table><tr><td> </td><td><pre class="example">^(a|b)\.c\.d$
</pre></td></tr></table>
<p>is a regular expression that matches either of the two hosts <em>a.c.d</em> or
<em>b.c.d</em>. When a regular expression is used in a host list, you must take care
that backslash and dollar characters are not misinterpreted as part of the
string expansion. The simplest way to do this is to use ‘<samp>\N</samp>’ to mark that
part of the string as non-expandable. For example:
</p>
<table><tr><td> </td><td><pre class="example">sender_unqualified_hosts = \N^(a|b)\.c\.d$\N : ....
</pre></td></tr></table>
<p><strong>Warning</strong>: If you want to match a complete host name, you must include the
‘<samp>$</samp>’ terminating metacharacter in the regular expression, as in the above
example. Without it, a match at the start of the host name is all that is
required.
</p></li></ul>
<hr size="6">
<a name="Behaviour-when-an-IP-address-or-name-cannot-be-found"></a>
<a name="SEC129"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC128" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC130" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC115" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC115" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_11.html#SEC137" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<h2 class="section"> 10.14 Behaviour when an IP address or name cannot be found </h2>
<p>While processing a host list, Exim may need to look up an IP address from a
name (see section <a href="#SEC126">Host list patterns that match by IP address</a>), or it may need to look up a host name
from an IP address (see section <a href="#SEC128">Host list patterns that match by host name</a>). In either case, the
behaviour when it fails to find the information it is seeking is the same.
</p>
<p><strong>Note</strong>: This section applies to permanent lookup failures. It does <em>not</em>
apply to temporary DNS errors, whose handling is described in the next section.
</p>
<a name="IDX612"></a>
<a name="IDX613"></a>
<p>By default, Exim behaves as if the host does not match the list. This may not
always be what you want to happen. To change Exim's behaviour, the special
items ‘<samp>+include_unknown</samp>’ or ‘<samp>+ignore_unknown</samp>’ may appear in the list (at
top level - they are not recognized in an indirected file).
</p>
<ul class="toc">
<li>
If any item that follows ‘<samp>+include_unknown</samp>’ requires information that
cannot found, Exim behaves as if the host does match the list. For example,
<table><tr><td> </td><td><pre class="example">host_reject_connection = +include_unknown:*.enemy.ex
</pre></td></tr></table>
<p>rejects connections from any host whose name matches ‘<samp>*.enemy.ex</samp>’, and also
any hosts whose name it cannot find.
</p>
</li><li>
If any item that follows ‘<samp>+ignore_unknown</samp>’ requires information that cannot
be found, Exim ignores that item and proceeds to the rest of the list. For
example:
<table><tr><td> </td><td><pre class="example">accept hosts = +ignore_unknown : friend.example : \
192.168.4.5
</pre></td></tr></table>
<p>accepts from any host whose name is <em>friend.example</em> and from 192.168.4.5,
whether or not its host name can be found. Without ‘<samp>+ignore_unknown</samp>’, if no
name can be found for 192.168.4.5, it is rejected.
</p></li></ul>
<p>Both ‘<samp>+include_unknown</samp>’ and ‘<samp>+ignore_unknown</samp>’ may appear in the same
list. The effect of each one lasts until the next, or until the end of the
list.
</p>
<hr size="6">
<a name="Temporary-DNS-errors-when-looking-up-host-information"></a>
<a name="SEC130"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC129" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC131" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC115" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC115" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_11.html#SEC137" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<h2 class="section"> 10.15 Temporary DNS errors when looking up host information </h2>
<p>A temporary DNS lookup failure normally causes a defer action (except when
<code>dns_again_means_nonexist</code> converts it into a permanent error). However,
host lists can include ‘<samp>+ignore_defer</samp>’ and ‘<samp>+include_defer</samp>’, analagous to
‘<samp>+ignore_unknown</samp>’ and ‘<samp>+include_unknown</samp>’, as described in the previous
section. These options should be used with care, probably only in non-critical
host lists such as whitelists.
</p>
<hr size="6">
<a name="Host-list-patterns-for-single_002dkey-lookups-by-host-name"></a>
<a name="SEC131"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC130" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC132" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC115" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC115" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_11.html#SEC137" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<h2 class="section"> 10.16 Host list patterns for single-key lookups by host name </h2>
<p>If a pattern is of the form
</p>
<table><tr><td> </td><td><pre class="display"><single-key-search-type>;<search-data>
</pre></td></tr></table>
<p>for example
</p>
<table><tr><td> </td><td><pre class="example">dbm;/host/accept/list
</pre></td></tr></table>
<p>a single-key lookup is performed, using the host name as its key. If the
lookup succeeds, the host matches the item. The actual data that is looked up
is not used.
</p>
<p><strong>Reminder</strong>: With this kind of pattern, you must have host <em>names</em> as
keys in the file, not IP addresses. If you want to do lookups based on IP
addresses, you must precede the search type with "net-" (see section
<a href="#SEC127">Host list patterns for single-key lookups by host address</a>). There is, however, no reason why you could not use
two items in the same list, one doing an address lookup and one doing a name
lookup, both using the same file.
</p>
<hr size="6">
<a name="Host-list-patterns-for-query_002dstyle-lookups"></a>
<a name="SEC132"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC131" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC133" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC115" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC115" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_11.html#SEC137" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<h2 class="section"> 10.17 Host list patterns for query-style lookups </h2>
<p>If a pattern is of the form
</p>
<table><tr><td> </td><td><pre class="display"><query-style-search-type>;<query>
</pre></td></tr></table>
<p>the query is obeyed, and if it succeeds, the host matches the item. The actual
data that is looked up is not used. The variables <code>$sender_host_address</code> and
<code>$sender_host_name</code> can be used in the query. For example:
</p>
<table><tr><td> </td><td><pre class="example">hosts_lookup = pgsql;\
select ip from hostlist where ip='$sender_host_address'
</pre></td></tr></table>
<p>The value of <code>$sender_host_address</code> for an IPv6 address contains colons. You
can use the <code>sg</code> expansion item to change this if you need to. If you want to
use masked IP addresses in database queries, you can use the <code>mask</code> expansion
operator.
</p>
<p>If the query contains a reference to <code>$sender_host_name</code>, Exim automatically
looks up the host name if has not already done so. (See section
<a href="#SEC128">Host list patterns that match by host name</a> for comments on finding host names.)
</p>
<p>Historical note: prior to release 4.30, Exim would always attempt to find a
host name before running the query, unless the search type was preceded by
‘<samp>net-</samp>’. This is no longer the case. For backwards compatibility, ‘<samp>net-</samp>’ is
still recognized for query-style lookups, but its presence or absence has no
effect. (Of course, for single-key lookups, ‘<samp>net-</samp>’ <em>is</em> important.
See section <a href="#SEC127">Host list patterns for single-key lookups by host address</a>.)
</p>
<hr size="6">
<a name="Mixing-wildcarded-host-names-and-addresses-in-host-lists"></a>
<a name="SEC133"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC132" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC134" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC115" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC115" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_11.html#SEC137" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<h2 class="section"> 10.18 Mixing wildcarded host names and addresses in host lists </h2>
<p>If you have name lookups or wildcarded host names and IP addresses in the same
host list, you should normally put the IP addresses first. For example, in an
ACL you could have:
</p>
<table><tr><td> </td><td><pre class="example">accept hosts = 10.9.8.7 : *.friend.example
</pre></td></tr></table>
<p>The reason for this lies in the left-to-right way that Exim processes lists.
It can test IP addresses without doing any DNS lookups, but when it reaches an
item that requires a host name, it fails if it cannot find a host name to
compare with the pattern. If the above list is given in the opposite order, the
<code>accept</code> statement fails for a host whose name cannot be found, even if its
IP address is 10.9.8.7.
</p>
<p>If you really do want to do the name check first, and still recognize the IP
address, you can rewrite the ACL like this:
</p>
<table><tr><td> </td><td><pre class="example">accept hosts = *.friend.example
accept hosts = 10.9.8.7
</pre></td></tr></table>
<p>If the first <code>accept</code> fails, Exim goes on to try the second one. See chapter
<a href="spec_40.html#SEC308">Access control lists</a> for details of ACLs.
</p>
<hr size="6">
<a name="Address-lists"></a>
<a name="SEC134"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC133" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC135" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC115" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC115" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_11.html#SEC137" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<h2 class="section"> 10.19 Address lists </h2>
<p>Address lists contain patterns that are matched against mail addresses. There
is one special case to be considered: the sender address of a bounce message is
always empty. You can test for this by providing an empty item in an address
list. For example, you can set up a router to process bounce messages by
using this option setting:
</p>
<table><tr><td> </td><td><pre class="example">senders = :
</pre></td></tr></table>
<p>The presence of the colon creates an empty item. If you do not provide any
data, the list is empty and matches nothing. The empty sender can also be
detected by a regular expression that matches an empty string,
and by a query-style lookup that succeeds when <code>$sender_address</code> is empty.
</p>
<p>Non-empty items in an address list can be straightforward email addresses. For
example:
</p>
<table><tr><td> </td><td><pre class="example">senders = jbc@askone.example : hs@anacreon.example
</pre></td></tr></table>
<p>A certain amount of wildcarding is permitted. If a pattern contains an @
character, but is not a regular expression and does not begin with a
semicolon-terminated lookup type (described below), the local part of the
subject address is compared with the local part of the pattern, which may start
with an asterisk. If the local parts match, the domain is checked in exactly
the same way as for a pattern in a domain list. For example, the domain can be
wildcarded, refer to a named list, or be a lookup:
</p>
<table><tr><td> </td><td><pre class="example">deny senders = *@*.spamming.site:\
*@+hostile_domains:\
bozo@partial-lsearch;/list/of/dodgy/sites:\
*@dbm;/bad/domains.db
</pre></td></tr></table>
<a name="IDX614"></a>
<a name="IDX615"></a>
<p>If a local part that begins with an exclamation mark is required, it has to be
specified using a regular expression, because otherwise the exclamation mark is
treated as a sign of negation, as is standard in lists.
</p>
<p>If a non-empty pattern that is not a regular expression or a lookup does not
contain an @ character, it is matched against the domain part of the subject
address. The only two formats that are recognized this way are a literal
domain, or a domain pattern that starts with *. In both these cases, the effect
is the same as if ‘<samp>*@</samp>’ preceded the pattern. For example:
</p>
<table><tr><td> </td><td><pre class="example">deny senders = enemy.domain : *.enemy.domain
</pre></td></tr></table>
<p>The following kinds of more complicated address list pattern can match any
address, including the empty address that is characteristic of bounce message
senders:
</p>
<ul class="toc">
<li>
<a name="IDX616"></a>
<a name="IDX617"></a>
If (after expansion) a pattern starts with "^", a regular expression match is
done against the complete address, with the pattern as the regular expression.
You must take care that backslash and dollar characters are not misinterpreted
as part of the string expansion. The simplest way to do this is to use ‘<samp>\N</samp>’
to mark that part of the string as non-expandable. For example:
<table><tr><td> </td><td><pre class="example">deny senders = \N^.*this.*@example\.com$\N : \
\N^\d{8}.+@spamhaus.example$\N : ...
</pre></td></tr></table>
<p>The ‘<samp>\N</samp>’ sequences are removed by the expansion, so these items do indeed
start with "^" by the time they are being interpreted as address patterns.
</p>
</li><li>
<a name="IDX618"></a>
Complete addresses can be looked up by using a pattern that starts with a
lookup type terminated by a semicolon, followed by the data for the lookup. For
example:
<table><tr><td> </td><td><pre class="example">deny senders = cdb;/etc/blocked.senders : \
mysql;select address from blocked where \
address='${quote_mysql:$sender_address}'
</pre></td></tr></table>
<p>Both query-style and single-key lookup types can be used. For a single-key
lookup type, Exim uses the complete address as the key. However, empty keys are
not supported for single-key lookups, so a match against the empty address
always fails. This restriction does not apply to query-style lookups.
</p>
<p>Partial matching for single-key lookups (section <a href="spec_9.html#SEC96">Partial matching in single-key lookups</a>)
cannot be used, and is ignored if specified, with an entry being written to the
panic log.
<a name="IDX619"></a>
However, you can configure lookup defaults, as described in section
<a href="spec_9.html#SEC95">Default values in single-key lookups</a>, but this is useful only for the "*@" type of
default. For example, with this lookup:
</p>
<table><tr><td> </td><td><pre class="example">accept senders = lsearch*@;/some/file
</pre></td></tr></table>
<p>the file could contains lines like this:
</p>
<table><tr><td> </td><td><pre class="example">user1@domain1.example
*@domain2.example
</pre></td></tr></table>
<p>and for the sender address <em>nimrod@jaeger.example</em>, the sequence of keys
that are tried is:
</p>
<table><tr><td> </td><td><pre class="example">nimrod@jaeger.example
*@jaeger.example
*
</pre></td></tr></table>
<p><strong>Warning 1</strong>: Do not include a line keyed by "*" in the file, because that
would mean that every address matches, thus rendering the test useless.
</p>
<p><strong>Warning 2</strong>: Do not confuse these two kinds of item:
</p>
<table><tr><td> </td><td><pre class="example">deny recipients = dbm*@;/some/file
deny recipients = *@dbm;/some/file
</pre></td></tr></table>
<p>The first does a whole address lookup, with defaulting, as just described,
because it starts with a lookup type. The second matches the local part and
domain independently, as described in a bullet point below.
</p></li></ul>
<p>The following kinds of address list pattern can match only non-empty addresses.
If the subject address is empty, a match against any of these pattern types
always fails.
</p>
<ul class="toc">
<li>
<a name="IDX620"></a>
<a name="IDX621"></a>
<a name="IDX622"></a>
If a pattern starts with "@@" followed by a single-key lookup item
(for example, ‘<samp>@@lsearch;/some/file</samp>’), the address that is being checked is
split into a local part and a domain. The domain is looked up in the file. If
it is not found, there is no match. If it is found, the data that is looked up
from the file is treated as a colon-separated list of local part patterns, each
of which is matched against the subject local part in turn.
<a name="IDX623"></a>
<p>The lookup may be a partial one, and/or one involving a search for a default
keyed by "*" (see section <a href="spec_9.html#SEC95">Default values in single-key lookups</a>). The local part
patterns that are looked up can be regular expressions or begin with "*", or
even be further lookups. They may also be independently negated. For example,
with
</p>
<table><tr><td> </td><td><pre class="example">deny senders = @@dbm;/etc/reject-by-domain
</pre></td></tr></table>
<p>the data from which the DBM file is built could contain lines like
</p>
<table><tr><td> </td><td><pre class="example">baddomain.com: !postmaster : *
</pre></td></tr></table>
<p>to reject all senders except <code>postmaster</code> from that domain.
</p>
<a name="IDX624"></a>
<p>If a local part that actually begins with an exclamation mark is required, it
has to be specified using a regular expression. In <code>lsearch</code> files, an entry
may be split over several lines by indenting the second and subsequent lines,
but the separating colon must still be included at line breaks. White space
surrounding the colons is ignored. For example:
</p>
<table><tr><td> </td><td><pre class="example">aol.com: spammer1 : spammer2 : ^[0-9]+$ :
spammer3 : spammer4
</pre></td></tr></table>
<p>As in all colon-separated lists in Exim, a colon can be included in an item by
doubling.
</p>
<p>If the last item in the list starts with a right angle-bracket, the remainder
of the item is taken as a new key to look up in order to obtain a continuation
list of local parts. The new key can be any sequence of characters. Thus one
might have entries like
</p>
<table><tr><td> </td><td><pre class="example">aol.com: spammer1 : spammer 2 : >*
xyz.com: spammer3 : >*
*: ^\d{8}$
</pre></td></tr></table>
<p>in a file that was searched with <code>@@dbm*</code>, to specify a match for 8-digit
local parts for all domains, in addition to the specific local parts listed for
each domain. Of course, using this feature costs another lookup each time a
chain is followed, but the effort needed to maintain the data is reduced.
</p>
<a name="IDX625"></a>
<p>It is possible to construct loops using this facility, and in order to catch
them, the chains may be no more than fifty items long.
</p>
</li><li>
The @@<<em>lookup</em>> style of item can also be used with a query-style
lookup, but in this case, the chaining facility is not available. The lookup
can only return a single list of local parts.
</li></ul>
<p><strong>Warning</strong>: There is an important difference between the address list items
in these two examples:
</p>
<table><tr><td> </td><td><pre class="example">senders = +my_list
senders = *@+my_list
</pre></td></tr></table>
<p>In the first one, ‘<samp>my_list</samp>’ is a named address list, whereas in the second
example it is a named domain list.
</p>
<hr size="6">
<a name="Case-of-letters-in-address-lists"></a>
<a name="SEC135"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC134" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC136" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC115" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC115" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_11.html#SEC137" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<h2 class="section"> 10.20 Case of letters in address lists </h2>
<p>Domains in email addresses are always handled caselessly, but for local parts
case may be significant on some systems (see <code>caseful_local_part</code> for how
Exim deals with this when routing addresses). However, RFC 2505 (<em>Anti-Spam
Recommendations for SMTP MTAs</em>) suggests that matching of addresses to
blocking lists should be done in a case-independent manner. Since most address
lists in Exim are used for this kind of control, Exim attempts to do this by
default.
</p>
<p>The domain portion of an address is always lowercased before matching it to an
address list. The local part is lowercased by default, and any string
comparisons that take place are done caselessly. This means that the data in
the address list itself, in files included as plain file names, and in any file
that is looked up using the "@@" mechanism, can be in any case. However, the
keys in files that are looked up by a search type other than <code>lsearch</code> (which
works caselessly) must be in lower case, because these lookups are not
case-independent.
</p>
<a name="IDX626"></a>
<p>To allow for the possibility of caseful address list matching, if an item in
an address list is the string "+caseful", the original case of the local
part is restored for any comparisons that follow, and string comparisons are no
longer case-independent. This does not affect the domain, which remains in
lower case. However, although independent matches on the domain alone are still
performed caselessly, regular expressions that match against an entire address
become case-sensitive after "+caseful" has been seen.
</p>
<hr size="6">
<a name="Local-part-lists"></a>
<a name="SEC136"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC135" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="spec_11.html#SEC137" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC115" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC115" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_11.html#SEC137" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<h2 class="section"> 10.21 Local part lists </h2>
<p>Case-sensitivity in local part lists is handled in the same way as for address
lists, as just described. The "+caseful" item can be used if required. In a
setting of the <code>local_parts</code> option in a router with <code>caseful_local_part</code>
set false, the subject is lowercased and the matching is initially
case-insensitive. In this case, "+caseful" will restore case-sensitive
matching in the local part list, but not elsewhere in the router. If
<code>caseful_local_part</code> is set true in a router, matching in the <code>local_parts</code>
option is case-sensitive from the start.
</p>
<p>If a local part list is indirected to a file (see section <a href="#SEC118">File names in lists</a>),
comments are handled in the same way as address lists - they are recognized
only if the # is preceded by white space or the start of the line.
Otherwise, local part lists are matched in the same way as domain lists, except
that the special items that refer to the local host (‘<samp>@</samp>’, ‘<samp>@[]</samp>’,
‘<samp>@mx_any</samp>’, ‘<samp>@mx_primary</samp>’, and ‘<samp>@mx_secondary</samp>’) are not recognized.
Refer to section <a href="#SEC123">Domain lists</a> for details of the other available item
types.
<a name="IDX627"></a>
</p>
<hr size="6">
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC115" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="spec_11.html#SEC137" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<p>
<font size="-1">
This document was generated on <i>September, 10 2009</i> using <a href="http://www.nongnu.org/texi2html/"><i>texi2html 1.78</i></a>.
</font>
<br>
</p>
</body>
</html>
distrib
>
Mandriva
>
2010.0
>
i586
>
media
>
contrib-release
>
by-pkgid
>
a4080654d049ad31b216b761b9173c1f
>
files
>
111
