On 03/11/2012 04:02 PM, [email protected] 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.
