3 ms·

> What would (imnsho opinion) have fixed spam is sender pays. I've debated this with a lot of people. We're 50/50 on it. Fifty agree with me, fifty million don'

> What would (imnsho opinion) have fixed spam is sender pays. I've debated this with a lot of people. We're 50/50 on it. Fifty agree with me, fifty million don't. I propose a scheme where the sender pays e.g. 5 ct per e-mail (low enough that it does not matter for legitimate use, but high enough to make spam unprofitable). BUT with the following twist: The receiver can generate API tokens that allow free e-mail delivery. So when I sign up for e.g. Twitter, I can give them an API token for my mail address so they can send notification mails to me for free. If they decide to start spamming me, or if they decide to sell my token to a spammer, I can just revoke the token and the spam flood stops instantly. I have not found any flaws in this idea yet. RFC!

pbhjpbhj 8y ago
First thought is that international differences in value of a fixed monetary amount might break it. 5¢ is affordable in USA but too much in, I don't know, Mongolia. Lower it to 0.05¢ and you get spam from USA. Natural solution is a pricing list, but then USA spammers could route via cheapest geographic servers. How do you get paid? Banks will put a transaction cost making sending email cost stupid money. So, bitcoin? But the built in energy costs for processing a transaction will force a floor on the transaction pricing that's too high? If a token leaks you'll have to fiddle about to allow a sender's emails to get through ; I guess you could automate that if your MUA had credentials to inform genuine senders of API key updates.
cujo 8y ago
You could do away with the 5ct part of this, just by requiring a special header to get around the api part. Then you funnel all that junk into a special folder (black hole) that you can either ignore or check if you are expecting a legit request for your attention. The more I think about it, the more I love this idea. All email that shows up in your inbox is there because you have to explicitly allowed it.
dane-pgp 8y ago
I've been thinking of a similar system, actually, but instead of having each end user pay per transaction, you have each domain put up a bond (in a digital currency) which can be forfeited if the domain is found guilty of spamming. The one controversial part of this is deciding who is permitted to redeem the bond, i.e. who is the central arbiter of what is and isn't spam? Well, fortunately we already have an entity like that, de facto, since we have the Big 4 email providers ("Gmail, Hotmail, Yahoo, and AOL", or any other similar group that all mail servers must, in practice, comply with the demands of). In the system I'm proposing, if any of these big providers detect a domain being involved in spam (or N out of M providers, to reduce the risk of false positives), they could redeem the bond. Of course, the bond would be structured such that the only recipient was a non-profit, like the IETF, or possibly an entity like ICANN. That way there is no financial incentive to make false positive claims. As for how this system would be introduced, that's the easy part. All pre-existing domains would be grandfathered in, so that no current email users would be negatively affected. (Indeed, there is a moral hazard that some email providers would support this system precisely because it only affects new entrants to the market). There would simply be a flag day, after which if you register a new domain, and want to send emails from it, your domain registrar would have a check box saying "Yes, I am happy to be charged an extra $10 and have put it in a bond so that I can send email to the Big 4 providers". After sending a certain amount of legitimate email, a Big 4 provider could then send a transaction which makes the locked funds return to the original issuer of the bond. Finally, to decide how big the bond has to be, we can look at data like this: https://krebsonsecurity.com/2018/06/bad-men-at-work-please-dont-click/ https://krebsonsecurity.com/2018/06/bad-men-at-work-please-d... If spammers are going to extra effort to save a few dollars on their registration costs, then their margins must be pretty tight. It also means that domain reputation systems are working, since spammers have to keep bulk buying new domains: http://conferences.sigcomm.org/imc/2013/papers/imc247-haoA.pdf http://conferences.sigcomm.org/imc/2013/papers/imc247-haoA.p...

pbhjpbhj 8y ago

First thought is that international differences in value of a fixed monetary amount might break it. 5¢ is affordable in USA but too much in, I don't know, Mongolia. Lower it to 0.05¢ and you get spam from USA. Natural solution is a pricing list, but then USA spammers could route via cheapest geographic servers. How do you get paid? Banks will put a transaction cost making sending email cost stupid money. So, bitcoin? But the built in energy costs for processing a transaction will force a floor on the transaction pricing that's too high? If a token leaks you'll have to fiddle about to allow a sender's emails to get through ; I guess you could automate that if your MUA had credentials to inform genuine senders of API key updates.

cujo 8y ago

You could do away with the 5ct part of this, just by requiring a special header to get around the api part. Then you funnel all that junk into a special folder (black hole) that you can either ignore or check if you are expecting a legit request for your attention. The more I think about it, the more I love this idea. All email that shows up in your inbox is there because you have to explicitly allowed it.

dane-pgp 8y ago

I've been thinking of a similar system, actually, but instead of having each end user pay per transaction, you have each domain put up a bond (in a digital currency) which can be forfeited if the domain is found guilty of spamming. The one controversial part of this is deciding who is permitted to redeem the bond, i.e. who is the central arbiter of what is and isn't spam? Well, fortunately we already have an entity like that, de facto, since we have the Big 4 email providers ("Gmail, Hotmail, Yahoo, and AOL", or any other similar group that all mail servers must, in practice, comply with the demands of). In the system I'm proposing, if any of these big providers detect a domain being involved in spam (or N out of M providers, to reduce the risk of false positives), they could redeem the bond. Of course, the bond would be structured such that the only recipient was a non-profit, like the IETF, or possibly an entity like ICANN. That way there is no financial incentive to make false positive claims. As for how this system would be introduced, that's the easy part. All pre-existing domains would be grandfathered in, so that no current email users would be negatively affected. (Indeed, there is a moral hazard that some email providers would support this system precisely because it only affects new entrants to the market). There would simply be a flag day, after which if you register a new domain, and want to send emails from it, your domain registrar would have a check box saying "Yes, I am happy to be charged an extra $10 and have put it in a bond so that I can send email to the Big 4 providers". After sending a certain amount of legitimate email, a Big 4 provider could then send a transaction which makes the locked funds return to the original issuer of the bond. Finally, to decide how big the bond has to be, we can look at data like this: https://krebsonsecurity.com/2018/06/bad-men-at-work-please-dont-click/ https://krebsonsecurity.com/2018/06/bad-men-at-work-please-d... If spammers are going to extra effort to save a few dollars on their registration costs, then their margins must be pretty tight. It also means that domain reputation systems are working, since spammers have to keep bulk buying new domains: http://conferences.sigcomm.org/imc/2013/papers/imc247-haoA.pdf http://conferences.sigcomm.org/imc/2013/papers/imc247-haoA.p...