Text File

precedence: bulk Subject: RISKS DIGEST 19.21

RISKS-LIST: Risks-Forum Digest Thursday 5 June 1997 Volume 19 : Issue 21

FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

***** See last item for further information, disclaimers, caveats, etc. *****

Contents: Programmed Tunnel-Digging Robot (Robert J. Sandler) Cashless not crashless (David Hood) Revenge spam hits antispammer (Beth Arnold) Anti-spam missile misfires... (Reuben G. Torrey and Richard Karash) Big Brother strikes again... Netcheck New Zealand (Bruce J. Fitzsimons) When is 0 not 0? The wonderful world of the Web (Clarke Christopher Turrall) Java has a similar problem to the 2000-year problem (Quinton Jansen via Lindsay F. Marshall) Attack on California's electric power infrastructure (Betty G.O'Hearn) Indictments for Computer Chip Theft (Edupage) Commands without timeout (Nick Brown) Re: Computer fraud in subscribing ...? (Kevin McCullen) Re: newmediagroup.com headers were forged ... (Barry Brown) Re: Florida "Computer Gang" Members Arrested (Mich Kabay) Uniform password method (Ken Knowlton) Re: Microsoft and Privacy (Marnix Arnold) Re: Time-zone bug in Canadian election (Mark Brader) Re: Lost Pond: Jurassic Duck (Michael Handler) Re: Senate anti-spam bill (Ray Everett-Church) More dangers of e-mail to the wrong users (Aviel Rubin) Abridged info on RISKS (comp.risks)

----------------------------------------------------------------------

Date: Mon, 2 Jun 1997 00:18:18 -0400 From: "Robert J. Sandler" <rsandler@compuserve.com> Subject: Programmed Tunnel-Digging Robot

Anthony Catania got suspicious when his floor started to shake. For weeks, sewer diggers had been tearing up the street in front of his restaurant-supply store in Seattle. Among the deployed tools was a tunnel-digging robot "mole," a $475,000, 18-foot-long device that can chew through 70 feet of soil a day using programmed directional coordinates. The machine has been doing solid yeoman's work for years, but this time somebody programmed it incorrectly. Catania realized this when he saw 11 hard hats peering expectantly into a 30-foot-deep hole in the street, one muttering, "Our mole is supposed to come out here but we haven't seen it." Eventually recovered without damaging Catania's property, the wayward mole left behind a 700-foot hole that will have to be filled with concrete. Cost: $600,000. [Source: *The New York Times Magazine*, 1 Jun 1997, p. 25]

Apparently for $475,000 you don't get any tracking!

Robert J. Sandler rsandler@compuserve.com

------------------------------

Date: Thu, 5 Jun 1997 16:04:11 +1200 (NZST) From: david.hood@stonebow.otago.ac.nz (David Hood) Subject: Cashless not crashless

On Monday 2 Jun 1997, the major national EFTPOS (Electronic Funds Transaction, Point-Of-Sale) system crashed from 10am to noon. During the two hours Electronic Transaction Services estimated about 100,000 transactions were lost. Electronic Transactions Services covers about 80% of the country's retail terminals. The failure did not effect 'hole in the wall' money machines (ATMs) (source: *Otago Daily Times* 3 Jun 1997). Regarding the estimate of lost transactions, it is worth keeping in mind many major retailers have manual backup procedures for dealing with debit cards while the system is down.

In a radio interview the following day a spokesman said that there were two failures. The first was the failure that caused a processor to stop working. The second, a failure in the backup procedures that should have meant the workload of the failed processor was distributed to the company's other 7 processors. The specific causes of the failures were not known at the time of the interview.

The failure took place on a public holiday which was being used as a 'sale day' by some national chains of stores. Supermarkets were open at the time, but many locally owned shops were closed for the holiday.

David H.

------------------------------

Date: Sun, 1 Jun 1997 20:24:15 -0400 From: "Beth Arnold" <betharnold@cfjf.dyn.ml.org> Subject: Revenge spam hits antispammer

My name is Elisabeth Arnold. As you may or may not know, I have been the victim of a massive revenge spam. I work at a small ISP in New Jersey. Recently, I pulled a spammer's account for repeated violation of our acceptable-use policy. This was 2 weeks ago. That weekend, a message was sent out by "Beth Arnold" with a bunch of gibberish and a 200k wav file of "animal sounds".

