Ref. rjbs

Ref. rjbs

Ricardo Signes has made a great effort to provide similar information. His proposals focus more on creating a dedicated protocol, rather than define the general algorithms. Much of this document resembles his points of view.

Some divergencies are:

• implicitly we stick to terse notification, only absolutely necesary metadata should be transmitted in a notification message. We do not prohibit verbose notification either.
• Ricardos Mailing lists send actively notification messages to the subscribers upon receiving a post. We allow this scenario, but rather propose that a "scan"-operation has to be performed on the archive, to generate notification messages.
• Ricardo is more specific about possible operations of the Recipient on the Mail Storage - this is a flaw in our document.
• Mail addresses are shown to be user-domain compounds in Ricardos example. We introduce the Directory as an independent component of the Mail infrastructure. While "old" Email-addresses should still be recognized and deliverable via Gateways, we want to break principally the dependence of an Email user and a host.
• Encryption of the delivered message on the wire is not possible in all cases, mostly because of legal issues in some countries. We do explicitely not enforce it, while providing the means to do it (Ricardo does not make an explicit statement about this matter either, but assumes encryption in his example).

IMTP

Internet Message Transfer Protocol. This is used to post a message to the Mail Storage Server. Ricardo means to edit a Message with "your favorite text editor" and then usa a mua programm to copy the message via IMTP over to the Mail Storage Server. Ricardos IMTP is similar to SMTP.

IMMP

Internet Message Managment Protocol. Not specified by Ricardo, but meant to tackle outgoing queue managment. Delivery problems are managed by the posting process (IMTP). This does well on SMTP, because from that point on you really don't have any guarantee about what will happen with the message. Eventually you get a bounce. Although not explicitely discussed here, we think that a user with posting rights on a Mail Storage Server also has some management to do. Undeliverability, forgery attempts, download statistics, etc. can be made available to the sender. On the other hand we foresee, that a user can withdraw or modify a message after posting, or post a followup chained to an already posted message.

This are implications to the im2000 concept that the messages is queued on the sender side and requires more thought.

IMNP

Internet Mail Notification Protocol. A Mail Storage Server connects to a WYWOP server to send notification messages about new posts.

IMRP

Internet Mail Retrieval Protocol (?). A mail user who gets a notification about a new messages lets a mua connect to the Mail Storage Server to retrieve that message.

WYWOP

While You Were Out Protocol. Corresponds to our notify server, who receives the notification messages issued by a Mail Storage Server. A Mail User eventually connects to the WYWOP-Server to learn about available messages.

Ref. rjbs