- cypherpunks-legacy - lists.cpunks.org

Anon address attack...
by Hal 01 Mar '93

01 Mar '93

-----BEGIN PGP SIGNED MESSAGE----- It seems like there are several problems that arise from this "automatic" anonymization of messages sent through the Penet remailer. You have these security threats which involve people being tricked into sending messages through the remailer in such a way that the recipient knows the true email address from where the messages are coming. (I think that is what happened here with "deadbeat", because otherwise why would he have asked people to send their email addresses? He wouldn't need email addresses since he could reply to people without knowing them, by just using a "reply" command in his mailer.) (It's interesting that he also sent his message via one of the Cypherpunks remailers. Maybe he thought they worked like the Penet remailer and he could break anonymity on those as well.) Another problem that people have complained about is when they respond to an anonymous posting, they get a message from Penet saying that they now have an anonymous ID assigned. This confuses and bothers some people. We had some debate about this issue here several months ago (before Penet was operating, I think). One question is, if I send mail to anonymous person A, does that mean or imply that I should be made anonymous to A? This is to some extent a matter of expectations. Some people argued that should be no expectation of anonymity in this case; A is the one who wants to be anonymous, not the people who are sending to him/her. Others replied that since some anonymous remailers already worked this way, there would be an expectation of anonymity, and so the safest assumption was to anonymize all messages since people can always override the anonymity by revealing their true addresses. I think these attacks on Penet re-open these questions. Evidentally there is positive harm that can occur by automatically anonymizing all messages which pass through a remailer. (BTW, I certainly don't mean here to be presuming to tell Julf what he should or should not do with Penet. I'm just taking that as an example. We have discussed adding similar functionality to our Cypher- punks remailers. The main problem occurs when sending a message to an anonymous Penet address. For the other uses of the Penet remailer, for anonymous posting and for mail to a non-anonymous address, it's more reasonable to assume that anonymization is desired. (Otherwise, why would they be using the service?) But when sending a message to an anonymous address, it's not known whether the sender wants to be anonymized or not. One possibility (which might not be that easy technically) would be to assign a new anonymous ID for each such message through the Penet server. This means that you would get a _different_ anonymous ID for each of these messages, preventing an attacker from pairing up your "usual" posting ID with your email address. (Perhaps this anonymous ID creation could be suppressed with another X- command, as proposed earlier, but this could be the default behavior.) It might be hard to keep track of that many anonymous ID's, but perhaps they could be kept active for only a limited period of time (several weeks or months) and retired after that. It might seem that people should just be careful about what they send through Penet, but there are some problems with this. What do you do if you get a message from an5877(a)anon.penet.fi asking for advice on cryptography mailing lists? If you reply, your questioner can figure out who the reply is coming from, and sees your Penet alias. There is no way to prevent this from happening currently. Also, I have seen proposals that anonymous ID's should be made less recognizable, so that instead of an5877(a)anon.penet.fi we would have joe(a)serv.uba.edu. In such a situation it might be tedious to scrutinize every email address we send to (via replies, for example) to make sure it isn't a remailer where you have an anonymous ID. All in all, I think some changes need to be made in how anonymous addresses are used and implemented in order to provide reasonable amounts of security. Hal Finney -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBK4lfIagTA69YIUw3AQGzQAQApOduiD7P2C26f7ml5tcOJf6xQff7bdV0 qw+zjOevW6hSBunOY59Qstkk5uQ2CoEALDAyUfKRsy7dionBAtCJYlwfX7uclHKL Sonor8bg0NPHMP8SV/antacq00fK3b5wtiFFMn3WsjCvSEjhGoB9SIE/TB/zL9Et Ow8JEodP488= =cXHd -----END PGP SIGNATURE-----

8 11

Re: dispatches from the front lines of anonymity
by wcs＠anchor.ho.att.com 01 Mar '93

01 Mar '93

X-Real-Subject: Re: not assigning IDs for alt.whistleblower X-Real-From: Richard M. Nixon X-Real-Message-Body-Begin: It's probably a reasonable policy - anybody who wants to can add a signature line or equivalent giving themselves a pseudonym, and if they want private replies they can provide a PGP or RIPEM public key. A clean way to avoid the problem of encrypted replies cluttering up the newsgroup is to also create alt.whistleblower.followup or a.w.crypt, with similar non-assignment of ids, so readers can easily skip over the crypted private replies. If some whistleblower, or some whistlelistener, is more trusting, they can even post their an12345 address. I *would* recommend the following policies - - accept email in PGP, RIPEM, and also unencrypted MIME, X.400, and vanilla formats- not everybody who wants to blow a whistle has the right-shaped whistle handy. - publish an "official" method for defining what part gets posted - e.g. Anonymous-Subject: Use me instead of the main header Subject: Begin-Anonymous-Message-Body: ..... End-Anonymous-Message-Body: as part of the *text* of the message, so that people with different mailers can be sure about what parts get kept and what don't - it would be real annoying to have the signature-stripper delete the good parts of a message because they looked like signatures, or leave on the signatures because they looked like text, but some mailers won't let your do what you want with headers. Also publish a policy for messages that _don't_ contain them. A proper approach might be to use the MIME headers, but accept them from inside the message body as well as from the headers of proper MIME messages, so people can do them by hand. This has the added advantage of supporting Content-Transfer-Encoding: headers so you can tell more easily which encryption was used, and so senders of unencrypted messages can use compression or rot13 :-) to avoid having their message sent in obvious ascii. X-Real-Signature: "Maybe I _was_ a crook" X-Real-Message-Body-End: Bill # Bill Stewart wcs(a)anchor.ho.att.com +1-908-949-0705 Fax-4876 # AT&T Bell Labs, Room 4M-312, Crawfords Corner Rd, Holmdel, NJ 07733-3030

