Andrew,
AN> On Apr 16, 2004, at 2:58 AM, Greg Connor wrote:
AN> For the receiving MTA, complexity does not come from multiple
AN> identities but from multiple code paths to support multiple
AN> authorization policies. So, is there a way to take a group of the
AN> identities and make them all apply to a single authorization policy on
AN> the receiving MTA?
If comes from having to support multiples of anything. Multiple
identities are going to have multiple code segments, for dealing with
syntax, semantics and/or authentication. THEN we get to have the fun
of multiple policy modules. Put it all together and it spells
combinatorial complexity.
The more there alternatives there are for a sender to excercise, then
the more code and complexity the receiver must support, lest email
between sender and receiver be prevented.
When there is not prior arrangement for all of the details, then the
choices need to be few and sufficient, with everyone everywhere
supporting them.
When there does need to be prior arrangement between sender and
recipient, it is called EDI. I assure us all that we do not want to
go there.
Why would we be forbidden to make changes to either 2821 or 2822?
Could we change a Should to a Must here or there, or a May Not to a
May? What about RFC2476?
AN> Our charter is about placing MTA policy in DNS.
Forgive me for being concerned with our bandying about the word
policy. Not that your use is incorrect, but that it is not in the
charter -- the word "authorization" is in the charter -- and because
use of the word "policy" usually portends lovely, broad-ranging
efforts at generic policy engines. I suspect you didn't mean that,
but I thought it worth making sure that the group is not going to go
down that path.
d/
--
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>