Chris,
CN> The architecture needs a "Message Store" piece. The MDA delivers messages
into
CN> the message store, while POP/IMAP transfer messages from the message store
to
CN> 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.
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.
Here's an attempt:
| MTA
| | smtp, lmtp
| MDA <-------------------------+
| | smtp, pop, (local) |
| MS sieve
| | imap, (local) |
| | |
+------> MUA recipient (rMUA) -----------+
This might suggest that one could use pop to do final delivery and then
imap for access, but I think that showing more differential components
and "paths" in the architecture slide would be worse.
That is:
| MTA
| | smtp, lmtp
| MDA <------------------------------+
| | |
| +---------------------+ sieve
| | smtp | pop |
| MS MS |
| | imap, (local) | (local) |
| | | |
| +---------------------+ |
| | |
+------> MUA recipient (rMUA) ----------------+
strikes me as too much about implementation and not enough about
architecture.
Thoughts?
d/
--
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>