I wonder, why isn't Bitcoins proof-of-work concept used to fight spam? Or at least to make spamming more difficult? People proposed charging small micro-payments for every send email. And this failed, for obvious reasons. Implementing such a payment system is too complex. But implementing the proof-of-work concept would be really easy.
All that needs to be done is include a nonce in the header of every email. When a clients sends an email, it will keep randomly changing the nonce, until the email itself (or just the header, that would be faster) produces a hash that meets certain specifications. This doesn't need to be too difficult. If a normal PC needs a few seconds to do this, it won't be a problem for any normal user, trying to send a legitimate email. But it will become a serious problem for any spammer, trying to send billions of spam-emails. Regardless if they use massive botnets, it will severely reduce the amount of spam the can produce. And if they choose not to calculate a new nonce for every spam-email, it will be easy pickings for the spamfilters.
Open Source email applications, like Thunderbird and Roundcube, could simply start implementing this. And the widely used SpamAssassin could start using it to filter those emails, by giving them a more positive score. I imagine the chicken-and-egg problem would be quickly overcome this way and commercial software would soon follow.
The computing power needed to produce a good nonce, that will give a good hash, is always done on the client-side. I suppose this can also be done with webbased email applications, via ajax? Meaning, it doesn't require huge changes to the current infrastructure. All that needs to be done, is implement it in the software.
This either forces spammers to produce spam with good hashes, which will severely reduce the amount of spam they can produce. And if they don't, it will be more easy to filter them out. There is really not much to lose here.
All that needs to be done is include a nonce in the header of every email. When a clients sends an email, it will keep randomly changing the nonce, until the email itself (or just the header, that would be faster) produces a hash that meets certain specifications. This doesn't need to be too difficult. If a normal PC needs a few seconds to do this, it won't be a problem for any normal user, trying to send a legitimate email. But it will become a serious problem for any spammer, trying to send billions of spam-emails. Regardless if they use massive botnets, it will severely reduce the amount of spam the can produce. And if they choose not to calculate a new nonce for every spam-email, it will be easy pickings for the spamfilters.
Open Source email applications, like Thunderbird and Roundcube, could simply start implementing this. And the widely used SpamAssassin could start using it to filter those emails, by giving them a more positive score. I imagine the chicken-and-egg problem would be quickly overcome this way and commercial software would soon follow.
The computing power needed to produce a good nonce, that will give a good hash, is always done on the client-side. I suppose this can also be done with webbased email applications, via ajax? Meaning, it doesn't require huge changes to the current infrastructure. All that needs to be done, is implement it in the software.
This either forces spammers to produce spam with good hashes, which will severely reduce the amount of spam they can produce. And if they don't, it will be more easy to filter them out. There is really not much to lose here.
). Also, what to do with emails with a zillion TO, CC and BCC headers? If I understand correctly, the email is sent once to the SMTP server, which forwards it to the zillion locations.
