precedence: bulk
Subject: RISKS DIGEST 19.21

RISKS-LIST: Risks-Forum Digest  Thursday 5 June 1997  Volume 19 : Issue 21

  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:
Programmed Tunnel-Digging Robot (Robert J. Sandler)
Cashless not crashless (David Hood)
Revenge spam hits antispammer (Beth Arnold)
Anti-spam missile misfires... (Reuben G. Torrey and Richard Karash)
Big Brother strikes again... Netcheck New Zealand (Bruce J. Fitzsimons)
When is 0 not 0? The wonderful world of the Web (Clarke Christopher Turrall)
Java has a similar problem to the 2000-year problem (Quinton Jansen via
   Lindsay F. Marshall)
Attack on California's electric power infrastructure (Betty G.O'Hearn)
Indictments for Computer Chip Theft (Edupage)
Commands without timeout (Nick Brown)
Re: Computer fraud in subscribing ...? (Kevin McCullen)
Re: newmediagroup.com headers were forged ... (Barry Brown)
Re: Florida "Computer Gang" Members Arrested (Mich Kabay)
Uniform password method (Ken Knowlton)
Re: Microsoft and Privacy (Marnix Arnold)
Re: Time-zone bug in Canadian election (Mark Brader)
Re: Lost Pond: Jurassic Duck (Michael Handler)
Re: Senate anti-spam bill (Ray Everett-Church)
More dangers of e-mail to the wrong users (Aviel Rubin)
Abridged info on RISKS (comp.risks)

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

Date: Mon, 2 Jun 1997 00:18:18 -0400
From: "Robert J. Sandler" <[email protected]>
Subject: Programmed Tunnel-Digging Robot

Anthony Catania got suspicious when his floor started to shake.  For weeks,
sewer diggers had been tearing up the street in front of his
restaurant-supply store in Seattle.  Among the deployed tools was a
tunnel-digging robot "mole," a $475,000, 18-foot-long device that can chew
through 70 feet of soil a day using programmed directional coordinates.  The
machine has been doing solid yeoman's work for years, but this time somebody
programmed it incorrectly.  Catania realized this when he saw 11 hard hats
peering expectantly into a 30-foot-deep hole in the street, one muttering,
"Our mole is supposed to come out here but we haven't seen it."  Eventually
recovered without damaging Catania's property, the wayward mole left behind
a 700-foot hole that will have to be filled with concrete.  Cost: $600,000.
[Source: *The New York Times Magazine*, 1 Jun 1997, p. 25]

Apparently for $475,000 you don't get any tracking!

Robert J. Sandler  [email protected]

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

Date: Thu, 5 Jun 1997 16:04:11 +1200 (NZST)
From: [email protected] (David Hood)
Subject: Cashless not crashless

On Monday 2 Jun 1997, the major national EFTPOS (Electronic Funds
Transaction, Point-Of-Sale) system crashed from 10am to noon.  During the
two hours Electronic Transaction Services estimated about 100,000
transactions were lost.  Electronic Transactions Services covers about 80%
of the country's retail terminals.  The failure did not effect 'hole in the
wall' money machines (ATMs) (source: *Otago Daily Times* 3 Jun 1997).
Regarding the estimate of lost transactions, it is worth keeping in mind
many major retailers have manual backup procedures for dealing with debit
cards while the system is down.

In a radio interview the following day a spokesman said that there were two
failures.  The first was the failure that caused a processor to stop
working.  The second, a failure in the backup procedures that should have
meant the workload of the failed processor was distributed to the company's
other 7 processors.  The specific causes of the failures were not known at
the time of the interview.

The failure took place on a public holiday which was being used as a 'sale
day' by some national chains of stores.  Supermarkets were open at the time,
but many locally owned shops were closed for the holiday.

David H.

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

Date: Sun, 1 Jun 1997 20:24:15 -0400
From: "Beth Arnold" <[email protected]>
Subject: Revenge spam hits antispammer

My name is Elisabeth Arnold.  As you may or may not know, I have been the
victim of a massive revenge spam.  I work at a small ISP in New Jersey.
Recently, I pulled a spammer's account for repeated violation of our
acceptable-use policy.  This was 2 weeks ago.  That weekend, a message was
sent out by "Beth Arnold" with a bunch of gibberish and a 200k wav file of
"animal sounds".

