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
capabilities.
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
....
mta--->-+
| -<+
| |
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
fMTA
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
one)
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
document.
d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net