home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
OS/2 Professional
/
OS2PRO194.ISO
/
os2
/
com
/
bbs
/
ommm
/
ommm.doc
< prev
next >
Wrap
Text File
|
1989-01-18
|
80KB
|
1,826 lines
+---+
| |
| |====================+
\ \ | | / /
\ +---+ /
oMMM
The Opus Matrix Message Masher
A Mail Processing and Routing Program for
Opus-CBCS and BinkleyTerm Systems
Version 1.30
January 21, 1989
Software Written by
Marshall Presnell and Jim Nutt
Based on Bob Hartman's Original Code
From a Concept and Framework Coded by
Wynn Wagner
Documentation Written and Hacked by Alan Applegate
Under the Influence of Homebrew
Some Segments From "MATRIX.DOC"
Copyright (C) 1987, Wynn Wagner, All Rights Reserved
Used by Permission
Software Copyright (C) 1988, 1989 BS Software
Documentation Copyright (C) 1988, 1989 Alan D. Applegate
All Rights of the Copyright Holders
Strictly Reserved
Use and Distribution Allowed Only in Accordance
With the Terms Listed Herein
Multi-Zone Operation Section
by Vince Perriello
oMMM Version 1.30 - Page 1
+---+
| | Contents
| |====================+
\ \ | | / /
\ +---+ /
INTRODUCTION 2
STUFF AND NONSENSE 3
What You Can and Cannot Do 3
Acknowledgements 4
SPECIAL NOTICES 5
Regarding ARCmail 5
Regarding ZOOmail 5
Politics 5
Regarding Archiving Programs 5
TECHNORATA 6
How Mail is Handled 6
A Sample Message, Start to Finish 9
The Concept of Cost 10
More on File Names 10
Other Files 11
What oMMM Does 13
HOW TO 15
Making it Mash 15
Control File Parameters 15
Leave Related Commands 16
General Commands 17
Mail Routing - Direct Flavor Commands 19
- Hold Flavor Commands 20
- Continuous Flavor Commands 22
ZOOmail Command Differences 24
Add Command Modifiers 24
oMMM Command Line Options 25
OMMM.CFG Configuration File 28
EXAMPLES 29
Sample oMMM Control File for BinkleyTerm and
Opus 1.1x 29
Sample oMMM Control File for Opus 1.0x 29
MULTI-ZONE SUPPORT 31
General Information 31
oMMM Version 1.30 - Page 2
+---+
| | Introduction
| |====================+
\ \ | | / /
\ +---+ /
oMMM, the Opus Matrix Message Masher (hence the mallet
illustration) is a mail processing and routing program originally
intended for use with Opus-CBCS, a FidoNet compatible BBS
package. oMMM is also used in conjunction with BinkleyTerm, a
FidoNet compatible mail interface package.
oMMM performs several tasks, including packing of NetMail,
archiving of mail into "ARCmail" packets, routing of outbound
mail, re-routing of pending outbound mail, and more.
This documentation is divided into three primary sections:
TECHNORATA
A technical description of mail operation and how oMMM
affects that process.
HOW TO
What oMMM's various functions are, and how they are
used.
EXAMPLES
Situations you may encounter, and practical ways to
handle them.
There are other sections as well. Please refer to the Contents
page for a complete listing.
NOTE! This documentation does not go out of its way to explain
new concepts or terminology. The documentation for your system
(Opus-CBCS or BinkleyTerm) should serve as your main reference.
oMMM Version 1.30 - Page 3
+---+
| | Stuff and Nonsense
| |====================+
\ \ | | / /
\ +---+ /
WHAT YOU CAN AND CAN'T DO
The license for the oMMM software is contained separately in the
oMMM distribution package. The following pertains ONLY to the
documentation.
This oMMM documentation is a copyrighted, creative work. The
rights to it are owned exclusively by the author, who provides a
limited license granting certain rights which may be altered or
revoked at any time. You are licensed to use and distribute the
oMMM documentation under these terms:
- The documentation must not be altered and subsequently
distributed to others.
- No profit may be realized directly from its distribution.
So-called "pay systems" who offer it for download may levy
their normal charge.
- If the documentation is to be distributed in hard copy
form, the hard copy must be for personal use, or limited to
non-profit uses only.
- No rights whatsoever are granted to reproduce this
document for profit in any form, in whole or part, except as
provided herein.
- No rights whatsoever are granted to reproduce any portion
of this documentation as part of another work without the
express, written permission of the author, except as
provided by Federal Copyright Laws, and applicable
international treaties.
- All translation rights are retained by the author.
For further clarification or information regarding this license,
or to obtain a license for a specific purpose please write:
oMMM Documentation
Alan D. Applegate
P. O. Box 260723
Lakewood, CO 80226-0723
oMMM Version 1.30 - Page 4
ACKNOWLEDGEMENTS
The following names are either trademarks of and/or the efforts
of the person and/or organization given:
Fido, FidoNet - Tom Jennings, Fido Software
ARCmail, ARC - Thom Henderson, System Enhancement Associates,
Inc.
Opus-CBCS - Wynn Wagner
BinkleyTerm - Bit Bucket Software
XlaxNode - Scott Samet
XlatList - Thom Henderson, System Enhancement Associates, Inc.
ConfMail, ParseLst - Bob Hartman, Spark Software Inc.,
Sirius - Bob Klahn, Micro Solutions
QuickBBS - Adam Hudson
ARCA, ARCE - Vernon Buerg, Wayne Chin, System Enhancement
Associates, Inc.
PKARC, PKXARC, PKPAK, PKUNPAK - Phil Katz, PKware, Inc.
ZOO - Rahul Dhesi
OOPS - Tom Kashuba
AMAX - Alan Applegate
oMMM Version 1.30 - Page 5
+---+
| | Special Notices
| |====================+
\ \ | | / /
\ +---+ /
REGARDING ARCMAIL
"ARCmail" is a trademark of System Enhancement Associates, Inc.,
for their FidoNet compatible mail processing program of the same
name. oMMM is capable of producing compressed mail of a type
compatible with that of the ARCmail program. We use the term
"ARCmail" within this documentation to avoid the use of other,
longer terms, and to avoid confusion with ZOOmail, another type
of compressed mail. No rights are claimed by use of the term
"ARCmail" within this documentation. All appearances of the term
"ARCmail" herein should be construed to mean "ARCmail compatible"
without any implied reference to the ARCmail program.
REGARDING ZOOMAIL
oMMM now provides ZOOmail compatibility. ZOOmail, like ARCmail,
is compressed FidoNet compatible packets, named in a consistent
and recognized manner. The oMMM implementation of ZOOmail
follows the same naming convention as oMMM uses for ARCmail. The
only difference is that the ZOO compression utility is used to
create the finished product, rather than an ARC-compatible
compression utility.
This ZOOmail functionality is provided for compatibility with
other influential ZOOmail implementations that have been
implemented or are planned. No political statement is implied by
the implementation of ZOOmail in oMMM.
POLITICS
It is the earnest desire of the current developers and
documenters of oMMM to avoid participation as a unit in actions
or choices regarding the oMMM package which are motivated by
network politics. Statements by persons associated with oMMM
development are strictly the opinion of the individual, and may
or may not reflect the opinion of other persons associated with
oMMM development.
REGARDING ARCHIVING PROGRAMS
In recognition of the wide variety of needs, desires and opinions
within FidoNet and compatible networks, oMMM endeavors to provide
the widest possible choice of archiving programs for use in
creating compressed mail. oMMM is capable of using ARCA by V.
Buerg, PKARC/PKPAK (in "compatibility" mode) by P. Katz, and ZOO
by R. Dhesi. No recommendation is made by the developers, and
none should be construed by any statements made herein. ARCmail
and ZOOmail are often referred to by the term "compressed mail."
oMMM Version 1.30 - Page 6
+---+
| | Technorata
| |====================+
\ \ | | / /
\ +---+ /
HOW MAIL IS HANDLED
In order to understand what oMMM is supposed to do, it's
important to have a working knowledge of the concepts involved
with mail handling for Opus-CBCS and BinkleyTerm.
Understanding the concepts is easy if you're new to FidoNet, and
this is your first experience with handling FidoNet mail.
However, if you're a "grizzled veteran" of FidoNet, and have
experience with other FidoNet compatible mailers or BBS packages,
then the following box contains everything you should remember
about the way other programs handle mail:
+-------------------------------------------+
| |
| |
| |
| |
| |
+-------------------------------------------+
In this section, the term "your system" is implied to mean Opus-
CBCS or BinkleyTerm, the two mailer systems that use oMMM at this
writing.
Sending outbound mail with your system is fairly simple. If you
are a complete neophyte, this section is intended to give you an
understanding of the concepts involved. It is suggested reading
even if you think you know all about FidoNet mail handling.
IDEA #1. Mail events are less important than they are with other
mailing methods and systems. With your system, you paint a wide
brush telling the system what to do with 'classes' of remote
systems.
When systems handled mail only at specific times, routing and
times were of great importance. Because more and more systems
can process mail at any time (including yours), the idea of a
schedule become less important. The item of prime importance
with your system is COST. We are going to try and relieve you of
the tedious details of scheduling, and concentrate on doing
things for the least cost. More on this later.
IDEA #2. Another new idea deals with the way that packets are
created.
If you have used other mailer systems, you're probably used to
seeing packets generated several times. With some programs,
oMMM Version 1.30 - Page 7
packets are built every time a mail schedule starts. As a
result, one message may be put into a packet several times.
With your system, packets are built once by an external program
called oMMM. They may be remarked and rerouted once they're
built, but they are physically built only once, and placed in a
special sub-directory called the outbound holding area.
IDEA #3. Your system uses 'Continuous Mail.' If you are already
using a program that supports 'Crash Mail' then you understand a
little of what Continuous Mail does. Continuous Mail differs
from Crash Mail in a couple of areas.
In other mailer systems, you would mark a message as 'Crash'
meaning that you wanted this message to go out NOW. These mailer
programs would shut down human caller access to the BBS and try
ardently to get the message through.
Your system uses Continuous Mail, meaning that this is a message
going to a system that can accept mail at any time of day. Your
system makes no frantic attempts to dial out, rather it will try
and deliver the message between incoming calls.
IDEA #4. The driving forces of outbound traffic are file names!
This is very important to understand, so read carefully.
You'll have a special sub-directory set aside just for packets
(processed outbound messages), ARCmail (or ZOOmail) packets and
other outbound network files. The sub-directory belongs to your
system, which will maintain the directory for you. It's a good
idea not to play with this area unless you know exactly what
you're doing.
As we mentioned before, packets are created only once, and are
placed in your outbound area for holding until they are sent.
Your system differentiates between the various files based
entirely on file names.
oMMM's basic concept is to scan your NetMail message area (for
some systems, this may be done by other software), place new
messages into packets in your outbound area, then scan the
outbound area and rename files according to the oMMM control
file. That's right, one of oMMM's major functions is renaming
files. oMMM also may append a new outbound message onto the end
of an existing packet, or add additional packets to existing
compressed mail packets.
The file names of the packets tell your system how to treat the
different packets. Here's a typical packet name:
00680024.OUT
That says that the packet is for 0068/0024 (in hexadecimal) or
104/36 in more familiar terms. The ".OUT" means it is a Normal
oMMM Version 1.30 - Page 8
packet.
Packet extensions are:
.OUT . . . Normal, meaning that this packet hasn't been
processed by oMMM yet. If left unprocessed,
it will be treated the same as a .DUT packet.
.HUT . . . Hold this packet for pickup by the remote system.
.CUT . . . The other system can receive Continuous Mail.
.DUT . . . Direct, meaning the other system can NOT receive
Continuous Mail.
One nice thing is that you can manually change the file
extensions if you need to, or you can use fancy utilities such as
OOPS and AMAX to do this sort of thing for you. By changing the
file extension, you change the "flavor" of the packet.
The oMMM program knows about these extensions and creates them
based on information you put into the oMMM control file. You'll
have statements like:
NormHold 124/102
Any messages you enter to 124/102 would be turned into a .HUT
packet file, placed in the outbound area, and your system would
hold that packet for 124/102 to call and pickup. oMMM control
file statements are covered in detail later in this document.
Files are also sent through FidoNet. oMMM builds and maintains a
file that tells Opus or BinkleyTerm what files to send (or hold)
for whom. A typical 'file attach' file might be named:
00680024.FLO
This would designate that there is a file waiting to be sent to
0068/0024 (in hexadecimal) or 104/36 in more familiar terms. The
".FLO" says it is a Normal file attach. File attach files are
also called 'flow files' after the .FLO file extension.
Flow file extensions are:
.FLO . . . Normal, meaning that this flow file hasn't
been processed by oMMM yet. If left unprocessed,
it will be treated the same as a .DLO flow file.
.HLO . . . Hold these files for pickup by the remote system.
.CLO . . . The other system can receive Continuous Mail.
.DLO . . . Direct, meaning the other system can NOT receive
Continuous Mail.
A flow file is just a flat ASCII text file. It contains a list
of files that are to be send to (or held for) another system:
#c:\binkley\outbound\0000fc9c.mo1
c:\pascal\notes.doc
oMMM Version 1.30 - Page 9
The '#' prior to a flow file entry says to truncate the file to
zero-length after successfully sending the file to the remote
system. This is normally only employed when sending compressed
mail to the remote. Once the mail is sent, you don't need it
anymore, so the file is truncated.
Files may also be deleted after they are sent by preceding the
file entry in a flow file with a carat (^) sign. This is not
compatible with early versions your system.
The oMMM program will also put messages into archives for you.
Details on how this is done can be found later in this
documentation. The point is that oMMM combines the functionality
of "generating packets" with that of programs like ARCmail.
A SAMPLE MESSAGE, START TO FINISH
So here's a practical example. Say I enter a message to Rod
Lamping at 104/610. I mark the message as KILL/SENT when I enter
it. I also enter the message designating a file to attach to
Rod, named C:\FILE\REQ\PARSELST.ARC.
I then enter a message in an EchoMail conference. My conference
host is Phil Kaiser at 104/904. I hold my mail for his system to
call and pickup.
Among other things, I have two lines in my oMMM control file that
tell my system how to handle mail addressed to Phil and Rod:
NormCM 104/610
OneHold 104/904
'NormCM' tells oMMM to mark the message as Continuous Mail (since
Rod runs a mailer 24 hours a day). 'OneHold' tells oMMM to both
archive the mail to 104/904, and mark it Hold-for-Pickup.
NOTE: Don't worry! You won't have to list each node
individually in your control file. Only systems that
require special handling need to be listed. Other oMMM
control file statements handle broad groups of nodes,
essentially by designating default settings.
First, my EchoMail utilities are run to turn EchoMail messages
into Normal packets, and place them in the outbound area for
processing by oMMM. This may be handled by my system (in the
case of a bare Opus), by a utility that comes with my system (in
the case of QuickBBS) or by other enhanced utilities available
separately (such as ConfMail).
Next, I execute oMMM. It first scans the NetMail message area
(where I entered my message to Rod) and turns new messages there
into Normal packets, and if there are files attached, it creates
Normal flow files. oMMM's second step is to use its control
oMMM Version 1.30 - Page 10
file, and apply the statements in the file against the mail in
the outbound area, renaming or appending outbound files as
needed.
Since I have Rod's board listed as NormCM, oMMM renames the file
extension of the Normal packet and flow file for Rod to .CUT and
.CLO respectively, for Continuous Mail. My system will attempt
to send the message and file to Rod as soon as possible. Since I
have Phil's board listed as OneHold, first oMMM archives the
packets to Phil, then creates a flow file with a file extension
of .HLO for Hold-for-Pickup. My system will wait for Phil's
system to call me (poll), and will only then release the ARCmail
to Phil.
I would then have the following in my outbound area:
00680262.CUT Message to Rod.
00680262.CLO Flow File to Rod. It lists the file I wanted
to send him, C:\FILE\REQ\PARSELST.ARC.
00680388.HLO Flow File to Phil. It lists the ARCmail
file that I'm sending him.
0000FC9C.MO1 Compressed Mail Message to Phil.
More information about the various oMMM control file statements
is given later in this documentation.
THE CONCEPT OF COST
As mentioned earlier, one of the prime considerations with your
system is sending mail for the least cost. Cost is, of course,
determined by the nodelist entry. With a properly compiled
nodelist, local FidoNet nodes have '0' in the cost field for
their nodelist entry (assuming local calls are free of charge).
Other entries have cost fields that realistically reflect the
actual cost of sending mail to a particular node.
In most areas, it is cheapest to send toll calls at night.
Therefore, your system is normally set-up to send such mail only
at night.
The event scheduling facilities built into your system have the
functionality to create events that are 'local only.' As already
mentioned, nodes with a '0' cost field are assumed to be local.
When an event is local only, only zero-cost calls are made. A
local only event should be used whenever it costs the most money
to make toll calls, and removed for events during which toll
calls are cheapest. More about this is in the documentation for
your system. Cost and the limitations on cost that you set for a
given schedule will always override any message marking, i.e.,
Normal, Direct, Continuous Mail.
MORE ON FILE NAMES
As mentioned previously, one of the driving forces behind mail
oMMM Version 1.30 - Page 11
handling for your system is file names. Your system uses the
names to determine what to send to whom, and in conjunction with
your event scheduling, when it should be sent.
There are four types or "flavors" that can be used to describe
various forms of packets or flow files (attaches). We've covered
these concepts already, but here's more detail. Remember, file
names are one of the driving forces of outbound mail!
NORMAL is the default flavor of packets and attaches. oMMM may
build Normal packets and attaches and place them in your outbound
area as it scans your NetMail message area (does not apply to
systems such as QuickBBS). EchoMail utilities such as ConfMail
may also place Normal packets in the outbound area. Packets and
attaches will stay marked as Normal until one of oMMM's statement
affects a particular packet or attach, as described later. If
for some reason a Normal packet or attach does not get remarked
to another flavor, it will be handled in the same manner as a
Direct packet or attach.
DIRECT packets and attaches started life as Normal, and were
remarked as Direct by one of oMMM's control file statements.
Direct packets and attaches are destined for systems that CANNOT
accept Continuous Mail. Such systems include Fido 11w that
functionally cannot accept Continuous Mail. Also included are
any systems that by choice of the system operator are not on-line
24 hours a day. Mail must be sent to these systems during pre-
defined mail hours, such as FidoNet's National Mail Hour at
9:00 UTC (GMT). In the raw FidoNet nodelist, such system are
typically designated with a '#09' flag.
CONTINUOUS MAIL packets and attaches also started life as Normal,
and were remarked as Continuous Mail by one of oMMM's control
file statements. Continuous Mail packets and attaches are
destined for systems that are functionally able to accept
incoming mail at any time. These system include Opus,
BinkleyTerm, Fido 12, SEAdog, D'Bridge, FrontDoor, Dutchie and
others. Continuous Mail is sent to any nodes listed with a '#CM'
flag in the raw nodelist.
HOLD packets and attaches also started life as Normal, and were
remarked as Hold by one of oMMM's control file statements. Hold
packets and attaches are destined for systems that must call your
system to pick-up their mail. Under no circumstances will Hold
packets and attaches be sent by your system. The only way that
they can reach their destination is by having the destination
system call your system directly.
OTHER FILES
Also in your outbound area are three more types of files. The
first type is compressed mail packets. Compressed mail packets
are message packets that have been placed into compressed,
archived form for faster sending and disk space economy.
oMMM Version 1.30 - Page 12
Although any outbound messages may be compressed, it's primarily
employed for EchoMail, which typically involves a significant
message volume. oMMM creates ARCmail packets using the ARCA
program or PKARC, commonly available archiving utilities (see the
section on oMMM's command line for more information). For
ZOOmail, oMMM uses the ZOO utility. Should EchoMail need to be
sent to a system that does not support ARCmail or ZOOmail, then
the outgoing EchoMail would be represented by regular message
packets. This is controlled entirely with oMMM control file
statements.
Compressed mail packets are named in a similar manner to packets
and attaches. The first four digits represent a net number, the
last four represent a node number. But with compressed mail, the
representation is not of the destination address, but the
difference between your address and the destination address. For
example, if you were at 104/36, and had an outbound ARCmail
packet for 104/56, the packet would be named 00000014.???,
because the difference between the net numbers is 0 (the first
four digits) and the difference between the node numbers is 20,
represented in hexadecimal as 14 (the last four digits).
File extensions created and used by oMMM are consistent with
SEA's original ARCmail program. The first two digits of the file
extension are MO, TU, WE, TH, FR, SA and SU, the last digit is a
single number, 0 through 9. Originally, the first two digits of
the extension corresponded to the day of the week the packet was
created. oMMM does not follow this convention exactly; details
about the procedure are given in the section on how to use oMMM.
The second type of file is a call progress entry. This file is
named in the same manner that packets and attaches are, except
that the file extension is .$$? - the last digit being a single
number. This file is used by Opus-CBCS and/or BinkleyTerm to
determine how many times a system has been called, and how
successful the call(s) have been. The last digit of the file
extension indicates how many times a bad connect has occurred
with the destination system. These bad connects are when the
destination system has answered, but session was not established.
In long distance cases, these bad connects are billable calls
(both Opus-CBCS and BinkleyTerm have ways of limiting the number
of bad connects). The call progress file is two bytes long. The
two bytes represent an integer value of the number of call
attempts that have been made. These attempts ended with a busy
signal or no answer status, and are typically not billable calls.
Call progress entries are established, maintained and deleted by
the software (Opus-CBCS or BinkleyTerm). The files can safely be
manually deleted; once the limit of bad connects has been
reached, deleting the call progress file is the only way to make
the software again dial out to the given destination system. In
Opus, this is known as "clearing undialables."
Finally, the third file is an outbound request file. It is named
oMMM Version 1.30 - Page 13
in the same manner that packets and attaches are, except that the
file extension is .REQ. Inside the file is the name of a file to
be requested from the destination system. The file can contain
more than one filename; each filename is shown on a separate
line. These files can be generated manually, but are typically
produced by some sort of utility designed for the purpose. Once
the system has been dialed and the request given, the file is
deleted.
Typically, .REQ files are treated in the same manner as .OUT
files. In other words, an .REQ file would prompt your software
to dial out under the same circumstances as it would for a .OUT
file. If you want the request to made sooner, a null packet or
attach must be created with the desired "flavor" to make the
system dial out sooner (many utilities that build .REQ files also
build this null file). You can also manually poll the
destination system to force the request to be passed.
WHAT OMMM DOES
oMMM has a host of integrated functions. Most of the functions
are controlled by a separate text control file, discussed later,
and/or by command line parameters.
As mentioned previously, the software you use will generally
build .OUT and/or .FLO files and place them in the outbound area.
oMMM may also build these files as it scans your NetMail message
area. Once the .OUT and .FLO files are in place, oMMM changes
the files to implement routing of outbound messages (host
routing, discussed earlier, or other routing arrangements) and to
change the "flavor" of existing files to that which you specify.
Your software will also place packets of EchoMail in the outbound
area; oMMM may use ARCA, PKARC or ZOO to create compressed mail
if you instruct it to do so.
oMMM follows a series of instructions that you give it with a
control file, typically named OMMM.CTL. The commands that can be
used in this file are given later. Of equal importance are the
command line arguments used when oMMM is invoked, which are also
discussed later.
Typically, oMMM is invoked by way of a batch file, the same one
you use to start your system. oMMM should be invoked after
entering a NetMail message, and after EchoMail scanning has been
performed (if you run EchoMail on your system). How you
accomplish the invoking of oMMM is up to you. Refer to your
system's documentation for information on setting-up your batch
file.
When invoked, oMMM first uses the information in a "pre-
processing" control file, if any, and applies the information
against the files in your outbound area. Next, oMMM scans your
NetMail (Matrix) message area as given on the command line. New
messages are packed into .OUT files and placed into the outbound
oMMM Version 1.30 - Page 14
area, and the "sent" flag of the message is set (so oMMM won't
send it again). Note that if the Kill/Sent flag of the message
is set, the message will be deleted once oMMM creates a packet
and/or attach for the message. If the message has the file
attach flag set, oMMM will build a .FLO attach file, pointing to
the file that you specified when the message was entered. If the
message has the file request flag set, oMMM will build a .REQ
file containing the name of the file you specified when you
entered the message.
NOTE: Message "flags" should be explained more thoroughly in the
documentation for the program you use for entering your messages,
i.e., Opus, Sirius, etc.
Finally, oMMM uses the regular control file, and applies the
information against the files in your outbound area. This main
control file contains routing information and instructions for
oMMM to process your mail correctly.
Based on information you place in the control file, oMMM is
capable of archiving mail, changing mail from one flavor to
another (i.e., Continuous to Normal, Normal to Hold, etc.), host
routing .OUT files, etc. oMMM can mark particular packets or
attaches as "leave" meaning that your system will completely
ignore their presence. Of course, oMMM is capable of reversing
the "leave" marking as well.
One of the most useful features of oMMM is the ability to make it
use some control file commands at one time of the day, and
another set of control file commands at another time of day.
This is the schedule feature of oMMM, and shouldn't be confused
with the scheduling of events on your system (although they work
in conjunction with each other).
You communicate the schedule oMMM is supposed to use at the oMMM
command line. Therefore, you may wish to invoke oMMM with
different command lines at different times, something that can be
accomplished by using the scheduling capabilities of your
software. Examples of this confusing concept are given in the
examples section.
oMMM Version 1.30 - Page 15
+---+
| | How To
| |====================+
\ \ | | / /
\ +---+ /
MAKING IT MASH
So how do you make oMMM do its thing? First is the control file.
Typically, a pre-processing file (as mentioned above) is NOT
used. You'll be able to judge this for yourself after using oMMM
and analyzing your own situation. The control file commands that
are about to be described apply to both the pre-processing and
main control files, however.
The only difference between the pre-processing control file and
the primary control file is when the information is used and
applied to your outbound mail. Remember, when oMMM is invoked,
it first uses and applies the information in the pre-processing
control file, THEN it scans your NetMail message area, THEN it
uses and applies the information in the primary control file.
The control file information is used and applied in the order it
appears within the file. The control file is standard ASCII
text, one instruction per line. You can edit or create the file
with any common text editor, such as DOS' own EDLIN command.
If you are planning on having oMMM create ARCmail, then you must
have ARCA or PKARC in the current directory, or on the DOS path
(which you use depends on your command line; refer to the section
"oMMM Command Line Parameters" for information). If you will be
having oMMM create ZOOmail, the ZOO program MUST be on the DOS
path.
CONTROL FILE PARAMETERS
The parameters described in this section apply only to oMMM
Version 1.10 or higher. Very early oMMM versions used a
different set of parameters. oMMM 1.30 contains some limited
changes from previous versions. If you're reading this
documentation, one assumes that you also have a current version
of oMMM at hand.
There are several "global" designators available to you with
oMMM. A global is used instead of explicit references to a
specific group of systems. Globals available are:
WORLD (also possible is "ALL")
The word "WORLD" means roughly "all systems."
"104/WORLD" for example means "all systems in net 104."
This should be used with care to avoid undesired
results.
oMMM Version 1.30 - Page 16
NET???
Equivalent to the "???/WORLD" statement. If you used
"NET104" for example, it would mean "all systems in net
104."
OURNET
Means "all nodes in my net." If you are located in net
128, for example, "OURNET" would mean "all systems in
net 128."
OTHERS
Means "all nodes NOT in my net." If you are located in
net 132, for example, "OTHERS" would mean "all systems
NOT in net 132."
Now for the control file statements.
Below, "syntax" shows the proper usage of the command. "Example"
shows a sample control file entry. "Effect" shows the names of
the files in your outbound area that are affected, and how they
are affected. The second "example" shows how a typical entry
would be changed.
LEAVE RELATED COMMANDS
Leave
Mark packets or attaches addressed to node(s) given in
<destination(s)...> as "do not send." This will cause
your system to COMPLETELY IGNORE this mail in ANY
situation.
SYNTAX: Leave <destination(s)...>
EXAMPLE: Leave 104/36 112/101
EFFECT: xxxxyyyy.?UT to xxxxyyyy.N?T
xxxxyyyy.?LO to xxxxyyyy.N?O
EXAMPLE: 00680024.CUT to 00680024.NCT
00700065.FLO to 00700065.NFO
Send
Un-mark all packets or attaches addressed to node(s)
given in <destination(s)...> that have previously been
marked "do not send" (with the 'Leave' statement) so
oMMM Version 1.30 - Page 17
that the system can once again be aware of their
presence.
SYNTAX: Send <destination(s)...>
EXAMPLE: Send 104/36 112/101
EFFECT: xxxxyyyy.N?T to xxxxyyyy.?UT
xxxxyyyy.N?O to xxxxyyyy.?LO
EXAMPLE: 00680024.NCT to 00680024.CUT
00700065.NFO to 00700065.FLO
DoCM
Un-mark Continuous Mail packets or attaches addressed
to node(s) given in <destination(s)...> that have
previously been marked "do not send" (with the 'Leave'
statement) so that the system can once again be aware
of their presence. Only Continuous Mail packets and/or
attaches are affected; all others are left untouched by
this statement.
SYNTAX: DoCM <destination(s)...>
EXAMPLE: DoCM 104/36
EFFECT: xxxxyyyy.NCT to xxxxyyyy.CUT
xxxxyyyy.NCO to xxxxyyyy.CLO
EXAMPLE: 00680024.NCT to 00680024.CUT
GENERAL COMMANDS
Poll
This creates a dummy .FLO (normal attach) file for the
system(s) given in <destination(s)...> if there are no
non-Hold packets or attaches already addressed to the
given system(s).
If there are already Normal, Direct or Continuous Mail
packets or attaches addressed to a given system, then
no .FLO file will be created ("hold for pick-up" mail
does not affect this command).
SYNTAX: Poll <destination(s)...>
EXAMPLE: Poll 104/36
oMMM Version 1.30 - Page 18
EFFECT: If no xxxxyyyy.[F/C/D]LO or
xxxyyyy.[O/C/D]UT file,
then create xxxxyyyy.FLO
EXAMPLE: If no 00680024.FLO/.CLO/.DLO or
00680024.OUT/.CUT/.DUT file,
then create 00680024.FLO
HostRoute
Host route any remaining Normal packets (.OUT files).
Any .OUT files that have not already been affected by
an oMMM control file command will be re-addressed
(routed) to the host for the destination system's
network. Normally, this is the LAST STATEMENT in your
oMMM control file (except for 'Poll' statements, they
should be VERY LAST, if used).
SYNTAX: HostRoute
EXAMPLE: HostRoute
EFFECT: xxxxyyyy.OUT to xxxx0000.OUT
EXAMPLE: 00680024.OUT to 00680000.OUT
Password
Encrypts ARCmail packets to the system given in
<destination> with the password given in <password>
during the archiving process. The destination system
must not only support ARCmail, but must have their
system set-up to un-arc the ARCmail packets with the
same password you use.
Has no effect on mail other than ARCmail.
SYNTAX: PASSWORD <destination> <password>
EXAMPLE: PASSWORD 132/101 mypass
Sched
This statement starts a schedule as named by <tag>.
All oMMM statements between the 'Sched' statement and
the next 'Sched' statement will be executed only if the
tag matches the one given on the oMMM command line
(refer to the section "oMMM Command Line Parameters").
The schedule tag is a single letter that can be in
upper or lower case.
Statements prior to the FIRST 'Sched' statement are
executed with every invocation of oMMM, regardless of
oMMM Version 1.30 - Page 19
the schedule tag.
SYNTAX: SCHED <tag>
EXAMPLE: SCHED A
MAIL ROUTING - DIRECT FLAVOR COMMANDS
ARCDirect
Takes .OUT packets addressed to nodes in the
<routelist...> and archives them into an ARCmail
packet, then builds a Direct attach file addressed the
<destination> system. Such usage allows for routing of
messages through another system. If no <routelist...>
is given, mail to the destination system only will be
archived.
The destination system must be capable of processing
ARCmail.
SYNTAX: ARCDirect <destination> [<routelist...>]
EXAMPLE: ARCDirect 124/0 124/WORLD
EFFECT: xxxxyyyy.OUT to xxxxyyyy.DLO
with ARCmail packet also created
EXAMPLE: 007C0058.OUT \
007C000F.OUT > to 007C0000.DLO
007C001D.OUT /
with ARCmail packet also created
OneDirect
Takes .OUT packets addressed to nodes in the
<destination(s)...> list and archives them into ARCmail
packets, then builds separate Direct attach files
addressed to the given system(s).
This statement is like 'ARCDirect,' except that NO
routing takes place, and all nodes listed have the
packets archived into ARCmail INDIVIDUALLY.
SYNTAX: OneDirect <destination(s)...>
EXAMPLE: OneDirect 104/36 132/101
EFFECT: xxxxyyyy.OUT to xxxxyyyy.DLO
with ARCmail packet(s) also created
oMMM Version 1.30 - Page 20
EXAMPLE: 00680024.OUT to 00680024.DLO
00840065.OUT to 00840065.DLO
with ARCmail packet(s) also created
UnDirect
Any Direct packets or attaches addressed to the node(s)
given in the <destination(s)...> are re-marked Normal.
SYNTAX: UnDirect <destination(s)...>
EXAMPLE: UnDirect 104/36 132/101
EFFECT: xxxxyyyy.DUT to xxxxyyyy.OUT
xxxxyyyy.DLO to xxxxyyyy.FLO
EXAMPLE: 00680024.DUT to 00680024.OUT
00840065.DLO to 00840065.FLO
NormDirect
Any Normal packets or attaches addressed to the node(s)
given in the <destination(s)...> are re-marked as
Direct. NO archiving is performed.
SYNTAX: NormDirect <destination(s)...>
EXAMPLE: NormDirect 104/36 132/101
EFFECT: xxxxyyyy.OUT to xxxxyyyy.DUT
xxxxyyyy.FLO to xxxxyyyy.DLO
EXAMPLE: 00680024.OUT to 00680024.DUT
00840065.FLO to 00840065.DLO
MAIL ROUTING - HOLD FLAVOR COMMANDS
ARCHold
Takes .OUT packets addressed to nodes in the
<routelist...> and archives them into an ARCmail
packet, then builds a Hold attach file addressed the
<destination> system. Such usage allows for routing of
messages through another system. If no <routelist...>
is given, mail to the destination system only will be
archived.
The destination system must be capable of processing
ARCmail.
oMMM Version 1.30 - Page 21
SYNTAX: ARCHold <destination> [<routelist...>]
EXAMPLE: ARCHold 124/0 124/WORLD
EFFECT: xxxxyyyy.OUT to xxxxyyyy.HLO
with ARCmail packet also created
EXAMPLE: 007C0058.OUT \
007C000F.OUT > to 007C0000.HLO
007C001D.OUT /
with ARCmail packet also created
OneHold
Takes .OUT packets addressed to nodes in the
<destination(s)...> list and archives them into ARCmail
packets, then builds separate Hold attach files
addressed to the given system(s).
This statement is like 'ARCHold,' except that NO
routing takes place, and all nodes listed have the
packets archived into ARCmail INDIVIDUALLY.
SYNTAX: OneHold <destination(s)...>
EXAMPLE: OneHold 104/36 132/101
EFFECT: xxxxyyyy.OUT to xxxxyyyy.HLO
with ARCmail packet(s) also created
EXAMPLE: 00680024.OUT to 00680024.HLO
00840065.OUT to 00840065.HLO
with ARCmail packet(s) also created
UnHold
Any Hold packets or attaches addressed to the node(s)
given in the <destination(s)...> are re-marked Normal.
SYNTAX: UnHold <destination(s)...>
EXAMPLE: UnHold 104/36 132/101
EFFECT: xxxxyyyy.HUT to xxxxyyyy.OUT
xxxxyyyy.HLO to xxxxyyyy.FLO
EXAMPLE: 00680024.HUT to 00680024.OUT
00840065.HLO to 00840065.FLO
NormHold
Any Normal packets or attaches addressed to the node(s)
given in the <destination(s)...> are re-marked as Hold.
oMMM Version 1.30 - Page 22
NO archiving is performed.
SYNTAX: NormHold <destination(s)...>
EXAMPLE: NormHold 104/36 132/101
EFFECT: xxxxyyyy.OUT to xxxxyyyy.HUT
xxxxyyyy.FLO to xxxxyyyy.HLO
EXAMPLE: 00680024.OUT to 00680024.HUT
00840065.FLO to 00840065.HLO
MAIL ROUTING - CONTINUOUS FLAVOR COMMANDS
ARCCM
Takes .OUT packets addressed to nodes in the
<routelist...> and archives them into an ARCmail
packet, then builds a Continuous Mail attach file
addressed the <destination> system. Such usage allows
for routing of messages through another system. If no
<routelist...> is given, mail to the destination system
only will be archived.
The destination system must be capable of processing
ARCmail.
SYNTAX: ARCCM <destination> [<routelist...>]
EXAMPLE: ARCCM 124/0 124/WORLD
EFFECT: xxxxyyyy.OUT to xxxxyyyy.CLO
with ARCmail packet also created
EXAMPLE: 007C0058.OUT \
007C000F.OUT > to 007C0000.CLO
007C001D.OUT /
with ARCmail packet also created
OneCM
Takes .OUT packets addressed to nodes in the
<destination(s)...> list and archives them into ARCmail
packets, then builds separate Continuous Mail attach
files addressed to the given system(s).
This statement is like 'ARCCM,' except that NO routing
takes place, and all nodes listed have the packets
archived into ARCmail INDIVIDUALLY.
oMMM Version 1.30 - Page 23
SYNTAX: OneCM <destination(s)...>
EXAMPLE: OneCM 104/36 132/101
EFFECT: xxxxyyyy.OUT to xxxxyyyy.CLO
with ARCmail packet(s) also created
EXAMPLE: 00680024.OUT to 00680024.CLO
00840065.OUT to 00840065.CLO
with ARCmail packet(s) also created
UnCM
Any Continuous Mail packets or attaches addressed to
the node(s) given in the <destination(s)...> are re-
marked Normal.
SYNTAX: UnCM <destination(s)...>
EXAMPLE: UnCM 104/36 132/101
EFFECT: xxxxyyyy.CUT to xxxxyyyy.OUT
xxxxyyyy.CLO to xxxxyyyy.FLO
EXAMPLE: 00680024.CUT to 00680024.OUT
00840065.CLO to 00840065.FLO
NormCM
Any Normal packets or attaches addressed to the node(s)
given in the <destination(s)...> are re-marked as
Continuous Mail. NO archiving is performed.
SYNTAX: NormCM <destination(s)...>
EXAMPLE: NormCM 104/36 132/101
EFFECT: xxxxyyyy.OUT to xxxxyyyy.CUT
xxxxyyyy.FLO to xxxxyyyy.CLO
EXAMPLE: 00680024.OUT to 00680024.CUT
00840065.FLO to 00840065.CLO
oMMM Version 1.30 - Page 24
ZOOMAIL COMMAND DIFFERENCES
oMMM now supports ZOOmail. This is compressed mail named in the
same manner as ARCmail, but the compression is performed with the
ZOO utility by Rahul Dhesi, rather than an ARC-compatible
compression utility.
To cause oMMM to create ZOOmail rather than ARCmail, certain
commands must be used. Rather than list and describe each
command separately, the following chart shows the oMMM ARCmail
command, then it's ZOOmail counterpart.
ARCmail Command ZOOmail Command
--------------- ---------------
ARCHold ZOOHold
ARCDirect ZOODirect
ARCCM ZOOCM
OneHold Z1Hold
OneDirect Z1Direct
OneCM Z1CM
ADD COMMAND MODIFIERS
The Add modifier is a mechanism design ed to provide a measure of
control over the number of call (actually, successful net
sessions) made to a given node. It is used ONLY with compressed
mail statements.
Consider the case of a net level EchoMail hub, using AT&T Reach
Out America (ROA) hours for most of its work. This node polls
his regional hub twice a night, but otherwise has no specific
call window to his regional hub. After successfully completing
the first poll (or before), his downstream nodes both pick-up and
drop-off mail. If the nbet hub is doing immediate mail
processing, it will try to call the regional hub again (and
again).
In the old oMMM environment, there were only two paths to deal
with this - pay the piper by making many short calls, or have a
tightly regulated schedule with yout upstream node(s). Very
often, neither of these options is very attractive.
The Add modifier attempts to address this situation. Let's
assume the net level hub is 321/109 and the regional 132/101.
During ROA timne, 321/109 would use:
ZooAddHold 132/101
in his events. At specific times (perhaps 22:00 and ZMH+1),
321/109 would do the following:
UnHold 132/101
Poll 132/101
oMMM Version 1.30 - Page 25
Under ideal conditions, this will result in 321/109 making two
successful calls to 132/101.
Note that the execution of specific oMMM statements (or groups of
them) is handled by the 'Sched' statement discussed previously.
Here's how it actually works. If you are in an Add type
compressed mail statement, and compressed mail already exists,
any new mail is simply added to the compressed mail file, and
NOTHING is done to the attach (flow) file. If no compressed mail
exists, a new compressed mail file is created, and an attach file
of the flavor specified in the statement is created also.
ARCAddHold would result in an .HLO file, ARCAddCM would result in
a .CLO file, etc.
In order to use this successfully, one must be VERY careful not
to otherwise alter the flavor of nodes so handled in the control
file (whether main or prescan), or by any other external process.
This means careful thought must be given to the use of ALL, WORLD
and other such wildcard global designators, and ANY statements
referencing nodes so handled, whether they are compressed mail
related or not.
The following tables lists oMMM statements which may be modified
by 'Add' and what the modified statements are:
oMMM Statement Modified Statement
-------------- ------------------
ARCHold ARCAddHold
ARCDirect ARCAddDirect
ARCCM ARCAddCM
OneHold OneAddHold
OneDirect OneAddDirect
OneCM OneAddCM
ZOOHold ZOOAddHold
ZOODirect ZOOAddDirect
ZOOCM ZOOAddCM
Z1Hold Z1AddHold
Z1Direct Z1AddDirect
Z1CM Z1AddCM
OMMM COMMAND LINE OPTIONS
oMMM is always invoked with a set of command line options. The
options tell oMMM various things about your system.
If you use 'Sched' statement in your control file, then you tell
oMMM what schedule it is by way of the command line. As
mentioned earlier, it's up to you to configure your system in
such a way as oMMM is called, at the proper times, with the
desired command line.
oMMM Version 1.30 - Page 26
This is normally accomplished by programming your system to exit
to your start-up batch file with various ERRORLEVEL values at the
times you designate. The batch file in turn uses the ERRORLEVEL
value to decide what to run and how to run it. Samples are shown
in the sample section.
oMMM can also use an optional OMMM.CFG configuration file, which
will be discussed later. Command line options which may be
included in OMMM.CFG instead of on the command line are marked
with an asterisk (*).
oMMM uses a command line in the following format (oMMM must be
have all of the command line options on one continuous line; the
line is broken here to fit on the page):
oMMM -c<filename> -h<path> -i<filename> -m<path> [-p<filename>]
[-s<tag>] [-z<zone>] [-a] [-f] [-n] [-o] [-q] [-g]
* -c This designates the filename of the primary oMMM
control file. This file contains the processing
commands outlined in the previous section. A complete
path may be given in addition to the filename. This
parameter is required.
EXAMPLE EXCERPT: -cC:\OPUS\OMMM.CTL
* -h This designates the path to the outbound mail holding
area. This parameter is required.
EXAMPLE EXCERPT: -hC:\OPUS\OUTBOUND
* -i This designates the filename of the Opus style
parameter file to be used by oMMM. Opus creates this
file. For BinkleyTerm systems, the BTCTL utility
creates this file. This parameter is required.
EXAMPLE EXCERPT: -iC:\OPUS\BINKLEY.PRM
* -m This designates the path to your NetMail (Matrix)
message area. This area contains Fido compatible
messages. This parameter is required.
EXAMPLE EXCERPT: -mC:\MSG\NET
* -p This designates the filename of the pre-processing oMMM
control file. This file contains the processing
commands outlined in the previous section. This
control file varies from the primary control file in
that it is used first (refer to the section "What oMMM
Does" for information). This parameter is OPTIONAL.
EXAMPLE EXCERPT: -pC:\OPUS\OMMM_ALT.CTL
-s This tells oMMM what schedule to execute. The tag
oMMM Version 1.30 - Page 27
given corresponds to the tag(s) given with the 'Sched'
statement in the control file. This parameter is
OPTIONAL.
EXAMPLE EXCERPT: -sA
* -a Instructs oMMM to use PKARC for archiving of ARCmail
packets instead of ARCA (default). oMMM must be able
to find the archiving program (regardless of "-a"
setting) in the current directory or by a previously
set DOS path. If "-a" is used, oMMM will use PKARC's
"-oct" command line switch to force compatibility with
older archiving methods (occurs automatically). NOTE!
If you use PKPAK, you must rename it to PKARC, or have
a renamed copy available.
* -z This tells oMMM your zone number. If used, this will
cause oMMM to operate in zone smart mode, and messages
to other zones will be placed in their own outbound
area, as expected by BinkleyTerm and Opus 1.1x. Users
of Opus 1.0x should NOT use this switch.
EXAMPLE EXCERPT: -z1
-f This tells oMMM to un-mark all packets and attaches
that have been marked as "no-send" (by the 'Leave'
statement of the control file) so that the system knows
of their existence once again. This is a global
version of the 'Send' control file statement.
* -n This tells oMMM not to forward messages that are "in-
transit." These are messages addressed to systems
other than your own that have been routed to you from
other nodes.
* -o Tells oMMM to name ARCmail using file extensions of
.MO? only (like older oMMM versions). Without the "-o"
switch, oMMM uses file extensions of.MO1, .MO2, ...
.SU9, .SU0, in sequence, then wraps around to .MO1
again. This follows the style used by ConfMail and
other EchoMail utilities, except that the file
extension does not necessarily correspond to the day of
the week.
-q Tells oMMM to operate in "quiet mode," producing
marginally faster processing throughput.
* -g Tells oMMM to gate route inter-zone messages. This
means that messages to other zone will be routed
through established zone gateways within your own zone.
oMMM Version 1.30 - Page 28
OMMM.CFG CONFIGURATION FILE
Some of the command line options, as previously mentioned, can be
stored in a stand-alone, raw text configuration file. This file
can be created or edited with any standard text editor, such as
DOS' own EDLIN command. A sample OMMM.CFG configuration file
comes with the oMMM distribution package.
The sample file includes all possible statements that may be
included in the file, including proper syntax. Refer to that
file for information.
oMMM Version 1.30 - Page 29
+---+
| | Examples
| |====================+
\ \ | | / /
\ +---+ /
SAMPLE OMMM CONTROL FILE FOR BINKLEYTERM AND OPUS 1.1x
BinkleyTerm and Opus 1.1x are "continuous mail" smart. Nodes
marked "#CM" in the nodelist are flagged as such in the compiled
nodelist files that these systems use. Nodelist versions that
support this information are: Opus Version 6, QuickBBS 2.00, and
TBBS w/ the special BinkleyTerm adjunct nodelist file.
If you use any of the three previously mentioned nodelist formats
with your system, you can follow this guide for creating a basic
control file:
Compress to EchoMail Hub(s)
|
|
v
Continuous to OurNet
|
|
v
HostRoute All Others
For example, a sample for node 104/36 might look like this:
OneCM 104/610 104/45
NormCM OurNet
HostRoute
SAMPLE OMMM CONTROL FILE FOR OPUS 1.0x
Older versions of Opus use the Opus Version 5 nodelist. This
nodelist does not offer complete information to the system, so a
slightly longer oMMM control file is needed. Like this:
Compress to EchoMail Hub(s)
|
|
v
Continuous to Crashable OurNet Nodes
|
|
v
Direct to All Other OurNet Nodes
|
|
v
HostRoute All Others
oMMM Version 1.30 - Page 30
The control file for 104/36 might look like this:
OneCM 104/610 104/45
NormCM 104/19 104/56 104/604 104/44 104/43 132/101 141/491
NormDirect OurNet
HostRoute
oMMM Version 1.30 - Page 31
+---+
| | Multi-Zone Operation
| |====================+
\ \ | | / /
\ +---+ /
GENERAL INFORMATION
BinkleyTerm Version 2.00 and above, and (at some point before
release) Opus 1.10, both implement support for direct NetMail to
and from other zones, using discrete outbound areas. oMMM 1.30
is capable of storing messages in these discrete outbound areas,
but since Opus 1.03b and below, and, as of this date, Opus 1.10
test versions, are not capable of processing these outbound
areas, this oMMM feature is disabled by default and must be
enabled using a command line switch.
To enable multiple zone support in oMMM, add the -z<zone> switch
to the oMMM command line. For example, if your address is
2:507/1, there should be a -z2 on the command line. When oMMM
sees this switch, it makes several significant changes in its
processing:
1) All addressing becomes zone-sensitive in the control
file. You may include zone information in addresses where
necessary. When zone information is omitted, the zone
number specified on the command line will be used as the
default.
2) All messages in the NetMail area that are candidates for
mashing will be scanned for the IFNA "extended addressing"
field associated with inter-zone mail.
3) All mail destined to your zone will be stored in the
"default" outbound directory.
4) All mail destined to other zones, and which contain the
IFNA "extended addressing" field previously mentioned, will
be stored in a discrete directory for those zones. Using
2:507/1 as a sample address again, and assuming
C:\OPUS\OUTBOUND as the "default" outbound area, oMMM will
store mail for Zone 1 in the directory C:\OPUS\OUTBOUND.001
(yes, that's right, directory names MAY have extensions!)
and mail for Zone 3 in C:\OPUS\OUTBOUND.003.
5) All mail destined to other zones that DOES NOT contain
the IFNA "extended addressing" field will NOT be placed into
the discrete outbound areas mentioned previously...such mail
will be placed in the primary, default outbound area.
It is possible to support up to 4095 zones using this method, as
the zone number is encoded in hexadecimal. For example, Zone 99
would use extension .063.