% The FLAME Disk, Sample File for FLAME.CFG
% for eSoft's FLAME v. 1.1
%
% Copyright 1994, Chris Anderson
%
%
% *--------------------------------------------------------------------------*
% *--------------------------------------------------------------------------*
% * Configuration File for FLAME *
% *--------------------------------------------------------------------------*
% *--------------------------------------------------------------------------*
%
%
% --------------------------------------------------------------------------
% Introductory Comments About this FLAME.CFG File
% --------------------------------------------------------------------------
%
% COMMENT LINES BEGINNING WITH AN ASTERISK ARE THOSE SUPPLIED IN THE SAMPLE
% FILES DISTRIBUTED BY eSoft WITH THE FLAME SOFTWARE PACKAGE. THE SAMPLE.CFG
% AND ADVANCED.CFG FILES ARE COVERED TOGETHER HERE IN A SINGLE FILE.
%
% Note that "nanny" operation (mail processing on a different machine
% than the TBBS BBS machine) may require a few minor modifications to
% this file in some configurations. A separate section will cover
% those exceptions.
%
% It is legal to add comments to the *end* of may of the lines in
% FLAME.CFG. However, this is not possible for such items as "Origin"
% where variable numbers and sizes of words can be used as the parameter.
% Do so with caution. Run a FLAMEDIT EXPORT now and again just to be
% sure that FLAME is thinking along the same lines as are you about your
% configuration.
%
% *--------------------------------------------------------------------------*
% * The full network address of this system in 3-D (zone:net/node) format *
% *--------------------------------------------------------------------------*
%
% You may be part of only one network, and have only one network address
% for your system. In this case, you need only enter that number here.
% If, on the other hand, you have more than one address in your network,
% or are a member of more than one network, you must decide which of
% your network addresses that you wish to place here. Only ONE address
% may be declared your "primary address" in this "Node" statement.
% Fortunately, if you hold addresses in multiple networks, FLAME, when
% correctly configured, is quite good at keeping things straight for
% you.
%
% Any mail archives that FLAME builds will use the net and node
% portions of your "Node" number to create the first eight characters
% of any mail archive filename *unless* a better matching AKA is
% available (see below). This convention is recognized and used by
% some software to determine the source of archives sent to it (see
% earlier section on archive names).
%
% In addition, it is this address or a better AKA match that will be
% used in the message headers of messages that FLAME may automatically
% generate on your behalf, and that will appear in the packet headers
% that are created for all of your outbound mail.
%
% This should match the address you supply to TIMS.CTL in its "Node"
% statement in all but the *rarest* cases. NOTE: FLAME is a FULLY 3-D
% addressing system. If you neglect to supply a zone number in your
% address, FLAME will complain during compilation and assume Zone 1 for
% your address. Please also note that Zero (0) is not considered a
% valid zone number by FLAME.
%
% If neither your "Node" or "AKA" contains a match to the zone for which
% a message is destined, then an ^AINTL (known as an "International
% kludge line") is added. This technique is almost universally supported
% by Fido technology mail processors to indicate the destination and
% origin addresses. This is because not all mail processors look for
% zone information in the packet header, but are obliged to honor the
% ^AINTL information by FTS standard. See also "Force_Intl", below.
%<Z>
Node 1:104/114
% *--------------------------------------------------------------------------*
% * Additional network addresses this system is known as *
% * Limit: 19 *
% *--------------------------------------------------------------------------*
%
% As noted above, your AKA's will be searched for any good match when
% creating message and packet headers for outbound mail, and when
% creating archived mail filenames. For example, if mail is being
% packed for 8:7703/2, then the AKA shown below of 8:7703/4703 will be
% used instead of the 1:104/114 primary address above. In fact, any
% Zone 8 outbound mail would be made to include the better match of the
% 8:7703/4703 address in created message and packet headers rather than
% the primary (containing Zone 1) address above.
%
% FLAME will not attempt to forward NetMail to one of your AKA's, as
% common sense would have it. Any and all FLAME routines that are
% looking for "your address" will recognize any AKA as being as much
% "your address" as your primary address as specified in "Node".
%
% Note that specified "AKA" addresses will have no effect on EchoMail
% SEEN-BY information. Any changes in that function must be handled by
% the "Zonegate" statement or the Add_To_Seenby statement (see below).
% If you are moving mail between networks or between zones in
% networks, the Zonegate statement should be used. If you have
% more than one address within a single zone or network, you may
% wish to use Add_To_Seenby.
%
% Neither are your AKA addresses used for modification of the Origin,
% PATH or MSGID lines within any message. This is handled by means of
% the MYADDRESS address override within the Areas_BBS file(s).
%
% FLAME will not accept an AKA of 0:net/node. In addition, FLAME will
% convert a "0" zone in any mail you receive to your primary ("Node")
% zone. If your address is 1:104/114, and mail is received for
% 0:104/114, FLAME will assume that the correct address must be
% 1:104/114. This makes it possible to properly process most mail
% if received from a "zone unaware" system.
%
% If you specify a "0" zone or omit your zone in any AKA, FLAME
% will use the zone from your primary ("Node") address for that
% AKA.
%<Z>
Aka 1:30333/0
Aka 8:7703/4703
% *--------------------------------------------------------------------------*
% * The path to your primary network mail area *
% * *
% * Syntax: Mail <directory> [NoScan] *
% *--------------------------------------------------------------------------*
%
% The following identifies the same directory as you would typically
% provide in your TIMS.CTL "Mail" statement. This directory will
% contain any "*.MSG" level mail that may exist on your system. FLAME
% can be asked to scan this area for any *.MSG mail that may have been
% placed in your "Mail" directory. *.MSG files may occur due to use of
% another utility to create mail such as the SEAdog MAIL program, an
% automated file distribution utility, etc. (see also the NETMAIL_SCAN
% statement in ROUTE.CFG). However, FLAME will pack a file attach message
% if found here, so you may well wish to include NoScan to prevent this as
% it will cause an inability to send files using utilities that create
% *.MSG files. Note also the use of the NETMAIL_SCAN statment in
% ROUTE.CFG.
%
% Also, if you use the TIMS "UNPACK" command, *.MSG files will be
% created here. For that reason, it is not advised to use the TIMS
% UNPACK if you have any attach *.MSG files for outbound files, as it
% will be impossible for FLAME to distinguish them from one another.
% In fact, there is rarely any reason to use the TIMS "UNPACK" at all in
% on a system using FLAME. If you are using UNPACK now, you should
% probably discontinue its use immediately upon installing FLAME.
Mail C:\TBBS\MAIL
% *--------------------------------------------------------------------------*
% * The system's outbound mail directory *
% *--------------------------------------------------------------------------*
%
% Except for certain "nanny" environments, this should match the
% OUTBOUND statement in your TIMS.CTL file. FLAME will place outbound
% mail archives, *.?LO file lists (.FLO, .CLO, .HLO, .DLO) and *.?UT
% packet files (.OUT, .CUT, .HUT and .DUT) in this area after
% processing. Note that the *.?UT files above are actually identical to
% *.PKT files, but whose names correspond to the net (first four hex
% digits) and node (second four hex digits) of the system to whom the
% mail is to be sent. The first letter of the file extension is used to
% provide TIMS (or other mailer) the "flavor" of the mail.
Outbound C:\TBBS\OUTBOUND
% *--------------------------------------------------------------------------*
% * The path to your network file area(s) *
% * Limit: 10 *
% * *
% * Syntax: NetFile <directory> [NoToss] *
% * NetFile <directory> [NoPkt] *
% * NetFile <directory> [NoArcmail] *
% * NetFile <directory> [NoEchoMail] *
% *--------------------------------------------------------------------------*
%
% When FLAME unpacks and processes new mail, it is the NetFile
% directories that it looks to to determine the location of this new
% mail.
%
% As noted in a separate "Security" section in this Interconnectivity
% chapter of "TBBS, Tips, Traps and Techniques", you should always employ
% session passwords with any node with which you do regular archive mail
% business. Only archive file directories that contain files received
% under session password should be automatically unpacked by FLAME, and
% as a result, specified here. This would be the second directory you
% specify in your TIMS.CTL "FILES" statement.
%
% In addition, you may receive unarchived (packet) mail in the directory
% specified in your TIMS.CTL "Packet" statement. Automatically unpacking
% such mail can be risky unless you have established a session password
% with systems sending you packet mail. However, something known as a
% "packet level password" can also be used to at least verify that a
% packet has come from the system for which it claims to have come. See
% the optional FLAME_PASSWORD statement for details.
%
% It will probably be unnecessary for you to make use of most of the four
% modifiers that may accompany each directory, but here is the function
% of each if they turn out to be useful to you:
%
% NoToss - No mail found in this directory will be tossed to the BBS
% message area when processing mail. Passthru mail to other
% nodes for whom you hub will be processed if found here.
%
% NoPkt - No packet files found in this directory will be processed.
%
% NoArcmail - No archived mail files found in this directory will be
% processed.
%
% NoEchoMail - Only NetMail will be processed from this directory.
% EchoMail found in this directory in either packet or
% archive files is deleted.
NetFile C:\TBBS\FILES
NetFile C:\TBBS\PACKETS
% *--------------------------------------------------------------------------*
% *--------------------------------------------------------------------------*
% * GENERAL SETUP *
% *--------------------------------------------------------------------------*
% *--------------------------------------------------------------------------*
%
% *--------------------------------------------------------------------------*
% * Your point networks *
% * Limit: 20 *
% *--------------------------------------------------------------------------*
%
% The definition of Point systems was covered in an earlier section.
% If you have chosen to hub mail for your own point network, the
% PointNet statement is used to supply FLAME with your Point network
% number. Note that FLAME does not completely support 4D addressing,
% although it will handle point system functions for you in an
% entirely satisfactory manner. In the example below, a point address
% of 30333/8 would equate to the primary address, point #8, or
% 1:104/114.8. Please also note the REMAP statements below, where the
% point remapping services performed by FLAME are explained.
%
% When FLAME encounters an inbound EchoMail message *from* one of your
% points, the address in the Origin line at the end of the message is
% changed from pointnet/node to yournet/yournode.point.
%
% When FLAME encounters an inbound Netmail message *from* one of your
% points, a ^AFMPT kludge line is added to the top of the message, and
% the origin address information in the message header is changed from
% its pointnet/node address to your primary address as defined in "Node",
% above before it is sent to the outside world, or if it is addressed to
% your system, before it is tossed to your message base.
%
% When FLAME encounters an inbound NetMail message to your system that
% contains a ^ATOPT kludge line, the messages destination address is
% automatically changed from your system's address to the pointnet/node
% address of the point.
%
% See the "Remap_Name" statement for other information about inbound
% NetMail that you receive for your points.
PointNet 30333
% *--------------------------------------------------------------------------*
% * Your name (35 characters max) *
% *--------------------------------------------------------------------------*
%
% FLAME will automatically generate NetMail messages under a variety of
% circumstances. However, FLAME is content to use the name "FLAME", not
% yours, in the From: field of many (but not all) such messages. For
% example, if you "bounce" routed EchoMail back to its source, your name
% will be used in the From: field. Another purpose for this option is
% the replacement of any outbound EchoMail from your system From: SYSOP
% with the name you provide here. Using the old NetMail utilities, this
% used to be provided from the first line of the AREAS.BBS file. This is
% no longer the case. Also, FLAME will send you NetMail messages using
% your name in the "To:" field for such functions as FLAME TBBS REPORT.
Name Chris Anderson
% *--------------------------------------------------------------------------*
% * The system's primary origin line (59 characters max) *
% *--------------------------------------------------------------------------*
%
% This parameter can be overridden on an echo by echo basis from the
% Areas_BBS file(s). Please refer to documentation in that file. This
% may especially useful if you are operating in a multi-zone environment.
%<Z>
%
% Your origin line should conform to the FidoNet standard that limits
% the total line length to something that will fit on an 80 column
% screen. A good general rule of thumb here is to avoid anything
% longer than about 55 characters after the word "Origin" here, as
% FLAME will append your zone:net/node automatically. AVOID placing
% your address here, therefore, as it will be duplicated. Find
% something clever to do with the space. Most systems like to include
% the system name and a location. Some manage to fit something that
% identifies some unique feature of their BBS. Where room permits,
% a phone number is often shown.
%
% Using the old NetMail utilities, this information was once taken
% from the first line of the AREAS.BBS file. This is no longer the
% case.
Origin The Dinosaur Board [Niwot, CO]
% *--------------------------------------------------------------------------*
% * The system's log file (path may be included) and log categories *
% * Limit: 4 *
% *--------------------------------------------------------------------------*
%
% The full syntax for this statement is
%
% Flame_Log <path\filename> <option, option, ... option>
%
% Options include:
%
% ALL = (default) log everything
% ALLBUT <items> = log everything except noted items (see below)
% <items> = log just the items specified
%
% You may specify any or all of the following "items":
%
% WARNING = Any warning messages from FLAME
% ERROR = Any error messages from FLAME
% TOSS = Mail tossed to the BBS message base
% SCAN = Mail scanned from the BBS message base
% PACK = All lines related to packing & unpacking
% REMAP = All "Pointmap" lines
% LINK = Link statistics
% AREAFIX = Any AreaFix activity
% DUPE = Dupe message count reporting
% ROUTE = Mail routed to/through other systems
% STATS = "Totals" figures at end of sessions
% NETMAIL = Forward, Send, Gate, etc.
% DOS = Any shells to DOS programs incl. archivers
% NOHEADER = avoids BEGIN and END information in report
%
% Up to four different Flame_Log lines can be specified with different
% filenames and different contents options. If you wished to create
% two log files, one containing everything pertaining to AREAFIX and
% the remapping of mail, and another containing all of your other log
% information, you might use
%
% Flame_Log C:\TBBS\AREAFIX.LOG AREAFIX, REMAP
% Flame_Log C:\TBBS\FLAME.LOG ALLBUT AREAFIX, REMAP
Flame_Log C:\TBBS\TEXT\FLAME.LOG
% *--------------------------------------------------------------------------*
% *--------------------------------------------------------------------------*
% * TBBS Messsage Base Configuration *
% *--------------------------------------------------------------------------*
% * Areas.Bbs MODE parameters define other configuration options. *
% *--------------------------------------------------------------------------*
%
% *--------------------------------------------------------------------------*
% * Forces TBBS processing. This is the same as adding TBBS to the command *
% * line for every execution. The TBBS message base and userlog files must *
% * be available when running in TBBS mode. *
% *--------------------------------------------------------------------------*
%
% You would likely only want to comment out the "TBBS" statement on a
% "nanny" machine in the event you are running in a "nanny"
% environment. An exception is if you wish to process mail and avoid
% tossing it immediately to the BBS, but rather, to place the prepared
% packet where TIMS can find it for tossing. See the information in
% TBBS_Tims_Toss_File for more information on this mode of operation.
% Nanny machine operation will be covered elsewhere. Note that any
% attempt to run in "TBBS" mode will not only require that FLAME have
% access to the messagse base and userlog files as mentioned by eSoft,
% but also the CONFIG.CTL file for the BBS. FLAME will search the
% current directory and the TBBSPATH environment variable in an attempt
% to locate these files. Access to CONFIG.CTL is needed in order for
% FLAME to establish the current TBBS board names/numbers.
%
% Note that even if you comment out "TBBS", you can force FLAME to
% operate in TBBS mode by requesting this on your FLAME command line.
TBBS
% *--------------------------------------------------------------------------*
% * TBBS_Limits <Msg size> <Highest Msg Number> <Max number of Msgs> *
% * *
% * These are the TBBS message base limits. Three numbers are expected. If *
% * any of the numbers is zero the default value will be used. If any one of *
% * the numbers is used all three must be entered. *
% * *
% * The three numbers represent: *
% * *
% * -1- The maximum message size to import into the message base *
% * *
% * Set the maximum message byte count to import into the TBBS message base. *
% * Message text longer than this number will be truncated. If this is 0 *
% * the default is to import the actual message size up to 30,000 bytes. *
% * Use a negative number (eg -1) to set the parameter to the Config.Ctl *
% * configured maximum message size. 30000 is the maximum size supported and *
% * the default if limits are not provided. *
% * *
% * -2- The highest message number to allow in the message base *
% * -3- The maximum number of messages in the message base *
% * *
% * Mail tossers typically load up the message base right to the brim. This *
% * is great for the tosser and fine for some TBBS installations. But it's *
% * not always what the SysOp and users need. Many systems run MFSQZ before *
% * importing new mail. If the import then loads the message base to *
% * capacity it might be 24 hours or more before callers, QSO, PIMP, and *
% * online message entry/import operations will work. These values let you *
% * control the message base load. *
% * The default high message number is 64534, allowing 1000 higher message *
% * numbers. The default maximum message count is 1000 less than the *
% * Config.Ctl message count set via CEDIT. The maximum values are message *
% * number 65534 and 60000 messages. *
% *--------------------------------------------------------------------------*
%
% Note on Item #1. This will override any CEDIT limit that you
% have placed as the upper limit on message length.
% Note on Item #2. Under NO conditions may TBBS 2.2 ever be allowed
% to exceed the high message number of 65534.
% Note on Item #3. This will override any CEDIT limit that you
% have placed as the upper limit for message count. Allowing a
% greater number here without always squeezing out enough messages
% to drop below the CEDIT limit after tossing will prevent your
% users from being able to enter new messages into your BBS either
% manually or with QSO, and will keep such utilitites as PIMP from
% being able to import new mail.
%
% Messages that would otherwise be tossed, but would exceed one of
% the TBBS_Limits numbers, are tossed into "the bit bucket" rather
% than to the BBS! They are not saved for later processing, and
% cannot be recovered. They become "lost" mail, so be careful.
%
% Be sure you have sufficient disk space for the message counts that
% you are specifying here. MSGHDR.BBS will require 128 bytes for each
% message, and on average, MSG.BBS will require a minimum of about 1100
% bytes for each FidoNet echo message. That number may vary widely
% depending upon the mix of echo traffic that you carry on your system,
% and the average length of the echos in those areas. Don't forget
% that MFSQZ will create another set of MSG and MSGHDR files when it
% squeezes your message base, so you'll need this much space again
% somewhere on your system for these backup files.
TBBS_Limits 30000 64534 12000
% *--------------------------------------------------------------------------*
% * Filename to use to stage messages whenever TBBS mode is not active or *
% * whenever TBBS is running while mail is being tossed (nanny operation). *
% * You must rename this file to .PKT following a successful TOSS/SCAN *
% * operation to release the file for FLAME or TIMS to TOSS. Do not use .PKT *
% * as an extension for this file definition. Rename the file to a .PKT for *
% * processing by TIMS or FLAME. *
% *--------------------------------------------------------------------------*
%
% This item is typically used only in a "Nanny" configuration, and will be
% covered in a separate section for that purpose. However, it is also
% possible to use this statement in order to process (but not toss) mail
% for the BBS, letting TIMS toss the mail while TBBS is on-line. In
% such case, you may ignore the paragraph above and place the file where
% TIMS will find it, and the file may end with a *.PKT extension (as it
% must in order to be recognized by TIMS). This is possible since there
% will be no conflict over access to the file by two machines as there
% could be in a "nanny" environment. When using TIMS "TOSS" in a FLAME
% environment, please remember that no /H switch is needed, as there
% is no need for history files (MSGHIST.BBS) when running FLAME.
% TBBS_Tims_Toss_File C:\TBBS\TIMSTOSS\00000000.001
% *--------------------------------------------------------------------------*
% * Write NetMail addressed to these names as .Msgs and do not import into *
% * the TBBS message base. Use quotes if a name contains a space. *
% * Limit: 16 *
% *--------------------------------------------------------------------------*
%
% You may receive messages from automated utilities that identify
% themselves by name. For example, a message to be processed by the
% RAID util puts "RAID" in the "To:" portion of the message header.
% You will want to avoid tossing these to the TBBS message base. If
% messages *are* tossed to the message base, they are not available to
% be processed by other utilities. For example, if you receive RAID
% file attach messages from another system, you may not want that
% message to be tossed by FLAME, but rather, processed by the RAID
% utility on your system. This also prevents FLAME from attaching the
% associated file to the message in the TBBS message base as an
% EMnnnnn file in your TBBS "Enclosed" subdirectory, making it
% "disappear" for any other purpose. Provided below are several examples
% of software whose names you might want to watch for and exclude.
%
% See also the TBBS_Toss_File_Filter below that performs the same
% basic function, but is triggered by the associated file name as
% opposed to the name of the sending utility. Note the use of
% quote marks if the name contains spaces.
TBBS_Toss_Name_Filter Areafix Raid Allfix Areamgr Filemgr
% *--------------------------------------------------------------------------*
% * Write NetMail with these files attached as .Msgs and do not import into *
% * the TBBS message base. *
% * Limit: 16 *
% *--------------------------------------------------------------------------*
%
% Unless told otherwise, FLAME will take inbound file attach messages
% and toss them to the TBBS message base, and will attach the
% associated file as an "enclosed file" within TBBS. In some cases,
% this isn't desirable. For example, if you wish to automatically
% process your NODEDIFF files in your batch file as they arrive, you
% certainly won't want them disappearing into your TBBS message base
% and the TBBS "enclosed" file directory under EMnnnnn filenames!
% Files whose names match the ones you list here will be left alone by
% FLAME.
TBBS_Toss_File_Filter Nodediff.* Nodelist.* Fnews*.* Fmlydiff.*
% *--------------------------------------------------------------------------*
% * Defines the FidoNet address of the FidoNet -> internet gateway. This *
% * address is used whenever an outbound Net Mail message with an addressee *
% * of uucp but no destination FidoNet gateway address (as imported via *
% * QSO) is found during a scan/pack operation. *
% *--------------------------------------------------------------------------*
%
% In fact, this feature is not unique to TBBS messages entered by QSO.
% This feature will remap a NetMail message entered directly by a
% user into your TBBS message base To: UUCP regardless of what
% address was specified by the user or found in the nodelist when the
% message was entered.
%
% It is possible that you have a system in your area that is acting as
% an Internet gateway system. If you are a FidoNet member, check your
% nodelist flags for the characters UUCP to locate such systems. If
% all else fails, FidoNet members may use 1:1/31, which presently
% serves as the default gateway for FidoNet when no local gateway
% exists. You may also wish to make arrangements with another Fido
% system for this service.
Internet_Gateway 1:104/2
% *--------------------------------------------------------------------------*
% * Defines whether and where to write MSGAREA definitions during AREASCVT *
% * execution. Msgarea definitions can be included in Tims.Ctl for online *
% * tossing. *
% *--------------------------------------------------------------------------*
%
% If you are using TIMS to toss your mail, this is an ideal way of
% avoiding the maintenance of a separate toss area list for TIMS. Any
% message you receive from your echo hub(s) that contains a new echo
% area can cause FLAME to automatically add this area to your Areas_BBS
% file (see AF_NewAreas_Allow_Create), and this will automatically keep
% your toss areas list for TIMS up to date. You can then INCLUDE this
% file in your TIMS.CTL file.
TBBS_Msgarea_List C:\TBBS\TEXT\MSGAREA.TXT
% *--------------------------------------------------------------------------*
% * Activates and defines a filename to write the rolloff operation summary. *
% *--------------------------------------------------------------------------*
%
% Selecting this option causes the results of a FLAME roll-off of
% deleted messages to generate a report file like that of MFSQZ. Note
% that FLAME won't perform a roll-off, no matter what you have specified
% in your AREAS file, unless you also specify ROLLOFF on your FLAME
% command line.
TBBS_Rolloff_Log C:\TBBS\ROLLOFF.LOG
% *--------------------------------------------------------------------------*
% *--------------------------------------------------------------------------*
% * ECHOMAIL SETUP *
% *--------------------------------------------------------------------------*
% *--------------------------------------------------------------------------*
%
% *--------------------------------------------------------------------------*
% * The ASCII areas file *
% * Limit: 16 *
% *--------------------------------------------------------------------------*
%
% This defines the file(s) that is/are used to create the binary
% AREAS.DAT file used by FLAME. If FLAME is invoked, and discovers that
% the DOS time/date stamp on any of your defined Areas_BBS file(s)
% is/are more recent than that of the AREAS.DAT file, an automatic
% compilation will occur. You can also accomplish this manually by
% typing FLAME AREASCVT.
%
% Many sysops prefer to keep a separate ASCII (human-readable) AREAS
% file for each network in which they operate. All of the files defined
% in an Areas_BBS command are, however, consolidated into the single
% binary file used by flame, AREAS.DAT.
%
% In the event that "Areas_BBS" is defined, and no AREAS.DAT file
% exists, AREAS.DAT will automatically be created for you by FLAME
% when FLAME is invoked.
%
% In the event that "Areas_BBS" is NOT defined, and no AREAS.DAT
% file exists, one of two things will happen:
%
% If a file named AREAS.BBS file can be found, even though not
% specified as your Areas_BBS file in FLAME.CFG, it will be used to
% create an AREAS.DAT file.
%
% If no AREAS.BBS file can be found, a "empty" AREAS.DAT is built.
% Note that it is NOT a zero length file. This file will be several
% tens of thousands of bytes in size, but contains no real data! Do
% not be misled! How large it is depends upon the size specified
% in the "Maximum_Areas" and "Maximum_Nodes" statements, below.
%
% NOTE:
% If you permit the use of AREAFIX messages to allow other nodes
% to change the list of echo areas you send them, FLAME will use
% the information from these messages to modify only the binary
% AREAS.DAT file, and *if* you have specified an AF_Export_File
% (see below), that file will also be modified. However, unless
% your AF_Export_File is also your Areas_BBS file, be aware
% that you will have to manually copy the AF_Export_File over
% the Areas_BBS file before you edit it. If not, you would lose
% all of your AREAFIX changes the next time that your Areas_BBS
% data is manually (using FLAME AREASCVT) or automatically (due
% to a date/time stamp later than AREAS.DAT) compiled.
%
% On the other hand, if you have configured your system to
% automatically add new areas when EchoMail is received with
% previously unknown echo tags, *that* information will be
% reflected by an automatic addition to your Areas_BBS file.
% See the information in AF_NewAreas_Allow_Create for details.
%
%
% Note that the Areas_BBS file may now contain all sorts of other
% configuration information other than area tags and node addresses.
% Be *sure* to look at the documentation for AREAS files for details.
Areas_BBS C:\TBBS\AREAS.BBS
% *--------------------------------------------------------------------------*
% * The binary areas file *
% *--------------------------------------------------------------------------*
%
% This is the file that is created by FLAME from the Areas_BBS defined
% file(s). This improves the speed with which FLAME processes mail.
%
% Since this file gets hammered pretty heavily whenever FLAME is
% operating in "TBBS" mode, you may wish to consider these two steps,
% as they can speed up mail processing considerably:
%
% 1) copy the AREAS.DAT file to a RAMDRIVE before any invocation of FLAME
% 2) place the RAMDRIVE letter at the *front* of your TBBSPATH
Areas_Dat C:\TBBS\AREAS.DAT
% *--------------------------------------------------------------------------*
% * Directory for messages with unknown areas and general problems. *
% *--------------------------------------------------------------------------*
%
% Two kinds of messages will be either deleted, or if this statement is
% used, placed in the directory you specify. They include messages
% that are somehow "malformed" (the internal information in the message
% header is not to specification), and messages in echo areas that are
% not defined in any of your Areas_BBS defined files. All such messages
% will be stored in *.MSG format.
%
% One useful feature of using this statement is that this area is
% always scanned by FLAME for any EchoMail messages that were previously
% tossed here because their AREA tag wasn't found in your Areas_BBS
% file(s). As soon as you add the offending AREA to one of your Areas_BBS
% files, the messages are extracted from this directory and will be
% tossed to your TBBS message base if a board has been defined for them.
%
% Note that if you use AF_NewAreas_Allow_Create (see below) for your
% hub(s), you will never have a situation where a new EchoMail area won't
% be automatically added to your Areas_BBS file, and so no such messages
% from your hub(s) could land here.
Bad_Msgs_General C:\TBBS\BADMSGS\GENERAL
% *--------------------------------------------------------------------------*
% * Directory for messages with security problems (secure and unallowed). *
% *--------------------------------------------------------------------------*
%
% Three kinds of messages will be either deleted, or if this statement
% is used, placed here. This includes echomail messages from systems
% that are not included in your Areas_BBS files for the echo in
% question (unless you have such systems specified in "Secure_Override"
% statements). Again, please note that this is done on an echo by echo
% basis. Any messages received where the packet containing them
% contained a wrong packet password (see "Flame_Password" statement)
% are also parked here. Note that TIMS does not support packet passwords,
% and does not inspect packet headers for password matches. The only
% password that TIMS uses is a session password. Last, if you have
% specified "Routed_Echomail BAD_MSGS", any echomail you receive from
% another system that belongs to a third system will find its way to
% this directory. All such messages will be stored in *.MSG format.
Bad_Msgs_Security C:\TBBS\BADMSGS\SECURITY
% *--------------------------------------------------------------------------*
% * Action for routed echomail from nodes not listed in Route-Through *
% *--------------------------------------------------------------------------*
%
% First, it seems that the "Route_Thru" (below) statement that was once part
% of FLAME no longer exists. Then again, that also appears to be
% the case with "Routed_Echomail". Actually, both are still recognized
% by FLAMEDIT.
%
% Typically, nodes are not permitted to attempt to route Echomail
% through another system. That function is normally performed by
% the hubbing function via each system's AREAS file. In the event
% that another system should send you an EchoMail message whose
% destination address is not your own, you may choose from any of
% four courses of action:
%
% Pass = will be sent (routed) to the other system.
% Any routing configurations you have in ROUTE.CFG will be
% employed if appropriate.
% Delete = will delete the message, never to be seen again.
% Bad_Msgs = will be tossed to your Bad_Msgs_Security directory, if
% you have defined one, else into the bit bucket it goes.
% Bounce = will be deleted, and a NetMail "nastygram" will be sent
% to the system whose address is in the originating field
% of the message header -- this is usually the system that
% actually sent the message to you.
%
% Routed_Echomail Pass
% Routed_Echomail Delete
% Routed_Echomail Bad_Msgs
Routed_Echomail Bounce
% *--------------------------------------------------------------------------*
% * Nodes allowed to transparantly route echomail through this system *
% * Limit: 64 *
% *--------------------------------------------------------------------------*
%
% Having just gone through the things that can happen to EchoMail should
% someone try to route it through your system, FLAME *does* offer the
% option of doing so intentionally in the rare case that this suits your
% situation. It would probably be easier to route entire mail archives
% without opening them (see ROUTE.CFG "[FILE]" option), or to operate in
% the normal "hub" mode, making copies for the final destination.
%
% Any addresses listed here are permitted to send EchoMail to your
% system that contains another system's address in the "From" field, and
% you should have already agreed to forward all of it to its destination.
% Route_Thru <[zone:]net/node>
% *--------------------------------------------------------------------------*
% * Generates a detailed ASCII log of all TOSS/SCAN activity. One log entry *
% * is written for every message tossed and one entry is written for each *
% * message scanned/exported to up/down links. If a message is exported to 6 *
% * nodes 7 log entries will be written. Log entries are TOSS or SCAN *
% * followed by the address, the EchoMail areaname, and the message size. *
% * This file can get very large very fast on a busy hub. *
% *--------------------------------------------------------------------------*
%
% Unless you are troubleshooting some sort of problem, or have a utility
% designed to create summaries of this file, you probably don't have any
% reason to use it. It not only takes up a lot of space, it will slow down
% mail processing.
% Accounting_Log C:\TBBS\ACCOUNT.LOG
% *--------------------------------------------------------------------------*
% * Whether or not to run in a secure environment. Secure mode refuses *
% * echomail messages from addresses not listed in your Areas_BBS file. *
% *--------------------------------------------------------------------------*
%
% Operating in "Secure" mode prevents systems other than those found
% in any of your Areas_BBS files from entering EchoMail into the net
% via your system. You may override this function on a node by node
% basis using "Secure_Override" for systems with address problems.
%
% If you have specified a "Bad_Msgs_Security" directory, and the system
% sending the message is not included in "Secure_Override", such messages
% will be placed into the directory described by "Bad_Msgs_Security" -
% otherwise, the message is deleted.
Secure
% *--------------------------------------------------------------------------*
% * A list of addresses that do not need to be in your Areas_Dat to deliver *
% * echomail to your system. Connections with these addresses should be *
% * secure in other ways such as session password. This is primarily so that *
% * you can run secure mode even though one or more up-/down-link nodes *
% * suffer from multiple address syndromes. *
% * Limit: 16 *
% *--------------------------------------------------------------------------*
%
% For the most part, you should avoid using this feature on your
% system if you are running in a "Secure" environment. The only
% good reasons to use this are to temporarily deal with a node that
%
% 1) is having trouble getting his right zone number into packet
% headers such that what is being sent to you in the packet
% header doesn't match any of the addresses in your Areas_BBS
% file(s).
%
% For example, a Zone 2 system that is placing Zone 1 into the
% origin section of the packet header when sending mail to Zone
% 1 systems would qualify for this kind of treatment.
%
% 2) is getting the wrong address entirely, due to reasons described
% in the documentation supplied above. Some folks have a hard
% time explaining to their systems which of their several
% addresses should be used on mail at any particular time.
% The trouble with this approach is that unless the node is at
% least getting his correct address into the SEEN-BY information,
% you may well wind up duplicating the message and sending it
% back to him at the address that *is* shown in your Areas_BBS
% file(s).
%<Z>
% Secure_Override <[zone:]net/node>
% *--------------------------------------------------------------------------*
% * Flag EchoMail messages with entry dates more than Dupe_Days ago as dupes.*
% * If this parameter is selected messages with unrecognized date formats *
% * and dates more than Dupe_Days in the future are also flagged as dupes. *
% *--------------------------------------------------------------------------*
%
% Note that the FTS-0001 standard provides for two dating formats for
% FidoNet messages. Both the "Opus" and "Seadog" date schemes are
% understood by FLAME in determining message age.
%
% Difficulties in mail routing may make using a more conservative figure
% such as Dupe_Days 7 impractical.
% Dupe_Days 30
% *--------------------------------------------------------------------------*
% * Nodes which should be added to the SEEN-BY lines of passing mail *
% * Your own address is added automatically. *
% * Limit: 10 *
% *--------------------------------------------------------------------------*
%
% Although normally not required, there may be occassions where you
% need to add one or more additional addresses to the SEEN-BY list on
% all of your messages; that is to say, addresses other than your
% primary "Node" address and any you add with a "Zonegate" statement
% (see below). One example of this that may occur is where you hold
% more than one address in a network, and are concerned that some nodes
% may not consistently use just one of your addresses in their AREAS
% file. You may wish to add your AKA's to all messages under such
% circumstances. Note that this will occur universally. It is not
% possible to limit this to specific areas or when packing mail to
% specific nodes.
%<Z>
% Add_To_Seenby <[zone:]net/node>
% *--------------------------------------------------------------------------*
% * Setup for EchoMail zonegates. (16 nodes max per zonegate) *
% * This becomes the all-inclusive SEEN-BY: list for all EchoMail sent to *
% * the first address listed. If you do not include your own address the *
% * mail can bounce right back to you. *
% * Limit: 64 *
% *--------------------------------------------------------------------------*
%
% Syntax: <address of destination system> <address for SEEN-BY>
%
% Typically, one of your own AKA addresses is used for the second
% parameter.
%
% If you are a member of multiple networks, or are moving mail between
% multiple zones within a network (the zone number being the issue here
% in any case), you will probably wish to make use of this feature in
% order to keep your SEEN-BY information "clean". By specifying
% "Zonegate", any EchoMail sent to the system specified in the first
% parameter has any existing SEEN-BY information stripped (there won't
% be any unless you are a mail hub), and your own information (whatever
% it is you specify in the 2nd parameter) starts the new SEEN-BY list
% for the message. If you are not hubbing mail, this simply determines
% which of your addresses you wish to have appear in SEEN-BYs for mail
% being sent to a particular system.
%
% For example:
% If you hold addresses in both Zone 1 and Zone 8, and are packing
% mail for your Zone 8 hub or hubees, and your primary address as
% shown in "Node" is your Zone 1 address, you should use your hub or
% hubees address for the first parameter, and your Zone 8 address for
% the second parameter.
%
% When more than one zone shares the same net and node addresses (for
% example, there could be a 1:104/114 and a 8:104/114), placing your
% primary address in the SEEN-BY list unnecessarily might keep someone
% with the same net/node in another zone from ever seeing the message.
% SEEN-BY technology for EchoMail has its limitations. You can help
% keep your network happier by using the Zonegate feature to prevent
% such problems. The example below places *only* the 7703/4703 address
% in the SEEN-BY line for any EchoMail created for 8:7703/1.
%<Z>
Zonegate 8:7703/1 8:7703/4703
% *--------------------------------------------------------------------------*
% * Individual nodes that are to receive tiny SEEN-BY: lines. *
% * The SEEN-BY list of EchoMail areas sent to these addresses will include *
% * only the addresses listed for that area in your Areas file. *
% * Limit: 64 *
% *--------------------------------------------------------------------------*
%
% Most networks permit what is known as the "Tiny Seenby" to be used
% in assembling the SEEN-BY information in EchoMail messages. The
% "Tiny Seenby" is nothing more than removing redundant net numbers
% from a SEEN-BY list, using the assumption that the last net number
% is still the one we mean until another one comes along. For example,
% instead of having
%
% SEEN-BY 114/2 114/112 114/131 104/1 104/114 104/118 30333/1
%
% this would be reduced to
%
% SEEN-BY 114/2 112 131 104/1 114 118 30333/1
%
% As you can see, this can save a lot of "overhead" in a message, and
% the majority of mail processors recognize this technique. Be sure,
% however, that you ask your Net Coordinator whether or not your
% network permits this.
% Tiny_Seenby <[zone:]net/node> <[zone:]net/node> <[zone:]net/node> etc
% *--------------------------------------------------------------------------*
% * Areafix protection and optional bundle (.pkt) level passwords. *
% * All fields except Bundle Pw are required. *
% * Limit: 255 *
% *--------------------------------------------------------------------------*
%
% If you are not hubbing mail for other systems (including points),
% and do not use "packet passwords", then you do not need to use
% any of the features of this statement.
%
% First, please note that the PASSWORD information that may be found in
% any TIMS.CTL or AREAFIX.CTL files is *not* looked at by FLAME as
% equivalent to a Flame_Password, and they are in rather different
% formats. So although they may in fact be the same password here as
% specified in those other files, they must also be specified here.
%
% Net/Node Level Key Areafix Pw Bundle Pw (optional)
% -------------- --------- ----- ---- -------- --------
INCLUDE FLAMEPW.CTL
% Not too helpful? Well, it does demonstrate how INCLUDE statements
% may be used in your FLAME.CFG file just as is the case for TIMS.CTL.
% In this example, it was possible to display an entire FLAME.CFG file,
% without editting, since all of the password information exists
% elsewhere. This is a good idea for those of you who share files with
% others to give them a hand in understanding how to configure their
% systems. Below is the same table filled with a few dummy arguments.
% Note that any number of spaces can be used between arguments, and that
% you can modify the size of some fields to make them more readable.
%
% Each line must begin with the expression "Flame_Password", followed
% by the full address of the system being described. Next, a level and
% key are given that allow you to control which nodes may AREAFIX
% a particular set of echos from your system (see the separate
% discussion of using AREAFIX as a mail hub). If you are not hubbing
% for other systems, this "Level" and "Key" information, and the
% "Areafix Pw" (password) can be filled with dummy information. In
% this case, you should only be using this option in order to get the
% benefit of the optional "Bundle Pw" (packet password) feature. In
% this sense, the packet password option and AREAFIX options have been
% blended together here, when in fact, they are separate functions of
% FLAME. You should feel free to use one without the other if it is
% appropriate for your system.
%
%
% Net/Node Level Key Areafix Pw Bundle Pw
% -------------- ----------- ----- ------- -------- --------
Flame_Password 1:104/115 100 AB GROCKIT
Flame_Password 1:2905/1400 50 A DONGLE
Flame_Password 2:255/1 100 ABCDEF GOBRIT TRINUK
% *--------------------------------------------------------------------------*
% *--------------------------------------------------------------------------*
% * PACKER SETUP *
% *--------------------------------------------------------------------------*
% *--------------------------------------------------------------------------*
%
%
% *--------------------------------------------------------------------------*
% * The packer's routing file *
% *--------------------------------------------------------------------------*
%
% Use of a routing file is not mandatory, but FLAME will warn you of
% its absence when FLAME is started up. However!!! without defining a
% Routing_File, NONE of your outbound mail will be archived or routed,
% and will be left in packet form. See the commentary on ROUTE.CFG for
% all you would miss!
%
% One of the primary sources of confusion for new users of FLAME is
% that they tend to think that defining an archiver for a particular
% node (see extensive info in "Pack", below) causes mail for that node
% to be archived. That is NOT the case. You need to BOTH define the
% preferred archiver AND tell FLAME to archive the mail in ROUTE.CFG.
Routing_File C:\TBBS\ROUTE.CFG
% *--------------------------------------------------------------------------*
% * Maximum size of a compressed mail file before starting a new file *
% *--------------------------------------------------------------------------*
%
% This item is of concern only to sysops who wish for whatever reason to
% limit the size of outbound mail archives. This is therefore used
% almost exclusively by those systems that are acting as mail hubs for
% other systems. This will cause FLAME to start over with the next
% logical archive filename in the sequence (if you have 00000001.SA0,
% 00000001.SA1 will be started) if the first archive becomes larger
% than what you specify here.
%
% Note that no matter *what* number you place here, your mail archives
% can grow larger unless you also make use of "Max_Msgs nnn Tossed"
% as shown in the next description. This is because FLAME will never
% attempt to split a packet, and will, if it creates a huge packet,
% go ahead and add it to an archive, quite possibly exceeding your
% request here by a very large number of bytes.
%
% However, if you limit the number of messages generated in your
% outbound packets using "Max_Msgs", then FLAME will be able to quit
% adding packets to your archives when it reaches or exceeds the
% Compressed_Mail_Max_Bytes number of bytes without substantially
% overrunning your requested Compressed_Max_Mail_Bytes. Note that
% as long as the archive is still under the number you specify here,
% FLAME *will* add the next packet.
Compressed_Mail_Max_Bytes 500000
% *--------------------------------------------------------------------------*
% * Stop scanning and exit after processing this many messages. The *
% * number can be set to exit after tossing or scanning the indicated number.*
% * The default operation is to TOSS/SCAN without interruption. *
% * *
% * Syntax: Max_Msgs ### Scanned << this is the default if blank. *
% * Syntax: Max_Msgs ### Tossed *
% * *
% *--------------------------------------------------------------------------*
%
% Actually, "exit" means to pack up whatever has been processed so far
% and, if called for, to shell out to DOS to the appropriate archiver
% to archive the packet. Whether or not archiving occurs depends upon
% the data in your ROUTE.CFG, and what archiver (if any) gets used for
% a particular node is determined by the "Pack" statement, below. Once
% this "exit" is done, control returns to FLAME and it continues on
% processing your mail.
%
% "Tossed" refers to the count of messages processed during any inbound
% mail processing, and "Scanned" refers to the count of new messages
% found while scanning your own message base.
%
% This is what limits the number of messages that will get added to a
% given packet, and what, in turn, allows one to have some control over
% the size of an archive with the "Compressed_Mail_Max_Bytes" command.
% Since FLAME can create a humongous packet if you don't control it
% here, you'll never be able to keep archives under any sort of control
% otherwise. So set "Max_Msgs 500 Tossed" or something along those lines
% to keep the size of the packets from being so large that a single one
% would already blow you over the top.
%
% A good rule of thumb is that typical mail packets will archive
% down to 1/3 of their original size. If your average message
% length is about 2000 bytes including the overhead for the
% message header, then
%
% 500 msgs * 2,000 bytes = 1,000,000 bytes
% of packet
% --------------- = 300,000 byte archives
% 3
%
% As you can see, two of these passes of 500 messages each would run
% a total of 600000 bytes, and the Compressed_Max_Mail_Bytes would
% shut off adding any new packets to the current archive if its limit
% were set at 500000.
%
% If your users are creating huge volumes of new mail on your system
% between invocations of FLAME, you may also find it helpful to use
% the "Scanned" option as well. As with "Tossed", FLAME will pause
% after the number of messages you specify to process the mail that
% has been found up to that point.
%
% Max_msgs 5000 Scanned
Max_Msgs 500 Tossed
% *--------------------------------------------------------------------------*
% * Globally disallows forwarding of netmail messages *
% *--------------------------------------------------------------------------*
%
% If you are not hubbing for other nodes, including points, then you
% may wish to leave this in to avoid forwarding messages for other
% systems that they might "drop" onto your system. If, on the other
% hand, you are doing any hubbing or pointnet work, you should leave
% this one commented out, as forwarding of NetMail will likely be one
% of your responsibilities.
% No_Forward_Mail
% *--------------------------------------------------------------------------*
% * Where to forward inbound network mail to. *
% * - Outbound Area copies the netmail messages directly from inbound packet *
% * to outbound packet. This is the default operation. *
% * - Netmail Area writes netmail not addressed to one of your addresses to *
% * .Msg files in the NetMail subdirectory. *
% * Forwarding directly to Outbound is faster but does not allow external *
% * processing as forwarding to (through) the netmail area does. *
% *--------------------------------------------------------------------------*
%
% Don't let the use of the word "forward" throw you here. No mail is
% being "forwarded" anywhere that it wasn't already going to be. The
% function of this statement is to determine whether any new inbound
% NetMail messages to another node will be written a) as *.MSG files in
% your "Mail" directory, or b) directly to the appropriate packet for
% the addressee. If you've turned off forwarding for the node in
% question, the message doesn't go either place, just as you wish.
%
% In the event (probably rare) that you've got a reason to deal with
% NetMail passing *through* your system with some third party utility,
% it would be necessary to save these as *.MSG files such that the
% utility could get to them and do whatever it's designed to do.
Forward_NetMail_To Outbound Area
% Forward_NetMail_To Netmail Area
% *--------------------------------------------------------------------------*
% *--------------------------------------------------------------------------*
% * Inbound and outbound compressed mail setup *
% *--------------------------------------------------------------------------*
% *--------------------------------------------------------------------------*
%
% *--------------------------------------------------------------------------*
% * Program and format definitions for archiving and unarchiving mail *
% *--------------------------------------------------------------------------*
%
% This section is used to describe any archivers that you expect to use
% for archiving mail to other nodes, and to identify archivers that may
% be used to create mail archives that you receive.
%
% Note that FLAME will attempt to automatically detect the type of
% archiver that was used on those archives that you receive and to call
% the appropriate unarchiver to extract the packets from these archives.
% This is done by looking at specific locations within the archive to
% see if any "signatures" exist that FLAME knows about from these
% "Archiver" definitions. Each of the many archivers in use leaves some
% telltale sign in its archives that identifies that it was the utility
% used to create the archive.
%
% The list provided in the FLAME.CFG file covers all of the more
% commonly used archivers. In the event that a new archiver comes
% along, or one is modified by the author such that the signature
% changes, it is easy to add new entries to this list.
%
% The signature line contains two fields. The first is the offset into
% the file where the signature can be found. If the offset is a
% negative number, this means that the signature is to be found that many
% bytes before the *end* of the file, not from its beginning.
%
% The second field is the signature that should be found at the specified
% offset location. For example, the first byte of a PKARC archive
% (offset = 0) will always be a hexidecimal 1A. Note that hexidecimal
% values are given between the < and > characters. Straight ASCII values
% (printable characters) may either be expressed as characters or in
% hexidecimal. Note, for example, that ZIP (at offset = 0) shows
% PK<0304>, meaning that the file starts with the characters PK and the
% next two bytes are 03 and 04 hex. This could have also been
% represented as <504B0304>.
%
% The "Extract" and "Add" fields are definitions of the command lines
% that each archiver requires to remove files from an archive and to add
% files to an archive, just as they would be used in DOS. The variable
% %1 will always be filled in with the archive filename, and %2 will be
% filled in with a packet filename. The filenames are passed to the
% archivers by FLAME.
%
% Note that in cases where more than one archiver shares the same
% signature (as with PKXARC v.s. ARC7, and LHA v.s. LHARC), FLAME will
% make an attempt at them in sequence.
%
% PKARC Example:
%
% For extraction, use -r, which causes an overwrite of any existing
% PKT file of the same name. (Why? I don't know!) For archiving
% the old ARC version 5 compatibility is requested using "-oct". Note
% the use of "-a" instead of "-m" as is common in some other utilities
% of this type. FLAME creates the archives, and then deletes the
% packets *itself*. Be careful of this when creating any new archiver
% definitions.
Archiver PKARC
Signature 0 <1a>
ArcType 9
Extract pkxarc -r %1 *.pkt
Add pkarc -oct -a %1 %2
End PKARC
Archiver PAK
Signature -2 <fe>
ArcType 11
Extract pak e /wn %1 *.pkt
Add pak a %1 %2
End PAK
Archiver ARC7
Signature 0 <1a>
ArcType 20
Extract arc7 eow %1 *.pkt
Add arc7 amo %1 %2
End ARC7
Archiver ZIP
Signature 0 PK<0304>
Extract pkunzip -o %1 *.pkt
Add pkzip -a -o %1 %2
End ZIP
Archiver LHA
Signature 2 -lh
Extract lha e %1 *.pkt
Add lha a /m %1 %2
End LHA
Archiver LHARC
Signature 2 -lh
Extract lharc e %1 *.pkt
Add lharc a /m %1 %2
End LHARC
Archiver ARJ
Signature 0 <60ea>
Extract arj e -n %1 *.pkt
Add arj a -e %1 %2
End ARJ
Archiver ZOO
Signature 0 ZOO
Extract zoo e:O %1 *.pkt
Add zoo a: %1 %2
End ZOO
% *--------------------------------------------------------------------------*
% * Assign defined ARCHIVERs to lists of nodes *
% *--------------------------------------------------------------------------*
%
% You should be aware that simply assigning an archiver to a node in
% this table does NOT cause FLAME to archive mail for the node. It only
% identifies which archiver should be used if mail IS archived for these
% nodes. Control over whether or not archiving occurs is handled in the
% ROUTE.CFG file, covered elsewhere. See "Routing_File", above.
%
% You do not specify which unarchiver to use for any node. As noted
% above in the "Archiver" section, FLAME detects archive type
% automatically for inbound archives.
%
% WARNING! If archived mail already exists for a node, and if you
% then define a different archiver for that node, trouble is guaranteed
% to occur when FLAME tries to add a new packet using a different
% archiver than that which originally created the archive! Before
% making such changes, check your outbound area (you can use FLAME VIEW
% for this) to see what archives may exist for the node whose archiver
% you plan to change. You can either wait for the archive to be
% transmitted to the other node and deleted, or you can manually extract
% and rearchive the file using the new method before calling FLAME to do
% its work.
%
% Note that you are limited to 64 node numbers on any single archiver
% line. However, you may *duplicate* the same archiver name on a
% separate line if needed to associate a total of more than 64 nodes
% with a specific archiver.
%
%
% Archiver: Node:
% ---- --------------- ----------------------------------------------> 64
Pack ZIP 1:104/115 104/118 104/123 104/124 104/125
Pack LHARC 1:104/1 104/18 8:7703/1 8:7703/4
% *--------------------------------------------------------------------------*
% * Define default ARCHIVER to assign to all other nodes. This defaults to *
% * the first Archiver defined if not indicated here. *
% *--------------------------------------------------------------------------*
%
% If you do NOT specify a Default_Archiver by using this statement with
% one of the names from your "Archiver" list, the first entry in "Archiver"
% list will be used as for your default archiver. Note that in a
% FidoNet environment, you should use PKARC for your default archiver
% with the "-oct" option for ARC5 compatibility, as this is the FidoNet
% standard. However, you can prearrange to use any archiver with other
% nodes by mutual consent.
Default_Archiver PKARC
% *--------------------------------------------------------------------------*
% * DOS command line to execute immediately after each incoming archive *
% * is unpacked into packets. *
% *--------------------------------------------------------------------------*
%
% In the event that you have some utility that you need to run on
% incoming mail packets before they are processed by FLAME, here is
% the place to specify it. After FLAME calls the appropriate
% unarchiver to extract the packets, whatever you like will be run.
% FLAME contains a good "grunged message detector" to get rid of
% damaged messages, but such a utility would logically be inserted
% here in the process. Normally, nothing will be done here.
% After_Unpack C:\TBBS\SOMEFILE.BAT
% *--------------------------------------------------------------------------*
% *--------------------------------------------------------------------------*
% * REMAPPER SETUP *
% *--------------------------------------------------------------------------*
% *--------------------------------------------------------------------------*
%
%
% *--------------------------------------------------------------------------*
% * Remaps incoming Net Mail addressed to your Node or Aka according to the *
% * network mail 'name' field. *
% * The name is a complete name that must match the incoming message name *
% * field. Spaces are significant. Case is ignored. *
% * Limit: 255 *
% *--------------------------------------------------------------------------*
%
% Note that at the time of writing, some systems were encountering
% difficulties when using a combination of remapping by name for
% points and AREAFIX functions. The most common symptom appears to
% be that FLAME doesn't "see" the password entry for the remapped
% point.
%
% If you are using a pointnet address as described earlier, FLAME will
% take NetMail messages directed to your BBS address and remap them to
% your points' pointnet addresses if you define them here. In the
% example below, any NetMail received that is sent to the BBS primary
% or an AKA address that is To: "Chris Anderson" or To: "Sysop" (not
% case sensitive) will be remapped to address 1:30333/1 and then
% processed by FLAME as would be any mail for that address.
%
% Note that the "outside world" is unaware of your private pointnet net
% number, and that other systems could not therefore know where to send
% a message or reply to one of your points if the private pointnet was
% shown in the original message. This is remedied by FLAME during the
% sending of your points' messages out into the network (see the
% "pointnet" command, above). Since those systems in the "outside
% world" don't know the pointnet address to use to send mail to your
% points, they simply send it to your BBS address, and you specify here
% how it should be "forwarded" (remapped) to your points.
%
% This can be convenient if you are operating as a point from your own
% system, since you can have your BBS forward your NetMail to you at
% your point address. This is a great feature for those "road
% warriors" that prefer to use a mailer when travelling rather than
% logging onto the BBS to receive each day's mail. It can certainly
% cut down on the phone bills from hotels.
% New Address Name
% ---------- --------------- ------------------------
Remap_Name 1:30333/1 Chris Anderson
Remap_Name 1:30333/1 Sysop
Remap_Name 1:30333/2 Chris Yoder
% *--------------------------------------------------------------------------*
% * Remaps according to the network mail destination zone:net/node field *
% * Limit: 255 *
% *--------------------------------------------------------------------------*
%
%
% This causes NetMail addressed to one system to be remapped to another
% address. This isn't often used, but can be handy if a node for whom
% you were once hubbing has moved and has a new address, and you want
% to be able to forward mail from those systems that aren't yet aware
% of the new address. In the example, it looks like someone in Denver
% (Net 104) has moved to Colorado Springs (Net 128). Another reason for
% using this feature might be if you wished for all of your own NetMail
% to be sent to another of your systems or addresses. This can be handy
% when you hold multiple addresses and wish to avoid reading mail on
% multiple systems. However, be aware that *all* NetMail destined for
% the "Old Address" is remapped with this command, and that would
% include NetMail for your users. Of course, much of this can be
% handled within ROUTE.CFG as well using the ROUTE command, but that
% will effect both NetMail and EchoMail.
% New Address Old Address
% ---------- ----------- -----------
% Remap_Node 1:128/206 1:104/123
% *--------------------------------------------------------------------------*
% *--------------------------------------------------------------------------*
% * AREAFIX SETUP *
% *--------------------------------------------------------------------------*
% *--------------------------------------------------------------------------*
%
% As already explained, unless you are hubbing for other nodes or points,
% you will have no use for *any* of the AREAFIX statements with the
% possible exception of some of the AF_NewAreas_something statements.
% For example, AF_NewAreas_Allow_Create will tell FLAME that any new
% echo area you receive may be added to your AREAS files provided that it
% is sent to you by a particular node. If you are using QSO and the
% "alternative" (*.MSG) non-TBBS message base technique to keep greater than
% the 64K limit of messages for your QSO users, some of these may also be
% of use to you.
%
% In addition to the commands found here, you must also review the
% contents of the AREAS.BBS sample, as a number of commands related to
% the AREAFIX function of FLAME are to be found there. Specifically, the
% assignment of "Level" and "Key" to each echo to control which nodes may
% AREAFIX each echo is found there, and the ability is given to purge out any
% passthrough areas that no longer have any active downstream nodes. See
% the MODE = LEVEL, LOCK, and MODE = PURGEOK statements there.
%
% *--------------------------------------------------------------------------*
% * Allow users to perform a rescan on requested areas (not available w/TBBS)*
% *--------------------------------------------------------------------------*
%
% As hinted at above, this only works with the "alternate" message base
% method, not with the TBBS message base. If you do use the "alternate"
% method, this will permit an AREAFIX user to request that your alternate
% message base *.MSG files be scanned for all messages in an area and that
% they be sent to him. This is typically done when a node wants to start
% an echo with a good load of messages, rather than wait for the area to
% fill with new mail.
% AF_Allow_Rescan
% *--------------------------------------------------------------------------*
% * Allow users to obtain a list of available areas they currently do not rcv*
% *--------------------------------------------------------------------------*
%
% The information from your AREAS_BBS file(s) is checked to see which areas
% are available to the node, but are not presently being received.
% AF_Allow_Query
% *--------------------------------------------------------------------------*
% * Shows the user if they are a feed on specific echos *
% *--------------------------------------------------------------------------*
%
% The "feed" for an echo is defined as the first node in the AREAS list
% for an echo. The standard procedure for creating your AREAS file is
% to place your source for the echos first in your list(s).
% AF_Show_Feeds
% *--------------------------------------------------------------------------*
% * Instructs Areafix to save any processed inbound messages *
% *--------------------------------------------------------------------------*
%
% If you wish to keep track of AREAFIX activity on your system, you have
% several choices, one of which is to save them as *.MSG files in your
% "Mail" directory. This is usually only necessary for troubleshooting,
% since you also have the option for AF_Alert, below, that describes what
% the requesting node is being told about his request.
% AF_Save_Messages
% *--------------------------------------------------------------------------*
% * Instructs Areafix to mark all outbound Areafix messages as Kill/Sent *
% *--------------------------------------------------------------------------*
%
% Unless you want outbound AREAFIX messages to start to clutter up your
% "Mail" directory, you should mark them as Kill/Sent so that when they
% are packed up for sending by TIMS, there aren't any copies left laying
% around. Therefore, you should probably leave this uncommented.
% AF_Kill_Sent
% *--------------------------------------------------------------------------*
% * A list of alias names for incoming messages (AREAFIX is always included) *
% * Limit: 16 *
% *--------------------------------------------------------------------------*
%
% Some people are used to using utilities other than AREAFIX to accomplish
% the same purpose. Messages addressed "To: AREAFIX" will always be
% processed by FLAME, but other names can be used by your users to invoke
% FLAME's AREAFIX processing. List those here if there is a need.
% AF_Alias AreaMgr MyPersonalAreaFileManager
% *--------------------------------------------------------------------------*
% * The file Areafix should return when prompted by a "-l" or %list *
% *--------------------------------------------------------------------------*
%
% If you wish to support the AREAFIX -l processing, this will cause a
% file to automatically be sent to the requesting node. You will need
% to decide what file is appropriate. Understand that what the requesting
% node wants is a list of your available echo areas.
% AF_List_File C:\TBBS\PS_AREAS.ARC
% *--------------------------------------------------------------------------*
% * The message text Areafix should return when prompted by a "-h" or %help *
% *--------------------------------------------------------------------------*
%
% Note that this file must be 4096 or less bytes in size. If you wish to
% provide a node who requests help information about your AREAFIX setup,
% place the information in this file and it will be sent in response.
% AF_Help_File C:\TBBS\AREAFIX.HLP
% *--------------------------------------------------------------------------*
% * Enable Areafix to chain requests for echos. Areafix will manage this file*
% *--------------------------------------------------------------------------*
%
% If an echo is requested that you aren't carrying, but shows as available
% based upon the list in the file defined in an AF_Forward_List file (see
% below), FLAME will send a request upstream to attempt to get the echo for
% the requesting node. The file specified here in the AF_Forward_Que
% statement keeps track of which node has requested the echo, and adds that
% node to your AREAS.DAT when the echo arrives from your upstream hub.
% AF_Forward_Que C:\TBBS\AREAFIX.QUE
% *--------------------------------------------------------------------------*
% * When a change is made Areafix will send a copy of the return message here*
% * Limit: 10 *
% *--------------------------------------------------------------------------*
%
% Any AREAFIX activity will cause a copy of the message that is returned
% to the requesting node to also be sent to any addresses you specify here.
% AF_Alert <[zone:]net/node>
% *--------------------------------------------------------------------------*
% * Nodes Areafix can chain echomail requests to *
% *--------------------------------------------------------------------------*
%
% Even if you don't have a requested echo on your system, FLAME can be
% asked to automatically request that echo from one or more of your
% hubs. You may have several AF_Forward_List statements if you have
% more than one hub and more than one list of echos available.
%
% In the event that an echo tag exists in more than one of the "List files"
% you specify, the first match is used from your list in the order in
% which you place them here.
%
% There are several formats for echo lists. The appropriate format must
% be specified in order for FLAME to know how to search the file.
%
% Text = ASCII text file in the form echotag description
% DAT = FLAME AREAS.DAT format
% TBBS = TBBS AREAS.BBS format
%
% Unless you are dealing with another system using FLAME, you will need
% to obtain a file in the "text" format. You should make a practice of
% regularly file requesting or receiving the full list of available echos
% so that the nodes for whom you hub will be able to request newly
% created echos.
%
% If the requested echo isn't carried on your system, and cannot be
% found in any of the files specified here, the requesting node will
% receive a message stating that the echo in question is unavailable.
%
% If you don't specify any AF_Forward_List, then unless the echo in
% question is available on your system already, the requesting node
% will receive a message stating that the echo is unavailable.
%
% If the echo is found, an AREAFIX message is created for the system
% listed under "Net/Node:" for that echo. An AREAFIX password is
% included as specified for that node.
% List file: File format: Net/Node: Password:
% --------------- -------------------- ------------ ----------- --------
% AF_Forward_List C:\TBBS\FILES\Fidonet.Na Text 1:104/115 MYPASS1
% *--------------------------------------------------------------------------*
% * Activate new area create and define the attributes of new area created *
% *--------------------------------------------------------------------------*
%
% When a new area is created due to the arrival of a new echo from either
% an AREAFIX request from FLAME or the AF_NewAreas_Allow_Create (below),
% it can either create an "alternate" message area (using *.MSG files) or
% can be added to your AREAS as passthrough area. If you specify *.MSG
% by using "Msg", then all new traffic in that area will start to accumulate
% on your system.
% AF_NewAreas Msg
% AF_NewAreas Pass
% *--------------------------------------------------------------------------*
% * Do not create directories for new .MSG areas created *
% *--------------------------------------------------------------------------*
%
% If you specify "Pass" for "AF_NewAreas", then you definitely have no
% need for new *.MSG directories for new echo areas, and this statement
% should be uncommented. If you want separate subdirectories created
% for the "alternate" message storage areas, then it would be wise to
% permit FLAME to create a subdirectory for those messages, and you
% would not comment out this statement.
% AF_NewAreas_Nodir
% *--------------------------------------------------------------------------*
% * The user access level of newly created areas (0 to 30000) *
% *--------------------------------------------------------------------------*
%
% Since all echo areas may be protected by access level and key, you
% must specify what level will be assigned to new echos as they are
% received either due to an AREAFIX you send or the AF_NewAreas_Allow_Create.
% This information is added to your AREAS.DAT file along with the name of
% the echo, the source of the echo, the requesting node (if any) and the
% lock string (see below). See "Flame_Password", above, to identify the
% access level that you assign to each node that you plan to permit to
% use AREAFIX requests. A node's access level as assigned there must
% be equal to or greater than that specified here to make new echos
% automatically available.
% AF_NewAreas_Level 100
% *--------------------------------------------------------------------------*
% * The lock string for newly created areas (1 to 50 characters) *
% *--------------------------------------------------------------------------*
%
% Just as you need to supply the AF_NewAreas_Level (above), you need to
% supply the default lock string for new echos as they are received.
% If you haven't yet read the information in the AREAS.BBS file description
% that explain the use of area levels and locks, you should do so before
% making any decisions about either of these options. A node's keys as
% defined in "Flame_Password", above, must cover the key(s) you specify
% here in order that new echos will be automatically available.
% AF_NewAreas_Lock ABCD
% *--------------------------------------------------------------------------*
% * Nodes Areafix should add to newly created areas *
% * Limit: 64 *
% *--------------------------------------------------------------------------*
%
% If you wish to automatically add a node or nodes whenever a new echo is
% received, place their node number here. If, for example, you are
% providing a your net's full backbone feed to another system, this is
% an easy method for automatically getting all new echos to that system.
% AF_NewAreas_Add_Nodes <[zone:]net/node>
% *--------------------------------------------------------------------------*
% * Create new areas only if the inbound message is from these nodes *
% * Limit: 64 *
% *--------------------------------------------------------------------------*
%
% Placing one or more node numbers here will cause any new echos (those not
% already defined in your AREAS.DAT file) that you receive from the listed
% node(s) to automatically be added to your AREAS.DAT file. This can be
% especially handy when you send AREAFIX messages to your hub, as new
% areas are automatically added for you when the arrive. If you are
% operating as a hub system, this becomes even more convenient. Note
% that changes are made to both your "human readable" Areas_BBS defined
% file and your AREAS.DAT file. This prevents the loss of any new
% areas should your Areas_BBS file be recompiled.
% AF_NewAreas_Allow_Create <[zone:]net/node>
% *--------------------------------------------------------------------------*
% * The directory off which Areafix will create the new message directory *
% *--------------------------------------------------------------------------*
%
% If you don't specify AF_NewAreas_Nodir, or if you specify *.MSG style in
% AF_NewAreas to use the "alternate" storage method, then FLAME is going to
% need to be told where you want the subdirectories for each echo area. As
% each new echo area is found, a subdirectory will be created below the
% directory specified here. The directory name is created using up to the
% first 11 characters of the echo tag for the echo. If the echo is called
% ALT_HAMSTER_DUCTAPE, the subdirectory created will be ALT_HAMS.TER and
% the balance is truncated.
% AF_NewAreas_Direc C:\TBBS\MSG
% *--------------------------------------------------------------------------*
% * The top part of the Notify functions response message *
% *--------------------------------------------------------------------------*
%
% Note that this file must be 4096 or less bytes in size.
%
% If you type FLAME AREAFIX NOTIFY from the command line, or a
% notification message is generated from an AREAFIX request, FLAME will
% generate a message to the specified node(s) giving a list of the
% echos for which the node(s) is/are currently active. If you specify
% a filename here, the content of this file will be appended to the
% head of the message as a preface.
% AF_Notify_Header C:\TBBS\NOTIFY.TXT
% *--------------------------------------------------------------------------*
% * Nodes to exclude from a Notify session *
% *--------------------------------------------------------------------------*
%
% If you wish to avoid sending any replies to an AREAFIX message for
% certain nodes, supplying those node numbers here will prevent it. The
% FLAME docs specify that all nodes are informed, but neglect to
% note that either all *or* individual nodes may be informed by using
% FLAME AREAFIX NOTIFY.
% AF_Notify_Exclude 1:104/1
% *--------------------------------------------------------------------------*
% * Include the echo list when doing a Notify *
% *--------------------------------------------------------------------------*
%
% If you always wish to send a full list of your areas to a node when
% replying to an AREAFIX message, you can specify that file here. This
% is the same file that is returned in response to a "-l" as defined
% in "AF_List_File", above.
% AF_Notify_With_List
% *--------------------------------------------------------------------------*
% * Filename for Areas_DAT file export (Areas.Txt) *
% *--------------------------------------------------------------------------*
%
% If you manually perform an FLAME AREAFIX EXPORT, it will default to
% AREAS.TXT. However, if you supply a filename here, this will cause
% an AREAFIX EXPORT to be done automatically whenever an AREAFIX message
% is processed that changes your AREAS.DAT file. The results will be
% sent to the filename you specify here. Since this automatic feature
% is only turned on by supplying a filename here, there is no default.
%
% Some sysops have kept backup copies of their AREAS.BBS files and have
% pointed the AF_Export_File directly back at their AREAS.BBS files rather
% than using the intermediate file AREAS.TXT. So long as nothing goes
% wrong with the creation of the human readable file specified here, this
% provides a "closed loop" situation where your AREAS.BBS can be modified
% manually, but you never run the risk of accidently compiling it without
% new AREAFIX changes that may have only been reflected in the AREAS.DAT
% file. If this is a bit confusing, please re-read the section that
% defines the binary and human-readable versions of the AREAS files. The
% following may help you a bit:
%
% If this configuration line is specified, and you use AREAS.BBS,
% and you receive an AREAFIX message:
%
%
% Old AREAS.BBS --> Old AREAS.DAT
% |
% (then if receive AREAFIX msg)
% |
% New AREAS.BBS <--------+--------> New AREAS.DAT
%
% If you do not specify AREAS.BBS, then you will need to review the
% resulting file (for example, AREAS.TXT) and copy it over your AREAS.BBS
% file so that new changes aren't lost when AREAS.BBS is compiled in the
% event that you change it manually for some reason.
% AF_Export_File C:\TBBS\AREAS.TXT
% *--------------------------------------------------------------------------*
% *--------------------------------------------------------------------------*
% * DUPLICATE FILE SETUP *
% *--------------------------------------------------------------------------*
% *--------------------------------------------------------------------------*
%
%
% *--------------------------------------------------------------------------*
% * The duplicate database file name (set to NUL to disable) *
% *--------------------------------------------------------------------------*
%
% If your system will be processing inbound EchoMail, the file that you
% define here will hold certain key information about each message that
% can be used to determine if the same message arrives at your system
% again for processing (a duplicate message). Such messages can be
% saved for inspection or deleted automatically. The maximum number of
% messages for which the key information is saved is specified in the
% Dupe_History_Count, and the number of echo areas and the number of
% messages per area will dictate the size of this file.
%
% Whether or not you wish to do this may well depend upon whether you
% are hubbing for other systems. It is a good service for any network
% if its mail hubs do duplicate message checking.
%
% Note that larger AREAS.DAT and DUPES.DAT will require additional
% conventional memory when FLAME runs. If you are not hubbing for
% other systems, and if your echos feeds are consistently free of
% duplicate messages, or if posting duplicate messages (or passing them
% along) is not of concern in your environment, you can save both
% mail processing time and disk space by commenting out this option.
%
% This file will increase in size as new areas are added, but the
% file does not automatically decrease in size as areas are removed.
% You must use FLAME DUPES to remove unused areas to reduce its size.
Dupe_History_File C:\TBBS\DUPES.DAT
% *--------------------------------------------------------------------------*
% * The maximum number of duplicate records for each area *
% *--------------------------------------------------------------------------*
%
% This specifies the number of messages that will be tracked for
% duplicate detection in each echo area that appears in your AREAS
% file.
Dupe_History_Count 2000
% *--------------------------------------------------------------------------*
% * Directory to save duplicate messages *
% *--------------------------------------------------------------------------*
%
% If you are curious to know where "dupes" are coming from and why,
% you may wish to save them here. However, a word of warning: if
% you get an entire archive repeated, ALL of those messages will be
% stored here as duplicate messages, and this may slow down your
% mail processing substantially as the file count grows!
% Bad_Msgs_Dupes C:\TBBS\BADMSGS\DUPEMSGS
% *--------------------------------------------------------------------------*
% *--------------------------------------------------------------------------*
% * End Configuration File (ADVANCED.CFG added) *
% *--------------------------------------------------------------------------*
% *--------------------------------------------------------------------------*
% *--------------------------------------------------------------------------*
% * Scan mail buffer. The larger the buffer, the faster FLAME *
% *--------------------------------------------------------------------------*
%
% Bigger is better here, but you'll need to be sure you have enough spare
% conventional memory to handle the larger buffer size. Smaller buffers
% will slow down your mail processing somewhat. If FLAME complains about
% insufficient memory, this may require adjustment.
BufferSize Large (128k)
% BufferSize Medium (64k)
% BufferSize Small (32k)
% *--------------------------------------------------------------------------*
% * The type of video writes to use in full screen mode (select one) *
% *--------------------------------------------------------------------------*
%
% On rare occassion, an attempt to write directly to video memory will
% simply not work because the video adapter card in use is using some
% unusual address. In that case, you cannot use "Direct", and should
% try "Bios", letting the calls to your BIOS handle the video. If that
% fails (very rare), then let the calls go to DOS, which should always
% be able to sort things out. These are listed in the order of speed
% of operation, so use "Direct" wherever possible.
Video Direct
% Video Bios
% Video Dos
% *--------------------------------------------------------------------------*
% * Box types for use in full screen mode (select one) *
% *--------------------------------------------------------------------------*
%
% Want to customize the FLAME video a bit? Here's a chance to twiddle it.
% Box_Type 1 ; ┌───────┐
% Box_Type 2 ; ╒═══════╕
% Box_Type 3 ; ╓───────╖
Box_Type 4 ; ╔═══════╗
% Box_Type 5 ; +-------+
% *--------------------------------------------------------------------------*
% * Changes the colors used when operating in full screen mode *
% *--------------------------------------------------------------------------*
%
% Here's a few more chances to get creative. Colors are a combination of
% both foreground and background color. Use the color guide on page
% 2-19 (the documentation on using colors for insertion parameters in the
% Overview chapter of the TBBS 2.2 manual) for specifics. The background
% color is multiplied by 16 and added to the foreground color. Note that
% the manual gives the values in hexidecimal, whereas FLAME uses decimal.
%
% A yellow border (14) added to a black background (0 x 16) = 14.
% Black text (0) added to a white background (7 x 16) = 112.
% White text (7) added to a red background (4 x 16) = 71.
% border text message rev.message
% ---------------- ------ ------ ------ ------
Color_StatusWin 14 23 4 71
Color_SpawnWin 14 3 4 71
Color_HistoryWin 14 112 4 71
Color_StatsWin 14 112 4 71
Color_Header 0 71 0 0
% *--------------------------------------------------------------------------*
% * Control run-time swapping during DOS operations. (default: SWAP AUTO) *
% *--------------------------------------------------------------------------*
%
% As you will inevitably run short on memory during a call to another DOS
% program by FLAME, the current operating environment of FLAME must be
% stored. Where it will be stored is defined here. For the most part, it
% is wise to use AUTO to let FLAME decide whether or not there is
% sufficient memory to swap the FLAME environment to memory, as this is
% faster than swapping it out to disk.
Swap Auto
% Swap EMS
% Swap XMS
% Swap Disk
% *--------------------------------------------------------------------------*
% * Identify the swap file directory and filename used when swapping to DISK *
% *--------------------------------------------------------------------------*
%
% If you specify "Swap Auto" or "Swap Disk", FLAME will need to know
% where to store the FLAME environment when calling another DOS program.
% You can specify both a directory and filename, or just the filename,
% in which case the directory where FLAME was invoked will be used.
Swap_File $$SWAP$$.TMP
% *--------------------------------------------------------------------------*
% * Keep NetMail file attaches after tossing into the TBBS message base as *
% * enclosures. The default action is to delete after importing. *
% *--------------------------------------------------------------------------*
%
% There is generally no reason to keep separate copies of attached files
% if they are attached to TBBS messages as EMnnnnn files in the TBBS
% 'Enclosed' directory. However, if you wish to do so, uncomment this
% line and they will accumulate in your inbound files area.
% TBBS_Toss_Keep_Files
% *--------------------------------------------------------------------------*
% * Selects use of the TBBS internal message number (EM#####) as the file *
% * name for enclosed files scanned to netmail. The default is to use the *
% * enclosed file name provided by the caller. *
% *--------------------------------------------------------------------------*
%
% Given that no one on the other end will be able to make sense of a
% file called EMnnnnn, it is almost always better to leave them with
% the filename the user provides. However, if you think there is some
% reason to do otherwise, you can uncomment this line.
% TBBS_Scan_EM_File
% *--------------------------------------------------------------------------*
% * Mark sent Net Mail messages deleted. *
% *--------------------------------------------------------------------------*
%
% This asks FLAME to set the deletion flag *in your message base* on any
% NetMail that is scanned out of your TBBS message base for transmission to
% the destination node. Normally, such messages are marked for deletion
% either by the sending user or by an automatic "roll-off" utility of one
% sort or another, including FLAME.
% TBBS_Delete_Sent_Netmail
% *--------------------------------------------------------------------------*
% * Disable Userlog.Bbs processing during message import. *
% * Uncomment this parameter to bypass Message Waiting list processing. *
% *--------------------------------------------------------------------------*
%
% In the rare situation where you don't wish to have your users know
% what mail is waiting for them, you can uncomment this line. This
% would provide a marginal improvement in mail tossing speed. However,
% this would be a most unusual situation. As a rule, leave this line
% commented out!
% TBBS_No_Message_Waiting
% *--------------------------------------------------------------------------*
% * Activates and defines a filename to write ASCII text copies of all *
% * messages exported from the TBBS message base, while the second file *
% * is the filename to use for ASCII text copies of messages rolled off *
% * the TBBS messsage base. If you want only the rolloff message log *
% * substitute NUL for the first filename. *
% *--------------------------------------------------------------------------*
%
% TBBS_Ascii_Messages Msgtxt.Log Rolloff.Msg
% TBBS_Ascii_Messages NUL Rolloff.Msg
%
%
% *--------------------------------------------------------------------------*
% * The maximum areas to allow whenever the Areas_Dat file is built. *
% * Maximum: 7000 Default: 1000 *
% *--------------------------------------------------------------------------*
%
% Before you even begin importing and exporting mail with FLAME, it
% builds an empty file for your binary AREAS information (defined in
% the Areas_Dat statement, above). The amount of time that it takes
% to process your mail and the amount of memory required will depend
% in part upon the size of this file, which in turn is determined by
% the number of areas and the number of nodes you define for it (see
% "Maximum_Nodes", below). Therefore, it pays to be realistic. If
% you discover that you are approaching your limits that you had
% previously set, you can always delete your AREAS.DAT file and
% rebuild it (automatically or using FLAME AREASCVT) with larger
% values for these two statements.
% Maximum_Areas 1000
% *--------------------------------------------------------------------------*
% * The maximum unique nodes to allow whenever the Areas_Dat file is built. *
% * Maximum: 8000 Default: 64 *
% *--------------------------------------------------------------------------*
% Maximum_Nodes 64
% *--------------------------------------------------------------------------*
% * An area-by-area log file of areas tossed *
% *--------------------------------------------------------------------------*
%
% This can be a useful troubleshooting tool, and can also be used
% with a FLAME LINK command as the file containing the areas that
% you wish FLAME to link. If you have use for it, uncomment this line.
% Toss_Log C:\TBBS\TEXT\ECHOTOSS.LOG
% *--------------------------------------------------------------------------*
% * Insert ^aMSGID lines on locally written outbound messages *
% *--------------------------------------------------------------------------*
%
% Local_Msgid
%
%
% *--------------------------------------------------------------------------*
% * Put a ^a kludge line before SEEN-BY lines on local .MSG format messages *
% *--------------------------------------------------------------------------*
%
% The operative words above are "local *.MSG messages". Local (not
% imported) *.MSG messages of EchoMail aren't destined for export (but
% rather, for QSO processing). As a result, you can safely keep the SEEN-BY
% information from appearing on many off-line readers by using this option,
% as they will ignore these "kludge lines". Do NOT confuse this with the
% "Hide_Seenby" statement, below!
% Hide_Local_Seenbys
% *--------------------------------------------------------------------------*
% * Put a ^a kludge line before AREA: lines in exported echomail. *
% * Use this only if all receiving system(s) use software that *
% * accepts ^aAREA: lines. *
% *--------------------------------------------------------------------------*
%
% This, on the other hand, is not likely to be of any use to you. Many
% mail processors won't recognize an AREA: tag hiding behind a control-A.
% Use of this option is *not* recommended.
% Hide_Area
% *--------------------------------------------------------------------------*
% * Put a ^a kludge line before SEEN-BY: lines in exported echomail *
% * echomail. Use this only if all receiving system(s) use software that *
% * accepts ^aSEEN-BY: lines. *
% *--------------------------------------------------------------------------*
%
% Disaster waiting to happen. Almost *no* mail processors will see the
% SEEN-BY information hiding behind the control-A, and as a result, many
% duplicate messages will be generated. Do NOT confuse this with the
% "Hide_Local_Seenbys" statement, above.
% Hide_Seenby
% *--------------------------------------------------------------------------*
% * Defines the Circular Path Detection Log file. CPD is always active. The *
% * log file is optional. *
% *--------------------------------------------------------------------------*
%
% An interesting troubleshooting tool, enabling this log will cause FLAME
% to examine PATH lines more closely to see if a message has passed
% through the same system more than once on its way to you.
CPD_Log C:\TBBS\TEXT\CIRCULAR.LOG
% *--------------------------------------------------------------------------*
% * Activates Path Trace logging to a file for all path lines or optionally *
% * only paths exceeding a specified number of addresses. *
% *--------------------------------------------------------------------------*
%
% This option should only be used for troubleshooting, as it requires
% a great deal of disk space and time to generate. Here is a sample
% of the output. The first node number shown was the source of the
% message. The date is the original message date.
%
% AREA:TBBS 1:104/115 [04 Jul 94 08:30:28]
% PATH: 114/257 271 163 124 396/1 3615/50 104/1 104/115 104/114
% Path_Log C:\TBBS\TEXT\Path.Log
% Path_Log C:\TBBS\TEXT\Path.Log 10
% *--------------------------------------------------------------------------*
% * Whether or not to toss echomail messages from the network mail area *
% *--------------------------------------------------------------------------*
%
% You can secure your system a bit more by not permitting *.MSG files
% from your "Mail" directory to be tossed if they are EchoMail. In
% most cases, you should never have such messages anyway, as they will
% have either arrived in *.PKT form or archives in one of the directories
% defined in your "Netfiles" statement.
No_Net_Toss
% *--------------------------------------------------------------------------*
% * Use the Opus v1.00 style binary date in local .Msg format messages. *
% *--------------------------------------------------------------------------*
%
% FidoNet standards demonstrate different forms for dates in *.MSG
% files. Either SEAdog (default) or Opus style date schemes are
% recognized by nearly all software.
% Opus_Date
% *--------------------------------------------------------------------------*
% * Use this if you are merging two or more conferences in the same directory*
% *--------------------------------------------------------------------------*
%
*********************************Finished to Here *********************
%
%
% Conference_Merge
% *--------------------------------------------------------------------------*
% * When to kill compressed mail. After tossing the packets or before *
% *--------------------------------------------------------------------------*
%
% Kill_Compressed_Mail Before tossing pkts
Kill_Compressed_Mail After tossing pkts
% *--------------------------------------------------------------------------*
% * Delete .Msgs in passthrough message areas after scanning. This is used *
% *--------------------------------------------------------------------------*
%
% Delete_Passthrough_Messages
% *--------------------------------------------------------------------------*
% * Defines how to process locally entered private echomail replies *
% *--------------------------------------------------------------------------*
%
% Note: Settings here are global, effecting all echos. Please see
% information on setting up your Areas_BBS file describing how
% sending private echo messages created on your system may be
% allowed or disallowed on an echo-by-echo basis. You should
% also consider controlling this within TBBS itself.
%
% A word of warning here. If for whatever reason you happen to use
% a TBBS "e-mail" style board and echo its messages, be aware that
% all "e-mail" board messages are automatically declared Private, and
% will cease to be exported if you set Private_Echomail to "Ignore".
%
% Setting to "Ignore" will cause FLAME to refuse to scan out any
% message with a TBBS "private" flag set.
%
% Setting to "Send" will tell FLAME to go ahead and scan out the
% message and send it to the nodes defined in Areas_BBS.
%
% Setting it to "Netmail" will cause FLAME to attempt to determine a NetMail
% address for the message and send it by that method. This can be handy if a
% *.MSG has been created by another (non-TBBS) means and it is marked private,
% FLAME tries to figure out the address of the originating system and sends it
% there via NetMail.
% Private_Echomail Ignore
Private_Echomail Send
% Private_Echomail Netmail
% *--------------------------------------------------------------------------*
% * Whether incoming private echomail should be processed *
% *--------------------------------------------------------------------------*
%
% Note: Settings here are global, effecting all echos. Please see
% information on setting up your Areas_BBS file describing how
% tossing private echo messages that are received from other
% systems may be allowed or disallowed on an echo-by-echo basis.
%
% A word of warning here. If for whatever reason you happen to use
% a TBBS "e-mail" style board and echo its messages, be aware that
% all "e-mail" board messages are automatically declared Private, and
% will cease to be imported if you set No_Private_Echomail. In
% addition, some echos permit (I believe ill-advisedly) users to
% reply with private messages in echos. This, by the way, means that
% potentially thousands of systems would sit with mail on their systems
% that none of their users could read. In any case, the typical sysop
% will probably *not* "comment out" this statement.
No_Private_Echomail
% *--------------------------------------------------------------------------*
% * The number of days to wait and the file to send when non-read netmail *
% * is found in the net mail message directory. *
% *--------------------------------------------------------------------------*
%
% Note that this file must be 4096 or less bytes in size.
%
% Also note that this operates ONLY on NetMail messages found *outside*
% of your TBBS message base. Assuming that your TBBS installation
% includes an internal "Net Mail" message area, this feature will be of
% no real value to you. Whether or not this was intended by the author
% was not known at the time of writing.
% Do_Not_Disturb 7 C:\TBBS\Disturb.Txt
% *--------------------------------------------------------------------------*
% * Only create compressed mail with the extention of '.MO?' *
% *--------------------------------------------------------------------------*
%
% First, be sure you have read the information in "TBBS, Tips, Traps and
% Techniques" regarding the naming conventions for mail archives.
% Believe it or not, there may still be someone out there that uses an
% archive unpacker that will not recognize any archive that does not end
% in *.MO?. You should feel free to ask anyone in that situation to join
% us in the 20th century - this old naming convention was dumped in the
% Fido Technical specification FTS-0006 many years ago. Uncommenting
% this line will cause FLAME to generate ONLY that style of archive.
% HOWEVER, this cannot be controlled on a node-by-node basis. It is an
% all or nothing proposition, and it is unlikely that you will wish to
% use it.
% Old_ArcMail_Ext
% *--------------------------------------------------------------------------*
% * Generate compressed mail with extentions ending in both 0-9 (standard) *
% * and A-Z (extended). Some mail processors might not process the extended *
% * compressed archive extensions. *
% *--------------------------------------------------------------------------*
% In fact, most mail processors *won't* approve of this format. These
% are also known as "Base36" archive extensions. Any character from 0-9
% and A-Z can appear in all three of the extension positions. However,
% there are some benefits to using this system -- it prevents any
% possible overwrite of files sent to another system using the same
% name, since a new extension is generated once each minute. But
% because this feature cannot be controlled on a node-by-node basis
% (it is an all or nothing proposition), it is rarely possible to make
% use of it unless you create archives only for systems using programs
% ARCmail to unpack their inbound mail archives.
% 36_Archive_Ext
% *--------------------------------------------------------------------------*
% * Save a copy of all forwarded net mail *
% *--------------------------------------------------------------------------*
%
% If you are curious as to the content of messages that you are
% forwarding for other systems (due to your agreement to do so in your
% ROUTE.CFG file configuration), this will cause copies of these to be
% kept on your system. However, in most cases you will not wish to
% have these accumulating in your "Mail" directory.
% Keep_Forwarded_Mail
% *--------------------------------------------------------------------------*
% * Do Not kill files forwarded after they are sent *
% *--------------------------------------------------------------------------*
% First, you are usually under no obligation to *forward* files that come
% to you with file attach messages. Systems that attempt to do so through
% your system (and you, theirs!) without prior agreement are are showing
% exceptionally bad manners. However, should such files appear (with or
% without agreement) on your system, you may keep copies of them for
% your own use, amusement or simple inspection by removing the "%" on
% this statement. File forwarding is caused by routing a file attach
% message and its corresponding file to a system that is not the
% intended final destination for the message (per the message header
% information) nor the file.
%
% If you leave this line commented out, and agree to forward files per
% the information you supply in your ROUTE.CFG file, then such files
% will be deleted from your system once they have been passed along
% (forwarded) to the destination system.
%
% A note: as of the time of writing, although the above was the
% intended operation of FLAME, it appears that FLAME is always keeping
% forwarded files, even if this line remains commented out.
% Keep_Forwarded_Files
*--------------------------------------------------------------------------*
% * Keep any passing messages that have no content *
*--------------------------------------------------------------------------*
%
% You may at times receive messages that accidently or intentionally
% (as is often the case with File Attach messages) contain nothing in
% the body of the message - just the message header itself. If you
% have some interest in seeing these, you can uncomment this command,
% but they do tend to accumulate in your TBBS NetMail directory. In
% most cases, they can and should be discarded.
% Keep_No_Content
*--------------------------------------------------------------------------*
% * Strip the crash bit on all inbound network mail messages *
*--------------------------------------------------------------------------*
%
% The only time that this will have any effect on mail is if you are
% forwarding NetMail to other systems, since in tossing mail to TBBS,
% neither FLAME nor TBBS really care if this bit is set or not.
%
% If you choose to use this, however, any messages delivered to you
% for forwarding will lose their "crash" flavor, and will default to
% "normal". Of course, you may 'reflavor' them as you like when you
% build packets with FLAME based upon the content of your ROUTE.CFG.
% Strip_Crash
*--------------------------------------------------------------------------*
% * Mark any inbound network mail addressed to your Node, Aka, and PointNet*
% * addresses as sent. This blocks delivery of net mail to your points. *
%
*--------------------------------------------------------------------------*
%
%
% Net_Sent
*--------------------------------------------------------------------------*
% * Delete NetMail .Msgs from the MAIL directory when sent *
%
*--------------------------------------------------------------------------*
%
% This parameter may be necessary if you are using a separate utility
% that creates *.MSG files in your "Mail" directory. If such a utility
% does not set the Kill/Sent flag, the message will not be deleted by
% TIMS after transmission. By using this parameter, FLAME will mark all
% messages in the "Mail" directory with the Kill/Sent flag. FLAME does
% not actually delete such messages, as it has no way of knowing whether
% or not TIMS has been able to send them... it only marks them so that
% TIMS will delete them at the appropriate time.
% Delete_Sent_Netmail
*--------------------------------------------------------------------------*
% * Add an ^AINTL line to all local outbound net mail even if addressed to *
% * your own zone. *
%
*--------------------------------------------------------------------------*
%
%
% This will force the FidoNet "standard" ^AINTL kludge lines on all
% messages being sent by your system. If FLAME finds that either your
% primary address or one of your AKA addresses matches the zone to whom
% the mail is to be sent, no ^AINTL line is added by FLAME unless
% forced to do so by this statement. In the event that FLAME cannot
% find a zone match in your primary address or AKA list, it will
% automatically add the appropriate ^AINTL kludge line, and the
% Force_Intl statement is not necessary.
%
% For most systems, no ^AINTL is needed within the same zone, and this
% statement is not required, and only takes up unnecessary space within
% your messages.
%<Z>
% Force_Intl
*--------------------------------------------------------------------------*
% * Display time in ^aVia lines using local time instead of GMT/UTC time. *
%
*--------------------------------------------------------------------------*
%
% FLAME will use the abbreviation and time for either local time or
% Greenwich Time (now called UTC, thanks to the French, who couldn't
% claim to have invented the town, so found it necessary to ask to have
% it renamed <grin>) when needed to identify times in messages and
% certain kludge lines such as VIA lines in NetMail messages.
%
% However, in order for this work properly, FLAME just get your time
% zone information from your DOS environment. The standard method of
% identifying time zones for MSDOS applications is by using the TZ
% environment variable. This is not mentioned in any of the FLAME
% documentation. If you do NOT set up your TZ variable, FLAME assumes
% by default that you are in the Eastern Time zone (e.g., EDT or EST),
% and will use those abbreviations or the Eastern Time zone offset to
% GMT when it writes messages. However, if the TZ variable is set,
% the information found there is used.
%
% To set your TZ environment variable add the following to your
% AUTOEXEC.BAT file:
%
% SET TZ=sss[+/-]H[H][ddd]
%
% where sss = your standard local time zone abbreviation. In the U.S.,
% this would be PST, MST, CST, or EST.
% where HH = the number of hours between your standard time and
% GMT/UTC. PST is 08 hours from GMT. This can be
% expressed as PST8, PST+8, PST08, or PST+08. Note that
% at least *one* number must always appear in this field,
% and that an unsigned number is assumed to be positive.
% Other examples in the U.S. are MST7, CST6 and EST5.
% Countries that lay to the east of the UK would use
% negative numbers.
% where ddd = your standard abbreviation for daylight time. In the
% U.S., this would be PDT, MDT, CDT or EDT.
%
% If you comment out "local time", FLAME will use the abbreviation
% "GMT" rather than your TZ abbreviations, and will automatically add
% or subtract the necessary number of hours from your system clock time
% to achieve GMT time. If you enable "Local_Time", then FLAME will use
% the appropriate abbreviation if you have supplied in your TZ
% environment variable. In either case, it is necessary to create the
% TZ environment variable to avoid the default of EST5EDT (unless, of
% course, that's where you are!) If your system clock is already set
% to GMT, then you want to use GMT0 for your TZ variable, and it won't
% matter whether or not you comment out Local_Time or not.
% Local_Time
*--------------------------------------------------------------------------*
% * Save a copy of all remapped messages *
%
*--------------------------------------------------------------------------*
%
% If you are curious to see what messages are being remapped due to
% your use of either or both Remap_Name or Remap_Node, copies of these
% will be saved if you uncomment this line. Generally, however, you
% won't want these building up in your "Mail" directory.
% Save_Mapped_Mail