December 2003 - cypherpunks-legacy

Re: Why sign pubkey?
by norm＠netcom.com 17 Dec '03

17 Dec '03

Thanks for the post. There is someone with a quite legitimate reason to sign a newly generated public key with "Norman Hardy" in the user id string but without my my e-mail address. He is one of the several other Norman Hardy's in the U.S. I could include a very short biography which would fix that ambiguity. I only send secrets to people that I have some reason to trust. I gain trust sometimes from having met someone in person and talked for a few hours. If I get a business card with a key finger print and e-mail address (or URL) then I am safe from such spoofing as described in your post. Her name plays no role in the transaction. If I trust her because you recommended her to me, then perhaps I can get a fingerprint and URL from you. Again I need no name. In both of these cases the URL is merely a convenience. If she moves her web page, a search engine will soon find it given a part of the finger print included in the web page. Unless the attacker has compromised the search engine, I need merely send mail enciphered by her public key to the e-mail address given in each web page claiming to own the public key. Only she will be able to read the mail. Recommendation: Put URL & finger print on business cards. Include URL and finger print in recommendations. To send a secure message to some whose URL & trusted print you have: Check the URL for a public key whose print matches the trusted print. If that fails use a search engine for a better URLs. Send mail to each e-mail address found on a web page passing the test. Recommendations should include a little text about what things the designee should trusted with. Programs like PGP that follow trust chains should display the text from each recommendation in the chain.

1 0

Re: the cost of untracability?
by Frank O. Trotter, III 17 Dec '03

17 Dec '03