2 1

header field indicating an anonymous address
by Eric Hughes 01 Mar '93

01 Mar '93

Marc R. suggests that we standardize on a header field to indicate that a message was anonymous. I suggest "Anon-Sender:". There's already a "Sender:" field in RFC-822, indicating who sent the message, as separate from who wrote the message. The "Anon-Sender:" field should contain an email address for the maintainer of the remailer. Why? To facilitate complaints. :-) Eric

3 2

Handling Abuses of Remailers
by tcmay＠netcom.com 01 Mar '93

01 Mar '93

I'll keep this one very short. * To handle _abusive volumes_ through remailers, charge for remailing. Short term, this may be a problem, but this is the long term market solution. * To handle _abusive messages_ through remailers, ignore them. "Sticks and stones" and all that. Put positive reputation filters in place. Accept e-mail only through those you know or have reason to trust. As Sandy Sandfort so cogently put it, punish the perps, not the words of the perps. This is the basis of our society, and a good basis, too. -Tim May -- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)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^756839 | Public Key: MailSafe and PGP available.

2 1

Infrastructure
by nobody＠alumni.cco.caltech.edu 01 Mar '93

01 Mar '93

-----BEGIN PGP SIGNED MESSAGE----- Some time back there was some debate here about whether MIME ("Multipurpose Internet Mail Extensions") features could be exploited to make encryption easier to use. I didn't pay much attention at the time, because I didn't know anything about MIME. But then a couple of weeks ago John Gilmore posted about Metamail, a software system designed to make it easy to integrate MIME into commonly-used mailers. I've played with Metamail a bit, and I do think this could be a good approach. Metamail basically performs a mail-sorting function, automatically passing mail which has the MIME "Content-type" header to a filter or display program based on a very flexible "mailcap" file. To add PGP (or PEM, or RIPEM) support would be a matter of defining a Content-type header for this application, then creating the appropriate 1-line entry in the mailcap file. This does sound like a pretty easy way to add this capability. The nice thing is, Metamail has already done the work of figuring out how to patch a whole bunch of different mailers to add this support. By using metamail we would be leveraging off this already-existing work. Here are some excerpts from the "mailers.txt" file that comes with the distribution, written by Nathaniel S. Borenstein: > Abstract > > It is surprisingly easy to use the RFC1049 "Content-type" header to turn > virtually any mail reading interface into a multi-media mail reading > interface. Mail readers are simply modified to use the new "metamail" > program whenever they receive non-text mail. The metamail program is > itself easily customizable by the use of a "mailcap" file that specifies > the media types supported by a given site or user. Given the existence > of the metamail program, this document explains how to add multimedia > support to sixteen very different mail reading programs, including all > of the most popular UNIX mail reading programs and (so far) one DOS mail > reading program. > [...] > The Basic Idea > > Basically, there are only two things you have to do to each mail reading > program: > > 1. Make the mail reader notice the special header ("Content-type") that > marks a message as a non-text message. (In the case of mail readers > that already understand certain content-types, such as Andrew, the mail > reader must be modified only to deal with the content-types it does not > already know how to handle. > > 2. When the special header appears, instead of (or, if it's much > easier, in addition to) showing the user the body of the message, the > mail reader must send that body off to the metamail interpreter. The > metamail interpreter includes features that deal with the diverse > situations of terminal-oriented and window-oriented mail readers. > [...] > A Variety of Mail and Bulletin Board Reading Interfaces > > With this document, you can patch all of your site's mail reading > interfaces to support whatever multimedia formats are deemed useful at > your site. This means that those who regularly use the multimedia tools > can begin to send mail in those formats freely, without worrying about > the ability of any local user to interpret the mail. It is my intent to > make this document exhaustive; as time goes on, I hope it will grow to > include an ever widening set of mail reading interfaces. Currently it > includes all of the mail reading interfaces that I know to be in use > anywhere in Bellcore's research laboratories. > > Currently this document describes how to add support for the following > mail readers: > > Berkeley Mail (/usr/ucb/Mail, /usr/ucb/mail, and Tahoe mail) > SunMail (another version of Berkeley mail, but rather different) > Xmail (an X11 interface to Berkeley mail) > Mailtool (older versions of a SunTools interface to Berkeley mail) > Imail (Bellcore MICE mailer) > PCS readmail/rdmail/sreadmail (another Bellcore mailer) > MH -- Rand Message Handling System > XMH -- X11 Interface to Rand Message Handling System > Rmail -- GNU Emacs mail reading package > VM -- Another GNU Emacs mail reading package > MH-E -- Yet another GNU Emacs mail reading package (GNU interface to MH) > CUI -- Andrew low-end mail reader > VUI -- Andrew termcap-based mail reader > Messages -- Andrew multimedia mail reader > BatMail -- Andrew Emacs mail-reading interface > Elm -- Mail reader from HP. > Mush -- Yet another popular mail reader > Msgs -- simple Berkeley bulletin board reader > UUPC --a mail reading program for MS-DOS > TRN -- a threaded netnews reader. > > > If you have mail readers that are not dicussed here, you will still > probably find some of this code useful as a model. If you develop a > patch for some other mail reader, and you send it back to me, I'll > include it in future versions of this document. I am very impressed with the range of mailers covered here. Unfortunately, access to source is needed for most of the patches. But my guess would be that patched versions would become available even to people who don't have source. I'm not really sure what is happening with PGP specifically in terms of MIME. I think there has been some work done with PEM integration. There doesn't seem to be any reason why these programs can't integrate nicely with MIME, and this Metamail package looks like it might be the most cost-effective way of getting widespread encryption into use. Hal -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBK5EwE6gTA69YIUw3AQHa3gP/d9rJg8FTE4glB3CbUy5skG8j0AS4qvGn ugFhor0RZYpZIrsZn+XXJaiaO6+7je8fdEuwO2SkFBS90p6D7vtR40hqPUPnc4io q4z4UYRwV3aIVMjWZqyDncYQUouUltXh9utwH7nsbZX4Md9vDWwuq9ck7DHZhT+m O7Zx1+44kRY= =4Kad -----END PGP SIGNATURE-----

