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!"

Why DNS-RBLs suck

[Anonymous Coward]

Oldie but goldie: http://acme.com/mail_filtering/shame.html#dnsrbls [acme.com]

Re:Whoa! ORDB better have a good disclaimer

[ZenDragon]

They arent being lost, simply being flagged as spam by the database. People will have to go into their respectave administration interface and "release" the mail and/or mark it as safe. Kind of a pain in the ass, but if your depending on a spam database that is over a year old, its not likley doing much for you anyway.

Re:We had one NDR today because of this

[RollingThunder]

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".

Re:No luck

[xiaomai]

How did you post that one logged in, eh ?

Remember: real trolls use their primary account.

I'm pretty sure he was making a joke. He couldn't get the confirmation E-Mail because he hadn't removed the ORDB spam-filter from his mail system.

Re:Why not just close the server?

[travisd]

Because the requests will still come. And even without a response, the request will consume bandwidth that someone is paying for, and consuming an IP address that someone would like to re-use.

Re:Bonehead

[WarJolt]

One connection refused doesn't take up a lot of bandwidth. Thousands of connections refused per day does. Clients often times aren't smart enough to figure out the site is down permanently.

Re:Bonehead

[Joe U]

Are you paying for their bandwidth? How about the servers that are being hammered, are you paying for them?

Short of removing themselves from DNS, this is the most effective way to reduce bandwidth usage in the long term AND teach mail admins on how to properly run their mail servers.

Re:Whoa! ORDB better have a good disclaimer

[interiot]

Why don't they just start reporting all messages as good, or just not give any rating to any message?

That's precisely what they did [readlist.com] for the last 15 months (a pretty reasonable amount of time):

DNS and the mailing lists will vanish today, December 18, 2006.

I don't know... do they still own a machine that responds to DNS requests, and are therefore paying for bandwidth? Probably not.

Do they want to sell the domain to someone, who wouldn't want to get hit with a bandwidth bill as soon as they throw some servers up? More likely.

Re:Why?

[sjames]

Even unanswered DNS queries cost bandwidth. Perhaps they just don't want the traffic anymore.

Re:It's the only way to get them to stop

[brassman]

Mod parent up. I don't have the article in front of me and I have no doubt that 'dickish' won't believe me anyway -- but the last time this happened, someone high up in the .org domain administration reported that the entire .org TLD was at risk of foundering under the load of UNANSWERED queries.

I tell you three times: At the volumes we're talking about, merely turning off the server does not solve the problem caused by people continuing to query it.

Re:Nope.

[Hal_Porter]

http://www.spamyourenemies.com/ [spamyourenemies.com]

Such a succinct website name.

Re:Why DNS-RBLs suck

[Mr. Roadkill]

RBLs are horribly broke & you should never use them as a sole method of determining if an email is spam.

