[Top] [All Lists]

Re: MS vs. pop and imap

2004-05-31 10:31:55


CD>            |        MTA
CD>            |         |
CD>            |         |  smtp, lmtp
CD>            |         |
CD>            |    +-- MDA   <-------------------------+
CD>            |    |    |                              |
CD>            |    |    |  smtp, imap, (local)         |
CD>            |    |    |                              |
CD>            |  smtp   MS                           sieve
CD>            |    |    |                              |
CD>            |    |    |  imap, pop, http, (local)    |
CD>            |    |    |                              |
CD>            |    +--->+                              |
CD>            |         |                              |
CD>            |         |                              |
CD>            +------> MUA recipient (rMUA) -----------+

Your diagram implies scenarios such as delivering into the MS by imap
and then having the MUA access the MUA by pop. Do we really want to
imply that?

It is not all that uncommon for IMAP append to be used to deliver messages to a
store. For example, suppose you have an MTA that performs final delivery using
LMTP and you want to use it with an IMAP server that doesn't support LMTP
delivery. The obvious thing to do is write an LMTP server that stuffs messages
into the IMAP server using APPEND.

We need to get clear about the difference between an MTA-related
transfer of responsibility, versus an action with the MUA of moving a
message from one folder to another. In the former, the message is held
in something that is a queue. It's difficult to imagine any utility in
modeling a folder as a queue.

Nobody is talking about moving messages between folders here.

CD> - some clients 'pull' messages into their local store via smtp and ETRN,
CD> bypassing the message store.

There's also ATRN.

For the scenario you describe, what is the difference between a Message
Store and an MTA's queue? It suggests that "delivery" is bypassing the
MS. I don't know what it means to bypass the MS.

You're still thinking of the MS as some kind of adjunct to the MUA. It isn't.
It is a separate piece of functionality, consisting of a collection
of mailboxes and some means to access them remotely.

MUAs may also provide local mailbox storage and it is perfectly reasonable for
messages to be delivered to such storage directly. But an MUA that provides
local message storage is not a message store, for two reasons: (1) It doesn't
provide remote access and (2) It doesn't support multiple users.

Where does the message
go? Onto the MUA's screen?

I don't know that I've ever seen a MUA that does "screen delivery", but  I have
most certainly seen specialized MUAs that print the mail they receive.

CD> - I'm afraid we cannot ignore webmail, so note the addition of http as an
MS->>MUA access protocol. I guess http should appear for the sender MUA ->
CD> MSA step in which case the MSA is actually a webserver.

2. HTTP is not used to deliver, post or even transfer mail, as a
semantic object.

I hate to have to disagree again, but it most certainly has been used this way.
For example, it is entirely possible to push MUA functionality into the web
browser using, say, Java, and then transfer messages as semantic objects to and
from the browser using HTTP. Basically what you're using is downloading the MUA
and running it in the browser. And since browsers prefer HTTP, well, there you

Mind you, I'm not saying this is a good idea. Experience has shown that it
isn't. The generally sad state of interoperability in the browser world makes
this approach fairly problematic in anything but the most homogeneous
environments. Additionally, inferring SMTP envelope information from what's in
the header (something these things sometimes do to implement message
submission) has its own set of issues. But this has been done. Has it been done
often enough for us to describe it as part of our architecture? I simply don't
have the data to say. (I generally try and stay as far away from webmail
schemes as possible.)

It is used as a front-end exchange protocol between an
application and the user interface (the display functions.) It has no
semantics for the data being transferred. So the use of http is really
within a split MUA. (Hmmm. Maybe that's the elaboration that will help,
showing a cross-net split MUA sometimes and not others?)

This is indeed the most popular way it is done. But not the only way.

In other words, http is a presentation-layer exchange protocol, not an
email protocol.

In most cases, yes. But not all.