-1-
BASICS.TXT -- A tutorial for newcomers and prospective members of
Rev. 0.3 FidoNet. (All those things they don't tell you
about in the software docs!)
Please circulate and post for D/L and File Request as BASICSXX.ZIP,
where XX is the revision number (in this case, BASICS03.ZIP).
TABLE of CONTENTS
Basic FidoNet Terminology ...................... 2
FidoNet Technical Standards .................... 5
Fido News ...................................... 5
FidoNet Policy ................................. 6
More FidoNet Terminology ....................... 6
Events & Nodelists ............................. 6
Processing Nodelists ........................ 8
Nodelist Contents .............................. 8
File Requests, Attaches, etc. .................. 10
Routing Mail ................................... 11
EchoMail, How It Works ......................... 11
Cross-Links .................................... 15
Mail Archving & Naming Techniques .............. 17
How to apply for a Fido node number ............ 20
Security Issues and Passwords .................. 21
INDEX
(copr 1990/1991) Chris Anderson at The Dinosaur Board
Please refer all change requests to FidoNet 1:104/114 via NetMail.
Some portions of this document are extracts from 101WAYS, which
includes 101CRASH and 101NIGHT, (copr 1989), Chris Anderson.
-2-
First, get some basic FIDO terminology under your belt. These words
will be used OFTEN during your use of any mailer and BBS net software!
NETMAIL
The international system of Electronic Mail. Designed primarily to
transfer E-Mail messages between individual users around the world.
The user sends his message from a local system and this message is
forwarded to the appropriate system automatically. The sending
system pays for the service by placing the outbound call, usually
billed as a one minute call to the receiving system's location at
late hour long distance rates. Replies are paid for by the
reply sender. No profit is allowed to sysops for this service when
users are charged for the service.
All NetMail is sent at least nightly during Zone Mail Hour. This is
a synchronized event taking place from coast to coast every day of
the week. In addition, some systems allow sending and receiving of
messages 24 hours a day, even during the higher priced daytime hours.
This is known as CRASH MAIL, and is often sent as soon as it is posted
by the sender.
ECHOMAIL
The method of sharing message boards between systems. This allows systems
to share one or more message boards on a nationwide basis. Some are even
worldwide systems. These shared boards are usually called ECHOS or
ECHO CONFERENCES. These ECHO's are available for a wide variety of
topics ranging from programming in Pascal to Amateur Radio. During the
night, each system sends its day's messages from selected message areas
to a central point and receives other system's day's messages in return.
Distribution of echos is, as noted, almost always handled by a central
system in each area to avoid confusion and possible duplication of
messages. This service is usually provided by sysops at no charge to
their users. An exception would be a board that charged for access for
all or most services.
Zone Mail Hour
Participants in the Fido NetMail system are obliged to make their system
available during Zone Mail Hour on a daily basis. This hour is
synchronized to occur simultaneously across the country.
0100-0200 Pacific Standard Time
0200-0300 Mountain Standard Time
0300-0400 Central Standard Time
0400-0500 Eastern Standard Time
Times are NOT adjusted for daylight savings time! In other words, if
you were in the Pacific zone, your hour would be from 0100-0200 during
standard time, and from 0200-0300 during daylight time if observed in
your area.
"OTHER" HOURS
Your net may also observe other hours where your system needs to be
available. Often, these times are used for EchoMail transfers. Note
that sending EchoMail during Zone Mail Hour is a *usually* a no-no!
You should avoid it unless it is acceptable in your area. Zone Mail
Hour is usually reserved for NetMail transfers only, as large file
transfers of EchoMail can tie up your system badly during this event.
An example is that in the 104 (Denver) net, we once used the hours of
0100-0200 open for sending our EchoMail from the day to our central
"collection points" - our EchoMail Hubs. From 0200-0300 we had Zone Mail
Hour, and from 0300-0400 we received EchoMail from the coordinator.
-3-
ZONES, REGIONS, HOSTS (NETS), HUBS, NODES AND POINTS
Each of these is descriptive of the position of a system in the overall
network. Technically, every system in the Fido network is a NODE. A
node is, after all, a "connection" within a system. However, certain
nodes have responsibility for routing data between other nodes.
ZONES are the largest discrete group of systems. There are now six
FidoNet zones covering the world. One zone handles the U.S. & Canada,
one for the Asian and Pacific areas, one for Europe and one for Latin
America. Every node has an implied zone number (see Net/Node Number,
below). Zone numbers are also sometimes used for interconnect to
non-Fido networks. At this time, it is still common to find these
other nets using non-Fido zone numbers (such as 8) to identify themselves.
As Fido continues to add zones, this could someday present a problem,
and new identificiation methods have already been established to
handle this problem in a different way. We won't talk about this
"DOMAIN" addressing technique here, but you should be aware of it.
REGIONS identify a large geographical area within a zone. In the U.S.
Zone, there are several regions, each taking care of a group of states.
My region is 15 which takes in Colorado, Utah, Arizona, New Mexico and
Wyoming. It's known as the Mountain Region.
Region numbers are never used as part of a Net/Node number. However,
be aware that your Net Coordinator's boss is the Regional Coordinator.
He helps handle nodelist updates and the like, but isn't involved in
the day-to-day moving of mail.
HOSTS (also known as NETS) are the next smaller subdivision. Within
Region 15, Denver is NET 104. On a typical Fido nodelist, you'll see
these referred to as a HOST, we call them NETS. The person who
administrates your net is known as the Net Coordinator. This is the
person who is responsible for making sure that the current Nodelist
(the FidoNet "phone book", so to speak) and other important items
are made available to you. The Net Coordinator also assigns the
node numbers (see below) in your net area.
HUBS serve to distribute to a smaller geographic area. For example, as
part of the Denver Net (104), various suburbs and surrounding cities
are grouped around a Hub. My Hub is Boulder. These are never included
in Net/Node numbers. Not all nets make use of hubs for assistance.
NODES are the last step in the chain (but remember that actually, ALL
systems are Nodes). Each system has a unique Node number within its Host
or Net area.
POINTS are like "superusers". They use mailer software to receive mail
from a member of the network, and do not have their own node numbers
listed in the nodelist. However, they do have unpublished private net
(Point Net) numbers which are used to handle movement of mail between
their systems and their respective Boss Nodes. Point Net numbers can
be received by applying to your Zone Coordinator at 1/0. The ZC will
supply you with your private net number, and you can assign the node
portion of the number to systems as you see fit.
NET/NODE NUMBER - the mailing address that makes it all work. In fact,
the proper definition is ZONE:NET/NODE, but unless international or
inter-net transactions are occuring the Zone number typically defaults
in software to whatever your own Zone is.
-4-
Since I am in the U.S., Denver area, my number will be 1:104/something.
My node number within 104 is 114, so my full address is 1:104/114. As
noted above, the Zone is often ignored, so I'm 104/114 for short.
Remember that Regions and Hubs are used for administrative purposes,
and don't figure into your net/node address number.
MESSAGE
Of course, the primary purpose of all this is to move "messages"
around the system between nodes. There are several types of message,
and each is handled in a unique way by your software. We've already
covered the definitions of EchoMail and NetMail messages above.
There are several other types of "messages" as well, including the
File Attach message and the File Request message. We'll touch on
those a bit later in this file. Most often, your software will
operate initially on the message with a filename in the form
of *.MSG. A rare few systems avoid this intermediate stage and
place the messages directly into the message base if there is
a "database" style message base in use.
Messages can be sent with a variety of attributes, some of which
are FidoNet standards, and some of which are unique to particular
software or groups of software. A few of these attributes include
Private - Various software can be configured to handle this
in a wide variety of ways. In many cases, only
the sysop, the sender, and the receiver are made
capable of reading a "private" message. Since the
point of an echo is to move useful mail to a great
many systems, sending a "private" message in an
echo is tacky. Hundreds of systems may be forced
to receive a message that their users can never read.
Crash - Flags that this message is to be sent "crash". On
many systems, the configuration causes a "crash"
message to be sent immediately to its destination
either directly or via whatever appropriate routing
has been supplied.
Hold - A message with a "hold" flag on it must generally
be picked up by a call *from* the destination
system.
Kill/Sent - Most often used only on NetMail messages, this flags
your software to delete your message once it has been
packed or sent to the destination, avoiding cluttering
up your own message area with traffic that has already
been sent on its way.
PACKET
The most BASIC unit of transfer between two systems is NOT the
message, it is the "packet". A packet is prepared by your software
that contains all of the messages destined for a given system - all
in one tidy bundle. There is no compression technique used here,
only the bundling process takes place. When two systems make
contact, and if things are configured properly, they will exchange
any packets destined for each other. If you have four messages
destined for a node, they will be transferred in a single packet
during the connect. They are immediately broken down into "messages"
by your software, and inspected for potential file requests or
attaches. Regular messages are then processed in whatever fashion
your software is designed to use to get the messages to someplace
where they can be read. If you should ever spot a file whose name
is in the form *.PKT, that's a packet. Note that when we discuss
moving archived (compressed) mail files back and forth later, that
it is the packets (*.PKT files) that are compressed. The FidoNet
standard for this is the old SEA 5.X ARC standard, although many
systems will use the newer ZIP format - but ONLY where mutually
agreed upon in advance.
-5-
There are official FidoNet Technical Standards covering the exact
construction of both messages and packets. Your software was most
probably written correctly, and will conform to these basic formats.
If, however, your software is prone to deviating from those standards,
you're likely going to run into trouble with your fellow net members
when *their* software gags and pukes on undecipherable messages or
packets. It is *your* responsibility to remedy such situations when
they occur. Always stay abreast of modifications and bug fixes for
your software that are intended to enable your software to maintain
FidoNet standard operation. If questions arise, the FTS standards
are the final authority for such matters.
If you're interested in seeing just how these standards allow your
system to talk to others, you may want to locate and download these
standards as created by the FidoNet Technical Standards Committee
(FTSC). A great deal more thought has gone into making our systems
function well together than first meets the eye!
FIDONEWS
Each week, more or less along with the new NODEDIFF file (the update
to our FidoNet "phone book"), you'll receive the Fido News. The
Fido News is a collection of editorial material, rants and raves,
amusing stories, and a useful list of the latest known revisions
for much of the software used by FidoNet systems. Announcements
of events of interest to members is also included.
Traditionally (well, let's say up until August 1990), the Fido News
was transmitted in archived (ARC) format. The editor decided it
would be amusing to begin transmission in LHARC (LZH) format in
August of 1990, to the consternation of the many FidoNet members
who have no utilities to turn the LHARC files back into readable
text. Your Net Coordinator or Administrative Hub may recreate
these files as ARC files, or may pass them through to you as LHARC
files. If your computer has no LHARC utility available for it,
you should request that it be converted before it is sent to you.
I suspect that if enough such requests are made, the Net Coordinators
will demand a return to a format for which decompression software
is more readily available. Time will tell.
-6-
FIDONET POLICY
FidoNet sysops are obliged to operate by a set of Policy guidelines
that must be followed by all within the FidoNet system. If you plan to
enter into the system, you should get a copy of whichever is currently
available (4 is in current today) and read it. Most important are the
understanding of Zone Mail Hour (above) and the responsibilities
of the individual Sysop. Pay particular attention to what is known as
an "annoyance". Fido is reasonably tolerant of a lot of things, but
Major Annoyances can get you canned from the system. The policy also
explains the responsibilities of the folks up the chain from you, and
therefore explains what you can and cannot reasonably expect from them.
Note that there is also an Echo Policy floating around. Sadly it doesn't
define much in regard to data formats or archiving utilities or any number
of other helpful things. However, it explains the duties of echo
coordinators and hubs and what you may and may not expect of them. Much
of the echo policy within a net is determined locally by the net members.
At the time of writing, no EchoPol has ever been formally adopted by
FidoNet as a whole. In addition, your net may have its own policy.
In addition, your own net may adopt local policies detailing its
own preferred method of operation so long as it does not come into
conflict with FidoNet policy.
Now for some other terms related directly to your software and its use:
EVENT
An Event is pretty much what it sounds like. It is an action that is
taken at a specific time of day or within a range of times by your
computer. You will want to set up Events so that at the appointed time,
your system will begin to execute each Event. All you'll need to supply
is the time and a description of what you want accomplished. An
example of this would be to tell your mailer software that at 0200 it
needs to put itself into send/receive mode for NetMail.
NODELIST
All of the addresses for the over 7,500 systems are contained in a file
called the Nodelist. This file is updated on a weekly basis by the
Fido coodinators. In addition, for those that already have the
most recent large working file, small update files are made available
weekly to add to the existing file. This avoids having to shuffle
around the big one once a week to all systems.
The large file is distributed as NODELIST.Axx, where xx represents the
number of the distribution. This number is the day of year. The
.Axx extension indicates that the file has been archived using SEA or PK
or similar archive techniques. After un-ARC'ing the file, it will
look something like NODELIST.241 instead of NODELIST.A41. You don't
see the entire day, of course, until you un-ARC the file.
The list is not useable by most software packages in its form as
distributed. This list will likely need to be translated to operate
with your mailer package. In addition, an index and some other necessary
files are usually created from NODELIST.xxx. If you will be running
software that can handle SEAdog, Opus or Fido style nodelist compilations,
I strongly recommend use of XLAXNODE for your nodelist compiler.
In addition to the NODELIST.Axx files, you will receive NODEDIFF.Axx
files weekly. These are the changes rather than the entire list.
These can be incorporated using XLAXDIFF. NODEDIFF.Axx files have the
same extension (archive indicator + day number) as the larger files.
-7-
It's much faster to incorporate changes into your existing list than to
receive an entire list each week! You'll discover that the archived
version of the full list runs well over 300K!
Execution of XLAX is a piece of cake. Just get yourself into the directory
where XLAX and your node lists reside, and type XLAXNODE. You'll discover
that it asks you to repeat a number that it gives you. This was the
author's way of trying to convince you that you should register your copy
and sent him his $10. Without doing so, you won't be able to run the
program automatically in unattended mode. Send him his $10. It's a
bargain!
Note: due to some overlap between some European and U.S. node numbers,
and the Zone-Brain-Dead nature of some mailer & BBS software, you may
see some "duplicate" warnings as the node list is being compiled. This
is normal. However, you should see pretty much the same ones month after
month. If new ones start showing up, your list may be hosed. If you need
to access these European nets, you may have to redefine them somehow.
The NET command can be used in your XLAXNODE.CTL file to redefine
duplicated net numbers. For example, if I have both a European and U.S.
Net 237, I could redefine the European net number like this:
NET 2:237 2237
By doing this, I can send a message to net "2237" and the call will be
placed to 2:237. This does cause some complications for the receiving
end, but if you wish to direct route mail to one of these "duplicate nodes",
I know of no other way to accomplish it given the current problems with some
of the BBS and mailer software out there that is not "zone aware".
A couple of files are needed for compiling any nodelist. In the case of
XLAXNODE, two of the more difficult to create are the file containing
costs and the file containing corrections for dialing. I've chosen to
call these COSTS.TXT and DIALFIX.TXT. The latter isn't too difficult,
but you're going to either have to borrow the former, or do some
substantial work to get accurate costs built into your nodelist if it
needs them.
COSTS
The XLAX docs provide an excellent description of the format for this
information. This list will probably the most time-consuming proposition
in the entire setup unless you can get an accurate list from another
sysop in your own local calling area. Best bet is to find the closest
FidoNet sysop and rework that list as opposed to building one from
scratch. One word of caution! If you use someone else's list, be aware
that this person may be using a different long distance carrier, and that
your rates may vary somewhat from his, even if you are in the same calling
area. Getting rates from your carrier can be a real bitch. They HATE
sending out rate lists for you in most cases. However, I've found that
threatening to ask them by phone, area code by area code, often produces
results. In general, rates don't vary much in the 1am-4am once you get
outside a certain distance from your area, but be sure! International
rates are a little easier to get in most cases. For in-state calls (where
your local phone company has you by the cajones) [yeah, sexist remark], the
possibilities may be endless and may require that you do some random
sampling and just generate an average in order to avoid a list that
could take weeks to enter. Of course, it should come as no surprise
that in-state calls wind up costing more than long distance. You'll get
an education into the cost of phone calls and federal regulation of
interstate long distance as you go about this process!
-8-
Be sure that you enter the default domestic and international rates at
the top of the list per the XLAX docs just in case your list misses
something along the way!
DIALING FIXES
All of the entries in the node list are in the full length form.
For example, a Colorado number might appear as 1-303-123-4567.
If you live in Colorado, dialing 1-303- before every number gets you
a recording telling you that you really didn't need to do that.
In fact, you don't even need the 1- for calls in your local calling
area. This file is where these things are dealt with. XLAX docs
this well, as usual, but here's a couple of examples:
I live in area code 303. One of my long distance 303 nodes is at
1-303-555-1111. In addition, two of my local calling area prefixes
are 552-xxxx and 553-xxxx.
I would want to include the following in my DIALFIX.TXT file:
1-303-555 1-555 (strip off the 1-303 when dialing, and use a 1-)
1-303-552 552 (strip off the 1-303 when dialing)
1-303-553 553 (strip off the 1-303 when dialing) etc., etc.
NODELIST ENTRIES
Everyone in FidoNet should be familiar with the makeup of a nodelist
entry. Here is mine (split into two lines for convenience - they are
never split in the list).
,114,The_Dinosaur_Board,Niwot_CO,Chris_Anderson,1-303-652-3595,9600,
HST,V32,CM,XP
Most of this information requires no explanation. The first number is
my node number within Net 104. The second bit of information is the
name of my BBS. Note that underscores are always used in the nodelist
entry, but are generally converted to spaces by other software. The
next items are my location, and my name. The phone number is
"normalized" to include all of the dialing information required for
somebody in the U.S. to place the call to my number. For those that
are in my area code (303), their nodelist compiler must remove the
1-303 if they are a local call, and the -303 if they are not a local
call. Next, the baud rate.
-9-
The baud rate is a little hinky. You may have a modem that can make
a zillion (ok, only 14400) connect to my modem. But we leave THAT to
the modems involved. 9600 is the highest baud rate that is reflected
in the node list. A call placed by an HST modem to my system would
indeed connect at the higher rate if the software was configured
properly to do so. What follows the baud rate varies a great deal
based on the system configuration and the diligence of the local
net coordinator. These are called the FLAG information. For a
system running 9600 or faster, there must be a flag that indicates
the modem type in use. The combination of HST and V.32 connect
possibilities are indicated because I am using a Courier HST Dual
Standard that supports both. Last, we have the mailer software
type. In my case, this is SEAdog, and the XP flag provides that
information.
Last, you should understand the CM, #09 and MO flags. The CM
identifies a system able to receive mail (a 'crash' system) on
a 24 hour basis. The #09 indicates that the system is not a CM
system, but supports the Zone 1 (North American) zone mail hour
at 0900 hours Greenwich (Zulu, CUT, or whatever you prefer to
call it). A system with an MO flag is "Mail Only", and calling
it with normal comm software will get you nowhere, as there is
only a FidoNet mailer there - no BBS.
I strongly recommend that you have a look at the end of the
nodelist and find there a text section explaining the meaning
of all of the other possible flags. You should also be aware that
some NC's and hubs aren't very diligent about getting the right
flags into the list (with the exception of the #CM flag). You
should check your own entry to be sure it is correct in the
nodelist. A program like LIST.COM is a handy way to do this, using
the ind feature. Just search for Host,xxx where the xxx is
your net's number. Just below that, you'll find your own entry.
You may see a couple of "oddball" entries in the Nodelist. First,
there is the "Down" entry. This means that although the system may
still exist, it is either down due to technical or other troubles,
or the NC has been unable to communicate with it for unknown reasons.
Failure to be available for NetMail by your NC during Zone Mail
Hour may get you a "Down" notation in the list. Continued failure
to be available for contact during ZMH may cause the NC to remove
your entry from the list!
Also, there is the "PVT", or Private node. There are a few folks
out there that either don't want calls from anyone except their
NC or hub, or are running software that most other systems couldn't
connect with in the first place. These are discouraged, but when
included in the list, they are marked as PVT and their phone
numbers are generally unpublished in the list. The reason for their
inclusion is to allow you to know how to route mail to them via
their NC or hub. Yes, it's possible (and also common) to deliver
NetMail to one system by sending it to another for re-routing.
We'll cover this elsewhere.
-10-
FILE REQUESTS, FILE ATTACHES and other neat stuff
Besides the normal traffic of NetMail, EchoMail and the like, a typical
mailer system has a few more tricks up its sleeve that you may find very
useful.
One such feature is the File Attach Message. Although it is often
used to move a bundled up file of EchoMail, the File Attach Message
can be used to send a copy of any file between systems. When you
get your weekly copy of your NODEDIFF file from your Net Coordinator
or Hub, it is done by creating a special kind of message whose
subject is actually the path and name of a file. There is a special
bit set in order to do so - you can't just place a fully qualified
path\file name in the subject area and cause the file to be sent.
Either your mailer, message editor or BBS software will have the
ability or come with a utility that provides the file attach function.
This is not only a nice way to move FidoNews, the NODEDIFF files, and
other administrative items, but can be used between two nodes to
send out a new piece of interesting software, a copy of some config
file that needs debugging - whatever sort of file you wish to send.
Besides the File Attach Message, there is the File Request Message.
Sometimes, in order to abbreviate File Request, folks will use the
form " freq " or " f'req " instead. You'll often see someone
talking about freq'ing a file. This is the File Request.
As for the File Attach, one of your programs or associated utilities
will provide you the ability to create a File Request Message.
During any event that allows you to place a call to the system for which
you've set up a File Attach or File Request Message, your mailer system
will dial that system, and use the message to indicate to the other
system that a file transfer is desired. So long as the other system
hasn't included something like NO-FILES in the event, and as long as
the other system talks the same "language" as yours, the file transfer
will occur.
One word of warning about File Requests...
The FidoNet standards for such file transfers were cleaned up in late
1989/early 1990. Two internal protocols for handling such file transfers
exist and are in common use in FidoNet. Both are valid, although
not all systems support both methods. In fact, CERTAIN authors have
still, as of this date (October 1990), refused to support one or the
other of the standards. Alas, there are politics in Fido, Martha, and
you should be aware that of this date, two mailers in particular have
taken a path that makes them completely incompatible with the SEAlink
protocol for file requests. One occurred by accident due to problems
in interpreting what was once a vague standard, and seems to have given
up trying. The other started out with similar problems, and then
simply REFUSED to make any attempt at compatibility. They are, in
order, Front Door and D'Bridge. If you are using either of these
two mailers in what is, as of today, their currently supported
versions, you can kiss file requests with SEAdog mailers goodbye.
Both the "barefoot" Opus and Binkley mailers cover both standards,
the Binkley mailer being the option for non-Opus-BBS users. If you
are concerned about possible file transfers with a SEAdog mailer at
any point in the future, Binkley may well be your best choice of a
mailer. Ditto for using SEAdog. If you're concerned about transfers
to Front Door, and ESPECIALLY D'Bridge mailers, SEAdog in its current
form is going to present problems. Since rev 2.40 (+ mods) of
Binkley, Bink and SEAdog are happily talking like crazy to one
another.
-11-
ROUTING MAIL
It's possible to send a message directly to any system with a published
number in the Nodelist. This is due to the fact that all systems are
required to observe the minimum FTS-001 (Fido Technical Standards)
protocol that allows for the most basic mail packet to be transferred
between systems. However, an alternative is to send the same message
to the NC or hub of the destination node instead. Your mailer or
"packing" software will allow you to send a message destined for a
node to another system for re-transmission. It is ALWAYS acceptable
to send mail routed to another node's Net Coordinator if, for
whatever reason, you find any difficulty in connecting directly.
However, it is considered tacky to route through another system
without first obtaining permission from the other system. Moreover,
it is entirely possible that another system won't have the proper
routing installed to re-transmit your message to the destination
in the first place! Except for NC or hub routing, ALWAYS ask first!
ECHOMAIL, HOW IT WORKS
Most of the traffic moved through FidoNet is in the form of what we call
EchoMail. There are several other techniques for moving mail that are
in use by other networks, but we'll stick to the EchoMail model for our
purposes here.
Again, a few definitions are going to be helpful:
STAR SYSTEM / REGIONAL ECHO COORDINATOR
There are a few selected systems across the U.S. that act as "stars"
for FidoNet echomail. These systems supply cross-country connection
between the various nets by accepting and distributing mail between
each Region's primary system (often run by the Regional Echo Coordinator,
or REC for short). In the case of some of the larger nets, they are
connected directly to the "Star" systems, bypassing the Regional
Coordinator due to the load of mail involved. It might look something
like this (things tend to change frequently!), an abbreviation of the
real star system in use:
Western Star ------- MidWestern Star ------- Eastern Star
/ /|\ / /|\ /|\
/ | | \
etc A large Net | | \ etc
net is the 104 | | \
exception. / | \
/ | \
/ | |
/ | |
/ | |
/ | |
Region Region Region
14 11 12
|
etc | etc
/|\
/ | \ This is the more
/ | \ typical arrangement.
/ | \
Net Net Net
108 110 115
etc etc etc
-12-
Under the regions are typically the nets. Each net has its own primary
system, usually run by the Net Echo Coordinator (NEC for short), who
distributes the mail within the net. Often, the NEC appoints hubs to
help in distribution of the mail. This is especially important in nets
with a large number of systems and a large volume of EchoMail being
imported.
TAG LINE / ECHO TAG
Each message in an echo area must include information regarding the
specific echo to which the message belongs. This is placed at the
top of the message before exporting to the outside world, and is
used by all receiving systems to know in what message area the message
needs to be placed on the BBS. It is also used for making copies of
the message as needed (see below). This is called the Echo Tag, or
Echo Tag Line. Most BBS software does not display this information,
or strips it before placing the message in to the message base.
How is this mess kept straight??? Messages flying all over creation
and somehow, we manage to keep track of who needs to receive them and
who's already seen them. Enter the SEEN-BY line, and another piece of
useful information, the PATH line.
Although not used to figure out where things need to go, it is easier
to explain the whole procedure if we start with the PATH information
attached to each message as it travels its course. The PATH is simply
the list of systems through which any message has passed to get from
its originating system to the destination system. Since messages
will take different paths to reach different systems, each sees a
slightly different PATH line when the message is delivered. Let's
say, for example, that there are three systems that all share mail
between them (a radically simplified model of the real distribution
system shown above). Let's call these systems 100/1, 100/2, 100/3
100/4 and 100/5.
Let us further assume that 100/2 is handling all of the distribution
for mail between the three systems. In other words, all mail must
pass through 100/2, regardless of where it originates, and is then
passed on to the other two systems. In addition, we will assume
that 100/3 is 'hubbing' for 100/4 and 100/5.
The real topology of our "mini-net" would look like this:
100/2
/ \
/ \
100/1 100/3
/ \
/ \
100/5 100/4
-13-
A message from 100/1 that is shared by all other systems would pass
to 100/2 first, then to 100/3 and on to 100/4 and 100/5. The PATH
information will always show how the message got to where it finally
was posted on any system. For example, the message from 100/1 shows
only 100/1 on the PATH line of the message as it leaves 100/1 bound
for 100/2. The 100/2 is then attached before the message is routed
on to 100/3. The 100/3 is then attached to the message before it is
forwarded to 100/4 and 100/5. At 100/5, then, the path information
should look like this:
PATH 100/1 100/2 100/3 100/5
This is often abbreviated by software, making the assumption that
if no net number is provided, it is assumed to be the same as the
last listed net. In this (the most common) case, the PATH information
would include our net number only once (since no others are involved
in this message) and would simply be
PATH 100/1 2 3 5
If a message were originated at 100/2, the path at 100/4 would
appear as
PATH 100/2 3 4
and at 100/1, it would simply be
PATH 100/2 1
Where multiple nets are shown, paths might look like this:
PATH 100/1 2 13/1 104/1 115 114
This shows that a message was passed up from 100/1 to another node (2)
in that net, on to a net 130 system, to net 104, and down through a
couple of nodes in net 104 to the final destination of 104/114.
The next item of importance is the SEEN-BY line(s). This information
is used by each system along the PATH to determine who has seen the
message, and for whom copies need to be made. As a message is processed
by any system, SEEN-BYs are added for any systems for which a copy is
made by the processing system. Using our 5 node example above, a message
moving from 104/1 to 104/5 would function this way:
Message as sent from 100/1 SEEN-BY 100/1 2
Message as sent from 100/2 SEEN-BY 100/1 2 3
Message as sent from 100/3 SEEN-BY 100/1 2 3 4 5
Note that since 100/3 needs to make copies for both 100/4 and 100/5,
it adds the SEEN-BY for both nodes for which it has made copies.
Each system should provide itself in the SEEN-BY information when it is
the originating system. Why? If it did not do so, the next system that
received the message would send a copy back!
The method of deciding who should be receiving copies is usually one format
or another of a copies called AREAS.* Various software packages like to
see this file in slightly different formats, but the essential information
there is the echo tag with the list of nodes for which that system is
responsible for making copies.
-14-
So, to wrap it up, the PATH shows how the message got from the originator
to anyone receiving the message, and the SEEN-BY shows what systems copies
were made for along the way.
Checking for the sources of duplicate messages is simplified by the PATH
information. By observing the two (or more) paths that the message may
have taken to get to the destination, it is often easy to tell who has
been sending the message to the wrong system(s), or fouling up the SEEN-BY
information along the way. Note that clobbering SEEN-BY information or by
making it unreadable to some other system is guaranteed to create
duplicate messages. Although the PATH line must always begin with a
"Control A" (a hex 01), the SEEN-BY line should NEVER start with one of
these. Many systems won't "see" the SEEN-BY information if the line(s)
start out that way!
ORIGIN LINE
The origin line can be used by the sysop to provide any information
that helps identify the system that is originating the message. This
information always starts with a '*' and a space, and is typically
followed by the name and phone number of the originating system. There
are some sysops who also include a cute saying here, and this is
generally accepted, but beware of including messages with "political
content", as it is appended to every message a user generates in an
echo, and that user will not see the origin line after entering the
message! User's have been known to become hostile when their messages
are suffixed with things they're not in agreement with! Do NOT
include your net/node number in the origin line if your software will
add this automatically. All too often, new sysops add this to the
origin line info, only to discover it is being duplicated by the
software. Also, please note that much software won't display an
origin line of >80 characters total, so remember that when you create
your message, space must be left for the net/node and "* Origin"
information!
TEAR LINE
This line starts with a '---' and is appended by either the message
editor/BBS software, the packer or the mailer. Some software will
delete any previously entered information and replace it with its own
as your message passes between your various programs.
Here's the "readable" portion of an EchoMail message, including a couple
of items we haven't yet discussed (note that not all software allows the
viewing of these items, even though they exist in the message). The
control A (01hex) character will be represented by a "^" so that you can
see where it would appear in the message.
ECHO: ECHONAME
^EID: eid info
^MSGID: msgid info
Text of the Message
* Origin: Origin line information (zone:net/node)
--- tear line information
SEEN-BY seenby nodes list
SEEN-BY continuation of list if required
^PATH path information
-15-
The EID and MSGID information is designed to help your software check
for duplicate messages. Most times, this is simply a check sum of the
body of the message, often including the header information (TO:, FROM:,
etc.)
When quoting any message with a message editor, it is important that you
not accidently leave any of the EID, MSGID, SEEN-BY or PATH information
resident in the message without something to preface it that would keep
software from recognizing it. For example, if you have a need to quote
the PATH information, be sure to delete the little smiley-face that
appears for the 01hex, and stuff something in front of it (such as a ">")
just to be safe!
CROSS-LINKS
As you can imagine, a fouled up SEEN-BY line or two in a message can
cause a great number of duplicate messages to be created. Unless a
system using the EchoMail technique described above has the full
necessary SEEN-BY information, a system is likely to start generating
copies for people that should have been listed, but aren't. Broken
software can be a real pain here!
There IS an exception to this rule, and when used, it must be used
VERY carefully to avoid duplicates! This is the Cross-Link method
of moving mail. Rather than dropping down the normal tier of nodes,
the cross-linked mail message is transmitted "across" a number of
hub nodes of equal position within the structure. This is used to
avoid having to move mail up and back from the top level system in
any structure. Things move a bit faster this way. Let's say that
we have those old 100 series systems again, each *normally* being
served their daily doses of mail via the Net Echo Coordinator at
100/1.
regional or star feed
|
100/1
|
|
/|\
/ | \
/ | \
/ | \
/ | \
/ | \
100/2 100/3 100/4
/ | \ / | \ / | \
to other nodes served
Normally 100/2, 100/3 and 100/4 would only send EchoMail between the nodes
they serve as hubs and 100/1, the Net Echo Coordinator as in the diagram
above. However, for those echos that are "Cross-Linked", this first
tier of hub systems are ALSO "cross-linked" to each other!
-16-
regional or star feed
|
100/1
|
|
/|\
/ | \
/ | \
/ | \
//---^---\\
// | \\
100/2--100/3--100/4
/ | \ / | \ / | \
to other nodes served
When a message appears on 100/2 that is originated on 100/2 or one
of the nodes it serves, where the echo in question has been
declared a cross-linked echo, 100/2 will immediately make copies not
only for any of the nodes it serves, but also for 100/1, 100/3 and 100/4.
This makes it unnecessary to first move the message back up to 100/1,
wait until 100/1 unpacks and creates copies for 100/3 and 100/4, and
can make contact with these other two top tier systems.
This is CAREFULLY controlled (until someone screws up!) by making sure
that all other top level systems are included in the AREAS file of each
top level system. In the case of 100/2, the AREAS entry for a cross-linked
echo in the system shown above would appear as follows:
100/1 100/3 100/4 100/xxx 100/xxx (where xxx are the other nodes
that 100/2 hubs for).
A fouled up AREAS file on the part of ANY of the systems that play a
direct part in the cross-link will cause duplicates to be created
quickly. Picture this: 100/2 forgets to include 100/1 in his AREAS
file. When 100/3 and 100/4 see the message, they'll BOTH see that
100/1 isn't in the SEEN-BY information, and BOTH of them will make
copies for 100/1. Bummer.. don't let it happen to you!!!
-17-
There are numerous utilities in use out there for handling the archiving
and unarchiving of mail files. For SEAdog users, ARCMAIL (in one of its
various revisions) is often used. Users of other BBS and mailer systems
use this or other utilities.
Problem: Not all utilities are flexible about the file name extension used
for archived mail files. Not all systems can accept all extension
variations! Your mail files *may* not be unpacked by the receiver
under certain circumstances!
Problem: Some of the utilities used on other systems will create packets
improperly, generating "short packets".
File extensions:
Currently the following have been noted as file name extensions that are
being generated by various utilities:
A) FILENAME.ddn
dd="MO" (never changes) n=sequential number
B) FILENAME.ddn
dd=day of week (SU, MO, TU, WE etc.) n=sequential number
C) FILENAME.ddx
dd=day of week (SU, MO, TU, WE etc.) n=sequential number/letter
depending on the half hour of the day during packing (i.e., it
will be 0-9 or A-Z depending on the time of day)
D) FILENAME.xxx
xxx=minute of the month in base 36 (using 0-9 and A-Z in all
three positions)
Don't be surprised if the FILENAME.ddn formats don't follow the
actual day of the week. Some just cycle through 10 digits in the
'n' position and then begin the next day regardless of the day of
the week when the file is created.
Formats A,B and C seem acceptable to most systems. This comes from
observing the experiences of the wide variety of software in use in
Net 104.
IF you are in contact with a system that generates the infamous "short packets"
in archived mail files sent to you, note that some utils will choke on
these, and you will be unable to extract your mail from them! Contrary to the
comments of some, these short packets are NOT properly built according to
FTS (FidoNet Technical Standards) format!
-18-
HOW ARCHIVE FILES ARE NAMED
(apart from the extension, which we've already discussed):
Incoming and outgoing archived mail files use the following method for
the root portion of the name:
NNNNnnnn.ext
NNNN=sender's net number - receiver's net number
nnnn=sender's node number - receiver's node number
In both cases, the result is always expressed in 4 hexidecimal
digits.
Example: I am node 104/114. I am having mail transfers with
node 363/18. If I send an archived bundle to 363/18,
the result will be:
104-363 114-18
= -259 96 decimal
= FEFD 0060 hexidecimal
= FEFD0060.ext filename
If 363/18 sends something to me, on the other hand:
363-104 18-114
= 259 -96 decimal
= 0103 FFA0 hexidecimal
= 0103FFA0.ext filename
Both archiving and mailer software make use of this convention to determine
where things are headed for. However, if both incoming and outbound files
are present in the same directory, there can be some confusion! AVOID THIS!
The REAL problem is where both result in valid node numbers! I got caught
by this problem when working with node 104/115. Mail he would send me would
look like mail *destined* for 104/113. If I didn't take time to unarchive
incoming mail for 104/115, it would be forwarded to 104/113!
Watch for this, as neither archivers nor mailers really know which
direction things are headed! How did this happen?
104-104 115-114
= 0 1 decimal
= 0000 0001 hexidecimal
= 00000001.ext filename
Now, if this were an incoming file, it would be correctly interpreted as
a file *coming* from 104/115. But what if the mailer was asked to
deal with an outbound file instead? You'd get the following!
104-104 114-113
= 0 1 decimal
= 0000 0001 hexidecimal
= 00000001.ext filename
-19-
Well, you can see that an incoming file called 00000001.ext means it is
arriving from 104/115, but an *outbound* file to 104/113 has the same
exact name! Since archivers and mailers use your net number as you've
described it in some configuration file for these computations... well, you
can see how you can get in hot water in a hurry.
The fellow at 104/113 and I suffered through several days of this before the
obvious occured to me. Don't leave someone else as confused as I did.
THE SOLUTION TO ALL OF THIS IS TO AVOID PLACING INCOMING "FILES" AND OUTGOING
"MAIL" (INCLUDING FILES) IN THE SAME DIRECTORY!!! Use different directories
by specifying them differently in the configuration file used by your software.
-20-
How to Apply for a FidoNet Node Number
Although written specifically regarding FidoNet procedures, you'll find
that much of the information here in 101WAYS is applicable to beginning on
any amateur network. The same is true for the process of obtaining and
using your own node number.
First, you'll need to locate the Net Coordinator (sometimes known as the
NC) for the net you want to join. In the case of FidoNet and some others,
it is preferred that you join the net nearest your physical location unless
there is a substantial reason (long distance to nearest hub, etc.) that
makes it financially more reasonable to go outside your local area.
In order to find the NC, just locate any bulletin board in your area that
supports FidoNet (or your choice of another network). You'll want to talk
the local sysop out of a copy of the current Nodelist either via disk or
download. Quite a few network sysops make these lists available for download.
Next, you'll need to create a message with your software to the NC who
will always be the /0 node of any network. For example, let's say that you
local or nearest network is #104. You'd send your application for a node
number to 104/0. During the time until you receive an official number, use
something like node number 999 or 9999 to send your request. The request
should include at least the following information:
Your name and voice phone #
The name and location of your board
The phone number of your board
Hours of operation
Whether or not you are able to handle continuous (crash) mail
Baud rates supported [if 9600+, please include which version(s)]
Which mailer software you are using
Each of these items is important as all but your voice phone # are required
items for your own Nodelist entry.
After sending your request, you should be available for a NetMail response
from the NC during the hours you've specified for your system. He will
return with your net/node address. Don't forget that people take vacations
and the like, so be patient. However, it should NEVER take more than three
weeks to get your node number. If it does, follow up with another message
and perhaps a voice call.
-21-
SECURITY ISSUES
FidoNet mailers most often make available the feature of the
"session password". Any two systems may agree in advance on a particular
password, and install it on their systems. Let's say that system 104/A
and 104/B agree and install a password (the same password would be
used on both systems). If 104/A calls 104/B, the mailer software makes
notices that a password is being used when calling 104/B, and presents
it's password to 104/B. If 104/B finds that the password exists in
its own list, it continues the session. Note that 104/A doesn't ask
for a password, as it assumes that since *it* dialed the call, the
system on the other end is the real one!
If some other system comes calling under the guise of 104/A, and is
unable to provide the mutually agreed upon password, 104/B will hang
up on this intruder - no file transfers of data will take place. Of
course, this would also occur if one or the other systems accidently
installed the wrong password, or no password for the other system.
Obviously, both systems must agree and continue to employ a password
for any transfers to take place.
Why? Well, there are some naughty boys and girls out there who'd like
nothing better than to create problems for someone - often just for
the sake of doing so. The session password guarantees that when
someone comes calling to deliver and pick up mail that they really
are who they claim to be... simple as that.
In Net 104, we have a local net sysop's echo. One of the rules
established by the echo moderator is that in order to participate
in the echo, all transfers to or from another system of the echo
must be done within the confines of "session passworded" sessions.
This provides our net with some degree of security, keeping some
ne'er-do-well from gaining any insight into our private conversations
regarding how we're operating the net, problems (and solutions) with
users, etc. I STRONGLY recommend it for any system with which you will
be regularly moving mail. Of course, it is impossible to establish
session passwords with every system that might ever place a call to
your system. That, in itself, represents a problem, but with a bit
of manual effort on your part, this can be handled as well.
-22-
First, you should be aware that it is relatively easy to do ALL of the
following on a good many netmail capable systems that have not been
properly configured for good security protection:
o Messages sent into echos that appear to be from you, on your system, that
were sent by other persons. All path and seen-by information is perfect,
and, in fact, the message is sent by your system without anyone logging
on to your system. If you have session passwording between you and your
echo hub, all the better, as the message will pass straight through into
the echo via that path! You may never see the message posted on your
own system, however!
o Files sent by your system to another system. Can be anything that the
user of the other system can correctly identify a path for, regardless of
whether or not you have set that path up for file requests.
o Destruction of your inbound echomail or netmail archive files if you have
not yet processed them.
o Bad NODEDIFF files - one clever thought was to change the phone number of
a sysop's echo hub to the sysop's own home voice telephone number. In
another case, one 15 year old changed many numbers in the net to 911.
You can imagine the problems this caused with emergency services.
o A wide variety of other nasty things, including having your system make
expensive 976- calls, forward mail to Norway... you name it.
These things are possible due to the fact that many sysops ordinarily un'ARC
archived NetMail files without manually reviewing their contents. I won't go
into the techniques involved in causing any of the above, but suffice it to
say, it is a relatively easy matter to do these things, and I have tested
most of them in cooperation with other systems in my net.
So, how do you protect yourself? The sysop has only one recourse
against such bad behavior... and by the way, it doesn't require another Fido
sysop to accomplish this ... anyone with a working knowledge of some mailer
software and a nodelist could probably accomplish what I've outlined. No, it
isn't session passwording, although that is essential in order to make the
technique described work.
This technique allows you to automate unpacking and tossing of mail from your
regular sources - if you use session passwords. It avoids automatic unpacking
of potential 'trojan' netmail archives, and offers some measure of protection
against them.
The downside to this method is that incoming netmail must be moved to the
secure directory and un'arc'd manually and inspected before you allow it to be
posted to your system. This may cause some delays on incoming traffic for
your users if you allow them access to netmail for their own use.
CHECK YOUR SOFTWARE! If it allows multiple directories to be used for
inbound archived mail files, USE THEM! You should only automatically
unpack mail from those systems with which you regularly do business, and
for which you have session passwords installed. ALL OTHER inbound
archived mail should be shuttled off to a separate inbound file area
and should be INSPECTED carefully before you move these inbound messages
into the regular message area for processing.
i
INDEX
Index to be created at Revision 1.0 (release) of this document).
