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. In accreditation, the server cannot
trust anything provided by the client, therefore, the server should
already have a predefined set of accreditation services it will query,
regardless what an SMTP client may claim. The Security Considerations
section of CSV-DNA should discuss this.
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.
In theory, yes, there is value in domains publishing accreditation
information.
First, let's distinguish between "accreditation" and "reputation".
"Accreditation" services are are generally geared toward the sender
and, if they give an evaluation on a sender, they generally give only
positive evaluations. "Reputation" services are generally geared
toward the receiver and, if they give an evaluation on a sender,
they generally give only negative evaluations.
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.
Let's look at reputation services. There is a *HUGE* number of DNSBLs
and things like DCC/Pyzor/Razor, etc. Some of these are very good,
some of them are very bad. In order be useful, receivers evaluate the
reputation of the reputation services and only use the ones they think
are useful. It is fairly easy for new DNSBLs to be created and used
(e.g. the CBL was quickly adopted by many), and this is a good thing.
Ok, we *want* lots of accreditation services also. We don't want a
monopoly. We also don't want to have to check hundreds of different
accreditation services on every email we receive. 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.
One of the hard parts of accreditation services is that you have to
know the people you are vouching for. This is really expensive if all
you are doing is looking at the email they send. Instead, it would be
better to leverage the knowledge of the domains that are obtained for
other reasons. For example, most countries and states/provinces have
some sort of certification for banks. You might know if there is a
"First Union Bank of Lincoln Nebraska" or a "Union Bank and Trust of
Lincoln Nebraska", but both the US government and the state of
Nebraska know. Both of these regulatory agencies could publish
accreditation information that could be used for anti-phishing
purposes. Now, I don't know who the appropriate banking regulatory
agency for Malaysia is or whether they do a good enough job to trust
for anti-phishing purposes, but that is where "accreditation
reputation" service comes in.
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.
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. 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.
-wayne
_______________________________________________
ietf-clear mailing list
ietf-clear(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-clear