precedence: bulk
Subject: RISKS DIGEST 18.79

RISKS-LIST: Risks-Forum Digest  Tues 28 January 1997  Volume 18 : Issue 79

  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:
Spamming Risks and Solutions (Simson L. Garfinkel)
Risks of floor repair (Paul Bissex)
Computer Glitch Gives Investors Instant Loss of Balance at Schwab
   (Norm deCarteret)
Microsoft Office 97 Steals My Initials, MSOF (Michael S.O. Franz)
Cosmic radiation can cause computer memory loss (Martin Minow)
Re: Shetland Times copyright suit (Prabhakar Ragde, John Pelan)
Re: Macintoshes and Y2K (Bear Giles, Jonathan Stott)
Y2K on non-Unix/Microsoft systems (Steve McKinty)
Re: Y2036, Y2038, and the superiority of UNIX (Frederick G.M. Roeber)
URL filtering, Re: ad.doubleclick.net (Caveh Frank Jalali)
Guilty by confusion? Domain names and IP addresses of net.abusers
   (Lars Wirzenius)
Adios ads.doubleclick.net (John Hascall)
Side benefit of proxies re cookies (Mark Seecof)
Risks of communicating with the wrong person (James W. Birdsall)
E-Mail Addressing Problems (Todd Burgess)
Verifying Mail Addresses (David Fetrow)
AOL software flaw (JMFBAH)
4th ACM Conference on Computer and Communications Security (Mike Reiter)
Abridged info on RISKS (comp.risks)

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

Date: Mon, 20 Jan 1997 20:30:41 -0800
From: "Simson L. Garfinkel" <[email protected]>
Subject: Spamming Risks and Solutions

On Monday, 13 Jan 1997, Vineyard.NET was apparently attacked by a
spam-for-hire company.  The organization, "CV Communications," connected to
our SMTP server and started sending us advertisements for its own spamming
services.

I discovered the attack after approximately 66,000 messages were sent.  Most
of them went to subscribers of AOL and CompuServe.  I contacted the spammer,
using the phone number at the bottom of each message he was sending out, and
demanded that he stop.

Spamming is a known problem on the Internet.  I'm hopeful that
law-enforcement agencies will start seriously looking into this problem, as
I think that there is a limit to how effective technological solutions can
be.

However, there are several solutions that I have thought of.

1. Limit the number of RECV recipients permitted in each SMTP transaction.

Rather than sending out tens of thousands of messages, we were hit with a
few hundred messages that each had more than 100 recipients. We have
therefore modified our netperm-table file to limit the number of recipients
that each SMTP connection can have.

2. Disallow transiting.

Vineyard.NET's SMTP server is used both by our customers to send out
messages and by others on the Internet to send us messages. But it shouldn't
be used by others on the Internet to send messages through us to third
parties. We have therefore modified our SMTP server so that it can tell the
difference between an internal connection and an external
connection. External connections are not allowed to transit through us to
other external mail servers.

3. Reject messages that come from "suspicious" sources.

We have not implemented this yet. However, it seems reasonable to reject out
of hand any SMTP message from certain kinds of hosts. For example, you might
want to reject those from addresses that do not have a valid domain name, or
from hosts that appear to be dialup addresses.

I have written an article about this spamming incident which will appear in
my 28 Jan 1997 Packet column. You can view it at
http://www.packet.com/garfinkel on Wednesday January 29th.

I have also made my modified SMTP server available. It is located at
http://simson.vineyard.net/hw/spam2/smap.c . This is a modified version of
the Trusted Information System's SMAP server, part of their firewall
toolkit. It is my understanding that FWTK is no longer being maintained by
TIS, which is a pity.

Simson L. Garfinkel, Visiting Scholar, University of Washington,
Columnist for PACKET <http://www.packet.com/garfinkel> and The Boston Globe.

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

