[wplug-internet] Spam filters

[Vance Kochenderfer]

On Wed, Jan 29, 2014 at 10:08:51PM -0500, Justin Smith wrote:
> We use Pair Networks for our email at work. The boss had me call them up 
> today because their spam filters weren't cutting it, and the rep I spoke 
> with walked me through setting up DNSBLs. They were so effective that it 
> was almost like flipping and "off" switch. I haven't received a single junk 
> email since then.
> 
> I was so impressed that I thought I'd give it a shot on our WPLUG mail 
> server. I added three DNSBLs: Spamhaus Zen, Spamcop, and another one 
> whose name escapes me because I'm on the verge of falling asleep.

This is not inherently a bad idea, but requires thought and
planning.  DNS block lists vary widely in their quality, even
among multiple lists from the same provider.  They *will* block
legitimate mail if not used carefully.

Five years ago, I ran a trial of pbl.spamhaus.org.  See
<http://www.wplug.org/pipermail/wplug-internet/2008-June/000115.html>
<http://www.wplug.org/pipermail/wplug-internet/2008-August/000116.html>
and the following messages in that thread for details.  We ended
up not using it because the benefit was small on top of our
existing countermeasures.

My view on the proposed block lists:

zen.spamhaus.org - I have a generally favorable impression of
Spamhaus, but the ZEN list combines four separate lists
<http://www.spamhaus.org/zen/>.  In my view, the PBL is the
component list likely to be most stable and best curated, while
the others have more activity and are more prone to error.  This
is why I started with the PBL in my testing.  I would want to see
good data on false positives for the complete ZEN list before
using it.  The component lists could also be judged/used
individually.

dnsbl.sorbs.net - This list is a combination of 11 lists with
various goals <http://www.sorbs.net/general/using.shtml>.  Some of
these lists have nothing to do with e-mail.  I would only consider
adding them if Spamhaus alone was not effective enough, and the
data showed it would provide additional gain without false
positives.

bl.spamcop.net - SpamCop is based (in part) on user submissions,
which are not 100% reliable.  Even they themselves do not
recommend outright blocking mail based on their list
<http://www.spamcop.net/fom-serve/cache/297.html>.  My impression
of SpamCop, admittedly based on hearsay rather than personal
knowledge, is that they play fast and loose and don't worry too
much about the consequences of an incorrect listing.  They are IMO
a last resort and I would have to see very compelling evidence
before using them.

With any of these, I would want to set check_recipient_access to
exempt mail addressed to postmaster@ or abuse@ from any DNSBL
checks.  If there is a problem with a list, there needs to be a
way to contact the admins to work it out.

For now, I've added warn_if_reject to the DNSBL configuration so
that matches are logged, but do not result in rejecting mail.
This will allow us to collect statistics without the risk of
blocking legitimate mail.

(For your workplace, you may want to take some of the same
concerns above into consideration.  If most of the people who send
you e-mail have a pre-existing relationship, it may not be as much
of an issue.  But since WPLUG could potentially get valid mail
from a wide variety of correspondents, false positives are a real
problem.  I would strongly recommend you look into greylisting
<http://wiki.centos.org/HowTos/postgrey> - it is extremely
effective and safe.  However, it can introduce annoying delays to
users who expect e-mail to be "instant," so you need to understand
its behavior before subjecting your users to it.)

Sorry for seemingly throwing cold water on your idea, but DNSBLs
are one of those things that seem simple at first but can result
in nasty unintended consequences.  Please feel free to engage and
discuss on this issue.

Vance Kochenderfer        |  "Get me out of these ropes and into a
vkochend at nyx.net          |   good belt of Scotch"    -Nick Danger