This weekend, 2 separate messages were sent, one to participants in the net-abuse groups -- including a 300k wav file of recordings from the activity menu of an Audix voice-mail system, and another to participants in the comp.* and rec.* groups. You may very well have received this message:

> Call BETH ARNOLD at 1-800-450-5766 to order a list of e-mail addresses and > bulk e-mail software. If you got this message, congratulations. You are > on a list of e-mail addresses that we sell. You will receive many more > messages like this one. [SLIGHTLY EDITED FOR RISKS. PGN]

This message was obvious flame bait, and it worked very well. I received 200 calls to my 800 number before disconnecting it. My mail server was inundated with mail bombs, returns, and complaints. My http ports were SYN attacked. And I was "ping stormed".

UUNet is useless in tracking this person down. They just don't care. I would appreciate any help I can get.

Thank you, Beth Arnold betharnold@cfjf.dyn.ml.org

------------------------------

Date: 4 Jun 97 7:59:02 From: "reuben.g.torrey" <reuben.g.torrey@ac.com> Subject: Anti-spam missile misfires at CompuServe (Richard Karash)

I monitor the Learning Organization news list as it comes into our organization. The following item just came through. Richard Karash is the manager of this news group. Here is another RISK of trying to maintain a "too protected" community with a border patrol that is not able to tell who is friend or who is foe. - Ben Torrey

>We've lost all compuserve readers... LO13813 >rkarash @ karash.com (Richard Karash) @ internet

>I believe that, as a result of a change in policy at compuserve, none of >our compuserve subscribers are getting learning-org mail. I have been in >touch with several to confirm this and it appears to be the case.

>Here's what seems to be happening: my tech support people here at my >vendor (world.std.com) think that compuserve is blocking all mail which >is directed to multiple addresses (more than a few) at compuserve. They >are doing so to combat unsolicited junk e-mail, but the effect is to kill >mailing lists for compuserve accounts.

>Until this can be changed, we probably won't be hearing much from several >of our frequent contributors.

> Richard Karash ("Rick") rkarash@karash.com <http://world.std.com/~rkarash> > Host for Learning-Org Mailing List <http://world.std.com/~lo> (617)227-0106

[I sent mail to postmaster@CompuServe.com asking for a clarification and giving alternative suggestions for handling the RISKS subscribers there. As of the time of posting this issue, I have heard nothing in return; business as usual? PGN]

------------------------------

Date: Tue, 3 Jun 1997 17:57:01 +1200 From: "Bruce J. Fitzsimons"<brucejfitzsimons@unn.unisys.com> Subject: Big Brother strikes again...

An article published today on the IDG Computerworld NZ site (www.idg.co.nz) detailed a "brave" new initiative in making information on individuals available on the Internet.

The exact link is: http://www.idg.co.nz/nzweb/61e6.html but I wouldn't expect it will be there forever.

Some of the best points are:

* Netcheck New Zealand believes it is the first in the world to provide credit checks on people over the Internet.

* The Managing Director will not reveal what security protects the site, but says it is secure. "We have sufficient security measures so that break-ins don't happen."

* The companies using the system have to be members, and use a password to get access to the operation's database. He says member companies have to show their inquiries are what he calls 'Privacy Act compliant', meaning that they will have the signed consent of the customers they are doing the search on.

* One aspect of the site which the MD believes won't be able to go ahead is the one-off searches with payment by credit cards. In practice it would have meant anyone could do a credit check on anyone else. He now says it's unlikely that will ever get started.

* Conversely Baycorp, which is perhaps New Zealands biggest credit information bureau have stated that they will not be providing Internet access to their records, and their data is 40 bit public key encrypted when sent over the PSTN.

* Looking at the site, the login screen is not SSL encrypted. There is no information about the rest of the site.

I don't think I have to start to explain my concerns to RISKS readers.

I am bemused by the "in practice this would have meant anyone could do a credit check on anyone else" - how do I know that the companies that PAY to use this service are any more trustworthy than a casual user (etc etc).

Bruce Fitzsimons

------------------------------

Date: Tue, 3 Jun 1997 15:58:50 +0800 From: Clarke Christopher Turrall <asctclarke@ntu.edu.sg> Subject: When is 0 not 0? The wonderful world of the Web

