On Wed, 14 Jan 1998 22:27:10 -0500 (EST) Andy Poling
<andy(_at_)globalauctions(_dot_)com>
wrote:
The fact is that you do sort of make a valid point in a backwards way, and
that point is that the MTA/MDA should *not* be running software on behalf of
the user.
Interesting. Why should the MDA not run software on the part of the user?
I can think of many reasons that doing so should be carefully engineered, but
I don't see any architectural reason for doing so. An MDA, by contract, has
to have some kind of user specific knowledge in order to do per-user
delivery. We are talking about extending that knowledge.
I think that of the problems has to do with the roles played by MTA and
MDA. MDA is a fairly recent addition to the architecture. It really has
been the advent of smart message stores that require separate delivery agents
that has led to people referring to MDA's separate from MTA's. In today's
reality, they are very different objects. LMTP is a protocol designed to
formalize the communication between an MTA and MDA as separate objects. They
have very different contracts. I think that there is some role (contract)
confusion between the two.
So, I will agree that an MTA probably should not be executing software on the
part of a user. I say this because I believe the MTA's primary contract
is to move messages from source to destination.
I propose that the MDA is responsible for final disposition of a message as
specified by the policy of the destination site. Policy at a site may
be restricted to site defined rules for disposition, or the site *may*
choose to set up default dispositions for its users and delegate final
disposition authority to the user -- all appropriately authenticated and
access controlled.
Cheers.
---
Steve Hole VP, Research and Development
The Esys Corporation EMail: steve(_at_)esys(_dot_)ca
900 10040 - 104 St. Phone: 403-424-4922
Edmonton, AB, Canada Fax: 403-424-4925
T5J 0Z6