2 1

RISKS for alt.whistleblowers
by wcs＠anchor.ho.att.com 01 Mar '93

01 Mar '93

I would expect two kinds of people to cause trouble for alt.whistleblowers: amateurs and professionals. Amateur troublemakers may cause the most volume of trouble, and the largest signal-to-noise problem, but the more serious concern is what happens if there's enough signal in the noise to be a threat to professionals, whether governments, corporations, or criminals. If I were a professional who wanted to stop a group like this, and options like court orders, violence, or confiscation weren't appropriate, I'd consider a few approaches like the following: - Flooding - it's really not hard, even with automatic protections - if you can emulate, or abuse, all the neighboring anon-remailers, you may even force disconnects from them. - Crying wolf, and other disinformation - if there are enough bogus posts, people will stop reading the newsgroup, and the talk.bizzare crowd wil take over because they're the only ones who can handle the noise .. - Posting libel, slander, child pornography, calls for violence, bomb threats followed by real bombings, blackmail requests, photographs of local politicians in real or fake compromising situations, and enough other legally dangerous material that the moderator and/or people who carry the newsgroup wouldn't be able to take the heat. It's really not all that hard, if somebody's serious about it. Crypto-anarchy is a good thing, but governments and other bad guys can hide behind it just as effectively as anarchists can. .... and the last count I've heard on the radio was that 19 separate groups have called in to claim responsibility for the World Trade Center bombing; some even called 911, though presumably they used pay phones ... Bill Stewart, somewhere out in Cyberspace

