On Mon, 28 Jun 1993, Sameer wrote:
I've been thinking a little bit about the problems with unreliable remailers.
I had another suggestion that might be helpful for people that are chaining through many remailers, but it would require an addition or two to existing remailers. I'm not sure how to make clear what I mean, but lets start with a proposed sample message: :: Request-Remailing-To-Remailer: hh@soda.berkeley.edu :: Request-Remailing-To-Remailer: remail@tamsun.tamu.edu :: Request-Remailing-To-Remailer: hfinney@shell.portal.com :: Request-Remailing-To: cypherpunks@toad.com {Message body goes here} I'm sure you caught the change... You identify for the remailer when the next hop is supposed to be a remailer. Just by itself, this is of no extra help, but hopefully of little extra bother because the old style would still work. Now how do we make it more reliable? If the remailer knows that the message is going to another remailer, it can expect a 'reply' from that remailer once the message has been processed (forwarded), say within 48 hours. Give each message a serial number and the remailer a memory... If the message is not acknowledged within the timeout period, it skips a hop and goes to the next remailer (or the destination). This could also be expanded to let each remailer tell other remailers about itself... it could maintain a database of known remailers. The problem with this approach is that the remailer must store messages locally for up 48 hours (well more if all of the hops were down)... I can't see (as Sameer alluded to) a way to have reliability (which sort of implies, especially with the above approach, storage) and secrecy (which implies quick and dirty 'less safe' message handling). I have source code for serializing things (file access is what it was designed form but I have found lots of neat uses for it). It really quite simple code, and not completely portable (well it uses flock(), not all versions of un*x support flock()...) I wrote the serializer to make sure that my mail alias did not allow more than one copy of my email processing script to run at once (thus creating very nasty log file collisions!). Comments? -- Nick MacDonald | NMD on IRC i6t4@jupiter.sun.csd.unb.ca | PGP 2.1 Public key available via finger i6t4@unb.ca | (506) 457-1931 ^{1024/746EBB 1993/02/23}