This afternoon, I visited a web site that offered to help me work out how big a mortgage I could afford: http://www.halifax.co.uk/mortgage/pay.html I entered numbers to the nearest ten pounds in each box as requested, and my computer churned away computing the sum of these values. Imagine my surprise to find that the sum of a set of numbers each with a least significant digit of 0 does not sum to another number whose least significant digit is a 0. To cut a long story short, I identified the problem as the fact that I had entered 020 for one entry rather than 20. Now I don't know about you, but I think they are the same thing. Netscape (and MSIE) insists however that 020 is actually equal to 16. Ok so I realised quickly that the the number was being viewed as octal (I tried 0x... and that makes the input hexadecimal), but that's because I know what octal is. I would certainly never consider using it to enter an approximation of my monthly telephone bill on a web form.

The reason I had entered 020 in the box, was that it contained 0 by default, and I had added my 20 to the end of the string when I typed it, rather than replacing the 0 with 20. I feel sure that more users of the web will get caught with this trap, than there will be users who are angry about not being able to enter numbers in octal.

Chris Clarke

------------------------------

Date: Tue, 3 Jun 1997 08:14:02 +0100 (BST) From: "Lindsay F. Marshall" <Lindsay.Marshall@newcastle.ac.uk> Subject: Java has a similar problem to the 2000-year problem (fwd)

Date: Mon, 2 Jun 1997 13:09:01 -0700 (PDT) >From: Quinton Jansen <qjansen@dns1.cent.org> To: ietf@ietf.org Subject: Java has a similar problem to the 2000-year problem

"TIME IS ON JAVA'S SIDE (*Information Week*, 19 May 1997, p. 12)

Sun Microsystems acknowledged last week that the Java programming language has a year-2000-like date error: It will run out of dates in the year 292271023. Yes, that's roughly 292 million years from now. James Gosling, creator of Java, insists a team of engineers is rushing to fix the problem. "We can't be certain Java will be around that long," he kids, "but then again, we can't take any chances."

In case you were wondering, the year 292271023 is the estimated date for the year 2000 fix at the IRS."

------------------------------

Date: Wed, 04 Jun 1997 17:35:47 -0400 From: "Betty G.O'Hearn" <betty@infowar.com> Subject: Attack on California's electric power infrastructure

This morning's IWAR Situation Report contains information about an attack on the electric power infrastructure in California. Although the attack used conventional weapons, it is one of the first attacks on the power infrastructure possibly linked to a political situation. Surf over to: http://www.iwar.org, log in, and get a password. [...]

Betty@infowar.com, Assistant to Winn Schwartau

