[phire]

As in, each email requires a bruteforced hash that takes about half a second to calculate on a desktop CPU, before it will be accepted by the mail server?

That's actually the best idea for spam reduction I've heard so far (which is not really saying a lot). Half a second won't be noticed by a normal user, but it will be noticed by people sending thousands or millions of emails.

Sure Spammer will install large GPUs hashing rigs and still manage to send thousands of emails per second, but it would cost them a lot more than it does now.

One problem will be phones, a hash that takes about half a second on a desktop will take tens of seconds on lower end mobile phones, which is hardly unworkable but you could offload the calculations to a 3rd party server (with a large GPU based hashing rig) for say a fraction of a cent, especially if the email contents were encrypted by the phone before hashing.

And it could be introduced without breaking the email system. Initially the presence of a hash will just be used as an additional spam filtering signal, but as support grows over time you can make it harder and harder for emails without a hash to get through.

Like bitcoins, you would need a mechanism to increase the required work over time, though it could just be ad-hoc based on what mail server operators choose to accept.

[drblue]

You may want to take a look at hashcash[1]. It was a proof of work scheme for email invented in the late 90s, and they claim it was adopted by bitcoin[2]. (Sadly, it never caught on for its 'intended' purpose.)

[1]: http://www.hashcash.org/ [2]: http://www.hashcash.org/bitcoin/

[Sanddancer]

The problem I can see there is with legitimate large mailing lists. Think security announcements, etc. Putting a burden like that on smaller teams, or teams without a lot of funding, could prove problematic.

[phire]

You could deal with large regular mailing lists, you want to move to a system where users can subscribe to a signed mailing list and have the mail server remember that subscription. But yeah, irregular mailing lists where you suddenly need to tell your million users that your database has been breached and they need to change their passwords will be an issue.

But we are talking about $0.0005 (0.05 cents) worth of hashing on CPU systems per email. With GPU based hashing it should be 50 times cheaper. If your team has 1 million customers, and can't afford the $10 to pay a GPU based hashing service to hash 1 million emails for you, you might have a bigger problem.

I suspect the biggest issue for such a scheme is $10 for 1 million emails is potentially still profitable for spammers while being at the limit of how much cpu time you can expect to waste for regular (particularly mobile) users. And that's before you consider the possibility of ASIC hashing for emails.