Articles

• Grunged Echomail Deleted (a Response)
• Letter from a concerned reader?
• The Shrinking Nodelist - What can be done?
• Zone 1 Backbone Service Level Agreement

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

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. Introduction
   1. Purpose of this Document
   2. Definitions
   3. Service Level Agreement
   4. Z1B Relationship to FidoNet
   5. Changes to this Document
2. Z1B Administration
   1. Voting
   2. Selection of Z1B Hubs
   3. Selection of the Z1BC
   4. Administrative Areas
3. Moderators
   1. Moderator Identification
   2. Moderator Responsibilities
   3. Moderator Tools
   4. Echo Addition
   5. Echo Removal
   6. Echo Name Change
4. Standard Operating Procedures
   1. Technical Standards
   2. Gateways
   3. Encrypted Messages
   4. Encoded Files in Echoes
   5. Illegal Activities
   6. Censorship of Messages
   7. Anonymous Remailers
   8. Emergency Plans

(Items noted by the "|" are changes from the previous version.)
(For his HTML version red text denotes changes. [jb])

1. Introduction

   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.

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

   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.

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

   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. Z1B Administration

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

      Tier 3 Z1B Hub selection is left up to the individual nets.

   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.

   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. Moderators

   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.

   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 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. 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 from another system.

   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".

         1. Echomail: To "Z1B", in the Z1BACKBONE echo
         2. Netmail: To "Z1B", at the Z1BC's FidoNet address
         3. 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".

         1. Echomail: To "Z1B", in the Z1BACKBONE echo
         2. Netmail: To "Z1B", at the Z1BC's FidoNet address
         3. 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.

   5. Echo Removal

      The Z1BC removes an echo from Z1B distribution when any of these situations occur:

      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:

         1. Echomail: To "Z1B", in the Z1BACKBONE echo
         2. Netmail: To "Z1B", at the Z1BC's FidoNet address
         3. 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:

         1. To encourage the formation of new echoes, like pruning dead branches off a tree.

         2. 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.

   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 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. Standard Operating Procedures

   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 the Z1B is acceptable.

      A Z1B Hub may choose not to provide services to a node which does not operate in a secure fashion.

   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.

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

   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.

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

   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.

   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 ====