[Cryptography] Paid SMTP (PSMTP)

[Ersin Taskin]

 I received some remarks and challenges to my proposal for PSMTP. Some
through the mail list, some in private. I researched the anti-spam
state-of-the-art on the web. I checked patents, implementations, services,
products, techniques, etc.

I got fascinated by the term: Final Ultimate Solution to the Spam Problem (
FUSSP). Most pages about FUSSP refer to the famous letter at
https://slashdot.org/comments.pl?sid=98024&cid=8373855 (dated Feb 24,
2004). One such page is http://www.dmuth.org/fussp.html ( Jan 14, 2006).
https://www.rhyolite.com/anti-spam/you-might-be.html is worth reading to
see the attitude of the people in the anti-spam space. This last page has
the following remark: " The existence of this list is proof that the spam
problem will never be solved by the people currently working on it." After
surfing on the subject for 4-5 hours, I accepted this auto-proof. I find
the FUSSP check-list at http://www.dmuth.org/fussp.html to judge any
anti-spam solution useful. I applied it to my proposal (which does not
claim to be Final Ultimate but rather an additional tool in the toolbox). I
think it performed well against the checklist. I could not find any patent
violation, similar proposal, nor any similar implementation (product,
service). Is it because it's a bad idea?  I have the impression that my
naivety on this subject may turn out to be precious. Therefore, I decided
to give an outline of my proposal and open it to discussion.

The whole idea is that a sender-pays-receiver scheme as presented below as
an extension to the current SMTP system will provide a robust tool in our
anti-spam toolbox. The cost per mail is the same for all mails and mail
addresses. It is as low as not hurting honest people/agents but high enough
to kill most of the spam. Let us make it a penny for the sake of clarity in
this introduction.

