Additional remailer notes

[rjc@gnu.ai.mit.edu (Ray)]

  I forgot to mention one of the major features of my anonymous remailer
network: robustness.  Each time a chaining request is processed, the
software creates a random id, the time, the remailer used, and the try#, and 
stores that in a file. Every 24 hours, the remailer checks to see if it got 
an 'OK' response in the last 24 hours(signed & encrypted of course) from the 
other remailer. If not, it tries again, this time picking another remailer to 
chain to, or if all have been tried, services the request itself.
The remailer also retains timestamps on all the remailers which it has
received requests from. These are used first before any other remailers
(unless overidden by the user by an explicit chain path) It also shows
up when you request a list of remailer sites.

This insures two things 1) only the "freshest" remailers are used
2) the common remailers used for chaining will be the most popular
remailers used, i.e. have the largest traffic

  One thing the software can not do is return an error/status message to you
through e-mail (it can through a socket). I have some ideas on that too like 
letting users "name" a request, then posting error/stat messages to a 
newsgroup like alt.remailer.errors, or more probably, a mailing list where 
users subscribe to find out whether or not their request worked by watching 
for the request name. This will definately require local email filters on the
user's side to pick out messages they are looking for.

-Ray


-- Ray Cromwell        |    Engineering is the implementation of science;   --
-- rjc@gnu.ai.mit.edu  |       politics is the implementation of faith.     --