ietf-smtp
[Top] [All Lists]

Re: MS vs. pop and imap

2004-05-29 15:48:12

On 5/29/04 at 11:32 AM -0700, Dave Crocker wrote:

The architecture needs a "Message Store" piece. The MDA delivers messages into the message store, while POP/IMAP transfer messages from the message store to the rMUA.

This looks like it needs to be discussed a bit. I think that reality is a bit different than you describe.

Here's why:

POP really does finally delivery, "moving" messages from upstream to downstream -- to choose some neutral terms. By contrast, IMAP does "copying" from upstream to downstream. That is, POP changes where the message actually resides. It is eliminated from the upstream. As a core construct, IMAP leaves the message on the upstream host and simply provides a copy to the MUA.

I don't buy your distinction at all and don't believe it is part of the architecture. POP and IMAP are protocols that pull mail out of the MS and bring them to an MUA. Both POP and IMAP have commands to get the contents of the message from the MS. Both POP and IMAP have commands to delete the message from the MS. And the getting and deleting are separate commands. They manipulate the MS for the MUA. They are in the same functional layer.

Not convinced? Consider: If the distance between the MDA and the MS (e.g., in the case of SMTP) can't be traversed (due to a disk full situation, for instance), a DSN is returned to the sender. If the distance between the MS and IMAP can't be traversed, that's not information that is sent back. POP is exactly analogous to IMAP in that situation: The distance between POP and its previous hop (which I claim is the MS) is a local matter and failure (or success) is not part of the transport reporting scheme. The MDA is the agent responsible for taking the message out of the transport system and bringing it into the MS for the user. It therefore has responsibilities to report back to the transport system success or failure. Neither POP nor IMAP have such responsibilities. They aren't part of that bit of the architecture.

Each protocol can do some/all of the functions of the other. But each has the primary job I've described. I think that that should be depicted differentially.

Nope. Disagree completely.

pr
--
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102