Category : BBS Programs+Doors
Archive   : MSGTOS2C.ZIP
Filename : MSGBBS.DOC

MSGTOSS Version 2.0

High-Performance FidoNet Mail Processor for RBBS-PC

Copyright(c) 1989-92, Mike Zakharoff & Warren Muldrow

Mike : FidoNet 1:138/154 Rbbsnet 8:918/10
Warren: FidoNet 1:3617/1 Rbbsnet 8:928/1


ALL RIGHTS RESERVED


R E F E R E N C E M A N U A L

for

MSGTOSS.BBS


Written by Mike Zakharoff


The MSGTOSS.BBS file is similar to the standard "AREAS.BBS" file that other
mail processors (CONFMAIL, QMAIL, RBBSMAIL, AREAFIX) use. Beginning with
version 2.0 of MSGTOSS, the MSGTOSS.BBS file needs to contain conference
specific keywords that affect what MSGTOSS does when a message is being
tossed into an RBBS and/or Fido-style area.

For description purposes, these are referred to as "key words", in this and
other MSGTOSS documents.


DISCLAIMER
----------
The authors make no claims or warranties with respect to the contents or
accuracy of this publication, or the product it describes, including any
warranties of fitness or merchantability for a particular purpose. Any
stated or expressed warranties are in lieu of all obligations or
liability for any damages, whether special, indirect, or consequential,
arising out of or in connection with the use of this publication or
the product it describes. Furthermore, the right is reserved to make any
changes to this publication without obligation to notify any person
of such changes.









MSGTOSS.BBS Reference Manual


L I C E N S E
-------------

MSGTOSS is not a Public Domain program and is not free. MSGTOSS is
copyright(c) 1989,1990,1991,1992 by Mike Zakharoff and Warren Muldrow.
Non-registered users of this program are granted a two week license to
evaluate the program suitability for their requirements. Any usage of
Msgtoss beyond evaluation time period requires registration. Use of non-
registered copies of Msgtoss beyond the original evaluation period is not
wished. You are free to distribute the PUBLICLY AVAILABLE shareware version
of MSGTOSS.

MSGTOSS is SHAREWARE. MSGTOSS was not an easy project, as it took 1000's
of hours to develop and test. The author has written other RBBS utilities
such as MSGRENUM, MAILWAIT, MSGECHO, FIXMSG, all of which were released as
freeware; none of which compares to the complexity of MSGTOSS. Fu-
ture releases of MSGTOSS will depend upon how much support the author re-
ceives. Therefore the author is asking for $25.00 for its use to:

MIKE ZAKHAROFF
18004 22ND ST CT E
SUMNER, WA 98390

Keep in mind that the authors could have easily crippled MSGTOSS with all
sorts of schemes, including disabling the multi-tasking/network support,
requiring a password, annoying "not-registered" lines appended to the tear
line, beg screens, long delays, and other things to pester you to support
the authors. If I were to figure out the amount of hours it took to devel-
op and test this program, it would easily run into 10,000 hours of personal
time that really can't be assigned any value. This was a service to the
RBBS-PC community, and its development will set the stage for RBBS-PC's fu-
ture in the Fidonet comminity. Cards and letters always welcome!

Registered users will receive a personal registration code (See REGCODE in
MSGCFG.DOC), and as much personal support as possible. Non-supporters
will basically be doomed to slither in their own guilt for all eternity.


WARRANTIES
----------

MSGTOSS is guaranteed only to occupy space on your hard drive. Therefore
the use of MSGTOSS is solely at your own risk! MSGTOSS had been beta
tested extensively to eliminate bugs, however due to the limitless pos-
sibilities of system configurations, no warranty is possible. Also,
there are no guarantees that the author will upgrade MSGTOSS.


TRADEMARKS
----------

The following products are mentioned in this document:

Areafix,Confmail,Qmail,RBBS-PC & RbbsMail



Page - 2





MSGTOSS.BBS Reference Manual


TABLE OF CONTENTS
-----------------

Page

MSGTOSS.BBS keywords ................................... 4
Keyword List ........................................ 4