2 1

Pgp with MH & MIME
by Peter & 01 Mar '93

01 Mar '93

--------Enter additional text -----BEGIN PGP SIGNED MESSAGE----- > Some time back there was some debate here about whether MIME > ("Multipurpose Internet Mail Extensions") features could be exploited > to make encryption easier to use. I didn't pay much attention at the > time, because I didn't know anything about MIME. Here is my latest copy of "pgpedit", I have modified it to insert a "Content-Type" line to that MIME mailer will automaticly #!/usr/local/bin/perl #!/usr/local/bin/tperl4.036 # pgpedit V1.5 # Mon Mar 1 00:40:49 PST 1993 # Peter Shipley # to install (mh instructions) # place this script in your path (eg ~/bin) # create few links: # # ln -s /usr/local/mh/bin/repl ~/bin/pgprepl # ln -s /usr/local/mh/bin/comp ~/bin/pgpcomp # ln -s /usr/local/mh/bin/forw ~/bin/pgpforw # # Add the following to your .mh_profile: # # pgprepl: -editor pgpedit # pgpcomp: -editor pgpedit # pgpforw: -editor pgpedit # # To use just use the commands pgprepl or pgpcomp instead of repl or comp # # If you are Useing MH 6.8 with MIME you may also want to add the following: # # mhn-show-text/x-pgp: %ppgp -m '%F' # mhn-store-text/x-pgp: %m%P.pgp # # This `instruct' MH how to interpet the MIME header "Content-Type: text/x-pgp" # and have MH automaticly invoke pgp for devcryption or signature verification # require "sys/wait.ph"; #custom stuff here #default editor $defaulteditor="/usr/ucb/vi"; $pgpcommand="/usr/local/bin/pgp -sta +clearsig=on"; $debug=0; #test the arg count die "bad argument count" if ($#ARGV > 0); #set the umask to something really paranoid umask(07177); #set the path if there is not one $ENV{'PATH'} = '/bin:/usr/ucb:/usr/bin' unless $ENV{'PATH'}; # get the editor if ($ENV{'VISUAL'}) { $editor=$ENV{'VISUAL'} ; } elsif ($ENV{'EDITOR'}) { $editor=$ENV{'EDITOR'} ; } else { $editor = $defaulteditor; } $editor = $defaulteditor if $editor =~ /pgpedit/ ; # prepare the file. &prepfile($ARGV[0]); # run the editor &run($editor, $ARGV[0]); # have pgp sign the file &SignMailFile($ARGV[0]); # the end exit 0; sub SignMailFile { local($INPUT) = @_; local($BODY) = "/tmp/pgp$$.body"; local($PGPBODY) = "$BODY".".asc"; local(@header); print "$INPUT \n" if ($debug); open(INPUT, "+>>$INPUT" ) || die "failed to open $INPUT: $!\n"; seek(INPUT,0, 0); open(BODY, "+>$BODY") || die "failed to open $BODY: $!\n"; select(BODY); $| = 1; select(STDOUT); while (<INPUT>) { last if (/^--------/); push (@header, $_); } if ($debug) { print STDERR "\n--header--\n"; print STDERR "@header \n" ; print STDERR "\n--BODY--\n"; print STDERR "$BODY \n" ; } while (<INPUT>) { print BODY $_; } print STDERR "$pgpcommand $BODY\n" if ($debug); `$pgpcommand $BODY`; # &run($pgpcommand, $BODY); if (! $? ) { truncate(BODY, 0); unlink($BODY); close(BODY); truncate(INPUT,0); open(PGPBODY) || die "failed to open $PGPBODY: $!\n"; seek(INPUT, 0, 0); print INPUT @header; print INPUT "Content-Type: text/x-pgp; charset=\"us-ascii\"\n"; print INPUT "--------\n\n"; print INPUT <PGPBODY>; } else { truncate(BODY, 0); unlink($BODY); close(BODY); if ( -f $PGPBODY ) { truncate(PGPBODY, 0); unlink($PGPBODY); close(PGPBODY); } } return; } sub prepfile { local($FILE) = @_; local(@data); open(FILE, "+>>$FILE" ) || die "failed to open $FILE: $!\n"; seek(FILE, 0, 0); while(<FILE>) { next if ( ?text/x-pgp? ); push (@data, $_); last if ( /^--------/ ); } # push (@data, "\n\n\n"); while(<FILE>) { last if (/^-----BEGIN PGP SIGNED MESSAGE-----/); } if( !eof(FILE) ) { while(<FILE>) { last if (/^-----BEGIN PGP SIGNATURE-----/); push (@data , $_); } seek(FILE, 0, 0); truncate(FILE, 0); print FILE @data; } close(FILE); return; } sub run { local($editor, $file) = @_; local($pid); FORK: { if ($pid = fork) { wait; } elsif (defined $pid) { # $pid is zero here if defined exec "$editor $file"; } elsif ($! =~ /No more process/) { # EAGAIN, supposedly recoverable fork error sleep 5; redo FORK; } else { # weird fork error die "Can't fork: $!\n"; } } return; } -----BEGIN PGP SIGNATURE----- Version: 2.1 iQBFAgUBK5HPZchmn7GUWLLFAQHGfgF9HFh4CwpEGi0UxYtswMA6VCxDSA/UaKzZ An7db1dLCOzZ3FEf7YjAi8Fi80482b+/ =j2S2 -----END PGP SIGNATURE-----