> FWIW, I think that there is no capital-gains-type tax on currency > conversions. In other words, if I take dollars and buy yen today, and the > interconvert rate changes and I convert back and make a "profit," that is > not considered income. If that's the case, then ecash has an excellent > precedent behind it to avoid any taxes on interest, especially if that > interest is, in effect, paid by increasing the inherent value of the currency. > > And most of the "interest" will simply be the avoided inflation loss that > would have otherwise occurred. Buying ecash may be equivalent to buying an > absolutely non-inflating currency that the government can't manipulate. > > Jim Bell > jimbell(a)pacifier.com > There is a tax event that occurs when one converts from one currency to another (be it capital or current). In your example the purchase of Yen and later sale may result in a gain if the Yen appreciates, or a loss if it drops. This is a taxable event. You actually refer to the method that was used in the 14th - 16th century in europo to pay interest when it was against church (really "Church") law. Early banks would do currency or metals-to-currency trades with people and imply a rent or interest rate. It was also the begining of the discount trade bill (I'll give you 90 cents today and get your dollar in a year from the person you sold those chairs to). I'll still cling to my Ecash is curency not a currency agument as well BTW. Frank O. Trotter, III - fotiii(a)crl.com www.marktwain.com - Fax: +1 314 569-4906 --------------------------------------------

2 1

Re: Someone's screwing around with anon.penet.fi
by Robert A. Rosenberg 17 Dec '03

17 Dec '03

At 15:55 4/6/96, stewarts(a)ix.netcom.com wrote: >The way to prevent this whole mess is to educate majordomo to turn >subscription requests from anXXXXXX(a)anon.penet.fi into naXXXXXX(a)anon.penet.fi, >or at least to block subscription requests form anXXXXXX(a)anon.penet.fi. As I've noted, such a patch already exists - it just must be installed by the Maintainer of the Majordomo copy at the Provider.

1 0

Re: .sig followup
by jf_avon＠citenet.net 17 Dec '03

17 Dec '03

>The media coverage of the sensationalist (violent and/or sexual) crime >has given the law makers and enforcers an excuse to step things up. It's >not quite as bad up here in Canada, but where the US goes, Canada >(and probably the rest of the world) usually follows. Hey, we got the new gun control bill up here. Mandatory registration of all firearms by year xxxx (I forgot). Other things are coming. Yesterday, a minister of Quebec province declared that the ownership of a house is a *privilege*, and therefore, can be seized for non payment or evasion of income tax. Next thing we'll know, they'll put a luxury tax on the breathing of air... >This is my first post to the Cypherpunks... So what government black >lists does this get me on? Is there anybody that have an informed answer to that question? JFA PGP 2048 bits key at: http://w3.citenet.net/users/jf_avon ID:C58ADD0D 52 96 45 E8 20 5A 8A 5E F8 7C C8 6F AE FE F8 91 Unsollicited commercial e-mail will be proofread at US165 $/h Any sender of such material will be considered as to have ac- cepted the above mentionned terms.

1 0

Enforcing the CDA improperly may pervert Internet architecture
by Declan B. McCullagh 17 Dec '03

17 Dec '03

The attached paper by Dr. Reed is worth reading -- I haven't seen this argument raised before. One portion that I found fascinating was: "It is quite silly to imagine that the Ascend router at the ISP can figure out if it is me or my child generating each packet." But that's exactly what the defenders of the CDA are claiming! Here's some background that might be interesting: When I was arguing with Bruce Taylor (an architect of the CDA) last week, we went 'round and 'round on the issue of children on the Net, as usual. He maintained that every Internet user has to have an account somewhere, so that account provider is able to tag accounts as minor or adult. To the best of my ability, I pointed out some of the technical problems with this, and he responded (I paraphrase from memory here) that technical problems can be solved by technical people: "Your side comes across to the court as saying that it can be done but we won't do it. You're a bunch of geeks who want to protect their porn and the court isn't going to buy it." He brought up IP Version 6, which the DoJ has focused on in cross-examination of one of our witnesses, Scott Bradner from the IETF: 13 Q Would it be fair to say, to summarize what you've just 14 said, that the IP Next Generation group is working on a new 15 generation of the IP Protocol itself? 16 A That is correct. 17 Q Does it have -- does the IP Next Generation group have 18 recommendations regarding a specific architecture of the 19 packet traffic on the Internet, including the format of the 20 packet? The DoJ and Taylor are going to argue that IP V6 can include such an adult/minor tag in each datagram! One of their key witnesses is Dan Olsen, the head of the computer science department at Brigham Young University and the incoming director of the Human Computer Interaction Institute at CMU. Olsen's background is NOT in distributed computing environments and protocol design -- but that minor detail notwithstanding, it looks like he'll be testifying this Friday that such a tagging scheme is technically possible. Chris Hansen from the ACLU told me last Friday: "Olsen is going to push this tagging idea that the government has, that you can imbed in your tag -- in your address -- an adult or minor tag. They're going to suggest that the market will come into existence that will make that tagging relevant." Comments? -Declan --------------------------------------------------------------------------- Enforcing the CDA Improperly May Pervert Internet Architecture by David P. Reed Friends - I'd like to call your attention to a situation where misguided politics (of the "ends-justify-means" sort) threatens one of the fundamental principles of Internet architecture, in a way that seems like a slippery slope. I do not normally take public stands of a political nature, and I do not participate much in Internet architecture anymore, but I'd like to call your attention to a very severe perversion of the Internet architectural philosophy that is being carried out in the name of political and commercial expediency. No matter what you believe about the issues raised by the Communications Decency Act, I expect that you will agree that the mechanism to carry out such a discussion or implement a resolution is in the agreements and protocols between end users of the network, not in the groups that design and deploy the internal routers and protocols that they implement. I hope you will join in and make suggestions as to the appropriate process to use to discourage the use of inappropriate architectural changes to the fundamental routing architecture of the net to achieve political policy goals. As you know, I am one of the authors, along with Saltzer and Clark, of the paper "End-to-end arguments in decentralized computer systems", which first characterized in writing the primary approach to the Internet's architecture since it was conceived, which approach arguably has been one of the reasons for its exponential growth. This philosophy - avoid building special functionality into the net internals solely to enforce an end-to-end policy - has led to the simplicity, low cost, and radical scalability of the Internet. One of the consequences is that IP routers do not enforce policies on a packet-by-packet basis, so routers can be extremely simple beasts, compared to the complex beasts that characterize even the simplest telephone central office switch. End-to-end policies are implemented by intelligence at the ends (today, the PCs and servers that communicate over the many consolidated networks that make up the Internet). I just read in Inter@ctive Week (March 25, 1996) that Livingston plans to announce an "Exon box" - a router that is designed to enable ISPs to restrict access to "indecent sites" or unrated sites unless an "adult" enters an authorization code when opening a session to enable the router to transmit packets to the site. The scam seems to be that Livingston has colluded with Senator Exon's staff to propose a "solution" to enable ISP's to implement parental controls. Exon's staff is using the announced solution as an example to demonstrate how simply ISPs can enforce local community standards and parental controls, thus supporting interpretations of the CDA requiring all access providers to include such capability in their boxes. Exon's staff is quoted as encouraging ISP's to install such functionality into the routers that serve as access points for nets. Since I use an Ascend P50 ISDN router to make frequent, short, bandwidth-on-demand ISDN connections from my "Family LAN" to an Ascend multi-line ISDN router at my commercial Internet Service Provider, I am worried that this model is completely unworkable for me, and for others that will eventually use such a practical system. My family has minor children and adults who all happily access the Internet. My ISP has no clue whatsoever whether a child or adult has initiated the call, and in fact, if my child and I are both on different computers in different rooms, it is quite silly to imagine that the Ascend router at the ISP can figure out if it is me or my child generating each packet. It is appalling to me that Livingston, which has some responsibility as a router provider to assist in the orderly growth of the net, is pandering to Exon's complete misunderstanding of how the Internet is built. I would hope that Ascend, with its much larger share of the ISP market, and other router companies such as Cisco and Bay Networks, would take a principled and likely popular position that the "Exon box" is not the way to go about this. I would hope that ISP's would in general avoid use of Livingston's products, and also refuse to cave into Exon's pressure. I believe, though I may be wrong, that Livingston has contributed to the RADIUS technology that many ISP's use to manage dialup access charging in a way that is consistent with ethe end-to-end philosophy, but any credit they are due is overwhelmed by the Exon box insanity. I do work to protect my children from inappropriate material, but pressure from Senators to mandate technically flawed solutions, and opportunistic, poorly thought-through technologies from companies like Livingston are not helpful. If you agree, please join me in attempting to call off any tendency for other router vendors and protocol designers to develop Exon box features. It would seem that the appropriate place for content restrictions, such as "parental controls", are in the end-to-end agreements between content providers and their users, not in the internal switching architecture of the net. - David P. Reed Notes: The end-to-end paper was edited and republished in several forms (with slight variations in title), generalizing its observations to systems beyond the distributed systems that were its original focus; the final and most accessible one is: Saltzer, J.H., D.P. Reed, and D.D. Clark, End-To-End Arguments in System Design. ACM Transactions on Computer Systems, 1984. 2(4) p. 277-288. I don't have any more details on Livingston's technology or its marketing plans than what was presented in Inter@ctive Week. The Inter@ctive Week article apparently based its information on 'sources' describing a planned announcement, and also quoted Exon's staff. It is possible that Livingston will choose not to announce or position its technology in this form. It seems less likely that Exon's staff will change its position on forcing ISP's to adopt some kind of technological solution, however. - David [After considering Dr. Reed's comments, I asked him whether he objects to firewalls in general. His reply: No, I think firewalls of the sort now deployed can be OK (e.g., packet filters), as a minimal line of defense. However, they are inherently flawed, in ways that are well understood (reading Cheswick and Bellovin gives good insight here). Most security threats ultimately require end-to-end policies and must be implemented with end-to-end solutions. As the paper points out, sometimes one can optimize cost of implementing and end-to-end solution by including some functionality that is not end-to-end. Firewalls may reduce the cost. --CEL]

