precedence: bulk
Subject: Risks Digest 20.52

RISKS-LIST: Risks-Forum Digest  Thursday 5 August 1999  Volume 20 : Issue 52

  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. *****
This issue is archived at <URL:http://catless.ncl.ac.uk/Risks/20.52.html>
and at ftp.sri.com/risks/ .

 Contents:
Can You Trust AT&T Wireless PCS Text Messaging? (Lauren Weinstein)
EverQuest devours players' lives (Mich Kabay)
Microsoft Word footnote problems irks federal appeals court (Declan McCullagh)
Perceived medical risk must often substitute for actual risk (John Doyle)
Open-source anesthesia software article in Salon (Martin Minow)
Re: IMRSS and Open Mail Relay Scanning (Lauren Weinstein)
Re: Japanese toilets (Chiaki Ishikawa, Brian Randell, Colin Sutton)
Risks of RISKS (Brian T. Schellenberger)
eBay's response to the eBay scam (Ray Randolph)
Re: Go FORTH and Multiply (Leo Wong)
Re: Heat wave (David Wittenberg)
Abridged info on RISKS (comp.risks)

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

Date: Wed, 04 Aug 99 19:47:17 PDT
From: Lauren Weinstein <[email protected]>
Subject: Can You Trust AT&T Wireless PCS Text Messaging?

Greetings.  Can you trust that messages sent via AT&T Wireless PCS Text
Messaging will always be reliably processed and received?  Unfortunately,
the answer appears to be no.  What's worse, when failures do occur, there
may be absolutely no indication to the sender of the message that their
communication has vanished into the ether.  An an example of a serious risk
associated with a more general class of modern, widely-used communications
systems, I believe that this is worthy of a detailed explanation and
significant concern.

The use of text paging directly to digital/PCS cellular phones is rapidly
replacing the use of conventional numeric and text pagers.  Such phone-based
text messaging, actually called "SMS" (Short Messaging Service) has a number
of advantages over older paging systems.  One of its biggest benefits is
that the network will normally store messages for some extended period of
time (e.g. 72 hours) for delivery to the phone, if the target phone is off
or out of range.  When the phone again is available, the message is
delivered, and the network receives confirmation that the message was
successfully delivered to the phone.  SMS messages typically can range
between 110 and 150 characters or so, depending on how they are submitted
and various formatting considerations.

The usefulness of SMS has caused an explosion in its use for all manner of
free and pay information and warning systems, where automated systems will
send messages (usually via an Internet e-mail interface provided by the
wireless carriers) to users.  Such messages could be anything from critical
status messages for system support or medical personnel, to news bulletins
and stock price warnings to traders.

But how useful is the entire environment if you cannot depend on messages
ever actually being delivered, and if messages can vanish into
a "black hole" without any warning?

AT&T Wireless (ATTWS) has, as you might expect, one of the most extensive
SMS implementations.  They provide three interfaces to the service:

* a web-based "form" interface: type in your message and hit send

* a direct dialup interface for specialized text paging software's use

* an Internet e-mail interface: messages are sent to
  <cellular-number>@<a specific AT&T site>

The Internet e-mail interface is by far the simplest method to use both for
Internet-connected individuals and automated systems.  Unfortunately, it is
also this interface that apparently has the most problems.  Since phones are
addressed via their mobile number without any additional access codes being
required, anyone who knows a cellular number can "flood" a phone with
messages, eating up a user's entire monthly message allocation in short
order--there's no way for the phone user to control such access.  There are
also some "denial of service" issues associated with this same lack of
access control.

But of even greater concern is the fact that text messages submitted to
ATTWS via their e-mail interface, at least for delivery to phones in the Los
Angeles area (I don't have info about other areas at this time--it might
well be a nationwide issue) can frequently simply "vanish" after delivery to
the ATTWS e-mail gateway.  Such "vanished" messages are never delivered to
the phone user, nor is any indication of a problem ever received by the
original sender of the message.

When this problem was originally brought to my attention recently, I was
initially a bit skeptical, but testing indicated that it is indeed the case.
While messages submitted via the web or paging software dialup interfaces
were reliably delivered to phones, it was not difficult to find instances of
messages submitted to ATTWS via their Internet e-mail interface which had
simply gone poof!  Interestingly, these seemed to all occur in the weekend
period (Friday night through Sunday morning), at least in my testing.  In
all cases, Internet mail delivery logs showed conclusively that the messages
in question had been accepted successfully by the ATTWS SMS e-mail server
(which is actually labeled as an "airdata.com" server).  But the messages
were never delivered to the target phones.

