On Apr 16, 2004, at 2:58 AM, Greg Connor wrote:
I'm curious as to why you said "A sender needs to implement only one,"
- does that mean the sender should pick a flavor of identity and the
receiver must honor all of them? That's one way to do it but I don't
know if we would want to encourage that.
Sorry, I need to clearly explain that. I was jumping to the conclusion
that if we did not narrow the list, then we are saying the sender
declares the type of identity they are asserting. Or as was just
stated by Jon Kyme in another email:
"Why not? Leave the choice of identities to the publisher, then *we*
don't
have to pick any one (or two). We can pick the whole set."
2) If it is possible, are there ways to examine a group of these
identities in a concise manner that would result in only one
authorization path for a receiving MTA?
I don't think I understood this question well enough to answer.
For the receiving MTA, complexity does not come from multiple
identities but from multiple code paths to support multiple
authorization policies. So, is there a way to take a group of the
identities and make them all apply to a single authorization policy on
the receiving MTA?
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?
Our charter is about placing MTA policy in DNS.
-andy