relays.ordb.org returning positive for everything?

[Aaron Wolfe]

It seems like relays.ordb.org (long dead) has started returning
positive answers for *all* IPs.
Today I've had several clients with old configs which still had this
RBL in them suddenly start blocking everything.
Is this a new thing?  Maybe the maintainers were tired of all the queries.

[Per Jessen]

Aaron Wolfe wrote:

> It seems like relays.ordb.org (long dead) has started returning
> positive answers for *all* IPs.
> Today I've had several clients with old configs which still had this
> RBL in them suddenly start blocking everything.
> Is this a new thing?  Maybe the maintainers were tired of all the
> queries.

ordb has been off-line for quite some time:

http://it.slashdot.org/article.pl?sid=06/12/18/154259&from=rss


/Per Jessen, Zürich

[mouss-2]

Aaron Wolfe wrote:
> It seems like relays.ordb.org (long dead) has started returning
> positive answers for *all* IPs.
> Today I've had several clients with old configs which still had this
> RBL in them suddenly start blocking everything.
> Is this a new thing?  Maybe the maintainers were tired of all the queries.
>  

It seems this is the only way. lists keep getting queries years after
they are discontinued. returning positive results gives a chances to
wake up the sleeping beauty...

[Aaron Wolfe]

On Tue, Mar 25, 2008 at 3:23 PM, Per Jessen <per@...> wrote:

>
> Aaron Wolfe wrote:
>
>  > It seems like relays.ordb.org (long dead) has started returning
>  > positive answers for *all* IPs.
>  > Today I've had several clients with old configs which still had this
>  > RBL in them suddenly start blocking everything.
>  > Is this a new thing?  Maybe the maintainers were tired of all the
>  > queries.
>
>  ordb has been off-line for quite some time:
>
>  http://it.slashdot.org/article.pl?sid=06/12/18/154259&from=rss
>
>
>  /Per Jessen, Zürich
>

I'm aware of that, but I don't think the servers were giving positive
responses to all queries until recently.

[Per Jessen]

Aaron Wolfe wrote:

> On Tue, Mar 25, 2008 at 3:23 PM, Per Jessen <per@...> wrote:
>>
>> Aaron Wolfe wrote:
>>
>>  > It seems like relays.ordb.org (long dead) has started returning
>>  > positive answers for *all* IPs.
>>  > Today I've had several clients with old configs which still had
>>  > this RBL in them suddenly start blocking everything.
>>  > Is this a new thing?  Maybe the maintainers were tired of all the
>>  > queries.
>>
>>  ordb has been off-line for quite some time:
>>
>>  http://it.slashdot.org/article.pl?sid=06/12/18/154259&from=rss
>>
>>
>>  /Per Jessen, Zürich
>>
>
> I'm aware of that, but I don't think the servers were giving positive
> responses to all queries until recently.

Sorry, I misread your question a little.  'mouss's previous answer is
probably spot on.


/Per Jessen, Zürich

[ajx]

It seems your logic is fundamentally flawed for several reasons.  By returning false positives, you're breaking mail gateways that use this once useful service.  On the contrary, the best way would be to simply return a DNS host not found error or a connection refused message when a client tries to make contact to the service... This would reduce your bandwidth and not confuse and frustrate any users...

mouss-2 wrote:

Aaron Wolfe wrote:
> It seems like relays.ordb.org (long dead) has started returning
> positive answers for *all* IPs.
> Today I've had several clients with old configs which still had this
> RBL in them suddenly start blocking everything.
> Is this a new thing?  Maybe the maintainers were tired of all the queries.
>  

It seems this is the only way. lists keep getting queries years after
they are discontinued. returning positive results gives a chances to
wake up the sleeping beauty...

[mouss-2]

ajx wrote:
> It seems your logic is fundamentally flawed for several reasons.  By
> returning false positives, you're breaking mail gateways that use this once
> useful service. On the contrary, the best way would be to simply return a
> DNS host not found error or a connection refused message when a client tries
> to make contact to the service... This would reduce your bandwidth and not
> confuse and frustrate any users...
>
>  


