informis
/
textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
textfiles/bbs/FIDONET/FIDONEWS/fido1336.nws

2972 lines
147 KiB
Plaintext
Raw 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 13, Number 36 2 September 1996
+----------------------------+-----------------------------------------+
| The newsletter of the | ISSN 1198-4589 Published by: |
| FidoNet community | "FidoNews" |
| _ | 1-407-383-1372 [1:1/23] |
| / \ | |
| /|oo \ | |
| (_| /_) | |
| _`@/_ \ _ | |
| | | \ \\ | Editor: |
| | (*) | \ )) | Christopher Baker 1:374/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. |
+----------------------------------------------------------------------+
THIS IS THE 600TH PUBLISHED ISSUE OF FIDONEWS!!
Table of Contents
1. EDITORIAL ................................................ 1
Our 600th Issue! Going to ZIP and other things ........... 1
2. ARTICLES ................................................. 3
It's a sad world we live in .............................. 3
Borlan Turbo C Large/Huge model difftime() bug ........... 4
What is a PUBLIC KEY? .................................... 4
A Public-key primer in answer to the previous ............ 5
3. FIDONET HISTORY .......................................... 7
Editorials Past - a reflection ........................... 7
4. REVIEWS .................................................. 22
Six Mail Processors Reviewed [III] ....................... 22
5. COORDINATORS CORNER ...................................... 25
Nodelist-statistics as seen from Zone-2 for day 243 ...... 25
6. ECHOING .................................................. 26
Zone 2 Echomail proposal from ZEC2 ....................... 26
7. WE GET EMAIL ............................................. 38
Old Nodelists at 2:240/5815 .............................. 38
Old Nodelists at 2:2448/610 .............................. 38
8. PROOFREADERS REPORT ...................................... 40
Somebody finally caught one! ............................. 40
9. NET HUMOR ................................................ 41
They don't mean Fido, do they? ........................... 41
10. COMIX IN ASCII .......................................... 42
Flushed with success? .................................... 42
And more!
FIDONEWS 13-36 Page 1 2 Sep 1996
=================================================================
EDITORIAL
=================================================================
FidoNews passes another milestone as this, the six hundreth Issue, is
published.
There were years where 52 were not published and there was the
composite Issue of 5 Jul 96 wherein I caught up the missing numbers
of the past Editor in one lump. I don't count any Issues that didn't
achieve actual, physical status as an existing file. I counted every
FidoNews file in the archives and this is number 600, right here.
It has been nearly twelve years since FidoNews started under the
fingers of FidoNet's progenitor, Tom Jennings. For the 600th Issue,
the History section will contain Editorials past from the previous
Editors as a reflection of where we've been, where we are, and where
we should be headed.
Congratulations, FidoNews!
**=*=**
Complete topic change - FidoNews is going to ZIP format for weekly
distribution beginning in FOUR weeks with the 30 Sep 96 Issue 1340!
PLEASE PAY ATTENTION TO THIS ANNOUNCEMENT if you never read another
word here. You have FOUR weeks to adjust your batch files and Tick
throughputs before they begin choking on the new extension of .ZIP
instead of .LZH!!
When 1340 comes out it will come out as: FNEWSD40.ZIP. Don't get
caught unaware and complain about not knowing why your batch files
don't work on FidoNews anymore.
After the survey, it was obvious that ZIP was the preferred format and
the format with the most platforms. It is also the defacto archiver on
the Internet as well as producing smaller and faster archives.
ALL Coordinators are requested to repeat this bulletin to those Nodes
under their auspices so everyone is on the same page come Issue 1340
on 30 Sep 96. Thanks, in advance, for your assistance and cooperation.
**=*=**
Your FidoNews Editor will be moving at the end of this month. This
be a physical move on all levels changing Node numbers [1:1/23 will
still be valid but have a new phone number] and counties and cities.
We will be going upstate a few miles to Edgewater_FL and be leaving
Net 374 for independent Node status as 1:18/14 [my first Node number
from the dim time]. The P.O. Box will also be changing in the contact
info in the Masthead. The specifics will be forthcoming in a future
Issue. Please get ready for that, too.
**=*=**
FIDONEWS 13-36 Page 2 2 Sep 1996
ZEC2 has a lengthy article in this Issue about a new Zone 2 Echopol.
All those affected please take note. Other Zones might want to pay
attention as well for future reference.
That's enough news for one Issue. [grin]
C.B.
-----------------------------------------------------------------
FIDONEWS 13-36 Page 3 2 Sep 1996
=================================================================
ARTICLES
=================================================================
A European point of view
by Fredrik Bennison -- 2:205/300, lomaxx@dalnet.se
Last night I had a great article in my head but decided to sleep on it
to get it all sorted out. Today the idea has evaporated into the
great unknown we call sleep. But as I think I know what I wanted to
say, I thought I'd try writing an article anyway.
It's sad to see the discussion regarding echomail in FIDONEWS the past
week. More and more absurd objections are brought up, like whether
being tried for murder in a criminal court can justify
excommunication or not. What has happened to common sense in Fidonet,
Fidonet is not governed by law like other parts of our society, it
depends on the good will, common sense and cooperation of individual
sysops across the globe. Disrupting the net in an 'excessively
annoying' way constitutes reason enough for excommunication. What is
excessively annoying is left to the discretion of the *C structure.
That is one of the reasons that they are there.
The next subject I'd like to mention is echomail and the *C
jurisdiction over it. P4 clearly states that in policy disputes,
echomail is considered another flavour of netmail, and therefore
covered by Policy. Which to me clearly states that actions that would
be deemed annoying in netmail does not automatically become null and
void just because they appear in echomail. In my opinion, there are
several scenarios in echomail that would constitute excessively
annoying behaviour and warrant action from the *C structure. But as
with so many other things in our beloved Policy, that can be disputed
and ignored.
Which brings me to the third (and final) topic for the day. Policy 4.
It is now more than 7 years old and outdated and obsolete in several
ways, of which echomail is one. At the time (1989) echomail was
considered secondary to netmail and echomail was not to impair the
performance of the network as a whole. Today, the bulk of mail
passing through Fidonet is in the form of echomail and I feel that
that needs to be addressed in a new version of Policy.
Another thing that really should be made more clear is netmail routing
policies. Routing netmail is (and has been for as long as I can
remember) a given right for members of Fidonet Region20, and I guess
for most of Zone2. Netmail routing in Zone1 however seems to be
haphazard at best. One can never know if a netmail will reach it
destination, or which networks disallow routing altogether. A new
Policy should impose that requirement on the *C structure, that they
must allow both inbound and outbound routing to their network.
Preferably by some acknowledged paths like NC -> RC -> ZC and back
down again.
Oh well, this article ended up a bit longer than I expected, but I
hope that I have managed to stir up some emotions and responses to my
FIDONEWS 13-36 Page 4 2 Sep 1996
opinions, I welcome ideas and constructive criticism.
-----------------------------------------------------------------
Borlan Turbo C Large/Huge model difftime() bug
Fredric L. Rice (frice@stbbs.com)
The Skeptic Tank (1:102/890.0) (818) 335-9601
I ran into a problem a couple of years ago when I was working on
a software project in Holland and rediscovered it again tonight.
Since I didn't make a note of it, I didn't avoid another length
session of table pounding.
The problem was that after executing my program in a DOS window,
Windows 3.1 would exit to DOS every time I hit Control-ESC or
Alt-ENTER to return to the Desktop.
Naturally I suspected something funny with my code so I dropped
exit() calls in the main() to isolate the problem yet the problem
couldn't be isolated that way. Eventually I commented-out
sections of the code until the problem went away which allowed me
to isolate the faulty code.
What was damn strange was the fact that the faulty code wasn't
even being executed -- it would cause this strange behavior in
Windows 3.1 simply by existing in the executable file.
A call to Borlan's difftime() function compiled for either the
Huge or Large memory model caused the problem. The difftime()
library code for Huge and Large, I would guess, generates code
that links strangely -- perhaps code gets byte aligned or some
other silly nonsense.
Has anyone else run into this and know what's wrong with the
library function? As it is I remembered replacing the call with
a call to labs().
-----------------------------------------------------------------
What is a PUBLIC KEY?
An Inquiry Concerning Fidonet Nomenclature
Author: Allen McBroom, 1:361/206
Having recently had the good fortune (or misfortune) of being
appointed the position of NC for 1:361, I was suddenly introduced to
the marvels of FidoNews. While I've enjoyed every edition that's
found it's way over the phone line to our system, I've been curious
about some of the terms used by LTFS (Long Term Fido Savvy) authors.
FIDONEWS 13-36 Page 5 2 Sep 1996
Every edition has contained a reference to a "Public Key", which
seems to be a matter of some import to many readers of FidoNews.
I've no clue as to what a Public Key is, and even less of a notion as
to whether I should be worried about my inadequate FNRE (FidoNet
Relevent Education). Would someone be so kind as to enlighten me?
-----------------------------------------------------------------
This Is What a Public-key Is
Christopher Baker, ISMH [temp]
Rights On! 1:374/14
Allen McBroom asks: "What is a public key?"
Well, Allen, without a complete introduction to the mechanics and
types of encryption systems, a brief answer to your question is as
follows:
Public-key cryptography differs from standard password encryption by
being a two-part system. When most folks think of encryption, they
think of spies coding documents with cipher keys like passwords or
passages from books or machines that take in streams of apparent
nonsense and put out cogent text at the other end. Standard encryption
is a one-part system where both ends must have the matching decoders.
Public-key cryptography is a two-part system where the originator has
two keys. One is a secret-key that is never revealed and is used
locally to decrypt incoming traffic created using his/her public-key.
The public-key is the visible and released part of the key pair that
anyone can use to send encrypted traffic to the key holder. The sender
has no need to have the secret-key because the necessary parts for the
sender are contained in the released public-key.
The public-key system allows the holder to post his/her public-key
anywhere so it may be used to either encrypt traffic to the holder or
to verify the signature of the holder on a publicly signed [called
clear-signed in the vernacular] document including messages and files.
In the case of the FidoNews public-key, it was produced by the program
known as Pretty Good Privacy by Phil Zimmerman. PGP is available for
most platforms and is the most powerful authenticity tool available to
ordinary folks today. You do not need PGP to read a clear-signed
document since the text is in 'the clear', i.e. openly readable. You
only need PGP to verify the authenticity of the signature. The
signature encloses the document to which it is affixed and will
indicate immediately any tampering with any part of the document or
signature. If, for some reason, you wish to send something to the
FidoNews Editor that can only be read by the FidoNews Editor, you can
use the FidoNews public-key and PGP to encrypt your traffic to that
public-key. The operation of PGP is well outside this brief answer.
If you want more information on public-keys or PGP or related privacy
issues, please join us in the PUBLIC_KEYS Echo available on the Zone 1
FIDONEWS 13-36 Page 6 2 Sep 1996
Backbone and elsewhere.
I hope this hasn't confused the issue. [grin]
-----------------------------------------------------------------
FIDONEWS 13-36 Page 7 2 Sep 1996
=================================================================
FIDONET HISTORY
=================================================================
Editorials coming and going - part of the FidoNet History series
Tom Jennings:
fidonews.man -- 04 Dec 84 00:56:08 Page 1
Editor: Tom Jennings
Publisher: Fido #1
HOT NEWS
THE FIRST FIDONET NEWSLETTER
Well, it finally got done ... FidoNews, the FidoNet
Users Group newsletter is real. It will be published once a
week, possibly once every two weeks if it gets busy.
There will be at least three regular "features": the
node list, Fido list, and the route list. Hopefully there
will be more interesting things later. Now you have a reason
to get FidoNews.
I, Tom Jennings, am apparently the editor. I do NOT
wish to be editor; the last thing I need is something else
to do. See the HELP WANTED section. (Not kidding)
We (ahem) are also looking for a publisher; I will
do that for a while at least. A freebie outgoing host would
be nice. Not a short term problem, though, like finding an
Editor in Chief is.
*All* articles, etc are user submitted; anything and
everything, as per usual Fidonet protocols (Which isn't
saying much ..) Ideas, problems, questions, tips, programs,
hardware, etc etc are all welcome. See the ARTICLE article.
(sic)
Distribution is still up in the air; it will be
mailed to at least six hosts across the country. For now, it
is available on #1 and #51. Possibly elsewhere in this thing
you'll find an article on distribution.
THE FIDONET USERS GROUP
Oh yeah, I did mention that ... I hereby declare all
Fido users and sysops members of the FidoNet Users Group.
Sounds pretty stupid, huh? Well ... If there are 100 Fido
systems around the country, and each has at least 100 users,
that's 10,000 people. Any group that large has advantages, if
nothing other than letters to the editor of your favorite
magazine. This is just a brainstorm at this point, but is
FIDONEWS 13-36 Page 8 2 Sep 1996
something to keep in mind.
To make this fake club at least appear real, I am
trying to decide whether or not to have bumper stickers
made. This will be 3 3/4" X 8 1/2" white vinyl, with black
artwork, will have the requisite doggie, the words "FidoNet
Bulletin Board Network" and "Fido Node #" on it, and a place
for a phone number, and blank space. These will cost $165.00
for 500 stickers, or about $230.00 for 1000. I'll pay part
of it ($40.00?) but no more; if I get promises to buy say
$125.00's worth, I'll have them made, and sell them at cost.
(They cost about 34 cents each; plus 20 cents postage, plus
envelopes, etc, call it a buck a piece.)
The real reason for this is so I can have one, but I
don't want to spend $165 for it!
EDITOR'S SOAP BOX
fidonews -- 18 Mar 85 18:52:30 Page 1
HOT NEWS
This is my last editorial, yeah! Thom Henderson at
FidoNode #375 is taking over as Head Procrastinator. Thom
has an article here.
Please note that this means you submit articles to
him, not me. You can FidoNet them, or upload them manually.
The latter will probably be a lot easier than spending hours
and hours trying to autodial into Fido #1.
Good luck to Thom, and thanks. Thanks also to the
others who volunteered for Procrastinator duty, it is
appreciated greatly.
No editorializing here today; I wrote a whole
article instead. There are a lot of changes coming soon.
This also means that I'll be able to WRITE ARTICLES
instead of having to MUNGE ARTICLES. Currently, I cringe
when I think about the newsletter; usually it's 10 PM on
Monday night when I think about it, and have to work on it
then. Ecch! I'll probably write more now that I don't have
to. (?)
----------------------------********---------------------------------
Thom Henderson:
FIDONEWS -- 01 Apr 85 01:35:51 Page 3
The New Kid on the Block
That's me. This is my first issue as editor of Fidonews.
Since you are reading this, then obviously I've at least
figured out how to put the paper together. So far, so good.
FIDONEWS 13-36 Page 9 2 Sep 1996
I've already made a few changes, but almost all of them are
internal things, dealing with how Fidonews is assembled, and
shouldn't really affect anyone but me. No big deal, really.
Everyone develops their own methods for doing things. Tom
Jennings and I have developed different methods, is all.
My short range goal is to totally automate the production of
Fidonews, so that it will get out on time even if I'm out of
touch for awhile. This should be no big problem, as long as
contributors abide by the submission standards (above).
This is really more your newsletter than mine, anyway. I
just put together the pieces and send it out, maybe with a
little note from me to you tucked away somewhere.
So don't think of this as "my" paper, or even as Fido's
paper (pun NOT intentional). Think of it as YOUR paper.
* * *
Real date: 31 Dec 87
FidoNews 5-01 Page 1 24 May 2010
=================================================================
EDITORIAL
=================================================================
Time Flies When You're Having Fun
I've been editing this newsletter for over two years now. Why do
I keep doing it? At least partly because it isn't that much
bother. As long as everyone goes along with the simple
guidelines given in ARTSPEC.DOC, which almost everyone does, it
pretty much takes care of itself. Meanwhile, every now and then
I get to sound off in one of these editorials. By and large it's
been fun, and when it hasn't been fun at least it hasn't been a
bother.
I have a long history of running newsletters. I was the editor
of my high school newspaper (a real fishwrapper if there ever was
one), and I was a shoo-in for the job. Way back in sixth grade I
started the first newsletter in the whole school. [The school was
in its first year when I was in sixth grade. It covered first
through twelfth, and had about 300 people when I graduated. I
graduated in a class of eighteen. Growing up in a small town
does have its advantages.]
Writing these editorials seems to give me a different slant on
things that I normally have. I feel as if I'm taking something
of a longer view. I have this conception of FidoNet as some
great and glorious mechanism to allow ordinary people (well, as
ordinary as BBS users ever get) to reach out to each other. When
I sit down to write an editorial I remember that view, and I try
to talk about it. And who knows? Maybe I even make a difference
in some small way. If so, then it's certainly worth it.
FIDONEWS 13-36 Page 10 2 Sep 1996
Do you share my vision? I hope so. Yes, we have our little
squabbles. But take any three people and sit them down, and they
will have their differences of opinion. We have much the same
situation, only on a larger scale and vastly amplified.
Sometimes it can seem almost too much to bear. But remember
this: Nobody ever guaranteed you that everyone would always agree
with you. There will always be those (not always the same ones)
who disagree with your viewpoint. That is the price we pay for
such unparalleled freedom of expression. In return for having so
many people hear your viewpoint, you must pay the price of
hearing viewpoints from those who disagree with you. You can
refuse to pay that price, but then your own voice will be
silenced.
We really do want to hear from you. So some people may disagree
with you. Maybe some of them will even descend to personal
invective. Just remember, the same is true of any personal
contact. That is a price you must pay to make your voice heard.
----------------------------**********---------------------------
Dale Lovell:
FidoNews 5-01 Page 1 4 Jan 1988
=================================================================
EDITORIAL
=================================================================
Much to my surprise I received a message from Thom Henderson
a few weeks ago. It wasn't that he had sent the message that took
me so much by surprise as the message's contents. He was looking
for a new editor for FidoNews and was "offering" me the position.
Let me say up front that it took me several days to finally
come to a decision. It wasn't an easy decision to make! As a
semi-regular columnist I had it easy. If I didn't feel like
writing or didn't have the time it was no big deal, although I
did have to live with the guilt it caused (and yes, I did feel
guilty when I didn't get a column out). As editor it would be my
responsibility to the net to make sure that an issue of FidoNews
did go out every week, regardless of what my work schedule was
like or my personal feelings. Only after I was sure I could take
on the responsibility did I check to make sure I could do the
work required. This may sound backward but I was reasonably sure
that if I decided to shoulder the responsibility, I could manage
the work. In the end, I decided that it was "the right thing."
For the time being there shouldn't be any real change
apparent to most of you. I am continuing Thom's policy of
printing anything I receive (outside of obvious plagiarism,
libel, or criminal intent). I am going to try and take a more
active role in getting material. Many of you will be hearing from
me in the near future in this regard! What kind of articles am I
interested in? Well first off, I'd like to see someone take up my
FIDONEWS 13-36 Page 11 2 Sep 1996
old "Regular Irregular Column." Actually, I'd like to see a large
group of "contributing editors" spring up in the near future. All
the title means as far as I'm concerned is that the person makes
regular contributions to FidoNews. Not weekly. Not monthly. Just
regularly.
Also, right now there are many new bulletin board systems
being introduced to the net. I'd like to see some articles from
these "converted" sysops and their users on what they expect and
see in FidoNet. What made them decide to add FidoNet
compatibility to their systems, and how easy (or hard) was it for
them to learn some of our unique terminology and practices.
Some other topics I'd like to see articles on in the future
are Gateways. What are they? How do they work? At FidoCon I heard
some of the possible uses of EchoMail, is anyone doing anything
new and exciting? Tell us about it if you are. There are several
public service EchoMail conferences, are they actually
accomplishing anything? Also, what is the EchoMail backbone? How
do you "link up" with it. Some of these are questions that every
sysop asks at one time or another, and it would be a big asset if
everyone could point to and read a good article on topics like
these.
If you think you'd like to write something but are unsure
how it would be received, drop me a line and we'll discuss it. In
addition to my electronic address (which is now a public board,
no more routing worries) I'm listing my home and work addresses
and phone numbers. I'm also interested in hearing from you on
topics for articles you'd like to see. Who knows, maybe I can
find someone to write them!
In summary, I'd like to say that I am very excited about
this new position and hope that I can live up to your
expectations. I plan on taking a more active role than Thom did
in that I'm going to be a little aggressive in getting some of
you to write an article instead of just posting a message in
EchoMail. EchoMail is fickle, many people may not see a message
that directly pertains to them. Why not enter a message AND send
in an article, after all this is YOUR newsletter!
Your Editor,
Dale Lovell
1:1/1 (1:157/504)
-----------------------------------------------------------------
Vince Perriello:
FidoNews 6-16 Page 1 17 Apr 1989
=================================================================
EDITORIAL
=================================================================
Hello there. I've been meaning to write a little something here
for several weeks now and just haven't gotten around to it.
FIDONEWS 13-36 Page 12 2 Sep 1996
Maybe next week I'll find the time.
The major reason that I decided to key in anything at all this
week was to let you know that next week we will publish responses
to the Policy4 issue of FidoNews. As it appears that these
responses are on the LONG side, the odds are that we won't
publish any other articles next week, though whether we publish
columns or not will be a function of how much space the articles
take up.
Thanks for reading this rag. I think it's a pretty good one. By
the way, feel free to help keep it that way by sending along some
material for publication.
Cheers,
Vince
-----------------------------------------------------------------
FidoNews 6-19 Page 1 8 May 1989
=================================================================
EDITORIAL
=================================================================
It's time to speak out on Freedom of the Press
As many of you have no doubt noticed, FidoNews isn't a rigidly
controlled publication. Its content often has little or nothing
to do with the day-in, day-out nonsense involved in being a
member of FidoNet. There are articles and discussions of some
amazingly varied topics, reflecting the similarly varied tastes
of the five thousand member nodes of FidoNet.
I personally believe that it is a major strength of this
publication that any member of FidoNet is allowed to contribute
to a publication that is made available to every other member of
FidoNet. It is, quite literally, a free and open public forum
in which any of us can share anything we consider important with
anyone else.
Of course, there is a "down" side to this openness. The down
side is this: not every issue of FidoNews will be of interest
to everyone in FidoNet. In some cases, there might be one or
two issues in succession that in some individuals' opinions,
would have been better off unpublished. I'm sorry to disagree
with those people, but this is the price that you pay for having
your own turn with FidoNews when YOU want it. There are
sometimes excesses, but we'll gradually learn how to minimize
them without hurting the open policy.
There now appear to be some rumblings in the coordinators'
structure to the effect that FidoNews has too low of a "signal
to noise ratio" and that perhaps the *C's might want to do
something about it. This is apparently largely due to the fact
that readership isn't what it used to be, and many NC's have
been resisting the idea of carrying FidoNews, which is currently
FIDONEWS 13-36 Page 13 2 Sep 1996
mandated by Fidonet Policy.
I can't resist the temptation to suggest that indeed we have had
the same problem with the *C structure. How about some more
signal and less noise from them? Whatever happened, for
example, to the promised WEEKLY update from the coordinators via
the "RegComm - Communications from RegCon" column? Well, to be
fair, it only claimed to be a "weekly" update in the January 2
and January 9 columns. The January 16 column billed itself as a
"regular" column. Of course, it was the last one submitted.
When humans get that "regular" they usually need an enema.
Look, maybe as an individual you don't always like what appears
in FidoNews. But this is YOUR publication. YOU decide what
appears in it through YOUR submissions. If you don't like the
signal to noise ratio, submit something with a high signal level
and its presence in the newsletter will help keep that ratio
closer to where you'd like it.
At this point, then, FidoNews seems to have reached a very
important cusp. We need this open and widely distributed forum.
The *C's want something that stays a bit closer to the center of
things. As yet there has been no real consensus among the *C's
on any course of action, and this means that the time is right
for you to be heard on this issue. If you agree that FidoNews
should belong to ALL of us, then you had damned well better get
off your gluteus maximus and write a note to your coordinator
saying just that.
Then, while you're in a writing mood, how about submitting an
article?
=================================================================
EDITORIAL
=================================================================
This is my last Editorial.
I have resigned as FidoNews Editor. We are currently working our
way through a "short list" of replacement candidates, and the new
Editor will be on the job next week.
Be kind to the poor soul.
I've just been looking though the indexes for the past two years.
It's really amazing what we have been through. It's even more
amazing that we are still here to talk about it.
For example, when I took over Dale's job as Editor, the current
version of FidoNet Policy was Version 3. David Dodell was the
current International Coordinator. IFNA was still trying to
figure out what, if anything, could be made of its existence.
I was running my system on a DEC Rainbow. It worked great, too.
A few other hardy souls were doing similar things on Sanyo and
Tandy PC's (the ones from before Tandy became the PC-Clone hawker
FIDONEWS 13-36 Page 14 2 Sep 1996
that they are today). Hardly anyone is doing THAT any more!
POLICY4 was declared to be in force in FidoNews Volume 6, Number
24, on June 12, 1989. This created a stir because in the absence
of a formal procedure in POLICY3 for replacement, David used the
method described in the POLICY4 draft to determine whether he
should declare it to be in force. Boy, what a stir! There was
that article in Volume 6, Number 26, entitled "Policy 4: FidoNet
now a Nazi Dictatorship?". To the best of my knowledge nobody has
been gassed or blitzed (except metaphorically) in the almost two
years since.
David quit at the end of July. I quit two weeks later, then
changed my mind (with some coercion from friends). It was an
exciting time to be the Editor. Because the Great IFNA Mandate
Plebiscite was taking place.
This was IFNA's final answer to the people who had claimed that
the simple majority who chose IFNA were not representative. The
voting rules were simple: if you were in the nodelist running a
public access system, you were eligible. And a majority of all
eligible nodes was required to endorse IFNA. If IFNA won the
election, the critics would be silenced forever. And in a high
stakes gamble, IFNA agreed to disband if not ratified.
Did IFNA ever have a chance? Was it the right idea? Who really
can say anymore? In any event, apathy won the election and IFNA
was out, as reported in FidoNews Volume 7, Number 1.
As I look back to 1989, what's really fascinating is that Pablo
Kleinman was already at work on Worldpol in the immediate
aftermath of the Policy4 adoption. And he's still at it. He is
showing signs of getting it right, too. It's just going to take
some more time.
Remember Hurricane Hugo? Remember what it did to Mike Ratledge
and many others in his area? FidoNet reached out and touched
him in a very special way, and FidoNews was there, starting with
an article in Volume 6, Number 39 entitled "Let's give Mike
Ratledge a hand". One of our finest hours. I am proud to have
been here to see it.
FidoNews has had its critics too. There was an article in Volume
6, Number 40 entitled "FidoNews: What IS Its Purpose ?". I have
my own ideas about that. Fortunately for my peace of mind, it
will soon be someone else's problem to define that role.
When the Internetwork Gating Policy was published, there was a
lot of comment. Mostly negative. I think (speaking as one of
the people who had some input in the process) that if the
criticism was directed at alternative solutions to the problems
addressed in the Policy rather than direct attacks on the entire
idea of HAVING such a document, we might have accomplished
something. As things stand, the original document is still in
force but not strongly enforced. In other words "If you want to
connect to FidoNet, you could refer to this document and get it
FIDONEWS 13-36 Page 15 2 Sep 1996
right -- or just do it any old way". Sigh. What happened to
the idea of you don't go wee-wee in my garden and I won't go
poo-poo in yours?
We at FidoNews had a great moment in everyone's spotlight too.
The way things were progressing, it was getting really hard to
attract your attention anymore. But we found a way. On July 30,
1990 lots of you woke up to find FidoNews sitting on your system
in a file compressed with LHARC. Yup, you sure DID notice. I
think it was probably the most popular topic in FidoNews that
year. Even with the late start.
It really pissed off Saddam Hussein too. In less than a week he
had taken over Kuwait in an attempt to capture the responsible
parties. After being told that the dirty deed had been done by
an American, he is reported to have said "An American? OK. I'll
wait here for him."
I never made it over there. A lot of very brave folks did. And
they did a great job. FidoNet was involved too, in its own unique
way. An article in FidoNews Volume 7, Number 45 announced "The
Saudi Connection". Numerous articles about the war were
published. A healthy exchange of opinions ensued. People were
engaged. It was great.
We had ZC, RC and EC elections in Zone 1 and elsewhere, as the
idea of democracy flowered in the Net. Then of course we had the
great turnout in the Worldpol ratification vote. Electing NC's
is an idea whose time has come. It should be easier to throw out
the old slugs than it presently is.
I sure wish I knew where FidoNet is going these days. The only
consolation I have is that nobody knows. If anybody tells you
that he or she DOES know, you can safely call that person a liar.
Boy, there are some great memories here. And some not so great
memories. It's been a lot of fun. But I won't miss it. I'll be
too busy with other things.
Well, maybe I will miss it. But I promise not to make a scene.
Best regards,
Vince
----------------------------********-----------------------------
Tom Jennings [again] and Tim Pozar:
FidoNews 8-22 Page 1 3 Jun 1991
======================================================================
EDITORIAL
======================================================================
Times they are achangin'
by Tom Jennings, Editor (1:1/1)
FIDONEWS 13-36 Page 16 2 Sep 1996
As you may have noticed, Vince Perriello has stepped down from
editorship of FidoNews. Tim Pozar & I have taken over as editors on
pretty short notice. We are about to make some substantial changes we
feel have been necessary for a long time. Some have already been
implemented.
The editorial policy was and still is "we publish anything". But what
that meant was, on any subject. This is an unusual editorial policy,
but one that I felt was important to the net back in 84 when this all
started, and I think it is still important.
In the intervening years, there were two major directions it could
have gone; the "well we can't have *THAT* in there ..." "and *THAT*
wasn't what was meant by..." which is the usual route. Then there's
the way it *did* go -- the harder route of an open policy. It is to
the great credit of all of the editors that they decided what they
did.
The phrase for the problem (which I just discovered a while back) is
the "slippery slope". Once you start down it, there is no way to turn
back and no way to tell when to stop.
To make it crystal clear -- the "rule" that would keep out
"controversial" christian articles would be the same "rule" that
would prevent homo-anarchist articles (for instance :-) -- and
eventually anything else not lowest-common-denominator.
FidoNews is *not* an L.C.D. trade rag. It has no pretense towards an
Industry newsletter. It is by and for FidoNet sysops, users and other
people we consider "members", and I can tell you plain that FidoNet
is not a monolith, the diversity is incredible and only our institu-
tional policies prevents this from being clearer.
FidoNews, like FidoNet, was an experiment, and I believe we can all be
proud of it's success -- for all the flaming, ill will and trouble we
go through, we have one of the most reliable, resilient and *fiercely
independent* organizations on the planet. I wouldn't have it any other
way! It is not supposed to be easy -- convenience is not a good goal.
So the policy remains in effect with one change -- there is a minimal
writing standard, for clarity, not content -- that articles must meet,
to ensure that they are intelligible to someone other than its author.
The article-submission guidelines file, ARTSPEC.DOC, has been
revamped, and is included in this issue of FidoNews as an article. The
various "departments" of FidoNews will also be changed. "Column" type
articles are no more; you must submit each one separately. Notices,
sale items and want-ads will be converted into a more general
"classifieds" section in the near future.
The format for FidoNews will change further. The current format is one
of those things I did in 1984 that is today very puzzling -- an
electronic newsletter designed to be copied to a printing device! It
is nearly impossible to read online. It is wasteful of space, on both
disk and printer. The left margin alone (now gone) accounted for 10%
of its size. The tentative goal is to keep FidoNews under 100K bytes
FIDONEWS 13-36 Page 17 2 Sep 1996
in size.
We will be actively soliciting articles from people with interesting
perspectives in FidoNet and the world beyond on issues and problems
that face us as a network in the real world. Though we are
accommodating access to/from other networks such as the Internet and
uucp, FidoNews will remain 100% a FidoNet newsletter.
Some time later this year, the format of FidoNews will be plain text
without pagebreaks, long dash lines and formfeed characters. End-of-
section markers will be ASCII characters. It will then be readable
online. All computer systems today have a way to "pretty print" ASCII
text files, so that is no longer a valid reason.
Sorry for the terse editorial, we're under a severe time limit to
learn the software, file conventions and to get an issue out on time.
By next week things will be under more control, and we can get down to
the business at hand -- communicating, instead of talking about the
communications device!
----------------------------------------------------------------------
I guess you noticed that there are new names for the "Editors" on the
Masthead. One you may recognize as the "papa" of this mess, Tom
Jennings. Well, I'm the other name. My name may be associated with
another mess, the linking of FidoNet to a network called UUCP and a
conferencing system called USENET. (*)
Which brings up the point of this essay. FidoNet users and sysops, for
the most part, are not aware that there are other networks out there.
We tend to be a bit ethnocentric in our views of the networking world.
With the advent of gateways into other networks from RBBS-NET to non-
fidonet based technologies like UUCP, USENET, and the Internet, we
need to be more aware of other customs and technologies. (For example,
not everyone can display the IBM-PC character set, or perhaps we
should look at the method of our network addressing so it is easier to
send and receive mail from these other networks. We'll look at these
things in later issues.)
To this end, we hope to include more articles that are not only
related to FidoNet, but to networking and communications as a whole.
This is not to say that FidoNews will loose it's FidoNet flavor, we
just want to give the readership an idea on what else is out there,
and include what Sysops and Users may have some interest in.
For instance, the Electronic Frontier Foundation, Inc. (EFF) is
working to educate folks (lawyers, law enforcement, policy makers,
sysops, hackers, and crackers) about the hysteria and misinformation
that our government and law enforcement agencies seem to be going
through and trying to spread about electronic communications. Our
basic civil rights are being affected due to the ignorance of these
agencies. The EFF is also supporting many of those affected by paying
or helping with legal costs.
On other subjects, how many know of the resources that are available
via the Internet? There are a number of "News" services that can add
FIDONEWS 13-36 Page 18 2 Sep 1996
value to your BBS. There are archives that will easily shadow the
biggest FidoNet archive sites.
We just can't hide our head in the sand with all of the potential that
FidoNet can be, and the threats to FidoNet from the ill informed.
Tim Pozar
Fido: 1:125/555
Internet: pozar@lns.com
---
* I'm not the only one to blame here. John Galvin, Garry Paxinos and I
co-wrote the code, and a host of others like David Dodell and Randy
Bush tested it.
----------------------------------------------------------------------
FidoNews 10-09 Page 1 1 Mar 1993
======================================================================
EDITORIAL
======================================================================
Editorial: Bye bye!! (boo hoo!)
Well this is it, my final editorial. Next week's will be edited by
Silvia Maxwell and Don Tees. Say hi to them. (Hi!)
Today is a momentous day for me. I'm moving into a new apartment this
very day, tomorrow my phone lines get swapped over. As soon as I
finish this, I have to pack more boxes and drag 'em over. We're moving
from out in the boonies to the heart of the Mission; 16th St between
Mission and Valencia. The three little holes in my windows turned out
to be bullet holes! (22 or 25 cal.) The glass is
double-paned, and I was able to locate the trajectory. Later, I pull
down the shade, and there's matching holes! Yipes! Oh well, instead of
a 45 minute walk to the cafe, it's about 120 seconds, a vast
improvement. No more do I have to pay $1 for a bus, down on the corner
I can buy a "late nite" (daily bus transfer) for 25 cents! ("I love,
livin' in the city!" -- FEAR)
I digress.
Oh, probably there'll be small mistakes made, but be helpful and nice.
Our new editors have to decipher my 4DOS batch files, and generate a
newsletter that's at least recognizable and somehow get it to 1:13/13.
In a week.
I look forward to seeing what changes they make. I failed to keep one
promise, that of revamping the newsletter format from "line printer"
format to online readable. I really blew the "Ask EFF!" project,
though Shari Steele is hanging in there raring to go.
Think back on all the little wars we've had... Zone 2 hassles... Z1C
"process" or lack of... POLICYx... encryption... I'm begging off just
in time to miss the "Caller ID" wars -- YAY!!! (You know it's time to
FIDONEWS 13-36 Page 19 2 Sep 1996
leave when...)
It's been fun, really!! Even the hard parts I learned a lot, about
taking my lumps when necessary, and staying the hell out of local
squabbles.
So ta-ta, I'll see you out in the cloud...
My BBS is going to go offline for a while, probably a month or two,
starting this week. I will have an email address however, but it's on
the Internet. It's
tomj@fido.wps.com
My old DOS machine is now running 386BSD and directly connected to the
internet. In itself an interesting story, and one you'll probably see
in these pages and BOARDWATCH magazine.
Anyways -- you can email me from FidoNet, via certain FidoNet nodes
flagged "GUUCP". Those are UFGATE sites, that have one foot each in
FidoNet and Internet. There's a bunch of then. The way it works is
you send a message to one of those FidoNet addresses, with certain
magicwords placed within the message itself, that the UFGATE software
detects. These are: the "to:" field being the single word UUCP. The
VERY FIRST line of the message formatted exactly as:
to: tomj@fido.wps.com
With at least one completely blank line following it. After that, put
your real message. Make sure you have the address (ie. the to: line
embedded in the message body) correct, otherwise your message won't
make it.
-------------------------------*********------------------------------
Sylvia Maxwell and Don Tees:
FidoNews 10-10 Page: 2 07 Mar 1992
======================================================================
Editorial
======================================================================
Hello World.
Brand new green editors here. No editorial policy at all...
just anarchy. I used to have a dream about how network
communications would free people from visually, geographically
and aurally enforced stereotypes like age, gender, nationality,
class... but upon reflection of mail this dream seems tame and
lame. The image of "everyone in the room, more or less armed to
the teeth, and no casualties" (thank you Tom Jennings) seems
more generative and fun. Electronic word travel enables a grand
experiment in reductio ad absurdum of normal human contact that
might fly anywhere willed by any one of us.
It has been a hectic week. Getting software to generate the news
set up, arranging passwords and paths for distribution, and
setting up an internet gateway so that we can get flames from
FIDONEWS 13-36 Page 20 2 Sep 1996
all directions. I think that everything is ready to go, but will
apologize in advance for the inevitable teething pains. Please
note the new addresses.
Last but not least, we would like to thank Tom Jennings for his
immense contribution to this medium, and say "well done". We
hope, Tom, that we will be seeing contributions in the future
(after a well deserved rest, of course <S>).
----------------------------------------------------------------------
FidoNews 13-18 Page: 2 29 Apr 1996
======================================================================
Editorial
======================================================================
Once again, there are no articles in the inbound. I think,
perhaps, that the writer of a few weeks back was correct. I
think that perhaps I should resign this post. I would welcome
letters suggesting a new editor.
----------------------------************------------------------------
Christopher Baker:
FidoNews 13-23/24/25/26/27 Page: 2 3 Jun - 1 Jul 1996
======================================================================
Editorial
======================================================================
The last issue of FidoNews published by Donald Tees appeared on
27 May 96 [Issue 1322]. Since then nothing has been heard from the
former Editor. This issue is a manual composite comprising Issues 23
through 27 for the sake of numbering continuity and historical
reference. [see Header]
FidoNews is now edited by yours truly from 1:374/14, Rights
On!, in Titusville, FLorida, USA. The Nodelist adjustment to the
FidoNews listing will appear in NODELIST.194 next Friday [12 Jul 96].
In the meantime, you may wish to set a temporary override for 1:1/23
to reflect the following telephone number: 407-383-1372. Flag
override should be: CM,H14,V32B,XA as well.
FidoNews submissions may be made to 1:1/23 as before or to my
Internet address: cbaker84@digital.net. Submission standards are
available in the file ARTSPEC.DOC from this system anytime except
Zone 1 ZMH [0900-1000 UTC/GMT]. ARTSPEC.DOC has also been sent to
every Zone Coordinator for distribution down the chain. Submissions
made as Netmail or email require manual processing so allow more lead
time for the issue in which you wish to have it appear.
FidoNews Issue 28 will put the standard numbering and submission
processing back on track for 1996 [Vol. 13].
----------------------------------------------------------------------
FIDONEWS 13-29 Page 1 15 Jul 1996
=================================================================
EDITORIAL
=================================================================
FIDONEWS 13-36 Page 21 2 Sep 1996
FidoNet has come a long way since it began over twelve years ago.
But how far has it come lately?
There hasn't been any discernable movement toward selecting an
International Coordinator [IC] from the current field of 6 Zone
Coordinators [ZC]. Are we ever going to get one and move along in
the areas of Policy and Standards?
As our guest editorial indicates, we don't even have regular updates
from the other Zones for the master Nodelist. Where are the diffs
[Nodelist difference files] from Zones 2-6? Are they getting ours
from Zone 1? This still is an INTERNATIONAL hobby, isn't it?
Are there any reports from the FTSC [FidoNet Technical Standards
Committee] on the state of our Standards? Updates to our practices?
Presumably, software authors are still at it and things have changed
in the last couple years, yes?
Hello, out there! Here's your vehicle for spreading your news. How
about some chiming in from the ZCs and FTSC Chair? What gives? Talk
to us!
CB
NOTE: This Issue contains ALL the new sections available. Some of
them may just be dummy files to show their locations and use.
ARTSPEC.DOC has been updated to include them. Also see the
FIDONEWS Echo for details. All sections will not appear in
all Issues depending on what is submitted.
-----------------------------------------------------------------
-----------------------------------------------------------------
FIDONEWS 13-36 Page 22 2 Sep 1996
=================================================================
REVIEWS
=================================================================
Six Mail Processors Reviewed [III]
Damian Walker, 2:2502/666
This is the third article in my six-part series looking at the
capabilities of various mail processors. The first and second
articles were about FastEcho and GEcho, and in this article I progress
to FMail. A full feature table for all six mail processors will be
included in the sixth and final article of the series.
FMAIL
Fmail is a mail processor written by Folkert J Wijnstra of
2:283/619. The version reviewed in this article is FMail/X 1.02.
Unlike the versions of FastEcho and GEcho under review, this version
of FMail is optimised for 386 processors and above, and so will be
faster (the 386 test machine) than an 8086 version. Please take this
into account when looking at the speed ratings. Versions for OS/2 and
8086 DOS machines are also available.
First Impressions
Upon first unpacking FMail, its compactness is noticeable. One
could be forgiven for thinking that FMail might be underfeatured when
looking at the size of its archive (if one judges a package by such
things, that is). While FMail doesn't have the exhaustive range of
features possessed by FastEcho and IMail, it certainly couldn't be
described as under-featured.
The manual seems rather small at 54 pages. Although you would
expect the manual to be smaller than that for larger packages such as
FastEcho, comparing it to GEcho's manual of around 100 pages shows
that this might be a cause for adverse comment. But this is without
taking the content of the manual into consideration-- size isn't
everything.
Looking at the directory of newly unpacked files we see that FMail
contains a full-screen setup utility (FSETUP.EXE or FSETUPX.EXE), so
configuration by those who do not like editing text files will not be
a problem.
On Further Examination...
The first interesting thing to point out about FMail is that it
doesn't support *.MSG areas for echomail. This will probably not be
counted against FMail by most sysops, as echomail is rarely held as
*.MSG areas on a DOS machine. Squish is not supported either, but the
common Hudson and JAM areas are both supported, so while FMail's
coverage of area types isn't fully comprehensive, it is enough for
most needs.
FMail's setup program offers a nice interface in the usual Fidonet
program style. The only thing lacking is an on-line help system, so
if you're not using a multitasking machine and you want to look
something up, you will have to exit FSETUP, and re-load it again
FIDONEWS 13-36 Page 23 2 Sep 1996
afterwards (hoping you can remember whatever it was you looked up).
Needless to say, some form of on-line help would be an improvement,
even if it was only a manual viewer like that used by GEcho.
Like most of the other programs reviewed here, FMail includes its
own areafix manager, allowing downlinks to fix into echoes and
automatically forwarding requests to an uplink if necessary.
Unfortunately it lacks the 'import description' facilities of GEcho
and FastEcho, so if you wish to set up a large number of areas
manually, you will need to find and type their descriptions
individually.
FMail has a feature which automatically adds areas to the
configuration files for itself and other software. Rather than being
added on the fly as FastEcho does it (ie. adding areas as mail is
being processed), FMail waits until the next time you enter its setup
program, and then asks you if you want to add the areas.
This has the disadvantage that the process is not fully automatic,
but it has the advantage that the process is not fully automatic :-)
In more serious terms, the FastEcho method is better for sysops who
would like to set up defaults and allow their system to automatically
add new echoes to the area database without the need for human
intervention, whereas FMail's method encourages more control over the
adding of new areas so you can be sure that areas are not being added
unless you want them to be.
The carbon copy feature, while not as flexible as that used by
FastEcho, is a cut above normal personal mail options in that you can
also direct mail to your 'personal' directory which contains up to two
keywords in the subject line. It also has an option to include the
netmail area in the scan.
Sysops can thus take a special interest in messages about their
BBS or node, moderators can do the same for their echo and software
authors can monitor opinion of their programs, all aided by FMail's
automatic scanning of subject lines.
The only downside of this feature is that it appears only to allow
*.MSG areas for personal mail (the option specifies a _directory_ but
there is no mention of a Hudson Message Board or JAM path).
One surprising and possibly limiting aspect of FMail is in the
fact that the 8086 version can hold only 512 echoes. If you want to
have all available echoes in your area database (as I do) then 512
might not be enough; I believe the zone 1 backbone has more echoes
than this, as does the Region 25 backbone which is more local to me.
If you are also active in other networks, this limit can make you feel
a bit claustrophobic. The 386 version has more comfortable space for
4096 echoes, which should be enough unless you take newsgroups and
want to list all 18,000 or so.
FastEcho shares with GEcho the option of moving the netmail marked
as Rcvd and Sent to special message areas (albeit only to *.MSG areas
in FMail's case). Unlike GEcho's similar option, sent/received file
attaches will not be moved. However, FMail has the extra option of
copying sent echomail messages as well as netmails; this is a handy
way of keeping track of what you've said to whom (useful in flame
wars, perhaps?)
One useful feature that FMail has is the option to reroute netmail
to points. Traditionally a task performed by netmail trackers, its
inclusion in FMail allows sysops to forego the pleasure of setting up
a separate netmail tracker if this is the only netmail tracker style
feature they need. Of the packages reviewed here, only Squish shares
FIDONEWS 13-36 Page 24 2 Sep 1996
this feature.
Speed is one feature which FMail has above all the other packages
tested, although one has to bear in mind that of all the packages
tested, only with FMail, Squish and IMail have the 386 versions been
used, so it is only to be expected that these will perform better than
the 8086 versions of other packages. Still, comparing the performance
of FMailX to that of IMail 386, we can see that it is a very
impressive package.
In the Hudson message toss test, where 91 messages were imported
into a newly-created Hudson message base, FMailX completed the task in
a sprightly 7 seconds. The same feat performed upon an empty set of
JAM areas yielded a performance of 12 seconds.
The documentation is not inadequate, but it does not seem as good
or comprehensive as that for the two packages already reviewed. This
is not too much of a problem as the software is easy to set up (even
without a help system), but I have experienced difficulty in looking
up certain features in the manual.
For instance, I could not find anything about FMail's behaviour in
creating new areas when mail in unknown areas arrives. Doubtless it
is in there somewhere, but neither the contents nor the index (yes,
there is an index) were any use in finding out what I wanted to know.
I had to resort to an actual testbed setup in order to find out
exactly how FMail treats these messages.
However, the documentation wasn't written with nosy reviewers like
myself in mind, so perhaps I am judging it from the wrong perspective.
Summary
FMail is a compact yet powerful mail processor which should
satisfy the needs of most sysops with mainstream mail processing
needs. Larger echomail hubs may find its limit on the number of
message areas a little too limiting, yet they, along with other users,
will find its impressive speed useful for processing large amounts of
echomail.
With its auto-add capability for new message areas, points will
find it an acceptable yet still compact alternative to GEcho (the
popular choice for power points), allowing them to add areas to their
whole setup with a single areafix message.
While a few features, such as a help system for FSETUP and an easy
way to import descriptions, would not go amiss, it couldn't be said
that FMail is in desperate need of any major improvements. As a
compact, fast, mail processor it is hard to beat.
Next week comes the fourth article in this series, where I will
turn my attention to IMail, which is the creation of Andreas Klein.
-----------------------------------------------------------------
FIDONEWS 13-36 Page 25 2 Sep 1996
=================================================================
COORDINATORS CORNER
=================================================================
Nodelist-statistics as seen from Zone-2 for day 243
By Ward Dossche, 2:292/854
ZC/2
+----+------+------------+------------+------------+------------+--+
|Zone|Nl-215|Nodelist-222|Nodelist-229|Nodelist-236|Nodelist-243|%%|
+----+------+------------+------------+------------+------------+--+
| 1 | 12691|12622 -69 |12530 -92 |12435 -95 |12313 -122 |39|
| 2 | 16462|16426 -36 |16408 -18 |16391 -17 |16366 -25 |52|
| 3 | 1023| 1023 0 | 1023 0 | 969 -54 | 966 -3 | 3|
| 4 | 637| 637 0 | 637 0 | 638 1 | 634 -4 | 2|
| 5 | 99| 99 0 | 99 0 | 99 0 | 99 0 | 0|
| 6 | 1018| 1020 2 | 1020 0 | 1020 0 | 1020 0 | 3|
+----+------+------------+------------+------------+------------+--+
| 31930|31827 -103 |31717 -110 |31552 -165 |31398 -154 |
+------+------------+------------+------------+------------+
-----------------------------------------------------------------
FIDONEWS 13-36 Page 26 2 Sep 1996
=================================================================
ECHOING
=================================================================
GENERAL ECHOMAIL POLICY 2
Applicable to Zone 2 only
August 21, 1996
Steve Woodmore ZEC/2
PROLOGUE
This document sets forth policy governing Echomail conferences
and their distribution.
For the purposes of this document a simple majority exists when
one candidate has more votes than any other at the closing date,
or when a proposal has more votes in favour of it than against
it. Only the votes of those who actually vote will be counted for
establishing the total number of votes cast, or for establishing
whether a simple majority exists.
This Policy applies to Zone Two 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 only by
a simple majority vote of the Regional Echomail Coordinators.
Those eligible to vote on any proposals made by the REC structure
will be the ZEC, RECs, NECs, NCs, RCs and IC. Only one vote per
person is allowed. Adoption of changes will require a simple
majority of those voting to pass.
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
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
Regional Echomail Backbone formed whose primary purpose is the
distribution of Echomail at a Regional 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.
FIDONEWS 13-36 Page 27 2 Sep 1996
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
voluntary members who provide services to enhance the Regional
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. REGIONAL ECHOMAIL LIST: The Regional Echomail List
identifies the available Regional conferences, the conference
moderator and requirements of the specified conference. The REC
will appoint the keeper of the Regional 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 Policy4
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
FIDONEWS 13-36 Page 28 2 Sep 1996
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 information available as to where to obtain feeds
for 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 a policy complaint of
Extremely annoying behaviour as defined by Policy4. 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.
A *EC shall do everything in their power to ensure 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 Regional 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-
FIDONEWS 13-36 Page 29 2 Sep 1996
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
regional 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 ensure that the moderated conference
does not distribute or promote illegal activities or information
as defined below in Section V Paragraph 2. The Moderator shall
be responsible for ensuring 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 next system within the *EC chain, {see note1}
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
FIDONEWS 13-36 Page 30 2 Sep 1996
NEC 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
Moderator level first If the sysop is unhappy with the moderators
decision, then they have the right to continue "up" the *EC chain as
defined in note1.
The "Moderator" is in essence the person "owning" the conference,
and generally the *EC chain will side with that moderator in the event
of a complaint. The appeal structure is in place to prevent so-called
"Vindictive" moderators from denying access for trivial reasons.
Fidonet is deemed to be a Free and open network, and designed to
encourage people to take part in echomail, and at that same time
discourage people from acting in a socially unacceptable manner.
For severe or chronic infractions the NEC, REC or ZEC may file
a complaint under general Fidonet policy for excessively annoying
behaviour.
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
two years has elapsed.
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.
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 call an election within that region.
b) 10 days after the candidates have come forward 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
FIDONEWS 13-36 Page 31 2 Sep 1996
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.
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. The IC recognizes a conference to be inter-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
forthcoming vote. Notice mediums acceptable are: Netmail from the
ZEC, usage of international postings in such conferences as
COORD. Or in extreme instances, by REC to NEC written
notification.
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 REC (or his delegate). This delegate
should not be from the 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
FIDONEWS 13-36 Page 32 2 Sep 1996
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.
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 not be
recovered. A Sysop that charges users for access to their BBS
shall NOT be in violation of this paragraph.
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. PATH REQUIRED: The PATHline, originally implemented by SEA
in the MGM package, is required except for terminal nodes. If
FIDONEWS 13-36 Page 33 2 Sep 1996
your current Echomail scanner supports the pathline you must
enable it NOW. If your current Echomail scanner does not support
the pathline, and if there is no alternative scanner, then
enforcement of this paragraph will be deferred for 60 days.
After that date, the *ECs may refuse to accept/supply echomail to
any node that is not supporting the pathline.
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.
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 exchanges may consist of any
type of archival storage format agreed upon by both parties.
SEA's ARC 5.1 (non-Squashing) archival storage format will be the
"fallback" if either party is unable or unwilling to support an
alternate method. The continued use of Echomail software without
prior agreement of both the sending and receiving nodes which
interferes with the distribution of echomail shall lead to
disciplinary action as described previously in this document.
See Section III. Examples of prohibited software would include
the use of non-standard echomail packets which can not be
processed by the receiving system. Another example would be the
use of poorly implemented scanners or tossers that cause
duplicates or fail to forward messages to downstream links. A
further example is the use of Tiny seenby options and the use of
^A hidden SEEN-BY lines. Use of 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.
The Software Certification Committee is authorized to determine
FIDONEWS 13-36 Page 34 2 Sep 1996
whether software meets minimum standards for use on the net.
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. SENDING OF ECHOMAIL DURING ZONE MAIL HOUR: Transmission of
echomail during Zone Mail Hour as defined in Fidonet policy
without the consent of the receiving system shall lead to
disciplinary action as described previously in this document.
See Section III.
14. 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.
15. 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.
16. ADDING OR REMOVING CONFERENCES FROM THE Backbone: A
conference may be added to the Backbone only by request of the
RECOGNIZED Conference Moderator. A conference may be removed
from the Backbone by lack of traffic. the REC shall review the status
of backbone echoes every 3 months. At which time those echoes
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 3 months to
improve their traffic or withdraw from Fidonet backbone
distribution. The recognized conference moderator may request
removal of their conference from the Fidonet backbone distribution at
their discretion.
17. 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
be established only with the permission of the REC in each
region. Each REC will do their best to make available high speed
hubs, out of country hubs, PC Pursuit hubs, etc, to facilitate the
low cost, efficient movement of mail within their respective
Region. If either REC has reason to believe duplicates are being
introduced into the system, an existing Cross Regional link must
be immediately cut pending resolution.
Any Sysop who willfully and knowingly establishes links that
either create duplicate loops (topology that creates circular
feeds), increase the risk of such loops or who refuses to break
FIDONEWS 13-36 Page 35 2 Sep 1996
those links upon request by their NEC, REC or ZEC shall be
subject to disciplinary action as described previously in this
document. See Section III.
18. MESSAGE STANDARDS: Until the adoption of a superseding
standard by the Fidonet Technical Standards Committee, the
following Echomail message standards will apply:
a) Eight-bit characters (ASCII 128-255) and non-printing
low-order codes (ASCII 2-31) are discouraged, and are at
the sole discretion of the relevant conference moderator.
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 are 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 are limited to 35 characters including the
required "--- " lead-in. These may 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 must be in sorted order. Multiple
AKAs 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 should 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. 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
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 EchoPol2 goes into
FIDONEWS 13-36 Page 36 2 Sep 1996
effect). A 30-day extension may be granted solely at the
discretion of the ZEC if efforts to bring about 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 RECs. The RECs must solicit the
opinions of their regions before voting.
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 REC of the relevant region from those
volunteering as moderator or if no volunteer is available then the
REC 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 REC 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 REC 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 REC. 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 information about 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 Document is designed as a stop-gap between the old EP1, and a
new Echopol document for this Zone, changes have been made at this
time only to reflect the differences between what was intended solely
for use within Zone One, and what is needed for Zone Two
This document is a temporary one, and may be modified either wholly or
FIDONEWS 13-36 Page 37 2 Sep 1996
in full by a vote among this regions RECs, after they have consulted
with their Regions. The voting on replacement either in part or in
full will be called by the ZEC/2. if more than 75% of the Zones RECs
decide that it needs replacing in full or in part, then the ZEC/2 must
attend to this matter as a priority.
Note1:
The appeal chain is always from the "bottom" upwards, IE if a
Node feels that his access to a conference has been unfairly
denied, he may appeal to his NEC, if this appeal is unsuccessful,
and the node still thinks the decision is unfair, then they may
step up to the REC for an appeal. If the node is still unhappy with
this decision, then they may appeal to the ZEC/2 whose decision will
be FINAL. During this appeal period, the Nodes conference access will
remain cut. The same applies if a sysop has any other complaints
regarding the Moderation of an echo
Steve Woodmore 2:440/410 ZEC/2
-----------------------------------------------------------------
FIDONEWS 13-36 Page 38 2 Sep 1996
=================================================================
WE GET EMAIL
=================================================================
--- Following message extracted from NETMAIL @ 1:374/14 ---
By Christopher Baker on Wed Aug 28 02:57:48 1996
From: Frank Ellermann @ 2:240/5815
To: Christopher Baker @ 1:374/14
Date: 28 Aug 96 05:57:00
Subj: question of the week 35
Hi Chris...
you find some old nodelists here (2:240/5815):
841123.NOD 8452 11.11.94 FIDO Nodelist 23.11.1984
841207.NOD 10930 02.10.94 FIDO Nodelist 7.12.1984
841228.NOD 10469 02.10.94 FIDO Nodelist 28.12.1984
850104.NOD 12289 02.10.94 FIDO Nodelist 4. 1.1985
FIDO1986.276 93041 21.11.95 FIDO nodelist 1986, day 276
FIDO1988.008 223103 08.01.88 FIDO nodelist 1988, day 008
FIDO1989.216 464875 18.08.95 FIDO nodelist 1989, day 216
FIDO1990.180 654078 17.02.95 FIDO nodelist 1990, day 180
FIDO1991.144 929797 17.08.96 FIDO nodelist 1991, day 144
FIDO1992.003 1169590 03.01.92 FIDO nodelist 1991, day 003
FIDO1993.169 2045640 18.06.93 FIDO nodelist 1993, day 169
FIDO1993.183 2014703 10.11.94 FIDO nodelist 1993, day 183
(after R24 Putsch)
More complete collectins based on a few list and following
NodeDiffs are available at Jan Vermeulen (RC2:28), Gisbert
Rudolph (2:2443/2161) and Ralph Mahler (2:2433/433). You
may notice that these nodes are a subset of those mentioned
in my answer to your snooze back issues question of the
week.
Greets, Frank
-----------------------------------------------------------------
--- Following message extracted from NETMAIL @ 1:374/14 ---
By Christopher Baker on Tue Aug 27 15:37:06 1996
From: jan n. klug @ 2:2448/610
To: Christopher Baker @ 1:374/14
Date: 27 Aug 96 19:45:20
Subj: old nodelists!
hi chris!
nodediffs:
FIDONEWS 13-36 Page 39 2 Sep 1996
DIFF1991.ZIP FidoNet NodeDiff-Files, 1991
(since 130)
DIFF1992.ZIP FidoNet NodeDiff-Files, 1992
DIFF1993.ZIP FidoNet NodeDiff-Files, 1993
DIFF1994.ZIP FidoNet NodeDiff-Files, 1994
DIFF1995.ZIP FidoNet NodeDiff-Files, 1995
DIFF1996.ZIP FidoNet NodeDiff-Files, 1996
nodelists:
NL84_327.ZIP Nodelist, Day 327, 1984
NL84_341.ZIP Nodelist, Day 341, 1984
NL84_362.ZIP Nodelist, Day 362, 1984
NL84_JUN.ZIP Nodelist, June 1984 (PCX-Format)
NL85_004.ZIP Nodelist, Day 004, 1985
NL86_276.ZIP Nodelist, Day 276, 1986
NL89_167.ZIP Nodelist, Day 167, 1989
NL89_216.ZIP Nodelist, Day 216, 1989
NL90_026.ZIP Nodelist, Day 026, 1990
NL90_145.ZIP Nodelist, Day 145, 1990
NL90_180.ZIP Nodelist, Day 180, 1990
NL90_229.ZIP Nodelist, Day 229, 1990
NL91_144.ZIP Nodelist, Day 144, 1991
NL93_169.ZIP Nodelist, Day 169, 1994 (last before Putsch-Diff)
these nodelists are also available. if there are only some nodelists
oder nodediffs missing, tell me and i will send you some, but i'm
sorry, i cannot afford sending so much files to you. (about $150 :-()
jan
-----------------------------------------------------------------
FIDONEWS 13-36 Page 40 2 Sep 1996
=================================================================
PROOFREADERS REPORT
=================================================================
A Netmail cookie to Damian Walker at 2:2502/666:
--- Following message extracted from NETMAIL @ 1:374/14 ---
By Christopher Baker on Fri Aug 30 14:40:38 1996
From: Damian Walker @ 2:2502/666.3
To: Christopher Baker @ 1:374/14
Date: 26 Aug 96 13:21:36
Subj: Something about FidoNews (probably)
Hi Chris,
I just spotted a little error in the Fidonews masthead:
> FNEWSD34.ZIP FidoNews, Vol. 13, Nr. 31 (August 19, 1996)
> FNEWSD35.ZIP FidoNews, Vol. 13, Nr. 32 (August 26, 1996)
> (etc) ^^
FNEWSD35.ZIP is issue 35, isn't it?
>> Damian <<
[it sure is! i forgot to update that part when i changed the front
part [grin]. it's fixed now. thanks!] Ed.
-----------------------------------------------------------------
FIDONEWS 13-36 Page 41 2 Sep 1996
=================================================================
NET HUMOR
=================================================================
They don't mean Fido, do they?
From: "Mike Riddle" <mriddle@monarch.papillion.ne.us>
To: "Baker, Christopher" <cbaker84@digital.net (Christopher
Baker)>
Date: Wed, 24 Jul 96 09:21:15 -0500
Reply-To: "Mike Riddle" <mriddle@monarch.papillion.ne.us>
Subject: Fwd: 2 DRUNKS & A DOG
==================BEGIN FORWARDED MESSAGE==================
Received: from shenessex.heartland.net (root@SHENANDOAH.HEARTLAND.NET
[206.72.57.253]) by monarch.papillion.ne.us (8.7.4/8.6.9) with SMTP id
BAA14607 for <mriddle@monarch.papillion.ne.us>; Wed, 24 Jul 1996
01:09:49 -0500 (CDT)
Date: Wed, 24 Jul 1996 01:00:26 -0500
From: jenniferrose <jjrose@shenessex.heartland.net>
Reply-To: jjrose@shenessex.heartland.net
Subject: 2 DRUNKS & A DOG
Two drunks are staggering down the sidewalk when they both espy a dog
cleaning himself. One drunk says, "Gee I wish I could do that!" To
which the other drunk replies, "Don't you think you should pet him
first?"
===================END FORWARDED MESSAGE===================
-----------------------------------------------------------------
FIDONEWS 13-36 Page 42 2 Sep 1996
=================================================================
COMIX IN ASCII
=================================================================
Date: 28 Aug 96 19:41:15
From: Deb Milner
To: Dave Raymond
Subj: Chain Of Command
_____________________________________________________________________
Sunday August 25 1996 14:17, Dave Raymond wrote to Dale Ross:
DR> --------------------------|\
DR> |---------------------------|
DR> || Your message has been |
DR> || carefully placed in | |------|
DR> || its very own, specially | -- |-+--+-|
DR> || prepared, luxuriantly | || 0| |
DR> || hand crafted porcelain | || | |
DR> || filing Cabinet where | || | |
DR> || it will receive the | _____________|| | |
DR> || dignity and attention | (_______________) |------|
DR> || it deserves. ------> | ( )----| |
DR> || Thank you. | ( )-------|
DR> || Dave Raymond | (_________)
DR> || FidoNet 1:3603/200 |
DR> \|--------------------------|
DR> Just Hit Enter/Next to flush.!
Stolen...<G>
De Colores,
Deb
dmilner@southeast.net
Origin:Wolverine's Asylum, past the boonies in Macclenny,FL(1:112/285)
-----------------------------------------------------------------
FIDONEWS 13-36 Page 43 2 Sep 1996
=================================================================
QUESTION OF THE WEEK
=================================================================
The Zone 1 Backbone produces a complete list of the Echos it carries
every week. Zone 2 appears to do likewise although receipt of them is
sporadic at best in Zone 1.
The Question of the Week is:
Do the other Zones produce Echolists in their Zones? What are they
called? Where are they available? How often are they produced? Who
distributes them and to whom?
Send answers as .ART, Netmail, email, or in the FIDONEWS Echo.
Thanks.
-----------------------------------------------------------------
FIDONEWS 13-36 Page 44 2 Sep 1996
=================================================================
NOTICES
=================================================================
Future History
12 Oct 1996
General Elections, New Zealand.
29 Oct 1996
Republic Day, Turkey.
5 Nov 1996
Election day, U.S.A.
5 Nov 1996
Guy Fawkes Day, England.
1 Dec 1996
Twelfth Anniversary of FidoNews Volume 1, Issue 1.
12 Dec 1996
Constitution Day, Russia
26 Jan 1997
Australia Day, Australia.
6 Feb 1997
Waitangi Day, New Zealand.
16 Feb 1997
Eleventh Anniversary of invention of Echomail by Jeff Rush.
29 Feb 1997
Nothing will happen on this day.
11 Jun 1997
Independence Day, Russia
26 Jul 1997
FidoNews Editor turns 48.
6 Dec 1997
Gallileo takes close-ups of Europa to resolution
of 11 meters at the north pole.
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.
15 Sep 2000
Sydney (Australia) Summer Olympiad opens.
FIDONEWS 13-36 Page 45 2 Sep 1996
-- If YOU have something which you would like to see in this
Future History, please send a note to the FidoNews Editor.
-----------------------------------------------------------------
FIDONEWS 13-36 Page 46 2 Sep 1996
=================================================================
FIDONET SOFTWARE LISTING
=================================================================
Latest Greatest Software Versions
by Peter E. Popovich, 1:363/264
This week was unique: an inbound chock full of completed forms but
not enough time to process them all. Several required clarification,
I hope to have them all included for next week. At this point, I'm
tempted to do my Jewish impression: "Oy vay, if you had the week that
I had, you'd be impressed there was a column at all!"
One note: Several authors have sent in internet style addresses for
inclusion in the list. I'm not about to flame anyone; but I should
probably explain my mindset:
It is my hope to find a Fidonet contact address and a FREQ name for
each package. While I'll always try to respect the author's wishes,
I'd far rather run info on a secondary Fidonet site than run a URL
for a primary web site. This isn't so much a political view as it is
an attempt to ensure that nodes who read Fidonews need look no
further than this list for addresses they're sure to have access to.
Also, I encourage listing every current version of a package for
every platform that it has a native binary for. I'm happy to run FD
2.12 and 2.20c. I'm happy to run Maximus for DOS, OS/2, and Win32.
But I don't think I can, in good conscience, run an extra entry just
to list a support contact.
On the other hand, there are no hard and fast rules. I originally
planned to reject any entry I couldn't stuff into one line; "Silver
XPress Reader" and "Joaquim Homrighausen" disabused me of that notion
quickly... ;-)
Phased out this week: ADTBBS 1.50.
Phase-out highlights:
This week: DMG 2.93 Deadline for info: 12 Sep 1996.
Last week: Aurora 1.32b. Deadline for info: 6 Sep 1996.
-=- 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.
FIDONEWS 13-36 Page 47 2 Sep 1996
Please send updates and suggestions to: Peter Popovich, 1:363/264
-=- Snip -=-
MS-DOS:
Program Name Version F S Contact Name Node Magic Name
----------------------------------------------------------------------
FidoBBS (tm) 12u B S Ray Brown 1:1/117 FILES
FrontDoor 2.12 M S Joaquim Homrighausen
2:201/330 FD
FrontDoor 2.20c M C Joaquim Homrighausen
2:201/330 FDINFO
GIGO 07-14-96 G S Jason Fesler 1:1/141 INFO
Imail 1.75 T S Michael McCabe 1:297/11 IMAIL
InfoMail 1.11 O F Damian Walker 2:2502/666 INFOMAIL
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
Maximus 3.01 B P Gary Gilmore 1:1/119 MAX
McMail g5 M S Michael McCabe 1:1/148 MCMAIL
Opus CBCS 1.73a B P Christopher Baker 1:374/14 OPUS
PlatinumXpress 1.1 M C Gary Petersen 1:290/111 PX11TD.ZIP
Silver Xpress
Door 5.4 O S Gary Petersen 1:290/111 FILES
Reader 4.3 O S Gary Petersen 1:290/111 SXR43.ZIP
SquishMail 1.11 T P Gary Gilmore 1:1/119 SQUISH
OS/2:
Program Name Version F S Contact Name Node Magic Name
----------------------------------------------------------------------
GIGO 07-14-96 G S Jason Fesler 1:1/141 INFO
Maximus 3.01 B P Gary Gilmore 1:1/119 MAXP
SquishMail 1.11 T P Gary Gilmore 1:1/119 SQUISHP
Windows (32-bit apps):
Program Name Version F S Contact Name Node Magic Name
----------------------------------------------------------------------
Maximus 3.01 B P Gary Gilmore 1:1/119 MAXN
PlatinumXpress 2.00 M C Gary Petersen 1:290/111 PXW-INFO
Unix:
Program Name Version F S Contact Name Node Magic Name
----------------------------------------------------------------------
ifmail 2.8e M G Pablo Saratxaga 2:293/2219 IFMAIL
ifmail-tx 2.8e-tx7.6 M G Pablo Saratxaga 2:293/2219 IFMAILTX
F: B-BBS, M-Mailer, N-Nodelist, G-Gateway, T-Tosser, C-Compression,
O-Other. Note: Multifunction will be listed by the first match.
S: P-Free for personal use, F-Freeware, S-Shareware, C-Commercial,
X-Crippleware, G-Source
Other info (pending verification or other work on my end):
MS-DOS:
FIDONEWS 13-36 Page 48 2 Sep 1996
Remove Tritel 2.0; Add TriBBS 10.0, TriToss 10.0, and TriDog 10.0
by Mark Goodwin 1:328/104, shareware
Update: D-Bridge 1.58, BinkleyTerm 2.60, ARJ 2.50,
ARC 6.02 (7.12 commercial), PKZIP 2.04g
Investigate: Xlax 2.54 (need clarification, XlaxDiff is up to 2.57)
Add: Announcer by Peter Karlsson, 2:204/145.42
MORON and QRATIO by Melle Koning, 2:281/731.29
Old info from: 01/27/92
---------------------------------------------------------------------
MS-DOS Systems
--------------
BBS Software NodeList Utilities Compression
Name Version Name Version Utilities
-------------------- -------------------- Name Version
Aurora 1.32b EditNL 4.00 --------------------
DMG 2.93 FDND 1.10 ARC 7.12
DreamBBS 1.05 MakeNL 2.31 ARJ 2.20
Genesis Deluxe 3.2 Parselst 1.33 LHA 2.13
GSBBS 3.02 Prune 1.40 PAK 2.51
Kitten 1.01 SysNL 3.14 PKPak 3.61
Lynx 1.30 XlatList 2.90 PKZip 1.10
Merlin 1.39n XlaxNode/Diff 2.53
Oracomm 5.M.6P@
Oracomm Plus 6.E@
PCBoard 14.5a Other Utilities(A-M) Other Utilities(N-Z)
Phoenix 1.07* Name Version Name Version
ProBoard 1.20* -------------------- --------------------
QuickBBS 2.75 2DAPoint 1.50* Netsex 2.00b
RBBS 17.3b 4Dog/4DMatrix 1.18 OFFLINE 1.35
RemoteAccess 1.11* ARCAsim 2.31 Oliver 1.0a
SimplexBBS 1.05 ARCmail 3.00* OSIRIS CBIS 3.02
SLBBS 2.15C* Areafix 1.20 PKInsert 7.10
Socrates 1.11 ConfMail 4.00 PolyXarc 2.1a
SuperBBS 1.12* Crossnet 1.5 QM 1.00a
SuperComm 0.99 DOMAIN 1.42 QSort 4.04
TAG 2.5g DEMM 1.06 RAD Plus 2.11
TBBS 2.1 DGMM 1.06 Raid 1.00
TComm/TCommNet 3.4 DOMAIN 1.42 RBBSMail 18.0
Telegard 2.7* EEngine 0.32 ScanToss 1.28
TPBoard 6.1 EMM 2.11* ScMail 1.00
TriTel 2.0* EZPoint 2.1 ScEdit 1.12
WildCat! 3.02* FGroup 1.00 Sirius 1.0x
WWIV 4.20 FidoPCB 1.0s@ SLMail 2.15C
XBBS 1.77 FNPGate 2.70 StarLink 1.01
GateWorks 3.06e TagMail 2.41
GMail 2.05 TCOMMail 2.2
Network Mailers GMD 3.10 Telemail 1.5*
Name Version GMM 1.21 TGroup 1.13
-------------------- GoldEd 2.31p TIRES 3.11
BinkleyTerm 2.50 GROUP 2.23 TMail 1.21
D'Bridge 1.30 GUS 1.40 TosScan 1.00
Dreamer 1.06 Harvey's Robot 4.10 UFGATE 1.03
FIDONEWS 13-36 Page 49 2 Sep 1996
Dutchie 2.90c HeadEdit 1.18 VPurge 4.09e
Milqtoast 1.00 HLIST 1.09 WEdit 2.0@
PreNM 1.48 ISIS 5.12@ WildMail 2.00
SEAdog 4.60 Lola 1.01d WMail 2.2
SEAmail 1.01 Mosaic 1.00b WNode 2.1
TIMS 1.0(mod8) MailBase 4.11a@ XRS 4.99
MSG 4.5* XST 2.3e
MSGED 2.06 YUPPIE! 2.00
MsgLnk 1.0c ZmailH 1.25
MsgMstr 2.03a ZSX 2.40
MsgNum 4.16d
MSGTOSS 1.3
OS/2 Systems
------------
BBS Software Other Utilities(A-M Other Utilities(N-Z)
Name Version Name Version Name Version
-------------------- -------------------- --------------------
Kitten 1.01 ARC 7.12 oMMM 1.52
Maximus-CBCS 2.00 ARC2 6.01 Omail 3.1
SimplexBBS 1.04.02+ ConfMail 4.00 Parselst 1.33
EchoStat 6.0 PKZip 1.02
EZPoint 2.1 PMSnoop 1.30
Network Mailers FGroup 1.00 PolyXOS2 2.1a
Name Version GROUP 2.23 QSort 2.1
-------------------- LH2 2.11 Raid 1.0
BinkleyTerm 2.50 MSG 4.2 Remapper 1.2
BinkleyTerm(S) 2.50 MsgEd 2.06c SquishMail 1.00
BinkleyTerm/2-MT MsgLink 1.0c Tick 2.0
1.40.02 MsgNum 4.16d VPurge 4.09e
SEAmail 1.01
Xenix/Unix 386
--------------
BBS Software Network Mailers Other Utilities
Name Version Name Version Name Version
-------------------- -------------------- --------------------
ARC 5.21
C-LHARC 1.00
MsgEd 2.06
|Contact: Willy Paine 1:343/15,| MSGLINK 1.01
|or Eddy van Loo 2:285/406 | oMMM 1.42
Omail 1.00
ParseLst 1.32
Unzip 3.10
VPurge 4.08
Zoo 2.01
QNX
FIDONEWS 13-36 Page 50 2 Sep 1996
---
BBS Software Network Mailers Other Utilities
Name Version Name Version Name Version
-------------------- -------------------- --------------------
QTach2 1.09 QMM 0.50s Kermit 2.03
QCP 1.02
NodeList Utilities Archive Utilities QSave 3.6
Name Version Name Version QTTSysop 1.07.1
-------------------- -------------------- SeaLink 1.05
QNode 2.09 Arc 6.02 XModem 1.00
LH 1.00.2 YModem 1.01
Unzip 2.01 ZModem 0.02f
Zoo 2.01
Apple II
--------
BBS Software Network Mailers Other Utilities
Name Version Name Version Name Version
-------------------- -------------------- --------------------
DDBBS + 8.0* Fruity Dog 2.0 deARC2e 2.1
GBBS Pro 2.1 ProSel 8.70*
ShrinkIt 3.30*
|Contact: Dennis McClain-Furmanski 1:275/42| ShrinkIt GS 1.04
Apple CP/M
----------
BBS Software Network Mailers Other Utilities
Name Version Name Version Name Version
-------------------- -------------------- --------------------
Daisy 2j Daisy Mailer 0.38 Filer 2-D
MsgUtil 2.5
Nodecomp 0.37
PackUser 4
UNARC.Com 1.20
Macintosh
---------
BBS Software Network Mailers Other Software
Name Version Name Version Name Version
-------------------- -------------------- --------------------
FBBS 0.91 Copernicus 1.0 ArcMac 1.3
Hermes 1.6.1 Tabby 2.2 AreaFix 1.6
Mansion 7.15 Compact Pro 1.30
Precision Sys. 0.95b EventMeister 1.0
Red Ryder Host 2.1 Export 3.21
Telefinder Host Import 3.2
2.12T10 LHARC 0.41
MacArd 0.04
Mantissa 3.21
FIDONEWS 13-36 Page 51 2 Sep 1996
Point System Mehitable 2.0
Software OriginatorII 2.0
Name Version PreStamp 3.2
-------------------- StuffIt Classic 1.6
Copernicus 1.00 SunDial 3.2
CounterPoint 1.09 TExport 1.92
MacWoof 1.1 TimeStamp 1.6
TImport 1.92
Tset 1.3
TSort 1.0
UNZIP 1.02c
Zenith 1.5
Zip Extract 0.10
Amiga
-----
BBS Software Network Mailers Other Software
Name Version Name Version Name Version
-------------------- -------------------- --------------------
4D-BBS 1.65 BinkleyTerm 1.00 Areafix 1.48
DLG Pro. 0.96b TrapDoor 1.80 AReceipt 1.5
Falcon CBCS 1.00 WelMat 0.44 ChameleonEdit 0.11
Starnet 1.0q@ ConfMail 1.12
TransAmiga 1.07 ElectricHerald 1.66
XenoLink 1.0 Compression FFRS 1.0@
Utilities FileMgr 2.08
Name Version Fozzle 1.0@
NodeList Utilities -------------------- Login 0.18
Name Version AmigArc 0.23 MessageFilter 1.52
-------------------- booz 1.01 Message View 1.12
ParseLst 1.66 LHARC 1.30 oMMM 1.50
Skyparse 2.30 LhA 1.10 PolyXAmy 2.02
TrapList 1.40 LZ 1.92 RMB 1.30
PkAX 1.00 Roof 46.15
UnZip 4.1 RoboWriter 1.02
Zippy (Unzip) 1.25 Rsh 4.07a
Zoo 2.01 Tick 0.75
TrapToss 1.20
|Contact: Maximilian Hantsch 2:310/6| Yuck! 2.02
Atari ST/TT
-----------
BBS Software Network Mailers Other Utilities
Name Version Name Version Name Version
-------------------- -------------------- --------------------
FIDOdoor/ST 2.5.1 BinkleyTerm 2.40n9 ApplyList 1.00@
FiFo 2.1v The Box 1.95* Burep 1.1
LED ST 1.00 ComScan 1.04
MSGED 1.99 ConfMail 4.10
QuickBBS/ST 1.06* NodeList Utilities Echoscan 1.10
Name Version FDrenum 2.5.2
-------------------- FastPack 1.20
Compression ParseList 1.30 Import 1.14
FIDONEWS 13-36 Page 52 2 Sep 1996
Utilities EchoFix 1.20 oMMM 1.40
Name Version sTICK/Hatch 5.50 Pack 1.00
-------------------- Trenum 0.10
ARC 6.02
LHARC 2.01i
PackConvert
STZip 1.1*
UnJARST 2.00
WhatArc 2.02
Archimedes
----------
BBS Software Network Mailers Other Utilities
Name Version Name Version Name Version
-------------------- -------------------- --------------------
ARCbbs 1.61 BinkleyTerm ARC 1.20
Odyssey 0.37 2.06f-wimp !AskFor 1.01
RiscBBS 0.9.85m BatchPacker 1.00
DeLZ 0.01
MailED 0.95
NetFile 1.00
ParseLst 1.30
Raul 1.01
!Spark 2.16
!SparkMail 2.08
!SparkPlug 2.14
UnArj 2.21
UnZip 3.00
Zip 1.00
Tandy Color Computer 3 (OS-9 Level II)
--------------------------------------
BBS Software Compression Utility Other Utilities
Name Version Name Version Name Version
-------------------- -------------------- --------------------
RiBBS 2.02+ Ar 1.3 Ascan 1.2
DeArc 5.12 AutoFRL 2.0
OS9Arc 1.0 Bundle 2.2
UnZip 3.10 CKARC 1.1
UnLZH 3.0 EchoCheck 1.01
FReq 2.5a
LookNode 2.00
ParseLST
PReq 2.2
RList 1.03
RTick 2.00
UnBundle 1.4
UnSeen 1.1
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Key to old info:
+ - Netmail Capable (Doesn't Require Additional Mailer Software)
FIDONEWS 13-36 Page 53 2 Sep 1996
* - Recently Updated Version
@ - New Addition
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Please send updates and suggestions to: Peter Popovich, 1:363/264
-----------------------------------------------------------------
FIDONEWS 13-36 Page 54 2 Sep 1996
=================================================================
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!
-----END PGP PUBLIC KEY BLOCK-----
Pending a formal decision about including 'encrypted' material inside
FidoNews from the Zone Coordinator Council, the guts of the FidoNews
public-key have been removed from this listing.
File-request FNEWSKEY from 1:1/23 [1:374/14] or download it from the
Rights On! BBS at 1-407-383-1372 anytime except 0100-0130 ET and Zone
1 ZMH at 1200-9600+ HST/V32B.
This section will contain only this disclaimer and instructions until
a ZCC decision is forwarded to the Editor.
Sorry for any inconvenience.
-----------------------------------------------------------------
FIDONEWS 13-36 Page 55 2 Sep 1996
=================================================================
FIDONEWS INFORMATION
=================================================================
------- FIDONEWS MASTHEAD AND CONTACT INFORMATION ----------------
Editor: Christopher Baker
Editors Emeritii: Thom Henderson, Dale Lovell,
Vince Perriello, Tim Pozar,
Tom Jennings, Sylvia Maxwell,
Donald Tees
"FidoNews Editor"
FidoNet 1:1/23
BBS 1-407-383-1372, 300/1200/2400/14400/V.32bis/HST(ds)
more addresses:
Christopher Baker -- 1:374/14, cbaker84@digital.net
cbak.rights@opus.global.org
(Postal Service mailing address)
FidoNews Editor
P.O. Box 5921
Titusville, FL 32783-5921
U.S.A.
voice: 1-407-264-2994 [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 1996 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 [FNEWSDnn.LZH] for a
FIDONEWS 13-36 Page 56 2 Sep 1996
particular Issue. Monthly Volumes are available as FNWSmmmy.ZIP
where mmm = three letter month [JAN - DEC] and y = last digit of the
current year [6], i.e., FNWSMAY6.ZIP for all the Issues from May 96.
Annual volumes are available as FNEWSn.ZIP where n = the Volume number
1 - 12 for 1984 - 1995, respectively. Annual Volume archives range in
size from 48K to 1.2M.
INTERNET USERS: FidoNews is available via:
http://www.fidonet.org/fidonews.htm
ftp://ftp.fidonet.org/pub/fidonet/fidonews/
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.sstar.com
in the FIDONET\FNEWS directory:
FNEWSTOC.ZIP FidoNews, Table of Contents, all issues (1984 - 1995)
FNEWS1.ZIP FidoNews, Vol. 1, all issues (1984)
FNEWS2.ZIP FidoNews, Vol. 2, all issues (1985)
FNEWS3.ZIP FidoNews, Vol. 3, all issues (1986)
FNEWS4.ZIP FidoNews, Vol. 4, all issues (1987)
FNEWS5.ZIP FidoNews, Vol. 5, all issues (1988)
FNEWS6.ZIP FidoNews, Vol. 6, all issues (1989)
FNEWS7.ZIP FidoNews, Vol. 7, all issues (1990)
FNEWS8.ZIP FidoNews, Vol. 8, all issues (1991)
FNEWS9.ZIP FidoNews, Vol. 9, all issues (1992)
FNEWSA.ZIP FidoNews, Vol. 10, all issues (1993)
FNEWSB.ZIP FidoNews, Vol. 11, all issues (1994)
FNEWSC.ZIP FidoNews, Vol. 12, all issues (1995)
FNEWSD01.ZIP FidoNews, Vol. 13, Nr. 01 (January 1, 1996)
FNEWSD02.ZIP FidoNews, Vol. 13, Nr. 02 (January 8, 1996)
(etc)
FNEWSD34.ZIP FidoNews, Vol. 13, Nr. 34 (August 19, 1996)
FNEWSD35.ZIP FidoNews, Vol. 13, Nr. 35 (August 26, 1996)
(etc)
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
FIDONEWS 13-36 Page 57 2 Sep 1996
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
1:1/23 [1:374/14] by file-request for FNEWSKEY or by download from
Rights On! BBS at 1-407-383-1372 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.
*=*=*=*=*
Anyone interested in getting a copy of the INTERNET GATEWAY FAQ may
file-request GISFAQ.ZIP from 1:133/411.0, or send an internet message
to fidofaq@gisatl.fidonet.org. No message or text or subject is
necessary. The address is a keyword that will trigger the automated
response. People wishing to send inquiries directly to David Deitch
should now mail to fidonet@gisatl.fidonet.org rather than the
previously listed address.
*=*=*=*=*
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 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, 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