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

<TITLE>Exim Specification - 46. Other policy controls on incoming mail</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_45.html">previous</A>, <A HREF="spec_47.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="SEC809" HREF="spec_toc.html#TOC809">46. Other policy controls on incoming mail</A></H1>
<P>
<A NAME="IDX1754"></A>
<A NAME="IDX1755"></A>
Exim provides a number of facilities for controlling incoming mail from remote
hosts, in addition to the verification options described in the previous
chapter. These controls can be used to stop unwanted messages getting into your
machine. After a message has been accepted, the filtering mechanism described
in chapter 47 can be used to check it before going ahead with
delivery.

</P>
<P>
An MTA is said to <EM>relay</EM> a message if it receives it from some host and
delivers it directly to another host as a result of a remote address contained
within it. Expanding a local address via an alias or forward file and then
passing the message on to another host is not relaying,
<A NAME="IDX1756"></A>
but a re-direction as a result of the `percent hack' is. There are special
options for controlling which remote hosts may use the local host as a relay.

</P>
<P>
The options described in this chapter control three stages of checking that are
applied to an incoming SMTP message:

</P>

<OL>

<LI>

At the start of an SMTP connection, a check on the remote host is made, leading
to one of the following conclusions:


<OL>

<LI>

No mail whatsoever is acceptable from the remote host.

<LI>

The remote host is permitted to send messages to local recipients only, but is
not permitted to use the local host as a relay.

<LI>

The remote host is permitted to send messages to local recipients, and can also
use the local host as a relay to certain specified domains only.

<LI>

The remote host is permitted to send mail to any recipient.
</OL>

If the host is completely unacceptable, the SMTP connection may be rejected
immediately, or (depending on the configuration) the message may be refused
later on by a rejection at the end of the message (so the headers can be
logged) or by rejecting every recipient.

<LI>

The message's sender, which is obtained from the MAIL command, is
checked. Again there is a choice of immediate rejection, or delayed rejection
of all recipients.

<LI>

Unless there are no controls on relaying, the recipient address in each
RCPT command is checked.
</OL>

<P>
These checks are all in addition to any verification that may be enabled. The
following sections give details of the various checking options.
The -<EM>bh</EM> command line option can be used to run fake SMTP sessions for the
purpose of testing them.

</P>

<P>



<H2><A NAME="SEC810" HREF="spec_toc.html#TOC810">46.1 Host checking using RBL</A></H2>

<P>
<A NAME="IDX1757"></A>
<A NAME="IDX1758"></A>
<A NAME="IDX1759"></A>
<A NAME="IDX1760"></A>
The Realtime Blocking List (RBL) is a black list of hosts that is maintained in
the DNS. See <A HREF="http://maps.vix.com/rbl/">http://maps.vix.com/rbl/</A> for the background to this.
Since the RBL was created, a number of other similar lists (DUL, ORBS, RRSS,
IMRSS) have sprung up. These all operate in the same way. If the <EM>rbl_domains</EM>
option is set, Exim looks up inverted incoming IP addresses in each of the
given domains, provided the remote host matches <EM>rbl_hosts</EM> (whose default is
to match all hosts). For example, if the setting is

<PRE>
rbl_domains = rbl.maps.vix.com:dul.maps.vix.com
</PRE>

<P>
and an SMTP call is received from the host whose IP address is 192.168.8.1,
then DNS lookups for address records for

<PRE>
1.8.168.192.rbl.maps.vix.com
and
1.8.168.192.dul.maps.vix.com
</PRE>

<P>
are done. Each domain in <EM>rbl_domains</EM> can be followed by `/warn' or `/reject'
to specify what is to be done when a matching DNS record is found, for example:

<PRE>
rbl_domains = rbl.maps.vix.com/warn : dul.maps.vix.com/reject
</PRE>

<P>
The action for domains without either of these is controlled by
<A NAME="IDX1761"></A>
<EM>rbl_reject_recipients</EM>, which implies `/reject' when set.
<font color=green>
If a lookup times out or otherwise fails to give a decisive answer, the address
is not blocked (by that entry in the list).

</P>
<P>
Two further options, in addition to `/warn' and `/reject', are available:

</P>

<UL>

<LI>

