Milter-greylist

Oops, I sent with the wrong email address.  Looks like it was eaten by
yahoo, or it awaits moderator approval.  In the latter case, it can be
deleted as I am resending it from the correct account.

Ondrej Valousek wrote:
> 1) Your script only gathers info about the botnets from the spamcop
> site, but you also mentioned dnswl to whitelist the "promising" senders.
> How did you implemented this? senderbase is meant to be more like
> "scoring" system ranking the sender's IP from -10 (a spammer) to 10
> (innocent guy) -> so I thought we could use it for whitelisting as well.

We certainly can.  In fact, it would probably only take a small tweak
to my script to do that; offer a different URL and create a different
link and you're done.  That's a really good idea, actually.  I'll
implement it when I have a spare moment.

I currently implement this (as previously mentioned on this list):

dnsrbl "DNS Whitelist"  list.dnswl.org  127.0.0.0/16
racl whitelist dnsrbl "DNS Whitelist"

> I have almost persuaded my boss to engage greylisting to protect the
> whole company, but he is still sort of concerned about the possible
> delays it could cause (and I must admit, I understand that concern). So
> far, I am whitelisting all senders who passes the SPF check or are able
> to do the TLS encryption, but it would be nice to have some other
> judgement as well (SPF and TLS technologies are gaining the popularity
> quite slowly)

Yeah, I get complaints from co-workers on this every once in a while.
 Since spammers who don't forge sender domains can control their own
SPF records and thus bless their own botnets, I turned off SPF.  This
was the source of my request in early-mid March.

I've found "lazyaw" to be indispensable.  Without it, the most common
user complaint was "I didn't get an email from customer X, but
coworker Y did."  This solves that issue right off.  It also mostly
solves the issue of larger companies having a bazillion SMTP servers
(since the greylisting only examines the server rather than the server
plus the sender plus the recipient).  Its only real weakness is
against ISPs, free webmail providers, universities, and other giants,
which is why I proposed lazyaw thresholds and awspf (on March 11).

> 2) Before I went to the CiscoExpo, I was sort of careful about dnsbls or
> dnswls. How could we trust them?

Yeah, some admins just don't trust them.  I've been very happy with my
usage, and the numbers at http://stats.dnsbl.com are very heartening
(though that's only one source).  I do NOT block a single email based
on listing in DNSBLs.  Items that hit spamcop, spamhaus zen, PSBL, my
hacked spamcop /24 blocks, and SORBS DUN are all greylisted (with
SORBS DUN staying whitelisted for a longer time due to the massive
number of false positives), but nothing is blocked.

In Spamassassin, I've added PSBL and bumped up spamcop and SBL.  I
also created an adjuster to ensure a combination of DNSBLs doesn't
single-handedly auto-delete an email.  Here's a snippet from my
local.cf file; note I mark spam at 5.0 and reject it (at
connection-time via spamass-milter) at 8.0.  The "meta" line wraps:

# all but implicit trust for zen/spamcop/psbl, http://stats.dnsbl.com
# psbl doesn't exist - copied from http://psbl.surriel.com/howto/
header   RCVD_IN_PSBL eval:check_rbl('psbl', 'psbl.surriel.com.')
describe RCVD_IN_PSBL Received via a relay in PSBL Spamikaze trap
tflags   RCVD_IN_PSBL net
#     SCORE_NAME              -  n  b n+b     defaults
score RCVD_IN_PSBL            0 1.0 0 2.3   # suggested: 0 1 0 1
      score RCVD_IN_BL_SPAMCOP_NET  0 2.2 0 3.2   # 0 2.188 0 1.960
score RCVD_IN_SBL             0 2.5 0 2.5   # 0 2.810 0 1.551
#score RCVD_IN_XBL            0 2.5 0 3.0   # 0 2.896 0 3.033
#score RCVD_IN_PBL            0 0.5 0 1.0   # 0 0.509 0 0.905

meta ICS_DNSBL_ADJ      ( RCVD_IN_PSBL + RCVD_IN_BL_SPAMCOP_NET +
RCVD_IN_SBL + RCVD_IN_XBL ) > 2
describe ICS_DNSBL_ADJ  Undo autokill from possibly incestuous DNSBLs
score ICS_DNSBL_ADJ     0 -0.3 0 -1.8
# min:         7.8->6.0 / max: 8.7->6.9
# nobayes min: 5.7->5.4 / max: 7.2->5.4

> If one starts to be too popular, spammers might try to DOS it (it
> is a single point of failure).

Yup.  PSBL is down right now, perhaps due to an attack, perhaps
because it is a poorly funded free service.  None of these are
"single" points of failure.  They are all helpers in a larger picture
of fighting spam.  If they ALL went away, spam would continue to be
filtered.  My ADJ meta rul ensures delivery if some (or all!) of them
were compromised (i.e. filled with false positives).

> You say, report the spam to make it better, but how is it protected
> from the spammers filling it with a number if innocent senders?

Few (if any) reporting facilities share their data.  If you fill our
manual reports with Spamcop, they won't even store your email address
(though sometimes they're not so great about censoring it).  They
don't report headers to the public, and the automated system doesn't
report headers when they report spammers; that's for real-person dialogs.

As to "innocent senders," that's what reporting is all about; Spamcop
(et al) actually contacts the ISP or IT dept in charge and reports the
spam attempting to ebb the flow from the source (e.g. deny internet
access to a zombie system).  Reporting functions on relays rather than
apparent email addresses, so you need not worry about forged senders
(or even forged relays, since it only goes as far as the most recent
untrusted relay).  Peruse the Spamcop website for more detail.

> 3) I have installed your script to cron on our MTA (looks like it works
> fine) to give it a try. I am sure others would be interested as well.

Don't forget to install it; the output (emailed to you via cron) will
tell you that on the first run.

> What about putting it into our wiki so it won't get lost?

I did that yesterday :-D
http://milter-greylist.wikidot.com/local--files/downloads/greylist-spamcop-offenders
which is linked from the files section a the bottom of
http://milter-greylist.wikidot.com/downloads (could they hide it any
more?)