MAIL: chained remailing strategy

[Karl Lui Barrus <klbarrus@owlnet.rice.edu>]

-----BEGIN PGP SIGNED MESSAGE-----

> Can some of the major remailer operators make available some
> "sanitized" traffic stats of average traffic by hour and day of the
> week?

Well, I don't run a remailer at the moment, but I can about ones I
used to run.

One I ran (elee9sf@menudo.uh.edu) batched all incoming messages and
remailed them randomly at midnight.  So in some sense it didn't matter
when during the day mail arrived.  During its operation, the remailer
averaged about 15-20 messages a week, or about 2-3 a day (I don't
remember which days of the week if any were more popular).

Sometimes there were severe usage "spikes", when the remailer would
handle several times its average (once nearly 100 messages in a week,
and 20 in one day).  However, I feel that this was due to users
repeatedly submitting messages - perhaps testing the remailer -
without realizing the remailer only resent at midnight.

I don't know what loads remailers operated with, but more messages
circulating via anonymous remailer would definitely help.

> Can someone familiar with remailer software answer something?  When
> a message is encrypted, using the "Encrypted: PGP" header, will
> everything after the end of the encrypted message itself be ignored?
> I ask, because this seems like a good place to introduce "padding"
> into the message length to thwart detection of identical messages,
> assuming that such extraneous material wouldn't screw something up.

Yes, the extra text is ignored.  In fact, the remailer implemented
this form of padding (however, it only padded messages shorter than 2K
out to 2K).  This isn't the best way to do padding since it is quite
obvious that it is in fact padding.  Hal Finney wrote some perl
scripts which pad inside the pgp message (add random text without
likewise updating the message length field; upon decryption the extra
text is throw away) and this is a better approach.

I think one thing that screws things up (Bill O'Hanlon pointed this
out months ago) is if somebody encrypts a message with the -m option
(for eyes only) - this causes the remailer to hang, waiting for
keyboard input.  I'm not sure if this problem is easily fixable on the
remailer side.

> What's the best strategy for utilizing a given group of remailers 
> in a chain?  Which ones would be most advantageous as the FIRST 

Run your own and use that one as the first link ;)

> How would "someone", hypothetically, follow the chain backwards?  

Hm... I guess exactly the way you describe, by going to each machine
and trying to piece together the remailing path, possibly with help
from the syslog file.

>  What, if anything, would prevent that?

By disabling sendmail logging, if the remailer operator is able to.
(I wasn't able to on any of the remailers I ran).  Of course, other
forms of logging would need to be disabled as well.

> For the sake of argument, let's assume a worst-case scenario: a 
> chained message to "president@whitehouse.gov" containing a 

Well, I'm not sure.  A few months ago, there was only one remailer
outside of the U.S. (in Canada, @extropia.wimsey.com).  However, now
there are several, in the Netherlands, and one in Italy (?).  I guess
it would depend on whether the chain includes out of the country
remailers, if each remailer keeps logs (including syslog which may or
may not be in control of the remailer operator).

All the same, I would recommend remailers block @whitehouse.gov. :)

Karl Barrus
klbarrus@owlnet.rice.edu


-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQCVAgUBLhJHbcSF/V8IjI8hAQEGswP+LmW+DqIOr7UZS82/EVINGn57e+LtBzlJ
0HOonCMuId7DmC7OiqbRyHD2TSHNZB5KrPOVGg7N4QXtuzioJ55e/S9mdMxsSy0G
9oan4UGzMZEyw9rD09KIu5MqG4vt/KVQqpNhy7F8XMZwt9wwlbupeQv1v/92VdRU
rDOlw9pCnZE=
=A4af
-----END PGP SIGNATURE-----