|‚ < ‚ Day Day Up ‚ > ‚|
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
220.127.116.11 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.
18.104.22.168 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:
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
22.214.171.124 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 .
|‚ < ‚ Day Day Up ‚ > ‚|