Re: Why are we here? What are our goals?
Paul Crowley <[email protected]>
| Newsgroups | gmane.mail.ng |
|---|---|
| Message-ID | <[email protected]> |
Chuq Von Rospach <[email protected]> writes: > > I'd be interested to know if you've looked at modern attack resistant > > trust metrics in detail before saying that. Metrics like Advogato, > > PageRank, and my own TrustFlow are explicitly designed to resist > > attackers who try to artifically inflate their trust through mass > > identity creation. > > At a simple level, yes. In detail, no. But I don't believe that > web-of-trust or social-networking metrics are the way a server should > define its trust model. perhaps as a service an admin can choose to > interface to, but I think those issues are outside of the scope of > what we should be doing here, other than making allowances for them to > be interfaced to the system if an admin chooses to. So let us focus on > building core features and a way to plug these things in, let's not > try to build them in I entirely agree - it would be a grave mistake to include such a trust metric as part of the specification of NGMAIL. But their existence may inform the protocol we do design. The reason is that if we're proposing replacing our current default-allow system with a default-deny system, we want to feel confident that it will rarely impede the mail of legitimate senders. Users will have the flexibility to choose their own policy, but we want to be confident that it will be *possible* to define a very permissive policy which allows in practically anyone who legitimately wants to email you, while stopping UBE. Thus we have to think about what shape that policy might take even though it won't form part of the protocol design. Here's my first thought on such a policy: * allow in anyone who's ever sent you email, except where you explicitly marked them otherwise. * allow in anyone a friend introduces. Alice introduces Bob to Carol simply by mentioning Carol in an email to Bob. * allow in anyone who ranks highly on some sort of attack-resistant trust metric. * allow in anyone bearing an "introduction pass" recognised by any k of n designated anti-spam sites. These sites certify organisations who have good anti-spam policies, and who have a relationship with users that is resistant to unlimited multiple sign-up. For example, you're an employee of IBM, or a student at Berkeley, or a paying customer of AOL broadband. These organisations will issue you with, say, up to 60 "introduction passes" a month to use as you see fit; they cannot be reused. Your organisation is listed with nice-guys.com and not-spammers.com, and I trust those sites to tell me which organisations are careful with their introduction passes. So I'll let in an email bearing such a pass. (Maybe IBM just certifies the relationship with the individual, and nice-guys.com issue the pass - this needs thought...) * otherwise, deny. -- __ Paul Crowley \/ o\ [email protected] /\__/ http://www.ciphergoth.org/