Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  nodelist  faq  login

Are you perchance running on a 64-bit machine? -- Larry Wall in <>

computers / news.admin.hierarchies / Usenet Hierarchy Administration FAQ

o Usenet Hierarchy Administration FAQRuss Allbery

Subject: Usenet Hierarchy Administration FAQ
From: Russ Allbery
Newsgroups: news.admin.hierarchies
Organization: The Eyrie
Date: Mon, 15 Nov 2021 08:01 UTC
From: (Russ Allbery)
Newsgroups: news.admin.hierarchies
Subject: Usenet Hierarchy Administration FAQ
Supersedes: <usenet-hier-faq-1634281265$>
Date: Mon, 15 Nov 2021 08:01:02 -0000 (UTC)
Organization: The Eyrie
Expires: 20 Dec 2021 08:01:02 -0000
Message-ID: <usenet-hier-faq-1636963262$>
Injection-Date: Mon, 15 Nov 2021 08:01:02 -0000 (UTC)
logging-data="19477"; mail-complaints-to=""
View all headers
Last-modified: 2018-07-16
Posted-by: postfaq 1.17 (Perl 5.28.1)
Archive-name: usenet/hierarchy-admin
Posting-frequency: monthly

This FAQ attempts to provide help to Usenet hierarchy administrators, the
people who try to maintain the canonical lists of newsgroups in managed
hierarchies.  It is aimed at the hierarchy administrators rather than at
news admins and tries to summarize the issues to consider in making it
easy for news admins to carry the hierarchy.

If you're reading this on Usenet, this FAQ is formatted as a minimal
digest, so if your news or mail reader has digest handling capabilities
you can use them to navigate between sections.  In rn variants, you can
use Ctrl-G to skip to the next section; in Gnus, press Ctrl-D to break
each section into a separate article.

Please send any comments, suggestions, or updates to
Bear in mind when sending me e-mail that I receive upwards of 800 mail
messages a day and sometimes have a large backlog of personal e-mail.

This FAQ is posted monthly to news.admin.hierarchies, and is available on
the web at


Subject: Contents

1.  Introduction and Terms
2.  Basic Hierarchy Administration
3.  PGP-Signing Control Messages
4.  Maintaining Moderated Groups
5.  About the Newsgroup Lists
6.  Other Resources


Subject: 1. Introduction and Terms

This FAQ assumes a basic familiarity with Usenet (there are other
documents that explain the fundamentals better), but there are a few
additional concepts that are specifically important for Usenet hierarchy

A Usenet hierarchy is, reduced to its essence, a set of Usenet newsgroups
that share a common naming prefix, such as all groups starting with
"comp." or all groups starting with "de.".  The names of Usenet newsgroups
define a hierarchy of names, with "." used as the separator between the
levels of the hierarchy, like host names.  Unlike host names, the most
significant part of the name is given first.  The first component of the
name is special and more significant than the rest of the name, since it
defines the top-level Usenet hierarchy to which that group belongs.

Generally, every top-level hierarchy is completely independent of the
others (although there are a few exceptions where multiple hierarchies
share the same management procedures).  How the list of newsgroups in that
hierarchy should be maintained varies very widely between hierarchies,
from the complete anarchy of alt.* to the highly formal system used by
comp.*, or simply by fiat of the organization running the hierarchy as
with microsoft.*.  Which maintenance methods you should use for your
hierarchy is out of scope for this FAQ; this document is about how to
publish the results of those methods, assuming that you want to have a
single canonical list of newsgroups that everyone carrying that hierarchy
can agree on.  If you don't want that (if your hierarchy is like alt.*,
for example), most of this document will not apply.

Usenet newsgroups are created and removed via specially formatted messages
called control messages that tell news servers to do something.  A
hierarchy should have a hierarchy administrator who is responsible for
following whatever procedures were agreed on for changing the list of
groups in that hierarchy and then publishing the results using control
messages.  The structure of control messages is explained in the Usenet
news standards and in many FAQs and web pages, so it won't be explained
here.  (Some sites don't use control messages for various reasons, and
it's therefore best to also publish the results via other methods, as will
be explained.)

