[Cryptography] Paid SMTP (PSMTP)

[Ersin Taskin]

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, Bertrand Mollinier Toublet <
crypto-metzdowd at bmt-online.org> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20180228/22e9535e/attachment.html>