REMAIL: problems

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

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.

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}