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.
An MTA is said to relay 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, 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.
The options described in this chapter control three stages of checking that are applied to an incoming SMTP message:
These checks are all in addition to any verification that may be enabled. The following sections give details of the various checking options. The -bh command line option can be used to run fake SMTP sessions for the purpose of testing them.
The Realtime Blackhole List (RBL) is a black list of hosts that is maintained
in the DNS. See http://mail-abuse.org/rbl/
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 rbl_domains option is set, Exim looks up inverted incoming
IP addresses in each of the given domains, provided the remote host matches
rbl_hosts (whose default is to match all hosts). For example, if the setting
is
rbl_domains = blackholes.mail-abuse.org:dialups.mail-abuse.org
1.8.168.192.blackholes.mail-abuse.org
and
1.8.168.192.dialups.mail-abuse.org
rbl_domains = blackholes.mail-abuse.org/warn : \
dialups.mail-abuse.org/reject
Two further options, in addition to `/warn' and `/reject', are available:
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'.
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,
rbl_domains = relays.orbs.org=127.0.0.2/reject
rejects only those hosts that yield 127.0.0.2 from the ORBS database. More than one address may be given, using a 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.
When a hosts matches an RBL item, warning consists of writing a message to the main and reject logs, and, if rbl_warn_header is true (the default), adding an X-RBL-Warning: 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.
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 recipients_reject_except_senders, or the recipient is listed in recipients_reject_except. It is fairly common to set
recipients_reject_except = postmaster@your.domain
to allow your host to accept mail to the postmaster from blacklisted hosts. X-RBL-Warning: headers are added to messages that get accepted as a result of an exception list.
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 prohibition_message is set (see section 46.5), in which case a locally-specified message is used. This can include any TXT data by referring to $rbl_text. It may also refererence the RBL domain that caused the rejection by referring to $rbl_domain (and, of course, the incoming host IP address is available in $sender_host_address).
Exim rejects incoming SMTP calls from any host that matches host_reject. For example:
host_reject = ! xxx.yy.zz : *.yy.zz : ! *.zz
rejects mail from any host outside the zz domain, and all hosts in the yy.zz domain, except for xx.yy.zz. 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.
Calls are rejected as a result of these options by sending a 5xx 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, host_reject_recipients should be used instead of host_reject.
A call from a host which matches host_reject_recipients 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, via the recipients_reject_except option. This is commonly set to the local postmaster address.
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 sender_reject configuration option; see its description in chapter 11 for details.
Some MTAs continue to try to deliver a message even after receiving a 5xx error code for MAIL. The alternative configuration option sender_reject_recipients is provided for use in such cases. It accepts the MAIL command but rejects all subsequent RCPT commands.
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.
Incoming relaying is controlled by restricting the domains to which an
arbitrary host may send via the local host; this is done by setting
relay_domains. 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 host_accept_relay. For example, a delivery server uses this option
to list its client hosts.
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 local_domains then it is destined to be handled on the local host as a local address, and relaying is not involved.
This includes the case of addresses such as "x@y"@z where z is a local domain, which are sometimes used in an attempt to bypass relaying restrictions. Exim treats such addresses as having a local part x@y -- it does not strip off the local domain and treat x@y as an entirely new address. Assuming that x@y is not a valid local part, this means that the address is rejected, either at SMTP time if receiver_verify is set, or later when Exim tries to deliver to it. Addresses of the form "x%y"@z are treated in the same way, unless the `percent hack' has been enabled by setting percent_hack_domains. 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.
When the relevant domain is not in local_domains, there is first a check for legitimate incoming relaying, by seeing if it matches relay_domains, or, when relay_domains_include_local_mx 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
local_domains = foobar.com relay_domains = *.foobar.com
then mail from external hosts is rejected, unless it is for a domain ending in foobar.com.
Warning: Turning on the relay_domains_include_local_mx 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.
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 host_accept_relay. 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
host_accept_relay = 172.16.213.0/24
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.
The option host_auth_accept_relay is similar to host_accept_relay, 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 auth_hosts. You can set host_auth_accept_relay only if Exim has been compiled to support SMTP authentication. Chapter 35 contains more details.
In addition to the tests on the host, if sender_address_relay 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.
Normally, therefore, both the host and the sender must be acceptable before an outgoing relay is allowed to proceed. However, if relay_match_host_or_sender is set, an address is accepted for outgoing relaying if either the host or 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.
All three options, relay_domains, host_accept_relay, and host_auth_accept_relay, 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, but it does prevent the `percent hack' from relaying to arbitrary domains even when percent_hack_domains is set.
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 local_domains) may nevertheless end up being delivered locally, and similarly an apparently local address may end up being delivered to some other host.
None of the relay checking applies when mail is passed to Exim locally using the -bm, -bs or -bS options, but it does apply when -bs is used from inetd.
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 local_domains or relay_domains, 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.
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 prohibition_message, 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
prohibition_message = contact postmaster@my.site for details
causes the response to a RCPT command for a blocked recipient to be
550-contact postmaster@my.site for details 550 rejected: administrative prohibition
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 $prohibition_reason is set to a characteristic text string in each case. The possibilities are as follows:
host_accept_relay the host is not in an accept_relay list host_reject the host is in a reject list host_reject_recipients the host is in a reject_recipients list rbl_reject the host is rejected by an RBL domain receiver_verify receiver verification failed 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 reject_recipients list sender_verify sender verification failed
In addition, if relay_match_host_or_sender is set, there is
sender+host_accept_relay the sender is not in a sender relay list
and the host is not in an accept relay list
For example, if the configuration contains
prohibition_message = ${lookup{$prohibition_reason}lsearch\
{/etc/exim/reject.messages}{$value}}
and the file /etc/exim/reject.messages contains (inter alia)
host_accept_relay: host not in relay list
then a response to a relay attempt might be
550-host not in relay list 550 relaying to <santa@northpole.com> prohibited by administrator
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 expand operator. For example, the setting
prohibition_message = ${lookup{$prohibition_reason}lsearch\
{/etc/exim/reject.messages}{${expand:$value}}}
when used with a file entry of the form
host_accept_relay: Host $sender_fullhost is not permitted to
relay |through $primary_hostname.
might produce
550-Host that.host.name [111.222.3.4] is not permitted to relay 550-through this.host.name. 550 relaying to <penguins@southpole.com> prohibited by administrator
In the case of an RBL rejection, $rbl_domain contains the RBL domain that caused the rejection during the expansion of prohibition_message, and $rbl_text contains the contents of any associated TXT record. In all cases, $sender_host_address contains the IP address of the calling host.
Go to the first, previous, next, last section, table of contents.