Long-Dead ORDB Begins Returning False Positives

Chapter80 writes "At noon today (Eastern Standard Time), the long dead ORDB spam identification system began returning false positives as a way to get sleeping users to remove the ORDB query from their spam filters. The net effect: all mail is blocked on servers still configured to use the ORDB service, which was taken out of commission in December of 2006. So if you're not getting any mail, check your spam filter configuration!"

Re:Whoa! ORDB better have a good disclaimer

[arkhan_jg]

ORDB was a realtime blacklist. I.E. it identified the IP addresses of open relays. Most people use RBL's like zen and njabl to block connections from 'bad' SMTP servers at HELO, they're much more effective at that stage than later as part of bayesian spam filters - context filtering is expensive and unrelaible with the volume of spam these days. Blocking open relays and dynamic ranges* at HELO is often the only practical way to get a handle on 99% spam loads.

Configured that way, there's no email to release, as the server was not allowed to connect in the fiirst place - in effect, ORDB would have caused an admin unaware that they had shut down to have his server block all inbound email at the connection level. Given the amount of sample configs about that still include them, that's not impossible to imagine.

Effective way of getting people to stop querying their servers, but kinda dickish.

*Yes, I know dynamic ranges sometimes host legit personal mail servers. Unfortunately, for every legit user there are hundreds of spam zombies on those dynamic IPs, often dumping dozens of spam at a time, often hitting over and over again until they get past the greylist timeout. I'm watching my log now, and I just blocked 50 odd connection attempts from one 1 pretending to be 50 different email domains. In the time it's taken me to write this footnote, the dynamic range IPs blacklists have blocked a few hundred emails.

Re:Whoa! ORDB better have a good disclaimer

[Naurgrim]

Concur, wholeheartedly.

I put a good deal of effort into getting spamassassin configured to classify spam into imap folders for my users, and giving them tools for whitelisting, etc. on an individual basis. One man's spam is another man's ham, after all.

I could not in good faith arbitrarily delete mail based on automatic filtering. I would rather run completely unfiltered than make that decision for somebody, and for a long time I resisted the idea of filtering server-side. Bottom line was that my customers demanded it, so I had to come up with a system that met their requirements and mine.

Alternative to DNS-RBLs

[gringer]

Er, he mentioned in his other discussions on mail filtering better ways to do it (i.e. those not on the "shame" list):

http://acme.com/mail_filtering/background_frameset.html [acme.com]

Make your own blacklist

[tepples]

You're right, the 90% of inbound mail that gets dropped at the pure IP level before it even hits my more CPU intensive filters is "worthless".

The trick is to make your server use CPU-intensive filters to construct its own IP address blacklist. These pages explain how one admin did it [acme.com].