                                   









                                 JMAIL
                                   
                             Version 2.80
                                   
                      PROZ Software -- 1993-1995








Section One.  Introduction

     A.  JMail Product License

     JMail and all PROZ Software products are provided "as
is".  No warranty or guarantee is expressed or implied.
This section serves to absolve PROZ Software and its agents
from any responsibility for damages, liability, or loss of
revenue due to the use, misuse, or inability to use this
product. In areas where such limitations on liability are
not legal, this product is not licensed for use.
     JMail and other PROZ Software products may not be
de-compiled, dis-assembled, patched, or reverse-engineered
in any way.  Such actions are a violation of PROZ Software
copyright and will be prosecuted through all available
channels.

     B.  Product Information

          1.  Introduction

     JMail is an integrated netmail/echomail processor with
the ability to operate with a wide variety of bulletin board
system (BBS) types and mailer types.
     This manual is intended to assist you in setting up and
operating the JMail software.

          2.  Equipment required

     JMail requires the following equipment to function
properly:

     1)  80286-, 80386-, or 80486-based computer with at
least 300k of memory available to JMail.  (450k or more is
optimum.)  Systems which require a version for 8088 or 8086-
based machines should contact their nearest PROZ Software
support site for information.
     2)  A hard disk.
     3)  MS-DOS/PC-DOS/DR-DOS 3.0 version or later or
compatible OS/2 window. (DOS 5.0 or later required for
message base locking.)
     4)  An existing message base appropriate for the JMail
version you have.  The first letter after the dash (-) in
the executable name specifies the message base format
supported by that JMail version.  An H specifies a classic
Hudson-style message base originated by QuickBBS (i.e.
QuickBBS 2.04-2.76, RA 0.04 - 1.10, SuperBBS thru version
1.13).  A J specifies Remote Access 2.xx  "JAM" format.  G
specifies the Goldbase QuickBBS format (QuickBBS 2.8x).  S
specifies Squish format.  If using only *.msg message areas,
no database format message base needs to be present and any
Jmail version will function in this mode.
     5)  An existing BinkleyTerm-style or Frontdoor-style
mailer implementation.  Some other mailer types may be
usable as well if they use directory and file-attach
configurations similar to BinkleyTerm or FrontDoor.  For
example, the D'Bridge mailer package functions in a manner
similar to Frontdoor and the Portal of Power mailer
functions in a manner similar to BinkleyTerm.  BinkleyTerm-
style mailers use the .?LO file-attach method while
FrontDoor-style mailers use the *.MSG file-attach method.
Consult your mailer documentation for information on your
mailer.   D'Bridge is considered a Frontdoor-style mailer
implementation, however, JMail has some special features for
D'Bridge systems.
          3.  Product Support Information

     Problems, requests, bug reports, and inquiries
regarding the entire line of JMail products or other PROZ
Software products should be directed to one of the following
support sites:

   Main/USA PROZ Support           Europe/Asia PROZ Support
   Jason Steck                     Pete Franchi
   12105 West Center Road #103     59 Hunters Place
   Omaha, NE, USA 68144            Westlands, Droitwich
   (402)291-2453 (data)            Worcestershire, UK WR9 9HD
   1:285/424@FIDONET               2:253/157@FIDONET
   200:5010/424@METRONET           200:5200/2@METRONET

     Additionally, the PROZ echomail support conference has
been established on the MetroNet and FidoNet backbone
systems to provide information and assistance to JMail
customers and announcements of new releases and other
crucial information.  This support conference is HIGHLY
RECOMMENDED for all JMail users.
     JMail product support may also be available on some BBS
software support conferences.  For example, JMail support
for QuickBBS users is available on the FidoNet QUICKPRO
echomail conference.

          4.  Registration

     JMail is fully capable and all features WILL function
without registration for 30 days from the date of initial
execution of the software.  After that time, all features
will continue to function, but JMail will insert slight
delays into processing to encourage registration.

     JMail may be registered by filling out the registration
form provided in the distribution file as ORDERFRM.TXT and
sending it to the appropriate support site.  The basic price
for a complete JMail registration is US$15.  Registered
users of a previous version of JMail may upgrade to JMail
2.xx for US$10. Those upgrading from a previous version of
JMail should provide their previous JMail key file name as
proof of purchase.

     Special JMail Gold registrations may be obtained for an
additional US$10.  JMail Gold registrants are entitled to
free upgrades to all future versions of JMail.  Furthermore,
JMail Gold purchasers will be provided with a printed manual
and diskette with the most recent release version of the
JMail product they use and all JMail utilities and
supplement programs.  Orders which require overseas shipment
will require an additional US$7 charge for shipment costs.
JMail Gold registrations may only be obtained from the USA
support site.

     C.  Introduction to network mail

     (This section is included for JMail users who may not
have experience with the technical concepts of FTS network
mail technology.  Users who are already familiar with FTS
conference mail may want to skip this section.)

          1.  What is echomail?

     "Echomail" encompasses by far the majority of
electronic mail within most FTS technology networks.
     Echomail exists within individual groups known as
"echos" or "conferences".  Each conference within a network
has a unique name known as an "area tag".  Messages within a
conference will generally center around a particular topic
area.  Most conferences are administered and controlled by a
"moderator" who establishes and enforces rules of behavior
and keeps the conference discussion within the intended
topic area.
     Most networks publish lists of conferences available
from their "backbone".  In addition, individual systems or
groups of systems may make still more echomail conferences
available through independent distribution systems.  An
individual BBS may receive and make available any number of
BBS conferences from a variety of network and private
distribution systems.
     Echomail conferencing is, as the name would specify, a
conference mail system.  This means that messages entered
into a particular conference are eventually copied and made
available on all systems which carry that conference.  The
effect is somewhat similar to a broadcast signal -- a
message is written into the conference and then "broadcast"
to all systems which receive that conference.  The actual
process is, however, much more complicated than a simple
broadcast signal.  Messages written into a particular
conference from a particular system are first sent to the
"hub" system upstream from that BBS.  In the case of
"backbone" conferences, the "hub" system is assigned
according to the rules and procedures of the host network.
Independently-distributed  conferences usually assign "hub"
systems on a more ad hoc basis according to individual
situations and requirements.
     The "hub" system will generally provide a link to a
conference for several systems.  When a message is received
at a "hub" system, the "hub" will send copies of the message
to each of the nodes downstream which has chosen to receive
that conference.  The "hub" will also send a copy to a
higher-level "hub" system upstream for distribution to other
systems outside of the limited distribution of the local
"hub" system.  Depending on the size of the distribution
area, any number of layers of "hub" systems may exist in
order to adequately and efficiently cover the numerical and
geographical distribution requirements.  On "backbone"
distribution systems, there will often be a top-level "star"
system which sit hierarchically at the top of several layers
of "hub" systems.
     Generally, a single BBS system or "node" which receives
echomail will only have to deal with a single "hub" from
which to receive "backbone" conferences from a network.  If
that "node" desires to receive "backbone" conferences from
more than one network, it will usually have a different
"hub" for each network "backbone".  Receipt of independently-
distributed conferences will usually require a different
"hub" link for each conference.
     Individual echomail messages include certain special-
purpose control information such as "origin lines",
"tearlines", "SEEN-BY lines" and "PATH lines".  Origin lines
exist near the bottom of a message and contain the text "*
Origin: " followed by a small text area and finally an
address where the message originally was entered.
"Tearlines" are small text areas immediately above the
origin line and prefaced by the text "--- " where mail
processing software is allowed to insert a small
advertisement of itself.  "SEEN-BY lines" are listed beneath
the origin line and list the systems which have previously
"seen" the message.  These are used for duplicate message
prevention.  "PATH lines" are listed below the SEEN-BY lines
and list the addresses through which the message has passed
to reach its current location.
     Mail processing software, such as JMail, creates a
flexible system to participate in as broad or as narrow a
range of conferences as the system operator desires.

          2.  What is netmail?

     "Netmail" is a point-to-point, usually person-to-person
form of electronic mail.  Whereas echomail effectively
broadcasts a message for the general consumption of a
potentially large audience, netmail is specifically intended
for and sent to a specific person on a specific remote
system.
     Most netmail is sent directly from the point of origin
to its destination by use of a direct dial-up telephone
call.  However, in order to minimize the costs of long-
distance netmail as well as the difficulties of reaching
part-time systems, many networks have set up netmail
"routing" structures.   "Routing" allows the sending of
netmail messages to distant locations through the
intermediary of one or more other systems along the way.  By
combining individual mail transactions into larger groups
through routing, the number of individual telephone calls is
minimized.  However, routed mail lacks the timeliness,
sureness and privacy of direct delivery.  Also, some
networks place restrictions on the content of routed
netmail.
     Aside from person-to-person messages between FTS
systems, netmail is often used to facilitate certain types
of automatic or special-purpose communications.  Some
special types of message formats have been established to
enable network between FTS networks and non-FTS networks
such as the "InterNet".  Also, other specialized formats
have been established in order to communicate certain types
of messages to automatic processing software such as the
echomail link management utilities (i.e. Remote Echo
Control, Areafix).
     Mail processing software, such as JMail, provides a
system to facilitate the sending and reception of both
direct-delivered and routed netmail.

          3.  The 5-dimensional network address

     Every node within an FTS network has a unique address
within that network.  Although some networks may use as few
as two elements of a complete address, there are five
elements in a complete network address.  The components of
an address, in hierarchical order, are the domain (network
name), zone, net, node, and point.  These are put together
to create an address in the following format:
zone:net/node.point@domain.
     The zone specifies the largest division of a network
(usually a very large geographical area such as an entire
nation or continent).  Many smaller networks will only have
a single zone for the entire network.  The zone is a
numerical value in the range of  1-32767, however, some
software packages impose a lower limitation on the zone
value for that particular implementation.
     The net specifies a smaller sub-division within a zone
(usually a city or similarly confined geographical area).
The net is also a numerical value in the range of 1-32767.
Some networks have sub-divisions called "regions" which are
higher than a net but lower than a zone in the hierarchal
structure.  "Regions" usually specify an intermediate area,
such as a state, province, or geographical regions.  In the
context of an address, a region number usually has no
relevance and, when it does, serves the same function as a
net number.
     The node is a unique number within a net assigned to an
individual system.  This number is also in the numerical
range of 1-32767.
     A point specifies an individual system which is
entirely dependant on a particular node for any and all
contact to the network.  While a node is capable of directly
reaching and being reached by any system within a network, a
point system generally is only able to conduct operations
through the intermediary operation of its "boss" node.  The
point is also in the numerical range of 1-32767.
     The domain entry is a 1-8 alphanumeric character name
for the network.  Often, the network name itself is also the
domain name, however, in cases where the network name is too
long, an abbreviated name will be created to specify the
domain name.  The domain name exists in an address to
provide capability for communication across network
boundaries.  Characters in domain names are generally
evaluated in a non-case-sensitive manner -- upper case is
assumed.
     An example of a 5-dimensional address would be as
follows:

          1:285/424.0@FIDONET

     In the above example, the system would be within zone 1
