Dean Anderson wrote:
On Tue, 16 Mar 2004, Ed Gerck wrote:
For example, saying that you're "god(_at_)heaven(_dot_)org" should not be so
easy to do when you're sending email, even though it should still
be easy to set "god(_at_)heaven(_dot_)org" 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