Files usepro-06 and allbery-00 are identical
--- usepro-06 Mon Dec 11 16:09:13 2006
+++ allbery-00 Mon Dec 11 16:09:13 2006
@@ -1,8 +1,8 @@
1.1. Basic Concepts
"Netnews" is a set of protocols for generating, storing and
- retrieving news "articles" (which resemble email messages) and for
- exchanging them amongst a readership which is potentially widely
+ retrieving news "articles" whose format is defined in [USEFOR], and
+ for exchanging them amongst a readership that is potentially widely
distributed. It is organized around "newsgroups", with the
expectation that each reader will be able to see all articles posted
to each newsgroup in which he participates. These protocols most
@@ -12,24 +12,8 @@
readers able to access that server.
"Usenet" is a particular worldwide publicly accessible network based
- upon the Netnews protocols, with the newsgroups being organized into
- recognized "hierarchies". Anybody can join (it is simply necessary
- to negotiate an exchange of articles with one or more other
- participating hosts).
-
- An important characteristic of Usenet is the lack of any requirement
- for a central administration or for the establishment of any
- controlling host to manage the network. Nevertheless, administrative
- agencies do exists with varying degrees of authority to establish
- "policies" applicable to particular parts of Usenet.
-
- A "policy" is a rule intended to facilitate the smooth operation of a
- network by establishing parameters which restrict behaviour that,
- whilst technically unexceptionable, would nevertheless contravene
- some accepted standard of "Good Netkeeping". Since the ultimate
- beneficiaries of a network are its human readers, who will be less
- tolerant of poorly designed interfaces than mere computers, articles
- in breach of established policy can cause considerable annoyance to
- their recipients.
-[Could omit that last sentence.]
+ on the Netnews protocols. It is only one such possible network;
+ there are deployments of the Netnews protocols other than Usenet
+ (such as ones internal to particular organizations). This document
+ discusses the more general Netnews architecture and protocols.
--- usepro-06 Mon Dec 11 16:09:14 2006
+++ allbery-00 Mon Dec 11 16:09:14 2006
@@ -1,28 +1,16 @@
-1.2. Objectives
+1.2. Scope
- The purpose of this present standard is to define the overall
- architecture and the protocols to be used for Netnews in general, and
- for Usenet in particular, and to set standards to be followed by
- software that implements those protocols. A companion standard
- [USEFOR] sets out the canonical format of news articles exchanged
- between the various agents comprising that architecture. In this
- standard, references to individual sections in the companion [USEFOR]
- are prefixed with "F-".
+ This document defines the architecture of Netnews systems and
+ specifies the correct manipulation and interpretation of Netnews
+ articles by software which originates, distributes, stores, and
+ displays them. It addresses protocol issues that are independent of
+ transport protocols such as NNTP [RFC3977] and specifies the
+ requirements Netnews places on those underlying transport protocols.
+ It also specifies the handling of control messages.
- A set of hosts within a network which, by mutual arrangement,
- operates some variant (whether more or less restrictive) of the
- Netnews protocols is a "cooperating subnet".
-[It is not clear whether we still need that definition.]
+ The format and syntax of Netnews articles are specified in [USEFOR],
+ which should be read in conjunction with this document.
- It is NOT the purpose of this standard to settle matters of policy,
- nor aspects of software behaviour which do not impinge upon the
- generation, transmission, storage and reception of articles, nor how
- the authority of various agencies to create such policies and to
- exercise control or oversight of the various parts of Usenet is
- established. For these purposes, a separate Best Current Practice
- document [USEAGE] is being provided.
-
- Nevertheless, it is assumed that such agencies with the necessary
- authority will exist, and tools are provided within the protocols for
- their use.
+ Comments are solicited and should be addressed to the Usenet Format
+ Working Group at ietf-usefor@imc.org or to the editor.
--- usepro-06 Mon Dec 11 16:09:15 2006
+++ allbery-00 Mon Dec 11 16:09:15 2006
@@ -1,45 +1,6 @@
-2.5. Textual Notations
+1.3. Requirements Notation
- This standard contains explanatory NOTEs using the following format.
- These may be skipped by persons interested solely in the content of
- the specification. The purpose of the notes is to explain why choices
- were made, to place them in context, or to suggest possible
- implementation techniques.
-
- NOTE: While such explanatory notes may seem superfluous in
- principle, they often help the less-than-omniscient reader grasp
- the purpose of the specification and the constraints involved.
- Given the limitations of natural language for descriptive
- purposes, this improves the probability that implementors and
- users will understand the true intent of the specification in
- cases where the wording is not entirely clear.
-
- "US-ASCII" is short for "the ANSI X3.4 character set" [ANSI X3.4].
- US-ASCII is a 7 bit character set. Please note that this standard
- requires that all agents be 8 bit clean; that is, they must accept
- and transmit data without changing or omitting the 8th bit.
-
- Certain words, when capitalized, are used to define the significance
- of individual requirements. The key words "MUST", "REQUIRED",
- "SHOULD", "RECOMMENDED", "MAY" and "OPTIONAL", and any of those words
- associated with the word "NOT", are to be interpreted as described in
- [RFC 2119].
-
- NOTE: A requirement imposed on a relaying or serving agent
- regarding some particular article should be understood as
- applying only if that article is actually accepted for
- processing (since any agent may always reject any article
- entirely, for reasons of site policy).
-
- Wherever the context permits, use of the masculine includes the
- feminine and use of the singular includes the plural, and vice versa.
-
- Throughout this standard we will give examples of various
- definitions, header fields and other specifications. It needs to be
- remembered that these samples are for the aid of the reader only and
- do NOT define any specification themselves. In order to prevent
- possible conflict with "Real World" entities and people the top level
- domain ".example" is used in all sample domains and addresses. The
- hierarchy "example.*" is also used as a sample hierarchy.
- Information on the ".example" top level domain is in [RFC 2606].
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
--- usepro-06 Mon Dec 11 16:09:16 2006
+++ allbery-00 Mon Dec 11 16:09:16 2006
@@ -1,34 +1,36 @@
-usefor-usepro-06 November 2006
-usefor-usepro-06 November 2006
-,_Notations_and_Conventions.h[< Prev],_Notations_and_Conventions.h
- [TOC] ,_Notations_and_Conventions.h[ Next >],_Notations_and_Conventions.h
-
-,_Notations_and_Conventions.h[< Prev],_Notations_and_Conventions.t
- [TOC] ,_Notations_and_Conventions.t[ Next >],_Notations_and_Conventions.t
-
#Diff to first older
-,_Notations_and_Conventions.t
| Newer | Older |
|---|
-| ,_Notations_and_Conventions.t | ,_Notations_and_Conventions.t |
-
-
-,_Notations_and_Conventions.t--- ../usefor-usepro-05/Definitions _Notations_and_Conventions.out
-+++ January 2006 ../usefor-usepro-06/Definitions
-
-,_Notations_and_Conventions.t
Documents were processed to this format by Forrest J. Cavalier III
-,_Notations_and_Conventions.t2.1. Definitions
-
- All the technical terms defined in F-1.5 are to be considered as
- defined also, with the same meaning, in this standard. In addition,
- some further terms are defined here, and in the following section.
+1.4. Definitions
+ Any term used in this document that is defined in Section 1.5 of
+ [USEFOR] is used with the definition given there. In addition, the
+ following terms will be used:
A "hierarchy" is the set of all newsgroups whose names share a first
- <component> (as defined in F-3.1.5). The term "sub-hierarchy" is
- also used where several initial components are shared.
+ <component> (as defined in Section 3.1.4 of [USEFOR]). A "sub-
+ hierarchy" is the set of all newsgroups whose names share several
+ initial components.
+
+ A "news server" is further distinguished into the roles of "injecting
+ agent", "relaying agent", and "serving agent". An "injecting agent"
+ accepts a proto-article with the goal of distributing it to relaying
+ and serving agents and hence to readers. A "relaying agent" accepts
+ articles from other relaying agents or injecting agents and
+ distributes them to other relaying agents or serving agents. A
+ "serving agent" receives an article from a relaying agent or
+ injecting agent and makes it available to readers.
+
+ A "user agent" is further distinguished into the roles of "posting
+ agent" and "reading agent". A "posting agent" is software which
+ assists in the preparation of a proto-article and then passes it to
+ an injecting agent. A "reading agent" is software which retrieves
+ articles from a serving agent for presentation to a reader.
+
+ "Injecting" an article is the processing of a proto-article by an
+ injecting agent. Normally this action is done once and only once for
+ a given article. "Reinjecting" an article is passing an already-
+ injected article to an injection agent.
- The "semantic content" (often abbreviated to just "content" when the
- context is clear) of a header field is its semantic interpretation;
- i.e. what remains after unfolding it and removing its field name with
- its colon and any leading and trailing whitespace and, in the case of
- structured header fields only, ignoring comments and other
- semantically invisible items and replacing white space by a single
- SP.
+ A "gateway" is software which receives news articles and converts
+ them to messages of some other kind (such as [RFC2822] mail
+ messages), receives messages of some other kind and converts them to
+ news articles, or conveys articles between two separate Netnews
+ networks.
--- usepro-06 Mon Dec 11 16:09:17 2006
+++ allbery-00 Mon Dec 11 16:09:17 2006
@@ -1,34 +1,31 @@
-4. Transport
+2. Transport
- As in this standard's predecessors, the exact means used to transmit
- articles from one host to another is not specified. NNTP [NNTP] is
- the most common transmission method on the Internet, but much
- transmission takes place entirely independent of the Internet. Other
- methods in use include the UUCP protocol [RFC 976] extensively used
- in the early days of Usenet, FTP, downloading via satellite, tape
- archives, and physically delivered magnetic and optical media.
+ The exact means used to transmit articles from one agent to another
+ is not specified. NNTP [RFC3977] is the most common transport
+ mechanism for Netnews networks. Other methods in use include the
+ UUCP protocol [RFC0976] (extensively used in the early days of
+ Usenet) and physically delivered magnetic and optical media. Any
+ mechanism may be used in conjunction with this protocol provided that
+ it can meet the requirements specified here.
+ Transports for Netnews articles MUST treat news articles as
+ uninterpreted sequences of octets, excluding the values 0 (which may
+ not occur in Netnews articles) and 13 and 10 (which MUST only appear
+ in Netnews articles as a pair in that order and which together denote
+ a line separator). These octets are the US-ASCII [ASCII] characters
+ NUL, CR, and LF respectively.
- Transmission paths for news articles MUST treat news articles as
- uninterpreted sequences of octets, excluding the values 0 (US-ASCII
- NUL) and 13 and 10 (US-ASCII CR and LF, which MUST ONLY appear in the
- combination CRLF which denotes a line separator).
+ NOTE: This corresponds to the range of octets permitted in MIME
+ 8bit data [RFC2045]. Transports for Netnews are not required to
+ support transmission of MIME binary data.
- NOTE: this corresponds to the range of octets permitted for MIME
- "8bit data" [RFC 2045]. Thus raw binary data cannot be
- transmitted in an article body except by the use of a Content-
- Transfer-Encoding such as base64.
-
- In particular, transmission paths MUST convey all header fields
- (including body part header fields and header fields within
- message/rfc822 objects) intact, even if they contain octets in the
- range 128 to 255. Furthermore, relaying agents MUST, and other
- agents SHOULD, convey lines even if they exceed 998 characters in
- length, especially in article bodies. These requirements include the
- transmissiom paths between posting agents, injecting agents, relaying
- agents, serving agents and reading agents, but NOT the paths
- traversed by Netnews articles that have been gatewayed into Email
- (7.9.1).
-[At some point it will be necessary for the IMAP standards to catch up
-with these requirements.]
+ In particular, transports MUST convey all header fields (including
+ header fields within message/rfc822 objects in article bodies)
+ unmodified even if they contain octets in the range 128 to 255.
+ Furthermore, transports for relaying and serving agents MUST, and
+ transports for other agents SHOULD, convey lines even if they exceed
+ 998 characters in length, especially in article bodies. (This
+ requirement is stricter than MIME 8bit data.) These requirements
+ include the transport paths between posting agents, injecting agents,
+ serving agents, and reading agents.
--- usepro-06 Mon Dec 11 16:09:18 2006
+++ allbery-00 Mon Dec 11 16:09:18 2006
@@ -1,19 +1,31 @@
-7. Duties of Various Agents
+3. Duties of Agents
- The following section sets out the duties of various agents involved
- in the creation, relaying and serving of Netnews articles. Insofar as
- these duties are described as sequences of steps to be followed, it
- should be understood that it is the effect of these sequences that is
- important, and implementations may use any method that gives rise to
- that same effect.
+ The following section specifies the duties of the agents involved in
+ the creation, relaying, and serving of Netnews articles. This
+ protocol is described by following the life of a typical Usenet
+ article: it is prepared by a posting agent, given to an injecting
+ agent, transferred through one or more relaying agents, accepted by a
+ serving agent, and finally retrieved by a reading agent. Articles
+ submitted to moderated groups go through an additional process, which
+ is described separately. Finally, the additional duties and
+ requirements of a gateway are discussed.
- In this section, the word "trusted", as applied to the source of some
- article, means that an agent processing that article has verified, by
- some means, the identity of that source (which may be another agent
- or a poster).
+ At each step, each agent has a set of checks and transformations of
+ the article that it is required to perform. These are described as
+ sequences of steps to be followed, but it should be understood that
+ it is the effect of these sequences that is important, and
+ implementations may use any method that gives rise to the same
+ effect.
- NOTE: In many implementations, a single agent may perform
- various combinations of the injecting, relaying and serving
- functions. Its duties are then the union of the various duties
- concerned.
+ Many news servers combine the functions of injecting agent, relaying
+ agent, and serving agent in a single software package. For the
+ purposes of this specification, such combined agents should
+ conceptually be treated as an injecting agent which sends articles to
+ a serving agent and optionally a relaying agent. The requirements of
+ all three agents MUST be still met when the news server is performing
+ the functions of those agents.
+
+ Control messages may have additional effects than those described
+ below on news servers which accept them. Those effects are described
+ in Section 5.
--- usepro-06 Mon Dec 11 16:09:19 2006
+++ allbery-00 Mon Dec 11 16:09:19 2006
@@ -1,15 +1,22 @@
-7.1. General principles to be followed
+3.1. General Principles
- There are two important principles that news implementors (and
- administrators) need to keep in mind. The first is the well-known
+ There are two important principles that news implementors and
+ administrators need to keep in mind. The first is the well-known
Internet Robustness Principle:
- Be liberal in what you accept, and conservative in what you
- send.
+ Be liberal in what you accept, and conservative in what you send.
- However, in the case of news there is an even more important
- principle, derived from a much older code of practice, the
- Hippocratic Oath (we may thus call this the Hippocratic Principle):
+ As applied to Netnews, this primarily means that unwanted or non-
+ compliant articles SHOULD be rejected as early as possible, but once
+ they are in general circulation, relaying and serving agents may wish
+ to accept them where possible rather than lose information. Posting
+ agents and injecting agents SHOULD therefore be maximally strict in
+ their application of both this protocol and [USEFOR], and reading
+ agents SHOULD be robust in the presence of violations of the Netnews
+ article format where possible.
+ In the case of Netnews, there is an even more important principle,
+ derived from a much older code of practice, the Hippocratic Oath (we
+ may thus call this the Hippocratic Principle):
First, do no harm.
@@ -17,7 +24,20 @@
suboptimal in a smaller context can become devastating mistakes when
amplified by the actions of thousands of hosts within a few minutes.
- In the case of gateways, the primary corollary to this is:
-
- Cause no loops.
+ No Netnews agent is ever required to accept any article. It is
+ common for injecting, relaying, and serving agents to reject well-
+ formed articles for reasons of local policy (such as not wishing to
+ carry a particular newsgroup or attempting to filter out unwanted
+ articles). This document specifies how articles are to be treated if
+ they are accepted and specifies some cases where they must be
+ rejected, but an agent MAY always reject any article for other
+ reasons than those stated here.
+
+ A primary goal of the Netnews protocol is to ensure that all readers
+ receiving a particular article (as uniquely identified by the content
+ of its Message-ID header field) see the identical article, apart from
+ allowable divergence in trace headers and local metadata.
+ Accordingly, agents (other than moderators) MUST NOT modify articles
+ in ways other than described here. Unacceptable articles MUST be
+ rejected rather than corrected.
--- usepro-06 Mon Dec 11 16:09:19 2006
+++ allbery-00 Mon Dec 11 16:09:20 2006
@@ -1,74 +1,33 @@
-2.3. Identification of news servers
+3.2. Path Identities
-[The format of the Path header is still under discussion (ticket #1047).
-Hence the following texts are tentative, and will need to be changed (as
-will the associated protocols in 7.3). Moreover, there are two
-alternative texts which have been proposed:]
-
- In order to record the passage of articles through the network, news
- servers need to identify themselves by means of a <path-identity>
- (F-3.1.6), which can appear in Path, Injection-Info and Xref header
- fields. Whatever <path-identity> is used in the Path header field
- SHOULD be used also in any Injection-Info header field (and it would
- be normal to use it in any Xref header field also).
-[Maybe that last sentence moves elsewhere.]
-
- NOTE: Such <path-identity>s may also be suitable for sending
- email to news server administrators (see [USEAGE]).
-
-[1st alternative]
-
- <Path-identity>s can take the following forms (in decreasing order of
- preference):
-
- 1. 1. A fully qualified domain name (FQDN) that SHOULD be resolvable
- in the DNS (whether via an A, AAAA or MX record or an equivalent
- CNAME), thus guaranteeing a unique identity. Ideally, it will also
- provide a means to contact the administrators by email (according
- to [RFC 2142], the forms "usenet@server" and "news@server" are
- common addresses for a news server administrator).
-
- 2. Some other (arbitrary) name believed to be unique and registered
- at least with all other news servers sending articles directly to
- the given one. This option SHOULD NOT be used unless the earlier
- option is unavailable (e.g. because the server in question is not
- connected to the Internet), or unless it is of longstanding usage
- and cessation would be unduly disruptive, or unless the earlier
- option is provided as well.
-
-[2nd alternative]
-
- <Path-identity>s can take the following forms (in decreasing order of
- preference):
-
- 1. A fully qualified domain name (FQDN) that can be resolved to an
- email server via an MX, A or AAAA record according to the
- procedures of [RFC 2821]; this guarantees that the name is unique,
- and makes it easy to contact the administrators if needed.
-
- 2. A fully qualified domain name (FQDN) that is guaranteed to be
- unique by the administrators of the domain; for instance, the
- uniqueness of "server.example.org" could be guaranteed by the
- administrator of "example.org" even if nothing is stored in the
- DNS for that name.
-
- 3. Some other (arbitrary) name believed to be unique and registered
- at least with all other news-servers sending articles directly to
- the given one. This option SHOULD NOT be used unless the earlier
- options are unavailable, or unless the name is of longstanding
- usage and cessation would be unduly disruptive, or unless one of
- the earlier options is provided as well.
-
- According to [RFC 2142]], the forms "usenet@server" and "news@server"
- are common addresses for a news server administrator.
-[end of alternatives]
-
- NOTE: A news server administrator who chooses a name which turns
- out not to be unique will have to bear the consequences.
-
- NOTE: The syntax permits the colon character (which, prior to
- this standard, was a <path-delimiter>) within any <path-
- identity> which is in the form of an <IPv6address>. It would
- therefore be unwise to choose, as such a name, anything composed
- solely from four (or less) hexadecimal digits.
+ All news server components (injecting agents, relaying agents, and
+ serving agents) MUST identify themselves, when processing an article,
+ by prepending their <path-identity> (defined in Section 3.1.5 of
+ [USEFOR]) to the Path header field. Injecting agents MUST also use
+ the same identity in Injection-Info header fields they add, and
+ serving and relaying agents SHOULD use the same identity in any Xref
+ header fields they add.
+
+ The <path-identity> used by an agent may be chosen via one of the
+ following methods (in decreasing order of preference):
+
+ 1. The fully-qualified domain name (FQDN) of the system on which the
+ agent is running.
+
+ 2. A fully-qualified domain name (FQDN) within a domain affiliated
+ with the administrators of the agent and guaranteed to be unique
+ by the administrators of that domain. For example, the
+ uniqueness of server.example.org could be guaranteed by the
+ administrator of example.org even if there is no DNS record for
+ server.example.org itself.
+
+ 3. Some other (arbitrary) name in the form <path-nodot> believed to
+ be unique and registered at least with all the other news servers
+ to which that relaying agent or injecting agent sends articles.
+ This option SHOULD NOT be used unless the earlier options are
+ unavailable or unless the name is of longstanding usage.
+
+ Path identities are case sensitive. To avoid unintentional variation
+ in a news server's identity, the <path-identity> SHOULD be all
+ lowercase.
--- usepro-06 Mon Dec 11 16:09:21 2006
+++ allbery-00 Mon Dec 11 16:09:21 2006
@@ -1,185 +1,107 @@
-7.2. Duties of an Injecting Agent
+3.4. Duties of an Injecting Agent
- An Injecting Agent is responsible for taking a (proto-)article from a
- posting (or other) agent and either forwarding it to a moderator or
- injecting it into the relaying system for access by readers.
-
- As such, an injecting agent is considered responsible for ensuring
- that any article it injects conforms with the rules of [USEFOR]. It
- is also expected to bear some responsibility towards the rest of the
- network for the behaviour of its posters.
-
- In the normal course of events, an article that has already been
- injected into a Netnews network will never pass through another
- injecting agent. So, if an injecting agent receives an otherwise
- valid article that has already been injected (as evidenced by the
- presence of an Injection-Date header field, an Injection-Info header
- field, or more than one "POSTED" in a Path header field) it MAY
- choose to reject it, but otherwise SHOULD cause it to be relayed, as
- it stands, by a relaying agent (7.3).
-
- In exceptional circumstances (e.g. as part of some complex gatewaying
- process, or where a relaying agent considers it essential for
- fulfilling its responsibility towards the rest of the network) an
- already injected article MAY be "reinjected" into the network. This
- standard does not prescribe any such circumstance; rather this is a
- matter of policy to be determined by the administrators of each
- injecting agent, who have the responsibility to ensure that no harm
- arises. In all other circumstances, unintented reinjection is to be
- avoided (see 7.9). Nevertheless, in order to preserve the integrity
- of the network in these special cases, this standard does set out the
- correct way to reinject (see special provisions in 7.2.2 Steps 3, 7
- and 9).
-
- It is usual for an injecting agent to be closely associated with a
- serving agent, thus giving it access to the list (7.4) showing the
- moderation status of the newsgroups it is likely to handle. In the
- event that it does not have such an associated serving agent, it MUST
- maintain that list itself.
-
-7.2.1. Proto-articles
-
- A proto-article SHOULD NOT be propagated in that form to other than
- injecting agents.
-
- A proto-article has the same format as a normal article except that
- some of the following mandatory header fields MAY be omitted:
- Message-Id, Date, Path (and even From if the particular injecting
- agent can derive that information from other sources). However, if
- it is intended to offer the proto-article to two or more injecting
- agents in parallel, then it is only the Path header field that MAY be
- omitted. The header fields that can be omitted MUST NOT contain
- invalid values; they MUST either be correct or not present at all.
-[Maybe omit that last sentence.]
-
- NOTE: An article that is offered for reinjection has, by
- definition, already been injected once, and is not therefore to
- be considered as a proto-article. Hence a genuine proto-article
- will not contain any Injection-Date header field nor any
- "POSTED" in its Path header field, though that header field MAY
- contain <path-identity>s corresponding to machines traversed
- between the posting agent and the injecting agent proper.
-
-7.2.2. Procedure to be followed by Injecting Agents
-
- An injecting agent receives (proto-)articles from posting and
- followup agents. It verifies them, adds header fields where required,
- and then either forwards them to a moderator or injects them by
- passing them to serving or relaying agents. It MUST NOT forward an
- already injected article to a moderator.
-
- An injecting agent processes articles as follows:
-
- 1. It MUST remove any Injection-Info header field already present
- (though it might be useful to copy it to a suitable "X-" header
- field). It SHOULD likewise remove any NNTP-Posting-Host, X-Trace,
- or other non-standard tracing header field.
-
- 2. It SHOULD verify that the article is from a trusted source, and
- MAY reject articles in which header fields contain unverified
- email addresses, that is, addresses which are not known to be
- valid for the trusted source, though it would be perverse to
- reject intentionally unverifiable addresses such as those ending
- in ".invalid" (7.5).
-
- 3. It SHOULD reject any article whose Date header field (F-3.1.2) is
- more than 24 hours into the future (and MAY use a margin less than
- that 24 hours). It MUST (except when reinjecting) reject any
- article with an Injection-Date header field already present (and
- SHOULD do likewise with any NNTP-Posting-Date header field). When
- reinjecting it MAY, in the absence of any Injection-Date header
- field, reject any article whose Date header field appears to be
- stale (e.g. more than 72 hours into the past).
-
- 4. It MUST reject any article that does not have the proper mandatory
- header fields for a proto-article or which contains any header
- field that does not have legal contents. It SHOULD reject any
- article which contains any header field deprecated for Netnews
- (e.g. as in [RFC 2298]). It SHOULD reject any article whose
- Newsgroups header field does not contain at least one <newsgroup-
- name> for an existing group (as listed by its associated serving
- agent) and it MAY reject any <newsgroup-name> which violates one
- of the restrictions in F-3.1.5 or which, although otherwise
- correct, violates a policy restriction established, for some
- (sub-)hierarchy, by an agency with the appropriate authority
- (1.2). Observe that crossposting to unknown newsgroups is not
- precluded provided at least one of those in the Newsgroups header
- field is listed.
-
- NOTE: This ability to reject <newsgroup-name>s in breach of
- established policy does not extend to relaying agents, though it
- might be reasonable for posting agents to do it.
-
- 5. If the article is rejected (for reasons given above, or for other
- formatting errors or matters of site policy) the posting agent
- SHOULD be informed (such as via an NNTP 44x response code) that
- posting has failed and the article MUST NOT then be processed
- further.
-
-
-
- 6. The Message-ID, Date and From header fields (with appropriate
- contents) MUST be added when not already present. A User-Agent
- header field MAY be added (or an already present User-Agent header
- field MAY be augmented) so as to identify the software (e.g.
- "INN/1.7.2") used by the injecting agent.
-[That last sentence may need to be reconsidered (in which case see
-consequential change in 7.3).]
-
- NOTE: The Message-ID, Date and From fields will already be
- present during reinjection.
-
- 7. The injecting agent MUST NOT alter the body of the article in any
- way (including any change of Content-Transfer-Encoding). It MAY
- (except when reinjecting) add other header fields not already
- provided by the poster, but SHOULD NOT alter, delete, or reorder
- any existing header field, with the specific exception of the
- "tracing" header field Injection-Info, which is to be removed as
- already mentioned.
-
- 8. If the Newsgroups header field contains one or more moderated
- groups and the article does NOT contain an Approved header field,
- the injecting agent MUST forward it to a moderator as specified in
- section 7.2.3 below.
-
- 9. Otherwise, a Path header field with a <tail-entry> (F-3.1.6) MUST
- be correctly added if not already present. During reinjection, the
- existing Path header field SHOULD be retained.
-
- 10.It MUST then prepend the <path-identity> of the injecting agent,
- followed by a '!', the <path-keyword> "POSTED" and a further "!"
- (or "!!" if appropriate) to the content of the Path header field;
- this header field SHOULD then be folded if it would otherwise
- result in a header line of excessive length.
-[This may need further changes depending on the resolution of ticket
-#1047.]
-
- NOTE: This could result in more that one "POSTED" <path-keyword>
- in the case of reinjection.
-
- 11.An Injection-Info header field (F-3.2.14) SHOULD be added,
- identifying the trusted source of the article and possibly an
- address for mailing complaints to. Each injecting agent SHOULD
- use a consistent form of the Injection-Info header field for all
- articles emanating from the same or similar origins.
-
- NOTE: The step above is the only place in which an Injection-
- Info header field is to be created. It follows that this header
- field MUST NOT be created, replaced, changed or deleted by any
- other agent (except during reinjection, in which case it will
- always relate to the latest injection and is, to that extent,
- regarded as a variant header field).
+ An injecting agent takes a proto-article from a posting agent and
+ either forwards it to a moderator or passes it to a relaying or
+ serving agent or agents. An injecting agent bears the primary
+ responsibility for ensuring that any article it injects conforms with
+ the rules of the Netnews standards. The administrator of an
+ injecting agent is also expected to bear some responsibility towards
+ the rest of the Netnews network to which it is connected for the
+ articles the injecting agent accepts.
+
+ Injecting agents, when rejecting articles, are encouraged to
+ communicate the reason for rejection to the posting agent using
+ whatever facility is provided by the underlying transport. The
+ injecting agent is in a unique position to communicate the reason for
+ rejection; relaying agents and serving agents normally have to reject
+ messages silently. The injecting agent therefore bears much of the
+ burden of diagnosing broken posting agents or communicating policy
+ violations to posters.
+
+ An injecting agent MUST have available a list (possibly empty) of
+ moderated groups for which it accepts articles and the corresponding
+ submission addresses. It SHOULD have available a list of valid
+ newsgroups to catch articles not posted to a valid newsgroup and
+ therefore likely to be silently discarded by relaying and serving
+ agents. Usually, an injecting agent is deployed in conjunction with
+ a serving agent and maintains these lists based on control messages
+ received by the serving agent.
+
+ An injecting agent processes proto-articles as follows:
+
+ 1. It SHOULD verify that the article is from a trusted source (by,
+ for example, relying on the authorization capability of the
+ underlying transport used to talk to the posting agent).
+
+ 2. It MUST reject any proto-article that does not have the proper
+ mandatory header fields for a proto-article; that has Injection-
+ Date, Injection-Info, or Xref header fields; that has a Path
+ header field containing the "POSTED" <diag-keyword>; or that is
+ not syntactically valid as defined by [USEFOR]. It SHOULD
+ reject any proto-article which contains a header field
+ deprecated for Netnews. It MAY reject any proto-article that
+ contains trace header fields indicating that it was already
+ injected by an injecting agent that did not add Injection-Info
+ or Injection-Date.
+
+ 3. It SHOULD reject any article whose Date header field is more
+ than 24 hours into the future (and MAY use a margin less than 24
+ hours). It SHOULD reject any article whose Date header appears
+ to be stale (more than 72 hours into the past, for example, or
+ too old to still be recorded in the database of a relaying agent
+ the injecting agent will be using) since not all news servers
+ support Injection-Date.
+
+ 4. It SHOULD reject any proto-article whose Newsgroups header field
+ does not contain at least one <newsgroup-name> for a valid
+ group, or containing a <newsgroup-name> reserved for specific
+ purposes by Section 3.1.4 of [USEFOR] unless that specific
+ purpose or local agreement applies to the proto-article being
+ processed. Crossposting to unknown newsgroups is not precluded
+ provided that at least one of the newsgroups in the Newsgroups
+ header is valid.
+
+ 5. The Message-ID and Date header fields with appropriate contents
+ MUST be added when not present in the proto-article.
+
+ 6. The injecting agent MUST NOT alter the body of the article in
+ any way (including any change of Content-Transfer-Encoding). It
+ MAY add other header fields not already provided by the poster,
+ but injecting agents are encouraged to use the Injection-Info
+ header for such information and to minimize the addition of
+ other headers. It SHOULD NOT alter, delete, or reorder any
+ existing header field except the Path header.
+
+ 7. If the Newsgroups header contains one or more moderated groups
+ and the proto-article does not contain an Approved header field,
+ the injecting agent SHOULD forward it to a moderator as
+ specified in Section 3.4.1. If the article cannot be forwarded
+ to a moderator for some reason, it MUST be rejected. This
+ forwarding MUST be done after adding the Message-ID and Date
+ headers if required, and before adding the Injection-Info and
+ Injection-Date headers.
+
+ 8. Otherwise, a Path header field with a <tail-entry> MUST be added
+ if not already present.
+
+ 9. The injecting agent SHOULD then prepend the <path-identity> of
+ the injecting agent followed by "!.POSTED", optionally "." and
+ the FQDN or IP address of the source, and a further "!" to the
+ content of the Path header field. If the injecting agent does
+ not support the use of <diag-keyword>, it MUST instead prepend
+ its <path-identity> followed by "!"; one or the other of these
+ mechanisms MUST be used.
+
+ 10. The relaying agent MAY fold the Path header field by inserting
+ FWS immediately after the <path-identity> it added.
+
+ 11. An Injection-Info header field SHOULD be added identifying the
+ source of the article and possibly other trace information as
+ described in Section 3.2.8 of [USEFOR].
12.The injecting agent MUST then add an Injection-Date header field
- (F-3.2.1) if one is not already present, but it MUST NOT alter, or
- delete, an already present Injection-Date header field (and
- likewise SHOULD NOT alter, or delete, an already present NNTP-
- Posting-Date header field). Finally, it forwards the article to
- one or more relaying or serving agents, and the injection process
- is to be considered complete.
-
- NOTE: The step above is the only place where an Injection-Date
- header field is to be created It follows that it MUST NOT
- subsequently be replaced, changed or deleted by any other agent,
- even during reinjection.
+ containing the current date and time.
+
+ 13. Finally, the injecting agent forwards the article to one or more
+ relaying agents, and the injection process is complete.
--- usepro-06 Mon Dec 11 16:09:22 2006
+++ allbery-00 Mon Dec 11 16:09:22 2006
@@ -1,43 +1,46 @@
-7.2.3. Procedure for Forwarding to a Moderator
+3.4.1. Forwarding Messages to a Moderator
- An injecting agent forwards an article to a moderator as follows:
-
- 1. It MUST forward it to the moderator of the first (leftmost)
- moderated group listed in the Newsgroups header field, customarily
- via email, (see 7.8 for how that moderator may forward it to
- further moderators). There are two possibilities for doing this:
-
- (a) The complete article is encapsulated (header fields and all)
- within the email, preferably using the Content-Type
- "application/news-transmission" (5.1) with any usage
- parameter set to "moderate". Moreover, there SHOULD NOT be
- more than one encapsulated article within the one email.
- This method has the advantage of removing any possible
- conflict between Netnews and Email header fields, or of
- changes to those fields during transport through email.
-
- (b) The article is sent as an email as it stands, with the
- addition of such extra header fields (e.g. a To header field)
- as are necessary for an email. The existing Message-ID header
- field SHOULD be retained.
-
- Although both of these methods have seen use in the past, the
- preponderance of current usage on Usenet has been for method (b)
- and many moderators are ill-prepared to deal with method (a).
- Therefore, method (a) SHOULD NOT be used until such time as the
- majority of moderators are able to accept it.
-
- 2. This standard does not prescribe how the email address of the
- moderator is to be determined, that being a matter of policy to be
- arranged by the agency responsible for the oversight of each
- hierarchy. Nevertheless, there do exist various agents worldwide
- which provide the service of forwarding to moderators, and the
- address to use with them is obtained as follows:
-
- (a) Each '.' in the <newsgroup-name> is replaced with a '-'.
-
- (b) The result of these operations is used as the <local-part> of
- the <mailbox> of the agent. For example, articles intended
- for "news.announce.important" would be emailed to "news-
- announce-important@forwardingagent.example".
+ An injecting agent MUST forward the proto-article to the moderator of
+ the leftmost moderated group listed in the Newsgroups header field,
+ customarily via email. There are two standard ways in which it may
+ do this:
+
+ 1. The complete proto-article is encapsulated, header fields and
+ all, within the email. This SHOULD be done by creating an email
+ message with a Content-Type of application/news-transmission with
+ the usage parameter set to "moderate". The body SHOULD NOT
+ contain any content other than the message. This method has the
+ advantage of removing any possible conflict between Netnews and
+ email header fields and any changes to those fields during
+ transport through email.
+
+ 2. The proto-article is sent as an email with the addition of any
+ header fields (such as a To header field) required for an email.
+ The existing Message-ID header field SHOULD be retained.
+
+ Although both of these methods have been used in the past and the
+ first has clear technical advantages, the second is in more common
+ use and many moderators are not prepared to deal with messages in the
+ first format. Accordingly, the first method SHOULD NOT be used
+ unless the moderator to which it is being forwarded is known to be
+ able to handle this method.
+
+ NOTE: Deriving the email address of the moderator of a group is
+ outside the scope of this document. It is worth mentioning,
+ however, that a common method is to use a forwarding service that
+ handles submissions for many moderated groups. For maximum
+ compatibility with existing news servers, such forwarding services
+ generally form the submission address for a moderated group by
+ replacing each "." in the <newsgroup-name> with "-" and then using
+ that value as the <local-part> of a <mailbox> formed by appending
+ a set domain.
+
+ Forwarding proto-articles to moderators via email is the most general
+ method and most common in large Netnews networks such as Usenet, but
+ any means of forwarding the article that preserves it without
+ injecting it MAY be used. For example, if the injecting agent has
+ access to a database used by the moderator to store proto-articles
+ awaiting processing, it may place the proto-article directly into
+ that database. Such methods may be more appropriate for smaller
+ Netnews networks.
--- usepro-06 Mon Dec 11 16:09:22 2006
+++ allbery-00 Mon Dec 11 16:09:23 2006
@@ -1,152 +1,98 @@
-7.3. Duties of a Relaying Agent
+3.5. Duties of a Relaying Agent
A Relaying Agent accepts injected articles from injecting and other
- relaying agents and passes them on to relaying or serving agents
- according to mutually agreed policy. Relaying agents SHOULD accept
- articles ONLY from trusted agents.
-
+ relaying agents and passes them on to relaying or serving agents. To
+ avoid bypass of injecting agent policies and forgery of Path and
+ Injector-Info headers, relaying agents SHOULD accept articles only
+ from trusted agents.
An article SHOULD NOT be relayed unless the sending agent has been
configured to supply and the receiving agent to receive at least one
of the <newsgroup-name>s in its Newsgroups header field and at least
- one of the <dist-name>s in its Distribution header field, if any.
- Exceptionally, ALL relaying agents are deemed willing to supply or
- accept the <dist-name> "world", and NO relaying agent should supply
- or accept the <dist-name> "local".
-
- However, if the particular implementation does not relay non-existent
- newsgroups, even when included in the Newsgroups header field and
- implied (e.g. by some "wild card" notation) in the configuration
- tables, then the agent MUST examine all group control messages (6.2)
- in order to ensure that relaying of those messages proceeds normally.
-
- NOTE: Although it would seem redundant to filter out unwanted
- distributions at both ends of a relaying link (and it is clearly
- more efficient to do so at the sending end), many sending sites
- have been reluctant, historically speaking, to apply such
- filters (except to ensure that distributions local to their own
- site or cooperating subnet did not escape); moreover they tended
- to configure their filters on an "all but those listed" basis,
- so that new and hitherto unheard of distributions would not be
- caught. Indeed many "hub" sites actually wanted to receive all
- possible distributions so that they could feed on to their
- clients in all possible geographical (or organizational)
- regions.
-
- Therefore, it is desirable to provide facilities for rejecting
- unwanted distributions at the receiving end. Indeed, it may be
- simpler to do so locally than to inform each sending site of
- what is required, especially in the case of specialized
- distributions (for example for control messages, such as cancels
- from certain issuers) which might need to be added at short
- notice. A similar possibility for reading agents to filter
- distributions is also suggested in [USEAGE]) for the same
- reason.
-
- In order to avoid unnecessary relaying, an article SHOULD NOT be
- relayed if the <path-identity> of the receiving agent (or some known
- alias thereof) appears as a <path-identity> (excluding within the
- <tail-entry>) in its Path header field.
-
- A relaying agent processes articles as follows:
-
- 1. It MUST establish the trusted identity of the source of the
- article and compare it with the leftmost <path-identity> of the
- Path header field's content. If it matches it MUST then prepend
- its own <path-identity> and a '!!' <path-delimiter> to that
- content. If it does not match then it prepends instead two entries
- to that content; firstly the true established <path-identity> of
- the source followed by a '!', the <path-keyword> "MISMATCH" and a
- further '!', and then, to the left of that, its own <path-
- identity> followed by a '!!' <path-delimiter> as usual. This
- prepending of two entries SHOULD NOT be done if the provided and
- established identities match. This header field SHOULD then be
- folded if it would otherwise result in a header line of excessive
- length.
-
-[This may need further changes depending on the resolution of ticket
-#1047.]
-[It has been suggested that relaying agents should be permitted to
-prepend more than the one or two entries permitted above.]
-[something like the following from Diablo might also be useful:
->>> NOTE <<< you should grep through newly created spool directories
-every so often looking for .MISMATCH in the spool files to locate
-incoming feeds with improperly configured I found that four of my 80+
-feeds were misconfigured. ]
-
- NOTE: In order to prevent overloading, relaying agents should
- not routinely query an external entity (such as a DNS-server) in
- order to verify an article (though a local cache of the required
- information might usefully be consulted).
-
- 2. It MUST examine the Injection-Date header field (or, if that is
- absent, the Date header field) and reject the article as stale
- (F-3.2.1) if that predates the earliest articles of which it
- normally keeps record, or if it is more than 24 hours into the
- future (the margin MAY be less than that 24 hours).
-
- 3. It SHOULD reject any article that does not include all the
- mandatory header fields (section F-3.1).
-
- 4. It MAY reject any article whose header fields do not have legal
- contents.
-
- 5. It SHOULD reject any article that has already been sent to it (a
- database of message identifiers of recent messages is usually kept
- and matched against).
-
- NOTE: Even though commonly derived from the domain name of the
- originating site (and domain names are case-insensitive), a
- message identifier MUST NOT be altered in any way during
- transport, or when copied (as when forming a References header
- field), and thus a simple (case-sensitive) comparison of octets
- will always suffice to recognize that same message identifier
- wherever it subsequently reappears.
-
- NOTE: These requirements are to be contrasted with those of the
- un-normalized msg-ids defined by [RFC 2822], which may perfectly
- legitimately become normalized (or vice versa) during transport
- or copying in email systems.
-
- 6. It SHOULD reject any article that matches an already received
- cancel message (or an equivalent Supersedes header field) issued
- by its poster or by some other trusted entity.
-
- 7. It MAY reject any article without an Approved header field posted
- to newsgroups known to be moderated (this practice is strongly
- recommended, but the information necessary to do so may not be
- available to all agents).
-
- 8. It MAY delete any Xref header field that is present.
-
- 9. Finally, it passes the articles on to neighbouring relaying and
- serving agents.
-
- If the article is rejected as being invalid, unwanted or unacceptable
- due to site policy, the agent that passed the article to the relaying
- agent SHOULD be informed (such as via an NNTP 43x response code) that
- relaying failed. In order to prevent a large number of error messages
- being sent to one location, relaying agents MUST NOT inform any other
- external entity that an article was not relayed UNLESS that external
+ one of the <dist-name>s in its Distribution header field (if
+ present). Exceptionally, control messages creating new newsgroups
+ (newgroup control messages) SHOULD be relayed if the sending agent
+ has been configured to supply and the receiving agent to receive the
+ newsgroup affected by the control message, even if that newsgroup
+ does not currently exist and even if the control message does not
+ contain that group in its Newsgroups header field.
+
+ In order to avoid unnecessary relaying attempts, an article SHOULD
+ NOT be relayed if the <path-identity> of the receiving agent (or some
+ known alias thereof) appears as a <path-identity> (excluding within
+ the <tail-entry> or following a "POSTED" <diag-keyword>) in its Path
+ header field.
+
+ A relaying agent processes an article as follows:
+
+ 1. It MUST reject any article without a Newsgroups header field or
+ Message-ID header field, or without either an Injection-Date or
+ Date header field.
+ 2. It MUST reject any article that has already been successfully
+ sent to it, based on the Message-ID header field of the article.
+ To satisfy this requirement, a relaying agent normally keeps a
+ database of message identifiers it has already accepted.
+
+ 3. It MUST examine the Injection-Date header field or, if absent,
+ the Date header field, and reject the article if that date
+ predates the earliest articles of which it keeps record or if
+ that date is more than 24 hours into the future. It MAY reject
+ articles with dates in the future with a smaller margin than 24
+ hours.
+
+ 4. It SHOULD reject any article that does not include all the
+ mandatory header fields. It MAY reject any article that
+ contains header fields that do not have valid contents.
+
+ 5. It SHOULD reject any article that matches an already-received
+ cancel control message or the contents of the Supersedes header
+ field of an accepted article, provided that the relaying agent
+ chose (on the basis of local site policy) to honor that cancel
+ control message or Supersedes header field.
+
+ 6. It MAY reject any article without an Approved header field
+ posted to a newsgroup known to be moderated. This practice is
+ strongly encouraged but the information necessary to do so is
+ not required to be maintained by a relaying agent.
+
+ 7. If the relaying agent is processing an article from an injecting
+ agent that is part of the same news server, it MAY leave the
+ Path header field unmodified.
+
+ Otherwise, it SHOULD compare the expected <path-identity> of the
+ source of the article with the leftmost <path-identity> of the
+ Path header field's content. If those identities match, it
+ SHOULD then prepend "!!" to that content. If those identities
+ do not match, it SHOULD instead prepend "!.MISMATCH.", the true
+ established <path-identity> of the source or its IP address, and
+ a further "!". If the relaying agent is not able or willing to
+ verify the path identity of the source of the article, it MUST
+ prepend "!" to the Path header field's content, optionally
+ preceded by "!.SEEN." and the FQDN, IP address, or expected
+ <path-identity> of the source. Regardless of which method it
+ used, the relaying agent MUST then prepend its own <path-
+ identity> to the Path header field content.
+
+ 8. If it added a <path-identity>, the relaying agent MAY fold the
+ Path header field by inserting FWS immediately after the final
+ (rightmost) <path-identity> it added.
+ 9. It MAY delete any Xref header field present and MAY add a new
+ Xref header field with any valid content. The Xref header field
+ is not used by relaying agents, but relaying agents that are
+ also serving agents may generate Xref header fields for their
+ own internal purposes.
+
+ 10. Finally, it passes the article on to other relaying and serving
+ agents to which it is configured to send articles.
+
+ Relaying agents SHOULD, where possible in the underlying transport,
+ inform the agent that passed the article to the relaying agent if the
+ article was rejected. Relaying agents MUST NOT inform any other
+ external entity of the rejection of an article unless that external
entity has explicitly requested that it be informed of such errors.
- Relaying agents MUST NOT alter, delete or rearrange any part of an
- article except for header fields designated as variant (2.4). In
- particular
-
- o they MUST NOT create or augment a User-Agent header field in
- order to identify themselves;
- o they MUST NOT rewrite the Newsgroups header field in any way,
- even if some supposedly non-existent newsgroup is included;
- o they MUST NOT refold any header field (i.e. they must pass on the
- folding as received);
- o they MUST NOT alter the Date header field or the Injection-Date
- header field;
- o they MUST NOT delete any unrecognized header field whose field
- name is syntactically correct (whether or not it is registered
- with IANA [RFC 3864]);
- o they MUST NOT change the Content-Transfer-Encoding of the body or
- any body part;
- o they MUST transmit lines of arbitrary length and articles of
- arbitrary size.
+ Relaying agents MUST NOT alter, delete, or rearrange any part of an
+ article except for the Path and Xref header fields. They MUST NOT
+ modify the body of articles in any way. If an article is not
+ acceptable as-is, the article MUST be rejected rather than modified.
--- usepro-06 Mon Dec 11 16:09:23 2006
+++ allbery-00 Mon Dec 11 16:09:23 2006
@@ -1,44 +1,45 @@
-7.3.1. Path Header Field Example
+3.5.1. Path Header Field Example
- Path: foo.isp.example!!foo-server!!bar.isp.example!MISMATCH!
- 2001:DB8:0:0:8:800:200C:417A!!old.site.example!barbaz!!
- baz.isp.example!POSTED!!dialup123.baz.isp.example!not-for-mail
-
- NOTE: That article was injected into the news stream by
- baz.isp.example, as indicated by the <path-keyword> "POSTED"
- (complaints may be addressed to abuse@baz.isp.example). The
- injector has chosen to record that it got it from
- dialup123.baz.isp.example. "not-for-mail" is a dummy <tail-
- entry>, though sometimes a real userid is put there.
-
- The article was relayed, perhaps by UUCP, to the machine known,
- at least to old.site.example, as "barbaz".
-
- Barbaz relayed it to old.site.example, which does not yet
- conform to this standard (hence the '!' <path-delimiter). So one
- cannot be sure that it really came from barbaz.
-
- Old.site.example relayed it to a site claiming to have the IPv6
- address [2001:DB8:0:0:8:800:200C:417A], and claiming (by using
- the '!!' <path-delimiter>) to have verified that it came from
- old.site.example.
-
- [2001:DB8:0:0:8:800:200C:417A] relayed it to "foo-server" which,
- not being convinced that it truly came from
- [2001:DB8:0:0:8:800:200C:417A], inserted the <path-keyword>
- "MISMATCH" and then did a reverse lookup on the actual source
- and concluded it was known as bar.isp.example (that is not to
- say that [2001:DB8:0:0:8:800:200C:417A] was not a correct IPv6
- address for bar.isp.example, but simply that that connection
- could not be substantiated by foo-server). Observe that foo-
- server has now added two entries to the Path.
-
- "foo-server" is a locally significant name within the complex
- site of many machines run by foo.isp.example, so the latter
- should have no problem recognizing foo-server and using a '!!'
- <path-delimiter>. Presumably foo.isp.example then delivered the
- article to its direct clients.
+ Here is an example of a Path header field created following the rules
+ for injecting and relaying agents.
- It appears that foo-server and barbaz decided to fold the line,
- on the grounds that it seemed to be getting a little too long.
+Path: foo.isp.example!.SEEN.isp.example!!foo-news
+ !.MISMATCH.2001:DB:0:0:8:800:200C:417A!bar.isp.example
+ !!old.site.example!barbaz!!baz.isp.example
+ !.POSTED.dialup123.baz.isp.example!not-for-mail
+
+ This article was injected by baz.isp.example as indicated by the
+ <diag-keyword> "POSTED". The injector has recorded that it received
+ the article from dialup123.baz.isp.example. "not-for-mail is a common
+ <tail-entry>.
+
+ The article was relayed to the relaying agent known, at least to
+ old.site.example, as "barbaz".
+
+ barbaz relayed it to old.site.example, which does not support <diag-
+ keyword> and therefore used the old "!" delimiter. This indicates
+ that the identity of "barbaz" was not verified and may have been
+ forged.
+
+ old.site.example relayed it to a news server using the <path-
+ identity> of bar.isp.example and claiming (by using the "!!" <path-
+ delimiter>) to have verified that it came from old.site.example.
+
+ bar.isp.example relayed it to foo-news which, not being convinced
+ that it truly came from bar.isp.example, inserted the <diag-keyword>
+ "MISMATCH" and then stated that it received the article from the IPv6
+ address [2001:DB8:0:0:8:800:200C:417A]. (This is not to say that
+ bar.isp.example was not a correct <path-identity> for that source but
+ simply that that identity did not match the expectations of foo-news.
+
+ foo-news then passed the article to foo.isp.example, which declined
+ to validate its <path-identity> and instead appended the <diag-
+ keyword> "SEEN" to indicate it knows the source of the article as
+ isp.example. This may be either an expected <path-identity> or the
+ FQDN of the system from which it received the article. Presumably
+ foo.isp.example is a serving agent that then delivered the article to
+ a reading agent.
+
+ baz.isp.example, bar.isp.example, and foo-news folded the Path header
+ field.
--- usepro-06 Mon Dec 11 16:09:24 2006
+++ allbery-00 Mon Dec 11 16:09:24 2006
@@ -1,74 +1,62 @@
-7.4. Duties of a Serving Agent
+3.6. Duties of a Serving Agent
- A Serving Agent takes an article from a relaying or injecting agent
- and files it in a "news database". It also provides an interface for
- reading agents to access the news database. This database is normally
- indexed by newsgroup with articles in each newsgroup identified by an
- <article-locator> (usually in the form of a decimal number - see F-
- 3.2.11).
-
- A serving agent MUST maintain a list of the newsgroups it stores in
- its news database showing the moderation status of each one (see
- 6.2.1), and SHOULD include in that list all groups likely to be
- crossposted to from those groups (e.g. all other groups in the same
- hierarchy(ies)).
-
- NOTE: Since control messages are often of interest, but should
- not be displayed as normal articles in regular newsgroups, it is
- common for serving agents to make them available in a pseudo-
- newsgroup named "control" or in a pseudo-newsgroup in a sub-
- hierarchy under "control." (e.g. "control.cancel").
-
- A serving agent MAY decline to accept an article if the Path header
- field contains some <path-identity> whose articles the serving agent
- does not want, as a matter of local policy.
-
- NOTE: This last facility is sometimes used to detect and decline
- control messages (notably cancel messages) which have been
- deliberately seeded with a <path-identity> to be "aliased out"
- by sites not wishing to act upon them.
-[INN at least does this. It might be argued that it is not necessary to
-mention it here.]
+ A serving agent accepts articles from a relaying agent or injecting
+ agent, stores it, and makes it available to reading agents. Articles
+ are normally indexed by newsgroup and <article-locator> (Section
+ 3.2.14 of [USEFOR]), usually in the form of a decimal number.
+
+ If the serving agent stores articles by newsgroup, control messages
+ SHOULD NOT be stored in the newsgroups listed in the control
+ message's Newsgroups header field. Instead, they SHOULD be stored in
+ a newsgroup in the hierarchy "control", which is reserved for this
+ purpose. Conventionally, control messages are stored in newsgroups
+ named for the type of control message (such as "control.cancel" for
+ cancel control messages).
+
+ A serving agent MUST have available a list (possibly empty) of
+ moderated groups for which it accepts articles so that it can reject
+ unapproved articles posted to moderated groups. Frequently a serving
+ agent is deployed in combination with an injecting agent and can use
+ the same list as the injecting agent.
A serving agent processes articles as follows:
- 1. It MUST establish the trusted identity of the source of the
- article and modify the Path header field as for a relaying agent
- (7.3).
-
- 2. It MUST examine the Injection-Date header field (or, if that is
- absent, the Date header field) and reject the article as stale
- (F-3.2.1) if that predates the earliest articles of which it
- normally keeps record, or if it is more than 24 hours into the
- future (the margin MAY be less than that 24 hours).
-
- 3. It MUST reject any article that does not include all the mandatory
- header fields (section F-3.1), or which contains any header field
- that does not have legal contents.
-
- 4. It SHOULD reject any article that has already been sent to it (a
- database of message identifiers of recent articles is usually kept
- and matched against).
-
- 5. It SHOULD reject any article that matches an already received
- cancel message (or an equivalent Supersedes header field) issued
- by its poster or by some other trusted entity.
-
- 6. It MUST reject any article without an Approved header field posted
- to any newsgroup listed as moderated.
-
- 7. It MUST (exept when specially configured to preserve the
- <article-locator>s set by the sending site) remove any Xref header
- field (F-3.2.11) from each article. It then MAY (and usually
- will) generate a fresh Xref header field.
+ 1. It MUST reject any article that does not include all the
+ mandatory header fields or any article which contains header
+ fields that do not have valid contents.
+
+ 2. It MUST examine the Injection-Date header field or, if absent,
+ the Date header field, and reject the article if that date
+ predates the earliest articles of which it keeps record or if
+ that date is more than 24 hours into the future. It MAY reject
+ articles with dates in the future with a smaller margin than 24
+ hours.
+
+ 3. It SHOULD reject any article that has already been successfully
+ sent to it or that matches an already-received and honored cancel
+ message or Supersedes header field following the same rules as a
+ relaying agent (Section 3.5).
+
+ 4. It MUST reject any article without an Approved header field
+ posted to any newsgroup listed as moderated.
+
+ 5. It MUST modify the Path header field following the same rules as
+ for a relaying agent (Section 3.5).
+
+ 6. It MUST (except when specially configured to preserve the
+ <article-locator>s set by the sending site) remove any Xref
+ header field from each article. It then MAY (and usually will)
+ generate a fresh Xref header field.
- 8. Finally, it stores the article in its news database.
+ 7. Finally, it stores the article and makes it available for reading
+ agents.
Serving agents MUST NOT create new newsgroups simply because an
- unrecognized <newsgroup-name> occurs in a Newsgroups header field
- (see 6.2.1 for the correct method of newsgroup creation).
+ unrecognized <newsgroup-name> occurs in a Newsgroups header field.
+ Newsgroups are normally created via control messages (Section 5.2.1).
- Serving agents MUST NOT alter, delete or rearrange any part of an
- article in any other way. The list of particular cases given for
- relaying agents (7.3) applies here also.
+ Serving agents MUST NOT alter, delete, or rearrange any part of an
+ article except for the Path and Xref header fields. They MUST NOT
+ modify the body of the articles in any way. If an article is not
+ acceptable as-is, the article MUST be rejected rather than modified.
--- usepro-06 Mon Dec 11 16:09:24 2006
+++ allbery-00 Mon Dec 11 16:09:25 2006
@@ -1,17 +1,19 @@
-7.5. Duties of a Posting Agent
+3.3. Duties of a Posting Agent
- A Posting Agent is used to assist the poster in creating a valid
- proto-article and forwarding it to an injecting agent.
+ A posting agent is the component of a user agent that assists a
+ poster in creating a valid proto-article and forwarding it to an
+ injecting agent.
- Postings agents SHOULD ensure that proto-articles they create are
- valid according to [USEFOR] and other applicable policies. In
- particular, they MUST NOT create any Injection-Date or Injection-Info
- header field.
+ Posting agents SHOULD ensure that proto-articles they create are
+ valid according to [USEFOR] and any other applicable policies. They
+ MUST NOT create any Injection-Date or Injection-Info header fields;
+ these headers will be added by the injecting agent.
- Contrary to [RFC 2822], which implies that the mailbox(es) in the
- From header field should be that of the poster(s), a poster who does
- not, for whatever reason, wish to use his own mailbox MAY use any
- mailbox ending in the top level domain ".invalid" [RFC 2606].
+ Contrary to [RFC2822], which implies that the mailbox or mailboxes in
+ the From header field should be that of the poster or posters, a
+ poster who does not, for whatever reason, wish to use his own mailbox
+ MAY use any mailbox ending in the top level domain ".invalid"
+ [RFC2606].
Posting agents meant for use by ordinary posters SHOULD reject any
attempt to post an article which cancels or Supersedes another
--- usepro-06 Mon Dec 11 16:09:26 2006
+++ allbery-00 Mon Dec 11 16:09:26 2006
@@ -1,41 +1,43 @@
-7.6. Duties of a Followup Agent
+3.3.3. Followups
- A Followup Agent is a special case of a posting agent, and as such is
- bound by all the posting agent's requirements. Followup agents MUST
- create valid followups and are subject to special requirements
- involving the Newsgroups, Subject, Distribution and References header
- fields. Wherever in the following it is stated that, "by default", a
- header field is to be "inherited" from one of those header fields in
- the precursor, it means that its initial (semantic) content is to be
- a copy of the content of that precursor header field. However,
- posters MAY then override that default before posting if they so
- wish.
-
- NOTE: The Keywords header field is not inheritable, though some
- older newsreaders treated it as such.
-
- 1. The Newsgroups header field (F-3.1.5) SHOULD by default be
- inherited from the precursor's Followup-To header field if
- present, and otherwise from the precursor's Newsgroups header
- field. However, if the content of that Followup-To header field
- consists of "poster" (and the user does not override it), then the
- followup MUST NOT be posted but, rather, is to be emailed to the
- precursor's poster.
-
- 2. The Subject header field SHOULD by default be inherited from that
- of the precursor. The case sensitive string "Re: " MAY be
- prepended to the content of its Subject header field, unless it
- already begins with that string.
-
- 3. The Distribution header field (F-3.2.7) SHOULD by default be
- inherited from the precursor's Distribution header field, if any.
-
- 4. The followup MUST (in accordance with the definition of that term)
- have a References header field referring to its precursor,
- constructed in accordance with section 7.6.1 below.
-
- NOTE: That "MUST" is to be contrasted with the weaker
- recomendation using "SHOULD" applied, in [RFC 2822], to the
- generation of "replies" in email. Moreover, in Netnews, there is
- no expectation of any In-Reply-To header field in a followup.
+ A followup is an article that contains a response to the contents of
+ an earlier article, its precursor. In addition to its normal duties,
+ a posting agent preparing a followup is also subject to the following
+ requirements. Wherever in the following it is stated that by default
+ a header field is said to be inherited from one of those header
+ fields in the precursor, it means that its initial content is to be a
+ copy of the content of that precursor header field (with changes in
+ folding permitted). However, posters MAY then override that default
+ before posting.
+
+ Despite the historic practice of some posting agents, the Keywords
+ header field SHOULD NOT be inherited by default from the precursor
+ article.
+
+ 1. If the Followup-To header field of the precursor article consists
+ of "poster", the followup MUST NOT be posted by default but by
+ default is to be emailed to the address given in the precursor's
+ Reply-To or From header field following the rules for an email
+ reply [RFC2822]. This action MAY be overridden by the poster, in
+ which case the posting agent should continue as if the
+ Followup-To header field in the precursor did not exist.
+
+ 2. The Newsgroups header field SHOULD by default be inherited from
+ the precursor's Followup-To header field if present, and
+ otherwise from the precursor's Newsgroups header field.
+
+ 3. The Subject header field SHOULD by default be inherited from that
+ of the precursor. The case-sensitive string "Re: " (including
+ the space after the colon) MAY be prepended to the content of its
+ Subject header field unless it already begins with that string.
+
+NOTE: Prepending "Re: " serves no protocol function and hence
+is not required, but it is widely expected and not doing so
+would be surprising.
+
+ 4. The Distribution header field SHOULD by default be inherited from
+ the precursor's Distribution header field, if present.
+
+ 5. The followup MUST have a References header field referring to its
+ precursor constructed in accordance with Section 3.3.4.
--- usepro-06 Mon Dec 11 16:09:27 2006
+++ allbery-00 Mon Dec 11 16:09:27 2006
@@ -1,28 +1,26 @@
-7.6.1. Construction of the References header field
+3.3.4. Construction of the References Header Field
The following procedure is to be used whenever some previous article
- (the "parent") is to be referred to in the References header field
- (F-3.2.2) of a new article, whether in the course of generating a
- followup or for some other reason (e.g. the later parts of a
- multipart posting such as a FAQ, or the later parts of a
- message/partial as suggested in [RFC 2046]).
+ (the "parent") is to be referred to in the References header field of
+ a new article, whether because the new article is a followup and the
+ parent is its precursor or for some other reason.
- The (semantic) content of the new article's References header field
- consists of the content of the Message-ID header field of the parent
- preceded, if the parent had a References header field, by the content
- of that References header field and a SP (subject to trimming as
- described below).
+ The content of the new article's References header field MUST be
+ formed from the content of the parent's References header field if
+ present and the content of the Message-ID header field of the parent.
+ If the parent had a References header, FWS as defined in [USEFOR]
+ MUST be added between its content and the Message-ID header field
+ content.
If the resulting References header field would, after unfolding,
exceed 998 characters in length (including its field name but not the
- final CRLF), it MUST be trimmed (and otherwise it MAY be trimmed).
- Trimming involves removing any number of message identifiers from its
+ final CRLF), it SHOULD be trimmed (and otherwise MAY be trimmed).
+ Trimming means removing any number of message identifiers from its
content, except that the first message identifier and the last two
MUST NOT be removed.
- NOTE: There is no provision in this standard for an article to
- have more than one parent. The essential property of the
- References header field, guaranteed by the procedure above and
- to be preserved in any future extension, is that no article can
- ever precede one of its own parents.
+ An essential property of the References header field, guaranteed by
+ the above procedure and REQUIRED to be maintained by any extensions
+ to this protocol, is that an article MUST NOT precede one of its
+ parents.
--- usepro-06 Mon Dec 11 16:09:27 2006
+++ allbery-00 Mon Dec 11 16:09:28 2006
@@ -1,13 +1,6 @@
-7.7. Duties of a Reading Agent
+3.7. Duties of a Reading Agent
- A reading agent downloads articles from a serving agent, as directed
- by the reader, and displays them to the reader (or processes them in
- some other manner). It SHOULD also have the capability to show the
- raw article exactly as received.
-
- It MAY present lists of articles available for display, and MAY
- structure those lists so as to show the relationships between the
- articles, as determined by the References, Subject, Date and other
- header fields (see [USEAGE] for some usual methods of doing this).
-[This whole section may yet get omitted]
+ Since a reading agent is only a passive participant in a Netnews
+ network, there are no specific protocol requirements placed on it.
+ See [USEAGE] for best-practice recommendations.
--- usepro-06 Mon Dec 11 16:09:28 2006
+++ allbery-00 Mon Dec 11 16:09:28 2006
@@ -1,99 +1,67 @@
-7.8. Duties of a Moderator
+3.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.
+ whether to approve them and, if so, either passes them to an
+ injecting agent 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 field), or
- else directly as an email already containing all the header fields
- 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
- header fields and add Comments and other informational header
- fields). 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.
+ Articles are normally received by the moderator in email either
+ encapsulated as an object of Content-Type application/
+ news-transmission (or possibly encapsulated but without an explicit
+ Content-Type header field), or else directly as an email already
+ containing all the header fields appropriate for a Netnews article
+ (see Section 3.4.1). Moderators who may receive articles via email
+ SHOULD be prepared to accept articles in either format.
+
+ Moderators are entirely free within the Netnews protocol to accept or
+ reject messages based on any criteria and to make arbitrary
+ modifications to articles (both header fields and body). See
+ [USEAGE] for best-practice recommendations. Moderators need to be
+ aware that modifications made to articles may invalidate signatures
+ created by the poster or previous moderators.
+
+ Moderators process articles as follows:
+
+ 1. They decide whether to approve or reject an article, and if
+ approved, make whatever modifications to the article (if any)
+ they choose. If the article is rejected, it is normally rejected
+ for all newsgroups to which it was posted and nothing further is
+ done. If it is approved, the moderator proceeds with the
+ following steps.
2. If the Newsgroups header field 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
- field to the left so that the targeted group is the leftmost
- moderated group in that field, 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 field.
-
- 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 field
- (or a similar but differently named header field if method (b)
- is being used) listing all the approvals made so far, or adding
- a separate header field for each individual approval (the header
- field X-Auth is sometimes used for this purpose). The approval
- may also be confirmed with some form of digital signature (6.1).
+ newsgroups for which approval has not already been given, they
+ may either reach some agreement with the other moderators on the
+ disposition of the article or, more generally, add an indication
+ (identifying both the moderator and the name of the newsgroup)
+ that they approve the article and then forward it to the
+ moderator of the leftmost unapproved newsgroup. This forwarding
+ SHOULD be done following the procedure in Section 3.4.1 and MAY
+ be done by rotating the <newsgroup-name>s in the Newsgroups
+ header field so that the leftmost unapproved newsgroup is is the
+ leftmost moderated newsgroup in that field and then posting it,
+ letting the injecting agent do the forwarding. However, if using
+ this mechanism, they MUST first ensure that the article contains
+ no Approved header field.
3. If the Newsgroups header field contains no further unapproved
- moderated groups, he adds an Approved header field (F-3.2.9)
- 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 field SHOULD be retained. Any Injection-Date
- header field 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 field and the Date
- header field appears to be stale (F-3.2.1) for reasons understood
- by the moderator (e.g. delays in the moderation process) he MAY
- substitute the current date. The Message-ID header field 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 header fields (2.4) MUST be removed, except that a
- Path header field MAY be truncated to only those entries following
- its "POSTED" <path-keyword>. Any Injection-Info header field (F-
- 3.2.14) SHOULD be removed (and if 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.
+ moderated groups, they add an Approved header field (see Section
+ 3.2.1 of [USEFOR]) identifying the moderator and, insofar as is
+ possible, all the other moderators who have approved the article.
+ The moderator who takes this step assumes responsibility for
+ ensuring that the article was approved by the moderators of all
+ moderated newsgroups to which it was posted.
+
+ 4. Moderators are encouraged to retain the Message-ID header field
+ if it is valid, and also retain the Date header field unless it
+ appears to be stale (72 hours or more in the past) for reasons
+ understood by the moderator (such as delays in the moderation
+ process) in which case they MAY substitute the current date. Any
+ Injection-Date, Injection-Info, or Xref header fields already
+ present (though there should be none) MUST be removed.
+
+ 5. Any Path header field MUST either be removed or truncated to only
+ those entries following its "POSTED" <diag-keyword>, if any.
+
+ 6. The moderator then passes the article to an injecting agent,
+ having first observed all the duties of a posting agent.
--- usepro-06 Mon Dec 11 16:09:29 2006
+++ allbery-00 Mon Dec 11 16:09:29 2006
@@ -1,29 +1,31 @@
-7.9. Duties of a Gateway
+3.9. Duties of a Gateway
A Gateway transforms an article into the native message format of
another medium, or translates the messages of another medium into
- news articles. Encapsulation of a news article into a message of MIME
- type application/news-transmission, or the subsequent undoing of that
- encapsulation, is not gatewaying, since it involves no transformation
- of the article.
+ news articles, or transforms articles into proto-articles for
+ injection into a separate Netnews network. Encapsulation of a news
+ article into a message of MIME type application/news-transmission, or
+ the subsequent undoing of that encapsulation, is not gatewaying,
+ since it involves no transformation of the article.
There are two basic types of gateway, the Outgoing Gateway that
transforms a news article into a different type of message, and the
- Incoming Gateway that transforms a message from another medium into a
- news article and injects it into a news system. These are handled
- separately below.
-
- The primary diktat for a gateway is:
-
- Above all, prevent loops.
+ incoming gateway that transforms a message from another network into
+ a news proto-article and injects it into a Netnews network. These
+ are handled separately below.
Transformation of an article into another medium stands a very high
chance of discarding or interfering with the protection inherent in
the news system against duplicate articles. The most common problem
- caused by gateways is "spews", gateway loops that cause previously
- posted articles to be reinjected repeatedly into Usenet. To prevent
- this, a gateway MUST take precautions against loops, as detailed
- below.
+ caused by gateways is loops that repeatedly reinject previously
+ posted articles. To prevent this, a gateway MUST take precautions
+ against loops, as detailed below.
+
+ The transformations applied to the message SHOULD be as minimal as
+ possible while still accomplishing the gatewaying. Every change made
+ by a gateway potentially breaks a property of one of the media or
+ loses information, and therefore only those transformations made
+ necessary by the differences between the media should be applied.
If bidirectional gatewaying (both an incoming and an outgoing
gateway) is being set up between Netnews and some other medium, the
@@ -33,23 +35,14 @@
SHOULD NOT be done; encapsulation of the article SHOULD be used
instead where this is necessary.
- A second general principal of gatewaying is that the transformations
- applied to the message SHOULD be as minimal as possible while still
- accomplishing the gatewaying. Every change made by a gateway
- potentially breaks a property of one of the media or loses
- information, and therefore only those transformations made necessary
- by the differences between the media should be applied.
-
- It is worth noting that safe bidirectional gatewaying between a
- mailing list and a newsgroup is far easier if the newsgroup is
- moderated. Posts to the moderated group and submissions to the
- mailing list can then go through a single point that does the
- necessary gatewaying and then sends the message out to both the
- newsgroup and the mailing list at the same time, eliminating most of
- the possibility of loops. Bidirectional gatewaying between a mailing
- list and an unmoderated newsgroup, in contrast, is difficult to do
- correctly and is far more fragile.
-
+ Safe bidirectional gatewaying between a mailing list and a newsgroup
+ is far easier if the newsgroup is moderated. Posts to the moderated
+ group and submissions to the mailing list can then go through a
+ single point that does the necessary gatewaying and then sends the
+ message out to both the newsgroup and the mailing list at the same
+ time, eliminating most of the possibility of loops. Bidirectional
+ gatewaying between a mailing list and an unmoderated newsgroup, in
+ contrast, is difficult to do correctly and is far more fragile.
Newsgroups intended to be bidirectionally gated to a mailing list
SHOULD therefore be moderated where possible, even if the moderator
is a simple gateway and injecting agent that correctly handles
--- usepro-06 Mon Dec 11 16:09:29 2006
+++ allbery-00 Mon Dec 11 16:09:30 2006
@@ -1,4 +1,4 @@
-7.9.1. Duties of an Outgoing Gateway
+3.9.1. Duties of an Outgoing Gateway
From the perspective of Netnews, an outgoing gateway is just a
special type of reading agent. The exact nature of what the outgoing
@@ -6,12 +6,12 @@
the articles are being gated. The operation of the outgoing gateway
is subject to additional constraints due to the possibility of one or
more corresponding incoming gateways back from that medium to
- Netnews, since this opens the possibility of loops.
+ Netnews, since this raises the danger of loops.
- In general, the following practices are recommended for all outgoing
- gateways, regardless of whether there is known to be a related
- incoming gateway, both as a precautionary measure and as a guideline
- to quality of implementation.
+ The following practices are encouraged for all outgoing gateways,
+ regardless of whether there is known to be a related incoming
+ gateway, both as precautionary measures and as a guideline to quality
+ of implementation:
1. The message identifier of the news article should be preserved if
at all possible, preferably as or within the corresponding unique
@@ -24,15 +24,10 @@
3. The message should be tagged in some way so as to prevent its
reinjection into Netnews. This may be impossible to do without
knowledge of potential incoming gateways, but it is better to try
- to provide some indication even if not successful; at the least, a
- human-readable indication that the article should not be gated
+ to provide some indication even if not successful; at the least,
+ a human-readable indication that the article should not be gated
back to Netnews can help locate a human problem.
4. Netnews control messages should not be gated to another medium
unless they would somehow be meaningful in that medium.
-
- 5. Changes MAY be made to the Content-Transfer-Encoding of some or
- all parts of the body, and even to the charsets specified in
- <encoded-word>s or in Content-Type header fields, but such changes
- SHOULD NOT be made unless absolutely necessary.
--- usepro-06 Mon Dec 11 16:09:30 2006
+++ allbery-00 Mon Dec 11 16:09:31 2006
@@ -1,10 +1,10 @@
-7.9.2. Duties of an Incoming Gateway
+3.9.2. Duties of an Incoming Gateway
- The incoming gateway has the serious responsibility of ensuring that
- all of the requirements of this standard are met by the articles that
- it forms. In addition to its special duties as a gateway, it bears
- all of the duties and responsibilities of an injecting agent as well,
- and additionally has the same responsibility of a relaying agent to
+ The incoming gateway has the responsibility of ensuring that all of
+ the requirements of this protocol are met by the articles that it
+ forms. In addition to its special duties as a gateway, it bears all
+ of the duties and responsibilities of a posting agent as well, and
+ additionally has the same responsibility of a relaying agent to
reject articles that it has already gatewayed.
An incoming gateway MUST NOT gate the same message twice. It may not
@@ -16,52 +16,43 @@
this rule bypassed by modifications of the message that can be
anticipated.
-
-
- News articles prepared by gateways MUST be legal news articles. In
- particular, they MUST include all of the mandatory header fields,
- MUST fully conform to the restrictions on those fields, and SHOULD
- exclude any deprecated header fields (e.g. as in [RFC 2298]). This
- often requires that a gateway function not only as a relaying agent,
- but also partly as a posting agent, aiding in the synthesis of a
- conforming article from non-conforming input.
+ News articles prepared by gateways MUST be valid news proto-articles
+ (see Section 3.3.1). This often requires the gateway to synthesize a
+ conforming article from non-conforming input. The gateway MUST then
+ pass the article to an injecting agent, not directly to a relaying
+ agent.
Incoming gateways MUST NOT pass control messages (articles containing
a Control or Supersedes header field) without removing or renaming
- that header field. Gateways MAY, however, generate their own cancel
- messages, under the general allowance for injecting agents to cancel
- their own messages ([USEAGE]). If a gateway receives a message that
- it can determine is a valid equivalent of a cancel message in the
- medium it is gatewaying, it SHOULD discard that message without
- gatewaying it, generate a corresponding cancel message of its own,
- and inject that cancel message.
-
- Incoming gateways MUST NOT inject control messages other than
- cancels. Encapsulation SHOULD be used instead of gatewaying, when
- direct posting is not possible or desirable.
-
- NOTE: It is not unheard of for mail-to-news gateways to be used
- to post control messages, but encapsulation should be used for
- these cases instead. Gateways by their very nature are
- particularly prone to loops. Spews of normal articles are bad
- enough; spews of control messages with special significance to
- the news system, possibly resulting in high processing load or
- even email sent for every message received, are catastrophic. It
- is far preferable to construct a system specifically for posting
- control messages that can do appropriate consistency checks and
- authentication of the originator of the message.
+ that header field. Gateways MAY, however, generate cancel control
+ messages for messages they have gatewayed. If a gateway receives a
+ message that it can determine is a valid equivalent of a cancel
+ control message in the medium it is gatewaying, it SHOULD discard
+ that message without gatewaying it, generate a corresponding cancel
+ control message of its own, and inject that cancel control message.
+
+ NOTE: It is not unheard of for mail-to-news gateways to be used to
+ post control messages, but encapsulation should be used for these
+ cases instead. Gateways by their very nature are particularly
+ prone to loops. Spews of normal articles are bad enough; spews of
+ control messages with special significance to the news system,
+ possibly resulting in high processing load or even email sent for
+ every message received, are catastrophic. It is far preferable to
+ construct a system specifically for posting control messages that
+ can do appropriate consistency checks and authentication of the
+ originator of the message.
If there is a message identifier that fills a role similar to that of
the Message-ID header field in news, it SHOULD be used in the
formation of the message identifier of the news article, perhaps with
transformations required to meet the uniqueness requirement of
Netnews and with the removal of any comments so as to comply with the
- syntax in section F-3.1.3. Such transformations SHOULD be designed so
- that two messages with the same identifier generate the same
- Message-ID header field.
+ syntax in Section 3.1.3 of [USEFOR]. Such transformations SHOULD be
+ designed so that two messages with the same identifier generate the
+ same Message-ID header field.
- NOTE: Message identifiers play a central role in the prevention
- of duplicates, and their correct use by gateways will do much to
+ NOTE: Message identifiers play a central role in the prevention of
+ duplicates, and their correct use by gateways will do much to
prevent loops. Netnews does, however, require that message
identifiers be unique, and therefore message identifiers from
other media may not be suitable for use without modification. A
@@ -71,38 +62,33 @@
Exceptionally, if there are multiple incoming gateways for a
particular set of messages, each to a different newsgroup(s), each
- one SHOULD generate a message identifier unique to that gateway. Each
- incoming gateway nonetheless MUST ensure that it does not gate the
- same message twice.
-
-
- NOTE: Consider the example of two gateways of a given mailing
- list into the world-wide Usenet newsgroups, both of which
- preserve the email message identifier. Each newsgroup may then
- receive a portion of the messages (different sites seeing
- different portions). In these cases, where there is no one
- "official" gateway, some other method of generating message
- identifiers has to be used to avoid collisions. It would
- obviously be preferable for there to be only one gateway which
- crossposts, but this may not be possible to coordinate.
+ one SHOULD generate a message identifier unique to that gateway.
+ Each incoming gateway nonetheless MUST ensure that it does not gate
+ the same message twice.
+
+ NOTE: Consider the example of two gateways of a given mailing list
+ into two separate Usenet newsgroups, both of which preserve the
+ email message identifier. Each newsgroup may then receive a
+ portion of the messages (different sites seeing different
+ portions). In these cases, where there is no one "official"
+ gateway, some other method of generating message identifiers has
+ to be used to avoid collisions. It would obviously be preferable
+ for there to be only one gateway which crossposts, but this may
+ not be possible to coordinate.
If no date information is available, the gateway MAY supply a Date
- header field with the gateway's current date. If no injection-date
- information is available, the gateway MUST supply an Injection-Date
- header field with whatever date information is available, and
- otherwise with the gateway's current date. If only partial
- information is available (e.g. date but not time), this SHOULD be
- fleshed out to a full Date and/or Injection-Date header field by
- adding default values rather than discarding this information. Only
- in very exceptional circumstances should Date information be
- discarded, as it plays an important role in preventing reinjection of
- old messages.
+ header field with the gateway's current date. If only partial
+ information is available (such as date but not time), this SHOULD be
+ fleshed out to a full Date by adding default values rather than
+ discarding this information. Only in very exceptional circumstances
+ should Date information be discarded, as it plays an important role
+ in preventing reinjection of old messages.
An incoming gateway MUST add a Sender header field to the news
article it forms containing the <mailbox> of the administrator of the
gateway. Problems with the gateway may be reported to this
<mailbox>. The <display-name> portion of this <mailbox> SHOULD
indicate that the entity responsible for injection of the message is
- a gateway. If the original message already had a Sender header field,
- it SHOULD be renamed so that its contents can be preserved.
+ a gateway. If the original message already had a Sender header
+ field, it SHOULD be renamed so that its contents can be preserved.
--- usepro-06 Mon Dec 11 16:09:31 2006
+++ allbery-00 Mon Dec 11 16:09:31 2006
@@ -1,10 +1,10 @@
-7.9.3. Example
+3.9.3. Gateway Example
To illustrate the type of precautions that should be taken against
loops, here is an example of the measures taken by one particular
- combination of mail-to-news and news-to-mail gateways at Stanford
- University designed to handle bidirectional gatewaying between
- mailing lists and unmoderated groups.
+ combination of mail-to-news and news-to-mail gateways designed to
+ handle bidirectional gatewaying between mailing lists and unmoderated
+ groups:
1. The news-to-mail gateway preserves the message identifier of the
news article in the generated email message. The mail-to-news
@@ -16,17 +16,17 @@
2. The news-to-mail gateway adds an X-Gateway header field to all
messages it generates. The mail-to-news gateway discards any
incoming messages containing this header field. This is robust
- against mailing list managers that replace the message identifier,
- and against any number of email hops, provided that the other
- message header fields are preserved.
+ against mailing list managers that replace the message
+ identifier, and against any number of email hops, provided that
+ the other message header fields are preserved.
3. The mail-to-news gateway prepends the host name from which it
received the email message to the content of the Path header
field. The news-to-mail gateway refuses to gateway any message
- that contains the list server name in its Path header field. This
- is robust against any amount of munging of the message header
- fields by the mailing list, provided that the email only goes
- through one hop.
+ that contains the list server name in its Path header field
+ (including in the tail section). This is robust against any
+ amount of munging of the message header fields by the mailing
+ list, provided that the email only goes through one hop.
4. The mail-to-news gateway is designed never to generate bounces to
the envelope sender. Instead, articles that are rejected by the
--- usepro-06 Mon Dec 11 16:09:32 2006
+++ allbery-00 Mon Dec 11 16:09:32 2006
@@ -1,5 +1,11 @@
-5. Definition of new Media Types
+4. Media Types
- This standard defines (or redefines) several new Media Types, which
- require to be registered with IANA as provided for in [RFC 2048].
+ This document defines several media types, which shall be registered
+ with IANA as provided for in [RFC4288].
+
+ The media type message/news, as previously registered with IANA, is
+ hereby declared obsolete. It was never widely implemented, and its
+ default treatment as application/octet-stream by agents that did not
+ recognize it was counter-productive. The media type message/rfc822
+ SHOULD be used in its place.
--- usepro-06 Mon Dec 11 16:09:32 2006
+++ allbery-00 Mon Dec 11 16:09:33 2006
@@ -1,54 +1,37 @@
-5.1. Application/news-transmission
+4.1. application/news-transmission
- The Media Type "application/news-transmission" is intended for the
+ The media type application/news-transmission is intended for the
encapsulation of complete news articles where the intention is that
the recipient should then inject them into Netnews. This Application
type provides one of the methods for mailing articles to moderators
- (see 7.2.2) and it is also the preferred method when sending to an
- email-to-news gateway (see 7.9.2).
+ (see Section 3.4.1) and may be used to convey messages to an
+ injecting agent. This encapsulation removes the need to transform an
+ email message into a Netnews proto-article and provides a way to send
+ a Netnews article using MIME through a transport medium that does not
+ support 8bit data.
- NOTE: The benefit of such encapsulation is that it removes
- possible conflict between news and email header fields and it
- provides a convenient way of "tunnelling" a news article through
- a transport medium that does not support 8bit characters.
-
- The MIME Media Type definition of "application/news-transmission" is:
+ The MIME media type definition of application/news-transmission is:
MIME type name: application
MIME subtype name: news-transmission
Required parameters: none
- Optional parameters: usage=moderate
- usage=inject
- usage=relay
- Encoding considerations: A transfer-encoding (such as Quoted-
- Printable or Base64) different from that of
- the article transmitted MAY be supplied
- (perhaps en route) to ensure correct
- transmission over some 7bit transport
- medium.
- Security considerations: A news article may be a "control message",
- which could have effects on the recipient
- host's system beyond just storage of the
- article. However, such control messages
- also occur in normal news flow, so most
- hosts will already be suitably defended
- against undesired effects.
- Published specification: [USEPRO]
- Body part: A complete article or proto-article, ready
- for injection into Netnews, or a batch of
- such articles in the batch format described
- in section 6.4.
-
- NOTE: It is likely that the recipient of an "application/news-
- transmission" will be a specialized gateway (e.g. a moderator's
- submission address) able to accept articles with only one of the
- three usage parameters "moderate", "inject" and "relay", hence
- the reason why they are optional, being redundant in most
- situations. Nevertheless, they MAY be used to signify the
- originator's intention with regard to the transmission, so
- removing any possible doubt.
-
- When the parameter "relay" is used, or implied, the body part MAY be
- a batch of articles to be transmitted together, in which case the
- batch format defined in section 6.4 MUST be used.
+ Optional parameters: One and only one of "usage=moderate",
+ "usage=inject", or "usage=relay".
+ Encoding considerations: A transfer-encoding different from that of
+ the article transmitted MAY be supplied to
+ ensure correct transmission over some 7bit
+ transport medium.
+ Security considerations: A news article may be a control message,
+ which if processed could have effects on
+ the recipient host's system beyond just
+ storage of the article.
+ Published specification: This specification.
+ Body part: A complete proto-article ready for
+ injection into Netnews or an article being
+ relayed to another agent
+
+ usage=moderate indicates the article is intended for a moderator,
+ usage=inject for an injecting agent, and usage=relay for a relaying
+ agent. The entity receiving the article may only implement one type
+ of agent, in which case the parameter MAY be omitted.
--- usepro-06 Mon Dec 11 16:09:33 2006
+++ allbery-00 Mon Dec 11 16:09:33 2006
@@ -1,29 +1,53 @@
-5.4. Application/news-checkgroups
+4.3. application/news-checkgroups
- The "application/news-checkgroups" Media Type is used in conjunction
- with the "checkgroups" control message (6.2.4). It MUST NOT be used
- except as a part of such control messages.
+ The application/news-checkgroups media type contains a list of
+ newsgroups within a hierarchy or hierarchies, including their
+ descriptions and moderation status. It is primarily for use with the
+ checkgroups control message (see Section 5.2.3).
- The "application/news-checkgroups" body part contains a complete list
- of all the newsgroups in a (sub)hierarchy, their <newsgroup-
- description>s and their moderation status.
-
- The MIME Media Type definition of "application/news-checkgroups" is:
+ The MIME media type definition of application/news-checkgroups is:
MIME type name: application
MIME subtype name: news-checkgroups
Required parameters: none
+ Optional parameters: charset, which MUST be a charset registered
+ for use with MIME text types and has the
+ same syntax as the parameter defined for
+ text/plain [RFC2046]. Specifies the
+ charset of the body part. If not given,
+ the charset defaults to US-ASCII [ASCII].
Disposition: by default, inline
- Encoding considerations: "7bit" or "8bit" is sufficient and MUST be
- used to maintain compatibility.
- Security considerations: this type MUST NOT be used except as part
- of a checkgroups control message
- Published specification: [USEPRO]
-
+ Encoding considerations: 7bit or 8bit MUST be used to maintain
+ compatibility.
+ Security considerations: This media type provides only a means for
+ conveying a list of newsgroups and does not
+ provide any information indicating whether
+ the sender is authorized to state which
+ newsgroups should exist within a hierarchy.
+ Such authorization must be accomplished by
+ other means.
+ Published specification: This specification.
- The content of the "application/news-checkgroups" body part is
- defined as:
+ The content of the application/news-groupinfo body part is defined
+ as:
checkgroups-body = *( valid-group CRLF )
- valid-group = newsgroups-line ; see 5.3
+ valid-group = newsgroups-line ; see 4.2
+
+ The same restrictions on <newsgroup-description> apply for this media
+ type as for application/news-groupinfo.
+
+ One application/news-checkgroups message may contain information for
+ one or more hierarchies and is considered complete for any hierarchy
+ for which it contains a <valid-group>. In other words, an
+ application/news-checkgroups body part consisting of:
+
+ example.moderated A moderated newsgroup (Moderated)
+ example.test An unmoderated test group
+
+ is a statement that the example.* hierarchy contains two newsgroups,
+ example.moderated and example.test, and no others. This media type
+ therefore MUST NOT be used for conveying partial information about a
+ hierarchy; if a group from a given hierarchy is present, all groups
+ that exist in that hierarchy MUST be listed.
--- usepro-06 Mon Dec 11 16:09:34 2006
+++ allbery-00 Mon Dec 11 16:09:34 2006
@@ -1,34 +1,28 @@
-5.3. Application/news-groupinfo
+4.2. application/news-groupinfo
- The "application/news-groupinfo" is used in conjunction with the
- "newgroup" (6.2.1) and "mvgroup" (6.2.3) control messages. The
- <newsgroup-name> in the <newsgroups-line> MUST agree with the
- <newsgroup-name> in the "newgroup" or "mvgroup" control message. The
- Media Type "application/news-groupinfo" MUST NOT be used except as a
- part of such control messages.
-
- The "application/news-groupinfo" body part contains brief information
- about a newsgroup, i.e. the group's name, it's <newsgroup-
- description> and the <moderation-flag>.
-
- NOTE: The presence of the <newsgroups-tag> "For your newsgroups
- file:" is intended to make the whole newgroup message compatible
- with current practice as described in [Son-of-1036].
+ The application/news-groupinfo media type is used in conjunction with
+ the newgroup control message (see Section 5.2.1). Its body part
+ contains brief information about a newsgroup: the newsgroup name, its
+ description, and its moderation status.
- The MIME Media Type definition of "application/news-groupinfo" is:
+ The MIME media type definition of application/news-transmission is:
MIME type name: application
MIME subtype name: news-groupinfo
Required parameters: none
+ Optional parameters: charset, which MUST be a charset registered
+ for use with MIME text types and has the
+ same syntax as the parameter defined for
+ text/plain [RFC2046]. Specifies the
+ charset of the body part. If not given,
+ the charset defaults to US-ASCII [ASCII].
Disposition: by default, inline
- Encoding considerations: "7bit" or "8bit" is sufficient and MUST be
- used to maintain compatibility.
- Security considerations: this type MUST NOT be used except as part
- of a control message for the creation or
- modification of a Netnews newsgroup
- Published specification: [USEPRO]
+ Encoding considerations: 7bit or 8bit MUST be used to maintain
+ compatibility.
+ Security considerations: None.
+ Published specification: This specification.
- The content of the "application/news-groupinfo" body part is defined
+ The content of the application/news-groupinfo body part is defined
as:
groupinfo-body = [ newsgroups-tag CRLF ]
@@ -46,22 +40,17 @@
moderation-flag = %x28.4D.6F.64.65.72.61.74.65.64.29
; case sensitive "(Moderated)"
+ This unusual format is backward-compatible with the scanning of the
+ body of newgroup control messages for descriptions done by Netnews
+ implementations that predate this specification. Although optional,
+ the <newsgroups-tag> SHOULD be included for backward compatibility.
+
The <newsgroup-description> MUST NOT contain any occurrence of the
- string "(Moderated)" within it. Although optional, the <newsgroups-
- tag> SHOULD be included until such time as this standard has been
- widely adopted, to ensure compatibility with present practice.
-
- Moderated newsgroups MUST be marked by appending the case sensitive
- text " (Moderated)" at the end. It is NOT recommended that the
- moderator's email address be included in the <newsgroup-description>
- as has sometimes been done.
-
- NOTE: There is no provision for the use of charsets other than
- US-ASCII within a <newsgroup-description>. Such a facility may
- be provided in a future extension to this standard.
-[That may seem harsh, but if we make any such provision now, it will
-make life more complicated and restrict our freedom when it comes to the
-proposed I18N extension. Therefore I resisted the temptation to include
-any charset parameter with this Media Type. Note that this also applies
-to the checkgroups message further on.]
+ string "(Moderated)" within it. Moderated newsgroups MUST be marked
+ by appending the case sensitive text " (Moderated)" at the end.
+
+ While a charset parameter is defined for this media type, most
+ existing software does not correctly handle descriptions in a variety
+ of charsets. Using a charset of US-ASCII where possible is therefore
+ RECOMMENDED.
--- usepro-06 Mon Dec 11 16:09:34 2006
+++ allbery-00 Mon Dec 11 16:09:35 2006
@@ -1,62 +1,31 @@
-6. Control Messages
+5. Control Messages
- The following sections document the control messages. "Message" is
- used herein as a synonym for "article" unless context indicates
- otherwise.
-
- Each <control-command> comprises a <verb>, which indicates the action
- to be taken, and <argument>(s), which supply the details (see F-
- 3.2.5). The following sections contain syntactic definitions for the
- <verb>, <argument>s, and possibly the body, for each type of control
+ A control message is an article which contains a Control header field
+ and thereby indicates that some action should be taken by an agent
+ other than distribution and display. Any article containing a
+ Control header field (defined in Section 3.2.3 of [USEFOR]) is a
+ control message. Additionally, the action of an article containing a
+ Supersedes header field is described here; while such an article is
+ not a control message, it specifies an action similar to the cancel
+ control message.
+
+ The <control-command> of a Control header field comprises a <verb>,
+ which indicates the action to be taken, and one or more <argument>
+ values, which supply the details. For some control messages, the
+ body of the article is also significant. Each recognized <verb> (the
+ control message type) is described in a separate section below.
+ Agents MAY accept other control message types than those specified
+ below, and MUST either ignore or reject control messages with
+ unrecognized types. Syntactic definitions of valid <argument> values
+ and restrictions on control message bodies are given in the section
+ for each control message type.
+
+ Contrary to [RFC1036], the presence of a Subject header field
+ starting with the string "cmsg " MUST NOT cause an article to
+ interpreted as a control message. Agents MAY reject an article with
+ no Control header field and such a Subject header field as ambiguous.
+ Likewise, the presence of a <newsgroup-name> ending in ".ctl" in the
+ Newsgroups header field or the presence of an Also-Control header
+ field MUST NOT cause the article to be interpreted as a control
message.
-[The term <control-command> is now used to denote the syntactic object
-within the Control header field, to distinguish it from "control
-message", which refers to the whole article.]
-
- The Newsgroups header field of each control message SHOULD include
- the <newsgroup-name>(s) for the group(s) affected (i.e. groups to be
- created, modified or removed, or containing articles to be canceled).
- This is to ensure that the message propagates to all sites which
- receive (or would receive) that group(s). It MAY include other
- <newsgroup-name>s so as to improve propagation (but this practice may
- cause the control message to propagate also to places where it is
- unwanted, or even cause it not to propagate where it should, so it
- should not be used without good reason).
-
- NOTE: Propagation is controlled by relaying agents, and it may
- be necessary for relaying agents to take special steps to ensure
- that control messages such as newgroup messages for not-yet-
- existent newsgroups are propagated correctly (see 7.3).
-
- The presence of a Subject header field whose content starts with the
- string "cmsg " followed by a <control-command> was construed under
- [RFC 1036] as a request to perform that control action (even if no
- genuine Control header field was present). Indeed, some
- implementations went further and added the implied Control header
- field before injecting. Likewise, the presence of a <newsgroup-name>
- ending in ".ctl" in the Newsgroups header field caused the Subject
- header field content (not starting with "cmsg" in this case) to be
- interpreted as a <control-command>.
-
- All these practices, which have already largely fallen into disuse,
- are now declared to be Obsolete, and Subject header fields MUST NOT
- now be interpreted as <control-command>s under any circumstances.
-
-
-
-[Possible addtional text:]
-
- In order to prevent continuing interpretation of Subject header
- fields in this way by existing agents, posting and injecting agents
- SHOULD detect and decline to post articles in which the Subject
- header field starts with the word "cmsg" and in which there is no
- Control header field.
-
- The descriptions below set out REQUIREMENTS to be followed by sites
- that receive control messages and choose to honour them. However,
- nothing in these descriptions should be taken as overriding the right
- of any such site, in accordance with its local policy, to refuse to
- honour any particular control message, or to refer it to an
- administrator for approval (either as a class or on a case-by-case
- basis).
--- usepro-06 Mon Dec 11 16:09:35 2006
+++ allbery-00 Mon Dec 11 16:09:36 2006
@@ -1,18 +1,25 @@
-6.1. Digital Signature of Header Fields
+5.1. Authentication and Authorization
- It is most desirable that group control messages (6.2) in particular
- be authenticated by incorporating them within some digital signature
- scheme that encompasses other header fields closely associated with
- them (including at least Approved, Message-ID and Date). At the time
- of writing, this is usually done by means of a protocol known as
- "PGPverify" ([PGPVERIFY]), and continued usage of this is encouraged
- at least as an interim measure.
+ Control messages specify actions above and beyond the normal
+ processing of an article and are therefore potential vectors of abuse
+ and unauthorized action. There is, at present, no standardized means
+ of authenticating the sender of a control message or verifying that
+ the contents of a control message were sent by the claimed sender.
+ There are, however, some unstandardized authentication mechanisms in
+ common use.
- However, PGPverify is not considered suitable for standardization in
- its present form, for various technical reasons. It is therefore
- expected that an early extension to this standard will provide a
- robust and general purpose digital authentication mechanism with
- applicability to all situations requiring protection against
- malicious use of, or interference with, header fields. That
- extension would also address other Netnews security issues.
+ Agents acting on control messages SHOULD take steps to authenticate
+ control messages before acting on them, as determined by local
+ authorization policy. Whether this is done via the use of an
+ unstandardized authentication protocol, by comparison with
+ information obtained through another protocol, by human review, or by
+ some other means is left unspecified by this document. Further
+ extensions or revisions of this protocol are expected to standardize
+ a digital signature mechanism.
+
+ Agents are expected to have their own local authorization policies
+ for which control messages will be honored. No Netnews agent is ever
+ required to act on any control message. The following descriptions
+ specify the actions that a control message requests, but an agent MAY
+ always decline to act on any given control message.
--- usepro-06 Mon Dec 11 16:09:36 2006
+++ allbery-00 Mon Dec 11 16:09:36 2006
@@ -1,22 +1,16 @@
-6.2. Group Control Messages
+5.2. Group Control Messages
- "Group control messages" are the sub-class of control messages that
- request some update to the configuration of the groups known to a
- serving agent, namely "newgroup", "rmgroup", "mvgroup" and
- "checkgroups", plus any others created by extensions to this
- standard.
+ A group control message is any control message type that requests
+ some update to the list of newsgroups known to a news server. The
+ standard group control message types are "newgroup", "rmgroup", and
+ "checkgroups".
- Group control messages that attempt to create groups with names that
- are deprecated or reserved according to F-3.1.5 MUST NOT be issued,
- except by prior agreement within some cooperating subnet. Moreover,
- sites receiving such control messages SHOULD check them for
- conformance before honouring them.
+ Before honoring any group control message, an agent MUST check the
+ newsgroup or newsgroups affected by that control message and decline
+ to create any newsgroups not in conformance with the restrictions in
+ Section 3.1.4 of [USEFOR].
All of the group control messages MUST have an Approved header field
- (F-3.2.9) which, in those hierarchies where appropriate
- administrative agencies exist (see 1.1), identifies the appropriate
- person or entity as authorized by those agencies. The authorized
- person or entity SHOULD adhere to any conventions and restrictions on
- the format of <newsgroup-name>s established for those hierarchies
- [USEAGE].
+ (Section 3.2.1 of [USEFOR]). Group control messages without an
+ Approved header field SHOULD NOT be honored.
--- usepro-06 Mon Dec 11 16:09:39 2006
+++ allbery-00 Mon Dec 11 16:09:39 2006
@@ -1,13 +1,13 @@
-6.2.2.1. Example
+5.2.2. The rmgroup Control Message
- From: "example.all Administrator" <admin@noc.example>
- Newsgroups: example.admin.obsolete, example.admin.announce
- Date: 4 Apr 2002 22:04 -0900 (PST)
- Subject: cmsg rmgroup example.admin.obsolete
- Message-ID: <rm-example.admin.obsolete-20020404@noc.example>
- Approved: admin@noc.example
- Control: rmgroup example.admin.obsolete
+ The rmgroup control message requests the specified group be removed
+ from a news server's list of valid groups. The syntax of its Control
+ header field is:
- The group example.admin.obsolete is obsolete. Please remove it
- from your system.
+ control-command =/ Rmgroup-command
+ Rmgroup-command = "rmgroup" Rmgroup-arguments
+ Rmgroup-arguments = 1*WSP newsgroup-name
+
+ The body of the control message MAY contain anything, usually an
+ explanatory text.
--- usepro-06 Mon Dec 11 16:09:40 2006
+++ allbery-00 Mon Dec 11 16:09:41 2006
@@ -0,0 +1,52 @@
+5.2.3. The checkgroups Control Message
+
+ The checkgroups control message contains a list of all the valid
+ groups in a hierarchy with descriptions and moderation status. It
+ requests a news server update its valid newsgroup list for that
+ hierarchy to include the groups specified, remove any groups not
+ specified, and update group descriptions to match those given in the
+ checkgroups control message. The syntax of its Control header field
+ is:
+
+ control-command =/ Checkgroup-command
+ Checkgroup-command = "checkgroups" Checkgroup-arguments
+ Checkgroup-arguments= [ chkscope ] [ chksernr ]
+ chkscope = 1*( FWS ["!"] newsgroup-name )
+ chksernr = FWS "#" 1*DIGIT
+
+ A checkgroups message is interpreted as an exhaustive list of the
+ valid groups in all hierarchies or sub-hierarchies with a prefix
+ listed in the <chkscope> argument, excluding any sub-hierarchy where
+ the <chkscope> argument is prefixed by "!". If no <chkscope>
+ argument is given, it applies to all hierarchies for which group
+ statements appear in the body of the message. Since much existing
+ software does not honor the <chkscope> argument, the body of the
+ checkgroups control message MUST NOT contain group statements for
+ newsgroups outside the intended scope and SHOULD contain a correct
+ newsgroup list even for sub-hierarchies excluded with "!" <chkscope>
+ terms. News servers, however, MUST honor <chkscope> as specified
+ here.
+
+ The <chksernr> argument may be any positive integer. If present, it
+ MUST increase with every change to the newsgroup list and MUST NOT
+ ever decrease. If provided, news servers SHOULD remember the
+ <chksernr> value of the previous checkgroups control message honored
+ for a particular hierarchy or sub-hierarchy and decline to honor any
+ subsequent checkgroups control message for the same hierarchy or sub-
+ hierarchy with a smaller <chksernr> value.
+
+ For example, the following Control header field
+
+ Control: checkgroups de !de.alt #248
+
+ indicates the body of the message will list every newsgroup in the
+ de.* hierarchy, excepting the de.alt.* sub-hierarchy, and should not
+ be honored if a checkgroups control message with a serial number
+ greater than 248 was previously honored.
+
+ The body of the message is an entity of type application/
+ news-checkgroups. It SHOULD be declared as such with appropriate
+ MIME headers, but news servers SHOULD interpret checkgroups messages
+ that lack the appropriate MIME headers as if the body were of type
+ application/news-checkgroups for backward compatibility.
+
--- usepro-06 Mon Dec 11 16:09:41 2006
+++ allbery-00 Mon Dec 11 16:09:42 2006
@@ -1,43 +1,33 @@
-6.3. Cancel
-
- The "cancel" message requests that a target article be "canceled",
- i.e. be withdrawn from circulation or access.
+5.3. The cancel Control Message
+ The cancel control message requests that a target article be
+ withdrawn from circulation and access. The syntax of its Control
+ header field is:
control-command =/ Cancel-command
Cancel-command = "cancel" Cancel-arguments
Cancel-arguments = FWS msg-id [FWS]
The argument identifies the article to be cancelled by its message
- identifier. The body SHOULD contain an indication of why the
- cancellation was requested. The "cancel" message SHOULD be posted to
- the same newsgroup(s), with the same distribution(s), as the article
- it is attempting to cancel.
-
- A serving agent that elects to honour a "cancel" message SHOULD make
- the article unavailable for relaying or serving (perhaps by deleting
- it completely). If the target article is unavailable, and the
- acceptability of the "cancel" message cannot be established without
- it, activation of the "cancel" message SHOULD be delayed until the
- target article has been seen. See also sections 7.3 and 7.4.
-
- NOTE: It is expected that the security extension envisaged in
- section 6.1 will make more detailed provisions for establishing
- whether honouring a particular "cancel" message is in order. In
- particular, it is likely that there will be provision for the
- digital signature of 3rd party cancels (i.e. those issued other
- than by the sender, the moderator, or the injector).
-
- NOTE: A cancel submitted by the poster for an article in a
- moderated group will be forwarded to the moderator of that
- group, and it is up to that moderator to act upon it (7.8).
-
- NOTE: The former requirement [RFC 1036] that the From and/or
- Sender header fields of the "cancel" message should match those
- of the original article has been removed from this standard,
- since it only encouraged cancel issuers to conceal their true
- identity, and it was not usually checked or enforced by
- canceling software. Therefore, both the From and/or Sender
- header fields and any Approved header field should now relate to
- the entity responsible for issuing the "cancel" message.
+ identifier. The body of the control message MAY contain anything,
+ usually an explanatory text.
+
+ A serving agent that elects to honor a cancel message SHOULD make the
+ article unavailable to reading agents (perhaps by deleting it
+ completely). If the cancel control message arrives before the
+ article it targets, news servers choosing to honor it SHOULD remember
+ the message identifier that was cancelled and reject the cancelled
+ article when it arrives.
+
+ Cancel control messages listing moderated newsgroups in their
+ Newsgroups header field MUST contain an Approved header field like
+ any other article in a moderated newsgroup. This means that cancels
+ posted to a moderated newsgroup will normally be sent to the
+ moderator first for approval. Outside of moderated newsgroups,
+ cancel messages are not required to contain an Approved header field.
+
+ Contrary to [RFC1036], cancel control messages are not required to
+ contain From and Sender header fields matching the target message.
+ This requirement only encouraged cancel issuers to conceal their
+ identity and provided no security.
--- usepro-06 Mon Dec 11 16:09:42 2006
+++ allbery-00 Mon Dec 11 16:09:43 2006
@@ -1,17 +1,43 @@
-usefor-usepro-06 November 2006
-,_sendme.h[< Prev],_sendme.h
- [TOC] ,_sendme.h[ Next >],_sendme.h
-
-,_sendme.h[< Prev],_sendme.t
- [TOC] ,_sendme.t[ Next >],_sendme.t
-
#Diff to first older
-,_sendme.t
| Newer | Older |
|---|
-| ,_sendme.t | ,_sendme.t |
-
-
-,_sendme.t--- ../usefor-usepro-05/Ihave _sendme.out
-+++ January 2006 ../usefor-usepro-06/Ihave
-
-,_sendme.t