My initial contacts with ATTWS customer service about this were not
inspiring.  While the front line folks tried to be helpful, they have very
limited information to work with (this is unfortunately typical of ATTWS
customer service in many respects--many seemingly simple questions may
receive answers ranging from correct to totally wrong from different
representatives).

In this case, one rep told me that they had "heard" that the web interface
was better to use and more reliable, and that he'd heard about paging system
problems on weekends.  He suggested that perhaps they take the system down
for testing on weekends.  This of course, even if true, would not be an
acceptable explanation for the permanent disappearance of potentially
important text messages!

Eventually I found my way to an ATTWS manager, with whom I am in continuing
contact.  While he initially didn't seem to understand the issue--at one
point asking me if I'd ever missed an old-style regular page and pointing
out that ATTWS service doesn't cover all areas (neither of which are at all
relevant to the store-and-forward SMS environment and the problems at hand),
he did ultimately appreciate both the issue and concerns.

He promised to try track this down with the technical folks, and I am still
hopeful of a response, but as of this time, I have yet to receive an
explanation.

Since then, additional testing has revealed more vanished messages following
the same pattern, including as recently as this past weekend.  I've also
received reports from other persons regarding related AT&T Wireless PCS text
messaging problems using interfaces other than the Internet e-mail
interface, but I've concentrated on the e-mail facet in this report since
that's where my own testing revealed lost messages.

So, the moral of this story is actually pretty simple--it can be very risky
to simply *assume* that messages sent through the ATTWS PCS Text Paging
Internet e-mail gateway are actually being delivered to user phones, even if
the messages are accepted by the ATTWS e-mail gateway itself.  This should
be kept in mind if you're expecting to receive important information or
other messages via such a method.  The end-to-end, store-and-forward
sophistication of SMS should be able to avoid the whole concept of
permanently "missed pages" in the conventional sense over reasonable periods
of time.  Unfortunately, it appears that with ATTWS, at least at present in
some areas, this simply isn't the case.

I'll of course report back when more information about this
matter is available.

Lauren Weinstein, Moderator, PRIVACY Forum, http://www.vortex.com; "Vortex
Daily Reality Report & Unreality Trivia Quiz" http://www.vortex.com/reality

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

Date: Fri, 30 Jul 1999 00:12:25 -0400
From: Mich Kabay <[email protected]>
Subject: EverQuest devours players' lives

