Risks Digest 16.77
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.
From nntp.crl.com!howland.reston.ans.net!spool.mu.edu!agate!agateway!csl.sri.com!risks Tue Jan 31 14:18 1995
From: firstname.lastname@example.org (RISKS Forum)
Subject: RISKS DIGEST 16.77
Date: 31 Jan 95 00:46:23 GMT
Organization: The Internet Gateway Service
RISKS-LIST: RISKS-FORUM Digest Monday 30 January 1995 Volume 16 : Issue 77
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, etc. *****
UK Cabinet Secret on National ID Card Found in Surplus Store (Li Gong)
Perils of Call Forwarding (Stephen Thomas, Quentin Fennessy)
Deutsche Telekom offices searched (Mich Kabay)
My life as "email@example.com" (Uucp@aol.com)
Risks of reusing accounts (Charlie Shub)
From the cat file (Andrew Koenig)
Another stamp machine story (John Kriens)
The risks of Risks (Fritz Knabe, Haritini Kanthou)
ACSAC '95 Call for Papers and Participation (Marshall D Abrams)
Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.
Date: Wed, 25 Jan 95 10:02:56 -0800
From: Li Gong <firstname.lastname@example.org>
Subject: UK Cabinet Secret on National ID Card Found in Surplus Store
The Manchester Guardian Weekly (week ending 21 Jan 1995) reported that plans
for the UK national ID card system was found in a government surplus store.
The second-hand file cabinet was sold for about 35 pounds. It contained
memos on investigation into the feasibility of smart-card technology, a
detailed card design, as well as cabinet level letters exchanged on this
topic. Whitehall has confirmed that the files are authentic.
Li GONG Email: email@example.com Tel: 415-859-3232 Fax: 415-859-2844
SRI International, Computer Science Lab, Menlo Park, California 94025, USA
Date: Mon, 30 Jan 1995 09:41:22 -0500
From: firstname.lastname@example.org (Stephen Thomas)
Subject: Perils of Call Forwarding [Plumbing the Depths]
I'm sure many eagle-eyed risks readers spotted this one, but just in case,
here's an item from an AP story in Sunday's Atlanta Constitution.
Stephen A. Thomas, AT&T Tridom, email: email@example.com
From The Atlanta Constitution, Sunday, January 29, 1995, page D7
Did he steal jobs, thanks to call forwarding?
Police say plumber grabbed rivals' calls [Abstracted starkly by PGN]
Michael Lasch, a plumber in Levittown, NY, is accused of calling Bell
Atlantic to order Ultra Call-Forwarding for at least five of his company's
competitors, which enabled him remotely to redirect their calls to his
phone. He was charged with theft by deception, criminal attempt, unlawful
use of a computer, criminal trespass and impersonating an employee. The
scam was detected when a customer complimented another firm on work
performed over Christmas weekend -- when in fact no one had been working!
[The WRENCH that stole Christmas?]
[Also noted by "Whittle, Jerome SMSgt" <JWhittle@amclg.safb.af.mil> and
Quentin Fennessy <Quentin.Fennessy@sematech.org>, from whom I include
the following excerpt. PGN]
Date: Sun, 29 Jan 1995 12:30:47 -0600
From: Quentin Fennessy <Quentin.Fennessy@sematech.org>
Subject: Phone number hijacking with Bell Atlantic ultra-forwarding
[...] There is nothing new about this crime - except the use of a new
medium to hijack a channel of communications. The risks are obvious - as
more such services are available without verification the more this crime
can occur. I suppose that if Lasch were more sophisticated he could have
kept up his scheme for much longer. For example, if the ultra-forwarding
were flexible enough he could enable it for the coldest days, in order to
fill up his queue with work orders for frozen pipes, and then disabling the
forwarding while he completed the jobs.
Date: 27 Jan 95 10:50:59 EST
From: "Mich Kabay [NCSA Sys_Op]" <firstname.lastname@example.org>
Subject: Deutsche Telekom offices searched
From the Reuters newswire (95.01.25 @ 11:36 EST) via CompuServe's Executive
Deutsche Telekom Offices Searched in Fraud Probe, by William Boston
BONN, Jan 25 (Reuter) - Police searched offices of Deutsche
Telekom AG on Tuesday to determine whether staff at the
German state telephone monopoly had withheld proof of
computer hackers tapping into private phone lines to call
foreign sex hotlines.
Juergen Froehlich, chief prosecutor in Cologne, said in a
statement that police went through Telekom offices in Bonn,
Cologne and Duesseldorf as part of an investigation into a
gang of hackers.
The author continues with the following key points:
* Legal authorities are investigating the possibility that D.T. employees
concealed data on stolen phone services.
* Over 2M D.T. clients have complained about fraudulent phone calls charged
to their accounts over the last 30 months.
* D.T. officials deny that its customers paid for any fraudulent calls,
explaining that the criminals placed their calls from accounts obtained
using false names.
M.E.Kabay,Ph.D., Director of Education, NCSA (Carlisle, PA)
Mgmt Consultant, LGS Group Inc. (Montreal, QC)
Date: Sat, 28 Jan 1995 18:45:29 -0500
Subject: My life as "email@example.com"
America Online allows its user accounts to specify up to five "screen
names", which uniquely identify the user. AOL screen names consist of a
capital letter followed by two to nine alphanumerics or spaces. The screen
name is not case-sensitive, so "MR SMITH" and "Mr Smith" refer to the same
account, and the AOL software forces uniqueness on new names by appending
digits to the end of the name.
AOL accounts can also send and receive Internet e-mail. AOL converts its
screen names to Internet-style addresses by dropping all spaces and
appending "@aol.com", so our "Mr Smith" becomes "firstname.lastname@example.org" to the
Which is where I come in. I was trying to come up with a unique screen name
that did not end in randomly assigned digits -- AOL's membership stands at
1.5 million users, each of whom can reserve up to five names, so most common
English words and names are already taken.
Idly searching for a name, I requested "root". (I always put this down as
my first choice when requesting a new account. It never hurts to ask.)
The AOL software politely informed me that this name was taken, and said the
same when I requested "postmaster", "webmaster", etc. In some cases it
suggested an alternative like "webmast236", and in others it simply said
"That name is taken."
Then I requested "uucp".
And the software asked me to enter my new password.
Since then I've been getting a lot of strange e-mail, to put it mildly.
Much of it is private correspondence from external addresses to accounts
on AOL, or vice versa, that has been Cc:'d to uucp. (I don't know why.
Is this happening due to user ignorance or carelessness, or is it the
behavior of the mail software?) In no case so far has the sender
suspected that "email@example.com" is a live human being.
The RISK here is the assumption that "uucp" (or, for that matter, "root")
is a trusted e-mail address on the remote machine. The only required
e-mail address in RFC 822 is "postmaster" -- there is no requirement that
the remote machine use the UUCP transport mechanism, the UNIX operating
system, or that any e-mail address other than "postmaster" route e-mail
to the system administrator. ("Postmaster@aol.com" does route e-mail to
a person responsible for AOL's mail system, in compliance with RFC 822.)
AOL reserves certain screen names to prevent this kind of confusion, but
"uucp" was not one of the reserved names. (Neither was "nuucp", if you
were curious -- I've reserved that one too. I think I can retire both
addresses permanently by deleting the screen names from my account, but
I plan to make certain before doing so.) "Root@aol.com" and "webmaster"
are already in use, but I can't say *who* is using them.
Of course these RISKs apply to any site, not just to AOL -- any site
could have a user account named "uucp" and still be RFC 822 compliant.
But as the net grows, and incorporates more and more diverse machines,
the RISK becomes more dangerous. Don't assume that mail addressed to
"uucp" or "root" on a remote machine is going to a trusted recipient,
because for at least one large site this assumption isn't true.
Scott Forbes MSForbes@aol.com
Date: Wed, 25 Jan 1995 23:47:46 +0700
From: firstname.lastname@example.org (Charlie Shub)
Subject: risks of reusing accounts
Two years ago, i was on sabbatical at a large university, and picked
up some support by teaching a course. Their division of computing
services managed many computing accounts, and had a pretty reasonable
scheme for class accounts. They used a 3 letter followed by 3 digit
account names. The first two letters denoted the department, and the
third letter was a for the first course, b for the second course, etc.
000 was always the instructor's account and 001 was student 1, 002
student 2, etc. A reasonably sane idea. I would guess that at the
end of each semester they cleaned student accounts by deleting all
files and reinserting initialization files. They would then generate
new passwords for all accounts each semester. What is the risk?
accounts may have state data that does not appear in the account or
that is not normally cleansed.
The course i was teaching was on a machine i did not use for my
personal work, so i had set up automatic mail forwarding to my machine
here that I normally read mail on (by telnet from there when i was
there). The between semester cleansing algorithm did not reset that
forwarding address. Finally, the 5th course in the department again
used that same machine, so account cse000 became the instructor's
account. That instructor has apparently given the students a "use
e-mail" assignment, and did not test the system with a self mailing.
Since the forwarding is still in effect, I have been receiving
electronic mail intended for this instructor for the past few days.
I thought of sending him/her email to let him/her know about this,
but realized that such mail would immediately be forwarded to me.
I thought of replying to the students, but if they are just learning
about computers, that would also be fruitless. I thought of logging
into the account to unset the forward, but the new instructor has
obviously changed the password. I suppose I could have chosen to just
wait until some interested party finds this in risks, or watch from
the sideline until confusion reigns. I believe I have identified the
instructor, and have sent her email. A blind copy of this note to
risks is being sent to a friend at that institution who will, no
doubt, follow up with the instructor and keep me (and perhaps risks
readers) posted on how this shakes out.
charlie shub email@example.com -or- cdash@colospgs (BITNET)
(719) 593 3492 (fax) 593-3369
Date: Thu, 26 Jan 95 16:56:42 EST
Subject: From the cat file
This morning I was sitting at my home terminal, reading mail. I got up for
a few minutes. When I returned to the terminal, the screen showed a partial
reply to the last message I had been reading. It looked something like
It didn't take me long to figure out what had happened. This particular
terminal has function keys that can be set to store strings. Once upon a
time I often used a machine named `redbone,' the name of which was therefore
stored in that function key. Sitting on the table, next to the keyboard,
was one of my two big, fluffy cats. She had evidently pressed that function
key and the mailer interpreted the `r' of `redbone' as a request to reply to
the message. After that, she must have spent some time sitting on the `2'
Oh well, at least she didn't try to eat the mouse.
--Andrew Koenig firstname.lastname@example.org
Date: 30 Jan 1995 18:00:26 -0500
From: email@example.com (kriens,john)
Subject: Another stamp machine story
My stamp machine story is similar to that of Jonathan Kamens in RISKS-16.76
in that the machine was programmed to keep the person using the machine from
losing money. It is different in that it let me get into a situation where
I could neither buy the stamps I wanted, nor could it give me my money back.
There is a stamp machine in the basement of one of the buildings in our
corporate campus, we also have a U.S. Post Office in our backyard, but if
you're lazy or in a hurry, it's simpler to use the machine.
Anyway, I wanted to buy a book of stamps (back when they were still a bargain
at $5.80 for the book of 20). I decided to go to the stamp machine. Now, I
had $6.00 with me--a five and a one. There was a sign on the machine saying
that the machine would give back no more than $.50 in change. I took this
sign to mean that I could put in more money if I wanted, but the most change
I could get for overpayment would be $.50.
Anyway, for some reason, I decided that I wanted to get a quarter back, rather
than two dimes. I would put in $6.05, get $5.80 worth of stamps, and get a
quarter back. Most candy vending machines will let you do this, but you have
to put your change in first, before the bills--otherwise they know that you're
overpaying and won't let you put the coins in. I started off with a nickel.
I then put the $1 bill in. So far, so good. I then attempted to put the five
in. The machine just wouldn't accept it. I can't remember what message the
machine gave me, but it was not enlightening. After trying 5-10 times to get
it to take the bill, I reached the conclusion that it just wasn't taking five
dollar bills today (since my bill was in pristine condition). It also wouldn't
let me get back the money I'd already put into the machine. Since I was stuck
with either losing my money or getting change and hoping I would finally get
my stamps, I left the machine and dashed upstairs to our credit union to get
change for the five.
Luckily, there was no line, so I got my five $1 bills and ran back downstairs.
The money was still registered in the machine, so I proceeded to feed my $1
bills in. Everything went fine until I got to the fifth bill--which the machine
refused to take. Once again, the bill was in perfect shape. After trying a
bunch more times, I realized that I would need exact change, so I walked down
to the change machine in one of the break rooms to get the bill broken into
Unfortunately, it took too long to get the coins and I arrived back at the
machine just in time to see it finish telling me I had taken too long and reset
itself, removing all traces of my money from the display.
As you have probably deduced by now, the machine had been programmed to not
allow a person to put more than the next highest dollar amount into the machine
from the purchase price of the stamps. Since all of the denominations of
stamps were between $(X).50 and $(X+1).00 [books of $.29 stamps were $2.90 and
$5.80 and post card stamps were $1.90 or $3.80], the machine assumed that anyone
putting in more than the next dollar would risk losing money--something they
*clearly* would not want to do, since they would lose money. (Never mind that
they would also lose the money they'd put in up to this point since once the
bills go into the machine they don't come back out.) The sign about getting a
maximum of $.50 back was misleading since the machine gave no opportunity to
lose that much.
Luckily the Post Office refunded my money without any hassle, but I still wish
whoever programmed the machine hadn't thought they were being so damn clever.
-John Kriens firstname.lastname@example.org
Date: Mon, 23 Jan 95 17:13:13 +0100
From: Fritz Knabe <Fritz.Knabe@ecrc.de>
Subject: The risks of Risks
As a frequent reader of the RISKS forum, I was very interested when
"Computer-Related Risks" (our esteemed moderator's new book) was reviewed
here. Using the information from the review, I faxed an order to ACM.
Two months later, with no book, I discovered that ACM had debited my credit
card for $34.50, rather than the $22.25 + shipping that I was expecting. It
seemed that not only did I not have the book, the book I didn't have wasn't
even the one I wanted.
I called ACM and discovered that whoever processed my order completely
ignored the title and author information in my fax and went right for the
6-digit order number, which it turns out was incorrect. (Interestingly
enough, the order number identified a book on software quality.) I hadn't
received the wrong book because it was out of stock (I had received no
notification of this, either).
The lessons? Overworked order entry people will enter an order number
and simply ignore the accompanying description, even though the
description is much more likely to be correct. And next time I'll be
sure to check the order number directly with ACM, or leave it off.
Fritz Knabe email@example.com
Date: Wed, 25 Jan 95 12:18:23 EDT
From: Haritini Kanthou <KANTHOU@ACMVM.bitnet>
Subject: The risks of Risks (Fritz Knabe)
Thank you for bringing to our attention the fact that in one of the ads in
CACM, the order number for Peter Neumann's Computer-Related Risks was
incorrectly cited as 706943. The correct number is 704943, at $22.25 plus
shipping for ACM members or $24.75 plus shipping to nonmembers.
[The incorrect number was first found in the original press release
from ACM, and it got propagated to various other places. PGN]
Haritini Kanthou, Member Services Mgr. firstname.lastname@example.org
Date: Fri, 27 Jan 95 23:25:07 EST
From: email@example.com (Marshall D Abrams)
Subject: ACSAC '95 Call for Papers and Participation
CALL FOR PAPERS AND PARTICIPATION
11th Annual Computer Security Applications Conference
December 11-15, 1995
New Orleans, Louisiana
The phenomenal growth of the Internet is threatening our very notion of
privacy and property. Information networks and computers are routinely
processing private, proprietary, sensitive, classified, and critical
information. The Internet has created an addiction to information and
instantaneous information exchange in the military, government, and private
sectors. Computers are making decisions ranging from the mundane to life
threatening. To provide protection to this information, the information
technology community must:
o Develop methodologies and tools for designing systems
capable of protecting the sensitivity and integrity of
information, and assuring that expected services are
available when needed.
o Design safety-critical systems such that their software
and hardware are not hazardous.
o Develop methodologies and tools capable of assuring that
computer systems accorded trust are worthy of that trust.
o Build systems of systems out of components that have
been deemed trustworthy.
o Build applications on evaluated trusted systems without
compromising the inherent trust.
o Include computer security in enterprise modeling and
o Extend computer security technologies to specifically
address the needs of the civil and private sectors.
o Develop international standards for computer security
For the past 10 years the Annual Computer Security Applications Conference
has been helping the IT community meet these challenges by providing a forum
for information exchange that is unsurpassed. The Conference will explore a
broad range of technology applications with security and safety concerns.
Technical papers, panels, vendor presentations, and tutorials that address
the application of computer security and safety technologies in the civil,
defense, and commercial environments are solicited. Selected papers will be
those that present examples of in-place or attempted solutions to these
problems in real applications; lessons learned; and original research,
analyses, and approaches for defining the computer security issues and
problems. Of particular interest are papers that present descriptions of
secure systems in use or under development, presenting general strategy,
methodologies for analyzing the scope and nature of integrated computer
security issues, and potential solutions. Papers will be judged for best
paper awards. A prize will be given for the Outstanding Conference Paper
and the Best Student Paper. For the Best Student Paper, expenses to attend
the conference will also be awarded .
Panels of interest include those that present alternative or controversial
viewpoints or those that encourage lively discussion of relevant issues.
Panels that are simply a collection of unrefereed papers will not be
Vendor presentations of interest should emphasize innovative product
implementations, especially implementations involving the integration of
multiple products. Vendor presentations that simply describe product
features will not be selected.
Areas of Interest:
Security in Enterprise Modeling and Reengineering
Trusted System Architectures and Technology
Encryption Applications (e.g., Digital Signatures)
Certification, Evaluation, and Accreditation
Application of Formal Assurance Methods
Trusted DBMSs, Operating Systems, and NetworksSecurity Policy
and Management Issues
Electronic Document Interchange
Open Systems and Composed Systems
Software Safety Analysis and Design
AIS Security Tools
Instructions for Submissions:
We provide blind refereeing of papers and ask that you put names and
affiliations of authors on a separate cover page only. Substantially
identical papers that have been previously published or are under
consideration for publication elsewhere should not be submitted. Panel
proposals should be a minimum of one page that describes the panel theme and
appropriateness of the panel for this conference, and should identify panel
participants and their respective viewpoints. Send 5 copies of your
completed Papers and Panel proposals to Dr. Gary Smith (papers from Europe
should be sent to Klaus Keus) by May 31, 1995. For panel/forum preparation
instructions, please contact Jody Heaney at (703) 883-5837 or via e-mail at
firstname.lastname@example.org. Send five copies of your vendor presentation
proposal to Steve Rome. Vendor presentation proposals should include an
abstract that describes the product and example applications. Send one copy
of your tutorial proposal to Daniel Faigin. It should consist of one- to
two-paragraph abstract of the tutorial, an initial outline of the material
to be presented, and an indication of the desired tutorial length (full day
or half day). Electronic submission of tutorial proposals is preferred.
Authors will be required to certify prior to June 30, 1995, that all
necessary clearances for public release have been obtained; that the author
or qualified representative will be presented at the conference to deliver
the paper, and that the paper has not been accepted or previously published
elsewhere. Authors will be notified of acceptance by August 1, 1995.
Camera-ready copies are due not later than September 30, 1995.
Instructions to Students:
Student papers must be authored 100% by students; no faculty authors are
permitted. Send 5 copies of student papers to Dr. Gary Smith; please
identify your paper as "Authored by Student." Contact Ravi Sandu, Student
Paper Award Chair, to ensure that your paper is considered for the Best
Student Paper Award. This award includes expenses to allow the student to
travel to the conference and present the paper.
Send your papers to:
Dr. Gary Smith
Technical Program Chair
ARCA Systems, Inc.
8229 Boone Blvd., Suite 610
Vienna, VA 22182
Klaus J. Keus
Bundesamt fuer Sicherheit in der Informationstechnik
Kessenicher Str. 216
53129 Bonn Germany
Send tutorial proposals to:
Tutorial Program Chair
The Aerospace Corporation
P.O. Box 92957, MS M1/055
Los Angeles, CA 90009-2957
For information about Student Paper contact:
Student Paper Award Chair
George Mason University
ISSE Department, Mail Stop 4A4
Fairfax, VA 22030
Send vendor proposals to:
Vendor Track Chair
9800 Savage Rd.
Ft. Meade, MD 20755
Videos Still Available!
Video tapes of the 1989, 1990, 1992, 1993, and 1994
Distinguished Lecturers are still available. The titles and
1994 Donn Parker
"Computer Loss Experience and Predictions"
1993 H. O. Lubbes,
"COMPUSEC, A Personal View"
1992 James P. Anderson,
"Computer Security Myths and Mythtakes"
1990 Dorothy Denning,
"The Data Encryption Standard: Fifteen Years of
1989 Stephen T. Walker,
"INFOSEC: How Far We Have Come! How Far Can We
The price for each tape is $17.00. An additional $5.00 will
be charged for foreign orders for postage. Checks should be
made out to Applied Computer Security Associates (ACSA). Send
check to Dr. Marshall Abrams, 2906 Covington Road, Silver
Spring, MD 20910. Please indicate which tape you are
Some copies of the 1992 and 1994 proceedings can still be
purchased through Ron Ross for $25 each. Contact him at The
Institute for Defense Analyses, 1801 N. Beauregard Street,
Alexandria, VA 22311, (703) 845-6617, e-mail: email@example.com.
For 1991 & 1993 Proceedings, contact the Computer Society
Press by dialing 1-800-CS-BOOKS or (714) 821-8380. The non-
member price is $80, the IEEE member price $40.
To be added to the Annual Computer Security Applications
Conference mailing list to receive future conference
announcements, please send Name, Company, Address,
City/State/Zip, Country, and e-mail address to Vince Reed,
Publicity Co-chair , The MITRE Corporation, 1500 Perimeter
Pkwy., Suite 310 , Huntsville, AL 35806, phone: (205) 830-
2606, fax: (205)830-2608, e-mail: firstname.lastname@example.org
Sponsored by Applied Computer Security Associates in
cooperation with IEEE Computer Society Technical Committee on
Security and Privacy, and ACM Special Interest Group on
Security, Audit and Control.
Marshall D Abrams
telephone 703.883.6938 Information Systems Security Division
secretary 703.883.5900 The MITRE Corporation, M/S Z202
facsimile 703.883-1397 7525 Colshire Drive, Mc Lean, VA 22101-3481
Date: 22 December 1994 (LAST-MODIFIED)
Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.
Risks can be read on the web at URL http://catless.ncl.ac.uk/Risks
Individual issues can be accessed using a URL of the form
(Please report any format errors to Lindsay.Marshall@newcastle.ac.uk)
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@example.com>
(Dennis Rears <firstname.lastname@example.org>). 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@example.com> (which is not yet automated). SUBJECT: SUBSCRIBE
or UNSUBSCRIBE; text line (UN)SUBscribe RISKS [address to which RISKS is sent]
CONTRIBUTIONS: to firstname.lastname@example.org, 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.
CURRENT ARCHIVES: "ftp unix.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; "bye<CR>" I and J are dummy variables here. REMEMBER,
Unix is case sensitive; file names are lower-case only. <CR>=CarriageReturn;
UNIX.SRI.COM = [22.214.171.124]; FTPs may differ; Unix prompts for username,
password; bitftp@pucc.Princeton.EDU and WAIS are alternative repositories.
End of RISKS-FORUM Digest 16.77