Re: Email System Model

David,

These are my own technical writing methods and for this type of 
subject, this would be some of my initial inclinations as a first 
approach using a system engineering (component, blackbox, functional 
models, etc.) standpoint.
- Legends

  Very important to begin with a legend of well known
  acronyms representing components of the network.

   MTA, MUA (UA), MTA,MSA, MDA, etc, I would probably add MLS for
   Mail List Server, a very important part of the infrastructure,
   and MGS (Mail Gateway Server), etc.

- Message Structure

  I would do a basic overview of the fundamental common message
  structure in ALL networks, starting with the basic idea that
  every "Communication" system and with mail, five basic elements:

    From (Author)
    To: (Recipient)
    Subject: (TOPIC)
    Date: (Creation Date)
    Body: (content

  You can then introduce the extensions and variations to be
  discuss in more detail elsewhere.

- Transport Structure

  I would begin to talk how Messages are wrapped with Transport
  Networking layers, envelope idea, etc. which can lead to
  the next subject.

- Offline, Online, Store and Forward

  I would also touch based with these ideas as is related to
  topologies and how data is created, sent and delivered. I
  would break this down to three parts:

   - Message Creation
   - Message Transfer
   - Message Delivery

- Topologies or Functional Models

  I would then probably talk about topology and the various
  common ones, including maybe the history from centralization,
  distributed, to maybe even back to centralization. I would
  start with a general overview (like what you have),

      UA --> [ MODELS ] --> UA

  and then show expands of the various models, from simple routes
  to more interfacing domain complex.

- List of technologies

  Here I would begin to talk about the ideas that extend or
  help the process. You can list the IETF protocols here and begin
  to show these how they fit into the topologies and mail flow.

And so on, the exact order above could change of course.

If this may help, since you are targeting students, one of my first 
intros to the growing communications market, was a first edition book 
I read long ago that covered the technologies of the day (including 
BBSes) and the directions might be useful:
    Digital Communications
    Thomas C Bartee
    First Edition, 1986

Its chapter on Electronic Mail System architectures is still valid 
today, there are also discussions on email security still valid today 
(i.e. the issue of anonymous senders and the forging potential).
It might worth your time to see if there are newer editions or grab 
the old one and see how he approached the subject.
--

David MacQuigg wrote:
> Hector Santos wrote:
> > In my view, you have an over simplification and Crocker's doc is 
> > attempt to model a more complex integrated world. Its one view abeit 
> > one that attempts to prescribe a model based on STDs and RFCs.  I 
> > think it could of been done in a more readable fashion, like a 
> > Requirements/Optional Grid to start work ala RFC 1153
> Standard textbook models are much simpler than what I am proposing.  The 
> most popular book (Peterson & Davie, 4th ed.) has just a sequence of 
> "gateways", and no good explanation as to why so many are needed.  The 
> two reasons given are 1) The recipient does not want to disclose the 
> actual host on which he reads his email, and 2) The recipient's machine 
> may not always be running, and a "gateway" can hold the message until it 
> is ready to be delivered.
> What I'm looking for is a model that is almost as simple, but a better 
> foundation to understanding real systems.  We have maybe half a week in 
> a 3-unit class on Computer Networks, so we clearly can't cover all the 
> details in email-arch.
> > I do think, in my opinion, your first illustration is pretty 
> > fundamental and much easier to understand, grasp without reading the 
> > context.  IMO, Dave's doc is too overwhelming for MOST people to read 
> > - totally only useful for highly IETF trained geeks.
> My primary goal is optimizing the model for students.  A secondary goal 
> is conformity with standards.  There is always a tradeoff.  If we 
> simplify too much, students will not learn how real systems work.  If we 
> add too much detail, or use jargon instead of plain English, students 
> will learn less of the fundamentals that are needed long after passing a 
> test.
> I'm looking for constructive criticism.  If you believe the model is 
> oversimplified, give me an example of an important system that the model 
> should cover.  If you think you can improve on the terminology, give me 
> some specific alternatives.
> The model is still work-in-progress, but the most complete description 
> is at http://open-mail.org/MHSmodels.html

--
Sincerely

Hector Santos
http://www.santronics.com