Re: Frothing remailers - an immodest proposal

[kevin@elvis.wicat.com]

>1.  Broadcasting every couple of minutes isn't necessary and is undesirable
>due to the real limitations of the Internet.  A remailer could broadcast
>its location with a time-out on the location without a constant stream
>of availability announcements.  In your position for example, you'd
>broadcast a message at 5 pm with a 16 hour valid time.

True, but this has two basic assumptions that I disagree with: first,
that we can guarantee delivery of a broadcast message to all interested
sites; and second, that remailers never go down for unexpected reasons.
When the day comes that both networks and software are perfect, this
method will be reliable. Of course, you are also right that broadcasting
is undesirable; that is why I am pondering a way to minimize the impact.

>2.  This is actually unnecessary for your situation: All you need to do is
>advertise your location as a "real" remailer and then have a cron job that
>kill sendmail at 5pm on your remailer machine (assuming you have a spare
>machine that doesn't need to run sendmail).  The mail network is flexible
>enough that things will Just Work.  Mail won't go through instantly during
>the day, of course, but that just helps to muddy up the mix.

But, if my understanding of remailer operation is correct, this has two
potential problems: first, I will still receive mail during the day,
causing a bandwidth concern (I know, it's probably not a problem right
now, particularly since users will probably choose to avoid a remailer
with a possible 16 hour delay); and second, the machine delivering mail
to me simply has to trust that a remailer will in fact pop up on this
machine to process the stored mail. There is no way of determining that
mail is not simply going into a black hole. And even if I try to be nice
when the mailer goes down permanently and tell everyone not to route
mail through it any more, that news still has to travel via word of
mouth to all users of the web.


>
>3.  Broadcasting over live IP isn't all that great a model.  Ideally,
>you'll use a mechanism that doesn't require instant communication among
>hosts.  I favor USENET for this: messages have a naturally long life-
>time and the network is self-adjusting.  If a direct route is temporarily
>unavailable, an indirect one will often manifest itself.  I also favor
>using USENET store-and-forward for the messages themselves for the same
>reasons: traffic analysis is impossible inside the web and direct routes
>are not necessary.

I am not happy with my proposed advertising methods, and was quietly
hoping for some guidance from internet gurus in this point (the irc
suggestion in particular is a pretty shaky straw man). However, see my
earlier message (on some other thread) about Usenet propagation times.
Propagation times in days do not seem to be rare (post to misc.test and
see when the last reply comes back). While this is better than
word-of-mouth propagation, it does not offer the very low latency I was
looking for.

>4.  Using a PGP-style web-of-trust is important.  In the ideal situation,
>one human in an extended web can certify individual remailers and all other
>remailers close enough on the same web of trust would pick up the message
>immediately.

It strikes me as critical; right now, a user has to choose to trust a
set of remailers, given no assistance other than a list of "reliable"
ones. Given an extended web of trust between remailers, the user can
choose to trust one remailer (I have no idea how to make this process
more palatable) and immediately gain the security of a large web of
remailers (maybe you are right about that instant gratification
thing...)

    Kevin