The email architecture draft uses the terms "User", "Mediator",
"Gateway", "Author", and "Originator" in ways which are quite confusing.
o Section 2 lists Actors: user/MHS/AU
o Section 2.1 subdivides User Actors as Originator/Recipient/Mediator
(but doesn't mention resenders and respondents)
o Section 2.1.1 equates Originator and Author (but as previously
noted, fails to distinguish Author and Sender)
o Section 2.1.3 says that list expansion software is a Mediator (i.e.
a User)
o Figure 3 (appropriately) shows Gateways as part of the MHS
o Section 2.2.3 reclassifies (Administrative) Actors as "User
Mediators"/"MHS Relays"/"Packet Switches" (confusing human users
with list expansion software and classifying low-level Data
Link/Physical layer hardware as Actors)
o Section 2.2.4 says that Gateways are hybrids of Users (but not
listed in other section 2 descriptions of users) and Relays
o Section 4 is headed "Services" but discusses messages, agents, and
stores.
o Section 4.2 says Mediators (previously classified as Users) are
MUAs (so in effect there is no distinction among a human user, a
software MUA, and mailing list expansion software).
o Section 5 reverses that and again classifies a Mediator as a User.
o Section 5.1 says that aliasing is readdressing (which is also what
list expansion is, as noted in RFCs 822/2822)
o Section 5.1 also equates aliasing with MDAs (probably justifiable,
but then the same applies to list expansion, which has previously
(separately) been classified as MUA and as User)
o Section 5.3 says that a mailing list is an Actor and is an
elaboration of a redirector or resender (sect. 5.2)
o Section 5.4 says that a Gateway (classified as part User by sect.
2.2.4) is a type of relay or MTA.
Taken together, those sections say
o list expander = mediator = MUA = user
o list expander = actor ~ redirector = resender
o aliasing = readdressing = redirecting = MDA
which further implies that an MUA and an MDA are very similar.
The draft also creates confusion between separate layers, conflating
human users (which are strictly not part of layering models) with
application layer UAs, while artifically separating list expansion
(really Transport-level redirection) from aliasing (also Transport-level
redirection).
There appears to be no mention of topological considerations, and
gateway architectural functionality appears to be shown as optional
(Figure 3) or missing (Figures 4, 5).
Consider the following simplified diagram for further discussion (view
with a monospaced font):
+----------------------------------------+ (Mediate/Respond/Resend)
v (Respond) /(Mediate/Resend) ^
user (Author)-->User (Sender) User (Recipient)
____________/\ ^
/ / ______/ \ | _______________
oMUA/ / / \ [Filter]~~rMUA
|-(--+---+--------+--+ /^\ \ ^ Application
|/ | | | / | \ \ | _______________
v v v _ v / v \ \ v
MSA--MTA--Gateway-(_)-Gateway--MTA--MDA--[MS] Transport (MHS)
\__/| /| \____/\ \______/ |
\__)__|_)_________/ \ |
|____|____________+<-----------+ (Alias/list expansion)
^ [ Possible MX hosts ] (a.k.a. "mail exploder")
| [Possible recipient domain Administrative Unit]
\[Sender Administrative Unit]
I believe the following statements to be accurate:
o message author(s) and sender are architecturally distinct (RFCs
822, 2822) but the sender may (by coincidence) be an author.
o a message sender initiates message transport either by using an
Application layer UA or by using Application layer software (e.g.
telnet client) to connect to an MSA, MTA, or Gateway. MSA
connection is determined by local configuration. If an MTA relay
(or gateway) not affiliated with a recipient is used, that might
also be determined by configuration. MTA or Gateway affiliated
with a recipient (by Sender, oMUA, MSA, relay, or gateway
determination) is located via DNS MX records.
o messages may transit zero or more non-Internet transport "clouds"
connected by gateways
o an MSA (when used) is operated by an Administrative Unit which is
separate from the Recipient (except by coincidence), and may be
associated with the Sender (as shown) or may be operated by a third
party (e.g. an ISP)
o MSA, MTA, Gateway, MDA operate architecturally at the Transport
layer, i.e. below the Application layer and above low-level data
transfer layers (details depend on whether one is using a 4-, 5-,
or 7-layer model)
o message delivery as directed by MX records points to hosts
associated with an Administrative Unit which is not (except by
coincidence) affiliated with the sender; that Unit may be
affiliated with the recipient or with a third party (e.g. an ISP)
o Architecturally, all messages must pass through at least one
Gateway (which may be implemented in conjunction with an MTA, MDA,
or even MUA). [this is necessary to accomplish MIME
message/partial reassembly as detailed in RFC 1344]. As reassembly
(RFC 2046) is a rather complex process that involves message
modification, the operative unit is unquestionably a gateway [it
might be useful to differentiate different types of gateways,
though that is not done in the simple diagram above or in the
draft]
o message/partial reassembly must occur on the recipient side of the
all MX hosts for the recipient domain [all fragments must pass
through a single gateway for reassembly]
o filtering operates at the Application layer rather than transport
layer
o [N.B. no discussion here of intermediate layers such as transfer
encoding (Presentation layer) or security wrapping
(signing/encrypting)]
o filtering must occur after message reassembly (Again see RFC 1344
and see also http://www.kb.cert.org/vuls/id/836088 to see what can
happen when that architectural principle is ignored)
o filtering can be accomplished at several places
o internally, gateways perform some operations at application level;
that is where content is mangled (a.k.a. modified) [of course, mere
relaying also involves application-level operations (e.g. DNS
lookups); ditto for MSA and MDA tasks]
o aliasing and list expansion (RFCs 822, 2822), also known as "mail
exploder" (RFC 1208), takes place at Transport level, with
additional "hops" as determined by MX records associated with the
domain(s) of the (new) [SMTP envelope] paths resulting from
aliasing or list expansion; as with initial injection into
transport, those MX hosts might be classified as MTA or Gateway.
These are automated Transport-level processes not requiring direct
intervention of a (human) User.
o aliasing and list expansion can only take place where the
local-part of the (SMTP envelope) path is interpreted;
architecturally that is at an MDA
o (human) user operations such as resending, responding, and active
mediation take place at (human) user level, interacting with
Application layer software and some sort of UI.
o the message store doesn't fit very well with this diagram; it can
be envisioned as being part of the MDA or rMUA
Especially, the draft description of mailing list expanders as users is
highly confusing. A description of the mail system architecture is
incomplete unless it discusses the gateway vs. message fragment
reassembly issues documented in RFC 1344, ignorance of which has led to
security problems.