precedence: bulk
Subject: RISKS DIGEST 19.26

RISKS-LIST: Risks-Forum Digest  Saturday 26 July 1997  Volume 19 : Issue 26

  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:
Satellite transmission snafu leads to diplomatic incident (Nick Brown)
Ghost account nets $169K embezzlement (PGN)
401(k) off-by-one errors (anonymized)
AOL customer phone-number availability (PGN)
General Mills & AOL in sleazy partnership: Chex Quest CD-ROM game
  (Bruce N. Baker)
Risks of relying on text search (Derek Lee Beatty)
Risks of URL completion (John Pettitt)
Computer jargon enters mainstream, is hit by truck (Mark Durst)
The dangers of Explorer-ation (Roger Barnett)
Win 95 TCP/IP Hole (Alex Klaus)
Re: MD5 weakness and possible consequences (Paul C. Kocher)
Re: Voice-controlled MS WORD (Tai, Christopher Kline)
Re: Medical computer crashes (Jonathan de Boyne Pollard)
Y2K: a different solution (Driss)
Re: DEC Alpha Bug, final resolution (David Chase)
Re: The truth about Usenet's Psychic Spammers! (H.Shrikumar, hymie)
Privacy Digests
Abridged info on RISKS (comp.risks)

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

Date: Fri, 25 Jul 1997 13:56:24 +0200
From: BROWN Nick <[email protected]>
Subject: Satellite transmission snafu leads to diplomatic incident

Early on Sunday morning (19 Jul 1997), a "technical error" caused the
contents of a channel on a satellite operated by France Telecom, to be
transmitted on another channel, for about twenty minutes.  Normally this
would have been merely annoying for the viewers of the affected channel.
However, the viewers were in (among other places) Saudi Arabia, the channel
they expected to be watching was the French government-run, general interest
and news station, Canal France International (CFI), and the programme which
replaced it was... a hard-core pornographic movie which should have been
shown on the subscription-only, encrypted French domestic station, Canal
Plus.

I presume that the incident involved two channels on different satellites,
since CFI is carried on Arabsat and Canal Plus on the European-oriented
Telecom satellite system.  My bet would be that the channel numbers are the
same and the operator was pointing at the wrong satellite while hitting
"Go".

Results: Arabsat has cancelled its contract with France Telecom, claiming
(it would appear with some justification) that France Telecom had not
"honoured its commitment to respect Arabic and Islamic values".  The French
Foreign Ministry and the French Ambassador in Riyadh are trying to calm what
has become a diplomatic incident.

Nick Brown, Strasbourg, France

 [Also noted by Paul Johnson <[email protected]> and
 and Pete Bentley <[email protected]>.  PGN]

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

Date: Fri, 25 Jul 97 10:03:16 PDT
From: "Peter G. Neumann" <[email protected]>
Subject: Ghost account nets $169K embezzlement

While working as a civilian military pay supervisor in the Army finance and
accounting office at Fort Myer from 1994 to 1997, Teasa Hutchins Jr. caused
regular military paychecks to be deposited to a bank account in the name of
a bogus officer, and accumulated $169,000 for himself.  He has pleaded
guilty and faces up to 10 years in prison and a $250,000 fine.
 [Source: An item in *The Washington Post*, during one of my trips there
 this summer -- I forgot to record the date]

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

Date: Fri, 25 Jul 1997 11:10:28 -0400
From: [identity withheld by request]
Subject: 401(k) off-by-one errors

