Several comments not already addressed, in order of appearance:
A number of formatting issues (text version); 2 empty lines
before the first page heading, pages shorter than the 58 lines
recommended in RFC 2223 (probably a contributing factor in the
mangling of diagrams). "SMTP" in the heading should be "Network
Working Group".
Section 1, second paragraph, first sentence: comma after "two"
is superfluous.
Section 1.1, last paragraph, first sentence: comma after "prior"
is probably superfluous.
Section 2, second paragraph, first sentence: "a discussions"
probably contains a typographical error.
Section 2.1, second paragraph, first sentence: comma after "three"
is superfluous.
Section 2.1, second paragraph, second sentence: "Fromhe t" is
probably a typographical error for "From the".
Section 2.1.1: the author (or indeed authors) is not necessarily
the same as the sender, i.e. the person initiating transmission.
Lumping the two distinct functions into "originator" is likely
to cause additional confusion, rather than shed light on the
mail architecture.
Section 2.1.3: I cannot understand the meaning of "Mediator is
viewed by the Mail Handling Service, when [...]". "viewed"?
The comma may be superfluous, but it's difficult to tell.
Same section: "hence the Mail Handling Service sees a new
message" is unclear w.r.t. message-ids (indeed, inadequate
discussion of message-ids continues to be a problem in this
iteration of the draft, as it was in the previous version).
A "new message" is supposed to have a new message-id (RFC 2822
section 3.6.4), whereas the message-id does not change when
a message is relayed, or when distribution is expanded by a
list expander, or when a message is gatewayed (provided that
the id semantics can be preserved). This is a general issue
with lumping disparate sorts of entities under the single
label "mediators", then making statements about "mediators"
that do not apply to many of those entities.
Same section, second paragraph mentions mailing lists; with
the exception of certain administrative messages, a list expander
does not generate "new messages" (as is claimed for "mediators");
it redistributes the *same* message -- with the *same* message-id --
to multiple recipients. The same error is repeated under the
section subheading "Mailing List:", which also speaks incorrectly
of a "new message".
Same section, subheading "Adaptor:": Is there a more precise
reference or description available? It's difficult to comment
based on "{per Ned Freed}".
Same section, subheading "Security Filter:": "by having message
subjected" probably contains a typographical error ("a message"
or "messages"?).
Section 2.2, second paragraph: [w.r.t. relays] "It is legal to
have only one" -- it is legal to have none, and indeed that is
the original SMTP model; transfer from SMTP sender/client
directly to recipient SMTP server/receiver with no relays
except in unusual circumstances.
Section 2.2.1: "submitting it to a mail relay" Or to the
destination MTA/MDA.
Same section: "Source also has the responsibility for any
post-submission, originator-related administrative tasks [...]"
An SMTP sender/client (or its associated host) might have
no receive/sever capability for error/delivery notices. At
large sites (e.g. ISPs), server and receiver functions may
be implemented by separate software running on separate hosts.
Section 2.2.3 "Relay:": "A Relay does not modify the message
contents." Ah, for the good old days (pre-SMTP) when that
was true. Alas, relays do modify message contents by adding
trace fields to the header. Some mangle other header fields
also, and still others foul up body content, though neither
of those operations are officially sanctioned except for
gateways.
Same section, second paragraph: "between a client and a
server Relay." Or a destination MX handler which is also
an MDA (i.e. no relay). [Also, "Relay" need not be capitalized.]
Same section, last paragraph, last sentence: "message, itself,
contain": commas are superfluous.
Section 3: "mailbox address <addr-spec>": three
distinct items (RFC 2822 section 3.4). Conflating those
distinct terms will only confuse matters, rather than elucidate
the mail architecture.
Section 3.1.1, last paragraph: Is the line break in the middle
of a local-part intentional?
Section 3.2: typographical error "structure" should be "structured".
Section 3.4: "fields references to identities" make no sense;
there is probably a typographical error there.
Section 4: diagram mangled at bottom of page 14.
Section 4.1.1 "RFC2822.Reply-To" description is inaccurate.
The Reply-To field is a suggestion by the author for a set of
addresses (N.B. not mailboxes or addr-specs) for responses to
the message. That suggestion may be overridden by the respondent,
depending on the intended purpose of the specific response. As
discussed in detail on the ietf-822 mailing list a few months
ago.
Same section, "RFC2822.Sender": "error return addresses [...]
is made by the RFC2822.Sender" NO! Never! The Sender field,
which contains a single mailbox (not an address), specifies the
mailbox of the person who initiated the message transport, if that
person is different from the author(s). It is never used in
automated responses.
Section 4.1.3: Why the introduction of angle brackets, which
are not used earlier in the document?
Section 4.1.4: "delivery is effected with POP" POP cannot
deliver (push) messages; it can only be used for message
retrieval (pull). The term "delivery" implies push (if I
personally go to a grocery store to get some items, that
is quite a different matter from "delivery" of the items
by a delivery person).
Same section & sentence: "or IMAP" IMAP also must be initiated
by the user (or user agent) for retrieval or other access to
a message store (the available operations are significantly
wider than the mere transfer for retrieval of POP).
Same section, last sentence of paragraph at the top of page 20:
typographical error "access" should be "accessed".
Section 4.1.5: Typographical error: "MUA's" should be "MUA".
Same section & paragraph (first): typographical error: "two
message store" should be "two message stores".
Section 4.2, last paragraph and sentence: typographical error:
"practises" should be "practices".
Section 6.2.4 "MUA Gateways": MUAs and gateways are distinct
entities (detailed discussion elsewhere).
Section 6.2.5 "MUA Alias Handling [...] in most MDA
implementations": MDA is correct; MUA is not.
Section 6.2.6 "MUA Mailing Lists" List expansion is not an
MUA function; a list expander is a separate function (it
might conceivably be thought of as similar to aliasing in
an MDA).
References: should be split into Normative and Informative
References sections (RFC 2223). Also, references should be
reviewed for out-of-date entries (e.g. RFC 2298 has been
obsoleted by RFC 3798); the RFC Editor has an "rfc-ref.txt"
file that provides suitable citations and indicates when
an RFC is obsoleted (or is in the process of being obsoleted).
General comments: no discussion of message fragmentation/reassembly,
inadequate discussion of use (as opposed to syntax) of message-ids.