MSGTOSS.BBS Sections ................................... 6
Default Origin Line ................................. 6
RBBS (M.DEF) Areas .................................. 7
FIDO (#.MSG) Areas .................................. 7
Area Name ........................................... 8
Nodes Listing ....................................... 8

Sample MSGTOSS.BBS File ................................ 10

Special Areas .......................................... 12
AREA:NETMAIL ........................................ 12
AREA:UNKNOWN ........................................ 13
AREA:MSGCAPTURE ..................................... 13
AREA:ROUTETHRU ...................................... 13

Passthru Areas ......................................... 14

NBBS:file .. Chain to the next BBS file ................ 15
RECS:xxxx .. No. of records in RBBS message base(s) .... 16
RNIF:xxxx .. Re-number msg only if last exceed xxxx .... 18
RNST:xxxx .. Re-number msg bases starting with xxxx .... 19
ESEC:xxxx .. Security level of tossed messages set to .. 20
NODE:xxxx .. The "home" NODE address for the echo ...... 21
MAXL:xxxx .. Max lines before MSGTOSS auto-breaks msg .. 23
SLAK:xxxx .. Min free messages if overflow condition ... 24
MRGN:xx .... Format right margin of RBBS messages to ... 25
PRIV:x ..... Whether to honor PRIVATE ECHOMAIL msgs .... 26
FMAS:x ..... Force Msgs to M.DEFs as Already Scanned ... 27
SECL:x ..... Strip Echo Control Lines (Only FMAS:1) .... 28
USRH:x ..... Hash USERS to keep msgs while purging ..... 29
CAPT:x ..... Capture messages with special text ........ 30
CDUP:x ..... Enable Duplicate Checking for AREA ........ 31
MWST:x ..... Set Mailwaiting Bits for new RBBS msgs .... 32
HIST:x ..... Maintain a history file of purged messages. 33
GATE:x ..... Zone/Domain gating option ................. 34
ORGN:text .. Origin: line to be used for scanning ...... 35

INDEX (See MSGIDX.DOC).................................. <-











Page - 3





MSGTOSS.BBS Reference Manual


MSGTOSS.BBS keywords
--------------------

The MSGTOSS.BBS file is similar to the standard "AREAS.BBS" file that
other mail processors (CONFMAIL, QMAIL, RBBSMAIL, AREAFIX) use. In
fact, it should be fully compatible with all of them. This allows the
sysop to maintain just one AREAS.BBS file which all other mail pro-
cessors can share.

Historically, the AREAS.BBS (MSGTOSS.BBS) file contained the Fido
SUB-DIRECTORY where the conference resided, the official FIDONET NAME
of the conference, and the NET/NODES of other systems who are on dis-
tribution of the conference (all on one line). However, MSGTOSS re-
quires special entries in the MSGTOSS.BBS file which deviate from this
standard format, but should not affect other mail processors.

Beginning with version 2.0 of MSGTOSS, the MSGTOSS.BBS file needs to
contain 'conference specific' keywords that affect what MSGTOSS does
when a message is being tossed into (or scanned from) a specific con-
ference. Here is a summary of the MSGTOSS.BBS "key words", as they
will be referred to in this and other MSGTOSS documents.


KEYWORD LIST
------------
Logically 'Chain' to the next BBS file ---> NBBS:[path]Filename.ext
No. of records in RBBS message base(s) ---> RECS:xxxx
Re-number msg only if last exceed xxxx ---> RNIF:xxxx
Re-number msg bases starting with xxxx ---> RNST:xxxx
Security level tossed msgs set to xxxx ---> ESEC:xxxx
The "home" NODE address for the echo -----> NODE:xxxx
Max Lines before MsgToss auto-breaks msg -> MAXL:xxxx
Minimum number of 'free' message slots ---> SLAK:xxxx
Format right margin of RBBS messages to --> MRGN:xx (30 thru 79)
Whether to honor PRIVATE echomail --------> PRIV:x (1=yes 0=no)
Force Msgs to M.DEFs as Already Scanned --> FMAS:x (1=yes 0=no)
Strip Echo Control Lines (Only FMAS:1) ---> SECL:x (1=yes 0=no)
Hash USERS to keep msgs while purging ----> USRH:x (1=yes 0=no)
Capture messages with special text -------> CAPT:x (1=yes 0=no)
Enable Duplicate Checking for AREA -------> CDUP:x (1=yes 0=no)
Set Mailwaiting Bits for new RBBS msgs ---> MWST:x (1=yes 0=no)
Maintain history file of purged messages -> HIST:x (1=yes 0=no)
Zone & Domain Separation (1=none 2=full) -> GATE:x (1 or 2)
Origin: line to be used for scanning -----> ORGN:text (last entry)

NOTE: Some of these Keywords are quite critical and should be
throughly understood PRIOR to attempting MSGTOSS.BBS
configuration. The most critical Keywords are as follows:

NODE:xxxx RECS:xxxx, ESEC:xxxx, GATE:xxxx, FMAS:x, SECL:x, USRH:x

*************************** WARNING! ****************************
* Read the documentation on the above critical Keywords PRIOR *
* to configuring the default Keywords in the MSGTOSS.BBS file. *
* Setting them incorrect will throughly screw things up!! *
*****************************************************************

Page - 4





MSGTOSS.BBS Reference Manual


These keywords are placed on a line PRECEDING the affected RBBS or
Fido-style conference. If the FIRST character of a line
in the MSGTOSS.BBS is a "-" (dash) then MSGTOSS will consider that
line a keyword line and attempt to parse it to obtain conference-
specific (or global) keywords. Note that mail tossers such as
CONFMAIL & RBBSMAIL will (should) politely ignore these "-" lines.

Non-Keywords that happen to be present on Keyword lines will be
ignored, allowing comments or other mail processors who use a sim-
ilar scheme (like MREN) to also use these lines.

All of these keywords are "global" until changed. For example, if
"MRGN:77" is entered at the top of the MSGTOSS.BBS file, then all
subsequent conferences will be formatted with a right margin of
77. If however, you want a particular conference to be formatted
with a right margin of 39 (maybe for 40 column machines like
Commodore 64's) then an entry such as "-MRGN:39" should be placed
on a line just PRIOR to the affected conference.

Example:

-MRGN:39
C:\RBBS\COMOM.DEF COMMODORE_64 1:343/300
-MRGN:77

Notice that these keywords begin with a "-". All of these key-
words apply to ALL SUBSEQUENT conferences, until you change them.
For instance. If you want the MAIN message base to NOT be hashed
for users during a purge, simply add the keyword "-USRH:0" just
before the line entry for C:\RBBS\MESSAGES.

Example:

-USRH:0
C:\RBBS\MESSAGES NETMAIL
-USRH:1

Remember, for all SUBSEQUENT conferences the "-USRH:0" will apply,
so if you want it for ONLY the main message base, then turn it
back on immediately after the C:\RBBS\MESSAGES line with another
"-USRH:1" entry!

Unless any of these are changed by either a single keyword entry
on a single line, such as:

-RECS:2000

Or multiple entries on a single line:

-RECS:3000 MAXL:99 RNIF:1

They remain in effect for all subsequent conferences until they
are changed.

-----------------------------------------------------------------------


Page - 5





MSGTOSS.BBS Reference Manual


MSGTOSS.BBS SECTIONS
--------------------

The MSGTOSS.BBS is made up of 5 sections, the DEFAULT ORIGIN LINE, the
MESSAGE BASE (or FIDO DIRECTORY), the official domain AREA NAME, and
the NET/NODE listing. As stated earlier, the MSGTOSS.BBS file should
be compatible with other mail processors.

Lines beginning with:

"-" are MSGTOSS keyword lines (comments to other mail processors)
";" are comments, and will be ignored
"#" is a PASSTHRU Area
" " (spaces) will be stripped of leading spaces, then processed.
"" (blank) are ignored

For instance, PASSTHRU areas (Qmail Style) are supported by MSGTOSS,
and usually have the following appearance in a Qmail AREAS.BBS

#C:\MAIL\RBBS RBBS-PC 343/300
C:\MAIL\COMM COMM 343/36

The leading space will be stripped in the second entry by MSGTOSS,
leaving the lined-up appearance of the PATHS for easy editing.

The CASE of the entries is of no concern as MSGTOSS will store all data
in memory as upper case.


DEFAULT ORIGIN LINE
-------------------
The FIRST un-commented line in MSGTOSS.BBS is always the default
Origin: line.

Example:

INTERSTATE BBS NETWORK - Seattle, WA ! Mike Zakharoff

The "!", followed by the sysops name is optional, MSGTOSS does not
require this, as it gets the sysop name from the FIRST SYSNAME---
--> entry in the MSGTOSS.CFG file when used for exporting mes-
sages.

See SYSNAME-----> in MSGCFG.REF for more information on this.

The Length of the Origin line matters, as MSGTOSS will attempt to
tell you that your Origin line is too long when doing a "/TEST"
during system set-up. Along with ZONE:NET/NODE, the Origin line
should be less than 79 characters.

NOTE: Special origin lines can be configured via the ORGN:text
keyword.





Page - 6





MSGTOSS.BBS Reference Manual



RBBS (M.DEF) AREAS
-------------------
The RBBS message base (or Fido-style directory) is the first item
entered on a normal conference line in MSGTOSS.BBS.

All of the RBBS conferences MUST contain an 'M.DEF' to be recog-
nized, and MUST have a matching 'U.DEF' users file in the same di-
rectory. The exception here is that if you use the message file
"MESSAGES", MSGTOSS will assume a user file called "USERS" in the
same directory.

Example:

-RECS:1000
C:\RBBS\RBBSM.DEF RBBS-PC 1:343/300

Would assume a matching user file in C:\RBBS\ called RBBSU.DEF.

All RBBS Conferences require a "-RECS:xxxx" value to apply where
the xxxx is the size in (128 byte) RECORDS of that message base.
The xxxx will be the size the message base is CHOPPED back down
(or INCREASED) to when using the '/SIZE' or '/SIZE-UP' switches,
respectively.

NOTE: Read documentation on RECS:xxxx for more information on
this.

NOTE: Executing "MSGTOSS /STAT" provides message base statistics
for all RBBS message bases. This includes the current sizes
(in RECS:xxx) that may be used for easy settings.

In the above example, the "RECS:1000" entry indicates that
RBBSM.DEF contains 1000 records.

NOTE: Actual size (in bytes) of the message bases is (xxxx * 128)

Although the above example has a RECS:xxxx keyword line immediate-
ly preceding it, this is usually not necessary, as a previously
defined RECS:xxxx keyword is probably already active. These are
only required when its desirable for the RECS:xxxx value to
change. For instance, the following example, although it would
work properly, is considered un-professional (heaven forbid), and
would slow down initialization:

-RECS:1000
C:\RBBS\COMMM.DEF COMM 1:343/300
-RECS:1000
C:\RBBS\RBBSM.DEF RBBS-PC 1:343/300
-RECS:1000
C:\RBBS\4SALEM.DEF 4SALE 1:343/300
-RECS:1000
C:\RBBS\COOKM.DEF COOKING 1:343/300

NOTE: When you execute a /STAT or /TEST major command line switch,
MSGTOSS will loudly complain if these RECS:xxx entries are

Page - 7





MSGTOSS.BBS Reference Manual

incorrect. You can then correct them. For more informa-
tion, see /TEST & /STAT in MSGSWI.DOC, and INSTALLATION
'Test System Setup' in MSGTOSS.DOC.

TIP: Place all similar sized RBBS message bases together, so you
can have just one "-RECS:xxx" entry that will apply for them.

NOTE: The old "|R999|" (in pre-version 2.0) will not work.
Configure these on a preceding line as "-RECS:999"


FIDO (#.MSG) AREAS
------------------
If the conference line doesn't contain either "MESSAGES" or
"M.DEF", it is automatically considered to be a FIDO-style area,
and MSGTOSS will attempt to verify its existence. It is important
to know that MSGTOSS requires that EACH Fido subdirectory must be
unique! MSGTOSS will not allow intermixing of Fido Areas,
and will abort with an error.

You CAN have BOTH an RBBS conference (as above) AND a FIDO style
conference for the SAME AREA.

Example:

You want to post the RBBS-PC conference for users AND have them
tossed into Fido Style also, where you could use an editor (such
as MSGED) for your own personal use.

C:\RBBS\commm.def COMM 1:343/300
C:\MAIL\COMM\ COMM (no Net/Nodes listed on second item)

NOTE: MSGTOSS 2.0+ provides a notable feature called "mirror-
scanning", where if you have a double-tossed area (as noted
above), then if a user entered a message in the RBBS confer-
ence, when exported, will also create a "carbon copy", com-
plete with Origin: line, in the Fido-Style directory as
well. The same applies to when a user (or yourself) enters
a message in a Fido-Style conference, when exported, will
create a carbon copy in the RBBS message base.

Don't go crazy with simultaneous (RBBS + FIDO) conferences, they
will drastically slow down tossing. Tossing is optimized for
tossing into RBBS conferences, and this feature is provided simply
for convenience.


AREA NAME
---------
The entry following the RBBS message base is the official AREA
name, as defined by your favorite domain (Fidonet, Rbbs-Net, Egg-
Net). Nothing fancy here, case does not matter.

NOTE: MSGTOSS has hard-coded special area names. See section on
"Special Areas" in this document



Page - 8





MSGTOSS.BBS Reference Manual

NODES LISTING
-------------
The Nodes listed to the right are those which you are either FEED-
ING (if you are a HUB) or your HUB that you exchange mail with.
If you are using MSGTOSS to FEED your nodes (You are either a HUB
--or-- you service points) then you use the /FEED switch during a
toss.

For the LIST of net/nodes, the following apply:

1) The ZONE and DOMAIN are the same as the "NODE----->"
entry (MSGTOSS.CFG) that corresponds to the NODE:x BBS
keyword.

2) You can change the ZONE entry on this line, and ...