Hunter Godfrey is quoted as saying that EverQuest "is the digital version of
crack."  He has spent over 656 hours on the game in about four months, the
equivalent of 82 8-hour days.  There are over 150,000 players ``hunting
monsters, collecting loot, and forging alliances in MUD world.'  [Source:
Noah Shachtman, EverQuest: the Latest Addiction, Wired Digital, 29 Jul 1999;
PGN-ed]

 [Watch out for network congestion on corporate systems when this
 infiltrates workplace networks.  M.E. Kabay, PhD, CISSP / Director of
 Education R&D Group / ICSA Labs <http://www.icsa.net>]

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

Date: Wed, 04 Aug 1999 14:40:40 -0700
From: Declan McCullagh <[email protected]>
Subject: Microsoft Word footnote problems irks federal appeals court

The U.S. 7th Circuit Court of Appeals is peeved at Microsoft. Seems as
though unlike WordPerfect, MS Word doesn't count properly footnotes, and
lawyers doing wordcounts have been running over length limits on briefs.
Naughty, naughty, say the judges, who kvetch: that MS "ought to make it
possible to obtain a count of words in footnotes attached to selected
text." The august three-judge panel has forwarded a copy of its design
recommendations to Redmond. More info in a Wired News story (4 Aug 1999):
http://www.wired.com/news/news/politics/story/21096.html

-Declan

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

Date: Sat, 31 Jul 1999 10:16:59 PDT
From: "John Doyle" <[email protected]>
Subject: Perceived medical risk must often substitute for actual risk

All human activities entail risk.  Indeed, to live is to take risks.

In the medical realm, patients who undergo anesthesia and surgery are
frequently concerned about the risks involved, such as the risk of *not
waking up*  (or as one patient put it, *waking up dead*).

The risk of death or brain damage to patients undergoing general anesthesia
is remarkably low, particularly for healthy patients in modern hospitals.
When an accident does occur, its cause is often an error made by the
anesthesiologist, either in triggering the accident sequence, or failing to
take timely corrective action. The overall risk of death for general
anesthesia in all comers is in the range of 1 in 10,000, the exact estimate
depending on how one separates anesthesia misadventures (such as airway
problems) from surgical misadventures (such as accidentally avulsing an
artery).

Risks for individuals with specific conditions are sometimes known, but
usually not. For example, administering general anesthesia when a patient
still has residual food in his stomach poses special risks since the food
sometimes ends up in the lungs (known as aspiration), with consequences
ranging from trivial to deadly. However, risk data specific to any patient
in this situation are not yet available. For instance, factors such as the
"state of the anesthesiologist", characterized in terms of alertness,
vigilance, and competence, would also be important.

(Of course, anesthesiologists employ a few good tricks to reduce aspiration
risk. One trick that is not generally used would be to suck out all the food
under visual guidance using a gastroscope. However, this procedure in itself
introduces new risks and is at best unpleasant in the awake patient.)

Some individuals are surprised to learn that in a great many situations
(indeed, in most complicated clinical situations) the risks of anesthesia or
surgery may not be even approximately known (as in known to within an order
of magnitude). No algorithm yet exists that one can use to get quantitative
risk estimates for all situations. An example illustrates the point.

Recently I was asked to give an anesthetic for a man with several serious
heart problems, the most pressing being a chaotic heart rhythm known as
atrial fibrillation, which the heart doctors planned to fix with a big
electric shock to the chest under general anesthesia (cardioversion). Once
atrial fibrillation has started, it must be fixed within 48 hours or it will
be necessary to start anticoagulant therapy (administration of *blood
thinners*) to reduce the risk of a stroke. We had about 30 hours left.

Because of concerns about harming the patient with a general anesthetic I
initially recommended against the cardioversion (electric shock) procedure,
viewing drug therapy to be a clearly safer alternative. The trouble with
drug therapy, however, is that it is far less effective and in addition
requires a much longer hospital stay. In other words, cardioversion was by
far the quickest and more cost-effective choice, although drug therapy
appeared to be the safer choice.

But the final twist that lead us to go for the cardioversion was that the
cardiologist pointed out that if drug therapy turned out to ineffective in
this individual by the end of the 48 hour window, the option of subsequent
cardioversion could not again be exercised until 4 weeks of anticoagulant
therapy had passed. The risks (such as the risk of bleeding) and costs
associated with that option now made cardioversion seem more attractive.

The unique nature of this particular patient's problem list meant that any
risk estimates from the literature would almost certainly be meaningless. It
was therefore necessary to rely on judgement drawn from experience rather
than formal risk data. Perceived risk must substitute for actual risk in
many settings.

D. John Doyle MD PhD FRCPC, University of Toronto and Toronto General Hospital
[email protected]  http://doyle.ibme.utoronto.ca

APPENDIX
The proposed drug therapy was intravenous amiodarone. Medical conditions
included: recent myocardial infarct with impaired ventricular function,
aortic stenosis, atrial fibrillation, gastroesophageal reflux (a *full
stomach* equivalent situation.) The patient was also known to be very
difficult to intubate because of a small chin!  Finally, note that
moderately reliable mortality estimates for multi-organ failure patients in
Intensive Care Units can be obtained by using the APACHE II algorithm; this
is one of the few situations where good risk data exist for complicated
patients.

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

Date: Thu, 5 Aug 1999 07:57:03 -0700
From: "Minow, Martin" <[email protected]>
Subject: Open-source anesthesia software article in Salon

Risks readers may be interested in an article by Andrew Leonard in the
online magazine, Salon, on the risks (and potential advantages) of
open-source medical software:

<http://www.salonmagazine.com/tech/feature/1999/08/05/anesthesia/index.html>

"When he isn't in the operating room taking care of patients, [Dr. Stefan]
Harms is hacking on the five computers in his basement. And he thinks he
knows how to achieve his dream of low-cost, reliable anesthesia software --
by going the open-source </tech/special/opensource/> route. Last year, Harms
founded LAMDI, <http://gasnet.med.yale.edu/lamdi/> the Linux Anesthesia
Modular Device Interface. Harms thinks that the open-source software
development model, in which the source code to a program is made freely
available to the general public for redistribution and modification, offers
fruitful possibilities for addressing anesthesiological software needs.  ...

"The obstacles faced by Harms in his quest for open-source anesthesia
software suggest that there are some serious potential limits for the
open-source software model. The experience of some medical programmers who
have placed their code in the public domain indicates that open source is
certainly no panacea for the problems faced by medical practitioners. But
there are still some intriguing possibilities. If liability issues can be
addressed, and if the peer-review component embedded in open-source software
can be proven to result in pragmatically better software, then, suggest some
open-source enthusiasts, wouldn't it be our duty to proceed down the
open-source road?"

(Transcribed by Martin Minow, [email protected], with apologies for any
residual Windows formatting cleverness)

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

Date: Mon, 2 Aug 99 19:16 PDT
From: [email protected] (Lauren Weinstein)
Subject: Re: IMRSS and Open Mail Relay Scanning (Roessler, RISKS-20.51)

In RISKS-20.51, concerns were raised over http://www.imrss.org,
their ongoing automated search for open mail relays, and the publicly
accessible query database of the resulting data which they maintain.  It was
suggested that such a database might actually help spammers find potential
relay targets.

I was also concerned about this, and sent them e-mail asking for
clarification on a number of related issues.  After several attempts (they
have various automated responders I had to deal with) I was quickly rewarded
with a phone call from Ron Guilmette, who runs IMRSS.  We had a long and
friendly chat.

While my own orientation towards fighting SPAM is different than his, and I
do not agree with various aspects of his operation, I think it's worth
noting that he seems quite level-headed and sincere, and clearly has a lot
of experience in the real world of SPAM problems.

Also, they are apparently about to address one of the more serious
criticisms of their procedures, by beginning a program to attempt to send
notification messages to "postmaster" and/or related addresses (when these
exist!) for sites where open relays are found.  This will at least provide
such sites with an early warning that they were found to have an open mail
relay, and that they were added to the IMRSS database.

Lauren Weinstein, Moderator, PRIVACY Forum http://www.vortex.com
Member, ACM Committee on Computers and Public Policy

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

Date: Fri, 6 Aug 1999 01:33:43 +0900 (JST)
From: Chiaki Ishikawa <[email protected]>
Subject: Re: Japanese toilets (Landwehr, RISKS-20.51)

Well the joy and risk of high-tech toilet!

It must have been quite an amusing and hilarious way to really wake up to
hear the interview on NPR (National Public Radio?).  And many seem to think
that the Japanese is too serious a nation without the proper sense of
humour, but I digress.

The case, eh, the toilet in question was an 18 years old toilet that caused
a minor fire in April this year (1999).  The cause seems to be a trouble in
electrical wiring due to leaking water.

Trying web search engines with "toilet fire" in Japanese didn't turn out
useful pages at all.  Below is what I gleaned from an article at Mainichi
Shimbun newspaper site (in Japanese).

By the way, fires believed to be caused by similar toilets were reported in
October last year (1998), and July 1993.

The fire in April this year was believed to have happened in the the
following manner.  The plastic vinyl water pipe (for supplying heated water,
I think) degraded and water began seeping.  The water caused the temperature
sensor to get rusty. The rust caused the electrical resistance of some
electrical contacts to go up much higher than it was supposed to be and thus
the excessive heat was generated.  Finally, the vinyl coating of the
electrical wires caught fire.

The family members had noticed the little water seepage about half a year
earlier, but did nothing since the basic functions of the toilet such as
heater, etc.  were still operational.

Many such toilets, of which life time the manufacturers say is about 7
years, are believed to be used in Japan.  The fire fighting department of
Tokyo government was quoted as saying that such toilets that outlived the
warranty period ought to be checked early.  (I could not find reference to
the toilet at the fire-fighting dept. web site, though.)

In Japan, these type of toilets showed up in the market early 1980's.
Today, about third of such toilets are this type according to a survey
mentioned in the article.

Personally, it was shocking and amusing to find the toilets of this type
when my office moved to a new building about 10 years ago.  Being a
gadget-interested person as I am, I tweaked the "control" myself. The
reported toilets that have seat raise control must be the "Rolls Royce" of
this type of toilets.  The one at the office doesn't have such a luxury so
to speak. Frankly speaking, I doubt if such toilets do exist: we need
hydraulic piston or something for that, don't we? In a toilet?

Anyway, even the Mainichi article had to have a cute headline talking about
this subject: it goes something like "Many fires by toilet: it smells and
your bottom is on fire!"

Oh well. It was a good thing that the interview was not aired on April
first. Nobody would have taken it seriously in USA.

Risks? We probably should not put electrical circuits unless absolutely
necessary. Toilets are not thought of as the cause of fire at least by many.
Of course, run-away faulty microprocessor or whatever will get you in a real
trouble such as minor burn!

Ishikawa, Chiaki        [email protected]
Personal Media Corp., Shinagawa, Tokyo, Japan 142-0051

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

Date: Tue, 03 Aug 1999 11:13:04 +0100
From: [email protected] (Brian Randell)
Subject: Re: Japanese toilets (Landwehr, RISKS-20.51)

> ... Some of these have recently been implicated as a source of fires ...

I was pleased to get the above explanation of at least some of the
electronic controls on these toilets. Such controls are, not surprisingly a
feature in the advanced research laboratory that I've visited regularly in
Japan these last few years - one that I made a point of photographing for my
unbelieving colleagues back here in the UK.

I had hinted to my hosts that I would appreciate English language
instructions or even a manual, so as to understand the multiple buttons,
keyboards, and digital displays (including of dates and times) - but neither
were forthcoming. However, they did accept the possible validity of my
concern that these toilets might well not be Y2K compatible - and we had
some interesting speculations as to the likely forms and seriousness of the
possible consequences! :-)

