RBL Lists (preference?)
spax
I was wondering what people are using for RBL lists these days. Below are
my lists (in order). I would still like to be able to block more.....
1. dnsbl.ahbl.org
2. blackholes.easynet.nl.
3. relays.ordb.org
4. list.dsbl.org
thanks for your help!
Tim Boyer
Jem Berkes
> Below are my lists (in order). I would still like to be able to block
> more.....
>
> 1. dnsbl.ahbl.org
> 2. blackholes.easynet.nl.
> 3. relays.ordb.org
> 4. list.dsbl.org
Here are the lists I use in order of preference:
sbl.spamhaus.org
blackholes.easynet.nl
list.dsbl.org
relays.ordb.org
--
Jem Berkes
http://www.sysdesign.ca/
Bill Cole
"spax" <her...@n-o-s-p-a-m.ihateblinktags.com> wrote:
cbl.abuseat.org
sbl.spamhaus.org
blackholes.easynet.nl
korea.services.net
opm.blitzed.org
relays.visi.com
verisign.blackholes.us
Plus a rather severe local blacklist that you can see at
http://www.scconsult.com/blacklist.shtml
Note that this is for a tiny domain where the majority of mailboxes are
for mail intended for myself or immediate family. However, I would
consider all of those public lists as reasonable to consider for a
corporate site or for offering to users optionally in an ISP environment
(with the caveat that it has been some years since I've done serious
work with any environment resembling a retail ISP, so my sense of that
environment may be skewed.)
It is my opinion that any mail system not using the CBL as a front line
DNSBL is doomed to work harder than necessary for no good reason. It has
BOTH the lowest false positive rate and the highest catch rate of any
public DNSBL I've ever seen.
--
Clues for the blacklisted: <http://www.scconsult.com/bill/dnsblhelp.html>
Current Peeve: People who try to crack my machines and then have the
chutzpah to complain to me about being shunned
Dolphin
message <bniamh$34c$1...@merki.connect.com.au> reply:
Leaving aside ISP/country-wide DNSBLs, I'm left with these (in order):
sbl.spamhaus.org
relays.ordb.org
proxies.blackholes.wirehub.net*
list.dsbl.org
opm.blitzed.org*
spews (mirrored locally)
* didn't produce hits in this month.
In my opinion, the Spamhaus one is a must to have on every mailserver,
even ones that don't use blocking, afraiding of false positives.
Dolphin.
--
URL: http://www.DolphinWave.org
Mail: on the web page (no spam)
ICQ: 6615461
JerryMouse
mb
... and some you may not have expected or wanted it to catch. That's
not usually a big problem, but I would expect to whitelist some
domains/ip sets that send out alot of email.
Some Bastard
bl.spamcop.net (catches the most spam, but occasionally nails major
mail servers such as redhat's list server, or expedia.com. Overall a
GREAT rbl, but be prepared to do some whitelisting with it)
blackholes.easynet.nl (catches a fair amount of spam, and never
gotten a false positive with it)
dynablock.easynet.nl (kills cable /dsl spam dead)
sbl.spamhaus.org (somewhat too conservative in my opinion, but
you'll never get a false hit with this one)
spews.bl.reynolds.net.au (a spews feed. Once in a blue moon it gets
a false positive, though pretty rare. Blocks the worst spammers)
Jem Berkes
> mail servers such as redhat's list server, or expedia.com. Overall a
> GREAT rbl, but be prepared to do some whitelisting with it)
IMHO this RBL is too risky to use except maybe on your personal site. User
feedback goes into listing IPs, so when a bunch of idiots report a mailing
list they're on the server gets listed.
During my trial periods of RBLs I've done manuals check on every mail
stopped. One of the first RBLs I decided was too risky was spamcop; the
list is too temperamental unlike something that's centrally coordinated
like blackholes.easynet.nl
Some Bastard
you bring up an excellent point, which is why i said you should be
prepared to whitelist. On the flip side, bl.spamcop.net stops new
spam sources cold. I've seen spamcop stop some no name spammer in
Iran or Morocco who started spamming out of a net cafe countless
times.
JerryMouse
>> bl.spamcop.net (catches the most spam, but occasionally nails major
>> mail servers such as redhat's list server, or expedia.com. Overall a
>> GREAT rbl, but be prepared to do some whitelisting with it)
>
> IMHO this RBL is too risky to use except maybe on your personal site.
> User feedback goes into listing IPs, so when a bunch of idiots report
> a mailing list they're on the server gets listed.
Idiots don't last. SpamCop does not accept reports from proven idiots. Abuse
the system, or make ghastly mistakes, and you're history.
On the other hand, if you don't belong to any mailing lists, or belong to
mailing lists you can whitelist, SpamCop is quite effective. SpamCop is
dynamic: some number of complaints in some realitvely small time period
triggers the listing. Often, this technique is sufficient to stop a spam run
before it completes. Certainly its fast enough to catch a spammer before his
stolen credit card gets discovered.
Huey Callison
> Jem Berkes wrote:
> >> bl.spamcop.net (catches the most spam, but occasionally nails major
> >> mail servers such as redhat's list server, or expedia.com. Overall a
> >> GREAT rbl, but be prepared to do some whitelisting with it)
> > IMHO this RBL is too risky to use except maybe on your personal site.
> > User feedback goes into listing IPs, so when a bunch of idiots report
> > a mailing list they're on the server gets listed.
> Idiots don't last. SpamCop does not accept reports from proven
> idiots. Abuse the system, or make ghastly mistakes, and you're
> history.
That's irrelevant to the fact that SpamCop still has a sizeable
false-positive problem. The metrics by which it determines what servers
are sending spam are flawed in that SpamCop occasionally lists servers
that are not sending a significant amount of spam, and in some cases it
lists servers that aren't sending any spam. Whether or not SpamCop
punishes the people who cause those false-positive listings doesn't
matter, because the listings still happen in the first place.
> On the other hand, if you don't belong to any mailing lists, or belong to
> mailing lists you can whitelist, SpamCop is quite effective. SpamCop is
> dynamic: some number of complaints in some realitvely small time period
> triggers the listing. Often, this technique is sufficient to stop a spam run
> before it completes. Certainly its fast enough to catch a spammer before his
> stolen credit card gets discovered.
If those false-positive listings are all legitimate mailing lists that
you're not subscribed to, or have whitelisted, that's fine, but unless
your whitelist includes all of the outbound MXes of everyone you will
ever get legitimate email from, SpamCop will eventually block mail you
want, along with all of the spam that it stops.
--
Huey
axlq in California
Huey Callison <bas-...@grace.speakeasy.net> wrote:
>JerryMouse <nos...@bisusa.com> wrote:
>> Idiots don't last. SpamCop does not accept reports from proven
>> idiots. Abuse the system, or make ghastly mistakes, and you're
>> history.
>
>That's irrelevant to the fact that SpamCop still has a sizeable
>false-positive problem.
Not from my spamcop reports.
>The metrics by which it determines what servers
>are sending spam are flawed in that SpamCop occasionally lists servers
>that are not sending a significant amount of spam, and in some cases it
>lists servers that aren't sending any spam.
That is how it's supposed to work. Not only does Spamcop identify
(correctly, as far as I can tell) the source of spam, but also
identifies the hosts of spamvertized domains of URLs within the body
of the spam. Naturally, many spammer web hosts don't actually send
spam, but they should be, and are, listed anyway. I'll note that
SPEWS apparently has the same point of view.
-A
Huey Callison
> Huey Callison <bas-...@grace.speakeasy.net> wrote:
> > The metrics by which it determines what servers are sending spam
> > are flawed in that SpamCop occasionally lists servers that are not
> > sending a significant amount of spam, and in some cases it lists
> > servers that aren't sending any spam.
> That is how it's supposed to work.
I don't know how it's 'supposed' to work, but I don't think a large
false-positive problem was an intentional design 'feature'.
> Not only does Spamcop identify
> (correctly, as far as I can tell) the source of spam, but also
> identifies the hosts of spamvertized domains of URLs within the body
> of the spam. Naturally, many spammer web hosts don't actually send
> spam, but they should be, and are, listed anyway. I'll note that
> SPEWS apparently has the same point of view.
Perhaps I wasn't specific enough. SpamCop's DNSBL has listed, currently
lists, and is likely to continue listing the more than occasional site
that 1) does not send any spam, 2) is not mentioned in any spam, 3) does
not host websites advertised in spam, 4) does not host dropboxes
advertised in spam, 4) does not serve DNS or act as a domain registrar
or serve bandwidth or electricity or cheese sandwiches to anyone who
sends spam, and 5) does not share an upstream provider with other sites
targeted by Spamcop's netblock escalations for sending spam. Most
recently, SpamCop's DNSBL has been documented to list IP addresses
forged into completely bogus received-lines. These IP addresses that
have nothing to do with the spam in question beyond a presence in a
forged header, and yet some of them belong to people who fit items 1-5
listed above. Some of those have mailservers at them that will attempt
to send legitimate mail, and some of that legitimate mail will be
blocked by SpamCop's DNSBL.
Sites that fall into this class are known as 'false positives'.
SpamCop's DNSBL has a disproportionately larger percentage of these
false positives compared to most other blocklists.
If you don't mind losing wanted mail, the SpamCop DNSBL blocks a lot
of spam. It also blocks some wanted mail.
--
Huey
JerryMouse
>
> That's irrelevant to the fact that SpamCop still has a sizeable
> false-positive problem. The metrics by which it determines what
> servers
> are sending spam are flawed in that SpamCop occasionally lists servers
> that are not sending a significant amount of spam, and in some cases
> it
> lists servers that aren't sending any spam. Whether or not SpamCop
> punishes the people who cause those false-positive listings doesn't
> matter, because the listings still happen in the first place.
You are absolutely, totally, and mysteriously wrong. I've gone back and
looked it up. So far this year, SpamCop has caught a little over 32,000
(32,045) spams on my machine (SpamEater keeps count). Not one has been a
false positive. Not ONE.
>
>> On the other hand, if you don't belong to any mailing lists, or
>> belong to mailing lists you can whitelist, SpamCop is quite
>> effective. SpamCop is dynamic: some number of complaints in some
>> realitvely small time period triggers the listing. Often, this
>> technique is sufficient to stop a spam run before it completes.
>> Certainly its fast enough to catch a spammer before his stolen
>> credit card gets discovered.
>
> If those false-positive listings are all legitimate mailing lists that
> you're not subscribed to, or have whitelisted, that's fine, but unless
> your whitelist includes all of the outbound MXes of everyone you will
> ever get legitimate email from, SpamCop will eventually block mail you
> want, along with all of the spam that it stops.
And eventually the sun will expire. I've been using SpamCop a little over
four YEARS and can't remember an unfounded block (and I do check this
stuff).
Your arguments are simply not supported by my experience. Maybe I'm just
lucky. Maybe you're just jinxed.
Huey Callison
> Huey Callison wrote:
> > That's irrelevant to the fact that SpamCop still has a sizeable
> > false-positive problem. The metrics by which it determines what
> > servers are sending spam are flawed in that SpamCop occasionally
> > lists servers that are not sending a significant amount of spam,
> > and in some cases it lists servers that aren't sending any spam.
> > Whether or not SpamCop punishes the people who cause those
> > false-positive listings doesn't matter, because the listings still
> > happen in the first place.
> You are absolutely, totally, and mysteriously wrong.
I don't think so.
A friend of mine has an AOL account. Checking my logs, I note that one
of AOL's out-MXes that I've gotten mail from him through is
152.163.225.101. Spamcop is having a little bit of trouble right now,
but it looks to me like that IP has been listed and delisted four times
in the last month.
> I've gone back and looked it up. So far this year, SpamCop has
> caught a little over 32,000 (32,045) spams on my machine (SpamEater
> keeps count). Not one has been a false positive. Not ONE.
Bully for you. Spamcop is clearly a good solution for you.
Unfortunately, it isn't a good solution for anyone who expects to get
mail from AOL, so unless you're willing to eliminate 35 million people
from the set of folks who are allowed to email you, it might NOT be.
> > If those false-positive listings are all legitimate mailing lists that
> > you're not subscribed to, or have whitelisted, that's fine, but unless
> > your whitelist includes all of the outbound MXes of everyone you will
> > ever get legitimate email from, SpamCop will eventually block mail you
> > want, along with all of the spam that it stops.
> And eventually the sun will expire. I've been using SpamCop a little over
> four YEARS and can't remember an unfounded block (and I do check this
> stuff).
Spamcop has listed servers that have never sent spam, but do send
legitimate mail. If this is not borne out by your personal statistics,
more power to you. The statistics I am familiar with are on a mailserver
cluster that receives in ten minutes what your system receives in a
year, delivering mail to a quarter million mailboxes. And my experience
as well as my personal preference tells me that when paying customers
can't get email from their buddy Scott who has an account with AOL,
they will complain.
> Your arguments are simply not supported by my experience. Maybe I'm just
> lucky. Maybe you're just jinxed.
Or maybe your experience is different from mine.
--
Huey
Administrator
usenet-O...@2003.dolphinwave.org says...
> #begin her...@n-o-s-p-a-m.ihateblinktags.com.exe (or was it spax.com)
> message <bniamh$34c$1...@merki.connect.com.au> reply:
> > Hi,
> >
> > I was wondering what people are using for RBL lists these days. Below are
> > my lists (in order). I would still like to be able to block more.....
> >
> > 1. dnsbl.ahbl.org
> > 2. blackholes.easynet.nl.
> > 3. relays.ordb.org
> > 4. list.dsbl.org
> >
> > thanks for your help!
>
> Leaving aside ISP/country-wide DNSBLs, I'm left with these (in order):
>
> sbl.spamhaus.org
> relays.ordb.org
> proxies.blackholes.wirehub.net*
zone has been moved to proxies.blackholes.easynet.nl
Jim Seymour
"spax" <her...@n-o-s-p-a-m.ihateblinktags.com> writes:
> Hi,
>
> I was wondering what people are using for RBL lists these days. Below are
> my lists (in order). I would still like to be able to block more.....
DNSbl's I Currently Use (in alphabetical order)
blackholes.easynet.nl
cbl.abuseat.org
list.dsbl.org
opm.blitzed.org
relays.ordb.org
sbl.spamhaus.org
spamdomains.blackholes.easynet.nl (RHSBL)
And some pretty damn aggressive local lists. Basically: Anything
that gets past the above, and there's more than two or three spams
from a /24, the entire /24 gets dropped into a "list and forget"
list.
Same DNSbl's, same local listing policy, at work and at home.
Very low "false positive" rate.
--
Jim Seymour | "Some of the lies are so strange it
jsey...@LinxNet.com | makes you wonder about the spammer's
LinxNet Spam Files: | sanity."
http://www.LinxNet.com/misc/spam | - Ed Foster, "The Gripe Line" 6/24/02
Administrator
bl...@grace.speakeasy.net says...
> JerryMouse <nos...@bisusa.com> wrote:
> > Huey Callison wrote:
> > > That's irrelevant to the fact that SpamCop still has a sizeable
> > > false-positive problem. The metrics by which it determines what
> > > servers are sending spam are flawed in that SpamCop occasionally
> > > lists servers that are not sending a significant amount of spam,
> > > and in some cases it lists servers that aren't sending any spam.
> > > Whether or not SpamCop punishes the people who cause those
> > > false-positive listings doesn't matter, because the listings still
> > > happen in the first place.
> > You are absolutely, totally, and mysteriously wrong.
>
> I don't think so.
>
> A friend of mine has an AOL account. Checking my logs, I note that one
> of AOL's out-MXes that I've gotten mail from him through is
> 152.163.225.101. Spamcop is having a little bit of trouble right now,
> but it looks to me like that IP has been listed and delisted four times
> in the last month.
And correctly. see <http://google.com/groups?q=152.163.225.101+group:
*.admin.net-abuse.*&scoring=d>
Two examples in the last month from that IP that you can see for
yourself are spam:
<http://google.com/groups?selm=139.25f8527e.2cb2081f%40aol.com>
<http://google.com/groups?selm=200310060633.h966XZ6R024248%
40jupiter.gwalter.demon.co.uk>
>
> > I've gone back and looked it up. So far this year, SpamCop has
> > caught a little over 32,000 (32,045) spams on my machine (SpamEater
> > keeps count). Not one has been a false positive. Not ONE.
>
> Bully for you. Spamcop is clearly a good solution for you.
>
> Unfortunately, it isn't a good solution for anyone who expects to get
> mail from AOL, so unless you're willing to eliminate 35 million people
> from the set of folks who are allowed to email you, it might NOT be.
>
> > > If those false-positive listings are all legitimate mailing lists that
> > > you're not subscribed to, or have whitelisted, that's fine, but unless
> > > your whitelist includes all of the outbound MXes of everyone you will
> > > ever get legitimate email from, SpamCop will eventually block mail you
> > > want, along with all of the spam that it stops.
> > And eventually the sun will expire. I've been using SpamCop a little over
> > four YEARS and can't remember an unfounded block (and I do check this
> > stuff).
>
> Spamcop has listed servers that have never sent spam, but do send
> legitimate mail. If this is not borne out by your personal statistics,
> more power to you. The statistics I am familiar with are on a mailserver
> cluster that receives in ten minutes what your system receives in a
> year, delivering mail to a quarter million mailboxes. And my experience
> as well as my personal preference tells me that when paying customers
> can't get email from their buddy Scott who has an account with AOL,
> they will complain.
Then its up to you to do as I have done and whitelisted aol.com through
that RBL check.
>
> > Your arguments are simply not supported by my experience. Maybe I'm just
> > lucky. Maybe you're just jinxed.
>
> Or maybe your experience is different from mine.
>
>
AJ
Huey Callison
> bas-...@grace.speakeasy.net says...
> > JerryMouse <nos...@bisusa.com> wrote:
> > > Huey Callison wrote:
> > > > That's irrelevant to the fact that SpamCop still has a sizeable
> > > You are absolutely, totally, and mysteriously wrong.
> > I don't think so.
> > A friend of mine has an AOL account. Checking my logs, I note that one
> > of AOL's out-MXes that I've gotten mail from him through is
> > 152.163.225.101. Spamcop is having a little bit of trouble right now,
> > but it looks to me like that IP has been listed and delisted four times
> > in the last month.
> And correctly. see <http://google.com/groups?q=152.163.225.101+group:
> *.admin.net-abuse.*&scoring=d>
The word 'correctly' in that statement is misleading. Yes, the listing
happened 'correctly' in regards to SpamCop's heuristics, but those
heuristics are pretty fundamentally broken if they cause major
providers' outbound MXes to be routinely listed when those IPs are not a
significant source of spam.
Let's look at the two opposite edge cases: a residential broadband line
with no legitimate mailserver but with a trojanned box or insecure proxy
on it, and the largest legitimate mailservers on the internet. The
broadband line is going to send millions of pieces of mail, and all of
them will be spam. A handful of users will complain, and SpamCop will
correctly block this IP as a spam source. The largest legitimate
mailservers on the internet are going to send millions of pieces of
mail, and a comparatively tiny percentage of them will be spam. A
handful of users will complain, and SpamCop will 'correctly' block this
IP as a spam source. ...except, in this case, it's also going to block
millions of pieces of legitimate mail, compared to a very small amount
of spam.
Somewhere between those two extremes, SpamCop starts blocking more spam
than legitimate mail. It blocks a _lot_ of spam. It also blocks way too
much legitimate mail to be used in a commercial production environment
for anything other than tagging, and even then, it's going to cause
problems. An occasional baby with the bathwater is sadly pretty much
unavoidable; dumping a bathtub that has thirty-five million babies in it
is fundamental brokenness, regardless of whether the ruleset is applied
'correctly' or not.
> > Spamcop has listed servers that have never sent spam, but do send
> > legitimate mail. If this is not borne out by your personal statistics,
> > more power to you. The statistics I am familiar with are on a mailserver
> > cluster that receives in ten minutes what your system receives in a
> > year, delivering mail to a quarter million mailboxes. And my experience
> > as well as my personal preference tells me that when paying customers
> > can't get email from their buddy Scott who has an account with AOL,
> > they will complain.
> Then its up to you to do as I have done and whitelisted aol.com through
> that RBL check.
If a DNSBL requires a massive whitelist to remove the false positives,
why use it? The CBL blocks almost as much spam as the SpamCop DNSBL
does, and without the false-positive problem.
The only piece of a sound spam-blocking strategy I can see SpamCop
fitting into would be greylisting. Delay connections from SCBLed hosts
for a couple hours, then check the CBL to see if it's legitimate.
This would _still_ require whitelisting all of the major providers'
out-MXes (or it'd drive queues through the roof) but would allow you to
take advantage of the quick-response ability of SpamCop without having
the massive false-positive problems.
--
Huey
Jem Berkes
> line with no legitimate mailserver but with a trojanned box or
> insecure proxy on it, and the largest legitimate mailservers on the
> internet. The broadband line is going to send millions of pieces of
> mail, and all of them will be spam. A handful of users will complain,
> and SpamCop will correctly block this IP as a spam source. The largest
> legitimate mailservers on the internet are going to send millions of
> pieces of mail, and a comparatively tiny percentage of them will be
> spam. A handful of users will complain, and SpamCop will 'correctly'
> block this IP as a spam source. ...except, in this case, it's also
> going to block millions of pieces of legitimate mail, compared to a
> very small amount of spam.
Seems to me that a system like spamcop (or any other dynamic system that
gets active feedback) would benefit a lot from a Bayesian-type algorithm.
The fundamental advantage of this being: instead of just looking at what is
spam, you also consider what is not spam.
A little spam from a netblock that is predominantly legit is not a great
concern. This is a netblock that is, for the most part, behaving well.
OTOH a netblock that is spewing almost entirely spam, with hardly any legit
mail, is obviously a region of the net you want to block off. These would
include heavily abused residential connections, etc.
If we could accomplish something like that in a blocklist, I would be so
much happier because admins wouldn't block my server simply because I have
a dynamic IP address. Instead, they could reject mail from my netblock if
my region of the net is actually a significant spam source.