Jim C. Nasby wrote: > On Wed, Feb 08, 2006 at 11:49:09AM -0500, Matt Kettler wrote: >> Jim C. Nasby wrote: >>> On Wed, Feb 08, 2006 at 11:29:36AM -0500, Matt Kettler wrote: >>>> However, looking in the config files, HASHCASH rules have the userconf >>>> flag. >>>> This means that the Autolearner will also ignore these rules too, as SA >>>> will >>>> treat it as a user configured whitelist. >>>> >>>> >>>> So, this message had an autolearner score of +0.135 from the >>>> FORGED_RCVD_HELO. >>> Ahh, so hashcash scores don't actually count towards learning. Should >>> maybe be changed...? >> I'm not entirely sure.. Part of me thinks it's a good idea to not count it, >> since it does effectively behave a bit like a user-configured whitelist. >> >> I mean, if you start accepting hashcash for learning, then you probably >> should >> also accept whitelist_from_spf. >> >> Realistically, hashcash doesn't provide any proof the sender isn't a >> spammer. It >> merely provides proof they are willing to burn some CPU time to send you an >> email. > > Sure, but I think it warrants a small negative learn score.
Does it? A negative learning score is a VERY powerful thing. VERY powerful. Someone who can forge a negative learning score can poison your bayes database rather quickly. Currently SA only accepts negative learning scores for things which actually attest to the fact that this specific sender is not a spammer. SA doesn't even trust the user's own whitelists for this purpose, because too many users do whitelist_from * >> In the era of spammers using enormous botnets a little CPU time really costs >> a >> spammer very little. They're much more limited by network bandwidth than >> available CPU power when they control 10,000+ infected PCs each with a >> cable/dsl >> uplink speed of 128k-1mbit to send spam with. > > True, but if they start burning that kind of CPU generating postage the > owner of the machine is more likely to notice something's wrong... Surely you're joking. The average user would only notice if their computer became sluggish and unresponsive. If you do the hashes in a low-priority thread the user interface responsiveness will never be affected. Take the distributed.net client as an example. It burns tons of CPU, and the average user wouldn't realize it was there. Sure the user could detect it with a processor usage monitor. However, if they were clueful enough to detect CPU load by using the task manager, they'd be clueful enough to avoid infection in the first place, or at least realize they'd infected themselves and clean it up asap. Remember, the bot nets are largely built from users who are infected by email viruses. Thus for the most part we are dealing with users that will open a .pif file attached to an email with a body saying nothing but "Please read the document." and a subject "Re: document" (a netsky/somefool variant)