I work for a large U.S. corporation which has a 401(k) plan.  For non-US
readers, a 401(k) is a self-funded retirement plan: you (voluntarily) put
aside part of your salary (pre-tax) and your employer (usually) matches it
in part.  The employee selects how to invest their portion of the money (and
at some companies, how the company's matching funds are invested).

As required by law, we receive quarterly reports on how much money we have
in the 401(k) plan, mailed to our home addresses.  This quarter, about 2/3
of employees received incorrect statements.  It seems that there was an
off-by-one error in matching employees to addresses.  That is, if employee
E1 has address A1, and employee E2 has address A2, etc., the report for E1
was sent to A2, the report for E2 was sent to A3, etc.  The interesting
thing was that the envelope delivered to A2 would have E1's name on the
outside and E1's data on the inside.  So those people who looked at the
envelope before opening would realize that something was amiss.

The hypothesis is that this occurred because an employee record had been
incompletely deleted from the database (and no, I have no idea how that
could happen).  When our payroll department uploaded data to the 401(k)
management company, the data was incorrectly interpreted by the receiving
program.  Nothing in the management company's computer system noticed that
2/3 of the addresses were mismatches with the addresses already on file.
Interestingly, the last address on the list received two reports: one for
the employee who lived at that address, and one for the employee who lived
at the next-to-last address.

The reason this affected "only" 2/3 of the employees is that those
employees whose records were uploaded before the "bad" database
record was encountered were unaffected.

Some employees are quite upset, since other (unauthorized) people saw the
balance in their 401(k) accounts and the amount being contributed.  From
that data, one can infer salary information ... which many people don't want
publicized!

We can see several RISKS here:

* It was possible to modify the database records such that an employee
was "partially" deleted, thus leading to the situation.

* The management company's computer system did not cross-check the
addresses being used for reports against the addresses of record.

* Most people don't look at the address on the mail before they open it!

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

Date: Fri, 25 Jul 97 8:55:42 PDT
From: "Peter G. Neumann" <[email protected]>
Subject: AOL customer phone-number availability

America OnLine recently announced its intention to provide telemarketer
clients with the phone numbers of all AOL customers who have not explicitly
requested that their phone numbers be excluded.  It was reported less widely
that AOL intended to provide some sort of user transactional information as
well.

The AOL customer contract fine print claims that they will not release such
personal information, but even finer print seems to reserve the right to do
so to their business partners.  (But opting out is apparently not easy.)
Nevertheless, presumably due to customer complaints, AOL has backed down
somewhat, and will now use that information only for its own [nefarious?]
activities.

Telemarketing and spamming are already out of control, and some of those
activities are questionable, if not truly unethical, immoral, and in some
cases illegal.  But in any event, they are generally annoying and unwanted
by most people.  The argument that using the transaction information will
permit hustlers to be selective about whom to harass seems specious and
disingenuous, at best.  Please stay alert.

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

Date: Sat, 26 Jul 1997 12:01:59 -0700 (PDT)
From: [email protected] (Bruce N. Baker)
Subject: General Mills & AOL in sleazy partnership: Chex Quest CD-ROM game

My 5 year-old grandson opened up a box of Chex Quest and eagerly placed the
"free" CD-ROM he found inside the box onto my Mac Performa, without any
adult supervision.  This is not unusual because he often plays educational
CD-ROMs.  The box makes it sound like you get the "free" game on the CD-ROM
*plus* 50 free hours of AOL.
 The "install" item on the CD-ROM menu installs not the game but rather,
AOL. The CD only contains a preview of how the game works on, guess what?
--AOL.
 It took me 3 days to un-install AOL and to re-install my regular service
with the help of support people at The Well.
 General Mills and AOL neatly "cover" themselves with the following:
 "By purchasing this product [the cereal], you agree that, with respect to
the CD-ROM game described on this package, (1) any and all disputes, claims
and causes of action shall be resolved individually, without resort to any
form of class action...(2) any and all claims, judgments and awards shall be
limited to actual out-of-pocket costs incurred, and in no event shall
attorneys' fees be recoverable...(4) you agree that your remedy for any
claim, if any, shall be limited to either replacement of the CD-ROM game or
refund of the purchase price of the product, such choice to be at the sole
discretion of General Mills"
 Just what I wanted -- another copy of the same CD-ROM :-(
 The risk?  It looks as if they knew very well what *their* risks were!
How many other "free" CD-ROMs will be included with other types of products?
Bruce N. Baker

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

Date: Thu, 24 Jul 97 23:20:05 -0500
From: Derek Lee Beatty <[email protected]>
Subject: Risks of relying on text search

The old risk of relying on text search instead of carefully reviewing a
document apparently bit the Texas legislature last session, according to an
article ("Inadvertent repeal of law puts city, developers in limbo," p.1) in
the July 24 Austin American-Statesman.  The article focuses on the local
regulatory-political implications and isn't completely clear about how the
mistake actually happened, but apparently SB 932, a 68-page bill intended to
abolish the Department of Commerce and create a new Economic Development
Department, contained a lone unwanted sentence abolishing "Subchapter I in
Chapter 481 of the Government Code."  The effect of the repeal is to make
the law governing land development uncertain.  The paper speculated that "a
liberal mole hacked into the legislative network" although the bill's author
believes he and his staff accidentally repealed the development law.

A government relations spokesman for the builders' association was quoted as
saying that lobbyists check bills by searching for key words, and "In this
case, you'd have to do a word search for 'I.'"

The risk?  A case of relying:
- on text search instead of document review
- on lobbyists to tell the legislators what laws they're making (!)
- on "the computer" as scapegoat

-- Derek Beatty         beatty@{netcom,ibmoto}.com      Austin, TX

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

Date: Sat, 19 Jul 1997 20:08:00 -0700
From: "John Pettitt" <[email protected]>
Subject: Risks of URL completion

Using either Netscape 4 or Microsoft Internet Explorer 4 type "msnbc" in the
address box and hit return, the URL completion will first look for msnbc in
the local domain then try the common domains net, com, edu etc.
Unfortunately msnbc.net exists and looks nothing like msnbc.com ...  in this
case the difference is not harmful.  However it opens the interesting
possibility of .net domain mirrors of say schwab.com or some other financial
site with the associated security implications.

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

Date: Mon, 21 Jul 1997 16:15:23 -0700 (PDT)
From: Mark Durst <[email protected]>
Subject: Computer jargon enters mainstream, is hit by truck

*The New York Times* Cybertimes story "Minor Error Throws Internet Into
Disarray", on 18 July 1997, by the usually savvy John Markoff, contains one
howler:

> Computer experts said the global glitch demonstrated that even a
> single point of vulnerability in the Internet's addressing system
> could hamper the workings of the far-flung computer network.

RISKS cognoscenti understand the term "single point of failure" to
refer to the critical dependency of an entire system on one component,
certainly a cause of last week's fiasco.  The opposite notion is of a
system that can survive failures in any specific piece.

But the text gives a quite different impression with that "even",
suggesting that the opposite notion would be a system with many points
of "vulnerability".

You "computer experts" out there: explain your buzzwords thoroughly,
or RISK having your pronouncements turned inside out!

Mark Durst  San Leandro CA  <[email protected]>

 [Long-time RISKS readers will also recollect many cases in which MULTIPLE
 points of failures were involved.  (For example, see Chapter 4 of my
 Computer-Related Risks.)  Of course, most systems seem to have MANY
 SINGLE-point failure modes, and if those don't get you there are lots of
 MULTIPLE-point failure modes.   PGN]

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

Date: Sat, 19 Jul 1997 15:21:21 +0100
From: Roger Barnett <[email protected]>
Subject: The dangers of Explorer-ation

As a follow on to the other comments on the security of Web browsers, I
noticed recently that several Microsoft products now use their Explorer
browser as their online Help interface.

However, to use this feature it is necessary to enable some, if not all,
of the "riskier" capabilities such as ActiveX and Java support - otherwise
the Help information is inaccessible.

What chances of the user remembering to re-disable these features before
venturing back out onto the big bad Internet ?

Incidentally, I first hit this problem with a Sales CD issued by DEC -
again, the only way to access the data on the CD was via Explorer with
ActiveX and Java applet loading enabled.

Roger Barnett

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

Date: Mon, 21 Jul 1997 22:52:48 -0400 (EDT)
From: [email protected] (Alex Klaus)
Subject: Win 95 TCP/IP Hole

While searching the Microsoft web site for Win95 updates, I came across an
interesting KB article. This deals with a problem with Win95's handling of
Microsoft TCP/IP, according to the article when Win'95 receives an Out of
Bound packet ". . . deliberately sent to the server" a Fatal Exception error
will result(The blue screen of death). " An update available on the web site
will fix the problem. The RISKS, if someone generates an out of bound
packet, whether by accident or design " . . . the computer may not receive
further network data until Windows is restarted."

The full text of the article can be found
at:http://www.microsoft.com/kb/articles/q168/7/47.htm
A link to the patch is also on this page. vtcpupd.exe is the file name

Alex Klaus <[email protected]>

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

Date: Fri, 18 Jul 1997 17:25:00 -0700
From: [email protected] (Paul C. Kocher)
Subject: Re: MD5 weakness and possible consequences (Giles, RISKS-19.24)

> This then becomes a matter of determining an _efficient_ way to set the
> value of the MD5 (or any) hash function to a desired value.

Although collisions must exist in cryptographic hash functions, this
(hopefully) isn't going to be easy.  In general, finding even a single
example of a collision is generally considered proof that the hash function
is broken.  Finding a feasible way to construct messages with a desired hash
would be a much more dramatic result.

Cryptanalysis of hash functions is an interesting and important area which
hasn't been given nearly as much attention as it deserves (though there has
been some excellent work in the area, such as what what Hans Dobbertin has
done attacking MD5 and MD5 -- see
http://www.cryptography.com/papers/hash/dobbertin.txt, for example).  The
consequences of a major hash function break could be quite devastating --
virtually all certificates, digital signatures, and modern cryptographic
protocols rely heavily on the collision resistance of MD5 and/or SHA...

Paul Kocher, President, Cryptography Research, 870 Market St., Suite 1088
San Francisco, CA 94102   415-397-0111 (FAX: -0127)  [email protected]

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

Date: Mon, 21 Jul 1997 10:50:34 -0500 (CDT)
From: test acct <[email protected]>
Subject: Re: Voice-controlled MS WORD (RISKS-19.25)

My cousin tried that on a Mac running 7.6.  It was rather accurate, but
tended to do a shutdown reboot when inspired by certain background noises
[exactly what it is, we have no idea].  However, he took the machine home,
to Hong Kong.  Being rather tight on landspace, HK offices are very
"friendly" and has a rather high ambient noise level when compared with US.
As a result of that, that Mac tried to reboot every few minutes.  Turned it
off finally.  So, I guess, risks would be trying to go overseas/unusual
accents :P

-Tai

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

Date: 24 Jul 1997 11:38:25 -0400
From: Christopher Kline <[email protected]>
Subject: Re: Voice-controlled MS WORD (RISKS-19.25)

  > "It'll make people give up the mouse," says Lernout & Hauspie's
  > chief technology officer.

Don't bet on it. The risks of spoken interfaces are the same as those
of mechanical ones. I recently saw a program on television (around two
months ago; unfortunately I have forgotten the program name) wherein a
company purchased voice interface systems to help stem the rise of
repetitive stress injuries (RSI) that their employees were
experiencing.

The catch? The workers soon began experiencing voice-related RSIs. It seems
that long periods of enunciating short, carefully articulated phrases ("cut
cell"... "down cell"... "over row"... "paste cell") had led to damage to the
employees' vocal cords and supporting anatomy.

I can't wait for the brain cramps that come with neural interfaces...

Christopher Kline <[email protected]>

 [Various other comments also received.  PGN]

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

Date: 22 Jul 97 21:09:04 +0100
From: Jonathan de Boyne Pollard <[email protected]>
Subject: Re: Medical computer crashes (Van Vleck, RISKS-19.25)

Possibly, it was not a PC at all, but a mainframe or timesharing system
terminal, and the nightly backup runs at midnight.  In my experience, some
several years ago, of one such system, the nightly backup ran at the highest
priority.  This meant that all terminals effectively "died" at 00:01, only
to spontaneously come back to life again 5 to 10 minutes later -- the first
couple of times with a sudden rush of all of the queued keystrokes that I
had entered over those 5 to 10 minutes in my puzzlement. (-:

The risk if this is the case?  Almost certainly of using the same system
administration techniques that work well for a daytime-only system
(scheduling the backup to run at night because that's when no-one will be
using the system) on a 24-hour system.

On the other hand, one could argue that a delay in one admissions data entry is
less critical than a delay in the backup of the whole day's transactions, and
so it is proper that the backup run at a high priority at the expense of those
interactive users unlucky enough to be active at the time.

Please remove the '$' in the from line before reply via e-mail.
Anti-UCE filter in operation.

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

Date: Fri, 25 Jul 1997 12:40:52 -0400 (EDT)
From: [email protected]
Subject: Y2K: a different solution

One of the most difficult tasks in dealing with the Y2K problem is finding
the parts of the source code or libraries that are used that are not Y2K
complaint. However, what if you look at the problem from a different
angle. Assuming that most of the software systems can be simplified to say
there is a user or batch system layer that communicates with a database
layer, what if:

1. You transfer all "live" records in the database that involve dates
between 1900-1909 to a new software system.  There should be few enough of
these types of records that the work should be reasonable.  [A live record
is one that is still used. All dead records would be removed from the
database and stored with a big note.]

2. You set all of the dates of data in the database back 10 years

3. You introduce a new layer in the software model. Add a program that
intercepts calls that normally go directly to the database that would
increase the date of data that is leaving the database (on requests or
queries) and decrease the date of data that is entering the database.

This would allow the user interface layer to only require an aesthetic
change (displaying 20xx instead of 19xx), allow for more time to develop a
more complete, revised system (allowing for better amortization on the
development of such software that is most likely already in progress),
reduce the cost and difficulty leave of a Y2K "solution" and be easier to
track problems with as it will retain the integrity of the database and user
interface layers.

This could be seen as being a perpetual solution as the number of people,
particularly in insurance databases, however that would require two separate
systems to be running, which would not be cost effective in the long run.

Driss

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

Date: Wed, 23 Jul 1997 07:02:37 -0400
From: David Chase <[email protected]>
Subject: Re: DEC Alpha Bug, final resolution (March, RISKS-19.25)

> Should there be a standard (no that will never work :-) set of tests that
> all chips must go through during start up?

Perhaps, but at startup is not often enough unless your machine reboots
frequently.  Long, long ago, a Vax-11/780 at Rice University had its
floating point accelerator (an entire board) go a little funny in the head
without telling anyone.  After that (after wondering how much of a week's
worth of x-ray crystallography and reservoir simulations were junk) we
decided to run user-mode floating point diagnostics late every night.  Of
course, I imagine most people are like me -- I use a Pentium- based machine,
and haven't a clue how to run floating point diagnostics, nor do the Norton
Utilities advertise that they check the FP (come on, guys, it wouldn't take
long compared to checking my disk), and if I use the past to predict the
future, the chip vendor won't tell me if a problem is discovered.

David Chase, [email protected]

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

Date: Thu, 24 Jul 1997 02:59:21 -0400
From: [email protected] (H.Shrikumar)
Subject: Re: The truth about Usenet's Psychic Spammers!

There were some serious errors in the article about the psychic spammers
(800-number asks caller to dial 809 number, rip-off).  And, though this
instance might be simple misconception, there is a RISK of an oft-quoted
forum like RISKS carrying egregious errors without a correction.

>However, several foreign countries have been assigned "North American"
>area codes recently.  Among them, area code 809 for the Caribbean.

These numbers are not a "recent assignment". In fact they are a holdover
from the _past_. Some Caribbean nations were given area-codes under the
North American Numbering Plan (NANP, 1947) many years before there was such
a thing as country codes or even Trans-Atlantic Telephone cable (TAT-1,
1956),

Exploiting these area-code-look-alikes for scams is a recent phenomenon,
though.

>Since these people are not bound by US law, they do not need to
>disclose the full cost of making the phone call.

Too many misconceptions here ..

First: These calls are very much bound by US law, being billed by a US long
distance company.  But remember that US law is based on a "free market", so
a rip-off can still be "legal".  (The RISKS of govt regulated tariffs are
left as an exercise to the reader.)

Second: They do have to disclose the rate (fair business, fraud etc.), but
you've got to ask! (e.g., the operator).

What can one do ? Be alert. There are innumerable ways one may be given the
number to call. From a 800-number call, Or an advt.  Your beeper.  You
return an urgent call.  You fax them.  Someone "borrowed" your phone.  That
BBS number with "free" goodies.  Almost anyhow! (Your dreams are probably
safe, though, despite the 'psychics').

Look at the first few digits of the number being called.

1. 1-809- ...
2. 011-   ...
3. 10-XXX-...   (May be written as 1-0XX-X ... !!)

If in doubt, ask your local friendly '0' operator for advice.

There is another similar scam that involves the victim getting a collect
call (possibly about something worrisome), but one that just "happens" to be
carried by a rip-off long distance company.  Ask. REFUSE A COLLECT CALL
UNLESS you know (1) what telephone company it is, and (2) what the charges
would be.

>http://www.fraud.org/809alert.htm
>http://www.oag.state.tx.us/WEBSITE/NEWS/LEGALMAT/9701cpd.htm
>http://www.ece.orst.edu/~alper/Info/scam.html

These web sites suggested do make an excellent read.  Here are a
few more authoritative sources of information.

Linkname: BELLCORE: National Solutions - North American Numbering Plan (NANP)
    URL: http://www.bellcore.com/NANP/

Linkname: CONSUMER ALERT: International Dial-a-Porn
    URL: http://www.fcc.gov/ib/td/dialporn.txt

Shrikumar, [email protected]

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

Date: Mon, 21 Jul 1997 09:22:18 -0400
From: hymie! <[email protected]>
Subject: Re: The truth about Usenet's Psychic Spammers! (Corteville, R19.25)

Re: The "809" problem, it might be worth noting that the so-called "809
problem" has expanded?  My telephone book lists the following area codes:
       242     Bahamas
       246     Barbados
       441     Bermuda
       787     Puerto Rico
I believe an area code has been assigned to Monserrat as well, and I would
expect more to be assigned to this set of countries.  (And this reminds me
of a recent scam where "011-24" was claimed to be the country code for
Canada.  It turned out that there is no country code 24, but the phone
number started with 8, and 011-248 is the country code for Seychelles
Island.)

RISK? Naming a problem by a characteristic that turns out to be non-unique?

.hymie!

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

Date: 17 Apr 1997
From: RISKS moderator
Subject: Privacy Digests

Periodically I remind you of TWO useful digests related to privacy, both of
which are siphoning off some of the material that would otherwise appear in
RISKS, but which should be read by those of you vitally interested in
privacy problems.  RISKS will continue to carry general discussions in which
risks to privacy are a concern.

* The PRIVACY Forum is run by Lauren Weinstein.  It includes a digest (which
 he moderates quite selectively), archive, and other features, such as
 PRIVACY Forum Radio interviews.  It is somewhat akin to RISKS; it spans
 the full range of both technological and nontechnological privacy-related
 issues (with an emphasis on the former).  For information regarding the
 PRIVACY Forum, please send the exact line:
    information privacy
 as the BODY of a message to "[email protected]"; you will receive
 a response from an automated listserv system.  To submit contributions,
 send to "[email protected]".

 PRIVACY Forum materials, including archive access/searching, additional
 information, and all other facets, are available on the Web via:
    http://www.vortex.com

* The Computer PRIVACY Digest (CPD) (formerly the Telecom Privacy digest) is
 run by Leonard P. Levine.  It is gatewayed to the USENET newsgroup
 comp.society.privacy.  It is a relatively open (i.e., less tightly moderated)
 forum, and was established to provide a forum for discussion on the
 effect of technology on privacy.  All too often technology is way ahead of
 the law and society as it presents us with new devices and applications.
 Technology can enhance and detract from privacy.  Submissions should go to
 [email protected] and administrative requests to
 [email protected].

There is clearly much potential for overlap between the two digests,
although contributions tend not to appear in both places.  If you are very
short of time and can scan only one, you might want to try the former.  If
you are interested in ongoing discussions, try the latter.  Otherwise, it
may well be appropriate for you to read both, depending on the strength of
your interests and time available.  PGN

 [For privacy devotees, there was an interesting panel at the Commonwealth
 Club of California on Thursday night, 24 Jul 1997, entitled PRIVACY ON
 THE INTERNET: Who Holds the Keys?  Gina Smith of ACM News moderated, with
 David Carlick (PowerAgent), Marc Rotenberg (EPIC), Phil Dunkelberger
 (PGP), Christine Varney (FTC), and me.  The audio might appear somewhen on
 NPR, and CCC audio is rumored to be archived somewhere on cnet.com.]

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

Date: 1 Apr 1997 (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
  [volume-summary issues are in risks-*.00]
  [back volumes have their own subdirectories, e.g., "cd 18" for volume 18]
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 19.26
************************

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.