Would it be a good idea to have a re-mailer "randomly" decide whether to send the mail to the destination or to another re-mailer.

No. The remailer user should be presumed to know what s/he wants. Some remailer users may want to optimize for speed and certainty of delivery and therefore use a short chain; other users may want to optimize for more difficult traceability, and consequently choose a long chain. Remailers shouldn't try to rewrite the user's (perhaps) deliberate balancing of these factors. Also, users may choose to use or not use certain remailers based upon their policies, the reputation of the operators, the legal rules affecting the operators, and so forth. These choices should also be left to the user and not overridden by third parties.

If all re-mailers performed this way, not even the sender would know the path.

I don't see why this is useful. As things work now, only the sender knows the path, assuming chaining and nesting encryption. How does taking away the sender's knowledge add security? Adding hops to the chain requires that remailers keep track of other remailers; a robust way of doing this would require that they also keep track of reliability, because deciding to add a downed (or unreliable) remailer to a chain would be harmful. To prevent an active and hostile eavesdropper from adding itself as a remailer eligible to receive extra hops (and then dropping or logging the traffic), this remailer status information should be provided by a trusted source in a secure manner. All of this (adding remailer status tracking based on frequent updates of digitally signed information from a trusted third party) can be done, but it's a pain in the ass to code, and it doesn't add anything that users can't get for themselves. (Users who want long difficult-to-trace chains can already generate them. They can also let software generate random chains at the source.) It also may degrade performance for users who value speed and reliability over untraceability. So I suggest that it's not very useful. The best way to implement this would be to modify remailers to use "Anon-To: random" or "Random-To: xxx@yyy.zzz" header commands, such that users who desired the random hop behavior could get it, but users who didn't want it wouldn't get it unexpectedly. (Isn't some remailer doing this already? I've lost track.) -- Greg Broiles | "We pretend to be their friends, gbroiles@netbox.com | but they fuck with our heads." http://www.io.com/~gbroiles | |