dlv@bwalk.dm.com (Dr.Dimitri Vulis KOTM) writes:
With the present scheme, if a remailer is "raided", it has precious little interesting stuff on it at any one time. Now consider the scenario:
X sends 1000 copies of child porn/seditious libel to 100 people believed not to be using remailers right now. The remailer keeps the 100 e-mails onits hard disk and e-mails each receipient a ping, inviting them to agree to the disclaimer terms and to retrieve their anonymous e-mail. The first recipient to retrieve the e-mail gets upset and contacts the feds. The feds figure, the remailer still has the 99 other e-mails and the information on who's supposed to receive them in its queue; why not seize it and take a look.
This is a potential problem, but there are some other considerations. First, there is no particular reason why one recipient of some email from the remailer should know or even suspect that other people have the same email waiting. Then, to defend against raids like this, the material could be separately encrypted to each recipient. There would be no way to know that material sent to one recipient matched material sent to someone else. The raiders would just find a bunch of encrypted files. Of course, if it were a sting operation, with the recipients being lured or entrapped into requesting information they shouldn't, then the sender might avoid using these countermeasures. However, there wouldn't really be any need to use a remailer for a sting operation like this, it could be done just by offering the material from an ordinary address. More generally, I think we need to keep in mind what a remailer does and what it doesn't do. The essential function of the remailer is to provide anonymity via mixing messages. It does not provide confidentiality of message contents. That has to be taken care of by encryption. And, as I wrote yesterday, it doesn't (can't) keep secret who the people are who send and receive anonymous mail. All it can do is to disguise which particular people send and receive to each other. The same is true of a DC-net or a perfect Chaumian mixnet. These systems do not disguise their particpants, or protect the confidentiality of their message contents; they only hide the knowledge of who is talking to whom. Having said that, I do like some aspects of this idea:
There's a big distributed database of pgp keys on the several keyservers. Add a bit to the database specifying whether the key owner wants to receive anonymous e-mail. By default set it to true for the existing addresses.
(The "default true" is going to allow the same kinds of abuse which we have seen in the past. Some remailers may be able to tolerate this, but as we have seen, many can't.)
When the final remailer in the chain wants to send someone an anonymous message, it attempts to retrieve a key from the keyservers.
If it fails to find a key, it junks the mail (you don't want to keep it around, it's baiting the LEAs!) and instead sends a notification to the recipient that some anon e-mail was addressed to it, but it was junked; and if they want to receive anon e-mail, they need to give a pgp key to one of the key servers this remailer uses.
This is what I like. It's a lot simpler than trying to keep a copy of the anonymous mail and deliver it later when the person asks for it. Just let him know that someone is trying to reach him anonymously, and let him enable that if he wants to be able to receive the next anonymous message that comes in for him. You can load his permission message down with all kinds of disclaimers that say he knows he's likely to receive obscene, threatening and illegal material, that he doesn't mind, that he knows the remailer is an automated system which doesn't look at the contents, etc. Not only does this give you a defense but it makes the person think about what he's getting into, so he will in fact be better prepared when something bad comes his way. Plus, having taken positive action to enable receiving anonymous mail, he will hopefully be more knowledgable about how to request that you stop, and it won't be such a big deal. He opens the pipe, and if he gets a face full of sewage, he closes up the pipe right away. You warned him.
If it finds a key, it looks at the anon mail bit; if it's on, it encrypts the e-mail with the recipient's key and sends it; otherwise it junks it.
Obviously, the key servers would need to be modified to allow users to specify whether they want anon e-mail when then store their keys, and to change this setting any time.
Key servers wouldn't be the only place to store this information. I think the remailer could keep its own list, especially if it were defaulting to "off". This way recipients wouldn't have to generate and submit PGP keys, which is more work than just sending a reply to a remailer giving the OK to receive anonymous mail.
Right now, there's a very large number of addresses in the key servers. Instantly making them into a list of addresses that accept anon mail will make it hard (hopefully infeasible) for the LEAs to investigate everyone willing to accept anon e-mail as a suspect in sending it.
More cautious or politically vulnerable remailers might default in the other direction. It would be a matter of the individual situation. Hal