--Andrew Newton <andy(_at_)hxr(_dot_)us> wrote:
Given that the IESG has assigned this working group a narrow charter and
specific milestones designed to focus our energies, consider the
following:
1) We have been given a list of 5 or 6 identities from which to pick. If
we did not narrow the list, where would most of the complexity be
located? A sender needs to implement only one, but would a receiving MTA
need to implement an authorization path for all, and might there be
overlap or conflict?
I'm going to make a rough guess and say that there will probably be lots of
overlap, and not that much conflict. I think a statement of what outgoing
MTAs I use for my domain could probably be applied to all of MAIL FROM,
HELO and From:/Sender: Some senders may tweak the info, or opt out of some
of those, but I think the large majority of domain owners want to put out a
single statement that describes authorized MTAs and not multiple policy
statements.
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.
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.
3) While our work may impact DNS and email implementations, our charter
does not give us the proper scope to make changes to either RFC 2821 or
RFC 2882. So which identities do not require us to wonder beyond our
charter?
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?
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>