Store, Don’t Forward is an essay by Jack Rusher, published here Sunday, October 04, 1998. It is part of Ideas, Big and Small.
A proposed solution to some of the problems that plague our email infrastructure.
The email infrastructure that has helped make the Internet a ubiquitous tool is showing its age. SMTP and friends were developed in a more innocent time; a time when there were few sites on the Internet and most users were neither commercially motivated nor technologically naïve.
It was in this trusting environment that the “store and forward” paradigm was developed to overcome the inconsistent links over which email traveled — many facilities, including large universities, were still communicating with the internet via periodic dialup and part-time frame relay connections. Store and forward was the designed to assure that best effort would be made to deliver mail over an unreliable network.
Store and forward should be now truncated to “store.” All email should be stored on the sending party’s email server — an operation that should require the same authentication process as fetching one’s mail. Instead of sending messages over the wire, the outgoing mail server should communicate with the receipients’ email servers via light weight notification slips. This simple design change would improve the efficiency of email in a number of ways:
- It would hinder dialup-based bulk commercial email because such email relies on the ability of the sender to quickly stuff the messages into victims’ mailboxes without culpability.
- Large binaries, such as photos, would be charged against the quota of the sender rather than that of the receipient, and, because notification slips would be sent instead of copies, corporate email systems wouldn’t be crushed under the weight of mass emailed baby pictures.
- The sender would not need to copy sent email into a separate archive; the outgoing mail spool would serve as the sent mail archive, which would also enable very low overhead message forwarding.
- It would be possible to determine whether a receipient has picked up a piece of mail, which better maps to traditional postal functions (e.g. “certified mail”).
- Such a system could support versioning, whereby change notifications could be circulated instead of fresh copies of a message. In organizations that typically use email to collaborate on large documents this would be a great boon.
- World readable folders and messages can be created with very little overhead. This has potential implications for mailing lists and personal publication systems.
This model would make email more like a filesystem — the lens through which I see so many problems — and less subject to many kinds of failure. The addition of cryptography to handle transport layer security and authentication (of both the sender and receiver) would improve the infrastructure by providing a general mechanism for secure and private communications over the Internet.
UPDATE 2000-08-20: The above mentioned ideas are not exclusively the ravings of a single lunatic. Another lunatic has come to the same conclusions, though with greater emphasis on mailing lists and bounce message handling.