Paying for Email with Computational Time (Part 2)

In a previous article I briefly described how it's mathematically possible to force email senders to pay for email with computational time. Such a mechanism could effectively stop spam email on a large scale. Email filters would become a thing of the past.

This page hashes out the exact mechanisms in a little more technical depth. It assumes a basic understanding of how the current SMTP protocol works.

My idea for implementing this would be an augmentation to the current SMTP protocol. Legacy email clients and servers would continue functioning as they are phased out over time. Let's call the augmented protocol SMTP Postage.

When you compose and send a message from your SMTP Postage enabled client, it is sent to your outgoing SMTP email server as normal. The only difference is that the message would include a special item in the header along the lines of, "SMTP Postage: Enabled."

If the user is using a legacy email client, their message will lack the special header, and the message will be placed in the normal queue for delivery. Conversely, if the user is using a new email client, and the server doesn't support the new standard, the additional header would be ignored.

Your outgoing email server would then immediately contact the incoming email server for the recipient's domain via SMTP. Instead of sending the email, it would request an "Envelope" for use with SMTP Postage. This "Envelope" would be the product of two large prime numbers as described in the previous article. This number also becomes a general-purpose tracking number for the email.

The "Envelope" is sent back to the sending computer as part of the SMTP transaction.

It is now the sending computer's job to factor the product of the two primes into its roots. The size of the product dictates how long this process will take. This process is in effect forcing the sending computer to "pay" for sending the email using computational time.

The two prime roots of the "Envelope" become the "Stamps" that the receiving server will require to accept your email.

Once the "Stamps" are determined, the sending computer again establishes an SMTP connection to its outgoing email server. This time it just sends the "Envelope" and the "Stamps".

This information is matched up with the previously queued email message, and everything sent to the receiving server for the recipient's domain. The receiving server can then easily verify that the "envelope" was one that it issued, and that the "stamps" match it.

Since the receiving server knows that significant computing time was required to send the message, it is almost certainly not spam e-mail. It can be delivered to the end-user without passing through the spam blockers that all other email must. There is an immediate benefit for users to adopt the new system in that it improves email reliability.

After the large majority of servers and clients add support for the new system, support for non-stamped email could be eliminated.

There are all sorts of variations on this scheme to optimize performance. With some minor tweaking the number of extra server requests can be minimized.

Back