Re: Operations requirement: no hop-by-hop

On Sun, 15 Feb 2004, Paul Hoffman / IMC wrote:

> At 1:42 PM -0800 2/15/04, william(at)elan.net wrote:
> >Point is that creating a barrier that will prevent unwanted traffic from
> >coming through (which maybe a violation of the law or violation of the
> >policies of the recepient) is not a bad thing to have as part of the
> >mail tranmission sesssion.
> 
> We disagree here. Many people have said that they want to be able to 
> have local multi-hop rules (for example, the edge MTA at my company 
> might want to pass messages addressed to me to an internal MTA for my 
> department, which then stores messages for me). From a design 
> standpoint, then, what you want is transmission rules to have to be 
> passed faithfully through all MTAs from one end to the other.

I dont see a problem as long as this is part of the envelope of the message
when its being passed from sender to recepient. Its a lot more difficult 
to pass on recepient rules to the sender, however - that is where multi-hop 
solution has a weakness - but way to deal with it is to say that its
responsibility of the recepient MTA if its willing to accept the message 
to get all the receipient rules (for which it may have to contact another 
MTA and request those rules or possibly get those through some other protocol
or from common database for enter organization if the message is being
tranmitted then only within organization). Basicly we don't disagree that 
each "hop" should be dealt with in itself as complete transmission, but
I'm for allowing in the protocol for possibility of multiple hops as a way
to help receipient MTA even if sending MTA should always assume there 
would not be any other hops.

> believe that doing so excessively complicates the transmission rules. 
> Instead, there should be a separate policy plane for passing policy 
> rules. MTAs on the way might want to follow those policies, but the 
> policies are not part of the transmission plane.
Separate protocol for passing policies may not be bad idea, but I don't 
quite see it as requirement - its more of something that we may have
to decide on when actually desiging the system. The requirement here is
that "Sender should be able to communicate to recepient its policies for 
email communications"

> >  > BTW, I'm not against having a way for a good sender to request
> >  > permission from a recipient: in fact, that is a fine requirement. But
> >>  that can be done in a different control plane than message
> >>  transmission.
> >Why? We may want to work on this on possibly slightly different protocol
> >that defines it as authentication, but it does not mean it should not be
> >possible for it to be used as part of email session.
> 
> "being possible for" is quite different than "being mandatory for at 
> every step along the path".

Well, I agree. We should not make any kind of policy a requirements.
Our work is not to produce policies but to create protocol and setting
up policies should be left to legistors or to just mail admins who may
may choose to follow certain common policies. We do however need to built
into protocol rules that allow those policies to be used when they are 
available and as such if sender does not follow clearly advertised 
policy, the error during transmission should be just that - recepientMTA
can not accept message because it violates such-and-such policy"
 
-- 
William Leibzon
Elan Networks
[email protected]