FidoNet Files

This page contains details regarding the names and contents of files used in FidoNet networking (netmail and echomail).

One of the most confusing aspects of FidoNet Technology Networks is the various files involved and their naming schemes.

Since FTN software was mostly created during the days of MS-DOS and PC-DOS, the file names were limited to the file name formats supported by these ancient operating systems. Specifically, eight base characters and a three character suffix (extension), separated by a period (or “dot”).

This is often referred to as the 8.3 file naming format and this limited name space resulted in some interesting (and often confusing) file naming schemes by FTN programs (e.g. BBSes, mailers, and echomail programs).

Here's a break down of the files involved and their naming:

Stored Message files are often referred to as “.msg files” as the file name is a positive non-zero decimal number with a .msg suffix (e.g. 1.msg, 2.msg, etc.) with a single message stored in each file.

Stored Messages contain a binary header with fixed-length header fields, followed by the body text, terminated with an ASCII NUL ('\0') character. You SHOULD NOT attempt to view or edit Stored Message files with a program designed to view or edit plain text files (e.g. Notepad).

These files are usually used for NetMail (private user-to-user messages between FTN nodes), but are sometimes used for Bundle or Packet file attachments (e.g. for FrontDoor/Attach- style mailers). The attached file is actually sent separately and usually stored in a different directory, but is referenced (pointed to) by a particular Stored Message.

Stored Message files are usually stored in a “netmail” sub-directory or folder. Some echomail programs or mailers use the 1.msg file as a special “highwater marker” and the “real” Stored Messages are stored in 2.msg, 3.msg, etc.

The contents of a Stored Message are defined in the FTSC document: FTS-0001.016.

Binkley/FLO-style mailers also support NetMail messages with attachments, but do not support Stored Messages. Binkley/FLO style mailers always send NetMail messages packed into Packets, so there is no “netmail” sub-directory of folder normally associated with a Binkley/FLO-style mailer and they don't deal with Stored Messages (a.k.a. “.msg files”).

An FTN Packet file contains a Packet Header, followed by one or more Packed Messages.

Packets may contain NetMail or EchoMail messages.

Packet files have a .pkt suffix (SBBSecho names Packet files “in process” with a .pk_ suffix). The base file name of a Packet can actually be *anything*, but is usually a numeric time stamp of some sort. SBBSecho uses “DDHHMMSS” (where each pair of letters is a 2-digit zero-padded decimal number representing the Day of the month, hour of the day, minute, and second at the time the packet was created) as the base file name when creating Packet files. The important thing is that the Packet files have unique names. The actual elements that make up the base file name are not important.

The exception to this Packet file naming scheme is: *outbound* NetMail Packet files pending transmission by Binkley/FLO-style mailers are named:

NNNNnnnn.Out

where “NNNN” is the destination network number as a 4-digit zero-padded hexadecimal number, “nnnn” is the destination node number as a 4-digit zero-padded hexadecimal number and “O” is a single character indicating the “status” of the packet: either (C)rash, (D)irect/Immediate, (H)old, or n(O)rmal.

Binkley/FLO-style mailers actually rename these Packet files to *.pkt before they are sent to a remote mailer.

The Packet Header and Packed Messages stored in a Packet file are defined in the FTSC document: FTS-0001.016.

Contrary to popular mistake, Packet files themselves are *not* compressed.

(a.k.a. ArcMail Bundle)

A Bundle is an archive file (typically created with PKZIP or similar archive program), containing one or more Packet files with a common destination address, usually compressed, though the file will not have a .zip or otherwise common archive file name suffix (more about that in a minute).

The Bundle file name suffix must be constructed from the first 2 letters of the current day of the week at the time the bundle was first created, followed by an alphanumeric character. The trailing alphanumeric character is incremented if a Bundle file with the next logical file name already exists (e.g. .Su0, followed by .Su1, ... .Mo0, ..., all the way to .SaZ).

Since the Bundle file name suffix does not indicate what type of archive program created the file (i.e. the format of the file), it is necessary for the receiving echomail program to either be configured to use a specific format for Bundle files received from a specific FTN node, or the echomail program must inspect the binary “signature” contained in the first few bytes of the file to automatically detect the archive format.

The Bundle file name suffix may contain upper and/or lower case characters.

The Bundle base file name is created by subtracting the destination FTN network and node number from the source network and node number and representing the result as 4-digit hexadecimal numbers. Example:

NNNNnnnn.Mo0

