ProfitPress Mega CDROM2 Shareware Freeware (MSDOS)(1992)(Eng)

home *** CD-ROM | disk | FTP | other *** search

/ ProfitPress Mega CDROM2 …eeware (MSDOS)(1992)(Eng) / ProfitPress-MegaCDROM2.B6I / BBS / RBBS_PC / MSGTOS2B.ZIP / MSGBBS.DOC < prev next >

Wrap

Text File | 1992-02-11 | 70.7 KB | 2,311 lines

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 <rtn> 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 <rtn> 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 <knock on 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: <Not 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 "<XMT>" 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