`/accept' allows RBL-type lookups to be used for `white lists' as well as black
lists. The message is accepted from a host that matches an `/accept' item, and
no further RBL domains are considered.  Earlier `/warn' entries may have
already added warning headers.

<LI>

`/skiprelay' causes that particular RBL domain to be skipped if the calling
host matches <EM>host_accept_relay</EM>. In other words, if the host has been listed
as one that is permitted to relay, no RBL check is done for it.
</UL>

<P>
The original RBL just used the address 127.0.0.1 on the right hand side of the
addresses records, but some other lists use a number of different values. The
ORBS database, for example, uses different addresses to denote different types
of open relay, and you might want to block on some but not on others. The
current values are 127.0.0.2 for a confirmed open relay, 127.0.0.3 for a manual
entry, and 127.0.0.4 for a `netblock'.

</P>
<P>
By adding an equals sign and an IP address after an RBL domain name, you can
restrict its action to DNS records with a matching right hand side. For
example,

<PRE>
rbl_domains = relays.orbs.org=127.0.0.2/reject
</PRE>

<P>
rejects only those hosts that yield 127.0.0.2 from the ORBS database.
More than one address may be given, using comma as a separator. These are
alternatives -- if any one of them matches, the RBL entry operates. If there
are no addresses, any address record is considered to be a match.
</font>

</P>

<P>
<A NAME="IDX1762"></A>
When a hosts matches an RBL item, warning consists of writing a message to the
main and reject logs, and, if <EM>rbl_warn_header</EM> is true (the default), adding
an <EM>X-RBL-Warning:</EM> header to the message. This can be detected later by system
or user filter files. If a host appears in several RBL lists, more than one
such header may be added to a message.

</P>
<P>
Rejection is done by refusing all recipients, that is, by giving permanent
error returns to all RCPT commands,
unless the message's sender is listed in <EM>recipients_reject_except_senders</EM>,
or the recipient is
listed in
<A NAME="IDX1763"></A>
<A NAME="IDX1764"></A>
<EM>recipients_reject_except</EM>. It is fairly common to set

<PRE>
recipients_reject_except = postmaster@your.domain
</PRE>

<P>
<A NAME="IDX1765"></A>
to allow your host to accept mail to the postmaster from blacklisted hosts.
<EM>X-RBL-Warning:</EM> headers are added to messages that get accepted as a result of
an exception list.

</P>
<P>
If a TXT record associated with the host is found in the RBL domain, its
contents are returned as part of the 550 rejection message, unless
<EM>prohibition_message</EM> is set (see section 46.5), in which case a
locally-specified message is used.
<font color=green>
This can include any TXT data by referring to $<EM>rbl_text</EM>. It may also
refererence the RBL domain that caused the rejection by referring to
$<EM>rbl_domain</EM> (and, of course, the incoming host IP address is available in
$<EM>sender_host_address</EM>).
</font>

</P>



<H2><A NAME="SEC811" HREF="spec_toc.html#TOC811">46.2 Other host checking</A></H2>

<P>
<A NAME="IDX1766"></A>
<A NAME="IDX1767"></A>
<A NAME="IDX1768"></A>
<A NAME="IDX1769"></A>
<A NAME="IDX1770"></A>
Exim rejects incoming SMTP calls from any host that matches <EM>host_reject</EM>.
For example:

<PRE>
host_reject = ! xxx.yy.zz : *.yy.zz : ! *.zz
</PRE>

<P>
rejects mail from any host outside the <EM>zz</EM> domain, and all hosts in the
<EM>yy.zz</EM> domain, except for <EM>xx.yy.zz</EM>. The use of wildcarded names implies a
reverse DNS lookup of the incoming IP address. This can be avoided by using IP
addresses. See section 7.13 for details.

</P>
<P>
Calls are rejected as a result of these options by sending a 5<EM>xx</EM> error
code as soon as the connection is received. Since this does not relate to any
particular message, the remote host is likely to keep on trying to send mail
(possibly to an alternative MX host) until it times out. This may be what is
wanted in some circumstances (for example, you want temporarily to hold back
all incoming mail from some host), but when dealing with incoming spam, for
example, one normally wants messages to be rejected once and for all, and in
this case, <EM>host_reject_recipients</EM> should be used instead of <EM>host_reject</EM>.

