Beijing Paradise BBS Backup

home *** CD-ROM | disk | FTP | other *** search

/ Beijing Paradise BBS Backup / PARADISE.ISO / software / BBSDOORW / OMX100.ZIP / OMX.DOC < prev next >

Wrap

Text File | 1994-10-10 | 149.0 KB | 3,467 lines

██████▒░ ██▒░ ██▒░ ██▒░ ██▒░ ██▒░ ██▒░ ███▒░███▒░ ██▒░██▒░ ██▒░ ██▒░ ████████▒░ ████▒░ ██▒░ ██▒░ ██▒██▒██▒░ ██▒░ ██▒░ ██▒░ ██▒░ ██▒░ ████▒░ ██▒░ ██▒░ ██▒░ ██▒░ ██▒░██▒░ ██████▒░ ██▒░ ██▒░ ██▒░ ██▒░ Offline Mail Executive for DOS and OS/2 Version 1.00 - October 10, 1994 Copyright 1994 by SysTech Computer Services All rights reserved. Written by Martin J. Pollard. Support addresses: FidoNet NetMail - 1:120/187@fidonet FidoNet EchoMail - BLUEWAVE, OFFLINE, SHAREWRE CompuServe - 74003,1353 Bulletin Board - (810) 398-3406 (effective November 1, 1994) ╒══════════════════════════════════════════════════════════════╕ │ ▒▒▒▒▒▒▒▒▒▒ DISCLAIMER AND COPYRIGHT INFORMATION ▒▒▒▒▒▒▒▒▒▒ │ ╘══════════════════════════════════════════════════════════════╛ SysTech Computer Services (SysTech) provides the Offline Mail Executive (OMX) software package to you as-is, without any warranty or guarantees of any kind. If OMX doesn't work, tough. If you lose millions because OMX messes up, it's you that's out millions, not us. If you don't like this disclaimer, tough. SysTech reserves the right to do the absolute minimum provided by law, up to and including nothing. (This is basically the same disclaimer that comes with all software packages, but ours is in plain English and theirs are in legalese. We didn't really want to include any disclaimer at all, but our lawyers insisted.) OMX and its documentation are copyrighted materials of SysTech and Martin Pollard. SysTech reserves all rights to these materials, and is protected under United States and international copyright laws. No part of these materials may be reproduced or modified in any way without the prior express written permission of SysTech. SysTech grants an unlimited license to make and distribute UNREGISTERED copies of OMX which have been released to the public by SysTech. Absolutely no modifications to the files contained in the software package, including this documen- tation file, may be made before distribution. No fee beyond the actual cost of providing these copies may be charged by anyone other than SysTech without the prior written consent of SysTech. Use of OMX constitutes acceptance of the stated terms and conditions. SysTech reserves all rights which are not ex- pressly granted. Offline Mail Executive Version 1.00 - Page ii ╒══════════════════════════════════════════════════════════════╕ │ ▒▒▒▒▒▒▒▒▒ REGISTRATION AND SHAREWARE INFORMATION ▒▒▒▒▒▒▒▒▒ │ ╘══════════════════════════════════════════════════════════════╛ Offline Mail Executive (OMX) is fully copyrighted, and is not, nor will it ever be, in the Public Domain. OMX is NOT Free- ware; it is distributed under the Shareware concept. Users are allowed to try this program for 30 days before paying for and registering the mail system with SysTech Computer Services (SysTech). If the software does not meet your needs, and you do not plan on registering with SysTech after your 30 day trial period, you are to cease usage of the program. Continued use beyond the authorized evaluation period requires payment of the registration fee in full. Registered users of OMX are granted an unlimited license to use the product, provided the following: Registration fees are NOT refundable. Registration codes are not transferable to other parties. Unofficial software patches must not be applied, and all copyright notices in the documentation and supporting files are not to be altered. Backup copies may be kept of all registered versions of this software for archive purposes only. Use of a registered copy is limited to one machine at a time. Use of multiple registered copies on multiple ma- chines requires additional payment to SysTech. To register, simply fill out the enclosed registration form (the REGISTER.DOC file) and mail to the address shown. You will receive a letter with your serial number and registration code, usually within 30 business days. READ THE REGISTRATION FORM CAREFULLY AND COMPLETELY IN ORDER TO AVOID PROBLEMS! Offline Mail Executive Version 1.00 - Page iii ╒══════════════════════════════════════════════════════════════╕ │ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ ACKNOWLEDGEMENTS ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ │ ╘══════════════════════════════════════════════════════════════╛ OMX was a massive undertaking, one of the largest projects I had ever attempted. It would never have been realized without the assistance of the OMX Beta Team: Francois Blais, Earl Faubion, Frank Koza, Doug Langley, Nick Marinelli, Steve Proctor, Scott Raymond, Roland Roberts, Clint Satterwhite, and Steve Stacher. Thanks, guys; your assistance was valuable beyond measure! In addition, I'd like to give a special thanks to George Hatchew for creating The Blue Wave Offline Mail System. Blue Wave has helped bring "painless" offline mail capabilities to the masses, and its popularity -- not to mention its non-proprietary nature and the generous assistance of its creator -- is what inspired me to base OMX on Blue Wave. Way to go, George! ╒══════════════════════════════════════════════════════════════╕ │ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ TRADEMARKS AND CREDITS ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ │ ╘══════════════════════════════════════════════════════════════╛ OMX makes use of the following toolkits: MsgAPI; Copyright 1991-1994 by SCI Communications; All rights reserved. JAM(mbp) API; Copyright 1993 Joaquim Homrighausen, Andrew Milner, Mats Birch, and Mats Wallin; All rights reserved. The following are products or trademarks of the companies or individuals indicated: BinkleyTerm - Bit Bucket Software Blue Wave - Cutting Edge Computing Fido, FidoNet - Tom Jennings and Fido Software FrontDoor - Joaquim Homrighausen Maximus, MsgAPI, Squish, SquishMail - Scott Dudley and SCI Communications MS-DOS, Windows, Windows NT - Microsoft Corp. Novell DOS, DR-DOS - Novell Inc. OS/2, PC-DOS - International Business Machines Corp. PKZIP - PKWare Inc. Wave Rider - Doug & Sue Crocker Offline Mail Executive Version 1.00 - Page iv ╒══════════════════════════════════════════════════════════════╕ │ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ TABLE OF CONTENTS ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ │ ╘══════════════════════════════════════════════════════════════╛ Introduction ................................................ 1 What You Get When You Register OMX ........................ 1 Definitions For Commonly-Used Terms ....................... 2 What Do I Need to Run OMX? .................................. 4 Installing and Configuring Your System ...................... 5 The Front-End Mailer and EchoMail Processor ............... 5 The Offline Mail Reader ................................... 6 Installing OMX ............................................ 7 Additional Notes .......................................... 8 OMX - Packet Processing Utility ............................. 10 Creating a Mail Packet .................................... 10 Processing a Reply Packet ................................. 12 Using OMXMAIL on the Command Line ......................... 13 OMXSETUP - OMX Configuration Utility ........................ 16 System Information ........................................ 17 Paths & Filenames ......................................... 18 Options & Settings ........................................ 19 Message Area Settings ..................................... 21 Archive Commands .......................................... 22 Zone Gate Addresses ....................................... 24 Registration Codes ........................................ 24 User Configuration ........................................ 25 Message Area Manager ...................................... 27 Keyword & Filter Managers ................................. 33 Import Information ........................................ 36 Export Information ........................................ 37 OMXMAINT - OMX Maintenance Utility .......................... 38 Appendix A - NetMail Processing in OMX ...................... 42 Appendix B - Technical Info on Last-Read Pointers ........... 43 Appendix C - Formats of OMX Import/Export Files ............. 44 OMX System Information (OMXSETUP.CFG) ..................... 44 OMX Message Areas (OMXAREAS.CFG) .......................... 50 Additional Commentary ..................................... 52 Appendix D - Suggested Software ............................. 53 Offline Mail Executive Version 1.00 - Page v ╒══════════════════════════════════════════════════════════════╕ │ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ INTRODUCTION ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ │ ╘══════════════════════════════════════════════════════════════╛ Offline Mail Executive (OMX) is an offline mail processing system designed for the individual. It allows an individual user to read and write FidoNet-style mail using the convenient features of an offline mail reader, but without the hassle of setting up an entire bulletin board system (BBS) and offline mail door. OMX provides the following features: * Creates and processes mail and reply packets using the Blue Wave offline mail format. * Supports FidoNet-compatible NetMail, EchoMail, and GroupMail. * Supports the Fido (*.MSG), Squish, and JAM message base formats for local ("raw") message processing. * Supports flexible message packing via keywords and filters. * Provides for complete message base maintenance (i.e. packing, renumbering, etc.) without the need for external utilities. * Supports one or two users (NO extra registration required!). * Available in both DOS and OS/2 versions. * Much, much more! This documentation assumes that you are somewhat familiar with the concept of networks, mail processing, nodes, points, and so forth. If you're unfamiliar with these concepts, it is suggest- ed that you contact a BBS in your area that is participating in FidoNet (or a similar network), and obtain a few pointers. Most SysOps and users will be more than happy to help you out. WHAT YOU GET WHEN YOU REGISTER OMX The unregistered version of OMX includes most, but not all, of the functionality of the registered version (the remaining 95% should be more than enough to help you determine whether or not OMX meets your needs). When you register the package, the following features become available: * NetMail address matching (both zone matching and exact address matching). * NetMail zone gating. * Automatic creation of the semaphore and ECHOTOSS.LOG files. * Unique origin lines for each message area. Offline Mail Executive Version 1.00 - Page 1 * Individual tear/origin line combinations for each message area. * Up to 100 keywords and filters each (the unregistered version is limited to 10 each). In addition, you will be eligible for special access on the SysTech support BBS to areas that are restricted to registered users. Simply call the BBS and leave a message to the SysOp indicating that you are a registered OMX user (include your serial number and registration code), and you will receive access to the areas reserved for registered users. DEFINITIONS FOR COMMONLY-USED TERMS Although it's assumed that you have some experience with Fido- Net-style mail, some of these terms may still be new to some of you. Therefore, here is a list of the commonly used terms scattered throughout this document: NetMail This is a type of mail generally intended for personal, one-on-one communication. NetMail is addressed directly to the recipient, and is usually marked as "private". This way, the only person that can read the message is the person to whom the message is addressed. EchoMail A method of mail processing used for public, or "conference" mail. Unlike NetMail, messages sent via EchoMail are usually NOT marked "private", and can therefore be read by anyone. EchoMail conferences are separated by topic, and are by far the most popular method of mail processing, since it allows people from all across the globe to interact with each other about their favorite topics. GroupMail This method of mail processing is, in concept, identical to EchoMail; the difference lies in the way that messages are processed. GroupMail is a rather esoteric method of mail processing, so don't feel left out if you've never heard of it. Generally, the only people who will be interested in GroupMail are those who are already receiving mail via the GroupMail method, as 99% of mail processing is done via EchoMail. Fido/*.MSG The very first method used to store messages on disk. (The name comes from Tom Jennings' "Fido", the BBS package that first used the format.) Each message is stored as an individual file, using the message number as the filename and ".MSG" as the extension (i.e. "1.MSG"), and each message area has its own individual direc- tory. The main advantage to the Fido format is Offline Mail Executive Version 1.00 - Page 2 that since it was the first, it has become the lowest common denominator in FidoNet, with liter- ally hundreds of support utilities available that support this format. (All FidoNet-compatible front-end mailers use the Fido format for storing NetMail messages, as well.) The main drawback to the Fido format is that each of these little files tends to cumulatively take up a HUGE amount of disk space, especially on FAT drives with large cluster sizes. Also, process- ing slows down tremendously as the number of messages increase, since each file comprises a single message that must be examined one by one. Squish This method was introduced in the Maximus BBS package. It stores messages in individual sets of database files for each message area. The biggest advantage that the Squish format has over the Fido format is that Squish files take up MUCH less disk space (since all messages for a base are stored in a single database file), while still retaining Fido's concept of segregated areas (making maintenance easier; you only have to delete a handful of files to remove a Squish area, with the other areas left intact). The only real disadvantage is that Squish is very much designed around FidoNet; currently, it is not flexible enough to encompass the needs of other networks. JAM This method was introduced in the Remote Access BBS package, and is very similar in concept to the Squish format. (The name is derived from the first initials of its creators -- Joaquim Hom- righausen, Andrew Milner, Mats Birch, and Mats Wallin.) The biggest difference between JAM and Squish is that the JAM format is not tied to FidoNet, which allows it to be used with mail from non-FidoNet networks (such as the Internet). Whew! Anyway, those are the terms you need to be familiar with right off the bat, since they form the core of what is OMX. Other terms will be defined and discussed as we go along. Offline Mail Executive Version 1.00 - Page 3 ╒══════════════════════════════════════════════════════════════╕ │ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ WHAT DO I NEED TO RUN OMX? ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ │ ╘══════════════════════════════════════════════════════════════╛ For the DOS version of OMX, you will need an IBM Personal Com- puter or compatible system based on (at minimum) the Intel 8088 CPU, at least 640K of RAM, and plenty of hard disk space. MS- DOS version 3.3 or later (or an operating system compatible with MS-DOS, such as PC-DOS, DR-DOS, Novell DOS, or the OS/2 or Windows NT DOS sessions) is required. For the OS/2 version of OMX, you will need an IBM Personal Computer or compatible system based on (at minimum) the Intel 80386 CPU, at least 8MB of RAM, and plenty of hard disk space. OS/2 version 2.0 or later is required. In addition, the following software is required to complete your setup: * An offline mail reader that supports the Blue Wave offline mail specification. An example of such a reader is its name- sake, The Blue Wave Offline Mail Reader. * A front-end mailer that conforms to the FidoNet Technical Standards Committee (FTSC) specifications for mail sessions and file transfers. An example of such a front-end mailer is FrontDoor. * An EchoMail processor that conforms to FTSC specifications for EchoMail. An example of such a processor is SquishMail. You must make sure that the processor supports the Fido (*.MSG), Squish, or JAM message base formats (most popular processors support some or all of these formats). * (Optional) A GroupMail processor that conforms to the System Enhancement Associates (SEA) specifications for GroupMail. An example of such a processor is SEA's GROUP. Offline Mail Executive Version 1.00 - Page 4 ╒══════════════════════════════════════════════════════════════╕ │ ▒▒▒▒▒▒▒▒▒ INSTALLING AND CONFIGURING YOUR SYSTEM ▒▒▒▒▒▒▒▒▒ │ ╘══════════════════════════════════════════════════════════════╛ I know what you're thinking, but no... the first step isn't to install OMX. Before installing OMX, you need to set up your front-end mailer, your EchoMail processor (including deciding which message areas you're going to be receiving), and your offline mail reader, as the decisions you make when configuring OMX are based on how you set them up. THE FRONT-END MAILER AND ECHOMAIL PROCESSOR (If you already have a mailer and EchoMail processor set up and configured -- for instance, if you are moving to OMX from a BBS setup or other program, such as a point package -- you can skip this section.) OMX isn't picky about which mailer or EchoMail processor you use; it'll work with just about any of the ones that are on the market. However, since there are so many to choose from, there is no way we can provide an installation guide for them. But, we *can* give you some guidelines to follow. * The easiest way to set up your system is in a single directory, with subdirectories to store such things as Net- Mail, EchoMail, and so on. This will make your batch files much easier to write and maintain, since all of the "action" will, for the most part, occur in a single directory. The following tree gives an example of a typical setup: C:\MAILER --+ +-- NODELIST | +-- INBOUND | +-- OUTBOUND | +-- NETMAIL | +-- FIDO --+ | +-- C_ECHO | | | +-- OS2 | | | +-- TREK | +-- SQUISH In this example, all software (mailer, EchoMail processor, and OMX) is set up in the C:\MAILER directory. The NODELIST and INBOUND directories store the mailer's nodelist files and all incoming files, respectively (your mailer documentation will have more information on these topics). The OUTBOUND directory will store all files that the mailer will be send- Offline Mail Executive Version 1.00 - Page 5 ing to other systems (this includes EchoMail bundles created by the EchoMail processor). The FIDO directory contains the message base directories for the C_ECHO, OS2, and TREK ech- oes, and the SQUISH directory will hold all message base files that are stored in the Squish format. * You should make a list of all EchoMail conferences you want to receive, and configure them ahead of time (i.e. before you install OMX). The best time to do this is when you're in- stalling your EchoMail processor, since the type of processor you choose will determine which message base formats you will use. The documentation for your EchoMail processor will give you full instructions on its installation and configuration, plus plenty of tips on EchoMail conferences and the concept of EchoMail itself. THE OFFLINE MAIL READER (If you already have an offline mail reader set up and configured, you can skip this part.) The offline mail reader is where you're going to be spending most of your time, since the operation of your mailer, EchoMail processor, and OMX is largely automatic. Therefore, you'll want to use a reader that suits your needs and with which you feel the most comfortable using. (It also goes without saying that the reader must be able to process mail and reply packets in the Blue Wave format, since that's the format used by OMX.) For the DOS environment (which includes Microsoft Windows), there are several Blue Wave-compatible readers from which to choose. There is, of course, The Blue Wave Offline Mail Reader, the standard by which other Blue Wave-compatible readers and mail processors are measured ("If it doesn't work with Blue Wave, it's not Blue Wave-compatible!"). For Windows users there is Wave Rider, a reader which takes full advantage of the Wind- ows interface (pull-down menus, pop-up windows, buttons, icons, etc.). For the OS/2 environment, the only choice at present is The Blue Wave Offline Mail Reader for OS/2, as the OS/2 market has yet to catch up to the long-standing DOS market. (Authors of other OS/2 readers have, however, expressed interest in adding Blue Wave compatibility to their products, so stay tuned!) Again, since there are several different readers from which to choose, installation instructions are beyond the scope of this document. Refer to the reader's documentation for instructions on installation and configuration. Offline Mail Executive Version 1.00 - Page 6 INSTALLING OMX The OMX package includes an installation program, INSTALL.EXE, that takes most of the "drudge work" out of installing the program. Since you're reading this document, you've already gotten through the most annoying part, i.e. unpacking the OMX distribution archive. To perform the installation: 1. Make sure the current directory is the one that contains INSTALL.EXE and INSTALL.DAT, and type "INSTALL" at the DOS (or OS/2) system prompt. The installation program will load and present the main screen. INSTALL has a number of command line switches that can be used to alter its behavior. Refer to the "OMXSETUP - OMX Configuration Utility" section for more information, as the OMXSETUP utility uses the exact same switches. 2. The first option that needs to be modified is the "In- stallation Path". This is where the OMX programs and data files are to be placed. The installation program uses "C:\OMX\" as the default path; if this is correct, you can move on to step 3. To change the path, use the arrow keys to move the cursor bar to the "Installation Path" option and press ENTER. Type the full path to where the OMX programs and data files are to be placed. (Using our earlier example as a guide, you would enter "C:\MAILER\" here.) 3. Move the cursor bar to the "System Name" option and press ENTER. This is where you'll enter a clever little name for your system (such as "Joe's Mail Emporium"). Note that this name will be used in the future to determine your registration codes, so be sure it's a name you can live with (otherwise, if you change it you'll have to go through the hassle of getting a new registration code). 4. Move the cursor bar to the "SysOp Name" option and press ENTER. This is where you'll enter your name, indicating that you are the operator of the system (hence the term "SysOp"). Note that the precaution in step 3 concerning registration codes applies here as well. 5. Move the cursor bar to the "Network Address" option and press ENTER. This is where you'll enter the network ad- dress that was assigned to your system, either by the net coordinator (if you're a full-fledged node) or your boss- node (if you're a point). Again, note the precaution in step 3 concerning registration codes. 6. After all information in steps 2-5 has been entered and verified, move the cursor bar to "Begin Installation" and press ENTER to begin the installation process. If the installation process was successful, follow the steps that are outlined on the screen and proceed to the next step. Offline Mail Executive Version 1.00 - Page 7 If a problem has occurred, you must correct it and repeat the installation process (if it's a problem with any of the information you've entered, you can simply correct it and repeat this step, rather than run the whole installation process again). 7. When the installation program returns to the main screen, press ESC to end the program and return to the DOS (or OS/2) system prompt. OMX is now ready to be configured. ADDITIONAL NOTES * Whenever you use OMX, the current directory must be the one that contains the OMX data files. If OMX, your front-end mailer, and your EchoMail processor are all in the same directory, this is usually not a problem, but if you've spread these programs out throughout different directories, it can become a real hassle. To this end, an environment variable can be assigned which will indicate the directory in which the OMX data files reside. Simply place: SET OMX=C:\OMX\ in your AUTOEXEC.BAT (DOS) or CONFIG.SYS (OS/2) file. You will, of course, need to substitute "C:\OMX\" for the actual directory you are using to store the OMX data files. * OMX also makes use of the operating system's file sharing capabilities. This is especially useful in multitasking environments, where more than one program can conceivably access the same data files. If you are running the OS/2 ver- sion, this is taken care of for you automatically, as OS/2 includes file sharing as part of the operating system. If, however, you are using the DOS version, you will have to enable your operating system's file sharing capabilities if you wish to use this feature (as DOS does not automatically include such abilities). This is done by running SHARE.EXE, which installs this feature into DOS. If you wish SHARE to be installed automatically, simply place "SHARE" in your AUTOEXEC.BAT file. (If you are using the DOS version under an OS/2 or Windows NT DOS session, you don't need to do anything special since these operating systems provide SHARE- compatible file sharing functions in their DOS sessions.) * The OS/2 version of OMX includes, in addition to the program files, a Dynamic Link Library (DLL) which provides functions to access Fido, Squish, and JAM style message bases. This DLL is called OMXAPI32.DLL, and is installed in the same directory as your OMX program files during the installation process. Needless to say, OMX needs to be able to find this DLL in order to access message bases. (The advantage of using a DLL is that if the code needs to be updated, due to a bug or the addition of new features, the program files that use it don't need to be changed. Also, more than one program Offline Mail Executive Version 1.00 - Page 8 can use the same DLL, preventing the need for each program to include the same routines, which tends to take up lots of disk space.) There are several ways of handling this. The first, and the easiest, is to place the directory where OMXAPI32.DLL resides into the LIBPATH line in your CONFIG.SYS file: SET LIBPATH=<existing stuff>;C:\OMX Another way is to copy OMXAPI32.DLL into a directory that is already listed in the LIBPATH variable, such as C:\OS2\DLL. A third alternative is to create a separate DLL directory, such as C:\DLL, copy OMXAPI32.DLL into it, and add the direc- tory to the LIBPATH line (the advantage here is that this directory can be used to store DLLs from other applications you might install in the future). The drawback to these two methods occurs if and when OMXAPI32.DLL is ever updated. If this happens, you will have to remember to copy the updated DLL into the appropriate directory (whereas if it's in the same directory as the OMX programs, it's easier to remember). Offline Mail Executive Version 1.00 - Page 9 ╒══════════════════════════════════════════════════════════════╕ │ ▒▒▒▒▒▒▒▒▒▒ OMXMAIL - PACKET PROCESSING UTILITY ▒▒▒▒▒▒▒▒▒▒▒ │ ╘══════════════════════════════════════════════════════════════╛ OMXMAIL is responsible for gathering up inbound mail from the "raw" message bases and placing it in a mail packet, as well as unpacking a reply packet and placing outbound messages into the "raw" message bases for processing. Since it handles all of the mail you will be dealing with, OMXMAIL is, literally, the heart of the whole OMX package. (Note that if you have just installed OMX, most of the required options and settings are not yet in place. These options and settings will need to be made via the OMXSETUP utility, but it is recommended that you at least read this section first, in order to become familiar with some of the concepts that will be bandied about rather loosely in the OMXSETUP section.) CREATING A MAIL PACKET Creating a mail packet for use with your offline mail reader is one of the two main concepts with which you will need to become familiar. If you're normally used to calling your favorite BBS and downloading a mail packet, you're really dealing only with the end result, not the "nitty-gritty" behind the process. This lack of knowledge is about to be remedied! The process isn't all that difficult to understand, really. Rather than present a long-winded description of the process, let's outline it in step-by-step form: 1. The front-end mailer calls the system (or systems) which supplies your system with mail (these systems are known as "uplinks"). When the process is finished, the mailer's inbound directory will contain compressed files that con- tain "raw" mail packets. These compressed files are known as ARCmail packets, named after the ARC file compression utility (the first such utility used to compress mail packets; despite the fact that other, more efficient com- pression utilities are now in common use, the name ARCmail has stuck, and is synonymous with ANY compressed mail packet). 2. The EchoMail processor unpacks these ARCmail bundles and tosses the messages from the mail packets into the "raw" message bases. This process may take some time, depending on how much mail was received and what message base types are being used (Fido being the slowest). When the process is finished, the mail will be sitting in the "raw" message bases, ready for use. 3. OMXMAIL will scan through each "raw" message base, one by one, and extract all messages that were received since the last mail session (i.e. the "new" messages). These new messages are gathered up and placed into a compressed Offline Mail Executive Version 1.00 - Page 10 offline mail packet, which is subsequently placed in the directory your offline mail reader uses to store mail packets. When the process is finished, the mail packet is ready for you to read. Not a very difficult process, is it? Despite its simplicity, however, you'll want to create batch files to automate the whole thing. For the process of calling and obtaining mail packets, you'll want to set up events in your front-end mailer so that it will automatically call at a set time every day (check your mailer's documentation for details). Processing the received mail via the EchoMail processor can usually be done the moment mail is received -- again, check your mailer's documentation for details on how to accomplish this -- but using OMXMAIL to create the offline mail packet should really only be done once per day (because if you run OMXMAIL every time you receive mail, you'll likely end up with a directory full of tiny mail packets, rather than one large packet containing the day's messages). At this point, you're probably questioning the wisdom of using "raw" message bases; after all, you ask, wouldn't it be simpler (and faster) to create the offline mail packet directly from the compressed mail packets, thus saving the intermediate step of creating "raw" message bases? Well, the answer is... possibly. The advantages of using "raw" message bases as an intermediate step are flexibility and ease of enhancement. With external mail processors handling all the "grunt work", OMXMAIL can concentrate on the task of creating offline mail packets. Also, future enhancements (such as new compressed mail formats or support for other networks, such as the Internet) can be made quickly and easily if OMXMAIL doesn't have to worry about handling the "raw" mail itself. Anyway, enough of that. OMXMAIL also has features that allow you to set the criteria upon which messages are placed into offline mail packets; it doesn't just blindly grab every new message it finds. These features are keywords, filters, and messages-from-you. Keywords are what is known as "inclusion" devices; they dictate which messages can be included in a mail packet. For example, if you define the keyword "Smith", then only messages which contain that text will be included in the mail packet; all other messages will be excluded. The options available with keywords are discussed in the "Keyword Manager" section. Filters are the exact opposite of keywords. They are known as "exclusion" devices, and dictate which messages cannot be included in a mail packet. For example, if you define the filter "Jones", then messages which contain that text will NOT be included in the mail packet; all others will be included. The options available with filters are discussed in the "Filter Manager" section. Offline Mail Executive Version 1.00 - Page 11 Messages-from-you is a simple exclusion device. If enabled, then any messages that were written by you will not be included in the mail packet; all others will be included. This option is discussed in the "User Configuration" section. PROCESSING A REPLY PACKET Processing a reply packet that was created by your offline mail reader is the second concept with which you need to become familiar. Again, the "nitty-gritty" details are more complex than what you're used to, if all you've done before is call your favorite BBS and uploaded reply packets. Let's also outline this process in step-by-step form: 1. OMXMAIL unpacks the reply packet and places each message into the proper "raw" message base. Duplicate messages, and messages which do not correspond to any currently defined area, are ignored. When the process is finished, the reply messages will be sitting in the "raw" message bases, ready for processing. 2. The EchoMail processor is used to scan the "raw" message bases. If it detects messages that have not been pro- cessed, it extracts those messages from the "raw" message bases and bundles them into ARCmail packets. When the process is finished, one or more ARCmail packets will be sitting in the outbound mail directory (provided any out- bound messages were found), ready to be sent to your uplinks. 3. The front-end mailer will send these outbound ARCmail packets to your uplinks, where they will be distributed throughout the network or networks to which you belong. Unlike before, the only process which should be automated is the EchoMail bundling process (the front-end mailer can be set up, via its event system, to control when the ARCmail packets will be sent; usually, this can be done at the same time that it calls to obtain new ARCmail packets). The process of using OMXMAIL to unpack reply packets should be done manually, in order to allow you the opportunity to review any and all reply messages that will be sent. After all, if you "flamed" someone in the heat of the moment, you might regret having that message sent out across the network before you have a chance to change your mind! Processing a reply packet is relatively straightforward when compared to creating a mail packet. There are no keywords or filters to deal with; messages are simply unpacked and placed into the "raw" message bases. Offline Mail Executive Version 1.00 - Page 12 USING OMXMAIL ON THE COMMAND LINE The OMXMAIL command line format is as follows: OMXMAIL functions switches There are only two functions available: PACK, which creates a mail packet, and UNPACK, which processes a reply packet. One or both functions can be specified, in any order. The following (optional) command line switches are available: -D Disable Duplicate Message Checking This switch disables the process that checks for duplicate messages during an UNPACK operation. Useful if you need to force processing of a reply packet that was already pro- cessed. Note that this switch should only be used if you intend to force processing of ALL messages in a reply packet. If you only wish to process a handful of messages (if, say, those messages were previously rejected for one reason or another and you have rectified the problem), you should NOT use this switch. -E Keep Reply Packets After Processing Normally, an UNPACK operation will delete the reply packet after it has been successfully processed. This switch will force OMXMAIL to skip this step, and retain the reply packet. Note that if any message from a reply packet was rejected during an UNPACK operation, the reply packet is automati- cally retained. This allows you to review the messages in question, and optionally rectify the problem. -F Disable Filter Searching This switch will force OMXMAIL to skip the process of searching the filter database during a PACK operation. -G Enable Zone Gating of NetMail This switch enables NetMail zone gating during an UNPACK operation. Normally, any NetMail message that is addressed to a node outside of your zone will be stored in the Net- Mail directory with the exact destination address. Some networks, however, have established "zone gate" systems through which you can route out-of-zone NetMail (thus cutting down your costs, especially to overseas systems). This switch will force OMXMAIL to store NetMail messages in such a manner that they will be sent to the "zone gate" systems, if defined. (For more information, refer to the "Zone Gate Addresses" section.) Offline Mail Executive Version 1.00 - Page 13 -H Ignore Last-Read Pointers During a PACK operation, OMXMAIL uses what are called "last-read pointers" to determine which messages in the "raw" message bases have not yet been processed, and will properly update the pointers after all messages have been packed. This switch will force OMXMAIL to totally ignore the last-read pointers, the result being that ALL messages in the "raw" message bases will be packed (and the pointers will not be updated). -K Disable Keyword Searching This switch will force OMXMAIL to skip the process of searching the keyword database during a PACK operation. -L Disable Log File Output This switch will suppress the creation and maintenance of the activity log during all OMXMAIL operations. Refer to the "Paths & Filenames" section for information on how to permanently disable the log file, if desired. -M Keep NetMail Messages After Packing Normally, any NetMail messages that OMXMAIL bundles during a PACK operation are deleted from the NetMail directory afterwards. This switch will force OMXMAIL to suppress this function, the result being that NetMail messages will be left intact. Useful if you need to perform further processing on messages in the NetMail directory. -N Force Exact Address Matching for NetMail (This switch only applies to users who have defined more than one NetMail area.) Normally, OMXMAIL will bundle all NetMail messages into the first NetMail area it encounters during a PACK operation. This switch will force OMXMAIL to be more selective, in that the destination address of the NetMail message must match EXACTLY the address defined for a particular NetMail area before it can be packed. Useful for separating Net- Mail messages from different networks (for example, FidoNet messages in zone 1 and AlterNet messages in zone 7). -R Ignore "Received" Status on NetMail Messages Normally, OMXMAIL will not bundle a NetMail message that contains the "Received" status flag during a PACK opera- tion. This switch will force OMXMAIL to ignore this flag and bundle such messages anyway. Offline Mail Executive Version 1.00 - Page 14 -Ux Perform Processing for Specified User Number The OMX package supports up to two users, numbered 1 and 2. This switch selects which user information is to be used for processing mail and reply packets. (If not specified, the default is user number 1.) -Z Force Zone Number Matching for NetMail (This switch only applies to users who have defined more than one NetMail area.) This switch is identical to the -N switch, except that only the zone numbers of the NetMail destination address and the NetMail message areas are compared, rather than the com- plete address. Offline Mail Executive Version 1.00 - Page 15 ╒══════════════════════════════════════════════════════════════╕ │ ▒▒▒▒▒▒▒▒▒▒ OMXSETUP - OMX CONFIGURATION UTILITY ▒▒▒▒▒▒▒▒▒▒ │ ╘══════════════════════════════════════════════════════════════╛ The OMXSETUP utility is where all of the features available with OMX are set up and maintained. Message areas, keywords, filters, and all the various OMX options and settings are configured in OMXSETUP. To run OMXSETUP, move to the directory that contains the OMX data files and enter the following on the DOS or OS/2 command line: OMXSETUP switches The following optional switches can be used to alter the behavior of OMXSETUP: /BIOS Force Video Output Through BIOS Normally, OMXSETUP performs all video output directly to the video display. Some ancient systems, however, are not 100% "IBM compatible", the result being that this method of video output might not work. If you run OMXSETUP and it doesn't seem to be displaying anything, this switch will force it to use the video routines in the BIOS (a method that's much slower than direct video output, but is guar- anteed to work). Note that this switch only applies to the DOS version, as the OS/2 version performs all video output via OS/2 video functions. /MONO Map Colors to Monochrome Equivalents If your system is using a monochrome or LCD display, some of the colors used in OMXSETUP may not show up properly. This switch will force OMXSETUP to display everything in black and white instead of color. /SNOW Eliminate Snow on CGA Monitors Some of the ancient Color Graphics Adapter (CGA) monitors and adapters had a problem that caused interference ("snow") on the display every time information was scrolled. Nowadays, CGA setups are all but extinct, but if you are using one and it exhibits this problem, this switch will force OMXSETUP to enable functions that suppress this interference. Note that this switch only applies to the DOS version, as the OS/2 version performs all video output via OS/2 video functions. (Besides, CGA's 320x200 resolution makes it quite impractical for use with OS/2.) Offline Mail Executive Version 1.00 - Page 16 After a few moments, the OMXSETUP main menu will be displayed. (If the OMX package has not yet been registered, a short regis- tration screen will be displayed first.) The following options are available from the main menu: System Information User Configuration Paths & Filenames Message Area Manager Options & Settings Keyword Manager Message Area Settings Filter Manager Archive Commands Import Information Zone Gate Addresses Export Information Registration Codes Quit Using the arrow keys moves the cursor bar from one option to another. Pressing ENTER will select the option under the cursor bar. These keys function similarly throughout all areas in OMXSETUP, for ease of use. When you have finished making any and all desired changes and are ready to return to DOS or OS/2, select the "Quit" option (or press ESC). If changes have been made, you will first be asked to verify whether or not they are to be saved to disk. Select- ing "Y" will save the changes you've made; selecting "N" will wipe them out, leaving the original settings intact. The following pages will describe, in detail, each option avail- able in OMXSETUP. SYSTEM INFORMATION System Information configures the information used to identify your system. System Name This is where you'll enter a clever little name for your system (such as "Joe's Mail Emporium"). Note that this name is also used to determine your regis- tration codes, so be sure it's a name you can live with; otherwise, you'll have to go through the hassle of getting a new registration code if you change it down the line. SysOp Name This is where you'll enter your name, indicating that you are the operator of the system (hence the term "SysOp"). Note that the precaution noted above (concerning registration codes) applies here as well. Network Address This is where you'll enter the network address that was assigned to your system, either by the net coordi- nator (if you're a full-fledged node) or your bossnode Offline Mail Executive Version 1.00 - Page 17 (if you're a point). Again, note the above precaution concerning registration codes. PATHS & FILENAMES Paths & Filenames records the various directories and files used throughout OMX, for such things as temporary storage and placement of mail and reply packets. BW Mail Packets Specifies the directory in which OMX will store mail packets it creates. This should be the same directory specified in your offline mail reader for the location of mail packets. BW Reply Packets Specifies the directory that OMX will search for reply packets. This should be the same directory specified in your offline mail reader for storage of reply packets. OMX Work Files Specifies the directory that OMX will use for storage of temporary files. This directory is automatically created and removed by OMX. Note that you cannot specify the root directory of a drive; it must be a subdirectory. NetMail Messages Specifies the directory in which NetMail messages are stored. This should be the same directory specified in your front-end mailer for storage of NetMail mes- sages. Activity Log File Specifies the name of the file that OMX will use to log session information (including error messages). If this field is left blank, no log file will be created. Activity Log Type Specifies the format that OMX will use to write information to the activity log. Two types are avail- able: "FrontDoor", which uses the log style used by the FrontDoor front-end mailer; and "BinkleyTerm", which uses the log style used by the BinkleyTerm mailer and other programs. Offline Mail Executive Version 1.00 - Page 18 Semaphore File Specifies the name of the file that OMX will create if any reply messages have been exported. Batch files can test for the existence of this file, and process mail accordingly. If this field is left blank, no semaphore file will be created. (The file that is created will have a length of 0 bytes, thus it does not take up any disk space.) ECHOTOSS.LOG File Specifies the name of the file that OMX will create if any reply messages have been exported. This is an ASCII text file that lists all of the message areas that have had reply messages exported to them via OMX. If this field is left blank, the file will not be created. OPTIONS & SETTINGS Options & Settings defines the default behavior for OMX modules, as well as providing override settings for various OMX command line options. BIOS Video Output When this option is set to YES, it does the exact same thing as the "/BIOS" command line switch (as described above), except that it applies to ALL of the programs in the OMX package. CGA Snow Elimination When this option is set to YES, it does the exact same thing as the "/SNOW" command line switch (as described above), except that it applies to ALL of the programs in the OMX package. Slow Message Purge When deleting a group of files from a directory, OMX will use certain low-level DOS routines that can delete files blazingly fast. (For the technical- minded, it directly modifies the directories and tables on a FAT drive.) Some DOS-compatible operating systems -- including OS/2 and Windows NT -- support other file systems (in addition to FAT), however, and since it would be dangerous to allow direct manipula- tion of the drive under their DOS sessions, they disable or modify these low-level routines. If you are using such a system, setting this option to YES will force OMX to use the slower, but safer, method of deleting each file one by one. Offline Mail Executive Version 1.00 - Page 19 If you are using the DOS version of OMX under OS/2, OMX will automatically set this option for you, since OS/2 does not provide the "fast file delete" function under a DOS session. (Actually, it *does*, but it's no faster than a per-file delete; also, the function is buggy under OS/2 2.0, and can result in some files not being deleted [it works properly under OS/2 2.1].) (Note that for the OS/2 version, this option -- while available -- is not applicable, as all file I/O is performed using OS/2's file I/O routines.) Keep Reply Packets (-E) When OMX processes a reply packet, the packet is automatically deleted. If you would rather retain the reply packet instead, set this option to YES. This is equivalent to specifying "-E" on the OMX command line, except that it will ALWAYS be enabled. NetMail Zone Gating (-G) A NetMail message that is addressed to a different zone is normally sent directly to the destination address. If, however, you wish to automatically send all out-of-zone NetMail through specified gateway systems, set this option to YES. This is equivalent to specifying "-G" on the OMX command line, except that it will ALWAYS be enabled. Keep NetMail Messages (-M) When OMX packs messages from the NetMail directory, it automatically deletes the messages it packs. If you would prefer that NetMail messages not be deleted, set this option to YES. This is equivalent to specifying "-M" on the OMX command line, except that it will ALWAYS be enabled. NetMail Address Matching (-N) When OMX packs messages from the NetMail directory, it places the messages in the first NetMail area that is encountered. If you would rather segregate NetMail messages by address (i.e. messages are tossed into individual NetMail areas based on the destination address), set this option to YES. This is equivalent to specifying "-N" on the OMX command line, except that it will ALWAYS be enabled. Ignore "Rcvd" Status (-R) When OMX searches the NetMail directory, it will ignore any NetMail message that has "Received" status. If you would rather pack NetMail regardless of this status, set this option to YES. This is equivalent to Offline Mail Executive Version 1.00 - Page 20 specifying "-R" on the OMX command line, except that it will ALWAYS be enabled. NetMail Zone Matching (-Z) When OMX packs messages from the NetMail directory, it places the messages in the first NetMail area that is encountered. If you would rather segregate NetMail messages by address (i.e. messages are tossed into individual NetMail areas based on the zone number in the destination address), set this option to YES. This is equivalent to specifying "-N" on the OMX command line, except that it will ALWAYS be enabled. MESSAGE AREA SETTINGS Message Area Settings specifies the default settings used when creating message areas in Message Area Manager. These settings include, among other things, the default Fido, Squish, and JAM directories, and the default message area and base types. Fido Base Root Path Specifies the default directory to be used as the "root path" when creating message areas that use Fido- style message bases. Fido-style message bases require separate directories for each base; this path would be used as the default path under which Fido base direc- tories are stored. Squish Base Path Specifies the default directory to be used when creating message areas that use Squish-style message bases. JAM Base Path Specifies the default directory to be used when creating message areas that use JAM-style message bases. JAM Last-Read Files Specifies how JAM last-read information is to be stored. "Standard" uses a method based on the user number, while "RA-Compatible" specifies the method used by the Remote Access BBS software. If you are converting your system from a Remote Access BBS, you should specify "RA-Compatible" in order to maintain current last-read pointers; otherwise, you should specify "Standard". (Either method is acceptable if setting up a system from scratch.) Offline Mail Executive Version 1.00 - Page 21 Message Area Type Specifies the default area type used when creating a new message area. Available area types are "NetMail", "EchoMail", and "GroupMail". Message Storage Type Specifies the default base type used when creating a new message area. Available base types are "Fido", "Squish", and "JAM". Post Under Type Specifies the default method for posting messages to be used when creating a new message area. Available posting types are "Real Name", "Alias", and "Any Name". Post Restrict Type Specifies the default posting restriction type to be used when creating a new message area. Available restriction types are "Public", "Private", "Public/ Private", and "Read Only". Keyword/Filter Type Specifies the default keyword and filter usage type to be used when creating a new message area. Available types are "None", "Keywords", "Filters", and "Keywords & Filters". Origin Line Specifies the default origin line text to be used when creating a new message area. This text is what is placed in the "* Origin:" line on EchoMail messages. For more information on the message area information shown above, refer to the "Message Area Manager" section. ARCHIVE COMMANDS Archive Commands specifies the archiver command lines that will be executed when packing and unpacking mail and reply packets. Pack Command Specifies the command line for the archiving utility, used when bundling a mail packet. Any valid archiver (PKZIP, ARJ, LHA, etc.) can be specified, along with a full path and any necessary options. Offline Mail Executive Version 1.00 - Page 22 Two macros are available for use in command lines, and should be placed in the positions dictated by the archiving utility. "@F" specifies the archive file- name, and "@I" specifies the path which contains the files to be packed into the archive. These macros will automatically be replaced by OMX with the appro- priate information. Result Code Specifies the ERRORLEVEL code returned by the archiv- ing utility which indicates that the command was successful. Any number from 0 to 255 may be speci- fied, with most archiving utilities returning 0 upon success. If you are using an archiving utility that does not return an error code, you can instruct OMX to always assume the command was successful by specifying a result code of -1. Be warned, however, that any errors which may occur will NOT be detected in this mode, since OMX will always assume that the command was successful. Unpack Command Specifies the command line for the de-archiving utili- ty, used when unpacking a reply packet. Any valid de- archiver (PKUNZIP, ARJ, LHA, etc.) can be specified, along with a full path and any necessary options. Two macros are available for use in command lines, and should be placed in the positions dictated by the de- archiving utility. "@F" specifies the archive file- name, and "@I" specifies the path in which the un- packed files will be placed. These macros will au- tomatically be replaced by OMX with the appropriate information. Note that some de-archiving utilities aren't able to accept a path to specify where the files are to be placed; they will always unpack files to the current directory. To get around this limitation, OMX will always switch to the proper path before executing the de-archiving utility, then switch back afterwards. This means that, technically, the "@I" macro is unne- cessary, but it is available and should be used never- theless. Result Code Specifies the ERRORLEVEL code returned by the de- archiving utility which indicates that the command was successful. Any number from 0 to 255 may be speci- fied, with most de-archiving utilities returning 0 upon success. Offline Mail Executive Version 1.00 - Page 23 If you are using a de-archiving utility that does not return an error code, you can instruct OMX to always assume the command was successful by specifying a result code of -1. Be warned, however, that any errors which may occur will NOT be detected in this mode, since OMX will always assume that the command was successful. Note that OMXSETUP allows the specification of commands for both DOS and OS/2. If you find yourself in a situation where you need to use both the DOS and OS/2 versions of OMX, this allows you to specify different sets of archiving and de-archiving utilities for each environment. ZONE GATE ADDRESSES Zone Gate Addresses defines the valid zones for NetMail gating, and the addresses of the gateway systems. As described earlier, zone gating allows NetMail messages destined for a zone other than your own to be routed through a "gateway" system (instead of being sent directly) which can produce quite a savings on toll charges, especially to overseas systems. The main screen displays up to 20 allowable zone gates. Use the arrows to select the entry you wish to modify, and press ENTER to modify it. This will bring up the modification screen, which provides the following options: Zone Defines the zone number that will have its messages gated. Any NetMail message that is addressed to a system in this zone will be routed through the gateway system (defined below). Address Defines the address of the gateway system which routes messages for the defined zone. Note that point sys- tems cannot be specified here. Note that zone gating does not take effect unless you specify the "-G" switch on the OMXMAIL command line (or set the "NetMail Zone Gating" option to YES in Options & Settings). Also, OMXSE- TUP will automatically fill in "gaps" in the zone gate table. That is, if entries 7-14 are empty and you defined a gateway in entry 15, OMXSETUP will automatically move it to entry 7 (thus filling in the gap). REGISTRATION CODES Registration Codes is where you input the codes necessary to unlock all of the features in OMX. After filling out and sending in the registration form, you will receive a letter that Offline Mail Executive Version 1.00 - Page 24 contains your serial number and registration code. Once those are "plugged in", all of the limits and restrictions in the shareware release will be lifted. The "Registration Status" line displays the current status ("Registered" if valid registration information has been entered, or "Unregistered" if not). After you enter your serial number and registration code as indicated, OMXSETUP will display a window that says: Thank you for registering Offline Mail Executive! if the information is valid. If this message is not displayed, double-check the serial number and registration code to be sure you entered them correctly. Also, compare the System Name, SysOp Name, and Network Address information (in "System Information") to the information on your registration letter, to ensure they match. If they don't, you will have to send the correct information and obtain new codes (there is no charge for this service, provided you have already registered). USER CONFIGURATION User Configuration defines all of the information for up to two individual users. Such items include the user's name and alias and the packet ID that OMX will use when referencing mail and reply packets. The User Configuration main screen displays abbreviated informa- tion on both users. The arrow keys are used to move the cursor bar between each user. Pressing TAB will display a window containing all of the current user's information; this is useful for quickly reviewing a user's setup. Pressing ENTER will display a window that allows you to modify the information for the current user. The following information can be modified: User Real Name The real name of the user, up to 35 characters in length. This name is used for message areas defined as only allowing real names, but more than that, it is the main identifying characteristic of the user. Note that both users cannot have the same real name. User Alias An optional alias, or "handle", for the user, up to 35 characters in length. This alias is used for message areas defined as only allowing aliases. Note that both users cannot have the same alias. Offline Mail Executive Version 1.00 - Page 25 Packet ID A one- to eight-character string that will be used as the root filename for mail and reply packets. Note that both users cannot have the same packet ID, as it would cause mass confusion when processing mail and reply packets. Reader Index Type Defines the message status index file that will be created when a mail packet is created. Two types are available: "Blue Wave" (which creates an *.XTI index file that is compatible with The Blue Wave Offline Mail Reader) and "None" (no index is created at all). Having OMX create the index will save a bit of time, as the reader will not have to go through the time and trouble of creating it (a process which can take some time, depending on how many messages are in the mail packet). Packet Extension Type Defines the type of file extension that will be used when a mail packet is created. Two types are avail- able: "Numeric" (uses extensions from "001" through "999") and "Day of Week" (uses extensions based on the day of the week, i.e. "SU1", "MO1", etc.). Tear Line Type Defines the type of tear line that will be added to messages when a reply packet is processed. Two types are available: Standard --- OMX/Blue Wave v2.12 Alternate ___ OMX/Blue Wave v2.12 The alternate tear line is provided for a special purpose. Some mail processing utilities, when pro- cessing outbound mail, will insist on replacing a valid tear line in a message with its own tear line, thereby obliterating the information that OMX normally places there. The alternate tear line type gets around this process and preserves the original infor- mation. (If your mail processor doesn't do this, or if you simply don't care what happens to the tear line, the standard tear line type should be used.) Tear Line Text Defines the text that will be written to the tear line. Two styles are available: Reader Name --- OMX/Blue Wave v2.12 OMX Version --- OMX v1.00 for DOS Offline Mail Executive Version 1.00 - Page 26 Pack Msgs From User Specifies whether or not messages that the user has written will be packed into a mail packet. If set to YES, such messages are packed; if set to NO, such messages are skipped. Create Empty Packets Specifies whether an empty mail packet is allowed. If set to YES, empty packets are allowed; if set to NO, empty packets are not allowed. Strip Subject "Re:" Specifies whether or not subject lines of messages will have any leading "Re:" sequences stripped before being packed into a mail packet. If set to YES, "Re:" sequences are stripped; if set to NO, "Re:" sequences are retained. Strip Control Info Specifies whether or not control information lines (i.e. "kludge lines") are to be stripped from messages before they are packed into a mail packet. If set to YES, control lines are stripped; if set to NO, control lines are retained. When you are finished, press ESC. If any changes were made, you will be asked whether or not the changes should be saved. Press "Y" to save the changes, or "N" (or ESC) to abandon them. Note that both users can either use the same reader, if it supports multiple users (such as The Blue Wave Offline Mail Reader), or they can use separate readers. In either case, the same directories can be used to store mail and reply packets, as each user will be using his own individual packet ID (which eliminates the mess of conflicting mail packets). MESSAGE AREA MANAGER Message Area Manager is where message areas are created and maintained. Up to 10,000 areas can be inserted, deleted, and modified, with each area having its own array of options, from the type of area (NetMail, EchoMail, or GroupMail) to the "raw" storage format (Fido, Squish, or JAM) to everything else in between. The Message Area Manager main screen displays abbreviated information on up to 10 message areas. The following control keys can be used at this screen: Esc Return to main menu. Arrows Move the cursor bar between entries. Offline Mail Executive Version 1.00 - Page 27 PgUp, PgDn Display the previous or next 10 entries. Home, End Display the first or last 10 entries. Tab Bring up a window that displays the settings for the entry under the cursor bar. Alt-A Add a blank entry to the end of the list. The blank entry can then be modified (see below). Alt-I, Ins Insert a blank entry at the cursor bar. The blank entry can then be modified (see below). Alt-D, Del Delete the entry under the cursor bar. A window will be displayed to confirm the action. Press "Y" to delete the area, "N" to leave it alone. Alt-S Sort the list. Sorting is performed in ascending order (i.e. A-Z), and can be based on the area tag or the description (see below for details on these fields). 1, 2 Toggle the "area is active" status for each user (see below under "Flag Settings" for details). Pressing ENTER will display a window that allows you to modify the information for the current entry. The following informa- tion can be modified: Area Tag A string of up to 20 characters that provides a unique identifier for the area. No two message areas can have the same area tag; if you attempt to duplicate an area tag, an error message will be displayed and the tag will not be allowed. (For EchoMail and GroupMail areas, a good idea would be to use the EchoMail or GroupMail tag name, i.e. "TREK", "C_ECHO", "OS2BBS", etc., for the sake of clarity.) EVERY MESSAGE AREA *MUST* HAVE AN AREA TAG! This tag is a crucial item in the Blue Wave format; Blue Wave compatible readers use the tag to distinguish between different message areas when creating replies, and OMXMAIL use the tag to ensure that those replies are written to the correct "raw" message bases. This applies for ALL message area types, including NetMail. (NetMail areas can have any description you care to use -- for example, "NETMAIL_FIDO" for FidoNet NetMail and "NETMAIL_TREK" for TrekNet NetMail -- as all outbound NetMail messages are written to the same NetMail directory. You don't have to use the tag "NETMAIL" at all, if that's your choice; the important thing is that each area have its own unique area tag.) Offline Mail Executive Version 1.00 - Page 28 Description Defines a short description of the areas's topic, i.e. "Star Trek", "C Programming", "OS/2 Support", etc. This description is generally used in the offline mail reader when listing available message areas. Up to 40 characters are allowed for the description. Area Type Defines the type of message that will be stored in the area. Available types are "NetMail", "EchoMail", and "GroupMail". Storage Type Defines the format used for the "raw" message base associated with this area. Available types are "Fido", "Squish", and "JAM". Note that this option is not available for NetMail areas, as OMX handles Net- Mail in a different fashion from EchoMail and Group- Mail.) Message Path Defines the directory used for the "raw" message base. Note that this option is not available for NetMail areas, as OMX uses a single NetMail directory (defined under "Paths & Filenames") for all NetMail message handling. Base Filename Defines the filename used for the "raw" message base, as required by the Squish and JAM formats. This option does not apply to the Fido format. Retention Defines the retention period for messages stored in the "raw" message base. The retention period can be defined by number of messages (up to 5000) and/or number of days (up to 99), or can be unlimited. OMXMAINT will use these settings when adjusting the number of messages in the "raw" message base via its PACK option (OMXMAINT is described in detail later). For Squish bases, these settings are written directly to the Squish files, since Squish bases have the ability to adjust themselves automatically (by number of messages only; number of days needs to be handled by an external utility, like OMXMAINT). Offline Mail Executive Version 1.00 - Page 29 Post Under Defines the name under which messages will be posted in the area. Available types are: REAL NAME Messages will always be posted using the user's real name. ALIAS Messages will always be posted using the user's alias. ANY NAME Messages will be posted using the name specified by the user in the reply message. The "Any Name" feature needs a bit of explanation. With the "Real Name" and "Alias" types, OMXMAIL will always use the necessary fields as defined for the user in User Configuration; the name that's returned by the reader in the reply header is totally ignored, and the reader itself will not allow the name to be changed. Under "Any Name", however, the reader WILL allow the name to be changed (the default is the user's real name) and OMXMAIL will accept whatever was entered by the user for each message. Hence the term "any name", as the user can literally use any name they like to identify messages. Post Restrict Defines the restriction placed on posting messages in the area. Available types are: PUBLIC Messages will always be marked as public, i.e. anyone can read them. PRIVATE Messages will always be marked as private, i.e. only the intended recipients can read them. PUBLIC/PRIVATE Messages will be marked either public or private (as specified by the user when creating the message via the offline reader). READ ONLY Messages cannot be posted in this area at all. Note that BY CONVENTION, NetMail message areas are usually marked "Private", while EchoMail and GroupMail Offline Mail Executive Version 1.00 - Page 30 areas are usually marked "Public". Of course, you can define message areas any way you like, but you should make sure that what you intend will be allowed by the person(s) in charge of the conferences (for example, most EchoMail areas in the FidoNet distribution system don't allow private messages). Address Defines the network address that will be used on all messages in the area to identify the originating system. Most of the time, this address will be your main network address, but if the area is for a confer- ence in a different network, you should put in this field the address you normally use in that network (in order that the messages will be properly identified). With multiple NetMail areas, this address is also used when packing NetMail messages based on address match- ing or zone matching (refer to the "-N" and "-Z" options under "OMXMAIL - Packet Processing Utility" for details). Origin Line Defines the text that will appear in the origin line. The origin line has the following format: * Origin: Joe's Message Emporium (1:234/56) and is normally placed at the end of EchoMail messages. Tear/Origin Defines the tear/origin line combination that is to be used for the area. Available types are: NO TEAR/ORIGIN LINES Does not add a tear or origin line to any posted message. Normally used for NetMail areas, as NetMail messages don't require either one. TEAR/ORIGIN LINES Adds both tear and origin lines to each reply message. Normally used for EchoMail areas, as EchoMail messages require them. TEAR LINE ONLY Adds only a tear line to each reply message. BLANK TEAR/ORIGIN LINES Adds a blank tear line and an origin line to each reply message. Offline Mail Executive Version 1.00 - Page 31 BLANK TEAR LINE ONLY Adds only a blank tear line to each reply message. Note that for EchoMail areas, the only valid types are "Tear/Origin Lines" and "Blank Tear/Origin Lines", as EchoMail areas require both tear and origin lines. For NetMail areas, the default type is "No Tear/Origin Lines". For EchoMail and GroupMail areas, the default type is "Tear/Origin Lines". Keywrd/Filter Specifies whether keyword or filter searches (or both) should be performed on this area. Available settings are: NONE Do not perform any keyword or filter search- ing at all. KEYWORDS Perform keyword searching only. FILTERS Perform filter searching only. KEYWORDS & FILTERS Perform both keyword and filter searching. The "Keywords & Filters" option needs explaining, as it is a rather new concept. When a message area with this setting is scanned, a keyword search will be performed on each message; if a keyword match is found (meaning that the message is valid), a filter search is then performed on that message. If the filter search fails, the message is then packed; if, however, a filter match is found (meaning that the message is NOT valid), the message is skipped. For more information on how keywords and filters work, refer to the "Creating a Mail Packet" section under "OMXMAIL - Packet Processing Utility". Flag Settings Defines the settings of several miscellaneous options. These options are: ASCII8 Defines whether or not characters with ASCII codes in the range 128-255 (also known as "8-bit ASCII" or "high ASCII") can be used in messages posted in this area. If ena- bled, ASCII codes 128-255 will be allowed; Offline Mail Executive Version 1.00 - Page 32 if disabled, they will be converted to ASCII codes 0-127. Useful for EchoMail conferenc- es that prohibit "high ASCII" characters. USER 1 Defines whether user 1 has access to this area. If enabled, user 1 can obtain messag- es from, and post messages to this area. If disabled, user 1 cannot access this area at all. USER 2 Same as above but for user 2. When you are finished, press ESC. If any changes were made, you will be asked whether or not the changes should be saved. Press "Y" to save the changes, or "N" (or ESC) to abandon them. KEYWORD & FILTER MANAGERS The Keyword and Filter Managers define, respectively, the keywords and filters that will be compared to inbound messages when creating a mail packet. Up to 100 entries can be defined for each type (for a total of 200 keywords and filters). Since both the Keyword and Filter Managers are identical (save for the type of information each stores), both will be discussed in this section (referred to as the "Keyword/Filter Manager"). The Keyword/Filter Manager main screen displays abbreviated information on up to 10 entries. The following control keys can be used at this screen: Esc Return to main menu. Arrows Move the cursor bar between entries. PgUp, PgDn Display the previous or next 10 entries. Home, End Display the first or last 10 entries. Tab Bring up a window that displays the settings for the entry under the cursor bar. Alt-A Add a blank entry to the end of the list. The blank entry can then be modified (see below). Alt-I, Ins Insert a blank entry at the cursor bar. The blank entry can then be modified (see below). Alt-D, Del Delete the entry under the cursor bar. A window will be displayed to confirm the action. Press "Y" to delete the area, "N" to leave it alone. Alt-S Sort the list. Sorting is performed in ascending order (i.e. A-Z), and can be based on the area tag or the comparison text (see below for details on these fields). 1, 2 Toggle the "area is active" status for each user (see below for details). Offline Mail Executive Version 1.00 - Page 33 Pressing ENTER will display a window that allows you to modify the information for the current entry. The following informa- tion can be modified: Status Determines whether or not the entry is active. If set to "Active", the keyword/filter will be used during a search. If set to "Inactive", the keyword/filter is skipped. Field to Compare Defines the field in the message header that will be used for the comparison. Available fields are: FROM Performs the comparison on the text in the "From:" field (i.e. the person who wrote the message). TO Performs the comparison on the text in the "To:" field (i.e. the person to whom the message is addressed). FROM/TO Performs the comparison on the text in both the "From:" and "To:" fields. SUBJECT Performs the comparison on the text in the "Subject:" field. ADDRESS Performs the comparison on the network address from which the message originated. Text to Compare Defines the text that needs to be matched in order for the comparison to be successful. For a keyword, this is the text that makes the message valid; for a filt- er, it is the text that makes the message invalid. The comparisons are always case-insensitive, so it doesn't matter how the text is specified in this field with regards to upper and lower case letters. Area Tag Defines the area tag of the message area to which this entry is to be confined. For example, an area tag of "TREK" would restrict this entry to messages scanned in the message area with that specific area tag. Offline Mail Executive Version 1.00 - Page 34 If this field is blank, the entry will be compared to messages in ALL message areas (i.e. it will be a "global" entry). This is useful if, for example, you know someone who is SO obnoxious that you wish to filter out ANY message from this person in EVERY message area you read! Partial Comparison Specifies how a successful comparison is to be deter- mined. If set to NO, then the text in the specified field must EXACTLY match the text defined in this entry. If set to YES, the text in the specified field must CONTAIN the text defined in this entry. Let's examine this closer. Say, for example, that an entry contains the text "Smith" and is to be compared to the "From:" field of messages. If this field is set to NO, the "From:" field must be "Smith" to in- dicate a successful comparison. If this field is set to YES, however, then the text "Smith" must be con- tained ANYWHERE WITHIN THE FIELD to indicate success; in other words, "Smith", "John Smith", and "Roy the Blacksmith" would all indicate successful comparisons. Note that this option does not apply when comparing the "Address" field, which are always performed as an exact comparison. Also, setting this option to YES is recommended for "Subject:" field comparisons, as the chances of performing an exact match on text in a "Subject:" field are quite low. User #1 User #2 Specifies whether or not the entry is active for each particular user. If set to YES, the entry is active for the user in question; if set to NO, the entry is inactive. (These settings DO NOT override the "Sta- tus" setting. If "Status" is set to "Inactive", then the entry will ALWAYS be inactive regardless of these individual settings.) When you are finished, press ESC. If any changes were made, you will be asked whether or not the changes should be saved. Press "Y" to save the changes, or "N" (or ESC) to abandon them. Note that if you wish to scan for the same keyword or filter in multiple areas, but not ALL areas, you will have to create separate entries for each area. This is because a single keyword or filter entry cannot specify multiple areas (it can only specify one area, or ALL areas). Offline Mail Executive Version 1.00 - Page 35 IMPORT INFORMATION Import Information allows you to configure many of the settings in the OMX package from the information contained in various control files of other programs. These include the control files from front-end mailers, message area files from EchoMail processors, and more. The following options are available: File to Import Specifies the type of file that is to be imported. The following files are currently supported: AREAS.BBS FIDONET.NA (and FIDONET.NO) BinkleyTerm 2.x (BINKLEY.CFG) FrontDoor 1.99 (FD.SYS) FrontDoor 2.x (SETUP.FD) GEcho 1.00 (SETUP.GE) InterMail 2.x (FD.SYS) SquishMail 1.x (SQUISH.CFG) as well as two OMX-specific files, OMXAREAS.CFG (message areas) and OMXSETUP.CFG (system information). These two files are described in detail in Appendix C, "Formats of OMX Import/Export Files". Path and File Defines the path and name of the file to be imported. Replace Areas Defines how the importing process will behave as it relates to the importing of message areas. Available types are: OVERWRITE The current message area file is deleted, and the imported information will be used to create a new message area file. UPDATE The imported information is used to update the currently defined message areas. If the imported information does not match up to any defined message area, it will be added to the message area list. Note that this option does not apply when importing information from certain file types (such as the control file of a front-end mailer). In these cases, this option will be set to "N/A" and you will not be allowed to change it. Offline Mail Executive Version 1.00 - Page 36 When the above information has been configured properly, move the cursor bar to "Begin Import From Selected File" and press ENTER. The specified file will be read, and the current OMX information will be updated. (If there were any problems, an error message will be displayed and the current OMX information will be left unchanged.) You may import as many files as needed. When you are finished, press ESC to return to the main menu. EXPORT INFORMATION Export Information allows you to write the current OMX system and message area settings to disk files in various formats. The following options are available: File to Export Defines the type of file that will be written. The file types currently supported are: OMX Area List (OMXAREAS.CFG) OMX System Info (OMXSETUP.CFG) AREAS.BBS (standard) AREAS.BBS (SquishMail-style) The formats for OMXAREAS.CFG and OMXSETUP.CFG are discussed in Appendix C, "Formats of OMX Import/Export Files". Path and File Defines the path and name of the file to be written. When the above information has been configured properly, move the cursor bar to "Begin Export To Selected File" and press ENTER. The specified file will be created. (If there were any problems, an error message will be displayed.) You may export as many files as needed. When you are finished, press ESC to return to the main menu. Offline Mail Executive Version 1.00 - Page 37 ╒══════════════════════════════════════════════════════════════╕ │ ▒▒▒▒▒▒▒▒▒▒▒ OMXMAINT - OMX MAINTENANCE UTILITY ▒▒▒▒▒▒▒▒▒▒▒ │ ╘══════════════════════════════════════════════════════════════╛ The OMXMAINT utility is used to perform maintenance on the "raw" message bases that are used by OMX. Such maintenance includes packing (removing messages from a base to maintain the number of messages at a certain level), renumbering (forcing messages to be numbered in sequential order), and more. You may ask yourself, why include such a utility when many EchoMail processors already come with such programs (and many more are available elsewhere)? Two reasons: One, OMXMAINT is geared specifically to the needs of OMX users; and two, OMXMAINT makes OMX a complete, "all-in-one" package. Nothing else is needed! To run OMXMAINT, move to the directory that contains the OMX data files and enter the following on the DOS or OS/2 command line: OMXMAINT functions switches The following functions are available. Note that many of these functions will not be used by most people, due to their esoteric nature, but they are nonetheless available if needed. FIRST Set Last-Read Pointers to First Message This function cycles through every message area and resets the last-read pointers to point to the first message in each area. The net effect is that ALL messages will be packed the next time OMXMAIL is used to create a mail pack- et. Note that FIRST will adjust the last-read pointers of both users, unless the "-U" switch is used (see below). LAST Set Last-Read Pointers to Last Message This function cycles through every message area and resets the last-read pointers to point to the last message in each area. The net effect will be that NO messages will be packed the next time OMXMAIL is used to create a mail packet. Note that LAST will adjust the last-read pointers of both users, unless the "-U" switch is used (see below). PACK Pack Message Bases This function cycles through every message area and adjusts them so that they conform to their retention settings. For retention settings based on number of messages, this means that messages (starting from the first one) will be deleted until the number of messages does not exceed the specified Offline Mail Executive Version 1.00 - Page 38 number. For retention settings based on number of days, all messages that are older than the specified number of days are deleted. For a Fido base, PACK will physically delete the message files, then renumber the files so that the messages are numbered sequentially (starting at message 1). Any and all reply links between messages will be preserved whenever possible. For Squish and JAM bases, PACK will create completely new message base files (minus the deleted messages). This is done even if no messages were deleted. The net effect is that bases will not only conform to the retention settings, they will physically be as small as they can possibly become (as Squish and JAM base files can eventually accu- mulate a lot of wasted "dead space"). As with Fido bases, any and all reply links between messages will be preserved whenever possible. Note that you should not use the PACK function until you have created your mail packets first, as you might end up missing messages if a base contains more new messages than what is allowed by its retention settings (some of the new messages would be eliminated by the packing routine). PURGE Delete All Messages In All Areas The PACK function was designed for users who, for whatever reason, wish to keep the "raw" message bases intact after mail packets have been created. If, however, you'd rather start with a "clean slate" after creating your mail pack- ets, the PURGE function is what you need. This function cycles through each message area and deletes every single message from each area (with appropriate adjustments to the last-read pointers), thus freeing up disk space for the next batch of messages. Note that you should not use the PURGE function until you have created your mail packets first, for obvious reasons! RENUM Renumber Message Bases This function will renumber the messages in all Fido-style "raw" message bases so that the messages are numbered sequentially. All message reply linkages and last-read pointers are adjusted accordingly. (This function does not apply to Squish or JAM bases.) Note that RENUM also renumbers the NetMail directory (defined in the "Paths & Filenames" section in OMXSETUP), unless the "-N" switch is used (see below). Offline Mail Executive Version 1.00 - Page 39 RETAIN Reset Message Base Retention Settings This function will set the retention settings in the "raw" files for Squish-style message bases to match the settings defined in Message Area Manager. This is provided mainly to support the ability of Squish bases to automatically adjust themselves based on number of messages. (This function does not apply to Fido or JAM bases.) The following optional switches are available to alter the behavior of the OMXMAINT functions: -F Skip Fido-Style Message Bases Forces OMXMAINT to skip over any message area that uses a Fido-style "raw" message base. (Note that this switch is ignored when using RETAIN, a function which does not apply to Fido-style bases. Also, the Fido-specific RENUM func- tion is unaffected by this switch.) -J Skip JAM-Style Message Bases Forces OMXMAINT to skip over any message area that uses a JAM-style "raw" message base. (Note that this switch is ignored when using RENUM or RETAIN, as those functions do not apply to JAM-style bases.) -L Disable Activity Log Output Forces OMXMAINT to suppress all output to the OMX activity log (as defined in the "Paths & Filenames" section of OMXSETUP). -N Ignore NetMail Directory Forces OMXMAINT to ignore the NetMail directory. (Note that this function applies to the RENUM function only; it is ignored otherwise.) -S Skip Squish-Style Message Bases Forces OMXMAINT to skip over any message area that uses a Squish-style "raw" message base. (Note that this switch is ignored when using RENUM, as that function does not apply to Squish-style bases. Also, the Squish-specific RETAIN function is unaffected by this switch.) -Ux Specify User Number Forces OMXMAINT to only alter the last-read pointer infor- mation for the specified user; otherwise, the last-read pointers of both users are altered. (Note that this switch only applies to the FIRST and LAST functions; it is ignored otherwise.) Offline Mail Executive Version 1.00 - Page 40 Note that multiple functions and switches can be specified, in any order, on the OMXMAINT command line. Keep in mind, however, that some combinations make no sense. For example, specifying both FIRST and LAST at the same time would be useless, as each performs the exact opposite function! Another example would be using PURGE with practically any other function, as PURGE wipes clean all the message bases; using any other function (with the exception of RETAIN) would be unnecessary. Offline Mail Executive Version 1.00 - Page 41 ╒══════════════════════════════════════════════════════════════╕ │ ▒▒▒▒▒▒▒▒▒ APPENDIX A - NETMAIL PROCESSING IN OMX ▒▒▒▒▒▒▒▒▒ │ ╘══════════════════════════════════════════════════════════════╛ The method in which NetMail is handled in OMX may be somewhat different that what you're used to seeing. It may seem strange at first, especially the part about OMX only needing to know about one NetMail directory, but it's actually rather simple (and logical) once you examine it further. Even if you don't currently plan to use OMX for your NetMail, an examination of how it's handled may be of interest to you. If you belong to only one network, NetMail handling is easy: Simply define a NetMail area (via the Message Area Manager in OMXSETUP) using your assigned network address. OMX and your offline mail reader will then only need to deal with one NetMail area, and you won't have to give it a second thought. If, however, you belong to multiple networks, you need to get a little more "creative". The easiest thing to do is to define NetMail areas for each network to which you belong (again, via the Message Area Manager in OMXSETUP) using the appropriate address for each network (if you have multiple addresses in a network, use the one that is used most often). Then, when you create a mail packet via OMXMAIL PACK, use the "-Z" (NetMail zone matching) switch to separate inbound NetMail into the areas for each specific network. (An alternative is to use the "-N" switch, for NetMail exact address matching, provided that you only have one address per network.) Creating NetMail messages with the offline mail reader is also a different ballgame -- though not MUCH different -- with multiple NetMail areas. All you need to do is make sure that you choose the proper NetMail area when creating messages destined for a particular network (the same goes for creating NetMail replies to EchoMail or GroupMail messages), as OMXMAIL will ensure that the origin and destination addresses are correct when unpacking the reply packet. Offline Mail Executive Version 1.00 - Page 42 ╒══════════════════════════════════════════════════════════════╕ │ ▒▒▒ APPENDIX B - TECHNICAL INFO ON LAST═READ POINTERS ▒▒▒▒ │ ╘══════════════════════════════════════════════════════════════╛ The following is a technical explanation of how OMX stores and handles last-read pointers for the three "raw" message base types it supports. If you aren't the technical type, feel free to ignore this section... at least until you BECOME the techni- cal type! FIDO BASES Although there is no official standard for storing last- read pointer information in a Fido base, OMX uses what has essentially become the de-facto standard (mainly because it is the method used in the Fido BBS, the origin of the Fido format). A file called LASTREAD is created and maintained in the Fido base directory, with each record consisting of a two-byte (16-bit) unsigned value; this value is the number of the last message that was read (packed). The first two-byte record stores the information for user 1, and the second two-byte record stores the information for user 2. Each record can store a maximum value of 65,535 (the limit for a 16-bit unsigned value). SQUISH BASES For a Squish base, a file with the extension *.SQL is created and maintained in the same directory as the other files for the Squish base. Each record of the *.SQL file consists of a four-byte (32-bit) unsigned value; this value is the unique message ID (UMSGID) of the last message that was read (packed). The first four-byte record stores the information for user 1, and the second four-byte record stores the information for user 2. Each record can store a maximum value of 4,294,967,295 (the limit for a 32-bit unsigned value). JAM BASES For a JAM base, a file with the extension *.JLR is created and maintained in the same directory as the other files for the JAM base. Each record of the *.JLR file consists of a 16-byte structure with four four-byte (32-bit) fields: User CRC (based on the user's real name), user ID, last message read, and highest message read. The highest mes- sage read field contains the message number of the last message that was read (packed). The information stored in the user ID field depends on the JAM Last-Read Files set- ting (defined in "Message Area Settings" in OMXSETUP); it will either be the user CRC ("RA-Compatible") or the user number ("Standard"). The records for each user are not stored sequentially; they are created at the end of the file if not present, and are searched for when needed (based on the user ID field). Offline Mail Executive Version 1.00 - Page 43 ╒══════════════════════════════════════════════════════════════╕ │ ▒▒▒▒ APPENDIX C - FORMATS OF OMX IMPORT/EXPORT FILES ▒▒▒▒▒ │ ╘══════════════════════════════════════════════════════════════╛ In addition to the data files used by other programs, OMXSETUP has the ability to import and export data files specific to OMX. This feature means that you can save a copy of your current OMX configuration and restore it at any time you like (for example, if your data files somehow became garbled, or if you made changes that you suddenly decide you didn't want made). There are two OMX file types, OMXSETUP.CFG (system information) and OMXAREAS.CFG (message areas). Each is a plain ASCII text file, and though each file serves a different purpose, they both follow the same set of formatting rules: * Each line defines one piece of information. * Blank spaces at the start of each line are ignored. Thus, any information line can be indented any number of spaces (for purposes of clarity). * A semicolon (";") denotes the beginning of a comment. Com- ments can appear at the start of a line, or at the end of any valid information line. * Blank lines are ignored. The format of an information line consists of a single keyword optionally followed by user-defined information, as follows: Keyword Text There can be any number of spaces between the keyword and the text; OMXSETUP will start accepting information at the first non-space character between the two. Also note that the keyword is not case sensitive, thus it can be specified with any combi- nation of upper and lower case characters. (In the descriptions shown below, the text field will be denoted as "<text>" for alphanumeric text, or "<value>" for numerical text. The left and right braces are for clarification only, and are NOT to be entered. Also, if a maximum length is specified, be aware that any number of characters beyond that length will be ignored.) OMX SYSTEM INFORMATION (OMXSETUP.CFG) OMXSETUP.CFG specifies all OMX information that doesn't pertain to message areas. This includes the system name, registration codes, user information, and so on. The following keywords are available: SystemName <text> Specifies the name of the system. Maximum length is 51 characters. Offline Mail Executive Version 1.00 - Page 44 SysopName <text> Specifies the name of the SysOp. Maximum length is 35 characters. Address <text> Specifies the main network address in standard FidoNet address format (zone:net/node.point). If the zone number is not specified, it will default to 1. If the point number is not specified, it will default to 0. SerialNum <text> Specifies the registration serial number. Maximum length is 9 characters. (Any text will be accepted; however, only a valid serial number, combined with a valid registration code, will properly register OMX.) RegCode <value> Specifies the registration code. Maximum length is 10 characters. (Any value will be accepted; however, only a valid registration code, combined with a valid serial number, will properly register OMX.) PackCmdDOS <text> Specifies the command line used to archive a mail packet under DOS. Maximum length is 50 characters. PackResultDOS <value> Specifies the ERRORLEVEL result code returned by the Pack- CmdDOS command. The value can be a number between 0 and 255, or -1. UnpackCmdDOS <text> Specifies the command line used to de-archive a reply packet under DOS. Maximum length is 50 characters. UnpackResultDOS <value> Specifies the ERRORLEVEL result code returned by the Un- packCmdDOS command. The value can be a number between 0 and 255, or -1. PackCmdOS2 <text> Specifies the command line used to archive a mail packet under OS/2. Maximum length is 50 characters. Offline Mail Executive Version 1.00 - Page 45 PackResultOS2 <value> Specifies the ERRORLEVEL result code returned by the Pack- CmdOS2 command. The value can be a number between 0 and 255, or -1. UnpackCmdOS2 <text> Specifies the command line used to de-archive a reply packet under OS/2. Maximum length is 50 characters. UnpackResultOS2 <value> Specifies the ERRORLEVEL result code returned by the Un- packCmdOS2 command. The value can be a number between 0 and 255, or -1. BWPacketPath <text> Specifies the directory used to store newly created mail packets. Maximum length is 40 characters. BWReplyPath <text> Specifies the directory that will be scanned for reply packets. Maximum length is 40 characters. OMXWorkPath <text> Specifies the directory that will be used by OMXMAIL to store temporary files. Maximum length is 40 characters. NetMailPath <text> Specifies the directory used to store NetMail messages. Maximum length is 40 characters. LogFile <text> Specifies the name of the activity log file. Maximum length is 40 characters. LogFileType <text> Specifies the style used to write information to the activity log. The specified text can be "BinkleyTerm" or "FrontDoor". SemaphoreFile <text> Specifies the name of the file that will be created to indicate that messages have been unpacked. Maximum length is 40 characters. Offline Mail Executive Version 1.00 - Page 46 EchoTossFile <text> Specifies the name of the file that will be used to write the area tags of message areas that have messages to be exported via the EchoMail processor. Maximum length is 40 characters. DefaultOrigin <text> Specifies the origin line text that will be used by default when creating a new message area. Maximum length is 55 characters. DefaultFidoPath <text> Specifies the path that will be used by default when creating a message area that uses the Fido format for storing "raw" messages. Maximum length is 40 characters. DefaultSquishPath <text> Specifies the path that will be used by default when creating a message area that uses the Squish format for storing "raw" messages. Maximum length is 40 characters. DefaultJAMPath <text> Specifies the path that will be used by default when creating a message area that uses the JAM format for stor- ing "raw" messages. Maximum length is 40 characters. DefaultAreaType <text> Specifies the type of message area that will be used by default when creating a new message area. The specified text can be "NetMail", "EchoMail", or "GroupMail". DefaultBaseType <text> Specifies the "raw" message base format that will be used by default when creating a new message area. The specified text can be "Fido", "Squish", or "JAM". DefaultNameType <text> Specifies the "name to post under" type that will be used by default when creating a new message area. The specified text can be "Real Name", "Alias", or "Any Name". DefaultPostType <text> Specifies the "posting restriction" type that will be used by default when creating a new message area. The specified text can be "Public", "Private", "Public/Private", or "Read Only". Offline Mail Executive Version 1.00 - Page 47 DefaultKeyFltType <text> Specifies the default keyword/filter type that will be used by default when creating a new message area. The specified text can be "None", "Keywords", "Filters", or "Keywords & Filters". JAMLastReadType <text> Specifies the method used to store last-read pointer infor- mation for "raw" message bases in JAM format. The speci- fied text can be "Standard" or "RA-Compatible". ZoneGate <text> Specifies an entry for the NetMail zone gate table. The text is specified as the zone number followed by the gate address (i.e. "2 1:1/2"). Up to 20 ZoneGate statements may appear in the file; if there are more than 20, the extras will be ignored. BIOSVideo If specified, video output via the PC BIOS routines will be enabled. CGASnow If specified, video output will be adjusted to eliminate "snow" interference on CGA video monitors. NetMailExactMatch If specified, NetMail will be packed into multiple NetMail areas based on the entire origin address. UseZoneGates If specified, NetMail that is unpacked from reply packets will be addressed based on the zone gate table. KeepNetMail If specified, NetMail messages that are in the NetMail directory will be retained after being packed, instead of being deleted. IgnoreNetMailRcvd If specified, NetMail will be packed even if it has the "Received" status flag set. NetMailZoneMatch If specified, NetMail will be packed into multiple NetMail areas based on the zone number of the origin address. Offline Mail Executive Version 1.00 - Page 48 SlowMessagePurge If specified, multiple files in a directory will be purged one at a time, instead of being purged via a special DOS routine that performs a "fast" purge. KeepReplyPackets If specified, reply packets will be retained after they have been unpacked and processed, instead of being deleted. BeginUser1 BeginUser2 Specifies the start of a block of keywords that pertain only to user 1 or user 2, respectively. Only the following user-related keywords are allowed in such a block: UserName <text> Specifies the real name of the user. Maximum length is 35 characters. UserAlias <text> Specifies the alias of the user. Maximum length is 35 characters. UserPacketID <text> Specifies the packet ID assigned to the user. Maximum length is 8 characters. UserIndexType <text> Specifies the type of message status index file that will be included when a mail packet is created. The specified text can be "None" or "Blue Wave". UserFlags <text> Specifies various options that should be set for this user. The specified text can include the following keywords, separated by one or more spaces: NoUser Do not pack messages written by user. NoEmpty Do not create empty mail packets. StripRE Strip "Re:" from subject fields. NoCtrl Strip control lines from messages. OMXTear Use OMX version tear lines instead of reader version tear lines. AltTear Use alternate style tear lines instead of standard tear lines. Offline Mail Executive Version 1.00 - Page 49 PktDowk Use day-of-week extensions on mail packets instead of numeric exten- sions. EndUser1 EndUser2 Specifies the end of a block of user-related keywords. Each "BeginUserX" block MUST end with a "EndUserX" block, as user-related keywords cannot be combined with normal keywords (and vice-versa). OMX MESSAGE AREAS (OMXAREAS.CFG) OMXAREAS.CFG specifies the information for all message areas that are available. This includes the area name, area tag, message path, area type, and so on. The information for each message area is defined as a series of "blocks", which begin and end with the "BeginArea" and "EndArea" keywords, respectively: BeginArea AreaTag BLUEWAVE Title Blue Wave Support ... EndArea Up to 10,000 blocks may be defined (the maximum number of mes- sage areas supported by OMX). The following keywords can be used within each block: AreaTag <text> Specifies the area tag assigned to the message area. Maximum length is 20 characters. Title <text> Specifies the description of the message area. Maximum length is 40 characters. Address <text> Specifies the network address assigned to the message area. The address is in FidoNet format (zone:net/node.point), with the zone defaulting to 1 and the point defaulting to 0 if one or the other is not specified. AreaType <text> Specifies the message area type. The specified text can be "NetMail", "EchoMail", or "GroupMail". Offline Mail Executive Version 1.00 - Page 50 BaseType <text> Specifies the "raw" message base type that is used by the message area. The specified text can be "Fido", "Squish", or "JAM". (Note that this keyword does not apply to Net- Mail areas.) MsgPath <text> Specifies the path to the "raw" message base files. Maxi- mum length is 40 characters. (Note that this keyword does not apply to NetMail areas.) BaseName <text> Specifies the root name of the "raw" message base files for Squish and JAM areas. Maximum length is 8 characters. (Note that this keyword does not apply to NetMail areas, nor does it apply to areas using the Fido format.) NameType <text> Specifies the name that will be used when posting messages in this area. The specified text can be "Real Name", "Alias", or "Any Name". MaxMsgs <value> Specifies the maximum number of messages allowed in the "raw" message base. The specified value can be from 0 to 5000. MaxDays <value> Specifies the maximum age (in days) of messages to be retained in the "raw" message base. The specified value can be from 0 to 99. KeyFlt <text> Specifies the keyword/filter type to use for this message area. The specified value can be "None", "Keywords", "Filters", or "Keywords & Filters". Origin <text> Specifies the text to be used in origin lines. Maximum length is 55 characters. TearOrigin <text> Specifies the tear/origin line type to be used. The specified text may be "None", "Tear & Origin", "Tear Only", "Black Tear & Origin", or "Blank Tear Only". Offline Mail Executive Version 1.00 - Page 51 Flags <text> Specifies various options that should be set for this message area. The specified text can include the following keywords (separated by one or more spaces): ASCII8 Allow the use of ASCII characters in the range 128-255. User1 Allow access to this area for user 1. User2 Allow access to this area for user 2. ADDITIONAL COMMENTARY Simply describing the keywords available in these files isn't really enough to familiarize you with how the files can/should appear. We recommend that you set up OMX, then use the Export Information option in OMXSETUP to create the OMXSETUP.CFG and OMXAREAS.CFG files. This way, you can see the layout of these files "in action". Offline Mail Executive Version 1.00 - Page 52 ╒══════════════════════════════════════════════════════════════╕ │ ▒▒▒▒▒▒▒▒▒▒▒▒ APPENDIX D - SUGGESTED SOFTWARE ▒▒▒▒▒▒▒▒▒▒▒▒▒ │ ╘══════════════════════════════════════════════════════════════╛ The following is a list of software packages for you to consider when setting up your system. These packages include front-end mailers, EchoMail processors, offline mail readers, and device drivers for serial communications. Note that this is NOT an endorsement of these packages; it is simply a reference guide to what is available out there. Also note that this list is current as of this writing. Since software development does not stand still, much of this software will be updated and enhanced over time (and some of it might even end up "orphaned" as authors decide to move on to other endeavors). Keep this in mind when searching for a particular program! Program: FrontDoor Version: 2.12 Filename: FD212.ARJ (DOS only) Category: Front-end mailer A very popular front-end mailer within FidoNet. Sports a clean, easy-to-understand, menu-driven interface, which makes setup and usage a breeze. Compatible with all Fido- Net technical specifications. Program: SquishMail Version: 1.10 Filename: SQSH_110.LZH (DOS) SQSHP110.LZH (OS/2) Category: EchoMail processor Supports the Fido and Squish message base formats... and, in fact, was the first to support Squish (not surprising; its author created it!). Both DOS and OS/2 versions use the same configuration files, which makes switching from one to the other a piece of cake. Includes various message base maintenance utilities. Program: FastEcho Version: 1.40 Filename: FASTE140.ZIP (DOS only) Category: EchoMail processor Supports the Fido, Squish, JAM, and Hudson message base formats. Configuration is performed via a menu-driven setup utility, making it one of the easiest EchoMail pro- cessors to use and maintain. Includes various message base maintenance utilities. Offline Mail Executive Version 1.00 - Page 53 Program: The Blue Wave Offline Mail Reader Version: 2.12 Filename: BWAVE212.ZIP (DOS) BW212OS2.ZIP (OS/2) Category: Offline mail reader The reader which set the standard for Blue Wave! Sports a menu-driven, easy-to-use text interface, with plenty of powerful features (including a sophisticated tagline sys- tem). Also supports mail packets created in the QWK for- mat. Program: Wave Rider for Windows Version: 1.20 Filename: WR120A.ZIP and WR120B.ZIP Category: Offline mail reader The first offline mail reader for Microsoft Windows to support the Blue Wave format. Takes full advantage of the Windows interface, including pull-down menus, icons, and multiple windows. Program: X00 FOSSIL Communications Driver Version: 1.50 Filename: X00V150.ZIP (DOS only) Category: Device driver A high-speed communications driver for DOS. Required for programs that provide communications via the FOSSIL API (which includes most front-end mailers, such as FrontDoor). Program: SIO High-Performance Communications Driver Version: 1.32 Filename: SIO132.ZIP (OS/2 only) Category: Device driver A replacement for the standard OS/2 communications drivers, providing improved support for high-speed communications (especially in DOS sessions). Also includes a driver that implements the FOSSIL API in DOS sessions, eliminating the need for a separate FOSSIL driver (see above). SIO should be considered a must for any OS/2 user that requires reliable high-speed communications. One final note. If you don't see your favorite software package listed here, it doesn't mean that it's not a perfectly good program. In fact, it might even be better than what is listed here. However, the purpose of this particular list is to steer users (particularly first-time users) towards products that we believe are both powerful and easy-to-use, not to be an all- encompassing catalog of available software. Offline Mail Executive Version 1.00 - Page 54