Then, why do I have an extremely low reported false-positive rate from them? Maybe it's got something to do with which ones I choose to use, how I choose to use them, the mix of mail people at my organisation expect to receive, and the mitigating whitelistings I've stuck in place over the years. There is no "zero false-positive anti-spam magic bullet", but for my specific values of "workable" (i.e. my users get a few pieces of spam rather than a deluge, and I don't get many questions about accidentally blocked mail from real people outside the organisation), I've found carefully selected and applied RBLs to be invaluable as a first-line of defence - when you've got between half a million and a million delivery attempts per day, 95% of which you don't end up accepting, you don't want to run that many resource-intensive tests if you don't have to.

Seriously, are you trying to tell me that I should just ignore data in something like the CBL or SpamHaus's PBL? In the case of the former, there's something horribly broke about something using the sending IP - and in the case of the latter, the sending IP is being used in a way the sender's connectivity provider has said it shouldn't be used. I have no problem with either of those, and see no reason to specifically white-list around either of those. Additionally, things like SpamCop can be very useful if properly applied - using any new RBL for scoring-only at first and going over your logfiles with a fine-tooth comb for obvious things you might want to whitelist (like the mail relays of local large ISPs, yes I'm looking at you Bigpond and Optus)can be a good way to ensure there are minimal problems when you do start blocking with them. Plus, a local list of whitelistings can minimise the effort and research required when evaluating and adding other RBLs in future. Granted, mine has been built up over a number of years and I'd hate to have to start from scratch, but it should be possible for any organisation to know what they'll need to whitelist for before they start blocking using RBLs if they use the list for scoring for a while and then go over their logs looking for hits.

Perhaps the biggest problem with RBLs isn't so much the lists themselves (although there are some poor ones out there), but how they're applied and the response of an organisation that uses them when you contact them to report a piece of mail that you think should have got through. Personally, I find them invaluable and I think the last RBL-related "false-postive" that was reported here was a few months back. Give them to a lazy, useless, know-it-all admin who hasn't looked at their potential darker side and isn't willing to do the hard work to make sure they don't cause significant problems, and you've got a recipe for disaster....but the same could be said about a whole lot of SA rules that look like a good idea too that you can't apply too high a score to in practice(No MsgID? Yeah, there are a lot of Domino servers out there in businesses that would affect mail from. Percentage of HTML? Good luck with Chinese webmail.)

Sheesh guys, spam filtering is hard. That's why there are so many commercial products out there, following so many different methodologies, and why so many places seem to have difficulty doing a fair to decent job of it.

Re:Is it really necessary?

[prshaw]

Well, I block about 50% of the connections to my email server based on RBLs.

So it could cost me almost double in bandwidth, processing, and storage if I let all of the email through. And then I would assume the users would end up deleting the emails anyway, causing them to do additional thinking/clicking.

Everyone's numbers are going to be a little different depending on how much they block on the RBLs. I use pretty non-agressive RBLs since I don't want to block any legit email.

Some RBLs are best used for scoring emails, some are good for blocking. You have to use them in the way that makes the most sense for what you are trying to accomplish.

Re:Why not just close the server?

[adolf]

No, they won't -- at least not much, if they were using a subdomain for their RBL (as is the only sane method of doing so).

They could abandon this subdomain (which would be silly), or just set up its SOA to have a huge TTL, and have an NS line in the right spot pointing to localhost.

Requests from end-user mail servers would still happen, perhaps thousands of them per minute, but they'll only be met with references to a nameserver known as 127.0.0.1. The DNS hierarchy will then cache this bogus nameserver for TTL seconds.

They'd still see some traffic, particularly from poorly-behaved DNS servers which don't honor TTL, but it ought to be pretty easy to limit their traffic to no more than one request, per server, no more frequently than every few days (at least on average).

Which, I'd think, would be good enough. But even if it's not: It's nowhere near as bad as you seem to make it appear.

Re:Is it really necessary?

[arkhan_jg]

I meant reliable as in identifying porn spam as spam. I run the email system for a school from reception to 18. Porn spam, of which we receive a VAST amount, simply cannot be allowed through the spam filters. Bayes filters do not catch all of it, even with RBL weighting as they struggle with all image mails. The bayes filters also flag legitimate email as spam, which then gets dumped in a spam box and never read. It's better to generate a clear non-receipt message to the sender, so they know it's not been delivered than have legitimate mail high-spam flagged and dumped in a box with a hundred others never to be read. Virtually all our legit email comes from parents or suppliers, all of which have our phone number for out of band communication.

So far, in the 2.5 years we've had RBL's running, we've had one reported false positive from a parent on a pink-ticket spam ISP in korea. They were whitelisted, and problem solved.
On the other hand, I've had hundreds of complaints from staff and pupils via staff about obscene spam that made it through the bayes filters. Reliability of detection IS an issue for us.

You also ask about expense. CPU horsepower is not cheap, nor is secure disk space for email storage. Our mail server is limited on both, and we don't have the budget this year to upgrade the mail server again. Being in a rural area, bandwidth to handle the torrent of image spam isn't cheap either. Must be nice to live in a world where you can just throw money at containing the problem.

The manual white and blacklists are first. The RBLs are a front line defence, which generate a clear fault message to the sender. The greylist catches some more, but is less and less effective these days since the spammers keep resending every few seconds until it gets through. They bayes filters are the last line and the least effective filters, both for false positives and negatives, which then flag the mail. Stuff which scores obscenely high (25+) gets redflagged and blocked from final delivery.

If I turned off everything but the bayes filters, the filter server would simply not clear the incoming email fast enough. The users would overnight get up to 10 times the spam, much of it very unsuitable for pre-teens, thus overloading the imap server. Flagging it and moving on may work for you and your mail server, but flagging the (checks) 524, no 528 spam the headmaster would have received in the last 24 hours and dumping them in his inbox instead of blocking them would very quickly put me out of work.

Re:Whoa! ORDB better have a good disclaimer

[monsted]

Nope, if they just let the domain expire, it would have caused the .org authoritative servers to die. It's been done already, shortly after they first shut down the service, causing them to open it a again, responding that everything is ham.

If the ordb.org zone goes away, every halfwit mail admin who uses ordb.org will be hammering the .org servers instead. This is why it was first reenabled and now shut down the way it is.

Re:Whoa! ORDB better have a good disclaimer

[harrumph]

It's one thing for a spam filter to make a mistake or even be careless and put a message into the spam folder, but quite another for a filter to intentionally cause known good messages to be absent from a user[']s inbox.

This is a misunderstanding of blacklists. Blacklists are not filters; some filtering methods use blacklists, and ORDB was (is) a blacklist. The operators of blacklists, by definition, cannot cause anything to happen with anyone's e-mail. Every blacklist has a criterion or criteria for listing, and any user of that list can check to find if a given IP address or domain name is listed. Listing criteria could be "domain recently bounced e-mail to postmaster@", "IP address was reported as sending junk mail by fifty different users", or "IP address is on Bob's personal shit-list". Users of blacklists can do whatever they like with the data. When ORDB was active, mail servers for domains I controlled checked all incoming connections against ORDB and simply refused to converse any further with listed systems. ORDB didn't make the mail bounce. I did. By my choice, just like the choices of everyone else who has ever used ORDB or any other blacklist, I specifically configured my systems to refuse messages from systems (or domains) listed. I decided that the listing of an IP address by ORDB was reason enough to refuse connections from it.

Why don't they just start reporting all messages as good, or just not give any rating to any message?

That is exactly what they've been doing for over fifteen months. They stopped listing anything. In fact, they stopped responding at all. Almost every system that was left configured to use ORDB after it was shut down in December 2006 has logged an error message every time it tried to check an incoming connection or message against ORDB, because ORDB didn't respond. Some systems with particularly out-of-touch administration have persisted in trying to query ORDB--or, according to this story, so many that it's been an annoyance to the admins of the systems receiving the queries. If this goes on for months and months and months, I think it's quite reasonable for the blacklist admins, who stopped their service fifteen months ago, to start a new list with a single new criterion: Everything is listed. Call it a test list. It's their list, and they can do whatever they want with it. The only systems that are affected are those that are specifically configured to use this list.

So, if you, the administrator, specifically tell your mail system to refuse to accept mail sent from a system listed in ORDB (which ceased to exist long ago), your system will now bounce everything until you stop telling it to do that. According to the story, this is what's happening, but only in the systems configured to do exactly that.