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.
Using Internet protocols, delivery is effected with POP [RFC1939] or
IMAP [RFC3501]. When coupled with an internal, local mechanism, SMTP
permits "push" delivery to the recipient system, at the initative of
the upstream email service. POP is used for "pull" delivery at the
initiative of the recipient system. Notably, SMTP and POP effect a
transfer of message control from the email service to the recipient
host. In contrast, IMAP provides on-going, interactive access to a
message store, and does not effect a transfer of message control to
the end-user host. Instead, control stays with the message store
host that is being access by the user.
I don't really get what you are trying to say here. I would say that
the MDA delivers to the mailstore. 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). A better distinction
between POP and IMAP is that POP provides a minimal form of access
to a single folder on a mailstore, while IMAP provides more extensive
forms of access to a mailstore. (And even that's not necessarily true:
one can hack POP servers to allow access to different folders in different
ways.)
One perspective of "end-to-end" is that the receiving end is the first
mailstore delivered to (for those messages that do indeed end up in
mailstores, which is the majority.) All other operations on email after
that delivery are mere manipulations of delivered mail. With that
perspective, POP/IMAP and the like are probably better covered by an
"access" category (Actor: Recipient) which would include not only
reading email but moving email from one delivered mailstore to another.
5.1
Direct envelope addressing information, as well as optional transfer
directives, are carried in-band by MTAs. All other envelope
information, such as trace records, is carried within the content
header fields.
"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.
This probably gets back to the whole "envelope/SMTP envelope/message"
brouhaha from the prior round of discussions. (Personally I thought
that X.400 made some good distinctions here, e.g. with the "P1 Envelope"
and "P2 Envelope" -- then again I haven't cracked open the old redbook
in, um, decades.)
6.2.5 MUA Alias Handling
Notably it does not typically change the RFC2821.Mailfrom
Realizing that you said "typically" : yet some alias implementations will
rewrite the return-path information, e.g. in sendmail;
mem: mem
owner-mem: mem
will rewrite the sender and implied mailfrom. (qmail has a similar
capability via .qmail-ext-owner files). I believe that people do use
this facility simply to handle bounces locally for certain mailboxes
under any condition, e.g. for role accounts or for an alias set up to
receive email from a mailing list.
And I believe that it is very common to use this "owner" rewriting when
expanding to more than one address, in order to take local responsibility
for problems with delivery to any of them.
[ I had collected a bunch of other comments on the previous version but
managed to misplace them. oh well.. ]
mm