where “NNNN” is the 4-digit zero-padded hexadecimal result of subtracting the destination network number from the source network number and “nnnn” is the hexadecimal result of subtracting the destination node number from the source node number.

If the destination network or node number is greater than the source number, then the result would be a “two's complement” representation of the negative result.

For example, if the source address was network 103, node 705 (represented as 103/705) and the destination address was 200/1, then the Bundle base filename would be:

FF9F02C0

Explanation (network part, first four characters):

103-200 = -97
-97 = FF9F (hexadecimal)

Explanation (node part, last four characters):

705-1 = 704
704 = 02C0 (hexadecimal)

Another permuation of this scheme is used when the destination address is a “point” address (e.g. 200/1.2). In this scheme, the “NNNN” portion of the base filename is always “0000” and the “nnnn” portion is “pPPP” where “PPP” is the destination point number as 3-digit zero-padded hexadecimal number (e.g. 0000p002).

Hexadecimal numbers can be made from either upper or lower case letters (A-F), so case is not significant.

(a.k.a. File Attach files)

Flow Files are unique to Binkley/FLO-style (a.k.a. Binkley-Style-Outbound, or BSO) mailers and are not an FTN standard. Flow Files are control files containing plain text (so they can be easily viewed or edited, unlike the other file types described in this document).

The file name of a Flow File is usually in the format

NNNNnnnn.Flo

where “NNNN” is the destination node number as a 4-digit zero-padded hexadecimal number, and “nnnn” is the destation network number as a 4-digit zero-padded hexadecimal number, and “F” indicates the “Status” of the Bundles or Packets listed in this file: (C)rash, (D)irect/Immediate, (H)old, or F, for “Normal”.

Another permuation of this scheme is used when the destination address is a “point” address. In this scheme, the base file name is the destination point number as an 8-digit zero-padded hexadecimal number and the file is placed in a sub-directory of the normal “outbound” directory, named:

NNNNnnnn.pnt

where “NNNN” is the destination node number as a 4-digit zero-padded hexadecimal number, and “nnnn” is the destation network number. So, for example:

outbound/006702C1.PNT/00000001.FLO

would be the name of a Flow File listing files destined for FTN address: 103/705.1 (in the same zone as the sender).

Flow Files for destination addresses in a *foreign* zone are placed in a different “outbound” directory with a suffix of the destination zone number represented as a 3-digit zero-padded hexadecimal number.

Hexadecimal numbers can be made from either upper or lower case letters (A-F), so case is not significant.

Each line of the Flow File describes an outbound file (typically a Bundle or Packet file , but technically, any file) that is pending transmission to a remote FTN node. The first character of the line indicates whether or not to delete or truncate the file after its been sent (i.e. '#' indicates truncate, '^' indicates delete).

Snippet explaining “Flow Files” from the BinkleyTerm v2.60 User Guide (BT-USER.TXT):

Use File names to control traffic The driving forces of outbound traffic are file names! You'll have a special sub-directory set aside just for packets, compressed mail packets (Bundles) and other network files. This sub-directory belongs to BinkleyTerm, which will maintain the directory for you. It's a good idea not to play with this area unless you know exactly what you're doing.

Note also that when zoned operation is active (BinkleyTerm default) there are separate outbound areas for each zone. The default outbound area (for your zone) and one additional area for each other zone you deal with. The names of these additional areas are simply the outbound area name, with a three-digit extension that is the zone number in hexadecimal with leading zeroes. See “ZONE SUPPORT” on page 33.

The file names of the packets tell BinkleyTerm how to treat the different packets. Here's a typical packet name:

00680024.OUT

That says that the packet is for 0068/0024 (in hexadecimal) or 104/36 in more familiar terms. The .OUT means it is a Normal packet.

Other packet extensions include:

One nice thing is that you can manually change the file extension if you need to, or you can use fancy utilities such as AMAX or BONK to do this sort of thing for you on your command.

For the remainder of this section, we'll assume that you'll be using oMMM as your mail packer. As mentioned previously, you probably will be using another program that has oMMM-like functionality; it depends on your environment.

The oMMM program knows about these extensions and creates them based on information you put into the oMMM control file. You'll have statements like this:

NormHold 124/102

Any messages you enter to 124/102 would be turned into a .HUT packet file, placed into the outbound area, and BinkleyTerm would hold that packet for 124/102 to call and pick it up. Files are also sent through FidoNet compatible networks. oMMM builds and maintains a file that tells BinkleyTerm what files to send (or hold) for whom. A typical 'file attach' file might be named:

00680024.FLO

This would designate a that there is a file waiting to be sent to 0068/0024 (in hexadecimal) or 104/36 in more familiar terms. The .FLO says it is a Normal file attach. File attach files are also called 'flow files' - named after the .FLO file extension.

Other flow file extensions are:

A flow file is just a text file. It contains a list of files that are to be sent to another system:

#c:\binkley\outbound\0000fc9c.mo1
^c:\myfiles\wizzle.doc
 c:\pascal\notes.doc

The # prior to a flow file entry says to truncate the file to zero-length after successfully sending the file to the remote system. This is normally only employed when sending compressed mail (archived mail, a.k.a. Bundles) to the remote. The ^ prior to a flow file entry says to delete the file after sending.

The oMMM program (or the packer of your choice) will put messages into archives for you. Details on how this is done can be found in the EchoMail processor/message packer documentation. The point is that these packers combine the functionality of “generating packets” with that of traditional standalone programs like ARCmail.

So here's a practical example. Say I enter a message to Rod Lamping at 104/610. I mark the message as KILL/SENT when I enter it. I also enter the message designating a file to attach to Rod, named

C:\FILE\REQ\FOOBAR.ARC.

I then enter a message in an EchoMail conference. My conference host is Phil Kaiser at 104/904, for whom I hold my mail for pickup.

Among other things, I have two lines in my oMMM control file:

NormCM 104/610
OneHold 104/904

NormCM tells oMMM to mark the message as Continuous Mail (since Rod runs a mailer 24 hours a day). 'OneHold' tells oMMM to archive the mail to 104/904, and mark it Hold-for-Pickup.

oMMM users should refer to the oMMM documentation for the full set of available oMMM control file statements.

First, my EchoMail utilities are run to turn EchoMail messages into Normal packets, and place them in the outbound area for processing by oMMM. Next, I execute oMMM. It first scans the NetMail message area (where I entered my message to Rod) and turns new messages there into Normal packets, and if there are files attached, it creates Normal flow files. oMMM's second step is to use its control file, and apply the statements in the file against the mail in the outbound area that is marked as Normal.

Since I have Rod's board listed as NormCM, oMMM renames the file extension of the Normal packet and flow file for Rod to .CUT and .CLO respectively, for Continuous Mail.

Since I have Phil's board listed as OneHold, first oMMM archives the packets to Phil, then creates a flow file with a file extension of .HLO for Hold- for-Pickup.

I would then have the following in my outbound area:

00680262.CUT             Message to Rod
00680262.CLO             Flow File to Rod
00680388.HLO             Flow File to Phil
0000FC9C.MO1             Archived Message to Phil

For more information on how oMMM or your processor/packer works, refer to its specific documentation.

Snippets from the BinkleyTerm 2.60 Reference Manual (BT-REF.TXT) explaining outgoing file requests and Binkley/FLO style outbound directories for point nodes.

These can be generated by BinkleyTerm or by using one of the many utilities designed for the purpose, such as Amax, Bonk, Please, etc. Any Opus-compatible file request builder can be used with BinkleyTerm. You may also manually build file requests. They are a single-line flat ASCII text file, and are named in the same manner as packets (refer to the User Manual section “How BinkleyTerm Handles Mail” for information on the naming convention) and have a file extension of .REQ. Outgoing requests should NEVER have a drive and path designation; only the file name. The remote system handles the drives and paths.

The .REQ file is placed in your outbound holding area.

BinkleyTerm will not place calls for a stand-alone .REQ file. In order for a call to be placed, a packet or file attach of the proper flavor must also exist (this will be prepared, along with the .REQ file, by utilities such as Bonk and Amax). You can also manually poll to send the request immediately.

Where is the outbound area for points? Let's say you are storing mail for points off of a system whose address is 1:132/491. You would do so by creating a directory 008401EB.PNT in your Zone 1 FidoNet outbound directory. (the hex representation of “132” is “84”, “491” translates to hex “1EB”, so “008401EB” represents 132/491 in hexadecimal)

If you were in Zone 1 of FidoNet, a crash packet to this system's point 12 (“12” is “C” in hex) would be something like:

C:\BINKLEY\OUTBOUND\008401EB.PNT\0000000C.CUT

• How-To Join FidoNet
• SCFG
• FidoNet
• Reference Library