Brian Randell, Dept. of Computing Science, Univ. of Newcastle, Newcastle
upon Tyne, NE1 7RU, UK  [email protected]   +44 191 222 7923

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

Date: Tue, 3 Aug 1999 22:16:27 +1000
From: "Colin Sutton" <[email protected]>
Subject: Re: Japanese toilets (Landwehr, RISKS-20.51)

My wife and I went into a department store in Tokyo and she visited the
toilet. When she came out she was soaked and she couldn't stop laughing.
After she'd used the toilet (and used it well) she went to flush it and
discovered a row of pushbuttons with Kanji labels. Not wanting to leave the
toilet in an unsuitable state for the next user, and not reading Kanji, she
stood back as far as she could from the toilet and pressed one of the
buttons. Hot air started to blow up from the bowl. She tried the next
button, and got sprayed with water. Luckily it was winter and she was
wearing a raincoat. The other buttons didn't seem to do much at all, perhaps
adjust the temperature of the toilet seat or something. None of them caused
the toilet to flush. So she gave up, turned to the washbowl (in the cubicle
with the toilet, as they often are in Japan). When she turned the tap on,
the toilet flushed.

A good design. And the Japanese are so fond of cute icons. It's a pity no
one thought about the illiterate.

Colin Sutton, Development Manager, Siemens Building Technologies Pty. Ltd.
14-18 Suakin Street, Pymble NSW 2073 Australia  +61 2 98551310

 [What about the ill-litter-rate?  PGN]

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

