Even though the OP didn’t write their posts or the code or the text on the website, we at least know that some part of the project is original: only a human could come up with a project name so terrible. Speaks to the problem of vibecoding: anyone can generate a bunch of output but still, taste matters.
I was the developer of CamRAM/2pennyblue, so I have a fair bit of knowledge about how SenderPays works with hashcash, why it failed, and what issues any email postage system will have to solve.
The reason we chose hashcash versus a digital currency was that we were trying to eliminate friction points in terms of creating tokens for sending email (i.e., going to the bank for more tokens) and eliminating the possibility of everyone in the message chain holding their hand out, saying, "Pay me too."
The use of hashcash in email clearly had some benefits, including raising the cost of spam, guaranteeing mail delivery to a mailbox, and providing a clear indication of your mail server's reputation. But there were some other faults that were a combination of implementation problems and poor vision of the future, such as:
- The token was embedded in the message.
- There was no mechanism for scaling the cost dynamically.
- Power of two, increasing cost of tokens. I.e., increasing by a single bit doubled the time cost of a token.
- Distribution in time costs of creating tokens.
- T0 problem. How do you get started when nobody else is generating tokens?
- political issues. Ordinary people understood the concept and were willing to pay the cost in time to reduce spam, but technologists were indignant. How dare I spend their CPU cycles on creating a token?
- Vulnerable to botnets generating tokens.
Before I gave up on the project, I had a few fixes, and since then, I've thought of more that I would implement if I were to take on this particular albatross again.
In the ideal Hashcash email system, all messages would have tokens, but you need to get started. The solution was a somewhat messy combination of spam filters and a reputation database. The reputation database was populated with those to whom the server sent messages or whose messages had a valid token. If your email address was in the reputation database, you bypassed the token and spam filter requirements.
Dynamic pricing would have been created through an SMTP protocol extension. EHLO would indicate whether the server supports Hashcash tokens and provide a default token size for the sending server. Mail from: Rcpt to: would tack on an additional field for the token itself. A 250 would indicate that the token had sufficient value. A 3XX/4XX response would tell the sender the size of the token that should have been generated.
The Power of Two problem was solved by someone in the community who proposed creating a chain of tokens. Each individual token was smaller, but in aggregate, it was a large token with finer granularity than the original.
The political problem may have been solved because of Bitcoin. The main difference between Bitcoin and Hashcash postage tokens is that postage tokens do something positive: they deliver a mail message without getting caught by spam filters.
The botnet problem is simultaneously a benefit and a detriment. The attack model was a botnet software that could be used to distribute the load of generating Hashcash tokens across multiple infected machines. The attack was validated today in cryptocurrency miners as part of malware. At the same time, the botnet problem is how an organization could generate tokens for all the emails passing through its servers. Let the server distribute the token-generation load across all the desktops in your office.
As I envision it, such a system would start out generating lots and lots of hashcash tokens, but eventually, between remembering who you sent mail to and dynamic pricing, most people would not need to generate very large tokens, and spammers would be fully burdened.
