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.
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?
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.
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.