Re: RCVD_IN_XBL score

>
> On Mar 11, 2012, at 10:21 AM, Axb wrote:
>
>> On 03/11/2012 04:02 PM, darxus@... 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.