Cover V12, I05

Article
Listing 1
Listing 2
Listing 3
Listing 4
Listing 5
Listing 6

may2003.tar

Spam-Proofing Your Qmail Server

Chris Woodard

The Mail Transfer Agent (MTA) qmail is a popular alternative to Sendmail. Qmail has a number of features that make it easy to spam-proof. Qmail separates the functions of SMTP transaction capture and delivery queuing into different processes. It does this in such a way that external programs can be invoked to intercept messages on their way from the SMTP daemon to the delivery queuing daemon and filter out those that meet the organization's criteria for spam (including originating IP, keywords in the title or message body, or Bayesian word distribution). This can help reduce the amount of incoming spam. Qmail also has a feature that lets an administrator keep spammers from using the mail server as a mail relay to hide the origin of the spam.

Overview of Qmail Architecture

Qmail, which is available from: http://www.qmail.org is implemented as a cluster of processes that handle remote-to-local, local-to-remote, remote-to-remote (relaying), and local-to-local delivery of messages. Interaction with SMTP clients (e.g., Pine, Outlook, and Eudora) is done through the qmail-smtpd program, which receives and processes the SMTP command stream and then passes the message to qmail-queue. The qmail-queue then is responsible for running the qmail-lspawn and qmail-rspawn processes (for local and remote delivery, respectively):

qmail-smtpd -> qmail-queue -> qmail-lspawn -> qmail-local
qmail-smtpd -> qmail-queue -> qmail-rspawn -> qmail-remote
This architecture provides two main points for intercepting inbound spam. A message can be intercepted either before it reaches the Qmail SMTP daemon qmail-smtpd, or after it is queued but before it is locally delivered to a user. Qmail also provides a central point of interception for outbound spam.

Blocking Outbound spam

Given qmail's architecture, blocking outbound spam can be done in at least two ways. Since all spammers use SMTP clients to send messages via relays, administrators can block the spammer at the SMTP interface by (a) requiring a username and password before messages can be sent or (b) only allowing outbound email to be sent from clients connecting from inside the organization's network.

The first method requires the administrator to apply the SMTP AUTH patch, which is available at: http://members.elysium.pl/brush/qmail-smtpd-auth/.

This patch implements the SMTP AUTH protocol, which interacts with most modern mail clients and requires credentials to be supplied before an email message can be sent. It modifies qmail so that it invokes a program to check a username and password before queuing a message for delivery. This program exits with a 0 if the username and password supplied by qmail are valid, and nonzero otherwise. This is useful, but it requires vigilance on the part of the administrator.

Spammers have programs that will test an MTA to see whether the VRFY and EXPN commands are enabled. If they are, it is only a matter of time before a dictionary attack or simple brute-force enumeration reveals one or more usernames or passwords. Even if VRFY and EXPN are disabled, brute-force attacks can reveal usernames and passwords (although it will take much longer for them to do so).

The second method, which is more effective, requires some explanation of qmail's configuration files. Instead of using one monolithic configuration file, qmail uses several smaller control files that manage different phases of its operation. Two files that are relevant here are rcpthosts and morercpthosts. They contain domains to which qmail will send mail. If rcpthosts exists, then outbound email can only be sent to hosts in that file (or in morecpthosts). That can be temporarily overridden, however. If the RELAYCLIENT environment variable is set, then qmail ignores the rcpthosts and morecpthosts files and allows outbound mail to be sent anywhere. This RELAYCLIENT variable must be set for connections originating within the organization's network and not for connections originating outside of the organization's network.