It is your logic that is flawed. Returing an error brings nothing at
all. the error is ignored since it has no practical consequence (except
maybe in some unread log file) and queries continue. when all or a lot
of mail is blocked, someone will hit some head and the problem will
probably be fixed.

Note that we are talking about a list that was discontinued for a long
time, so a "grace period" was generously provided. but at some time, I
understand that people who kindly and generously offered a free service
would like to get some rest.

Anyway, I am not related to ordb in any way, and I am not defending this
practice nor do I condemn it. I am merely explaining why things are the
way they are.

[Benny Pedersen]

On Tue, March 25, 2008 20:01, Aaron Wolfe wrote:
> It seems like relays.ordb.org (long dead) has started returning
> positive answers for *all* IPs.
> Today I've had several clients with old configs which still had this
> RBL in them suddenly start blocking everything.
> Is this a new thing?  Maybe the maintainers were tired of all the queries.

05/01/07: ORDB is gone - Remove from your mailserver!

maybe spammers want to take over that domain, lol :)

Benny Pedersen
Need more webspace ? http://www.servage.net/?coupon=cust37098

[John Rudd]

mouss wrote:

> ajx wrote:
>> It seems your logic is fundamentally flawed for several reasons.  By
>> returning false positives, you're breaking mail gateways that use this
>> once
>> useful service. On the contrary, the best way would be to simply return a
>> DNS host not found error or a connection refused message when a client
>> tries
>> to make contact to the service... This would reduce your bandwidth and
>> not
>> confuse and frustrate any users...
>>
>>  
>
>
> It is your logic that is flawed.

> Returing an error brings nothing at
> all.

Which is exactly why it is better.  It brings no false positives.
That's infinitely better than returning all false positives.


> the error is ignored since it has no practical consequence (except
> maybe in some unread log file)

Unread/unchecked only by half-assed postmasters who aren't worth their
salt, and should thus be fired.


A decent postmaster at least generates summaries of traffic (perhaps via
cron), and will note that one of their DNSBLs dropped from "lots of hits
per day" to "no hits per day", wonders why, and looks into the problem.
  These responsible postmasters (who may have missed any notification of
the impending death of the DNSBL they use) do not deserve to have the
headaches caused by generating "all false positives".  They will get
angry calls from users whose mail was returned to the senders (many of
whom will not resend, some of whom are even so lazy as to not even read
bounce reports).  In short, returning an always block result from a
deprecated DNSBL effectively, and inappropriately, penalizes the
responsible postmasters who do in fact check the results, and
investigate why things changed.


A postmaster who doesn't check their logs in any fashion deserves
whatever they get.  Including having all of the spam sail through
unchecked.  Or having their domain actually RBL'ed (ie. routed to null)
because they've continued to do queries well past any reasonable
expiration period.


Generate all misses:  doesn't penalize the good postmasters, don't care
about the effect on the bad postmasters.

Generate all hits: penalizes the good postmasters, don't care about the
effect on the bad postmasters.


Clearly, only half-baked providers do the latter.

[Aaron Wolfe]

On Tue, Mar 25, 2008 at 11:50 PM, John Rudd <jrudd@...> wrote:

