Long-Dead ORDB Begins Returning False Positives 265
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!"
Whoa! ORDB better have a good disclaimer (Score:3, Insightful)
Nice (Score:4, Insightful)
Dealing with Email and Spam issues can be enough of a pain in the ass without the added hassle of this shit.
It isn't that the recipient complains they aren't getting email, it's when the sender (my customer) complains to me that their mail isn't making it to the recipient and blames me when it's the spam filters at the other end causing the problem. And now this?
Nice.
Why not just close the server? (Score:5, Insightful)
Re:Whoa! ORDB better have a good disclaimer (Score:3, Insightful)
That said, if you're that crappy of a sysadmin, you deserve a wake-up call. It's just too bad that other people have to suffer for you to learn to do your job properly.
Re:Whoa! ORDB better have a good disclaimer (Score:5, Insightful)
Re:Nice (Score:5, Insightful)
This will cause some confusion at first, but if it hit
I just hope no one's spam filter defaults to automatic-deletion.
Re:Whoa! ORDB better have a good disclaimer (Score:5, Insightful)
That said, the approach of ORDB does seem to be the right way to stop administrators from using it. If you don't force the issue by stopping all mail, then random non-spam emails will continue to be blocked indefinitely. Short-term pain for long-term gain...
Bonehead (Score:3, Insightful)
Re:We had one NDR today because of this (Score:3, Insightful)
However, such a filter wouldn't score good if it were judged on the really important metrics like number of false positives.
Re:Why DNS-RBLs suck (Score:4, Insightful)
Re:Whoa! ORDB better have a good disclaimer (Score:5, Insightful)
Re:Wow, they've got that ass-backwards. (Score:2, Insightful)
What really gets me about this case is that this is at least the third time a defunct BL has done this (Osirusoft and monkeys.com being the other two examples I know of), and in this case, returning false positives was particularly unnecessary. Since ORDB is defunct, the domain could have been just allowed to expire. Or, make sure that no IP space is associated with the domain at all. For the upstream ISP(s) who owned the IPs formerly used by ORDB, they might have to let them lie fallow forever, though, since queries would never stop in the absence of this sort of event.
OTOH, I have to assign more than the usual amount of blame to those who kept using ORDB so long after it went defunct, just because it is at least the third time this has happened. Anyone responsible for a mail server should stop to think that "Gee, continuing to query a defunct BL service over a year after it was shut down could someday be hazardous to my mail stream. I'd better update my config." I'm not absolving anyone from ORDB for not just getting rid of all ORDB IPs and having no routes to any of the ones they used to use, but willfully ignorant admins are also played a starring role in this tragedy. Or comedy of errors, depending on your point of view.
Re:Why not just close the server? (Score:5, Insightful)
My bet is this is going to really REALLY negatively affect all of those mailservers that have been setup, for which there is *no* administrator. You know. the ones setup for smaller companies who have no inhouse admin, who hired a consultant, but wouldn't pay for ongoing maintenance (either due to tightness or actual lack of funds, etc). The response time here, and time to resolution is likely to be high to non-existent.
All in all, this is a pathetic (understandable, mind you) move, and reeks of inconsideration.
Re:Wow, they've got that ass-backwards. (Score:3, Insightful)
rblcheck.pl and other embedded rbl lists (Score:3, Insightful)
Somewhat recently, I started using a perl version of rblcheck in some of my procmail recipes. A lengthy list of rbl's is embedded in the source code. I removed some obvious losers but was unaware until reading this article that ordb was a problem. How many people out there are using this script and are unaware that a bomb like this is lurking in the code? How many are using it and don't even remember that they even use this script?
Re:Whoa! ORDB better have a good disclaimer (Score:1, Insightful)
Serves 'em right! Like anyone but the most brain dead administrator on EARTH is going to expect an anti-spam product to continue working a year or more after they've purchased it. I mean the whole reason they ORDB went out of business is because these asshats were expecting something for nothing. So if they loose a little important email, then that's just tough love isn't it? They should have been keeping ORDB management in Porches and million dollar homes at the least. Hell, they could make more than that being spammers themselves, so the cheap bastards better pay up.
Re:Whoa! ORDB better have a good disclaimer (Score:5, Insightful)
On a side note, given that this move by ORDB specifically targets people other than those who they want to change the behaviour of in an attempt to get those innocent bystanders to affect change upon the real people they want to affect, this actually meets the FBI's definition of terrorism.
Comment removed (Score:4, Insightful)
It's the only way to get them to stop (Score:5, Insightful)
It was the only way to get them to stop and if I check my server today, I will likely find I am still getting some requests on them. So it's not dickish at all as another commentator claimed.
Re:Whoa! ORDB better have a good disclaimer (Score:5, Insightful)
When someone just plain will not check back to see if your free service is still working (and free), how else do you get their attention?
Re:Whoa! ORDB better have a good disclaimer (Score:4, Insightful)
Mmmm, stereotypes (Score:5, Insightful)
Jocks are idiots.
Linux users have tiny penises.
Windows users are point-and-drool morons.
Mac users are artistic and gay and think overpriced computers are status symbols.
Business execs and politicians don't know fuck-all about computing or networking, but insist on controlling them anyway.
Women are shitty drivers (they themselves have fewer accidents, hence they receive a better insurance rate; they're shitty drivers because they do annoying shit that creates obstacles for others, like not knowing what the fuck the passing lane is for).
Black people are either from the ghetto, or act like they wish they were.
White people have zero sense of rhythm, can't dance, and can't jump.
Now where's my +5 Insightful?
Re:Is it really necessary? (Score:5, Insightful)
Blocking with an error code is the Right Way. That way the sending mail server generates a bounce message and the sender knows that the message didn't get through. The idea of accepting every message so the user can have 50,000 messages in his spambox that will never get looked at for every real message is absurd.
Re:Whoa! ORDB better have a good disclaimer (Score:2, Insightful)
if you wanted to be more accurate, it's more like you've been using your neighbours power for free and they have cut you off in order to make you get your own connection with the power company.
Re:Whoa! ORDB better have a good disclaimer (Score:2, Insightful)
the complete opposite of what i said would be if they had no right to take it down. comprehension eludes you doesn't it?
Re:Why not just close the server? (Score:3, Insightful)
An awful lot of mail systems have been set up as set-and-forget by work-for-hire conslutants, who never end up touching them again. The only way to get those kind of systems re-configured is for the organisations that use them to suffer some pain. It's arguable that that pain is deserved, since they're obviously not running their mail systems responsibly. Anyone who used ORDB and responsibly managed their mail system knew long ago that ORDB was going to do this and stopped using it ages ago. Besides, there may well come a day on which that domain lapses and falls prey to squatters - or worse. Don't you think that J. Random-Hacker would love to get information on poorly-configured or poorly-maintained systems? ORDB have to stop people querying them before they can even think about relinquishing the domain, if only to protect the ignorant from themselves. In the case of ORDB, it's probably not much of an issue - but imagine what would happen if Ironport decided to pull the plug on Spamcop and then forgot to renew the domain before January 30 next year and there were still a few thousand ill-informed people generating queries against the SpamCop RBL. Not pretty...
Block lists (Score:4, Insightful)
Re:Whoa! ORDB better have a good disclaimer (Score:2, Insightful)
First, I'm not aware of any publicly owned spam registrars. Care to enlighten me?
Second, how is a publicly owned (e.g. stock exchange, or do you mean run by the government of a country chosen at random (or heaven forefend the UN)) service less likely to go belly up? There have been any number of companies delisted from the stock exchange... As far as government services, that's a little touchy, at least in the good old U.S. of A. Kind of a 1st amendment issue.
Third, how do you suggest a company providing a service like this behave as it is going out of business? Keep in mind that a four letter domain name is quite valuable. Would you expect the original company to continue to forever pay the extra bandwidth costs due to 'dumb mail admins' for a DNS service that they don't use, or use for another purpose? How about the purchaser of the domain if/when it sold? Do they have a responsibility to continue to provide the false negatives? Why?
Fourth, arguably false negatives are as bad as false positives. If a mail admin has layered another spam detection method on top of ORDB because ORDB wasn't working well enough (because it was off) and ignored the malfunctioning service, are they still not irresponsible? If they didn't, and their customers were being bombarded by spam for over a year, are they still responsible administrators, with users who are being terribly hurt?
Fifth, terrorism? Really? Who is being frightened? Who is being terrorized? This word is horrifyingly overused, and I do not think it means what you clearly think it means. If I purchase the land on either side of your house, and set up a circus on one side, and a parking lot on the other side, is it terrorism if you put up a fence to keep my customers from strolling through your yard? Really?
Re:No it is not ... (Score:3, Insightful)
I know I would rather be notified of a rejection than have an email go to a spam box.
Re:Whoa! ORDB better have a good disclaimer (Score:3, Insightful)
Comment removed (Score:4, Insightful)
Re:Whoa! ORDB better have a good disclaimer (Score:4, Insightful)
You cannot say that people were NOT warned. Lazy mail admins, who couldn't be bothered changing their boxes are the problem here. Looks like they got burned due to their laziness and lack of proactiveness. They weren't good mail admins in the first place, if they got this wrong, what else are they doing wrong? At the end of the day, they deserve everything they get.
Re:Why not just close the server? (Score:1, Insightful)
> (deleting a DNS record,
If they delete the DNS record,
> or pointing it to 127.0.0.1 and giving it a TTL of a few decades)
That's more or less what they actually do. Unfortunately, returning 127.x.y.z to
a DNS request ist a DNS-RBL's way of saying "SPAM".
> would do the trick better than BLOCKING EMAIL.
They dont't block emails. They return 127.x.y.z to a DNS query, which
gets interpreted as a "Mail is SPAM", which may lead to blocked mail
(if the mail administrator is lazy or stupid)
Re:Let's be fair to Mac users (Score:3, Insightful)
Re:Why not just close the server? (Score:3, Insightful)
I think what GPP was trying to say is that the only thing necessary is to add relays IN NS localhost to the ordb.org zone file. That means that a recursing resolver (e.g. a caching nameserver) will query one of the root servers and be redirected to the .org nameservers by virtue of the glue records which will be queried and redirected to ordb.org by virtue of those glue records which will then be redirected to localhost by ordb.org by virtue of its "glue" records for relays. Since the recursing nameserver will not be authoritative for the relays.ordb.org zone it will fail to look up anything. Assuming the TTL is set high enough on the relays glue record, the recursing server will cache this for quite some time and thus all further queries to *.relays.ordb.org will immediately fail without banging on the ordb.org nameservers.
This is also quite different from returning IN A 127.0.0.1 to the query of a name. What will happen instead is that the ordb.org nameservers will explicitly disown the relays.ordb.org zone in much the same way that the root nameservers explicitly disown the GTLDs and the GTLDs explicitly disown the domains within them.
Doing it this way, the ordb.org servers will be hit very infrequently. Really only once by any given caching nameserver which upon seeing the relays IN NS record delegating authority to localhost will remember it and stop asking ordb.org for anything in relays.ordb.org. It's a really really simple solution that wouldn't break anything and wouldn't put much if any burden on the ordb.org nameservers. Too bad they didn't think of this before adding *.relays IN A 127.0.0.2 to the ordb.org zone file.