Sorry, John. I have to side with Elliot's statment here. If the "security
protocol" need only look at "security features" then why look at list expansion
at all? The answer is that obviously the security protocol has a direct effect
on non-security features. Ergo, you have to accept some level of non-security
baggage in the interest of functionality.
Exempted addresses are a mail feature that makes good functional sense. I
think it is finding it's way into most definitions of "business grade
messaging". It would be wise for us to support it, I think.
Chris
__________________
John Pawling wrote:
All,
I still disagree with adding the ML exempted address feature to CMS or ESS.
This service does not belong in any security protocol. If a user
organization needs this service then they can implement it without adding
unneeded complexity to the security protocol.
================================
John Pawling, jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
www.jgvandyke.com
================================
Elliott Ginsburg wrote:
I don't see why it is 'bad protocol practice'. If a remote service (in this
case an ML expander) offers a certain service, it is the job of the
protocol to
allow the service to be requested.
In an environment where there are a large number of MLs, ML management becomes
a problem; having to create and maintain variants for each is untenable and
would in effect guarantee that they were not maintained well (as, for
instance,
when someone should be removed). It is perfectly reasonable for a 'third party
( the ML expander) to offer a service which is an alternative to having to
maintain variants.
elliott ginsburg