> mouss wrote:
>  > ajx wrote:
>  >> It seems your logic is fundamentally flawed for several reasons.  By
>  >> returning false positives, you're breaking mail gateways that use this
>  >> once
>  >> useful service. On the contrary, the best way would be to simply return a
>  >> DNS host not found error or a connection refused message when a client
>  >> tries
>  >> to make contact to the service... This would reduce your bandwidth and
>  >> not
>  >> confuse and frustrate any users...
>  >>
>  >>
>  >
>  >
>  > It is your logic that is flawed.
>
>  > Returing an error brings nothing at
>  > all.
>
>  Which is exactly why it is better.  It brings no false positives.
>  That's infinitely better than returning all false positives.
>
>
>
>  > the error is ignored since it has no practical consequence (except
>  > maybe in some unread log file)
>
>  Unread/unchecked only by half-assed postmasters who aren't worth their
>  salt, and should thus be fired.
>
>
>  A decent postmaster at least generates summaries of traffic (perhaps via
>  cron), and will note that one of their DNSBLs dropped from "lots of hits
>  per day" to "no hits per day", wonders why, and looks into the problem.
>   These responsible postmasters (who may have missed any notification of
>  the impending death of the DNSBL they use) do not deserve to have the
>  headaches caused by generating "all false positives".  They will get
>  angry calls from users whose mail was returned to the senders (many of
>  whom will not resend, some of whom are even so lazy as to not even read
>  bounce reports).  In short, returning an always block result from a
>  deprecated DNSBL effectively, and inappropriately, penalizes the
>  responsible postmasters who do in fact check the results, and
>  investigate why things changed.
>
>
>  A postmaster who doesn't check their logs in any fashion deserves
>  whatever they get.  Including having all of the spam sail through
>  unchecked.  Or having their domain actually RBL'ed (ie. routed to null)
>  because they've continued to do queries well past any reasonable
>  expiration period.
>
>
>  Generate all misses:  doesn't penalize the good postmasters, don't care
>  about the effect on the bad postmasters.
>
>  Generate all hits: penalizes the good postmasters, don't care about the
>  effect on the bad postmasters.

I think you're mistaken.  Generating all hits does not penalize a
"good" postmaster, because no good postmaster will be using an RBL
that's been dead for over a year.   It has no effect on good
postmasters.  Generating all misses penalizes the maintainers who were
nice enough to provide the list while it was active, because bad
postmasters will *never* stop pounding their servers with queries.


>
>
>  Clearly, only half-baked providers do the latter.
>

[John Rudd]

Aaron Wolfe wrote:

> On Tue, Mar 25, 2008 at 11:50 PM, John Rudd <jrudd@...> wrote:
>> mouss wrote:
>>  > ajx wrote:
>>  >> It seems your logic is fundamentally flawed for several reasons.  By
>>  >> returning false positives, you're breaking mail gateways that use this
>>  >> once
>>  >> useful service. On the contrary, the best way would be to simply return a
>>  >> DNS host not found error or a connection refused message when a client
>>  >> tries
>>  >> to make contact to the service... This would reduce your bandwidth and
>>  >> not
>>  >> confuse and frustrate any users...
>>  >>
>>  >>
>>  >
>>  >
>>  > It is your logic that is flawed.
>>
>>  > Returing an error brings nothing at
>>  > all.
>>
>>  Which is exactly why it is better.  It brings no false positives.
>>  That's infinitely better than returning all false positives.
>>
>>
>>
>>  > the error is ignored since it has no practical consequence (except
>>  > maybe in some unread log file)
>>
>>  Unread/unchecked only by half-assed postmasters who aren't worth their
>>  salt, and should thus be fired.
>>
>>
>>  A decent postmaster at least generates summaries of traffic (perhaps via
>>  cron), and will note that one of their DNSBLs dropped from "lots of hits
>>  per day" to "no hits per day", wonders why, and looks into the problem.
>>   These responsible postmasters (who may have missed any notification of
>>  the impending death of the DNSBL they use) do not deserve to have the
>>  headaches caused by generating "all false positives".  They will get
>>  angry calls from users whose mail was returned to the senders (many of
>>  whom will not resend, some of whom are even so lazy as to not even read
>>  bounce reports).  In short, returning an always block result from a
>>  deprecated DNSBL effectively, and inappropriately, penalizes the
>>  responsible postmasters who do in fact check the results, and
>>  investigate why things changed.
>>
>>
>>  A postmaster who doesn't check their logs in any fashion deserves
>>  whatever they get.  Including having all of the spam sail through
>>  unchecked.  Or having their domain actually RBL'ed (ie. routed to null)
>>  because they've continued to do queries well past any reasonable
>>  expiration period.
>>
>>
>>  Generate all misses:  doesn't penalize the good postmasters, don't care
>>  about the effect on the bad postmasters.
>>
>>  Generate all hits: penalizes the good postmasters, don't care about the
>>  effect on the bad postmasters.
>
> I think you're mistaken.  Generating all hits does not penalize a
> "good" postmaster, because no good postmaster will be using an RBL
> that's been dead for over a year.

