Re: Operations requirement: no hop-by-hop

This all goes back to one of the early requirements I cited:

- Support for Direct Client to Client communications aka DIAL-UP.

This is will become more important as the VOIP market matures.  Tomorrow
users will be able to dial up directly to a user (over the internet) but in
the software is now RS232 based, unless a PPP server and client support is
added to MAIL-NG.

(Hint to Brad Clements)

Yes to those who say this is a implementation issue.  But what it means is
that it relaxes TCP/IP related requirements.  In other words, MAIL-NG is a
virtual communication system  - completely defined at the upper network
application layer.

-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com


----- Original Message ----- 
From: "Iljitsch van Beijnum" <[email protected]>
To: "Richard Welty" <[email protected]>
Cc: <[email protected]>
Sent: Saturday, February 14, 2004 1:38 PM
Subject: 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.)
>
>