SM <sm(_at_)resistor(_dot_)net> wrote:
At 19:56 17-10-2011, Douglas Otis wrote:
What is needed is a light weight method to avoid abusive sources
with a glimmer of hope it might actually work...
Neither SPF nor DKIM properly defend domains...
SPF and DKIM, like any other scheme, is not some holy grail that will
solve all the email problems. All schemes largely support "too big
to block". That is how consumerism works.
2B2B is indeed a feature we can't avoid. I would disagree that "all
schemes" support it at all well.
to compete with social networks, a light weight method to
authenticate outbound MTAs is needed, or eventually email will be
supplanted by various proprietary services.
From draft-ietf-marid-csv-csa-02:
Dear to my heart!
"Internet operation has typically required no public mechanism for
announcing restriction or permission of particular hosts to operate
clients or servers for particular services on behalf of particular
domains. What is missing is an open, interoperable means by which a
trusted agency can announce authorization for a host to operate a
service."
Which trusted agency should it be?
"Any trusted agency" was our intent.
"Trust" here must be based on a plausible basis for trust. There
cannot be only-one "trusted agency".
The "csv" drafts considered that receivers would choose which
"reputation services" to trust, while senders would choose which
"vouching services" to ask to vouch for them, with no limit to the
number of each. Reputation services would each consider which of
the vouching services they consider reliable. Thus the problem of
trust reduces to a 1 x N problem, where N is limited to the number
of vouching services a particular reputation service chooses to
consider.
The 2B2B problem remains, of course; but it is up to reputation
services to compile their own lists of 2B2B and decide whether to
assign high reliability to one or more of their vouching services
and/or just always report "good-enough reputation".
This is what Doug and I thought could scale to Internet scale.
YMMV, of course...
--
John Leslie <john(_at_)jlc(_dot_)net>