Two of this e-mail system's characteristics -- having to do with identity (anonymity or spoofing) of the sender and the costs incurred by the sender -- make spamming easy.
Anonymity and spoofing mean you don't know the sender; the sender isn't who he claims to be; or the sender is fictitious. This enables spammers to get their message or virus through to recipients and avoid scolding, retribution, and overall accountability for their deeds.
Solutions like white lists (enumerate who you allow), black lists (enumerate who you don't allow), and policy frameworks (register respectable sources) attempt to discipline e-mail by sender. Bayesian filters attempt to filter e-mail by content. These techniques put additional burdens on the recipient and further raise the cost of spam.
The second characteristic of the current e-mail system is that all messages traverse the network and end up being stored on the recipients' SMTP servers. With multimedia and files attached to e-mails, message sizes have gone up drastically. The cost of sending and storing the messages is multiplied. That cost is for the recipient's account.
One tiny change in the e-mail model could address both of these characteristics -- and go a long way to resolving the problem of spam.
Consider the message being stored on the sender's server rather than the recipient's. Consider only a tiny notice going to the recipient. You, the recipient, review your notices and decide which messages you want to receive. Further, if you choose to receive the message and then consider it spam, you may inform the sender. The sender cannot be anonymous or spoofed. The recipient must know him to come for his message.
This model change has many useful characteristics.
First, it removes anonymity and spoofing. You, the recipient, may not know who is sending to you but you do know where they are and how to contact them. You can easily find out who they are (because their host and ID are registered). Spoofing does them no good and you little harm.
Second, Internet traffic and storage is greatly reduced. A spammer sending out a million short notices generates much less traffic than one sending out a million messages. He is likely to get only a tiny number of requests for his message. The spammer must be reachable long enough for a good percentage of his targets to receive his notice and respond. Currently, he can just fire off his messages and quickly disappear. He could try to use notices to effect a denial of service, but many tiny notices coming from the same place are easily detected and mitigated.
Third, with this new model, the cost to the spammer goes up significantly. He must store his messages for some length of time. Even worse, he must store his list of recipients. The protocol will require the recipient to be in the send list to retrieve the message. Large lists will consume large amounts of the spammer's storage.
Fourth, there are benefits to the non-spammer. A sender can retract a message before the recipient sees it. This is useful in those cases where a sender's judgment improves and he realizes he shouldn't have sent the message.
All the issues regarding retrieval of e-mail messages remain essentially unaffected. For example, much the same way e-mail works today, after the notices arrive, recipients can set their systems to automatically fetch all of the associated messages or only a portion of them based on certain selection criteria.
Message retrieval becomes a two-step processes (albeit the steps can be made transparent to you): 1) The message is retrieved from the sender's server to your server and 2) The message is downloaded from your server to your e-mail client (i.e., Outlook, Eudora). Your server connects to the many sending servers at retrieval time (in addition to the sender's multiple connections to send notices). SMTP makes these separate connections only at send time and does it in background. The user may choose to watch as this retrieval happens and thus experience the delay directly.
The message notices are well structured so that you, the receiver, can easily configure the model to use white lists, black lists, and content-type filters (e.g. don't bring me any video files right now) to narrow messages of interest on the fly. Of course, to use Bayesian filtering, you must retrieve the message.
You can opt for automatic periodic retrieval from trusted senders and download those messages as efficiently as you do now. You can retrieve and download important messages as you wait. Messages can be ignored, rejected or retrieved in the background for later download. Devices like BlackBerrys and Palms, which support synchronization and robust downloads with automatic resumption after interruption, will behave as they now do. All this flexibility is easily obtained.
At least one large caveat exists for moving to this new model. Try as we will to make it bulletproof, there will be those trying to compromise it. Solid defenses will take time to build. In the mean time, this model could coexist with the existing model. To users, it could be made to look like an additional feature of their existing system. As the new model matures, the old model will fall into disuse and die a natural death.
Todd Marshall is an independant developer of special purpose computer applications and the creator of GLEE, an interpretive programming language.
