| Document: FSC-0078
| Version: 001
| Date: 11th April, 1993
|
| Clovis Lacerda, 4:808/2
Gateway between Fidonet compatible networks
Author: Clovis Lacerda, Brazil
Fido : 4:808/2
Email :
[email protected]
Date : March, 1993
Copyright 1993, Clovis Lacerda. All rights reserved. The right to
distribute for non-commercial use is granted to the Fidonet
Technical Standards Committee, provided that no fee is charged. This
may be posted on electronic BBSs which charge no fee for accessing
this document. Any and all other reproduction or excerpting requires
the explicit written consent of the author.
INTRODUCTION
Many networks, using the Fido technology, are being created
everywhere. It is now time to implement a means to provide gateway
capability between these networks. Some proposals were made, but, as
far as I know from reading most of the FSC standards, none of them
actually play with the basic standards of Fidonet, as established in
FSC-0001. It is time to think of other ways in which to improve Fido
technology based on what is universally available, rather than
relying on the infamous ^A kludges that many software packages out
there don't use, or worse, ignore systematically.
ABSTRACT
From now on, the word FakeNet will be used to refer to any
Fido-compatible network that is not in the Fidonet nodelist, thus
using node numbers not found in the 1-thr-6 Fidonet zones.
A Fakenet uses its own nodelist. There is a large number of Fakenets
all over, one not knowing the existence of the other, some using the
same node numbers in their own nodelists. We shall try to put these
networks together, not by forcing any of them into a single nodelist,
but by making one aware of the existence of the others, and providing
gateways in each of these networks so that mail can flow in both
directions.
IMPLEMENTATION
For a gateway to be implemented, extra information must be provided
in the netmail. Normally, two user names, From: and To: define the
sender and the addressee. The node numbers go "inside" the netmail
and have their existences checked in the nodelist of the network in
question by the local running software.
Since we now have 2 networks, the extra information must be the
remote node in the destination network, which obviously cannot be
found in the local nodelist, and the local node that must reach the
remote addressee, otherwise a reply cannot be made.
Suppose, for example, that there are 2 Fakenets, one based in zone 10
(network 1), the other one in zone 11 (network 2), and that user John
Green in node 10:100/1 wants to send a netmail to Paul Brown in
11:200/1.
In both networks, a gateway node (common to both nodelists) must be
provided. Let's say that node 10:10/1 is the gateway in network 1,
named "Gateway system A" and node 11:11/1, named "Gateway system B"
is the gateway in network 2.
What John, from network 1, will have to do is:
Send a netmail to his local gateway node, which is 10:10/1.
In the To: field, he will put, besides the name of the addressee,
Paul Brown, PAUL'S NODE NUMBER, 11:200/1, inside (). This is the
extra information needed for the gateway to work. What will happen
is:
This netmail, in the domain of network 1, will travel the route and
reach the gateway, 10:10/1. This gateway system must do the
following:
Change the domain of the netmail from network 1 to network 2. This
means that any reference to node numbers in the netmail header must
be updated.
Thus, the netmail will now have the node 11:11/1 as the originating
node, and 11:200/1 as the destination node, "hardcoded" in its
header. But we can see that John's node number must be provided,
otherwise Paul will not be capable of replying. This is done by the
gateway software that includes John's node number in his From: name
field, inside (). When Paul receives John's netmail, he will reply,
and the From: field will automatically become the new To: field, and
will contain John's name and node number. The netmail will reach back
11:11/1 and the process will be exactly the same, finally reaching
John.
In resume, this is the odyssey of John's netmail to Paul:
1 - John enters his message to Paul. Since Paul is not in John's
network, John will have to use the gateway.
He sends a netmail to his local gateway system, 10:10/1 which
looks like this:
From: John Green, John's BBS (10:100/1)
To : Paul Brown (11:200/1), Gateway System A (10:10/1)
Re : Hello
------
body of message ......
Note that John had to MANUALLY enter Paul's node number and put it in
the To: field, together with Paul's name. This netmail is addressed
to Gateway System A, node 10:10/1.
2 - After arriving in 10:10/1, the gateway software will create a new
netmail that looks like this:
From: John Green (10:100/1), Gateway System B (11:11/1)
To : Paul Brown, Paul's BBS (11:200/1)
Re : Hello
----
body of message....
Note that John's node number was inserted in the From: field, which
is the information needed for the bidirectional gateway to work.
3 - This netmail is now in the domain of network 2. It will travel
the normal route and reach Paul. When he replies, the local message
editor will make the From: field become the To: field. The
netmail-reply will look like this:
From: Paul Brown, Paul's system (11:200/1)
To : John Green (10:100/1), Gateway System B (11:11/1)
Re : Hello
----
body of new message.....
This netmail will travel the route and reach 11:11/1. The process now
is exactly the one used to gate the original netmail from network 1
to 2. The gateway software will create a new netmail that looks like
this:
From: Paul Brown (11:200/1), Gateway System A (10:10/1)
To : John Green, John's system (10:100/1)
Re : Hello
----
body of new message....
Note that Paul's node number was inserted in the From: field,
finishing the gateway process.
The only trade-off in the current proposal is obvious. The limited
length of the name fields, which, according to FSC-0001, is 36
characters long, and that may not allow the inclusion of the person's
node number in it.
For example, if John's full name were John Green Richardson Smith
Jr., he would have sent his netmail to Paul, but the gateway system
would fail when attempting to include his node, 10:100/1 together
with his name. In this case, the netmail is bounced back with a
warning message, and it will be John's responsibility to change his
name to a shorter one or use an alias. It seems that more and more
people are being practical and using only 2-word names, so this is a
problem that can be easily worked out by the local BBS operator.
Lastly, ^aINTL kludges must be issued in all netmails gated between
the 2 networks.
This proposal follows FSC-0034 and FSC-0001. It also allows immediate
aplication, since it relies on what is Fidonet in essence, FSC-0001.
A gateway package was implemented for this purpose. MailGate (c),
besides gating netmail and echomail between 2 or more Fakenets, also
provides transparent gateway between a Fakenet and Internet,
integrating lists and news with echomail and also providing a BBS
with the feature of creating its own lists, that can flow as
echomail through a Fido-compatible network, through the gateway
between 2 fakenets, and also through Internet, as a mailing list.
CONCLUSION
Enhancing technology and creating new oportunities, necessary
ingredients to allow systems and sysops to play their freedom of
choice, are the best keys to improve Fidonet technology and make it
really become the de facto standard, no matter which new network is
created every day.
I don't know how suitable this proposal is in regard to the incoming
problem Fidonet is facing, or will have to face, when all the
nodelist zones split apart, since the size of the nodelist is growing
alarmingly.
This document is not perfect and may contains wrong conclusions.
Should you have suggestions and constructive criticisms, please
contact the author.
My thanks to those who were prompt in helping me through the
technical aspects of Fidonet and in the last days routed my emails
when trying to reach FTSC, (it finally reached the right place,
Australia) especially Tom Jennings, Randy Bush and David Nugent.
Thanks to Mitch Davis for helping me with some technical details.
By no means am I saying that they support or have even read this
document, it's only a thank you note.
Fidonet is a trademark of Tom Jennings and Fido software, to whom we
all owe many thanks for the origin and spirit of Fidonet.
MailGate is a trademark of Clovis Lacerda
