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

===== Background =====
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 =====

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-[[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 or folder normally
associated with a Binkley/FLO-style mailer and they don't
deal with Stored Messages (a.k.a. ".msg files").


===== Packet =====

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

[[ref:FidoNet Packets]] may contain NetMail or EchoMail messages.

Packet files have a ''.pkt'' suffix (SBBSecho v2 named 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 v2 used "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 while
SBBSecho v3 uses the packet creation time in Unix time_t format
(seconds since Jan-1-1970) represented with hexadecimal digits
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-[[FTS>0001.016]].

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


===== Bundle =====
(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.

===== Flow Files =====
(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 defined in [[http://ftsc.org/docs/fts-5005.002|FTS-5005]]. 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 network number as a 4-digit zero-padded
hexadecimal number, and "nnnn" is the destination node 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/(I)mmediate, (H)old, or F, for "Normal".

Another permutation 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 network number as a 4-digit zero-padded
hexadecimal number, and "nnnn" is the destination node 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).
==== BT-USER.TXT ====

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

=== Idea #4 ===
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:

|''.HUT''    |Hold this packet for pickup by the remote system. |
|''.CUT''    |The other system can receive Continuous Mail.|
|''.DUT''    |Direct, meaning the other system can NOT receive Continuous Mail.|

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:


|''.HLO''  |Hold these files for pickup by the remote system. |
|''.CLO''  |The other system can receive Continuous Mail.     |
|''.DLO''  |Direct, meaning the other system can NOT receive Continuous Mail. |

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

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

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.

=== A Sample Message, Start to Finish ===

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.

===== BT-REF.TXT =====

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

==== Outgoing file requests ====
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.

==== Points ====

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
 

===== See Also =====
  * [[:howto:fidonet|How-To Join FidoNet]]
  * [[:util:SCFG]]
  * [[:network:FidoNet]]
  * [[:ref:|Reference Library]]

{{tag>fidonet}}
