draft-ietf-usefor-usepro-12.txt   draft-ietf-usefor-usepro-13.txt 
Usenet Format Working Group R. Allbery, Ed. Usenet Format Working Group R. Allbery, Ed.
Internet-Draft Stanford University Internet-Draft Stanford University
Obsoletes: 1036 (if approved) C. Lindsey Obsoletes: 1036 (if approved) C. Lindsey
Intended status: Standards Track University of Manchester Intended status: Standards Track December 14, 2008
Expires: February 28, 2009 August 27, 2008 Expires: June 17, 2009
Netnews Architecture and Protocols Netnews Architecture and Protocols
draft-ietf-usefor-usepro-12 draft-ietf-usefor-usepro-13
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 28, 2009. This Internet-Draft will expire on June 17, 2009.
Abstract Abstract
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 which originates, distributes, stores, and
displays them. It also specifies the requirements that must be met displays them. It also specifies the requirements that must be met
by any protocol used to transport and serve Netnews articles. by any protocol used to transport and serve Netnews articles.
Internet Draft Comments Internet Draft Comments
skipping to change at page 3, line 27 skipping to change at page 3, line 27
1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6
2. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Duties of Agents . . . . . . . . . . . . . . . . . . . . . . . 9 3. Duties of Agents . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. General Principles . . . . . . . . . . . . . . . . . . . . 9 3.1. General Principles . . . . . . . . . . . . . . . . . . . . 9
3.2. The Path Header Field . . . . . . . . . . . . . . . . . . 10 3.2. The Path Header Field . . . . . . . . . . . . . . . . . . 10
3.2.1. Constructing the Path Header Field . . . . . . . . . . 11 3.2.1. Constructing the Path Header Field . . . . . . . . . . 11
3.2.2. Path Header Field Example . . . . . . . . . . . . . . 12 3.2.2. Path Header Field Example . . . . . . . . . . . . . . 12
3.3. Article History and Duplicate Suppression . . . . . . . . 13 3.3. Article History and Duplicate Suppression . . . . . . . . 13
3.4. Duties of a Posting Agent . . . . . . . . . . . . . . . . 14 3.4. Duties of a Posting Agent . . . . . . . . . . . . . . . . 14
3.4.1. Proto-articles . . . . . . . . . . . . . . . . . . . . 15 3.4.1. Proto-articles . . . . . . . . . . . . . . . . . . . . 15
3.4.2. Multiple Injection of Articles . . . . . . . . . . . . 15 3.4.2. Multiple Injection of Articles . . . . . . . . . . . . 16
3.4.3. Followups . . . . . . . . . . . . . . . . . . . . . . 16 3.4.3. Followups . . . . . . . . . . . . . . . . . . . . . . 17
3.4.4. Construction of the References Header Field . . . . . 17 3.4.4. Construction of the References Header Field . . . . . 18
3.5. Duties of an Injecting Agent . . . . . . . . . . . . . . . 18 3.5. Duties of an Injecting Agent . . . . . . . . . . . . . . . 18
3.5.1. Forwarding Messages to a Moderator . . . . . . . . . . 20 3.5.1. Forwarding Messages to a Moderator . . . . . . . . . . 20
3.6. Duties of a Relaying Agent . . . . . . . . . . . . . . . . 21 3.6. Duties of a Relaying Agent . . . . . . . . . . . . . . . . 21
3.7. Duties of a Serving Agent . . . . . . . . . . . . . . . . 23 3.7. Duties of a Serving Agent . . . . . . . . . . . . . . . . 23
3.8. Duties of a Reading Agent . . . . . . . . . . . . . . . . 24 3.8. Duties of a Reading Agent . . . . . . . . . . . . . . . . 24
3.9. Duties of a Moderator . . . . . . . . . . . . . . . . . . 24 3.9. Duties of a Moderator . . . . . . . . . . . . . . . . . . 25
3.10. Duties of a Gateway . . . . . . . . . . . . . . . . . . . 26 3.10. Duties of a Gateway . . . . . . . . . . . . . . . . . . . 26
3.10.1. Duties of an Outgoing Gateway . . . . . . . . . . . . 27 3.10.1. Duties of an Outgoing Gateway . . . . . . . . . . . . 27
3.10.2. Duties of an Incoming Gateway . . . . . . . . . . . . 28 3.10.2. Duties of an Incoming Gateway . . . . . . . . . . . . 28
3.10.3. Gateway Example . . . . . . . . . . . . . . . . . . . 30 3.10.3. Original-Sender header field . . . . . . . . . . . . . 30
4. Media Types . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.10.4. Gateway Example . . . . . . . . . . . . . . . . . . . 30
4.1. application/news-transmission . . . . . . . . . . . . . . 31 4. Media Types . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2. application/news-groupinfo . . . . . . . . . . . . . . . . 32 4.1. application/news-transmission . . . . . . . . . . . . . . 32
4.3. application/news-checkgroups . . . . . . . . . . . . . . . 34 4.2. application/news-groupinfo . . . . . . . . . . . . . . . . 33
5. Control Messages . . . . . . . . . . . . . . . . . . . . . . . 37 4.3. application/news-checkgroups . . . . . . . . . . . . . . . 35
5.1. Authentication and Authorization . . . . . . . . . . . . . 37 5. Control Messages . . . . . . . . . . . . . . . . . . . . . . . 38
5.2. Group Control Messages . . . . . . . . . . . . . . . . . . 38 5.1. Authentication and Authorization . . . . . . . . . . . . . 38
5.2.1. The newgroup Control Message . . . . . . . . . . . . . 38 5.2. Group Control Messages . . . . . . . . . . . . . . . . . . 39
5.2.2. The rmgroup Control Message . . . . . . . . . . . . . 40 5.2.1. The newgroup Control Message . . . . . . . . . . . . . 39
5.2.3. The checkgroups Control Message . . . . . . . . . . . 40 5.2.2. The rmgroup Control Message . . . . . . . . . . . . . 41
5.3. The cancel Control Message . . . . . . . . . . . . . . . . 42 5.2.3. The checkgroups Control Message . . . . . . . . . . . 41
5.4. The Supersedes Header Field . . . . . . . . . . . . . . . 42 5.3. The cancel Control Message . . . . . . . . . . . . . . . . 43
5.5. The ihave and sendme Control Messages . . . . . . . . . . 43 5.4. The Supersedes Header Field . . . . . . . . . . . . . . . 43
5.6. Obsolete Control Messages . . . . . . . . . . . . . . . . 44 5.5. The ihave and sendme Control Messages . . . . . . . . . . 44
6. Security Considerations . . . . . . . . . . . . . . . . . . . 45 5.6. Obsolete Control Messages . . . . . . . . . . . . . . . . 45
6.1. Compromise of System Integrity . . . . . . . . . . . . . . 45 6. Security Considerations . . . . . . . . . . . . . . . . . . . 46
6.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 46 6.1. Compromise of System Integrity . . . . . . . . . . . . . . 46
6.3. Leakage . . . . . . . . . . . . . . . . . . . . . . . . . 47 6.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 47
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 6.3. Leakage . . . . . . . . . . . . . . . . . . . . . . . . . 48
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
8.1. Normative References . . . . . . . . . . . . . . . . . . . 49 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50
8.2. Informative References . . . . . . . . . . . . . . . . . . 49 8.1. Normative References . . . . . . . . . . . . . . . . . . . 50
Appendix A. Changes to the Existing Protocols . . . . . . . . . . 51 8.2. Informative References . . . . . . . . . . . . . . . . . . 50
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 52 Appendix A. Changes to the Existing Protocols . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 53
Intellectual Property and Copyright Statements . . . . . . . . . . 54 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54
Intellectual Property and Copyright Statements . . . . . . . . . . 55
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 [USEFOR], 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
skipping to change at page 11, line 50 skipping to change at page 11, line 50
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.
The "expected <path-identity> of the source of the article" is a
<path-identity> for the injecting or relaying agent that passed
the article to this relaying or serving agent, determined by
properties of the connection via which the article was received
(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 which 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
skipping to change at page 12, line 42 skipping to change at page 12, line 47
!.MISMATCH.2001:DB:0:0:8:800:200C:417A!bar.isp.example !.MISMATCH.2001:DB: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 common
<tail-entry>. <tail-entry>.
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". old.site.example, as "barbaz". That relaying agent confirmed to its
satisfaction that "baz.isp.example" was an expected <path-identity>
for the source of the article and therefore used <diag-match> ("!")
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-
delimiter) 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 that 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
skipping to change at page 14, line 4 skipping to change at page 14, line 13
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 its Date header
field.) 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 be aggressively short. For it had not yet seen, so it ought not to be aggressively short.
Usenet, for example, a cutoff interval of no less than seven days For Usenet, for example, a cutoff interval of no less than seven
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
articles that had dates older than the cutoff from their history articles that had dates older than the cutoff from their history
databases. If such an article were offered to the agent again, it databases. If such an article were offered to the agent again, it
would be rejected due to the cutoff date, so the history record is would be rejected due to the cutoff date, so the history record is
no longer required to suppress the duplicate. no longer required to suppress the duplicate.
o Alternatively, agents MAY drop history records according to the o Alternatively, agents MAY drop history records according to the
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
skipping to change at page 15, line 36 skipping to change at page 15, line 45
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 for offering to an injecting agent. It may omit certain header
fields which can be better-supplied by the injecting agent and will fields which can be better-supplied by the injecting agent and will
not contain header fields that are added by the injecting agent. A not contain header fields that are added by the injecting agent. A
proto-article is only for transmission to an injecting agent and proto-article is only for transmission to an injecting agent and
SHOULD NOT be transmitted to any other agent. SHOULD NOT be transmitted to any other agent.
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 MUST NOT contain a "POSTED" <diag-keyword>; and any Path header field SHOULD NOT contain a "POSTED" <diag-keyword>; and
of the following mandatory header fields MAY be omitted: Message-ID, any of the following mandatory header fields MAY be omitted:
Date, and Path. In all other respects, a proto-article MUST be a Message-ID, Date, and Path. In all other respects, a proto-article
valid Netnews article. In particular, the header fields which may be MUST be a valid Netnews article. In particular, the header fields
omitted MUST NOT be present with invalid content. which 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 disjoint networks, Under some circumstances (posting to multiple supposedly disjoint
injecting agents with spotty connectivity, or for redundancy, for networks, injecting agents with spotty connectivity, or for
example), a posting agent may wish to offer the same article to redundancy, for example), a posting agent may wish to offer the same
multiple injecting agents. In this unusual case, the goal is to not article to multiple injecting agents. In this unusual case, the goal
create multiple independent articles but rather to inject the same is to not create multiple independent articles but rather to inject
article at multiple points and let the normal duplicate suppression the same article at multiple points and let the normal duplicate
facility of Netnews (see Section 3.3) ensure that any given agent suppression facility of Netnews (see Section 3.3) ensure that any
accepts the article only once, even if supposedly disjoint networks given agent accepts the article only once, even if supposedly
have unexpected links. 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 the fact, 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 convert the unconnected one). In this case, the posting agent MUST remove any
article back into a proto-article before passing it to another Xref header field and rename or remove any Injection-Info, Path, and
injecting agent, but it MUST retain unmodified the Message-ID, Date, other trace header field before passing it to another injecting
and Injection-Date header fields. It MUST NOT add an Injection-Date agent. (This converts the article back into a proto-article.) It
header field if it is missing from the existing article. It MUST MUST retain unmodified the Message-ID, Date, and Injection-Date
remove any Xref header field and either rename or remove any header fields. It MUST NOT add an Injection-Date header field if it
Injection-Info header field and other trace fields. is missing from the existing article.
NOTE: Multiple injection inherently risks duplicating articles. NOTE: Multiple injection inherently risks duplicating articles.
Multiple injection after the fact, 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
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 listing 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
skipping to change at page 18, line 4 skipping to change at page 18, line 14
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 and the content of the Message-ID header field of the parent. present, followed by the content of the Message-ID header field of
If the parent had a References header, FWS as defined in [USEFOR] the parent. If the parent had a References header, FWS as defined in
MUST be added between its content and the Message-ID header field [USEFOR] MUST be added between its content and the Message-ID header
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
skipping to change at page 20, line 52 skipping to change at page 21, line 12
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 (such as a To header field) required for an email. header fields required for an email as defined in [RFC2822], and
possibly with the addition of other header fields conventional in
The existing Message-ID header field SHOULD be retained. email such as To and Received. The existing Message-ID header
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,
skipping to change at page 22, line 33 skipping to change at page 22, line 44
the cutoff interval since it won't know whether such articles had the cutoff interval since it won't know whether such articles had
been accepted previously or not. been accepted previously or not.
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
chose (on the basis of local site policy) to honor that cancel has chosen (on the basis of local site policy) to honor that
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 required
to be maintained by a relaying agent. 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
skipping to change at page 25, line 49 skipping to change at page 26, line 14
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 [USEFOR]) 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
if it is valid, and also retain the Date header field unless it unless it is invalid or the article was significantly changed
appears to be stale (72 hours or more in the past) for reasons from its original form. Moderators are also encouraged to retain
understood by the moderator (such as delays in the moderation the Date header field unless it appears to be stale (72 hours or
process) in which case they MAY substitute the current date. Any more in the past) for reasons understood by the moderator (such
Injection-Date, Injection-Info, or Xref header fields already as delays in the moderation process) in which case they MAY
present MUST be removed. substitute the current date. Any Injection-Date, Injection-Info,
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.
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
skipping to change at page 29, line 48 skipping to change at page 30, line 11
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 containing the <mailbox> of the administrator of the
gateway. Problems with the gateway may be reported to this 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 so that its contents can be preserved. 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
header field.
3.10.3. Gateway Example 3.10.3. Original-Sender header field
The Original-Sender header field holds the content of a Sender header
field in an original message received by an incoming gateway,
preserving it while the incoming gateway adds its own Sender header
field. The content syntax makes use of syntax defined in [USEFOR]
and [RFC2822].
header =/ Original-Sender-header
Original-Sender-header
= "Original-Sender" ":" SP
Original-Sender-content
Original-Sender-content
= mailbox
The Permanent Message Header Field Repository entry for this header
field is:
Header field name: Original-Sender
Applicable protocol: Netnews
Status: standard
Author/Change controller: IETF
Specification document(s): RFCXXXX
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-Gateway header field to all 2. The news-to-mail gateway adds an X-* header field to all messages
messages it generates. The mail-to-news gateway discards any it generates. The mail-to-news gateway discards any incoming
incoming messages containing this header field. This is robust messages containing this header field. This is robust against
against mailing list managers that replace the message mailing list managers that replace the message identifier, and
identifier, and against any number of email hops, provided that against any number of email hops, provided that the other message
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.
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
skipping to change at page 35, line 48 skipping to change at page 36, line 48
checkgroups-body = *( valid-group CRLF ) checkgroups-body = *( valid-group CRLF )
valid-group = newsgroups-line ; see 4.2 valid-group = newsgroups-line ; see 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>. In other words, an for which it contains a <valid-group> unless accompanied by external
application/news-checkgroups body part consisting of: information limiting its scope (such as a <chkscope> parameter to a
checkgroups control message as described in Section 5.2.3). In 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
that exist in that hierarchy MUST be listed. that exist in that hierarchy MUST be listed unless its scope is
limited by external information, in which case all groups SHOULD be
listed.
5. Control Messages 5. Control Messages
A control message is an article which contains a Control header field A control message is an article which 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 [USEFOR]) 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
skipping to change at page 37, line 28 skipping to change at page 38, line 28
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 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 with
no Control header field and such a Subject header field as ambiguous. no Control header field and such a Subject header field as ambiguous.
Likewise, the presence of a <newsgroup-name> ending in ".ctl" in the Likewise, the presence of a <newsgroup-name> ending in ".ctl" in the
Newsgroups header field or the presence of an Also-Control header Newsgroups header field or the presence of an Also-Control header
field MUST NOT cause the article to be interpreted as a control field MUST NOT cause the article to be interpreted as a control
message. 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. common use, such as [PGPVERIFY].
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.
skipping to change at page 42, line 47 skipping to change at page 43, line 47
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
message. Accordingly, news servers SHOULD use the same message. Accordingly, news servers SHOULD apply to a Supersedes
authentication and authorization checks for deciding whether to honor header field the same authentication and authorization checks as they
a Supersedes header field as they use for cancel control messages. would apply to cancel control messages. If the Supersedes header
If the Supersedes header field is honored, the news server SHOULD field is honored, the news server SHOULD take the same actions as it
take the same actions as it would take when honoring a cancel control would take when honoring a cancel control message for the given
message for the given target article. target article.
The article containing the Supersedes header field, whether or not
the Supersedes header field is honored, SHOULD be handled as a normal
article and SHOULD NOT receive the special treatment of control
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. 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:
skipping to change at page 46, line 10 skipping to change at page 47, line 10
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
verify that messages approved for a moderated newsgroup are being verify that messages approved for a moderated newsgroup are being
injected by the moderator using authentication information from the injected by the moderator using authentication information from the
underlying transport or some other authentication mechanism arranged underlying transport or some other authentication mechanism arranged
with the moderator. with the moderator. There is, at present, no standardized method of
authenticating approval of messages to moderated groups, although
some unstandardized authentication methods such as [PGPMOOSE] are in
common use.
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.
skipping to change at page 48, line 18 skipping to change at page 49, line 18
elsewhere in this document, for use with the Content-Type header elsewhere in this document, for use with the Content-Type header
field, in the IETF tree in accordance with the procedures set out in field, in the 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
the Permanent Message Header Field Repository using the template in
Section 3.10.3.
IANA is also requested to change the status of the message/news media IANA is also requested to change the status of the message/news media
type to "OBSOLETE". message/rfc822 should be used instead. An type to "OBSOLETE". message/rfc822 should be used instead. An
updated template is included in Section 4. updated 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, "Coded
Character Sets - 7-Bit American National Standard Code for Character Sets - 7-Bit American National Standard Code for
skipping to change at page 49, line 39 skipping to change at page 50, line 39
[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 [USEFOR] Murchison, K., Ed., Lindsey, C., and D. Kohn, "Netnews
Article Format", draft-ietf-usefor-usefor-12 (work in Article Format", draft-ietf-usefor-usefor-12 (work in
progress), progress),
<http://tools.ietf.org/html/draft-ietf-usefor-usefor-12>. <http://tools.ietf.org/html/draft-ietf-usefor-usefor-12>.
8.2. Informative References 8.2. Informative References
[PGPMOOSE]
Rose, G., "PGP Moose", November 1998,
<http://seer-grog.net/README>.
[PGPVERIFY]
Lawrence, D., "Signing Control Messages", August 2001,
<ftp://ftp.isc.org/pub/pgpcontrol/FORMAT>.
[RFC0976] Horton, M., "UUCP mail interchange format standard", [RFC0976] Horton, M., "UUCP mail interchange format standard",
RFC 976, February 1986. RFC 976, February 1986.
[RFC1036] Horton, M. and R. Adams, "Standard for interchange of [RFC1036] Horton, M. and R. Adams, "Standard for interchange of
USENET messages", RFC 1036, December 1987. USENET messages", RFC 1036, December 1987.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996. Bodies", RFC 2045, November 1996.
skipping to change at page 53, line 17 skipping to change at page 54, line 17
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
University of Manchester
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
Full Copyright Statement Full Copyright Statement
 End of changes. 31 change blocks. 
101 lines changed or deleted 162 lines changed or added

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