Date: Sat, 25 Jan 1997 13:14:16 -0800 (PST)
From: [email protected] (Paul Bissex)
Subject: Risks of floor repair

 Last summer, contractors at Commonwealth Edison's LaSalle nuclear
 power station were filling cracks in a concrete floor by pumping them
 full of foam grout.  What the workers didn't know, though, was that a
 tunnel ran beneath that floor, carrying water for some safety systems at
 the plant, and their grout was pouring through the cracks into the water.
 The grout partially clogged the tunnel, compromising safety at the plant
 for 10 days before Edison -- when pushed by federal inspectors -- finally
 figured out what was wrong.  [*Chicago Tribune*, 25 Jan 1997, front page]

The NRC levied a $650,000 fine for what they called a "very significant
safety problem."  Without getting into a debate about nuclear power, I think
one could point out the risk in thinking that there are any non-critical
jobs where critical systems are concerned.

Paul Bissex   [email protected]    http://www.well.com/user/pb/tech/

 [Grout, Grout, Dammed Slot!  PGN]

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

Date: Thu, 23 Jan 97 08:06:05 EST
From: "Norm deCarteret (813-878-3798 (TL 438)" <[email protected]>
Subject: 'Computer Glitch Gives Investors Instant Loss of Balance at Schwab'

A program error caused Schwab's computers to omit a significant number of
mutual funds when investors used Telebroker to track holdings by phone,
leading some of them to believe themselves broke.  The problem existed from
Monday afternoon through late Tuesday evening scaring scores of investors.
Janus, Putnam and Schwab's own funds were among those omitted from net asset
calculations.

Tracey Gordon, Schwab spokeswoman: "We were making some system changes when
there was a program error."  On why the problem went on so long: 'Mutual
funds are priced once a day.  We found that it would be cleaner and simpler
to wait until the next regularly scheduled market change to update the
system'.  Cleaner and simpler for Schwab, presumably.  Gordon said investors
who made panicky trades as a result 'would be made whole' but there'd be
risks in determining both the who and the how much.

Norm deCarteret

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

Date: Wed, 22 Jan 1997 15:56:04 -0800
From: Michael Franz <[email protected]>
Subject: Microsoft Office 97 Steals My Initials, MSOF

My full name is Michael Steffen Oliver Franz, which makes my initials
"msof". I usually use these initials in internal correspondence, and I
have an e-mail address "[email protected]".

Now, I just installed Microsoft Office 97 on my computer.

Curiously, Office 97 automatically replaces some occurrences of "msof" by
"Microsoft Office". For example, this happens in the "initials" box in the
Word Annotations dialog. I am not yet sure how far-reaching this automatism
is, but the prospect of having my name replaced without my knowledge is
frightening. You can see this strange effect for yourself if you type "msof"
at the start of a line in Word and then wait for a short time.

Michael Steffen Oliver Franz
[email protected] (university business) and [email protected] (private)

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

Date: Fri, 24 Jan 1997 10:08:38 -0800
From: Martin Minow <[email protected]>
Subject: Cosmic radiation can cause computer memory loss

An article in the Swedish newspaper Svenska Dagbladet (1997 Jan 24)
currently available on their web site http://www.svd.se/ describes research
carried out by Ericsson Saab Avionics by Karin Johansson that suggests that
computers, especially those carried on high-altitude aircraft flights, may
be at risk for cosmic radiation.

Johansson and her colleagues carried out experiments on SAS transcontinental
(Atlantic) flights that measured one [bit] error per memory chip per 200
hours. The article notes that a modern personal computer may have 64 such
chips. This means that an ordinary laptop PC may expect an error every three
hours, or about twice during an atlantic flight. [Assuming you brought
enough batteries.] The problem is worsened when the flight path is over the
North Pole because the earth's magnetic field, which normally protects
against cosmic radiation, is directed such that the protection is lessened.

Karin Johansson notes that the computers used to control the aircraft itself
"are not the absolutely most modern, and consequently their electronic
circuits are not as small and sensitive." However, component manufacturers
are not interested in building electronics for such a small market as
avionics, so the aircraft manufacturers must use the electronics available
in the marketplace. To protect against error, aircraft computer designers
will use parity and error-correcting circuitry to prevent a single-bit error
from propagating into other computation.

Summerized and translated by Martin Minow, [email protected]

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

