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 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 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 [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 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 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 .. 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 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 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 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 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 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 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 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 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 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 [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 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 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 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 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 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 [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 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 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 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 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 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 ADDRESS 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 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 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 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 [...] ASSUMEZONE [...] 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 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 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 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 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 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 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 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 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 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} DEFINEUNPACKER ----------------------------------------------------------------- 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 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 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 MAXPKTSIZE 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
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 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 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 This command has the same function as the LOGFILE control file statement. FD This command has the same function as the DUPEFILE control file statement. FP This command has the same function as the PASSWORDFILE control file statement. FA This command has the same function as the AREAFILE control file statement. FO 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 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
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:
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 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: $
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: #
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: $
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 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 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 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
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
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 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: + 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. - 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 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 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. An alternate routing control file may be specified by using the ----------------------------------------------------------------- JMail 2.80 Page 36 command line argument: -r 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 The name parameter gives each schedule a unique, one-word name which can be specified on the command line using the following argument: -S 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 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 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 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
The MAPNAME command will cause all netmail to the name specified to be "mapped" to the specified address regardless of original destination address. DOMAINGATE [EXCEPT ] 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 [EXCEPT ] 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][EXCEPT ] ROUTEFILES [EXCEPT ] 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 CHANGE2 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 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 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 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 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 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 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 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] The 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 <1-8 char domain name> 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 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