home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Black Box 4
/
BlackBox.cdr
/
bbs_mail
/
ee_030.arj
/
ENGINE.DOC
< prev
next >
Wrap
Text File
|
1991-07-04
|
34KB
|
874 lines
▄▄▄▄▄▄▄▄▄ <Last updated 7/4/91> 0.30 *release* documentation
██
██ ▄▄▄▄▄▄ █ █ ▄▄▄▄▄▄ ▄▄▄▄▄▄▄▄ ▄▄ ▄ ▄
██▄▄▄▄▄▄▄ █ █ █ █ █ █ █ █ ▄▀ ▀▄ █ █
██ █ ██████ █ █ █ █ █ █▄▄▄▄█ █ █
██ █ █ █ █ █ █ █ █ █ █ █ █
██▄▄▄▄▄▄▄ █▄▄▄▄▄ █ █ █▄▄▄▄█ █ █ █ █ █ █ █▄▄▄▄
▄▄▄▄▄▄▄▄▄
██
██ ▄▄▄▄▄ ▄▄▄▄▄▄ ▄ ▄▄▄▄▄ ▄▄▄▄▄▄
██▄▄▄▄▄▄▄ █ █ █ █ █ █ █
██ █ █ █ ▄▄▄ █ █ █ █▄▄▄
██ █ █ █ █ █ █ █ █
██▄▄▄▄▄▄▄ █ █ █▄▄▄▄█ █ █ █ █▄▄▄▄▄
■ By Joe Jared of 1:103/200@Fidonet.org ■
Contents:
CONFIGEE.EXE --- Compiles Raw text files to Database configuration.
EEPACKER.EXE --- Compresses Outbound mail using various packers as
Defined, or using routing information.
EESERA.EXE --- Scanner from Hudson to FTSC packets. <ALPHAKEY req'd>
EE.EXE --- The String that binds all of the utilities together.
This utilities reacts to situations on the fly as
they occur, to allow as fluent a flow of traffic as
possible. It's capabilities are far in excess of a
simple batch file, in that it checks your system for
various circumstances that dos cannot, and reacts
according to what results it finds.
EEMOVER.EXE --- For multinode systems. This program enables multiple
working outbound directories for Binkley systems,
without the need of .BSY flags in the least. It is a
secondary processor, that focuses on sharing
violations, and is designed to operate in conjunction
with EEPACKER in the shell environment.
FloMover.EXE --- For multinode Binkley systems only.
This program is used to move the stray flo files that
are created by various utilities to the multinode
outbound directory that is shared by 2 or more lines.
It does not use nor does it need the .bsy flags in
Binkley v 2.40 or later, but requires that share be
loaded to handle file sharing violations. If a file
listed in the flo file is not marked for deletion or
truncation, it is marked as read only, to assure that
if it is to be distributed on multinode systems
concurrently, that no file sharing violations occur.
PKTTOOUT.EXE --- For rebuilding of outbound directories. This program
will rename all .pkt files in the specified directory
and then call EE PACK to repackage them.
SENDDIFF.EXE --- This utility is used to aid in the distribution of
nodediffs of various flavors. It will create various
flavors of nodediffs, and allow you to script just
who gets what compression method.
Description:
Echomail engine is a fidonet technology Net/Echomail processor,
designed specificly for the hudson and future related
structures. Also included is a generic Shell environment, to
improve the process you already have with your current mail
processor. This shell environment is expandable to your needs,
and in addition, will react on the fly to changes in netmail,
badmsgs, drive space, and other problems as addressed in
EE_Support. The goal for the shell environment is 0 downtime.
Limitations:
Echomail Engine has the following limitations:
Up to 64000 bytes of text space in each message processed.
<FTSC does not define a limitation, and messages generated in
excess of this size will NOT be processed by this program.>
Up to 30 AKA Addresses in EE.cfg
Up to 255 node definitions in EE.CFG for echomail distribution.
Up to 1000 Nodes in routing information. A Global definition is
considered One node entry. <Refer to Routing>
Up to 2000 conferences in Areas.bbs
Up to 60000 node entries in Areas.bbs
255 characters per line in Areas.bbs
Up to a total of 10 packers and primary outbound directories.
Configuring Echomail Engine:
There are 2 files that Echomail Engine uses.
-------------------------------------------------------------------------
EE.CFG Configuration information
Keywords:
Debug_ON
This statement turns debug information on, allowing you to watch
the config file as it's compiled, to aid in searching for
problem areas in your config file.
Debug_OFF
This statement turns off debug information.
Ext_Tosser
This statement is a keyword that means that you are not using
Echomail Engine to Toss incoming mail, and have no need for the
duplicate index. Each entry in the duplicate index occupies 8k
of drive space, and accounts for 2000 messages per conference.
Sysop Joe Jared
This statement is for netmail and registration purposes. When
netmail is received to Sysop at any of your aka addresses,
it is automatically remapped to the name as defined,
to make sure that you receive all mailaddressed to you.
It is also used in the registration information,
and is not case sensitive.
Serial_No 91-0001
This line should only be used if you've received a registration
key. If you haven't, do not use this line. It will immediately
abort if this line is found and the key information is not
found.
Address 1:103/201.0
Address 8:911/301.0
Address 144:144/1.0
Up to 30 addresses can be defined
This is a full 4d address, and your primary address should be
first. The primary address should always be the first listed
address. The first listed address is used in generating a
operating key.
Note: Multiple Addresses in the same ZONE will do nothing more
than add the number into the SEEN-BY's.
The first number of each respected Zone is Always used in sending,
but mail to other AKA's will be accepted.
Pointnet 10200
This number is used as the fakenet address for mail addressed to
points. Any mail addressed to points on your system will
automatically be remapped to the correct point by creating a
packet of Pointnet/point. Also, for normal distribution of
echomail, the fakenet/point will be included in your point's
mail only. Normal traffic to nodes will not have this
information.
Key 123456789
This information should only be included if you've registered
the product. Having this information in place without
registering the product will cause a failure.
RA_Msg_Dir L:\FD
This is where your hudson type message base should be found.
NetMail_Bd 14
This is the board number of where your netmail will be imported
to/exported from.
Netmail f:\line1\mail1
This is where all file attach messages can be found.
NOTE: When routing netmail, Echomail Engine imports the mail
to other systems, and later exports it into packet format.
Routed netmail never hits your netmail directory.
Netfile j:\line1\Inb1
KnownFile J:\Line1\Inb1
SecureFile J:\Line1\Inp1
Standard Inbound directories used in Binkley
*** Front Door/D'Bridge systems only use NetFile ***
This is where Echomail Engine expects to find Compressed and
uncompressed packets for processing.
Status_Log EE.CFG
Optionally, a log file can be generated, to allow you to see the
kind of traffic that is going through your system. The next
keyword will explain in detail the levels of logging that can be
done. Status_Log must be defined, to operate properly. If
undefined, it will not create a log file at all.
<This segment did not make it into 0.30 >
<->
LogLevel 65535
This statement sets an internal group of flags < 16 bits>, to
allow you to save information of mail processed. Each Bit will
activate a single part of the logging to disk that you desire.
The bits are as followed, and for each level defined, add the
numeric value to suit your individual needs.
Bit value Discription
0 1 Log all mail exported from your message base.
1 2 Verbose log of exported mail. <Who/From/Subject>
2 4 Log the number of messages sent to each node.
3 8
4 16
5 32
6 64
7 128
8 256 Log packet header information of inbound packets.
9 512 Summarize at each packet.
10 1024 Verbose log of routed netmail thru your system.
11 2048
12 4096
13 8192
14 16384
15 32768 Log All packing and routing occurances.
<->
Defined_Zones 1 2 3 4 5 6 144
|
| This line is used to determine whether or not EE should place an
| outbound file in a properly pathed directory, or to place the
| outbound packet in the bad_Zone directory. adding Zones to this
| line will automaticly create the proper directories for
| operation, as long as the zones are between 1 & 4095.
v
BAD_ZONE l:\outbound\badZone
This is the directory where mail generated to other zones that
do not have a holding directory are kept. Typically, you'll
find netmail here, because directories will be automatically
created as needed. The filenames of packets found in this
directory will be as follows:
aaaabbbb.zzz
aaaa = Net <hex>
bbbb = Node <hex>
zzz = Zone <hex>
All characters to the left are '0' padded.
Example: 9:103/103 = 00670067.009
Outbound l:\Outbound\out <Do not give this directory an
extention>
Your Primary outbound directory.
Note: This software does support multiple outbound directories,
in Conjunction with EEMover and MoveMail.exe. Each of these
programs handle a specific feature, to better improve speed and
performance. Multiple outbounds are only supported for binkley
at this time, but in the future, other mailers will be supported
as time allows. <Refer to packers for details.>
The following example describes the definitions of how outbound
directories are calculated:
Primary system address = L:\Outbound\Out
OtherZone matrix mail outbound = L:\Outbound\out.hhh
hhh = the Destination Zone address <3 digits hex, 0 padded>
Example: Zone 144 = L:\outbound\Out.090
There is no longer a need to 'calculate' and create these
directories, as Configee.exe does this for you.
<Refer to Defined_Zones.>
DupeFile_path j:\line1
Note: This is the directory where EE_Dupes.dat & EE_Dupes.idx will
reside. EE_Dupes.Idx will be imported into Areas.Dat, which is
later discussed in this manual. Areas.Dat is 8192 bytes per
conference added, and should remain constant in size once all
areas have been added. If this line is not defined, the files
will be created in the root directory of the drive you are
operating in.
Dupes f:\Line1\mail1
This is the directory where dupes will be kept in the FTS-0001
format of a stored message.
Max_Pkt_Toss
Maximum ammount of packets in total bytes that will be processed
in a single pass of your tosser.
Max_Packets 10000000 12
Maximum ammount of packets per number of hours it processes mail.
This feature is designed to limit the overflow that comes from having an
uplink who's been down for days, thus shutting your system down.
Only use this feature if you have problems. Default should be sufficient
protection for downlinks...
MAX_ARCSIZE 500000
The maximum size allowable to add to the same arcmail bag. If
the destination mailbag is already over that size, it will increment
to the next higher archive sequence. Default is 100000 bytes.
Mailer 0 Binkley
Mailer 10 FrontDoor 1.99c
Mailer 11 FrontDoor 2.xx? <Reserved for future implementations>
The type of front end mailer you are using. All mailers that
support flags in MSG attach systems use Mailer 10, as that
application uses ^AFlags to Truncate the file when sent.
Anything other than 0 or 10 will default to Binkley mode
at this time, so please handle this with care.
Sizer_Cmd Sizemail.exe
This program will be called prior to packing archives, and is
reserved for a pre-processor prior to archiving mailbags.
Note: Internally EEPacker and EEMover both support sizing of
arcmail bags, but you may chose to use an external sizing
program. If you do, set MAX_ARCSIZE to an ungodly number
totally unaccessable by a single run of your process. Default
for both the mover and packer is 100k.
Unpacker_CMD Spaz.com -d %N *.pkt
This command will be executed in place of the internal
de-compressor, for future compatibility issues.
%N is a fully qualified path name, and if the program is not in
the current directory, it will need to be fully pathed.
If Unpacker_Cmd is commented out, it will recognise on its own
the existance of the following file compression programs:
Arc<PKPAK 3.61 and prior and SEA/ARC V6.02>,
ARJ <2.00 & prior>,
No-Gate's PAK < 2.52 and prior>
LHA <2.12 and prior>,
and PKZip <1.10 and prior>.
The following are example implementations of each compression
method, using _direct_ calls to the decompressor programs.
ARC_Unpack F:\Arc\PKUnpak.EXE %N *.PKT %D
ARJ_Unpack f:\ARC\ARJ.EXE e %N *.PKT %D
PAK_Unpack F:\Arc\PAK.EXE E %N *.pkt %D
LHA_Unpack f:\Arc\LHA.EXE %N *.PKT %D
ZIP_Unpack F:\Arc\PKUnzip.exe %N *.PKT %D
Scanner_Cmd EESERA.EXE SCAN
Scanner_Cmd QM.EXE Scan Pack -z
These command lines tell Echomail engine what processor to use
in scanning of echo and netmail from your bbs to outbound
packets. If you are using a hudson format message base, it will
only be called if Echomail.bbs exists in the current directory
in TossScanPack mode, and will be unconditionally be called in
ScanPack or Scan mode. Other systems that do not support
quickindex files will be called unconditionally in all modes.
Note: If you are not using any engine utilities for tossing or
scanning of echomail, add the following line to inhibit the
creation of dupe files used with Echomail Engine into EE.CFG
Ext_Tosser <Inhibits creation of EE's Dupe files.>
Tosser_Cmd QM.exe Toss scan -q -z
Tosser_CMD EESERA.EXE TOSS SCAN
This command allows you to run a program other than Echomail Engine
To import mail. It is called in as many passes as required to
complete you import/parse process.
Mover_CMD EEMover.EXE
For multinode use only: This program is called after all mail
in the primary outbound directory is processed. Generally, it's
used to packup all outbound mail in other directories. If you
are running a single node system, do not use this program, as it
will slow your process down.
OutPAcker_CMD EEPacker.EXE
This statement is called to packup all outbound mailbags to
archived format. What ever program you use should also create
the appropriate attach format.
<The following segment is not fully implemented in release 0.30>
At this time it will call Areafix after all Echomail has been processed
if defined to do so.
<->
Areafix_Cmd Areafix.exe EC
This program will be called at the end of the current process,
but only if the following circumstances occur:
1> Netmail high message number increases after toss.
2> BadMessage directory HImsg number increases.
<->
NetPacker_CMD QM.EXE Pack
Packers ( Up to 10)
Pack ARC f:\ARC\PKpak.exe -oct -m %N %P %D
Pack LHA F:\ARC\LHA.EXE m /x /m %N %P %D
Pack PAK f:\ARC\PAK.EXE M %N %P %D
Pack Zip f:\ARC\PkZip.exe -ex -a -m %N %P %D
These Are Pre-defined PAckers, and must be defined before
defining Nodes. Parameters are as follows:
%N = Fully Qualified archive name to be sent
%P is the packet name after renaming it to FTS packet name.
%D will employ a direct call to the packer, without calling
a dos shell. Make sure that your compressor program is not
in the current directory, or it may have adverse effects.
Also, use suggested formats.
The packer MUST be configured to delete the packet after compression,
and The above examples will work as advertised. Errorlevel returns are
ignored, and the fact that the packet dissappears is used to
determine whether or not the compression is successful.
For routing purposes, all mail to undefined Zones will default route
using OLD COMPRESSION TECHNIQUE. Be sure to unpack and repack their
Outbound files before changing packers!
THE SAMPLES DO WORK.
The following kludge is a multiline kludge.
The existance of the %M in the line signifies that the destination path
is where the file will be renamed to. This path must be on the
same drive as your primary outbound directory.
After each pack sequence if a MOVER_CMD is defined, that program is
executed, to compress the moved mail.
Pack MOVER j:\line2\out2 %M
Pack MOVER j:\line2\out2 %M
This keyword simply means to rename the file to a packet,
And generate a list file in the appropriate flavor, using
The following Parameters:
%M is a *flag* to move the file, and *NOT* a program execution!
The first word following the destination path, is a remap parameter.
This feature does not work in any environment other than Binkley and
Other oMMM bundling environments. This feature *only* works when
The destination is the same physical drive.
Sequence for this kludge is as follows:
Verb Type Dest_Path Trigger_flag
Pack MOVER j:\line2\out2 %M
Other strings can be made available as needed
Note: .BSY flags are not required for this move, and are not
useful in all applications. Standard practice in multinode
environments is to load SHARE <A dos utility> before loading
any multitasker or File server software. EEPACKER performs the
packing of outbound files, and routing. In the case of
multinode systems, EEMOVER will finish the job by checking to
see if the flo file for the destination system can be hidden,
and if so, it proceeds to pack mail for that node.
------------------------------------------------------------------------
AreasFile 103-200.Lst
AreasFile Echomail parsing information
These files are compiled into database format when ever the date
stamps of either has changed, and during this process, it will
point out problem areas in your configuration, in either
'WARNING', or 'FATAL ERROR' mode. If a warning has occured, it
will continue processing, and allow echo/netmail processing to
continue. If a fatal error has occured, it will abort
compilation of the database files, and beep signifying that it
has an error.
-----------------------------------------------------------------
Note: Before a system can be sent echomail, that system must be
qualified via the '@ Zone:Net/Node FLAVOR PACKER' in EE.CFG.
Failure to do this will result in not adding them to the database.
-----------------------------------------------------------------
This is the name of the control file for use in parsing of
incoming echomail. It can be fully qualified file name.
If this line is not defined, the default will be AREAS.BBS
The structure of the file is as follows:
First word : Board number, P, or # as the first letter of the first
word.
Second word : Conference Areaname
Remainder of the line : The nodes you feed, in long or short, or tiny form.
Example Long form listing:
1 ORANGE_CO 1:103/100 1:103/350 1:103/201
Short form listing.
1 ORANGE_CO 1:103/100 201 350
1 ORANGE_CO 103/100 201 350
Also, tiny form is available by the design structure, but
not recommended for utilities like Areafix, unless they are
specificly stated to work using this method.
1 ORANGE_CO 100 201 350
The first entry, if no net number is defined, will go to MYNET/.
In all entries, 103/100 is listed as the feed for the
conference, it is imported into Board 1 of RA, and sent on to
103/201 and 103/350. For point operation, use the fakenet
address. Example: To add .1 to this conference, using the
fakenet address of 10200, you would then have a areas line that
looks like this:
1 ORANGE_CO 1:103/100 201 350 10200/1
In this listing, 103/200.1 is now listed in the distribution for
ORANGE_CO. Most importantly, your points should have in their
control file point to your primary address. Example:
1 ORANGE_CO 103/200
Message_Type RA
The type of Database you are using for your bbs.
Acceptable format's will at some future date will be:
NEWMaximus <Non .msg format>
PCBOARD
TELEGARD
WILDCAT
NODES
This section is where your downlinks and uplinks are defined.
This section defines the compression method to be used, as well
as the flavor of routing. Sysop name is optional, and will be
used in all file attach messages for echomail distribution when
used with Message attach systems, like Front Door and D'Bridge.
However, I do suggest that you enter the sysop's names, because
you may not be pleased with the default. <grin>
Any time the @ Symbol is found as the first word of a line, it assumes
you are defining a node entry. These entries can exist anywhere in the
file.
Syntax
@ Zone:Net/Node Flavor Compressor optional_Flags
Allowable optional flags:
%O - Use old Arcmail extention for this node. <Opus 1.03 and prior>
This flag forces the file extention to start with MO with the last
digit being a number from 0 to 9. Most systems support a higher
convention than this, so this is considered a non-standard
compressed naming convention.
The default naming convention of arcmail is to use the first 2
letters of the week the mail was compressed, with a number to
signify which mailbag of the day is being created.
%E - Extend the arcmail extention to include all of the letters of the
alphabet except T. <T confuses Binkley>. This flag in particular
helps to better control the size of the archived mailbags, by
allowing the extentions to go as high as ??Z for a potential of 35
different arcmailbags per node before cycling back to 0.
However, some software on other systems do not support this feature,
so use it carefully.
Do not use this feature on ANY version of OPUS as of this date,
without permission of the sysop you are feeding.
Examples:
@ 1:103/100 Crash ZIP
This line tells the packer to Pack all mail with PKZip, and to
send it crash.
@ 1:103/102 Crash ZIP
@ 1:103/105 Crash ZIP
@ 1:103/200 Crash ZIP Joe Jared
@ 1:103/208 Hold ARC
This command tells the packer to pack with PKPAK, and send with
the hold attribute set.
@ 1:103/241 Crash ZIP The Kestral
This command tells the packer to send crash ZIPmail, and to
address the attach to 'The Kestral'.
<This feature is not in Release 0.30>
@ 143/302 Hold MOVER
By the defination I previously showed for MOVER, all mail to an
address using a %Multinode move will not really be packed by the
packer, but rather moved for later processing. This process is
very fast, so don't blink, or you'll miss what happened. If
your system beeps at you, immediately look in your status_log
file. It will return the results of the failure to you.
@ 69:1000/7 Normal Sir DEP
This line basicly allows your routing section to take priority,
instead of defaulting to crash or hold.
Routing <Routing information> <Limit 1000 nodes>
Before I go into the explaination of this specific section, I'd like to
Explain the limitation involved here.
When you're setting up routing of mail, consider the order with
which you are routing. This route section is a *sequential* routing
scheme, meaning that the first statement that meets the qualifications for
packing mail to a specific address will hold true. Make sure you have
default definitions for your own net, Zone, and the other 6 zones. The
definition of a node entry as it relates to the limitation of the
Routing.Dat file can be calculated as the number of entries whether global
or defined.
Example:
Route Crash 1:103/100 102 103 104 2:all 1:102/all
This line is considered 5 nodes towards the limitation.
In the routing.dat, 5 nodes will be defined in the routing file.
1:103/102
1:103/103
1:103/104
2:32767/32767
1:102/32767
65535 is an unused addressing scheme, and is a key number that defines
All mail in that particular Zone or net by default gets sent to the defined
address. For Routing of netmail, the destination node for the routed mail
need not be defined unless you would like to send anything other than the
default compression method, or uncompressed mail to that specific address.
Note: For your own net, add the following line, so that unlisted nodes
using Yournet/65535 may get a response from you:
@ Yournet/65535 Hold Arc
Personally, with all of the conflicts in how various software
determines net/node addressing, I don't recommend new nodes
using a -1/-1 address. For new nodes requesting an address, I
recommend something like Yournet/999 or Yournet/9999
Defined nodes take first precedence, and if a node is undefined,
Routing information is then used.
-----------------------------------------------------------------------
Send <Flavor> <Destination_Address> Nodes
<Currently under construction>
This is the default list of nodes you wish to send to. Example:
Send Hold 1:103/all 102/all
In this example, unless a node in Net 102 or 103 is previously
defined, it will generate a hold attach for nodes that fit into this
definition. I cannot emphasize enough the 'sequence' of operations in
routing, and will show you an example that will NOT work.
Example:
Route Crash 1:103/100 103/all
Send Hold 1:103/all 102/all
In this example, 103/100 has been defined to handle all
undefined nodes in net 103. The line immediately after that defines all
nodes with HOLD status. Since the nodes in net 103 are already
previously defined, the entry to Send to net 103 on hold status is
ignored.
-----------------------------------------------------------------------
Route <Flavor> <Destination_Address> <Nodes> .. .. ..
This commandline option will define how netmail destine to nodes
not defined in EE.CFG will be routed. All routing is setup in
priority of the first listed address. Example:
Route Crash 1:103/100 1:all 2:all 3:all 4:all
Route Crash 1:103/501 1:all
In this case, mail destined to anyone in Zone 1 would be routed
to 103/100, because it matches with the first listed address.
The only accepted routing flavors in the route statement are
CRASH NORMAL and DIRECT.
Note: if the address that you are routing to is not defined in
the nodes section of EE.CFG, the first compressor listed will be
used to compress this mail. By default, the first definition
should be ARC, using Old compression technique. Although ARC
can be totally removed, it's not recommended.
The following is the 'thought process' of my current routing section to
better define how this system 'thinks'. Think of the routing scheme as
a thought process, and where the first match occurs, action is taken.
Route Crash 1:103/158 158 69:all
Send all mail destined to Zone 69 to 1:103/158
Route HOLD 1:116/1000 3000
Route Echomail previously defined as 'NORMAL' destined to 116/3000 to
1:116/1000
Route Hold 1:157/2 157/3
Route all mail destined to 157/3 to 157/2
Route HOLD 1:282/44 22
Route HOLD 1:3807/1 380/5
Route Hold 1:10200/2 1:103/210
Route Crash 1:103/350 1:103/300 307 355
Hub route these addresses.
Route crash 1:103/100 0 106 115 121 122 125 130 134 136 143 145 148 150 155 156 158 160 165
Route crash 1:103/100 310 315 328 320 332 335 338 340 345 507 602
Route Crash 1:103/100 900 901 908 910 912 913 916 917 918 921 925 929 930 935
Route Crash 1:103/100 280/all 374/all 362/all 991/all 112/all 212/all 379/all 33/all
These too.
Route Crash 1:103/227 0/0
What can I say, he's the worst offender... <g>
Route Crash 1:109/25 109/all
Route all mail destined to net 109 to The 109/25
Route HOLD 1:202/701 202/all 2:all 3:all
A bit more on this part.
Route Crash 1:103/229 329
Route Crash 1:103/501 10/all 1/All 102/all 151/all 13/13
Route Crash 1:103/501 4:all 5:all 6:all
Route Hold 32767/1 1:103/all
For test purposes, I unpack all other mail at a time when I have a
chance to look at it.
Route Crash 1:32000/1 1:all
Everything else pack to a non-existant address to go no where real fast.
<For testing purposes>.
------------------------------------------------------------------------------
Other tossers may be implemented in the shell environment, as all of this
is fully configurable. This section will describe how to use the engine
with various processing packages.
Using external tossers with the Shell environment:
QMail Copywrite (c) Greg Dawson (1988,1989) & George Peace.
When you operate with Qmail, take the following into consideration,
to assure your downlinks a smooth transition:
Turn Max_Msgs off, and instead, configure the engine to the largest
total number of packets to process in one pass of QM Toss SCAN -z.
Comment out the Routing file in QM.CFG and define your routing in
EE.CFG. If you are gating, you may need to have a gate route
statement, but it's only NOARC NORMAL route statement should be in
the file, to assure that Qmail does no packing of outbound .OUT
files. Also, for scheduling purposes, EE_SKUD will do the job in
the near future. I hadn't planned on it, but found that several
Coordinators use Scheduling Exclusively. EE_SKUD will make up for
the weaknesses in the routing of the other Echomail and default
routing of outbound .out files. Also, refer to SAMPLE.CFG that comes
with this package for efficient operation. I let EE unpack all
archived mail, and Qmail does not see archived mail in any inbound
directory, using the following command line in QM.CFG
NETFILE NOARCMAIL j:\line1\inp1
Using this method, Qmail will only find .pkt files, and will leave
Arcmail alone. The intention behind this method is so that Echomail
Engine can tell whether or not it's 'safe' to unpack and process
mail. 'Safe' is the defined ammount of drive space required to
unpack incomming mail to the current operating directory.
Suggestions are welcomed in improving of this process.
Qecho <Copywrite Quickbbs Group>
When using Qecho, use oMMM bundling to process mail. <-Z instead
of -A>. Recommended parameters for tossing & Scanning are as
follows:
Tosser_Cmd Qecho.EXE -t -u -p -z
Scanner_Cmd Qecho.EXE -e -p -z
Also, in Qecho.Ctl, make sure that OutboundPath points to the
same directory as Echomail Engine.
---
For additional support with various implementations,
request from your uplink EE_SUPPORT for access to the conference
dedicated to developement and support of the Engine.
Although the product is not yet fully released, all ideas will be
considered, trashed, or discussed, in that order.
Joe Jared
1:103/200@Fidonet.Org