ZmailH v 1.25 Copyright 1989,90,91 -- PROZ Software Written by: Charles Whitlatch and Jason Steck User Documentation LICENSING ZmailH and other 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. ZmailH 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. INTRODUCTION WHAT IS ZmailH? ZmailH is a integrated netmail/echomail processor designed for use on Hudson-style message bases in a network environment compatible with the FidoNet Technical Standards. At present, "Hudson-style message bases" include those in use on such systems as QuickBBS, Remote Access, and SuperBBS. This manual is intended to assist you in setting up and operating your ZmailH system. REQUIRED EQUIPMENT ZmailH requires the following equipment and software support to operate: 1) PC-DOS/MS-DOS 3.0 or later. 2) At least 300k of RAM available. 3) An existing Hudson-style message base. ZmailH OPERATION Crash Recovery ZMailH will occasionally write a Zmail.CRF file in the BBS or ZMail directory. This file is called the Crash Recovery File. It tells ZMailH the position and file name of the packet file that was being processed when the system stopped. If this file exists on the system DO NOT DELETE it ZMailH will delete it when it has been utilized. ZmailH Exit Errorlevels When ZmailH has completed its processing or stops for any reason it will set the errorlevel to one of the following exit codes. Errorlevel Meaning 0 No Error / Processing performed 1 DOS Error 2 Configuration Error 3 Insufficient Disk Space 4 Net Mail Tossed/Extracted 5 Echo Mail Tossed/Extracted 255 User Abort (^C) You may wish to trap these errorlevels with a batch file and process them accordingly. If a DOS error is encountered, ZmailH will create or append to an error log in the current directory. The name of this file is ZM_ERROR.LOG. This is an ASCII file that contains the state of ZmailH at the time of the crash. ie. It contains all of the command line parameters, system generated variables, and other information. This file should prove useful for determining why the system crashed. INSTALLATION ZmailH may be run from any directory. Most often the program (ZmailH?.EXE) is placed in the BBS directory. The Control file must be in the directory that is active when ZmailH is run or it must be specified on the command line (See Command Line Options). INTER-ZONE MAIL SETUP If ZmailH is used for inter-zone mail there are several adjustments which must be made to the system configuration. Ommm based systems, such as Binkley, require that each zone have a separate outbound directory. Non Ommm based systems, such as SEAdog and FrontDoor, will only require special outbound directories if they are having ZmailH create and or archive packets. The default outbound directory, as specified in the Zmail.ctl file, coincides with the primary address zone. Alternate zones are handled in directories that are named as follows: .ZZZ where ZZZ is the zone number in hex and outbound is your default outbound directory. If ZmailH is used to process echo mail in more than one zone special care must be taken to ensure that the systems that you are sending the mail to are also addressing your system correctly. The Key File (.KEY) ZmailH uses a key file to ensure that only licensed copies of the program are being used. The key file must be present in the ZzyzxPath directory or the BBS directory if the ZzyzxPath is not specified. The Key file is provided when you register your copy of the program. If an appropriate key file is NOT found ZmailH will require manual intervention to run. The Control File (Zmail.ctl) ZmailH uses a control file called Zmail.ctl. This file contains information pertaining to the environment in which ZmailH is to run. It must be in the current directory unless specified on the command line. Each line in the Zmail.ctl file is limited to 255 characters. Any characters that follow a semi-colon (;) are considered comments and are ignored. The Control file provided on the ZmailH disk can be edited or a new Control file may be created using any ASCII editor. If you do not have any other editor you can use the DOS EDLIN editor (See your DOS manual for more information). Any command line option may be included in the control file. Addressing Options NODE The first statement in the control file is the NODE statement. This statement specifies what address(es) the BBS uses. The node statement may contain more than one address and there may be more than one node statement in the control file. The order in which the addresses are listed is important. The first address listed must be the primary address. All AKA's should be listed in priority order. Unless explicitly stated otherwise ZmailH will assume that the first address is in zone 1. ZmailH uses an extended addressing scheme that includes a private network address in the address. The structure of the Node statement is: NODE [:]/[.[/]]. If the node statement was NODE 1:999/102 then ZmailH would operate with an address of zone 1, Net 999, and node 102. NODE 999/102 would have the same effect. If the system also had an address in zone 2 then the zone two address would also need to be listed. For example: Node 999/102 2:333/444 would specify that the BBS has a primary address of 1:999/102 and a secondary address of 2:333/444. The primary address is used whenever ZmailH is exporting a message from the system and there is no other "closer" address. If the BBS in the above example were to send a message to a board in zone 2 then the address ZmailH would use as the origin address would be 2:333/444. if the message were to go to zone 3 then ZmailH would use the 1:999/102 (primary) address. The distinction between addresses also carries over to the net level. Suppose a BBS had the following node statement in the Zmail.ctl file: Node 999/102 90/3 2:333/444. If this system were to send a message to 1:90/6 the address that ZmailH would use for the origin address would be 1:90/3. If the message was going to 2:90/6 then ZmailH would use the 2:333/444 address. If the message was going to 3:90/6 then ZmailH would use the 1:999/102 address. To specify a private net address to be used as part of a point net attached to the system the statement would look like: Node 999/102.102102/0. This would inform ZmailH that the private net 102102 is also used by node 999/102. ZmailH will also automatically forward any mail addressed to 999/102.xxx to 102102/xxx. ZmailH will automatically map all 102102/x addresses as necessary. All echo mail that is passed into or out of the point network will have the seen-by lines stripped down. On import they will only contain the addresses within the private net, on export they will only contain the addresses outside the private net. It should be noted that all 'points' under this node should address their echo mail to 102102/0. MAP The MAP command allows ZmailH to know of point net addresses without having to specify the full address in the AREAS.BBS file. The structure of this statement is: MAP [:][]/./. If the map statement was MAP 1:999/102.120120/0 this would specify that 1:199/102 was the boss node for private net 120120. Path Options MAILPATH The MailPath statement specifies the directory in which net mail *.MSG files will be stored. This control statement is required and should be of the form: MAILPATH [:]. The MailPath is also used by several other programs. The directory that it points to is one of the interface points between these programs. Some mailers of the SEAdog type use this directory to store messages that list files to be sent. Other mailers like Binkley never use this directory directly. In a Binkley environment Ommm would bundle the messages in the MailPath directory and create packets or archived packets. An example of the MailPath statement would be: MAILPATH C:\MAILER\MAIL FILESPATH FilesPath is the path that points to the directory in which your mailer places inbound files. This is where ZmailH will find the packets and archived packets that need to be processed. This is another interface directory. Both ZmailH and your mailer must point to this directory. The structure of the FilesPath statement is: FILESPATH [:]. An example would look like: FILESPATH C:\MAILER\FILES. OUTBOUNDPATH The OutboundPath specifies where the final archived mail packets should be stored. On an Ommm system this should be the same path that is specified on the Ommm command line as the holding path. On SEAdog type systems this may be any directory. The structure of this statement is: OUTBOUNDPATH [:]. An example would look like: OUTBOUNDPATH C:\MAILER\OUTBOUND. BBSPATH The BBSPATH specifies where your BBS software is located. If no BBS software is being used on the system then this path should point to a directory where ZmailH files should be stored. THIS DIRECTORY MUST BE DEFINED. The structure of this statement is: BBSPATH [:]. An example would look like: BBSPATH E:\BBS. EXPRESSMAIL Several off line message reading programs place packeted mail in special directories. These systems also create messages that have the origin address of the current system. If these packets are moved to the netfile directory ZmailH will detect them as forgeries (originating on the current system) and will toss them to bad messages. To circumvent this problem ZmailH uses an ExpressMail directory. The expressmail directory is where the offline generated messages will be stored. WARNING: The ExpressMail directory is not checked for forgeries, do not allow non-automated access to this directory if you are concerned about forgeries. The structure of this statement is: EXPRESSMAIL [:]. An example would look like: EXPRESSMAIL C:\XRS\ DUPPATH The DupPath is an optional statement that specifies where duplicate *.MSG messages should be placed. If the statement is omitted no *.MSG files will be created and the processing of packets will be much faster. The structure of the DupPath statement is: DUPPATH [:]. An example would be: DUPPATH E:\MAIL\DUPS. BADMSGS The BadMsgs is an optional statement that specifies in what directory any bad messages should be stored. This command has the same limitations, restrictions as the DupPath statement. Bad messages are created when using echo security or when mail forwarding and echo forwarding are not enabled. The structure of this statement is: BADMSGS [:]. An example is: BADMSGS E:\MAIL\BAD ARCHIVEPATH The ArchivePath is an optional statement that specifies where temporary outbound packets should be created and updated. If not specified then the outbound path is used. The ArchivePath statement allows the sysop to specify a drive with extra free space to be used to create the outbound packets. Some speed increase may be seen if the ArchivePath is on a different drive than the Outbound path. The structure of this command is: ARCHIVEPATH [:]. An example is: ARCHIVEPATH F:\OUT WARNING: Do NOT use a RAM disk for the Archive Path. Due to the nature of the ZmailH disk space detection algorithm it is possible to have incomplete packets in the ArchivePath between runs. Should the power fail during one of these periods the incomplete packets and all messages in them would be lost. UNARCPATH The UnArcPath is an optional statement that specifies where the inbound mail packets are to be unpacked. If it is not specified then the FilesPath is used. The ArchivePath warning also applies to the UnArcPath statement. The structure of the UnArchive Path is: UNARCHIVEPATH [:]. An example is: UNARCHIVEPATH F:\IN ZMAILPATH The ZMAILPATH is an optional statement that specifies where the ZMailH ancillary files will be found. ZmailH will look in this directory for the signature and Key files. The structure of this statement is: ZMAILPATH [:]. An example would look like: ZMAILPATH E:\BBS\ZMAIL SWAPPATH The SWAPPATH is an optional statement that specifies the directory (preferably a RAMDisk) where ZmailH will write its swap file. The swap file is a file which ZmailH uses to store its current status in while executing external programs such as archivers and unarchivers. Storing this file allows ZmailH to temporarily remove itself from memory to provide greater RAM availability for external programs. If available, EMS (Expanded Memory) which conforms to the LIM/EMS 3.2 standard or higher will automatically be used instead of the SWAPPATH. Mail Compression Options ARCCOMMAND The ArcCommand is used to archive the mail. If ZmailH never archives the outbound mail then this line does not need to be specified. The archiving function must be specified on the command line (See Command Line Options). The structure of this command is: ARCCOMMAND : . A full drive and path to the archive program must be specified as well as the extension of the archiving program. The sysop must also specify the location for the archive and file names on the archiving programs command line. To do this the sysop places a %A where the archive name should be and a %F where the file name to extract should be. To use the "standard" ARCA command the control file statement would be: ARCCOMMAND C:\UTIL\ARCA.COM %A %F /D UNARCCOMMAND The UnArcCommand is the command that is used to unarchive inbound archived packets. If ZmailH never unarchives mail packets then you do not need to use this line. The unarchiving function must be specified on the command line (See Command Line Options). In order to allow the sysop to use any unpacking program the structure of this statement is somewhat complicated: UNARCCOMMAND : . This command has the same structure and limitations as the ArcCommand. For example to use the "standard" ARC program in The C:\UTIL directory then the line would read: UNARCCOMMAND C:\UTIL\ARC.COM -E %A. To use ZOO as the unpacker the line would look like: UNARCCOMMAND C:\UTIL\ZOO.EXE -E %A. If the sysop has a program called PickARCE.EXE that will determine what unpacker to use then the command line might look like: UNARCCOMMAND C:\UTIL\PICKARCE.EXE %A. If the sysop had a batch file to call the proper unpacking program then the command line would look like: UNARCCOMMAND C:\COMMAND.COM /C UNPACK.BAT %A WARNING: Do not use a batch file unless you are certain that you will never run short of disk space, and you are certain that the batch file works. ZmailH can not determine Errorlevels generated by programs run inside batch files. ZmailH does not have internal facilities to determine what type of packer was used. It is the responsibility of the sysop to ensure that the proper unpacker is being called. Note: As of this writing ARC() 5.2 is the FidoNet standard for archived mail. System Options OMMM The OMMM command tells ZmailH that it is operating in an OMMM environment. If you are running SEAdog, Front Door, or any other mailer that does not use Ommm than you MUST REMOVE this line. The format of this statement is: OMMM. FDFIX The FDFIX command tells ZMailH that your system uses a FrontDoor message editor. This command is MANDATORY on all systems which use the FrontDoor editor in order to work around a bug in the way FrontDoor's editor treats message replies. PASSWORDFILE The PasswordFile statement is an optional statement that is used to point to a password file to be used with packet security (see command line options). Passwords may be up to 8 characters in length and are not case sensitive. The structure of the statement is: PASSWORDFILE [:]\\[.] The internal structure of the password file is:
An example of the file is: 1:999/123 FRED 2:123/456 mark 1:102/214.5 JoesPwd NOSEENBY The NoSeenBy statement is an optional statement that inhibits the importation of the seen-by lines. Seen-bys are still processed and included on messages that are passed through the system. This statement has the structure: NOSEENBY NOPATH The NoPath statement is an optional statement that inhibits the importation of the path lines. Paths are still processed and included on messages that are passed through the system. This statement has the structure: NOPATH LOGLEVEL When executing ZmailH writes a log in the current directory. The loglevel option allows the sysop to set the level of log reporting. Each level will include the information from lower log levels as well as the current level. The valid levels are from 0 to 6 with the default being 5. The log level settings correspond to the following: Level Log Entries 0 Start and Stop times 1 Dos Errors 2 Configuration Errors 3 Insufficient Disk Space 4 Internally Compensated Errors 5 Information 6 Detailed processing information An example of this command is: LOGLEVEL 3. This log level would produce a log that contained only references to Dos Errors, Configuration Errors, or Insufficient Disk Space errors. RETAIN In order to maintain the echo mail "signatures" ZmailH allows the sysop to specify how long to keep each signature. Retain is an optional command. If it is not used then the default retention period is 30 days. When an echo mail message is received and processed its signature is stored in a file along with the date. If the signature is not seen again for the duration of the retention period then the signature is removed from the file during the clean operation (See Clean Command Line Option). The retain command has two formats: RETAIN and RETAIN . The first example changes the default retention from 30 to . For example the statement RETAIN 15 would change the default retention period from 30 to 15 days. The second example is used to change the retention period for a single conference. For example the statement RETAIN SYSOP 25 would change the retention period of signatures in the "Sysop" echo from the default to 25 days. Each retain command must be on a separate line. Locking Options RALOCK, QUICKLOCK, SBBSLOCK The locking statements are provided for those systems which may be running ZmailH in a multi-line environment using QuickBBS 2.75 (Gamma-2) or higher, Remote Access 1.00 or higher, or SuperBBS 1.12 (Beta-12) or higher. Use of a locking statement will cause ZmailH to attempt to obtain a "lock" on the message base before importing a message into it. This locking prevents message base corruption due to conflicts in a multi-line environment. When attempting to obtain a lock, ZmailH will check to ensure that no other application (such as the BBS itself) presently has a lock established on the message base. If a lock cannot be obtained, ZmailH will re-try for five seconds. If the lock cannot be obtained after that time, ZmailH will save its current status (for continuation on the next run) and abort to prevent corruption of the message base. The locking statements are optional. Systems not running in a multi-line environment should not utilize a locking statement in the Zmail.ctl file. Systems which DO have locking statements must have share.exe loaded or else locking will fail and ZmailH will abort. LIST OF CONFERENCES (AREAS.BBS) In addition to the above files an AREAS.BBS file is also required. The sysop must create the AREAS.BBS file based on the names of the conferences that the system is carrying. The AREAS.BBS file must be in the current directory when ZMailH is run unless specified on the command line (See Command Line Options). The first line of the AREAS.BBS file is a considered a comment line and is not used. The structure of the remaining lines is: [:]/ [[[:]/]] The is a the number of the board specified in the configuration program. If the echo conference is to be passed through to another system and you do not wish to keep a copy on your system then the structure is: P [:]/ [[[:]/]]. Unlike other echo mail processors ZmailH does not create *.MSG format messages for pass through areas. Each area that you receive and/or forward must be listed in the AREAS.BBS file. There may be more than one line for each area. However each line must be a valid AREAS.BBS line. The zone numbers are optional as long as the systems that you are passing the echo to are in the same zone as your primary address. Once a zone has been specified it does not need to be specified again. For example: 1 SYSOP 1:99/864 1:99/369 2:333/44 2:543/21 is the same as 1 SYSOP 1:99/864 99/369 2:333/44 543/21 Like the zone numbers net numbers only need to be listed once. This means that the above line could be written as: 1 SYSOP 1:99/864 369 2:333/44 543/21. The extended addresses, as explained in the node statement, are also valid. For example: 1 SYSOP 1:99/864.864864/2 369 2:333/444 543/21 Would cause the SYSOP echo to be forwarded to 864864/2, which is understood to be a point under 99/864. ZmailH also provides a method to override the command line options that affect echo mail packeting. If an asterisk '*' is placed before an address in the areas.bbs file then all messages forwarded to that address in the current conference will be written to the net mail area as *.MSG files. This is used primarily to interface with UUNET and other 'external' networks. For example: UUCP_AREA 99/864 *32/100 would cause all messages to 32/100 to be tossed as *.MSG files in the net mail directory while messages to 99/864 will be processed according to the command line options. ZmailH will, by default, create "normal" packets, these packets are neither crash nor hold. When looking for file attaches ZmailH will look for attaches that have the same flavor as the packets that were created. If your mail bundling program changes the flavor of the attaches then ZmailH will not be able to add to the archive. For this reason flavor characters may proceed the address and follow the asterisk if one exists. The valid flavor characters are: "C" for Crash, "H" for Hold, and "N" for normal. WARNING: If you find that your system is creating many small packets for a system verify that the flavor is not being changed and that you have the correct flavor letters in the AREAS.BBS file. The complete address entry for the AREAS.BBS file is: [*][][:][/][.[/]] COMMAND LINE OPTIONS ZmailH is typically run from a batch file. The command line options listed below control how ZmailH will interact with the system on any given run. Any command line option can be listed in the control file. Command line options override control file statements. Command line options can be divided into five basic categories: general, file, packet, echo mail, and net mail. General Commands C (Clean) Instructs ZmailH to clean the message signature files. This command also causes ZmailH to delete any signature files for areas that are no longer carried on the system. it is recommended that signature file cleaning be performed once per day. S (Scan) Instructs ZmailH to scan the bad message area. ZmailH will then import or forward any messages that were listed as bad messages but are now valid. Such a condition may occur when a hub forgets to turn on an echo for a node. T[[.]] (Traffic) Instructs ZmailH to generate an echo mail traffic report. The report will contain the average volume of echo mail traffic for all of the echo conferences that are carried on or pass through the system as well as the total number of signatures that are in the file. The report is useful for determining what echo areas are dead, if a conference has not been turned on by your echo mail hub, and how many messages to retain in each of the areas. The report will be appended to the file if it exists. If does not exist it will be created. If is not specified the report will be written to the screen. QB (Quiet Bell) Instructs ZmailH to Quiet the Bell. This inhibits any beeping that would have otherwise occurred. QS (Quiet Screen) Instructs ZmailH to Quiet screen writes. The is the equivalent of the log level. The default is 6. File Commands FA[.] Instructs ZmailH to use [.] instead of the standard AREAS.BBS file. FC[.] Instructs ZmailH to use [.] instead of the standard Zmail.ctl file. FL[.] Instructs ZmailH to generate a list of all of the echo areas that had messages tossed into them. The list will be appended to [.] if it exists. If [.] does not exist it will be created. If [.] is not specified the ZmailH will display the list on the screen. Packet Commands PU (Packet Unarc) Instructs ZmailH to unarchive any archived mail it finds in the directory specified by the FilesPath control file statement. If this option is not specified any archived mail will not be processed. PI (Packet Import) Instructs ZmailH to process any unarchived mail packets it finds in the directories specified by the FilesPath and UnArchivePath control file statements. If this command is not specified then any mail packets that exist in the FilesPath and UnArchivePath directories will not be processed. PF (Packet Forward) Instructs ZmailH not to unpack any unarchived mail packets that are destined for another system. With the PF option those packets are simply forwarded. This option only works with packets that were created by another ZmailH system and it supersedes the PS option listed below. PS (Packet Security) Instructs ZmailH not to unpack any unarchived mail packets that are not destined for the BBS. ZmailH will rename these packets to BADPKT.*. In addition a password may be added to the packet. Packet passwords are stored in the file specified by the PasswordFile control file statement. At this time ZmailH will only check for passwords on packets from other ZmailH systems. PA (Packet Archive) Instructs ZmailH to archive ALL outbound packets created during this run. WARNING: On Ommm systems, if net mail is packeted and archived then no routing may occur. PC (Packet Crash) Instructs ZmailH to mark all generated packets as crash mail. PH (Packet Hold) Instructs ZmailH to mark all generated packets as hold. Echo Mail Commands EI (Echo Import) Instructs ZmailH to import all inbound echo mail messages. If this option is not specified then all echo mail messages will be tossed, as *.MSG files, into the directory pointed to by the MailPath control file statement. Imported echo areas must appear in the AREAS.BBS file (or the file specified by the FA[.] option above.). If the echo name is not located in the file then the message will be tossed, as a *.MSG file, into the directory pointed to by the BadMsgs control file statement. If the BadMsgs directory is not defined then the message is deleted. ES (Echo Security) Instructs ZmailH to verify that the system that forwarded the echo mail message to the BBS is listed in the AREAS.BBS file (or the file specified by the FA[.] option above). If the message fails the security check then it is tossed, as an *.MSG file, into the directory pointed to by the BadMsgs control file statement. If the BadMsgs directory is not defined then the message is deleted. This option has no effect if the EI option is not activated. EF (Echo Forward) Instructs ZmailH to forward any echo mail messages that were not generated on the BBS. This only occurs when one system is using the current system to forward mail to a third system. For this option to work the area must be listed in the AREAS.BBS or FA[.] option file, otherwise the message will be tossed as a bad message by the EI option. If this option is not enabled then the messages are tossed, as *.MSG files, to the directory specified by the BadMsgs control file statement. If the BadMsgs directory is not defined then the messages are deleted. This option has no effect if the EI option is not activated. EE (Echo Export) Instructs ZmailH to scan the BBS echo messages for any new outbound echo mail. The messages are extracted and forwarded to the other nodes receiving the echo as specified in the AREAS.BBS file (or the file specified by the FA[.] command line option above). NOTE: Due to ZmailH's one pass algorithm this command should only be run after echo mail is entered on the system. EP (Echo Mail Packet) Instructs ZmailH to create packet files for all outbound echo mail. If this option is NOT used then *.MSG files are created in the directory specified by the MailPath control file statement. Net Mail Commands NI (Net mail Import) Instructs ZmailH to import all inbound net mail messages. If this option is not specified then all net mail messages will be tossed, as *.MSG files, into the directory pointed to by the MailPath control file statement. NS (Net mail Security) Instructs ZmailH not to scan the directory pointed to by the MailPath Control file statement. This prevents other systems from dropping unauthorized or forged echo mail messages onto your system so that it will forward them into the network. NF (Net mail Forward) Instructs ZmailH to forward any net mail messages that were not generated on the BBS. Regardless of the flavor that the message had when it arrived on the system the flavor or the forwarded message will be normal to allow for message routing. If files are attached to a message that is forwarded through the system the file is placed on hold and the message is sent along with an appended line informing the recipient that the file is on hold. This command must be used on host and hub systems that may forward mail for other systems. If this option is not enabled then the messages are tossed, as *.MSG files, to the directory specified by the BadMsgs control file statement. If the BadMsgs directory is not defined then the messages are deleted. NE (Net mail Export) Instructs ZmailH to scan the BBS net mail messages for any new outbound net mail. The messages are extracted and sent to the addressed node. NP (Net mail Packet) Instructs ZmailH to create packet files for all outbound net mail provided the messages are not marked crash or hold and do not have files attached. If this option is NOT used then *.MSG files are created in the directory specified by the MailPath control file statement. Note: On non Ommm systems net mail is not usually packeted. Also, packeted net mail can not be routed. COMMAND LINE EXAMPLES Because ZmailH is so configurable and because it handles three distinct jobs; mail importing, net mail exporting, and echomail exporting, it is beyond the scope of this document to give examples of all possible configuration options. However, included here are some of the more common command line options. Import Command Line ZMailH PI PA PU EI EP EF NI NF This command line is probably the most common and should work for 80% of the systems. It causes ZmailH to unarchive, and import any inbound packets, import to the database any echo or net mail messages, create packets for any outgoing echo mail messages and then archive those packets. It should be noted that because the packets are archived they can not be routed in an Ommm environment. Any net mail that is not destined for the system is placed in the net mail directory and is not packeted. Export Command Line ZMailH EE EP PA NS This command is probably the most common export command line. *.MSG messages in the net mail area will not be scanned and packeted with the echo mail. This is useful if net mail was previously extracted, an external bundler has not been run, and the sysop does not want the net mail to be bundled with the echo mail. Removing the NS entry and replacing it with an NP entry would cause netmail to be packeted and archived. WARNING: If net mail messages are packeted and archived they can not be routed automatically. The routing program will not be able to reroute them. This is of particular importance when net mail and echo mail traffic is generated at the same time. It is usually better to extract echo mail and bundle it prior to extracting the net mail. CUSTOMER SUPPORT Support Echo The ZMAIL support echo is currently available on many network's echomail "backbone". Networks which are known to carry the ZMAIL echomail conference include FidoNet, MetroNet, NETWork, and AlterNet. This echo is intended as the direct line to PROZ Software for questions, answers, requests and comments regarding ZmailH. Obtaining New Keys Any registered ZmailH user may receive a new key should the old key be destroyed (due to a disk error, for example) or should the user's address change. To receive a new key, contact the dealer where you originally purchased your key and inform him/her of your need for a new key and, if applicable, your new address. Please include information to assist the dealer in finding your original purchase record such as your old address or, if necessary, a copy of the original canceled check. Netmail Support Netmail support for questions regarding ZmailH can be obtained from: Jason Steck FidoNet 1:104/424 MetroNet 200:5000/400 EggNet 99:910/952 Network 8:7703/10 COMPRESS UTILITY The Compress utility (zcmprs?.exe) is used to physically shrink the size of the signature file. The file cleaning process will free up space within the file to be used again by the system however it does not physically shrink the file size. Compress should not be run during daily maintenance but after an echo has been removed from the system. The reason Compress should not be run every day is that if all of the internal space is removed from the signature file then ZmailH will spend more time expanding the file, thus causing the system to run slower. Compress must be run in the directory in which the ZM_Dups.Sig file exists. It has one optional command line parameter: /B. The /B will instruct Compress that you want to delete the backups after compression. Compress requires that the free space available on the disk be at least as much as the size of the signature file. Compress will create a new signature file from the old one and, when finished, rename the old signature file to ZM_Dups.BAK unless the /B option is specified Compress will return one of four errorlevels when it exits. Errorlevel Error 0 No Error -- processed normally 1 No signature file found 2 Unable to create temporary file 3 Unable to close new file -- Disk Full? RECOMMENDED UTILITIES The following utilities are suggested as recommended additions to a ZmailH implementation: REC (Remote Area Control) REC is an automatic areas.bbs maintenance and update utility like Areafix. REC supports the special areas.bbs flavor codes included in ZmailH areas.bbs files. Author: Dan Fitch (1:104/438@FidoNet) Latest Release: 1.20 PolyXArc PolyXArc is a multiple-format archive extractor program. This utility could be used as the UNARCCOMMAND in Zmail.ctl to easily extract many different formats of incoming mail archives. Author: Jeffrey Nonken (1:273/715@FidoNet) Latest Release: 2.10a TwoPk TwoPk allows multiple-format archiving on outbound packets. This utility could be used as the ARCCOMMAND in Zmail.ctl to easily allow multiple archiver use on a system-by-system basis for outbound mail files. WARNING: DO NOT USE TWOUPK UTILITY FOR EXTRACTION WITH ZmailH 1.2! Author: Charlie Teufert (1:269/203@FidoNet) Latest Release: 1.14 ZMailCfg ZMailCfg is a program designed to assist the ZmailH sysop with setup and configuration of Zmail.ctl file options. Author: Joe Lindstrom (1:134/55@FidoNet) Latest Release: 1.20