Network Working Group Moderators-advice Request for Comments: XXXX Sometime 1994 Category: Informational NetNews Moderator's Handbook Status of this Memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Abstract This document provides information concerning moderation of NetNews newsgroups. It describes the moderator-specific formats and usage for articles posted to such newsgroups and generic practices common to all moderators and newsgroups. It does not establish rules but is a general framework of accepted practices used by NetNews moderators. The goal of this document is to explain the practices currently in use for the benefit of new and existing moderators. moderators-advice [Page 1] RFC XXXX NetNews Moderator's Handbook Sometime 1994 1. Introduction ........................................... ?? 2. What does 'moderated' mean ? ........................... ?? 3. Why do USENET moderated newsgroups exist ? ............. ?? 4. Role of a moderator .................................... ?? 5. How the moderation process works technically ........... ?? 5.1. Mailpath usage ....................................... ?? 5.2. Standard News Header Usage ........................... ?? 5.2.1. Approved: Line ..................................... ?? 5.2.2. Date: Line ......................................... ?? 5.2.3. Distribution: Line ................................. ?? 5.2.4. Expires: Line ...................................... ?? 5.2.5. Followup-To: Line .................................. ?? 5.2.6. From: Line ......................................... ?? 5.2.7. Keywords: Line ..................................... ?? 5.2.8. Newsgroups: Line ................................... ?? 5.2.9. Path: Line ......................................... ?? 5.2.10. References: Line ................................... ?? 5.2.11. Reply-To: Line ..................................... ?? 5.2.12. Subject: Line ...................................... ?? 5.2.13. Other informational headers ........................ ?? 5.3. Other headers that should be removed before posting .. ?? 5.4. Signatures ........................................... ?? 5.5. Creating newsgroup specific headers .................. ?? 5.6. Receiving Submissions ................................ ?? 5.6.1. Articles posted to a moderated group ............... ?? 5.6.2. Emailed submissions ................................ ?? 5.7. Adding moderator comments ............................ ?? 5.8. Submitting articles .................................. ?? 5.9. Canceling articles ................................... ?? 5.10. Where to find other documentation on moderation ...... ?? 6. What are the different types of moderated groups ? ..... ?? 6.1. Announce groups ...................................... ?? 6.2. Binary groups ........................................ ?? 6.3. Digests .............................................. ?? 6.4. Discussion groups .................................... ?? 6.5. Source groups ........................................ ?? 7. Setting up a new moderated group ....................... ?? 7.1. Submission aliases ................................... ?? 7.2. Email submission servers ............................. ?? 8. Choosing a moderation policy ........................... ?? 8.1. Article rejections ................................... ?? 8.2. Copyrights ........................................... ?? 8.3. Dealing with forged Approved: headers ................ ?? 8.4. Commercial postings .................................. ?? 8.5. Dealing with cross-posted articles ................... ?? moderators-advice [Page 2] RFC XXXX NetNews Moderators' Handbook Sometime 1994 9. Backup moderators ...................................... ?? 10. Multiple or Team Moderation ............................ ?? 10.1 Team moderator mailing lists .......................... ?? 10.2 Facilitators .......................................... ?? 10.3 Rejection Notices ..................................... ?? 10.4. Multiple moderator conflict resolution ............... ?? 11. Handling temporary moderator absences .................. ?? 12. Gatewaying your newsgroup to mailing lists ............. ?? 12.1. Newsgate ............................................. ?? 12.2. Listserv ............................................. ?? 13. Creating Periodic Informational Postings ............... ?? 13.1. Copyright ............................................ ?? 13.2. Frequency of distribution and news.answers ........... ?? 14. Archiving postings to the group ........................ ?? 14.1. FTP Archives ........................................ ?? 14.2. Email Archives ...................................... ?? 14.3 Archives of selected articles ....................... ?? 15. Tools for moderators .................................. ?? 16. News transport gotcha's ................................ ?? 16.1. Line lengths ........................................ ?? 16.2. Old C News blanks-in-ng bug ......................... ?? 16.3. B News non-local unapproved articles bug ............ ?? 16.4. Article size concerns ............................... ?? 16.5. Amount of messages posted daily ..................... ?? 16.6. Cross-posting to other moderated groups ............. ?? 16.7. Extra headers on directly posted articles ........... ?? 16.8. Multiple copies of the same submission received ..... ?? 16.9. B News static Newsgroups: header limit .............. ?? 17. How to deal with your readership ....................... ?? 17.1. Personality of your group ........................... ?? 17.2. Deciding a course of action ......................... ?? 17.3. Community perceived problems with moderation ........ ?? 17.4. Vocal minority ...................................... ?? 17.5. Anonymous postings .................................. ?? 18. Answers to general questions ........................... ?? 18.1. How big is my group's readership ? .................. ?? 18.2. What mechanisms guard the group from unauthorized "Approved:" headers ? ............. ?? 18.3. Have any moderators gotten paid for what they do ? .. ?? 18.4. Why are readers complaining of lost articles ? ...... ?? 19. Passing the torch ...................................... ?? 20. Acknowledgments ........................................ ?? 21. Security Considerations ................................ ?? moderators-advice [Page 3] RFC XXXX NetNews Moderators' Handbook Sometime 1994 22. Author's Address ....................................... ?? Appendix A: USENET Newsgroup Moderation ................... ?? A.1. Discussion lists for USENET moderators ............. ?? A.1.1. moderators-advice ............................... ?? A.1.2. moderators ...................................... ?? A.2. Changing moderators ................................ ?? A.3. USENET moderator replacement concerns .............. ?? A.4. Group Charters ..................................... ?? A.5. Submitting articles thru public USENET Mail/News gateways ................... ?? Appendix B: Canned Messages ............................... ?? B.1. C News Duplicate headers message template .......... ?? B.2. Thanks for FAQ comments ............................ ?? B.3. Inappropriate submission ........................... ?? B.4. Get a Clue ......................................... ?? B.5. Test elsewhere ..................................... ?? Appendix C: Tributes ...................................... ?? moderators-advice [Page 4] RFC XXXX NetNews Moderators' Handbook Sometime 1994 1. Introduction The purpose of this document is to assist new and existing moderators in understanding what is involved in moderating a newsgroup. This document contains information about how the moderation process works, how to get started, where to get existing moderation posting software, what NetNews related problems moderators may encounter, and where to get additional help if needed. In the past, most moderators learned on-the-job, and there was not much documentation available about what was expected of a moderator. This document attempts to aid new moderators in understanding what it is that they have gotten themselves into. This document will also be useful to those wishing to volunteer to be a moderator. Within this document, USENET refers to the traditional core hierarchies of comp, misc, news, rec, sci, soc and talk. The term 'Network News' (or 'NetNews') refers to all hierarchies that use the same transport and reader mechanisms that the traditional core hierarchies do. Moderation of newsgroups is transcending the traditional core USENET news hierarchies as many organizations begin using NetNews software for internal use. Also, many non-core hierarchies, such as alt, biz, bionet, etc., contain moderated newsgroups. It is the intent of the author that this document also be of use to those who are not USENET moderators but are moderating NetNews newsgroups nevertheless. It is expected that readers of this document are already familiar with NetNews, at least from a user's perspective, and have been exposed to network tools such as FTP. A complete explanation of NetNews jargon and culture is beyond the scope of this document. 2. What does 'moderated' mean ? 'Moderated' means that all postings to the newsgroup go to a mail address (e.g. comp.std.unix@uunet.uu.net) instead of appearing in the newsgroup directly. The postings are then forwarded via email to a moderator, or group of moderators, or even an automated program, who decides whether to actually inject the article into the newsgroup or to reject it as not meeting guidelines spelled out in the group's charter. The main purpose of newsgroup moderation is to prevent inappropriate posts to the newsgroup. For example, moderation can prevent discussion or requests for software from appearing in groups dedicated to posting source code. It can also be used to facilitate discussions, to create a forum for announcements, to prevent repeated posts of the same information, or to cut off endless uninformative arguments. Some groups, e.g. rec.humor.funny and some source groups, also use it to control the traffic volume. Moderation should not be used to censor unpopular viewpoints, or those that the moderator simply disagrees with. It is best to have a very clear charter and moderation policy for the newsgroup, so that newsgroup readers and posters can tell which topics are, or are not, appropriate for discussion on the newsgroup. 3. Why do USENET moderated newsgroups exist Groups on the net are moderated for a variety of reasons. All moderation serves the same basic purpose, to filter out inappropriate postings and to deliver timely, on-topic articles. Most moderated groups fall into one of five general categories: 1) Groups with postings of an informative nature not suited to discussion and always originating from the same (very small) group of posters. Groups within this category include news.lists, news.announce.newusers, and comp.mail.maps. 2) Groups derived from regular groups with such a high volume that it is hard for the average reader to keep up. The moderated versions of these groups are an attempt to provide a lower volume and higher quality version of the same forum. An example of this category is news.announce.newgroups (a reduced form of news.groups). 3) Groups derived from regular groups that have often been abused. That is, the regular groups often received postings of items that were not germane to the stated topic of the group (or sometimes even within the realm of politeness for the net). This also includes groups suffering from an annoying number of duplicate postings and inappropriate followups. Moderated groups in this category include comp.sources.misc. 4) Groups designed to serve as direct feedback to an off-the-net group. The discussion in comp.std.mumps is an example of this. 5) Groups that are gatewayed into USENET from an Internet mailing list. These groups are moderated by someone on the Internet side but are shared with the USENET population. Submissions mailed to the proper addresses, given below, will appear in both the group on USENET, and the Internet list. This includes some groups in the "inet" distribution such as comp.ai.vision and rec.mag.fsfnet. 4. Role of a moderator Moderating a newsgroup is a volunteer effort but it carries certain responsibilities. The role of a moderator is to review, approve and post articles relevant to a newsgroup according to the group's charter or guidelines. If an article does not qualify for posting, it is to be sent back to the author with an explanation of why it is not suitable for posting. Depending on the nature of the group, acceptable turnaround time can range from a few days to a few weeks. If posts accepted for the group have a long delay before being actually posted, as happens with moderated net magazines, it is a good idea to let the submitter know that the post was accepted, and what the approximate posting date will be. 5. How the moderation process works technically This section contains technical information about the news mechanisms of concern to newsgroup moderators, including standard news headers, dealing with submissions, and generating special purpose headers to better serve your newsgroup. A moderated newsgroup is marked as such in the news transport software (most often with a trailing "m" flag in the active file of news systems). What this means is that articles must be approved before they are accepted in the group. When an article is posted to a moderated group, the news transport software will mail the article to the moderator [See Section 5.1 Mailpath Usage] for approval and actual injection into the news system. Once the moderator has received a submitted article in the incoming mailbox, (and if necessary has edited the article's content) the moderator needs to process the article's headers a bit before actually posting it to the group. The descriptions below explain usage of the various headers. Technically, all that the moderator has to do is add an "Approved" header, and repost the article. The only thing that differentiates an "approved" from a "non-approved" posting is the existence of the "Approved:" header. The news transport will then accept it and transfer it to other machines. New moderators, especially those not familiar with news mechanisms, may need to refer back to the list of standard news headers (Section 5.2) often as they familiarize themselves with the moderation process. 5.1. Mailpath usage When a net.citizen posts a message to a moderated newsgroup, the news software looks up the moderator's submission address. The software then mails the unapproved article to the moderator for approval and injection into the news system. To make this work the mailpaths file is used on B News or C News systems. INN uses the moderators file and the inn.conf file to provide the same functionality. The list of moderator addresses can change almost daily and trying to keep up with it can be a job in itself at times. For that reason the mailpaths file can be configured to send all unapproved submissions to moderated newsgroups to a site which has volunteered and been approved as a mail forwarder for USENET moderators. In almost all cases it is best to configure news software to forward unapproved articles to one of the established mailpath forwarders. David Lawrence maintains the periodic posting "How to Construct the Mailpaths File" It describes the syntax of the contents of the file and how to construct it for your B News or C News system. It also lists the sites that are maintaining a current listing of moderator addresses and are acting as mail forwarders for the USENET moderator infrastructure. The article is regularly posted to the newsgroups news.lists, news.admin.misc and news.answers. 5.2. Standard News Header Usage Articles posted to moderated newsgroups, like all other news articles, must conform to the article specifications of the USENET news system, as described in RFC 1036. The list below explains the standard news headers as they pertain to moderating USENET newsgroups, though if there is any doubt about the specifications of a particular header RFC 1036 should be consulted. [See Section 5.10 for more information on obtaining RFC 1036 and other NetNews related RFCs and doucments.] There is no preferred order of headers. Compliant software should accept the articles with the following headers in any order. 5.2.1. Approved: Line Any article posted to a moderated newsgroup must contain an Approved: line. Always sign the approved line with your electronic address. The software won't care what is here, but in case something goes wrong, the community will know who approved the article. Some moderators sign the Approved: line with the moderator's submission address, so that any comments-to-the-moderator tend to get routed into the moderation mailbox. A sample Approved: line: Approved: kent@sterling.com (comp.sources.misc) If an article has been approved by the moderators of different moderated groups, the moderator with final approval should try to put the other moderators on the Approved: line as a way of documenting that it was approved to appear in multiple groups. A sample Approved: line marking approval in more than one group: Approved: kent@sterling.com, tale@uunet.uu.net While showing multiple approval is not required, it is informative to the readership and common courtesy to the other moderator(s) to do so. [ Beware of approving cross-posted articles. Refer to "Section ] [ 5.2.8 Newsgroups: Line", "Section 8.5 Dealing with cross-posted ] [ articles" and "Section 15.6. Cross-posting to other moderated ] [ groups" for a discussion of the problems. ] 5.2.2. Date: Line Strip the Date: header from submitted articles, or change it into something like X-Original-Date:. Do not include an X-Original-Date: header without a good reason. For example, an article might refer to "today's New York Times", or might mention software "uploaded to an FTP site today. Proving your timeliness isn't a good reason unless, for some reason, it has been in question. The problem with keeping the original Date: header is that it might badly confuse the news posting software, or some latency could cause the article to be unnecessarily rejected at sites, especially when the date was completely wrong. 5.2.3. Distribution: Line The Distribution: header should be stripped from any submitted article. You should try not to post things of a definite local nature to world-wide groups with the current state of network news propagation. Unfortunately, using the Distribution: header rarely produces the intended or desired results. An article posted with a restrictive Distribution: header is almost certain to be propagated far beyond the intended area, and will be equally likely to miss some sites that would be interested in that region's news, and might even be physically located in the intended target zone. In addition, many articles are posted with "na" (North America) or "usa" (U.S.A.) distributions because of poorly-thought-out software defaults, rather than any conscious decision by the poster. Many non-North-American readers are annoyed by this needless limitation on what news reaches them. In theory the distributions work as intended, but in practice, due to lack of verification by posting agents, misconfigured news transport agents, wide-area sites which pick up all news regardless of distribution, and inadequate controls on the names of the distributions, they are relatively useless. 5.2.4. Expires: Line Moderators should consider adding an Expires: header if the information being posted has a limited period of usefulness. For example, a Call For Papers (CFP) posted to the group news.announce.conferences might be valid only until a certain date. The Expires: header can then be set to expire the article the day after the deadline specified in the CFP. Many sites with limited news retention times keep articles with explicit Expires: headers online longer than the default time period, so an Expires: header can help keep periodically posted information readily available to readers at all times. Your use of the Expires: line should be documented in your group's periodic policy posting. 5.2.5. Followup-To: Line If you have a policy of directing all followups to the article submitter, or if the submitter requests it, use the header line Followup-To: poster The news reader software will then email followups to the address listed in the Reply-To:, and if non-existent, to the From: address. In some cases it might be appropriate to place the name of an unmoderated discussion group in this header. For example: Comp.sys.amiga.announce does not carry any discussions. Most articles there contain the line Followup-To: comp.sys.amiga.misc With this header, when a reader with compliant news software tries to followup to an article appearing in the group, their article is actually redirected to the unmoderated discussion group comp.sys.amiga.misc. The appropriate use and content of this header are very dependent on the community of readers that the newsgroup is serving. Note that it is never correct to put an actual email address in the Followup-To: line. 5.2.6. From: Line Postings to newsgroups should have a From: line that refers to the submitter, unless the posting is a digest, in which case the From: line should be that of the compiler of the digest. Since most news readers display From: line information, it is appropriate to accurately depict who the article's content is "From", when possible. 5.2.7. Keywords: Line Keywords: lines should be included as received in the posted article. Some moderators may want to add a Keywords: line if it doesn't already exist. Some moderators have added "SPOILERS" to the Keywords: line in articles posted to movie or book discussion groups if the article gives away the ending. Some moderators have a list of all of the keywords used in the group and adjust the Keywords: line as needed. Limiting the set of keywords makes keyword searching a lot easier and avoids problems with synonyms and variant spellings. Keywords: should augment rather than replace keyword usage on the Subject: line because, unfortunately, some news reader programs cannot use Keywords: to auto-select articles. 5.2.8. Newsgroups: Line If the moderator receives a request to cross-post an article to multiple groups, and the moderator has a policy of honoring cross-posting requests, the moderator should try to comply with the poster's specification if the other groups make sense and are not moderated. If the submitter requests cross-posting to newsgroups that the moderator cannot post to, the submitter should be so notified, unless there is a clear policy statement covering this inability. For example, users at many sites cannot post or cross-post articles to any alt groups. If one or more of the other requested groups are moderated, the moderator can either inform the submitter that the article is being cross-posted to only unmoderated newsgroups or coordinate with the moderator(s) of the other group(s). Leave the final decision of what is relevant on other newsgroups with moderators for those newsgroups. Due to the nature of existing news software, an article cross-posted by a moderator to multiple moderated newsgroups appears in all the specified moderated groups without requiring the further approval of the other moderator(s). A posting of this type will probably surprise and may even anger the other moderator(s) if the article posted violates the charter of the other moderated newsgroup(s). 5.2.9. Path: Line The original Path: line should be removed and the news system should be allowed to generate a new one. The purpose of the Path: line is to show the path that the article took since being injected into the news system. Since the moderator is the one that actually injects an article into the news system, any previous Path: line should be discarded before the moderator posts the article. Also insure your news transport software generates a non-replyable Path: line. For example: Path: host!not-for-mail This allows it to be propagated back to the site it came from. It also assures that mail from seriously broken news sites is not returned to you. New moderators shouldn't need to worry about this. If there is not a Path: line in an article, most news transport software generate one similiar to that shown above. 5.2.10. References: Line The References: header is used by some threaded newsreaders to chain a set of articles together. It allows a discussion thread or multi-part posting to be dealt with as a unit. The second and and subsequent articles in a set should include a References: header. News reader software needs to be able to reconstruct the article tree even if (a) the root article is missing, such as the article has expired, (b) the immediate predecessor is missing as in a cancelled article. The software must do this based solely on information from the References: headers of existing articles. Other approaches, eg. keeping a separate history in something like trn's mthreads database, have more or less failed because of the high load on the server and the application-specific data format. There are different ways the References: headers is used today to support threading depending on the article flow in the moderated group. If articles are posted so that all linked articles are posted in sequence and within a short period, such as is done in sources groups, then References: headers can be constructed with a minimualist method. Otherwise, groups where referenced articles are not in sequence or are posted days apart should use the standard References: header usage. The standard and recommended usage of the References: headers is to include the Message-ID of both the first and one to three immediately prior article(s), in chronological order. The reason for this strategy is to keep news reader programs with thread-specific kill files happy after some articles have expired. With the minimualist method used by source or binary moderated newsgroups, the References: header contains the Message-ID of the first part of the series (or package). The References: header only lists the Message-ID of the first part posted and not all the intermediate parts. By using this header, threaded news readers present each set of postings as a single item to the user making it much easier for them to read. Note: Another way of linking articles is to list the Message-ID of every part. This is not recommended as it just increases the size of the articles without adding much additional information or utility. 5.2.11. Reply-To: Line The Reply-To: line should be preserved if it existed in the submission. This allows the news reader software to email replies back to the article's submitter at their preferred address. 5.2.12. Subject: Line Standardizing your use of the Subject: line somewhat can really help readers choose which articles to read and construct accurate kill files. A leading or trailing keyword system can help immensely, for example. Moderators of source and binary newsgroups use the Subject: line in a de-facto way to make it easier for the readership to see what an article is. For example: v43INF1: Introduction to comp.sources.misc v43i001: ecuman - Manual for ECU comm package v3.30, Part01/06 The leading volume-issue and the trailing Part number information are helpful in giving the readership quick clues to an article. Assure that your use of the Subject: line is documented in the newgroup's policy posting so that the readership knows it is occurring and can take advantage of it. 5.2.13. Other Informational headers There are additional headers that a submitter may supply from time to time. Informational headers such as Summary: and Organization: lines should be included as received in the posted article. 5.3 Other headers that should be removed before posting Submitted articles may arrive in your mailbox with one or more headers that should be removed before posting. Automated scripts can do this for you, or, for a low-volume group, you might prefer to remove them by hand, or write your own pre-processing tools. NNTP-Posting-Host: Status: Lines: Received: Apparently-To: X-* Cc: Message-ID: Sender: In-Reply-To: X-VM-v5-Data: Originator: 5.4. Signatures Some moderators allow all postings to go out with the original signature block as received. Others trim excessive signature blocks off, or remove all but a few lines. In other cases, the moderator will append a standard newsgroup signature to the bottom of the posting, typically containing a line or two describing how to submit articles to the newsgroup, how to retrieve the FAQ, or other highly condensed information. Moderators need to be aware that news software may be appending the moderator's own personal signature file to the end of postings. This may not be desired and can cause confusion with the original submitter's signature. The moderator should decide what is the most appropriate way to deal with their personal signature. 5.5. Creating newsgroup specific headers A moderator may find that their newsgroup is better served with the addition of non-standard informational header lines to the individual postings. This can be done with user-definable "X-" headers placed in the RFC 1036 header portion of the article or by creating auxiliary headers as the comp.sources.* groups have done. Source newsgroup moderators have established additional headers whose sole purpose is to support the posting of source code, automatic archiving and index creation. Auxiliary headers do not appear in the RFC 1036 "News" header section of an article. Instead they are the first lines of the article text separated from the news headers by a single line containing a newline. The actual article text is then separated from the auxiliary headers by another single line containing a newline. In either case, the moderator should inform the newsgroup of the purpose and use of the new headers. This should be done in the periodic policy posting. 5.6. Receiving submissions Submissions are received by the moderator as mail. Although it is possible to use a personal mailbox, it is not advisable. The moderator mailbox should be either a separate account or an alias that points to the moderator's personal account. There are various reasons for doing this, among them: o Filtering on the To: line to separate submissions from other mail. o Ease of maintenance when the moderator moves or is replaced. o Most important, if it's the same mailbox is very hard to tell what's a submission from what's personal mail. o [Others, I am sure] Submissions to a moderated group should be automatically acknowledged when received. This can be accomplished using the deliver or procmail mail processing packages. The UCB Vacation program can also be used to generate acknowledgements. Deliver is available from comp.sources.reviewed archives in volume1. Procmail is available from comp.sources.misc archives in volume43. Other mail filtering programs may be used as such as 'mh' and the 'filter' program that comes as part of Elm. ftp://ftp.uu.net/usenet/comp.sources.reviewed/volume01/deliver/ ftp://ftp.uu.net/usenet/comp.sources.misc/volume43/procmail/ ftp://dsinc.dsi.com/pub/elm/ ftp://ics.uci.edu/pub/mh/ There are procmail auto-reply tools in the moderators' archive. [See Section 15 for the location of the archive.] 5.6.1. Articles posted to a moderated group There are a couple ways that a reader can submit an article to be posted to a moderated newsgroup. The reader can post the article to the moderated newsgroup as if the group was not moderated. If the news software is properly configured then it will forward the article to the appropriate moderator for approval. Unfortunately, it is not unusual for a posting to be lost in a misconfigured news system. Readers then send mail to the moderator wondering where their article went to. The moderator has not seen it and has no idea what the submitter is talking about. Other problems with encouraging direct posting to newsgroups is that the article might be cross-posted or might have been sent without knowing the group's moderation status. Another problem that makes directly posted articles harder to deal with is the duplicate headers problem described in Section 15.7 5.6.2. Emailed submissions Moderators should consider encouraging submitters to mail articles to the submission address directly instead of direct postings to the group. The benefits are users are usually alerted to mail problems faster than news problems. Duplicate headers are not a problem and articles received via email are guaranteed not to be cross-posted. All in all, emailed submissions tend to cause moderators less grief then do directly posted submissions. 5.7. Adding moderator comments Comments from the moderator, if necessary, should be added in a way that clearly differentiates the comments from the submitted article. This is usually done by including comments enclosed in brackets [ such as this ]. Whether the comments are included at the beginning or appended to the end of the article does not really matter. It has been suggested that placing the comments at the end of a posting is better since it does not interrupt the flow of the author's train of thought. It is also sometimes appropriate to interject comments into the middle of a posted article; for example, if a post gives a vague reference to an FTP site, the moderator may wish to add a line with a specific reference immediately below that paragraph to avoid confusion. Also moderators should sign the comments, either with their name or some way to identify the moderator (e.g. -mod, -editor or the moderator's initials). No matter what method is chosen, the moderator should be consistent so that the group's readership can easily locate and recognize the moderator's comments. 5.8. Submitting articles The software and process a moderator uses to post to a newsgroup can be as simple as piping an article through a script from within the moderator's mailer which posts it. It can be as full blown as a program that creates Auxiliary headers for a source submission and checks for all sorts of potential name conflict problems and common posting errors. The moderator should determine what is needed to make these tasks easier. Taking the time to try to figure out actual posting procedures can potentially save time every day. Posting software is available on the moderator tools archive. From the simplest "submit" script to the complication of "postit", the archive has a wide range of posting tools that are there for others to grab and modify for their purposes. [See Section 15 for the location of the archive.] 5.9. Canceling articles From time to time you may need to cancel an article. It may be that you need to cancel an article with forged approval or an article that was posted in error. Whatever the reason, know how to cancel an article so that when the need arises you are prepared to cancel it quickly and correctly. To cancel an article, create a cancel message and post it the very same way the article was originally posted. The From: and Sender: headers need to be the same as they were in the original article. Take the Message-ID: of the article being canceled and make it the cancel header by "Control: cancel ". You should use the same Newsgroups: line as the original, and you must have an Approved: line, otherwise it'll get submitted to the moderator for approval. You might choose to make the Subject: contents the same, but it is not necessary. Finally, if you provide your own Message-IDs for your articles make sure that you give the cancel message a new Message-ID. For example, to cancel this message: Newsgroups: your.newsgroup,other.newsgroup From: I-made-a-mistake@erroneous.com (I. Goofed) Sender: usenet@erroneous.com Message-ID: <12345abcde@erroneous.com> Subject: How to shoot yourself in the foot Approved: Post this cancel message: Newsgroups: your.newsgroup,other.newsgroup From: I-made-a-mistake@erroneous.com (I. Goofed) Sender: usenet@erroneous.com Control: cancel <12345abcde@erroneous.com> Subject: Cancelling erroneous article Message-ID: Approved: Also put a note in the body of the cancellation message explaining why you cancelled the article. This is normally just a one-line comment. There are scripts in the moderator tools archive to assist in canceling articles. [See Section 15 for the location of the archive.] 5.10. Where to find other documentation on moderation News programs communicate with each other according to standard protocols, some of which are described by RFCs. RFC stands for Request For Comment, but might be better described as Requirements For Compliance. RFCs describe de-facto standards in the Internet Community. They are a form of a published software standard. Copies of RFCs are often posted to the net in the group comp.doc and obtainable from archive sites such as ds.internic.net. Current news-related RFCs include the following: o RFC 822 specifies the format of messages; RFC 1036 uses this. o RFC 977 specifies NNTP, the Network News Transfer Protocol. o RFC 1036 specifies the format of USENET articles. o RFC 1123 amends RFC 822. o RFC 1153 specifies the digest format some groups use. Henry Spencer is currently developing a Son-of-RFC 1036. ftp://ftp.zoo.toronto.edu/pub/news.txt.Z ftp://ftp.zoo.toronto.edu/pub/news.ps.Z .ps is the PostScript version. Kent Landfield is currently developing an FYI describing Sources group moderation. ftp://ftp.sterling.com/moderators/mod.sources.txt Chris Lewis maintains an FAQ that suggests a format for an FAQ. "FAQs: A Suggested Minimal Digest Format" It is periodically posted to news.admin.misc and news.software.readers. It is also probably a wise thing to re-read the documents that are posted from time to time in news.announce.newusers so that you are aware of what the rest of the community is seeing. It may have been a long time since you last read those articles and they have changed over the years. 6. What are the different types of moderated groups ? Moderated groups come in many forms. A brief description of the major types follows. 6.1. Announce groups Announce groups are generally specified as low-volume newsgroups that all readers interested in a specific topic may subscribe to. Some announce groups serve as a collecting point for FAQs and announcements for a set of related newsgroups, such as rec.music.info. Most announce groups are chartered for fast turnaround time, which in turn implies only light editing of content; comp.newprod is a rare exception. Moderators of announce groups should make the charter as specific as possible, and should keep the focus on the value to the readers rather than the posters. 6.2. Binary groups Binary groups exist to distribute software. [See also Source groups, Section 6.5] Binary groups distribute executable binaries or other non-human-readable material, usually for one particular system type. Normally binaries are distributed only for systems where many users do not have development or compilation facilities, such as personal computers of various types. Moderators of binary groups should take particular care to prevent the distribution of software containing viruses. Because UNIX executables tend to rely on the site-specific configuration, they should never be posted to the net. 6.3. Digests In preparing a digest, the moderator packs all accepted articles into one file, and posts it to the newsgroup. Articles are edited to remove unuseful mail headers, excessive signatures, and other noise. A summary, table of contents, or other index information is added to the top of the digest to assist readers in finding pertinent information. Depending on the nature or volume of the group, digests may be sent out once a day, or whenever a certain volume of messages has accumulated. Special-topic digests may also be put out when one topic generates a large number of messages. The return address on a digest is the posting address for the group; unless specified otherwise, all replies to the digest are considered submissions. Digest format makes it difficult for readers to mail replies to the authors of individual submissions, and defeats threaded news readers; it is discouraged for these reasons. It is easy to send news as separate items to the newsgroup while sending digests to mail subscribers, as the Telecom digest does. RFC 1153 specifies the digest format used by some moderated groups. [See the group comp.risks for an example.] The "MH" mail package also supports building message digests. 6.4. Discussion groups Discussion groups are usually moderated to quell overheated arguments or to eliminate certain types of repetitive discussions. Moderation also removes thoroughly inappropriate posts, such as chain letters, blanket cross-posts, and topics specifically excluded from the group's charter. Discussion groups are frequently used for questions, and moderators may want to prepare a Frequently Asked Questions (FAQ) posting for the group, or to delegate another knowledgeable poster to do so. Moderators of discussion groups should also be prepared to answer common questions offline, perhaps by forwarding the relevant section(s) of the FAQ." 6.5. Source groups Source newsgroups are moderated newsgroups whose sole purpose is for the distribution and archiving of source code. These groups are different from the binary groups in that the distributed code is not compiled and is in text format. The people receiving code from these groups are expected to have the facilities to compile the programs into executable form. 7. Setting up a new moderated group This is very dependant on the news system employed (eg. INN, C News, ANU). Refer to the documentation supplied as part of the news transport software for the specific steps required to set up a moderated group. There are, however, a few general steps in common. 1) Assure that the moderator has an active account on the system from which moderation will be performed. Create it if needed. 2) Choose and install the submission aliases for the moderator. Two aliases are usually needed, one for receiving actual submissions, and another for receiving administrative requests. news.group.name -> news-group-name & news-group-name-request. 3) Ensure that whatever server, filter or auto-reply software will be used by the moderator is available on the system. Install and test it if necessary. 4) Install the forwarding entry for the moderated group into the mailpaths or moderators file, or equivalent. 5) Finally, the group must be created and marked moderated, using the 'm' flag in the 'active' file. This is done using the tool appropriate for your news transport. (Eg: newsbin/maint/addgroup for C News or 'ctlinnd newgroup' for INN) The same steps are used to moderate a pre-existing group which is being changed from un-moderated to moderated status. If you have further questions, post them in news.software.b or news.admin.technical. 7.1. Submission aliases When you set up your group you will need to establish two mail aliases, so that directly posted articles and emailed submissions can reach you. o The address for submissions to the list. It is better if this is not the name of the newsgroup itself, but something similarly descriptive. For example, comp.source.reviewed's address for submissions might be csr@host.domain o An address where requests and administrative information should be sent. Normally this address is FOO-request for submission address FOO. Using the example of comp.sources.reviewed above, the associated request list address would be csr-request@host.domain Depending on the expected newsgroup and administrative volume, it may be appropriate to have both aliases point to the same place, while retaining the ability to reconfigure the destinations locally. You will need to notify the appropriate people to assure the mailpaths file is updated. USENET moderators refer to Appendix A. 7.2. Email submission servers If your group is to have multiple moderators then you might want to consider setting up a truly co-moderated group. This would be useful for high-volume newsgroups. Greg Woods has written a program to support multiple moderators. When mail is sent to the moderated group alias, it is routed by sendmail to the program, which randomly selects one of the list of moderators to handle the submission. The submission is then forwarded to that moderator. (The program is available in the moderators' tools archive.) 8. Choosing a moderation policy Before you can write up the policies that are going to guide you in moderating your group, there are a few things to consider. 8.1. Article rejections When an inappropriate posting is submitted to the newsgroup, the moderator should send the submitter email informing the sender that their submission was inappropriate for posting to the group. If possible, suggest a newsgroup where the posting might be appropriate. Forwarding a canned message can save the moderator time and assure that the submitter knows which newsgroups might be an acceptable alternative. --------------------- "I am sorry but I am unable to post your request to the newsgroup comp.sources.misc. This newsgroup is a moderated newsgroup whose sole purpose is for the distribution and archiving of source code. Requests for software can be made to comp.sources.wanted or a more specific newsgroup if one exists. Requests for help with the sources gathered from the net should be made to the newsgroups comp.sources.d or comp.sources.bugs depending on the type of the problem." --------------------- If the article is cross-posted to other groups, the moderator should inform the submitter that the article did not appear in the other groups specified in the Newsgroups: line. Do not repost it yourself - this may get you into problems. Send the entire article back to the poster, so that he or she can repost it to a non-moderated group, if so desired. Some common reasons why articles are rejected are: o Submitted article does not fall within the charter of the group, o Copyright or reprint permission problems, o Previously posted question has already been answered, o Excessive quoting, o Asking something specified in the group's FAQ or policy posting, o Message not relevant to the group but targeted toward one person, and should have been sent via email to that person, o Articles that are just flames with little to no real substance. [See Sections 2 and 17.1 for discussions of the difference between moderation and censorship.] 8.2. Copyrights Copyrighted submissions should not be posted without the explicit permission of the copyright holder or the appropriate release authority. Any such release notice should be prominently visible in the article. This rule applies equally to general articles, images, and software. If there are any questions about the legality or approval status of a submission, the moderator should not post it until appropriate permission has been received. There should be no "compilation copyright" placed on the newsgroup by the moderator. The newsgroups are a collective effort, the result of the sites that pass the newsgroup around, the kind souls that maintain software and article archives, and -most importantly- the people who write the articles. Please note, in no way can a moderator-supplied copyright notice supersede the copyright of the individual submitters. 8.3. Dealing with forged Approved: headers As moderator of your group, you are within your rights to cancel articles with forced Approved: headers at any time you wish. It is not possible to stop someone from posting to a moderated newsgroup if they know how. All you can do is complain at them, or complain to root@ or postmaster@ or usenet@ or newsmaster@ or news@ the offending host. In the end, if they choose to continue to ignore convention, the USENET community can try to get their site's NetNews feeds cut off by convincing their neighbors to stop feeding the offenders. If there are repeated forgeries, or if a forged article causes widespread confusion among readers, it is wise to inform the net in the appropriate newsgroups (i.e. news.admin.policy) that these are forged postings and of the trouble you are having. Often a public denouncement will be enough to make the offender stop. Note that few people bother to denounce forgeries posted on April 1. Another approach is to have an auto-canceler script that verifies all articles received by the moderator's site in the moderator's newsgroup have been posted by the moderator or a backup moderator. If an article is encountered that was not posted by the moderator then the script automagically cancels the article and a mail message is sent to the sender parties involved. Naturally, this is tricky when there are changing or multiple moderators. There are also potential problems generated due to propagation delay. There are auto-canceler scripts available. If forgeries are not a common problem on a newsgroup, cancelling by hand when they do come up is probably the best option. 8.4. Commercial postings The group charter should state clearly what the policy on posting articles of a commercial nature should be. If the group charter does not address this issue, or is unclear, then the moderator must define a clear and consistent policy on the subject. The policy should be documented before the issue arises, so that the newsgroup's readership knows what to expect to have done. Don't believe the myth that commercial postings are not allowed on USENET. In reality, commercial posting have been traversing the world via USENET newsgroups almost since the beginning of NetNews. With that said, blatant commercials and hyperbole are roundly frowned upon. It is best to spell this out in the policy. The important thing is that you post only what the readers want (learned via a survey maybe). A good way to describe a generally acceptable policy: "Information, not promotion." 8.5. Dealing with cross-posted articles The moderator needs to determine how cross-posted articles are going to be handled for the group. In some cases the moderator may honor the Newsgroups: lines which list other newsgroups outside the moderator's control. In other cases the moderator's policy may state that cross-posting will never be done, or will be done only at the moderator's discretion. If an article submitted to a moderated group is rejected, then it does not get posted to the unmoderated groups listed in the Newsgroups: line. This is a little unfair to the submitter if the moderator does not inform the submitter of the situation. Not all readers/submitters are aware of how NetNews moderation works. Some moderators refuse to honor any cross-postings listed on the Newsgroups: line and only post to their own group. There is nothing wrong with this policy but the moderator should assure that the group's readership is aware of the policy. Articles are sometimes cross-posted to multiple moderated groups. In those cases, it is important to make sure that moderators of all groups have approved the article before it is actually posted. [See Section 16.6] 9. Backup moderators Each new moderator should recruit one or more people willing to serve as a backup, on a permanent or temporary basis as needed. These backups should be located as soon as possible after the moderator is selected. The need for a backup moderator depends a lot on the nature and volume of the group. A newsgroup that contains mostly pre-approved FAQs from other groups, such as some of the *.info groups gaining popularity, needs backup moderators a lot less than a high-volume discussion group or a time-sensitive *.announce group. Having others who can fill in temporarily, if the need arises, serves as an insurance policy for the primary moderator. You may need to take some time off from moderator responsibilities due to work schedules, vacations, or net connectivity problems, to name a few common reasons. In those cases, having a pre-selected backup assures the newsgroup's continuity during periods when you are unavailable. 10. Multiple or Team Moderation In some cases it might be possible to share a moderation job, rotating from one person to another. No one moderator should become hard to replace. In many cases, a diversity in moderation styles and filtering choices will enrich a group. If the topic of your group makes it possible for you to split the task (by sub-topic or otherwise) consider it desirable to "farm out" the work as it reduces moderator burn-out. As 'titles' are an easy reward to give, consider 'Guest Moderators', 'Associate Moderators' and 'Co-Moderators'. For extremely high volume newsgroups it may be necessary to have the group moderated by a team of moderators. Some such groups have as many as 10 moderators. There are benefits for having a team of moderators, including, o no need for backup moderators, o much easier to go on vacation or take a short break, o consulting/second opinion on topics of concern, o possible to have a moderator dedicated to answering queries. o more bodies working towards making the newsgroup a better resource, There are few things to watch out for. Setting up the process and rules of team moderation is critical to a successful group. Don't forget team moderation is a real "team" effort. 10.1 Team moderator mailing lists Like any other moderated newsgroup, an alias for submissions to the newsgroup should be setup. The incoming articles need to be distributed among the moderators. There are software packages available in the moderators archive which do this. Two strategies for submission distribution among moderators are: o systematic distribution, o random distribution. Systematic distribution usually targets the next moderator to receive a submission in a round-robin fashion. [See "Section 7.2. Email submission servers" for a description of random distribution.] Besides the normal submission and administrative list address it is necessary to have a list address for the moderation team members. In a team moderation scenario, it is recommended that moderators communicate closely with each other to enforce a standard moderation policy and to discuss matters relating to the newsgroup. Any message sent to the team list goes to all the group moderators. It is also helpful for any reader who may wish to pose a question or make a comment to all the moderators. A pointer to the team moderators list should be included in the group's FAQ or the group's policy posting. 10.2 Facilitators Someone needs to be responsible for maintaining the list of moderators receiving the submissions. The moderator team list needs to be frequently updated as moderators go on leave etc. This may be an existing group moderator but it should more properly be a non-moderator acting as a facilitator. More successful team moderated groups have a group of people working with the group moderators supplying unbiased services to the team. For example, facilitators provide additional services to the group and the moderation team by: o Maintaining the distribution script o Writing and maintaining FAQs o 'Owners' of moderation submission, administrative and team mailing list addresses/facilities o Maintaining the official group archives or WWW access o supplying other group specific needs What faciliators are NOT expected to do is: o receive articles for the newsgroup o review articles for the newsgroup o post submitted articles to the newsgroup In times of group crisis, facilitators should have the right to post an article using an 'Approved:' line. It is expected that facilitators would only post original articles explaining the situation or its solution as absolutely necessary to resolve a moderator conflict. Having a good communication among not only the moderators but also the facilitators keeps the newsgroup functionality healthy. An example of such a mailing list is: 'srg-admin@aldhfn.org' for the group soc.religion.gnosis. Another example is 'ww2-mods@acpub.duke.edu'. In this case,the mailing list for the moderators and facilitors is the same one. 10.3 Rejection Notices It is recommended that all rejection notices sent out, in multiple moderators envirnoment, be carbon copied to all the moderators and facilitators. This helps in avoiding confusion & conflicts. In general, all rejections should be honored by co-moderators, unless majority moderators overturn it. 10.4. Multiple moderator conflict resolution. Sometimes conflicts between moderators can get out of hand and spill over into the group. Then everyone suffers. In extreme cases, with a polarized readership, it's generally better to have all moderators resign and stand for re-election, or choose some other way of letting the readership have its say, rather than relying on, for example, confidence motions among the moderators. In some cases, it makes sense to use a corporate board of directors model for moderatorship, and document it officially. This is something that needs to be decided early and not something to be decided when the problem arises. It should be documented in the group's policy posting at a minimum and really should be addressed in the group's charter if possible. Methods of handling inter-moderator conflicts need to be decided before conflicts arise, especially in groups which handle a controversial or emotional topic. Once a problem gets out of control, it can be difficult to get people to agree on a method for resolving it. These methods should be documented in the group's policy posting or available from the official FTP site. 11. Handling temporary moderator absences In the event that a moderator is not able to perform the duties of the moderator for some small length of time, such as a vacation, the moderator should inform the community by posting to the appropriate newsgroup, that there will be a delay in posting articles. It is not usually necessary to give a reason for the delay, though you may choose to do so. If a moderator finds that they will be unable to perform their duties for a more extended period of time, they should allow the backup moderator to assume posting responsibilities until the primary moderator is able to once again assume the responsibilities of posting to the newsgroup. In this manner, articles submitted can to be posted to the newsgroup in a timely fashion and the newsgroup continues to be a resource the NetNews community can depend on. 12. Gatewaying your newsgroup to mailing lists There are people who will hear about your group who do not have access to network news distributions or software. You may want to set up a mailing list that allows your group to be a resource for those who have email access but no NetNews access. Here are a couple of approaches you will want to consider. 12.1. Newsgate Rich Salz has written a package named "newsgate" that is in wide spread use for bidirectionally gatewaying articles posted to a newsgroup into email. It is available in volume 24 of the nearest comp.sources.unix archives such as ftp://gatekeeper.dec.com/pub/usenet/comp.sources.unix/volume24/newsgate ftp://ftp.uu.net/usenet/comp.sources.unix/volume24/newsgate His kit provides two programs for "linking" RFC822 Mail messages and RFC 1036 Network News articles. Each half of the conversion is handled by a different program, mail2news or news2mail. A few utility programs are also included. With these programs and the right set of mail aliases, news sys and active file entries, it is possible to build any set of moderated, unmoderated, one-way, or bi-directional gateways between any set of news and mail groups and lists that you may need to support your group. [ The currently available version of newsgate, from comp.sources.unix ] [ archives, does not work with INN. You just need to make a minor ] [ change to the source. Change references to getdate() to parsedate()] [ and use the parsedate() function that comes with the INN news ] [ software. If you do not wish to do this, contact rsalz@uunet.uu.net ] [ for a pre-patched version. ] 12.2. Listserv Another method of gatewaying is via LISTSERV gateways. It is relatively easy to arrange a two-way gateway between a BITNET list and a moderated group. (For example, the group comp.compilers and the list COMPIL-L@AMERICAN.EDU carry the same content.) It works automatically; the gateway there picks up messages from the group as they arrive and sends them to the list. It also forwards submissions to the moderator. The moderator can do any necessary list maintenance, such as deleting the addresses of people who forget to unsubscribe before their accounts expired, via email. If you are interested in finding out more about establishing a LISTSERV gateway send a message to listserv@auvm.american.edu with a body of send netgate policy and an informational file will be returned via email. Questions about Listserv/NetNews gateways can be posted to bit.admin or sent to news-admin@auvm.american.edu or NEWS-ADM@AUVM.BITNET. 13. Creating Periodic Informational Postings One of the best ways to communicate with your readership, as well as a tool for saving you time, is via a policy posting, and potentially additional Frequently Asked Questions postings (FAQ). A policy posting is an article that describes how you will run the newsgroup. It should include information describing the use of any additional Auxiliary header lines, how and where articles should be submitted, and general guidelines for the group (often including the charter) used by you in performing the responsibilities as the newsgroup's moderator. Other things that might be included are: o How you will deal with cross-posted submissions, o How postings of a commercial nature will be dealt with, o Use of backup or multiple moderators, o Items concerning the group that have been hashed out via the group or moderator lead surveys, o Where to obtain a current copy of the informational postings outside of the newsgroup. If possible, an email location or mailserver should be included, since not all users have FTP capabilities, o A list of sites, if any, that archive the group as well as how to become an archive site, o Moderator conflict resolution methods, o Moderator replacement policy. This posting should be made periodically to the group. Your group may be best served by having both a periodic policy posting and an FAQ. Quite often it becomes necessary to have a Frequently Asked Questions posting. Readers drop in and out of newsgroups frequently, and may not be familiar with previous discussions. A FAQ posting can help reduce the number of duplicate questions submitted to the newsgroup. FAQ posting(s) do not have to be written, or even directly posted, by the primary moderator. Many moderated groups have a group of relevant FAQs posted, written by a number of authors. It is perfectly acceptable to simply give an FAQ author permission to post or crosspost the FAQ into your newsgroup. All the poster needs to do is add the appropriate Approved: header to the FAQ posting. (Of course, if the moderator gives others permission to post to the group, automatic cancellation software, if used, should not cancel those articles.) More suggestions about writing and maintaining FAQs, as well as information about automatic FAQ-posting software, can be gotten from the faq-maintainers mailing list. Write to faq-maintainers-request@mit.edu to subscribe. Unfortunately, the list maintainers do not have the time to individually answer your questions; as of the writing of this handbook, there is no FAQ on writing FAQs. Having these types of documents as a consistent part of the group will save you from answering the same questions again and again. The readership will be able to get the majority of the information about the group from the group itself. When people submit requests for information that has already been covered, it is easy to simply forward the appropriate informational posting to them, or send them a pointer to it. 13.1. Copyright Recently there has been a lot of discussion about implicit and explicit copyrights on policy and FAQ postings. This has become an issue, in part, due to the increasing number of CD-ROM vendors and Internet How-To book authors, who reproduce informational postings in commercial products, with or without obtaining the permission of the authors or maintainers. It is wise to document your copyright and any distribution restrictions within your periodic postings. In most cases you should try to be as open as possible. The purpose of the newsgroups is to communicate information to the community at large. Your information is probably archived and available in many ways and places that you are not aware of; it does not make a lot of sense to be overly sensitive to one particular use of postings that have already been broadcast freely all over the world. Remember that copyright laws can vary widely among the many countries where your posting goes. If asked, it is up to you if you want to see your group's informational postings included. A suggestion might be to send a message back such as: --------------------- I give you permission to use my FAQ for the group 'your.group' as you have requested with the following additional conditions: 1. You state explicitly that the information in the FAQ may not be entirely correct or up to date. That information should not be used directly without first checking it out. FAQ information is only a guideline. 2. Do not change the content of the FAQ in any way but may reformat it to better integrate with your production media. 3. Assure that credit is given as appropriate. 4. You send me a free copy of the {book/cdrom...} --------------------- This is just a suggested starting point; feel free to modify it as needed to suit your policies. 13.2. Frequency of distribution and news.answers You will need to determine how often your informational postings are actually posted to your group. Sources groups post them at the beginning of each new volume in the archives. Discussion and announcement group moderators may decide to post them on a periodic basis, usually once a month. The policy statement should document how often informational posting are done. If there are many requests for the FAQ, or repeats of FAQ information, it may make sense to post the FAQ more often, or to frequently post an explanation of how to obtain the FAQ or policy posting. It is strongly suggested that your policy posting and any FAQ have a consistent Subject: line every time that it is posted, to assist readers in recognizing it. You may also want to consider cross-posting your informational postings to news.answers and the other appropriate *.answers newsgroups. This requires the prior approval of the *.answers moderators. The process is fairly easy, and is described in the postings "Introduction to the *.answers Newsgroups" posted regularly to news.announce.newusers,news.answers and other groups, and "*.answers submission guidelines" posted regularly to all of the *.answers groups (alt.answers, comp.answers, de.answers, misc.answers, news.answers, rec.answers, sci.answers, soc.answers, and talk.answers.) The basic requirements for cross-posting to *.answers, above basic compliance with RFC 1036, are meeting the *.answers standards for the consistent content of a few of the standard header lines, and the addition of an auxiliary header containing an Archive-name: header. There are no format restrictions whatsoever on the contents of postings to *.answers. The *.answers groups are archived on rtfm.mit.edu and elsewhere around the world. If you are not sure if your group is archived and want to make sure that your group's informational postings are available to the community, *.answers is a good option. Even if you do not want to crosspost your informational posting to *.answers, you should have it listed in the "List Of Periodic Informational Posts" which is posted regularly to news.lists and news.answers. To have your informational posting listed, send it to news-answers-request@mit.edu, with a note saying what the posting frequency is, and that you wish to add your posting to the List of Periodic Informational Posts, but are not seeking approval for crossposting to *.answers. 14. Archiving postings to the group It is very common for a moderator to keep an archive of the discussion in their group. While this is recommended, disk space limitations may prevent it. Newsgroup archives are more feasible on Internet sites where they can be made available via anonymous FTP. If you keep an archive accessible via UUCP you'll probably get requests for back issues that you may have to fill by hand. LISTSERV gatewayed lists can do this very conveniently, complete with automatic archival and on-demand retrieval. 14.1. FTP Archives You should list archives that you consider official in your group's policy posting. There are tools to assist you in keeping your archives up to date with a minimum of effort. An example is the "rkive" package written by Kent Landfield . It allows you to automatically archive some or all articles as they arrive in a newsgroup and will create the appropriate Index files. 14.2. Email Archives You may find it useful to set up email-based access to your archives. If so, see the FAQ titled "Mail Archive Server Software List, A Summary of Available Mail Archive Server Software", initially written by Jonathan Kamens and currently maintained by Piero Serini. (piero@strider.st.dsi.unimi.it) and is posted monthly to comp.mail.misc, comp.sources.wanted, comp.answers and news.answers. It is also available from sites that archive news.answers. For reference purposes, email-based archive access programs are often known as "mailservers." 14.3 Archives of selected articles Some moderators find it useful to set up selective archives of noteworthy articles from their groups. For example, rec.food.recipes has an FTP archive of categorized recipes, and alt.sewing has an archive of collected posts about specific sewing techniques. Although it takes a great deal of human affort to maintain such archives, they are generally more useful than wholesale archives, especially for high-volume discussion groups. 15. Tools for moderators An archive of tools written and used by moderators of USENET newsgroups now exists. In the past, most moderators were forced to write much of their posting software by themselves, though sometimes other experienced moderators would share their sources when asked. Until recently there has not been a single archive where moderators could make what they had available for all to use. Moderators both new and existing can see how others with similar types of newsgroups are doing their job. A much wider set of support software is becoming available to the moderating community as we all bring our tools out of the closet. There is no reason new moderators need to develop their own software/support environment from scratch as has been the norm in the past. To make the tools most useful, the moderator will probably need to be familiar with the 'C' language, UNIX shell and perl scripts, in order to adapt them to their own group's needs. The contents of the moderators' tools archive have been generously made available in an "AS IS" condition. The archive is a snapshot of existing tools, as they are being used, rather than a formal release of polished software. Many of the sources, scripts, and supporting documentation are not as pretty as their authors might wish, but they work. The tools are being made available so that other moderators can see working examples of how the tasks are handled, and potentially use them as a starting point for their own custom tools. If you would like to contribute, either send your tools to mod-archive@sterling.com or send email explaining where the tools can be picked up. The moderator's tool archive is available via FTP from ftp://ftp.sterling.com:/moderators/ UUNET mirrors the tools directory and has made it available via FTP from ftp://ftp.uu.net:/networking/news/moderating/ 16. News transport gotcha's There are a few quirks in the network news transport software that you might encounter, and should be aware of. What follows is far from a complete list but does include the ones most commonly encountered. 16.1 Line lengths The NNTP reference implementation (the NNTP 1.x (latest 1.5.11) package) in use on the Internet has a limit on the number of characters that an individual line may contain. Submissions containing lines longer than 512 bytes will be corrupted because the reference servers will truncate the lines longer than 512 bytes. In general you should limit your individual line lengths to 79 characters or less if possible. Systems that have fixed record lengths, such as some BITNET IBM servers, can drop text longer than that. 16.2 Old C News blanks-in-ng bug If there is a newsgroup line in an article like this Newsgroups: comp.unmoderated, comp.moderated some older versions of C News fail to skip the space after the comma and so only see the group " comp.moderated" which of course is not moderated and passes it along. When the message hits a B News site, the space is squeezed out, the moderated group is seen for the first time and the message gets mailed in. This has been fixed in later C News releases, but sites running older software will still act this way. 16.3 B News non-local unapproved articles bug As mentioned in Section 5, most news servers will automatically forward unapproved postings to the moderator. This should only occur for local postings, otherwise, situations can occur where the moderator gets far more than one copy of the same article. B News forwards non-local articles too. This coupled with the old C News blanks-in-ng bug has been responsible for moderators being deluged with hundreds of copies of an article. It's particularly nasty when the newsgroup has been recently unmoderated and not every server has respected the control message and the ex-moderator gets bombed. To be fair, the B News behavior of mailing unapproved non-local articles to the moderator was not a "bug". It was a "feature". It used to be that B News was the only game in town. It used to be that people ran ancient software versions forever. In such an environment, it was useful for a site receiving an article that should have gone to the moderator to assume that the previous hosts were running old software, and do the moderator-send itself. That is not the case today This bug has not been fixed, and never will be because B News is no longer being supported. Fortunately, B News is dying out. 16.4 Article size concerns In some places, such as small systems and news-to-mail gateways, there are problems when individual article sizes exceed software limits. We need to either remove builtin system limitations or work around them. Since it takes time to remove old software versions and overcome hardware limitations netwide, the best course of action is to work around the limitations so that the news will get to all sites. Individual postings should be less than or equal to 60K. If it is necessary to split the posting into multiple parts, each part should be less than or equal to 60K. This is due to the architecture restrictions of some older systems. This restriction is more in the minds of the users on the net than the software running it. Postings of 90K successfully make it through most present day news systems. Many mail systems have limitations of 100K on messages that pass through them. This is a concern because there are news to mail gateways that deliver and post news via electronic mail. Note that many new commercial gateways to the Internet have broken news and mail software that truncate anything over around 25K. Most are in the process of correcting their sub-standard software but at this point that has not been universally acomplished. 16.5. Amount of messages posted daily Moderators of high volume newsgroups should try to limit the amount of data posted per day so as not to flood news spool directories on smaller systems. A good rule of thumb is to limit posting to 800K per day if possible. If you are overwhelmed with posts on one day, it may be better to hold some articles back until the next day. Articles can be posted either in chronological order, or grouped by subject. On the other hand, it is not a good idea to loosen your acceptance standards simply because fewer articles were submitted in a given time period - in most cases it is better to have lower volume than lower quality. 16.6 Cross-posting to other moderated groups None of the NetNews software handles cross-posted moderation very well, largely because there is no consensus on what the correct action is. What actually happens is that the posting software picks one of the moderated groups more or less at random (usually the first moderated group) and mails the message to its moderator. If the posting software used by the moderator who received the article does not check for other moderated newsgroups, the article will appear in the newsgroup of the other moderated group without being approved by the appropriate moderator. Moderators should try to bullet-proof the posting software by making it check cross-posting to multiple moderated groups. But until NetNews gets a far more sophisticated posting scheme, e.g. one that lets a moderator add a new newsgroup to a message already in circulation, glitches like this will happen. Remember that it is often VERY desirable to cross-post among moderated newsgroups: comp.sources.misc "list of sources" also goes to comp.archives comp.sources.misc "intro posting" also goes to news.answers Many of the postings in news.answers are cross-posted into news.answers from other moderated groups. 16.7 Extra headers on directly posted articles Some submissions will arrive with two sets of headers. The "real" headers will be a set of generic mail headers; the news headers will be included as text within the body of the mail message. Even worse, in these cases the mail headers may indicate that the article is "From" usenet@site or news@site, making it difficult to identify or respond to the actual author. This is the article-headers-in-body problem caused by C News feeding the article into UCB Mail or mailx instead of /bin/mail, which usually incorporates the news headers into the mail header. Explanation: in C News, the newsbin/relay/injnews script is used by inews to do site-specific header bashing. When it discovers the newsgroup is moderated, it invokes mail to send off the article to the moderator (via mailpaths). Unlike B News and INN, where time has been spent to configure how to use the mail transport directly (to merge the news headers in with the mail headers), C News blindly punts the article into "mail" which is a user agent, which often refuses to accept "header-like" stuff at the beginning of a message as part of the RFC822 header block. In essence, mail will often implicitly put a blank line at the beginning of the message, so the headers carefully crafted by injnews end up as part of the body instead of the mail headers. If this becomes a problem for you, it would be appropriate to send a message to usenet@ and/or postmaster@ at the offending site with a suggestion on how to fix their C News injnews script. [See Appendix B for a description of the solution. A template message is included that will allow you to inform the offending site of both the problem and the solution.] 16.8 Multiple copies of the same submission received There are a number of different reasons why you may get many copies of a submission: o A mailer or gateway bug that keeps resending the same message (distinguished by having the same sites in "Received by" headers). o The posting site doesn't have the group marked as moderated (usually you only get a few extra copies of the message, all with short "Path" headers, if any). o Interaction with the C-news problem when there is a space in the list of newsgroups; when it gets to a B-news site, the space is squashed out and the moderated group is recognized (there are multiple newsgroups in the header, and your moderated group is not the first in the list). o Submitter was unaware that the group was moderated and repeatedly attempted to post the article to the group since their article did not immediately appear in their local newsgroup. Contacting the administrator of the site where the problem posting was generated is probably a good first step. 16.9. B News static Newsgroup: header limit B News inews has a static limit of 256 bytes for header lines. One might think that this limits Newsgroups: headers to about 254 bytes, but unfortunately the practical limit is lower than that. The Xref: header, which is generated from the Newsgroups: line plus article numbers, is longer than the Newsgroups: header. If the Xref: header at a particular site is longer than 256 bytes, the article simply will not appear at that site. Since the length of the same article's Xref: header varies from site to site, and cannot be easily computed in advance, it is necessary to leave some spare room in the Newsgroups: header. Set a fair limit on the size of the Newsgroups: header, and make a policy prohibiting crossposting to more groups than will fit on the line. Some moderators have decided on a 200-character limit for the entire Newsgroups: line. 17. How to deal with your readership Moderators need to take the time to figure out how they wish their newsgroup to be perceived on the net. Some of this is forced upon the moderator by the group's charter but much of it is up to the moderator. Are you planning on being proactive in keeping discussions going and on track ? Do you see yourself only as a filter for the group and keep yourself totally in the shadowd ? Or do you plan to be somewhere in the middle of the two ? And how will you deal with the submitters ? Much of the perceived success in being a moderator is how your deal with your group's readership. 17.1. Personality of your group This is up to you as the moderator to determine. The whole point of having a moderator is to act as a filter, so you don't get 20 copies of the origin of "foobar" all posted. In general, you decide: o Which submissions are appropriate for the newsgroup, o What format to post them in, o What order to post things in, o Whether to edit the submissions, o How, or in what directions to steer the discussion. Because of the very restrictive charter of news.announce.important, submissions accepted and posted to the group should be a very important article for all NetNews system administrators to read. For this reason almost all postings are rejected. The moderator might suggest to the submitter that the submission belongs in another group such as news.misc instead. However, for most discussion newsgroups, you'll probably want to let almost everything through; otherwise you can get a reputation as a tyrant or censor. Most moderators try to help the author say what they really meant; if the original submission isn't clear you can suggest changes, or suggest a different place where it might belong. If you get duplicates, pick the best one and post it, perhaps along with an editorial note thanking A, B and C for their similar answer. If you get a high noise/signal ratio, you can delete some of the noise (like extra mail headers or signature lines). If the poster asks a question that you know the answer to, it's common to post the question and give the answer right there in an editorial note [such notes are generally in brackets, like this - MRH.] Other common editorial practices are to remove excessive quoted material, and to reformat paragraphs to be under 80 columns per line. (Some moderators return articles to the author for such reformatting, though.) If you want to have a lively discussion (or discussions) going, you might group related notes (possibly into a digest) and pass almost everything through. If your goal is to improve the quality of the newsgroup (like rec.humor.funny does for rec.humor) you might be very selective. 17.2. Deciding a course of action There are times when you may not know the best way to handle an issue or policy. You cannot always be sure what the newsgroup's readership actually wants to see happen. When a significant question or controversy arises, you should consider running a survey of the readers to determine the appropriate course of action. Surveys can be extremely useful, not only for determining what people want to happen on a specific issue, but for the other benefits they can provide: o Once it is documented what the readers want, it is much easier to explain to the malcontents why you need to reject their submissions. o Readers feel the moderator is listening, and allowing them to help improve the group. o Often you receive other comments that are not a part of the issue on the table that you find useful to incorporate into your group's moderation. 17.3. Community perceived problems with moderation in general Censorship - People are afraid they won't be able to get their idea out to the masses if the moderator doesn't like it. You are strongly discouraged from ever telling someone "I don't think this should be posted to the net" when you get a submission. It's almost always possible to say "toplevel.mygroup isn't the right place, have you considered net.framus?" We should also emphasize that only the moderated groups are affected, the unmoderated groups will still exist for those who want total freedom and lower quality or higher volume. (Hopefully you'll be able to take some of these high volume newsgroups and reduce their volume to a manageable level, along with increased organization.) This is only true for groups that are parallelled by unmoderated groups. Time delays - When someone posts something to an unmoderated group, most of the net sees it within two days. When submitted to a moderator, you introduce a delay, and you submit to the net from a different place which might introduce an additional delay. Depending on the nature of your group, it may be very important that you process submissions promptly. A lively discussion will die out if turnaround is worse than about one day. On the other hand, groups such as comp.sources.* and rec.humor.funny probably can easily tolerate more delays. There have been moderators who've gotten way behind on traffic; the result has been bad feelings toward the moderator, and in extreme cases, a newsgroup that dies out. 17.4. Vocal minority As moderator of a newsgroup, prepare to be flamed by a vocal minority. Assuming you do your job reasonably well, most of the satisfied readers will remain silent. Whether you deserve it or not, you will receive annoyed criticism from readers concerning just about everything, typically of the form: Why did you reject my article? Who made you God? How dare you get sick/go on vacation/neglect the newsgroup for your real life? Remaining calm in the face of this sort of criticism is the best defense. If there are actual facts under the heated rhetoric, address those calmly and ignore the tone of the criticism. Apart from that, just ignore the poster. It helps to have form letters to deal with some of these questions, particularly the first two. [See Appendix B.] Keep the charter of the newsgroup handy. Resist the temptation to have the last word in an argument, even if the argument is in public. 17.5. Anonymous postings On some newsgroups, the moderator will facilitate anonymous postings by stripping identifying headers from submissions, if so requested. On other newsgroups, the moderator requires that all submissions be from identified accounts, going so far as to reject all postings submitted through anonymous remailers such as anon.penet.fi. In choosing your policy, you should be aware that even 'identified' accounts may have very little connection to a real person. For all practical purposes, most user accounts on large commercial network providers such as netcom.com and aol.com are anonymous - the user chooses what, if any, identifying information is visible. No matter what policy you choose for your newsgroup, it should be documented clearly in the group's periodic policy posting. It might also be wise to let the group's readership decide the policy, by holding a vote. 18. Answers to general questions The following section is a frequently asked questions list with answers. They are listed in no particular order. 18.1. How big is my group's readership ? The best way at present to determine readership is via the newsgroup reports that are posted monthly by Brian Reid to news.lists. For local or organizational newsgroups, you can obtain the arbitron scripts and run them yourself on the local machines. 18.2. What mechanisms guard the group from unauthorized "Approved:" headers? None. The best process is for the moderator to read the group from another site and cancel anything posted to his/her group by 'outsiders'. (You should try to do it from another site, in general, because the type of person who posts their own stuff to a moderated group frequently puts your "official" site in the Path: line in an attempt to keep you from seeing the posting.) 18.3. Have any moderators gotten paid for what they do ? Yes. Sometimes a moderator's employer understands the importance of news moderation, and the effort involved in doing a good job, and allows the employee to perform some moderation tasks during working hours, or on the employer's equipment. This potentially gives the organization greater visibility through an Organization: header or signature file in the moderator's postings. While the moderator is not being directly paid for moderation duties, their normal compensation covers time spent working on the newsgroup. The group comp.research.japan received a grant from the U.S. Office of Naval Research to help support the operation of the group. There have been other research oriented groups that have received support, but to-date moderation is a volunteer position with no compensation other than a grateful community. 18.4. Why are readers complaining of lost articles ? A complaint a moderator hears from time to time concerns lost submissions. There are several reasons for these complaints. o The reader is unaware of the group's moderated status The reader replies to an article or submits a new one and does not see it appear within minutes in the newsgroup they are reading, as is the case for unmoderated newsgroups. Solution: Advertise the moderation status in the newsgroup in the group's periodic posting. o Reader turnaround expectation time A reader may wish to see the article reviewed and posted even before the moderator gets to it. Total Turnaround time, barring unusual network problems, may be calculated as follows: T = T1 (Time for the submission to the forwarding site for the newsgroup from the site it is submitted) [ 0.5 day ] + T2 (Time for the submission to be processed at the forwarding site and transfered to moderator's email address) [ 0.5 day ] + T3 (The suggested turnaround time by the moderator) [ X days ] + T4 (Time a submission will take after posting at moderators site to propagate to the authors) [ 1 day ] T = 2 days + X days. For example: If a moderator has a turn around time of 1 day, it can take up to 3 days for an article to re-appear at the submitter's site. Solution: Make the total expected turnaround time available. Readers will know to wait before complaining their articles are lost. Request they wait at least 'T' time before flagging their articles as lost. o Misconfigured local news software Readers may complain that they are posting/sending articles which the moderators never see. None of the articles from that site ever reach the moderator(s). It is possible the site was configured correctly and in an update to the software something went wrong and articles no longer reach the moderators. Solution: If all the previous options have been exhausted. Ask them to pursue the following: 1. Send a test submission. [if it fails continue on] 2. Talk to news@_user_site for an explanation. 3. Talk to root@_user_site for mailer logs to check if the submissions are going out of the site. 4. In the meantime, request the reader to post thru an alternate way by sending submissions to: - Mail2News gateways. eg. group-name@cs.utexas.edu group-name-news@starbase.yale.edu - email submission directly to the moderator's submission address o Reader continue to complain At this time, don't rule out the possibility of readers intentionally creating the problem make moderator(s) appear incompetent or to appear as 'victimized' by the moderators or any political agenda of their own. It is recommended, moderators be upright and honest and inform the readership of what is being down to track the lost articles. 18.5. Readers complain of articles being deleted after a day Every system that runs the news software has its own set of article expiration times set by its news administrator. The admin sets the expiration period depending on how many groups they carry and how much disk space is available. As a full news feed is over 100 MBytes a day and rising, some groups are set to expire very rapidly. That is probably what is happening to the articles your users are worried about. Most news admins expire articles faster in groups they think are less important, to make space for those they think really matter. For example, some sites keep alt. groups only 1-2 days but keep the comp.* groups much longer. Tell the readers having the problem to talk to their local news admins. Most will extend the life of a particular group their users say they find important to them. There is a way that you can indicate that your articles should not be expired so quickly as the rest - the Expires: header. However, this should not be used for normal articles as it is not reasonable to try to override the local news admin's policy on how to use the limited disk space on their systems. If your group has an FAQ or other regular monthly information posting, though, you may like to use the Expires: header on that article - look in news.answers for lots of FAQ articles, many of which will have an Expires: Note however that, partly because of misuse of the Expires: header in the past, some systems no longer support it and expire all articles at the same rate. The only real way your users can be sure of keeping the articles long enough is for them to get the support of their local news admin. 19. Passing the torch The worst time for a moderator is when they realize that they can no longer provide the time needed to keep their newsgroup responsive to the submitters and the group's readership. It is hard to give up something that has been enjoyed in the past and to admit to yourself that it is time to move on. That time will come for all moderators at some point. The best moderators are the ones that recognize it is time and then tries to make the transition as easy for the new moderator as well as the group in general. When it is time, there are a few ways to proceed in finding a replacement. o Post a message to your group or some other appropriate group requesting one or more volunteers to take over moderation duties. Be prepared for many responses coming back. Also be prepared for no responses coming back. o Directly offer the position to someone you feel would do a good job, such as your backup moderator, and then announce it as a done deal to the group. o USENET moderators can post to the moderators mailing list and ask for a replacement. Some have even resorted to a vote in the past but this is not recommended as it is not a win/win situation for the moderator or the group. Once a replacement moderator is selected, inform the group of the change in responsibility and introduce the new moderator to the group. It should not be the new moderator's job to do a self introduction. You as the departing moderator should do so. Also, take the time to thank those who have helped you along the way. If you are the moderator of a USENET newsgroup you will need to follow the procedures specified in the Changing Moderators section of Appendix A: 20. Acknowledgments Sections of the text in this document are based on and taken from emailed responses that appeared on the moderators list and moderators-advice mailing list. The following people contributed in that fashion. Erik E. Fair Ron Heiby Mark R. Horton Thomas Krueger J. Philip Miller Rich Salz Gene Spafford Werner Uhrig I would also like to thank the moderators-advice list for being patient through the many revisions that they saw go by. Finally, the author wishes to express his heartfelt thanks to David Lawrence John R. Levine Chris Lewis Mark Moraes Scott Hazen Mueller Asim M. Mughal Aliza R. Panitz Matthias Urlichs David Wright Dan Zerkle for help in writing and re-writing sections, reviewing the document, answering my silly questions and for making the document's creation much easier. Thanks! 21. Security Considerations Security issues are not discussed in this memo. 22. Author's Address Kent Landfield Sterling Software 1404 Ft. Crook Rd. So. Bellevue, Nebraska 68005-2969 Phone: 402-291-8300 EMail: kent@sterling.com Appendix A: USENET Newsgroup Moderation For new USENET newsgroups, draft charters and moderation policies should be made clear in the Request For Discussion, and final versions should be in the Call For Votes. The process of creating new USENET newsgroups is discussed in "How To Create A New Usenet Newsgroup" posted periodically to news.admin.misc and news.answers. A.1. Discussion lists for USENET moderators Two mailing lists have been set up to facilitate communication between moderators. They are described below. These lists are there for your benefit. Use them. New moderators may feel worried about showing their ignorance in front of the list of their new found peers. Don't! These lists are there to help new USENET moderators. USENET moderators are generally extremely helpful. Don't try to struggle through when a simple request will make your new tasks easier. A.1.1. moderators-advice The group 'moderators-advice' was formed from a volunteer group of USENET moderators in Fall of 1993. The goal of this group is to come up with some practical general guidelines for moderated groups on USENET, in the form of a moderators' handbook (this FYI). One of the goals of 'moderators-advice' group is to assist, guide and answer questions for moderators of USENET. To facilitate this process, this document has been compiled. It is hoped that this document gives basic information and general guidelines about the moderation process. If you have general questions about the moderation process please send them to moderators-advice prior to posting to the entire moderators mailing list. A.1.2. moderators A general discussion list for USENET moderators is: moderators@uunet.uu.net All changes -- additions, address changes, deletions: moderators-request@uunet.uu.net The traffic on this mailing list varies. Most of the time it is low or quiet, if some discussions starts, it may go up to several messages a day. Almost all USENET moderators subscribe to it. Incoming USENET moderators are normally added by default. A.2. Changing moderators The official list of moderators is maintained by David Lawrence . The list is posted monthly to the newsgroups news.lists, news.groups and news.answers. It is titled "List of Moderators for USENET" When a change occurs, the current moderator needs to send a message to: moderators-request@uunet.uu.net indicating the change to be made. The following information must be supplied: o The name of the new moderator(s) o An address where requests and administrative info should be sent. Normally this address is FOO-request for submission address FOO-. o The address for submissions to the list. It is better if this is not the name of the newsgroup itself, but something similarly descriptive. The message to initiate the change should only be sent when the old and new moderators are ready to actually make the switch. It is best if the new moderator also sends a message to the address listed to say hello. This will help speed the change. David will update the list and mail it out to all sites acting as USENET moderator mail forwarders. A.3. USENET moderator replacement concerns In the past, it has generally been decided (though not quite unanimously) that a moderator may not be removed by the group's readership. This topic is a recurring one on the moderators mailing list where there are those who feel USENET needs a way to remove moderators who have quit supplying their services to a newsgroup or who are otherwise not fulfilling their duties in a satisfactory manner. To date there is no accepted process for removing a moderator. When a moderator has not been posting for a very long time the readership can get angry at the moderator and their inactivity. Members of the readership have also become vocal when the moderator failed to follow the charter of their group when selecting articles to post to it. Whatever the reason, when this happens members of the group's readership have flooded associated groups with "Off with their head!" or "The moderator of 'your.group' is a worthless ... !" messages. Things start to get ugly at this point. Most moderators when confronted with this situation will try to find a peaceful way out. It may be that a polite message posted to your group explaining the reason such as "real work has gotten in the way and it is temporary situation" will calm the troubled savages. The solution may entail finding a co-moderator/backup to assist with the workload or find a permanent replacement. Some moderators just ignore these types of problems and continue as if the complainers do not exist. The later approach does have problems that you should be fully aware of. A rabid readership can't really knock you out of the moderator position but they can damage your net.reputation with barrages of constant complaints in unmoderated discussion groups relevant to the one you moderate. You may end up spending time responding to messages when you could be using that time to post to your group. In any case, be prepared for a nasty situation if you chose to ignore the problem. In the end, you must make your own decision on how to deal with the problem. But please remember that your group is a net.resource to many people and when it is not functioning smoothly, it is not useful. A.4. Group Charters These are important! *Don't* lose 'em. They often come in very handy when it's necessary to quote chapter and verse to a recalcitrant loudmouth. And if you wish to make changes to it, make sure that you get some sort of public consensus that the changes are reasonably acceptable. For recently created Usenet groups (since sometime in 1990), group charters are available at ftp://ftp.uu.net/usenet/news.announce.newgroups/ They are archived by hierarchy and newsgroup name. A.5. Submitting articles thru public USENET Mail/News gateways. If you do not have direct access to USENET news, you can still moderate a USENET newsgroup. This can be done by submitting articles to the group via electronic mail, instead of posting them directly to the group. There are a several 'public' mail/News gateways. Each one has their own ways for addressing syntax. The three most common ones are: Site: cs.utexas.edu Syntax: newsgroup-name@cs.utexas.edu Example: To send to the newsgroup 'comp.compilers', address the message to comp-compilers@cs.utexas.edu Site: newbase.cs.yale.edu Syntax: newsgroup.name-news@newbase.cs.yale.edu Example: To send to the newsgroup 'comp.compilers', address the message to comp.compilers-news@newbase.cs.yale.edu Site: decwrl.dec.com Syntax: newsgroup.name@decwrl.dec.com Example: To send to the newsgroup 'comp.compliers', address the message to comp.compliers@decwrl.dec.com Appendix B: Canned Messages All moderators get a certain amount of wildly off-topic submissions, and it helps to have a form letter that you can send to clueless folks, without having to take the time to figure out why they might have been posting to your group, or where they should have sent their post, or whether it was their brain or their software that erred. Here are a few types of canned responses that you may want to have handy to save you time and effort: o Read the FAQ, where the question you asked is answered. o Your message wasn't posted because it was similar to several other messages just posted, but thanks anyway. o Your question was answered by past messages, here's how to look in the archives. o You have been taken off the mailing list [if your group is two-way gatewayed to a BITNET list] because mail to you bounced. If your mail now works go ahead and resubscribe. o To subscribe or unsubscribe to the mailing list, send a message to blah. o Your message was cross-posted to other moderated newsgroups and the policy of this newsgroup is no cross-posting. It appeared on this one but no others. o Various responses pointing people at on-line resources. When a spamming message is received, just throw it away with no response at all, particularly if it was cross-posted to a bunch of equally irrelevant groups. There is no reason to alert the spammer to the fact that the message wasn't posted. If it seems like it might be useful, send a polite note to usenet@ or the postmaster@ the spammer's site. B.1. C News Duplicate headers message template Dear postmaster/usenet administrator: I am the moderator of . I receive emailed submissions for the group. As I get a lot of submissions, it can sometimes be rather time consuming to get incoming articles ready for posting. You appear to be running C News, which has the annoying habit of inserting duplicate sets of headers when the transport software sends the posting from your user to me. While a single posting like this isn't a problem by itself, after the 100th or 1000th time it gets rather tiresome, and it's *very* simple to fix. Explanation: in C News, the newsbin/relay/injnews script is used by inews to do site-specific header bashing. When it discovers that the newsgroup is moderated, it invokes mail to send off the article to the moderator (via mailpaths). Unlike B News and INN, where time has been spent to configure how to use the mail transport directly (to merge the news headers in with the mail headers), C News blindly punts the article into "mail" which is a user agent, which often refuses to accept "header-like" stuff at the beginning of a message as part of the RFC822 header block. In essence, mail will often implicitly put a blank line at the beginning of the message, so the headers carefully crafted by injnews end up as part of the body instead of the mail headers. The solution is simple - change injnews to call the mailer (usually the transport) in such a way that injnew's headers are included in the mail headers. In relaynews/injnews, there is the following line: mail "$moderator" <$censart Change it to call the mail transport directly. If you're using sendmail or smail, simply change "mail" to be the full path. Eg: /usr/lib/sendmail "$moderator" <$censart Most other transports, such as MMDF or PP should be just as simple. Please note that injnews is intended to be modified for local site policy, so you won't be voiding your warranty ;-) If you're not using sendmail or smail, or simply wish to test this, try typing: Subject: it worked hello It should appear in your mailbox with Subject: properly recognized. If the subject isn't recognized, then it didn't work, and "Subject: it worked" will appear in the body. If you have any questions, please don't hesitate to contact me. Thank you for your time, .... B.2. Thanks for FAQ comments Thank you for your comments on the FAQ. I'm updating the FAQ now, and am including your corrections or additions as appropriate. Expect to see them in the next posting. B.3. Inappropriate submission (Begin form letter.) The message below was submitted by you to the moderator of either by posting a message to the group, or by sending E-mail to the group's submission address, or by sending mail to the group's administrative address. Your message is not appropriate for posting to . (End form letter.) , Moderator of B.4. Get a Clue (Begin form letter.) The message below was submitted by you to the moderator of either by posting a message to the group, or by sending E-mail to the group's submission address, or by sending mail to the group's administrative address. Your message is not appropriate for posting to . Unfortunately, I do not have the time to make specific suggestions as to where your question or post should go. If you are new to USENET, you should probably read the posts in news.announce.newusers (n.a.n.) -- if they are not available in your newsreader, they also available by anonymous FTP in rtfm.mit.edu:/pub/usenet/news.announce.newusers/* A few that are most likely to be immediately helpful are: A_Primer_on_How_to_Work_With_the_Usenet_Community Answers_to_Frequently_Asked_Questions_about_Usenet Emily_Postnews_Answers_Your_Questions_on_Netiquette Hints_on_writing_style_for_Usenet Introduction_to_the_*.answers_newsgroups Rules_for_posting_to_Usenet What_is_Usenet? To find what groups are relevant for your question, you might scan through your local list of newsgroups (your .newsrc file on most Unix systems), to see which group names seem related. Then subscribe to those groups, and look at some of the recent traffic, to make sure that your question is suitable for the group. (For example, questions about Microsoft Windows belong in comp.os.ms-windows.*, not comp.windows.*) On some systems, you will be able to look at a file containing a one-line description of the purpose of each newsgroup (the 'newsgroups' file), or at a longer description of the purpose and contents of each newsgroup (the newsgroup charters.) Ask your local news administrator if these resources are available on your system. For widely-distributed newsgroups, you can also find the one-line descriptions in the following n.a.n postings: List_of_Active_Newsgroups,_Part_I List_of_Active_Newsgroups,_Part_II Alternative_Newsgroup_Hierarchies,_Part_I Alternative_Newsgroup_Hierarchies,_Part_II The 'List' posts describe newsgroups in the comp, misc, news, rec, soc, sci, and talk hierarchies. The 'Alt' posts describe newsgroups in the alt, bionet, bit, biz, clarinet, gnu, hepnet, ieee, inet, info, k12, relcom, u3b, and vmsnet hierarchies. They will not describe groups that are available only in your region or institution. If these sources of information do not suggest some newsgroups which might be appropriate for your questions, you may wish to post on the newsgroup news.groups.questions, whose charter includes helping users find newsgroups appropriate for their questions. Please consult the above-listed sources before posting on news.groups.questions, however. Very few sites carry all available newsgroups. Your local newsadmin can help you access newsgroups that are not currently available, or explain why certain groups are not available at your site. If your site does not carry the newsgroup(s) where your post belongs, do NOT post it in other, inappropriate groups. Think very carefully before cross-posting to more than one, or perhaps two, newsgroups. It is considered highly inappropriate to broadcast your message to a wide selection of newsgroups merely to have more people read it. Follow the general rules of Netiquette (USENET etiquette) described in the news.announce.newusers postings above. Once you decide what newsgroup(s) are relevant to your question, make sure that you're not asking questions that are frequently asked and answered. In addition to looking at recent traffic in the group, check whether your question is included in an FAQ (Frequently Asked/Answered Questions) list. Most FAQs are archived at rtfm.mit.edu, in directory /pub/usenet/your.group.name, if they're not available in your newsreader in the specific group or in *.answers. Many groups also have a periodic introductory post that describes the content and purpose of the newsgroup - if one exists, you should read it before posting. A listing of many of the periodical postings on USENET can be found in n.a.n. or its archives, as List_of_Periodic_Informational_Postings,_Part_*_* Following these suggestions will help not only to ensure that your post reaches its intended audience, but to make USENET more useful for all of us. (End form letter.) , Moderator of B.5. Test elsewhere (Begin form letter.) The message below was submitted by you to the moderator of either by posting a message to the group, or by sending E-mail to the group's submission address, or by sending mail to the group's administrative address. The is not an appropriate place to send test messages. If you wish to post a test message, there are newsgroups for that purpose, such as alt.test, misc.test, and news.test. Messages sent to the *.test newsgroups are automatically acknowledged by daemons running at many sites. If you want to test your site set up for posting to a moderated group, post your test message to the group misc.test.moderated. (End form letter.) , Moderator of Appendix C: Tributes Any person who moderates a newsgroup for over 10 years should have it documented somewhere so others can appreciate the effort and dedication. Our first tribute goes to Gene Spafford . For 12 years between April 1981 until April 1993 Gene (spaf) maintained and posted *THE* "USENET periodic postings" to the net. The postings included the A Primer on How to Work With the Usenet Community, Introduction to news.announce, Answers to Frequently Asked Questions about Usenet Rules for posting to Usenet, Hints on writing style for Usenet, USENET Software: History and Sources What is Usenet? How to Construct the Mailpaths File, List of Active Newsgroups, List of Moderators for Usenet, inet Checkgroups, non-inet Checkgroups, and others. He also managed the moderators mailing list during that time. The moderator community and the net as a whole owe Spaf a debt of gratitute for his dedication and BS&T. Thanks Spaf!