ietf-smtp
[Top] [All Lists]

"User" confusion and incomplete description of architecture in draft-crocker-email-arch-04.txt

2005-04-05 04:38:39

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.