[Cryptography] Paid SMTP (PSMTP)

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