eMstamp: Stop Spam Mail :: Gain Privacy

eMstamp (pronounced: em stamp)

Technical Description

OVERVIEW
The eMstamp system comprises a software module residing with an MTA (Message Transfer Agent). The module works with the SMTP to charge a fee for every message sent. It does this through the use of a binary token called an eMstamp, having embedded credits. The credits are purchased in bulk by the administrator of an MTA and stored in a bank of credits used for sending mail. An eMstamp with a given number of imbedded credits is required on each message before a receiving eMstamp enabled MTA can allow delivery of the message. Upon delivery, the receiving MTA strips the credits and adds them to its own bank of stored credits. As long as an MTA is receiving more messages than sent, there will be no need to buy eMstamp credits.

Nearly all MTAs receive more mail than is sent because of spam and commercial mail. On the other hand, MTAs used for commercial and spam mail send more messages than received. Therefore, the cost of eMstamp credits accrues to administrators of the commercial and spam mail servers. Commercial enterprises should actually find the eMstamp system a benefit because now they have a way of insuring message delivery. Spammers, on the other hand, traditionally relying on the nearly zero cost of e-mail, will be severely inhibited from indiscriminately sending millions of unsolicited e-mail messages every day. Even at a cost of 1/10 cent per credit, sending just 1 million e-mails will cost the spammer $1000.00.

OPERATION
The eMstamp system operates with the SMTP by simply injecting an additional communication step in the transfer channel. The EHLO command is used by the outgoing MTA to determine if it is communicating with an eMstamp enabled incoming MTA. If it is, it can expect to receive from the incoming server instructions as to the number of credits needed for delivery to the mailbox in question and a partial eMstamp token, comprising a ID value. If the outgoing MTA does not know what to do with this information then it is not an eMstamp enabled server and it will receive a quit command. The only exception is when the number of required credits is zero; then the outgoing MTA will continue with the message transfer. This allows the eMstamp system to be introduced gradually over time without disrupting existing e-mail services.

An outgoing eMstamp enabled MTA takes the received information and aggregates it along with the required credits into a complete eMstamp token. At the same time it subtract the required credits from its bank. The message along with the eMstamp is then sent to the incoming MTA. The incoming MTA authenticates the eMstamp against its list of sent IDs and, if valid, adds the incoming eMstamp credits to its bank of credits and delivers the message.

A typical transaction flow will appear as follows:
a typical eMstamp transaction

In the illustration the number of eMstamp credits is referred to as a privacy rule value. This is because the credits required for delivery of a message to a mailbox can optionally be determined by the rightful holder of that mailbox. Therefore it can be considered that the holder is establishing a privacy level wherein the box will only accept messages having a number of eMstamp credits equal to or greater than the privacy number. Alternately, the MTA administrator can set a default value. The advantage of a privacy level setting is that a user can set a high value that commercial and spam mailers will not be willing to pay for while infrequent mailers will find that it's not a deterrent. In the case of multiple mailboxes, a user can set different levels according to the use of each box.

EMstamp credits are issued in bulk, upon payment, by the administrator of an MTA, to a central issuing agency. The agency establishes a communication channel with the eMstamp software module residing on that MTA and adds the purchased credits to the bank. A provision is also made for redeeming credits for cash where an MTA has an excess of eMstamp credits not needed for normal operation.

SECURITY
All of the eMstamp activities must of necessity take place in a non-trusted environment. Provisions have been made for protecting an eMstamp transaction, the eMstamp software module, and bank of credits from alteration. In addition a secure procedure is invoked when the issuing agency contacts the eMstamp module of an MTA for issuing or redeeming credits.