3) You can add "@domain" on the line also.


Example:

1:343/300 36 666/1 2 3
1:343/300@fidonet 301 302 8:8/1@rbbs-net 4 5 918/10 20
343/300 36 37 38
918/1 2 3

NOTE: If the Zone is omitted from the list of nodes, MSGTOSS will
figure it out from its own nodelist.

NOTE: The FIRST unique AREA: entry determines the NET/NODES
that are fed or exported.

Example:

C:\RBBS\commm.def COMM 1:343/300
C:\MAIL\COMM\ COMM 1:343/300 301 555/666 4 5
^^^^^^^^^^^^^^^^^^^^^^^^^
second nodelist Ignored!

Note that the FIRST sequential entry (only) counts, so if
you append new NET/NODE information to the second entry, it
will be ignored! This ONLY applies to "double tossed" ar-
eas (as the above example) where the same AREA is being
tossed to both #.MSG and M.DEF format.

-----------------------------------------------------------------------












Page - 9





MSGTOSS.BBS Reference Manual


SAMPLE MSGTOSS.BBS FILE
-----------------------

INTERSTATE BBS Seattle WA ! Mike Zakharoff
;
; Default keyword entries
;
-RECS:1000 RNST:1 RNIF:1 ESEC:5 MAXL:100
-SLAK:10 MRGN:77 FMAS:1 SECL:1 USRH:1 HIST:0
-CAPT:0 NODE:1 GATE:2 PRIV:0 CDUP:0 MWST:1
;
; NOTE: Some of these Keywords are quite critical and should be
; throughly understood PRIOR to attempting MSGTOSS.BBS
; configuration. The most critical Keywords are as follows:
;
; NODE:x RECS:xxxx ESEC:xxxx GATE:xxxx FMAS:x SECL:x USRH:x
;
; *************************** WARNING! ****************************
; * Read the documentation on the above critical Keywords PRIOR *
; * to configuring the default Keywords in the MSGTOSS.BBS file. *
; * Setting them incorrect will throughly screw things up!! *
; *****************************************************************
;
; Note the NODE:1 entry! This indicates that the following
; conferences are associated with your FIRST "NODE-------->"
; address in your MSGTOSS.CFG file. NODE:2 would mean the
; SECOND NODE--------> entry, NODE:3 means THIRD.
;
; Turn off USER hashing for the main message base (USRH:0), as
; there are too many users for MSGTOSS to efficiently purge as
; required (its unnecessary). Turn it back on after (USRH:1)
; for the rest of the small conferences.
;
-USRH:0
C:\RBBS\MESSAGES NETMAIL
-RECS:800 USRH:1
;
; All subsequent conferences are 800 records (RECS:800).
; Naturally, you will have to adjust these to match your system.
;
C:\RBBS\commm.def COMM 1:343/300
C:\RBBS\consultm.def CONSULTING 1:343/300
C:\RBBS\cookingm.def COOKING 1:343/300
C:\RBBS\c_prgmm.def C_ECHO 1:343/300
C:\RBBS\feminm.def FEMINISM 1:343/300
C:\RBBS\forsalem.def 4SALE 1:343/300
;
; Special Origin line to apply ONLY to the NEXT sequential message base
;
-ORGN:MSGTOSS - Accept no substitutes!
C:\RBBS\rbbsm.def RBBS-PC 1:343/300
;
; Default Origin line takes over
;
C:\RBBS\techm.def TECH 1:343/300
C:\RBBS\warningm.def WARNINGS 1:343/300

Page - 10





MSGTOSS.BBS Reference Manual

