> > 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,
No, it really does no such thing. Final delivery is a well defined action that
takes place before POP comes into the picture.
> "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.
Not necessarily. POP can be used in a variety of ways, and leave mail
on server modes are quite popular in practice.
> 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
I agree. It may seen odd that POP in particular operates after final
delivery, but that's the way it is.
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.
Which is why all the original work on so-called "timely delivery" in the FAX WG
never panned out. Originally this was a (misnamed) attempt to extend ESMTP
DELIVERBY semantics past the point of final delivery to cover POP and IMAP
activities. It ran afoul of the architectural issue that POP and IMAP actions
don't consist of a single, well defined transactin, which makes it impossible
to know when the message has been "delivered". And there was also the
implementation issue that Message Stores don't have queues and queue timeouts.
> 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.
I agree with Pete.