It's not very clear how long the delays should be; depends on traffic to/from your remailer and to some extent to/from the other sites your remailer cooperates with and the machine it runs on. If the delay is near-zero, relative to the rest of your traffic, traffic-analysts can see mail going to your remailer, followed quickly by similar-sized mail going to another location, and guess that the two are related, especially if they're reading the mail itself. (For instance, if netcom is a bunch of machines on an Ethernet, and somebody breaks root on one of them, packet-sniffing the net may catch a non-trivial amount of your mail going in at least one direction. It's certainly easier than tapping all the phones if you don't have a warrant.) How much you need also depends on your threat model - do you expect monitoring by netcom users only, active monitoring by root, logfile examination without ongoing monitoring, etc....? If there are a bunch of other messages in between, especially if you're sending most of them to the same destination (e.g. instead of always choosing a random remailer to send through, you pick one remailer and send a batch of N messages to it; and maybe use a different remailer for the next batch) then it's harder to correlate incoming and outgoing messages. One strategy for batching is to accumulate N messages and send them at once, rather than delaying for N minutes. This may cause rather long delays, unless you either get lots of traffic or else give up and send the real message and some fake ones after rand{5..N} minutes. (If you use fixed N, it's easy to track when traffic is low.) Bill