;
; Qmail-Style PASSTHRU areas are also supported, these have the
; following format:
;
; #[Optional Path] PASSAREA 1:343/300 301 301 666/1 2 3
;
; Note that the FIRST character must be a "#", followed by the AREA:
; name, followed by the list of NET/NODES. Note that the NET/NODES
; will ONLY be "fed" if you are using the "/FEED" switch. Note that
; QMAIL requires a Fido Path to follow the "#", and this CAN be listed,
; but MSGTOSS will ignore the path.
;
; The areas NETMAIL & UNKNOWN are required.
; The areas ROUTETHRU & MSGCAPTURE are optional
; For each unique domain/zone, separate areas are required
; The extensions of ".001" & ".008" (meaning Zone 1 & 8)
; are for illustrative purposes only and are not necessary.
;
C:\MAIL\NETMAIL.001\ NETMAIL
C:\MAIL\UNKNOWN.001\ UNKNOWN
; C:\MAIL\ROUTEIT.001\ ROUTETHRU
; C:\MAIL\CAPTURE.001\ MSGCAPTURE
;
C:\MAIL\NET343\ NET343 1:343/300
C:\MAIL\RBBS.001\ RBBS-PC 1:343/300
C:\MAIL\LAN\ LAN 1:343/300
;
; The -NODE:2 entry signifies the SECOND NODE--------> entry in
; the MSGTOSS.CFG file. This keyword separates the MSGTOSS.BBS
; file into Domains/Zones. -NODE:3 would mean the THIRD
; NODE--------> entry (if exist).
;
;
-NODE:2 (The second AKA is RBBS-NET!)
C:\MAIL\NETMAIL.008\ NETMAIL
C:\MAIL\UNKNOWN.008\ UNKNOWN
; C:\MAIL\ROUTEIT.008\ ROUTETHRU
; C:\MAIL\CAPTURE.008\ MSGCAPTURE
;
C:\MAIL\MSGTOSS\ RBBS_MSGTOSS 8:918/1
C:\MAIL\MSGBETA\ MSGBETA 8:918/1
C:\MAIL\RBBS.008\ RBBS-PC 8:918/1
;
; Having two RBBS-PC conferences is not a misprint. What separates
; them is the NODE:2 keyword, meaning the second RBBS-PC conference
; belongs to RBBS-NET (Zone 8).

-----------------------------------------------------------------------










Page - 11





MSGTOSS.BBS Reference Manual


SPECIAL AREAS
-------------

MSGTOSS has hard-coded AREAS with special names, these are:

NETMAIL - Where non-echomail (Netmail) is tossed
UNKNOWN - Where unidentified echomail is tossed
ROUTETHRU - Where Netmail (not addressed to your AKAs) are tossed
MSGCAPTURE - Where "captured" echomail is tossed

For all of the above, separate directories must be defined for each
unique Domain/Zone, as indicated by your ZONETYPE----> entry in your
MSGTOSS.CFG. Refer to MSGCFG.REF for detailed information.

NOTE: The AREAs NETMAIL and UNKNOWN are required for all MSGTOSS
installations, where ROUTETHRU and MSGCAPTURE are optional.

Example:

-NODE:1 (The first NODE--------> entry Zone:1)
C:\MAIL\NETMAIL.001\ NETMAIL
C:\MAIL\UNKNOWN.001\ UNKNOWN
C:\MAIL\ROUTEIT.001\ ROUTETHRU (optional)
C:\MAIL\CAPTURE.001\ MSGCAPTURE (optional)
;
-NODE:2 (The second NODE--------> entry Zone:8)
C:\MAIL\NETMAIL.008\ NETMAIL
C:\MAIL\UNKNOWN.008\ UNKNOWN
C:\MAIL\ROUTEIT.008\ ROUTETHRU (optional)
C:\MAIL\CAPTURE.008\ MSGCAPTURE (optional)
;

The areas UNKNOWN and NETMAIL are required as either an RBBS conference
or as a FIDO style conference. Note that tossing these into an RBBS
conference (only) is a one way street. Although MSGTOSS will be happy
doing this, its serves no useful purpose.

NOTE: Placing Net/Node lists following these areas will do nothing, as
MSGTOSS will ignore them. These areas should be Non-Echoed ar-
eas.

NOTE: The areas NETMAIL, UNKNOWN and ROUTETHRU (if exist) will be
exempt from dup and size checking, even if you specify CDUP:1.

AREA:NETMAIL
------------
NETMAIL is required! All non-echo mail will be tossed into this
area for users (and sysops) Netmail. Recommended to be a double-
tossed area (both RBBS and FIDO-Style). This is optional, but its
nice having the MAIN message base listed, as MSGTOSS's internal
maintenance routines (such as SIZING, PURGING & MAILWAITING RESET)
will also apply. Also if all NETMAIL is tossed into the main RBBS
message base, then users will be notified of their NETMAIL (and
can read it).

Example of double tossed NETMAIL AREA:

Page - 12





MSGTOSS.BBS Reference Manual


C:\RBBS\MESSAGES NETMAIL (no nodes listed!)
C:\MAIL\NETMAIL.001 NETMAIL (no nodes listed!)

NOTE: Separate directories must be defined for NETMAIL for each
unique Domain/Zone, as indicated by your ZONETYPE----> entry
in your MSGTOSS.CFG. Refer to MSGCFG.REF for detailed
information.

AREA:UNKNOWN
------------
UNKNOWN is required! This is where echomail, whose areas were
omitted from your MSGTOSS.BBS file will be tossed when MSGTOSS
can't figure out where they go. Recommended to be a Fido-style
area as you can toss the previously unknown (after you fixed the
BBS file) using the "/TUNK" (toss unknown) switch. Messages with
UNKNOWN areas will be tossed into the specified directory along
with the original AREA:xxxx which was not recognized.

NOTE: Separate directories must be defined for UNKNOWN for each
unique Domain/Zone, as indicated by your ZONETYPE----> entry
in your MSGTOSS.CFG. Refer to MSGCFG.REF for detailed
information.

AREA:MSGCAPTURE
---------------
Note that MSGCAPTURE is optional. This is the directory where (if
CAPT:x is true) all messages that contain target strings in accor-
dance with the "CAPTURE---->" entries (in MSGTOSS.CFG). Note that
after you have done what you needed to these messages, you can
then import them into public areas by using the "/TCAP" (toss
MSGCAPTURE) command line switch.

NOTE: Read documentation on CAPT:x for more information on this
feature.

NOTE: Separate directories must be defined for MSGCAPTURE for each
unique Domain/Zone, as indicated by your ZONETYPE----> entry
in your MSGTOSS.CFG. Refer to MSGCFG.REF for detailed
information.

AREA:ROUTETHRU
--------------
Note that ROUTETHRU is optional. All NETMAIL messages that are
NOT addressed to ANY of your AKA(s) (NODE------> entries) will be
tossed into your NETMAIL area (which is required). However, if
you have this special area called "ROUTETHRU", then MSGTOSS will
toss those messages here instead. This is useful for HUBS who
want to control mail routing.

NOTE: Separate directories must be defined for ROUTETHRU for each
unique Domain/Zone, as indicated by your ZONETYPE----> entry
in your MSGTOSS.CFG. Refer to MSGCFG.REF for detailed
information.

-----------------------------------------------------------------------


Page - 13





MSGTOSS.BBS Reference Manual


PASSTHRU AREAS
--------------

MSGTOSS supports Qmail-Style PASSTHRU areas, these require the follow-
ing format:

Example:

#[Optional Path] RBBS-PC 1:343/300 301 301 666/1 2 3

