Dean Anderson wrote: > > On Tue, 16 Mar 2004, Ed Gerck wrote: > > For example, saying that you're "god@xxxxxxxxxx" should not be so > > easy to do when you're sending email, even though it should still > > be easy to set "god@xxxxxxxxxx" as your address in your MUA. > > The From: address is just dressing. It makes no difference what its actual > value is, nor that it can or can't receive email. As was pointed out, > many things only send email, and don't receive it. Those things will have > informative (or not) from addresses that are invalid for reception. Things that send email but don't receive them can nonetheless have a valid email entry for 'no mail accepted', with no mailbox. In terms of trust as I defined before here [1], an email address for those things (or any other things) should have a *minimum* of three values: + trusted according to policy(+) 0 trust value not assigned - distrusted according to policy(-) Of course, the positive and negative range can be expanded in values as well. How to assign these values? How the trust model works? Let me copy from an earlier discussion elsewhere. This is the wrong question to ask. The real answer is, "what trust model would you like?" There is a built-in notion (given by the abstract trust definition in [1]) of the meta-rules that a trust model has to follow, but I might buy a trust model from someone and add that, design my own, or even augment one I bought. Thus, I can ask for a fingerprint and check it against the FBI, Scotland Yard, and Surite databases, check their PGP key to make sure that it was signed my Mother Theresa, ask for a letter of recommendation from either the Pope or the Dalai Lama (except during Ramadan, when only approval by an Iman will do), and then reject them out of hand if I haven't had my second cup of coffee. As flippant as I'm being, this has a lot of value. I write with a GUI framework because I don't have to worry my pretty little head about the details of how to draw a checkbox. I ask the system to draw it for me, and it does. It even handles what happens when it's clicked. I just ask the checkbox if it's on or off, and it tells me. If I want a special checkbox, I can make one of those as a subclass, and once I've done that work, I don't have to think about it again, I just use it. Similarly, if I use such a concept of trust, I may have to do some up front work to get things the way I want but I can always use an off-the-shelf validity mechanism. In either case, I just ask the trust framework if the trust assertion is valid. The framework can combine rules of thumb with special-cases as appropriate, and without my having to worry my pretty little head about it. Trust on the sender cannot be proven by the sender (self-assertions cannot induce trust -- e.g., "trust me" doesn't work), but 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. Cheers, Ed Gerck [1] http://nma.com/mcg-mirror/trustdef.htm