% 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. % 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. % Aka 1:30333/0 Aka 8:7703/4703 % *--------------------------------------------------------------------------* % * The path to your primary network mail area * % * * % * Syntax: Mail [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 [NoToss] * % * NetFile [NoPkt] * % * NetFile [NoArcmail] * % * NetFile [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. % % % 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 % % Options include: % % ALL = (default) log everything % ALLBUT = log everything except noted items (see below) % = 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 * % * * % * 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). % % 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. % % 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:
% % 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. % 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 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. % % 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 ) 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