Hacker News Reader

As noted by other people, your idea, especially in its final version, has already been proposed.

The basic problem with the proposal is that it fundamentally misunderstands how the economics of spam works. Especially when it comes to the idea of using proof-of-CPU time to generate the cost to send mail. Spam generally comes from compromised machines, so the people who would actually be paying the cost of sending mail are not the spammers, but those who own the compromised systems. In effect, you'd be making everyone but the spammers pay for their email. (And the idea of being able to pay extra to get higher priority is going to be a godsend to spammers--historically, spammers were the most eager to implement anti-spam technologies such as SPF because of the boost it gives the spam.)

The parent comment isn't talking about proof of work it's talking about actual payment. In practice payment system are much more rarely compromised (or at least it doesn't last long) and if you could compromise someone's payment system you'd not bother sending spam, you'd just take the money and run.

>The parent comment isn't talking about proof of work it's talking about actual payment.

I think he was replying to this that the gp wrote: "The best part of this system is that it really does not require actual money [...] , he could just _mine_ the coins he uses to send the mail with."

Indeed I somehow missed that last paragraph >_<

I did notice that bit, and it seemed bizarre and sort-of irrelevant to his point.

  > using proof-of-CPU time to generate the cost to send mail. Spam generally
  > comes from compromised machines

I see, thank you. You are correct, but it would greatly reduce the quantity of spam. Additionally, such compromised machines should now become (how to word this) more-unusable :) which may accelerate incentive to resolve the issue.

You've gone full circle and reinvented HashCash, the algorithmic predecessor to Bitcoin :)

http://hashcash.org/

Interesting, thank you.

Maybe new-email could be linked to a cryptocurrency?

In case readers aren't aware because the comment doesn't say, the Bitcoin proof of work algorithm was invented by the designers of Hash Cash as an e-mail anti-spam measure, more than a decade before anyone ever thought to use it for currency. They're effectively the e equivalent of postage stamps, with prices that dynamically adjust to whatever level is needed to deter spammers. Just as with stamps, someone eventually realized they could be traded for more than face value, and like with limited-edition collector's stamps, someone eventually realized you could make "non-fungible" versions and try to trade them for even more than face value.

Please read https://craphound.com/spamsolutions.txt and check all boxes that apply to your post yourself. Ideas such as yours have been around since the mid-1990’s and have been debated to death since then, so much so that the aforementioned template was created.

That template essentially shot down any discussion of fixing email in the open source space, and so companies like Slack, Google and MSFT were able to create walled gardens that can only be interacted with by their systems or by email senders they consider secure enough.

If, instead of creating that template, somebody had made Thunderbird send PoW headers and priotize those that had it, maybe we would have been in a freer world.

And yet, nobody who could have made that change in Thunderbird thought it would be a good idea to do that. This is how ideas are evaluated and either adopted or rejected.

Yea, there's about 0% chance that PoW would fix anything. Much like how bitcoin miners run in javascripts these days, victims would have born the brunt of the computing expense.

Does everything need to devolve into sudoku-solving coins that the makers can try to profit off of?

If we’re building all this tech for coins or digital stamps, it seems like the existing system could work fine by rolling per-contact email addresses to give out. Traceability without having to kill any polar bears. Apple is already offering this through their Apple Sign-In

For what it's worth I have never used any of the cryptocurrencies. It just seemed to me that this is a viable solution to a difficult problem - a way to associate a cost with a behaviour that we'd like to limit, in a way that does not prevent the poor, disadvantaged, or those who wish to remain anonymous from participating.

> in a way that does not prevent the poor, disadvantaged,

Yeah mining coins totally doesn't exclude poor people. If it costs less than the profit spammers make they will use it. You can't just handwave the thresold away, and pretend you are solving the problem by just asking for money(thereby excluding large swaths of people). Just use your iMessage.

This is probably the worst part about any kind of payment based system, whether it be money or proof of work- these systems do reflect the disadvantages of the economies of the world.

That said, since this problem already exists in the world, it is often overstated.

If a stamp is a reasonable cost, and only a one time cost, it will be largely invisible. 25 cents (a price set by the recipient) to send a message from a stranger won't have a big impact on most people, and it's important to recognize it's only the first time.

It's further important to know it would even be possible to refund the cost of the stamp back to the sender once the message is sent. The recipient could have a button that says "Return stamp" which would then let the sender re-use or in some other way organize the stamp.

Now let's contrast to today... Let's say I want to send a message to a big movie star or a CEO. The chances that I will be able to get their address is relatively low. Even if I do, they likely have someone they pay to filter their messages before it gets to them.

