The meaning I am attempting to attach to accreditation
is that it is a statement provided by a third party.
OK, this is "gut feeling" but it is based on the experience
I've ranted about
before. I don't believe *implicitly* accepting statements
from a third
party, about accreditation, will be accepted by e-mail users or
administrators. Explicitly accepting statements is different
(ie: MAPS)[1] as that's the recipient deciding.
The recipient still decides here.
Even if the recipient decides that they WAY they are going to
decide is by allowing spam assasin and some sort of feedback
loop to work out what the value should be.
I don't like manual configuration alone, in most cases the
accreditations will start out being 100% accurate indicators
of the accredited party not being spam. The spammers will attack
the service as they discover that it has credibility. So the
measured quality is likely to drop over time, hence a
constant re-evaluation is needed.
I'd hate to cite Habeas as an example because I thought they
were good people with good intentions, but they're the best one
to cite as a third-party accreditation authority gone wrong.
People trusted this third-party right
until spammers started faking the Habeas headers and *getting
away with it.*
Absolutely, hence the relevance to this spec. Habeas did not
fail because the idea is bad, it failled because it did not
have an authentication component.
Hence the relevance to MARID. We do NOT have to discuss the
details of the accreditation concept here, they are not in
scope.
But it is important that the authentication concept be capable
of supporting an accreditation use. Otherwise all this will
do is to drive up demand for domain names. And nobody here
would want that.
Phill