     Volume 8, Number 17                                 29 April 1991
     +---------------------------------------------------------------+
     |                                                  _            |
     |                                                 /  \          |
     |                                                /|oo \         |
     |        - FidoNews -                           (_|  /_)        |
     |                                                _`@/_ \    _   |
     |         FidoNet (r)                           |     | \   \\  |
     |  International BBS Network                    | (*) |  \   )) |
     |         Newsletter               ______       |__U__| /  \//  |
     |                                 / FIDO \       _//|| _\   /   |
     |                                (________)     (_/(_|(____/    |
     |                                                     (jm)      |
     +---------------------------------------------------------------+
     Editor in Chief:                                  Vince Perriello
     Editors Emeritii:                    Thom Henderson,  Dale Lovell
     Chief Procrastinator Emeritus:                       Tom Jennings
     
     Copyright 1991, Fido Software.  All rights reserved.  Duplication
     and/or distribution permitted  for  noncommercial  purposes only.
     For use in other circumstances, please  contact  Fido Software.
     
     FidoNews  is  published  weekly by and for  the  Members  of  the
     FidoNet (r) International Amateur Electronic Mail System.   It is
     a compilation of individual articles contributed by their authors
     or authorized agents of the authors. The contribution of articles
     to this compilation does not diminish the rights of the authors.
     
     You  are  encouraged   to  submit  articles  for  publication  in
     FidoNews.  Article submission standards are contained in the file
     ARTSPEC.DOC, available from node 1:1/1.    1:1/1  is a Continuous
     Mail system, available for network mail 24 hours a day.
     
     Fido and  FidoNet  are  registered  trademarks of Tom Jennings of
     Fido Software, Box  77731,  San  Francisco  CA 94107, USA and are
     used with permission.
     
     Opinions expressed in  FidoNews articles are those of the authors
     and are not necessarily  those of the Editor or of Fido Software.
     Most articles are unsolicited.   Our  policy  is to publish every
     responsible submission received.


                        Table of Contents
     1. EDITORIAL  ................................................  1
        Otto-Pilot  ...............................................  1
     2. ARTICLES  .................................................  2
        2nd Democratic Election in Zone-4  ........................  2
        Looking for (Artificial) Intelligence  ....................  4
        Reply to Snooze 815  ......................................  7
        Your dog walks on water?!?  ............................... 11
        Z1EC Initial Report  ...................................... 19
     3. LATEST VERSIONS  .......................................... 31
        Latest Software Versions  ................................. 31
     4. NOTICES  .................................................. 36
     And more!
     FidoNews 8-17                Page 1                   29 Apr 1991


     =================================================================
                                 EDITORIAL
     =================================================================


     I'm not really here. I'm in Houston.

     If you get to read this, it means that MY version of Honey was
     able to put up with me and with a computing instrument other
     than a Macintosh for long enough to create your newsletter.

     She did it while I was screaming into the phone at her ("no, not
     THAT button! The OTHER button!"), so please be forgiving if the
     result is less than stellar.

     Let me apologize in advance, though, if something you sent me
     didn't get into the newsletter. She's doing a good job, but
     fixing batch files and (more to the point) reformatting stuff
     that MAKENEWS doesn't like is not her cup of tea. It will be
     published next week.

     All my best from (deep in the heart of) Texas,
     Vince


     -----------------------------------------------------------------
     FidoNews 8-17                Page 2                   29 Apr 1991


     =================================================================
                                 ARTICLES
     =================================================================


                     Coordinator Elections in Zone-4
                 Elecciones de Coordinador en la Zona-4
                    Eleicoes de Coordenador na Zona-4

     Next May 12th, Zone-4 Latin America will celebrate its second
     birthday. I think this time is appropriate for me to resign as
     Zone Coordinator and call for new elections to choose my
     successor.

     The process of election of the new Zone-4 Coordinator will be
     identical to the one held in November 9th, 1990 in which I
     was re-elected.

     The procedures defined for the democratic election process are
     the following:

     - All the FidoNet members will be able to present themselves as
     candidates to the zone coordinator position, by sending netmail
     to Elecciones at node 4:4/444 until May 10th.

     - On May 11th, the list of all candidates will be published
     on the official echomail conference LATIN.SYSOP and on May 13th,
     on NotiFido, the official Zone-4 sysops' electronic newsletter.
     From then until the voting closes on May 31st, the candidates
     will be able to debate ideas on the LATIN.SYSOP echo, as well
     as on the other region and local sysops' echomail conferences.

     - From May 11th until May 31st, all the members of FidoNet Zone 4
     will be able to vote for their preferred candidate -voting for
     someone that is not a candidate will void the ballot- for Zone
     Coordinator. They will do so by sending a message to Elecciones
     at node 4:4/444 (region-routing will be enabled to reduce the
     cost of voting), whose subject will be a special "secret
     password" and the text will indicate the sysop's choice. THE
     VOTE IS SECRET, AND ITS CONTAINTS WILL NEVER BE REVEALED. This is
     an example of how a ballot must be issued:

                                               secret password
          From: Jose Corzo Gomez (4:900/789)   |
            To: Elecciones (4:4/444)           |
          Subj: guantelimpio   <---------------|     text
                                                       |
          ZC: Roque Santeiro      <--------------------|

     - The results from the election will be published on June 2nd
     on the official echomail conference LATIN.SYSOP and on June 3rd
     on NotiFido and FidoNews. A comprehensive list with every ballot
     listed, to grant the accurateness of the results, will be posted
     on June 2nd on the echomail conference LATIN.SYSOP. This is
     an example of how a ballot will be published in the comprehensive
     list:
     FidoNews 8-17                Page 3                   29 Apr 1991


      Password            ZC            Status
      ------------------------------------------------
      guantelimpio        R.Santeiro      OK(*)

     (*) Will say "VOID" if the ballot is not correct

     - The candidate with more votes will become the newly elected
     Zone Coordinator and will take over his/her new position as
     arranged with the current ZC.

     Pablo Kleinman
     Latin American FidoNet Coordinator
     Buenos Aires, April 23, 1991


     -----------------------------------------------------------------
     FidoNews 8-17                Page 4                   29 Apr 1991


     Looking for (Artificial) Intelligence

     Bill Keller  1:129/124.0

     I guess I should begin this article by introducing myself
     and stating my reasons for submitting this article.

     My name is Bill Keller and I run a bbs called ShadeTree in
     Pittsburgh, PA 15221 (412-244-9416).  ShadeTree is
     oriented solely towards artificial intelligence (AI).
     Mostly, the people who log on are beginners or amatuers,
     but they are all enthusiasts.

     I originally got into AI by way of a "free" magazine.
     I'm sure you've all received these type of offers, "Try our
     magazine, the first issue for FREE, if you don't like it,
     mark "cancel" on the invoice and send it back, there will
     be no further obligation on your part".  Sometimes, I felt
     almost criminal (notice I said "almost") but it is a good
     way to take a look at a new magazine before deciding to
     subscribe.  Anyway, the magazine ad I answered was one for
     PC AI, one of the two big AI related magazines.  The issue
     I received was one of their first on neural nets.
     Immediately, I was HOOKED!!

     I started to look around for an inexpensive way to get
     started in AI.  What I found was over priced, over
     complicated, over hyped programs.  Knowing the computer
     community, I figured that SOMEWHERE, there had to be either
     shareware or public domain programs available to help me
     get started.  The quest started!

     What I found was more than a little disheartening.  There
     was VERY little of either type of software out there.  Oh,
     I managed to locate a few expert system shells here and
     there, and some other miscellaneous files, but there was no
     CENTRAL place I could go to find the latest release of a
     shareware program or a new public domain program that had
     just been released or that maintained a large library of AI
     oriented programs and files.  It was at that point I
     conceived of ShadeTree.

     I had been using bbs's for several years, not a lot (I knew
     from experience how addicting it can be!) but enough to have
     a very general idea how it worked.  One of the local Pgh
     SysOps helped me get started with OPUS (a GREAT piece of
     software) and to get my mail and echos set up.  At this
     point, I started searching very seriously.

     There's the back ground, now for the reason or more
     correctly, the request.

     FidoNews 8-17                Page 5                   29 Apr 1991


     I am asking all the SysOps and users who read this
     newsletter, to provide me with the following information:

     1.  What is your FIDONet address and any particulars about
         your bbs, max baud rate, phone number, hours of
         operation, city, state and zip code (no addresses unless
         you want to provide it but with just the city and zip
         code, many people will be able to tell how close they
         are to your board), with this info I intend to compile
         and distribute a file containing a list of boards
         carrying the various AI related echos so that people
         can find a bbs close to them
     2.  Do you participate in any other networks and if so,
         which ones and what AI related echos are available on
         that network, for example the RIME network, or RBBS,
         etc
     2.  What FIDONet "backbone" AI related echos are you
         receiving? (The only ones I am aware of are AI,
         NEURAL_NET, ROBOTIX, if you are aware of any others,
         please let me know)
     3.  What "local" AI echos do you have on your board and is
         there a possibility of that echo becoming a "backbone"
         echo or would you consider some alternative method of
         allowing users from all over access to your echo
     4.  What AI related files do you currently have on your
         board, please give the program name, author name,
         version number, size in kb, and a brief description if
         possible, I am interested in both text files, program
         files, descriptive files, tutorial files, data files,
         etc
     5.  Any of the following topics would be considered AI
         (although some by only very loose standards):
         Expert systems / inference engines
         Neural nets / neural modeling
         Problem solving
         Natural language processing
         Machine vision
         Pattern processing
         Decision analysis
         Robotics
         Machine learning / understanding
         Logic and uncertainty / fuzzy logic
         Genetic algorithms
         LISP and all it's dialects
         PROLOG and all it's dialects
         SmallTalk and all it's dialects
         Hypertext
         Speech recognition
         Speech to text translation and vice versa

     This list should cover most of the  major areas of
     interest in AI but if you have a file that you're not sure
     of, better to let me know than to not include it.

     FidoNews 8-17                Page 6                   29 Apr 1991


     What I intend to do is start a consolidated repository of
     AI related materials and keep them as up to date as
     possible.  This can only be accomplished with the help of
     the network and the individual's willingness to contribute
     a little time to initially get the project off the ground.
     Evenutally, I hope to automate the process as much as
     possible (after all, isn't that what computers are for?) and
     use some sort of database to track version numbers and
     releases, etc.

     I can be reached at either my FIDONet address, 1:129/124.0
     or via the U. S. Mail at:

             ShadeTree BBS
             c/o Bill Keller
             417 Peebles Street
             Pittsburgh, PA 15221

     At this time, ShadeTree is only running from 8:30 PM until
     8:30 AM and only at a maximum of 2400 buad.  That is
     another reason to suggest the regular mail as an
     alternative.

     I would like to thank you all, in advance of any assistance
     rendered, for your help and participation in this project.

                                 Bill Keller


     -----------------------------------------------------------------
     FidoNews 8-17                Page 7                   29 Apr 1991


     Garth Kidd
     3:680/828@fidonet
     garth_kidd@f828.n680.z3.fidonet.org


     Ages ago, I posted a few articles about POLICY, WorldPOL, and
     whether Z3 should throw some kind of revolution and crawl out
     from under Z1's wing.

     This is *nothing* to do with them :-)

     Well, ok, it is. It's also rather different. This is partially
     because I'm talking about a few different items. The fact that
     some rather nice people took the time to debate a couple of
     issues with me probably helped, too. Thanks, guys. You know who
     you are.

     I digress.

     ===

     AutoNews sounds interesting, Vince. Make sure you put in
     something that'll flag suspiciously large articles, though. I can
     just imagine some twit sending you 40k of ^g.

     ===

     Bob, I like the idea. The main problem is that your proposal is
     HUGE. It'd be really nice if you trimmed it down to something the
     average human being couls sit down with, read and comprehend
     within an hour or two. [Ideally, we should be able to reduce it
     to "Act Sensibly" :-)]

     I would have tried to make suggestions and comments on your
     proposal, but it was simply too large to deal with. Apologies.

     ===

     Alexander, the main problem with passing the ambiguity buck to
     the ZCs is that it's exactly that -- passing the buck. Why not
     correct the problems once now, rather than have to do it in each
     Zone (or Region, or Net, or...)

     ===

     Mike, just a point:

      > WorldPol would have made it much easier to fix.  WorldPol
      > would have given the *Cs more reason to be responsive to
      > the valid needs of a sysop.

     FidoNews 8-17                Page 8                   29 Apr 1991


     To be a member of the *C structure, you need to have a fair bit
     of time, expertise, and equipment you're willing to donate to the
     cause. Unfortunately, there aren't a huge number of people who
     have all the necessary elements handy. The result is a very small
     number of people to choose from when having an election.

     Now, when your city has an election, there are a huge number of
     people who'd like to be the Mayor, and who have the necessary
     equipment (that is, they're a citizen with spare time). This
     means that you *can* pressure your Mayor with the threat of being
     voted out next time 'round, because there are people available to
     fill their place.

     You can't so easily discard a *C. First, you have to find someone
     with the technical nouse and spare time that's willing to take on
     the job, and that's going to be fairly difficult in a lot of
     places. It seems to me that a lot of *C's are going to be fairly
     safe. Ergo, they're not going to be terribly more responsive.

     ===

     Don, I couldn't agree more. For those who missed what he said,
     here's perhaps the most important bit:

      > In sum, I think that WorldPol could probably be reduced
      > to a third of the current size, and we would end up with
      > a smaller, more effective document.  Take a few moments
      > and look at WorldPol again.  Ask yourself if each section
      > is absolutely necessary to be controlled at the inter-
      > national level?  If not, why include it?

     ===

     Dick, I know the feeling. Something's not working quite right. As
     for the BOMBRUN kludge -- I like it! Take it to NET_DEV and see
     how people react to it. I'd have a bash, but due to a feed
     interruption of a strange nature [Paul, I'll netmail you as soon
     as I've got the time and inclination, but I'll condense: your
     netmail on the matter *NEVER REACHED ME*, reasons unknown :-(] I
     won't be able to.

     Main problem: too much exception handling :-) Also, until people
     catch on to installing session passwords for anyone they connect
     to on a regular basis, there's the potential for people to insert
     fake BOMBRUN messages, which would be a Bad Thing.

     ===

     Finally, Jack. Incidentally, yours was the article that prompted
     me to start this multiple reply in the first place.

     FidoNews 8-17                Page 9                   29 Apr 1991


     Agreed, we need to get some new software up and running, quick.
     Correct me if I'm wrong, but it seems that this won't be able to
     be quickly grafted on at the mail processor level, unfortunately
     -- we'll need a couple of sneaky changes to the mailers
     themselves (domain-style addressing, here we come! :-), and some
     change to BBS software to handle the new-fangled ideas of fully
     moderated conferences [*] and conference hierachies.

     Unfortunately, even if you manage to implement a decent
     replacement [**], you'll still have to get people to switch to it.
     You don't need me to tell you that this isn't going to be the
     easiest thing to accomplish.

      > Trouble is, it seems that all the topics I am
      > interested in fall into one of three categories:  1)
      > There's no echo covering it, 2) There's an echo
      > covering it but it's a dead (or nearly dead) echo,  3)
      > There's an echo covering it but it's so large and has
      > so many off-topic or "useless" messages that I just
      > don't have the time to keep up with it.

     Is there anyone here who *doesn't* have that feeling?

     I like the method the USEnet uses to cope.

     [Warning: this is from what I've seen only. I may have been
     temporarily visually challenged at the time].

     You have the comp.* groups, and various other "official"
     conference trees. To create a new group in here requires a lot of
     discussion and manoeuvering.

     You also have the alt.* tree, in which you create a conference by
     posting a message to it. All the systems who have the alt.* tree
     enabled [***] [****] will get it, until they turn it off. I think
     the software also automatically kills conferences that have been
     dead for a sufficiently long time.

     Just excuse me whilst I catch up on my footnotes.

     ===

     [* Note to people who think that fully-moderated conferences mean
     double the throughput: this is the case only if you're directly
     between the moderator and the rest of the world, and the
     moderator isn't all that choosy. For people at the far reaches,
     the difference would be negligible, and probably advantageous.]

     [** Even this is going to be near impossible. I was one of the
     participants in a rather active discussion in NET_DEV about
     potential Fido/3 technology. Unfortunately, I've suffered from a
     "minor" feed cut. Ironically, one of the contributing factors
     (apart from a rather badly timed and \extremely\ badly placed
     argument I had with someone) was that transmission failures meant
     that netmail and echomail warnings on the matter simply didn't
     make it to my system.]
     FidoNews 8-17                Page 10                  29 Apr 1991


     [*** Apart, that is, from the people who've disabled the part of
     the tree you're in. Example: to create alt.swedish would be fine
     as long as people didn't have it already in their kill file. Now,
     creating alt.swedish.chef would be ok, but systems who'd already
     turned off alt.swedish would never see the new subconference.
     swedish.chef.bork.bork.bork would be for the true diehards :-) Oh
     yeah; some people save lots of time and just kill alt.*]

     [*** Apologies for all of these footnotes. I can't seem to get my
     text in order these days.]

     ===

      > But will our software authors ever be able to agree on
      > any new standard that might be proposed along these
      > lines?

     I think not. At least, not in NET_DEV, from what I'd seen just
     before I left. At the time the feed bottomed out, people were
     still debating whether a timestamp should be stored as seconds
     since 1970, a 32-bit bitmapped struct, plaintext, ISO, and if
     anything remotely binary, which wordsex to use :-(

     There is one way in which I think it could all be accomplished.
     Unfortunately, it doesn't leave much of Fido standing :-(. Since
     a change would be extremely difficult to orchestrate piecemeal,
     it seems vaguely reasonable to start a new network with the new
     technology and let it gradually "eat" FidoNet, gating the major
     conferences and so on. Can anyone think of a better method?
     Please?

     That'll do for today. Have a nice day, all.


     gk

     -----------------------------------------------------------------
     FidoNews 8-17                Page 11                  29 Apr 1991


     Jack Decker
     1:154/8 Fidonet
                       YOUR DOG WALKS ON WATER?!?

     Well, last week I tried out the AutoNews program that Vince
     uses, by sending an article via netmail.  It worked, but it
     threw out the blank spaces that I had left between paragraphs.

     I think that may have happened because my message editor only
     put a single <CR> after each line, no <LF>'s anywhere, so this
     week I'll try manually creating the message to make sure that
     each line terminates with a CR/LF and see if that helps.  In
     the meantime, Vince, you may want to see if AutoNews recognizes
     two <CR>'s in a row as a blank line.  However, for a first
     attempt, the program worked admirably. [I spoke to the author
     and he thanks you, both for your kind comments and for your
     assistance in getting everything straightened out -- Vince]

     Besides, I did want to make one little comment on Vince's
     Editorial in FidoNews 8-16.  In Vince's reply to Pablo
     Kleinman, we see the following exchange:

     [Begin quote:]

     > I want to believe that Jack Decker's last article is really
     > pessimistic and not the harsh reality of our network.

     It's sort of redundant to call Jack a pessimist.

     Can you see this?

     Jack goes hunting with you. You shoot a duck. Your dog goes
     after the duck. When it reaches the water, your dog walks on
     top of the water, never even leaving a ripple. The dog gets the
     duck and brings it back to you. Jack says nothing. This happens
     twice more. You finally ask Jack if he has noticed anything
     unusual.  Jack says, "Yeah. Your dog can't swim."

     [End quote]

     What strikes me as amusing about this is that the other day I
     happened to have the radio on when Rush Limbaugh was on, and he
     made a comment to the effect that when liberals run out of
     substance, they start in with personal attacks (for those
     outside of the U.S.A., Rush Limbaugh is a conservative radio
     talk show host that is carried on well over 300 radio stations
     in the U.S.  for three hours a day, and who is most noted for
     having an ego about the size of the planet Jupiter).  Anyway, I
     thinks to myself, that sounds a lot like Fidonet...  when they
     can't assail the logic of what you have to say, they start in
     with the personal smears.

     FidoNews 8-17                Page 12                  29 Apr 1991


     Actually, I realize that my messages may, if taken out of
     context, sound a bit pessimistic.  What I see is that we have a
     potentially wonderful communications medium here... one that
     allows people from all corners of the earth to converse with
     each other with reasonable speed and at fairly low cost.  Yet
     there are problems and in some cases they need to be quantified
     and solutions need to be found.

     Consider what would have happened if the Ford Motor Company,
     after having come out with the Model "T" had said "Now, you
     folks have something that is better than the horse, and you can
     afford to buy it, so you should be grateful and not ask for
     anything more."  Actually, from what I've read, that was
     EXACTLY the attitude of some in that company (I believe it was
     Henry Ford who said "they can have any color they want, as long
     as it's black!").  Would anyone doubt that we are better off
     now because some folks looked at the Model "T" and dared to say
     "it's wonderful, but it can be improved upon"?

     So it is with Fidonet... it is wonderful, but it can be
     improved upon.

     I have felt, and expressed on many occasions, that there are
     about four basic things wrong with Fidonet:

     First, it is too politically motivated.  What folks like Vince
     and some others seem to have a hard time grasping is that there
     ARE people in the world who seek to acquire any sort of power
     over others that they can get, and since there are only so many
     countries in the world, not all of them can aspire to be world
     dictators.  Some will try and manipulate their way to the top
     of the office political structure at their place of employment,
     others will try and rise to the top of a local service club,
     charitable organization, or political group, and still others
     will try to cling to the top spot of a hobbyist group.  Some of
     these folks get into Fidonet and do manage to get a *C spot and
     once they get there, they will oppose any policy change that
     might lessen their supposed power.  I think those who have
     trouble understanding this have simply never been in an
     organization where one person has clawed their way to the top
     and then manipulated people like crazy to keep the top spot.  I
     have, and I can tell you that it's no fun to see an
     organization disintegrate because the top person is driving
     everyone away.

     Second, it makes a god (small "g") out of geography.  This is
     out and out idiocy, when referring to an electronic network
     (no, Vince, I can't vote in Duluth when I live in Sault Ste.
     Marie... but Fidonet isn't providing my water, fixing my
     streets, or regulating the zoning around my home.  You can't
     compare physical structures to a structure that can quite
     reasonably exist in a configuration that pays little regard to
     geography).  (Side note to Pablo... no, I truly believe that
     MOST common sysops in Zone 1 DON'T want geographic
     restrictions... and that is EXACTLY why a few are so opposed to
     WorldPol, because they will lose their enforced power base.
     FidoNews 8-17                Page 13                  29 Apr 1991


     They know that if common sysops are given a vote on a Zone-wide
     policy, they'll never vote for one that contains geographic
     restrictions, and that scares a few of them to death).

     Third, it is getting technically stagnant...  Fidonet is SO
     large that we find that we're unable to refine the system to
     get rid of SEENBY's in messages, have true 5D addressing
     instead of endless kludge lines, have truly moderated
     conferences so that the signal-to-noise ratio of conferences
     can be improved, communicate with the ubiquitous FAX machines
     around us, enter non-text data in messages, and any of a
     hundred other improvements that WILL come in time.  Just as the
     Model "T" owner might never have dreamed of having air
     conditioning, a stereo audio system and cruise control, so we
     can't imagine what future online communicators will be able to
     do.  The question is, will these advances come from within
     Fidonet, or will those who want something better be forced into
     other networks?  And if the latter happens, will those in
     Fidonet then stubbornly snub them and ignore what they're
     accomplishing?

     Fourth, it is intolerant of certain political viewpoints.
     Vince at one point raised the specter of a "whites only" net
     run by the KKK.  Well, far be it from me to defend that group,
     since I find their ideas repugnant, but since you're so
     concerned about law, Vince, you ought to ask your lawyer
     friends about the "slippery slope" principle.  Basically, it
     says that if you can deny any one group the right to be heard
     (or, in this case, to freely associate) then you have set up a
     principle that can be used against ANY group.  So suppose you
     write something into Policy that says that special interest
     nets cannot be formed... not only are you attempting to
     unreasonably limit freedom of association for no real good
     reason, but any such policy could be used against groups you
     might happen to AGREE with.  Not only that, but you haven't
     really stopped the subversive groups from operating - it is
     very easy to set up and operate a private net using Fidonet
     technology, that is totally invisible to Fidonet as a whole -
     so now you've driven them underground where their activities
     can't be monitored, and where they're less likely to be
     influenced by those in the larger net that might be able to
     explain to them and convince them of the error of their ways.
     In the meantime, is it right to let our fear of extremist
     groups cause us to set up a mechanism whereby those who hold
     political viewpoints we find simply disagreeable may be
     harassed or excluded?

     I'm hoping for better things from Fidonet... but it's not going
     to happen as long as we operate as though all that HAS been
     achieved is all that CAN be achieved.  We've come through the
     Model "T" stage, but there are a lot of improvements that can
     be made, both in the technology and the political structure of
     Fidonet (and hopefully we can avoid the tailfins!).

     FidoNews 8-17                Page 14                  29 Apr 1991


     *****

     A couple of other notes only semi-related to the above:  First,
     Pablo mentioned Jason Steck, who was at one point working on
     another Policy document.  My impression is that Jason has
     decided that his time would be better spent working in
     MetroNet, an alternative Fidonet-technology network that's a
     bit unique in some ways.  For example, Jason tells me that they
     have their own UseNet-MetroNet gateway and are the only
     Fidonet-technology network other than Fidonet itself to have a
     registered domain in the Internet (I hope I'm stating this
     correctly, I'm repeating this from my memory of a phone
     conversation).  Also, I gather that the MetroNet folks are
     working on a practical implementation of a new packet type that
     will be backward compatible with existing Fidonet technology,
     but that will offer several of the innovations that have been
     suggested in various forums from time to time.  In any event,
     if you are interested in furthering the technology and are
     running into roadblocks (political or otherwise) in Fidonet,
     you might contact Jason Steck at Fidonet 1:104/424 and see what
     they're up to (however, if you're the typical NET_DEV type that
     like to argue about formats, structures, etc. ad nauseum but
     never gets around to writing a line of code, don't bother... I
     don't think they either need or want those types around!).
     Second, I have to wonder why some of the sysops who believe in
     carrying political discussions that cover all sides of the
     political spectrum haven't asked for some political echoes to
     balance out some of the echoes that are already carried.

     Please consider that there are plenty of "issues oriented"
     echoes such as ABORTION, ANIMAL_RIGHTS, BEYOND_WAR, ECOLOGY,
     ECONET, ENVIRO, ENVIRON, FEMINISM, GAYLINK, GAYNEWS, ICGAL,
     INDIAN_AFFAIRS ... and on and on, and if you understand the
     difference between the political right and the political left,
     you can easily see that Fidonet is pretty one sided (not
     necessarily from the TITLES of some of the echoes, but from
     their content).  Now maybe this is intentional, but I certainly
     hope not.  So I'd like to suggest that maybe we should think
     about having some echoes that might bring more of a political
     balance to Fidonet.  Here are some ideas I've had, you might
     think of more:

     EDU_CHOICE - For those who support the idea of parental choice
     in education, and would like to discuss the reasons for it and
     the ways in which it could be implemented.

     PEOPLE_FIRST  - An echo to keep track of and expose the
     activities and motives of some of the fringe groups that
     believe that humanity is a cancer on the planet (such as the
     groups that believe that animal research is never justified,
     even if it means we never find a cure for AIDS, etc.).  In
     other words, to count the cost to people and society if some of
     the goals of the far left groups are achieved, without
     necessarily having to rely upon their statistics.

     FidoNews 8-17                Page 15                  29 Apr 1991


     DITTOS - an echo for listeners and fans of the Rush Limbaugh
     radio talk show, for further discussion of issues that have
     been raised on that program.  Those who've heard the program
     will recognize the significance of the tag.  If we can have
     echoes for fans of "Star Trek", why not one for fans of a
     popular talk show host?  (by the way, in case you're wondering,
     no I do NOT agree with everything he says... but it's certainly
     an INTERESTING show to listen to, when I get the chance).

     My point is that if we are going to carry issue-oriented
     political echoes, let's have them cover the whole political
     spectrum and not be quite so one-sided.  There ARE two (or
     more) sides to most issues, after all.

     Well, that's enough for one week.  Let's see if Autonews eats
     the blank lines in this article! [It did. I did a quick once-over
     to put at least some of them back -- Vince]

     --- via AutoNews 0.1

     -----------------------------------------------------------------
     FidoNews 8-17                Page 16                  29 Apr 1991


               "Ramblings of a Dictatorial Megalomaniac"

               or "It's about time for Policy6, Godammit"

         Luke Kolin, NC250
         1:250/714@fidonet

     "I thought it sucked, but Wayne here thought it sucked donkeys."
       -- Dana Carvey, playing Garth on SNL's "Wayne's World"

      Garth may be talking about movie reviews, but perhaps Worldpol
     is also appropriate in this case. As a Zone 1 *C, I've been quite
     offended by the rhetoric that's been floating around regarding
     WorldPol, and I feel that it's time that I speak my two bits'
     worth.

      Before I begin, I want to state for the record that regardless
     of wether WorldPol passes or fails, we will be planting the seeds
     for future discontent within FidoNet. If it fails, it will be
     widely perceived as yet another example of Zone 1 imposing its
     will upon FidoNet. If it passes, it will be further proof that
     the largest group of FidoNet sysops have been effectively disen-
     franchised by a gerrymandered voting system. Net 250 is larger
     than quite a few regions, but while they may have 2 to 4 votes,
     we only have one. Is that fair?

      So I think it's time to look beyond WorldPol. Because if we look
     upon this vote as the be-all and end-all, there will be a lot of
     po'd people in FidoNet. We got that with Policy4, and what came
     out of that was Policy5, aka WorldPol. Documents created out of
     resentment and frustration are inherently flawed, and unless we
     look beyond WorldPol NOW, Policy6 will end up the same way.

      For the record, I voted against WorldPol. I don't support making
     a completely new policy. I believe that Policy4 can do the job,
     with ammendments. Why start from scratch when we have the cumula-
     tive efforts of many man-years lying around, only to be modified
     as needed? Therefore, I support a Policy6 based on Policy4, with
     the following fundamental changes. Call them a Sysop's Bill of
     Rights.

      o DEMOCRATIC ELECTION OF THE *C STRUCTURE. FidoNet's a hobby. Or
     a club. And it only stands to reason that FidoNet sysops should
     be able to choose their representatives. Therefore, Policy4 should
     be ammended to ensure that NCs and RCs are elected by a vote of
     all sysops within their respective Net/Region. ZCs will be elected
     by a vote of all *Cs within their Zone.

      o GEOGRAPHICAL NETWORK BOUNDARIES. Within Region 12, we have been
     attempting to institute strict geographic boundaries for networks.
     For people to say in FidoNews that geographic boundaries force
     people to deal with bad *Cs is a blatant insult to the efforts of
     the NCs and RCs of Region 12 since 1988. Allowing nodes to join
     any network they wish only encourages the rise of cliques, and
     networks based on politics and infighting. It encourages NCs to
     discriminate on who they wish to accept into "their" Nets. If we
     FidoNews 8-17                Page 17                  29 Apr 1991


     make georgraphy the sole criterion for network membership, we
     make sure that FidoNet is accessible to all. Equally. If an NC
     cannot live with that, he should be axed immediately.

      o FIDONET IS FREE. Several previous articles in FidoNews have
     mentioned several networks who charge an admissions fee to join.
     No node should be forced to pay to join or remain in FidoNet, nor
     should they be forced to pay for any mandatory echo conferences.
     We are an amatuer network, accessible to all at least at a basic
     level. That should be a fundamental right.

      o A NEW AMMENDING FORMULA. There's a problem with the way FidoNet
     is structured right now. Zone 1 has a grand total of ten regions
     and six thousand people, while Zones 4 and 5 have regions that
     are hard pressed to qualify as networks up here. So why should
     they have the same voting rights? I think it's time for an
     ammending formula that protects both minorities in FidoNet: a
     minority of sysops outside Zone 1, and a minority of *C beings
     inside Zone 1.
      Let's keep the method of putting ammendments up for vote the
     same. A lot of RCs are good people who'll support a vote even
     if they are going to vote NO. However, when it comes down to the
     actual vote, why don't we say that to pass, a policy must meet
     with the approval of a majority of *Cs in each zone. To boot,
     the NCs' votes must represent a majority of sysops in that zone.
     That way, policies cannot be passed by the simple virtue that
     one zone has a plethora of tiny zones.

      So let's drop WorldPol. It reeks of an atitude saying, "Let's
     make sure Zone 1 never screws us over again." Let's go back to
     the time-honored method of taking what we have, and improving
     it, to make something even better.

      I also support the idea of condensing policy. For example, in
     Net 250 I have published a little 2K guide to FidoNet. I don't
     see why we should force all sysops to read the entire policy
     document, when most of the time a little guide will do. To this
     end, I propose two versions of Policy6. The first would be a
     very short explanation of FidoNet to the new sysop, and the
     second could be as large as you want. Since most sysops will
     never read the second, it can be *C-oriented, taking into
     account all facets of FidoNet. Rather than taking about demo-
     cratic elections according to "western standards", let's write
     a full elections policy. We have. Rather than making provisions
     for zonal, regional, or network policies, let's just make one
     broad-based one. If you follow the basic principles in it, and
     the few specifics (like elections), the other stuff is up to
     you.

      WorldPol must fail. Much bitterness will be aroused pass or
     fail, but I'd rather be bitter that a flawed document did not
     pass. Let's start with Policy4 again, change it to reflect the
     new FidoNet, and live with that.

     FidoNews 8-17                Page 18                  29 Apr 1991


     -----------------------------------------------------------------
     FidoNews 8-17                Page 19                  29 Apr 1991


     Tony Davis
     Z1EC 1:1/200

     After the first month of performing the duties of Zone One
     Echomail Coordinator, I felt some information on how the system
     is progressing was in order.

     The first month has been extremely interesting. In the first 30
     days, I have received in excess of 200 netmail messages
     concerning policies, procedures, complaints, suggestions, adding
     an echo to the backbone, removing an echo to the backbone,
     moderators requesting links be cut, users requesting moderators
     be replaced, etc. Very few (less then 5) actually concerned with
     coordination of traffic flow.

     One fact became the extremely clear.  That was that in the
     absence of a recognized, approved echo policy and no other
     documentation; that I would be subject to making many judgement
     calls. The only mathematical certainty is that if many judgement
     calls are made, some will be incorrect.  In an effort to remove
     myself from the position of judge, jury, and executioner that
     the numerous requests asked me to be and place me in the
     position of administrator that I was elected to, I contacted all
     the RECs and asked their guidance of exactly how they wanted me
     to handle the position.

     The general opinion that came from these discussions was that
     the *EC structure did not have the right to dictate a mandatory
     Echo Policy.  It also became obvious that even if we could not
     set a zone wide policy, that a document that described the
     operation of the backbone, and explained to the general sysop
     exactly what they could expect from the backbone was necessary.
     A set of backbone procedures was written, and put up to a vote
     of all RECs. The procedure were adopted by an absolute majority
     of current RECs.

     The document prepared is not intended to be a general echo
     policy, it is designed as an informational document to explain
     the self-imposed rules the Zone One Backbone will operate under.

     If at any time, the net does adopt a general echo policy, the
     net approved policy will either replace this Backbone Operation
     Procedure document or changes in the document will be made for
     it to comply with the general echomail policy.

     The document lays out specific requirements that an echo must
     meet in order for it to be distributed by the backbone, on the
     balance side, it also lays out exactly how to remove the echo
     from any restrictions the moderator of an echo feels the
     backbone places on him (or her).

     FidoNews 8-17                Page 20                  29 Apr 1991


     Any one that disagrees with any segment of that document, and
     would like to see a change, deletion, or addition, please
     contact your REC.  The document itself was designed to be a
     "living" document, and changes may be made to it quickly and
     easily. The procedures to initiate changes are described in the
     document itself.

     One side note: The document was not authored by the ZEC, it is a
     collection of parts supplied by different RECs. As ZEC, I
     accepted the mandate of the RECs to implement the document.

     Respectfully,
     Tony Davis Z1EC



               ZONE ONE BACKBONE OPERATION PROCEDURES


     Revision: 1.01                    Effective Date: May 1, 1991


     PROLOGUE

     This document sets forth procedures followed by the Zone One
     Backbone Echomail System.


     If any item in this document are in conflict with any existing
     or subsequent General Fidonet Policy, then General Fidonet
     Policy will be in effect.

     This document addresses echomail at the zone level.  It is not a
     General Echomail Policy.  This document makes no attempt to
     address any issues below the "Backbone Level".


     I.  HISTORY

     Echomail consists of the sharing of message bases or conferences
     between various independent network addresses.  The echomail
     concept started with a series of programs by Jeff Rush.  Since
     the original implementation, many authors have written programs
     improving on the original idea.  In spite of worries that the
     flow of echomail would increase netmail traffic to the point
     that the network would collapse under its own weight, echomail
     has been a success.

     To simplify the distribution of echomail at the zone level, the
     Backbone was formed.  As a result of the growth of Fidonet and
     the increase in the volume of echomail, it has become necessary
     to set forth operational procedures to allow the general Fidonet
     sysop to know what services he can expect from the Backbone.

     FidoNews 8-17                Page 21                  29 Apr 1991


     II.  DEFINITIONS

     1.  GENERAL FIDONET POLICY:  The document which governs Fidonet
     as adopted by Fidonet.  The document as of this writing is
     Policy 4 and is subject to change.

     2.  NODE:  A Fidonet member, as per General Fidonet Policy.

     3.  ECHOMAIL:  A form of mail in which message bases are shared
     between independent systems with unique Net/Node addresses.

     4.  ECHOMAIL CONFERENCES:  An echomail conference is a message
     base or forum, distributed under a specified echomail conference
     name, dealing with a defined area of interest.  Echomail
     conferences are hereafter referred to simply as conferences.
     Examples include COMM, an inter-zone telecommunications
     conference, and POLITICS, a zone level political conference.

     5.  ZONE ECHOMAIL COORDINATOR:  This individual is responsible
     for coordination of echomail at the zone level.  The Zone
     Echomail Coordinator is hereafter referred to simply as the ZEC.

     6.  REGION ECHOMAIL COORDINATOR:  This individual is responsible
     for coordination of echomail at the region level.  The Region
     Echomail Coordinator is hereafter referred to simply as the REC.

     7.  NET ECHOMAIL COORDINATOR:  This individual is responsible
     for coordination of echomail at the net level.  The Net Echomail
     Coordinator is hereafter referred to simply as the NEC.

     8.  ECHOMAIL HUBS:  These are nodes who distribute echomail.
     The Echomail Hubs are hereafter referred to simply as Hubs.  The
     Zone Hubs distribute echomail at the zone level.  The Region
     Hubs distribute echomail at the region level.  The Net Hubs
     distribute echomail at the net level.

     9.  CONFERENCE MODERATORS:  These individuals preside over
     conferences.  Conference Moderators are hereafter referred to
     simply as Moderators.

     10.  RESTRICTED DISTRIBUTION CONFERENCE:  A restricted
     distribution conference is one which is restricted only to
     eligible recipients.  Examples include MODERATOR, a pre-register
     conference for Moderators, and MEADOW, a conference for Opus
     Sysops.

     11.  ZONE ONE ECHOMAIL BACKBONE:  The Zone One Echomail Backbone
     consists of Zone Hubs (commonly referred to as "Stars") and the
     Regional Hubs (who directly connect to the "Stars").  The Zone
     One Echomail Backbone is hereafter referred to simply as the
     Backbone.

     FidoNews 8-17                Page 22                  29 Apr 1991


     12.  ZONE ONE ECHOMAIL CONFERENCE LIST:  The Zone One Echomail
     Conference List identifies the registered zone level
     conferences.  The Zone One Echomail Conference List is hereafter
     referred to simply as the Echolist.

     13.  ZONE ONE ECHOMAIL CONFERENCE LIST COORDINATOR:  This
     individual is responsible for the Zone One Echomail Conference
     List.  The Zone One Echomail Conference List Coordinator is
     hereafter referred to simply as the Zone Echolist Coordinator.

     14.  ECHOMAIL GATEWAYS:  These are nodes whose systems are used
     to exchange mail with other groups.  The term Echomail Gateway,
     as used hereafter, shall include all forms of gating, including,
     but not limited to, zone-gating, inter-network gating, and
     domain-gating.

     15. VOTE:  Any vote shall be carried out in a fair and decent
     manner.  A good faith attempt shall be made to make all eligible
     voters aware that a vote is about to occur and to make available
     all necessary information.  At a minimum, this notice shall be
     posted in the REC conference 7 days prior to the start of the
     voting period.  The voting period shall be 7 days.

     16.  ABSOLUTE MAJORITY:  The term absolute majority means more
     than 50 percent of those eligible to vote.


     III.  DUTIES OF ZONE ECHOMAIL COORDINATOR, ZONE HUBS, ZONE
     ECHOLIST COORDINATOR, REGIONAL COORDINATORS AND MODERATORS

     1.  DUTIES OF ZONE ECHOMAIL COORDINATOR:  The ZEC shall
     coordinate echomail distribution at the zone level.  This
     includes coordinating the transmission and routing of echomail
     so that it is done in a manner so as to avoid creation of
     duplicate messages within a conference.

     The ZEC shall make available, to any region, any conference
     which that region is eligible to receive.  If for any reason the
     ZEC does not have access via recognized distribution channels to
     a specific conference, he can not be expected to provide it.

     An exception is that the ZEC is not required to make available
     any conference which routinely contains messages which are
     encrypted or illegal.

     Nothing in this provision requires that a ZEC or Zone Hub must
     import any conference to the extent of adverse economic impact.

     The ZEC shall recognize conferences at the zone level.  The ZEC
     shall maintain a list of available conferences at the zone level
     as well as the requirements of each conference as supplied by
     the Moderator (Echolist).

     FidoNews 8-17                Page 23                  29 Apr 1991


     The ZEC shall appoint Zone Hubs (Stars) to distribute echomail
     at the zone level.  The ZEC may also serve as a Zone Hub, but is
     not required to do so.

     The ZEC shall make available a minimum of one connection to each
     "Star", to each region.  Each Region is not required to use all
     available connections, but it is the ZEC's responsibility to
     insure that the connections are available.

     2.  DUTIES OF ZONE HUBS:  All systems designated as Zone Hubs
     (Stars) by the ZEC will be required to allow a single direct
     connection from each region as requested by the REC of each
     region.  Zone Hubs may act as Regional Hubs and/or File
     Distribution systems only if such actions do not interfere with
     the primary duties of Zone Echomail Distribution.  Zone Hubs
     will make any conference available that has been designated a
     "Backbone Conference" by the ZEC.  Zone Hubs will distribute a
     text file named "FIDONET.NA" that is a list of all Conferences
     available from the Zone Hubs.

     3.  DUTIES OF ZONE ECHOLIST COORDINATOR:  The Zone Echolist
     Coordinator shall compile and make available the Echolist.  This
     is a registry of zone level and inter-zone conferences, updated
     monthly, and optionally, conferences at various other levels.

     The content and format of the Echolist will be at the sole
     discretion of the Zone Echolist Coordinator, except that it
     shall include the conference name, the Moderator's name, a
     netmail address listed in a publicly available nodelist of any
     network where the Moderator may be reached, a general
     description of the conference topic, eligibility requirements
     for restricted conferences, network of origin for conferences
     which originate outside of Fidonet, distribution plan if other
     than via the Backbone, and rules for each conference.

     4.  DUTIES OF REGIONAL ECHOMAIL COORDINATORS:  This Document
     details the REC's duties in relationship to the Backbone, only.
     The REC shall coordinate echomail distribution at the regional
     level.  This includes coordinating the transmission and routing
     of echomail so that it is done in a manner so as to avoid
     creation of duplicate messages within a conference.

     The REC shall make available, to any net, any conference which
     that net is eligible to receive.  If for any reason the REC does
     not have access via recognized distribution channels to a
     specific conference, he can not be expected to provide it.

     An exception is that the REC is not required to make available
     any conference which routinely contains messages which are
     encrypted or illegal.

     FidoNews 8-17                Page 24                  29 Apr 1991


     Nothing in this provision requires that a REC or Regional Hub
     must import any conference to the extent of adverse economic
     impact.

     The REC shall appoint Regional Hubs to distribute echomail at
     the regional level.  The REC may also serve as a Regional Hub,
     but is not required to do so.  The REC designates the systems
     that will have the direct connections to the Zone Hubs.  In the
     event the REC feels his region needs more than one connection
     per Zone Hub, he may request an additional connection.  Any such
     connection will be granted on a space available basis.  Each
     such request will be looked at on a case-by-case basis.

     5.  DUTIES OF MODERATORS:  Moderators shall make, in good faith,
     every reasonable effort to insure that their conferences do not
     distribute or promote illegal activities or information as
     defined in Section V, Paragraph 2.

     Moderators shall publish the conference rules in their
     conferences at least once a month.

     Moderators shall be responsible for seeing that messages
     contained in their conferences correspond to the conference's
     theme.

     Moderators shall not fail to perform their duties for a period
     of more than 10 days without failing to designate proxies.

     Moderators are encouraged to appoint Co-Moderators to assist
     them in their duties.  If the Moderator is not a member of
     Fidonet, he must list an address in a publicly available
     nodelist of any network, that he may be contacted if the need
     arises.

     Moderators shall report any violations of these procedures to
     the proper Echomail Coordinators and lodge any appropriate
     policy complaints as provided for in General Fidonet Policy.

     If a Moderator believes that a Node is violating a conference
     rule, he may authorize the feed to that Node be severed.  This
     authorization shall be made in direct written form (netmail), to
     the Hub feeding the offending Node, with a copy to the offending
     Node.


     IV.  SELECTION OF ZONE ECHOMAIL COORDINATOR, ZONE ECHOLIST
     COORDINATOR AND MODERATORS

     1.  GRANDFATHER CLAUSE:  The ZEC, Zone Echolist Coordinator and
     Moderators currently holding these positions as of the date of
     acceptance of this document shall continue to serve in said
     capacity.

     FidoNews 8-17                Page 25                  29 Apr 1991


     For the purpose of calculating the term of office, such term
     will be deemed to have started on the date that this document
     goes into effect.

     2.  SELECTION OF THE ZONE ECHOMAIL COORDINATOR:  The ZEC shall
     serve for a term of 1 year.  He shall be elected as follows:

         A) Upon resignation or replacement of the existing ZEC, the
         Zone Coordinator (ZC) shall oversee the election of the new
         ZEC.

         B) After the nominees are selected, an election shall be
         held.  The ZEC will be elected by a absolute majority of the
         RECs.

     The current ZEC can be identified from the 1/200 listing in the
     Nodelist.

     3.  REMOVAL OF THE ZEC:  The ZEC may be removed from his
     position by a absolute majority of the RECs.  The ZC will
     oversee the recall election in the same manner as prescribed for
     electing the ZEC.

     The ZEC may only be subject to recall for failure to properly
     carry out his duties described above, or if he is no longer a
     member of Fidonet.  A promise of "free" echomail delivery from
     another source is not considered an acceptable reason for
     recall.

     A ZEC may be removed by the ZC for continued violations of
     policy or for gross misconduct.

     4.  SELECTION OF THE ZONE ECHOLIST COORDINATOR:  The ZEC shall
     appoint the Zone Echolist Coordinator.

     The current Zone Echolist Coordinator can be identified from the
     1/201 listing in the Nodelist.

     5.  SELECTION OF A MODERATOR:  A Moderator shall be selected as
     follows:

         A) Upon formation of a conference, the person who forms the
         conference is the Moderator.

         B) Upon resignation or replacement of an existing Moderator,
         the conference's rules shall define how the new Moderator is
         selected.

     A Moderator need not be either a sysop, or a member of Fidonet.
     A Moderator must have an netmail address in a publicly available
     nodelist where netmail concerning the conference may be sent.

     FidoNews 8-17                Page 26                  29 Apr 1991


     V.  STATEMENT OF POLICIES

     1.  BASIC ECHOMAIL POLICY:  The basic policy of echomail is to
     promote communication in conferences in a lawful, friendly
     manner consistent with the general principles of Fidonet.

     2.  PROHIBITION ON ILLEGAL ACTIVITIES:  Knowingly distributing,
     or allowing to be entered into conferences, any messages
     containing or promoting illegal activities or information, is a
     serious violation of this document.  As used in this paragraph,
     "illegal activities" includes activities which are a violation
     of civil law as well as activities which would result in
     criminal prosecution.

     3.  CENSORSHIP:  Removing a message from a conference, or
     altering its contents, in the passing or distribution of
     echomail, is considered a serious violation of this document.

     An exception to this provision is the deletion of messages, by
     any Node, which may lead to legal action against that Node.
     Textual changes to such messages are not allowed.

     An additional exception to this provision is the deletion of
     messages, by any Node, which do not meet the echomail message
     standards in Section V, Paragraph 13.  Textual changes to such
     messages are not allowed.

     Under no circumstances shall echomail be modified in any manner
     which could potentially cause duplicates.

     4.  COUNTERFEIT MESSAGES:  Entering or knowingly distributing
     counterfeit messages is a serious violation of this document.  A
     counterfeit message is defined as any message entered using
     another person's name, handle or Node address with the intent of
     deceiving others about the true author of the message.  No
     handles shall be used to enter messages to knowingly provoke,
     inflame, or upset participants in a conference with the purpose
     of deceiving others about the true identity of the author.

     5.  CHARGING FOR DISTRIBUTION:  Any entity which makes a profit
     from the passing or distribution of echomail shall be deemed to
     be excessively annoying and in violation of General Fidonet
     Policy.  Profit is defined as the charging for echomail
     distribution in excess of the actual cost to obtain and
     distribute the echomail over a sustained period.  The cost of
     the equipment used to obtain and distribute echomail may only be
     recovered on a strictly voluntary basis.  Nodes who charge users
     for access to their BBSs shall not be in violation of this
     paragraph.

     6.  RESTRICTED DISTRIBUTION CONFERENCES:  Participating Nodes
     shall honor and support the restrictions placed upon restricted
     distribution conferences.  Violation of this restriction by
     individual Nodes is a violation of this document and shall
     result in suspension of that Node from the violated echo in
     accordance with Section III.
     FidoNews 8-17                Page 27                  29 Apr 1991


     A violation of the restrictions placed on a restricted
     distribution conference will be a violation of this document
     only if the Moderator has posted the restrictions governing the
     conference both in the conference and in the Echolist.

     7.  PATHLINE OPTION:  The PATHline (as defined in FTS-0004), is
     recommended for all Nodes, but is required for any node directly
     connected to a Zone Hub (Star).

     8.  SEEN-BY LINE:  Under the current technology and topology
     (the routing structure of echomail), SEEN-BY lines play an
     important part in reducing duplicate messages.  Tiny SEEN-BYs
     will not be allowed until the ZEC feels that the topology allows
     their use.  The stripping of SEEN-BYs (except by Echomail
     Gateways) is not allowed unless approved by the ZEC.  Echomail
     Gateways shall strip the SEEN-BYs of the exporting group to
     reduce addressing conflicts.

     9.  ECHOMAIL SOFTWARE:  using echomail software which does not
     conform to the minimum acceptable standards as defined by the
     Fidonet Technical Standards Committee (FTSC), and by this
     Section, is a violation of this document.

     10.  INTER-NETWORK CONFERENCES:  It is the general policy of
     Fidonet to encourage the development of Inter-Network
     Conferences.  Inter-Network Conferences shall conform to General
     Fidonet Policy, as well as the provisions of this document, in
     addition to any foreign network's provisions.

     It shall be the duty of those providing the Inter-Network
     Conference links to remove foreign network distribution
     identifiers which will adversely effect the distribution of the
     conference while in Fidonet.  The Inter-Network Conference links
     maintained in Fidonet shall be operated such that they do not
     interfere with the foreign network's distribution of echomail.

     Conferences which originate outside of Fidonet must be
     designated as such in the Echolist.

     Echomail Gateways must be able to pass netmail through the
     Gateway into the other network, unless it is technically
     impossible to do so.

     12.  ADDING OR REMOVING CONFERENCES FROM THE BACKBONE:  A
     conference may be added to the Backbone only at the request of
     the Moderator.  A conference must have a Moderator, be listed in
     the Echolist, and its addition requested by two or more RECs,
     before it is added to the Backbone by the ZEC.

     The Moderator may, at his discretion, request that his
     conference be removed from the Backbone.  The ZEC shall honor
     such requests.

     FidoNews 8-17                Page 28                  29 Apr 1991


     A conference will be removed from the Backbone when fewer than 2
     RECs carry it.

     The ZEC may also remove a conference from the Backbone due to
     lack of traffic (under 10 messages over a two month period).

     A conference is subject to removal from the Backbone when the
     Moderator fails to properly carry out his duties, as described
     as described in Section III, or violates Section V.

     A conference is subject to removal from the Backbone if its
     listing in the Echolist is not current.

         NOTE:  To allow time for all existing Backbone conferences
         to be listed in the Echolist, no such conference will be
         removed from the Backbone for a grace period of 120 days
         from the issuance of this document.

     13.  ECHOMAIL MESSAGE STANDARDS:  Until the adoption of a
     superseding standard by the Fidonet Technical Standards
     Committee, the following echomail message standards are
     recommended:

         A) Eight-bit characters (ASCII 128-255) and non-printing
         low-order codes (ASCII 2-31) are prohibited, except the use
         of 8Dh(soft <CR> character) per FTS-0004.  This is not
         intended to discourage participation of foreign zones or
         networks, which may permit said characters.  Any echomail
         processor should pass information exactly as it was
         received, without stripping any non-standard characters.

         B) There should be only one tear line in a message.  Tear
         lines should be limited to 25 characters including the
         required "--- " lead-in.  Tear lines should only contain
         packer or editor program identification.  Tear lines for
         message editors are discouraged.  If an editor adds a tear
         line, it should also add an origin line, to avoid multiple
         tear lines.

         C) There should be only one origin line in a message, except
         as noted in the next paragraph.  Origin lines should be
         limited to 79 characters including the required " * Origin:
         " lead-in and ending of a proper network address (i.e.
         Zone:Net/Node.Point with zone and point being optional),
         enclosed in parenthesis.

         D) "Extra" origin lines are allowed when a message is gated.
         The original origin line's lead-in should be changed to " #
         Origin:  ", and the Echomail Gateway's origin line added.
         There may be more than one extra origin line in the case
         that a message passes through multiple Echomail Gateways.
     FidoNews 8-17                Page 29                  29 Apr 1991


         The Echomail Gateway's origin line is limited to essential
         information only.  This consists of the required lead-in,
         the network name, "Gateway", a proper Fidonet address (i.e.
         Zone:Net/Node with zone being optional), enclosed in
         parenthesis.  Example:  " * Origin:  TComm Gateway
         (1:372/666)".

         E) SEEN-BY addresses should be in sorted order.  AKA's are
         not allowed in SEEN-BY lines unless you have more than one
         address which processes mail.  Or for one month during
         change of an existing address (to avoid duplicates to the
         previous address).  Node 0 addresses should not be used for
         echomail distribution.

         F) All current FTSC specifications must be followed.

     14.  NETMAIL ROUTING:  It is important that users have access to
     routed netmail in order to facilitate private replies to
     echomail messages.  This helps reduce overall echomail message
     volume by allowing off-topic replies, flames and other types of
     messages which don't belong in the conference, to be sent via
     routed netmail.

     Until such time as a new General Fidonet Policy is adopted which
     defines and codifies the routed netmail scheme, the following
     shall be in effect:

         A) Zone Hubs and Regional Hubs shall accept routed netmail
         from any Node or Hub who exchanges Backbone conferences with
         them.  Routed netmail may be routed along echomail paths, or
         to a ZC, RC, or NC  who has agreed to handle such mail.  Any
         netmail message with a valid Fidonet destination will be
         accepted.  Refusal of netmail based a non-Fidonet origin
         will not be allowed.

         B) At the present time, routed netmail is provided by both
         the Coordinator and Echo Coordinator structures.  The ZEC
         shall cooperate with the Coordinators and the Echo
         Coordinators in further developing and maintaining a routed
         netmail scheme.

     16.  FEEDING SEVERED NODE:  Knowingly feeding a conference to a
     Node who has been severed for violations of this document or at
     the request of the Moderator, where such feed is intended to
     subvert either the provisions of this document or the authority
     of the moderator, is considered a serious violation of this
     document.


     VI.  ENFORCEMENT

     FidoNews 8-17                Page 30                  29 Apr 1991


     Enforcement of this document shall be under the provisions of
     General Fidonet Policy.  Serious violations of these procedures
     shall be considered excessively annoying under General Fidonet
     Policy.

     Complaints concerning violations defined under these procedures
     may be filed by the aggrieved individual, the Moderator or by
     any level of Echomail Coordinator to the appropriate IC, ZC, RC
     or NC level.  All complaints made pursuant to this document must
     be made within 60 days of the date of occurrence or discovery.
     Complaints shall be filed under the provisions of General
     Fidonet Policy, with a copy to the ZEC or respective REC, as
     appropriate.

     Enforcement of these procedures are immediate, with any
     currently existing software allowed 90 days to conform (from the
     date this document goes into effect).  30 day extensions may be
     granted solely at the discretion of the ZEC if efforts to bring
     about compliance are clear.  Continued use of aberrant software
     after this period is a serious violation of this document.


     VII.  CHANGES

     Future changes to these procedures may be proposed by any Node,
     by submitting the proposal to any REC.  The REC will then
     determine if the proposal should be brought before the rest of
     the RECs.  If two RECs concur with the proposed change, the
     change must be brought to a vote of all RECs.

     A absolute majority vote of the RECs is required in order for a
     change to be implemented.


     -----------------------------------------------------------------
     FidoNews 8-17                Page 31                  29 Apr 1991


     =================================================================
                              LATEST VERSIONS
     =================================================================

                         Latest Software Versions

                              MS-DOS Systems
                              --------------

                           Bulletin Board Software
     Name        Version    Name        Version    Name       Version

     DMG            2.93    Phoenix         1.3    TAG           2.5g
     Fido            12s+   QuickBBS       2.66    TBBS           2.1
     GSBBS          3.02    RBBS          17.3B    TComm/TCommNet 3.4
     Lynx           1.30    RBBSmail      17.3B    Telegard       2.5
     Kitten         2.16    RemoteAccess   1.00*   TPBoard        6.1
     Maximus        1.02    SLBBS          1.77A   Wildcat!      2.55
     Opus           1.14+   Socrates       1.10    WWIV          4.12
     PCBoard        14.5    SuperBBS       1.10    XBBS          1.17

     Network                Node List              Other
     Mailers     Version    Utilities   Version    Utilities  Version

     BinkleyTerm    2.40    EditNL         4.00    ARC            7.0
     D'Bridge       1.30    MakeNL         2.31    ARCAsim       2.30
     Dutchie       2.90C    ParseList      1.30    ARCmail       2.07
     FrontDoor     1.99c    Prune          1.40    ConfMail      4.00
     PRENM          1.47    SysNL          3.14    Crossnet      v1.5
     SEAdog         4.60*   XlatList       2.90    DOMAIN        1.42
     TIMS      1.0(Mod8)    XlaxDiff       2.35    EMM           2.02
                            XlaxNode       2.35    4Dog/4DMatrix 1.18
                                                   Gmail         2.05
                                                   GROUP         2.16
                                                   GUS           1.30
                                                   HeadEdit      1.18
                                                   IMAIL         1.10
                                                   InterPCB      1.31
                                                   LHARC         2.10
                                                   MSG            4.1
                                                   MSGED         2.06
                                                   MSGTOSS        1.3
                                                   Oliver        1.0a
                                                   PK[UN]ZIP     1.20
                                                   QM             1.0
                                                   QSORT         4.03
                                                   ScanToss      1.28
                                                   Sirius        1.0x
                                                   SLMAIL        1.36
                                                   StarLink      1.01
                                                   TagMail       2.41
     FidoNews 8-17                Page 32                  29 Apr 1991


                                                   TCOMMail       2.2
                                                   Telemail      1.27
                                                   TMail         1.15
                                                   TPBNetEd       3.2
                                                   TosScan       1.00
                                                   UFGATE        1.03
                                                   XRS           4.10*
                                                   XST           2.3e
                                                   ZmailH        1.14


                                OS/2 Systems
                                ------------

     Bulletin Board Software   Network Mailers     Other Utilities

     Name            Version   Name      Version   Name       Version

     Maximus-CBCS       1.02   BinkleyTerm  2.40   Parselst      1.32
                                                   ConfMail      4.00
                                                   EchoStat       6.0
                                                   oMMM          1.52
                                                   Omail          3.1
                                                   MsgEd         2.06
                                                   MsgLink       1.0C
                                                   MsgNum        4.14
                                                   LH2           0.50
                                                   PK[UN]ZIP     1.02
                                                   ARC2          6.00
                                                   PolyXARC      2.00
                                                   Qsort          2.1
                                                   Raid           1.0
                                                   Remapper       1.2
                                                   Tick           2.0
                                                   VPurge        2.07


                                 Xenix/Unix
                                 ----------

     BBS Software                  Mailers         Other Utilities
     Name             Version  Name      Version   Name       Version

                               BinkleyTerm 2.30b   Unzip         3.10
                                                   ARC           5.21
                                                   ParseLst     1.30b
                                                   ConfMail     3.31b
                                                   Ommm         1.40b
                                                   Msged        1.99b
                                                   Zoo           2.01
                                                   C-Lharc       1.00
     FidoNews 8-17                Page 33                  29 Apr 1991


                                                   Omail        1.00b


                                   Apple II
                                  ----------

     Bulletin Board Software   Network Mailers     Other Utilities

     Name            Version   Name      Version   Name       Version

     GBBS Pro            2.1   Fruity Dog    1.0   ShrinkIt      3.23*
     DDBBS +             5.0                       ShrinkIt GS   1.04
                                                   deARC2e       2.1
                                                   ProSel        8.66*



                                 Apple CP/M
                                 ----------

     Bulletin Board Software   Network Mailers     Other Utilities

     Name            Version   Name      Version   Name       Version

     Daisy               v2j   Daisy Mailer 0.38   Nodecomp      0.37
                                                   MsgUtil        2.5
                                                   PackUser        v4
                                                   Filer         v2-D
                                                   UNARC.COM     1.20


                                 Macintosh
                                 ---------

     Bulletin Board Software   Network Mailers     Other Utilities

     Name            Version   Name      Version   Name       Version

     Red Ryder Host      2.1   Tabby         2.2   MacArc         0.04
     Mansion            7.15   Copernicus    1.0   ArcMac          1.3
     WWIV (Mac)          3.0                       LHArc          0.41
     Hermes              1.5                       StuffIt Classic 1.6
     FBBS               0.91                       Compact Pro    1.30
     Precision Systems 0.95b*                      TImport        1.92
     TeleFinder Host 2.12T10                       TExport        1.92
                                                   Timestamp       1.6
                                                   Tset            1.3
                                                   Import          3.2
                                                   Export         3.21
     Point System Software                         Sundial         3.2
                                                   PreStamp        3.2
     Name            Version                       OriginatorII    2.0
     FidoNews 8-17                Page 34                  29 Apr 1991


                                                   AreaFix         1.6
     Copernicus          1.0                       Mantissa       3.21
     CounterPoint       1.09                       Zenith          1.5
                                                   Eventmeister    1.0
                                                   TSort           1.0
                                                   Mehitable       2.0
                                                   UNZIP         1.02c
                                                   Zip Extract    0.10

                                   Amiga
                                   -----

     Bulletin Board Software   Network Mailers     Other Utilities

     Name            Version   Name      Version   Name       Version

     Falcon CBBS        0.45   BinkleyTerm  1.00   AmigArc       0.23
     Paragon           2.082+  TrapDoor     1.50   AReceipt       1.5
     TransAmiga         1.07   WelMat       0.44   booz          1.01
                                                   ConfMail      1.12
                                                   ChameleonEdit 0.10
                                                   ElectricHerald1.66
                                                   Lharc         1.30
                                                   Login         0.18
                                                   MessageFilter 1.52
                                                   oMMM         1.49b
                                                   ParseLst      1.64
                                                   PkAX          1.00
                                                   PolyxAmy      2.02
                                                   RMB           1.30
                                                   Roof         44.03
                                                   RoboWriter    1.02
                                                   Rsh           4.06
                                                   Skyparse      2.30
                                                   Tick          0.75
                                                   TrapList      1.12
                                                   UNZIP         1.31
                                                   Yuck!         1.61
                                                   Zippy (Unzip) 1.25
                                                   Zoo           2.01

                                Atari ST/TT
                                -----------

     Bulletin Board         Network                Node List
     Software    Version    Mailer      Version    Utilities  Version

     FIDOdoor/ST   2.2.3*   BinkleyTerm   2.40l    ParseList     1.30
     QuickBBS/ST    1.02    The BOX        1.20    Xlist         1.12
     Pandora BBS   2.41c                           EchoFix       1.20
     GS Point       0.61                           sTICK/Hatch   5.50*
     LED ST         1.00
     MSGED         1.96S

     FidoNews 8-17                Page 35                  29 Apr 1991


     Archiver               Msg Format             Other
     Utilities   Version    Converters  Version    Utilities  Version

     LHARC          0.60    TB2BINK        1.00    ConfMail      4.03
     LHARC2         3.18*   BINK2TB        1.00    ComScan       1.02
     ARC            6.02    FiFo           2.1m*   Import        1.14
     PKUNZIP        1.10                           OMMM          1.40
                                                   Pack          1.00
                                                   FastPack      1.20
                                                   FDrenum      2.2.7*
                                                   Trenum        0.10


                                Archimedes
                                ----------

     BBS Software           Mailers                Utilities
     Name        Version    Name        Version    Name       Version

     ARCbbs         1.44    BinkleyTerm    2.03    Unzip        2.1TH
                                                   ARC           1.03
                                                   !Spark       2.00d

                                                   ParseLst      1.30
                                                   BatchPacker   1.00


     + Netmail capable (does not require additional mailer software)
     * Recently changed

     Utility authors:  Please help  keep  this  list  up  to  date  by
     reporting  new  versions  to 1:1/1.  It is not our intent to list
     all utilities here, only those which verge on necessity.

     -----------------------------------------------------------------
     FidoNews 8-17                Page 36                  29 Apr 1991


     =================================================================
                                  NOTICES
     =================================================================

                          The Interrupt Stack


     12 May 1991
        Fourth anniversary of FidoNet operations in Latin America and
        second anniversary of the creation of Zone-4.

     15 Aug 1991
        5th annual Z1 Fido Convention - FidoCon '91 "A New Beginning"
        Sheraton Denver West August 15 through August 18 1991.

      8 Sep 1991
        25th anniversary of first airing of Star Trek on NBC!

      7 Oct 1991
        Area code  415  fragments.   Alameda and Contra Costa Counties
        will  begin  using  area  code  510.   This includes  Oakland,
        Concord, Berkeley  and  Hayward.    San  Francisco, San Mateo,
        Marin, parts of  Santa Clara County, and the San Francisco Bay
        Islands will retain area code 415.

      1 Nov 1991
        Area code 301 will split.  Area code 410 will consist of the
        northeastern part of Maryland, as well as the eastern shore.
        This will include Baltimore and the surrounding area. Area 301
        will include southern and western parts of the state,
        including the areas around Washington DC. Area 410 phones will
        answer to calls to area 301 until November, 1992.

      1 Feb 1992
        Area  code 213 fragments.    Western,  coastal,  southern  and
        eastern portions of Los Angeles  County  will begin using area
        code 310.  This includes Los  Angeles  International  Airport,
        West  Los  Angeles,  San  Pedro and Whittier.    Downtown  Los
        Angeles  and  surrounding  communities  (such as Hollywood and
        Montebello) will retain area code 213.

      1 Dec 1993
        Tenth anniversary of Fido Version 1 release.

      5 Jun 1997
        David Dodell's 40th Birthday


     If you have something which you would like to see on this
     calendar, please send a message to FidoNet node 1:1/1.

     FidoNews 8-17                Page 37                  29 Apr 1991


     -----------------------------------------------------------------