</P>
<P>
A call from a host which matches <EM>host_reject_recipients</EM>
is not rejected at the start; instead, every RCPT command is subsequently
rejected, which should cause the remote MTA to cease trying to deliver the
message. This style of blocking also has the advantage of catering for
exceptions for certain recipients,
<A NAME="IDX1771"></A>
<A NAME="IDX1772"></A>
via the <EM>recipients_reject_except</EM> option. This is commonly set to the local
postmaster address.

</P>



<H2><A NAME="SEC812" HREF="spec_toc.html#TOC812">46.3 Sender checking</A></H2>

<P>
<A NAME="IDX1773"></A>
<A NAME="IDX1774"></A>
<A NAME="IDX1775"></A>
<A NAME="IDX1776"></A>
Incoming messages can be rejected on the basis of the sender address, as given
in the MAIL command. A list of senders to reject is set by the
<EM>sender_reject</EM> configuration option; see its description in chapter
11 for details.

</P>
<P>
Some MTAs continue to try to deliver a message even after receiving a 5<EM>xx</EM>
error code for MAIL. The alternative configuration option
<EM>sender_reject_recipients</EM> is provided for use in such cases. It accepts the
MAIL command but rejects all subsequent RCPT commands.

</P>



<H2><A NAME="SEC813" HREF="spec_toc.html#TOC813">46.4 Control of relaying</A></H2>

<P>
<A NAME="IDX1777"></A>
<A NAME="IDX1778"></A>
<A NAME="IDX1779"></A>
<A NAME="IDX1780"></A>
<A NAME="IDX1781"></A>
Two kinds of relaying exist, which are termed `incoming' and `outgoing'.
A host which is acting as a gateway or an MX backup is concerned with incoming
relaying from arbitrary hosts to a specific set of domains. On the other hand,
a host which is acting as a smart host for a number of clients is concerned
with outgoing relaying from those clients to the Internet at large. Often the
same host is fulfilling both functions, as illustrated in the diagram below,
but in principle these two kinds of relaying are entirely independent, and are
therefore controlled by separate options. What is not wanted is the
transmission of mail from arbitrary remote hosts through your system to
arbitrary domains.
<IMG SRC="relaying.gif" alt="Controlled relaying"><br>
Incoming relaying is controlled by restricting the domains to which an
arbitrary host may send via the local host; this is done by setting
<EM>relay_domains</EM>. For example, you use this option to list the domains that
your host is an MX backup for. Outgoing relaying is controlled by restricting
the set of hosts which may send via the local host to an arbitrary domain, by
setting <EM>host_accept_relay</EM>. For example, a delivery server uses this option
to list its client hosts.

</P>
<P>
Checks for unwanted relaying are made on the domains of recipient addresses in
messages received from other hosts. This is done at the time of the RCPT
command in the SMTP dialogue. The first check is whether the address would
cause relaying at all: if its domain matches something in <EM>local_domains</EM> then
it is destined to be handled on the local host as a local address, and relaying
is not involved.

