From: Nickey MacDonald <i6t4@jupiter.sun.csd.unb.ca>
Date: Mon, 28 Jun 93 22:31:09 PDT
To: cypherpunks list <cypherpunks@toad.com>
Subject: Re: REMAIL: problems
In-Reply-To: <m0oAU20-000MU8C@genesis.mcs.com>
Message-ID: <Pine.3.05.9306290204.A16729-c100000@jupiter>
MIME-Version: 1.0
Content-Type: text/plain


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}