Alice sends mail to Bob and Bob sends mail to Alice. Or, Alice mails Bob
who mails Charlie who mails David who mails Alice. Normal people will send
and receive emails. Alice pays when she sends and gets paid when she
receives. Her net mail cost will fluctuate around zero if there is a
symmetry. I personally receive more mails than I send. Therefore, my
CommCoin balance will increase negligibly in time. Someone sending more
mails than receive, will have a negligible cost. 100 net mails (#sent -
#received) will cost just 1 Dollar. So someone who sends 100 more
mails than receive per month would incur 1$/month cost. Companies may
require their employees to charge their corporate mail addresses themselves
to simplify the model maybe reimbursing some estimation through an increase
in their salaries. In any case, the cost per mail address would be
negligible in comparison to salaries. This would kill spammers because they
broadcast mails in a brute fashion and do not receive any responses.
Imagine 1 million copies of a single spam mail would cost 10 K$.

This scheme works much better than POW because;
i. the race is much more unfair against the spammer (the asymmetry is
significantly higher due to the cancel-out feature of mail fees).
ii. it is more difficult to hack/break a private key stored and used
locally in the Tursted Execution Environment than to gain control of a PC
to outsource PoW, than spoofing, forging, etc.. This raises the bar for the
spammer significantly. Thanks to the cryptocurrency revolution, end-point
private key technology (wallets) has a Cambrian age providing convenient
and secure means of private key utility both on PCs and mobile devices. I
had a face-to-face discussion with Len Veil of Rivetz who is an expert on
TEE, recently. He was convincingly optimistic on the future of end-point
TEE.
iii. the solution is environmentally friendly.

The email transaction fee schemes proposed so far are either too
complicated to implement or WKBI's based on wrong assumptions as
John Levine nails it on his recent posts in the list. See patents 6,697,462
(expired) 7,072,943 and earn.com, boxbe.com. The proposal below differs
significantly from all of them.

Therefore, the proposed scheme is robust and effective because it is
simple, fair and secure. The higher asymmetry brings enough room to find
the right value for CommCoin to kill spammers with low or no cost to honest
agents. Its simplicity can make it to the SMTP protocol in the long run.


THE SIMPLIFIED PROOF OF CONCEPT

I will simplify things and make simple assumptions to make my proposal
clear in this introductory mail. I will address implementation details in
other mails.

Mission #1: to fight against spam
Mission #2: raise funds for the Internet through IETF

Assumption #1. IETF (or a similar organization to serve the Internet)
accepts my proposal. I make this assumption to make the following easy to
understand.

IETF creates and runs a cryptocurrency system called CommCoin (or SMTP Coin
or AttentionCoin or ?)
1 CommCoin (CC) = 0.01 USD. It is pegged to 1 Cent.

The coin state for PSMTP is as follows simply:
The CommCoinAddress Table
1. Table name = "CommCoinAddress"
2. The columns are as follows.
    a. CommCoinAddressId:  PK
    b. MailAddress: Unique, not null, varchar (mail address type: obeys
mail address regex)
    c. CommCoinAddress: Unique, not null, varchar (Imagine we use BIP 38
scheme for private keys. Then this column will store the relevant coin
address produced from the private key according to BIP 38. This address is
derived from the WIF Compressed Public Key. You may consider it as the
Public Key).
    d. CoinBalance: not null, int (since 1 mail costs 1 CC and a mail is
not divisible we cannot have a non-integer balance)

We have two options to process transactions for the State (I assume 100
processor nodes just for clarity. IEFT can decide the number dynamically
for robust global implementation).

Option#1. Replication: the 100 processor nodes have the exact replica of
the CommCoinAddress Table (the Coin State). Imagine leader based ring
consensus algorithm. Leadership moves clockwise. The system runs in
synchronous mode. Each round is a few seconds. Clients contact some
processor nodes for transaction requests which are flooded across via, say,
an appropriate gossip protocol implementation. Then, each round the leader
validates, orders and commits the transaction requests from the mempool,
say, in a block. So the log is a blockchain. Upon successful
broadcast/notification/acknowledgment, all the other nodes register the
block on top of the blockchain, process the transactions in the block in
order and update the state reaching an exact replica. Then the current
leader leaves the microphone to the next leader. We may skip Byzantine for
the sake of PoC (we trust IETF). The processor nodes can have UTC Satellite
receivers for up to 50 nsec accuracy to keep the record of time
synchronously. These nodes are strongly connected and reliable to do a very
simple task. (We can have alternative implementations).

Option#2. Sharding: We can shard the table to the 100 processor nodes. Each
Processor Node will have its own CommCoinAddress Table shard. Every mail
address running in PSMTP mode must have one and only one Shard Processor
Node address denoting where its CommCoinAddress (Balance) is. Sharding will
save us from the issues of replication. However, we need additional
information for the state: The ShardNodeAddress of each mail address. I
would prefer a different table in relation to the CommCoinAddress Table
because this Sharding Table needs replication. It is a good design choice
because sharding node addresses of mail addresses change extremely rarely
if not at all while the CommCoinAddress Table state (balances) changes in
every mail transaction. Therefore, replicating the ShardingTable is trivial
while replicating the CommCoinAddress Table is not. The Sharding Table has
the following columns:
  a. ShardingId: PK
  b. NodeId: FK to relate to the Table of Processor Nodes.
  c. MailAddress: FK to relate to the CommCoinAddress Table.
(Implementation may use the relevant PK as FK)
So our simple data model has three Tables:
1. CommCoinAdress: Managing mail addresses together with their private
key/public key/coin addresses and balances.
2. Node: The table of the processor nodes. (100 records).
3. Sharding: Storing/managing which mail address belongs to which processor
node.

I personally prefer sharding for performance concerns that I address below.

The above-mentioned PSMTP layer sits on top of the SMTP Layer.

A MAIL TRANSACTION SCENARIO
Just for simplicity I only mention desktop and mobile mail clients below.
For the web client scenario, we would still require a local CommCoin wallet
application component, running in the TEE, for security concerns. For the
sake of convenience, it can support other currencies for easy exchange to
fill empty CommCoin balance.

Main Success Scenario:
1. Sender clicks the send button on his mail client.
2. The mail client signs the public key or the CommCoin address (BIP 38) of
the recipient with the private key of the sender (the payment signature).
3. Mail client attaches the payment signature to the mail.
4. Mail client sends the mail to its MSA via SMTP.
5. The rest is SMTP all the way through MTA(s) ending up at the destination
host (MDA of the recipient). I recommend DANE to be safe. Keep in mind that
IETF knows and manages the Processor Nodes and therefore guarantees that
their Certificates are good and there are no intermediaries. IETF also
manages the DNSSec entries accordingly. We have TLSA safety.
6. Before fetching the mail via IMAP or POP3 from its Mail Host (MDA), the
recipient mail client makes a RedeemCoin RPC by using her private key and
the sender's public key to the processor node. Implementation differs for
replicated vs sharded options. In the sharding option contacting your
processor node is enough.
7. In sharding, the processor node checks the redemption data, verifies and
sends the payment transaction to the sender's processor node. The two nodes
process the payment. 1 CommCoin is transferred from the sender's account at
the sender's processor node (shard) to the recipient's address at the
recipient's processor node (shard). In sharding, no involvement of other
nodes is necessary since we don't have replication. Each processor node
sends its client a successful termination notification. In case of the
replication option, the recipient's processor node sends the transaction
commit request to the other nodes and wait for the leader to commit it.
8. Upon receiving successful redemption notification, the recipient mail
client fetches the mail.

The whole idea is to accept the mail if the payment script attached to the
mail can be redeemed. I leave the UC extensions (exception handling) to the
imagination of the readers for the time being since this is the simplified
POC just to explain what I propose.

One huge bonus is to supply the IETF with significant funds to support the
Internet. IETF shall create and sell the coins that will be the blood of
PSMTP system. The Internet must own this CommCoin to fight against spam and
to fund some of its operations.

The same scheme can be applied to any means of communication. SMS,
Phonecall, any message type. My attention is valuable, so is yours. My
attention is a store of value, so is yours. Hence, we can call it
AttentionCoin (AttCoin) rather than CommCoin.

CHALLENGES
1. Performance bottleneck at the processors.
The number of mail transactions is insanely high. We have to exclude spam,
and non-PSMTP mail traffic, though. At the beginning, we will not have
performance issues since we will have few people getting CommCoin addresses
for their mail addresses. However, we must take into account performance
issues when this thing gets widely adopted.
As I said above my favorite is sharding. I put replication as an
alternative, popular in the crypto world today. Therefore, I will keep
sharding option in answering the performance issues.
a. White-listing
- I receive %90 of my ham emails through my corporate account. 90% of those
come from the within the company. So almost 80% of my incoming mail is
inner-domain. Since our company has its own domain name and since this is
the prevalent scheme I think a great deal of the ham email is inner-domain.
Mail clients can have the default setting of "free inner-domain mailing".
This setting will not apply to gmail, hotmail, etc. of course.
- Optionally, corporation/organization domains can whitelist each other on
admin level. This, I believe can decrease a great deal of processor
transaction volume. (Not crucial though).
- People can keep using personal whitelisting schemes.
If you think about it the PSMTP scheme makes whitelisting easier.
b. Inner-processor transactions
- Mail is geographical. I live in Istanbul. The majority of my emails come
from Istanbul. More than 80% come from Turkey. I believe the global people
form the very minority when it comes to ham email. The fact that "the more
global a mail is the more important and famous it is" gives the wrong
feeling that the vast majority of ham e-mail traffic is international. Spam
mail is international. Ham mail is extremely local in comparison. This
means the vast majority of my ham email transactions will take place in the
same processor node. Since sharding requires no replication this is a huge
network performance gain.
c. Inter-processor transactions.
I have a love/hate relationship with distributed systems and my technique
is to escape distribution whenever I can. Most "decentralized" consensus
ideas I have heard at the Bitcoin Ethereum Superconference don't take into
account network effects. I find this amazing.
The inter-processor transactions take place between the nodes of the sender
and the recipient only. Don't bother with the other nodes. Remember,
sharding requires no replication. We can apply all the enhancements of
sending transactions in packages rather than one by one, etc.
Other enhancement techniques are beyond the scope of this mail.

2. How about mail lists? They would not like to pay significant transaction
fees. They are good spammers:).
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
probably whitelist it. Since mail list white-listing so seldom I don't see
it as a problem.

