Subject: RISKS DIGEST 18.72

Subject: RISKS DIGEST 18.72

RISKS-LIST: Risks-Forum Digest Monday 30 December 1996 Volume 18 : Issue 72

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:
Ontario legal system going online (J. Kivi Shapiro)
Do Not Attempt to use Airplane as Submarine? (Mark Brader)
Re: Cleaning person inadvertently kills patients (Mark Brader)
The risk of being clueless? ClariNet Site Audit (Mike Stump)
Beware - a new mail virus: PENPAL GREETINGS (Moshe Zviran)
Computer billing brouhaha for data networks (Robert Perillo)
Re: Microsoft documents and Rosetta stones (Henry G. Baker, Peter Bishop)
Re: Arrogance of Micro$loth Products (Robin Sheppard)
More Area Code Problems (Simson L. Garfinkel)
Re: Ghost 911 calls: software upgrade brings police (Michael Fuller,
Peter Campbell Smith, Wayne Hayes, Steve Branam)
Re: Cookies (Marc Salverson)
Abridged info on RISKS (comp.risks)

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

Date: Sun, 29 Dec 1996 18:44:36 -0500 (EST)
From: "J. Kivi Shapiro" <[email protected]>
Subject: Ontario legal system going online

As a cost-saving measure, the justice system of the province of Ontario,
Canada, has created a two-phase plan to file legal documents online rather
than on paper as at present. The first phase covers civil courts; the
second, criminal courts, police and correctional services. Documents to be
submitted electronically in the first phase include various notices and
statements of claim and defense, as well as court decisions.

The usual RISKS of relying on an electronic medium for important documents
apply, with a twist. The proposed plan limits the accessibility of the
documents: under the current system, they are generally accessibly, but
under the proposed plan, the lawyers involved with the case will decide
whether or not to release them. This includes the statements of claim,
explaining why someone is suing, and defense, the response from the person
being sued.

The Canadian Press item I am using as a source quotes prominent Toronto
lawyer Julian Falconer as saying, "a hallmark of a democratic process is the
openness of the adjudicative process.... It is wrong and unseemly to put
litigants and their counsel in the position of being gatekeepers of
information." I am inclined to agree.

Kivi Shapiro

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

Date: Sun, 29 Dec 96 01:08:09 EST
From: [email protected] (Mark Brader)
Subject: Do Not Attempt to use Airplane as Submarine?

I was just reading a Transportation Safety Board of Canada report on a
runway overrun incident in 1995 at Vancouver International Airport. The
airport is on an island just barely above sea level; presumably, then, when
a high pressure cell is in the area, its "pressure altitude" is below sea
level.

