You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Warren Togami <wt...@redhat.com> on 2009/11/15 09:14:52 UTC
DNSBL Comparison 20091114
http://mail-archives.apache.org/mod_mbox/spamassassin-users/200910.mbox/%3C4AD11C44.9030201@redhat.com%3E
Compare this report to a similar report last month.
http://wiki.apache.org/spamassassin/NightlyMassCheck
The results below are only as good as the data submitted by nightly
masscheck volunteers. Please join us in nightly masschecks to increase
the sample size of the corpora so we can have greater confidence in
the nightly statistics.
http://ruleqa.spamassassin.org/20091114-r836144-n
Spam 131399 messages from 18 users
Ham 189948 messages from 18 users
============================
DNSBL lastexternal by Safety
============================
SPAM% HAM% RANK RULE
12.8342% 0.0021% 0.94 RCVD_IN_PSBL *
12.3053% 0.0026% 0.94 RCVD_IN_XBL
31.2499% 0.0827% 0.87 RCVD_IN_ANBREP_BL *2
80.2578% 0.1485% 0.86 RCVD_IN_PBL
27.1836% 0.1985% 0.79 RCVD_IN_SORBS_DUL
19.8213% 0.1785% 0.79 RCVD_IN_SEMBLACK *
90.9360% 0.3854% 0.77 RCVD_IN_BRBL_LASTEXT
13.0564% 0.4838% 0.67 RCVD_IN_HOSTKARMA_BL *
Commentary:
* PSBL and XBL lead in apparent safety.
* ANBREP was added after the October report and has made a surprisingly
strong showing in this past month. ANBREP is currently unavailable to
the general public. The list owner is thinking about going public with
the list, which I would encourage because they are clearly doing
something right. It seems he would need a global network of automated
mirrors to be able to scale. He would also need listing/delisting
policy clearly stated on a web page somewhere.
* SEMBLACK consistently has been performing adequately in safety while
catching a respectable amount of spam. I personally use this
non-default blacklist.
* It is clear that the two main blacklists are Spamhaus and BRBL. The
Zen combinatoin of Spamhaus zones is extremely effective and generally
safe. BRBL has a high hit rate as well, with a moderate safety rating.
* HOSTKARMA_BL ranks dead last in safety for the past several weeks in a
row, while not being more effective against spam than PSBL, XBL or SEMBLACK.
===============================
HOSTKARMA_BL much better as URIBL
===============================
SPAM% HAM% RANK RULE
68.3651% 0.2806% 0.79 URIBL_HOSTKARMA_BL *
Commentary:
While HOSTKARMA_BL is pretty unsafe as a plain DNSBL, it is surprisingly
effective as a URIBL. This is curious as it seems it was not designed
to be used as a URIBL. In any case as long our masschecks show good
statistics like this, I will personally use this on my own spamassassin
server.
=========================
SPAMCOP Dangerous?
=========================
SPAM% HAM% RANK RULE
17.4225% 2.6076% 0.56 RCVD_IN_BL_SPAMCOP_NET *
Commentary:
Is Spamcop seriously this bad? It consistently has shown a high false
positive rates in these past weeks. Was it safer than this in the past
to warrant the current high score in spamassassin-3.2.5?
Warren Togami
wtogami@redhat.com
Re: DNSBL Comparison 20091114
Posted by Warren Togami <wt...@redhat.com>.
On 11/15/2009 11:00 AM, Marc Perkel wrote:
>
>
> Warren Togami wrote:
>> http://mail-archives.apache.org/mod_mbox/spamassassin-users/200910.mbox/%3C4AD11C44.9030201@redhat.com%3E
>>
>> Compare this report to a similar report last month.
>>
>> http://wiki.apache.org/spamassassin/NightlyMassCheck
>> The results below are only as good as the data submitted by nightly
>> masscheck volunteers. Please join us in nightly masschecks to increase
>> the sample size of the corpora so we can have greater confidence in
>> the nightly statistics.
>>
>> http://ruleqa.spamassassin.org/20091114-r836144-n
>> Spam 131399 messages from 18 users
>> Ham 189948 messages from 18 users
>>
>> ============================
>> DNSBL lastexternal by Safety
>> ============================
>> SPAM% HAM% RANK RULE
>> 12.8342% 0.0021% 0.94 RCVD_IN_PSBL *
>> 12.3053% 0.0026% 0.94 RCVD_IN_XBL
>> 31.2499% 0.0827% 0.87 RCVD_IN_ANBREP_BL *2
>> 80.2578% 0.1485% 0.86 RCVD_IN_PBL
>> 27.1836% 0.1985% 0.79 RCVD_IN_SORBS_DUL
>> 19.8213% 0.1785% 0.79 RCVD_IN_SEMBLACK *
>> 90.9360% 0.3854% 0.77 RCVD_IN_BRBL_LASTEXT
>> 13.0564% 0.4838% 0.67 RCVD_IN_HOSTKARMA_BL *
>>
>> Commentary:
>> * PSBL and XBL lead in apparent safety.
>> * ANBREP was added after the October report and has made a
>> surprisingly strong showing in this past month. ANBREP is currently
>> unavailable to the general public. The list owner is thinking about
>> going public with the list, which I would encourage because they are
>> clearly doing something right. It seems he would need a global network
>> of automated mirrors to be able to scale. He would also need
>> listing/delisting policy clearly stated on a web page somewhere.
>> * SEMBLACK consistently has been performing adequately in safety while
>> catching a respectable amount of spam. I personally use this
>> non-default blacklist.
>> * It is clear that the two main blacklists are Spamhaus and BRBL. The
>> Zen combinatoin of Spamhaus zones is extremely effective and generally
>> safe. BRBL has a high hit rate as well, with a moderate safety rating.
>> * HOSTKARMA_BL ranks dead last in safety for the past several weeks in
>> a row, while not being more effective against spam than PSBL, XBL or
>> SEMBLACK.
>>
>> ===============================
>> HOSTKARMA_BL much better as URIBL
>> ===============================
>> SPAM% HAM% RANK RULE
>> 68.3651% 0.2806% 0.79 URIBL_HOSTKARMA_BL *
>>
>> Commentary:
>> While HOSTKARMA_BL is pretty unsafe as a plain DNSBL, it is
>> surprisingly effective as a URIBL. This is curious as it seems it was
>> not designed to be used as a URIBL. In any case as long our masschecks
>> show good statistics like this, I will personally use this on my own
>> spamassassin server.
>>
>> =========================
>> SPAMCOP Dangerous?
>> =========================
>> SPAM% HAM% RANK RULE
>> 17.4225% 2.6076% 0.56 RCVD_IN_BL_SPAMCOP_NET *
>>
>> Commentary:
>> Is Spamcop seriously this bad? It consistently has shown a high false
>> positive rates in these past weeks. Was it safer than this in the past
>> to warrant the current high score in spamassassin-3.2.5?
>>
>> Warren Togami
>> wtogami@redhat.com
>>
>
> All I can say is that if your results were typical then we would be out
> of business. Your results are inconsistent with two other comparison lists.
>
> http://www.intra2net.com/en/support/antispam/blacklist.php_dnsbl=RCVD_IN_JMF_BL.html
http://ruleqa.spamassassin.org/20091114-r836144-n
http://www.intra2net.com/en/support/antispam/index.php
Both of these sites show roughly similar FP rates. Both sites show
nearly 0% PSBL and ~0.5% HOSTKARMA.
>
> http://www.sdsc.edu/~jeff/spam/cbc.html
>
This page says nothing about FP's.
>
> I also doubt we are as good of a URIBL as your resukts indicate. I'm
> thinking we got lucky on your test somehow. Although behind the scenes
> we do feed a lot of data to other RBL people so maybe it's related somehow.
It seems that your list was not meant to be a URIBL, (it isn't
documented as such) but Henrik suggested adding that testing rule to our
weekly masschecks. The URIBL results have been pretty consistent for
weeks now. Yes, perhaps this is luck.
Warren
Re: DNSBL Comparison 20091114
Posted by Marc Perkel <ma...@perkel.com>.
Warren Togami wrote:
> http://mail-archives.apache.org/mod_mbox/spamassassin-users/200910.mbox/%3C4AD11C44.9030201@redhat.com%3E
>
> Compare this report to a similar report last month.
>
> http://wiki.apache.org/spamassassin/NightlyMassCheck
> The results below are only as good as the data submitted by nightly
> masscheck volunteers. Please join us in nightly masschecks to
> increase the sample size of the corpora so we can have greater
> confidence in the nightly statistics.
>
> http://ruleqa.spamassassin.org/20091114-r836144-n
> Spam 131399 messages from 18 users
> Ham 189948 messages from 18 users
>
> ============================
> DNSBL lastexternal by Safety
> ============================
> SPAM% HAM% RANK RULE
> 12.8342% 0.0021% 0.94 RCVD_IN_PSBL *
> 12.3053% 0.0026% 0.94 RCVD_IN_XBL
> 31.2499% 0.0827% 0.87 RCVD_IN_ANBREP_BL *2
> 80.2578% 0.1485% 0.86 RCVD_IN_PBL
> 27.1836% 0.1985% 0.79 RCVD_IN_SORBS_DUL
> 19.8213% 0.1785% 0.79 RCVD_IN_SEMBLACK *
> 90.9360% 0.3854% 0.77 RCVD_IN_BRBL_LASTEXT
> 13.0564% 0.4838% 0.67 RCVD_IN_HOSTKARMA_BL *
>
> Commentary:
> * PSBL and XBL lead in apparent safety.
> * ANBREP was added after the October report and has made a
> surprisingly strong showing in this past month. ANBREP is currently
> unavailable to the general public. The list owner is thinking about
> going public with the list, which I would encourage because they are
> clearly doing something right. It seems he would need a global
> network of automated mirrors to be able to scale. He would also need
> listing/delisting policy clearly stated on a web page somewhere.
> * SEMBLACK consistently has been performing adequately in safety while
> catching a respectable amount of spam. I personally use this
> non-default blacklist.
> * It is clear that the two main blacklists are Spamhaus and BRBL. The
> Zen combinatoin of Spamhaus zones is extremely effective and generally
> safe. BRBL has a high hit rate as well, with a moderate safety rating.
> * HOSTKARMA_BL ranks dead last in safety for the past several weeks in
> a row, while not being more effective against spam than PSBL, XBL or
> SEMBLACK.
>
> ===============================
> HOSTKARMA_BL much better as URIBL
> ===============================
> SPAM% HAM% RANK RULE
> 68.3651% 0.2806% 0.79 URIBL_HOSTKARMA_BL *
>
> Commentary:
> While HOSTKARMA_BL is pretty unsafe as a plain DNSBL, it is
> surprisingly effective as a URIBL. This is curious as it seems it was
> not designed to be used as a URIBL. In any case as long our
> masschecks show good statistics like this, I will personally use this
> on my own spamassassin server.
>
> =========================
> SPAMCOP Dangerous?
> =========================
> SPAM% HAM% RANK RULE
> 17.4225% 2.6076% 0.56 RCVD_IN_BL_SPAMCOP_NET *
>
> Commentary:
> Is Spamcop seriously this bad? It consistently has shown a high false
> positive rates in these past weeks. Was it safer than this in the
> past to warrant the current high score in spamassassin-3.2.5?
>
> Warren Togami
> wtogami@redhat.com
>
All I can say is that if your results were typical then we would be out
of business. Your results are inconsistent with two other comparison lists.
http://www.intra2net.com/en/support/antispam/blacklist.php_dnsbl=RCVD_IN_JMF_BL.html
http://www.sdsc.edu/~jeff/spam/cbc.html
Additionally results vary depending on where you get your spam from and
if the people spamming you are also spamming us. One of the ways we
improve results is if someone is using out list then they should also
add tarbaby.junkemailfilter.com as their highest MX record because that
way the list can pick up those who are spamming you and tune itself to
add your spam to our list.
I also doubt we are as good of a URIBL as your resukts indicate. I'm
thinking we got lucky on your test somehow. Although behind the scenes
we do feed a lot of data to other RBL people so maybe it's related somehow.
Not to discredit your fine work. All results are interesting.
Understanding the results is often the tricky part.
Re: DNSBL Comparison 20091114
Posted by Henrik K <he...@hege.li>.
On Sun, Nov 15, 2009 at 10:08:45AM +0100, Raymond Dijkxhoorn wrote:
>>> ===============================
>>> HOSTKARMA_BL much better as URIBL
>>> ===============================
>>> SPAM% HAM% RANK RULE
>>> 68.3651% 0.2806% 0.79 URIBL_HOSTKARMA_BL *
>
> How do you check return values? There is a lot inside. If you 'just' use
> the default response you get back any spam listed on a freemail platform
> and so on. Is there no legitimate mail from those platforms? I tend to
> say, yeah right. But for the fairly limited test set it could be the
> case.
I tried reading this several times, but I'm still not sure what you are
getting at.
http://svn.apache.org/viewvc/spamassassin/trunk/rulesrc/sandbox/wtogami/20_bug_6212_hostkarma.cf?view=markup
Personally URIBL_HOSTKARMA_FRESH_2D is working great here with 0.99 S/O. But
as we know, hostkarma results might fluctuate from time to time given it's
nature.
Anyways, it's a fact that SA mass checks can't measure things accurately,
since not everyone uses the REUSE mass check feature. Checking weeks old
corpuses against live BLs isn't exactly good science. And things like
FRESH_2D are impossible to rate that way.
Re: DNSBL Comparison 20091114
Posted by Raymond Dijkxhoorn <ra...@prolocation.net>.
Hi!
>> 27.1836% 0.1985% 0.79 RCVD_IN_SORBS_DUL
>> 19.8213% 0.1785% 0.79 RCVD_IN_SEMBLACK *
>> 90.9360% 0.3854% 0.77 RCVD_IN_BRBL_LASTEXT
>> 13.0564% 0.4838% 0.67 RCVD_IN_HOSTKARMA_BL *
>> * It is clear that the two main blacklists are Spamhaus and BRBL. The
>> Zen combinatoin of Spamhaus zones is extremely effective and generally
>> safe. BRBL has a high hit rate as well, with a moderate safety rating.
Thats moderate? That you loose 1 legitimate mail over ~ 3000 mails
if you start blocking with it ?
I think the FP rating should be much much lower and like BRBL they should
check and cleanout FP's before it will be taken anything close to serious.
>> ===============================
>> HOSTKARMA_BL much better as URIBL
>> ===============================
>> SPAM% HAM% RANK RULE
>> 68.3651% 0.2806% 0.79 URIBL_HOSTKARMA_BL *
How do you check return values? There is a lot inside. If you 'just' use
the default response you get back any spam listed on a freemail platform
and so on. Is there no legitimate mail from those platforms? I tend to
say, yeah right. But for the fairly limited test set it could be the case.
You have to know whats inside to do proper suggestions. If it works for
you, sure, will it work for others. If you care about your inbox i would
not jump to these conslusions just now.
Just my 2 cents.
And yes, Spamcop is doing a bad job (As BL) nowdays, i would not even
consider rejecting on MTA with that one. Use it to score, but dont use it
to reject. That time is long gone. User reports do have disadvantages ;)
Bye,
Raymond.
Re: DNSBL Comparison 20091114
Posted by Res <re...@ausics.net>.
On Mon, 16 Nov 2009, richard@buzzhost.co.uk wrote:
> You neglected to trim my name from your post making it look like the
hrmm... that is not how alpine showed it...
> That said {don't you just lurvvee net policemen} I do have to laugh that
> the BRBL has mysql.com listed, given it sits at the heart of every one
> of the spam 'and virus' firewalls they sell. This could potentially mean
> that Barracuda are not getting up-to-date information on mysql
> developments - so they can steal it and put it in their chudware.
indeed :)
--
Res
"What does Windows have that Linux doesn't?" - One hell of a lot of bugs!
Re: DNSBL Comparison 20091114
Posted by "richard@buzzhost.co.uk" <ri...@buzzhost.co.uk>.
On Mon, 2009-11-16 at 17:21 +1000, Res wrote:
> On Mon, 16 Nov 2009, richard@buzzhost.co.uk wrote:
>
> >>>> safe. BRBL has a high hit rate as well, with a moderate safety rating.
>
> Wondered why i wasn't getting anything from mysql.com for over a week,
> BRBL has them listed :)
>
You neglected to trim my name from your post making it look like the
comment is mine - it is not :-) As Matus UHLAR pointed out the other day
when I did this: "Since I didn't clearly write the part you are reacting
on, it would be nice from you to remove my name from the begin" - so
consider yourself told off, but rest assured I won't be sending you a
childish off-list email for doing it :-)
That said {don't you just lurvvee net policemen} I do have to laugh that
the BRBL has mysql.com listed, given it sits at the heart of every one
of the spam 'and virus' firewalls they sell. This could potentially mean
that Barracuda are not getting up-to-date information on mysql
developments - so they can steal it and put it in their chudware.
Re: DNSBL Comparison 20091114
Posted by Res <re...@ausics.net>.
On Mon, 16 Nov 2009, richard@buzzhost.co.uk wrote:
>>>> safe. BRBL has a high hit rate as well, with a moderate safety rating.
Wondered why i wasn't getting anything from mysql.com for over a week,
BRBL has them listed :)
--
Res
"What does Windows have that Linux doesn't?" - One hell of a lot of bugs!
Re: DNSBL Comparison 20091114
Posted by "richard@buzzhost.co.uk" <ri...@buzzhost.co.uk>.
On Mon, 2009-11-16 at 14:00 +0000, Justin Mason wrote:
> First -- my name is not Jim. Secondly -- I don't care what Spamhaus
> does, I'm asking what you suggest SpamAssassin do to measure FPs.
Is that a core feature of spamassassin Just in? Is it necessary to have
that data? Will 'Hey, I noticed Spamhaus had 22 false positives in ten
million' last week have everyone rushing to change the scores?
The only false positives and false negatives that matter are the ones
that effect a given user. One man's false positives can be another man's
spam. It's the metrics of measuring opinion.
Re: DNSBL Comparison 20091114
Posted by LuKreme <kr...@kreme.com>.
On 16-Nov-2009, at 07:00, Justin Mason wrote:
> First -- my name is not Jim. Secondly -- I don't care what Spamhaus
> does, I'm asking what you suggest SpamAssassin do to measure FPs.
Thirdly, don't TOFU post (at least twice as bad as Top-posting).
--
May the forces of evil become confused on the way to your house.
Re: DNSBL Comparison 20091114
Posted by Justin Mason <jm...@jmason.org>.
First -- my name is not Jim. Secondly -- I don't care what Spamhaus
does, I'm asking what you suggest SpamAssassin do to measure FPs.
--j.
On Mon, Nov 16, 2009 at 06:00, richard@buzzhost.co.uk
<ri...@buzzhost.co.uk> wrote:
> On Sun, 2009-11-15 at 20:34 +0000, Justin Mason wrote:
>> On Sun, Nov 15, 2009 at 08:53, richard@buzzhost.co.uk
>> <ri...@buzzhost.co.uk> wrote:
>> > On Sun, 2009-11-15 at 03:14 -0500, Warren Togami wrote:
>> >> http://mail-archives.apache.org/mod_mbox/spamassassin-users/200910.mbox/%3C4AD11C44.9030201@redhat.com%3E
>> >> Compare this report to a similar report last month.
>> >>
>> >> http://wiki.apache.org/spamassassin/NightlyMassCheck
>> >> The results below are only as good as the data submitted by nightly
>> >> masscheck volunteers. Please join us in nightly masschecks to increase
>> >> the sample size of the corpora so we can have greater confidence in
>> >> the nightly statistics.
>> >>
>> >> http://ruleqa.spamassassin.org/20091114-r836144-n
>> >> Spam 131399 messages from 18 users
>> >> Ham 189948 messages from 18 users
>> >>
>> >> ============================
>> >> DNSBL lastexternal by Safety
>> >> ============================
>> >> SPAM% HAM% RANK RULE
>> >> 12.8342% 0.0021% 0.94 RCVD_IN_PSBL *
>> >> 12.3053% 0.0026% 0.94 RCVD_IN_XBL
>> >> 31.2499% 0.0827% 0.87 RCVD_IN_ANBREP_BL *2
>> >> 80.2578% 0.1485% 0.86 RCVD_IN_PBL
>> >> 27.1836% 0.1985% 0.79 RCVD_IN_SORBS_DUL
>> >> 19.8213% 0.1785% 0.79 RCVD_IN_SEMBLACK *
>> >> 90.9360% 0.3854% 0.77 RCVD_IN_BRBL_LASTEXT
>> >> 13.0564% 0.4838% 0.67 RCVD_IN_HOSTKARMA_BL *
>> >>
>> >> Commentary:
>> >> * PSBL and XBL lead in apparent safety.
>> >> * ANBREP was added after the October report and has made a surprisingly
>> >> strong showing in this past month. ANBREP is currently unavailable to
>> >> the general public. The list owner is thinking about going public with
>> >> the list, which I would encourage because they are clearly doing
>> >> something right. It seems he would need a global network of automated
>> >> mirrors to be able to scale. He would also need listing/delisting
>> >> policy clearly stated on a web page somewhere.
>> >> * SEMBLACK consistently has been performing adequately in safety while
>> >> catching a respectable amount of spam. I personally use this
>> >> non-default blacklist.
>> >> * It is clear that the two main blacklists are Spamhaus and BRBL. The
>> >> Zen combinatoin of Spamhaus zones is extremely effective and generally
>> >> safe. BRBL has a high hit rate as well, with a moderate safety rating.
>> >> * HOSTKARMA_BL ranks dead last in safety for the past several weeks in a
>> >> row, while not being more effective against spam than PSBL, XBL or SEMBLACK.
>> >>
>> >> ===============================
>> >> HOSTKARMA_BL much better as URIBL
>> >> ===============================
>> >> SPAM% HAM% RANK RULE
>> >> 68.3651% 0.2806% 0.79 URIBL_HOSTKARMA_BL *
>> >>
>> >> Commentary:
>> >> While HOSTKARMA_BL is pretty unsafe as a plain DNSBL, it is surprisingly
>> >> effective as a URIBL. This is curious as it seems it was not designed
>> >> to be used as a URIBL. In any case as long our masschecks show good
>> >> statistics like this, I will personally use this on my own spamassassin
>> >> server.
>> >>
>> >> =========================
>> >> SPAMCOP Dangerous?
>> >> =========================
>> >> SPAM% HAM% RANK RULE
>> >> 17.4225% 2.6076% 0.56 RCVD_IN_BL_SPAMCOP_NET *
>> >>
>> >> Commentary:
>> >> Is Spamcop seriously this bad? It consistently has shown a high false
>> >> positive rates in these past weeks. Was it safer than this in the past
>> >> to warrant the current high score in spamassassin-3.2.5?
>> >>
>> >> Warren Togami
>> >> wtogami@redhat.com
>> >
>> > Is it not a bit flawed to do the metrics on volunteer submissions, given
>> > the Spamhaus has is said to have a small army of them? It means the data
>> > cannot be relied upon as any kind of sensible comparison.
>>
>> please explain. How would you suggest measuring false positives?
>>
> Do you think that volunteer submissions are an accurate way to do them,
> or do you think that is open to abuse?
>
> For example, say I am Steve Linford with a small army of volunteers. I
> get a few false positives come in from Spamhaus, and a few from SORBS.
> What is my inclination when I submit the data?
>
> It takes only a small amount of research and a trawl through the NANAE
> archives to get a handle on the problem, and the general abuse and
> nefarious goings on with DNSBL volunteers. It is fair to say that there
> is not much love lost.
>
> I'm not pretending I have the answers, so it's probably better to take
> these lists with a large bucket of salt and find how any given DNSBL
> list works for a given organisation.
>
> In a world where presidents and world leaders in America, Zimbabwe and
> Afghanistan get 'elected' on tainted data, some random RBL 'comparison'
> list is a trivial by comparison. It must, however, be duly remembered
> that there are many competing 'sides' in the world of the DNSBL's, each
> looking to do the other discredit.
>
> Perhaps Jim, as you posed the question - you have some strong feelings
> on the matter that you would like to share?
>
>
--
--j.
Re: DNSBL Comparison 20091114
Posted by "richard@buzzhost.co.uk" <ri...@buzzhost.co.uk>.
On Sun, 2009-11-15 at 20:34 +0000, Justin Mason wrote:
> On Sun, Nov 15, 2009 at 08:53, richard@buzzhost.co.uk
> <ri...@buzzhost.co.uk> wrote:
> > On Sun, 2009-11-15 at 03:14 -0500, Warren Togami wrote:
> >> http://mail-archives.apache.org/mod_mbox/spamassassin-users/200910.mbox/%3C4AD11C44.9030201@redhat.com%3E
> >> Compare this report to a similar report last month.
> >>
> >> http://wiki.apache.org/spamassassin/NightlyMassCheck
> >> The results below are only as good as the data submitted by nightly
> >> masscheck volunteers. Please join us in nightly masschecks to increase
> >> the sample size of the corpora so we can have greater confidence in
> >> the nightly statistics.
> >>
> >> http://ruleqa.spamassassin.org/20091114-r836144-n
> >> Spam 131399 messages from 18 users
> >> Ham 189948 messages from 18 users
> >>
> >> ============================
> >> DNSBL lastexternal by Safety
> >> ============================
> >> SPAM% HAM% RANK RULE
> >> 12.8342% 0.0021% 0.94 RCVD_IN_PSBL *
> >> 12.3053% 0.0026% 0.94 RCVD_IN_XBL
> >> 31.2499% 0.0827% 0.87 RCVD_IN_ANBREP_BL *2
> >> 80.2578% 0.1485% 0.86 RCVD_IN_PBL
> >> 27.1836% 0.1985% 0.79 RCVD_IN_SORBS_DUL
> >> 19.8213% 0.1785% 0.79 RCVD_IN_SEMBLACK *
> >> 90.9360% 0.3854% 0.77 RCVD_IN_BRBL_LASTEXT
> >> 13.0564% 0.4838% 0.67 RCVD_IN_HOSTKARMA_BL *
> >>
> >> Commentary:
> >> * PSBL and XBL lead in apparent safety.
> >> * ANBREP was added after the October report and has made a surprisingly
> >> strong showing in this past month. ANBREP is currently unavailable to
> >> the general public. The list owner is thinking about going public with
> >> the list, which I would encourage because they are clearly doing
> >> something right. It seems he would need a global network of automated
> >> mirrors to be able to scale. He would also need listing/delisting
> >> policy clearly stated on a web page somewhere.
> >> * SEMBLACK consistently has been performing adequately in safety while
> >> catching a respectable amount of spam. I personally use this
> >> non-default blacklist.
> >> * It is clear that the two main blacklists are Spamhaus and BRBL. The
> >> Zen combinatoin of Spamhaus zones is extremely effective and generally
> >> safe. BRBL has a high hit rate as well, with a moderate safety rating.
> >> * HOSTKARMA_BL ranks dead last in safety for the past several weeks in a
> >> row, while not being more effective against spam than PSBL, XBL or SEMBLACK.
> >>
> >> ===============================
> >> HOSTKARMA_BL much better as URIBL
> >> ===============================
> >> SPAM% HAM% RANK RULE
> >> 68.3651% 0.2806% 0.79 URIBL_HOSTKARMA_BL *
> >>
> >> Commentary:
> >> While HOSTKARMA_BL is pretty unsafe as a plain DNSBL, it is surprisingly
> >> effective as a URIBL. This is curious as it seems it was not designed
> >> to be used as a URIBL. In any case as long our masschecks show good
> >> statistics like this, I will personally use this on my own spamassassin
> >> server.
> >>
> >> =========================
> >> SPAMCOP Dangerous?
> >> =========================
> >> SPAM% HAM% RANK RULE
> >> 17.4225% 2.6076% 0.56 RCVD_IN_BL_SPAMCOP_NET *
> >>
> >> Commentary:
> >> Is Spamcop seriously this bad? It consistently has shown a high false
> >> positive rates in these past weeks. Was it safer than this in the past
> >> to warrant the current high score in spamassassin-3.2.5?
> >>
> >> Warren Togami
> >> wtogami@redhat.com
> >
> > Is it not a bit flawed to do the metrics on volunteer submissions, given
> > the Spamhaus has is said to have a small army of them? It means the data
> > cannot be relied upon as any kind of sensible comparison.
>
> please explain. How would you suggest measuring false positives?
>
Do you think that volunteer submissions are an accurate way to do them,
or do you think that is open to abuse?
For example, say I am Steve Linford with a small army of volunteers. I
get a few false positives come in from Spamhaus, and a few from SORBS.
What is my inclination when I submit the data?
It takes only a small amount of research and a trawl through the NANAE
archives to get a handle on the problem, and the general abuse and
nefarious goings on with DNSBL volunteers. It is fair to say that there
is not much love lost.
I'm not pretending I have the answers, so it's probably better to take
these lists with a large bucket of salt and find how any given DNSBL
list works for a given organisation.
In a world where presidents and world leaders in America, Zimbabwe and
Afghanistan get 'elected' on tainted data, some random RBL 'comparison'
list is a trivial by comparison. It must, however, be duly remembered
that there are many competing 'sides' in the world of the DNSBL's, each
looking to do the other discredit.
Perhaps Jim, as you posed the question - you have some strong feelings
on the matter that you would like to share?
Re: DNSBL Comparison 20091114
Posted by Justin Mason <jm...@jmason.org>.
On Sun, Nov 15, 2009 at 08:53, richard@buzzhost.co.uk
<ri...@buzzhost.co.uk> wrote:
> On Sun, 2009-11-15 at 03:14 -0500, Warren Togami wrote:
>> http://mail-archives.apache.org/mod_mbox/spamassassin-users/200910.mbox/%3C4AD11C44.9030201@redhat.com%3E
>> Compare this report to a similar report last month.
>>
>> http://wiki.apache.org/spamassassin/NightlyMassCheck
>> The results below are only as good as the data submitted by nightly
>> masscheck volunteers. Please join us in nightly masschecks to increase
>> the sample size of the corpora so we can have greater confidence in
>> the nightly statistics.
>>
>> http://ruleqa.spamassassin.org/20091114-r836144-n
>> Spam 131399 messages from 18 users
>> Ham 189948 messages from 18 users
>>
>> ============================
>> DNSBL lastexternal by Safety
>> ============================
>> SPAM% HAM% RANK RULE
>> 12.8342% 0.0021% 0.94 RCVD_IN_PSBL *
>> 12.3053% 0.0026% 0.94 RCVD_IN_XBL
>> 31.2499% 0.0827% 0.87 RCVD_IN_ANBREP_BL *2
>> 80.2578% 0.1485% 0.86 RCVD_IN_PBL
>> 27.1836% 0.1985% 0.79 RCVD_IN_SORBS_DUL
>> 19.8213% 0.1785% 0.79 RCVD_IN_SEMBLACK *
>> 90.9360% 0.3854% 0.77 RCVD_IN_BRBL_LASTEXT
>> 13.0564% 0.4838% 0.67 RCVD_IN_HOSTKARMA_BL *
>>
>> Commentary:
>> * PSBL and XBL lead in apparent safety.
>> * ANBREP was added after the October report and has made a surprisingly
>> strong showing in this past month. ANBREP is currently unavailable to
>> the general public. The list owner is thinking about going public with
>> the list, which I would encourage because they are clearly doing
>> something right. It seems he would need a global network of automated
>> mirrors to be able to scale. He would also need listing/delisting
>> policy clearly stated on a web page somewhere.
>> * SEMBLACK consistently has been performing adequately in safety while
>> catching a respectable amount of spam. I personally use this
>> non-default blacklist.
>> * It is clear that the two main blacklists are Spamhaus and BRBL. The
>> Zen combinatoin of Spamhaus zones is extremely effective and generally
>> safe. BRBL has a high hit rate as well, with a moderate safety rating.
>> * HOSTKARMA_BL ranks dead last in safety for the past several weeks in a
>> row, while not being more effective against spam than PSBL, XBL or SEMBLACK.
>>
>> ===============================
>> HOSTKARMA_BL much better as URIBL
>> ===============================
>> SPAM% HAM% RANK RULE
>> 68.3651% 0.2806% 0.79 URIBL_HOSTKARMA_BL *
>>
>> Commentary:
>> While HOSTKARMA_BL is pretty unsafe as a plain DNSBL, it is surprisingly
>> effective as a URIBL. This is curious as it seems it was not designed
>> to be used as a URIBL. In any case as long our masschecks show good
>> statistics like this, I will personally use this on my own spamassassin
>> server.
>>
>> =========================
>> SPAMCOP Dangerous?
>> =========================
>> SPAM% HAM% RANK RULE
>> 17.4225% 2.6076% 0.56 RCVD_IN_BL_SPAMCOP_NET *
>>
>> Commentary:
>> Is Spamcop seriously this bad? It consistently has shown a high false
>> positive rates in these past weeks. Was it safer than this in the past
>> to warrant the current high score in spamassassin-3.2.5?
>>
>> Warren Togami
>> wtogami@redhat.com
>
> Is it not a bit flawed to do the metrics on volunteer submissions, given
> the Spamhaus has is said to have a small army of them? It means the data
> cannot be relied upon as any kind of sensible comparison.
please explain. How would you suggest measuring false positives?
--
--j.
Re: DNSBL Comparison 20091114
Posted by "richard@buzzhost.co.uk" <ri...@buzzhost.co.uk>.
On Sun, 2009-11-15 at 03:14 -0500, Warren Togami wrote:
> http://mail-archives.apache.org/mod_mbox/spamassassin-users/200910.mbox/%3C4AD11C44.9030201@redhat.com%3E
> Compare this report to a similar report last month.
>
> http://wiki.apache.org/spamassassin/NightlyMassCheck
> The results below are only as good as the data submitted by nightly
> masscheck volunteers. Please join us in nightly masschecks to increase
> the sample size of the corpora so we can have greater confidence in
> the nightly statistics.
>
> http://ruleqa.spamassassin.org/20091114-r836144-n
> Spam 131399 messages from 18 users
> Ham 189948 messages from 18 users
>
> ============================
> DNSBL lastexternal by Safety
> ============================
> SPAM% HAM% RANK RULE
> 12.8342% 0.0021% 0.94 RCVD_IN_PSBL *
> 12.3053% 0.0026% 0.94 RCVD_IN_XBL
> 31.2499% 0.0827% 0.87 RCVD_IN_ANBREP_BL *2
> 80.2578% 0.1485% 0.86 RCVD_IN_PBL
> 27.1836% 0.1985% 0.79 RCVD_IN_SORBS_DUL
> 19.8213% 0.1785% 0.79 RCVD_IN_SEMBLACK *
> 90.9360% 0.3854% 0.77 RCVD_IN_BRBL_LASTEXT
> 13.0564% 0.4838% 0.67 RCVD_IN_HOSTKARMA_BL *
>
> Commentary:
> * PSBL and XBL lead in apparent safety.
> * ANBREP was added after the October report and has made a surprisingly
> strong showing in this past month. ANBREP is currently unavailable to
> the general public. The list owner is thinking about going public with
> the list, which I would encourage because they are clearly doing
> something right. It seems he would need a global network of automated
> mirrors to be able to scale. He would also need listing/delisting
> policy clearly stated on a web page somewhere.
> * SEMBLACK consistently has been performing adequately in safety while
> catching a respectable amount of spam. I personally use this
> non-default blacklist.
> * It is clear that the two main blacklists are Spamhaus and BRBL. The
> Zen combinatoin of Spamhaus zones is extremely effective and generally
> safe. BRBL has a high hit rate as well, with a moderate safety rating.
> * HOSTKARMA_BL ranks dead last in safety for the past several weeks in a
> row, while not being more effective against spam than PSBL, XBL or SEMBLACK.
>
> ===============================
> HOSTKARMA_BL much better as URIBL
> ===============================
> SPAM% HAM% RANK RULE
> 68.3651% 0.2806% 0.79 URIBL_HOSTKARMA_BL *
>
> Commentary:
> While HOSTKARMA_BL is pretty unsafe as a plain DNSBL, it is surprisingly
> effective as a URIBL. This is curious as it seems it was not designed
> to be used as a URIBL. In any case as long our masschecks show good
> statistics like this, I will personally use this on my own spamassassin
> server.
>
> =========================
> SPAMCOP Dangerous?
> =========================
> SPAM% HAM% RANK RULE
> 17.4225% 2.6076% 0.56 RCVD_IN_BL_SPAMCOP_NET *
>
> Commentary:
> Is Spamcop seriously this bad? It consistently has shown a high false
> positive rates in these past weeks. Was it safer than this in the past
> to warrant the current high score in spamassassin-3.2.5?
>
> Warren Togami
> wtogami@redhat.com
Is it not a bit flawed to do the metrics on volunteer submissions, given
the Spamhaus has is said to have a small army of them? It means the data
cannot be relied upon as any kind of sensible comparison.
Re: DNSBL Comparison 20091114
Posted by Warren Togami <wt...@redhat.com>.
On 11/15/2009 03:36 PM, Justin Mason wrote:
>> SPAM% HAM% RANK RULE
>> 12.8342% 0.0021% 0.94 RCVD_IN_PSBL *
>> 12.3053% 0.0026% 0.94 RCVD_IN_XBL
>> 31.2499% 0.0827% 0.87 RCVD_IN_ANBREP_BL *2
>> 80.2578% 0.1485% 0.86 RCVD_IN_PBL
>> 27.1836% 0.1985% 0.79 RCVD_IN_SORBS_DUL
>> 19.8213% 0.1785% 0.79 RCVD_IN_SEMBLACK *
>> 90.9360% 0.3854% 0.77 RCVD_IN_BRBL_LASTEXT
>> 13.0564% 0.4838% 0.67 RCVD_IN_HOSTKARMA_BL *
>
> hi Warren --
>
> any chance you could post the S/O ratios? RANK is a bit "unportable",
> as it depends on other rules in the ruleset at the time the
> measurement takes place.
>
> --j.
I intentionally posted only RANK because it seems to be most influenced
by safety, which is the goal of this particular comparison.
Warren
Re: Back on DNSBL overlap
Posted by Justin Mason <jm...@jmason.org>.
can't type much as i've broken my elbow (oh noes!) -- but we talked in
the past about using an LR engine for rescoring. not sure if that got
anywhere though.
btw be aware also that there was a perceptron rescorer, but it
produced more fragile scores than the ga; see 3.2.0 rescoring ticket
for history
--j
On Tue, Nov 17, 2009 at 03:22, Warren Togami <wt...@redhat.com> wrote:
> On 11/16/2009 07:26 PM, Adam Katz wrote:
>>
>> My hypothesis, which I've anecdotally proven on my own deployment, is
>> that the flaws are repeated as well. Spammers that trigger spamtraps
>> on multiple DNSBLs (and URIBLs) may be sending from (or linking to)
>> servers that also deal with legitimate traffic. This means that
>> thanks to these similar indexing techniques, DNSBL overlap from
>> spammers' abuse of a non-spam-exclusive server can single-handedly
>> mark a ham as spam.
>>
>> My "solution" is to counter-intuitively *remove* points from message
>> that hit too many DNSBLs. They still net quite a positive score, but
>> that score is effectively capped at something not quite high enough to
>> kill a ham with DNSBLs alone.
>>
>> A more elegant version of this, which Karsten and I theorize might
>> even happen automatically (as scored by the GA) if I were to check my
>> adjustor into SVN, would be to reduce most of the points on the DNSBLs
>> and add them back with a meta rule containing a union of the DNSBL
>> rules (without a "multiple" tflag).
>
> I think there is a lot of merit to this approach, and it might even be a
> great idea. But I spoke with a machine learning expert and heard some
> interesting things on this topic.
>
> We held a small workshop yesterday in which she explained Logistic
> Regression and how it might be applied to automated rescoring of
> spamassassin's rules. The most intriguing aspect of her explanation was the
> suggestion of using a logarithmic function in weight scoring. I asked
> specifically about this issue of overlap (like BRBL_LASTEXT with every other
> list) and she suggested this particular method of rescoring wouldn't have an
> issue with overlap.
>
> I believe you mentioned logarithmic scoring in an earlier discussion?
>
> It appears that we have a few very smart people interested in implementing
> an alternative rescorer using Logistic Regression. We plan on using an
> existing library for the bulk of this implementation.
>
> I think we should proceed with our current generated scores for 3.3.0. After
> that we can compare the effectiveness of different approaches including your
> proposal.
>
> Specifically on the issue of overlapping DNSBL's, there might be a few
> possibilities:
>
> * Overlapping DNSBL's really is no problem with any method of scoring.
> * Overlapping DNSBL's is only a slight problem with any method of scoring,
> but if a host is blacklisted with more than one major DNSBL they have
> serious issues they need to fix and we shouldn't try to workaround for their
> benefit.
> * Overlapping DNSBL's is a real problem, but logarithmic scoring avoids it
> as an issue.
>
> rulesrc/sandbox/jm/20_bug_5984.cf:# score RCVD_IN_BRBL_LASTEXT 2.0
>
> This apparently was set manually. It appears that spamassassin-3.2.x was
> not scored when BRBL existed as a rule. Meanwhile our new GA scores
> resulted in:
>
> score RCVD_IN_BRBL_LASTEXT 0 1.644 0 1.449 # n=0 n=2
>
> This is relatively modest. This combined with one other DNSBL alone will
> not push it clearly above 5 points. I might suggest manually adjusting down
> BRBL or PBL so it requires one additional tiny score to push it over the
> edge. I'm personally comfortable enough to outright reject mail from a
> Spamhaus listed host. Given this bias, it is sufficiently cautious in my
> book to accept PBL + BRBL as insufficient.
>
> Warren Togami
> wtogami@redhat.com
>
>
--
--j.
Re: Back on DNSBL overlap
Posted by Warren Togami <wt...@redhat.com>.
On 11/16/2009 07:26 PM, Adam Katz wrote:
>
> My hypothesis, which I've anecdotally proven on my own deployment, is
> that the flaws are repeated as well. Spammers that trigger spamtraps
> on multiple DNSBLs (and URIBLs) may be sending from (or linking to)
> servers that also deal with legitimate traffic. This means that
> thanks to these similar indexing techniques, DNSBL overlap from
> spammers' abuse of a non-spam-exclusive server can single-handedly
> mark a ham as spam.
>
> My "solution" is to counter-intuitively *remove* points from message
> that hit too many DNSBLs. They still net quite a positive score, but
> that score is effectively capped at something not quite high enough to
> kill a ham with DNSBLs alone.
>
> A more elegant version of this, which Karsten and I theorize might
> even happen automatically (as scored by the GA) if I were to check my
> adjustor into SVN, would be to reduce most of the points on the DNSBLs
> and add them back with a meta rule containing a union of the DNSBL
> rules (without a "multiple" tflag).
I think there is a lot of merit to this approach, and it might even be a
great idea. But I spoke with a machine learning expert and heard some
interesting things on this topic.
We held a small workshop yesterday in which she explained Logistic
Regression and how it might be applied to automated rescoring of
spamassassin's rules. The most intriguing aspect of her explanation was
the suggestion of using a logarithmic function in weight scoring. I
asked specifically about this issue of overlap (like BRBL_LASTEXT with
every other list) and she suggested this particular method of rescoring
wouldn't have an issue with overlap.
I believe you mentioned logarithmic scoring in an earlier discussion?
It appears that we have a few very smart people interested in
implementing an alternative rescorer using Logistic Regression. We plan
on using an existing library for the bulk of this implementation.
I think we should proceed with our current generated scores for 3.3.0.
After that we can compare the effectiveness of different approaches
including your proposal.
Specifically on the issue of overlapping DNSBL's, there might be a few
possibilities:
* Overlapping DNSBL's really is no problem with any method of scoring.
* Overlapping DNSBL's is only a slight problem with any method of
scoring, but if a host is blacklisted with more than one major DNSBL
they have serious issues they need to fix and we shouldn't try to
workaround for their benefit.
* Overlapping DNSBL's is a real problem, but logarithmic scoring avoids
it as an issue.
rulesrc/sandbox/jm/20_bug_5984.cf:# score RCVD_IN_BRBL_LASTEXT 2.0
This apparently was set manually. It appears that spamassassin-3.2.x
was not scored when BRBL existed as a rule. Meanwhile our new GA scores
resulted in:
score RCVD_IN_BRBL_LASTEXT 0 1.644 0 1.449 # n=0 n=2
This is relatively modest. This combined with one other DNSBL alone
will not push it clearly above 5 points. I might suggest manually
adjusting down BRBL or PBL so it requires one additional tiny score to
push it over the edge. I'm personally comfortable enough to outright
reject mail from a Spamhaus listed host. Given this bias, it is
sufficiently cautious in my book to accept PBL + BRBL as insufficient.
Warren Togami
wtogami@redhat.com
Back on DNSBL overlap
Posted by Adam Katz <an...@khopis.com>.
Warren reported:
>> SPAM% HAM% RANK RULE
>> 12.8342% 0.0021% 0.94 RCVD_IN_PSBL *
>> 12.3053% 0.0026% 0.94 RCVD_IN_XBL
>> 31.2499% 0.0827% 0.87 RCVD_IN_ANBREP_BL *2
>> 80.2578% 0.1485% 0.86 RCVD_IN_PBL
>> 27.1836% 0.1985% 0.79 RCVD_IN_SORBS_DUL
>> 19.8213% 0.1785% 0.79 RCVD_IN_SEMBLACK *
>> 90.9360% 0.3854% 0.77 RCVD_IN_BRBL_LASTEXT
>> 13.0564% 0.4838% 0.67 RCVD_IN_HOSTKARMA_BL *
Justin requested:
> any chance you could post the S/O ratios? RANK is a bit "unportable",
> as it depends on other rules in the ruleset at the time the
> measurement takes place.
I agree with Warren in that S/O isn't as useful here. Even SPAM% is
just a minimum threshold. With respect to this specific problem, HAM%
is the best indicator of the standard stats performed by MassCheck.
That said, I think that a measure of independence from the other
RCVD_IN_* rules is an even better metric. How many hits are unique
(among DNSBLs) to each DNSBL?
I do this kind of thing manually on occasion since the data is usually
at the bottom of the detail page for each rule, e.g. the last network
test (20091114-r836144-n, http://tinyurl.com/yfef2ef ) reveals:
86% of BRBL_LASTEXT appears in PBL
97% of PBL appears in BRBL_LASTEXT
The non-overlapping 3% of PBL means it's SPAM% is 2.4077
29% of BRBL_LASTEXT appears in SORBS_DUL
97% of SORBS_DUL appears in BRBL_LASTEXT
The non-overlapping 3% of SORBS_DUL means SPAM% = 0.8155
24% of BRBL_LASTEXT appears in SORBS_WEB
94% of SORBS_WEB appears in BRBL_LASTEXT
The non-overlapping 6% of SORBS_WEB means SPAM% = 1.4041
33% of BRBL_LASTEXT appears in ANBREP_BL
97% of ANBREP_BL appears in BRBL_LASTEXT
The non-overlapping 3% of ANBREP_BL means SPAM% = 0.9075
21% of BRBL_LASTEXT appears in SEMBLACK
96% of SEMBLACK appears in BRBL_LASTEXT
The non-overlapping 4% of SEMBLACK means SPAM% = 0.7129
20% of BRBL_LASTEXT appears in ANBREP_L3
98% of ANBREP_L3 appears in BRBL_LASTEXT
The non-overlapping 2% of ANBREP_L3 means SPAM% = 0.3725
(Fetched from other pages)
18% of BRBL_LASTEXT appears in BL_SPAMCOP_NET
95% of BL_SPAMCOP_NET appears in BRBL_LASTEXT
The non-overlapping 5% of BL_SPAMCOP_NET means SPAM% = 0.8711
33% of PBL appears in RCVD_IN_SORBS_DUL
97% of SORBS_DUL appears in PBL
The non-overlapping 3% of SORBS_DUL means SPAM% = 0.8155
I can't go a step further and figure out how much of SORBS_DUL is
hitting independent of /both/ BRBL and PBL other than it's between
0.0245 and 0.8155. Removing the 27% overlap with SEMBLACK reduces
that to between 0.0179 and 0.8155, ...
This is a two-way street; rather than using BRBL + PBL + SEMBLACK to
reduce SORBS_DUL, we can reduce BRBL: Removing just PBL from
BRBL_LASTEXT's impressive 91% match of the spam corpus reduces that to
12.7310. Removing the rest of the aforementioned DNSBLs could reduce
that down to as low as 2.3853.
So this brings me right back to my older point: DNSBLs catch the same
culprits even given completely independent spamtrap configurations.
While I've called this "incestuous" in the past, that term leads one
to the wrong conclusion. They're not syndicating each other (and if
they are, either they need to be called out on it or they need to both
have permission and also advertise that fact), they just attract the
same spammers because they use the same methods.
My hypothesis, which I've anecdotally proven on my own deployment, is
that the flaws are repeated as well. Spammers that trigger spamtraps
on multiple DNSBLs (and URIBLs) may be sending from (or linking to)
servers that also deal with legitimate traffic. This means that
thanks to these similar indexing techniques, DNSBL overlap from
spammers' abuse of a non-spam-exclusive server can single-handedly
mark a ham as spam.
My "solution" is to counter-intuitively *remove* points from message
that hit too many DNSBLs. They still net quite a positive score, but
that score is effectively capped at something not quite high enough to
kill a ham with DNSBLs alone.
A more elegant version of this, which Karsten and I theorize might
even happen automatically (as scored by the GA) if I were to check my
adjustor into SVN, would be to reduce most of the points on the DNSBLs
and add them back with a meta rule containing a union of the DNSBL
rules (without a "multiple" tflag).
Re: DNSBL Comparison 20091114
Posted by Justin Mason <jm...@jmason.org>.
> SPAM% HAM% RANK RULE
> 12.8342% 0.0021% 0.94 RCVD_IN_PSBL *
> 12.3053% 0.0026% 0.94 RCVD_IN_XBL
> 31.2499% 0.0827% 0.87 RCVD_IN_ANBREP_BL *2
> 80.2578% 0.1485% 0.86 RCVD_IN_PBL
> 27.1836% 0.1985% 0.79 RCVD_IN_SORBS_DUL
> 19.8213% 0.1785% 0.79 RCVD_IN_SEMBLACK *
> 90.9360% 0.3854% 0.77 RCVD_IN_BRBL_LASTEXT
> 13.0564% 0.4838% 0.67 RCVD_IN_HOSTKARMA_BL *
hi Warren --
any chance you could post the S/O ratios? RANK is a bit "unportable",
as it depends on other rules in the ruleset at the time the
measurement takes place.
--j.