blocking vs scoring (from SANS)

[Jeff A. Earickson]

Gang,

   This was an article in the weekly SANS newsletter (www.sans.org)
on the issue of using DNSBL's to block (ie sendmail) versus spam
scoring (SpamAssassin).  Interesting points.  I've always been in
the "block 'em with sendmail, 500 error" camp, but I'm rethinking.
Of course MailScanner makes retooling easy...

Jeff Earickson
Colby College

 --Spam Filters In An Operational Environment
Analysis by Stephen Northcutt

In SANS/GIAC status report #17,
(http://www.sans.org/newsletters/statusupdates/17.php ) I editorialized
that using research grade spam filters in an operational production
environment could be a bad idea.  I am sticking to my guns, it appears
that Security Focus was blacklisted twice in the past 10 days; the lack
of a whitelist for known leaders during Internet crises is reckless.
Without such a safety mechanism, it would be simple for an attacker to
blacklist, CERT, SANS/dshield/Internet Storm Center, SecurityFocus,
Department of Homeland Security, NIPC just before releasing an attack.
A number of people have written with comments on the editorial ranging
from "Right on" to "SANS loves Spam".  But the most well written/well
reasoned comment was from Charles Oriez and is shown below:

There are several ways to properly manage the use of a Spamcop-like
dnsbl in such a fashion as to protect your resources while at the same
time limiting the damage from false positives.  I have been using
Spamcop on client systems for years with few false positives and few
problems, in part because of the effective safeguards that we put in
place.

For an automated list such as Spamcop where false positives tend to
disappear quickly, consider refusing the connection with a 400 series
transient failure message rather than a 500 series permanent failure
message.  True Spam sources seldom disappear from the Spamcop list
before the sending server gives up, but false positives almost always
will.  Also, during that window of time, the alert systems
administrator, who should be monitoring system logs for this and other
problems anyway, can step in to white list an appropriate CIDR
(65.173.218.0/24 in the case of SANS) fairly quickly.  The 400 series
error being returned at that point would then have cleared up and the
mail would have been delivered.

You can also use Spamcop and any of the other 500 plus dnsbls in a
fashion other than as a binary accept/reject decision point. Spam
Assassin[tm], for instance, uses a scoring system based in part on the
appearance of the originating IPA in Spamcop and other dnsbls, to
determine the likelihood that a particular email is spam. Score high
enough, and the suspect email is diverted to a separate mailbox for
further review.  The system can be adjusted in numerous ways to reduce
the risk of false positives, and since mail is merely diverted instead
of deleted, important missing emails can still be accessed by the end
user.