Additional remailer notes
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. --
participants (1)
-
rjc@gnu.ai.mit.edu