home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Crawly Crypt Collection 2
/
crawlyvol2.bin
/
program
/
c
/
berm122s
/
update.doc
< prev
next >
Wrap
Text File
|
1993-08-16
|
12KB
|
384 lines
Bermuda 1.22
============
Modifications by Vincent Pomey (2:320/100.2) and Franck Arnaud (2:320/100)
Cruncher by Vincent Pomey
See the LICENSE file for details about source code distribution policy
and READ.ME about binary code distribution policy.
Built-in archiver support
=========================
Import now detects the type of arcmail, and launches the correct
archiver. The following keywords have been added to tb.cfg:
arcunpack <path> <command-line>
zipunpack <path> <command-line>
arjunpack <path> <command-line>
zoounpack <path> <command-line>
lzhunpack <path> <command-line>
In the command line, %n is replaced by the name of the archive, and
%d by the path where the packets will be extracted. %% is replaced by a
single %.
For example:
arcpack e:\bin\arc.ttp x %n %d*.*
Pack also supports various archivers; the arcmail command in the
route file has been "replaced" by the new commands:
arcmail <nodes>
zipmail <nodes>
zoomail <nodes>
arjmail <nodes>
lzhmail <nodes>
This of course means that <nodes> will receive the arcmail type
you choose, and the correct archivers will be called according to the
new keywords in tb.cfg:
arcpack <path> <command-line>
zippack <path> <command-line>
arjpack <path> <command-line>
zoopack <path> <command-line>
lzhpack <path> <command-line>
In the <command-line>, %n will be replaced by the full name of the
mail archive while %p will be replaced by the full name of the packet,
%d by the directory where the packet reside and %k by the name of the
packet without path.
For example:
arcpack e:\bin\arc.ttp a %n %p
If you use Arc/ST 6.02, STZip 2.1, Quester LHarc 2.01, Zoo 2.1, UnARJ
1.00 by J Webb, we suggest the following configuration:
arcunpack e:\bin\arc.ttp xo %n %d*.*
zipunpack e:\bin\stzip.ttp -xo %d %n
lzhunpack e:\bin\lharc.ttp x -m %n %d
zoounpack e:\bin\zoo.ttp -extract %n %d*
arcpack e:\bin\arc.ttp m %n %p
zippack e:\bin\stzip.ttp -am %n %p
lzhpack e:\bin\lharc.ttp m /m %n %p
If you don't use this feature, the old -a command line command still
works as usual.
Pass-thru areas
===============
If you are a large node, you may redistribute many echos you or your
users don't read, and it takes some time to process and/or to scan.
Now, if the <path> of the area is "passthru" in areas.bbs, Import
will not write the messages to the message base, and Scan will not
try to scan this area.
For example:
e:\msgs\0100 ATARIST 2:1000/1
passthru AMIGA 2:1000/1 2:1234/5 2:34/56
passthru KITCHEN 2:78/78 2:1902/2890
no-hold keyword in tb.rte
=========================
The no-hold keyword has been added to tb.rte, it complements the "hold"
keyword. Mail for a node will be put on hold if
1. this node matches "hold" and
2. doesn't match "no-hold"
It allows one to simplify one's config.
For example:
Instead of writing
if normal
hold 1:1/1 2:2/2 2:3/3
if boss1
poll 1:1/1
hold 2:2/2 3:3/3
if boss2
poll 2:2/2
hold 1:1/1 3:3/3
id boss3
poll 3:3/3
hold 1:1/1 2:2/2
You can just just write
hold 1:1/1 2:2/2 3:3/3
if boss1
poll 1:1/1
no-hold 1:1/1
if boss2
poll 2:2/2
no-hold 2:2/2
if boss3
poll 3:3/3
no-hold 3:3/3
Forwarded mail is deleted
=========================
If your system receives netmail from other nodes, and if it is routed to
somewhere else (if you are a hub for example, or messages from/to
your points), Imports marks the messages as Kill/Sent so that Pack
can delete them with the Killed flag once they have been sent. This
option may be disabled with the keyword "nokillrouted" in tb.cfg.
Adding all your akas in seen-by lines
=====================================
An undocumented feature is now usable :-). If you insert -d in the
Import or Scan command line, the the seen-by will include all your
addresses, while the addresses in other zones are automatically stripped,
so this results in all your akas in the zone of the echo (defined as
you know by the first node in areas.bbs) present in the seen-by.
New display of imported messages
================================
Import now displays the number of messages that have been echoed in
each area, this allows you to see if routing works well, and to
detect problems more easily.
Support of incoming 4D packets
==============================
Import now recognises the extended Type 2 Packet headers, as defined
in fsc-0039, fsc-0045 (type 2.2), fsc-0048 (type 2+). Bermuda still
produces FSC-0001 packets, which works quite well anyway :-).
Redirection of Netmail according to the key # statement
=======================================================
If you have a key # statement in your tb.cfg, for example:
key #100:242/1 100:all
and if you write a netmail to 100:345/25, the netmail will be sent as
coming from 100:242/1 regardless of the originating node number written
in the header by the message editor. This is very useful with LED for
example. This applies only to messages entered locally.
Direct flag for netmails
========================
Direct mail allows you to send a netmail directly to the node without
routing, but in a normal mail packet rather than in a crashmail packet.
You can send semi-urgent mail directly to the node during low phone cost
periods, by setting the Direct flag of a message. (Note that these messages
are affected by an eventual HOLD statement in TB.RTE)
Direct flag is bit 10 of the message flags. Since most messages editors
(namely Led) don't allow to change it, setting both Crash and Hold
flags is equivalent to setting the Direct flag.
Never mix rerouting and password statements in key lines
========================================================
A common error is to mix rerouting statements (key #) and passwords (key !)
for example a point, which also have a fidonet primary address, may think
this is right:
key #100:234/567.8 !password 100:234/567
This is not correct! This means that you are behaving as 100:234/567.8 with
your Boss only, but not if you write netmails to other nodes in the zone 100,
you will be using your primary (fidonet) address.
The correct setup is:
key #100:234/567.8 100:all
key !password 100:234/567
Application Bermuda
===================
Configuration lines specific to Bermuda may start by 'application
bermuda' in tb.cfg. This may be used for key statement that apply
only to Bermuda and not to The-Box or other programs using TB.CFG.
It is especially useful with EMSI versions of The-Box. If you want EMSI
to work as expected in The-Box you must write key # statements behind
application:
application bermuda key #90:4/5 90:all
A second required thing to make The-Box EMSI works is to write all akas
of one boss node behind one password line, because The-Box uses this
information to know to which akas it must send mail. Unlike other mailers,
it does not try to send mail to all akas of the other side, hence making
sessions shorters with people having many akas.
; sends mail in the same emsi session to both logical boss nodes
key !mypass 2:345/678 90:100/110
Messages To Sysop
=================
Messages to 'sysop' in echomail areas are not counted as "sysop messages"
in the report. Usually echomail messages to "sysop" are written by buggy
software or people on other nodes.
Scanned messages are 'Sent'
===========================
Scan sets the Sent flag in processed echomail messages. It allows you to
see if a message has already been scannned by looking at the flags in
your message editor. Besides it is more compatible with Scanners not using
the mailer[7] field as usual. Scan still upgrades the mailer[7] field.
Crunch utility
==============
This is the new fourth face of the Bermuda triangle :-) the program is
used to delete old messages, so it "crunches" your message base and prevent
it from becoming very huge. There are several ways to choose how many and
which messages will be deleted per area. You may indicate the default one
in the command line of crunch.
For each area, you specify the way to delete messages by putting an
option line before the area line in areas.bbs.
** -days nnn [min mmm] [max ppp]
(with the equivalent form in the command line : crunch -dnnn [-mmmm] [-xppp])
This will keep only the last nnn days of messages.
If the min field is present, the number of messages will never go under
mmm, even if the kept messages are very old.
If the max field is present, the number of messages will never go over
ppp, even if some of the deleted messages were receiving during the
last nnn days.
** -msgs nnn
This will keep the last nnn messages.
(nnn, mmm and ppp are numbers with any number of digits.)
Ex:
-days 2
e:\msgs\0055 TALK
-msgs 300
e:\msgs\0056 THINK
-days 30 min 5 max 200
e:\msgs\0057 SLEEP
If you call crunch without setting the default in the command line, the
default will be keep 30 days.
If a message has the NOKILL flag set (this is new and is the bit 11 of
the message flags), that message won't be deleted because of its age.
Crunch updates the reply links and the files LED.NEW and LASTREAD.BBS
if found.
Pack and INTL lines
===================
Pack will always add INTL lines in netmails if you add the -i switch
on its command line. Otherwise it will only add it for inter-zone
netmails. This should help some importers to find the zone number.
Binkley compatible outbound
===========================
Pack will handle a Binkley 3.0 outbound if you specify 'binkley' in
the configuration file. Now it doesn't renames the file, all is done
internally. However, you should have outbound.zone directory created
for all your possible zone. If Pack wants to create a packet for zone
8 and outbound.008 doesn't exist, it will crash. Note that this problem
doesn't exist when you're using The-Box !
Various little bug fixes
========================
Don't forget there is a bad messages area to put bad messages instead
of putting them in the Netmail area. Just add a BADMSGS area in your
areas.bbs file.
In Scan, if you have various key # statements and you send an echo to
several nodes for whom your address is not the same as the one of the key
#, the packets were not correctly addressed. This has been corrected.
An area like MAILBOX.GER is no longer recognised as the mail area in Scan.
In Pack, the "via" line now displays 19 Jan 92 instead of 01/19, as
it is done by most programs.
For point systems, the netmails are imported with the 4D address
written in the message header, which looks nicer.
In scan, an extra line is added before the tearline at the end of the
message, so that the message looks nicer :-).
Small bug fixes now allow sophisticated key # configurations to work
correctly with Scan and Import (e.g. if you have a different aka for two
nodes who receive the same echo area).
Changing the origin of a netmail according to the key statement,
renaming bad arcmail bundles, importing echomail in a point from a
TosScan boss works all correctly now.
When a packet with zone 0 arrives, it is considered as comming from
your main zone (the one in the first address statement in tb.cfg),
rather than from the zone of the last packet processed.
The strange routing bug is fixed (if a netmail is to be routed to
2:320/7 it was sometimes routed to 2:320/7x, x behing a number changing
from time to time).
Maximum number of areas in areas.bbs is now 500, and the programs tells
when overflow.
Added a -n switch to suppress generating INTL lines in inter-zone
echomail messages. Also note that the switch to add kludges in SEEN-BY
and AREA lines is -k.
Added a -i switch to always add INTL lines in netmail messages, even
if there're not interzone (used by some old technology tossers).
The problem with Pack not handling xxxmail (arcmail, lzhmail...) as
expected when used with wildcards in TB.RTE is suppressed.
Fixed some problems with zone numbers in SEEN-BY/PATH lines.
Will Bermuda produce Type 2+ packets in the future?
===================================================
"No way." - Jac Kersing
Bermuda doesn't produce anything else than FTS-0001 release 15 type
two packets. This is a feature. There are at least three proposals of
"enhancements" to type 2 packets, none of them is really satisfactory,
and many implementations don't even follow the proposals. The situation
is so messy and the "enhancement" so ridiculous, that we'll stick to
standard packets that works pretty well, anyway.