Date: Fri, 24 Jan 1997 09:51:35 -0500 (EST)
From: Prabhakar Ragde <[email protected]>
Subject: Re: Shetland Times copyright suit (Randell, RISKS-18.78)

The Shetland Times has obtained a preliminary injunction against the
Shetland News to prevent the News's web site from linking to Times
documents. Part of the judge's reasoning was that the advertising material
on the "front page" of the Times could thus be bypassed.

I did an AltaVista search on the phrase "Shetland Times" and came up with
lots of links into the depths of the Shetland Times site. Presumably DEC has
committed the same offense as the Shetland News, and their new European
mirror site might be vulnerable to a similar challenge.

Given the usual response to any attempts to remove "offensive" or "illegal"
material from the Net, I'm surprised that I didn't turn up dozens of
third-party links into the Shetland Times site, in defiance of the reasoning
behind the injunction.

Prabhakar Ragde, Department of Computer Science, University of Waterloo
Waterloo, Ontario CANADA N2L 3G1  (519)888-4567,x4660 [email protected]

 [There were several longer messages with similar points.  PGN]

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

Date: Thu, 23 Jan 1997 20:18:45 +0000 (GMT)
From: John Pelan <[email protected]>
Subject: Re: Shetland Times copyright suit (Randell, RISKS-18.78)

The judgement, as I believe it should be interpreted, means that it is the
duplication of the headlines themselves which breached the copyright
law. Whether they link to the original Shetland Times articles or different
articles on the same story is irrelevant.  The judge believes that the
headlines constitute a separate work.

It think that his decision was in line with the intention and spirit of the
copyright law.

Also, I note that RISKS contributions with URLs seem to be increasingly
giving away the registered account information, namely

http://www.the-times.co.uk/news/pages/tim/97/01/21/timlawscl01001.html?10695

This contains '10695' at the end, which is what identifies the user and
now permits anyone to access The Times site in that guise. Watch out for a
change in personal preferences !

John Pelan ([email protected])

 [Note, in the above the '10695' is in fact a truncation of the full set
 of digits that were in the URL that Brian had posted.  In a side message,
 Brian recommends that in the future that he/we indicate when such
 alterations are made.  PGN]

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

Date: Thu, 23 Jan 1997 19:20:43 -0700 (MST)
From: Bear Giles <[email protected]>
Subject: Re: Macintoshes and Y2K (Wood, RISKS-18.78)

>Macintosh users probably have less cause for concern about the year 2000
>than any other computer users, thanks to Apple's farsighted programmers.

This gem illustrates just how nasty the Y2K issue is.  The internal
representation of the date is only one small Y2K problem.  The others
include:

- are the library functions robust?  Are they correct?  (E.g.,
  can they tell you whether 2000 is a leap year?  The date of
  Memorial Day in 2017?  The date of Easter in 2004?  The number
  of business days between any two arbitrary dates?)

- do the developers actually call these functions, or do they
  write their own?

- do the developers always display 4-digit years?  If not, do they
  always truncate the year correctly?

- do the developers alway require 4-digit years?  If not, how do
  they interpret shorter years?

Bottom line: if mac programs are intrinsically Y2K safe due _solely_ to the
representation selected by the godlike system designers at Apple, then all
C++ programs are intrinsically bug free and fault tolerant since that
language was designed to include resources to help make software engineering
manageable.

Bear Giles  [email protected]

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

Date: 23 Jan 1997 17:58:56 GMT
From: [email protected] (Jonathan Stott)
Subject: Re: Macintoshes and Y2K (Wood, RISKS-18.78)

Ahh, but how do your _applications_ store dates?  If only the last two
digits are stored on disk then you have a problem, no matter how many bits
your system clock uses.  Good hardware design only provides a false sense of
security when the programmers get sloppy.

Jonathan Stott, CWRU Dept. of Physics, School of Graduate Studies
[email protected] [email protected] http://poly.phys.cwru.edu/~jstott/

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

Date: Thu, 23 Jan 1997 15:05:49 +0100
From: [email protected] (Steve McKinty Sun Microsystems Grenoble)
Subject: Y2K on non-Unix/Microsoft systems (Wood, RISKS-18.78)

