--------------------------------------------------------------------------
The FLAME Disk, Sample File for AREAS.BBS
for FLAME v. 1.1
Copyright 1994, Chris Anderson
--------------------------------------------------------------------------
The AREASAMP.BBS file provided with your FLAME package is unquestionably
the most completely documented of the several FLAME configuration files.
As such, little information need be added to it to explain how to use the
options. However, the "why" of these options could use a little
clarification, especially for those of you setting up a mail system for
the first time. Those items are included for you here. As this file is
built "from scratch" on your system, no ";" comment markers will even be
included except as they occurred in the original source files from eSoft.
This file should simply act as a reference when reading the AREASAMP.BBS
file and associated information in the FLAME.DOC file.
Note that in some cases, a command appearing after a ";" IS NOT CONSIDERED
TO BE A COMMENT. Therefore, such commands appear behind *two* semicolons
";;" in the eSoft supplied sample files in order to avoid having FLAME
accidently try to process them. If you wish such commands as MODE= and
ORIGIN= commands to be processed, only ONE semicolon can be placed before
them. Use two, and they become comments only!
========================================================================
Confmail Compatibility Origin ! Confmail Compatibility Name
;
; The first line of an Areas.Bbs file usually defines a default origin and
; optional SysOp name separated by an exclamation mark [!]. This program
; does not use this line since Origin and Name information are provided in
; the .CFG/.PRM configure definition files. The line must be present --
; even if blank -- for compatibility with other EchoMail processing
; software. If a message area is defined on the first line the program
; will ignore it.
If you used the old NetMail utilities from eSoft, you will have used the
information above for yet another purpose. When a message was entered
on the BBS system by a user with the *name* SYSOP in the "To:" field,
the old ECHOSCAN program would replace "SYSOP" with your name from the
first line of your AREAS.BBS file as shown above. FLAME, as noted, does
not use this information, but performs the same function. It gets your
name from the "Name" command within the FLAME.CFG file and replaces any
outbound echo message addressed to "SYSOP" with your name.
One of the primary reasons for doing this is to avoid having such
messages them flagged as waiting messages for the SYSOP on many other
systems.
========================================================================
; Message area definitions are defined on one line in three parts...
;
; - The first part is the path. This is an MS-Dos drive:\directory path
; for .Msg files; or a board number or topic path for TBBS. (see below)
; - The second part is the EchoMail conference tag or area name.
; - The third part is a list of Zone:net/node addresses the conference
; is exchanged with.
Note the comment above about a "path" as part of a message area definition.
This is only used if you are using the "alternate" method for storing
messages. Such messages are not stored in your TBBS message base, and may
be accessed by your users only by their use of the QSO (QWK) option module.
Unless you are making use of this technique (often to get beyond the 65534
message limit of the TBBS message base), you will be using the board name,
board number, or topic path with or without board number.
Note especially that zone numbers are not only used in these examples,
but encouraged! Unlike the previous eSoft utilities that were unable
to process zone information in an AREAS file, FLAME uses this information
to pack the mail into the correct OUTBOUND directory for the zone in
question.
<Z>
WARNING: Some users have complained of being unable to process mail from
a second zone or network using another zone UNLESS the echo
areas for the alternate zone are defined FIRST in the AREAS.BBS
file. If you encounter problems where your "other zone" mail is
not being tossed or scanned, you should consider reordering your
AREAS.BBS entries to place the "other zone" entries first, using
the "Origin" and "MyAddress" as necessary to start off the file.
In their most simple form, such entries appear in one of the following
forms. Note that quotes are used where spaces exist in TBBS board names:
Board Name Echo Address of your hub and any to whom
or Number Tag you feed the echo if you are a hub
--------- --------- ------------------------------------
20 TRAVEL 2:255/1 (using board #)
TBBS TBBS 1:104/115 (using board name)
"C ++" C_PLUSPLUS 1:104/115 (quotes are required)
local/fidosysp FIDOSYSP 1:104/115 (using topic board)
25/bbs/tbbs TBBS 1:104/115 (using topic and board #)
Echo Address of your hub and all of those
Tag to whom you feed the echo
--------- --------------------------------------
# TBBS 1:104/115 1:110/18 (a "passthrough" area)
Note the space between the "#" and the echo tag, "TBBS". This is
critical, else FLAME not properly recognize the area tag.
If you are a mail hub for other nodes or points, note the last entry
style. The presence of the "#" indicates that you are hubbing this
echo for some other node or nodes, but have no storage (either in your
TBBS or "alternate" storage areas) for this echo. When it comes in, it
is packed out for your hubees and otherwise kept nowhere on your system.
When you are not retaining a copy of the echo for your own system, this
is referred to as a "passthrough", and the "#" functions as FLAME's way
of being told that an echo is to be treated as a passthrough.
Note that if a board name or topic path begins with a number or numbers
instead of a letter, you should use the board number (or board number
assigned to the topic root) to avoid confusing FLAME about your
intentions.
Because the first address is always considered to be the "feed" for
an echo area, *your* hub for the echo should always be placed first
on the line. You will note that one of the FLAME.CFG configuration
options asks FLAME to notify the "feed" system that it is in fact the
feed for the echo. FLAME *will* assume that the first node should be so
notified if you select this option.
Although using FLAME and QSO's path\*.MSG storage format does make it
possible to make a great many more messages available to your QSO users,
it provides no other benefit other that the possible rescanning of echo
areas stored in *.MSG format with less difficulty than is possible from
the TBBS message base itself.
The penalties for using *.MSG storage format can be substantial in terms
of both processing speed and disk space. Disk space can become a a real
issue for you if you are using large disk drive partitions. The reason
for this is that DOS uses a certain minimum amount of storage for any
file, and this minimum varies with partition size. There are a finite
number of "slots" in the DOS table that keeps track of used and unused
space. The greater the partition size, the greater area each "slot"
references, and the greater space that *any* file, no matter how small,
will occupy on your disk drive. A message file only 500 bytes long may
in fact "use up" 2048 bytes of disk space, not including directory
space, etc.
In addition, if the file count (in this case, message count) in a DOS
subdirectory exceeds about 250 files, your mail processing and QSO
processing will slow down considerably unless you have a substantial
"BUFFERS=" statement in your CONFIG.SYS, or are using a good disk cache.
However, having said all of this, here is the format if you need to use
this method for storing EchoMail messages. Note that you *must* begin
the path with a drive letter, not just a path. Other combinations will
confuse FLAME and may cause it to think that you are trying to identify
a TBBS board.
Path to Echo Address of your hub and any to whom
echo area Tag you feed the echo if you are a hub
--------- --------- ------------------------------------
c:\mail\tbbs TBBS 1:104/115
#c:\bbs\tbbs FIDOSYSP 1:104/115 1:110/18
The second entry show requires some explanation. In the event that you
are not even keeping the message for QSO users, but have (reason?) opted
for external storage while creating and packing mail for other nodes or
points, you can specify this by using the "#" passthrough marker and a
full path to the alternate storage area. It is not a very efficient
means for hubbing mail due to the massive number of file open/close
operations that occur, and is not recommended.
========================================================================
;;MODE = NOWRAP * TBBS: retains message formatting as received
;;MODE = WRAP TBBS: reformats messages to fit the caller's screen
You may well have never noted that there is a flag contained in the
header for each TBBS message that indicates whether or not an imported
message should be displayed "as is" or "wordwrapped" according to the
algorithm shown in the TBBS manual. This option allows you to decide
whether or not that flag is set when messages are tossed to TBBS by
FLAME.
This wordwrap feature can be both a blessing and a curse - which case
depending largely upon your users and the sorts of messages you are
importing to your message base.
Certain message areas cater only to equipment whose screen widths can
safely be assumed to be at least 80 characters, and the vast majority
of messages are entered by such systems as well. Those message areas
where code samples or columnar data is being entered will probably
appear more readable *without* word wrapping because we cannot assume
that the user on the other end understands the TBBS wordwrap algorithm
when typing such things. Therefore, boards for areas such as
programming assistance ('c', 'Pascal', etc.) may need to have their
original message formatting retained, and will work better using NOWRAP.
========================================================================
;;MODE = ORIGIN * TBBS: Import message tear and origin line
;;MODE = NOORIGIN TBBS: Do not import tear and origin line
Don't confuse ";MODE = ORIGIN" with ";ORIGIN" in your AREAS file. The
MODE version of this command is used to decide whether or not the
tear line and origin line from a message will be imported along with the
body of your message when FLAME tosses it into your message base. If
you wish for your users to see such information about the originating
system of messages, leave this enabled. Changing your own origin line
contents on an echo-by-echo basis is done with ";ORIGIN". See below:
========================================================================
; EchoMail origin lines for locally generated messages can be defined
; individually for each area or set/cleared using special comment lines
; beginning with ORIGIN. Origin definitions remain in effect for all areas
; that follow in that Areas_BBS or until another ORIGIN is defined. A
; blank ORIGIN definition cancels a special origin. An ORIGIN= definition
; must be the only definition on a line. Origin definitions can be up to
; 59 characters. It is up to the SysOp to make sure that the total origin
; line length (* Origin: plus this text plus the node address) do not exceed
; the accepted maximum of 79 characters.
;
;;ORIGIN = This space available...
; ...
;;ORIGIN =
; ...
The ";ORIGIN = something" command will override the "Origin" definition
in your FLAME.CFG file until a null ";ORIGIN =" command is given to
cause all such overrides to cease. Some sysops use this option to
provide different information about their systems in different echo
areas. For example, if you support a particular software product or
computer system with your BBS, you may believe that this information
would be useful to people reading certain echos, but not others. As
with the FLAME.CFG origin definition, do *not* add your address to this
information. Your network address is added automatically by FLAME using
either your FLAME.CFG defined address, or MYADDRESS within your AREAS
file (see below). An ORIGIN command should be placed on its own line
in the file.
========================================================================
;;MODE = READWRITE * TBBS: Export locally entered messages to other BBSs
;;MODE = READONLY TBBS: Do not export locally entered messages
An echo that is READ ONLY? Yes, they exist, and you may find yourself
carrying them on your BBS. These are "informational" echos whose
contents are supplied only by certain systems as selected by the echo
moderator. Of course, you can also control write access with CEDIT by
setting high a high priv level or unusual auth flag for an echo, but
FLAME is also capable of universally declaring an echo unavailable for
"write" by simply refusing to export any messages in such areas from
your TBBS message base.
========================================================================
;;MODE = OLDDATE * TBBS: Use the original date on messages imported
;;MODE = NEWDATE TBBS: Use today's date on messages imported
The option here is to allow the date that was created by the originating
system to remain when the message is tossed to TBBS, or to change the
date current system clock date of the machine upon which FLAME is being
run. What's the difference? If you retain the original date, your
users will have a good feel for just how old the message really is, and
can note the actual sequence in which messages were entered around the
world. Due to varying time lags in getting those messages to your
system, messages of various ages will arrive out of sequence at your
system.
The important effect of this option, beyond being able to see the real
date of entry if "OLDDATE" is used, is if you "age" your message base by
date before you roll off "old" messages.
The rolloff functions of FLAME and such other utilities as KILLMAIL and
MFSQZ can be configured to use the dates of messages in deciding which
messages should be discarded from your message base first. So let's say
that a message was delayed for an unusual length of time (a week),
arriving at your system on 7/21, and its date was 7/14. It's age would
already be 7 days, and even though it may arrived *after* messages dated
more recently, it could be deleted before them based upon its date. If
you choose to use age instead of (or in addition to) message count for
your deletion technique, you *may* wish to change message dates to your
system date in order to treat them fairly. Using "NEWDATE" causes their
age to reflect the order in which they arrived at your system, not the
date upon which they were originally written.
Due to the confusion to users that can be created by use of "NEWDATE"
and 'unfairness' of "OLDDATE", and for other reasons as well, many
sysops prefer message count alone for rolloff. Note additional
information on this decision in the "ROLLOFFDAYS" and "ROLLOFFCOUNT"
commands as described next in this document.
========================================================================
Note that at the time of writing (FLAME version 1.1), FLAME would begin
to delete your ROLLOFF entries, one at a time, during each export of
your AREAS.DAT file if the *first* entry was for 0 count / 0 days. It
is expected that this bug will be fixed in a future release. The best
workaround is to order your AREAS file(s) such that the first ROLLOFF
entry is non-zero.
;;MODE = ROLLOFFCOUNT#### Default is 0, which means "don't do it!"
;;MODE = ROLLOFFDAYS#### Default is 0, which means "don't do it!"
As noted above, either or both of these techniques can be used to
control the growth of your message base. The obvious question is, why
not just use these same facilities as are provided in the configuration
section of the MFSQZ program?
Topics. When MSFQZ rolls off messages from Topic areas, it treats all
of the subtopics within a topic root equally. It is not possible to use
MFSQZ to roll off using different ages or counts within a topic root.
As a result, sysops have had to make some peculiar groupings of topics
within roots (that often don't really belong together except for the
volume of traffic they produce), or watch as heavily trafficed echos get
rolled off much more quickly than their slower traffic counterparts.
FLAME permits rolloff of "old" messages on a topic by topic basis within
each topic root. In fact, this was one of the features so universally
requested by TBBS sysops at the ONEBBSCON in 1993 (before FLAME was
released) that it is said to have been in part responsible for FLAME's
belated introduction.
Which to use? Or both? As explained in the section above on OLDDATE
and NEWDATE, problems exist in any attempt to use date to decide which
echo messages should be deleted from the message base first during your
use of MFSQZ. As well, the number of messages that could occur within a
given period of time can be somewhat unpredictable, and the size of your
message base can grow and shrink substantially as a result, making
planning of disk space a bit of a problem, and may even cause you to
reach your CEDIT (or FLAME.CFG) defined maximum message count limit
unexpectedly.
However, you may find that other areas (such as EMail style board areas)
are better suited to rolloff by date. EMail boards? Yes, that and all
of your other "local" (non-echo) message areas can also be "rolled off"
by using FLAME. It's just a matter of entering the board numbers or
board names as dummy echos without any node numbers. To remind yourself
of what you have done, you may wish to use a "dummy" echo name as shown
in this example. If you had three local (non-echo) boards whose numbers
were 23, 24 and 25 as defined in CEDIT, then the following might be
appropriate for you:
;MODE=ROLLOFFCOUNT100
23 DUMMYECHO1
24 DUMMYECHO2
25 DUMMYECHO3
The primary advantage of using ROLLOFFCOUNT instead of ROLLOFFDAYS for
most of your areas is that you can predict with some precision the
message count of your message base after each MFSQZ operation. However,
don't forget that users who "Cubbyhole" messages will likely always add
to the total count.
========================================================================
;MODE = LINK * TBBS: Message reply chain linking ok when requested
;MODE = NOLINK TBBS: Message reply chain linking bypassed
Most users prefer to be able to read message "threads", following along
with a discussion of a particular subject in the sequence in which
messages were received by your BBS. The method used to accomplish this
is a series of pointers within the message headers in your MSGHDR.BBS
file. Generally, as users prefer this, and since this benefit of a FLAME
LINK is usually considered well worth the time it takes to perform the
linking process, most sysops will want FLAME to link all echo message
areas.
========================================================================
;; MODE = NOPRIVATE
;; MODE = PRIVATEOK <- default
"Private_Echomail" in FLAME.CFG can be used to decide whether or not (or
how) EchoMail messages marked "private" by your BBS should be exported,
and "No_Private_Echomail" can be used to decide whether or not FLAME
will toss such messages to your BBS if they are received. However,
these operate "globally" on all messages. If you wish to control this
on an echo-by-echo basis, it can be done here within your AREAS file.
Please read the information in FLAME.CFG about the use of private flags
on EchoMail, as it may well effect your decision.
========================================================================
; EchoMail is sometimes maintained for different and often unrelated network
; addresses. In that case it may be necessary to present different addresses
; for different message areas. Use the MYADDRESS parameter to set the address
; to present in MSGID, ORIGIN, PATH lines for messages exported. Use
; the EchoMail ZONEGATE facility to control SEEN-BY content.
;<Z>
;
;; MODE = MYADDRESS 36:120/0
;; MODE = MYADDRESS 1:13/13
;; MODE = MYADDRESS off <- ends address override
As will have noted in our FLAME.CFG document, although FLAME will use a
better matching AKA address (if you provide them) for some purposes, it
does not automatically use a better matching AKA address in your origin,
MSGID or PATH lines - these are set to your primary address (defined in
your FLAME.CFG "Node" statement) unless you change that operation here,
and it can be done here on an echo-by-echo basis.
Hence, if you hold more than one address in your network, or addresses
in multiple Fidonet zones (unlikely) or addresses in two or more Fido
technology networks using different zone numbers (a very common
situation these days), you will probably wish to reflect that here. If
you happen to be in the rare case of operating as a Zone Gateway system
yourself (transferring echo mail between two zones), you will have to
decide which of your addresses you prefer to have on such messages. In
most cases, however, you will only be sending EchoMail for a particular
echo within a particular zone, and you should display your address for
that zone for the echo. This permits users and sysops at other locations
to see your address in their zone, and therefore to send you NetMail
messages easily. You should avoid using the wrong (other zone) address
in your origin lines, since other systems may well NOT have a nodelist
available for zones in which they do not directly participate.
========================================================================
;; MODE=LEVEL<level>
; NOTE: There is no space allowed between the keyword LEVEL and
; the actual level number; e.g., LEVEL250 is allowed, whereas
; LEVEL 250 is not.
;; LOCK=<lock>
; IMPORTANT: THIS COMMAND MUST BE ON ITS OWN LINE IN THE AREAS FILE.
;; MODE = NOPURGE <- default
;; MODE = PURGEOK
These three commands are only useful if you are hubbing mail for other
nodes or points. However, if you are acting as a hub, and wish to
provide "AREAFIX" ability to some or all of these nodes, you may need to
control access to all or some of your available echo areas. The LEVEL
and KEY assignments you make for each echo in your AREAS file(s) are
matched against that for a requesting node in the "Flame_Password"
commands in your FLAME.CFG file. In order for a node or point to
automatically request a new echo area from your system, the level for
that node as assigned in "Flame_Password" must be greater than or equal
to the LEVEL you set on the echo here in this file, and the node's list
of KEYs as assigned in "Flame_Password" must contain at least all of the
letters in the KEY you set on the echo here in this file.
A node with a level of 50 in "Flame_Password" cannot AREAFIX an echo
from you where you have assigned the echo a LEVEL of 100. A node whose
keys are AB cannot AREAFIX an echo from you whose KEY string is ABC or
DEF. However, if the KEY string for the echo is simply A, this is
covered by one of the node's keys (AB).
Why all of this lock and key business?
First, as a matter of security and network management, you must control
the list of nodes that are permitted to use your system as a source for
their EchoMail. In addition, passage of EchoMail between networks or
zones (the function of a Zone Gate) may be limited to certain selected
nodes, and you may need to avoid passing EchoMail to systems of other
zones or networks, while permitting them to obtain mail from you for
those echos within a common zone. Here are some purely hypothetical
but useful examples:
1) Avoiding Accidental Multiple Feeds
You and another system both hold addresses in Zone 1 FidoNet and
Zone 8 Familynet. However, you act as a hub for the other system only
for FidoNet EchoMail. The other system has a different hub for his
FamilyNet mail. To avoid accidental "dupe loops", you are not
permitted to feed the other system FamilyNet echos in addition to his
regular source for such mail. You would wish to avoid his accidently
requesting and receiving such echos from you by refusing access to his
address by means of LOCK and key or LEVEL commands, while permitting
continued ability to request FidoNet echos by being sure his LOCK and
LEVEL access makes FidoNet echos available for AREAFIX purposes.
<Z>
2) Avoiding Accidental Zone Gate Operation
You hold addresses in Both Zone 1 FidoNet and Zone 8 Familynet. You
may or may not hub in both networks, but you hub in at least one of
them. Some rule may exist that limits the cross-over of EchoMail
between the networks to certain specified ZoneGate systems. As a
result, you would not be permitted to pass Zone 1 mail to Zone 8
systems, nor Zone 8 mail to Zone 1 systems. To keep the nodes for
whom you hub from requesting mail from the other network (zone), you
can prohibit this by use of LOCK and/or LEVEL access.
<Z>
3) Avoiding Feeding Restricted Echos
Some echos are restricted in their distribution per the policy of the
echo moderator. One reason for such restrictions may include the need
for prior agreement to some policy statement by a receiving system
before the feed can be begun. By using LOCK and/or LEVEL commands,
you can prohibit any system from AREAFIXing certain echo areas from
you until you have specifically allowed this by adding the necessary
key or level in their "Flame_Password" entry.
This sort of restriction might also be used for an echo area that is
used only for a restricted group of people. For example, a group of
people beta testing some software might wish to create a "private"
echo for sharing their information, and other nodes should not be
permitted to AREAFIX this area.
The NOPURGE and PURGEOK option allows you to ask FLAME to make a
decision about what to do with echos listed in your AREAS file in the
event that all of the nodes who were receiving an echo from you delete
their feeds via AREAFIX.
The following will occur if you specify PURGEOK for a particular echo
area:
If all of your downstream nodes delete themselves from an echo in your
AREAS file by AREAFIX, leaving only one node (assumed to be your hub,
who should always be the FIRST entry in any of your AREAS files) the
entry is removed from your AREAS file (and when next compiled, your
AREAS.DAT file). An AREAFIX message will also be sent to your own hub
to turn off the unneeded area.
However, the file that you may have defined for duplicate message
detection (Dupe_History_File in FLAME.CFG) still retains entries for all
messages in the deleted area. Therefore, you may also want to manually
get rid of the unneeded entries in your Dupe_History_File by asking
FLAME to "FLAME DUPES DELETE ..." the area in question.
NOPURGE turns that function off for any subsequent echo areas or until
you specify PURGEOK again for an echo.