ietf-smtp
[Top] [All Lists]

Re: Re: draft-crocker-email-arch-03 Users, MDA and administrative domains

2005-03-07 15:14:23

Made me think again
Can we think of another name for the MDA?
And i think that a message is not a service. (see further in this email)


On Sat March 5 2005 09:54, willemien(_at_)amidatrust(_dot_)com wrote:

But i disagree with:

Section 2.1 refers to the MHS as monolithic; it is not --
it is composed of autonomous agents (MTAs, MSAs, MDAs,
gateways, list expanders) and a user may receive a delivery
notification of some sort from any of those agents.

For users the (image of the) MHS is monolithic.
In This section I would keep it that way.

I specifically mentioned delivery notification because a
sender may receive such a notification from any of the
distinct message-handling components, and the significance
of such notifications (and the user's reaction) depends
on the component.


A that makes it much more clear but I still disagree.
section 2 is a (very) general discription of the mail architecture.
error messages nitty gritty belongs elsewhere.
 

Maybe it is better to create a seperate section on messages with subsections 
for 
- Delivery Status Notification 
- Message Disposition Notification 
- Message Filtering (SIEVE)

I would suggest to break section 4 services in to 2 sections
one for messages  and one for services (or agents)
Messages are things that are transfrered.
Services are the things that allow that things to happen. 

the structure becomes then

4 messages
4.1 message components
4.1.1 Envelope
4.1.2 Message Header Fields
4.1.3 Body 
4.1.4 Identity References in a Message
 (but this section should use the names used in the section on services)

4.2 Special messages
4.2.1 Delivery Status Notification 
4.2.2 Message Disposition Notification 
4.2.3 Message Filtering (SIEVE)

5 services

rest needs renumbering.



I like the concept of MDA and want to distinguish it more clearly from the 
MTA.
I would suggest the MTA only works with domain part of the message, the MDA 
with domain parts and local parts.
So the MTA does the transfering, the MDA does all the rest.
If an operation needs the localpart of the address it is a MDA function.
(auto responders, mailinglist actions, the SMTP VRFY, EXPN, ETRN commands 
ect.)

Architectonal ideas
Eexcept with LMDP, an MDA is always hiding behind an MTA.
LMDP uses SMTP-Direct (sending to a fixed ip address, not to a public MX 
record)

LMTP?

Sorry slip of the finger.


There is no direct contact between MTA outside the administrative domain 
and the MDA in that administrative domain.

Architecturally (or topologically), an MDA can only appear
on the recipient side of all MX hosts for the recipient's
domain. There may, however, be MTAs in that area (some
administrative entities configure their systems with a
border MTA for aliasing, etc.).



Within one administrative domain globaly valid MX records are NOT used.
MX records are used for transfer between seperated administrative domains.
within an Administrative domain SMPT-direct. (sending to only one MTA) is 
used.

Except for list expansion and other forwarding operations
that extend beyond the (DNS) domain.


List expansion and forwarding are done by the MDA, (they depend on the 
localpart of the email address) the MDA sends the message to an MTA and the MTA 
sends it to other domains.



What is your standpoint about Users in general?

Users of email (authors, senders, moderators, and recipients)
are part of the end-to-end communications path. Message
body and header originator/origination-date/destination/
information/resent fields (RFC 2822) [and some extension
fields] are exclusively for use of the users (and as assisted
by their UAs) and should never be altered by the MHS.