[Top] [All Lists]

Re: draft-crocker-email-arch-03

2005-02-19 08:32:30

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
(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" 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

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.

(textual) reference to
Domain names are defined and operated through the Domain Name Service (DNS)
[RFC1034], [RFC1035], [RFC2181].

should be better placed in

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?)

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
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
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


    | SMTP
    | env
    |  |     MDA <sieve> ---------------+        |
    |  |      |                         |        |
    |  |      |                         |        |
    |  +---> sMS                        |        |
End of SMTP   |                         |        |
====+=======  |                         |        |
Retrieving    |    < pop ,imap , web    |        |
    |        MRA   < sieve> <-----------+        |
   MIME       |                         |        |
    |        rMS                        |       mdn
    |         |                         |        |
    V         |                         |        |
    +------> rMUA ->--------------------+--------+

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 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

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

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
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


----- 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


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

; <>

; <>

Dave Crocker
Brandenburg InternetWorking
dcrocker a t ...

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