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. 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. > > BTW, I was reading http://article.gmane.org/gmane.mail.spam.hashcash/803 > last night, and I'm wondering if there's been any progress on a way to > enable hashcash without requiring users to supply emails they receive > stamps for? The hashcash_accept command accepts file-glob style wildcards, so this should work: hashcash_accept * or safer: hashcash_accept [EMAIL PROTECTED] The problem with wildcards is that a spammer doesn't need to compute a hash on a per-recipient basis. They merely need to do it on a per-message basis, which makes it much less expensive for a spammer to use.
