Like zero in arithmetic, the "device" /dev/null serves a useful purpose as a kind of "syntatic glue" for Unix shell programs. I wonder if such a "bit bucket" for mail might also be useful for anonymous remailers. A couple examples: * To provide multiple endpoints for a mail message, so that the remailer list becomes a tree (or at least one branch with a bunch of leaves). This might be done with syntax like Request-Remailing-To: remail@tamsun.tamu.edu <remail@tamsun decrypts to reveal> Request-Remailing-To: next@destination.com Cc-Bit-Bucket: hfinney@shell.portal.com Cc-Bit-Bucket: remailer@utter.dis.org where "Cc-Bit-Bucket" causes the tamsun remailer to randomly generate a message of identical size, paste a "Bit-Bucket:" header, encrypt it with the hfinney remailer's public key, and send it to hfinney. When the hfinney remailer decrypts the message and sees the "Bit-Bucket:" header it deletes the message. remail@tamsun repeats this process with remailer@utter.dis.org, and sends the real mail message on to next@destination.com. To the traffic analyzer, bit bucket messages are indistinguishable from real ones (as long as the sender properly encrypted the next message layer with next@destination.com's public key). Remailer bit bucket branching might be useful for adding confusion when it's impractical to delay the mail to mix it with other traffic (either because it's time sensitive or due to lack of other traffic). Bit bucket accounts could be useful if the destination receives a regular, identifying pattern of traffic (eg a unique number or size of encrypted messages). To foil traffic analysis, set up a bunch of pseudonymous accounts at various sites that serve no other purpose than sending and receving bit bucket messages. It then looks like many sites are receiving that pattern of traffic. * To provide endpoints for confusion & diffusion loops. For example: Request-Remailing-To: remail@tamsun.tamu.edu <remail@tamsun.tamu.edu decrypts to reveal> Cc-Loop: 7 iterations: hfinney@shell.portal.com, remail@tamaix.tamu.edu Request-Remailing-To: next@destination.com Does the same as above, except the randomized carbon copy is put in a loop between remail and hfinney (in real life we'll want more than two remailers in the loop). After 7 iterations remail dumps the message, terminating the loop. Instead of "Bit Bucket:" the remailers might paste a loop counter, where 0 causes the message to be terminated. Remailers might set limits on the number of loops and destination sites, charge postage, or both, to make sure these techniques don't soak up the available bandwidth. With sufficient bandwidth and software tools we might get fancy and be able to choose routing patterns from trees, acyclic and cyclic graphs, randomized branching, fractal branching, etc. if we find any such patterns better at thwarting traffic analysis. Nick Szabo szabo@netcom.com