[Top] [All Lists]

Re: revised Email Architecture draft

2005-01-29 12:19:58

On Fri, 28 Jan 2005 12:02:10 -0500, Mark E. Mallett wrote:

  Some more random comments-

 > 4.1.4  Mail Delivery Agent (MDA)
 >    The <MDA> delivers email to the recipient's inbox.

  Or, more generally, to the recipient's mailstore.  "inbox" is usually
  a name for a specific well-known folder in the recipient's mailstore.
  The MDA might store directly to other folders; saying "inbox" implies
  something narrower than that.

 >    Using Internet protocols, ...
 >    initiative of the recipient system.  Notably, SMTP and POP effect a
 >    transfer of message control from the email service to the recipient
 >    host.  In contrast, IMAP provides on-going, ...

  I don't really get what you are trying to say here.  

yeah.  it needs cleaner language.

the point i was trying to make is that smtp and pop "move" the message from the 
remote system to the local system, whereas IMAP is able to keep a copy on the 
remote store.

I would say that
  the MDA delivers to the mailstore.  Access to the mailstore (rather than
  "delivery") may be effected via POP and IMAP.  Those are not the only
  mailstore access mechanisms; direct filesystem access would be another.

"direct filesystem" and the like are what I mean by 'local'.  this needs to be 
modified to be more obviously what is meant.

  Further, I think you've got a false distinction between POP as a
  transfer technique and IMAP as an access technique.  

This was a point of considerable debate, between me and lots of others, after 
the first draft.  I thought I had modified it to reflect rough consensus, but 
obviously need to modify it more.

(it is even possible that i lost the text that was meant to reflect this 
change.  anyhow, i'll fix it.)

  One perspective of "end-to-end" is that the receiving end is the first
  mailstore delivered to (for those messages that do indeed end up in
  mailstores, which is the majority.)  All other operations on email after
  that delivery are mere manipulations of delivered mail.  

Your qualifier "one perspective" is the most important point.  What is 
increasingly clear is that "end-to-end" is a very useful term only if one is 
VERY clear about defining the end-points, since the choice of where they occur 
varies enormously, depending upon the semantics of the service AND the 
configuration of its use.

One reason for adding the construct of Administrative Domain is tha there are 
some functions that exist within an Administrative domain, but can occupy 
different places within it.  From a global perspective, it does not matter 
which of those different places it resides in, as long as it is within an "end" 
administrative domain.

With that
  perspective, POP/IMAP and the like are probably better covered by an
  "access" category (Actor:  Recipient) which would include not only
  reading email but moving email from one delivered mailstore to another.

The earlier debate, that I referred to, seems to come from exactly the issue of 
distinguishing delivery from access.  My own preference is to make an 
architectural distinction between delivery and access but my reading of 
community consensus is, instead, to view delivery as the architectural item and 
access as a usage item.  That is, either pop or imap can be used for delivery 
and either pop or imap can be used for access.

Hmmm.  Maybe I can still reflect this via an architecural point.  It occurs to 
me that the "Internet Mail Protocols and Services" has the seeds of this 

 > 5.1
 >    Direct envelope addressing information, as well as optional transfer
 >    directives, are carried in-band by MTAs.  All other envelope
 >    information, such as trace records, is carried within the content
 >    header fields.

  "in-band" is not a clear term because there are multiple bands.  

The message object is the RFC2822 thing.  The SMTP Envelope is parametric 
information not carried as part of the message object.  It is carried within 
the transfer protocol.

That is what I mean by "in-band".  So now the question is how to say this more 

When I
  read "in-band" I think "mixed with the message," e.g. in the message

close.  i meant 'mixed with the protocol RATHER THAN the message'.

one thing that is now eminently clear to me is that 'in-band' is entirely the 
wrong term.

  This probably gets back to the whole "envelope/SMTP envelope/message"
  brouhaha from the prior round of discussions.  (Personally I thought
  that X.400 made some good distinctions here, e.g. with the "P1 Envelope"
  and "P2 Envelope" -- then again I haven't cracked open the old redbook
  in, um, decades.)

On the average, I believe the OSI work often elucidated very important issues.  
It's how they solved them that was the problem.

In the latest round of the architecutre, the obvious example is use of 
Administrative Domain.  X.400 used it as an addressing construct.  In the 
architecture document, I am trying to use it, instead, as an operations and 
routing construct, invisible to addressing.

 > 6.2.5  MUA Alias Handling
 >   Notably it does not typically change the RFC2821.Mailfrom

  Realizing that you said "typically" : yet some alias implementations will
  rewrite the return-path information, e.g. in sendmail;

Well, frankly the goal for this sub-section is to define an MUA-level function 
that is essentially on a par with MTA-level relaying.  It uses a new RCPT-To 
address, but does not otherwise alter responsibilities for the message, for 
notifications, etc.  

Perhaps that is overly strict.  The question, then, is what boundaries for the 
function represent community rough consensus?

And what is the next level of MUA funnctionality?  Do we immediatley jump to 
"gateway" where any action at all might be done, or is there (another) 
intermediate role that does more than the restricted aliasing but less than 

In other words, what are the gradations of labels for MUA-related re-posting 
that are useful for the community?

  And I believe that it is very common to use this "owner" rewriting when
  expanding to more than one address, in order to take local responsibility
  for problems with delivery to any of them.

And isn't that the essence of mailing list functionality?

Dave Crocker
Brandenburg InternetWorking
dcrocker  a t ...