Greylisting
I’ve just installed postgrey at webthing. So I’m (experimentally) greylisting incoming mail.
Since people say greylisting is so effective, I’m also dropping the more fallible part of my existing spam filtering as part of the experiment. Blacklist access restrictions and sbl-rbl remain in effect, along with basic SMTP well-formedness checking. But all pattern-matching on message headers and bodies is suspended, as part of the experiment.
If greylisting is as effective as many folks claim for it, I’ll make that a permanent change. Time will tell!
Posted on September 2, 2008, in email, spam, webthing. Bookmark the permalink. 6 Comments.
niq's soapbox 
I’ve been using the simple greylisting facility offered by my ISP (gradwell.com) for some time and I’ve found it to be very effective. I’m down from circa 30 – 40 spam messages per day to one or two per month on average. The downside is that the process delays incoming email, sometimes by several hours. That’s no great hardship as I tend to work on my small client base in the evenings (I’m out during the day at my “other” job) but it would be more inconvenient if I was homeworking full time and needed to turn mail around rapidly. I’m sure there are ways to overcome this disadvantage for those more technically savvy than me! I’d be interested to learn how you get on with postgrey.
I’ve been using Greylisting (with Postgrey) for what seems like eternity (over three years). Originally I was seeing a 97% hit rate, in email addresses that receive only spam I was recording greylisting stopping 97% of incoming spam. Late comers will find the current hit rate is substantially lower (under 90% for me), although it still exceeds the effectiveness of Spamhaus ZEN list, which comes in a respectable (and improving!) second in terms of single checks on spam.
Annoyingly (and perhaps surprisingly given the methods) Spamhaus ZEN has a lower false positive rate than Postgrey. Although if one gets routine updates to the whitelists for Postgrey one can minimize the false positives.
For my own use, delays from Postgrey are largely irrelevant, the only delay that I notice routinely is email from signing up to websites. I probably ought to invent an extension to my email address that bypasses greylisting for a day or some such. As other correspondence are largely already learnt and stored in the database.
I fear the killer for greylisting is that the spambots are taking it seriously, and so greylisting ends up more as a delaying tactic to give the spambots time to get added to a blacklist. On the upside I regularly see this at work, where we defer a connection, and by the time it retries it is already blacklisted.
I expect Zen spamhaus to surpass greylisting as the most effective single antispam check known to me soon, probably within a matter of months.
Current score: 20 spam in 9 hours got through greylist+spamhaus. I’m afraid that’s significantly worse than I had before. By my reckoning, header_checks would’ve caught 18 of those 20 (they follow patterns). Looks like I may have to restore the header_checks and body_checks.
I’m currently using spamhaus sbl-xbl. Guess I should take a look at Zen.
+ another two while I wrote that (including time to make that estimate of 18). This is getting ridiculous.
I view greylisting as a way to force spammers to invest in a mail queue[*], and as a way to reduce the spamassassin load. I wouldn’t use it as the only spam defense mechanism.
[*] Of course, there is a way for spammers to pass greylisting without a proper mail queue, but all the ways I am aware of still do create costs in other ways to spammers, so it’s still worth the while.
Bah. About 60 spam now, of which I’d guess at least 50 would’ve been caught by the old filters.
Reinstating header_checks, but leaving body_checks for the time being.