Piper's Pit BBS/FTP: ibm 0000

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

/ Piper's Pit BBS/FTP: ibm 0000 - 0009 / ibm0000-0009 / ibm0003.tar / ibm0003 / NETMAL45.ZIP / NETMAIL.DOC < prev next >

Wrap

Text File | 1990-01-18 | 140.8 KB | 3,284 lines

NetMail Version 4.5 Network Mail System For PCBoard 14.0 by Mark J. Findlay Home Dba BBS (206) 789-9302 (WASEA) Copyright (c) 1989,90 All Rights Reserved Disclaimer: The author makes no warranties expressed or implied as to the quality or performance of this program. The author will not be held liable for any direct, indirect, incidental, or consequential damages resulting from the use of this program. Your use of the program constitutes your agreement to this disclaimer and your release of the author from any form of liability or litigation. We are continuing our full support of the NetMail system and are constantly working to improve our product to suit the needs of the users. Many of the upgrades to NetMail since its original release are due to user's comments and suggestions for improvement. We also provide FREE 24 hour support to ALL Home Dba Software users regardless of their registration status via our support board (Home Dba BBS) as well as the HOMEDBA conference carried by systems throughout the United States. Table of Contents. NETMAIL.ZIP Contents ............................... 1.0 Files Included with NETMAIL.ZIP ............... 1.1 Files Created by NetMail Processing ........... 1.2 GLOBAL.NET ................................ 1.2.1 CONF.NET .................................. 1.2.2 BBS.NET ................................... 1.2.3 NETWORK.LST ............................... 1.2.4 <BBS IDENTIFIER>.HST ...................... 1.2.5 Other Files Used by NetMail ................... 1.3 <TIMESTAMP>.SND ........................... 1.3.1 <BBS IDENTIFIER>.FIL ...................... 1.3.2 <BBS IDENTIFIER>.INF ...................... 1.3.3 <BBS IDENTIFIER>.OUT ...................... 1.3.4 <BBS IDENTIFIER>.IN ....................... 1.3.5 <BBS IDENTIFIER>.HST ...................... 1.3.6 NODELIST .................................. 1.3.7 TAGS.NET .................................. 1.3.8 TCAN.NET .................................. 1.3.9 NAMES.NET ................................. 1.3.10 PCB Caller Log ............................ 1.3.11 Introduction ....................................... 2.0 What is Networking ............................ 2.1 HUB vs NODE operations ........................ 2.2 What is NetMail ............................... 2.3 Setup .............................................. 3.0 HUB Responsibility - Assigning Conf Names ..... 3.1 Directories ................................... 3.2 Option Line Function Keys ..................... 3.3 F1 : Pop-Up Help .................... 3.3.1 F10 : Save ........................... 3.3.2 ESCAPE : Abort and/or Exit .............. 3.3.3 ALT-A : Add an Entry ................... 3.3.4 ALT-D : Delete an Entry ................ 3.3.5 ALT-U : Univeral Update an Entry ....... 3.3.6 PgUp, PgDn, Ctl-Home, Ctl-End, etc....... 3.3.7 Configuration ...................................... 4.0 Global Items .................................. 4.1 Sysop's Name ............................ 4.1.1 BBS Code ................................ 4.1.2 USERS File Directory (Path ONLY!) ....... 4.1.3 Work Directory........................... 4.1.4 File Directory........................... 4.1.5 Comm Directory........................... 4.1.6 CNAMES / CONFINFO Full Path/Filename .... 4.1.7 Is This a HUB Configuration ............. 4.1.8 Do You Operate a Node AND Hub ........... 4.1.9 If Hub, Should NetDoor Verify Callers ... 4.1.10 Max Age (Days) of Msgs to Export/Import . 4.1.11 Accept SEND Files ....................... 4.1.12 Max K Bytes to Import ................... 4.1.13 If Hub, Disable NetDoor From ............ 4.1.14 Tag Line ................................ 4.1.15 Conference Items .............................. 4.2 Conference Name Assigned By Hub ......... 4.2.1 Conference Filename ..................... 4.2.2 Last Msg Processed ...................... 4.2.3 Network Messages in this Conference ..... 4.2.4 Max Messages per Import ................. 4.2.5 Stop Incoming Private Msgs .............. 4.2.6 Stop Outgoing Private Msgs .............. 4.2.7 Convert Incoming Private Msgs ........... 4.2.8 Convert Outgoing Private Msgs ........... 4.2.9 Convert Outgoing Msgs to "Echo=Yes" ..... 4.2.10 Network Only "Echo=Yes" Messages ........ 4.2.11 Supress Tag on Outgoing Messages ........ 4.2.12 Creating a New Conference File ................ 4.3 Edit/Create Trash Can File .................... 4.4 RESET ......................................... 4.5 SEND .......................................... 4.6 Receiving Files from other Systems ...... 4.6.1 Differences between NODE and HUB SEND ... 4.6.2 SENDing a file to ALL NODES in a Network. 4.6.3 BBS Maintenance ............................... 4.7 HUB Creation of NODELIST Text File ............ 4.8 Misc Text File Creation ....................... 4.9 Running NetMail .................................... 5.0 EXPORT ........................................ 5.1 What is Exporting ......................... 5.1.1 Differences Between HUB and NODE Export ... 5.1.2 What Export Does .......................... 5.1.3 What Must Be Done Following Export ........ 5.1.4 Requesting a NODELIST from the HUB ........ 5.1.5 Re-Receiving Messages Already Received .... 5.1.6 Re-Receiving Your Last Mail Packet ........ 5.1.7 Caller Log Tracking of Export Activity .... 5.1.8 IMPORT ........................................ 5.2 Duplicate Message Handling ................ 5.2.1 Message Threading (Refer To:) ............. 5.2.2 Caller Log Tracking of Import Activity .... 5.2.3 Skipping Messages To and From Certain Users 5.2.4 Removing Excessive Tag Lines On Imports ... 5.2.5 PCBoard Caller Log and HUB Operations ......... 5.3 Sample PCBoard Event File .......................... 6.0 Other Required Programs ............................ 7.0 PKZIP, PKUNZIP ................................. 7.1 DSZ ............................................ 7.2 Step by Step Network Operations .................... 8.0 NODE Operations ................................ 8.1 HUB Operations ................................ 8.2 Running a NODE AND HUB from 1 System ........... 8.3 Unattended Logging of HUB Operations ........... 8.4 Networking Conferences Not On Your System ...... 8.5 Sample Script Files ................................ 9.0 Questions and Answers .............................. 10.0 Technical Information .............................. 11.0 How to Get Additional Help ......................... 12.0 Help in Finding/Joining a NetMail Network .......... 13.0 Other Programs From Home Dba Software .............. 14.0 Acknowledgements ................................... 15.0 1.0 NETMAIL.ZIP Contents. 1.1 Files Included with NETMAIL.ZIP. Congratulations. You are the owner of one of the most advanced network mail systems available: NetMail. Contained in the NETMAIL.ZIP file should be the following: CONFIG.EXE - NetMail Configuration Program. EXPORT.EXE - NetMail Export Program. IMPORT.EXE - NetMail Import Program. SEND.EXE - SEND function previously part of CONFIG.EXE. NETMAIL.DOC - This Document. NETMAIL.HLP - Pop-Up Help File. NETDOOR.ZIP - The NetMail HUB Door. SAMPLES.ZIP - Sample Script Files for NODE-HUB Transfers. If your NETMAIL.ZIP file is missing any of these files, please contact Home Dba BBS at (206) 789-9302 (WASEA). You may always download the most recent version of NetMail from our support conference there. 1.2 Files Created by NetMail Processing. During the course of its operation, NetMail creates several files. Some are kept, some are not. The following gives a brief description of these files for your information. 1.2.1 GLOBAL.NET - Maintains all information pertaining to global aspects of NetMail operation. When you execute the NetMail configuration program CONFIG.EXE, NetMail searches for the existence of this file. If not found in the current NetMail directory, NetMail assumes you are running CONFIG for the first time and presents you with the GLOBAL information screen. Pressing F10 after completing the information on the initial GLOBAL information screen saves the information into GLOBAL.NET. You must run the configuration program prior to running any other component of NetMail such as EXPORT, IMPORT or any DOOR operations. NetMail will search the default NetMail directory for this file and will abort if it is not found. 1.2.2 CONF.NET - Maintains information specific to each conference networked by NetMail. Just as GLOBAL.NET is required for any NetMail execution, so is CONF.NET. After completing the GLOBAL information screen for the first time, NetMail automatically loads the CONF.NET information with the entries from your CNAMES or CONFINFO file depending on which one you had specified in the GLOBAL configuration. As NetMail loads the conference information for the first time, it also performs a RESET on the conference (See RESET below) to insure that the first mail transfer of that conference message base does not contain your entire message base. It should be noted that NetMail does NOT write to your CNAMES file, CONFINFO file, or any other file related to PCBoard operations (except the caller log during door operations). All NetMail information is always maintained by NetMail's own information files in the default NetMail directory. Once you have loaded and configured the conference information, (See Conference information below) and press F10 to save, CONF.NET is created. No NetMail functions will perform with the prior creation and proper configuring of GLOBAL.NET and CONF.NET. 1.2.3 BBS.NET - Used by the HUB to maintain information on all participating NODES. Each time a HUB sysop saves the conference information, BBS.NET is updated with the HUB's up to date conference configuration. If you are operating as a HUB and wish NetDoor to cross reference all calling NODEs against the BBS.NET file, you must first use option 7 from the configuration program to add the NODE to the BBS.NET file. More on this function below. 1.2.4 NETWORK.LST - This file is created and maintained by the hub system's NetDoor program. It is the file used to automatically maintain the network-wide nodelist of the netowrk in which you participate. (This file should not be confused with the file "NODELIST" which is created by the hub system and details just the nodes carried by that hub). Each time a node (whether acting solely as a node or whether a hub performing the node aspect of node/hub operations) calls its hub system, its record on the NETWORK.LST file is updated. When the node receives its mail packet, the updated NETWORK.LST is included in that packet and is automatically placed in the node's NetMail directory. Subsequent exports by the node will automatically include the NETWORK.LST file, which will again be updated and returned to the node. It should be noted that this file is compressed prior to transmission and its compressed size remains negligible. After just a few day's transfers, the NETWORK.LST file will be sufficiently to reflect the network-wide structure of all the nodes and hubs in the network. You may print this structure via with the NetStat program provided to all registered users. 1.2.5 <BBS IDENTIFIER>.HST This file is created by the NetDoor and will reside only on HUB systems. A file with this naming convention will be created for each node that calls the hub system. If a particular hub is supporting 3 nodes, 3 ".HST" files will be maintained by that hub's NetDoor. The purpose of this file is to maintain the last mail pointers for each of the conferences networked by the calling node in case the calling node wishes to re-receive the last successfully transferred mail packet. If you operating solely as a node system, you will not encounter this file. 1.3 Other Files Used by NetMail. NetMail also maintains other files in the course of Import, Export and SEND functions. These files are given names corresponding to the 1 to 8 character BBS-Code identifier each Sysop designates during initial configuration: 1.3.1 < TIME STAMP >.SND - Used to tell the HUB system how to process files being sent to other NODES via the SEND command. When a file is sent to another node or HUB via the SEND command, NetMail creates a handling file with the timestamp of the send request and the name of the file begin sent. Once all target nodes have received the file, the < TIME STAMP >.SND file as well as the file being sent, is deleted by the HUB system. 1.3.2 < BBS IDENTIFIER >.FIL - The complete SEND file complete with all files to be sent via the SEND command (including <BBS IDENTIFIER>.SND) 1.3.3 < BBS IDENTIFIER >.INF - Information sent out by each node to keep the HUB system up to date on the NODE's configuration. This file is included with each export packet sent to the HUB. It contains the current configuration of the calling node system and the HUB system updates its BBS.NET file with this information upon each node's call. For this reason, the calling node can change its GLOBAL and/or CONFERENCE information as often as desired and the HUB system will automatically be updated with the new information. 1.3.4 < BBS IDENTIFIER >.OUT - The results of a NODE's Export. This file is sent directly to the NODE's communications directory. This file contains the complete packet, including any SEND file, and complete outgoing mail, from the NODE system. 1.3.5 < BBS IDENTIFIER >.IN - The results of a NODE's Import. After calling the HUB Door and transferring the < BBS IDENTIFIER >.OUT file to the HUB system, the NetDoor will gather the waiting mail for the NODE and place it into a file with the BBS CODE identifier prefix and .IN extension. The calling NODE then downloads this file from the HUB system into the COMM directory specified in the GLOBAL information configuration. 1.3.6 NODELIST - A NODE can request a text file nodelist from the HUB system comprised of information on all NODEs in the HUB's immediate network, by using the parameter NODELIST as part of the EXPORT command: Export nodelist NetMail will perform the export function as usual, but will also include a request of the HUB Door to automatically format a complete nodelist of all NODEs in the HUB's network. The HUB Door will format the NODELIST file by BBS Code, Sysop's Name, Tag Line, and all conferences carried by each NODE. Upon import, the requesting NODE will then find the file NODELIST in the FILES directory specified in the GLOBAL configuration. The NODELIST file can be used as a PCBoard bulletin as well as for browsing by the NODE sysop. The HUB sysop need not require such a NODELIST as the same information can be browsed with option 7 from the config.exe program. 1.3.7 TAGS.NET - This file contains the tag line prefixes that will be used by the import program to identify and subsequently remove excessive tag lines from incoming messages. This file is created by the user using a text editor. See Import processing for further details. 1.3.8 TCAN.NET - This file contains any words that the sysop wishes to be replaced by SPACES during the importing of new messages. This is a text file, created by the system using a text editor. See Import processing for further details. 1.3.9 NAMES.NET - This file contains any names of users the sysop wishes to exclude from any incoming messages. Any incoming message with the Addressor or Addressee field matching any name in this file, will NOT be imported into the system. See Import processing for further details. 1.3.10 PCB Caller Log - This is the text file which PCBoard logs all BBS activity. It is also used by the export and import processes to record NetMail network activity. This is especially useful for use with NetStat, the NetMail Statistics and Report Generator available to registered users only. See Import Processing for further details. 2.0 Introduction. 2.1 What is Networking. Networking, as the term applies to PCBoard mail systems, is a means for several BBSes to share each other's message bases. Briefly, the design of the NetMail networking system is this: A group decides it wishes to share the messages contained on their systems with each other. One system agrees to act as the central processing center through which all the other systems will receive and send their mail. This central processing center is known as the HUB system. There need not be only one HUB but for the purposes of explanation we will use only one. The HUB system sets up the NetDoor door which the calling NODEs (NODEs are all the other BBSs in the system besides the HUB) will transfer their mail. Each NODE sets up its own NetMail program and configures its system accordingly. All NODEs follow the same process of exporting, calling the HUB system with the new mail, and finally importing new mail received from the HUB into their own system. The HUB system need not perform export and import because the door immediately disperses new mail received from each of the calling NODEs into the HUB's message bases. Thus, each NODE gathers the new mail on its own system, calls the HUB system and passes along its new mail to the HUB, which immediately incorporates it into its own message bases. As each NODE calls the HUB, new messages from each of the other NODES are gathered for the calling NODE, which receives the new collective mail from the HUB and imports the new messages into its own message bases. 2.2 HUB vs NODE Operations. As stated above, the HUB system acts as the central processing center for the mail network. HUB operation involves a few aspects that are not a concern for NODE systems. For instance, the HUB will NOT perform IMPORT and EXPORT as this function is already handled by the HUB Door. THE HUB SYSTEM DOES NOT PERFORM EXPORT OR IMPORT. THESE FUNCTIONS ARE HANDLED AUTOMATICALLY BY NETDOOR. It is also the responsibility of the HUB system to maintain the interface to PCBoard which allows the NODE system to send and receive mail through the HUB. This interface is most commonly a DOOR and it is the responsibility of the HUB to maintain security for the DOOR. It is also the responsibility of the HUB to assign unique conference names to each of the conferences that are to be networked. Since all nodes in the network must follow the naming convention of the conference precisely, the HUB must insure proper communication with each of the NODE systems. Note: When assigning a conference name to a particular conference, the HUB system is assigning a name to be used in the "Conference Name Assigned by HUB" field, NOT the actual filename of the conference. Each system, including the HUB, may define a message base with whatever filename is desired. For instance: the sysops conference might be c:\pcb\sysops\msgs or c:\pcb\conf\sysops etc. There is no restriction placed on naming conventions of conferences by NetMail. All references to the HUB being responsible for assigning a conference name, and a node having to follow that naming convention, refers to the field "Conference Name Assigned by HUB" within the conference configuration portion of NetMail's CONFIG.EXE. This is an 8 character field which is determined by the HUB system to represent the name which will be given to that particular conference. All nodes networking with that HUB must place that 8 character name in the "Conference Name Assigned by HUB" field of their Conference Configuration screen but do NOT need to alter the actual filename of the conference. If you have any doubts as to the understanding of this field, you should contact your HUB system before beginning in order to avoid any possible confusion. On the other hand, NODE operations are somewhat simpler in that NODEs only need to maintain their own message bases and do not need to concern themselves with DOOR operations. 2.3 What is NetMail. NetMail is the special software noted above, that gathers and processes messages bases for use in networking. Contained within NetMail is the complete package required for either NODE and/or HUB operation. HUB operations also make use of the NetDoor system. (Please see NetDoor.doc for further information). Among the special features NetMail has to offer are: * HUB does NOT maintain individual mail files for each conference for each node!! Nodes gather new mail directly from HUB's message bases!! * Node can download ONLY messages addressed to users on the node's system at DOWNLOAD TIME from the HUB! This means that the node needs only spend the time and money to receive its own user's mail rather than downloading large mail packets which may not contain any mail addressed to the node system's users. * Private messages are only imported into node systems which the addressee is registered on WITHOUT the user having to enter their name via a door or any auxilliary process. * Checks for mail addressed to or from unwanted users. * Kills Duplicate Tag Lines. * Kills Duplicate Messages. * Message Threading without need for individual thread files for each conference! * Conferences assigned by NAME rather than by number. No more messages ending up in incorrect conferences due to hubs changing number scheme and/or other configuration mistakes. * Node systems can override "last message exported" field normally maintained by the HUB system, thus enabling node to force re-transmission of messages already received, or if desired, entire message bases. * Sysop can set time frame for availability of HUB Door, allowing users freer access to the HUB BBS. * User can specify max K bytes to receive from HUB and/or max number of messages. No more 2 hour downloads when you're calling long distance! * User can specify max age of messages to receive! No more 3 month old mail! * User can specify whether or not to allow reception of SEND files. Also cuts down on long distance time. * Auto conference configuration loading from either CNAMES or CONFINFO file. * Does not Duplicate Tag lines on Messages passing through HUBS. No more concatonation of multiple tag lines. Only originating system apends tag line! * Trash Can Editing on Imported Mail. Your front-end to obscene or inappropriate language. Automatically replaces specified words with "spaces". Can also delete entire lines based on single word find. Great for deleting tags. * Complete private message handling! User can: - convert outgoing private msgs to public. - convert incoming private msgs to public. - stop outgoing private msgs. - stop incoming private msgs. * No Author intervention required! You get the ENTIRE network package and GO! * Nodelist automatically maintained by Netdoor. Sysop can browse all nodes in network. For each node, displays: - Sysop Name - BBS Code - Tag Line - Hub Indicator - All Conferences Carried at that time. Nodes calling the HUB can request NODELIST through the export command. Netdoor automatically formats and transmits text file containing complete imformation of every node in network! * Report file automatically created by each Import indicates number of messages imported in each conference and % index space used. * HUB can configure for COMPLETELY UNATTENDED network operation! * HUB can configure system to allow new NODE callers without ANY preconfiguration. * NODEs can change conferences carried AT ANY TIME without ANY HUB intervention. * Completely menu driven system. * Extensive concise documentation. * 24 Hour support through Home Dba BBS. * User maintains own tag line. Can change tag line at any time without intervention of author. * Configurable limit on number of imported messages per transfer. Keeps number of new messages from becoming overwhelming. * All features configurable on conference by conference basis. * Can RESET an individual conference or perform mass RESET. * Allows for specification of separate "work" directory which can be RAM disk to greatly speed up operations and performance. * Written in Turbo Pascal 5.0 * HUB can configure system to cross-reference calling NODE against NetMail security file, or if desired, allow new NODES without any intervention required whatsover. * All network activity reported to PCB Caller file. 3.0 Setup. 3.1 HUB Responsibility : Assigning Conference Names. When you execute the conference configuration for the first time, notice that the conference names for each of the conferences correspond to those in your CNAMES or CONFINFO file, depending on which one you had specified in your GLOBAL information screen. These conference names are critical to the proper operation of NetMail as they define to NetMail operations, the name to be associated with the conference message base. For instance, a sysops conference would have the name SYSOPS as the conference name, a hardware/software conference might be named HARDSOFT etc. EACH NODE MUST NAME ITS CORRESPONDING "Conference Name Assigned By HUB" TO THAT OF THE HUB SYSTEM. NOTE: Please note that this does NOT require that a node rename its message base. This field is strictly an internal field used by NetMail. You may name your message bases any filename you like, however, the field "Conference Name Assigned by HUB" within the NetMail Conference Configuration screen for that conference, must match that name given by the HUB system for that conference in its conference configuration. If you have any question as to the proper use of this field, please contact your HUB system, as it can save you many hours of frustration. If a NODE wished to network the sysops conference with the HUB system, that NODE (and all other nodes networking with that HUB) MUST assign the same nmae the HUB system did, to the field "Conference Name Assigned by HUB". If the HUB system used the name "SYSOP" in the "Conference Name Assigned by HUB" field to identify the sysops conference, then all nodes calling that HUB must use the same name in their "Conference Name Assigned by HUB" field. Remember: The node systems do NOT need to rename their actual message bases, they need only insure that they use the same "Conference Name Assigned by HUB" field to represent the conference in their Conference Configuration screen. It is therefore imperative that the HUB system coordinate the naming of conferences with the NODEs that are to make up the network. 3.2 Directories. The first step in setting up NetMail is determining and/or creating the directories in which NetMail will reside. For the sake of order, the author recommends the creation of a separate subdirectory to house the main NetMail executable files. Example: C:\Netmail\ Copy all the files contained in the NetMail ZIP into this main directory or subdirectory. During the course of NetMail's interactive configuration, you will be asked to provide the name of the "work" directory. This directory will act as a scratch directory for Netmail. Other files not related to NetMail will be safe in this directory. Again, for the sake of order you should create a subdirectory off of the main NetMail directory which will serve as the "work" directory. Example: C:\Netmail\work\ THE WORK DIRECTORY MUST BE A COMPLETELY SEPARATE DIRECTORY FROM ANY OTHER NETMAIL DIRECTORY. NetMail ERASES all files in the WORK directory before and after each operation so you must NOT share this directory with any other directory on your system! The exception to creating a subdirectory directly linked with the main NetMail directory is if you have a virtual disk (expanded or extended memory). Since the work directory will be used as a scratch directory, placing it in a virtual disk will greatly enhance NetMail performance as well as decrease the disk fragmentation that is associated with network operations. Finally, you need to create an additional subdirectory which will serve as a holding directory for processed mail. The NetMail configuration prompt refers to this as the FILES subdirectory. THIS DIRECTORY MUST NOT BE CONTAINED ON A VIRTUAL DISK. The recommended subdirectory creation is as follows: Example: C:\Netmail\files\ At this point your subdirectory creation is complete and, if you elected to follow the authors suggested directory configuration, your directory configuration should look something like this: \NETMAIL\ - housing all NetMail executable files. \NETMAIL\WORK\ - scratch subdirectory. (specify a directory on a virtual disk if possible). \NETMAIL\FILES\ - files directory, which will hold files sent to you via the SEND command. 3.3 Option Line Function Keys. With your NetMail directories created, we should take a moment to mention a few items which will help you better understand NetMail execution. 3.3.1 F1 : Pop-Up Help. Pressing F1 at any point in the CONFIG.EXE program will present you with a pop-up help facility. You will be given a menu arranged in alphabetical order by topic from which you may choose any item by moving the highlist bar over that item and pressing <Enter>. You will then be shown a window with the help for the topic chosen which you can scrool both forward and backwards through (when applicable). To leave the help topic screen, press ESC, and you will be returned to the help Main Menu screen. You may choose to select another help item, or press ESC to return to whichever screen you were browsing at the time you requested the help. 3.3.2 F10 : SAVE. When you go through initial configuration, (or whenever you make any subsequent changes to the configuration) you must be aware that NetMail will ONLY save your work after you press the SAVE key (F10). Should you make changes to your configuration or any other component of NetMail without pressing F10 prior to leaving that screen, no information will be saved and you will have to return to that screen and re-enter the information. Please keep this in mind as NetMail was written this way for your protection. 3.3.3 ESCAPE : Abort and/or Exit. By the same token, pressing ESCAPE at any time throughout any configuration or change processing will abort any changes made since the last save. This can come in quite handy as well. 3.3.4 ALT-A : Add an entry. Certain screen items allow you to add an entire entry. You do this by pressing ALT-A. NetMail will then present the appropriate screens to allow additional item entry. 3.3.5 ALT-D : Delete an entry. You may delete an entry in the same fashion that you added one by pressing the ALT-D key combination. As with all important functions, you will be prompted to verify that you wish to delete the entry prior to its deletion. 3.3.6 ALT-U : Universally Update and Entry. While you are in the Conference Configuration Screen, you may find you wish to update a field for all conferences. Rather than having to scroll through each conference individually and update the particular field, you may update that field for all conferences by placing the desired value in the field and pressing the ALT-U key combination. When this is done, the value in the field at which the cursor is placed will be placed in the identical field for all conferences. Note: You will still need to press F10 in order to save any changes made by the ALT-U key function. 3.3.7 PgUp, PgDn, Ctl-Home, Ctl-End, etc. As stated above, NetMail provides complete menu driven screens to help you navigate through configuration, Export, Import and other functions. From certain screens, you have the ability to move up and down through the various items via the UP and DOWN arrow keys located on the numeric keypad. By the same token, the PGUP and PGDN keys allow you to review whole screen entries up or down. You may also jump immediately to the last entry by pressing CTL-END and jump immediately to the first entry by pressing CTL-HOME. If you are on a screen that is showing only one available screen, rather than 1 of many, then the jump and paging keys will be disabled although you will still see the bottom line prompt indicating their function. 4.0 Configuration. Now it is time to execute NetMail and start yourself on the road to networking. After typing CONFIG and hitting enter you will be presented with the opening screen followed by the Config Main Menu. From this menu you may choose any of the Config functions. Select the default function to start: 1) Global. Note: If you are executing NetMail for the first time, or if you have deleted your global.net file, NetMail will automatically present you with the Global information screen. 4.1 Global Items. This is one of the most important configuration screens and you should take your time to insure that you do not make any entries in haste as they affect your entire NetMail operation. 4.1.1 Sysop's Name: Enter your name in this field EXACTLY as it appears in messages to you. (Do not enter "SYSOP" in this field, enter your first and last name as it appears in the PCBoard USERS file). NetMail uses this field to convert your name from "SYSOP" to your actual name when Exporting messages. 4.1.2 BBS Code: Enter a unique identifier in this field. It may be a maximum of 8 characters. NetMail uses this field to identify your BBS within the master BBS data file maintained by the HUB system. Once you enter your BBS Code, you should make every effort to keep that identifier constant as it could amount to overhead for the HUB system if it has to continue to hold mail for a NODE identifier which is no longer being used. You may also find yourself losing mail from the HUB should you change your identifier once you have performed initial mail transfer with the HUB. 4.1.3 USERS File Directory: This is the location (Path Only!) of your PCBoard USERS file. NetMail does NOT read or access your USERS file in any way. NetMail does however read your PCBoard index files (PCBNDX.A, PCBNDX.B, PCBNDX.C, etc.) during the node Import process in order to load your users into memory for incoming private mail checking. NETMAIL DOES NOT READ OR ACCESS YOUR PCBOARD USERS FILE IN ANY WAY. When node import takes place, any incoming private message is crossed referenced against all users in your system. If a private message is encountered which is not addressed to a user on your system, the message will be bypassed by the import process and will not be placed in your message base. NetMail will load up to 25,000 users before proceding with the import function. By using the PCBoard index files for private mail cross references, NetMail insures that the most up to date record of your users are used for private message verification. Also, this process also relieves your users from having to enter their name through any auxilliary process in order to receive private mail. 4.1.4 Work Directory: This directory acts as a "scratch" directory in that NetMail uses it only for the duration of a process and then deletes all the files it placed or created there. For this reason, you may wish to specify a directory on a virtual disk in extended or expanded memory. You will notice a significant increase in performance and will also avoid the usual hard disk fragmentation that accompanies mail processing. If you do specify a virtual disk as your work directory, please insure that the disk has adequate space to hold all mail being Exported or Imported at any single session. Depending on how much mail you expect to Export or Import, this value could vary significantly. This is the ONLY directory for which you may specify a virtual disk. NOTE: If this is your HUB configuration, you must also create separate work directories for each PCBoard node that you will be operating and the directory names MUST be named with the following convention: Work directory name + node number ...for each PCBoard node you will be operating. For instance, if you will be operating 3 PCBoard nodes, and your work directory specified here is C:\NETMAIL\WORK, then you must also create the following directories: C:\NETMAIL\WORK1 C:\NETMAIL\WORK2 C:\NETMAIL\WORK3 Each PCBoard node will have its own work directory in which to process its mail. YOU MUST CREATE A SEPARATE WORK DIRECTORY FOR EACH PCBOARD NODE YOU OPERATE! For this reason, the last qualifier of the work directory must not be greater than 7 characters. For example: C:\NETMAIL\WORK - valid, WORK is 4 chars. C:\NETMAIL\TESTWORK - invalid! TESTWORK is > than 7 chars! 4.1.5 File Directory: This is the directory which NetMail will maintain your more static (permanent) files, such as those being sent to another BBS through the SEND command. Note: As an added precaution, NetMail will NOT allow you to specify the same directory for both your WORK and FILE directories. 4.1.6 Comm Directory: This is the directory where your communications program resides. When NetMail processes your mail, it places Exported mail packets in this directory and looks to this directory for Imported mail packets. Therefore, be sure to download your mail packets into this directory when receiving mail from the HUB. Note: NetMail will verify the existence of all directories and files entered from any prompt on any screen during any process. If the file or directory does not exist, NetMail will reject the entry. 4.1.7 CNAMES / CONFINFO Full Path and Filename. This file indicates the FULL PATH and filename of your PCBoard conference information. Specify either your CNAMES filename, or if running extended conferences via ProDoor, the CONFINFO file location and name. 4.1.8 Is This a HUB Configuration. This field indicates whether or not your system will be acting as the HUB for the network. If you are acting as a HUB and a NODE, you should specify "Y" when executing the HUB configuration from the hub directory and specify "N" then executing the NODE configuration from the NODE directory Note: When set to "N", this field acts as a bypass indicator for other HUB related fields in the GLOBAL configuration. For instance, if "BBS Operating as a HUB" is set to "N", the cursor will pass over "Verify NetDoor Callers" since that field concerns HUB operations. 4.1.9 Do You Operate a Node AND Hub. This field identifies your system as one which operates a HUB, AND a Node. In other words, besides acting as a HUB system, in which you receive calls from your NODEs through NetDoor, you ALSO act as a NODE system yourself, complete with your own separate NODE directory housing separate NetMail files, global.net, conf.net etc., and you call a system as a node, transferring mail through someone else HUB. Normally, when a node performs import, all incoming private messages that are NOT addressed to users on the NODE's system are NOT imported. In this way, only the BBS on which the addressee of the private message is registered receives private message. However, when a node is also acting as a HUB, ALL private messages are imported by the NODE because often times, the incoming private message is addressed to a user on one of HUB system's participating node. If the private message deleted by the node portion of the NODE/HUB operation, then HUB system's participating nodes might never receive the own user's private mail. Therefore, if you are acting as both a Node AND a HUB, specify "Y" in this field. 4.1.10 If Hub, Should NetDoor Verify Callers. If you will be operating as the HUB system, you can specify here that you wish NetDoor to confirm the membership of NODE using NetDoor each time the door is entered. NetDoor will confirm the NODE by cross-referencing that NODE against the entries in the NetMail file BBS.NET. If this verification process is in effect, the HUB must first use the configuration option "BBS Maintenance" to add an entry to BBS.NET for each new NODE joining the network, or the NODE will be denied access to the door. If this option is off, NetDoor automatically enters the new NODE into the BBS.NET file when the NODE calls for the first time. See the NetDoor documentation for further details. Note: The cursor will pass over this field if the "BBS Operating as a HUB" field is set to "N". 4.1.11 Max Age (Days) of Msgs to Export/Import. This number represents how many days old you wish to receive mail from the HUB system. For instance, if you specified a value of 14, The HUB Door would only transmit new messages to you that were 14 days old or younger. Older messages would not be sent to you. If you are a HUB system, this value will prohibit incoming messages that are older in days than the value you specify here. A value of zero indicates NO limit on the age of processed mail. The maximum allowable value here is 120 days. 4.1.12 Accept SEND Files: If you do not wish to receive any SEND files which may be waiting for you on the HUB system, specify "N" here. This option is helpful if you are calling long distance and do not wish your connect time increased due to a SEND file being included in your mail packet. 4.1.13 Max K Bytes to Import: This value represents the limit you wish to place on packet size received from the HUB system. If you are running an unattended transfer and are calling long distance, you may not wish to receive a mail packet greater than a certain size. This option allows you to set the limit on packet size received from the HUB system. A value of zero indicates NO limit on packet size. If you do set a value here, and that value is exceeded, NetDoor will delete the excessively sized mail packet, and create a small "dummy" packet which will not involve any messages and will simply pass through the import function without importing any messages. The next time you call the HUB system, you will receive only new messages from the time of your last call. NetMail will not attempt to send you the same mail packet which exceeded the file size limit during your previous call. 4.1.14 If Hub, Disable NetDoor From: As a HUB you may find that a large volume of NODE calls ties your system up more than you would like. This option lets you disable the NetDoor between particular hours. NODE callers attempting to use NetDoor between the hours you specify will be presented with a message indicating that NetDoor is disabled and will be shown the hours you specify here. The initial default time specification is 00:00 to 00:00. NetDoor will ignore these settings, and will perform the time check ONLY if either the FROM HOUR or FROM MINUTE is non-zero. You must specify the desired time in "military" time. for example, 4:30 P.M. would be denoted as 16:30. The format of the entries are: From Hour From Minute To Hour To Minute If you wished to disable NetDoor from 9:00 A.M. to 9:00 P.M., you would make the following entries: 9:00 to 21:00 In order to remove the non-availability specification, you must re-enter the GLOBAL configuration screen and place 00:00 in the FROM time parameter. Note: The cursor will pass over these fields if the "BBS Operating as a HUB" field is set to "N". 4.1.15 Tag Line: This is where you indicate how you would like your tag line to appear. The tag line is added to the end of each message Exported through NetMail unless you specifically indicate that you do not wish a tag line to accompany your Exported mail. (This is covered in the upcoming section on conference specific configuration). As a minimum, you should include your BBS name, location and number. 4.2 Conference Items. The Global information allowed you to specify information universal to the entire operation of NetMail. The Conference information, on the other hand, allows you to specify parameters unique to each conference your system networks. When you complete the global information screen for the first time, NetMail loads the conference information table with the contents of either your CNAMES or CONFINFO file, depending on which one you specified during global configuration. You may scroll through the entries using the keys defined above (up/down arrows, PGUP/PGDN, CTL-HOME, CTL-END, ALT-A, ALT-D, ALT-U etc) to update each conference's own unique information. 4.2.1 Conference Name Assigned by HUB: At the time of initial conference load, this will be the name you assigned to the conference using PCBSETUP. However, because NetMail keys on the conference name to coordinate message handling with the HUB system, it is IMPERATIVE that you use the EXACT same name for this entry as the HUB system. Failure to do so will result in your failure to receive or transmit that conference. THE "CONFERENCE NAME ASSIGNED BY HUB" FIELD MUST MATCH THE NAME ASSIGNED TO THE CONFERENCE BY THE HUB SYSTEM OR YOU WILL NOT SEND OR RECEIVE MESSAGES IN THAT CONFERENCE. You MUST coordinate the naming of your conferences in this field with the HUB system. If you are operating as a NODE and a HUB as well, you must, from your NODE directory, designate the same conference names as that used by the HUB. When you configure your HUB system from within your HUB directory, you are free to name the conferences any name you like, but you are also responsible for communicating your conference names to your own nodes. THIS CONDITION APPLIES TO THE "CONFERENCE NAME ASSIGNED BY HUB". YOU DO NOT NEED TO CHANGE YOUR ACTUAL CONFERENCE FILENAMES, NOR DO YOU NEED TO CHANGE YOUR PCBSETUP CONFIGURATION OR CNAMES/CONFINFO FILE. Once NetMail has loaded the CNAMES or CONFINFO file, you may chnage the conference name from the one loaded, to any name you like to suit your (or your HUB's) networking naming conventions. THIS IS ONE OF THE MOST IMPORTANT FIELDS WITHIN THE NETMAIL SYSTEM. IF YOU HAVE ANY DOUBTS AS TO ITS FUNCTION, PURPOSE ETC, PLEASE CONTACT YOUR HUB SYSOP, OR CALL HOME DBA BBS (206) 789-9302 (WASEA) AND ASK ME! As an additional precaution, NetMail checks all other conference name entries against the name you enter in this field to insure that the name does not duplicate an existing entry. If it does, NetMail will display an error message and reject the entry. 4.2.2 Conference Filename: This is the fully qualified filename of the message base for the conference. Although this field is initialized during the initial configuration process, should the location or filename of the conference change, all you need do is alter this entry. As an additional precaution, NetMail checks all other conference Filename entries against the name you enter in this field to insure that the name does not duplicate an existing entry. If it does, NetMail will display an error message and reject the entry. 4.2.3 Last Msg Processed: NetMail keeps track of the last message number it has imported within a conference via this field. It is very important that you do not alter this field unless you fully understand the implications involved. NOTE: DO NOT ALTER THIS FIELD UNLESS YOU FULLY UNDERSTAND THE IMPLICATIONS INVOLVED! When you alter this field, (and there are legitimate reasons for doing so), you are telling NetMail that you wish to resume processing from a message number in that conference other than the one last processed. For example: If you have already exported messages up through message number 1000 in a conference and wish to re-send messages into the network that have already been sent, you would set this field to the message number which you wish the next export function to begin retrieval of messages with. If you wanted to export all messages following message #500, you would place the number 500 in this field. The problem with altering this field of course if that you will be sending mail that has already been transmitted into the network. While it is true that NetMail's import function will not allow duplicate messages into the system, it is possible that on other systems, messages already received have been killed and the conference packed, therefore completely erasing the message from the base. NetMail's import function would now have no way of knowing the message had already been imported on that system, which would result in a form of duplicate message. If you do alter this field, NetMail will check the value you enter to insure that it does not exceed the range of the highest and the lowest message number currently on the message base. If the value you enter is greater than the highest message number, the highest message number in the message base will be placed in place of the value you entered. The same holds true for entering a value lower than the lowest message number on the message base except that the value you entered is then replaced by the lowest message number in that message base. This field can NOT be universally updated across all conferences via the ALT-U key sequence. 4.2.4 Network Messages in this Conference: This field indicates whether you wish this conference to be networked. You need to specify "Y" in this field in order to network the conference as the default value is "N". You can make ALL conferences available for networking by placing a "Y" in this field and pressing the ALT-U key which will perform universal updating of this field for all conferences. Be sure to press F10 to save your updates. 4.2.5 Max Messages Per Import: This allows you to limit the number of incoming messages for this conference. This can serve to keep your conference from becoming so full so fast that you and your callers cannot keep up with it. It can also serve the function of safety valve in that should some configuration error occur or should a BBS with massive message activity join the network, your conference will not be overrun with messages. PLEASE NOTE THAT THE FOLLOWING PRIVATE MESSAGE, AND ECHO INDICATORS APPLY ONLY TO NODE SYSTEMS. HUB SYSTEMS WILL HAVE NO CONTROL OVER PRIVATE MESSAGE EDITING AT IMPORT OR EXPORT TIME. This is necessary to insure that messages remain intact in the form they were written, through the networks, and finally arrive at the node systems in their original form. The node systems may then set the following indicators to specify how they wish private messages to be handled. You may use the ALT-U key to update this field across all conferences. 4.2.6 Stop Incoming Private Msgs: This field allows you to indicate whether you wish private messages to be stopped upon import. If set to "Y", no INCOMING private messages will be allowed into your message base. Note: Messages TO and FROM the sysop will NEVER have any restrictions placed on them for ANY of the private message handling functions. You may use the ALT-U key to update this field across all conferences. 4.2.7 Stop Outgoing Private Msgs: This field allows you to indicate whether you wish private messages to be stopped upon export. If set to "Y", no OUTGOING private messages will be allowed out of your message base. You may use the ALT-U key to update this field across all conferences. 4.2.8 Convert Incoming Private Msgs: This field allows you to indicate whether you wish private messages to be converted to public messages upon Import. If set to "Y", all private mail (except that addressed to you, the Sysop), will be converted to public. You may use the ALT-U key to update this field across all conferences. 4.2.9 Convert Outgoing Private Msgs: This field allows you to indicate whether you wish private messages to be converted to public messages upon Export. If set to "Y", all private mail (except that from you, the Sysop), will be converted to public. You may use the ALT-U key to update this field across all conferences. CAUTION: You may wish to familiarize yourself with any laws concerning the rights and limitations or private message handling by electronic bulletin board systems prior to manipulating the above private message handling options. 4.2.10 Convert Outgoing Msgs to "Echo=Yes": You may specify that the export function set all outgoing message's echo flag to the "ON" setting by specifying "Y" to this prompt. This can be useful in instances where other network mail systems are used in conjunction with NetMail, as other systems may look exclusively for the echo flag to be set in order to network the message. 4.2.11 Network Only "Echo=Yes" Messages: This field allows you to specify that only messages created with the PCBoard Echo Flag set to "Y" will be exported. This function applies to node exported messages only! You may use the ALT-U key to update this field across all conferences. When a user enters a message, they are prompted, whether by PCBoard, or by ProDoor, as to whether they wish the message to be "echoed", (networked). If they respond "Y", The message is saved with an "Echo Indicator" set to indicate that the message is available to be echoed. If they respond "N" to the echo prompt, the message is still saved, but the echo indicator is not set. If set the conference "Echo Only Echo=Yes Messages" to "Y" in the NetMail Conference Configuration Screen, messages indicated by the user as "Echo=Yes" will be read and networked by NetMail, however, messages written by those users specifying "N" to the PCBoard echo prompt will not be exported. This function allows your users to write messages and be assured that their messages do not get distributed throughout your network. NOTE: Please bear in mind that with this option set to "Y", ONLY messages written with "Y" in response to the PCBoard echo prompt will be networked. As a Sysop, should you use this function, you should advise your users that this function is in effect and that should they wish their messages networked, they should be sure to respond "Y" to the PCBoard (or ProDoor) echo prompt. NOTE: With this option in effect, it is vital that you set the PCBSETUP or PROSM Conference Echo flag to "Y" for each conference you are networking through NetMail. If you fail to do this, your users will NOT be prompted as to whether they wish the message they are entering to be echoed, and subsequently, the message will not have its echo flag set by PCBoard or ProDoor! Thus, when NetMail reads the message during export, the echo indicator will be absent and the message will NOT be exported. Since this flag applies to imported messages as well, it is the responsibility of every Sysop in the Network to insure that the PCBSETUP or PROSM echo conference indicator is set. Otherwise, messages without the PCBoard echo indicator will not be brought into your system upon import. 4.2.12 Supress Tag on Outgoing Messages: This field indicates whether you wish NetMail to add the tag line specified in the global information to outgoing messages. If you wish to supress the tag line, indicate so here by entering "Y". It should be noted here that NetMail will only append a NetMail tag line to an original message regardless of this value. In other words, if a message originates on system "A", and passes through system "B", and on to another system, system "B"'s NetMail will recognize the existence of a previous NetMail tagline and will not append "B"'s tag. You may use the ALT-U key to update this field across all conferences. Please remember that the information entered in the conference specific configuration area applies to that particular conference ONLY and that you will need to enter conference specific information for each conference you wish to echo through the network. Please also remember that all the information you enter for all the conferences will not amount to anything if you do not SAVE your information prior to leaving the Conference Configuration Area by pressing F10. It is worth noting that should you decide at some future date that you wish to eliminate or add a conference to those being networked, you need not coordinate your change with the HUB system. This is because NetMail automatically updates your conference configuration information on the HUB system each time you perform a mail transfer. The update is transparent to you as well as the Sysop of the HUB system. We should touch on the Alt-A and Alt-D functions at this point again. If you remove a conference from PCBoard that you had been networking, you will want to delete the conference from NetMail's conference information file. To do this, you can delete CONF.NET which contains all the information you entered for ALL the conferences (not recommended...) or you can use the ALT-D command to remove that single conference from the CONF.NET file. (highly recommended...). To do this, enter the conference maintenance screen as you did before from the Configuration Menu screen, and page through the entries until you arrive at the conference entry corresponding to the conference you wish to delete. At that point, press ALT-D. You will be presented with a delete confirmation prompt. When you are SURE you wish to delete the conference, confirm by pressing "Y". You will then be returned to the conference menu. The entry WILL NOT have been physically deleted however. To permanently delete this entry you must (all together now...) PRESS F10 TO SAVE! Should you at some time wish to add a conference to the conference information file because you have added a new conference to PCBoard that you wish to network, enter the conference maintenance screen once more and press ALT-A. You will be asked to provide the same conference information as you did for the other conferences at initial configuration time. When you have completed this, you will be returned to the conference maintenance screen where you can complete the conference entry information. Again, this entry WILL NOT be saved unless you press F10 prior to leaving the conference maintenance screen. Please note that initial conference definition and subsequent conference adding via the ALT-A key sequence, induces the RESET function to automatically set the last message number processed within NetMail's conference information file to the current high message number in that conference. This was added to avoid massive initial mail packets from entering the network from new NODES or conferences. Thus, all NEW mail entered from the point of conference definition is networked. 4.3 Creating a New Conference File. If you find yourself totally revamping your conference configuration in PCBoard that you estimate it would take less time to simply reload a new conference information file and complete the conference information for each networked conference, you may do so by selecting the third item from the Configuration Menu: Creating a New Conference File. After selecting this item, NetMail will load a new conference information file based on the information contained in your GLOBAL record. You may then proceed to update this information accordingly, keeping in mind that you must save the new file using F10 or your old file information will remain intact. Once you have entered all the pertinent information for all the conferences and have saved it by pressing F10, you are ready to proceed with other (optional) NetMail operation items. You have now completed the mandatory configuration of NetMail. 4.4 Edit/Create Trash Can File. NetMail offers you the opportunity to replace individual words or letters (if that is your inclination) with blanks. This is ideal for Sysops who may feel they need to watch over the language being used on their system. In order to use NetMail's Trash Can editing function, you must create a text file called TCAN.NET. In this file, you will place one word per line. These words need not be in upper or lower case. NetMail will search for the word CASE INSENSITIVE. You are allowed a maximum of 10 words, and each word may be up to 25 letters in length. TCAN.NET MUST BE PLACED IN YOUR NETMAIL DIRECTORY, THAT IS, THE SAME DIRECTORY HOUSING IMPORT.EXE. NetMail searches for the file TCAN.NET when performing the Import function. If found, it will be loaded into an internal table and be used to search each incoming message. If you do not wish this editing to take place on incoming messages, either delete TCAN.NET from the \NETMAIL executable directory, or move it to another directory where Import will not find it during import processing. When IMPORT finds a word in an incoming message that you had specified in TCAN.NET, that word is replaced with SPACES before being imported into your message base. 4.5 RESET. When you pack a PCBoard message base and specify that you wish the messages to be re-numbered, you uncalibrate the message number information maintained by NetMail and you must then perform the RESET function in order to recalibrate this information. Failure to do so on your part will result in NetMail's mishandling of your outgoing and incoming mail. Simply performing a message base pack has no adverse effect on NetMail processing. It is only when the message numbers are re-numbered by the pack process that NetMail needs to RESET the conference message number information for each conference that had its messages re-numbered. There are 2 means of resetting conference message number statistics in the NetMail conference information file. You may RESET all of the conference message values at once or RESET only a single conference information entry. To perform mass RESET, simply select the RESET function from the NetMail Main Menu. After confirming your desire to RESET, NetMail will update its message number information for all participating conferences while you wait. NOTE: If you are networking your MAIN PCBOARD MSGS file (as opposed to one of your conference message bases), ALL PCBoard NODES must be at the DOS prompt when performing RESET on the MSGS file. Attempts to RESET the MAIN PCBOARD MSGS file while any PCBoard node is NOT at the DOS prompt will result in a SHARE violation. Should you only need to RESET a single conference message entry, (after re-numbering a single conference), proceed to the Conference Maintenance screen by selecting the appropriate entry from the Configuration Menu. Scroll through the entries using the PgUp and PgDn keys until you arrive at the conference entry you wish to reset. At this point, press ALT-R and respond "Y" to the confirmation prompt. NetMail will then update the conference information with the proper message number. (Remember to SAVE the update with F10). The most effective approach to re-numbering your message bases is to perform the pack and re-number IMMEDIATELY following IMPORT. Follow this by IMMEDIATELY performing RESET on the re-numbered conference(s). 4.6 SEND. Another of NetMail's features is the ability to send a file or files to another participating NODE (or HUB) in the Network. This has the advantage of eliminating the necessity of calling the NODE you wish to send the file to. The file can be of any nature. To SEND a file to another system, execute the SEND.EXE program provide with the NetMail system. You will be presented with a prompt asking for the filename you wish to send. Respond with the COMPLETE path and filename of the file you wish to send. If NetMail cannot find the file, it will reject your entry. Having entered the filename and having been accepted, you will then be prompted for the BBS-Code of the system you wish to send the file to. Note: The BBS-Code you specify MUST be identical to that which the sysop of the target system designated during his/her Global information configuration. If it does not match precisely, your file will never arrive at its destination. Having entered in the BBS-Code for the system you wish to send the file you may enter yet another BBS-Code should you desire to send the file to more than 1 BBS. You may enter up to 50 different target systems for each file you wish to send. You may send an unlimited number of files. Once you complete your file entries, save your requests using the F10 key. SEND will then compress the designated file into a file under the name <BBS-Code>.FIL where BBS-Code is the 1 to 8 character BBS identifier you specified at Global information configuration. When NetMail performs its next Export, it will gather this file and include it in its BBS-Code.OUT final Export packet. 4.6.1 Receiving Files from other Systems. When Import is executed, NetMail recognizes the presence of any files which were sent to you and places them in the FILES directory you specified during Global Information Configuration. 4.6.2 Differences between NODE and HUB SEND. Just as there were differences between NODE and HUB Export and Import functions, so there are differences with the SEND function as well. These differences center around the same factor as before - that the HUB needn't call a system to deliver its mail and SEND files. Once initiated, the HUB system gathers the files to SEND and immediately places them (along with the rest of the mail awaiting each participating NODE) in the FILES directory. 4.6.3 SENDing a file to ALL NODES in a network. When you SEND a file, you can SEND the file to a single target NODE, several NODEs, or ALL NODEs in the network. To SEND a file to ALL NODEs in the network, specify "ALL" when prompted for the BBS Code of the target BBS from the SEND menu. Specifying "ALL" overrides all other BBS Code entries for the file being sent and you are immediately prompted to confirm your SEND file command. Following confirmation, the file is gathered and, if your are a HUB system, the file is immediately ZIPped into the appropriate <BBS-CODE.FIL> file in the FILES directory where it will reside until the target BBS system calls. If you are a NODE, NetMail will gather the file being sent, and ZIP it, along with the file <TIME STAMP.SND>, into your FILES directory under the name <BBS-CODE.FIL> where it will reside until you perform your next Export. 4.7 BBS Maintenance. The BBS Maintenance function is reserved for HUB systems only. When you enter the BBS Maintenance function, NetMail recognizes your HUB/NODE status and displays an error message if you are not defined as a HUB. The reason for the exclusive HUB access is that the BBS.NET file maintained by the BBS Maintenance function is only created when NetMail determines that the system begin configured is a HUB system. The BBS.NET file is used to store and cross-reference information about nodes calling the NetDoor. The BBS record for the HUB system is created at the time the conference information is initially created and is updated each time the conference information is updated. The HUB record is always record #1. THE HUB RECORD WILL ALWAYS REGISTER ZERO IN THE MESSAGE NUMBERS WHEN VIEWED ON THE BBS MAINTENANCE SCREEN Please note that because the HUB system does not call any other HUBs (except when acting as a node AND a hub in which case the node networking functions are handled from the separate node NetMail directory), you will notice that the message number indications for the HUB record will ALWAYS register as zero. If you are operating as a HUB sysop, you have the option of configuring NetDoor to cross-reference all new NODE callers through a master BBS list which NetMail and NetDoor maintain called BBS.NET. This cross reference check is an added security feature that verifies the NODE caller even though you have already provided the NODE with adequate security to enter the NetDoor via the PCBSetup DOOR security setup. With this option, NetDoor will not allow access of any NEW NODE (A NODE entering the door for the first time) if the NODE information is not found on the BBS.NET file. To add a BBS to the BBS.NET file, enter the BBS Maintenance function by pressing the appropriate number from the Configuration Menu. You will then be presented with the BBS Maintenance screen and your own BBS record will be presented. You may then press ALT-A to add an additional BBS to the BBS.NET file. You will be prompted to enter the 1 to 8 character BBS-Code uniquely identifying the BBS you wish to add. Once added, you may continue to add or in the same fashion, delete BBS codes. Deleting a BBS Code from BBS.NET effectively removes that BBS from the network. That BBS will no longer receive mail and if the NetDoor security function is in effect, that BBS will no longer be granted access to NetDoor processing. Note: NetDoor determines the identity of the NODE caller after receiving the mail packet from the NODE. No processing of the mail packet takes place until the NODE caller is identified and, where appropriate, verified against the BBS.NET file. 4.8 HUB Creation of NODELIST Text File. NODE systems may request a text file list of all NODES participating in the HUB's system through the NODELIST parameter passed to the export.exe program. The HUB system may also generate a text file containing the complete NODE information for each NODE in the HUB system. This is done via the NODELIST creation option from the config.exe program. When the Nodelist creation option is selected, NetMail generates the same text file that is created for calling nodes requesting the nodelist text through the export parameter. The file called "NODELIST" will be generated in the current NetMail directory. The HUB system may now rename the NODELIST file to a suitable bulletin name and post the text file as a PCBoard bulletin notifying the network nodes as well as prospective callers of the identity of each node and various pieces of information about each node such as the Sysop's Name, the BBS Code, the Tag Line, and a listing of all conferences currently by that BBS. This information is repeated for each node in the network. 4.9 Creation of Miscellaneous Text Files. You may create text files of your GLOBAL and CONFERENCE configuration for general browsing or to post on your BBS as a bulletin, or to use in debugging, by using this option. When selected, two text files by the name of GLOBAL.TXT and CONF.TXT are created in your NetMail directory. These files will contain the sum information of your Global and Conference information files in text readable format. 5.0 Running NetMail. You have now configured your system to identify your BBS, whether you are operating as a HUB or a NODE, which conferences you are carrying and how you wish mail to be processed for those conferences, and have selected various other configuration options that identify particular words or phrases to be deleted upon import, and other parameters which uniquely define your system's operation. If you are operating a HUB system, you should also completely familiarize yourself with the door operation of NetDoor, but for now, you are ready to begin what will be your regular network operations. 5.1 EXPORT. 5.1.1 What is Exporting. Exporting is the term applied to the process of gathering new messages from each of the conference message bases you wish to network and transfering them to the HUB system where the HUB can distribute your mail to all of the other participating NODEs. You are now ready to perform your first EXPORT. NOTE: NetMail will not permit HUB systems to perform EXPORT as this function is automatically performed on the HUB's behalf by NetDoor. To execute Export, simply type EXPORT from the DOS prompt. MetMail takes complete control from this point, using the information it finds in the various files created as a result of the configuration process. 5.1.2 Differences Between HUB and NODE Export. The Export function is performed ONLY by the NODE system. NetMail 2.0 relieves the HUB system of the necessity of performing Export and Import as these functions are performed by the NetDoor. The distribution of mail to the participating NODEs is transparent to both the HUB and NODE user and is presented here for informational purposes only. 5.1.3 What Export Does. With all the buzzing that goes on during the Export function, the author felt it would be conforting to know a little more about what exactly was going on during all the commotion. When NetMail has confirmed that the vital information files (containing such information as where each of the conferences resides and whether or not each is to be networked etc.) exist and are valid, the Export processing proceeds into the actual gathering of messages. If you are defined to NetMail as operating solely as a Node, NetMail loads an internal table with the entire user base of your system. (Not the actual names, but a numeric representation). The file created by this process is called <BBSCODE>.USR where BBSCODE is the BBS Code field you entered in the global configuration. This is done so that (for nodes only) any private messages addressed to users NOT registered on the node's system, do not get imported to the node. Processing then continues... For each conference found in the conference information file, NetMail reads through the message base if it is to be networked and (based on various criteria associated with private mail processing and amount of mail to process,) edits the outgoing mail and writes each Exported message to a holding file in the WORK directory. Other processing such as appending the tag line to each outgoing message (if appropriate) and converting the sysop's name from "SYSOP" to his/her actual name also occurs. When all the messages for all of the conferences to be networked are processed, NetMail checks to see if any data sets have been previously gathered by the SEND function, and if so, compresses the data sets, along with the outgoing mail, into a single data set and places that data set in the user's communication directory. At this point, NetMail erases the files it created or stored in the work directory, and removes any files associated with the SEND function. 5.1.4 What Must Be Done Following Export. With the Export function complete, the task of transferring the newly gathered mail to the HUB remains. At this point, it is up to the NODE, (See Sample Batch Files) to deliver the mail packet to the HUB system, retrieve its new mail from the HUB and return to NetMail in order to perform Import. The output file created by the Export process will be named with the following convention: <BBS-Code>.OUT where BBS-Code is the 1 to 8 character specified during the Global Configuration process. After calling the HUB system, the NODE would then open the DOOR used to house the NetDoor system. The NetDoor system will begin by telling you it is ready to receive your mail. At that point you must UPLOAD your <BBS-Code>.OUT file to the HUB using Zmodem file transfer. Note: You MUST use Zmodem file transfer when using the NetDoor Door. After recieving your mail upload, NetDoor will gather your mail and place it in a file called <BBS-Code>.IN and immediately begin sending it to you. Download the file into your communications directory. Note: You MUST download <BBS-Code>.IN into your communications directory as NetMail will search there for the file to Import and will not Import without finding it there. During the time you are in NetDoor, you will be kept informed as to the progress of your "visit" and when finished with both the reception and delivery of your mail, you will be returned to the HUB system's main PCBoard prompt. At this point you may log off or, if you wish, remain on the HUB BBS for other business. At this point, you need only to execute the NetMail Import function in order to complete a full mail transfer cycle. 5.1.5 Requesting a NODELIST from the HUB. When you perform export, you may add a parameter to the export command line requesting the HUB system to automatically format a text file containing a list of all NODEs in the network. To do this, type EXPORT NODELIST <Enter> rather than just Export <Enter>. Example: EXPORT NODELIST <Enter> NOTE: If you are executing other export command line parameters, you may specify the parameters in any desired order. Example: EXPORT NODELIST OVERRIDE <Enter> Example: EXPORT OVERRIDE NODELIST <Enter> (See 5.1.6: Re-Receiving Messages Already Received From HUB); When you import the subsequent mail packet received from the HUB system, NetMail will place the nodelist file in your FILES directory indicated at GLOBAL configuration. You may then use this file as a PCBoard bulletin or simply browse the file for your own information. 5.1.6 Re-Receiving Messages Already Received from HUB. When a node makes its initial call to the HUB system, the NetDoor program insures that the initial mail packet sent to the node is not an overwhelming one, by first setting the "Last Message Number Exported" field within the HUB's BBS.NET for the calling node, to the highest message number in each conference networked. In this way, only subsequent messages left or imported on the HUB system will be sent to the calling node. For instance, if a new node calls the HUB system and is carrying the SYSOPS conference, the HUB system will set the calling node's record for that conference to the highest message number in the conference at that time. If the highest message number is 100, that value is stored in the calling node's record. Only messages left beyond message 100 in the SYSOPS conference will be networked to the calling node upon subsequent calls. It is for this reason that initial node calls to the HUB system result in 0 messages being exported to the node on the first call. Only messages left subsequent to the initial call to the HUB are networked to the node. Each time the node calls the HUB and receives new mail in a particular conference, the last message number sent to the node is stored by NetDoor in the HUB system's BBS.NET file for that node. This is how NetDoor keeps track of which nodes have received which messages in each conference. Normally, the node plays no part in maintaining this "last message number exported" value. The HUB system keeps track of all nodes' last received message number. However, there may arise, occasions in which the node wishes to OVERRIDE the existing "last received message number" field maintained on the HUB system for a particular conference or ALL conferences. For instance, the node calling the HUB system for the first time, may wish to receive the entire message base of a conference or conferences in order to immediately propogate his/her conference message base with the entire message base(s) of the HUB. Another use for this function might be to re-receive mail already received in the past, perhaps to restore from messages that were inadvertantly killed or purged during a message base repack. Whatever your reason, the OVERRIDE function of the export.exe program will allow you to override any conference "last message exported" value maintained on the HUB system for your node. The conference override function is initiated by the use of the command line parameter "OVERRIDE" when executing the EXPORT.EXE program. example: EXPORT OVERRIDE <Enter> When the export program receives this command line parameter, it presents you (after first gathering your outgoing mail....) with the Conference Override Menu screen. The Conference Override Menu screen allows you to specify, on a conference by conference basis, each and all conferences for which you wish to set new "last message exported" values. You will receive a series of 2 prompts. 1) Conference Name To Override: This is the "Conference Name Set by HUB" of the conference you wish to set the override for. Enter the 1 - 8 position conference name in this field and hit <Enter>. Export will validate the conference name you enter into this field on 2 criteria. The conference name you enter MUST match exactly, the conference name specified in your Conference Configuration under the name "Conference Name Assigned By HUB". The second criteria is that the Network indicator for the conference you enter MUST be set to "Y". In other words, you must have defined the conference in your Conference Configuration screen, AND you must be currently networking that conference with the HUB, (as indicated by the "Network Indicator" set to "Y".). If either of these two criteria are NOT met, you will receive a "BEEP" and the cursor will be placed back at the Conference Name prompt. 2) "Number of Messages to Retrieve": This field allows you to specify the number of messages (counting backwards from the last message you received from the hub) you wish to receive. For instance: If you had called your hub for the first time and therefore been given no messages in a conference. you could perform an export with the OVERRIDE parameter and specify that you wished to receive the last 25 messages in that conference by entering the value 25 when prompted by the override function. The next time you transferred mail with the hub, you would receive the previous 25 messages from the last message number you had received before, as well as any new messages left in the conference since your previous call. You need not worry about entering a value that is greater than the existing number of messages in the HUB system's conference message base. If you do, NetDoor will simply place the message base's low message number in its place and you will receive the entire message base. You will continue to receive these prompts until you press either Escape or F10. ESCAPE: Pressing the ESC key will ABORT all entries you had made during this session and the export process will continue as normal. F10: Pressing F10 after finishing a complete cycle (that is, after entering a conference name(s) AND an overriding number), will save the values you have entered and pass the overrides along to the HUB system for processing when you call through the NetDoor. If you are also requesting a NODELIST file from the HUB system through the EXPORT command line parameter: NODELIST, you may still do so even if processing OVERRIDEs. The order of command line parameters is not significant. You may execute the command line parameters in any order: Example: EXPORT NODELIST OVERRIDE <Enter> EXPORT OVERRIDE NODELIST <Enter> NOTE: Unlike the NODELIST command line parameter, OVERRIDE is an interactive function requiring you to respond to the prompts presented by EXPORT. You may NOT use the OVERRIDE parameter as part of a batch file. If you use the OVERRIDE parameter as part of your batch file, your system will wait at the OVERRIDE prompt until you return! 5.1.7 Re-Receiving Your Last Mail Packet. There are times when you may need to re-request your entire mail packet from your hub system. Aborted file transfers, bad clusters, or other reasons may prompt you to require the last successful mail packet over again. This is handled for you automatically by the hub system's NetDoor. Each time you call the hub system to transfer your mail packet, you will be prompted by the NetDoor as to whether you wish to receive your last mail run's packet. You will be given approximately 10 seconds to respond to this prompt before processing continues (the default is "NO") in case you are calling from an automated batch file; therefore you will need to be present in order to request the resending of the packet. If you do respond "Y", NetDoor will gather your last mail packet and add to it any additional messages that may have been left in the interim period. 5.1.8 PCB Caller Log Tracking of Export Activity. You may direct all export activity to your PCBoard Caller Log if desired. This is an optional feature of the export process, and is not required for proper execution. If specified on the export command line, logging will take occur on the caller log specified. Export will log the time and date of the export, and a conference by conference listing of number of messages exported. This function is especially useful for those running NetStat, the NetMail Statistics and Report Generator (available to registered users only). To specify that you wish caller log recording of export activity, simply indicate the full path and filename of the caller log you with export activity to be reported to: Example: EXPORT C:\PCB\GEN\CALLER1 YOU MUST SPECIFY YOUR PCB CALLER LOG AS THE 1ST PARAMETER IF YOU WISH LOGGING TO OCCUR. You may specify the other available export options in any order following the caller log specification, but they MUST occur after the caller log parameter if the caller log parameter is specified. 5.2 IMPORT. NOTE: NetMail will not permit HUB systems to perform IMPORT as this function is automatically performed on the HUB's behalf by NetDoor. When you complete your business with the HUB system, you need to return to NetMail and execute the Import function in order to disperse your new mail into the appropriate conferences. When you perform the Import, NetMail performs very much the opposite functions it performed to Export your mail. During the Import process, NetMail will report on the number of messages received in each conference and also report on the updated size of your message base index file for each conference. This report can be found following Import, in your NetMail mail executable directory under the name REPORT.NET. This file is created automatically by NetMail and overwritten with each Import. It contains the current date and time as well as the conference message information described above. Import also performs several of the edits that Export performed with regards to private message handling and updating message numbers within the conference information file. Import also performs the Trash Can Word replacement on all Imported messages if it finds the Trash Can file TCAN.NET in the mail NetMail executable directory. 5.2.1 Duplicate Message Handling. From time to time, configuration or processing errors result in duplicate messages being entered into the network mail system. NetMail detects duplicate messages during the Import function and does not process them. 5.2.2 Message Threading. (Refer To:). NetMail maintains message threading on all messages networked to all NODEs. This means that messages responded to on a NODE system other than the one which the message originated will still have the proper message number in the "Refer To:" field upon its return to the originating BBS. For example, let's take 2 BBSes, NODE "A" and NODE "B": 1) Message 100 is written on NODE "A". 2) Message 100 is Exported. 3) NODE "B" Imports the message, where it becomes Message 500. 4) A user on NODE "B" responds to message 500. (What was originally Message 100 on NODE "A"...) 5) NODE "B" Exports the response to its Message 500. 6) NODE "A" Imports the response to its original Message 100. 7) The incoming response is given a new messaage number and the "Refer To:" field contains the Message number 100. 5.2.3 PCB Caller Log Tracking of Import Activity. You may direct all import activity to your PCBoard Caller Log if desired. This is an optional feature of the import process, and is not required for proper execution. If specified on the import command line, logging will take occur on the caller log specified. Import will log the time and date of the import, and a conference by conference listing of number of messages imported. This function is especially useful for those running NetStat, the NetMail Statistics and Report Generator (available to registered users only). To specify that you wish caller log recording of import activity, simply indicate the full path and filename of the caller log you with import activity to be reported to: Example: IMPORT C:\PCB\GEN\CALLER1 YOU MUST SPECIFY YOUR PCB CALLER LOG AS THE 1ST PARAMETER IF YOU WISH LOGGING TO OCCUR. You may specify the other available import options in any order following the caller log specification, but they MUST occur after the caller log parameter if the caller log parameter is specified. 5.2.4 Skipping Messages To and From Certain Users. With NetMail, you have the ability to block mail addressed to certain users. For instance, if you operate a system which is regularly receiving mail from a user by the name of BATMAN. You may specify that import processing check for and delete any incoming messages addressed to or from "BATMAN" by created a text file called NAMES.NET and placing it in your NetMail directory, that is, the directory housing IMPORT.EXE. NAMES.NET can support up to 100 names, each up to 25 characters in length. You may only specify 1 name per line of text. When Import processing begins, Import will check for the existence of NAMES.NET and load any and all entries contained in it. Any messages found to be addressed to or from any of the names in NAMES.NET will be discarded prior to import into your system. To remove this function, either delete NAMES.NET, or place the file in another directory, where import processing cannot find it. 5.2.5 Removing Excessive Tag Lines on Imports. With the growth of various networks has come the problem of multiple tag lines being appended to a single message passing through a series of networks. It is not uncommon to see a message of 2 or 3 lines containing TAG lines amounting to 10 or 15 lines. Given the size of an average tag, it would not be uncommon for a system of 40 conferences, each with 200 messages, to require 2 MEGABYTES OR MORE!...just to support additonal tag lines!! NetMail brings messages with multiple tag lines under control by allowing you to specify that only the 1st tag line appended to a message is to remain on the message as it enters your system. To specify this, create a text file called TAGS.NET. In this text file, specify the PREFIX! of all the tags you commonly find on your incoming messages. The reason you should specify the prefix of the tag instead of the entire tag is two-fold. First, specifying an entire tag line would greatly increase the search time required to verify the existence of the specified tag in each incoming message. Second, since all but the first several characters of any tag line are configurable by the sysop, you would require a nearly endless supply of tag specifications to catch them all. Therefore, specify ONLY what is required to ABSOLUTELY identify the tag you wish to check for. Be warned however, against specifying TOO short a tag prefix. If you specifying too short a tag, for instance, "NE" when you wished to specify NET/Mail, you would run the risk of deleting part of a message that had the word NEVER, or NEED, etc... Incorrectly specifying a tag prefix in TAGS.NET will not damage your system or message base in any way, except to make for some pretty cryptic messages...! You may specify up to 10 tag prefixes. Each prefix may be up to 25 characters in length. You should use your favorite text editor to create TAGS.NET. You may place only 1 tag prefix for line. TAG PREFIXES ARE TO BE ENTERED EXACTLY AS THEY APPEAR IN A MESSAGE. THE IMPORT PROCESSING CHECKS TAGS FOR CASE SENSITIVITY! If you enter NET/MAIL : on a line in TAGS.NET, and the actual tag on the incoming message is NET/Mail, then, because the last 3 letters were not upper case on the incoming message, import processing will not have considered a match to be found and the message will import untouched. When import processing occurs, NetMail checks each message for the existence of any tag specified by the prefixes in TAGS.NET. When any and all tags are identified in the message, import processing determines which tag occurs first, and saves that tag, deleting the remaining tags, as the message is imported. Only the necessary length of the message is imported. If the 1st tag found in a message is followed by 1024 bytes of additional tags, all appended to that message, the additional tags, (the 1024 bytes worth) are dropped by import, prior to writing the new message to your message base, thus, saving your system a potential disk wasting 1024 bytes for that message. Therefore, it is important that you specify as many tags as appear regularly in your system. For instance, if you specify 1 tag prefix in your TAGS.NET file: TAGS.NET : NET/Mail : ...and a message comes in with 3 tags, none of which are NetMail tags, then, since import could not find any tags in the message (remember, it has only what you specify in TAGS.NET to go on...), the message would be imported as is, with all 3 tags appended on the message, taking up your valuable disk space. While a single message cannot make or break a hard drive, consider the following equation: A) average tag size = 128 bytes. B) average messages per base = 200. C) average conferences on a BBS = 40. A times B times C = 1024000 bytes! As you can see, even if each message has only 1 tag on it, your hard drive must use 1 MEG to house JUST the tag portion of a message. For this reason, you should tag extra time and care to be as precise as possible when specifying tag prefixes in order to target as many as possible. Remember however, that NetMail will leave the 1st tag of a message intact, and only delete the remaining. The 1st tag of a message is defined as that which is specified in TAGS.NET which is the closest to the beginning of the message. To remove this function, either delete TAGS.NET, or place the file in another directory, where import processing cannot find it. 5.3 PCBoard Caller Log and HUB Operations. If you are operating as a HUB system, NetDoor will log all network activity that passes through the NetDoor in your PCBoard caller log file for that node. NetDoor will log the following to the PCBoard caller log: - Time and Date NetDoor was opened and closed. - If the mail packet from the node was successfully received, and if the outgoing mail packet was successfully received by the calling node. - If the calling node is a NEW node. - If the calling node has the same BBS Code as the HUB system. - If any SEND files were received from the calling node. - A detailed accounting of all exported and imported messages to and from the calling node on a conference by conference basis. - If the door was aborted due to an upcoming PCB event. - The identity (BBS CODE) of the calling node and/or a message indicating that NetDoor was unable to determine the calling node ID. You may browse this information in the same manner you would any other PCBoard related caller log activity. 6.0 Sample PCBoard Event File. If you are like most people, you will not wish to be burdened with having to be present during mail transfer. Not only is it unnecessary but most Sysops find the most convenient time for them as well as their users to transfer mail is in the early morning hours. For this reason you will most likely wish to create a batch file from a PCBoard EVENT in order to perform the necessry Export, mail transfer with the HUB and Import. There are many different ways you can set up your batch file and, depending on your system and what other EVENTS you may currently run, will want to tailor it to your specific needs. The author can suggest however, the basics of a simple EVENT which executes a batch file which in turn executes the complete mail transfer cycle. 1) Determine at what hour you wish to perform mail transfer. Most elect to use the very early morning hours, as this is when phone rates are best and when caller activity is at a minimum. Once you determine the time you wish to perform mail transfer, use PCBSETUP to tell PCBoard that an EVENT is now active and what time you wish the event to take place. (See PCBoard documentation for further detail). 2) Next, place the following in your EVENT.SYS file in your main PCBoard directory, or, if running multiple nodes, in the PCBoard directory of the node which will perform the EVENT: cd\Netmail <directory housing NetMail> EXPORT <Export> cd\comm <directory housing communication program> boyan netmail <comm program name and unattended script startup> <note that you should replace "boyan" with your> <comm program name and "netmail" with your script> <name. The format for unattended script execution> <is different from comm program to comm program so> <consult your comm program documentation for> <complete information> <The script should contain the commands required> <to log on to the HUB system, Upload the export> <mail packet (BBS-Code.OUT where BBS-Code is the> <1 to 8 character identifier designated in NetMail> <Configuration), download the new mail packet,> <(must be downloaded into the comm directory),> <logoff and terminate the communications program> cd\NetMail <Return to NetMail directory> IMPORT <Import> cd\PCB1 <Return to your originating PCBoard directory> Board1 <Start up PCBoard> 7.0 Other Required Programs. 7.1 PKZIP, PKUNZIP. Phil Katz : PKWare. 7.2 DSZ. Chuck Forsberg : Omen Technology. If you are operating as a HUB system, you MUST use a registered version of DSZ or your Door processing will be unsuccessful. These programs MUST be present in one of the directories in your DOS PATH! NetMail will call PKZIP and PKUNZIP at various times in its operation. HUB systems MUST have DSZ in one of the directories of their DOS PATH. NODE systems, while required to use Zmodem for file transfer, are not required to have DSZ in their PATH. 8.0 Step by Step Network Operations. The following paragraphs describe a typical walk through of every step required to execute NetMail as a NODE or a HUB. Also included are instructions for configuring and using NetMail as both a NODE AND a HUB. 8.1 NODE Operations. 1) Find a system acting as a NetMail HUB. 2) Find out what conferences are carried by the HUB and the unique conference name assigned to each conference by the HUB. 3) Determine whether the HUB Sysop is running a completely open system (in which case you would have free access to NetDoor from the HUB system) or whether you need to get authorization from the HUB to enter NetDoor and transfer your mail. 4) Through your config.exe program, enter the Conference Information screen and for each conference you wish to network through the HUB system, insure that the conference name for that conference is identical to that used by the HUB system. It is absolutely VITAL that the name used is the name assigned to that conference by the HUB system. 5) Complete all other global and conference items in accordance with the instructions above. 6) At a time of your own choosing, perform EXPORT by going to the NetMail directory housing the EXPORT.EXE program and typing EXPORT <Enter>. If you wish to receive a NODELIST from teh HUB system, type EXPORT NODELIST <Enter>. 7) NetMail will gather all NEW messages since your initial configuration or since your last NetMail import, and ZIP them into the comm directory you specified in the global configuration. 8) Call the HUB system and after logging on, OPEN the DOOR assigned by the HUB system to be the NetDoor mail transfer door. 9) When you enter NetDoor, NetDoor will present you with a prompt indicating it is ready to receive. At this point, UPLOAD the mail packet created by the Export program (BBS-CODE.OUT where BBS-CODE is your unique 1 to 8 character identifier) to NetDoor. The BBS-CODE.OUT file will be in the comm directory you specified during the configuration process. You must perform the UPLOAD with ZMODEM! 10) When NetDoor has received your upload, it will present you with a few quick information prompts and then display "NetDoor ready to Send...". At this point, NetDoor has gathered your waiting mail (if any) and has created a ZIP file called BBS-CODE.IN (where BBS-CODE is your unique bbs identifier), and is ready to transmit the file to you. DOWNLOAD the file (again using ZMODEM) into the communications directory you specified during configuration. YOU MUST DOWNLOAD THE BBS-CODE.IN FILE INTO YOUR COMMUNICATIONS DIRECTORY or Import will not be able to find the incoming mail packet. If you somehow accidently download it into a different directory, you must move the file to your comm directory prior to performing Import. 11) Return to your NetMail mail executable directory and perform IMPORT by typing IMPORT <enter>. You should perform Import as soon as you receive your BBS-CODE.IN file. If you run a subsequent Export before executing Import, you will Export the same mail packet you had exported previously as well as any new mail. While this is of no major consequence (Import will bypass duplicate messages), your mail packet will be that much larger and more time consuming. 12) Upon successful Import, you have completed a full network mail cycle. Remember: The proper order for mail transfer is Export, HUB Transfer, then Import. 8.2 HUB Operations. 1) Determine which conferences you wish to be included in your network, and assign a UNIQUE name in the PCBSETUP program (Or use the existing values.). 2) Be sure to have specified yourself as a HUB through the Global Config process. 3) If you are requesting NetDoor to verify its NODE callers, (specified on the Global Configuration screen), use the BBS Maintenance option from config.exe to ADD the BBS-CODE representing each participating BBS to the BBS.NET Master BBS file. This BBS-CODE must match EXACTLY, the BBS-CODE specified by each NODE in its own configuration. After adding each BBS-CODE, the BBS.NET file will contain a blank entry for that BBS which will be updated by NetDoor after each NODE call with the conferences the calling NODE is carrying. 4) Set up your NetDoor DOOR for PCBoard: Create a separate directory to house the NetDoor and place the NetDoor files into it. Create an entry in the DOORS.DAT file with the security required (if any) to enter the door. Place an entry in your DOORS and DOORSG file so that calling NODES will know which door to enter to transfer their mail. Place the NETDOOR batch file in your main PCBoard executable directory. Update NETDOOR batch file to reflect the location of your HUB NetMail executable directory. 5) Consider creating an information bulletin for your NODE's information containing the conferences available through your network and the unique conference names you have assigned to them. 8.3 Running a NODE AND HUB from 1 System. 1) To run a NODE AND a HUB from 1 system, follow the individual steps detailed in 8.1 and 8.2 above, however, create a SEPARATE NetMail executable directory, FILES directory and WORK directory for both the "NODE" and the "HUB". For example: c:\hub\ c:\hub\files\ - for the HUB system. c:\hub\work\ c:\node\ c:\node\files\ - for the NODE system. c:\node\work\ Remember: Create a separate NetMail directory structure for the HUB system and a separate NetMail directory structure for the NODE system. Perform NODE operations from the NODE directory and all HUB operations from the HUB directory. For example: when the NODE wishes to export mail, the c:\node\ directory is entered and EXPORT is performed. However, for DOOR operations, the directory of the HUB system would be designated on the NetDoor command line. Take extra care to keep this rule in mind if you are acting as both a NODE and a HUB. 8.4 Unattended Logging of HUB Operations. Incorporated into NetMail are many ProKit routines. This means that as a HUB, you may log all NetDoor screen display activity to a collection file for later review. This can be useful if you wish to review to message activity of a node over a period of time, or wish to review the NetDoor activity which occurred while you were away from the terminal. Everything that is normally displayed by NetDoor will be written to the collection file in the NetDoor directory. The collection filename will be DEBUG1.OUT. In order to turn this function on, you must set the ENVIRONMENT variable "PRODEBUG" on by using the following command either from the DOS prompt or in your autoexec.bat: SET PRODEBUG=ON Keep in mind that with prodebug set to on, ALL programs written with ProKit routines will begin the detailed logging process. This could have a profound effect on your disk space, as well as the overall performance of your system, which is now writing to disk, nearly everthing that scrolls across the user's screen. WITH PRODEBUG SET TO ON, ALL PROGRAMS WRITTEN WITH PROKIT ROUTINES WILL BEGIN THE DETAILED LOGGING PROCESS. THIS COULD HAVE A PROFOUND EFFECT ON YOUR DISK SPACE, AS WELL AS OVERALL SYSTEM PERFORMANCE. In order to counter the effects of the disk utilization of the various ProKit program logging, you should periodically enter the subdirectories that the programs using ProKit reside, and delete the DEBUG1.OUT files that are created. By far the greatest impact will be seen by the ProDoor program. All screens displayed to the user by ProDoor will also be logged to disk! Therefore, a user browsing 100K of messages during a session would also result in an additional 100K being added to your log file. Multiply this by several callers and you can easily see the impact this environment variable can have. In order to remove the PRODEBUG=ON variable, you must either remove the SET PRODEBUG=ON command from your autoexec.bat and reboot your system, or, you may turn the variable off from the DOS command line: SET PRODEBUG=OFF Keep in mind that just turning the prodebug variable off from the DOS command line will be ineffective if you still have the PRODEBUG=ON command in your autoexec.bat file. The next time you booted your system, the prodebug variable would be reset to ON and you would again be logging all ProKit program activity. 8.5 Networking Conferences Not On Your System. If you operating as a HUB system, or a regional HUB system, it is likely that you may be requested to network conferences which you do not wish to post on your own BBS. This is often requested of HUB systems from NODEs with an interest in networking the conference with other NODEs. This is entirely possible and easy to configure through NetMail's Conference Configuration Screens. Conferences defined such as these, are not defined to PCBoard through the PCBSETUP program, nor are they defined through ProDoor's PROSM program. Also, your users will not be able to access these conferences for this same reason. However, your NODEs will still be able to benefit from message activity just as if you carried the conference yourself through your BBS. In order to carry these "invisible" conferences, you must initially create the message base which will define the conference using PCBSETUP. (After the initial setup of the conference, you can go back to PCBSETUP and delete the conference entry). After defining the conference just as you would if you were setting up a conference which you intended to use, save the conference configuration through PCBSETUP, and enter PCBoard. Once in PCBoard, Join the conference you had just defined. You will be notified that the message base needs packing. This is normal as you have just defined the message base and no index file has yet been created. Procede immediately to pack the message base using PCBPack. (PCBoard Sysop Option 3). After performing the initial message base pack, you may exit PCBoard. Your conference is now ready for networking. You do NOT need to enter an initial message in a newly formed message base; however, you MUST perform an initial pack in order to create and initialize the index file for that conference. YOU DO NOT NEED TO CREATE AN INITIAL MESSAGE IN A NEWLY CREATED MESSAGE BASE. YOU MUST HOWEVER PERFORM AN INITIAL PACK TO CREATE AND INITIALIZE THE CONFERENCE MESSAGE BASE. You may now return to PCBSETUP and remove the conference entry you created for the conference just created. The entry was necessary only to enter the conference through PCBoard for the initial pack. Finally, enter NetMail's Conference Configuration Screen and use ALT-A to add the new conference entry. Answer the prompts as normal. You are now ready to network mail in a conference which you do not maintain through PCBoard. Should you ever use the NetMail config.exe option 3 to load a completely new conference file from the CNAMES or CONFINFO file, please remember that because the CNAMES or CONFINFO file maintains entries only for conferences actively supported by your PCBoard system, you will need to use the ALT-A function once again to re-add the conference entry for the conference(s) you are networking, yet not supporting through PCBoard. 9.0 Sample Script Files. Included in the NetMail package is a file called Samples.Zip. This is a collection of sample script files to be used with your communications program to automate node to hub transfers. Choose the script file associated with your communications program (Qmodem.scr to be used with QModem, Telix.slt to be used with Telix, etc.) and replace the critical parameters such as your signon name, password, target bbs number etc., with your own information. (See your communications program documentation for further information on script files). If you are using a communications program for which no script is included in NetMail, and wish to donate a script which you develop, please feel free to upload the script to me at Home Dba BBS (206) 781-9762. I will include the script in the next NetMail release. 10.0 Questions and Answers. Q. Do I need to create a "starter" message in a new message base just created for networking purposes? A. No. As of release 2.5, NetMail and NetDoor both handle a message base with zero or 1 messages. Q. I receive DOS ERROR [6] ON FILENAME: xxxxxxx when first configuring my NetMail system. A. When you configure your GLOBAL information, one of the fields required is the location and name of your CNAMES or CONFINFO file. Once you save the GLOBAL information, NetMail procedes to load the CONFERENCE information with the entries in the CNAMES or CONFINFO file, and, in the process, NetMail reads the various conference message bases listed in the CNAMES or CONFINFO file. If there is an errant or "dummy" entry in the file, NetMail will attempt to read what it thinks is a conference message base. When it does, you will receive the DOS ERROR message. There is no harm in this message; however, you should be informed that an errant entry appears in your CNAMES or CONFINFO file. Q. I am a node and have configured my system but when I run my first export, no messages get exported, even though there are many active messages in each of my message bases. A. When NetMail first configures your system, each of the conference message bases is read and the "high message number" contained in the message base header record is stored by NetMail in the conf.net file. Only new messages left AFTER that "high message number" will be exported. This is done as a safety measure to help insure that new users do not send massive mail packets into the HUB system. Q. I have configured my system, run the initial export, and several messages have been left on my system, but no messages ever seem to be exported. A. Examine all the various switches you can set through the GLOBAL and CONFERENCE information screens to insure that you are not netgating the export of messages based on those switches. The most important switch of course is the network indicator in the conference information screen. It must be set to "Y" in order for the message base to be networked. Q. I have configured my system, exported messages and sent then to the HUB system but I never seem to receive any in return, nor is the HUB system receiving MY messages. A. Make sure that the "Conference Name Assigned by HUB" field for each of the conferences you are networking with the HUB is EXACTLY identical to that of the HUB system's configuration. You must coordinate this with the HUB system. Another way to list the conference names used by the HUB systen is to execute config.exe and request the NODELIST creation. You will receive the NODELIST file containing the HUB systems conference list in the FILES directory off of your main NetMail directory. Q. Since NetMail requires that each node name the conferences EXACTLY as the HUB system has them named, do I need to go into my PCBSETUP or PROSM (Prodoor) program and change every conference entry? A. Not at all. When NetMail performs its initial load from the CNAMES or CONFINFO file (or at any subsequent time), you simply enter the conference information screen from the config.exe program and in the "conference name assigned by HUB" field, enter the name of the conference. You do not need to alter the CNAMES or CONFINFO file at all. Q. Does NetMail write to any PCBoard or Prodoor files? A. No. NetMail reads the CNAMES or CONFINFO file, but does not write to it. Nor does NetMail read the USERS file. The only PCBoard file that NetMail reads is the conference message base and its index. Q. Can I run the NetDoor from both nodes? A. Yes, NetDoor can run from each of your PCBoard nodes. Q. I receive a DOS ERROR 2 when NetDoor tries to PKZIP my node's outgoing mail packet. A. Make sure the 4th parameter in the NetDoor command line indicates the proper location of your PKZIP.EXE file. Q. NetDoor is "unable to determine calling node id" even though I have the configuration set NOT to verify callers. A. NetDoor receives the caller's mail packet into the directory specified as the HUB work directory. Unless you specify the correct location of your HUB configuration as the 3rd parameter of NetDoor, NetDoor cannot find that work directory and determine the id of the calling node. Q. How many nodes can NetMail support? A. NetMail can support an unlimited number of nodes. Q. How many conferences can NetMail support? A. NetMail can support up to 255 conferences. Q. How can I join the NetMail network? A. There is no single "NetMail Network". NetMail is the networking software that allows anyone to join or start their own network. I would suggest starting at a local level and finding a few sysops who would like to start a networking system, and working your way to a larger network. You will find that shortly after forming your local network, you will have plenty of requests from other sysops in other parts of the country wishing to participate in yours. Starting slowly is a good way to get acquainted with the software and the process of networking. You might also find that your local network begins to take on a distinct character which you will be able to develop as the network grows. Q. Can I send a file to the HUB system as well as to another node in the network? A. Yes, simply indicate the HUB BBS code when prompted by the SEND command. Q. Can I use an existing directory as my WORK directory or should I create a separate directory for this? A. You should definitely create a separate directory for this function. NetMail erases ALL files in this directory before AND after network activity so this should most definitely be a scratch directory. Q. Can I be both a HUB and a node, and, as a node, can I call many different HUB systems? A. Yes, but acting as a HUB and a NODE together takes a little care. The most important aspect to remember is this: For EACH HUB system you call, you MUST have a separate NetMail directory and configure that NetMail system completely autonomous of any and all others. This means that if you intended to network with 3 different hubs, you would create 3 different subdirectories, each with its own WORK and FILES subdirectories, and would configure 3 different NetMail systems within those directories, each with its own "conference names assigned by HUB" based on the names given by the HUB system you were to call. As the HUB system however, you would dictate what the names of the conferences were to be, but only to those systems calling YOU. Q. Whenever I look at my HUB record in the BBS Maintenance screen, all the conferences register 0 (zero) as the last message number read. A. These are listed just for your information. The message numbers are NOT manipulated by the NetDoor process. They will always remain 0 just as the conference information screens will always show the initial value loaded at config time. Q. I have just packed my message base. Do I need to perform RESET? A. NO. You should stay clear of the RESET function unless you truly are in need of it. Simply packing your message base is no cause to reset the high message number processed by NetMail. When you perform a pack, you are not altering the message numbers, and therefore, have no need to RESET. HOWEVER, if you pack your message base AND specify renumber! THEN, you MUST perform RESET on that conference (and each conference for which this condition exists) or risk sending mail you have already sent through the network. Q. I receive a DOS SHARE violation when I attempt to RESET my MSGS file. A. Unlike the conference message bases, your MAIN PCBoard MSGS file is acquired at PCBoard startup and "held". You MUST insure that all PCBoard nodes are at the DOS prompt before attempting to RESET the MAIN PCBoard MSGS file. Attempts to RESET this file while any of your nodes are active will result in a DOS SHARE violation. Q. As a HUB, can I network conferences even though I don't carry them on my system or have them defined to PCboard through my PCBSETUP or PROSM setup programs? A. Yes. A HUB can act as a "intermediary" area for conference message bases even though the HUB does not carry those conferences on his/her system. Messages would continue to accumulate from other node mail passing through the HUB system and NODEs would be able to acquire new messages from the HUB as if the HUB were carrying the conference in PCBoard. (See Section 8.5: Networking Conferences Not On Your System). Q. I receive a DOS ERROR 2 when NetDoor attempts the export function. A. DOS ERROR 2 represent "File not Found". Make sure the "full conference filename specifed in the Conference Information Screen of config.exe is in fact the correct name of the message base for that conference. This can occur when you rename a message base but neglect to change the full conference filename indicated in the Conference Information Screen. Q. I receive the message "unable to dos_getmem xxxxxx bytes". A. NetMail is attempting to dynamically acquire enough memory to hold your index file. If you have defined your index file with more blocks then NetMail can support, you will receive this message. Most systems will receive this message if their index file is defined with more than 8 blocks. Except for very special circumstances, you should not need to define this many blocks for your index file and should consider reducing the block count through the PCBSETUP program and repacking your message base. Most systems should not require more than a maximum of 4 blocks and in fact most can get by quite comfortably with 2. Q. Are there script files already available to use for NODE/HUB mail transfers? A. Yes, see the file SAMPLES.ZIP that accompanied your NetMail package. 11.0 Technical Information. For those technically minded who like to know absolutely everything about a programs workings, the author has assembled a few tidbits of information: Language Written : Turbo Pascal 5.0 Can Execute in Multitasking Environment: YES Uses Direct Screen Writes: NO Can Make Use of Expanded Memory: YES Can Make Use of Extended Memory: YES Maximum Allowable PCBoard Message INDEX size: 32768 bytes. This amounts to 8 PCBoard message blocks. Version of PCBoard Required: 14.0 or greater. Memory Requirements Program Name Code Size Data Size as reported by ------------ --------- --------- Turbo Pascal 5.0 NetDoor.exe 53,392 32,638 Compiler: Config.exe 39,504 29,466 Export.exe 18,512 26,550 Import.exe 24,816 21,602 12.0 How to Get Additional Help. If at any time you happen to run into problems you cannot solve or need additional information on any of NetMail's functions or simply wish to learn more about NetMail or any other Home Dba Software program, you may call our Support Board - HOME DBA BBS at (206) 789-9302 (WASEA). PLEASE MAKE ALL INQUIRIES ETC. IN THE SUPPORT CONF! When calling HOME DBA with problems, please upload as many NetMail files as possible. (CONF.NET, BBS.NET etc...), and if possible, your CONFIG.SYS and AUTOEXEC.BAT files. 13.0 Help in Finding/Joining a NetMail Network. The Support conference on Home Dba will maintain a bulletin listing all known bulletin boards networking with NetMail. You may browse and/or capture this list and contact the BBS most conveniently located, for more information in joining that BBS's network. If you are already a member of a NetMail network, you may fill out the support conference questionnaire and your BBS will be added to the Nationwide NetMail Users List. 14.0 Other Programs Available from Home Dba Software. NetStat - This is the complete NetMail Statistics and Report Generator! Based on information contained in your PCB Caller log, NetStat reports detailed information on every aspect of your network operations: From total and average messages imported and exported, to number and lists of nodes, and their import and export performance on a conference by conference basis! You also get te Index File Statistics function which displays current PCBoard message base index file capacity as well as projected "fill" dates of the index files based on your own network activity. This program is available ONLY to registered NetMail users. When you register your copy of NetMail, you may indicate that you wish a copy of NetStat mailed directly to you, or, you may simply write on a piece of paper, the password you wish designated for you on HOME DBA, and you may call and download the program yourself. The advantage to this system is that you are always in position to immediately download the latest version as your record will always remain on our caller file. See NETSTAT.DOC for further information! NetDoor - This is the counterpart to NetMail. This door provides the HUB system with the means to receive, transfer and send the NODE mail packet and files. TuDoor - This DOOR allows users to view ansi/ascii tutorials forward and backwards. It was put together to get information to users who never seemed to get around to reading bulletins... know any users like that?... AnsiView - Interactive Ansi Viewing Door that allows users to view ansi screen creations interactively without having to download them first. Comes with a starter set of ansi screens.... WallyBil - Calculates and maintains shared expenses among groups of people like roommates in college etc. Maintains individual entries, allows update of entries, calculates each person's debt to the other etc. Assorted Tutorial Screens to support TUDOOR. 15.0 Acknowledgements. Special thanks and program dedication to Yani, whose patience and encouragement are outdone only by her Indian cooking! I also wish to thank Rich Greene of the Evergreen Exchange BBS (206) 838-1166 and Bob Neddo of the King County Systems Services BBS (206) 296-5277 for their time and efforts in the testing of NetMail.