Anti-spam modifications for Zmailer 2.2e10
This directory contains various patches developed by the
Unix Systems Group, primarily by
Chris Siebenmann,
for Zmailer 2.2e10 and associated programs and put into use on
our systems. In the tradition of such things, we disclaim any
responsibility if your machine explodes after you install some
or all of these; to quote from days of yore:
No warranties whatsoever -- we stoutly deny any possibility
that this may actually compile to anything resembling working
binaries on any given system.
However, we use this code on our systems and would appreciate
hearing about any problems you encounter or any improvements
you make.
Although these patches are for Zmailer 2.2e10, it's likely that
at least some of them will apply to any version of Zmailer 2.2.
For Zmailer 2.99 you're on your own, although the author understands
that that version of Zmailer now has integral antispam stuff in its
smtpserver (this is likely superior to these patches for high volume
sites).
The discussion of some of these patches assumes familiarity with
how SMTP works. Applying these modifications requires familiarity with
patching files, compiling programs, and operating Zmailer; some of the
modifications may require familiarity with the Zmailer configuration
file language.
What seems to work well
Verifying origin addresses is a reasonably decent win at the moment,
although the use is slowly decreasing as spammers get smarter. Our spam
trapped addresses typically yield pretty good benefits (partly because
we have a long history, which gives us lots of now-bad addresses that
are on spammer lists that we can trap), as does rejecting all-numeric
usernames from commonly abused domains that don't support them (part of
badusers.cf).
I strongly urge people to look carefully at how much mail your users
get from where before adopting some of our policies on things to reject.
Your users may have very different patterns of who they correspond with
than ours do that may make our decisions unsuitable for you. Consulting
with your users may be necessary.
Cautionary Basic Theory
These patches function by verifying all MAIL FROM: and RCPT TO:
addresses during the SMTP conversation. In order to do this, the
SMTP server forks a router process and passes it various commands
(this is also how VRFY and EXPN is supported). MAIL FROM and RCPT
TO verification must be specifically enabled in your
$MAILSHARE/smtpserver.conf file.
Because it starts a router process per SMTP connection, this
approach may overload a small machine or a machine receiving
a large volume of mail. In our environment this hasn't proven
to be a problem, and besides one can limit the maximum number
of simultaneous connections as part of the patch to the SMTP
server.
Modifications
Some of these modifications are interrelated, or otherwise have prerequisites.
Some of these modifications contain local policies; sometimes they contain a
LOT of local policies. Please be sure to review such policies
to make sure they're suitable for your local use. You will want to
download these files in a way that saves them to your local disk (unless
you just want to read them; all of them are ASCII files).
- smtpserver/smtpserver.c mods
- This patch adds support for TCP Wrappers, for a maximum number
of connections, and for letting the router verify SMTP HELO greetings.
See some sketchy documentation for
usage details. Use of SMTP HELO greeting verification requires a modified
$MAILSHARE/cf/server.cf
file, assuming you want to receive any mail. This patch is almost entirely
policy free.
- relay-*.cf sharfile
- This is a shar file of relay-check.cf and relay-policy.cf, which
together implement (but do not control) the anti-relaying portions and
some of the bad address and domain rejection portions of
our anti-spam modifications. They need to be placed with the rest of
your Zmailer cf files, in $MAILSHARE/cf, and then called from
your server.cf file; see ours for an example of how. They are driven
from configuration files in $MAILVAR/db/relay; see the comments
in the source for details
on how this all works.
They contain a tiny modicum of policy, both in terms of what relaying
policy they let you implement (without code changes) and on how qualified
they
insist on addresses being in some circumstances.
- flushot.cf
- This Zmailer cf file (which must be placed in $MAILSHARE/cf)
implements spam-trapped addresses. If mail is sent to these addresses its
origin address is logged and trapped and further mail from that origin
will be rejected with a 454 error until the trap is cleared (either because
it's not really spam, or because you've added it to the list of truly bad
addresses). The list of addresses is in the code, but I've deleted ours.
It requires our server.cf file or something that calls its functions in
the right place, and also requires you to touch the file
$MAILSHARE/db/relay/flushots before you use it. You will want
to monitor this file regularly.
It also contains a local policy of giving 454 errors on all-numeric
user names unless we either know they're bad or they're from a specifically
exempted domain. You will need our badusers.cf file unless you
delete this.
- badusers.cf
- This Zmailer cf file contains a bunch of heuristics to reject
various sorts of bad origin addresses (and sometimes bad destination
addresses). These are HIGHLY dependent on local policies,
local mail setups, and what sort of spam you see; they work for us,
but not necessarily anyone else. The functions here must be called
from server.cf; some of them require HELO verification to be on.
- nscheck.shar
- This is a program to check whether the nameservers for a given
domain or host would normally be refused a connection to your SMTP
server by your TCP Wrappers configuration. It has very little
documentation. Our badusers.cf file uses it. The intended use is to
avoid having to maintain a list of CyberPromo/Nancynet/etc domains;
simply add their DNS servers or subnets to your TCP Wrappers shun
lists, and then any MAIL FROM of a domain served by them will be
rejected.
You do not need this program to use our badusers.cf file. If you
do want to use it, you should put it in $MAILBIN/cks/,
where our badusers.cf file expects to find it.
- server.cf
- Our version of the Zmailer 2.2e10 control file that handles
all SMTP-time address verification and expansion. This has various
small bugfixes and a large dose of both general and local anti-spam
support. In order to use it you need all of the above Zmailer cf
files. To enable the configuration-file driven anti-relay stuff,
you need to define the RELAYCHECK environment variable, such as by
putting
RELAYCHECK=1
in your /etc/zmailer.conf file.
This file does handle verifying HELO names, requiring them
to be fully qualified and saving the resulting name.
- a patch to aliases.cf
- This is a patch for aliases.cf that allows rejection of non-existent
local users during the RCPT TO verification process. This is a serious win
for us, since a fair amount of spam is sent to non-existent users; we would
otherwise accept it, process it, bounce it, and often the bounce would then
bounce back into the postmaster mailbox.
As of September 29th 1997, these are our current files (somewhat
edited for public consumption). Also available is a
sharfile of
our current $MAILSHARE/db/relay directory (minus the flushot
data files), showing
the control files in use for the anti-relay policy code.
These files may serve as a starting point for people, especially
those inside the University of Toronto.
Other Components
Although these are all our Zmailer modifications, they're only a
part of our overall anti-junk-email precautions. You can find more
detail about those here.
This page along with this set of code is primarily maintained
by Chris Siebenmann, who hates junk email and other
sorts of spam.