Besides newgroup (create a newsgroup) and rmgroup (remove a newsgroup)
control messages, there is also a control message called a checkgroups
which provides a complete list of newsgroups in a hierarchy complete with
short descriptions.  A "checkgroups" is therefore also used to mean a
complete list of newsgroups in a hierarchy.  The checkgroups format is a
list of groups, one per line, with the name of the group, a tab, and a
short description.  If the newsgroup is moderated, the description must
end in the literal text " (Moderated)".  (Sadly, you can't translate the
word to another language.  It's an ugly wart on the protocol.)

Originally, control messages were authenticated only by the (easily
forged) address of the sender of the message, which worked when Usenet was
small but broke down badly as it got larger.  As a result, most
hierarchies now sign their control messages using PGP, an open standard
for public key cryptography, allowing receiving sites to verify that the
control message was issued by the person it claims to be from.


Subject: 2. Basic Hierarchy Administration

A hierarchy administrator has three separate audiences who should be kept
in mind when publishing information about a Usenet hierarchy:  users who
may be interested in reading or posting to the hierarchy, news
administrators who are not currently carrying the hierarchy on their
servers and want to, and news administrators who are already carrying the
hierarchy and want to keep current with changes to it.

The most important audience is probably the users, but that's also the
audience that's the hardest to make general statements about, since how
you communicate with potential users varies quite a bit by hierarchy.  The
users will primarily be interested in a description of what the hierarchy
is for, a list of groups in the hierarchy, any hierarchy-wide policies,
the charters of the newsgroups, and the newsgroup creation procedure.
They'll generally speak the same language as the hierarchy (since if they
don't, they probably won't be interested in reading it).

News administrators who aren't currently carrying the hierarchy likely
won't be as interested in detail like particuliar policies or group
charters, but will also be interested in the overall purpose for the
hierarchy and any policies that specifically affect sites carrying the
groups.  They will specifically need the list of newsgroups in the
hierarchy in checkgroups format, however, and preferrably as a plain-text
file that they can download and feed into their news software.  They'll
also need instructions for processing control messages to pick up changes
to the hierarchy, generally as an INN control.ctl fragment.  Finally, news
administrators may not speak the language of your hierarchy (they may be
running a news server for a large international ISP, for example), so you
may want to provide instructions specifically for news administrators in
English if the language of your hierarchy isn't English.

News administrators who are already carrying the hierarchy are mostly
interested in being notified of changes to it (usually via control
messages).  They also want ways of checking their group list against the
current one so that they can get back into sync if they've missed some

So, given that, here are a few specific recommendations:

 * Have a web site.  Try to make sure that the URL for your hierarchy web
   site is stable and doesn't change, since the URL makes it into various
   FAQs and configuration files that live for years.  Put all of the
   hierarchy information on the web site, and make sure that the web site
   stays up to date. may be available as a
   hosting site for your web site.

 * Every time you create a group, remove a group, rename a group (which
   can be done with a creation and removal), or change the moderation
   status of a group, send the appropriate control message.  By looking
   for it in under your hierarchy,
   you can check that the control message has propagated.  Control
   messages should have, in the Newsgroups header, the group being created
   or removed (even for newgroup messages; they'll propagate correctly
   even though the group hasn't been created yet because newgroup messages
   have special propagation rules).  The exception is checkgroups
   messages, which should normally be posted to the administrative group
   of your hierarchy and possibly crossposted to news.admin.hierarchies.
   Don't put a Distribution header in your control messages unless you
   really intend to limit the availability of the groups to sites
   configured to accept that distribution (which mostly doesn't work

 * Send a checkgroups control message periodically.  If you do this, you
   don't really need to send duplicate control messages for changes; if
   someone misses a change, they'll catch it with the next checkgroups

Click here to read the complete article
rocksolid light 0.7.2