home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Crawly Crypt Collection 1
/
crawlyvol1.bin
/
bbs
/
acs_deng
/
acs_eng3.doc
< prev
next >
Wrap
Text File
|
1989-04-07
|
42KB
|
1,003 lines
P A R T 3
(Appendix with Detail Information)
You'll find, in this part, specific information within the individual
appendixes about the ACS Package.
- Appendix 1: ACS.CFG and Binkley.RTE Files documentation (R.Bohn)
- Appendix 2: Graphical overview (M.Dominick)
- Appendix 3: When do the different Packers work (M.Dominick)
- Appendix 4: File Request from other Nodes (E.Jeckl)
- Appendix 5: Crashmails (E.Jeckl)
- Appendix 6: Domains (R.Bohn)
Translator: Frank Bell
A P P E N D I X 1:
ACS.CFG and Binkley.RTE Files documentation (by Roland Bohn):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
--- ACS.CFG ---
An Example of the Area-Cleaner-Software Configuration File.
===========================================================
General Parameters:
^^^^^^^^^^^^^^^^^^^
So that Come_In and Go_Out know what Packer program to use and what
parameters to pass to these Packers the following keywords are needed.
The *Imp paths are for - who would have thought of that - Come_In and
the *Exp paths influence Go_Out accordingly.
The '+' just after the keyword means that the parameter used on the
file to be unpacked is separate from the Path, just like its done
with LHarc version 1.13.
Format: ArcImp[+] <File path of the Arcer> [Packer Parameters]
ArcExp <File path of the Arcer> [Packer Parameters]
ArcImp \NODE\PACKER\ARC_602.TTP x
ArjImp \NODE\PACKER\UNARJ.TTP -x
LzhImp+ \NODE\PACKER\LHARC.TTP x
ZipImp \NODE\PACKER\UNZIP.TTP
ZooImp+ \NODE\PACKER\ZOO.TTP xO (Oh, not zero!)
ArcExp \NODE\PACKER\ARC_602.TTP a
ArjExp \NODE\PACKER\ARJ.TTP -a (Note that there isn't any ARJ yet)
LzhExp \NODE\PACKER\LHARC.TTP a
ZipExp \NODE\PACKER\ZIP.TTP a
ZooExp \NODE\PACKER\ZOO.TTP aP:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Normally Tidy_Up works in all Areas that are listed in AREAS.BBS. But
most of the time not all Areas have been changed so there is no reason
for these Areas to be processed. LED and Come_in can create a file
where only those Areas which have changes are listed. Tidy_Up can read
this and then process only the Areas included in the file (except of
course for the Netmail and two other 'help' Areas). The file is deleted
as soon as Tidy_Up has done its job and recreated by LED and/or Come_In
when they're loaded the next time.
Format: EchoList <File Path>
Example: EchoList \NODE\NEWECHOS.LST
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
When Tidy_Up scan Areas it has to make copy all Echomails which are to
be exported so that Go_Out can process them. Normally the Netmail
Area is used for this propose. But because Netmail is also used for
private messages its very inconvenient to search for these mails which
may lay between the temporary Echomail copies.
So its possible to tell Tidy_Up and Go_Out to use an extra Area for
their Echomail processing.
Format: ExtraExpArea <File Path without Extension>
Example: ExtraExpArea \NODE\MSGS\EXPAREA
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Its sometimes possible that Points (or even their Boss) create messages
in Areas which don't even exist or which haven't been requested.
Simply said: when Come_In has to process an Area in which it hasn't
the slightest idea of what's going on, its shove the incoming messages
into the Bad_Msgs Area (if it exist) or into Netmail (if it doesn't).
The Bad_Msgs Area is a Help Area used to keep such messages out of the
Netmail. Further processing of these messages has to be done by hand.
Format: Bad_Msgs <File Path without Extension>
Example: Bad_Msgs \NODE\MSGS\BADMSGS
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Special Flags for Come_In:
^^^^^^^^^^^^^^^^^^^^^^^^^^
Note: - All flags are activated with '+' and deactivated with a '-'.
- Not all Commandline-Flags are also saved in the ACS.CFG.
ACS.CFG Command Line Description
-----------------------------------------------------------------------
LogInfo -l An extract of the screen messages is written
to the Log File which is defined in BINKLEY.CFG.
Verbose -v Comprehensive information concerning Packet
File is written to the screen and the Logfile.
Keep_ArcImport -k The packed Packets (*.mo0, *.tu0, etc.) are not
deleted after they have been Imported.
Just in case an error occurs during mail importing
(because of ARC, LHarc or TOS error (disk full))
the mail packet won't be deleted. This gives one
the possibility to unpack the files again after
correcting the problem.
AreaFix The integrated AreaFix is activated. (for Nodes)
FileFix The integrated FileFix is activated.
PrintMyMail All incoming own Netmails will be printed out, if
the printer is online.
Diskfree -f Before an Area is processed, the partition is
checked for enough room. If room is not
available, the process is cancelled.
Wait -w Come_In waits for a 'key press' when finished.
Quiet -q No messages will be displayed on the screen.
Example:
Come_In:
+LogInfo
+Verbose
-Keep_ArcImport
-Diskfree
-Wait
-Quiet
-AreaFix
-FileFix
-PrintMyMail
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Special Flags for Tidy_Up:
^^^^^^^^^^^^^^^^^^^^^^^^^^
ACS.CFG Command Line Description
-----------------------------------------------------------------------
Days xx -dxx The number of days after which messages are
automatically deleted.
HeaderLevel xx -hxx The minimum number of messages which should be
left in an Area. If the number of messages
in an Area is less than this number then the
Area is skipped over.
LogInfo -l Refer to Come_In.
Verbose -v Refer to Come_In.
KillDupes -k Duplicate Messages are delete.
UseExtraExpArea -e Refer to ExtraExpArea - This parameter says
everything anyway doesn't it?
LastCall -c Just in case an eccentric clock shows the
wrong date (2049 for example) Tidy_Up would
is sure to remove all messages because it
would interpret them as being too old. If
this flag is turned on, then Tidy_Up checks to
see if it has been called within the last 10
days. If not, then a messages is displayed and
Tidy_Up waits for an answer.
Keep_OldMsgs -o A copy of Netmail is made before Tidy_Up starts
processing.
Diskfree -f Refer to Come_In.
Wait -w Refer to Come_In.
Quiet -q Refer to Come_In.
Example:
Tidy_Up:
+Days 4
+HeaderLevel 20
+Loginfo
-Verbose
+KillDupes
+UseextraExpArea
-Keep_OldMsgs
+LastCall
-Diskfree
-Wait
-Quiet
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Special Flags for Go_Out:
^^^^^^^^^^^^^^^^^^^^^^^^^
ACS.CFG Command Line Description
-----------------------------------------------------------------------
Deletemode #|^ -d#|^ Refer to the "BinkleyTerm User's Guide". The
characters '#' or '^' are written to the
corresponding Binkley-Outbound-Flow-File to
tell BinkleyTerm what to do with the files
after exporting them.
Using a '^' the files will be deleted.
Using a '#' the files will reduced to a length
of zero. Because the file name remains on
disk, when using the second method, the
so-called FlowFile-Counter is activated. The File
then exist with the ending *.MO0. After the
next Poll, then *.MO1, *.MO2, etc.
LogInfo -l Refer to Come_In.
Verbose -v Refer to Come_In.
Crashmail -c When a Netmail is flagged 'Crash', its not
routed like a normal Netmail, its packed for
direct transmission to the addressee. If this Flag
is turned off the Crash Flag will be ignored.
UseExtraExpArea -e Refer to Come_In.
Keep_NetHdr -o A NETMAIL.HDR is first renamed to to
NETMAIL.OLD. Just in case something happens
the old Netmail structure can be easily
recreated.
Unarced_Netmail -u Netmails won't be packed and are sent out as
*.PKT files.
SaveWorkList -s Go_Out creates a small Worklist in memory from
NODELIST.DAT, this means Go_Out has process
a little longer. When this flag is turned on,
the Worklist is saved to disk. The next time
Go_Out is called it just has to load the
Worklist.
Wait -w Refer to Come_In.
Quiet -q Refer to Come_In.
Example:
Go_Out:
-Deletemode
+Loginfo
+Verbose
+Crashmail
+UseExtraExpArea
-Keep_NetHdr
-Unarced_Netmail
+SaveWorklist
-Wait
-Quiet
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Parameters for Come_In's integrated AreaFix and FileFix:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AreaFix:
^^^^^^^^
With the help of AreaFix connected Nodes and Points have the possibility
to independently connect or disconnect their Areas. That happens via
Netmail, addressed on AreaFix, in which line for line the Areas are
listed which are to be connected or disconnected (this is described
further in the documentation to BTS). As not everybody is allowed to
order or remove all Areas, passwords have to be used. The password, as
an authorization, is written in the subject line of the AreaFix Netmail,
parameters can follow.
A password, for AreaFix, must be given to every Node/Point who wants to
receive Areas from the system and who want to do their own management.
Format: AreaFixPwd <4D-Address> <Password>
Example: AreaFixPwd 2:241/5811.1 TEST
AreaFixPwd 2:310/12.0 HELLO
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
With AreaFix, an overview of Areas can be requested, then one receives
a complete list of existing Areanames. But if one doesn't know anything
about some Areas, then its impossible to know if those Areas are
interesting or not. A text file with Area descriptions would be very
helpful in this case. Using the parameter -l, after AreaFix in the
Netmail subject line, such a text file can be requested. With
AreaFixAvail a file path is defined which points to this file.
Format: AreaFixAvail <File Path>
Example: AreaFixAvail \NODE\FILES\AREALIST.LZH
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
FileFix:
^^^^^^^^
In Fidonet messages are constantly passed back and forth and it works
pretty good too, but files are a different matter, its not so easy.
There is a way, actually many methods have been thought out for file
routing and TICK is, for example, a very well known routing program on
PC compatibles.
Come_In's integrated FileFix is a simple File Router (TICK compatible to
a certain extent) which controls the routing of files.
Just like AreaFix the connected Nodes/Points have the possibility to
connect or disconnect FileEchos independently. A password is also
needed for FileFix, refer to AreaFix.
Format: FileFixPwd <4D-Address> <Password>
Example: FileFixPwd 2:241/5811.1 NOTHING
FileFixPwd 2:310/12.0 SPECIAL
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
FileFix also has a text file with FileEchos descriptions. Using
FileFixAvail a file path is defined for this file which can also be
requested from connect Nodes/Points with the -l parameter.
Format: FileFixAvail <File Path>
Example: FileFixAvail \NODE\FILES\FILELIST.LZH
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
When one is connected to a FileEcho then one knows when a new file is
received. But an outsider doesn't get much out of it. FileFix has the
possibility to send notes that new files are available to a Message-
Area indicated below.
Format: FileFixReportArea <Areaname>
Example: FileFixReportArea NEWFILES
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Area-Gating with Come_In:
~~~~~~~~~~~~~~~~~~~~~~~~~
With the steady increase of the Online-Users during the last years there
were many new Networks born and all of them naturaly want to use own Areas.
But some of the Users maybe want to read some foreign Areas from the other
Networks without using also the foreign name.
A single Node must take the Messages of the foreign Area, copy them to
the own Area and distribute the Messages within this Areas through his
Network. This Node acts as an Area-Gate from his Network to the foreign one.
ACS can either copy or move the Messages received in the foreign Area to one
or more Areas (up to 4) of his Network.
If the Gate Node doesn't have to distribute the foreign Msgs further to
other Nodes in the foreign Network, so he doesn't need to save the incoming
Msgs in the foreign Area. In this case he should/can use the move Command.
Note: copy and move mean of course that the incoming Messages for the
foreign Area will be copied/moved to the own Areas.
If the incoming Messages for the own Areas should be copied back to
the foreign one, then it is required to install a copy or move
Command for each own Area backwards to the foreign one.
(This helps to make also a 'oneway' Gate possible.)
Format: Crosslinked_Areas: (as a Keyword in ACS.CFG)
copy <other_area> to <my_area>, ... (1 to 4 Areas allowed)
move <other_area> to <my_area>, ... (1 to 4 Areas allowed)
Example:
Crosslinked_Areas:
move SFFAN to N_SF
copy N_SF to SFFAN
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Readdressing with Come_In:
^^^^^^^^^^^^^^^^^^^^^^^^^^
It happens sometimes that the address of Nodes/Points change. Other
Fidonet users can't react to the changed address very fast especially as
they may not know about the changes. It makes sense that all Netmails
that were sent with the old address get rerouted to the new address.
Come_In, with Readdress, has the ability to readdress individual Points
or Nodes or even whole Nets. Here the '*' means that an element doesn't
have to be considered or it doesn't have to be changed.
Format: Readdress "Change Receiver's Name" <Old 4D-Receiver's Address>
"New Receiver's Name" <New 4D-Receiver's Address>
Example: Readdress "Roland Bohn" 2:241/5811.0 "Nobody Else" 2:241/5811.99
Readdress "Juergen Moellenhoff" 2:507/*.* "*" 2:241/5811.5
Readdress "*" 2:507/203.* "*" 2:241/5811.*
============================================================================
--- BINKLEY.RTE ---
An Example of Area-Cleaner-Software Routing File.
=================================================
The Routing File helps to control where messages are sent and the
packing method used. For example, Points, normally, only send their
messages to their Boss and he passes them on to other Nodes and so on,
till the Addressee is reached.
The following macro names are used in all Route Commands:
ALL Example: 2:241/ALL, 2:ALL, ALL
HOSTS Example: 2:HOSTS (Means: 2:241/0, 2:242/0, etc.)
OURNET (Means: all those in your own Net. I'm in Net 241.)
POINTS (Means: all my Points.)
Important: Go_Out analyses the Routing Commands in the order that they
appear. The last command encountered by the referenced Node
is always processed.
Example:
ROUTE-TO 241/5800 ALL ;everything to 241/5800
ROUTE-TO 310/12 310/ALL ;Net 310 to 310/12
A message to 310/3 is routed over 310/12.
But:
ROUTE-TO 310/12 310/ALL ;Net 310 to 310/12
ROUTE-TO 241/5800 ALL ;everything else to 241/5800
A message to 310/3 is routed over 241/5800. Because
the last command routes everything over 241/5800.
All Node entries in Binkley.RTE are maximum 3D (that is
2:241/5811). When Routing is performed on ones own Zone
the Zone entry isn't needed (241/5811).
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Packing Methods:
^^^^^^^^^^^^^^^^
ACS only knows five Packers: Arc, Arj, LHarc, Zip and Zoo (also see ACS.CFG)
Its possible to define that certain Nodes are to receive ARC files and,
other Nodes LZH files if they rather have them.
Format: ARCMAIL <node> <node> ...
ARJMAIL <node> <node> ...
LZHMAIL <node> <node> ...
ZIPMAIL <node> <node> ...
ZOOMAIL <node> <node> ...
Example: ARCMAIL ALL ;send ARCed Mail to everybody
LZHMAIL 241/5800 247/43 310/12 ;send LHarc Mail to these Nodes
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If ARCMAIL ALL is defined and a certain Node shouldn't be packed, then
the Pack flag has to be turned off.
Format: NOTPACKED <node> <node> ...
Example: NOTPACKED 252/25 241/5800 ;these Nodes receive unpacked Mail
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Packet-Types:
~~~~~~~~~~~~~
Every Message is packed in a Packet (special Fileformat) before sending
to the destination. This way the addressee of the Packet knows who the
originator of the Packet was and what is further to do with the Packet.
The format of the Packet-Header was developed some years ago and it is
no wonder that since then new Situations required to change this format.
But because one (still) cannot know that the destination Node can
handle with the new format, there have to be a way to declare which format
has to be sent.
Format: 4D-PACKETS <node1> <node2> ...
or
2D-PACKETS <node1> <node2> ...
Example: 4D-PACKETS 241/ALL ; send 4D Packets to all Nodes in Net 241
2D-PACKETS 241/5806 7902 ; but send only 2D Packets to 241/5806
; and 241/7902
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Forward:
^^^^^^^^
Some Nodes, possibly for security reasons, want to receive/send messages
only on certain Nodes via their own system. Normally this is not
necessary, but the number of Nodes can be reduced from which messages
will be accepted or sent on to.
A Netmail is then passed on when the Origin-Node's FORWARD-FOR flag
is set on and the Destination-Node's FORWARD-TO flag is set on.
(Normally, always on for everybody.)
Format: FORWARD-FOR <node> <node> ...
FORWARD-TO <node> <node> ...
Example: FORWARD-FOR ALL
FORWARD-TO ALL
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Routing:
^^^^^^^^
Routing is included because its impossible to call every addressee when
a message is to be sent. That means, that messages must be passed
through many Nodes before the recipient is finally reached. Every Sysop
controls which Node is to receive his Netmails via the Routing file.
Format: ROUTE-TO <route-node> <node> ...
Example: ROUTE-TO 241/5800 ALL ;all Nodes to 241/5800
ROUTE-TO 310/12 310/ALL 302/ALL ;Net 310 and Net 302 to 310/12
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
All Nodes are covered and provided for using ROUTE-TO. But what about
when one certain Node is to directly receive Mail? Then its possible to
write ROUTE-TO 247/43 247/43, but there is a more elegant way.
Format: NO-ROUTE <node>
Example: NO-ROUTE 247/43 252/25 ;Mail goes directly to 247/43 and 252/25
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Polling:
^^^^^^^^
The above Routing information isn't enough to distribute all Mail to
every Nodes/Point correctly. Things have to be set so that one knows
whether calls are made or that calls are only received. Normally one
expects to make calls himself, so things have to explicitly be set up
so that messages will be held for certain caller.
Format: HOLD <node> <node> ...
Example: HOLD POINTS 247/43 246/18 282/352 ;Messages for Points and
;the indicated Nodes are
;held on the system
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
When calls are originated the system has to know if the call is always
made or to be made only when Messages are present to be sent out.
POLL is used when a call is always originated and PICKUP when one waits
till Messages are waiting to be sent.
Format: POLL <node> <node> ...
PICKUP <node> <node> ... (or SEND-TO <node> <node> ...)
Example: POLL 241/5800 ;always call 241/5800, even if nothing
;is be to sent.
PICKUP 310/12 252/25 ;only if there is something to send.
SEND-TO 244/1 ;just like PICKUP.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
It sometimes happens that Netmails should be sent directly (not Routed)
to the whole Net (for whatever reason). Then, for example, SEND-TO
241/ALL should be written to the Routefile. In case NetMails for some
Nodes (example 241/5800) shouldn't be SEND-TOed because they are planed
for later export (in another Event) then NO-SEND has to be used to switch
off the above SEND-TO for the intended Nodes (241/4300) NO-SEND can also
be used for POLL, HOLD and PICKUP.
Format: NO-SEND <node1> <node2> ...
Example: NO-SEND 252/25 ; don't export mail for this node.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Flowchange:
^^^^^^^^^^^
Generally the most favorable calling time is selected when someone wants
to Poll another Node. Schedules (Events) are used so that the least
expensive Polling is used. It can happen that the Node in question calls
us from time to time so why not give him his mail while he is online.
That's why its necessary to process Mails for the Nodes as early as possible
and have them ready at all times.
As our computer should call only during the most convenient time then
Mails for the target Node must be made ready but on 'Hold'. When
the time comes (Schedule) that we should do the calling then the Mail
shouldn't remain packed on 'Hold'. The Mail has to be changed to 'Crash'
or 'Normal' so that Binkley knows to make the call. After the call
everything should be changed back to 'Hold'.
Format: CHANGE <from> <to> <node1> ...
where <from> and <to> equal HOLD, NORMAL and CRASH.
Example: CHANGE HOLD CRASH 247/43 246/18 ;Holdmail for these Nodes
;is changed to Crash
;(*.HLO -> *.CLO)
CHANGE NORMAL HOLD 252/25 ;Normalmail for these Nodes
;is changed to Hold
;(*.FLO -> *.HLO)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Naturally there's a way to turn everything off in case a general
conversion is made and only a few Nodes are to remain uneffected.
Format: NO-CHANGE <node1> ...
Example: NO-CHANGE 241/5800 ;no changes are made to this node.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Schedules:
^^^^^^^^^^
During normal operations a Box with fixed Routing isn't the most perfect
system. A BBS system has many different tasks to perform and request
to make during a day. Netmails have to be sent to certain Nodes at
certain times while other Nodes/Points doesn't have to be taken into
consideration at all, and more.
When using Binkley as a Mailer there is the Binkley.EVT file where all
Events for a day are processed. Events in Go_Out are numbered exactly
like Binkley and are selected for SCHEDULES.
Event 4 using Binkley also means SCHEDULE 4 when Routing.
Format: SCHEDULE <number> (or maybe a String used with -r)
Example: SCHEDULE 2
SEND-TO 252/25
POLL 310/12
SCHEDULE 4
SEND-TO 1:102/346
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Domains in the Routefile:
~~~~~~~~~~~~~~~~~~~~~~~~~
All Statements and Parameters in the Routefile mentioned above are reffering
naturally to only one Nodelist.
But if you are active in different Networks which are requiring the use of
multiple Nodelists then you have to tell the Software the names of the used
Lists and how the routing for the different Lists should be done. Since each
List is individual there has to be also an individual routing method for
each List.
Which Lists are used by the System is defined in Binkley.CFG with the
Statement "Domain <designator> <abbreviation> <nodelist>". To define the
routing for each of these Statements (and therefore for each Nodelist), the
Routefile will be splitted in small Blocks. Each of these Blocks starts with
a Keyword (defined by the <abbreviation> plus a colon).
That means that you have to write the Networkname followed by a colon in a
line at the start of the Block of Statements which is reffering to the
same Network.
Format: Abbreviation:
Example: Fidonet:
ARCMAIL 241/5800
FORWARD-FOR ALL
FORWARD-TO ALL
ROUTE-TO 241/5800 ALL
POLL 241/5800
NeST:
ARCMAIL 90:6000/0 (Important: All Zones other than the
FORWARD-FOR ALL own (from the 1. Address)
FORWARD-TO ALL must be written down in the
ROUTE-TO 90:6000/0 ALL Routfile.)
SEND-TO 90:6000/0
============================================================================
A P P E N D I X 2:
Graphical Representation of a Poll Session (by Matthias Dominick):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+------------------------------------------------------------------+
| Fido Mailnode (Boss), who holds your Packets |
+------------------------------------------------------------------+
| / \
| |
+---------------+ +---------------+
| Mail for You | | Mail for Boss |
| packed | | packed |
+---------------+ +---------------+
| |
\ / |
+------------------------------------------------------------------+
| Fido Mailer (for example: BinkleyTerm 2.4) |
+------------------------------------------------------------------+
| / \
| |
+---------------+ +-----------+ +---------------+
| Importer |-->| Packer |<--| Exporter |
| Come_In |<--| i.e. ARC |-->| Go_Out |
+---------------+ +-----------+ +---------------+
| |
| +----------->+
| | | MsgBase-Scan is
| +---------------+ | optional and only
| | MsgBase-Scan | | necessary, when
| | i.e. Tidy_Up | | your a Node or use
| +---------------+ | another MsgEditor
| | | and not LED.
| +------------+
| |
+-------+------+----------------+ |
| | | |
\ / \ / \ / |
+---------+ +---------+ +---------+ |
| Area 1 | | Area 2 | ... | Area n | |
+---------+ +---------+ +---------+ |
/ \ / \ / \ |
| | | |
+--------------+----------------+---------->+
| | |
\ / \ / \ /
+------------------------------------------------------------------+
| Message Editor (for example: LED) |
+------------------------------------------------------------------+
A P P E N D I X 3
How do the different Packers work (by Matthias Dominick):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+-------------------+-------------------------+-------------------------+
| | relative Path | absolute Path |
| | Imp+ Imp Exp | Imp+ Imp Exp |
+-------------------+-------------------------+-------------------------+
| LHArc 0.60 (Webb) | Yes Yes Yes | Yes Yes Yes |
| UnLzh 1.72 (PRG) | No No --- | Yes 1) Yes --- |
| LHArc 1.13 (Yoshi)| No No Yes 2)| Yes No Yes 2)|
| LHArc 1.13 (009As)| No No Yes 2)| Yes No Yes 2)|
| FastLzh5 | No No No 3)| Yes No No 3)|
+-------------------+-------------------------+-------------------------+
1) UnLzh has to be appropriately configured:
Create Folder: No
1x manually uncrunch from Inbound Folder to Inbound Folder
These paths have to saved in all cases, otherwise the packets will be
save just about any place.
2) To turn off the Prompt or the the incorrect File Extension pass the
'-m' Parameter.
3) Only the *.FLO File is created; the actual Archive is not created!
To sum it up: When the received Packet isn't too big then the universal
unpacker, LHArc, should be used. If the Inbound Mail Packet is greater
then 100kb then a special configuration of Unlzh for Importing should be
used; for Exporting the normal LHArc should be used.
A P P E N D I X 4
File Requests from other Nodes ((Nodelist necessary) by Erich Jeckl):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Here we differentiate in
- Requests in your own Zone
- Requests in other Zones
FILE REQUEST IN YOUR OWN ZONE
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The Binkley Philosophy says, that a Point Polls his Boss exclusively and
nobody else. And this was the case for a long time, but with the
increasing size of the Net and the huge existing base of Files makes it
just about impossible for a Boss to meet his Points wishes.
The ACS Packet gives the user the possibility, with Binkley, to make File
Request from other Nodes.
It works like this:
Click on BTS - "Extras" --> "Make Requests".
A Dialog box is displayed, in which the Point's Boss' NodeNumber
is already shown. With "ESC" you can delete the field contents
and enter the NodeNumber of the target Node. Then the individual
files can be entered (and if necessary the Password in the next
field) or when a Filelist of the target Node exist, the Filelist
can be displayed and the wish for files can be marked for
Requesting (the marked files are shown in inverse).
After the last file is selected, click on the "Save" button. In
the next Dialog box click on either "NORMAL" or "CRASH". Normal
or Crash are to be differentiated because a corresponding dummy
file has to be written into the Outbound Folder (some Nodes
demand it) with either the .FLO file extension or, for Crash,
with the extension .CLO.
When this is finished, start the Binkley Terminal program via BTS,
press ALT + M keys. You then have the possibility to enter either
the Sysop's name or his NodeNumber. If you enter a NodeNumber a
FIDOUSER.LST isn't necessary, but you need a compiled Nodelist
(and a FIDOUSER.LST if you want to use the name of the Sysop).
Binkley switches to Mailer Mode, searches out of the Nodelist the
correct telephone number of the target Node and Polls it. The
target Node also knows in Mail-Only operation that a FidoNode or
Point wants to log-on and if the Node allows Request nothing
stands in your way.
I'm not going to go into the many possibilities of BinkleyTerm
here, you can read all about it in the BinkleyTerm manuals.
FILE REQUEST IN OTHER ZONES
^^^^^^^^^^^^^^^^^^^^^^^^^^^
There's a couple of preparations to make first, then things function just
like in your own Zone.
What "preparations"? Now, BinkleyTerm needs for every Zone its own
Outbound Folder, that means, that you have to create for every Zone you
want to request into its own OUTBOUND.xxx folder. (The Zone number 'xxx'
has to be given in hexadecimal Notation).
That is -
Requesting in Zone 1 = OUTBOUND.001
Requesting in Zone 3 = OUTBOUND.003
Requesting in Zone 27 = OUTBOUND.01b and so on.
In BTS, from "Make Request" change the preset NodeNumber to the target
Node's Zone, enter the files to be requested, click on "SAVE", and then
"CRASH". BTS then writes the Request file into the correct folder.
Selection of the target Nodes functions just like a Request in your own
Zone:
- BinkleyTerm (in single call mode)
- Press ALT + M
- Enter NodeNumber (completely, with Zone)
- BT searches the correct telephone number out of the Nodelist
- After a Connect, your Request file is sent to the target Node.
Most Nodes use the so-called Magic Word "FILES"; you can, when you use
this Magic Word in your first Request file, the target Node will send a
Filelist which you can use just like the one from your Boss.
A P P E N D I X 5
C R A S H M A I L S (by Erich Jeckl):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Here too we want to differentiate between Crashes in your own Zone or in
other Zones.
CRASHMAIL TO YOUR ZONE:
=======================
First some important points:
- Crashmails are always NetMails (Matrix) and never EchoMails
- Crashmails without a Nodelist are impossible!!
- Crashmails must be allowed by the target Node! Some Nodes refuse
unlisted Nodes or Points from logging on (not password protected) with
the idea that a virus could be uploaded into his system.
To generate CrashMails do the following:
- Set 'on' the ACS Flag "CrashMail" (if you don't have it already)
- Write with LED a Header for the Netmail (Node Number!)
- And then click on "Private Local", above right in LED (or ALT+V)
- A Dialog box is displayed
- Click on "Crash"
- Then write your message
- Then "Save" (you can also use CTRL + S)
- Then leave LED (use CTRL + Q)
As mentioned before, Crashmail cannot be sent without Nodelist. That means
you will have to use a compiled Nodelist and therefore use Go_Out without
the Parameter -m in the Commandline. This installation differs from the one
described in Part 1 of the ACS Documents. You will need a Routefile.
- Start Go_Out and you will see that your Netmail is sent with the
Crash-Flag on.
- Call BinkleyTerm in single call mode
- Press the ALT + M keys
- Enter target NodeNumber, press RETURN
- And thats it.
Now nothing stand in the way of sending CrashMails.
CRASHMAIL TO OTHER ZONES:
=========================
Crashing into other Zone works exactly the same as in your own Zone, with
the exception the every Zone must have its own OUTBOUND folder (also see
File Request in other Zones).
for Zone 1 = OUTBOUND.001
for Zone 3 = OUTBOUND.003
for Zone 27 = OUTBOUND.016 and so on.
Go_Out then writes into the corresponding OUTBOUND.xxx folder, just like
Crashmails in your own Zone, the necessary files.
A P P E N D I X 6
Domains in Fidonet (by Roland Bohn):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Domain Addressing is relatively new concept in Fidonet. It puts in
another and more complicated form of Addressing. With the addition of
another field in the Address its possible to clearly address other
networks (Fidonet, Signet, Eggnet, etc.), without addressing conflicts
between networks with identical Zones or Net Numbers.
To support Domains its necessary to have the different Nodelist (NODELIST,
SIGLIST, etc.) which the other Net needs. Also the Address Statements
must have the correct Domain Addressing.
Therefore a universal indication or Complement has to be connected to
the Address Statements of the corresponding Network. The Complement of a
Network has to have a certain ending. Our, primary, Network has to have
the ending ".org". All of the alternate Network indications have to have
".ftn" as an ending. That means that the alternate Networks work using
the Fido Standard.
Address 2:241/5800@fidonet.org
Address 7:520/1015@alternet.ftn
The Domain Statement need many entries so that it functions correctly.
Format: Domain <Complement> ShortForm> <Nodelist>
Example: Domain fidonet.org fidonet nodelist
Domain alternet.ftn alternet anetlist
IMPORTANT: For every Domain Complement, of an Address Statement, the
corresponding Domain Statement must exist.
<Complement> is the actual Domain Name along with the corresponding
ending, see above.
<ShortForm> can have a maximum of 8 characters. Mailers exchanged
it with each other during a connect. Its almost always
a universally know name of the target Network. As in
the above example the ShortForm is "fidonet" and
"alternet".
<Nodelist> points to the name of the Nodelist of the appropriate
Network. In the above example "nodelist" is for
Fidonet and "anetlist" is for Alternet.
With the entry of the Domain Statements were not finished with the Domain
installation. Just like with different Zones which have different
Outbound paths, Domains have to have their own paths too.
The path are differentiated only by the name of the last folder of the
path of the primary Outbound Folder (indicated by the 'Hold' statement).
For the alternate Network, the last folder name of the 'Hold' statement is
replaced by the ShortForm of the Domain Statement.
When you yourself are in Fidonet and the Hold statement points, for
example, to:
C:\NODE\OUT\OUTBOUND\
then for Alternet the path
C:\NODE\OUT\ALTERNET.xxx\
is used.
Note: The path for other Domains, not your own, must always include the
Zone-Number.
Example:
Hold c:\node\out\outbound\
Address 2:241/4306@fidonet.org
Address 7:520/1015@alternet.ftn
Domain fidonet.org fidonet nodelist
Domain alternet.ftn alternet anetlist
The Outbound Paths look like the following:
c:\node\out\outbound\ ;Default Outbound
c:\node\out\outbound.001\ ;Fidonet Zone 1
c:\node\out\outbound.003\ ;Fidonet Zone 3
c:\node\out\alternet.007\ ;Alternet Zone 7
c:\node\out\alternet.059\ ;Alternet Zone 89