[Top] [All Lists]

Re: revised Email Architecture draft

2005-01-29 12:47:01

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.

<Prev in Thread] Current Thread [Next in Thread>