This isn't particularly novel. DEC's VMS operating system (designed in the
mid-1970s) also implements the date as a 64-bit signed integer giving the
number of microseconds since the Smithsonian base date of (I think) 17th
November 1858.  +ve numbers are regarded as absolute values, -ve ones as
deltas, but even so the VMS clock is good for many millenia.

In addition to that all date displays use a 4-digit year. There is a
well-known bug filed against VMS pointing out that the date displays will be
incorrect after Dec 31st 9999. The bug was accepted by DEC with the note "we
will fix this in a future major architecture."

Steve

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

Date: Fri, 24 Jan 1997 01:57:37 -0800
From: "Frederick G.M. Roeber" <[email protected]>
Subject: Re: Y2036, Y2038, and the superiority of UNIX (RISKS-18.78)

In RISKS 18.78, Dan Hicks wrote:
> I prefer a floating-point format ...

Note that if you are measuring intervals by subtracting timestamps, then the
use of floating point numbers for the timestamps can lead to hard-to-debug
errors in accuracy.

The Patriot missile failure in Dhahran was caused by a similar error: values
from the system clock (integer number of tenths of seconds since powerup)
were converted into floating point values to do the intercept math.  After
some number of days of operation, the point floated, and the accuracy
suffered.  [See RISKS-13.35]

While it can be argued that this merely means that intervals should not
be measured by subtraction like this, I think that floating-point system
clocks would only increase the RISK of such an error.

Frederick G.M. Roeber, Netscape Communications Corp., 501 E. Middlefield Rd.
Mountain View, CA, USA-94043 +1 (415) 937 3180 [email protected]

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

Date: Thu, 23 Jan 1997 14:15:38 -0800
From: Caveh Frank Jalali <[email protected]>
Subject: URL filtering, Re: ad.doubleclick.net (RISKS-18.78)

The obvious defense against hostile or undesirable web sites is to not visit
them in the first place.  This process can in fact be automated in
netscape's browser.  This saves bandwidth and your time!

The basic premise is that the browser may optionally execute a function on
every URL before it is accessed to determine whether a direct connection
should be made or a proxy should be used in the process.  This affords the
opportunity to [mis]direct the browser to fetch the document from an invalid
source.  this is a good approximation of not getting the document at all.

We sit behind a fire wall, so all WWW access has to funnel through a
proxy.  If I tell netscape to fetch an external document using a
direct connection, the connection attempt will fail, and the document
will not be accessed.  Netscape will put a broken image icon in its
place.

Here are the nuts and bolts to do it, but some assembly is required:
Under options/network preferences/proxies, select "automatic proxy
config" and tell it which file to use.  Call it something like
"file:///HOMEDIR/.netscape/proxy.pac", replacing HOMEDIR with your
home directory; the actual code is included below.
Next, go to options/general preferences/helpers and create an
application helper of type "application/x-ns-proxy-autoconfig" for
suffix "pac", handled by "navigator".
Install this java-script code to do the actual filtering.  call it
"file:///HOMEDIR/.netscape/proxy.pac", as mentioned before.

================
function FindProxyForURL(url, host) {
       if ( isResolvable(host) && ! shExpMatch(host, "[0-9]*") )
               return "DIRECT" ;
       else if (host == "advertising.quote.com")
               return "DIRECT" ;
       else if (host == "ad.doubleclick.net")
               return "DIRECT" ;
       else if (shExpMatch(url, "*:*/ads/*"))
               return "DIRECT" ;
       else
               return "PROXY webcache:8080; ";
}

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

Date: Thu, 23 Jan 1997 12:08:32 +0200
From: Lars Wirzenius <[email protected]>
Subject: Guilty by confusion? Domain names and IP addresses of net.abusers

Net.abuse (spamming, mailbombing, systematic trolling, etc) are being fought
via filters, among other things. This leads to unexpected risks for innocent
bystanders.

Having a similar domain name as a known net.abuser can make you guilty by
confusion: if a spammer operates from earthFOO.com, and you are
earthBAR.com, people are going to confuse the two domains.  This has already
happened (for suitable values of FOO and BAR -- the common earth prefix was
actually used).

