wayne <wayne(_at_)schlitt(_dot_)net> wrote:
In <200509082128(_dot_)j88LSAa20018(_at_)gator(_dot_)earlhood(_dot_)com> Earl
Hood <earl(_at_)earlhood(_dot_)com> writes:
I'm wondering of there is really any value for an SMTP client
to publish vouch records...
OK, let's ignore the fact that almost no one uses CSV and therefore
there is currently almost no value in using it. Let's also ignore the
fact that this is the case even after a year and a half of massive
hype, so this chicken-and-egg problem is unlikely to ever change.
"Massive hype"... I'm flattered, Wayne.
In theory, yes, there is value in domains publishing accreditation
information.
Wayne explains this very well.
Yes, the people publishing accreditation information are likely to only
give pointers to accreditation services that say positive things about
them. And, yes, the receiver can't take those evaluations seriously,
based *solely* on the fact that the sender has listed them.
But _some_ of them may be trustworthy for other reasons.
Ok, we *want* lots of accreditation services also. We don't want a
monopoly.
I absolutely agree, but it may not be obvious why we want lots of
them.
One reason is that anybody can sue _one_ accreditation service,
but nobody can sue thousands of them. While it is being sued, any
accreditation service will be _very_ circumspect about what it reports.
Another reason is that we don't know yet what sorts of accreditation
will give long-term useful information. With different accreditation
services accrediting different things, we have a much better chance
of finding what works.
We also don't want to have to check hundreds of different
accreditation services on every email we receive.
We simply can't afford to check very many on _every_ email.
The solution is for senders to say which accreditation services
they are listed on, and for receivers to use some sort of
"accreditation reputation" service to decide which, if any, of
the accreditation services the sender mentioned are worth checking.
Yes, this is one way. And it's very likely what we'll see near-term.
It still leaves receiving SMTP servers checking multiple services
for every email. It would be more efficient for reputation services
under contract by the receiving SMTP servers to do those accreditation
checks, and have the receiving SMTP server do a single reputation check.
I don't know when we'll get there, though.
I hope that one day there aren't just a few accreditation services,
or even hundreds, but tens of thousands of them. Most will be very
specialized, knowing only a small number of domains, but that is fine.
The system outlined in CSV-DNA _could_ deal with tens of thousands
of accreditation services. And I won't disagree that, once the scaling
issues are resolved, the end-users would be better off for there being
10,000 instead of 100.
Phillip Hallam-Baker once wrote up an I-D for an accred= keyword for
SPF records. Like CSV, it hasn't gone anywhere yet because there is a
kind of a chicken-and-egg problem.
Wait a few years... In e-mail a change which takes five years is a
_fast_ change.
BTW, there's no reason there can't be overlap between accreditation
under SPF and accreditation under CSV, so long as it's clear that it's
the sending SMTP client (as identified by its EHLO string) which is
being accredited.
Until there are widely deployed email authentication systems, there
isn't much reason to trust any accreditation service, and until
there is a reason to trust accreditation services, there isn't much
reason to create them.
Oh, I quite disagree with that last statement. There's plenty of
reason to create them: just don't expect to get rich doing so!
--
John Leslie <john(_at_)jlc(_dot_)net>
_______________________________________________
ietf-clear mailing list
ietf-clear(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-clear