Date: Wed, 4 Aug 1999 10:57:03 -0400 (EDT)
From: "Brian T. Schellenberger" <[email protected]>
Subject: Risks of RISKS

A few miscellaneous risks from recent risks issues:

1. Risk of not explicitly stating the risk.

  Marshall Lindsay wrote of the "Conversion service for viewable
  formats." Our Esteemed Moderator wrote: "But, security by obscurity
  does not work too well for strange formats."

  This suggests to me that perhaps the risk that Mr.  Lindsay was
  referring to wasn't sufficiently clear.  The risk is not that formats
  are decoded; but rather, that the people supplying the conversion
  service could readily make a copy of every document passing through
  their translation service.  Sooner or later they are likely to
  acquire plenty of interesting information!

2. Risk of promoting silver bullets.

  M. Simon wrote a couple of articles; one teaser and one sort-of real
  article, promoting the FORTH programming language.

  First of all, the "teaser" article should *never* have been printed
  in RISKS.  It contained no actual information; it was just a
  shameless plug for something that wasn't even named.

  Second, as I hope all RISKS readers know, there is no "silver bullet"
  to the programming challenges facing us, and this article certainly
  promotes FORTH as just that.

  Third, I've used FORTH, and it is a lovely little language, but I
  think that it's a particularly poor candidate for such a silver
  bullet if one were to exist at all.

  First of all, by its very nature it does not support static error
  checking.  It completely lacks the concept of a "type" which renders
  its ability to do even run-time error checking very limited.  It is
  great for small projects and for controlling real-world objects.
  (Controlling telescopes, for example; the application for which was
  originally designed.) I cannot even begin to imagine managing a large
  (hundreds of programmers) project with it, and I do not believe that
  a project that takes hundreds of C or Java programmers could be done
  with a mere dozen FORTH programmers, either.  (Though a project that
  takes a half-dozen C programmers may very well be doable by a single
  FORTH programmer, and FORTH is underutilized, it's not a language
  which scales up to enormous projects well, IMHO.)

