[Top] [All Lists]

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

2005-02-07 19:02:33

Thank you for your comments. You raise some points that I think are worth 
clarifying on the mailing list.

On Wed, 22 Dec 2004 15:51:51 -0000, Willemien wrote:
  The draft is very SMTP centred it would be better to integrate other email
  systems in it.

This document is meant to describe Internet Mail and it defines this in terms 
of IETF standards.  For transit, that primarily means SMTP.  

That said, I think you will find that the next draft treats message 
transmission issues as being distinct from user-to-user issues.

  I propose to put this discussion also in the mail-NG mailing list
  It would be nice to have one overarching mail-architecture for currently
  used mail systems.
  (including mail systems that are being developed)

This has been suggested by others.  For the moment, my goal is to document what 
we have.  When we have a solid base of community agreement on that, I think we 
will be in a better position to enhance the model to cover additional 

  The draft does not mention the
  (RFC 3888) Tracking User Agent (TUA) and the Tracking Server

The document does not mention a number of interesting specifications and 
activities.  The goal of the document is to provide a framework for discussing 
the core of standard Internet mail.  This means leaving out quite a bit of 
material that is otherwise interesting.

  Some More detailed comments

  MTA -- MTA interchange with errors
   | -<+
   |   |
   V   | SMTP error (500+)
  MTA -+

You raise an interesting point.  I would prefer to include that sort of 
notation, but it would require including it for every protocol on the chart, 
since very protocol can respond with an error.

The chart is already quite busy, so my feeling is that it is better to leave 
protocol-level feedback out of it.

  (Hm drawing in ascii is not my first choice)

I am pretty sure it is not the first choice of anyone sane.  However it is what 
is required for RFCs.  This has been argued about every few years, for the last 
20 years, or so.

  Different MTA's

  There are architectional differences between MTA's

Please remember that this document is about Internet service architecture, not 
MTA software architecture. 

  I would suggest the following sub catagories

  rMTA an MTA that is named in the receivers MX list

  the final MTA deserves a special place call it the fMTA (This is the MTA
  where the lowest MX records refer to, explain that there can be more than

1. What are the required, functional differences between these MTAs?

2. It bothers me that I have left the DNS entirely out of the discussion.  I 
suspect this should change.

  The envelope ends at the MDA/MS.

The SMTP envelope ends, but there is envelope information in the rfc2822 header.

  A personal problem: our system does not fit in the architecture

  We have the system that our mail is collected by a catch-all POP3 mailbox at
  our ISP.
  Our mailserver in its turn collects the POP3 mail and redistributes it to
  other POP3 mailboxes.
  How should I call our mailserver according to this architecture?

You are using POP3 as a mail Relay protocol.  This is done periodically, but is 
very far from mainstream use, as far as I know.  Again, the architecture 
document is not trying to list every possible scenario.

  Comment about figure 1

  Why are providers mentioned?

The next version moves discussion of operators (providers) to a different 
place.  They need to be discussed because inter-provider policies and trust 
interfaces play such a major role in the actual operation of Internet mail.

  Levels in mail architecture

  There are some levels distinguisable in mail architecture

  on the top is the user (sender) --user (receiver) level, mail is made

You have anticipated exactly a change that is in the next version of the 

Dave Crocker
Brandenburg InternetWorking
dcrocker  a t ...

<Prev in Thread] Current Thread [Next in Thread>