[Cryptography] Paid SMTP (PSMTP)

[tifkap]

I've been building spam-filter clusters for quite some time, and
although I appriciate new people trying to cut their teeth on the spam
problem (and moving the field forward), i'm a bit sceptical about this 
proposal.

For the record: I stopped creating anti-spam clusters a couple of years ago
(This because I became a bit to cynical for my own taste, and chasing spammers 
can be temporary fun, but is a waste of time nontheless). 


The reason I'm sceptical is that there is no real difference betweel
this proposal, and all the earlier 'e-stamp / proof-of-work proposals'
i've seen before.

Also: I don't think you really understand what the problem is with 
spam.

1rst:
The problem of how to live in a spam-free world has allready been solved.

The solution is simply invite only (whitelisting .. in an ideal world this 
would be done by a PGP web of trust kind of system). But the problem then 
becomes how to deal with people / messages that are not whitelisted / 
denied yet (invite's).


2nd: If whitelisting is the solution, then why do we still have spam? 

It's no coincidense that almost all social networks use invitation 
only. But the fact that mail is 'open' (not just in the sense that anybody
can try to send a message, but also that it's a open federated network), 
is one of the few benefits email has left. These 2 properties keep it from
being whiped out by closed social networks.

So email is still around because invite only has no good solution to the 
'introduction problem'.

Also: mail filtering has evolved from simply trying to filter the bad stuff out.

You might think that email is a simple message system, where 'bad mail' 
(spam, virii) are simple filtered, and the rest is allowded to pass though,
but this is not a correct image. In reality :

some mail is ok (sender whitelisted.. 90% of ham ) 
Some mail is known bad (sender blacklisted, 90% of spam ) 
And the rest is grey.. and this grey mail is the problem.

Some people see this mail as spam, and some do not. A spam filter is 
not a system that is trying to determine absolutely what a mail is, but
a classifier that trys to keep the amount of 'corrective voting actions'
of it's users to a minimum. (unless it's required to protect the users,
in that case they get no vote, or the vote is overruled).

A SPAM-FILTER IS NOT A ARBITER OF ABSOLUTE TRUTH!! IT'S A SYSTEM
THAT IS TRYING TO SECOND GUESS WHAT IT IS THAT *YOU* WANT TO SEE IN
YOUR INBOX / SPAMBOX. IT's HIGHLY PERSONALISED, AND TRYING TO SECOND
GUESS YOU.  


WHy did earlier e-postage schema's fail? 

* They don't understand email's fundamental strenght is that is not 
  invite only

* They require adjustments in the SMTP protocol 

* They have no (or no adequate ) penalty for fallback behavior

Say I where to implement your schema (as the first person on the internet).

I now have to choice about what to do clients that do not implement P-SMTP.

I choose to reject all email from those clients => I get no mail whatsoever

Or :

I choose to also accept old smtp mail. If I don't do this I will lose mail,
especcialy in the beginning. 

But if I (and everybody else that implements P-SMTP) also accepts plain old
smtp, then why would anybody bother to pay to get mail delivered? 

Say that mail that doesn't pay get send to a SPAMBOX / GREYBOX .. The users
will 'vote' this mail out of the spam / greybox, into the inbox (because that 
is what spamfilters do).

So why bother with paying for mail? Legitimate mail will be voted in the inbox
no matter what (whitelisted), and unwanted mail can pay as much as it wants,
but it will still be voted into the doghouse, no matter what.


Kind regards,

=paulv



>    2018-02-27 22:53 GMT+03:00 John Levine <[1]johnl at iecc.com>:
>    First thing's first. Thank you for your time. I appreciate it.
>    Let me answer your questions in an order providing a train of
>    thought.Â
>    Â  Â
> 
>      * Hacker X broke into grandma's account and sent $100 of spam.Â
>      Does
>      grandma pay the $100?  If not, who decides?  If so, why would
>      grandma
>      want to do this?
> 
>    Let me repeat: " ...my proposal (which does not claim to be Final
>    Ultimate but rather an additional tool in the toolbox)Â ". I also
>    stated explicitely that PSMTP lives simultaneously with SMTP. So by
>    definition I am not proposing a FUSSP covering the entire mail space.Â
>    Anyone who is not capable of installing, filling, using a crypto wallet
>    cannot be a part of PSMTP. They can continue with SMTP. Granma can keep
>    mailing her granchildren in SMTP.
> 
>      * Spammer Y claims that Hacker X broke into his account and sent
>      $100
>      of spam. but he's lying.  Does he pay?  How do you tell the
>      difference
>      between him and grandma?
> 
>    Yes he pays. I don't have to tell the difference. Security is crypto
>    wallet level. If you lose your private keys you lose your CommCoins
>    just like Bitcoin. You would admit as a cryptographer that
>    crypto-wallets and cryptocurrency use cases increased end-point
>    security significantly. This raises the bar a lot for the spammer.
>    Â
> 
>      * There are roughly three billion e-mail users in the world.  How
>      do
>      you plan to set up accounts for all of them and sell them all
>      stamps?
>      A large fraction, perhaps now the majority, of mail users are on
>      mail
>      systems like Gmail and Yahoo and Netease that have no financial
>      relationship with their users and do not want one.
> 
>    Again, I have to repeat that my proposal is not a FUSSP. It does not
>    cover everyone.Â
>    GMail, Yahoo have nothing to do here. I have explicitely written that
>    you have a crypto wallet installed on your PC and Mobile. It is that
>    crypto wallet that takes care of the coin (PSMTP) business through your
>    CommCoin private keys. One can think of a HD key scheme to manage
>    multiple PSMTP registered mail accounts. We will need some integration
>    here, I admit. But the integration will not involve Gmail into
>    financial relations. My money is at the CommCoin Network and I reach it
>    through my private key(s) that I manage locally through my wallet
>    app.Â
>    Â
> 
>      * Some people are much richer than others.  For example, when I had
>      a
>      phone SIM in India, the data plans started at 10 rupees, about 15c
>      US,
>      and plenty of people bought that plan to check crop prices and maybe
>      a
>      handful of messages.  How do you set a price that's affordable for
>      people in the developing world while not rounding to zero in the
>      rich
>      world?
> 
>    Again, my proposal is not a FUSSP. Anyone that cannot afford a penny
>    cannot use PSMTP. However, the aim is to make spam less profitable.
>    What is the point of spaming a poor guy in India who cannot afford a
>    penny? If you have the ability to find a way to sell him Cialis, you
>    are wasted at spam business.
> 
>      * The vast majority of non-spam mail is sent in bulk, some through
>      discussion lists like this one, some transactional info such as
>      receipts, shipping notices, and bank statements, quite a lot of
>      marketing stuff that people have said they'll accept.  Assuming
>      that
>      the list owner is not a philanthropist willing to pay to subsidize
>      his
>      habit, how do you tell your mail system to waive the fee for the
>      bulk
>      mail you want?  How do you unwaive it?  How do you do it in a way
>      that
>      Hacker X can't claim you just subscribed to his list and waive
>      everything and you don't notice until your mailbox is full of his
>      junk?
> 
>    I thought I covered that. The answer is white-listing, ie putting the
>    sender in the exception list. Let me repeat below.
>    "2. How about mail lists?...Â
>    When a user subscribes to a mail list he puts the mail list address
>    to his white-list and acknowledges that the mail list will not attach
>    payment script to emails. Therefore, its mail client skips redeem
>    process for the mails from the list. It has to skip if the user wants
>    to get mails from the list. White-listing an address is much easier
>    than subscribing to a mail list. We can provide automatic and one-click
>    convenient ways to do that. So anyone who bothers to subscribe to a
>    mail list will whitelist it. Since mail list white-listing is so seldom
>    I don't see it as a problem."
>    Therefore, the mail list would not add a payment script. The recipient
>    will accept the mail without contacting the PSMTP node because it is in
>    the exception list (white list). You can remove the sender address from
>    the white-list anytime, for example when you unsubscribe. Hacker X
>    can't claim that I subscribed to his mail list because I do it in my
>    mail client or wallet app. I manage my contacts. Imagine the following
>    algorithm run by the mail client-wallet couple
>    IF (the sender is white listed)
>    Â  Fetch the mail
>    ELSE IF (payment script not included)
>    Â  Apply my non-white SMTP settings
>    ELSE IF (syntax valid AND I am the receviver of the CommCoin (I use my
>    private key))
>    Â  IF (RedeemCoin())
>    Â  Â  Â Fetch the mail
>    Â  ELSE
>    Â  Â  Â Reject the mail
>    ELSE
>    Â  Â Reject the mail
>    Please note that all the reject mail scenarios above end in black
>    listing of the spammer as I mention below.
> 
>      * What is the overall capacity of your scheme?  If it's under
>      10,000
>      messsages/sec you're not serious.  100K/sec would be better.  When
>      making your estimates, assume that the mail is 90% spam, and the
>      spam
>      will all have bogus stamps pointing at empty wallets, so you'll have
>      to do the check but there's no money to be collected.
> 
>    Think of a solution that spots the spammer at the first instance of a
>    spam mail from him and then forwarding him to the routine blacklisting
>    procedures we already have. That would be scary for any spammer. Now
>    let's see if we can do that with PSMTP.Â
>    A wallet keeps track of money. That's what it does. A CommCoin wallet
>    never signs invalid payment scripts. An empty wallet signature is
>    invalid. Its security is to the level of keeping private keys secret.
>    Therefore, if a spammer wants to attack the system from an empty
>    wallet, he would do it via an invalid script, it will be spotted as a
>    spammer by the system at the first such attempt. The PSMTP system will
>    then apply DNS Black Listing procedures as well as push the PSMTP
>    blacklisting data to the relevant MTA's. Therefore, the same address
>    cannot send a second spam. Not to mention that the empty address is
>    deleted from the PSMTP DB. So the simplest version of the requirement
>    is that a PSMTP address is allowed to have empty account but is
>    prohibited to try to use it. You can try to use an empty account once
>    before it gets deleted. The spammer would not bother with PSMTP and
>    sail towards SMTP. The very existence of anti-spam techniques like
>    greeting delay, greylist temporary rejection, nolisting, quit detection
>    all show that when there is a little bit of trick in the mail
>    transaction, spammers don't bother and move on to another mail
>    address in their list where the process runs in a less tricky manner.
>    That is the essence of brut force. PSMTP trick is much harder to cope
>    with than those at the presented techniques. And PSMTP applies
>    balcklisting measures immediately while these techniquies do not. I
>    could easliy imagine that the PSMTP threat would cause spammers to
>    stay away. How about a minimum opening deposit requirement of 100 CC (1
>    $) on top of that? This although not necessary, would further scare
>    spammers away while 1 $ is nothing for someone who would prefer the
>    privildge of PSTMP.Â
> 
>      I certainly have to admire the chutzpah of someone who, having seen
>      that this idea has failed every single time it's been tried over the
>      past 20 years, wants to do it again.  (And, sorry, no, there's
>      nothing
>      very different about it this time around.)
> 
>    When I saw so many patent applications and failures based on
>    stamp/postage scheme to fight spam by so many experts in the field the
>    feeling I get is "this is a good idea waiting for the right time".



>    History is full of good ideas that failed until the right time has
>    come. Technolgy history is no different. The right time provides right
>    conditions where prerequisites to succesful implementation/adoption are
>    met. You can see so many failures and conclude the idea is completely
>    bad or you can see so many experts having tried over and over again and
>    may still conclude that it is a good idea waiting for the right
>    conditions. I believe the cryptocurrency revolution is the key
>    difference against past trials. This revolution made wallets convenient
>    to the computer literate people who would be the first adopters of
>    PSMTP. I see a lot of development activity at wallet/ledger and TEE
>    spaces. I don't see a reason why we shouldn't get the
>    convenience-security level of end-point/wallet private key + ledger
>    schemes to anti-spam. Besides my proposal is different form all the
>    past implementations I have seen. They either lack the
>    cyrptocurrency-wallet approach or go for the wrong direction of paying
>    high amounts to important people ([2]earn.com). None involved an
>    organization like IETF. Adding DANE to the list of differences now, I
>    think there may be a chance this time.
>    One other aspect of PSMTP is that it does not posess any false positive
>    nor false negative as long as private keys are safe.Â
> 
>      Once you've figured these out, we have lots more questions to ask.
> 
>    If you take your precious time, I will do same. After all, this is a
>    constructive discussion.
>