FidoNews · Vol 14, No 15 · 14 April 1997
F I D O N E W S -- Volume 14, Number 15 14 April 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=> cbaker84@digital.net |
+----------------------------------------------------------------------+
| For information, copyrights, article submissions, |
| obtaining copies of FidoNews or the internet gateway FAQ |
| please refer to the end of this file. |
+----------------------------------------------------------------------+
WHERE IS THE IC?
Table of Contents
1. EDITORIAL ................................................ 1
No news is good news? .................................... 1
2. GETTING TECHNICAL ........................................ 2
FSC-0057 - Conference Managers - Request Specs ........... 2
FSC-0058 - New way of addressing in FidoNet .............. 11
3. COORDINATORS CORNER ...................................... 20
Nodelist-statistics as seen from Zone-2 for day 101 ...... 20
4. NOTICES .................................................. 21
Future History ........................................... 21
5. FIDONET SOFTWARE LISTING ................................. 22
Latest Greatest Software Versions ........................ 22
6. FIDONEWS PUBLIC-KEY ...................................... 27
FidoNews PGP public-key listing .......................... 27
7. FIDONET BY INTERNET ...................................... 28
8. FIDONEWS INFORMATION ..................................... 30
FIDONEWS 14-15 Page 1 14 Apr 1997
=================================================================
EDITORIAL
=================================================================
Everyone must be licking their cyberwounds this week since there are
no .ARTs or .LETs or .COLs this week. That leaves so much space for
clearing out these FSC docs. [grin]
Either that or everyone is perfectly happy in FidoNet. It's a FIRST!
Enjoy it while it lasts.
But what's happening in the International Coordinator election?
C.B.
-----------------------------------------------------------------
FIDONEWS 14-15 Page 2 14 Apr 1997
=================================================================
GETTING TECHNICAL
=================================================================
[This is part of the continuing FidoNet History series of technical
publications related to the ops of FidoNet. They have been
reformatted to 70 columns where required and any tables may be askew.
Node numbers and/or phone numbers may be outdated.] Ed.
Document: FSC-0057
Version: 003
Date: 07-Dec-92
Conference Managers - Specifications for Requests
December 7, 1992
Fabiano Fabris Joaquim H. Homrighausen
2:285/304.100@fidonet 2:270/17@fidonet
Status of this document:
This FSC suggests a proposed protocol for the FidoNet(r)
community, and requests discussion and suggestions for
improvements. Revision 3 presents several additions and
enhancements over the previous revision.
Distribution of this document is unlimited.
Fido and FidoNet are registered marks of Tom Jennings and Fido
Software.
1 Purpose
This document will explore the methods implemented by various
conference managers which process requests (in net mail form)
for changes to the conference mail links on the system on which
they are in use.
Until now, it would appear that no real standard exists, so
most software authors have either tried to emulate another
program, or to create a new method of their own, or both.
Here, an attempt will be made to define a standard, one which
tries to maintain compatibility with methods already in use,
while also extending them to provide new functions.
2 Conventions
The names of the commands described in the following paragraphs
are given in upper case, for legibility. However, a conference
manager should be able to interpret them even if they are given
in lower or mixed case.
FIDONEWS 14-15 Page 3 14 Apr 1997
Similarly, conference names, or tags, are given in upper case,
but the conference manager should be able to handle them even
if typed in lower or mixed case.
Optional information is enclosed with square brackets, while
variable information is enclosed with angle brackets. For
example:
+CONF [,R=<n>]
indicates that the section within square brackets is optional,
and if supplied, requires a parameter after the equals sign.
Some conference managers may allow commands to be abbreviated
to the shortest non-ambiguous string. For example, %LIST might
be reduced to %L.
3 Format of the request
A request to a conference manager is generally made in a net
mail message containing specific information in some of the
fields. In particular, the addressee is the name of the
conference manager itself, and the subject of the message is a
password assigned by the sysop of the system running the
program.
For example:
From: John Doe, on 2:123/56
To: Program, on 2:234/0
Subject: password
Here the first problem is encountered. Each of the existing
programs recognizes a different addressee. For this reason it
is proposed that all such programs recognize requests made to a
single, "standard" addressee, besides any other they may wish
to implement. The term "ConfMgr" has been arbitrarily chosen,
and should be used by those programs which adhere fully to all
the standards proposed in this document.
The text of the message itself contains the request proper, and
is the subject of the following paragraphs.
4 Linking and Unlinking of conferences.
The current methods for requesting that a conference be linked
are basically two:
+CONFNAME
CONFNAME
For reasons of uniformity, it is proposed that all conference
manager programs recognize the first method.
Requests that a conference be unlinked are given by:
FIDONEWS 14-15 Page 4 14 Apr 1997
-CONFNAME
It might be interesting to implement some form of pattern
matching, similar to the unix shell. The following basic
wildcards should be considered:
* matches zero or more characters
? matches any one (not zero) character
Since the requests are processed top-down, a request of the
form
+CONFNAME
-*
would be redundant, since the ConfMgr would link CONFNAME from
the first line, and then immediately unlink it again because of
the second line, which requests that all linked conferenecs be
unlinked.
It should also be possible to specify more than one conference
tag on the same line. For example:
+CONF1 CONF2 CONF3
would link the three conferences CONF1, CONF2 and CONF3.
5 Rescanning Conference Mail
Many conference managers currently allow a system to request
that an area be "rescanned". In other words, the system
receiving the request will export all mail in one or more areas
to the requesting system.
This may be accomplished by specifying the %RESCAN command in
the body of the request. This will force the ConfMgr to
generate a scan request for those areas which the remote system
requested with the message containing the %RESCAN command.
Rescans of a single area, newly linked, could be requested as
follows:
+CONFNAME, R[=<n>]
where 'n' is the number of messages in that area to be
rescanned. (The space following the comma is optional, but
allowed.)
Rescanning has one serious drawback: dupes! It is very possible
for the requesting system to have already set up the area with
several downlinks. Thus, when the rescanned mail is received,
it could be exported to other systems. In a tree-based
topology, this is harmless, but in circular topologies this
would create dupes.
Thus, it is proposed that system receiving the rescan request
FIDONEWS 14-15 Page 5 14 Apr 1997
add a kludge to the messages, so that they can be recognized by
the requesting system and not re-exported.
The proposed kludge is:
^ARESCANNED <addr>
where <addr> is the network address, including domain, of the
system from which the mail was rescanned.
In alternative to a rescan, a sysop might request a "sample",
consisting of a series of messages contained in a text file.
The ConfMgr would export some or all messages from an area to a
plain ASCII text file, and send it along with the reply, to the
requesting system. A "sample" request would be made as follows:
+CONFNAME, S[=<n>]
where 'n' indicates how many messages should be sampled.
a) Updating Conferences
Update requests allow a sysop to rescan or "sample" an area
without having to first unlink from it, and then relink with
the rescan or "sample" parameter.
The format of this command is:
=CONFNAME, <param>[=<n>]
Thus a rescan request for the most recent 50 messages would
be specified as:
=CONFNAME, R=50
6 Information Requests
Requests for information have until now taken two forms. In one
case, they are given as switches after the password on the
subject line, while in the second they are given as "commands"
within the body of the message text. It is proposed that the
second method be chosen as standard, since it is considerably
more flexible.
Below are listed the proposed commands:
%HELP Sends a (pre-defined) help text to
the requesting system, explaining
how the ConfMgr is to be used.
%LIST[,B] Lists the conferences currently
available to the requesting system,
on the basis of a method internal to
the conference manager itself. This
list would flag the areas which are
already linked. The 'B' modifier
FIDONEWS 14-15 Page 6 14 Apr 1997
would generate the list in
binary format (see section 8e).
%BLIST Equivalent to %LIST,B above.
%QUERY Lists the conferences currently
linked to the requesting system.
%UNLINKED Lists the conferences which are
available to the requesting system,
but not currently linked. This is
the logical difference between a
%LIST and a %QUERY.
7 Remote Maintenance
Besides these simple functions, it is becoming more and more
interesting to make handling of the conference mail flow even
more automatic. For this reason, for example, it might be
useful to allow another sysop control over your own system,
adding and removing conferences as need requires. Thus a hub or
coordinator could automatically have a new area added to their
conference lists, or discontinued ones removed.
Naturally, the ConfMgr must be able to distinguish which system
has the ability to make such changes, but that is beyond the
scope of this document.
It is proposed that a conference manager be able to
automatically add a new conference to the system's list if/when
it is detected. Thus no special commands would be required.
The manager should be able to determine a default list of down-
links for the new area, and also the "group" of systems which
could then request it.
However, should it be desired to explicitly create a new
conference via remote, this could be done by including a line
such as the following in the message text:
&CONFNAME
In order to remote delete an area, the requesting sysop should
include a line like this in the body of the message text:
~CONFNAME
Thus, if the system has remote privileges, the conference would
be deleted (and optionally, all systems linked to the
conference could be informed of this fact).
Similarly, it would also be possible to allow a system to
change the tag of a conference. This would be accomplished by a
line such as:
# OLD_NAME NEW_NAME
FIDONEWS 14-15 Page 7 14 Apr 1997
The ConfMgr should inform all downlinks of the change by
sending a net mail message.
It might also be desirable to allow a sysop to make changes on
behalf of another system. This could be done by inserting a
special command at the beginning of the request itself. For
example:
From: John Doe, on 2:123/1
To: Program, on 2:987/65
Subject: password
Text:
%FROM: 2:234/56
+CONFNAME
The %FROM command would make the ConfMgr carry out the changes
as if the system 2:234/56 had requested them. The password
should nonetheless be the one assigned to 2:123/1.
8 Further Automation
In order to make the system more powerful, and to reduce the
necessity for human intervention, several extensions are
feasible.
a) ARCmail Compression Method
One interesting application is the possibility of allowing a
remote system to change the compression program used to
"pack" mail bound for his system. This could be done with
the following command in the message to a ConfMgr:
%COMPRESS <method>
where <method> is one of the compression programs supported
by the system. Of course, the remote system should also be
able to determine which compression methods are available;
this could be done with
%COMPRESS ?
Requests for an unsupported compression method should also
be responded to with a list of those available.
From the practical point of view, only systems which pick up
their mail (as opposed to those to whom mail is sent) should
be allowed to change the compression method used. How this
distinction is achieved is beyond the scope of this
document.
b) Passwords
A sysop should be able to change the password used to make
requests to a ConfMgr without requiring the intervention of
the other system's sysop. This could easily be done if the
conference manager implemented the following command:
FIDONEWS 14-15 Page 8 14 Apr 1997
%PWD <new_password>
The new password (case insensitive) would replace the
current one as of the next request.
c) Temporary Unlink
Should a system's sysop be absent for a prolonged period of
time, he might want to temporarily cut all conferences from
his uplink. This could be accomplished with the
%PAUSE
command. This would tell the ConfMgr to temporarily stop
sending conferences to that system. On his return, the
sysop could reactivate them all with the
%RESUME
command.
d) Forwarding Remote Requests
If a conference manager receives a remote request to delete
an area, it could very easily "forward" that request to all
its downlinks by producing a similar request. In that way,
a single request originating from, for example, a Region
Coordinator, would result in the conference being deleted
from all systems "below" him.
Similarly, remote requests for conference name changes could
also be passed on to downlinks.
e) Automatic Requests for Conferences
A conference manager should also be able to automatically
request an area from an uplink. This would become necessary
if, for example, it processed a request for an area not
currently available on the system. In this case, it would
scan a series of conference lists for the requested area,
and if found, would send a request for that area.
In order to be able to do this, the ConfMgr would need to
have one or more lists of conferences from the uplinks.
These lists could be produced on request by the ConfMgr
itself. In order to simplify matters, a binary format is
proposed. (Note that these are C-style structures, with
everything which that implies.) This binary file is called a
Binary Conference List (BCL).
The file starts with a header, containing some basic system
information:
struct bcl_header {
char FingerPrint[4]; /* BCL<NUL> */
char ConfMgrName[31]; /* Name of "ConfMgr" */
FIDONEWS 14-15 Page 9 14 Apr 1997
char Origin[51]; /* Originating network addr
*/
long CreationTime; /* UNIX-timestamp when
created */
long flags; /* Options, see below */
char Reserved[256]; /* Reserved data */
}
The currently defined flags for the header are:
BCLH_ISLIST 0x00000001L
File is complete list
BCLH_ISUPDATE 0x00000002L
File contains update/diff information
The BCL would then contain a series of entries having the
following format:
struct bcl {
int EntryLength; /* Length of entry data */
long flags1, flags2; /* Conference flags */
char *AreaTag; /* Area tag [51] */
char *Description; /* Description [51] */
char *Administrator; /* Administrator or contact
[51] */ }
The flags currently defined are:
FLG1_READONLY 0x00000001L
Read only, software must not allow users to enter
mail.
FLG1_PRIVATE 0x00000002L
Private attribute of messages is honored.
FLG1_FILECONF 0x00000004L
File conference.
FLG1_MAILCONF 0x00000008L
Mail conference.
FLG1_REMOVE 0x00000010L
Remove specified conference from list (otherwise
add/upd).
Thus, instead of scanning an AREAS.BBS style list, the
ConfMgr would parse and use lists in the above format.
Naturally, each list would be in some way "attached" to a
node number, and a corresponding ConfMgr password.
Each system may only have one master file, called anything
they want. But when transmitted to other systems, this file
must always be named ????????.BCL.
The list would be generated in response to a
FIDONEWS 14-15 Page 10 14 Apr 1997
%LIST, B
command in the message text.
f) Receipts
It might be useful to have the ConfMgr generate a receipt to
be sent to another system, perhaps a co-sysop or a sysop
point node. This could be done with the command:
%RECEIPT <name>,<address>
embedded in the request message. For example:
%RECEIPT JoHo,2:270/17
9 Comments in the request
It should be possible for a sysop to insert a comment in the
request made to a conference manager. These comments,
naturally, would be destined to the sysop of the system, and
not to the conference manager itself. Such comments should be
placed at the end of the message, following a %NOTE command.
In all cases except the above, the request can be deleted by
the ConfMgr once processed, but messages containing comments
should be retained.
Note: the current method used is to supply comments after a
tear-line. This practice is somewhat "messy", but it might be
wise to support it until such time as all conference managers
have implemented the %NOTE command.
10 Summary
+CONFNAME[,R|S] Request to link to CONFNAME
-CONFNAME Request to unlink from CONFNAME
=CONFNAME,R|S Rescan or "sample" linked conference
&CONFNAME Request to create CONFNAME
~CONFNAME Request to delete CONFNAME
#OLD NEW Name change request
%LIST[,B] List available areas, flag linked
%QUERY Only list linked areas
%UNLINKED List available but unlinked areas
%HELP Send help text
%FROM <addr> Simulate request from another system
%RESCAN Rescan conferences linked in current
request
%COMPRESS <method> Change compression method
%PWD <new_pwd> Change ConfMgr password
%PAUSE Suspend link
%RESUME Resume link
%RECEIPT <name>,<addr> Send copy of receipt to another system
%NOTE Introduces comment to the sysop
FIDONEWS 14-15 Page 11 14 Apr 1997
11 Final Note
This document is to be considered as a suggestion for software
developers to make their programs compatible with one another,
so as to make life easier for the average sysop when dealing
with conference managers.
Feedback would be appreciated and can be sent to us at the
addresses specified on the title page. Please send feedback via
netmail only.
-30-
-----------------------------------------------------------------
Document: FSC-0058
Version: 002
Date: 01-Nov-1992
A New Way Of Addressing In FidoNet(r)
Wim Van Sebroeck & Jan Spooren
November 1st, 1992
This document replaces the now obsolete version 001
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 unlimited.
Fido and FidoNet are registered trademarks of Tom Jennings and
Fido Software.
A. Why a new Proposal :
------------------------
FidoNet has grown from a few single BBSs to a worldwide network of
nodes. Because of that enormous growth, we have several kludge-lines
just to write to someone else. And for every extra dimension a new
kludge is necessary. (3D: ^AINTL ; 4D: ^AFMPT, ^ATOPT ; 5D:
^ADOMAIN). Every time a new dimension or addressing-system is
invented, not only the packer/router software needs to be adjusted,
but also the message editor and a whole series of other utilities,
being virtually the whole FidoNet software.
This is why we made this proposal:
1) to make life easier for programmers and developers.
2) to have a system that will have no problems with further backward-
compatibility. (from this system on)
3) to have a system that is simple (in usage).
4) and to have a system that accepts every possible address.
FIDONEWS 14-15 Page 12 14 Apr 1997
B. Proposal :
--------------
To send a message one needs two things: the origin address and the
destination address. (And for routing inter-domain messages you also
need the address of the gateway). Until now, we needed four different
kludge-lines when we wanted to send a message to another domain
(^ADOMAIN, ^AINTL, ^AFMPT, ^ATOPT). To minimize these kludges we
suggest the following:
^ADEST <dest_address>
^AORIG <orig_address>
^AROUTE <route_via_address>
These kludges are *not* followed by a colon (':').
1) The ^ADEST kludge: this kludge contains the address where the
message has to be sent to. In other words: it contains the
destination address. <dest_address> is an ASCII string that may
contain any readable character, (above and including 32 (space) and
below ASCII 128), and is only terminated by the end-CR of the
kludge-line. It is up to the mailprocessors of every domain
(FidoNet compatible or not) if they regard the address as case-
sensitive or not.
The FORMAT of <dest_address> is :
<Address>[@<Domain>]
Where <Address> is the valid username/address in the network
<Domain>, and <Domain> cannot have any '@' of '/'-characters in it,
while <Address> can. The reason why '/' characters are not allowed
in the <Domain>-field, is because they are necessary to recognize a
FidoNet-style address, since <Domain> is optional for messages that
won't be crossing domain- borders. (*)
In other words: The domain is always the string behind the last @
sign in the <dest_address> field, except when domain would contain
a '/'-character. In that case, <Domain> is the default domain, and
<Address> is the complete string behind the DEST-kludge.
Concerning FidoNet-compatible addresses, there are some extra
rules, since FidoNet is one of these rare networks that haven't got
the username in the address.
A valid FidoNet <Address> is made up like this:
<Username>@<Fido_Address>
Where <Username>@ is mandatory and <Fido_Address> is a valid
fidonet address. The FidoNet-address must contain at least the
zone:net/node number. Point number is optional.
Eg.: ^ADEST Wim Van Sebroeck@2:292/862.0@FidoNet.Org
will generate an outbound message for user 'Wim Van Sebroeck' at
Fido-node 2:292/862.0 within FidoNet. The domain name for FidoNet
FIDONEWS 14-15 Page 13 14 Apr 1997
is 'FidoNet.Org', and *not* just Fido, or FidoNet or whatever. This
is not a waste of space, since the domain name can be omitted when
the message remains in the default network. Only for messages
crossing domain borders, the domain name is necessary. We opted for
the '.org' and '.ftn' suffixes, in order to make interfacing to
InterNet easier.
Some more addressing-examples:
^ADEST Jan Spooren@2:292/852.0@Fidonet.Org
^ADEST 292/862-cosysops@2:292/850
^ADEST TE880714%BANUFS11@BITNET
^ADEST Jack@OS/2.dev.itnet@itnet
^ADEST m2xenix!uunet!BANUFS11.BITNET!TE880714@uucp
The first example should be clear, since it will be the most
frequently used addressing-style. The 4th example shows the kludge
for a message to the address 'Jack@OS/2.dev.itnet', within domain
'itnet'. There is no problem whatsoever with the '/' character,
because it is part of the <Address>, and not of the <Domain>.
In the last example, the message has to be sent to the uucp-
gateway, wich will send it on within the internet-network, with the
destination-address: 'm2xenix!uunet!BANUFS.11BITNET!TE880714'
Also this is a valid address:
^ADEST Wim Van Sebroeck@2:292/862.0@FidoNet.Org@SIGnet.ftn
The message will be sent to 2:292/862.0@FidoNet.Org, within
SIGnet.ftn. SIGnet will then send the message back to 2:292/862.0
in FidoNet. The message will cross the domain-borders twice. Apart
from the fact that it may seem an annoying practice, technically
the address is 100% OK.
Information in the DEST-kludge will always override information in
the FTS-0001 message header.
FOOTNOTE:
(*)
For a proper understanding of this '/'-restriction, let's
illustrate this by means of an example. If we send a message with a
kludge like this:
^ADEST Wim Van Sebroeck@2:292/862
Then the mailprocessor could wrongly interpret the <dest_address>:
It could decide the <address> to be 'Wim Van Sebroeck' in <domain>
'2:292/862'. But with the '/'-restriction it is now clear that the
address is 'Wim Van Sebroeck@2:292/862' in the default domain.
2) The ^AORIG kludge: this kludge contains the origin address.
<orig_address> has the same restrictions as the <dest_address>.
For example: ^AORIG Wim Van Sebroeck@2:292/862.0@Fidonet.Org
FIDONEWS 14-15 Page 14 14 Apr 1997
or: ^AORIG Infomag.Dev@ITNet
3) The ^AROUTE kludge: this is needed to point to the gateway address,
when sending a message to another domain. Since not all gateways
are listed in the nodelist and because possibly not all
intermediate systems are aware of a particular domain-name, it is
necessary to add the address of the gateway. The gateway is a
system within the default domain, that can send the message to the
desired domain. The kludge can also be used, however, to point to a
zonegate between different zones in one domain. In any case, for
every domain-border that will be crossed, there needs to be one
ROUTE-kludge to indicate the gateway. It should be obvious, that a
FidoNet-address in a ROUTE-kludge never carries a username.
The ROUTE-kludge always overrides the DEST-kludge. A system
receiving a message should ALWAYS send the message to the address
specified by the ROUTE-kludge, and NOT to the destination address.
In other words, the ROUTE-kludge is not to be interpreted as a hint
to a possible gateway, but must be regarded as a new destination
address, and the message will always have to reach the gateway. The
gateway will then change the ^AROUTE to a ^AROUTD kludge, in order
to indicate that the gateway received the message, and to see to it
that the message won't travel back to the gateway. This absolute
priority of the ROUTE-kludge above the DEST-kludge is necessary,
since otherwise messages could be bouncing between two nodes that
both prefer different gateways to send the message to. The ROUTE-
kludge also has nothing to do with the actual routing itself. The
ROUTE-kludge only defines an intermediate address that has to be
reached before the message reaches its final destination. How the
message gets to this intermediate address doesn't matter: it may be
direct or it may be routed through other systems. Remember that
FidoNet is an amateur network, with each system paying its own
phone bills!
For example: ^AORIG Wim Van Sebroeck@2:292/862.0@Fidonet.Org
^AROUTE 1:105/42.0@Fidonet.Org
^ADEST m2xenix!uunet!BANUFS11.BITNET!TE880714@uucp
C. Advantages and Disadvantages :
---------------------------------
a) Advantages:
- The main advantage is that one only needs two kludges to
specify the origin and the destination address. (And that these
kludges are always in a message).
- The system is also very flexible because any address is
possible.
- Utilities must not be updated when a new address-dimension is
created. - Inter-domain and inter-network messages are finally
possible.
- No limits are placed on both username and address-field length.
- Perfect compatibility is ensured with future message and packet
formats that will override FTS-0001.
b) Disadvantages:
- Please be so kind to write them to us. We can't figure what
FIDONEWS 14-15 Page 15 14 Apr 1997
they could be?
D. Implementation Notes :
--------------------------
D.1. Processing an outgoing message.
.-----+----------+-------------------------+-------------------------
+-----.
|State| State | Predicate(s) | Action(s) |
Next|
| # | Name | | |
St | |-----+----------+-------------------------+--------------------
-----+-----|
| O1 | MsgFound | Find DEST/ROUTE | 1 Found fsc-58 kludge |
O2 |
| | | kludges in message | 2 Fsc-58 kludge not fnd |
S8 |
| | | | 3 Error occured |
exit|
| | | | 4 Dest is 1 of our AKAs |
exit| |-----+----------+-------------------------+--------------------
-----+-----|
| O2 | ReadKldg | | Take only 1st ROUTE and |
O3 |
| | | | 1st DEST-kludge |
| |-----+----------+-------------------------+------------------------
-+-----|
| O3 | ChkROUTE | Is there a ROUTE kludge | 1 Route kludge found |
O4 |
| | | | 2 No route kludge |
O10 | |-----+----------+-------------------------+--------------------
-----+-----|
| O4 | WeRoute? | Is ROUTE one of our | 1 Yes |
O5 |
| | | AKA's | 2 No |
O9 | |-----+----------+-------------------------+--------------------
-----+-----|
| O5 | DsblROUT | | Change ROUTE into ROUTD |
O6 |
| | | | and strip 'TOPT' and |
|
| | | | 'INTL'-kludges to our |
|
| | | | system. |
| |-----+----------+-------------------------+------------------------
-+-----|
| O6 | WeGate? | Are we a gateway to | 1 Yes |
O7 |
| | | another domain? | 2 No |
O2 | |-----+----------+-------------------------+--------------------
-----+-----|
| O7 | Needgate | Get next ROUTE/DEST-kldg| 1 Yes |
O8 |
| | | Is it another domain? | 2 No |
O3 | |-----+----------+-------------------------+--------------------
FIDONEWS 14-15 Page 16 14 Apr 1997
-----+-----|
| O8 | Gateway | | Do gatewaying-stuff |
exit|
| | | | Don't forget to strip |
|
| | | | @<domain> from the |
|
| | | | <dest_address> |
| |-----+----------+-------------------------+------------------------
-+-----|
| O9 | SndROUTE | | SendMsg to ROUTE |
S1 |
| | | | (Temp. Dest = ROUTE) |
| |-----+----------+-------------------------+------------------------
-+-----|
| O10 | SndDEST | | SendMsg to DEST |
S1 |
| | | | (Temp. Dest = DEST) |
| `-----+----------+-------------------------+------------------------
-+-----'
D.2. Sending of an outgoing message
SendMsg(Temporary_destination)
.-----+----------+-------------------------+-------------------------
+-----.
|State| State | Predicate(s) | Action(s) |
Next|
| # | Name | | |
St | |-----+----------+-------------------------+--------------------
-----+-----|
| S1 | Looktabl | | Find node to route to |
S2 |
| | | | according to own routng |
|
| | | | scheme and msg-attribs. |
| |-----+----------+-------------------------+------------------------
-+-----|
| S2 | IsFsc58 | Lookup in table if node | 1 No, not fsc-58 compl. |
S3 |
| | | is fsc-58 compliant | 2 YES! Fsc-58 compliant |
S8 | |-----+----------+-------------------------+--------------------
-----+-----|
| S3 | FMPT | Has ORIG-kludge point# | 1 No |
S4 |
| | | | 2 Yes: Insert FMPT-kldg |
|
| | | | if not already present|
| |-----+----------+-------------------------+------------------------
-+-----|
| S4 | TOPT | Contains | 1 No |
S5 |
| | | temporary_destination | 2 Yes: Insert TOPT-kldg |
|
| | | a point-address ? | if not already present|
FIDONEWS 14-15 Page 17 14 Apr 1997
| |-----+----------+-------------------------+------------------------
-+-----|
| S5 | INTL | Compare ORIG and | 1 Zones equal |
S6 |
| | | temporary_destination | 2 Not eq. : Make INTL-k |
|
| | | | if not already present|
| |-----+----------+-------------------------+------------------------
-+-----|
| S6 | DOMAIN | Compare ORIG and | 1 Domains equal |
S7 |
| | | temporary_destination | 2 Not eq. : Domain-kldg |
|
| | | | if not already present|
| |-----+----------+-------------------------+------------------------
-+-----|
| S7 | Usernames| | Fill in FTS-1 dest and |
S8 |
| | | | orig usernames, accord. |
|
| | | | to ORIG and DEST except |
|
| | | | when ORIG/D names blank |
| |-----+----------+-------------------------+------------------------
-+-----|
| S8 | XportMsg | | Export message |
Exit| `-----+----------+-------------------------+--------------------
-----+-----'
D.3. Processing an incoming message:
.-----+----------+-------------------------+-------------------------
+-----.
| I1 | ChkKldg | Find DEST/ROUTE/ORIG | If found: store kludges |
I2 |
| | | kludges in message | |
| |-----+----------+-------------------------+------------------------
-+-----|
| I2 | ChkFSC58 | Are DEST/ROUTE/ORIG | 1 Yes, fsc-58 compliant |
I3 |
| | | Kludges available? | 2 No, not fsc-58 compl. |
I4 | |-----+----------+-------------------------+--------------------
-----+-----|
| I3 | ChkTable | Is originator of packet | If not in lookup-table |
I4 |
| | | in lookup-table? ^^^^^^ | and should be, then |
|
| | | ( SEE SECTION E !) | add node to the table |
| |-----+----------+-------------------------+------------------------
-+-----|
| I4 | ChkDEST | Is message to us? | 1 Yes: store message |
exit|
| | | (Are we DEST?) | 2 No |
I5 | |-----+----------+-------------------------+--------------------
-----+-----|
| I5 | KeepTrans| Do we keep a copy of in-| 1 Yes: Store msg and -->|
FIDONEWS 14-15 Page 18 14 Apr 1997
O1 |
| | | transit mail ? :-( | 2 No: |
O1 | `-----+----------+-------------------------+--------------------
-----+-----'
E. Discussion of the Implementation Notes.
------------------------------------------
* O5, "DsblROUT" :
It is clear that when a message travels through an intermediate
system which is mentioned in a ROUTE-kludge, this ROUTE-kludge will
have to be removed, because the message did arrive at this system.
Instead of just deleting the whole kludge-line, the kludge will be
changed in ROUTD. This is a much easier and faster process for a
mailprocessor and it enables the recipient of the message to have
some information about the route the message took.
Because there is no FTS-0001 equivalent to the route-kludge, a
system that is in a route-kludge needs to be FSC-0058 compliant.
The intermediate systems to this ROUTE-system need not to be FSC-
0058 compliant: Our implementation notes assume a list of fsc-0058
compliant nodes (the 'lookup table'), that is continuously updated,
when messages arrive from fsc-0058 systems. When a message is to be
send on to a non-fsc-0058 system, the message will be converted to
the old FTS-0001 format, including FMPT-, TOPT- and INTL-kludges.
The destination-address in this (converted) message will then be the
address of the first ROUTE-kludge.
There is one tricky point: When such a message arrives at this
ROUTE-system, the message can have TOPT (if the system is a
pointsystem) and INTL kludges in the messagebody, due to the
conversion to the FTS-0001 format. The ROUTE-system's mailprocessor
will have to find these and strip them from the message.
* S3 -> S7 :
These stages perform the conversion to FTS-0001 format, in case the
next receiving system will be non-fsc-0058 compliant.
* I3, "ChkTable" :
Care must be exercized: If we find FTS-0058 information in a
message we don't know if the last system, or any of the previous
systems the message passed is fsc-0058 compliant. We can only know
for sure when the message was sent directly to us. That is (in
FidoNet packet type 2) when the packet-orig address is the same as
the message orig-address, or when the packet-orig address is the
same as the last routd-kludge address.
We are aware of the fact that the lookup-table won't be filled fast
this way. But we don't want that: We only have to know if our
'surrounding' nodes, i.e., the nodes with which we have frequent
connections, support fsc-0058. We also want to know if gateway
systems are fsc-0058 compliant, because we have to put them in a
ROUTE-kludge. But these should be just a few systems and the fact
FIDONEWS 14-15 Page 19 14 Apr 1997
of their fsc-0058 compliance will be known easily. They can then be
added manually.
We do not even dare to suggest the use of a nodelist-flag, that
could simplify this whole system of investigating the fsc-0058
compliance, in order to downgrade to the FTS-0001 level for non-
compliant systems.
F. Questions :
---------------
Questions can always be sent to:
Jan Spooren 2:292/852.0@Fidonet.Org
Wim Van Sebroeck 2:292/862.0@Fidonet.Org
--- End Of Proposal ---
-30-
-----------------------------------------------------------------
FIDONEWS 14-15 Page 20 14 Apr 1997
=================================================================
COORDINATORS CORNER
=================================================================
Nodelist-statistics as seen from Zone-2 for day 101
By Ward Dossche, 2:292/854
ZC/2
+----+------+------------+------------+------------+------------+--+
|Zone|Nl-073|Nodelist-080|Nodelist-087|Nodelist-094|Nodelist-101|%%|
+----+------+------------+------------+------------+------------+--+
| 1 | 9107| 9088 -19 | 9088 0 | 8900 -188 | 8837 -63 |32|
| 2 | 15996|15956 -40 |15923 -33 |15922 -1 |15902 -20 |58|
| 3 | 800| 800 0 | 800 0 | 800 0 | 800 0 | 3|
| 4 | 547| 548 1 | 548 0 | 549 1 | 548 -1 | 2|
| 5 | 87| 87 0 | 87 0 | 87 0 | 87 0 | 0|
| 6 | 1088| 1088 0 | 1090 2 | 1090 0 | 1083 -7 | 4|
+----+------+------------+------------+------------+------------+--+
| 27625|27567 -58 |27536 -31 |27348 -188 |27257 -91 |
+------+------------+------------+------------+------------+
-----------------------------------------------------------------
FIDONEWS 14-15 Page 21 14 Apr 1997
=================================================================
NOTICES
=================================================================
Future History
17 May 1997
Independence Day, Norway.
6 Jun 1997
National Commemoration Day, Sweden.
12 Jun 1997
Independence Day, Russia.
1 Jul 1997
Canada Day - Happy Birthday Canada.
9 Jul 1997
Independence Day, Argentina.
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-15 Page 22 14 Apr 1997
=================================================================
FIDONET SOFTWARE LISTING
=================================================================
[reprinted from FidoNews 1414] Ed.
Latest Greatest Software Versions
by Peter E. Popovich, 1:363/264
Well, I'm catching back up. Still waiting to hear about Gecho, though.
Note: At the end of April, I'll be phasing out the old Macintosh
section. As always, I'll be happy to process any information I get,
either before or after it is phased out.
-=- 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.11 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.0a 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
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
FIDONEWS 14-15 Page 23 14 Apr 1997
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.8 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 11.0 B S Gary Price 1:3607/26 TRIBBS
TriDog 11.0 T F Gary Price 1:3607/26 TRIDOG
TriToss 11.0 T S Gary Price 1:3607/26 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
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
FIDONEWS 14-15 Page 24 14 Apr 1997
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 ...tx8.1 M G Pablo Saratxaga 2:293/2219 IFMAILTX
ifmail-tx.rpm ...tx8.1 M G Pablo Saratxaga 2:293/2219 IFMAILTX.RPM
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
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
FIDONEWS 14-15 Page 25 14 Apr 1997
TrapDoor 1.86.b2 M S Maximilian Hantsch
2:310/6 TRAPDOOR
TrapDoor 1.86.b2 M S Maximilian Hantsch
2:310/6 TRAPBETA
TrapToss 1.50 T S Rene Hexel 2:310/6 TRAPTOSS
Atari:
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
BinkleyTerm/ST 3.18pl1 M F Bill Scull 1:363/112 BINKLEY
Semper 0.80beta M S Jan Kriesten 2:2490/1624 SMP-BETA
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
FIDONEWS 14-15 Page 26 14 Apr 1997
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
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
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
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-15 Page 27 14 Apr 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-15 Page 28 14 Apr 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
Region 11: http://oeonline.com/~garyg/region11/
Region 14: http://www.netins.net/showcase/fidonet/
Region 15: http://www.smrtsys.com/region15/
Region 16: http://www.tiac.net/users/satins/region16.htm
Region 17: http://www.portal.ca/~awalker/region17.htm
Region 18: http://www.citicom.com/fido.html
Region 19: http://home1.gte.net/bhamilt/index.htm
============
Zone 2: http://www.z2.fidonet.org
ZEC2: http://fidoftp.paralex.co.uk/zec.htm
Zone 2 Elist: http://www.fidonet.ch/z2_elist/z2_elist.htm
Region 20: http://www.fidonet.pp.se (in Swedish)
Region 24: http://www.swb.de/personal/flop/gatebau.html (in German)
Region 25:
http://members.aol.com/Net254/
Region 27: http://telematique.org/ft/r27.htm
Region 29: http://www.rtfm.be/fidonet/ (in French)
FIDONEWS 14-15 Page 29 14 Apr 1997
Region 30: http://www.fidonet.ch (in Swiss)
Region 34: http://www.pobox.com/cnb/r34.htm (in Spanish)
REC34: http://pobox.com/~chr
Region 36: http://www.geocities.com/SiliconValley/7207/
Region 41: http://www.fidonet.gr (in Greek and English)
Region 48: http://www.fidonet.org.pl
============
Zone 3: http://www.z3.fidonet.org
============
Zone 4: (not yet listed)
Region 90:
Net 904: http://members.tripod.com/~net904 (in Spanish)
============
Zone 5: (not yet listed)
============
Zone 6: http://www.z6.fidonet.org
============
-----------------------------------------------------------------
FIDONEWS 14-15 Page 30 14 Apr 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, cbaker84@digital.net
cbaker84@aol.com
cbaker84@msn.com
(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-15 Page 31 14 Apr 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:
jbarchuk@worldnet.att.net
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-15 Page 32 14 Apr 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-
-----------------------------------------------------------------
Download original FidoNews · Volume 14 (1997) · ← Previous · Next →