Andrew Newton <andy(_at_)hxr(_dot_)us> wrote:
On Mar 29, 2004, at 5:31 PM, John Leslie wrote:
I do not agree that "spam generated from compromised hosts" is
excluded from our scope. Nor do I see how anyone can believe
that mail generated by "ill-meaning senders" is out of scope.
In both contexts, I was referring to a domain, MTA, etc... that has
a valid MARID RR but has either been compromised or intentionally
sends spam. So for example, accreditation might solve this problem,
but at present that is beyond the scope of the work in front of us.
I agree that any details of accreditation services are out of
scope -- though this is not, IMHO, the meaning conveyed by the
post I was responding to.
I would strongly suggest, however, that we leave room (possibly
even "room for expansion") for domain owners to specify the _name_
of accreditation service(s) which they subscribe to. (I want the
name only -- not any pretence at a "certificate".)
The overall point here is that there are many causes of spam, but we
are only seeking a charter to solve a subset of the problem.
Alas! Are we still "seeking a charter"? :^(
Our scope _is_ limited, yes, but the limits are that we are
designing a mechanism for storing and distributing "authorization"
information.
You left out 'MTA' as in:
The primary current use case for this facility is to allow
recipient MTAs to confirm that peer MTAs' actions are authorized
by specific domains or networks.
I do not agree that omitting that from my quoted text changes
any meaning; but let's quote the charter in full _again_ :
" It would be useful for those maintaining domains and networks
" to be able to specify that individual hosts or nodes are authorized
" to act as MTAs for messages sent from those domains or networks.
" This working group will develop a DNS-based mechanism for
" storing and distributing information associated with that authorization.
" The primary current use case for this facility is to allow recipient
" MTAs to confirm that peer MTAs' actions are authorized by
" specific domains or networks. This will help combat a certain
" class of domain forgery common in spam. The solution chosen,
" however, should be generally useful for others which might
" check this authorization data.
and
It will not consider anti-spam abatement
measures outside of the area of MTA authorization.
That text is _not_ in the draft charter Ted posted.
--
John Leslie <john(_at_)jlc(_dot_)net>