1015 lines
45 KiB
Plaintext
1015 lines
45 KiB
Plaintext
F I D O N E W S -- Vol.11 No.37 (12-Sep-1994)
|
||
-----------------------------+-----------------------------------------
|
||
A newsletter of the | ISSN 1198-4589 Published by:
|
||
FidoNet BBS community | "FidoNews" BBS
|
||
_ | +1-519-570-4176
|
||
/ \ |
|
||
/|oo \ | Small animal psychology and
|
||
(_| /_) | Spiritual guidance Department:
|
||
_`@/_ \ _ | Rev. Richard Visage 1:163/409
|
||
| | \ \\ |
|
||
| (*) | \ )) | Editors:
|
||
|__U__| / \// | Donald Tees 1:221/192
|
||
_//|| _\ / | Sylvia Maxwell 1:221/194
|
||
(_/(_|(____/ | Tim
|
||
(jm) | Newspapers should have no friends.
|
||
| -- JOSEPH PULITZER
|
||
-----------------------------+------------------------------------------
|
||
Submission address: editors 1:1/23
|
||
------------------------------------------------------------------------
|
||
MORE addresses: submissions=> editor@exlibris.tdkcs.waterloo.on.ca
|
||
Don -- don@exlibris.tdkcs.waterloo.on.ca
|
||
Sylvia -- max@exlibris.tdkcs.waterloo.on.ca
|
||
Tim Pozar -- pozar@kumr.lns.com
|
||
David Deitch -- 1:133/411.411, deitch@gisatl.fidonet.org
|
||
------------------------------------------------------------------------
|
||
For info about copyrights, article submissions, obtaining copies of
|
||
snooze or the internet gateway faq please refer to the end of this file.
|
||
========================================================================
|
||
Table of Contents
|
||
========================================================================
|
||
|
||
1. Editorial: why is this in my mailbox?......................... 2
|
||
2. Articles...................................................... 2
|
||
Backbone Echo Changes [Jul-Aug]............................. 2
|
||
Software Museum............................................. 3
|
||
Has the Structure of Fidonet Had Its Day?................... 4
|
||
Dear Reverend Visage,....................................... 6
|
||
Remote Access - False Security Promotion.................... 8
|
||
Gating from FidoNet, banned................................. 11
|
||
Election Announcement - Zone One Echomail Coordinator....... 12
|
||
Dear MADam emilia........................................... 14
|
||
FidoNet Excommunication - An interpretation................. 14
|
||
3. Fidonews Information.......................................... 18
|
||
FidoNews 11-37 Page: 2 12 Sep 1994
|
||
========================================================================
|
||
Editorial
|
||
========================================================================
|
||
|
||
A truly amazing bit of mail arrived this week. As i read the
|
||
first bit of it, which was erotic creative writing, i thought it
|
||
was an echo ad for the GAY_TEEN echo, and i thought, "oh well, here
|
||
we go again, this will provoke some controversy but it is interesting
|
||
and not at all offensive".
|
||
|
||
Then, i reached the bottom line. Someone had quoted pages of
|
||
a message from some echo, then tacked a few phrases on the end
|
||
complaining that they had had to read the echo message when they turned
|
||
on their computer and suggesting policy fru-fra. If someone doesn't
|
||
want to read something, why would they assume no-one else wants to read
|
||
it, then quote what they assume no-one wants to read and re-send it so
|
||
more people can read it? What happened to self-censorship and pressing
|
||
return keys?
|
||
|
||
Mind boggling.
|
||
|
||
On a less befuddled note, a FidoCon is going to happen "in"
|
||
South Western Obtario during the second week of August next year.
|
||
Please check upcoming snooze issues for more info.
|
||
|
||
I'm passing this file to Don's computer now to see if i can
|
||
induce him to explain geonets <Evil GrIN>...
|
||
|
||
... Max, geonets are inexplicable ...
|
||
|
||
========================================================================
|
||
Articles
|
||
========================================================================
|
||
|
||
Backbone Echo Changes [Jul-Aug]
|
||
by Lisa Gronke, 1:105/6
|
||
lisa@m2xenix.psg.com
|
||
|
||
Summary of backbone & quasi-backbone echo changes during Jul & Aug.
|
||
|
||
Brought to you courtesy of (unix) diff.
|
||
|
||
diff (fidonet.na + fidonet.no) 03-Jul-94 (ditto) 04-Sep-94 [edited].
|
||
|
||
Added to the backbone
|
||
---------------------
|
||
> AIDS.DATA READ ONLY News Group Relating to AIDS/HIV
|
||
> APOGEE Apogee Support Conference
|
||
> CDOOR RBBS/CDOR Support, Development & Users
|
||
> CROSS_STITCH Cross Stitchers Conference
|
||
> DOOM Official DOOM Support Echo
|
||
> INK Desktop Publishing & Word Processing
|
||
> MICROCOM Microcom Modem Support Echo
|
||
> MUSE Muse Studio (Poetry Discussion)
|
||
FidoNews 11-37 Page: 3 12 Sep 1994
|
||
|
||
> OLDTRUCK Old Trucks and Related Topics
|
||
> REENACT Reenacting & Living History Echo
|
||
> STOP_SMOKING Stop Smoking
|
||
> TRIBBS_SUPPORT TriBBS Support - The Official Conference
|
||
|
||
Echotag changes
|
||
---------------
|
||
< HST US Robotics high speed modem disc. [old name]
|
||
> USR_MODEMS US Robotics high speed modem disc. [new name]
|
||
|
||
Removed from the backbone or quasi-backbone
|
||
-------------------------------------------
|
||
< CRASH (not in EchoList since 3/1/94)
|
||
< DBTECH (not in EchoList since 9/1/93)
|
||
< QNX QNX Software Systems LTD QNX OS
|
||
< SCIFOR VortexNet/c-128 Support conference
|
||
< USS_LIBERTY USS Liberty (AGTR-5) Incident of June 8, 1967
|
||
|
||
o There are 625 echos in fidonet.na [04-Sep-94] (up 3)
|
||
o There are 43 echos in fidonet.no [04-Sep-94] (up 6)
|
||
o for a total of 668 backbone & quasi-backbone echos (up 9)
|
||
|
||
o two echos, BIBLE & HOBBIES, are available from the Zone STARS but
|
||
not in the FidoNet bundles from Planet Connect.
|
||
----------------------------------------------------------------------
|
||
|
||
SOFTWARE MUSEUM
|
||
|
||
Dear all,
|
||
|
||
I have visited the Science Museum in London and in Manchester. Both
|
||
have an exhibition about computers. I find them boring, I mean there
|
||
is nothing exciting on an old black box or a dusty PCB. I think the
|
||
'soul' of the electronical computer is the software. Hey, here comes
|
||
my idea:
|
||
|
||
A SOFTWARE MUSEUM SHOULD BE ESTABLISHED
|
||
RATHER THAN A HARDWARE EXHIBITION.
|
||
|
||
Here you are my initial ideas:
|
||
|
||
* The museum should consist of ancient softwares (such as FORTRAN
|
||
compilers :-) and operating systems. These stuffs should be
|
||
emulated, allow the 'visitors' to pick up some experience about how
|
||
hard the life was before the invention of the high-level languages,
|
||
for instance.
|
||
|
||
* The exhibited items (simulators) should be public domain softwares,
|
||
written by computer enthusiasts.
|
||
|
||
* There is no need for a museum building. The whole exhibition can be
|
||
implemented 'virtually' via WWW, anonymous ftp, or on a CD ROM.
|
||
|
||
FidoNews 11-37 Page: 4 12 Sep 1994
|
||
|
||
* Furthermore, photos, animated diagrams, texts and multimedia objects
|
||
can be included, to describe the ancient hardware.
|
||
|
||
If you are interested in the software museum, have further ideas and
|
||
feel like helping to set up this 'museum', please contact me at my
|
||
private address rather than via this mailing list, as I am not a
|
||
subscriber of this newsgroup :-(
|
||
|
||
My e-mail address: stsmork@zeus.iit.uni-miskolc.hu
|
||
|
||
Regards,
|
||
Peter Mork
|
||
|
||
( 2:370/23.3 )
|
||
|
||
|
||
----------------------------------------------------------------------
|
||
|
||
HAS THE STRUCTURE OF FIDONET HAD ITS DAY?
|
||
|
||
Keith Jackson,
|
||
2:2503/105.0
|
||
kjackson@cix.compulink.co.uk
|
||
|
||
I have been accessing Fidonet as a point and node for about three
|
||
years now and it seems to me that there is increasing dissatisfaction
|
||
with the way some things are being done. In R25, as elsewhere in
|
||
Z2,we had a period of upheaval last year while geonets were enforced.
|
||
There was a lot of heat generated by this most of which, I thought,
|
||
stemmed from the realisation that nodes have no influence beyond
|
||
accepting or rejecting a line in the nodelist. Any objections were
|
||
all too frequently countered by comments along the lines of "If you
|
||
don't like it feel free to leave.". I suppose we could have been
|
||
reconciled more quickly had there been a demonstrable improvement in
|
||
connectivity as a result of the upheaval but my impression is that
|
||
there was none. R25C has recently announced further changes to
|
||
improve the aesthetics of the boundaries . . . !
|
||
|
||
This is not intended as yet another Euro-node griping at all and
|
||
sundry in the *C chain, although the way in which geonets were imposed
|
||
illustrates some of the problems I see with the situation as we have
|
||
it now. I think that the existing structure is taking powers to
|
||
itself which were not envisaged by those who wrote Policy 4 and that
|
||
it is unresponsive to pressure from the nodes. They don't need to
|
||
listen to us because they don't have to and there's currently
|
||
precious little anyone can do about it, beyond writing to The Snooze!
|
||
|
||
When a new group gets going it is usual for those involved to sort
|
||
out things between themselves and not to bother with a formal
|
||
structure until things grow. The next state, which Fido seems stuck
|
||
in, is for people to be appointed without a vote to specific tasks.
|
||
Perhaps, in earlier times when the software was less friendly, it was
|
||
necessary for the newcomer to be known to the incumbent to ensure a
|
||
seamless changeover but that system can also be open to abuse. It
|
||
puts the influence into the hands of a small number of people who end
|
||
FidoNews 11-37 Page: 5 12 Sep 1994
|
||
|
||
up having a rather incestuous relationship as each selects the other.
|
||
As a small group they become more and more remote from the nodes as
|
||
the nodelist expands. In the UK we redefine electoral boundaries to
|
||
compensate for changes in the population. Is there any reason why
|
||
the Zones are inviolate? Could splitting them down make anything any
|
||
better?
|
||
|
||
There are plenty of people who don't want to see Fido as a democratic
|
||
institution but is what we have all that satisfactory? Is it right
|
||
that people can be ignored without redress? Fido now covers the world
|
||
and there are well over 30,000 lines in the nodelist. Comms is
|
||
increasingly coming to the attention of Joe Public so the expansion
|
||
isn't over yet. Can Fido evolve to the new situation or is it a
|
||
dinosaur, doomed to extinction?
|
||
|
||
Now, there is a place for international standards - would anyone want
|
||
to see FTSC spec's abolished? - but is it realistic to believe that a
|
||
single document will fit everyone equally? Do we *need* a global
|
||
policy beyond an acceptance that communication will be via
|
||
FTSC-compliant mailers? With so many people involved, there must be
|
||
thousands upon thousands of different ideas of the right way for the
|
||
future of Fidonet. In my experience you can't get two sysops to agree
|
||
as to who's turn it is to buy the beer but here's my idea for Fido,
|
||
for what it's worth! <grin>
|
||
|
||
I object to the remoteness of many of the things happening in Fido
|
||
not necessarily because they're wrong but because I can't be
|
||
guaranteed a proper hearing. The all-embracing (it feels like
|
||
all-constricting) Policy severely restricts what I can do. Let me try
|
||
an illustrate. This is *not* from my own experience and is intended
|
||
to be extreme!
|
||
|
||
Let's say I have a complaint so I take it to my NC. I believe the
|
||
complaint is valid but it's rejected. OK, take it up with the RC. The
|
||
RC appoints the NC and, again, is both judge and jury. He rejects it
|
||
so I go to the ZC but the same applies there. Would taking it to the IC
|
||
guarantee me any more of an even-handed approach? My theoretical problem
|
||
could remain unresolved not because it was invalid but because
|
||
the old-boys network allowed it to be smothered.
|
||
|
||
What I think we have is a self-sustaining oligarchy and other people
|
||
have described it as a benign dictatorship. It's a dictatorship,
|
||
certainly, but whether it's benign or malign depends on the
|
||
post-holders. We have to *hope* that we aren't saddled with the
|
||
wrong person because it is impossible for nodes to remove them
|
||
afterwards without the agreement of the person who made the original
|
||
appointment! I think that's an inversion of what we need. I want to
|
||
see the nodes selecting their NC's without the RC being able to
|
||
reject the candidate selected by those voting. Nor do I want to see a
|
||
situation where it is possible manipulate votes by moving nodes to
|
||
different Nets which, at present, can be done on the whim of one
|
||
person.
|
||
|
||
I don't believe that any organisation can be fully democratic. If
|
||
every decision has to be put to a full vote nothing would get done.
|
||
FidoNews 11-37 Page: 6 12 Sep 1994
|
||
|
||
Nevertheless, I want the NC to be aware all the time that the the
|
||
nodes will have their say and likewise for the RC. Beyond that it
|
||
gets tricky, because of the numbers of nodes involved, but something
|
||
along similar lines could be developed and each sub-division could
|
||
devise procedures to suit their own particular circumstances.
|
||
|
||
To summarise:
|
||
|
||
1) The various *C positions certainly have part to play but I believe
|
||
that some are exceeding their authority so that the duties
|
||
associated with these posts should be more closely defined. Power,
|
||
in Fidonet terms, is control of the nodelist. Who can control the
|
||
controllers?
|
||
|
||
2) At present, the nodes have no guaranteed voice in the selection of
|
||
*C's, giving the potential for the imposition of one person's view
|
||
against the wishes of a majority. This should be changed. A step
|
||
in this direction has been made in R25 with a Regional Policy but
|
||
it does not entirely remove the ZC's ability to interfere and so is
|
||
of limited effectiveness.
|
||
|
||
3) Policies should be of a local nature with global documents limited
|
||
to ensuring technical compliance between the local organisations.
|
||
|
||
4) I'd like to see a Fidonet where rules are at a minimum and
|
||
enforced once in a blue moon. A Fidonet where the basic aim is
|
||
communication, not control by confrontation. A Fidonet where we
|
||
have *fun* first and foremost and the freedom to enjoy it!
|
||
|
||
What kind of Fidonet do you want to see in the future?
|
||
|
||
Keith Jackson
|
||
|
||
|
||
----------------------------------------------------------------------
|
||
|
||
|
||
Samp Swine Magazine,
|
||
Shuckmagosh, Ohio
|
||
P1S 0RF
|
||
|
||
|
||
Dear Reverend Visage,
|
||
|
||
Thank god we sold our shares in a well-known deep fried
|
||
chicken franchise. You may not have noticed, but Calgary is
|
||
the ostrich ranching capital of Canada. I understand that
|
||
there are some foul (note to Eds: "foul" not "fowl")
|
||
tempered birds who will do almost anything to avoid ending
|
||
up bathed in grease and 7 secret herbs and spices. I realize
|
||
that Ms. LaBamba is fond of adorning herself with the
|
||
aforementioned condiments, but you can't reason with
|
||
ostriches Visage... they have the same lack of social graces
|
||
common to Australians, fergodsake.
|
||
|
||
FidoNews 11-37 Page: 7 12 Sep 1994
|
||
|
||
|
||
In Region 12, the internecine warfare continues unabated. It
|
||
seems that Net250 have rituals that involve eating their
|
||
young, resigning from Hub positions so as to maximize mail
|
||
disruption and a fondness for AntFarmMail that would make an
|
||
anteater look like a crack-crazed junkie. At Ladbrookes, the
|
||
odds of the current NC lasting to the end of his term are
|
||
astronomical. I placed your entire garageful of used diapers
|
||
on a bet that the NC-being would stay the course. The payoff
|
||
should be enormous, possibly equaling the entire message
|
||
output of Iann Grant.
|
||
|
||
I am disappointed that you were unable to pick up the spoor
|
||
of our missing RC. Rumours that he had been John Denver's
|
||
designated driver turned out to be false and alas, poor John
|
||
was charged with defoliating Aspen with his Porsche. I
|
||
suggest you look in the vicinity of Winnepeg for the
|
||
vapourous RC. I understand that there are agricultural test
|
||
plots of rye which, if Skippy's information can be relied
|
||
upon, are infected with some of the world's finest
|
||
ergotamine. You ought to bring the flintlock in case low
|
||
flying bats plague your visit.
|
||
|
||
Don't worry about your expense account problems with the
|
||
Snooze editors. Donald & Silvia hired a fellow named
|
||
Grimspam who worked his legal and accounting magic on the
|
||
invoices. The bills for large tubs of mazola that you
|
||
submitted turned into income after Grimspam had used
|
||
something fascinating called "attractor accounting." They
|
||
had some concern over the bill for eighteen cases of
|
||
Glenlivet but were calmed down after I explained that it was
|
||
used for purely medicinal purposes as a Chinook repellent.
|
||
Incidentally, a Chinook - being characterized as a warm, wet
|
||
wind which blows for days - is surely a perfect metaphor for
|
||
any meeting involving lawyers.
|
||
|
||
My sojourn in France to assist in the revival of the
|
||
International Dwarf Tossing Society was marred by strafing
|
||
runs from Harrier jump jets. It seems that the geopolitical
|
||
ambitions of the British RC have extended to the
|
||
sub-continent. I shall send him a life-sized photo of Sinead
|
||
O'Connor to ease his poor bovine suffering.
|
||
|
||
I noticed that the usual crop of Ace Ventura, Nodelist
|
||
Detectives, have graced the 'Snooz's pages with more
|
||
suggestions as to how to pare the nodelist down to a more
|
||
diminutive stature. It amazes me that they haven't
|
||
discovered the obvious - simply remove all of the telephone
|
||
numbers - surely this would solve all of their nightmares
|
||
about a nodelist looming out of the mists to swallow
|
||
Chicago.
|
||
|
||
I must go Visage, your secretary has unleashed a horde of
|
||
atrazine-crazed beavers which have me backed against the
|
||
wall. She has a feral-toothed scowl on her face and
|
||
|
||
FidoNews 11-37 Page: 8 12 Sep 1994
|
||
|
||
bloodlust in her eyes which has almost nothing to do with
|
||
the fact I suggested that she simulate a near-death
|
||
experience by moving to Mississauga. As a good and decent
|
||
gesture, I recommend that we suit her in a glow-in-the dark
|
||
body condom and turn her loose in Net250, The Planet of
|
||
Primal Screams.
|
||
|
||
Regards,
|
||
|
||
|
||
Doc Logger,
|
||
Trout-on-Trent,
|
||
FlinFlon, Manitoba
|
||
|
||
|
||
----------------------------------------------------------------------
|
||
|
||
REMOTE ACCESS - FALSE SECURITY PROMOTION
|
||
|
||
By: Andrew Leniart
|
||
3:633/106 @fidonet
|
||
aleniart@insane.apana.org.au - Internet
|
||
|
||
Preamble:
|
||
|
||
The following article has been submitted to FidoNews due to the many
|
||
requests I've had from RA sysops since telling of it's publication in
|
||
my column "Online" in the Australian PC Review computer magazine.
|
||
Despite the many requests, it was not posted in the RA_SUPPORT
|
||
conference so as to comply with the wishes of the moderator.
|
||
|
||
Before you read the article, please keep in mind that I am an RA
|
||
system operator myself and overall, I continue to enjoy using the
|
||
software. It's never been my intention to put people 'off' from
|
||
running Remote Access. Indeed, I have promoted Remote Access heavily
|
||
on many occasions in the past and have invested considerable time and
|
||
expence in registering third party utilities to enhance it for my own
|
||
use.
|
||
|
||
Rather, the purpose of my little crusade is to bring to everyones
|
||
attention what I consider to be a "false sense of security" being
|
||
instilled in the averadge RA sysop regarding it's CRC32 password
|
||
storage method.
|
||
|
||
Since V2.0 of RA has been released, sysops have been given the
|
||
impression by many RA_SUPPORT participants that the CRC password
|
||
storage method has enhanced system security.
|
||
|
||
To my utter dismay, Sysops have even been encouraged to 'feel safe' in
|
||
using the same password on all RA systems because of the claim that
|
||
the sysop on the other end can no longer view thier password.
|
||
|
||
This article, along with an accompanying utility called CRC2PWD, has
|
||
been written to show people conclusive proof that the claims being
|
||
FidoNews 11-37 Page: 9 12 Sep 1994
|
||
|
||
made of enhanced system security are quite simply, false.
|
||
|
||
Don't fall for the trap. Always use different passwords on all systems
|
||
which you call, regardless of which software the sysop is using to run
|
||
his bbs with.
|
||
|
||
For those that may require further proof - CRC2PWD is freq'able at
|
||
3:633/106 at all times except zone mail hour. It is a utility which
|
||
will generate a set of characters that will produce an identical CRC
|
||
value to any users account in an RA2.0 users.bbs file. It requires a
|
||
386 or better processor to run.
|
||
|
||
The Article:
|
||
|
||
Warning to Prospective RA SysOps
|
||
|
||
I've been a RemoteAccess (RA from here on) die hard for many years
|
||
now, and despite many people trying to sway me to run other BBS
|
||
packages, I've stuck it out with RA and promoted it heavily for two
|
||
reasons.
|
||
|
||
One is that it's always been a highly configurable package which is
|
||
relatively easy to configure and use, even for beginners.
|
||
|
||
Secondly because it's developed by an Australian author, Andrew Milner
|
||
and I generally try and buy Australian when I see good value for
|
||
money.
|
||
|
||
Having said that though, it should go without saying that if I DID
|
||
choose to change from RA to another BBS package, I should be able to
|
||
do so with relative ease. This option has always been there with RA
|
||
until version 2.0 came out some months ago. With the release of V2.0
|
||
of RA, users passwords are no longer stored in RA in the conventional
|
||
sense.
|
||
|
||
Rather, what the software now does is change the users password to a
|
||
CRC32 and stores the CRC value in the user base instead. This
|
||
effectively makes the actual password non existant on the system and
|
||
it can no longer be viewed either by the SysOp or the account holder.
|
||
|
||
According to RA beta testers and support people, this password storage
|
||
method was introduced to enhance system security in the event of a
|
||
hacker managing to steal a BBS' user file. In my opinion though,
|
||
system security has been anything BUT enhanced with this method. Why?
|
||
|
||
The short of it is that CRC32 values are not secure. They are easily
|
||
cracked, so telling people that RA has greater security because it
|
||
stores it's passwords as CRC32 values is to simply instill a false
|
||
sense of security.
|
||
|
||
What's more, with previous versions of RA, only your actual password
|
||
would get you access to your account.
|
||
|
||
With the CRC32 password storage method, this is not necessarily the
|
||
case. To illustrate, a 7 character password can produce an identical
|
||
FidoNews 11-37 Page: 10 12 Sep 1994
|
||
|
||
CRC value to a say, alphanumeric 3 character password.
|
||
|
||
So in other words, if you happen to be unlucky enough to choose a
|
||
password which has a CRC value that can be duplicated by a different
|
||
password, then a hacker's chances of fluking access to your account by
|
||
simply guessing the password you use has just doubled.
|
||
|
||
This is an increase in system security? I don't think so and neither
|
||
do many other fellow RA sysops.
|
||
|
||
SWAPPING OVER
|
||
|
||
How does this prevent us from easily swapping over to another BBS
|
||
package? Well, it doesn't if you haven't been running a BBS for any
|
||
great length of time, but consider if you were running one for a few
|
||
months and had developed a user base with five or six hundred callers
|
||
on your system. If you charge money for access to your system, simply
|
||
wiping the user base and starting from scratch is certainly not
|
||
practicable..
|
||
|
||
It's relatively easy for most programmers to whip up a conversion
|
||
utility that transfers details from one BBS user file format over to
|
||
another. It's done all the time, and quite a lot of BBS software
|
||
packages come with such utilities bundled in with the main software.
|
||
|
||
Yet with RA, it's no longer possible, because the most critical part
|
||
of the user file, the password, no longer exists - only a CRC value.
|
||
It's impossible to retrieve the actual characters which originally
|
||
produced the CRC value, so all of a sudden you're stuck with RA unless
|
||
you want to go to all the trouble of voice calling each and every one
|
||
of your callers and manually enter thier password into the new BBS
|
||
software.
|
||
|
||
So what's the solution? I've asked Andrew Milner via direct netmail
|
||
for his comment on this issue but haven't yet recieved a reply. RA
|
||
beta testers have responded to questions though, confirming that Mr
|
||
Milner has stated that the encrypted password storage method in RA is
|
||
here to stay, whether we like it or not. My question is WHY?
|
||
|
||
Suggestions of making it an optional feature have been waved off and
|
||
discussion of the issue in the FidoNet RA_SUPPORT conference has been
|
||
declared off topic by the moderator. I've actually been threatened
|
||
with having my access to the support conference severed by Bruce
|
||
Bodger if I continued to discuss the issue in there. Great stuff huh?
|
||
|
||
So what's it all about then? System security or ensuring that RA
|
||
SysOps don't desert, unless they want to go through a heck of a lot of
|
||
heartache in changing over to another system? Make up your own mind.
|
||
|
||
In closing, I would like to say to all prospective sysops - think long
|
||
and hard before selecting RA as your BBS package.
|
||
|
||
RA is still in all other respects an excellent BBS package, but be
|
||
aware that you may end up stuck with it for a very long time. Be also
|
||
aware of the aparant reluctance of both Mr Milner and his Beta Support
|
||
FidoNews 11-37 Page: 11 12 Sep 1994
|
||
|
||
Team to take the loyal software users' wishes into account.
|
||
|
||
ONE SOLUTION
|
||
|
||
Some good news though.. At least one BBS software package has seen the
|
||
plight of RA system operators and has addressed the problem for us.
|
||
|
||
Philippe Leybaert, Belgian author of the shareware BBS package
|
||
Proboard v2.01, has redesigned his BBS to use the same user file RA2.0
|
||
does, with the exception that it also stores the users passwords in
|
||
the conventional form, so converting over from RA2.0 to ProBoard is
|
||
quite painless.
|
||
|
||
ProBoard gives you a choice of having hidden passwords or not, and if
|
||
you selelct that you don't want want hidden passwords, it stores them
|
||
in in the conventional form for you as your users log on and enter
|
||
thier password.
|
||
|
||
Let's hope that other shareware authors will see that this is the way
|
||
to go and incorporate a similar feature in thier BBS packages in
|
||
furture versions, I'm not holding my breath, though.
|
||
|
||
Till the next time...
|
||
|
||
|
||
----------------------------------------------------------------------
|
||
|
||
GATING FROM FIDONET, BANNED
|
||
|
||
Recently it has been brought to the attention of readers in TrekNet
|
||
(you guessed 'er, a Star Trek and Sci-Fi OtherNet) that some of the
|
||
TREK and related areas that are gated between FidoNet and TrekNet are
|
||
not going to be permitted to be gated any more.
|
||
|
||
At this time, those nets who are running CRP's (Cost Recovery
|
||
Programs) are probably jumping out of your seats and dancing around
|
||
their computer desk chanting "Yes, we finally got rid ofthe
|
||
moochers". No, I'm not here to defend those of us who pull those
|
||
echos through the OtherNets which the echos are being gated, but
|
||
rather to ask a simple question.
|
||
|
||
Now, the poop that we're being told (and I use the word 'poop' very
|
||
liberally) is that the order came from the "Higher Ups", which would
|
||
indicate ZC's and RC's, and the like. I've got just one thing to ask:
|
||
|
||
Isn't the moderator of the echo permitted to gate his or her echo
|
||
into any Network that he or she wishes?
|
||
|
||
Ultimately, it is the moderator who says "No, I don't want you using
|
||
my echo", and by all rights and priviledges the moderator does own
|
||
the echo, yes? So, what gives these people in the offices of ZC, RC
|
||
and NC the right to say "No, you can't gate these echos anymore, you
|
||
have to get them through a FidoNet Net in your area."
|
||
|
||
I'm just a little tired of the buracracy of FidoNet. I've watched
|
||
FidoNews 11-37 Page: 12 12 Sep 1994
|
||
|
||
good and honourable people turn into domineering bafoons after
|
||
they've been elected into the office of NC, or even a HUB.
|
||
|
||
If FidoNet keeps this up, I think that they may find fewer nodes
|
||
wishing to tolerate the crap and possibily a bit of Negative Growth.
|
||
|
||
----------------------------------------------------------------------
|
||
|
||
Election Announcement - Zone One Echomail Coordinator
|
||
|
||
by Adrian Walker
|
||
1:153/752
|
||
Interim Z1EC
|
||
ELECTION ANNOUNCEMENT
|
||
|
||
Position:
|
||
---------
|
||
|
||
Zone 1 Echomail Coordinator (1:1/200).
|
||
|
||
Customary Duties:
|
||
|
||
* Coordination of echomail distribution at the zone level.
|
||
* Recognition of echoes at the zone level.
|
||
* Maintenance of a list of recognized echoes and their
|
||
requirements as supplied by the Moderator.
|
||
* Making recognized echoes available to Zone 1 regions.
|
||
* Appointment of Zone Hubs to distribute echomail at the zone
|
||
level.
|
||
* Appointment of a Zone Echolist Coordinator.
|
||
|
||
Term of office is two years from date elected.
|
||
|
||
Election Schedule 1994:
|
||
-----------------------
|
||
|
||
Nominations are open from 19 September 00:01 PDT (07:01 UTC).
|
||
to 25 September 23:59 PDT (06:59 UTC).
|
||
|
||
Discussion follows from 26 September 00:01 PDT (07:01 UTC).
|
||
to 7 October 23:59 PDT (06:59 UTC).
|
||
|
||
Voting period will be from 10 October 00:01 PDT (07:01 UTC).
|
||
to 14 October 23:59 PDT (06:59 UTC).
|
||
|
||
Results announced by 17 October 23:59 PDT (06:59 UTC).
|
||
|
||
Eligibility:
|
||
------------
|
||
|
||
Any Zone 1 SysOp listed in the 16 September 1994 Nodelist
|
||
(NODELIST.259) is eligible to be nominated.
|
||
|
||
Nominations:
|
||
------------
|
||
FidoNews 11-37 Page: 13 12 Sep 1994
|
||
|
||
|
||
Nominations are to be sent by netmail to Adrian Walker at 1:153/752.
|
||
|
||
A nomination is only valid after a message from the nominee accepting
|
||
the nomination is included or posted.
|
||
|
||
Voting:
|
||
-------
|
||
|
||
Each Zone 1 Region Echomail Coordinator listed in the 16 September
|
||
1994 Nodelist (NODELIST.259) may cast one vote.
|
||
|
||
Each REC will consult his region to determine how to cast his vote.
|
||
|
||
Votes are to be sent by netmail to Dave James at 1:209/209, and to
|
||
ensure security of the vote, are to include a password selected by the
|
||
voting REC.
|
||
|
||
All votes will be tallied and the results forwarded by Dave James at
|
||
1:209/209 to the Zone Coordinator (Z1C) at the end of the voting
|
||
period.
|
||
|
||
The nominee having a simple majority (more than 50%) of the votes cast
|
||
will be declared the new Z1EC.
|
||
|
||
If no one candidate receives more than 50% of votes cast, the RECs
|
||
shall be presented with a ballot containing the names of the two
|
||
nominees having the most votes, and shall conduct a runoff election.
|
||
The nominee with the most votes in the runoff election will be
|
||
declared the new Z1EC.
|
||
|
||
Announcements:
|
||
--------------
|
||
|
||
The election announcement will be posted in FidoNews and the
|
||
Z1_ELECTION echo by 19 September 1994 by the Interim ZEC.
|
||
|
||
The nominees will be posted in Z1_ELECTION echo on 26 September 1994
|
||
and in FidoNews as quickly thereafter as possible by the Interim ZEC.
|
||
|
||
Results will be posted in FidoNews and Z1_ELECTION echo on 17 October
|
||
1994 by the Interim ZEC.
|
||
|
||
RECs are encouraged to cross post all such announcements into their
|
||
respective regional echos.
|
||
|
||
---ooo000ooo---
|
||
|
||
FidoNews 11-37 Page: 14 12 Sep 1994
|
||
|
||
|
||
Dear MADam emilia
|
||
|
||
A: There's been much gripeing lately over Fidonet "positions" being
|
||
passed on to friends rather than won in elections.
|
||
|
||
Q: What is the mechanism of power-mongering? How can popularity
|
||
contests result in the selection of the best person to laboriously
|
||
fulfill a purely technical position?
|
||
|
||
A: There seems to be the potential for egotistical zealotry and
|
||
corruption in both democratic and feudal models of management.
|
||
Maybe an optomistic laissez-faire eeks out the best of all
|
||
models, even though it's messy sometimes.
|
||
|
||
Q: Should the Fidonews editorship-hood-ness be an elected position,
|
||
for example? <cringe, fear, hey i like this job, woooo>
|
||
|
||
q: Why did the last page description of Fidonet as an "amateur"
|
||
network change to "volunteer" network and then back again?
|
||
|
||
a: Well, it started bugging me that the word "amateur" connotes
|
||
unsophisticated or unknowledgeable, and Fidonet chuggs along
|
||
amazingly seamlessly compared to some professionally done and
|
||
inflatedly expensive communications systems. But then i read the
|
||
dictionary, and one possible denotation of "volunteer" is "a person
|
||
who voluntarily undertakes a task or enters military or other
|
||
service". I'm not big on the military except when they're rescuing
|
||
people drowning at sea or building shelters and providing aid in
|
||
distasterous situations, so i changed it back to "amateur".
|
||
|
||
q: How do you feel about Steve Winter being kicked out of Fidonet?
|
||
|
||
a: Lousy. It contradicts the tolerant spirit of Fidonet in a bad
|
||
way. Excommunication smacks of religionism, like permanent
|
||
damnation. It's easy for me to talk this way, because i am
|
||
not a hub.
|
||
|
||
----------------------------------------------------------------------
|
||
|
||
Submitted by: Al Hays
|
||
1:363/89
|
||
al.hays@oau.org
|
||
|
||
FIDONET EXCOMMUNICATION - AN INTERPRETATION
|
||
|
||
A Debate is currently underway in HOST18 (which is READ-ONLY to R18
|
||
SysOps) between Region 18's Network *C and *ECs, and the RC & REC.
|
||
It is a civil, even-handed debate to all of the coordinator's credit.
|
||
|
||
POLICY debates: always such fun, and yet regardless of the outcome,
|
||
RC18 Larry Squire states that his "hands are tied" due to the current
|
||
consensus of the Zone 1 RC Council. Perhaps the council, or even Z1C,
|
||
has not considered the obvious. Sometimes it takes an outside
|
||
opinion to stimulate the thought process or to bring a previously
|
||
FidoNews 11-37 Page: 15 12 Sep 1994
|
||
|
||
unheard perspective to light which may change opinion. Am I right?
|
||
Who knows ... but I respectfully submit this as one man's opinion,
|
||
nonetheless.
|
||
|
||
...
|
||
|
||
What is excommunication?
|
||
|
||
Excommunication, as defined by POLICY4, has a dual meaning. First,
|
||
simply being dropped from the Nodelist for down time, non-compliance,
|
||
etc. is defined in section 2.1.12 as having been "excommunicated." As
|
||
such, section 2.1.12 also prescribes relief from inadvertent
|
||
excommunication by advising the node to "rectify the problem and
|
||
contact your coordinator."
|
||
|
||
Excommunication "for cause" is also defined in section 2.1.12. It
|
||
also refers to sections 4.3 and 5.2 both of which, paraphrased, state
|
||
that a coordinator may "excommunicate" a node for excessively annoying
|
||
behavior (XAB).
|
||
|
||
The pertinent sections of POLICY4 appear below:
|
||
|
||
> 2.1.12 Excommunication
|
||
>
|
||
> A system which has been dropped from the network is said to be
|
||
> excommunicated (i.e. denied communication). If you find that you
|
||
> have been excommunicated without warning, your coordinator was
|
||
> unable to contact you. You should rectify the problem and contact
|
||
> your coordinator.
|
||
>
|
||
> Systems may also be dropped from the nodelist for cause. See
|
||
> section 9, and sections 4.3 and 5.2.
|
||
>
|
||
> It is considered annoying behavior to assist a system which was
|
||
> excommunicated in circumventing that removal from the nodelist.
|
||
> For example, if you decide to provide an echomail feed to your
|
||
> friend who has been excommunicated, it is likely that your listing
|
||
> will also be removed.
|
||
>
|
||
>
|
||
> 4.3 Assigning Node Numbers
|
||
>
|
||
> ... unrelated text removed ..
|
||
>
|
||
> If a node in your network is acting in a sufficiently annoying
|
||
> manner, then you can take whatever action you deem fit, according
|
||
> to the circumstances of the case.
|
||
>
|
||
>
|
||
> 5.2 Assigning Node Numbers
|
||
>
|
||
> ... unrelated text removed ...
|
||
>
|
||
> If a node in your region is acting in a sufficiently annoying
|
||
> manner, then you can take whatever action you deem fit, according
|
||
FidoNews 11-37 Page: 16 12 Sep 1994
|
||
|
||
> to the circumstances of the case.
|
||
|
||
Let's examine, for a moment, the PURPOSE that POLICY4 conveys behind
|
||
excommunication due to XAB. The excommunicated node in question was
|
||
removed "for cause" meaning that he/she was intentionally a) causing
|
||
a disruption in FidoNet Operations, b) ignoring POLICY, and/or c)
|
||
repeatedly harassing or otherwise interfering with another node.
|
||
He/she was, therefore, excommunicated, or as POLICY defines it,
|
||
"denied communication." The purpose of this denial of communication
|
||
is not for retribution, but to take specific action to end the
|
||
activities which brought about the excommunication in the first
|
||
place. The PURPOSE of excommunication is to "deny communication."
|
||
|
||
|
||
What constitutes "denied communication?"
|
||
|
||
In this author's opinion excommunication, or "denied communication,"
|
||
indicates that the individual in question has purposely and defiantly
|
||
acted in a sufficient manner that the Network, through it's
|
||
coordinators, wishes to have no further communication with the
|
||
individual in *ANY* manner, be it as Node, Point, or User. Simply
|
||
removing an individual from the Nodelist does not "deny communication."
|
||
The denial must be complete or excommunication is a fruitless exercise
|
||
in futility.
|
||
|
||
|
||
Node, Point, or User ...
|
||
|
||
Providing a "feed" to an excommunicated FidoNet SysOp is clearly
|
||
defined by POLICY4 as XAB in section 2.1.12. The term "feed" is
|
||
ambiguous and, since it is covered in the very same section which
|
||
defines excommunication as "denied communication" can be easily
|
||
interpreted to mean "access" to any/all FidoNet areas. This would
|
||
cover Points and Users alike. Policy defines a point "in the same
|
||
manner as a user" and the converse may, therefore, be extricated. To
|
||
wit:
|
||
|
||
> 1.2.1.2 Points
|
||
>
|
||
> A point is a FidoNet-compatible system that is not in the nodelist,
|
||
> but communicates with FidoNet through a node referred to as a
|
||
> bossnode. A point is generally regarded in the same manner as a
|
||
> user ...
|
||
|
||
According to POLICY4, a point "communicates with FidoNet through a
|
||
node" and since POLICY4 defines excommunication as "denied
|
||
communication" then applied logic would dictate that acting as a
|
||
bossnode for an excommunicated node would constitute XAB (section
|
||
2.1.12, 1.2.1.2, 4.3 and 5.2). Conversely, therefore, an
|
||
excommunicated node may not access FidoNet communications as a point.
|
||
|
||
Again, from section 2.1.12:
|
||
|
||
> It is considered annoying behavior to assist a system which was
|
||
> excommunicated in circumventing that removal from the nodelist.
|
||
FidoNews 11-37 Page: 17 12 Sep 1994
|
||
|
||
> For example, if you decide to provide an echomail feed to your
|
||
> friend who has been excommunicated, it is likely that your listing
|
||
> will also be removed.
|
||
|
||
.
|
||
Providing a "feed" is but one "example" provided for by section
|
||
2.1.12 as annoying behavior. It is not the *ONLY* method of
|
||
accessing FidoNet and it is the act of "assist(ing) a system which
|
||
was excommunicated in circumventing that removal" which is defined
|
||
as XAB. POLICY4 also defines Points and Users "in the same manner."
|
||
Again, the very same applied logic would dictate that a SysOp who
|
||
provides an excommunicated node as a User access to FidoNet
|
||
Communications is engaging in XAB (sections 2.1.12, 1.2.1.2, 4.3 and
|
||
5.2) and once again, conversely, it may be said that an
|
||
excommunicated node may not access FidoNet as a user.
|
||
|
||
Can FidoNet, or it's coordinators, dictate a who a SysOp may, or may
|
||
not, extend access to on their personal BBS? Of course not. But
|
||
FidoNet certainly may, dictate who may, or may not, have access to
|
||
*it's* Communication's areas. A SysOp may certainly allow *any user*
|
||
access to his/her BBS without question or interference from FidoNet
|
||
or it's coordinators but, once notified, that same SysOp must take
|
||
great care to insure that an excommunicated node *is* *not* granted
|
||
access to any FidoNet communications areas. A BBS' File Areas,
|
||
OtherNet Areas, and Local bases are beyond the scope of FidoNet,
|
||
but FidoNet has every right to restrict access to communications
|
||
areas specific *to* FidoNet. If FidoNet, through it's coordinators,
|
||
has deemed a node to be such a problem that it has been removed "for
|
||
cause" by excommunication, then it would be reasonable to assume that
|
||
this individual has been "denied communication" from all areas of
|
||
FidoNet communications and via all avenues. Therefore, SysOps
|
||
providing an excommunicated node access to FidoNet areas as a user
|
||
are engaging in XAB (sections 1.2.1.2, 2.1.12, 4.2 and 5.2).
|
||
|
||
Debate rages on over whether a Point or User may be denied access to
|
||
FidoNet communications because of the definition of "feed." What
|
||
possible purpose could be served by simply removing a node listing?
|
||
POLICY4 clearly defines it a much more: specifically "denied
|
||
communication." It is on this POLICY4 definition that coordinators
|
||
should focus their attention, not whether the "communication" or
|
||
"feed" is fully automated, partially automated, dictated, or even
|
||
transcribed. If excommunication is the defined solution by the
|
||
coordinator structure, then the "denial of communication" as
|
||
defined by POLICY4 most be thorough, complete, and followed, as
|
||
*intended* by POLICY4: DENY COMMUNICATION.
|
||
|
||
Respectfully Submitted,
|
||
|
||
Al Hays
|
||
SysOp, 1:363/89
|
||
al.hays@oau.org
|
||
|
||
FidoNews 11-37 Page: 18 12 Sep 1994
|
||
|
||
|
||
========================================================================
|
||
Fidonews Information
|
||
========================================================================
|
||
|
||
Editors: Sylvia Maxwell, Donald Tees
|
||
Editors Emeritii: Thom Henderson, Dale Lovell,
|
||
Vince Perriello, Tim Pozar
|
||
Tom Jennings
|
||
"FidoNews" BBS
|
||
FidoNet 1:1/23
|
||
BBS +1-519-570-4176, 300/1200/2400/14400/V.32bis/HST(DS)
|
||
|
||
more addresses:
|
||
Rev. Richard Visage -- 1:163/409
|
||
Don -- 1:221/192, don@exlibris.tdkcs.waterloo.on.ca
|
||
sylvia -- 1:221/194, max@exlibris.tdkcs.waterloo.on.ca
|
||
Tim -- pozar@kumr.lns.com
|
||
|
||
(Postal Service mailing address)
|
||
FidoNews
|
||
128 Church St.
|
||
Kitchener, Ontario
|
||
Canada
|
||
N2H 2S4
|
||
|
||
max & Don voice: (519) 570-3137
|
||
|
||
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 1994 Sylvia Maxwell. All rights reserved. Duplication
|
||
and/or distribution permitted for noncommercial purposes only. For use
|
||
in other circumstances, please contact the original authors, or the eds.
|
||
|
||
OBTAINING COPIES: The most recent issue of FidoNews in electronic
|
||
form may be obtained from the FidoNews BBS via manual download or
|
||
Wazoo FileRequest, or from various sites in the FidoNet and Internet.
|
||
PRINTED COPIES may be obtained by sending SASE to the above paper-mail
|
||
address, or trade for copy of your 'zine.
|
||
|
||
INTERNET USERS: FidoNews is available via FTP from ftp.fidonet.org,
|
||
in directory ~ftp/pub/fidonet/fidonews.
|
||
|
||
Anyone interested in getting a copy of the INTERNET GATEWAY FAQ may
|
||
freq GISFAQ.ZIP from 1:133/411.0, or send an internet message to
|
||
fidofaq@gisatl.fidonet.org. No message or text or subject is
|
||
FidoNews 11-37 Page: 19 12 Sep 1994
|
||
|
||
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 BBS, or Wazoo filerequestable
|
||
from 1:1/23 as file "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.
|
||
|
||
"the pulse of the cursor is the heartbeat of fidonet"...
|
||
-- END
|
||
----------------------------------------------------------------------
|
||
|