













                                      JMAIL

                                   Version 2.80

                            PROZ Software -- 1993-1995





















     This  Document is  formated for  viewing on  your computer  or sending
     directly  to your  printer.  It will  print properly  on a  dot matrix
     printer or a laser printer.  To print this document type the following
     in at the DOS  prompt provided  your printer is  connected to  printer
     port number one.

          TYPE JMAIL.TXT >LPT1

     The above command line should cause  your computer to send this entire
     document to your printer.


                                 Table of Contents

    SECTION ONE:  INTRODUCTION                                           1

    JMAIL PRODUCT LICENSE                                                1

    PRODUCT INFORMATION                                                  1
      INTRODUCTION                                                       1
      EQUIPMENT REQUIRED                                                 1
      PRODUCT SUPPORT INFORMATION                                        2
      REGISTRATION                                                       2

    INTRODUCTION TO NETWORK MAIL                                         3
      WHAT IS ECHOMAIL?                                                  3
      WHAT IS NETMAIL?                                                   4
      THE 5-DIMENSIONAL NETWORK ADDRESS                                  5
      MAIL PACKETS AND BUNDLES                                           5

    SETTING UP JMAIL                                                     6
      JMPATH                                                             6
      CONTROL FILE                                                       6
      ROUTING CONTROL FILE                                               6
      AREAS CONTROL FILE                                                 6

    JMAIL TERMINATION CODES                                              7
      ABNORMAL TERMINATIONS                                              7
      ERRORLEVELS                                                        7

    SECTION TWO:  JMAIL CONTROL FILE (JMAIL.CTL)                         7

    SYSTEM PATHS                                                         7
      JMPATH                                                             7
      JMAILPATH                                                          8
      BBSPATH                                                            8
      INBOUNDPATH                                                        8








      OUTBOUNDPATH                                                       9
      ARCPATH                                                            9
      UNARCPATH                                                          9
      NETMAILPATH                                                        9
      BADPATH                                                           10
      DUPEPATH                                                          10
      SPECIALPATH                                                       10
      BADFILEPATH                                                       10
      ATTACHPATH                                                        10
      PACKETTOSSPATH                                                    11
      SPECIALINBOUND                                                    11
      DBRIDGEPATH                                                       11
      SWAPPATH                                                          12

    SYSTEM FILES                                                        12
      AREAFILE                                                          12
      DUPEFILE                                                          12
      LOGFILE                                                           12
      BILLINGFILE                                                       12
      TOSSFILE                                                          13
      OPUSEXPORTFILE                                                    13
      QUICKNETEXPORTFILE                                                13
      QUICKECHOEXPORTFILE                                               13
      SQUISHEXPORTFILE                                                  13
      JAMEXPORTFILE                                                     13

    ADDRESS OPTIONS                                                     14
      ADDR                                                              14
      ADDRESS                                                           14
      HIDDEN                                                            14
      USEAKA                                                            14
      ADDSEENBY                                                         14
      ASSUMEDOMAIN                                                      14
      ASSUMEZONE                                                        15
      NODOMAIN                                                          15

    BBS OPTIONS                                                         15
      NETMAILBOARD                                                      15
      NOIMPORT                                                          15
      SPECIALIMPORT                                                     16
      REBUILD                                                           16
      NOPATH                                                            16
      NOSEENBY                                                          16
      SHOWARRIVED                                                       16
      FULLSCAN                                                          17
      RESCAN                                                            17
      NOSTOMPORIGIN                                                     17
      ORIGINFORMAT                                                      17
      STOMPTEAR                                                         18
      NODELETE                                                          18
      LENIENT                                                           18









    SYSTEM OPTIONS                                                      18
      SYSOP                                                             18
      REG                                                               18
      BINKLEY                                                           19
      DESQVIEW                                                          19
      SCREENLEVEL                                                       19
      DISKLEVEL                                                         19
      LOCK                                                              19
      SMALLSWAP                                                         20
      RECFIX                                                            20

    MAIL PROCESSING OPTIONS                                             20
      PACKETARCHIVE                                                     21
      PACKETUNARCHIVE                                                   21
      PACKETSECURITY                                                    21
      PACKETIMPORT                                                      21
      ECHOEXPORT                                                        21
      ECHOFORWARD                                                       21
      ECHOSECURITY                                                      22
      MAILEXPORT                                                        22
      NETIMPORT                                                         22
      SCANBAD                                                           22
      SCANSPECIAL                                                       22
      SCANNET                                                           22
      NODUPE                                                            23
      TINYSEENBY                                                        23
      NOSEENPROCESS                                                     23
      GATEORIGIN                                                        23
      IGNOREMSGID                                                       23
      EXACT                                                             23
      POLLONREQ                                                         24

    ARCHIVES AND PACKETS                                                24
      DEFINEPACKER                                                      24
      DEFINEUNPACKER                                                    24
      USEPACKER                                                         25
      USEPACKET                                                         26
      MAXARCSIZE                                                        26
      MAXPKTSIZE                                                        26
      ARCNAMEMAX                                                        27
      PASSWORD                                                          27
      FLAVOR                                                            27

    SECTION THREE:  JMAIL COMMAND LINE                                  27

    PATH/FILENAME OVERRIDES                                             27
      FC                                                                27
      FL                                                                28
      FD                                                                28
      FP                                                                28
      FA                                                                28
      FO                                                                28









    MAIL PROCESSING OVERRIDES                                           28
      PA                                                                28
      PU                                                                28
      PS                                                                28
      PI                                                                28
      NE                                                                28
      NI                                                                29
      EE                                                                29
      EF                                                                29
      ES                                                                29
      SB                                                                29
      SN                                                                29
      SS                                                                29
      FS                                                                29
      R                                                                 29

    SECTION FOUR:  JMAIL AREAS CONTROL FILE (AREAS.BBS) REFERENCE       29

    FIRST LINE                                                          30

    *.MSG AREAS LINES                                                   30

    HUDSON AREAS LINES                                                  30
      HUDSON IMPORTED AREAS                                             30
      HUDSON PASS-THRU AREAS LINES                                      30

    SQUISH AREAS LINES                                                  31
      SQUISH IMPORTED AREAS                                             31
      SQUISH PASS-THRU AREAS LINES                                      31

    JAM AREAS LINES                                                     31
      JAM IMPORTED AREAS                                                31
      JAM PASS-THRU AREAS LINES                                         32

    ADDRESS LINKS AND SPECIAL PROCESSING FLAGS                          32

    SECTION FIVE:  JMAIL AUTOMATED CONTROL FACILITY                     33

    JMAIL CONTROL FILE COMMANDS                                         33
      JMAILID                                                           33
      DEFAULTSECURITY                                                   34
      XDOMAINSECURITY                                                   34
      DOWNLINK                                                          34
      UPLINK                                                            35
      SECUREAREA                                                        35

    REMOTE COMMANDS                                                     35
      +                                                                 35
      -                                                                 36
      %LIST                                                             36
      %QUERY                                                            36








      %COMPRESS                                                         36
      %PACKET                                                           36

    SECTION SIX:  JMAIL NETMAIL ROUTER (JROUTE.EXE)                     36

    JROUTE COMMAND LINE                                                 36

    JMAIL CONTROL FILE COMMANDS                                         37

    ROUTING CONTROL FILE COMMANDS                                       37
      THE SCHEDULE LINE                                                 37
      ROUTING COMMANDS                                                  38
        ROUTEFROM                                                       38
        ROUTETO                                                         39
        MAP                                                             39
        MAPNAME                                                         39
        DOMAINGATE                                                      39
        ZONEGATE                                                        39
        ROUTE                                                           40
        ROUTEFILES                                                      40
        CHANGE1                                                         40
        CHANGE2                                                         40
        POLL                                                            40
        DIRECTPOINT                                                     40
        SEND                                                            41
        LEAVE                                                           41

    ORDER OF EVALUATION                                                 41

    SECTION SEVEN:  JPACK SIGNATURE FILE PACKER (JPACK.EXE)             42

    COMMAND LINE OPTIONS                                                42
      -C                                                                42
      -D                                                                42
      -T                                                                42

    JMAIL CONTROL FILE OPTIONS                                          42
      RETAIN                                                            42

    APPENDIX ONE:  BINKLEY DOMAIN SETUP                                 43
      DOMAIN LINES                                                      43
      DOMAINKLUDGE LINES                                                43
      TASKNUMBER LINE                                                   44

    APPENDIX TWO:  ADDRESSING ISSUES                                    45

    APPENDIX THREE:  SAMPLE COMMAND LINES                               46
    NORMAL JMAIL OPERATION                                              46
    JROUTE SEND ARCHIVING                                               46
    RESCANNING MESSAGE AREAS                                            47

    APPENDIX FOUR:  ACKNOWLEDGMENTS AND CREDITS                         48









    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.
         -----------------------------------------------------------------
           JMail 2.80                                           Page 1







         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.
         -----------------------------------------------------------------
           JMail 2.80                                           Page 2







         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.
         -----------------------------------------------------------------
           JMail 2.80                                           Page 3







         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
         -----------------------------------------------------------------
           JMail 2.80                                           Page 4






    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.
         -----------------------------------------------------------------
           JMail 2.80                                           Page 5






    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,
         -----------------------------------------------------------------
           JMail 2.80                                           Page 6






    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.

         -----------------------------------------------------------------
           JMail 2.80                                           Page 7






              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
         -----------------------------------------------------------------
           JMail 2.80                                           Page 8






    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.
         -----------------------------------------------------------------
           JMail 2.80                                           Page 9







              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
         -----------------------------------------------------------------
           JMail 2.80                                           Page 10






    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
         -----------------------------------------------------------------
           JMail 2.80                                           Page 11






    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
         -----------------------------------------------------------------
           JMail 2.80                                           Page 12






    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
         -----------------------------------------------------------------
           JMail 2.80                                           Page 13






    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
         -----------------------------------------------------------------
           JMail 2.80                                           Page 14






    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
         -----------------------------------------------------------------
           JMail 2.80                                           Page 15






    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.

              SHOWARRIVED

         This  option will cause all imported messages to be appended with
    a  hidden  line showing the date and  time that the message arrived on
    the local system.
         This entry is optional.
         -----------------------------------------------------------------
           JMail 2.80                                           Page 16







              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]

         -----------------------------------------------------------------
           JMail 2.80                                           Page 17






              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
         -----------------------------------------------------------------
           JMail 2.80                                           Page 18






    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).
         -----------------------------------------------------------------
           JMail 2.80                                           Page 19






         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.

              CHECKTIME

         CHECKTIME  will cause JMail to verify  the time stamp on incoming
    echomail  messages before processing. If  CHECKTIME is specified, each
    incoming  echomail  message will be checked  and  if the time stamp is
    found  to  be more than 48 hours in  the future or more than 1 year in
    the past, the message will be treated as a bad message.
         This entry is optional.

              BIOSSCREEN

         By  default,  JMail  will use  direct  screen  writes to maximize
    processing  speed.  However,  on some  systems,  such  as some systems
    running  Desqview,  this may be undesirable  and  actually result in a
    degradation  of  system  performance.  BIOSSCREEN  will disable direct
    screen writes and force all screen writes to use standard BIOS calls.
         This entry is optional.

         -----------------------------------------------------------------
           JMail 2.80                                           Page 20






         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
         -----------------------------------------------------------------
           JMail 2.80                                           Page 21






    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

         -----------------------------------------------------------------
           JMail 2.80                                           Page 22






         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
         -----------------------------------------------------------------
           JMail 2.80                                           Page 23







         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>

         -----------------------------------------------------------------
           JMail 2.80                                           Page 24






         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
         -----------------------------------------------------------------
           JMail 2.80                                           Page 25






    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
         -----------------------------------------------------------------
           JMail 2.80                                           Page 26






    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.

         -----------------------------------------------------------------
           JMail 2.80                                           Page 27






              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.

         -----------------------------------------------------------------
           JMail 2.80                                           Page 28






              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
         -----------------------------------------------------------------
           JMail 2.80                                           Page 29






    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
         -----------------------------------------------------------------
           JMail 2.80                                           Page 30






    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
         -----------------------------------------------------------------
           JMail 2.80                                           Page 31






    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
         -----------------------------------------------------------------
           JMail 2.80                                           Page 32






         * - 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
         -----------------------------------------------------------------
           JMail 2.80                                           Page 33






    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
         -----------------------------------------------------------------
           JMail 2.80                                           Page 34






    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
         -----------------------------------------------------------------
           JMail 2.80                                           Page 35






    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
         -----------------------------------------------------------------
           JMail 2.80                                           Page 36






    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
         -----------------------------------------------------------------
           JMail 2.80                                           Page 37






    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
         -----------------------------------------------------------------
           JMail 2.80                                           Page 38






    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
         -----------------------------------------------------------------
           JMail 2.80                                           Page 39






    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
         -----------------------------------------------------------------
           JMail 2.80                                           Page 40






    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.





         -----------------------------------------------------------------
           JMail 2.80                                           Page 41






    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.






         -----------------------------------------------------------------
           JMail 2.80                                           Page 42






    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
         -----------------------------------------------------------------
           JMail 2.80                                           Page 43







         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


































         -----------------------------------------------------------------
           JMail 2.80                                           Page 44






    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.






         -----------------------------------------------------------------
           JMail 2.80                                           Page 45






    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
         -----------------------------------------------------------------
           JMail 2.80                                           Page 46






    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.




















         -----------------------------------------------------------------
           JMail 2.80                                           Page 47






    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.











































         -----------------------------------------------------------------
           JMail 2.80                                           Page 48


