[conspire] Antispam at the level of the SMTP daemon

Rick Moen rick at linuxmafia.com
Mon Oct 3 13:10:33 PDT 2011


A friend forgot that she'd asked me to monitor the expiration status of
her domain, and at first thought I was asking to take over that domain,
which just expired.  She's now clarified that she's going to renew it,
but is tired of dealing with e-mail spam, and asked my advice.

What I recommended is tested on the ground, and also got used in
building a new server for Peter Knaggs to host PenLUG on.


----- Forwarded message from Rick Moen <rick at linuxmafia.com> -----

Date: Mon, 3 Oct 2011 13:01:28 -0700
From: Rick Moen <rick at linuxmafia.com>
To: [a friend]
Subject: Re: You need to renew grrattitude.com
Organization: If you lived here, you'd be $HOME already.

Quoting [my friend]:

> No, it is not really deliberate.  I'll get on it.  My memory sucks.
> But if  you know how to handle the I-get-5000-spam-a-day that goes with
> owning a domain, I'd sure like to hear about it.

This problem divides into two cases, where your domain either does or
does not accept SMTP mail.

Case 1 (no SMTP acceptance):  In this case, your only spam exposure is
via your published domain contacts (Registrant, Administrative Contact,
Technical Contact, Billing Contact) in the public whois.  Some people
evade this spam by using registrars' 'privacy proxy' service, whereby
the whois data show only intermediate e-mail addresses supposedly
monitored by the registrars to let through only legitimate mail.  I
recommend against such services, in part because I conducted
deliverability tests with a friend who had such a domain, and he never
got my mail.

You can cut by two nines the amount of spam reaching your domain
contents by using addresses at SMTP hosts with strong spam rejection, a
subject covered below.


Case 2 (SMTP acceptance):  A successful SMTP antispam strategy in 2011
is one with maximal detection in the front-end of the SMTP daemon, where
various heuristics are applied to measure spamicity of the mail _before_ 
the receiving MTA accepts the incoming mail.  I keep seeing sysadmins
and users attempting to apply antispam at later stages of mail-handling
including the local delivery agent and the MUA.  Those are WAY too late
for satisfactory results.

Unfortunately, all MTA default setups are miserably inadequate in this
area.  Therefore, substantial configuration work and connection of
ancillary software to effectively measure spamicity during the incoming
SMTP conversation are required.

Some people claim to have implemented effective spam rejection during
SMTP delivery ('before-queue') in Postfix using some software speaking
to the milter interface.  See:
http://www.postfix.org/MILTER_README.html  I cannot speak to that, but I
_can_ speak to the high effectiveness of such measures with the Exim4
MTA.  I recommend highly a kit of canned configurations for Exim4 by
J.P. Boggis, called 'Eximconfig'.  You can find it via this link in my
knowledgebase:

'Eximconfig' on http://linuxmafia.com/kb/Mail/


I started having a permanent 24x7 presence on the Internet in the early
1990s, and I'll be damned if I'm going to be driven off it, or deterred
from using an essential service like SMTP, by the likes of spammers.
Strong spam rejection at the SMTP level is the key to dealing with that
problem, and averts the need for the usual ignominious dodges such as
'hiding from spammers' (treating your address as a secret, and hoping
it's not discovered by the wrong people) and hiding behind someone
else's webmail service.

I keep hearing people talking about how good GMail's antispam is, and,
frankly, its effectiveness sucks compared to that of even my ancient
Pentium III with a slightly broken Exim4/Eximconfig/SA-Exim/SA setup,
which does a lot better than GMail does.


----- End forwarded message -----




More information about the conspire mailing list