I think the recent death-threat-to-Clinton desaster has made clear that the remailers we have are not very secure, mainly because incoming and outgoing mail seems to be monitored at many sites. Even the current pgp encryption scheme offered by some remailers doesn't help much, once the incoming and outgoing messages are known: just take the outgoing message from the remailer, encrypt it with the remailer's public key, compare this to the incoming messages and you know who sent this message (repeat if a chain of remailers was used). Here's a proposal which could close this hole: remailers should allow for a new header 'Encrypt-with:' which takes as argument a public pgp key. This is used just like the 'Request-Remailing-To:' header, i.e. using the '::' construct in the body of the pgp encrypted mail. ('Encrypt-with:' offers no additional security if no pgp encryption is used in the first place.) The semantics is that the remailer, just before passing the message along (and after having decrypted it, of course) encrypts the message using this public key and adds an 'Encrypted: pgp' header to it. To make sure that no remailer on the way knows the contents of the message, we should add one more mechanism: Whenever a remailer encounters a message with an 'Encrypted:' header, and the decrypted message contains another 'Encrypted:' header, the remailer decrypts it again. (Perhaps this feature exists already?) In this way, even if someone knew the contents of every incoming and outgoing mail of the remailer, they couldn't tell which incoming message produced which outgoing message. To trace a message back to its origin through a chain of remailers, one would have to know in addition all the secret keys on the way (except the first one). Axel