Note that the FIRST character must be a "#", followed by the AREA:
name, followed by the list of NET/NODES. Note that the NET/NODES will
ONLY be "fed" if you are using the "/FEED" switch. Note that QMAIL re-
quires a Fido Path to follow the "#", and this CAN be listed, but
MSGTOSS will ignore the path.

NOTE: The PASSTHRU function will NOT work without the /FEED command
line switch.

-----------------------------------------------------------------------





































Page - 14





MSGTOSS.BBS Reference Manual


Chain to the next BBS file - NBBS:[path]Filename.ext
------------------------------------------------------

NBBS:file - The next 'MSGTOSS.BBS' file to "chain" to after processing
is complete with the current file. This allows you to have
multiple AREAS.BBS files, one or each ZONE. MSGTOSS will
read all sequentially, but will not allow one that has al-
ready been processed to be processed again (will abort).

Example:

-NBBS:C:\MSGTOSS\MSGTOSS.BB2

The NBBS Keyword allows the chaining of multiple *.BBS
files. The format is NBBS:filename. NBBS may appear on any
of the control lines in the BBS file. The current file
that it appears in will be processed all the way to the end
before MsgToss will look for the new file. If more than
one NBBS parameter appears in a BBS file, only the last one
will be honored.

Possible uses:

If you NEED to keep separate *.BBS files for separate ZONES
or domains, or you are using another mail processing utili-
ty that can't handle the multiple domain/zone *.BBS file
that MSGTOSS uses, or you just want to keep a separate
MSGTOSS.BBS file for maybe Fidonet and Rbbs-Net (zone 1
& 8).

-----------------------------------------------------------------------


























Page - 15





MSGTOSS.BBS Reference Manual


No. of records in RBBS message base(s) - RECS:xxxx
----------------------------------------------------

RECS:xxx - All RBBS Conferences require "-RECS:xxxx" to apply where
the xxx is the size in RECORDS of that message base. The
xxxx will be the size the message base is CHOPPED back
down (or INCREASED) to when using the /SIZE (or /SIZE-UP)
switches when necessary.

Example:

-RECS:1000
C:\RBBS\RBBSM.DEF RBBS-PC 1:343/300
C:\RBBS\COMMM.DEF COMM 1:343/300

-RECS:2000
C:\RBBS\MSGTOSSM.DEF RBBS_MSGTOSS 1:343/300

Means that the RBBS conferences RBBSM.DEF and COMMM.DEF are
both 1000 records but MSGTOSSM.DEF conference is 2000 re-
cords.

1000 records * 128 = 128,000 bytes
2000 records * 128 = 256,000 bytes

NOTE: Actual size of the message bases is (xxxx * 128)

Notice how another RECS:1000 entry IS NOT required
for COMMM.DEF, as the previously entered one still applied.

Whats the purpose of this? When you preassign the sizes of
the message bases as such, MSGTOSS will know what sizes
they are suppose to be, allowing extremely easy SIZING of
the message bases. No more need to use the clumsy CONFIG
program that came with RBBS-PC. All you need to do to
change the size of message bases is to change the RECS:xxxx
entries, and issue one of the MSGTOSS SIZING command. For
instance:

MSGTOSS /SIZE

Will CHOP message bases back down (but not up) if the sizes
of any of them EXCEED the sizes as defined in the RECS:x
keywords.

MSGTOSS /SIZE-UP

Will CHOP message bases back down AND INCREASE them (as re-
quired) to match their associated RECS:xxx keywords.

Why was such a wonderful utility included with MSGTOSS? Be-
cause MSGTOSS will expand a message base (only if it has
to) to accommodate messages, and one quick MSGTOSS SIZE
command line will restore them (maybe a daily event).

If you have multiple sizes for your RBBS message bases

Page - 16





MSGTOSS.BBS Reference Manual

(why?) then you will have to have a different "-RECS:xxx"
entry before EACH RBBS-related line.

NOTE: Place all similar sized RBBS message bases together,
so you can have just one "-RECS:xxx" entry that will
apply for them.

NOTE: The old "|R999|" will no longer work! Configure
these on a preceding line as "-RECS:999"

-----------------------------------------------------------------------















































Page - 17





MSGTOSS.BBS Reference Manual


Re-number msg only if last exceed xxxx - RNIF:xxxx
----------------------------------------------------

RNIF:xxx - During an internal purge, will re-number, BUT ONLY IF
the last message number of the message base (Prior to the
purge) is GREATER (or EQUAL) to the RNIF:xxx value.

Example:

-RECS:1000 RNST:1 RNIF:500
C:\RBBS\RBBSM.DEF RBBS-PC 1:343/300
C:\RBBS\COMMM.DEF COMM 1:343/300

So in this case MSGTOSS will execute internal re-numbering
on the above conferences, but only IF their LAST message is
greater than (or equal) to 500. Incidentally, the re-num-
bering will start with "1", as defined by the RNST:1 key-
word.

When MSGTOSS purges messages MSGTOSS will check to make
sure that last message entered in the message base is >=
RNIF:xxx, otherwise MSGTOSS will simply skip re-numbering.

NOTE: This is used in conjunction with the RNST:xxx (re-
number start) keyword.

NOTE: MSGTOSS will automatically reset the "last message -
read" entry in the associated USERS(s) file to the
NEW message number -or- the next closest NEW message
number, so last-read pointers will NOT be lost.

This works like its little cousin, MSGRENUM (Version 1.4,
Mike Zakharoff, available as MSGREN14.xxx).

-----------------------------------------------------------------------






















Page - 18





MSGTOSS.BBS Reference Manual


Re-number msg bases starting with - RNST:xxxx
-----------------------------------------------

RNST:xxx - Re-numbering of messages (during an internal purge) will
START with this number...

Example:

-RECS:1000 RNST:1000
C:\RBBS\RBBSM.DEF RBBS-PC 1:343/300
C:\RBBS\COMMM.DEF COMM 1:343/300

When MSGTOSS purges messages then MSGTOSS will make the
FIRST message of the message base start with the number
1000, next is 1001, 1002, etc.

NOTE: Recommended to be set to "1".

NOTE: MSGTOSS will automatically reset the "last message -
read" entry in the associated USERS(s) file to the
NEW message number -or- the next closest NEW message
number, so last-read pointers will NOT be lost.

This works like its little cousin, MSGRENUM (Mike Zakhar-
off).

-----------------------------------------------------------------------






























Page - 19





MSGTOSS.BBS Reference Manual


Security level of tossed messages set to - ESEC:xxxx
------------------------------------------------------

ESEC:xxx - ESEC:xxx sets the security level of the message during
tossing, and during purging as users with the security
level of ESEC:xxx or higher will not have their messages
deleted.

Example:

-RECS:1000 ESEC:5
C:\RBBS\RBBSM.DEF RBBS-PC 1:343/300
C:\RBBS\COMMM.DEF COMM 1:343/300

Means that these two conferences (and ones that follow)
will have the messages tossed into them to a security level
of "5".

*READ* --> NOTE: If you set ESEC:xx higher than the SYSOPS level, then
even YOU won't be able to read messages tossed. This
is a VERY IMPORTANT keyword!

-----------------------------------------------------------------------


































Page - 20





MSGTOSS.BBS Reference Manual


The "home" NODE address for the echo - NODE:xxxx
--------------------------------------------------

