It would be useful for Mail Transfer Agents (MTAs) implementing
message acceptance restrictions to be able to confirm that
information provided by peer MTAs' is consistent with a description
of the configuration of the purported origin.
I find Ted's language a _lot_ clearer here. "Message acceptance
policies" makes it clear that the "policies" (whatever that might
mean) are the province of the operators of the receiving MTA.
"Restriction", alas, does not.
Actualy Jon pointed out we don't need that clause at all. Taking into
account the other points raised I don't think we need the text at
all:
It would be useful for Mail Transfer Agents (MTAs) to be able to confirm
that actions performed by peer MTAs' is consistent with the purported
origin of messages they attempt to transfer.
Ted's "authorized by specific domains or networks", to me, is
clear in stating that the "authorization" (whatever that might mean)
comes from specific domains or specific networks. Phillip's text
is not clear on that.
My problem was with the '"authorization" (whatever that might mean)'
But I don't think we need it at all for charter purposes
I, frankly, prefer Ted's text. I don't think there's any need
for us to argue what "policy" means, or what "authorized" means,
so long as the context makes it clear who assigns meaning to them.
I don't think we need to use the terms at all, my point is that they
are making it harder to understand the problem, not easier.
This working group will develop a DNS-based mechanism for storing
and distributing information associated with that authorization.
This working group will develop a DNS-based mechanism for storing
and distributing information that describes the configuration of
domains and networks that are relevant to this task.
This working group will develop a DNS-based mechanism for storing
and distributing information that is relevant to this task.
I suspect that this use of "authorization" may deserve to be
dropped. Our standard should find uses that go well beyond MTA-MTA
authorization.
It seemed to me that 'authorization' was being used as a shorthand
for 'access control', just because you often do the authorization
part after authentication does not mean that it has to be that way.
We are not really providing authorization information, that is
certainly involved - there will be accreditations of a peer MTA
and there will be evaluations of accreditation providers. But
those are exactly the parts that we don't want to have in scope.
Does anyone believe we need to change anything in Ted's draft
to clarify that those parts are _not_ in our scope?
I think that it should be clear that C-R schemes, the details of
how accreditation information are interpreted should be out of scope.
But we have to be careful that we do not arbitrarily cut off
important connections between this spec and other schemes that
will be required. I have to be able to tell people that I have an
accreditation as part of the sender description, the rules for
interpreting that information are not in scope.