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:
| | MDA <sieve> <--------------+ |
| | | | |
| | | | |
| +---> rMS | |
End of push | | |
transfer | | |
====+======= = | |
retrieving | < pop3,imap,webmail> | |
transfer MRA < sieve> <-----------+ |
| | | |
MIME lMS | mdn
| | | |
V | | |
+------> rMUA ->--------------------+--------+
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
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
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
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
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
(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
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
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
And they are both widely used.
(A ISP interception of SMTP to an other server is NOT a recommended
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
Was there a need to distinguish IM from email In the time of RFC 2821 and
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
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.