Sorry I still have long comments
They re over a broad range of topics.
But the draft itself also covers a broad range.
You do not have to agree with me in every thing.
But also feel free to convince me.
I'll follow the sequence of the draft
<draft-crocker-email-arch-03>
(the HTML version)
1 Introduction
In your idea users and MUA's are outside (and not part of) the
Mailhandling system.
For users I agree fully with that, but for MUA's I am wondering.
In my opinion MUA's are part of the mailhandling system.
Some motivation for this:
- (practical) They supply the MIME encapsulation of the message.
- (philosophical) They do not have a function outside the mailhandling
system. (without an mailhandling system there is no use for a MUA)
I want to elaborate the last point because it come back more often. (and
than I only have to point to this point)
I would use the term User only as entities outside the mail system.
Everything that only has a function within or no function without e-mail is
not an user.
originators can use other means of communicating so they are users.
gateways have no function without e-mail so they are not users.
"End-to-End"
"End-to-end" should mean from user to user, from keyboard to screen or
something similar.
Ideas that have a restriction in this are missing the basic point. Mail is a
medium for connecting users. Actors outside the mailhandling system.
1.1 service overview
Small point: what is an email object? there is no description of it.
Instant messaging systems also fit in the description.
I think the basic difference between Mail an IM (instant Messaging) is that
for email users do not have to be online at the same time.
Section 2
Figure 2: Relationships Among User Actors
What is the meaning of the lines from recipient to mediator ?
The line from recipient to originator seems to represent a message delivery
notification.
2.1.3 mediators
see section 5
Figure 3: Relationships Among MHS Actors
Notice should be Notifications Handler
( If I read it correctly)
2.2.1 source
See my discussion about the MUA as part of the Mailhandling system earlier.
2.2.4 gateways
Gateways are NOT users.
see description of users earlier.
3.1
(textual) reference to
Domain names are defined and operated through the Domain Name Service (DNS)
[RFC1034], [RFC1035], [RFC2181].
should be better placed in
3.2
3.3 Message Identifiers
Not conform RFC 2822 section 3.6.4
(the right side is not always a domain)
Users do not assign this identifier.
It may be assigned by the MUA but it is hidden from the user.
3.4 Identity Referencing Convention
(textual) this section should be put in part 1. (new section)
section 4
Figure 5: Protocols and Services
very general remarks
Put an user at the top and at the bottom of the figure. (I think that every
figure should be an end-to-end figure, exceptions are if it adds more than a
couple of lines to it)
4.1 Message
Delivery Status Notification (DSN):
in figure 5 MSA receives the DSNmessages in the text it send them. (and
where it is supposed to send them to?)
4.1.4
additions and changes
Layer Field Set By see
Content body Originator User
Message Body MIME Header oMUA
Message From oMUA
header Sender oMUA
fields Reply-To oMUA
To, CC, BCC Originator User
Message-ID oMUA
Received MSA, MTA, MDA
Return-Path MDA, from MailFrom
Resent-* Mediator User
SMTP HELO Latest Relay Client MTA
MailFrom oMUA
RcptTo oMUA
IP IP Address Latest Relay Client MTA,MDA
main changes
Names refer to names in section 4
split originator in oMUA and Originator user.
Added level content.
Notice that the from address is set by the oMUA and not by the originator.
(I am not sure about this but it is the most common case)
4.2 Mail User Agent (MUA)
RFC2822.From and
RFC2822.Reply-To
fields are set by the oMUA not by the originator.
In as far I am correct MUA's are using the SMTP or a SMTP deviate so do have
RFC2821 fields. but they are not mentioned here.
4.4 Mail Transfer Agent
Missing is that there are MTA's that only forward to specified MTA's without
using MX records at all.
Or maybe this is a primal distinction between MTA's and MSA's
I am getting more and more confused an email client that sends al its mail
by SMTP to the ISP's mailserver is that:
a an MUA
b an MUA-MSA
c an MUA-MSA-MTA
d something else
4.6 Message Store (MS)
I would like to put a new suggestion in for this and the bottompart of
figure 5
suggestion
MIME
| SMTP
| env
| | MDA <sieve> ---------------+ |
| | | | |
| | | | |
| +---> sMS | |
End of SMTP | | |
====+======= | | |
Retrieving | < pop ,imap , web | |
| MRA < sieve> <-----------+ |
MIME | | |
| rMS | mdn
| | | |
V | | |
+------> rMUA ->--------------------+--------+
|
rUser
I came to this because the old MS always must be local to the MDA while the
rMS mostly is local to the rMUA.
And I liked the idea of a MRA agent.
New functional components
sMS Smtp final message store
MRA message retrieval agent
rMS receiver message store
rUser receiver of the message (see comments about figure 5 earlier)
4.6 The sMS is local to the MDA
Texts for the new components
4.7 Message Retrieval Agent (MRA)
The MRA message retrieval agent retrieves the mail from the SMTP final
Message store and stores it on the local machine of the recipient-user. this
can be as a download (pop3) or as synchronising(Imap4) or even a
virtual(Webmail) operation.
Webmail and Imap in general keep the message in the SMTP final message store
while POP3 deletes it.
4.8 receiver message store rMS
The rMS is the final store for the message.in Pop3 and Imap this message
store resides in the local computer of the user. and is available to the
user for manipulating, opening etc.
In webmail this store is virtual.
5 mediators
I see differences between User mediators and Non-user mediators. (see for a
discussion about users the beginning of this comment)
I would like to suggest to split the mediator group along these lines.
for the time being lets call user mediators- Moderators
and non-user mediators Mailmanagers
(I am very open for other names but could not think of anything more
suitable)
5.1 Alliassing is a mailmanager
5.2 resending is a mailmanager
5.3 a mailinglists if not moderated is a mailmanagers
5.3 a mailinglists if moderated is a moderator (that is why I choose that
name)
5.4 a gateways is a mailmanager
5.5 a security filter is a mailmanager
an auto replysystem is a mail manager etc..
---
A more general comments
I am afreight that this draft will eventually create more confusion than it
solves.
There need to be a dictionary section that links "common language" email
terms and RFC terms to the terms we use in this draft.
for example the
RFC2821 MTA is a hybrid from the MTA and the MDA.
RFC2821 UA is in this draft called an MUA
and then i am not even speaking for common language names:
an email client is a MUA MSA and/or MTA
an (e)mailserver is an MTA MDA and/or sMS
It will be a nice excercise to make and such a dictionary and it will surely
lead to more detailed changes.
It would be good if this draft will be a Standart track RFC instead of an
informal one
Willemien
----- Original Message -----
From: "Dave Crocker" <dhc(_at_)dcrocker(_dot_)net>
To: <ietf-smtp(_at_)mail(_dot_)imc(_dot_)org>
Sent: Thursday, February 17, 2005 3:50 PM
Subject: draft-crocker-email-arch-03
Folks,
I think (hope) the email architecture document has reached a stable point,
in its attempt to describe the current service.
The latest version has substantial changes, but I think they are
refinements from the previous version and reflect feedback I've received. Of
course, any additional comments are more than welcome, and I have no doubt
there can be debate about lots of the details.
But the goal is to get this published sooner, rather than later, so I am
hoping this is the last major revision.
I've submitted the doc to the i-d folks. In the interim, you can access it
at:
; <http://bbiw.net/specifications/draft-crocker-email-arch-03.html>
; <http://bbiw.net/specifications/draft-crocker-email-arch-03.txt>
d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net