3. Risk of waiting for risks to be proven.

  Bob Frankston wrote of "Fear in the the skies" and stated that "The
  real risk of this nonsense is in relieving the airlines for
  responsibility for safety" and Our Esteemed Moderator observed that
  lots of e-mail had been received, "most of it suggesting that there
  is still little hard evidence of bad effects."

  All this is true, and yet when we weigh even slight evidence of risk
  and the airlines responsibility for the safety of its passengers
  against the rather minute convenience that a cellular phone offers on
  a plane; and when we consider the social risks of allowing the
  passengers to determine which safety rules they will follow and which
  they will ignore when the well-being of their fellow passengers is at
  stake; I do not believe that the decision in this case was
  outrageous.

BRIAN TOD SCHELLENBERGER [email protected]

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

Date: Mon, 2 Aug 1999 12:47:25 -0600
From: "Randolph, Ray" <[email protected]>
Subject: eBay's response to the eBay scam

The most astonishing part of the information provided in RISKS-20.51
regarding the eBay scam was the response from eBay found on the web site we
were pointed to (http://mars.superlink.net/jason/ebay/ ).  eBay's response,
"PLEASE, do not give out details of this, as it will only cause more users
to try it."  Is classic security through obscurity.  In this case, with all
of the media attention this is getting, certain eBay employees are no doubt
lamenting the Risks of the media discovering what they've attempted to
obscure. :)

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

Date: Tue, 3 Aug 1999 08:54:00 -0400
From: "Wong, Leo" <[email protected]>
Subject: Re: Go FORTH and Multiply (Kane, RISKS-20.51)

> You mean:
>        * Forth Go

One reason that Forth is simple is that it reads from left to right:

Go Forth AND *

Leo Wong [email protected]  http://www.albany.net/~hello/

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

Date: Tue, 3 Aug 1999 08:57:13 -0400 (EDT)
From: David Wittenberg <[email protected]>
Subject: Re: Heat wave (RISKS-20.51)

>  athena% weather bos
>  Conditions at KBOS on 7/6/99 at 7:56 PM EDT (18:56 GMT)

Note also the unusual time conversion.  7:56 PM EDT is 19:56 EDT,
which is 23:56 GMT, not the 18:56 they reported.  Or is there an EDT
other than (American) Eastern Daylight Time, presumably somewhere in
England?

--David Wittenberg                [email protected]

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

Date: 23 Sep 1998 (LAST-MODIFIED)
From: [email protected]
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.  Alternatively, via majordomo,
SEND DIRECT E-MAIL REQUESTS to <[email protected]> with one-line,
  SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or
  INFO     [for unabridged version of RISKS information]
.MIL users should contact <[email protected]> (Dennis Rears).
.UK users should contact <[email protected]>.
=> The INFO file (submissions, default disclaimers, archive sites,
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 [email protected] 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 19" for volume 19]
or http://catless.ncl.ac.uk/Risks/VL.IS.html      [i.e., VoLume, ISsue].
PostScript copy of PGN's comprehensive historical summary of one liners:
  illustrative.PS at ftp.sri.com/risks .

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

End of RISKS-FORUM Digest 20.52
************************

You are viewing proxied material from gopher.quux.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.