Adam Back <aba@dcs.ex.ac.uk> writes:
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.
Here's a partial solution to that: in the ping email informing the recipient there is mail waiting, you include a key, encrypt the message body that you are retaining data with the key and then discard the key. Give a deadline: "your message will be deleted in 5 days". They re-supply the key when they request the message. You immediately decrypt and send it back to them, discarding all knowledge of them (email, encrypted message, encryption key).
That's a good idea, but it'll take up a lot of disk space at the machine running the remailer. Right now, remailers that provide latency don't keep an e-mail for more than about 12 hours. Once you start keeping them around for a few days (a reasonable grace period for a first-time user), it's a lot more disk space.
One snag is that you still have addresses for recipients on your machine so they can go harass people and ask them for the keys to the as yet uncollected messages.
Refinement to solution (I like this one), get rid of the intended recipients address immediately after sending the ping, just keep the encrypted body of the message. Include in the ping something which reliably selects a message (say first encrypted line, SHA1 hash of encrypted message, whatever, to save you having to try to decrypt all of your messages).
That's a good refinement, but it's still not enough, IMO. Suppose a LEA wants to search the computer hosting the remailer. They come across a bunch of encrypted files. The operator has to convince the LEA that they don't have the means to decrypt the e-mails or even to figure out who they're from. That just may be close to contempt of court. Say, you might be asked to explain how you generate the "random" keys so they can be recreated. IMO, the 'net has changed from what it used to be a few years ago. One can no longer send e-mail to an unknown recipient and hope that they're willing to accept anonymous e-mail. I'm not 100% sure what needs to be done, but I firmly believe that in today's climate unless the remailer knows that the recipient took some positive action to indicate that s/he has a clue (such as, added a key to a keyserver), their anon mail should be immediately discarded and they should instead get a note: Someone tried to send you anonymous e-mail; because we don't know whether you want to receive anon e-mail, it's been discarded and can't be recovered; anon e-mail can be bad; disclaimer dislciamer disclaimer; and here's what you need to do to receive future e-mail if you want it.
[keyserver with I-accept-anon-email bit consulted by remailer, no key in remailer => instant trash of message and ping message explaining how to accept anon email]
This sounds a lot like the distributed block and accept list idea which has been discussed a bit.
Yes - nothing really new.
I like your treatment of the remailed material as a `hot potato', instantly pass it on or burn it.
Yes - 5 days worth of anon mail, even if it's encrypted and the recipient is stripped, is an attractive target for LEA's looking for child porn and the like.
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.
The per remailer block list system kind of does this at the moment, only the list of people initially marked down as willing to accept anon email is the world.
Everyone can recieve email, but people get blocked when they complain.
Unfortunately this model is based on assumptions that are no longer true. I've been on the 'net since the early 80s. I used to prozelityze(sp?) everyone I knew that the 'net is a great tool and that we all should use it. Well, now the 'net is full of assholes and you can no longer assume that just because someone has access to the 'net, they have a clue. However I think it's a safe assumption that someone who put their key in a key server has enough of a clue to be able to handle an anon e-mail; and if they don't, they should be able to turn it off easily.
Incidentally, it has occurred to me for a while now that the reverse problem also exists: if I suspect you (Dimitri) use remailers, I can forge a message from you to all the remailer operators requesting that I (ie you) be blocked. I can include some exceedingly dire legal threats to the remailer operator, and dig up some vile messages from some dark corner of usenet which I falsely claim came through that operators remailer. As the remailer operator doesn't keep logs he won't be able to recognize the falsehood of the accusation.
To solve this problem you need to do a ping message, "please reply with this nonce to be blocked".
Yes, that's a possibility. E-mail from has has been forged in the past, as Igor can attest. :-) Again, the 'net has changed. As some folks are aware, I run 3 mailing lists at another site. 2 are near-dead, but one has been up since '89 and is pretty active. Recently I had to institute the policy of confirming subscriptions because of the several forged subscription requests. Such things were unthinkable even 4 or 5 years ago. A key server presumably has some mechanisms for checking that someone who wants to store or update a key for a@b appears to be a@b. --- Dr.Dimitri Vulis KOTM Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps