FidoNet Glossary

This is our glossary of technical terms specific to FidoNet.

FidoNet Technology Network: Any network using FidoNet standards for addressing, mail packets, mail sessions, node lists, etc.

FTN node addresses are like phone numbers, they are made up of multiple components (four usually, but sometimes three and sometimes five).

The main four components are: zone, net, node, and point. Each component is specified by a decimal (base-10) number, separated by symbols (no spaces):

Zone:Net/Node.Point

The zone represents the continent (if FidoNet) or the network number (if other FTN network). All FidoNet nodes in North America have a zone 1 address. When the zone is specified in an address, it is the first component and must be followed by a colon. If the zone is not present in an address, the local system's zone is assumed.

The net represents the network number of the FTN node. Duplicate net numbers may exist between zones. If the net number is not present, the local system's net is assumed.

The node number specifies an exact FTN node within a network. The node number is the only required element of an FTN node address. The point is an optional component which specifies a sub-node that does not directly receive mail and is also not listed in the main FTN node list, but instead gets all its mail from its boss-node (zone:net/node.0). When the point is not specified, 0 (zero) is assumed (i.e. 1:2/3 and 1:2/3.0 are identical) which indicates the system with that address is not a point node.

Zones can be grouped into named domains (e.g. @fidonet), but FTN domains are pretty rarely used in the twenty-first century.

A 2D (2 dimensional) address refers to an FTN address containing just the net and node numbers (e.g. 103/705).

A 3D (3 dimensional) address refers to an FTN address containing the zone, net, and node numbers (e.g. 1:103/705), specifically excluding the point number if it exists.

A 4D (4 dimensional) address refers to an FTN address containing the zone, net, node, and optional point numbers (e.g. 1:103/705.1).

A 5D (5 dimensional) address refers to an FTN address consisting of a standard 3D or 4D address with an appended “@domain” (e.g. 1:103/705@fidonet).

All FidoNet node-listed systems are nodes of the network.

Normal Nodes do not have a point value, so a .0 suffix on their address is implied. The addresses 1:103/705 and 1:103/705.0 are the same node, a normal node (sometimes also called a boss node).

Point Nodes (nodes with non-zero point value) may only directly connect and communicate with their boss node. The boss node of a point node with the address 1:103/705.1 would be 1:103/705 (the .0 point value is implied). Point nodes are not listed in the network's official nodelist. Some network regions distribute a pointlist containing only point nodes.

A Boss Node is just a normal node that has one or more point nodes for which they are responsible to deliver and receive messages and files.

A Linked Node is a node which is linked with your system in some pre-arranged way and is reflected in your SBBSecho configuration (e.g. packet password, AreaFix password, packet type, archive type, etc.). Linked Nodes may also be linked with one or more EchoMail message areas on your system as reflected in your Area File.

AKAs are additional/alias addresses for an FTN node. Some times you'll see the Main/Primary address also referred to as an “AKA”, but just know this just means an FTN address, possibly one of many, that may be used to reach a single FTN node.

If a node belongs to multiple FTN networks (e.g. FidoNet and one or more “othernets”), then they will usually have their FidoNet address (Zones 1-4) as their Main address and the “othernet” addresses as their AKAs.

An Uplink is a Linked Node which is your system's pre-arranged conduit to the rest of the message network (a.k.a. your hub).

A Downlink is a Linked Node which your system “feeds” messages and for which your system is responsible for routing received messages from.

A FidoNet Mailer is the software component which transfers FidoNet Packets between systems (“FidoNet nodes”).

In the dial-up BBS days, it was common for a FidoNet mailer to answer the phone modem to determine if the incoming “caller” was another FidoNet mailer or a potential user for the local BBS. If the caller was determined to be a user (e.g. due to timeout or the user hitting the ESC key), it would launch the BBS program and pass control of the call to the BBS:

Press the ESC key twice to access the BBS.

These types of mailers (e.g. FrontDoor, D'Bridge, Portal of Power, etc.) were often called “front-end mailers” and are fairly obsolete today, replaced by modern mailers that support Internet-based FidoNet packet transfers (e.g. using BinkP over TCP/IP).

If you are using FrontDoor, InterMail, D'bridge, SEAdog, Dutchie, or any other ArcMail *.MSG attach-style mailer, you are using what we will refer to as an “ArcMail/Attach-style Mailer”. Support for ArcMail/Attach-style mailers has been deprecated in SBBSecho v3 and unless there is anyone coming forward to test what support does remain, it will be removed in the future.

If you are using BinkD (Binkley daemon), Argus/Radius/Taurus, BinkleyTerm, Portal of Power, or any other mailer that uses Binkley-Style-Outbound (BSO) directories and FLO/CLO/HLO/DLO files (a.k.a. FLO-files), you are using what we will refer to as a “Binkley/FLO-Style Mailer”.

It is very important that you select the correct “Mailer Type” in the echocfg utility (or sbbsecho.ini file).

BinkP is the BinkD Protocol, a TCP application protocol invented by Dima Maloff in 1996 and later standardized by the FTSC, for transferring files (primarily, FidoNet Packets) between Internet hosts over IP. The BinkP protocol was originally implemented as an ad-hoc protocol for the transferring of files between instances of the Binkley Daemon FidoNet mailer (BinkD). The protocol was later adopted by other FidoNet mailers and later became a FidoNet standard.

Point-to-point (usually person-to-person) directly-delivered or routed messages (now more commonly referred to as “e-mail” or just “mail”).

Group or conference messages of a particular subject matter (a.k.a. Message Area). Usually distributed on a regional or continental scale (e.g. FidoNet Zone 1 backbone). FTN style echomail areas have a unique name associated with them to distinguish each area from the others. These agreed upon area names are called Area Tags or Echo Tags.

To toss EchoMail packets or messages means to import the packed messages into your BBS's local message bases where your users can read and reply to the messages. FidoNet EchoMail programs, like SBBSecho, are often referred to as “Tossers” for this reason.

To scan message bases means to export locally-posted messages from your BBS's local message bases into EchoMail packets to be sent to your upstream link (hub) and any downstream linked nodes you may have.

An FTN packet is a group of one or more messages contained in a single uncompressed file. Packets may contain echomail and/or netmail messages. Packets files usually have a .pkt extension, although outbound NetMail packets for Binkley/FLO Mailers will have .?ut extensions (where ? is either o, c, d, or h, e.g .out, .cut, etc.). The first eight characters of the filename may be anything, but are usually decimal or hexadecimal digits representing the date and time the packet was created.

You can use the digital man's pktdump utility to view packet headers and help identify and fix problems with inbound and outbound packets.

If SBBSecho cannot process an inbound packet file, it will rename the file, giving it a .bad extension. Checking the SBBSecho log file (e.g. data/sbbsecho.log) for the reason for the Bad packet detected, if you can then remedy the problem and rename the *.bad files to *.pkt, SBBSecho will rediscover and attempt to re-process the packet files. Alternatively, you can just delete .bad packets and perform a hub re-scan if you expect the packets contain only EchoMail (no NetMail) and you want the missing EchoMail messages from the packets.

1. File length is shorter than a packet header (58 bytes)
2. Packet terminator (0x0000, 2 NUL bytes) missing from end of the file
3. File read failure (e.g. permissions or file locking issue)
4. Source address does not match expected address (e.g. for packets found in inboxes)
5. Packet header cannot be parsed (e.g. is not a type 2 packet header)
6. Packet header contains incorrect packet password
7. Packet contains one or more “grunged messages” (e.g. packed message type is not 2)

An FTN bundle is a single file archive of one or more (usually compressed) packets. Bundles will have file extensions where the first two characters represent the day of the week the bundle was created (MO, TU, WE, TH, FR, SA, and SU) and the third character of the extension is a number or letter. The first eight characters of the filename may be anything, but are usually hexadecimal digits representing the FTN node address (or relative address) of the system that created the bundle. SBBSecho changes the file extension of bad inbound bundles to .?_? or .?-? (e.g. *.mo0 would be renamed to *.m_0).

AreaFix is a synonym for area manager (the very first FTN area manager program was called “AreaFix”). Area manager capabilities (remote adding/removing of areas, changing compression type, etc) are built into SBBSecho, so therefore no external area manager program is required. If you are not an FTN hub, then the area manager portion of SBBSecho will probably not get much use on your system. The Area Manager process has also be called a “Conference Manager” (ConfMgr).

Due to historic FTN message and packet header limitations, some message metadata was defined in body text of each message in the form of “control lines” (often called kludge lines). Each control line begins with a Ctrl-A (ASCII 1) character followed by a keyword, a space, some optional data, and terminated with a carriage return (ASCII 13) character. Different control line keywords are used define different metadata values.

Kludge/control lines are not normally displayed to messages viewers (users), but most programs have an option to view the control lines where it is customary to replace the Ctrl-A character with an @ character.

Synchronet stores FTN control lines in its message headers, so you must use the Terminal Server operator->View Header command (H), to view a message header to see the metadata that may have been received via FTN kludge lines.

Some control lines are only expected in EchoMail messages, some only in NetMail, and some in either.

• Reference Library