info/mirror-textfiles.com
1
0
Fork 0
mirror of https://github.com/opsxcq/mirror-textfiles.com.git synced 2025-08-31 04:00:09 +02:00
Code Issues Releases Wiki Activity
Files
gh-pages
mirror-textfiles.com/bbs/FIDONET/FIDONEWS/fido1422.nws

2211 lines
98 KiB
Plaintext
Raw Permalink Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

F I D O N E W S -- Volume 14, Number 22 2 June 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. |
+----------------------------------------------------------------------+
THE RIOT STARTS TOMORROW
Table of Contents
1. EDITORIAL ................................................ 1
How about a contest or another new Section? .............. 1
2. LETTERS TO THE EDITOR .................................... 2
IGATOR by Argus .......................................... 2
International BBS Week Echo Correction ................... 2
Bring Back FIDONET.NA .................................... 3
3. ARTICLES ................................................. 5
North American Backbone Problems ......................... 5
4. GETTING TECHNICAL ........................................ 7
FSC-0075 - ISDN capability flags in the Nodelist ......... 7
FSC-0076 - Proposal for NetMail AreaTags ................. 10
FSC-0077 - Type-10 Packet Format ......................... 14
FSC-0078 - Gateway between FidoNet compatible networks ... 20
5. COORDINATORS CORNER ...................................... 25
Nodelist-statistics as seen from Zone-2 for day 150 ...... 25
6. NET HUMOR ................................................ 26
7. ADVERTISE YOUR FREE SERVICE/EVENT ........................ 28
FidoNet Echos via the Internet from 1:141/635 ............ 28
8. ANSWERS OF THE WEEK ...................................... 30
Old Nodelists available in Zone 2 by appointment ......... 30
9. NOTICES .................................................. 32
Future History ........................................... 32
10. FIDONET SOFTWARE LISTING ................................ 34
Latest Greatest Software Versions ........................ 34
And more!
FIDONEWS 14-22 Page 1 2 Jun 1997
=================================================================
EDITORIAL
=================================================================
Let's have a contest to name the new network the Echomail weenies
want to move into when FidoNet refuses to adjust to their skew of
what FidoNet is and does!
The new name should certainly be self-contained in eight characters
for historical if not MSDOS plurality. That name should express as
succinctly as possible the all-consuming Echomailness of the newly
moved into network. It might even have some kind of oblique reference
to its former FidoNet origin like TailDog or FleaNits. [snicker]
After all, the EWs don't want to become yet another superfluous FTN
based solely on Echomail that will eventually dry up and blow away
like its predecessors such as EggNet and AlterNet do they? They've
got to fight for the right to coopt FidoNet without infringing that
trademark.
And in an unrelated vein, next week there will be two more Sections
available for submissions to FidoNews. The first will be .TRU for
True Stories of FidoNet and the second will be .FIC for wannabe
FidoNet Fiction writers [which could include Echomail weenies'
standard bleats]. The ARTSPEC.DOC will be updated to include the new
Section extensions and hatched out into FIDONEWS and SOFTDIST file
echos.
The True Stories will be essays about FidoNet-related events in the
personal lives of Sysops and/or Users. FidoNet Fiction will be
imaginary FidoNet-related short stories or novellae or poems or
limericks. In either case, remember this is a family publication and
nothing illegal gets published. [grin]
Well, it's later than usual this week. We've been having a lot of
lightning storms and tornado watches and warnings today and the system
has been offline a lot to avoid frying.
Please note that the R19 Internet listing has changed once again.
C.B.
-----------------------------------------------------------------
FIDONEWS 14-22 Page 2 2 Jun 1997
=================================================================
LETTERS TO THE EDITOR
=================================================================
--- Following message extracted from NETMAIL @ 1:18/14 ---
By Christopher Baker on Tue May 27 22:26:02 1997
From: Max Masyutin @ 2:469/84
To: Christopher Baker @ 1:18/14
Date: 26 May 97 16:11:18
Subj: Fidonews FIDONET BY INTERNET
Hello Christopher!
About "FIDONET BY INTERNET" section of fidonews. We are the
developers of IGATOR - Fidonet-Internet gateway - our URL is
http://www.ritlabs.com/igator/
We are also working in direction of fidonet transferring via
internet channels, and have written a multinode mailer that can
simultaneously transfer fidonet netmail/echomail/files over dialup and
ip using standard FTS technology. Argus is now widely used in Russia,
especially be hubs, and some nodes in UK and US began to use Argus as
a primary mailer.
Argus home page is http://www.ritlabs.com/argus/
Max. [Argus Team]
---
* Origin: max@ritlabs.com (2:469/84)
-----------------------------------------------------------------
--- Following message extracted from NETMAIL @ 1:18/14 ---
By Christopher Baker on Sun Jun 01 00:37:10 1997
From: David Chord @ 3:771/1560
To: Christopher Baker @ 1:18/14
Date: 27 May 97 16:33:24
Subj: INTBBSWK.ART
It's been brought to my attention that I made an error with a previous
note on International BBS Week and it's support echo, INTBBS_WK. The
error was mentioning the echo as INTBBS_WEEK.
Could anyone who has set this area up as INTBBS_WEEK please change it
to the correct INTBBS_WK.
Also, links are needed to Zones 2, 4, 5 and 6, as well as distribution
around the rest of Z1 and Z3. If you could help with this, please do
so.
Dave
FIDONEWS 14-22 Page 3 2 Jun 1997
Support International BBS Week! Peek in INTBBS_WK for details
--- timEd 1.10
-----------------------------------------------------------------
--- Following message extracted from NETMAIL @ 1:18/14 ---
By Christopher Baker on Sun Jun 01 19:18:16 1997
From: Cindy Ingersoll @ 1:2623/71
To: Editor @ 1:1/23
Date: 30 May 97 16:17:46
Subj: Bring Back FIDONET.NA
-=> Note:
Copied (from: z1_backbone) by C I A using timEd.
I am proposing the reformation of fidonet.na.
The way I figure, if enough people in enough regions support the
concept, we can approach the main distrib hubs (George Peace, John
Souvestre, Ken Wilson) and ask them to host it for us.
I know at least George Peace is willing to include other nets in his
bulk feed, so I don't see him rejecting an request to pass around
fidonet.na.
The technical aspects we need to accomplish are, who maintains the
fidonet.na, how echos are to be added/removed to/from it, and a
minimum set of 'rules'.
Please, let's open a discussion on this, perhaps someone can assist in
getting a 'fidonet.na discussion' echo on the backbone, so we can hash
out some ideas.
I had in mind, for adding echos, to have say, 5 nodes from each region
'vote' that they will carry and participate in the echos. Much better
than the current '2 rec' voting echos are at the mercy of now :)
As for a minimal set of rules, we'll prolly be arguing for a while.
But I think the concept of an alternative backbone is overdue, and I
hope we can get together and create it :)
A good start, along with the creation of an echo for discussion, would
be to begin assembling a list of ftp/transx/vfossil and other
Internet-fido feeds. I would like to suggest to our Editor of Fidonews
Chris Baker, add a new section to the weekly fidonews, a list in
hierarchial order, from T3's to 28.8s, all the system's who have
fidonet available across the Internet.
Here's my current list, please feel free to send additions! :)
Spd | Node# | Operator | Services | rate
--------------------------------------------------------------------
T1 | 1:270/101 | George Peace | FTPHUB | $30 monthly
FIDONEWS 14-22 Page 4 2 Jun 1997
33.6 | 1:2604/104 | J. Mclaughlin | FTPHUB, VFOSSIL | $1 monthly
| | | |
Origin: Fly By Night * HaXeD HeXeD HiXed * (609)653-1FLY! (1:2623/71)
-----------------------------------------------------------------
FIDONEWS 14-22 Page 5 2 Jun 1997
=================================================================
ARTICLES
=================================================================
North American Backbone Problems
-by Jon Gentil 1:232/211.0 <jon.gentil@magi.station-1.com>
The North American Backbone (NAB for short) is undergoing
tremendous alterations of itself, and it's causing some
disturbances in the FidoNet community.
Take for example the FLAME echo. I don't really like the FLAME
echo, and really don't hate it either. But when it's removed from
distribution simply because the Backbone feels that it's causing
trouble, there's a problem. Which echo will they remove next? The
TOTT_* echos pose a potential hazard to it's readers. The CHATTER
echo has mean people in it. The FILEFIND echo doesn't have enough
real people posting there. What next?
And did you notice the second-to-last paragraph of this week's
Backstat.na?
It reads:
--------------------------------------------------[BACKSTAT.NA]----
Each region is normally offered 1 link to each ZHub. Exceptions are
made after agreement between the REC, Z1EC, and the ZHub subject to
the ability to handle the additional load. Individual net/node
connections to ZHubs are made on the basis that the node will serve as
a Region Hub, the exception being connections local to the ZHub.
----[END]----------------------------------------------------------
Note "Individual net/node connections to ZHubs are made on the
basis that the node will serve as a Region Hub."
Does that mean that every node connected to a ZHub serves as a
Region Hub? That's what it says.
So we have 100+ Rhubs now. !!!
Ever notice how the BOFAQ is constantly changing? Who radified it?
Who must obey it? Anyone? Everyone?
Why is a private distribution system allowed to use the term ZHub
if it's private? I thought that Hubs were public.
The requirements to be a Hub of the NAB are that you must have a
link to a ZHub and you must have at least one downlink, yet Ken Wilson
(1:12/12), a ZHub, has no downlinks. Do they pardon those that are
"Insiders?"
Did you notice how conviently the Backbone changed their policy of
who is the OBO? Possibly in fear that someone that wants to abolish
the OBO Council and return the Backbone to a public system?
Write your NC's, NEC's, RC's, REC's, ZC, ZEC, and even me telling
FIDONEWS 14-22 Page 6 2 Jun 1997
us your opinion of the North American Backbone. Articleize it in
FidoNews.
-----------------------------------------------------------------
FIDONEWS 14-22 Page 7 2 Jun 1997
=================================================================
GETTING TECHNICAL
=================================================================
[This is part of the continuing FidoNet History republication of the
extant FidoNet Standards and Proposal documents. They have been
reformatted to 70 columns where required and some tables may be askew
as a result. Node numbers and phone numbers may be out of date.] Ed.
| Document: FSC-0075
| Version: 001
| Date: 23rd October 1993
| Author: Jan Ceuleers
ISDN capability flags in the Nodelist
A proposal
by Jan Ceuleers, 2:292/857
version 0.4, October 3rd 1993
1 Introduction
The Integrated Services Digital Network is a worldwide
overlay network, offering the same services as the PSTN
(Public Switched Telephone Network) and more. Its basic
bearer capability is a digital bit stream of 64000 bits/s,
as opposed to the audio channel with a 3.1 kHz bandwidth
provided by the PSTN.
Transferring data across the ISDN can be done in one of two
ways:
- by using the telephony services the ISDN provides. In
this mode, a standard modem can continue to be used.
Some modulation schemes currently in use are V.32bis,
PEP, ZyXEL, HST, V.32, etc. We already have nodelist
flags for these cases.
- by using ISDN's 'native' mode. In this case, a
number of protocols (either or not ISDN-specific) are
used, such as V.110, V.120, X.75 etc.
This document aims to define the way in which nodes
are to advertise their ISDN capabilities in the nodelist,
irrespective of whether or not ISDN-only nodes should be in
the nodelist in the first place. This latter problem is to
be solved by the politicians.
Descriptions of ISDN equipment and compatibility with POTS
(Plain Old Telephone Service) equipment are beyond the scope
of this document. More detailed information on ISDN is also
not provided; readers are referred to the literature (e.g.
'Computer Networks' by Andrew Tanenbaum).
FIDONEWS 14-22 Page 8 2 Jun 1997
2 Different flavors of the same protocol
Some ISDN protocols have different flavors, some of which
differ only marginally, but others are quite distinct.
For the techies among the readership: examples of
both cases can be found in the 1988 definition of
V.110. There are two variants of the frame
structure used in the 56kbps synchronous mode
(marginal difference), while there is quite a major
difference between the synchronous and asynchronous
versions of V.110.
Since FidoNet applications are essentially character-based,
the asynchronous versions of protocols will be preferred
over the synchronous-ones(1). This applies to V.110 and
V.120 and to any other such protocol.
If there is an option, 8 data bits, no parity and 1 stop bit
will be used in preference over all other possible
combinations. (This is in line with the FOSSIL spec).
3 Speeds
Some protocols (such as V.110) can be used at different
speeds. Certain implementations of these protocols may not
support some of these speeds.
The baud rate field in the nodelist should not be used for
indicating the maximum speed an ISDN node is capable of,
since ISDN capability flags could (technically) co-exist
with normal modem capability flags(2).
4 Nodelist flags
ISDN-related nodelist flags consist of a prefix, a protocol
indicator and an optional (set of) suffixes.
The prefix is the capital letter I (for ISDN).
The protocol indicator is one of the strings defined in
paragraph 5 below.
The suffix indicates the way in which the implementation
deviates from the preferred implementation, as indicated in
paragraphs 2 and 3. The possible suffixes are:
Onnn The only bit rate supported = nnn
* 100 (e.g. IV110O384 means that
this node only supports V.110
asynchronous at 38400 bps and at no
other speeds.
1. As a matter of fact, there are no
provisions for advertising the synchronous
versions of such protocols.
FIDONEWS 14-22 Page 9 2 Jun 1997
2. ISDN technology indeed allows for the possibility
of both modem and ISDN-specific datacom
connectivity on the same 'telephone' number.
Pnnnnn Maximum packet size supported in
bytes. This is a layer 2 packet
protocol parameter. Communication
between two nodes is only possible if
either end's maximum packet size is
not exceeded. Leading zeroes are to
be omitted.
Rnnn Highest bit rate supported = nnn * 100
(e.g. IV110R192 means that this node
does not support V.110 asynchronous at
38400 bps, but does support all other
standardised rates up to and including
19200 bps)
Wn Window size. The window size must be
less than the modulo value (i.e. in
modulo 8, the maximum window size is
7).
If more than one suffix is used, the suffixes will be
sorted in ascending order.
5 Protocols
This section defines the meaning of the base protocol
indicators. The aim is to have this base protocol indicator
cover the majority of cases, so that suffixes will only
rarely be required.
5.1 V.110
The protocol indicator is V110. When specified
without suffixes, the IV110 nodelist flag indicates
V.110 asynchronous capability at bit rates up to and
including 38400 bps.
5.2 V.120
The protocol indicator is V120. When specified
without suffixes, the IV120 nodelist flag indicates
V.120 asynchronous capability. Due to the nature of
the protocol, the O and R suffixes are irrelevant.
There is no explicit mention of frame size in the
V.120 specifications. However, since Q.921 is the
layer-2 protocol of V.120, one might assume the
frame size of Q.921, which is 260 bytes. Frame sizes
larger than that should be negotiated between
sysops.
5.3 T.90 (X.75)
FIDONEWS 14-22 Page 10 2 Jun 1997
The protocol indicator is T90. Base protocol
parameters are:
modulo: 8
window size: 2
packet size: 2048 bytes
Currently, there is no standardized method for
negotiation of the modulo mode (Recommendation ITU-
TS T.90 reserves this subject for further study),
all T.90-capable nodes should answer in modulo-8
mode. Itis therefore useless to advertise modulo-
128 capability. This also limits the maximum
window size to 7.
Some implementations have a maximum frame length of
130 bytes and a maximum window size of 1. This
would be documented as IT90P130W1. The 1992 version
of the T.90 standard specifies a method for in-band
negotiation of frame length and window size.
5.4 Other protocols
Additional protocols can be added to this document
(and thus assigned a nodelist flag) if sufficient
technical information is made available.
Neither X.25 on B nor on D have been added, because
there is no room in the nodelist for the X.25
address.
6 Conversion from old to new
The ISDNA, ISDNB and ISDNC nodelist flags are already in use
in zone 2. The table below shows the relationship between
old and new.
new old
IV110O192 ISDNA
IV110O384 ISDNB
IT90 ISDNC
IV110 ISDNA,ISDNB
IV110O384,IT90 ISDNB,ISDNC
---===---
-30-
-----------------------------------------------------------------
FIDONEWS 14-22 Page 11 2 Jun 1997
| Document: FSC-0076
| Version: 001
| Date: 03rd December 1993
| Author: Steve T. Gove
A Proposal for NetMail AreaTags.
Steve T. Gove
1:106/6.0@fidonet
Status of this document:
========================
This FSC suggests a proposed protocol for the
FidoNet(r) community, and requests discussion and
suggestions for improvements. Distribution of this
document is unlimited.
Fido and FidoNet are registered marks of Tom
Jennings and Fido Software.
General Introduction:
=====================
Within the FTN networks today is the ability to
belong to a variety of networks. These can include, but
are not limited to, FidoNet, RBBSNet, AlterNet, etc.
Within each of these specific networks is the ability to
pass "NetMail" both routed and direct. But what if
someone belongs to many of these networks? How does one
differentiate netmail between them? Currently, NetMail
does NOT allow for an AreaTag to allow for specifying
between different Domains. I propose that this change.
My proposal is to allow for the areatag, for netmail, to
be called "NETMAIL".
current netmail - none
current echomail - AREA:<echoname> ex. AREA:Binkley
proposed netmail - NETMAIL:<domain> ex. NETMAIL:FidoNet
ex. NETMAIL:RBBSNet
This would allow for multi domain'd netmail to be
seperated into seperate sub-directories to allow our
netmail readers to differentiate between them and allow
for replying based on their originating Domain.
Compatability
=============
"Compatibility is a set of abilities which, when
taken as a whole, make it safe to list a net or node in
the FidoNet nodelist."
I believe that utilization of my proposal, will
FIDONEWS 14-22 Page 12 2 Jun 1997
allow for full backwards compatability with reguard to
netmail and will allow, at the same time, for forward
progress to be achieved, both, within the fidonet
community and with other FTN networks.
NetMail Definition:
===================
NetMail is a driving force behind FidoNet, and
allows for the communication between two individuals
anywhere in the world.
See FTS-0001.015 for details on netmail packet
structure.
Required Control Information:
============================
An "AREA:" tag is what makes the difference between
netmail and echomail. This would change the definition
between NetMail and EchoMail, as practiced today. This
proposal, however, would not effect EchoMail. NetMail
would now, simply, have an areatag named "NETMAIL".
The NETMAIL line must be the first line in an
netmail message's body. A NETMAIL line's format is
simply:
NETMAIL:<DomainName>
The NETMAIL tag is specifically _not_ preceded by a ^a.
Where <DomainName> is the unique name of the
NetMail's origin. Area names should not begin with the
plus or minus ("+" or "-") symbols. Area names must not
contain control characters (less than ASCII character
32, a space). Leading and trailing spaces on the area
name should be ignored (and preferably not produced).
Compares on the netmail name should be case insensitive.
NetMail <Domain> names are generally kept as short
as possible while still maintaining uniqueness and some
sense of which Domain the NetMail belongs to.
EchoMail Definition:
====================
Echomail, sometimes called broadcast or conference
mail, is netmail (ref. FTS-0001) containing additional
control information that allows it to be "echoed"
(forwarded) from node (site) to node. Echomail is
divided into areas, or conferences, with unique names.
Acknowledgements:
================
Tom Jennings who "created" Fidonet.
FIDONEWS 14-22 Page 13 2 Jun 1997
Jeff Rush who "created" echomail.
Mark Kimes - 1:380/16@fidonet (fsc-0068.a01)
Related documents:
==================
FTS-0001 (transport layer, packet format, various
kludge lines)
Policy4 (whether you agree or not...!)
PSEUDO-CODE
===========================================================
For historical reasons, the term packet is used in
FidoNet to represent a bundle of messages, as opposed to
the more common use as a unit of communication, which is
known as a block in FidoNet.
An Inbound Mail packet arrives. (0000fff1.mo0)
The packet is unpacked and b498c880.pkt is found.
A "Tosser" looks at the *.pkt for an areatag,
IF AREA: THEN (EchoMail) toss to appropriate area,
IF NETMAIL: THEN toss to "Tosser" defined netmail area
according to domain,
IF NOT AREA: OR NETMAIL: THEN *.pkt is (old-style) netmail
toss to "Tosser" defined netmail area.
Sample "Tosser.CFG" file excerpt
-----------------------------------------------------------
NetArea FidoNet E:\Mail\NM_Fido
NetArea RBBSNet E:\Mail\NM_RBBS
NetArea AlterNet E:\Mail\NM_AltNt
NetArea OtherNet E:\Mail\NM_OtrNt
BadArea BAD_MSGS D:\Bad_Msgs
DupeArea DUPES E:\Mail\Dupes
LocalArea Bad_Mail D:\Bad_Mail
LocalArea Bad_GMD D:\Bad_GMD
LocalArea WIMM D:\WIMM
EchoArea File_Announce D:\File_Announce 1:106/6
EchoArea MHS D:\MHS\Mail\Users\Steve 1:124/1301
EchoArea Test D:\T\Test 1:106/6 .1
EchoArea R19SysOp D:\R\R19Sysop 1:106/2000
-30-
FIDONEWS 14-22 Page 14 2 Jun 1997
-----------------------------------------------------------------
| Document: FSC-0077
| Version: 001
| Date: 03rd December 1993
| Author: Jason Steck
Type-10 Packet Format
An FSC Standard Proposal
I. Introduction:
Over time, the traditional FidoNet FTS-0001 "Type 2"
packet format has been repeatedly shown to be inadequate in
a wide variety of advanced implementations. The inadequacies
of the type-2 format have been particularly evident in multi-
zone and multi-domain environments.
When type-2 was originally established, it was
sufficient to existing networking needs. FidoNet was the
"only show in town" and the 2-dimensional net/node
arrangement was easily adequate to the requirements of the
network. However, growth in FidoNet required the
introduction of "zones" to separate large geographical areas
from each other. The advent of echomail led directly to the
creation of sub-node "point" systems, adding a fourth
dimension to the addressing scheme. The explosion in recent
years of similar-technology, non-FidoNet networks has
required the addition of a fifth dimension, the "domain" to
differentiate between potentially conflicting addresses in
different networks.
The 2-dimensional type-2 format is clearly inadequate
to a 5-dimensional addressing requirement. Various schemes
have evolved to attempt to compensate for the failings of
the type-2 environment. Type 2.2 (FSC-0045) and type-2+
("capability word" -- FSC-0039) packet format modifications
have been devised to attempt to modify the packet format to
include necessary addressing information. Further, a
plethora of message text "kludge lines" (lines hidden behind
an ASCII #01 character) have been inserted to provide
additional addressing information required by modern
implementations.
The major failing of all these schemes, however, comes
when they run square-on into the "real world". Competing
implementations often use slightly different formats or
requirements within packet formats and kludge lines. The
mere existence of kludge lines impose significant performance
and message test size and content penalties for mail
processors.
This proposal seeks to establish a new packet format
which would resolve the problems and inadequacies presented
by the existing formats. In acknowledgment of the fact that
a theoretical proposal is useless without a practical
implementation, this proposal has been implemented in the
JMail 2.10 (and later) versions of electronic mail
processors. In the interests of reverse-compatibility, it
FIDONEWS 14-22 Page 15 2 Jun 1997
is STRONGLY RECOMMENDED that any implementations of this
proposal include some mechanism for supporting older formats
and their popular modifications.
This proposal establishes a detailed packet format
including packet header and internal message structure. The
format assumes the utilization of the FidoNet-style
zone:net/node.point@domain addressing format. Other
addressing formats, such as UUCP RFC-822 domain addressing
and/or "bang-path" addressing are not directly supported by
this format.
II. The 5-Dimensional Address
The 5-dimensional address consists of the elements (in
hierarchical order) domain, zone, net, node, and point. The
full ASCII representation of this is
"zone:net/node.point@domain". Where the point number is
zero (a full node system as opposed to a dependent point
system), the period (.) and the point number (0) may be
excluded.
Implementations with size concerns may desire to include
some facility to "assume" or "guess" at particular elements
of a particular address based on prior addresses or user-
supplied criteria. This capability also has advantages when
dealing with older formats which supply less than complete
information.
III. Type-10 Packet Format
A. Conventions
All binary numerical values in a type-10 packet are
stored in Intel's byte-swapped format.
Within this document, all binary numerical values will
be given in hexadecimal notation (base-16) using the (#)
designator and right-justified with leading zeros. For
example, a single-byte value of 10 would be designated as
"#0A" while a word-length, two-byte value of 10 would be
designated as "#000A".
"NULL" is equivalent to either a #00 byte or #0000 word
value.
B. File Naming Conventions -- *.P10
Type-2 packet formats established the convention of
using the PKT extension on file names. This naming
convention enabled mail-processing software to easily
determine which files within a given directory were intended
to be processed.
In order to prevent conflicts and preserve easy reverse-
compatibility, it is necessary for any upgraded format to
utilize a different file naming convention. Type-10 packets
are named with an extension of P10. This has the additional
effect of providing an easy new path for additional standards
-- for example, a theoretical type-11 packet could use,
without conflict, an extension of P11.
FIDONEWS 14-22 Page 16 2 Jun 1997
Archived type-10 mail packets may use the same archiving
file name conventions established for type-2 packets.
Indeed, the different file naming convention of type-10
packets allows the inter-mixing of packet types within a
single archive.
C. Packet Header
The PacketAddressRecord contains a complete 5-
dimensional address.
(* Address structure -- Pascal notation *)
PacketAddressRecord = RECORD
Domain : ARRAY[1..8] of char;
Zone, Net, Node, Point : integer;
END;
/* Address structure -- C notation */
struct PacketAddressRecord {char domain[8],int
zone,int net,int node,int point};
A packet header must appear at the beginning of each
type-10 packet file.
(* Packet Header structure -- Pascal notation *)
PacketHeaderRecord = RECORD
PktType : byte;
PktFrom,PktTo : PacketAddressRecord;
PktPWd : ARRAY[1..8] of char;
ProdCode : word;
ProdVer : word;
END;
/* Packet Header structure -- C notation */
struct PacketHeaderRecord {unsigned char
PktType,struct PacketAddressRecord PktFrom, struct
PacketAddressRecord PktTo, char PktPWd[8],unsigned
int ProdCode, unsigned int
ProdVer]
The PktType field contains a numerical value indicating
the packet type format of the rest of the packet. The
PktType field of a type-10 packet will always contain the
value #0A. This value has been placed in byte 0 of the file
to provide a convenient upgrade path for future packet
formats.
The PktFrom field contains a PacketAddressRecord
structure indicating the address of the sending system.
The PktTo field contains a PacketAddressRecord
structure indicating the address of the destination system.
The PktPWd field may contain a 1-8 byte (NULL padded)
password for the securing of links between systems. If the
link has no password protection, this field will contain 8
NULL bytes.
The ProdCode field contains a 0-65535 numerical value
FIDONEWS 14-22 Page 17 2 Jun 1997
indicating the product code assigned by a relevant standards
committee for the software package producing the packet.
The ProdVer field contains a 0-65535 value. The hi-
order byte contains the major version number and the low-
order byte the sub-version number. The ProdCode and ProdVer
fields are used to detect and assist in the elimination of
format errors produced by errant software implementations.
D. Packet Body Format
After a packet header, a type-10 packet will contain
any number of packet "blocks". Individual blocks may not
exceed 30720 bytes (30 kilobytes) in length. (This allows
for easy buffering and data manipulation.)
Each block is prefaced with a "block header" to define
the type of information contained within the block:
(* Block header structure -- Pascal format *)
BlockHeaderRecord = RECORD
BlockID : longint;
BlockType : byte;
BlockLen : word;
BlockCRC : word;
END;
/* Block header structure -- C format */
struct BlockHeaderRecord {long int blockid,
unsigned char BlockType, unsigned int BlockLen,
unsigned int BlockCRC}
The BlockID field is used for error-checking purposes.
It must alwasy be set to #22AAE0.
The BlockType field contains a numerical value from 0-
255 indicating the type of data contained within the block:
#00 - Packet Terminator Block. (BlockLen and BlockCRC
fields must be set to #0000.) This block indicates an end-
of-file. Data beyond this point will be ignored.
#01 - Command Block. This block is for system-to-
system commands and requests. This block is not yet
implemented and will be detailed in a future revision to
this document.
#02 - Message Header Block.
#03 - Seen-by Block.
#04 - Path Block.
#05 - Message Text Block. (More than one successive
#05 block may be used to hold the text of messages greater
than the maximum block size. In theory, this allows for
truly unlimited-length message capability. However,
implementations which intend to communicate with older, type-
2 are realistically limited to message sizes which can be
adequately buffered by type-2 processors.)
The BlockLen field indicates the number of bytes within
the block.
The BlockCRC field is optional. If the value of field
FIDONEWS 14-22 Page 18 2 Jun 1997
is other than #0000, then the field will contain the CRC
value of the field data (excluding the Block Header). This
allows for some degree of integrity-checking on packet data.
Following each Block Header will be BlockLen bytes of
data of the type specified in the BlockType indicator. A
normal message would break down into a Message Header block
(#02) followed by a Seen-by Block (#03), followed by a Path
Block (#04), followed by one or more Message Text Blocks
(#05).
Some data areas will contain structured sub-fields.
These are as follows:
#02 - Message Header Block. Each sub-field within this
data block will be prefaced with a numerical sub-field
identifier, followed by a single byte indicating the
length (in bytes) of the sub-field, followed by the
appropriate sub-field. Sub-fields are as follows:
#01 - From Name. This is the ASCII name of the
person who originally wrote the message. This sub-
field is required on all messages.
#02 - To Name. This is the ASCII name of the
person to whom the message is directed. This sub-field
is required on all messages.
#03 - Subject. This is the ASCII representation
of the originator-entered subject.
#04 - Date/Time Group (binary -- length byte will
always be #04). This is the date and time the message
was originally entered. It is stored in the 32-bit
"longint" format. This is a "packed" time format used
by MS-DOS to store file date/time records. This or a
#05 sub-field is required on all messages.
#05 - Date/Time Group (ASCII -- length byte will
always be #13). This is an ASCII date/time
representation of the origination date/time of the
message in the format specified in the FTS-0001
document (DD MMM YY HH:MM:SS) This or a #04 sub-field
is required on all messages.
#06 - MSGID line. This is an FSC-0036 compliant
MSGID line. It is a required sub-field on all echomail
messages.
#07 - Origin Address (PacketAddress Format --
length byte will always be #10). This is the network
address of the originating system of the message. This
sub-field is required on all messages.
#09 - Destination Address Override (PacketAddress
Format -- length byte will always be #10). This sub-
field contains an override for the destination address
of the corresponding messages. Processors should
determine that each message is destined for the address
listed in the PacketHeaderRecord except where
specifically overridden in a #09 sub-field.
#0A - Echomail Area Name. This sub-field
indicates the echomail area that the message is being
FIDONEWS 14-22 Page 19 2 Jun 1997
distributed in. This sub-field is required on all
echomail messages.
#0B - Origin Line. This sub-field contains the
origin line for echomail messages. This sub-field is
optional, but is realistically required on all
implementations which intend to communicate using any
older type-2 format.
#0C - FLAGS line. This sub-field contains the
message attributes in FSC-0053 format. The leading
ASCII #01 (control-A) character should be excluded from
this sub-field, but implementations should be tolerant
of common minor FSC-0053 variations.
#0D - Tear Line: This sub-field contains a
tearline (not to exceed 35 characters including the
leading "---" characters. This line is required on all
echomail messages.
#0E - PID Line: This sub-field contains the
optional Product Identification (PID) line.
#0F - REPLY: This sub-field contains the optional
REPLY field, used with MSGID lines for message thread
linking purposes on echomail messages.
#03 - Seen-by Block. The Seen-by Block contains
address information of the systems which have "seen" an
echomail message. This data is used to prevent sending
multiple copies of messages to a single system. Seen-
by blocks are required on all echomail messages.
Implementations will append information for all
addresses the local system is sending the current
message to prior to actually sending any message. Seen-
by information for systems not in the same domain as
the destination system must be excluded. The local
system's address information in a minimal requirement
on all messages.
The data is a series of two-byte integers. The
first four integers indicate (in order) the zone, net,
node, and point number of the first address in the
list. This address serves as a "base" from which other
addresses "evolve" as explained below:
Positive value (greater than or equal to 0): node
number (zone and net information same as previous
address and point number equals 0).
Negative number (less than zero EXCEPT -32768):
number multiplied by -1 equals new net number (absolute
value). Next number will be new node number.
"Reset number" (-32768): indicates new full
address block. Next four integers will equate to (in
order) the zone, net, node, and point number of next
address in seen-by list. Later addresses will "evolve"
from this number.
This storage format allows for an extremely
flexible and compact method of storing seen-by
information.
FIDONEWS 14-22 Page 20 2 Jun 1997
#04 - Path Block. This block contains the addresses
that the current message has passed through. This
information is maintained across all domain boundaries.
Whenever a system processes a message, it adds its own
address to the end of this list. Address records are
stored in PacketAddressRecord format.
IV. Development and Implementation Assistance
As this is a proposal for a new standard, it is
reasonable to expect ambiguities and problems to eventually
develop in potential implementations of the standard. The
author of this standard is available to clarify matters of
interpretation or ambiguity or problems in coding or
implementation of the standard. Public-domain code
"snippets" of critical portions of the standard
implementation will be made available when necessary and
feasible.
The author may be reached at the addresses below:
Jason Steck 1:285/424@FIDONET
PROZ Software 200:5000/400@METRONET
12105 W. Center Rd #103 39:70/200@LDSSNET
Omaha, NE 68144 42:1009/424@CANDYNET
Ready Room BBS (402)691-0946
-30-
-----------------------------------------------------------------
| Document: FSC-0078
| Version: 001
| Date: 11th April, 1993
|
| Clovis Lacerda, 4:808/2
Gateway between Fidonet compatible networks
Author: Clovis Lacerda, Brazil
Fido : 4:808/2
Email : clovis@ear.anpe.br
Date : March, 1993
Copyright 1993, Clovis Lacerda. All rights reserved. The right to
distribute for non-commercial use is granted to the Fidonet
Technical Standards Committee, provided that no fee is charged. This
may be posted on electronic BBSs which charge no fee for accessing
this document. Any and all other reproduction or excerpting requires
the explicit written consent of the author.
FIDONEWS 14-22 Page 21 2 Jun 1997
INTRODUCTION
Many networks, using the Fido technology, are being created
everywhere. It is now time to implement a means to provide gateway
capability between these networks. Some proposals were made, but, as
far as I know from reading most of the FSC standards, none of them
actually play with the basic standards of Fidonet, as established in
FSC-0001. It is time to think of other ways in which to improve Fido
technology based on what is universally available, rather than
relying on the infamous ^A kludges that many software packages out
there don't use, or worse, ignore systematically.
ABSTRACT
From now on, the word FakeNet will be used to refer to any Fido-
compatible network that is not in the Fidonet nodelist, thus using
node numbers not found in the 1-thr-6 Fidonet zones.
A Fakenet uses its own nodelist. There is a large number of Fakenets
all over, one not knowing the existence of the other, some using the
same node numbers in their own nodelists. We shall try to put these
networks together, not by forcing any of them into a single nodelist,
but by making one aware of the existence of the others, and providing
gateways in each of these networks so that mail can flow in both
directions.
IMPLEMENTATION
For a gateway to be implemented, extra information must be provided
in the netmail. Normally, two user names, From: and To: define the
sender and the addressee. The node numbers go "inside" the netmail
and have their existences checked in the nodelist of the network in
question by the local running software.
Since we now have 2 networks, the extra information must be the
remote node in the destination network, which obviously cannot be
found in the local nodelist, and the local node that must reach the
remote addressee, otherwise a reply cannot be made.
Suppose, for example, that there are 2 Fakenets, one based in zone 10
(network 1), the other one in zone 11 (network 2), and that user John
Green in node 10:100/1 wants to send a netmail to Paul Brown in
11:200/1.
In both networks, a gateway node (common to both nodelists) must be
provided. Let's say that node 10:10/1 is the gateway in network 1,
named "Gateway system A" and node 11:11/1, named "Gateway system B"
is the gateway in network 2.
What John, from network 1, will have to do is:
Send a netmail to his local gateway node, which is 10:10/1.
In the To: field, he will put, besides the name of the addressee,
Paul Brown, PAUL'S NODE NUMBER, 11:200/1, inside (). This is the
extra information needed for the gateway to work. What will happen
FIDONEWS 14-22 Page 22 2 Jun 1997
is:
This netmail, in the domain of network 1, will travel the route and
reach the gateway, 10:10/1. This gateway system must do the
following:
Change the domain of the netmail from network 1 to network 2. This
means that any reference to node numbers in the netmail header must
be updated.
Thus, the netmail will now have the node 11:11/1 as the originating
node, and 11:200/1 as the destination node, "hardcoded" in its
header. But we can see that John's node number must be provided,
otherwise Paul will not be capable of replying. This is done by the
gateway software that includes John's node number in his From: name
field, inside (). When Paul receives John's netmail, he will reply,
and the From: field will automatically become the new To: field, and
will contain John's name and node number. The netmail will reach back
11:11/1 and the process will be exactly the same, finally reaching
John.
In resume, this is the odyssey of John's netmail to Paul:
1 - John enters his message to Paul. Since Paul is not in John's
network, John will have to use the gateway.
He sends a netmail to his local gateway system, 10:10/1 which
looks like this:
From: John Green, John's BBS (10:100/1)
To : Paul Brown (11:200/1), Gateway System A (10:10/1)
Re : Hello
------
body of message ......
Note that John had to MANUALLY enter Paul's node number and put it in
the To: field, together with Paul's name. This netmail is addressed
to Gateway System A, node 10:10/1.
2 - After arriving in 10:10/1, the gateway software will create a new
netmail that looks like this:
From: John Green (10:100/1), Gateway System B (11:11/1)
To : Paul Brown, Paul's BBS (11:200/1)
Re : Hello
----
body of message....
Note that John's node number was inserted in the From: field, which
is the information needed for the bidirectional gateway to work.
3 - This netmail is now in the domain of network 2. It will travel
the normal route and reach Paul. When he replies, the local message
editor will make the From: field become the To: field. The
FIDONEWS 14-22 Page 23 2 Jun 1997
netmail-reply will look like this:
From: Paul Brown, Paul's system (11:200/1)
To : John Green (10:100/1), Gateway System B (11:11/1)
Re : Hello
----
body of new message.....
This netmail will travel the route and reach 11:11/1. The process now
is exactly the one used to gate the original netmail from network 1
to 2. The gateway software will create a new netmail that looks like
this:
From: Paul Brown (11:200/1), Gateway System A (10:10/1)
To : John Green, John's system (10:100/1)
Re : Hello
----
body of new message....
Note that Paul's node number was inserted in the From: field,
finishing the gateway process.
The only trade-off in the current proposal is obvious. The limited
length of the name fields, which, according to FSC-0001, is 36
characters long, and that may not allow the inclusion of the person's
node number in it.
For example, if John's full name were John Green Richardson Smith
Jr., he would have sent his netmail to Paul, but the gateway system
would fail when attempting to include his node, 10:100/1 together
with his name. In this case, the netmail is bounced back with a
warning message, and it will be John's responsibility to change his
name to a shorter one or use an alias. It seems that more and more
people are being practical and using only 2-word names, so this is a
problem that can be easily worked out by the local BBS operator.
Lastly, ^aINTL kludges must be issued in all netmails gated between
the 2 networks.
This proposal follows FSC-0034 and FSC-0001. It also allows immediate
aplication, since it relies on what is Fidonet in essence, FSC-0001.
A gateway package was implemented for this purpose. MailGate (c),
besides gating netmail and echomail between 2 or more Fakenets, also
provides transparent gateway between a Fakenet and Internet,
integrating lists and news with echomail and also providing a BBS
with the feature of creating its own lists, that can flow as
echomail through a Fido-compatible network, through the gateway
between 2 fakenets, and also through Internet, as a mailing list.
CONCLUSION
Enhancing technology and creating new oportunities, necessary
ingredients to allow systems and sysops to play their freedom of
FIDONEWS 14-22 Page 24 2 Jun 1997
choice, are the best keys to improve Fidonet technology and make it
really become the de facto standard, no matter which new network is
created every day.
I don't know how suitable this proposal is in regard to the incoming
problem Fidonet is facing, or will have to face, when all the
nodelist zones split apart, since the size of the nodelist is growing
alarmingly.
This document is not perfect and may contains wrong conclusions.
Should you have suggestions and constructive criticisms, please
contact the author.
My thanks to those who were prompt in helping me through the
technical aspects of Fidonet and in the last days routed my emails
when trying to reach FTSC, (it finally reached the right place,
Australia) especially Tom Jennings, Randy Bush and David Nugent.
Thanks to Mitch Davis for helping me with some technical details.
By no means am I saying that they support or have even read this
document, it's only a thank you note.
Fidonet is a trademark of Tom Jennings and Fido software, to whom we
all owe many thanks for the origin and spirit of Fidonet.
MailGate is a trademark of Clovis Lacerda
-30-
-----------------------------------------------------------------
FIDONEWS 14-22 Page 25 2 Jun 1997
=================================================================
COORDINATORS CORNER
=================================================================
Nodelist-statistics as seen from Zone-2 for day 150
By Ward Dossche, 2:292/854
ZC/2
+----+------+------------+------------+------------+------------+--+
|Zone|Nl-122|Nodelist-129|Nodelist-136|Nodelist-143|Nodelist-150|%%|
+----+------+------------+------------+------------+------------+--+
| 1 | 8519| 8430 -89 | 8367 -63 | 8277 -90 | 8277 0 |31|
| 2 | 15952|15904 -48 |15879 -25 |15855 -24 |15835 -20 |59|
| 3 | 800| 800 0 | 800 0 | 761 -39 | 765 4 | 3|
| 4 | 548| 543 -5 | 543 0 | 543 0 | 543 0 | 2|
| 5 | 87| 87 0 | 87 0 | 87 0 | 87 0 | 0|
| 6 | 1083| 1083 0 | 1083 0 | 1077 -6 | 1078 1 | 4|
+----+------+------------+------------+------------+------------+--+
| 26989|26847 -142 |26759 -88 |26600 -159 |26585 -15 |
+------+------------+------------+------------+------------+
-----------------------------------------------------------------
FIDONEWS 14-22 Page 26 2 Jun 1997
=================================================================
NET HUMOR
=================================================================
Date: Fri, 23 May 1997 22:19:14 -0700
From: Shari <bluedawg@concentric.net>
Organization: OREGON - USA
To: webheads@softdisk.com
Subject: The Newbie's Song
Sender: owner-webheads@softdisk.com
Reply-To: webheads@softdisk.com
The Newbie's Song
(Based on the Major General's song from "The Pirates of Penzance",
Gilbert & Sullivan) By Anonymous Author
I am the very model of a Usenet individual,
I've information meaningless and ultimately trivial,
I know the basic elements of alien biology,
And all the hidden secrets of the Church of Scientology,
I've seen "The Wrath of Khan" and every Star Trek film that followed
it,
I moan about my Servicecard and how the cash till swallowed it,
About the laws on handguns I am sending off a counterblast,
With many cheerful facts about the way you can MAKE MONEY FAST!
ALL: With many cheerful etc.
I'll tell you why the Japanese are taking over Panama,
And why the USA is still a better place than Canada,
In short, in matters meaningless and ultimately trivial,
I am the very model of a Usenet individual.
ALL: In short, in matters meaningless and ultimately trivial,
He is the very model of a Usenet individual.
I post in alt.revisionism lies about the Holocaust,
I cut my .sig to twenty lines, I didn't want to, I was forced,
I really can't believe the "Good Times" virus to be mythical,
And Clinton's raising taxes which is, frankly, bloody typical,
I've upset several people on alt.flame, I really don't know how,
And sent a thousand business cards to Mr. and Mrs. Shergold now,
I have a very poor grip of political geography,
And absolutely no involvement (yet!) in child pornography,
ALL: And absolutely no, etc.
I've paid two-fifty dollars for the Nieman-Marcus recipe,
And told the Spanish tourist's tale about the toothbrush pessary,
In short, in matters meaningless and ultimately trivial,
I am the very model of a Usenet individual.
ALL: In short, in matters meaningless and ultimately trivial,
He is the very model of a Usenet individual.
FIDONEWS 14-22 Page 27 2 Jun 1997
In fact, when I know what is meant by "binary" and "FTP",
When I know how to decode porno JPEGs from a .uue,
When I can handle HTML, Telnet, mail and IRC,
And when I know the words initialised to form "http",
When I have learnt what topics are acceptable in talk.bizarre,
When I know more of Usenet than the tailpipe of a motor-car,
In short, when I've a smattering of elementary netiquette,
You'll say a better individual has never surfed the Net.
ALL: You'll say a better individual, etc.
For my technical experience, although I claim to know it all
Could barely serve to run the installation disk from AOL;
But still, in matters meaningless and ultimately trivial,
I am the very model of a Usenet individual.
ALL: But still, in matters meaningless and ultimately trivial,
He is the very model of a Usenet individual.
-30-
-----------------------------------------------------------------
FIDONEWS 14-22 Page 28 2 Jun 1997
=================================================================
ADVERTISE YOUR FREE SERVICE/EVENT
=================================================================
New haven, CT USA - 06/01/97 -
Fidonet echos are available for internet users. Smokey's Lair BBS,
formally of Dallas, TX, more recently of New Haven, CT, has been
watching the current trend of disappearing FidoNet BBSes with alarm.
The quality of available echos and conferences on these systems far
outweighs ANYTHING that can be found on the internet. The FidoNet
echos have experts in all fields, have good in depth conversation
without the spamming that is found so often on the net.
In hopes that we can help bring back life to some of the conferences
and echos that are dropping like flies we have made them available to
those of you fidonet users that have lost your local BBSes or just
prefer the ease of use of the internet. It is our hope that you will
once again re-join the FidoNet family.
Here is how it works:
1. You must have an internet connect, be it dial-up, employer network,
or anything else that connects you. If your using a LAN, you must know
how to get through the firewall. I'm sorry we can't help you on that
one.
2. You must have a newsreader. This could be something like Microsoft
netNews, Netscape News, Chameleon, Trumpet, or Free Agent from Forte.
I use Free Agent and find it the best.
3. Find the location in your setup that defines the news server.
Change this to newn.com
4. Connect and let it pick up a listing of all news groups. This can
take 10 or 15 minutes, so be prepared to wait.
5. You can subscribe to any newsgroup, but be aware, the only active
ones are the FidoNet ones. These all start with "fido." and the echo
name.
6. Once you have selected those that you want to read, have at `em.
Please follow the moderators rules for each echo. Remember, in FidoNet
NO ADVERTISING is allowed except where specifically included. This
includes spam (Internet junk mail).
Please, if you are trying to read an echo and find no activity for a
couple days, send me net-mail. This can either be done to Chris Molnar
@ 1:141/635 or cmolnar@newn.com. Most likely I haven't turned on the
echo, but will be happy to do it for you.
A word to echo moderators: We are a FidoNet node, the echos are NOT
being gated to the internet. We are not passing these echos to other
systems, we insist that the users connect to our system to read and
post.
FIDONEWS 14-22 Page 29 2 Jun 1997
A word to the users: We maintain a log that includes your machine
name, host, and internet feed for every article posted. This is an
electronic signature and is yours. We will not tolerate abuse, this
includes spamming. Please do not jeopardize our system, but help us
try and maintain the Fido Family.
If you run an FTC compatible network, and you would like your net
added to this type of distribution please contact us, we will not
charge for this service. Please, however be aware the following rules
apply:
1. We will not place long distance calls to carry your network. You
may however drop mail packets off via FTP. It is your responsibility
to get and receive mail from us. We do not charge for carrying your
network, and we maintain a dedicated internet connect, therefore we
believe that you can maintain the cost of distribution to and from us.
2. We will not carry multiple AKAs. We believe the FidoNet address
structure can easily identify our system and if you want us to make
your network available to internet users, you can adjust.
3. We do not screen users accessing the echos. We do not screen the
messages being sent. We are an information provider and the content of
your network is not our business. This protects us from legal harm.
However, we believe that you as the Network Coordinator are
responsible for following US law when creating and administering your
network. Be it that your network originates outside or inside the
United States as we are proudly a U.S. based system.
Please ask us if you have any questions!
-----------------------------------------------------------------
FIDONEWS 14-22 Page 30 2 Jun 1997
=================================================================
ANSWERS OF THE WEEK
=================================================================
--- Following message extracted from NETMAIL @ 1:18/14 ---
By Christopher Baker on Mon May 26 12:50:54 1997
From: Ralf Mahler @ 2:2433/401
To: Christopher Baker @ 1:18/14
Date: 25 May 97 11:57:11
Subj: old nodelists
Hello Christopher!
=== Cut ===
D:\VAR\FILES\FIDO\HISTORY\NODELIST\1990UV
26.10.93 0.23 27033 0 jun84-1.pcx
26.10.93 0.25 22128 0 jun84-2.pcx
26.10.93 0.27 17951 0 jun84-3.pcx
11.11.94 23.50 8452 0 node1984.328
2.10.94 21.53 10930 0 node1984.342
2.10.94 21.54 10469 0 node1984.363
2.10.94 21.55 12289 0 node1985.004
3.10.86 8.00 93042 0 node1986.276
8.01.88 8.00 223103 0 node1988.008
10.09.88 16.06 319929 0 node1988.253
16.06.89 15.26 440725 0 node1989.167
4.08.89 1.25 464876 0 node1989.216
26.01.90 22.01 525064 0 node1990.026
30.03.90 9.06 584373 0 node1990.089
25.05.90 17.20 636935 0 node1990.145
29.06.90 23.13 654078 0 node1990.180
17.08.90 15.26 690316 0 node1990.229
D:\VAR\FILES\FIDO\HISTORY\NODELIST:
27.12.91 12.00 1144152 0 ndiff_91.zip since day 144
9.09.95 16.21 2168996 0 ndiff_92.zip
9.09.95 16.17 2670637 0 ndiff_93.zip
9.09.95 16.06 3344477 0 ndiff_94.zip
7.01.96 14.48 2872017 0 ndiff_95.zip
1.01.97 9.09 2604931 0 NDIFF_96.ZIP
2.01.92 10.43 362441 0 nlist_91.zip
10.11.94 17.14 416414 0 nlist_92.zip
1.01.93 19.32 597289 0 nlist_93.zip
7.01.94 16.18 795059 0 nlist_94.zip
9.09.95 16.32 1021029 0 nlist_95.zip
6.01.96 15.45 1105455 0 nlist_96.zip
4.01.97 18.52 940509 0 NLIST_97.ZIP
=== Cut ===
These files may be placed on hold - no f'req possible.
CM-System: +49-2131-745559 , but only X.75 (BRI)
FIDONEWS 14-22 Page 31 2 Jun 1997
cheers,
Ralf.
-30-
-----------------------------------------------------------------
FIDONEWS 14-22 Page 32 2 Jun 1997
=================================================================
NOTICES
=================================================================
Future History
3 Jun 1997
2 years since FidoNet had an International Coordinator.
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.
1 Aug 1997
International FidoNet PENPAL [Echo] meeting in Dijon, France
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
FIDONEWS 14-22 Page 33 2 Jun 1997
Future History, please send a note to the FidoNews Editor.
-----------------------------------------------------------------
FIDONEWS 14-22 Page 34 2 Jun 1997
=================================================================
FIDONET SOFTWARE LISTING
=================================================================
Latest Greatest Software Versions
by Peter E. Popovich, 1:363/264
A fairly quiet week around here. Things seems to be settling down into
some sense of order...
-=- 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
GEcho 1.00 T S Bob Seaborn 1:140/12 GECHO
GEcho/Plus 1.11 T C Bob Seaborn 1:140/12 GECHO
GEcho/Pro 1.20 T C Bob Seaborn 1:140/12 GECHO
GIGO 07-14-96 G S Jason Fesler 1:1/141 INFO
GoldED 2.50 O S Len Morgan 1:203/730 GED
GoldED/386 2.50 O S Len Morgan 1:203/730 GEX
GoldED Docs 2.50 O S Len Morgan 1:203/730 GEM
GoldNODE 2.50 O S Len Morgan 1:203/730 GEN
Imail 1.75 T S Michael McCabe 1:1/121 IMAIL
FIDONEWS 14-22 Page 35 2 Jun 1997
ImCrypt 1.04 O G Michiel vd Vlist 2:500/9 IMCRYPT
InfoMail/86 1.21 O F Damian Walker 2:2502/666 INFOMAIL
InfoMail/386 1.21 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.79 B P Christopher Baker 1:374/14 OPUS
O/T-Track 2.66 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
Telegard 3.02 B F Tim Strike 1:259/423 TELEGARD
Terminate 4.00 O S Bo Bendtsen 2:254/261 TERMINATE
Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK
TosScan 1.01 T C JoHo 2:201/330 TSINFO
TransNet 1.00 G S Marc S. Ressl 4:904/72 TN100ALL.ZIP
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
FIDONEWS 14-22 Page 36 2 Jun 1997
CFRoute 0.92 O G C. Fernandez Sanz 2:341/70 CFR
FastEcho 1.45a T S Tobias Burchhardt 2:2448/400 FE2
FleetStreet 1.19 O S Michael Hohner 2:2490/2520 FLEET
GEcho/Pro 1.20 T C Bob Seaborn 1:140/12 GECHO
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.12 P S Mats Wallin 2:201/329 FDAPXW
Windows (32-bit apps):
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
Argus 95 2.62 M S Max Masyutin 2:469/77 ARGUS95
Argus NT 2.62 M S Max Masyutin 2:469/77 ARGUSNT
Argus NT/IP 2.62 M S Max Masyutin 2:469/77 ARGUSIP
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.10 M G Eugene Crosser 2:293/2219 IFMAIL
ifmail-tx ...tx8.2 M G Pablo Saratxaga 2:293/2219 IFMAILTX
ifmail-tx.rpm ...tx8.2 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
FIDONEWS 14-22 Page 37 2 Jun 1997
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
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
----------------------------------------------------------------------
ApplyList 1.00 N F Daniel Roesen 2:2432/1101 APLST100.LZH
BinkleyTerm/ST 3.18pl2 M F Bill Scull 1:363/112 BINKLEY
BTNC 2.00 N G Daniel Roesen 2:2432/1101 BTNC
JetMail 0.99beta T S Joerg Spilker 2:2432/1101 JETMAIL
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
Please send updates and suggestions to: Peter Popovich, 1:363/264
-----------------------------------------------------------------
FIDONEWS 14-22 Page 38 2 Jun 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-22 Page 39 2 Jun 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 13: http://www.smalltalkband.com/st01000.htm
Region 14: http://www.netins.net/showcase/fidonet/
Region 15: http://www.smrtsys.com/region15/ [disappeared?]
Region 16: http://www.tiac.net/users/satins/region16.htm
Region 17: http://www.portal.ca/~awalker/region17.htm
REC17: http://www.westsound.com/ptmudge/
Region 18: http://www.citicom.com/fido.html
Region 19: http://www.compconn.net
============
Zone 2: http://www.z2.fidonet.org
ZEC2: http://fidoftp.paralex.co.uk/zec.htm [shut down?]
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/
FIDONEWS 14-22 Page 40 2 Jun 1997
Region 27: http://telematique.org/ft/r27.htm
Region 29: http://www.rtfm.be/fidonet/ (in French)
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-22 Page 41 2 Jun 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-22 Page 42 2 Jun 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-22 Page 43 2 Jun 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-
-----------------------------------------------------------------
Reference in New Issue View Git Blame Copy Permalink