usefor-usepro-03 February 2005
[< Prev]
[TOC] [ Next >]
7.8. Duties of a Moderator
A Moderator receives news articles, customarily by email, decides
whether to approve them and, if so, either injects them into the news
stream or forwards them to further moderators.
Articles will be received by the moderator either encapsulated as an
object of Content-Type application/news-transmission (or possibly
encapsulated but without an explicit Content-Type header), or else
directly as an email already containing all the headers appropriate
for a Netnews article (see 7.2.2). Moderators SHOULD be prepared to
accept articles in either format.
A moderator processes an article, as submitted to any newsgroup that
he moderates, as follows:
1. He decides, on the basis of whatever moderation policy applies to
his group, whether to approve or reject the article. He MAY do
this manually, or else partially or wholly with the aid of
appropriate software for whose operation he is then responsible.
If the article is a cancel nessage (6.3) issued by the poster of
an earlier article, then he is expected to cancel that earlier
article (in which case there is no more to be done). He MAY
modify the article if that is in accordance with the applicable
moderation policy (and in particular he MAY remove redundant
headers and add Comments and other informational headers). He
also needs to be aware if any change he makes to the article will
invalidate some authentication check provided by the poster or by
an earlier moderator.
If the article is rejected, then it normally fails for all the
newsgroups for which it was intended. If it is approved, the
moderator proceeds with the following steps.
2. If the Newsgroups header contains further moderated newsgroups for
which approval has not already been given, he adds an indication
(identifying both himself and the name of the group) that he
approves the article, and then forwards it to the moderator of the
leftmost unapproved group (which, if this standard has been
followed correctly, will generally be the next moderated group to
the right of his own). There are two ways to do this:
(a) He emails it to the submission address of the next moderator
(see section 7.2.2 for the proper method of doing this), or
(b) he rotates the <newsgroup-name>s in the Newsgroups header to
the left so that the targeted group is the leftmost moderated
group in that header, and injects it again (thus causing the
injecting agent to forward it to the correct moderator).
However, he MUST first ensure that the article contains no
Approved header.
NOTE: This standard does not prescribe how a moderator's
approval is to be indicated (though a future standard may do
so). Possible methods include adding an Approved header (or a
similar but differently named header if method (b) is being
used) listing all the approvals made so far, or adding a
separate header for each individual approval (the header X-Auth
is sometimes used for this purpose). The approval may also be
confirmed with some form of digital signature (6.1).
3. If the Newsgroups header contains no further unapproved moderated
groups, he adds an Approved header (F-3.2.8) identifying himself
and, insofar as is possible, all the other moderators who have
approved the article. He thus assumes responsibility for having
ensured that the article was approved by the moderators of all the
moderated groups involved.
4. The Date header SHOULD be retained. Any Injection-Date header
already present (though there should be none) MUST be removed.
Exceptionally, if it is known that the injecting agent does not
yet support the Injection-Date header and the Date header appears
to be stale (F-3.1.7) for reasons understood by the moderator
(e.g. delays in the moderation process) he MAY substitute the
current date. The Message-ID header SHOULD also be retained unless
it is obviously non-compliant with this standard.
NOTE: A message identifier created by a conforming posting or
injecting agent, or even by a mail user agent conforming to [RFC
2822], may reasonably be supposed to be conformant (and will, in
any case, be caught by the injecting agent if it is not).
5. Any variant headers (2.3) MUST be removed, except that a Path
header MAY be truncated to only its pre-injection region (a-
5.6.3). Any Injection-Info header (F-3.2.13) or Complaints-To
header (a-6.20) SHOULD be removed (and if they are not, the
injecting agent will do so, as required in 7.2.2).
6. He then causes the article to be injected, having first observed
all the duties of a posting agent.
NOTE: This standard does not prescribe how the moderator or
moderation policy for each newsgroup is established; rather it
assumes that whatever agencies are responsible for the relevant
network or hierarchy (1.1) will have made appropriate
arrangements in that regard.
[< Prev]
[TOC] [ Next >]
#Diff to first older
--- ../usefor-usepro-02/Duties_of_a_Moderator.out December 2004
+++ ../usefor-usepro-03/Duties_of_a_Moderator.out February 2005
@@ -1,12 +1,12 @@
7.8. Duties of a Moderator
- A Moderator receives news articles by email, decides whether to
- accept them and, if so, either injects them into the news stream or
- forwards them to further moderators.
+ A Moderator receives news articles, customarily by email, decides
+ whether to approve them and, if so, either injects them into the news
+ stream or forwards them to further moderators.
Articles will be received by the moderator either encapsulated as an
object of Content-Type application/news-transmission (or possibly
- encapsulated but without an explicit Content-Type-header), or else
+ encapsulated but without an explicit Content-Type header), or else
directly as an email already containing all the headers appropriate
for a Netnews article (see 7.2.2). Moderators SHOULD be prepared to
accept articles in either format.
@@ -15,11 +15,11 @@
he moderates, as follows:
1. He decides, on the basis of whatever moderation policy applies to
- his group, whether to accept or reject the article. He MAY do this
- manually, or else partially or wholly with the aid of appropriate
- software for whose operation he is then responsible. If the
- article is a cancel nessage (6.3) issued by the poster of an
- earlier article, then he is expected to cancel that earlier
+ his group, whether to approve or reject the article. He MAY do
+ this manually, or else partially or wholly with the aid of
+ appropriate software for whose operation he is then responsible.
+ If the article is a cancel nessage (6.3) issued by the poster of
+ an earlier article, then he is expected to cancel that earlier
article (in which case there is no more to be done). He MAY
modify the article if that is in accordance with the applicable
moderation policy (and in particular he MAY remove redundant
@@ -29,10 +29,10 @@
an earlier moderator.
If the article is rejected, then it normally fails for all the
- newsgroups for which it was intended. If it is accepted, the
+ newsgroups for which it was intended. If it is approved, the
moderator proceeds with the following steps.
- 2. If the Newsgroups-header contains further moderated newsgroups for
+ 2. If the Newsgroups header contains further moderated newsgroups for
which approval has not already been given, he adds an indication
(identifying both himself and the name of the group) that he
approves the article, and then forwards it to the moderator of the
@@ -43,12 +43,12 @@
(a) He emails it to the submission address of the next moderator
(see section 7.2.2 for the proper method of doing this), or
- (b) he rotates the newsgroup-names in the Newsgroups-header to
+ (b) he rotates the <newsgroup-name>s in the Newsgroups header to
the left so that the targeted group is the leftmost moderated
- group in that header, and injects it as below (thus causing
- the injecting agent to email it to the correct moderator).
+ group in that header, and injects it again (thus causing the
+ injecting agent to forward it to the correct moderator).
However, he MUST first ensure that the article contains no
- Approved-header.
+ Approved header.
NOTE: This standard does not prescribe how a moderator's
approval is to be indicated (though a future standard may do
@@ -57,32 +57,32 @@
used) listing all the approvals made so far, or adding a
separate header for each individual approval (the header X-Auth
is sometimes used for this purpose). The approval may also be
- confirmed with some form of digital signature (a-7.1).
+ confirmed with some form of digital signature (6.1).
- 3. If the Newsgroups-header contains no further unapproved moderated
- groups, he adds an Approved-header (a-6.14) identifying himself
+ 3. If the Newsgroups header contains no further unapproved moderated
+ groups, he adds an Approved header (F-3.2.8) identifying himself
and, insofar as is possible, all the other moderators who have
approved the article. He thus assumes responsibility for having
- ensured that the article was acceptable to the moderators of all
- the moderated groups involved.
+ ensured that the article was approved by the moderators of all the
+ moderated groups involved.
- 4. The Date-header SHOULD be retained. Any Injection-Date-header
+ 4. The Date header SHOULD be retained. Any Injection-Date header
already present (though there should be none) MUST be removed.
Exceptionally, if it is known that the injecting agent does not
- yet support the Injection-Date-header and the Date-header appears
- to be stale (a-5.7) for reasons understood by the moderator (e.g.
- delays in the moderation process) he MAY substitute the current
- date. The Message-ID-header SHOULD also be retained unless it is
- obviously non-compliant with this standard.
+ yet support the Injection-Date header and the Date header appears
+ to be stale (F-3.1.7) for reasons understood by the moderator
+ (e.g. delays in the moderation process) he MAY substitute the
+ current date. The Message-ID header SHOULD also be retained unless
+ it is obviously non-compliant with this standard.
NOTE: A message identifier created by a conforming posting or
injecting agent, or even by a mail user agent conforming to [RFC
2822], may reasonably be supposed to be conformant (and will, in
any case, be caught by the injecting agent if it is not).
- 5. Any variant headers (2.3.2) MUST be removed, except that a Path-
+ 5. Any variant headers (2.3) MUST be removed, except that a Path
header MAY be truncated to only its pre-injection region (a-
- 5.6.3). Any Injection-Info-header (a-6.19) or Complaints-To-
+ 5.6.3). Any Injection-Info header (F-3.2.13) or Complaints-To
header (a-6.20) SHOULD be removed (and if they are not, the
injecting agent will do so, as required in 7.2.2).