Fighting spam – greylisting take 2

You don’t really want to know, but I’ve spent my morning fighting spam.  It’s a periodic activity, makes me almost want to go back to the MailFrontier days when I could focus on these topics as a full time thing.  Though on the advantage side I can use a lot more off the shelf components in my battles.

If you recall I’ve been running sqlgrey on my box for a while, but over time more and more spam is getting through.  It’s primary objective is to slow down enough “unknown” email that other distributed sources will report on it’s true quality.  The problem is that looking at my logs that the spammers have worked out reasonable courses to get things routed onto white lists.

While I can’t say I’ve totally automated the process I’ve made one primary enhancement to sql grey which is adding a “BAD_IP” table which allows for either fully qualified IP addresses or /24 (Class C) versions of IP addresses to be added.   If an inbound message sources from one of these IP addresses then it’ll be “special”.  Two things happen with special IP addresses –  Longer greylisting cycle and they’re not allowed to be whitelisted.

The second part — which isn’t automated, today — is that my postfix log is chock full of all of the address probing going around.  So, all I need to look at is the IP addresses that are sourcing in lots and lots of probes.  If I see a lot of probes from your IP address you get added to the BAD_IP table.

Though as a feature request… I have a 60% solution in place, which is a python version of sqlgrey!  Not that I’m a big python person (ok, maybe converting slowly).  But, I’ve gotten to be a big OO person and procedural programming wrapped in a object wrapper is a bit “ugly”.