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

2631 lines
123 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 27 7 July 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. |
+----------------------------------------------------------------------+
ONE YEAR AGO THIS ISSUE! AND DRIVING ON MARS!
Table of Contents
1. EDITORIAL ................................................ 1
One Year Ago, this Issue! ................................ 1
2. GUEST EDITORIAL .......................................... 2
Gulp? .................................................... 2
3. LETTERS TO THE EDITOR .................................... 3
FTSC Chairman retires in office? ......................... 3
How Do I get a Node number in Hong Kong? ................. 3
A remark concerning FSC-0093 ............................. 4
Found it! ................................................ 5
FTPoint in Zone 1 Wanted ................................. 6
Where does FidoNews go in Zone 3? ........................ 7
4. ARTICLES ................................................. 9
FidoSpine Distribution System Pledge ..................... 9
Observational Titbits .................................... 10
5. TRUE STORIES OF FIDONET .................................. 11
A True Story of FidoNet .................................. 11
6. FIDONET HISTORY .......................................... 14
History of Echomail - Part 1 ............................. 14
7. GETTING TECHNICAL ........................................ 27
No more "Getting technical" ? ............................ 27
8. COORDINATORS CORNER ...................................... 35
Nodelist-statistics as seen from Zone-2 for day 185 ...... 35
9. ECHOING .................................................. 36
ELIST Suspended for July ................................. 36
And more!
FIDONEWS 14-27 Page 1 7 Jul 1997
=================================================================
EDITORIAL
=================================================================
This is the Issue number where I took over the Editorial operation of
FidoNews last year. It's STILL fun. [grin]
This is quite a full Issue with lots of Echomail-related stuff and
some odds and ends that came in at the last minute.
One of the items is a note about the resignation of the FTSC Chairman,
David Nugent [who is also ZC3]. This was first reported in several
Sysop Echos and is confirmed here. Nugent is indeed resigning and is
also leaving FidoNet. Along these lines, I sent direct Netmail to each
Zone Coordinator asking for information, comment, and publication
permission for any replies. They will appear here or in subsequent
Issues as they arrive and are released for publication. Nugent advises
that he has a few unpublished Proposals to get out and list updates to
make before his successor takes over the Chairmanship and that will be
done in the next weeks.
Another is a plea for assistance from a fellow in Hong Kong who can't
seem to get a Node number over there. Somebody help him, please.
Speaking of the Comix section, if any .CMX come in that are political
in nature, they will be reassigned to the Guest Editorial [.GUE]
section so as not to confuse anyone. It also puts them up front.
I forgot to add the two new sections mentioned in 1424 to the ARTSPEC
doc. That omission has been corrected and the updated ARTSPEC.DOC has
been hatched into the pipeline for the FIDONEWS file echo and
ARTSPEC.ZIP into the SDS area SOFTDIST for further distribution. The
entire ARTSPEC.DOC will be reprinted next week [due to space
constraints this week] for information. Look for it once a year or
whenever updated. The two, new sections are the .TRU and .FIC sections
for FidoNet-related true stories or fiction. Both ARTSPEC.DOC and
ARTSPEC.ZIP can be file-requested from this system or found on the
FidoNews webpage and many other FidoNet file sources.
And now that we've successfully put a robot rover on the surface of
the planet Mars, maybe someone can tell me why FidoNet still doesn't
have an International Coordinator? [How about that MARS MISSION?!!]
C.B.
-----------------------------------------------------------------
FIDONEWS 14-27 Page 2 7 Jul 1997
=================================================================
GUEST EDITORIAL
=================================================================
---------------------------------------------------------------------
/`. o
.^\ \ \, o o
{ \ / `~~~--__
{ \___----~~' `~~-_ ______ _____
\ FidoSpine / a '~._(_||___)________/___
/ /~~~~-, ,__. , /// __,,,,) Zone 1 Backbone__/\
\/ \/ `~~~; ,---~~-_`~= \ \------o-' \
/ / / /
'._.' _/_/
';|\
(Art stolen from Jack Sargeant)
-----------------------------------------------------------------
FIDONEWS 14-27 Page 3 7 Jul 1997
=================================================================
LETTERS TO THE EDITOR
=================================================================
--- Following message extracted from NET_DEV @ 1:18/14 ---
By Christopher Baker on Fri Jul 04 19:54:57 1997
From: Lisa Gronke
To: Frank Ellermann
Date: 02 Jul 97 14:18:32
Subj: Where O Where is the FTSC_Chair?
27-Jun-97, Frank Ellermann <2:240/5815.1> muttered to Christopher
Baker in the NET_DEV echo:
> BTW, you probably noticed it, 3:3/20 is not more listed, what
> is the true FTSC now planning, elect another chair man ? Just
> curious as always... greets, Frank
Where O Where is the FTSC_Chair?
I sent Internet email to David Nugent, davidn@csource.oz.au, and asked
him.
He said that he resigned as FTSC chair since he is leaving FidoNet at
the end of July. His BBS is already offline due to lack of callers.
He said he informed the other FTSC members of this fact about 3 weeks
ago via the ftsc mailing list, but has gotten no response at all.
He also says the ftsc web page will be disappearing at the end of July
unless he finds a current member of the FTSC who is willing to
maintain it.
Origin: EastSide Data Services (1:105/61)
-30-
-----------------------------------------------------------------
Received: by yonet.org.hk (0.99.970109)
From: any@yonet.org.hk (Chris Tang)
Date: 06 Jul 97 12:10:17 +0800
Subject: fidonet
Organization: YO!Net
To: cbaker84@digital.net
.o[-MAiL-FRoM-AnY-BoX-Of-Chris Tang-tO-cbaker84-]o.
cd> yes. that is what the above means. send me your story and contact
cd> info in an email msg and i will publish it in FidoNews tomorrow.
ok..below are the details. (my English is not good actually :> )
btw, i hope u can give me a copy of fidonews which published
FIDONEWS 14-27 Page 4 7 Jul 1997
this event via any@writeme.com, thanx..
---
Hi, i'm a sysop in Hong Kong, I met a problem of applying a
fidonet node in Zone6 Host700.
A few month before, I have tried to contact 6:700/0 via netmail,
however, his system doesn't receive any netmail at all, I assumed
that his mailer couldn't work properly.
Later, luckily, i found his E-Mail address from fidonet nodelist
and i sent him a E-Mail about apply a fidonet node in Z6H700 with
my system information, he then replied within a day and told me
that he would help me to do so. However, a few weeks later, i
didn't get any reply from him any more. i then got a fidonet
nodelist to see if my node had already inside or not, but it had
no change at all in Z6H700 part of fidonet nodelist. So I tried to
send him the second E-Mail to him about the applying of fidonet
node, he has replied that he would do so. Again, no more reply was
received from him.
Luckily, i read Fidonews and find out some fidonet sysop contact
methods from it for help.
I wanna have a fidonet node because of the international purpose
and the fidonet node is always required if being a bbs product
oversea distro sites in order to prove that my system works
properly. this is why i wanna join fidonet family. :)
Now, i hope i can apply a fidonet node directly from ZC of Zone6
but i can't find his e-mail address (E-Mail is the unique contact
method for me for contacting oversea).
Anyone can help me about this? below are my contact methods.
Name : Chris Tang
E-Mail: any@who.net (text email only)
any@writeme.com (file attach support)
ICQ : 1251490
BBS : AnyWhere Board +852-2672-5505 [Hong Kong]
--
Greetz,
Chris Tang, any@who.net
-= AnyW =-
-30-
-----------------------------------------------------------------
--- Following message extracted from NETMAIL @ 1:18/14 ---
By Christopher Baker on Wed Jul 02 22:59:44 1997
From: Frank Ellermann @ 2:240/5815
FIDONEWS 14-27 Page 5 7 Jul 1997
To: Editor @ 1:1/23
Date: 03 Jul 97 04:18:00
Subj: fsc-0093.let
A remark concerning FSC-0093
by Frank Ellermann, 2:240/5815.1@fidonet.org
Hello Chris...
I don't know how this *.LET submission type is meant to work, but at
least I try to stay within the 70 columns limit. <g> First an idea,
how you could get more replies like this into FidoNews. Just replace
the useless (?) publishing of pages in NEWSCHAT by posting of the
complete articles there. Then whoever wants to answer can simply use
the quote function of his news reader... et voila, a new article !?
Two additions to your publishing of FSC-0093. Reduced seen-by lines
are implemented in IMAIL version 1.85. If some users of this fine
product weren't aware of it until today: Reduced seen-by lines are by
far safer than tiny seen-by lines, because the vital informations to
detect dup-rings automatically are preserved by reduced seen-by lines.
So if you still use tiny seen-by lines today (and you're not by
accident a zonegate :-), then please try reduced seen-by lines.
Second point, it would be quite simple to extend FSC-0093 in a way
that allows interzonal dup-ring detection. Still fully compatible with
FSC-0074 (i.e. FTS-0004) of course, and mostly of interest for
zonegates. Today it's almost impossible to detect multi-zone rings
automatically, but based on the old SPTH-proposal it's possible to
extend FSC-0093 in this direction... However, before I try it, there
should be at least one zonegate (all those internet tunneling nodes,
hi, that's you :-) really interested in using this method, if it's
implemented in e.g. IMAIL or FASTECHO.
"QOFM" to Chris, you probably know, that in practice FidoNews is the
last working "official" glue keeping FidoNet together, don't you ?
Tnx and bye, Frank
-30-
-----------------------------------------------------------------
Got my CRC problems solved...
Anybody with a nodelist later than day 150 punch up
Susana Baratta 4:851/7
The entry for this node contains high ascii characters at the end,
some utils probably do not allow for this, so the CRC comes out
incorrect!
The bad file was NODEDIFF.157 which has a grunged entry. The CRC
calculates correctly if the data type is changed from signed 8-bit
FIDONEWS 14-27 Page 6 7 Jul 1997
(char) to unsigned char for the calculation...
Therefore the CRC error message was correct because there was a
problem, but incorrect because the checksum on the top line is
accurate if you allow for the high-ASCII characters.
I've really enjoyed figuring this out for myself. I've spent a lot of
time testing my routines for CRC calculation, and come to the
conclusion that any nodelist utility really should check a byte at a
time for illegal characters. It may really slow things down, but it's
probably for the best.
L8r,
Brainwave
... Yes, Socrates himself is particularly missed.
--
|Fidonet: Brian Wood 1:362/903@fidonet.org
|Internet: 903!Brian.Wood@river.chattanooga.net
|
| Standard disclaimer: The views of this user are strictly his own.
| River Canyon Rd. BBS <=> Chattanooga OnLine! Gateway to the World.
-30-
-----------------------------------------------------------------
From: "Mikhail Ramendik" <mikhram@dataforce.net>
To: "cbaker84@digital.net" <cbaker84@digital.net>
Date: Mon, 30 Jun 97 21:28:35 -0300
Reply-To: "Mikhail Ramendik" <mikhram@dataforce.net>
Subject: For FidoNews: FTPoint in z1 wanted
This is for Fidonews. Please put it into the appropriate section.
I am Mikhail Ramendik of Moscow, Russia, 2:5020/768.45,
mikhram@dataforce.net
I have a good command of English and want to receive some echos from
the z1 backbone. Notably HOLY_BIBLE and company, HISTORY and
MILHISTORY . Even though some of them do get to z2, they're SLOW!!!
And HOLY_BIBLE is NOT here AFAIK...
What I am searching for is a Point in Zone 1 with Mail transfer via
FTP (or if impossible - via VMODEM). I am a Point since 1993, have
software tuned OK, will never generate dupes and annoy the bossnode.
(Yes I have seen the commercial hub list. I wish I could use such a
hub, but transferring the bucks from Russia is impossible)
If anyone can help me join Z1 please email! Thanks in advance!
----------------
Mikhail Ramendik -mikhram@dataforce.net
FIDONEWS 14-27 Page 7 7 Jul 1997
FidoNet: 2:5020/768.45
Praise be to the Father, the Son and the Holy Spirit
-30-
-----------------------------------------------------------------
--- Following message extracted from NETMAIL @ 1:18/14 ---
By Christopher Baker on Fri Jul 04 19:03:38 1997
From: John Gardeniers @ 3:632/360
To: Editor @ 1:18/14
Date: 28 Jun 97 20:56:50
Subj: Fidowhere.art
Hi Editor,
As I figure it's better in this format than none at all, and I do find
artspec a little off-putting, I've decided to post this to you as a
message. Do with it what you will. :-)
regards,
John
------------------------------------------------------------------
Fidowhere (Where can I get Fidonews?) by John "Fuse" Gardeniers
(3:632/360.70)
In FIDO1425 there was yet another comment about the unavailability of
Fidonews, so I thought I'd share my own experiences in that regard.
When I became a Fido point last late last year one of the things I
looked forward to was getting a regular copy of Fidonews. This had
always been intermittent, to say the least, on various local BBSes.
Indeed, many BBSs around here don't even carry a single issue. :-(
Having obtained lists of the available message and file areas I
immediately proceeded to link to the Nodelist and Fidonews areas.
"Great" I thought, I'll most likely get the first one within a few
days. It was not to be. :-( After a couple of weeks I contacted my
boss to try to find out why the news wasn't arriving.
Not being a reader of it herself, my boss was a little surprised that
Fidonews wasn't arriving at her system either. The system in question
is a major mail hub, not just an end leaf. A few messages here an
there soon revealed that Fidonews wasn't available locally, at least
not via Fidonet. We did learn that it was readily available via
Internet! The idea of having to use the Internet to obtain Fidonet's
newsletter struck me as just a little absurd.
Due to some persistence on the part of my boss we finally had Fidonews
being delivered to these parts via Fidonet itself, as it always should
have been. Am I the only one who finds at strange that so many sysops
FIDONEWS 14-27 Page 8 7 Jul 1997
didn't bother chasing it up? We are in the largest network in the
state, so many systems must have been affected by the unavailability
of the newsletter. I wonder how many sysops currently believe that
Fidonews has ceased to exist.
On a slightly more critical note, the fact that so little effort
appears to be put in by so many people to get a copy at all says quite
a lot about it's value. :-/
-30-
-----------------------------------------------------------------
FIDONEWS 14-27 Page 9 7 Jul 1997
=================================================================
ARTICLES
=================================================================
FidoSpine Distribution System Pledge
1. The FidoSpine Distribution System recognizes all echoes as listed
in the Echolist for June 1, 1997 (ELIST706.*) along with their
first-listed moderator as the Moderator-of-Record.
2. The FidoSpine Distribution System will initially carry all Fidonet
Zone one echoes that appear in the June 1997 echo listing, plus
some that are not. The FidoSpine Distribution System will use it's
own echo distribution list, FIDONET.NOW. The FidoSpine Distribution
System does not require echo listing renewals or minimum traffic
levels for any echo(s).
3. The FidoSpine Distribution System recognizes the Moderator-of-
Record as the "owner" of their echo. As such all moderator requests
for feed cuts are honored, provided that the moderator follows the
path from the 'problem' system and works backwards. Any FidoSpine
Distribution System hub retains the right to not distribute any
echo who's moderator's actions causes too much of a burden on their
system or well being.
4. The FidoSpine Distribution System recognizes the validity of
Fidonet Policy 4.07 in determining the legality and appropriateness
of messages carried in echomail. Since the Moderator-of-Record is
the "owner" of the echo, The FidoSpine Distribution System
recognizes the moderator's responsibility in maintaining the
legality and appropriateness of message traffic in their echo(es).
The FidoSpine Distribution System is not responsible for the
content of echomail traffic.
5. The FidoSpine Distribution System will work toward establishing
SuperHubs in each zone and region. The FidoSpine Distribution
System does not mandate any specific routing scheme, and allows
each zone, region, and net to adopt and use their own methods. The
FidoSpine Distribution System, where netmail and other traffic is
concerned, will use routing charts provided by recognized Fidonet
Coordinators (as indicated in the Fidonet Nodelist).
6. The FidoSpine Distribution System distribution system will not
interfere with any traffic in any echo, aside from eliminating
duplicate messages ("dupes") and adding necessary routing
information in accord with Fidonet Technical Standards.
7. The FidoSpine Distribution System will accept input from any
moderator as to a request to carry his/her echo. We will NOT
require multiple requests from various NEC's and REC's to
'authorize' distribution of any echo. All that is required is that
the moderator have properly established an entry in the current
Echolist, and make a request of the FidoSpine Distribution System
to distribute his/her echo.
8. The FidoSpine Distribution System may, from time to time,
FIDONEWS 14-27 Page 10 7 Jul 1997
establish, and distribute, technical criteria that messages must
meet in order to be carried on FidoSpine. Such criteria may
include, but not be limited to, definitions of character set,
Origin Line length, age of messages, technical specifications of
the SEEN-BY's, the PATH, the tearlines, and assorted control lines.
Bob Seaborn, 1:140/1
Ed Georgen, 1:2222/258
Jerry Gause, 1:3651/9
Jim Balcom, 1:13/25
Peter Rocca, 1:2401/0
-----------------------------------------------------------------
Observational Titbits
by Lee Kindness, 2:259/7
Well, just a couple of observations...
3:3/20, the FTSC Chair alias address is no-longer in the nodelist,
what gives? A number of people have been trying to form a new FTSC
(without an IC) but these guys should perhaps show a bit more common-
sense (use NET_DEV rather than FTSC_PUBLIC due to NET_DEV having
better distribution) and a bit more 'get-up-and-go' (like contact me
about all those FTSC additions/revisions I published in Fidonews a
couple of weeks back). I wonder if we'll ever see an FTSC entry in the
nodelist ever again... Hell, a united world-wide Fidonet is looking
very shakey...
ftp.fidonet.org is now an alias for ftp.paonline.com rather than the
IEEE server it used to be on. Interesting to note that only FSC
documents up to fsc-0090 are on the site (up to fsc-0093 exist on
ftp.blaze.net.au - the 'former' FTSC internet site) while the two
'fta' documents by the would be new FTSC are present...
>From 2:259/7, In dis-united Scotland...
--
Lee Kindness shazze@on.bright.yelly.bowls.com
Fidonet 2:259/7 wangi@earthling.net hufunglun
http://www.scms.rgu.ac.uk/students/cs_yr94/lk
-----------------------------------------------------------------
FIDONEWS 14-27 Page 11 7 Jul 1997
=================================================================
TRUE STORIES OF FIDONET
=================================================================
[This is the inaugural True Story of FidoNet. It's old but it's
true. Send yours today!] Ed.
[In 1989 I was injured on-the-job and had little and then no access
to my FidoNet computer which was at work. The members of my Net at
the time, built me a computer to use at home to operate the one at
work remotely.]
--Original post:
This file is my way of expressing my gratitude to the members
of my Net (FidoNet Net 1:135, SFLorida NET, Miami_FL_USA) for
a holiday gift they presented me in mid-December.
Composed on 5 Jan 89.
A Holiday Ode to Net 135
by Christopher Baker
RC 18 / NC 135
Twas two weeks before Christmas and all thru my house,
my body was aching, I started to grouse.
"If I don't dump this backache and get back to work
my Users and Sysops will think I'm a jerk."
I'd been laid up at home for many a week
and I had no computer through which I could speak.
It's tough to do business without a remote and I'm sure
many NCs thought things I can't quote.
All the while in the background quite unknown to me,
the folks of my own Net were planning a spree.
They talked and they chatted and gathered up parts
to build me a system for home, bless their hearts.
They Netmailed and Echoed and telephoned, too,
deciding just which part was what and from who.
They assembled a system that was based on a Tandy;
with modem and hard drive, I mean, it's a dandy!
I was tired and cranky the night it was due
and had NO idea this dream would come true.
I had pains in my back and a pain in my head
but my wife kept insisting I not go to bed.
It didn't seem normal the way she cajoled.
It wasn't till later she said, "I was told."
So unknown to me I was being prepared
for a real demonstration of how my Net cared.
It was close to eleven P.M. when I said,
FIDONEWS 14-27 Page 12 7 Jul 1997
"I can't stay up longer. I'm going to bed."
Then suddenly and very much to my shock
came a tap on the door and then a loud knock.
"Ho, Ho, Ho!", said a voice not too clear through the door.
"Open up! I have presents for you by the score!"
The door was thrown wide to allow the sprite in
but he wasn't in red; not a hair on his chin.
He was thin as a rail and no Santa was he.
I recognized Peter; our own NEC.
"What the heck's going on?" I exclaimed to the air.
He said, "Just a token to show that we care."
He said nothing else but went straight to his work
and set up the system then he turned with a smirk.
"No more excuses!", he said, "Now, get cracking!"
"Your traffic's piled up and the stuff keeps on stacking!"
I stood there dumbfounded, amazed and confused.
My mind boggled speechless and he seemed amused.
"What? How? Who and why?", I managed to say.
"It's nothing", said he, "now, get back in the fray!"
It wouldn't sink in that such things still take place
that confirm all your faith in the rest of the race.
The best I could do was to stammer my thanks
and then write this poem to honor our ranks.
I still can't believe it and simply must say,
"All the folks in my Net, you made my whole day!"
"I never can thank you enough for this gift."
"Your generous act brings a permanent lift!"
So, all of the rest out in FidoNet land,
keep your faith that our concept continues to stand.
The FidoNet concept of help and of sharing
is here. Look around and you'll see people caring.
It's never too late to put egos aside.
Let go some bygones and take them in stride.
This Network is people and people are kind.
When your urge is to flame them, please keep that in mind.
To all of my Net, I say "Thank you, nth times!"
To the rest of the world who are sick of my rhymes
I say "I hope the New Year will bring you much joy!"
Now, I think I'll stop here and go play with my toy! [grin]
The End
Happy Holidays and Happy New Year to the wacky world of FidoNet!
Christopher Baker
MetroFire, 1:135/14(0), 305-596-8611
FIDONEWS 14-27 Page 13 7 Jul 1997
Miami_FL_USA
SFLorida Net 135, Miami_FL_USA
Roster of Net 135 Santas:
1 RAM-SOFT_Archive_Library, Miami_FL, David_Gilbert & James Gilbert
2 Eclectic_BBS, South_Miami_FL, Tark_Henderson
3 Medical_Software_Exchange, Miami_FL, Richard_Kaplan
4 The_Kendall_BBS, Miami_FL, Mike_Janke
5 CAP-BBS, Miami_FL, Duane_Ellis
6 Dungeons_of_Darkness_OPUS, Miami_FL, Mike_Jones
7 Miami's_First_Fido, Miami_FL, Al_DelaTorre
8 Coral_Gables_Medterm_BBS, Coral_Gables_FL, Mario_Diaz
9 EPICS_Opus, Hialeah_FL, Sandy_Schurtz
10 AMS_Support-Net_135_NEC, Miami_FL, Peter_Adenauer
11 Power_Station, North_Miami_FL, Mike_Lombana
12 Off-Duty_Inc._BBS, Miami_FL, Kathryn_Fanning
20 FrontDoor_Headquarters, Miami_FL, Joaquim_Homrighausen
24 TURBO-Soft, Homestead_FL, David_Kerley
27 Bitsy's_Place, Miami_Beach_FL, Henry_VanLeer
30 SMURFIT_Latin_America_Opus, North_Miami_Beach_FL, Jeff_Wolach
33 Byte_Size_Bits, Homestead_FL, Jean_Prophet & Buddy Prophet
34 The_Jailhouse, North_Miami_FL, Kenny_Star
35 The_Sober_Way_Out, Miami_FL, Robert_Egan
36 Town_Crier_Opus, Miami_Shores_FL, Orville_Bullitt
38 C-Board, Miami_FL, Jack_Bowman
39 The Expressions_BBS, Miami_Springs_FL, Daniel_Johnston
40 The_Cable_Connection, Miami_FL, Jerry_Iovine
41 BBS1-PC!, Miami_FL, John_Theed
43 Key's_Paradise, Key_West_FL, Steve_Froeschke
46 Bullitt_-_80_Opus, North_Miami_FL, Guy_Bullitt
47 MOBS_Opus_Humor_South, North_Miami_FL, Andrew_Adler
48 The_Road_Runner, Hialeah_FL, Luis_Hernandez
88 Chatterbox_BBS, Miami_FL, Marc_Moyantcheff
204 BerkShire_Board, Miami_FL, Bill_Kraski
901 Miami's_Personal_Consultant, Miami_FL, Dave_Steinman
942 wHy_bE_NoRmaL?, Miami_Fl, Tim_LaVan,
990 Friends_of_Dorothy, Miami_FL, Scott_Samet
Thank you all for the fabulous Tandy T1000 w/20 meg hard drive, 1200
bps modem, 384K RAM, floppy drive and completely configured with DOS
and programs! It is a gift I will always cherish and never forget. You
ARE an amazing and generous bunch of people and Sysops!
TTFN.
Chris
-30-
[That was a long time ago but I haven't forgotten that most of the
folks in our net are not rotten.] [grin] Ed.
-----------------------------------------------------------------
FIDONEWS 14-27 Page 14 7 Jul 1997
=================================================================
FIDONET HISTORY
=================================================================
[This an abortive chapter of FidoNet History from 1989. This is the
original EchoPol that was 'ratified' and then revoked by the IC of
the period {David Dodell} as non-representative. With the recent REC
Echomail effort, it might be well to reflect upon that which has not
been enacted for going on ten years after Policy4. It has been
reformatted to 70 columns for FidoNews and the spelling and
punctuation corrected where necessary. The original is available at
1:18/14 for file-request as ECHOPOL.] Ed.
GENERAL ECHOMAIL POLICY 1
April 22nd, 1989
PROLOGUE
This document sets forth policy governing Echomail conferences and
their distribution.
If any item in this policy is in conflict with any existing or
subsequent General FidoNet Policy, then General FidoNet Policy will
be in effect.
This Policy applies to Zone One Backbone Echomail conferences and to
any other conferences for which the Moderator desires it to be
applicable.
Future changes to Echo Policy may be proposed by any FidoNet Sysop
by submitting the proposal to their REC. The REC will then determine
if the proposal should be brought before the rest of the RECs. If an
REC decides not to bring a proposed change before the rest of the
RECs, a message stating why must be sent. If 10% or more of the NCs
and NECs in a region request that a proposal be brought before the
RECs then that proposal must be brought before the RECs.
A majority vote of the Regional Echomail Coordinators is required in
order for a proposal to be formally voted on. If 10% or more of the
NCs and NECs in the Zone request that a proposal be formally voted
on, then that proposal must be formally voted on.
Those eligible to vote on any proposals made by the REC structure
will be the ZEC, RECs, NECs, NCs, RCs and ZC. Only one vote per
person is allowed. Adoption of changes will require a simple
majority of those voting to pass.
In this document, "a simple majority" means more than 50 percent
of those voting. A good faith attempt must be made to make all
potential voters aware that a vote is occurring and make available
all necessary information.
I. HISTORY
FIDONEWS 14-27 Page 15 7 Jul 1997
Echomail consists of the sharing of message bases or conferences
between various independent network addresses. The Echomail concept
started with a series of programs by Jeff Rush. Since the original
implementation, many authors have written programs improving on the
original idea. In spite of worries that the flow of Echomail would
increase Netmail traffic to the point that the Network would
collapse under its own weight, Echomail has been a success. To
simplify the distribution of Echomail, a national Echomail Backbone
formed whose primary purpose is the distribution of Echomail at a
national level. Of recent introduction to the Backbone system has
been the generous contribution of the Echomail Stars. As a result
of the growth of Fidonet and the increase in the volume of Echomail,
it has become necessary to set forth a formal policy governing
Echomail.
II. DEFINITIONS
1. ECHOMAIL: The process of sharing message bases between
independent systems with unique net/node addresses.
2. ECHOMAIL CONFERENCES: An Echomail conference is a message
base of forum design distributed under a specified
conference name dealing with a defined area of interest.
Notable examples include TECH, the National Technical
Conference and COMM, the National Telecommunications
Conference.
3. MODERATED CONFERENCE: A moderated conference is an Echomail
conference for which a moderator has been appointed to
supervise the flow and content of the conference. All
conferences carried on the Backbone must be moderated.
4. SYSOP-ONLY CONFERENCE: A Sysop-Only Conference is one in
which the Moderator has decided that the conference will be
made available only to Sysops and not to users.
5. RESTRICTED DISTRIBUTION CONFERENCES: A restricted
distribution conference is one which is restricted only to
eligible recipients. Notable examples include REGCON, the
Regional Coordinators Conference, COORD, the National
Echomail Coordinators Conference, and MAGICK, a pre-register
Echomail Conference.
6. ZONE ECHOMAIL COORDINATOR (ZEC): This individual is
responsible for coordination of Echomail on a FidoNet Zone
level.
7. REGIONAL ECHOMAIL COORDINATOR (REC): This individual is
responsible for coordination of Echomail within his region.
8. NET ECHOMAIL COORDINATOR (NEC): This individual is
responsible for coordination of Echomail at the Local Net
level.
9. ECHOMAIL Backbone: The Echomail Backbone consists of
FIDONEWS 14-27 Page 16 7 Jul 1997
voluntary members who provide services to enhance the
national distribution of Echomail. The Backbone consists of
nodes which handle a high volume of Echomail traffic and are
responsible for distribution of Echomail down to the
regional level.
10. NATIONAL ECHOMAIL LIST: The National Echomail List
identifies the available national conferences, the
conference moderator and requirements of the specified
conference. The ZEC will appoint the keeper of the National
Echomail List.
11. AUTOMATED CENSORSHIP: The term Automated Censorship refers
to programs which cause messages to be removed from the
intended conference or have their content altered.
12. FIDONET POLICY: The document which governs Fidonet as
adopted by Fidonet. The document as of this writing is
Policy3 and is subject to change. This policy is intended
to become a part of general Fidonet policy. Until it is
incorporated into General Fidonet policy, this document
shall serve to define policy violations occurring in
Echomail.
13. OPEN ACCESS CONFERENCE: This is a non-restricted conference
open to all users who are willing to follow the posted
conference rules.
14. TERMINAL NODE: A system which does not process echomail for
pickup by another system.
III. DUTIES OF ECHOMAIL COORDINATORS
1. GENERAL: It is the duty of the *ECs to make available to
any Fidonet Sysop, any conference which the Sysop is not
prohibited from receiving by not meeting requirements as
mandated by the conference moderator. If for any reason the
*EC does not have access via recognized distribution
channels to a specific conference, they can not be expected
to pass it on. If a *EC fails to make available any
conference to qualified lower distribution levels, this
shall be deemed to have violated the outlined duties of the
position held. Such violation is cause for the removal as
provided by this document. Nothing in this provision
requires that a *EC must import any conference to the extent
of adverse economic impact. It is recommended that cost
sharing arrangements be employed. Where financially
feasible for the supplier any conference on the Backbone
must be made available (other than restricted conferences)
when requested.
An exception is when a *EC cuts a link to end unauthorized
distribution of a conference. In this case, some otherwise
authorized nodes may temporarily lose their link.
FIDONEWS 14-27 Page 17 7 Jul 1997
A *EC shall do everything in their power to insure that:
1. All downstream links are educated as to this
policy.
2. Downstream links know how to properly link into
conferences.
3. Acceptable and unacceptable behavior in echomail
conferences is explained.
4. Downstream links are not engaging in topologies
that increase the risk of duplicate messages.
2. DUTIES OF ZONE ECHOMAIL COORDINATOR: It is the duty of the
ZEC to coordinate the connections between the Echomail
Backbone on both an inter-Zone and intra-Zone level as well
as coordination of inter-regional connections. The ZEC will
coordinate transmission of Echomail and to provide for
routing in a manner that will avoid the transmission of
duplicate messages within the same conference. It is also
the duty of the ZEC to monitor compliance with this policy
on both a national and international basis.
3. DUTIES OF REGIONAL ECHOMAIL COORDINATOR: It is the duty of
the REC to provide for regional Echomail distribution. In
addition, the REC will coordinate any inter-regional cross-
linking of conference feeds with the REC of the
participating region with the direct knowledge of the ZEC.
The REC will provide for transmission and routing of
Echomail within his/her region in a manner to avoid creation
of duplicate messages within the same conference. It is the
duty of the REC to monitor compliance with this policy at a
regional level.
4. DUTIES OF NET ECHOMAIL COORDINATOR: It is the duty of the
NEC to coordinate the intra-net Echomail and to cooperate
with the REC and NECs of other nets to arrange for the
inter-net transmittal of echomail. The REC may require the
NEC to provide links for independent (regional) nodes. The
NEC shall maintain a list of available Echomail Conferences
within the net as well as the requirements of each
Conference area as supplied by the conference moderator
(Echolist). The NEC shall also monitor compliance with this
policy at a net level.
5. DUTIES OF ECHOLIST COORDINATOR: It is the duty of the
Echolist Coordinator to compile and make available a listing
of national and international Echomail conferences and,
optionally, conferences at various local levels. The
content and format of the Echomail listing shall be at the
sole discretion of the Echolist Coordinator, but shall
include the conference name and moderator for each
conference. The Echolist Coordinator shall also maintain a
list of requirements applicable to each listed conference.
6. DUTIES OF ECHOMAIL CONFERENCE MODERATOR: It shall be the
duty of the Echomail Conference Moderator to make in good
faith every reasonable effort to insure that the moderated
FIDONEWS 14-27 Page 18 7 Jul 1997
conference does not distribute or promote illegal activities
or information as defined below in Section V Paragraph 2.
The Moderator shall be responsible for insuring that
messages contained in the conference corresponds to the
conference theme. The Moderator shall report any violations
of this policy to the proper Echomail coordinators and lodge
any appropriate policy complaints as provided for in policy
documents adopted by Fidonet. The Moderator shall post the
conference rules in the conference at least once a month.
The Moderator is to authorize the disconnection of the
conference feed. Any Sysop the moderator believes is
violating policy shall be reported to the offending node's
nearest local echomail coordinator (may be a NEC, REC or in
extreme situations, a ZEC); and the moderator shall formally
authorize the feed to the offending node to be severed. The
conference moderator is the sole judge - subject to review
only by the ZEC (or his delegates) if a complaint is filed
by the banished party. The Moderator may request in direct
written form (netmail) that the *ECs disconnect a node from
the conference when that node refuses to follow the
published conference rules after at least 3 warnings.
Knowingly feeding a conference to a node that has been
severed by the Moderator is considered a violation of this
echomail policy and is subject to suspension. The length of
this suspension will be determined by a joint decision of
the conference moderator and the nearest local echo
coordinator of the node illegally feeding the conference to
the original offending node or point.
Echo conference complaints from a Sysop should be filed at
the net level (NEC) or if the complaining party is an
independent node then with their REC. The NEC or REC
receiving such a complaint must take action in accordance
with the provisions of this echomail policy.
For severe or chronic infractions, the NEC, REC, or ZEC may
file a complaint under general Fidonet policy for
excessively annoying behavior.
IV. APPOINTMENT AND ELECTION OF ECHOMAIL COORDINATORS AND
MODERATORS.
1. GRANDFATHER CLAUSE: Those Zone, Regional, and Net Echomail
Coordinators and Echomail Coordinators currently holding
these positions as of the date of acceptance of this
Echomail Policy shall continue to service in said capacity
until resignation or replacement under this policy.
2. ELECTION OF ZONE ECHOMAIL COORDINATOR: The ZEC shall be
elected as follows:
a) upon resignation or replacement of the existing ZEC,
the FidoNet Zone Coordinator (ZC) shall nominate at
least five individuals to be voted upon.
FIDONEWS 14-27 Page 19 7 Jul 1997
b) 10 days after the nominees are selected, an election
shall be held. The ZEC will be elected by a simple
majority of IC, ZC, RCs, NCs, RECs, and NECs in their
Fidonet zone. An individual holding more than one
position can only cast one vote. That is, if an
individual is both a NC and a NEC, they may cast only
one vote.
3. ELECTION OF REGIONAL ECHOMAIL COORDINATOR: The REC shall be
elected as follows:
a) upon resignation or replacement of an existing REC,
the ZEC shall nominate at least 3 individuals for
election.
b) 10 days after the nominees are selected, an election
shall be held. The REC will be elected by a simple
majority of the RC, NCs, and NECs in their FidoNet
Region. An individual holding more than one position
may only cast one vote.
4. NET ECHOMAIL COORDINATOR: The NEC shall be appointed by the
FidoNet Net Coordinator (NC) or in such alternative manner
as determined by the NC. If a NEC is not appointed within
30 days, the REC will appoint the NEC.
5. REMOVAL OF A *EC: A *EC may be removed from their position
by a simple majority of those allowed to vote for their
successor. For a NEC, the members of the Net may vote by
simple majority to remove the NEC. The position directly
above (in the *EC structure) will oversee the recall
election in the same manner as prescribed for electing
successors.
A *EC may only be subject to recall for failure to properly
carry out their duties described above, or if they are no
longer a member of Fidonet. A promise of 'free' echomail
delivery from another source is *not* considered an
acceptable reason for recall.
A *EC maybe removed by the level above for continued
violations of policy or for gross misconduct.
6. RECOGNITION OF CONFERENCES: The *EC corresponding to the
appropriate level recognizes a conference at his level.
Examples: The NEC recognizes a conference as local. The REC
recognizes a conference to be regional. A ZEC recognizes a
conference to be zonal.
7. REMOVAL OF AN ECHOMAIL CONFERENCE MODERATOR: An Echomail
Conference Moderator may be removed from their position by a
three fourths (3/4) vote of the *EC structure voting. This
vote must be carried out in a fair and decent manner while
giving at least ten (10) days notice to the entire *EC
structure of the upcoming vote. The ZEC shall notify the
RECs who in turn shall notify the NECs in their region of
FIDONEWS 14-27 Page 20 7 Jul 1997
any upcoming vote. Notice must be given via NetMail.
Additional postings in such conferences as COORD and
regional conferences are encouraged.
An Echomail Conference Moderator may only be subject to
recall for failure to properly carry out their duties
described above or continued pre-meditated violation of this
documents section V. Statement of Policies as seen below.
Failing to perform the above duties of a conference
moderator for a period of 3 or more months and/or failing to
designate a proxy in his absence shall be in violation of
this policy and be subject to recall. A vote may only be
callable by the ZEC (or his delegate). This delegate should
not be from the region or net of the affected conference
moderator.
Membership in Fidonet need not be a paramount issue, but is
highly recommended.
V. STATEMENT OF POLICIES
1. BASIC ECHOMAIL POLICY: The basic policy of Echomail is to
promote communication in Echomail Conferences in a lawful,
friendly manner consistent with the general principles of
FidoNet.
2. PROHIBITION ON ILLEGAL ACTIVITIES: Any Node which knowingly
distributes or allows to be entered into echomail
conferences any messages containing or promoting illegal
activities or information shall be deemed to have violated
general FidoNet policy as being excessively annoying. As
used in this paragraph, "illegal activities" includes
activities which are a violation of civil law as well as
activities which would result in criminal prosecution.
3. AUTOMATED CENSORSHIP: The use of Automated Censorship in
the passing or distribution of echomail will be considered a
violation of this policy and will not be tolerated.
Disciplinary action will be as referred to in General
Fidonet policy as being excessively annoying.
An exception to this provision shall be the deletion and not
censorship of messages by any Sysop which may lead to legal
action against that Sysop.
No echomail shall be modified in any manner which could
potentially cause duplicates.
4. INTER-NETWORK CONFERENCES: Inter-Net conferences shall
conform to general Fidonet policy as well as the provisions
of this policy document in addition to any foreign network's
provisions. Conferences which originate outside of FidoNet
must be designated as such in the list of conferences kept
by the Echolist Coordinator.
FIDONEWS 14-27 Page 21 7 Jul 1997
5. CHARGING FOR DISTRIBUTION: Any entity which makes a profit
from the distribution (passing from system to system) of
echomail shall be deemed to be excessively annoying and in
violation of Fidonet policy subject to enforcement under
existing Fidonet policy. Profit as defined in this
paragraph is the charging for echomail distribution that
exceeds actual cost to obtain and distribute the Echomail
over a sustained period. The cost of the equipment used to
obtain and distribute echomail may only be recovered on a
strictly voluntary basis. A Sysop that charges users for
access to their BBS shall NOT be in violation of this
paragraph.
Implementation of cost recovery plans may vary greatly. In
general cost recovery plans should not be overly
restrictive.
6. RESTRICTED DISTRIBUTION CONFERENCES: Participating Nodes
shall honor and support the restrictions placed upon
restricted distribution conferences. Violation of this
restriction by individual nodes and points shall be a
violation of this echomail policy and result in suspension
of the violated echo in accordance with the above paragraph
in Section III Duties of the Echomail Conference Moderators.
A SYSOP only conference shall be made available only to the
Sysops or Co-Sysops of Fidonet or other nets with which
inter-net conferences exist.
A violation of the restrictions placed on a RESTRICTED
DISTRIBUTION CONFERENCE will be a violation of this policy
if and only if the moderator has posted and specified the
restrictions governing the conference.
7. PATHLINE OPTION: The PATHline (as defined in FTS-0004),
originally implemented by SEA in the MGM package, is
recommended for all nodes. If your current Echomail
scanner supports the pathline you should enable it. While
the pathline does not eliminate duplicate messages, it can
be a very useful tool in determining where a topology
problem exists.
Systems operating as Echomail Stars, Backbone nodes, or
Echomail Hubs must implement the PATHline option (as defined
in FTS-0004 within 30 days of adoption of this policy.
Since these system are operating beyond the scope of the
typical FidoNet system, they are required to implement
features that are otherwise optional.
8. SEEN-BY LINE: Under the current technology and topology
(the routing structure of echomail), SEEN-BY lines play an
important part in reducing duplicate messages. Tiny SEEN-
BYs will not be allowed until the respective ZECs feel
topology will allow their use. Nor will the stripping of
SEEN-BYs (except Zone-Gates and Inter-Network EchoGates) be
allowed unless approved by the ZEC.
FIDONEWS 14-27 Page 22 7 Jul 1997
Violation of the above shall be excessively annoying
behavior enforceable under general Fidonet policy. Zone-
Gates and Inter-Network EchoGates SHOULD strip the SEEN-BYs
of the exporting Zone or Network to reduce addressing
conflicts.
9. COUNTERFEIT MESSAGES: Entering or knowingly distributing
counterfeit messages shall be considered excessively
annoying and a violation of Fidonet policy enforceable under
the terms of Fidonet policy. As used in this paragraph, a
counterfeit message is defined as any message entered using
another person's name, handle or node address with the
intent of deceiving others about the true author of the
message. No handles shall be used to enter messages to
knowingly provoke, inflame, or upset participants in a
conference with the purpose of deceiving others about the
true identity of the author.
10. SYSOP'S RESPONSIBILITY: It is the responsibility of each
Sysop to make every reasonable effort to assure that the
users on his board conform to the provisions of this policy
document. A Sysop may be held responsible for the acts of
his users unless the Sysop can show that a reasonable
attempt was made to conform to this policy document.
11. ECHOMAIL SOFTWARE: Echomail software which does not conform
to the minimum acceptable standards as defined by the
Fidonet Technical Standards Committee (FTSC) shall lead to
disciplinary action as described previously in this
document.
12. HOST ROUTING OF ECHOMAIL: Host routing of Echomail without
the prior consent of both the Sending and Receiving Hosts
shall lead to disciplinary action as described previously in
this document. See Section III.
13. INTER-NETWORK CONFERENCES: It is the general policy of
Fidonet to encourage the development of INTER-NETWORK
CONFERENCES. It shall be the duty of those providing the
INTER-NETWORK CONFERENCE links to remove foreign net
distribution identifiers which will adversely effect the
distribution of the Echomail Conference while in Fidonet.
The INTER-NETWORK CONFERENCE links maintained in Fidonet
shall be operated in a manner not to interfere with the
foreign network's distribution of Echomail. INTER-NETWORK
CONFERENCE links maintained in FidoNet must also conform to
General FidoNet Policy.
14. DEFAMATORY POSTING: The posting of any DEFAMATORY MESSAGE
other than in conferences dedicated to this purpose (i.e.
FLAME) shall lead to disciplinary action as described
previously in this document. See Section III. The posting
of substantiated facts shall not be considered a violation
under this section.
15. ADDING OR REMOVING CONFERENCES FROM THE Backbone: A
FIDONEWS 14-27 Page 23 7 Jul 1997
conference may be added to the Backbone only at the request
of the RECOGNIZED Conference Moderator. A conference must
be registered with the Echolist Coordinator before it can be
added to the Backbone.
A conference may be removed from the Backbone by lack of
traffic. A committee composed of the ZEC and 4 RECs shall
review the status of backbone echos every 3 months. At
which time those echos which have not maintained a minimum
10 messages a week over the preceding 3 months will be noted
and their Conference moderators will be contacted. These
conferences will be given 1 months to improve their traffic
or be withdrawn from Fidonet backbone distribution. The
recognized conference moderator may request removal of their
conference from the Fidonet backbone distribution at their
discretion.
16. TOPOLOGY and DUPLICATE MESSAGES: Cross Regional links should
be avoided as they increase the risk of improper linking and
generation of duplicate messages. Cross Regional links may
only be established with the knowledge of the REC in both
regions. The REC must be notified prior to or at the time
of the link being established. If an REC determines that a
cross regional link is contributing to the creation of
duplicate messages, the REC may request that the link be
terminated.
The use of the PATHline option is required for all out of
region links.
If a sysop has a prior history of creating duplicate
messages because of out of region links, the REC may require
prior notification and approval before an out of region link
can be established.
Cross Regional links are permitted without notification if
one of those systems is a dead-end. Should the status of
this link change, then notification is required.
Each REC will do their best to make available high speed
hubs, out of state hubs, PC Pursuit hubs, etc., to
facilitate the low cost, efficient movement of mail within
their respective Region.
Any Sysop who willfully and knowingly establishes links that
either create duplicate loops (topology that creates
circular feeds) or who refuses to break such links upon
request by their NEC, REC, or ZEC shall be subject to
disciplinary action as described previously in this
document. See Section III.
17. MESSAGE STANDARDS: Until the adoption of a superseding
standard by the Fidonet Technical Standards Committee, the
following Echomail message standards are recommended:
a) Eight-bit characters (ASCII 128-255) and non-
FIDONEWS 14-27 Page 24 7 Jul 1997
printing low-order codes (ASCII 2-31) are prohibited,
except the use of 8Dh (soft <CR> character) per FTS-
0004. This is not intended to discourage participation
of foreign zones or networks, which may permit said
characters. Any echomail processor should pass
information exactly as it was received, without
stripping any non-standard characters.
b) Origin lines should be limited to 79 characters
including the required ending of a proper network
address (i.e. Zone:Net/Node.Point with zone and point
being optional).
c) Tear lines should be limited to 35 characters
including the required "---" lead-in. These should
only contain packer or editor program identification.
Tear lines for message editors are discouraged. If an
editor adds a tear line, it should also add an origin
line to avoid multiple tear lines.
d) "Extra" origin lines (ZoneGating) are limited to
essential information only. This consists of the
required lead-in plus the network name "Gateway" and
optionally the software ID followed by a Zone:Net/Node
address.
Example:
" * Origin: FidoNet Gateway (TComm 88:372/666)"
e) SEEN-BY addresses should be in sorted order.
Multiple AKA's are not allowed in SEEN-BY lines unless
you have more than one address which processes mail.
Or for one month during change of an existing address
(to avoid duplicates to the previous address). Node 0
addresses should not be used for echomail distribution.
f) All current FTSC specifications must be followed.
VI. ENFORCEMENT
Enforcement of this policy document shall be under the
provisions of General FidoNet policy. Complaints concerning
Echomail violations defined under this policy may be filed
by the aggrieved individual, the conference moderator or by
any level of Echomail Coordinator to the appropriate *C
level. All complaints made pursuant to this policy must be
made within 60 days of the date of occurrence or discovery.
Complaints shall be filed under the provisions of General
Fidonet Policy, with a copy to the respective *EC.
Enforcement is immediate, with any currently existing
software allowed 60 days to conform (from the date EchoPol1
goes into effect). A 30-day extension may be granted solely
at the discretion of the ZEC if efforts to bring about
FIDONEWS 14-27 Page 25 7 Jul 1997
compliance are clear. Continued use of aberrant software
after this period shall be deemed excessively annoying.
VII. ADOPTION OF POLICY
1. ADOPTION: This policy shall become effective upon
ratification by a simple majority of those voting. Those
eligible to vote shall be the IC, ZCs, RCs, NCs, ZECs, RECs,
and NECs. Those individuals holding more than one position
can cast only one vote.
2. GRANDFATHER CLAUSE: Within 60 days of adoption of this
policy, moderators shall be appointed for all existing
Echomail Conferences which do not now have a moderator.
Moderators shall be appointed by the ZEC from those
volunteering as moderator or if no volunteer is available
then the ZEC shall request and appoint a moderator for the
conference. In the case where more than one individual
claims to be the conference moderator and no agreement can
be reached, the ZEC may order the conference retired and ban
the further use of the specific conference name. Failure of
the individuals to retire the conference name shall be
deemed excessively annoying behavior.
VI. BACKBONE STRUCTURE
This section is for information purposes only. It gives a
plain English description of the current structure and
operation of the Backbone. The ZEC may change this
structure without amending this document.
At the top of the Echomail distribution network, there are
systems commonly called Stars. These systems are usually
dedicated to passing Echomail. The stars operate at the
discretion and direction of the ZEC. At the time of this
writing there are 3 stars, each has a backup system/plan in
the event of a failure. In general, the Stars link to one
another and feed the RECs.
The RECs are then responsible for distribution of the
echomail within their Region. Normally, the REC will feed
the NECs in that region.
The NEC is responsible for distribution of Echomail to the
individual Sysops within a net.
Note that the RECs and NECs can appoint Hubs to help in the
distribution of Echomail. That is, they do not have to
directly feed the lower level.
This is the distribution GOAL. Because of less expensive
phone rates and other reasons, this distribution method is
not followed exactly. Any change to the above requires
agreement of the *EC's involved. All *ECs will use all the
FIDONEWS 14-27 Page 26 7 Jul 1997
tools at their disposal, such as hubs, high speed modems,
ROA, Wide Area Calling plans, PC Pursuit, corporate
sponsorship, etc., to provide fast, efficient, and cost
effective movement of echomail.
Echopol Committee
Mike Ratledge
Norm Henke
Rick McWilliams
Barry Shatswell
-30-
[This may give the clamoring newbies and Echomail weenies an idea
where some of the wacky ideas concerning Echomail came from. With
something to compare it to, let's see them come up with one that
makes sense in 1997.] [fnord]
[And, folks, when you write these things, PLEASE DON'T right justify
them. All that white space is a real pain to remove. And chip in
for a spell-checker.] Ed.
-----------------------------------------------------------------
FIDONEWS 14-27 Page 27 7 Jul 1997
=================================================================
GETTING TECHNICAL
=================================================================
No more "Getting technical" ?
by Frank Ellermann, 2:240/5815.1
I hate the idea, that now after all old FTSC documents the "Getting
technical" corner could vanish from FidoNews. And there are lots of
other interesting technical documents, which should be part of the
FTSC library. So when my time allows it, I'll submit some texts I'm
aware of. The first one is easy, a FSC proposal lost somewhere in
cyber space between David Nugent and me... Fortunately, because here
is the newest third edition: Z2C approved X2C and X2S as user flags in
zone 2... :-)
Document: FSC-????
| Version: 003
| Date: 03 July, 1997
Zone 2 nodelist flags
Frank Ellermann, 2:240/5815.1
Introduction
------------
This document informs about known differences of FidoNet zone 2
nodelist flags from FTS-0005.003. The ultimate sources for these
informations are the current zone 2 nodelist epilog and the setup
for flag corrections at Z2C, but it may be difficult to get these
sources for readers in other zones.
FTS-0005 flags
--------------
The following flags are used as specified in FTS-0005.003:
CM Node accepts mail 24 hours a day
MO Node does not accept human callers
LO Node accepts calls only from valid listed node numbers
in the current FidoNet nodelist
V21 ITU-T V21 300 bps full duplex
V22 ITU-T V22 1200 bps full duplex
In zone 2 a value of 1200 in the former "baud rate" field implies
V22. Today only two nodes not supporting at least V22bis or ISDN
still exist in the zone 2 segment, therefore the flags V21 and V22
are obsolescent. Both flags should be dropped from FTS-0005.
V29 ITU-T V29 9600 bps half duplex
V33 ITU-T V33
V33 cannot be used in connecting Fido nodes over public dial-up
lines and is most probably a historical error in FTS-0005. This
flag should be removed from FTS-0005 a.s.a.p. A similar argument
is applicable on V29, and few nodes flagging V29 today all support
FIDONEWS 14-27 Page 28 7 Jul 1997
at least V32. The next version of FTS-0005 should drop V29.
V32 ITU-T V32 9600 bps full duplex
-> V32B ITU-T V32bis 14400 bps full duplex (implies V32)
V34 ITU-T V34 28800 bps full duplex
FTS-0005 specifies V32b and V42b (capital V and small b), current
nodelist practice in FidoNet shows all combinations of small and
capital letters for flags. This was no problem before FSC-0062
introduced case-sensitive flags. In zone 2 all old flags except
from FSC-0062 flags are upper case, and a NODEDIFF changing this
convention would be annoying. The best solution is to stick to the
current practice and treat all old flags as case-insensitive.
H96 Hayes V9600
HST USR Courier HST up to 9600 (implies MNP)
H14 USR Courier HST up to 14400 (implies HST)
-> H16 USR Courier HST up to 16800 (implies H14 and V42B)
MAX Microcom AX/96xx series
PEP Packet Ensemble Protocol
CSP Compucom Speedmodem
-> ZYX Zyxel series 16800 bps (implies V32B and V42B)
-> V32T V.32 Terbo 19200 bps (implies V32B)
VFC V.Fast Class 28800 bps
If a flag directly or indirectly implies other flags, then these
other flags are not shown in a nodelist entry, because this would
be redundant. Unfortunately the rules for redundancies in zone 2
and FTS-0005 are different. Zone 2 continued to avoid redundancy
with most "new" flags, but FTS-0005.003 specified no redundancies
for "new" flags like ZYX, H16, V32T, or VFC. "New" flags in this
context are flags approved by FidoNet International Coordinators
since 1989, when FTS-0005.TXT, the predecessor of FTS-0005.003, was
published.
For details see the chapter "implications" below, for now only
note, that in zone 2 H16 implies V42B, ZYX implies V32B and V42B,
and V32T implies V32B.
Zone 1 and zone 2 have introduced a user flag Z19 approved by the
corresponding Zone Coordinator. User flags are discussed later,
for now only note, that in zone 2 ZYX is specified as Zyxel 16k8,
while FTS-0005.003 not knowing Z19 specifies ZYX as generic flag
for all Zyxel protocol speeds.
| Today there is no more node in FidoNet still flagging MAX, this
flag is obsolete and should be dropped from FTS-0005. The flags
HST, H14, and CSP should be marked as obsolescent.
MNP Microcom Networking Protocol error correction
V42 ITU-T LAP-M error correction w/fallback to MNP 1-4
-> V42B ITU-T LAP-M error correction w/fallback to MNP 1-5
As mentioned above FTS-0005 specifies V42b (capital V, small b).
In zone 2 all case-insensitive flags are listed in upper case.
FIDONEWS 14-27 Page 29 7 Jul 1997
The next version of FTS-0005 will probably adopt the better V42B
and MNP definitions of the zone 3 nodelist epilog. FTS-0005.003
specifies an implication of V42 by V42B, but the exact meaning of
the flag MNP is unclear. Most probably this flag was meant to
indicate support of MNP 1-4, and in this sense V42B implies MNP:
MNP Microcom Networking Protocol 1-4 error correction
V42 ITU-T LAP-M error correction w/fallback to MNP 1-4
V42B ITU-T V.42 LAP-M plus V.42bis BTLZ data compression
In zone 2 MNP is considered as redundant, if V42B is flagged or
implied by other flags like H16, ZYX, or Z19.
| MN No compression supported in insecure inbound
XA Bark and WaZOO file/update requests
XB Bark file/update requests, WaZOO file requests
XC Bark file requests, WaZOO file/update requests
XP Bark file/update requests
XR Bark and WaZOO file requests
XW WaZOO file requests
XX WaZOO file/update requests
These flags are equivalent in FTS-0005 and in the zone 2 segment.
Gx..x Gateway to domain 'x..x'
Valid values for this flag are assigned by the Fido International
Coordinator, FTS-0005.003 explicitly mentions GUUCP. In zone 2
only GUUCP gateways are flagged.
#01 Zone 5 mail hour (01:00 - 02:00 UTC) w/ Bell 212A
#02 Zone 2 mail hour (02:30 - 03:30 UTC) w/ Bell 212A
-> #08 Zone 4 mail hour (08:00 - 09:00 UTC) w/ Bell 212A
#09 Zone 1 mail hour (09:00 - 10:00 UTC) w/ Bell 212A
#18 Zone 3 mail hour (18:00 - 19:00 UTC) w/ Bell 212A
#20 Zone 6 mail hour (20:00 - 21:00 UTC) w/ Bell 212A
The variants !01, !02, !08, !09, !18, and !20 indicate missing Bell
212A support. In zone 2 #02 or !02 would be obviously redundant.
Today less than five 1200 modems (V22 or Bell 212A) are listed.
A future version of FTS-0005 should drop !mn variants together with
V21 and V22 flags.
Further most non-CM systems flagging #mn or !mn today probably want
to show additional online times instead of additional mail hours.
As soon as FSC-0062 flags have been approved by the IC or adopted
as FTS by the FTSC, the following version of FTS-0005 should mark
#mn as obsolescent and recommend the more flexible FSC-0062 flags
(see below).
User flags
----------
An example for one of several problems in zone 2 with user flags:
FIDONEWS 14-27 Page 30 7 Jul 1997
...,U,Z19,V110H,V120L,V120H,X75,ENC,NEC
These flags indicate a modern Zyxel ISDN-modem and two additional
user flags ENC and NEC. This possible user flags string contains
34 characters, but at most 32 characters are allowed in FTS-0005.
...,U,Z19,V110L,V110H,X75,ISDNA,ISDNB,ISDNC
During the period for the replacement of old by new ISDN flags
(several months !) many nodes listed both old and new flags for
maximal compatibility, and no problems with nodelist compilers
or mailers caused by too long user flags strings were reported.
Therefore the length limit in FTS-0005 is probably unnecessary
and at least inconsequent: Other nodelist fields like the system
name are unlimited, so why only restrict the user flags string? To
help developers an upper limit of e.g. 255 characters for a
nodelist line and 63 characters for fields 3 to 6 would be more
useful.
The next problem with user flag strings as specified in FTS-0005 is
their introduction by the letter U with no comma following:
Nodelist compilers could parse ...,UISDN,USR in user flags ISDN and
USR. But USR cannot be approved as "real" flag, because the
combination ...,USR,UISDN would then be parsed in SR and UISDN.
Other side effects of the FTS-0005 specification are additional
difficulties in finding flags. Almost all flags are separated by a
comma, only the first user flag can be an exception to this simple
rule. If the order of user flags has no meaning, then...
...,UV120L,V120H
...,UV120H,V120L
... are equivalent. A "simple" solution of this problem could be
to treat UV120L as synonym for V120L, and UV120H as synonym for
V120H. Similar problems show up, if user flags are counted, etc.
Obviously a nodelist compiler looking for user flags has always to
consider the case "user flag separated by comma". In zone 2 this
idea was simply extended to the first user flag:
All flags are separated by commas. Flags not yet approved by the
International Coordinator or the FTSC (i.e. user flags only used
experimentally or locally) are separated by a new pseudo flag U.
-> U pseudo flag to the left of at least one user flag
All flags following this pseudo flag U are user flags, all flags
before this pseudo flag are "real" flags specified in FTS-0005 or
approved by the International Coordinator.
Because this definition should be compatible with any reasonable
software implementation based on FTS-0005.003, and simplifies the
handling of user flags significantly, a future FTS-0005 version
FIDONEWS 14-27 Page 31 7 Jul 1997
will hopefully adopt it.
Approved zone 2 user flags
--------------------------
In zone 2 user flags have to be approved by the Zone Coordinator.
Currently the following zone 2 user flags exist:
-> V110L ITU-T V.110 19k2 async 'Low' (former ISDNA)
-> V110H ITU-T V.110 38k4 async 'High' (former ISDNB)
-> V120L ITU-T V.120 56k6 async, N1 = 259, W = 7, modulo 8
-> V120H ITU-T V.120 64k async, N1 = 259, W = 7, modulo 8
-> X75 ITU-T X.75 SLP (single link procedure),
64kbit/s B channel; layer 2 max. framesize N1 = 2048,
window size W = 2, frame numbering modulo 8;
layer 3 transparent (no packet layer)
-> ISDN Other configuration, used only if none of above fits
These ISDN flags follow the specification in FSC-0091.
-> Tyz Online time flags as specified in FSC-0062
The flag Tyz is used by non-CM nodes online not only during ZMH,
y is a letter indicating the start and z a letter indicating the
end of the online period as defined below (times in UTC):
A 0:00, a 0:30, B 1:00, b 1:30, C 2:00, c 2:30,
D 3:00, d 3:30, E 4:00, e 4:30, F 5:00, f 5:30,
G 6:00, g 6:30, H 7:00, h 7:30, I 8:00, i 8:30,
J 9:00, j 9:30, K 10:00, k 10:30, L 11:00, l 11:30,
M 12:00, m 12:30, N 13:00, n 13:30, O 14:00, o 14:30,
P 15:00, p 15:30, Q 16:00, q 16:30, R 17:00, r 17:30,
S 18:00, s 18:30, T 19:00, t 19:30, U 20:00, u 20:30,
V 21:00, v 21:30, W 20:00, w 20:30, X 23:00, x 23:30.
For example TuB shows an online period from 20:30 until 1:00 UTC.
-> Z19 Zyxel series 19200 bps (implies ZYX)
-> X2C x2 client w/ 56000 bps (should imply V34 and V42B)
-> X2S x2 server w/ 56000 bps (should imply V34 and V42B)
-> K12 Systems offering all educational K12-conferences
-> ENC The node accepts inbound encrypted mail
-> NC Network Coordinator (only if the NC is not the host)
-> NEC Net Echomail Coordinator (at most one per net)
-> REC Region Echomail Coordinator (at most one per region)
-> ZEC Zone Echomail Coordinator (at most one per zone)
Redundant AKAs used to indicate echomail coordination in zone 2 are
no longer permitted. One *EC flag is valid for all AKAs of a given
sysop.
Flag implications
-----------------
Flag implications directly or indirectly specified in FTS-0005:
FIDONEWS 14-27 Page 32 7 Jul 1997
HST => MNP
H14 => MNP HST
H16 => MNP HST H14
V42b => V42 (MNP ?)
V32b => V32
Flag implications specified in the zone 2 nodelist epilog:
HST => MNP
H14 => HST MNP
-> H16 => V42 MNP V42B H14 HST
-> V42B => V42 MNP
-> ZYX => V42 MNP V42B V32B
-> Z19 => V42 MNP V42B V32B ZYX
V32B => V32
-> V32T => V32 V32B
-> V110L => ISDN
-> V110H => ISDN
-> V120L => ISDN
-> V120H => ISDN
-> X75 => ISDN
The latter ISDN flag redundancies are a consequence of FSC-0091.
| Maybe some of the following implications could be added in zone 2:
VFC => V32 V32B
| or VFC => V32 V32B MNP V42 V42B
| X2C => V34
| or X2C => V34 MNP V42 V42B
| X2S => V34
| or X2S => V34 MNP V42 V42B
Flag implications (i.e. not listing redundant flags) have several
advantages: Some old nodelist tools are unable to handle too long
lines. Old flags like HST, MNP, V42, or V32 vanish automatically,
if they are implied by H16, V42B, V32B, or better. Redundancies
defined globally for the whole nodelist help to avoid flag errors.
"Baud rate" field
-----------------
The former "baud rate" field 7 in the nodelist as specified in FTS-
0005 is nearly useless today: Except from a few remaining 1200 and
2400 nodes almost all nodelist entries show either 9600 for all
modem protocols better than V22bis or 300 for ISDN only nodes. No
more V21 or Bell 103 modems are listed today.
Obscure "baud rate" values 19200 and 38400 specified in FTS-0005
have not been used in the FidoNet nodelist. So all a reasonable
nodelist compiler can do today, is treat 300 as indicator for ISDN
only, and treat unknown or missing values in field 7 like 9600.
A new meaning for field 7 as speed field could be really useful.
An example is ZYX, if we would have 16800, 19200, 28800, and 33600
as speed values, then their combination with ZYX is all we need
technically, Z19 would be unnecessary. Another example is HST,
FIDONEWS 14-27 Page 33 7 Jul 1997
flags H14 and H16 are unnecessary, if HST is combined with 9600,
14400, 16800, 28800, or 33600. Variants of PEP could be shown in
the speed field without new flags. "Enhanced V32.terbo" could be
shown by 21600.
Most important: V34 may have the famous bug not allowing connects
from new "V34+", unless the caller disabled symbol rate 3429. If
"V34+" is indicated by speed 33600, then an appropriate setup for
all kinds of V34 connects is possible.
A future version of FTS-0005 hopefully allows the following speed
values in field 7:
300 reserved for ISDN only (for historical reasons)
1200 V22 or Bell 212A (obsolete)
2400 implies V22bis
9600 default, used with V32, HST, H96, PEP, CSP
12000 rare variant of V32
14400 used with V32b or HST (obsoleting H14)
16800 used with ZYX or HST (obsoleting H16)
19200 used with V32T or ZYX (obsoleting Z19)
21600 rare variant of V32T (no "H21" needed)
28800 used with VFC or V34
33600 used with V34 (no V34+ or V34b needed)
| 56000 used with X2C, X2S, or "K56FLEX"
The following values should be specified in FTS-0005, because they
are already used in nodelists of other FTNs:
empty no value, useful for Pvt nodes or in point lists
19200 used with V110L, V32T, or ZYX (obsoleting Z19)
38400 used with V110H
| 56000 used with V120L, X2C, X2S, or "K56FLEX"
| 64000 used with V120H, X75, X2S, or other ISDN equipment
Allowing more than 12 speed values or allowing ISDN speeds could
break old software. Therefore the transition could be done in two
steps, first add all non-ISDN speeds (ISDN only shown as 300).
Later remove 300 (ISDN only) and 1200 (obsolete) replacing 300 by
19200, 38400, 56000, or 64000.
Thanks to...
------------
Ben Baker St. Louis nodelist format
Rick Moore FTS-0005.TXT
David Nugent FTS-0005.003 and NLTOOLS
Jonny Bergdahl ERRFLAGS 2.6
Ward Dossche Zone 2 nodelist epilog
Arjen Lentz FSC-0091.001
David J. Thomas FSC-0062.003
Leonard Erickson CHECKNL 2.14 and many discussions in NET_DEV
Jim Barchuk LNDL 2.7
Marius Ellen FASTV7 2.03j (but I still prefer 1.45b ;-)
Jan Vermeulen, Jan Ceuleers, Ian Smith, and many others...
FIDONEWS 14-27 Page 34 7 Jul 1997
- eof -
-----------------------------------------------------------------
FIDONEWS 14-27 Page 35 7 Jul 1997
=================================================================
COORDINATORS CORNER
=================================================================
Nodelist-statistics as seen from Zone-2 for day 185
By Ward Dossche, 2:292/854
ZC/2
+----+------+------------+------------+------------+------------+--+
|Zone|Nl-157|Nodelist-164|Nodelist-171|Nodelist-178|Nodelist-185|%%|
+----+------+------------+------------+------------+------------+--+
| 1 | 8182| 8182 0 | 8182 0 | 8182 0 | 7828 -354 |30|
| 2 | 15774|15703 -71 |15666 -37 |15640 -26 |15577 -63 |60|
| 3 | 758| 758 0 | 758 0 | 743 -15 | 728 -15 | 3|
| 4 | 519| 514 -5 | 514 0 | 519 5 | 517 -2 | 2|
| 5 | 87| 87 0 | 87 0 | 87 0 | 87 0 | 0|
| 6 | 1078| 1078 0 | 1079 1 | 1079 0 | 1079 0 | 4|
+----+------+------------+------------+------------+------------+--+
| 26398|26322 -76 |26286 -36 |26250 -36 |25816 -434 |
+------+------------+------------+------------+------------+
-----------------------------------------------------------------
FIDONEWS 14-27 Page 36 7 Jul 1997
=================================================================
ECHOING
=================================================================
ECHOLIST
The EchoMail Conference List
01 July 1997
Due to the proximity of my vacation, the July issue of the Elist will
be dropped. The next regular issue will be 01 August 1997. My
apologies for the inconvenience.
Adrian Walker
Echolist Coordinator
1:1/201
---ooo000ooo---
-----------------------------------------------------------------
FIDONEWS 14-27 Page 37 7 Jul 1997
=================================================================
ADVERTISE YOUR FREE SERVICE/EVENT
=================================================================
Don't risk being banned! Use FIDOTEST.
Almost ALL other echoes FORBID posting TEST messages. Where do you
and your users send test' posts to ensure they are leaving your
system? Which Backboned echo can you use to ensure your posts are
reaching the far corners of Z1, or to see if upstream/downstream
systems are wrecking or loosing your message?
Why not a specific echo devoted to testing echomail links?
There is one! If you believe it to be beneficial for the Fidonet
community to have a _dedicated_ and _authorized_ echo for testing,
be sure to ask your REC to ensure that
FIDOTEST -
the Fidonet TEST echo and malfunction conference gets
Z1-Backboned.
For your edification, the complete echo rules follow:
FIDOTEST Echo Rules and Information
===================================
Revision 1, July 1997
(This document may be revised without prior notice.)
>> Description:
Fidonet TEST echo and malfunction conference
>> Extended Description:
Use the TEST echo to post TEST ECHOMAIL! Useful
for checking your tosser/scanner/FTS mail software
configurations. **ALSO: discuss/query about broken
links, dupe loops, and other problems within Fidonet
and the North American Backbone on all net/region/zone
levels here. All users and sysops welcome.
>> Moderator:
Ronnie Grant, 1:2612/114, 1:102/836, 1:3618/555,
ronnie.grant@global.nws.net, ronnie.grant@bbsnets.com, rg@dhp.com,
ronnie@eqcity.ktb.net
>> Rules:
1. No off-topic posts.
2. No profanity.
3. No "flooding" or other abuse of the echo.
4. No illegal activities or posts.
-----------------------------------------------------------------
FIDONEWS 14-27 Page 38 7 Jul 1997
Remember: only YOU can make sure your REC knows your position
on the backboning of FIDOTEST. Netmail him today, because
without your help, tomorrow's Fidonet may never arrive.
Ronnie L. Grant
Moderator, Fidonet FIDOTEST echo
-----------------------------------------------------------------
FIDONEWS 14-27 Page 39 7 Jul 1997
=================================================================
NOTICES
=================================================================
Future History
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.
30 Apr 1998
Queens Day, Holland.
22 May 1998
Expo '98 World Exposition in Lisbon (Portugal) opens.
1 Dec 1998
Fifteenth Anniversary of release of Fido version 1 by
Tom Jennings.
31 Dec 1999
Hogmanay, Scotland. The New Year that can't be missed.
1 Jan 2000
The 20th Century, C.E., is still taking place thru 31 Dec.
15 Sep 2000
Sydney (Australia) Summer Olympiad opens.
1 Jan 2001
This is the actual start of the new millennium, C.E.
-- If YOU have something which you would like to see in this
Future History, please send a note to the FidoNews Editor.
-----------------------------------------------------------------
--- Following message extracted from NETMAIL @ 1:18/14 ---
By Christopher Baker on Wed Jul 02 22:58:14 1997
From: C. Ingersoll @ 1:2623/71
FIDONEWS 14-27 Page 40 7 Jul 1997
To: Editor @ 1:1/23
Date: 01 Jul 97 02:14:46
Subj: Fidonet via Internet Hubs
Fidonet Via Internet Hubs
Speed| Node# | Operator | Facilities | Basic Rate
-----+-----------+-------------------+-------------------+-----------
T1 | 1:270/101 | George Peace | FTP | $30mo.
T1 | 1:396/1 | John Souvestre | FTP | $25mo.
T1 | 1:12/12 | Ken Wilson | FTP | $24mo.
T1 | 1:140/12 | Bob Seaborn | FTP, TransX | $5/$20
T1 | 1:346/250 | Aran Spence | FTP, TransX | $10mo.
64k | 1:124/7008| Ben Hamilton | FTP, VMoT, TransX | $20mo.
56k | 1:13/25 | Jim Balcom | FTP | $20mo.
33.6 | 1:2604/104| Jim Mclaughlin | FTP, VMoT, UUEMAIL| $1mo.
33.6 | 1:2624/306| D. Calafrancesco | VFOS | $15yr.
33.6 | 1:281/169 | Brian Greenstreet | FTP | $2mo.
28.8 | 1:330/204 | Patrick Rosenheim | Transx | $25yr.
--
* VMoT = Virtual Mailer over Telnet
compiled by Cindy Ingersoll, 1:2623/71, (609)814-1978,
fbn@cyberEnet.net
Posted on the 1st of every month in FN_SYSOP, R13SYSOP and Fidonews.
---
* Origin: * Fly By Night * (609)814-1978 *(1:2623/71)
-----------------------------------------------------------------
FIDONEWS 14-27 Page 41 7 Jul 1997
=================================================================
FIDONET SOFTWARE LISTING
=================================================================
Latest Greatest Software Versions
by Peter E. Popovich, 1:363/264
Whew. Been a big month for me, but a relatively slow one for the list.
-=- 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
FastLst 1.36 N S Alberto Pasquale 2:332/504 FASTLSTD
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-27 Page 42 7 Jul 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
Max User Ed. 0.18 O F Larry Cooke 1:300/53 MUE
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
NEF 2.38 O S Alberto Pasquale 2:332/504 NEFD
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.01 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.600 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
FIDONEWS 14-27 Page 43 7 Jul 1997
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
FastLst 1.36 N S Alberto Pasquale 2:332/504 FASTLST
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
Max User Ed. 0.18 O F Larry Cooke 1:300/53 MUEP
Msged/2 4.10 O G Andrew Clarke 3:635/728 MSGED41O.ZIP
NEF 2.38 O S Alberto Pasquale 2:332/504 NEF
PcMerge 2.3 N G Michiel vd Vlist 2:500/9 PCMERGE
RAR 2.01 C S Ron Dwight 2:220/22 RAR2
Squish 1.11 T P Tech 1:249/106 SQUISHP
T-Mail 2.600 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
FastLst 1.36 N S Alberto Pasquale 2:332/504 FASTLSTW
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
NEF 2.38 O S Alberto Pasquale 2:332/504 NEFW
PlatinumXpress 2.00 M C Gary Petersen 1:290/111 PXW-INFO
T-Mail 2.600 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
FIDONEWS 14-27 Page 44 7 Jul 1997
Msged 4.00 O G Paul Edwards 3:711/934 MSGED
Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK
Amiga:
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
CrashMail 1.23 T X Fredrik Bennison 2:205/324 CRASHMAIL
CrashTick 1.1 O F Fredrik Bennison 2:205/324 CRASHTICK
DLG Pro BBOS 1.15 B C Holly Sullivan 1:202/720 DLGDEMO
GMS 1.1.85 M S Mirko Viviani 2:331/213 GMS
Msged 4.00 O G Paul Edwards 3:711/934 MSGED
Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK
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-27 Page 45 7 Jul 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-27 Page 46 7 Jul 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: [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://www.proteus.demon.co.uk/zec.htm
Zone 2 Elist: http://www.fbone.ch/z2_elist/
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-27 Page 47 7 Jul 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-27 Page 48 7 Jul 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-27 Page 49 7 Jul 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-27 Page 50 7 Jul 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