Hallam-Baker, Phillip <pbaker(_at_)verisign(_dot_)com> wrote:
[Ted Hardie wrote:]
---new--draft--text
It would be useful for Mail Transfer Agents (MTAs) implementing
message acceptance policies to be able to confirm that peer MTAs'
actions are authorized by specific domains or networks.
Given that this is the charter lets try to avoid all use of terms
that are considered contentious by anyone, in particular 'policy',
'authorization' etc.
Mea culpa. I did suggest avoiding those terms. :^(
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.
Also, "information provided by peer MTAs" is awfully vague, and
connotes something quite different from "actions".
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.
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.
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.
Phillip's text _may_ be an improvement here, but I still find
Ted's text a lot clearer -- and I'm not at all sure our charter
should talk of "describing the configuration". Does anyone else
feel strongly?
While the primary current use case for this facility is to combat
a certain class of domain forgery in spam, the solution chosen
should be generally useful for MTA-MTA authorization.
4) The term 'MTA-MTA' authorization does not seem right at all,
the principal use of the information here is authentication of the
message origin.
There's that nasty "authentication" word! ;^)
I suspect that this use of "authorization" may deserve to be
dropped. Our standard should find uses that go well beyond MTA-MTA
authorization.
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?
--
John Leslie <john(_at_)jlc(_dot_)net>