On 3/17/2004 10:47 AM, Ed Gerck wrote: > "Eric A. Hall" wrote: >>Not applicable to sales@ or emergency@ type mailboxes. > > Why? Should someone arrive at your Sales or Emergency window > in your office, naked, what would you do? uh, public nudity is (mostly) criminal, so not a good analogy, although comparisons to a "no shirt, no shoes, no service" policy statement would be getting there. A better analogy is with new checking accounts. Many places won't accept checks numbered below 1000, since they indicate that the account has not established a track record. Other places will accept the checks after verification, other places will accept them with thumbprint or some other identifier. In all these cases, the organization is able to determine its risk limits and act accordingly. I'm not going to get sucked into this endless debate, but it is equally tyrannical to require everyone use some kind of hard trust as it is to require everyone use no trust (what we are moving away from, in blobbish fashion and pace). There must be consideration for exceptions; the swimming pool snack bar probably cannot enforce a "no shirt..." policy. Property rights (of which I am a big advocate) "work" because they can be selected and enforced at the owner's scale; people can put up "no trespassing" or "no solicitation" or "no hunting" or "no shirt..." signs to advertise their chosen policies. The same kind of mechanism is needed for property protection to work in networking as well. > Note that this is nothing new. We already do this with IP numbers. > If you send me a packet with a non-verifiable source IP there > will be no communication possible. Why should it be different > with email addresses? Verification is different from trust. My position is that you need to be able to validate and verify before you can successfully apply any kind of trust (otherwise the trust is meaningless). Paul's message that I replied to was specifically describing a minimum threshold of trust (it was akin to the "no checks below #1000" position). -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/