The following is the specifications of the proposed anonymous remailer system ( described by various people here ) as I understand it. 1) all messagess are PGP ( or otherwise ) encrypted to hide their content. 2) real headers and to/from lines are stripped and replaced with a code which the system uses to retrieve that information when the message is answered ( double-blind ). 3) from their first entry into the remailer system, messages are rerouted using one or more of the following methods in attempts to defeat message traffic analysis and tracking: i) random garbage prefix/suffixes used to pad messages ii) multiple messages combined with possibly dummy messages before remailing through random number of stops in remailer system iii) message remailings are delayed by a possibly message-sender- defined amount of time. iv) messages are sent via atleast one non-American remailer Given that my understanding is basically correct, why couldn't the remailer system be set up similarly to the way IRC is? detailed example : When one wants to send a message, she would load up a local Anonymous Internet Remailer (AIR) daemon which would attempt to connect to one of the AIR clients running elsewhere on the Internet. Then she would send a PGP pre-encrypted message down the line, prefixed with the e-mail address of the person who is to receive the message. At this point, the AIR-client sends out a general message to the other AIR-clients. This message contains an encrypted copy of the receiver's e-mail address. The response to this message is two-fold. First a response is circuitously sent back to the original AIR-client, telling it that an alias has/has not already been assigned by that AIR-client to the receivers e-mail address; further, if one has been then a reference number would be assigned to the message ( which it does not have a copy of ) and be sent back in the same message. Second, if the alias exists then the responding client sends a circuitous message to the receiver's e-mail address telling him that he now has AIR-MAIL waiting for him. If none of the responses about the alias are positive, then one is assigned by the original AIR-client, and encrypted 'add new alias' messages are sent to two other randomly selected AIR-clients to ensure that the alias is redundandly recorded. The original AIR-client would then assign the reference number to the message. In either case, the reference number would always be used to reference the message. The encrypted message is then sent circuitously to a random number of other AIR-clients. After all of these have responded to the original AIR-client that the message was received, the original AIR-client would then choose atleast two of them ( again for redundancy ) to keep the message, all others to purge it. This same encrypted hold/purge message would then be sent circuitously to ALL of the holding AIR-clients. Finally the original AIR-client would purge its copy of the message. (this does not however, preclude the original AIR-client's being one of the holding AIR-clients) The AIR-client <=> AIR-daemon and AIR-client <=> AIR-client connections could invisibly handle further encryption and padding. Finally, the message needs to be picked up by the intended recipient. He would run the AIR-daemon on his machine, which would then connect to one of the AIR-clients ( this being hereafter the receiving AIR-client ). He would send the message reference number, which the AIR-client would then encrypt and send out in a general message to all of the other AIR-clients... requesting that they send this message. If an AIR-client has the requested message then it pads, encrypts and sends it... otherwise if the AIR-client does not have the message it creates a garbage file which it encrypts and sends to the receiving AIR-client. The receiving AIR-client would then send one copy of the message with the correct reference number to the receiver's AIR-daemon, where it could be saved on disk. This system has several advantages over a purely e-mail based system: i) messages would no longer be limited to 60k in size as it is now, due to the fact that none of the messages would actually be sent via e-mail. ii) every site and daemon could have a unique encryption key for use by the other sites. iii) even if the message is tracked to its holding client, the trackers still have to chase it again when the receiver requests its delivery. iv) the receiver need not necessarily be at his home e-mail address when he requests the message. he could choose to run the AIR-daemon on a remote host several rlogins from his home site. v) if coded well, any user could run an AIR-client on her home site, thus permitting the network to grow to hundreds or thousands of sites very quickly, each with much lower overhead than the current non-networked, anonymous remailers available. Futher, as administrator of that particular AIR-client, the user could configure her AIR-client's involvement in the overall AIR-network based upon the resources of her system. She could for example, choose that her site be only a remailer site and not a holding site, or vice versa... thus adding further message tracking problems for any snoopers. Futher hairyness which could be added: i) AIR-daemons could accept command-line parameters rather than being full interfaces, thus allowing redirect. ii) listserv software could be configured to allow connection to the AIR-network, thus allowing someone to send a PGP-encrypted message to the listserv for forwarding via the AIR-network. A further advantage of this is that users from non-Internet sites, such as CompuServe or RIME could still make use of the remailer. iii) the receiver could send the message code to a listserv for message retrieval. iv) when a user starts up an AIR-daemon on his machine, make it automatically continue to run and become another non-holding bounce site, thus accounting for why messages are suddenly being sent to a non AIR-network site. v) one could have several completely separate AIR-networks running on the Internet. These would dynamically expand as more people ran daemons. Constructive comments solicited... -Garet {Garet.Jax@nitelog.com}