F I D O N E W S Volume 16, Number 09 01 March 1999 +----------------------------+---------------------------------------+ | The newsletter of the | ISSN 1198-4589 Published by: | | FidoNet community | "FidoNews" | | _ | +27-41-581-5913 [5:5/23] | | / \ | | | /|oo \ | | | (_| /_) | | | _`@/_ \ _ | | | | | \ \\ | Editor: | | | (*) | \ )) | Henk Wolsink 5:7104/2 | | |__U__| / \// | | | _//|| _\ / | | | (_/(_|(____/ | | | (jm) | Newspapers should have no friends. | | | -- JOSEPH PULITZER | +----------------------------+---------------------------------------+ | Submission address: FidoNews Editor 5:5/23 | +--------------------------------------------------------------------+ | MORE addresses: | | | | submissions=> editor@fidonews.org | | hwolsink@catpe.alt.za | +--------------------------------------------------------------------+ | For information, copyrights, article submissions, | | obtaining copies of FidoNews or the internet gateway FAQ | | please refer to the end of this file. | +--------------------------------------------------------------------+ Table of Contents 1. EDITORIAL ................................................ 1 2. GUEST EDITORIAL .......................................... 2 Announcing Candidacy for Z1C... maybe .................... 2 What's Not Happening - Elections ......................... 2 3. LETTERS TO THE EDITOR .................................... 5 SPAM-lite in FidoNews? Ptooie! .......................... 5 4. ARTICLES ................................................. 6 Grunged Echomail Deleted (a Response) .................... 6 Letter from a concerned reader? .......................... 6 The Shrinking Nodelist - What can be done? ............... 7 Zone 1 Backbone Service Level Agreement .................. 8 5. COLUMNS .................................................. 20 ECHO TALK - Monkey Business .............................. 20 6. NOTICES .................................................. 21 7. FIDONET BY INTERNET ...................................... 22 8. FIDONEWS INFORMATION ..................................... 26 FIDONEWS 16-09 Page 1 1 Mar 1999 ================================================================= EDITORIAL ================================================================= Greetings, On my question in the 16-07 issue about Z2 and in particular R29, I received a very interesting e-mail from a SysOp there. It seems, that the Z2C just wants to show how big or is it small, he can be. What a great pity. As the saying goes: it takes all kinds to make the world go round. ;-) Since I do have the full message and the authors name here on file, he has given permission to use it. Some interesting articles this week. From a message I saw, Bob Satti has decided not stand for another term as Z1C. Thats the spirit Bob, one should not have two *C positions as far as I'm concerned. ;-) Happy reading, ----------------------------------------------------------------- FIDONEWS 16-09 Page 2 1 Mar 1999 ================================================================= GUEST EDITORIAL ================================================================= I'm not sure why I'm doing this... you'd think I'd learn. Last year I announced a candidacy for the Z1EC election, only to find that the election I'd expected never happened. Things are different this year, though. In announcing for the Z1C sysop-level election, I'm not expecting it to be held. In fact, there's been no hint from the Zone 1 RC's, who are empowered by policy to elect a Zone Coordinator, that there are any plans afoot, let alone a sysop-level election. I'm interpreting the silence from the RC's as an indication that Bob Satti will receive a vote of confidence, as happened last year, and this will serve as an election for an additional two-year term. So why run for an office when I don't expect an open election? Mostly because I believe that there should be one. There are at least two good reasons for this: 1. Fidonet sysops have expressed a consistent desire that representative positions be determined by sysop-level election rather than by the appointments specified in Policy 4. It's become fairly common practice at the NC level and a growing number of RC's are elected... but not the ZC. 2. Bob Satti currently holds the simultaneous positions of Zone Coordinator for Zone 1 and International Coordinator for all of Fidonet. One of these positions is more than enough for one man - it's time to let go. Whether there is an open election or not, I intend to start acting like a candidate. Currently I plan to discuss two issues which I consider core to the ZC position - the shrinking nodelist and the subject of elections. Following those discussions, I'll try to follow up on whatever feedback comes from echomail and netmail. One outcome I'd like to see from this announcement is the encouragement of other candidates to announce so we can get a real forum going. Perhaps Bob Satti will even join us. I'd especially like to see the sysops of Fidonet actually conduct an open election themselves rather than waiting for the RC's to make a decision. Such an election would not be binding on the RC's of course, but would effectively communicate to them the expectations of the sysops. Hopefully the RC's would realize that this is a healthy process, and seriously consider it. ----------------------------------------------------------------- What's Not Happening - Elections .-- -- -- -- -- -- WHAT'S NOT HAPPENING -- -- -- -- -- --. | There isn't always something happening on Fidonet, but | | there's always something which isn't happening. This | FIDONEWS 16-09 Page 3 1 Mar 1999 | column is dedicated to the lost causes which make Fido | | what it isn't today. Published semi-occasionally... | `-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --' Douglas Myers 1:279/720 doug@mdtnbbs.com Perennial sport in the Fido echoes is the roasting of non-elected coordinators. Currently, Martin Belcke (Regional Coordinator of Region 11) is the recipient of the honors, but he shares the limelight on a rotating basis with Dallas Hinton (RC17) and Bob Satti (Zone 1 Coordinator and International Coordinator), with occasional guest appearances by other notables. In all fairness, the criticism doesn't center on Martin's performance as RC. Indications are that he does a good job in that capacity, and probably enjoys widespread support in his own region. The criticism centers on a deep-seated conviction on the part of many that representative positions in Fido should be determined by regularly-scheduled, public elections. Unfortunately, Fido policy doesn't actually require elections - all coordinator positions are appointments by policy. However, it's become customary for a substantial number of these positions to hold public, sysop-level elections with the elected candidate then appointed per policy, and proponents of elections want that practice uniformly applied. Election advocates make several claims to support their wishes: 1. Elections, if uniformly applied, would revitalize Fidonet. This seems highly doubtful to me, as the main reason for Fido's shrinking nodelist seems to be the simple fact that computer enthusiasts have found the Internet more attractive than local BBSes. 2. Elections yield better leaders. This is unsupported, and I doubt that it can be demonstrated. However, I believe regularly-scheduled elections encourage some minimum of responsiveness from representatives, or - at least - provide a means for their removal at the next election if unsatisfactory. 3. Elections "validate" a coordinator. This seems to be the strongest argument for elections to me. No matter how controversial the election, most folks recognize a voting process as valid. Martin and his supporters offer several reasons to decline holding an election: 1. Sysops in the region have indicated that they don't want an election - to hold one would act against the wishes of the majority. FIDONEWS 16-09 Page 4 1 Mar 1999 There does seem to be some validity to the claim that sysops in the region are generally satisfied with their present representation, or - at least - aren't in open revolt. Unfortunately, the basis for that claim isn't solid. Surveys have been conducted by both proponents and opponents of elections with, supposedly, conflicting results. I suspect that sysops in the region have no desire to elect another candidate, but are not necessarily opposed to holding elections. It's hard for me to see how an actual election would be any more of an imposition than all the surveys. 2. Elections are a messy procedure, leading to vocal conflict and general disharmony. If they're done right, this is true. However, what's the alternative? Morphine injections? 3. Elections don't necessarily lead to agreement; those who supported a candidate before still support him, those who didn't still don't, and those who didn't care still don't. It's certain that the arguments still go on after an election, often with charges of election irregularities. Still, most folks eventually concede that the fellow who got the most votes should represent. My prediction is that sysop-level elections for Regions 11 and 17 and for the Z1C position won't happen in the near future... but they should. Not because Fido will somehow be revitalized with elections, not because the unelected coordinators have done a poor job, but simply because Fido should be in the hands of the sysops who are members. ----------------------------------------------------------------- FIDONEWS 16-09 Page 5 1 Mar 1999 ================================================================= LETTERS TO THE EDITOR ================================================================= SPAM-lite in FidoNews? Dear Editor: It was with growing dismay that I read the two-page press release from Fast Engines, Inc. embedded in FIDO1606.NWS, touting their new web server utility. What made it worse was that it was the longest "article" in the Snooze -- although that is not the point. I'm really very disappointed. I didn't like the idea when you announced in FIDO1547.NWS that you would allow ads that related to "BBSs and/or Fidonet", but I assumed that you meant it would be limited to commerical products applicable to the majority of FidoNet. I assumed wrongly, it seems. Since the simple majority of us still run POTS dial-up BBSi and don't run web servers, Fast Engine's product has no utility for us. In fact, it amounts to SPAM-lite, if you will --a little less salty but it still gets piped directly to an audience that didn't solicit the ad, can't use the product, don't want it and still must pay to haul and store it. I note that several to the Snooze Editor on this subject were published in 1998 (Gary Petersen, Dave Garland in FIDO1523, Doc Logger in FIDO1547) and that all of them were objections. When Zorch raised the question FIDO1522, he appeared to have qualms about the appropriateness of commerical ads. Since the readership has commented that it doesn't want commerical ads, I ask that you revise your stand and cease publishing them. If I'm hungry for highly processed stuff in a brightly colored package, I'll seek it out on my own. Lee Ayrton 1:320/455 dayrton@mail.welseyan.edu ED: The editor has the right to publish what he/she thinks is appropriate for the newsletter. I have made it quite clear in the FIDONEWS echo, that I will allow advertising, provided it relates to computers and/or communication(s). No one editor, regardless for which or what publication it might be, has the same oppinion about what should or not be placed in the their newsletter, magazine or newspaper. Your objection has been noted and I appriciate feedback. Thanks. ----------------------------------------------------------------- FIDONEWS 16-09 Page 6 1 Mar 1999 ================================================================= ARTICLES ================================================================= Grunged Echomail Deleted (a Response) by Jerry Schwartz 1:142/928 A couple of weeks ago, Roy Tellason asked about the appropriateness of suppressing long (30kb) messages from the echomail distribution system. While I'm no expert in this matter, I can address his question about whether or not people are running software which needs to be protected from messages of this size. Not long ago, I posted a series of messages which were in the 16k range (approximately). I checked to make sure they weren't much bigger than that, but I didn't check their size exactly. I should have been more careful, I guess: one or another of those messages prevented my uplink from tossing the entire bundle! Again, I can't say what the limit is but I was certainly surprised that an OS/2 system running Squish would have problems with anything I, running the DOS version of Squish, could generate. So the answer is "Yes." Anyone posting messages in the 16kb+ range is creating a technical problem. As a technical solution, I'd certainly prefer to see messages split, rather than bounced or deleted, but I'm not in charge around here. ----------------------------------------------------------------- Letter from a concerned reader? (Henk, you may use this in FidoNews or not, as you wish. I am posting it here only because this is the closest thing to an administrative echo that is available to non-members.) I have been a Fidonet user since 1995, and have seen a bit of the discussion (and I use that word loosely) concerning administrative and policy matters of all sorts. I have observed (and occasionally taken part in) arguments over everything from the validity of Policy 4.07 and the need for an Echo Policy to the multiplicity of backbones and the effectiveness or ineffectiveness of certain hat-wearers. Although I wasn't around at the time, I understand all these counterproductive arguments are due to Fidonet's departure from the ideals and goals set by its founder, Tom Jennings. in fact, if what I have read is true, it was this very sort of in-fighting that led Mr. Jennings to leave Fidonet. Here is my revolutionary suggestion: Let us beseech Tom Jennings to return to Fidonet as a sort of one-man "supreme court" with the authority to arbitrarily overturn any existing policy and any FIDONEWS 16-09 Page 7 1 Mar 1999 actions (or inactions) taken by officials at any level of Fidonet, with such authority limited to a period of, say, two years. While the power of such a position may not appeal to Mr. Jennings, perhaps the opportunity to put fidonet back on track would be sufficient to bring him out of his self-imposed retirement. Just imagine the possibilities. At last we would know if Policy 4.07 actually serves the best interests of Fidonet as seen by its "founding father". We'd know for certain if ZCs must come from within the ranks of RCs, or if any sysop is eligible to run for the post. We'd even have someone with the authority to find out, once and for all, if Zorch Frezburg and Mark Hernandez are the same person! Please consider my suggestion carefully and seriously. Discuss it among yourselves. Fidonet membes, feel free to kick the idea around in your admin echoes. No one knows how Fidonet should be better than Tom Jennings, and it would be nice to have a "benevolent dictator" whose only interest was the good of Fidonet itself. Of course, actually getting Mr. Jennings to take such a job might be difficult, and getting him to stay with it for two full years without getting disgusted and leaving again may be well-night impossible; but we'll never know unless we try. Walter, wluffman@usit.net ED: Walter, I do not know the reason why Tom has left FidoNet, but what you are 'saying' has merit. ;-) ----------------------------------------------------------------- The Shrinking Nodelist - What can be done? Douglas Myers, 1:270/720, doug@mdtnbbs.com In this article, I'm discussing one of the issues I feel is pertinent to the Z1C election. In a separate article, I've announced my candidacy for this position; please note, however, that there's been no indication from the RC's that there will be an open election, so I may simply be talking through a non-existent "hat." Fidonet is losing nodes, particularly in Zone 1. The evidence is clear, in that each week I compile a smaller nodelist. This shrinking nodelist has been blamed on all sorts of things: excessive fighting in the echoes, lack of democratic elections throughout Fido, inaction by the Zone Coordinator and Regional Coordinators... While I would certainly like to see a friendlier atmosphere in the echoes... while I support the concept of sysop-level elections... and while there are some areas I'd like to see the ZC and RC's address... I don't think any of the above actions would reverse the trend of the shrinking nodelist. Sysops are simply taking down their BBSes because computer owners have chosen to connect to the world through the Internet instead. FIDONEWS 16-09 Page 8 1 Mar 1999 This is not necessarily bad news - the same internet technology which has attracted the general public away from Fido has also given us the means to maintain low-cost connections despite a smaller number of nodes. We can live with a smaller nodelist, and still have a viable and quality network. This doesn't mean we have to be passive and let Fido be swallowed by the Internet, but it does mean that we need to stop using the size of the nodelist as the sole indicator of the health of Fido. The health of Fido is best indicated by how we, the hobbyists, enjoy the hobby. If we maintain Fido in a state that we, the sysops, enjoy... then the job of inviting guests to join us will be all that much easier. The work has already begun - many individuals and teams have chosen to do something positive about the changing nature of Fidonet. Mail has long been transferred over the Internet, reducing costs and improving availability. The nodelist format has been positively altered to facilitate the integration of nodes operating strictly from the Internet. Enterprising sysops have offered QWK packets and Blue Wave packets to individuals through internet email attachments, effectively allowing individuals to function as users of their BBS without the necessity of logging on... and providing a low-cost alternative to the telenetable BBS. At least one net has established an information package for internet users, offering instructions for using the commonly-available windows terminal program to log onto a local BBS. All these efforts should be encouraged and expanded where possible. The shrinking nodelist isn't the death of Fidonet. If we make Fido the kind of place where we want to be, folks will join us. ----------------------------------------------------------------- Zone 1 Backbone Service Level Agreement by The Members of the Zone 1 Backbone ===================================== == Zone 1 Backbone == == Service Level Agreement == ===================================== SLA_9903.Z1B - Mar 99 ========================= Table of Contents =================== 1.0 Introduction 1.1 Purpose of this Document 1.2 Definitions 1.3 Service Level Agreement 1.4 Z1B Relationship to FidoNet FIDONEWS 16-09 Page 9 1 Mar 1999 1.5 Changes to this Document 2.0 Z1B Administration 2.1 Voting 2.2 Selection of Z1B Hubs 2.3 Selection of the Z1BC 2.4 Administrative Areas 3.0 Moderators 3.1 Moderator Identification 3.2 Moderator Responsibilities 3.3 Moderator Tools 3.4 Echo Addition 3.5 Echo Removal 3.6 Echo Name Change 4.0 Standard Operating Procedures 4.1 Technical Standards 4.2 Gateways 4.3 Encrypted Messages 4.4 Encoded Files in Echoes 4.5 Illegal Activities 4.6 Censorship of Messages 4.7 Anonymous Remailers 4.8 Emergency Plans (Items noted by the "|" are changes from the previous version.) 1.0 Introduction =================== 1.1 Purpose of this Document ------------------------------- This Service Level Agreement has been assembled as a means to provide information about the Zone 1 Backbone, how it operates, what it offers, what it expects in return, and to provide insight as to its internal administration. This document is updated as circumstances and practices change. Please ensure that you are referencing a current edition. 1.2 Definitions ------------------ Zone 1 Backbone - A group of volunteer FidoNet hubs who help distribute echomail and routed netmail in FidoNet Zone 1 (North America). The structure is customarily recognized as a set of tiers with the intention of distributing echomail in an accurate and expeditious manner. Hereafter in this document the Zone 1 Backbone is referred to simply as the Z1B. Echo or Conference - An echomail conference is a message base or forum, distributed under a specified echomail conference name or tag, dealing with a defined area of interest. Hereafter in FIDONEWS 16-09 Page 10 1 Mar 1999 this document echomail conferences are referred to simply as echoes. Zone 1 Backbone Hub - A hub who helps to distribute mail within the Zone 1 Backbone. Tier 1 Z1B Hubs, also known as ZHubs or Stars, distribute mail at the zone level. They are fully meshed with each other for speed and reliability. Tier 2 Z1B Hubs, also known as RHubs, distribute mail at the region level. Tier 3 Z1B Hubs distribute mail at the net level. Zone 1 Backbone Coordinator (Z1BC) - Person responsible for the day-to-day operation of the Zone 1 Backbone. He coordinates routing to ensure reliable and efficient transport of echomail and Z1B-routed netmail while avoiding creation of duplicate messages. He also serves as liaison to the ZEC and to other distribution systems. Echomail Coordinators (ECs) - Echomail Coordinators have been recognized by Fidonet since 1987. The Zone Echomail Coordinator (ZEC) functions at the zone level. Region Echomail Coordinators (RECs) function at the region level. Net Echomail Coordinators (NECs) function at the net level. BACKBONE.Z1B - A text file listing all echoes, and their descriptions, which are presently distributed by the Zone 1 Backbone. This text file is formatted in a manner which makes it easily readable by echomail distribution software to use as a "forward list". It is published weekly by the Z1BC and distributed in the BACKBONE file area. BACKSTAT.Z1B - A text file containing the Zone 1 Backbone status report which, among other things, itemizes echoes which are in the process of being added to or dropped from the Zone 1 Backbone, as well as listing the Tier 1 and 2 Z1B Hubs, and the Z1BC. It is published weekly by the Z1BC and distributed in the BACKBONE file area. It is advisable that those who rely on the Zone 1 Backbone get in the habit of reading this file. SLA_xxxx.Z1B (xxxx = yymm version) - This document. It is published monthly by the Z1BC and distributed in the BACKBONE file area. Moderator - Person(s) responsible for an echo and its liaison with the Zone 1 Backbone. EchoList - A database containing a list of echoes, published monthly by the EchoList Coordinator (1:1/21). It customarily contains echo names, moderator names and addresses, and descriptions of the echoes. Gateways - Echomail Gateways are nodes whose systems are used to exchange mail with other groups. The term Gateway, as used here, includes all forms of gating including, but not limited to, FidoNet zone gating, inter-distribution system gating, inter-network gating, and domain gating. FIDONEWS 16-09 Page 11 1 Mar 1999 1.3 Service Level Agreement ------------------------------ The members of the Z1B agree to distribute mail in the most accurate and expeditious manner possible within their means. Although they agree to provide the best service possible, they do not have control over all of the factors thus some problems might occur occasionally. Netmail messages which are time critical or require sensitive handling should be sent direct. The Tier 1 and 2 Z1B Hubs agree to make available all echoes which are listed in BACKBONE.Z1B. Tier 3 Z1B Hubs are not obligated to distribute all listed echoes. In no case does any Z1B Hub agree to distribute any echo which, in their own opinion, could subject them to consequences which might have a negative effect on their well being. The Z1B encourages the use of "echo-path routed netmail" (ERN) as a means of keeping echo volume and off-topic posts at a reasonable level. Z1B Hubs agree to accept routed netmail from any node who connects with them. Any netmail message with a deliverable destination within FidoNet, regardless of its origin, is accepted. The Z1B Hubs agree to route ERN according to the wishes of the individual nets. The Z1B Hubs depend on regional routing maps provided by the RECs to represent these wishes. The Z1B encourages all nets to list every ERN connection path to the nearest Tier 1 (zone level) Hub, regardless of distribution system, in their region's chart. This will allow ERN to follow the best path available. When these paths are not known or are not available, Z1B Hubs agree to route ERN along echomail paths or to a ZC, RC, or NC who has agreed to handle such mail. The Z1B Hubs agree that ERN is for personal messages. It is not for commercial messages, echoes, tunneling, mailing lists, news groups, file-attaches, "encoded" files, pyramid letters, or chain letters. Thus, the Z1B Hubs do not agree to route such messages. The Z1B Hubs agree to treat all in-transit netmail as private mail. The Z1B Hubs agree to not read or disclose routed netmail which passes through their systems, except as required for technical or legal reasons. The Z1B consists of volunteers. It does not agree to handle any echo which could take the fun out of the hobby. Use of Z1B services should be viewed as a privilege, not a right. Any or all of these services may be terminated at any time, without any prior notice. All Z1B Hubs agree to the terms of this document. 1.4 Z1B Relationship to FidoNet ---------------------------------- The Z1B is indeed part of FidoNet. It's made up of a voluntary group of FidoNet members. It exists within FidoNet and must abide by FidoNet Policy, just as any other FidoNet node or group of FidoNet FIDONEWS 16-09 Page 12 1 Mar 1999 nodes. However, the Z1B is not an entity or sub-division of FidoNet in the sense that it is not mandated or defined by FidoNet Policy and is not operated by FidoNet officials. There is no requirement for the Z1B to offer services and there is no requirement for anyone to use the Z1B's services. This document is not a part of FidoNet Policy. Should any part of this document conflict with FidoNet Policy, then FidoNet Policy shall prevail. 1.5 Changes to this Document ------------------------------- This document is changed only as the result of a two-thirds vote. Anyone may propose a change by finding a Tier 1 or 2 Z1B Hub who is willing to sponsor it for them. 2.0 Z1B Administration ========================= 2.1 Voting ------------- Tier 1 and 2 Z1B Hubs, as listed in BACKSTAT.Z1B, get 1 vote each. Nobody else may vote. All voting is by public ballot in the Z1B_Coord echo. The standard voting period is 1 week. Unless specified otherwise, a majority vote (more than half of those voting) is the norm. Certain decisions, as noted, require a two-thirds vote (at least two-thirds of those voting). A recall vote can not be held until at least 4 months has elapsed since the prior selection or recall vote for the person holding that position. 2.2 Selection of Z1B Hubs ---------------------------- Tier 1 Z1B Hubs are selected by a majority vote. They are normally chosen from amongst the Tier 2 Z1B Hubs. They serve an indefinite term but are subject to recall by a two-thirds vote. Tier 2 Z1B Hubs are selected by a majority vote. Anyone may apply by finding a Tier 1 or 2 Z1B Hub who is willing to nominate them. The applicant should connect to either a Tier 1 or 2 Z1B Hub and route netmail and/or echomail for at least a few nets other than their own. They serve an indefinite term but are subject to recall by a two-thirds vote. FIDONEWS 16-09 Page 13 1 Mar 1999 Tier 3 Z1B Hub selection is left up to the individual nets. 2.3 Selection of the Z1BC ---------------------------- The Z1BC is selected by a majority vote. Anyone may apply by finding a Tier 1 or 2 Z1B Hub who is willing to nominate them. He serves a 1 year term but is subject to recall by a two-thirds vote. Note: The term of the current Z1BC expires on April 1, 1999. 2.4 Administrative Areas --------------------------- The Z1B uses two echoes of its own and two shared file areas to conduct its business. The Z1BACKBONE echo is open to any node having business with the Z1B. The moderator for this area is selected by a majority vote. He serves an indefinite term but is subject to recall by a two-thirds vote. The Z1B_COORD echo is restricted to Tier 1 and 2 Z1B Hubs, the Z1BC, and invited guests. Guests are invited by a majority vote. The moderator for this area is the Z1BC. The Z1B also makes use of the shared BACKBONE and Z1_REC file areas. 3.0 Moderators ================= 3.1 Moderator Identification ------------------------------- The Z1B refers to the current EchoList in order to identify an echo's moderator. As far as the Z1B is concerned, all individuals listed as moderators or co-moderators of a particular echo are equal. In case of disagreement, however, the moderator listed first has priority. Moderators are encouraged to appoint co-moderators to assist them in their duties and to stand in for them in their absence. This will ensure that the echo is properly maintained, especially in the case of a moderator who is frequently absent for long periods of time. 3.2 Moderator Responsibilities --------------------------------- The responsibilities of a moderator of an echo which the Z1B distributes are: 1) Seeing that messages in their echo correspond to the echo's FIDONEWS 16-09 Page 14 1 Mar 1999 theme. 2) Updating their echo's listing in the Echolist at least every six months. 3) Preventing the distribution of their echo from interfering with the operation of the Z1B. 4) Must be accessible via netmail through known channels. 5) Seeing that messages in their echo do not violate the standards set in Section 4. When moderators place their echoes on the Z1B they must realize that Z1B Hubs distribute publicly available echoes and that the job of enforcing any kind of access restrictions remains with the moderator. These restrictions, as well as the echo's rules, are usually available in the EchoList so that any Sysop interested in the echo may review them prior to actually carrying the echo on his or her system. 3.3 Moderator Tools ---------------------- The Z1B provides some "tools" to a moderator in order to help him/her carry out their responsibilities. If a moderator believes that a node is violating an echo rule, he/she may request the feed to that node be severed. This request is made in written form (netmail), to the Z1B Hub feeding the offending node, with a copy to the offending node. It is recommended that a copy also be sent to the node's NEC so that he or she is aware of such problems in the net and can provide information and assistance. Some important points to remember regarding feed cut requests: 1) Feed cuts should be initiated with an effort to cause the least amount of disruption to the echo. 2) In most cases, the main goal of a feed cut is to remove a REPEAT offender who is likely to cause future echo disruption. 3) Echo rule offenders are, in most cases, PEOPLE - not systems. 4) SYSTEMS should not be cut until efforts to remove the PERSON have failed. Moderators should attempt to resolve problems as close to the root of the problem as possible, i.e., user first, SysOp second, hub third, etc. 5) Feed cuts at the zone level are taken very seriously. Only use them as a last resort after all other means have failed. Have proper documentation ready to support a link cut request at the zone level showing that all other efforts have failed. 6) Feed cut requests are just that - requests. Communications should be polite and not demanding as you are REQUESTING help FIDONEWS 16-09 Page 15 1 Mar 1999 from another system. 3.4 Echo Addition -------------------- The Z1BC adds an echo to Z1B distribution when all of these requirements are met: 1) The moderator lists the echo in the EchoList. See the EchoList FAQ for information about how to do this. 2) The moderator requests that the echo be distributed by the Z1B. The request should be sent from one of the moderator addresses listed in the EchoList, via one of the following methods, preferably "A". A) Echomail: To "Z1B", in the Z1BACKBONE echo B) Netmail: To "Z1B", at the Z1BC's FidoNet address C) Email: To the Z1BC's Internet address, subject "Z1B" The body of the request should consist of a current copy of the EchoList listing for the echo. This could be taken from a recent message from the EchoList (netmail, email or echomail) or be an excerpt from the current EchoList itself. The echo is then listed in BACKSTAT.Z1B as requesting addition. 3) Within one month of being initially being listed in BACKSTAT.Z1B, two Tier 1 or 2 Z1B Hubs and/or RECs request that the Z1B distribute the echo. The requests should be sent via one of the following methods, preferably "A". A) Echomail: To "Z1B", in the Z1BACKBONE echo B) Netmail: To "Z1B", at the Z1BC's FidoNet address C) Email: To the Z1BC's Internet address, subject "Z1B" The requests are noted in BACKSTAT.Z1B. If two requests are not forthcoming, prior to the one month expiring the moderator may request a one month extension from the Z1BC. The echo is then added to BACKBONE.Z1B and this is noted in BACKSTAT.Z1B. A welcome message is sent in the echo to help establish links. At this time any private links to the echo should be switched to the Z1B. 3.5 Echo Removal ------------------- The Z1BC removes an echo from Z1B distribution when any of these situations occur: FIDONEWS 16-09 Page 16 1 Mar 1999 1) The echo is not listed in the EchoList. The echo is first listed as "not in EchoList" in BACKSTAT.Z1B for up to 3 months, then it is dropped entirely. During these 3 months, weekly warning messages are posted in the echo alerting the moderator and the users as to the echo's status. If at any time during these 3 months it is re-listed in the EchoList then it's status is restored. 2) Unconditionally when the moderator sends a direct request to the Z1BC that the echo be removed. The request should be sent from one of the moderator addresses listed in the EchoList, to one of the following: A) Echomail: To "Z1B", in the Z1BACKBONE echo B) Netmail: To "Z1B", at the Z1BC's FidoNet address C) Email: To the Z1BC's Internet address, subject "Z1B" 3) The moderator fails to properly carry out his responsibilities (see Section 3.2). 4) The traffic level in the echo falls below 2 messages for any month. The echo is first listed as "low traffic" in BACKSTAT.Z1B for up to 6 months, then it is dropped entirely. If at any time during these 6 months the traffic level rises to or above 5 messages for any month then it's status is restored. The Z1B drops echoes when the traffic level falls below a minimum: A) To encourage the formation of new echoes, like pruning dead branches off a tree. B) To save the SysOps and users from the frustration of setting up areas only to find that they are dead. 5) When it is decided by a two-thirds vote that the distribution of an echo is not in the best interest of the Z1B. All changes in status of echoes are noted in BACKSTAT.Z1B. 3.6 Echo Name Change ----------------------- In order to change the name of an echo which is currently distributed by the Z1B, without the necessity of reapproval, you should: 1) EchoList the new echo name. 2) Set a date for the change to occur. This date should give all concerned plenty of time to prepare. Generally, a 3-4 week notice should suffice. The proposed date for the change should fall on a Sunday. 3) Spread the word of the impending name change. Do so in the FIDONEWS 16-09 Page 17 1 Mar 1999 affected echo, the Z1BACKBONE echo, and via netmail or email to the Z1BC. 4) Item 3 should be repeated at least once per week before the name change is to occur. 5) On the day before the change is to occur, send a netmail reminder to the Z1BC. 6) The change occurs. The new echo name is added to BACKBONE.Z1B and the old echo name is removed. 4.0 Standard Operating Procedures ==================================== 4.1 Technical Standards -------------------------- The Z1B observes FTSC specifications FTS-0001 and FSC-0074. Notes: 1) All Z1B Hubs use the pathline. 2) The Z1B considers the "toUserName", "fromUserName" and "Origin Line" to be control information lines, thus character set restrictions apply. 3) The requirement that control information lines shall contain only ASCII characters, from 32 to 126, is extended to include hi-bit alphabetic characters, including 128 to 168, 173, and 224 to 240. 4) Echomail messages older than 30 days may considered to be dupes. This technique has undergone much testing and has proven its value in preventing dupes due to massive rescans without interfering with the flow of normal echomail. 5) Due to the limitations of some current software, the Z1B can not guarantee delivery of messages in excess of 30K bytes. Z1B Hubs are encouraged to use message processing software which allows larger messages, preferably up to 64K bytes, to be handled. Z1B Hubs may split large messages to ensure their safe passage. Z1B Hubs may delete messages which do not conform to these technical standards when such messages might be harmful to the technical operation of the Z1B. This includes duplicate messages and "grunged" messages. Such messages are generally not returned. Z1B Hubs operate in a secure fashion. They automatically process inbound messages only from those nodes with which prior agreements have been made. Normally this means that Z1B Hubs use session passwords and secure ("protected") inbound areas. However, any reasonable method of ensuring that non-secure messages do not enter FIDONEWS 16-09 Page 18 1 Mar 1999 the Z1B is acceptable. A Z1B Hub may choose not to provide services to a node which does not operate in a secure fashion. 4.2 Gateways --------------- Gateways must remove foreign distribution identifiers (including seen-bys) which might adversely affect the distribution of the echo on the Z1B. Pathlines, however, should be left intact. The origin line should be that of the Gateway. Gateways also pass netmail into the other network, unless it is technically impossible to do so. 4.3 Encrypted Messages ------------------------- Some Z1B Hubs do not allow encrypted messages to flow through their systems. Therefore, the Z1B does not agree to handle encrypted messages in routed netmail or in echoes, excepting digital signatures and occasional demonstration and/or test messages. 4.4 Encoded Files in Echoes ------------------------------ Echomail is not an efficient method of transporting files. There are many File Distribution Networks which can be used instead. Thus the Z1B does not distribute any echo which routinely contains large (multi-message) encoded files. The use of an echo for small or occasional encoded files is left up to the discretion of its moderator. 4.5 Illegal Activities ------------------------- The Z1B does not distribute any echo which routinely contains messages which contain illegal information, or promote illegal activities. As used in this paragraph, "illegal activities" includes activities which are a violation of civil law as well as activities which could result in criminal prosecution. 4.6 Censorship of Messages ----------------------------- Z1B Hubs do not delete or alter messages as they are distributed, except for technical reasons. If a Z1B Hub feels that netmail messages may lead to legal action against him then he may decline to handle such messages, as per FIDONEWS 16-09 Page 19 1 Mar 1999 FidoNet Policy. If a Z1B Hub feels that echomail messages may lead to legal action against him then he may decline to handle that echo in its entirety, notifying the echo's moderator. The Z1B does not distribute any echo which routinely contains counterfeit messages. A counterfeit message is 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. 4.7 Anonymous Remailers -------------------------- An "Anonymous Remailer" (AR) is software which conceals the identity of a message's author. Use within an echo is up to the moderator of that echo. However, an AR should not be used in an echo until the echo's moderator has informed the operator of the AR that such messages would be welcome. The burden of proof that such a request has been granted is carried by the operator of the AR. 4.8 Emergency Plans ---------------------- The Tier 1 Z1B Hubs maintain emergency backup plans should one of them experience problems. These plans include: 1) Quick availability of replacement equipment. 2) Adequate backups of necessary control information. 3) Standby nodes capable of assuming the load. 4) Alternate routing to bypass a down Tier 1 Z1B Hub. ================================== End =============================== ----------------------------------------------------------------- FIDONEWS 16-09 Page 20 1 Mar 1999 ================================================================= COLUMNS ================================================================= ECHO TALK - Monkey Business . -- -- -- -- -- ECHO TALK -- -- -- -- -- . | Food for thought from Fido's echomail. | | Purloined without permission by D Myers | ` -- -- -- -- -- -- - -- -- -- -- -- -- ' RanD on the structure of Fidonet: -------------------------------- Fidonet is like a tree full of monkeys, all on different limbs at different levels. Some monkeys are climbing up, some down. The monkeys on top look down and see a tree full of smiling faces. The monkeys on the bottom look up and see nothing but assholes. ----------------------------------------------------------------- FIDONEWS 16-09 Page 21 1 Mar 1999 ================================================================= NOTICES ================================================================= Future History 12 May 1999 12th Anniversary of Fido Operations in Zone 4; 10th Anniversary of the creation of FidoNet Zone 4. 24 Jul 1999 XIII Pan American Games [through 8 Aug 99]. 9 Jun 1999 Tenth Anniversary of the adoption of FidoNet Policy 4.07. 10 Sep 1999 10th anniversary of Zone 5 operations. 26 Oct 1999 Thirty years from release Abbey Road album by the Beatles. 31 Dec 1999 Hogmanay, Scotland. The New Year that can't be missed. 1 Jan 2000 The 20th Century, C.E., is still taking place thru 31 Dec. 1 Jun 2000 EXPO 2000 World Exposition in Hannover (Germany) opens. 15 Sep 2000 Sydney (Australia) Summer Olympiad opens. 21 Sep 2000 10 years of FidoNet in +7 (xUSSR) 1 Jan 2001 This is the actual start of the new millennium, C.E. -- If YOU have something which you would like to see in this Future History, please send a note to the FidoNews Editor. ----------------------------------------------------------------- FIDONEWS 16-09 Page 22 1 Mar 1999 ================================================================= FIDONET BY INTERNET ================================================================= This is a list of all FidoNet-related sites reported to the FidoNews Editor as of this issue; see the notice at the end. FidoNet: Homepage http://www.fidonet.org FidoNews http://www.fidonews.org [HTML] http://209.77.228.66/fidonews.html [ASCII] WWW sources http://travel.to/fidonet/ FTSC page http://www.ftsc.org/ Echomail [pending] General http://owls.com/~jerrys/fidonet.html http://www.nrgsys.com/orb/foti List servers: http://www.onelist.com/subscribe.cgi/fidonet-discussion ============ Zone 1: http://www.z1.fidonet.org Region 10: http://www.psnw.com/~net205/region10.html Region 11: http://oeonline.com/~garyg/region11/ Region 13: Net 264: http://www.net264.org/r13.htm Region 14: Net 282: http://www.rxn.com/~net282/ Region 17: http://www.nwstar.com/~region17/ Region 18: http://techshop.pdn.net/fido/ Region 19: http://www.compconn.net/r19 Zone 1 Elist http://www.baltimoremd.com/elist/ Not sure where the following should be placed: http://www.angelfire.com/biz/snwvlly/fido.html ============ Zone 2: http://www.z2.fidonet.org ZEC2: Zone 2 Elist: http://www.fbone.ch/echolist/ Region 20: http://www.fidonet.pp.se (in Swedish) FIDONEWS 16-09 Page 23 1 Mar 1999 Region 23: http://www.fido.dk (in Danish) Region 24: http://www.swb.de/personal/flop/gatebau.html (German) Fido-IP: http://home.nrh.de/~lbehet/fido (English/German) Region 25: http://www.bsnet.co.uk/net2502/net/ Region 26: http://www.nemesis.ie REC 26: http://www.nrgsys.com/orb Region 27: http://telematique.org/ft/r27.htm Region 29: http://www.rtfm.be/fidonet/ (French) Region 30: http://www.fidonet.ch (German) Region 33: http://www.fidoitalia.net (Italian) Region 34: http://www.pobox.com/cnb/r34.htm (Spanish) REC34: http://pobox.com/~chr Region 36: http://www.geocities.com/SiliconValley/7207/ Region 38: http://public.st.carnet.hr/~blagi/bbs/adriam.html Region 41: http://www.fidonet.gr (Greek/English) Region 42: http://www.fido.cz Region 48: http://www.fidonet.org.pl Region 50: http://www.fido7.com/ (Russian) Net 5010: http://fido.tu-chel.ac.ru/ (Russian) Net 5015: http://www.fido.nnov.ru/ (Russian) Net 5030: http://kenga.ru/fido/ (Russian & English) Net 5073: http://people.weekend.ru/soa/ (Russian) ============ Zone 3: http://www.z3.fidonet.org ============ Zone 4: Region 90: http://visitweb.com/fidonet Net 903: http://www.playagrande.com/refugio Net 904: http://members.tripod.com/~net904 (Spanish) ============ Zone 5: http://www.eastcape.co.za/fidonet/index.htm ============ Zone 6: http://www.z6.fidonet.org FIDONEWS 16-09 Page 24 1 Mar 1999 Region 65: http://www.cfido.com/fidonet/cfidochina.html (Chinese) ============ Pages listed above are as submitted to the FidoNews Editor, and generally reflect Zone and Regional Web Page sites. If no Regional site is submitted, the first Network page from that Region is used in its place. Generally, Regional pages should list access points to all Networks within the Region. TCP/IP accessible node access information should be submitted to the FidoNews Editor for inclusion in their Region or Zone. -----------oOo------------- Fidonet Via Internet Hubs Node# | Operator | Facilities (*) | Speed | Basic Rate -----------+-------------------+----------------+-------+------------ 1:12/12 | Ken Wilson | FTP | T1 | $24mo. 1:13/25 | Jim Balcom | FTP | 56k | $20mo. 1:106/1 | Matt Bedynek | FTP,VMoT,UUE | 64k | $5/$15mo. 1:106/6018 | Lawrence Garvin | FTP,VMoT | 64k | $5/mo. 1:107/451 | Andy Knifel | FTP, VMoT, UUE | 33.6 | n/c 1:140/12 | Bob Seaborn | FTP | T1 | $5/$20 1:270/101 | George Peace | FTP | T1 | $30mo. 1:271/140 | Tom Barstow | UUE | T1 | n/c 1:275/1 | Joshua Ecklund | UUE | 28.8 | $10/yr. 1:280/169 | Brian Greenstreet | FTP | 33.6 | $2mo. 1:2401/305 | Peter Rocca | FTP,UUE | T1 | unkn 1:2424/10 | Alec Grynspan | FTP,UUE | T1 | n/c 1:2604/104 | Jim Mclaughlin | FTP,VMoT,UUE | 33.6 | $1mo. 1:2624/306 | D. Calafrancesco | VMoT | 33.6 | $15yr. 1:345/0 | Todd Cochrane | FTP | T1 | n/c 1:346/250 | Aran Spence | FTP,UUE | T1 | $10mo. 1:396/45 | Marc Lewis | UUE | 33.6 | $26/yr. 1:3651/9 | Jerry Gause | FTP,VMoT | 33.6 | $3/$6 1:396/1 | John Souvestre | FTP,VMoT | T1 | $15mo. 2:335/535 | Mario Mure | VMoT,UUE | 64k | n/c 2:254/175 | Alex Kemp | UUE | 56k | n/c 2:284/800 | Jeroen VanDeLeur | FTP,UUE | 64k | n/c 2:335/610 | Gino Lucrezi | UUE | 33.6 | n/c 2:469/84 | Max Masyutin | VMoT | 256k | n/c 2:2411/413 | Dennis Dittrich | UUE | 64k | n/c 2:2474/275 | Christian Emig | UUE | 64k | unkn 3:633/260 | Malcolm Miles | FTP | 33.6 | n/c 4:905/100 | Fabian Gervan | VMoT, UUE | ??? | n/c 5:7104/2 | Henk Wolsink | FTP | 28.8 | n/c -- * FTP = Internet File Transfer Protocol * VMoT = Virtual Mailer over Telnet (various) * UUE = uuencode<->email type transfers [I'm only cataloging transfer methods, eg, ftp, email, telnet. Specific programs using these protocols are no longer being listed. Contact the system operators for details of which programs they have available.] FIDONEWS 16-09 Page 25 1 Mar 1999 Compiled by C. Ingersoll, 1:2623/71, (609)814-1978, fbn@dandy.net Posted on the 1st of every month in FN_SYSOP, R13SYSOP and Fidonews. ----------------------------------------------------------------- FIDONEWS 16-09 Page 26 1 Mar 1999 ================================================================= FIDONEWS INFORMATION ================================================================= ------- FIDONEWS MASTHEAD AND CONTACT INFORMATION ------- Editor: Henk Wolsink Editors Emeriti: Tom Jennings, Thom Henderson, Dale Lovell, Vince Perriello, Tim Pozar, Sylvia Maxwell, Donald Tees, Christopher Baker, Zorch Frezberg "FidoNews Editor" FidoNet 5:5/23 BBS +27-41-581-5913, 2400/9600/V34 more addresses: Henk Wolsink -- 5:7104/2, hwolsink@catpe.alt.za (Postal Service mailing address) FidoNews Editor P.O. Box 12325 Port Elizabeth, 6006 South Africa ------------------------------------------------------ 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 and/or the Editor. Authors retain copyright on individual works; otherwise FidoNews is Copyright (C) 1999 Henk Wolsink. 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 FidoNet and the 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 [FNEWSGnn.ZIP] for a particular Issue. Monthly Volumes are available as FNWSmmmy.ZIP where mmm = three letter month [JAN - DEC] and y = last digit of the current year [9], i.e., FNWSJAN9.ZIP for all the Issues from Jan 99. FIDONEWS 16-09 Page 27 1 Mar 1999 Annual volumes are available as FNEWSn.ZIP where n = the Volume number 1 - 16 for 1984 - 1999, respectively. Annual Volume archives range in size from 48K to 1.4M. INTERNET USERS: FidoNews is available via: http://www.fidonews.org ** http://www.fidonet.org/fidonews.htm ** ftp://ftp.fidonet.org/pub/fidonet/fidonews/ ftp://ftp.irvbbs.com/fidonews/ ftp://ftp.nwstar.com/Fidonet/Fidonews And in non-English formats via: ** http://www.hvc.ee/pats/fidonews (Estonian) http://www.fidonet.pp.se/sfnews (Swedish) ** LINK HAS NOT BEEN UPDATED *=*=* You may obtain an email subscription to FidoNews by sending email to: jbarchuk@worldnet.att.net with a Subject line of: subscribe fnews-edist and no message in the message body. To remove your name from the email distribution use a Subject line of: unsubscribe fnews-edist with no message to the same address above. * You may retrieve current and previous Issues of FidoNews via FTPMail by sending email to: ftpmail@fidonews.org with a Subject line of: help and FTPMail will immediately send a reply containing details and instructions. When you actually make a file request, FTPMail will respond in three stages. You find a link for this process on www.fidonews.org. *=*=* You can read the current FidoNews Issue in HTML format at: http://www.fidonews.org and in the FIDONEWS echo. STAR SOURCE for ALL Past Issues via FTP and file-request - Available for FReq from 1:396/1 or by anonymous FTP from: FIDONEWS 16-09 Page 28 1 Mar 1999 ftp://ftp.sstar.com/fidonet/fnews/ Each yearly archive also contains a listing of the Table-of-Contents for that year's issues. The total set is currently about 13 Megs. =*=*=*= The current week's FidoNews are now also available almost immediately after publication on the FidoNews Editor homepage on the World Wide Web at: http://209.77.228.66/fidonews.html There are also links there to jim barchuk's HTML FidoNews source and to John Souvestre's FTP site for the archives. There is also an email link for sending in an article as message text. Drop on over. =*=*=*=*=*=*=*=*= 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 5:5/23 [5:7104/2] as file "ARTSPEC.DOC". ALL Zone Coordinators should have copies of ARTSPEC.DOC. Please read it. "Fido", "FidoNet" and the dog-with-diskette are U.S. registered trademarks of Tom Jennings, P.O. Box 410923, San Francisco, CA 94141, and are used with permission. "Disagreement is actually necessary, or we'd all have to get in fights or something to amuse ourselves and create the requisite chaos." -Tom Jennings -----------------------------------------------------------------