Internet Mail 2000

Internet Mail 2000 is a new Internet mail architecture proposed by Daniel J. Bernstein (and in subsequent years separately proposed by several others), designed with the precept that the initial storage of mail messages be the responsibility of the sender, and not of the recipient as it is with the SMTP-based Internet mail architecture.

Whereas the SMTP-based Internet mail architecture has a close analogue in the architecture of paper mail, this is not the case for Internet Mail 2000. Its architecture depends on various things that are unique to the natures of the Internet and to electronic messages. One of its goals is to reduce spam.

Implementations

Over the years since Daniel J. Bernstein proposed it, several attempts have been made to design and to implement a real Internet Mail 2000 system, with varying degrees of achievement. The closest thing to a concrete, open implementation of the system is Meng Weng Wong's StubMail, which was presented at Google in July 2006.

A commercial implementation exists at feed-mail.com, but it appears to be dead (the last blog entry—dated September 5th, 2005—saying the beta would be delayed).

Some ramifications of this concept

Each message is stored under the sender's disk quota at the sender's ISP. ISPs accept messages only from authorized local users. The sender's ISP, rather than the receiver's ISP, is the always-online post office from which the receiver picks up the message.

The message isn't copied to a separate outgoing mail queue. The sender's archive is the outgoing mail queue.

The message isn't copied to the receiver's ISP. All the receiver needs is a brief notification that a message is available.

After downloading a message from the sender's ISP, the receiver can efficiently confirm success. The sender's ISP can periodically retransmit notifications until it sees confirmation. The sender can check for confirmation. There's no need for bounces.

Recipients can check on occasion for new messages in archives that interest them. There's no need for mailing-list subscriptions.

Some advantages

In the old Internet mail infrastructure, keeping track of undelivered messages takes a lot of work. The mail client (e.g., ezmlm) and mail transfer agent (e.g., qmail) have to support variable envelope return paths; bounce messages then have to be parsed by an automated bounce handler that matches bounces with original messages. In IM2000, each message in the sender's archive carries its own delivery status. In the old Internet mail infrastructure, bounce messages are often misdirected by low-quality software. Users end up receiving bounce messages that should have been sent to an automated bounce handler. In IM2000, there are no bounce messages.

In the old Internet mail infrastructure, mailing-list managers have to keep track of mailing-list subscriptions. Typical subscription protocols are slow, complicated, unreliable, difficult to automate, and trivially subject to forgery. In IM2000, mailing lists are a purely local matter for the receiver's software.

In the old Internet mail infrastructure, the receiver's ISP has to carefully write every message to disk, so that messages will not be lost if the computer crashes. This limits the amount of mail that can be received. In IM2000, the receiver's ISP can keep notifications in memory.

In the old Internet mail infrastructure, a message to a large mailing list is written to disk on a huge number of computers. In IM2000, a message to a large mailing list is written to disk only by a few receivers who want to save local copies of the message.

Some questions to be answered

How should receivers be identified? How will the sender's ISP find the receiver's ISP? Recipients will want to move transparently from one host to another. How should senders be identified? How will the receiver find the sender's ISP? Recipients will want to provide better handling to known senders; in the long run, recipients will want to debit unknown senders.

How should messages be identified? How should messages be downloaded? Messages could be retrieved through HTTP, but an NFS/FSP-style UDP-based protocol would be much more resistant to denial of service.

How should notifications, messages, and confirmations be protected against espionage and sabotage? DH authenticators seem more appropriate than public-key signatures for private email; they're also much faster and just as convenient.

How should the sender create a message?

How should the receiver download a list of notifications?

What format should messages have?

See also

Bernstein has also proposed the Quick Mail Transport Protocol (QMTP).

External links

• Daniel J. Bernstein's original IM2000 outline (2000)
• Brett Watson's proposal (2002)
• JFC Morfin's proposal (2003) describing weemail
• Jonathan de Boyne Pollard's detailed proposed specifications and elaboration of the system (2004)
• Duan's, Dong's, and Gopalan's proposal (2004) and subsequent Internet Draft (2006) describing Differentiated Mail Transfer Protocol (DMTP)
• Nathan Cheng's proposal (2006) describing Hypertext Mail Protocol (HTMP)
• Levent Ozturk's Email protocol, added SMTP commands