This weekend, 2 separate messages were sent, one to participants in the
net-abuse groups -- including a 300k wav file of recordings from the
activity menu of an Audix voice-mail system, and another to participants in
the comp.* and rec.* groups.  You may very well have received this message:

> Call BETH ARNOLD at 1-800-450-5766 to order a list of e-mail addresses and
> bulk e-mail software.  If you got this message, congratulations.  You are
> on a list of e-mail addresses that we sell.  You will receive many more
> messages like this one.
[SLIGHTLY EDITED FOR RISKS.  PGN]

This message was obvious flame bait, and it worked very well.  I received
200 calls to my 800 number before disconnecting it.  My mail server was
inundated with mail bombs, returns, and complaints.  My http ports were SYN
attacked.  And I was "ping stormed".

UUNet is useless in tracking this person down.  They just don't care.  I
would appreciate any help I can get.

Thank you, Beth Arnold  [email protected]

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

Date:  4 Jun 97  7:59:02
From: "reuben.g.torrey" <[email protected]>
Subject: Anti-spam missile misfires at CompuServe (Richard Karash)

I monitor the Learning Organization news list as it comes into our
organization. The following item just came through.  Richard Karash is the
manager of this news group.  Here is another RISK of trying to maintain a
"too protected" community with a border patrol that is not able to tell who
is friend or who is foe.   - Ben Torrey

>We've lost all compuserve readers... LO13813
>rkarash @ karash.com (Richard Karash) @ internet

>I believe that, as a result of a change in policy at compuserve, none of
>our compuserve subscribers are getting learning-org mail. I have been in
>touch with several to confirm this and it appears to be the case.

>Here's what seems to be happening: my tech support people here at my
>vendor (world.std.com) think that compuserve is blocking all mail which
>is directed to multiple addresses (more than a few) at compuserve. They
>are doing so to combat unsolicited junk e-mail, but the effect is to kill
>mailing lists for compuserve accounts.

>Until this can be changed, we probably won't be hearing much from several
>of our frequent contributors.

> Richard Karash ("Rick") [email protected]  <http://world.std.com/~rkarash>
> Host for Learning-Org Mailing List <http://world.std.com/~lo> (617)227-0106

 [I sent mail to [email protected] asking for a clarification
 and giving alternative suggestions for handling the RISKS subscribers
 there.  As of the time of posting this issue, I have heard nothing in
 return; business as usual?  PGN]

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

Date: Tue, 3 Jun 1997 17:57:01 +1200
From: "Bruce J. Fitzsimons"<[email protected]>
Subject: Big Brother strikes again...

An article published today on the IDG Computerworld NZ site (www.idg.co.nz)
detailed a "brave" new initiative in making information on individuals
available on the Internet.

The exact link is: http://www.idg.co.nz/nzweb/61e6.html but I wouldn't
expect it will be there forever.

Some of the best points are:

* Netcheck New Zealand believes it is the first in the world to provide
 credit checks on people over the Internet.

* The Managing Director will not reveal what security protects the site,
 but says it is secure. "We have sufficient security measures so that
 break-ins don't happen."

* The companies using the system have to be members, and use a password to
 get access to the operation's database. He says member companies have to
 show their inquiries are what he calls 'Privacy Act compliant', meaning that
 they will have the signed consent of the customers they are doing the
 search on.

* One aspect of the site which the MD believes won't be able to go ahead is
 the one-off searches with payment by credit cards. In practice it would
 have meant anyone could do a credit check on anyone else.  He now says
 it's unlikely that will ever get started.

* Conversely Baycorp, which is perhaps New Zealands biggest credit
 information bureau have stated that they will not be providing Internet
 access to their records, and their data is 40 bit public key encrypted
 when sent over the PSTN.

* Looking at the site, the login screen is not SSL encrypted. There is no
 information about the rest of the site.

I don't think I have to start to explain my concerns to RISKS readers.

I am bemused by the "in practice this would have meant anyone could do a
credit check on anyone else" - how do I know that the companies that PAY to
use this service are any more trustworthy than a casual user (etc etc).

Bruce Fitzsimons

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