NODE:x - The "home" node address for the echo area. This switch
determines the domain and zone to which the echo belongs
and identifies which of your AKA addresses will be used for
the origin lines generated during a /SCAN. NODE:1 selects
your primary address, NODE:2 your first AKA, etc.

NOTE: The order of the NODE:x entries must coincide with
the NODE--------> entries in your MSGTOSS.CFG file
(very important!).

Example:

You belong to two domains (Fidonet and Rbbs-Net), as shown
in your MSGTOSS.CFG file:

NODE-------->1:343/36.0@fidonet (NODE:1) primary <---+
+------> NODE-------->8:918/11.0@rbbs-net (NODE:2) AKA |
| |
| And your MSGTOSS.BBS file contains BOTH Fidonet and |
| RBBS conferences, as shown: |
| |
| -NODE:1 \ |
| C:\RBBS\RBBS1M.DEF RBBS-PC 1:343/300 >-----+
| C:\RBBS\COMMM.DEF COMM 1:343/300 /
|
| / -NODE:2
+---< C:\RBBS\RBBS8M.DEF RBBS-PC 8:918/1
\ C:\RBBS\MSGTOSSM.DEF RBBS_MSGTOSS 8:918/1

The first two conferences are linked to the primary address
(1:343/36) via the NODE:1 keyword, and the second two con-
ferences are linked to the second address via the NODE:2
keyword.

Notice that the RBBS-PC conference is listed two times,
once for Fidonet and Rbbs-Net. This is totally valid, and
MSGTOSS should be able to keep them totally separate. Note
also that this would cause other mail processors go bon-
kers, so if you plan on sharing your MSGTOSS.BBS file with
other processes then you may not want to do this.

****************************** IMPORTANT!! ****************************
* The NODE:x entries MUST coincide with the NODE--------> entries *
* in your MSGTOSS.CFG file. For instance, if your FIRST NODE entry *
* is: *
* *
* NODE------->1:343/36.0@fidonet *
* *
* Then you must have a NODE:1 ("1" meaning your FIRST NODE--------> *
* entry) which informs MSGTOSS that these conferences are associated *
* with this NODE-------> entry. *
* *
* NOTE: Failure to set these correct will screw up the * Origin: *

Page - 21





MSGTOSS.BBS Reference Manual

* lines during an export! *
* *
* NOTE: Once you configure these NODE entries you should avoid *
* changing the ORDER of these entries unless you simultaneously *
* change both at the same time. *
* *
* Remember, remember, remember... These two items (NODE-------> & *
* NODE:x) are linked and MUST be configured properly. *
* *
***********************************************************************

-----------------------------------------------------------------------














































Page - 22





MSGTOSS.BBS Reference Manual


Max lines before MSGTOSS auto-breaks msg - MAXL:xxxx
------------------------------------------------------

MAXL:xxx - If set to say 99, MSGTOSS will toss (for extremely large
messages) in 99 line chunks, and then create a new message,
appending "MSGTOSS (continued on NEXT message)" to the
bottom of the message. Since the maximum message length is
150 lines in RBBS, recommend this be set to at least 99.

Example:

-RECS:1000 MAXL:99
C:\RBBS\RBBSM.DEF RBBS-PC 1:343/300
C:\RBBS\COMMM.DEF COMM 1:343/300

Means that these two conferences (and ones that follow)
will auto-break messages if they exceed 99 lines into mul-
tiple messages (99 line chunks).

If MAXL: is set to say 99, then MSGTOSS will take an ex-
tremely long message and break it up to 99 line chunks. As
you know, MSGTOSS can import a whole BOOK into M.DEF's, but
unfortunately RBBS is only capable of displaying 150 lines
max (wonderful planning). Setting MAXL:xx to say 100 will
allow it to be fully read.

In addition, when MSGTOSS breaks up a message, it will ap-
pend ....

MSGTOSS (continued on NEXT message) to bottom of message
MSGTOSS (continued from LAST message) to top of next...

The purpose of this is to allow the SCANNING code to re-
build the message for export if necessary.

NOTE: During a Re-Scan (/RSCAN: switch, applies ONLY to
HUBS), MSGTOSS will do its best to "re-create" the
original message which was broken up due to MAXL:x.

************************ WARNING! *************************

