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 ... ... 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! 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? 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 ----------------------------------------------------------------------