First of all I want to praise your work. It is useful to have such a draft.
I am not an email specialist so please check everything thoroughly before
accepting.
Also at the end became a little messy, but I still hope you can use it.
Missing points
The draft is very SMTP centred it would be better to integrate other email
systems in it.
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)
The draft does not mention the
(RFC 3888) Tracking User Agent (TUA) and the Tracking Server
Some More detailed comments
MTA -- MTA interchange with errors
the SMTP errors are missing
should be something like
MSA <---+
|
: | dsn (delivery status notification)
MTA--->-+
| -<+
| |
V | SMTP error (500+)
MTA -+
(HM drawing in ASCII is not my first choice)
Different MTA's
There are architectional differences between MTA's
I would suggest the following sub categories
rMTA an MTA that is named in the receivers MX list
fMTA
the final MTA deserves a special place (This is the MTA
where the lowest MX records refer to, explain that there can be more than
one)
Message Tracking Model (RFC 3888) also uses
Intermediate Message Transfer Agent (MTA)
Foreign Message Transfer Agent
Gateway Message Transfer Agent (GW-MTA)
I myself was more thinking about a catogarisation of MTA's on the bases if
whether they have or have not a RDNS, whois, MX or other DNS record.
Message stores
I think there is reason to put an oMS (originator message store) between the
oMUA and MSA. MUA's store their message and it looks functualy better to
actually place a message store there.
(messages in this store possibly have a Bcc header)
The envelope ends at the MDA or MS.
But already long before that the envelope has been shrinking. Only
recipients that are in the downstream part of the MTA-MTA link stay in the
envelope.
Expandable architecture
Structures in the real world are always more complex than the structures on
paper.
But this draft should have the structural elements to describe them.
Lets start with:
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?
An Catch all mailbox in this situation needs special care because we need
the SMTP envelop to redistribute the email properly. Only very few ISPs
acknowledge that. An catch-all mailbox in this situation is more than just a
anything alias.
(This is only one example for expanding figure 2 but figure 2 should be
expandable to include structures like mine that actually exist in the real
world)
Comment about figure 1
Why are providers mentioned?
They do not seem to have any particular function.
If they have different architectual functions they should have different
names.
Levels in mail architecture
There are some levels distinguishable in mail architecture
on the top is the user (sender) --user (receiver) level, mail is made to
give a message from one human user to another human user.
below that is the
MUA -- MUA level this level is about MIME encryption etc.
below that is the
MSA -- MDA level
Some levels lower are the
bottom levels
MUA --> MS --> MSA
MSA --> MTA
MTA --> MTA
MTA --> MDA
MDA --> MS --> MUA
I haven't filled in all levels but it seems a handy instrument to look and
name them in the architecture.
Dictionary
A dictionary from "old" names to the new names would be useful
examples (This is definitely not a complete reference)
UA is used in many RFC's but in this one it is called a MUA
A Local Delivery Agent (LDA) RFC 3888 is now called a Mail Delivery Agent
(MDA)
I hope you can use my comments.