[...]
paranoid). This would make traffic analysis much harder because once the message enters the remailer system it bounces around so much; the remailers become a black box that deliver the message without really knowing anythign about it until the last phase of delivery.
I'm not sure what you mean about bouncing it around to different remailers, because if there are a lot of remailers, it could take a long time before it finally gets to the appropriate one that can decrypt the destination information (perhaps longer than the TTL and therefore it does not get delivered). With encryption, the remailers don't have to know the recipient until the last phase anyway. In addition, they may not know the contents of the message either.
I set the "breakout counter" at 10 and throw it into any port on the remailer web. It bounces around 10 times and then the "deliver this damn message" flag gets tripped and the TTL counter starts. The TTL counter is actually the number of hops from this point on that the message will traverse looking for someone who can decode the encrypted destination address before the message dies or is otherwise checked for problems. It could take a long time to deliver the message, but time latency is another possible means of confounding traffic analysis. What I was basically thinking was that the breakout counter tells the message how many times to randomly bounce around the internal structure of the remailer web (and hopefully becoming lost in the clutter) before it tries to find someone who can deliver it; the TTL would be used once the breakout counter had hit zero and would try to keep a message from bouncing around forever if there is an addressing problem. This would obviously increase the complexity of the system and require a collection of remailers scattered across the net, but it seems to me to have the advantages of providing more security as the number of remailers grows and to allow bepopel to set up thier own forwarding and addressing that is independant of the remailer system (you generate your own destination certificates and can string together whatever you want in the destination, even another hop back into the remailer system.) It may be overly complex, but it just seemed to me that it might offer the possiblity of truly untracable mail: two messages sent into the same entry port with the same destination certificates at the same time could end up coming out of two different exit ports on the black box depending on how they bounced around inside the system. If you want someone to be able to send you a reply to an anonymous message you give them a destination certificate that contains the destination you want the message sent to wrapped in various remailer pubkeys (one or more, it is up to you). They do not need to know where the message is going, they just attach the certificate to thier message and drop it into _any_ remailer and know that it will either get to the destination or get bounced back to them. A distributed anonymous remailer system of sorts... jim