You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by Axb <ax...@gmail.com> on 2012/03/11 00:19:51 UTC
RCVD_IN_XBL score
Guys,
At the moment, after last sa-update:
score RCVD_IN_XBL 0 0.724 0 0.375 # n=0 n=2
is amazingly low.
last net masscheck shows
0 43.3599 0.0133 1.000 0.97 0.00 RCVD_IN_XBL
(http://ruleqa.spamassassin.org/20120310-r1299162-n/RCVD_IN_XBL/detail)
(darxus & llanga corpus poisoned?)
as the second best ranking rule, shouldn't this this score be raised
quite a bit, to at least 1.7?
Also:
score RCVD_IN_SBL 0 2.596 0 0.141 # n=0 n=2
with a ranking of 0.85
Cannot imagine what HAM is hitting SBL unless its IPs listed due to 419s
or llanga & darxus' corpus have snowshow in their ham corpus
(See http://ruleqa.spamassassin.org/20120310-r1299162-n/RCVD_IN_SBL/detail)
Imo, this should also be scored at 1.7 as they are both of similar
quality with DBL.
Comments?
Axb
Re: RCVD_IN_XBL score
Posted by Henrik Krohns <he...@hege.li>.
On Sun, Mar 11, 2012 at 10:05:16PM +0200, Henrik Krohns wrote:
> SA needs profiles like "mta-blocking used" and "no mta-blocking used"..
Not to mention "heavy whitelisting used" etc.. all these things have large
effect. Who knows what the "average" profile should be defined as.
Re: RCVD_IN_XBL score
Posted by Henrik Krohns <he...@hege.li>.
On Sun, Mar 11, 2012 at 03:44:45PM -0400, darxus@chaosreigns.com wrote:
>
> I do not disagree with this. I think increasing the score of the
> spamhause rules would be fine. The only reason I stopped automatically
> rejecting everything in zen at my MTA was to collect better data for
> things like masscheck. Funny, huh? I wonder how many more false
> positives aren't showing up in masscheck / rule QA / score generation
> because the contributor never sees them due to using zen at their MTA.
>
> Rule QA output certainly suggests we're missing that data for that reason
> in several of the corpora.
You are right that mass checker setups may vary wildly. I sure know my old
corpus was heavily biased since MTA checks were very strict. Mostly my spam
was hard-to-catch freemail crap which raised freemail-rule scores
considerably. This is why I don't bother to participate anymore. SA needs
profiles like "mta-blocking used" and "no mta-blocking used"..
While interessting, I couldn't care less if zen had "more FPs" than mass
checks show. It's still used pretty much everywhere (if you are listed, you
are screwed) and the FP rate is too small to care (I never saw FPs on my
50k/day traffic).
Re: RCVD_IN_XBL score
Posted by Axb <ax...@gmail.com>.
On 03/11/2012 06:10 PM, Henrik Krohns wrote:
> On Sun, Mar 11, 2012 at 05:09:05PM +0100, Axb wrote:
>> On 03/11/2012 04:50 PM, Michael Parker wrote:
>>>
>>> On Mar 11, 2012, at 10:21 AM, Axb wrote:
>>>
>>>> On 03/11/2012 04:02 PM, darxus@chaosreigns.com wrote:
>>>>> On 03/11, Axb wrote:
>>>>>>> There are a number of reasons for the score generator to come up with this
>>>>>>> result.
>>>>>>
>>>>>> agreed, and that doesn't mean it's 100% accurate.
>>>>>
>>>>> Yep. Well, I'd use "ideal" instead of "accurate". But I fear fully
>>>>> comprehending the mind of the re-scorer.
>>>>>
>>>>>> Could you please check if any of those IPs are still listed ?
>>>>>> (especially XBL)
>>>>>>
>>>>>> If they aren't, then it's "reuse" which is causing the issue.
>>>>>
>>>>> If any of the IPs are not still listed, then reuse is doing exactly
>>>>> its job, providing us with the accuracy of the lists at the time email
>>>>> is received. I'm not interested in their accuracy after they've had
>>>>> ample opportunity to correct bad listings, which is not the accuracy
>>>>> anybody actually gets from spamassassin.
>>>>
>>>> yeah right - re-using stale data - sorry, I can't agree.
>>>>
>>>> XBL doesn't "correct" its listings.
>>>> If anybody does any correction, then it's the exploited/abused host's owner who's taken action and cleaned up/delisted
>>>>
>>>> If your windows box was exploited and listed in CBL for a day, and you submit a delisting request after you fixed , the listing will disappear within a couple of hours, the CBL/XBL worked as intended and that incident could be recorded in someone's corpus for a long time tho the incident has long been resolved and this would negatively influence the BL's score.
>>>>
>>>> Pretty obviously wrong.
>>>>
>>>>>> reuse RCVD_IN_XBL
>>>>>> reuse RCVD_IN_SBL
>>>>>>
>>>>>> Unless we want to trust stale data, I think this should be removed
>>>>>> for a number of BLs which have short lived listings.
>>>>>
>>>>> I object strongly.
>>>>
>>>> Then you don't understand how CBL/XBL works and how this method and low score is breaking its strength in tagging exploited sender IPs.
>>>> As we may use XBL to reject mail, the score should be accordingly high for those who chose NOT to reject yet want to get the full advantage of XBL's accuracy.
>>>>
>>>>> Although I still think it would be lovely to reduce the maximum age of
>>>>> emails used in re-scoring to something lower than 6 *years* for ham:
>>>>> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6386
>>>>> But that would require significantly more masscheck contributors, which
>>>>> would require allowing more masscheck contributors:
>>>>> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6694 (security
>>>>> problem not visible to everybody, possibly invalid, needs input from
>>>>> Warren)
>>>>
>>>> Anybody using HAM older than 3 years should voluntarily cleanup.
>>>> Patterns change and as with spam, HAM also goes stale.
>>>>
>>>>
>>>
>>> Sorry, but your thinking is wrong. What Darxus says is completely correct.
>>
>> How can be it be right to reuse BL hits which have probably expired
>> along time ago?
>>
>> To me this is like saying your credit rating at age 40 is bad coz
>> you had a $5k debt at age 20
>>
>> Don't understand your logic.
>
> I have to agree with Axb here.
>
> If we are talking about _Spamhaus_ which most people have rejecting at SMTP
> time anyway, the current XBL/SBL scores are ridiculously low.
>
> A few lame livejournal/forum mails are allowed to make one of the most
> respected lists to be less effective?
.......and why did these forum IPs land in XBL in the firts place?
What exploit hit them?
May we have these IPs so we can research their history?
Re: RCVD_IN_XBL score
Posted by Henrik Krohns <he...@hege.li>.
On Sun, Mar 11, 2012 at 05:09:05PM +0100, Axb wrote:
> On 03/11/2012 04:50 PM, Michael Parker wrote:
> >
> >On Mar 11, 2012, at 10:21 AM, Axb wrote:
> >
> >>On 03/11/2012 04:02 PM, darxus@chaosreigns.com wrote:
> >>>On 03/11, Axb wrote:
> >>>>>There are a number of reasons for the score generator to come up with this
> >>>>>result.
> >>>>
> >>>>agreed, and that doesn't mean it's 100% accurate.
> >>>
> >>>Yep. Well, I'd use "ideal" instead of "accurate". But I fear fully
> >>>comprehending the mind of the re-scorer.
> >>>
> >>>>Could you please check if any of those IPs are still listed ?
> >>>>(especially XBL)
> >>>>
> >>>>If they aren't, then it's "reuse" which is causing the issue.
> >>>
> >>>If any of the IPs are not still listed, then reuse is doing exactly
> >>>its job, providing us with the accuracy of the lists at the time email
> >>>is received. I'm not interested in their accuracy after they've had
> >>>ample opportunity to correct bad listings, which is not the accuracy
> >>>anybody actually gets from spamassassin.
> >>
> >>yeah right - re-using stale data - sorry, I can't agree.
> >>
> >>XBL doesn't "correct" its listings.
> >>If anybody does any correction, then it's the exploited/abused host's owner who's taken action and cleaned up/delisted
> >>
> >>If your windows box was exploited and listed in CBL for a day, and you submit a delisting request after you fixed , the listing will disappear within a couple of hours, the CBL/XBL worked as intended and that incident could be recorded in someone's corpus for a long time tho the incident has long been resolved and this would negatively influence the BL's score.
> >>
> >>Pretty obviously wrong.
> >>
> >>>>reuse RCVD_IN_XBL
> >>>>reuse RCVD_IN_SBL
> >>>>
> >>>>Unless we want to trust stale data, I think this should be removed
> >>>>for a number of BLs which have short lived listings.
> >>>
> >>>I object strongly.
> >>
> >>Then you don't understand how CBL/XBL works and how this method and low score is breaking its strength in tagging exploited sender IPs.
> >>As we may use XBL to reject mail, the score should be accordingly high for those who chose NOT to reject yet want to get the full advantage of XBL's accuracy.
> >>
> >>>Although I still think it would be lovely to reduce the maximum age of
> >>>emails used in re-scoring to something lower than 6 *years* for ham:
> >>>https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6386
> >>>But that would require significantly more masscheck contributors, which
> >>>would require allowing more masscheck contributors:
> >>>https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6694 (security
> >>>problem not visible to everybody, possibly invalid, needs input from
> >>>Warren)
> >>
> >>Anybody using HAM older than 3 years should voluntarily cleanup.
> >>Patterns change and as with spam, HAM also goes stale.
> >>
> >>
> >
> >Sorry, but your thinking is wrong. What Darxus says is completely correct.
>
> How can be it be right to reuse BL hits which have probably expired
> along time ago?
>
> To me this is like saying your credit rating at age 40 is bad coz
> you had a $5k debt at age 20
>
> Don't understand your logic.
I have to agree with Axb here.
If we are talking about _Spamhaus_ which most people have rejecting at SMTP
time anyway, the current XBL/SBL scores are ridiculously low.
A few lame livejournal/forum mails are allowed to make one of the most
respected lists to be less effective?
Re: RCVD_IN_XBL score
Posted by John Hardin <jh...@impsec.org>.
On Sun, 11 Mar 2012, Axb wrote:
> How can be it be right to reuse BL hits which have probably expired along
> time ago?
>
> To me this is like saying your credit rating at age 40 is bad coz you had a
> $5k debt at age 20
>
> Don't understand your logic.
It makes some sense if you're considering URIBLs, where you'd like to know
the score at the time the message was processed (before they were listed
in the URIBL) rather than now (after they were listed in the URIBL).
(Just explaining, not agreeing.)
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Failure to plan ahead on someone else's part does not constitute
an emergency on my part. -- David W. Barts in a.s.r
-----------------------------------------------------------------------
Today: Daylight Saving Time begins in U.S. - Spring Forward
Re: RCVD_IN_XBL score
Posted by Axb <ax...@gmail.com>.
On 03/11/2012 04:50 PM, Michael Parker wrote:
>
> On Mar 11, 2012, at 10:21 AM, Axb wrote:
>
>> On 03/11/2012 04:02 PM, darxus@chaosreigns.com wrote:
>>> On 03/11, Axb wrote:
>>>>> There are a number of reasons for the score generator to come up with this
>>>>> result.
>>>>
>>>> agreed, and that doesn't mean it's 100% accurate.
>>>
>>> Yep. Well, I'd use "ideal" instead of "accurate". But I fear fully
>>> comprehending the mind of the re-scorer.
>>>
>>>> Could you please check if any of those IPs are still listed ?
>>>> (especially XBL)
>>>>
>>>> If they aren't, then it's "reuse" which is causing the issue.
>>>
>>> If any of the IPs are not still listed, then reuse is doing exactly
>>> its job, providing us with the accuracy of the lists at the time email
>>> is received. I'm not interested in their accuracy after they've had
>>> ample opportunity to correct bad listings, which is not the accuracy
>>> anybody actually gets from spamassassin.
>>
>> yeah right - re-using stale data - sorry, I can't agree.
>>
>> XBL doesn't "correct" its listings.
>> If anybody does any correction, then it's the exploited/abused host's owner who's taken action and cleaned up/delisted
>>
>> If your windows box was exploited and listed in CBL for a day, and you submit a delisting request after you fixed , the listing will disappear within a couple of hours, the CBL/XBL worked as intended and that incident could be recorded in someone's corpus for a long time tho the incident has long been resolved and this would negatively influence the BL's score.
>>
>> Pretty obviously wrong.
>>
>>>> reuse RCVD_IN_XBL
>>>> reuse RCVD_IN_SBL
>>>>
>>>> Unless we want to trust stale data, I think this should be removed
>>>> for a number of BLs which have short lived listings.
>>>
>>> I object strongly.
>>
>> Then you don't understand how CBL/XBL works and how this method and low score is breaking its strength in tagging exploited sender IPs.
>> As we may use XBL to reject mail, the score should be accordingly high for those who chose NOT to reject yet want to get the full advantage of XBL's accuracy.
>>
>>> Although I still think it would be lovely to reduce the maximum age of
>>> emails used in re-scoring to something lower than 6 *years* for ham:
>>> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6386
>>> But that would require significantly more masscheck contributors, which
>>> would require allowing more masscheck contributors:
>>> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6694 (security
>>> problem not visible to everybody, possibly invalid, needs input from
>>> Warren)
>>
>> Anybody using HAM older than 3 years should voluntarily cleanup.
>> Patterns change and as with spam, HAM also goes stale.
>>
>>
>
> Sorry, but your thinking is wrong. What Darxus says is completely correct.
How can be it be right to reuse BL hits which have probably expired
along time ago?
To me this is like saying your credit rating at age 40 is bad coz you
had a $5k debt at age 20
Don't understand your logic.
Re: RCVD_IN_XBL score
Posted by Michael Parker <pa...@pobox.com>.
On Mar 11, 2012, at 10:21 AM, Axb wrote:
> On 03/11/2012 04:02 PM, darxus@chaosreigns.com wrote:
>> On 03/11, Axb wrote:
>>>> There are a number of reasons for the score generator to come up with this
>>>> result.
>>>
>>> agreed, and that doesn't mean it's 100% accurate.
>>
>> Yep. Well, I'd use "ideal" instead of "accurate". But I fear fully
>> comprehending the mind of the re-scorer.
>>
>>> Could you please check if any of those IPs are still listed ?
>>> (especially XBL)
>>>
>>> If they aren't, then it's "reuse" which is causing the issue.
>>
>> If any of the IPs are not still listed, then reuse is doing exactly
>> its job, providing us with the accuracy of the lists at the time email
>> is received. I'm not interested in their accuracy after they've had
>> ample opportunity to correct bad listings, which is not the accuracy
>> anybody actually gets from spamassassin.
>
> yeah right - re-using stale data - sorry, I can't agree.
>
> XBL doesn't "correct" its listings.
> If anybody does any correction, then it's the exploited/abused host's owner who's taken action and cleaned up/delisted
>
> If your windows box was exploited and listed in CBL for a day, and you submit a delisting request after you fixed , the listing will disappear within a couple of hours, the CBL/XBL worked as intended and that incident could be recorded in someone's corpus for a long time tho the incident has long been resolved and this would negatively influence the BL's score.
>
> Pretty obviously wrong.
>
>>> reuse RCVD_IN_XBL
>>> reuse RCVD_IN_SBL
>>>
>>> Unless we want to trust stale data, I think this should be removed
>>> for a number of BLs which have short lived listings.
>>
>> I object strongly.
>
> Then you don't understand how CBL/XBL works and how this method and low score is breaking its strength in tagging exploited sender IPs.
> As we may use XBL to reject mail, the score should be accordingly high for those who chose NOT to reject yet want to get the full advantage of XBL's accuracy.
>
>> Although I still think it would be lovely to reduce the maximum age of
>> emails used in re-scoring to something lower than 6 *years* for ham:
>> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6386
>> But that would require significantly more masscheck contributors, which
>> would require allowing more masscheck contributors:
>> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6694 (security
>> problem not visible to everybody, possibly invalid, needs input from
>> Warren)
>
> Anybody using HAM older than 3 years should voluntarily cleanup.
> Patterns change and as with spam, HAM also goes stale.
>
>
Sorry, but your thinking is wrong. What Darxus says is completely correct.
Michael
Re: RCVD_IN_XBL score
Posted by Axb <ax...@gmail.com>.
On 03/11/2012 04:02 PM, darxus@chaosreigns.com wrote:
> On 03/11, Axb wrote:
>>> There are a number of reasons for the score generator to come up with this
>>> result.
>>
>> agreed, and that doesn't mean it's 100% accurate.
>
> Yep. Well, I'd use "ideal" instead of "accurate". But I fear fully
> comprehending the mind of the re-scorer.
>
>> Could you please check if any of those IPs are still listed ?
>> (especially XBL)
>>
>> If they aren't, then it's "reuse" which is causing the issue.
>
> If any of the IPs are not still listed, then reuse is doing exactly
> its job, providing us with the accuracy of the lists at the time email
> is received. I'm not interested in their accuracy after they've had
> ample opportunity to correct bad listings, which is not the accuracy
> anybody actually gets from spamassassin.
yeah right - re-using stale data - sorry, I can't agree.
XBL doesn't "correct" its listings.
If anybody does any correction, then it's the exploited/abused host's
owner who's taken action and cleaned up/delisted
If your windows box was exploited and listed in CBL for a day, and you
submit a delisting request after you fixed , the listing will disappear
within a couple of hours, the CBL/XBL worked as intended and that
incident could be recorded in someone's corpus for a long time tho the
incident has long been resolved and this would negatively influence the
BL's score.
Pretty obviously wrong.
>> reuse RCVD_IN_XBL
>> reuse RCVD_IN_SBL
>>
>> Unless we want to trust stale data, I think this should be removed
>> for a number of BLs which have short lived listings.
>
> I object strongly.
Then you don't understand how CBL/XBL works and how this method and low
score is breaking its strength in tagging exploited sender IPs.
As we may use XBL to reject mail, the score should be accordingly high
for those who chose NOT to reject yet want to get the full advantage of
XBL's accuracy.
> Although I still think it would be lovely to reduce the maximum age of
> emails used in re-scoring to something lower than 6 *years* for ham:
> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6386
> But that would require significantly more masscheck contributors, which
> would require allowing more masscheck contributors:
> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6694 (security
> problem not visible to everybody, possibly invalid, needs input from
> Warren)
Anybody using HAM older than 3 years should voluntarily cleanup.
Patterns change and as with spam, HAM also goes stale.
Re: RCVD_IN_XBL score
Posted by da...@chaosreigns.com.
On 03/11, Axb wrote:
> >There are a number of reasons for the score generator to come up with this
> >result.
>
> agreed, and that doesn't mean it's 100% accurate.
Yep. Well, I'd use "ideal" instead of "accurate". But I fear fully
comprehending the mind of the re-scorer.
> Could you please check if any of those IPs are still listed ?
> (especially XBL)
>
> If they aren't, then it's "reuse" which is causing the issue.
If any of the IPs are not still listed, then reuse is doing exactly
its job, providing us with the accuracy of the lists at the time email
is received. I'm not interested in their accuracy after they've had
ample opportunity to correct bad listings, which is not the accuracy
anybody actually gets from spamassassin.
> reuse RCVD_IN_XBL
> reuse RCVD_IN_SBL
>
> Unless we want to trust stale data, I think this should be removed
> for a number of BLs which have short lived listings.
I object strongly.
Although I still think it would be lovely to reduce the maximum age of
emails used in re-scoring to something lower than 6 *years* for ham:
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6386
But that would require significantly more masscheck contributors, which
would require allowing more masscheck contributors:
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6694 (security
problem not visible to everybody, possibly invalid, needs input from
Warren)
--
"Democracy is the theory that the common people know what they want,
and deserve to get it good and hard." - H. L. Mencken
http://www.ChaosReigns.com
Re: RCVD_IN_XBL score
Posted by Axb <ax...@gmail.com>.
On 03/11/2012 06:47 AM, darxus@chaosreigns.com wrote:
> On 03/11, Axb wrote:
>>
>> Guys,
>>
>> At the moment, after last sa-update:
>>
>> score RCVD_IN_XBL 0 0.724 0 0.375 # n=0 n=2
>>
>> is amazingly low.
>>
>> last net masscheck shows
>> 0 43.3599 0.0133 1.000 0.97 0.00 RCVD_IN_XBL
>> (http://ruleqa.spamassassin.org/20120310-r1299162-n/RCVD_IN_XBL/detail)
>> (darxus& llanga corpus poisoned?)
>
> One of my two is a notification from livejournal.com that my girlfriend
> posted to her lj. The other is a post to a yahoo group for a local goth
> club night, to which I have been subscribed for a while.
>
>> as the second best ranking rule, shouldn't this this score be raised
>> quite a bit, to at least 1.7?
>
> There are a number of reasons for the score generator to come up with this
> result.
agreed, and that doesn't mean it's 100% accurate.
>
>> score RCVD_IN_SBL 0 2.596 0 0.141 # n=0 n=2
>> with a ranking of 0.85
>>
>> Cannot imagine what HAM is hitting SBL unless its IPs listed due to
>> 419s or llanga& darxus' corpus have snowshow in their ham corpus
>>
>> (See http://ruleqa.spamassassin.org/20120310-r1299162-n/RCVD_IN_SBL/detail)
>
> I have 29 hams that hit this. In reverse chronological order:
>
> Looks like 18 are livejournal.com. 11 are notifications that there were
> updates to the thread
> http://www.diyelectriccar.com/forums/showthread.php?t=53001 which I had
> subscribed to.
>
> So, all of my hams hitting both of these rules are legit hams, where the
> blacklists had false positives. I am very confident that none of them were
> just exquisitely faked.
Could you please check if any of those IPs are still listed ?
(especially XBL)
If they aren't, then it's "reuse" which is causing the issue.
reuse RCVD_IN_XBL
reuse RCVD_IN_SBL
Unless we want to trust stale data, I think this should be removed for a
number of BLs which have short lived listings.
Axb
Re: RCVD_IN_XBL score
Posted by da...@chaosreigns.com.
On 03/11, Axb wrote:
>
> Guys,
>
> At the moment, after last sa-update:
>
> score RCVD_IN_XBL 0 0.724 0 0.375 # n=0 n=2
>
> is amazingly low.
>
> last net masscheck shows
> 0 43.3599 0.0133 1.000 0.97 0.00 RCVD_IN_XBL
> (http://ruleqa.spamassassin.org/20120310-r1299162-n/RCVD_IN_XBL/detail)
> (darxus & llanga corpus poisoned?)
One of my two is a notification from livejournal.com that my girlfriend
posted to her lj. The other is a post to a yahoo group for a local goth
club night, to which I have been subscribed for a while.
> as the second best ranking rule, shouldn't this this score be raised
> quite a bit, to at least 1.7?
There are a number of reasons for the score generator to come up with this
result.
> score RCVD_IN_SBL 0 2.596 0 0.141 # n=0 n=2
> with a ranking of 0.85
>
> Cannot imagine what HAM is hitting SBL unless its IPs listed due to
> 419s or llanga & darxus' corpus have snowshow in their ham corpus
>
> (See http://ruleqa.spamassassin.org/20120310-r1299162-n/RCVD_IN_SBL/detail)
I have 29 hams that hit this. In reverse chronological order:
Looks like 18 are livejournal.com. 11 are notifications that there were
updates to the thread
http://www.diyelectriccar.com/forums/showthread.php?t=53001 which I had
subscribed to.
So, all of my hams hitting both of these rules are legit hams, where the
blacklists had false positives. I am very confident that none of them were
just exquisitely faked.
--
"Force, my friends, is violence; the supreme authority
from which all other authority is derived."
- Michael Ironside, Starship Troopers
http://www.ChaosReigns.com