Eli writes regarding my Totally Anonymous Mailing scheme:
A problem here. The SEND system eliminates the risk of database seizure, and encrypting mail to the remailer eliminates snooping on incoming mail, but outgoing mail is unprotected. Anybody watching net traffic coming out of the TAR can snoop the destination of SEND requests, and reasonably presume that address to be the owner of the nym. This is of course a problem with a penet-style setup too, but it's something to fix if you want to be "totally anonymous".
I don't think this is a problem. The send command is received by the mailing system encrypted by the mailer's public key. An outside observer can't decode the message. When it gets the message, the mailer decrypts the envelope, and gets the sender's pseudonym and an encrypted command (encrypted with the sender's private key). The mailer knows the pseudo's public key, so it can decrypt the command. If it is a spoofed command, the mailer gets junk, and merely sends email into the psuedo's account giving details of the intrusion attempt (which might just be an error on the owner's part). The outgoing mail packet(s) would be encrypted by the pseudo owner's public key, so only he could read them. Some mechanism might have to be added to prevent an irritating "spoof" attack where the attacker records an incoming message and merely duplicates it. This might involve having the server remember the last couple of weeks of command transactions, reject duplicates, and reject any messages more than a week "old." This would require a timestamp in the encrypted part of the message. The part of the proposal that really needs work is methods to make traffic analysis prohibitive. I suspect that a net of cooperative mailers, along with the ability to delay the relay of outgoing mail, might help in that regard.