RE:[Cryptography] Paid SMTP (PSMTP)-2
First, your mail has gone to my spam box at Gmail, which funnily shows we must do better anti-spam. Well, PSMTP does not suffer false positive.
On Wed, Feb 28, 2018 at 12:27 AM, xxx@xxx> wrote:
Let me repeat that my proposal does not claim to be Final Ultimate but rather an additional tool in the toolbox. It does not cover the entire mail space, and it is there to be used alongside with the current anti-spam tehcniques like white-listing, black-listing, grey listing, etc. I had written these points in several parts in my mail explicitly.
Ersin, a few thoughts, although it seems hardly fair to burden the Crypto mailing list with what is essentially a spam fighting discussion (moderators will decide):
I think we are offering a cryptographic solution to anti-spam.
a) can I ever get to a point where I can outright reject non-paid email, as a receiver, and not miss out on potentially desired mail? If not, this solution suffers from one of the FUSSP issues whereby it needs to be fully deployed to be of value.
In fairness, you do acknowledge this problem (even though you are not providing a solution to it)
Looking at the PSTMP world from the point of view of an SMTP view is the problem. Imagine PSMTP has fair adoption. A PSMTP user would be inclined to managing whitelists. I have suggested efficient ways of whitelisting, involving inner-domain default, domain scale whitelisting for corporate/organization domains together with all the successful schemes currently available. If a mail comes from someone not in my whitelist and not with a payment script then I reject it. Then the sender is notified that “he is not included in the whitelist and he should send a PSMTP mail”. If PSMTP is adopted, a non-spammer would spare a penny to resend the mail by just clicking the “Resend with PSTMP” button. They can whitelist each other later. We can have features like mutual whitelisting. I have admitted that I do not know how to run a campaign to make it adopted. However, since it will help honest mail users like you and me, adoption is for our benefit. PSMTP together with whitelisting/blacklisting can work if we have adoption.
b) does being a sender require a TEE? If so, this is a major impediment, because deployment of the solution is effectively akin to deployment of new hardware.
I think it is fair to start with standard cryptocurrency wallet scheme and evolve with it. Today we have companies like Rivetz developing SDK’s to access TEE even on standard mobile devices. I think wallet developers are getting more security day by day.
c) if I don’t require a TEE, then I’m subject to theft of the sender payment, which is a strong counterincentive to deploying the solution in the first place: as a sender, I would not want to take on the potential liability of a spam run executed by stealing my payment credentials.
CommCoin accounts would have far less money than Bitcoin accounts. Anyone with the ability to hack cryptocurrency wallets would be wasted in spam business. The way the whole crypto-thing goes, if we can’t get end-point private key security then spam will not make it to the list of our major problems.
d) how are both the recipient and “the IETF” getting paid in this scheme?
IETF creates and sells the coins in the first place and does not get any transaction fees. The sender pays the receiver 1 CC per mail. I thought I made it crystal clear in my proposal.
Finally, and even though you seem to be of good faith in your presentation of PSMTP, I would refer you to the following couple of “You might be” entries:
:)) I had read the whole page before my post and I even attached the link. Although my proposal declares missing the FU part of FUSSP, I still judge myself on the list. Read the https://www.rhyolite.com/anti-spam/you-might-be.html#dont-get-no-respect-4 carefully, though.
