« Return to Thread: RCVD_IN_XBL score
Re: RCVD_IN_XBL score
by Axb
::
Rate this Message:
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.
> 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.
« Return to Thread: RCVD_IN_XBL score
| Free embeddable forum powered by Nabble | Forum Help |
