Lets walk through the proposed solutions to this issue, because this is the biggest problem I see with the proposed new way of mailing:
> In the simplest case, the server might never give out stamps
For me, that's not feasible. I hand out my mail addr. with cards, as signature, its on websites, in READMEs, etc. I knowingly invite people to contact me via mail.
> The server might require the putative sender to solve a CAPTCHA of some kind.
How does that work if the mail is generated automatically, eg. a coworker makes me the recipient of a customers monitoring system? How does this work if the mail is generated without a GUI, eg. using a terminal mail-client?
> The server might require the sender to write a short sentence of why they want to reach the recipient. If that contains keywords chosen by the recipient, the server issues the stamp.
How does this solve the problem of being able to be contacted by strangers? The would-be sender has to know the keywords. If these are publicly available, eg. in a README, then there is no security, if they are not, sending a mail becomes guesswork for the sender.
> The server might require some sort of proof of work.
Let's forget for a moment how much trouble is caused by the energy consumption of cryptocurrencies, but how would that work on, say, a mobile device with already limited battery power?
> The server could require a very small payment.
The article points out the problem with this already. This would mean companies that can afford the fees are now free to spam me with advertising, but someone from an underprivileged community, who found a bug in my project, may think twice about contacting me.
-----
Edit:
In my opinion, spam and phishing are not problems that should be solved by changing or replacing SMTP.
Don't get me wrong, I am not defending SMTP. It has a lot of shortcomings that need to be addressed, the biggest are an incabability to transmit binary data without resorting to base64 encoding, and the lack of built-in encryption support.
But spam and phising are issues to be solved at the application level, not the protocol level. Spam isn't that different from portscans, and we don't change TCP/IP to prevent these.
> The server might require some sort of proof of work.
One of the things that I think many people don't really understand about the proposal I made for Stamps is that POW is not required for stamps. Stamps can be given in any number of ways.
For example, someone could simply issue them, with money. For example, if Alice wants to contact Bob for the first time, Bob might say "It will cost one Stamp please", and then Alice will need to get a stamp, maybe it costs 25 cents. Then Alice gives the stamp to Bob, and Bob lets the message pass.
I think proof-of-work systems are incredibly wasteful, and would think that should be an absolute last resort.
90% of European supermarkets (and some Canadian supermarkets) require you to put money in them to unlock them. It's either 1 euro or 1 Canadian dollar.
You get your money back when you give the cart back.
Lets walk through the proposed solutions to this issue, because this is the biggest problem I see with the proposed new way of mailing:
> In the simplest case, the server might never give out stamps
For me, that's not feasible. I hand out my mail addr. with cards, as signature, its on websites, in READMEs, etc. I knowingly invite people to contact me via mail.
> The server might require the putative sender to solve a CAPTCHA of some kind.
How does that work if the mail is generated automatically, eg. a coworker makes me the recipient of a customers monitoring system? How does this work if the mail is generated without a GUI, eg. using a terminal mail-client?
> The server might require the sender to write a short sentence of why they want to reach the recipient. If that contains keywords chosen by the recipient, the server issues the stamp.
How does this solve the problem of being able to be contacted by strangers? The would-be sender has to know the keywords. If these are publicly available, eg. in a README, then there is no security, if they are not, sending a mail becomes guesswork for the sender.
> The server might require some sort of proof of work.
Let's forget for a moment how much trouble is caused by the energy consumption of cryptocurrencies, but how would that work on, say, a mobile device with already limited battery power?
> The server could require a very small payment.
The article points out the problem with this already. This would mean companies that can afford the fees are now free to spam me with advertising, but someone from an underprivileged community, who found a bug in my project, may think twice about contacting me.
-----
Edit: In my opinion, spam and phishing are not problems that should be solved by changing or replacing SMTP.
Don't get me wrong, I am not defending SMTP. It has a lot of shortcomings that need to be addressed, the biggest are an incabability to transmit binary data without resorting to base64 encoding, and the lack of built-in encryption support.
But spam and phising are issues to be solved at the application level, not the protocol level. Spam isn't that different from portscans, and we don't change TCP/IP to prevent these.