>From the report (http://bst-tsb.gc.ca/air/ea95h0015.html):

1.16.7 Take-off Performance Below Sea Level Calculations

During the review of the take-off performance calculations for the
flight, it was noted that the TPS incorrectly calculated the effect of
below-sea-level pressures on engine performance. The manufacturer
confirmed that the engine thrust curves indicated less thrust output
for operations at below-sea-level pressure altitudes; whereas the TPS
program calculated that performance increased as pressure altitude
decreased below sea level.

The CAI DC-10 FCOM and the OD43J Performance Manual also do not
incorporate a performance-reduction correction for operations at
below-sea-level pressure altitudes.

(TPS is the Takeoff Performance System computer, and FCOM is Flight Crew
Operating Manual. CAI is Canadian Airlines International.)

Mark Brader SoftQuad Inc. Toronto

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

Date: Fri, 27 Dec 96 16:26:22 EST
From: [email protected] (Mark Brader)
Subject: Re: Cleaning person inadvertently kills patients (RISKS-18.28, 18.29)

This past summer in Risks-18.28, Michael Crawford reforwarded us an item
beginning as follows:

| "For several months, our nurses have been baffled to find a dead patient in
| the same bed every Friday morning" a spokeswoman for the Pelonomi Hospital
| (Free State, South Africa) told reporters.

Michael didn't know if it was true, but he thought it sounded plausible. In
the following issue, Prabhakar Ragde and Geoff Kuenning suggested that it
sounded more like an urban legend, though a citation was given for its
appearance in the Cape Times, a respected South African paper.

The following Web page:

<http://www.legends.org.za/arthur/cleanfaq.htm>

debunks the story thoroughly. It is indeed merely an urban legend.

Basically, it was circulating as a local rumor, and someone decided that it
had better be investigated, since rumors are, after all, *sometimes* based
on truth. The fact of the investigation then led to the story reaching the
press and the Internet, and along the way the fact that it was *only* an
investigation was lost.

Arthur Goldstuck, author of the Web page, provides not only successive
versions of the story in Afrikaans and English, but also discussion with the
newspaper staff involved. Recommended reading if you like that sort of
thing.

Mark Brader SoftQuad Inc., Toronto [email protected] ["Oh, especially if it's
accurate. There's nothing worse than *accurate*, ill-informed,
irresponsible press speculation." -- Lynn & Jay: "Yes, Prime Minister"]

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

Date: 27 Dec 1996 09:53:16 -0800
From: Mike Stump <[email protected]>
Subject: The risk of being clueless: ClariNet Site Audit

A friend forwarded this... It was sent to his system's `news' account... I
think there are many risks. One is that you have a support staff that
doesn't know why it would be bad, and sends him your site's root password
via e-mail. Another is that this makes for a great spam scam for dishonest
hackers... Another is that even if they are legitimate, it is a risk having
passwords to many machines on the Internet in one location (prime target for
dishonest hackers). I am sure I missed many risks as well. Oh, yeah, the
risk on Clarinet having such an idea, and having them think it is a good
idea.

------- Start of forwarded message -------
Date: Tue, 24 Dec 1996 14:50:44 -0800 (PST)
>From: Alex Ramos <[email protected]>
Subject: ClariNet Site Audit - Response Requested - Please Read

Dear Administrator:

You are listed in my records as ClariNet's technical contact at your site.
Our supplier contracts, the need for copyright protection and other
obligations require us to audit all sites and obtain confirmation of feed
data for our records on a periodic basis.

We have developed a two-step plan for implementing this audit, and we need
your help to make this plan work.

As a first step, I have sent you a questionnaire to complete and e-mail back
to me. This should not take more than a couple of minutes, as it is simply
a listing of your newsserver information and data about sites to which you
feed the e.News.

The second part will involve remotely checking your news-server from our
site, thus we will need a login account and password.

Login account name:
Password:

[ ... ]

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

Date: Tue, 24 Dec 1996 15:41:13 +0200 (IST)
From: Moshe Zviran <[email protected]>
Subject: Beware - a new mail virus: PENPAL GREETINGS

>Forwarded virus warning!!!!!!!!!
>
>If anyone receives mail entitled: PENPAL GREETINGS! please delete it
>WITHOUT reading it. Below is a little explanation of the message, and
>what it would do to your PC if you were to read the message.
>
>This is a warning for all internet users - there is a dangerous virus
>propagating across the internet through an e-mail message entitled "PENPAL
>GREETINGS!". DO NOT DOWNLOAD ANY MESSAGE ENTITLED "PENPAL GREETINGS!"
>
>This message appears to be a friendly letter asking you if you are
>interested in a penpal, but by the time you read this letter, it is too
>late. The"trojan horse" virus will have already infected the boot sector
>of your hard drive, destroying all of the data present. It is a
>self-replicating virus, and once the message is read, it will AUTOMATICALLY
>forward itself to anyone who's e-mail address is present in YOUR mailbox!
>
>This virus will DESTROY your hard drive, and holds the potential to
>DESTROY the hard drive of anyone whose mail is in your in box, and who's
>mail is in their in box, and so on. If this virus remains unchecked, it
>has the potential to do a great deal of DAMAGE to computer networks
>worldwide!!!!
>
>Please, delete the message entitled "PENPAL GREETINGS!" as soon as you see it!
>And pass this message along to all of your friends and relatives, and the
>other readers of the newsgroups and mailing lists which you are on, so
>that they are not hurt by this dangerous virus!!!!

Moshe Zviran, Faculty of Management, The Leon Racanati School of Business
Administration, Tel Aviv University, Tel Aviv 69978 ISRAEL +972-3-6409671

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

Date: Mon, 30 Dec 96 10:29 EST
From: [email protected]
Subject: Computer billing brouhaha for data networks

Many organizations have switched from Private Data Networks to Carrier based
data communications services, such as the AT&T frame-relay service. To take
advantage of the benefits of not buying, managing, and maintaining their own
systems. Yet the automated billings for these services have had many
errors. In a July user group meeting, user's talked of three years of bills
with constant errors, and of monthly bills being off by as much as $1,000 to
$2,000.

Originally, AT&T stated that the bills were correct, and the problem was
that users were being fed inaccurate network loading and performance
data. Users were using this incorrect data to track and double check the
bills. In July, AT&T Corp. confirmed that flawed software in the StrataCom
IPX network switches have provided users with inaccurate performance
data. The software in the StrataCom (now acquired by Cisco) switches, that
supports the Customer Network Management Services (CNMS), was said to have
bugs and flawed algorithms.

AT&T sent a letter during the summer to all user's alerting them of the
problem and warned them not to calculate usage, performance, or capacity
using this corrupted data. AT&T stated that they became aware of the
problems with the switch software in early 1996, and that they would be
fixing the problem with either corrective software or by upgrading to
StrataCom BPX switches by the end of 1996.

AT&T then admitted that their own billing process, an automated billing
system in its new frame-relay network, was creating "billing blunders". AT&T
blamed human error, and system integration problems. It seems that salesman
were unable to enter contracted discounts into the automated system, and
that facilities unrelated to the company's frame-relay service were being
included by the automated billing system essentially double billing.

Some user's stated that "the scary part is that these software anomalies
somehow slipped through testing by StrataCom and AT&T, that shows that their
system is not foolproof, and that is more of a concern then the corrupted
data". Also, "If bills are incorrect, the service is perceived by users as
being less trustworthy".

I have noticed that Performance Monitoring (PM) software is usually left
to late in the development process, staffed by the less experienced or less
productive engineers of the development team. Yet PM software can be tricky
to develop, because you are trying to devise algorithms to measure a system
that is still undergoing development and not completely defined. Also, it is
very difficult to specify performance, how you measure it, and to not
degrade performance by measuring it. It is difficult to test, because of the
varying conditions and loads.

It is reasonable that the designers, concerned about the mission critical
portions of the system, would concentrate their scarce resources in those
area's. When I have brought these concerns up in team meetings, I have been
told by project managers that we must focus on getting the system working
first and that we can worry about meeting PM requirements "sometime down the
road".

This attitude seems to create the Risks mentioned above, PM software
should not be the stepchild of the development effort. Because the first
version of the PM software is usually incomplete and has bugs, it does not
show complete system performance correctly. There have been projects that I
have been on which have been out in the field for years, when we finally get
the PM software working, we notice that the system has never been performing
properly. Properly functioning PM systems can uncover flaws in the mission
critical portions of the software and system.

REFERENCES

ComputerWorld, "Bug causes AT&T switch itch", 8-Jul-96, page 6.

ComputerWorld, "Billing brouhaha bristles AT&T frame-relay users",
15-Jul-96, page 8.

Robert Perillo, CCP Richmond, Va [email protected]

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

Date: Mon, 23 Dec 1996 16:38:55 -0800 (PST)
From: [email protected] (Henry G. Baker)
Subject: Re: Microsoft documents and Rosetta stones (Jewell, RISKS-18.71)

Re: Internet Docs and the RTF spec/M$Word recursion:

I ran into exactly the same recursion, but I took the more drastic/expensive
route of purchasing Mac M$Word 6.0.1c. Although this helped somewhat, it
didn't completely solve the problem.

* Although the Mac/PC versions of M$Word are roughly the same (I think that
the bulk of this product is some kind of interpreted P-code) there are
important differences -- e.g., they don't have the same capabilities to
translate documents & graphics. Thus, if someone posts/e-mails a M$Word
document, you may be able to read the text, but the graphics may remain
untranslated/invisible. Also, the PC versions of the fonts in the documents
prevail, so printing on your Mac takes forever because the generated
postscript includes separate commands _for each individual character
output_! Oh, and BTW, the Mac version is unusable as a word processing
program due to its incredible slowness, so it is _only_ good for translating
documents and printing them.

* You should search a bit further. There are sites with the latest RTF spec
in RTF format. They also have the earlier versions of the RTF spec, so you
can see how it has changed.

* Having RTF won't necessarily help you. Although RTF is supposedly an
'open' format, many of the features are supported only by M$Word, so you'll
_still_ need access to M$Word to read the document. Although there is
supposed to be some level of backward compatibility, M$Word doesn't work
very hard at this, so the documents may still come out looking like a
disaster.

* The posting of documents in a proprietary/trade secret format _by
government agencies at all levels_ should be illegal. Although M$ provides
a free Word reader for the PC, they provide no such reader for the Mac (or
Un*x). The posting of court decisions in the proprietary wordperfect format
is also a major irritant. If people can't easily read the document, then
the agency has not made the document accessible.

* There are a number of 'conversion' programs available that supposedly
handle RTF, Word X.X, Wordperfect, etc., documents. Some of them do a
better job on the graphics than do the M$ converters. However, most seem to
do very poorly on the word-processing parts -- e.g., fonts, section
headings, indentations, etc. So you may have to utilize an ascii editor to
disassemble the RTF into text and graphics, convert each separately, and
then put the mess together again. This is possible for one or two
documents, but not something you want to do on a routine basis.

So far, html 1.0 & .gif appear to be more easily transportable than any
particular word processing format, TeX excepted. Sadly, html is no closer
to having a math capability than 3 years ago -- putting equations in gif's
is not resolution independent!

Postscript is quite transportable, but many PC (l)users don't have
Ghostscript or equivalent to print it on their HP-compatible printers.

PDF (Adobe) is quite transportable and there are good versions for the PC
and the Mac. I commend the IRS for making their forms so readily available
on the Internet in this format.

Henry Baker www/ftp directory: ftp.netcom.com:/pub/hb/hbaker/home.html

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

Date: Tue, 24 Dec 1996 15:32:57 +0000
From: Peter Bishop <[email protected]>
Subject: Re: Microsoft documents and Rosetta stones (Giersig, RISKS-18.70)

This is not a particularly deep comment, but one way of getting portable
documents from Microsoft products is to install a Postscript driver under
Windows. Choose this as the default printer and select the "print to file"
option when printing.

I have used technique to to publish Postscript documents on our Web site.
Anyone with a Postscript viewer (such as the excellent Ghostscript) or a
Postscript printer is then able to view the document regardless of the
computer or operating system they use.

Peter Bishop, Adelard, 3 Coborn Rd, London E3 2DA, England
+44-181-983-0219 [email protected] http://www.adelard.co.uk

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

Date: Tue, 24 Dec 1996 11:45:49 -0700
From: Robin Sheppard <[email protected]>
Subject: Re: Arrogance of Micro$loth Products (RISKS-18.70)

Without defending Microsoft, I would have thought that "the final lesson
learned" should have been to read the manual.

It's easy to blame a software publisher when things go wrong with a program
because of a programming error. Unfortunately, it's just as easy to blame
the publisher when things go wrong through user ignorance. An increasing
number of "risks" reported here seem to fall into the category of "I was
driving my car at 120 mph when I hit a patch of ice and slammed into a tree,
and it's all Ford's fault."

By all means, criticize the publisher when there is an error in a
program; but accept personal responsibility for user errors.

Robin Sheppard

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

Date: Tue, 24 Dec 1996 13:38:42 -0800
From: "Simson L. Garfinkel" <[email protected]>
Subject: More Area Code Problems (Re: Kay, RISKS-18.71)

I read Timothy L. Kay's problem with his paging software calling the
police. One of the real problems, I think, is that we don't really have a
national consensus about phone numbers, area codes, and country codes:

* Is my phone number 555-1212, 617-555-1212, or 1-617-555-1212?
* Should the phone system allow me to dial 1-617-555-1212 if I
am in area code 617?

I'm having this problem in spades right now in a cross-country trip that
I'm taking. Some cell phone areas that I drive through require that you
dial 1-617-555-1212. Others insist that you dial 617-555-1212. You can
imagine that this means that my stored phone numbers don't work half the
time, depending on which zone I'm in.

Frankly, I think that the ambiguity over area codes and the "1" is an
industry disgrace and its sure to cause billions of dollars in lost
productivity and lost time over the coming years. But I don't see any way
to resolve the problems. When I speak with phone companies about this
matter---I ask them "why don't you let people always dial 1+area code even
when you are in the area code"---they don't even have a clue what I'm
talking about.

I have an OP-ED piece that I wrote on a similar subject --- area code
splits -- and I will post it if there is interest.

-simson

Follow Simson's ramblings at http://www.packet.com/garfinkel

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

Date: Tue, 24 Dec 1996 12:24:42 +1100
From: Michael Fuller <[email protected]>
Subject: Re: Ghost 911 calls: software upgrade brings police (Kay, RISKS-18.71)

Timothy has fallen into the trap of being US-centric. "911" is the
emergency services telephone number in the US. But in Australia, "911"
doesn't mean a thing - our equivalent is "000". "911" would simply be the
first three digits of a normal local telephone number! [AUSTEL policy may
preclude this, but not as far as I can see. For reference, see
http://www.austel.gov.au/info/numbering/]

Other countries use other things - a quick search of the New Zealand Telecom
WWW site revealed that they use "111". I'm sure that there numerous other
variants. Now, unless modem manufacturers want to supply an appropriately
tailored setup for every country in the world (and they'd better make sure
they get it right!), then it's ridiculous for them to consider about
building in such checks.

Note that if "911" *was* the appropriate emergency services contact number,
to block modem calls to it would eliminate potential systems that might be
designed to watch over the elderly or infirm, and automatically contact
emergency services when appropriate, security systems that might do the
same, and so on.

So, no, it would not make sense to include a "911" sanity check; to do so is
arguably a RISK in its own right.

Michael Fuller

[I was thinking more of a context-sensitive parameter-programmable
advisory rather than a complete blockage. I should have been much more
explicit. However, the theme of Timothy Kay's US-centricism was noted by
quite a few others, including
Sebastian Delmont <[email protected]>
(in Venezuela, 91 is an area code).
Terje Mathisen <[email protected]>
(in Norway, 911xxxxx is a mobile-phone number,
although 900MHz GSM phones will never work in the US anyway!)
Tim Kuehn <[email protected]>
(in Canada, one must dial 1 even within an area code!)
Also,
"Andrew Marc Greene" <[email protected]> noted that in the 617 area-code
in Massachusetts, some intra-617 calls require a preceding 1. Etc.
The moral lesson is a familiar one in RISKS: Easy answers are risky.
Complex solutions are also risky. On the other hand, even moderate
solutions are risky, as your immoderate moderator repeatedly points out.
So, join the RISKS club. By the way, any automatic censorship technique
is likely to run afoul of similar difficulties! PGN]

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

Date: Tue, 24 Dec 1996 13:45:42 -0000
From: "Campbell Smith Peter (Exchange)" <[email protected]>
Subject: Re: Ghost 911 calls: software upgrade brings police (Kay, RISKS-18.71)

[... 112 spreading for emergencies ... 911 is prefix for a London university]

* Phone numbers change so quickly these days that any assumptions built into
software are likely to be invalid in a few years.

* Some address book applications use modems to dial telephone numbers for
voice calls. No doubt there's one out there with an 'emergency' button, and
I wouldn't be too happy to discover that the modem had suppressed the number
as my house burnt down around me.

Peter Campbell Smith, Logica, London, UK
[email protected] - phone:+44 171 446 4496 - fax:+44 1932 869107

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

Date: Tue, 24 Dec 1996 11:21:05 -0500
From: Wayne Hayes <[email protected]>
Subject: Re: Ghost 911 calls: software upgrade brings police (Kay, RISKS-18.71)

I'm sitting in front of my computer and have a heart attack. I can't get to
the phone in the other room, so with my last ounce of strength I fire up my
modem software and type "atdt911". When my house-mate arrives later that
day to discover my dead body and

atdt911

ERROR

on my screen, a law suit against the modem manufacturer would almost
certainly ensue. One could even envision some sort of automatic system that
might require a modem to dial 911.

If there's one thing your post shows, it's that adding needless complexity
to a software system (a.k.a. making the software "smarter") often adds
confusion and can lead to Really Bad Things.

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

Date: Mon, 30 Dec 1996 13:34:01 -0500
From: Steve Branam <[email protected]>
Subject: Re: Ghost 911 calls: software upgrade brings police

Two years ago I had a similar incident. I had received a set of operating
system upgrade disks for a home system, primarily intended to correct some
problems in some of the items bundled with it. The upgrade went smoothly and
shortly after I attempted to dial up my online service provider. I heard the
modem dialing, but rather than the full dialing sequence, a person quickly
came on the line and said, "Emergency 911." Yikes! The modem continued
sending digits for a second while I sat there totally confused. The
emergency operator did not wait very long before hanging up.

I then waited for a return call or the police to show up. Neither
occurred. Meanwhile, I checked my comm setup. Where before I had disabled
"9" for outside line access, it was now enabled. In addition, the prefix
"1174" (or some similar meaningless code beginning with "11") was specified
to disable call waiting. Thus the setup specified the full prefix "91174"
before the actual number; the switching system cut me over to the 911
operator as soon as the second 1 was sent.

Prior to the upgrade, I had been able to dial in with no problems. Since I
had not changed the setup, I concluded that the upgrade had; most likely it
had overwritten or updated a configuration file, since the communications
software was part of the system bundle. I sent e-mail to the system tech
support folks notifying them of this, and they later responded with
something along the lines of "that couldn't happen". Yeah, right.

I pondered the reason why the operator had hung up so quickly and there was
no confirmation from emergency service personnel regarding the call. While
it is possible that our local 911 system was not capable of supplying
calling number identification at the time, I would still expect the operator
to try harder to get a voice response from the caller. The only thing I
could come up with was that she had heard the modem continue to send digit
tones in fast sequence and figured it was a bad fax or modem setup
accidentally placing the call (for all I know, 911 operators have to deal
with this problem every day, considering the proliferation of automatic
dialing equipment and the nifty interactions between PBX and public system
feature escape codes). Still, that's one place where a little knowledge can
be dangerous. It could just as easily been someone in the throes of heart
attack or panic banging on the numbers after having managed to dial 911. On
the other hand, maybe they were so used to dealing with prank or misdialed
calls that they didn't bother if there was no immediate response.

Steve Branam Hub Products Engineering 508-486-6043
[email protected] Digital Equipment Corporation DTN 226-6043

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

Date: Tue, 24 Dec 1996 10:53:48 -0600
From: Marc Salverson <[email protected]>
Subject: Re: Cookies (Stuart, RISKS-18.68)

Is the setting "2" or "not 1 or 0"? What about the RISK of Netscape adding
option 2 = "don't accept cookies from strangers & send password file", or
any other option you might not want to choose by default but already have
chosen by setting the option to "2"?

Marc Salverson <[email protected]>, Network Analyst, Advanced Research Center (ARC)

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

Date: 15 Aug 1996 (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. Or use Bitnet LISTSERV. Alternatively,
(via majordomo) DIRECT 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]
=> 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 [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
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.72
************************