1767 lines
79 KiB
Plaintext
1767 lines
79 KiB
Plaintext
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-
|
||
|
||
-----------------------------------------------------------------
|
||
|
||
|