[Over 60 rounds were fired at a Pacific Gas and Electric substation in Redwood City, CA, knocking out power in the area. A Confederate flag and a newspaper with the headline of the McVeigh's guilty verdict were found on the fence surrounding the facility. PGN]

------------------------------

Date: Thu, 5 Jun 1997 11:31:55 -0400 (EDT) From: Edupage Editors <educom@educom.unc.edu> Subject: Indictments for Computer Chip Theft (Edupage)

Federal prosecutors have indicted 17 individuals for their involvement with an Asian organized-crime syndicate responsible for armed robberies in May 1995 of more than $10 million worth of Intel Pentium chips from two companies in Orange County, California. (*The New York Times*, 4 Jun 1997)

------------------------------

Date: Tue, 3 Jun 1997 10:37:05 +0200 From: BROWN Nick <Nick.BROWN@coe.fr> Subject: Commands without timeout

We recently installed a new security system for our computer room door. This requires you to type in a 5-digit code to release the lock. Several codes are in use, for software people, telephone technicians, cleaners, etc. The system allows certain codes to be defined as "privileged". If a privileged code is preceded by a press on a button marked "L", the door will thereafter be open for all. If it is preceded by a press on "R", the door will be closed for all except privileged codes.

However, the designers of the circuitry forgot to build in a timeout. If someone presses "L" or "R" inadvertently (perhaps immediately after having typed their code - the buttons are rather small and easy to press by accident), and the next person to enter the room (which might be 60 hours later, on Monday morning) uses a privileged code, the "L" or "R" will be activated. There is a brief flash of an LED when this occurs, but I doubt if anyone other than the service engineer is likely to work out what it means at the time.

We contacted the suppliers of the lock, who to their credit understood and acknowledged the problem and have promised to fix it, but said we were the first to report it. Maybe we're just clumsy, but we've hit the problem six times in as many weeks. Perhaps other customers are locked out and can't get to a phone.

The risks are reasonably obvious: a malicious person could gain untraceable entry by systematically pressing "L" after entering his or her access code, and eventually a privileged user would be the next to turn up; or, someone could accidentally press "R", and after the next (privileged) person entered the room and went on three weeks' vacation, we'd be looking for someone with cutting gear.

Nick Brown, Strasbourg, France

------------------------------

Date: Mon, 02 Jun 1997 11:18:25 -0400 From: kwmcc <kwmcc@ibm.net> Subject: Re: Computer fraud in subscribing ...? (Brazil, RISKS-19.19)

We've had a large number of the automated hangups that Thomas Brazil identified. Dialing *69 didn't work (we'd get an automated message telling us that we couldn't dial back to that number). The operator gave us an interesting theory. Apparently, it's the result of faulty equipment at telemarketers. The telemarketers have equipment which dials numbers and listens for an answering machine. If an answering machine is identified, it hangs up. If a person answers the phone, the call is transferred immediately to an operator (who sees your name appear on their computer screen).

The operator tells us that the equipment used by the telemarketers doesn't do a very good job of identifying people on the phone and they hang up on a lot of people. I suppose it's better for them to hang-up on people (who don't know who they are!) than to waste their operators time talking to machines.

Kevin McCullen

------------------------------

Date: Wed, 04 Jun 1997 15:23:47 -0700 From: Barry Brown <bbrown@sna.com> Subject: Re: newmediagroup.com headers were forged ... (RISKS-19.17-18)

The mention of enterprise.net in RISKS-19.17 and RISKS-19.18 caught my attention as I had recently had an unrelated "problem" with them. One of our customers reported that as of Thursday, May 31, he was unable to bring up a web page from the server at homepages.enterprise.net. At the time, I hadn't caught up on my RISKS reading and didn't know anything about it other than my observation that once my traceroute packets hit the CRL backbone, they were unroutable. We chalked this one up as another CRL/Sprint/BGP mystery since we had implemented dual-homing with BGP only a few days before and routing to enterprise.net through Sprint worked fine.

Along come the RISKS articles saying that enterprise.net was involved in a spam incident. Putting the pieces together, we surmise that CRL is still advertising the route but is denying transit through their network. (We have no proof since CRL made no announcement that such an action would be performed.) By applying such blanket censorship to an entire network, CRL is not allowing legitimate traffic through and by offering no explanation of their actions, they've created confusion among their customers.

As a workaround, we have added an ad-hoc static route to our main router so that traffic destined for enterprise.net gets sent via Sprint.

Barry

------------------------------

Date: Tue, 3 Jun 1997 13:40:32 -0400 From: Mich Kabay <Mich_Kabay@CompuServe.COM> Subject: Re: Florida "Computer Gang" Members Arrested (RISKS-19.20)

Anonymous Harassment on Net Eludes Florida Law

Two Florida men who had been arrested for anonymous harassment on the Internet have now been released. A chief assistant state attorney in Florida explains: "It's simply not criminal under statute in the state of Florida. I'm not condoning this activity. All I'm saying is that I'm left powerless to do anything about it." The two men are 19-year-old former high school students who had used a Web site to allege that a teacher and student at their school were engaging in homosexual relations. The statute cited in the men's arrest prohibits anonymous publication of material that holds a person up to ridicule or contempt; however, the Florida state attorney's office concluded that the statute is an unconstitutional infringement of the right to free speech. (*St. Petersburg Times*, 31 May 1997, Edupage, 1 June 1997)

Edupage is written by John Gehl <gehl@educom.edu> & Suzanne Douglas <douglas@educom.edu>. Voice: 404-371-1853, Fax: 404-371-8057.

------------------------------

Date: Tue, 3 Jun 1997 08:08:26 -0400 (EDT) From: KCKnowlton@aol.com Subject: Uniform password method

Quoted from http://www.twa.com:

"Welcome aboard the TWA ... WebSite! ... you can personalize your experience ... to meet your individual travel needs and interests ... by simply entering your name and a password in the box below and clicking on the Sign in button. (We suggest that you use your E-mail address or some other unique password that is easy to remember)."

Ken Knowlton

------------------------------

Date: Tue, 03 Jun 1997 11:11:10 PDT From: Marnix Arnold <marnix@hplpp4.hpl.hp.com> Subject: Re: Microsoft and Privacy (RISKS-19.20)

In RISKS 19.20, "cooler" mentions the Microsoft sidewalk site (http://www.newyork.sidewalk.com/) as a way for Microsoft to sell "your e-mail address together with any demographic data they might gather about you". The way this gathering is done is a lot less insidious (i.e., invisible to the user) than one might think after reading Mich's article. On the abovementioned page, there is a link called "Customize Sidewalk Now!", but the URL is called "membersurvey", which seems a lot more appropriate. It enables the user to "Get the information that's most interesting to you". After registering of course, thus providing all "Locator information" (see below for MS's definition of this) voluntarily. It's interesting to note that the "Terms and Conditions" are not mentioned or referred to on this registration page...

As for these terms and conditions, somehow the definition of "Locator information" (which MS also allows itself to share with "other parties") was omitted from RISKS 19.20:

"Locator information" consists of a user's name, e-mail address, physical address and/or other data about the user that enables the recipient to personally identify the user. Any user who does not wish to receive any special offers or communications from Microsoft on behalf of suppliers, or directly from Microsoft or its affiliates, may so notify Microsoft at the listed below under SERVICE CONTACT.

So MS can basically do anything they want with your demographic information, unless you just happened to read the Terms and Conditions and told them specifically to leave you alone. That reminds me a bit of mail-spammers offering to remove you from their list if you send them an e-mail. How very considerate of them.

Marnix Arnold (disclaimers...)

[In response to an earlier comment, I had previously inserted the missing text into the archive copy of RISKS-19.20. PGN]

------------------------------

Date: Tue, 3 Jun 97 01:09:27 EDT From: msb@sq.com (Mark Brader) Subject: Re: Time-zone bug in Canadian election

Back in RISKS-18.95, Mich Kabay cited an article that appeared in March in the (Toronto) *Globe and Mail*:

> Officials have decided that the Internet will face the same rules as other > news media when it comes to disseminating public opinion polls within 48 > hours of election day and releasing vote results early on election night.

And in RISKS-19.05, I called it bizarre that they were deciding this only now. The reason turns out to be that there is a new law this year with wider prohibitions on poll results, and that's what was being discussed.

It looks as though it was a mistake to introduce this law in the winter: it contains a daylight saving time bug! The problem is that most of the country observes DST, but not all: in Saskatchewan (well, almost all of it) they keep Central *Standard* Time all year. So when DST is in effect everywhere else, the table in RISKS-19.05 REALLY reads:

Time zone Local time Pacific Time NDT 8:30 4:00 ADT 8:30 4:30 EDT 9:30 6:30 CDT 8:30 6:30 CST 8:30 7:30 MDT 7:30 6:30 PDT 7:00 7:00

and so, when the election was held yesterday, it was the results from Saskatchewan, of all places, that were the last to come. One hopes the government will take the time to debug the law before the *next* election.

(Okay, so it's not a computer bug. But legislation is, after all, a kind of programming too -- it's just executed on rather different hardware. And it's subject to the same kind of requirements of accuracy and precision.)

Mark Brader, msb@sq.com, SoftQuad Inc., Toronto

------------------------------

Date: 1 Jun 1997 11:19:31 -0000 From: "Michael Handler" <handler@sub-rosa.com> Subject: Re: Lost Pond: Jurassic Duck

Actually, it was "The Duck World: Jurassic Pond", which scans slightly better. I mirrored a copy of the hack at <URL:http://www.sub-rosa.com/handler/lost-world-hack/>, for those who missed it.

>* Alan Sutton, Universal Studios vice president for distribution and > marketing, said he thought prank was amusing and done in a spirit of fun. >* Universal plan to improve their security.

Hacking web sites isn't that difficult for anyone with access to the regular bag of cracker's tricks; it's rumored that the CIA web page hack some time back was via poorly checked NFS export options...

It's nice to see a web hack with subtlety and a sense of humor, though. ;)

Michael Handler <handler@sub-rosa.com> * Sub Rosa * Washington, DC

[Also commented on by David Schachter, Lloyd Wood (with an oft-forwarded item from http://netlynews.com), Joe Buck, and Jeffrey Young. Jurassic Duck is the third bogus-hack report in a week, after AT&T WorldNet and the yet-to-awaken LAPD.org. PGN]

------------------------------

Date: Mon, 2 Jun 97 21:53:59 -0400 From: Ray Everett-Church <ray@everett.org> Subject: Re: Senate anti-spam bill (Hoffman, RISKS-19.18)

Lance Hoffman makes some excellent points about the Murkowski bill. In its present form, the Murkowski Bill legitimizes spam as long as it is tagged with the word "Advertisement" on the subject line of the message. The bill also proscribes verifiable e-mail routing and then *requires* that ISPs install filtering systems for their customers or face being sued and fined by the Federal Trade Commission. This approach, while well-intentioned, forces consumers and their internet service providers to do all the hard work -- making ISPs and their customers bear the costs of the spam. This approach has been likened to legalizing burglary while penalizing you for not having the right locks on your doors. This may also explain why the Murkowski bill is vigorously supported by the junk e-mailers.

On the same day Murkowski introduced his bill, Rep. Chris Smith (NJ) introduced a bill that would add e-mail to the existing law restricting junk faxes. The Smith bill gives consumers a private right of action against spam: $500 for *each* of the unsolicited messages they receive. (And if the court believes that the spammer "willfully" or "knowingly" violated the law, the damages are tripled.) The junk fax law has worked extremely well, it has survived many court challenges, and it has cut the junk fax problem off at the knees. The Smith bill doesn't attempt to proscribe technical standards for mail delivery and it places enforcement in the hands of the consumer, not in the hands of any government agency.

Smith's bill incorporates much of the language offered by CAUCE, the Coalition Against Unsolicited Commercial E-mail, an ad hoc volunteer organization of ISP operators, system administrators, mailing list owners, and spam fighters. You can see copies of the Smith bill and his introductory floor statement at <http://www.cauce.org>.

Ray Everett-Church, Esq. <ray@everett.org> www.everett.org/~everett

------------------------------

Date: 3 Jun 1997 09:23:15 -0400 From: rubin@quip.eecs.umich.edu (Aviel Rubin) Subject: More dangers of e-mail to the wrong users

I have seen some messages on this newsgroups of the dangers of e-mail aliases, and I recently had two scary experiences.

I worked at Bellcore last year, and I was used to sending e-mail to users by including only their userid in the mail address. Now I am at AT&T. I sent a long, very sensitive message to one of my co-workers at Bellcore, and out of habit, I only used the userid. Well, it turns out that this id is an alias at AT&T, and my message went to a group of people that should not have seen it. I am currently doing damage control. I quickly imagined how much worse it could have been if certain names were included in that alias.

The other incident was similar. I had aliased Stuart Haber to his new e-mail address, stuart@surety.com. Then, when I got to AT&T, I sent a message to Stuart Stubblebine about a project we were working on. Unfortunately, I had stuart aliased, so the message went to Stuart Haber instead. Fortunately, S. Haber realized that the message was not intended for him, and quickly notified me of this. S. Stubblebine meanwhile, had not received a message, which I had promised him by a certain time. This problem was quickly fixed, but the potential for what errors like this could lead to makes me sweat.

I now make it a habit to grep an alias out of my .mailrc file before I send it mail. (yes, I still use regular Unix mail for the most part) I supposed more modern mailers print out the name of an alias before sending the mail, but that would not have prevented the first problem I had above, where the alias was a system alias, which was used because there was no userid at AT&T for my colleague at Bellcore.

Avi Rubin

------------------------------

Date: 1 Apr 1997 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Abridged info on RISKS (comp.risks)

The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. Or use Bitnet LISTSERV. Alternatively, (via majordomo) DIRECT REQUESTS to <risks-request@csl.sri.com> with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or INFO [for unabridged version of RISKS information] => The INFO file (submissions, default disclaimers, archive sites, .mil/.uk subscribers, copyright policy, PRIVACY digests, etc.) is also obtainable from http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info The full info file will appear now and then in future issues. *** All contributors are assumed to have read the full info file for guidelines. *** => SUBMISSIONS: to risks@CSL.sri.com with meaningful SUBJECT: line. => ARCHIVES are available: ftp://ftp.sri.com/risks or ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks [volume-summary issues are in risks-*.00] [back volumes have their own subdirectories, e.g., "cd 18" for volume 18] or http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. The ftp.sri.com site risks directory also contains the most recent PostScript copy of PGN's comprehensive historical summary of one liners: get illustrative.PS

------------------------------

End of RISKS-FORUM Digest 19.21 ************************