I am sure such a scheme embedded into a protocol would work with certain group of people. Most people would just get the same amount of spam, because they can't afford to up their threshold in a way that would deter the "marketeers" to stop such activity.

I actually think it would dramatically cut down on spam, but not hate messages.

If the sender is on the recipient's allow-list then it goes straight through. Otherwise the recipient has to solve a captcha. This allows humans to send small numbers of emails easily, but makes it harder for spammers.

Also, recipients could have deny-lists and automatically share them with others they trust. The deny-lists might be a list of senders' cryptographically generated IDs, in which case it should be reasonably hard to generate new ones (e.g. 10 minutes on an X86 cpu using an algorithm not conducive to parallelisation or special hardware).

> Otherwise the recipient has to solve a captcha.

No way am I going to solve captchas for incoming emails! Not any.

Spam from hell: you don't know if the email is real and you have to solve a CAPTCHA to find out.

Shouldn’t the sender be who needs to solve the captcha?

I've said this in another comment but it bears repeating, and perhaps repeating in different ways.

Stamps are just tokens, as in bearer tokens. How you get stamps is a different issue. Let me give you a couple of examples how one might do stamps without cryptocurrency:

1. Alice, "I'd like 100 Bob stamps please." Bob: "Please pay me $5"

2. Alice, "I'd like 100 Bob stamps please." Bob: "Can you please do some computational work on my behalf?"

3. Alice: "I'd like 100 Bob stamps please." Bob: "How will you pay for them?" Alice: "I could trade in 30 Carol stamps, would that work?" Bob: "Yes, let's trade Carol stamps for Bob stamps."

As for Apple Sign-In, I don't know what it is, so I can't speak to it.

Apple generates a random email address for each individual subscription, and forwards it to your inbox. If you cancel the subscription, then the forward is changed to a blackhole.

Not only does this give you a nice way to really cancel, it also means you can track down if someone sold your address to a spam list. Or if it accidentally leaks, rotate it.

>, it seems like the existing system could work fine by rolling per-contact email addresses to give out.

The problem is you can't give out "per-contact email addresses" to future unknown people when you can't predict who will legitimately send you email that's not spam.

The random-generated-rolling email addresses that hides real addresses such as systems in Apple/craigslist/ebay/domainWhoISprivacy can function because there's already a non-email type of _transaction_ or _activity_ to establish the first link for communication -- without requiring a reference to a person id. E.g. Consider that it's the _user_ that first enters the "fake" rolling email address into a shopping website. In that case, the activity is "shopping cart" and now the website can communicate back with that fake email.

That doesn't work for other real-life scenarios where the sender only has the person in mind to send a message but no transaction or other triggering activity to publish/discover a random email address. For that, you need stable easy-to-type addresses such as johndoe@example.com which you can put on business cards. But the problem is that spammers also know that non-random email address. So the cpu-puzzles approach was (attempting to) solve a different problem: people can publicize their stable email addresses but spammers also knowing it doesn't matter because they don't want to spend $$$ on cpu.

This is getting a bit fanciful, but there’s a universe where you print unique addresses on business cards.

Of course you can use a QR code.

In the world where you can’t do this, you could have a request mechanism. It’s a link, you go there, and it requires one-time auth from _any site at all of note_. Some sort of social proof. And that gives you a link.

Though ultimately business cards are business cards are business cards. They’re pretty low-value and you probably want to put a less important email on there.

>, you could have a request mechanism. It’s a link, you go there, and it requires one-time auth from _any site at all of note_. Some sort of social proof. And that gives you a link.

Sure but as I previously mentioned, that proposal is another variation of a "solution" where you must do some non-email activity first such as ... authorize with login credentials from LinkedIn/Facebook/Google/Github/Apple/etc ... and then receive the generated rolling email address.

Yes, if the solution space is opened up to include doing non-email activity as a prerequisite to later communicating via email, there are many ideas. But many SMTP email decentralized purists think having to use centralized "social proof" sites such as Facebook for single-sign-on credentials is not an acceptable solution.

That's why the (failed) Hashcash idea had appeal for email enthusiasts that wanted the "proof" to reside _within_ the SMTP ecosystem. E.g. the extra Hashcash email header row would be something like "X-Hashcash: 1:20:1303030600:anni@cypherspace.org::McMybZIhxKXu57jd:ckvi"

The "sudoku-solving" hashcash "proof" as one might call it... is generated by the email sender and verified by the receiver without relying on a non-email entity. The "legitimacy score" of new emails from new unknown users can be calculated and assessed within the SMTP ecosystem. ... But it's not a solution that pleases everyone because there are inevitable tradeoffs: (1) cpu heat "killing polar bears" and (2) home computers (instead of spammers' computers) inadvertently expend the cpu because of infection by malware to become part of a bot army

