[Top] [All Lists]

Re: [long] commnets on draft-crocker-email-arch-01

2004-12-21 09:56:36

 > legacy term.  orig/recip are from the X.400 days and have a pretty high
 > installed base of usage.  I do not see our community having a dominant
 > practise of using author -- although it does seem to have a high enough
 > occurrence to cite the term also -- and this document is not trying to
 > establissh new practise.

  Hmm. My problem is that "originator" seems ambiguous between "author(s)"
  (i.e. 822.From) and "submitter" (822.Sender).


however, given the extensive of using the term originator, i'm inclined to 
change it only if there is a groundswell of popular preference expressed.  

again, note that the goal for the document is to document, not really be 
creative or even persuasive.  it is trying to capture the current community 
consensus on existing email architecture (and terminology).

 > I definitely am used to thinking of protocols as residing at boundaries,
 > pretty much by definition, and I hope we are VERY careful about
 > maintaining the distinction between the abstract architecture, versus
 > concrete implementations.

  I agree. However in the ugly tables you say that the envelope is created
  by the MSA, but from a the protocols point of view (and from the point of
  view of most software these days) the MUA must create the envelope in
  order to be able to talk to the MSA. 

saying anything that means the msa always creates something is a writing error. 
 my intent is to say that it enforces things and *might* create/modify things, 
in order to do the enforcing.

 > > MDA:

 > The only question this leaves is about choices for delivery protocols.
 > I think the answer is reduced to <local> or SMTP.

  LMTP is intended for this role.

The document is trying to capture actual practise.  That's why this particular 
diagram shows lists of candiates.  It is my impression that LMTP is not used 

Also, on review, the MDA-MS, MS-MS and MS-MUA segments can have quite a bit of 
overlap in the set of protocols they use.  In particular, POP and IMAP do get 
used in each of the segments, I believe.

 > >  Sieve should be mentioned as a means for controlling the MDA.
 > The diagram shows sieve as feeding into the MDA.

  Hmm. Sieve's a scripting language. What architectural entity interprets

The diagram shows the sieve data being given to the MDA.  The intent is to 
indicate that the MDA does the interpreting.

 > >  Is it worth distinguishing online mode and local message store access?
 > although the operational difference is important, how does that affect
 > the architecture?

  Whether an Internet protocol is being used or not.

Since this is a document about Internet mail, references to non-Internet stuff 
is intentionally limited.

What, specific change are you suggesting?

Note that the diagram already shows two message stores.  One of the reasons is 
that the second one can be used offline.

  The details of communication with the message store and where it resides
  etc. in this section are rather complicated, because a lot of the
  functions can be implemented in either or both of two places (on the
  server and/or the client), with or without network protocols in between.


 > >  Sieve should be mentioned as a means for controlling the movement of
 > >  messages in offline mode under control of the rMUA.
 > please elaborate.

  In the IMAP world, the MDA interprets a Sieve script to determine which
  mailboxes to deliver the message into, and the MUA talks IMAP to the
  message store to access the email.

I think the problem is that the document shows sieve in the diagram but does 
not discuss it.  I need to add some text, along the lines of what you are 

  I think it's essential to have a word to describe the SMTP commands that
  occur before DATA (i.e. MAIL FROM and RCPT TO). See above in the
  discussion about MSA for an example. I'm not sure what you mean by
  "user-to-user message" and how it can be used to draw a line through the
  message header. 

This is the major architectural weakness to Internet mail.  We blurred the 
distinction between user headers and handling headers.  

User-to-User is the stuff that the originator creates with the intent that it 
be consumed by the recipient.  

In contrast, the handling information is created for consumption by the 
handling service or by the handling service, primarily for consumption by email 
operators or for operational analysis.

The Subject: is probably included. 


Are the addressing
  fields included? 

Ignoring the MUA/MSA protocol issues, where the MSA might get its rcptto list 
from the to/cc/bcc fields, the to/cc/bcc fields are intended for consumption by 

What about instructions to the MSA (BCC:)? 

depends upon the particulars of the mua/msa interface.

What about

It really is not used by the handling system and very much IS used by 


mixed bag, on this one, i think.


operations use.

When a message is Resent- are the trace
  fields from the original message now part of the "user-to-user message" or

Good question.  I do not know what constitutes "prevailing" practise.  My own 
view is that old trace information should be dropped, since a re-send is 
creating an entirely new message.

 > >  There should also be a section on MTA firewalling, to distinguish it
 > >  from gatewaying.
 > I'm inclined to agree, but let's explore this a bit.  What is the
 > architectural role of a firewall?  I understand it's operational import,
 > of course, but how does this relate to an/the architecture?

  We need a word to talk about the parts of the MHS that might mangle
  messages. You mentioned fleshing out the operational side of the
  architecture, so that we can talk about outgoing relays and incoming MXs
  etc. and in this context the border firewall MTA is becoming practically

Historically, the email term for an entity that transforms content is 'gateway'.

A gateway is an entity that does message (semantics) conversions.

 > >  MUA Gateways:
 > >
 > >  Aren't these really at the MTA level? Putting them at the MUA level
 > >  implies a "final delivery" event before the message reaches the
 > >  gateway.

That's right.  A gateway sits between heterogeneous environments and does 
conversions to reconcile differences.  By contrast, a relay makes no changes to 
message semantics and merely takes the message off one transfer link, makes a 
routing decision, and queues the message for another transfer link.

Relative to the underlying handling service, when there is a gateway it usually 
take formal delivery creates a new message.  As I said, what makes gateways 
interesting -- besides the impossible task of trying to preserve all the 
semantics -- is that it is possible that they emulate a continuation of the 
handling service, through the gateway.  This is difficult and I believe it is 

 > Gateways are strange beasts, indeed.  My experience forces me to view
 > them as hybrid MTA/MDA/MUA devices.  The basic point is that a gateway
 > messes mightily with the content.  So it is not merely a variant of an
 > MTA.  On the other hand, your point about the possibility of deferring
 > the formal delivery event to a point after the gateway is well taken.

   From the content mangling point of view they are close to firewall MTAs.
  They are clearly inside the MHS boundary so are not MUAs.

I am not used to having the term firewall refer to the job of content 
conversion.  I am used to it strictly meaning a security function of detecting 
attacks and rejecting them.

That a firewall might do the 'rejecting' by selectively modifying the content 
is certainly true, but it's secondary to the task that is referenced by the 
term firewall.

My point is not to be abstractly pure or to deny the reality of what is done in 
existing practise. Rather I want to make sure the architecture is as clean as 
possible in distinguishing roles and responsibilities.  In this regard, one 
thing we keep needing to juggle is the difference between the conceptual 
architecture versus implementation choices that might cross architectural 
boundaries (and/or blur them).

Dave Crocker
Brandenburg InternetWorking
dcrocker  a t ...