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
I have an idea I don't think has been proposed before. There has been a lot of discussion of having "background noise" by having remailers mail random messages to various bit-buckets and other remailers on a constant basis. But why not do it this way. If a remailer recieves a message of size N, it holds that message for a short (< 15min) period of time, and then it sends out X (5 < rnd X <15) messages of size N, some going to remailers as noise messages, some going to bit buckets as dummy recipients, and of course one heading on it's origional route. One problem with this is that messages would multiply, ie. 'A' sends to remailer 'B' whichs sends 10 messages out, 5 to other remailers who in turn send out 10 messages a piece, 5 of which goes to other remailers who again multiply this. And you end up with one of those annoying commercials, where, he tells 5 friends, and they tell 5 friends until the network shuts down. So Remailers must establish some code (which would be send pgp encrypted) that would give a message a max possible life span of say 5-10 generations. (even that may be too much) Well it is just my $.02 (and Canadian cents at that!) Rob "Remeber, the day after tomorrow is the second day of the rest of your life." Unknown.