F I D O  N E W S --         |         Vol. 10 No. 9 (1 March 1993)
 A newsletter of the       |
 FidoNet BBS community     |         Published by:
         _                 |
        /  \               |        "FidoNews" BBS
       /|oo \              |         +1-415-863-2739
      (_|  /_)             | NEW!--> 1:1/23@FidoNet
       _`@/_ \    _        |         [email protected]
      |     | \   \\       |
      | (*) |  \   ))      |         Editors:
      |__U__| /  \//       |          Tom Jennings
       _//|| _\   /        |          Tim Pozar
      (_/(_|(____/         |
            (jm)           |         Newspapers should have no friends.
                           |                         -- JOSEPH PULITZER
----------------------------+---------------------------------------

/*********************************************************************
* IMPORTANT NOTE: The FidoNet address for FidoNews has been changed. *
* The new address is:                                                *
*                                                                    *
*                     FidoNews  =  1:1/23                            *
*                                                                    *
* Starting January 1993 email sent to the old address will not be    *
* forwarded! You were warned!                                        *
*********************************************************************/

For information, copyrights, article submissions, obtaining copies and
other boring but important details, please refer to the end of this
file.


                         Table of Contents
1. EDITORIAL  .....................................................  1
  Editorial: Bye bye! (boo hoo!)  ................................  1
2. ARTICLES  ......................................................  3
  Steve Jackson Games case -- recent news  ....................... 11
  Caller ID  ..................................................... 15
  The Youth of FidoNet, Part II  ................................. 17
  I get the point!  .............................................. 18
  H-Net (Handle-Net) Opening March 6,1993!  ...................... 19
  Head-to-Head Air Combat Simulators Echo  ....................... 21
  This New Echo, KLINGON - What Is It?  .......................... 22
  TWO NEW BLINDNESS-RELATED ECHOS NOW AVAILABLE  ................. 23
3. FIDONEWS INFORMATION  .......................................... 25
FidoNews 10-09                 Page 1                       1 Mar 1993


======================================================================
                             EDITORIAL
======================================================================

Editorial: Bye bye!! (boo hoo!)


Well this is it, my final editorial. Next week's will be edited by
Silvia Maxwell and Don Tees. Say hi to them. (Hi!)

Today is a momentous day for me. I'm moving into a new apartment this
very day, tomorrow my phone lines get swapped over. As soon as I
finish this, I have to pack more boxes aand drag 'em over. We're
moving from out in the boonies to the heart of the Mission; 16th St
between Mission and Valencia. The three little holes in my windows
turned out to be bullet holes! (22 or 25 cal.) The glass is
double-paned, and I was able to locate the trajectory. Later, I pull
down the shade, and there's matching holes! Yipes! Oh well, instead of
a 45 minute walk to the cafe, it's about 120 seconds, a vast
improvement. No more do I have to pay $1 for a bus, down on the corner
I can buy a "late nite" (daily bus transfer) for 25 cents! ("I love,
livin' in the city!" -- FEAR)

I digress.

Oh, probably there'll be small mistakes made, but be helpful and nice.
Our new editors have to decipher my 4DOS batch files, and generate a
newsletter that's at least recognizable and somehow get it to 1:13/13.
In a week.

I look forward to seeing what changes they make. I failed to keep one
promise, that of revamping the newsletter format from "line printer"
format to online readable. I really blew the "Ask EFF!" project,
though Shari Steele is hanging in there raring to go.

Think back on all the little wars we've had... Zone 2 hassles... Z1C
"process" or lack of... POLICYx... encryption... I'm begging off just
in time to miss the "Caller ID" wars -- YAY!!! (You know it's time to
leave when...)

It's been fun, really!! Even the hard parts I learned a lot, about
taking my lumps when necessary, and staying the hell out of local
squabbles.


So ta-ta, I'll see you out in the cloud...





FidoNews 10-09                 Page 2                       1 Mar 1993


My BBS is going to go offline for a while, probably a month or two,
starting this week. I will have an email address however, but it's on
the Internet. It's

                       [email protected]

My old DOS machine is now running 386BSD and directly connected to the
internet. In itself an interesting story, and one you'll probably see
in these pages and BOARDWATCH magazine.

Anyways -- you can email me from FidoNet, via certain FidoNet nodes
flagged "GUUCP". Those are UFGATE sites, that have one foot each in
FidoNet and Internet. There's a bunch of then. The way it works is
you send a message to one of those FidoNet addresses, with certain
magicwords placed within the message itself, that the UFGATE software
detects. These are: the "to:" field being the single word UUCP. The
VERY FIRST line of the message formatted exactly as:

to: [email protected]


With at least one completely blank line following it. After that, put
your real message. Make sure ytou have the address (ie. the to: line
embedded in the message body) correct, otherwise your message won't
make it.


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

FidoNews 10-09                 Page 3                       1 Mar 1993


======================================================================
                              ARTICLES
======================================================================


*A FidoNet (FTN) Domain Name Service

(I'm submitting this to FidoNews to generate thought and discussion
about alternatives to the present nodelist.  This proposal was
inspired by the recent nodelist problems (extrainious control
characters, CRC errors, etc.).  The present nodelist is getting too
big to be perfectly managed - the recent nodelist problems will happen
again sooner or later.  Sooner or later MakeNL will break (probably
sooner) and other nodelist processing software will start to have
problems as the nodelist continues to grow.  RPH)

Document: FSC-0000
Version:  001
Date:     14-Nov-1992


                             A Proposal
                                for
                A FidoNet (FTN) Domain Name Service
                           Robert Heller
                             1:321/153
                           Locks Hill BBS

 Information:

    The purpose of this FSC is to describe my ideas for
    migrating FidoNet(r) networks from a "static" nodelist to a
    domain based nameserver type of address resolution scheme.
    This document does not propose a definitive scheme, only one
    posible scheme.  Other schemes are posible - this document
    just presents one as a starting point for discussion.
    Distribution of this document is unlimited.

1. Introduction
---------------

In this document I plan to present a simple domain nameserver
scheme for FidoNet(r) networks.  This scheme could be implemented
easily, since no new connection protocols would be needed and in
fact little new software would be needed.

Nameserver queries would be implemented as File Requests for
magic filenames.  The files would contain the information needed
to perform the desired address resolution. These files would be
built by the nameserver in advance by an off-line process.  That
is, they would be pre-computed - the querying node would not be
left hanging on the line while the nameserver went off and did a
database lookup.

FidoNews 10-09                 Page 4                       1 Mar 1993


2. Addresses
------------

A domain nameserver based FidoNet would use three levels of
addressing: virtual (most abstract), logical, and physical (least
abstract).


2.1 Virtual Addresses

A node has 1 or more virtual addresses, one of which is it
primary address and the others are aliases.  A virtual address is
a totally symbolic address and is formatted just like an InterNet
address:

   node.domain

where node is the node's name and domain is a domain
specification and can have any number of [sub-]* domains.  For
example, my system could have a virtual address of:

  LocksHill.DeepWoods.com.fidonet.org

The node and domain segment strings consist of letters (upper and
lower case are equivelant), digits, dash (-), underscore (_), and
dollar sign ($) characters and must begin with a letter.

Virtual addresses generally convey no geographical or routing
information.  They are intended purely for human convience
purposes - they are really little more and a node name, with some
added information.

2.2 Logical Addresses

A node can 1 or more logical addresses, although having only 1 is
preferable. A logical address is exactly an existing 3-4D
FidoNet(r) address:

Zone:Net_or_Region/Node

or

Zone:Net_or_Region/Node.Point

A logical address is used by mail packers and mail routers.  It
is the addresses exchanged in YooHoo/2U2 packets and live in the
Type-2 packet headers.

2.3 Physical Addresses

A node has exactly one physical address.  In FidoNet(r), this is
typically the telephone number assigned by the telephone company.
(It is posible that some nodes have something else as a
"physical" address, for example a point which is connected to its
bossnode via a LAN connection or a hardwired COM port.)  A
multi-line BBS typically has one line for FidoNet(r) connections
FidoNews 10-09                 Page 5                       1 Mar 1993


or multiple logical and virtual address, at least one per line.
The physical address is used by the mailer program to actually
make a connection.

3. The Domain Database
----------------------

The domain database would consist of four ASCII text files,
probably compressed:

    1) The domain table.  This text file maps between virtual
       addresses and logical addresses.  It also defines aliases
       as well and lists nameservers.

    2) The mail-exchanger table.  This text file describes the
       prefered netmail routing.  For each domain tail, it lists
       one or more node names that handle incoming mail for
       those domain tails.  This file only uses virtual
       addresses.  Its data is consulted by high-level mail
       routers, that take out-bound mail messages and combines
       them into bundles that are later packed into mail packets
       (which are routed to logical address fetched from the
       domain table).

    3) The capability file.  This file describes any extra
       services or capabilities a node might provide.  This
       includes (but is certainly not limited to):  gateway
       services (to other FTN or to non-FTN networks),
       alternitive low-level connection protocols (i.e. UUCP,
       SLIP, etc.), and file echos (SDS, SDN, etc.).  This file
       is meant as a catch-all for misc. optional information
       that might be usefull.

    4) The nodelist segment file. This file contains the mapping
       from logical address to physical address, and is in fact,
       a presnt-day NodeList file, except it is a "sparce"
       nodelist.  That is, it only describes the nodes at the
       immediate level of the nameserver and nodes at the level
       above and below the nameserver.

3.1 Format of the domain table file.
------------------------------------

The domain table file contains 1 or more lines of text.  Lines
starting with a semi-colon (;) are comments and are ignored when
this file is processd.  Each non-comment line contains two or
more fields separated by commas:

field1,field2,...,fieldN

The first field is a field type keyword.  The field types defined
are (case is not important):

FidoNews 10-09                 Page 6                       1 Mar 1993


DEFAULT,domaintail

  Defines the default domain tail to append to domain names in
the rest of the file.  Domain tail must begin with a dot (.).
Any subsequent domain names that do end in a dot will get the
specified domaintail appended before further processing.

NAMESERVER,domaintail,domain,preference

  Defines a domain server for domaintail.  Domain is the virtual
address of the server node and preference is a preference value,
a number giving a relative value when looking for a server to
contact. A higher number means this is a better node to try and a
lower number means this is a backup server.  The preference gives
a ranking for multiple servers for a given domain tail.

ALIAS,domain1,domain2

  Defines that domain1 is an alias for domain2.

ZONE,zone-number
REGION,region-number
NET,net-number

  Defines default values to use in subsequent ADDRESS lines.
Region and net lines are effectivly interchangable and are used
for documentary reasons.

ADDRESS,domain,logical-address

  Defines the logical address for domain.  The logical-address
can be missing fields.  Missing fields are supplied from prior
ZONE, REGION, and NET lines.  Node and point numbers cannot be
defaulted.

3.1.1 Sample domain table.

;; Domain table for Network 999 (N_Luna) of zone 444 (the Moon)
;; (c) Copyright 2001 Network 999
;;
;; Our default domain
Default,.N_Luna.moon.fidonet.org
;; Our zone
Zone,444
;; Our Net
Net,999
;; Our NC, Jim
Alias,N_Luna_Net,Jims_SpaceSuits
;; Our NEC, Sally
Alias,N_Luna_NEC,Sallys_Lunies
;; Our namesevers
;; Note empty domaintail - the default is used
NameServer,,N_Luna_Net,100
NameServer,,N_Luna_NEC,50
;; Out of net nameservers
;; Our Zone nameserver
FidoNews 10-09                 Page 7                       1 Mar 1993


NameServer,.moon.fidonet.org.,Moon_NS.fidonet.org.,100
;; Our IC nameserver
NameServer,.fidonet.org.,FidoNet_NS.fidonet.org.,100
;; Use the IC nameserver for non-fidonet addresses
NameServer,.,FidoNet_NS.fidonet.org.,100
;;
;;
;; Nodes
;;
Address,Jims_SpaceSuits,100
Address,Sallys_Lunies,110
Address,Moon_Rock_BBS,120
Address,Monolith_HQ,200
Address,Space1999,210
Address,LostOnTheMoon,240
Address,NorthLunaics,300
;;
;; Out of net addresses
;;
Address,Moon_NS.fidonet.org.,999/100
Address,FidoNet_NS.fidonet.org.,1:1/0
Address,naEarth_gate.moon.fidonet.org.,999/1
Address,eurEarth_gate.moon.fidonet.org.,999/2
Address,ozEarth_gate.moon.fidonet.org.,999/3
Address,saEarth_gate.moon.fidonet.org.,999/4
Address,AfricaEarth_gate.moon.fidonet.org.,999/5



Some notes about the above - the underscores (_) are part of the
names and do not indicate spaces.  The case mixing is stylistic
and is an aid to readablity.  The above is a net level domain
table. It also includes nameserver definations for higher levels,
so nodes in N_Luna net can perform address resolutions to out of
net addresses.

3.2 Format of the mail exchanger table file.
--------------------------------------------

The mail exchanger table file contains 1 or more lines of text.
Like the domain table lines starting with a semi-colon (;) are
comments and each non-comment line contains a list of three
comma-separated values:

domaintail,domain,preference

Where domaintail is a domain suffix of a posible mail address,
domain is the virtual-address of a node that handles the domain
suffix's mail, and preference is a preference value (higher
number is more prefered than a lower number).

FidoNews 10-09                 Page 8                       1 Mar 1993


3.2.1 Sample mail exchanger table file

;; Mail exchanger table for Network 999 (N_Luna)
;;                        of zone 444 (the Moon)
;; (c) Copyright 2001 Network 999
;;
;; Local mail can go via either the NC or NEC, with the NC
;; getting a higher preference
N_Luna.moon.fidonet.org,N_Luna_Net.moon.fidonet.org,100
N_Luna.moon.fidonet.org,N_Luna_NEC.moon.fidonet.org,90
;; Out of zone mail goes through the zone gates
naEarth.fidonet.org,naEarth_gate.moon.fidonet.org,50
eurEarth.fidonet.org,eurEarth_gate.moon.fidonet.org,50
ozEarth.fidonet.org,ozEarth_gate.moon.fidonet.org,50
saEarth.fidonet.org,saEarth_gate.moon.fidonet.org,50
AfricaEarth.fidonet.org,AfricaEarth_gate.moon.fidonet.org,50
JupiterNet.org,Monolith_HQ.N_Luna.moon.fidonet.org,50

Some notes about the above - undefined domain tails don't have a
defined mail exchanger - this will cause a node trying to send
such mail to do a nameserver call to get mail exchanger and any
other info needed. ( The above is probably unrealistic - a more
realistic mail exchanger table might have a default mail gateway.
And/or a zone-local inter-network nameserver.)

3.3 Capability file.
--------------------

The capability file lists virtual-address and any extra services
it might provide.  Semi-colon (;) in column one means a comment.
The non-comment lines are of the format:

virtual-address,keyword:value,keyword:value,...

Where virtual-address is a node's virtual address.  There can be
any number of lines with the same virtual-address.  The
keyword:value pairs accumulate (as if there was only one very
long line for that virtual-address).

3.3.1 Sample capability file.

;; Capability file for Network 999 (N_Luna)
;;                   of zone 444 (the Moon)
;; (c) Copyright 2001 Network 999
;;
Jims_SpaceSuits.N_Luna.moon.fidonet.org,Protcol:UUCP-Z
Jims_SpaceSuits.N_Luna.moon.fidonet.org,File:SDSURISC
Jims_SpaceSuits.N_Luna.moon.fidonet.org,File:PDNVIRTWIND
Jims_SpaceSuits.N_Luna.moon.fidonet.org,File:PDNVIRTREAL
Monolith_HQ.N_Luna.moon.fidonet.org,Protocol:X2500
Monolith_HQ.N_Luna.moon.fidonet.org,Gateway:JupiterNet.org
Space1999.N_Luna.moon.fidonet.org,File:PDNNUKEWASTE

FidoNews 10-09                 Page 9                       1 Mar 1993


3.4 The NodeList Segment File.
------------------------------

The nodelist segment file is just a FTS-0005 nodelist file,
except it is "sparce", that is, it only contains just enough info
to translate the logical addresses in the corresponding domain
table file.

4.0 Nameserver Implementation.
------------------------------

Nameservers would be implemented by using the existing
file-request methods presently in existance.  Five magic
filenames would be setup:

  DNSDTABL   - Domain table file
  DNSMXTBL   - Mail Exchanger table file
  DNSCAPAF   - Capability file
  DNSNODEL   - NodeList segment file
  DNSALL     - An archive file containing all four of the files.

All a nameserver would need to do would be to provide these five
files, probably in some sort of commonly acceptable archive
format. The real filenames should have some sort of predictable,
but unique name probably based on the level of the nameserver and
the number of the zone, region, or network the nameserver serves.

4.1 Nameserver Levels.
----------------------

Nameservers would exist at various levels:

    1) At the zone level.  The zone level nameserver(s) would
       supply information for the current zone level nodes,
       regional level nameservers, and would also have
       information about the zone level nameservers in all other
       zones.

    2) At the regional level.  The regional level nameservers
       would supply information for the current region level
       nodes (indpendent nodes), the current zone nameserver(s)
       (up level), and network level nameservers.  In some
       smaller zones, the region level *might* be skipped. The
       RC also makes the regional level domain info available to
       each of the region's independent nodes.

    3) At the network level.  The network level nameservers
       would supply information about the current network level
       nodes (regular nodes), and the current regional
       nameserver(s).  Also, the NC delivers or makes available
       the network level domain info to each of the nodes in the
FidoNews 10-09                 Page 10                      1 Mar 1993


       local network.

(If the regional level is skipped, the network nameservers would
contain entries for zone level nameservers and zone level
nameserver(s) would contain network nameserver info instead of
regional nameserver info.)

5.0 Database Updates and Management.
------------------------------------

Each node gets the network (region for independents) level info.
These updates are handled much the way nodediffs get handled at
present. The existing nodediff structure is really a generic text
file difference editor and should work for any sort of text file.
If the node needs additional info for regular connections, it is
up to the node's sysop to schedule regular file requests to the
nameservers that supply the additional info needed.  (This might
require a cascade of requests, depending on nameserver
dependencies - posibily a "make" like utility could be used to
generate the requests.) A compiled database would be a merge of
the data files a node gets from its NC (or RC for independents)
and any additional info the node fetches.

Because the information supplied at each level only relates to
that level and the levels just above and below, updates are
mostly local in nature.  There is no need to pass detailed
network level info to the RC.  All that is needed is for the NC
to pass the local info, merged with the regional nameserver info
to the network's nameservers and pass the network's nameserver
info to the RC.  Likewise the RC only needs to merge the regions
indepent node info with the network nameserver info (passed up
from the NCs) and zone level nameserver info (passed down from
the ZC) and pass this to the regional nameservers and to pass
info on the region's nameserver(s) to the NCs. Things are much
the same at the zone level, except the ZCs pass their own zone
level nameserver info to each other.  Nothing like the full
nodelist ever gets passed around.

6.0 Final Thoughts.
-------------------

This document is by no means complete. It is intended as "food
for thought".  I hope that the members of the FTSC and others
will read this and think about these ideas and maybe even setup
experimental nameservers and see how it goes.  I expect lots of
feedback.

Robert Heller
1:321/153


FidoNews 10-09                 Page 11                      1 Mar 1993


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


Published with permission from:

EFFector Online Volume 5 No. 2       2/19/1993       [email protected]
A Publication of the Electronic Frontier Foundation   ISSN 1062-9424


Happy Anniversary ;-) Steve Jackson Games Case!!

March 1st marks the three-year anniversary of the Secret Service
raid on Steve Jackson Games.  As we await Judge Sam Sparks's
decision in this precedent-setting case, EFF would like to remind
everyone of what has happened so far.

In May of 1991, EFF reported about the case in issue #1.04 of
EFFector Online:

   On March 1, 1990, the United States Secret Service nearly
   destroyed Steve Jackson Games (SJG), an award-winning
   publishing business in Austin, Texas.

   In an early morning raid with an unlawful and unconstitutional
   warrant, agents of the Secret Service conducted a search of the
   SJG office.  When they left they took a manuscript being prepared
   for publication, private electronic mail, and several computers,
   including the hardware and software of the SJG Computer Bulletin
   Board System.  Yet Jackson and his business were not only
   innocent of any crime, but never suspects in the first place.
   The raid had been staged on the unfounded suspicion that
   somewhere in Jackson's office there "might be" a document
   compromising the security of the 911 telephone system.

   In the months that followed, Jackson saw the business he had
   built up over many years dragged to the edge of bankruptcy. SJG
   was a successful and prestigious publisher of books and other
   materials used in adventure role-playing games.  Jackson also
   operated a computer bulletin board system (BBS) to communicate
   with his customers and writers and obtain feedback and
   suggestions on new gaming ideas.  The bulletin board was also the
   repository of private electronic mail belonging to several of its
   users.  This private mail was seized in the raid.  Despite
   repeated requests for the return of his manuscripts and
   equipment, the Secret Service has refused to comply fully.

   Today, more than a year after that raid, The Electronic Frontier
   Foundation, acting with SJG owner Steve Jackson, has filed a
   precedent setting civil suit against the United States Secret
   Service, Secret Service Agents Timothy Foley and Barbara Golden,
   Assistant United States Attorney William Cook, and Henry
FidoNews 10-09                 Page 12                      1 Mar 1993


   Kluepfel.

   "This is the most important case brought to date," said EFF
   general counsel Mike Godwin, "to vindicate the Constitutional
   rights of the users of computer-based communications technology.
   It will establish the Constitutional dimension of electronic
   expression.  It also will be one of the first cases that invokes
   the Electronic Communications and Privacy Act as a shield and not
   as a sword -- an act that guarantees users of this digital medium
   the same privacy protections enjoyed by those who use the
   telephone and the U.S. Mail."


As the case proceeded, the attorneys from George, Donaldson and
Ford, who represented Steve Jackson, Steve Jackson Games, and
Illuminati BBS users Elizabeth McCoy, Steffan O'Sullivan and Walter
Milliken, decided to drop charges against all defendants except the
United States Secret Service.  (This was a strategic decision made to
ensure that the trial would proceed in a timely manner.)  The case
went to trial in the United States District Court in Austin, Texas, from
January 26 - 28, 1993.  The plaintiffs presented their case first with
testimony from all of the plaintiffs themselves, Secret Service Special
Agents Timothy Foley and Barbara Golden, former U.S. District
Attorney William J. Cook, Bellcore security expert Henry Kluepfel,
University of Texas security guard Larry Coutorie, WWIV BBS
software creator Wayne Bell and a financial expert who testified to
the amount of damages.  By the end of the second day, the plaintiffs
rested their case.

On Thursday morning, the defense put Special Agent Timothy Foley
back on the witness stand.  After he testified that he did not know
that Steve Jackson Games was a publisher, that the seized computer
equipment (3 computers, 5 hard disks, and more than 300 floppies)
had not been accessed by Secret Service investigators after March
27, 1990, but was not returned to Steve Jackson until late June, and
that no copy of the information contained on the seized disks
(including a manuscript for an upcoming publication and the
company's business records) was ever provided to Steve Jackson,
Agent Foley sat through a solid 15-minute reprimand from the judge
on the unacceptability of the government's behavior.  The defense
attorneys were so shaken by the judge's admonishments that they
decided not to call any other witnesses.

While Judge Sparks made it clear that he found the Secret Service's
behavior to be reprehensible, it is not clear how he will rule in this
case.  The case was based on two rarely-construed federal statutes --
the Electronic Communications Privacy Act (ECPA) and the Privacy
Protection Act (PPA).  ECPA says that government officials may not
read private electronic mail unless they have a warrant specific to
that mail.  No search warrant specified that Elizabeth McCoy, Steffan
O'Sullivan or Walter Milliken had done any wrong, yet it appears that
their mail -- in fact, ALL of the electronic mail contained on the
system that ran the Illuminati BBS -- had been read and deleted by
agents conducting the search at Secret Service headquarters in
Chicago.  PPA requires that law enforcement officers follow special
procedures when the entity to be searched is a publisher, in order to
FidoNews 10-09                 Page 13                      1 Mar 1993


protect the First Amendment freedom of the press.  No special
procedures were followed in this case.  So even if the judge finds that
Secret Service behavior was inappropriate, it is not so clear that he
will find that the behavior was actually in violation of these statutes.

We expect Judge Sparks will hand down his decision any time now.
When it is issued, we will be sure to print the written opinion in an
upcoming issue of EFFector Online.


=============================================================

    EFFector Online is published by
    The Electronic Frontier Foundation
    666 Pennsylvania Ave., Washington, DC 20003
    Phone: +1 202 544-9237 FAX: +1 202 547 5481
    Internet Address: [email protected]





       MEMBERSHIP IN THE ELECTRONIC FRONTIER FOUNDATION

In order to continue the work already begun and to expand our efforts
and activities into other realms of the electronic frontier, we need
the financial support of individuals and organizations.

If you support our goals and our work, you can show that support by
becoming a member now. Members receive our bi-weekly electronic
newsletter, EFFector Online (if you have an electronic address that
can be reached through the Net), and special releases and other
notices on our activities.  But because we believe that support should
be freely given, you can receive these things even if you do not elect
to become a member.

Your membership/donation is fully tax deductible.

Our memberships are $20.00 per year for students, $40.00 per year for
regular members, and $100.00 per year for organizations.  You may, of
course, donate more if you wish.

Our privacy policy: The Electronic Frontier Foundation will never,
under any circumstances, sell any part of its membership list.  We
will,  from time to time, share this list with other non-profit
organizations  whose work we determine to be in line with our goals.
But with us,  member privacy is the default. This means that you must
actively grant us permission to share your name with other groups. If
you do not  grant explicit permission, we assume that you do not wish
your  membership disclosed to any group for any reason.

FidoNews 10-09                 Page 14                      1 Mar 1993


=============================================================
Mail to: The Electronic Frontier Foundation, Inc.
        238 Main St.
        Cambridge, MA 02142

I wish to become a member of the EFF.  I enclose: $_______
           $20.00 (student or low income membership)
           $40.00 (regular membership)
          $100.00 (Corporate or organizational membership.
                   This allows any organization to
                   become a member of EFF.  It allows
                   such an organization, if it wishes
                   to designate up to five individuals
                   within the organization as members.)

   [  ] I enclose an additional donation of $_______

Name:

Organization:

Address:

City or Town:

State:       Zip:      Phone: (    )             (optional)

FAX: (    )              (optional)

Email address:

I enclose a check [  ].
Please charge my membership in the amount of $
to my Mastercard [  ]  Visa [  ]  American Express [  ]

Number:

Expiration date:

Signature: ________________________________________________

Date:

I hereby grant permission to the EFF to share my name with
other non-profit groups from time to time as it deems
appropriate   [ ].
                      Initials:___________________________


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

FidoNews 10-09                 Page 15                      1 Mar 1993


From:      Doug Mclean@1:255/9

Having read the article about caller ID by Chris Farrar in Vol. 10 No.
8 of FidoNews, I thought some views from a sysop who has already
implemented caller ID security on a BBS might be helpful.

I have had caller ID security in place here for several months. Since
my modem directly supports caller ID, and since I am a programmer, the
cost of me setting this up was next to nil. The only cost at all was a
slight increase in my monthly phone bill to pay for the caller ID
feature. The software that I wrote runs on the Amiga computer (sorry
MS-Dos users!) and is freely available to anyone who wishes to file
request it (MSCID.LHA at 1:255/9). It requires TrapDoor 1.83, and DLG
Pro BBS/OS, although it could probably be adapted to run with other
software.

The effort it took to program a caller ID system and the higher phone
bill are small prices to pay when one considers the benifits that
caller ID security offers to both me as a sysop *AND* to my users.
Before I implemented caller ID security, my BBS occasionally got calls
from fake users whose only reason for calling the BBS was to leave
nasty messages to the sysop composed mostly of four letter words.
While this was not a frequent event, it was still annoying.  Most
likely, the callers were irresponsible kids with nothing better to do
with their evenings (I am *NOT* saying that all younger callers are
irresponsible or cause problems, many of my users are young, very well
behaved, and a pleasure to have as regular callers). With caller ID in
place, all I have to do is look for the annoying call in my log, and
instruct the BBS to hang up when it detects a call from that phone
number (I also get a message from the software stating that a user was
booted off because they called from a dis-allowed phone number). In my
particular implementation, several other options are available besides
simply hanging up.

Another potential annoyance is the user who calls late at night,
enters a fake phone number, and then proceeds to use a callback
verifier. Although I don't run a callback verifier, I can see how it
could easily be used to annoy innocent people in the middle of the
night. I'm sure I wouldn't appreciate a call from a BBS at 3 in the
morning generated by a fake number entered into someone callback
software! Caller ID software can eliminate this potential problem.

Imagine the supprise on the face of a bogus caller (who had planned to
do nothing more than annoy the sysop) when they were told that the
phone number that gave in their application is not the number that
they are calling from, and that the sysop will be informed of their
real number! I haven't had ANY bogus users since putting caller ID in
place. Once this type of person knows that you know who they are, they
are unwilling to risk entering a lot of messages to the sysop that
contain little more than four letter words. This is especially true of
younger callers (again, I am not trying to lump all younger callers
into one group) who fear that a quick phone call to their parents
could revoke their computer access, or worse.

FidoNews 10-09                 Page 16                      1 Mar 1993


Caller ID security offers advantages to the user as well. How many
times has a user called your BBS but is unable to remember his
password? Have you ever gotten a message from one user asking for
someone elses password because the other person has forgotten it? With
caller ID, this can be a thing of the past. My users have the option
of having the caller ID software log them into the BBS automatically,
they do not have to remember their password or (even their name) as
long as they call from their registered phone number.  Obviously,
households that have more than one computer user will not want to use
this feature, but most of my users find it a great convenience!

But before rushing ahead with caller ID security a sysop must consider
several potential problems. Not all phone lines will send caller ID
information. This is especially true in areas that are still in the
process of implenting caller ID. These numbers will show up as either
blocked or private numbers. The user has no control over this, and
until the phone company upgrades their exchange there is nothing that
they can do.

Some people have unlisted phone numbers for perfectly valid reasons.
These people usually have no objection to a sysop knowing who they are
and what their phone number is, but they do not want their number
listed in the phone book. Such a phone line will not send valid caller
ID information, so these users must be validated by some other means.

Finally, long distance calls may not send caller ID info. The caller
ID systems are different in Canada than they are in the US, so calls
to Canada from the US may show up as blocked, private, or long
distance, depending on your phone system and theirs. Long distance
calls within the same country can send a valid caller ID string, but
the exchanges on both ends must support it.  As more phone companies
upgrade their systems more phone numbers will send the required
information, but for now caller ID is rather rare on long distance
calls.

One more dis-advantage of caller ID security is that the information
is sent between the first and second rings. Calling long distance
takes longer than calling locally (depending on how that call is
routed and where you are calling, I have seen it take up to a minute
to connect on a long distance call). Some people have their modem or
software set to time out too quickly.  Since my BBS now must answer on
the second ring, occasionally when it answers there is nothing but a
dial tone because the modem on the other end didn't wait long enough.
As more and more sysops are implementing caller ID security, people
will have to allow their modems to wait a little longer for a connect,
especially on long distance calls.

Caller ID is a fairly new technology that people will have to get used
to. If every complaint about a new technology resulted in the
supression of that technology, we would all still be living in caves
eating raw food because someone would have banned fire. Caller ID can
offer benefits not only to the sysop, but the user as well. In my
experience, the only people who complain about it are the few people
that complain about everything anyway. Most of my users like the
faster and more convenient automatic login capability, and I like the
increased security. Caller ID is a good thing, and it is here to stay.
FidoNews 10-09                 Page 17                      1 Mar 1993


Doug McLean
1:255/9

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

The Youth of FidoNet, Part II
by Ryan Park (1:232/19)

    I read Isaac Salpeter's article in last week's FidoNews ("The
Youth of FidoNet") with interest.  I believed everything he said, as I
have had first- hand experience.  I am 13 and also run a BBS, the
QCC-NET BBS.  My board is not a "hacker board" and in no way reflects
my age.  When people read my bulletin about the SysOp, they don't
believe I'm 13!

    I started my bulletin board as "Da Board!" in September.  Since
December, I get 10-20 calls each day on my 17-hour BBS; many more than
other full-time BBS's in our area.

    And just like Isaac, I have had a lot of experience with
computers.  I got my first computer, a Texas Instruments 99/4A when I
was four and learned to read by reading the programming manuals.  I
learned BASIC and by the time I was six, I was writing simple
programs.  When we went on vacation and stopped at a computer store,
the owner figured I was just playing with the keyboard.  But he saw me
type RUN and saw a wonderful program with sound, colours, and more
appear!  Since then, I have written some freeware and am writing my
first "professional" program now.

    I applied for a FidoNet node in November to the hub at 1:232/400.
He turned down my request because he thought Lee Busby, net 282's NC,
would turn me down because of my age.  Obviously, I was very upset
with this.  I reviewed POLICY4 and left messages on other FidoNet
systems to the SysOps explaining this, who had no idea why I was
turned down.  Instead, I started my own network in January and have
added both FidoNet nodes as well as QWK nodes.  While it is small, it
carries echos all over our area and accomplishes what I wanted to do
in FidoNet --- start a local echo.

    After mentioning this in a number of international conferences
such as OTHERNET, I decided to reapply to net 232 in January.  Lee
Busby was very helpful and agreed to my request.  He said that the
power of the hub "got to his head" and didn't think it would happen
again as the person moved away from the area.  But I've seen this type
of behaviour once too many in FidoNet: people losing access, node
numbers, or being denied node numbers altogether because of their age.
A 14-year-old SysOp in my area applied in net 283 for a node number.
While the NC was quite helpful, other people failed to reply for
inquiries about a front door for the Amiga.  While it was just because
they didn't know of any, or they were "prejudice" against him because
of his age, no one knows.

FidoNews 10-09                 Page 18                      1 Mar 1993


    I'm not doing this to flame anyone, certainly not Lee Busby.
Instead, I think (as well as many other people) that it's time for a
major policy revision.  POLICY4 was written years ago, and POLICY5 is
needed badly for this and many other issues (namely the elections, as
Zone 1 has had a major problem democratically electing a ZC.)  There
have been so many teenagers writing Fido-News in the past requesting
fair treatment that I feel this issue should be addressed soon.  What
_are_ the rights of minorities (including age, race, and sexual
preference) in FidoNet?  Is FidoNet going to become "adults only" like
the others are?  I hope this isn't the case.  Unless the international
policies include a non-discrimination clause in them with references
to young adults also, FidoNet will be "going to the dogs".

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


Steve Mulligan 1:163/307.30

 Well, I get the point people.  Points are just glorified users.
Sure.  I'll let you have that.  As long as you realize that Private
Nodes are just glorified points.  And nodes are just glorified
Private Nodes.  I'm still not happy with the points-are-JUST-users
image but I can't do much about it.  What I have done is tried to
start a point-nodelist.

 The point-nodelist is a list of all the points and their private
net numbers.  I know there will probably be conflicting private net
numbers but that is something that we can work around.  The point-
nodelist is in no way a replacement nodelist.  It is just something
to be added when you compile your full nodelist.  I use XLAXNODE
and it has a MYLIST command which works quite nicely to do this.

eg:

MYLIST PRIVLIST.###

 To be placed in the point-nodelist, all you points have to do is
send me your bosses Private Net number, your bosses address (who
must be in the nodelist), your point number, the name of your point
system, the city the point system is located in and your name as
you want it to appear in the point-nodelist.  (Send to : Steve
Mulligan 1:163/307.30)

 I will use MAKENL (wow, and you though you had to be a ZC to use
MAKENL) every two weeks to generate an updated point-nodelist.  If
there are a lot of submissions I will increase the rate to one
week.  You can then FREQ the file from 1:163/307 with the magic
filename of PRIVLIST every Friday that it is released.

 If you have to take your point system down for a long period of
time, it is recommended that you NetMail me saying you want your
node taken out.

FidoNews 10-09                 Page 19                      1 Mar 1993


 I also need some help.  I would like to have this distributed the
same way the FidoNews and other nodelists are distributed but I
don't know how.  I also only support points from zone 1.  I'm not
an advanced MAKENL user (I'd have to be a ZC before I could call
myself that!).  So, all you points, send me all the information and
you can finally be in a nodelist!

Steve Mulligan 1:163/307.30

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


By Jason Garneau 1:325/304
H-Net (Handle-Net) Opening March 6,1993!

             /    /        /\        --------------------
            /    /        /  \      /   /           /
           /----/  ----  /    \    /   /-----      /
          /    /        /      \  /   /           /
         /    /        /        \/   ----------  /
     -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

   H-Net started out as a local message base on Online World BBS. The
purpose was to allow users on my BBS to talk with other users on my
BBS with handles instead of their legal name. This has worked out
really well on my board, but running out of a small village in
Northern Vermont, there are very few local users.
   Users started to tell me that I should make H-NeT a national echo
so they could talk with other people from around the U.S. I decided
about three or four months ago that I would give it a try. I started
advertizing H-Net in the Vermont SysOp echo, and New England SysOp
echo. Some SysOps in Vermont seemed interested, but many didn't like
the idea of their users using handles to talk with other users, and
yet others thought it would end up being a flop, and no one would use
it (99.9% of all VT echos are "dead"). I decided not to give up. I have
successfully gotten H-Net onto three other Fidonet BBS systems, and will
soon be on a Non-Fido BBS.

   For the past 3 months, H-Net has successfully worked using Fidonet
Addresses. I have had two Non-Fido BBS Sysops asking to join, but did
not want to join Fidonet due to the large and costly echos. I could
not give them H-Net access because they would first need a Fidonet
address. This is where H-Net broke away from Fidonet Addresses. H-Net
will be operating on Zone 11 by March 6th, 1993.

   H-Net is complete with it's own H-Net Policy 1.01, HNETECHO.xxx,
HNETFILE.xxx, and the HNETLIST.xxx. These files are hatched via Tick
to all nodes once a week on Fridays. This way, you can compile it at
the same time as your Fidonet Nodelist. H-Net also has it's own
H-Netmail similair to Fidonet's NETMAIL.

FidoNews 10-09                 Page 20                      1 Mar 1993


   H-Net's policy is totally Democratic. As we have been hearing,
Fidonet's South American Region has been taken over almost like a
dictator. With H-Net Policy 1.01, Elections to all positions are
required every two years or less.  If someone has become a dictator,
the individual nodes below him/her can appeal to the H-Net Court which
is ran by all of the RC's with the exception of the involved
region(s). If found guilty of breaking a policy rule, they will lose
their position, and possibly their node number (depending on how
serious the violation). This system is designed to help keep H-Net a
100% democratic network. Policy 1.01 is in effect for all Regions and
continents so all regions are equal.

    H-Net is still one of the smallest networks around. We listen to
users' opinions and are willing to please the public. We are dedicated
to making the people happy. Although this is Handle-Net, sysops with
BBS programs not supporting handles can apply, and are allowed to use
real names.

    And, for you power-hungry sysops out there: Since H-Net is just
starting out, we have hundereds of positions such as RC, REC, NC, and
NEC's to fill. So, if you are interested in becoming one of these
positions, they are on a First-come, First-serve basis. Just to show
what we have available for positions:

  Regional and Network Positions: Virginia, West Virginia, Kentucky,
Tennessee, North Carolina South Carolina, Georgia, Alabama, Florida,
Mississippi, Louisianna Arkansas, Missouri, Illinois, Indiana, Ohio,
Wisconsin, Minnesota, Iowa, Oklahoma, Texas, Kansas, Nebraska, North
Dakota, South Dakota, Montana, Wyoming, Idaho, Washington, Oregon,
California, Nevada, Alaska, Hawaii,Delaware, D.C., Maryland and all
other countries than USA.

Network Positions: Maine, New Hampshire, Massachusetts, Rhode Island,
Connecticut, New York Pennsylvania, New Jersey, Utah, Arizona, and New
Mexico.

    Well, that just about concludes this article. If you are
interested, Send the below application form crash Netmail to Jason
Garneau at 1:325/304. Call back after 48 hours, and you will receive
the latest HNETMEMB.ZIP which will always inclose the latest
HNETLIST.xxx, HNETECHO.xxx, HNETFILE.xxx, and HNETPOL.101.

-------------------------------------------------- |   H-Net -
Handle-Net Application Form Version  | |                   1.00 | |
Taken From Fidonews Elecronic Newsletter     |
|------------------------------------------------| | Name - First
_________________________    | | Name - Last _________________________
| | BBS Name ________________________________    | | Fidonet Node
Number (if one) __:____/____      | | Flags
(CM,XA,V32BIS,etc)___________________    | |
____________________________    | | Applying for (check all that
apply)            | |     ( ) NC   ( ) NEC   ( ) RC ( ) REC        | |
( ) Node ( ) Point ( ) ZC   ( ) ZC         | | ( ) Other
_____________________________    | | Mother's Maiden Name (for
Security reasons)    | | _____________________________    | | BBS
Telephone Number (___) ___-____            | |      European -
FidoNews 10-09                 Page 21                      1 Mar 1993


___________________ | | Voice/Telephone Number (___) ___-____
| |      European - ___________________            | | City, State
(Province), Country: | |           __________________________________
| | Baud Rate (Check all that apply)               | | ( ) 300    ( )
1200    ( ) 2400    ( ) 4800    | | ( ) 7200   ( ) 9600    ( ) 14400
( ) 19200 | | ( ) 38000  ( ) Other _________                 | | |
--------------------------------------------------

      If your system does not use Fidonet Netmail, Log on my BBS at
(802) 873-9443, and upload this message by entering an ASCII upload in the
full-screen message editor.

     Hope to see you online soon! - Jason Garneau
                                   (ZC-11 - H-Net)

                                   Jonathan Comtois
                                   (NC-100 - H-Net)


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


By Kevin Higgins, 1:128/74
H2H_ACS : The new Head-To-Head Air Combat Simulations Echo

I recently purchased a game which is literally THE most realistic com-
bat flight simulator for WWI/WWII/Korean War aircraft (actually, it's
not a full-fledged "game," but a Front End (FE) for a multi-player
game called Air Warrior, which is available on GEnie Information
Services. In the past I've flown most of the successive generations
of F-15/F-16 flight simulators in between eras of dabbling in WWI and
WWII simulations. Obviously, I've long been an afficianado of combat
flight simulations, and probably like most of you who share a similar
interest, have found that sooner or later (usually sooner) the computer
drones against which you're supposed to fly prove to be very limited
opponents indeed--either that, or you find out that they don't have to
fly using the same laws of physics or aircraft performance that you do
(a discovery that usually results in my tossing the game onto the
"yeah-it's-an-okay-game-but-I-don't-play-it-anymore" shelf. The fact
that I can't realistically expect a simple program to compete in the
fluid arena of ACM (Air Combat Maneuvers) against a human opponent
never seems to dampen my disappointment.

But there's another facet of many combat flight simulations that often
gets overlooked, and that's head-to-head combat--flying against your
friends (or enemies) via modem! Often, the reason this facet of the
games gets overlooked is that many of our friends, quite unreasonably,
don't share our addiction to cutting through the air in maniacal
maneuvers, getting onto another human's six (tail, for you non-fighter
pilot types) and blazing away until he and his plane are shot to doll
rags!

FidoNews 10-09                 Page 22                      1 Mar 1993


<author wipes a light sheen of sweat from his brow>

Well, I say enough of this lack of fodder--er, competition! The
H2H_ACS (Head-to-Head Air Combat Simulations) Echo is a meeting ground
for us chairborne aces where we can discuss ACM tactics and strategy
with other predatory types; where we can tell completely true <ahem>
stories of our exploits in the virtual atmospheres created for us my
MicroProse, LucasFilm Games, Electronic Arts, Konami and others; and
where we can coordinate to fly against other people foolish enough and
audacious enough believe they could last for five minutes in the air
with us before finding they were trying to pilot a smoking sieve which
suddenly has all the flight possibilities of a brick!

We will also use this echo to advertise and announce the availability
of missions (for File Request or download) we've created using those
games that include mission-building utiltities, and perhaps hold con-
tests to see who can fly some of these custom scenarios with the most
success. The possibilities are endless and we hope to explore as many
of them as possible.

Netmail or areafix Kevin Higgins, at 1:128/74, if you're interested in
joining the H2H_ACS echo. Until we can get this baby on the backbone,
I would prefer systems to poll at least twice a week.



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


A New Star Trek Echo - KLINGON
By Ray Brown, Vice-Moderator
SysOp, SpacePort Miami, 1:135/70



     "Tlhlngan Hol Dajatlh'a'?"
     ("Do you speak Klingon?")

     Greetings and salutations, fellow Trekkers/Trekkies!
I'd like to announce a new echo, called KLINGON. This echo is
for discussion of any aspect of "Klingons", the alien race, as
seen in many of the various Star Trek episodes and Movies.

    The topic of discussion will be _ALL_ things that relate to
Klingons, period. This will include, but not limited to, any
activities of the various Klingon fan organizations, such as
the Klingon Assault Group and Klingon Legion of Assault Warriors,
(KAG and KLAW), or trying to write and talk in Klingon (as in the
above example), or just to learn more about the Klingon "way of
life" (grin). Rembember, bashing or flaming the United Federation
of Planets, or members of "Federation" Star Trek fan orgainzations,
is really frowned on. (Remember, we'll be ALLIES with the Federation
in the 24th Century.)

FidoNews 10-09                 Page 23                      1 Mar 1993


    This new echo is currently seen on over 12 BBS's that are
members of TrekNet (Z87). However, this echo is available to any
and all that are interested in the Klingon way of thinking. <g>
For linking information, please contact me via NetMail, and I'll
see if there's a BBS near you that's carrying KLINGON. Or, you
may wish to have mail on HOLD here at 1:135/70 for you to pick up.

    If the number of BBS's and activity picks up, we will strongly
consider requesting that KLINGON be placed on the FidoNet BackBone.

    Qapla!! (Success!!)


               Scott Kuhr                Ray Brown
               Moderator                 Vice-Moderator
               1:363/91                  1:135/70



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


TWO NEW BLINDNESS-RELATED ECHOS NOW AVAILABLE
by David Andrews, Fidonet 1:261/1125

    Two new blindness-related Echos are now available via the
Fidonet Zone 1 backbone.  Both of these Echos, NFB Talk and Blind
Talk, have been started by the National Federation of the Blind
(NFB).  The NFB is the oldest and largest organization of the
blind in this country with over 50,000 members.  There are state
affiliates and local chapters in all 50 states, Puerto Rico, and
the District of Columbia.  Founded in 1940, the NFB is dedicated
to the complete integration of the blind into the economic,
political, and social community.

    NFB Talk is for the dissemination of news and information
about the NFB and its activities.  It is also intended for the
discussion of NFB's philosophy of blindness and topics of
specific interest to members of the National Federation of the
Blind and our friends as they relate to the NFB, our policies,
activities, and philosophy.

    Blind Talk is for the discussion of general topics of
interest to blind and visually impaired persons, our friends and
relatives, and anyone else who is interested.  Possible topics
include, but are not limited to, computers and adaptive access
technology, Braille and Braille literacy, cane travel, guide
dogs, alternative techniques of  blindness, etc.  This Echo is
intended to promote the positive philosophy of blindness
developed and promoted by the National Federation of the Blind.
Blind Talk also provides access to the resources and information
provided by the International Braille and Technology Center for
the Blind, the world's largest demonstration and evaluation
center for computer technology used by blind persons.

FidoNews 10-09                 Page 24                      1 Mar 1993


    NFB Talk and Blind Talk originate at 1:261/1125, NFB NET,
the bulletin board sponsored by the National Federation of the
Blind.  NFB NET, which can be reached at (410) 752-5011, contains
a variety of files of interest to blind computer users.  There
are also a variety of materials concerning the Americans with
Disabilities  Act (ADA).  NFB NET is also the home of the Braille
Monitor, the monthly publication of the National Federation of
the Blind, Future Reflections, for parents of blind children, and
the newsletter of the NFB in Computer Science.  All of these
publications are available in electronic form and can be file
requested from 1:261/1125 using the magic file names MONITOR,
KIDS and COMPUTERS respectively.

    You can request NFB Talk and Blind Talk from your regular
Echo source.  The Echo Tags are NFB-TALK and BLINDTLK.  If you
have questions, please contact the Moderator, David Andrews, at
Fidonet 1:261/1125.

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

FidoNews 10-09                 Page 25                      1 Mar 1993


======================================================================
                        FIDONEWS INFORMATION
======================================================================

------- FIDONEWS MASTHEAD AND CONTACT INFORMATION ----------------

Editors: Tom Jennings, Tim Pozar
Editors Emeritii: Thom Henderson, Dale Lovell, Vince Perriello

IMPORTANT NOTE: The FidoNet address of the FidoNews BBS has been
changed!!! Please make a note of this.

"FidoNews" BBS
   FidoNet  1:1/23                     <---- NEW ADDRESS!!!!
   Internet  [email protected]
   BBS  +1-415-863-2739,  300/1200/2400/16800/V.32bis/Zyxel

(Postal Service mailing address) (have extreme patience)
   FidoNews
   c/o World Power Systems             <---- don't forget this
   Box 77731
   San Francisco
   CA 94107 USA

Published weekly by and for the members of the FidoNet international
amateur electronic mail system. It is a compilation of individual
articles contributed by their authors or their authorized agents. The
contribution of articles to this compilation does not diminish the
rights of the authors. Opinions expressed in these articles are those
of the authors and not necessarily those of FidoNews.

Authors retain copyright on individual works; otherwise FidoNews is
copyright 1992 Tom Jennings. All rights reserved.  Duplication and/or
distribution permitted for noncommercial purposes only. For use in
other circumstances, please contact the original authors, or FidoNews
(we're easy).


OBTAINING COPIES: The-most-recent-issue-ONLY of FidoNews in electronic
form may be obtained from the FidoNews BBS via manual download or
Wazoo FileRequest, or from various sites in the FidoNet and Internet.
PRINTED COPIES may be obtained from Fido Software for $10.00US each
PostPaid First Class within North America, or $13.00US elsewhere,
mailed Air Mail. (US funds drawn upon a US bank only.)

BACK ISSUES: Available from FidoNet nodes 1:102/138, 1:216/21,
1:125/1212, (and probably others), via filerequest or download
(consult a recent nodelist for phone numbers).

A very nice index to the Tables of Contents to all FidoNews volumes
can be filerequested from 1:396/1 or 1:216/21. The name(s) to request
are FNEWSxTC.ZIP, where 'x' is the volume number; 1=1984, 2=1985...
through 8=1991.

FidoNews 10-09                 Page 26                      1 Mar 1993


INTERNET USERS: FidoNews is available via FTP from ftp.ieee.org, in
directory ~ftp/pub/fidonet/fidonews. If you have questions regarding
FidoNet, please direct them to [email protected], not the
FidoNews BBS. (Be kind and patient; David Deitch is generously
volunteering to handle FidoNet/Internet questions.)

SUBMISSIONS: You are encouraged to submit articles for publication in
FidoNews. Article submission requirements are contained in the file
ARTSPEC.DOC, available from the FidoNews BBS, or Wazoo filerequestable
from 1:1/23 as file "ARTSPEC.DOC". Please read it.



"Fido", "FidoNet" and the dog-with-diskette are U.S. registered
trademarks of Tom Jennings, Box 77731, San Francisco CA 94107, USA and
are used with permission.



   Asked what he thought of Western civilization,
   M.K. Gandhi said, "I think it would be an excellent idea".

-- END

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