If it happens in a discussion, it can be (and has been)
corrected.  If it happens in a router, filter, or other software,
it can be difficult to even detect.

A similar thing applies to IP numbers. Many sites now block all IP addresses
belonging to problematic sites. If at a later date those addresses are
reclaimed by the ISP and re-assigned to another client, that client will
still be blocked. Given the worries about IPv4 numbers running out,
especially for smaller ISPs, this isn't unthinkable.

I have an aggressive junkmail filter (http://www.iki.fi/liw/mail-to-lasu.html)
You don't have to worry about it, since I've sent you mail.
------------------------------

Date: Fri, 24 Jan 1997 11:29:38 -0600
From: <[email protected]> John Hascall
Subject: Adios ads.doubleclick.net

I put the following in my /etc/hosts (yea, unix-centric, too bad):

127.0.0.1 localhost ad.doubleclick.net

End of problem.  I suppose if not already running a WWW server
one could even put in a simple script invoked by inetd :

#!/bin/sh
echo "Content-type: image/gif"
echo ""
cat /usr/local/etc/nyah-nyah-nyah.gif

if it makes you happier....

I suppose the risk is if ad-avoidance becomes popular enough that browser
makers make it easy, then everyone does it, then an unintended consequence
might be the hastening of the "pay-per-viewing" of the internet.

John

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

Date: Fri, 24 Jan 1997 18:03:30 -0800
From: Mark Seecof <[email protected]>
Subject: Side benefit of proxies re cookies

A side benefit of proxy-server/firewalls is that they somewhat mask the
identity of web-browsing folks behind them.  When I refuse cookies and
access Internet resources through the firewall of a large organization I get
much of the anonymity I might want.  I suggest that ISP's should offer to
proxy their small customers' browsing just to give them this benefit.

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

Date: Thu, 23 Jan 1997 20:19:11 -0800
From: "James W. Birdsall" <[email protected]>
Subject: Risks of communicating with the wrong person

Actually, the risks of misaddressing occur in any communication medium.  We
all receive paper mail that isn't for us; since most of us check addresses
before opening mail, privacy is usually preserved at least (as it would be
if we used the electronic equivalent of envelopes -- encryption).  We all
receive phone calls that aren't for us; since the telephone is an
interactive medium it is customary to verify the identify of the person at
the other end before exchanging messages, thus preserving privacy and
ensuring that the message reaches the right person.

In 18.77, [email protected] (Darin Johnson) writes:
>The old rule applies - never say anything on usenet or e-mail that you
>wouldn't mind being posted in the office lunchroom.  Chances are, it just
>might end up there.

Actually, the place where this event is most common is on the MU* (MUD,
MUSH, MUCK, MOO, MUX, etc.) systems, where it is known as a "mav". When
sending a private message (page, whisper) to someone, it is very easy to 1)
send a message to the wrong person, typically somebody else you are talking
to or 2) mistype the command so everybody in the room sees the message. On
fancier systems which allow a user to automatically reply to the last person
who paged them, it is common (especially when the net is lagging) to get a
page from person B while typing a reply to person A and thereby accidentally
send the reply to person B.

Despite a lot of fallout and embarrassment from these incidents, nobody has
come up with a good way of reducing them -- if people won't double-check
what they type, there's nothing software can do to save them.

Also in 18.77, [email protected] (Lawrence H Smith) writes:
> ... naive users perceive it as "like paper mail, only faster and cheaper" -
> a perception which is deeply flawed.

Actually, the perception that paper mail is reliable is deeply flawed.
Comparing the performance of the US Postal Service to that of the net in my
nine-plus years on the net, I would have to say that paper mail is at least
as bad if not worse. The post office loses several pieces of mail on me
every year. Their latest goof-up was to misdeliver a piece of mail to the
wrong address (wrong *state*, even!) three times before bouncing it back to
me. Now, this failure mode is shared by electronic mail, but the post office
took two months as opposed to a few hours.

  --James W. Birdsall

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

Date: Thu, 23 Jan 1997 23:07:10 -0500 (EST)
From: Todd Burgess <[email protected]>
Subject: E-Mail Addressing Problems

