       The following text was written by Scott Dudley, author of
       MAXIMUS, one of the most common BBS systems in use on the planet.

       Scott has also written a mail processor called SQUISH which is
       also a world leader in processing Fidonet mail.  The following
       was taken from the documentation file for Squish with the kind
       permision of Mr. Dudley.


                                 NETWORK PRIMER
                                by, Scott Dudley
                                   1:249/106

       This section is intended as a primer for SysOps who are new to
       FidoNet or a FidoNet Technology Network (FTN).  This section
       covers many of the terms and concepts which are required for
       everyday FidoNet operations.


                                  The Basics

       The term "FidoNet" refers to an amateur electronic mail network,
       run collectively by a group of system operators.  In the
       beginning, FidoNet started out as a simple system for exchanging
       private messages between different bulletin boards.  Since then,
       FidoNet has grown into a full-fledged electronic mail and
       conferencing network which has members in most countries of the
       world.

       FidoNet itself is organized into a numerical hierarchy of
       "zones", "regions", "nets", "nodes" and "points".  Each member of
       FidoNet, individually known as a "node", can be uniquely
       identified by that system's zone, net, node and point numbers.
       To define each term:

       Zones are wide geographical areas, usually covering one or more
       continents.  At the time of writing, FidoNet currently has six
       zones:  zone 1 (North America), zone 2 (Europe), zone 3
       (Oceania), zone 4 (South America), zone 5 (Africa) and zone 6
       (Asia).

       Nets cover a much smaller area than zones; a net usually
       encompasses a large city and the surrounding area.  There are
       usually many nets within each zone, each of which represents a
       small geographical area within that zone.

       Nodes are individual systems.  Most nodes consist of bulletin
       board systems, although a few nodes are devoted exclusively to
       handling mail.  If you wish to become a member of FidoNet and you
       are running a BBS, this is probably where you will start.

       Points are users on an individual system.  Normally, points do
       not run full-time systems, since they simply send and receive

       mail through their "bossnodes" (the nodes where the points pick
       up their mail).  As the size of the network grows, points are
       becoming increasingly popular.  If you don't wish to run a full-
       time system, this is probably where you'll start.

       These four terms can be combined to give a "network address"
       which identifies any one node in the network.  The format of a
       FidoNet address is as follows:

                             zone:net/node[.point]

       For example, given a user in zone 1, in net 249, with a node
       number of 106, and a point number of 2, that user's full address
       would be '1:249/106.2'.  The point number is optional, so both
       1:249/106 and 1:249/106.0 refer to the bossnode of 1:249/106.2.

       This mode of addressing is sometimes referred to as "4D" or four-
       dimensional, since it includes the four basic elements of a
       network address.


                               The Outside World

       Like other electronic mail systems, it's possible to enter a
       private message on a FidoNet system and have that message be
       delivered to its final destination in a short period of time.
       FidoNet systems "talk" with each other over telephone lines,
       using one or more sophisticated handshaking protocols.  To get a
       message (known in this context as "NetMail") from point "A" to
       point "B", the following sequence of events has to occur:

       *    The message is created.  Most Fido-compatible software
       packages can be used to generate a private message to a user on
       another node.  The destination address is entered, using the
       standard 4D addressing scheme.

       *    The on-disk message is then converted to packet (or *.PKT)
       form.  If you are running BinkleyTerm, this will be performed by
       Squish after a user logs off.  If you are running FrontDoor or a
       similar mailer type, this will be performed by the mailer itself
       on startup, or while your mailer is connected to other systems.

       There are four reasons for converting a message into a packet:

       1)   The packet structure is much more flexible than the local
       message structure.  All of the fields (such as the To:, From: and
       Subject: fields) in a packet are variable length, whereas the
       fields in stored messages are fixed-length.

       2)   Packets are the "compatibility layer".  Since all systems
       convert messages to the *.PKT format before sending them to
       another system, there are few compatibility problems.  This means
       that systems can store their local message bases in different
       formats, but still be able to exchange messages easily.  In
       addition, more than one message can be stored in a single packet.
       Sometimes hundreds (or even thousands) of messages can be stored
       in a single packet.


       3)   Messages in a packet can have a different address from the
       packet itself.  The packet itself has a destination (the system
       where you'll be sending that packet directly to), but each
       message has an individual destination address.  This is useful,
       for example, when a long-distance call is required to connect
       with certain parts of the network.  The message's final
       destination always stays the same, but by sending the packet to
       someone who is local to you (and then having that someone send it
       to another local system, and so on), costs can be controlled
       quite effectively.  Since the interim destination of packet
       doesn't need to be the same as the final destination of the
       message, routing of messages via the lowest-cost route can be
       performed.

       4)   Packets can be given a "flavour".  A "flavour" (or a
       behaviour characteristic) helps your system decide what to do
       with an individual message.  For example, the "hold" flavour
       instructs your system to hold the message and wait for the
       destination system to call and pick it up.  Other flavours
       include "crash" (send a message directly to the destination),
       "direct" (same as crash), and "normal" (wait for later routing
       commands).

       Packets always have an extension of *.PKT.  (Qualifier:  if you
       are running a BinkleyTerm system, they may have an extension of
       *.HUT, *.OUT, *.CUT, or *.DUT on your local system, but Binkley
       always changes them to *.PKT files before they are sent to
       another system.)

       *    After the packet is created, it can be optionally archived
       using a file compression utility.  Compression is useful when
       transferring large volumes of mail or sending to long- distance
       sites, since compressing mail saves both time and money.

       *    The system which created the message then tries to call the
       destination system.  Obviously, if both systems are fairly busy,
       this may take a while.  Messages are sent back and forth between
       systems through the use of mailers, also known as "front ends".
       Mailers call out to deliver waiting mail, handle incoming
       messages and files, and in general, supervise the entire file
       transfer.

       *    After the two mailers connect (using one of several FidoNet
       protocols), waiting mail and files are transferred between the
       two systems.

       *    After the transfer completes, the receiving system then
       tries to import the message.  If the packet was compressed by the
       sender, it will be decompressed.  The *.PKT files will then be
       imported (otherwise known as "tossed") into the local message
       base, ready for the recipient to read.

       Although transferring NetMail can involve much more than just
       what is given above, this should give you a grasp on NetMail
       fundamentals.


                           Is There an Echo In Here?

       In the beginning, FidoNet consisted solely of nodes exchanging
       NetMail.  The only way to get a message from "here" to "there"
       was to send a private NetMail message.  However, a technology
       called "EchoMail" was developed in late 1985; EchoMail is
       analogous to a public message area or conference, but EchoMail
       areas (sometimes known as "echoes") are shared among several
       other systems.

       EchoMail is organized into different groups of echoes, each with
       a different topic.  For example, the topics of FidoNet echoes
       range from Maximus Support to deep-sea fishing and many more
       special-interest groups.  To facilitate topic-oriented EchoMail,
       each echo must given a tag (or area name).  This tag is used to
       uniquely identify that EchoMail area when transferring messages
       with other systems.  (It doesn't matter what you call the echo on
       YOUR system, as long as you are using the same tag as everyone
       else.)  Area tags are one word only, although they can include
       periods and underscores.  To start receiving an echo area, you
       need to know the tag of that area.  For example, the area tag for
       the echo dealing with hardware and other technical issues is
       "TECH".

       EchoMail messages are normally public, and they are entered in a
       message area just like a normal message.  EchoMail messages also
       look like normal, locally-entered messages, but with some special
       control information at the bottom of each message.

       After an EchoMail message is saved, an EchoMail utility (such as
       Squish) is invoked to "scan" that message out to the rest of the
       network.  Unlike NetMail, EchoMail areas have an electronic
       topology.  Some echoes are very large, and as such, the cost to
       directly send a message to each system which carried that echo
       would be prohibitive.  Instead, each system carrying that echo
       only transfers EchoMail messages to neighbouring systems.  (The
       neighbour you receive an echo from is also known as your "feed".)
       EchoMail messages get sent from the originating system to its
       neighbours, and from those systems to their neighbours, and so
       on.  Despite this "hoppity-hop" method of transferring messages,
       EchoMail is fairly quick; it can often take less than three days
       for a message to travel from the USA to Australia and back.

       Just like NetMail, echoes are sent to other systems in packets.
       EchoMail messages are almost always compressed, since most of the
       popular echoes have a daily throughput anywhere from 20 to 200
       messages per day.

            Copyright 1991 by Scott J. Dudley.  All rights reserved.
                             Used with permission.

                                     * * *

