985 lines
50 KiB
Plaintext
985 lines
50 KiB
Plaintext
|
|
__
|
|
The World's First / \ New-Sysop
|
|
BBS Network /|oo \ Orientation
|
|
* FidoNet * (_| /_) Information
|
|
_`@/_ \ _
|
|
| | \ \\ published by IFNA
|
|
| (*) | \ ))
|
|
______ |__U__| / \// (International FidoNet
|
|
/ Fido \ _//|| _\ / Association)
|
|
(________) (_/(_|(____/ (tm)
|
|
Steve Bonine (115/777)
|
|
editor
|
|
|
|
Version 1.1
|
|
2/22/88
|
|
|
|
Copyright (c) 1987, International FidoNet Association. All rights reserved.
|
|
May be freely copied and distributed for noncommercial purposes.
|
|
|
|
Fido(tm) is a trademark of Tom Jennings.
|
|
FidoNet(R) is a registered trademark of Tom Jennings.
|
|
The ASCII dog-with-diskette is a trademark of IFNA.
|
|
|
|
The purpose of this little treatise is to provide introductory information for
|
|
persons who are interested in starting a computer bulletin board system or
|
|
connecting an existing system with FidoNet. In this one document you will find
|
|
an introduction to many different aspects of running a bulletin board and
|
|
information on where to go for more information in those cases where the
|
|
introduction sounds interesting.
|
|
|
|
This document is distributed under the auspices of IFNA, the International
|
|
FidoNet Association. IFNA's chief responsibility is the maintenance and
|
|
administration of the network which forms the backbone of this collection of
|
|
diverse bulletin board systems. Part of this job involves orientation of new
|
|
members of the network. The growth and health of FidoNet speaks well of the
|
|
ability of the systems and the operators of those systems to work together, and
|
|
you can't work together if you don't know the ground rules.
|
|
|
|
Introduction to FidoNet
|
|
------------ -- -------
|
|
|
|
The network is a loose coalition of many different bulletin board systems.
|
|
"FidoNet" and "Fido" are registered trademarks of Tom Jennings; a formal
|
|
agreement allows IFNA to use these in the name of the organization. The
|
|
network is by no means limited to the Fido software; there are several "FidoNet
|
|
compatible" systems which interface with the network. By joining, you as a
|
|
sysop can take advantage of the expertise of thousands of other users.
|
|
|
|
A short history lesson will help in understanding FidoNet. Tom Jennings was in
|
|
San Francisco, and John Madill was in Baltimore, both working on the Fido BBS
|
|
software. In the spirit of finding out if it could be done, they decided to
|
|
add code to the system to support a dialup connection with no human interven-
|
|
tion during the wee hours when the sysops were sleeping and the systems were
|
|
free. This quickly became a useful function, since both systems and both
|
|
sysops were busy and it was a convenient method of exchanging information.
|
|
|
|
From this chance beginning in May 1984, growth was phenomenal. By August 1984,
|
|
there were 30 nodes; by September there were 50. By February 1985, there were
|
|
160 systems, and a group of sysops in St. Louis had taken over the administra-
|
|
tion of the list of systems. In June 1985 the network converted to the
|
|
currently-used two-part addressing scheme to support the growth. As this is
|
|
written in late 1987, the size of the network has passed 2000 nodes and change
|
|
continues with a zone-based nodelist to facilitate communication with systems
|
|
overseas. But we get ahead of the story . . .
|
|
|
|
Network Organization
|
|
------- ------------
|
|
|
|
Today's network is organized into geographical divisions of zones, regions,
|
|
networks, individual systems, and points. A zone is a very large division;
|
|
zone 1 is North America, zone 2 is Europe, and zone 3 is Australia, New
|
|
Zealand, etc. Of more interest are regions, networks, and points.
|
|
|
|
North America is divided into regions. For example, the central region, region
|
|
11, includes Illinois, Indiana, Kentucky, Michigan, Ohio, and Wisconsin.
|
|
Regions are assigned 2-digit numbers to differentiate them from networks.
|
|
|
|
Regions are further broken down into networks. A network usually covers a
|
|
rather small geographic area, such as a metropolitan area. Chicagoland is
|
|
network 115.
|
|
|
|
Individual systems are assigned a node number within the appropriate network or
|
|
directly within the region if no network covers that specific location.
|
|
|
|
A point is a usually a one-person BBS.
|
|
|
|
There is an analogy with telephone numbers. Think of the zone as the country
|
|
code, the network as the area code, the node number as the telephone number,
|
|
and the point as an extension for the individual. This is written as
|
|
zone:network/node.point. For example, Chicago is covered by network 115, and
|
|
is in zone 1. The specific BBS which has been assigned node 100 in the Chicago
|
|
network would be 1:115/100. If there were point systems served by this BBS,
|
|
they would be 1:115/100.1, 1:115/100.2, and so on.
|
|
|
|
The purposes of this organization are twofold. First, decentralization means
|
|
that no one person has the task of administering the entire network. Since it
|
|
is a volunteer and amateur operation and such an assignment would be a big job,
|
|
it became obvious early in the life of FidoNet that decentralization was
|
|
necessary to support growth of the network.
|
|
|
|
The second reason for such a hierarchy is to improve the flow of mail. One
|
|
system in each network takes on the responsibility of Network Co-ordinator, and
|
|
that BBS becomes node zero in the network. One of the tasks of the Network Co-
|
|
ordinator is to forward incoming mail. Thus, if I have ten messages for
|
|
different systems in the Chicagoland network, I need to make not ten telephone
|
|
calls but only one -- to system 115/0, which is the NC for Chicagoland. The
|
|
mailer software automatically routes messages for nodes in network 115 to
|
|
115/0, saving me money and making the network work better.
|
|
|
|
The Nodelist and FidoNews
|
|
--- -------- --- --------
|
|
|
|
All of this is held together by two documents, each published weekly. One of
|
|
these is a list of every system in the network, with network/node address,
|
|
telephone number, and other useful information; this is called the NODELIST.
|
|
The other document is a newsletter, FidoNews. Both the nodelist changes and
|
|
FidoNews are distributed using the network; once your system is up and running
|
|
you will have a source for the most current information.
|
|
|
|
What's in it for Me?
|
|
------ -- -- --- --
|
|
|
|
This is all well and good, but other than the thrill of being a part of all
|
|
this exciting technology, what good is FidoNet to the average sysop? Through
|
|
the magic of echomail, your system can have thousands of callers a day, posting
|
|
messages, asking questions, and receiving answers. This use of the network has
|
|
eclipsed the original sysop-to-sysop communication, although this is still a
|
|
strong motivation, especially when used to exchange data and/or programs. More
|
|
about echomail later.
|
|
|
|
What Must I Do?
|
|
---- ---- - --
|
|
|
|
There are really only two rules to follow to be a part of the network. The
|
|
first is that your BBS system must be "FidoNet compatible" and able to receive
|
|
network messages during one hour each day. The second is that you must not
|
|
unduly annoy other members of the network, or yourself be unduly annoyed. Like
|
|
a large family, the members of the network must all learn to live together, if
|
|
not in perfect harmony, at least working together.
|
|
|
|
A formal policy document exists which states in more detail the expectations
|
|
of systems as members of the network. It should be available from the same
|
|
source where you found this document; for example, as an additional file in the
|
|
ARC or an additional file in the download area where you found this. Look for
|
|
POLICYx.ARC.
|
|
|
|
How do I join FidoNet?
|
|
--- -- - ---- -------
|
|
|
|
If you live in an area covered by a network, you will normally join that net-
|
|
work; if your geographic area is not covered by a network then you can join the
|
|
region as an independent system.
|
|
|
|
The method for becoming a part of the network is described in the policy
|
|
document mentioned above. It involves actually using your BBS to send a
|
|
message to the network co-ordinator. This insures that you have a working
|
|
system, providing an important cross-check on your request. (This became
|
|
important early in the history of the network as wrong numbers crept into the
|
|
nodelist. Imagine explaining to someone why their telephone rang dozens of
|
|
times between 3 and 4 AM, with no one on the other end when they answered it.)
|
|
|
|
Many networks have a document available to prospective members which
|
|
supplements the Policy document and contains local requirements. The best
|
|
course of action is to find a BBS in your area and quiz the sysop on local
|
|
procedures. Failing this, find a nodelist (see below) and send a message to
|
|
the General Help node listed in Region 1.
|
|
|
|
The Nodelist
|
|
--- --------
|
|
|
|
Perhaps the single most-important file on your system is the nodelist. From
|
|
it, your system obtains the information necessary to communicate with other
|
|
systems, be they across the street or in another country.
|
|
|
|
The most basic format of nodelist is described by the FidoNet Technical
|
|
Standards Committee (FTSC) and is generally called the "St. Louis format"
|
|
nodelist. If you find a file named NODELIST.nnn, where nnn is a number, that
|
|
is an FTSC nodelist. The number is the date associated with the nodelist; for
|
|
example, NODELIST.275 was issued on day 275. Nodelists are often ARC'ed;
|
|
NODELIST.A75 is the ARC'ed version of NODELIST.275. (No, Virginia, all ARC
|
|
files don't end with .ARC.) FTSC nodelists (which no longer come from St.
|
|
Louis) are issued each Friday.
|
|
|
|
The FTSC nodelist contains information on every BBS in the network. Luckily,
|
|
it is rare that you will need to transmit or receive an entire nodelist.
|
|
CHANGES are distributed each week in a file named NODEDIFF.nnn. For example,
|
|
let's say that you are running with NODELIST.267. When the next nodelist is
|
|
ready, you will obtain a file named NODEDIFF.275. When you run the XLATLIST
|
|
program (see below) it will automatically apply the changes in the nodediff
|
|
file, and as if by magic you will have NODELIST.275 on your system.
|
|
|
|
Here is an excerpt from NODELIST.275 which illustrates the FTSC format:
|
|
|
|
Host,115,Chicagoland,Homewood_IL,Rick_Moore,1-312-799-4790,2400,#CM:
|
|
,333,Solar_Wind,Homewood_IL,Rick_Moore,1-312-799-4790,2400,#CM:
|
|
,500,Sit_UBU_Sit_HST,Skokie_IL,Henry_Senk,1-312-982-5092,9600,#CM:
|
|
,108,Samson,Arlington_Heights_IL,Larry_Miglore,1-312-394-0071,2400,
|
|
Down,123,Chicago_DECUS,Elk_Grove_IL,Chuck_Garrett,1-312-640-5667,1200,
|
|
,640,Computer_Guild,Elk_Grove_IL,Dick_Sonka,1-312-640-7980,2400,RE:
|
|
|
|
This is part of the definition of network 115 ("Host,115"). The network co-
|
|
ordinator is listed first, and becomes node zero in the network. After that,
|
|
individual nodes are listed. Notice that 115/333 is really the same BBS as
|
|
115/0. System 115/123 has been marked in the nodelist as "down", which gives
|
|
other systems notice that it is unavailable.
|
|
|
|
The FTSC nodelist is the only file which is consistent throughout FidoNet.
|
|
Virtually all systems process this file into other forms before it is actually
|
|
used by the BBS software. In the interest of attempting to clarify, the
|
|
current process for MS-DOS will now be described. If your system does not use
|
|
this method, don't let the explanation confuse you -- instead consider it an
|
|
example of nodelist processing.
|
|
|
|
For most systems, the next flavor of nodelist is NODELIST.BBS. This one is
|
|
similar to the FTSC format, but some of the information is dropped (name of
|
|
sysop, for example), and some is customized (for example 1-312 in the telephone
|
|
number could be removed if you are in area-code 312). NODELIST.BBS is created
|
|
by a program named XLATLIST. This program and its documentation are usually
|
|
found in a file named XLATRGEN.ARC. (Another program in the same ARC file is
|
|
ROUTEGEN. XLATRGEN=XLATlist+RouteGEN. ROUTEGEN will not be discussed here; if
|
|
you choose to use it read the documentation carefully.) Input to XLATLIST is
|
|
the FTSC nodelist, optionally a nodediff file containing changes for the week,
|
|
and a control file, XLATLIST.CTL. The control file specifies options like
|
|
telephone-number customization and how much you want to charge your users to
|
|
send mail to various locations.
|
|
|
|
Here is an example of the same segment of the nodelist as it might appear in
|
|
NODELIST.BBS:
|
|
|
|
HOST 115 0 2400 Chicagoland 9-799-4790 Homewood_IL
|
|
333 0 2400 Solar_Wind 9-799-4790 Homewood_IL
|
|
500 0 9600 Sit_UBU_Sit_HST 9-982-5092 Skokie_IL
|
|
108 0 2400 Samson 9-394-0071 Arlington_Heights_IL
|
|
640 0 2400 Computer_Guild 9-640-7980 Elk_Grove_IL
|
|
|
|
Notice that the sysop name is not included and the format is slightly
|
|
different. The telephone number has been "customized" based upon the
|
|
XLATLIST.CTL file -- this system needs to prefix local numbers with a "9".
|
|
The zero after the node number is the cost of calling that system; these are
|
|
free calls for the example system. The system marked "down" in the FTSC
|
|
nodelist was not included in NODELIST.BBS.
|
|
|
|
The last flavor of nodelist is created from NODELIST.BBS by your BBS software,
|
|
and is specific to the system (Opus, SEAdog, etc.). This step is called
|
|
"compiling" the nodelist. Its exact implementation varies with the type of BBS
|
|
software, but usually there is a program similar to XLATLIST which takes
|
|
NODELIST.BBS as its input and creates internal files used by the BBS while it
|
|
is running. For example, Opus has a program named OPUSNODE.EXE which creates
|
|
NODELIST.SYS and NODELIST.IDX. During actual execution, Opus uses these files
|
|
to look up information on network addresses.
|
|
|
|
Finally, a real-life example from my system, running Opus with an address of
|
|
1:115/777. The current nodelist is NODELIST.268. On Saturday I receive from
|
|
my network co-ordinator a file named NODEDIFF.A75 which when un-ARC'ed becomes
|
|
NODEDIFF.275. Being a conscientious sysop who knows that maintaining a current
|
|
nodelist is one of the requirements of FidoNet policy (and also not wanting to
|
|
jangle someones telephone at 0400) I will update the nodelist. I have a file
|
|
named XLATLIST.CTL which looks like this:
|
|
|
|
node 1:115/777
|
|
seadog
|
|
nocomments
|
|
DIAL
|
|
1-312- ;
|
|
;
|
|
END
|
|
cost 0 0
|
|
1-312 0
|
|
end
|
|
|
|
This is a simple control file which tells XLATLIST I am node 1:115/777, that I
|
|
want a SEAdog-format NODELIST.BBS, that I don't want to see the comments in the
|
|
nodelist, that the text "1-312" should be removed from telephone numbers, and
|
|
that the cost for all calls is zero.
|
|
|
|
After un-ARCing the NODEDIFF, I execute XLATLIST.EXE. Its input is
|
|
NODELIST.268, NODEDIFF.275, and XLATLIST.CTL. Its output is a short summary on
|
|
the screen, NODELIST.275, and NODELIST.BBS.
|
|
|
|
Now I execute the command "OPUSNODE -f". This creates Opus' internal-format
|
|
nodelist files. And that's it. Next week, I'll receive a file named
|
|
NODEDIFF.282 and repeat the process. Very painless, actually.
|
|
|
|
|
|
Which BBS System is the Best?
|
|
----- --- ------ -- --- ----
|
|
|
|
You will find no answer to that question here, as each sysop has good reasons
|
|
for choosing a particular system. You must decide for yourself, based upon what
|
|
you observe as a user of the system and what you may be able to find out from
|
|
sysops of that particular type of system. A quick overview of the various
|
|
types of software available will be provided here, and even that is done with
|
|
fear and trembling, since new versions and new products are upon us always.
|
|
|
|
There are two distinct components required for a FidoNet BBS: the part that
|
|
interfaces with the NETWORK (which we'll call the MAILER) and the part which
|
|
interfaces with the USER (which we'll call the BBS). Some products contain
|
|
both of these functions (Fido, Opus), some contain only the BBS portion (TBBS,
|
|
RBBS), and some contain only the mailer function (SEAdog, Dutchie,
|
|
BinkleyTerm). This provides the flexibility to interface existing BBS products
|
|
such as TBBS and RBBS to the network.
|
|
|
|
Specific information on how to obtain the systems is provided at the end of
|
|
this document.
|
|
|
|
Full-Function: BBS and Mailer
|
|
-------------- --- --- ------
|
|
|
|
Fido: This is where it started. Fido version 11 is copyrighted software which
|
|
may be used for free if the use meets certain conditions (free access and non-
|
|
commercial are two). Fido version 12 is a commercial product with a list
|
|
price of $175, available to IFNA members for $100. Fido version 12 has several
|
|
new features, including the ability to receive network mail any time and
|
|
locks/keys for message areas. An echomail conference exists for Fido support.
|
|
|
|
Opus: A more recent entry in the Fido-compatible BBS field is Opus. This BBS
|
|
is copyrighted software which is free to users who observe the restrictions of
|
|
the license, and from the caller's perspective behaves much the same as Fido;
|
|
this makes the conversion from Fido to Opus easy for the caller. For the
|
|
sysop, the conversion is also easy as Opus supports the user list, file areas,
|
|
and messages from Fido. However, from the sysop perspective, Opus is
|
|
significantly different from Fido, more flexible, and supports 24-hour mail.
|
|
Several echomail conferences exist devoted to Opus support.
|
|
|
|
BBS-function (User Interface) Only
|
|
------------ ----- ---------- ----
|
|
|
|
TBBS: In the opinion of many, this system is the premier BBS. It costs
|
|
$299.95, plus $99.95 for SEAdog to handle network mail. (Note: Because of the
|
|
method used to package the extension to TBBS for network operation, it is not
|
|
possible to order SEAdog through IFNA and TBBS from the vendor. The TBBS mail
|
|
processors and SEAdog are bundled together.) TBBS is a very flexible system
|
|
from the sysop perspective and very easy to use for callers. TBBS will even
|
|
support a multi-line and online chat option if you want to get fancy. An
|
|
echomail conference exists for TBBS sysops.
|
|
|
|
QBBS: A shareware clone of TBBS, this BBS combines much of the flexibility of
|
|
TBBS with the economy of a shareware product ($25 registration). It requires a
|
|
mailer front end to interface with the network; BinkleyTerm works nicely for
|
|
this purpose. It can use outboard echomail processing (e.g. ConfMail) or
|
|
integral echomail utilities. A QBBS echomail conference exists.
|
|
|
|
RBBS: A recent entry in the FidoNet arena by virtue of interfacing an existing
|
|
BBS how to a mailer. RBBS uses a separate mailer system to interface with
|
|
FidoNet and a program written by Bob Westcott (132/114) to convert netmail-
|
|
style messages into the RBBS message base. RBBS is public domain, available
|
|
from most sysops which run it.
|
|
|
|
PCBoard: There is now a Door written by Peter Vernaglia (101/149) that lets
|
|
PCBoard V11 or V12 be FidoNet compatible by using SEAdog or BinkleyTerm.
|
|
PCBoard is a commercial BBS that must be purchased from the author, Fred Clark.
|
|
The version that supports Doors costs $120. PCBoard's main features are that
|
|
any file can be downloaded from the main menu, it can be networked to support
|
|
multiple phone lines and is very easy to set up and maintain.
|
|
|
|
Mail-function (Network Interface) Only
|
|
------------- -------- ---------- ----
|
|
|
|
There are two options when using a separate mailer system. The mailer can
|
|
answer the phone and, if it detects a human caller, load the BBS. Or the
|
|
mailer can be run only during specific time periods, such as during National
|
|
Mail Hour, to send and receive network messages. With the first option, the
|
|
system is able to receive network mail at any time, but callers are slightly
|
|
inconvenienced by waiting for the BBS to load. With the second, network
|
|
interface is limited to the specific time period. The best choice for an
|
|
individual system depends upon whether it is primarily human-caller oriented or
|
|
primarily FidoNet-mail oriented.
|
|
|
|
SEAdog: SEAdog began its life as a commercial mail system for standalone use.
|
|
It became popular in FidoNet as an improved mail processor for Fido version 11.
|
|
SEAdog is a commercial product of System Enhancement Associates, costing $100;
|
|
it is available to members of IFNA for $60. A SEAdog echomail conference
|
|
exists to provide support for those who obtain the product thru the IFNA offer.
|
|
|
|
DUTCHIE: Dutchie began its life in FidoNet as the first system designed
|
|
specifically to operate as a point, but has since grown to a full FidoNet mail
|
|
system similar to SEAdog, but with a more amateur user oriented interface and
|
|
setup. Unlike SEAdog, Dutchie is free to non-commercial users.
|
|
|
|
BinkleyTerm: This package can be used as a mailer for a BBS, as a terminal
|
|
program, or to support a point system. It is copyrighted code, distributed
|
|
with source code with no charge for use in noncommercial applications. The
|
|
authors request recognition for their work, which may take the form of a simple
|
|
"thank you", a post card, or best of all, helpful hints on special applications
|
|
or new utilities. A BinkleyTerm echomail conference exists for support
|
|
questions.
|
|
|
|
EchoMail: What is it?
|
|
-------- ---- -- --
|
|
|
|
For many sysops, echomail is the primary reason to hook up to FidoNet. It
|
|
provides the opportunity to share information with large numbers of callers on
|
|
other BBS's which may be in other parts of the world. This is a particularly
|
|
important advantage for those BBS's which do not have large numbers of local
|
|
callers, or for those subjects in which the interest level on any particular
|
|
BBS is low.
|
|
|
|
The concept of echomail operation is simple. A group of systems decides to
|
|
form a conference on some topic. Each of them sets aside a message area on the
|
|
local BBS. Then any message posted on one board is automatically echoed to all
|
|
the other systems. Functionally, it is as if all the participants were dialing
|
|
into the same local BBS.
|
|
|
|
This concept was invented in late 1985 by Jeff Rush, a sysop in Dallas. Growth
|
|
since then has been phenomenal, with network volume associated with echomail
|
|
eclipsing person-to-person volume. Conferences exist today on hundreds of
|
|
topics with more being started every week. Computer/technical topics are
|
|
covered (programming, general-technical, mainframe) as well as non-computer
|
|
topics (debate, Bible, music, disABLED, humor), providing every sysop with a
|
|
wide variety of interesting conferences, even in subject areas that have
|
|
limited local expertise.
|
|
|
|
The advantages of echomail are obvious, but it has a few disadvantages. In
|
|
most cases, the sysop pays telephone charges to obtain echomail; the routing
|
|
discussed above is not used for echomail because of the volume involved.
|
|
Connecting to other systems to obtain the conferences can be a headache,
|
|
depending upon how well the local network has organized echomail. There are
|
|
delays in response which take some getting used to, and there can be "too much
|
|
of a good thing" with active conferences averaging in excess of 100 messages a
|
|
day. Like anything, echomail is best taken in moderation, and the sysop must
|
|
use good judgement. For example, an attempt to maintain 50 echomail
|
|
conferences with a 10-meg hard drive is doomed to failure.
|
|
|
|
Operation of EchoMail
|
|
--------- -- --------
|
|
|
|
Various echomail utilities are used to move the messages between the mail area
|
|
and the message area. The words used to describe the operation of these
|
|
utilities are different with the different BBS software, but the same functions
|
|
are performed in all cases. A summary of processing using several popular
|
|
packages is provided after the "generic" explanation.
|
|
|
|
Several fields within the message are used to control this process. Some of
|
|
these fields may be invisible, depending upon the type of software and
|
|
parameters specified when it was installed.
|
|
|
|
There are two basic functions required to support echomail. Messages posted by
|
|
local users must be sent to all the other systems participating in the
|
|
conference; we'll call that EXPORT here. Messages arriving from other systems
|
|
must be placed where the users can see them; we'll call that IMPORT here. The
|
|
import/export process is controlled by information within the message itself,
|
|
and the utilities use a control file named AREAS.BBS or ECHO.CTL.
|
|
|
|
The first line of each echomail message, when it is sent through the network,
|
|
is AREA:something. The "something" is what determines into which area the
|
|
message will be placed. A file named AREAS.BBS or ECHO.CTL controls the
|
|
correspondence between this field and the BBS area; in other words,
|
|
AREA:MAINFRAME might correspond to area 12 on your BBS and area 3 on mine.
|
|
|
|
Near the end of each message is a SEEN-BY line. This is the control field
|
|
which is used to determine which system(s) have not yet seen the message.
|
|
Again, AREAS.BBS or ECHO.CTL lists which systems see messages, based upon the
|
|
AREA:something.
|
|
|
|
The last piece of control information in the message is the Origin line, near
|
|
the end of the message, which is placed there during the export process. This
|
|
is primarily for us humans to know from which system the message originated; it
|
|
is not used in routine operation of the echomail utilities.
|
|
|
|
A few examples may make this easier to understand. The syntax of the ConfMail
|
|
product is used in the examples, but consider them generic to the echomail
|
|
process, rather than specific to one product.
|
|
|
|
Assume that the following line exists in AREAS.BBS:
|
|
|
|
c:\msg\mframe MAINFRAME 115/123 115/234
|
|
|
|
which defines the message area corresponding to the conference with
|
|
AREA:MAINFRAME to be subdirectory c:\msg\mframe, and defines systems 115/123
|
|
and 115/234 as recipients of this conference. Also assume that this is system
|
|
115/777.
|
|
|
|
Example 1:
|
|
A user on this board (115/777) posts a new message in the area.
|
|
|
|
The export process will find no SEEN-BY line at the end of the message. It
|
|
will add a SEEN-BY line to the existing message which reads
|
|
SEEN-BY 115/123 234 777
|
|
It will also add an Origin line to the existing message. Then that message
|
|
will be sent to systems 115/123 and 115/234.
|
|
|
|
Example 2:
|
|
A incoming netmail message has as its first line AREA:MAINFRAME, and it's SEEN-
|
|
BY line lists 115/123 and 115/777.
|
|
|
|
IMPORT moves the message into the MAINFRAME message subdirectory,
|
|
c:\msg\mframe. The first line, AREA:MAINFRAME, is removed.
|
|
|
|
When EXPORT runs, it compares the SEEN-BY line with AREAS.BBS and discovers
|
|
that the message has not been seen by 115/234. A copy is sent to 115/234 via
|
|
netmail. (The copy sent to 115/234 will have AREA:MAINFRAME as its first
|
|
line.) The SEEN-BY line in the message in the local area is also updated to
|
|
indicate that the message has been sent to 115/234.
|
|
|
|
Echomail Terms
|
|
-------- -----
|
|
|
|
One thing that makes echomail difficult for many people is that each echomail
|
|
processor uses different words to describe the same thing. The discussion
|
|
above used the vocabulary of Bob Hartman's popular ConfMail system. Messages
|
|
are IMPORTED from the netmail area into the actual conference, and EXPORTED
|
|
from the conference to the netmail area. Other products are available to
|
|
process echomail: Jeff Rush's original utilities, Opus, TBBS, and MGM.
|
|
|
|
ARCMAIL is a utility normally used in connection with echomail processing,
|
|
although its application is not limited to echomail. Early in the life of
|
|
echomail, it became obvious that thousands of messages sent as normal network
|
|
mail were causing problems. To address this problem, Thom Henderson at SEA
|
|
provided the ARCMAIL utility. ARCMAIL searches through the netmail area and
|
|
finds all messages which are to be sent to a system and packs all these
|
|
messages into one ARC file. It then deletes these messages from the netmail
|
|
area and creates one message to that system, with the ARC file attached. This
|
|
saves significant connect time for the systems involved, and provides the side
|
|
benefit that a point-to-point routing will be used since the message has a file
|
|
attached. Of course, ARCMAIL also provides the function of expanding the ARC
|
|
file into netmail messages at the receiving system; if you receive a funny-
|
|
looking file attached to a null message, chances are it is an ARCmail file.
|
|
ConfMail has the ARCmail function integrated; in other systems it is a separate
|
|
step.
|
|
|
|
The original Jeff Rush echomail utilities used the terms TOSS and SCAN --
|
|
messages were TOSSED from netmail into the conference, and the conferences were
|
|
SCANNED, creating the outgoing messages in the netmail area.
|
|
|
|
Opus uses the Jeff Rush terms -- scanning and tossing can be done automatically
|
|
by the Opus system, or an external processor like ConfMail can be used. There
|
|
are restrictions on what Opus' internal scan/toss mechanism can handle, but
|
|
these restrictions will not affect the casual sysop -- only the active echomail
|
|
hub.
|
|
|
|
MGM also uses the Jeff Rush terms. Its operation is similar to the original
|
|
echomail utilities. Incoming messages are unARC'ed using ARCMAIL and tossed
|
|
(from the netmail area to the actual conference area) using MGM TOSS. MGM SCAN
|
|
is similar to the original scan function, in that it moves messages from the
|
|
actual conference to the netmail area. However, once in the netmail area, all
|
|
msessages are addressed to your own system. An additional step, MGMFWD, is
|
|
required to address the outgoing messages to their actual destination.
|
|
Finally, ARCMAIL is normally used to pack the outgoing messages.
|
|
|
|
TBBS has an interesting situation, since it uses SEAdog to interface with
|
|
FidoNet. TBBS maintains all message subboards in one DOS file, as opposed to
|
|
the Fido method of one message per DOS file which is used by SEAdog. Thus,
|
|
there is a utility named PREMAIL which searches the TBBS message file for
|
|
messages which need to be sent out and converts them to messages in the SEAdog
|
|
netmail area. There is a similar utility named POSTMAIL which pulls the
|
|
messages back into the TBBS file from SEAdog's area. The ECHOLINK utility
|
|
establishes reply chains within the TBBS message base and also checks for
|
|
duplicate messages. Finally, if there is a need to forward to additional
|
|
systems, the ECHOFWD utility handles that chore.
|
|
|
|
|
|
Routing of Echomail
|
|
------- -- --------
|
|
|
|
It is not unusual for a moderately-sized echomail hub to handle dozens of
|
|
conferences and thousands of messages a day. This volume would quickly swamp
|
|
the structure which was set up to handle person-to-person communication in
|
|
which mail flows into a network through the network co-ordinator. For this
|
|
reason, separate structures have been established to expedite the movement of
|
|
echomail conferences. Echomail co-ordinators have the responsibility to
|
|
administer this activity. In some cases, the same individual handles both the
|
|
job of a network or region co-ordinator and echomail co-ordinator; many times
|
|
these different jobs are performed by different individuals.
|
|
|
|
There are entire systems dedicated to the movement of echomail. These
|
|
"echomail backbones" serve as repositories for large numbers of conferences and
|
|
links to the next level down on the hierarchy.
|
|
|
|
The actual topology of echomail is unimportant. The point is simple -- do not
|
|
route echomail through normal channels! Send a few hundred echomail messages
|
|
to some network co-ordinator and find out the real meaning of "annoying
|
|
behavior".
|
|
|
|
To get started in echomail, first get a working BBS. Get into the network, and
|
|
get settled. Then talk with your network co-ordinator, or perhaps by then you
|
|
will have found out who the echomail co-ordinator is. Regional echomail co-
|
|
ordinators are listed in Region 1 of the nodelist, with the help nodes. You
|
|
should start by receiving a small number of conferences from another node and
|
|
you will route your traffic (that is, messages your users enter) back to that
|
|
node. As your knowledge and confidence grows, you can ask for more conferences.
|
|
|
|
Echomail Etiquette
|
|
-------- ---------
|
|
|
|
There are a few simple things you can do to make echomail more pleasant for
|
|
everyone. These are common-sense issues but they may not be immediately
|
|
obvious when you are just getting started with echomail.
|
|
|
|
Do not send person-to-person messages using echomail. If you have a message
|
|
for Joe Klutz, and no one else is interested in it, then use standard netmail.
|
|
Even if you mark the message private, every sysop in the conference will pay to
|
|
receive it! A message between two sysops across town in New York, received on
|
|
a BBS in California, isn't likely to win any friends.
|
|
|
|
Every conference has a subject; don't get too far off of it. Most conferences
|
|
have a moderator who will step in and shout if the topic strays too much.
|
|
Unless you have been involved in a conference and have a good grasp of its
|
|
scope, be cautious about starting a new topic.
|
|
|
|
When you reply to a message in echomail, mention enough of the previous message
|
|
so that readers can tell what you are replying to. It is maddening to see
|
|
someone discussing the merits of a previous message when you can't figure out
|
|
what the previous message is about. Remember, reply chains in echomail are
|
|
imperfect at best and some echomail processors don't even attempt to
|
|
reconstruct reply chains.
|
|
|
|
Also, remember the delay inherent in echomail. If you post a question, don't
|
|
expect a response tomorrow. If you reply to a question, realize that many
|
|
others may be replying at the same time, a flood which will pour in over the
|
|
next several days.
|
|
|
|
Flames
|
|
------
|
|
|
|
The term "flame" is used within FidoNet to describe a "hot" message which
|
|
disagrees violently with some issue. Unfortunately, flames often are attacks
|
|
on persons, not ideas. This can be very annoying, using the term in its
|
|
"technical" context from FidoNet policy.
|
|
|
|
There is no excuse within FidoNet for personal attacks by one individual upon
|
|
another individual, yet it happens all the time. When you compose a message,
|
|
remember that the electronic media does not convey facial expressions or voice
|
|
tones. This can make it very difficult to convey the real meaning of what you
|
|
are trying to say.
|
|
|
|
Flames are contagious. If you see an attack on something you believe in, or on
|
|
someone you like, it is human nature to want to answer the challenge. Instead,
|
|
think about whether you really should reply. If you violently disagree with
|
|
what you just read, a reply may not be the best idea. . . at least not until
|
|
you have had time to calm down. It is bad form (although altogether too
|
|
common) to spend more time in the reply discussing personalities than the real
|
|
issues. Calm reasoning will win over more support than calling your opponent
|
|
names. Remember, it's not the COMPUTER you are jousting with; there is a real
|
|
human being out there, with feelings. Sure, the modem does a great job of
|
|
insulating you, but don't say anything in an electronic message which you would
|
|
not say face-to-face.
|
|
|
|
On the other hand, if someone attacks YOUR ideas, don't take it personally.
|
|
Humor is often the best response to a flame. Remember, everyone has a right to
|
|
their opinion, and the lack of verbal queues in echomail makes disagreement
|
|
sound like attack. It is not necessary to respond to each and every message
|
|
which states an opinion different from your own. There are times when ignoring
|
|
a message is the right thing to do, even though it is much more difficult than
|
|
replying to it.
|
|
|
|
|
|
An Alternative for EchoMail Junkies
|
|
-- ----------- --- -------- -------
|
|
|
|
Are you the type of person who is addicted to echomail? You call up your local
|
|
BBS and spend hours online reading all the messages in twenty different confe-
|
|
rences? Perhaps the major reason you're even considering opening a BBS is to
|
|
have your own local source for echomail, where you can sit in front of your own
|
|
computer, and read without worrying about tying up a telephone line.
|
|
|
|
Welcome to the world of POINTS and SERVERS. There is an alternative to much of
|
|
the hassle which you've just read about -- instead of starting a full-service
|
|
BBS, become a POINT instead. Here's the way it works.
|
|
|
|
A POINT system operates as an adjunct to another system which is a traditional
|
|
nodelisted FidoNet system, the SERVER. The POINT system is much like a one-
|
|
person BBS. The point system dials the server at some pre-arranged time,
|
|
usually in the wee hours, and downloads echomail. Then the owner of the point
|
|
can read it, enter replies, and upload this information at the next call.
|
|
|
|
This has many advantages for all concerned. (1) The point system doesn't tie
|
|
up the server BBS for hours reading messages online in the traditional way.
|
|
(2) The owner of the point may save lots of money in telephone charges if there
|
|
is a connect-time charge involved in the call. (3) The point owner doesn't
|
|
have to worry about busy signals, and can peruse the messages at any convenient
|
|
time. (4) If the point owner types slowly, this is even more of an advantage.
|
|
(5) The point system isn't listed in the nodelist, but can still participate in
|
|
network mail. With growth of the nodelist, this is a serious consideration.
|
|
(6) Compared to setting up a full-service BBS, setting up a point is easier.
|
|
|
|
The disadvantage of being a point is that you must have a server. This is
|
|
becoming less of a problem with the development of point/server software. If
|
|
you routinely tie up a popular system for hours reading mail, the sysop will
|
|
likely be more than happy to provide you with point access, since it will make
|
|
the BBS more available for other callers. If you fall into the category of
|
|
"echomail junkie", consider discussing point/server with your favorite sysop;
|
|
it may be what you really want to do rather than open a full-service BBS.
|
|
|
|
There are several alternatives available now for point/server software, and the
|
|
capabilities of the software are growing by the day. DUTCHIE was the first
|
|
package, and introduced the concept. Other alternatives include ConfMail, MGM,
|
|
and BinkleyTerm. Obviously the point must use a system which is compatible
|
|
with the server.
|
|
|
|
Common "Gotcha's"
|
|
------ ----------
|
|
|
|
Here's a collection of little tips that may save you from having to ask your
|
|
fellow sysop when something looks bad. . . or keep your system running more
|
|
smoothly.
|
|
|
|
You'll have an interesting problem once a year with XLATLIST. It "knows" that
|
|
the most current changes to the nodelist are in a file named NODEDIFF.nnn where
|
|
nnn is the largest. What happens at the first of a new year? Guess what --
|
|
it's not true, once a year, that the most current nodediff file has the
|
|
"highest" name. So watch for this; it can keep your nodelist update from
|
|
working correctly in early January. The solution is simple: Rename the old
|
|
nodelist (the one you want the nodediff applied to) to NODELIST.000, and make
|
|
sure that there aren't any other NODELIST.nnn files present in the
|
|
subdirectory.
|
|
|
|
A similar problem exists with Daylight Savings Time. FidoNet does not observe
|
|
daylight savings time. If your area does, then the LOCAL time for your
|
|
National Mail Hour changes twice a year -- once in the spring when DST begins,
|
|
and once in the fall when it ends. When you change the time on your computer
|
|
(using the TIME command), remember to also change the time for your mail events
|
|
in whatever mailer program you are using. If you don't change both at the same
|
|
time, you'll be observing National Mail Hour during the wrong hour.
|
|
|
|
Many new FidoNet sysops find out the hard way that messages which have files
|
|
attached do not follow normal routing. No matter which BBS software you are
|
|
using, if a message has a file attached it will be sent direct to its
|
|
destination, and no routing that you request will affect it. This can come as
|
|
a shock to the new sysop who thinks that all the outgoing messages are routed
|
|
to another local system; attach a file to a message and your system will gladly
|
|
call Australia if you let it.
|
|
|
|
Sources
|
|
-------
|
|
|
|
To obtain help on FidoNet or a related software product, use FidoNet! The best
|
|
source is a local sysop who has done what you want to do.
|
|
|
|
There are echomail conferences on many of the products discussed in this
|
|
document. Refer to the echomail section to discover how to join them.
|
|
|
|
The first part of the nodelist, "Region 1", contains help nodes for many
|
|
software products and functions. This is a partial list (taken from the
|
|
current nodelist):
|
|
|
|
1/0 International FidoNet Co-ordinator 1-602-235-9653 Scottsdale AZ
|
|
1/1 FidoNews Editor 1-216-642-1034 FidoNews Editor
|
|
1/10 Internation FidoNet Association 1-314-576-2743 St Louis MO
|
|
1/11 IFNA Finance 1-808-533-0190 Honolulu HI
|
|
1/12 IFNA Legal 1-201-326-9870 Parsippany NJ
|
|
1/16 IFNA Membership data 1-216-291-3048 Clevland OH
|
|
1/17 IFNA Membership information 1-216-883-0578 Clevland OH
|
|
1/20 FidoNet Technical Standards 1-503-297-9145 Portland OR
|
|
1/88 FidoCon 88 1-606-727-3811 Cincinnati OH
|
|
1/100 General Help 1-201-245-6614 Clifton NJ
|
|
1/102 BinkleyTerm Help 1-615-875-4131 Chattanooga TN
|
|
1/113 OPUS Information 1-916-893-9019 Chico CA
|
|
1/114 Quick BBS (QBBS) Help 1-516-328-7064 Floral Park NY
|
|
1/116 Dutchie Help 1-314-334-6359 CapeGirardeau MO
|
|
1/117 Fido Help 1-408-296-2329 San Jose CA
|
|
1/200 National Echomail Coordinator 1-415-672-2504 Concord CA
|
|
1/201 EchoList Coordinator 1-201-286-2567 Toms River NJ
|
|
1/210 Region 10 Echomail Coordinator 1-714-544-3369 Tustin CA
|
|
1/211 Region 11 Echomail Coordinator 1-216-883-0578 Clevland OH
|
|
1/213 Region 13 Echomail Coordinator 1-201-249-1898 E. Brunswick NJ
|
|
1/214 Region 14 Echomail Coordinator 1-612-377-3398 Minneapolis MN
|
|
1/215 Region 15 Echomail Coordinator 1-303-973-9338 Littleton CO
|
|
1/216 Region 16 Echomail Coordinator 1-603-888-8179 Nashau NH
|
|
1/217 Region 17 Echomail Coordinator 1-206-848-5317 Puyallup WA
|
|
1/218 Region 18 Echomail Coordinator 1-901-853-3116 Memphis TN
|
|
1/219 Region 19 Echomail Coordinator 1-405-691-0863 Okla City OK
|
|
1/300 SoftWare Coordinator 1-301-574-1984 Essex MD
|
|
1/302 SoftWare Distribution West 1-915-857-1974 El Paso TX
|
|
1/311 Software Distribution Region 11 1-312-982-5092 Region 11
|
|
1/313 Software Distribution Region 13 1-412-856-1428 Region 13
|
|
1/314 Software Distribution Region 14 1-612-377-3469 Region 14
|
|
1/315 Software Distribution Region 15 1-303-252-9235 Region 15
|
|
1/316 Software Distribution Region 16 1-617-433-8452 Region 16
|
|
1/318 Software Distribution Region 18 1-305-226-3310 Region 18
|
|
1/319 Software Distribution Region 19 1-405-848-2828 Region 19
|
|
|
|
|
|
Any user of FidoNet is eligible to join the International FidoNet Association
|
|
to assist in the administration of the network and to take advantage of special
|
|
offers on software available to members. An application blank and order form
|
|
can be found at the end of each issue of FidoNews, and are included below:
|
|
|
|
__
|
|
The World's First / \
|
|
BBS Network /|oo \
|
|
* FidoNet * (_| /_)
|
|
_`@/_ \ _
|
|
| | \ \\
|
|
| (*) | \ ))
|
|
______ |__U__| / \//
|
|
/ Fido \ _//|| _\ /
|
|
(________) (_/(_|(____/ (tm)
|
|
|
|
Membership for the International FidoNet Association
|
|
|
|
Membership in IFNA is open to any individual or organization that
|
|
pays a specified annual membership fee. IFNA serves the
|
|
international FidoNet-compatible electronic mail community to
|
|
increase worldwide communications.
|
|
|
|
Member Name _______________________________ Date _______________
|
|
Address _________________________________________________________
|
|
City ____________________________________________________________
|
|
State ________________________________ Zip _____________________
|
|
Country _________________________________________________________
|
|
Home Phone (Voice) ______________________________________________
|
|
Work Phone (Voice) ______________________________________________
|
|
Zone:Net/Node Number ____________________________________________
|
|
BBS Name ________________________________________________________
|
|
BBS Phone Number ________________________________________________
|
|
Baud Rates Supported ____________________________________________
|
|
Board Restrictions ______________________________________________
|
|
Your Special Interests __________________________________________
|
|
_________________________________________________________________
|
|
_________________________________________________________________
|
|
In what areas would you be willing to help in FidoNet? __________
|
|
_________________________________________________________________
|
|
_________________________________________________________________
|
|
Send this membership form and a check or money order for $25 in
|
|
US Funds to:
|
|
International FidoNet Association
|
|
c/o Leonard Mednick, MBA, CPA
|
|
700 Bishop Street, #1014
|
|
Honolulu, Hawaii 96813-4112
|
|
USA
|
|
|
|
Thank you for your membership! Your participation will help to
|
|
insure the future of FidoNet.
|
|
|
|
Please NOTE that IFNA is a general not-for-profit organization
|
|
and Articles of Association and By-Laws were adopted by the
|
|
membership in January 1987. The first elected Board of Directors
|
|
was filled in August 1987. The IFNA Echomail Conference has been
|
|
established on FidoNet to assist the Board. We welcome your
|
|
input to this Conference.
|
|
|
|
-----------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
INTERNATIONAL FIDONET ASSOCIATION
|
|
ORDER FORM
|
|
|
|
Publications
|
|
|
|
The IFNA publications can be obtained by downloading from Fido
|
|
1:1/10 or other FidoNet compatible systems, or by purchasing
|
|
them directly from IFNA. We ask that all our IFNA Committee
|
|
Chairmen provide us with the latest versions of each
|
|
publication, but we can make no written guarantees.
|
|
|
|
Hardcopy prices as of October 1, 1986
|
|
|
|
IFNA Fido BBS listing $15.00 _____
|
|
IFNA Administrative Policy DOCs $10.00 _____
|
|
IFNA FidoNet Standards Committee DOCs $10.00 _____
|
|
|
|
SUBTOTAL _____
|
|
|
|
IFNA Member ONLY Special Offers
|
|
|
|
System Enhancement Associates SEAdog $60.00 _____
|
|
SEAdog price as of March 1, 1987
|
|
ONLY 1 copy SEAdog per IFNA Member
|
|
|
|
Fido Software's Fido/FidoNet $100.00 _____
|
|
Fido/FidoNet price as of November 1, 1987
|
|
ONLY 1 copy Fido/FidoNet per IFNA Member
|
|
|
|
International orders include $10.00 for
|
|
surface shipping or $20.00 for air shipping _____
|
|
|
|
SUBTOTAL _____
|
|
|
|
HI. Residents add 4.0 % Sales tax _____
|
|
|
|
TOTAL _____
|
|
|
|
SEND CHECK OR MONEY ORDER IN US FUNDS:
|
|
International FidoNet Association
|
|
c/o Leonard Mednick, MBA, CPA
|
|
700 Bishop Street, #1014
|
|
Honolulu, HI. 96813-4112
|
|
USA
|
|
|
|
Name________________________________
|
|
Zone:Net/Node____:____/____
|
|
Company_____________________________
|
|
Address_____________________________
|
|
City____________________ State____________ Zip_____
|
|
Voice Phone_________________________
|
|
|
|
Signature___________________________
|
|
|
|
-----------------------------------------------------------------
|
|
|
|
|
|
For information on International FidoNet Association:
|
|
IFNA
|
|
PO Box 41143
|
|
St. Louis, MO 63141 USA
|
|
314 576-4067 (voice)
|
|
|
|
NOTE: If you wish to avail yourself of the IFNA sysop offer for SEAdog or
|
|
Fido, please use the order form above; do not contact the vendors at the
|
|
address below to take advantage of the IFNA offer. One of the reasons that the
|
|
IFNA offer can exist is the ability of IFNA to offer distribution and support
|
|
services.
|
|
|
|
For information on ConfMail:
|
|
Bob Hartman (132/101)
|
|
Spark Software
|
|
427-3 Amherst Street
|
|
Nashua, NH 03061
|
|
|
|
For information on commercial purchase of Fido:
|
|
Fido Software
|
|
164 Shipley
|
|
San Francisco, CA 94107
|
|
415 764-3785
|
|
|
|
For information on Opus, please provide a self-addressed stamped envelope and
|
|
write to:
|
|
Opus "Snail"
|
|
PO Box 16410
|
|
San Francisco, CA 94116
|
|
or
|
|
request information from the following FidoNet nodes: 1:1/113 (Chico, CA),
|
|
3:3/113 (North Ryde NSW Australia), 1:133/302 (Atlanta, Ga), 1:125/9 (San
|
|
Francisco, CA), 1:150/1 (Wilmington, DE).
|
|
|
|
The author of QBBS is Adam Hudson, 8020-A Holland Ct, Arvada CO 80005; his
|
|
FidoNet address is 104/24. Claude Warren (104/51) wrote the documentation for
|
|
QBBS.
|
|
|
|
For information on System Enhancement Associates' products, including SEAdog:
|
|
System Enhancement Associates
|
|
21 New Street
|
|
Wayne, NJ 07470
|
|
|
|
For information on TBBS:
|
|
eSoft, Inc.
|
|
4100 S. Parker Road #305
|
|
Aurora, CO 80014
|
|
303 699-6565 (voice)
|
|
|
|
A nationwide listing of echomail conferences is available from Thomas Kenney,
|
|
107/316. Request ELST*.ARC.
|
|
|
|
Acknowledgements
|
|
----------------
|
|
|
|
This document is a group effort. It has to be; no one person can know every
|
|
piece of software which is in common use in the network. When you run a
|
|
particular type of BBS software, you become familiar with that piece of
|
|
software and the utilities that it uses; that doesn't help the potential sysop
|
|
who isn't using your configuration.
|
|
|
|
So, readers, if you have made your way through the implementation of something
|
|
which is not covered here, and you want to share your experience with your
|
|
fellow users, please write something and send it to me. I would be happy for
|
|
this document to grow so that more topics are covered. To corrupt a popular
|
|
phrase. . . send prose!
|
|
|
|
Information was adapted from published documents by the following persons:
|
|
|
|
Bob Hartman -- ConfMail and the history of EchoMail
|
|
Tom Jennings -- FidoNet history
|
|
|
|
|
|
Thanks to the following individuals for "sending prose":
|
|
|
|
Randy Bush -- Dutchie and the term "public domain"
|
|
Norm Henke -- PCBoard
|
|
Thom Henderson -- SEAdog and TBBS
|
|
Ken Kaplan -- Specific <tm> information and IFNA background
|
|
Brian McCullough -- A careful reading; many useful suggestions
|
|
Vince Perriello -- BinkleyTerm
|
|
Dick Sonka -- TBBS
|
|
Bob Westcott -- RBBS
|
|
James Zachary -- MGM
|
|
|
|
|
|
|
|
Steve Bonine 115/777
|
|
|
|
|