Paul Hoffman wrote: > Tony's proposal is not for new software: it is for software that > *replaces* what they have now. Further, it is not a one-to-one > replacement. It requires new administrative actions by the sysadmin > and by the user to validate who they want to get mail from. The sysadmin effort would be setting up an automated way to hand out keys, and the user would have a one-time (or very infrequently) effort to establish a key pair. All the processing would then be automatic. If the message couldn't be decrypted, or the signature verification returned the wrong result, the message would simply be dropped. This keeps everyone except the originator and receiver out of the content inspection business, yet provides the receiver with an undeniable link back to the originator for anything that gets delivered. When the receiver decides that the content wastes resources, they get to decide the appropriate action to take against the identified origin. This approach does not prevent spam, because the spammer could set up their own public key service. It does keep the IETF out of defining spam and how to identify & filter it, the service provider out of the business of content inspection, and has a fairly straight forward set of technical bounds to build products against. It increases the cost to the spammer by seriously reducing the number of messages per minute they can send, and it creates a traceable record to the spammer (well at least to the key service). Existing legal infrastructure should be sufficient from there, but I can imagine that politicians would want to claim they were doing something about the problem and might dream up new laws, or mandates to deploy such a technology (I am not arguing they should, just predicting their actions). Tony