Re: Operations requirement: no hop-by-hop

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

> >  If this is correct, I must object as this is exactly where much of 
> >the current insanity comes from. What we need is a way to get the 
> >sender to behave according to the recipients wishes, which makes it 
> >necessary to add more feedback to the new protocol, even if this 
> >spans across servers and sessions.
> 
> Then we disagree about requirements here. I think others have said it 
> well: if a sender wants to ignore a recipient's desires, the sender 
> will do so regardless of the protocol. The operational requirement is 
> simplicity and predictability for operators. Adding overhead that 
> pretends that aggressive senders will follow recipient's desires has 
> proven to be a bad design choice for almost ten years now.

There maybe a sign on the road saying you can not drive that way and 
some will still do and choose to violate the law. That does not mean 
having such a sign is a bad thing. In some cases where too many are
violating the law (or same people doing it often) and there is just not 
enough law enforcement power to stop them all, then the barrier is put
up - this maybe a simple step barrier or it maybe concrete block or some
tire breakers if you go wrong way. 

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. Its all part of the authentication (i.e. 
requirements for permitting connection to go through) and its how
the recepientMTA and senderMTA agree on parameters of the transmission

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

----

There is something else I want to mention. While designing good efficient
mail protocol in itself should be the main goal, the other goal is to 
create something that users will have strong incentive to use and move to.
This has been a problem with IETF - protocols are created but some are 
not widely used or deployed. This may particularly become an issue for any 
protocol that is being designed to replace the existing one - there must 
be very strong user incentive to use it as apposed to current protocol.

What users currently want most out of mail protocol is prevention of spam.
If we're not able to offer this as part of new protocol design, no matter
if we designed something that otherwise fits all the requirements and is 
very elegant in its design - it'll not be something that people will switch
to and our efforts will prove fruitless in the end.

The spam control on the protocol level involves being able to communicate 
consent requirements ("put signs") of the recepient and for protocol to 
try to enforce those requirements ("put barriers"). We may do it by having 
sender request a consent token to be included in the mail (which maybe 
done within different protocol) but in the end protocol should still allow 
to use those consent tokens as part of the authentication system for email 
transmission OR we it may be more strongly integrated into the whole 
mail-ng system. In the end we'll have to work on this all and can not 
just dismiss it as part of our efforts before we even started.

-- 
William Leibzon
Elan Networks
[email protected]