Some comments, in the same order as the draft text:
In section 1.1. "intermingled" would probably be more accurate than
"divided".
Section 1.2 encourages review of tables. Table 4.1.4 refers to actor
"h", which is nowhere defined.
Section 1.2 also discusses MDA/MS/MUA and requests review of the model.
Several terms used in the model (discussed separately below) probably
need revision, and gateways (of various types) aren't shown at all.
And section 1.2 mentions message identifiers, but nowhere are the
message header fields that use message identifiers -- Message-ID,
Resent-Message-ID, Original-Message-ID, In-Reply-To, References,
Supersedes, and Delivery-Report-Content-Original -- discussed!
Indeed, only a tiny fraction of standardized message header fields
are mentioned at all.
Section 4 omits presentation and discussion of gateways. I can think
of several types of gateways:
1. gateways between different transport methods (using different
transport addressing), where the message content is identical,
e.g. between SMTP and UUCP (some mention in RFC 976)
2. gateways between mail systems where transport, addressing, and
message format all differ, but the basic function (interpersonal
electronic correspondence) is the same. E.g. between Internet
mail and X.400 (MIXER series of RFCs), between Internet mail
and proprietary vendor-specific systems
3. gateways between systems that use essentially the same message
format and transport, but between separate functional entities;
typically a separate end-to-end function using the Internet
message format and infrastructure. E.g. voice messaging (VPIM),
fax, printing
4. gateways implementing end-to-end functionality layered on top of
Internet mail (this is distinguished from the case immediately
above; whereas in the above case the interaction with the user
is typically *not* via a MUA except in particular implementations,
this case typically *does* use a MUA). E.g. EDI (RFC 3335).
5. list expansion is typically a gateway function
6. message processing for security by MTAs or MDAs which are acting
as gateways. E.g. virus scanning. See RFC 1344 vs. CERT Vulnerability
Note #VU836088 (http://www.kb.cert.org/vuls/id/836088).
7. gateways between systems that use essentially the same message
format but different modes of distribution and addressing. E.g.
between mail and Usenet.
Note that the message store (4.1.5), particularly type MS-1, is
correctly identified as a *message* store (and not a "mail" store);
IMAP (Internet Message Access Protocol) in particular is capable of
accessing messages in the message store regardless of how they may
have arrived at that store (Usenet, SMTP, ...).
Section 5.2 refers to "message headers". Some messages do in fact
have multiple headers; the message header and one or more MIME-part
headers. Section 5.2 refers to "headers" where it means message
header fields. Use of "headers" in lieu of "header fields" may
lead to confusion and/or misinterpretation.
Sections 6.2.4, 6.2.5, and 6.2.6 should probably be renamed; gateways
(in general), alias expanders (in particular), and mailing list
expanders (in particular) are not typically MUA functions. They
tend to be MTA or MDA functions.
Section 6.2.6 refers to mailing list "address", which should be
"mailbox" (a single mailing list is typically not accessed via
a named group, which contains a list of mailboxes and is the
difference between "mailbox" and "address" (RFC 2822)).