3. "Requires immediate total cooperation from everybody at once"
People can use PSMTP and SMTP simultaneously for the same mail address.
However, we must spread the word and make it a trend, fashion, cause or
whatever to get their mail addresses registered to PSMTP. PSMTP enabled
mail addresses should look cool. We may think of campaigns, incentives to
accelerate adoption. I am not an expert on this thing. This is an issue I
am not comfortable with. All parties who are against spam should join
forces. Spam is a parasite sucking the blood of the Internet. We must find
a way to convince honest Internet users to do this trivial job.

4.  Public reluctance to accept weird new forms of money
Cryptocurrency revolution is promising. We can have a bootstrapping effect
to provide a useful robust cryptocurrency (CommCoin) to help cryptocurrency
adoption which in turn may help us with PSMTP adoption.

5. Huge existing software investment in SMTP
PSMTP sits on top of SMTP and does not require any changes to SMTP nor MTAs.

6. Spammers will find a way
Well, we have DANE, and Cryptocurrency revolution today. Past failures are
important to read. However, timing is important in technology. I believe
that if we add the PSMTP scheme through IETF via CommCoin, keeping the
current anti-spam techniques as well, we have a significant chance to do
something big for the Internet.

If you read all the way here, your feedback is precious.

Regards,
Ersin

"This shit's got to go" Jacque Fresco
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20180227/dae67a5f/attachment-0001.html>