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.
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.
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.
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 authentication.
[Notes:
1) Changed policy to restrictions, if left unqualified the term
will be interpreted by some to mean authorization policy which in
the context of SAML etc. is a statement by the resource owner that
directly controls the resource.
2) A description of the configuration could include an authorization
to send - if you want to think of the statement in those terms.
I still think that we should avoid that characterization.
3) It would be nice to work in the principle outlined in CSRI, that
what we are attempting to do here is provide a way for the sender of
an email to provide the recipient with a small amount of additional
information that allows the recipient to determine that it should
be accepted. i.e. it is not likely to be spam because the purported
origin is authentic and has a good reputation.
4) The term 'MTA-MTA' authorization does not seem right at all,
the principle use of the information here is authentication of the
message origin. 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.
-----Original Message-----
From: owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Ted
Hardie
Sent: Tuesday, March 16, 2004 2:14 PM
To: ietf-mxcomp(_at_)imc(_dot_)org
Subject: re: Draft Charter
It would useful for Mail Transfer Agents (MTAs) to be able to
confirm that peer MTAs are authorized to send mail on behalf of a
specific domain or network. This working group will
develop a DNS-based
mechanism for storing and distributing information
associated with that
authorization. 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 usable for MTA authorization.
A number of folks have raised issues with this section of the charter;
some of those have been on list (Phill, Hector) and some
others off-list.
Working through those comments, I don't see any that run counter to
the sense of the meeting in Seoul or the discussions to date. In
coming up with replacement language, though, I confess that I keep
running into either very muddy language or appearing to specify
a solution in the charter. Here's a crack at replacement
text; comments
welcome.
---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. This
working group will develop a DNS-based mechanism for storing
and distributing information associated with that authorization.
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.
___________________________________
regards,
Ted Hardie