On Fri January 28 2005 12:02, Mark E. Mallett wrote:
Some more random comments-
4.1.4 Mail Delivery Agent (MDA)
The <MDA> delivers email to the recipient's inbox.
Or, more generally, to the recipient's mailstore. "inbox" is usually
a name for a specific well-known folder in the recipient's mailstore.
The MDA might store directly to other folders; saying "inbox" implies
something narrower than that.
I agree that "inbox" (in multiple places in the draft under discussion)
is unclear. However, mailstore isn't necessarily a suitable
replacement; and MDA might bounce messages, it might drop them (e.g.
spam), it might file them into "folders" (e.g. an IMAP MDA w/ Sieve),
it might print them on a printer device, it might forward them to
another mailbox (e.g. message forwarding when a user is on sabbatical
or has otherwise attained another mailbox) or to a pager, etc.
Access to the mailstore (rather than
"delivery") may be effected via POP and IMAP. Those are not the only
mailstore access mechanisms; direct filesystem access would be another.
Further, I think you've got a false distinction between POP as a
transfer technique and IMAP as an access technique. Both can be used
to access a remote mailstore: using POP does not imply deleting
messages once they have been accessed (in fact that is a separate
function that must be requested by the MUA).
I think the difference between POP and IMAP is clear; POP message
"access" is limited to transfer, deletion, and (optionally) status.
IMAP can move messages between folders, run search queries, tag
messages, sort messages, access individual header fields or
MIME-parts, etc.; far more than mere transfer/deletion. POP is
really a transfer mechanism (which is fine for some purposes)
whereas IMAP is capable of much more.
One perspective of "end-to-end" is that the receiving end is the first
mailstore delivered to
That might be an expected perspective for a transport-specific
mailing list like ietf-smtp, but in a human communications medium,
the real end-to-end process involves the users. MDNs, for example,
make no sense without considering the users (mind you, MDNs
aren't addressed by the draft under discussion...).
"in-band" is not a clear term because there are multiple bands. When I
read "in-band" I think "mixed with the message," e.g. in the message
header. Any routing information that's outside of the message text, I
think of as "out-of-band" even if it's using the same communication
channel (which I assume is where you get "in-band"). Especially
when you close with:
One danger with placing additional information in header fields is
that gateways often alter or delete them.
which reads as if it is talking about "in-band" information.
I agree.