A special feature allows Exim to handle mailing lists that are held separately from the alias file: if you specify:include: filename as a recipient, Exim reads the specified file and substitutes its contents as a list of recipients. An alternative to handling mailing lists is shown later in this chapter in "Mailing Lists".
The main aliases file is /etc/aliases. If you make this file world-writable or group-writeable, Exim will refuse to use it and will defer local deliveries. You can control the test it applies to the file's permissions by setting modemask in the system_aliases director.
This is a sample aliases file:
# vbrew.com /etc/aliases file
hostmaster: janet
postmaster: janet
usenet: phil
# The development mailing list.
development: joe, sue, mark, biff,
/var/mail/log/development
owner-development: joe
# Announcements of general interest are mailed to all
# of the staff
announce::include: /etc/Exim/staff,
/var/mail/log/announce
owner-announce: root
# gate the ppp mailing list to a local newsgroup
ppp-list: "|/usr/local/bin/gateit local.lists.ppp"
When there are file names and pipe commands in an alias file, as here, Exim needs to be told which userid to run the deliveries under. The user option (and possibly group, too) must be set in Exim's configuration file, either on the director that is handling the aliases, or on the transports to which it directs these items.
If an error occurs while delivering to an address generated from the aliases file, Exim will send a bounce message to the sender of the message, as usual, but this might not be appropriate. The errors_to option can be used to specify that bounce messages are to be sent elsewhere; for example, to the postmaster.
Mailing Lists
Instead of the aliases file, mailing lists may also be managed by means a forwardfile director. The lists are all kept in a single directory such as /etc/exim/lists/, and a mailing list named nag-bugs is described by the file lists/nag-bugs. This should contain the members' addresses separated by commas or newlines. Lines beginning with a hash sign (#) are treated as comments. A simple director to use such data is as follows:
lists:
driver = forwardfile
file = /etc/exim/lists/${local_part}
no_check_local_user
errors_to = ${local_part}-request
When this director runs, the values of the file and errors_to options are expanded. Expansion causes certain portions of the strings beginning with dollar characters to be replaced every time the string is used. The simplest kind of expansion is the insertion of the value of one of Exim's variables, and this is what is happening here. The substring ${local_part} substitutes the value of the $local_part, which is the local part of the address that is being processed.
For each mailing list, a user (or alias or mailing list) named listname-request should exist; any errors occurring when resolving an address or delivering to a list member are reported to this address.
Protecting Against Mail Spam
Mail spam, or unsolicited email advertising, is an annoying problem for many users. A project has been formed to address this problem called the Mail Abuse Protection System (MAPS), and a mechanism has been built that reduces the problem, called the Real Time Blackhole List (RBL). Information on how the MAPS RBL works can be obtained from its online documentation at http://maps.vix.com/rbl/. The idea is simple. Sites that are caught generating mail spam are added into the database and mail transfer agents like Exim are able to query the database to confirm that a source is not a spammer before accepting mail from it.
Since the advent of the RBL, several other similar lists have been created. One of the most useful is the Dial-Up List (DUL), which lists the IP addresses of dial-up hosts. These should normally send outgoing mail only to their ISP's mail servers. Many sites block mail from external dial-ups because when such a host avoids its own ISP's server, it is usually up to no good.
Exim provides support for the real-time and other blacklists. It is very easily configured. To enable it, add the following lines to your /etc/exim.conf file:
# Vixie / MAPS RBL (http://maps.vix.com/rbl)
rbl_domains = rbl.maps.vix.com: dul.maps.vix.com
This example checks both the RBL and the DUL, rejecting any messages from hosts that are on either list. The rbl_hosts option allows you to specify groups of hosts to which RBL checking does (or does not) apply. The default setting is:
rbl_hosts = *
which means that all hosts are subject to RBL checking. If you wanted to override blacklisting and accept mail from a specific host without performing the RBL checking you could, for example, use:
rbl_hosts =! nocheck.example.com: *
The exclamation mark before the first item in this list indicates a negated item: if the calling host is nocheck.example.com, it will match this item. But because of the negation, RBL checking is not performed. Any other host matches the second item in the list.
UUCP Setup
Exim does not have any specific code for transporting mail via UUCP, nor does it support UUCP bang path addresses. However, if domain addressing is being used, Exim can be interfaced to UUCP fairly simply. Here is a configuration fragment for sending certain domains to UUCP, taken from a real installation:
# Transport
uucp:
driver = pipe
user = nobody
command = "/usr/local/bin/uux -r - \
${substr_-5:$host}!rmail ${local_part}"
return_fail_output = true
# Router
uucphost:
transport = uucp
driver = domainlist
route_file = /usr/exim/uucphosts search_type = lsearch
In a complete configuration file, the transport would be inserted among the other transports, and the router probably defined as the first router. The file /usr/exim/uucphosts contains entries like this:
darksite.example.com: darksite.UUCP
which is interpreted to mean, "Send mail addressed to the domain darksite.example.com to the UUCP host darksite." This configuration could be set up more simply without the router adding the suffix.UUCP to darksite only to have the transport take it off again, but this way is useful because it makes clear the distinction between the domain name darksite.example.com and the UUCP host name darksite.
Whenever the router comes across a domain that is in the route file, it will send the address to the UUCP transport, which subsequently pipes it to the uux command (described in Chapter 16, Managing Taylor UUCP). If there is a problem, uux will generate some output and terminate with a non-zero error code. The setting of return_fail_output makes sure that the output is returned to the sender.