</P>
<P>
This includes the case of addresses such as <EM>"x@y"@z</EM>
where <EM>z</EM> is a local domain, which are sometimes used in an attempt to bypass
relaying restrictions. Exim treats such addresses as having a local part <EM>x@y</EM>
-- it does <EM>not</EM> strip off the local domain and treat <EM>x@y</EM> as an entirely
new address. Assuming that <EM>x@y</EM> is not a valid local part, this means that
the address is rejected, either at SMTP time if <EM>receiver_verify</EM> is set, or
later when Exim tries to deliver to it.
<A NAME="IDX1782"></A>
Addresses of the form <EM>"x%y"@z</EM> are treated in the same way, unless the
`percent hack' has been enabled by setting <EM>percent_hack_domains</EM>. In this
case, the new address (constructed from the local part by changing the % to an
@) is treated as an incoming address, and its domain is re-tested to ensure
that it complies with any relaying restrictions.

</P>
<P>
When the relevant domain is not in <EM>local_domains</EM>, there is first a check for
legitimate incoming relaying, by seeing if it matches <EM>relay_domains</EM>, or,
when <EM>relay_domains_include_local_mx</EM> is set, if it is a domain with an MX
record pointing to the local host. If it does match, this is an acceptable
incoming relay, and it is permitted to proceed. For example, if the FooBar
company has a firewall machine through which all mail from external hosts must
pass, and this machine's configuration contains

<PRE>
local_domains = foobar.com
relay_domains = *.foobar.com
</PRE>

<P>
then mail from external hosts is rejected, unless it is for a domain ending in
<EM>foobar.com</EM>.

</P>
<P>
<b>Warning</b>: Turning on the <EM>relay_domains_include_local_mx</EM> option opens
your server to the possibility of abuse in that anyone with access to a DNS
zone can list your server in a secondary MX record as a backup for their domain
without your permission. This is not a huge exposure because firstly, it
requires the cooperation of a hostmaster to set up, and secondly, since their
mail is passing through your server, they run the risk of your noticing and
(for example) throwing all their mail away.

</P>
<P>
If a recipient address is neither for a local domain nor an incoming relay, it
must be an outgoing relay, and it is accepted only if the sending host is
permitted to relay to arbitrary domains, and if the sender address is
acceptable. The set of hosts that are permitted to relay is specified by
<EM>host_accept_relay</EM>. For example, if the FooBar company's IP network is
172.16.213.0/24, and all hosts on that network send their outgoing mail via the
firewall machine, its configuration should contain

<PRE>
host_accept_relay = 172.16.213.0/24
</PRE>

<P>
in order to allow only the internal hosts to use it as a relay to arbitrary
domains.
Exim does not make an automatic exception for the loopback IP address, so if
you want to permit relaying from processes on the local host using this method,
you need to include 127.0.0.1 in the relay list. Some user agents, notably MH
and NMH, send mail by connecting to the loopback address on the local host.

</P>
<P>
The option <EM>host_auth_accept_relay</EM> is similar to <EM>host_accept_relay</EM>,
except that any client host matching one of its items is permitted to relay
only if it has successfully authenticated. This is independent of whether or
not it matches <EM>auth_hosts</EM>. You can set <EM>host_auth_accept_relay</EM> only if
Exim has been compiled to support SMTP authentication. Chapter 35
contains more details.

</P>
<P>
<A NAME="IDX1783"></A>
<A NAME="IDX1784"></A>
<A NAME="IDX1785"></A>
<A NAME="IDX1786"></A>
In addition to the tests on the host, if <EM>sender_address_relay</EM> is set, the
sender's address from the MAIL command must match one of its patterns to
allow outgoing relaying to an arbitrary domain. Also, if there are any
rewriting rules with the `X' flag set, such an address is rewritten using those
rules, and the result (if different) must verify successfully. See section
34.9 for an example of how this can be used.

</P>
<P>
Normally, therefore, both the host and the sender must be acceptable before an
outgoing relay is allowed to proceed. However, if
<EM>relay_match_host_or_sender</EM> is set, an address is accepted for outgoing
relaying if <EM>either</EM> the host <EM>or</EM> the sender is acceptable. Of course,
sender addresses can easily be forged, but the sender check does mean you can
prevent some kinds of unwanted mail from going through your host.

