IM2000 is discussed on the IM2000 mailing list.
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.
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.
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?