Re: Defining Trust and Reputation
Yakov Shafranovich <[email protected]> Thu, 18 Mar 2004 18:09:53 -0500
| Newsgroups | gmane.ietf.asrg.smtpverify |
|---|---|
| Organization | SolidMatrix Technologies, Inc. |
| Message-ID | <[email protected]> |
Ed Gerck wrote: > While I'm still reading past postings to falimiarize myself > with what has already been done, I'd like to reply to Yakov's > message Re above. Because I need to first deal with a scale > for trust values, my answer is actually at the end, where I > restate some of Yakov's comments. > (sorry that it took a while to reply, I have been flooded with emails) > In short, trust on the sender cannot be proven by the sender (self- > assertions cannot induce trust -- e.g., "trust me" doesn't work). > It must be calculated using sources independent of the sender. The sender > may hint to a specific trust service used, and even provide it and its > values, but we should be able to get that information from the service > directly and/or chose our own trust services independently. In doing so, > trust on the sender is what the receiver determines at a specific time > based on a behavior model for the sender. If the sender cooperates, > the process can be faster and easier. But the sender cannot determine > the process. > > The problem is, thus, not how do you determine trust, especially with all > the different definitions of spam possible, but how do you want to do it. > All you need to do is conform to the abstract model of trust [1]. > > Cheers, > Ed Gerck > > [1] http://nma.com/mcg-mirror/trustdef.htm > And the trust model that somebody uses would depend on his definition of spam. It seems to me that we have two approaches here: 1. We can try to define a trust model that is reasonable for fighting spam. However, with the divergent spam definitions, that might be unrealistic. 2. We can try to define a framework for exchanging and queing trust information, and let receivers pick their own trust models that they want to use. Part of this would be a protocol for providing hints from the sender. This might be more realistic, but is still a lot of work. Yakov