Minimum requirements for running RumorMill 1.2 are as follows:RumorMill is distributed as a "FAT" binary that will also take full advantage of a PowerPC processor when available. Allocating additional RAM to RumorMill (beyond the 2,500KB default allocation) can help if you are recieving many large articles (>250KB each). Allocating more memory than the default can also be useful when using the EMail Gateway features.
RumorMill RumorMill Setup Documentation MacOS 7.0.1 with thread mgr 7.6 n/a Processor 68K or better 68030 or better n/a RAM 2.5MB 2.5MB Web Browser Disk ~690KB + databases ~400KB ~220KB Allocating additional RAM for a large disk cache (see the Memory Control Panel) can also be helpful in improving the performance of RumorMill.
RumorMill is a news (NNTP) server. The News protocol is ideally suited to public discussion, and RumorMill is designed to make it easy to create local or shared Newsgroups. RumorMill (and other NNTP) servers can easily be linked together to create a wide spanning communication network.
RumorMill is a server. To read news from a RumorMill Server you need a news client like Newswatcher, YA-Newswatcher, MT-Newswatcher, or Netscape.
Any discussion of News must include a discussion of Usenet. Usenet is a collection of 30,000+ newsgroups, with about 1 Gigabyte of new articles posted per day. A full Usenet newsfeed requires a fast network connection, a fast computer, and lots of hard disk space.
RumorMill can probably handle the article throughput of a full newsfeed, but it is designed to handle a partial newsfeed and to facilitate the creation of local newsgroups: newsgroups which are only present on the one news server, or have limited distribution. RumorMill is presently limited to an article database no larger than 2GB (this is the current MacOS file system limit for a single file).
RumorMill has not been tested with a full news feed.
The RumorMill distribution comes with two separate applications, RumorMill and RumorMill Setup. RumorMill is the server, while RumorMill Setup is the configuration application. This separation of server and configuration software keeps the server application small, so it takes up less memory, and it also allows you to configure RumorMill remotely: RumorMill Setup can connect from another machine to allow convenient maintenance.
To setup RumorMill you need to specify what Newsgroups you wish to host, where you wish to gather news from and send it to. These are called Newsfeeds. You should also configure who can use the service through Site Restrictions, and possible through Users. RumorMill has a number of other settings which you can use to tighten security, reduce Spam, and tune performance.
When you run RumorMill Setup you will be asked to specify the location of your RumorMill server. If it is running on the same machine as RumorMill Setup select On This Computer, otherwise type in the DNS Name (eg news.stairways.com.au) or IP number (eg 203.10.11.12) of the machine running the RumorMill server. If RumorMill is not running locally (on the same machine as RumorMill Setup) you will need to enter a Site Administrator's Password. By default there is no password. RumorMill can not be configured remotely if there is no Site Administrator Password. (The password can be set in the Security window, using a copy of RumorMill Setup in "On this computer" mode.)
Note: RumorMill Setup saves any password you enter for a remote server in the file RumorMill Setup Preferences in the Preferences folder.
Once you have retrieved the preferences you can modify or update the preferences on the server. The most important information you need to set is in the Newsgroups and Newsfeeds windows.
A Newsgroup is a discussion area, a collection of articles posted by different users of the service. Newsgroup names are strings of normal letters and numbers, usually separated by dots (spaces are not allowed). Names must be all lower case: mixed case names are not allowed. The name should reflect the content and purpose of the newsgroup. (See the appendix on Usenet Group names below for more information.)If you wish to receive Usenet news, the group names must be the same as the Usenet news name. All groups you wish to collect must be listed explicitly in the Newsgroups window or RumorMill will not collect them.
Newsgroups are not explicitly marked as local or global: distribution of the Newsgroups is determined in the Newsfeeds window.
You can add newsgroups individually using the Add button, or you can add a list of Newsgroups using the Open Newsgroups File button. A Newsgroups File must be either plain text file (such as those created by SimpleText or BBEdit) or a Newswatcher preference file. If you are adding a large number of newsgroups it is easiest to list them in a text editor (such as BBEdit) and then load them into the Newsgroups window, or directly using the Create Groups... menu option in RumorMill.
Each newsgroup should have a description describing the purpose of the newsgroup. You may also specify a newsgroup as moderated and an expiration period different from your default expiration period. For existing groups, you can may be able to obtain the descriptions and moderator EMail submission address from your newsfeed.
For more information about handling large numbers of Newsgroups see the General Advice section below.
Newsfeeds are other NNTP servers where news articles come from, and are fed to. The Newsfeeds window lets you control whether news is fed to, received from, or pulled from specific hosts. It also allows you to specify the defaults for how often articles are fed to downstream newsfeeds, and how often they are pulled from upstream newsfeeds.
When you add a new newsfeed you are presented with a Newsfeed Entry window. Accept Articles From This Host determines whether RumorMill will let the newsfeed act as an upstream newsfeed. If this checkbox is not enabled RumorMill will reject attempts by this host to pass on articles. Note that if a newsfeed is marked as
Pull , then it cannot receive articlespushed from that newsfeed.
Note: A limited number of Newsfeeds can be specified (8 in v1.0, 16 in v1.1 and later version).
The Active Pull feature makes RumorMill pro-actively connect to the host and pull articles down (as if it were a news client). Active Pull cannot be used unless Accept Articles From This Host is enabled. This is a useful feature if you cannot organize for the newsfeed to push feed news, or your RumorMill server is not on a permanent link.
Please note that if you wish to host a large number of groups (more than a couple of hundred) you should probably arrange to be Push fed. When RumorMill pulls groups it intermittently checks with the Newsfeeds to see whether new articles have arrived. This causes unnecessary load on both RumorMill and the the Newsfeed. (And a significant amount of network traffic when large numbers of newsgroups are involved.)
Feed Articles To This Host determines whether RumorMill will attempt to forward new articles to this host. If this is not checked new postings will not be forwarded to the host.
When you add a new newsgroup RumorMill Setup automatically assumes you want all newsgroups defined in the Newsgroups window Pulled. To change this default behaviour click on the Edit Group List button.
The Group List window allows you control over specific newsgroups on a newsfeed by newsfeed basis. On the left is a list of groups associated with the current Newsfeed, the Group List, and on the right is the Master List, a full list of groups as defined in the Newsgroups window.
You can 'move' groups into the Group List from the Master List using the '<<' button. You can also add patterns to the group list which will match more than one group using the asterisk ('*') or question mark ('?'). For example, to match all groups in the alt hierarchy you could use the pattern:
alt.*
The question mark matches single characters. So the pattern:
al?.???
Would match with 'alt.sex', 'ala.aaa' and 'alt.six', but not with 'altt.aaa', 'alt.sixs' or 'blt.aaa'.
When you add a new group you can specify whether the server should Send the Group To the Newsfeeds, Exclude the Group From Being Received and Pull the Group From the Newsfeed. Note that this is a slightly different set of functions from the Newsfeed window, and it does not override the settings in the Newsfeed Entry window: if you do not have Pull enabled in the Newsfeed Entry window, no groups will be pulled even if they are marked as Pull in the Group List window.
That is all the configuration RumorMill requires. You can examine the Security, Site Restrictions, and Mail Gateway configurations, but you should probably Save your preferences back to the server using the Save menu command or command-S. The Save As menu option lets you 'transfer' preferences to another server, or save a backup to disk.
Load and Save operations can take some time, especially when there is a large group list. Once the group list is loaded RumorMill Setup only sends changes to the Group List to RumorMill. It does not attempt to ascertain whether the settings on the RumorMill Server have changed when it saves them, so it possible for RumorMill and RumorMill Setup to get out of step. Reload the preferences from RumorMill to update RumorMill Setup.
The Site Restrictions window lets you restrict which other machines have access to the server. Computers are restricted on the basis of their IP number. The server comes with a default mask permitting access by computers in the same subnet as the server (that is, the first three numbers in the IP number must match the server's).
For instance, if the server is at the IP number 1.2.3.4, then by default any client coming from a machine with IP numbers between 1.2.3.1 and 1.2.3.255 can connect to the server. A computer with IP number 5.6.7.8 would not be permitted to connect. The IP mask for this configuration is 1.2.3.4/255.255.255.0. (The mask makes a lot more sense if you consider it as a binary number: 255 is 11111111 in binary, 0 is 00000000. 255 means match all bits, 0 means match no bits.)
More complex masks can be used like, 127.2.3.4/1.255.0.255, which would match all IP numbers between 1.2.1.4 and 1.2.255.4, 3.2.1.4 and 3.2.255.4, 5.2.1.4 and 5.2.1.4 and so on (that is the first number is odd and the remaining three are between .2.1.4 and .2.255.4). The ordering of the IP masks is important: RumorMill starts at the top of the list and stops as soon as it finds a mask which specifically permits or denies the IP number. If it reaches the end of the list without specific reference the IP number is denied. Generally speaking more specific masks should be placed above more general masks.
RumorMill also adds a mask for each of the servers defined in the Newsfeed window (otherwise they would not be able to feed articles to RumorMill, and RumorMill would not feed articles to the Newsfeed). These masks will not show up in the Site Restrictions window because RumorMill generates them dynamically using a DNS lookup when it is run. That means that even if the server changes IP address RumorMill will (eventually!) allow it to connect (that is, as soon as RumorMill is reset).
Note:A finite number of Site Restrictions masks can be specified. The current maximum is 20.
The Site Restrictions window also allows you to check whether a particular IP number is permitted or denied using the Test IP number, which tests against the current list of masks.
Note that it is not possible to check against DNS names, for example, news.stairways.com, and use these to prohibit access. This is because DNS names can be 'spoofed' by other machines, that is pretented to be our example news.stairways.com, and thus DNS names are not secure way of restricting access.
Some Example Masks :
1.2.3.0/255.255.255.0/Permit: Allows all access in the C-Class domain 1.2.3
0.0.0.0/0.0.0.0/Permit: Permits everyone access
1.2.3.128/255.255.255.128/Permit: Permits everyone with an IP address of 1.2.3.128 or greater to connect.
0.0.0.1/0.0.0.255/Permit: Allows anyone with an IP adress who's last number is 1 to connect (eg 5.6.7.1, but not 5.6.7.81).
The Security Window allows you control over whether Rejected Messages are Logged. Messages are usually rejected for some kind of formatting error. Rejected messages are appended to a file called "Rejected Articles" when they are being logged. There is probably no reason to enable this feature unless you think the server is misbehaving.
Control Article Disposition lets you have some control over the creation and deletion of groups resulting from Usenet "control" articles. For an explanation of these controls see the General Advice section.
The Site Administrator password is only required when conducting remote configuration of a RumorMill Server. If the Site Administrator password has not been set, it is not possible to administer RumorMill remotely. When a password is set in the Security window it is not automatically set as the password for the current remote server (otherwise you could never change the password). You need to enter the new password in the Server Location window after updating the password. Note that the password in the Server Location window is stored locally in the file RumorMill Setup Preferences in the Preferences folder (as is the SIVC options in the Settings window).
The settings window provides access to a variety of settings to customize the behavior of your RumorMill server.
Expire Articles Time: Expiring articles is processor intensive, so it should be scheduled away from peak periods of server usage (usually sometime late at night).
Hold Articles: When an article is forwarded to the RumorMill Server without an explicit expiration date, RumorMill will expire it (delete it) after holding it for this period of time. Expiration periods can also be set on a per group basis, see also.
Maximum Number of Clients: Permits you to restrict usage of the RumorMill server, thereby constraining its impact on the server and your network.
Maintain minimum free disk space: Is a suggestion to RumorMill of how much disk space it should make sure is available on the volume(s) used for the various parts of the database (the database can be spread across multiple volumes by using aliases). This prevents RumorMill from filling the hard disk(s) and causing problems for other applications.
Note: It is possible for RumorMill to overrun the Maintain minimum free disk space setting, particularly if it is set to a small value (compared to the volume and size of articles being received).
Limit log file size: RumorMill maintains a running log of connections, errors detected, etc. This parameter is used to limit how large that log file may grow.
Server Port: For a variety of reasons you may wish to change the TCP/IP port RumorMill uses to communicate with clients (and RumorMill Setup). For instance, you may wish to run multiple copies of RumorMill with different configurations for each one. To change the port you need to change the this number, save the changes to RumorMill and then quit and Restart RumorMill. RumorMill will not change the port until you quit and restart the server.
Host Path Name: In some RumorMill installations, it's not possible to get a fixed IP address and/or an assigned host name. In this case, it's nice to have a host name to inserted into the "Path:" header. The value of this field is used in the Path: header, but only when no DNS name can be obtained.
Disconnect idle clients after: Sometimes you may find that clients connect to your server and remain idle for long periods of time. This can be prevented by specifying how long clients may remain idle before RumorMill disconnects them. A value of zero specifies that clients are never disconnected.
Help Note: Is only seen by NNTP Clients, it should not be seen by anyone reading articles. You should include an E-Mail address for other news administrators to contact in case of problems.
Enable Streaming for Sending: Selecting this option allows RumorMill to forward articles using the streaming protocol, but only if the downstream server permits streaming.
Enable Streaming for Receiving: Selecting this option allows RumorMill to receive articles using the streaming protocol.
Enable nightly expiration: This option can be used to totally disable nightly expiration processing. If disabled, no articles will ever be expired.
Hide the "control" group from users: Selecting this option tells RumorMill hide the "control" group so that users don't see it in their news reader clients.
EMail nightly statistics to Sys Admin: Selecting this option informs RumorMill to send an EMail containing the daily statistics to the System Adminstrator's EMail address. The System Adminstrator EMail address and the SMTP Host must be specified for this option to function.
EMail control articles to Sys Admin: Selecting this option tells RumorMill to send EMail copies of all control articles (attempts to delete or create news groups) to the System Administrator's EMail address. The System Adminstrator EMail address and the SMTP Host must be specified for this option to function.
EMail group changes to Sys Admin: By selecting this option, RumorMill will query each upstream newsfeed once a day for new groups. Groups created since the last query will be reported to the System Administrator in an EMail. This EMail will also list groups in RumorMill's database that are not in the database of the newsfeed. The System Adminstrator EMail address and the SMTP Host must be specified for this option to function.
Enable detailed logging: Use this option when you're having difficulties with RumorMill. With this option enabled, additional information will be placed into the RumorMill Log that can be helpful in determining the cause of problems. Detailed logging can be temporarily enabled or disabled by using the Detailed Logging item on RumorMill's File menu.
Enable server mode: Selecting this option tells RumorMill to not present any modal dialogs that might interrupt the processing in other applications.
Limit use of IHAVE to newsfeed hosts: Selecting this option prevents clients other than specified newsfeeds from using the IHAVE NNTP command. Selecting this option is highly recommended as one of the ways a System Administrator can limit spam.
Only forward local postings: Normally articles received by RumorMill (by any means) are automatically forwarded to downstream servers (subject to group specifications etc.). This preference allows the administrator to limit forwarded articles to just those locally generated (not received from other servers). This can be very useful when your copy of RumorMill is not used as a newsfeed to downstream servers, but you wish to have local postings forwarded to other NNTP servers.
Allow SIVC: Simple Internet Version Control should tell you when a new version of RumorMill is released. SIVC does not distribute any information about your computer - it just checks to see what is the latest version of RumorMill.
I Paid: Select this item once you've registered your copy of RumorMill (Thanks for registering!). Amoung other things, it disables the startup splash window.
Site Restrictions masks let you restrict where people can connect from. The Users settings let restrict who can connect, by giving users usernames and paswords.
The most important control in the Users window is the set of three Radio buttons at the top of the window. This lets you set whether your server is open to anyone, whether a password is required to post, or whether a password is required to even connect and read news.
The Users database can contain an arbitrary number of users. Each user has a setting associated with them which is 'Can Post'. Usernames are not case sensitive, but passwords are.
Note: Username are case insensitive, passwords are case sensitive.
If No Login Required is set, the user database is ignored. Anyone who connects can read and post, if such is permitted by the newsgroup (not permitted if the group is moderated).
If Login Required to Post is configured, then only users who have the Can Post checkbox can post. Clients which connect and do not have a valid Username and Password can still read.
If Login Always Required is set, then only those users configured in the Users database can read or post. Whether they can post depends upon the user by user setting.
In a school setting Login Required to Post may be enabled, and all the teachers could have Usernames. The teachers Can Post, while the students may only read.
Or alternatively, to restrict access to the server, each class group could be given a username and password with Can Post turned off. The teacher's each have Can Post enabled. Only students and teachers can access, and once again, only teachers can post.
RumorMill uses a database of news articles to increase speed and reduce disk usage. Occasionally this database will become corrupted (due, for instance, to a power outage). RumorMill usually autodetects when a database becomes corrupt and will rebuild the index information for the database. You can also force RumorMill to rebuild its database information by holding down control and option while launching RumorMill.
The rebuild process is, unfortunately, not completely well behaved at this time. During a rebuild RumorMill will seize your machine and not give it back (or only for brief moments) until it has finished. Note, a full database rebuild can take some hours: you may need to arrange to rebuild the database overnight.
When a user posts a new message to RumorMill, or an article is received from another server, the RumorMill will look through its list of Newsfeeds to see which servers it should attempt to forward the article on to. If those servers are not configured to permit RumorMill as an upstream newsfeed, they may reject the article.
You will need to ask the administrator of the downstream server to add your RumorMill server to the list of accepted servers. Note, that this is usually achieved by checking incoming connections against a list of server IP addresses. If you do not have a fixed IP address, the downstream server will probably not be able confirm RumorMill as a server. In this case RumorMill attempts to POST the article as if RumorMill was a client rather than a server. This generally works, but is less efficient than it would be otherwise, and definitely will not allow using the more efficient streaming protocol to move articles from your server to the downstream server.
If you carry a significant number of Newsgroups you should make sure you have plenty of disk space and a good connection. In our testing we found that about 60 (unexceptional) newsgroups took up 42 Mb of disk space, built up over a couple of days through a 28.8K (permanent) link. In one test, RumorMill built a database of over 200MB in less than 24hrs handling a mere 770 groups (there are in excess of 30,000 active USENET newsgroups). UNIX based NNTP servers that support "all" active USENET newsgroups typically require gigabytes of disk space and a permanent T1 link. RumorMill may be able to handle a full Newsfeed if it is running on a fast machine with a good (fast/wide SCSI) hard disk. However, a limiting factor is that RumorMill currently keeps all articles in a single MacOS file. Such files are limited to 2GB in size. We have not tested RumorMill with a full newsfeed.
RumorMill Setup should handle fairly large lists of Newsgroups, but it may be slow. If you wish to configure large numbers of groups, you may wish to do this using the Menu commands in RumorMill (Create Groups... and Save Groups...).
You will probably need a static IP address so that your newsfeed can be configured to send articles to RumorMill (make sure you have Accept Articles from this Host set in the Newsfeeds window). Pulling the Newsgroups takes a lot of time since RumorMill has to check each newsgroup to see if there are any new articles, every time. With a Push feed from an upstream Newsfeed, the articles are simply sent to RumorMill when they arrive and the more efficient streaming protocols can be used.
RumorMill can be used on a dial-up (intermittent) connection, to pull news for an individual or group. RumorMill has a menu command, Start Pull, which can be used to trigger the Pull. Note, depending on your network configuration you may need to quit and restart RumorMill once you have connected.
See also the section above on Propagating Articles Downstream.
Local Newsgroups are easy to make: give them a name which is not currently used on any other Newsfeed and it will not be propagated. Just to make sure no external news articles are fed into the local newsgroup you should probably add is as an Excluded group in the Group List of all the Newsfeeds. See also the section on Usenet Group names below.
RumorMill Setup can load and save preference files of type 'RMLS' and creator 'RMLS'. The files are plain text and they can be used to configure RumorMill, especially if a large number of groups or Users is involved. Try saving a the preferenes from your server into a file and editing it in BBEdit. Probably the quickest way to add a large number of Users is to add them using a preference file. For more information contact the maintainer of RumorMill Setup, Jim Calvin at <jcalvin@MacConnect.com>.
News servers have until recently been largely adminstered by very experienced computer users because the servers were awkward to configure and maintain, and there was whole body of etiquette which surrounded Usenet. RumorMill and servers like it, combined with the growth and interest in the Internet have changed the first fact: the servers are easier to configure and maintain.
But the etiquette of Usenet still remains, and exists for very good reasons.
If you intend to participate in distribution of Usenet articles, you should probably familiarise yourself with Usenet terminology and etiquette. A short glossary is included near the end of this documentation, in case you are unfamiliar with the terms used the following sections.
et i quette :n. the conduct or procedure required by good breeding or prescribed by authority to be observed in social or official life
Usenet is a big place, which has been going for a long time, and it involves a lot of people. There are on the order of thirty thousand newsgroups and more are added daily. Topics of discussion touch on ... well, pretty much everything. At a conservative estimate, over 10 million words are exchanged every day. Usenet is a place where people socialize, exchange opinions, and argue.
Because Usenet is a mix of such diverse people and opinions, users and administrators must be exercise tolerance and restraint. It is also a text medium where it is easy to misunderstand or misinterpret people's words and intentions.
So etiquette is important: good etiquette helps smooth out social interaction, and as an administrator you will be called to enforce rules of etiquette, and to judge when people have breached Usenet etiquette. If you do not, administrators who propogate news to you will be called on to enforce restrictions to your site.
No one is asking you to be superhuman, but there is a need to understand the social rules which surround the technology of Usenet.
There are many fines guides on the subject. The Usenet Frequently Asked Questions lists from the newsgroup news.answers are a good place to start. You can access these via FTP from MIT:
<ftp://rtfm.mit.edu//pub/usenet/news.answers/>
You should encourage users who haven't used Usenet before to read the newsgroup news.announce.newusers and news.newusers.questions, which contains good introductory information including the famous Emily Postnews questions.
RumorMill requires you to use Usenet group names if you wish to receive news from, or send news to a Usenet newsgroup. Usenet group names must be all lower case, they can use the alphanumeric character (a-z, 0-9), plus the following special characters:
. - _ +Newsgroup names are usually dot seperated, eg:
rec.humor.funnyUsenet group names usually belong to a fairly small number of basic hierachies. Even if you intend to run local newsgroups you would probably do well to put them inside a 'local' hierachy, so for instance you might have:
local.announce local.talk local.project.frisco local.project.zeta local.newsFinally, when you accept news from outside keep in mind the following, which is quoted from the news.answers Usenet FAQ:
Usenet newsgroups are named for mostly historical reasons, and are not intended to be fully general discussion groups for everything about the named topic. Please accept this and post articles in their appropriate forums.
Request For Comment 977 and RFC 1036 are the basic RFCs for the NNTP protocol. These documents list the commands which are sent back and forth between the server and the client, and between servers. These should only be necessary for software authors, but as an administrator you may find it useful to have some idea how articles are formed and propogated.
RFCs are available on the web and at many quality FTP sites. Try:
< http://andrew2.andrew.cmu.edu/rfc/rfc-front.html>
Other places to look for internet drafts are:
Africa: ftp.is.co.zaEurope: ftp.nordu.net
ftp.nis.garr.itPacific Rim: munnari.oz.au
US East Coast: ds.internic.net
US West Coast: ftp.isi.edu
RumorMill supports a few features which are not supported in RumorMill Setup. It is possible to access these features using a telnet client.
It is possible to telnet directly RumorMill to configure commands not currently supported by RumorMill Setup. This section will not cover the commands: more information is available on our web site.
We recommend using Nifty Telnet (or the like) rather than NCSA Telnet because NCSA Telnet sends a series of characters when it opens a connection which will cause the first command to return an error.
To connect to the RumorMill server, telnet to port 119. (In Nifty Telnet simply enter my.host.name:119 as the hostname, substituting the appropriate DNS name.) If you are connecting remotely you will need to enter the 'xpass mypass' command, where mypass is the password you have previously configured by connecting to RumorMill locally (either using a telnet client or RumorMill Setup).
After that you can issue the 'help' command and explore. Most preferences are listed using 'xpref list' or 'xpref get', and are set using 'xpref set'. Note: RumorMill can run on an arbitrary port, so it is possible that if someone else has already configured RumorMill and it is no longer running on port 119.
For additional information, see the RumorMill web site or, these other sites that have mirrors of Stairways Software:
Articles can have headers like "Control: " and "Also-control: " in them. These header lines can contain directives to create (newgroup) and delete (rmgroup) newsgroups. The "Control Article Disposition" in the Security window determine whether or not these control directives are executed when the articles are received, deferred for the administrator to review, or completely ignored. Since any knowledgable user with permission to post articles to your server, or at a server that you receive articles from, can create a control article, it is recommended that you choose the "Administrator Approves" options.
At present, in the Administrator Approves mode, there is no way to view the messages from RumorMill Setup; they can only be viewed and executed using the Execute Deferred Articles command in RumorMill.
OVERVIEW.FMT is user definable. Create a STR# resource in the RumorMill preferences file called "OVERVIEW.FMT". The format is one header per entry. The header should include the ":". If you want the "full" option, append an "*" to the header string.
RumorMill supports the "LIST SUBSCRIPTIONS" command by allowing the system administrator to place a text file called "Subscriptions" in the RumorMill Database folder. This file is transferred verbatim to the client when the "LIST SUBSCRIPTIONS" command is issued. Some news reader clients will look for this information when configuring for a new user. The information in the Subscriptions file should normally be a list of groups that the news reader should automatically subscribe to for the new user.
RumorMill 1.2 and later support moderated Newsgroups. To fully utilize this support, each moderated group must have a newsgroup submission EMail address listed with each moderated group. A submission EMail address can be specified as part of the group creation or editing process.
The Create Groups command is used to create groups in RumorMill by reading an existing text file of group names. Text files created by hand should have one group name per line. Files created by the Save Groups have a more complex format and add information such as group description and moderated groups's EMail submission address.
Save Groups writes a text file containing the current groups in RumorMill's database. The file written also contains group descriptions, EMail submission addresses for moderated groups, etc. so that the group database can be fully restored using the Create Groups command.
The Create Users command is used to restore the user database from a file written by the Save Users command.
The Save Users command writes a TEXT file can be used with the Create Users command to restore the user database.
Some posted articles contain information that news servers use to maintain or convey directives between servers. Such articles contain headers such as Control:, Also-Control:, or Supersedes:. RumorMill is capable of interpreting some of these directives, particularly those that will add or remove groups, supersede older messages, and cancel messages (SPAM or otherwise). Depending upon various preference settings, RumorMill may not take immediate action on the directives when they first arrive. The Execute Deferred Messages command will cause RumorMill to process the directives and, in some cases, present the articles to the user and ask whether the directive should be performed, deferred, or discarded.
Possible actions for deferred control articles
Execute Perform the function described in the article shown. Defer Perform no action at this time, but retain the article. Forget Peform no action on this article and do not consider the article again. Stop Discontinue processing deferred articles.
RumorMill normally performs database expiration at a regularly scheduled time. However, there maybe times when the System Administrator would like to force the expiration process to happen immediately. The Expire Database command is provided for that purpose.
RumorMill databases are only periodically compacted. RumorMill will reuse the disk space, but it will not immediately release the space to be used for other files. The Compact Database command will walk through each selected database reading each active record and copy it to a new file. When the copy process is completed, the old database will be deleted and the new copy renamed to replace the original database. This process does release unused disk making it available for other uses.
However, the Compact Database command requires sufficient disk space to create a second copy of each database selected for compaction (in series, not all at once). If disk space is exhausted, or some other error occurs, the compaction process will be aborted and the database currently being processed will remain as it was before compaction started.
If sufficient disk space is available, RumorMill will periodically (on average, about every fourth day) compact the database when performing its normal expiration process. However, if you're using RumorMill as a private server and never allow expiration to take place, using the Compact Database command will be useful to limit the size of the RumorMill database.
The Discard Existing Database command deletes all current databases. The command will offer the opportunity to save user and group information before the databases are discarded. It is necessary to restart RumorMill after using this command.
This menu item allows the user to temporarily enable or disable detailed logging. Detailed logging writes extra information to the RumorMill Log file that can be very useful when attempting to debug a problem using RumorMill. Using this command only has effect during the current session (that is, until RumorMill is restarted).
Upstream servers can be marked as "Pull," and periodically RumorMill will attempt to contact the server to retrieve articles. The Start Pull command will immediately attempt to connect to "Pull"s servers rather than waiting for the next scheduled interval.
The Quit command will exit from RumorMill. This command will cause all existing connections to RumorMill to be disconnected.
article n. A posting to a newsgroup . Articles following a common subject are said to be in the same thread [of conversation].
cross-post [Usenet] vi. To post a single article simultaneously to several newsgroups. Distinguished from posting the article repeatedly, once to each newsgroup, which causes people to see it multiple times (which is very bad form). Gratuitous cross-posting without a Followup-To line directing responses to a single followup group is frowned upon, as it tends to cause followup articles to go to inappropriate newsgroups when people respond to only one part of the original posting.
DNS name n. Literally Domain Name Server name. A DNS name usually identifies a single computer or service - it is like a Post Office box in the real world. DNS names are mapped by Domain Name Servers to an IP address which is then used to route information to that computer.
downstreamn. A news server which is downstream from your news server is fed articles from your news server, ie it is one of the places to which your news server sends articles. Two news server can be both upstream and downstream relative to each other.
host n. Another server on the network. For instance a 'news host' is computer on the network which provides news (NNTP) services.
IP number n. An Internet Protocol number uniquely identifies a computer somewhere in the world. IP numbers are used to route information to a computer and identify them the computer on the network.
A computer can have multiple IP numbers but it is relatively rare to find multiple computers to have the same IP number. (An exception is when there is a Redundant Array of Inexpensive Computers which can service heavy loads through a single entry point.) A DNS (Domain Name Server) maps DNS names to IP numbers.
newsfeed n. Another NNTP server which feeds articles to, or receives articles from other NNTP servers. Often refers to a source of Usenet news. Newsfeed, 'news server' and host can all be used interchangeably in the correct context.
newsgroup n. [Usenet] One of Usenet's huge collection of topic groups or forums. Usenet groups can be `unmoderated' (anyone can post) or `moderated' (submissions are automatically directed to a moderator, who edits or filters and then posts the results). Some newsgroups have parallel mailing lists for Internet people with no netnews access, with postings to the group automatically propagated to the list and vice versa. Some moderated groups (especially those which are actually gatewayed Internet mailing lists) are distributed as `digests', with groups of postings periodically collected into a single large posting with an index.
NNTP n. Network News Transfer Protocol. This is the protocol that servers (such as RumorMill) use to talk to each other, and clients (such as Newswatcher) use to retrieve and post articles. NNTP is plain-text and human readable, even if it is a little cryptic at times.
push feed n. Large newsfeeds are usually propagated by push feeding. When a new article arrives on a news server (either by someone posting to the news server or another news server feeding it an article) it can propagate the articles by looking up a list of other news servers it is meant to transfer articles to, connecting to them, and telling them the new article has arrived. RumorMill supports push feeding. See also pull.
pull v. RumorMill can act like a client, connect to another NNTP server and pull articles form the news server.
This is also known in the community as a "suck feed." It's weird, but apparently some folks think of "pull" as an inefficient implementation while a "suck" is efficient. This must date back to someone's implementation that did "pull" badly and another one that did "suck" well (or at least better). I must say that I prefer the word "pull" to "suck" ...
See also push feed.
server n. A server is a computer or piece of software which provides a service. Usually humans use servers through another piece of software generically called a 'client'. For instance RumorMill is a news server, and to read news of a RumorMill you use a news client (like Newswatcher). Web Servers provide web services, which a human can use through a web client (like Netscape).
spam n. An article which is posted to a large number of news groups, usually with little relevance to the most of the newsgroups. Typical spam postings are adverts and Make Money Fast pyramid schemes. Spam is usually more of an annoyance than a problem, but it should definitely be discouraged.
subject n. A single line which should (but often doesn't) summarise the topic of an article in a newsgroup.
thread n. As in a 'thread of conversation'. A thread is usually a series of articles in a newsgroup with the same subject line or topic.
upstream n. A news server which is upstream from your news server feeds articles to your news server, ie it is one of the places from which your news server receives articles. Two news server can be both upstream and downstream relative to each other.
Usenet n. [from `Users' Network'; the original spelling was USENET, but the mixed-case form is now widely preferred] Usenet was originally created in the late 1970s as a "poor man's ARPAnet", to distribute news about the Unix Operating System. It has since grown to include over 30,000+ separate newsgroups about many different topics. Some newsgroups are "moderated" so that messages have to be approved before anyone can read them, but most newsgroups are unmoderated. In an unmoderated newsgroup, anyone can place messages, and anyone can read them. Most messages are replies to other messages, and thus an endless discussion is formed. Posting to a newsgroup is not unlike writing email.
The Internet is the main medium for the distribution of Usenet News, but it wasn't always so. UUCP used to be the most common way to transfer Usenet, and it is still in use today. All that is required to run a news server is some computer hardware and a "Usenet Feed." Getting a Usenet feed is as simple as asking an existing Usenet site. Any site can feed or be fed by any other site, and thus it is practically impossible to control.
RumorMill is Shareware, which means if you use it, you must pay for it. A single user license costs US$35. After you have confirmed your registration in RumorMill the Startup splash screen will disappear.
You can pay in one of two ways: on-line registration using a web browser, or off-line registration using the Register program.
Our online registration can be found at:
<http://order.kagi.com/?PL>
Or, using the Register program, you need to:
1. Get hold of a copy of the Register program: Register comes with the RumorMill distribution. You can also get Register from the following sites:
<ftp://ftp.stairways.com/>
<ftp://mirrors.aol.com/pub/peterlewis/>
<ftp://ftp.amug.org/pub/peterlewis/>
..or there are download links on the following Web page:
<http://www.stairways.com/register/topay.html>
2. Run the Register program and fill out the form: You need to enter your name, email, postal address, and the shareware you wish to pay for. The form accepts many different payment methods such as: US Check, Money Order, Cash (in many different currencies), Visa, Mastercard, American Express, First Virtual, and Invoice (to be given to your accounts payable department).
3. Send it to Kagi Shareware: Then either email the data generated by the registration program or print it and send it via postal mail or fax. Credit card information is encoded by the Register program.
The address to send the completed form is output by Register when you Print or Copy the completed form. The addresses are:
Email: shareware@kagi.com
FAX: +1 510 652 6589
Snail-mail:
Kagi Shareware
1442-A Walnut Street #392-PL
Berkeley, California, 94709-1405
USA
You may distribute this program any way you wish as long as you don't charge for it (reasonable download costs such as Compu$erve are ok (although who would call Compu$erve's download costs reasonable?)). You must distribute the package in its entirety. We don't guarantee any support, but we always answer our Email. If we don't answer Email it is because your message didn't get to us, or our reply bounced, so please try again and include a valid Internet address if you can.
You MAY NOT DISTRIBUTE this program on any disk or CD without our explicit permission.
Australians may pay in Australian dollars direct to us if they prefer.
World-wide license: US$2000
Universities or companies site license: US$500
Curtin University and the University of Western Australia are exempt.
A site license covers usage of RumorMill on an unlimited number of machines within 100 miles of some arbitrary central point which are owned by the licensed organization. (A site license will not be useful unless you intend to run more than 14 copies of RumorMill.)
World Wide licenses remove the 100 mile radius restriction.
This program should do what is described in this document. If it doesn't, you can simply stop using it. If you paid for the product, and within a year find that it doesn't do what has been described here, then you can notify Stairways Shareware and your money will be refunded and your license cancelled.
Peter Lewis hereby disclaims all warranties relating to this software, whether express or implied, including without limitation any implied warranties of merchantability or fitness for a particular purpose. Peter Lewis will not be liable for any special, incidental, consequential, indirect or similar damages due to loss of data or any other reason, even if Peter Lewis or an agent of his has been advised of the possibility of such damages. In no event shall Peter Lewis be liable for any damages, regardless of the form of the claim. The person using the software bears all risk as to the quality and performance of the software.
US GovernmentGovernment End Users: If you are acquiring the Software and fonts on behalf of any unit or agency of the United States Government, the following provisions apply. The Government agrees:
(i) if the Software and fonts are supplied to the Department of Defence (DoD), the Software and fonts are classified as "Commercial Computer Software" and the Government is acquiring only "restricted rights" in the Software, its documentation and fonts as that term is defined in Clause 252.227-7013(c)(1) of the DFARS; and(ii) if the Software and fonts are supplied to any unit or agency of the United States Government other than DoD, the Government's rights in the Software, its documentation and fonts will be as defined in Clause 52.227-19(c)(2) of the FAR or, in the case of NASA, in Clause 18-52.227-86(d) of the NASA Supplement to the FAR.
Jim's Acknowledgements
Thanks to Ellen for her patience and support while I worked on RumorMill. Thanks to Peter for the opportunity and to Jeremy for chasing too many bugs.
Jim Calvin, author of RumorMill.
Jem's Acknowledgements
Thanks to Peter for his patience and support. Thanks to Jim for putting up with my amateur efforts: I hope people won't be put off by RumorMill Setup!
Jeremy Nelson, author of RumorMill Setup.
[ Home | Subject Index | Feedback ]