Date: Tue, 3 Jun 1997 15:58:50 +0800
From: Clarke Christopher Turrall <[email protected]>
Subject: When is 0 not 0? The wonderful world of the Web

This afternoon, I visited a web site that offered to help me work out
how big a mortgage I could afford:
 http://www.halifax.co.uk/mortgage/pay.html
I entered numbers to the nearest ten pounds in each box as requested, and my
computer churned away computing the sum of these values.  Imagine my
surprise to find that the sum of a set of numbers each with a least
significant digit of 0 does not sum to another number whose least
significant digit is a 0. To cut a long story short, I identified the
problem as the fact that I had entered 020 for one entry rather than 20. Now
I don't know about you, but I think they are the same thing. Netscape (and
MSIE) insists however that 020 is actually equal to 16. Ok so I realised
quickly that the the number was being viewed as octal (I tried 0x... and
that makes the input hexadecimal), but that's because I know what octal
is. I would certainly never consider using it to enter an approximation of
my monthly telephone bill on a web form.

The reason I had entered 020 in the box, was that it contained 0 by default,
and I had added my 20 to the end of the string when I typed it, rather than
replacing the 0 with 20. I feel sure that more users of the web will get
caught with this trap, than there will be users who are angry about not
being able to enter numbers in octal.

Chris Clarke

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

Date: Tue, 3 Jun 1997 08:14:02 +0100 (BST)
From: "Lindsay F. Marshall" <[email protected]>
Subject: Java has a similar problem to the 2000-year problem (fwd)

Date: Mon, 2 Jun 1997 13:09:01 -0700 (PDT)
>From: Quinton Jansen <[email protected]>
To: [email protected]
Subject: Java has a similar problem to the 2000-year problem

"TIME IS ON JAVA'S SIDE (*Information Week*, 19 May 1997, p. 12)

Sun Microsystems acknowledged last week that the Java programming language
has a year-2000-like date error: It will run out of dates in the year
292271023.  Yes, that's roughly 292 million years from now.  James Gosling,
creator of Java, insists a team of engineers is rushing to fix the problem.
"We can't be certain Java will be around that long," he kids, "but then
again, we can't take any chances."

In case you were wondering, the year 292271023 is the estimated date for the
year 2000 fix at the IRS."

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

Date: Wed, 04 Jun 1997 17:35:47 -0400
From: "Betty G.O'Hearn" <[email protected]>
Subject: Attack on California's electric power infrastructure

This morning's IWAR Situation Report contains information about an attack on
the electric power infrastructure in California.  Although the attack used
conventional weapons, it is one of the first attacks on the power
infrastructure possibly linked to a political situation.  Surf over to:
http://www.iwar.org, log in, and get a password.  [...]

[email protected], Assistant to Winn Schwartau

 [Over 60 rounds were fired at a Pacific Gas and Electric substation in
 Redwood City, CA, knocking out power in the area.  A Confederate flag and
 a newspaper with the headline of the McVeigh's guilty verdict were found
 on the fence surrounding the facility.  PGN]

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

Date: Thu, 5 Jun 1997 11:31:55 -0400 (EDT)
From: Edupage Editors <[email protected]>
Subject: Indictments for Computer Chip Theft (Edupage)

Federal prosecutors have indicted 17 individuals for their involvement with
an Asian organized-crime syndicate responsible for armed robberies in May
1995 of more than $10 million worth of Intel Pentium chips from two
companies in Orange County, California.  (*The New York Times*, 4 Jun 1997)

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

Date: Tue, 3 Jun 1997 10:37:05 +0200
From: BROWN Nick <[email protected]>
Subject: Commands without timeout

We recently installed a new security system for our computer room door.
This requires you to type in a 5-digit code to release the lock.  Several
codes are in use, for software people, telephone technicians, cleaners, etc.
The system allows certain codes to be defined as "privileged".  If a
privileged code is preceded by a press on a button marked "L", the door will
thereafter be open for all.  If it is preceded by a press on "R", the door
will be closed for all except privileged codes.

However, the designers of the circuitry forgot to build in a timeout.  If
someone presses "L" or "R" inadvertently (perhaps immediately after having
typed their code - the buttons are rather small and easy to press by
accident), and the next person to enter the room (which might be 60 hours
later, on Monday morning) uses a privileged code, the "L" or "R" will be
activated.  There is a brief flash of an LED when this occurs, but I doubt
if anyone other than the service engineer is likely to work out what it
means at the time.

