Hashcash is a nice idea – it's a “proof of work” system where the sender demonstrates that they've spend some amount of CPU time as part of the mail delivery. Basically, paying for e-mail delivery through the use of CPU cycles. As a sender, you use a timestamp and the recipient address, combined with a string which when hashed produces a hash with at least a certain number of leading 0 bits. The idea being that you try a bunch of strings until you find one that has more than your threshold of zero bits. The problem is few people use Hashcash.
I haven't checked recently, but 4 to 6 months ago when I first started using Hashcash I found that I had received exactly 1 message that used Hashcash over the previous several months worth of mail logs. I did decide to set up our mail server to use Hashcash because it was fairly easy, but didn't expect much good to come of it yet.
Today in preparing for a presentation tomorrow on e-mail spam prevention, I found that SpamAssassin includes checks for Hashcash, and based on the number of 0 bits it can give a pretty significant benefit to incoming e-mail messages. I was running 20 bits (the default) because many more bits was delaying our outgoing e-mail for what I thought was little benefit. Then I found that SpamAssassin gives a fairly minimal benefit to 20 bits, but gives 5 points to messages with a Hashcash of 26 bits or more.
So, I've pushed our mail server back up to generating a 26-bit Hashcash, which takes around 25 seconds per message on our 2.66GHz P4 mail server. If SpamAssassin implements it, that's a huge benefit because of it's penetration.comments powered by Disqus