* * * F I N A L D R A F T P R O P O S A L * * * May 14, 1994 * * *
Zone One Mail Backbone Operating Procedures
=============================================
Revision: 1.05 Effective Date: July 1, 1994
Table of Contents
===================
1.0 Introduction
1.1 Purpose of this Document
1.2 Definitions
2.0 Zone Level Operations
2.1 Zone Backbone Coordinator
2.2 Zone Hubs
3.0 Conference Moderators
3.1 Recognition of Moderators
3.2 Responsibilities of Moderators
4.0 Other Operating Procedures
4.1 Administrative Areas
4.2 Message Technical Standards
4.3 Adding Conferences to the Backbone
4.4 Removing Conferences from the Backbone
4.5 Routed Netmail
5.0 Changes to this Document
1.0 Introduction
=================
1.1 Purpose of this Document
-----------------------------
This document sets forth the operating procedures used, and defines the
services offered, by the Zone One Mail Backbone at the zone level. It
describes how the Zone Backbone Coordinator is selected. It also
describes how the Zone Hubs operate. The operation of the Backbone
within regions and nets is not covered by this document.
Participation in the Zone One Mail Backbone is voluntary. Those
Coordinators, Hubs, Nodes and Moderators who participate, agree to
operate by the procedures, and offer the services, as described in this
document.
The services offered by the Zone One Mail Backbone are in addition to
any which are required of, or due to, members of FidoNet by FidoNet
Policy. Use of these services should be viewed as a privilege, not a
right.
Although the Zone One Mail Backbone attempts to provide the best service
possible, there is no guarantee provided. Specifically, messages which
require sensitive or timely handling should not be sent through the Zone
One Mail Backbone.
This document is not a part of FidoNet Policy. Should any part of this
document conflict with FidoNet Policy then FidoNet Policy shall prevail.
1.2 Definitions
----------------
The Zone One Mail Backbone consists of the Coordinators, Hubs and Nodes
who agree to operate by the procedures, and offer the services, as
described in this document, to help distribute the Zone One Mail
Backbone echomail conferences and routed netmail to end users, other
distribution services and other networks. The Zone One Mail Backbone is
hereafter referred to simply as the Backbone.
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.
The Zone Backbone Coordinator (ZBC) functions at the zone level. It is
assumed that Backbone Coordinators of some sort exist at the region
level. Hence this document refers to them as Region Backbone
Coordinators (RBCs) with the understanding that this might vary within
any given region. Regions select their RBCs however they choose. RBCs
function at the regional level, providing regional input and direction
to the operation of the Backbone at the zone level, as described
elsewhere in this document.
Hubs are Nodes who distribute mail to other Nodes. Zone Hubs (ZHubs)
distribute mail at the zone level. It is assumed that Hubs of some sort
exist at the region level. Hence this document refers to them as Region
Hubs (RHubs) with the understanding that this might vary within any
given region.
2.0 Zone Level Operations
==========================
2.1 Zone Backbone Coordinator
------------------------------
The Zone Backbone Coordinator (ZBC) oversees the operation of the
Backbone at the zone level. The ZBC coordinates routing and schedules
to ensure reliable and efficient availability of Backbone mail while
avoiding creation of duplicate messages. The current ZBC can be
identified from his[her] listing in the FIDOSTAT.NA file.
The ZBC maintains a list of Backbone conferences in a text file called
FIDONET.NA. He[she] also maintains a list of temporary Backbone
conferences, in a text file called FIDONET.NO. These files are
formatted so that they can be used as forward-lists by programs such as
AreaFix. The ZBC distributes these files on a weekly basis via the
BACKBONE file area.
The ZBC maintains a text file called FIDOSTAT.NA. This file contains a
list of conferences seeking to be added to the Backbone. It also
contains a list of the ZBC, ZHubs, RBCs and RHubs. The ZBC distributes
this file on a weekly basis via the BACKBONE file area.
The ZBC is selected by a vote of the RBCs. A mutually agreeable RBC serves
as the election chairman. An election is held when any of the following
occur:
1) The ZBC position becomes vacant.
2) More than one-fourth of the RBCs request that an election be held
and it has been more than six months since the last election.
3) It has been more than 2 years since the last election.
2.2 Zone Hubs
--------------
The ZBC appoints Zone Hubs (ZHubs) to distribute Backbone mail at the
zone level. The ZBC may also serve as a ZHub if [s]he so desires.
Each ZHub offers a minimum of one connection to each region.
Each ZHub makes available all of the Backbone conferences, routed
netmail and the BACKBONE file area. Nothing in this provision requires
that a ZHub carry any conference to the extent of adverse economic
impact.
The ZHubs maintain an emergency backup plan should one of them
experience problems.
3.0 Conference Moderators
==========================
Conference Moderators (Moderators) preside over conferences. The
Backbone has no desire to interfere with the internal affairs of a
conference in so much as they do not disturb the operation of the
Backbone.
A Moderator need not be either a SysOp or a member of FidoNet.
3.1 Recognition of Moderators
------------------------------
A Moderator is recognized as follows:
1) Upon formation of a conference, the person who forms the
conference is the Moderator.
2) Upon resignation or replacement of an existing Moderator, the
conference's rules define how the new Moderator is selected.
3) The Moderator and Co-Moderators, if any, are listed in the
Echolist entry for the conference since it serves as the guide
for Hubs needing this information.
Moderators are encouraged to appoint Co-Moderators to assist them in
their responsibilities and to stand in for them in their absence.
3.2 Responsibilities of Moderators
-----------------------------------
Moderators are responsible for:
1) Maintaining a netmail address in the Echolist, at which they can
be reached from FidoNet.
2) Seeing that messages in their conference correspond to the
conference's theme.
3) Seeing that messages in their conference do not contain illegal
information or promote illegal activities.
4) Posting the conference rules or policies in the conference at
least every month.
5) Updating their conference listing in the Echolist at least every
six months.
If a Moderator determines that a Node persists in violating a conference
rule, [s]he may direct the feed to that Node be severed. Such a
directive, listing the conference rule violated, is made in a netmail
message to the Hub feeding the offending Node, with a copy to the
offending Node. After verifying the Moderator in the Echolist, the Hub
severs the feed.
Should the Hub not comply with the Moderator's directive then the
Moderator may direct the feed to that Hub be severed, and so on. Such a
directive, listing the procedure followed, is made in a netmail message
to the Hub feeding the offending Hub, with a copy to the offending Hub.
After verifying the information, the Hub severs the feed of the
offending Hub.
4.0 Other Operating Procedures
===============================
4.1 Administrative Areas
-------------------------
The Z1_BACKBONE and Z1_RBC conferences are used to conduct Backbone
business. Z1_BACKBONE is open to any Node having business with the
Backbone. Z1_RBC is restricted for use by region and zone level
Backbone Coordinators and Hubs. The ZBC serves as Moderator for both
conferences.
4.2 Message Technical Standards
--------------------------------
FTSC specification FTS-0001 is followed.
Only ASCII characters are used in a message's control fields.
Pathlines are used.
Due to the limitations of some current software, the Backbone can not
guarantee delivery of messages in excess of 13,000 bytes. Hubs are
encouraged to use message processing software which allows larger
messages, preferably up to 64K bytes, to be handled.
The Backbone does not agree to handle encrypted messages in conferences,
excepting digital signatures and occasional demonstration and/or test
messages.
Hubs may delete messages which do not conform to the technical standards
set forth in this Section when such messages might be harmful to the
technical operation of the Backbone. This includes duplicate messages,
"grunged" messages and echomail messages over 20 days old. Such
messages are generally not returned.
Hubs operate in a secure fashion. They automatically process inbound
messages only from those nodes with which prior agreements have been
made. Normally this means that Hubs use session passwords and secure
("protected") inbound areas. However, any reasonable method of ensuring
that non-secure messages do not enter the Backbone is acceptable.
A Hub may choose not to provide services to a Node which does not
operate in a secure fashion if this Node has a history of causing
problems due to this lack of security.
4.3 Adding Conferences to the Backbone
---------------------------------------
A conference is added to the Backbone and listed in the FIDONET.NA file
when all of these requirements are met:
1) The conference is listed in the published Echolist.
2) The Moderator either sends a netmail request to the ZBC or an
echomail request, addressed to "Backbone", in the Z1_BACKBONE
conference. The ZBC normally requires that the conference has
achieved some degree of distribution before accepting this
request. See the FIDOSTAT.NA file for current limits.
3) At least three RBCs request that the Backbone distribute the
conference to their regions.
Also, any conference removed temporarily from the Backbone is restored
to regular Backbone distribution when it again qualifies.
4.4 Removing Conferences from the Backbone
-------------------------------------------
A conference is removed temporarily from the Backbone, with its listing
moved from the FIDONET.NA file to the FIDONET.NO file, when any of these
situations occur:
1) The conference is no longer listed in the published Echolist.
2) The conference is without a Moderator.
3) There are no longer three RBCs requesting that the Backbone
distribute the conference to their regions.
A conference is removed entirely from the Backbone, with its listing
removed from both the FIDONET.NA file and the FIDONET.NO file, when any
of these situations occur:
1) The Moderator either sends a netmail request to the ZBC or an
echomail request, addressed to "Backbone", in the Z1_BACKBONE
conference.
2) The Moderator does not carry out his[her] responsibilities, as
described in Section 3.2 and determined by the ZBC.
3) The traffic level in the conference falls below ten messages
over a two month period.
4) A conference which was removed temporarily from the Backbone
does not qualify to be restored to regular Backbone distribution
within two months of being removed.
5) When such an excessive number of complaints about the conference
or its Moderator are received by the RBCs that a majority of
them vote to remove the conference from the Backbone.
4.5 Routed Netmail
-------------------
Hubs accept routed netmail from any Node who connects with them for
Backbone conferences. Any netmail message with a valid FidoNet
destination, regardless of its origin, is accepted. Routed netmail may
be routed along Backbone paths or to a ZC, RC, or NC who has agreed to
handle such messages.
Routed netmail is for personal messages. It is not for commercial
messages, conferences, mailing lists, news groups, file-attaches, or
"encoded" files.
Some Hubs do not allow encrypted messages to flow through their systems.
Therefore, the Backbone does not agree to handle encrypted routed
netmail messages, excepting digital signatures.
5.0 Changes to this Document
=============================
A change to this document may be proposed by any RBC. If a second RBC
concurs, the proposed change is voted on by all of the RBCs. Notice of
such a vote, including the proposed change, is posted in the Z1_RBC
conference, the Z1_BACKBONE conference and the FIDOSTAT.NA file, at
least fourteen days prior to the start of the voting period.
The RBCs are expected to assess the opinions of the Backbone
Coordinators, Hubs and Nodes in their regions, and to vote accordingly.
More than fifty percent of those voting must vote for a change for it to
be accepted.
- end -
* * * F I N A L D R A F T P R O P O S A L * * *