[Top] [All Lists]

[Another long] commnets on draft-crocker-email-arch-01

2004-12-22 09:02:43

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

Also at the end became a little meshy, 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 ne something like

MSA <---+
 :      | dsn (delivery status notification)
 | -<+
 |   |
 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 catagories

rMTA an MTA that is named in the receivers MX list

the final MTA deserves a special place call it the fMTA (This is the MTA
where the lowest MX records refer to, explain that there can be more than

Message Tracking Model  (RFC 3888) also uses 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
they have an 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/MS.
But allready long before that the enveloppe has  been shrinking. Only
recipients that are in the downstream part of the MTA-MTA link stay in the

Expandable architecture
Structures in the real wor;d are always more complex than the structures on
But this draft should have the structural elements to discribe 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

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

Levels in mail architecture

There are some levels distinguisable 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  ect.

below that is the

MSA -- MDA level

Some levels lower are the
bottum levels

MUA --> MS --> MSA
MDA --> MS --> MUA

I haven't filled in all levels but it seems a handy instrument to look and
name them in  the architecture.


A dictionary from "old" names to the new names would be useful

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

I hope you can use my comments.