There must be some correlation between my weekend trips and other events. Last time I went out of town was "Cliper weekend" :-) I've tested the remailers with unencrypted requests, and have received these replies (within seconds, I might add): soda.berkeley.edu cicada.berkeley.edu pmantis.berkeley.edu bsu-cs.bsu.edu alumni.caltech.edu rosebud.ee.uh.edu mead.u.washington.edu shell.portal.com tamsun.tamu.edu tamaix.tamu.edu <-- note, 'Return-Path: remail@tamaix.tamu.edu' 'From: remail@tamsun.tamu.edu' just in case you see the from line and think tamaix isn't working So I'll wait for the others (rebma, extropia, utter, uclink, jarthur) and then try them all with encrypted requests. A while ago I had a script test all the remailers once a week - I wasn't able to have a cron entry, but I used the 'at' command to schedule the mailing of prepared messages and itself every week. Maybe I'll start that up again since it would help isolate problems if a remailer doesn't respond, especially if twice in a row. /-----------------------------------\ | Karl L. Barrus | | elee9sf@menudo.uh.edu | <- preferred address | barrus@tree.egr.uh.edu (NeXTMail) | \-----------------------------------/
I've been thinking a little bit about the problems with unreliable remailers. Supposing that we can never rely on the reliability of all the remailers in a given path (because of not just bugs in the software, but political hassles) it would be good to figure out a mechanism by which a problem can be noticed. For example: supposing that I made the following mail path :: Request-Remailing-To: hh@soda.berkeley.edu :: Request-Remailing-To: remail@tamsun.tamu.edu :: Request-Remailing-To: hfinney@shell.portal.com :: Request-Remailing-To: cypherpunks@toad.com Suppose that remail@tamsun.tamu.edu wasn't working. Maybe it would be possible for the remailer to notice that the next address in the hop is a remailer, and check to see whether the next remailer is working or not. (Send a ping-message.. This would slow things down greatly, yes.) Then if the remailer isn't working, something can be done. (Maybe figure out some way of telling the originator [through encrypted return-paths] that a certain remailer isn't working) This idea (obviously) isn't fully thought out. There are some glaring problems with the system in that it would end up destroying a good deal of the anonymity in the system. It might be possible, however, to modify this idea to make it workable. It is definitely likely, in my mind, that remailers will continue to be unreliable as long as net-anonymity is a controversial topic. -- | Sameer Parekh-zane@genesis.MCS.COM-PFA related mail to pfa@genesis.MCS.COM | | Apprentice Philosopher, Writer, Physicist, Healer, Programmer, Lover, more | | "Symbiosis is Good" - Me_"Specialization is for Insects" - R. A. Heinlein_/ \_______________________/ \______________________________________________/
On Mon, 28 Jun 1993, Sameer wrote:
I've been thinking a little bit about the problems with unreliable remailers.
Supposing that we can never rely on the reliability of all the remailers in a given path (because of not just bugs in the software, but political hassles) it would be good to figure out a mechanism by which a problem can be noticed.
I've thought about this as well. I don't think it's right to _ever_ keep return path information in a cypherpunk remailer, even for error reporting. Far better to just drop the message on the floor than provide a loophole to the anonymity of the system. That said, I think there are possible solutions to the problem of vanishing remailers. Let's say there is a method to quickly and easily verify the continuing existance (or lack thereof) of a remailer. When a remailer receives a request to send a message to another remailer, it can quickly check to see if that remailer is in operation. The question is what to do with the information if it turns out the remailer is really down. If the message is unencrypted, a smart remailer could simply skip the missing remailer or send the message on to a substitute remailer, which would then pass the message down the chain. But if the message is encrypted with each remailer's key, it is undeliverable without that remailer to decrypt it. My idea is for remailers to share their private keys using a secret-sharing protocol. When a remailer goes down, all the other remailers that hold pieces of its key would choose a replacement remailer and send it the key pieces. From then on, all mail for the missing remailer would be routed instead to its replacement remailer, which would decrypt and process it as usual. It would be quite a pain to implement, but would make large remailer nets a lot more reliable if it's done right. Joe
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}
In article <Pine.3.07.9306282132.A8310-b100000@access.digex.net> Joe Thomas <src4src!imageek!access.digex.net!jthomas> writes:
[...] Let's say there is a method to quickly and easily verify the continuing existance (or lack thereof) of a remailer. When a remailer receives a request to send a message to another remailer, it can quickly check to see if that remailer is in operation. [...]
But how would this be done? The first way that comes to my mind is spooling the message in a queue of some sort, sending a "ping" message to the next remailer in the chain, and waiting x minutes for a response. If a response does arrive within x minutes, that remailer is considered alive. But what is the value of x? It can't be too short - the remailer might be on a slow link. For example, I have a remailer running on my machine, which is connected via uucp. The turnaround time of a "ping" message would vary from about 35 minutes to upwards of 13 hours (I don't connect at all from 0855 to 2205 EDT). But the longer the delay, the slower the whole chain runs. If one popular remailer goes down, all messages routed to it would be delayed at least x minutes, which is better than the bit bucket - but with x being, say, 1440 (one day) the delay would not be trival. There also might be security issues with the spooling of the messages. I just wrote a couple extra perl programs for the remailer that do part of the above. I'll try to put them on soda, called "morpheus-remailer-hack" or something similiar. They add another header (called "Request-Safe-Remailing-To for now - please send better suggestions!) that acts just like R-R-To: but spools the message and sends out a email ping, then waits to send the actual message until it gets the "ok" message back. It's slow and ugly, but it seems to work (it works with itself, anyway ;-) There's probably lots of locally-dependant stuff in it (like the MESSAGE_ID and VISIBLE_NAME enviroment variables, etc) that will need to be fixed. The big problem with it at this point is that it's useless - there isn't any code to deal with the "no response" condition. A simple script ran from the crontab could check timestamps in the spool area and do something if they were more than x minutes old - but _WHAT_ should it do? Maybe a better idea would be to add a Recipt-Requested header instead of doing the email ping, which would have the receiving remailer send back an "ok", but continue with delivery.. Then the sending remailer could delete the spooled message, otherwise if it didn't get an ok it would try again at another site. Better or worse? -- morpheus@entropy.linet.org Non serviam! Support your local police for a more efficient police state.
participants (5)
-
Joe Thomas -
Karl Barrus -
morpheus＠entropy.linet.org -
Nickey MacDonald -
zane＠genesis.mcs.com