That's only specific to this case.  I'm talking about from day 1 of the
RBL going dark.

[David B Funk]

On Tue, 25 Mar 2008, John Rudd wrote:

> Aaron Wolfe wrote:
>> On Tue, Mar 25, 2008 at 11:50 PM, John Rudd <jrudd@...> wrote:
>>>  A postmaster who doesn't check their logs in any fashion deserves
>>>  whatever they get.  Including having all of the spam sail through
>>>  unchecked.  Or having their domain actually RBL'ed (ie. routed to null)
>>>  because they've continued to do queries well past any reasonable
>>>  expiration period.
>>>
>>>  Generate all misses:  doesn't penalize the good postmasters, don't care
>>>  about the effect on the bad postmasters.
>>>
>>>  Generate all hits: penalizes the good postmasters, don't care about the
>>>  effect on the bad postmasters.
>>
>> I think you're mistaken.  Generating all hits does not penalize a
>> "good" postmaster, because no good postmaster will be using an RBL
>> that's been dead for over a year.
>
> That's only specific to this case.  I'm talking about from day 1 of the RBL
> going dark.

But that's exactly what this whole thread is about, an RBL that wants to
go dark but is still being hammered upon by unmaintained mail systems.

This thread was started by a mail-admin-wanabe who was asking why his
systems suddenly started rejecting all mail. That PROVES that he was still
using the dead RBL and needed the clue-by-4 along side the head to wake
him up.

This is not the first time an expiring RBL resorted to that technique and
probably will not be the last (sad to say).

