> Quite the opposite. It should charge the user per-e-mail on an at-cost basis.
When you write “charge” do you mean money? When you say “at cost” do you mean at the cost of the sender, receiver, both?
If charge means money, isn’t money just a transaction cost inefficient method of proving stake? Maybe a new SMTP would ask the sending server to perform some work on behalf of the reciever in order for the recover to accept it.
In this case, you'd want the sending client to do some POW. Verified either by the sending server (to prevent it being blacklisted) or by the recipient (as a much wider anti-spam system).
I still would expect this breaks down from ASICS and generally the price not being high enough.
It also seems like it’d have unintended consequences due to resource differentials: a non-profit or freelancer with a newsletter would feel that harder than spammers using other people’s computers or simply getting commissions on the more profitable scams, similar to how cryptocurrency made ransomeware profitable enough that the attackers have more capacity than the defense at most small to medium-sized businesses.
Maybe this would work better in combination with PKI: allow me to give you a signed voucher OR you pay full price, allowing that price to be set high enough to actually deter spam. That wouldn’t help with businesses abusing your contact info for marketing, of course, but there’s never going to be one fix for this class of problems.
When you write “charge” do you mean money? When you say “at cost” do you mean at the cost of the sender, receiver, both?
If charge means money, isn’t money just a transaction cost inefficient method of proving stake? Maybe a new SMTP would ask the sending server to perform some work on behalf of the reciever in order for the recover to accept it.