We contacted the suppliers of the lock, who to their credit understood and
acknowledged the problem and have promised to fix it, but said we were the
first to report it.  Maybe we're just clumsy, but we've hit the problem six
times in as many weeks.  Perhaps other customers are locked out and can't
get to a phone.

The risks are reasonably obvious: a malicious person could gain untraceable
entry by systematically pressing "L" after entering his or her access code,
and eventually a privileged user would be the next to turn up; or, someone
could accidentally press "R", and after the next (privileged) person entered
the room and went on three weeks' vacation, we'd be looking for someone with
cutting gear.

Nick Brown, Strasbourg, France

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

Date: Mon, 02 Jun 1997 11:18:25 -0400
From: kwmcc <[email protected]>
Subject: Re: Computer fraud in subscribing ...? (Brazil, RISKS-19.19)

We've had a large number of the automated hangups that Thomas Brazil
identified.  Dialing *69 didn't work (we'd get an automated message telling
us that we couldn't dial back to that number).  The operator gave us an
interesting theory.  Apparently, it's the result of faulty equipment at
telemarketers.  The telemarketers have equipment which dials numbers and
listens for an answering machine.  If an answering machine is identified, it
hangs up.  If a person answers the phone, the call is transferred
immediately to an operator (who sees your name appear on their computer
screen).

The operator tells us that the equipment used by the telemarketers doesn't
do a very good job of identifying people on the phone and they hang up on a
lot of people.  I suppose it's better for them to hang-up on people (who
don't know who they are!) than to waste their operators time talking to
machines.

Kevin McCullen

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

Date: Wed, 04 Jun 1997 15:23:47 -0700
From: Barry Brown <[email protected]>
Subject: Re: newmediagroup.com headers were forged ... (RISKS-19.17-18)

The mention of enterprise.net in RISKS-19.17 and RISKS-19.18 caught my
attention as I had recently had an unrelated "problem" with them.  One of
our customers reported that as of Thursday, May 31, he was unable to bring
up a web page from the server at homepages.enterprise.net.  At the time, I
hadn't caught up on my RISKS reading and didn't know anything about it other
than my observation that once my traceroute packets hit the CRL backbone,
they were unroutable.  We chalked this one up as another CRL/Sprint/BGP
mystery since we had implemented dual-homing with BGP only a few days before
and routing to enterprise.net through Sprint worked fine.

Along come the RISKS articles saying that enterprise.net was involved in a
spam incident.  Putting the pieces together, we surmise that CRL is still
advertising the route but is denying transit through their network.  (We
have no proof since CRL made no announcement that such an action would be
performed.)  By applying such blanket censorship to an entire network, CRL
is not allowing legitimate traffic through and by offering no explanation of
their actions, they've created confusion among their customers.

As a workaround, we have added an ad-hoc static route to our main router so
that traffic destined for enterprise.net gets sent via Sprint.

Barry

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

Date: Tue, 3 Jun 1997 13:40:32 -0400
From: Mich Kabay <[email protected]>
Subject: Re: Florida "Computer Gang" Members Arrested (RISKS-19.20)

Anonymous Harassment on Net Eludes Florida Law

Two Florida men who had been arrested for anonymous harassment on the
Internet have now been released.  A chief assistant state attorney in
Florida explains: "It's simply not criminal under statute in the state of
Florida.  I'm not condoning this activity.  All I'm saying is that I'm left
powerless to do anything about it."  The two men are 19-year-old former high
school students who had used a Web site to allege that a teacher and student
at their school were engaging in homosexual relations.  The statute cited in
the men's arrest prohibits anonymous publication of material that holds a
person up to ridicule or contempt; however, the Florida state attorney's
office concluded that the statute is an unconstitutional infringement of the
right to free speech.  (*St. Petersburg Times*, 31 May 1997, Edupage, 1 June
1997)

Edupage is written by John Gehl <[email protected]> & Suzanne Douglas
<[email protected]>.  Voice:  404-371-1853, Fax: 404-371-8057.

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

