informis/textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
textfiles/bbs/FIDONET/FIDONEWS/fido1421.nws
root@procul 278a90f7ce Initial commit
2021-04-15 13:31:59 -05:00

1994 lines
88 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 21 26 May 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. |
+----------------------------------------------------------------------+
REMEMBER MEMORIAL DAY AND THOSE WHO GAVE ALL
Table of Contents
1. EDITORIAL ................................................ 1
Chugging right along? .................................... 1
2. LETTERS TO THE EDITOR .................................... 2
FTSC Nominations Re-opened ............................... 2
It can't work response ................................... 4
Looking for FidoNet systems in Miami ..................... 5
3. COLUMNS .................................................. 6
Lock and Load: Guerilla Marketing for BBSes .............. 6
4. GETTING TECHNICAL ........................................ 8
FSC-0071 - Distributed FREQ (DFREQ) Specs ................ 8
FSC-0073 - Encrypted Msg Identification for FidoNet ...... 12
FSC-0074 - Echomail Specification ........................ 14
5. COORDINATORS CORNER ...................................... 23
Nodelist-statistics as seen from Zone-2 for day 143 ...... 23
6. NET HUMOR ................................................ 24
What if Dr. Seuss wrote tech manuals? .................... 24
7. ADVERTISE YOUR FREE SERVICE/EVENT ........................ 25
Announcing the CRICKET_ECHO .............................. 25
Announcing the WRESTLING_CHAT Echo ....................... 25
8. NOTICES .................................................. 26
Future History ........................................... 26
9. FIDONET SOFTWARE LISTING ................................. 28
Latest Greatest Software Versions ........................ 28
10. FIDONEWS PUBLIC-KEY ..................................... 33
And more!
FIDONEWS 14-21 Page 1 26 May 1997
=================================================================
EDITORIAL
=================================================================
Several notices, an answer, a request for Miami FidoNet info, some
technical stuff, a Dr. Seuss parody, nothing negative, nothing
personal, and not too long. [grin]
C.B.
-----------------------------------------------------------------
FIDONEWS 14-21 Page 2 26 May 1997
=================================================================
LETTERS TO THE EDITOR
=================================================================
--- Following message extracted from NETMAIL @ 1:18/14 ---
By Christopher Baker on Sat May 24 12:43:12 1997
From: Bruce Bodger @ 1:170/400
To: fidonews @ 1:1/23
Date: 24 May 97 10:25:54
Subj: FTSC Nominations Re-opened
Chris,
Please publish the below message in the upcoming FidoNews. Thank you.
Submitted to FidoNews this date
by Bruce Bodger
FTSC NOMINATIONS RE-OPENED
Adrian Walker and I have discussed the plans for the FTSC election and
we have decided that for several reasons we would delay the vote until
01 August 97;
1. Both of us are going to be extremely busy, and unable to give this
our full attention for the next few weeks.
2. It is clear to us that there are several more nominations "waiting
in the wings" which missed the earlier nomination period.
3. We will shortly be into the summer vacation period, and delaying
the vote a short while will avoid much of that.
====================
NOMINATIONS REOPENED
====================
Effective immediately, nominations for Standing Members have been
reopened.
For reference, here are the details of the nomination process:
FTSC members are appointed for a two year renewable term. [50 %
of appointments on initial formation of the FTSC shall be for a 3
year renewable term, to ensure continuity of the Committee on
expiry of the terms.]
To be selected as a FTSC member, an individual must be a Fidonet
node, and should be actively involved in Fidonet. Examples
include having put out a Fidonet-related product or having
updated a product in the preceding two years, or having
experience as a Coordinator, Echomail Coordinator or mail or file
FIDONEWS 14-21 Page 3 26 May 1997
Hub.
Standing members may be nominated Fidonet-wide by all of the
following methods:
1. any RC or REC
2. a nominating committee established for the purpose by the
FTSC
3. a nominating committee established for the purpose by the
ZCC
===============
ACTION REQUIRED
===============
Since there is no nominating committee at this stage, those persons
interested in becoming a Standing Member of the FTSC should state
their interest to any currently-serving RC or REC and request that the
RC or REC nominate them either by message in the FTSC_PUBLIC echo, or
by netmail to Bruce Bodger (1:170/400), who is administering the
nomination list.
The closing date for such applications to be an active Standing Member
of the FTSC will be Friday 01 August 1997. At that time a list of all
applicants having been properly nominated will be published, and the
voting process will then be followed as defined in FTA-1001.
================
CURRENT NOMINEES
================
NAME NODE # NOMINATOR NODE # POS'N
Ron Bemis 1:124/1113 Ben Hamilton 1:124/7008 REC19
Bjorn Felten 2:203/208 Mats Wallin 2:201/329 RC20
Rune Johansen 2:210/20 Stein-Ivar Johnsen 2:212/8 RC21
Cristoffer Crusell 2:204/701 Mats Wallin 2:201/329 RC20
Joaquim Homrighausen 2:201/330 Mats Wallin 2:201/329 RC20
Tobias Burchhardt 2:2448/400 Mats Wallin 2:201/329 RC20
Mats Wallin 2:201/329 James Ray 1:124/8002 RC19
Mike Bilow 1:323/107 Jerry Schwartz 1:142/928 RC16
Thomas Waldmann 2:2474/400 Detlef Nick 2:2454/410 RC24
Tom Schlangen 2:2450/10 Detlef Nick 2:2454/410 RC24
Jason Steck 1:285/424 James Ray 1:124/8002 RC19
Carlos Fernandez Sanz 2:341/70 Carlos Hermida 2:348/603 REC34
Colin Turner 2:443/13 Mats Wallin 2:201/329 RC20
Peter Karlsson 2:206/221 Mats Wallin 2:201/329 RC20
Odinn Sorensen 2:236/77 Morten Mertner 2:235/100 RC23
Zorch Frezberg 1:205/0 Ed Georgen 1:2222/258 REC11
Goran Eriksson 2:201/505 Stefan Andersson 2:203/216 REC20
Robert Szarka 1:320/42 Ed Georgen 1:2222/258 REC11
Benjamin Schollnick 1:2613/477 David Moufarrege 1:2613/404 RC13
---ooo000ooo---
FIDONEWS 14-21 Page 4 26 May 1997
-----------------------------------------------------------------
--- Following message extracted from NETMAIL @ 1:18/14 ---
By Christopher Baker on Fri May 23 00:09:09 1997
From: Ivy Iverson @ 1:154/170
To: FidoNews Editor @ 1:18/14
Date: 16 May 97 02:39:24
Subj: It can't work?
* Original to: Clay Tannacore (1:372/4)
Hi, Clay;
I am sitting here reading your letter in FidoNews, and the thought
strikes me that no matter WHAT happens in the politics of FidoNet,
_ALL_ of the private nets - FidoNet, MufoNet and the rest), are very
ill because of a virus. That virus is Internetitus!
I am so damn sick and tired of all the political "campaigning," (read
that as "Mud-slinging"), crap in FN_SYSOP that I dropped the echo. (I
turned it on again, but only because of the INTBBS_WEEK echo which we
are trying to get started, and the International BBS week which is
being planned.)
If we cannot get some publicity for our BBSes and recruit new systems
into the nets, FidoNet and all the rest will become nothing more than
a memory in some oldtimer's mind - a story to be told on some obscure
home page somewhere, a reference in an old book on the history of the
Internet.
When that happens, and we are headed that way just as surely as if the
phone company went out of business, please tell me what will all the
politics, the name calling, the hard feelings, the high blood pressure
of the current election matter?
Have you read the message I posted which started the INTBBS_WEEK idea?
If not, I will be more than happy to send you a copy! From where _I_
sit, the network's political issues won't make a penny's worth of
difference when the last BBS pulls the plug for the last time.
When we, (FidoNet SysOps in several European countries including
Holland), get INTBBS_WEEK on the North American backbone, PLEASE get
it and participate, ok?
I am excited about it and you will be too!
Catch you later... Let's keep the nets alive!
Ivy Iverson
SysOp: Ivy's WALL BBS
1:154/170
-30-
FIDONEWS 14-21 Page 5 26 May 1997
-----------------------------------------------------------------
Date: Sat, 24 May 1997 21:09:34 -0400
From: Richard Pence <mrpence@ix.netcom.com>
To: cbaker84@digital.net
Subject: bbs list
to whom it may concern;
i'm interested in obtaining a list of bulletin boards in the Miami,
FL, area which are in the Fidonet network. any information on updated
lists would be appreciated.
thank you,
richard pence
miami, fl
-----------------------------------------------------------------
FIDONEWS 14-21 Page 6 26 May 1997
=================================================================
COLUMNS
=================================================================
Lock and Load: Guerilla Marketing for BBSes
Robert Parson (1:3822/1)
I had fully intended there to be a column last week. Time grabbed me
by the lapel and wouldn't let go. Which is why I don't envy Editor
Chris Baker. Onward:
The first thing to remember about reporters is that they are not the
enemy.
Yes, the general image of BBSes within the media has been tarnished.
But with proper cleaning that image can be shiny. We've talked about
News Releases, but that's the easy part. The hard part comes when a
reporter calls to interview you.
As you can tell, I put a lot of emphasis on News Releases. Most are
thrown away. But some really do result in news stories and some are
filed away for future reference. Keep sending out those news releases
and you will eventually become The Expert in the field.
At first, you came to the media because you have something you want to
say. But now, they are coming to you because you have something that
they want to know.
Rule number one: Return your calls. I know that sounds rather
obvious, but you'd be amazed at how many news sources don't return
phone calls.
Rule number two: Don't lie. If you get caught, you'll get nailed to
the wall. If you accidentally pass along some incorrect information,
admit it at the first opportunity. Rule number two-and-a-half: Don't
buffalo your way through something you don't know. If you don't know,
refer the reporter to someone who does know. Sure it may mean less
press for you, but that's better than being perceived as a fool.
Rule number three: If the reporter is coming to see you, be neatly
groomed. That doesn't mean you have to wear a suit and tie. Just
don't look like you fell off a train.
If you know and understand those three basic rules, you'll get along
rather well with reporters. But there are some gaps to fill in.
Some interviews will simply be conducted on the phone. A reporter may
call to get some information on a breaking story, or get more
information on the news release you sent him/her.
Be patient. Reporters are representative of the public as a whole.
They use computers at work, they are comfortable with them, but for
the most part they don't go beyond what is required for them to know.
They aren't techno-phobic, but they aren't going out their way to
FIDONEWS 14-21 Page 7 26 May 1997
learn everything they can, either. Chances are the average reporter
knows enough about computer communications to log onto the internet,
grab e-mail, send a reply, and check into a couple news-oriented
Websites. You may have to lead them through some issues. My favorite
analogy is "If you can drive a car, you can drive a computer."
Visual aids are always nifty. TV reporters like lots of movement.
Give them lights blinking on a modem, animated ANSI, messages
scrolling up the screen. Anything that conveys motion. For print
journalists, a few static screen shots and a picture of you doing some
work. If you have a room full of computers, a modem pool or whatever,
they're usually quite happy about having pictures of tech-stuff from
floor to ceiling.
The entire time you are talking with a reporter, maintain your
professional image. You can still be casual, but you are serious
about your work as a Sysop. Don't lose your head on controversial
topics.
Which brings me to this point: If a reporter comes with an agenda
don't get angry with him/her. Acknowledge that agenda. You read that
right. But you have the opportunity to amend the agenda, and possibly
even change it. "Porn on BBSes? Yes. But it is no more prevalent
than it is in the community at large. Here, check out this Missing
Children's Echo..."
Always find some way to cast a negative issue in a positive light.
And never pass up the opportunity to invite someone to call your BBS.
What do BBSes and Newspapers have in common? We'll talk about that in
two weeks.
Got a BBS newsletter? or maybe a comment you want to keep out of
netmail? Send it to:
Robert Parson
2501 Phoenix
Fort Smith, AR USA 72901
Remember: if you want an evaluation of your newsletter please send a
self addressed stamped envelope.
-----------------------------------------------------------------
FIDONEWS 14-21 Page 8 26 May 1997
=================================================================
GETTING TECHNICAL
=================================================================
[This is part of the continuing publication of FidoNet Technical
Standards and proposals for FidoNet History. These documents have
been reformatted to 70 columns where required and any tables or
diagrams may be askew as a result. Node numbers and phone numbers may
be out of date. In this week's group, FSC-0072 has not been published
due to its size [110K]. It is available as FSC-0072.ZIP for freq here
and other sites. FSC-0072 is the HYDRA Protocol Specs.] Ed.
Document: FSC-0071
Version: 001
Date: 17-Jan-1993
Distributed FREQ (DFREQ) Specifications
Bill Auclair, FidoNet 1:141/545
January 17, 1993
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.
Distributed File Requests: What Are They?
------------------------------------------
DFREQ programs are designed to allow both sysops and users
to make Distributed File Requests from other BBS systems
listed in FidoNet<tm> or compatible nodelists. There are
several major differences between Distributed File Request
methodology (hereafter referred to as DFREQ) and existing
FidoNet FREQ and/or file distribution formats.
FidoNet file request technology was designed only for the
direct transmittal of file requests from one system to
another. DFREQ technology allows routing of file requests
from the originating system along a user-configurable
"chain" of systems, ending at the target node. This
methodology allows the setup of no-cost, local routing
paths for file requests between distant systems that would
normally incur long-distance phone charges.
How DFREQs Work
---------------
Distributed File Request methodology can be separated into
2 main parts-- the REQUEST and the ACKNOWLEDGEMENT.
FIDONEWS 14-21 Page 9 26 May 1997
The REQUEST represents the initial stage, in which DFREQ
data from the originating system has not yet reached its
target, and thus carries no accompanying requested files
with it. DFREQ data may be relayed via file or netmail
message attach through any number of intermediate systems
on its way to its ultimate target, which is defined by the
contents of the request file. The path taken by the
request to its target is determined by routing data used by
the DFREQ processors of participating nodes in the chain.
The ACKNOWLEDGEMENT is the result of a processed request,
and is created whether or not the requested files are
available at the target system. The DFREQ information
formerly carried by the request is used to create the
acknowledgement, set its destination back to the
originating system, file- or netmail-attach requested files
(if any) for transmission, and/or provide information as to
why requested file(s) were unavailable at the target
system. Request data is deleted by the target system after
the acknowledgement is created. The path taken by the
acknowledgement back to the originating system again
depends upon the routing configurations of the chain nodes,
but need not be the same as the path previously travelled
by the request.
ASCII text files are used to transport DFREQ information
between nodes. These carrier files are similar in form and
function to the .TIC files used by the TICK<tm> file echo
utility.
The DFREQ process starts when a user generates a DFR file
containing file request information, using the local or
on-line mode of a DFREQ processor.
DFR Files
---------
DFREQ data for the REQUEST stage is transmitted using a
file with a .DFR (Distributed File Request) extension. The
filename is a randomly-generated 8-digit number. DFR files
carry information on the net/node of the originating
system, net/node of the target system, the name of the user
who originated the request, the filenames and descriptions
of the files to be requested, the path travelled by the
request on its way to the target system, and date/time
stamps indicating when the request was processed by each
node in the path. DFRs are transmitted via file or netmail
message attach.
DFA Files
---------
DFREQ data for the ACKNOWLEDGEMENT phase is transmitted
using a file with a .DFA (Distributed File Acknowledgement)
extension. The 8-digit filename of the previously
processed DFR request file is retained. DFA files carry
FIDONEWS 14-21 Page 10 26 May 1997
information on the net/node of the originating system
(formerly the target system in the DFR file), the net/node
of the target system (formerly the originating system in
the DFR file), the name of the user who generated the
request, the filenames and descriptions of successfully
requested files, and the filenames and associated error
information for any unsuccessfully requested or unavailable
files. The full path information from the previously
processed DFR file is retained, and is appended with path
and datestamp information representing the travel of the
DFA file back to its new target, the source of the original
DFREQ. DFAs are transmitted via file or netmail attach.
Error Messages
--------------
When requests for any or all files in a DFREQ can not be
fulfilled for some reason, information as to why the
request was not satisfied is included in the DFA file,
replacing the file descriptions of the unavailable files.
Reasons for file unavailability can include:
o File(s) not found or not available at target system
o OKFile path does not exist on target system
o File(s) not found in inbound area-- node xxx/xxx
DFA files may be appended with error information by any
processing system in the chain back to the originating
node, depending upon where the error condition occurs.
DFR/DFA File Formats
--------------------
DFR and DFA files are ASCII text files that transport DFREQ
information between systems. The DFR file is used during
the REQUEST stage of the transaction. The DFA file is used
during the ACKNOWLEDGEMENT stage of the transaction.
New DFR files are created by the DFREQ processor using its
local or on-line user mode. A random 8-digit numeric
filename and .DFR extension are assigned to the file. File
format for a newly-created DFR is shown below:
Created by GOFER v0.05a, Copyright (C) 1992 by Bill Auclair
Origin 141/545
Requestor Bill Auclair
Target 141/455
File LOGON.LZH 2969 01-17-90 generic telix log-on
script
The first line of the DFR holds information identifying the
program/version used to create it. No empty spaces are
allowed above this line, or between any of the lines that
follow.
FIDONEWS 14-21 Page 11 26 May 1997
The second line of the DFR contains Origin information.
This indicates the net/node number of the system which
generated the DFR.
The third line of the DFR contains Requestor information.
This provides the name of the user who initiated the DFREQ.
The fourth line of the DFR contains Target information.
This indicates the net/node number of the system which is
to receive the DFR and process it to deliver requested
files.
All lines beginning with the "File" identifier contain
filename and description information taken from remote file
lists. Filenames and descriptions must be separated by at
least one space. No empty lines are allowed after File
information.
When a DFR is sent to another system, that system's
net/node information is appended to it, along with date and
time stamp information indicating when the DFR was
processed by the system. This information accompanies the
DFR throughout its entire journey. A DFR file with Path
information appended to it is shown below:
Created by GOFER v0.05a, Copyright (C) 1992 by Bill Auclair
Origin 141/545
Requestor Bill Auclair
Target 141/455
File LOGON.LZH 2969 01-17-90 generic telix log-on
script
Path 141/507 15 Nov 92 07:40:31
Information contained within the DFR file above indicates
it has already traveled through the intermediate system
141/507 on its way from Origin system 141/545 to Target
system 141/455. No empty lines are allowed after Path
information.
When a DFR file reaches its Target destination, it is
converted into a DFA file, and its file requests are
evaluated by the target system. Conversion of DFRs to DFAs
is done by retaining the DFR filename, changing the .DFR
extension to .DFA, and reversing Origin and Target data.
Thus, a DFR file originally named 12345678.DFR from Origin
141/545 for Target 141/455 becomes 12345678.DFA from Origin
141/455 for Target 141/545, as shown below:
Created by GOFER v0.05a, Copyright (C) 1992 by Bill Auclair
Origin 141/455
Requestor Bill Auclair
Target 141/545
File LOGON.LZH 2969 01-17-90 generic telix log-on
script
Path 141/507 15 Nov 92 07:40:31
Path 141/485 15 Nov 92 08:02:55
FIDONEWS 14-21 Page 12 26 May 1997
Path 141/455 15 Nov 92 08:15:23
Path 141/455 15 Nov 92 08:15:25
Note the dual Path lines for the Target system. The first
line represents processing as a DFR, the second represents
processing as a DFA.
The successfully-processed DFA file is returned to the
system that originated the DFREQ, along with the
accompanying requested file. The DFA as received and
processed by the originating system is shown below:
Created by GOFER v0.05a, Copyright (C) 1992 by Bill Auclair
Origin 141/455
Requestor Bill Auclair
Target 141/545
File LOGON.LZH 2969 01-17-90 generic telix log-on
script
Path 141/507 15 Nov 92 07:40:31
Path 141/485 15 Nov 92 08:02:55
Path 141/455 15 Nov 92 08:15:23
Path 141/455 15 Nov 92 08:15:25
Path 141/485 15 Nov 92 10:01:06
Path 141/507 15 Nov 92 10:27:35
Path 141/545 15 Nov 92 10:31:59
If the Target system receiving the DFR file cannot satisfy
the DFREQ, the file description for the unavailable file
contained in the new DFA is replaced with error
information. The DFA is then transmitted back to the
system that originated the DFREQ. Error information
contained within the DFA file as returned to the
originating system is shown below:
Created by GOFER v0.05a, Copyright (C) 1992 by Bill Auclair
Origin 141/455
Requestor Bill Auclair
Target 141/545
File LOGON.LZH !ERR018! File Not Available From
141/455
Path 141/507 15 Nov 92 07:40:31
Path 141/485 15 Nov 92 08:02:55
Path 141/455 15 Nov 92 08:15:23
Path 141/455 15 Nov 92 08:15:25
Path 141/485 15 Nov 92 10:01:06
Path 141/507 15 Nov 92 10:27:35
Path 141/545 15 Nov 92 10:31:59
-30-
-----------------------------------------------------------------
| Document: FSC-0073
| Version: 001
| Date: 28th July 1993
FIDONEWS 14-21 Page 13 26 May 1997
| Author: John Mudge
ENCRYPTED MESSAGE IDENTIFICATION FOR FIDONET
*DRAFT I*
FIDONET TECHNICAL COMMENT
Author : John Mudge
Fido : 1:352/111
Date : 25FEB1993
ABSTRACT:
The following document proposes a standard for encrypted message
identification for Fidonet and Fidonet-based electronic mail
systems.
The proposed standard will assist in encrypted-message detection.
The standard consists of mandatory and suggested portions; however
the term "mandatory" does not mean that any Fidonet product must
implement this standard; it simply means that those that do claim to
implement this standard must do so in the way described.
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.
BACKGROUND:
Currently, Fidonet encrypted messages are not uniquely identified. A
variety of schemes are in place to determine whether a message
received by a Fidonet node has been encrypted, but all of them involve
encryption method specific tests. Current Fido Policy (Policy4)
prohibits routing encrypted material through systems which have not
given specific prior approval. This FSC proposes a method of
identifying such traffic, but makes no effort to determine what action
should be taken after the identification.
IFNA KLUDGE LINES:
Fidonet supports a general method for sending additional information
embedded in a message known as the "IFNA kludge line". This is a line
of text beginning with the ASCII SOH character (^A). The characters
following SOH are a word indicating the type of kludge line, and the
remainder of the line contains information specific to that type.
This standard introduces a new type of kludge line, the ENC.
FORMAT OF A MESSAGE ID - MANDATORY:
The mandatory portion of the ^AENC line shall consist of the Ascii SOH
character immediately followed by the uppercase characters ENC and a
colon and one space.
FIDONEWS 14-21 Page 14 26 May 1997
FORMAT OF A MESSAGE ID - SUGGESTED:
It is suggested, though not required, that the unique part of all
^AENC lines consist of a unique product identifier following the same
format as specified in FSC-0046 for ^APID kludge lines and identifying
the program used for encryption. This product identifier will allow
message editors to invoke the appropriate decryption software.
EXAMPLE:
^AENC: PGP2.1
with PGP21 to be replaced with a two digit hex identifier at such time
as a central product registry exists.
IMPLEMENTATIONS:
As of this writing, several products are being written, notably by
Fredric Rice and GK Pace, to implement this proposal. Examples of
currently available programs are GENMSG V1.30 and PGP-TOSS.
SUMMARY:
As of this date, no public repository exists for encryption/decryption
product registration, but the FTSC is suggested as is the application
form presented in FSC-0022.
I am publishing this information as a Fidonet technical comment in
hopes that other Fidonet products will eventually incorporate all or
part of this standard as well, and that it will eventually form part
of a Fidonet Technical Standard.
CREDITS:
I would like to thank all of the pioneers of Fidonet for making all of
this possible. The ^AENC proposal is the result of the collective
efforts of many of the participants of the Fido PUBLIC_KEYS echo.
Much of the wording and structure for this document I stole from
authors of previous FSC authors. Special thanks go to GK Pace and
Fredric Rice for their ongoing programming efforts in support of
public-key encryption systems.
-30-
-----------------------------------------------------------------
| Document: FSC-0074
| Version: 001
| Date: 28th July 1993
| Author: John Souvestre, David Troendle, Bob Davis, George Peace
|
| FTS-0004.002 -- proposed
FIDONEWS 14-21 Page 15 26 May 1997
EchoMail Specification
June, 1992
This document began as
the Conference Mail System User Manual
By Bob Hartman t/a Spark Software
FidoNet(tm) node 132/101 (currently 1:104/501)
Used with permission
Revision 2:
06 Jun 1991
John Souvestre, David Troendle, Bob Davis
29 Oct 1991
John Souvestre, David Troendle
28 Jan 1992
George Peace
02 Jun 1992
George Peace
ECHOMAIL DEFINED
EchoMail is a technique that permits several nodes on a
network to share a message base. It is similar in concept to
the conferences available on commercial information services
but is most closely related to the Usenet system consisting of
thousands of systems world wide. All systems sharing a given
conference see any messages entered into the conference by any
of the participating systems. This can be implemented in such
a way as to be totally transparent to the users of a
particular system. In fact, they may not even be aware of the
network being used to move their messages about from node to
node!
Unfortunately, EchoMail has disadvantages as well. Many users
who are not educated about EchoMail systems do not realize the
messages transmitted cost MANY sysops (system operators)
money, not just the local sysop. This is an important
consideration in EchoMail and should not be taken lightly. In
a conference with 100 systems participating the cost per
message can be quite high.
BRIEF HISTORY OF ECHOMAIL
In late 1985, Jeff Rush, a Fido sysop in Dallas, wanted a
convenient means of sharing ideas with the other Dallas
sysops. He created a system of programs he called Echomail,
and the Dallas sysops' Conference was born.
Within a short time sysops in other areas began hearing of
this marvelous new gadget and EchoMail took on a life of its
own. Today the FidoNet public network boasts a myriad of
FIDONEWS 14-21 Page 16 26 May 1997
conferences varying in size from a handful of participants to
Sysop conferences with hundreds of participants. It is not
uncommon for a system to carry hundreds or more conferences
and share those conferences with 10 or more nodes.
HOW ECHOMAIL WORKS
Today's EchoMail processing is functionally compatible with
the original EchoMail utilities. In general, the process is:
- A message is entered into a designated area on a FidoNet
compatible system.
- This message is "Exported" along with some 'control
information' to each system "linked" to the conference
through the originating system.
- Each receiving system "Imports" the message into the
proper Conference Mail area.
- The receiving systems then "Export" these messages, along
with additional control information, to each of their own
EchoMail links.
- Return to the import step.
The method is quite simple in general. Of course, following
the steps literally means messages would never stop being
Exported and transmitted to other systems. This obviously
would not be desired. The information contained in the
'control information' section is used to prevent exporting the
same message more than once to a single system.
MESSAGE CONTROL INFORMATION
Control information is associated with each EchoMail message.
This information consists of certain special lines placed
inside the message. These lines are typically inserted
automatically by the program which prepares or processes the
message, not by the person writing it.
In FTS-0001 terminology, these control information lines shall
be inside the "text" field of a "packed message".
Control information lines shall contain only ASCII characters,
from 32 to 126, except the first character of the path line
and as noted elsewhere in this document. This limitation
applies only to control information lines.
Alphabetic characters in required literal strings (AREA,
Origin, SEEN-BY, and PATH) are case-sensitive.
All control information lines shall be terminated with ASCII
character 13 (carriage return).
These required control information lines determine how
FIDONEWS 14-21 Page 17 26 May 1997
EchoMail is handled:
1. Area line
There shall be exactly one area line in an exported message.
The AREA line:
- Shall be the first line of the text and thus shall
immediately follow the packed message header. This
position is "offset 0" of the "text" portion of the
packed message.
- Shall be formatted as:
AREA:CONFERENCE
AREA: is a required five character upper case
literal.
CONFERENCE is the name of the conference. The
conference name is composed of ASCII characters in
the range 33 to 96 and 123 to 126. The conference
name shall be no more than 60 characters in length.
The AREA line is added when a conference is "Exported" to
other systems. It is based upon information found in a
configuration file for the designated message area. This
field is used by receiving systems to "Import" messages into
the correct EchoMail area.
Some implementations insert a Ctrl-A (0x01) immediately
preceding the AREA: literal (^AAREA:CONFERENCE).
Six months after adoption of this document the ^AAREA: format
shall be processed equally with the AREA: format when either
occurs in received packets.
2. Origin Line
There shall be exactly one origin line in a message. It shall
be placed in the message following all user entered
information and immediately before the remaining control
information lines.
The origin line:
- Shall begin with the eleven character literal:
<space>*<space>Origin:<space>
- Is optionally followed by user/system defined data in the
ASCII range 32 to 126.
- Shall end with a FidoNet network address enclosed in
parenthesis:
FIDONEWS 14-21 Page 18 26 May 1997
([<zone>:]<net>/<node>[.<point>][@<domain>])
- Shall be no more than 79 characters long including the
required lead-in and address information.
- Shall be inserted into the message at the originating
system.
The complete line might look like:
* Origin: Conference Mail BBS (1:132/101)
3. Seen-by Lines
Seen-by lines are the focus of EchoMail distribution control
information. They are used to determine which addresses
(systems) have received messages. There can be as many seen-
by lines as required to store the necessary information.
Seen-by lines consist of "SEEN-BY:<space>", followed by a list
of net/node numbers corresponding to the systems which have
received that message. The net/node number of each system to
which a message is exported is added to the seen-by lines at
the time of export.
There shall be exactly one set of seen-by lines in a message.
Seen-by lines:
- Shall follow the origin line.
- Shall begin with the nine character literal:
SEEN-BY:<space>
- Shall contain a list of net/node numbers.
- Shall be no more than 80 characters long including the
required literal.
The complete lines might look like:
SEEN-BY: 104/1 501 132/101 113 136/601 1014/1
SEEN-BY: 1014/2 3
The list of net/node numbers:
- Shall identify at least one address. "Blank" seen-by
lines shall not be transmitted.
- Shall be sorted in ascending net/node order.
- Shall not contain repeated node numbers.
- Shall use only "2D" net/node notation.
- May use short form address notation where a net number is
FIDONEWS 14-21 Page 19 26 May 1997
listed once on any one line. These 2 lines are
equivalent:
SEEN-BY: 104/1 104/501 132/101 132/113 136/601
SEEN-BY: 104/1 501 132/101 113 136/601
Some implementations insert a Ctrl-A (0x01) immediately
preceding the SEEN-BY: literal (^ASEEN-BY:).
Six months after adoption of this document the ^ASEEN-BY:
format shall be processed equally with the SEEN-BY: format
when either occurs in received packets.
4. Path Lines
Path lines identify a list of net/node numbers that processed
a message before it reached the current system. There can be
as many path lines as required to store the necessary
information.
This is different from seen-by lines, in that seen-by lines
list list all systems to which the message has been sent while
path lines list the systems which have processed the message.
There shall be exactly one set of path lines in a message.
Path lines:
- Shall follow seen-by lines.
- Shall be the last line(s) in the text field of a packed
message.
- Shall begin with the seven character literal:
^APATH:<space>
The ^A is a special character which stands for Control-A
(ASCII character 1), and is required at the beginning of
each path line.
- Shall contain a list of net/node numbers.
- Shall be no more than 80 characters long including the
required literal.
The complete path line might look like:
^APATH: 132/101 1014/1
The list of net/node numbers:
- Shall identify at least one net/node number. "Blank"
path lines shall not be transmitted.
- Shall not be sorted. They shall remain in the order
representing the actual "path" along which the message
FIDONEWS 14-21 Page 20 26 May 1997
traveled.
- Shall use only "2D" net/node notation.
- Shall begin with the net/node of the originating system.
- Shall not be deleted during processing. The original
path information shall be maintained from origin to final
destination.
ECHOMAIL TOPOLOGY
The way in which systems link together for a particular
conference is called the "EchoMail Topology." It is important
to know this structure for two reasons:
- It is important to have a topology which is efficient in
the transfer of the EchoMail messages.
- It is important to have a topology which will not cause
systems to see the same messages more than once.
Efficiency can be measured in a number of ways:
- Least time involved for all systems to receive a message
- Least cost for all systems to receive a message
- Fewest phone calls required for all systems to receive a
message.
Users of EchoMail systems have determined (through trial and
error) the best measure of efficiency to be a combination of
all three measurements. Balancing the equation is not
trivial, but some guidelines can be offered:
- Have nodes form "stars" for distribution of EchoMail.
This arrangement has several nodes all receiving their
EchoMail from the same system. In general the systems on
the "outside" of the star poll the system on the
"inside". The system on the "inside" in turn polls other
systems in a similar star configuration to receive the
EchoMail that is being passed on to the "outside"
systems.
- Utilize fully connected polygons with few vertices.
Nodes can be connected in a triangle (A sends to B and C,
B sends to A and C, C sends to A and B) or a fully
connected square (all corners of the square send to all
of the other corners). This method is useful for getting
EchoMail messages to each node as quickly as possible.
All of these efficiency guidelines have to be tempered with
the guidelines dealing with keeping duplicate messages from
being exported. Duplicates will occur in any topology that
forms a closed polygon that is not fully connected. Take for
FIDONEWS 14-21 Page 21 26 May 1997
example the following configuration:
A ----- B
| |
| |
C ----- D
This square is a closed polygon that is not fully connected.
It is capable of generating duplicates:
1. A message is entered on node A.
2. Node A exports the message to node B and node C placing
the seen-by for A, B, and C in the message as it does so.
3. Node B sees that node D is not listed in the seen-by and
exports the message to node D.
4. Node C sees that node D is not listed in the seen-by and
exports the message to node D.
At this point node D has received the same message twice - a
duplicate was generated.
Normally a "dup-ring" will not be as simple as a square.
Generally it will be caused by a system on one end of a long
chain accidentally connecting to a system on the other end of
the chain. This causes the two ends of the chain to become
connected, forming a polygon.
In FidoNet this problem is reduced somewhat by having a
regional EchoMail star distribution architecture that
maintains EchoMail connections within regions of the world.
Within that architecture only a small number of prearranged
systems (regional collection systems) make inter-regional
connections. This architecture, along with multiple daily
connections, results in an efficient topology which typically
allows global distribution within 24 hours.
THE PATH LINE AND TOPOLOGY
The PATH line stores the net/node numbers of each system
having actually processed a message. This information is
useful in correcting the biggest problem encountered by nodes
running an Echomail compatible system - the problem of finding
the cause of duplicate messages. How does the PATH line help
solve this problem? Take the following path line as an
example:
^APATH: 107/6 107/312 132/101
This shows that the message was processed by system 107/6 and
transferred to system 107/312. It further shows system
107/312 transferred the message to 132/101, and 132/101
processed it again. Here's another example:
FIDONEWS 14-21 Page 22 26 May 1997
^APATH: 107/6 107/312 107/528 107/312 132/101
This shows the message having been processed by node 107/312
on more than one occasion. Based upon the earlier description
of the 'information control' fields in Echomail messages, this
identifies an error in processing. This further shows node
107/528 as the node which apparently processed the message
incorrectly. In this case the path line can be used to help
locate the source of duplicate messages or topology problems.
In a conference with many participants it becomes almost
impossible to determine the exact topology used. In these
cases the use of the path line can help a moderator or
distributor of a conference track any possible breakdowns in
the overall topology, while not substantially increasing the
amount of information transmitted. Having this small amount
of information added to each message pays for itself very
quickly when it can be used to help detect a topology problem
causing duplicate messages to be transmitted to each system.
-30-
-----------------------------------------------------------------
FIDONEWS 14-21 Page 23 26 May 1997
=================================================================
COORDINATORS CORNER
=================================================================
Nodelist-statistics as seen from Zone-2 for day 143
By Ward Dossche, 2:292/854
ZC/2
+----+------+------------+------------+------------+------------+--+
|Zone|Nl-115|Nodelist-122|Nodelist-129|Nodelist-136|Nodelist-143|%%|
+----+------+------------+------------+------------+------------+--+
| 1 | 8675| 8519 -156 | 8430 -89 | 8367 -63 | 8277 -90 |31|
| 2 | 15992|15952 -40 |15904 -48 |15879 -25 |15855 -24 |59|
| 3 | 800| 800 0 | 800 0 | 800 0 | 761 -39 | 3|
| 4 | 547| 548 1 | 543 -5 | 543 0 | 543 0 | 2|
| 5 | 87| 87 0 | 87 0 | 87 0 | 87 0 | 0|
| 6 | 1083| 1083 0 | 1083 0 | 1083 0 | 1077 -6 | 4|
+----+------+------------+------------+------------+------------+--+
| 27184|26989 -195 |26847 -142 |26759 -88 |26600 -159 |
+------+------------+------------+------------+------------+
-----------------------------------------------------------------
FIDONEWS 14-21 Page 24 26 May 1997
=================================================================
NET HUMOR
=================================================================
Date: Thu, 08 May 1997 17:44:41 -0700
From: Shari <bluedawg@concentric.net>
Organization: OREGON - USA
To: webheads@softdisk.com
Subject: Dr. Seuss' technical manual
References: <v01530501af97adea1cd0@[129.65.101.1]>
Sender: owner-webheads@softdisk.com
Reply-To: webheads@softdisk.com
---
WHAT IF DR. SEUSS WROTE TECHNICAL MANUALS?
If a packet hits a pocket on a socket on a port,
and the bus is interrupted as a very last resort,
and the address of the memory makes your floppy disk abort,
then the socket packet pocket has an error to report!
If your cursor finds a menu item followed by a dash,
and the double clicking icons put your window in the trash,
and your data is corrupted 'cause the index doesn't hash,
then your situation's hopeless, and your system's gonna crash!!!
If the label on your cable on the gable at your house
says the network is connected to the button on your mouse,
but your packet wants to tunnel to another protocol,
that's repeatedly rejected by the printer down the hall,
and your screen is all distorted by the side effects of gauss,
so your icons in the window are as wavy as a souse,
then may as well reboot and go out with a bang,
'cause as sure as I'm a poet, the sucker's gonna hang!!
When the copy of your floppy's getting sloppy on the disk,
and the microcode instructions cause unnecessary RISC,
then you have to FLASH your memory and you'll want to RAM your ROM.
Quickly turn off your computer and be sure to tell your Mom!!
-----------------------------------------------------------------
FIDONEWS 14-21 Page 25 26 May 1997
=================================================================
ADVERTISE YOUR FREE SERVICE/EVENT
=================================================================
Emanuel Edwards
1:348/963
emanuel@pangea.ca
Hello all Cricket Lovers:
This ad is to inform you that there is a cricket echo now on fidonet.
All Sysops in England, Pakistan, India, Australia,South Africa and
the West Indies that carry fidonet please request the cricket_echo
on your bbs. The echo tag is called CRICKET_ECHO. The cricket_echo
describe all aspects on how the game is played, the latest scores and
upcoming tours and events in the cricket world. Please request the
cricket_echo onto your bbs and let's start chatting about this
beautiful and intersting game.
Thanks you
Emanuel Moderator.
-----------------------------------------------------------------
Emanuel Edwards
1:348/963
emanuel@pangea.ca
Hello all Wrestling Fans:
This ad is to inform you that there is a new wrestling echo on the
fidonet backbone. The echo tag is called WRESTLING_CHAT. Wrestling
Fans in North American and around the world if you want to hear about
all the latest wrestling news and upcoming events this is the echo to
be on. All you sysops request the WRESTLING_CHAT on you BBS. The
Wrestling_chat offer a freedom of speech atmosphere and there are
great wrestling fans on that echo that echo.
-----------------------------------------------------------------
FIDONEWS 14-21 Page 26 26 May 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-21 Page 27 26 May 1997
Future History, please send a note to the FidoNews Editor.
-----------------------------------------------------------------
FIDONEWS 14-21 Page 28 26 May 1997
=================================================================
FIDONET SOFTWARE LISTING
=================================================================
[This is a repeat of the SOF from 1420.] Ed.
Latest Greatest Software Versions
by Peter E. Popovich, 1:363/264
Note: Mid-May, I will phase out the entire "Old Info" 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
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
FIDONEWS 14-21 Page 29 26 May 1997
GoldED Docs 2.50 O S Len Morgan 1:203/730 GEM
GoldNODE 2.50 O S Len Morgan 1:203/730 GEN
Imail 1.75 T S Michael McCabe 1:1/121 IMAIL
ImCrypt 1.04 O G Michiel vd Vlist 2:500/9 IMCRYPT
InfoMail/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
FIDONEWS 14-21 Page 30 26 May 1997
Binkley Docs 2.60 M F Bob Juge 1:1/102 BDOC_260.ZIP
BinkleyTerm 2.60 M F Bob Juge 1:1/102 BOS2_260.ZIP
BinkleyTerm-XE XR4 M F Thomas Waldmann 2:2474/400 BTXE_OS2
CFRoute 0.92 O G C. Fernandez Sanz 2:341/70 CFR
FastEcho 1.45a T S Tobias Burchhardt 2:2448/400 FE2
FleetStreet 1.19 O S Michael Hohner 2:2490/2520 FLEET
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
----------------------------------------------------------------------
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-21 Page 31 26 May 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
----------------------------------------------------------------------
BinkleyTerm/ST 3.18pl2 M F Bill Scull 1:363/112 BINKLEY
JetMail 0.99beta22
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
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
FIDONEWS 14-21 Page 32 26 May 1997
GUS 1.40 TMail 1.21
NodeList Utilities Harvey's Robot 4.10 TosScan 1.00
Name Version HeadEdit 1.18 UFGATE 1.03
-------------------- HLIST 1.09 VPurge 4.09e
EditNL 4.00 ISIS 5.12@ WEdit 2.0@
FDND 1.10 Lola 1.01d WildMail 2.00
MakeNL 2.31 Mosaic 1.00b WMail 2.2
Parselst 1.33 MailBase 4.11a@ WNode 2.1
Prune 1.40 MSG 4.5* XRS 4.99
SysNL 3.14 MsgLnk 1.0c XST 2.3e
XlatList 2.90 MsgMstr 2.03a YUPPIE! 2.00
XlaxNode/Diff 2.53 MsgNum 4.16d ZmailH 1.25
MSGTOSS 1.3 ZSX 2.40
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
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-21 Page 33 26 May 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-21 Page 34 26 May 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://rhub.hex.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-21 Page 35 26 May 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-21 Page 36 26 May 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-21 Page 37 26 May 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-21 Page 38 26 May 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