ASG V7 and use of RBLs (Realtime Blackhole Lists)

ASG V7 uses by default some RBls that are not active anymore or are combinded. Please see my personal investigation,

From the ASG help:
Note – Note that the list of RBLs queried by Astaro Security Gateway is subject to change without notice. Astaro does not warrant for the contents of these databases. 

Databases used by default:
sbl-xbl.spamhaus.org
pbl.spamhaus.org
list.dsbl.org
cbl.abuseat.org

sbl-xbl.spamhaus.org
The Spamhaus Project - ZEN
zen.spamhaus.org ,ZEN is the combination of all Spamhaus DNSBLs into one single powerful and comprehensive blocklist to make querying faster and simpler. It contains the SBL, the XBL and the PBL blocklist.

pbl.spamhaus.org
See above.

list.dsbl.org
http://dsbl.org/
DSBL is GONE and highly unlikely to return. Please remove it from your mail server configuration.

cbl.abuseat.org
The CBL via CBL country 
Blacklists Compared (24 January 2009) Blacklists Compared, 24-Jan-09

This document was last updated by Jeff Makey  on 29 January 2009. 

Blacklists Compared

Conclusions
The results of this survey are not necessarily helpful for choosing a blacklist for the purpose of blocking spam. Such an evaluation would require good data on which of the thousands of e-mail messages handled by SDSC every week are truly spam and which are not, but if it were easy to automatically tell the difference we would just block the spam and not worry about blacklists. Without that data there can be no objective measure of a blacklist's effectiveness for blocking spam.
This survey also does not attempt to measure the quality of blacklists in terms of erroneous listings (false positives) nor in terms of missing entries (false negatives) with respect to each blacklist's policy. To do so would require maintaining my own lists for comparison with the other blacklists, which would take far more effort than I am willing to expend.

That said, it is my subjective opinion that most of the blacklists surveyed here are at least somewhat useful for blocking spam. There is a tendency for those with the highest number of hits to list many places that send substantial quantities of non-spam, and at the other end of the scale some blacklists (such as those listing specific ISPs) are so narrowly focused that they are good for blocking a relatively small fraction of spam with a correspondingly small probability of false positives. To the best of my knowledge all of the blacklist operators make an honest effort to maintain their listings according to their published policies, but the blacklists that cover less than 1% of the survey space seem to be too ineffective to be worthwhile. Your mileage may vary.

For the record, SDSC uses these blacklists:
dsn.rfc-ignorant.org 
zen.spamhaus.org 
dul.dnsbl.sorbs.net 
bl.spamcop.net 

Feel free to comment.

Regards John
  • John, I checked the SMTP Log in the Mail Manager of our Astaro.  sbl-xbl.spamhaus.org and pbl.spamhaus.org are the only ones consulted in the last week.  I found two instances of cbl.abuseat.org back on January 18th.  I suspect that list.dsbl.org was deleted from the Astaro, but that the documentation needs to be brought up to date.

    Cheers - Bob
  • In reply to BAlfson:

    Bob, thanks for the fast reply.

    John
  • In reply to willemsej:

    I turn off the "recommended" blacklist; and leave residential blocking on.
    Then we use these in this priority order.

    zen.spamhaus.org
    cbl.abuseat.org
    b.barracudacentral.org      
  • In reply to ratz:

    I only use and recommend RBL's that have been around for a long time and even better if they are linked to a commercial company, like Spamhaus for example.  There are tons of lists, but many of them are run by hobbyists, which come and go over time.
     
    A little story to illustrate the dangers in this.  One day I get a call from a client that they couldn't receive any emails.  The issue was that they had a "hobbyist" RBL set on their mail server.  Whoever ran this RBL, got bored with running it one day and decided to discontinue the service.  The admin posted a message on the home webpage for the RBL service about this and set a target date 6 months out for complete shutdown.  If you didn't check the home page, you never knew it was going to be shut down.  The target date came and DNS requests to the RBL were bounced.  No problem there.  Now we forward a couple of months later.  The person who ran the former RBL got tired of his servers constantly being pelted by DNS requests, so he fired up his RBL database again with only one address:  0.0.0.0.  This is a catchall, meaning all addresses.  So, any query to his RBL for any address would show as being blacklisted.  When I removed the RBL from use, everything started working again as usual.
     
    The moral here, is to be careful which RBLs you use, don't let a vendor choose the lists for you, and to occasionally check on the status of RBLs you use.  It's better to allow a little bit of spam than face a complete cessation of service.  Smile
  • In reply to Scott_Klassen:

    I remember having a problem under V6 with an RBL that died.  At the time, we had to change that for our clients.  Now, if I understand the situation correctly, any change in the "standard" RBLs is handled by Up2Date.  I can't imagine that adding additional RBLs manually will make any difference in the amount of spam that gets by the Astaro.

    My take on this is similar to my feeling about SPF - the decision to allow the addition of an RBL is political/marketing: if you take it away, users will complain and competitors will niggle.

    Thanks, Scott, for the real-life illustration.  That's a great story, and I'll use it!

    Cheers - Bob
  • In reply to BAlfson:

    FWIW, I find (and my customers find) the default RBLs that Astaro uses do a great job... I haven't really seen a need to add any others yet.
  • In reply to BrucekConvergent:

    FWIW, I've had good experiences with the SpamCop RBLs on my sendmail server... I use both SpamCop and SpamHaus, and here's the results on my sendmail server:

    # grep -i spamhaus maillog|wc -l
    771

    # grep -i spamcop maillog|wc -l
    1757

    (spamcop is catching more mail)

    That's using both bl.spamcop.net and sbl-xbl.spamhaus.org in my sendmail.mc.
    I'm (deliberately) not using the pbl (residential) lists. 

    It's possible this is biased though, as spamcop comes first in the config. I'll switch them around and see if there's any difference. (regardless, spamcop is still a good blacklist.)

    Barry
  • In reply to BAlfson:

      I can't imagine that adding additional RBLs manually will make any difference in the amount of spam that gets by the Astaro.

    My take on this is similar to my feeling about SPF - the decision to allow the addition of an RBL is political/marketing: if you take it away, users will complain and competitors will niggle.



    98% of the time I'd agree that the defaults do a nice job for most of our customers that have astaros.

    But there's always the exception. We've got two situations. (1) a client site that get 1 million SMTP hits a week. On that one 3-5% improvement is huge if we can catch them at the STMP phase.  (2) a client that gets 99.2% of their traffic as spam; as their domain has been around since 1993 from the UUCP unix days. Again 3-5% improvement is huge at the spam/ham ratio.
  • list.dsbl.org has  stopped  DNS. If you have ASG Version 
  • In reply to pebo:

    Our inhouse Astaro is on V7.306. I just checked the DNS logs and you are correct about the problem.  Maybe Astaro will release a 7.307 update...

    Thanks for the heads-up - Bob
    PS But, other than cause an incremental increase in CPU usage and a brief delay in mail delivery, is this a serious problem for anyone?