On 14-feb-04, at 4:46, Richard Welty wrote:
This may or may not be controversial, but I propose that a
requirement for sane operations is that mail-ng be single hop.
there are various good reasons why an organization (corporation,
school, government body) might want internal hops for outbound
mail.
I think a single hop "requirement" is a red herring.
The MUA-(MTA){2,}-MUA way of doing things is so ingrained in our mail
universe that it seems like the natural order of things. However, there
are good reasons to do things differently.
MUA-MUA makes sense in ad-hoc networks or when the users are in close
proximity to eachother but not to their MTAs. MUA-MTA-MUA makes sense
in situations where the sender doesn't have an MTA at its disposal,
even though we generally don't like this today since this is the way
most spam is delivered.
I think the reason to favor a MUA-MTA-MTA-MUA model would be that the
receiving MTA would then be able to enforce the user's policies.
However, this is only one way to implement such a requirement, and
limiting mail flow to this model doesn't automatically have this
effect. It would be much better if the MUA were able to participate in
the reception of all messages, in which case it can enforce any policy
the user can express. However, this breaks an important feature of
today's email (one that we are likely to want to retain): sender and
recipient don't have to be online at the same time, or able to reach
eachother directly if they are.
What we need instead is a mechanism for the user to push out her mail
reception policy to the MTA that is responsible for her email address.
Unfortunately, it seems likely that such policies would be too complex
or require too much information to express to be able to push out any
and all policies.
Another way to reach the same result would be to consult the MUA before
the message is accepted even though it may not be available at the time
the message is presented to the MTA. In other words, the message
delivery transaction must be split into several sub-transactions.
Example:
A and D are MUAs, B and C MTAs
A to B: I have a message for D, here are the headers
B to A: Ok, give it up
B to C: I have a message from A to D, here are the headers
C to B: Thanks, I'll get back to you
C to D: I have headers for a message from A to D
D to C: I don't want it, send back this error message: "I don't accept
messages executable attachments from people I don't know"
C to B: I want to complete transaction with msgid X
B to C: Ok
C to B: Rejected with error message ...
B to A: I want to complete transaction with msgid X
A to B: Ok
B to A: Rejected with error message ...
Or alternatively:
[...]
D to C: Sure, let me have it
C to B: I want to complete transaction with msgid X
B to C: Ok
C to B: Send me the message
B to C: Here you go
C to D: Here is the message body for msgid X
Obviously this is more involved than what we have today, but it allows
for much cleaner error handling and it should help fight the spam
problem as legitimate senders that are caught by spam filters now get
to hear about this, possibly with a pointer to an alternative way of
contacting the recipient. When at any time the return path breaks down
(for instance, because the return MTA/MUA was forged) the system knows
this is a control message so it can simply be thrown away without
having to bother the user. (A big problem today is that bounces look
like regular messages and must be looked at by people rather than
software.)
(BTW there was some discussion of failing during message transmission
because halfway during the session it becomes apparent that the message
that is being transmitted is too large. This of course makes no sense,
the sender should first announce the length of the message it wishes to
transfer, after which either the receiver rejects the message because
it is too long before the actual transmission starts, or the message is
transferred and accepted.)