[wordup] Internet Mail 2000

[Adam Shand]

In a lot of ways it's an interesting idea.  In the "real world" postal 
system the sender pays, is this the equivelent of that?

It also puts RSS feeds and readers into a different light.

Adam.

From: http://cr.yp.to/im2000.html
Via: http://www.decafbad.com/blog/geek/email_feeds.phtml

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?