On Mar 11, 2012, at 10:21 AM, Axb wrote: > 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. > >
Sorry, but your thinking is wrong. What Darxus says is completely correct. Michael
