FidoNews is published weekly by the International FidoNet
Association as its official newsletter. You are encouraged to
submit articles for publication in FidoNews. Article submission
standards are contained in the file ARTSPEC.DOC, available from
node 1:1/1. 1:1/1 is a Continuous Mail system, available for
network mail 24 hours a day.
Copyright 1989 by the International FidoNet Association. All
rights reserved. Duplication and/or distribution permitted for
noncommercial purposes only. For use in other circumstances,
please contact IFNA at (314) 576-4067. IFNA may also be contacted
at PO Box 41143, St. Louis, MO 63141.
Fido and FidoNet are registered trademarks of Tom Jennings of
Fido Software, 164 Shipley Avenue, San Francisco, CA 94107 and
are used with permission.
We don't necessarily agree with the contents of every article
published here. Most of these materials are unsolicited. No
article submitted by a FidoNet SysOp will be rejected if it is
properly attributed and legally acceptable. We will publish
every responsible submission received.
Table of Contents
1. ARTICLES ................................................. 1
A Christmas Poem ......................................... 1
Anudder Christmas Poem ................................... 3
D'Bridge 1.30 Single-line / Press release ................ 4
Internetwork Gateway Policy .............................. 6
TosScan, The Ultimate FrontDoor Echomail Processor ....... 23
Algorithm, The Personal Programming Newsletter ........... 27
2. COLUMNS .................................................. 28
From The Node At The End Of The Universe ................. 28
3. LATEST VERSIONS .......................................... 31
Latest Software Versions ................................. 31
And more!
FidoNews 6-51 Page 1 18 Dec 1989
Twas the night before Christmas, and all through the shop,
The computers were whirring; they never do stop.
The power was on and the temperature right,
In hopes that the input would feed back that night.
The system was ready, the program was coded,
And memory drums had been carefully loaded;
While adding a Christmasy glow to the scene,
The lights on the console flashed red, white, and green.
When out in the hall there arose such a clatter,
The programmer ran out to see what was the matter.
Away to the hallway he flew like a flash,
Forgetting his key in his curious dash.
He stood in the hallway and looked all about,
When the door slammed behind him,and he was locked out.
Then, in the computer room, what should appear,
But a miniature sleigh and eight tiny reindeer;
And a little old man, who with scarcely a pause, Chuckled:
"My name is Santa... the last name is Claus."
The computer was startled, confused by the name,
Then it buzzed as it heard the old fellow exclaim:
"This is Dasher and Dancer and Prancer and Vixen,
And Comet and Cupid and Donner and Blitzen."
With all these odd names, it was puzzled anew;
It hummed and it clanked, and a main ciruit blew.
It searched in its memory core, trying to "think";
Then the multi-line printer went out on the blink.
Unable to do its electronic job,
It said in a voice that was almost a sob:
"Your eyes--how they twinkle--your dimples so merry,
Your cheeks so like roses, your nose like a cherry,
Your smile--all these things, I've been programmed to know,
And at data-recall, I am more than so-so;
But your name and your address (computers can't lie),
Are things that I just cannot identify.
You've a jolly old face and a little round belly,
That shakes when you laugh like a bowlful of jelly;
My scanners can see you, but still I insist,
Since you're not in my program, you cannot exist!'
FidoNews 6-51 Page 2 18 Dec 1989
Old Santa just chuckled a merry "ho,ho,"
And sat down to type out a quick word or so.
The keyboard clack-clattered, its sound sharp and clean,
As Santa fed this "data" into the machine:
"Kids everywhere know me; I come every year;
The presents I bring add to everyone's cheer;
But you won't get a thing-- that's plain to see;
Too bad your programmers forgot about me."
Then he faced the machine and said with a shrug,
"Happy Christmas to all," as he pulled out its plug.
Submitted by Phil Buonomo 1:107/583@FidoNet, 520/583@AlterNet
-----------------------------------------------------------------
FidoNews 6-51 Page 3 18 Dec 1989
THE NIGHT BEFORE BETA TEST
'Twas the night before beta test, and all through the house,
not a program was working not even a browse.
The programmers hung by their tubes in despair,
with hopes that a miracle soon would be there.
The users were nestled all snug in their beds,
while visions of inquiries danced in their heads.
When out in the machine room there arose such a clatter,
I sprang from my desk to see what was the matter.
And, what to my wondering eyes should appear,
but a super-programmer (with a six-pack of beer.)
His resume glowed with experience so rare,
he turned out great code with a bit-pusher flair.
More rapid than eagles, his programs they came,
and he cursed and muttered and called them by name:
On update On add On inquiry On delete
On batch jobs On closing On functions complete.
His eyes were glazed over, fingers nimble and lean,
from weekends and nights in front of a screen.
A wink of his eye, and a twitch of his head,
soon gave me to know I had nothing to dread.
He spoke not a word, but went straight to his work,
turning specs into code, and then turned with a jerk.
And laying his finger upon the "ENTER" key,
he brought it all up and it worked perfectly.
The updates updated; the deletes, they deleted;
the inquiries inquired; and the closings completed.
He tested each whistle, he tested each bell,
with nary an a bug, all had gone well.
The system was finished, the tests were concluded,
the users' last changes were even included.
Yet the users exclaimed with a snarl and a taunt,
"It's just what we asked for but NOT what we want."
-- arthur bozlee
Submitted by Phil Buonomo 1:107/583@FidoNet, 520/583@AlterNet
-----------------------------------------------------------------
FidoNews 6-51 Page 4 18 Dec 1989
D'Bridge Software, 1:18/68
15 December 1989
Fidonet EMAIL users:
This is just a note to let you know that the 1.30 Single-line
version of D'Bridge has been released. It may be obtained via
many distribution sources and is available for download or
WaZOO-style file-request from 1:18/68, 1:105/3 and 1:273/905.
There's no sense in wasting Fidonews space with technical
details. Just try it; you'll like it. It's unlike any mailer
you've seen before... PLEASE KEEP IN MIND THAT D'BRIDGE IS
A COMMERICIAL PRODUCT.
Request: DBRIDGE or DB130*.* for the full distribution package.
These files total 778,678 bytes and take about 13-14
minutes with an HST. (You've been warned!)
DB130A.ZIP DBRIDGE0.130 D'Bridge installation control file
DBRIDGE1.130 D'Bridge (1 of 7)
ORDER-DB.TXT D'Bridge Order form
USA-EAST.COS Example cost file
MODEMS.SEL Modem default file
READ.ME This document
DB130B.ZIP DBRIDGE2.130 D'Bridge (2 of 7)
DBRIDGE3.130 D'Bridge (3 of 7)
DBRIDGE4.130 D'Bridge (4 of 7)
DBRIDGE5.130 D'Bridge (5 of 7)
DBRIDGE6.130 D'Bridge (6 of 7)
DBRIDGE7.130 D'Bridge (7 of 7)
X00.SYS FOSSIL driver courtesy of Ray Gwinn
X00.DOC Documentation for X00.SYS
DB130INS.ZIP INSTALL.EXE D'Bridge installation program
INSTALL.DOC Simple instructions INSTALL.EXE
Chris Irwin, 305-232-5245 Technical support
D'Bridge Software 800-762-4197 Credit card orders
Suite 208 305-255-6460 FAX
15321 South Dixie Highway 305-232-9365 EMAIL, 1:18/68
Miami, FL 33176
FidoNews 6-51 Page 5 18 Dec 1989
-----------------------------------------------------------------
FidoNews 6-51 Page 6 18 Dec 1989
Tim Pearson - 1:286/703
-----------------------
Introduction
============
I expect that many in FidoNet will view the draft of the
Internetwork Gateway Policy document published in this issue with
some puzzlement. Some will not have more than a cursory
awareness that Other Networks even exist. Others will,
initially, not understand why the current tendency of most other
FidoNet Technology Networks (FTNs) to "grab a zone and go" is
causing technical and administrative difficulties within FidoNet.
Many may be under the quite mistaken impression that FidoNet
somehow sanctions or assigns zone numbers to other FTN networks.
Very few will be aware that FidoNet currently exchanges net and
echomail traffic with networks whose technology and addressing
scheme is not that of FidoNet. Most folks, quite rightly,
believe in the old maxim: "If it ain't broke, don't fix it." In
this article, I will try to explain why most current internetwork
communication methods are broken and why we feel that this
document will at least lay the groundwork for correcting the
problems that currently exist.
Why Zones Don't Work
--------------------
Those who designed the addressing scheme used within FidoNet
intended that zones be used to denote large geographic areas of
the world. The zonegate concept was developed to facilitate
economical and flexible interzone communication.
Zonegates provide economy by concentrating interzone
messages at the zonegate; allowing many messages to be combined
and compressed before they make the expensive "jump" to the other
zone.
Zonegates provide addressing flexibility by allowing net and
node numbers to be duplicated across zones. For example, all
FidoNet zones may contain a net 123 or a node 123/456. This
allows each zone coordinator a substantial amount of freedom in
how they set up the zone's addressing scheme.
Zonegate technology specifically does not, however, provide
the functionality necessary to run a proper network to network
gateway. The inherent design assumes too much. It assumes that
the zonegate's FidoNet address will be something that it will not
be in the case of a network gateway. It assumes that there is
only one "zone" for any given zone number. It assumes that the
"from" Zone:Net/Node of the message need not be modified. None
of these things may be properly assumed in the network gateway
scenario. The result of attempts to make zonegate technology
serve in a network gateway role is that both FidoNet and the
other network are plagued with invalid, unknown addresses. The
problem is compounded when more than one other network attempts
to use the same illicit zone number. Private netmail replies to
FidoNews 6-51 Page 7 18 Dec 1989
echomail messages (one of the basic tenets of FidoNet) become
impossible.
The problem is further aggravated when users on a network to
which FidoNet is properly gated (UUCP / Internet for example)
attempt to reply to a message containing one of these illicit
zone numbers. The message arrives at the FidoNet / Internet
gate. Automatic forwarding from that point becomes impossible
since the "to" address is not a valid FidoNet address. Usually,
the FidoNet gateway sysop has no idea where to manually forward
the message.
What Will Work
--------------
The solution to this growing problem is to require that
messages, while in FidoNet, contain only valid FidoNet addresses.
Period. A proper gateway will make all messages emanating from
it into FidoNet appear technically as if they originated from the
gate's FidoNet address just as if a user on that FidoNet system
had entered the message. If an "other network" address is to
appear in the message, it must appear elsewhere (in a location
not relied upon by FidoNet mailer software for routing, duplicate
checking, etc.), such as in the message body. With that
accomplished, the technical problems disappear with the sole
exception being the education of the users in both networks as to
how and where to place the other network's address before sending
the message to the gate. Several techniques have been
considered.
The imposition of a standard method is beyond the scope of
this group's mandate. That will be left to the FTSC, and the
software developers. It is our sincere hope that a standard
method will be put forth in the near future. Otherwise, users
will have to remember multiple methods of gateway addressing
depending upon which network the message is ultimately destined
for.
Administrative Objectives
-------------------------
Another problem with the "grab a zone and go" method of
internetwork connectivity arises when the question of
accountability arises. Who is this other network whose
zone:net/node addresses are now appearing in FidoNet echoes? Who
does FidoNet contact in the event that technical or policy
related problems occur? Who does an echo moderator contact to
resolve a problem with an unruly user in the other net? Who does
a FidoNet coordinator contact in the event that a policy
complaint is filed upon a user or sysop in the other net? In
most cases for most networks the current answer to the above
questions is "I don't know."
FidoNews 6-51 Page 8 18 Dec 1989
We submit that this is no way to run a railroad. It is this
series of problems that the "Administrative Agreement and
Registration" portion of the Gateway document was developed to
address. Some person in the other net needs to come forward and
say "Me. I'm the guy (or gal). Here's my address and voice /
data phone numbers. If you have problems with or questions about
this network or its gateways, FidoNet, call me. I'll take care
of it. By the way, here are the names and numbers of a few other
highly placed persons in this net. If you can't reach me, call
them. They will be able to assist you too." On its part, we
propose that FidoNet create the position of Internetwork
Coordinator to provide just that service to other nets that may
have problems with or questions of FidoNet.
The question of accountability can be simply and elegantly
addressed if we simply choose to view each "other network" as a
large "point" network under the control of the "responsible
party" named in the administrative agreement with the other
network. Just as the "bossnode" is responsible for the actions
of his "point" systems, the "responsible party" is responsible
for the actions of the sysops and users in the other network with
respect to FidoNet policy compliance.
In the event of a problem, FidoNet can work with the
"responsible party" or their authorized agent to resolve the
matter. If the matter cannot be resolved in any other fashion,
FidoNet reserves the right to simply cease gateway activities.
FidoNet makes no attempt to dictate what policy users in any
other network adopt or operate under. It simply requires that if
a message is to travel into FidoNet, it will be measured by the
same policy yardstick as any other FidoNet message or it will not
travel here at all.
Summary
-------
Your comments are invited. Many individuals have spent many
months in the development and refinement of the draft you see
here. In that situation, we may have taken for granted something
that the wording of the document really doesn't make clear. A
policy is nothing unless it can be clearly understood and
applied. If something seems unclear or ambiguous, please call it
to our attention. It is our intention to allow 30 days for the
receipt of input from the network at large. After that, the
final draft will be presented to the International Coordinator
for adoption. When that occurs, an article containing the final
text along with information on how to contact the Internetwork
Coordinator for an application will be published.
Members of the Gateway Policy Development Committee include:
Bill Bolton, Steve Bonine, Randy Bush, David Dodell, Rick Moore,
Tim Pearson, Vince Perriello, Tim Pozar, and Matt Whelan.
Netmailed comments to any of the above individuals will be shared
with the entire group at your request.
FidoNews 6-51 Page 9 18 Dec 1989
The Draft Internetwork Gateway Policy document follows:
This document sets forth the administrative policy
requirements for interconnection between the FidoNet amateur
international electronic mail network and other electronic mail
networks.
As an amateur network, membership in FidoNet is open and
available to any individual or group capable of meeting the
technical challenge and willing to participate constructively
within the technical and administrative guidelines employed
within FidoNet. FidoNet desires to extend this idea, "The free
exchange of information," to include other electronic mail
networks. While connectivity with other networks can be
beneficial to all parties involved, it cannot be expected to
operate smoothly unless the parties involved understand and agree
to observe technical and administrative guidelines designed to
promote the orderly flow of traffic between networks and to
provide a mechanism for problem resolution should problems arise.
This document intends to address those points.
Section 2 - Definitions
=======================
"FidoNet"
---------
An amateur electronic mail wide area network consisting of
several thousand computer systems world wide. Most of these
systems operate electronic bulletin board (BBS) software giving
each system the capability to provide electronic mail services to
up to several hundred users. Detailed information on the
technical and organizational aspects of the FidoNet mail network
is beyond the scope of this document. Further information can be
obtained from various FidoNet publications including the FidoNet
official policy document.
FidoNews 6-51 Page 10 18 Dec 1989
"Other Network"
---------------
The term "Other Network" will be used in this document as a
shorthand term referring to any other electronic mail network,
whether inherently compatible with the technology employed within
FidoNet or not. This term will often be used to refer
specifically to the electronic mail network making application to
FidoNet for a "Gateway" (defined below).
"Gateway"
---------
A gateway is a system of computers equipped with the
hardware and software necessary to pass electronic mail messages
(possibly of various types, see below) between FidoNet and a
specific Other Network. A Gateway acts as a translator, allowing
messages entered on a system in the Other Network and addressed
to a destination within FidoNet to be translated into a form that
is technically acceptable to and compatible with FidoNet and vice
versa. All messages originated in the Other Network and
addressed to a destination within FidoNet are first routed to a
Gateway.
At a Gateway, the message is made technically acceptable to
and compatible with FidoNet and forwarded into FidoNet's wide
area network for delivery to its final destination. A message
originated within FidoNet and addressed to a destination within
the Other Network is handled in a similar manner.
"Netmail"
---------
The term Netmail, as used within FidoNet, refers to an
electronic mail message that is addressed to a specific physical
destination. Netmail messages can be addressed to a particular
individual at the destination site. Public messages can be read
by users other than the named addressee while private messages
cannot typically be read by any user other than the named
addressee and the system administrator/operator at the
destination site. Further information on Netmail is available in
other FidoNet technical and policy documents.
"Conference Mail"
-----------------
Echomail is the term used within FidoNet to refer to
electronic "Conference Mail" messages that, while possibly
containing the name of a particular individual in the "To:"
field, are copied and distributed to multiple (possibly several
hundred) destination systems. Some Other Networks refer to their
analogous capability under the terms "GroupMail" or "newsgroup".
Echomail messages are segregated into "Conferences" based upon
the topic being discussed. Echomail message content is usually
restricted to the topic(s) for which the particular conference
was created. Several hundred Echomail conferences exist within
FidoNet dedicated to topics ranging from technical discussions of
FidoNews 6-51 Page 11 18 Dec 1989
various computer systems and peripherals to philosophy and
religion. Further information on Echomail can be obtained by
consulting other FidoNet technical and policy documents.
"FidoNet Technology Network" (FTN)
----------------------------------
For the purposes of this document, a "FidoNet Technology
Network" (FTN) shall be defined as an Other Network whose message
format and transmission protocols strictly meet the technical
requirements set forth by the FidoNet Technical Standards
Committee (FTSC). FidoNet Technology Networks are inherently
technically compatible with FidoNet. Connectivity options are
available to FTN's that are not (for technical reasons) available
to non-FTN Other Networks.
Internetwork Coordinator (INC)
------------------------------
The Internetwork Coordinator is the individual within
FidoNet who has the responsibility for overseeing the granting,
installation, and maintenance of FidoNet to Other Network
Gateways. The INC shall be designated by and act as the agent of
the FidoNet International Coordinator.
Multi-Network (MultiNet)
------------------------
A "multinet" is a type of "super" network whose function is
to provide connectivity between many other networks and to allow
bidirectional communication between these networks.
Duplicate Message
-----------------
Because of the technology employed by some FidoNet
Conference Mail distribution systems, improper routing
information or topology can cause multiple copies of the same
message text to be delivered to FidoNet systems. A duplicate
message is defined as any message arriving at a FidoNet node
whose message body (the text entered by the human originator of
the message) is identical to the message body of a previously
received message. Messages manually forwarded to another
recipient are not considered duplicates for the purposes of this
document.
This section is intended to outline the administrative
framework under which Other Networks may connect to FidoNet.
FidoNet reserves the right to reject any Other Network Gateway
application for any reason.
FidoNews 6-51 Page 12 18 Dec 1989
3.1 - Other Network Connectivity to FidoNet Through "MultiNets"
---------------------------------------------------------------
FidoNet may elect to seek and obtain connectivity to various
multinet host facilities for the purposes of communicating with a
wide range of Other Networks. Any Other Network that desires to
communicate with FidoNet may elect to facilitate such
communication via the multinet. However, FidoNet reserves the
right to refuse to deliver incoming message traffic arriving via
such an arrangement based upon the guidelines set forth in this
document.
An Example:
FidoNet is now gated into Internet via UUCP. It has agreed
to the terms and conditions necessary for membership in and
connectivity to the Internet multi-network "umbrella". One
obvious method for achieving connectivity to FidoNet (and a whole
host of other wide area networks) is for the Other Network to
apply to Internet for a gateway. Under this scenario, the Other
Network is bound by the terms and conditions of Internet just as
FidoNet is. In this peer relationship, the terms and conditions
stated in this document are used by FidoNet to determine if Other
Network message traffic arriving at a FidoNet/Internet gateway
will be accepted into FidoNet.
3.2 - Connectivity Only Through Mutually Recognized Gateways
------------------------------------------------------------
While FidoNet has no desire to inhibit experimentation or
connectivity between consenting systems it must maintain the
technical and administrative integrity of its network.
Henceforth, FidoNet will not permit non-FidoNet addresses to
appear in any addressing or routing control fields (Some current
examples include: the "From" or "To" address fields, the "*
Origin" lines, the "seen-by" fields, and the "^APath" fields.) of
any netmail or echomail messages traveling on any portion of
FidoNet's wide area network. This restriction applies to all
present and future FidoNet nodes. FidoNet nodes who wish to
participate in Other Networks may do so but must insure that all
message traffic transmitted to other FidoNet systems contain only
valid FidoNet addresses in the addressing and routing control
fields. The FidoNet coordinators will enforce this requirement
and are authorized by the International Coordinator to take
whatever action may be necessary to prevent non-FidoNet addresses
from entering Fidonet, including without limitation, referring
the offending nodes to this document and to the InterNetwork
Coordinator for information on how to establish proper Gateways.
The sole exception to this requirement is set forth in the
following paragraph:
FidoNews 6-51 Page 13 18 Dec 1989
The exchange of message traffic, on an experimental or
private and closely controlled basis, between an Other Network
and a system or systems that happen to be members of FidoNet is
permitted and encouraged if such message traffic is confined to
the consenting FidoNet systems and is not allowed to travel on or
to any portion of FidoNet's wide area network that has not
previously consented to carry such traffic and if such
connectivity does not prohibit the FidoNet system(s) from
fulfilling the technical and policy requirements necessary for
membership in FidoNet. FidoNet requests that the INC be informed
of such arrangements so that any unintentional "leakage" of Other
Network message traffic into FidoNet's wide area network may be
rapidly isolated and corrected.
The exchange of message traffic between any Other Network
and FidoNet on any basis other than the one mentioned in the
paragraph above shall only be done through mutually recognized
and proper Gateways meeting the requirements set forth in this
document.
3.3 - Administrative Agreement and Registration
-----------------------------------------------
FidoNet requires that an Administrative agreement be
executed by and between the individual(s) responsible for the
administration of the Other Network and the FidoNet International
Coordinator, or the IC's authorized agent. This agreement should
outline, at a minimum, the following items:
1 - The name of the organization.
2 - The name, address, and voice telephone number
where the administrator of the Other Network may
be reached. (Administrative contact and responsi-
ble party).
3 - A brief description of the organization.
4 - The name, address and voice telephone number where
the individual(s) responsible for the operation of
the FidoNet/Other Network Gateway(s) may be
reached. (Technical Contact(s))
5 - A list of computer system(s) requesting Gateway
status containing the following information:
o The name of the gateway system as it will
appear in the FidoNet nodelist.
o The Locality, State / Province / Department /
etc., and Country where the Gateway is
FidoNews 6-51 Page 14 18 Dec 1989
physically located.
o The name of the system administrator for the
particular Gateway.
o The complete data telephone number for the
Gateway, including country code.
o The maximum baud rate supported by the Gate-
way and all modem standards supported.
o The hours during which the Gateway will
support FidoNet dial up mail sessions. (*SEE
NOTE BELOW*)
o The date the Gateway is expected to become
operational.
o The FidoNet compatible session protocol(s)
supported
o If the Gateway is now a member of FidoNet,
the zone, net, and node number of the FidoNet
system applying for Gateway status.
NOTE: For a system to be granted Gateway status, it
must at least be available for FidoNet dial
up mail sessions during the FidoNet dedicated
mail period for the geographic locality
concerned. FidoNet calls its mandatory
dedicated mail period the "Zone Mail Hour".
The time for "Zone Mail Hour" varies through-
out the world and can be found in Appendix A
of the current FidoNet Policy Document.
6. A clearly worded statement indicating that the
responsible party in the Other Network and Fido-
Net agree to the terms and conditions set forth in
the Administrative Agreement and those in this
document (included by reference as a part of the
agreement).
3.4 - Application of FidoNet Administrative Policy
--------------------------------------------------
For the purposes of applying FidoNet policy, FidoNet will
view the entire Other Network as a single FidoNet "node" under
the control of the individual named as the "Administrative
Contact / Responsible Party" (or an authorized agent thereof) in
the administrative agreement outlined in paragraph 3.3 above.
All other systems and their users will be viewed by FidoNet as
users on the "responsible party's" node for the purposes of
FidoNet official policy application.
FidoNews 6-51 Page 15 18 Dec 1989
FidoNet holds the operator of a FidoNet node responsible
(from an administrative policy standpoint) for the actions of
that node's users, subordinate "point" systems, and the "point"
system's users. FidoNet views single or multiple Other Network
Gateways as a single "boss" node under the control of the
"responsible party" and will apply FidoNet official policy
accordingly. FidoNet reserves the right to sever links to one or
more of the Other Network's Gateways as its final remedy for
violations of administrative policy. (see the paragraph titled
"Points" in the "Overview" section and the paragraph titled
"Responsible for All Traffic Entering FidoNet Via the Node" in
the "Sysop Procedures" section of FidoNet's official policy
document, for further information).
3.5 - Supported Message Types
-----------------------------
FidoNet will grant Gateway interconnection for the purposes
of exchanging messages of the type defined above as "Netmail" and
optionally for the purposes of exchanging messages of the type
defined above as "Echomail". FidoNet will not grant Gateway
interconnection for the purposes of exchanging "Echomail" only.
The ability to generate a private and personal "Netmail" reply to
an "Echomail" message is one of the basic facets of FidoNet and
cannot be compromised.
3.6 - Acceptance Criteria (All Other Networks)
----------------------------------------------
The granting of Other Network Gateways into FidoNet is not
automatic nor is it based solely on the Other Network's ability
to demonstrate technical compliance with the objectives set forth
in section 4 below. Some other criteria include:
o The Other Network should have an individual will-
ing and able to carry out the role of "Responsible
Party" as defined herein. The Other Network
"administration" should be willing to help in
assuring that technical, social, and administra-
tive policy standards are consistently met in all
message traffic emanating from the Gateway(s).
FidoNet pledges to do likewise.
o The Other Network must have demonstrable stabili-
ty. It should have been in operation as a free
standing network for a period of time sufficient
to prove its reliability. It should be able to
prove that it has the technical and administrative
expertise to maintain and regulate reliable Gate-
ways over an extended period of time.
FidoNews 6-51 Page 16 18 Dec 1989
3.7 - Other Criteria (FTN Other Networks)
-----------------------------------------
Software allowing nodes in FTN Other Networks to
simultaneously participate directly in FidoNet as valid FidoNet
nodes, isolating the Other Network's addresses from FidoNet
message traffic (i.e., using only valid FidoNet addresses in
FidoNet message traffic) presently exists. This "dual identity"
approach is the method FidoNet expects nodes in the FTN Other
Network will employ. Such an approach:
o Eliminates the need for any written agreement
between FidoNet and the FTN Other Network since
each Other Network node simply participates in
FidoNet, using only valid FidoNet addresses, in a
manner indistinguishable from a FidoNet node that
does not belong to any Other Network.
o Allows for FidoNet connectivity on a node by node
basis.
o Speeds mail transfer since message traffic can
enter FidoNet's wide area network at the point of
origin rather than having to first pass through a
Gateway.
o Eliminates the costly situation where an Other
Network node wanting to communicate with a FidoNet
node (or vice versa) in the same local calling
area must first route the message through a dis-
tant Gateway, incurring unnecessary expense to
himself, the Other Network and FidoNet.
o Gives each node contact with a nearby FidoNet
coordinator to provide FidoNet services more
effectively.
o Greatly reduces the effort involved to connect
into FidoNet. Each node simply sends a Netmail
message to the nearest FidoNet coordinator listing
the pertinent information for the system and
requesting that a FidoNet node number be granted.
o Eliminates any possible administrative policy
conflicts between the FTN Other Network and Fido-
Net. The node simply adheres to FidoNet policy in
FidoNet message traffic and to Other Network
policy in Other Network message traffic.
Given the above advantages, the FTN Other Network must
provide evidence of overriding technical or social
considerations, must show cause why these considerations justify
the establishment of a Gateway instead of merely allowing its
individual nodes to use the "dual identity" approach, and must
satisfy FidoNet that such an arrangement will be mutually
beneficial.
FidoNews 6-51 Page 17 18 Dec 1989
3.8 - Shared Echomail Conferences
---------------------------------
Echomail conferences shared between networks must be
registered with the appropriate FidoNet echomail coordinator. It
is the responsibility of the Other Network and its Echomail
source(s) within FidoNet to insure that proper topology is
observed between the FidoNet / Other Network Gateway(s) and that
duplicate echomail messages do not enter FidoNet. It cannot be
overemphasized that all message traffic emanating from a Gateway
must contain only valid FidoNet addresses in the message's
addressing and routing fields. Current examples include, without
limitation, the "from" and "to" addresses in the message header,
the *ORIGIN line address, the SEEN BY addresses and the ^APath
addresses.
3.9 - Network Integrity
-----------------------
In the event that FidoNet determines that significant harm
is being caused to the technical or social integrity of its
network, it may immediately sever links between the Other Network
Gateway(s) and FidoNet. FidoNet will make all reasonable
attempts to contact the "Responsible Party" as soon as possible
(before the severing of links if possible) to inform the Other
Network of the problem and to work toward its resolution.
At this time, FidoNet has not published a detailed technical
standard for Gateways. FidoNet reserves the right to develop,
implement, and require adherence to such a standard at a future
date. In the mean time, the following general guidelines are set
forth for Other Networks that desire to communicate with FidoNet.
4.1 - Technical Standards within FidoNet
----------------------------------------
The FidoNet Technical Standards Committee (FTSC) has
developed and published technical standards for message packets
and mailer-to-mailer protocols. The Gateway system(s) must be
able to assemble and transmit FidoNet standard message packets
using FidoNet standard session protocol. A gateway must also be
able to receive and disassemble FidoNet standard message packets
using FidoNet standard session protocol. Translation from the
Other Network's internal message format to FidoNet standard
packets and vice versa is the responsibility of the Gateway.
4.2 - Logical Other Network Address
-----------------------------------
FidoNews 6-51 Page 18 18 Dec 1989
Software at a Gateway shall modify each message entering
FidoNet (whether Netmail or Echomail) such that FidoNet software
will interpret the logical address of origin of the message as
the Gateway's FidoNet address.
4.3 - Physical Other Network Address
------------------------------------
Software at a Gateway shall embed the Other Network address
(physical point of origin), in human readable form, at a
predictable location in the message body immediately preceded by
a predictable identifier such that software designed to
facilitate the automatic inclusion of this information in FidoNet
replies to Other Network messages will be able to glean this
information from the other text in the body of the message
reliably. This requirement applies to Other Network messages
entering FidoNet, both Netmail and Echomail.
4.4 - FidoNet to Other Network Addressing (Netmail)
---------------------------------------------------
FidoNet users must be provided with a procedure for routing
what FidoNet defines as "Netmail" to Other Network users via a
Gateway. FidoNet users will be instructed to address netmail to
Other Network users to the FidoNet Zone:Net/Node address for an
Other Network Gateway.
The exact method by which these messages are forwarded to
their final destination within the Other Network is left to the
discretion of the Other Network. One obvious method is to have
the FidoNet user enter the "physical Other Network address" in
the proper location preceded by the proper identifier as outlined
in paragraph 4.4 above. FidoNet will help the Other Network in
educating FidoNet users on the proper form and location of the
additional address information necessary to route a FidoNet to
Other Network message to its final destination automatically via
a Gateway. FidoNet netmail arriving at a Gateway with improper
Other Network addressing information must either be corrected and
forwarded to the proper Other Network address or returned to the
FidoNet sender with text inserted notifying the sender that the
message was undeliverable.
4.5 - Echomail Standards
------------------------
Echomail entering FidoNet shall conform to FidoNet (FTSC)
standard format. FidoNet control, routing, and addressing
information in each message shall show that it originated from
the Gateway's FidoNet address. Internal Other Network routing
information (if any) attached to echomail messages must be
removed at the Gateway with the exception being the "Physical
Other Network Address" as defined in paragraph 4.3 above.
5.1 - Interpretation
--------------------
FidoNet retains the exclusive right to interpret the terms
and conditions stated herein based upon its representatives' best
understanding of those terms and conditions and upon its
knowledge of the original intent of the authors.
Draft Administrative Agreement
This agreement made this ________ day of _________,
__________ between "FidoNet" and
__________________________________________________, hereinafter
referred to as "Other Network", shall be mutually exclusive and
binding upon the parties herein until rescinded or revised by
agreements of the parties, as defined and stated herein.
Article 1.
----------
Other Network and FidoNet desire to exchange electronic mail
between their respective networks. The parties do therefore
mutually covenant and agree as follows:
Article 2.
----------
The parties hereto agree that the FidoNet document titled
"Internetwork Gateway Policy" shall be controlling and is
incorporated as if referenced and set out in full.
Paragraph 2.1 - Internetwork Gateway Policy
-------------------------------------------
Other Network and FidoNet agree to be bound by the terms and
conditions set forth in the FidoNet document titled "Internetwork
Gateway Policy" included by reference in Article 1 above.
Paragraph 2.2 - Gateway Certification
-------------------------------------
FidoNet and Other Network agree not to exchange or attempt
to exchange electronic mail via the proposed Gateway system(s)
other than on a limited and mutually agreed "test" basis until
both parties certify that the Gateway(s) are open for general
message traffic.
FidoNews 6-51 Page 20 18 Dec 1989
Paragraph 2.3 - Registration Information
----------------------------------------
Other Network agrees to provide FidoNet with complete and
accurate information as requested in Articles 3 and 4 below and
with any other information FidoNet may deem necessary as a prior
condition for the certification of any FidoNet/Other Network
gateways.
Article 3 - General Information.
--------------------------------
Is this system at present a FidoNet node? ___Yes ___No
If yes, Zone:_____ Net:______ Node:______
Article 5 - Termination
-----------------------
This agreement shall be terminated _______ days after the
giving of notice by either party at which point all Gateway
activities will cease.
Article 6 - Sole and Exclusive Agreement
----------------------------------------
This agreement is the sole and exclusive agreement between
the parties.
Article 7 - Remedies
--------------------
Both parties agree that their sole and exclusive remedy for
non compliance with the Internetwork Gateway Policy shall be to
terminate gateway activities.
For FidoNet:
By:___________________________________________
Title:___________________________________________
Date: ___________________
For Other Network:
By:___________________________________________
Title:___________________________________________
Date:____________________
-----------------------------------------------------------------
FidoNews 6-51 Page 23 18 Dec 1989
Mike Janke
1:135/4
TosScan - THE Echomail processor
Introduction:
-------------
The day many of you have been waiting for, and some thought would
never come, has finally arrived. Yes TosScan, the most awesome
echomail processor to ever hit the network, is finally available!
Let me just say that when one is coding such a full-featured pro-
gram, and when the integrity of billons of bytes of echomail is
at stake, it's best to make sure it is right rather than rush a
questionable version out the door.
As part of the beta test team, I can say that TosScan is rock
solid and ready to roll.
What it is
----------
Of course TosScan has all the usual features you'd expect of any
echomail toss/scan program, but there is much more!
o Full-screen, window-based setup/configuration program.
o Echo Area manager.
o Node manager.
o AreaMgr (similiar to AreaFix)
o Full point support.
o Full zone support.
o Message base utilities.
You'll never have to load your text editor to modify a areas file
or other control file every time a node or area is added to your
system. And, you won't have to keep that dog-eared copy of docs
nearby just to mutter... "Hmmmm, lets see, what was that command
line switch again?" as is often done with other processors.
Tsetup, the TosScan setup/configuration program, will make your
life much easier whether you are the last link or a major NEC.
All aspects of echomail areas/nodes and message base maintenance
are handled according to parameters defined in Tsetup.
I'd like to describe each individual feature, but to do so would
swell FidoNews to unmanageable proportions.
Flexibility is the keyword. ARCmail in all flavors, variable net
node number usage and ARCmail filenaming conventions just to name
a few. The list goes on and on, but as I said, there is just too
much for this article.
FidoNews 6-51 Page 24 18 Dec 1989
Reliability is one of TosScan's strong points. It can handle the
worst junk that programs such as Qecho can throw at it. TosScan
processes mangled packets and grunged archives with unbelievable
ease; I have yet to see it stumble over a single bundle.
I hear you saying "But is it fast?". Speed, of course, depends
on whether you have a screamer 386 or lowly 8088 with 80ms hard
drive. Here's an idea of what you can expect. Your times may be
slightly different.
System: 386/20, 2 MB RAM running in page interleave, DOS 4.01,
28ms hard drive.
Arcmail: 377 KB *.pkt. About 1/2 of the conferences run in
passthrough, averaging of 2.5 links per conference.
Time: 1 minute, 40 seconds.
System: 6MHZ AT/286 Clone, 1 x Miniscribe 6085 72 meg voice
coil 28 ms, DOS 4.01, 1 meg RAM drive, 1 meg cache.
Arcmail: 1,273,367 bytes (.PKT), 9 down-link systems.
Time: 26 minutes
External utilities
------------------
TosScan comes with two external utility programs to help maintain
your message base. Reply chain linking, killing old messages or
keeping an area within a certain number of messages, renumbering,
and for QuickBBS systems, the fastest pack and reindex you have
seen.
Availability
------------
By now I hope you're saying "Ok ok, enough! Where do I get it?".
TosScan, as you may or may not know, is a commercial product. It
will not be available for download or file request. It can only
be purchased from the author.
The current special price, valid for 30 days from initial release
is:
$20.00 - for users of the commercial version of FrontDoor.
$30.00 - for users of the noncommercial version of FrontDoor.
Add $6.00 shipping and handling for all orders within the United
States, $10.00 for overseas orders.
FidoNews 6-51 Page 25 18 Dec 1989
Send your orders to:
InterZone Software, Inc.
161 Madeira Avenue, Suite 57
Coral Gables FL 33134
Please specify whether you want the QuickBBS version or MSG
version. If you need the opposite version at a later date, you
may obtain it for a minimal fee.
In closing
----------
TosScan is THE ultimate echomail processor for FrontDoor systems
and I'm 100% sure you'll be glad you waited. It works quite well
and has been filled with features suggested by dozens of beta
testers like myself.
Here's what a few of my fellow Beta testers have to say about
TosScan:
"FrontDoor and TosScan fit together seamlessly...They are sim-
ply the best network mailer and echomail processor available
today... FrontDoor and TosScan are also the software of choice
for point operation..."
--- Bob Beilstein, 1:260/335
"I used to run Binkley/Confmail/Opus, but I long lusted after the
flexibility of QuickBBS. But as an NEC and defacto MacList star
I needed a fast, reliable echomail processor. TosScanQ/286 lets
me run QuickBBS."
--- Eric Larson, 1:260/330
" ...TosScan has taken the `worry' out of processing a great
deal of mail. Easy to install, easy to maintain, but most im-
portant, it is the most *ACCURATE* mail processor I have seen."
--- Bruce Bodger, NEC Net-170
"TosScan has made it easy being a Hub by it's shear speed and
power...It's everything you ever wanted in a mail processor, all
rolled up in one powerful package."
--- Kelly Drown, 170/403
"All I can say about TosScan is that it's the _slickest_
tosser/scanner I've ever seen in my entire life. ...TosScan
was the best $30 investment I made, and may the IC strike me down
with excommunication if I don't tell the truth.."
--- Felix Kasza, 2:310/11
FidoNews 6-51 Page 26 18 Dec 1989
"I have found TosScan to be a professionally conceived, executed,
and supported product. It has provided me with a low cost and
simple solution to all of my echomail needs, with a high degree
of performance."
--- Mark Howard, 1:260/340
Every feature has been tried, misused, abused and mangled during
the long months of testing. The result is a top notch product by
an author that supports his products and is readily available to
answer his users' questions.
Try it. I know you will be glad you did.
Mike Janke, 1:135/4
-----------------------------------------------------------------
FidoNews 6-51 Page 27 18 Dec 1989
Algorithm, The Personal Programming Newsletter
by A.K. Dewdney
London, Ontario, Canada
A.K. Dewdney, Computer Recreations columnist with Scientific
American magazine, has launched a personal programming
newsletter, Algorithm. The new publications is aimed at amateur
and professional programmers alike. It extends the Computer
Recreations tradition of recreational and educational
programming projects: the Mandelbrot set, cellular automata,
chaos and dynamics, wierd machines, stellar simulation, puzzles
and many other topics.
The new publication carries seven features and will expand to
include more columns. Currently, it includes Algoletter, advice
from professionals; Easy Pieces, fascinating projects for
beginning programmers by Michael Ecker of Creative Computing
fame; Personal Programs, exercises for more advanced programmers
by Cliff Pickover, IBM's computer graphics wizard; Algopuzzles,
computer mid-benders by Dennis Shasha, author of The Puzzling
Adventures of Dr. Ecco; Algofact and Algofiction, invited
articles and stories from well-known scientists and authors. A
Bulletin Board advertises hosts of recreational products by
individuals and small companies.
Algorithm puts the "personal" back in "personal computing" by
encouraging you to develop your programming skills while
pursuing high adventure on the frontiers of science and
computing. Order a free exmination copy by writing Algorithm at
P.O. Box 29237, Westmount Postal Outlet, 785 Wonderland Road,
London, Ontario, Canada N6K 1M6.
-----------------------------------------------------------------
FidoNews 6-51 Page 28 18 Dec 1989
The Node At the End Of The Universe
2:256/117
By Steve Townsley
Forget about uninterruptable power supplies this week the PSU
went bang on an AT in the office. Luckly we know a good
maintenance firm that happily trails the 170 miles from London
just to fix problems like exploding computers.
Now, like everyone else in the office, I thought that the AT
power supply had blown. Apparently I was wrong. Our peculiar
beast was not true blue and therefore didn't have an AT power
supply but a '286 power supply.
The intelligent amongst you may well ask, as I did, why a '286 is
different from an AT. Well it isn't really. It's some of the odd
bits that go into a 286 that are different from an AT. So while
we are all proud of the fact that we have a small footprint AT be
aware that a full AT power supply probably isn't in there.
So as well as blowing the fuse, fusing the network, and generally
destroying a computer we now have to wait for our maintenance man
to come back with a '286 power supply. A perfect fit for the
slimer AT!
When your AT blows up, which I hope it never will, you can save
yourself the error of ordering the wrong part by finding out
whether you have a '286 or a real AT power supply.
Graphics
One of the subjects that occasionally crosses my mind is
graphics. Not because I am some kind of expert but simply because
the various formats are beginning to gain my interest.
Like or not we are all heading towards graphics environments. The
happy existance of 7 bit ASCII is on its way out. In place we may
get variations of the Mac or something like Presentation Manager.
I know quite a few Swedes, Danes, Germans and so on that will be
pleased to see the end of 7 bit ASCII. In graphics mode all
foreign language character sets, symbols, mathematics and so on
become straightforward and unrestricted by the rather narrow
ASCII set. Even the British would like to see the pound sign
become more standardised across hardware and software.
FidoNews 6-51 Page 29 18 Dec 1989
On my Epson printer at work a pound sign is ASCII 35 - I
therefore lose the hash symbol. On my IBM proprinter the pound
sign is ASCII 156 which carefully sits in the middle of Epson's
italic character set. Finally there is yet another standard for
Hewlett Packard LaserJets.... ASCII 175 (a double chevron).
Daisy-wheel printers differ depending on which wheel you choose.
In Britain we are only trying to print one character outside the
American standard set. In Europe multiply the problem many times
over.
So in reality the acceptance of new graphics environments,
whether PC, Amiga or ST should be good news.
However I have to admit that something about these graphics
environments throws me. Not only do they seem so much slower than
my trusty, text based, PC-Write they also leave me with a feeling
of 'do not touch'. I cannot quite explain it but when I finish
this file I can type it to screen from a DOS prompt, copy it to a
printer, even send it down a telephone line. Something about a
graphics environment says that I will remove the simplicity of
the command line to be replaced by a corporate designed
leviathan.
Already the TLA's (Three Letter Abreviations) indicate that
graphics 'experts' are far worse than comms junkies. Who can tell
what a TIF, GIF or PCX file really is. How do I explain a user
friendly icon based environment in terms that the average citizen
might be enthusiastic about. Do I really have to buy a 386, 8
megabytes of memory, OS/2 Presentation Manager, Pagemaker and a
laser printer just to create a letterhead on my continuous
stationery.
I have to confess to being partly a technological rebel. If
someone could show how to include a letterhead from PC-Write on
my trusty dot-matrix printer I would be inclined to feel that
graphics have some place in my day to day computing. Wrestling
with Ventura to send out a designed invoice on continuous
stationery is hard work.
Having to create 3 separate printer drivers for 3 different
printers just to print a pound sign does not make me confident
that graphics will help. Abandoning 7 bit ASCII should help all
PC owners be more creative and help us foreigners with a
universal standard character set. However I have this suspicion
that maybe software developers are not going to make it that
easy.
Finally if you have a comment to make on anything I ramble on
about address it to 'The Node At The End Of Universe somewhere in
Zone 2' or shorthand 2:256/117. Yes I do have a Compuserve
address - but it's far to expensive to use from this corner of
the Galaxy.
FidoNews 6-51 Page 30 18 Dec 1989
VIA 0:0/0 <grin>
-----------------------------------------------------------------
FidoNews 6-51 Page 31 18 Dec 1989
Utility authors: Please help keep this list up to date by
reporting new versions to 1:1/1. It is not our intent to list
all utilities here, only those which verge on necessity.
-----------------------------------------------------------------
FidoNews 6-51 Page 34 18 Dec 1989
Thom Henderson 1:107/528 Chairman of the Board
Les Kooyman 1:204/501 President
Fabian Gordon 1:107/323 Vice President
Bill Bolton 3:3/0 Vice President-Technical Coordinator
Kris Veitch 1:147/30 Secretary
Kris Veitch 1:147/30 Treasurer
IFNA COMMITTEE AND BOARD CHAIRS
Administration and Finance *
By-laws and Rules John Roberts 1:385/49
Executive Committee (Pres) Les Kooyman 1:204/501
International Affairs *
Membership Services Jim Vaughan 1:226/300
Nominations and Elections Steve Bonine 1:1/0
Public Affairs David Drexler 1:147/30.20
Publications Irene Henderson 1:107/9
Technical Standards Rick Moore 1:115/333
Ethics *
Security and Privacy *
Grievances *
* Position in abeyance pending reorganization
IFNA BOARD OF DIRECTORS
DIVISION AT-LARGE
10 Courtney Harris 1:102/732 Don Daniels 1:107/210
11 John Rafuse 1:12/900 Phil Buonomo 1:107/583
12 Bill Bolton 3:711/403 Mark Hawthorne 1:107/238
13 Fabian Gordon 1:107/323 Tom Jennings 1:125/111
14 Ken Kaplan 1:100/22 Irene Henderson 1:107/509
15 Kevin McNeil 1:128/45 Steve Jordan 1:206/2871
16 Ivan Schaffel 1:141/390 Robert Rudolph 1:261/628
17 Kathi Crockett 1:134/30 Dave Melnik 1:107/233
18 Andrew Adler 1:135/47 Jim Hruby 1:107/536
19 Kris Veitch 1:147/30 Burt Juda 1:107/528
2 Henk Wevers 2:500/1 Karl Schinke 1:107/516
3 Matt Whelan 3:54/99 John Roberts 1:147/14
-----------------------------------------------------------------
FidoNews 6-51 Page 36 18 Dec 1989
Membership for the International FidoNet Association
Membership in IFNA is open to any individual or organization that
pays a specified annual membership fee. IFNA serves the
international FidoNet-compatible electronic mail community to
increase worldwide communications.
Member Name _______________________________ Date _______________
Address _________________________________________________________
City ____________________________________________________________
State ________________________________ Zip _____________________
Country _________________________________________________________
Home Phone (Voice) ______________________________________________
Work Phone (Voice) ______________________________________________
Zone:Net/Node Number ____________________________________________
BBS Name ________________________________________________________
BBS Phone Number ________________________________________________
Baud Rates Supported ____________________________________________
Board Restrictions ______________________________________________
Your Special Interests __________________________________________
_________________________________________________________________
_________________________________________________________________
In what areas would you be willing to help in FidoNet? __________
_________________________________________________________________
_________________________________________________________________
Send this membership form and a check or money order for $25 in
US Funds to:
International FidoNet Association
PO Box 41143
St Louis, Missouri 63141
USA
Thank you for your membership! Your participation will help to
insure the future of FidoNet.
Please NOTE that IFNA is a general not-for-profit organization
and Articles of Association and By-Laws were adopted by the
membership in January 1987. The second elected Board of Directors
was filled in August 1988. The IFNA Echomail Conference has been
established on FidoNet to assist the Board. We welcome your
input to this Conference.
