Introducing FLAME
Welcome to FLAME, the FidoNet Link, Areafix, Mail and EchoMail
processor for TIMS. FLAME and TIMS work in conjunction with each
other to provide a full-function interface to FidoNet and
FidoNet-compatible store and forward electronic mail networks.
Think of FLAME and TIMS as a closely knit team, each performing
part of the overall capabilities that together form the basis
for the most powerful FidoNet implementation available. TIMS
performs these functions:
Mail transport interface to other systems
Real-time processing of outbound NetMail
Real-time processing of uncompressed inbound NetMail and EchoMail
While FLAME performs these functions:
Processing of outbound EchoMail
Processing of compressed mail, inbound and outbound
Ancillary functions (such as areafix and routing of outbound
mail)
The TIMS manual explains how to configure the TIMS portion of
the team. This manual is designed to acquaint you with the
features and configuration of the FLAME portion of the overall
two-part FidoNet system.
IMPORTANT NOTE: The TIMS manual spends some amount of time
discussing "Net Mail Utilities." These are the programs
POSTMAIL, PREMAIL, ECHOSCAN, ECHOLINK, ECHOFWD, and UNPACK.
Please be aware that FLAME replaces and supercedes these
programs entirely, in a new and more efficient single-program
package. Disregard references to these programs and their usage
when you encounter them in the TIMS manual.
FLAME System Requirements
FLAME requires the following:
At least 520k of free conventional memory. You can determine the
amount of conventional memory available in DOS Version 5.0 and
up by using the "MEM" command (in previous versions of DOS by
using the "CHKDSK" command). The reported amount of memory for
"largest executable program size" is the amount of free
conventional memory you have.
At least 512k of EMS (expanded) memory. This is the same type of
memory used by TBBS itself.
If you have no EMS memory available, FLAME can use an equivalent
amount of XMS memory, but it will run much slower than it would
with EMS memory.
Sufficient disk space for FLAME operations is also required. Any
system running in an electronic mail network should keep several
megabytes of disk space -- at least 200% of the size of your
message base files -- free at all times. (Your message base
files are MSG.BBS and MSGHDR.BBS.) Total the size of these
files, and keep at least twice that amount of disk space
(preferably much more) free and available. Although FLAME itself
will not require this much space, other aspects of a running
system in a network likely will. This also allows you to feel
confident there's room for incoming mail and file enclosures to
be stored.
Why You Need FLAME
As discussed earlier, TIMS alone is capable of handling some of
the mail processing needs of a typical FidoNet-technology
network system. In fact, in some installations TIMS alone may be
all you need for complete mail functions and FLAME is not
actually needed at all. This is typical of closed, private store
and forward mail networks such as those used in corporate
environments. However, if you use TIMS in a public network such
as FidoNet itself, then you will most likely need FLAME to
handle at least some of the mail processing tasks demanded by
your situation.
Understanding FLAME's Role
We outlined before what mail processing TIMS does by itself, and
what processing FLAME handles. To help in understanding this
relationship, some illustrations might be beneficial. First,
let's take a look at the processing of inbound mail, the mail
that is arriving at your system from other systems in the
network:
In FidoNet-technology networks, mail can arrive in one of two
forms: compressed, or uncompressed. TIMS alone can handle
incoming uncompressed mail in real-time, while TBBS continues to
operate normally. It can process this mail (toss it) to both the
NetMail area and EchoMail areas you have defined in the TIMS.CTL
configuration file with the MSGAREA configuration statements.
Compressed mail, on the other hand, must have additional
processing steps. FLAME is designed to provide these additional
processing steps. FLAME can decompress the mail, then toss it
into the TBBS message base offline while TBBS is unloaded and
unavailable to callers. As with TIMS itself, FLAME can handle
both NetMail and EchoMail. (Note that FLAME can also handle
uncompressed mail if TIMS has not processed that mail by itself.)
Outgoing mail is somewhat more involved, since NetMail and
EchoMail are handled differently. Here is how NetMail is usually
handled:
The TIMS integrated real-time scanner can handle NetMail,
provided that sending the mail uncompressed is acceptable. The
TIMS real-time scanner is not, however, designed to handle
compressed mail or the processing of EchoMail in any form. This
type of mail processing places a potentially heavy load on the
system, and it is unrealistic to handle it while TBBS continues
to run. FLAME must therefore be used to perform this processing
(compressed mail creation and EchoMail scanning) with TBBS
offline and unavailable. Here's a diagram of this processing:
FLAME can handle either NetMail or EchoMail messages, and in
addition to being able to send the mail uncompressed, FLAME can
be used to compress the mail if desired. Remember, FLAME must be
executed with TBBS offline.
Installing FLAME
The installation of FLAME is very easy. Simply follow these
steps:
Copy the contents of the FLAME release disk to the TBBS
directory on your hard disk. No special processes are required;
just copy all the files from the diskette to the hard disk,
ensuring that they are placed in the main TBBS directory.
Run the program SCANSET which is included with FLAME. From DOS,
just type "SCANSET OK" and press Enter. SCANSET can take some time
to run if you have a large message base; please be patient.
SCANSET ensures that the message base is converted and ready for
FLAME to interact with it.
Make sure you are current on software mods for TIMS, through
eSoft's UPDATE program. If you're not familiar with this
process, download the files UPDATE.ZIP and UPDBIN.ZIP from the
eSoft Support Board, at (303) 699-8222. Place these files in
your TBBS directory, and "un-ZIP" them. Then from DOS, type
"UPDATE" and press Enter. Follow the directions on the screen.
Doing this will ensure that TIMS is fully compatible with FLAME.
Physical installation is now completed. You'll next need to
configure FLAME to your specific needs. This is covered in the
section "Configuring FLAME" later on.
Once the FLAME programs are in place and configured, you need to
reference them in your RUNBBS.BAT file. This too is extremely
simple. What follows is a sample RUNBBS.BAT file you can use to
help get you started:
:recycle
rem THIS IS WHERE TBBS/TIMS ARE INVOKED
mltbbs /O:TIMS
if errorlevel 25 goto mail_window
if errorlevel 15 goto mfsqz
if errorlevel 1 goto remote_host
goto exit
:mail_window
rem PROCESS ALL OFFLINE MAIL ACTIVITIES
flame tbbs
goto recycle
:mfsqz
mfsqz /m
goto recycle
:remote_host
mlhost
echo Hang-up to restart TBBS
:exit
This sample batch file assumes the following:
TIMS is properly installed, configured and operational.
You have an external event configured in TBBS (using CEDIT)
which runs at least once daily and exits TBBS with an errorlevel
of 25. This event will invoke FLAME to perform mail processing
functions which TIMS cannot do on its own (refer to the section
"Introducing FLAME" to understand what activities are handled by
TIMS and which are handled by FLAME).
Configuring FLAME
If you have successfully configured TIMS, you will find that the
additional steps necessary to configure FLAME are quite simple
and straightforward. Configuration of FLAME consists of these
areas:
Overall FLAME configuration (options, parameters, etc.)
EchoMail area configuration
Both are simple to perform, and are done using any text editor
(or a word processor in non-document mode), exactly as you did
to create the TIMS.CTL configuration file when you configured
TIMS. You should start by configuring FLAME options and
parameters, then move to EchoMail area configuration.
FLAME offers many, many different options and parameters you can
use to configure FLAME and customize its operating environment.
These are stored in a configuration file named FLAME.CFG, which
you create with a text editor.
The sample configuration file, SAMPLE.CFG, contains examples of
the various options and their usage; the section "FLAME
Configuration Statements" lists all of the options along with
explanations of their use.
Thankfully, only of few of these are actually required for
successful operation. They are:
NODE
MAIL
OUTBOUND
NETFILE
FLAME will even automatically extract these from your TIMS.CTL
if there is no FLAME.CFG present. Keep in mind that these four
minimum configuration items cause FLAME to operate in a very
minimal mode (compressed mail will not be handled, for example).
We recommend you also use the following configuration statements
for more full operation:
AKA (if applicable)
POINTNET (if applicable)
NAME
ORIGIN
AREAS_BBS
TBBS
FLAME_LOG
TBBS_LIMITS
ARCHIVER (actually a series of statements; contained in the
SAMPLE.CFG file)
All other configuration verbs can be used as needed for your
particular circumstances.
Configuring EchoMail Areas
In order for FLAME to process EchoMail for your system, you must
tell it what EchoMail areas you carry on your system and which
message areas they go with. This is done in the areas file,
typically named AREAS.BBS. Although this file is optional, it is
required in order for FLAME to process EchoMail.
The actual name of the areas file is configured with the
AREAS_BBS configuration statement within the FLAME configuration
file (discussed later). You can specify multiple areas files if
you wish for any reason to organize EchoMail area configuration
into multiple files.
Each EchoMail area you carry on your system is configured on one
line of the areas file. Each of these lines is an "entry" in the
file which serves to tell FLAME about the area and where it
goes. There is one entry per EchoMail area you carry. The format
of an areas file entry is as follows:
<board> <echotag> <systems ...>
The <board> parameter can be any one of the following:
A TBBS board name from the MESSAGE BOARD DEFINITIONS screen in
CEDIT. You can use this method for STANDARD type message boards
only. The board name should be enclosed in quotation marks.
A TBBS topic path. This is the method used when you want to
place an EchoMail area in a specific sub-topic on a TOPIC type
message board. The topic path should be enclosed in quotation
marks.
Optionally, you can designate a TBBS board number from CEDIT in
lieu of a board name for STANDARD type message boards (topic
paths must be used for TOPIC type message boards). For clarity,
however, we recommend using the board name as described above.
The <echotag> parameter is the name of the EchoMail area as it
is known to the network, usually called an EchoTag. This is how
mail systems in the network identify which EchoMail area a
particular message goes with.
The <systems ...> parameter is a list of one or more EchoMail
area source(s) or desination(s) for the corresponding EchoMail
area. All systems you get the area from or need to send it to
should be listed here. In most cases, this is just one system -
your host. All systems are designated in standard FidoNet
addressing notation.
Here are examples of the various ways you can configure an areas
file entry:
"TBBS Development" TBBS_DEV 145/191 701/678 2:431/700
"echoes/national/tech" TECH 145/191 701/678 7:429/678
The first is a standard type message board indentified by name.
The second example is a topic path for a topic type message
board. Simply define each of the EchoMail areas you carry in
this fashion, one line for each area, and FLAME will be ready to
process mail for the defined areas.
NOTE: When you're creating these entries, make sure you spell
everything very carefully (both the TBBS board name or topic
path, as well as the tag) to ensure successful FLAME operation.
IMPORTANT: An EchoMail area should be configured once only
within the areas file(s). In other words, make sure that an
EchoTag is not used more than once. If you define multiple areas
files, they are handled internally by FLAME as a single areas
file and an EchoTag therefore cannot appear more than once
total, independent of how many areas files you may have.
FLAME Command Line Switches
Ordinarily, you'll run FLAME (whether interactively or through a
batch file) without any command line switches whatever. Doing so
enables full FLAME functionality, which is desirable in most
cases.
For specialized situations, however, or for diagnostic purposes,
you may wish to limit the behavior of FLAME to a particular
operation. To do this, FLAME supports a variety of command line
switches which can be used singly or together. All are listed
here. Command line switches are not case sensitive, and if more
than one is used, must be separated by one or more spaces.
An example of a FLAME command line using switches is:
FLAME TOSS SCAN LINK
This command line would cause FLAME to limit its operation to
tossing (bringing newly received mail into TBBS), linking
(establishing reply chains), and scanning new mail to your host.
TBBS
NOTE: Most systems do not need this command line switch. Using
this switch is the same as placing the TBBS configuration
statement in your FLAME.CFG configuration file.
The TBBS switch is used primarily in EchoMail hub situations. It
tells FLAME to operate in a mode where it interacts with the
TBBS message base files. When operating as a hub, particularly
one using slave (nanny) machine processing, you may wish to
selectively enable TBBS processing instead of defaulting to such
operation when the TBBS configuration statement is used.
TOSS
The TOSS switch tells FLAME to toss mail, i.e., to take newly
received mail and import it into the TBBS message base. FLAME
operation requires that SCAN be used together with TOSS whenever
importing to the TBBS message base.
SCAN
The SCAN switch tells FLAME to scan mail, i.e., to export new
mail from the TBBS message base and prepare it for delivery.
LINK
The LINK switch tells FLAME to perform reply chain linking
operations. This means that FLAME will attempt to link together
messages that have come into your system from the network that
are part of a discussion chain. When linked, messages can then
be read as a single coherent group within TBBS.
PACK
The PACK switch tells FLAME to enable packing and routing
operations. A PACK switch also tells FLAME to scan NetMail
messages. Any routing commands contained in the routing file you
have configured (if any) will be acted upon when the PACK switch
is used.
FLAME Configuration Statements
FLAME offers a variety of configuration statements to suit a
tremendous number of applications. Although you only need a few
of these for complete operation in most cases, you have many
options for special needs and unusual situations. Remember; the
minimum required configuration statements were listed in the
section, "Configuring FLAME." All available configuration
statements are listed in this section, and are also shown in the
sample configuration file SAMPLE.CFG, included with FLAME.
The configuration statements are divided into five categories:
Indentification. These configuration statements identify your
system to the outside world. An example of this is your network
address.
Directories. These are DOS file directories which you create,
and which FLAME and/or TIMS uses to process mail on your system.
An example of this is your outbound directory, where mail is
placed when it's ready to be sent to other network systems by
TIMS.
Files. These are particular files external to TIMS or FLAME, but
which FLAME uses for various aspects of mail processing. One
example of such a file is the areas file, which lists the
various EchoMail areas carried on your system.
Logs. FLAME offers a variety of log files you can use to track
operation of the FLAME software. One of the logs available to
you is the rolloff log, where FLAME records information about
message base maintenance it has performed.
Configuration. These are various control elements for FLAME,
such as processing limits, passwords, etc.
Indentification
The following FLAME configuration statements identify your
system to the outside world.
NODE <address>
Example: NODE 1:104/23
This is the network address of your particular system within the
e-mail network you are a part of. It uniquely identifies your
BBS from others in the network. FLAME uses it to know which mail
is actually to your system. If no zone is specified, zone 1 is
assumed.
AKA <address>
Example: AKA 59:610/911
This statement tells FLAME the alias network address(es) that
your system may be known by in addition to your primary network
address designated using the NODE statement. You may use
multiple AKA statements if you have multiple aliases. The
designation of AKA addresses allows FLAME to understand that
mail addressed to any of the AKA addresses is also for your
system (in addition to the mail address to your primary address
designated by the NODE statement). Note that AKA addresses are
not added to the SEEN-BY lines of EchoMail processed by your
system. If you need them added to the SEEN-BY lines of EchoMail,
you can use the ADD_TO_SEENBY configuration statement to do this.
POINTNET <net_number>
Example: POINTNET 1503
This keyword alerts FLAME to the fact that it is operating in a
point network environment, i.e., your network system has points
under it. When this keyword is present, FLAME will automatically
remap mail to your points when point information is found within
a message. See also REMAP_NAME and REMAP_NODE for additional
remapping options.
NAME <sysop_name>
Example: NAME Alan Bryant
This identifies the name of the person in charge of the network
system on which FLAME operates.
ORIGIN <origin_line>
Example: ORIGIN The Short Line BBS - Denver, CO, USA
This is the primary origin line which will be placed at the
bottom of all EchoMail messages entered on your TBBS system, and
which FLAME scans out to send through the network. It should
identify your BBS and its location in most cases, although
suitable uses of the origin line vary from network to network.
This default origin line can be overridden on an area by area
basis within the areas file (refer to "Advanced Areas File
Configuration").
INTERNET_GATEWAY <address>
Example: INTERNET_GATEWAY 1:104/2
This configuration statement informs FLAME who your
FidoNet/Internet gateway system is (if any). When this is
present, NetMail messages addressed to a user named "UUCP" will
be automatically rerouted to the address listed. It is designed
primarily for situations where callers use an offline reader to
submit a FidoNet message to the gateway via QSO. This allows
such users to use the FidoNet/Internet gateway easily and
conveniently from an offline reader. If this configuration
statement is omitted, FLAME will not perform this type of
processing.
Directories
The following FLAME configuration statements identify certain
DOS directories that FLAME uses during mail processing.
MAIL <directory> [NOSCAN]
Example: MAIL C:\MSG\NET
Example: MAIL C:\MSG\NET NOSCAN
This statement identifies the "mail" directory on your system.
Primarily for backward compatibility, this directory holds .MSG
style FidoNet messages. FLAME uses this directory to stage some
incoming NetMail messages and Areafix messages. It will by
default scan the .MSG messages found there in case they were
generated by external utilities, such as SEAdog's MAIL editor
program, mailing list generators, etc. The optional NOSCAN
parameter keeps FLAME from performing scans on any .MSG message
files found in this directory. This should match the MAIL
directory configured for TIMS.
NETFILE <directory> [NOTOSS] [NOPKT] [NOARCMAIL] [NOECHOMAIL]
Example: NETFILE C:\FILE\NET
This statement identifies the inbound files area where TIMS
places files received by other systems in your network. You can
identify multiple directories by using multiple NETFILE
statements. FLAME will look in the designated directory (or
directories, if using multiple NETFILE statements) for mail to
be processed. At least one of the NETFILE directories you
configure should match the FILE and PACKET directories
configured for TIMS so that FLAME can find mail received by TIMS
and process it.
There are four optional parameters:
NOTOSS tells FLAME not to toss any mail files found in the
directory.
NOPKT tells FLAME not to process .PKT (uncompressed packets)
found in the directory.
NOARCMAIL tells FLAME not to process compressed mail found in
the directory.
NOECHOMAIL tells FLAME to process only netmail found in the
directory. EchoMail messages are deleted.
BAD_MSGS_GENERAL <directory>
Example: BAD_MSGS_GENERAL C:\MSG\BAD_GEN
This directory designates where FLAME will put messages received
from the network which have general problems. This directory is
also used to store EchoMail messages which are received but for
which there is no area configured (i.e., EchoMail messages that
are for an unknown area). If this configuration statement is
omitted, then FLAME will simply delete messages that have
general problems.
BAD_MSGS_SECURITY <directory>
Example: BAD_MSGS_SECURITY C:\MSG\BAD_SEC
This directory designates where FLAME will put messages received
from the network which have various security problems. This
includes: EchoMail messages received from systems not in your
areas file; messages received whose passwords don't match what
you have configured; etc. If this configuration statement is
omitted, then FLAME will simply delete messages that have
security problems.
OUTBOUND <directory>
Example: OUTBOUND C:\OUTBOUND
This directory designates where FLAME will place outbound
(outgoing) messages it has processed. This should be the same as
the OUTBOUND directory configured for TIMS so that TIMS can
deliver mail processed by FLAME.
BAD_MSGS_DUPES <directory>
Example: BAD_MSGS_DUPES C:\MSG\BAD_DUPE
This directory designates where FLAME will put messages received
from the network which appear to be duplicates (i.e., messages
you've already received and processed before). If this
configuration statement is omitted, FLAME will not keep copies
of duplicate messages; instead it will simply delete them.
Files
A number of files are used by FLAME for additional
configuration, or for holding information used by FLAME during
processing. This section shows you how to reference these files.
AREAS_BBS <filename>
Example: AREAS_BBS C:\TBBS\AREAS.BBS
This statement defines the name of the areas file where you have
configured EchoMail areas carried by your system. The areas file
is a text-based listing of these areas, where they go in your
TBBS message base, and what network systems they go to or come
from. The format of the areas file is discussed in the section
"Configuring EchoMail Areas." You can have multiple areas files
configured; simply use an AREAS_BBS configuration statement for
each one. If this configuration statement is omitted, FLAME's
EchoMail processing is disabled.
AREAS_DAT <filename>
Example: AREAS_DAT C:\TBBS\AREAS.DAT
This configuration statement identifies the compiled areas file
that FLAME uses for processing.
Refer to the section "Compiling the FLAME Configuration Files"
for more information. If you omit this configuration statement,
it default to AREAS.DAT.
ROUTING_FILE <filename>
Example: ROUTING_FILE C:\TBBS\ROUTE.CFG
This statement indentifies the file which contains routing and
packing configurations for FLAME. Routing and packing is
discussed in the section "Routing and Packing With FLAME." If
you omit this configuration statement, FLAME will perform only
very simple packing of outbound mail, and will not perform any
routing whatsoever.
DUPE_HISTORY_FILE <filename>
Example: DUPE_HISTORY_FILE C:\TBBS\FLDUPES.DAT
This statement identifies the file where FLAME will keep
information about messages it has processed so that it can
detect duplicate messages. You will never need to manipulate
this file yourself; FLAME creates and maintains it
automatically. If you omit this statement, FLAME will not
perform duplicate message detection whatsoever. For this reason,
you should always designate a file with this statement to
prevent duplicate messages from entering your TBBS message base.
TBBS_MSGAREA_LIST <filename>
Example: TBBS_MSGAREA_LIST C:\TBBS\MSGAREA.TXT
This statement causes FLAME to generate a message area list file
each time you compile the FLAME configuration. This message area
list contains TIMS-compatible MSGAREA statements, and is
designed to be included in your TIMS.CTL file, using an INCLUDE
statement. If you use TIMS' real-time EchoMail tossing feature,
this allows you to configure EchoMail areas in one place (your
FLAME configuration) and have your TIMS configuration
automatically updated with the changes. To use the resulting
message area list file, simply use an INCLUDE configuration
statement inside your TIMS.CTL file. For example, "INCLUDE
MSGAREA.TXT".
Logs
FLAME is capable of generating a variety of audit trail logs.
Logs can be helpful in tracking down problems in your
configuration, and for learning what FLAME has actually done on
your system.
FLAME_LOG <filename>
Example: FLAME_LOG C:\TBBS\FLAME.LOG
This statement designates the primary FLAME log file. We
recommend that this log file be generated by any system running
FLAME. The resulting log provides a complete detailing of FLAME
activities each time it is run. If you omit this statement, then
FLAME will not keep its primary log.
TBBS_ROLLOFF_LOG <filename>
Example: TBBS_ROLLOFF_LOG C:\TBBS\ROLLOFF.LOG
This statement designates the file where FLAME will place
information about what messages it has rolled off your system,
and is used in conjunction with FLAME's message base maintenance
capabilities. Those capabilities are discussed in the section
"Message Rolloff and Maintenance." If you omit this statement,
FLAME will not keep a record of its rolloff activities. This
file is compatible with the ROLLOFF.LOG file generated by MFSQZ.
ACCOUNTING_LOG <filename>
Example: ACCOUNTING_LOG E:\LOGS\FLAMEACT.LOG
This designates the name of a detailed mail processing log of
all scan and toss activity which occurs on your system. One log
entry is written for each message scanned, and one log entry is
written for each message tossed. Note that if you are a hub, an
entry is written for each node the message is scanned out to; if
you have six nodes under you for a particular area, then six
entries will be written to this log file for each message
processed. WARNING: This file can get very large, very quickly
on busy systems! If you omit this statement, FLAME will not keep
this detailed mail processing log.
Configuration
FLAME offers a variety of configuration capabilities which are
discussed in this section. They allow you to control various
aspects of FLAME's operation on your system.
FLAME uses configuration information from CONFIG.CTL so that
file must be available to FLAME at all times via the TBBSPATH
environment variable.
TBBS
Example: TBBS
This statement places FLAME in TBBS message base handling mode.
When this statement is present, FLAME will assume that it is to
toss and scan mail to and from your TBBS message base. In the
absence of this statement, FLAME operates in a mode designed for
nanny machine use and will not attempt to open the TBBS message
base files for mail handling.
TBBS_LIMITS <max_size> <max_number> <max_count>
Example: TBBS_LIMITS 30000 64534 59000
This statement allows you to configure three limits used by
FLAME with regard to the TBBS message base.
The <max_size> parameter designates the maximum size, in bytes,
of the message text that FLAME will import into the TBBS message
base. The value 30000 is a maximum allowed. You can use the
value -1 to have FLAME use the maximum size configured in CEDIT
on the MESSAGE BOARD OPTIONS screen. The text of any message
greater than the configured value will be truncated.
The <max_number> parameter designates the maximum message number
which will be used by FLAME. The maximum value (and FLAME's
default) is 64534. FLAME will stop tossing messages into the
message base when the message number reaches this value.
The <max_count> parameter designates the maximum quantity of
messages you wish to allow in your message base. The maximum
value is 60000. FLAME will stop tossing messages into the
message base when the total message count reaches this value.
The default value is the maximum number configured in CEDIT on
the MESSAGE BOARD OPTIONS screen, less 1000.
If you omit this statement, FLAME will use the default values
for all three of these settings. If you use this statement, you
must configure all three of the limit values or FLAME will
disregard the statement altogether.
When any of the limits you define are reached, FLAME will stop
importing any mail into your TBBS system and refuse to run.
You should take reasonable steps to ensure that the message base
is maintained such that these limits are not reached on a normal
basis to avoid processing problems.
TBBS_TOSS_NAME_FILTER <name> [<name> ...]
Example: TBBS_TOSS_NAME_FILTER AREAFIX RAID FILEMGR
This statement designates name(s) which FLAME will disregard on
tossing. Any NetMail messages addressed to the name(s) listed
will be written to .MSG style messages in the MAIL directory,
and will not be imported to the TBBS message base. This option
is designed to allow automated mail processing utilities which
use the "To" field of a NetMail message as an identifier to be
run in a TBBS/FLAME environment without difficulty.
TBBS_TOSS_FILE_FILTER <file> [<file> ...]
Example: TBBS_TOSS_FILE_FILTER NODEDIFF.* NODELIST.* FNEWS*.*
This statement designates filename(s) which FLAME will disregard
on tossing. Any NetMail messages that arrive on your system with
a file attachment whose name matches one listed here will be
written to .MSG style messages in the MAIL directory, and will
not be imported to the TBBS message base. It is designed to
allow automated processing of nodelist updates and the like. If
this statement is omitted, these messages and their file
attachments will be imported into the TBBS message base.
SECURE
Example: SECURE
This statement tells FLAME to operate in secure mode. When
operating in secure mode, FLAME will reject EchoMail messages
that are sent from network systems not found in your areas file
(e.g., AREAS.BBS). With this statement present, only those
systems found in your areas files will be allowed to send you
EchoMail; the EchoMail sent by anyone else will be deleted (or
placed in the directory designated by the BAD_MSGS_SECURITY
statement, if present).
SECURE_OVERRIDE <address> [<address> ...]
Example: SECURE_OVERRIDE 1:987/654 555/1212
This statement designates a list of addresses that do not need
to be in your areas file (e.g., AREAS.BBS) to transmit EchoMail
when FLAME is operating in secure mode. This is for special
cases where you may wish to allow certain systems this
particular capability, such as certain nodes you connect to
routinely that may suffer from multiple address (a/k/a) related
anomalies.
DUPE_DAYS <days>
Example: DUPE_DAYS 30
This statement allows you to unconditionally designate old
messages as duplicate messages, and have FLAME handle them
accordingly (which usually means deleting them). EchoMail
messages which arrive at your network system, and internally are
dated older than the number of days designated, will be assumed
to be duplicates. Note that messages which are newer than the
specified number of days are also considered duplicates.
ADD_TO_SEENBY <address> [<address> ...]
Example: ADD_TO_SEENBY 1:987/654 555/1178
This statement allows you to unconditionally add the designated
address(es) to the SEEN-BY lines of all outgoing EchoMail
messages. This is normally for use only under special
circumstances. The address(es) of systems listed in your areas
files as well as your own address are added to the SEEN-BY lines
automatically.
COMPRESSED_MAIL_MAX_BYTES <bytes>
Example: COMPRESSED_MAIL_MAX_BYTES 500000
This statement tells FLAME that when it is preparing outbound
compressed mail files, it should not build a compressed mail
file that exceeds the designated number of bytes. If this
statement is provided, and FLAME reaches the designated maximum
size, it will start a new compressed mail file for any
additional mail that needs to be sent. The compressed mail file
size is checked during outbound PACK operations as routing file
SEND and ROUTE commands are processed. Use MAX_MSGS to instruct
FLAME how often to PACK mail.
NO-FORWARD
Example: NO-FORWARD
This statement unconditionally disallows NetMail forwarding.
NetMail forwarding is a situation whereby another network system
sends NetMail to your system that is not addressed to your
system (i.e., routing through you). If this configuration
statement is not present, this practice is allowed. When you add
this statement, FLAME will not allow this practice to occur.
FORWARD_NETMAIL_TO NETMAIL|OUTBOUND
Example: FORWARD_NETMAIL_TO OUTBOUND
This statement designates how FLAME should behave when NetMail
forwarding is allowed (i.e., the NO-FORWARD configuration
statement is not present). The NETMAIL keyword means that the
forwarded mail will be placed in the MAIL directory as .MSG
style messages, to allow for external processing of the messages
if desired. The OUTBOUND keyword means that forwarded mail will
be placed as outbound packets directly in the outbound mail
directory without allowing for external processing. OUTBOUND is
the default.
MAX_MSGS <count> TOSSED|SCANNED
Example: MAX_MSGS 5000 SCANNED
Example: MAX_MSGS 500 TOSSED
This statement allows you to instruct FLAME to interrupt
processing and perform a PACK when a certain number of messages
have been processed. The SCANNED keyword (which is the default
keyword if one is not designated) tells FLAME to PACK after the
designated number of messages have been scanned out. The TOSSED
keyword tells FLAME to PACK after the designated number of
incoming messages have been tossed in. EchoMail TOSS/SCAN
processing is interrupted during MAX_MSGS execution of
compressed mail PACK and routing; and resumed when that process
is complete.
ARCHIVER <type> / END <type>
The ARCHIVER configuration statement allows you to define and
configure the use of compressed file handlers for FLAME. This is
an advanced feature, and should not be created or modified by
most users. A number of archiver configurations are supplied
with FLAME. The sample configuration file, SAMPLE.CFG, has these
configuration within it for ZIP, LHA, LHARC, ARJ, PKARC, PAK,
ARC7, and ZOO, which should be adequate for virtually all
situations.
PACK <type> <address> [<address> ...]
Example: ZIP 1:104/1 114/15 343/491
This statement allows you to select the type of archiver which
will be used when preparing compressed mail for the systems
whose addresses are listed. The <type> parameter corresponds to
the archiver type, configured as part of the ARCHIVER
configuration statements. With the PACK statement, you can pick
whichever type of compression a particular system desires. If
necessary, you can specify multiple PACK statements with the
same archiver type.
DEFAULT_ARCHIVER <type>
Example: DEFAULT_ARCHIVER PKARC
This statement allows you to select an archiver type that will
be used by default. The <type> parameter corresponds to the
archiver type, configured as part of the ARCHIVER configuration
statements. When no PACK statement applies to a particular node,
the designated archiver will be used to prepare compressed mail
for that node. Note that if no DEFAULT_ARCHIVER is designated,
FLAME defaults to the first archiver configured.
AFTER_UNPACK <command>
Example: AFTER_UNPACK C:\TBBS\ELVIS.BAT
This statement allows you to designate a DOS command to execute
immediately after each incoming compressed mail file is unpacked
into packets. It is designed for situations where you may need
to run special pre-processing software on inbound packets before
FLAME processes them itself.
REMAP_NAME <new_address> <name>
Example: REMAP_NAME 1:12399/791 ALAN BRYANT
This statement allows you to remap mail based on name. When
FLAME processes a NetMail message addressed your node and to the
name identified by the <name> parameter, that message will be
remapped and sent to the address identified by the <new_address>
parameter. You may have up to 256 REMAP_NAME statements.
REMAP_NODE <new_address> <old_address>
Example: REMAP_NODE 1:12399/791 1:104/36
This statement allows you to remap mail based on node address.
When FLAME processes a NetMail message destined to the node
address identified by the <old_address> parameter, that message
will be remapped and sent to the address identified by the
<new_address> parameter. You may have up to 256 REMAP_NODE
statements.
DUPE_HISTORY_COUNT <count>
Example: DUPE_HISTORY_COUNT 2000
This statement allows you to set the number of duplicate
tracking records that will be maintained for each EchoMail area
carried on your system. A tracking record corresponds to the
number of unique messages that FLAME will keep track of for the
checking of duplicates. A value of 2000 is recommended, and is
the default. Note, however, that an appropriate setting for this
configuration statement depends entirely on the volume of mail
processed by your system. Systems who are hubs or who carry
large volumes of mail will usually need a much higher number
than the default of 2000.
Routing and Packing With FLAME
FLAME is capable of performing routing and packing for outbound
mail. Routing is the process of sending mail for one system to
an intermediate system instead, to gain efficiencies or to
handle special situations. Packing is the process of taking mail
leaving your system and preparing it to be handled in the most
efficient way possible, which may include compressing the mail,
putting it on hold for pick-up, and so forth.
Routing and packing are both handled as a single process in
FLAME. Routing and packing are enabled when the PACK
configuration statement is used within FLAME's configuration
file. (When the PACK command is omitted, FLAME will not perform
any routing or packing functions whatever.) Instructions on how
to pack and what to route are given in a file called the routing
file. The routing file is designated in the FLAME configuration
file by the ROUTING_FILE statement. Normally the routing file is
named ROUTE.CFG, but it can be named anything you like.
How the Routing File Works
The routing file is processed sequentially from top to bottom
when FLAME runs. Each line of the routing file can be used to
give FLAME a routing or packing command. As FLAME reads each
line from the routing file, it processes the routing or packing
command given on that line before moving to the next one.
The routing file itself is divided into schedules, which allows
you to have some routing or packing commands active at certain
times of the day or days of the week, while other commands are
active at other times.
You can also have global commands; these are routing and packing
instructions which apply all the time and are not schedule
dependent. Global commands must come at the top of the routing
file prior to any schedule definitions.
The schedules are defined using the SCHED command within the
routing file. Each one has its own tag, which is an identifier
that describes the schedule. If for example we had a situation
where we wanted two schedules, along with some global commands,
then our routing file layout would structurally be something
like this:
(global commands that apply anytime go here)
SCHED DAYTIME
(commands active during the "daytime" schedule)
SCHED NIGHT
(commands active during the "night" schedule)
Please note that global commands must come at the top of the
routing file, prior to any SCHED commands.
There can be as many as 200 commands active per schedule (global
commands are counted toward this limit).
Routing File Verbs and Their Meaning
There are four types of outbound mail recognized by TIMS and
FLAME. These four types correspond to eight file extensions
(four for non-compressed mail; four for compressed mail) which
are used on outbound mail files. In this manner, the name of a
mail file in the outbound mail area identifies what type of mail
it is, so that TIMS can handle that type of mail intelligently.
Similarly, some of the routing and packing commands in FLAME do
nothing more than change the name of a file so that TIMS will
handle the mail in that file differently.
Mail types are often called mail flavors. The four types of mail
supported by TIMS and FLAME are as follows:
Normal. Generally speaking, normal mail is that which has been
prepared and placed in the outbound mail area for delivery by
TIMS, but which has not been routed or otherwise packed by TIMS,
FLAME or any other mail processing utility. Think of normal mail
as "unprocessed" mail. If it remains unprocessed, it will simply
be sent by TIMS whenever normal mail is scheduled to be sent.
Outbound packets that are normal have .OUT file extensions.
Outbound file attach lists (which are most often used to
reference EchoMail) have .FLO file extensions.
Crash. Crash mail is that which has been processed as having
priority over other types of mail. Generally, you can think of
crash mail as mail "to be sent as soon as possible." Crash mail
is delivered by TIMS whenever TIMS is scheduled to send crash
mail. Outbound packets that are crash have .CUT file extensions.
Outbound file attach lists (which are most often used to
reference EchoMail) have .CLO file extensions.
Hold. Hold mail is that which has been processed and is intended
to be held for pick-up by the destination system. Mail marked as
hold will never be delivered by TIMS with an outbound call.
Rather, TIMS will wait indefinitely for the destination system
to call and pick-up that mail. Outbound packets that are hold
have .HUT file extensions. Outbound file attach lists (which are
most often used to reference EchoMail) have .HLO file extensions.
Direct. Direct mail is that which has been processed, but is not
crash and is not hold. Direct mail is handled by TIMS the same
as normal mail. In other words, it will be sent by TIMS whenever
normal mail is configured to be sent. It differs from normal
mail only in that it has been processed, whereas normal mail
itself means that it has not been processed and could later be
changed to crash, hold or direct when it is processed. Also note
that normal mail can be affected by the ROUTE command (discussed
later), while direct mail is not affected by the ROUTE command.
Both direct and normal mail are, however, sent under the same
circumstances. Outbound packets that are direct have .DUT file
extensions. Outbound file attach lists (which are most often
used to reference EchoMail) have .DLO file extensions.
Routing and Packing Commands
FLAME offers a number of routing and packing commands that you
can use in the routing file to tailor operation to your specific
needs. The commands are discussed in this section.
SCHED <tag> <day> [<start_time> <end_time>]
Example: SCHED MORNING ALL 06:00 11:00
NOTE: You should always have at least one SCHED command in your
routing file.
The SCHED command allows you to designate that particular
routing and packing commands take place only during certain
hours of the day, i.e., a schedule for routing and packing. Any
routing and packing commands which follow a SCHED command apply
to that that schedule, up to any subsequent SCHED command.
The <tag> parameter designates a text descriptor for the
schedule, and may be up to 32 characters in length (embedded
spaces are not allowed). The tag must be unique (not used by any
other schedules you define).
The <day> parameter designates day(s) of the week that the
schedule applies in standard three-character day abbreviations
(e.g., SUN, MON, TUE, WED, THU, FRI and SAT). Three special day
parameters are allowed: ALL (every day), WEEK (weekdays; Monday
through Friday), and WKEND (weekends; Saturday and Sunday). You
can use the split bar character ( | ) to separate multiple days
of the week; for example MON|THU|SAT means "Monday, Thursday,
and Saturday."
The <start_time> and <end_time> parameters designate the time
range that the schedule is active, in standard 24-hour
(military) time notation. For example, a start time of 11:00 and
an end time of 15:30 means that the schedule is active between
11:00 AM and 3:30 PM. These are optional; if not specified FLAME
defaults to starting at 00:00 and ending at 24:00 (i.e., the
schedule is active all day).
SEND [NOARC] <verb> <address> [<address> ...]
Example: SEND CRASH 1:104/36 1:104/23
Example: SEND NOARC DIRECT 1:104/501
This routing and packing command is the fundamental command used
within the routing file. It allows you to specify how mail is to
be sent to particular nodes. The SEND command lets you designate
two aspects of mail delivery: the mail type (flavor), and
whether the mail is to be compressed or not.
The <verb> parameter is where you designate the mail type. You
can use any one of the four verbs, NORMAL, DIRECT, CRASH or HOLD
depending on your needs. You cannot mix verbs on the same
configuration line; you must select only one of the four.
The optional NOARC parameter tells FLAME not to compress mail to
the listed system(s). Without this parameter, FLAME will
compress the mail (i.e., send ARCmail).
The <address> parameter(s) designate the network addresses of
those systems to which the SEND command applies.
ROUTE [NOARC] <verb> <hub_address> <address> [<address> ...]
Example: ROUTE NOARC CRASH 1:104/501 1:104/36 1:104/23
This command allows you to implement routing with FLAME. Routing
is the sending of mail for a particular system to another system
instead, to take advantage of cost savings, network
efficiencies, etc. NOTE: In amateur networks such as FidoNet,
routing should ALWAYS be arranged in advance; DO NOT carelessly
route mail without making pre-arrangements!
The <verb> parameter and optional NOARC keyword operate the same
as the SEND command, discussed previously. The <hub_address> is
the network address of the system you wish to route mail to. The
<address> parameter(s) for whom you want mail routed instead of
sent to them. In other words, all mail for the listed
address(es) will be sent to the system identified by
<hub_address> instead of going directly to their destination.
Except for the fact that it implements routing, the ROUTE
command is identical to the SEND command in that it allows you
to designate the mail type (flavor) of the mail, as well as
whether or not the mail is to be compressed.
CHANGE <from_verb> <to_verb> <address> [<address> ...]
Example: CHANGE CRASH NORMAL 1:104/36 1:104/23
Example: CHANGE CRASH HOLD 1:104/501
This command allows you to change the mail type (flavor) of mail
for particular network systems. You can, for example, use this
command in conjunction with the SCHED command to have mail to
some systems be "crash" at one time of day, and "hold" at
another time of day.
The <from_verb> designates the type of mail (flavor) you want to
change from, and the <to_verb> designates the type of mail
(flavor) you want it changed to. The <address> parameter(s)
allow you to provide a list of network address(es) whose mail
you wish to perform this change on.
HOSTROUTE [<max_bytes>]
Example: HOSTROUTE 250000
This command allows you to instruct FLAME to perform "host
routing." It is customary within some amateur networks, such as
FidoNet, to host route out-of-net mail. Host routing means that
mail is sent to the destination system's network host instead of
the system itself. For example, if you were in net 107, and you
had mail to go to 104/36 (a system not in your local net), then
the HOSTROUTE command would send that mail to 104/0, the net
host for 104/36.
The <max_bytes> parameter allows you to designate the largest
size of a packet that will be host routed. If used, any mail
packets larger than the designated size will not be host routed.
NOTE: HOSTROUTE will only route NORMAL type (flavor) mail,
which is presumed to be not otherwise processed. CRASH, HOLD or
DIRECT mail will not be host routed, since it is assumed to be
processed as needed. For this reason, the HOSTROUTE verb should
come AFTER other routing and packing commands in your routing
file, so that those commands can process the mail as needed
before FLAME attempts to host route that same mail. DO NOT USE
HOSTROUTE AS A GLOBAL ROUTING/PACKING COMMAND, or all mail will
be host routed instead of processed as you need! The HOSTROUTE
command should be placed within a schedule (defined with the
SCHED command) after all other commands in that schedule. Here
is an example block diagram of the routing file sequence:
(global commands that apply anytime go here)
SCHED DAYTIME
(commands active during the "daytime" schedule)
HOSTROUTE
SCHED NIGHT
(commands active during the "night" schedule)
HOSTROUTE
In this manner, host routing will only take place on mail that
is not otherwise processed.
Advanced Areas File Configuration
FLAME has a number of additional features for use within the
areas file, normally AREAS.BBS. These additional features let
you achieve a number of special effects and address the unique
needs often associated with being an EchoMail "hub" or
distribution point. Most installations will not need these
features.
All of the advanced features operate the same way within the
areas file.
All are prefaced with a comment character, either semi-colon ( ;
), percent sign (%), or asterisk ( * ). Although this sounds odd
at first, these advanced commands are hidden behind comment
lines so that your areas file will remain compatible with
certain types of third-party utilities and processors that may
wish to use your areas file. Even though you hide them behind a
comment line, FLAME will still recognize and process them. (If
you really do want to comment out an advanced command, you must
double the comment character, such as ;; or %%.)
All of the various advanced features are processed sequentially
as they appear in the areas file, from top to bottom. Once you
configure one of the advanced options, it will stay in effect
and apply to all subsequent processing until you change it in
the sequence of the areas file. It is important to remember this
effect, as you can sometimes generate undesired results by
carelessly using the advanced options. The following is a sample
illustrating this concept using the WRAP and NOWRAP commands
(which are discussed later):
; MODE=WRAP
"TBBS Area" TBBS 12/12 104/1 104/23
"Travel Echo" TRAVEL 12/12 11/3 3:45/187
; MODE=NOWRAP
"Systems Info" SYSTEMS 104/36
In this example, the WRAP command applies to the areas
definitions for the TBBS and TRAVEL EchoMail areas. The NOWRAP
command applies to the SYSTEMS EchoMail area. Remember, once you
set one of the advanced commands, it will remain in effect for
all subsequently listed EchoMail areas until you change the
setting or cancel it out with an opposite command.
This section describes the various options you have. Remember:
all are prefaced with a comment character! Refer to the sample
areas file included with FLAME, AREASAMP.BBS, for details on how
these commands appear visually in your areas file.
Word Wrapping on Import
; MODE=WRAP
; MODE=NOWRAP
NOWRAP is the FLAME default. This MODE option tells FLAME to let
TBBS know not to word wrap the text of messages when it's
displaying them to callers. With WRAP, messages FLAME imports
into your message base are reformatted by TBBS automatically when
they are displayed so that they will match the reader's screen
settings.
Origin Line Handling on Import
; MODE=ORIGIN
; MODE=NOORIGIN
ORIGIN is the FLAME default. It tells FLAME to include the
origin line of messages when it's importing messages received
from other systems. When a TBBS user reads a message, the origin
line will be displayed. NOORIGIN allows you to tell FLAME to
remove the origin line when it imports a message to your system
so that callers cannot see the origin line.
Local Message Handling on Export
; MODE=READWRITE
; MODE=READONLY
READWRITE is the FLAME default. It tells FLAME to export
messages entered by your TBBS users online, and to send those
messages to systems listed for a given EchoMail area. READONLY
tells FLAME to leave messages entered by TBBS users alone, and
not to send them to other systems listed.
Date Handling on Import
; MODE=OLDDATE
; MODE=NEWDATE
OLDDATE is the FLAME default. It tells FLAME to set the TBBS
date and time for messages imported to the date and time that
are in the message as it is received from other network systems.
NEWDATE tells FLAME to set the date and time of the messages
imported to the current date and time (the date and time it's
imported). Note that the use of these commands affects FLAME's
message rolloff capabilities, since the rolloff function uses
the date of a message to determine its age.
Message Thread Linking on Import
; MODE=LINK
; MODE=NOLINK
LINK is the FLAME default. This tells FLAME to perform reply
chain (message thread) linking operations on imported messages.
This means that FLAME will attempt to intelligently decide
whether a message imported is part of an existing message
conversation and link the messages together using TBBS' message
linking capabilities. NOLINK tells FLAME to leave the messages
alone, and not to perform chain linking.
Rolloff Handling by Message Count
; MODE = ROLLOFFCOUNT####
Example: ; MODE=ROLLOFFCOUNT500
This feature tells FLAME to perform message rolloff by message
count. When more than the designated number of messages are
found in a single TBBS message area or topic path, FLAME will
automatically remove messages (oldest messages first, newest
messages last) until the total count of remaining messages
equals what is set. The number of messages to rolloff by is
provided by the #### portion of the command, such as ;
MODE=ROLLOFFCOUNT250 for 250 messages. The FLAME default is 0
(zero), which means do not perform rolloff by count.
Rolloff Handling by Message Age
; MODE=ROLLOFFDAYS####
Example: ; MODE=ROLLOFFDAYS30
This feature tells FLAME to perform message rolloff by message
age in days. When messages become older than the designated
number of days, FLAME will automatically remove messages older
than that number of days. The number of days to rolloff by is
provided by the #### portion of the command, such as ;
MODE=ROLLOFFDAYS20 for 20 days. The FLAME default is 0 (zero),
which means do not perform rolloff by age.
Setting Areafix Privilege Level
; MODE=LEVEL####
Example: ; MODE=LEVEL250
This feature allows you to set the required AREAFIX privilege
level for EchoMail areas. If you are an EchoMail hub, this lets
you setup a case where downstream systems must match or exceed a
preset privilege level in order to perform AREAFIX commands on
the listed areas. NOTE: You set the privilege level for other
systems by using the FLAME_PASSWORD configuration statement in
FLAME's main configuration file. The privilege level is provided
by the #### portion of the command, such as ; MODE=LEVEL125 for
privilege level 125. The FLAME default is 0 (zero) which allows
anyone access to AREAFIX commands for the listed areas. The
privilege level itself is a number from 0 (zero) to 32000.
Overriding Your Network Address on Export
; MODE=MYADDRESS <address>
Example: ; MYADDRESS 36:120/0
Occasionally, you may operate your system with more than one
network address. In that case, it may be necessary to present
different addresses for different message areas, and present
those different addresses to other systems in your outgoing
EchoMail. The network address designated by the <address>
parameter will be used on outgoing messages for listed areas.
These messages will show the mail as being sent from the
designated address. SEEN-BY lines in EchoMail are not affected
by the use of this command.
Disallowing Private Messages in EchoMail
; MODE=NOPRIVATE
; MODE=PRIVATEOK
The FLAME default is PRIVATEOK, which means that FLAME will toss
or scan private messages in EchoMail areas. The NOPRIVATE
command forces FLAME to reject tossing or scanning of private
messages when found in EchoMail.
AREAFIX Capabilities
Many store-and-forward networks using FidoNet technology have
struggled with the problem of ensuring that everyone who wants
to carry EchoMail areas are allowed to carry those areas they
desire. The FidoNet network itself now handles so many EchoMail
areas, the task of manging EchoMail can be daunting. One of the
elements of managing EchoMail is the turning on and off of
particular EchoMail areas for the various network systems
(nodes). Since EchoMail configuration is contained in a text
file, AREAS.BBS usually, one way to add or delete areas for a
network system is to simply edit the file. But there is a better
way, and that way is called AREAFIX.
AREAFIX allows a node to automatically turn EchoMail areas on
and off simply by sending a specially formatted NetMail message.
This message goes from the system who wants to turn areas on or
off, to the source system, usually called an EchoMail hub. An
EchoMail hub serves as a central distribution point for EchoMail
for a given sub-net, net, or region. The nodes he serves are
often called downstream nodes, since such systems are farther
down if you visualize the network as a hierarchy.
When a downstream node wants to add or delete an EchoMail area,
without AREAFIX he would send NetMail to his EchoMail hub asking
that particular areas be added or deleted. The hub would then
handle this request manually. With AREAFIX, the downstream node
can automate this request simply by sending a special NetMail
message to the hub's system. There, AREAFIX functionality
"reads" the message, processes the requests for EchoMail adds or
drops, and the sysop of the hub system never has to get
involved. FLAME provides this AREAFIX functionality to the TBBS
environment for people operating as EchoMail hubs.
IMPORTANT NOTE: Downstream nodes don't need to enable FLAME's
AREAFIX functionality; only EchoMail hubs do! Unless you
distribute EchoMail to other systems, you will not need to know
how to setup AREAFIX. Simply read the section "Using AREAFIX" to
learn how to make automated requests of your EchoMail hub.
Using AREAFIX -- Downstream System
If you are a downstream node, and you have an EchoMail hub that
provides AREAFIX functionality, then you can take advantage of
the automated services available.
To turn areas on or off, you need to send a NetMail message to
your EchoMail hub. The message should be addressed to AREAFIX.
The subject of your message should contain your AREAFIX
password. Your EchoMail hub and you agree on this password in
advance, and shouldn't need to be changed. The text of your
message contains AREAFIX commands to add or drop particular
EchoMail areas -- one per line. Here is an example of a message
entered on TBBS to AREAFIX:
To: AREAFIX on 1:104/8911, Our Net Echo Hub of Dayton CO
Subj: DMXCH9
Private Message
Is this correct(Y/N)? Y
Submit Prepared Msg Text(Y/N)? N
Enter text of message.
<CR> by itself ends input.
01: COMM
02: TECH
03: -WOODWORK
04: -DIGITAL
05: LASER
06: ---
07:
<L>ist, <V>iew, <E>dit, <F>ile, <Q>uit, <S>ave, or <H>elp?
This message, entered using TBBS' line editor, shows a message
addressed to AREAFIX. The node address should be that of your
EchoMail hub system (the address above is shown only as an
example, and should not be used). The subject of the message is
your AREAFIX password, DMXCH9 in this case. Finally, on each
line of the message text is an AREAFIX command. Each command is
an EchoMail area tag.
A tag given alone, such as COMM, TECH and LASER in our example,
tells AREAFIX on your hub to turn on (enable) these areas and
start sending them to you. When a tag is prefixed by a minus
sign ( - ), such as WOODWORK and DIGITAL in our example, your
hub's AREAFIX is instructed to turn those areas off (disable).
The tear line, three dashes, tells AREAFIX that commands are
completed and there are no more in the message.
AREAFIX supports three additional commands. These additional
commands are given in the subject line, after the password. They
operate like command line switches do for a program. Note that
not all of these commands are always allowed by your EchoMail
hub, depending on setup, preference, and mail handling software
installed. These additional commands are:
-R
This is the rescan command. It tells AREAFIX to perform a rescan
on any EchoMail areas which are being enabled with this AREAFIX
message. A rescan means that all messages in the respective
areas currently held by your EchoMail hub will be sent to you to
help initialize the area with messages immediately, instead of
having to wait for new traffic to come in. PLEASE NOTE: This
command may not be allowed by your EchoMail hub system. Command
synonym: %RESCAN
-L
This is the list command. It tells AREAFIX to send you back a
list of available EchoMail areas. When allowed by your EchoMail
hub, you'll receive by return NetMail a list of areas that has
been prepared by your hub. This list can be in any format the
hub desires. Command synonym: %LIST
-Q
This is the query command. Like the -L command, this command
tells AREAFIX to send back a list of available EchoMail areas.
Unlike the list sent when the -L command is used, however, this
list is actually "built" by AREAFIX on the hub system
on-the-fly, based on that system's configured list of available
EchoMail areas. Any areas currently being sent to your system by
the hub will be marked with an asterisk (*). The list will be
sent by return NetMail. Command synonym: %QUERY
-H
This is the help command. Like the -L and -Q commands, it tells
AREAFIX to send a file to the downstream node that initiated the
command by return NetMail. Command synonym: %HELP
Again, please note that the special commands -R, -L, -Q and -H
are not always available to you. Here is an example of how these
commands might be entered into an AREAFIX message on a TBBS
system:
To: AREAFIX on 1:104/8911, Our Net Echo Hub of Dayton CO
Subj: DMXCH9 -R -Q
Private Message
Is this correct(Y/N)? Y
Submit Prepared Msg Text(Y/N)? N
Enter text of message.
<CR> by itself ends input.
01: COMM
Note how the -R and -Q commands have been added to the password
line.
Configuring AREAFIX -- EchoMail Hub System
If you are an EchoMail hub, then you probably want to save
yourself time and effort by providing AREAFIX capabilities to
the systems you feed. FLAME allows you to provide this
capability simply and easily.
AREAFIX uses a system of access levels as well as a lock and key
system. The levels work much the same as TBBS privilege levels,
except that an AREAFIX level is any number from 0 to 32000. Like
TBBS, the higher the number, the greater the access. The lock
and key system uses a "character string matching" mechanism.
The key assigned to a downstream node must match all the characters
of an EchoMail area lock in order to match.
For example, let's take a lock whose code is "ABC". If a
downstream node had a key of "ABCDEF" it would match, since the
key contains all the characters in the lock. If a downstream
node had a key of "AB", however, it would not match -- the lock
requires three characters, ABC, and there are not even three
characters in the key (regardless of matching). A key of
"XYZPDQ" wouldn't match either. Although it does have three
characters or more (as the lock of ABC requires) the six
characters of the key don't contain the three characters needed
to match the lock, and therefore there is no match. The bottom
line is that the key must have the same number of (or more)
characters as the lock, and the key must contain the same
characters as the lock NOTE: Although locks and keys can contain
any readable characters, most sysops use letters of the alphabet
in sequence (A, B, C, D, E, F, G, etc.) for consistency and ease
of management.
You, as an EchoMail hub system, use the level and lock and key
structures to control which EchoMail areas a system can AREAFIX
request from you. To use AREAFIX on your system at all, however,
a downstream node must also have an AREAFIX password established
with you (as mentioned in the section "Using AREAFIX --
Downstream System"). The level, key, and password assignments
for a given node are configured in your FLAME.CFG file using the
FLAME_PASSWORD configuration statement. This statement is
documented fully later in this section.
Configuration of AREAFIX is done within the FLAME.CFG
configuration file, along with the main FLAME configuration
options, and to some degree within your areas file (usually
AREAS.BBS). We'll discuss each in their own section.
AREAFIX Configuration in FLAME.CFG
The following configuration statements are used within the
FLAME.CFG to configure AREAFIX operation:
FLAME_PASSWORD <address> <level> <key> <areafix_pw> [<packet_pw>]
Example: FLAME_PASSWORD 1:104/36 175 ABCDEF FOOBAR
This statement allows you to configure the AREAFIX level and key
assignment for a particular downstream node, as well as define
the AREAFIX password for the system. Optionally, you can also
define a packet-level password which can be used by some mail
systems to password-protect individual mail files sent between
you. AREAFIX levels and keys are discussed in a previous
section. AREAFIX passwords are discussed previously, and in the
section "Using AREAFIX -- Downstream System."
AF_ALLOW_RESCANS
NOTE: This statement is not available when FLAME is running in
TBBS mode. It is only available in non-TBBS mode when using
nanny machine processing via a LAN. This statement tells FLAME
to allow rescan commands in AREAFIX requests. Rescanning means
that FLAME will scan all existing messages and send them out
when a request comes in from a downstream node to add an area.
AF_ALLOW_QUERY
This statement tells FLAME to allow query commands in AREAFIX
requests. A query command instructs FLAME to prepare a list of
available EchoMail areas on the fly and send back the result by
return NetMail. The list is built from the areas listed in your
AREAS.BBS file.
AF_SHOW_FEEDS
This statement tells FLAME to show whether a system is a feed or
not on specific EchoMail areas when lists are presented. Lists
are presented whenever an AREAFIX query command comes in, and
when AREAFIX responds to an incoming AREAFIX request to add or
drop areas. When this statement is active, FLAME will indicate
in these lists whether the receiving node is the feed for a
particular or not.
AF_SAVE_MESSAGES
This statement tells FLAME to save AREAFIX request messages
after processing them. Without this statement present, FLAME
will delete such messages after it is done processing their
AREAFIX commands.
AF_ALIAS <name> [<name> ...]
Example: AF_ALIAS AREAMGR
This statement allows you to configure alias names for AREAFIX
on your system. When an alias is defined, downstream nodes can
send their AREAFIX requests to the name(s) you define in lieu of
sending them to the user "AREAFIX" on your system. Note that
AREAFIX itself is always a valid alias.
AF_LIST_FILE <filename>
Example: AF_LIST_FILE C:\TBBS\FIDO\AREALIST.ZIP
This statement designates the name of a file to return to
downstream nodes when they include a list (-L) command along
with an AREAFIX request. The file can be in any format you wish.
AF_HELP_FILE <filename>
Example: AF_HELP_FILE C:\TBBS\FIDO\AREAHELP.TXT
This statement designates the name of a file to return to
downstream nodes in the AREAFIX return message when they
include a help (-H) command along with an AREAFIX request. The
file must be a ASCII text and less than 4,000 bytes.
AF_FORWARD_QUE <filename>
Example: AF_FORWARD_QUE C:\TBBS\FIDO\AREAFIX.QUE
This statement designates the name of a queue file used by
AREAFIX to handle requests for new areas. When a downstream node
issues an AREAFIX command to enable a valid area, but one which
you do not currently carry, it will request the area (as
configured) from your EchoMail feed. When the area is later
turned on and available on your system, AREAFIX uses the
information in the queue file to determine which downstream
node(s) requested the area from you, and will enable those nodes
automatically to receive the new area. The recommended name for
this file is AREAFIX.QUE.
AF_ALERT <address>
Example: AF_ALERT 1:104/1918
This statement, when used, causes AREAFIX to send copies of
return messages to the system at the designated network address.
AREAFIX will always return a message back to the system who
initiated an AREAFIX request; this command simply tells AREAFIX
to send a copy to this address as well. Often used when you (as
an EchoMail hub) maintain a separate network system for your
EchoMail hubbing activities, and want to be kept abreast of
AREAFIX activity.
AF_FORWARD_LIST <list_file> <format> <address> <password>
Example: AF_FORWARD_LIST D:\BACKBONE\FIDONET.NA TEXT
1:104/2878 FOOBAR
The statement allows you to designate an areas file (or files)
of systems you obtain EchoMail from (your feed, not downstream
nodes). When one of your downstream nodes issues an AREAFIX
command to turn on an area you don't currently carry, it will
scan these areas file(s) for the requested area. If found, it
will automatically issue an outbound AREAFIX request to enable
the area. This allows complete automation of the AREAFIX process
when downstream nodes request new areas.
The <list_file> parameter designates the name of the areas file
to scan. The <format> parameter is either the word TEXT, DAT, or
TBBS. They mean:
TEXT. A text file in the format <echotag> <description>, one
entry per line.
DAT. A compiled FLAME "AREAS.DAT" areas file.
TBBS. An uncompiled FLAME "AREAS.BBS" area file (text form).
The <address> parameter is the network address of the system
whose areas file is referenced on this line; the system to whom
the AREAFIX request will be made to obtain the new area. The
final parameter, <password>, is the AREAFIX password to use when
requesting a new area from this system.
AF_NEWAREAS <type>
This statement allows you to instruct AREAFIX on how to create a
new message area. When you begin receiving a new area from your
EchoMail feed (resulting from an AREAFIX request generated by
your system) AREAFIX will modify your areas file and create a
new message area on the fly. The <type> parameter can be MSG or
PASS. An "MSG" type creates a Fido-style .MSG message area. The
"PASS" type makes the area passthrough. WE RECOMMEND USING THE
"PASS" TYPE.
AF_NEWAREAS_NODIR
When this statement is used, and when you're using the "PASS"
type with the AF_NEWAREAS statement (see above), AREAFIX will
not create a message directory when the feed for a new EchoMail
area begins (as a result of an AREAFIX request generated by your
system; see AF_FORWARD_LIST). Without this statement, AREAFIX
will create a sub-directory on disk to use as a holding area for
messages. WE RECOMMEND USING THIS STATEMENT.
AF_NEWAREAS_LEVEL <level>
Example: AF_NEWAREAS_LEVEL 5
This statement allows you to designate the AREAFIX level that
will be used when the feed for a new EchoMail area begins (as a
result of an AREAFIX request generated by your system; see
AF_FORWARD_LIST).
AF_NEWAREAS_LOCK <lock>
This statement allows you to designate the AREAFIX lock that
will be used when the feed for a new EchoMail area begins (as a
result of an AREAFIX request generated by your system; see
AF_FORWARD_LIST).
AF_NEWAREAS_ADD_NODES <address> [<address> ...]
Example: AF_NEWAREAS_ADD_NODES 1:104/12718 1:104/2716
This statement allows you to designate the address(es) of
system(s) that you would like to automatically send new areas to
when their feed begins (as a result of an AREAFIX request
generated by your system; see AF_FORWARD_LIST). When a new
EchoMail area starts up, FLAME will add these systems to your
areas file and will automatically begin sending the new area to
them.
AF_NEWAREAS_ALLOW_CREATE <address> [<address> ...]
Example: AF_NEWAREAS_ADD_NODES 1:104/12718 1:104/2716
The statement allows you to designate a list of network
addresses of systems who will be allowed by FLAME to create new
EchoMail areas automatically on your system. When FLAME receives
a new EchoMail area feed from one of these systems, it will
create a place for the messages (see AF_NEWAREAS) and add a new
entry to your areas file.
AF_NEWAREAS_DIREC <path>
Example: AF_NEWAREAS_DIREC C:\TEST\MSG
The statement is used in conjunction with the AF_NEWAREAS and
AF_NEWAREAS_NODIR statements. When you designate that new areas
should be type "MSG", or when you use type "PASS" without using
AF_NEWAREAS_NODIR, FLAME can create a new EchoMail message area
on the fly. This statement allows you to designate a drive and
path where the area should be created. The area will be a
sub-directory under the designated drive and path. The name of
the sub-directory will be up to 11 characters long, based on the
EchoTag of the new area, to make a unique name.
AF_NOTIFY_HEADER <filename>
Example: AF_NOTIFY_HEADER C:\TEST\NOTIFY.TXT
The statement designates the drive, path and filename of a text
file up to 4,000 bytes in length. This will be used as a header
for notify messages generated by AREAFIX. This header will be
followed by the contents of the verification message, which are
generated by AREAFIX. (Notify messages are generated by using
the FLAME AREAFIX NOTIFY command from the DOS prompt.)
AF_NOTIFY_EXCLUDE <address> [<address> ...]
Example: AF_NOTIFY_EXCLUDE 1:104/2321 1:104/2897
This statement designates a list of network addresses to exclude
from notification messages. When you generate notify messages,
they will be sent to all your various EchoMail links -- except
the systems listed with this statement.
AF_NOTIFY_WITH_ECHOLIST
This command tells AREAFIX to include the list of EchoMail areas
whenever it is delivering a notification message to a downstream
node. The EchoMail area list is the same sent with a list
command, i.e., the file designated by the AF_LIST_FILE statement.
AREAFIX Configuration in AREAS.BBS
You should read and be familiar with the material in the section
"Advanced Areas File Configuration" before you attempt to read
and understand this section.
This section outlines two additional advanced areas file
configuration statements available to you when using AREAFIX
functionality on your EchoMail hub system. Remember, these
advanced commands, like those discussed earlier, are processed
in the order they appear in the areas file. Each will apply to
all areas which appear after the command, until you override or
reset the command by using the same command again with a
different value. The additional commands are:
; MODE=LEVEL<level>
Example: ; MODE=LEVEL10
Example: ; MODE=LEVEL250
NOTE: There is no space allowed between the keyword LEVEL and
the actual level number; e.g., LEVEL250 is allowed, whereas
LEVEL 250 is not.
This command allows you to set the required AREAFIX access level
for subsequently defined EchoMail areas. The level assignment
means that a downstream node must have a matching (or higher)
access level in order to add or drop the area using AREAFIX
requests. FLAME will ignore AREAFIX requests for areas for which
the downstream node has an inadequate level assignment.
; LOCK=<lock>
Example: ; LOCK=ABCD
IMPORTANT: THIS COMMAND MUST BE ON ITS OWN LINE IN THE AREAS
FILE.
This command allows you to set the lock for subsequently defined
EchoMail areas. The lock assignment means that a downstream node
must have a key capable of unlocking the lock. (Key and lock
matching is discussed in a previous section.) FLAME will ignore
AREAFIX requests for areas for which the downstream node doesn't
have a matching key.
EchoMail Hubbing With a Slave (Nanny) Machine
IMPORTANT NOTE: The information provided in this section is
provided for general information only. eSoft Technical Support
cannot assist you in the installation, configuration, or
debugging of slave machine processing using FLAME. Use the
information and proceed at your own risk. Slave machine
processing is a very advanced operation, and you should be
familiar with FidoNet mail handling, local area networks, and
hubbing requirements before proceeding!
When you are operating as an EchoMail hub system, you may have a
requirement to process a high volume of mail on a continual
basis. The TIMS manual briefly discusses the concept of slave
(nanny) machine EchoMail processing. With the availability of
FLAME, you have all the software necessary to perform slave
machine processing in a single package.
To use slave processing, you need a second PC connected to your
TBBS machine using a peer to peer local area network (LAN)
product, such as Artisoft's LANtastic or Novell's NetWare Lite.
Other peer to peer LANs should also work.
Essentially, TIMS continues to handle the acceptance and
delivery of FidoNet mail to and from other network systems. The
bulk of mail processing, however, is handled by FLAME running on
the slave machine, in real time, while TBBS continues to run
normally. FLAME will create outbound mail to go to the
downstream systems to serve, while generating a separate mail
file for your TBBS system (which contains only those areas you
wish to carry on TBBS).
Setting Up Slave Processing
The steps involved with setting up slave machine processing are
as follows:
You should have two machines installed and working with a peer
to peer LAN before beginning, one machine running TBBS, and
another machine for slave processing. You can use a peer-to-peer
LAN, or traditional LAN (dedicated server).
Using your LAN software, select and map a virtual drive letter
that can be used in common on both machines. This virtual drive
must contain your outbound mail holding area (the OUTBOUND
configuration statement in the TIMS and FLAME configurations).
The physical drive and/or directory used for the outbound area
doesn't matter -- it simply must be mapped to a virtual drive
letter that can be common between the two machines.
For example, let's assume that your TBBS machine is a server
named "TBBS" on your LAN. Let's further assume that your LAN
software is configured to identify the C: drive on the TBBS
machine as device "DRIVE-C". Additionally, we'll assume that
your outbound drive and directory is located on your TBBS
system's hard disk, as C:\OUTBOUND. Select a drive letter; we'll
use drive K:, that can be used on either of the two machines. On
your TBBS machine, you'll map the C: drive to the K: drive
letter with your LAN software.
NET MAP K: DRIVE-C (NetWare Lite)
NET USE K: \\TBBS\DRIVE-C (LANtastic)
On the slave machine, you'll need to perform a similar mapping
command:
NET MAP K: DRIVE-C TBBS (NetWare Lite)
NET USE K: \\TBBS\DRIVE-C (LANtastic)
The net result of this operation is the K: drive letter
identifies your C: disk drive mounted in the TBBS machine. The
K: drive letter can be used on either machine now to reference
that drive. Of course, you can use a drive letter other than K:
if you prefer.
Configure FLAME and TIMS to use the newly mapped drive for your
outbound area. With our above example, you would configure FLAME
and TIMS like this:
OUTBOUND K:\OUTBOUND
You must use the mapped, virtual drive for the configuration and
NOT THE PHYSICAL DRIVE (such as C:\OUTBOUND)! This is very
important!
SPECIAL NOTE: If you have an existing TIMS or FLAME
installation, you should either send or delete all existing mail
in your outbound area before you change the TIMS and/or FLAME
configuration to reflect the mapped, virtual drive. Otherwise,
TIMS may not be able to find attached files or compressed mail
when it attempts to send it!
You should begin with a working standalone FLAME installation on
your TBBS system. Ensure that the configuration is correct, and
that everything is in operating order. You should test that mail
delivery happens without error. Even if you had a working
TIMS/FLAME system before, test again after changing your
outbound area to the new virtual LAN drive to make sure the new
configuration works.
If you have the "TBBS" configuration statement in your FLAME.CFG
configuration file, remove it at this time. When running FLAME
on your TBBS machine, you will then need to add "TBBS" to the
command line of FLAME every time you run it on the TBBS machine,
or malfunction may result. An example command line looks like
this:
FLAME TBBS
Add the configuration statement "TBBS_TIMS_TOSS_FILE" to your
FLAME.CFG configuration file. The format is:
TBBS_TIMS_TOSS_FILE <filename>
The filename parameter is a drive, path and filename of a
temporary holding file. We recommend using the name TBBS.IN.
This file will be used to "stage" mail destined for your own
TBBS system (as opposed to mail you are processing for
downstream nodes) so that TIMS can import it in real-time. This
allows you to process mail for your own system as well as
downstream nodes at the same time on the nanny machine. Note
that the presence of this configuration statement is what
automatically enables FLAME's slave machine processing behavior.
IMPORTANT: Whenever you run FLAME from your TBBS machine, make
sure you place "TBBS" on the FLAME command line, as mentioned
previously. Otherwise, FLAME will assume it's running on the
slave machine when configured this way!
Install the FLAME executable files on your slave (nanny)
machine. Make sure your FLAME configuration file and areas
file(s) -- the same ones you used and tested on your TBBS
machine -- are present as well. Compile the configuration and
areas files normally. IMPORTANT NOTE: Make sure your CONFIG.CTL
file, the main TBBS ocnfiguration file, is either copied to the
slave machine or is available on the slave. You can make it
available by setting a special TBBSPATH on the nanny machine
that references the TBBS directory on your TBBS machine using
whatever virtual, redirected LAN drive letter is needed.
At this point, you should have an operational TIMS/FLAME/slave
machine system working. All EchoMail areas carried by your
system will be echoed to TBBS when processed by the slave
machine, and to downstream nodes as necessary.
To finish off your installation of slave machine processing, be
aware of the following:
To configure additional EchoMail areas that are carried on your
TBBS system, simply make the necessary changes to your areas
file, referencing TBBS message boards or topic paths as usual.
Make sure the areas file is updated on your TBBS machine and the
slave machine.
To configure additional EchoMail areas that are distributed to
downstream nodes only, and are NOT carried on your TBBS, add
them to your areas file as pass-through areas. Passthrough area
entries in your areas file begin with a pound sign (#), followed
by a space, followed by the EchoTag, then a list of node
addresses separated by spaces, like this:
# TBBS 1:104/7161 1:104/1263
# COMM 1:104/9810
You can share the FLAME files (both the program itself, and the
data files) if desired by mapping appropriate virtual drives
using your LAN software, instead of maintaining separate copies
of the files (one set on TBBS, one on the nanny).
When you run FLAME from the slave machine, you MUST run it in
"TOSS SCAN" mode. DO NOT RUN "SCAN" ALONE OR "TOSS" ALONE
-- MALFUNCTION WILL RESULT!
FLAME can be invoked on the slave machine in any fashion you
desire. Some sysops use a batch file, continually looping, in
conjunction with delay programs that cause the batch file to
pause. Other sysops use scheduling software, such as the
shareware program Cron Jr. We do not recommend sharing your
FLAME slave with other slave processes, such as the use of
CD-ROM copying systems. Although FLAME is very high
performance, depending on mail volume, FLAME's operations could
take lengthy amounts of time to complete -- time during which
other slave operations would not run.
The packet that FLAME prepares for your TBBS system (the file
designated by the TBBS_TIMS_TOSS_FILE configuration statement)
can be tossed into TBBS using TIMS' real-time tossing, or by
FLAME itself running on your TBBS machine during an external
event. Use whichever mechanism is best for your situation.
The packet that FLAME prepares for your TBBS system (the file
designated by the TBBS_TIMS_TOSS_FILE configuration statement)
should not be named as to allow TIMS or FLAME to know it's a
mail file. Therefore, do not use a name with a .PKT file
extension (as mentioned previously, we recommend using TBBS.IN
as the name for the file). In order for FLAME or TIMS to process
the file later, however, the batch process running on the slave
should rename the file to 99999999.PKT (or a similar name
unlikely to conflict). This will allow TIMS' real-time tosser or
FLAME to recognize the file as mail to be processed, and to
handle it accordingly. If you're running a batch file on the
slave, simply use a DOS "RENAME" command after FLAME's slave
processing is finished. Until the file is renamed, FLAME will
continue adding mail for your TBBS system to the file
indefinitely.