ietf-smtp
[Top] [All Lists]

Re: draft-crocker-email-arch-03

2005-02-25 07:55:21

thanks for your reply


I'll first elaborate about my new parts to chapter 4

(And Yes, I am elaborating the MS-1 and MS-2)

First of all
I renamed the sMS to rMS (recipient Mail Store)
and the rMS to lMS. (local Mail store)
I think these names are a better indication of what they are.
But I am open for better names.

I changed the end of SMTP transfer to end of push transfer.


the figure then becomes:

   MIME
    | SMTP
    | env
    |  |     MDA <sieve> <--------------+        |
    |  |      |                         |        |
    |  |      |                         |        |
    |  +---> rMS                        |        |
End of push   |                         |        |
transfer      |                         |        |
====+=======  =                         |        |
retrieving    |    < pop3,imap,webmail> |        |
 transfer    MRA   < sieve> <-----------+        |
    |         |                         |        |
   MIME      lMS                        |       mdn
    |         |                         |        |
    V         |                         |        |
    +------> rMUA ->--------------------+--------+
              |
             rUser

I came to this because the old MS always must be local to the MDA while the
lMS is local to the rMUA.
And I liked the idea of a MRA agent.


New functional components
  rMS   recipient message store
  MRA   message retrieval agent
  lMS   local message store
  rUser receiver of the message (see comments about figure 5 earlier)

Texts for the components: (including 4.6 rMS)


4.6 rMS recipient Message Store

The rMS is where SMTP does final delivery
it is a message store as mentioned in RFC2821 section 2.3.3.
This store SHOULD always be accessible (local) to the MDA.
(NOT to the rMUA)
It is the end of the SMTP store-and-forward transfer.


4.7  Message Retrieval Agent (MRA)
The MRA and the lMS are to overcome what is called the lacking of the
resource known as "connectivity".
(RFC  1939 section 1 introduction) where this resource is not lacking
(webmail) the MRA and the lMS are not needed.

The MRA message retrieval agent retrieves the mail from the recipient
Message Store and stores it on the local machine of the receiver-user. this
can be as a download (pop3) or as synchronising (IMAP4)
 Imap in general keep the message in the  rMS while POP3 deletes it.

The MRA works on request of the receiving User.
The MRA links the computer to the MDA and collects the messages.
There is no need for a connection between the MRA and the rMS if the MRA is
not retrieving messages.


4.8 local message store lMS

The lMS is the final store for the message.in POP3 and Imap this message
store resides in the local computer of the MUA. and is available to the
user for manipulating, reading etc.
In webmail this store is virtual.


4.9 receiver Mail User Agent  rMUA

(text copied from 4.2)
The Recipient-side rMUA works on behalf of the end-user Recipient to process
received mail. This includes generating user-level return control messages,
display and disposition of the received message, and closing or expanding
the user communication loop, by initiating replies and forwarding new
messages.


Other points

As the document describes, the purpose of distinguishing MUAs from the
Mail Handling Service is to separate user services from transfer services.
The MHS only concerns transfer.  The MUA is not part of the transfer
service.

I think we have an philosophical point here
I see email architecture as including everything between
Originator-user-content and recipient-user-content.

You seem to put a layer between the user and the Mailhandling system. (The
"message posting layer" or mailforminglayer that consists of the MUAs and
that makes the user-content transferable trough email)
In your scenario the mailhandling system is then what I would call the mail
transfer system.

I think it is better to have an overall view. where the mailposting layer is
part of the greater mailhandling system.
I thought this draft was about the general email architecture not about a
more limited email transfer architecture.

It is true that the draft says

The original distinction between user-level concerns and transfer-level
concerns is retained,

But I think is time to remove or at least address that distinction as well.
A RFC about email architecture should address both levels and if possibly
integrate them.

The purpose of an architecture is to show *relationships* between
components.  It is not possible to do that if all the pieces are treated as
part of the same activity.

That is  exactly the point are MUA's part of the "email" activity or not?

Treating the MUA as representing the user is creating confusion and not
creating clarity.
(what about an user with 2 MUA's, what is a common scenario in IMAP.)


Other points 2

about automobiles and the road system.
autos are pretty useless without roads. (at sea, in a swamp, in the
mountains) and if auto's where designed without having roads in mind they
would look quiet different.



I was not clear in my remark about the
4.1 message
Delivery Status Notification (DSN):

the text mentions DNS-messages coming from the MSA but the figure does not
show an DNS message arrow coming from the MSA.




 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.

As I've noted a few times, there are many variations that are legal and are
done.  This document is not trying to >describe every possible scenario,
merely those that are most common and use standardized techniques.

These are the only two proper standardised possibilities I know.
Or (simply) SMTP to one server or (smartly) SMTP to many servers with MX
records.
And they are both widely used.
(A ISP interception of SMTP to an other server is NOT a recommended
practice)



Instant messaging systems also fit in the description.

generally, yes it does.  for the architecture document, the baseline
definitions come from rfc2821 and rfc2822, so it's clear this does not apply
to IM.

Was there a need to distinguish IM from email In the time of RFC 2821 and
2822 ?
With the possibility of creating hybrids it is nessesary to distinguish
email from IM.


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

b or c, depending upon the operational configuration of the ISP.

Can you explain this more in detail??
This is meant as a general remark about how to link real life entities (and
entities in other RFC's) to the entities in this document.


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