December 2003 - cypherpunks-legacy

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{"mix"} = "<mixmaster(a)remail.obscura.com> cpunk mix pgp hash latent cut ek ksub reord ?"; $remailer{"replay"} = "<remailer(a)replay.com> cpunk mix pgp hash latent cut post ek"; $remailer{"exon"} = "<remailer(a)remailer.nl.com> cpunk pgp hash latent cut ek"; $remailer{"haystack"} = "<haystack(a)holy.cow.net> cpunk mix pgp hash latent cut ek"; $remailer{"lucifer"} = "<lucifer(a)dhp.com> cpunk mix pgp hash latent cut ek"; $remailer{"jam"} = "<remailer(a)cypherpunks.ca> cpunk mix pgp hash middle latent cut ek"; $remailer{"winsock"} = "<winsock(a)rigel.cyberpass.net> cpunk pgp pgponly hash cut ksub reord"; $remailer{'nym'} = '<config(a)nym.alias.net> newnym pgp'; $remailer{"balls"} = "<remailer(a)huge.cajones.com> cpunk pgp hash latent cut ek"; $remailer{"squirrel"} = "<mix(a)squirrel.owl.de> cpunk mix pgp pgponly hash latent cut ek"; $remailer{"middle"} = "<middleman(a)jpunix.com> cpunk mix pgp hash latent cut ek reord"; $remailer{'cyber'} = '<alias(a)alias.cyberpass.net> alpha pgp'; $remailer{"dustbin"} = "<dustman(a)athensnet.com> cpunk pgp hash latent cut ek mix reord middle"; $remailer{'weasel'} = '<config(a)weasel.owl.de> newnym pgp'; $remailer{"reno"} = "<middleman(a)cyberpass.net> cpunk mix pgp hash middle latent cut ek reord ?"; $remailer{"wazoo"} = "<remailer(a)wazoo.com> cpunk mix pgp hash latent cut ek"; $remailer{"shaman"} = "<remailer(a)lycaeum.org> cpunk pgp hash latent cut ek"; $remailer{"hidden"} = "<remailer(a)hidden.net> cpunk pgp hash latent cut"; 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. remailer(a)crynwr.com is _not_ a remailer. There is no remailer at relay.com. Groups of remailers sharing a machine or operator: (cyber mix) (weasel squirrel) The alpha and nymrod nymservers are down due to abuse. However, you can use the nym or weasel (newnym style) nymservers. The cyber nymserver is quite reliable for outgoing mail (which is what's measured here), but is exhibiting serious reliability problems for incoming mail. The squirrel and winsock remailers accept PGP encrypted mail only. 403 Permission denied errors have been caused by a flaky disk on the Berkeley WWW server. This seems to be fixed now. The penet remailer is closed. Last update: Mon 5 May 97 6:45:39 PDT remailer email address history latency uptime ----------------------------------------------------------------------- nym config(a)nym.alias.net *+*#+#+++**# 3:30 99.99% cyber alias(a)alias.cyberpass.net ++++*-++***# 19:39 99.98% balls remailer(a)huge.cajones.com *####*####*# 1:52 99.97% squirrel mix(a)squirrel.owl.de +-++++++++- 1:54:28 99.94% weasel config(a)weasel.owl.de +-++-+++++- 1:57:01 99.90% lucifer lucifer(a)dhp.com ++++++++++++ 35:18 99.90% mix mixmaster(a)remail.obscura.com ++.-.-.---.- 8:18:24 99.87% replay remailer(a)replay.com ***++- * -* 54:35 98.34% jam remailer(a)cypherpunks.ca ******* *** 8:52 97.43% winsock winsock(a)rigel.cyberpass.net -------..- 5:58:48 97.30% hidden remailer(a)hidden.net #+#**#+# + 5:34:09 95.94% reno middleman(a)cyberpass.net -+.--+-.+ 1:19:01 90.79% dustbin dustman(a)athensnet.com -..-- 3:59:41 78.48% 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

Problems with posts
by William H. Geiger III 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Hmmmm I seem to be having some problems with getting my messages posted to the list (at least they are not showing up back here). :( This is just a test so please ignore. Thanks, - -- - ----------------------------------------------------------- William H. Geiger III http://www.amaranth.com/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. Finger whgiii(a)amaranth.com for PGP Key and other info - ----------------------------------------------------------- Tag-O-Matic: Win3.1? For fast relief call 800-3-IBM-OS2. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Registered User E-Secure v1.1 ES000000 iQCVAwUBM24DHo9Co1n+aLhhAQFQAwP+L3AXu9AbQsCuaNroI3UfuyAKGO70MiMM MD4bxRENaBwRc4A1aU6QsZosbuyRZfOZqCQ67ANI7Ecowfij9rc92wOvl+ePhYjS ObvDdDoDRpDqBDQ8oVimDkIwXJ8z79xxK6s3F0uevSb4pSlz3MZHrf+BoDxc5L1u mA403n2n+W8= =cAdA -----END PGP SIGNATURE-----

1 0

Re: Controversial Commercial ISP for Remailer?
by Dave Hayes 17 Dec '03

17 Dec '03

Mr. Arachelian writes: > Well, here's a thought. Let's pool some cash together and go off and > spam cyberpromo from the inside. Let's get an account there, turn it > around and spam everyone and their mother at cyberpromo and their > respective subdomains. Wouldn't that be sweet revenge? If vengance is your concern, this is a good idea. Neither vengance nor righteousness is my concern, however. Judgementally speaking, if you spam, you may not continue to condemn spammers and be consistent. ------ Dave Hayes - Altadena CA, USA - dave(a)jetcafe.org Freedom Knight of Usenet - http://www.jetcafe.org/~dave/usenet "If you are distressed by anything external, the pain is not due to the thing itself, but to your estimate of it; and this you have the power to revoke at any moment." - Marcus Aurelius, 121-180

4 6

Win up to $4,950.00 Instantly with Cyber Casino
by Service＠iBase.net 17 Dec '03

17 Dec '03

Win up to $4,950.00 Instantly with Cyber Casino, found at http://www.iBase.net/InternetCasino. See you there! "Because face it......MONEY MATTERS!" /////////////////////////////////////////////////////////////////////////////// If you wish to be removed from this advertiser's future mailings, please reply with the subject "Remove" and this software will automatically block you from their future mailings. ////////////////////////////////////////////////////////////////////////////////

1 0

Fast Cheap Unreviewed Stream Cipher
by Bill Frantz 17 Dec '03

17 Dec '03

I received this code from another friend. Here's a FAST somewhat cryptographically secure pseudo-random generator written by a friend of mine that wishes to remain anonymous. He has given permission for the following code to be placed in the public domain, and to be sent to cypherpunks and others for review. Alas, I have never gotten around to doing so. As it states, on a PowerPC it'll produce bits fast enough to be a pseudo-one-time pad / stream cipher for good digitized video on a LAN (the purpose for which he originally sent it to me) and hence should do point-to-point audio without even breathing hard. For those who haven't heard, the scenario is for point-to-point audio to use an affordable (weak) stream cipher, but to be changing keys frequently using our strongly secure SSL channel. Each costly break would only compromise a few seconds or so of audio. The following code may serve as the affordable (but maybe better than weak) stream cipher. /******************************************************/ /** (c) 1823 Millard Fillmore, all rights expired **/ /** Full words of pseudorandom bits at video speed **/ /******************************************************/ #include <stdlib.h> #include <stdio.h> #include <time.h> #include <sioux.h> #define WORD_SIZE 32 unsigned long shiftRand(); static void refillShiftRand(); void seedShiftRand(unsigned long seed); static unsigned long shiftRandArray[31] = { }; // to hold internal state values static unsigned long * arrayPtr = shiftRandArray; // incremented as state values are consumed static unsigned long * const end = shiftRandArray + 31; // marks end (and need to refill array) // Initializes shiftRandArray to pseudorandom contents using a seed value and the system rand function, // which is assumed to produce 16 bits per call. Low rand bits are obscured by xoring with high bits from other // calls, and all product bits depend on two or more calls to rand. The resulting values are themselves obscured, // not simply revealed at the output, hence this is probably overkill. The seed acts as a key. void seedShiftRand(unsigned long seed) { srand(seed); long cyclesPerWord = ((WORD_SIZE + 7) >> 3) - 1; // will add a net of 8 bits per call to rand unsigned long * arrPtr = shiftRandArray; for (; arrPtr < end; arrPtr++) { unsigned long rand1 = rand(); // wrap this value around word boundary: unsigned long element = (rand1 >> 8) | (rand1 << (WORD_SIZE - 8)); for (long i = 0; i < cyclesPerWord; i++) { element ^= rand() << (8 * i); //previous 8 high bits obscure 8 new low bits } *arrPtr = element; } } // Low-order bits in the following act as an xor-based linear feedback shift register (with moving taps // and stationary data); the repeat period equals (1 << 31) - 1. Higher-order bits have similar // "intrinsic" behavior, but the state of each is determined by additional xoring with a sequence // of carry bits from below, causing repeated period-doubling across the width of the word. // // The choice of 31 and 13 corresponds to a primitive polynomial mod 2; Applied Cryptography has // typos in polynomial coefficients, but the repeat period was tested directly. This code avoids a // shift-direction mistake in Applied Cryptography, and hence follows Numerical Recipes. // static void refillShiftRand() { unsigned long * tap0 = shiftRandArray + 0; unsigned long * tap13 = shiftRandArray + 13; *tap0 = *tap0 + *tap13; tap0++; tap13++; *tap0 = *tap0 + *tap13; tap0++; tap13++; *tap0 = *tap0 + *tap13; tap0++; tap13++; *tap0 = *tap0 + *tap13; tap0++; tap13++; *tap0 = *tap0 + *tap13; tap0++; tap13++; *tap0 = *tap0 + *tap13; tap0++; tap13++; *tap0 = *tap0 + *tap13; tap0++; tap13++; *tap0 = *tap0 + *tap13; tap0++; tap13++; *tap0 = *tap0 + *tap13; tap0++; tap13++; *tap0 = *tap0 + *tap13; tap0++; tap13++; *tap0 = *tap0 + *tap13; tap0++; tap13++; *tap0 = *tap0 + *tap13; tap0++; tap13++; *tap0 = *tap0 + *tap13; tap0++; tap13++; *tap0 = *tap0 + *tap13; tap0++; tap13++; *tap0 = *tap0 + *tap13; tap0++; tap13++; *tap0 = *tap0 + *tap13; tap0++; tap13++; *tap0 = *tap0 + *tap13; tap0++; tap13++; *tap0 = *tap0 + *tap13; tap0++; tap13 = shiftRandArray; *tap0 = *tap0 + *tap13; tap0++; tap13++; *tap0 = *tap0 + *tap13; tap0++; tap13++; *tap0 = *tap0 + *tap13; tap0++; tap13++; *tap0 = *tap0 + *tap13; tap0++; tap13++; *tap0 = *tap0 + *tap13; tap0++; tap13++; *tap0 = *tap0 + *tap13; tap0++; tap13++; *tap0 = *tap0 + *tap13; tap0++; tap13++; *tap0 = *tap0 + *tap13; tap0++; tap13++; *tap0 = *tap0 + *tap13; tap0++; tap13++; *tap0 = *tap0 + *tap13; tap0++; tap13++; *tap0 = *tap0 + *tap13; tap0++; tap13++; *tap0 = *tap0 + *tap13; tap0++; tap13++; *tap0 = *tap0 + *tap13; return; } // sum at 10 million iterations = 1344076334 /* // Slightly faster than the above on a 604, provided CodeWarrior's instruction-scheduling "optimization" is OFF. static void refillShiftRand() { unsigned long * tap0a = shiftRandArray + 0; unsigned long * tap0b = shiftRandArray + 1; // uses more registers unsigned long * tap13a = shiftRandArray + 13; unsigned long * tap13b = shiftRandArray + 14; *tap0a = *tap0a + *tap13a; tap0a += 2; tap13a += 2; *tap0b = *tap0b + *tap13b; tap0b += 2; tap13b += 2; *tap0a = *tap0a + *tap13a; tap0a += 2; tap13a += 2; *tap0b = *tap0b + *tap13b; tap0b += 2; tap13b += 2; *tap0a = *tap0a + *tap13a; tap0a += 2; tap13a += 2; *tap0b = *tap0b + *tap13b; tap0b += 2; tap13b += 2; *tap0a = *tap0a + *tap13a; tap0a += 2; tap13a += 2; *tap0b = *tap0b + *tap13b; tap0b += 2; tap13b += 2; *tap0a = *tap0a + *tap13a; tap0a += 2; tap13a += 2; *tap0b = *tap0b + *tap13b; tap0b += 2; tap13b += 2; *tap0a = *tap0a + *tap13a; tap0a += 2; tap13a += 2; *tap0b = *tap0b + *tap13b; tap0b += 2; tap13b += 2; *tap0a = *tap0a + *tap13a; tap0a += 2; tap13a += 2; *tap0b = *tap0b + *tap13b; tap0b += 2; tap13b += 2; *tap0a = *tap0a + *tap13a; tap0a += 2; tap13a += 2; *tap0b = *tap0b + *tap13b; tap0b += 2; tap13b += 2; *tap0a = *tap0a + *tap13a; tap0a += 2; tap13a = shiftRandArray; *tap0b = *tap0b + *tap13b; tap0b += 2; tap13b = (shiftRandArray + 1); *tap0a = *tap0a + *tap13a; tap0a += 2; tap13a += 2; *tap0b = *tap0b + *tap13b; tap0b += 2; tap13b += 2; *tap0a = *tap0a + *tap13a; tap0a += 2; tap13a += 2; *tap0b = *tap0b + *tap13b; tap0b += 2; tap13b += 2; *tap0a = *tap0a + *tap13a; tap0a += 2; tap13a += 2; *tap0b = *tap0b + *tap13b; tap0b += 2; tap13b += 2; *tap0a = *tap0a + *tap13a; tap0a += 2; tap13a += 2; *tap0b = *tap0b + *tap13b; tap0b += 2; tap13b += 2; *tap0a = *tap0a + *tap13a; tap0a += 2; tap13a += 2; *tap0b = *tap0b + *tap13b; tap0b += 2; tap13b += 2; *tap0a = *tap0a + *tap13a; tap0a += 2; tap13a += 2; *tap0b = *tap0b + *tap13b; *tap0a = *tap0a + *tap13a; return; } // sum at 10 million iterations = 1344076334 */ // The array-filling mechanism above provides an information-conserving mechanism for producing // pseudorandom numbers with an effectively unlimited repeat period, fast, but based on a large number of // internal state bits, and having a bit of a given order eventually depend on all bits of the same or // lower order in all words in the array. // Rare, transient states having almost all zeros in the low bits will show strong correlations, // since the restoration of normal bit statistics will take several cycles. (The all-zero state // is inaccessible unless it is the starting condition -- one might test for this.) Correlations // in the frequency of low-order zero bits in sequentially generated array elements are eliminated // in the output by xoring high bits with the low bits; adding a preceding squaring operation // adds the effect of making any given output consistent with a large number of array element states, // making inferences regarding the internal state of the system relatively difficult. inline unsigned long shiftRand() { ((arrayPtr == end) ? // '?:' instead of 'if' to enable inlining by CW compiler (refillShiftRand(), arrayPtr = shiftRandArray, 0) : 0); unsigned long output = *arrayPtr++; unsigned long square = output * output; // this multiplication seems free on a 605 return(square + (output >> (WORD_SIZE / 2))); } // With multiplication (above) and summing of output to prevent bogus optimizations, 16.5 clocks per word. // Test code for CodeWarrier environment. void main () { SIOUXSettings.asktosaveonclose = FALSE; unsigned long sum = 0; seedShiftRand(12345); // easily guessed seed long start = clock(); for (long i = 0; i < 2000000; i++) { sum += shiftRand(); sum += shiftRand(); sum += shiftRand(); sum += shiftRand(); sum += shiftRand(); } unsigned long end = clock(); printf("\n sum = %u", sum); printf("\n\n time = %d \n", (int)(1000.0 * ((float)(end - start) / (float)CLOCKS_PER_SEC))); }

1 0

(Fwd) Extropia dead
by Alec 17 Dec '03

17 Dec '03

>Mailing-List: contact pgp-users-help(a)joshua.rivertown.net; run by ezmlm >Reply-To: pgp-users(a)joshua.rivertown.net >Comments: Authenticated sender is <fredr(a)[204.141.41.5]> >From: "Fred B. Ringel" <fredr(a)[204.141.41.5]> >Organization: Rivertown.Net >To: pgp-users(a)joshua.rivertown.net >Date: Mon, 5 May 1997 12:52:57 -0500 >Subject: (Fwd) Extropia dead >Priority: normal > >Hi all- > > Thought I'd pass this *bad* news along. :-(( > > Fred >------------------------------------------ >Date: Mon, 5 May 1997 00:39:36 -0700 (PDT) >From: Miron <miron(a)best.com> > >Due to best.com (Best Internet) policies >remail(a)miron.vip.best.com has been shut down. >You will only received one notice.

1 0

Re: XS4ALL censored pages (fwd)
by root 17 Dec '03

17 Dec '03

As we guessed XS4ALL don`t even have the guts to send us a copy of the pages they censored. Check this out... >Dear Paul, >>Postmaster, >> >>Please send me a copy of your current pricing for web space. >> >>Also, please send me a copy of the marajuana pages you recently removed >>from your web server. > >Hearby you recieve information about all services from xs4all. > >We don't know anything about marajuana pages so we can't send you a copy of >that. > >Kind regards, > <Much pricing information and rattling of the stick in the swill bucket cut> >XS4ALL Internet B.V. Sales afdeling: >Postbus 1848 Email: sales(a)xs4all.nl >1000 BV Amsterdam Http://www.xs4all.nl/business > >Tel: 020-6222885 Fax: 020-5352002 >Ma. t/m vrij. van 12.00u tot 20.00u

1 0

Re: Rape, death and XS4ALL
by Alex de Joode 17 Dec '03

17 Dec '03

Paul Bradley sez: : > Perhaps we should further expose XS4ALL's hypocricy by renting from the : > web space and putting up some pages they won't like. : I think this is an excellent idea, I`ll call or mail them in a few days : to find out their pricing structure. 30 Guilders a month (approx 17 USD a month) you get 5mb for your homepage. -- -aj-

1 0

Re: Rejecting Dialog with Government Vermin
by jimbell＠pacifier.com 17 Dec '03

17 Dec '03

At 22:43 5/01/97 -0700, Kent Crispin wrote: >On Wed, Apr 30, 1997 at 08:24:27PM -0800, Jim Bell wrote: >> I feel confident that a statistical analysis of various countries' >> governments would reveal a wide scatter in the relationship between >> population and government size. One of the main factors in this scatter is >> simply the amount that government has decided to butt into activities that >> could (and should) be privatized. Another is the amount that the >> government steals from one group in order to reliably receive the votes of >> some other group. > >> Population size would end up being a very poor determinant of government >> size. > >Yes, there would be scatter, but it is not important. The only reason "it is not important" is that this scatter is what demolishes your view of the world. > Population size >is *obviously* a strong determinant of government size. But probably not even close to the largest determinant. >So, having clearly established that larger countries will on balance >have larger governments, we can then just look at organizational >dynamics. *Any* large organization requires more infrastructure to >function. *Any* large organization will develop bureaucracy. This >is true for governments, this is true for businesses, this is true >for schools, this is true for militias. A big city police department >will have many different precints, with multiple layers of >management, a small town will have a chief of police and a few >deputies. But NONE of this is truly needed. I have a solution to that problem. Jim Bell jimbell(a)pacifier.com

4 4

Re: Bypassing the Digicash Patents
by azur＠netcom.com 17 Dec '03

17 Dec '03

>> When one combines the transactional economic advantages of DBC: no customer >> accounts, statement generation, little or no need for dispute resolution >> and the economies of using the Net for settlement, with the still >> considerable marketing costs, the likely differential between DBC and >> CC/ACH is closer to one order of magnitude at best. > >Again, I still hold out for three or four. > >> This is still >> considerable, however, and if properly branded and marketed could >> significantly displace current competition, for lower value transactions. >> The overhead of CC discounts is keenly watched by merchants. If a trusted >> DBC issuer/agent offered 1.0% fees (especially to on-line merchants) it >> would get noticed quickly. > >Agreed. However, when it happens, it'll probably be more significant than >that. I think removing 3 or 4 extra zeroes from the status quo is probably >what people should try to do when developing this stuff. I think that the >technology offers us at least that much slack, and probably more. > >Remember, it *is* supposed to change the world. :-). If I grant that you're right that DBCs will be 3-4 orders of magnitude cheaper than the book-entry approaches, and I'm ready yet, there is still the issue of whether such savings can be quickly passed on to the merchant and consumer, and thus spark this revoltion. Consider this, if a DBC-based system were to garner 3% (about what it might take to get noticed by the consumer, retail and business markets) of the GDP's $4 trillion in transactions, or about $120 billion, and the transaction fees were $0.0025, this would generate about $300 million in fees. This is about what Western Union International generates in fees, a very respectable sized business. But how much marketing and branding expenditures would it take to get there? All financial products which attempted to reach a broad market and have a significant impact have required, in the past, significant up-front marketing expenses (VISA succeeded because BankAmericard spent in the $10s million per year range). Unless the Net will enable a 3-4 orders of magnitude reduction in such expenses, amounting to an historic bootstrap, it is difficult to see how this will occur without a white knight. A similar situation is occuring in cellular. Prices are plummeting because many new companies are building out competitive PCS networks and forward pricing their services to gain market share and economies of scale. These new players have deep pockets (or are backed by those with deep pockets). To wrench away the bank and credit card francshise from the established players may require similar sized investments. --Steve PGP mail preferred Fingerprint: FE 90 1A 95 9D EA 8D 61 81 2E CC A9 A4 4A FB A9 Key available on BAL server, http://www-swiss.ai.mit.edu/~bal/pks-toplev.html --------------------------------------------------------------------- Steve Schear | tel: (702) 658-2654 CEO | fax: (702) 658-2673 First ECache Corporation | 7075 West Gowan Road | Suite 2148 | Las Vegas, NV 89129 | Internet: azur(a)netcom.com --------------------------------------------------------------------- "I know not what instruments others may use, but as for me, give me Ecache or give me debt."

2 1