(North America), and net 285 (Omaha, Nebraska, USA) of the
FidoNet network.  The node is numbered as 424 in the 285
network.  The 0 point number specifies that the system is an
actual node and is not a point number at all.  (0 point
numbers are optional inclusions in addresses.  Point numbers
need only be listed if the system referenced is an actual
point system.)

          4.  Mail packets and bundles

     When sent from system to system, both netmail and
echomail are stored in a "packet" format.  Individual
packets may contain one or more netmail or echomail
messages.  One or more packets may be compressed into an
archived mail "bundle" for more efficient transmission.
     "Packet" formats have an established minimum format
called "type 2" which was established by the FidoNet
Technical Standards Committee.  However, various extensions
have been created by re-defining and re-utilizing obsolete
fields in the old "type-2" format.  The most popular of
these extensions are the "type 2-plus" and the "type 2.2"
formats.  These packet extensions provide more detailed
addressing information in the packet header than that which
is available in the obsolescent "type-2" format.

     D.  Setting up JMail

     JMail is NOT a "plug-and-play" utility.  Certain
critical information about your network site and certain
options regarding how you want JMail to run must be
specified.

          1.  JMPath

     The JMPATH is the directory where JMail will look for
its control files and where it will, unless overridden, use
for BBS files, swapping and activity logging.  The JMPath
may be specified by declaring a "JMAIL" DOS environment
variable specifying the desired directory.  If no JMAIL DOS
environment variable is found, the current directory will be
assumed.

          2.  Control file

     Most site and run-time options information are kept in
the JMail control file (usually named JMAIL.CTL and kept on
the JMPath).  Prior to running JMail, you must edit the
JMail control file for use at your network site.  The sample
control file included in the release package contains some
assistance with setup.  Section Two of the documentation is
a detailed reference for the JMail control file.
     Most sites will need to change many of the preset
options in the sample control file.
          3.  Routing control file

     The routing control file (usually named JROUTE.CTL and
kept on the JMPath) contains routing commands and schedules
for treatment of outbound netmail and file-attatches.  Prior
to running JMail, you should edit this file to reflect the
routing and flavor changes necessary for your system.  The
sample routing control file included in the release package
contains some assistance with setup.  Section Five of the
documentation is a detailed reference for the JMail routing
control file.
     The JRoute utility must not be used with Frontdoor-type
systems as it will conflict with the internal FrontDoor
routing capability.

          4.  Areas control file

     The areas control file (usually named AREAS.BBS and
kept on the JMPath) contains information relating to
echomail links.  A sample areas control file is included
with the JMail release package.  Section Four of the
documentation is a detailed reference for the areas control
file.

     E.  JMail termination codes

          1.  Abnormal terminations

     When JMail terminates, it will report the Error Code of
its termination.  An Error Code of 0 specifies a normal,
apparently error-free run and termination.  If JMail
encounters a run time error that it cannot recover from
(such as a hardware error), it will report an "abnormal
termination" and give an Error Code greater than 0.
     If you are unable to clear the problem or connect this
problem to a hardware error or other problem on your local
system, the error information should be reported to PROZ
Software for analysis and correction.  Please also provide
all possibly relevant system information such as hardware,
operating system, multi-tasker, BBS type, and disk cache.

          2.  Errorlevels

     JMail will return the following "errorlevel" codes to
DOS for potential trapping in a batch file environment.

          0 - Normal termination.  No errors.  No mail
imported.
          2 - Configuration error or message base locking
error.
          11 - Netmail was imported to the message database
(other than the NETMAILPATH).
          12 - Echomail was imported to the message
database.
          13 - BOTH netmail and echomail were imported to
the message database.
          255 - Abnormal termination (see above).
Section Two:  JMail control file (JMAIL.CTL)

     A.  System Paths

          JMPATH

     The JMPATH is not actually defined within the control
file.  Instead, JMPATH may be defined by setting a "JMAIL"
DOS environment variable.  Whenever JMail executes, it will
search the environment for a valid path value assigned to
"JMAIL".  If found, This path value will become the JMPATH.
If no value is found, the current path (the directory from
which JMail was executed) is assumed to be the JMPATH.

          JMAILPATH <path>

     The JMAILPATH specifies the directory where JMail will
find its registration key file (if any) and duplicate-
prevention files and where JMail will output requested
reports and listings.    This entry is optional.  If it is
not specified, then the JMAILPATH will be equivalent to the
JMPATH.

          BBSPATH <path>

     The BBSPATH specifies the directory where BBS message
base files and control files (such as user files) are kept.
On Squish systems, this is the path where the user file is
kept.     This entry is required.

          INBOUNDPATH <path> [NOARC]

     The INBOUNDPATH specifies the path on your system where
JMail will look for inbound mail packets and archives.  Up
to five of these entries may exist in a single control file
to reflect multiple inbound areas for mail packets and/or
archives (i.e. Binkley systems using PROTINBOUND and
KNOWNINBOUND path entries for secure mail processing).
     NOARC on the line will cause JMail not to accept any
