home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
DP Tool Club 17
/
CD_ASCQ_17_101194.iso
/
vrac
/
amd202b.zip
/
AMAIL.DOC
next >
Wrap
Text File
|
1994-08-02
|
92KB
|
2,060 lines
* * * * * * * * * * *
Alexi/Mail, version 2.02a
July 27th, 1994
by Chad Nelson
1:109/536 @ Fidonet
Copyright 1992-1994 by Chad Nelson
* * * * * * * * * * *
NOTE: If you are upgrading from FreeMail, please check the FREEMAIL.DIF file
(included in the archive) for important changes to the configuration and
functionality. It should make the transition nearly painless.
NOTE: Please use the outline at the end of this file as an index. It will give
you a good idea where to look for various information. Common problems and
their solutions appear in the Troubleshooting section.
Alexi/Mail (abbreviated A/Mail) allows Sysops and users of compatable
BBS systems to communicate with worldwide BBS networks based on Fidonet (tm)
technology. It can import Fidonet-style packets to your message bases
("tossing") and export messages written on your system to other BBSs
("scanning"). It is the successor of the FreeMail program, and will contain
all its features and more.
Unlike most tosser/scanner packages, which support one or two common
message base styles, Alexi/Mail supports several:
Hudson format, used in QuickBBS, RemoteAccess 1.x, SuperBBS, TAG BBS,
some versions of ROBO-BBS/ROBO-FX, and others;
The multiple-Hudson-base format used by TAG BBS;
The *.MSG format, also known as Fido/Opus and Star-Dot-Message (SDM),
used by FIDO, OPUS, Maximus, TAG BBS, and many others;
The Spitfire format, used by Spitfire BBS and (probably) TriBBS;
and the Synchronet v1 BBS format.
Other formats, including Squish, JAM, GoldBase, and SynchroNet v2,
are planned for future versions.
Alexi/Mail is also compatable with all the major mailer programs
("front ends"), including BinkleyTerm, Portal of Power, FrontDoor, Intermail,
and d'Bridge. It can be used without problems on multitasking systems or LANs,
and with some mailers (Bink, PoP, Intermail, etc), it can process mail in the
background while the mailer/BBS is online with another caller, without
affecting the session. It is one of the very few tosser programs capable of
extracting 100% of the undamaged messages from a badly grunged packet.
Alexi/Mail can handle the duties of nearly any size system, from a
point carrying half a dozen echos to the North American Fidonet backbone. The
only limitation is your system's free memory (in the OS/2 version, with the
virtual memory available, there is no limit!). It has full message routing
capabilities, and supports up to 64 Fidonet-style addresses for those who use
multiple networks. It fully supports 2D (also known as pointnet or fakenet)
addressing, full 4D point addressing, and zones up to 65500. It contains
dozens of features to handle just about anything you want, and is still
growing.
Alexi/Mail is distributed under the "shareware" concept. You have 21
days to evaluate the program; if you continue to use it, you are expected to
pay for it (see the COST section later in this file, or the included
REGISTER.TXT file, for details); otherwise, you must stop using it. Once you
have registered, you will be able to use all the features of Alexi/Mail, in
this and all future versions, and can run the utility programs soon to be
available. These include:
MSGPURGE: A program that will purge, pack, link, and renumber your
message bases (whatever features are applicable to the type of message
base you use) to your specifications.
MSGFIX: Will diagnose and fix many message base problems.
SCHED: Allows flavoring, file-attaching and requesting, and polling
from the command line, or by a pre-configured SCHEDule. Perfect for
batch file manipulations.
Other utilities, including a TICK-file processor, menued area manager,
and menued outbound manager, are planned for the future.
I recommend using the outline at the end of this file to locate the
information you need.
SETUP AND CONFIGURATION
=======================
Alexi/Mail uses two text files for configuration, which it assumes are
in the directory it is run from: an AMAIL.CFG file containing information
abour your system and the options you've selected; and an AREAS.BBS file
containing information about your echomail and netmail areas. Either or both
of these files can have different names or be in different directories, so
long as you tell A/Mail how to find them (see the sections titled THE
CONFIGURATION FILE and THE AREAFILE for details).
In the examples shown, the name AMAIL is used for the program. If
you're using the OS/2 version, use AMAIL2 instead.
THE COMMAND LINE
----------------
There are several "switches" possible on the command line. You will
need one or more of them to tell the program what to do. All switches must
begin with a dash ('-') or forward-slash ('/'); the examples use a dash.
-ET
ECHO TOSS: This is the main tossing command. It tells A/Mail to unpack
all incoming packets, distribute and toss echomail messages according
to the instructions in the areafile, bundle up the outgoing *.PKT
files, and instruct the mailer to send these mail bundles to the
proper addresses. Netmail messages are a special case; they will be
unpacked by this command, but where they end up depends on the -NT
option, described below.
-NT
NET TOSS: Despite its similarity to -ET, the options have little in
common. The -NT option tells A/Mail to take any *.MSG netmail messages
addressed to your system and toss them into your Hudson or Spitfire
format netmail area, if applicable. If the STOPSIGN option is used
(see STOPSIGN in THE CONFIGURATION FILE for details), using -NT will
allow the stopped messages to continue on their journey. Note that
using -ET and -NT on the same command line will cause your netmail to
skip the *.MSG phase, and defeat the STOPSIGN function. If you use
multiple netmail areas (*.MSG for your mailer and Spitfire for the
BBS, for instance), you must use this option to have your mail sent
directly to the BBS.
-ES
ECHO SCAN: Scans your message base for unsent echomail messages, and
distributes them according to the instructions in your areafile.
-NS
NET SCAN: Does the same thing as the -ES option, but for your netmail
area(s) instead of echomail.
-ES###, -NS###
FAST ECHO/NET SCAN (Spitfire format only): By adding a number to the
-ES or -NS commands, you can instruct A/Mail to scan only the last
X-number of messages in each message area. For instance, using -ES250,
A/Mail would only look at the last 250 messages in each echomail area.
This can speed scanning, especially on large systems, but may miss
some unsent mail if it is more than the specified number of messages
from the end. It is recommended that you use -ES/-NS without a number
at least once a day to catch these.
-ALL
SCAN ALL (Hudson and *.MSG formats only): This activates the SCANALL
option (see THE CONFIGURATION FILE section for details) for this run
only. To use this in every run, put SCANALL in the config file.
-NOTIFY (<address>...)
(Available only when Area Manager is used) This switch tells A/Mail's
Area Manager to send a NOTIFY message to all or specific downlinks,
telling them what areas they're currently receiving from each of your
addresses. If you specify one or more addresses after -NOTIFY, only
these addresses will be sent messages (*if* they are defined in your
config file); otherwise, all your downlinks will be notified, except
those you have specified should not be (see NONOTIFY).
-BAD
This switch tells A/Mail to scan the bad-message directory (which must
be defined) for messages that were previously considered bad, but now
(perhaps because you have changed your configuration file) can be
tossed. If it finds any, it will toss them or tell you why it can't.
-X
This is a special switch that disables the full-screen interface,
causing A/Mail to use standard I/O calls instead. You can use this to
redirect the output to a different file.
THE CONFIGURATION FILE
----------------------
Although Alexi/Mail is based on FreeMail, there are differences. Many
of the keywords are the same, and have the same usage; some have changed
drastically; others have disappeared altogether. Please check this file (and
possibly the FREEMAIL.DIF file included in the archive) if you have questions
about whether a FreeMail option still works in A/Mail.
The configuration file is assumed to be AMAIL.CFG, in the current
directory when the program is run. If you wish to relocate it or use a
different name, you must specify the filename as the *first* option on the
command line, before any switches:
AMAIL D:\NEWAMAIL.CFG -ET -NT
Note that lines in the config file must not exceed 500 characters in
length, and anything after a semicolon will be ignored as a comment. All
options and keywords are shown CAPITALIZED, but A/Mail will recognise them in
any case or mixture of cases. Parameters shown in lower case should be
replaced with the text they describe; for instance, <sysop> should be replaced
by the Sysop's name.
In this section, the following notation is used:
Required parameters are shown in <angle brackets>.
Optional parameters use (parentheses).
When only one of a list of options is allowed, the options are
shown in [square brackets], separated | by | vertical | bars.
More than one of a given parameter is allowed when the elipses
(...) are shown after it.
Note that Alexi/Mail is not yet finished. Some options available in
FreeMail are not yet available here. All features documented in this file
should work.
Required
--------
The items listed in this section are required for all systems.
SYSOP <sysop's board name>
(Required) Netmail for the Sysop will be addressed to this person.
This should be the name you use on your BBS.
NOTE for Spitfire Sysops: If you have configured your board to use a
handle such as "Sysop" for the Sysop's alias, use that here and use
your real name in the SYSOPCVT field (see SYSOPCVT, below). A
conversion between the name entered here, and the one in SYSOPCVT,
will be made on all outgoing and incoming mail in the TO: and FROM:
fields. If you are using a handle other than "Sysop," put the handle
here. Pay attention to capitalization; it must be the same here and in
Spitfire, or Spitfire will not find it when scanning for messages
addressed to you.
SYSTEM <origin line>
(Required) Alexi/Mail will append this to any message leaving your
system that does not have an origin line already on it. This should
normally contain your system's name, location, and (optional)
telephone number, but can contain anything. You should NOT include
your network address here -- A/Mail adds that itself. If you need
multiple origin lines, see the /ORG option in THE AREAFILE section.
ADDRESS <zone:net/node(.point)>...
ADDRESS <zone:net/node.pointnet/point>...
(Required) At least one ADDRESS statement is required, up to 64 are
fully supported. The first format is standard FidoNet 3D or 4D
addressing. The second is a nonstandard format which supports the use
of multiple "pointnets," a kludge to let older, non-point-aware
software work with point systems. A/Mail will work with or without a
pointnet. Note that the zone is REQUIRED on the first address, and
subsequent addresses will default to that zone number if another is
not specified. Also note, multiple addresses should be listed in the
same order here as in your mailer and other software. See also the
HIDDEN option.
INBOUND <incoming files directory>
OUTBOUND <outgoing files directory>
(Required) The directories must already exist; A/Mail will not create
them. These are the directories your mailer uses to store incoming
mail, and mail bundles waiting to be sent out. NOTE: A/Mail must *not*
share FrontDoor's PACKET directory! Make certain the OUTBOUND and
PACKET directories are *not* the same!
ARCDEF <name> <byte location> <hex ID string>
ADD <command line to add file to archive>
EXTRACT <command line to extract all files from archive>
END
(Required) The ARCDEF commands tell Alexi/Mail how to identify and
handle different types of archived mail. At least one ARCDEF is
required; you can have as many ARCDEF blocks as you need to identify
the different types of archives you use.
The <name> in the ARCDEF line is the short name you give to that type
of archive (such as ARC, ZIP, etc; see the USE option). The <byte
location> and <hex ID string> let A/Mail identify the archive type.
See the examples below for more information.
The ADD line tells A/Mail how to add files to this type of archive.
The macro %A in this line will be expanded to the name of the archived
file; the macro %F will expand to the name of the file being added.
The EXTRACT line does just the opposite: it lets A/Mail extract
packets from within archived files. The %A macro will again expand to
the name of the archived file. Neither ADD nor EXTRACT need path
information; that is taken care of by the program.
NOTE: If an EXTRACT command is not given for a particular archive
type, A/Mail will silently ignore any inbound archives of that type.
If an ADD command is not given, A/Mail will complain when asked to
archive something in that format.
Some example ARCDEF blocks are shown here:
ARCDEF ARC 0 1A
ADD Arca %A %F
EXTRACT Arce %A
END
ARCDEF ZIP 0 504B
ADD PkZip %A %F
EXTRACT PkUnzip %A
END
ARCDEF LZH 2 2D6C68
ADD Lha a %A %F
EXTRACT Lha e %A
END
ARCDEF ARJ 0 60EA
ADD Arj a %A %F
EXTRACT Arj e %A
END
Required for certain systems only
---------------------------------
The items in this section are required only for certain systems, as
noted in their descriptions.
BOSSOF <pointnet>
(Required for Boss Nodes Only) This option is only used on
"boss-nodes," the parent nodes of point systems using 2D pointnet
addresses. It enables a special filter to keep these fake addresses
from getting out into the network.
NOFLO
(FrontDoor/d'Bridge mailers only; required) Tells A/Mail to use the
*.MSG file-attach method, instead of the BinkleyTerm *.FLO files. This
will automatically activate the NONETPACK option needed for these
mailers. NOTE: A/Mail must *not* share FrontDoor's PACKET directory!
Make certain A/Mail's OUTBOUND and FrontDoor's PACKET directories
are NOT the same!
HMSGDIR <directory>(=<key>)
(Hudson-format only; required) Tells Alexi/Mail where to find the
Hudson message base files. The <directory> should be the location of
the message base; the directory must exist, but A/Mail will create the
required files if they are missing. If you use multiple Hudson bases,
they must be defined on separate HMSGDIR lines, and all but the first
must include a <key>, a short word used to identify the message base.
SFMSGDIR <directory>(=<key>)
(Spitfire-format only; required) This tells A/Mail where to find the
Spitfire-format message base files. The <directory> must already
exist; A/Mail will not create it, though it will create the message
base files if necessary. The <key> is a short word used to identify
the message base, and is required only for multiple Spitfire-format
message directories; it is seldom needed.
SYNCDIR <main Synchronet directory>
(Synchronet-format only; required) This should refer to the main
Synchronet directory, the directory just above the NODEx\ directories.
A/Mail will search the CTRL directory under this one for MAIN.CFG,
which it needs -- if it can't be found or read, A/Mail will refuse to
run.
Outbound and Routing options
----------------------------
The options listed in this section control the handling and routing of
mail packets and archived mail bundles.
ARCSIZE <size in kilobytes>
(Optional; defaults to 250K) When an archived bundle grows past the
limit set by this option, A/Mail will no longer add to it; it will
start a new one instead.
PKTSIZE <size in kilobytes>
(Optional; defaults to 250K) Does for packets what ARCSIZE does for
bundles. When a packet reaches or exceeds the specified size, A/Mail
will take time out to put it into a bundle and start a new packet.
USE <archiver tag> <address>...
(Optional) This option tells A/Mail to use an alternate archiver for
certain addresses. The <archiver tag> is the one you chose to
represent that type of archive (see ARCDEF). Any address which is not
specified in a USE line will use the first archiver defined with an
ARCDEF option. The ALL keyword is supported here -- USE ZIP 2:ALL
would use PkZip for all zone 2 addresses, while USE ZOO 1:109/ALL
would use Zoo for addresses within zone 1, net 109.
HOLD <address>...
CRASH <address>...
DIRECT <address>...
NORMAL <address>...
IMMEDIATE <address>...
(Optional) These tell A/Mail how to "flavor" the mail for particular
nodes. The ALL keyword is supported. The meaning of the flavors
depends on the mailer software you use, and how it is set up on your
system. See the documentation for your mailer for more information.
Note that these may not work with FrontDoor or other non-FLO style
mailers.
ROUTE [<flavor>] <dest address> <address>...
(Optional) Routes all mail destined for the <address>es listed to the
<destination address>, and flavors it HOLD, CRASH, DIRECT, NORMAL, or
IMMEDIATE. The ALL keyword is fully supported in the <address> list. A
full description of routing and flavoring is beyond the scope of this
file. Note that this may not work with FrontDoor or other non-FLO
style mailers.
Logfile options
---------------
These options tell A/Mail what kind of logfile you want, where you
want it, and how detailed it should be.
LOGFILE <path and filename of log-file for Alexi/Mail>
(Optional) If a LOGFILE is defined, A/Mail will store important
information in human-readable log format (see also LOGTYPE and
LOGLEVEL).
LOGLEVEL [1 | 2 | 3]
(Optional; Defaults to 2) Specifies the level of logging desired.
1 - Logs only very important items
2 - Logs important and general items
3 - Logs important, general, and trivial items; used for debugging
LOGTYPE [BINK | FD]
(Optional; Defaults to BINK) Specifies the style of logfile desired.
BINK - BinkleyTerm-style. Each line contains the date and time of
the entry, and the ID of the program that made it, as well as the
text.
FD - FrontDoor-style. The lines contain only the time of the entry
and the text; A/Mail will put the current date in the text of the
first entry for each run, to make up for this.
Duplicate-message detection
---------------------------
The options in this section will allow A/Mail to find and stop
duplicate messages, when enabled.
SIGDIR <directory>
(Optional) Defining a SIGDIR activates Alexi/Mail's CRC-based
duplicate message detection. The information it needs to keep for this
function is stored in the defined directory. If necessary, A/Mail will
create subdirectories under this one to maintain full access speed.
See also DUPEMSG.
SIGKEEP <number>
(Optional; defaults to 2000) You can use this option to change the
number of messages A/Mail keeps dupe-detection information on. Each
message requires four bytes; the default 2000 limits this information
to 8K per message area.
DUPEMSG <directory>
(Optional) If defined, messages A/Mail detects are duplicates are
stored in this directory, in *.MSG format.
CHECKPATH
(Optional) This option offers another layer of duplicate-message
protection, which can be used in conjunction with the CRC detection
mentioned above, or alone. CHECKPATH tells A/Mail to look for
duplicated addresses in the PATH lines of the messages; if an address
appears twice, the message is likely a duplicate. I don't recommend
using this alone -- often a duplicate message has the PATH information
stripped from it -- but used in addition to SIGDIR, it can provide
extra protection.
CHECKTIME
(Optional) When enabled, A/Mail will check the timestamp on each
echomail message that it tosses. If the message says it was written
more than a year ago, or more than 24 hours in the future (to allow
for timezone variations), A/Mail will call it a bad message and not
toss it. This technically isn't part of the duplicate-message
detection system; it's included here because it will catch problems
that occur when a system dupes its entire message base into the net
(which can include messages several years old). WARNING: make sure
your system's clock is set to the right date before using this! See
also FIXDATES.
Security options
----------------
The options listed in this section, when combined with the security
features of your mailer, will prevent almost any unauthorized access
PKTPWD <address> <packet-password>
(Optional) This enables packet-passwording for certain addresses. It
is best used when combined with SECURE mode and your mailer's
session-level passwording. Don't confuse this with the session-level
passwording offered by mailer software; it's an entirely different
beast. Notice that you must have a PKTPWD line for each address you
want passworded. There is no limit on the number of PKTPWD lines you
can have.
SECURE
(Optional) The SECURE option checks all incoming messages' origination
addresses. If the originating address is not listed as one that gets
the echoarea in question, the message is considered bad, and will not
be processed.
Message-control options
-----------------------
These options allow extra control over the messages going into and out
of your system.
ALLSEEN
(Optional) The standard message base formats are somewhat limited, in
that they cannot store the full zone:net/node.point address
information in the standard SEEN-BY lines. The ALLSEEN option replaces
the SEEN-BY lines with ALLSEEN lines (in the local message base only),
which include the full zone and point addresses, and enables special
processing to allow cross-zone echomail. If any other software will be
accessing your messagebase and needs normal SEEN-BY information, do
not use this option.
BADMSG <directory to store "bad" messages in>
(Optional) If defined, all messages that A/Mail cannot process will
be stored in this directory, in *.MSG format. The reasons it could
not process them will be sent to the Sysop in a netmail message,
unless NOWARN is active.
DUMPUNKNOWN
(Optional) Intended for systems using the Planet Connect satellite
system. This option tells A/Mail to ignore messages intended for areas
it doesn't know, dumping them into the bit bucket. This removes the
need to define all the echomail areas PC sends, and frees up a lot of
memory A/Mail would otherwise spend storing information about them.
Note that the UNKNOWN and NEWAREA options are disabled when
DumpUnknown is used.
FIXDATES
(Optional) When used, A/Mail will check the dates on each incoming and
outgoing message. If the date is more than a year in the past, or more
than a day in the future (to allow for time-zone differences), the
date will be set to the current date and time. Your system clock must
be set correctly for this to work.
When combined with CHECKTIME, FIXDATES will only work on messages
being sent out; CHECKTIME will be used on inbound messages. See also
CHECKTIME.
FORCEKILLSENT
(Optional) When using FrontDoor or a similar non-FLO mailer, this
option will force all outgoing *.MSG netmail messages create by A/Mail
to be marked kill/sent. This will tell the mailer to delete the
messages after sending them.
FORCEPRIVATE
(Optional) When FORCEPRIVATE is used, all netmail messages imported to
your system will get the PRIVATE bit set, regardless of whether they
were marked private at the originating system. This does not affect
outgoing messages or messages being routed through your system.
KEEPATTRS
(Optional) By default, A/Mail will strip the Crash/Hold bits off of
incoming netmail, as a safety measure. If you need to disable this
behavior (to allow people to send crash netmail on your dime, for
instance) use KEEPATTRS.
LIMITADDRS
(Optional) In most echomail areas, Alexi/Mail will add only your
addresses within the same zone to the SEEN-BY lines. In areas going to
more than one zone, it will add *all* your addresses. The LIMITADDRS
option changes this; with LIMITADDRS active, A/Mail will only add the
addresses in the last /FROM line (see THE AREAFILE section), and it
will add all of those. A/Mail will revert to the original behavior for
areas with no addresses in the /FROM line, or no /FROM lines at all.
NOCHECKORG
(Optional) NOCHECKORG will disable Alexi/Mail's origin-line checking,
to allow echomail messages which do not have proper origin lines. As
this prevents A/Mail from detecting some types of grunged messages, it
should not be used unless needed.
NOFORWARD
(Optional) Alexi/Mail forwards routed netmail by default, unless you
use NOFORWARD to tell it not to. If NOFORWARD is active, routed
netmail will be considered "bad" messages, and will generate a warning
message to you, the Sysop.
NOIMPORTBOSS
(Optional) Alexi/Mail will, by default, treat inbound mail addressed
to a point's bossnode as its own. This allows point systems using
Alexi/Mail to recognise their echomail, which usually appears to be
addressed to the bossnode. If you need to disable this behavior, use
NOIMPORTBOSS.
NOPVTECHO
(Optional) When used, A/Mail will strip any "Private" flags off of
echomail messages both inbound and outbound. Does not affect netmail.
NOTOSS <name>
(Optional) This is primarily intended for use with Areafix, Filefix,
and other such "robot" programs, If a netmail message comes in for
your system addressed to the name indicated, it will be left in your
*.MSG netmail area (not tossed into Hudson or Spitfire netmail areas).
Only one name is allowed per line. There is no specific limit to the
number of NOTOSS lines you can use, though I would recommend keeping
it to a few.
NOZONEPURE
(Optional) By default, Alexi/Mail will only add to the SEEN-BYs the
addresses you have in the same zone a message is going to, unless the
message area is going to multiple zones. The NOZONEPURE option tells
A/Mail to add *all* your addresses to the SEEN-BYs of *all* message
areas.
RESTRICT
(Optional) For those SysOps who allow their users access to Netmail,
the RESTRICT option will prevent everyone except the SysOp from
entering flavored netmail; a flavored message entered by anyone else
while this is active will have the flavor stripped off of it as it
goes out, and a warning will be posted on the screen and in the
logfile.
RETEAR [ADD | REPLACE | NO]
(Registered version only; optional; defaults to ADD) This defines how
the tearlines are handled. On unregistered versions, or any message
with a blank or non-existant tearline, A/Mail will act as if RETEAR
REPLACE was used regardless of the RETEAR option specified.
ADD: A/Mail will add its name to the tearline of all outgoing
echomail messages created on your system, keeping the original
tearline intact after it. (ex: "--- Alexi/Mail+Alexi/Reader 1.00")
REPLACE: A/Mail will replace any existing tearlines on these messages
with its own name and version number, and your registration number or
(UNREG). (ex: "--- Alexi/Mail 2.00 (#1)")
NO: A/Mail will not touch the existing tearline at all.
ROUTECHO
(Optional) By default, A/Mail will not allow routed echomail through
your system. If you DO want to allow them, use ROUTECHO.
SHOWARRIVED
(Hudson-format only; optional) The SHOWARRIVED option, available only
for Hudson and multi-Hudson formats, tells A/Mail to add a hidden line
to all messages imported, telling the date the message arrived. This
line (@Arrived) can be seen by the Sysop with most BBS programs and
message readers.
STORESEEN
(Hudson-format only; optional) When STORESEEN is used, the hidden
SEEN-BY and PATH lines in echomail messages are stored in the message
base. If it's not used, A/Mail will throw away these lines, since they
are useful only to a few people.
STRIPCTL (<char>)
(Optional) Similar to the STRIPHIGH option, STRIPCTL works on control
characters (ASCII values of less than 32). This should not affect
non-English languages, but it *will* prevent ANSI strings, including
'ANSI bombs' -- the ESCAPE character will be changed. Don't use it if
you want to exchange ANSI-coded screens.
STRIPHIGH (<char>)
(Optional) This will tell Alexi/Mail to change any high-ASCII
characters to the specified character (or a space, if no character is
specified) when importing and exporting messages. It does not affect
messages already in the message base, and does not change the messages
passed on to other systems. High ASCII is not allowed in many
(English-speaking) Fidonet echomail areas, but is required for some
non-English languages -- if you use another language in any of your
mail, do *not* use STRIPHIGH.
SYSOPCVT <sysop's real name>
(Optional) If used, all incoming netmail addressed to this name is
translated to the Sysop's alias (see also SYSOP), and outgoing netmail
from the Sysop's alias is translated to this name.
On Spitfire systems (only), echomail areas are translated as well.
UNKNOWN <temporary directory for messages in unknown echo-areas>
(Optional) If defined, any message for an unknown echomail area will
be stored here in *.MSG format, and the Sysop will be notified via
netmail. This directory will be scanned before each echo-tossing run
for areas which have been defined since the last run. THIS OPTION MUST
BE SET TO A UNIQUE DIRECTORY, NOT USED BY OR FOR ANYTHING ELSE! If you
try to define it as a directory used to store other *.MSG messages,
you'll regret it -- consider yourself warned. See also DUMPUNKNOWN.
Remapping Options
-----------------
FORWARD <name> @ <address>
(Optional) If a netmail message arrives addressed to <name> at your
address, it will be forwarded to <name> at <address>. This is useful
for points or users that have moved, for example.
LIST <listname> (<password>)
<name> (@ <address>)
...
END
(Optional) The LIST option simulates the Carbon Copy function
available in many message-readers and BBS packages. After defining a
LIST, you send a netmail message to "LIST <listname>", where
<listname> is a name you pick. It will be forwarded to every name in
the list, at their addresses. If you don't specify an address for a
particular name, your primary address is used.
Since LIST messages can be sent from other systems as well as your
own, the LIST includes an optional password. If used, messages for
that LIST must be sent to "LIST <listname> <password>" to be
distributed. There is no limit to the number of LISTs you can have, or
the number of people on them, but each list *must* be terminated with
an END line.
If a message arrives for an unknown LIST, or with a bad password, the
message will be imported unchanged as normal netmail (with NO
distribution).
Integrated Area Manager
-----------------------
The items in this section relate to configuring the built-in
Areafix-style area manager, used by hub systems to allow downlinks to turn
areas on and off without manual intervention. For usage instructions for your
downlinks, and a list of features available, see the AREAMGR.USE file in the
distribution archive.
The two main keywords for this function are ECHOLIST and AREAFIX. The
ECHOLIST keyword tells A/Mail what areas are available and what flags are
needed to access them; the AREAFIX section describes what systems are allowed
to access the Area Manager, and what flags they have. The other keywords
described here control secondary functions and the Area Manager itself.
ECHOLIST <filename> (<reqflags>...) (/FORWARD <address> (<fwdflags>...))
(Required for Area Manager) The ECHOLISTs are the heart of the Area
Manager. They tell A/Mail what areas are available, who to allow
access to them, how to get ones that we don't already have, and who
can do so. Since this is rather involved, I will include a lot of
examples here.
The <filename> is the full path and filename of a list of echos. This
file should be formatted at one area per line, with the area name
starting somewhere within the first four characters. Anything on the
line after the area name, or after a ';' comment delimiter, is
ignored; any lines that begin with a TAB or four or more spaces will
be ignored entirely.
The optional <reqflags> are one or more "flags" you assign to these
echos. Only systems with *all* of these flags can request areas stored
in this ECHOLIST. If you don't specify any <reqflags>, then any system
with a password (see AREAFIX) can get these echos. Flags can be any
single word you wish; I recommend making them descriptive, so you will
remember what they mean. Flags can be of any length, and include any
alpha-numeric characters and most punctuation. Upper- and lower-case
do not matter; the flags WOW, wow, and wOW are the same to A/Mail.
The /FORWARD is optional. It tells A/Mail to allow systems to request
areas your system is not already picking up. You must put an <address>
immediately after the /FORWARD to tell A/Mail where to request these
areas. The <fwdflags> work just like the <reqflags> -- only systems
with all of the flags specified here can request areas you aren't
already picking up. If you specify /FORWARD without any flags, then
any system that can access these echos can forward a request.
Example:
ECHOLIST backbone.lst BKBN /FORWARD 1:109/343
In this example, any system which has the BKBN flag can access areas
listed in the BACKBONE.LST file. Areas not already being picked up
will be requested from 1:109/343, and anyone who has access to these
echos is allowed to forward requests.
ECHOLIST backbone.lst BKBN /FORWARD 1:109/343 FWDBKBN
This example is similar to the previous one, but systems must have
both the BKBN and FWDBKBN flags to request areas that aren't already
being received. Areas that *are* already being received still need
only the BKBN flag to access.
AREAFIX (<from-address>...)
<address> <password> <flags>
...
END
(Required for Area Manager) This is where Alexi/Mail gets the
passwords for various systems. You can have multiple AREAFIX sections
(for different addresses, perhaps) if you wish. NOTE: You MUST include
the addresses and passwords of your feed(s) if you wish to allow
A/Mail to automatically request areas from them. If you don't, A/Mail
will generate messages to the sysops instead, asking them to manually
turn on or off echos, when necessary.
The optional <from-address> field allows you to specify which of your
addresses this section is used for. If no addresses are specified, it
will use all your addresses. If one or more addresses are used here,
the Area Manager will only look at the section(s) to which the
messages are addressed.
Example:
AREAFIX 1:109/536
1:109/114 ZIMBOBWAI BKBN
1:109/343 WHODUNNIT BKBN
1:109/298 CAUSALITY BKBN PODS
END
In this example, if a message arrives on my system addressed to
1:109/536, this section will be used. If this were the only AREAFIX
section in my config file, any Area Manager messages for my other
addresses would result in a message that the sending node is not
allowed to access the Area Manager.
According to this, if the message is from 1:109/114, the password must
be ZIMBOBWAI. /114 also has the BKBN flag, meaning it can access any
areas that require only that flag (see ECHOLIST).
Also shown is 1:109/298, with the password CAUSALITY. /298 can access
any areas that require the flag BKBN, PODS, or both.
AREAMGR (NOSAVE) (KILLSENT) (FROMSYSOP) (SENDNOW) (LIST) (NORESCAN)
(Optional) Used to set various Area Manager options.
NOSAVE: Stops A/Mail from importing the Areafix messages from your
downlinks.
KILLSENT: Tells A/Mail to mark all return Area Manager messages
kill-sent. Your mailer will delete these messages as soon as they are
sent.
FROMSYSOP: By default, A/Mail puts its own name on forwarded Areafix
requests. Some area managers insist on having the name of the sysop
there instead. The FROMSYSOP option tells A/Mail to use the name
defined in SYSOP (or SYSOPCVT, if used) instead of its own.
SENDNOW: Default behavior is to place return Area Manager messages in
the netmail area unsent, to be sent out on the next mail run. This
option tells A/Mail to export them immediately, and not to store them
at all. When combined with the NOSAVE option, this makes the Area
Manager's operation completely unnoticable to the Sysop.
LIST: This option instructs the Area Manager to append a List of the
echos that node is receiving every time a change request is processed,
as if all requests had a -L option in them.
NORESCAN: As you might expect, this option disallows RESCAN requests.
NOAREAFIX
(Optional) This option tells Alexi/Mail to ignore messages addressed
to "Areafix", the default Area Manager name. You can use PROCESS (see
below) to allow Alexi/Mail to answer to one or more alternate names
instead, or in addition to, Areafix.
NONOTIFY <address>...
(Optional) This option tells A/Mail which of your downlink/uplink
systems it should NOT send a NOTIFY message to (see the command line
option -NOTIFY). You can specify as many addresses as you need on
one or more lines; short-form addressing and the ALL keyword are
fully supported.
PROCESS <name>
(Optional) Alexi/Mail's Area Manager answers (by default) only to the
name "Areafix", sans quotes. You can add additional names to this, to
allow A/Mail to emulate other area manager programs, using PROCESS.
Example:
PROCESS Areamgr
PROCESS Echofix
By including these lines in your config file, you would tell A/Mail to
answer to any messages addressed to "Areafix", "Areamgr", or "Echofix"
(to disable the default "Areafix", see the NOAREAFIX option). A/Mail
always answers messages with the name and address the messages were
sent to.
NEWAREA (ADD) (NOTIFY)
(Optional) The NEWAREA option tells A/Mail what to do with messages
that arrive in unknown areas. By default, such messages are put in the
UNKNOWN directory (if defined) or BADMSGS, and a message is sent to
the sysop to warn of this. If NEWAREA ADD is used, these areas would
immediately be added to the areafile. If NOTIFY was added to the line,
A/Mail would let the sysop know about the addition. See also DEADEND
and DUMPUNKNOWN.
DEADEND (TURNOFF) (NOTIFY)
(Optional) DEADEND TURNOFF tells A/Mail to look for areas defined in
your areafile, which are pass-through and have one or no downlinks.
Such areas serve no useful purpose; this option lets A/Mail remove
them from your areafile, and turn them off on the system that is
sending them to you. If no AREAFIX password is known for that system,
a message is generated for the sysop of it, asking him to turn the
echo off. The NOTIFY parameter tells A/Mail to let you, the sysop,
know when this happens.
This scan is made at the end of each run. It is useful with areas that
have been turned off by your downlink systems, and are no longer
needed. WARNING: When combined with the NEWAREA ADD option, any
messages that arrive for unknown areas will be turned on, then
immediately turned off again on the next run.
Miscellaneous Options
---------------------
For the most part, these options control the operation of A/Mail
itself.
AREAFILE <path/filename of areafile>
(Optional) A/Mail assumes the areafile is called AREAS.BBS, and is
stored in the directory the program is run in. If you use a different
name or location, you must use the AREAFILE option to tell A/Mail
where to find it.
FASTHUB <number>
(Optional) A/Mail has the ability to keep a number of outbound packet
files open at a time, which can speed up hubbing quite a bit. The
<number> option is the number of files to keep open, between 1 and 25.
The default is now 25, to give the maximum speed possible on all
systems; the option is still available only if it becomes necessary
to set this number lower for some reason.
EXIT <errorlevel> (<condition>...) ([NET | ECHO]...)
(Optional) The EXIT option allows A/Mail to tell the system when
certain events occur, by returning an errorlevel (see DOS manual for a
description of errorlevels and how to use them). *All* the conditions
specified must be met before the errorlevel will be used.
The conditions currently supported are:
TOSS: One or more netmail or echomail messages (use NET or ECHO to
specify only one or both types) was imported to your message base.
SCAN: One or more locally-generated netmail or echomail messages
(again, use NET/ECHO to specify the type[s]) was exported from
your message base.
HERROR: Hudson-base error. Problems detected with your Hudson
base(s), or A/Mail's SEATBELT has stopped tossing to prevent a
crash.
DISKFULL: The free space on your outbound drive has fallen below
the THRESHOLD value (which defaults to 1Mb).
ERROR: Generic error -- anything but a Hudson-base error or
disk-full.
If not defined, any ERROR, HERROR, or DISKFULL will produce an
errorlevel of 1, while all others will return an errorlevel of zero.
In most cases, only one or two EXIT lines will be used; the following
example just shows what's available.
Example:
EXIT 99 DISKFULL ; Outbound drive almost full!
EXIT 5 TOSS NET ECHO ; Any Netmail or Echomail tossed
EXIT 16 TOSS NET SCAN ECHO ; Netmail tossed and Echomail scanned
EXIT 8 TOSS ECHO ; If any echomail was tossed
EXIT 7 TOSS NET ; If any netmail was tossed
EXIT 6 SCAN ; If anything is scanned out
EXIT 9 ERROR ; If a general error occurred
EXIT 10 HERROR ; If a Hudson base needs fixing
EXIT 12 ; Used if none of the others apply
FLAGFROM <filename> <user name>
FLAGTO <filename> <user name>
(Optional) The FLAGFROM and FLAGTO options instruct A/Mail to create
zero-length files (often called "flagfiles") when a netmail message
from or to certain people arrives. For example, with the following
line in the config file:
FLAGTO D:\Den\Areafix.FLG AREAFIX
A/Mail would create the file AREAFIX.FLG, in the specified directory,
when any messages arrive addressed to Areafix (the file will be
created in the current directory if a full path isn't specified). This
file could be used to trigger other programs, or detected by your
batch files (see IF EXIST in your DOS manual) to run certain programs
when someone gets netmail.
By the same token, the FLAGFROM could be used to detect netmail from
certain people, and perhaps trigger an alarm when netmail from a Very
Important Person arrives:
FLAGFROM URGENT.FLG Vicki Surratt
FUZZYZONE
(Optional) Some programs don't put zone information into packets.
A/Mail will report these packets as being from your primary zone, even
if they're actually in an alternate zone -- this can lead to "routed
echomail" problems, among other things.
The FUZZYZONE option will blur A/Mail's perception of the zones (on
inbound messages only), so any mail for one of your addresses, in any
zone you have an address for, will be treated as your mail and
imported properly. For instance, if you had two addresses:
ADDRESS 1:109/536 93:9800/0
If your zone 93 messages comes in addressed to 1:9800/0, the FUZZYZONE
option lets A/Mail look for any other 9800/0 address you have, and
assigns the correct zone from it. The same with any messages sent to
93:109/536.
This also affects SECURE-mode, allowing SECURE operation in alternate
zones, and should prevent your system from creating duplicate messages
due to zone problems.
HIDDEN <zone:net/node(.point)>...
HIDDEN <zone:net/node.pointnet/point>...
(Optional) A HIDDEN address is never shown in the SEEN-BY lines. In
all other respects it is identical to an ADDRESS statement. HIDDEN is
almost never needed, except with Planet Connect -- make sure this is
really what you want before using it.
IGNORENM
(Spitfire-format only; optional) The Spitfire format includes a bit
designated "network message." When this is not turned on by the author
of a message, the message is supposed to be local, and ignored by mail
scanners such as A/Mail. Many Sysops and users who have used other BBS
programs find this confusing. The IGNORENM option tells A/Mail to
ignore this flag, and export all messages written in netmail or
echomail areas no matter what it is set to. FreeMail, and versions of
A/Mail up to 2.00a6, operated as if this option were always on.
NOPAUSE
(Optional) Alexi/Mail pauses for five seconds at the end of each run,
to allow you time to read what's on the screen before it disappears.
If you wish to disable this pause for whatever reason, use NOPAUSE.
NOSEATBELT
(Hudson-format only; optional) Alexi/Mail will attempt to protect your
Hudson message base(s) from going over certain limits, by refusing to
toss more messages into a nearly-full base. These limits are hardcoded
into the program, and are based on the RemoteAccess BBS 1.xx limits.
If you find this to be a problem, and have no fear of exceeding them,
you can remove these "seat belts" with the NOSEATBELT option.
NOTOUCH (<address>...)
(Optional) When NOTOUCH is used with one or more addresses after it,
Alexi/Mail will not toss packets addressed to those addresses. This is
particularly useful when more than one address must share the same
inbound directory, but toss messages separately. The ALL keyword and
short-form addressing are fully supported.
When NOTOUCH is used with no address, A/Mail assumes it should toss
packets *only* if they are addressed to your system.
NOWARN (<parameter>...)
(Optional) Disables all or some of the "warning netmail" Alexi/Mail
sends to the Sysop when it finds a problem. If used with no parameters,
all warnings are disabled. See also WARNAREA.
These options *only* disable the warning netmail messages. They do not
otherwise affect the operation of the program; if you define a DUPEMSG
directory, for example, all duplicate messages will still be put there
even if you tell A/Mail not to netmail you about them.
The available parameters are:
DUPES: Disables duplicate-message warnings.
CIRCULAR: Disables "Circular PATH detected" warnings.
UNKNOWN: Disables the "Unknown Area" warnings.
ROUTECHO: Disables the "Routed echomail" warnings.
BADPWD: Disables the "Bad password in echomail bundle" warnings.
SECURE: Disables the "Secure mode violation" warnings.
ORIGIN: Disables the "No ORIGIN line in echomail message" warnings.
DATE: Disables the "Bad date" and "Date fixed" warnings.
READONLY: Disables the "Read-only node sent mail" warnings.
OTHER: Disables any other warning messages.
REGISTERED <validation code> <reg. number> <name>
(Registered users only; required) This is what tells A/Mail you're
registered, and allows you to use the registered-only features.
Registration numbers are assigned in the order registrations are
received. The <validation code> is generated to match a particular
registration number and name.
REPORTSTATS (<filename>)
(Optional) When REPORTSTATS is used, A/Mail will list the number any
size of messages handled per area, either in the logfile or in the
specified filename. If you include a filename, the file will have full
message and byte information for every echo tossed, suitable for
processing with an echomail accounting program. If you don't use a
filename, basic stats will be kept in the logfile instead.
SCANALL
(Hudson and *.MSG formats only; optional) This keyword activates two
functions, one for Hudson, the other for *.MSG. If you only want to
activate these features for a single run, see the -ALL command-line
option.
Hudson-format operation:
Hudson-bases normally include two flag-files pointing to messages that
haven't been sent out yet. Some Hudson-base utilities apparently do
not support these files. If you use such a utility on a regular basis,
you can use the SCANALL option to tell A/Mail to scan the entire
message base for unsent messages. If you only need to do this on
occasion, you can use the -ALL parameter on the command line instead.
If A/Mail discovers that the information in one of these files is
incorrect, it will automatically invoke SCANALL.
*.MSG-format operation:
The *.MSG format (for echomail) uses part of the 1.MSG file as a "high
water mark," to speed scanning for unsent messages. Some BBS packages
use the *.MSG format as a stepping stone to their own formats; on
these systems, the 1.MSG pointer can cause locally-created messages to
be missed when scanning for unsent echomail. The SCANALL option tells
A/Mail to ignore the 1.MSG pointer for echomail areas, ensuring that
all messages are checked. Warning: in effect, this causes A/Mail to go
through each and every *.MSG message on the system. It should *not* be
used on most systems.
STOPSIGN [NOKILL]
(Optional) In a BinkleyTerm system's normal operation, when A/Mail
finds a netmail message being routed through your system, it will
immediately pack it up (possibly routing it, if you've specified this)
to ship it on. With the STOPSIGN option enabled, and -NT *not*
specified on the command line, A/Mail will make a *.MSG netmail
message out of it, allowing such programs as MSGTRACK to glance over
it. The message will be allowed to continue its journey when A/Mail is
run with the -NT option on the command line. You must define a *.MSG
netmail area to use this.
The optional NOKILL parameter tells A/Mail not to delete the *.MSG
copy of the stopped messages when it releases them.
Example:
AMAIL -ET (toss echomail, make *.MSGs out of netmail)
MSGTRACK (run whatever programs need to look over the messages)
AMAIL -NT (let the messages continue on)
SWAP
(DOS version only; optional) If this option is used, Alexi/Mail will
call Ralf Brown's excellent SPAWNO library to swap out most of its
code when executing an external program such as ARCE, PkZip, or ARJ.
This is not recommended for systems without EMS or XMS; the final
resort on such systems is swapping to disk, which can slow A/Mail
considerably. This option is accepted (but ignored) in the OS/2
version.
THRESHOLD <megs>
(Optional; defaults to 1Mb) A/Mail monitors the free disk space on
your outbound drive. When it detects that you have less than <megs>
megabytes of free space, it will stop tossing and exit; it will not
toss any more messages until you have at least <megs> space free. It
will try to archive mail before it exits, to make more room, if you're
not using a WORKDIR.
WARNAREA <area name>
(Optional; defaults to NETMAIL) When A/Mail runs across a problem it
thinks you need to know about, it will send you a message about it.
These "status report" messages are usually put in Netmail for you. If
you want them elsewhere, you can specify the area you want them to go
in with the WARNAREA option. The parameter should be a name you've
defined in the areafile; otherwise, A/Mail will complain and continue
to put the messages in Netmail. NOTE: although you can have these
messages put in an echomail area, they will *not* be exported. See
also NOWARN.
WORKDIR <working directory name>
(Optional) When WORKDIR is used, Alexi/Mail will build outgoing packet
files in the directory specified (creating it if required), archiving
them in the proper outbound directory when necessary. The WORKDIR
should be on a a much faster drive than your OUTBOUND directory (a
RAMdisk is ideal) to get the full benefits, and this drive should have
at least 256-512K free -- A/Mail monitors the free space on this
drive, and will start archiving packets to make room when it gets
below 50K. WARNING: Using a RAMdisk for the WORKDIR can cause
archiving errors if you have an archiver set to use it as well. For
best results, disable the archiver's use of the RAMdisk.
THE AREAFILE
------------
The AREAFILE is a text file, assumed to be in the current directory
when Alexi/Mail is run, and named AREAS.BBS. If you wish to change its name or
location, you must tell A/Mail where to find it with the AREAFILE option in
the config file (see AREAFILE in THE CONFIGURATION FILE section for details).
This section demonstrates everything Alexi/Mail will understand in an
areafile, and explains the rules it follows in interpreting the lines. As
there are several control lines unique to Alexi/Mail's areafile format, I
recommend all users at least skim this section.
The areafile gives Alexi/Mail the information it needs about the
message areas on your system. It is required. Like the configuration file,
everything after a semicolon (;) in the areafile is ignored, and can be used
for comments.
The general format for each line is...
<boardinfo> <areatag> <address>... (; <area description or comment>)
...where <areatag> is the official area tag of the echo (or NETMAIL for your
netmail area[s]), and the <address>es are addresses of the other systems you
send this echo to. The <boardinfo> tells Alexi/Mail where and how to store the
messages for that area; the format depends on the type of message-base you
use:
<Number> (a single-Hudson-base board)
<Number>@<tag> (a multiple-Hudson-base board)
!<Number> (a normal Spitfire conference number)
!<Number>@<tag> (a multiple-Spitfire-base conference number)
<directory> (a *.MSG echomail or netmail directory)
%<Internal code> (a Synchronet message area)
#<directory> (a pass-through area; the <directory> is optional)
P (alternate pass-through designation)
Echomail Areas
--------------
TAG BBS USERS, PLEASE NOTE: The TAG BBS system uses a modification of
the Hudson message base for local message areas. This modified format IS NOT
COMPATABLE with the standard Hudson format. The problem, a corrupted message
base, appears when maintenance is run. Keep your netmail/echomail areas in a
different Hudson base from all TAG local message areas; this will prevent the
problem. I have not been able to get any further information about this;
thanks to Russ Trahan for what's here.
The largest part of the areafile will probably be the echomail areas.
This section gives tips and examples on them.
2 L_SYSOP 271/247 ; Felicia's Local messages-to-sysop area
9 SYSOP-109 109/5 40 400 500 700 800 !261/2 ; Sysop-only echo for net109
%Folklore P_FOLKLORE 1:109/536 ; Synchronet area, internal code "Folklore"
In this example, the first line shows that the echo L_SYSOP should be
stored in the Hudson-style echomail area #2, and it is being sent and received
from 271/247. The zone, if not specified, will default to that of the origin
address for that echo.
The second line is similar. The echo SYSOP-109 is being sent to six
different addresses from here. Notice the short-form address list -- you
don't have to specify the "net" portion again if it's the same as the previous
one on that line. The same it true for the zone, if you use multiple zones.
If you looked closely at the second line, you might have noticed that
there is an exclaimation point ('!') before the last address. This is the
"read only" designator here -- the address listed directly after it will
receive messages as normal, but will not be able to send any messages for that
area; if he did, it would be thrown away, and you would be warned that he
tried it. When used with SECURE mode, it provides a near-foolproof way to
prevent a particular node from posting while still allowing it to receive an
area. The '!' *only* affects the address directly after it; to use this with
multiple addresses, you must specify the '!' in front of each of them.
Note that, for Synchronet-format areas, the boardinfo is a '%'
followed by the "Internal code" (as shown in SCFG's sub-board display for that
area) with no space between them. See the third example line above.
Hudson-style message bases are limited to 200 areas each. The board
number MUST be between 1 and 200, inclusive, or Alexi/Mail will complain and
refuse to run. I don't know of any specific limit on the number of Spitfire
areas. There is no limit to the number of areas Alexi/Mail can handle except
memory. The OS/2 version, with the near-unlimited virtual memory OS/2 offers,
should be able to handle anything you throw at it; the DOS version should be
able to take several thousand echos before choking.
C:\BBS\FUBAR\ FOOBAR 109/542 536 271/248
This line says that the FOOBAR echo is a *.MSG-style area, stored in
the C:\BBS\FUBAR directory. It is being passed to three other systems:
109/542, 109/536, and 271/248. The trailing backslash on the directory name is
optional.
# SAMPLE 109/542 271/248
P SAMPLE 109/542 271/248
These lines are identical in meaning. They say that the echo SAMPLE
is being passed between 109/542 and 271/248 through my system, but not stored
here -- it is a PASS-THROUGH area. I don't read the hypothetical SAMPLE echo,
and my users aren't interested, so I don't want to keep it around taking up
disk space.
Most Hudson-base mail programs use the 'P' to designate pass-through;
most others use a pound sign (#) followed by a directory name. A/Mail
recognizes either, but does NOT need a directory name for such areas. It uses
one pass to both import and export such messages and does not need to store
them locally.
An Example of a simple Spitfire AREAS.BBS File:
!05 HOUSTON_CHAT 1:106/1000 ;Houston Chit-Chat conference
!06 SPITFIRE 1:106/1000 ;Spitfire Support conference
!07 DBASE 1:106/1000
!08 CLIPPER 1:106/1000
!09 FOXPRO 1:106/1000
!10 PARADOX 1:106/1000
!11 CLARION 1:106/1000
!12 CONSULTING 1:106/1000
!13 PC_CONSULT 1:106/1000
!14 DBRIDGE 1:106/1000
!15 NEW_SYSOP 1:106/1000
!16 SYSOP 1:106/1000
Netmail Areas
-------------
A NetMail area is similar to an echomail area; where echomail messages
arrive and are "echoed" to many other systems, a netmail message has only one
destination. The netmail area is also where A/Mail sends you messages
concerning problems it encountered during a run (see NOWARN and WARNAREA).
You tell A/Mail the location and format of your Netmail area(s) the
same way you do the echomail areas (see the previous section if you need a
refresher), with the area "tag" as NETMAIL. You don't need to put any
addresses after the area tag; netmail areas aren't echoed. Alexi/Mail can
handle netmail in all the formats it can handle echomail for, except
Synchronet.
Control Lines
-------------
Alexi/Mail currently recognizes several control lines in the areafile,
as described below. At this time, these are unique to A/Mail and FreeMail.
Since some other programs use the areafile for their own purposes, these
control lines can cause confusion; to prevent this, there is a way to tell
A/Mail to use certain lines while other programs ignore them:
Example:
12 C_ECHO 1:109/343 ; Normal line with comment
;+ /FROM 93:9800/0 ; Line hidden from all programs except A/Mail
20 P_SYS 93:9600/0 ; Normal line
As you see in the example, the ";+" characters (when used at the
beginning of a line) instruct A/Mail to use that line, while hiding it from
other programs. A/Mail will process these lines as if the ;+ characters
weren't there at all. These characters can be used with area lines as well as
control lines, though the usefulness of this application is questionable.
The first is the /FROM line, most commonly used when running echomail
in multiple networks. It tells Alexi/Mail to use one (or more) of your
alternate addresses as the primary address for the areas following it. The
format of this line is:
/FROM (<address>...)
You may specify zero or more of your addresses in this line. If you
don't specify any addresses, A/Mail will assume it can use all of them as
needed.
For example, if you had an AREAS.BBS file like this:
!05 HOUSTON_CHAT 1:106/1000 ;Houston Chit-Chat conference
!06 SPITFIRE 1:106/1000 ;Spitfire Support conference
!07 DBASE 1:106/1000
/FROM 1:106/1024 81:400/21
!81 OS2MSGS 81:400/100 413/0 132 ; Being sent to three other systems
!82 OS2BUGS 1:106/1000 81:400/100
Every area listed after a /FROM line will use one of the addresses on
the /FROM line as the origin. The message will be shown to have come from that
address, and the Origin line (if A/Mail has to append one; see /ORG, below)
will use it also. The address *must* be one of yours, listed in an ADDRESS or
HIDDEN statement in the config file. If it isn't, Alexi/Mail will complain and
refuse to run.
Notice, in the last example line above, that the OS2BUGS echo is being
sent to two places, in two different zones. For the zone 1 address, Alexi/Mail
will send the message from 1:106/1024; for the zone 81 address, it will use
81:400/21. Both addresses, sans zone info, will be listed in the SEEN-BYs (see
the description of the NOZONEPURE option for more information). If the /FROM
line shown had only the zone 1 address in it, both the zone 1 and zone 81
messages would be shown as originating at 1:106/1024.
Another control line Alexi/Mail understands is the /ORG line, which
allows you to specify a customized Origin line for one or more echo areas.
/ORG <origin-line text>
This is probably useful only in Spitfire setups (in which Alexi/Mail
must add an Origin line to every outgoing message), or in combination with the
/GATE option. Like the /FROM line, it affects every area listed after it,
until another /ORG line overrides it. Note that you do *not* put your address
here; Alexi/Mail will add it when necessary. Areas before the first /ORG line
will use the SYSTEM line (see SYSTEM in THE CONFIGURATION FILE) for the
origin.
If your AREAS.BBS file had:
/ORG The Jhereg's Den -- Home of Alexi/Mail and Alexi/Ware
!10 FREEMAIL 106/4196 109/5
!11 SPITFIRE 109/50
/ORG The Jhereg's Den -- An it harm none...
!21 MUNDANE 109/120 418
The first /ORG line would affect both the FREEMAIL and SPITFIRE
conferences. The second would affect MUNDANE and any conferences listed after
it.
The control lines /STRIPHIGH and /STRIPCTL have the same syntax, and
(along with /NOSTRIPHIGH and /NOSTRIPCTL) control the removal of certain types
of characters from messages (please see the discussion of the STRIPHIGH and
STRIPCTL options in the config file for details). The options in the config
file, if not overridden, control all areas; these lines affect only the areas
listed after them. As you might guess, /NOSTRIPHIGH and /NOSTRIPCTL disable
that type of stripping for the areas listed after them.
/STRIPHIGH (<character>)
/STRIPCTL (<character>)
/NOSTRIPHIGH
/NOSTRIPCTL
The next control line, /AND, allows you to keep mail from one area in
two or more places. It is placed directly after the area it is intended to
mirror.
<boardinfo> <echo tag> (<address>...)
/AND <boardinfo>
(/AND <boardinfo>)
(...)
For example:
C:\BBS\FIDO\FREEMAIL FREEMAIL 106/4196
/AND !10
In this example, the FREEMAIL echo would be stored in both the *.MSG
area (in the directory C:\BBS\FIDO\FREEMAIL) and the Spitfire-format area
(conference 10). Any messages entered in one of these areas would be tossed
into the other as well, when the echo was scanned.
The /AND line can contain any of the valid <boardinfo> types,
including another board or conference of the same type as the first. Although
FreeMail would only allow one /AND line per echo, Alexi/Mail allows as many as
you need.
The next control line is /BRIDGE. This was added to allow systems to
gate echo areas to and from different technology networks, such as QWK
networks. It selectively prevents A/Mail from marking imported or exported
messages as "sent," to allow the tosser program for another network to send it
out as well. The format is:
/BRIDGE (IN) (OUT)
Consider the following AREAS.BBS fragment:
/BRIDGE IN ; Turn on the import-only bridge
19 TECHNET109 109/5
13 AUTO109 109/5 40
/BRIDGE ; Turn off bridging. ** VERY IMPORTANT! **
When any messages come in for the two areas shown (TECHNET109 and
AUTO109), they will be tossed into the message base and distributed as usual,
but marked unsent. Then, presumably, some other program (for the QWK or other
type of network) will scan the message bases, find the unsent messages, send
them out, and mark them sent. THE LAST SUCH PROGRAM *MUST* MARK THE MESSAGES
"SENT"! Otherwise, you will find numerous duplicate messages being exported
from your system!
You can also use /BRIDGE OUT, or /BRIDGE IN OUT. The "out" option
prevents A/Mail from marking messages written on your system as "sent." IN and
OUT will normally be used together; they are provided separately just in case
someone needs that capability.
As shown in the example, you *must* use /BRIDGE with no options to
turn off bridging before any un-BRIDGEd areas are defined.
The next control line is /GATE. This allows you to set up a "gateway"
between two different echo areas. All messages going into one of these areas
will be "gated" into the other as well. Like the /AND line, this is added
directly after the area it is meant to modify. Most people will never need
this.
The format of the /GATE line is:
<boardinfo> <echo tag> (<address>...)
/GATE <echo tag> (<address>...)
...where the <echo tag>s are the names of the echos to gate, and the
<address>es are the systems you want to send the echos to. If you need to use
a different set of origin addresses for the gated echo, put a /FROM line just
between the original echo and the /GATE.
To set up a gateway between the echos ERIS and ERIS&MOO, for instance:
/FROM 1:109/536
!22 ERIS 1:109/120 228
/FROM 93:9800/0
/GATE ERIS&MOO 93:9300/0 9800/3 9810/0
Using these lines, the ERIS echo would be stored in the Spitfire
message area 22, and sent from 1:109/536 to 1:109/120 and 1:109/228. It would
also be gated to the ERIS&MOO echo in zone 93, from 93:9800/0 to 93:9300/0,
93:9800/3, and 93:9810/0. Any messages coming into either of these echos would
go out in both, with the proper origin lines (see /ORG, above) appended on the
gated side. WARNING: Because gating removes all SEEN-BY information, there
must be only *one* gateway for a particular pair of echos, or you will set up
a nasty dupe-loop!
For obvious reasons, you can only /GATE a echomail areas.
SPITFIRE NETMAIL FEATURES
=========================
There is some confusion between Fidonet's definition of the word
"netmail" and that used by the Spitfire BBS. Fido's definition does *not*
include echomail; it is limited to non-echomail messages going from one system
to another. This document uses the Fido definition unless otherwise specified.
In Spitfire, a NetMail message is created by entering coded
information in the subject of the message in the conference named NETMAIL. The
message MUST be entered in your NETMAIL conference; if you have not set up a
NETMAIL conference, this feature will not work.
Alexi/Mail will consider any message in your NetMail conference that
does not contain a valid Fidonet-format address to be a local message and will
not send it.
The syntax to address a NetMail message (in the subject line) is as
follows:
<address>(<flavor>) <subject>
The <address> is the address of the system which you wish to send the
NetMail message to, in standard Fidonet format (Zone:Net/Node.Point). The
<flavor> is a single letter ('c' for crash, 'h' for hold, etc), which
indicates the optional flavoring of this message (see the RESTRICT option for
a way to prevent users from sending out crash-netmail). <subject> is the
actual text of the subject. You must leave at least one space between the
address/flavor and the text of your subject.
NOTE: If the zone is not entered, the message will default to your
primary zone. If the <flavor> is not entered, or is an unrecognized letter,
the flavor will default to "normal."
Example:
1:106/4196c I Love Alexi/Mail!
This message will be sent, as crash-flavored netmail, to 1:106/4196
with the subject of "I Love Alexi/Mail!"
NOTE: Spitfire 3.3 includes a new, mostly undocumented field for the
destination address. If there is a readable Fidonet-format address in this
field, Alexi/Mail will use it instead of searching the subject line, allowing
the entire subject line to be used for the subject of the message. At the time
of this writing, only Alexi/Mail, FreeMail 1.07+, and the Alexi/Message (soon
to be rewritten) support this field.
Alexi/Mail now supports limited file-attaches and requests from the
Spitfire netmail conference. To use this, the *first* line of the netmail
message must be one of the following:
@FATT <filename>...
...or...
@FREQ <filename>...
The first creates a "file-attach" -- the file(s) you list after the
@FATT will be sent to the destination address along with the message. The
second creates a "file-request," asking the destination system to send you the
file(s) you list. Both are currently limited to 70 characters, and one line,
per message.
COST
====
Alexi/Mail is Shareware. It is available under two pricing schemes.
The first is intended for personal, non-commercial use only; the second for
commercial or government use.
Non-commercial, non-government systems must pay a one-time fee of $25
for the program, and may then use it on as many machines as are run by that
Sysop. These systems do *not* need to purchase multiple copies or site
licences to run the program on more than one machine.
Commercial or government systems must pay for each copy they use. Bulk
pricing is available as follows:
Copies Price per copy
------ --------------
1-10 $25
11-25 $22
26-50 $18
51-75 $13
76+ $10
Please see the REGISTER.TXT and ORDER.FRM files, included in the
distribution archive, for details on how to register.
TROUBLESHOOTING
===============
If you have problems with Alexi/Mail, please check through this
section for any tips that might help. This section will grow as more common
problems are discovered.
PROBLEM: Alexi/Mail exports messages and archives them, but BinkleyTerm
doesn't see them and won't send them.
REASON: BinkleyTerm and related mailers use *.FLO files to designate
file-attaches. If these files are damaged or deleted -- as some versions
of Bink will do in some instances -- Alexi/Mail will not re-create them
unless it adds to the archived bundle.
SOLUTION: If you have a utility such as BONK, you can view the outbound,
see the files that need to be attached, and file-attach them to their
destinations. If you don't, you can go into your outbound area, decompress
and delete the unattached mail bundles and use the command "AMAIL -ET".
Alexi/Mail will go through its normal run, and when it finds all of the
unarchived packets in the outbound area, it will re-compress them,
creating new file-attaches.
---
PROBLEM: Alexi/Mail exports messages and archives them, but FrontDoor (or
compatable mailer) doesn't see them and won't send them.
REASON: Similar to the BinkleyTerm problem mentioned above. The bundles
are only file-attached when A/Mail adds to them; if the file-attach
message is deleted before the bundle is sent, Alexi/Mail won't reattach
it.
SOLUTION: As with the above problem. Go into your outbound directory,
decompress and delete the unattached mail bundles, and use the command
"AMAIL -ET". Alexi/Mail will go through its normal run, and when it finds
the unarchived packets in the outbound area, it will re-compress them,
creating new file-attaches.
---
PROBLEM: Netmail sometimes/always goes into the FrontDoor netmail folder,
instead of the other netmail areas you've defined.
REASON: Unless you tell it not to, FrontDoor will handle any netmail that
comes in *.PKT format before Alexi/Mail can see it; netmail that arrives
packed in an archive is handled properly by Alexi/Mail.
SOLUTION: Add this line to your batch file before calling FrontDoor:
SET FDOPT=NOUNPACK
This will tell FrontDoor to leave netmail packets alone, allowing
Alexi/Mail to handle them. Also make sure you are including -NT on the
command line.
---
PROBLEM: Alexi/Mail complains that you have to have a *.MSG netmail area
with FrontDoor systems.
REASON: FrontDoor-style systems use the *.MSG netmail area to store
file-attach messages, necessary for A/Mail's operation.
SOLUTION: Add a line to your AREAS.BBS file in this format:
C:\FD\NETMAIL NETMAIL
Change the C:\FD\NETMAIL portion to match the NETMAIL directory defined in
FrontDoor. If you define another NETMAIL area in a different format (ie
Spitfire or Hudson), Alexi/Mail will understand that the *.MSG area is to
be used only for file-attaches.
---
PROBLEM: Some alternate-zone packets are coming in with the wrong zone on
them.
REASON: The "Stone Age" type-2 packet format doesn't include a reliable
way to get zone information.
SOLUTION: Add the FUZZYZONE option.
---
PROBLEM: A/Mail sometimes/always ignores Areafix messages.
REASON: FrontDoor unpacks these messages, so A/Mail never sees them.
SOLUTION: As with some other problems, adding this line to your batch file
before calling FrontDoor:
SET FDOPT=NOUNPACK
...will tell FrontDoor to leave netmail packets alone, allowing Alexi/Mail
to handle them.
---
PROBLEM: A/Mail complains that the "Route-To address may not include ALL"
or is routing things backwards.
REASON: A/Mail's ROUTE command has a tail-first syntax, like many of the
original routing handlers. The first address listed is the one all the
other addresses will be routed to, and it cannot include ALL.
SOLUTION: Rearrange your ROUTE lines in AMAIL.CFG so that the target
address is listed *first* on the line.
---
PROBLEM: There is a mail bundle in the INBOUND directory, but Alexi/Mail
won't process it.
REASON: The most common reason for this is that the file is empty (a
directory listing of the INBOUND would show its size as zero bytes).
A/Mail ignores these files because this is also how a file appears when
it is being received under a multi-tasking program without SHARE.
Deleting it while it's being received in another task creates problems on
the hard drive, so A/Mail ignores these files completely.
SOLUTION: The easiest solution is to manually delete any zero-length files
that may appear, as soon as you notice them. A slightly fancy batch file,
under a batch-enhancing utility like REXX or 4DOS, could be designed to
find and delete these files automatically.
---
PROBLEM: My multi-network system adds new echos to the bottom of the
areafile, and they go out with the wrong /FROM addresses on them.
REASON: A/Mail doesn't yet have a mind-reading function. <grin> It will
use the last /FROM line in the file for any echos it adds.
SOLUTION: Add an *empty* /FROM line to the end of the areafile. This tells
A/Mail to use the best-fitting address for the areas after it, which is
usually the desired operation.
---
Any other problems you may have can likely be solved in the FREEMAIL
echo, a Zone 1 Backbone echo devoted to support for FreeMail, Alexi/Mail, and
other Alexi/Ware programs. If you can't get this echo, you may contact me by
netmail for help, but *please* try to get the echo first... I'm being swamped
by netmail already, to the point that I barely have time to write anything
else.
CREDITS
=======
Alexi/Mail would not have gotten where it is now without the efforts
of many people, especially the alpha-test team and those who helped develop
FreeMail. Although I'm sure there are people I've missed, here's at least a
partial list of the testers and contributors:
Paul Aljets, Bill Arlofski, Sid Balcom, Jeff Balderson, Matt Barton,
Matt Blythe, Danny Burdick, Ross Cassell, Brad Collyer, Jim Couch,
Doug Cox, Jack Crawford, Rich Davies, Barry Dowell, Earl Driscoll,
Robert La Ferte, Laura Fiorilla, Edward Georgen, Aaron Goldblatt, Mike
Grant, Don Griffin, Dan Guenthner, John Hargrove, Gary Hagwood, Howard
Hill, Steve Horrighs, Ron Hossack, Bill Huttig, Michael J. Klein,
Kevin Leger, Randy Lilleston, Renald Loignon, Bill McGarrity, Bill
Meck, Russell Mikami, Andrew Minter, Andy Montgomery, Ken Nelson, Dave
Nemeth, Jeff Norton, Emmett Perdue, Kevin Perkins, Jim Quick, Shawn
Ramsey, Joe Salemi, Rupa Schomaker, Vicki Surratt, Rick Sweares,
Thomas Teeter, Russ Trahan, George Vandervort, Michael Walker, Tex
Watson, Mike Weaver, James Young, Roy Zurowski
...and all the people who exchange mail with them and me, for putting
up with the problems that occurred long enough to fix them. And of course, a
special thanks to Bill Hampton and the Felicia BBS, who I blame for getting me
into FidoNet programming to begin with. Some of my first programs are still
chugging along there, helping make Felicia (already an outstanding system)
truly one-of-a-kind.
Thanks also to Ralf Brown, who wrote the excellent SPAWNO library used
by the DOS version of Alexi/Mail to swap itself out of memory when running
external programs.
DISCLAIMER
==========
The author hereby disclaims all warranties relating to this software,
whether express or implied, including without limitation any implied
warranties of merchantability or fitness for a particular purpose. The
author will not be liable for any special, incidental, consequential,
indirect, or other damages resulting from loss of data or other reason,
even if the author has been advised of the possibility of such damages. In
no event shall the author's liability for any damages ever exceed the
price paid for the license to use software, regardless of the form of the
claim. The person using the software bears all risk as to the quality and
performance of the software.
OUTLINE
=======
This section contains an outline of this file, showing the layout it
uses. All the section names are shown in the order they appear.
I. SETUP AND CONFIGURATION
A. THE COMMAND LINE
B. THE CONFIGURATION FILE
1. Required
SYSOP
SYSTEM
ADDRESS
INBOUND
OUTBOUND
ARCDEF
2. Required for certain systems only
BOSSOF
NOFLO
HMSGDIR
SFMSGDIR
SYNCDIR
3. Outbound and Routing options
ARCSIZE
PKTSIZE
USE
HOLD
NORMAL
DIRECT
CRASH
IMMEDIATE
ROUTE
4. Logfile options
LOGFILE
LOGLEVEL
LOGTYPE
5. Duplicate-message detection
SIGDIR
SIGKEEP
DUPEMSG
CHECKPATH
CHECKTIME
6. Security options
PKTPWD
SECURE
7. Message-control options
ALLSEEN
BADMSG
DUMPUNKNOWN
FIXDATES
FORCEKILLSENT
FORCEPRIVATE
KEEPATTRS
LIMITADDRS
NOCHECKORG
NOFORWARD
NOIMPORTBOSS
NOPVTECHO
NOTOSS
NOZONEPURE
RESTRICT
RETEAR
ROUTECHO
SHOWARRIVED
STORESEEN
STRIPCTL
STRIPHIGH
SYSOPCVT
UNKNOWN
8. Remapping options
FORWARD
LIST
9. Integrated Area Manager
ECHOLIST
AREAFIX
NOAREAFIX
NONOTIFY
PROCESS
NEWAREA
DEADEND
10. Miscellaneous options
AREAFILE
FASTHUB
FLAGFROM
FLAGTO
FUZZYZONE
EXIT
HIDDEN
IGNORENM
NOPAUSE
NOSEATBELT
NOTOUCH
NOWARN
REGISTERED
REPORTSTATS
SCANALL
STOPSIGN
SWAP
THRESHOLD
WARNAREA
WORKDIR
C. THE AREAFILE
1. Echomail Areas
2. Netmail Areas
3. Control Lines
/FROM
/ORG
/STRIPHIGH
/NOSTRIPHIGH
/STRIPCTL
/NOSTRIPCTL
/AND
/BRIDGE
/GATE
II. SPITFIRE NETMAIL FEATURES
III. COST
IV. TROUBLESHOOTING
V. CREDITS
VI. DISCLAIMER
VII. OUTLINE