Again, the best way to build a secure remailer is to have one that sends a fixed "remailer-packet" to other mailers for internal communication with other remailers on the "network" These packets should all be super-encrypted and of a fixed size. This size should be as small as possible. Say around 200K or so. Why? Because this serves to prevent email spamming by severly delaying a message. Also if there is some quota of say, no more than 100 messages a day from a user, it serves to limit spamming quite a bit. Basically all incoming mail is spooled on the remailer's hard drive in encrypted form by the remailer. When a new message is sent to the remailer, the remailer will go through all the received messages and look for duplicate messages and also count the number of messages sent by the user who just submitted another one. At the end of the day, at a certain hour agreed upon by the remailer operators, the remailer will split up its cached messages and split them among several remailers with a RANDOM number of hops set in the message. These packets will then be randomly padded inbetween messages with null messages which would be eaten by the receiving remailer. The padding serves to limit traffic analysis and the automatic hop number helps idiot users from being caught. The packets will then be compressed and then would be encrypted with the respective public key of the target remailer and sent as a fixed sized block again with rand padding at the end... perhaps via ftp or some other protocol, but not necessarily via sendmail. Having them as binary makes them easier to handle than by sendmail... When the packet is received by a remailer it would first decrypt it, then decompress it, then remove null messages, then decrement the number of hops and if it's zero, it would invoke sendmail to send them. I strongly suggest that the remailer packet protocol be openly published so that users can build their own packets to forward to remailers in encrypted form rather than using sendmail. I suppose that using sendmail to a remail should still be allowed, but slowly phased out so as to force users to encrypt their email. Client software can be written for Windoze and Macs to use TCP/IP or even Zmodem a packet into a remailer. You may think that spamming can still occur by allowing users to send packets themselves, however if the recepient remailer will limit the size of a packet it will receive to a very small size (especially if it's coming from an unknown site,) and refuse to receive more than one packet per day from that site, it would prevent a lot of spamming and creeping detweilerism. Perhaps remailers can work out a set of special private keys which they share between them to speed up mail, or the size of the packet can be increased for remailer-remailer transfers. Anyhow, the system has to be balanced so that mail gets there in at most a day or so, at best only a few hours depending on how often remailers talk to each other. If traffic at a remailer should suddenly increase, the remailer should issue instructions to the other remailers that it'll send larger packets or send more often. But only after it receives permissions from the other remailers should it send. Perhaps if a remailer is too filled it should bounce a message to the sender (if it knows his/her address...) or perhaps they can be polled to see if they're busy, or better yet, the message can be forwarded to another remailer in the old fashioned way (losing some security I guess)