1 0

Re: a few opinions, unasked
by dclunie＠pax.tpa.com.au 01 Mar '93

01 Mar '93

> Who is John Galt? The man who said he would stop the motor of the world - and did. :) Where is John when you need him ?

1 0

more ideas on anonymity
by L. Detweiler 01 Mar '93

01 Mar '93

The question as to what specifically to prohibit being posted anonymously has come up, and is by far one of our most serious and sensitive considerations. Of course, the decision is largely in the hands of the anonymous server operator, but no generally accepted guidelines currently exist, and we might help some people and advance the cause by codifying `legitimate use'. First, let me assure you my intent and preference is that it should be as liberal as possible. Let's look at some of the options (I'm tiptoeing on eggshells here, please don't flame me too much): 1) operator makes decision for every posting brought to his attention. Things that would test this system: what about revisionists (not ugly-enough term) who claim that the Holocaust never happened? Or someone who is posting extremely provocative but fabricated data? (The first case happened on Prodigy--the censors let it through at one point, and was documented in a column by Alan Dershowitz, famous American lawyer defending e.g. Mike Tyson, and other major celebrities. The second case happened with the now infamous challenger transcript posting, where anonymous user of penet posts without any comment a `transcript' of shuttle crew dialog during the crash.) Here, I think one policy might be that if the poster seems to be repeatedly and blatantly fabricating the data himself, maybe some restriction or warning is in order. But if ever the poster includes `real source' (no matter how trashy) from the outside world, and makes it clear that they are not the originator, only the purveyor (`messenger'), perhaps this is less serious. (I think Mr. Helsingius' current standards in this area should be held up as an outstanding model of commitment to privacy and free speech.) 2) some kind of global system for keeping track of `abusive' posters. Here are some interesting ideas--how about lists circulated among anonymous server operators only (not public) that record barred users by their email address or even real identity? The lists could be categorized and tagged so that the administrator can prohibit use based on the seriousness of the offense. Here are some things that operators `might' look at: 1) ad hominem attacks 2) flame baiting 3) lying outright 4) defying Usenet conventions: posting copyrighted material, binaries to regular groups, massive amounts of data, etc. 5) number or existence of *any* complaints 6) `racist' remarks 7) terrorism 8) `harassment' 9) anything illegal in the poster's country (yes, tricky I know) ad infinitum ad nauseam. Maybe we could try to organize the severity of this kind of stuff, and classify servers as `type 1' or `type 2' and we can get a feel for how liberal or conservative the operator is. The operator would say which lists he subscribes to, and which lists your email address will go on if you abuse the site. Really extreme operators (like Mr. Kleinpaste) might actually be interested in `public' lists -- abusers get their email addresses, along with the offense, posted on the public list, i.e. `outed'. Now, I think a lot of this is pretty unpalatable, but we have things to gain by formalizing these mechanisms, and as long as the anonymous user is *warned* in the server intro-use message, and possibly even has ways of redress, and has choice of different servers, then the system could be fairly agreeable by most. Remember, no one is preventing operators from being conservative or liberal as they like, the only thing wanted is adherence to their stated policies. Look what we have to gain. Currently, there is a lot of censorship (attempts? conquests?) going on behind the scenes, as a recent episode here attests. No one really knows how effective in general it is currently to hunt down and bar `abusive' users (hence a lot of misinformation and paranoia about the effects of anonymous servers). If we could have some *statistics* that show x% of nonanonymous users get complaints and y% of anonymous ones do, this would be very useful for gauging the social impact of our technologies. (There could be some very surprising results---I get the impression that many very responsible people *prefer* anonymity, and conceivably the overall complaints on anonymity could even be *less*). 3) Possibility of net.trials Ok, so don't flame me too much on this one. But if `abusers' (this could be for anonymity on a local server, but eventually involve to other realms) were subject to a `trial by peers', imagine what this could do to enhance the legitimate reputation of networks. Suddenly, a judicial system. I certainly don't want to be known as an advocate of bringing in lawyers and bureaucrats. Actually, that's precisely why I'm proposing this, to prevent that scenario. Imagine that the net establishes these formal self-regulating mechanisms. People in the real-world law enforcement would be much less likely to become enraged by perceived abuses when they realize that there are intrinsic mechanisms for quelling the psychopaths (uhm, maybe, anyway). Also, if people weren't added to blacklists just by the caprice of one operator but after a perceived fair `trial', people at other sites would be much more willing to enforce the sentences of suspension, expulsion or whatever. An electronic trial by peers? (with voting at the end?) A very interesting idea. Each server may develop a kind of peer or family structure, keeping kin in line. Maybe everyone that replies to an anonymous message could vote in their header whether to get rid of the user, with the default `one vote of approval' (limit voting regularity). Approves add, complaints subtract. The user starts with some initial balance. If he gets down to zero, *poof*. Lots of `approval'? No problemo. Post something really outrageous? You might get enough zaps to lose it all. Imagine, this could improve the accountability of users in *general* (the mechanisms could be applied to new Usenet groups, for example, or if very trustworthy and fair even logins themselves). I've been a bit vague and ambiguous in some of these statements. This is because, as I hope has become clear, the kind of things that start out on anonymous servers could eventually have a much greater scope, so that it `behooves' us to develop effective and dynamic mechanisms for self-regulation. Keep in mind a lot of these things are happening already albeit in much less formal ways. For example, the convention is to send complaints to the system adminstrator at a site regarding their users, and they act as judge and jury (or use whatever other local procedures are in place). The user may or may not be able to justify their actions (redress). There is already a loose confederation of cooperation between administrators, esp. over extremely abusive posters. We already get somewhat public `trials' of extremists, where people put forward all the evidence on Usenet and argue both sides. `Enforcement' and `punishment' sometimes consists of revoking logins, feeds, or whatever. I think we ultimately stand to gain by `formalizing' a lot of the currently informal mechanisms in place. My feeling is that if we don't head off these issues at the pass, so to speak, Real World (tm) courts will start deciding them for us. Let's develop something we can be proud of and will be a model of excellence for the future, and not something frail and unstable. Perhaps our anonymous motto: ``I disagree with what you say but will defend to my death your right to say it.'' --Voltaire (written pseudonymously)

4 4

Re: more annoying philosophizing on anonymity
by hkhenson＠cup.portal.com 01 Mar '93

01 Mar '93

Re this thread, and picking up a current theme, what do you think would happen if a message claiming to be responsible for the WTC blast came through an anon remailer? Keith Henson

1 0