Re: soda.berkeley.edu back.

[catalyst-remailer@netcom.com]

Eric Hollander stated some reasonable concerns about my using the
Cypherpunk remailers....

I have every intention of trying to be as responsible about this as I can
be. I may sound cocky about it at times but I am doing that on purpose to
try to get some attention to my questions. I am genuinely interested in
which remailers can take some traffic. You all DID ask for more traffic.
Here are some random thoughts.

1) Five 40K mails sent at in a row, maybe 3-5 sec. apart doesn't feel like I'm
mail-bombing a remailer. Were these 400K I'd feel pretty guilty. If I'm feeling
like testing limits, I might send 20 mails instead (to myself) but so far this
hasn't caused even a glitch. Soda and cicada seemed to go down out of the
blue, not in the middle of one of my tests. Soda just added a delay of an hour
so that's not really "dead", but cicada did have a heart attack once and bounced
a few mails before recovering.

2) I will never send this package of five mails (~18-46K each) to any mailing
list  unless I do it by sad mistake. I am receiving 6-12 or more messages a day
with  Subject "Bomb me!", so I wouldn't call this unsolicited. The only time a
person  will get the package without asking me personally for it is if they post
to Usenet or this mailing list asking where to get info on PGP. If you are
worried about this I could certainly switch to just sending a note for them to
send me a "Bomb me!".

3) Before I send off a round in the morning (usually about 5-6 "Bomb me!"s), I
send a small "Ping!" message to all the remailers on the list below to make
sure they are working.

4) Here is a list of remailers that I am considering and my experience
with them. I am personally only interested in fast ones (less than 1 hour
delay). I have tagged  a header onto each of my mails telling people NOT
to reply to the remailer address and to try again the next day if one part
doesn't get through.

      1  hh@pmantis.berkeley.edu <-[Very fast.]
      2  elee7h5@rosebud.ee.uh.edu <-[Very fast.]
      2  hfinney@shell.portal.com <-[Fast. Warning header.]
      1  hh@cicada.berkeley.edu <-[Very fast, may die and bounce mail.]
      1  hh@soda.berkeley.edu <-[Very fast, may add an hour.]
      ?  catalyst@netcom.com <-[Fast. Warning header.]
      2  ebrandt@jarthur.claremont.edu <-[Fast, often adds an hour.]

      ?  nowhere@bsu-cs.bsu.edu <-[Fast, but removes Subject header!]
      ?  remailer@chaos.bsu.edu <-[Fast, but removes Subject header!]

      1: Remailer accepts only plain text headers.
      2: Remailer accepts both plain text and encrypted headers.

5) I am trying to get a perl script to output csh shell variables instead
of printing  to the screen. Help. I want to make the remailing route
random, thus. Alan Barrett has just posted what I think is an answer to
how I could do this. Maybe I should do the entire thing within perl? I'm not
having much fun reading 'man perl'.

6) Question: should I or should I NOT chain each piece between two
remailers. Will this  increase the load? It is certainly what I've heard
people dreaming about here. I have a mental block concerning what the
effect on remailer load this would have.

7) I would appreciate, as would many, a short list of remailers and some
specs about their qualities and an idea of who is running them, and how
stable they have each been in the last year. catalyst@netcom.com seems
durable, and yet I'd never heard of it till someone just mentioned it in
this mailing list. Are soda and cicada indeed fragile (should I use them)? When
they are up I seem to be able to use them without a problem. Why is jarthur
sometimes very fast and other times adds an hour or more delay?

-Xenon

P.S. Remailer stablility is especially important when chaining remaliers, since
bounced messages will never get back to you. I feel that a next generation of
remailers should not just be concerned with security but with total
internet-like e-mail reliability, as well an easy return address option so I
can use them with more people. I think command-line interfaces are going bye
bye fast, for those who will be the majority of e-mailers in the near future.