Date: Tue, 3 Jun 1997 08:08:26 -0400 (EDT)
From: [email protected]
Subject: Uniform password method

Quoted from http://www.twa.com:

"Welcome aboard the TWA ... WebSite!  ... you can personalize your
experience ... to meet your individual travel needs and interests ... by
simply entering your name and a password in the box below and clicking on
the Sign in button.  (We suggest that you use your E-mail address or some
other unique password that is easy to remember)."

Ken Knowlton

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

Date: Tue, 03 Jun 1997 11:11:10 PDT
From: Marnix Arnold <[email protected]>
Subject: Re: Microsoft and Privacy (RISKS-19.20)

In RISKS 19.20, "cooler" mentions the Microsoft sidewalk site
(http://www.newyork.sidewalk.com/) as a way for Microsoft to sell "your
e-mail address together with any demographic data they might gather about
you".  The way this gathering is done is a lot less insidious (i.e.,
invisible to the user) than one might think after reading Mich's article.
On the abovementioned page, there is a link called "Customize Sidewalk
Now!", but the URL is called "membersurvey", which seems a lot more
appropriate. It enables the user to "Get the information that's most
interesting to you". After registering of course, thus providing all
"Locator information" (see below for MS's definition of this)
voluntarily. It's interesting to note that the "Terms and Conditions" are
not mentioned or referred to on this registration page...

As for these terms and conditions, somehow the definition of "Locator
information" (which MS also allows itself to share with "other parties") was
omitted from RISKS 19.20:

 "Locator information" consists of a user's name, e-mail address,
 physical address and/or other data about the user that enables the
 recipient to personally identify the user. Any user who does not wish
 to receive any special offers or communications from Microsoft on
 behalf of suppliers, or directly from Microsoft or its affiliates, may
 so notify Microsoft at the listed below under SERVICE CONTACT.

So MS can basically do anything they want with your demographic information,
unless you just happened to read the Terms and Conditions and told them
specifically to leave you alone. That reminds me a bit of mail-spammers
offering to remove you from their list if you send them an e-mail.  How very
considerate of them.

Marnix Arnold (disclaimers...)

 [In response to an earlier comment, I had previously inserted
 the missing text into the archive copy of RISKS-19.20.  PGN]

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

Date: Tue, 3 Jun 97 01:09:27 EDT
From: [email protected] (Mark Brader)
Subject: Re: Time-zone bug in Canadian election

Back in RISKS-18.95, Mich Kabay cited an article that appeared in March
in the (Toronto) *Globe and Mail*:

> Officials have decided that the Internet will face the same rules as other
> news media when it comes to disseminating public opinion polls within 48
> hours of election day and releasing vote results early on election night.

And in RISKS-19.05, I called it bizarre that they were deciding this only
now.  The reason turns out to be that there is a new law this year with
wider prohibitions on poll results, and that's what was being discussed.

It looks as though it was a mistake to introduce this law in the winter:
it contains a daylight saving time bug!  The problem is that most of the
country observes DST, but not all: in Saskatchewan (well, almost all of
it) they keep Central *Standard* Time all year.  So when DST is in effect
everywhere else, the table in RISKS-19.05 REALLY reads:

       Time zone       Local time       Pacific Time
          NDT             8:30             4:00
          ADT             8:30             4:30
          EDT             9:30             6:30
          CDT             8:30             6:30
          CST             8:30             7:30
          MDT             7:30             6:30
          PDT             7:00             7:00

and so, when the election was held yesterday, it was the results from
Saskatchewan, of all places, that were the last to come.  One hopes the
government will take the time to debug the law before the *next* election.

(Okay, so it's not a computer bug.  But legislation is, after all, a kind
of programming too -- it's just executed on rather different hardware.
And it's subject to the same kind of requirements of accuracy and precision.)

Mark Brader, [email protected], SoftQuad Inc., Toronto

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

Date: 1 Jun 1997 11:19:31 -0000
From: "Michael Handler" <[email protected]>
Subject: Re: Lost Pond: Jurassic Duck

Actually, it was "The Duck World: Jurassic Pond", which scans slightly
better. I mirrored a copy of the hack at
<URL:http://www.sub-rosa.com/handler/lost-world-hack/>, for those who missed
it.

>* Alan Sutton, Universal Studios vice president for distribution and
>  marketing, said he thought prank was amusing and done in a spirit of fun.
>* Universal plan to improve their security.

Hacking web sites isn't that difficult for anyone with access to the regular
bag of cracker's tricks; it's rumored that the CIA web page hack some time
back was via poorly checked NFS export options...

It's nice to see a web hack with subtlety and a sense of humor, though. ;)

     Michael Handler <[email protected]> * Sub Rosa * Washington, DC

 [Also commented on by David Schachter, Lloyd Wood (with an oft-forwarded
 item from http://netlynews.com), Joe Buck, and Jeffrey Young.  Jurassic
 Duck is the third bogus-hack report in a week, after AT&T WorldNet and
 the yet-to-awaken LAPD.org.  PGN]

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

Date: Mon, 2 Jun 97 21:53:59 -0400
From: Ray Everett-Church <[email protected]>
Subject: Re: Senate anti-spam bill (Hoffman, RISKS-19.18)

Lance Hoffman makes some excellent points about the Murkowski bill. In its
present form, the Murkowski Bill legitimizes spam as long as it is tagged
with the word "Advertisement" on the subject line of the message. The bill
also proscribes verifiable e-mail routing and then *requires* that ISPs
install filtering systems for their customers or face being sued and fined
by the Federal Trade Commission. This approach, while well-intentioned,
forces consumers and their internet service providers to do all the hard
work -- making ISPs and their customers bear the costs of the spam. This
approach has been likened to legalizing burglary while penalizing you for
not having the right locks on your doors. This may also explain why the
Murkowski bill is vigorously supported by the junk e-mailers.

On the same day Murkowski introduced his bill, Rep. Chris Smith (NJ)
introduced a bill that would add e-mail to the existing law restricting junk
faxes. The Smith bill gives consumers a private right of action against
spam: $500 for *each* of the unsolicited messages they receive.  (And if the
court believes that the spammer "willfully" or "knowingly" violated the law,
the damages are tripled.)  The junk fax law has worked extremely well, it
has survived many court challenges, and it has cut the junk fax problem off
at the knees. The Smith bill doesn't attempt to proscribe technical
standards for mail delivery and it places enforcement in the hands of the
consumer, not in the hands of any government agency.

Smith's bill incorporates much of the language offered by CAUCE, the
Coalition Against Unsolicited Commercial E-mail, an ad hoc volunteer
organization of ISP operators, system administrators, mailing list owners,
and spam fighters. You can see copies of the Smith bill and his introductory
floor statement at <http://www.cauce.org>.

Ray Everett-Church, Esq.  <[email protected]>    www.everett.org/~everett

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

Date: 3 Jun 1997 09:23:15 -0400
From: [email protected] (Aviel Rubin)
Subject: More dangers of e-mail to the wrong users

I have seen some messages on this newsgroups of the dangers of e-mail
aliases, and I recently had two scary experiences.

I worked at Bellcore last year, and I was used to sending e-mail to users by
including only their userid in the mail address. Now I am at AT&T. I sent a
long, very sensitive message to one of my co-workers at Bellcore, and out of
habit, I only used the userid. Well, it turns out that this id is an alias
at AT&T, and my message went to a group of people that should not have seen
it. I am currently doing damage control. I quickly imagined how much worse
it could have been if certain names were included in that alias.

The other incident was similar. I had aliased Stuart Haber to his new e-mail
address, [email protected]. Then, when I got to AT&T, I sent a message to
Stuart Stubblebine about a project we were working on.  Unfortunately, I had
stuart aliased, so the message went to Stuart Haber instead. Fortunately,
S. Haber realized that the message was not intended for him, and quickly
notified me of this. S. Stubblebine meanwhile, had not received a message,
which I had promised him by a certain time. This problem was quickly fixed,
but the potential for what errors like this could lead to makes me sweat.

I now make it a habit to grep an alias out of my .mailrc file before I send
it mail. (yes, I still use regular Unix mail for the most part) I supposed
more modern mailers print out the name of an alias before sending the mail,
but that would not have prevented the first problem I had above, where the
alias was a system alias, which was used because there was no userid at AT&T
for my colleague at Bellcore.

Avi Rubin

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

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