home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
The World of Computer Software
/
World_Of_Computer_Software-02-387-Vol-3of3.iso
/
i
/
imail135.zip
/
IMAIL.DOC
< prev
next >
Wrap
Text File
|
1992-12-20
|
213KB
|
5,091 lines
█┐ █▀▀▀█┐ █▀▀█┐ █┐ █┐
█│ █│█┐█│ █│▀█│ █│ █│
█│ █│└┘█│ █│ █│ █│ █│
█│ █│ █│ █│ █│ █│ █▄▄▄┐
└┘ └┘ └┘ └┘ └┘ └┘ └──┘
The "Semi-Intuitive" Mail Processor
V e r s i o n 1 . 3 5
Copyright 1992
IMAIL INC.
Stefan Kaspar, Andreas Klein, Markus Lomb,
Frank Prade and Stefan Rubner
All Rights Reserved
══ TABLE OF CONTENTS ══
1. INTRODUCTION
2. WARRANTY AND REGISTRATION INFORMATION
a. Standard Disclaimer
3. ACKNOWLEDGEMENTS
a. Copyrights
4. INSTALLATION
a. Environment Variables
1) IMAIL
2) POINTNET
3) TASK
b. System Requirements
1) Hardware
2) Software
3) Networks and File Sharing
4) IMAIL Semaphore
c. Upgrading from Previous Versions
5. IMSETUP
a. General Configuration
1) System Addresses
2) Domains
- Domain
- Outbound Directory
- Zone List
- AKA List
3) Subdirectories
- Hudson Message Base
- Net Mail Message
- Inbound Net Files
- Temp Inbound Packets
- Outbound Net Files
- Temp Outbound Packets
- Netmail Semaphore File
- Semaphore Directory
- IMAIL Log File Name
- Auto-Added Areas Log
- Log Format
4) AreaLink Options
- Keep AreaLink Reply
- Keep AreaLink Request
- Password Expiration Days
- AreaLink Help Text
- Forward Link Requests
- Remote Maint Help Text
- Unlink Requests
- Forward Link Requests Data
5) Product Codes
6) No Import
7) Other Parameters
- ARCmail 0.6 Compatibility
- Number of Dupe Records
- Auto-add New Areas
- New Areas Passthrough
- New Areas Group
- Multi-Tasking
- Semaphore Time-out
- Max Packet Size
- Max Arcmail Size
- Dupe Ring Handling
- Max Message Size
- Environment
- Truncate/Delete Sent ARCmail
- Single Bundle Extract
- Send Return Receipt
- Forward For Other Systems
- Keep Outgoing Packets Open
- Swap Options
- Add Via Lines
- Use FTSC Product Names
- Check for personal mail
- Add new systems to IMAIL.ND
- Unlink autoadded areas
- Before Toss
- Sysop Name
- Default Origin
9) Group Manager
b. Compression Programs
c. Decompression Programs
d. Area Manager
1) Editing Keys
- F1: Edit
- F2: Find
- F3: Global
- F4: Browse
- F10: Save
- Ins: Add
- Del: Delete
- Home: First
- End: Last
- ESC: Exit
- PgUp/PgDn: Previous/Next
2) The Message Area Record
- Area Name
- Comment
- Origin Line
- Active
- Group
- Secure
- Msg Base Type
- Type
- Board
- Path
- # Days
- # Msgs
- Hide
- Unlinked
- Unlinked Request
- Mandatory
- Read only
- Origin Address
- Seen-Bys
- Export List
e. Node Export Manager
1) Editing Keys
- F1: Edit
- F2: Find
- F4: Browse
- F10: Save
- Ins: Add
- Del: Delete
- Home: First
- End: Last
- ESC: Exit
- PgUp/PgDn: Previous/Next
2) Address
3) Sysop
4) Domain
5) AreaLink Password
6) Packet Password
7) Groups
8) Notify
9) Remote Maint
10) Direct
11) Rescan OK
12) Add to New
13) Forward Requests
14) Create New Areas
15) New Areas Group
16) Uplink
17) Program Name
18) FSC-0057 compatible
19) Status
20) Program
21) Capability
22) Cap Handling
f. Pack Routing
6. IMAIL COMMAND LINE OPTIONS
a. /? - Help
b. TOSS - Toss Incoming Mail
1) /B - Check Bad Message Board
3) /X - No Compression
c. SCAN - Scan for Outgoing Mail
1) /D - Disable Dupe Checking
2) /F - Force Complete SCAN
3) /Q - Only Hudson
4) /S - Only MSG/Squish
5) /X - No Compression
7. IMPACK - Pack Net Mail Messages
a. /N - No Default Pack Routing
b. /C - Pack Crash Messages
c. /D - Pack Direct Messages
d. /H - Pack Hold Messages
e. /R - Pack Route Direct
f. /X - No Compression
g. /? - Help
8. IMALNK
a. Format of the Request
b. Meta-Commands
1) %COMPRESS
2) %FROM
3) %HELP
4) %LIST
5) %NOTE
6) %PAUSE
7) %PWD
8) %QUERY
9) %RESCAN
10) %RESUME
11) %UNLINKED
12) %INFO
c. AreaLink Replies
d. Forward Link Requests
e. Remote Deletion
f. Remote Adding
g. Remote Change
h. Local Maintenance
1) /N<address> - Node to Make Changes For
2) /+<area> - Link Node to Area
3) /-<area> - Unlink Node from Area
4) /=<area> - Update Node in Area
5) /I - General Information
6) /L - List Available Areas
7) /Q - Query - List Linked Echos
8) /U - List Available but Unlinked Echos
9) /R - Rescan
10) /H - Send Help
11) /P - Pause
12) /S - Resume Sending
13) /D<area> - Delete Echo Area
14) /A<area> - Create Echo Area
15) /C<area:area> - Change Echo Name
9. IMTHINGS
a. IMPORT - Import Net Mail Messages [MQS]
b. INDEX - Rebuild index files [-Q-]
c. KILL - Delete messages from an area [MQS]
1) /A<areaname>
2) /B<board>
3) /D<days>
4) /K<days>
5) /N<number>
6) /Q - Hudson Only
7) /S - MSG/Squish Only
8) /U - Use Default Information
9) /! - Allow All Messages to be Killed
d. LINK - Link Messages in Message Base [MQS]
1) /C - Clean
2) /Q - Hudson only
3) /S - MSG/Squish only
e. MOVE - Move Message Area [MQS]
1) /R<src area>
2) /S<src board>
3) /F<src path>
4) /T<dst area>
5) /D<dst board>
6) /P<dst path>
f. NOTIFY - Send list of linked echos [---]
1) /N - No node manager
2) /P - Notify AreaLink Password
3) /W - Only Warn of Password Expiration
g. PACK - Compress message base [MQS]
1) /B - Keep backup
2) /P - Pack IMAIL.AR
3) /Q - Hudson Only
4) /R - Renumber
5) /S - *.MSG/Squish Only
h. POST - Post message in echo area [MQS]
1) /F<filename>
2) /A<areaname>
3) /B<board>
4) /W<to_who>
5) /R<from_who>
6) /S<subject>
i. RECOVER ....- Unerase messages [-Q-]
1) /A<areaname>
2) /B<board>
3) /U - Automatic Mode
j. SEND ....- Send a file [---]
1) /F<filename>
2) /A<address>
3) /W<to_who>
4) /T<text>
5) /C - Crash
6) /H - Hold
7) /D - Direct
8) /K - Kill/Sent
9) /E - Delete/Sent
10) /Y<days> - Newer than
11) /N<0-15> - Alternate Address or AKA
k. SORT - Sort the Message Base [-Q-]
1) /L - Link Messages after Sort
2) /Q - "Quick" Sort
10. AN OVERVIEW OF ECHOMAIL
a. What is Echo Mail?
b. How it Works
c. Echo Mail Message Control Information
1) Area Line
2) Tear Line
3) Origin Line
4) SEEN-BY Lines
5) PATH Lines
d. Methods of Sending Echo Mail
e. Topology
f. Why a PATH line?
g. Gating of Echo Mail
11. KLUDGE LINES
a. EID
b. FLAGS
1) DIR
2) IMM
3) TFS
4) KFS
5) CFM
6) RRQ
c. FMPT
d. INTL
e. MSGID
f. PID
g. REPLY
h. RESCANNED
i. TOPT
12. BATCH FILE EXAMPLE
13. MISCELLANEOUS INFORMATION
a. A Note about Capability
b. Defaults for Compression/Decompression
1) Compression
2) Decompression
c. Files Maintained by IMAIL
d. Exit Codes
14. IMAIL REGISTRATION SITES
a. Headquarters
b. Australia
c. C.I.S. (ex-USSR)
d. Europe
e. Germany
f. North America
g. Sweden
h. United Kingdom
1. INTRODUCTION
IMAIL is an echo mail processor. In other words, it moves incoming
mail received by your mailer to a local message base and is also
able to forward echo mail to other systems (this is called
TOSSing). It scans the message base for locally entered messages
and will create packets for your uplink and the other connected
systems, so your mailer can transmit them (this is the SCAN
function).
IMAIL is FTSC-compatible, and written for those who use any
combination of the "Hudson" message base (QuickBBS, RemoteAccess or
fully compatible), an *.MSG message base (for example Opus) or the
Squish message base (Maximus). It can be used with mailers which
implement the file attach method of mail transfer (such as
FrontDoor), or with systems which use "flow files" (such as
Binkley). Support for the D'Bridge Queue system is planned for the
next version.
It also features full Zone and Point support, eliminating the need
to use the "fake address" method of sending mail to and from points
(IMAIL however still supports the point net addressing).
If you are new to FidoNet mail processing, we suggest you
familiarize yourself with the documentation for the mailer you will
be using, and read "An Overview of Echo mail", Chapter 10.
2. WARRANTY AND REGISTRATION INFORMATION
This software and anything enclosed in the original archive are
protected by both German and international copyright law and treaty
provisions.
IMAIL is NOT Public-Domain or Freeware, it is released as
Shareware. If you intend to use this program after a trial period
of THIRTY (30) days, you must register your copy of IMAIL or stop
using it.
You are entitled and encouraged to give this program together with
its original documentation to anybody, if you do not change the
contents of the archive or the program itself. Distributing of
modified versions is prohibited.
IMAIL has no restricted features, everything can be used. But
unregistered users only get a minimal support by the developers and
support/registration sites.
Only registered users will get full support.
The base registration cost is US$35.00 for "normal" nodes,
US$30.00 for points. For specific rates, contact the registration
site closest to you, the addresses of which appear in Chapter 14.
When you register, send a cheque or money order to the
registration site, and the registration form you can find either in
the release archive or at the registration sites.
When the registration fee is received, you shall be sent a net mail
message indicating where you can pick up the key. Once you have
received the key file, copy it to your IMAIL "home" directory,
renaming it to IMAIL.KEY. Note: if you copy the file, be sure to
use the /B switch, otherwise it may not be copied correctly.
IMAIL is in no way a crippled program, nor will it stop working
after a certain amount of time. We don't like this concept in
ShareWare programs.
This software is provided AS IS without any warranty, expressed or
implied, including but not limited to fitness for a particular
purpose.
The authors will not be liable for any direct or consequential
damages due to loss of data or any other reason, the person using
the software bears all risk as to the quality and performance of
of the software.
If your local laws do not permit any of the statements made above,
or if you do not agree with any of them yourself, then you are not
licensed to use this program!
We will however do our best to fix any bugs reported to us, as long
as we have enough information to do this.
a. Standard Disclaimer
This product is meant for educational purposes only. Any
resemblance to real persons, living or dead is purely
coincidental. Void where prohibited. Some assembly required.
List each check separately by bank number. Batteries not
included. Contents may settle during shipment. Use only as
directed. No other warranty expressed or implied. Do not use
while operating a motor vehicle or heavy equipment. Postage will
be paid by addressee. Subject to CAB approval. This is not an
offer to sell securities. Apply only to affected area. May be
too intense for some viewers. Do not stamp. Use other side for
additional listings. For recreational use only. Do not disturb.
All models over 18 years of age. If condition persists, consult
your physician. No user-serviceable parts inside. Freshest if
eaten before date on carton. Subject to change without notice.
Times approximate. Simulated picture. No postage necessary if
mailed in Antartica. Breaking seal constitutes acceptance of
agreement. For off-road use only. As seen on TV. One size fits
all. Many suitcases look alike. Contains a substantial amount of
non-tobacco ingredients. Colours may, in time, fade. We have
sent the forms which seem to be right for you. Slippery when
wet. For office use only. Not affiliated with the Red Cross.
Drop in any mailbox. Edited for television. Keep cool; process
promptly. Post office will not deliver without postage. List was
current at time of printing. Return to sender, no forwarding
order on file, unable to forward. Not responsible for direct,
indirect, incidental or consequential damages resulting from any
defect, error or failure to perform. At participating locations
only. Not the Beatles. Penalty for private use. See label for
sequence. Substantial penalty for early withdrawal. Do not write
below this line. Falling rock. Lost ticket pays maximum rate.
Your cancelled check is your receipt. Add toner. Place stamp
here. Avoid contact with skin. Sanitized for your protection. Be
sure each item is properly endorsed. Sign here without admitting
guilt. Employees and their families are not eligible. Beware of
dog. Contestants have been briefed on some questions before the
show. Limited time offer, call now to insure prompt delivery.
You must be present to win. No passes accepted for this
engagement. No purchase necessary. Processed at location stamped
in code at top of carton. Shading within a garment may occur.
Use only in well-ventilated area. Keep away from fire or flame.
Replace with same type. Approved for veterans. Booths for two or
more. Check here if tax deductible. Some equipment shown is
optional. Price does not include taxes. Not recommended for
children. Prerecorded for this time zone. Reproduction strictly
prohibited. No solicitors. No alcohol, dogs, or horses. No
anchovies unless otherwise specified. Restaurant package, not
for resale. List at least two alternate dates. First pull up,
then pull down. Call toll free before digging. Driver does not
carry cash. Some of the trademarks mentioned in this product
appear for identification purposes only. Record additional
transactions on back of previous stub.
3. ACKNOWLEDGEMENTS
IMSETUP makes use of the C eXtended Library (CXL) version 5.2 by
Mike Smedley and the Squish MSGAPI by Scott J. Dudley.
Our deepest gratitude to the Beta Testers, who risked seeing their
message base grunged by our program, and for having had patience
when we released buggy betas.
Very special thanks to:
Fabiano Fabris, Udo Fleckenstein, Mike Hartmann, Henk Heidema,
Roelof Heuvel and Bob Snowdon.
a. Copyrights
These programs are mentioned in this document, and are
copyrighted as follows:
Arc System Enhancement Accociates
Arj Robert K. Jung
Binkley Bit Bucket Software Co
D'Bridge Chris Irwin
FrontDoor Joaquim Homrighausen
IUTIL Andreas Klein
LHarc Haruyasu Yoshizaki
Opus Wynn Wagner III
PAK NoGate Consulting
PKarc/PKpak PKWARE Inc.
PKZIP PKWARE Inc.
QuickBBS Richard Creighton &
Steve Grabilowitz
Maximus Scott J. Dudley
RemoteAccess Andrew Milner
Squish Scott J. Dudley
SQZ J. I. Hammarberg
TosScan Joaquim Homrighausen
XRS Mike Ratledge
zoo Rhaul Dhesi
If we have forgotten someone, or have made any mistakes, our
most sincere apologies! Drop us a line and it will be rectified
for the next release.
4. INSTALLATION
IMAIL is supplied in a single compressed file which should contain
the following files:
IMAIL.EXE The mail processor
IMALNK.EXE The AreaLink
IMPACK.EXE The net mail packer program
IMSETUP.EXE The setup program
IMTHINGS.EXE The external utilities
IMAIL.DOC The documentation
CHANGES.DOC Summary of changes since the last release
IMAILREG.ARJ Information concerning registration.
There may also be a README file which includes last minute
information. Please refer to it before installing.
Copy all the executable files to the same directory. Set the IMAIL
environment variable (see below) to point to a directory where you
want your configuration files to be stored (usually the same
directory as that in which the program "resides", it is known as
the IMAIL "home" directory) and run IMSETUP.
a. Environment Variables
1) IMAIL
An environment variable should be set to point to the
directory containing IMAIL's configuration files. This is not
required, but strongly recommended, in order to avoid
problems in case of errors in your batch file. The variable
may be set by including an instruction such as the following
in your AUTOEXEC.BAT file:
SET IMAIL=C:\IMAIL
Please note that IMAIL and its companion programs do not make
use of any other program's configuration files.
2) POINTNET
If you are a "boss" node and have point running software
which cannot handle 4D addressing, you will have assigned
them a point net (sometimes called a fakenet) address. You
should inform IMAIL of this point net by setting the POINTNET
environment variable, so that TOSS and SCAN can remove
addresses containing the point net from the SEEN-BYs in echo
mail messages.
For example, if you were using a point net of 31339, you
would set the POINTNET variable with:
SET POINTNET=31339
3) TASK
This environment variable is needed in a FrontDoor network/
multitasking environment, it is used for the FrontDoor CRC
semaphore.
SET TASK=99
The variable is used to determine by the program on which
system (in a multitasking/network environment) it is running
when creating the FD 2.10 CRC semaphores. If you use the same
variable on different computers/tasks you will experience
problems.
b. System Requirements
1) Hardware
IBM PC/AT/386/486, or fully compatible
Mono or color display
Hard disk
2) Software
MS-DOS (or PC-DOS) 3.10 or greater
An FTSC-0001 compatible mailer
One or more compression programs, selected from:
ARC by System Enhancement Associates;
Arj by Robert K. Jung
LHarc by Haruyasu Yoshizaki;
PKARC/PKPAK by PKWARE Inc.;
PAK by NoGate Consulting;
PKZip by PKWARE Inc.;
SQZ by J. I. Hammarberg
ZOO by Rhaul Dhesi.
3) Networks and File Sharing
IMAIL has been extensively tested in the NetWare and
Lantastic environments, as well as under DESQview.
IMAIL implements file sharing as "expected" by RemoteAccess.
What this means is that it will open all files in sharing
mode, and will lock MSGINFO.BBS just before writing to any of
the message base files.
Note that SHARE.EXE =must= be loaded in order for this to
work correctly, unless you are using IMAIL in a network
environment, which supports the MS-DOS file sharing
functions.
However, IMTHINGS (beside the LINK function) does =not= make
use of RemoteAccess file sharing. It is expected that message
base utilities will not be run while a user is on line, or
while some other program is making use of the message base.
Damage can result if you try to use IMTHINGS together with
another program.
4) IMAIL Semaphore
IMAIL itself implements a semaphore to indicate when it wants
exclusive access to its configuration files. This is
generally necessary whenever IMAIL (or its companion
programs) need to write to the configuration files.
The semaphore file, called IMBUSY.NOW, is created in the
directory pointed to by the SEMAPHORE environment variable
or, if this is not defined, in the IMAIL "home" directory
(the directory pointed to by the IMAIL environment variable).
Once the configuration files are no longer needed, the file
is deleted.
Please note that the semaphore files are created only if you
are using IMAIL in a multi-tasking or network environment,
where more than one program is likely to access the IMAIL
configuration files at the same time. If you are working in
such a configuration, please set the Multi-Tasking flag in
IMSETUP (see Chapter 5. section a. para 7)).
In this case IMAIL fully supports the multi-tasking/network
capabilities of FrontDoor 2.10 and Binkley. IMAIL indicates
when it is accessing the arcmail bundles for a certain system
and checks whether a session is currently running to avoid
file sharing problems.
c. Upgrading from Previous Versions
If you are upgrading IMAIL from a previous version, please see
the file CHANGES.DOC for information on new features since the
last public release.
If upgrading from 1.20 or 1.21(a), before using any of the other
programs, run IMCVT in the directory in which the IMAIL
configuration files are located. This will upgrade you to 1.35.
Once the conversion is complete, run IMSETUP and go into the
Area Manager. Make any changes you wish and then exit the
manager. This will regenerate the IMAIL.AX and IMAIL.BX (Index)
files, which IMCVT does not do.
5. IMSETUP
The program IMSETUP is used to configure the various options used
by IMAIL. In this chapter, each option will be examined in detail.
If any of the options are not clear, or their meaning and use is
"obscure", you can generally leave them in their default setting.
You can get help in any of the IMAIL support echos, or by sending
net mail to the author or to the support sites listed at the end of
this documentation.
A complete new version of IMSETUP with context-sensitive help and
is in work but not yet ready.
IMSETUP can be given one or more command line options, selected
from the following:
/M Force 'mono' color set
/C Force 'color' color set
/D Force direct screen writes
/S Force CGA snow elimination
Naturally, /D and /S have exactly opposite effects, so it makes no
sense to use them together.
Note: Should you wish IMSETUP to create and/or look for the
configuration files in a directory which is different from the one
in which you ran it, set the IMAIL environment variable to point to
this directory. Otherwise, IMSETUP will look for its configuration
files in the current working directory, whatever that happens to
be.
a. General Configuration
This options leads to another menu which allows various
system-wide parameters to be set. Please read this section
carefully!
1) System Addresses
The "System Addresses" menu allows you to define up to 16
network addresses. The first of the addresses is known as
your primary address. It should be the same as the one
defined as your primary in your mailer and/or BBS program.
The other addresses given are your system's AKAs (or
aliases).
Addresses should be given in the form:
zone:net/node.point
Addresses may be in different zones, and even in different
domains (or networks). At least the primary address must be
specified.
Note that if you make changes to the list of addresses in an
existing configuration, it is advisable that you then enter
the Area Manger to check your Origin and SEEN-BY addresses.
2) Domains
In this menu the domain(s) to which you belong are specified.
The word "domain" is used to distinguish between different
amateur networks such as SIGnet and FidoNet.
Here, you should indicate the domains of which you are a
part, the zones belonging to these domains, your AKAs in this
domain, and the outbound directory for each domain. You
should also specify those domains to which you do not belong,
but with which you exchange mail.
IMAIL uses this information for MSGID kludges when generating
net mail messages. More importantly, outbound mail for a
specific domain will be placed in the directory you specify
here.
If you are in doubt of which zone you belong to, or which
domain, please contact your nearest Coordinator or Host.
- Domain
Specify the name of the domain. No universally accepted
standard seems to exist, but some examples are: FidoNet for
zone 1 through 7, intlnet for zone 56 through 58, and so
on.
- Outbound Directory
If you belong to more than one domain, it might be wise to
keep the outbound mail for each domain separate. In this
case, specify each directory here. In Binkley mode, mail
for points will be place "under" these directories.
If this field is left empty, IMAIL will default to the
directory specified as Outbound Net Files (see below).
- Zone List
Specify all the zones which belong to this domain. For
example, for intlnet, these would be 56, 57, 58 and 59.
- AKA List
Select those of your addresses which belong to each domain.
3) Subdirectories
In this menu, specify the paths to the various files IMAIL
needs to use during execution. Most of the fields are
required.
When specifying subdirectories, you may omit the trailing
backslash.
- Hudson Message base
Specify the path to the Hudson format message base files.
These message base files are searched for outgoing messages
when you run the IMAIL SCAN function. If you are not using
a Hudson message base, this field may be left empty.
- Net Mail Message
The path to where your mailer stores its net mail message
(*.MSG) files. IMAIL will use this when searching for
existing file attaches, when creating new file attach
messages, or when it generates outgoing net mail of its
own.
This field is required.
- Inbound Net Files
This is where your mailer stores inbound compressed mail
files and packets. IMAIL will look here when you run the
TOSS function.
NOTE: Please do =not= run IMAIL from this directory!
This field is required.
- Temp Inbound Packets
This directory is used by IMAIL TOSS to store packets as
they are extracted from ARCmail files, and before they are
processed.
This field is required.
- Outbound Net Files
This subdirectory is where your mailer normally looks for
outbound compressed files. These files may be generated by
all of IMAIL's functions.
This CANNOT be the same subdirectory as the Inbound Net
Files directory, otherwise IMAIL will process the files as
if they were FOR your system.
Note that if you are running in a Binkley environment, this
will be the subdirectory in which outgoing mail for your
PRIMARY zone will be placed. Mail addressed to other zones
will be placed in other subdirectories, having the same
root name as the one specified in this field, but with a
3-digit numeric extension. For more details, please refer
to the Binkley documentation.
This subdirectory will be used whenever you do not specify
an outgoing subdirectory in the Domains menu (see above).
This field is required.
- Temp Outbound Packets
This is the directory in which IMAIL and IMPACK will build
outbound packets prior to compression into ARCmail files.
This directory must NOT be the same as your mailers
temporary packet directory, nor may it be the same as
IMAIL's Temporary Inbound Packet directory. If omitted,
IMAIL will default to the Outbound Net Files directory.
This field is required.
- Semaphore Directory
This directory is used to store and create all semaphores.
Also the mailer rescan semaphore as defined below will be
created in this directory.
For FrontDoor 2.10, this is the semaphore directory as
defined in the FrontDoor setup, for FrontDoor 2.02 this is
the directory where the FD environment variable points to.
- Netmail Semaphore File
If IMAIL should tell your mailer that netmails have been
created or updated, you should specify the name of the ne-
cessary semaphore file here. IMAIL will create it in the
semaphore directory if necessary.
For FrontDoor this is FDRESCAN.NOW
- IMAIL Log File Name
Is you wish IMAIL to log its activity to file, you may
specify the name of the log file here. If a path is not
specified, the file will be written to the current working
directory.
- Auto-Added Areas Log
If you have enabled the Auto-Add feature (see section 7
below), you can have IMAIL create a text file listing the
echo areas it creates. This file will also be written to by
AreaLink if it creates any new area records. Specify just
the file name, with no path; the file will be written to
the directory pointed to by the IMAIL environment variable.
Here a small batch which allows you to post a notification
whenever a new echo has been arrived.
%IMAIL% is the IMAIL environment variable.
NEWAREAS.LOG is the name as entered in IMSETUP for the auto-
added areas log.
AREA.NEW is used to store the file after posting it.
REM BATCHFILE, POST A MESSAGE CONTAINING NEW AREA'S ONCE...
REM
IF NOT EXIST %IMAIL%\NEWAREAS.LOG GOTO NONEWMAINT
%IMAIL%\IMTHINGS POST /F%IMAIL%\NEWAREAS.LOG /ALOCAL.SYS
/WSysop /SNew_areas
COPY %IMAIL%\AREA.NEW+%IMAIL%\NEWAREAS.LOG %IMAIL%\AREA.NEW
DEL %IMAIL%\NEWAREAS.LOG
:NONEWMAINT
REM
-----------[ END ]----------
- Log Format
If you have specified that IMAIL should create a log file,
here you may indicate how much information you wish to be
written to the log file.
There are two possible choices:
N: Normal. This will log only important information,
errors and final stats to the log.
V: Verbose. Complete information will be logged,
including all echo areas scanned or tossed.
4) AreaLink Options
The options in this menu regard IMAIL's area manager, called
AREALINK. This function will do for IMAIL what AreaFix does
for other systems.
Your downlinks will be able to request that new areas be sent
to them, or that areas no longer be sent. Besides this, they
may request information on which echos are available to them,
and have a list of the echos they are currently receiving. In
registered copies of IMAIL, AreaLink can also request areas
not available on your system from your uplinks, thus further
automating your system.
For information on how AreaLink is used, see Chapter 8.
- Keep AreaLink Reply
If you enable this option (set it to 'Y'), then IMAIL will
not mark its outgoing messages as KILL/SENT. In other
words, once the message has been sent, it will remain in
your net mail directory for you to see it. Note that this
is valid only for the messages generated by AreaLink, but
not for those it has processed.
- Keep AreaLink Request
If you enable this option (set it to 'Y'), then IMAIL will
not delete incoming requests, they will remain in your net
mail directory for you to see it. Note that this is valid
only for the messages processed by AreaLink, but not for
those it has created.
- Password Expiration Days
This allows you to specify that your downlinks should
change their AreaLink password after a specified number of
days. If set to 0, this feature is disabled. AreaLink will
still allow a system to use AreaLink if the deadline has
passed, but it will add a warning saying that the password
should be changed. A sysop may change his password
automatically by using the %PWD meta-command; see Chapter
8. section b. for more information on this.
- AreaLink Help Text
In this field you may specify the name of a text file to
send if a user requests help with AreaLink (see Chapter 8.
Section b.) If no name is specified, then AreaLink will
respond to a request for help by saying that none is
available. If the file does not exist, IMSETUP will prompt
you for the creation of a default help text.
If a file is specified, it must be located in the directory
pointed to by the IMAIL environment variable, or in the
directory which is current when IMAIL is run.
- Allow Forward Link Requests
This allows you to specify whether AreaLink should execute
forward link requests to one of the uplinks defined in the
data section.
A detailed explanation of Forward Link Requests can be
found below.
- Remote Maint Help Text
In this field you may specify the name of a text file to
send if a user requests help with AreaLink (see Chapter 8.
Section b.) if this users has remote maintenance rights on
your system. If no name is specified, then AreaLink will
take the file specified under AreaLink Help Text.
If a file is specified, it must be located in the directory
pointed to by the IMAIL environment variable, or in the
directory which is current when IMAIL is run.
- Unlink Requests
Here you can specify whether AreaLink should check areas
(whenever one user requests to unlink from an echo and at
least once per day after midnight during the statistic
update) whether you have areas with only one system in the
list of linked systems.
If this single system is also listed in the forward link
requests data section, then IMAIL marks this area unlinked
and sends an unlink request to this system.
You can specify whether this function should only affect
passthrough echos or all echos. Moreover you can exclude
single areas from this function in the Area Manager.
Using this feature you can prevent echos from being tossed
into the NUL device and consequently reducing the amount of
mail.
The Area Manager allows you to exclude single area from
this function (Unlink Req).
- Forward Link Requests Data
Forward Link Requests are a method to have IMAIL
automatically request areas from your echo uplinks. If
AreaLink processes a request for an echo area which is not
listed in your configuration, it will search the files you
have defined for this area. If found, it will send a
request for that area to the system listed. See Chapter 8.
section d. for more information.
In the "Uplink" column, specify the network address of the
system to which the request should be sent. The "Areas
file" column indicates the file name of an AREAS.BBS type
file containing the list of echo areas available on that
system.
In the "Areas File" column, indicate the name of the
AREAS.BBS-type file which AreaLink should search. This file
should be located in the directory pointed to by the IMAIL
environment variable (if set), or in the directory from
which IMAIL is run if the IMAIL variable is not set.
The format of the AREAS.BBS file is the same as that used
by most programs. Each line is composed of three fields.
The first is a board number or a subdirectory name, and
must be present in order for IMAIL to correctly extract the
information it needs. The second field is the name of the
echo area. The third field is the list of export addresses;
this field is not required. Note that IMAIL will discard
the first line of the file, as well as any beginning with a
semi-colon (';').
The "Send to" column should contain the name of the program
to which the net mail message will be sent, such as for
example AREAFIX, AREAMGR or IMAIL. If you are unsure of
what to put here, contact your uplink. Note that AreaLink
will behave a bit differently if AREAFIX is specified
instead of another name.
The last column, "Password", indicates the password the
uplink has assigned to your system. You will need to
contact your uplink to have one assigned to you.
5) Product Codes
This small and apparently insignificant menu is really very
important. It allows you to indicate programs which produce
Type 2+ information in the packet header. (For more
information about this and the Capability Word, see Chapter
13. Section a.)
With this information, IMAIL TOSS will know how to correctly
process incoming mail. If it finds a packet with no
capability word, it will scan the list of product codes
defined in this menu to see if the packet really contains
zone and point information. If the packet was produced by one
of the programs whose code is listed here, then it will treat
the packet as it is fully Type 2+. Otherwise it will be
treated as "Stone Age".
Note that the product codes must be entered in hexadecimal.
6) No Import
In this screen, you specify the names of persons (or
programs) which IMTHINGS IMPORT should ignore. For example,
if you wish messages addressed to AreaLink not to be imported
into your net mail area, you would specify AREALINK here
(case is not significant). Similarly, if you do not want net
mail addressed to you to be imported, specify you name in
this menu. See Chapter 9. Section a. for information on
IMTHINGS IMPORT.
7) Other Parameters
This menu is a "catch all" for various options which control
how IMAIL operates.
Most of the options available are of the "on/off" type; in
other words, specifying 'Y' will enable the option, while 'N'
will disable it.
- ARCmail 0.6 Compatibility
If this option is set, IMAIL will generate compressed mail
bundles that conform to the ARCmail 0.6 naming standard
when sending to systems marked in the node manager as
"Stone Age", or to systems not listed in the node manager.
Systems listed as "Type 2+" will have a special naming
scheme. (See Chapter 5. section e. for information on the
Capability Word).
If this is set to "No", then IMAIL will always use its own
internal method for the naming of outbound compressed
files.
Note that the setting of this flag will be ignored when
IMAIL generates ARCmail to point addresses.
- Number of Dupe Records
This field indicates how many dupe records IMAIL will save
in the file IMAIL.DP for dupe checking. If the number is
set to zero, no dupe checking will be performed; this will
make a bit IMAIL faster, but certainly less secure.
- Auto-add New Areas
Enable this if you want IMAIL to automatically create a new
area record whenever an echo mail message arrives in an
undefined area. The area record created will be marked as
Auto-Added; the node which originated the message (or
better, your uplink) will be inserted in the export list
for the new area.
If you allow the creation of these areas, please check the
Node Manager (to configure the system which are allowed to
create areas) and the Group Manager to specify some default
settings for these new areas.
- New Areas Passthrough
If you want all newly created areas to be marked as
passthrough, so that they are not imported into your
message base, then set this option to Yes.
- New Areas Group
This is the group to which all newly created areas will be
assigned. Be careful with this one, since if you set it to
a group to which other systems have access, then they will
be able to link to the new areas without your knowing about
it.
This setting is overridden if a new areas group is defined
for a system in the Node Manager (see Chapter 5. section e.
para 14)).
- Multi-Tasking
If you are running in a multi-tasking or network
environment, then set this to Yes. It will force IMAIL to
make more checks for locked files; the IMAIL semaphore will
only be created if this flag is enabled.
- Semaphore Time-out
Setting this to a non-zero value will tell the IMAIL
programs that if IMBUSY.NOW is detected, they should wait
the specified number of seconds before timing-out.
- Max Packet Size
With this option, you can specify the maximum size of the
packet files (*.PKT) that IMAIL will create. Use this if
your up and/or down links are short on disk space.
The number should indicate a size in kilobytes. If a zero
(0) is specified, there will be no limit imposed.
- Max Arcmail Size
Setting this to a non-zero value tells IMAIL not to add
further arcmail PKTs to a compressed arcmail bundle if its
size is bigger than specified.
Using this feature you can limit the size of the arcmail
bundles and therefore reducing the time which is needed to
transfer the bundle again if a session was interrupted.
- Dupe Ring Handling
This option tells IMAIL how to handle echo mail if one of
the downlinks is already listed in the SEEN-BYs of this
mail. You have four options:
N Disable this check
W Write a warning to the logfile
Z Do not export to this downlink except in
zonegated echos
K Do not export to this downlink
For further information on echo mail topology and related
problems see the section about echo mail below.
- Max Message Size
Here you can specify the maximum message size of messages
generated by IMAIL. The value entered here should be around
10-15 kB. If it is too small, IMAIL will produce lots of
mails and if it is too high, some mail processors will get
trouble with these mails.
Currently this value is only used by IMALNK and by IMTHINGS
POST.
- Environment
This field will accept either a 'B' or an 'F', which
indicate respectively Binkley or FrontDoor.
By selecting Binkley, IMAIL will create "flow files" in
your outbound directory, containing lists of files which
the mailer should send.
If instead you select FrontDoor, IMAIL will generate file
attach messages. This method can be used for other mailers
which use file attach messages rather than "flow files".
This setting will also control the style of the IMAIL log
file.
- Truncate/Delete Sent ARCmail
Normally, when ARCmail has been sent by your mailer, the
file is truncated (that is, its length is set to zero).
This allows IMAIL to generate a new file name if it
processes more outbound mail for the same system.
If for any reason you want the mailer to delete the file
instead of truncating it, set this option to 'D'. However,
it is NOT suggested that this be done! Use this option with
caution!
- Single Bundle Extract
When enabled, IMAIL will try to extract one bundle or
packet at a time from compressed mail files.
This option should be used only on systems where disk space
is tight, because it will slow down the execution of the
program noticeably.
Currently, this option will extract the packets in a single
compressed file before processing, but it will extract ALL
the packets. In a future version, IMAIL will be able to
extract a single packet from the compressed file, process
it and then go on to the next.
- Send Return Receipt
If a net mail messages arrives with the "Request Return
Receipt" flag set, IMAIL will automatically generate a net
mail message to the originating system, stating that the
message arrived.
Note that the FLAGS RRQ kludge is not supported by IMAIL in
the current version. Since the message attribute is
defined, we decided to support it.
- Forward For Other Systems
If this option is enabled, IMAIL will forward mail
addressed to other system, by simply moving the packet to
your outbound packet directory. Otherwise, it will process
the packet as if it were addressed to you. Thus your normal
mail routing commands can take effect.
Note that if this option is disabled, it will become
impossible to route echo mail packets, because they will be
processed by IMAIL, and the messages will probably end up
in your Bad Message board.
- Keep Outgoing Packets Open
This option is potentially dangerous, as it tells IMAIL to
keep packets open during TOSSing. It will bring about a
certain speed increase, but if there is a power failure, it
may result in many lost clusters .. and much lost mail.
- Swap Options
Before calling any external programs (compression or
decompression programs), IMAIL and IMPACK will swap most of
themselves out of memory, to leave room for the program
called. Once the program has completed, IMAIL (or IMPACK)
will be reloaded into memory and continue execution.
E - EMS. If you specify EMS, IMAIL will try to allocate
a certain number of EMS pages to try to swap itself
into. If this fails, it will swap to disk
X - Extended memory. If you specify this option, IMAIL
will try to swap to extended memory. If this fails, it
will swap to disk. (Note: Extended memory here refers to
XMS; in other words, you will need a driver such as
HIMEM.SYS in order for it to work.)
B - Both. This indicates that IMAIL should try both EMS
and extended memory, in that order. If both fail,
swapping to disk will occur.
D - Disk. IMAIL will swap its overlay buffers to disk
when needed. This is the default, and also the slowest
of the options.
- Add Via Lines
Registered users of IMAIL may disable the insertion of a
Via kludge in forwarded net mail by setting this option to
No.
- Use FTSC Product Names
This options controls whether or not IMAIL TOSS will
display product names when processing inbound packets of
mail. If enabled, TOSS will show the name of the program
used to create the PKT file; otherwise, it will simply show
the program's product code.
In order to use this option, you must have a file called
FTSCPROD.??? available in the IMAIL home directory; if
found, IMAIL will compile this file into IMAIL.PR (after
which you may remove the FTSCPROD file). If the FTSCPROD
file is not available for compilation, IMAIL will behave as
if you had set this option to No.
The newest version of the FTSC product code list is distri-
buted by the FidoNet Standard Committee, it can be requested
at many systems (FTSCPROD.A??).
- Check for personal mail
While tossing, IMAIL has the possibility to check whether
there are new messages for the user defined as sysop. You
have four options
N Disable this feature
L Write a log entry if a message was found
M Create a netmail containing the headers of
the new messages
C Copy each new message to a special area
The last option requires a special area PERSMAIL defined
in the Area Manager.
- Add new systems to IMAIL.ND
With this switch you can prevent IMAIL from adding unknown
nodes (from which you received PKTs) to the Node Manager.
Especially when working in a Binkley environment (where
IMAIL also handles the netmail) it is not very useful to
have every system in your Node Manager which sent you a
crash mail.
- Unlink autoadded areas
This switch controls the Unlink Req switch when IMAIL
autocreates new area. You can select here whether new
area should be unlinked by IMAIL automatically when the
conditions for unlinking match.
- Before Toss
This option was included to allow sysops to run a "mail
mangler" on extracted packets before IMAIL processes them.
If you wish to use this feature, then specify the full path
name of the executable program here, including arguments.
If you need to give the name of the PKT file, then place a
%P on the command line. For example:
MY_PROG.EXE %P /ZAP
The %P will expand to the name of the packet file.
Note that the program called MUST NOT delete the packet
file!
- Sysop Name
This field is required, as it is used by IMAIL for the
generation of automatic messages and so on. IMAIL also uses
it to validate your registration key.
- Default Origin
This is the Origin line which IMAIL will use if one or more
of your echo areas have no Origin line defined.
8) Group Manager
The Group Manager has two functions. It allows you to assign
descriptions to the various groups which can be accessed from
the Area Manager and from the Node Manager. Moreover you can
define the default settings which should be used if a new
area arrives and is automatically created by IMAIL.
You can assign each system which is allowed to create areas a
"New area group". Each area created by this system will get
this group and the defaults of this group as defined in the
Group Manager.
- Comment
Here you can enter a short description of the group, it is
used when you select groups in the Area Manager and in the
Node Manager.
- Msg Base and Path
This feature allows you to control the areatype a new area
gets: Passthrough, QuickBBS, Squish and *.MSG.
If you select QuickBBS IMAIL tries to find a free board in
IMAIL.AR and assignes this to the new area (be careful that
all areas used are defined in IMAIL.AR).
If you select Squish or *.MSG, IMAIL calculates a CRC-32
from the areatag and creates either a new squish area in the
directory specified in Path or a new directory under the
directory specified in Path using this CRC for the filename/
directory to prevent collisions with already existing areas.
- Other switches
The following switches only control the default settings of
a new entry created by IMAIL. They are described in the
Area Manager section:
Secure, # Days, # Msgs, Hide, Unlink Req, Mandatory,
Read Only, Tiny-Seens, Zone-Gate, Keep-Seens
b. Compression Programs
In this section, you may specify the programs, along with their
parameters, to use in the creation of outbound compressed mail.
When you run IMSETUP for the first time, it will show defaults
for the following programs:
ARC, Arj, LHarc, PKARC/PKPAK, PAK, PKZip, SQZ, ZOO.
The default parameters are listed in Chapter 13. section b.
If you wish, you may add other programs of your own choice, but
do not leave any entries empty. Instead, if you do not intend to
use one (or more) of the predefined programs, replace it with
one that you do use.
Of course, all of the programs you intend to use must be present
somewhere in the DOS path.
You will then select which of these programs to use for mail
compression on a per-system basis, in the Node Export Manager
(see Section e.). If IMAIL needs to compress mail for a system
not listed, it will use the first of those given in this menu.
c. Decompression Programs
IMAIL automatically recognizes compressed files produced by the
following programs:
ARC, Arj, LHarc, PKARC/PKPAK, PAK, PKZip, SQZ, ZOO.
In this menu, you may change the name and parameters which will
be executed when compressed mail files are identified. The
default parameters "preinstalled" in IMSETUP are listed in
Chapter 13. section b.
It is also possible to define a program which should be invoked
if IMAIL is not able to determine the type of compression used
to create an ARCmail file. If this entry is not defined, IMAIL
will simply ignore the file.
Be VERY careful when changing these items, for a mistake might
produce very unexpected (and often unwanted) results. And
certainly do NOT try to use one program instead of another. A
compressed file identified as having been created by LHarc, for
example, cannot be decompressed by ARC!
If possible, have all of the decompression programs somewhere in
the DOS path, unless you are absolutely certain that you will
not be getting mail compressed by one or more of them.
d. Area Manager
The Area Manager is one of the most important parts of the
program, and also controls most of what IMAIL does.
When you first run IMSETUP, no message areas are defined. You
will see a screen with many different fields, all empty or set
to certain default values. These fields will be explained in a
moment, but first the editing keys.
1) Editing Keys
The following keys will allow you to edit, add, delete or
find area records. They are:
- F1: Edit
The F1 key allows you to edit the current message area
record (ie. the one currently being displayed). For the
meaning of each of the fields, see below.
If at any time during editing you wish to abort, simply
press ESC, and nothing will be saved. The same is true if
you were adding an area: it will be "forgotten".
- F2: Find
Pressing F2 brings up a window in which you may specify an
area name. If the area is found, it will be displayed. Wild
cards may be used: * expands to 0 or more characters, while
? will match any single character. The record may then be
edited with F1. Note that a wild card search is slower than
one in which the full area name is specified.
- F3: Global
If you need to make global changes to the area information,
pressing F3 will bring up the Global Edit menu. From this,
it is possible to edit the origin lines, origin addresses,
or to add, delete or replace systems in the export list.
In each case, the changes will be made on a per-group
basis. One or more groups may be specified, and the
modifications will be made for all echo areas which belong
to the selected groups.
To close the Global Edit menu, press ESC; you will be
returned to the main Area Manager screen.
- F4: Browse
The browse function will allow you to examine a list of all
the currently defined areas, and to move to a specific
record. The window shows some information about each area.
For example, an entry might read:
TEST_ECHO T:S G:X
The first field is the name of the area. This is followed
by the type of the area (Q for Hudson, M for *.MSG or S for
Squish), and by the group to which it belongs.
Autoadded areas area indicated with an [A], unlinked areas
with an [U].
- F5: Copy Area
The F5 key allows you to create a new echo but in opposite
to Ins it takes over some data from the current record
(like group, flag settings, downlinks).
- F6: Echo flow statistics
Pressing F6 pops up a small window which allows you to
check the current echomail flow information for the current
area.
- F10: Save
The F10 key is used to exit the Area Manager, saving any
changes made. Note that if IMSETUP detects the presence of
the semaphore IMBUSY.NOW, it will wait until the semaphore
has been removed before saving.
- Ins: Add
Adds a new message area, and takes you into editing mode.
Added records are automatically inserted into the list so
that it is maintained in alphabetical order.
Note that this function will not be available if IMSETUP
detects the presence of IMBUSY.NOW in the IMAIL "home"
directory.
- Del: Delete
Deletes the current message area. You will be asked for
confirmation.
- Home: First
Takes you to the first message area (they are sorted in
ascending alphabetical order).
- End: Last
Takes you to the last message area.
- ESC: Exit
ESC is used to exit the Area Manager, abandoning any
changes made. You will be asked if you are sure that you
want to abandon the changes; if you reply 'N', you will be
returned to the Manager.
- PgUp/PgDn: Previous/Next
The PgUp and PgDn keys move between the area records. Once
you have found the one you are looking for, you may edit it
with F1. (Note that the arrow keys have the same effect as
PgUp and PgDn.)
2) The Message Area Record
What follows is a description of the individual fields of the
message area record, and how they are used and changed.
All fields are required unless stated otherwise.
- Area Name
This is the name of the message area, sometimes called
"Area Tag". The name may be up to 50 characters long; it
will be forced into upper case. Special characters such as
'-', '_' and '.' may be used, but no spaces may appear.
Please be sure of the spelling of the name, since it is
used to identify into which area (board or path) an
incoming message should be tossed.
It is not possible to define two areas with the same area
name. IMSETUP will show a warning message, and you will be
prompted to correct the name. This is to prevent
cross-linked areas.
- Comment
Here you may enter a brief description of the area. This
description is used by AreaLink and IMTHINGS NOTIFY when
generating lists of the areas you have available, and may
also help remind you of the topic or purpose of the message
area.
Note that if the area was auto-added by TOSS or by
AreaLink, the comment will be set to something like
"Area autoadded by <node> on <date>"
IMAIL tries also to determine the description from the for-
ward link request file (if defined).
This field is optional.
- Origin Line
Here you may specify up to 63 characters which will be used
as the origin line for the area if it is an echo area (see
Chapter 10. for more information on Origin lines).
To this will be prefixed the string
* Origin:
and your origin address (see below) will be appended. The
total length must not exceed 79 characters.
If you forget to define this field, the default origin line
will be used. Note that if the BBS or editor program used
to write an echo message already adds an origin line, the
one defined here will not be used.
- Active
This by default is set to 'Y', which means that the area is
active. If set to 'N', IMAIL will behave as if the area had
not been defined.
This will allow you to disable an echo area for any reason
you may wish, without having to actually delete it, and
later re-enter it.
In opposite to unlinked areas, inactive areas are ignored by
AreaLink and cannot accessed by any downlink.
- Group
A letter between A and Z which identifies the group to
which this message area belongs.
Groups are used primarily by the AreaLink function to
indicate which nodes may request links to which echo areas.
For more information on this, see Section e., and Chapter
8.
If the area was auto-added by TOSS or AreaLink, this field
will be set to the group specified in the Node Manager's
New Area Group field (for the node which created the echo),
or to that specified in the Other Parameters menu, or to
'?' if neither of these are defined. In the last case, it
should be edited to the correct value.
You can access the Group Manager via F6 which allows you to
select one of the predefined groups.
- Secure
If enabled, IMAIL will check the address of the system
which sent the message in this area. If it is among the
export nodes listed in the Export List (see below), it will
be imported and processed; otherwise, it will be tossed
into your Bad Message Board.
- Msg Base Type
Here you indicate the message base (format). Possible
choices are 'Q' for Hudson (QBBS or RemoteAccess), 'M' for
*.MSG, or 'S' for Squish.
- Type
In this field, you will indicate the type of message area.
You may specify that an area is Echo (E), Local (L), Net
Mail (N) or Passthrough (P). In this way, you may include
ALL of your message areas in IMSETUP. For the purpose of
handling echo mail, only those areas which are of type Echo
will be considered.
Local areas will be ignored by all IMAIL functions (but not
by IMTHINGS), but will ensure that you do not use a board
number twice. Net mail areas are used by the IMPORT
function of IMTHINGS. Passthrough areas indicate that there
is no corresponding board number or path into which mail
will be TOSSed. Echo is similar to Passthrough, except that
mail arriving in that area will also be imported into your
local message base.
- Board
If the area is of type Hudson, then in this field you
should specify the board number corresponding to the
message area.
The board number may be between 1 and 200 inclusive (the
upper limit is imposed by QuickBBS/RA). The number 0 is
used by IMAIL to indicate a passthrough area (see below).
IMSETUP will not let you use the same board number twice,
because you would be cross-linking echo areas. If you press
F4, a list of all unused board numbers will be shown, and
you may select one from it by pressing ENTER. If you are
changing the board number, the highlight bar will be placed
on the currently defined board number; ESC will allow you
to retain the current definition.
TOSS uses this number when importing echo messages, since
the QuickBBS/RemoteAccess message bases contain no
indication of the area name. Similarly, SCAN uses this to
derive the name of an echo area when exporting mail.
- Path
If the message area is of type *.MSG or Squish, then in
this field you should specify the directory or path name of
the message base.
If the area is of type *.MSG, the directory in which the
the messages will be placed should be specified. For
Squish-type areas, specify the directory and the base file
name of the area (ie. directory plus file name without
extension).
- # Days
This item is used by IMTHINGS KILL /U (see Chapter 9.
Section c.) to determine which messages to kill: it will
mark as deleted any messages older than the number of days
specified here. If this field is left at zero, no messages
will be killed, unless the "# Msgs" field below is
specified.
The maximum value which can be entered in this field is
255.
If the area is marked as Passthrough, this field has no
meaning.
- # Msgs
This is used by IMTHINGS KILL /U (see Chapter 9. Section
c.) to determine how many messages to leave in this board.
If this field is left at zero, it will be ignored, and no
messages will be killed, unless the "# Days" field (see
above) is specified.
Naturally, if the area is Passthrough, this field has no
meaning.
- Hide
Enable this option if this area should not be displayed in
any AreaLink report of available areas. Moreover it cannot
be linked with a wildcard request.
- Unlinked
Together with Unlink Request, this field control the unlink
status for the current area. If this field is set to yes,
IMAIL has unlinked this area after the last downlink has
unlinked it from your system and the remaining system was
listed as uplink in the Forward Link Request Manager.
The echo will still appear in your list of available areas
and if a system requests this area, IMALNK automatically
requests this area from your uplink again.
- Unlink Request
If this option is set to N the unlink check is disabled
for this area, so it will remain linked to your system.
- Mandatory
If you set this field to yes, no downlink can unlink from
this echo using the AreaLink functions. This can only be
done manually.
- Read only
If this option is enabled, every system linking this area
gets an export only flag (which can be removed manually by
the sysop). This flag prevents unauthorized downlinks from
posting messages in restricted (read only) areas.
- Tiny-Seens
Enable this option if you want to strip all the SEEN-BY
information from an incoming echo message before it is
re-exported.
In this case, the outgoing message will contain only the
SEEN-BYs of your downlinks. Note, however, that if the area
is not marked as passthrough, and if the Keep-Seens option
(below) is active, the message will be imported with the
original SEEN-BY information.
- Zone Gate
This field is similar to the Tiny-Seens field (above). It
indicates that IMAIL should strip all information from the
SEEN-BY line when exporting to a system which is in a
different zone, except for your address and that of the
downlink.
Note that when the message is imported in your message base
(if the area is not passthrough) the original SEEN-BY lines
will be preserved.
- Keep-Seens
Enable this option if you want to import the SEEN-BY
information into your message base. If disabled, the
SEEN-BY lines will be stripped from the message.
- Origin Address
Pressing F1 while editing an area will allow you to choose
the address to use in the Origin line of the message.
You will be presented with a window containing a list of
all the addresses defined in the "System Addresses" menu;
select one of these.
This address will also be used in the PATH line of the echo
message, as well as in the list of SEEN-BYs.
Note that only the net and node numbers will be placed in
the SEEN-BYs and PATH lines; the use of zone and point
numbers is not accepted. However, IMAIL is able to parse
zone and point information from these lines, if found.
- Seen-Bys
Pressing F2 while editing an area will allow you to choose
one or more addresses to add to the SEEN-BY line for that
area.
If you do not select any addresses, then the one specified
as "Origin Address" will be used.
Note, as above, that zone and point numbers will not be
placed in the SEEN-BY lines generated by IMAIL.
- Export List
Pressing F3 will bring up the Export List Manager. Here,
you may specify up to 60 systems to which this echo will be
exported. At least one node must be defined to TOSS or SCAN
to/from the area.
In this menu, you may also indicate that a system is
"Export-only" or "Import-only". "Export-only" means that
IMAIL will export mail to this system, but will not accept
incoming mail, in this area, from this system.
"Import-Only" indicates that IMAIL will accept incoming
mail from the system, but will never export to it.
It is also possible to see whether a node has been marked
as "Paused", and to toggle this flag (see Chapter 8.
section b.).
3) Special boards
- Bad Messages
Messages flagged as "bad" will be tossed into this message
area. These include echo mail messages arriving from
unlisted systems when "Secure" mode is active for that
area, as well as echo mail in unrecognized areas.
You should first choose if you want the area to be of type
Hudson (Q), *.MSG (M) or Squish (S). If you select Hudson,
then you must supply a valid board number; otherwise, you
should specify a path name.
This record is required, they hardcoded areatag is
BADMAIL.
Note: this area should NOT be used for anything except
"bad" mail! If you post messages into this board, there is
a distinct possibility that the messages will be sent to
other systems should any areas be automatically added.
- Dupe Messages
This message area is the one into which all messages
flagged as duplicates will be tossed. It may be the same as
the one defined a Bad Message Area (see above), or a
different area. If not defined, dupes will simply be killed
(deleted).
As with the Bad Message Area, first select the type of the
message area (Hudson, *.MSG or Squish), and then the board
or path.
The hardcoded areatag for this record is
DUPES.
Note: This board should not be used for anything except
duplicate messages (or "bad" mail, if set to be the same as
the Bad Message Board).
- Personal Message Board
IMAIL can check the echo mail while tossing for new mail
for the person defined as sysop in IMSETUP. If you enable
this feature you can select that these mails are copied
into a special board, the Personal Message Board.
The hardcoded areatag for this record is
PERSMAIL.
Note: This board should not be used for anything except
duplicate messages (or "bad" mail, if set to be the same as
the Bad Message Board).
e. Node Export Manager
The Node Export Manager is used to specify information regarding
the systems to which you normally export mail, including which
program will be used to compress outbound mail for the system,
as well as what type of file attach to generate.
1) Editing Keys
The following keys will allow you to edit, add, delete or
find node records. They are:
- F1: Edit
The F1 key allows you to edit the current node record (ie
the one currently being displayed). For the meaning of each
of the fields, see below.
If at any time during editing you wish to abort, simply
press ESC, and nothing will be saved. The same is true if
you were adding an entry: it will be "forgotten".
- F2: Find
Pressing F2 brings up a window in which you may specify a
node number. If the address is found, it will be displayed.
It may then be edited with F1.
- F4: Browse
The browse function will allow you to examine a list of all
the currently defined nodes, and to move quickly to a
specific record. The window shows some information about
system. For example, an entry might read:
27:1331/1 C ANP
The letter following the node address indicates the status:
H means Hold, C is Crash, while N is normal. The letters
following are the groups to which that system has access.
- F5: Copy Record
- F10: Save
The F10 key is used to exit the Node Manager, saving any
changes made. Note that if IMSETUP detects the presence of
the IMAIL semaphore it will wait until the semaphore is
removed before saving.
- Ins: Add
Adds a new entry, and takes you into editing mode. Added
records are automatically inserted into the list so that is
it maintained in order.
Note that if IMAIL detects the existence of the IMAIL
semaphore it will not allow this function to be used until
the semaphore has been removed.
- Del: Delete
Deletes the current record. You will be asked for
confirmation.
- Home: First
Takes you to the first record (they are sorted in ascending
alphabetical order).
- End: Last
Takes you to the last node in the list.
- ESC: Exit
ESC is used to exit the Node Manager, abandoning any
changes made. You will be asked if you are sure that you
want to abandon the changes; if you reply 'N', you will be
returned to the Manager.
- PgUp/PgDn: Previous/Next
The PgUp and PgDn keys move between the records. Once you
have found the one you are looking for, you may edit it
with F1. (Note that the arrow keys have the same effect as
PgUp and PgDn.)
2) Address
Here you specify the address of the system. The Zone, Net and
node are required. If no point is specified, it will default
to 0.
3) Sysop
This field allows you to specify the name of the sysop of the
system. It is used for purely cosmetic purposes, by AreaLink
and IMTHINGS NOTIFY, when generating net mail messages, and
so is not required.
4) Domain
If you press F1 while editing, it will allow you to specify
the domain to which the system belongs. This is very
important in multi-domain environments, and when you have
different outbound directories for each domain (see Chapter
5., Section a., para 2) for more on this).
Select the domain from the list presented. If the system
belongs to a domain which is not listed, you should define it
in the Domains menu.
5) AreaLink Password
If specified, this will be the password that the system will
use when requesting areas or information from Area Link. If
no password is specified, the system may not request any
areas, even if one or more groups have been enabled.
For more information on Area Link, see Chapter 8.
6) Packet Password
For added security, you may specify that packets to and from
this node contain a password. The password may not be longer
than 8 characters. This password will ensure that mail from
that system cannot be sent by someone else under false
pretences.
7) Groups
List the Groups to which the system may have access. Up to 26
may be specified.
A system must have a Group enabled in order to be able to
request a link to any echo area which is part of that Group.
Using F6 you can access the Group Manager. It shows you the
groups currently assigned to that system and allows you to
add or remove certain groups very easy.
8) Notify
This flag indicates whether or not the specified node should
receive NOTIFY messages. By default, this is set to Yes,
indicating that the system will receive a notification
message from IMTHINGS NOTIFY.
9) Remote Maint
Registered users of IMAIL may allow systems to carry out
changes in the links for other systems. These changes may be
made via AreaLink, using the %FROM meta-command (see Chapter
8. section b.).
In order to enable a node to make these changes for other
systems, this field must be set to 'Y'; the default is 'N'.
Remote Maint also allows the system to delete an echo area
from your list, or to change the name of an area. It thus
allows a lot of control over your system.
10) Direct
If this flag is set to 'Y', any mail generated for this node
(be it ARCmail or "automatic" mail such as replies from
AreaLink) will be marked DIRECT. In other words, it will not
(and cannot) be routed. If it is set to 'N', it will not be
marked as DIRECT, and thus can be routed via other systems.
It is STRONGLY recommended that echo mail NOT be routed, so
if the node is your echo mail feed, it is best to mark it as
Direct.
Note that any systems not defined in the Node Manager will
not have their mail marked DIRECT.
11) Rescan OK
This flag indicated whether the system is allowed to rescan
echo mail from your system, with an AreaLink request. Of
course, only those echo to which this node has access will be
rescanned.
12) Add to New
If you wish this system to be added to all new areas, then
set this field to Yes. Note that the node will only be
auto-added if it is in the same domain as the system which
"created" the new area.
13) Forward Requests
This flag selects whether this system is allowed to cause
Forward Link Requests, so you can prevent downlinks from
requesting areas from your uplink.
14) Create New Areas
If you wish to allow the system to create new echo mail areas
on your system, then set this flag to 'Y'. Otherwise, mail in
unknown echo areas, originating from this system, will be
tossed into the bad message area.
15) New Areas Group
If you have enabled the Create New option (above), this field
will specify the group to be used for echo areas created by
the node. If it is left empty, group will default to that
specified in the Other Parameters menu (see Chapter 5.
section a. para 7)).
16) Uplink
Together with "Program Name" and "FSC-0057 compatible" these
fields are used by the remote functions of AreaLink. If an
area is remote created, renamed or deleted, IMAIL informs
your links about this.
This field selects whether this system is one of your
uplinks (see below).
17) Program Name
This is the name of the AreaLink used by this system.
18) FSC-0057 compatible
This flag specifies whether this system is FSC-0057 compa-
tible (which is only required concerning the remote delete,
rename and create request).
If such a function is executed on your system, all affected
downlinks are notified. If they are also FSC-0057 compatible
and are not an uplink, their AreaLink is also notified with
a message. The table below shows how AreaLink works in this
cases:
Remote request FSC-0057 not FSC-0057
delete delete request unlink request
create create request link request
rename rename request -------------
19) Status
Pressing F1 while editing a node's information will allow you
to change the file attach status. By default, this is
"Normal", but you may select one of:
Normal No status
Hold Hold message for pick up
Crash Send message Crash
20) Program
If you press F2 while editing a node's information, you will
be able to select the program to use for mail compression. A
list will appear, containing the programs you defined in the
"Compression Programs" menu.
If you make no selection, by default the first program in the
list will be used.
Note that is is possible to specify that no compression
program be used (the last entry in the list). In this case,
PKT files addressed to the node being edited will not be
compressed, and will simply be file attached to the system.
This allows simple mail processors to receive mail from IMAIL
systems without needing to have one or more decompression
programs available.
21) Capability
The Capability describes the other system's mail processor.
Currently, two types are defined:
Stone Age
Type 2+
Set this field according to the capability of the system's
mail processor, if known. If you are unsure, leave the field
set to "Stone Age".
Note, that it is possible to define as Type 2+ mail
processors which are not normally detected as such but which
have the zone and point information. This is done in the
Product Code menu (see above).
For more information on the capability word, refer to the
FTSC documents FSC-0039 and FSC-0048. See also FTS-0001.
These documents may be available near you; otherwise you
should be able to file request them from 1:1/20. Refer also
to Chapter 13. Section a.
Note that IMAIL will always generate "Type 2+" information in
the packet header, and identify itself as a Type 2+ mail
processor, regardless of the setting of this field.
22) Cap Handling
This field allows you to define how IMAIL will use the
setting defined in the Capability field when handling inbound
mail. If it is set to "Force", IMAIL will always use the
setting defined in the Capability field, regardless of what
the actual format of the inbound packet(s) might be.
Instead, if set to "Auto", IMAIL will try to determine the
type of packet by examining the Capability Word and its
validation copy and/or the product code, and process the file
accordingly.
Please note that IMAIL cannot correctly handle points which
use "Stone Age" mail processors, unless they are using
fakenet addresses.
Note also that if TOSS processes mail from a system not
listed in the node manager, it will "Auto-add" it to the list
of nodes (this will be indicated in the edit window), giving
the determined Capability, and handling it as "Auto".
f. Pack Routing
In this menu you may specify default routing for IMPACK (see
Chapter 6. Section 7.); in other words, you may specify that net
mail for one or more systems be compressed in a packet addressed
to another system, from which (presumably) the mail will be
forwarded on.
The menu is composed of two "Route Via" columns, which indicate
the nodes via which net mail will be routed. For reasons of
space, the routed and excepted nodes are not shown unless the
appropriate function key is pressed.
If no systems are listed as "Routed Systems", IMPACK will simply
look for and compress mail for the "Route Via" address.
To edit these entries, position the cursor on the desired row
and press ENTER. You will then be able to edit the "Route Via"
address. Once finished, you may edit the list of "Routed System"
by pressing F1. It is also possible to specify one or more
"excepted systems" by pressing F2.
It is possible to insert new entries between existing ones by
pressing INS, and to delete entries (permanently!) by pressing
DEL.
IMSETUP supports the use of the "*" macro when specifying the
"Routed Systems". This macro may be used in place of the net,
node or point fields (the zone should always be given). For
example:
2:* All net mail messages addressed to
systems in Zone 2
2:230/* All net mail messages addressed to the
nodes in Zone 2, Net 230
27:230/100.* All net mail messages addressed to the
points of node 2:230/100. This is
equivalent to:
27:1331/100 This is treated as if you had written
27:1331/100.*; in other words, it will
act on all messages to the "boss" node
and his points.
If you wish to indicate only certain
points (or the node itself as .0), you
will have to specify them explicitly:
2:230/100.1 This will pack messages for point 1 of
the system 2:230/100 via the node
specified in the "Route Via" column.
If you do not specify the Zone, IMSETUP will use the Zone as
defined in your primary address.
Routing via itself:
If you use the ALL macro '*' as Via System, IMPACK will pack all
messages matching this entry via the node itself, for example
Route Via: *
Routed Systems: 2:246/18
Routed Systems: 2:246/48
Routed Systems: 2:246/37
tells IMPACK to packs the netmail for 2:246/18 via 2:246/18,
2:246/48 via 2:246/48 and 2:246/37 via 2:246/37. Using this
feature you can collect several entries to one.
An example might serve to illustrate how this all works. If you
have two entries such as the following:
Route Via: 2:285/304
Routed Systems: 2:*
Excepted Systems: 2:333/* 2:335/*
Route Via: 2:333/1
Routed Systems: 2:*
Excepted Systems: (none)
Thus all mail addressed to systems in Zone 2 would be routed via
2:285/304, EXCEPT for mail addressed to systems in net 333 and
335. Since the list is processed top-down, mail for systems in
nets 333 and 335 will be pack-routed via 2:333/1.
6. IMAIL COMMAND LINE OPTIONS
Once you have configured the program via IMSETUP, you are ready to
use IMAIL. There are three separate commands or functions
"contained" in IMAIL, and they are invoked via the command line.
The syntax used to invoke IMAIL is:
IMAIL TOSS | SCAN | /?
The switch ? may be prefixed with a dash (-) or a slash (/); IMAIL
will recognize both. If no command is given, IMAIL will display a
help screen, and return to the DOS prompt.
Here is a description of the commands.
a. /? - Help
This will cause IMAIL to display a brief summary of its command
line options on the screen. Any other commands will be ignored.
b. TOSS - Toss Incoming Mail
This enables IMAIL's TOSS function. This will search your
inbound files directory for mail, either compressed or in PKT
form, and toss it into your message base; net mail messages will
end up in the net mail subdirectory, while echo mail will be put
into the correct message area.
The TOSS function will automatically forward any echo mail to
other links, as well as net mail messages. Outgoing mail is
automatically compressed, and a file attach message generated
(unless the /X option is used).
The following is important when working in a multitasking/net-
work environment.
When compressing outgoing mail, IMAIL fully supports the Front-
Door 2.10 CRC-semaphores and the Binkley BUSY-flags. So IMAIL
can work while your mailer is still online. Without this support
(like under FrontDoor 2.02) you should not leave your mailer
online while IMAIL is compressing because it may cause file
access problems. This does not affect TOSS.
If TOSS finds that there is insufficient free space on the
working drive while processing, it will automatically compress
all outgoing mail before going on. This should help prevent disk
full errors.
Should TOSS encounter an ARCmail file from which it cannot
extract the mail packets successfully, it will rename the file
to have an extension of .BA? so that you can look at it, and so
the file will not be processed again.
For information on how TOSS handles the Capability Word, refer
to Chapter 5. Section e.
Note that IMAIL TOSS will return an ERRORLEVEL of 1 if it has
processed net mail messages. This fact can be used to
selectively call IMAIL ALNK only if net mail messages have been
received. For the full list of ERRORLEVELs returned, see Chapter
13. section d.
1) /B - Check Bad Message Board
Use this switch is you wish to force IMAIL to check messages
in the Bad Message Area. This will override the configuration
setting (see Chapter 5. section a.).
What will happen is this: if an echo message is found, IMAIL
will search to see if it belongs to an area defined in your
Areas file (IMAIL.AR); if the correct are is found, the
message will be moved to the correct area. However, if the
area is marked as Passthrough, the message will be deleted.
Please note that if you are tossing dupes into the Bad
Message Board (rather than having a separate board for them),
then any dupes found may also be moved. This option is useful
in those cases in which your echo feed has "turned on" an
area which has not yet been defined in your areas file.
2) /X - No Compression
The /X switch will force TOSS to not compress any outgoing
packets which it has generated. This is useful only in
multi-tasking environments.
The reason for this is that there can be problems if IMAIL is
running and the mailer tries to transfer the ARCmail file. In
some cases it could happen that the mailer truncates a file
while IMAIL is trying to access it; IMAIL hangs with a
sharing violation:
IMAIL checks the file, it is unaccessed; the mailer accesses
the file and transfers it; IMAIL tries to access the file and
gets a sharing violation; the mailer truncates the file, but
IMAIL still tries to access the file and gets an invalid
archive.
Use this switch with caution! If you are not running in a
multi-tasking environment, it should not be used, since it
will leave packets that have not been compressed, and with no
corresponding file attach message.
Naturally, a later run of IMAIL TOSS (or SCAN) will find the
unprocessed packets and process them into ARCmail.
c. SCAN - Scan for Outgoing Mail
This evokes the echo/net mail SCAN function. The message base(s)
will be searched for outgoing net and echo mail, exporting it to
packets.
If the messages are echo mail, a packet will be generated for
each of the downlinks listed for the area; a net mail message,
on the other hand, will be exported to a MSG-style file, and
placed in your net mail directory, where it can be pack routed
and compressed with IMPACK - IMAIL will not compress it.
For echo mail, if the destination system is listed in the Node
Manager, the appropriate compression program will be called to
compress the packet; otherwise, the first program listed will be
used (by default, ARC).
Regarding echo mail, SCAN will use the origin address as
specified in the IMSETUP Area Manager, rather than trying to
extract this information from the message header.
1) /D - Disable Dupe Checking
Normally, SCAN will check that a message about to be exported
in not a dupe, by checking the dupe database (IMAIL.DP). If
you are sure that you will never export duplicate messages,
you can speed up SCAN by disabling this check; however, this
is not advisable.
2) /F - Force Complete SCAN
If for any reason you suspect that IMAIL has not scanned out
all the the mail which should be exported, run it with the /F
switch. This will bypass the use of the ECHOMAIL.BBS,
NETMAIL.BBS and/or ECHOSCAN.LOG files generated by the BBS
and/or message editor, as well as the internal counter IMAIL
uses to keep track of which message it last scanned.
3) /Q - Only Hudson
If you wish to have IMAIL process only the Hudson message
base (QuickBBS or RemoteAccess), then you may run SCAN with
the /Q switch.
4) /S - Only MSG/Squish
This switch has the opposite effect of /Q: it will cause SCAN
to process only *.MSG and Squish message areas, ignoring the
Hudson message base (if present).
5) /X - No Compression
The /X switch will force SCAN to not compress any outgoing
packets it has created.
For a detailed explanation of this, see the /X switch as used
in TOSS (Section b. above).
7. IMPACK - Pack Net Mail Messages
This is IMAIL's net packer. The IMAIL Net Mail Message Directory
will be searched for outgoing net mail messages, which will be
compressed into ARCmail compressed files according to the
information given on the command line, and specified in IMSETUP
(see Chapter 5. Section f.).
Note that this command operates only on MSG style messages. Net
mail messages in the QuickBBS message base will be exported by the
SCAN command and thereafter treated as normal net mail.
The syntax of IMPACK is:
IMPACK [/N] [/C] [/D] [/H] [/R] [/X]
[z:n/nd[.p] [[...] VIA z:n/nd[.p]]]
(The square brackets enclose optional elements.) 'z:n/nd.p'
represents a network address in the usual form:
zone:net/node.point
where the point field is optional. If not specified, messages
addressed to point of the given system will be packed along with
the mail for that system. If you are a "boss" node, net mail for
your points will never be pack routed via another node, unless
explicitly forced with the ".*" macro (see below).
As with IMSETUP, the net, node and point fields may be replaced
with the '*' macro. If you omit the zone field, the zone defined
for your primary network address will be used by default.
If more than one system is given on the command line, then there
MUST be a 'via' node; that is, a system for which all the mail for
the preceding systems will be packed. Therefore, a command such as:
IMPACK 2:* 5:* 2:2/1
is not valid, and IMAIL will complain. Similarly, remember that if
you write
IMPACK *
you are specifying more than one system, in which case, there must
be a 'via' node.
When run, IMPACK will scan the command line for routing commands
and act on them, after which it will process the default routing
commands given in IMSETUP, which means that you may override the
defaults. If no parameters are given on the command line, IMPACK
will simply act on the defaults.
For example, the command:
IMPACK 2:* 5:* VIA 2:2/1
will collect any outgoing messages for all systems in zones 2 and
5, as well as messages for 2:2/1, and compress them into a file
attach for 2:2/1.
Please note that by default mail for points will always be routed
via the boss system. Therefore the commands
IMPACK 2:230/41.*
and
IMPACK 2:230/41
are equivalent. In both cases all mail for the system 2:230/41 and
any of its points will be compressed into the same file.
As another example, you may specify:
IMPACK * VIA 2:2/1
If your primary zone is 2, this will pack all outgoing mail for
systems in zone 2 via the system 2:2/1.
If you are a "boss" node (that is, you have points), net mail for
points can only be pack routed explicitly. For example:
IMPACK 2:230/100.* VIA 2:230/100.1
This applies also to default pack routing. Also note that it
applies only to 4D addressing (addresses which use the point
number); fake net addresses will not be checked, so care should be
taken that net mail destined to a fakenet address is never pack
routed out of your point net.
Messages marked as Crash or Hold will only be processed and packed
if the /C and/or /H switches (described below) are specified.
Messages which are file attaches, file requests, update requests,
or which have the IMMediate, DIRect or LOCKed status will NEVER be
packed.
a. /N - No Default Pack Routing
If for any reason you wish IMPACK to ignore the defaults given
in IMSETUP, suffix the switch /N to the command line. In this
case, IMPACK will simply process the command line.
Note that the command
IMPACK /N
effectively tells IMPACK to do nothing, since no route commands
are given in the command line, and the /N switch tells IMPACK to
ignore the defaults.
b. /C - Pack Crash Messages
If you want IMPACK to pack messages marked with Crash status,
specify the /C switch on the command line.
Otherwise, IMPACK will by default NOT pack Crash messages.
c. /D - Pack Direct Messages
If you specify this switch, IMPACK will pack messages which are
marked as Direct. By default, such messages are not packed.
NOTE: messages marked as direct will not be routed, unless the
/R switch is also specified (see below). So for example, if you
have a message addressed to 2:310/11, and it is marked direct,
you cannot pack route it with the command
IMPACK 2:all via 2:310/0
Without the /R switch, direct messages will only be packed if
"routed" to their destination. For example:
IMPACK 2:310/11
d. /H - Pack Hold Messages
If you want to pack messages marked as Hold along with "normal"
messages, specify the /H switch on the command line.
Normally, IMPACK will not pack messages with the Hold bit set.
e. /R - Pack Route Direct
If you specify the /D switch (see above), net mail messages will
not be pack routed unless they are being packed to their
destination. This behaviour can be overridden with the /R
switch. In this case, IMPACK will pack route net mail marked as
Direct as though this flag had not been specified.
Use this switch with care, since the Direct flag is =not=
stripped from the net mail message, and might cause your uplink
considerable grief! Please check with your uplink before using
it!
Note that if the /D switch is =not= specified, this switch will
have no effect.
f. /X - No Compression
This switch has the same effect as the /X switch in IMAIL SCAN
or TOSS. For more information, see Chapter 6. section b.
g. /? - Help
If you do not give IMPACK any parameters, or if you specify the
/? switch, it will display a brief summary of its options.
8. IMALNK
AreaLink is a function which allows other systems to request echos
from your system without the need for you to manually insert them
in the areas' export list. It is similar in function to AreaMgr
(which is part of TosScan), or to AreaFix. AreaLink is not fully
compliant with FSC-0057 (rev 3), but will implement full compliance
with one of the next releases.
What happens is this: a system sends a message addressed to IMAIL
on your system. Instead of the subject, he places a password. In
the body of the message will go the list of areas to which the
other system wishes to be linked, or areas which he no longer
wishes to receive. The system may also request information from
IMAIL by including one or more of the supported meta-commands.
In order to be able to use AreaLink, a system must be defined in
your Node Manager (See section e. of Chapter 5.). When the request
is processed by AreaLink, it will check that the password given on
the subject line of the message matches the one defined in the node
manager.
Also, AreaLink will only allow a system to request areas belonging
to one of the groups to which he has access.
When allowing rescan requests you should consider that IMALNK only
creates the PKTs for the downlink but does not compress them into
the arcmail bundles. You have to call IMAIL or IMPACK for that
purpose!
a. Format of the Request
As outlined above, a request to AreaLink takes a specific
format. Here is an example:
From: John Doe on 2:230/40
To: IMAIL on 2:230/0
Subject: password
-------------------------------------------------------------
+SYSOP <= Request to add area
+SYSOP,R <= Request to add area with rescan
+SYSOP,R=10 <= Request to add area with rescan
<= of the last 10 messages
+NEWS <= Request to add area
=NEWS,R <= Request to update area with rescan
=NEWS,R=20 <= Request to update area with rescan
<= of the last 20 messages.
-PENPAL <= Request to remove area
~FRIENDS <= Request for remote deletion
#OLD.ECH : NEW.ECH <= Request for name change
%query <= Request for active area list
%list <= Request for available area list
%unlinked <= Request for unlinked but available
areas
%info <= Request for general information
%rescan <= Request to rescan new and updated areas
%pwd xxxx <= Request for password change
%compress xxx <= Request to change compression program
%help <= Request for help on AreaLink use
All names, the password, area names and meta-commands may be
given in any combination of upper and lower case.
As can be seen, in order to request that an area be added, the
name of the area may be prefixed with a plus ('+') sign, whereas
to have a area removed, it =must= be prefixed with a minus ('-')
sign. The plus sign is optional.
Wildcards may be specified within area names. AreaLink
recognizes and handles the following:
* Matches 0 or more characters. For
example, IM*L will match IMAIL.
? Matches a single character. So ?MAIL
will match IMAIL and FMAIL.
[a-d] Matches any character in the range 'a'
to 'd'
Thus to request that all areas available to you be linked, you
could specify
+*
The '~' character indicates a remote deletion request; for more
information, see Section e. below. The '#' character indicates a
request to change the name of an echo area; this is described in
Section f. The '%', on the other hand, is used to prefix the
meta-commands recognized by AreaLink; these are described in
Section b.
Note that requests may be addressed to any one of:
IMAIL
AREALINK
AREAFIX
AREAMGR
AreaLink will recognize any of the above "names".
Optionally, the message may end in a tear line ('---'), followed
by any text (usually a message to the sysop). In this case, the
request will not be deleted. If the message contains no tear
line, it will be removed once processed.
b. Meta-Commands
IMAIL supports several meta-commands in AreaLink requests. These
are:
1) %COMPRESS
This allows a sysop to request that your system use a
different compression program be used to create ARCmail files
bound for his system. If no valid compression program is
given, AreaLink will respond with a list of the available
programs.
The format of the command is:
%COMPRESS <program>
where <program> should be the root name of a valid
compression program (eg. PKZIP, ARC, or whatever).
2) %FROM
On registered copies of IMAIL, the %FROM meta-command will
allow another system to make requests "on behalf" of a
different system. This is particularly useful for remote
maintenance of someone else's system. In order to do this,
the system have Remote Maint enabled in IMSETUP (see Chapter
5. section e.).
The format of the meta-command is
%FROM <full node number>
where the address must include the zone and point fields of
the system which will be linked (or unlinked).
Note that the password (subject) of the message must be
correct for the system SENDING the message, not for the
system for which the changes will be made. The generated
reply will be send, again, to the system which sent the
request, not to the one for which the changes were made.
3) %HELP
This meta-command will make AreaLink send a help text to the
sysop. The help text to be sent may be defined in IMSETUP; if
none is defined, a standard text will be sent, explaining the
principle features of AreaLink.
4) %LIST
The %LIST meta-command will have AreaLink reply with a list
of all the areas available to the requesting system. In other
words, those which are marked as Active, and which belong to
a group listed as available for that system.
5) %NOTE
This meta-command is used to introduce a comment to the
sysop. It is equivalent to adding a tear-line in the message
body, but the use of %NOTE is preferred.
AreaLink requests containing a tear-line or a %NOTE will not
be deleted once processed.
6) %PAUSE
If a sysop wishes to temporarily unlink from ALL echos, then
he may send a message to AreaLink with the %PAUSE command.
This will cause the receiving system to stop exporting echo
mail without deleting the node from the export list for the
echo areas to which he is linked.
This command is revered with a %RESUME (see below).
7) %PWD
With this meta-command, a sysop can change the password he
uses to make AreaLink requests to your system. Note that if
no new password is specified, AreaLink will NOT respond with
the current password, for reasons of security.
8) %QUERY
If the message contains this meta-command, AreaLink will
reply with a list of currently active echos for the
requesting system
9) %RESCAN
This meta-command will allow a node to request that IMAIL
send all old mail in the areas requested. For example, if a
system requests to be linked to the SYSOP echo, and places a
%RESCAN meta-command in the message text, IMAIL will link the
system, and then scan your message base for any messages in
this area, and send them to the requesting system.
All the exported messages will have the same SEEN-BY lines as
they normally would, thus (hopefully) preventing duplicates.
However, the messages will be exported only to the system
requesting the rescan, not to all linked nodes.
In order to prevent the system which requested the rescan
from sending the messages out to other systems, AreaLink will
insert a special kludge into the message: ^ARESCANNED <addr>
where <addr> is the address of the system which requested the
rescan.
Note that if you have set the Allow Rescan option in IMSETUP
to "no" (see Chapter 5. Section 4)), then the rescan request
will be ignored.
10) %RESUME
%RESUME will reverse the effect of a %PAUSE command (see
above). It will reactivate the suspended link.
11) %UNLINKED
This meta-command is, in a sense, the complement of %QUERY
and %LIST. In other words, it will send a list of all
available echos which are NOT currently linked to the
requesting system.
12) %INFO
%INFO sends some general information (packer used, AreaLink
password, ...) to this system.
c. AreaLink Replies
When it has processed a request, AreaLink will generate a reply
message to the system who sent the request. This message will
contain the list of echo areas added and/or removed for that
system, as well as query and list information, if requested.
The message will be marked as Kill/Sent (ie it will be deleted
once sent) unless you have configured IMAIL to keep them (see
Chapter 5. Section 4)).
d. Forward Link Requests
Registered users of IMAIL may define one or more systems as
uplinks, specifying the name of a file containing a list of echo
areas available on those systems.
If a system requests an echo area not currently available on
your system, AreaLink will search the files specified for the
required echo. If it is found, it will generate a request to the
given uplink. In this case, it will also automatically add the
area to your database, defining the area name, and marking it as
passthrough (as opposed to areas automatically added by TOSS);
the group will be undefined. The uplink and downlink systems
will be defined in the export list. Such areas will be marked as
"Auto-Added" in the IMSETUP Area Manager until they are edited.
e. Remote Deletion
AreaLink will allow you to give partial control of your areas
configuration to another system: any system which has Remote
Maint (see Chapter 5. Section e.) enabled in the Node Manager
will be able to delete one or more echo areas from your system.
This feature is useful if, for example, you wish to allow your
boss or host system to automatically delete an area when it has
been discontinued.
In order for a system to delete an area from your list, it will
send a normal AreaLink request to your system, prefixing the
names of the areas to be deleted with a '~' character. For
example:
From: John Doe on 2:230/40
To: IMAIL on 2:230/0
Subject: password
---------------------------------------------------
SYSOP <= Request to add area
~PENPAL <= Request to delete area
In the above example, the system is requesting that an area be
linked to it, and at the same time, that the area PENPAL be
deleted from your configuration.
When AreaLink processes such a request, it will first send a net
mail message to any other systems which are linked to that area,
warning them that it has been deleted. It will then flag the
area as deleted and inactive, so that any requests to link to it
will be ignored. The next time IMSETUP is run, and the Area
Manager entered, the area will be removed completely from the
list.
f. Remote Adding
This command allows to create an area remotly (similiar as if
the area is sent by a system which is allowed to create areas).
As for all remote commands, the system requesting to create an
area needs Remote Maint privileges.
The format of a Remote Create request is as follows:
From: John Doe on 2:230/40
To: IMAIL on 2:230/0
Subject: password
---------------------------------------------------
SYSOP <= Request to add area
&PENPAL <= Request to delete area
g. Remote Change
As with Remote Deletion requests (see above), a system which has
Remote Maint privileges on your system may request a change of
area name. What this will do is simply to change the name of the
area; no other variations will take place.
The format of a Remote Change request is as follows:
From: John Doe on 2:230/40
To: IMAIL on 2:230/0
Subject: password
---------------------------------------------------
SYSOP <= Request to add area
#OLD.ECH NEW.CH <= Request to change name
The '#' character indicates a Change request. Following should
be the old area name; then, after one or more spaces should come
the new area name.
If AreaLink finds the old area name, and the node requesting the
change is active for that group, AreaLink will make the
requested change, advising all other downlinks of the variation
by sending them a net mail message.
h. Local Maintenance
Registered copies of IMAIL will allow the sysop to use AreaLink
as if another sysop had sent a request. This can be done by
using one or more of the command line switches described below.
When run from the command line, AreaLink is designed to mimic
its behaviour when it is parsing a request from another system.
(For more information on the single meta-commands, see Section
b. above.) The advantage of using AreaLink to make changes
instead of doing it from IMSETUP is that a net mail message will
be generated automatically, informing the system of the changes
made.
Note that each switch may appear only ONCE on the command line.
However, the /+ and /- switches may make use of the '*' wild
card. For multiple changes, it will be necessary to run AreaLink
several times.
The complete syntax accepted by AreaLink is:
IMALNK /N<addr>
/+<area>
/-<area>
/=<area>
/I
/L
/Q
/U
/R
/H
/P
/S
/D<area>
/A<area>
/C<area:area>
1) /N<address> - Node to Make Changes For
This switch indicates the node number for which you wish the
changes to be made. It will make AreaLink behave as it it had
received a request from that system, sending it a net mail
messages listing the actions taken.
If this parameter is omitted, AreaLink will act on behalf of
YOUR system. Thus most of the other switches are meaningless.
In particular, /I, /L, /Q, /H, /U, /R, /P, /S, /+, /- and /=
will be ignored.
If the /N switch is used, a net mail message will be
generated for that system, specifying the changes made. If
this switch is NOT used, a net mail message will be generated
to you.
2) /+<area> - Link Node to Area
Links the system specified by /N to the echo area. If /N is
not specified, this switch will be ignored. Wild cards may be
used, as illustrated in this chapter, section a.
3) /-<area> - Unlink Node from Area
Unlinks the system specified by /N from the given echo area.
If /N is not specified, this switch will have no effect. Wild
cards may be used, as explained in this chapter, section a.
4) /=<area> - Update Node in Area
Updates the area for this node and has the same effect as an
unlink request followed by a link request. It is mainly used
when an already linked echos should be rescanned.
5) /I - General Information
This sends some general information (packer used, AreaLink
password, ...) to the system.
6) /L - List Available Areas
Sends the system a list of available echos, marking those
which are already linked. This switch is ignored if /N is not
given. (Corresponds to the %LIST meta-command.)
7) /Q - Query - List Linked Echos
Sends the system a list of currently linked echos. The switch
is ignored if no system is specified with the /N switch.
(Corresponds to the %QUERY meta-command.)
8) /U - List Available but Unlinked Echos
Sends a list of echo areas which are available but not
currently linked to the system. The switch will be ignored if
no system is specified with /N. (Corresponds to the %UNLINKED
meta-command.)
9) /R - Rescan
Perform a rescan of echos linked with /+. This switch has no
meaning if /+ and /N are both not specified. (Corresponds to
the %RESCAN meta-command.)
10) /H - Send Help
Sends the system the defined help text. This switch has no
meaning if no system is specified with the /N switch.
(Corresponds to the %HELP meta-command.)
11) /P - Pause
This will cause the receiving system to stop exporting echo
mail without deleting the node from the export list for the
echo areas to which he is linked.
This command is revered with /S (see below).
12) /S - Resume Sending
/S will reverse the effect of a /P command (see above). It
will reactivate the suspended link.
13) /D<area> - Delete Echo Area
Deletes the specified echo area. All links will be notified
of the deletion (Switch may be substituted with /~<area>).
14) /A<area> - Create Echo Area
Creates the specified echo area. (Switch may be substituted
with /&<area>).
15) /C<area:area> - Change Echo Name
Changes the name of an echo. The first echo tag is changed to
the second. (Switch may be substituted with /#<area:area>)
9. IMTHINGS
IMTHINGS is a program containing additional utilities for use with
IMAIL. It is used giving it a command and additional parameters,
which vary according to the command given.
All of the commands give a brief on-line help if followed by the /?
switch. For example, to get help on the SEND command:
IMTHINGS SEND /?
In most cases, the commands may be abbreviated to one or two
letters; for example IMTHINGS KILL may be given as IMTHINGS K.
However, IMTHINGS SORT must be abbreviated to IMTHINGS SO since the
SEND command also begin with the letter 'S'.
Supported message bases are indicated by a letter, as follows:
M = *.MSG
Q = Hudson (QuickBBS or RemoteAccess)
S = Squish
PLEASE NOTE: The Squish MSGAPI which is used in IMAIL and IMTHINGS
has a built-in limit regarding the number of messages it can handle
during certain operations. This limit is just over 5300 messages.
So it is suggested that you keep each Squish message area under
this limit.
a. IMPORT - Import Net Mail Messages [MQS]
The IMPORT function allows you to import net mail messages from
the net mail directory into the net mail area of the message
base. This is necessary is you wish to allow the users of your
BBS to read net mail addressed to them.
This command has no parameters. It will scan the net mail
directory for net mail messages addressed to one of your AKAs,
and if found, import them into the net mail area which
corresponds to that AKA. Once imported, the MSG file will be
deleted. Note that net mail addressed to any of the names
specified in the IMSETUP No Import menu will not be imported
(see Chapter 5. Section a.).
NOTE: net mail messages which are also File Requests or Update
Requests will not be imported. However, File Attach messages
will. So to avoid problems, it is best to run IMAIL TOSS before
IMTHINGS IMPORT.
b. INDEX - Rebuild index files [-Q-]
The INDEX command will rebuild the message base index files
(MSGIDX.BBS, MSGTOIDX.BBS and MSGINFO.BBS) from the MSGHDR.BBS
file. Use this if for any reason you suspect that one or more of
these files have somehow become damaged.
Note that INDEX is run automatically after the following
functions:
MOVE
SORT
The INDEX function has no command line parameters.
c. KILL - Delete messages from an area [MQS]
The KILL command allows you to mark as deleted some or all
messages in a specified message area. Note that KILL does NOT
pack the message base. Use IMTHINGS PACK for this.
With a Hudson message base, normally KILL will create a
temporary file to which it will write the new MSGHDR.BBS.
However, if it detects that there is not enough disk space, it
will overwrite the original file directly; this method is MUCH
slower.
Note that it is advisable to run IMAIL SCAN /F before running
this command; this will ensure that all outgoing echo mail
messages have been exported.
The syntax of the command is:
IMTHINGS KILL /A<areaname>
/B<board>
/D<days>
/K<days>
/N<number>
/Q
/S
/U
/!
1) /A<areaname>
If specified, the /A switch should be followed by the name of
one of the echo areas, as given in the Area Manager. If this
switch is used, then the /B switch should NOT be given.
NOTE: If you specify the /U switch, this switch will be
ignored.
2) /B<board>
If specified, the /B switch should be followed by a message
board number. In this way, it is possible to "act" on message
board not defined in the IMSETUP Area Manager (for example,
local message areas). If the /B switch is used, then the /A
switch should NOT be given.
If you do not specify one of /A or /B, then KILL will act on
ALL message boards, unless the /U switch is given (see
below).
3) /D<days>
This allows you to specify that KILL should keep messages
younger than the given number of days. If the switch is not
used, then IMTHINGS will not check the date of the message.
Note that if the /U switch is given, the /D switch will be
ignored.
4) /K<days>
This switch allows you to have KILL delete old ARCmail files
and their respective file attaches. The <days> parameter
indicates the age of the message; in other words, ARCmail
files which are older than the given number of days will be
deleted.
If you choose to use this switch, it is recommended that you
advise your downlinks, so that they know that should pick up
their mail before it is deleted.
This option is available in registered versions of IMAIL
only.
5) /N<number>
If this switch is used, KILL will leave the specified number
of messages in the base, marking the rest as deleted.
Note that if neither /N nor /D are specified, then KILL will
mark ALL messages in the designated board as deleted, unless
the /U switch is given (see below). If both are given, the
KILL will ensure that both criteria are met, in which case it
may leave less than <number> messages in the area if it finds
"old" messages.
6) /Q - Hudson Only
This switch instructs KILL to only process the Hudson message
base (if defined). Squish or MSG message bases will be
ignored.
7) /S - MSG/Squish Only
This switch instructs KILL to process only *.MSG or Squish
message bases. If you have also defined a Hudson message
base, it will be ignored.
8) /U - Use Default Information
This parameter tells IMTHINGS KILL to use the information
given in IMSETUP to determine how many messages to kill. It
will operate on all boards defined in the Areas Manager,
leaving the given numbers of messages in the board, or
deleting all messages older than the given number of days.
PLEASE NOTE: if you use the /U switch, the /A, /B, /D and /N
switches will be ignored if also specified.
9) /! - Allow All Messages to be Killed
This switch will allow all messages in a given area, or all
messages in a given message base, to be deleted.
d. LINK - Link Messages in Message Base [MQS]
In order to update the links between the messages and their
replies, run IMTHINGS LINK after each arrival of echo mail, or
at least once a night.
LINK scans the message base, looks for messages with similar
subject lines, and from them, creates links for each message,
which point to the previous message in the chain, and the next
message.
Note that the case of the subject line is not significant; thus
"Echo mail" and "Echo Mail" will match when creating links. Note
however that the search is performed ignoring any leading "RE:"
in the subject line.
IMAIL marks Squish/*.MSG areas when tossing new mails into them
which is used by LINK to skip areas without new messages. This
can be overwritten by using the /F commandline switch.
The syntax of this command is:
IMTHINGS LINK /C /Q /S /F
1) /C - Clean
If this switch is specified, LINK will remove all occurrences
of "RE:" (in upper and/or lower case) from the message
subject lines. Otherwise, the "RE:" strings will be left in
place, but still ignored when the link search is being done.
2) /Q - Hudson only
With this switch, LINK will be forced to process only the
Hudson message base.
3) /S - MSG/Squish only
This is the opposite of /Q: it will force LINK to process
only Squish and MSG type areas.
e. MOVE - Move Message Area [MQS]
The MOVE command allows you to move all the messages from one
board or area to another. The syntax of the command allows you
to specify the source and destination areas either by board
number or by area name.
IMTHINGS MOVE /R<src area> | /S<src board> | /F<src path>
/T<dst area> | /D<dst board> | /P<dst path>
Please note that all messages moved will have the Outgoing Echo,
Outgoing Net and Net mail bits cleared, so that they will not be
SCANned out again by mistake, thus creating confusion in the
network.
1) /R<src area>
If you know the area name as specified in IMSETUP's Area
Manager, you may use this switch. If you use this switch,
then do NOT use the /S switch.
For example:
IMTHINGS MOVE /RSYSOP /D12
will move all messages from the SYSOP area to board 12 (which
might be a local board).
2) /S<src board>
If the source board in not defined in the Area Manager, it
will have no area name; so specify the board number using the
/S switch. If you use /S, then do NOT use /R.
3) /F<src path>
Here you specify the source Squish/*.MSG path. SEND tests
whether this area is a *.MSG area (in this case you specify
the directory) or a Squish area (in this case you specify the
filename of the area without extension). If you use /F, then
do NOT use /R or /S.
4) /T<dst area>
You may specify the destination area name with this switch.
It is used in the same way as /R. If you use the /T switch,
then do NOT use /D.
5) /D<dst board>
If the destination board is not defined in IMSETUP's Area
Manager, you may specify the board number. See above for an
example of its use. If you use this switch, then do NOT use
/T.
6) /P<dst path>
Here you specify the destination Squish/*.MSG path. SEND
tests whether this area is a *.MSG area (in this case you
specify the directory) or a Squish area (in this case you
specify the filename of the area without extension). If you
use /F, then do NOT use /D or /T.
f. NOTIFY - Send list of linked echos [---]
The NOTIFY function will send a message to the systems which are
linked to you for at least one echo area, listing the echos to
which they are linked, as well as systems listed in the Node
Manager. Note that systems listed in the Node Manager which have
the Notify flag set off will not be notified unless explicitly
specified on the command line (see Chapter 5. section e.).
The syntax of the command is:
IMTHINGS NOTIFY [z:n/nd.p]
[....]
/N
/P
/W
where "z:n/nd.p" is a standard network address. The "*" macro
may be used, as with IMPACK (except, of course, that in this
case there are no "VIA" nodes). Note that
IMTHINGS NOTIFY *
notifies all systems in your primary zone only. If you have AKAs
in different zones or feed echo mail to systems in more than one
zone, and wish to notify ALL of your downlinks, simply give the
command
IMTHINGS NOTIFY
1) /N - No node manager
If you specify this switch, NOTIFY will not generate a
message to systems which are listed only in the node manager,
but are not listed in any of the echo areas' export lists.
2) /P - Notify AreaLink Password
If you wish to remind your downlinks of their AreaLink
password, specify the /P switch. The password will then be
included in the net mail message which is generated.
3) /W - Only Warn of Password Expiration
The /W switch will cause NOTIFY to only generate a message
warning about an expired AreaLink password, should this be
the case.
g. PACK - Compress message base [MQS]
In Hudson and Squish message bases, when you delete a message,
it is not actually removed from the base, but rather is just
marked in a special way. PACK will allow you to remove from the
message base those messages marked as deleted, thus recovering
unused disk space.
In *.MSG message areas, this concept does not exist, since
messages are physically deleted; so PACK will simply renumber
the message area.
For Hudson areas, PACK will normally create temporary files to
which it will write the new MSGHDR.BBS and MSGTXT.BBS files.
However, if it detects that there is not enough free disk space
to do this, it will overwrite the original files; this method is
considerably slower.
Optionally, it is also possible to have PACK renumber all net
mail messages.
In order to make PACK faster on Hudson areas, it does not try to
update the 3 index files; instead of this, it will call IMTHINGS
INDEX after having completed.
Note that it is advisable to run IMAIL SCAN /F before packing
the message base. This will ensure that all outgoing echo mail
messages have been exported.
The syntax of the command is:
IMTHINGS PACK /B
/P
/Q
/R
/S
PACK is not able to keep track of the message links, so it may
be desirable to run LINK after PACK.
PACK will update the USERS.BBS file (if it is found) as well as
LASTREAD.BBS (this file keeps track of the last messages read in
each message area).
1) /B - Keep backup
If you specify this switch, PACK will not delete the backups
it made of the five files which comprise the message base.
2) /P - Pack IMAIL.AR
Though it is not normally necessary, it might occur that some
deleted records remain in IMAIL.AR, or that you wish to
rebuild the areas index files (IMAIL.?X). In this case, run
IMTHINGS PACK /P. This will reconstruct the areas files, and
do nothing else.
3) /Q - Hudson Only
If you wish to process only the Hudson message base, then
specify the /Q switch. *.MSG and Squish areas will be
ignored.
4) /R - Renumber
Giving the /R switch will have PACK renumber all net mail
messages.
5) /S - *.MSG/Squish Only
If you wish to process only *.MSG and Squish areas, then use
the /S switch on the command line. Any areas in a Hudson
message base will be ignored.
h. POST - Post message in echo area [MQS]
The POST function will allow you to post a message in an echo
area. It is particularly useful for posting echo message
statistics, for example.
The syntax of the command is:
IMTHINGS POST /F<filename>
/A<areaname>
/B<board>
/W<to_who>
/R<from_who>
/S<subject>
1) /F<filename>
The /F switch is used to specify the name of the text file to
post as the message. This file should be a simple ASCII file,
containing no special control characters. This parameter is
required.
2) /A<areaname>
To specify the name of the echo area in which to post the
message, use the /A switch. The name of the area may be given
in upper or lower case, or any combination of the two. If you
use this switch, do NOT use the /B switch.
3) /B<board>
Use the /B switch to give the number of the message board in
which to post the message, if the area is not defined in
IMSETUP's Area Manager. If you use this switch, then do NOT
use the /A switch.
4) /W<to_who>
You may optionally specify the name of the person to whom the
message is addressed. If this parameter is omitted, the
message will be addressed to 'All'.
If the /W parameter is used, the name should contain no
spaces; replace the spaces with underscores: /WTest_User
5) /R<from_who>
By default, POST will use the name defined in the Sysop field
in IMSETUP to indicate the name of the sender of the message.
If you want to use another name, specify it after the /R
switch. The name should contain no spaces; replace any spaces
with an underscore.
6) /S<subject>
You may also specify the subject of the message with the /S
switch. If this parameter is omitted, the message subject
will be 'News'.
If you do use this parameter, the text following the switch
should contain no spaces; replace them with underscores. For
example: /STest_message_#1
i. RECOVER - Unerase messages [-Q-]
The RECOVER command will allow you to "undelete" messages in
your Hudson message base. Naturally, it will only work if you
have not PACKed the base.
By default, RECOVER will "undelete" messages found in any
message area, prompting you at each message. However, you may
specify that it look for messages in a specific area, and that
it automatically recover all deleted messages it finds.
The syntax of the command is:
IMTHINGS RECOVER /A<areaname>
/B<board>
/U
1) /A<areaname>
If specified, the /A switch indicates the name of the echo
area to search for deleted messages. If given, then the /B
switch (see below) should NOT be given.
2) /B<board>
If specified, this switch indicates the board to search for
deleted messages. Giving the board number allows you more
flexibility, since local message areas might not be defined
in the Area Manager, and therefore would have no name - the
/A switch cannot be used. If you use this switch, the /A
switch (see above) should NOT be given.
3) /U - Automatic Mode
Automatic mode. If this switch is given, RECOVER will not
prompt you at each message. Instead, it will "undelete" all
messages it finds (if /A or /B are specified, only messages
in the specified message area will be recovered).
j. SEND - Send a file [---]
The SEND command invokes the IMAIL Robot. This will allow you to
send a file and/or message to another system, much like any
other Robot program.
This command is available only in registered copies of IMAIL.
The syntax of the SEND command is:
IMTHINGS SEND /F<filename>
/A<address>
/W<to_who>
/T<text>
/C | /H
/D
/K
/E
/Y<days>
/N<1-16>
If a file name is given with /F, and the required file is found,
a file attach message will be generated in your Net Mail
directory. However, it is also possible omit the file name, and
simply specify a text file (with /T). In this case, a net mail
message will be generated, with no attached file. Note that
either a file or a message text (or both) must be specified; if
both are omitted, SEND will exit with an error.
This command is available to registered users only.
1) /F<filename>
Indicates the full pathname of the file to be sent. This
parameter is not required if you simply wish to send a net
mail message.
If the filename contains wildcards, only the first matching
file will be sent. If the full path is not supplied, IMTHINGS
will use the current drive and path when generating the file
attach message. Note that if the file has zero length, it
will NOT be sent.
2) /A<address>
Specifies the destination address of the file. This parameter
is required.
The address should contain the zone, otherwise the zone of
your primary address will be used by default.
3) /W<to_who>
You may optionally specify the name of the person to whom the
file is being sent. If this parameter is omitted, the message
will be addressed to 'Sysop'.
If the /W parameter is used, the name should contain no
spaces; replace the spaces with underscores: /WTest_User
4) /T<text>
This switch allows you to specify the name of a text file to
be used as the "body" of the file attach message. If omitted,
the message will have no text. It may also be used to
generate a normal net mail message if the /F parameter is not
given.
5) /C - Crash
Mark message with Crash status.
This option is mutually exclusive with the Hold option below.
6) /H - Hold
Mark message with Hold status.
This option is mutually exclusive with the Crash option
above.
7) /D - Direct
Send message Direct. This means that in no case will the
message be routed via another system. It may be used together
with the /C or the /H option.
Use this flag only if your mailer supports the FLAGS DIR
kludge.
8) /K - Kill/Sent
Marks the message as Kill/Sent. In other words, once sent,
the message will be automatically deleted from your Net Mail
directory. Otherwise, it will remain, but be marked as Sent.
9) /E - Delete/Sent
Marks the message as Delete/Sent. This will cause the mailer
to delete the file once it has been sent.
Use this flag only if your mailer supports the FLAGS KFS
kludge.
10) /Y<days> - Newer than
Indicates that the file must be newer than <days> for it to
be sent.
This is useful for sending nodelist files, as you can then
specify a wildcard in the filename, and indicate that the
file be sent only if it is newer than, say, 6 days.
11) /N<0-15> - Alternate Address or AKA
With this switch, you may specify which of your addresses
should be used when sending the file. If /N is not specified,
SEND will attempt to find an address which best matches that
of the destination system.
If /N is specified, it may take one of several forms:
/N or /N0 - your primary address
/Nx - AKA 'x', where x may be between 1 and 15
/N<addr> - where addr is a full network address.
k. SORT - Sort the Message Base [-Q-]
The SORT function will sort the Hudson message base by message
date. What it does is to read in the MSGHDR.BBS file, saving the
message number and time stamp. The list thus created is sorted,
and then the MSGHDR.BBS file is rewritten, following the order
of the new message numbers.
Note that the SORT command destroys the message index files, so
it automatically called INDEX once finished.
SORT also updates USERS.BBS (if found) and LASTREAD.BBS; this
may account for the last message number read being suddenly
moved; previously "older" messages have a newer date and/or
time.
The syntax of the SORT function is:
IMTHINGS SORT /L
/Q
1) /L - Link Messages after Sort
Since SORT destroys the message links, you may wish to have
it call LINK after processing has completed. This can be done
by specifying /L on the command line.
2) /Q - "Quick" Sort
The /Q switch forces a "quick" sort. In other words, only
those messages numbered higher than the highest lastread
pointer will be sorted. The advantage of this is that your
users will not have to read old messages again. The
disadvantage is that, due to the way certain message editors
assign new message numbers, it is possible that a small
number of "old" messages will be overwritten. Thus it might
be advisable to run IMTHINGS PACK prior to calling SORT with
this switch.
10. AN OVERVIEW OF ECHOMAIL
Information derived from FTS-0004.
a. What is Echo Mail?
Echo Mail is a technique which permits several nodes in a
network to share messages. All systems sharing a given echo see
any messages entered into the echo by any of the participating
systems. This can be implemented in such a way as to be totally
transparent to the users of a particular system. In fact, they
may not even be aware of the network being used to move their
messages about from node to node! This has its disadvantages
also - most users who are not educated about Echo Mail do not
realize the messages transmitted cost MANY sysops money, not
just the local sysop. This is an important consideration in Echo
Mail and should not be taken lightly. In an echo with 100
systems as participants the cost per message can get quite high.
b. How it Works
In general, the process is:
1. A message is entered into a designated area on a FidoNet
or compatible system.
2. This message is "exported" along with some control
information to each system "linked" to the echo through the
originating system.
3. Each of the receiving systems "import" the message into
the proper Echo Mail area.
4. The receiving systems then "export" these messages, along
with additional control information, to each of their links.
5. Return to step 3.
The method is quite simple - in general. Of course, following
the steps literally would mean messages would never stop being
exported and transmitted to other systems. This obviously is not
desired as the network would quickly become overburdened. The
information contained in the 'control information' section is
used to prevent transmitting the same message more than once to
a single system.
c. Echo Mail Message Control Information
There are five pieces of control information associated with an
Echo Mail message. Some are optional, some are not. Normally
this information is never entered by the person creating the
message, but rather is added by the program which is responsible
for the exporting of the original message. The following control
fields determine how Echo Mail is handled:
1) Area Line
This is the first line of an echo mail message. Its actual
appearance is:
AREA:CONFERENCE
where CONFERENCE is the name of the echo. This line is added
when a conference is being "exported" to another system. It
is based upon information found in the configuration file for
the designated message area (in the case of IMAIL, this file
is IMAIL.AR). This field is REQUIRED by the receiving system
to "import" a message into the correct Echo Mail area.
Note that IMAIL will not handle echo mail messages which
"kludge" this field by putting a ^A character in front of it;
these messages will be tossed into your net mail directory.
Note also that you may not have two areas defined with the
same area name; this would create cross-linked messages,
which are a potential source of duplicates.
2) Tear Line
This line is near the end of a message and consists of three
dashes (---) followed by an optional program specifier. This
is used to show the first program used to add Echo Mail
compatible control information to the message. The tear line
generated by IMAIL looks like:
--- <a small product-specific banner>
This field is optional for most Echo Mail compatible
processors. Some systems will place this line in the message
when it is first created, but it is normally added when the
message is first "exported."
3) Origin Line
This line appears near the bottom of a message and gives a
small amount of information about the system where it
originated. It looks like:
* Origin: IMAIL Development (2:246/47)
The " * Origin: " part of the line is a constant field. This
is followed by a banner which should in some way identify the
system which originated the message. The complete network
address (2:230/41.22 in this case) is added by the program
inserting the line. This field is generated at the same time
as the tear line, and therefore may either be generated at
the time of creation or during the first "export" processing.
4) SEEN-BY Lines
There can be many SEEN-BY lines at the end of Echo Mail
messages, and they are the real "meat" of the control
information. They are used to determine the systems to
receive the exported messages. The format of the line is:
SEEN-BY: 132/101 113 136/601 1014/1
The net/node numbers correspond to the net/node numbers of
the systems having already received (or "seen") the message.
In this way a message is never sent to a system twice. In an
Echo with many participants the number of SEEN-BY lines can
be very large. This line is added if it is not already a part
of the message, or added to if it already exists, each time a
message is exported to other systems. This is a REQUIRED
field, and IMAIL will not function correctly if this field is
not put in place by other Echo Mail compatible programs.
5) PATH Lines
These are the last lines in an Echo Mail message. They appear
as follows:
^APATH: 132/101 1014/1
where the ^A stands for Control-A (ASCII character 1) and the
net/nodes listed correspond to those systems having processed
the message before it reached the current system. This is not
the same as the SEEN-BY lines, because those lines list all
systems the message has been sent to, while the path line
contains all systems having actually processed the message.
d. Methods of Sending Echo Mail
To this point the issue of how Echo Mail is actually sent has
been glossed over entirely. The phrase has been, "the message is
exported to another system." What exactly does this mean?
Thom Henderson (from System Enhancement Associates) came up with
the original ARCmail program. Having previously written the ARC
file archiving and compression program, he knew the savings
achievable by having all of the Net Mail messages placed in .ARC
format for transmission. As a by-product, the messages no longer
appeared in the net mail area, but were included in a file
attached to a message. In this way the tremendous number of
messages generated, and the phone bill problems were both
solved.
IMAIL builds the ARCmail files during export, and unpacks them
during import. This way messages are exported directly to
ARCmail style file attaches, and imported directly from ARCmail
style file attaches.
e. Topology
The way in which systems link together for a particular Echo is
called the "echo topology." It is important to know this
structure for two reasons:
1) it is important to have a topology which is efficient in the
transfer of the Echo Mail messages;
2) it is important to have a topology which will not cause
systems to see the same messages more than once.
Efficiency can be measured in a number of ways; least time
involved for all systems to receive a message, least cost for
all systems to receive a message, and least phone calls required
for all systems to receive a message are all valid indicators of
efficiency. Users of Echo Mail compatible systems have
determined (through trial and error) the best measure of
efficiency is a combination of all three of the measurements
given above. Balancing the equation is not trivial, but some
guidelines can be given:
1. Never have two systems attempting to send Echo Mail to
each other at the same time. This results in "collisions"
that will cause both systems to fail. To avoid this, one
system should be responsible for polling while the other
system is holding mail. This arrangement can alternate based
upon various criteria, but both systems should never be
attempting to call each other at the same time.
2. Have nodes form "stars" for distribution of Echo Mail.
This arrangement has several nodes all receiving their Echo
Mail from the same system. In general the systems on the
"outside" of the star poll the system on the "inside". The
system on the "inside" in turn polls other systems to receive
the Echo Mail that is being passed on to the "outside"
systems.
3. Utilize fully connected polygons with a few vertices.
Nodes can be connected in a triangle (A sends to B and C, B
sends to A and C, C sends to A and B) or a fully connected
square (all corners of the square send to all of the other
corners). This method is useful for getting Echo Mail
messages to each node as quickly as possible.
All of these efficiency guidelines have to be tempered with the
guidelines dealing with keeping duplicate messages from being
exported. Duplicates will occur in any topology that forms a
closed polygon that is not fully connected. Take for example the
following configuration:
A ----- B
| |
| |
C ----- D
This square is a closed polygon that is not fully connected. It
is capable of generating duplicates as follows:
1. A message is entered on node A.
2. Node A exports the message to node B and node C placing
the SEEN-BY for A, B, and C in the message as it does so.
3. Node B sees that node D is not listed in the SEEN-BY and
exports the message to node D.
4. Node C sees that node D is not listed in the SEEN-BY and
exports the message to node D.
At this point node D has received the same message twice - a
duplicate was generated. Normally a "dupe-ring" will not be as
simple as a square. Generally it will be caused by a system on
one end of a long chain accidentally connecting to a system on
the other end of the chain. This causes the two ends of the
chain to become connected, forming a polygon.
f. Why a PATH line?
The PATH line stores the net/node numbers of each system having
actually processed a message. This information is useful in
correcting the biggest problem encountered by nodes running an
Echo Mail compatible system - the problem of finding the cause
of duplicate messages. How does the PATH line help solve this
problem? Take the following path line as an example:
^aPATH: 107/6 107/312 107/528 107/312 132/101
This shows the message having been processed by node 107/312 on
more than one occasion. Based upon the earlier description of
the 'information control' fields in Echo Mail messages, this
clearly is an error in processing (see Section b. entitled "How
it Works"). This further shows node 107/528 as the node which
apparently processed the message incorrectly. In this case the
path line can be used to quickly locate the source of duplicate
messages.
In an Echo with many participants it becomes almost impossible
to determine the exact topology used. In these cases the use of
the path line can help a coordinator of the Echo track any
possible breakdowns in the overall topology, while not
substantially increasing the amount of information transmitted.
Having this small amount of information added to the end of each
message pays for itself very quickly when it can be used to help
detect a topology problem causing duplicate messages to be
transmitted to each system.
g. Gating of Echo Mail
Until recently, the only network which made use of the methods
described above was FidoNet. However, new networks have
appeared, and the problem of sharing Echo Mail between these
networks arose. (To avoid ambiguity, the term "domain" was
introduced to distinguish between networks such as FidoNet and
SIGnet.)
Sharing (or gating) of Echo Mail presents technical problems.
Put simply, the network addresses which are valid in one domain
may not appear in the messages of another domain.
The reason for this is that, if we consider only the net and
node fields of a network address (many mail processors are not
able to handle the zone and point fields), there is a high
possibility that a given address exists in another domain.
With net mail, this problem may be solved by enforcing the
requirement that inter-domain mail be sent directly to its
destination, or at least, to a gateway system.
With Echo Mail, the problem is more complex, due to the
information contained in the SEEN-BY and PATH lines (as
described above). These lines contain network addresses, and are
needed to prevent duplicate rings.
However, a strategy has evolved which will allow Echo Mail to be
gated.
Above all, only ONE system should be allowed to gate Echo Mail
between domains. This may be done on a world-wide or Zone-wide
basis. This system will be responsible for receiving the mail
from one domain, and feeding it into the other.
This is not enough. Due to the possibility of duplicate network
addresses, all SEEN-BYs and PATH lines should be removed during
the gating process. This explains why only one system should be
allowed to gate Echo Mail.
11. KLUDGE LINES
For the more technically minded, there follows an explanation of
the various kludge lines that IMAIL may place in messages.
A kludge line is generally defined as any line preceded by a ^A
(Control-A) character, and may be found either before the message
text itself, or after it.
a. EID
The EID is used only in Echo Mail messages. IMAIL does NOT add
this kludge to echo messages. It was 'invented' mostly for
reasons of dupe checking, but IMAIL will use other methods for
this purpose.
The format of the kludge varies; according to the specification
proposed by Jim Nutt, it may be:
^AEID zddd nnnccccc
where z is the zone modulo 16, ddd is the net modulo 4096, nnn
is the net modulo 4096, and ccccc is a message serial number.
The serial number is generated using the low order word of the
Unix time stamp shifted left 4 bits, with a nybble counter
appended.
b. FLAGS
This kludge is present in net mail messages only, and is used by
many mailers to give more information on how the message should
be treated. It is followed by one of more modifiers; some of the
more common ones are listed below.
1) DIR
Indicates that the net mail message should be sent direct to
its destination; it will NEVER be routed.
IMAIL allows you to specify whether mail should be marked
DIRECT or not. See the description of the Node Manager
(Chapter 5. Section e.)
2) IMM
Indicates that a message should be sent immediately. IMAIL
will never use this, and will always ignore it.
3) TFS
Truncate File when Sent. This is found only in file attach
messages, and indicates that the file should be truncated
when sent. ARCmail file attached generates by IMAIL will have
this flag set.
4) KFS
Kill File when Sent. This is found only in file attach
messages, and means that the mailer will delete the file once
sent.
Please note that ARCmail file attaches should NOT use this
flag. If the ARCmail file is deleted, the next time IMAIL
generates an outbound compressed file for a system, chances
are that it will have the same name as the last one sent (if
the file is generated on the same day, at least). If it is
then sent out to the system, and that system has not yet
processed the mail it had previously received, there is the
possibility that the file will be refused, overwritten, or
discarded.
5) CFM
Confirmation Receipt Request. This flag is set if the sending
system wishes to have an acknowledgement that the message was
read. As such, IMAIL does not intercept this flag; it is up
to the message editor to handle it.
6) RRQ
Return Receipt Request. This flag is set if the sending
system wishes to have an acknowledgement that the message was
received by your system.
Currently, IMAIL does not recognize this flag, since the
message header itself defines a similar bit. If the bit is
set, a registered version of IMAIL will automatically
generate a reply to the sending system.
c. FMPT
The FMPT kludge is used in net mail messages only. It is similar
to the TOPT kludge, except that it is used to indicate that the
message originate from a point system.
The format of this kludge is:
^AFMPT <orig point>
where <orig point> is the point component of the address of the
system originating the message.
d. INTL
The INTL kludge is used in net mail messages only. It indicates
that the message is destined to a zone which is different from
the one in which it originated.
The format of the INTL kludge is:
^AINTL <dest zone:net/node> <orig zone:net/node>
IMAIL will use this kludge to try to determine zone addresses,
as well as adding it to net mail messages it generates. Note
that in multi-domain environments (ie, systems which belong to
more than one domain, and thus more than one zone), IMAIL will
put an INTL kludge in ALL net mail messages it generates, even
if the destination and origin zones are the same.
e. MSGID
A MSGID kludge is used in all messages, be they net mail of echo
mail messages. They are automatically added by IMAIL when it
generates messages (Automatic Reply, AreaLink's messages, etc),
and used in duplicate checking.
The format of the MSGID follows the specification proposed by
Jim Nutt, which is:
^AMSGID: zone:net/node[.point]@domain xxxxxxxx
where zone, net, node and point are the address of the
origination system, and domain is the domain of the originating
system (eg. FidoNet, SIGnet, etc). xxxxxxxx is a serial number
which is derived from the originating system's address, a Unix
time stamp, and an internal counter.
IMAIL will automatically supply the domain by attempting to
derive it from the list of domains specified in IMSETUP (see
Chapter 5. section a. para 2)). If the zone number is not
recognized, no domain field will be added.
f. PID
The PID (Product ID) is appended by IMAIL to all messages it
generates. Following the specifications given by Joaquim
Homrighausen, the format of the kludge is:
^APID: <product> <version> [<serial number>]
For example, IMAIL 1.35 would generate the kludge as follows:
^APID: IMAIL 1.35
g. REPLY
The REPLY kludge is simply a copy of the MSGID of the message to
which you are replying. IMAIL currently does not generate this
kludge.
The format is as for MSGIDs:
^AREPLY: zone:net/node[.point]@domain xxxxxxxx
h. RESCANNED
IMAIL inserts this kludge in messages which have been exported
in response to a %RESCAN request. This way, when they are
processed by TOSS, they will not be exported to other system,
thus potentially creating dupe rings.
As of the current writing, only few other mail processor support
this kludge, so it is by no means a fail-safe method of
preventing dupes. Rescanning echo mail is ALWAYS dangerous, and
until some robust and standard method is adopted, it is best
to avoid rescanning altogether.
The format of this kludge (according to FSC-0057) is:
^ARESCANNED <addr>
where addr is the address of the system which requested the
rescan.
i. TOPT
To TOPT kludge is used in net mail messages only. It is used to
indicate that the message is directed to a point system, rather
than a "normal" node.
The format of this kludge is:
^ATOPT <dest point>
where <dest point> is the point component of the address. For
example, a message addressed to 2:310/11.22 will have:
^ATOPT 22
while the message header will contain the address 310/11.
Please note that IMAIL supports the "extended" message header,
which contains not only the net and node addresses (as per
standard), but also the zone and point field. However, since not
all software support this header format, the TOPT and FMPT
(below) kludges are added whenever necessary, and used when
examining inbound messages.
12. BATCH FILE EXAMPLE
The example given below is designed for systems running QuickBBS,
with FrontDoor as a mailer. It should be easy to modify for other
setups, but we can only write from our own experience.
ECHO Off
:START
CD C:\QBBS
FD
IF ERRORLEVEL 99 GOTO CLEAN
IF ERRORLEVEL 50 GOTO UNPACKMAIL
IF ERRORLEVEL 40 GOTO LOCAL
IF ERRORLEVEL 33 GOTO LOAD_2400
IF ERRORLEVEL 32 GOTO LOAD_1200
IF ERRORLEVEL 30 GOTO LOAD_BBS
IF ERRORLEVEL 10 GOTO OUT
IF ERRORLEVEL 6 GOTO ERROR6
IF ERRORLEVEL 5 GOTO ERROR5
IF ERRORLEVEL 4 GOTO ERROR4
IF ERRORLEVEL 3 GOTO ERROR3
IF ERRORLEVEL 2 GOTO ERROR2
IF ERRORLEVEL 1 GOTO ERROR1
GOTO START
:LOAD_BBS
CALL DOBBS.BAT
GOTO START
:LOCAL
BBS -L -E0
GOTO START
:CLEAN
rem Message Areas Maintenance
IMTHINGS KILL /D10 /N50
GOTO START
:UNPACKMAIL
IMAIL TOSS
IMPACK 1:all 2:all 3:all via 2:2/1
GOTO START
:ERROR1
CLS
ECHO *** Internal Error *** Programming Error
GOTO OUT
:ERROR2
CLS
ECHO *** External Error *** Missing File
GOTO OUT
:ERROR3
CLS
ECHO *** Insufficient Disk Space ***
GOTO OUT
:ERROR4
CLS
ECHO *** Modem not Responding ***
GOTO OUT
:ERROR5
CLS
ECHO *** Unable to Init Modem ***
GOTO OUT
:ERROR6
CLS
ECHO *** FOSSIL Error ***
:OUT
ECHO System .... Down!
13. MISCELLANEOUS INFORMATION
a. A Note about Capability
The term Capability, when referred to a mail processor,
indicates that program's ability to generate zone and point
information in outgoing mail, as well as the ability to
recognize and use such information in inbound mail
Currently, IMAIL distinguishes between two forms of capability:
"Stone Age" and "Type 2+". "Stone Age" means that the packet
contains no zone and/or point information, and thus IMAIL is
forced to guess at their value; "Type 2+" indicates that the
packet contains zone and point information, and IMAIL knows
where to look for them.
"Type 2+" mail packets are distinguished from the others by
means of a Capability Word and a Capability Word Validation Copy
(as outlined in the document FSC-0039). However, there are
several mail processors which produce valid zone and point
information, but do not mark the packets as "Type 2+". In order
for IMAIL to correctly extract the zone and point fields from
these packets, they must be marked as
Capability: Type 2+
Cap Handling: Forced
in the Node Manager (see Chapter 5. Section e.). In other words,
you should enquire as to which mail processor echo node is
using, and set these two fields accordingly.
Examples of mail processors which produce Type 2+ information
are:
Product Product Code
--------------- ---------------
D'Bridge 1A
GEcho 61
Qmail 29
ScanToss 82
TosScan 3F
ZmailQ 35
Some of these do not (yet) make use of the Capability Word, but
it is possible to "tell" IMAIL that a mail processor has Type 2+
Capability by indicating its product code in IMSETUP (see
Chapter 5. section a.).
For other mail processors, unless you are certain of the
contrary, the best is to set the two capability fields to "Stone
Age"/Auto.
b. Defaults for Compression/Decompression
For reference, below are listed the default parameters for the
compression and decompression programs as you would see them
when installing IMAIL for the first time.
1) Compression
Arc.Exe mw
Arj.Exe m -c -e+ -y -i
Lha.Exe m /m2n1t1
Pak.Exe m /WN /ST. /P
PkArc.Exe -ot m"
PkZip.Exe -m -ex -o
Sqz.Exe a -o1
Zoo.Exe aMPh:
2) Decompression
Arc.Exe xw
Arj.Exe e -c -i -y
Lha.Exe e /c1m2n1
Pak.Exe e /WA
PKUnZip.Exe -ed -o
PkXArc.Exe -r
SQZ e
Zoo.Exe eO
c. Files Maintained by IMAIL
IMAIL and IMSETUP create and maintain several external data
files. Generally it is NOT a good idea to delete these unless
you wish to rebuild your configuration from the beginning.
Of these files, all those containing IMAIL's configuration
information (ie, all those whose name begins with IMAIL) should
reside in the directory from which IMAIL is run, or, if you have
set the IMAIL environment variable, in the directory it points
to.
IMAIL.CF Basic IMAIL configuration information,
including network addresses, Pack Routing and
so on.
IMAIL.AR Contains the definitions of the echo areas. If
this file is deleted, ALL echo area
information will be lost. This file is updated
by AreaLink, if necessary, and is usually
maintained via IMSETUP.
IMAIL.AX Index file of echo area information, according
to area name. This file is maintained and
updated both by IMSETUP and IMAIL. It may be
deleted (in which case you will need to run
IMSETUP to recreate it).
IMAIL.BX Index file of echo area information, according
to Hudson board number. This file is
maintained and updated both by IMSETUP and
IMAIL. It may be deleted (in which case you
will need to run IMSETUP to recreate it).
IMAIL.ND This file contains the information defined in
the Node Manager.
IMAIL.DP Data base of information used to catch
IMAIL.DPI duplicate messages. This file may be deleted,
but then you risk missing incoming dupes.
IMAIL.PR This is a compiled version of the FTSC product
code list (which is usually distributed as
FTSCPROD.xxx, where xxx is a decimal number).
IMAIL.GR The Group Database with the names and the de-
fault settings for the groups.
????????.$I$ A packet file (????????.PKT) that was being
processed by TOSS. You should only find these
files if there was a system crash during a
TOSS. In order to process it, simply rename it
to ????????.PKT and run IMAIL TOSS again.
d. Exit Codes
Should an error occur while IMAIL or IMTHINGS are running, both
programs will exit with an error, and set the MS-DOS ERRORLEVEL
environment variable. This may be tested in a batch file, and
acted upon. Listed below are the ERRORLEVELs returned by IMAIL
and IMTHINGS.
ERRORLEVEL Meaning
0 No error
1 TOSS/SCAN process net mail
2 TOSS/SCAN processed echo mail
4 TOSS/SCAN processed bad mail
8 TOSS/SCAN processed Hudson mail
16 TOSS/SCAN processed *.MSG mail
32 TOSS/SCAN processed Squish mail
64 TOSS found mail to the sysop
238 Cannot create directory
239 File locking error
240 Error opening IMAIL.AX
241 Error opening IMAIL.BX
242 Index file missing or corrupt
243 IMAIL.CF not found
244 IMAIL.AR not found
245 IMAIL.ND not found
246 Error in IMAIL.CF
247 Bad version of IMAIL.CF
248 Error opening file
249 Error reading file
250 Error writing file
251 Command line parameter error
252 File not found
253 Memory allocation error
254 Disk full
255 Unknown (generic) error
The errorlevels 1-64 are also indicated by a set of semaphore
files which area created in the semaphore directory when IMAIL
exits. This makes the evaluation of the errorlevels much easier:
IMAIL.NET TOSS/SCAN processed net mail
IMAIL.ECO TOSS/SCAN processed echo mail
IMAIL.BAD TOSS/SCAN processed bad mail
IMAIL.QBS TOSS/SCAN processed QuickBBS Areas
IMAIL.MSG TOSS/SCAN processed Msg Areas
IMAIL.SQU TOSS/SCAN processed Squish Areas
IMAIL.PER TOSS found mail to the sysop
14. IMAIL REGISTRATION SITES
a. Headquarters
IMAIL INC.
System: FidoNet 2:246/47
intlnet 57:49/0
Snail Mail: Andreas Klein
Werner-Heisenberg-Weg 102
W-8014 Neubiberg
Germany
b. Australia
IMAIL Support & Distribution Australia
System: FidoNet 3:632/350
intlnet 58:4100/31
Snail Mail: Bob Snowdon
17 Witham Drive
Coldstream, Victoria
Australia 3770
c. C.I.S. (ex-USSR)
IMAIL Support & Distribution C.I.S.
System: FidoNet 2:495/21
Snail Mail: Egons Bush
20 Virzas str.
District Bauska
Iecava, Latvia
LV3913
d. Europe
IMAIL Support & Distribution Europe
System: FidoNet 2:285/304
intlnet 57:3101/100
Snail Mail: Henk Heidema
Vinkplein 64
3334 VH Zwijndrecht
Holland
e. Italy
IMAIL Support & Distribution Italy.
System: FidoNet 2:285/304.100
intlnet 57:3901/100
Snail Mail: Fabiano Fabris
Via Zardini 19
33090 Sequals (PN)
Italy
f. North America
IMAIL Support & Distribution North America (North)
System: FidoNet 1:153/923
intlnet 57:3106/110
SIGnet 25:4604/198
Snail Mail: Hardy Rosenke
P.O. Box 1240
Tsawwassen, BC
Canada V4M 3T3
IMAIL Support & distribution North America (South)
System: FidoNet 1:10/100
intlnet 57:49/22
Snail Mail: Pablo Kleinman
1353 N. Martel Ave, Suite 320
Hollywood, CA 90046
U.S.A.
g. Sweden
System: FidoNet 2:204/503
intlnet 57:4604/302
Snail Mail: Jonny Bergdahl
Lillgatan 34B
S554 51 Jonkoping
Sweden
h. United Kingdom
System: FidoNet 2:254/44
intlnet 57:4401/2
Snail Mail: Cliff Jones
96 Whiting Road
Lowestoft
Suffolk NR32 3QB
UK