If you use another message utility to export mail from RBBS
(like RBBSMAIL) then DON'T use this feature!! With
RBBSMAIL you may be safe by using the FMAS:1 keyword, but
others will probably cause problems. Why use RBBSMAIL any-
way???? (?<>^%$#@!)

-----------------------------------------------------------------------









Page - 23





MSGTOSS.BBS Reference Manual


Min free messages if overflow condition - SLAK:xxxx
-----------------------------------------------------

SLAK:xxxx - When MSGTOSS does an internal purge, MSGTOSS will always
make sure that the number of messages left in the message
base is always LESS than ( RBBS-MAX-----> minus SLAK:xxxx
). This helps prevent the possibility of "overflows"
beyond the RBBS maximum of 999 (RBBS-MAX) messages.

Example:

-RECS:1000 SLAK:10
C:\RBBS\RBBSM.DEF RBBS-PC 1:343/300
C:\RBBS\COMMM.DEF COMM 1:343/300

The SLAK keyword sets the number of open message numbers to
leave at the end of a conference. The default value is
10. When tossing mail, MsgToss will compute the resulting
number of messages for the conference (current messages
plus new messages) and compare that to RBBSMAX. If the
total message count is greater than RBBSMAX minus SLAK, a
purge will be forced. This virtually eliminates wood> the possibility of an "overflow" beyond the RBBSMAX
value.

-----------------------------------------------------------------------































Page - 24





MSGTOSS.BBS Reference Manual


Format right margin of RBBS messages to - MRGN:xx
---------------------------------------------------

MRGN:xx - What right margin should the RBBS conferences should be
set to. RBBS normally formats newly entered messages to
72. It should be noted that setting the
right margin beyond the RBBS expected value of 72 may cause
editing to be more difficult, but will make the
messages more pleasing to read. Values beyond 77 are not
recommended. A value of 39 can be used to format the
message bases to support 40 column users.

Example:

-RECS:1000 MRGN:77
C:\RBBS\RBBSM.DEF RBBS-PC 1:343/300

-MRGN:39
C:\RBBS\COMMM.DEF COMMODORE_64 1:343/300
-MRGN:77

Note that only for the COMMODORE_64 conference, the right
margin will be formatted to 39 characters, but immediately
after its set back to 77.


NODE: Valid entries are 30 through 79

NOTE: If not supplied, a default of 72 will be used

-----------------------------------------------------------------------


























Page - 25





MSGTOSS.BBS Reference Manual


Whether to honor PRIVATE ECHOMAIL msgs - PRIV:x
-------------------------------------------------

PRIV:x - During /TOSS (importing mail):

Whether to honor incoming PRIVATE echomail. Normally
set "0" (or blank), which converts to public.
Setting to "1" will slow down tossing. If tossing NET-
MAIL into an RBBS conference then MSGTOSS will AUTOMATI-
CALLY check it the message is private. Better to set
this switch to "0".

If PRIV:1 is set, MSGTOSS will check if the message is
private (private echomail DOES exist) and if so will
make the message private in the M.DEF conference.

During /SCAN (exporting mail):

Also used to honor OUTGOING private messages.

For exporting messages, the following rules apply:

If COMMENT will not be exported (ever)
If PRIVATE and TO:SYSOP will not be exported
If PRIVATE and TO:USER and PRIV:1 then export (priv set)
If PRIVATE and TO:USER and PRIV:0 then DON'T export


Example:

-RECS:1000 PRIV:0
C:\RBBS\RBBSM.DEF RBBS-PC 1:343/300

-----------------------------------------------------------------------























Page - 26





MSGTOSS.BBS Reference Manual


Force Msgs to M.DEFs as Already Scanned - FMAS:x
--------------------------------------------------

FMAS:x - Force Mail As Scanned. Will set the second colon of the
TIME field to a '.' vice ':'. This is the "marking"
mechanism MSGTOSS (and RBBSMAIL, if used) uses to say that
the message is NOT to be exported, or has already been ex-
ported.

Example:

-RECS:1000 FMAS:1
C:\RBBS\RBBSM.DEF RBBS-PC 1:343/300

NOTE: There is really NO GOOD REASON to have this set to
"0", unless you insist on using another mail proces-
sor to export from RBBS conferences (like RBBSMAIL).

************************* WARNING! ************************
* Setting FMAS:0 and using MSGTOSS will cause MSGTOSS to *
* happily reexport your mail back to your host! Again, *
* this is a special purpose switch that you might as well *
* forget about it (leave it set to FMAS:1) unless you *
* want to catch hell. *
***********************************************************

Newly entered messages (local) have the second colon of the
TIME to be a colon (as it should). After MSGTOSS exports
a message, it will change it to a "." (period). If /FEED
command line switch is used, FMAS:x will be forced to "On"
for all echo areas.

NOTE: Carefully UNDERSTAND the effects of this switch if
you set it to be null (FMAS:0). It should NEVER be
null if you use MSGTOSS to export mail from RBBS mes-
sage bases. If you do, then MSGTOSS will happily re-
export all messages BACK to the host! The only REAL
reason to set to null would be if you planned to use
RBBSMAIL to "FEED" downstream nodes (not recom-
mended).

-----------------------------------------------------------------------















Page - 27





MSGTOSS.BBS Reference Manual


Strip Echo Control Lines (Only FMAS:1) - SECL:x
-------------------------------------------------

SECL:x - Strip Echomail Control Lines. This switch CAN ONLY be
used in conjunction with the FMAS:1 switch, as explained
above. Basically, if you are using the FMAS:1 switch, you
are telling MSGTOSS to don't bother exporting echomail
that has already been tossed to RBBS conferences. If this
is the case then why bother importing echomail control
lines such as SEEN-BY:,
PATH: and other lines. Using
this feature will DRASTICALLY improve the number of
messages allowed to be imported in a given message base, as
SEEN-BY: lines can use large amounts of disk space.

Example:

-RECS:1000 SECL:1
C:\RBBS\RBBSM.DEF RBBS-PC 1:343/300

In your MSGTOSS.CFG file, set:

SECL-------->SEEN-BY:
SECL-------->


Will strip all occurrences of SEEN-BY:,
EID:,
PATH:,

MSGID: &
VIA:, and other lines beginning with ^a in RBBS
messages.

NOTE: The most restrictive entry will override a similar
less restrictive entry, example:

SECL-------->

SECL-------->
PATH:

The first entry ALREADY will strip the second entry!

NOTE: Also see SECL--------> in MSGCFG.REF for more
information.

NOTE: During a re-scan (/RSCAN:xxx, for HUBS) of an RBBS
message base, MSGTOSS will automatically IGNORE ex-
isting SEEN-BY: and PATH: lines anyway, and simply
create TINY control lines. Therefore the ONLY real
reason to NOT use this switch is where you are using
ANOTHER mail exporter (like RBBSMAIL) that requires
complete SEEN-BY and PATH: lines.

-----------------------------------------------------------------------









Page - 28





MSGTOSS.BBS Reference Manual


Hash USERS to keep msgs while purging - USRH:x
------------------------------------------------

USRH:x - Whether to (when conducting an INTERNAL purge) load all of
the users in memory to keep conference users messages
around as specified by the various DAYSTO??? parameters
(in the MSGTOSS.CFG file. Also setting to FALSE ("0") will
make the internal purge as fast as possible. For very
LARGE USERS files (like the main message base) will speed
up purging.

Example:

-USRH:0
C:\RBBS\MAINM.DEF NETMAIL

-USRH:1
C:\RBBS\RBBSM.DEF RBBS-PC 1:343/300

In the above example, the Main message base is set to
USRH:0, as there is alot of users, and set the smaller
conference RBBS-PC to USRH:1.

For small conferences (who have small user files)
recommended to be set for TRUE ("1").

The BBS keyword "USRH:1" directs MSGTOSS whether to load
all of the users into memory prior to purging. For very
large message bases with alot of users, the purging speed
can be dramatically increased by using the "USR:0" BBS
keyword, as hashing users will not take place. However,
loading the users have alot of benefits (read on).

MSGTOSS will purge ONLY ENOUGH messages for successful
importation. Therefore, if only 2-3 messages are received
in a particular conference, then roughly the same amount
will be purged (if there isn't enough space to begin with).

MSGTOSS can handle roughly 1500 users in memory at any
one time. If MSGTOSS detects that it is running out of
memory as users are being loaded, it will stop loading
in memory and page the remaining users to disk. This
causes the purging to be slower (but more complete). For
optimum operation, try to keep the sizes of your conference
users under 1500 or use the USRH:0 BBS keyword where
appropriate.

Using the "USRH:1" BBS keyword will prevent messages
from being purged before the sysop or conference users
have had a chance to read them. This feature is called
"smart-purging" in other MSGTOSS documents.

-----------------------------------------------------------------------




Page - 29





MSGTOSS.BBS Reference Manual


Capture messages with special text - CAPT:x
---------------------------------------------

CAPT:x - Whether to (when tossing) to divert messages that contain
the "text words" as specified by the various "CAPTURE---->"
items entered in the MSGTOSS.CFG file. These messages
will be tossed to a special area called "MSGCAPTURE",
which must exist in the MSGTOSS.BBS file. Recommended if
used to be a FIDO style area, so after censorship can be
imported.

Whenever a message contains these words (could be anywhere
in the message) then MSGTOSS will divert those messages to
a special area defined as MSGCAPTURE. This must be
entered in your MSGTOSS.BBS file as a non-echo'ed area...

Example: (in MSGTOSS.BBS)

-CAPT:1
C:\RBBS\RBBSM.DEF RBBS-PC 1:343/300
-CAPT:0

C:\MAIL\CAPTURE.001 MSGCAPTURE (non-echoed area)

Example: (in MSGTOSS.CFG)

CAPTURE----->SHIT
CAPTURE----->FUCK (We're all adults, right)

These are entered in your MSGTOSS.CFG file. Then if you
have "CAPT:1" turned on for a particular conference (in
this example the RBBS-PC conference), then those messages
will be diverted to C:\MAIL\CAPTURE.001 as a Fido-style
message. Note that you will have to create a separate
directory for each unique Zone defined. After checking
over these messages, you can re-import these messages to
their respective conference via the "/TCAP" (toss
captured) command line switch.

******************* WARNING WARNING **********************
* Don't use this feature to censor other BBS systems! *
* This is intended to censor a private BBS system, for *
* those desiring this. A safeguard was built in to *
* prevent those who /FEED downstream nodes from *
* capturing messages to downstream nodes. *
**********************************************************

NOTE: To use this feature, you must turn the "CAPT:1"
switch on (in your MSGTOSS.BBS file).

NOTE: After you are done with the messages in MSGCAPTURE,
you can re-toss back to the proper area by using the
"/TCAP" (toss capture) switch.

-----------------------------------------------------------------------


Page - 30





MSGTOSS.BBS Reference Manual


Enable Duplicate Checking for AREA - CDUP:x
-------------------------------------------

CDUP:x - MSGTOSS will check for duplicates during the tossing phase
when using the CDUP:x keyword. If one is encountered, wil-
lignore the message and display in informational line of
the duplicate while tossing. If you specified the /DLOG
(Maintain Dup Log File) switch, when a duplicate is en-
countered MSGTOSS will append the date, pkt, msg number,
area and net/node of originating system into a file called
MSGTOSS.DUP.

This feature allows individual conference configuration on
whether to check for duplicates (or not). For instance,
you are having problems in the SCIENCE echo, but all others
seem fine. All you need to do is the following:

-CDUP:1
C:\RBBS\SCIENCEM.DEF SCIENCE 1:343/300
-CDUP:0

All other echos (following SCIENCE) will have the dup
checking disabled.

NOTE: The areas NETMAIL, UNKNOWN, ROUTETHRU & MSGCAPTURE
are exempt from dup checking.

NOTE: If you have a reliable HUB, who faithfully checks for
DUPS before sending to you, then the use of this key-
word may NOT be necessary and will make mail events
as fast as possible.

See MSGCFG.DOC (DUPFILE, MAXAREAS, DUPSIZE), MSGTOSS.DOC,
(Duplicate messages) and MSGEID.EXE for more information on
this.

-----------------------------------------------------------------------




















Page - 31





MSGTOSS.BBS Reference Manual


Set Mailwaiting Bits for new RBBS msgs MWST:x
---------------------------------------------

MWST:x - Use MSGTOSS's internal code to set mailwaiting bits in its
associated user file for all new messages. After success-
ful tossing of the messages, MSGTOSS will set the 'mail-
waiting bits' for the active conference. This allows users
to be notified when they log-on the system whether they
have mail waiting to be read in each of the conferences.
During initializing, MSGTOSS will remember what the
first message was before it started tossing, therefore
if you use the MWST:1 keyword, it will ONLY set the bit
for new messages.

NOTE: When using the /MWRST (mailwaiting reset) switch, all
MWST:x keywords are ignored.

-----------------------------------------------------------------------







































Page - 32





MSGTOSS.BBS Reference Manual


Maintain a history file of purged msgs HIST:x
---------------------------------------------

HIST:x - If HIST:x is true (HIST:1) then MSGTOSS will append all
purged messages into a *.HIS file. The message will be
off-loaded in text format, similar to RBBS-PCs internal ed-
itor. If the message base is RBBSM.DEF, MSGTOSS will ap-
pend all purged messages into a file called RBBSM.HIS. For
the file MESSAGES, will be MESSAGES.HIS. It is recommended
that this feature be used in moderation. Overuse may cause
disk space to be filled up fast!

Example:

-HIST:1
C:\RBBS\RBBSM.DEF RBBS-PC
-HIST:0

Will create/append all purged messages into a file called
RBBSM.HIS. Here is an example of the text format.

---------------------------------------------------------------------------
Msg #: 23 Purged: 01-15-92 18:58:00
From: MIKE ZAKHAROFF Sent: 12-29-91
To: ALL Rcvd:
Re: MSGTOSS 2.0

Will be releasing MSGTOSS 2.0 real soon. Are you ready for "mail
tosser shock"?

Have a Happy New Year!!!


--- MsgToss 2.0
* Origin: MsgToss Support System (206)555-1212 (1:138/154)
---------------------------------------------------------------------------

NOTE: This does slow down purging, as the message has to
be exported FIRST, then the pack-in-place takes
place.

-----------------------------------------------------------------------















Page - 33





MSGTOSS.BBS Reference Manual


Zone/Domain gating option - GATE:x
------------------------------------

GATE:x - Whether to enforce normal echo mail rules when generating
echo mail control lines within messages. GATE:2 performs
normal echo mail handling, providing zone and domain
separation of echo areas. Only mail addressed to your
NODE addresses in the same zone and domain as the
identified with the NODE:x key word will be tossed into the

area. Seen-by lines will list only your AKAs that match
the zone and domain of the receiving system. This is the
normal mode for all backbone echo mail conferences. GATE:1
relaxes these rules to allow you to DELIBERATELY VIOLATE
ECHO MAIL RULES and freely share selected echos that have
LIMITED distribution and do not depend on the echo mail
control lines to track their routing. GATE:1 echos will
receive mail addressed to any of your AKAs and will add all
of your AKAs, regardless of zone and domain,to the seen-by
lines sent to all recipients of the message.

Example:

-GATE:2
C:\RBBS\RBBSM.DEF RBBS-PC 1:343/300

NOTE: Unless you are really familiar with all aspects of
MSGTOSS, and how it behaves in multi-zone
environments, its better to leave this set to GATE:2
all of the time.

Beta Info:

The GATE:x option determines if an echo area
may be shared between domains and zones. GATE:2 enables
zone and domain separation, and works very much like
MsgToss has always done. GATE:1 disables the zone and
domain isolation that MsgToss does so well. GATE:1 is
useful for local (or non-backbone) echos that you wish to
share freely with all zones you support. SEEN-BY lines for
GATE:1 areas will contain node addresses for all zones.
Be sure to use GATE:2 for backbone echos to keep your
seen-by lines clean. (MsgToss will default to GATE:2
unless you intentionally tell it to shoot you in the foot.)

-----------------------------------------------------------------------












Page - 34





MSGTOSS.BBS Reference Manual


Origin: line to be used for scanning - ORGN:text
--------------------------------------------------

ORGN:text - When exporting (scanning) a message, what Origin: line to
use. In addition, during a PURGE operation, and MSGTOSS is
processing a previously exported message, and "" was
placed during a /SCAN operaion, the Origin line MSGTOSS
will insert into the message while purging.

Example:

-ORGN:MSGTOSS is wonderful!
C:\RBBS\RBBSM.DEF RBBS-PC 1:343/300

Will appear on the outbound message when exported as...

* Origin: MSGTOSS is wonderful! (1:343/36)

NOTE: The ORGN:xxx entry(s) must be either the LAST entry
of a series of BBS keywords --or-- on a line by own!

The default" origin line (the one at the top of the file)
will ALWAYS apply, EXCEPT for the "first" message base af-
ter the -ORGN:xxxx entry...

Example:

INTERSTATE BBS Sea WA (206)631-3231 450 Meg

The default origin line

-ORGN:MSGTOSS - The BEST for RBBS (Ver 2.0 coming soon)!
C:\RBBS\rbbsm.def RBBS-PC 343/300

Default takes over again

C:\RBBS\sciencem.def SCIENCE 343/300
C:\RBBS\techm.def TECH 343/300
C:\RBBS\warningm.def WARNINGS 343/300

-----------------------------------------------------------------------
















Page - 35