So to go back to your idea of a non-email activity as a requirement to open up a new email communication link... this is not an unreasonable scenario as this was the way SMTP email in 1981 used to work. Before the general public accessed the internet in the 1990s, the email system didn't have a massive spam problem because the non-email activity to prevent it was being hired by University of XYZ that was part of the network linked by National Science Foundation. (That researcher had ".edu" address.) Or the person wanting to send an email was a government worker in the Department of Defense. (That government worker had a ".mil" address.) So any new email users were already vetted by the hiring procedures of universities and United States government. It's like an ancient form of "social proof" without Facebook/LinkedIn/etc. As a consequence, a researcher "bob@xyz.edu" sending a new email to "alice@darpa.mil" -- was not likely to be spam. (Similar to users noticing that their company Slack channel doesn't have spam. Yes, it's because the people talking to you on Slack had to be hired first and therefore, your coworkers are unlikely to send you spam.)

But now that email is "opened up to everybody" -- including the spammers, the "hiring procedures" as the non-email activity to prevent spam doesn't scale up for a billion new users. So your proposal tries to re-create a barrier again... instead of University of Illinois vetting you before giving you an ".edu" email address, the similar idea for modern times is to have something like Facebook "vet" you with their sign-on credentials before revealing some random generated per-contact email address.

To summarize the meta categories of solutions for email spam:

- outside of email universe solutions: non-SMTP non-email activity prerequisite such as 3rd-party entity "social proof": e.g. 1980s old days of being hired by USA government or educational institution, or today's proposal of 3rd-party SSO credentials from centralized websites such as Facebook

- inside the email universe solutions: proof-of-work, Bayesian text filtering, domain and ip reputation blacklists, etc

(But domain and ip reputation blacklists solutions can arguably be categorized as "outside" of email system because it requires a big entity that can scan millions/billions of email traffic to create the blacklists. A residential SMTP server sending a new email to another residential SMTP server won't have that reputation list.)

> if the recipient system would require an ε payment to the recipients' public wallet

And allow recipients to whitelist senders who don't need payment.

Why would you prefer and value your bank sending you some automated valueless security theater[1] over your relative sending you a human to human birthday greeting? And why would you build the system so that, for everyone, personal communication is expensive and burdensome, and for every company, mass advertising is cheap and easy? (Relatively cheap, because companies have vastly more money than individuals).

This applies whatever the cost values is; if it's low, it's low for spammers. If it's high, it's high for individuals. And wherever "low" or "high" is, someone you like will think it expensive enough to be in the way and someone you dislike will think it cheap enough to be no problem.

[1] if the bank stopped the attempted logon, I don't care. If the login was actually me messing up, I already know. If they didn't stop the logon, then they didn't detect it was fraudulent and wouldn't be emailing or calling at all.

Given how much SMS and phone spam there is I am not sure this would work.

This is a proposed email spam mitigation, not an SMS spam mitigation.

Yes, but SMS are way more expensive for the spammers to send than I assume this proposal for mail will be and there still is a ton of SMS spam. The issue with spam is that it is lucrative and I do not think a small fee will fix that.

This idea is not bad. I would just add that there should be an option for parties with mutual trust to exchange without cost.

Your bank is going to increase your fees to cover the cost of sending mail to you, so the process is a pointless waste of resources in that case. This illustrates the need for a free mechanism between parties that trust each other.

My bank just sent an email "A surprise for you!!". Open it up ..it's a link to my app to login to see a useless budgeting report I've been suffering with for over a year. That should cost them.

> That should cost them.

It could, if you choose, cost them your business.

Like I said, they can just charge it back to you, and no law is going to completely prevent them from doing that one way or another. So I think it's a waste of time with a party you already have a paid service agreement with.

i suppose if your inbox auto-replied with an ACK you could just instantly repay the postage

Yeah, but as others have pointed out, I know my bank, and I know my aunt, so wouldn't a properly implemented signing mechanism just solve the problem? I know that PGP failed, but with a better implementation and greater support it just might work. This would also solve phishing, where the attacker would be willing to pay a few cents per attempt.

For institutional senders, this is what DKIM already does. Your bank has an e-mail domain registered with a CA somewhere that other e-mail domains, such as wherever you receive mail, trust.

Too bad that even if I setup DKIM correctly Google still black holes my email.

This is something that is missing from the OPs list of problems with e-mail. There is an "extended" version of it by a certain bigtech company that a lot of people use, which is not completely interoperable with e-mail. Just enough to confuse people into thinking that it is, but not more.

Yes! But that's not a solution for aunt Sally, though indeed it solves the phishing issue.