draft-ietf-usefor-usepro-14.txt   rfc5537.txt 
Usenet Format Working Group R. Allbery, Ed. Network Working Group R. Allbery, Ed.
Internet-Draft Stanford University Request for Comments: 5537 Stanford University
Obsoletes: 1036 (if approved) C. Lindsey Obsoletes: 1036 C. Lindsey
Intended status: Standards Track March 3, 2009 Category: Standards Track November 2009
Expires: September 4, 2009
Netnews Architecture and Protocols Netnews Architecture and Protocols
draft-ietf-usefor-usepro-14
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Abstract
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This document defines the architecture of Netnews systems and
http://www.ietf.org/ietf/1id-abstracts.txt. specifies the correct manipulation and interpretation of Netnews
articles by software that originates, distributes, stores, and
displays them. It also specifies the requirements that must be met
by any protocol used to transport and serve Netnews articles.
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 4, 2009. This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
This document defines the architecture of Netnews systems and Table of Contents
specifies the correct manipulation and interpretation of Netnews
articles by software which originates, distributes, stores, and
displays them. It also specifies the requirements that must be met
by any protocol used to transport and serve Netnews articles.
Internet Draft Comments 1. Introduction ....................................................3
1.1. Basic Concepts .............................................3
1.2. Scope ......................................................3
1.3. Requirements Notation ......................................3
1.4. Syntax Notation ............................................3
1.5. Definitions ................................................4
2. Transport .......................................................5
Comments are solicited and should be addressed to the Usenet Format RFC 5537 Netnews Architecture and Protocols November 2009
Working Group at ietf-usefor@imc.org.
Table of Contents 3. Duties of Agents ................................................6
3.1. General Principles .........................................6
3.2. The Path Header Field ......................................7
3.2.1. Constructing the Path Header Field ..................8
3.2.2. Path Header Field Example ...........................9
3.3. Article History and Duplicate Suppression .................10
3.4. Duties of a Posting Agent .................................11
3.4.1. Proto-Articles .....................................12
3.4.2. Multiple Injection of Articles .....................13
3.4.3. Followups ..........................................14
3.4.4. Construction of the References Header Field ........15
3.5. Duties of an Injecting Agent ..............................15
3.5.1. Forwarding Messages to a Moderator .................18
3.6. Duties of a Relaying Agent ................................19
3.7. Duties of a Serving Agent .................................21
3.8. Duties of a Reading Agent .................................22
3.9. Duties of a Moderator .....................................22
3.10. Duties of a Gateway ......................................24
3.10.1. Duties of an Outgoing Gateway .....................25
3.10.2. Duties of an Incoming Gateway .....................25
3.10.3. Original-Sender Header Field ......................27
3.10.4. Gateway Example ...................................28
4. Media Types ....................................................29
4.1. application/news-transmission .............................30
4.2. application/news-groupinfo ................................31
4.3. application/news-checkgroups ..............................33
5. Control Messages ...............................................35
5.1. Authentication and Authorization ..........................35
5.2. Group Control Messages ....................................36
5.2.1. The newgroup Control Message .......................36
5.2.1.1. newgroup Control Message Example ..........37
5.2.2. The rmgroup Control Message ........................38
5.2.3. The checkgroups Control Message ....................38
5.3. The cancel Control Message ................................40
5.4. The Supersedes Header Field ...............................40
5.5. The ihave and sendme Control Messages .....................41
5.6. Obsolete Control Messages .................................42
6. Security Considerations ........................................42
6.1. Compromise of System Integrity ............................42
6.2. Denial of Service .........................................44
6.3. Leakage ...................................................44
7. IANA Considerations ............................................45
8. References .....................................................45
8.1. Normative References ......................................45
8.2. Informative References ....................................46
Appendix A. Changes to the Existing Protocols ....................47
Appendix B. Acknowledgements .....................................48
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 RFC 5537 Netnews Architecture and Protocols November 2009
1.1. Basic Concepts . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Requirements Notation . . . . . . . . . . . . . . . . . . 5
1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5
1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6
2. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Duties of Agents . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. General Principles . . . . . . . . . . . . . . . . . . . . 9
3.2. The Path Header Field . . . . . . . . . . . . . . . . . . 10
3.2.1. Constructing the Path Header Field . . . . . . . . . . 11
3.2.2. Path Header Field Example . . . . . . . . . . . . . . 12
3.3. Article History and Duplicate Suppression . . . . . . . . 13
3.4. Duties of a Posting Agent . . . . . . . . . . . . . . . . 14
3.4.1. Proto-articles . . . . . . . . . . . . . . . . . . . . 15
3.4.2. Multiple Injection of Articles . . . . . . . . . . . . 16
3.4.3. Followups . . . . . . . . . . . . . . . . . . . . . . 17
3.4.4. Construction of the References Header Field . . . . . 18
3.5. Duties of an Injecting Agent . . . . . . . . . . . . . . . 18
3.5.1. Forwarding Messages to a Moderator . . . . . . . . . . 20
3.6. Duties of a Relaying Agent . . . . . . . . . . . . . . . . 21
3.7. Duties of a Serving Agent . . . . . . . . . . . . . . . . 23
3.8. Duties of a Reading Agent . . . . . . . . . . . . . . . . 24
3.9. Duties of a Moderator . . . . . . . . . . . . . . . . . . 25
3.10. Duties of a Gateway . . . . . . . . . . . . . . . . . . . 26
3.10.1. Duties of an Outgoing Gateway . . . . . . . . . . . . 27
3.10.2. Duties of an Incoming Gateway . . . . . . . . . . . . 28
3.10.3. Original-Sender header field . . . . . . . . . . . . . 30
3.10.4. Gateway Example . . . . . . . . . . . . . . . . . . . 30
4. Media Types . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1. application/news-transmission . . . . . . . . . . . . . . 32
4.2. application/news-groupinfo . . . . . . . . . . . . . . . . 33
4.3. application/news-checkgroups . . . . . . . . . . . . . . . 35
5. Control Messages . . . . . . . . . . . . . . . . . . . . . . . 38
5.1. Authentication and Authorization . . . . . . . . . . . . . 38
5.2. Group Control Messages . . . . . . . . . . . . . . . . . . 39
5.2.1. The newgroup Control Message . . . . . . . . . . . . . 39
5.2.2. The rmgroup Control Message . . . . . . . . . . . . . 41
5.2.3. The checkgroups Control Message . . . . . . . . . . . 41
5.3. The cancel Control Message . . . . . . . . . . . . . . . . 43
5.4. The Supersedes Header Field . . . . . . . . . . . . . . . 44
5.5. The ihave and sendme Control Messages . . . . . . . . . . 44
5.6. Obsolete Control Messages . . . . . . . . . . . . . . . . 45
6. Security Considerations . . . . . . . . . . . . . . . . . . . 46
6.1. Compromise of System Integrity . . . . . . . . . . . . . . 46
6.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 47
6.3. Leakage . . . . . . . . . . . . . . . . . . . . . . . . . 48
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50
8.1. Normative References . . . . . . . . . . . . . . . . . . . 50
8.2. Informative References . . . . . . . . . . . . . . . . . . 50
Appendix A. Changes to the Existing Protocols . . . . . . . . . . 52
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54
1. Introduction 1. Introduction
1.1. Basic Concepts 1.1. Basic Concepts
"Netnews" is a set of protocols for generating, storing and "Netnews" is a set of protocols for generating, storing, and
retrieving news "articles" whose format is defined in [USEFOR], and retrieving news "articles" whose format is defined in [RFC5536], and
for exchanging them amongst a readership that is potentially widely for exchanging them amongst a readership that is potentially widely
distributed. It is organized around "newsgroups", with the distributed. It is organized around "newsgroups", with the
expectation that each reader will be able to see all articles posted expectation that each reader will be able to see all articles posted
to each newsgroup in which he participates. These protocols most to each newsgroup in which he participates. These protocols most
commonly use a flooding algorithm which propagates copies throughout commonly use a flooding algorithm that propagates copies throughout a
a network of participating servers. Typically, only one copy is network of participating servers. Typically, only one copy is stored
stored per server, and each server makes it available on demand to per server, and each server makes it available on demand to readers
readers able to access that server. able to access that server.
"Usenet" is a particular worldwide publicly accessible network based "Usenet" is a particular worldwide, publicly accessible network based
on the Netnews protocols. It is only one such possible network; on the Netnews protocols. It is only one such possible network;
there are deployments of the Netnews protocols other than Usenet there are deployments of the Netnews protocols other than Usenet
(such as ones internal to particular organizations). This document (such as ones internal to particular organizations). This document
discusses the more general Netnews architecture and protocols. discusses the more general Netnews architecture and protocols.
1.2. Scope 1.2. Scope
This document defines the architecture of Netnews systems and This document defines the architecture of Netnews systems and
specifies the correct manipulation and interpretation of Netnews specifies the correct manipulation and interpretation of Netnews
articles by software which originates, distributes, stores, and articles by software that originates, distributes, stores, and
displays them. It addresses protocol issues that are independent of displays them. It addresses protocol issues that are independent of
transport protocols such as NNTP [RFC3977] and specifies the transport protocols such as the Network News Transfer Protocol (NNTP)
requirements Netnews places on those underlying transport protocols. [RFC3977], and specifies the requirements Netnews places on those
It also specifies the handling of control messages. underlying transport protocols. It also specifies the handling of
control messages.
The format and syntax of Netnews articles are specified in [USEFOR], The format and syntax of Netnews articles are specified in [RFC5536],
which should be read in conjunction with this document. which should be read in conjunction with this document.
1.3. Requirements Notation 1.3. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.4. Syntax Notation 1.4. Syntax Notation
Syntax defined in this document uses the Augmented Backus-Naur Form Syntax defined in this document uses the Augmented Backus-Naur Form
(ABNF) notation (including the Core Rules) defined in [RFC5234] and (ABNF) notation (including the Core Rules) defined in [RFC5234] and
constructs defined in [USEFOR] and [RFC2822]. constructs defined in [RFC5536] and [RFC5322].
RFC 5537 Netnews Architecture and Protocols November 2009
The ABNF rules defined elsewhere and used in this document are: The ABNF rules defined elsewhere and used in this document are:
CRLF = <see [RFC5234] appendix B.1> CRLF = <see [RFC5234] Appendix B.1>
DIGIT = <see [RFC5234] appendix B.1> DIGIT = <see [RFC5234] Appendix B.1>
HTAB = <see [RFC5234] appendix B.1> HTAB = <see [RFC5234] Appendix B.1>
SP = <see [RFC5234] appendix B.1> SP = <see [RFC5234] Appendix B.1>
WSP = <see [RFC5234] appendix B.1> WSP = <see [RFC5234] Appendix B.1>
VCHAR = <see [RFC5234] Appendix B.1>
argument = <see [USEFOR] section 3.2.3> argument = <see [RFC5536] Section 3.2.3>
article-locator = <see [USEFOR] section 3.2.14> article-locator = <see [RFC5536] Section 3.2.14>
component = <see [USEFOR] section 3.1.4> component = <see [RFC5536] Section 3.1.4>
control-command = <see [USEFOR] section 3.2.3> control-command = <see [RFC5536] Section 3.2.3>
diag-keyword = <see [USEFOR] section 3.1.5> diag-keyword = <see [RFC5536] Section 3.1.5>
diag-match = <see [USEFOR] section 3.1.5> diag-match = <see [RFC5536] Section 3.1.5>
diag-other = <see [USEFOR] section 3.1.5> diag-other = <see [RFC5536] Section 3.1.5>
dist-name = <see [USEFOR] section 3.2.4> dist-name = <see [RFC5536] Section 3.2.4>
msg-id = <see [USEFOR] section 3.1.3> msg-id = <see [RFC5536] Section 3.1.3>
newsgroup-name = <see [USEFOR] section 3.1.4> newsgroup-name = <see [RFC5536] Section 3.1.4>
path-diagnostic = <see [USEFOR] section 3.1.5> path-diagnostic = <see [RFC5536] Section 3.1.5>
path-identity = <see [USEFOR] section 3.1.5> path-identity = <see [RFC5536] Section 3.1.5>
path-nodot = <see [USEFOR] section 3.1.5> path-nodot = <see [RFC5536] Section 3.1.5>
tail-entry = <see [USEFOR] section 3.1.5> tail-entry = <see [RFC5536] Section 3.1.5>
verb = <see [USEFOR] section 3.2.3> verb = <see [RFC5536] Section 3.2.3>
display-name = <see [RFC2822] section 3.4> display-name = <see [RFC5322] Section 3.4>
local-part = <see [RFC2822] section 3.4.1> local-part = <see [RFC5322] Section 3.4.1>
mailbox = <see [RFC2822] section 3.4> mailbox = <see [RFC5322] Section 3.4>
utext = <see [RFC2822] section 3.2.6>
1.5. Definitions 1.5. Definitions
Any term used in this document that is defined in Section 1.5 of 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 [RFC5536] is used with the definition given there. In addition, the
following terms will be used: following terms will be used:
A "hierarchy" is the set of all newsgroups whose names share a first A "hierarchy" is the set of all newsgroups whose names share a first
<component> (as defined in Section 3.1.4 of [USEFOR]). A "sub- <component> (as defined in Section 3.1.4 of [RFC5536]). A "sub-
hierarchy" is the set of all newsgroups whose names share several hierarchy" is the set of all newsgroups whose names share several
initial components. initial components.
A "news server" is further distinguished into the roles of "injecting A "news server" is further distinguished into the roles of "injecting
agent", "relaying agent", and "serving agent". An "injecting agent" agent", "relaying agent", and "serving agent". An "injecting agent"
accepts a proto-article with the goal of distributing it to relaying accepts a proto-article with the goal of distributing it to relaying
and serving agents and hence to readers. A "relaying agent" accepts and serving agents and hence to readers. A "relaying agent" accepts
articles from other relaying agents or injecting agents and articles from other relaying agents or injecting agents and
distributes them to other relaying agents or serving agents. A distributes them to other relaying agents or serving agents. A
"serving agent" receives an article from a relaying agent or "serving agent" receives an article from a relaying agent or
injecting agent and makes it available to readers. injecting agent and makes it available to readers.
RFC 5537 Netnews Architecture and Protocols November 2009
A "user agent" is further distinguished into the roles of "posting A "user agent" is further distinguished into the roles of "posting
agent" and "reading agent". A "posting agent" is software which agent" and "reading agent". A "posting agent" is software that
assists in the preparation of a proto-article and then passes it to assists in the preparation of a proto-article and then passes it to
an injecting agent. A "reading agent" is software which retrieves an injecting agent. A "reading agent" is software that retrieves
articles from a serving agent for presentation to a reader. articles from a serving agent for presentation to a reader.
"Injecting" an article is the processing of a proto-article by an "Injecting" an article is the processing of a proto-article by an
injecting agent. Normally this action is done once and only once for injecting agent. Normally, this action is done once and only once
a given article. "Multiple injection" is passing the same article to for a given article. "Multiple injection" is passing the same
multiple injecting agents, either serially or in parallel, by one or article to multiple injecting agents, either serially or in parallel,
several posting agents. by one or several posting agents.
A "gateway" is software which receives news articles and converts A "gateway" is software that receives news articles and converts them
them to messages of some other kind (such as [RFC2822] mail to messages of some other kind (such as [RFC5322] mail messages),
messages), receives messages of some other kind and converts them to receives messages of some other kind and converts them to news
news articles, or conveys articles between two separate Netnews articles, or conveys articles between two separate Netnews networks.
networks.
2. Transport 2. Transport
The exact means used to transmit articles from one agent to another The exact means used to transmit articles from one agent to another
is not specified. NNTP [RFC3977] is the most common transport is not specified. NNTP [RFC3977] is the most common transport
mechanism for Netnews networks. Other methods in use include the mechanism for Netnews networks. Other methods in use include the
UUCP protocol [RFC0976] (extensively used in the early days of Unix-to-Unix Copy Protocol [UUCP] (extensively used in the early days
Usenet) and physically delivered magnetic and optical media. Any of Usenet) and physically delivered magnetic and optical media. Any
mechanism may be used in conjunction with this protocol provided that mechanism may be used in conjunction with this protocol provided that
it can meet the requirements specified here. it can meet the requirements specified here.
Transports for Netnews articles MUST treat news articles as Transports for Netnews articles MUST treat news articles as
uninterpreted sequences of octets, excluding the values 0 (which may uninterpreted sequences of octets, excluding the values %d00 (which
not occur in Netnews articles) and 13 and 10 (which MUST only appear may not occur in Netnews articles), %d13, and %d10 (which MUST only
in Netnews articles as a pair in that order and which together denote appear in Netnews articles as a pair in that order and which,
a line separator). These octets are the US-ASCII [ASCII] characters together, denote a line separator). These octets are the US-ASCII
NUL, CR, and LF respectively. [ASCII] characters NUL, CR, and LF respectively.
NOTE: This corresponds to the range of octets permitted in MIME NOTE: This corresponds to the range of octets permitted in MIME
8bit data [RFC2045]. Transports for Netnews are not required to 8bit data [RFC2045]. Transports for Netnews are not required to
support transmission of MIME binary data. support transmission of MIME binary data.
In particular, transports MUST convey all header fields (including In particular, transports MUST convey all header fields unmodified
header fields within message/rfc822 objects in article bodies) (including header fields within message/rfc822 objects in article
unmodified even if they contain octets in the range 128 to 255. bodies), even if they contain octets in the range of 128 to 255.
Furthermore, transports for relaying and serving agents MUST, and Furthermore, transports for relaying and serving agents MUST, and
transports for other agents SHOULD, convey lines even if they exceed transports for other agents SHOULD, convey lines even if they exceed
998 characters in length, especially in article bodies. (This 998 characters in length, especially in article bodies. (This
requirement is stricter than MIME 8bit data.) These requirements requirement is stricter than MIME 8bit data.) These requirements
include the transport paths between posting agents, injecting agents, include the transport paths between posting agents, injecting agents,
serving agents, and reading agents. serving agents, and reading agents.
RFC 5537 Netnews Architecture and Protocols November 2009
3. Duties of Agents 3. Duties of Agents
The following section specifies the duties of the agents involved in The following section specifies the duties of the agents involved in
the creation, relaying, and serving of Netnews articles. This the creation, relaying, and serving of Netnews articles. This
protocol is described by following the life of a typical Usenet protocol is described by following the life of a typical Usenet
article: it is prepared by a posting agent, given to an injecting article: it is prepared by a posting agent, given to an injecting
agent, transferred through one or more relaying agents, accepted by a agent, transferred through one or more relaying agents, accepted by a
serving agent, and finally retrieved by a reading agent. Articles serving agent, and finally retrieved by a reading agent. Articles
submitted to moderated groups go through an additional process, which submitted to moderated groups go through an additional process, which
is described separately. Finally, the additional duties and is described separately (see Section 3.5.1 and Step 7 of
requirements of a gateway are discussed. Section 3.5). Finally, the additional duties and requirements of a
gateway are discussed.
At each step, each agent has a set of checks and transformations of 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 the article that it is required to perform. These are described as
sequences of steps to be followed, but it should be understood that sequences of steps to be followed, but it should be understood that
it is the effect of these sequences that is important, and it is the effect of these sequences that is important, and
implementations may use any method that gives rise to the same implementations may use any method that produces the same effect.
effect.
Many news servers combine the functions of injecting agent, relaying Many news servers combine the functions of injecting agent, relaying
agent, and serving agent in a single software package. For the agent, and serving agent in a single software package. For the
purposes of this specification, such combined agents should purposes of this specification, such combined agents should
conceptually be treated as an injecting agent which sends articles to conceptually be treated as an injecting agent that sends articles to
a serving agent and optionally a relaying agent. The requirements of a serving agent and, optionally, to a relaying agent. The
all three agents MUST be still met when the news server is performing requirements of all three agents MUST still be met when the news
the functions of those agents. server is performing the functions of those agents.
Control messages may have additional effects than those described On news servers that accept them, control messages may have
below on news servers which accept them. Those effects are described additional effects than those described below. Those effects are
in Section 5. described in Section 5.
3.1. General Principles 3.1. General Principles
There are two important principles that news implementors and There are two important principles that news implementors and
administrators need to keep in mind. The first is the well-known administrators need to keep in mind. The first is the well-known
Internet Robustness Principle: 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.
As applied to Netnews, this primarily means that unwanted or non- As applied to Netnews, this primarily means that unwanted or non-
compliant articles SHOULD be rejected as early as possible, but once compliant articles SHOULD be rejected as early as possible, but once
they are in general circulation, relaying and serving agents may wish they are in general circulation, relaying and serving agents may wish
to accept them where possible rather than lose information. Posting to accept them where possible rather than lose information. Posting
agents and injecting agents SHOULD therefore be maximally strict in agents and injecting agents SHOULD therefore be maximally strict in
their application of both this protocol and [USEFOR], and reading their application of both this protocol and [RFC5536], and reading
agents SHOULD be robust in the presence of violations of the Netnews agents SHOULD be robust in the presence of violations of the Netnews
article format where possible. article format where possible.
RFC 5537 Netnews Architecture and Protocols November 2009
In the case of Netnews, there is an even more important principle, In the case of Netnews, there is an even more important principle,
derived from a much older code of practice, the Hippocratic Oath (we derived from a much older code of practice, the Hippocratic Oath (we
may thus call this the Hippocratic Principle): may thus call this the Hippocratic Principle):
First, do no harm. First, do no harm.
It is vital to realize that decisions which might be merely It is vital to realize that decisions that might be merely suboptimal
suboptimal in a smaller context can become devastating mistakes when in a smaller context can become devastating mistakes when amplified
amplified by the actions of thousands of hosts within a few minutes. by the actions of thousands of hosts within a few minutes.
No Netnews agent is ever required to accept any article. It is No Netnews agent is ever required to accept any article. It is
common for injecting, relaying, and serving agents to reject well- common for injecting, relaying, and serving agents to reject well-
formed articles for reasons of local policy (such as not wishing to formed articles for reasons of local policy (such as not wishing to
carry a particular newsgroup or attempting to filter out unwanted carry a particular newsgroup or attempting to filter out unwanted
articles). This document specifies how articles are to be treated if articles). This document specifies how articles are to be treated if
they are accepted and specifies some cases where they must be they are accepted and specifies some cases where they must be
rejected, but an agent MAY always reject any article for other rejected, but an agent MAY always reject any article for other
reasons than those stated here. reasons than those stated here.
skipping to change at page 10, line 37 skipping to change at page 7, line 39
allowable divergence in trace headers and local metadata. allowable divergence in trace headers and local metadata.
Accordingly, agents (other than moderators) MUST NOT modify articles Accordingly, agents (other than moderators) MUST NOT modify articles
in ways other than described here. Unacceptable articles MUST be in ways other than described here. Unacceptable articles MUST be
rejected rather than corrected. rejected rather than corrected.
3.2. The Path Header Field 3.2. The Path Header Field
All news server components (injecting agents, relaying agents, and All news server components (injecting agents, relaying agents, and
serving agents) MUST identify themselves, when processing an article, serving agents) MUST identify themselves, when processing an article,
by prepending their <path-identity> (defined in Section 3.1.5 of by prepending their <path-identity> (defined in Section 3.1.5 of
[USEFOR]) to the Path header field. Injecting agents MUST also use [RFC5536]) to the Path header field. Injecting agents MUST also use
the same identity in Injection-Info header fields they add, and the same identity in Injection-Info header fields that they add, and
serving and relaying agents SHOULD use the same identity in any Xref serving and relaying agents SHOULD use the same identity in any Xref
header fields they add. header fields they add.
The <path-identity> used by an agent may be chosen via one of the The <path-identity> used by an agent may be chosen via one of the
following methods (in decreasing order of preference): following methods (in decreasing order of preference):
1. The fully-qualified domain name (FQDN) of the system on which the 1. The fully qualified domain name (FQDN) of the system on which the
agent is running. agent is running.
2. A fully-qualified domain name (FQDN) within a domain affiliated 2. A fully qualified domain name (FQDN) within a domain affiliated
with the administrators of the agent and guaranteed to be unique with the administrators of the agent and guaranteed to be unique
by the administrators of that domain. For example, the by the administrators of that domain. For example, the
RFC 5537 Netnews Architecture and Protocols November 2009
uniqueness of server.example.org could be guaranteed by the uniqueness of server.example.org could be guaranteed by the
administrator of example.org even if there is no DNS record for administrator of example.org even if there is no DNS record for
server.example.org itself. server.example.org itself.
3. Some other (arbitrary) name in the form <path-nodot> believed to 3. Some other (arbitrary) name in the form of a <path-nodot>,
be unique and registered at least with all the other news servers believed to be unique and registered at least with all the other
to which that relaying agent or injecting agent sends articles. news servers to which that relaying agent or injecting agent
This option SHOULD NOT be used unless the earlier options are sends articles. This option SHOULD NOT be used unless the
unavailable or unless the name is of longstanding usage. earlier options are unavailable or unless the name is of
longstanding usage.
Some existing implementations treat <path-identity> as case- Some existing implementations treat <path-identity> as case-
sensitive, some case-insensitive. The <path-identity> therefore sensitive, some as case-insensitive. The <path-identity> therefore
SHOULD be all lowercase and implementations SHOULD compare identities SHOULD be all lowercase and implementations SHOULD compare identities
case-insensitively. case-insensitively.
3.2.1. Constructing the Path Header Field 3.2.1. Constructing the Path Header Field
If a relaying or serving agent receives an article from an injecting If a relaying or serving agent receives an article from an injecting
or serving agent that is part of the same news server, it MAY leave or serving agent that is part of the same news server, it MAY leave
the Path header field of the article unchanged. Otherwise, every the Path header field of the article unchanged. Otherwise, every
injecting, relaying, or serving agent that accepts an article MUST injecting, relaying, or serving agent that accepts an article MUST
update the Path header field as follows. Note that the Path header update the Path header field as follows. Note that the Path header
skipping to change at page 11, line 50 skipping to change at page 9, line 5
consecutive "!"s. consecutive "!"s.
* If the expected <path-identity> of the source of the article * If the expected <path-identity> of the source of the article
does not match, use "!.MISMATCH." followed by the expected does not match, use "!.MISMATCH." followed by the expected
<path-identity> of the source or its IP address. <path-identity> of the source or its IP address.
* If the relaying or serving agent is not willing or able to * If the relaying or serving agent is not willing or able to
check the <path-identity>, use "!.SEEN." followed by the FQDN, check the <path-identity>, use "!.SEEN." followed by the FQDN,
IP address, or expected <path-identity> of the source. IP address, or expected <path-identity> of the source.
RFC 5537 Netnews Architecture and Protocols November 2009
The "expected <path-identity> of the source of the article" is a The "expected <path-identity> of the source of the article" is a
<path-identity> for the injecting or relaying agent that passed <path-identity> for the injecting or relaying agent that passed
the article to this relaying or serving agent, determined by the article to this relaying or serving agent, determined by
properties of the connection via which the article was received properties of the connection via which the article was received
(for example, an authentication identity or a peer IP address). (for example, an authentication identity or a peer IP address).
Be aware that [RFC1036] did not include <path-diagnostic>. Be aware that [RFC1036] did not include <path-diagnostic>.
Implementations which predate this specification will add only Implementations that predate this specification will add only
single "!" characters between <path-identity> strings. single "!" characters between <path-identity> strings.
4. The agent MAY then prepend to the Path header field content "!" 4. The agent MAY then prepend to the Path header field content "!"
or "!!" followed by an additional <path-identity> for itself or "!!" followed by an additional <path-identity> for itself
other than its primary one. Using "!!", and thereby adding a other than its primary one. Using "!!", and thereby adding a
<diag-match> since the <path-identity> clearly is verified, is <diag-match> since the <path-identity> clearly is verified, is
RECOMMENDED. This step may be repeated any number of times. RECOMMENDED. This step may be repeated any number of times.
This is permitted for agents that have multiple <path-identity>s This is permitted for agents that have multiple <path-identity>s
(such as during a transition from one to another). Each of these (such as during a transition from one to another). Each of these
<path-identity>s MUST meet the requirements set out in <path-identity>s MUST meet the requirements set out in
Section 3.2. Section 3.2.
5. Finally, the agent MUST prepend its primary <path-identity> to 5. Finally, the agent MUST prepend its primary <path-identity> to
the Path header field content. The primary <path-identity> is the Path header field content. The primary <path-identity> is
the <path-identity> it normally advertises to its peers for their the <path-identity> it normally advertises to its peers for their
use in generating <path-diagnostic>s as described above. use in generating <path-diagnostic>s as described above.
Any agent which modifies the Path header field MAY fold it by Any agent that modifies the Path header field MAY fold it by
inserting FWS immediately after any <path-identity> or <diag-other> inserting FWS (folding white space) immediately after any <path-
it added (see section 3.1.5 of [USEFOR] for allowable locations for identity> or <diag-other> it added (see Section 3.1.5 of [RFC5536]
FWS). for allowable locations for FWS).
3.2.2. Path Header Field Example 3.2.2. Path Header Field Example
Here is an example of a Path header field created following the rules Here is an example of a Path header field created by following the
for injecting and relaying agents. rules for injecting and relaying agents.
Path: foo.isp.example!.SEEN.isp.example!!foo-news Path: foo.isp.example!.SEEN.isp.example!foo-news
!.MISMATCH.2001:DB:0:0:8:800:200C:417A!bar.isp.example !.MISMATCH.2001:DB8:0:0:8:800:200C:417A!bar.isp.example
!!old.site.example!barbaz!!baz.isp.example !!old.site.example!barbaz!!baz.isp.example
!.POSTED.dialup123.baz.isp.example!not-for-mail !.POSTED.dialup123.baz.isp.example!not-for-mail
This article was injected by baz.isp.example as indicated by the This article was injected by baz.isp.example as indicated by the
<diag-keyword> "POSTED". The injector has recorded that it received <diag-keyword> "POSTED". The injector has recorded that it received
the article from dialup123.baz.isp.example. "not-for-mail is a common the article from dialup123.baz.isp.example. "not-for-mail" is a
<tail-entry>. common <tail-entry>.
RFC 5537 Netnews Architecture and Protocols November 2009
The article was relayed to the relaying agent known, at least to The article was relayed to the relaying agent known, at least to
old.site.example, as "barbaz". That relaying agent confirmed to its old.site.example, as "barbaz". That relaying agent confirmed to its
satisfaction that "baz.isp.example" was an expected <path-identity> satisfaction that "baz.isp.example" was an expected <path-identity>
for the source of the article and therefore used <diag-match> ("!") for the source of the article and therefore used <diag-match> ("!")
for its <path-diagnostic>. for its <path-diagnostic>.
barbaz relayed it to old.site.example, which does not support <diag- barbaz relayed it to old.site.example, which does not support <diag-
keyword> and therefore used the old "!" delimiter. This indicates keyword> and therefore used the old "!" delimiter. This indicates
that the identity of "barbaz" was not verified and may have been that the identity of "barbaz" was not verified and may have been
forged. forged.
old.site.example relayed it to a news server using the <path- old.site.example relayed it to a news server using the <path-
identity> of bar.isp.example and claiming (by using the "!" <path- identity> of bar.isp.example and claiming (by using the "!" <path-
diagnostic>) to have verified that it came from old.site.example. diagnostic>) to have verified that it came from old.site.example.
bar.isp.example relayed it to foo-news which, not being convinced bar.isp.example relayed it to foo-news, which, not being convinced
that it truly came from bar.isp.example, inserted the <diag-keyword> that it truly came from bar.isp.example, inserted the <diag-keyword>
"MISMATCH" and then stated that it received the article from the IPv6 "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 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 bar.isp.example was not a correct <path-identity> for that source but
simply that that identity did not match the expectations of foo- simply that the identity did not match the expectations of foo-news.)
news.)
foo-news then passed the article to foo.isp.example, which declined foo-news then passed the article to foo.isp.example, which declined
to validate its <path-identity> and instead appended the <diag- to validate its <path-identity> and instead appended the <diag-
keyword> "SEEN" to indicate it knows the source of the article as keyword> "SEEN" to indicate it knows the source of the article as
isp.example. This may be either an expected <path-identity> or the isp.example. This may be either an expected <path-identity> or the
FQDN of the system from which it received the article. Presumably FQDN of the system from which it received the article. Presumably,
foo.isp.example is a serving agent that then delivered the article to foo.isp.example is a serving agent that then delivered the article to
a reading agent. a reading agent.
baz.isp.example, bar.isp.example, and foo-news folded the Path header baz.isp.example, bar.isp.example, and foo-news folded the Path header
field. field.
3.3. Article History and Duplicate Suppression 3.3. Article History and Duplicate Suppression
Netnews normally uses a flood-fill algorithm for propagation of Netnews normally uses a flood-fill algorithm for propagation of
articles in which each news server offers the articles it accepts to articles in which each news server offers the articles it accepts to
multiple peers and each news server may be offered the same article multiple peers, and each news server may be offered the same article
from multiple other news servers. Accordingly, duplicate suppression from multiple other news servers. Accordingly, duplicate suppression
is key; if a news server accepted every article it was offered, it is key; if a news server accepted every article it was offered, it
may needlessly accept (and then potentially retransmit) dozens of may needlessly accept (and then potentially retransmit) dozens of
copies of every article. copies of every article.
Relaying and serving agents therefore MUST keep a record of articles Relaying and serving agents therefore MUST keep a record of articles
they have already seen and use that record to reject additional they have already seen and use that record to reject additional
offers of the same article. This record is called the "history" file offers of the same article. This record is called the "history" file
or database. or database.
RFC 5537 Netnews Architecture and Protocols November 2009
Each article is uniquely identified by its message identifier, so a Each article is uniquely identified by its message identifier, so a
relaying or serving agent could satisfy this requirement by storing a relaying or serving agent could satisfy this requirement by storing a
record of every message identifier that agent has ever seen. Such a record of every message identifier that agent has ever seen. Such a
history database would grow without bound, however, so it is common history database would grow without bound, however, so it is common
and permitted to optimize based on the Injection-Date or Date header and permitted to optimize based on the Injection-Date or Date header
field of an article as follows. (In the following discussion, the field of an article as follows. (In the following discussion, the
"date" of an article is defined to be the date represented by its "date" of an article is defined to be the date represented by its
Injection-Date header field if present, otherwise its Date header Injection-Date header field, if present; otherwise, by its Date
field.) header field.)
o Agents MAY select a cutoff interval and reject any article with a o Agents MAY select a cutoff interval and reject any article with a
date farther in the past than that cutoff interval. If this date farther in the past than that cutoff interval. If this
interval is shorter than the time it takes for an article to interval is shorter than the time it takes for an article to
propagate through the network, the agent might reject an article propagate through the network, the agent might reject an article
it had not yet seen, so it ought not to be aggressively short. it had not yet seen, so it ought not to be aggressively short.
For Usenet, for example, a cutoff interval of no less than seven For Usenet, for example, a cutoff interval of no less than seven
days is conventional. days is conventional.
o Agents that enforce such a cutoff MAY then drop records of o Agents that enforce such a cutoff MAY then drop records of
skipping to change at page 14, line 34 skipping to change at page 11, line 42
date when the article was first seen by that agent rather than the date when the article was first seen by that agent rather than the
date of the article. In this case, the history retention interval date of the article. In this case, the history retention interval
MUST be at least 24 hours longer than the cutoff interval to allow MUST be at least 24 hours longer than the cutoff interval to allow
for articles dated in the future. This interval matches the for articles dated in the future. This interval matches the
allowable error in the date of the article (see Section 3.5). allowable error in the date of the article (see Section 3.5).
These are just two implementation strategies for article history, These are just two implementation strategies for article history,
albeit the most common ones. Relaying and serving agents are not albeit the most common ones. Relaying and serving agents are not
required to use these strategies, only to meet the requirement of not required to use these strategies, only to meet the requirement of not
accepting an article more than once. However, these strategies are accepting an article more than once. However, these strategies are
safe and widely deployed and implementors are encouraged to use one safe and widely deployed, and implementors are encouraged to use one
of them, especially if they do not have extensive experience with of them, especially if they do not have extensive experience with
Netnews and the subtle effects of its flood-fill algorithm. Netnews and the subtle effects of its flood-fill algorithm.
3.4. Duties of a Posting Agent 3.4. Duties of a Posting Agent
A posting agent is the component of a user agent that assists a 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 poster in creating a valid proto-article and forwarding it to an
injecting agent. injecting agent.
RFC 5537 Netnews Architecture and Protocols November 2009
Posting agents SHOULD ensure that proto-articles they create are Posting agents SHOULD ensure that proto-articles they create are
valid according to [USEFOR] and any other applicable policies. They valid according to [RFC5536] and any other applicable policies. They
MUST NOT create any Injection-Info header field; this header field MUST NOT create any Injection-Info header field; this header field
may only be added by the injecting agent. may only be added by the injecting agent.
If the proto-article already contains both Message-ID and Date header If the proto-article already contains both Message-ID and Date header
fields, posting agents MAY add an Injection-Date header field to that fields, posting agents MAY add an Injection-Date header field to that
proto-article immediately before passing that proto-article to an proto-article immediately before passing that proto-article to an
injection agent. They SHOULD do so if the Date header field injection agent. They SHOULD do so if the Date header field
(representing the composition time of the proto-article) is more than (representing the composition time of the proto-article) is more than
a day in the past at the time of injection. They MUST do so if the a day in the past at the time of injection. They MUST do so if the
proto-article is being submitted to more than one injecting agent; proto-article is being submitted to more than one injecting agent;
see Section 3.4.2. see Section 3.4.2.
The Injection-Date header field is new in this revision of the The Injection-Date header field is new in this revision of the
Netnews protocol and is designed to allow the Date header field to Netnews protocol and is designed to allow the Date header field to
hold the composition date (as recommended in section 3.6.1 of hold the composition date (as recommended in Section 3.6.1 of
[RFC2822]), even if the proto-article is not to be injected for some [RFC5322]), even if the proto-article is not to be injected for some
time after its composition. However, note that all implementations time after its composition. However, note that all implementations
predating this specification ignore the Injection-Date header field predating this specification ignore the Injection-Date header field
and use the Date header field in its stead for rejecting articles and use the Date header field in its stead for rejecting articles
older than their cutoff (see Section 3.3), and injecting agents older than their cutoff (see Section 3.3), and injecting agents
predating this specification do not add an Injection-Date header. predating this specification do not add an Injection-Date header.
Articles with a Date header field substantially in the past will Articles with a Date header field substantially in the past will
still be rejected by implementations predating this specification, still be rejected by implementations predating this specification,
regardless of the Injection-Date header field, and hence may suffer regardless of the Injection-Date header field, and hence may suffer
poorer propagation. poorer propagation.
Contrary to [RFC2822], which implies that the mailbox or mailboxes in Contrary to [RFC5322], which implies that the mailbox or mailboxes in
the From header field should be that of the poster or posters, a 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 poster who does not, for whatever reason, wish to use his own mailbox
MAY use any mailbox ending in the top level domain ".invalid" MAY use any mailbox ending in the top-level domain ".invalid"
[RFC2606]. [RFC2606].
Posting agents meant for use by ordinary posters SHOULD reject any Posting agents meant for use by ordinary posters SHOULD reject any
attempt to post an article which cancels or Supersedes another attempt to post an article that cancels or supersedes (via the
article of which the poster is not the author or sender. Supersedes header field) another article of which the poster is not
the author or sender.
3.4.1. Proto-articles 3.4.1. Proto-Articles
A proto-article is an article in the format used by a posting agent A proto-article is an article in the format used by a posting agent
for offering to an injecting agent. It may omit certain header when offering that article to an injecting agent. It may omit
fields which can be better-supplied by the injecting agent and will certain header fields that can be better supplied by the injecting
not contain header fields that are added by the injecting agent. A agent and will not contain header fields that are added by the
proto-article is only for transmission to an injecting agent and injecting agent. A proto-article is only for transmission to an
SHOULD NOT be transmitted to any other agent. injecting agent and SHOULD NOT be transmitted to any other agent.
RFC 5537 Netnews Architecture and Protocols November 2009
A proto-article has the same format as a normal article except that A proto-article has the same format as a normal article except that
the Injection-Info and Xref header fields MUST NOT be present; the the Injection-Info and Xref header fields MUST NOT be present, the
Path header field SHOULD NOT contain a "POSTED" <diag-keyword>; and Path header field SHOULD NOT contain a "POSTED" <diag-keyword>, and
any of the following mandatory header fields MAY be omitted: any of the following mandatory header fields MAY be omitted:
Message-ID, Date, and Path. In all other respects, a proto-article Message-ID, Date, and Path. In all other respects, a proto-article
MUST be a valid Netnews article. In particular, the header fields MUST be a valid Netnews article. In particular, the header fields
which may be omitted MUST NOT be present with invalid content. that may be omitted MUST NOT be present with invalid content.
If a posting agent intends to offer the same proto-article to If a posting agent intends to offer the same proto-article to
multiple injecting agents, the header fields Message-ID, Date, and multiple injecting agents, the header fields Message-ID, Date, and
Injection-Date MUST be present and identical in all copies of the Injection-Date MUST be present and identical in all copies of the
proto-article. See Section 3.4.2. proto-article. See Section 3.4.2.
3.4.2. Multiple Injection of Articles 3.4.2. Multiple Injection of Articles
Under some circumstances (posting to multiple supposedly disjoint Under some circumstances (for example, when posting to multiple,
networks, injecting agents with spotty connectivity, or for supposedly disjoint, networks, when using injecting agents with
redundancy, for example), a posting agent may wish to offer the same spotty connectivity, or when desiring additional redundancy), a
article to multiple injecting agents. In this unusual case, the goal posting agent may wish to offer the same article to multiple
is to not create multiple independent articles but rather to inject injecting agents. In this unusual case, the goal is not to create
the same article at multiple points and let the normal duplicate multiple independent articles but rather to inject the same article
suppression facility of Netnews (see Section 3.3) ensure that any at multiple points and let the normal duplicate suppression facility
given agent accepts the article only once, even if supposedly of Netnews (see Section 3.3) ensure that any given agent accepts the
disjoint networks have unexpected links. article only once, even if supposedly disjoint networks have
unexpected links.
Whenever possible, multiple injection SHOULD be done by offering the Whenever possible, multiple injection SHOULD be done by offering the
same proto-article to multiple injecting agents. The posting agent same proto-article to multiple injecting agents. The posting agent
MUST supply the Message-ID, Date, and Injection-Date header fields, MUST supply the Message-ID, Date, and Injection-Date header fields,
and the proto-article as offered to each injecting agent MUST be and the proto-article as offered to each injecting agent MUST be
identical. identical.
In some cases, offering the same proto-article to all injecting In some cases, offering the same proto-article to all injecting
agents may not be possible (such as when gatewaying, after injection, agents may not be possible (such as when gatewaying, after injection,
articles found on one Netnews network to another supposedly- articles found on one Netnews network to another supposedly
unconnected one). In this case, the posting agent MUST remove any unconnected one). In this case, the posting agent MUST remove any
Xref header field and rename or remove any Injection-Info, Path, and Xref header field and rename or remove any Injection-Info, Path, and
other trace header field before passing it to another injecting other trace header fields before passing it to another injecting
agent. (This converts the article back into a proto-article.) It agent. (This converts the article back into a proto-article.) It
MUST retain unmodified the Message-ID, Date, and Injection-Date MUST retain unmodified the Message-ID, Date, and Injection-Date
header fields. It MUST NOT add an Injection-Date header field if it header fields. It MUST NOT add an Injection-Date header field if it
is missing from the existing article. is missing from the existing article.
NOTE: Multiple injection inherently risks duplicating articles. NOTE: Multiple injection inherently risks duplicating articles.
Multiple injection after injection, by converting an article back Multiple injection after injection, by converting an article back
to a proto-article and injecting it again, additionally risks to a proto-article and injecting it again, additionally risks
loops, loss of trace information, unintended repeat injection into loops, loss of trace information, unintended repeat injection into
the same network, and other problems. It should be done with care the same network, and other problems. It should be done with care
RFC 5537 Netnews Architecture and Protocols November 2009
and only when there is no alternative. The requirement to retain and only when there is no alternative. The requirement to retain
Message-ID, Date, and Injection-Date header fields minimizes the Message-ID, Date, and Injection-Date header fields minimizes the
possibility of a loop and ensures that the newly injected article possibility of a loop and ensures that the newly injected article
is not treated as a new, separate article. is not treated as a new, separate article.
Multiple injection of an article listing one or more moderated Multiple injection of an article that lists one or more moderated
newsgroups in its Newsgroups header field SHOULD only be done by a newsgroups in its Newsgroups header field SHOULD only be done by a
moderator and MUST only be done after the proto-article has been moderator and MUST only be done after the proto-article has been
approved for all moderated groups to which it is to be posted and has approved for all moderated groups to which it is to be posted and
an Approved header field (see Section 3.9). Multiple injection of an after an Approved header field has been added (see Section 3.9).
unapproved article intended for moderated newsgroups will normally Multiple injection of an unapproved article intended for moderated
only result in the moderator receiving multiple copies, and if the newsgroups will normally only result in the moderator receiving
newsgroup status is not consistent across all injecting agents, may multiple copies, and if the newsgroup status is not consistent across
result in duplication of the article or other problems. all injecting agents, may result in duplication of the article or
other problems.
3.4.3. Followups 3.4.3. Followups
A followup is an article that contains a response to the contents of A followup is an article that contains a response to the contents of
an earlier article, its precursor. In addition to its normal duties, an earlier article, its precursor. In addition to its normal duties,
a posting agent preparing a followup is also subject to the following a posting agent preparing a followup is also subject to the following
requirements. Wherever in the following it is stated that by default requirements. Wherever in the following it is stated that, by
a header field is said to be inherited from one of those header default, a header field is said to be inherited from one of those
fields in the precursor, it means that its initial content is to be a header fields in the precursor, it means that its initial content is
copy of the content of that precursor header field (with changes in to be a copy of the content of that precursor header field (with
folding permitted). However, posters MAY then override that default changes in folding permitted). However, posters MAY then override
before posting. that default before posting.
Despite the historic practice of some posting agents, the Keywords Despite the historic practice of some posting agents, the Keywords
header field SHOULD NOT be inherited by default from the precursor header field SHOULD NOT be inherited by default from the precursor
article. article.
1. If the Followup-To header field of the precursor article consists 1. If the Followup-To header field of the precursor article consists
of "poster", the followup MUST NOT be posted by default but by 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 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-To or From header field following the rules for an email
reply [RFC2822]. This action MAY be overridden by the poster, in reply [RFC5322]. This action MAY be overridden by the poster, in
which case the posting agent should continue as if the which case the posting agent should continue as if the
Followup-To header field in the precursor did not exist. Followup-To header field in the precursor did not exist.
2. The Newsgroups header field SHOULD by default be inherited from 2. The Newsgroups header field SHOULD, by default, be inherited from
the precursor's Followup-To header field if present, and the precursor's Followup-To header field if present; otherwise,
otherwise from the precursor's Newsgroups header field. it is inherited from the precursor's Newsgroups header field.
3. The Subject header field SHOULD by default be inherited from that RFC 5537 Netnews Architecture and Protocols November 2009
of the precursor. The case-sensitive string "Re: " (including
the space after the colon) MAY be prepended to the content of its 3. The Subject header field SHOULD, by default, be inherited from
Subject header field unless it already begins with that string. 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 NOTE: Prepending "Re: " serves no protocol function and hence
is not required, but it is widely expected and not doing so is not required, but it is widely expected and not doing so
would be surprising. would be surprising.
4. The Distribution header field SHOULD by default be inherited from 4. The Distribution header field SHOULD, by default, be inherited
the precursor's Distribution header field, if present. from the precursor's Distribution header field, if present.
5. The followup MUST have a References header field referring to its 5. The followup MUST have a References header field referring to its
precursor constructed in accordance with Section 3.4.4. precursor, constructed in accordance with Section 3.4.4.
3.4.4. Construction of the References Header Field 3.4.4. Construction of the References Header Field
The following procedure is to be used whenever some previous article The following procedure is to be used whenever some previous article
(the "parent") is to be referred to in the References header field of (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 a new article, whether because the new article is a followup and the
parent is its precursor or for some other reason. parent is its precursor or for some other reason.
The content of the new article's References header field MUST be The content of the new article's References header field MUST be
formed from the content of the parent's References header field if formed from the content of the parent's References header field if
present, followed by the content of the Message-ID header field of present, followed by the content of the Message-ID header field of
the parent. If the parent had a References header, FWS as defined in 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 [RFC5536] MUST be added between its content and the Message-ID header
field content. field content.
If the resulting References header field would, after unfolding, If the resulting References header field would, after unfolding,
exceed 998 characters in length (including its field name but not the exceed 998 characters in length (including its field name but not the
final CRLF), it MUST be trimmed (and otherwise MAY be trimmed). final CRLF), it MUST be trimmed (and otherwise MAY be trimmed).
Trimming means removing any number of message identifiers from its Trimming means removing any number of message identifiers from its
content, except that the first message identifier and the last two content, except that the first message identifier and the last two
MUST NOT be removed. MUST NOT be removed.
An essential property of the References header field, guaranteed by An essential property of the References header field, guaranteed by
the above procedure and REQUIRED to be maintained by any extensions the above procedure and REQUIRED to be maintained by any extensions
to this protocol, is that an article MUST NOT precede one of its to this protocol, is that an article MUST NOT precede one of its
parents. parents.
3.5. Duties of an Injecting Agent 3.5. Duties of an Injecting Agent
An injecting agent takes a proto-article from a posting agent and 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 either forwards it to a moderator or passes it to a relaying or
serving agent or agents. An injecting agent bears the primary serving agent or agents. An injecting agent bears the primary
responsibility for ensuring that any article it injects conforms with responsibility for ensuring that any article it injects conforms with
RFC 5537 Netnews Architecture and Protocols November 2009
the rules of the Netnews standards. The administrator of an the rules of the Netnews standards. The administrator of an
injecting agent is also expected to bear some responsibility towards injecting agent is also expected to bear some responsibility towards
the rest of the Netnews network to which it is connected for the the rest of the Netnews network to which it is connected for the
articles the injecting agent accepts. articles the injecting agent accepts.
Injecting agents, when rejecting articles, are encouraged to Injecting agents, when rejecting articles, are encouraged to
communicate the reason for rejection to the posting agent using communicate the reason for rejection to the posting agent by using
whatever facility is provided by the underlying transport. The whatever facility is provided by the underlying transport. The
injecting agent is in a unique position to communicate the reason for injecting agent is in a unique position to communicate the reason for
rejection; relaying agents and serving agents normally have to reject rejection; relaying agents and serving agents normally have to reject
messages silently. The injecting agent therefore bears much of the messages silently. The injecting agent therefore bears much of the
burden of diagnosing broken posting agents or communicating policy burden of diagnosing broken posting agents or communicating policy
violations to posters. violations to posters.
An injecting agent MUST have available a list (possibly empty) of An injecting agent MUST have available a list (possibly empty) of
moderated groups for which it accepts articles and the corresponding moderated groups for which it accepts articles and the corresponding
submission addresses. It SHOULD have available a list of valid submission addresses. It SHOULD have available a list of valid
newsgroups to catch articles not posted to a valid newsgroup and newsgroups to catch articles not posted to a valid newsgroup and
therefore likely to be silently discarded by relaying and serving therefore likely to be silently discarded by relaying and serving
agents. Usually, an injecting agent is deployed in conjunction with agents. Usually, an injecting agent is deployed in conjunction with
a serving agent and maintains these lists based on control messages a serving agent and maintains these lists based on control messages
received by the serving agent. received by the serving agent.
An injecting agent processes proto-articles as follows: An injecting agent processes proto-articles as follows:
1. It SHOULD verify that the article is from a trusted source (by, 1. It SHOULD verify that the article is from a trusted source (for
for example, relying on the authorization capability of the example, by relying on the authorization capability of the
underlying transport used to talk to the posting agent). underlying transport used to talk to the posting agent).
2. It MUST reject any proto-article that does not have the proper 2. It MUST reject any proto-article that does not have the proper
mandatory header fields for a proto-article; that has Injection- mandatory header fields for a proto-article, that has Injection-
Info or Xref header fields; that has a Path header field Info or Xref header fields, that has a Path header field
containing the "POSTED" <diag-keyword>; or that is not containing the "POSTED" <diag-keyword>, or that is not
syntactically valid as defined by [USEFOR]. It SHOULD reject syntactically valid as defined by [RFC5536]. It SHOULD reject
any proto-article which contains a header field deprecated for any proto-article that contains a header field deprecated for
Netnews (see, for example, [RFC3798]). It MAY reject any proto- Netnews (see, for example, [RFC3798]). It MAY reject any proto-
article that contains trace header fields (e.g., NNTP-Posting- article that contains trace header fields (e.g., NNTP-Posting-
Host) indicating that it was already injected by an injecting Host) indicating that it was already injected by an injecting
agent that did not add Injection-Info or Injection-Date. agent that did not add Injection-Info or Injection-Date.
3. It SHOULD reject any article whose Injection-Date or Date header 3. It SHOULD reject any article whose Injection-Date or Date header
field is more than 24 hours into the future (and MAY use a field is more than 24 hours into the future (and MAY use a
margin less than 24 hours). It SHOULD reject any article whose margin less than 24 hours). It SHOULD reject any article whose
Injection-Date header field is too far in the past (older than Injection-Date header field is too far in the past (older than
the cutoff interval of a relaying agent the injecting agent is the cutoff interval of a relaying agent that the injecting agent
using, for example). It SHOULD similarly reject any article is using, for example). It SHOULD similarly reject any article
whose Date header field is too far in the past, since not all whose Date header field is too far in the past, since not all
news servers support Injection-Date and only the injecting agent news servers support Injection-Date and only the injecting agent
RFC 5537 Netnews Architecture and Protocols November 2009
can provide a useful error message to the posting agent. In can provide a useful error message to the posting agent. In
either case, this interval SHOULD NOT be any shorter than 72 either case, this interval SHOULD NOT be any shorter than 72
hours into the past. hours into the past.
4. It SHOULD reject any proto-article whose Newsgroups header field 4. It SHOULD reject any proto-article whose Newsgroups header field
does not contain at least one <newsgroup-name> for a valid does not contain at least one <newsgroup-name> for a valid
group, or containing a <newsgroup-name> reserved for specific group, or that contains a <newsgroup-name> reserved for specific
purposes by Section 3.1.4 of [USEFOR] unless that specific purposes by Section 3.1.4 of [RFC5536] unless that specific
purpose or local agreement applies to the proto-article being purpose or local agreement applies to the proto-article being
processed. Crossposting to unknown newsgroups is not precluded processed. Crossposting to unknown newsgroups is not precluded
provided that at least one of the newsgroups in the Newsgroups provided that at least one of the newsgroups in the Newsgroups
header is valid. header is valid.
5. The Message-ID and Date header fields with appropriate contents 5. The Message-ID and Date header fields with appropriate contents
MUST be added when not present in the proto-article. MUST be added when not present in the proto-article.
6. The injecting agent MUST NOT alter the body of the article in 6. The injecting agent MUST NOT alter the body of the article in
any way (including any change of Content-Transfer-Encoding). It any way (including any change of Content-Transfer-Encoding). It
skipping to change at page 20, line 28 skipping to change at page 17, line 46
it. This forwarding MUST be done after adding the Message-ID it. This forwarding MUST be done after adding the Message-ID
and Date headers if required, and before adding the Injection- and Date headers if required, and before adding the Injection-
Info and Injection-Date headers. Info and Injection-Date headers.
8. Otherwise, a Path header field with a <tail-entry> MUST be added 8. Otherwise, a Path header field with a <tail-entry> MUST be added
if not already present. if not already present.
9. The injecting agent MUST then update the Path header field as 9. The injecting agent MUST then update the Path header field as
described in Section 3.2.1. described in Section 3.2.1.
10. An Injection-Info header field SHOULD be added identifying the 10. An Injection-Info header field SHOULD be added that identifies
source of the article and possibly other trace information as the source of the article and possibly other trace information
described in Section 3.2.8 of [USEFOR]. as described in Section 3.2.8 of [RFC5536].
11. If the proto-article already had an Injection-Date header field, 11. If the proto-article already had an Injection-Date header field,
it MUST NOT be modified or replaced. If the proto-article had it MUST NOT be modified or replaced. If the proto-article had
both a Message-ID header field and a Date header field, an both a Message-ID header field and a Date header field, an
Injection-Date header field MUST NOT be added, since the proto- Injection-Date header field MUST NOT be added, since the proto-
article may have been multiply injected by a posting agent that article may have been multiply injected by a posting agent that
RFC 5537 Netnews Architecture and Protocols November 2009
predates this standard. Otherwise, the injecting agent MUST add predates this standard. Otherwise, the injecting agent MUST add
an Injection-Date header field containing the current date and an Injection-Date header field containing the current date and
time. time.
12. Finally, the injecting agent forwards the article to one or more 12. Finally, the injecting agent forwards the article to one or more
relaying agents, and the injection process is complete. relaying agents, and the injection process is complete.
3.5.1. Forwarding Messages to a Moderator 3.5.1. Forwarding Messages to a Moderator
An injecting agent MUST forward the proto-article to the moderator of An injecting agent MUST forward the proto-article to the moderator of
skipping to change at page 21, line 12 skipping to change at page 18, line 31
1. The complete proto-article is encapsulated, header fields and 1. The complete proto-article is encapsulated, header fields and
all, within the email. This SHOULD be done by creating an email all, within the email. This SHOULD be done by creating an email
message with a Content-Type of application/news-transmission with message with a Content-Type of application/news-transmission with
the usage parameter set to "moderate". The body SHOULD NOT the usage parameter set to "moderate". The body SHOULD NOT
contain any content other than the message. This method has the contain any content other than the message. This method has the
advantage of removing any possible conflict between Netnews and advantage of removing any possible conflict between Netnews and
email header fields and any changes to those fields during email header fields and any changes to those fields during
transport through email. transport through email.
2. The proto-article is sent as an email with the addition of any 2. The proto-article is sent as an email with the addition of any
header fields required for an email as defined in [RFC2822], and header fields required for an email as defined in [RFC5322], and
possibly with the addition of other header fields conventional in possibly with the addition of other header fields conventional in
email such as To and Received. The existing Message-ID header email, such as To and Received. The existing Message-ID header
field SHOULD be retained. field SHOULD be retained.
Although both of these methods have been used in the past and the Although both of these methods have been used in the past and the
first has clear technical advantages, the second is in more common first has clear technical advantages, the second is in more common
use and many moderators are not prepared to deal with messages in the use and many moderators are not prepared to deal with messages in the
first format. Accordingly, the first method SHOULD NOT be used first format. Accordingly, the first method SHOULD NOT be used
unless the moderator to which it is being forwarded is known to be unless the moderator to which it is being forwarded is known to be
able to handle this method. able to handle this method.
NOTE: Deriving the email address of the moderator of a group is NOTE: Deriving the email address of the moderator of a group is
outside the scope of this document. It is worth mentioning, outside the scope of this document. It is worth mentioning,
however, that a common method is to use a forwarding service that however, that a common method is to use a forwarding service that
handles submissions for many moderated groups. For maximum handles submissions for many moderated groups. For maximum
compatibility with existing news servers, such forwarding services compatibility with existing news servers, such forwarding services
generally form the submission address for a moderated group by generally form the submission address for a moderated group by
replacing each "." in the <newsgroup-name> with "-" and then using replacing each "." in the <newsgroup-name> with "-" and then using
that value as the <local-part> of a <mailbox> formed by appending that value as the <local-part> of a <mailbox> formed by appending
a set domain. a set domain.
RFC 5537 Netnews Architecture and Protocols November 2009
Forwarding proto-articles to moderators via email is the most general Forwarding proto-articles to moderators via email is the most general
method and most common in large Netnews networks such as Usenet, but method and the most common in large Netnews networks such as Usenet,
any means of forwarding the article that preserves it without but any means of forwarding the article that preserves it without
injecting it MAY be used. For example, if the injecting agent has injecting it MAY be used. For example, if the injecting agent has
access to a database used by the moderator to store proto-articles access to a database used by the moderator to store proto-articles
awaiting processing, it may place the proto-article directly into awaiting processing, it may place the proto-article directly into
that database. Such methods may be more appropriate for smaller that database. Such methods may be more appropriate for smaller
Netnews networks. Netnews networks.
3.6. Duties of a Relaying Agent 3.6. Duties of a Relaying Agent
A relaying agent accepts injected articles from injecting and other A relaying agent accepts injected articles from injecting and other
relaying agents and passes them on to relaying or serving agents. To relaying agents and passes them on to relaying or serving agents. To
avoid bypass of injecting agent policies and forgery of Path and avoid bypass of injecting agent policies and forgery of Path and
Injector-Info headers, relaying agents SHOULD accept articles only Injection-Info headers, relaying agents SHOULD accept articles only
from trusted agents. from trusted agents.
An article SHOULD NOT be relayed unless the sending agent has been An article SHOULD NOT be relayed unless the sending agent has been
configured to supply and the receiving agent to receive at least one configured to supply, and the receiving agent to receive, at least
of the <newsgroup-name>s in its Newsgroups header field and at least one of the <newsgroup-name>s in its Newsgroups header field and at
one of the <dist-name>s in its Distribution header field (if least one of the <dist-name>s in its Distribution header field (if
present). Exceptionally, control messages creating or removing present). Exceptionally, control messages creating or removing
newsgroups (newgroup or rmgroup control messages, for example) SHOULD newsgroups (newgroup or rmgroup control messages, for example) SHOULD
be relayed if the affected group appears in its Newsgroups header be relayed if the affected group appears in its Newsgroups header
field and both the sending and receiving relaying agents are field and both the sending and receiving relaying agents are
configured to relay a newsgroup of that name (whether or not such a configured to relay a newsgroup of that name (whether or not such a
newsgroup exists). newsgroup exists).
In order to avoid unnecessary relaying attempts, an article SHOULD In order to avoid unnecessary relaying attempts, an article SHOULD
NOT be relayed if the <path-identity> of the receiving agent (or some NOT be relayed if the <path-identity> of the receiving agent (or some
known alias thereof) appears as a <path-identity> (excluding within known alias thereof) appears as a <path-identity> (excluding within
skipping to change at page 22, line 31 skipping to change at page 20, line 5
1. It MUST reject any article without a Newsgroups header field or 1. It MUST reject any article without a Newsgroups header field or
Message-ID header field, or without either an Injection-Date or Message-ID header field, or without either an Injection-Date or
Date header field. Date header field.
2. It MUST examine the Injection-Date header field or, if absent, 2. It MUST examine the Injection-Date header field or, if absent,
the Date header field, and reject the article if that date is the Date header field, and reject the article if that date is
more than 24 hours into the future. It MAY reject articles with more than 24 hours into the future. It MAY reject articles with
dates in the future with a smaller margin than 24 hours. dates in the future with a smaller margin than 24 hours.
RFC 5537 Netnews Architecture and Protocols November 2009
3. It MUST reject any article that has already been accepted. If it 3. It MUST reject any article that has already been accepted. If it
implements one of the mechanisms described in Section 3.3, this implements one of the mechanisms described in Section 3.3, this
means that it MUST reject any article whose date falls outside means that it MUST reject any article whose date falls outside
the cutoff interval since it won't know whether such articles had the cutoff interval since it won't know whether or not such
been accepted previously or not. articles had been accepted previously.
4. It SHOULD reject any article that does not include all the 4. It SHOULD reject any article that does not include all the
mandatory header fields. It MAY reject any article that contains mandatory header fields. It MAY reject any article that contains
header fields that do not have valid contents. header fields that do not have valid contents.
5. It SHOULD reject any article that matches an already-received 5. It SHOULD reject any article that matches an already-received
cancel control message or the contents of the Supersedes header cancel control message or the contents of the Supersedes header
field of an accepted article, provided that the relaying agent field of an accepted article, provided that the relaying agent
has chosen (on the basis of local site policy) to honor that has chosen (on the basis of local site policy) to honor that
cancel control message or Supersedes header field. cancel control message or Supersedes header field.
6. It MAY reject any article without an Approved header field posted 6. It MAY reject any article without an Approved header field posted
to a newsgroup known to be moderated. This practice is strongly to a newsgroup known to be moderated. This practice is strongly
encouraged but the information necessary to do so is not required encouraged, but the information necessary to do so is not
to be maintained by a relaying agent. required to be maintained by a relaying agent.
7. It MUST update the Path header field as described in 7. It MUST update the Path header field as described in
Section 3.2.1. Section 3.2.1.
8. It MAY delete any Xref header field already present. It MAY add 8. It MAY delete any Xref header field already present. It MAY add
a new Xref header field for its own use (but recall that [USEFOR] a new Xref header field for its own use (but recall that
permits at most one such header field). [RFC5536] permits at most one such header field).
9. Finally, it passes the article on to other relaying and serving 9. Finally, it passes the article on to other relaying and serving
agents to which it is configured to send articles. agents to which it is configured to send articles.
Relaying agents SHOULD, where possible in the underlying transport, Relaying agents SHOULD, where possible in the underlying transport,
inform the agent that passed the article to the relaying agent if the inform the agent that passed the article to the relaying agent if the
article was rejected. Relaying agents MUST NOT inform any other article was rejected. Relaying agents MUST NOT inform any other
external entity of the rejection of an article unless that external external entity of the rejection of an article unless that external
entity has explicitly requested that it be informed of such errors. entity has explicitly requested that it be informed of such errors.
Relaying agents MUST NOT alter, delete, or rearrange any part of an Relaying agents MUST NOT alter, delete, or rearrange any part of an
article except for the Path and Xref header fields. They MUST NOT 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 modify the body of articles in any way. If an article is not
acceptable as-is, the article MUST be rejected rather than modified. acceptable as is, the article MUST be rejected rather than modified.
RFC 5537 Netnews Architecture and Protocols November 2009
3.7. Duties of a Serving Agent 3.7. Duties of a Serving Agent
A serving agent accepts articles from a relaying agent or injecting A serving agent accepts articles from a relaying agent or injecting
agent, stores it, and makes it available to reading agents. Articles agent, stores them, and makes them available to reading agents.
are normally indexed by newsgroup and <article-locator> (Section Articles are normally indexed by newsgroup and <article-locator>
3.2.14 of [USEFOR]), usually in the form of a decimal number. (Section 3.2.14 of [RFC5536]), usually in the form of a decimal
number.
If the serving agent stores articles by newsgroup, control messages If the serving agent stores articles by newsgroup, control messages
SHOULD NOT be stored in the newsgroups listed in the control SHOULD NOT be stored in the newsgroups listed in the control
message's Newsgroups header field. Instead, they SHOULD be stored in message's Newsgroups header field. Instead, they SHOULD be stored in
a newsgroup in the hierarchy "control", which is reserved for this a newsgroup in the hierarchy "control", which is reserved for this
purpose. Conventionally, control messages are stored in newsgroups purpose. Conventionally, control messages are stored in newsgroups
named for the type of control message (such as "control.cancel" for named for the type of control message (such as "control.cancel" for
cancel control messages). cancel control messages).
A serving agent MUST have available a list (possibly empty) of A serving agent MUST have available a list (possibly empty) of
moderated groups for which it accepts articles so that it can reject moderated groups for which it accepts articles so that it can reject
unapproved articles posted to moderated groups. Frequently a serving unapproved articles posted to moderated groups. Frequently, a
agent is deployed in combination with an injecting agent and can use serving agent is deployed in combination with an injecting agent and
the same list as the injecting agent. can use the same list as the injecting agent.
A serving agent processes articles as follows: A serving agent processes articles as follows:
1. It MUST reject any article that does not include all the 1. It MUST reject any article that does not include all the
mandatory header fields or any article which contains header mandatory header fields or any article that contains header
fields that do not have valid contents. fields that do not have valid contents.
2. It MUST examine the Injection-Date header field or, if absent, 2. It MUST examine the Injection-Date header field or, if absent,
the Date header field, and reject the article if that date is the Date header field, and reject the article if that date is
more than 24 hours into the future. It MAY reject articles with more than 24 hours into the future. It MAY reject articles with
dates in the future with a smaller margin than 24 hours. dates in the future with a smaller margin than 24 hours.
3. It MUST reject any article that has already been accepted. If it 3. It MUST reject any article that has already been accepted. If it
implements one of the mechanisms described in Section 3.3, this implements one of the mechanisms described in Section 3.3, this
means that it MUST reject any article whose date falls outside means that it MUST reject any article whose date falls outside
the cutoff interval since it won't know whether such articles had the cutoff interval since it won't know whether or not such
been accepted previously or not. articles had been accepted previously.
4. It SHOULD reject any article that matches an already-received and 4. It SHOULD reject any article that matches an already-received and
honored cancel message or Supersedes header field following the honored cancel message or Supersedes header field, following the
same rules as a relaying agent (Section 3.6). same rules as a relaying agent (Section 3.6).
5. It MUST reject any article without an Approved header field 5. It MUST reject any article without an Approved header field
posted to any newsgroup listed as moderated. posted to any newsgroup listed as moderated.
6. It MUST update the Path header field as described in 6. It MUST update the Path header field as described in
Section 3.2.1. Section 3.2.1.
7. It MUST (except when specially configured to preserve the RFC 5537 Netnews Architecture and Protocols November 2009
<article-locator>s set by the sending site) remove any Xref
header field from each article. It then MAY (and usually will) 7. It MUST remove any Xref header field from each article (except
add a new Xref header field (but recall that [USEFOR] permits at when specially configured to preserve the <article-locator>s set
most one such header field). by the sending site). It then MAY (and usually will) add a new
Xref header field (but recall that [RFC5536] permits at most one
such header field).
8. Finally, it stores the article and makes it available for reading 8. Finally, it stores the article and makes it available for reading
agents. agents.
Serving agents MUST NOT create new newsgroups simply because an Serving agents MUST NOT create new newsgroups simply because an
unrecognized <newsgroup-name> occurs in a Newsgroups header field. unrecognized <newsgroup-name> occurs in a Newsgroups header field.
Newsgroups are normally created via control messages (Section 5.2.1). Newsgroups are normally created via control messages (Section 5.2.1).
Serving agents MUST NOT alter, delete, or rearrange any part of an Serving agents MUST NOT alter, delete, or rearrange any part of an
article except for the Path and Xref header fields. They MUST NOT 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 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. acceptable as is, the article MUST be rejected rather than modified.
3.8. Duties of a Reading Agent 3.8. Duties of a Reading Agent
Since a reading agent is only a passive participant in a Netnews Since a reading agent is only a passive participant in a Netnews
network, there are no specific protocol requirements placed on it. network, there are no specific protocol requirements placed on it.
See [USEAGE] for best-practice recommendations. See [USEAGE] for best-practice recommendations.
3.9. Duties of a Moderator 3.9. Duties of a Moderator
A moderator receives news articles, customarily by email, decides A moderator receives news articles, customarily by email, decides
whether to approve them and, if so, either passes them to an whether to approve them and, if so, either passes them to an
injecting agent or forwards them to further moderators. injecting agent or forwards them to further moderators.
Articles are normally received by the moderator in email either Articles are normally received by the moderator in email, either
encapsulated as an object of Content-Type application/ encapsulated as an object of Content-Type application/
news-transmission (or possibly encapsulated but without an explicit news-transmission (or possibly encapsulated but without an explicit
Content-Type header field), or else directly as an email already Content-Type header field) or else directly as an email already
containing all the header fields appropriate for a Netnews article containing all the header fields appropriate for a Netnews article
(see Section 3.5.1). Moderators who may receive articles via email (see Section 3.5.1). Moderators who may receive articles via email
SHOULD be prepared to accept articles in either format. SHOULD be prepared to accept articles in either format.
There are no protocol restrictions on what criteria are used for There are no protocol restrictions on what criteria are used for
accepting or rejecting messages or on what modifications a moderator accepting or rejecting messages or on what modifications a moderator
may make to a message (both header fields and body) before injecting may make to a message (both header fields and body) before injecting
it. Recommended best practice, however, is to make the minimal it. Recommended best practice, however, is to make the minimal
required changes. Moderators need to be aware that modifications required changes. Moderators need to be aware that modifications
made to articles may invalidate signatures created by the poster or made to articles may invalidate signatures created by the poster or
previous moderators. See [USEAGE] for further best-practice previous moderators. See [USEAGE] for further best-practice
recommendations. recommendations.
RFC 5537 Netnews Architecture and Protocols November 2009
Moderators process articles as follows: Moderators process articles as follows:
1. They decide whether to approve or reject a proto-article, and if 1. They decide whether to approve or reject a proto-article and, if
approved, prepare the proto-article for injection. If the proto- approved, prepare the proto-article for injection. If the proto-
article was received as an unencapsulated email message, this article was received as an unencapsulated email message, this
will require converting it back to a valid Netnews proto-article. will require converting it back to a valid Netnews proto-article.
If the article is rejected, it is normally rejected for all If the article is rejected, it is normally rejected for all
newsgroups to which it was posted and nothing further is done. newsgroups to which it was posted and nothing further is done.
If it is approved, the moderator proceeds with the following If it is approved, the moderator proceeds with the following
steps. steps.
2. If the Newsgroups header field contains further moderated 2. If the Newsgroups header field contains further moderated
newsgroups for which approval has not already been given, they newsgroups for which approval has not already been given, they
may either reach some agreement with the other moderators on the may either reach some agreement with the other moderators on the
disposition of the article or, more generally, add an indication disposition of the article or, more generally, add an indication
(identifying both the moderator and the name of the newsgroup) (identifying both the moderator and the name of the newsgroup)
that they approve the article and then forward it to the that they approve the article and then forward it to the
moderator of the leftmost unapproved newsgroup. This forwarding moderator of the leftmost unapproved newsgroup. This forwarding
SHOULD be done following the procedure in Section 3.5.1 and MAY SHOULD be done following the procedure in Section 3.5.1. It MAY
be done by rotating the <newsgroup-name>s in the Newsgroups be done by rotating the <newsgroup-name>s in the Newsgroups
header field so that the leftmost unapproved newsgroup is is the header field so that the leftmost unapproved newsgroup is the
leftmost moderated newsgroup in that field and then posting it, leftmost moderated newsgroup in that field and then posting it,
letting the injecting agent do the forwarding. However, if using letting the injecting agent do the forwarding. However, when
this mechanism, they MUST first ensure that the article contains using this mechanism, they MUST first ensure that the article
no Approved header field. contains no Approved header field.
3. If the Newsgroups header field contains no further unapproved 3. If the Newsgroups header field contains no further unapproved
moderated groups, they add an Approved header field (see Section moderated groups, they add an Approved header field (see Section
3.2.1 of [USEFOR]) identifying the moderator and, insofar as is 3.2.1 of [RFC5536]) identifying the moderator and, insofar as is
possible, all the other moderators who have approved the article. possible, all the other moderators who have approved the article.
The moderator who takes this step assumes responsibility for The moderator who takes this step assumes responsibility for
ensuring that the article was approved by the moderators of all ensuring that the article was approved by the moderators of all
moderated newsgroups to which it was posted. moderated newsgroups to which it was posted.
4. Moderators are encouraged to retain the Message-ID header field 4. Moderators are encouraged to retain the Message-ID header field
unless it is invalid or the article was significantly changed unless it is invalid or the article was significantly changed
from its original form. Moderators are also encouraged to retain from its original form. Moderators are also encouraged to retain
the Date header field unless it appears to be stale (72 hours or the Date header field unless it appears to be stale (72 hours or
more in the past) for reasons understood by the moderator (such more in the past) for reasons understood by the moderator (such
as delays in the moderation process) in which case they MAY as delays in the moderation process), in which case they MAY
substitute the current date. Any Injection-Date, Injection-Info, substitute the current date. Any Injection-Date, Injection-Info,
or Xref header fields already present MUST be removed. or Xref header fields already present MUST be removed.
5. Any Path header field MUST either be removed or truncated to only 5. Any Path header field MUST either be removed or truncated to only
those entries following its "POSTED" <diag-keyword>, if any. those entries following its "POSTED" <diag-keyword>, if any.
6. The moderator then passes the article to an injecting agent, 6. The moderator then passes the article to an injecting agent,
having first observed all the duties of a posting agent. having first observed all the duties of a posting agent.
RFC 5537 Netnews Architecture and Protocols November 2009
3.10. Duties of a Gateway 3.10. Duties of a Gateway
A gateway transforms an article into the native message format of A gateway transforms an article into the native message format of
another medium, or translates the messages of another medium into another medium, or translates the messages of another medium into
news articles, or transforms articles into proto-articles for news articles, or transforms articles into proto-articles for
injection into a separate Netnews network. Encapsulation of a news injection into a separate Netnews network. Encapsulation of a news
article into a message of MIME type application/news-transmission, or article into a message of MIME type application/news-transmission, or
the subsequent undoing of that encapsulation, is not gatewaying, the subsequent undoing of that encapsulation, is not gatewaying since
since it involves no transformation of the article. it involves no transformation of the article.
There are two basic types of gateway, the outgoing gateway that There are two basic types of gateway, the outgoing gateway that
transforms a news article into a different type of message, and the transforms a news article into a different type of message, and the
incoming gateway that transforms a message from another network into incoming gateway that transforms a message from another network into
a news proto-article and injects it into a Netnews network. These a news proto-article and injects it into a Netnews network. These
are handled separately below. are handled separately below.
Transformation of an article into another medium stands a very high Transformation of an article into another medium stands a very high
chance of discarding or interfering with the protection inherent in chance of discarding or interfering with the protection inherent in
the news system against duplicate articles. The most common problem the news system against duplicate articles. The most common problem
skipping to change at page 27, line 26 skipping to change at page 25, line 4
Safe bidirectional gatewaying between a mailing list and a newsgroup Safe bidirectional gatewaying between a mailing list and a newsgroup
is far easier if the newsgroup is moderated. Posts to the moderated is far easier if the newsgroup is moderated. Posts to the moderated
group and submissions to the mailing list can then go through a group and submissions to the mailing list can then go through a
single point that does the necessary gatewaying and then sends the single point that does the necessary gatewaying and then sends the
message out to both the newsgroup and the mailing list at the same message out to both the newsgroup and the mailing list at the same
time, eliminating most of the possibility of loops. Bidirectional time, eliminating most of the possibility of loops. Bidirectional
gatewaying between a mailing list and an unmoderated newsgroup, in gatewaying between a mailing list and an unmoderated newsgroup, in
contrast, is difficult to do correctly and is far more fragile. contrast, is difficult to do correctly and is far more fragile.
Newsgroups intended to be bidirectionally gated to a mailing list Newsgroups intended to be bidirectionally gated to a mailing list
SHOULD therefore be moderated where possible, even if the moderator SHOULD therefore be moderated where possible, even if the moderator
RFC 5537 Netnews Architecture and Protocols November 2009
is a simple gateway and injecting agent that correctly handles is a simple gateway and injecting agent that correctly handles
crossposting to other moderated groups and otherwise passes all crossposting to other moderated groups and otherwise passes all
traffic. traffic.
3.10.1. Duties of an Outgoing Gateway 3.10.1. Duties of an Outgoing Gateway
From the perspective of Netnews, an outgoing gateway is just a From the perspective of Netnews, an outgoing gateway is just a
special type of reading agent. The exact nature of what the outgoing special type of reading agent. The exact nature of what the outgoing
gateway will need to do to articles depends on the medium to which gateway will need to do to articles depends on the medium to which
the articles are being gated. The operation of the outgoing gateway the articles are being gated. Because it raises the danger of loops
is subject to additional constraints due to the possibility of one or due to the possibility of one or more corresponding incoming gateways
more corresponding incoming gateways back from that medium to back from that medium to Netnews, the operation of the outgoing
Netnews, since this raises the danger of loops. gateway is subject to additional constraints.
The following practices are encouraged for all outgoing gateways, The following practices are encouraged for all outgoing gateways,
regardless of whether there is known to be a related incoming regardless of whether there is known to be a related incoming
gateway, both as precautionary measures and as a guideline to quality gateway, both as precautionary measures and as guidelines to quality
of implementation: of implementation:
1. The message identifier of the news article should be preserved if 1. The message identifier of the news article should be preserved if
at all possible, preferably as or within the corresponding unique at all possible, preferably as or within the corresponding unique
identifier of the other medium, but if not at least as a comment identifier of the other medium. However, if it is not preserved
in the message. This helps greatly with preventing loops. in this way, then at least it should be preserved as a comment in
the message. This helps greatly with preventing loops.
2. The Date and Injection-Date of the news article should also be 2. The Date and Injection-Date of the news article should also be
preserved if possible, for similar reasons. preserved if possible, for similar reasons.
3. The message should be tagged in some way so as to prevent its 3. The message should be tagged in some way so as to prevent its
reinjection into Netnews. This may be impossible to do without reinjection into Netnews. This may be impossible to do without
knowledge of potential incoming gateways, but it is better to try knowledge of potential incoming gateways, but it is better to try
to provide some indication even if not successful; at the least, to provide some indication even if not successful; at the least,
a human-readable indication that the article should not be gated a human-readable indication that the article should not be gated
back to Netnews can help locate a human problem. back to Netnews can help locate a human problem.
4. Netnews control messages should not be gated to another medium 4. Netnews control messages should not be gated to another medium
unless they would somehow be meaningful in that medium. unless they would somehow be meaningful in that medium.
3.10.2. Duties of an Incoming Gateway 3.10.2. Duties of an Incoming Gateway
The incoming gateway has the responsibility of ensuring that all of The incoming gateway has the responsibility of ensuring that all of
the requirements of this protocol are met by the articles that it 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 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 of the duties and responsibilities of a posting agent, and it has the
additionally has the same responsibility of a relaying agent to same responsibility of a relaying agent to reject articles that it
reject articles that it has already gatewayed. has already gatewayed.
RFC 5537 Netnews Architecture and Protocols November 2009
An incoming gateway MUST NOT gate the same message twice. It may not An incoming gateway MUST NOT gate the same message twice. It may not
be possible to ensure this in the face of mangling or modification of be possible to ensure this in the face of mangling or modification of
the message, but at the very least a gateway, when given a copy of a the message, but at the very least a gateway, when given a copy of a
message it has already gated identical except for trace header fields message that it has already gated and that is identical except for
(like Received in Email or Path in Netnews) MUST NOT gate the message trace header fields (like Received in Email or Path in Netnews), MUST
again. An incoming gateway SHOULD take precautions against having NOT gate the message again. An incoming gateway SHOULD take
this rule bypassed by modifications of the message that can be precautions against having this rule bypassed by modifications of the
anticipated. message that can be anticipated.
News articles prepared by gateways MUST be valid news proto-articles News articles prepared by gateways MUST be valid news proto-articles
(see Section 3.4.1). This often requires the gateway to synthesize a (see Section 3.4.1). This often requires the gateway to synthesize a
conforming article from non-conforming input. The gateway MUST then conforming article from non-conforming input. The gateway MUST then
pass the article to an injecting agent, not directly to a relaying pass the article to an injecting agent, not directly to a relaying
agent. agent.
Incoming gateways MUST NOT pass control messages (articles containing Incoming gateways MUST NOT pass control messages (articles containing
a Control or Supersedes header field) without removing or renaming a Control or Supersedes header field) without removing or renaming
that header field. Gateways MAY, however, generate cancel control that header field. Gateways MAY, however, generate cancel control
skipping to change at page 29, line 4 skipping to change at page 26, line 36
message that it can determine is a valid equivalent of a cancel message that it can determine is a valid equivalent of a cancel
control message in the medium it is gatewaying, it SHOULD discard control message in the medium it is gatewaying, it SHOULD discard
that message without gatewaying it, generate a corresponding cancel that message without gatewaying it, generate a corresponding cancel
control message of its own, and inject that cancel control message. 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 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 post control messages, but encapsulation should be used for these
cases instead. Gateways by their very nature are particularly cases instead. Gateways by their very nature are particularly
prone to loops. Spews of normal articles are bad enough; spews of prone to loops. Spews of normal articles are bad enough; spews of
control messages with special significance to the news system, control messages with special significance to the news system,
possibly resulting in high processing load or even email sent for possibly resulting in high processing load or even in emails being
every message received, are catastrophic. It is far preferable to sent for every message received, are catastrophic. It is far
construct a system specifically for posting control messages that preferable to construct a system specifically for posting control
can do appropriate consistency checks and authentication of the messages that can do appropriate consistency checks and
originator of the message. authentication of the originator of the message.
If there is a message identifier that fills a role similar to that of 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 the Message-ID header field in news, it SHOULD be used in the
formation of the message identifier of the news article, perhaps with formation of the message identifier of the news article, perhaps with
transformations required to meet the uniqueness requirement of transformations required to meet the uniqueness requirement of
Netnews and with the removal of any comments so as to comply with the Netnews and with the removal of any comments so as to comply with the
syntax in Section 3.1.3 of [USEFOR]. Such transformations SHOULD be syntax in Section 3.1.3 of [RFC5536]. Such transformations SHOULD be
designed so that two messages with the same identifier generate the designed so that two messages with the same identifier generate the
same Message-ID header field. same Message-ID header field.
NOTE: Message identifiers play a central role in the prevention of NOTE: Message identifiers play a central role in the prevention of
duplicates, and their correct use by gateways will do much to duplicates, and their correct use by gateways will do much to
prevent loops. Netnews does, however, require that message prevent loops. Netnews does, however, require that message
identifiers be unique, and therefore message identifiers from identifiers be unique, and therefore message identifiers from
RFC 5537 Netnews Architecture and Protocols November 2009
other media may not be suitable for use without modification. A other media may not be suitable for use without modification. A
balance must be struck by the gateway between preserving balance must be struck by the gateway between preserving
information used to prevent loops and generating unique message information used to prevent loops and generating unique message
identifiers. identifiers.
Exceptionally, if there are multiple incoming gateways for a Exceptionally, if there are multiple incoming gateways for a
particular set of messages, each to a different newsgroup(s), each particular set of messages, each to a different newsgroup(s), each
one SHOULD generate a message identifier unique to that gateway. one SHOULD generate a message identifier unique to that gateway.
Each incoming gateway nonetheless MUST ensure that it does not gate Each incoming gateway nonetheless MUST ensure that it does not gate
the same message twice. the same message twice.
NOTE: Consider the example of two gateways of a given mailing list NOTE: Consider the example of two gateways of a given mailing list
into two separate Usenet newsgroups, both of which preserve the into two separate Usenet newsgroups, both of which preserve the
email message identifier. Each newsgroup may then receive a email message identifier. Each newsgroup may then receive a
portion of the messages (different sites seeing different portion of the messages (different sites seeing different
portions). In these cases, where there is no one "official" portions). In these cases, where there is no one "official"
gateway, some other method of generating message identifiers has gateway, some other method of generating message identifiers has
to be used to avoid collisions. It would obviously be preferable to be used to avoid collisions. It would obviously be preferable
for there to be only one gateway which crossposts, but this may for there to be only one gateway that crossposts, but this may not
not be possible to coordinate. be possible to coordinate.
If no date information is available, the gateway MAY supply a Date If no date information is available, the gateway MAY supply a Date
header field with the gateway's current date. If only partial header field with the gateway's current date. If only partial
information is available (such as date but not time), this SHOULD be information is available (such as date but not time), this SHOULD be
fleshed out to a full Date by adding default values rather than fleshed out to a full Date by adding default values rather than by
discarding this information. Only in very exceptional circumstances discarding this information. Only in very exceptional circumstances
should Date information be discarded, as it plays an important role should Date information be discarded, as it plays an important role
in preventing reinjection of old messages. in preventing reinjection of old messages.
An incoming gateway MUST add a Sender header field to the news An incoming gateway MUST add a Sender header field to the news
article it forms containing the <mailbox> of the administrator of the article it forms by containing the <mailbox> of the administrator of
gateway. Problems with the gateway may be reported to this the gateway. Problems with the gateway may be reported to this
<mailbox>. The <display-name> portion of this <mailbox> SHOULD <mailbox>. The <display-name> portion of this <mailbox> SHOULD
indicate that the entity responsible for injection of the message is indicate that the entity responsible for injection of the message is
a gateway. If the original message already had a Sender header a gateway. If the original message already had a Sender header
field, it SHOULD be renamed to Original-Sender so that its contents field, it SHOULD be renamed to Original-Sender so that its contents
can be preserved. See Section 3.10.3 for the specification of that can be preserved. See Section 3.10.3 for the specification of that
header field. header field.
3.10.3. Original-Sender header field 3.10.3. Original-Sender Header Field
The Original-Sender header field holds the content of a Sender header The Original-Sender header field holds the content of a Sender header
field in an original message received by an incoming gateway, field in an original message received by an incoming gateway,
preserving it while the incoming gateway adds its own Sender header preserving it while the incoming gateway adds its own Sender header
field. The content syntax makes use of syntax defined in [USEFOR] field. The content syntax makes use of syntax defined in [RFC5536]
and [RFC2822]. and [RFC5322].
RFC 5537 Netnews Architecture and Protocols November 2009
header =/ Original-Sender-header header =/ Original-Sender-header
Original-Sender-header Original-Sender-header
= "Original-Sender" ":" SP = "Original-Sender" ":" SP
Original-Sender-content Original-Sender-content
Original-Sender-content Original-Sender-content
= mailbox = mailbox
The Permanent Message Header Field Repository entry for this header The Permanent Message Header Field Repository entry for this header
field is: field is:
Header field name: Original-Sender Header field name: Original-Sender
Applicable protocol: Netnews Applicable protocol: Netnews
Status: standard Status: standard
Author/Change controller: IETF Author/Change controller: IETF
Specification document(s): RFCXXXX Specification document(s): RFC 5537
3.10.4. Gateway Example 3.10.4. Gateway Example
To illustrate the type of precautions that should be taken against To illustrate the type of precautions that should be taken against
loops, here is an example of the measures taken by one particular loops, here is an example of the measures taken by one particular
combination of mail-to-news and news-to-mail gateways designed to combination of mail-to-news and news-to-mail gateways designed to
handle bidirectional gatewaying between mailing lists and unmoderated handle bidirectional gatewaying between mailing lists and unmoderated
groups: groups:
1. The news-to-mail gateway preserves the message identifier of the 1. The news-to-mail gateway preserves the message identifier of the
news article in the generated email message. The mail-to-news news article in the generated email message. The mail-to-news
gateway likewise preserves the email message identifier provided gateway likewise preserves the email message identifier, provided
that it is syntactically valid for Netnews. This allows the news that it is syntactically valid for Netnews. This allows the news
system's built-in suppression of duplicates to serve as the first system's built-in suppression of duplicates to serve as the first
line of defense against loops. line of defense against loops.
2. The news-to-mail gateway adds an X-* header field to all messages 2. The news-to-mail gateway adds an X-* header field to all messages
it generates. The mail-to-news gateway discards any incoming it generates. The mail-to-news gateway discards any incoming
messages containing this header field. This is robust against messages containing this header field. This is robust against
mailing list managers that replace the message identifier, and mailing list managers that replace the message identifier and
against any number of email hops, provided that the other message against any number of email hops, provided that the other message
header fields are preserved. header fields are preserved.
3. The mail-to-news gateway prepends the host name from which it 3. The mail-to-news gateway prepends the host name from which it
received the email message to the content of the Path header received the email message to the content of the Path header
field. The news-to-mail gateway refuses to gateway any message field. The news-to-mail gateway refuses to gateway any message
that contains the list server name in its Path header field that contains the list server name in its Path header field
(including in the tail section). This is robust against any (including in the tail section). This is robust against any
amount of munging of the message header fields by the mailing amount of munging of the message header fields by the mailing
list, provided that the email only goes through one hop. list, provided that the email only goes through one hop.
RFC 5537 Netnews Architecture and Protocols November 2009
4. The mail-to-news gateway is designed never to generate bounces to 4. The mail-to-news gateway is designed never to generate bounces to
the envelope sender. Instead, articles that are rejected by the the envelope sender. Instead, articles that are rejected by the
news server (for reasons not warranting silent discarding of the news server (for reasons not warranting silent discarding of the
message) result in a bounce message sent to an errors address message) result in a bounce message sent to an errors address
known not to forward to any mailing lists, so that they can be that is known not to forward to any mailing lists. In this way,
handled by the news administrators. they can be handled by the news administrators.
These precautions have proven effective in practice at preventing These precautions have proven effective in practice at preventing
loops for this particular application (bidirectional gatewaying loops for this particular application (bidirectional gatewaying
between mailing lists and locally distributed newsgroups where both between mailing lists and locally distributed newsgroups where both
gateways can be designed together). General gatewaying to world-wide gateways can be designed together). General gatewaying to world-wide
newsgroups poses additional difficulties; one must be very wary of newsgroups poses additional difficulties; one must be very wary of
strange configurations, such as a newsgroup gated to a mailing list strange configurations, such as a newsgroup gated to a mailing list
which is in turn gated to a different newsgroup. that is in turn gated to a different newsgroup.
4. Media Types 4. Media Types
This document defines several media types, which shall be registered This document defines several media types, which have been registered
with IANA as provided for in [RFC4288]. with IANA as provided for in [RFC4288].
The media type message/news, as previously registered with IANA, is The media type message/news, as previously registered with IANA, is
hereby declared obsolete. It was never widely implemented, and its hereby declared obsolete. The intent of this media type was to
define a standard way of transmitting news articles via mail for
human reading. However, it was never widely implemented, and its
default treatment as application/octet-stream by agents that did not default treatment as application/octet-stream by agents that did not
recognize it was counter-productive. The media type message/rfc822 recognize it was counter-productive. The media type message/rfc822
(defined in [RFC2046], section 5.2.1) SHOULD be used in its place. (defined in Section 5.2.1 of [RFC2046]) SHOULD be used in its place.
The updated MIME media type definition of message/news is: The updated MIME media type definition of message/news is:
MIME type name: message MIME type name: message
MIME subtype name: news
Required parameters: none MIME subtype name: news
Optional parameters: charset, compare message/rfc822
Encoding considerations: compare message/rfc822 (RFC 2046) Required parameters: none
Security considerations: OBSOLETE, use message/rfc822.
Interoperability considerations: Optional parameters: none
Rarely used; and therefore often
handled as application/octet-stream. Encoding considerations: same as message/rfc822
Disposition should by default be inline.
Published specification: [SON-OF-1036], RFCXXXX Security considerations: News articles may constitute "control
Applications that use this media type: messages", which can have effects on a
Some old mail and news user agents. host's news system beyond just addition
Intended usage: OBSOLETE of information. Since control messages
Author: Henry Spencer may occur in normal news flow, most hosts
Change controller: IETF are suitably defended against undesired
effects already, but transmission of news
articles via mail may bypass
RFC 5537 Netnews Architecture and Protocols November 2009
firewall-type defenses. Reading a news
article transmitted by mail involves no
hazards beyond those of mail, but
submitting it to news software for
processing should be done with care.
Interoperability considerations:
Rarely used, and therefore often
handled as application/octet-stream.
Disposition should by default be inline.
Published specification: RFC 5537
Applications that use this media type:
Some old mail and news user agents.
Intended usage: OBSOLETE
Author: Henry Spencer
Change controller: IETF
4.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 encapsulation of complete news articles where the intention is that
the recipient should then inject them into Netnews. This application the recipient should then inject them into Netnews. This application
type provides one of the methods for mailing articles to moderators type provides one of the methods for mailing articles to moderators
(see Section 3.5.1) and may be used to convey messages to an (see Section 3.5.1) and may be used to convey messages to an
injecting agent. This encapsulation removes the need to transform an injecting agent. This encapsulation removes the need to transform an
email message into a Netnews proto-article and provides a way to send 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 a Netnews article using MIME through a transport medium that does not
support 8bit data. support 8bit data.
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 type name: application
MIME subtype name: news-transmission
Required parameters: none MIME subtype name: news-transmission
Optional parameters: One and only one of "usage=moderate",
"usage=inject", or "usage=relay". Required parameters: none
Encoding considerations: A transfer-encoding different from that
of the article transmitted MAY be Optional parameters: One and only one of "usage=moderate",
supplied to ensure correct transmission "usage=inject", or "usage=relay".
over some 7bit transport medium.
Security considerations: A news article may be a control message, RFC 5537 Netnews Architecture and Protocols November 2009
which if processed could have effects on
the recipient host's system beyond just Encoding considerations: A transfer-encoding different from that
storage of the article. of the article transmitted MAY be
Published specification: RFCXXXX supplied to ensure correct transmission
Body part: A complete proto-article ready for over some 7bit transport medium.
injection into Netnews or an article
being relayed to another agent. Security considerations: News articles may constitute "control
Applications that use this media type: messages", which can have effects on a
Injecting agents, Netnews moderators. host's news system beyond just addition
Intended usage: COMMON of information. Since control messages
Change controller: IETF may occur in normal news flow, most hosts
are suitably defended against undesired
effects already, but transmission of news
articles via mail may bypass
firewall-type defenses.
Published specification: RFC 5537
Body part: A complete proto-article ready for
injection into Netnews or an article
being relayed to another agent.
Applications that use this media type:
Injecting agents, Netnews moderators.
Intended usage: COMMON
Change controller: IETF
usage=moderate indicates the article is intended for a moderator, usage=moderate indicates the article is intended for a moderator,
usage=inject for an injecting agent, and usage=relay for a relaying usage=inject for an injecting agent, and usage=relay for a relaying
agent. The entity receiving the article may only implement one type agent. The entity receiving the article may only implement one type
of agent, in which case the parameter MAY be omitted. of agent, in which case the parameter MAY be omitted.
Contrary to the prior registration of this media type, article Contrary to the prior registration of this media type, article
batches are not permitted as a body part. Multiple messages or a batches are not permitted as a body part. Multiple messages or a
message with multiple application/news-transmission parts may be used message with multiple application/news-transmission parts may be used
instead. instead.
4.2. application/news-groupinfo 4.2. application/news-groupinfo
The application/news-groupinfo media type is used in conjunction with The application/news-groupinfo media type is used in conjunction with
the newgroup control message (see Section 5.2.1). Its body part the newgroup control message (see Section 5.2.1). Its body part
contains brief information about a newsgroup: the newsgroup name, its contains brief information about a newsgroup: the newsgroup name, its
description, and its moderation status. description, and its moderation status.
The MIME media type definition of application/news-groupinfo is: The MIME media type definition of application/news-groupinfo is:
RFC 5537 Netnews Architecture and Protocols November 2009
MIME type name: application MIME type name: application
MIME subtype name: news-groupinfo MIME subtype name: news-groupinfo
Required parameters: none Required parameters: none
Optional parameters: charset, which MUST be a charset Optional parameters: charset, which MUST be a charset
registered for use with MIME text types registered for use with MIME text types.
and has the same syntax as the parameter It has the same syntax as the parameter
defined for text/plain [RFC2046]. defined for text/plain [RFC2046].
Specifies the charset of the body part. Specifies the charset of the body part.
If not given, the charset defaults to If not given, the charset defaults to
US-ASCII [ASCII]. US-ASCII [ASCII].
Encoding considerations: 7bit or 8bit MUST be used to maintain
compatibility. Encoding considerations: 7bit or 8bit encoding MUST be used to
maintain compatibility.
Security considerations: None. Security considerations: None.
Interoperability considerations: Interoperability considerations:
Disposition should by default be inline. Disposition should by default be inline.
Applications that use this media type: Applications that use this media type:
Control message issuers, relaying Control message issuers, relaying
agents, serving agents. agents, serving agents.
Published specification: RFCXXXX
Published specification: RFC 5537
Intended usage: COMMON Intended usage: COMMON
Change controller: IETF Change controller: IETF
The content of the application/news-groupinfo body part is defined The content of the application/news-groupinfo body part is defined
as: as:
groupinfo-body = [ newsgroups-tag CRLF ] groupinfo-body = [ newsgroups-tag CRLF ]
newsgroups-line CRLF newsgroups-line CRLF
newsgroups-tag = %x46.6F.72 SP %x79.6F.75.72 SP newsgroups-tag = %x46.6F.72 SP %x79.6F.75.72 SP
%x6E.65.77.73.67.72.6F.75.70.73 SP %x6E.65.77.73.67.72.6F.75.70.73 SP
%x66.69.6C.65.3A %x66.69.6C.65.3A
skipping to change at page 34, line 45 skipping to change at page 33, line 4
%x6E.65.77.73.67.72.6F.75.70.73 SP %x6E.65.77.73.67.72.6F.75.70.73 SP
%x66.69.6C.65.3A %x66.69.6C.65.3A
; case sensitive ; case sensitive
; "For your newsgroups file:" ; "For your newsgroups file:"
newsgroups-line = newsgroup-name newsgroups-line = newsgroup-name
[ 1*HTAB newsgroup-description ] [ 1*HTAB newsgroup-description ]
[ *WSP moderation-flag ] [ *WSP moderation-flag ]
newsgroup-description newsgroup-description
= eightbit-utext *( *WSP eightbit-utext ) = eightbit-utext *( *WSP eightbit-utext )
moderation-flag = SP "(" %x4D.6F.64.65.72.61.74.65.64 ")" moderation-flag = SP "(" %x4D.6F.64.65.72.61.74.65.64 ")"
RFC 5537 Netnews Architecture and Protocols November 2009
; SPACE + case sensitive "(Moderated)" ; SPACE + case sensitive "(Moderated)"
eightbit-utext = utext / %d127-255 eightbit-utext = VCHAR / %d127-255
This unusual format is backward-compatible with the scanning of the This unusual format is backward-compatible with the scanning of the
body of newgroup control messages for descriptions done by Netnews body of newgroup control messages for descriptions done by Netnews
implementations that predate this specification. Although optional, implementations that predate this specification. Although optional,
the <newsgroups-tag> SHOULD be included for backward compatibility. the <newsgroups-tag> SHOULD be included for backward compatibility.
The <newsgroup-description> MUST NOT contain any occurrence of the The <newsgroup-description> MUST NOT contain any occurrence of the
string "(Moderated)" within it. Moderated newsgroups MUST be marked string "(Moderated)" within it. Moderated newsgroups MUST be marked
by appending the case sensitive text " (Moderated)" at the end. by appending the case-sensitive text " (Moderated)" at the end.
While a charset parameter is defined for this media type, most While a charset parameter is defined for this media type, most
existing software does not understand MIME header fields or correctly existing software does not understand MIME header fields or correctly
handle descriptions in a variety of charsets. Using a charset of US- handle descriptions in a variety of charsets. Using a charset of US-
ASCII where possible is therefore RECOMMENDED; if not possible, UTF-8 ASCII where possible is therefore RECOMMENDED; if not possible, UTF-8
[RFC3629] SHOULD be used. Regardless of the charset used, the [RFC3629] SHOULD be used. Regardless of the charset used, the
constraints of the above grammar MUST be met and the <newsgroup-name> constraints of the above grammar MUST be met and the <newsgroup-name>
MUST be represented in that charset using the same octets as would be MUST be represented in that charset using the same octets as would be
used with a charset of US-ASCII. used with a charset of US-ASCII.
skipping to change at page 36, line 8 skipping to change at page 33, line 38
4.3. application/news-checkgroups 4.3. application/news-checkgroups
The application/news-checkgroups media type contains a list of The application/news-checkgroups media type contains a list of
newsgroups within a hierarchy or hierarchies, including their newsgroups within a hierarchy or hierarchies, including their
descriptions and moderation status. It is primarily for use with the descriptions and moderation status. It is primarily for use with the
checkgroups control message (see Section 5.2.3). checkgroups control message (see Section 5.2.3).
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 type name: application
MIME subtype name: news-checkgroups MIME subtype name: news-checkgroups
Required parameters: none Required parameters: none
Optional parameters: charset, which MUST be a charset Optional parameters: charset, which MUST be a charset
registered for use with MIME text types registered for use with MIME text types.
and has the same syntax as the parameter It has the same syntax as the parameter
defined for text/plain [RFC2046]. defined for text/plain [RFC2046].
Specifies the charset of the body part. Specifies the charset of the body part.
If not given, the charset defaults to If not given, the charset defaults to
US-ASCII [ASCII]. US-ASCII [ASCII].
Encoding considerations: 7bit or 8bit MUST be used to maintain
compatibility. Encoding considerations: 7bit or 8bit encoding MUST be used to
maintain compatibility.
RFC 5537 Netnews Architecture and Protocols November 2009
Security considerations: This media type provides only a means Security considerations: This media type provides only a means
for conveying a list of newsgroups and for conveying a list of newsgroups and
does not provide any information does not provide any information
indicating whether the sender is indicating whether the sender is
authorized to state which newsgroups authorized to state which newsgroups
should exist within a hierarchy. Such should exist within a hierarchy. Such
authorization must be accomplished by authorization must be accomplished by
other means. other means.
Interoperability considerations: Interoperability considerations:
Disposition should by default be inline. Disposition should by default be inline.
Applications that use this media type: Applications that use this media type:
Control message issuers, relaying Control message issuers, relaying
agents, serving agents. agents, serving agents.
Published specification: RFCXXXX
Published specification: RFC 5537
Intended usage: COMMON Intended usage: COMMON
Change controller: IETF Change controller: IETF
The content of the application/news-groupinfo body part is defined The content of the application/news-checkgroups body part is defined
as: as:
checkgroups-body = *( valid-group CRLF ) checkgroups-body = *( valid-group CRLF )
valid-group = newsgroups-line ; see 4.2 valid-group = newsgroups-line ; see Section 4.2
The same restrictions on charset, <newsgroup-name>, and <newsgroup- The same restrictions on charset, <newsgroup-name>, and <newsgroup-
description> apply for this media type as for application/ description> apply for this media type as for application/
news-groupinfo. news-groupinfo.
One application/news-checkgroups message may contain information for One application/news-checkgroups message may contain information for
one or more hierarchies and is considered complete for any hierarchy one or more hierarchies and is considered complete for any hierarchy
for which it contains a <valid-group> unless accompanied by external for which it contains a <valid-group> unless accompanied by external
information limiting its scope (such as a <chkscope> parameter to a information limiting its scope (such as a <chkscope> parameter to a
checkgroups control message as described in Section 5.2.3). In other checkgroups control message, as described in Section 5.2.3). In
words, an application/news-checkgroups body part consisting of: other words, an application/news-checkgroups body part consisting of
example.moderated A moderated newsgroup (Moderated) example.moderated A moderated newsgroup (Moderated)
example.test An unmoderated test group example.test An unmoderated test group
is a statement that the example.* hierarchy contains two newsgroups, is a statement that the example.* hierarchy contains two newsgroups,
example.moderated and example.test, and no others. This media type example.moderated and example.test, and no others. This media type
therefore MUST NOT be used for conveying partial information about a therefore MUST NOT be used for conveying partial information about a
hierarchy; if a group from a given hierarchy is present, all groups hierarchy; if a group from a given hierarchy is present, all groups
RFC 5537 Netnews Architecture and Protocols November 2009
that exist in that hierarchy MUST be listed unless its scope is that exist in that hierarchy MUST be listed unless its scope is
limited by external information, in which case all groups SHOULD be limited by external information, in which case all groups SHOULD be
listed. listed.
Spaces are used in this example for formatting reasons. In an actual
message, the newsgroup name and description MUST be separated by one
or more tabs (HTAB, ASCII %d09), not spaces.
5. Control Messages 5. Control Messages
A control message is an article which contains a Control header field A control message is an article that contains a Control header field
and thereby indicates that some action should be taken by an agent and thereby indicates that some action should be taken by an agent
other than distribution and display. Any article containing a other than distribution and display. Any article containing a
Control header field (defined in Section 3.2.3 of [USEFOR]) is a Control header field (defined in Section 3.2.3 of [RFC5536]) is a
control message. Additionally, the action of an article containing a control message. Additionally, the action of an article containing a
Supersedes header field is described here; while such an article is Supersedes header field is described here; while such an article is
not a control message, it specifies an action similar to the cancel not a control message, it specifies an action similar to the cancel
control message. control message.
The <control-command> of a Control header field comprises a <verb>, The <control-command> of a Control header field comprises a <verb>,
which indicates the action to be taken, and one or more <argument> which indicates the action to be taken, and one or more <argument>
values, which supply the details. For some control messages, the values, which supply the details. For some control messages, the
body of the article is also significant. Each recognized <verb> (the body of the article is also significant. Each recognized <verb> (the
control message type) is described in a separate section below. control message type) is described in a separate section below.
Agents MAY accept other control message types than those specified Agents MAY accept other control message types than those specified
below, and MUST either ignore or reject control messages with below, and MUST either ignore or reject control messages with
unrecognized types. Syntactic definitions of valid <argument> values unrecognized types. Syntactic definitions of valid <argument> values
and restrictions on control message bodies are given in the section and restrictions on control message bodies are given in the section
for each control message type. for each control message type.
Contrary to [RFC1036], the presence of a Subject header field Contrary to [RFC1036], the presence of a Subject header field
starting with the string "cmsg " MUST NOT cause an article to be starting with the string "cmsg " MUST NOT cause an article to be
interpreted as a control message. Agents MAY reject an article with interpreted as a control message. Agents MAY reject an article that
no Control header field and such a Subject header field as ambiguous. has such a Subject header field and no Control header field as
Likewise, the presence of a <newsgroup-name> ending in ".ctl" in the ambiguous. Likewise, the presence of a <newsgroup-name> ending in
Newsgroups header field or the presence of an Also-Control header ".ctl" in the Newsgroups header field or the presence of an Also-
field MUST NOT cause the article to be interpreted as a control Control header field MUST NOT cause the article to be interpreted as
message. a control message.
5.1. Authentication and Authorization 5.1. Authentication and Authorization
Control messages specify actions above and beyond the normal Control messages specify actions above and beyond the normal
processing of an article and are therefore potential vectors of abuse processing of an article and are therefore potential vectors of abuse
and unauthorized action. There is, at present, no standardized means and unauthorized action. There is, at present, no standardized means
of authenticating the sender of a control message or verifying that of authenticating the sender of a control message or verifying that
the contents of a control message were sent by the claimed sender. the contents of a control message were sent by the claimed sender.
There are, however, some unstandardized authentication mechanisms in There are, however, some unstandardized authentication mechanisms in
common use, such as [PGPVERIFY]. common use, such as [PGPVERIFY].
RFC 5537 Netnews Architecture and Protocols November 2009
Agents acting on control messages SHOULD take steps to authenticate Agents acting on control messages SHOULD take steps to authenticate
control messages before acting on them, as determined by local control messages before acting on them, as determined by local
authorization policy. Whether this is done via the use of an authorization policy. Whether this is done via the use of an
unstandardized authentication protocol, by comparison with unstandardized authentication protocol, by comparison with
information obtained through another protocol, by human review, or by information obtained through another protocol, by human review, or by
some other means is left unspecified by this document. Further some other means is left unspecified by this document. Further
extensions or revisions of this protocol are expected to standardize extensions or revisions of this protocol are expected to standardize
a digital signature mechanism. a digital signature mechanism.
Agents are expected to have their own local authorization policies Agents are expected to have their own local authorization policies
skipping to change at page 39, line 22 skipping to change at page 36, line 32
5.2. Group Control Messages 5.2. Group Control Messages
A group control message is any control message type that requests A group control message is any control message type that requests
some update to the list of newsgroups known to a news server. The some update to the list of newsgroups known to a news server. The
standard group control message types are "newgroup", "rmgroup", and standard group control message types are "newgroup", "rmgroup", and
"checkgroups". "checkgroups".
Before honoring any group control message, an agent MUST check the Before honoring any group control message, an agent MUST check the
newsgroup or newsgroups affected by that control message and decline newsgroup or newsgroups affected by that control message and decline
to create any newsgroups not in conformance with the restrictions in to create any newsgroups not in conformance with the restrictions in
Section 3.1.4 of [USEFOR]. Section 3.1.4 of [RFC5536].
All of the group control messages MUST have an Approved header field All of the group control messages MUST have an Approved header field
(Section 3.2.1 of [USEFOR]). Group control messages without an (Section 3.2.1 of [RFC5536]). Group control messages without an
Approved header field SHOULD NOT be honored. Approved header field SHOULD NOT be honored.
Group control messages affecting specific groups (newgroup and Group control messages affecting specific groups (newgroup and
rmgroup control messages, for example) SHOULD include the <newsgroup- rmgroup control messages, for example) SHOULD include the <newsgroup-
name> for the group or groups affected in their Newsgroups header name> for the group or groups affected in their Newsgroups header
field. Other newsgroups MAY be included in the Newsgroups header field. Other newsgroups MAY be included in the Newsgroups header
field so that the control message will reach more news servers, but field so that the control message will reach more news servers, but
due to the special relaying rules for group control messages (see due to the special relaying rules for group control messages (see
Section 3.6) this is normally unnecessary and may be excessive. Section 3.6) this is normally unnecessary and may be excessive.
5.2.1. The newgroup Control Message 5.2.1. The newgroup Control Message
The newgroup control message requests the specified group be created The newgroup control message requests that the specified group be
or, if already existing, have its moderation status or description created or, if already existing, that its moderation status or
changed. The syntax of its Control header field is: description be changed. The syntax of its Control header field is:
control-command =/ Newgroup-command control-command =/ Newgroup-command
Newgroup-command = "newgroup" Newgroup-arguments Newgroup-command = "newgroup" Newgroup-arguments
Newgroup-arguments = 1*WSP newsgroup-name Newgroup-arguments = 1*WSP newsgroup-name
RFC 5537 Netnews Architecture and Protocols November 2009
[ 1*WSP newgroup-flag ] [ 1*WSP newgroup-flag ]
newgroup-flag = "moderated" newgroup-flag = "moderated"
If the request is honored, the moderation status of the group SHOULD If the request is honored, the moderation status of the group SHOULD
be set in accordance with the presence or absence of the <newgroup- be set in accordance with the presence or absence of the <newgroup-
flag> "moderated". "moderated" is the only flag defined by this flag> "moderated". "moderated" is the only flag defined by this
protocol. Other flags MAY be defined by extensions to this protocol protocol. Other flags MAY be defined by extensions to this protocol
and accepted by agents. If an agent does not recognize the and accepted by agents. If an agent does not recognize the
<newgroup-flag> of a newgroup control message, it SHOULD ignore that <newgroup-flag> of a newgroup control message, it SHOULD ignore that
control message. control message.
skipping to change at page 41, line 21 skipping to change at page 38, line 5
Newsgroups: example.admin.info Newsgroups: example.admin.info
Date: 27 Feb 2002 12:50:22 +0200 Date: 27 Feb 2002 12:50:22 +0200
Subject: cmsg newgroup example.admin.info moderated Subject: cmsg newgroup example.admin.info moderated
Approved: admin@noc.example Approved: admin@noc.example
Control: newgroup example.admin.info moderated Control: newgroup example.admin.info moderated
Message-ID: <ng-example.admin.info-20020227@noc.example> Message-ID: <ng-example.admin.info-20020227@noc.example>
MIME-Version: 1.0 MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="nxtprt" Content-Type: multipart/mixed; boundary="nxtprt"
Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit
RFC 5537 Netnews Architecture and Protocols November 2009
This is a MIME control message. This is a MIME control message.
--nxtprt --nxtprt
Content-Type: application/news-groupinfo; charset=us-ascii Content-Type: application/news-groupinfo; charset=us-ascii
For your newsgroups file: For your newsgroups file:
example.admin.info About the example.* groups (Moderated) example.admin.info About the example.* groups (Moderated)
--nxtprt --nxtprt
Content-Type: text/plain; charset=us-ascii Content-Type: text/plain; charset=us-ascii
A moderated newsgroup for announcements about new newsgroups in A moderated newsgroup for announcements about new newsgroups in
the example.* hierarchy. the example.* hierarchy.
--nxtprt-- --nxtprt--
Spaces are used in this example for formatting reasons. In an actual
message, the newsgroup name and description MUST be separated by one
or more tabs (HTAB, ASCII %d09), not spaces.
5.2.2. The rmgroup Control Message 5.2.2. The rmgroup Control Message
The rmgroup control message requests the specified group be removed The rmgroup control message requests that the specified group be
from a news server's list of valid groups. The syntax of its Control removed from a news server's list of valid groups. The syntax of its
header field is: Control header field is:
control-command =/ Rmgroup-command control-command =/ Rmgroup-command
Rmgroup-command = "rmgroup" Rmgroup-arguments Rmgroup-command = "rmgroup" Rmgroup-arguments
Rmgroup-arguments = 1*WSP newsgroup-name Rmgroup-arguments = 1*WSP newsgroup-name
The body of the control message MAY contain anything, usually an The body of the control message MAY contain anything, usually an
explanatory text. explanatory text.
5.2.3. The checkgroups Control Message 5.2.3. The checkgroups Control Message
The checkgroups control message contains a list of all the valid The checkgroups control message contains a list of all the valid
groups in a hierarchy with descriptions and moderation status. It groups in a hierarchy with descriptions and moderation status. It
requests a news server update its valid newsgroup list for that requests that a news server update its valid newsgroup list for that
hierarchy to include the groups specified, remove any groups not hierarchy to include the groups specified, remove any groups not
specified, and update group descriptions to match those given in the specified, and update group descriptions and moderation status to
checkgroups control message. The syntax of its Control header field match those given in the checkgroups control message. The syntax of
is: its Control header field is:
control-command =/ Checkgroup-command control-command =/ Checkgroup-command
Checkgroup-command = "checkgroups" Checkgroup-arguments Checkgroup-command = "checkgroups" Checkgroup-arguments
Checkgroup-arguments= [ chkscope ] [ chksernr ] Checkgroup-arguments= [ chkscope ] [ chksernr ]
chkscope = 1*( 1*WSP ["!"] newsgroup-name ) chkscope = 1*( 1*WSP ["!"] newsgroup-name )
chksernr = 1*WSP "#" 1*DIGIT chksernr = 1*WSP "#" 1*DIGIT
RFC 5537 Netnews Architecture and Protocols November 2009
A checkgroups message is interpreted as an exhaustive list of the A checkgroups message is interpreted as an exhaustive list of the
valid groups in all hierarchies or sub-hierarchies with a prefix valid groups in all hierarchies or sub-hierarchies with a prefix
listed in the <chkscope> argument, excluding any sub-hierarchy where listed in the <chkscope> argument, excluding any sub-hierarchy where
the <chkscope> argument is prefixed by "!". If no <chkscope> the <chkscope> argument is prefixed by "!". For complex cases with
argument is given, it applies to all hierarchies for which group multiple <chkscope> arguments, start from an empty list of groups,
statements appear in the body of the message. Since much existing include all groups in the checkgroups control message matching
software does not honor the <chkscope> argument, the body of the <chkscope> arguments without a "!" prefix, and then exclude all
checkgroups control message MUST NOT contain group statements for groups matching <chkscope> arguments with a "!" prefix. Follow this
newsgroups outside the intended scope and SHOULD contain a correct method regardless of the order of the <chkscope> arguments in the
newsgroup list even for sub-hierarchies excluded with "!" <chkscope> Control header field.
terms. News servers, however, MUST honor <chkscope> as specified
here. 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 The <chksernr> argument may be any positive integer. If present, it
MUST increase with every change to the newsgroup list, MUST NOT ever MUST increase with every change to the newsgroup list, MUST NOT ever
decrease, and MUST be included in all subsequent checkgroups control decrease, and MUST be included in all subsequent checkgroups control
messages with the same scope. If provided, news servers SHOULD messages with the same scope. If provided, news servers SHOULD
remember the <chksernr> value of the previous checkgroups control remember the <chksernr> value of the previous checkgroups control
message honored for a particular hierarchy or sub-hierarchy and message honored for a particular hierarchy or sub-hierarchy and
decline to honor any subsequent checkgroups control message for the decline to honor any subsequent checkgroups control message for the
same hierarchy or sub-hierarchy with a smaller <chksernr> value or same hierarchy or sub-hierarchy with a smaller <chksernr> value or
with no <chksernr> value. with no <chksernr> value.
There is no upper limit on the length of <chksernr> other than the There is no upper limit on the length of <chksernr>, other than the
limitation on the length of header fields. Implementations may limitation on the length of header fields. Implementations may
therefore want to do comparisons by zero-padding the shorter of two therefore want to do comparisons by zero-padding the shorter of two
<chksernr> values on the left and then doing a string comparison <chksernr> values on the left and then doing a string comparison,
rather than assuming <chksernr> can be manipulated as a number. rather than assuming <chksernr> can be manipulated as a number.
For example, the following Control header field For example, the following Control header field
Control: checkgroups de !de.alt #2009021301 Control: checkgroups de !de.alt #2009021301
indicates the body of the message will list every newsgroup in the indicates that the body of the message will list every newsgroup in
de.* hierarchy, excepting the de.alt.* sub-hierarchy, and should not the de.* hierarchy, excepting the de.alt.* sub-hierarchy, and should
be honored if a checkgroups control message with a serial number not be honored if a checkgroups control message with a serial number
greater than 2009021301 was previously honored. The serial number in greater than 2009021301 was previously honored. The serial number in
this example was formed from the date in YYYYMMDD format followed by this example was formed from the date in YYYYMMDD format, followed by
a two-digit sequence number within that date. a two-digit sequence number within that date.
RFC 5537 Netnews Architecture and Protocols November 2009
The body of the message is an entity of type application/ The body of the message is an entity of type application/
news-checkgroups. It SHOULD be declared as such with appropriate news-checkgroups. It SHOULD be declared as such with appropriate
MIME headers, but news servers SHOULD interpret checkgroups messages MIME headers, but news servers SHOULD interpret checkgroups messages
that lack the appropriate MIME headers as if the body were of type that lack the appropriate MIME headers as if the body were of type
application/news-checkgroups for backward compatibility. application/news-checkgroups for backward compatibility.
5.3. The cancel Control Message 5.3. The cancel Control Message
The cancel control message requests that a target article be The cancel control message requests that a target article be
withdrawn from circulation and access. The syntax of its Control withdrawn from circulation and access. The syntax of its Control
skipping to change at page 44, line 10 skipping to change at page 41, line 4
Contrary to [RFC1036], cancel control messages are not required to Contrary to [RFC1036], cancel control messages are not required to
contain From and Sender header fields matching the target message. contain From and Sender header fields matching the target message.
This requirement only encouraged cancel issuers to conceal their This requirement only encouraged cancel issuers to conceal their
identity and provided no security. identity and provided no security.
5.4. The Supersedes Header Field 5.4. The Supersedes Header Field
The presence of a Supersedes header field in an article requests that The presence of a Supersedes header field in an article requests that
the message identifier given in that header field be withdrawn in the message identifier given in that header field be withdrawn in
exactly the same manner as if it were the target of a cancel control exactly the same manner as if it were the target of a cancel control
RFC 5537 Netnews Architecture and Protocols November 2009
message. Accordingly, news servers SHOULD apply to a Supersedes message. Accordingly, news servers SHOULD apply to a Supersedes
header field the same authentication and authorization checks as they header field the same authentication and authorization checks as they
would apply to cancel control messages. If the Supersedes header would apply to cancel control messages. If the Supersedes header
field is honored, the news server SHOULD take the same actions as it field is honored, the news server SHOULD take the same actions as it
would take when honoring a cancel control message for the given would take when honoring a cancel control message for the given
target article. target article.
The article containing the Supersedes header field, whether or not The article containing the Supersedes header field, whether or not
the Supersedes header field is honored, SHOULD be handled as a normal the Supersedes header field is honored, SHOULD be handled as a normal
article and SHOULD NOT receive the special treatment of control article and SHOULD NOT receive the special treatment of control
messages described in Section 3.7. messages described in Section 3.7.
5.5. The ihave and sendme Control Messages 5.5. The ihave and sendme Control Messages
The ihave and sendme control messages implement a predecessor of the The ihave and sendme control messages implement a predecessor of the
NNTP [RFC3977] protocol. They are largely obsolete on the Internet NNTP [RFC3977] protocol. They are largely obsolete on the Internet
but still see use in conjunction with some transport protocols such but still see use in conjunction with some transport protocols such
as UUCP. News servers are not required to support them. as UUCP [UUCP]. News servers are not required to support them.
ihave and sendme control messages share similar syntax for their ihave and sendme control messages share similar syntax for their
Control header fields and bodies: Control header fields and bodies:
control-command =/ Ihave-command control-command =/ Ihave-command
Ihave-command = "ihave" Ihave-arguments Ihave-command = "ihave" Ihave-arguments
Ihave-arguments = 1*WSP *( msg-id 1*WSP ) relayer-name Ihave-arguments = 1*WSP *( msg-id 1*WSP ) relayer-name
control-command =/ Sendme-command control-command =/ Sendme-command
Sendme-command = "sendme" Sendme-arguments Sendme-command = "sendme" Sendme-arguments
Sendme-arguments = Ihave-arguments Sendme-arguments = Ihave-arguments
relayer-name = path-identity ; see 3.1.5 of [USEFOR] relayer-name = path-identity ; see 3.1.5 of [RFC5536]
ihave-body = *( msg-id CRLF ) ihave-body = *( msg-id CRLF )
sendme-body = ihave-body sendme-body = ihave-body
The body of the article consists of a list of <msg-id>s, one per The body of the article consists of a list of <msg-id>s, one per
line. The message identifiers SHOULD be put in the body of the line. The message identifiers SHOULD be put in the body of the
article, not in the Control header field, but news servers MAY article, not in the Control header field, but news servers MAY
recognize and process message identifiers in the Control header field recognize and process message identifiers in the Control header field
for backward compatibility. Message identifiers MUST NOT be put in for backward compatibility. Message identifiers MUST NOT be put in
the Control header field if they are present in the body of the the Control header field if they are present in the body of the
control message. control message.
The ihave message states that the named relaying agent has received The ihave message states that the named relaying agent has received
articles with the specified message identifiers, which may be of articles with the specified message identifiers, which may be of
interest to the relaying agents receiving the ihave message. The interest to the relaying agents receiving the ihave message. The
sendme message requests that the agent receiving it send the articles sendme message requests that the agent receiving it send the articles
having the specified message identifiers to the named relaying agent. having the specified message identifiers to the named relaying agent.
Contrary to [RFC1036], the relayer-name MUST be given as the last Contrary to [RFC1036], the relayer-name MUST be given as the last
argument in the Control header field. argument in the Control header field.
RFC 5537 Netnews Architecture and Protocols November 2009
Upon receipt of the sendme message (and a decision to honor it), the Upon receipt of the sendme message (and a decision to honor it), the
receiving agent sends the article or articles requested. The receiving agent sends the article or articles requested. The
mechanism for this transmission is unspecified by this document and mechanism for this transmission is unspecified by this document and
is arranged between the sites involved. is arranged between the sites involved.
These control messages are normally sent as point-to-point articles These control messages are normally sent as point-to-point articles
between two sites and not then sent on to other sites. Newsgroups between two sites and not then sent on to other sites. Newsgroups
beginning with "to." are reserved for such point-to-point beginning with "to." are reserved for such point-to-point
communications and are formed by prepending "to." to a <relayer-name> communications and are formed by prepending "to." to a <relayer-name>
to form a <newsgroup-name>. Articles with such a group in their to form a <newsgroup-name>. Articles with such a group in their
skipping to change at page 46, line 14 skipping to change at page 42, line 39
6. Security Considerations 6. Security Considerations
Netnews is designed for broad dissemination of public messages and Netnews is designed for broad dissemination of public messages and
offers little in the way of security. What protection Netnews has offers little in the way of security. What protection Netnews has
against abuse and impersonation is provided primarily by the against abuse and impersonation is provided primarily by the
underlying transport layer. In large Netnews networks where news underlying transport layer. In large Netnews networks where news
servers cannot be relied upon to enforce authentication and servers cannot be relied upon to enforce authentication and
authorization requirements at the transport layer, articles may be authorization requirements at the transport layer, articles may be
trivially forged and widely read, and the identities of article trivially forged and widely read, and the identities of article
senders and privacy of articles cannot be assured. senders and the privacy of articles cannot be assured.
See Section 5 of [USEFOR] for further security considerations related See Section 5 of [RFC5536] for further security considerations
to the format of articles. related to the format of articles.
6.1. Compromise of System Integrity 6.1. Compromise of System Integrity
Control messages pose a particular security concern since acting on Control messages pose a particular security concern since acting on
unauthorized control messages may cause newsgroups to be removed, unauthorized control messages may cause newsgroups to be removed,
articles to be deleted, and unwanted newsgroups to be created. articles to be deleted, and unwanted newsgroups to be created.
Administrators of news servers SHOULD therefore take steps to verify Administrators of news servers SHOULD therefore take steps to verify
the authenticity of control messages as discussed in Section 5.1. the authenticity of control messages as discussed in Section 5.1.
Articles containing Supersedes header fields are effectively cancel Articles containing Supersedes header fields are effectively cancel
control messages and SHOULD be subject to the same checks as control messages and SHOULD be subject to the same checks as
RFC 5537 Netnews Architecture and Protocols November 2009
discussed in Section 5.4. Currently, many sites are ignoring all discussed in Section 5.4. Currently, many sites are ignoring all
cancel control messages and Supersedes header fields due to the cancel control messages and Supersedes header fields due to the
difficulty of authenticating them and their widespread abuse. difficulty of authenticating them and their widespread abuse.
Cancel control messages are not required to have the same Newsgroups Cancel control messages are not required to have the same Newsgroups
header field as the messages they are cancelling and, since they are header field as the messages they are cancelling. Since they are
sometimes processed before the original message is received, it may sometimes processed before the original message is received, it may
not be possible to check that they do. This allows a malicious not be possible to check that the Newsgroup header fields match.
poster to inject a cancel control message for an article in a This allows a malicious poster to inject a cancel control message for
moderated newsgroup without adding an Approved header field to the an article in a moderated newsgroup without adding an Approved header
control message, and to hide malicious cancel control messages from field to the control message, and to hide malicious cancel control
some reading agents by using a different Newsgroups header field so messages from some reading agents by using a different Newsgroups
that the cancel control message is not accepted by all news servers header field so that the cancel control message is not accepted by
that accepted the original message. all news servers that accepted the original message.
All agents should be aware that all article content, most notably All agents should be aware that all article content, most notably
including the content of the Control header field, is potentially including the content of the Control header field, is potentially
untrusted and malicious. Articles may be constructed in untrustworthy and malicious. Articles may be constructed in
syntactically invalid ways to attempt to overflow internal buffers, syntactically invalid ways to attempt to overflow internal buffers,
violate hidden assumptions, or exploit implementation weaknesses. violate hidden assumptions, or exploit implementation weaknesses.
For example, some news server implementations have been successfully For example, some news server implementations have been successfully
attacked via inclusion of Unix shell code in the Control header attacked via inclusion of Unix shell code in the Control header
field. All article contents, and particularly control message field. All article contents, and particularly control message
contents, SHOULD be handled with care and rigorously verified before contents, SHOULD be handled with care and rigorously verified before
any action is taken on the basis of the contents of the article. any action is taken on the basis of the contents of the article.
A malicious poster may add an Approved header field to bypass the A malicious poster may add an Approved header field to bypass the
moderation process of a moderated newsgroup. Injecting agents SHOULD moderation process of a moderated newsgroup. Injecting agents SHOULD
skipping to change at page 47, line 24 skipping to change at page 44, line 5
A malicious news server participating in a Netnews network may bypass A malicious news server participating in a Netnews network may bypass
checks performed by injecting agents, forge Path header fields and checks performed by injecting agents, forge Path header fields and
other trace information (such as Injection-Info header fields), and other trace information (such as Injection-Info header fields), and
otherwise compromise the authorization requirements of a Netnews otherwise compromise the authorization requirements of a Netnews
network. News servers SHOULD use the facilities of the underlying network. News servers SHOULD use the facilities of the underlying
transport to authenticate their peers and reject articles from transport to authenticate their peers and reject articles from
injecting and relaying agents that do not follow the requirements of injecting and relaying agents that do not follow the requirements of
this protocol or the Netnews network. this protocol or the Netnews network.
RFC 5537 Netnews Architecture and Protocols November 2009
6.2. Denial of Service 6.2. Denial of Service
The proper functioning of individual newsgroups can be disrupted by The proper functioning of individual newsgroups can be disrupted by
the excessive posting of unwanted articles; by the repeated posting the excessive posting of unwanted articles; by the repeated posting
of identical or near identical articles; by posting followups of identical or near identical articles; by posting followups that
unrelated to their precursors or which quote their precursors in full either are unrelated to their precursors or that quote their
with the addition of minimal extra material (especially if this precursors in full with the addition of minimal extra material
process is iterated); by crossposting to, or requesting followups to, (especially if this process is iterated); by crossposting to, or
totally unrelated newsgroups; and by abusing control messages and the requesting followups to, totally unrelated newsgroups; and by abusing
Supersedes header field to delete articles or newsgroups. control messages and the Supersedes header field to delete articles
or newsgroups.
Such articles intended to deny service, or other articles of an Such articles intended to deny service, or other articles of an
inflammatory nature, may also have their From or Reply-To addresses inflammatory nature, may also have their From or Reply-To addresses
set to valid but incorrect email addresses, thus causing large set to valid but incorrect email addresses, thus causing large
volumes of email to descend on the true owners of those addresses. volumes of email to descend on the true owners of those addresses.
Users and agents should always be aware that identifying information Users and agents should always be aware that identifying information
in articles may be forged. in articles may be forged.
A malicious poster may prevent an article from being seen at a A malicious poster may prevent an article from being seen at a
particular site by including in the Path header field of the proto- particular site by including in the Path header field of the proto-
article the <path-identity> of that site. Use of the <diag-keyword> article the <path-identity> of that site. Use of the <diag-keyword>
"POSTED" by injecting agents to mark the point of injection can "POSTED" by injecting agents to mark the point of injection can
prevent this attack. prevent this attack.
Primary responsibility for preventing such attacks lies with Primary responsibility for preventing such attacks lies with
injecting agents, which can apply authentication and authorization injecting agents, which can apply authentication and authorization
checks via the underlying transport and prevent those attempting checks via the underlying transport and prevent those attempting
denial of service attacks from posting messages. If specific denial-of-service attacks from posting messages. If specific
injecting agents fail to live up to their responsibilities, they may injecting agents fail to live up to their responsibilities, they may
be excluded from the Netnews network by configuring relaying agents be excluded from the Netnews network by configuring relaying agents
to reject articles originating from them. to reject articles originating from them.
A malicious complainer may submit a modified copy of an article (with A malicious complainer may submit a modified copy of an article (with
an altered Injection-Info header field, for instance) to the an altered Injection-Info header field, for instance) to the
administrator of an injecting agent in an attempt to discredit the administrator of an injecting agent in an attempt to discredit the
author of that article and even to have his posting privileges author of that article and even to have his posting privileges
removed. Administrators SHOULD therefore obtain a genuine copy of removed. Administrators SHOULD therefore obtain a genuine copy of
the article from their own serving agent before taking action in the article from their own serving agent before taking action in
response to such a complaint. response to such a complaint.
6.3. Leakage 6.3. Leakage
Articles which are intended to have restricted distribution are Articles that are intended to have restricted distribution are
dependent on the goodwill of every site receiving them. Restrictions dependent on the goodwill of every site receiving them. Restrictions
on dissemination and retention of articles may be requested via the on dissemination and retention of articles may be requested via the
Archive and Distribution header fields, but such requests cannot be Archive and Distribution header fields, but such requests cannot be
enforced by the protocol. enforced by the protocol.
RFC 5537 Netnews Architecture and Protocols November 2009
The flooding algorithm used by Netnews transports such as NNTP The flooding algorithm used by Netnews transports such as NNTP
[RFC3977] is extremely good at finding any path by which articles can [RFC3977] is extremely good at finding any path by which articles can
leave a subnet with supposedly restrictive boundaries, and leave a subnet with supposedly restrictive boundaries, and
substantial administrative effort is required to avoid this. substantial administrative effort is required to avoid this.
Organizations wishing to control such leakage are advised to Organizations wishing to control such leakage are advised to
designate a small number of gateways to handle all news exchange with designate a small number of gateways to handle all news exchanges
the outside world. with the outside world.
The sendme control message (Section 5.5), insofar as it is still The sendme control message (Section 5.5), insofar as it is still
used, can be used to request articles the requester should not have used, can be used to request articles that the requester should not
access to. have access to.
7. IANA Considerations 7. IANA Considerations
IANA is requested to register the following media types, described IANA has registered the following media types, described elsewhere in
elsewhere in this document, for use with the Content-Type header this document, for use with the Content-Type header field, in the
field, in the IETF tree in accordance with the procedures set out in IETF tree in accordance with the procedures set out in [RFC4288].
[RFC4288].
application/news-transmission (4.1) application/news-transmission (4.1)
application/news-groupinfo (4.2) application/news-groupinfo (4.2)
application/news-checkgroups (4.3) application/news-checkgroups (4.3)
application/news-transmission is a change to a previous registration. application/news-transmission is a change to a previous registration.
IANA is requested to register the new header field Original-Sender in IANA has registered the new header field, Original-Sender, in the
the Permanent Message Header Field Repository using the template in Permanent Message Header Field Repository, using the template in
Section 3.10.3. Section 3.10.3.
IANA is also requested to change the status of the message/news media IANA has changed the status of the message/news media type to
type to "OBSOLETE". message/rfc822 should be used instead. An "OBSOLETE". message/rfc822 should be used instead. An updated
updated template is included in Section 4. template is included in Section 4.
8. References 8. References
8.1. Normative References 8.1. Normative References
[ASCII] American National Standard for Information Systems, "Coded [ASCII] American National Standard for Information Systems,
Character Sets - 7-Bit American National Standard Code for "Coded Character Sets - 7-Bit American National
Information Interchange (7-Bit ASCII)", ANSI X3.4, 1986. Standard Code for Information Interchange (7-Bit
ASCII)", ANSI X3.4, 1986.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet
Extensions (MIME) Part Two: Media Types", RFC 2046, Mail Extensions (MIME) Part Two: Media Types",
November 1996. RFC 2046, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, RFC 5537 Netnews Architecture and Protocols November 2009
April 2001.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications
Registration Procedures", BCP 13, RFC 4288, December 2005. and Registration Procedures", BCP 13, RFC 4288,
December 2005.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[USEFOR] Murchison, K., Ed., Lindsey, C., and D. Kohn, "Netnews [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
Article Format", draft-ietf-usefor-usefor-12 (work in October 2008.
progress),
<http://tools.ietf.org/html/draft-ietf-usefor-usefor-12>. [RFC5536] Murchison, K., Ed., Lindsey, C., and D. Kohn, "Netnews
Article Format", RFC 5536, November 2009.
8.2. Informative References 8.2. Informative References
[PGPMOOSE] [PGPMOOSE] Rose, G., "PGP Moose", November 1998.
Rose, G., "PGP Moose", November 1998,
<http://seer-grog.net/README>.
[PGPVERIFY] [PGPVERIFY] Lawrence, D., "Signing Control Messages", August 2001,
Lawrence, D., "Signing Control Messages", August 2001, <ftp://ftp.isc.org/pub/pgpcontrol/FORMAT>.
<ftp://ftp.isc.org/pub/pgpcontrol/FORMAT>.
[RFC0976] Horton, M., "UUCP mail interchange format standard", [RFC1036] Horton, M. and R. Adams, "Standard for interchange of
RFC 976, February 1986. USENET messages", RFC 1036, December 1987.
[RFC1036] Horton, M. and R. Adams, "Standard for interchange of [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet
USENET messages", RFC 1036, December 1987. Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", RFC 2045, November 1996.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS
Extensions (MIME) Part One: Format of Internet Message Names", BCP 32, RFC 2606, June 1999.
Bodies", RFC 2045, November 1996.
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS [RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition
Names", BCP 32, RFC 2606, June 1999. Notification", RFC 3798, May 2004.
[RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition [RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)",
Notification", RFC 3798, May 2004. RFC 3977, October 2006.
[RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", [SON-OF-1036] Spencer, H., "News Article Format and Transmission",
RFC 3977, October 2006. Work in Progress, May 2009.
[SON-OF-1036] [USEAGE] Lindsey, C., "Usenet Best Practice", Work in Progress,
Spencer, H., "News Article Format and Transmission", March 2005.
June 1994.
[USEAGE] Lindsey, C., "Usenet Best Practice", [UUCP] O'Reilly, T. and G. Todino, "Managing UUCP and
draft-ietf-usefor-useage-01 (work in progress), Usenet", O'Reilly & Associates Ltd., January 1992.
March 2005,
<http://tools.ietf.org/html/draft-ietf-usefor-useage-01>. RFC 5537 Netnews Architecture and Protocols November 2009
Appendix A. Changes to the Existing Protocols Appendix A. Changes to the Existing Protocols
This document prescribes many changes, clarifications, and new This document prescribes many changes, clarifications, and new
features since the protocol described in [RFC1036]. Most notably: features since the protocol described in [RFC1036]. Most notably:
o A new, backward-compatible Path header field format that permits o A new, backward-compatible Path header field format that permits
standardized embedding of additional trace and authentication standardized embedding of additional trace and authentication
information is now RECOMMENDED. See Section 3.2. Folding of the information is now RECOMMENDED. See Section 3.2. Folding of the
Path header is permitted. Path header is permitted.
o Trimming of the References header field is REQUIRED and a o Trimming of the References header field is REQUIRED, and a
mechanism for doing so is defined. mechanism for doing so is defined.
o Addition of the new Injection-Date header field is required in o Addition of the new Injection-Date header field is required in
some circumstances for posting agents (Section 3.4.2) and some circumstances for posting agents (Section 3.4.2) and
injecting agents (Section 3.5) and MUST be used by news servers injecting agents (Section 3.5), and MUST be used by news servers
for date checks (Section 3.6). Injecting agents are also strongly for date checks (Section 3.6). Injecting agents are also strongly
encouraged to put all local trace information in the new encouraged to put all local trace information in the new
Injection-Info header field. Injection-Info header field.
o A new media type is defined for transmitting Netnews articles o A new media type is defined for transmitting Netnews articles
through other media (Section 4.1), and moderators SHOULD prepare through other media (Section 4.1), and moderators SHOULD prepare
to receive submissions in that format (Section 3.5.1). to receive submissions in that format (Section 3.5.1).
o Certain control messages (Section 5.6) are declared obsolete, and o Certain control messages (Section 5.6) are declared obsolete, and
the special significance of "cmsg" at the start of a Subject the special significance of "cmsg" at the start of a Subject
header field is removed. header field is removed.
o Additional media types are defined for improved structuring, o Additional media types are defined for improved structuring,
specification, and automated processing of control messages specification, and automated processing of control messages
(Section 4.2 and Section 4.3). (Sections 4.2 and 4.3).
o Two new optional parameters are added to the checkgroups control o Two new optional parameters are added to the checkgroups control
message. message.
o The message/news media type is declared obsolete. o The message/news media type is declared obsolete.
o Cancel control messages are no longer required to have From and o Cancel control messages are no longer required to have From and
Sender header fields matching those of the target message, as this Sender header fields matching those of the target message, as this
requirement added no real security. requirement added no real security.
o The relayer-name parameter in the Control header field of ihave o The relayer-name parameter in the Control header field of ihave
and sendme control messages is now required. and sendme control messages is now required.
In addition, many protocol steps and article verification In addition, many protocol steps and article verification
requirements unmentioned or left ambiguous by [RFC1036] but widely requirements that are unmentioned or left ambiguous by [RFC1036] but
implemented by Netnews servers have been standardized and specified are widely implemented by Netnews servers have been standardized and
in detail. specified in detail.
RFC 5537 Netnews Architecture and Protocols November 2009
Appendix B. Acknowledgements Appendix B. Acknowledgements
This document is the result of a ten year effort and the number of This document is the result of a twelve-year effort and the number of
people that have contributed to its content are too numerous to people that have contributed to its content are too numerous to
mention individually. Many thanks go out to all past and present mention individually. Many thanks go out to all past and present
members of the USEFOR Working Group of the Internet Engineering Task members of the USEFOR Working Group of the Internet Engineering Task
Force (IETF) and the accompanying mailing list. Force (IETF) and the accompanying mailing list.
Special thanks are due to Henry Spencer, whose [SON-OF-1036] draft Special thanks are due to Henry Spencer, whose [SON-OF-1036] draft
served as the initial basis for this document. served as the initial basis for this document.
Authors' Addresses Authors' Addresses
Russ Allbery (editor) Russ Allbery (editor)
Stanford University Stanford University
P.O. Box 20066 P.O. Box 20066
Stanford, CA 94309 Stanford, CA 94309
US US
Email: rra@stanford.edu EMail: rra@stanford.edu
URI: http://www.eyrie.org/~eagle/ URI: http://www.eyrie.org/~eagle/
Charles H. Lindsey Charles H. Lindsey
5 Clerewood Avenue 5 Clerewood Avenue
Heald Green Heald Green
Cheadle Cheadle
Cheshire SK8 3JU Cheshire SK8 3JU
United Kingdom United Kingdom
Phone: +44 161 436 6131 Phone: +44 161 436 6131
Email: chl@clerew.man.ac.uk EMail: chl@clerew.man.ac.uk
 End of changes. 238 change blocks. 
527 lines changed or deleted 693 lines changed or added

This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/