Category : BBS Programs+Doors
Archive   : FIDOGATE.ZIP
Filename : OPUSGATE.DOC

 
Output of file : OPUSGATE.DOC contained in archive : FIDOGATE.ZIP


GTPOWER <==> FIDONET GATEWAY

ALPHA TEST VERSION



1. SO WHAT IS THIS GATEWAY THING ANYWAY?

The Gateway is a method of interfacing net and echomail between two
incompatible electronic mail systems. It is presently implemented for use
between systems running GT Power and Systems running OPUS. It allows the
following:

1. Exchange of NETMAIL between the two networks, with the present
restriction that mail going into Fidonet can only be sent to nodes
within the local Zone. Direct point addressing is also not implemented
at this stage.

Further, file attach and file request are also not implemented (with
the exception being that a Fidonet node can file attach to (only) the
host GT board (that is, to the board running the gate itself).

These restrictions should be gradually removed as the gateway software
is developed.

2. Exchange of ECHOMAIL between the two networks. There are virtually no
restrictions here. However, you should be VERY careful in how it is
done. It is easy enough to create a circular network topology within
one mail system alone, when interfacing two of them the problems are
much worse. In the development net (GT net 36, we have a standing rule,
at least at the moment, that only one gate can operate within the local
net. Coupled with the convention that all conferences coming through
the gate from Fidonet are assigned LOCAL Gt conference numbers, means
that no Fidonet conferences can escape out onto the Gt network and
inadvertently find their way back through another gate into Fidonet.

You are free to work out your own rules for how to do it in you own net
of course. That is just what we do here. Perhaps we are too cautious,
but I for one, don't want the Fidonet community to have any reason to
feel a lack of confidence in either the Gt network or the gate!


2. WHAT DO I NEED TO SET UP A GATE

1. You need a local friendly OPUS Sysop, who is prepared to co-operate.
From his point of view it is all very easy. He makes you a point on his
board, and scans out to you whatever conferences you wish to take. The
only difference for him is that he needs to run an extra remapper
program to send Gt mail to the gate. It is called "GATEMAP" and is part
of this package. It is the only program which needs to be run on the
OPUS system, all the rest run on the GT system. Gatemap should run
whenever the normal OPUS remapper runs, either immediately before or
after it.

2. You need to collect a number of OPUS style programs in order to set up
an OPUS point on your system. Required are:

BinkleyTerm
Confmail
OMMM
A fossil program (I use Opus!com v5.20).

3. You need to have the Gateway programs themselves, (this package):

Premail the GT to Fidonet mail processor
| Inmap Maps in the FROM: field in inbound msgs
Postmail the Fidonet to GT mail processor
Rebagger for sending netmail on through the GT net
wallop for cleaning out Binkley's mail directories
wait to be sure the system does not run too fast
stamp if you want to datestamp log files

4. You need to assign the gate to a GT Net/Node number. For instance, here
we have called the gate 36/9. That is not a "real" system, but an
address which I accept here at 36/1 and which my routing.bbs marks as
an inbound node. It is therefore never called. Mail arrives for it, and
is picked up by the gate next time it runs. You do not need the CRC for
it -- just be sure that you use a fresh number!


5. Set up Binkley/Confmail. The docs for those programs are reasonably
clear. An example of what is set up here is shown below.

I have a directory C:\BINKLEY where the OPUS style programs live. From
that hang the rest of the normal Binkley dirs:

OUTBOUND where the oubound (to Fidonet) mail bags go,
BFILES where the inbound (from Fidonet) mailbags and
attached files are put,
BMAIL where Opus style netmail messages are processed,
CONTROL where gate control files (and some log files) are
placed.

I have a directory C:\CONFMAIL which contains all the directories where
Fidonet echomail messages are processed. There must be one directory
per echo conference. These are generally empty, but are used in
processing, and are required by Confmail. There should also be two
extra directories (apart from those for any conferences going through
the gate) called GENERAL and PRIVATE. The confmail docs say that it is
prudent to have them, even though in general they will NEVER be used.

6. Set up one or two other directories related to the GT side of the gate.
You will need a MAILHOLD directory, which is used for catching inbound
netmail before it is unbagged and rebagged to its proper destination
nodes.

PLEASE NOTE THAT AT THIS STAGE ALL OF THESE DIRECTORIES NEED TO BE ON
THE SAME DRIVE AS YOUR MAILIN AND MAILOUT DIRECTORIES. This restriction
should be lifted in a later release, but we have to live with it at the
moment. The programs also require the GTPATH environment variable to be
set.

7. Place the programs into a place where they can be found (in the path
would be a good choice -- but I have them all in the BINKLEY directory,
to which I change when I run the gate.)

8. Set up batch files to run and go to it!

I run with three scheduled events: 02:45 for a gatemail preparation
event. It is not strictly necessary to do this as a separate thing, but
it does mean that when gatemail starts you can be directly into calling
the Opus system, and not spending the first 10 minutes doing
preparatory housekeeping.

In this event I do the following:

cd \binkley
mbagger /d99 ; to prepare GT style bags for processing
premail 36/9 premail.log
confmail export areas.bbs -o c:\binkley\outbound\ -a
ommm -z -sa -ic:\binkley\binkley.prm -mc:\binkley\bmail
-hc:\binkley\outbound -cc:\binkley\ommm.ctl
; long lines wrap here -- one line really
wallop c:\binkley ; NEVER allow this to run on any "REAL" Opus
; system -- it will systematically wipe out
; every message in every area! That's exactly
; what it needs to do here, of course.
wait 2 ; waits 2 minutes so that GT can never restart
; too fast, and go out to prepmail again on
; the same schedule time

The second event (at 03:15 here) is the Binkley mail run to the co-
operating Opus board. After that run is completed some postprocessing
of inbound bags is necessary. Below are extracts from the batch file:

opuscom1 ; start fossil

:start
BT unattended ; start up Binkley itself
if errorlevel 40 goto nomail ; when nothing has come through the gate
if errorlevel 30 goto postarc ; when arcmail has been received
; (actually, all mail is arcmail)
if errorlevel 20 goto postrec ; when non arcmail has been received
; (actually, never)
if errorlevel 10 goto end ; user interrupt
goto start

:nomail
ocom_cfg r ; nothing to process, remove the fossil
goto rungt ; restart the GT board

:postarc
:postrec
ocom_cfg r ; remove the fossil
confmail import areas.bbs -a ; unpack the Opus mail into its areas
| inmap 3:414/404 c:\binkley\bmail
; put in the FROM field while messages
; are still in OPUS form
postmail 36/9 postmail.log ; translate the mail to GT bags
rebagger 36/1 rebagger.log ; notice the node number!
; rebagger looks for inbound mail to me
; and sees if any of it needs to go
; on to other net/nodes.
cd \mailin ; probably unnecessary
mdist ; process the new mailbags

:rungt
cd \binkley
wallop c:\binkley ; clear out the binkley areas
cd \
host ; restart the GT host mode

:end
ocom_cfg r ; remove fossil -- user cancellation of
; binkley

The third event (04:00 -- 05:00 here) is my normal netmail hour for net
36.

My batch files are actually quite a bit more compley, basically because
I make backup copies of inbound and outbound mailbags and keep stamping
logfiles with dates and times. This is basically to see what has
happened overnight while the thing is in test. Probably not a bad move.


3. OTHER REQUIRED FILES

The gate programs (premail, postmail, and rebagger) all require the presence
of at least two control files -- FROMOPUS.BBS and OPxxxyyy.BBS. They must
both be in the GTPATH directory. The xxx and yyy are the GT net/node numbers
of the gate you are using. For example, here the gate is known as 36/9 so
the filename is OP036009.BBS.

Examples are shown below:

FROMOPUS.BBS
===========================================================================
Gateway to Power: From FIDONET via the GT-Kangaroo Gate!
C:\BINKLEY\CONTROL
C:\BINKLEY\BMAIL 036/001 C:\MAILHOLD
C:\CONFMAIL\PERSPECT E00/002 C:\MAILOUT
C:\CONFMAIL\BTOPICS E10/006 C:\MAILOUT
C:\CONFMAIL\STELLAR E10/101 C:\MAILOUT
C:\CONFMAIL\GATERS E36/000 C:\MAILIN
C:\CONFMAIL\GOSPEL E36/001 C:\MAILIN
C:\CONFMAIL\Z3TECH E36/002 C:\MAILIN
C:\CONFMAIL\GTSYSOPS E36/003 C:\MAILOUT
C:\CONFMAIL\CECHO E36/004 C:\MAILIN
C:\CONFMAIL\LTUAE E36/005 C:\MAILIN
===========================================================================

Now: here there are two special lines (in order) after which follow any
number of lines, one for each mail area/conference

Line 1 contains the origin line to be tagged onto mail coming IN to GT
through the gate.

Line 2 contains the name of the directory where the gate control and log
files are to be placed.

Thereafter: the fields for each line are as follows:

(a) the directory where Binkley will get/place the Opus format mail
(b) the GT net/node (for netmail -- 1 only please) or conference
number which is related to that mail area. There should be a one
to one correspondence between Binkley areas and GT names. That
means that all netmail must go to one address -- which is why
rebagger is used after the mail is imported to distribute it
properly.
(c) The directory where postmail will place the GT style bags it has
made up. For Fidonet conferences which you are hosting (from the
GT point of view) that will always be \mailin. For conferences
which someone else is hosting (whether they are Fidonet or GT net
conferences) that will always be \mailout. For example, E36/003 is
our local net 36 Sysops conference, which is also taken by the co-
operating Opus node. It is hosted by 36/0 -- so bags are placed in
\mailout for transmission to the hub. For netmail, the directory
MUST be \mailhold. Here it will be kept for reprocessing by
rebagger.

NOTE THAT DIRECTORY NAMES MUST NOT CONTAIN A TRAILING BACKSLASH.


OP036009.BBS
===========================================================================
Gateway to Power: From GTNET via the GT-Kangaroo Gate! (3:711/404.3)
1209/3
C:\BINKLEY\CONTROL
711/404
036/009 0 C:\BINKLEY\BMAIL
E00/002 460 C:\CONFMAIL\PERSPECT
E10/006 460 C:\CONFMAIL\BTOPICS
E10/101 466 C:\CONFMAIL\STELLAR
E36/000 445 C:\CONFMAIL\GATERS
E36/001 470 C:\CONFMAIL\GOSPEL
E36/002 470 C:\CONFMAIL\Z3TECH
E36/003 469 C:\CONFMAIL\GTSYSOPS
E36/004 469 C:\CONFMAIL\CECHO
E36/005 470 C:\CONFMAIL\LTUAE
===========================================================================
In this file there are four special lines:

Line 1: The origin line to be tacked on to mail going to Opus through the
gate.

Line 2: The point address of your gate as seen by Opus. Used to tell Opus
the source of outbound mail -- at least until it gets to your
local Opus board where it gets remapped!

Line 3: The same as the FROMOPUS line 2, the directory where control and
log files go.

Line 4: The Opus Net/Node address of your co-operating Opus board. Used
for default addressing of mail which arrives at the gate with no
Fidonet address.

Thereafter follow any number of lines which describe to premail what
conferences are being sent out through the gate.

Fields are as follows:

(a) The mailbag/conference numbers of what has to go out through this
particular gate. This is where the gate "pseudo" address (here
36/9 is used. Premail picks up bags for that one and sends them
out). The NETMAIL line must be the FIRST of these multiple lines.
(ie it must come immediately after the control lines above).

(b) The day number of the echomail bag last sent -- premail updates
this itself. Note that a day number is required even for the
netmail line -- it should be 0, and will never be changed by
premail).

(c) the directory where mail for translation should be put. Confmail
will look there for mail to be exported (so will OMMM).


That's all there is to it. The command lines of the programs are as follows:

Premail net/node [logfile]

where net/node is the GT address of the gate (36/9 here for instance), and
logfile is the optional name of a logfile. A log is ALWAYS written, and the
default name is "premail.log". It is placed in the control directory (in the
case of the example, C:\BINKLEY\CONTROL). It is always appended to.

Postmail net/node [logfile]

As for premail above, except that the default name for the log is
"postmail.log".

Rebagger net/node [logfile]

Not quite the same. The net/node is the address of the GT host system, in my
case, my normal GT-Kangaroo, 36/1. It is used to determine which inbound
mail bag to look for in \MAILHOLD. The default logfile name is
"rebagger.log".


If you wish to use stamp.exe, (to place datestamped comments into log files)
the format is like this:

Stamp A comment of many words for the file >>logfile

Trivial but useful


That should be enough to get you going:

I'll include all my batch and control files on the disk for you as more
complete samples of what I am doing with this. I trust you can get whatever
Opus files you need from 148/1. If you need any help please contact me. You
are the first Beta tester of this. (Really it is an ALPHA test for another
week or two until I get the extended zone addressing into the programs for
netmail to/from Fidonet).

Meanwhile, have fun with it -- in tests running daily now for over a month
it seems to perform as it should. We get the odd glitch but generally they
are not serious things, and are quickly and easily fixed.

Please remember that what you have is a very early copy. You are free to
share it with your friend, but remember my comments (paranioa??) about
circular topologies.

best wishes
Stephen



  3 Responses to “Category : BBS Programs+Doors
Archive   : FIDOGATE.ZIP
Filename : OPUSGATE.DOC

  1. Very nice! Thank you for this wonderful archive. I wonder why I found it only now. Long live the BBS file archives!

  2. This is so awesome! 😀 I’d be cool if you could download an entire archive of this at once, though.

  3. But one thing that puzzles me is the “mtswslnkmcjklsdlsbdmMICROSOFT” string. There is an article about it here. It is definitely worth a read: http://www.os2museum.com/wp/mtswslnk/