FidoNet NetMail/EchoMail File Naming Primer by Rob Swindell
-----------------------------------------------------------
$Id: fidonet.txt,v 1.4 2006/06/29 02:27:46 rswindell Exp $

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 a 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 different directory, but is referenced 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 FidoNet
Technical Standard document: FTS-0001.

Binkley/FLO-style mailers also support NetMail messages with
attachments, but do *not* support Stored Messages. Binkley/FLO
style mailers always send NetMail 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").


Packet
------
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 proccess" 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 FidoNet Technical Standard document: FTS-0001.

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 filename 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 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 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).

More on this 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:

     #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.

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.

... and from the BinkleyTerm 2.60 Reference Manual (BT-REF.TXT):

     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



/* End of File */
