home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Jason Aller Floppy Collection
/
147.img
/
NETMAL46.ZIP
/
NETMAIL.DOC
< prev
next >
Wrap
Text File
|
1990-01-30
|
146KB
|
3,312 lines
NetMail
Version 4.6
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
Direct Screen Writes .................... 4.1.14
Sound Bell on Errors .................... 4.1.15
If Running PCBoard MultiNode, # of Nodes. 4.1.16
If Hub, Disable NetDoor From ............ 4.1.17
Tag Line ................................ 4.1.18
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 the work directory specified does not exist, NetMail
will create the directory for you when you press F10
to save the Global Configuration information.
The same holds true for the FILE DIRECTORY and the
COMM DIRECTORY.
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.
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 Direct Screen Writes: When you set this option to 'Y',
all NetMail screen I/O will be performed
with writes directly to the screen.
While this gives you faster screen I/O,
the price paid is the "bleed through"
to your other active screens during
any multitasking activity. If you
experience this problem, set this
field to "N".
4.1.15 Sound Bell on Errors: If you wish to be alerted of any errors
during NetMail processing via the error
bell (a beep of 1 second), set this
option to "Y".
4.1.16 If Running PCBoard MultiNode, # of Nodes:
This is an important field to those operating as HUB systems!
If you have configured your PCBoard system as a MultiNode
system (You have turned the Network Indicator to "Y" in the
PCBSETUP program), you must tell NetMail how many PCBoard
nodes you will be operating. This is vitally important as
NetDoor will receive each calling node's mail in a work
directory solely dedicated to that node. When you save this
configuration screen, NetMail will create a separate
subdirectory (if it does not already exist) for each node
with the following naming convention:
Work directory specified in your global configuration +
node 1 - x depending on the number of nodes you
are operating.
Thus; if you are operating a multinode PCBoard system with
3 nodes, and you have specified I:\WORK as your work
directory, when you save your configuration screen,
NetMail will create :
I:\WORK1
I:\WORK2
I:\WORK3
If the drive you specify the work directory happens to be
a RAM drive, keep in mind that you will need to make
provisions to create these directories each time you boot
your system; which is most easily handled by a series of
commands in your autoexec.bat.
4.1.17 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.18 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.
NetDiags - This is a helpful utility companion program to NetMail.
It runs a complete diagnostics on your configuration
and your message bases and indexes to help you pinpoint
possible problems you may be having!
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.