</P>
<P>
All three options, <EM>relay_domains</EM>, <EM>host_accept_relay</EM>, and
<EM>host_auth_accept_relay</EM>,
are unset by default, which means that no relaying of any kind is enabled. This
does not prevent a local user from setting up forwarding to some external
system,
<A NAME="IDX1787"></A>
but it does prevent the `percent hack' from relaying to arbitrary domains even
when <EM>percent_hack_domains</EM> is set.

</P>
<P>
As all the relay checking is done at RCPT time on incoming messages, the
directors and routers are not involved. Depending on the configuration of these
drivers, an address that appears to be remote to the relay checking code (that
is, its domain does not match <EM>local_domains</EM>) may nevertheless end up being
delivered locally, and similarly an apparently local address may end up being
delivered to some other host.

</P>
<P>
None of the relay checking applies when mail is passed to Exim locally using
the -<EM>bm</EM>, -<EM>bs</EM> or -<EM>bS</EM> options, but it does apply when -<EM>bs</EM> is used from
<EM>inetd</EM>.

</P>
<P>
Exim does not attempt to fully qualify domains at RCPT time. If an
incoming message contains a domain which is not fully qualified, it is treated
as a non-local, non-relay domain (unless partial domains are included in
<EM>local_domains</EM> or <EM>relay_domains</EM>, but this is not recommended). The use of
domains that are not fully qualified is non-standard, but it is a commonly
encountered usage when an MTA is being used as a smart host by some remote UA.
In this situation, it would be usual to permit the UA host to relay to any
domain, so in practice there is not normally a problem.

</P>



<H2><A NAME="SEC814" HREF="spec_toc.html#TOC814">46.5 Customizing prohibition messages</A></H2>

<P>
<A NAME="IDX1788"></A>
<A NAME="IDX1789"></A>
<A NAME="IDX1790"></A>
<A NAME="IDX1791"></A>
It is possible to add a site-specific message to the error response that
is sent when an incoming SMTP command fails for policy reasons, for example if
the sending host is in a host reject list. This is done by setting the option
<A NAME="IDX1792"></A>
<EM>prohibition_message</EM>, which causes one or more additional response lines with
the same error code and a multiline marker to be output before the standard
response line. For example, setting

<PRE>
prohibition_message = contact postmaster@my.site for details
</PRE>

<P>
causes the response to a RCPT command for a blocked recipient to be

<PRE>
550-contact postmaster@my.site for details
550 rejected: administrative prohibition
</PRE>

<P>
The string is expanded, and so it can do file lookups if necessary. If it ends
up as an empty string, no additional response is transmitted. To make it
possible to distinguish between the several different types of administrative
rejection, the variable $<EM>prohibition_reason</EM> is set to a characteristic text
string in each case. The possibilities are as follows:

<PRE>
host_accept_relay          the host is not in an <EM>accept_relay</EM> list
host_reject                the host is in a reject list
host_reject_recipients     the host is in a <EM>reject_recipients</EM> list
rbl_reject                 the host is rejected by an RBL domain
<font color=green>receiver_verify            receiver verification failed
</font>
sender_relay               the sender is not in a sender relay list
sender_reject              the sender is in a reject list
sender_reject_recipients   the sender is in a <EM>reject_recipients</EM> list
sender_verify              sender verification failed
</PRE>

<P>
In addition, if <EM>relay_match_host_or_sender</EM> is set, there is

<PRE>
sender+host_accept_relay  the sender is not in a sender relay list
                            <EM>and</EM> the host is not in an accept relay list
</PRE>

<P>
For example, if the configuration contains

<PRE>
prohibition_message = ${lookup{$prohibition_reason}lsearch\
  {/etc/exim/reject.messages}{$value}}
</PRE>

<P>
and the file <EM>/etc/exim/reject.messages</EM> contains (<EM>inter alia</EM>)

<PRE>
host_accept_relay:  host not in relay list
</PRE>

<P>
then a response to a relay attempt might be

<PRE>
550-host not in relay list
550 relaying to &#60;santa@northpole.com&#62; prohibited by administrator
</PRE>

<P>
Because some administrators may want to put in quite long messages, and it
isn't possible to get newlines into the text returned from an lsearch lookup,
Exim treats the vertical bar character as a line separator in this text. If you
want the looked up text to be re-expanded, you can use the <EM>expand</EM> operator.
For example, the setting

<PRE>
prohibition_message = ${lookup{$prohibition_reason}lsearch\
  {/etc/exim/reject.messages}{${expand:$value}}}
</PRE>

<P>
when used with a file entry of the form

<PRE>
host_accept_relay:  Host $sender_fullhost is not permitted to
                    relay |through $primary_hostname.
</PRE>

<P>
might produce

<PRE>
550-Host that.host.name [111.222.3.4] is not permitted to relay
550-through this.host.name.
550 relaying to &#60;penguins@southpole.com&#62; prohibited by administrator
</PRE>

<P>
<A NAME="IDX1793"></A>
<A NAME="IDX1794"></A>
<font color=green>
In the case of an RBL rejection, $<EM>rbl_domain</EM> contains the RBL domain that
caused the rejection during the expansion of <EM>prohibition_message</EM>, and
$<EM>rbl_text</EM> contains the contents of any associated TXT record. In all cases.
$<EM>sender_host_address</EM> contains the IP address of the calling host.
</font>

</P>

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