Night Owl 25

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

/ Night Owl 25 / nopv25.iso / 029A / VERVEP.ZIP / AMAIL.DOC < prev next >

Wrap

Text File | 1994-08-02 | 89.6 KB | 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