5 ms·
I was thinking about this a while ago and have been meaning to write it up and post it somewhere, so I guess this is as good a time as any. Hashcash (also know
by zrm 11y ago
I was thinking about this a while ago and have been meaning to write it up and post it somewhere, so I guess this is as good a time as any.
Hashcash (also known as the precursor to Bitcoin) was proposed to solve this problem in 1997:
https://en.wikipedia.org/wiki/Hashcash https://en.wikipedia.org/wiki/Hashcash
The trouble with it is that it requires computation for each sent message, which is bad for senders with low resource devices or legitimate mailing lists. I want to propose a variant.
Instead of creating an expensive hash against the message, create an even more expensive hash against the (sender TLS certificate, receiver domain name) pair. This implies using TLS but it works just as well even if the certificate is self-signed. Then each mail server only has to generate a hash once per recipient domain, ever. Every message that mail server sends to that domain is tagged with that hash. A legitimate mail server will have already computed hashes for all the domains its users regularly correspond with and rarely if ever need to do any more expensive computations.
If spammers do the same thing then the receiving server can mark all messages sent with that hash as spam. So there is a highly disproportionate cost to spammers (even if they have more computing power) because to avoid that they have to continuously generate expensive new hashes. Which can be made arbitrarily expensive because legitimate servers only need to do it once. And a new hash is much less valuable to a spammer than a domain name or IP address is today because each hash can only be used against one recipient domain. The required amount of computation can be set by the receiving server so domains with more users can require more computation.
If a legitimate mail server is compromised by a spammer then it will have to generate all new hashes (because the spammer will presumably immediately ruin the reputation of the compromised ones), but the reputation of the legitimate sender's email domains is unharmed because the reputation is tied to the hash computation, not the sender's domain name(s).
And adding support to mail servers would require no configuration whatsoever. You install server version N+1 and it starts tagging outgoing messages with hashes that receiving servers can verify.
So here's the traditional form: http://craphound.com/spamsolutions.txt http://craphound.com/spamsolutions.txt
How'd I do?
- tromp 11y agoSounds like a plan! With a memory-bound proof-of-work system like my Cuckoo Cycle, computing the hash could require the use of more than 4GB of memory for over 5 minutes on a 20-thread server, thus preventing the use of botnets for avoiding the expense.
- chmike 11y agoNot sure Internet providers or google will be enthusiast about this proposal. This is equivalent as asking to pay to register a new destination address. In this case the mail relay owner has to pay. It would be more fair to ask users who send mail to pay to register a new destination address. Google and mail relay provider would be more happy with this variant.
- zrm 11y agoIt's very friendly to large providers. The amount of computation needed to send to a domain is the same regardless of how many emails you send so large providers can amortize it over more emails. And large providers generally operate their own infrastructure, which implies they already have a lot of idle computing capacity during off peak hours, and "off peak" is staggered across regions. But even if some large providers refuse to hash outgoing mail, they can still verify incoming mail. The interesting benefit is that a small email provider can burn some dollars in computation once to avoid having their mail discarded by a large provider's spam filter indefinitely.