Internet Mail 2000

IM2000 is a project to design a new Internet mail infrastructure around the following concept: Mail storage is the sender's responsibility.

IM2000 is discussed on the IM2000 mailing list.

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

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?