--
Dave Funk                                  University of Iowa
<dbfunk (at) engineering.uiowa.edu>        College of Engineering
319/335-5751   FAX: [phone]           1256 Seamans Center
Sys_admin/Postmaster/cell_admin            Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{

[Aaron Wolfe]

On Wed, Mar 26, 2008 at 2:23 AM, Dave Funk <dbfunk@...> wrote:

> On Tue, 25 Mar 2008, John Rudd wrote:
>
> > Aaron Wolfe wrote:
> >> On Tue, Mar 25, 2008 at 11:50 PM, John Rudd <jrudd@...> wrote:
> >>>  A postmaster who doesn't check their logs in any fashion deserves
> >>>  whatever they get.  Including having all of the spam sail through
> >>>  unchecked.  Or having their domain actually RBL'ed (ie. routed to null)
> >>>  because they've continued to do queries well past any reasonable
> >>>  expiration period.
> >>>
> >>>  Generate all misses:  doesn't penalize the good postmasters, don't care
> >>>  about the effect on the bad postmasters.
> >>>
> >>>  Generate all hits: penalizes the good postmasters, don't care about the
> >>>  effect on the bad postmasters.
> >>
> >> I think you're mistaken.  Generating all hits does not penalize a
> >> "good" postmaster, because no good postmaster will be using an RBL
> >> that's been dead for over a year.
> >
> > That's only specific to this case.  I'm talking about from day 1 of the RBL
> > going dark.
>
> But that's exactly what this whole thread is about, an RBL that wants to
> go dark but is still being hammered upon by unmaintained mail systems.
>
> This thread was started by a mail-admin-wanabe who was asking why his
> systems suddenly started rejecting all mail. That PROVES that he was still
> using the dead RBL and needed the clue-by-4 along side the head to wake
> him up.
>

Does anyone actually read the posts they are responding to here, or is
it normal to just assume everyone is an idiot and start typing?

I started this thread.   I was not at all confused about why some of
my clients were having problems (which I had helped them correct
before I posted).   I simply made the observation that the RBL's
behavior seemd to have changed, offered what I knew about it, and
asked if anyone else knew more about the situation.

Maybe my post was unclear?  Two people have written in to inform me
that the RBL is dead.  Strange, since I mentioned that in my post.
Now I am called a "mail admin wannabe" etc?

To put it simply: WTF?

> This is not the first time an expiring RBL resorted to that technique and
> probably will not be the last (sad to say).
>
> --
> Dave Funk                                  University of Iowa
> <dbfunk (at) engineering.uiowa.edu>        College of Engineering
> 319/335-5751   FAX: [phone]           1256 Seamans Center
> Sys_admin/Postmaster/cell_admin            Iowa City, IA 52242-1527
> #include <std_disclaimer.h>
> Better is not better, 'standard' is better. B{
>

[mouss-2]

John Rudd wrote:
> Aaron Wolfe wrote:
>>
>> I think you're mistaken.  Generating all hits does not penalize a
>> "good" postmaster, because no good postmaster will be using an RBL
>> that's been dead for over a year.
>
> That's only specific to this case.  I'm talking about from day 1 of
> the RBL going dark.


doing it at day 1 is certainly wrong, but this is not what we are
talking about here. ordb was discontinued in December 2006.

[nws.charlie]

I guess I'm one of the mail admin wannabe's... not by choice, but by inheritance. It was turned over to me with almost zero training or experience. :(
I found the initial posts clear, and had to wonder at some of the replies myself! Just wanted to say thanks for posting the answer before I posted the question. It shortened my head-bang session.

>Does anyone actually read the posts they are responding to here, or is
>it normal to just assume everyone is an idiot and start typing?

>I started this thread.   I was not at all confused about why some of
>my clients were having problems (which I had helped them correct
>before I posted).   I simply made the observation that the RBL's
>behavior seemd to have changed, offered what I knew about it, and
>asked if anyone else knew more about the situation.

>Maybe my post was unclear?  Two people have written in to inform me
>that the RBL is dead.  Strange, since I mentioned that in my post.
>Now I am called a "mail admin wannabe" etc?

>To put it simply: WTF?

[Jim Flanagan]

Aaron Wolfe wrote:

> On Wed, Mar 26, 2008 at 2:23 AM, Dave Funk <dbfunk@...> wrote:
>  
>> On Tue, 25 Mar 2008, John Rudd wrote:
>>
>>    
>>> Aaron Wolfe wrote:
>>>      
>>>> On Tue, Mar 25, 2008 at 11:50 PM, John Rudd <jrudd@...> wrote:
>>>>        
>>>>>  A postmaster who doesn't check their logs in any fashion deserves
>>>>>  whatever they get.  Including having all of the spam sail through
>>>>>  unchecked.  Or having their domain actually RBL'ed (ie. routed to null)
>>>>>  because they've continued to do queries well past any reasonable
>>>>>  expiration period.
>>>>>
>>>>>  Generate all misses:  doesn't penalize the good postmasters, don't care
>>>>>  about the effect on the bad postmasters.
>>>>>
>>>>>  Generate all hits: penalizes the good postmasters, don't care about the
>>>>>  effect on the bad postmasters.
>>>>>          
>>>> I think you're mistaken.  Generating all hits does not penalize a
>>>> "good" postmaster, because no good postmaster will be using an RBL
>>>> that's been dead for over a year.
>>>>        
>>> That's only specific to this case.  I'm talking about from day 1 of the RBL
>>> going dark.
>>>      
>> But that's exactly what this whole thread is about, an RBL that wants to
>> go dark but is still being hammered upon by unmaintained mail systems.
>>
>> This thread was started by a mail-admin-wanabe who was asking why his
>> systems suddenly started rejecting all mail. That PROVES that he was still
>> using the dead RBL and needed the clue-by-4 along side the head to wake
>> him up.
>>
>>    
>
> Does anyone actually read the posts they are responding to here, or is
> it normal to just assume everyone is an idiot and start typing?
>
> I started this thread.   I was not at all confused about why some of
> my clients were having problems (which I had helped them correct
> before I posted).   I simply made the observation that the RBL's
> behavior seemd to have changed, offered what I knew about it, and
> asked if anyone else knew more about the situation.
>
> Maybe my post was unclear?  Two people have written in to inform me
> that the RBL is dead.  Strange, since I mentioned that in my post.
> Now I am called a "mail admin wannabe" etc?
>
> To put it simply: WTF?
>
>
>  

Try this new article.... http://www.itwire.com/content/view/17322/53/

JF

[mouss-2]

nws.charlie wrote:
> I guess I'm one of the mail admin wannabe's... not by choice, but by
> inheritance. It was turned over to me with almost zero training or
> experience. :(
> I found the initial posts clear, and had to wonder at some of the replies
> myself! Just wanted to say thanks for posting the answer before I posted the
> question. It shortened my head-bang session.
>  

I guess the real problem comes from sites using appliances or commercial
solutions that use DNSBLs without the admins really realizing what this
means (some may even think the DNSBL is managed by the solution vendor).
The lesson for such vendors is that they must use some mechanism to
verify the "integrity" of their solutions (not everybody will update
their solution, so the check must be enabled since day 1). for instance,
a cron would qury the DNSBLs for 127.0.0.1 or the like, and if it is
listed, the DNSBL must be disabled.

This can be done on home grown setups as well.

[Aaron Wolfe]

On Wed, Mar 26, 2008 at 12:10 PM, mouss <mouss@...> wrote:

> nws.charlie wrote:
>  > I guess I'm one of the mail admin wannabe's... not by choice, but by
>  > inheritance. It was turned over to me with almost zero training or
>  > experience. :(
>  > I found the initial posts clear, and had to wonder at some of the replies
>  > myself! Just wanted to say thanks for posting the answer before I posted the
>  > question. It shortened my head-bang session.
>  >
>
>  I guess the real problem comes from sites using appliances or commercial
>  solutions that use DNSBLs without the admins really realizing what this
>  means (some may even think the DNSBL is managed by the solution vendor).
>  The lesson for such vendors is that they must use some mechanism to
>  verify the "integrity" of their solutions (not everybody will update
>  their solution, so the check must be enabled since day 1). for instance,
>  a cron would qury the DNSBLs for 127.0.0.1 or the like, and if it is
>  listed, the DNSBL must be disabled.
>
>  This can be done on home grown setups as well.
>
>
>

I assisted a site today that uses a Symantec antispam product on their
Exchange server.  They were blocking all mail with a very vague error,
"571 message refused" if i recall.

There was a feature called "Block open relays" or similar that made no
mention of using relays.ordb.org.  It just explained what an open
relay was and offered a check box to block them.  There was a separate
section for RBLs in another area of the interface.

Not sure if it's on by default, but if I was an admin using this
product, I'd probably check the box and assume Symantec was providing
the functionality.

It's a pretty safe bet that this feature queries relays.ordb.org,
since it never blocked mail before today and turning it off resolved
the problem.

I think you are right.  Vendors need to take responsibility here.  I
doubt many users of this product have any idea that they are querying
the RBL.

[M. Ehlert]

>  I guess the real problem comes from sites using appliances or commercial
>  solutions that use DNSBLs without the admins really realizing what this
>  means (some may even think the DNSBL is managed by the solution vendor).

We had a this issue using Merak Mail Server for Windows, which has a checkbox
which says:
[x] Use DNSBL (DNS blacklist hole)

There was no mention that Merak used relay.ordb.org anywhere in the configuration.

[Daniel Zaugg]

John Rudd wrote:

> the error is ignored since it has no practical consequence (except
> maybe in some unread log file)

Unread/unchecked only by half-assed postmasters who aren't worth their
salt, and should thus be fired.


A decent postmaster at least generates summaries of traffic ...

A postmaster who doesn't check their logs in any fashion deserves
whatever they get.  

Clearly, only half-baked providers do the latter.

Wow ! Aren't you guys proud to be postmasters !

For me being a postmaster clearly is a chore (one of many) to wich I devote an absolute minimum amount of my precious time.
BTW firing me is not an option since I'm the CEO of my own (small) private owned company :-)

Expecting all postmaster to be highly skilled professionals who have studied all the ins an outs of their system is in my view an unrealistic approach of a world where almost every company has to have an email server.
I gladly accept all the qualifications you made about being "half baked" "not decent" etc..

Is there somewhere a list of all the still working RBL's or an easy way for an unskilled neophyt like me to check if an RBL is still valid?