    Sysop's TechNet Policy Document revision 010                        01/10/2006

    --- Overview -----------------------------------------------------------------

    This document establishes the policy for sysops who are members of the
    Sysop's TechNet organization of Bulletin Board Systems and electronic mail
    transportation.

    Sysop's TechNet is an organization of sysops whom are interested and eagre
    to pursue the development and support of Bulletin Board Software and related
    programs.  To this extent, Sysop's TechNet is an organization of dilligent
    systems operators who wish to keep their hobby alive and pursue the
    development of the associated programs and standards.

    Although primarily a FidoNet Technology network, Sysop's TechNet (also referred
    to as STN) is not associated with nor in competition with the FidoNet network.
    STN is simply another alternative network where sysop support is the primary
    focus.

    Portions new to any given revision are denoted at the beginning of the line
    by the '|' character.

    1.  Language

    To facilitate the largest possible readership, all international STN documents
    will be written in English.  Translation into other languages is encouraged.

    The primary language of the network itself, however, will remain strictly
    english.

    2.  Introduction

    Sysop's TechNet was founded on May 16, 1996 by founder Vincent Danen and co-
    founder Kevin Nunn.  It was founded in an effort to provide support for
    systems operators, and since there were no other sysop-oriented networks, that
    were solely of that nature, STN is the first.

    STN is a network that many felt was necessary among the BBS world.  There was
    a lack of comraderie among the nodes of larger networks, and a power-struggle
    that was egotistical in nature by iron-fisted moderators and coordinators.
    STN was founded to remedy that sorry situation, and to provide an alternative
    to the abuse sometimes found in other networks, yet at the same time provide
    the support sysops around the world craved.  Within the first year of
    existance, STN gathered over 80 individual nodes across the globe, making it
    one of the fastest growing echomail networks available.

    The goals of STN are to provide information and support to sysops, in an
    honest and friendly fashion.  To provide opportunities for developers to
    inform the public of their product and support it directly.  This benefits the
    end user as well as the developer by providing a mutual relationship of
    support and financial gain.  Although STN is not a commercial network in
    nature, we do not oppose advertising and promotion of individual products.

    To this end, Sysop's TechNet is a tool to be used by sysops who wish to learn
    more about the hobby, strengthen their own systems as well as find
    alternatives to software they use, as well as inform them of other products
    available, and to provide support for those selfsame products.

    3.  Organization

    The STN network is fashioned after the typical FTN-style network.  In this,
    STN consists of points, individual nodes, local hubs, hosts, regional
    | coordinators, and finally the international coordinators.

    STN is divided into nine major regions that cover the entire world.  Below
    these regions are individual hosts which are split up based on areacode.  The
    hosts maintain a specific areacode, and provide for the individual nodes
    beneath.  Hubs may be used in networks to reduce the costs of long distance.

    | The International Coordinator(s) have final say over all things.  Consider them
    | the monarchs of the network.  All final decisions are his to make.  However, STN
    is governed, more or less, by a Regional Council, made up of the nine regional
    coordinators.  The Regional Council dictates the direction of the network,
    accepts applications, and solves disputes on a regional basis.  If there are
    ever any inter-regional conflicts, the regionals will attempt to mend the
    | dispute, but the International Coordinator(s) have final say.

    Echomail and netmail is distributed along these channels.  STN is not strict
    in the method of obtaining an echomail feed, however it is desireable that one
    remains within the region for obtaining their feed.  Inter-regional feeds are
    possible, of course, however they are discouraged for simplicity's sake.
    Inter-regional feeds can make the routing of netmail difficult, and delivery
    cannot be ensured.

    Within each region are the regional coordinators and the Regional Internet
    Hubs.  The RIHs are individuals within a region who provide echomail feeds
    via the internet to networks within that region.  RIHs can utilize any or all
    of the following internet transport methods but is not limited to:

        Transx
        E-mail
        Fido2Internet
        Internet Rex
        AllFix
        WaterGate's MailTunnel
        FTP
        Vmodem/Telnet polls
        TCP/IP
        QWK
        BinkP
        InterNet Rex
        BinkD
        NNTP
        List

    If this form of echomail distribution is undesirable or unfeasible for a
    network, landline connections will be required.  Alternative methods of
    transportation will be considered as well.

    --- Network Information and Regulations --------------------------------------

    1.   Nodelists

    The nodelist is an ASCII file that is updated weekly containing the node
    addresses of all the members of STN.  The nodelist does not contain point
    information.

    The IC releases the nodelist each Friday morning, therefore all regionals must
    have their nodelist segment in to the IC prior to Thursday morning each week.
    It is up to the individual regional whether or not they will require their
    hosts to deliver similar nodelist segments to them in time enough to process
    and send their own segment to the IC by the required time.

    2.  Encryption of Mail

    STN does not advocate the use of encrypted mail, however neither does it forbid
    the use.  Encrypted mail may be used in netmail alone, whether routed or
    direct.  Encrypted mail may not be used in echomail areas.  Use of PGP and
    similar programs to provide digital signatures or fingerprints is, however,
    encouraged to ensure the integrity of mail for those concerned.  The nodelist
    flag NCR must be observed where encrypted mail is concerned, however.  The NCR
    flag is placed on systems whom, by country law, may not receive or send any
    encrypted mail.

    3.  Routed Netmail

    Netmail is private person to person mail.  It may be crashed direct or routed
    through other systems to reduce costs for the sender.  However, routed netmail
    must not be altered in any way by the systems it is being routed through.
    Tampering with routed netmail is grounds for dismissal.

    Disclosing the contents of routed netmail to other parties other than the
    sender or recipient is also grounds for dismissal.  Netmail, whether direct or
    routed, is considered private and the contents thereof must remain private.
    This does not apply to echomail.

    4.  Private Nodes

    Private nodes do not, and will not, exist in STN.  Mail-only nodes are
    admissable, however.  Do not ask to have private status in the network as you
    will be refused.  This does not include points.
    Unless a Pvt node have a *Telnet* bbs system behind his mailer, and can be
    reach by this Telnet system to BBs.

    5.  Dismissal

    Nodes may be dismissed from the network for a number of reasons.  Foremost of
    these is aggressive or overly annoying behaviour.  On the recommendation of
    the Regional Council or of network moderators, an individual being blatantly
    obnoxious, whether in private or publically in echomail, may be dismissed.
    Complaints by other nodes may cause investigation as to the validity of the
    complaints, and if severe enough, may cause dismissal.

    Nodes may also be dismissed from the network due to failure to comply with
    policy standards, or by being unresponsive.  From time to time, by the IC's
    discretion, messages may be posted in the administrative echo (STN.ADMIN) that
    requires responses from nodes.  If these responses are not forthcoming, a node
    may be dismissed.

    6.  Obtaining a Node Addresses

    Currently, node addresses are issued by regional coordinators and the IC.
    Hosts are not permitted to issue node addresses.  To obtain a node address,
    you must fill out the included application form (STN.APP) and forward it to
    the host in your area (who must then forward it to the RC or IC), or send it
    directly to the RC or IC.  For quickest results, sending directly to the RC
    of your area is desirable.

    6.1  Finding your RC

    The world has been divided into 9 regions for STN, numbering 1000, 2000, 3000,
    4000, 5000, 6000, 7000, 8000, and 9000.  To find out which region you belong
    in, observe the following:

      Region        Geographical Location
      ------------- ----------------------------------------------------------
      1000          Canada
      2000          Israel, India, Africa
      3000          Indonesia, Philippines, Asia
      4000          Eastern USA:  MI, IN, KY, TN, GA, FL, SC, NC, VA, WV, OH,
                      PA, NY, NJ, DE, MD, DC, CT, NH, VT, ME, RI, MN, IA, WI,
                      IL, AK
      6000          Western USA:  CA, NV, UT, AZ, CO, NM, KS, OK, TX, AR, LA,
                      MS, AL, FL, HI, WA, OR, ID, MT, WY, ND, SD, NE
      7000          Europe, Former Soviet Union
      8000          Australia, New Zealand
      9000          South America, Mexico

    7.  Down Systems and Absenses

    If your system is going down for a prolonged period of time (more than two
    days), inform your host or regional coordinator as quickly as possible.  This
    will prevent unnecessary wasted calls to your system when down, as well as the
    possibility of dismissal.  If you are going to be absent from your system and
    it will be unattended for more than two days, inform your host or regional
    coordinator as well, so that if problems do arise, or connections are not
    obtained, they know ahead of time that you are gone.  This is simply a matter
    of courtesy and respect to other members of the network.

    8.  General Guidelines

    There are very few guidelines in STN, and they are more common sense
    guidelines than rules of the network.  However, they must be adhered to.
    Failure to comply with these simple guidelines may be cause for dismissal.

    1) This is a real-name only network.  Aliases are not permitted in the
       echomail areas.

    2) Excessive use of vulgar language is not tolerated.  Minors may be using
       (and are encouraged) to use this network.  We don't want to offend them or
       their parents, and basically we don't want to offend anyone.  If you can
       say it without the extra "flair", please do so.

    3) The excessive use of quoting is frowned upon.  It is considered
       exceptionally rude, and particularly useless.  People want to read your
       replies, not what 20 people previously said.

    4) There is to be no software bashing without a legitimate reason.

    5) All members of the network are equal.  The obvious structure of the network
       (in regards to hubs, hosts, RCs, etc.) implies power to certain positions.
    |   The only true powers in the network are the moderators, the RCs, and the
    |   ICs.

    6) If there is a problem between sysops or systems, take it to netmail.  It
       doesn't belong in the echos.  If someone is creating a problem, chances are
       the administrators will pick up on it and deal with it.  Don't presume to
       take our place in the event that such action needs to be taken.  We won't
       like it.

    7) On the above note, flaming, derogatory remarks, racial/ethnic/sexual slurs
       are not permitted.  If any of this is noted, the offending user will have
       ONE warning.  If it is not heeded, the sysop must remove their access.  If
       the sysop cannot or will not comply with this, their feed will be cut.
       This also includes any and all forms of harrassment, whether the originator
       sees it as such or not.

    8) The File Announcements echo may be used to announce any files coming into
       your system, and all sysops in the net are encouraged to use the echo.
       However, announcements containing adult files and/or illegal (pirated)
       files are frowned upon.  Please keep this in mind when you announce your
       files.  It is also strongly suggested that you announce your files once
       per day. This is by no means mandatory, but it would be appreciated if done.

    9) The administration echo, STN.ADMIN, is mandatory reading.  All nodes are
       required to read the information posted in that echo.  Browsing the
       messages is encouraged.  Ignoring messages or the echo itself is not.
       Important information vital to the network is often posted there.  A sysop
       may be inadvertantly dismissed because they do not read in that echo.

    --- Requirements of Coordinators ---------------------------------------------

    1.  Nodelist Availability

    Each coordinator should have the STN nodelist available for download and file
    request.  Along with this, each coordinator should also have the latest
    informational package available.  This facilitates the growth of the network
    by making information available.

    2.  Nodelist Segments

    Each RC is responsible for maintaining one working copy of MakeNL or a similar
    program/method to provide the IC with a nodelist segment prior to Thursday
    morning every week.  This segment is the make-up of the entire region.  This
    is required of all RCs.  It is up to individual RCs as to whether they wish
    their hosts to participate in this practice and send them nodelist segments of
    each network.

    3.  New Sysops

    Coordinators are encouraged to freely provide information on STN, whether it
    be verbally, through discussion or advertisements, or by having and spreading
    the informational package.  The growth of STN depends on how free we are with
    the information concerning it, and how much we are willing to bend to provide
    an applying sysop every courtesy they deserve.  Alienating new nodes because
    of lack of information or rude dispositions is frowned upon.

    Also, when a host is assigned a new downlink, they must act as quickly as
    possible to setup and provide a feed for the new sysop.  This will show the
    new sysop the true spirit of STN as opposed to other networks.  It will also
    show STN's efficiency as an organization and as a network.

    In the event that a new sysop joins and becomes the second system of a
    one-system network and the host of that network does not respond or is seen as
    unfit to be a network coordinator, the existing NC may be demoted to simple
    node status and the new node provided with NC status.  This will ensure that
    the pro-active members of the network remain in positions to further the
    network, instead of being hampered by those who propogate nothing.

    4.  Technological Competence

    Coordinators are required to have previous knowledge of FTN networks and their
    own software.  This facilitates efficiency when helping inexperienced sysops
    join the network, as well it provides a solid backbone for network operations.
    An inept coordinator is not one who can do their job, nor who can do their
    best in a position granted them.  Therefore, some competence with FTN networks
    and FTN technology is required.

    5.  NCs

    Network Coordinators are hosts who maintain individual areacode-assigned
    networks.  It is their responsibility to ensure the smooth maintenance of the
    network, and to keep abreast of any problems within the network.  It is also
    highly desirable of NCs to promote STN in their local area and bring new
    nodes into their network.

    On the discretion of the RC, NCs may be required to submit a nodelist segment
    each week for their network.  NCs are required to forward the full nodelist,
    weekly, to their downlinks.

    6.  RCs

    Regional Coordinators maintain a group of networks within their assigned
    region.  It is their responsibility to ensure smooth maintenance of their
    region, and to keep abreast of any problems within the region, or individual
    networks.  In a network or regional scenario, the RC's decision supercedes
    all others with the exception of the ICs.  RCs should also be promoting STN in
    their local areas and region-wide if possible.  This can be done through
    advertising in other networks, providing and spreading informational packages,
    and other means.

    RCs are required to submit a regional nodelist segment to the IC prior to
    Thursday morning each week.  RCs are required to forward the full nodelist,
    weekly, to their downlinks.

    7.  RIHs

    Regional Internet Hubs are required to provide a full echomail backbone feed,
    including the alternate backbone, and a full fileecho feed to networks within
    | their region.  RIHs receive their feed from the ICs and forward mail down to
    those networks within their region who may require it.  RIHs are free to
    choose whichever internet transport method they prefer and are able to
    provide.  In the event that a network requires a transport method the RIH
    cannot provide, RIHs in other regions, or the ICs, may be required to provide
    the feed.

    | 8.  ICs

    | The International Coordinators maintain the entire nodelist and must keep
    | abreast of all things in the network.  The ICs maintain the echomail backbone,
    | as well as the alternate backbone, and the fileecho system.  The ICs have final
    | say on all matters of the network, and their primary function is to ensure the
    | network is smoothly run.  Every Friday morning, the ICs release a full
    | nodelist to all downlinks and regionals.

    | The ICs are also responsible for maintaing all documents pertaining to STN, as
    | well as a timely release of informational packages as required.

    | If there are ever conflicts in the network, as human nature dictates there
    | must, the ICs have final say over all things.  The ICs will fairly consider
    | appeals and requests, and will weigh the opinions and recommendations of the
    | Regional Council, moderators, and individual NCs.  In all cases, the
    | offending node(s) have the right to defend themselves.  The ICs will fairly
    | consider their defense, and make any judgements on them.  The ICs will always
    | try to be fair, yet will consider the good of the entire network over the good
    | of individual node(s).

    9.  Moderators

    Moderators are necessary to the network to ensure that echomail traffic is not
    polluted with off-topic conversation, illegal discussions, or otherwise
    messages that do not conform to the ideals of the network.  There will be no
    more than two moderators per echomail area.  Any individual interested in
    becoming a moderator in a specific echomail area(s) must send a message of
    request to the ICs.

    --- Credits and Acknowledgments ----------------------------------------------

    1.  FidoNet Technical Standards (FTS)

    The Fidonet Technical Standards Committee (FTSC) is a deliberative body
    charged with developing and maintaining technical standards for operations
    in a Fidonet Technology Network (FTN).  All software used in Sysop's TechNet
    communications must be in compliance with the appropriate standards, which
    include:

         FTS-0001  A basic Fidonet technical standard, R Bush
         FTS-0004  Echomail specifications, B Hartman
         FTS-0005  The distribution nodelist, B Baker, R Moore
         FTS-0006  YOOHOO and YOOHOO/2U2, V Periello
         FTS-0007  SEAlink protocol extension, P Becker
         FTS-0008  Bark file-request protocol extension, P Becker
         FTS-0009  Message identification and reply linkage, j nutt

    Relating to FTS-0009, use of the MSGID kludge in echomail messages is strongly
    encouraged to prevent duplicates of echomail messages in the network.

    Sysop's TechNet may optionally use standards that have not yet been approved
    by the FTSC.  This includes, but is not limited to, nodelist flags.

    Fido and FidoNet are registered trademarks of Fido Software, Inc.