Re: Operations requirement: no hop-by-hop

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