Nobody writes:

This mention of "DEATH TO BLACKNET" sounds intriguing. Is this some sort of abusive/harassing message you're trying to track down? With encrypted chaining available to hide the actual subject until the last link, it would seem that the sender is either naive, or else WANTS the Subject: line itself to send some sort of "statement". (What is "BLACKNET", BTW?)

Several months ago arch anti-cypherpunk Larry Detweiler, about to lose his account, set up a daemon to post an edited version of Tim May's old "Blacknet" spoof to random and inappropriate usenet groups. ("Blacknet" was Tim's hypothetical cryptographically anonymous black market for il- legal information exchange.) He happened to use my remailer as a single hop to the net. I logged in and found my mailbox full of people complaining about this message which "I" had sent to sci.med.diabetes and such. So I added a line to the .maildelivery file so that any message with the subject line Detweiler was using would be dumped to a file rather than forwarded. This is the only kind of logging I do, other than recording the date and time at which the remailer sends each message, the source of my previous posting.

This brings up a related question, however. How often, if at all, are you asked to help trace down the source of a message handled by your remailer? Under what circumstances would you cooperate with such a request?

In the year and a half that I have been running this remailer, I have been asked probably a dozen times if I could tell where some abusive message comes from. I am not able to do so since after the message has been sent the information is gone. At best I could insert a log if it looked like something really vicious was going on. Even then, if the sender used chaining then every remailer on the chain would have to anticipate and log his messages (or all messages). My general practice is to add every person who complains about receiving an unwanted message to my list of outgoing blocked addresses.

I've noticed that you have a 510 bit public key for your remailer. Did you choose the shorter length to speed things up, or what? I tend to use a remailer with a longer key as my FIRST link in the chain. Maybe it's overkill, but why not?

I chose the ~512 bit key in recognition of the limited security provided by my remailer. Like every automated remailer, the decryption key has to be on the system essentially in cleartext. I don't come up and type in a pass phrase for every message which goes through. This means that anyone who can hack Unix can learn my remailer secret key. Under the circum- stances, there would be no point in going with 1024 bits, and in fact it would give an entirely false and unjustified sense of security.

And, finally, as a chained remailer user, I've read the periodic "status reports" by fingering "ghio@andrew.cmu.edu" and your remailer must certainly rank as one of the promptest and most reliable. In fact, I think I'll include you *SOMEWHERE* on the chain for this reply... <g>

I can't take any credit for either the promptness or reliability; that is a function of my internet service provider, the Portal system. Frankly, I have not been too happy with the reliability and availability of the system; mail and news seem to fail for 24 to 36 hour periods every month or so, and the system seems to have unscheduled downtime a few hours a week. But I suppose almost everyone has complaints like this. The one thing I will give the Portal people high marks for is that they have never said anything about my remailer. I'm sure some of the nasty letters I have received after inappropriate mail and news postings have been cc'd to the sysops here, but I haven't heard one word. I understand that at the "Hackers' Conference" a couple of years ago the owner of the Portal system endorsed the concept of remailers. (This was reported by Tim May.) Perhaps he is silently offering me some sort of protection. Whatever the reason, I am pleased that I have been able to keep the service going this long. Hal Finney hfinney@shell.portal.com