Table of Contents

• I. Introduction
• II. Who Should Be Reading This Document
• III. General Issues of Spam Prevention Policy
• IV. Specific Issues of Spam Prevention Policy
• V. Basic Things You Can do to Prevent/Reduce Spam
• VI. Commonly Held Views About Spam
  • "Spam Can't be Stopped"
  • "Spam is the User's Responsibility"
  • "Spam is the Sysadmin's Responsibility"
  • Variations
• VII. Options for Individual Users
  • Using Realtime Third-Party Black-hole Lists
  • Using Your Own Black-hole Lists
  • Using Tagged Messages
• VIII. Options for System Administrators
  • Rejecting SMTP connections at the network level from hosts with bad DNS
  • Using your SMTP daemon to reject "known" spammers
  • Using qmail-smtpd to reject mail with invalid envelope or From headers
  • Make it hard to spam from your system to the outside world
• IX. Other Resources
• X. History
• XI. Comments/Feedback

II. Who Should Be Reading this Document

This document could be useful for

• UNIX system administrators
• qmail administrators
• System Use/Abuse Policy Makers
• Casual users of e-mail concerned about SPAM

III. General Issues

Spam is defined here as unsolicited commercial e-mail, usually sent in bulk. In other words, spam is simply electronic junk mail. Dealing with spam is, at best, a very difficult task. This is mostly true because spammers have a wide array of tools and circumstances available to them that make it easy for them to send you mail but difficult for you to communicate back with them or any authority over them. Spam is also difficult to deal with because it almost always comes in under the guise of being a normal e-mail message. No amount of technology can automatically decide what content is undesirable to you, but there are many ways to use technology to reduce the amount of unwanted e-mail you or your users receive.

For a more thorough explanation of the issues here, I recommend reading the IETF Anti Spam Recomendations. David E. Sorkin has produced an excellent document called Technical and Legal Approaches to Unsolicited Electronic Mail.

IV. Specific Issues of Policy

