|
Risks Digest 16.56
NOTICE: TO ALL CONCERNED Certain text files and messages contained on this site deal with activities and devices which would be in violation of various Federal, State, and local laws if actually carried out or constructed. The webmasters of this site do not advocate the breaking of any law. Our text files and message bases are for informational purposes only. We recommend that you contact your local law enforcement officials before undertaking any project based upon any information obtained from this or any other web site. We do not guarantee that any of the information contained on this system is correct, workable, or factual. We are not responsible for, nor do we assume any liability for, damages resulting from the use of any information on this site.
RISKS-LIST: RISKS-FORUM Digest Monday 14 November 1994 Volume 16 : Issue 56
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
***** See last item for information on RISKS (comp.risks), disclaimers *****
Contents:
Catalogin' (Henry Cate)
Worker cleared of deleted planning files (Vinc Duran)
"Netsafe makes the Internet safe for K-12 schools" (Forman)
Alberta vote-by-phone fiasco (Mich Kabay)
Rob Slade's review of Robert Slade's book (Rob Slade)
Re: EMI and construction cranes (Michael P. Hartley, Arthur Byrnes)
Re: Ottawa Library fines people ... (Peter Kaiser, Sean Donelan)
Re: Postscript FAX Security Hole (Andrew Klossner, Brooks Benson,
Ross Oliver, Kevin S. McCurley, Ed Taft, Barry Margolin)
Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.
----------------------------------------------------------------------
Date: [Whenever]
From: [email protected] (Henry Cate) [culled by PGN]
Subject: Catalogin'
``It's not clear whether Morris Feline Stuart is a Democat, a Fat Cat or a
Republicat -- or even a fan of Ross Purr-O -- but Morris is now a registered
voter in Cuyahoga County.'' Normalee Stuart of Shaker Heights, Ohio, says
that she registered her cat to prove there are few, if any, safeguards
against voter fraud in the county. She got the idea when a a neighbor had
told her of receiving a voter registration card addressed to a woman who had
been dead for 12 years. Ohio law does not require people -- or cats -- to
identify themselves when registering to vote. In fact, state law doesn't
require identification from people when voting and allows mail-in
registration. [Excerpted from a UPI item in the (Cleveland) *Plain Dealer*,
as noted (without date) by Henry Cat(e). Soon cats and dogs will be able to
vote by E-mail. On the Internet, no one knows whether it's reigning cats or
dogs. Normalee, anyway. PGN]
------------------------------
Date: Thu, 10 Nov 1994 18:38:35 -0700 (MST)
From: vincd@ile.com (Vinc Duran)
Subject: Worker cleared of deleted planning files
Worker cleared of deleting planning files
By James Burrus, Camera Staff Writer
Boulder Daily Camera Thursday, November 10, 1994
A former Boulder County Planning Department employee was cleared Tuesday of
charges that she deleted an unknown number of files from county computers.
Charges against Vina Windes were dropped for "insufficient evidence" and
because "information indicates no crime may have been committed," according
to a motion filed Tuesday by the county's district attorney. Windes, 53,
has worked as a secretary in the current planning division of the county
Planning Department for five years.
Graham Billingsley, Boulder County land use director, said charges were
dropped after his department and Windes worked out a deal Monday in which
"she would tell us what she did so we can put together the missing
information. So far she hasn't done that so we don't know" what happened.
But Windes said the files were never erased to begin with. "They just
didn't know where anything was" in the computer system, Windes said. "All I
did was leave. No one else did what I did, so they didn't know where to find
anything on the computer when I was gone." Windes gave two weeks' notice of
her resignation on Sept. 8 and started a new secretarial job Oct. 3. She was
taken away from her new job in handcuffs Oct. 7 by Boulder County sheriff's
officers and charged with computer crime, a felony, and abuse of public
records.
"The whole thing got blown out of proportion because of a lack of
communication," Billingsley said.
"Lack of communication?" Windes said. "There was no communication. All they
had to do was call me and ask. Instead, they sent a sheriff's investigator
to arrest me."
Vinc Duran vincd@ile.com or [email protected]
------------------------------
Date: Wed, 9 Nov 1994 18:30:35 -0800
From: [email protected]
Subject: "Netsafe makes the Internet safe for K-12 schools"
Imagine how often your network could go down with this new service:
"Netsafe(tm) makes the Internet safe for K-12 schools.
Netsafe keeps information away from minds that are not ready for it."
Netsafe consists of a black box that monitors school traffic to the Internet
and when an attempt to access a host with undesirable information is made
(you select what categories to censor, they maintain the list of hosts), it
shuts down all Internet access for 15 minutes and sends an email or beeper
message to the local administration. Netsafe costs $20,000 the first year,
$10,000 in successive years! They manage Netsafe over the Internet itself.
Excerpts from product announcement by Russell Nelson, [email protected]
------------------------------
Date: 14 Nov 94 15:37:33 EST
From: "Mich Kabay [NCSA Sys_Op]" <75300.3232@compuserve.com>
Subject: Alberta vote-by-phone fiasco
The Canadian newspaper, _The Globe and Mail_, reports today (94.11.14) on a
disastrous attempt to tally votes by phone:
Alberta phone voting crashes: Liberal fiasco casts doubt
on future of high-tech balloting in Canada.
By Scott Feschuk, Alberta Bureau.
Calgary -- Alberta Liberal officials will be trying this
morning to determine how the party's weekend leadership
convention degenerated into what they concede was an
outright debacle.
Edmonton MLA [Member of the Legislative Assembly] Grant
Mitchell, 43, was selected to head the opposition party,
but his second-ballot victory was all but overlooked as
the telephone voting system crashed, and many members
were unable to vote or their votes were not recorded.
The author continues with the following key points of interest to RISKS and
NCSA FORUM readers:
o Rural Albertans "found it all but impossible" to vote by phone
during most of the first ballot.
o The Maritime Telegraph and Telephone Co. claimed that "the system
could handle more than 500 calls a minute" but the system crashed when a
mere 11,000 people tried to vote in the 5.5 hours allotted.
o The voting was stopped for 40 minutes in the middle of the process.
o Distribution of the personal identification numbers (PIN) required to
vote was incomplete, prompting complaints from disenfranchised voters.
o Some users were informed by the computer system that their PIN had
already been used to vote.
o Some users reported that it took them over an hour to complete one
vote.
o Many users were informed that their vote had _not_ been counted even
though later analysis suggested it had.
o The sequence of touch-tone buttons required to vote on the second
ballot was _different_ from the sequence used during the first ballot,
resulting in confusion by an "unknown number of participants" whose votes
were therefore lost.
o Liberal Party officials are now "reluctant to pay Maritime tel's
C$100,000 fee [~U$72,000]."
o There were discrepancies in the numbers of people counted in the
votes; at one point, the chief electoral officer reported "that more than
12,500 people had voted in the first ballot...." but he later reported just
over 11,000 votes. However, "...[a]bout 19,000 people paid C$10 to
participate." Calgary MLA Frank Bruseker commented, "You really have to
wonder what happened to those other 8,000 people.... Did they not vote, or
did their votes get lost, or did they try to vote and just get too
frustrated?"
o The problematic balloting has discredited the Liberals' claim to be
an efficient alternative to the current government.
o Bad feeling has worsened between the rivals for the leadership as a
result of claims of unfairness due to the technological breakdown.
o Maritime Tel's system will next "be used again this weekend in
Saskatchewan, where provincial Conservatives will select a new leader."
M.E.Kabay,Ph.D./DirEd/Natl Computer Security Assn (HQ: Carlisle, PA)
------------------------------
Date: Fri, 11 Nov 1994 17:55:07 EST
From: "Rob Slade, VARUG, SecSIG, BCVAXLUG, ComSIG and EdSIG"
<[email protected]>
Subject: Rob Slade's review of Robert Slade's (no relation :-) book
[Rob Slade is one of our most prolific reviewers.
Here we give him a change to review Robert Slade's book. PGN]
BKCVP.RVW
Please note that the following is a completely fair and unbiased review. I
strive at all times to be even-handed in my reviewing. My vested interest
in this work in no way can be said to influence my judgement. I mean, to
say that just because I spent *THREE SOLID YEARS* writing it means I might
have a biased opinion about it is a prejudiced opinion on your part, isn't
it? :-)
%A Robert M. Slade
%C 175 Fifth Avenue, New York, NY 10010
%D 1994
%G 0-387-94311-0 or 3-540-94311-0 in Europe
%I Springer-Verlag
%O U$29.95 800-SPRINGER, fax 201-348-4505
%O in Europe email [email protected], UK [email protected]
%O (and the title was *NOT MY IDEA!*)
%P 480
%T "Robert Slade's Guide to Computer Viruses"
This is the most FANTASTIC virus book EVER WRITTEN! This is the most
FANTASTIC virus book that EVER WILL BE WRITTEN!! The day this book was
released the ENTIRE VIRUS WRITING COMMUNITY committed suicide from
depression over the fact that no one would EVER BE HURT BY A VIRUS AGAIN!
Book stores are advised to have LARGE STOCKS of the book on hand,
prominently displayed, and probably to hire extra staff for the crush of
buyers. Grown men have been known to pull their own liver out when told
that they could not buy the book! (And that was before it was PUBLISHED!)
When we sent the books to reviewers, they typically danced in the streets
for joy for several days. However, we reprint here some of the less
effusive comments:
"Mr. Slade's lists are more interesting than the NYC phone book."
- Dr. Fred Cohen
"Obviously some johnny-come-lately upstart."
- Harold Joseph Highland
"Is this guy some kind of comedian?"
- William Murray
"i think its cute and i like the title but i have a few questions ..."
- sara gordon
"Wonderful! It certainly cured *my* insomnia!"
- Dorothy Denning
"A mantlepiece!"
- Terry Jones
"I only have a hundred new samples that came in this week, and then I'll read
it. Promise."
- Fridrik Skulason
"Should have had more sample code."
- Ralph Burger
""
- John McAfee (forwarded by Aryeh Goretsky)
"Vrooooom, vrooooom!"
- Padgett Peterson
"Too long."
- Ross Greenberg
"Still doesn't reliably detect MtE."
- Vesselin Bontchev
"[A bruised read]"
- PGN
"Should be powered off, cast in a block of concrete and sealed in a
lead-lined room with armed guards -- and even then I have my doubts."
- Eugene H. Spafford
"Where's my baseball bat?"
- Edwin Cleton
"Is this legal?"
- Paul Ferguson
"I don't think this is funny."
- Brad Templeton
"We're the federal government. We don't *do* that."
- James Earl Jones
"Let me diagram that on a Turing machine for you ..."
- Yaron Goland
"A great virus book. No, I meant a great *anti*virus book. No, I meant a
great *virus* book. No ..."
- John Buchanan
"Cool."
- Ray Kaplan
"My title was better than his."
- Cliff Stoll
"I elisted this book, and I have the password. Therefore I am now the author."
- Gene Paris
"We probably shouldn't be publicising stuff like this."
- J. B. Condat
Cecil B. DeMille, Alfred Hitchcock, John Ford, John Houston and Federico
Fellini are working on a co-production of the movie version. Casting is not
yet complete, but rumours indicate that Tom Hanks will play frisk, Arnold
Schwartzenegger will portray Padgett Peterson, and Mark Ludwig will be
Stoned. The part of Vesselin Bontchev will be played by a Cray YMP.
DECUS Canada Communications, Desktop, Education and Security group newsletters
Editor and/or reviewer [email protected], [email protected], Rob Slade at 1:153/733
------------------------------
Date: Thu, 10 Nov 1994 14:01:07 -0500 (CDT)
From: "Michael P. Hartley, \"Dreading the Info SuperTrafficJam\""
<SYS_MPH%[email protected]>
Subject: Re: EMI and construction cranes (Summit, RISKS-16.55)
While not directly related to computer RISKS, I feel a comment on how the
FCC allocates frequencies is apropos here. Back in '91, the parts of the
72Mhz range that formerly were allocated in 40kHz wide ranges for R/C planes
were re-allocated. Now, the R/C frequencies are 10Khz wide, 20Khz apart
with various other devices allocated the frequencies between. These include
pagers and some crane operations, among others. The old, pre-1991
transmitters are still legal to use until sometime around 1998.
An older or poorly tuned R/C transmitter can cause short-ranged problems,
like spurious pager signals or disruption of crane operations. R/C Tx are
very low powered. Their effective range may be as far as 3 miles.
The real RISKS are obvious to the public. In the R/C community, cranes
are notorious for using very 'messy' and over-powered transmitters. A
crane, pager tower, or other source of EMI could cause R/C fliers to lose
control. A 10Kg object, hurtling through the air at over 200 KPH and
spinning a razor- sharp 15" prop at 18000 RPM can cause a lot of damage or
loss of life.
Michael P. Hartley [email protected]
------------------------------
Date: Mon, 14 Nov 94 12:37:48 EST
From: [email protected] (Arthur Byrnes (ATS))
Subject: Microwave oven RFI? (Summit, RISKS-16.55)
"Broadcast towers ... and consumer microwave ovens ... are suspected,
(of causing interference to the radio controls of a crane.)"
Not knowing the Seattle area, but assuming that the "Nearby hill" is
probably several thousand feet away, and maybe several miles away, the quoted
person's (Donovan) comment shows a very poor understanding of the technology
he is working with.
It is outraegous that the blame can be placed on a microwave oven. Maybe,
if the oven were inside the crane, there would be enough leakage to cause
interference, but it is not likely even then. Even a broken oven that would
work with the door open, and pointed toward the crane, wouldn't interfere
with the crane if it was more than several hundred feet away. We know of
course that the "Broadcast Towers" themselves wouldn't affect the crane, but
the transmitters using those towers could. The interesting thing is that in
most cases of isolated RFI (interference affecting only a particula person
or machine), the "Cause" is not the source of the interfering signal, but
the receiver being affected. Poorly designed receivers are a major cause of
headaches to legally operating radio transmitters.
Arthur J. Byrnes (Licensed Radio user Amateur, and Commercial.)
------------------------------
Date: Thu, 10 Nov 94 08:20:27 MET
From: Peter Kaiser <[email protected]>
Subject: Re: Ottawa Library fines people ...
Daniel Smith writes:
> a) Each "ring signal" you hear is synchronized with the actual sounding of
> the bell...
No, it isn't. Our phone has a switch that turns the bell on and off. As
we eventually discovered, a hard bump can switch off the bell; and in a
household with children and animals, the phone is inevitably bumped hard
enough.
Furthermore, it's unplugged at times.
It's obviously risky to assume that because one hears a ring signal, a
phone is actually ringing.
___Pete [email protected] +33 92.95.62.97
------------------------------
Date: Thu, 10 Nov 1994 2:56:08 -0600 (CST)
From: Sean Donelan <[email protected]>
Subject: Re: Ottawa Libary fines people ...
The goals of automated telephone notification are to reduce the postage
costs and to notify people more quickly. For example, alerting you to
overdue books faster so the fines don't get as large.
DRA sells a few of different phone notification systems to libraries.
Ottawa Public Library is one of our customers, but I don't know their
exact setup. However, here is the basic (the specifics may vary depending
on hardware platform) notification method.
1) Dial phone
2) Monitor call progress signals (if we're lucky the library
has a telephone line that returns answer supervision)
3) When telephone line "answered"
speak notification message twice,
otherwise
after a number of failed attempts
send a mailed notice
otherwise
rescheduled call and exit
4) Wait up to 10 seconds for DTMF (touch-tone) key
if DTMF digit "0" pressed
go back to step 3
if other DTMF key pressed
record it in notice response (e.g. "Press 1 to confirm")
otherwise
record no response (rotary dial, answering machine?)
Its not a foolproof system. DTMF talk-off, wrong phone numbers, children
answering the phone can cause the notice to be marked "SENT" (note: I don't
use the word "received.") But it usually gets the job done under a
variety of adverse conditions on low-bid hardware. (Hint, hint, pass
that next tax increase for the library, and maybe they'll be able to
afford a more sophisticated system.)
>Well, I am. I know that it is only two bucks, but the implications that
>arise from misuse or overly trusting such a system are worrisome. What if
>the government started issuing parking tickets or summonses in this manner,
>or banks warning you of surcharges on financial transactions? What if my
>wife answered the phone and the book was "how to handle infidelity in you
>marriage" :) (it wasn't).
Some libraries use postcards to notify people when a copy of "How to
handle infidelity in your marriage" is available. Parking tickets
are presumed valid even if someone rips it off your windshield before
you see it. There are all sorts of risks in all sorts of notification
systems. Nevertheless we accept many risks as normal.
Libraries rarely send notices via certified return receipt requested mail.
The problem of "lost" notifications is something libraries have dealt
with for a long time. The dog ate it. The post office lost it. The
kids hid the overdue notice before the parent gets home. Different
libraries have different policies for handling reports of not receiving
a notice. Generally proof of receipt is not a requirement.
What should be considered a reasonable attempt at notification?
Sean Donelan, Data Research Associates, Inc, St. Louis, MO
Domain: [email protected], Voice: (Work) +1 314-432-1100
------------------------------
Date: Mon, 14 Nov 94 07:08:27 PST
From: [email protected] (Andrew Klossner)
Subject: Re: Postscript FAX Security Hole (Crawford, RISKS-16.55)
A quick description of security for PostScript FAX (as implemented in
various laser printers) follows:
If the ReceivePostScript FAX parameter is false, the printer will
reject any attempt to inject PostScript through the modem. In this
case, it will accept only the FAX format.
If the PostScriptPassword FAX parameter is not the empty string, then
the transmitting printer must supply a password. Receiver challenge
and encryption are used.
The default values of these parameters are true and the empty string,
respectively, so a factory-new printer will accept PostScript without
requiring a password. In this case, any attempt to change system or
device parameters (such as passwords) from within an incoming FAX job
will fail unless the (separate) system password is supplied. Also,
attempts to generate outbound FAXes will fail. If no system password
has been set (as in a factory new printer), then such attempts fail.
I can't find anything in the documentation which gives disk files
better protection from a FAX job than from a local job.
The reference for all this is "PostScript Language Reference Manual
Supplement for Version 2014" by Adobe Systems Incorporated. This is
available, as a PostScript file (naturally), from ftp.adobe.com as
"pub/adobe/DeveloperSupport/TechNotes/PS.Supp.2014.ps". "2014" here
refers to the major revision number of the PostScript interpreter, as
reported by the printer on the page that it prints at power-up.
Similar files are available for versions 2011, 2012, and 2013.
-=- Andrew Klossner ([email protected])
------------------------------
Date: Thu, 10 Nov 94 08:58:48 -0600
From: [email protected] (Brooks Benson)
Subject: Re: Postscript FAX Security Hole
A similar situation may exist with NEXTSTEP's Mail application. NEXTSTEP
uses Display PostScript as it's imaging model. When one selects for display
a piece of email that contains an encapsulated PostScript file attachment,
the PostScript is sent to the window server and executed.
This feature has led several clever hackers to create NeXTmail
PostScript "viri". I have seen several of these, all pranks, none
malicious. One causes a number of spiders to scurry across the
desktop, which must be squashed with a mouse click before allowing
you to regain control of your desktop. Another causes all the window
objects to drop off the bottom of the desktop one at a time, yet
another shakes the entire desktop, giving the impression of an
earthquake.
Although I have personally not seen any destructive email viri, I can't say
that none exist. I'll ask roughly the same question as the original poster.
Was the possibility of malicious use of the PostScript language considered
when determining standards for intelligent PostScript devices??
Brooks Benson Swiss Bank Corporation International Finance Division
[email protected]
------------------------------
Date: Thu, 10 Nov 1994 14:30:51 -0800
From: Ross Oliver <[email protected]>
Subject: Re: Postscript FAX Security Hole
In RISKS-16.55, Mike Crawford write about the risks of remote configuration
of intelligent devices such as his Postscript printer.
One possible solution to this risk is to require a switch to be thrown,
button pushed, jumper changed, or some other physical manipulation of the
actual device before any critical configuration information can be changed.
A physical "lock-out" would provide security when needed, yet still allow the
benefits of remote configuration if desired.
The company I work for manufactures X terminals, and we have incorporated
this type of feature into our terminals. When a special type of keyboard,
called a "secure keyboard" is attached to the terminal, the critical portion
of the terminal's configuration data (stored in non-volatile memory) can be
locked against further changes. The secure keyboard is then removed and
replaced with a standard keyboard.
Ross Oliver [email protected]
------------------------------
Date: Thu, 10 Nov 94 21:14:57 MST
From: [email protected] (Kevin S. McCurley)
Subject: Re: Postscript FAX Security Hole
In RISKS-16.55, Mike Crawford pointed out that accepting postscript to a fax
machine is really accepting a program to be executed. Postscript is a
programming language with operators for renamefile, deletefile, createfile,
and some others that are risky in some situations. Moreover, operators can
be created from other operators, so it is not even sufficient to scan the
postscript stream for the offending sequences before executing them because
they can be built from other strings at runtime.
Many web viewers such as netscape and mosaic can be configured to invoke
external viewers such as ghostscript that are in reality postscript language
interpreters. It is therefore possible for someone to click on a URL inside
a web viewer, and in so doing have changes made to their local file system
that are not apparent to the user, because it caused a postscript file to be
brought back and executed. The default mode (safer) for the recent version
of ghostscript does not execute these operators, but the risk still exists
for other configurations. Postscript is probably also not the worst
offender for this - what if your local web viewer on a UNIX machine
processes Bourne shell scripts locally by feeding them to /bin/sh, or your
DOS viewer executes .bat files by feeding them to command.com? Click here
to reformat your disk ...
It is clearly possible to write internet software that is dangerous to
operate, but the risk can easily be eliminated through proper
configuration and coding. Many of us drive automobiles to work every
day, recognizing that they possess the capability to inflict serious
injury and death if used improperly or if they experience a
catastrophic failure. Will the government someday legislate seatbelts
for web viewers and fax machines because of the risks to uninformed or
careless users?
Kevin McCurley Sandia National Laboratories
------------------------------
Date: Fri, 11 Nov 94 10:25:10 PST
From: [email protected].com (Ed Taft)
Subject: Re: Postscript FAX Security Hole
> Would anyone know whether this has been considered under the postscript FAX
> standard? It seems to me it would be a problem for just regular PS faxes -
> one would just hack it over the phone line from another PS fax machine.
Indeed, this issue was considered at length in the design of PostScript fax.
There are several passwords that control access to both PostScript fax
specifically and to system administrator functions generally (such as
erasing the disk).
The defaults are set up to be relatively permissive. This decision is based
on the reality that many PostScript fax printers will be installed and
operated by unsophisticated users having no system administrator support and
who expect the product to work right out of the box. However, the defaults
are such that system administrator functions can't be executed by a fax job.
This, of course, solves only part of the problem. There is no
protection against a fax job that executes something like:
1000000 {showpage} repeat
More comprehensive facilities for authentication, access control, resource
accounting, etc., await implementation in future versions of PostScript fax
products.
Ed Taft taft@adobe.com
------------------------------
Date: Fri, 11 Nov 94 17:34:38 EST
From: [email protected]
Subject: Re: Postscript FAX Security Hole
Don't you run the same risk when you print any PS file that you download
from the net or receive as email and then send to your printer? Do you
examine every PS file for security holes before you print it? PS FAX just
gets rid of the middleman.
As for changing the printer password, wouldn't they have to know the old
password in order to get into the mode that allows it to be changed? [...]
What's needed is probably a general concept of trust levels associated with
PS document sources. Dangerous commands would only be permitted for
documents that came from a trusted source. When printing PS files, the
user could indicate the trust level (high trust if they generated the file
themselves from an application, low trust if they got it from the net).
For automated processing like PS FAX, it could simply default to low trust,
or perhaps permit passwords to be included (either in the PS code, or
perhaps in the FAX wrapper).
In effect, a PS FAX machine needs to be like a computer with a dialin modem:
you need to be able to define accounts and give them access privileges.
Barry Margolin BBN Internet Services Corp. [email protected]
------------------------------
Date: 20 October 1994 (LAST-MODIFIED)
From: [email protected]
Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.
The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks.
Undigestifiers are available throughout the Internet, but not from RISKS.
SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on
your system, if possible and convenient for you. BITNET folks may use a
LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S.
users on .mil or .gov domains should contact <[email protected]>
(Dennis Rears <[email protected]>). UK subscribers please contact
<Lindsay.Marshall@newcastle.ac.uk>. Local redistribution services are
provided at many other sites as well. Check FIRST with your local system or
netnews wizards. If that does not work, THEN please send requests to
<[email protected]> (which is not automated).
CONTRIBUTIONS: to [email protected], with appropriate, substantive Subject:
line, otherwise they may be ignored. Must be relevant, sound, in good taste,
objective, cogent, coherent, concise, and nonrepetitious. Diversity is
welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS
MESSAGES in responses to them. Contributions will not be ACKed; the load is
too great. **PLEASE** include your name & legitimate Internet FROM: address,
especially from .UUCP and .BITNET folks. Anonymized mail is not accepted.
ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
Relevant contributions may appear in the RISKS section of regular issues
of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.
All other reuses of RISKS material should respect stated copyright notices,
and should cite the sources explicitly; as a courtesy, publications using
RISKS material should obtain permission from the contributors.
ARCHIVES: "ftp crvax.sri.com<CR>login anonymous<CR>YourName<CR> cd risks:<CR>
or cwd risks:<CR>, depending on your particular FTP.
Issue j of volume 16 is in that directory: "get risks-16.j<CR>". For issues
of earlier volumes, "get [.i]risks-i.j<CR>" (where i=1 to 15, j always TWO
digits) for Vol i Issue j. Vol i summaries in j=00, in both main directory
and [.i] subdirectory; "dir" (or "dir [.i]") lists (sub)directory; "bye<CR>"
logs out. CRVAX.SRI.COM = [128.18.30.65]; <CR>=CarriageReturn; FTPs may
differ; UNIX prompts for username, password; [email protected] and
WAIS are alternative repositories. See risks-15.75 for WAIS info.
To search back issues with WAIS, use risks-digest.src.
With Mosaic, use http://www.wais.com/wais-dbs/risks-digest.html.
FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving
it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info
regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL
RISKS COMMUNICATIONS; as a last resort you may try phone PGN at
+1 (415) 859-2375 if you cannot E-mail [email protected] .
------------------------------
End of RISKS-FORUM Digest 16.56
************************
|
|