4 5

(Fwd) British Study Claims That Photo Credit Cards Don't Work
by Deranged Mutant 17 Dec '03

17 Dec '03

This comes from the FTC Privacy List, and is somewhat relevant.... (The the "Crypto" in the title isn't, oddly...). Some thoughts... (er, questions): 1. What are the implications for log-on systems that rely on recognition of faces (supposedly impossible for hackers to describe and exploit)? 2. Legal implications for witnesses? ------- Forwarded Message Follows ------- Date: Sun, 7 Apr 1996 08:24:18 -0700 From: taxhaven(a)ix.netcom.com (Adam Starchild ) Subject: British Study Claims That Photo Credit Cards Don't Work To: privacy(a)ftc.gov "Crypto-ID" Cards Not Effective Recent studies into the effectiveness of photo credit cards have cast doubt over their ability to cut fraud. Dr. Richard Kemp, of the Department of Psychology at Westminster University, London, organized an experiment involving a London supermarket to test the cards in "the real world." The supermarket was staffed by six people who were all warned to be on the look out for fraudulent credit cards. Dr. Kemp arranged for 44 of his students to pose as shoppers and test the staffs' ability to spot photo-card misuse. Each student was armed with four cards. One showed the student as they were, one showed the student wearing make-up, one showed an individual who vaguely resembled the student and the last card depicted someone who looked nothing like the bearer. People usually recognize photographs of individuals based on a familiarity of the subject. A photograph captures only one angle and expression out of thousands of different combinations. People will recognize photographs of family, friends and well known individuals easily. But how easy is it to accurately compare a photograph with the face of a perfect stranger? At a recent conference, Dr. Kemp said that matching a photo to a stranger's face was "too difficult." He also said that in a non- experimental situation, such as a supermarket, the incidence of fraud detection would be even lower. The results of Dr. Kemp's supermarket experiment proved very interesting. In all, the majority of fraudulent cards were accepted. Amazingly, 35 per cent of the cards bearing a photograph of someone completely different from the student were accepted. A massive 64 per cent of cards bearing a similar individual were also accepted. Another factor which seems to further prove Dr. Kemp's point is that 14 per cent of cards bearing a true likeness of the student were rejected. A few British banks are already offering customers the opportunity to have their photograph etched onto their cards. They claim a reduction in fraud has resulted from this. Dr. Kemp's findings would seem to contradict this belief. Dr. Nicky Towell, one of Dr. Kemp's researchers, said "There is a widely held assumption that photo credit cards are a cheap and effective way of stopping fraud. But this is not the case." No one can tell how well photo credit cards will catch on. But with the majority of people carrying at least one, if not more cards of some sort, how long will it be before photos become compulsory? The government knows that the introduction of ID cards is a political hot potato, but how many people would notice if they turned the cards we already have into crypto-ID cards? Reprinted from The Mouse Monitor, The International Journal of Bureau-Rat Control, a periodical published by Scope International for its customers. Scope International is on the Worldwide Web at http://www.britnet.co.uk/Scope/ Posted by Adam Starchild The Offshore Entrepreneur at http://www.au.com/offshore The privacy list is run automatically by the Majordomo list manager. Send a "help" command to majordomo(a)ftc.gov for assistance. Rob. --- Send a blank message with the subject "send pgp-key" to <WlkngOwl(a)unix.asb.com> for a copy of my PGP key.

2 1

Re: Someone's screwing around with anon.penet.fi
by Robert A. Rosenberg 17 Dec '03

17 Dec '03

At 18:37 4/6/96, Chris Walter wrote: >In article ><cypherpunks.Pine.BSF.3.91.960406114609.5026B-100000(a)kirk.edmweb.com> >Steve Reid <steve(a)edmweb.com> writes: > >> Here's another one of them unsolicited messages from anon.penet.fi. > >I also got one of these right after I posted to cypherpunks. I >normally just lurk, and the address that was used is the machine I >read and post news on(we have a gateway to the mailing list). So I am >pretty sure it is related to my posting to cypherpunks. > >I have written to the administrators at anon.penet.fi asking about this >and informing them. I'll pass on any relevant info they send me. While taking to anon.penet.fi will help, the one to talk to is the list owner and ask them to clean up their act. They should either reject any attempt to use ANxxx(a)anon.penet.fi IDs in lieu of the correct NAxxx(a)anon.penet.fi form, automatically convert the registration to NAxxx(a)anon.penet.fi, or parse the membership list for ANxxx(a)anon.penet.fi IDs and fix them to the NAxxx form. If the list is run by Majordomo, there is a patch that fixes the problem by correcting the address list [or it may be outgoing address] (and I think keeping it clean at subscribe time).

1 0

Re: the cost of untracability? Re: the cost of untracability?
by mixmaster＠remail.obscura.com 17 Dec '03

17 Dec '03

[Please excuse the minor taxpunks diversion; there's a relevant point here, aside from the fact that we're approaching April 15 and discussing technologies that will let some people not care if they're approaching April 15 in a few years :-] At 09:28 AM 4/7/96 -0800, Jim Bell wrote: >FWIW, I think that there is no capital-gains-type tax on currency >conversions. In other words, if I take dollars and buy yen today, >and the interconvert rate changes and I convert back and make a >"profit," that is not considered income. What it's worth is fairly minimal, i.e. the IRS doesn't see it that way. If you did transaction Y and then transaction X and now have $100 more than you did before you started, they think that's capital gain, whether you were buying and selling Yen, soybeans, or mutual funds. The only difference if you're buying and selling ecash from Bank Foo is that it may be easier to not tell them about the transaction if it were all encrypted and outside your home jurisdiction. What they don't know won't hurt them... On the other hand, depending on what country your bank is in, there may be taxes or fees or bribes charged by the bank's home country, which would get passed along to you either directly or indirectly. > And most of the "interest" will simply be the avoided inflation loss > that would have otherwise occurred. Buying ecash may be equivalent > to buying an absolutely non-inflating currency that the government > can't manipulate. No, it's equivalent to buying private-bank currency, which may be denominated in dollars or ECUs or gold or yen or pesos or zorkmids, which may be inflatable by some government, or may be backed only by the full faith and credit of the anonymous remailer in Panama that you reach your ostensibly Cayman-Islands e-bank through. Now for the slight cypherpunks relevance - assuming that you're banking in some currency other than your home country's government's, whether it's hard currency like Swiss Francs or soft metal like gold or a mixture like ECUs or shares of Fidelity Mercury Fund, if you to pay taxes on the net result of transactions, you'll probably want a timestamped log of what you did when, and ideally a good data set of the highest, lowest, and instantaneous prices of the backing currency on several markets, so you can report your profits and losses pessimistically. (For most kinds of accounts, you'd want those sources to be totally separate, but for captive currencies like BankFoo Non-Inflatable Zorkmids, you might want to get them together, though you might want to have two accounts, one of which is quiet and subscribes to the price reports and another where your real transactions happen.) Alice du Gnome-ynous.

1 0

Re: "Contempt" charges likely to increase
by ddfr＠best.com 17 Dec '03

17 Dec '03

Unicorn wrote: > No ISP in its right mind is going to ask for trouble. If I'm a >prosecutor and I suspect that the ISP may be complicit in hiding >evidence, I'm going to ask for a search and seizure warrant (a la sun >devil) and just walk in and take the equipment I believe the data to be >on and then satisify myself that it's unattainable. Last semester I taught a seminar on computers, crime, and privacy and we had, as a guest lecturer one evening, Silicon Valley's one full time computer cop (he works for the SC County D.A.'s office). One of his comments was that ISP's were generally very cooperative, because they knew that he could legally impose large costs on them by seizing their systems as evidence. David Friedman

1 0

List of reliable remailers
by Raph Levien 17 Dec '03

17 Dec '03

I operate a remailer pinging service which collects detailed information about remailer features and reliability. To use it, just finger remailer-list(a)kiwi.cs.berkeley.edu There is also a Web version of the same information, plus lots of interesting links to remailer-related resources, at: http://www.cs.berkeley.edu/~raph/remailer-list.html This information is used by premail, a remailer chaining and PGP encrypting client for outgoing mail. For more information, see: http://www.c2.org/~raph/premail.html For the PGP public keys of the remailers, finger pgpkeys(a)kiwi.cs.berkeley.edu This is the current info: REMAILER LIST This is an automatically generated listing of remailers. The first part of the listing shows the remailers along with configuration options and special features for each of the remailers. The second part shows the 12-day history, and average latency and uptime for each remailer. You can also get this list by fingering remailer-list(a)kiwi.cs.berkeley.edu. $remailer{"extropia"} = "<remail(a)miron.vip.best.com> cpunk pgp special"; $remailer{"portal"} = "<hfinney(a)shell.portal.com> cpunk pgp hash"; $remailer{"alumni"} = "<hal(a)alumni.caltech.edu> cpunk pgp hash"; $remailer{"bsu-cs"} = "<nowhere(a)bsu-cs.bsu.edu> cpunk hash ksub"; $remailer{"c2"} = "<remail(a)c2.org> eric pgp hash reord"; $remailer{"penet"} = "<anon(a)anon.penet.fi> penet post"; $remailer{"hacktic"} = "<remailer(a)utopia.hacktic.nl> cpunk mix pgp hash latent cut post ek"; $remailer{"flame"} = "<remailer(a)flame.alias.net> cpunk mix pgp. hash latent cut post reord"; $remailer{"rahul"} = "<homer(a)rahul.net> cpunk pgp hash filter"; $remailer{"mix"} = "<mixmaster(a)remail.obscura.com> cpunk mix pgp hash latent cut ek ksub reord ?"; $remailer{"ford"} = "<remailer(a)bi-node.zerberus.de> cpunk pgp hash ksub ek"; $remailer{"vishnu"} = "<mixmaster(a)vishnu.alias.net> cpunk mix pgp hash latent cut ek ksub reord"; $remailer{"robo"} = "<robo(a)c2.org> cpunk hash mix"; $remailer{"replay"} = "<remailer(a)replay.com> cpunk mix pgp hash latent cut post ek"; $remailer{"spook"} = "<remailer(a)spook.alias.net> cpunk mix pgp hash latent cut ek reord"; $remailer{"rmadillo"} = "<remailer(a)armadillo.com> mix cpunk pgp hash latent cut ek"; $remailer{"ecafe"} = "<cpunk(a)remail.ecafe.org> cpunk mix"; $remailer{"wmono"} = "<wmono(a)valhalla.phoenix.net> cpunk mix pgp. hash latent cut"; $remailer{"shinobi"} = "<remailer(a)shinobi.alias.net> cpunk mix hash latent cut ek reord"; $remailer{"amnesia"} = "<amnesia(a)chardos.connix.com> cpunk mix pgp hash latent cut ksub"; $remailer{"gondolin"} = "<mix(a)remail.gondolin.org> cpunk mix pgp hash latent cut ek reord"; $remailer{"tjava"} = "<remailer(a)tjava.com> cpunk mix pgp hash latent cut"; $remailer{"pamphlet"} = "<pamphlet(a)idiom.com> cpunk pgp hash latent cut ?"; $remailer{'alpha'} = '<alias(a)alpha.c2.org> alpha pgp'; $remailer{'gondonym'} = '<alias(a)nym.gondolin.org> alpha pgp'; $remailer{'nymrod'} = '<nymrod(a)nym.alias.net> alpha pgp'; $remailer{'cubed'} = '<alias(a)alias.alias.net> alpha pgp'; $remailer{"lead"} = "<mix(a)zifi.genetics.utah.edu> cpunk pgp hash latent cut ek"; $remailer{"treehole"} = "<remailer(a)mockingbird.alias.net> cpunk pgp hash latent cut ek"; $remailer{"nemesis"} = "<remailer(a)meaning.com> cpunk pgp hash latent cut"; $remailer{"exon"} = "<remailer(a)remailer.nl.com> cpunk pgp hash latent cut ek"; $remailer{"vegas"} = "<remailer(a)vegas.gateway.com> cpunk pgp hash latent cut"; $remailer{"haystack"} = "<haystack(a)holy.cow.net> cpunk pgp hash latent cut ek"; $remailer{"ncognito"} = "<ncognito(a)gate.net> mix cpunk latent"; catalyst(a)netcom.com is _not_ a remailer. lmccarth(a)ducie.cs.umass.edu is _not_ a remailer. usura(a)replay.com is _not_ a remailer. Groups of remailers sharing a machine or operator: (c2 robo alpha) (gondolin gondonym) (flame hacktic replay) (alumni portal) (vishnu spook wmono nymrod) Use "premail -getkeys pgpkeys(a)kiwi.cs.berkeley.edu" to get PGP keys for the remailers. Fingering this address works too. Note: The remailer list now includes information for the alpha nymserver. Last update: Mon 8 Apr 96 6:48:25 PDT remailer email address history latency uptime ----------------------------------------------------------------------- cubed alias(a)alias.alias.net *+#********* 15:15 100.00% exon remailer(a)remailer.nl.com **-*++++***+ 7:10 100.00% ecafe cpunk(a)remail.ecafe.org ######*#+### :53 99.99% shinobi remailer(a)shinobi.alias.net ###*###+-.-# 57:53 99.96% ncognito ncognito(a)gate.net **-###***#*# 1:58 99.95% spook remailer(a)spook.alias.net **+****+**** 19:38 99.92% mix mixmaster(a)remail.obscura.com --*-+-+-++++ 4:47:31 99.92% amnesia amnesia(a)chardos.connix.com -+++----++- 2:23:46 99.89% portal hfinney(a)shell.portal.com #*##- *##### 6:42 99.89% alpha alias(a)alpha.c2.org ++**++ ++++* 43:53 99.83% vishnu mixmaster(a)vishnu.alias.net **--+*+--.-* 5:31:24 99.82% treehole remailer(a)mockingbird.alias.net -+++---..-+ 7:01:45 99.73% alumni hal(a)alumni.caltech.edu -###-### ### 25:20 99.66% vegas remailer(a)vegas.gateway.com #+##-* -***+ 1:08:32 99.49% hacktic remailer(a)utopia.hacktic.nl ****** ***** 8:32 99.37% flame remailer(a)flame.alias.net ------ ---- 4:10:53 98.99% penet anon(a)anon.penet.fi _..._---.-- 27:54:21 98.63% replay remailer(a)replay.com +**+ -**** 15:48 98.40% nymrod nymrod(a)nym.alias.net *+--**+--. * 6:11:27 98.39% c2 remail(a)c2.org -+++ +++++++ 40:17 97.18% gondonym alias(a)nym.gondolin.org -+---+ .- 16:49:10 89.13% extropia remail(a)miron.vip.best.com -- ------- 7:03:22 88.90% gondolin mix(a)remail.gondolin.org -----+ .- 15:51:19 88.04% haystack haystack(a)holy.cow.net ***+*#*-## 47:06 84.29% lead mix(a)zifi.genetics.utah.edu ++++ 38:07 69.04% nemesis remailer(a)meaning.com ***** 2:39:59 38.60% tjava remailer(a)tjava.com 1:02 -3.94% History key * # response in less than 5 minutes. * * response in less than 1 hour. * + response in less than 4 hours. * - response in less than 24 hours. * . response in more than 1 day. * _ response came back too late (more than 2 days). cpunk A major class of remailers. Supports Request-Remailing-To: field. eric A variant of the cpunk style. Uses Anon-Send-To: instead. penet The third class of remailers (at least for right now). Uses X-Anon-To: in the header. pgp Remailer supports encryption with PGP. A period after the keyword means that the short name, rather than the full email address, should be used as the encryption key ID. hash Supports ## pasting, so anything can be put into the headers of outgoing messages. ksub Remailer always kills subject header, even in non-pgp mode. nsub Remailer always preserves subject header, even in pgp mode. latent Supports Matt Ghio's Latent-Time: option. cut Supports Matt Ghio's Cutmarks: option. post Post to Usenet using Post-To: or Anon-Post-To: header. ek Encrypt responses in reply blocks using Encrypt-Key: header. special Accepts only pgp encrypted messages. mix Can accept messages in Mixmaster format. reord Attempts to foil traffic analysis by reordering messages. Note: I'm relying on the word of the remailer operator here, and haven't verified the reord info myself. mon Remailer has been known to monitor contents of private email. filter Remailer has been known to filter messages based on content. If not listed in conjunction with mon, then only messages destined for public forums are subject to filtering. Raph Levien

1 0