spf-discuss
[Top] [All Lists]

Authentication, Accreditation, and Reputation

2004-08-13 14:58:41
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

It seems a whole lot of you have missed the discussion on how 
authentication, accreditation, and reputation interrelate, and why all of a 
sudden we are talking about accreditation and reputation in our quest to 
end spam.

Authentication is finding out whether or not the email is authentic. This 
will eliminate outright forgeries. (Yes, there are holes in the system, but 
they are very small holes and can be filled in with more work.) 
Authentication technologies include SPF, Domain Keys, Caller ID (RIP), and 
Sender ID. There are other technologies out there as well, but these are 
the major players. SPF is already deployed and working and widely adopted, 
so we have the authentication piece begun.

Accreditation can't happen without authentication. For this discussion, 
let's call accreditation "trust", in that the accreditor "trusts" that the 
domain is what it says it is. (The accreditation realm is much larger than 
this.) If you get a piece of email from a domain, it doesn't matter who 
trusts that domain if you can't tell whether it is real or forged. Only 
after you can discern whether it is forged or not can you begin asking 
people whether they trust the domain.

Reputation is like accreditation, and they get often confused. But it is 
basically the "memory" of the actions of the domain. Is SpamsALot.com sends 
a lot of spam, then they will have a reputation for spam. If NeverSpam.com 
never sends spam, then they will have a reputation for not sending spam. 
Authentication precedes reputation because you can't hold a domain 
responsible for email that was forged.

Accreditation can be used to lend reputation to someone else. For instance, 
if I trust A, and tell you that A is a good guy, I am accrediting him. Now 
your opinion of A depends on what my reputation is in your eyes. But don't 
forget A's previous reputation while you judge A - you may already know him 
regardless of whether I accredit him or not.

We don't know what accreditation or reputation will look like. We do have 
current systems that resemble some possibilities. For instance, Verisign 
does something like accreditation. Spamcop and others do reputation. But 
will these be examples of the future systems? I can't tell.

Accreditation may or may not involve money. Likely some people will try it. 
Will they succeed? I don't know. Accreditation has other purposes beyond 
buying the services. We have accreditation systems in place for PGP (You 
sign your friend's key, and now people who trust you will trust your friend 
as well.) We have accreditation systems in place for other things. We need 
accreditation for things beyond what we do now. (Banks, corporations, 
government offices, etc...)

Meng's post earlier wasn't telling people, "This is the way it will be." He 
was just showing you that there are people actively working on potential 
solutions to the accreditation and reputation problems. If you want to work 
on the bleeding edge of the spam solution, then you should be building 
systems for accreditation and reputation.

Now for one final point: Sender pays. We want to transfer the cost of 
sending email to the sender, and leave the receiver basically unfettered. 
We want the sender to take the time to build up a good reputation (like the 
way it works in the real world.) We want them to prove who they are, rather 
than having us try and figure that out on our own. When we do this, we 
begin to increase the cost of spamming, and thus reduce the amount of spam.

Does this mean, "If you want to send email, you have to pay $300 to 
Verisign"? No, that's absurd. What it means though is that if you want to 
send email *and expect that email to be received* you have to be 
responsible, publish SPF records, don't send spam, and fix your computers 
when they get a virus. If that is unreasonable, then call me a troll.

- -- 
Jonathan M. Gardner
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFBHTmRBFeYcclU5Q0RAqgoAJ9PEkBkOKxmlEhuqF+dgd6cXTLYlwCeOCD7
o+KGkoPWsci+tE4cheMSX08=
=SDcZ
-----END PGP SIGNATURE-----