Nice as remailers are, I wonder if it might be better to simply create a "message drop". Various anon ID's would be created, with suitable passwords. If Sam wishes to mail to Joe, he sends to the account. It sits for up to a week before auto-deletion; prior to that time Joe can check his account for messages, retrieve as appropriate, leave other messages, and leave. The primary 'phone number would be in one location, with the remailer at a different physical location connected via non-toll call forwarding. Hence, no LD toll records of the calls to the device. Individuals would place calls, so their records might "give them away"; but there would be no return calls from the device. Finally, if someone wanted to use methods other than PGP this would seem to support such methods. Any thoughts, or am I hopelessly clueless? Regards, Dave
David Womack writes:
Nice as remailers are, I wonder if it might be better to simply create a "message drop". Various anon ID's would be created, with suitable passwords.
If Sam wishes to mail to Joe, he sends to the account. It sits for up to a week before auto-deletion; prior to that time Joe can check his account for messages, retrieve as appropriate, leave other messages, and leave.
The "message drop" is essentially what a "pool" is, and such pools have been run before, and may still be running. (That few use them is an ongoing issue.) Mailing a message anonymously to a bulletin board, a newsgroup, or some other publically accessible area is the idea. A newsgroup (Eric Hughes and I proposed the facetious newsgroup "alt.w.a.s.t.e" for such messages, after Pynchon's mail service in "The Crying of Lot 49") has the advantage of worldwide distribution and essentially no ability to trace who reads the group. I used the groups "alt.extropians" and "alt.fan.david-sternlight" for the anonymous posting pools to be used with my example of "BlackNet." Of course, world-readable newsgroups will not continue to work forever, as volume of messages increases. (On the other hand, net bandwidth may increase faster than pool use, so....) Hope this helps. --Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power:2**859433 | Public Key: PGP and MailSafe available.
The "message drop" is essentially what a "pool" is,
The message drop described was held at a single place, not transmitted widely or even available widely, as a message pool is. I've come to believe that message drops or, more generally, rendevouz points are a big pragmatic win. Here's why. I have a friend out here whose BBS was seized in a civil action by Sega. Sega's lawyers made a pleading to the court based on logs they had taken from the BBS. The court granted Sega the ability to search and seize the computer. But all Sega had was the phone number. So Sega first had a _subpoena duces tecum_ served on Pacific Bell. This form of subpoena is not an order to appear but rather an order to produce documents or items relevant to a judicial proceeding. Sega gave Pac Bell the phone number, Pac Bell gave them a name and address. This was the same name and address that the US Marshall's service used when seizing the BBS equipment. Suppose that phone number was an email address or an IP address. If the provider of message or packet delivery actually knows the final destination, a subpoena to produce records will disclose that destination. On the other hand, if the 'public face' of the address is only mapped to some authentication means (such as a password or a public key), then such a subpoena will only reveal that authentication info, not an identity or a location. Willful ignorance can be a beautiful thing. Furthermore, if the system is constructed such that the only way to get at the information in RAM about current connections is to take down the system, well, then there's no way to get at that information, is there? Eric
participants (3)
-
dwomack＠runner.utsa.edu -
hughes＠ah.com -
tcmay＠netcom.com