The university of Guelph has a simple policy for creating e-mail accounts:
first initial, last name (i.e., [email protected]). This scheme works
great as long as their are no duplicates (ie Tom Burgess). If there are
duplicates then they start adding numbers to the e-mail ID or simply using
first names.

When my brother came to Guelph my Dad tried sending e-mail to
[email protected] which was not my brother's e-mail account. My brother
had been given the account [email protected]. Luckily the person who got the
e-mail was nice enough to look up the correct address and forward it to my
brother.

The RISKs? E-mail ID schemes like this work great as long as there are no
duplicate names. The moment there are duplicate names then a lot people are
going to start seeing other people's e-mail.

As for Kamens's (RISKS 18.78) comment about paper mail vs. e-mail. I think
it would be fair to say that it is easier to get an e-mail address wrong
then a paper address wrong. E-mail delivery systems only have the e-mail
address to go on when delivering mail. If your e-mail ID doesn't match then
tough it bounces.

Mail addresses have fields like name, address, city, country and postal code
to assist in delivering mail. Failing that post offices can open mail in
hopes of finding the correct address. I know people who have worked in post
offices in small towns and they say they can usually determine where to send
a letter simply on the name alone (even if the address is incorrect or
missing).

University of Guelph, Computer Science Major   E-mail: [email protected]
URL: http://eddie.cis.uoguelph.ca/~tburgess

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

Date: Fri, 24 Jan 1997 21:26:55 -0800 (PST)
From: David Fetrow <[email protected]>
Subject: Verifying Mail Addresses

In RISKS-18.78 [email protected] and others discuss the problem of
verifying e-mail addresses as correct, rather than just hitting the send key.

The obvious solution ("Do you really want to send this? y/n") would
undoubtably work no better than it does for file deletion.

It occurred to me that perhaps what's needed is verifying something besides
words on the screen; that if I am dealing with two kinds of sensory data
something is more likely to click. e.g. a voice saying:

"Sending mail to Ann Landers <[email protected]>, OK?" and my saying "yes" or
"no" (well within a modern machines abilities). Perhaps even do a little
scan for hot words and have it ask: "Do you really want to use the word
'braindead' in your mail to 'boss'?".

Although this is probably silly regarding e-mail (and adds a host of risks
of its own) such warnings attached to particularly risky commands and
forcing a person to do something *unusual* to continue could prevent a lot
of errors, if not overused.

(Note, something similar happens when the WinNT 4.0 license appears on the
screen while installing that product. To continue you have to hit F8, and
only F8. You are pretty much forced to at least glance at the license in
order to continue. Annoying but rather slick. Taking it one step further:
the key could needed could be chosen at random from the non-letters.)

David Fetrow, Biostatistics, University of Washington

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

Date: Thu, 23 Jan 1997 09:30:15 -0500 (EST)
From: [email protected] (JMFBAH)
Subject: AOL software flaw (Re: PGN comment in RISKS-18.77)

> ... AOL seems to have shot itself in the foot by going to flat-rate charges.

Complicating the access problem (which I haven't experienced personally) is
that AOL keeps putting up a piece of software that seems to block internet
traffic.  Despite repeated attempts to explain the problem, this software
still appears (almost every other day) without the original problems getting
fixed.  I believe it's very hard to determine whether the new pricing has
anything to do with their problems as long as they keep putting up software
that doesn't work.

/BAH

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

Date: Thu, 23 Jan 1997 22:03:33 -0500 (EST)
From: Mike Reiter <[email protected]>
Subject: 4th ACM Conference on Computer and Communications Security

       *** EARLY REGISTRATION DISCOUNT ENDS JANUARY 31 ***
   Fourth ACM Conference on Computer and Communications Security
              (Preliminary Technical Program)
                    Zurich, Switzerland
                     April 1-4, 1997
                  Sponsored by ACM SIGSAC

For more information, including registration and hotel information,
see: http://www.zurich.ibm.ch/pub/Other/ACMsec/index.html

 [The program looks really interesting.  PGN says, "check it out."]

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

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.79
************************

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.