5.3 Building a Spam-Checking Gateway

By combining sendmail, MIMEDefang, and SpamAssassin, you can build a complete spam-checking gateway. Such systems are increasingly popular as external mail exchangers, receiving messages from the Internet and relaying them to internal mail servers that don't perform their own spam-checking (either for performance reasons or because they run operating systems that don't provide cost-effective antispam solutions). I assume that users relay outgoing mail through an internal mail server, rather than through the spam-checking gateway. Figure 5-2 illustrates this topology.

Figure 5-2. Spam-checking gateway topology

The example gateway in this section is based on actual gateways in operation on the Internet. Although I provide complete configuration files for the example, I discuss only those aspects of configuration directly relevant to spam-checking.

5.3.1 sendmail Configuration

In our scenario, the spam-checking gateway should accept messages for our domains, check them for spam, and relay them to an internal mail server. Accordingly, I include the following in our sendmail configuration:

• The mailertable feature, which we may use to indicate the internal server to which we'll relay checked messages.

• A one- hour timeout before sending a warning message about delayed delivery, and a seven-day timeout before bouncing messages. If the internal server should fail and need to be replaced , senders will quickly know that their messages have been delayed, but messages won't be bounced unless you can't replace the internal server within a week.

• Several configuration options to limit sendmail's resource usage. We limit sendmail to 60 forked child processes and 10 connections per second. We limit messages to 10Mb and 500 recipients each.

• An INPUT_MAIL_FILTER definition for MIMEDefang.

Example 5-10 is the sendmail.mc configuration file for the gateway and is used to generate /etc/mail/sendmail.cf .

Example 5-10. sendmail.mc file for a spam-checking gateway

 divert(-1) # # Spam-checking gateway configuration # divert(0)dnl VERSIONID(`Spam-checking gateway') OSTYPE(linux)dnl DOMAIN(generic)dnl FEATURE(virtusertable)dnl FEATURE(mailertable)dnl FEATURE(access_db)dnl FEATURE(always_add_domain)dnl FEATURE(nouucp,`reject')dnl FEATURE(`relay_based_on_MX')dnl define(`confDEF_USER_ID',``8:12'')dnl define(`confPRIVACY_FLAGS',`goaway,noreceipts,restrictmailq,restrictqrun,noetrn' dnl Since this is for a gateway MX, we keep the queue around for a long dnl time without bouncing messages, but we warn about delivery delay dnl rather quickly define(`confTO_QUEUERETURN',`7d')dnl define(`confTO_QUEUEWARN_NORMAL',`1h')dnl dnl Options to prevent denial-of-service define(`confMAX_DAEMON_CHILDREN',`60')dnl define(`ConfMAX_MESSAGE_SIZE',`10000000')dnl define(`confMAX_CONNECTION_RATE_THROTTLE',`10')dnl define(`confMAX_RCPTS_PER_MESSAGE',`500')dnl INPUT_MAIL_FILTER(`mimedefang', `S=unix:/var/spool/MIMEDefang/mimedefang.sock, T MAILER(smtp)dnl MAILER(local)dnl MAILER(procmail)dnl 

Because mail destined for the example.com domain should not be delivered locally on the external gateway, do not include example.com as one of the gateway's local hostnames in the /etc/mail/local-host- names ( /etc/mail/sendmail.cw on some systems) file.

5.3.2 SpamAssassin Configuration

Store the SpamAssassin configuration for a gateway in /etc/mail/sa-mimedefang.cf . In addition to setting the typical options, it's a wise idea to use the trusted_networks (and, in SpamAssassin 3.0, internal_networks ) directive to define the boundary between trusted and untrusted networks. Example 5-11 shows the sa-mimedefang.cf file on a system configured to use a sitewide Bayesian database.

Example 5-11. sa-mimedefang.cf file for a spam-checking gateway

 required_hits 5 # These are hosts that we control internal_networks 192.168.10/24 # This is a backup MX that's offsite trusted_networks 111.222.333.444 bayes_path /var/spool/MD-Bayes/bayes 

5.3.3 MIMEDefang Configuration

After installing MIMEDefang, set up three directories:

/var/spool/MIMEDefang

To contain MIMEDefang's working directories, and to hold the socket and pid files. Mount this directory on a RAM disk for increased performance.

/var/spool/MD-Quarantine

To contain quarantine directories.

/var/spool/MD-Bayes

To hold the Bayesian database files.

Each of these directories should be owned by the user under which MIMEDefang runs (typically, defang ).

Edit mimedefang-filter to configure it for your gateway. Example 5-12 shows the first portion of a mimedefang-filter script corresponding to the example gateway I'm describing in this chapter. Each of the key variables in the file is defined.

Example 5-12. mimedefang-filter configuration for a spam-checking gateway

 #*********************************************************************** # Set administrator's e-mail address here.  The administrator receives # quarantine messages and is listed as the contact for site-wide # MIMEDefang policy.  A good example would be '[e-mail]' #***********************************************************************  $AdminAddress = '[e-mail]'; $AdminName = "Example.com Postmaster";  #*********************************************************************** # Set the e-mail address from which MIMEDefang quarantine warnings and # user notifications appear to come.  A good example would be # '[e-mail]'.  Make sure to have an alias for this # address if you want replies to it to work. #***********************************************************************  $DaemonAddress = '[e-mail]';  # Allow SpamAssassin to use network-based tests  $SALocalTestsOnly = 0;  

5.3.4 Routing Email

Mail from the Internet for example.com should be sent to the spam-checking gateway mail.example.com . To accomplish that, add a DNS mail exchanger (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 . You can accomplish that relaying in one of two ways:

Using DNS

Provide mail.example.com with an MX record for example.com pointing to internal.example.com and having a lower preference value (more preferred) than the mail.example.com MX record. This requires that you provide different results to DNS queries from Internet hosts versus queries from mail.example.com . Do so by running so-called split DNS, or by using BIND 9's view directives. Internet hosts should see only the mail.example.com MX record, but mail.example.com (and probably all internal hosts and clients ) should see the internal.example.com MX record.

Using mailertable

Add FEATURE(`mailertable') to the sendmail.mc file, and create a /etc/mail/mailertable file that instructs sendmail where to forward messages destined for example.com :

 example.com    esmtp:internal.example.com 

or:

 example.com    esmtp:[192.168.10.55] 

After editing mailertable , be sure to use makemap to build the mailertable.db database from the mailertable file.

5.3.5 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. This restriction is usually enforced by limiting access to TCP port 25 using a host-based firewall or a packet-filtering router.

5.3.6 Testing

You should now have a complete, spam-checking gateway. Test the gateway by sending spam and non-spam messages to [e-mail] . Messages should arrive at internal.example.com with Received headers that show that they were first received by mail.example.com and then by internal.example.com , and X-Scanned-By headers that mention MIMEDefang. Spam messages should have X-Spam-Status headers added as well.