archived mail from that inbound path.  Since netmail
messages are usually not archived and echomail messages
usually are, this is a fairly effective way of enforcing
inbound file areas which exclusively accept netmail (such as
Binkley's unprotected inbound areas).
     At least one of these lines is required for JMail to
execute.

          OUTBOUNDPATH <path>

     The OUTBOUNDPATH specifies the default directory for
outbound mail packets and archives for the default zone and
domain (the "default" zone and domain are those defined in
the first ADDR line in the control file).  This path must be
a sub-directory, not the root directory of a drive.
Destination addresses in the default domain but different
zone will use a sub-directory beneath the parent directory
of the OUTBOUNDPATH with a name the same as the outbound
path but with an extension indicating the different zone
number (directories can have extensions just like
filenames).  Destinations outside of the default domain will
use a sub-directory beneath the parent directory of the
OUTBOUNDPATH with a name of the domain and an extension
indicating the zone number within that domain.
     The optional NODOMAIN parameter will prevent JMail from
using the domain-aware directories and will instead cause
directory names to revert to an only zone-aware format for
all destination addresses (same as a "NODOMAIN
all:all/all@all" control file line).  This may be useful for
some systems which desire to avoid the domain-aware
directory names for any reason (i.e. extensive requirement
for non-domain-aware utilities).
     This entry is required for JMail to execute.

          ARCPATH <path>

     The ARCPATH specifies the path where you want JMail to
place temporary outbound echomail packets.  The packets will
be written to sub-directories beneath this directory named
in the form <domain>.<zone>.  For example, temporary
echomail packets for 1:104/424@FIDONET would be placed in a
subdirectory beneath the ARCPATH named FIDONET.001.
     This entry is required for JMail to run.

          UNARCPATH <path>

     When JMail decompresses archived mail packets from the
INBOUNDPATH, the packets within the file will be written to
the UNARCPATH and then processed.
     This entry is optional.  If it is not defined, then the
temporary packets will be written to the JMPATH.

          NETMAILPATH <path>

     The NETMAILPATH line specifies the path on your system
where you want JMail to put netmail messages in *.msg file
format.  Even if you import netmail to your system, this
path is still required for temporary files during
processing.
     This path must be defined.

          BADPATH <path>

     The BADPATH specifies the path on your system where you
want JMail to put  messages (in *.msg format) which are
found to be unacceptable to JMail for any reason.  Examples
of such messages would include echomail messages with area
tags not listed in the areas file (Section Four), echomail
messages in known areas but from addresses other than those
listed in areas.bbs, or netmail messages routed through the
local system which are excluded from routing in the routing
file (Section Five).
     If this option is not defined, bad messages will be
deleted.
          DUPEPATH <path>

     The DUPEPATH specifies the path on your system where
you want JMail to put echomail messages (in *.msg file
format) which it detects to be duplicates of previous
messages.  These messages can then be examined manually to
find the source of the duplicate messages.
     If this option is not defined, then duplicate messages
will be deleted.

          SPECIALPATH <path>

     The SPECIALPATH specifies the path on your system where
you want JMail to put echomail messages destined for
addresses listed in the areas.bbs file with the special
processing flag (Section Four).  Such messages will be
written to this location for later processing by utilities
external to JMail (such as UFGate of Waffle UUCP newsgroup
gateways).
     If this option is not defined, then JMail will ignore
special processing flags and toss all messages to packets
normally.

          BADFILEPATH <path>

     Occasionally, JMail will encounter archives with
unknown compression formats or mail packets which are
corrupted or invalid.  In these situations, JMail will copy
the files to BADFILEPATH using the name BADARC.### or
BADPKT.### where ### is a numerical extension used to
provide each file with a unique filename.  Once copied to
BADFILEPATH, the files will be left for manual inspection by
the system operator.
     This entry is optional.  If is it not defined, bad
files will be renamed, but left in the directory they were
previously in.

          ATTACHPATH <path>

     Often, files other than mail packets or archives will
be delivered to a system.  Normally, these files are simply
left on the INBOUNDPATH requiring the system operator to
either run external utilities to copy these files to other
locations or to do so manually.
     Specifying an ATTACHPATH in the control file will cause
JMail to do this automatically.  After mail processing, any
files which remain on the INBOUNDPATH(s) will be assumed to
be attached files and will be moved to the directory
specified in this entry.  This can allow for cleaner
INBOUNDPATH areas and more efficient received-files
processing on systems with more than one INBOUNDPATH.
     This entry is optional.  If no ATTACHPATH is specified,
no such file moving will take place.

          PACKETTOSSPATH <path>

     By default, JMail will delete all inbound mail packets
after the messages within are processed.  However, if a
PACKETTOSSPATH is defined, the packets will instead be moved
to the path indicated.  This facility is useful on systems
which maintain multiple multiple message bases or on systems
which need to use JMail for pass-thru mail processing but
use another utility to actually import messages.
     If this option is not defined, inbound packets will be
deleted after processing.

          SPECIALINBOUND <path>

     Some systems run offline reader software which uses
packets in a special directory to transfer mail bundles to
and from other remote systems.  This arrangement is somewhat
like point systems except for the lack of a point address
for the remote system.  Instead, the packets and messages
inside appear to be both to and from the local system.  This
arragement can cause serious problems for a JMail system
running with the ECHOSECURITY option active.
     The SPECIALINBOUND command will designate a path which
may contain mail packets from offline readers intended both
for possible importation to the local message base as well
as forwarding out into the larger echomail system.  On
messages coming from this area, JMail will act as if the
message is being exported from the local system with two
exceptions.  First, JMail will conduct a check on the origin
line to ensure it is actually from the local system.  This
prevents the use of offline readers to "smuggle" messages
into the echomail system which appear to be from other
addresses.  Second, JMail will import the message to the
local message base.
     If this option is not defined, then JMail will not
process packets other than from the defined INBOUNDPATH
entries.

          DBRIDGEPATH <path> [OLD]

     If a DBRIDGEPATH is found in the control file, it will
activate JMail's special features for the D'Bridge echomail
processor.  The path on the line should point to the
D'Bridge "system directory" where Jmail will output a
JMAIL.RSN file to force rescanning of the D'Bridge outbound
queue.  When these features are active, JMail will use,
where possible, the special D'Bridge "no message" method of
packet archive naming and attaching.
     The OLD option will force backwards compatibility to
the older method of archive naming and will disable any
MAXARCSIZE control file option.  (Users should use the the
OLD option until such time as it is definitely verified that
the "NEW" process is functional in D'Bridge.  Check with
your D'Bridge or JMail support site for verfication of the
capabilities of your software.)
     Due to D'Bridge's special limitations in the outbound
area, JMail will only use the special method on archives to
the same domain as that in the address listed first in the
JMail control file.  Archives to other domains will use
standard Binkley-style file naming conventions and file-
attach procedures.
     This entry is optional and is necessary only on
D'Bridge systems which desire to use the special D'Bridge
file-attach methods.

          SWAPPATH <path>

     The SWAPPATH specifies the directory where JMail will
write its temporary swapping file.  The swapping file will
only be used if there is insufficient expanded memory
available for JMail to use its memory-swapping routines.
Swapping  is used to maximize available memory during
archiving and de-archiving operations.
     This entry is optional.  If it is not defined, SWAPPATH
will be equivalent to JMPATH.

     B.  System Files

          AREAFILE <path and filename>

     This option will specify the path and filename of the
area control file (Section Four).
     This entry is optional.  If it is not defined, AREAFILE
will default to "AREAS.BBS" on the JMPATH.

          DUPEFILE <path and filename>

     This option will specify the path and base filename
(without extension) of the file where JMail stores message
signatures for duplicate detection.
     This entry is optional.  If it is not defined, DUPEFILE
will default to "JDUPE280" on the JMAILPATH.

          LOGFILE <path and filename>

     This option will specify the location and filename of
JMail's log file.
     This entry is optional.  If not specified, LOGFILE will
default to JMAIL.LOG on the JMAILPATH.

          BILLINGFILE <path and filename>

     This option will specify the file to which JMail will
output a report each individual echomail link in which
messages were processed.  The file format will be ASCII
text.  Each line will contain the area name, the link
address, and the number of bytes received from and sent to
that link in that area.
     This entry is optional.  If not defined, no BILLINGFILE
will be output.

          TOSSFILE <path and filename>[FULL]

     This entry specifies the path and filename of a file to
which JMail will output a report of the echomail areas in
which messages were imported.  If the FULL option is used,
JMail will also output a record of how many messages were
processed in each area.
     This entry is optional.  If not defined, a list will be
written to the screen at the end of the run.

          OPUSEXPORTFILE <path and filename>

     This entry specifies the path and filename of the
export list for Opus-style (*.MSG) areas.
     This entry is optional.  If not defined, OPUSEXPORTFILE
will default to EXPORT.CTL on the BBSPATH.  [This option is
accepted on all JMail versions as all versions support the
*.MSG format in addition to a database format.]

          QUICKNETEXPORTFILE <path and filename>

     This entry specifies the path and filename of the
Hudson-format netmail export list.
     This entry is optional.  If not defined,
QUICKNETEXPORTFILE will default to NETMAIL.BBS on the
BBSPATH.  [This option is only accepted in the Hudson, JAM,
and Goldbase versions of JMail.]

          QUICKECHOEXPORTFILE <path and filename>

     This entry specifies the path and filename of the
Hudson-format echomail export list.
     This entry is optional.  If not defined,
QUICKECHOEXPORTFILE will default to ECHOMAIL.BBS on the
BBSPATH.  [This option is only accepted in the Hudson, JAM,
and Goldbase versions of JMail.]

          SQUISHEXPORTFILE <path and filename>

     This entry specifies the path and filename of the
echomail export list for Squish systems.
     This entry is optional.  If not defined,
SQUISHEXPORTFILE will default to ECHOTOSS.LOG on the
BBSPATH.  [This option is only accepted in the Squish
versions of JMail.]

          JAMEXPORTFILE <path and filename>

     This entry specifies the path and filename of the
echomail export list for JAM systems.
     This entry is optional.  If not defined, JAMEXPORTFILE
will default to ECHOTOSS.LOG on the BBSPATH.  [This option
is only accepted in the JAM versions of JMail.]

     C.  Address Options

          ADDR <addresses>
          ADDRESS <addresses>

     ADDR lines must be the first lines in the control file.
     These line will define one or more of the addresses for
your system.  The first address listed on the first ADDR
line found will be presumed to be the primary address for
the system.  The default address is used as a default when
matching address AKAs as well as in determining OUTBOUNDPATH
locations for outbound files.
     The first ADDR line MUST use the 5-dimensional format.
(i.e. "1:104/424.0@FIDONET")  Once the first 5-dimensional
ADDR line is listed, all other control file lines do not
require the domain element be listed.  The domain element
contained in the first ADDR line will be assumed unless
overridden by an explicit 5-dimensional address.
     At least one of these lines is required for JMail to
execute.

          HIDDEN <addresses>

     HIDDEN lines operate exactly the same way as ADDR lines
except that addresses defined in a HIDDEN line will not be
allowed to appear in echomail seen-by or path lines.  This
supports the unique requirements of "Planet Connect"
echomail communications.
     These lines are optional.

          USEAKA <local address> <remote address>

     When processing an outbound message or packet, JMail
will use the local AKA address which most closely matches
the destination address of the message or packet in domain,
zone, and even net number.  This option gives the user the
oppurtunity to override such "nearest-net" matching and
require that certain destination addresses match to a
specific local AKA address.

          ADDSEENBY <addresses>

     This line will cause the addresses listed to be added
to the seen-by lines of all messages processed through the
local system.  Messages will appear to have already been
sent to the addresses listed, although copies may not
actually have been sent at all to those systems.
     These entries are optional.  If not included, no
addresses will be added to seen-bys other than local AKA
addresses.

          ASSUMEDOMAIN <domain name> <zone[:net]> [...]
          ASSUMEZONE <zone> <domain> <net> [...]

     At times, JMail will not be able to obtain sufficient
information from a particular message regarding its true
source or destination address.  In such cases, JMail is
forced to "guess" at the complete 5-dimensional address
based on the information available.  By default, the list of
local addresses defined on ADDR lines is used as the basis
for such "guessing".  However, this line allows the user to
set down additional information telling JMail how to guess.
     The ASSUMEDOMAIN criteria will be used in instances
where JMail is able to obtain accurate zone information, but
lacks domain information.  The ASSUMEZONE criteria will be
used in instances where neither zone or domain information
can be obtained from sources within the message or packet
header.
     Specifying specific nets is optional within the
ASSUMEDOMAIN line.  If no nets are specified, JMail will
assume that all addresses within the specified zone also
belong to the specified domain.
     These lines are optional.  If not defined, JMail will
use only the information defined in ADDR lines as the basis
for guessing complete 5-dimensional addresses.

          NODOMAIN <address(es)>

     The NODOMAIN line allows the selective disabling of
domain-aware OUTBOUNDPATH names for specified addresses.
This can be useful for systems which, for various reasons,
cannot tolerate domain-aware processing.
     "NODOMAIN all:all/all@ALL" would have the same effect
as the NODOMAIN option on
the OUTBOUNDPATH control file line.
     Most systems, even Frontdoor type systems which do not
fully support domains, will tolerate domain-aware
OUTBOUNDPATH naming conventions.
     These lines are optional.  They may be rendered moot by
a NODOMAIN option on an OUTBOUNDPATH line.  If not defined
and if NODOMAIN is not defined on the OUTBOUNDPATH line,
then domain-aware OUTBOUNDPATH names will be used.

     D.  BBS Options

          NETMAILBOARD <board #>

     This entry specifies the Hudson/GoldBase message base
board number which has been reserved for netmail.
     On Squish versions of JMail, instead of a board number,
a path and 1-8 character (without extension) filename of the
Squish-format netmail area should be provided.
     On JAM versions of JMail, either a netmail board name
(JAM format) or a netmail board number (Hudson format) may
be used.
     This entry is optional.  If not specified, netmail will
not import even if the NETIMPORT control file option or NI
command line option is set and netmail will be left on the
NETMAILPATH in *.MSG format.

          NOIMPORT <Name>

     If the NETIMPORT control file option or NI command line
option is set, this line will prevent netmail messages
destined to the specified name from being imported to the
local message base.  An example of this circumstance is when
messages to "Remote Echo Control" need to be left in *.MSG
format to allow processing by the Remote Echo Control
utility.
     This entry is optional.  If none of these entries are
found, then all netmail will be processed according to the
NETIMPORT/NI settings.

          SPECIALIMPORT <board> <Name>

     SPECIALIMPORT lines will cause all messages (netmail
and echomail) intended to the names specified to be imported
to the message board number (or board name on JAM and Squish
systems, athough JAM systems may specify either a board
number or board name) specified on the same line.  The
importation will take place IN ADDITION to any message board
importation specified in an areas.bbs line applicable to the
message being examined.
     This entry is optional.

          REBUILD

     When JMail initializes, it searches for and opens the
BBS message base files on the BBS path.  If those files are
not found, JMail will terminate.  By default, if the files
are found to be corrupted or invalid, JMail will also
terminate.  This option will cause JMail to attempt to
rebuild the message base indexing files.  If successful,
JMail will continue rather than terminate.
     This entry is optional.  [This option will only be
accepted on Hudson or Goldbase versions of JMail or on JAM
versions using Hudson message bases.]

          NOPATH

     This option will prevent the writing of  PATH lines to
the message base when an echomail message is imported.  This
can save a significant amount of disk space.
     This entry is optional.  If not found, PATH lines will
be imported and "hidden" with ASCII #01 characters.

          NOSEENBY

     This option will prevent the writing of  SEEN-BY lines
to the message base when an echomail message is imported.
This can save a significant amount of disk space.
     This entry is optional.  If not found, SEEN-BY lines
will be imported and "hidden" with ASCII #01 characters.

          NOSTOMPDATE

     By default on echomail message import, JMail will
update the message date and time to the time of importation.
This allows systems to delete echomail messages according to
how long they have been on the local system instead of
according to how long it may have been since the message was
originally written.  NOSTOMPDATE turns this utility off and
leaves the message date/time stamp at the time the message
was originally written.
     This entry is optional.  If not found, JMail will
maintain the original date/time group on echomail message
import.

          FULLSCAN

     By default, when scanning a Hudson or Goldbase message
base for export, JMail will ignore any invalid entries in
the export file.  If no export file is found, JMail will
assume there is nothing to export.  However, if FULLSCAN is
specified, then JMail will interpret any such error
condition as a requirement to conduct a complete message-by-
message scan of the entire message base.
     This entry is optional.  [This option will only be
accepted on Hudson or Goldbase versions of JMail or on JAM
versions using Hudson message bases.]

          RESCAN [path and file name]

     This option will cause JMail to conduct a rescan
operation by accessing the specified areas control file
specified on the line.  The areas listed in the file will be
scanned out of the message base and sent to the addresses
specified in the file.  If no filename is specified, the
filename will default to JRESCAN.BBS on the JMPATH.  The
format of this file is identical to the JMail areas control
file (Section Four).
     This entry is optional.

          NOSTOMPORIGIN

     By default, JMail will change the address on an origin
line in each exported echomail message to AKA-match the
destination address of each copy of the message outbound to
other systems.  This option will cause JMail to not modify
the origin line address.
     This entry is optional.  If not found, JMail will
modify origin line addresses on exported echomail messages.

          ORIGINFORMAT <0|1|2|3|4>

     ORIGINFORMAT specifies the format JMail will use for
the addresses on origin lines JMail produces.  JMail
produces origin line addresses in situations such as
"stomped" origin lines on exported echomail (default unless
NOSTOMPORIGIN option is set) and domain-gated echomail
messages with a gateway origin line.
     This entry is optional.  The default is format 4.  The
formats are as follows:

               0 - zone:net/node[.point]@domain
               1 - zone:net/node[.point]  (* domain
information not included *)
               2 - zone:net/node  (* domain and point
information not included *)
               3 - net/node  (* domain, zone, and point
information not included *)
               4 - domain zone:net/node[.point]

          STOMPTEAR

     This message will cause JMail to replace tear lines
with JMail product information.  According to the technical
standards of echomail, mail processors (such as JMail) are
supposed to be the source of tear line information.
However, many BBS systems and offline readers use tear lines
for their own purposes, so the tear line "stomp" utility is
optional with JMail.
     JMail operating during an evaluation period will
automatically force STOMPTEAR on.
     This entry is optional.  If not found, tear lines will
not be processed on exported messages.

          NODELETE

     The Squish version of JMail will automatically delete
messages whenever a Squish message base if found to exceed
its defined maximum number of active messages.  The NODELETE
line will suppress this function and allow the message base
to grow indefinitely (perhaps for processing by external
message base maintenence).
     This entry is optional.  [This entry will only be
accepted on Squish versions of JMail.]

          LENIENT

     A few message base editors have been reported to have
problems with early releases of the Goldbase message base
specification.  These problems have resulted in production
of some invalud bit-mask values on netmail messages produced
by these editors.  The LENIENT line will cause JMail to
forgo error checking on these errant bits and thus allow
netmail produced by errant editors to export normally.
     This entry is optional.  [This entry will only be
accepted on Goldbase versions of JMail.]

     E.  System Options

          SYSOP <Name>

     This is the name of the system operator of the local
system.  It must be the same as the name used to register
JMail with PROZ Software as  REG lines will be evaluated
according to this line.
     This line is required for JMail to execute.

          REG <registration code or EVAL>

     This entry specifies the registration code provided to
JMail purchasers by PROZ Software.  The registration code is
the 1-8 character filename (without extension) of the key
file sent to JMail purchasers.  JMail will accept either a
REG line or the presence of the actual key file as proof of
registration.
     A "REG EVAL" line may be input by new JMail users to
enable a 30-day evaluation mode.  After that period has
expired, JMail will require registration or will run in a
"delay" mode as explained earlier.
     Either this line or the presence of a key file on the
JMAILPATH is required for registered JMail systems.  This
line must be specified after the SYSOP line.

          BINKLEY

     The BINKLEY command instructs JMail that it is
operating in a BinkleyTerm-style environment and must,
therefore, use BinkleyTerm-style file-attaches.
     This command is required for BinkleyTerm-style systems
to operate properly.

          DESQVIEW

     Many systems operate using the Desqview multi-tasking
utility.  This option will cause JMail to recognize the
Desqview multi-tasking and to use certain critical call
priorities and time-release functions to optimize
performance in that environment.
     This entry is optional and only has benefit on systems
running Desqview.

          SCREENLEVEL <[1|2|3]>
          DISKLEVEL <[1|2|3]>

     During the course of its run, JMail will display and
log to disk certain information, error messages, etc.  These
lines allow the user to control how much information will be
displayed by specifying a priority level for both the screen
and the disk log file.
     Recommended settings are SCREENLEVEL 3 (full
information) and DISKLEVEL 2 (everything but the tedious
process of writing the address of each message copy going
out).  DISKLEVEL 3 will give a remarkably complete log, but
may significantly slow down JMail and may consume very high
amounts of disk space.
     DISKLEVEL 3 may be necessary to produce documentation
of certain error conditions for report to PROZ Software.
     These entries are optional and are only necessary if a
change from default values is desired.
          LOCK [FORCE]

     This option is intended for multi-line or other systems
which may have a need to have more than one program
accessing the message base simultaneously.  Most BBS systems
supported by JMail use a method of message base "locking"
which allows shared access by multiple programs or multiple
copies of one program.  This entry will cause JMail to use
and respect message base locking and unlocked schemes.
     On Binkley systems, the LOCK option will also enable
the use of *.BSY files to prevent collisions between JMail
and Binkley on multi-line systems.  (Refer to Binkley
documentation for more information on *.BSY files).
     Normally, JMail will search for DOS' SHARE.EXE utility
in memory and, if not found, will refuse to accept the LOCK
entry.  However, the FORCE option will force JMail to use
file sharing options regardless of the presence of the
SHARE.EXE utility.  In this way, JMail supports integrated
file schemes such as NovellDOS.
     This entry is optional.  If not specified, file sharing
will not be used.

          SMALLSWAP

     By default, JMail will swap out all of the memory it
has allocated when swapping out as a result of a %S
parameter on either a DEFINEPACKER or DEFINEUNPACKER line.
This provides maximum safety.  However, in small memory
configurations, systems without a great deal of expanded
memory (EMS) or systems with little or no EMS and short disk
space on the SWAPPATH, the SMALLSWAP parameter will help
reduce the amount of swap space required by swapping out
only the memory which is actually used.

          RECFIX <REC Processor Name>

     The RECFIX option has been put in to compensate for a
bug in the "Remote Echo Control (REC)" automated areas
control file maintainence utility (versions 1.99-2.02).  REC
is the only external areas maintainence utility which is
currently capable of handling JMail's unique areas control
file capabilities and domain-aware format.  However, for an
unknown reason, REC has a problem with INTL lines in
messages.
     Accordingly, all messages which are addressed to the
name listed on the RECFIX line in the control file and are
addressed to the local system will be written to the netmail
area without an INTL line.
     This entry is optional and is only necessary on systems
running Remote Echo Control versions 1.99 through 2.02.

     F.  Mail Processing Options

          PACKETARCHIVE

     This entry will activate the ability of JMail to
archive (compress) outbound echomail packets.
     This entry is optional.  If it is not activated,
outbound echomail will be left in a temporary packet format
on the ARCPATH.  This allows for use of external mail-
archiving software

          PACKETUNARCHIVE

     This option will activate the function of JMail to
search for and process inbound compressed mail bundles.
     This entry is optional.  If it is not activated, JMail
will not scan for or process any inbound compressed mail
bundles.

          PACKETSECURITY

     This option will activate checking to ensure inbound
packets are addressed to the local system and contain any
passwords required by a PASSWORD control file line.  If this
option is active, packets with improper passwords will be
handled as "bad packets" in accordance with the BADFILEPATH.
     This entry is optional.  If it is not found, packet
passwords will not be checked on inbound packets.

          PACKETIMPORT

     This option will cause JMail to search for and process
mail packets on the UNARCPATH, the INBOUNDPATH and, if
defined, the SPECIALINBOUND path.  Echomail messages in
these packets will be imported and/or forwards in accordance
with the areas control file (Section Four).  Netmail
messages will be handled in accordance with the NETIMPORT
option.
     This entry is optional.  If not defined, inbound
packets will not be processed.

          ECHOEXPORT

     This option will cause JMail to scan for outbound
echomail from the message base.  If a valid echomail export
file is found, the messages listed will be exported and
processed in accordance with the areas control file.  If no
echomail export file is found, the entire message base may
be scanned for outbound echomail depending on the FULLSCAN
entry.
     This entry is optional.  If not found, JMail will not
scan for echomail export.

          ECHOFORWARD

     This option will cause JMail to forward any inbound
echomail messages which are discovered to be addressed for
other systems than the local system.  Such messages will not
be imported or processed through the areas control file, but
will be packeted for the system for which they were
addressed.
     This entry is optional.  If not found and an echomail
message is addressed for another system, it will be tossed
to the BADPATH.
          ECHOSECURITY

     This option will cause all incoming echomail messages
to be checked to ensure they are addressed to the local
system and that they are coming from a system listed for
that area tag in the areas control file.  If a message is
found to be addressed to another system, it will be
processed in accordance with the ECHOFORWARD statement.  If
the message is found to originate from an address not listed
with that area tag in the areas.bbs file, the message will
be output to the BADPATH.
     This entry is optional.  If not found, inbound echomail
messages will be assumed to be addressed to the local system
and from a valid remote system for that area tag.

          MAILEXPORT

     This option will cause JMail to scan for outbound
netmail from the message base.  Outbound netmail which is
found will be written to the NETMAILPATH for processing
either by the JMail routing utility (JRoute) or by a front-
end mailer such as D'Bridge or Frontdoor.
     This entry is optional.  If not found, JMail will not
scan for netmail export.

          NETIMPORT

     This option will cause netmail messages destined for
the local system to be imported into the local message base
on the NETMAILBOARD.   If this option is active, all netmail
messages destined for the local system will be imported
except those destined to individuals listed in a NOIMPORT
statement.
     This entry is optional.  If not found, netmail messages
will remain on the NETMAILPATH in *.MSG format.

          SCANBAD

     This option will cause JMail to scan and attempt to
process messages in the BADPATH.

          SCANSPECIAL

     This option will cause JMail to scan and attempt to
process messages in the SPECIALPATH.

          SCANNET

     This option will cause JMail to scan the NETMAILPATH
for any echomail messages.

          NODUPE

     This option will disable JMail's checking for duplicate
echomail messages.  If the local system does any hubbing for
other systems, this option is NOT recommended as it will
allow any duplicate messages to pass through the local
system and be passed on to remote systems.  However, on non-
hub systems, this option can significantly increase
processing speed.
     This entry is optional and is not recommended except
for end-node systems which do no echomail forwarding.

          TINYSEENBY

     This message will cause the local system to use "tiny"
SEEN-BY lines on messages sent to other systems.  "Tiny"
SEEN-BY lines are lines which include entries from only the
systems which to which the local system is hubbing that
area.  SEEN-BYs pre-existing from other links in the
distribution system are stripped away.  This option can
significantly reduce message sizes, but also results in an
increased risk of duplicate messages being produced within
the distribution system.
     This entry is optional and is not recommended on most
systems.

          NOSEENPROCESS

     This option will cause JMail to process the shorter
PATH line instead of the SEEN-BY lines for duplicate
prevention.
     This entry is optional and is not recommended for most
systems due to the increased potential for duplicate message
production.

          GATEORIGIN <text>

     When JMail conducts domain-gating of echomail messages
it places a new origin line beneath the original origin line
of the message.  This control file line specifies the
content of the text field of that appended origin line.
     This line is optional and only should be specified if
any echomail areas are to be domain-gated.

          IGNOREMSGID

     Normal JMail duplicate checking will check the MSGID
line, if available, or a CRC value based on the message
header fields if a MSGID is not found.  IGNOREMSGID will
cause the MSGID line to be ignored even if present and all
duplicate checking will be done based on message header
values only.
     This entry is optional.

          EXACT

     By default when processing netmail, JMail will only
output DOMAIN lines when the source and destination domains
are different and INTL lines when either the source and
destination DOMAIN or source and destination zones are
different.  The EXACT line will force output of DOMAIN and
INTL lines on all netmail messages to ensure the most
exacting level of addressing information.
     This entry is optional but highly recommended on all
systems which operate in multiple networks.

          POLLONREQ

     This entry will cause JRoute to create a forced poll of
the destination system when an outbound null-text netmail
message is found with a file-request attached and the flavor
of the message is other than HOLD.  This will force
BinkleyTerm to poll the remote system rather than waiting
(possibly forever) for another condition which will cause
the file request to actually be sent.
     This entry is optional but highly recommended on all
systems which operate in multiple networks.

     G.  Archives and Packets

     JMail has the ability to handle multiple archiving
formats on both inbound and outbound mail bundles.  Inbound
archived bundles are subjected to tests according to
standards laid down in the JMAIL.CTL file to determine what
type of unarchiver should be used.  Outbound bundles may be
archived differently depending on the outbound address and
its corresponding entry in the JMAIL.CTL file.

          DEFINEPACKER <name> <command line>

     This control line defines an individual archiving
utility with corresponding command line.  At least one of
these lines must be defined.  The first line found will be
assumed to be the default archiver.  The default archiver
will be used when an outbound bundle is intended for an
address not specified for a particular archiver in a
USEPACKER control line.
     In this control line, the name must not exceed 10
characters in length.  Characters beyond the tenth will be
ignored.  The command line should include the specific
directory and filename with extension of the executable
archiver program as well as any command line switches.  A %A
should be placed on the command line in the place that the
archive name would be specified.  A %F should be placed on
the command line where the file intended for inclusion in
the archive would be specified.  A %S at the end of the
command line will cause JMail to swap itself out of active
memory when the archiver is called in order to give the
archiver program the maximum amount of memory possible.

          DEFINEUNPACKER{ARC5|ARC6}<max ARC lvl><cmd line>
          DEFINEUNPACKER <name><sig offset><sig><cmd line>

     These entries specify individual unarchiver utilities.
     ARC5/ARC6 lines are intended to define ARC-standard
archivers.  These archivers all utilize the same archive
"signature" of a single ASCII #26 byte in the zero position
of the archive.  However, many different and incompatible
archivers use the same signature.  Accordingly, there has to
be a method to tell these very similar archive type apart.
The ARC5/ARC6 lines accomplish this.
     ARC-standard archive headers contain information which
specifies both whether they were formed with ARC5-type ARC-
standard archivers or ARC6-type ARC-standard archivers as
well as the maximum ARC-standard "ARC level" supported by
the original archiver program.  Putting these two pieces of
information together, it is easily possible to determine the
appropriate unarchiver program.  The DEFINEUNPACKER line for
each individual combination must define whether the
unarchiver in the command line is for an ARC5 or ARC6
archive and the maximum ARC level supported. The command
line should include the specific directory and filename with
extension of the executable unarchiver program as well as
any command line switches.  A %A should be placed on the
command line in the place that the archive name would be
specified.  A %S at the end of the command line will cause
JMail to swap itself out of active memory when the
unarchiver is called in order to give the unarchiver program
the maximum amount of memory possible.
     Other types of unarchivers are defined in a more
comprehensible format.  Other than ARC-standard archives,
all types of archivers include a unique "signature"
someplace within the archive.  The offset of this signature
is provided in the "sig offset" portion of the control line.
The signature itself is provided in the "sig" portion.  The
signature may be either typed in using the ASCII characters
of the signature or the numerical ASCII codes may be
provided byte-by-byte with each byte prefaced by a # sign
and followed by a three-digit decimal numerical ASCII code.
These techniques may also be mixed within a single signature
entry.  The command line should include the specific
directory and filename of the executable unarchiver program
as well as any command line switches.  A %A should be placed
on the command line in the place that the archive name would
be specified.  A %S at the end of the command line will
cause JMail to swap itself out of active memory when the
unarchiver is called in order to give the unarchiver program
the maximum amount of memory possible.
     When JMail evaluates an archive, it will first
determine whether the archive is an ARC-standard archive
which begins with an ASCII #26 byte.  If it is, it will be
evaluated according to the various ARC5 and ARC6 lines
listed in the JMAIL.CTL file.  If not, the archive will be
checked for each of the signatures listed in the non-ARC
DEFINEUNPACKER control lines.  If no match is found, the
archive will be written as a BADARC file to the BADFILEPATH.

          USEPACKER <name> <addresses>

     This control line specifies which addresses will
receive which kind of archives.  The "name" entry must refer
to a name entry in a corresponding DEFINEPACKER control
line.    The "addresses" entry may contain one or more
addresses, including the same type of "ALL" entries used in
the JMail Router (Section Five).
     Since the JMail Router often writes directly to packet
files which are not later archived, it is not possible to
use type-10 packets in that environment.  Therefore,
addresses which are specified to receive type-10 packets
will receive netmail processed by the JMail Router in domain-
aware type-2.2 packets (JMail default format).

          USEPACKET <packet type> <address[es]>

     These control lines specify the type of "packet header"
to be used when sending to various remote systems.  The
default packet header type is "2.2" specifying the type 2.2
packet header format defined in FidoNet's FSC-0045 document.
This packet header type includes full 5-D addressing
information.  However, some remote systems may mis-interpret
the extended information in such a packet header and it may
be necessary to use a different format with less complete
information and/or a slightly different format for storing
the information.
     Address entries may include "ALL" in the zone, net,
node, point, or domain areas to specify all addresses in
that scope.  More than one address per line may be
specified.
     If no packet type is specified for a particular
address, JMail will default to the type 2 "stone age" packet
header type to ensure maximum compatibility.
     Packet types which can be used are as follows:

     "TYPE2", "TYPE-2", "STONEAGE", "2" or "CLASSIC2":
Oldest and least complete format.  Uses only net and node
information in packet header.  Advantage is that this format
is compatible on a minimal basis with ALL other processors.
     "CW", "2+" or "2PLUS":  "Capability Word" format
specified in FidoNet's FSC-0048 document.  This format is
preferred on many newer processors which may, for whatever
reason, be unable to handle reception of type 2.2 packets.
This format includes zone, net, node, and point information,
but no domain information.
     "2.2":  Extended type which is JMail's default and is
defined in FidoNet's FSC-0045 document.  This format
includes complete zone, net, node, point, and domain
information.

     The JRoute netmail routing utility will ignore any
USEPACKET lines on netmail messages and will always use
standard type-2 or "STONEAGE" packets to ensure maximum
compatibility with remote systems.  JRoute's "SEND" utility
will respect USEPACKET lines on echomail packets.

          MAXARCSIZE <size in kilobytes>
          MAXPKTSIZE <size in kilobytes>

     These control lines control the maximum packet size of
outbound packets and archives.  When an outbound packet
reaches the MAXPKTSIZE, JMail will compress that packet and
start a new packet for that system.  When an archive reaches
the MAXARCSIZE, JMail will add no more packets to that
archive file and will instead begin a new archive file for
the same system.
     The MAXARCSIZE and MAXPKTSIZE default to 1024 kilobytes
or 1 megabyte.

          ARCNAMEMAX {10|16|32|36}

     The final character of the extension is used in an
archive name to ensure unique filenames for multiple
archives destined for an individual system.  By default,
JMail will use the entire range of 0-9 and A-Z to maximize
the number of available unique archive names.  However, some
networks and/or software packages have technical standards
which limit the acceptable archive names to lesser numbers
(usually 10, 16, or 32).  Accordingly, this option allows
JMail users to modify the maximum character range according
to the demands of individual requirements.
     This entry is optional.
          PASSWORD <address> <password>

     The PASSWORD command establishes a packet-level
password security link with the specified address.  Outbound
packets to that address will be tagged with the appropriate
password.  If the PACKETSECURITY option is active, inbound
packets from the specified address will be checked prior to
any processing to ensure that the appropriate password has
been provided.

          FLAVOR <flavor> <addresses>

     The FLAVOR command establishes a default packet and
archive flavor (NORMAL, HOLD, CRASH, DIRECT, or IMMEDIATE)
for the specified addresses.  The "all" word may be used as
part(s) of the address(es) to specify more than one address.
     These entries are optional.  The default packet and
archive flavor is NORMAL.

Section Three:  JMail Command Line

     Although many JMail command-line commands have the same
functionality as control file options, command line commands
override control file options.  This allows users to set
certain default options in the control file and to override
those options when needed on the command line.

     A.  Path/Filename Overrides

          FC<path and filename>

     This command line option specifies a specific location
and filename for the JMail control file.  If the command is
not present, the control filename will default to JMAIL.CTL
on the JMPATH.

          FL<path and filename>

     This command has the same function as the LOGFILE
control file statement.

          FD<path and filename>

     This command has the same function as the DUPEFILE
control file statement.

          FP<path and filename>

     This command has the same function as the PASSWORDFILE
control file statement.

          FA<path and filename>

     This command has the same function as the AREAFILE
control file statement.

          FO<path and filename>

     This command has the same function as the TOSSFILE
control file statement althought the FULL option is not
available.

     B.  Mail Processing Overrides

          PA

     This command has the same function as the PACKETARCHIVE
control file statement.

          PU

     This command has the same function as the
PACKETUNARCHIVE control file statement.

          PS

     This command has the same function as the
PACKETSECURITY control file statement.

          PI

     This command has the same function as the PACKETIMPORT
control file statement.

          NE

     This command has the same function as the MAILEXPORT
control file statement.

          NI

     This command has the same function as the MAILIMPORT
control file statement.

          EE

     This command has the same function as the ECHOEXPORT
control file statement.

          EF

     This command has the same function as the ECHOFORWARD
control file statement.

          ES

     This command has the same function as the ECHOSECURITY
control file statement.

          SB

     This command has the same function as the SCANBAD
control file statement.

          SN

     This command has the same function as the SCANNET
control file statement.

          SS

     This command has the same function as the SCANSPECIAL
control file statement.

          FS

     This command has the same function as the FULLSCAN
control file statement.

          R<path and filename>

     This command has the same function as the RESCAN
control file statement.
Section Four:  JMail Areas control file (AREAS.BBS)
Reference

     JMail obtains all of its information regarding area
tags, conference linking, message boards, and *.MSG message
directories from the areas file.  This file is usually named
AREAS.BBS and is kept on the JMPATH.  However, other areas
files may be accessed through use of the AREAFILE control
file statement or the FA command line parameter.
     This section outlines the structures of the areas
files.  Rescan files also use this format.  The areas file
is in text format with each line terminated by a hard
carriage return (ASCII code 13).  Word processing codes and
other non-text characters can cause JMail to misinterpret
areas file data.
     On all lines, blank lines will be ignored and data on a
line after a semi-colon character will be ignored.  Invalid
lines will be ignored and an error message will be output to
the screen and the LOGFILE.  Extra space characters within a
line will be ignored.

     A.  First Line

     The first line of the areas file traditionally has a
special purpose.  However, in JMail, this line is simply
ignored.  It may be left blank or be used for informational
messages.

     B. *.MSG areas lines

     In addition to one database message format (such as
Hudson, Goldbase, JAM, or Squish), all versions of JMail are
capable of supporting *.MSG message areas.  On any but a
Squish system, lines intended to specify *.MSG message areas
should be in the following format:

     O <path> <area tag> <address links>

     One a Squish system, the leading "O" and the first
space are omitted and the path is the first word on the
line.
     C.  Hudson areas lines

          1.  Hudson imported areas

     Lines intended to specify imported Hudson (including
GoldBase) message areas should be in the following format:

     <board number> <area tag> <address links>

     For example, the following line would inform JMail that
the SYSOP echo was to be imported to and exported from
Hudson board #45 and that the local system received the
upstream feed from 1:285/2@FidoNet and also linked to
1:285/99@FidoNet.

     45 SYSOP 1:285/2@FidoNet 1:285/99@FidoNet

          2.  Hudson pass-thru areas lines

     Some systems will be links in the distribution chain
for certain echomail conferences, but will not desire to
actually maintain those conference on their systems for
import and export.  Such conferences are "pass-thru"
conferences.  Lines intended to specify pass-thru
conferences should be in the following format:

     P <area tag> <one or more address links>
     D.  Squish areas lines

          1.  Squish imported areas

     JMail's Squish version uses the areas control file
format defined by the original Squish mail processor.  Lines
intended to specify imported Squish message areas should be
in the following format:

     $<Squish root path and filename> <area tag> <address
links>

     The Squish root path and filename specifies the
complete path and 1-8 character filename for the Squish
message area.  This entry must NOT include a filename
extension.

     For example, the following line would inform JMail that
the SYSOP echo was to be imported to and exported from
C:\BBS\SYSOP.SQ? files and that the local system received
the upstream feed from 1:285/2@FidoNet and also linked to
1:285/99@FidoNet.

     $C:\BBS\SYSOP SYSOP 1:285/2@FidoNet 1:285/99@FidoNet

     As each imported area line is read, JMail will ensure
the presence of appropriate Squish message base files.  If
the area does not already exist, a minimal area will be
created.

          2.  Squish pass-thru areas lines

     Some systems will be links in the distribution chain
for certain echomail conferences, but will not desire to
actually maintain those conference on their systems for
import and export.  Such conferences are "pass-thru"
conferences.  On a Squish system, lines intended to specify
pass-thru conferences should be in the following format:

     #<path> <area tag> <address links>

     With JMail, the actual path entry is not required for
pass-thru areas.  However, this entry is retained for
compatibility with the old-style Squish-format areas control
files.  In reality, the path entry can be left off entirely.
However, the # sign is required to designate a pass-thru
area on a Squish-type system.
     E.  JAM areas lines

          1.  JAM imported areas

     JMail's JAM version uses a combination of the Hudson-
format and the Squish format areas control files.  Lines
intended to specify message areas imported to the classic
"Hudson-style" format message base should be in the format
specified for Hudson message bases above.  Lines intended
for a JAM-style message base should be in the Squish format
as follows:

     $<JAM root path and filename> <area tag> <address
links>

     The JAM root path and filename specifies the complete
path and 1-8 character filename for the JAM message area.
This entry must NOT include a filename extension.

     For example, the following line would inform JMail that
the SYSOP echo was to be imported to and exported from
C:\BBS\SYSOP.JH? files and that the local system received
the upstream feed from 1:285/2@FidoNet and also linked to
1:285/99@FidoNet.

     $C:\BBS\SYSOP SYSOP 1:285/2@FidoNet 1:285/99@FidoNet

     As each imported area line is read, JMail will ensure
the presence of appropriate JAM message base header file.
If the area does not already exist, a header file with a
base record will be created.

          2.  JAM pass-thru areas lines

     JMail's JAM version uses the "Hudson" format pass-thru
areas line as defined above.
     F.  Address Links and Special Processing Flags

     Address links entries need not always include the full
and complete address of the system being linked.  If parts
of an address are left off of a particular entry, those
parts will be assumed from the previous address on the line
(or the default AKA address of the local system if the first
entry on the line).
     For example, the following Hudson area line would
specify links in the SYSOP conference to  1:285/2@FidoNet
and 1:285/99@FidoNet as well as 1:285/424.9@FidoNet.

     P SYSOP 1:285/2@FidoNet 99 424.9

     Note that neither of the last two entries includes the
zone, net, or domain parts of the address.  These parts are
assumed to be 1, 285, and FidoNet based on the prior
complete address given.

     Individual addresses on a line may be tagged for
special processing or special handling using JMail special
processing codes.  These codes must precede, without a
space, the address entry they are intended to affect.
Legitimate codes are:

     H - outbound packets are HOLD flavor
     C - outbound packets are CRASH flavor
     D - outbound packets are DIRECT flavor
     I - outbound packets are IMMEDIATE flavor
     * - messages to this link are written to the
SPECIALPATH for external processing
     S - link is send-only.  Messages will not be accepted
from this link.
     R - link is receive-only.  Messages will not be sent to
this link.
     G - Gateway link.  When a message to this node appears
to originate from a different domain than this link is in,
gateway procedures will be used in accordance with accepted
inter-network protocols to place a valid origin line address
on this message.

     For example, the following line would specify links in
the SYSOP conference to 1:285/2@FidoNet, 1:285/99@FidoNet,
and 200:5000/100@MetroNet.  In addition, packets for
1:285/99@FidoNet would be tagged with the HOLD flavor and
messages for 1:285/2@FidoNet would be examined to see if
gateway procedures were necessary (due to the inter-network
link in this conference to 200:5000/400@MetroNet).

     P SYSOP G1:285/2@FidoNet H99 200:5000/400@MetroNet

     Links which are intended to be CRASHed or placed on
HOLD for the remote system should have those special flavors
set using this method rather than using the JRoute utility.
If you use JRoute to change the flavor after each run, JMail
will create a new archive on the next run which includes
that link leading to many small archives cluttering up the
outbound areas and possible ARCNAMEMAX overflowing.

     If you are trying to send something which is normally
placed on HOLD and is taken off of HOLD periodically (maybe
once per week), you should put that link on HOLD in the
areas control file and then use JRoute once per week to take
it off of HOLD.  Alternatively, you could leave it as NORMAL
(default) in the areas control file and use JRoute's SEND
utility to set to hold.  This, however, requires not using
JMail's PACKETARCHIVE control file command or PA command
line command.
Section Five:  JMail Automated Control Facility

     JMail has an integrated utility for downlink nodes to
configure their desired echomail feeds as well as desired
compression method (USEPACKER) and packet type (USEPACKET).
The information necessary to configure and use this
capability is defined in this section.

     A.  JMail Control File Commands

     JMail's automated control facility will use the
following command lines from the JMail control file.

          JMAILID <name>

     A JMAILID line defines a single name which JMail will
use to identify messages from remote systems which are
intended for automatic processing.  Basically, this becomes
JMail's "name" for the purpose of finding those messages
which are intended to alter areas control file links and/or
USEPACKER/USEPACKET control file commands.
     If a JMAILID line is not provided, the automated
control facility will not operate.

          DEFAULTSECURITY <security level 1-32767>

     A DEFAULTSECURITY line will define the default
numerical "security level" for each echomail conference.
Unless this value is overridden by a specific SECUREAREA
line for a specific area, JMail will use this value as the
security level which the downlink node must meet or exceed
in order to request a new link to a conference which
originates within the same domain as itself.
     The "originating domain" of an echomail conference is
defined as the domain of the address listed FIRST on the
areas control file line for that echomail area.
     If no DEFAULTSECURITY line is found, the value will
default to 10.

          XDOMAINSECURITY <security level 1-32767>

     A XDOMAINSECURITY line will define a default numerical
"security level" for each echomail conference in regards to
cross-domain requests.  Unless this value is overridden by a
specific SECUREAREA line for a specific area, JMail will use
this value as the security level which the downlink node
must meet or exceed in order to request a new link to a
conference which originates within the a different domain as
itself.
     The "originating domain" of an echomail conference is
defined as the domain of the address listed FIRST on the
areas control file line for that echomail area.
     If not XDOMAINSECURITY line is found, the value will
default to 100.

          DOWNLINK <address> <password> <flags> <in-domain
security> <cross-domain security>

     These lines provide the information necessary for JMail
to process automated echomail areas and JMail control file
changes from downlinks.
     JMail will require that the password in the subject
line of an automated configuration message (a message
destined to the JMAILID name) the message matches the
password listed in the DOWNLINK line for the remote system.
     The "in-domain security" field specifies this node's
security level for conferences originating within the same
domain.  The "cross-domain security" field specifies this
node's security level for conferences originating in other
domains.  The "flags" field defines those areas control file
flags which should be used on link entries for this node
(Section Four).  Although all three of these fields are
optional, if any later field is used, all prior fields must
be provided.  If not provided, the "in domain security"
field will default to the DEFAULTSECURITY value and the
"cross-domain security" value will default to the
XDOMAINSECURITY value.  If necessary, a single "N" can be
provided in the "flags" field position as a no-value place-
holder.
     The "password" field must not exceed 8 characters in
length.
     If a DOWNLINK line is not found for a specific address,
automated processing requests will not be accepted from that
address.

          UPLINK <domain> <address> <destination ID>
<password> <flags>

     UPLINK lines define the default uplink location for
"forwarded" conference requests.  If a conference requested
by a downlink does not exist in the local areas control
file, JMail will "forward" the request to the appropriate
uplink address for the domain of the requesting system.  The
"destination ID" specifies the ID name for the automated
control facility on the uplink system.  The "flags" field is
optional and defines those areas control file flags which
should be used for this particular uplink address (Section
Four).

          SECUREAREA <areaname> <in-domain> <cross-domain>

     SECUREAREA lines override the default security values
established in DEFAULTSECURITY and XDOMAINSECURITY for a
specific echomail conference.  This can be used, for
example, to place particular conferences completely off-
limits for cross-domain access by specifying a very high
value for the "cross domain" field on a SECUREAREA line.
     B.  Remote Commands

     After verifying the appropriate password on the subject
line of an incoming netmail message, JMail will evaluate the
lines in the text sequentially.  The following commands will
be accepted as valid:

          +<areaname>

     This command adds a conference link to the specified
conference.
     If the conference is found in the local areas control
file, the line will be evaluated to find whether it
originates in the same domain as the remote system.  If so,
the remote system's "in-domain" security level will be
evaluated against the "in-domain" security level of the
conference.  If not, the remote system's "cross-domain"
security level will be evaluated against the "cross-domain"
security level for the conference.  If the remote system has
the appropriate security, the conference will be linked to
the remote system's address using the special processing
flags specified in the remote system's DOWNLINK line.
     If the conference is not found in the local areas
control file, a pass-through link for that conference will
be established linked to the uplink for the remote system's
domain and the remote system.  The request will then be
forwarded to the address specified in the appropriate UPLINK
line.
     In all cases, the remote system will be notified of the
action taken.

          -<areaname>

     This command will terminate a link to the specified
conference.  If no such link exists, the remote system will
be notified of an erroneous request.

          %LIST

     This command will cause JMail to issue a message to the
remote system listing all conferences available on the local
originating within their domain.

          %QUERY

     This command will cause JMail to issue a message to the
remote system listing all conferences currently linked to
that system from the local system.

          %COMPRESS <packer name>

     This command will cause JMail to use the packer type
specified for all archived packets to the remote system.
The "name" field must contain a name specified in a
DEFINEPACKER line on the local system.

          %PACKET <packet type>

     This command will cause JMail to use the packet type
specified when sending to the remote system.  The packet
type specified must be a valid packet type acceptable on a
USEPACKET line.

Section Six:  JMail Netmail Router (JROUTE.EXE)

     JROUTE.EXE is an external utility designed to provide a
domain-aware, point-aware netmail and file-attaching routing
capability.  When executed, JROUTE.EXE will search for a
JMAIL.CTL and JROUTE.CTL file on the JMPATH.

     A.  JRoute command line

     An alternate JMail control file may be specified by
using the command line argument:
      -c<full path and filename of JMAIL.CTL replacement>.
     An alternate routing control file may be specified by
using the command line argument:
     -r<full path and filename of JROUTE.CTL replacement>

     JRoute will also accept a routing command line in the
same format as any routing control file line.  If a valid
routing command line is found, no control file lines will be
processed.  The routing command line will be processed
exclusively.  This feature is intended to give the user the
capability to do quick, one-time routing functions without
the necessity of creating a special control file and/or
schedule.

     JROUTE SHOULD NOT BE USED WITH THE FRONTDOOR MAILER.
FRONTDOOR HAS AN INTERNAL NETMAIL ROUTING CAPABILITY WHICH
WOULD INTERFERE.  FURTHERMORE, JROUTE IS DESIGNED TO OPERATE
SOLELY ON BINKLEY-STYLE *.?LO AND *.?UT FILE-ATTACHES AND
MAIL PACKETS.

     B.  JMail control file commands

     JRoute uses much of the information contained in the
JMail control file.  Section Two of the documentation
provides a detailed reference to JMail control file
commands.

     C.  Routing control file commands

     There are two classifications of routing file commands
-- global and schedule commands.  Global commands are listed
at the beginning of the file prior to any SCHEDULE line.
Schedule commands are listed within individual schedule
areas of the file, each prefaced with a SCHEDULE line (see
sub-section B).
     Global commands will execute on every run.  Schedule
commands will only execute when that schedule is used either
via an explicit designation on a SCHEDULE control file line
or via a SC command line override or when there is no
explicit designation and the day/time parameters on the
SCHEDULE line cause that schedule to be active.

          1.  The SCHEDULE line

     The SCHEDULE line has a unique purpose in the routing
file as it determines which routing commands will be
executed.  The SCHEDULE line is listed in the following
format:

     SCHEDULE <name> <day> <start-time> <stop-time>

     The name parameter gives each schedule a unique, one-
word name which can be specified on the command line using
the following argument:
     -S<Schedulename>
     If the schedule is specified in this fashion, the rest
of the parameters are ignored.  However, if no schedule is
called in the control file or on the command line, the day
parameter will cause the schedule to only function on the
day of the week indicated and the start and stop times will
limit the times of the day during which the schedule will be
active.
     The day parameter must specify at least the first two
letters of the day the schedule is intended to run.  (For
example, Thursday could be abbreviated by using TH.)  If you
want the schedule to run without respect to day of the week,
"ALL" may be used for the day parameter.  The start and stop
time entries must be in 24-hour format.  For example, 9:00pm
would be entered as 21:00.   NOTE:  24:00 is an INVALID
time.  A schedule intended to start at midnight should use
00:00.  A schedule intended to end at midnight should use
23:59.
     If no schedule is specified on the command line or in
the control file, then JMail will use the day and time
parameters to determine which schedule is active.  Only one
schedule may be active at once.  JMail will use the first
schedule in the file which qualifies for activity at the
current day and time.

          2.  Routing commands

     Routing commands are either global (at the beginning of
a file prior to any SCHEDULE line) or listed under a
schedule.  Schedule routing commands will only execute if
their SCHEDULE line is active either by an explicit call in
the control file or on the command line or, if no explicit
schedule name is called, by the restrictions of the day and
time entries.
     Addresses in routing lines have the unique capability
to refer to more than one actual address through the use of
the "ALL" parameter.  For example, the following address
entry would specify all systems in net 285 of zone 1 of the
FidoNet domain:

     1:285/ALL@FidoNet

     Only the domain name may not be "ALL".  "ALL" may be
used to refer to any zone, net, node, or point entry.
     In the following command explanations, "addrs"
specifies that one or more address entries may be placed in
that position.  Parameters enclosed in brackets, [ ], are
optional.

     Many commands make reference to mail "flavors".  Valid
flavors are NORMAL, CRASH, HOLD, DIRECT, and IMMEDIATE.

          ROUTEFROM <addrs>

     The ROUTEFROM command limits the origin addresses of
messages which JMail will accept as valid for routing
through the local system.  Local system AKA addresses are
always presumed to have valid access to be routed through
the local system.
     If this parameter is not present in any global command
or active schedule, then messages will be accepted and
routed from any address.  However, if one or more active
ROUTEFROM lines are found, only messages from either the
local system or the addresses listed in an active ROUTEFROM
line will be processed.

          ROUTETO <addrs>

     The ROUTETO command limits the destination addresses of
messages which JMail will accept as valid for routing
through the local system.
     If this parameter is not present in any global or
active schedule command, then messages destined for any
address will be assumed to have valid access through the
local system.  However, if one or more active ROUTETO lines
are found, only messages destined for the addresses listed
on an active ROUTETO line will be processed.

          MAP <original addr> <mapped addr>

     The MAP command will cause all netmail destined to the
address specified in the original address position to be
"mapped" to the address in the mapped address position.  For
example, the following MAP line would cause all netmail
destined for 1:104/424@FIDONET to be "mapped" to go to
1:285/424@FIDONET instead.

     MAP 1:104/424@FIDONET 1:285/424@FIDONET

     This command is an easy way to compensate for relocated
systems, address changes, and some forms of private nets and
point systems.

          MAPNAME <address> <name>

     The MAPNAME command will cause all netmail to the name
specified to be "mapped" to the specified address regardless
of original destination address.

          DOMAINGATE <route point> <addrs> [EXCEPT <addrs>]

     This command will cause messages destined to the
addresses listed to be "domain gated" through the route
point address.  The optional EXCEPT portion of a line may be
used to list addresses which are exceptions to ALL
parameters used in the first part of the command.
     "Domain gated" messages will be changed to appear to be
addressed to the route point, with the original destination
address retained only in a ^aDOMAIN kludge line in the text.
This mechanism allows for the transmission of netmail
between diverse networks through common interchange points.
This system at the route point address should be capable of
arranging delivery to the destination listed in the DOMAIN
line and should be an accepted interchange point for such a
mechanism.

          ZONEGATE <route point> <addrs> [EXCEPT <addrs>]

     This command will cause messages destined to the
addresses listed to be "zone gated" through the route point
address.  The optional EXCEPT portion of a line may be used
to list addresses which are exceptions to ALL parameters
used in the first part of the command.
     "Zone gated" messages will be changed to appear to be
addressed to the route point, with the original destination
address retained only in a ^aDOMAIN and a ^aINTL kludge line
in the text.  This mechanism allows for the transmission of
netmail between zones within a network through common
interchange points.

          ROUTE [ARC]<flavor><route point><addrs>[EXCEPT
<addrs>]
          ROUTEFILES <flavor><route point><addrs>[EXCEPT
<addrs>]

     This command will cause messages destined to the
addresses listed to be routed through the route point.  The
flavor parameter will determine the output flavor (NORMAL,
HOLD, or CRASH) of the routed message packet.  The optional
ARC parameter will cause the message to be routed and then
archived into a compressed mail bundle for the route point
address.
     ROUTE lines affect the routine of mail packets (.OUT
files).  ROUTEFILES lines affect the routing of file-
attaches (*.FLO) files.
     Routed messages will retain their original source and
destination addresses, they will just be sent through an
intermediary system.  This mechanism allows for the
efficient routing of netmail traffic through common
distribution points.
     In the cases of both ROUTE and ROUTEFILES, JMail will
only affect files which begin as NORMAL in flavor.  HOLD and
CRASH flavored files will not be affected by ROUTE or
ROUTEFILES.  CHANGE1 commands may be used to change the
flavor of CRASH or HOLD packets to NORMAL before ROUTE and
ROUTEFILES commands are executed.
     The flavor change from NORMAL (if any) on a ROUTE or
ROUTEFILES lines will also affect any packets or file-
attaches destined for the address listed in the "route
point" portion of the command line.

          CHANGE1 <from flavor> <to flavor> <addrs>
          CHANGE2 <from flavor> <to flavor> <addrs>

     These commands will cause mail packets and file attach
bundles which are both destined for the listed addresses and
currently in the flavor listed in the from flavor parameter
to be changed to the to flavor listed.
     The CHANGE1 commands are executed at the beginning of
routing  processing before all other commands.  CHANGE2
commands are executed at the end of routing processing.

          POLL <addrs>

     This command will cause JMail to output an empty file
attach bundle in the NORMAL flavor destined for the
addresses listed.  This will cause most mailers to conduct
"polling" of those systems until a successful connection is
obtained.  Systems must be listed specifically -- ALL macros
are not allowed within a POLL line.

          DIRECTPOINT <addrs>

     By default, a message destined for a point address off
of a "boss node" other than the local system, that message
is routed through the point's boss node.  The DIRECTPOINT
command allows JMail to override this default and force the
message to be sent directly to the point system.

          SEND <flavor> <addresses>

     The SEND command is designed to allow JRoute to handle
echomail and netmail archiving on a unified basis.  SEND
will search for echomail packets on the ARCPATH and netmail
*.OUT files on the OUTBOUNDPATH and will archive both types
of packets into an compressed archive with a file-attach in
the flavor specified.  Archive type is specified using the
same USEPACKER lines that are used in the main JMail
program.
     To use SEND to handle echomail archiving, simply make
sure that PACKETARCHIVE is NOT active on the previous JMail
run.  Then run JRoute with the appropriate SEND line(s)
active either in the current schedule or as global command
(at the top of the JRoute control file).  SEND will only
send packets destined for addresses which are specified in a
SEND line, so users of the SEND capability should make sure
that there is an appropriate SEND line for all addresses
which might have echomail packets queued for them on the
ARCPATH.

          LEAVE <addrs>

     LEAVE commands will exempt from any ROUTE, ROUTEFILES,
CHANGE1, or CHANGE2 commands any *.?UT (netmail) and *.?LO
(file-attatch) files which are currently destined for the
address(es) listed.
     D.  Order of Evaluation

     At the beginning of route file processing, a complete
list of active routing commands is compiled.  These
statements are then executed one-by-one in the following
order of evaluation:

     All CHANGE1 commands are executed.
     Each message on NETMAILPATH is read and, if destined
for a remote system, is processed as follows:
          MAP and MAPNAME commands
          ROUTEFROM commands (possible process abort)
          ROUTETO commands (possible process abort)
          DOMAINGATE commands
          ZONEGATE commands
          ROUTE commands (DIRECTPOINT overrides)
          Output to packet format (possible archiving)
     All SEND commands are executed.
     All POLL commands are executed.
     All CHANGE2 commands are executed.

Section Seven:  JPACK Signature File Packer (JPACK.EXE)

     The JPACK.EXE utility is designed to "pack" the
signature file according to the criteria set in RETAIN
statements within the JMail control file.  JPack should be
run at least once daily to prevent unnecessary growth in the
size of the signature file(s).  JPack will require at least
as much free disk space as the size of the original
signature files.

     A.  Command-line options

     JPack only accepts three command line options:

          -C<path and filename>

     This option specifies the path and filename of the
JMail control file.  By default, this is assumed to be
JMAIL.CTL on the JMPATH or in the current directory if the
JMAIL environment variable is not set.

          -D<path and filename without extension>

     This option specifies the path and filename (without
extension) of the signature file to be packed.  By default,
this is assumed to be ZDUPE on the JMAILPATH.

          -T<path and filename>

     This option will cause JMail to output a traffic report
file containing information about the number of messages
received in each area each day.  By default, no traffic
report is produced.

     B.  JMail Control-file options

     Unless overriden on the command line, JPack looks for
its control file using filename JMAIL.CTL on the JMPATH.
Signature retain criteria is contained in one or more RETAIN
lines.  Retain lines are listed in the following manner:

          RETAIN [Areaname] <days>

     The <days> parameter specifies how many days old a
signature must be before it is thrown away.  Recommended
value is 10.
     If an area name is listed, the RETAIN line will only
apply to signatures from the corresponding echomail area.
If no areaname is listed, then the number will be assumed to
be the default RETAIN value for all areas not specifically
listed in another RETAIN line.
Appendix One:  Binkley Domain Setup

     JMail is the first domain-aware mail processor and
router.  While this gives an explosion of new options and
capabilities, it also produces a few complexities in setup.
     BinkleyTerm is capable of functioning in a domain-aware
mode, but this option must be specified in the BinkleyTerm
configuration file (BINKLEY.CFG).  If the NODOMAIN option is
used on the OUTBOUNDPATH line in JMAIL.CTL or is a "NODOMAIN
all:all/all@ALL" control file line is used, Binkley's domain-
aware capabilities should NOT be used as they would cause
unintended misinterpretations of inbound address information
during EMSI handshaking.
     First, all ADDRESS lines in the BinkleyTerm
configuration file must be edited to include domain entries.
BinkleyTerm uses a slightly different domain parameter than
JMail.  While JMail uses a 1-8 character domain name,
BinkleyTerm uses the 1-8 character domain name followed by a
period and a three-letter extension.  Some networks (such as
FidoNet) use an extension of ".org" while most other
networks use an extension of ".ftn".
     Secondly, each domain specified must have a DOMAIN line
specified below in the BinkleyTerm configuration file.  The
format of this line is as follows:

     DOMAIN <full domain name> <1-8 char domain name>
<nodelist filename without extension>

     The first two options are self-explainatory.  The last
option gives you the capability to use a separate compiled
nodelist file for each domain.  To use the same file for all
domains (as most systems will), just put the filename
without extension appropriate for the nodelist type you are
using.  For example, the following line might be used to
specify the FIDONET domain on system using a version 7
nodelist:

     DOMAIN fidonet.org fidonet nodex

     The following line might be used to specify the
METRONET domain on a system using a version 6 nodelist:

     DOMAIN metronet.ftn metronet nodelist

     Additionally, for each domain, BinkleyTerm requires a
DOMAINKLUDGE line to enable BinkleyTerm to deduce the domain
portion of addresses provided by non-domain-aware systems.
The format of this line is:

     DOMAINKLUDGE <zone number> <domain name>

     For example, for MetroNet (which uses zone number 200),
the following line would be input to BINKLEY.CFG:

     DOMAINKLUDGE 200 metronet.ftn

     Only BinkleyTerm versions after 2.40 have this domain-
aware capability.  Versions above 2.50 are recommended due
to the inclusion of EMSI multi-address handshaking which
signficantly increases the efficiency of operations on multi-
domain systems.  The latest Binkley versions and related
documentation can be obtained from the JMail support sites.
     On multi-tasking systems, it is also necessary to
include a TASKNUMBER line in the BINKLEY.CFG file.  The
TASKNUMBER command word is followed by a number unique for
that Binkley window (it is designed for multi-line systems).
The TASKNUMBER line activates the use of Binkley *.BSY files
which JMail uses to avoid conflicts with Binkley file-
transfer sessions.  On a normal multi-tasking system running
only a single copy of Binkley but having the potential to
run JMail simultaneously with Binkley in another window, the
following BINKLEY.CFG line should be sufficient:

     TASKNUMBER 1

Appendix Two:  Addressing Issues

     The domain-aware nature and unique flexibility and
accuracy of JMail's address processing can expose many of
the shortcomings in other echomail processors which might
otherwise remain unnoticed.
     Most commonly, problems will result from the
differences in how JMail handles addressing of echomail
messages versus how some other echomail processors handle
echomail message addressing.
     When processing an echomail message without NOSEENPROC
active, JMail will scan the existing seen-by lines to ensure
a particular copy is not being sent to an address which has
already seen the message.  Since most echomail processors
(including JMail) put all their AKA addresses from the
current zone and domain in the seen-by lines, it is usually
not a worry that one will be sending a copy to a system
which may have already seen the message under a different
AKA address.
     However, some echo processors, including JMail if the
NOSEENPROC control file opition is set, will only scan the
path line of message to prevent duplicate message
production.  Unlike seen-by lines, path lines only contain a
single address (almost always the AKA which is also in the
"from" blocks of the message header).  If the remote system
is linked to a different AKA in their areas control file,
this can cause that system to immediately produce a
duplicate message back towards the local system based on the
limitations imposed by the single address format of the path
line.
     While processing the much-shorter path lines may lead
to small increases in processing speed, such techniques do
have the effect of rendering the echomail system vulnerable
to human error in the form of links made to incorrect AKA
addresses.  The best way to prevent such situations is, of
course, to use echomail processors which process seen-by
lines instead of just path lines or to simply remain very
careful that both sides of an echomail link have proper
entries in areas control files.
     Another way to resolve the problem is through the use
of USEAKA lines on the JMail system.  If, for example, the
local system has 2:253/157@Fidonet as its primary FidoNet
address and 2:25/22@FidoNet as an AKA address and a
particular remote system (say 2:253/156@FidoNet) insists on
linking to 2:25/22@FidoNet, you may force the local system
to use 2:25/22@FidoNet only when dealing with that
particular system by using the following USEAKA line in the
JMail control file:

     USEAKA 2:25/22@FidoNet 2:253/156@FidoNet

     USEAKA lines may be used to resolve a variety of
similar addressing situations where JMail needs to be told
to go outside of its normal AKA-matching system.
Appendix Three:  Sample Command Lines

     This section will outline some suggested command line
configurations for JMail operations.  It is always advisable
to implement options which will be active on all runs (such
as PACKETIMPORT, PACKETSECURITY, ECHOSECURITY, and
PACKETARCHIVE) in the control file instead of on the command
line.
     All the following examples assume that the current
directory is already set to the location of the JMail
control file or that a JMPATH has been defined via a JMAIL
environment variable.

     A.  Normal JMail Operation

     Normal JMail operations would have JMail handling all
echomail archiving and attempt to securely process any
waiting mail packets and/or archives.  Accordingly,
PACKETARCHIVE, PACKETUNARCHIVE, PACKETIMPORT, and
ECHOSECURITY would be set in the JMail control file.
(NETIMPORT might also be set if netmail is to be imported to
the message base.)
     Under such a configuration, after receiving mail from
Binkley or Frontdoor, all that would be necessary would be
to run the JMail executable (JMAIL-?.EXE) with no command
line parameters.  This run would be followed by a JROUTE.EXE
run on Binkley-type systems, again with no command line
options necessary.
     Exporting from the message base would be accomplished
simply by adding command line options EE (for exporting
echomail) and/or NE (for exporting netmail) to the JMail
command line.  That run would also be followed by a JRoute
run with no command line options.
     For example, the following would do normal mail
processing after mail has been received on the local system
(Hudson-Binkley system is assumed for this example):

     JMAIL-H.EXE
     JROUTE.EXE

     To accomplish the same thing using command line options
instead of control file defaults, the following command
lines would be used in the batch file:

     JMAIL-H.EXE PU PA PI
     JROUTE.EXE

     The following would accomplish exporting or any netmail
and/or echomail:

     JMAIL-H.EXE NE EE PA
     JROUTE.EXE

     B.  JRoute SEND Archiving

     While JMail has the capability to control flavors on a
case-by-case basis in the areas control file, some users may
wish to have everything to a given node, group of nodes, or
even all nodes to be set to a flavor other than the default
NORMAL flavor.  This can be done best by using JRoute's SEND
ability.
     The control file configuration would be much like that
for normal JMail operations (above) with the exception that
the PACKARCHIVE option would NOT be active.  JRoute could
then be run with the appropriate SEND lines in the JRoute
control file.  If there are any remaining packets to be
archived (if the SEND lines did not encompass all outbound
links), JMail could be run again with PA on the command line
to archive any remaining packets.
     The following command lines would accomplish this
within batch files:

     JMAIL-H.EXE PU PI
     JROUTE.EXE
     JMAIL-H.EXE PA

     C.  Rescanning message areas

     There may be times when it is necessary to rescan
existing messages in one or more areas to one or more links.
In this situation, it is necessary first to create a
JRESCAN.BBS (in the same format as an areas control file)
listing the areas to be rescanned and the links they are to
be sent to.  Then, to accomplish the actual rescanning, run
JMail with the following command line (PA could be left off
on systems using JRoute SEND archiving):

     JMAIL-H.EXE EE R PA

     JMail will then scan copies of all messages which exist
in the local message base in the areas defined in the
JRESCAN.BBS file to the links specified in the JRESCAN.BBS
file.
Appendix Four: Acknowledgements and Credits

     BinkleyTerm is copyright Bit Bucket Software.
     FrontDoor is copyright Joachim Homrighausen.
     QuickBBS and Goldbase are copyright Pegasus Software.
     Remote Access is copyright Andrew Milner.
     Squish is copyright Scott Dudley.
     ARC is copyright System Enhancement Associates.
     ZIP and PKZIP are copyright PKWare, Inc.

