[1259] in RISKS Forum
RISKS DIGEST 18.38
daemon@ATHENA.MIT.EDU (RISKS List Owner)
Mon Aug 26 17:17:20 1996
From: RISKS List Owner <risko@csl.sri.com>
Date: Mon, 26 Aug 96 14:15:08 PDT
To: risks@MIT.EDU
RISKS-LIST: Risks-Forum Digest Monday 26 August 1996 Volume 18 : Issue 38
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:
More on the American Airlines Cali crash (PGN)
DarkStar UAV crash from software change - cost, $39M (David Wheeler)
Electric meter halts mail/news server (Kolja Waschk)
Denial of service attack brings down Netcom listservers (Sidney Markowitz)
DNS failure [from Matthew Dillon] (Steven Weller)
Re: SSN problem hits a Congressman (Craig Neth)
Microsoft's warning (Mike Walsh)
Microsoft's patch (Ed Felten)
Why Java, Bash, Explorer, and other bugs keep hurting us (Fred Cohen)
Too much integration (Nick Brown)
Re: Computer testing of nuclear weapons (Frank C. Ferguson, Jake Donham,
Mike McKinlay)
Year 2000 Bites the Budget (Frank Christensen)
Re: London train crash (Clive D.W. Feather)
Re: "Inability to tinker not confined..." (Tom Zmudzinski)
Once more Murphy's Law (Jim Horning)
Dependable Computing for Critical Applications, Final Call for Papers
(Catherine A. Meadows)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Fri, 23 Aug 1996 15:13:43 PDT
From: "Peter G. Neumann" <neumann@csl.sri.com>
Subject: More on the American Airlines Cali crash
"David L. Oppenheimer" <davido@CS.Princeton.EDU> and
jeisner@unagi.cis.upenn.edu (Jason Eisner) sent me the
identical item, one from the AP and the other from *The
New York Times*, 23 Aug 1996, entitled
Wrong Computer Command Led to Colombia Crash of American Airlines Boeing 757
American Airlines has noted that the pilots of the December 1995 crash of
Flight 965 were lost at the time, and attributed the crash to the captain
entering a computer command that steered the plane in the opposite
direction. Unfortunately, the one-letter code for Cali on the flight chart
they were using was the same as the one-letter for Bogota, and caused the
plane to fly into a mountain, killing 159 of the 163 people aboard. Pilots
have been alerted as to the discrepancies. (Most airline computers use
different codes for the two cities.)
------------------------------
Date: Fri, 23 Aug 1996 12:33:47 -0400
From: wheeler@ida.org (David Wheeler)
Subject: DarkStar UAV crash from software change - cost, $39M
An uncoordinated software change cost $39 million, as reported in
"Inside the Air Force", July 5, 1996, page 10:
"Lockheed Martin and Boeing completed negotiations last week on how to
split the team's share of the $39 million cost of replacing the high-altitude
unmanned aerial vehicle [UAV] which crashed in April near Edwards AFB, CA.
The partners will split equally what could be a $6 million to $12 million
bill from the Pentagon for the destroyed DarkStar, the same proportion
by which it divides the workshare of building the UAVs.
The first flying DarkStar crashed shortly after take off from Edwards
on April 22, resulting in the total loss of the air vehicle, the only
flight test asset available at the time.
Although finger pointing has been assiduously avoided by both companies,
industry and Air Force sources said the crash was the result of Boeing
having adjusted software controlling flight on the UAV without commensurate
changes being made in the system by Lockheed Martin's Skunk Works division.
`The left hand didn't know what the right hand was doing,' a source said.
However, the problem has been addressed and the program should be back on
track shortly, pending the approval by the companies' lawyers of the terms
of splitting the cost for the crash.
A May 16 letter to Rep. John Murtha (D-PA), the ranking minority member
of the House Appropriations national security subcommittee, from Defense
Airbourne Reconnaissance Office chief Maj. Gen. Kenneth Israel tagged the
cost of rapidly configuring another DarkStar UAV for flight and making up
lost time in the program at $39 million."
[reprinted with permission from "Inside Washington Publishers - Defense
Group". Permission Point of Contact: Richard Lardner, U.S. (703) 416-8530]
Related URLs include "http://www.boeing.com/dsg.darkstar.html" and
"http://www.afa.org/magazine/6-6nn96.html".
--- David A. Wheeler dwheeler@ida.org
------------------------------
Date: 24 Aug 96 21:24:23 +0200
From: kawk@yo.com (Kolja Waschk)
Subject: Electric meter halts mail/news server
I run a mail + news server at my home, serving only a few people but to these
the ability to receive and send e-mail is quite important.
Recently I had to leave home for a couple of weeks.
I spent a lot of time before to make the system quite fail safe, especially so
it could handle some tasks that I otherwise do manually. While I was away, it
worked more reliably than at any time before. Until one day. It was not
accessible anymore. I could not even call into a backup PC which was there
just to provide at least the ability to reboot the server system.
Why ? The wheel in the electric meter (a 35 or more years old
electromechanical device) used for counting the power consumed by the system,
somehow stopped rotating. I assume due to a problem in the bearing it was not
able to restart rotating after a simple power blackout (it restarted after
giving it a slap, manually). Well, this meter was designed to limit the
current to whatever it could count. Thus, no rotation, no current.
I understood that I'm responsible for the reliable operation of the PC hard-
and software, and I can rely on the power supplied by my PSC. But I forgot
there was one important device between their output and my system.
Kolja Waschk (kawk@yo.com, NIC-handle KW84) Tel +49-40-8891-3034 BBS/Fax -3035
http://hp00.rz.tu-harburg.de/users/sekw0206 "Yo.COM news & mail service ..."
------------------------------
Date: Fri, 23 Aug 1996 06:01:39 -0700
From: Sidney Markowitz <sidney@research.apple.com>
Subject: Denial of service attack brings down Netcom listservers
A mailing list I subscribe to started sending an endless loop of bounce
messages and another subscriber forwarded the following as explanation. I
have not verified the authenticity of the message with Netcom, but I have no
reason to doubt it. There are two denial of service attacks here: A person
was email bombed by someone who subscribed him to many mailing lists, and
then that person retaliated by bringing down the mailing lists. Once again
we see an old problem that could have been prevented had the system
administrators simply configured known security measures before their system
was hacked.
[begin quoted message]
Newsgroups: netcom.announce
From: nc0022@netcom.com (Margaret)
Subject: Temporary hiatus of mailing lists
Reply-To: support@netcom.com
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
Date: Thu, 22 Aug 1996 03:42:16 GMT
Approved: netmail@netcom.com
Outgoing mail from Netcom mailing lists is temporarily being delayed
due to a mail looping problem, starting at 5:30 PM PDT today.
The problem was caused by a user at another site; someone subscribed
him to many Netcom mailing lists, and he responded by creating an
infinite loop of "bounce messages" to all the list subscribers. List
mail is being queued until we can filter out these error messages.
Netcom is currently in the process of upgrading majordomo, and we hope
to implement improved security for all our lists. In the interim, we
strongly recommend that listowners set their lists to "closed"; this
protects against all mass-subscription attacks.
Delivery of list mail should resume later this evening. Thank you for
your patience.
[end quoted message]
-- Sidney Markowitz <sidney@research.apple.com>
Apple Research Laboratories, Apple Computer, Inc.
------------------------------
Date: Sat, 24 Aug 1996 08:53:31 -0700
From: stevenw@best.com (Steven Weller)
Subject: DNS failure [from Matthew Dillon]
The following describes DNS meltdown at my ISP the other day: all DNS
services were unavailable, despite multiple servers being online. Lack of
DNS assured that other working services were unavailable to everyone who
didn't have IP addresses written down.
Here is a technical explanation of the DNS failure, for those of you
interested.
First, a synopsis of how DNS works... every site on the net serves their
own DNS records. Some sites serve other people's DNS records. For
example, BEST serves the DNS records for best.com, best.net, and most
of our customer's custom domains. No site serves more then a small
fraction of the DNS records on the internet from their own database.
The way DNS works is that when a domain name needs to be resolved, our
DNS server (anyone's DNS server) first goes to the NIC to ask where to
go to resolve the domain name. The NIC itself cannot resolve domains,
it can only tell our DNS server where to go to resolve a domain.
Our DNS server then goes to the specified remote site to resolve the
domain name belonging to that site. The remote site replies with the
answer which our DNS server (a) caches for future reference, and
(b) returns to the original requester.
The caching is important, because otherwise a DNS server would have to
re-query the remote DNS server every time someone wanted to resolve a
domain. DNS records propagate through caches. It is simply not possible
to run a DNS system with caching turned off, it would create an impossible
load on the internet.
Around 4:00 a.m. yesterday, some unknown site's cache got corrupted.
The corruption propagated to many (hundreds) of other sites on the internet
and eventually propagated to us. This corruption hit a bug in the DNS
server program that wound up corrupting the program, causing DNS to
loose major records.
Restarting the server in this case does not solve the problem because,
due to the caching on remote sites, the corrupted record repropagates
almost instantly. BEST was hit by this problem very hard due to the
large number of custom domains we serve... so many DNS requests come into
BEST and are made by BEST that our servers would hit the corruption out
on the internet within 10 seconds of starting up.
Worse, this particular corruption tended to destroy the root records
(stored in memory), called SOA records, for the domains served locally.
This destroyed the mail system causing mail messages to bounce rather then
to simply be delayed, because the DNS server was saying 'site X does
not exist' rather then timing out. It's worst possible corruption that
can occur in a DNS system.
--
It turns out that the last two BIND releases contain a bug that,
when a corrupted record of the type that started propagating at 4:00 a.m.
is received, results in the destruction of other **unassociated**
records stored in memory.
The particular release of BIND that we were using had been running
perfectly for several *months* before this incident. It was not something
recently installed.
There are two fixes to the problem: (1) One can lock out those sites
where the corrupted records come from, and (2) One can revert to an older
release. (1) is not a good solution because, due to the nature of DNS,
corruption can propagate to many sites and it would be impossible to keep
up to date and lock all of them out. We wound up taking action #(2)
and reverting to an older release of bind which, fortunately, did not
have the bug that caused the problem. We had to revert to BIND 4.9.3.
Unfortunately, we did not think to do this for many hours because we were
all convinced that the problem was external in nature and just didn't
think to try a reversion. In hind sight, that is the first thing we
should have tried since we had the friggin binary for the older version
sitting in our source tree.
As far as DNS goes... the DNS we run is not 'bsd' or 'sgi' .. it's the
*official* world-wide BIND distribution run by Paul Vixie. It is really
not appropriate to run the older versions shipped with most operating
systems due to massive, massive security holes. The corruption problem
was unavoidable. What *was* avoidable was the long period of time that
elapsed before the problem got fixed, which I take full responsibility for.
We spent most of that time trying to track down where the corruption was
coming from... a near impossible task. Around 6:00 p.m. scuttlebutt
started propagating regarding a possible bug in the last two BIND releases
at which point we instantly reverted to an earlier version, which fixed
the problem, then started banging our heads against the wall for not trying
it earlier.
Matthew Dillon Engineering, BEST Internet Communications, Inc.
<dillon@best.net>
------------------------------
Date: Mon, 26 Aug 1996 10:42:24 -0400
From: Craig Neth <neth@zk3.dec.com>
Subject: Re: SSN problem hits a Congressman (McCandlish, RISKS-18.37)
Early last week, the Nashua, NH *Telegraph* ran a front page story about
U.S. Congress Bill Zeliff, who is current running for Governor of NH. The
story asserted that the paper had discovered that the Honorable Mr. Zeliff
was registered for two SS numbers. The excerpts I have seen from the
article indicated that the reporters from the newspaper had contacted two
`out of state' database firms that collect information from various sources
and make it available to various parties. The data showed two SSN numbers
for Mr. Zeliff, one that was clearly his and one that looked to have been
created rather more recently.
The next day, the headline was something to the effect that the two numbers
might in fact be a database error, and included quotes from the database
firms saying that errors in these databases were common, and that they are
not responsible for errors - the errors are in the submitting systems, not
theirs. Their was an interesting quote from one of the spokesman, something
to the effect of "The press shouldn't have access to our system". In the
meantime the Mr. Zeliff has asked for apologies, etc.
By the third day the duplicate entry was definitely declared a mistake.
Interestingly, the influential (and decidely Anti-Zeliff) *Union Leader*
newspaper of Manchester, NH. decided to stay out of the fray, running only a
small sidebar on the issue the second day and one or two short editorials,
all of which showed amazing restraint. (The *Union Leader* has an extremely
conservative editorial position and has the widest circulation in the state;
its statewide influence is considered to be *powerful* by most political
observers.) Yesterday's Sunday Edition of the *Union Leader* also included
a discussion of the *risks* of such electronic databases; the article
mentions EFF and other 'privacy' advocates prominently.
As for the damage to Mr. Zeliff's election chances, the results are still
unclear, but seem minimal. His main competitor in the Republican primary
did not make an issue of the problem, choosing instead to continue harping
on a ``fact-finding'' mission Mr. Zeliff made to South America last Winter
(at taxpayers expense, of course).
[I apologize for the sketchiness of this report: I have the newspapers at
home and should be able to substantiate some of the more relevant facts when
I get home this evening.]
Craig Neth Digital Equipment Corporation 110 Spit Brook Road ZKO3-3/Y25
Nashua, NH 03062 neth@zk3.dec.com
[Apparently the *other* SSN belonged to a four-year-old. PGN]
------------------------------
Date: Fri, 23 Aug 96 09:43:00 +0200
From: mike.walsh@pcb.compart.fi (MIKE WALSH)
Subject: Microsoft's warning
Thomas Reardon of Microsoft points out that Internet Explorer 3.0 now
includes a warning of "suspect" software. The Risk here is that this
warning is far too broad. That is you seem to get the warning for almost
everything. Thus the typical user will almost certainly get into the habit
of pressing the Yes button every time - just as he/she already does on all
the idiot "are you sure" prompts. The warning by itself is thus useless.
Another Risk is that the user can't distinguish between Intranet and
Internet usage. If we assume that on the Intranet he is allowed to download
ActiveX modules because they are considered safe there, but now (sorry NOT)
allowed to download ActiveX bits from the Internet, how is he able to tell
them apart. The browser certainly doesn't. Mike Walsh, Pohjola, Finland
------------------------------
Date: Fri, 23 Aug 1996 10:29:33 -0400
From: felten@CS.Princeton.EDU (Ed Felten)
Subject: Microsoft's patch (RISKS-18.36)
We have tested Microsoft's patch and have verified that it fixes the problem
we reported. The patch is available from
http://www.microsoft.com/msdownload/iepatch.htm
------------------------------
Date: Thu, 22 Aug 1996 07:37:07 -0700
From: Fred Cohen <fbcohen@california.sandia.gov>
Subject: Why Java, Bash, Explorer, and other bugs keep hurting us
This is just an editorial opinion from a non-editor of risks. We see
increasing numbers of security holes formed from what would appear to be
minor design or implementation flaws in systems - particularly in the
user-level programs running on those systems. Perhaps the real problem
comes from not using trusted systems. Some examples:
Java allows access to user files:
A trusted system could prevent this regardless of any
flaws in Java. Just provide it with a private area.
Bash error allows character code ff to act as a separator:
A proper trusted system would not allow you to exploit this
to any advantage.
Explorer error lets you overwrite system and other files:
Again a trusted system would eliminate the problem.
Perhaps the real problem we face has to do with the lack of interest by the
community in using technologies that we know about and that are highly
effective in preventing a wide range of threats. Instead of building on the
work of others, people keep on starting from scratch and making the same
mistakes again and again.
Fred Cohen can be reached at tel:510-294-2087 fax:510-294-1225
------------------------------
Date: Thu, 22 Aug 1996 15:49:15 GMT
From: Nick.BROWN@DCT.coe.fr (Nick BROWN) (Tel (+33)88412674)
Subject: Too much integration
For a long time, I've been coming to the conclusion that one of the biggest
RISKS in computing (and, since that's starting to touch every aspect of our
lives, everything else), is an excessive degree of integration. It
increases system complexity (read: bugginess) exponentially for often
negligible benefits.
A couple of items in RISKS-18.36 bring this home:
> before Explorer downloads a dangerous file like a Word document,
Sorry ? A Word document is dangerous ? Ah yes - when you run it, an
auto-start macro buried in the document itself might get DOS to format your
hard disk... Why do the 99% of users who just want to edit a letter have to
risk their entire system integrity for what is basically a gee-whiz feature
?
(Does Word have some way to load documents without executing any auto-start
macros ? Or would that be too complex because users could turn it off and
then forget they'd done it when they _needed_ to run an autostart macro ?)
> Friends of mine have a remote-controlled gas fireplace in their new home.
I tested this statement on several colleagues (all computer people). They
all thought it was either (a) "hugely funny" or (b) "absolutely terrifying".
Typical reactions in the respective categories were
(a) "who's so lazy that they want a real, old-fashioned-style,
back-to-nature log[-effect] fire, but can't be bothered do something
old-fashioned like getting their b*tt [AOL!] out of their chair" [I suppose
it may have been an unrequested feature of the house, put in by the builders
following input from their "marketing" types - NB]
(b) "every electronic system fails at least once every 5 years or so - to
run something as dangerous as burning gas with a 27 MHz [we presume - NB]
$4.99 remote circuit is just insane".
The other day, I was in an electrical store (buying an overvoltage
protector...go figure) and the lady in front of me was trying to find a
replacement remote control for her shutters. These had been stuck in the
down position for two weeks because the remote's cheap push buttons were
sticking. If there was a manual override in the house, she sure didn't know
where it was.
These days, before buying almost anything, I try to work out what its
failure mode is likely to be, how long I can reasonably expect it to (a)
work and (b) be reparable. The results of this calculation for personal
computers is one of several reasons why I don't own one (but that's another
story).
Nick Brown, Strasbourg, France
------------------------------
Date: Sun, 25 Aug 1996 17:40:47 -0400
From: "Frank C. Ferguson" <ferguson@dmapub.dma.org>
Subject: Re: Computer testing of nuclear weapons (Ferguson, RISKS-18.36)
On Sun, 25 Aug 1996, A. Lester Buck III wrote:
> >I suspect we would soon be building weapons that would never work when
> >the real trigger was actually squeezed.
>
> The very first nuclear weapon was designed (and tested!) using teams of
> women operating hand calculators. Funny thing, it worked the first
> time!
The very first atomic bomb was tested (and destroyed) in the desert out
west. The second and third atomic bombs were tested over Hiroshima and
Nagasaki. Even though the first one worked, most of the scientists weren't
sure #2 and #3 would work because they were made differently. One of the
main reasons that a demonstration wasn't conducted for the Japanese was
because our experts weren't sure it would work. Computers are very useful
and should be used as much as possible, however, anyone who thinks that a
computer can reliably substitute for a "real" test is naive.
------------------------------
Date: Mon, 26 Aug 1996 14:03:11 -0700
From: Jake Donham <donham@linex.linex.com>
Subject: Re: Computer testing of nuclear weapons (Ferguson, RISKS-18.36)
>> to use the new computer ... to determine which country wins a war
>> without actually fighting the war.
Perhaps the best fictional treatment of this idea appears in Philip
K. Dick's "The Variable Man". Dick's works (especially his short
stories) contain a wealth of RISKS-relevant ideas.
------------------------------
Date: Fri, 23 Aug 96 08:33:00 PDT
From: Mike McKinlay <MMcKinla@dbq.cycare.com>
Subject: Re: Computer testing of nuclear weapons (RISKS-18.36/37)
[In response to Frank C. Ferguson's response concerning the ancient
Chinese to Jonathan Kamens noting Star Trek's origin of "virtual war"]
"We inwented the ancient Chinese." -- Pavel Chekov
------------------------------
Date: Thu, 22 Aug 1996 10:53:59 -0500
From: Frank Christensen <frankc@aquila.com>
Subject: Year 2000 Bites the Budget
[Frank sent in a long copyrighted Reuters item, 22 Aug 1996, on the Y2K
problem, citing estimated costs to the U.S. Government of $9 to $30
billions, with worldwide fixes costing from $300 to $600 U.S. billion.
The article also noted that Nebraska is imposing a two-cent tax per
pack of cigarettes, to help smoke out the state's reprogramming problem.
Independently, Mark Brader forwarded an item from Malcolm Austin
<maus@ms.com>, who had suggested naming a project aimed at this problem
``Dreadnought'', but he was voted down with those preferring
``Odyssey 2000''. In response, Malcolm noted that the original Odyssey
project (Odysseus's voyage) ended up 20 years behind schedule, and
killed off everyone involved except the lead manager. I like Malcolm's
chosen name, but suppose that a fractured American spelling, DreadNaught,
might be slightly more appropriate. PGN]
------------------------------
Date: Fri, 23 Aug 1996 17:19:12 +0100 (BST)
From: "Clive D.W. Feather" <clive@demon.net>
Subject: Re: London train crash (Poole, RISKS-18.37?)
> The northbound train (with the passengers) was the 17:04 which left on time.
> The preceding northbound train (16:54) was delayed by over 6 minutes which
> meant the southbound (empty) train would have been delayed by at least that
> in crossing over onto the other line.
Not necessarily. The signalman would have all three trains visible on his
panel. If the other train was that late, the signalman could have crossed
the empty train *before* the late train reached the area. This is the sort
of thing they do every day.
Clive D.W. Feather, <clive@demon.net> Associate Director, Demon Internet Ltd.
<cdwf@cityscape.co.uk> Director, CityScape Internet Services Ltd. +441813711138
-----------------------------
Date: Fri, 23 Aug 96 11:35:30 EST
From: "Tom Zmudzinski" <zmudzint@ncr.disa.mil>
Subject: Re: "Inability to tinker not confined..." (Scott, RISKS-18.37)
In RISKS-18.37, Alastair Scott <scotta@logica.com> wrote:
> Who was it who wrote that "any sufficiently advanced technology is
> indistinguishable from magic"? They are right, and they are becoming
> more than right.
Answer: Arthur C. Clarke
And Dr. Stanley Schmidt once wrote, "Any sufficiently advanced magic is
indistinguishable from technology."
Rhetorically, Tom Zmudzinski
[Also noted by Stanton McCandlish <mech@eff.org>. PGN]
------------------------------
Date: Sat, 24 Aug 1996 11:24:32 -0700
From: Jim Horning <jhorning@ix.netcom.com>
Subject: Once more Murphy's Law
This was in my inbox today, concerning an order scheduled for
delivery August 15 (fortunately, I was not in a hurry for it):
> Subject:
> <Firm> order update
> Date:
> Fri, 23 Aug 1996 09:44:46 -0700
> From:
> <<person>@<firm>.com>
> To:
> jhorning@ix.netcom.com
>Dear Mr. Horning:
>Your order has been processed this morning and will be shipped out today,
>via Federal Express second day, and you will receive it Monday, August 26th.
>You will not be charged for shipping. For future reference, your new order
>number is <number>.
>All Federal Express and Airborne Express orders that were processed and
>uploaded to our distributor on Monday, August 12th were subject to a
>technical error which placed them on a hold without anyone's knowledge,
>until we started hearing from our customers.
>Please accept our apologies for this problem, as well as for any
>inconvenience this has caused you. Please let us know if you have any
>questions or comments.
>Best regards,
><Person> <Firm>
[TECHNICAL ERROR? Is that a human error made by a techie? PGN]
------------------------------
Date: Mon, 26 Aug 1996 13:36:07 -0400 (EDT)
From: meadows@itd.nrl.navy.mil (Catherine A. Meadows)
Subject: Dependable Computing for Critical Applications, Final Call for Papers
DCCA-6 Call for Papers
Sixth IFIP International Working Conference on
Dependable Computing for Critical Applications
Can We Rely on Computers?
March 5-7, 1997
Garmisch-Partenkirchen, Germany
Final deadline for original papers is 3 Sep 1996.
Prof. William H. Sanders
University of Illinois Tel: 217 333 0345
CRHC - Coordinated Science Lab Fax: 217 244 3359
1308 West Main Street E-mail: whs@crhc.uiuc.edu
Urbana, Illinois 61801 USA
------------------------------
Date: 15 Aug 1996 (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
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 18.38
************************
