[Spambayes] Email Certificates of Approval

[Robert Woodhead]

At 7:16 PM -0500 3/13/03, Eric S. Johansson wrote:
>I hope you realize that as I play Devils advocate, there is 
>absolutely no animosity towards you or your idea.  This "think like 
>a spammer" role-playing was an essential part of the process in 
>making camram (a sender pays antispam system) more robust.

Oh of course.  I do that all the time myself.

If I think you're being a dickhead, you'll be the second to know.  ;^)

>trusting someone is the fundamental leverage point a con artist counts on.

Actually, this is not entirely correct.  Con artists depend on the 
greed of the marks.

>Now one thing to consider is the reputation damage the industry 
>would have given a sufficiently motivated set of spammers.  They can 
>keep setting up certificate authorities faster than you can knock 
>them down.  If they stayed legit long enough, they can burn a whole 
>bunch of people and get them to cease trusting certificates and 
>certificate authorities.
>
>reputation capital such a wonderful thing...

Obviously, there would have to be a central registrar who is 
responsible for certifying subregistrars.  We have that already with 
DNS.  And clearly, the amount of vetting required to become a 
subregistrar would be significant.

>how will they get the word out?  Are you envisioning some form of 
>peer-to-peer reporting structure?

Not quite clear on this, but it will involve some central servers 
keeping track of the votes.

>   How do you deal with false reports?  Imagine someone collecting 
>certificates and then a network of people report them as spammers.

No, a certificate holder can only vote that a particular email from 
another cert holder is spam, he would have to register his vote 
within a reasonable period of time, and his vote (and the yea votes) 
would decay over time.  So to get tagged as a spammer you would have 
to get voted against by a significant fraction of the electorate 
(those receiving emails from you) in a short period of time [there 
would have to be some provision that if A emails B, B can't forward 
to C and both B and C vote it to be spam].

This provides a form of traffic analysis.  Spammers email to a lot of 
people over a short period of time.  Hammers email to a much smaller 
number of people -- almost all known to them -- over longer periods.

The only reasonable targets for a smear campaign are large legit bulk 
emailers (say, amazon.com) and mailing lists.

>  Instantly, you can cause loss of e-mail access to a large number of 
>people. Also, what about indirect reputation trashing.  Someone gets 
>a certificate with your name and identity.  Obviously, it won't 
>match your certificate but most people won't know that.

The cert isn't intended to identify you, though in most cases it can. 
It's used to tell you "emailer 23734282932823732732929 is regarded as 
a spammer".  Rarely will end-users bother to, or need, to find out 
that 23734282932823732732929 is dipwad27 at hotmail.com.

This isn't supposed to be a replacement for other systems of spam 
detection, just another data point used in deciding what to do.  The 
more orthoganal detection methods we have, the harder it will be to 
spam.  What this does is give you an estimate of the reputation of 
someone you've never heard of before.

>
>On the latency issue, a spammer can get out an awful lot of e-mail 
>in a small number of hours.  The distribution of a certificate 
>revocation notice worldwide will need to be under 10 minutes in 
>order for it to be only moderately effective.  I suggest you do the 
>math of propagation and figure out how far and how fast spam can go 
>in only a few minutes.

You're missing something.  From the standpoint of an enduser, it 
doesn't matter how fast the spam gets to his mailserver.  All that 
matters is how long it is between the start of the spam run and the 
time his mailreader downloads the email from the mailserver and 
checks its reputation.  For most email users, this averages several 
hours, enough time for the earlybirds who check their email every 5 
minutes to vote on the reputation.

>The problem with certificates and this kind of identity theft is 
>that it directly affects your reputation.  You can be barred from 
>ever having access to e-mail again based on this form of identity 
>theft.  You could potentially even be barred from accessing the 
>Internet ever.  How you repudiate something that's  supposedly 
>something you can't repudiate?  After all, it's your electronic 
>identity.  I don't know about you but I want to deny that I ever 
>wrote some of my e-mail. ;-)

No, not at all.  Worst case, you buy another certificate.  Or even, 
if reputations decay, just wait a couple of days and you'll have a 
decent rep again.

Consider the horrible case, a worm that goes around stealing 
certificates and giving them to spammers.  What happens?  The 
reputation system becomes unreliable for a few days until the apps 
get patched.  If we're clever in the implementation, in such a case, 
the cert holders could get a fresh cert at no charge if they wanted.

>I agree with most of which you say.  I think that certificate based 
>or, more correctly stated, identity based e-mail antispam filters 
>can be made to work if you make them decentralized and based on who 
>you know.  The trouble comes when you try to send e-mail to someone 
>that you don't know.

Which is the problem I'm addressing.

>   If you assume web of trust, then you have a "six degrees from 
>Kevin Bacon" type problem as you try to find someone you know who's 
>willing to introduce you to someone who knows the person you're 
>trying to get in touch with.

