F I D O N E W S -- Volume 14, Number 9 3 March 1997

F I D O N E W S -- Volume 14, Number 9 3 March 1997
+----------------------------+-----------------------------------------+
| The newsletter of the | ISSN 1198-4589 Published by: |
| FidoNet community | "FidoNews" |
| _ | 1-904-409-7040 [1:1/23] |
| / \ | |
| /|oo \ | |
| (_| /_) | |
| _`@/_ \ _ | |
| | | \ \\ | Editor: |
| | (*) | \ )) | Christopher Baker 1:18/14 |
| |__U__| / \// | |
| _//|| _\ / | |
| (_/(_|(____/ | |
| (jm) | Newspapers should have no friends. |
| | -- JOSEPH PULITZER |
+----------------------------+-----------------------------------------+
| Submission address: FidoNews Editor 1:1/23 |
+----------------------------------------------------------------------+
| MORE addresses: |
| |
| submissions=> [email protected] |
+----------------------------------------------------------------------+
| For information, copyrights, article submissions, |
| obtaining copies of FidoNews or the internet gateway FAQ |
| please refer to the end of this file. |
+----------------------------------------------------------------------+

WANT YOUR MESSAGE IN THIS SPACE? SEND IT IN!

Table of Contents
1. EDITORIAL ................................................ 1
No responses to last week's Questions .................... 1
2. ARTICLES ................................................. 2
Net 1:231 Has a New Web Page ............................. 2
'Anarchy' in Region 50 Russia - no RC? ................... 2
An Innocent Bystander .................................... 3
3. GETTING TECHNICAL ........................................ 6
FSC-0044 - Improved method of duplicate message detecti .. 6
4. COORDINATORS CORNER ...................................... 20
Nodelist-statistics as seen from Zone-2 for day 059 ...... 20
5. WE GET EMAIL ............................................. 21
Another Internet-FidoNet query ........................... 21
6. NET HUMOR ................................................ 24
Computer riddles? ........................................ 24
7. NOTICES .................................................. 25
Future History ........................................... 25
8. FIDONET SOFTWARE LISTING ................................. 26
Latest Greatest Software Versions ........................ 26
9. FIDONEWS PUBLIC-KEY ...................................... 32
FidoNews PGP public-key listing .......................... 32
10. FIDONET BY INTERNET ..................................... 33
11. FIDONEWS INFORMATION .................................... 35
FIDONEWS 14-09 Page 1 3 Mar 1997

=================================================================
EDITORIAL
=================================================================

Quando Omni Flunkus Moritati strikes again. [See FidoNews 1351.]

Seems to be a little uproar in Russia.

USR is finally releasing the X2 firmware download for those who
have V34s and haven't heard.

The FSC in this week's Issue was written by Jack Decker who left
FidoNet about three years ago but still reads the FidoNews and
wanted to say 'hi' to those who remember him. His contact info
appears at the end of his FSC today.

We have a couple new FidoNet sites in the Internet section.

There are no Headlines or film at eleven this week.

C.B.

-----------------------------------------------------------------

FIDONEWS 14-09 Page 2 3 Mar 1997

=================================================================
ARTICLES
=================================================================

Net 1:231 Has a New Web Page
by Richard Bash - 1:231/0
Internet: [email protected]

FidoNet 1:231 in Indianapolis, Indiana, is pleased to announce
the creation of a web page for the Net. The URL is:

http://www.oaktree.net/net231

While no astounding creation of art, the page lists all of the
members of Net 231, their BBS names, BBS phone numbers and also
provides links to web pages of the members of the Net. Documents
such as POLICY4.DOC, the local Net operating guidelines and a node
application form are also available via the web page. You are
invited to visit the site and provide your constructive comments on
ways to improve the page.

-----------------------------------------------------------------

Elections of R50C went crazy

By Mikhail Ramendik, 2:5020/145.43, [email protected]

WARNING: this question caused much flame in the Russian sysop areas.
I am not into it either side, in fact I'm not a Node at all. I just
want to communicate an interesting story.

It all started as usual. R50C, Basil Dolmatov 2:5020/140, has quietly
resigned. Elections were announced, Kostya Boyko 2:5020/37 became
Returning Officer.

The elections were to end somewhere like February 17. But some mail
was lost on the way to the RO. So the senders (an entire Net)
requested a prolongation. The RO granted it to 22 Feb. Then...

On 19 Feb he announced the results. Dmitry Zavalishin, 2:5020/32, won.

He claimed that as the mail from the requestors has arrived, the vote
was over, despite the public announcement of prolongation. Flame
started here.

But it did not end here. For the winner got only 44% of the votes
that came, with Mikel Lavrentyev 2:5020/35 second with 23%. A second
run - between these two was requested from the RO and finally granted
by him. But...

BY THIS TIME, THE OLD RC AND THE ZC HAVE RECOGNIZED THE NEW RC!!!

So now we have no publicly accepted RC. Anarchy? ;)

FIDONEWS 14-09 Page 3 3 Mar 1997

This situation is very dynamic. In fact it may change by the time
this article reaches Fidonews. And I hold NO opinion on what side is
right. But it calls us to some thoughts.

What has become of the Net which started as just a union of friendly
SysOps?

Why has the Founding Father Tom Jennings left his creation? I have
his answer here in a letter of July 1994. The text of the letter
makes it clear that this information is not confidential.

8<

Personally, I consider "policy4" to be a smelly old crock of shit.
You can quote me on that, only you will find many people have heard
me say it before... :-)

Note that "POLICY4" contains valid procedural advice and information
-- how to assign numbers, how to define a functional system, and
such. For that it's fine. Otherwise, the actual policy is intended to
let a small number of people control the behavior and speech of
another, larger group of people. I immediately mistrust people who
propose such things. If they are young enough, I give them time to
get over it :-)

8<

Do we NEED to have this structure, so that the RC elections become
something like Presidential ones with all the necessary scandals?
Surely the *backbone* needs management, but then the Net and the
backbone are not the same, and one theoretically can be a node and
not link to a backbone.

I'm NOT proposing anything here. It's just food for thought. And - I
apologize to Tom Jennings if it was not good to quote his letter.

In fact, my secret desire is that he would show up here with an
article explaining his thoughts. Perhaps we have grown old enough to
understand.

Mikhail Ramendik. Moscow, Russia. Team OS/2.

-----------------------------------------------------------------

An Innocent Bystander
Robert "Not a Sysop" Parson
Jackalope Junction 1:3822/1

I've been reading Fidonews with great interest over the past several
months (actually years, but that's another matter). Quite a few
things have sparked my interest, and I thought I'd comment as an
"interested bystander." (It's true, I'm really not a sysop.)

I noticed a disturbing trend in the Coordinator's Corner that Zone 1
FIDONEWS 14-09 Page 4 3 Mar 1997

was losing roughly 200 nodes a week, so I started keeping my own stats
on the Nodelist. There are some differences, which I attribute mainly
to the differences in which we are compiling our stats, but generally
turned up the same thing. At this rate, Zone 1 will cease to exist in
midsummer 1998. By the way, according to the latest report published
in Fidonews, the number of nodes in North America has now slipped
below 10,000. My hat's off to Ward Dossche for compiling and making
this analysis available.

On this subject, someone noted a couple months ago that most of the
nodes in Zone 2 are not BBSs. His description sounded like most of
them were glorified points. If someone could explain this a bit
better or clear up any misunderstanding on my part, I'd appreciate it.

Someone else noted (I really should keep Fidonews archived on my
computer and give these people the appropriate credit. But again, I'm
not a Sysop) that a "State of the Network" message/address/whatever
would be of interest. There are significant problems with Fidonet
both technically and internally. He's in charge, at least nominally,
and we should demand he say something.

Election underway for IC and pending for Z1C? Without notice in
Fidonews? After consulting Policy 4, it appears notice of elections
is not necessary. Looks like something that needs to be fixed.

And about that Policy 4... forget it. P4 doesn't work. It's
outdated and the only reason it's pulled out is when somebody has some
griping to do. Should The Powers That Are ever decide to update
Fidonet Policy, don't bother with P4.whatever. Scrap the darn thing
entirely, start fresh, skip a P5 even and go on to P6. My first
recommendation is to split it into two documents. One that is
specific to technical standards, the other for personnel matters
(moderators, coordinators, and the ubiquitous etc). I also think a
Fidonet Users' Guide for non-sysops would be very helpful.

Since the latest Big Controversy seems to be Chris Baker's editorship
of Fidonews, I thought I'd comment on that as well.

I contacted Donald Tees about taking over the reigns about two years
ago when he originally announced he was considering resigning. My
vision was somewhat different from his and the (unwritten) mission of
Fidonews. So, I opted out. Nobody else picked up the standard. Late
last year, Donald disappeared from Fidonet. After several weeks
hiatus, and apparently quite a bit of non-action on the part of those
who had responsibility, Chris began publishing Fidonews. There are
some things I would not have done, and a few things I wish I'd thought
of. But generally, I think he's doing a good job with this thankless
position.

If there's somebody upset enough with Chris' editorship, there's
nothing to stop them from publishing a competing Fidonews, as long as
it doesn't actually call itself "Fidonews" or represent itself as the
"Official Publication of Fidonet." I think anyone who tries will find
out exactly how difficult it is.

Now that I've rattled on a bit, I guess I should tell you what I bring
FIDONEWS 14-09 Page 5 3 Mar 1997

to the table since I've noted I'm not a sysop: nothing. I'm just a
user of a local BBS. And isn't bringing us users together what
Fidonet is all about? I'm keenly interested in the continued
viability of Fidonet. And frankly, it looks pretty shaky.

Robert Parson 1:3822/1

-----------------------------------------------------------------

FIDONEWS 14-09 Page 6 3 Mar 1997

=================================================================
GETTING TECHNICAL
=================================================================

[This is part of a continuing series of FTSC Standards and Proposals
and the FidoNet History series. These docs have been reformatted to 70
columns where necessary. Node numbers that appear in these docs are
often no longer in service. Check your Nodelist for current listings
of authors.] Ed.

Document: FSC-0044
Version: 002
Date: 07-Oct-1990

An improved method of duplicate message detection and prevention

Jack Decker
1:154/8@Fidonet

Status of this document:

This FSC suggests a proposed protocol for the FidoNet(r)
community, and requests discussion and suggestions for
improvements. Distribution of this document is subject to the
restrictions stated in the copyright paragraph below.

Fido and FidoNet are registered marks of Tom Jennings and Fido
Software.

Purpose:

The purpose of this document is to present a proposal for an improved
method of duplicate message detection and prevention, that could
eventually replace the existing PATH and SEEN-BY lines currently used
within Fidonet. The principal advantages of this method over previous
schemes is that it is fully Domain-, Zone-, and Point-aware, and that
it adds far fewer bytes to a message than the current combination of
SEEN-BY and PATH lines. It can also be run in parallel with existing
SEEN-BY and PATH lines for an indefinite period, thus allowing a
"transition period" of as long as is necessary for software to be
converted.

Copyright:

This document is Copyright 1990 by Jack Decker. However, permission
is granted for any and all non-commercial use, providing the contents
of this document are not altered in any way. Also, permission is
expressly granted for any use by developers of software primarily
intended to be used in the Fidonet amateur communications network, or
in any similar amateur communications network that primarily uses
Fidonet technology and protocols, whether that software is commercial
or not.

Comments on this proposal, and suggestions for improvement are
FIDONEWS 14-09 Page 7 3 Mar 1997

welcomed by the author. In particular, suggestions on how this
proposal might be reworded to make the meaning clearer are especially
welcome.

A. Definition:

In this document the characters ^A (caret and capital A) will be used
to represent a 0x01 (SOH) byte. It will be most commonly used in
reference to the "^APTH line", which will be a line that begins with a
0x01 byte immediately followed by the letters "PTH" (and then by
additional data as specified below).

B. Why a new method of duplicate message detection is needed:

Most of the methods of duplicate message detection currently used in
Fidonet echomail processing operate by trying to find some
distinguishing characteristic of an echomail message (whether it be
something deliberately included in the message, such as an EID, MSGID,
etc. type of "kludge line", or something which is contained in all
echomail messages, such as the message header). Typically, either the
item being used for duplicate detection itself or a checksum of that
item is then saved in a data file, and if another item comes in with
that same distinguishing characteristic, the message is considered to
be a duplicate message. The data files used to store previously-seen
message data can occupy a significant amount of disk space if many
conferences are carried on a system.

Unfortunately, all such schemes seem to suffer from the drawback that
under the proper circumstances, messages that are not duplicates of
each other may be created with identifying characteristics that are
similar enough to be falsely recognized as duplicates. The
circumstances under which this can happen may differ from method to
method, but none are totally foolproof. Thus, it's possible that
messages may be deleted as duplicates even though in reality they are
not duplicates, but rather they are simply messages that contain data
that make them appear to be duplicates.

The most common cause of duplicate messages is improper echomail
topology (also known as the infamous "dupe loop"). While there are
certainly other ways that duplicates can be generated, improper
topology is far and away the leading cause. Further, many of the
current duplicate elimination schemes will NOT catch most of the
duplicates that are NOT generated as a result of improper topology
(which is why duplicate messages are seen occasionally, even though
duplicate message detection schemes are currently in use).

Unfortunately, if a duplicate killer is to be effective, it must store
the identifying characteristics for the last several thousand messages
that have passed through a particular system. This not only uses up
disk storage space, it consumes extra processing time during echomail
processing, since each new arriving message must be compared to the
data list in the attempt to determine if it is, indeed, a duplicate.

A better approach would be to store within a message itself data that
identifies it as having already been received by a particular system,
before sending it on to another system. Then, if the same message
FIDONEWS 14-09 Page 8 3 Mar 1997

came back to a given system in a "dupe loop", it would be possible to
positively identify it as one that has already been seen on that
particular system. And, since the data necessary to identify the
message as a duplicate is stored within the message itself, it is
possible to use this method without the necessity of storing great
amounts of data on previously-seen messages (in many implementations
this alone would save 10K or more of disk space per conference
carried!).

Were it not for the fact that the PATH line present in most echomail
messages does not contain Zone or Point information, we could use it
for that purpose. However, since it does not contain that
information, it cannot and should not be used in that manner. Another
drawback of the PATH line is that because it is physically located at
the end of a message (after the SEEN-BY lines), if only the last part
of a message is scrambled or deleted, the PATH line information will
be lost.

C. Proposal:

1) A new type of kludge line (commonly known within FIDONET as an
"IFNA kludge line"), which combines certain characteristics of the
existing PATH and SEEN-BY lines, will be placed into each echomail
message. This line, known as the ^APTH line, will be placed at the
TOP of the message (not necessarily the first line, but prior to the
body of the message text). IMPORTANT: Support for the existing PATH
and SEEN-BY lines will be retained as long as is necessary to
accommodate everyone in Fidonet, but eventually the ^APTH line could
possibly replace both the current PATH and SEEN-BY lines.

2) The ^APTH line will contain full five-dimensional addressing
(Zone:Net/Node.Point@Domain), BUT elements that are the same as the
previous entry in the line need not be repeated (except when a message
passes to a new domain, in which case the full address of the first
node in the new domain shall be given). When the "point" portion of
an address stands alone, it shall be preceded by at least a "."
character (to distinguish it from a node address).

3) If a system is importing messages and finds a message with its own
address already in the ^APTH line, it will discard the message (unless
that address is in the very last position on the line... this allows
for the odd situation where a point or another task on the same system
has already inserted the system's address in the ^APTH line, or where
it is desirable to process the same message a second time).

4) One (and only one) modifier character may appear just AFTER any
address on the ^APTH line. When using the ^APTH for duplicate message
checking only, you may just skip past any such address, unless it's
your own address (see examples later in this document). In that case,
strip the address and the modifier character (in other words, if you
see your own address but it's immediately followed by a modifier
character, remove that address, add yours to the end of the ^APTH
line, and toss the message anyway). The reason for doing this is to
allow the design of an echomail processor that doesn't rely on SEEN-
BY's. Such a processor could append a modifier character (such as a
"!") to an address, in order to indicate that "this message hasn't
FIDONEWS 14-09 Page 9 3 Mar 1997

really passed through this node, but don't send it back there" (which
would be the equivalent of a SEEN-BY statement for that node,
indicating that this message has already been sent to that node).
Thus the ^APTH line could eventually take the place of SEEN-BY lines,
but you could still have a "fully coupled" triangular or rectangular
topology. In this case, you'd add the nodes that are part of that
fully coupled topology to the ^APTH line BEFORE sending the message to
them, but with the special character after the address. The receiver
would know that the message didn't really pass through that node yet,
but it should NOT send it to that node under any circumstances.

(Please note that during the initial design of software to create
^APTH lines, you would not have to worry about generating the special
case with the trailing modifier characters, you'd just have to be able
to handle them as shown in the examples below if you came across one).

D. Specifications and examples:

The general specifications for a ^APTH line, and a general outline of
how an incoming message might be processed follows.

A valid ^APTH line will contain at a minimum the string ^APTH followed
by a single space character and the network address of the system that
created the ^APTH line, in Zone:Net/Node[.Point]@Domain format, where
^A is a 0x01 byte (SOH) and the point address is required only if the
system is a point (specifically, a system that is NOT a point should
not use .0).

Once again, the FIRST Fidonet-technology address specified in a ^APTH
line is expected to contain, at a minimum, Zone, Net, and Node
numbers, and a valid Domain string preceded by the "@" character. If
any of these are missing from the FIRST address, the line should be
considered defective (exception: See Note 5, "Messages sent to/from
non-Fidonet-technology networks"). It will be left to the discretion
of the software author as to how to handle a message with a defective
^APTH line.

Subsequent addresses in the ^APTH line are delimited by spaces and
should contain only that information that is different from the
previous entry on the line, except when a message passes into a new
domain (in which case the full address of the first system in the new
domain shall be given) or when a bossnode receives a message from a
point, in which case the bossnode should append its node number only.
Specific examples follow:

a. If the Domain and Zone are the same as the previous address,
but the net is different, then only Net/Node[.Point] should be
used.

b. If the Domain, Zone and Net are the same as the previous
address, but the node is different, then only Node[.Point]
should be used.

c. If the Domain, Zone, Net, and Node are the same as the
previous address, but the point is different, then only .Point
should be used. Note that in this case, the period is
FIDONEWS 14-09 Page 10 3 Mar 1997

included.

d. If the Domain, Zone, Net, and Node are the same as the
previous address, but the previous address contains a point
specifier and the receiving system is not a point (i.e., it IS
the bossnode), then only Node should be used. .0 (point zero)
might also be a valid entry in this case, but only if the
bossnode consistently identifies itself to other systems using
a full five-dimensional address. For example, a message that
originated on 1:234/5.6@Fidonet and went from there to 1:234/5
would contain a ^APTH line in this format:
^APTH 1:234/5.6@Fidonet 5
If the bossnode is also considered to be point zero, then
^APTH 1:234/5.6@Fidonet .0
Would be equally valid.

In the case of a "fully connected" topology, nodes may be added to the
^APTH line even though a message has not actually passed through those
nodes, to prevent the message from being sent to those nodes. Such
nodes should have an exclamation point character ("!") appended to the
end of the entry, immediately following the node or point number.
These nodes should be added to the very end of a new or existing ^APTH
line, after the address of the node which added them.

For example, suppose that 157/200, 154/9, and 228/6 were in a "fully
connected" topology. When a message was received by 157/200 and then
sent to 154/9 and 228/6, the ^APTH line might look something like
this:

^APTH: 3:711/431.5@Fidonet 431 403 1:124/4210 4115 157/200 154/9!
228/6!

When a message arrives on one of the nodes indicated by the
exclamation point, the exclamation point entry should be removed, and
the node should add itself to the end of the line in the normal
manner. For example, after the message containing the above ^APTH
line were received at 154/9, it would be modified to read:

^APTH: 3:711/431.5@Fidonet 431 403 1:124/4210 4115 157/200 228/6!
154/9

Please note that at the time of this proposal, the exclamation point
(!) is the ONLY "officially recognized" modifier character that can be
expected to be appended to a ^APTH line address (except for the
@Domain string, of course), however, the possibility remains that
someone may figure out a good reason to use a different trailing
character for some other (but similar) purpose, so I am allowing for
that possibility by using the generic terminology "modifier character"
rather than the more specific "exclamation point" throughout this
document.

The ^APTH line must be terminated with a carriage return and/or
linefeed (a carriage return followed by a linefeed is preferred, and
should be used by all systems capable of generating a carriage
return/linefeed combination).

FIDONEWS 14-09 Page 11 3 Mar 1997

There is no specified limit on the length of a ^APTH line. Each
message should contain only one ^APTH line, even if it extends beyond
the typical 80 column screen width. The ^APTH line is primarily
intended for use by the conference mail processing software, so
primary consideration is being given to ease of processing the line,
rather than making it easily human-readable (most software will not
display kludge lines hidden behind a ^A character in any event).

E. Pseudo-outline of message processing

Here is a suggested flow pseudo-outline showing one way that messages
might be processed in a standalone program that runs between the
import and export cycles of an existing conference mail processor such
as ConfMail (this outline assumes that the standard Fido/Opus style
*.msg files are used, though obviously that need not be the case):

1. Open *.msg file for input

2. Open temporary file for output

3. Copy header (first 190 bytes) from input to output file. The
following operations begin immediately following this header.

4. Examine each line of input file (a line is delimited by a carriage
return, linefeed, or any combination thereof) for one of the
following:

a. A blank line - Write to output and examine next line.

b. A line containing spaces only - Write to output and examine
next line.

c. A line that begins with a 01 byte (SOH) - GoTo 5.

d. A line that does not meet any of the above specifications.

I. Create a line containing the string ^APTH followed by a
single space character and your network address, in
Zone:Net/Node[.Point]@Domain format, where ^A is a 0x01
byte (SOH) and the point address is required only if you
are a point (specifically, a system that is NOT a point
should not necessarily use .0). This line should be
terminated with a carriage return and/or linefeed (a
carriage return followed by a linefeed is preferred).

II. Write the line created in 4.d.I. to the output file.

III. Write the line input in 4. to the output file.

IV. Goto 9.

5. If a line begins with a 0x01 (SOH) byte, examine the keyword
immediately following it.

a. If the keyword is NOT "PTH", write the entire line to output
and examine the next line (go back to 4).
FIDONEWS 14-09 Page 12 3 Mar 1997

6. If a line begins with ^APTH, examine each address in the line in
turn. Addresses start immediately following the characters "PTH "
(note the space).

a. The FIRST Fidonet-technology address (not counting any
pseudo-addresses consisting solely of "@Domain") is expected
to contain, at a minimum, Zone, Net, and Node numbers, and a
valid Domain string preceded by the "@" character. If any of
these are missing from the FIRST Fidonet-technology address,
the line should be considered defective (See Note 5, "Messages
sent to/from non-Fidonet-technology networks", for information
on "@Domain" entries). It will be left to the discretion of
the software author as to how to handle a message with a
defective ^APTH line.

b. As each address is found, any Zone, Net, and Node numbers and
Domain strings found should be stored in temporary variables,
to be used as defaults for subsequent addresses when only a
partial address is given. For example, the first address will
contain a Zone number. This should be stored in a temporary
variable and used as the default Zone for all subsequent
addresses, until and unless another Zone number is seen in the
line, at which time that Zone number should be stored in the
temporary variable and used as the default Zone.

c. If an address is found that consists entirely of the "@"
character (as the first character of the address) followed by
a domain name (with or without punctuation), all temporary
variables (defaults) should be cleared (since any subsequent
Fidonet-technology address should contain full
Zone:Net/Node[.Point]@Domain information). Otherwise, such
pseudo-addresses (consisting solely of @Domain) may be ignored
at systems that do not serve as inter-network gateways (such
entries are maintained only by inter-network "gateway"
software). However, they should not under any circumstances
be removed from the ^APTH line.

7. As each address is found, it should be compared against the
system's address. If a match is found:

a. Check to make sure that the address is not a point address if
the system's address does not contain a point specifier. If
the system's address is given without a point specifier, then
it should not be considered a match if ANY point address is
found in the ^APTH line address that is being compared (not
even .0 - for example, if the address 1:234/5.0 is seen in the
^APTH line, and 1:234/5 is the given system address, then it
is NOT a match).

b. If the address does match exactly, check to see if a modifier
character (specifically the "!" character) immediately follows
the address. If it does, then that address must be removed
from the line at that point.

I. When removing an address, please make sure that you do
not change the address of subsequent entries. This may
FIDONEWS 14-09 Page 13 3 Mar 1997

require modification of the next entry on the line, if
one exists. For example, suppose you had a "fully
connected" topology where 1:157/200 sent an echo to both
1:154/9 and 1:154/970. The ^APTH line might end
as follows:
..... 157/200 154/9! 970!
However, after modification of the ^APTH line, it should
read: ..... 157/200 154/970! 9
You can see that if 154/9 were simply deleted without
regard to what follows on the line, the following
(incorrect) line might result:
..... 157/200 970! 154/9 (THIS IS
INCORRECT)
The above is incorrect because 154/970 has been
transformed into 157/970.

II. After removing an address followed by a modifier
character, continue to scan any remaining addresses in
the ^APTH line in case a match is found later in the
line. If no other matches are found, proceed as if no
match had been found. Goto 8.

c. Check to see if the address is the last one on the line (not
counting addresses that have a modifier character immediately
following them). If this address is followed only by the end
of the line, or ONLY by addresses that have a modifier
trailing character, then there is a very high probability
that we have either inadvertently or deliberately processed
this message twice, and it is not really a duplicate. In
this case, the original *.msg file should be left untouched.

I. Close both the input and output files.

II. Delete the temporary output file. END.

d. If a match is found, and it is not followed by a modifier
character, and it is not the last address on the ^APTH line,
then the message is a duplicate message and should be treated
as such (either by deleting it, or moving it to a "bad
messages" area or the netmail area).

I. Close both the input and output files.

II. Delete the temporary output file.

III. Either delete or move the original .msg input file, as
appropriate. END.

8. If the end of the ^APTH line is reached and a match has not been
found, then add the system's address to the end of the ^APTH line.
Then write the modified ^APTH line to the output file.

I. If one or more addresses with an appended modifier
character (used within "fully-coupled" topologies) are
to be added to the ^APTH line, they should be added at
the very end of the line, after the address of the
FIDONEWS 14-09 Page 14 3 Mar 1997

system currently processing the message).

9. Copy the remainder of the input file to the output file. Close
both files.

10. Delete the input file.

11. Rename the temporary output filename to the old input filename.
END.

[End of outline]

F. Additional notes and clarifications:

Note 1: In section 7.b.I. I mentioned the necessity of not simply
deleting a node from the ^APTH line without checking to see if the
next address in the ^APTH line needs to be modified. This can easily
be accomplished if TWO sets of temporary variables are kept, for the
CURRENT and PREVIOUS Domain, Zone, Net, and Node information (Point
addresses are NOT kept as defaults, thus there is no need to store
Point information). When reading the FIRST address in the ^APTH line,
the Domain, Zone, Net, and Node information of that address would be
stored in both the CURRENT and PREVIOUS variables. Thereafter,
whenever a new Domain string or Zone, Net, or Node number is
explicitly specified in a ^APTH line address, the new value(s) are
stored in the CURRENT variables, but first the CURRENT values are
moved to the PREVIOUS values.

To help visualize this, let's again suppose we have a ^APTH line that
ends as follows (all of these addresses are in Fidonet Zone 1):

..... 157/200 154/9! 970!

Let's suppose that we are processing this message on 154/9, and will
need to remove the 154/9! address. When we encounter 157/200, our
variables will be set as follows:

Previous | Current
Domain Fidonet | Fidonet
Zone 1 | 1
Net ? | 157
Node ? | 200

Now, when we read 154/9, our current values will be moved to the
previous:

Previous | Current
Domain Fidonet | Fidonet
Zone 1 | 1
Net 157 | 154
Node 200 | 9

We now have the data we need to determine what needs to be added to
the next address, after we delete 154/9. In this case, we need only
compare the Previous and Current addresses to determine which are
UNEQUAL. In this case, the Zone and Domain are the same, but the Net
FIDONEWS 14-09 Page 15 3 Mar 1997

and Node are not. So, if the following address lacks either the Net
or Node, we'll have to add those. Now we delete the 154/9! and look
at the next address, 970. At this point our variables will look like
this:

Previous | Current
Domain Fidonet | Fidonet
Zone 1 | 1
Net 154 | 154
Node 9 | 970

Again, we compare to see which addresses are UNEQUAL. In this case,
only the NODE address is. So we know we do NOT have to add the NODE
address, nor do we have to add the Zone or Domain information (because
they were not different on the first compare). We only need add those
address components which were unequal on the first compare, but equal
on the second compare. So, in this case, the Net address must be
added to the next address in the ^APTH line, leaving as a result:

..... 157/200 154/970!

The current system address is then added back in at the end of the
line, thus:

..... 157/200 154/970! 9

Note that whenever a new Domain is specified, the full address (four-
or five-dimensional, depending on whether a point address is given)
must be used. In other words, an address that includes an "@Domain"
string but that does not also include the Zone, Net, and Node
components of the address is considered invalid (it does not meet
specifications).

Note 2: In section 4.d it is suggested that, when a line that is
neither blank nor a kludge line (that begins with a ^A character) is
found, a ^APTH line be added at that point. However, there are
reports that under certain circumstances (particularly when messages
are "forwarded" or "hurled"), certain software may insert a non-kludge
line prior to previously-existing kludge lines in a message. It
should be recognized by software authors that a non-kludge line should
NEVER be inserted in front of existing kludge lines located at the
start of a message, if those kludge lines are still valid (and if they
are NOT still valid, they should be removed. When a message is
forwarded or hurled, it is probably desirable to remove duplicate
control information since what is essentially happening is that the
text of a previous message is being inserted into a NEW message.
Since the message is new, the "old" duplicate control information is
no longer valid).

Software authors that are implementing the ^APTH line in their
software should never search beyond the first text line of a message
for the ^APTH line, because if one is found later in the text, it is
in all probability an old ^APTH line that was inadvertently copied
over from another message, and is not relevant to the current message.

Note 3: This is an optional suggestion, for use during the transition
FIDONEWS 14-09 Page 16 3 Mar 1997

period in which the ^APTH line has to coexist with more traditional
PATH and SEEN-BY lines. If ^APTH line checking is being used during
the import phase of echomail processing in a conference mail
processor, it might be a good idea to optionally check to make sure
that all ^APTH line addresses that are in the system's home Zone and
Domain (including those with an appended modifier character) have been
properly included in the SEEN-BY lines, and to add any that have not
been so included. It should be obvious that ^APTH line addresses that
are NOT in the system's home Zone and Domain should NOT be added to
the SEEN-BY lines. If this feature is implemented, it may be a good
idea to give the sysop the ability to enable or disable it by means of
a command line switch or a configuration file option.

Note 4: If nodes with trailing modifier characters are inserted into
a ^APTH line for the purpose of indicating "SEEN-BY" nodes in a fully
coupled topology, it is permissible (but not required) to include
those nodes ONLY in the ^APTH lines of messages actually exported to
the nodes participating in the circular topology. In other words,
it's permissible to add such nodes to the ^APTH lines of messages
during the import cycle, in which case messages with ^APTH lines
containing the added nodes would be exported to all nodes. However,
it's also permissible to add those nodes to the ^APTH line during the
export cycle, including them only in the ^APTH lines of the nodes that
need to see them. Please keep in mind that such nodes are added only
to the END of the ^APTH line, AFTER the address of the system
processing the message. In any event, it's up to the software author
to implement this feature in such a manner that duplicates will not be
created.

Similarly, if a node RECEIVES a message containing a ^APTH line that
lists nodes with trailing modifier characters, it is permissible to
remove those nodes from the ^APTH line if it can be positively
ascertained that they are no longer required. Generally speaking,
this should NOT be done unless there is absolutely NO possibility of
the message being exported to one of the nodes in question. Note that
in most situations, if a ^APTH line contains a node with a trailing
modifier character, but it is followed by a node number (other than
your own) that does NOT have a trailing modifier character (that is,
the node with the trailing modifier character is not one of the last
nodes on the line), then it can usually be safely removed since it
will have already "passed through" the fully-coupled topology.

Using the previous example of 157/200, 154/9, and 154/970
participating in a fully-coupled topology, the ^APTH line as received
at 154/9 and 154/970 might end as follows:

..... 157/200 154/9! 970!

However, please note that if 157/200 also feeds other nodes that are
NOT part of this particular fully coupled topology, there is no real
reason they would have to see the "154/9! 970!" at the end of the
line. However, there is no prohibition against including those nodes
in the ^APTH lines of messages exported to other nodes.

Once this example message arrives at 154/9, the ^APTH line would be
changed to look like this:
FIDONEWS 14-09 Page 17 3 Mar 1997

..... 157/200 154/970! 9

Now, when this message is exported from 154/9 to another node (154/111
for example), that node may remove the "154/970!" as long as 154/9
remains in the ^APTH line, since as long as the message cannot be sent
back to 154/9, it cannot re-enter the fully-coupled topology. The
^APTH line at this point (after the message is received on 154/111)
might look like this:

..... 157/200 154/9 111

It would probably not be advisable to remove the "154/970!" at 154/9
in this example, even if the message has already been exported,
because the message might need to be re-exported (such as when a new
board picks up an echo feed).

When in doubt, nodes with trailing modifier characters (other than
your own) should be left in the ^APTH line. While there is a cost of
a few extra bytes per message if you leave them in, it does not
compare to the cost of the duplicate messages that could be generated
if they are removed indiscriminately.

Note 5: Messages sent to/from non-Fidonet-technology networks: When
a message originates in, or is sent to, a non-Fidonet-technology
network (a network that does not use the Zone:Net/Node.Point
addressing format), it is permissible to indicate this in the ^APTH
line by using the syntax "@Domain" standing alone. For example, a
message that comes into Fidonet via a gateway from the Internet might
show a ^APTH line as follows:

^APTH: @Internet 1:114/15@Fidonet 5 ...

Note that in the above example, the first Fidonet-technology address
must still contain, at a minimum, Zone, Net, Node, and Domain
information.

It's also permissible to show a non-Fidonet-technology network at some
point in the ^APTH line other than at the beginning, if for some odd
reason a conference starts out in a Fidonet-technology network, passes
through a non-Fidonet-technology network, and then is picked up by
another Fidonet-technology network. For example,

^APTH: [Fidonet addresses] ..... 114/5 15 @Internet
200:5000/400@Metronet

Note that "@Internet" stands alone in the above example, meaning that
the conference originated in Fidonet, passed into the Internet (where
the ^APTH line was not maintained), and then back into a Fidonet-
technology network (Metronet in this case). Note that any Fidonet-
technology address that follows a standalone Domain specifier must
contain, at a minimum, Zone, Net, Node, and Domain information.

The question immediately arises, how do you maintain the original
Fidonet-technology ^APTH line while the message passes through another
(non-Fidonet-technology) network? This could be left solely to the
discretion of the designers of the gateway software, but in order to
FIDONEWS 14-09 Page 18 3 Mar 1997

maintain a standard that can be followed by authors of different
gateway software packages, I suggest that the ^APTH line be converted
to one or more lines that start with the keyword FtnPth (For "Fidonet-
technology ^APTH line), with the @Domain address of the non-Fidonet-
technology network to which the message is being passed inserted as
the last entry in the list. For example, the following ^APTH line

^APTH: 3:711/431.5@Fidonet 431 403 1:124/4210 4115 114/5 15

... would be converted to the following ASCII text line in the message
as sent to the Internet:

FtnPth: 3:711/431.5@Fidonet 431 403 1:124/4210 4115 114/5 15
@Internet

If the receiving network has a line length limitation, then it may be
necessary to break the ^APTH line into multiple FtnPth lines.

If the message is later passed back into a Fidonet-technology network,
the gateway software should ideally be able to take the FtnPth
information and convert it back to proper ^APTH line syntax, adding
the name of the network that the message was received from if not the
same as the last network indicated in the FtnPth line(s). Of course,
if no FtnPth lines exist in message, then the gateway software should
ideally create one, showing the network that the message was received
from as the first entry in the ^APTH line.

If this is done correctly (and if non-Fidonet-technology networks can
be persuaded to leave the FtnPth lines intact), duplicate message
detection can be maintained even if a message passes through a non-
Fidonet network. In addition, those in the other network will have
access to information showing where the message originated, which
systems it passed through, and where it entered their network, which
can be a big help in tracking problem messages. Finally, this
information can be used to prevent undesirable message paths (for
example, a message that enters Fidonet from a non-Fidonet-technology
network and then is later sent back into that same network at a
different gateway point, thus causing a potential duplicate message in
the other network).

Please note that in the above examples, references to @Internet are
for example purposes only, and are not intended to specify the
"correct" domain name (in preference to "UseNet" or "UUCP", for
example). Determination of the "correct" domain name for non-Fidonet-
technology networks may be left to those who operate the domain
gateways.

Jack Decker
October 7, 1990

Change History:

Version 001: 04/01/90 - Original document
Version 002: 10/07/90 - Added support for Domains, and other minor
modifications to the text (mostly error correction).

FIDONEWS 14-09 Page 19 3 Mar 1997

[Jack Decker is still around and wishes me to include his greeting to
FidoNet and give his Internet address for anyone who wishes to say
hello or discuss his FSC. He may be reached at:

[email protected] or [email protected]

or his homepage at: http://www.novagate.com/~jack

He also recommends http://www.techknowtimes.com for tech types.] Ed.

-30-

-----------------------------------------------------------------

FIDONEWS 14-09 Page 20 3 Mar 1997

=================================================================
COORDINATORS CORNER
=================================================================

Nodelist-statistics as seen from Zone-2 for day 059
By Ward Dossche, 2:292/854
ZC/2

+----+------+------------+------------+------------+------------+--+
|Zone|Nl-031|Nodelist-038|Nodelist-045|Nodelist-052|Nodelist-059|%%|
+----+------+------------+------------+------------+------------+--+
| 1 | 9877| 9729 -148 | 9527 -202 | 9527 0 | 9405 -122 |34|
| 2 | 16078|16067 -11 |16074 7 |16051 -23 |16116 65 |57|
| 3 | 863| 863 0 | 846 -17 | 812 -34 | 807 -5 | 3|
| 4 | 550| 549 -1 | 538 -11 | 541 3 | 541 0 | 2|
| 5 | 87| 87 0 | 87 0 | 87 0 | 87 0 | 0|
| 6 | 1072| 1072 0 | 1071 -1 | 1071 0 | 1088 17 | 4|
+----+------+------------+------------+------------+------------+--+
| 28527|28367 -160 |28143 -224 |28089 -54 |28044 -45 |
+------+------------+------------+------------+------------+

-----------------------------------------------------------------

FIDONEWS 14-09 Page 21 3 Mar 1997

=================================================================
WE GET EMAIL
=================================================================

--- Following message extracted from NETMAIL @ 1:18/14 ---
By Christopher Baker on Sat Mar 01 19:57:39 1997

From: Christopher Baker @ 1:18/14
To: Bob Satti @ 1:1/0
Date: 01 Mar 97 19:54:10
Subj: looking for Internet links to FidoNet ops

CC: Bob Kohl, Martin Belcke, Dave Beach, Phillip Dampier
CC: Dave Miller, Marv Carson, B Becker, Dallas Hinton, Ken Tuley
CC: James Ray, Ward Dossche, David Nugent, Ariel Nardelli
CC: Henk Wolsink, Kazuyoshi Shinada, Bruce Bodger, Jason Steck
CC: Adrian Walker, Ed Georgen, Ken Wilson, Sid Balcom
CC: Marge Robbins, Brandon Carnahan, Brian Bonfietti, John Mudge
CC: Dave Anderson, Ben Hamilton, John Souvestre, George Peace
CC: Roy Timberman, Peter Witschi

in case you hadn't noticed, there is a new section in FidoNews that
lists FidoNet-related webpages and websites for Zones, Regions, and
Nets. these listings also appear on the official FidoNews webpage at:

http://ddi.digital.net/~cbaker84/fidonews.html

and at the FidoNews HTML page listed in the Masthead each week.

i would appreciate all ZCs and RCs passing this request down their
chain of command and to their ECs down the chain as well.

i would like to know about any and all FidoNet-related pages out
there. the only way i can get that info after little response to
FidoNews requests is to send you and your downlinks this Netmail.

for example, i have a listing for REC19 at ccove that no longer seems
to exist. REC19? did you drop or change your webpage?

Zones 4 and 5 don't have any links at all in the fidonet.org section.
ZC4 and ZC5, do you have webpages down and over there?

here is the current list as it appears in FidoNews:

This is a list of all FidoNet-related sites reported to the Editor as
of this appearance.

============

FidoNet:

Homepage http://www.fidonet.org
FidoNews http://ddi.digital.net/~cbaker84/fidonews.html
HTML FNews http://www.geocities.com/Athens/6894/
WWW sources http://www.scms.rgu.ac.uk/students/cs_yr94/lk/fido.html
FIDONEWS 14-09 Page 22 3 Mar 1997

FTSC page http://www2.blaze.net.au/ftsc.html
Echomail http://www.portal.ca/~awalker/index.html
WebRing http://ddi.digital.net/~cbaker84/fnetring.html

============

Zone 1: http://www.z1.fidonet.org

Region 10:
http://www.psnw.com/~net205/region10.html

http://www.dharmanet.org/BDO/net125.html

Region 15:
http://www.smrtsys.com/region15/

Region 16:
http://www.tiac.net/users/satins/region16.htm

http://www.tiac.net/users/satins/net330.htm

Region 17:
http://www.portal.ca/~awalker/region17.htm

Region 18:
http://www.citicom.com/fido.html

Region 19:
http://ccove.n-link.com/

============

Zone 2: http://www.z2.fidonet.org
ZEC2 http://fidoftp.paralex.co.uk/zec.htm

Region 25:
http://members.aol.com/Net254/

Region 29: http://www.rtfm.be/fidonet/ (in French)

Region 34: http://www.pobox.com/cnb/r34.htm (in Spanish)

Region 36: http://www.geocities.com/SiliconValley/7207/

============

Zone 3: http://www.z3.fidonet.org

============

Zone 4: (not yet listed)

============

Zone 5: (not yet listed)

FIDONEWS 14-09 Page 23 3 Mar 1997

============

Zone 6: http://www.z6.fidonet.org

============

-30-

would any of you care to add your Internet info for publication in
FidoNews and on the FidoNews webpage?

please pass this request along.

thanks.

QOFM.
Chris
FidoNews Editor [in case you've been out of touch for 8 months] [grin]

-30-

-----------------------------------------------------------------

FIDONEWS 14-09 Page 24 3 Mar 1997

=================================================================
NET HUMOR
=================================================================

From: "Mike Riddle" <[email protected]>
To: "Baker, Christopher" <[email protected] (Christopher Baker)>,
Date: Thu, 20 Feb 97 08:15:31 -0600
Reply-To: "Mike Riddle" <[email protected]>
Subject: From another list....

PC Humour

Q. What lizards like to sit on PCs?
A. Monitors.

Q. How do cold PC programmers feel?
A. IC.

Q. What do Wiccan computer experts ride in?
A. A hex bus.

Q. How do memory chip experts want their payment?
A. In cache.

Q. How do programmers write a debt notice?
A. I/O U.

Q. How did the Hunchback of Notre Dame surf the Net?
A. With a quasi-modem.

Q. How is Seagate like a rutted road?
A. They both make hard drives.

Q. What kind of lingerie do lady programmers like?
A. Softwear.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

United States of A-moo-rica's state of the week:

Moonesota

-30-

-----------------------------------------------------------------

FIDONEWS 14-09 Page 25 3 Mar 1997

=================================================================
NOTICES
=================================================================

Future History

17 May 1997
Independence Day, Norway.

25 May 1997
Independence Day, Argentina.

6 Jun 1997
National Commemoration Day, Sweden.

11 Jun 1997
Independence Day, Russia.

1 Jul 1997
Canada Day - Happy Birthday Canada.

13 Oct 1997
Thanksgiving Day, Canada.

1 Dec 1997
World AIDS Day.

10 Dec 1997
Nobel Day, Sweden.

12 Jan 1998
HAL 9000 is one year old today.

22 May 1998
Expo '98 World Exposition in Lisbon (Portugal) opens.

1 Dec 1998
Fifteenth Anniversary of release of Fido version 1 by
Tom Jennings.

31 Dec 1999
Hogmanay, Scotland. The New Year that can't be missed.

1 Jan 2000
The 20th Century, C.E., is still taking place thru 31 Dec.

15 Sep 2000
Sydney (Australia) Summer Olympiad opens.

1 Jan 2001
This is the actual start of the new millennium, C.E.

-- If YOU have something which you would like to see in this
Future History, please send a note to the FidoNews Editor.

-----------------------------------------------------------------
FIDONEWS 14-09 Page 26 3 Mar 1997

=================================================================
FIDONET SOFTWARE LISTING
=================================================================

Latest Greatest Software Versions
by Peter E. Popovich, 1:363/264

All right, I admit it. I've been slacking off. I didn't get anything
done this week. Sigh.

The good news is that the old info section is down to under 40
percent, so we're seeing some real progress there.

Phased out this week: "OS/2 Systems" Section

Phase-out highlights:
This week: "Amiga" Section
Deadline for info: 14 Mar 1997.
Last week: "Atari ST/TT" Section
Deadline for info: 7 Mar 1997.

-=- Snip -=-

Submission form for the Latest Greatest Software Versions column

OS Platform :
Software package name :
Version :
Function(s) - BBS, Mailer, Tosser, etc. :
Freeware / Shareware / Commercial? :
Author / Support staff contact name :
Author / Support staff contact node :
Magic name (at the above-listed node) :

Please include a sentence describing what the package does.

Please send updates and suggestions to: Peter Popovich, 1:363/264

-=- Snip -=-

MS-DOS:
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
Act-Up 4.6 G D Chris Gunn 1:15/55 ACT-UP
ALLFIX 4.40 T S Harald Harms 2:281/415 ALLFIX
Announcer 1.1 O S Peter Karlsson 2:206/221 ANNOUNCE
BGFAX 1.60 O S B.J. Guillot 1:106/400 BGFAX
Binkley Docs 2.60 M F Bob Juge 1:1/102 BDOC_260.ZIP
BinkleyTerm 2.60 M F Bob Juge 1:1/102 BDOS_260.ZIP
BinkleyTerm-XE XR4 M F Thomas Waldmann 2:2474/400 BTXE_DOS
CFRoute 0.92 O G C. Fernandez Sanz 2:341/70 CFR
CheckPnt 1.0 O G Michiel vd Vlist 2:500/9 CHECKPNT
FastEcho 1.45a T S Tobias Burchhardt 2:2448/400 FASTECHO
FastEcho/16 1.45a T S Tobias Burchhardt 2:2448/400 FE16
FidoBBS (tm) 12u B S Ray Brown 1:1/117 FILES
FIDONEWS 14-09 Page 27 3 Mar 1997

FrontDoor 2.12 M S JoHo 2:201/330 FD
FrontDoor 2.20c M C JoHo 2:201/330 FDINFO
GIGO 07-14-96 G S Jason Fesler 1:1/141 INFO
GoldED 2.50 O S Len Morgan 1:203/730 GED
GoldED Docs 2.50 O S Len Morgan 1:203/730 GEM
GoldNODE 2.50 O S Len Morgan 1:203/730 GEN
Imail 1.75 T S Michael McCabe 1:1/121 IMAIL
ImCrypt 1.04 O G Michiel vd Vlist 2:500/9 IMCRYPT
InfoMail 1.11 O F Damian Walker 2:2502/666 INFOMAIL
InfoMail/386 1.20 O F Damian Walker 2:2502/666 INFO386
InterEcho 1.19 T C Peter Stewart 1:369/35 IEDEMO
InterMail 2.29k M C Peter Stewart 1:369/35 IMDEMO
InterPCB 1.52 O S Peter Stewart 1:369/35 INTERPCB
IPNet 1.11 O S Michele Stewart 1:369/21 IPNET
JD's CBV 1.4 O S John Dailey 1:363/277 CBV
Jelly-Bean 1.01 T S Rowan Crowe 3:635/727 JELLY
Jelly-Bean/386 1.01 T S Rowan Crowe 3:635/727 JELLY386
JMail-Hudson 2.81 T S Jason Steck 1:285/424 JMAIL-H
JMail-Goldbase 2.81 T S Jason Steck 1:285/424 JMAIL-G
MakePl 1.9 N G Michiel vd Vlist 2:500/9 MAKEPL
Marena 1.1 beta O G Michiel vd Vlist 2:500/9 MARENA
Maximus 3.01 B P Tech 1:249/106 MAX
McMail 1.0 M S Michael McCabe 1:1/148 MCMAIL
MDNDP 1.18 N S Bill Doyle 1:388/7 MDNDP
Msged 4.10 O G Andrew Clarke 3:635/728 MSGED41D.ZIP
Msged/386 4.10 O G Andrew Clarke 3:635/728 MSGED41X.ZIP
Opus CBCS 1.73a B P Christopher Baker 1:374/14 OPUS
O/T-Track 2.63a O S Peter Hampf 2:241/1090 OT
PcMerge 2.7 N G Michiel vd Vlist 2:500/9 PCMERGE
PlatinumXpress 1.3 M C Gary Petersen 1:290/111 PX13TD.ZIP
QuickBBS 2.81 B S Ben Schollnick 1:2613/477 QUICKBBS
RAR 2.00 C S Ron Dwight 2:220/22 RAR
RemoteAccess 2.50 B S Mark Lewis 1:3634/12 RA
Silver Xpress
Door 5.4 O S Gary Petersen 1:290/111 FILES
Reader 4.4 O S Gary Petersen 1:290/111 SXR44.ZIP
Spitfire 3.51 B S Mike Weaver 1:3670/3 SPITFIRE
Squish 1.11 T P Tech 1:249/106 SQUISH
StealTag UK 1.c... O F Fred Schenk 2:284/412 STEAL_UK
StealTag NL 1.c... O F Fred Schenk 2:284/412 STEAL_NL
T-Mail 2.599I M S Ron Dwight 2:220/22 TMAIL
Terminate 4.00 O S Bo Bendtsen 2:254/261 TERMINATE
Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK
TriBBS 10.0 B S Patrick Driscoll 1:372/19 TRIBBS
TriDog 10.0 M S Patrick Driscoll 1:372/19 TRIDOG
TriToss 10.0 T S Patrick Driscoll 1:372/19 TRITOSS
WaterGate 0.92 G S Robert Szarka 1:320/42 WTRGATE
WWIV 4.24a B S Craig Dooley 1:376/126 WWIV
WWIVTOSS 1.36 T S Craig Dooley 1:376/126 WWIVTOSS
xMail 2.00 T S Thorsten Franke 2:2448/53 XMAIL
XRobot 3.01 O S JoHo 2:201/330 XRDOS

OS/2:
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
ALLFIX/2 1.10 T S Harald Harms 2:281/415 AFIXOS2
FIDONEWS 14-09 Page 28 3 Mar 1997

BGFAX 1.60 O S B.J. Guillot 1:106/400 BGFAX
Binkley Docs 2.60 M F Bob Juge 1:1/102 BDOC_260.ZIP
BinkleyTerm 2.60 M F Bob Juge 1:1/102 BOS2_260.ZIP
BinkleyTerm-XE XR4 M F Thomas Waldmann 2:2474/400 BTXE_OS2
CFRoute 0.92 O G C. Fernandez Sanz 2:341/70 CFR
FastEcho 1.45a T S Tobias Burchhardt 2:2448/400 FE2
FleetStreet 1.19 O S Michael Hohner 2:2490/2520 FLEET
GIGO 07-14-96 G S Jason Fesler 1:1/141 INFO
GoldED 2.50 O S Len Morgan 1:203/730 GEO
GoldED Docs 2.50 O S Len Morgan 1:203/730 GEM
GoldNODE 2.50 O S Len Morgan 1:203/730 GEN
ImCrypt 1.04 O G Michiel vd Vlist 2:500/9 IMCRYPT
Maximus 3.01 B P Tech 1:249/106 MAXP
Msged/2 4.10 O G Andrew Clarke 3:635/728 MSGED41O.ZIP
PcMerge 2.3 N G Michiel vd Vlist 2:500/9 PCMERGE
RAR 2.00 C S Ron Dwight 2:220/22 RAR2
Squish 1.11 T P Tech 1:249/106 SQUISHP
T-Mail 2.599I M S Ron Dwight 2:220/22 TMAIL2
Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK
XRobot 3.01 O S JoHo 2:201/330 XROS2

Windows (16-bit apps):
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
BeeMail 1.0 M C Andrius Cepaitis 2:470/1 BEEMAIL
FrontDoor APX 1.10 P S Mats Wallin 2:201/329 FDAPXW

Windows (32-bit apps):
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
BeeMail 1.0 M C Andrius Cepaitis 2:470/1 BEEMAIL
Binkley Docs 2.60 M F Bob Juge 1:1/102 BDOC_260.ZIP
BinkleyTerm 2.60 M F Bob Juge 1:1/102 BW32_260.ZIP
CFRoute 0.92 O G C. Fernandez Sanz 2:341/70 CFR
GoldED 2.50 O S Len Morgan 1:203/730 GEO
GoldED Docs 2.50 O S Len Morgan 1:203/730 GEM
Maximus 3.01 B P Tech 1:249/106 MAXN
Msged/NT 4.10 O G Andrew Clarke 3:635/728 MSGED41W.ZIP
PlatinumXpress 2.00 M C Gary Petersen 1:290/111 PXW-INFO
T-Mail 2.599I M S Ron Dwight 2:220/22 TMAILNT
WinFOSSIL/95 1.12 r4 F S Bryan Woodruff 1:343/294 WNFOSSIL.ZIP
WinFOSSIL/NT 1.0 beta F S Bryan Woodruff 1:343/294 NTFOSSIL.ZIP

Unix:
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
ifmail 2.9 M G Eugene Crosser 2:293/2219 IFMAIL
ifmail-tx ...tx7.9 M G Pablo Saratxaga 2:293/2219 IFMAILTX
Msged 4.00 O G Paul Edwards 3:711/934 MSGED
Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK

Amiga:
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
CrashMail 1.23 T X Fredrik Bennison 2:205/324 CRASHMAIL
CrashTick 1.1 O F Fredrik Bennison 2:205/324 CRASHTICK
FIDONEWS 14-09 Page 29 3 Mar 1997

DLG Pro BBOS 1.15 B C Holly Sullivan 1:202/720 DLGDEMO
GMS 1.1.85 M S Mirko Viviani 2:331/213 GMS
Msged 4.00 O G Paul Edwards 3:711/934 MSGED
Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK

Atari:
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
BinkleyTerm/ST 3.18pl1 M F Bill Scull 1:363/112 BINKLEY

Function: B-BBS, P-Point, M-Mailer, N-Nodelist, G-Gateway, T-Tosser,
C-Compression, F-Fossil, O-Other. Note: Multifunction will
be listed by the first match.

Cost: P-Free for personal use, F-Freeware, S-Shareware, C-Commercial,
X-Crippleware, D-Demoware, G-Free w/ Source

Old info from: 01/27/92
---------------------------------------------------------------------

MS-DOS Systems Other Utilities Other Utilities
-------------- Name Version Name Version
-------------------- --------------------
Network Mailers 2DAPoint 1.50* Netsex 2.00b
Name Version 4Dog/4DMatrix 1.18 OFFLINE 1.35
-------------------- ARCAsim 2.31 Oliver 1.0a
D'Bridge 1.30 ARCmail 3.00* OSIRIS CBIS 3.02
Dreamer 1.06 Areafix 1.20 PKInsert 7.10
Dutchie 2.90c ConfMail 4.00 PolyXarc 2.1a
Milqtoast 1.00 Crossnet 1.5 QM 1.00a
PreNM 1.48 DOMAIN 1.42 QSort 4.04
SEAdog 4.60 DEMM 1.06 RAD Plus 2.11
SEAmail 1.01 DGMM 1.06 Raid 1.00
TIMS 1.0(mod8) DOMAIN 1.42 RBBSMail 18.0
EEngine 0.32 ScanToss 1.28
Compression EMM 2.11* ScMail 1.00
Utilities EZPoint 2.1 ScEdit 1.12
Name Version FGroup 1.00 Sirius 1.0x
-------------------- FidoPCB 1.0s@ SLMail 2.15C
ARC 7.12 FNPGate 2.70 StarLink 1.01
ARJ 2.20 GateWorks 3.06e TagMail 2.41
LHA 2.13 GMail 2.05 TCOMMail 2.2
PAK 2.51 GMD 3.10 Telemail 1.5*
PKPak 3.61 GMM 1.21 TGroup 1.13
PKZip 1.10 GROUP 2.23 TIRES 3.11
GUS 1.40 TMail 1.21
NodeList Utilities Harvey's Robot 4.10 TosScan 1.00
Name Version HeadEdit 1.18 UFGATE 1.03
-------------------- HLIST 1.09 VPurge 4.09e
EditNL 4.00 ISIS 5.12@ WEdit 2.0@
FDND 1.10 Lola 1.01d WildMail 2.00
MakeNL 2.31 Mosaic 1.00b WMail 2.2
Parselst 1.33 MailBase 4.11a@ WNode 2.1
Prune 1.40 MSG 4.5* XRS 4.99
SysNL 3.14 MsgLnk 1.0c XST 2.3e
XlatList 2.90 MsgMstr 2.03a YUPPIE! 2.00
FIDONEWS 14-09 Page 30 3 Mar 1997

XlaxNode/Diff 2.53 MsgNum 4.16d ZmailH 1.25
MSGTOSS 1.3 ZSX 2.40

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

BBS Software Macintosh Other Software
Name Version --------- Name Version
-------------------- --------------------
FBBS 0.91 Network Mailers MacArd 0.04
Hermes 1.6.1 Name Version Mantissa 3.21
Mansion 7.15 -------------------- Mehitable 2.0
Precision Sys. 0.95b Copernicus 1.0 OriginatorII 2.0
Red Ryder Host 2.1 Tabby 2.2 PreStamp 3.2
Telefinder Host StuffIt Classic 1.6
2.12T10 Other Software SunDial 3.2
Name Version TExport 1.92
-------------------- TimeStamp 1.6
Point System ArcMac 1.3 TImport 1.92
Software AreaFix 1.6 Tset 1.3
Name Version Compact Pro 1.30 TSort 1.0
-------------------- EventMeister 1.0 UNZIP 1.02c
Copernicus 1.00 Export 3.21 Zenith 1.5
CounterPoint 1.09 Import 3.2 Zip Extract 0.10
MacWoof 1.1 LHARC 0.41

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Amiga Network Mailers Other Software
----- Name Version Name Version
-------------------- --------------------
BBS Software BinkleyTerm 1.00 Areafix 1.48
Name Version TrapDoor 1.80 AReceipt 1.5
-------------------- WelMat 0.44 ChameleonEdit 0.11
4D-BBS 1.65 ConfMail 1.12
Falcon CBCS 1.00 ElectricHerald 1.66
Starnet 1.0q@ Compression FFRS 1.0@
TransAmiga 1.07 Utilities FileMgr 2.08
XenoLink 1.0 Name Version Fozzle 1.0@
-------------------- Login 0.18
AmigArc 0.23 MessageFilter 1.52
NodeList Utilities booz 1.01 Message View 1.12
Name Version LHARC 1.30 oMMM 1.50
-------------------- LhA 1.10 PolyXAmy 2.02
ParseLst 1.66 LZ 1.92 RMB 1.30
Skyparse 2.30 PkAX 1.00 Roof 46.15
TrapList 1.40 UnZip 4.1 RoboWriter 1.02
Zippy (Unzip) 1.25 Rsh 4.07a
Zoo 2.01 Tick 0.75
TrapToss 1.20
|Contact: Maximilian Hantsch 2:310/6| Yuck! 2.02

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

BBS Software Atari ST/TT
Name Version -----------
--------------------
FIDONEWS 14-09 Page 31 3 Mar 1997

FIDOdoor/ST 2.5.1 Network Mailers Other Utilities
FiFo 2.1v Name Version Name Version
LED ST 1.00 -------------------- --------------------
QuickBBS/ST 1.06* The Box 1.95* ApplyList 1.00@
Burep 1.1
Compression ComScan 1.04
Utilities NodeList Utilities ConfMail 4.10
Name Version Name Version Echoscan 1.10
-------------------- -------------------- FDrenum 2.5.2
ARC 6.02 ParseList 1.30 FastPack 1.20
LHARC 2.01i EchoFix 1.20 Import 1.14
PackConvert sTICK/Hatch 5.50 oMMM 1.40
STZip 1.1* Pack 1.00
UnJARST 2.00 Trenum 0.10
WhatArc 2.02

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Key to old info:
+ - Netmail Capable (Doesn't Require Additional Mailer Software)
* - Recently Updated Version
@ - New Addition
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

Please send updates and suggestions to: Peter Popovich, 1:363/264

-----------------------------------------------------------------

FIDONEWS 14-09 Page 32 3 Mar 1997

=================================================================
FIDONEWS PUBLIC-KEY
=================================================================

[this must be copied out to a file starting at column 1 or
it won't process under PGP as a valid public-key]

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2
Comment: Clear-signing is Electronic Digital Authenticity!

mQCNAzINVLcAAAEEAM5dZN6t6j5Yc0kl7qegVFfiBeVoteuhDg4ay8h43u38Q4kO
eJ9Mm7J89wXFb9vgouBVb4biIN6bTWCwcXTbGhBe5OIceLvluuxuEKsaIs/UwXNe
Ogx5azIPhRfC7MJDe41Z8tMEBuHY/NE88cuxQ8yXWO126IRttavu6L/U5BwRAAUR
tCRGaWRvTmV3cyBFZGl0b3IgPDE6MS8yM0BmaWRvbmV0Lm9yZz6JAJUDBRAyGwFS
JZMgw7eCKz0BAZl0A/9xrfhpsEOqGiPfjy2qd9dv6tvSVPPVFu+Wy1lGTHYtuTtg
FIN3fQ47AM3XzqHxWRWvp/xZYgR6sRICL7UFx94ShYBQc7CyqBBZKA0IvIWqXP/g
c4Br+gQJR6CLiQK7TUyjUbqNbs6QAxuNUi4xFQM+O2Gene5/iTjHFmmSDj2C9YkB
FQMFEDIOmHDTQ6/52IG1SQEBQ78H/Rz/mleIrtZwFIOhzy3JH4Z6FUTfZuM9nPcs
1ZLjZCPptHvY7wEYJWGr03lPPJ6tj1VBXwTrWJTf/hOLsoi00GKV8t1thjqGDo23
O91/bSQ+Vn0vBQ2vOEJys8ftxdoLJAyI5YLzHVT+RsMTQLIXVuPyrNcKs1vC2ql+
UDHpU1R+9cG9JUEHpGI6z0DPnQ74SKbQH3fiVBpHhYx4BmvcBC4gWQzKMkDWFiq3
8AssIZ7b9lWl3OBgQ4UM1OIDKoJyjRewIdKyl7zboKSt6Qu8LrcsXO3kb81YshOW
ZpSS3QDIqfZC4+EElnB15l4RcVwnPHBaQY0FxUr4Vl4UWM36jbuJAJUDBRAyDpgY
q+7ov9TkHBEBAQGoA/sFfN07IFQcir456tJfBfB9R5Z6e6UKmexaFhWOsLHqbCq6
3FGXDLeivNn6NTz81QeqLIHglTuM3NP1mu8sw215klAG8G3M1NA2xLw7Eqhspze2
raGvNeEwxl8e+PY9aZwBj4UWU+CmIm6QNiP0MtvR7QYDIKn5mZCDc3CLmr942IkB
FQMFEDIOh0O8AhTPqRipPQEB4EYH/1gkDmdHL6lbEkFuQLrylF+weBl0XQ+kv7ER
vWXYrvIrkppxtc4VAge6CXXEbOGJnvkFHgyNZzO9Q9O64QsmZvjip+4lhDLeNrdH
X9DizS4YKXxkSKr9Yltmn2/AlBCx6jwcDIfkqy/P1tNWcikxZZMd6KryK0Wsres9
Ik12OmVmJjQSxb5bS6Q8aYUbV3qwosGXTqy+BzYh/UYAX/XJIWa5kxFVSPKFSZ+5
toiSzANd9SpHPEogGvQDHJlJ23lmsMx/6uHsR1LTsQ8su8zIk92XyqePJTjlMx2j
D7KJWNR7Zzu4QHCXBkga5W8l2FfPk7D3+o7bXTLRuR1yTYGdNoiJAJUCBRAyDhwt
SlKLwP4OFW0BAdaMA/9rcWQlSq44K9JuJ7fZUgt9fwxGreTud9fC8DvlbUW79+CA
AHLTLLagcEF1OKsWzVBWcA2JEAp+TUTqktRN0oD8vnaw3uNJd1G5KK59hw0WR8x1
v4ivypbSjiq95Y3gBunb7WjpyiFRWDlm0PrKrWHtbWzjnpPIpetln1UuqsSfbokB
FQIFEDIOG9C3N61ZQ4Dr/QEBIzMH/1VxxztmBPBszbjZLDO8Svcax9Ng8IcWpcDy
WqHCAA2Hoe5VtMD0v6w31ZgVqTPIvCark2Y/aTR1GofiuN9NUqbVV534AgAYLzYk
DMT1swsPvqDTpOYgQl6PCGh6A5JGAbWJfKkX9XCUHJAAmiTsEVRNnjOgL+p6qjoh
EfIG8CGehghWSRKl5eGeDAtbXupZKNjFI1t2XV+ks0RFQ/RPuTH7pF7pk7WO6Cyg
+Dk2ZMgua0HRL1fXvHKb5Xzr3MVgsbAl5gP8ooIiD9MI/x5Irh3oo58VyoEZNBs/
Kz+drGFDPljcS6fdiVCFtYIzMrshY6YsfLi0aB8fwOvFtxgBqli0J0NocmlzdG9w
aGVyIEJha2VyIDwxOjE4LzE0QGZpZG9uZXQub3JnPrQoQ2hyaXN0b3BoZXIgQmFr
ZXIgPGNiYWtlcjg0QGRpZ2l0YWwubmV0Pg==
=61OQ
-----END PGP PUBLIC KEY BLOCK-----

File-request FNEWSKEY from 1:1/23 [1:18/14] or download it from the
Rights On! BBS at 1-904-409-7040 anytime except 0100-0130 ET and Zone
1 ZMH at 1200-9600+ HST/V32B. The FidoNews key is also available on
the FidoNews homepage listed in the Masthead information.

-----------------------------------------------------------------
FIDONEWS 14-09 Page 33 3 Mar 1997

=================================================================
FIDONET BY INTERNET
=================================================================

This is a list of all FidoNet-related sites reported to the Editor as
of this appearance.

============

FidoNet:

Homepage http://www.fidonet.org
FidoNews http://ddi.digital.net/~cbaker84/fidonews.html
HTML FNews http://www.geocities.com/Athens/6894/
WWW sources http://www.scms.rgu.ac.uk/students/cs_yr94/lk/fido.html
FTSC page http://www2.blaze.net.au/ftsc.html
Echomail http://www.portal.ca/~awalker/index.html
WebRing http://ddi.digital.net/~cbaker84/fnetring.html

============

Zone 1: http://www.z1.fidonet.org

Region 10:
http://www.psnw.com/~net205/region10.html

http://www.dharmanet.org/BDO/net125.html

Region 15:
http://www.smrtsys.com/region15/

Region 16:
http://www.tiac.net/users/satins/region16.htm

http://www.tiac.net/users/satins/net330.htm

Region 17:
http://www.portal.ca/~awalker/region17.htm

Region 18:
http://www.citicom.com/fido.html

Region 19:
http://ccove.n-link.com/

============

Zone 2: http://www.z2.fidonet.org
ZEC2 http://fidoftp.paralex.co.uk/zec.htm

Region 25:
http://members.aol.com/Net254/

Region 29: http://www.rtfm.be/fidonet/ (in French)

Region 34: http://www.pobox.com/cnb/r34.htm (in Spanish)
FIDONEWS 14-09 Page 34 3 Mar 1997

Region 36: http://www.geocities.com/SiliconValley/7207/

============

Zone 3: http://www.z3.fidonet.org

============

Zone 4: (not yet listed)

============

Zone 5: (not yet listed)

============

Zone 6: http://www.z6.fidonet.org

============

-----------------------------------------------------------------

FIDONEWS 14-09 Page 35 3 Mar 1997

=================================================================
FIDONEWS INFORMATION
=================================================================

------- FIDONEWS MASTHEAD AND CONTACT INFORMATION -------

Editor: Christopher Baker

Editors Emeritii: Tom Jennings, Thom Henderson, Dale Lovell,
Vince Perriello, Tim Pozar, Sylvia Maxwell,
Donald Tees

"FidoNews Editor"
FidoNet 1:1/23
BBS 1-904-409-7040, 300/1200/2400/14400/V.32bis/HST(ds)

more addresses:
Christopher Baker -- 1:18/14, [email protected]
[email protected]
[email protected]

(Postal Service mailing address)
FidoNews Editor
P.O. Box 471
Edgewater, FL 32132-0471
U.S.A.

voice: 1-904-409-3040 [1400-2100 ET only, please]
[1800-0100 UTC/GMT]

------------------------------------------------------

FidoNews is published weekly by and for the members of the FIDONET
INTERNATIONAL AMATEUR ELECTRONIC MAIL system. It is a compilation
of individual articles contributed by their authors or their
authorized agents. The contribution of articles to this compilation
does not diminish the rights of the authors. OPINIONS EXPRESSED in
these articles ARE THOSE OF THE AUTHORS and not necessarily those of
FidoNews.

Authors retain copyright on individual works; otherwise FidoNews is
Copyright 1997 Christopher Baker. All rights reserved. Duplication
and/or distribution permitted for noncommercial purposes only. For
use in other circumstances, please contact the original authors, or
the Editor.

=*=*=*=*=*=*=*=*=

OBTAINING COPIES: The most recent issue of FidoNews in electronic
form may be obtained from the FidoNews Editor via manual download or
file-request, or from various sites in the FidoNet and Internet.
PRINTED COPIES may be obtained by sending SASE to the above postal
address. File-request FIDONEWS for the current Issue. File-request
FNEWS for the current month in one archive. Or file-request specific
back Issue filenames in distribution format [FNEWSEnn.ZIP] for a
FIDONEWS 14-09 Page 36 3 Mar 1997

particular Issue. Monthly Volumes are available as FNWSmmmy.ZIP
where mmm = three letter month [JAN - DEC] and y = last digit of the
current year [7], i.e., FNWSFEB7.ZIP for all the Issues from Feb 97.

Annual volumes are available as FNEWSn.ZIP where n = the Volume number
1 - 14 for 1984 - 1997, respectively. Annual Volume archives range in
size from 48K to 1.4M.

INTERNET USERS: FidoNews is available via:

http://www.fidonet.org/fidonews.htm
ftp://ftp.fidonet.org/pub/fidonet/fidonews/
ftp://ftp.aminet.org/pub/aminet/comm/fido/

*=*=*

You may obtain an email subscription to FidoNews by sending email to:

[email protected]

with a Subject line of: subscribe fnews-edist

and no message in the message body. To remove your name from the email
distribution use a Subject line of: unsubscribe fnews-edist with no
message to the same address above.

*=*=*

You can read the current FidoNews Issue in HTML format at:

http://www.geocities.com/Athens/6894/

STAR SOURCE for ALL Past Issues via FTP and file-request -
Available for FReq from 1:396/1 or by anonymous FTP from:

ftp://ftp.sstar.com/fidonet/fnews/

Each yearly archive also contains a listing of the Table-of-Contents
for that year's issues. The total set is currently about 11 Megs.

=*=*=*=

The current week's FidoNews and the FidoNews public-key are now also
available almost immediately after publication on the Editor's new
homepage on the World Wide Web at:

http://ddi.digital.net/~cbaker84/fidonews.html

There are also links there to jim barchuk's HTML FidoNews source and
to John Souvestre's FTP site for the archives. There is also an email
link for sending in an article as message text. Drop on over.

=*=*=*=*=*=*=*=*=

A PGP generated public-key is available for the FidoNews Editor from
FIDONEWS 14-09 Page 37 3 Mar 1997

1:1/23 [1:18/14] by file-request for FNEWSKEY or by download from
Rights On! BBS at 1-904-409-7040 as FIDONEWS.ASC in File Area 18. It
is also posted twice a month into the PKEY_DROP Echo available on the
Zone 1 Echomail Backbone.

*=*=*=*=*

SUBMISSIONS: You are encouraged to submit articles for publication in
FidoNews. Article submission requirements are contained in the file
ARTSPEC.DOC, available from the FidoNews Editor, or file-requestable
from 1:1/23 [1:18/14] as file "ARTSPEC.DOC". ALL Zone Coordinators
also have copies of ARTSPEC.DOC. Please read it.

"Fido", "FidoNet" and the dog-with-diskette are U.S. registered
trademarks of Tom Jennings, P.O. Box 410923, San Francisco, CA 94141,
and are used with permission.

"Disagreement is actually necessary,
or we'd all have to get in fights
or something to amuse ourselves
and create the requisite chaos."
-Tom Jennings

-30-

-----------------------------------------------------------------