From: "L. McCarthy" <lmccarth@ducie.cs.umass.edu> I foresee a situation in which a large portion of the list traffic uses forged or meaningless signing-server-appended dig sigs. When I establish automatic signature validation for incoming mail here Real Soon Now, there will be plenty of noise generated by all the `false' negatives in the data to make a mockery of the authentication process. Recall my comments on transaction failure in a different context last week. What is important there is what happens under failure, not under success. Sig checking requires an analysis of the pragmatics of failure, i.e. what happens. What seems abundantly clear, no matter what actions are taken, is that it will be actions plural rather than action singular. The decision process to decide what happens is much more significant architecturally that what actually does happen. An embedded action, i.e. a hardcoded policy, would be bad, and since sig failure handling is a relatively unexplored area, one can do it right the first time. Assuming such a failure recovery decision process, the actions are simple: ignore, flag, discard, bounce, get key, etc. None are particularly difficult; the decider is what is hard. Now, assuming both decider and actions, you can very simply ignore all sig failure for cypherpunks. Encouraging cryptographically valid signatures was the first suggestion I'd seen in this entire debate which seemed to promise tangible benefits; Syntactic checking also encourages valid signatures, just not as strongly. encouraging cryptographically invalid signatures is the first notion which appears to offer tangible detriment. It's a problem that won't go away that the existence of bogus signatures merely make the problem imminent and proximate. Eric