Right.  It's an issue for new users.

>
>but you still haven't dealt with the issue of elected and unelected 
>governance and their influence on your ability to generate e-mail.

Nobody is stopping you from emailing to your heart's content.  Your 
readers are merely making a recommendation to new people you might 
want to email as to what kind of guy you are.

Nobody is being forced to stop emailing.  Nobody is being forced to 
not read an email.  It's just a suggestion.  No more, or less, 
important than "your bayesian filter  thinks this is spammy" or "your 
dnsbl says this comes from a known spam source".

End users can be stupid and trash emails based on the recommendation. 
But they can also do that based on what their spamfilter says.

>Now how does this apply to legitimate bulk e-mail?  All bulk e-mail 
>should be opt-in.  Therefore, after you have established a 
>relationship with a bulk e-mail source, they are now defined as 
>"friend" and sign their messages to you. Otherwise, they can just 
>sit there and generate stamps.

It's an interesting approach.

>actually, if you want identity based systems to control spam, you 
>have to have a and identity associated with every e-mail account. 
>At a $50 price point, it ain't going to happen. *I* wouldn't spend 
>$50 on a certificate when I know they cost pennies to generate. 
>Given a sufficient high price point, you create an opportunity for 
>folks to come in and trash the reputation capital of the entire 
>system.

The $ is really for running the reputation database.  If that can 
effectively be distributed, then that problem goes away.

>Actually, this raises an important point.  Why should I spend money 
>to clean up somebody else's mess.  Certificate based systems such as 
>you propose further increase the receiver pays nature of e-mail.  I 
>pay when Spam comes in, I pay to keep Spam out.

No.  Only senders who want a cert pay.  You can receive email and use 
the system without a cert (but you don't get a vote).

>>So can DNS registrars.  So can SSL registrars.  But note that such 
>>a compromise will be immediately obvious, so there is a great 
>>incentive for the registrar to play fair.
>
>how does it become immediately obvious?

Because certs that should quickly get tagged as belonging to spammers won't.

>   Will there be worldwide bulletins on CNN?  Will the Attorney 
>General's of 15 states lead a SWAT team into some small tropical 
>country to shut down the naughty registrar?  And if the registrar 
>has managed to accrue a few hundred thousand customers who are 
>legitimate?  What happens to them?  How do you get people to change 
>their certificates when the user interface to add them is so 
>painfully horrible that they won't use them in the first place?

That's an implementation issue.  But note that while you may have 
resellers, there needs to be a central registrar who has the database 
of certs (like the DNS root servers).  So that's the point of 
compromise.

>>Point well taken.  But note that I was talking about people buying 
>>certs to use to trash the reps of others.  As for the blastogram 
>>operators, after a while they'll find they can't buy certs from the 
>>registrar anymore.
>
>so they will form their own.

And have to go through background checks.  And put up a bond. 
Spammers won't do this.

>the trick is knowing when the transition happens and even experts 
>screwed up some of the time.  How can you ever hope to get someone 
>who is uninterested to give that level of attention to detail?

You don't.  They will tend to freeride on the power-users who will 
form the voting elite.  The whole point, as I've said before, is to 
have another orthogonal detection system, reducing false positives 
for the clueless, who are most likely to get bitten by them.

>like I said.  You need extremely fast propagation of information, 
>reliable dissemination points and reliable connections to those 
>dissemination points.  I still believe it's 10 minutes propagation 
>worldwide with full redundancy on all connections.

See above.  The rest-stop on the mailserver before the POP session 
gives you the time.

>
>also, what happens if someone can get to the dissemination points? 
>Does all the e-mail get held up and what do they get all of their 
>e-mail regardless?

Sure they do.  They just don't get the benefit of an opinion.  It 
fails gracefully.

>
>And who is going to pay for all this infrastructure?  Could it be 
>the receiver of the e-mail?  The Spammer isn't paying.

The cert purchasers.

>you can deal with one form of ballot stuffing from the certificate 
>identity which prevents multiple votes by the same certificate on 
>the same topic.  Then you can also use source IP address to see if 
>you get a lot of certificates from the same address.  Unfortunately, 
>this test would fail for organizations with address translation 
>gateways.

Note that if you're sending to someone who has a cert, you could 
encode that info into the header line, so that only the holder of the 
cert (the recipient) could vote against you.

This would also, btw, have the nice feature of having a robust 
X-Original-Recipient field in the email, great for detecting bounces 
from clueless isps who return bizarre bounce messages.

R

-- 

===========================================================
Robert Woodhead, CEO, AnimEigo     http://www.animeigo.com/
===========================================================
http://selfpromotion.com/   The Net's only URL registration
SHARESERVICE.  A power tool for power webmasters.