8.6 Building a Spam-Checking Gateway

Any of the approaches discussed earlier can form the basis for a spam-checking Exim gateway. exiscan or sa-exim will likely yield better performance than a router/transport approach, and I recommend using them unless you need per- user preferences and are prepared to configure spamd to perform SQL-based lookups. The remainder of this chapter explains how to configure an Exim-based gateway for routing messages and how to add sitewide Bayesian filtering and autowhitelisting .

8.6.1 Routing Email Through the Gateway

Once you have Exim receiving messages for the local host and performing SpamAssassin checks on them using any of the methods outlined earlier, you can start accepting email for your domain and routing it to an internal mail server after spam-checking. Figure 8-5 illustrates this topology.

Figure 8-5. Spam-checking gateway topology

8.6.1.1 Exim domain lists

To configure Exim to relay incoming mail for example.com to internal.example.com , add the following lines to Exim's configuration file:

 domainlist local_domains = @ domainlist relay_to_domains = example.com 

The key feature of this configuration is that example.com is a domain to which Exim may relay but is not on the list of local domains (for which mail is to be delivered on this host). Remember that you must restart Exim after changing its configuration file.

8.6.1.2 Routing changes

Mail from the Internet for example.com should be sent to the spam-checking gateway mail.example.com . Add a DNS MX record for the example.com domain that points to mail.example.com .

Once received by mail.example.com , messages will be spam-checked and should then be relayed to internal.example.com by Exim. There are two ways to get Exim to relay these messages:

• Set up an internal DNS MX record for example.com pointing to internal.example.com . When Exim on mail.example.com attempts to deliver messages for example.com , the dnslookup router will look up this MX record and deliver the messages to the internal mail host. This configuration may require that you run a "split DNS" system or use BIND 9's views feature to ensure that different MX records for example.com are published to the Internet and to internal hosts .

• Set up a new Exim router using the manualroute driver to manually route incoming messages for example.com to the internal mail host. The router definition, shown in Example 8-12, should be placed in the list of routers before the dnslookup router. In this case, mail.example.com need only be able to resolve internal.example.com (or the IP address for internal.example.com could be substituted for its name in the router definition).

Example 8-12. Using a manualroute router to relay messages

 internal_relay:   driver = manualroute   domains = example.com   transport = remote_smtp   route_list = example.com internal.example.com 

8.6.1.3 Internal server configuration

Once the external mail gateway is in place, you can configure the internal mail server to accept only SMTP connections from the gateway (for incoming Internet mail). If you don't have a separate server for outgoing mail, the internal mail server should also accept SMTP connections from hosts on the internal network. These restrictions are usually enforced by limiting access to TCP port 25 using a host-based firewall or a packet-filtering router.

8.6.2 Adding Sitewide Bayesian Filtering

You can easily add sitewide Bayesian filtering to any of the Exim approaches because they are all based on spamd . Use the usual SpamAssassin use_bayes and bayes_path directives in local.cf , and ensure that spamd has permission to create the databases in the directory named in bayes_path . Use a directory for the databases that is owned by spamd 's user, such as /var/spamd (or perhaps use /etc/mail/spamassassin ). If local users need access to the databases (e.g., they will be running sa-learn) , you may have to make the databases readable or writable by a group other than spamd 's and adjust bayes_file_mode . Or you can make the databases world-readable or world-writable. Doing so, however, is unlikely to be necessary on a gateway system and puts the integrity of your spam-checking at the mercy of the good intentions and comprehension of your users.

8.6.3 Adding Sitewide Autowhitelisting

Adding sitewide autowhitelisting is very similar to adding a sitewide Bayesian database. Just add the usual SpamAssassin auto_whitelist_path and auto_whitelist_file_mode directives to local.cf . As with the Bayesian databases, spamd 's user must have permission to create the autowhitelist database and read and write to it. In SpamAssassin 2.6x, spamd must be started with the --auto-whitelist option; this option is not needed (and is deprecated) in SpamAssassin 3.0 .