• Is the prevention of spam worth the time and resources required to reach a given level of spam reduction?
• Is the prevention of spam the responsibility of a system administrator or the responsibility of the end user?
• Should e-mail identified as potential spam be flatly rejected, or just tagged as spam and routed accordingly?
• Should system administrators (yours or anyone else's) who have misconfigured their systems be held responsible for any problems that result?
• Should you reject e-mail messages that are legitimate in content but that do not conform to known and accepted standards?
• Should you accept for delivery mail that does not have valid reply information (either in the envelope or From address)?
• What criteria should be met before an individual or ISP is justifiably classified as "spam-friendly"?

V. Basic Things You Can do to Prevent/Reduce Spam

• Don't use a dot-qmail-default file in a lazy way
  The dot-qmail-default file (e.g. '.qmail-default') makes any mailbox name on your system valid, whether or not it actually exists. While it can be useful as a catch-all for setups where there is a possibility that the sender would misspell the address, it often leads to an increased volume of spam from spammers who use made up aliases. Typical examples of this are "sales@domain.com", "webmaster@domain.com", and so on. Note that the dot-qmail-default file can actually be useful in fighting spam, if you set it up to process mail sent to invalid addresses and then reject the mail with useful error messages.

• Report any spam that you do get.
  Services like SpamCOP make this straightforward and efficient. See the resources section below for links.

• Educate
  Educate your users, friends, and family about spam, why it is (or is not) worth fighting, and what they can do. Spammers are successful in getting mail through because the typical end user doesn't understand the technical issues enough to make decisions about how to fight back.

• Make sure your system is properly configured
  All of the hosts on your system should have proper hostnames and corresponding IP addresses. Other systems should be able to properly resolve your hostname and IP address. Your mailer should issue standard error and warning messages when appropriate, and you should be aware of its configuration regarding rejection of messages. Adhering to standards is a good thing.

• Some people believe that any messages from senders who have been listed in one of the various "black hole lists" (see resources section for links) should be rejected without exception. Others sometime believe that these black hole lists are not always fair or just in their criteria for inclusion, and that depending on these lists would result in too many legitimate e-mails being rejected. Even others disagree with the use of the black hole lists because of grievances with the methodology the owners use to develop and maintain the lists.
• Some people believe that messages not conforming to known standards for mail delivery should be rejected or identified as potential spam. The most common example of this involves "From" headers or "envelope" addresses. These addresses are necessary to handle the "bouncing" of messages and for any sort of reply. For a variety of reasons, many spam messages do not have valid From or envelope headers. So, while some believe that any such message should be rejected, others hold that there are too many exceptions where these headers might be invalid but the content or intent of the message is legitimate.

MAILDIR=$HOME/mail
SPAMFOLDER=$MAILDIR/junkmail
LOGFILE=$MAILDIR/log


:0h
TCPREMOTEIP=| origip.pl
LOG="Remote IP: \"$TCPREMOTEIP\""

:0
* !^From.*myfriend@domain.com
* ! ? if [ -n "$TCPREMOTEIP" ]; \
      then /usr/local/bin/rblcheck -q "$TCPREMOTEIP"; fi
{
        LOGABSTRACT=all
        LOG="Filter: RBL-filtered address: \"$TCPREMOTEIP\""
        :0:
        $SPAMFOLDER
}

• SpamBouncer has a mechanism for tagged messenging
• Thomas Erskine wrote tms (Tagged Message Sender), which also does this.
• Jason R. Mastaler has taken tms and extended the project into Tagged Message Delivery Agent.
• Brett Randall has developed an avoidance technique especially for users participating in usenet and mailing list discussions.

VIII. Options for qmail Administrators

This section discusses options for system administrators who want to implement anti-spam mechanisms at the system-wide level. Please note that you should resolve the specific issues listed above before implementing any of these solutions, and that you should always notify your users of any changes to the system that affect the mail they do or don't receive.

Rejecting SMTP connections at the network level from hosts with bad DNS
It is becoming common for the default installation of many Unix operating systems like FreeBSD and Linux to include a mechanism to block network traffic based on certain criteria, commonly referred to "host-based access control" and commonly implemented using the tcp_wrappers package. In some of these installations, network traffic from hostnames that do not map to valid IP addresses is blocked. While not an e-mail specific measure, this is one way to cut down on e-mail from hosts that have misconfigured their DNS, and therefore are thought by some to be more likely to be spam-friendly.

If you're using inetd, an example line in a FreeBSD /etc/hosts.allow is here:
ALL : PARANOID : RFC931 20 : deny

One can also achieve this using the ucspi-tcp package's tcpserver (now the recommended alternative to inetd), by enabling the "-p" option, for paranoid, e.g.

tcpserver -p -v -x/etc/tcp.smtp.cdb -u1007 -g1007 0 25 \
qmail-smtpd 2>&1

Using your SMTP daemon to reject "known" spammers
In the ucspi-tcp package there is the rblsmtpd package, an alternative to the usual qmail-smtpd, and works with any SMTP server that runs under tcpserver.

So, if you follow the Life With qmail Installation guide, and then update your supervise scripts accordingly, your /var/qmail/supervise/qmail-smtpd/run script looks like this:

#!/bin/sh
QMAILDUID=`id -u qmaild`
NOFILESGID=`id -g qmaild`
MAXSMTPD=`cat /var/qmail/control/concurrencyincoming`

exec /usr/local/bin/softlimit -m 2000000 \
/usr/local/bin/tcpserver -v -p -x /etc/tcp.smtp.cdb -c "$MAXSMTPD" \
-u "$QMAILDUID" -g "$NOFILESGID" 0 smtp \
/usr/local/bin/rblsmtpd /var/qmail/bin/qmail-smtpd 2>&1

Note that the above is an updated version of the call to rblsmtpd; the previous version was only correct for older versions of daemontools, and is now deprecated. The upgrade is worth it.

If you're still using inetd, you can patch qmail to do about the same thing, or you can patch tcp_wrappers to use the RBL with software from SmallWorks.

If you want to use the ORBS database (or any other database with DNS access) in addition to the RBL, you can modify your rblsmtpd configuration with the "-r" option to do so.

rblsmtpd -rrelays.orbs.org -rrbl.maps.vix.com

Mike Silbersack says "If you wish to use the *.mail-abuse.org black-hole lists, you'll have to apply the patch to make rblsmptd work with A records"

Using qmail-smtpd to reject mail with invalid envelope or From headers
This area is a little blurry right now; it is the author's hope that readers will contribute their experiences here to improve the recommended options.

There are several patches out there that claim to make qmail reject messages with bad envelopes or From headers (i.e. if the envelope is blank or if the hostname in it doesn't have a valid DNS entry) or otherwise deal with suspected SPAM mail. Note that most of these patches are not featured on the qmail site and are therefore assumed to be "nonstandard".

• Nagy Balazs wrote a patch to ensure that the domain name on the envelope sender is a valid DNS name. This ensures that you do not receive email which you cannot bounce, should that prove necessary.
• Erwin Hoffman has written a patch for qmail-smtpd called SPAMCONTROL which improves qmail's filtering abilities and makes it RFC 2505 compliant. He and Noel Mistula also produced some scripts for filtering attachments and subject lines (something you can also do with procmail).
• The folks at flame.org wrote another patch that performs various header checks and bounce/flagging functionality
• Will Harris wrote a patch that allows you to use a new control file to specify Perl regular expressions to be used when checking the validity of the envelope sender.
• Mark Delany wrote a patch for qmail 1.01 which lets you match the envelope sender against a regex and accept or reject the mail accordingly.
• Jonathan McDowell has written an X-Spam-Warning header patch that adds warning headers for messages from senders in ORBS, RSS, RBL and DUL without the use of any external programs. This is useful if you want to allow your users to decide how to handle SPAM while tagging it as such at the system level.
• Jay Soffian has a script that also adds warning headers, but uses the existing QMAILQUEUE patch instead of patching qmail source itself.
• Chris Johnson wrote a patch to log attempted relay attempts

It should also be noted here that messages with recipient addresses in the form "user%hosta@hostb" are not going to be relayed through your system unless you have misconfigured something. See the qmail.faqts page on this issue for futher details.

Make it hard to spam from your system to the outside world

There are a variety of ways to make it difficult for your users to create spam. This is an important effort; while most of this document focuses on avoiding incoming spam, don't forget that a lot of incoming spam is generated because of overly lax mail sending policies.

• Chris Johnson has written a patch for qmail called tarpit. Tarpitting is "the practice of inserting a small sleep in an SMTP session for each RCPT TO after some set number of RCPT TOs." This discourages a user from using a given system as a relay.