For this to work, the superdaemon must be configured so that it uses tcpwrappers instead of directly connecting to the service daemon. Red Hat Linux ships with xinetd (http://www.xinetd.org) as the superdaemon, so that is the one we will discuss. Xinetd effectively replaces inetd, and many of the configuration fields have the same meaning for both daemons. The configuration files for xinetd are normally installed in /etc/xinetd.d, and there is one configuration file for each accessible daemon. An example configuration file for smtp is shown in Listing 1.

Note that the server command line uses tcpd, which reads and loads the /etc/hosts.allow file and sets the RELAYCLIENT variable in conjunction with tcp-env (see Listing 2). This allows qmail to ignore the rcpthosts file and permit outbound email, but only for requests authorized by /etc/hosts.allow. In conjunction with the SMTP AUTH patch this effectively prevents spammers from using your qmail server as a relay. However, there are no guarantees, and full protection will involve periodically examining /var/log/maillog for suspicious patterns of activity.

Blocking Inbound spam

Blocking inbound spam can also add a layer of relay protection. Spammers love to use the trick of sending email to an MTA with a legitimate inbound envelope but with the RFC 821 headers set to target a number of unsuspecting users (such as having the BCC: line set to contain a hundred or more addresses). By filtering out this type of email before it is processed by qmail-delivery, one spam avenue is closed. (See Listing 3 for an example.)

Qmail supports per-user .qmail files, which are loaded and run as each message intended for a given user is processed for delivery. A user's .qmail file is located in his or her home directory. Each message intended for a given user is passed through the commands in his or her .qmail file, and the message is either accepted or rejected for local delivery.

To implement a server-wide spam prevention policy, the filtering programs must be interposed between qmail-smtpd and qmail-queue to prevent spam-likely messages from even being queued for delivery at all. This requires a number of patches whose installation and configuration are beyond the scope of this article, but that can be found at: http://www.qmail.org.

Mail::Audit

Mail::Audit is a Perl module that parses the RFC 821 format messages and makes them available for processing and filtering. Mail::Audit filters are Perl scripts that use Mail::Audit to parse email messages and search the resulting message components for signs of spam (e.g., "Viagra" or "Rich" in the subject line). If those signs are found, then the message can be rejected with or without a message (or the message can be forwarded to a site that collects and analyzes spam). Sample Mail::Audit scripts are shown in Listings 4, 5, and 6.

To use a Mail::Audit filter in qmail on a per-user basis, this line:

preline ~/myfilter.pl
must be placed in the .qmail file in the user's home directory. To filter out spam server-wide, the simplest method is to make sure that all users' home directories contain that .qmail file.

SpamAssassin

SpamAssassin (http://www.spamassassin.org) is a command-line utility and library that incorporates a number of spam-fighting techniques into a single package. SpamAssassin includes Bayesian keyword analysis and RBL (real-time blacklist) support. After installation, using SpamAssassin is straightforward -- simply add it to the .qmail file in each user's home directory:

preline spamassassin
You can also use SpamAssassin and Mail::Audit by downloading and installing the Mail::SpamAssassin Perl module (http://www.cpan.org). This allows you to write more specific filtering scripts, including scripts that forward spam-to-spam collectors.

Conclusion

Spam-proofing a qmail server is relatively straightforward and effective. By using open source tools, systems administrators can protect their networks from being spammed and from being used to spam other networks.

References

1. Tcpd -- http://www.linuxgazette.com/issue15/tcpd.html

2. Tcpd source -- ftp://ftp.funet.fi/pub/Linux/PEOPLE/Linus/net-source/base/tcp_wrappers_7.4.tar.gz

3. Open Source Email Security by Richard Blum, SAMS Publishing.

4. Xinetd -- http://www.xinetd.org

5. Qmail -- http://www.qmail.org

6. SpamAssassin http://www.spamassassin.org

7. Mail::Audit -- http://simon-cozens.org/writings/mail-audit.html

8. Email headers -- http://www.stopspam.org/email/headers/headers.html

9. SMTP AUTH patch -- http://members.elysium.pl/brush/qmail-smtpd-auth/

10. General SPAM information -- http://www.cs.uu.nl/wais/html/na-dir/net-abuse-faq/spam-faq.html

Chris Woodard develops PHP-based Web sites and maintains Web and mail servers for internetpestcontrol.com, an Internet security company that does Web, FTP, and email security audits for small businesses. He also writes and teaches courses on UNIX, Linux, C, C++, Java, PHP, and MySQL. He can be reached at cwoodard@internetpestcontrol.com.