-----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-----