From: "Pat Farrell" <pfarrell@netcom.com> Re: majordomo alterations so that it pipes messages thru a filter to classify signatures. [...] We get classes like: [5 listed] What I was thinking was the following. There would be a recognizer that, given a message, would output "yes, something looks like a signature to me", or "no, there is nothing that I recognize as a signature". Based on this true/false answer, the server would either perform an action, or not. I was thinking of no notion of classes, but rather mere presence or absence. Maybe we need to have majordomo sign the message/header so we know that the true c'punk classifier has verified it? WARNING: The following paragraph does not have direct relevance to the issue at hand. It discusses servers which might verify signatures, which my current proposal does not have in it. What I have realized in the interim is, that if a server is to verify a signature, the server should sign not the message but rather the signature. After all, the signature is what was being verified, not any property of the message. The user can still detect message alteration, by first verifying the sig-on-sig, and then comparing the hash value in the original sig to a hash on the message. But then we ask, Hmmm, is this a hacked majordomo? After all, no sane person will read and manually verify the flood of c'punk messages. So some daemon is doing it all. And daemons can be hacked. Trust always terminates somewhere. How far back you go is a question of worth and of effort. Ceding some trust to toad.com may be desirable for some but not for others. Merely because it is not a complete solution to all problems doesn't mean it's not worth doing. anyone else see a solution? I do, but it involves program+proof ideas and is far from ready for deployment. I have no interest in solving those problems right now. There is benefit to be had from crypto, even if the first implementations only protect certain things. Eric