draft-ietf-usefor-article-10.txt   draft-ietf-usefor-article-11.txt 
INTERNET-DRAFT Charles H. Lindsey INTERNET-DRAFT Charles H. Lindsey
Usenet Format Working Group University of Manchester Usenet Format Working Group University of Manchester
April 2003 June 2003
News Article Format News Article Format
<draft-ietf-usefor-article-10.txt> <draft-ietf-usefor-article-11.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. all provisions of Section 10 of RFC 2026.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 50 skipping to change at page 1, line 50
Since the 1980s, Usenet has grown explosively, and many Internet and Since the 1980s, Usenet has grown explosively, and many Internet and
non-Internet sites now participate. In addition, the Netnews non-Internet sites now participate. In addition, the Netnews
technology is now in widespread use for other purposes. technology is now in widespread use for other purposes.
Backward compatibility has been a major goal of this endeavour, but Backward compatibility has been a major goal of this endeavour, but
where this standard and earlier documents or practices conflict, this where this standard and earlier documents or practices conflict, this
standard should be followed. In most such cases, current practice is standard should be followed. In most such cases, current practice is
already compatible with these changes. already compatible with these changes.
[This draft is derived from draft-09 by removing all the [Draft-10 removed all the Internationalization features (i.e. those
Internationalization features (i.e. those involving the use of the UTF-8 involving the use of the UTF-8 charset in headers). This is being done
charset in headers). This is being done so as to facilitate publishing so as to facilitate publishing those features, or similar ones, as an
those features, or similar ones, as an experimental protocol at a later experimental protocol at a later stage.
stage.
It is also intended to split it into two or more documents. Thus this
present draft is but an intermediate stage in an ongoing development
News Article Format April 2003
process.] This present draft is derived from draft-10 by removing many
requirements which were present for Social rather than Normative reasons
News Article Format June 2003
(and in particular the word "Ought" with its specially defined meaning
is no longer used). These former requirements will now appear in a
companion Informational document/*(us.
There may well be a further split of the present draft into a
syntax/semantics part and a protocol part. Thus this present draft is
but an intermediate stage in an ongoing development process.]
[The use of the words "this standard" within this document when [The use of the words "this standard" within this document when
referring to itself does not imply that this draft yet has pretensions referring to itself does not imply that this draft yet has pretensions
to be a standard, but rather indicates what will become the case if and to be a standard, but rather indicates what will become the case if and
when it is accepted as an RFC with the status of a proposed or draft when it is accepted as an RFC with the status of a proposed or draft
standard.] standard.]
[Remarks enclosed in square brackets and aligned with the left margin, [Remarks enclosed in square brackets and aligned with the left margin,
such as this one, are not part of this draft, but are editorial notes to such as this one, are not part of this draft, but are editorial notes to
explain matters amongst ourselves, or to point out alternatives, or to explain matters amongst ourselves, or to point out alternatives, or to
assist the RFC Editor.] assist the RFC Editor.]
skipping to change at page 2, line 28 skipping to change at page 2, line 34
[In this draft, references to [NNTP] are to be replaced by [RFC 977], or [In this draft, references to [NNTP] are to be replaced by [RFC 977], or
else by references to the RFC arising from the series of drafts draft- else by references to the RFC arising from the series of drafts draft-
ietf-nntpext-base-*.txt, in the event that such RFC has been accepted at ietf-nntpext-base-*.txt, in the event that such RFC has been accepted at
the time this document is published. Likewise, if may be possible to the time this document is published. Likewise, if may be possible to
replace references to [RFC 2279] by references to [RFC 2279bis].] replace references to [RFC 2279] by references to [RFC 2279bis].]
Table of Contents Table of Contents
1. Introduction .................................................. 6 1. Introduction .................................................. 6
1.1. Basic Concepts ............................................ 6 1.1. Basic Concepts ............................................ 6
1.2. Objectives ................................................ 7 1.2. Objectives ................................................ 6
1.3. Historical Outline ........................................ 7 1.3. Historical Outline ........................................ 7
1.4. Transport ................................................. 7 1.4. Transport ................................................. 7
2. Definitions, Notations and Conventions ........................ 8 2. Definitions, Notations and Conventions ........................ 7
2.1. Definitions ............................................... 8 2.1. Definitions ............................................... 7
2.2. Textual Notations ......................................... 9 2.2. Textual Notations ......................................... 9
2.3. Relation To Email and MIME ................................ 11 2.3. Relation To Email and MIME ................................ 10
2.4. Syntax .................................................... 11 2.4. Syntax .................................................... 10
2.4.1. Syntax Notation ....................................... 11 2.4.1. Syntax Notation ....................................... 10
2.4.2. Syntax adapted from Email and MIME .................... 11 2.4.2. Syntax adapted from Email and MIME .................... 11
2.4.3. Syntax copied from other standards .................... 12 2.4.3. Syntax copied from other standards .................... 13
2.5. Language .................................................. 14 2.5. Language .................................................. 15
3. Changes to the existing protocols ............................. 14 3. Changes to the existing protocols ............................. 15
3.1. Principal Changes ......................................... 15 3.1. Principal Changes ......................................... 15
3.2. Transitional Arrangements ................................. 15 3.2. Transitional Arrangements ................................. 16
4. Basic Format .................................................. 16 4. Basic Format .................................................. 17
4.1. Syntax of News Articles ................................... 16 4.1. Syntax of News Articles ................................... 17
4.2. Headers ................................................... 17 4.2. Headers ................................................... 18
4.2.1. Naming of Headers ..................................... 17 4.2.1. Naming of Headers ..................................... 18
4.2.2. MIME-style Parameters ................................. 18 4.2.2. MIME-style Parameters ................................. 19
4.2.3. White Space and Continuations ......................... 19 4.2.3. White Space and Continuations ......................... 20
4.2.4. Comments .............................................. 20 4.2.4. Comments .............................................. 21
4.2.5. Header Properties ..................................... 21 4.2.5. Header Properties ..................................... 22
4.2.5.1. Experimental Headers .............................. 21 4.2.5.1. Experimental Headers .............................. 22
4.2.5.2. Inheritable Headers ............................... 22 4.2.5.2. Inheritable Headers ............................... 22
News Article Format June 2003
4.2.5.3. Variant Headers ................................... 22 4.2.5.3. Variant Headers ................................... 22
4.2.6. Undesirable Headers ................................... 22 4.2.6. Undesirable Headers ................................... 23
4.3. Body ...................................................... 23 4.3. Body ...................................................... 23
4.3.1. Body Format Issues .................................... 23 4.3.1. Body Format Issues .................................... 23
4.3.2. Body Conventions ...................................... 23 4.3.2. Body Conventions ...................................... 23
4.4. Characters and Character Sets ............................. 25 4.4. Characters and Character Sets ............................. 23
News Article Format April 2003 4.4.1. Character Sets within Article Headers ................. 24
4.4.2. Character Sets within Article Bodies .................. 25
4.4.1. Character Sets within Article Headers ................. 26 4.5. Size Limits ............................................... 25
4.4.2. Character Sets within Article Bodies .................. 26 4.6. Example ................................................... 26
4.5. Size Limits ............................................... 26 5. Mandatory Headers ............................................. 26
4.6. Example ................................................... 27 5.1. Date ...................................................... 26
5. Mandatory Headers ............................................. 28 5.1.1. Examples .............................................. 27
5.1. Date ...................................................... 28 5.2. From ...................................................... 27
5.1.1. Examples .............................................. 29 5.2.1. Examples: ............................................ 27
5.2. From ...................................................... 29 5.3. Message-ID ................................................ 28
5.2.1. Examples: ............................................ 30 5.4. Subject ................................................... 29
5.3. Message-ID ................................................ 30 5.5. Newsgroups ................................................ 29
5.4. Subject ................................................... 31 5.5.1. Forbidden newsgroup-names ............................. 31
5.4.1. Examples .............................................. 32 5.6. Path ...................................................... 31
5.5. Newsgroups ................................................ 33 5.6.1. Format ................................................ 32
5.5.1. Forbidden newsgroup-names ............................. 35 5.6.2. Adding a path-identity to the Path-header ............. 32
5.6. Path ...................................................... 35 5.6.3. The tail-entry ........................................ 34
5.6.1. Format ................................................ 36 5.6.4. Path-Delimiter Summary ................................ 34
5.6.2. Adding a path-identity to the Path-header ............. 36 5.6.5. Suggested Verification Methods ........................ 35
5.6.3. The tail-entry ........................................ 38 5.6.6. Example ............................................... 35
5.6.4. Path-Delimiter Summary ................................ 38 6. Optional Headers .............................................. 36
5.6.5. Suggested Verification Methods ........................ 39 6.1. Reply-To .................................................. 36
5.6.6. Example ............................................... 39 6.1.1. Examples .............................................. 36
6. Optional Headers .............................................. 40 6.2. Sender .................................................... 36
6.1. Reply-To .................................................. 40 6.3. Organization .............................................. 37
6.1.1. Examples .............................................. 41 6.4. Keywords .................................................. 37
6.2. Sender .................................................... 41 6.5. Summary ................................................... 37
6.3. Organization .............................................. 41 6.6. Distribution .............................................. 37
6.4. Keywords .................................................. 41 6.7. Followup-To ............................................... 38
6.5. Summary ................................................... 42 6.8. Mail-Copies-To ............................................ 39
6.6. Distribution .............................................. 42 6.9. Posted-And-Mailed ......................................... 39
6.7. Followup-To ............................................... 43 6.10. References ............................................... 40
6.8. Mail-Copies-To ............................................ 44 6.10.1. Examples ............................................. 40
6.9. Posted-And-Mailed ......................................... 45 6.11. Expires .................................................. 41
6.10. References ............................................... 45 6.12. Archive .................................................. 41
6.10.1. Examples ............................................. 46 6.13. Control .................................................. 42
6.11. Expires .................................................. 46 6.14. Approved ................................................. 42
6.12. Archive .................................................. 47 6.15. Supersedes ............................................... 43
6.13. Control .................................................. 47 6.16. Xref ..................................................... 44
6.14. Approved ................................................. 48 6.17. Lines .................................................... 44
6.15. Supersedes ............................................... 49 6.18. User-Agent ............................................... 45
6.16. Xref ..................................................... 49 6.18.1. Examples ............................................. 45
6.17. Lines .................................................... 50 6.19. Injector-Info ............................................ 46
6.18. User-Agent ............................................... 50 6.19.1. Usage of Injector-Info-parameters .................... 47
6.18.1. Examples ............................................. 51 6.19.1.1. The posting-host-parameter ....................... 47
6.19. Injector-Info ............................................ 52 6.19.1.2. The posting-account-parameter .................... 48
6.19.1. Usage of Injector-Info-parameters .................... 53 6.19.1.3. The posting-sender-parameter ..................... 48
6.19.1.1. The posting-host-parameter ....................... 54 6.19.1.4. The posting-logging-parameter .................... 48
6.19.1.2. The posting-account-parameter .................... 54 News Article Format June 2003
6.19.1.3. The posting-sender-parameter ..................... 54
6.19.1.4. The posting-logging-parameter .................... 55
6.19.1.5. The posting-date-parameter ....................... 55
6.19.2. Example .............................................. 55
6.20. Complaints-To ............................................ 55
6.21. MIME headers ............................................. 56
6.21.1. Syntax ............................................... 56
News Article Format April 2003
6.21.2. Content-Type ......................................... 56 6.19.1.5. The posting-date-parameter ....................... 48
6.21.2.1. Message/partial .................................. 57 6.19.2. Example .............................................. 48
6.21.2.2. Message/rfc822 ................................... 57 6.20. Complaints-To ............................................ 48
6.21.2.3. Message/external-body ............................ 58 6.21. MIME headers ............................................. 49
6.21.2.4. Multipart types .................................. 58 6.21.1. Syntax ............................................... 49
6.21.3. Content-Transfer-Encoding ............................ 58 6.21.2. Content-Type ......................................... 50
6.21.4. Character Sets ....................................... 60 6.21.3. Content-Transfer-Encoding ............................ 50
6.21.5. Content Disposition .................................. 60 6.21.4. Character Sets ....................................... 51
6.21.6. Definition of some new Content-Types ................. 60 6.21.5. Content Disposition .................................. 51
6.21.6.1. Application/news-transmission .................... 60 6.21.6. Definition of some new Content-Types ................. 51
6.21.6.2. Message/news obsoleted ........................... 62 6.21.6.1. Application/news-transmission .................... 51
6.22. Obsolete Headers ......................................... 62 6.21.6.2. Message/news obsoleted ........................... 53
7. Control Messages .............................................. 62 6.22. Obsolete Headers ......................................... 53
7.1. Digital Signature of Headers .............................. 63 7. Control Messages .............................................. 53
7.2. Group Control Messages .................................... 63 7.1. Digital Signature of Headers .............................. 53
7.2.1. The 'newgroup' Control Message ........................ 63 7.2. Group Control Messages .................................... 54
7.2.1.1. The Body of the 'newgroup' Control Message ........ 64 7.2.1. The 'newgroup' Control Message ........................ 54
7.2.1.2. Application/news-groupinfo ........................ 64 7.2.1.1. The Body of the 'newgroup' Control Message ........ 55
7.2.1.3. Initial Articles .................................. 66 7.2.1.2. Application/news-groupinfo ........................ 55
7.2.1.4. Example ........................................... 66 7.2.1.3. Initial Articles .................................. 56
7.2.2. The 'rmgroup' Control Message ......................... 67 7.2.1.4. Example ........................................... 57
7.2.2.1. Example ........................................... 67 7.2.2. The 'rmgroup' Control Message ......................... 58
7.2.3. The 'mvgroup' Control Message ......................... 68 7.2.2.1. Example ........................................... 58
7.2.3.1. Example ........................................... 69 7.2.3. The 'mvgroup' Control Message ......................... 58
7.2.4. The 'checkgroups' Control Message ..................... 70 7.2.3.1. Example ........................................... 60
7.2.4.1. Application/news-checkgroups ...................... 71 7.2.4. The 'checkgroups' Control Message ..................... 60
7.3. Cancel .................................................... 71 7.2.4.1. Application/news-checkgroups ...................... 61
7.4. Ihave, sendme ............................................. 72 7.3. Cancel .................................................... 62
7.5. Obsolete control messages. ............................... 74 7.4. Ihave, sendme ............................................. 63
8. Duties of Various Agents ...................................... 74 7.5. Obsolete control messages. ............................... 64
8.1. General principles to be followed ......................... 74 8. Duties of Various Agents ...................................... 64
8.2. Duties of an Injecting Agent .............................. 75 8.1. General principles to be followed ......................... 64
8.2.1. Proto-articles ........................................ 75 8.2. Duties of an Injecting Agent .............................. 65
8.2.2. Procedure to be followed by Injecting Agents .......... 75 8.2.1. Proto-articles ........................................ 65
8.3. Duties of a Relaying Agent ................................ 77 8.2.2. Procedure to be followed by Injecting Agents .......... 65
8.4. Duties of a Serving Agent ................................. 79 8.3. Duties of a Relaying Agent ................................ 67
8.5. Duties of a Posting Agent ................................. 79 8.4. Duties of a Serving Agent ................................. 68
8.6. Duties of a Followup Agent ................................ 80 8.5. Duties of a Posting Agent ................................. 69
8.7. Duties of a Moderator ..................................... 80 8.6. Duties of a Followup Agent ................................ 70
8.8. Duties of a Gateway ....................................... 82 8.7. Duties of a Moderator ..................................... 71
8.8.1. Duties of an Outgoing Gateway ......................... 83 8.8. Duties of a Gateway ....................................... 73
8.8.2. Duties of an Incoming Gateway ......................... 84 8.8.1. Duties of an Outgoing Gateway ......................... 74
8.8.3. Example ............................................... 86 8.8.2. Duties of an Incoming Gateway ......................... 74
9. Security and Related Considerations ........................... 86 8.8.3. Example ............................................... 76
9.1. Leakage ................................................... 87 9. Security and Related Considerations ........................... 77
9.2. Attacks ................................................... 87 9.1. Leakage ................................................... 77
9.2.1. Denial of Service ..................................... 87 9.2. Attacks ................................................... 78
9.2.2. Compromise of System Integrity ........................ 88 9.2.1. Denial of Service ..................................... 78
9.3. Liability ................................................. 89 9.2.2. Compromise of System Integrity ........................ 79
10. IANA Considerations .......................................... 90 9.3. Liability ................................................. 80
11. References ................................................... 90 10. IANA Considerations .......................................... 81
12. Acknowledgements ............................................. 93 11. References ................................................... 81
13. Contact Address .............................................. 94 12. Acknowledgements ............................................. 83
Appendix A.1 - A-News Article Format .............................. 94 13. Contact Address .............................................. 84
News Article Format April 2003 News Article Format June 2003
Appendix A.2 - Early B-News Article Format ........................ 95 Appendix A.1 - A-News Article Format .............................. 85
Appendix A.3 - Obsolete Headers ................................... 95 Appendix A.2 - Early B-News Article Format ........................ 85
Appendix A.4 - Obsolete Control Messages .......................... 96 Appendix A.3 - Obsolete Headers ................................... 86
Appendix B - Collected Syntax ..................................... 97 Appendix A.4 - Obsolete Control Messages .......................... 86
Appendix B.1 - Characters, Atoms and Folding ...................... 97 Appendix B - Collected Syntax ..................................... 87
Appendix B.2 - Basic Forms ........................................ 98 Appendix B.1 - Characters, Atoms and Folding ...................... 87
Appendix B.3 - Headers ............................................ 100 Appendix B.2 - Basic Forms ........................................ 89
Appendix B.3.1 - Header outlines .................................. 100 Appendix B.3 - Headers ............................................ 90
Appendix B.3.2 - Control-message outlines ......................... 102 Appendix B.3.1 - Header outlines .................................. 90
Appendix B.3.3 - Other header rules ............................... 102 Appendix B.3.2 - Control-message outlines ......................... 92
Appendix C - Notices .............................................. 104 Appendix B.3.3 - Other header rules ............................... 93
News Article Format April 2003 Appendix C - Notices .............................................. 95
News Article Format June 2003
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" (which resemble email messages) and for retrieving news "articles" (which resemble email messages) and for
exchanging them amongst a readership which is potentially widely exchanging them amongst a readership which 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 6, line 34 skipping to change at page 6, line 34
participation to some restricted set of hosts (within some company, participation to some restricted set of hosts (within some company,
for example) is a "closed" network; otherwise it is an "open" for example) is a "closed" network; otherwise it is an "open"
network. A set of hosts within a network which, by mutual network. A set of hosts within a network which, by mutual
arrangement, operates some variant (whether more or less restrictive) arrangement, operates some variant (whether more or less restrictive)
of the Netnews protocols is a "cooperating subnet". of the Netnews protocols is a "cooperating subnet".
"Usenet" is a particular worldwide open network based upon the "Usenet" is a particular worldwide open network based upon the
Netnews protocols, with the newsgroups being organized into Netnews protocols, with the newsgroups being organized into
recognized "hierarchies". Anybody can join (it is simply necessary recognized "hierarchies". Anybody can join (it is simply necessary
to negotiate an exchange of articles with one or more other to negotiate an exchange of articles with one or more other
participating hosts). Usenet "belongs" to those who administer the participating hosts)
hosts of which it is comprised. There is no Cabal with overall
authority to direct what is to be be allowed. Nevertheless, there do
exist agencies within Usenet that have authority to establish
policies and to perform administrative functions, but such authority
derives solely from the consent of those sites which choose to
recognize it (and who can decline to exchange articles with sites
which choose not to recognize it). Usually, the authority of such an
agency is restricted to a particular hierarchy, or group of
hierarchies.
A "policy" is a rule intended to facilitate the smooth operation of a A "policy" is a rule intended to facilitate the smooth operation of a
network by establishing parameters which restrict behaviour that, network by establishing parameters which restrict behaviour that,
whilst technically unexceptionable, would nevertheless contravene whilst technically unexceptionable, would nevertheless contravene
some accepted standard of "Good Netkeeping". Since the ultimate some accepted standard of "Good Netkeeping". Since the ultimate
beneficiaries of a network are its human readers, who will be less beneficiaries of a network are its human readers, who will be less
tolerant of poorly designed interfaces than mere computers, articles tolerant of poorly designed interfaces than mere computers, articles
in breach of established policy can cause considerable annoyance to in breach of established policy can cause considerable annoyance to
their recipients. their recipients.
Policies may well vary from network to network, from hierarchy to
hierarchy within one network, and even between individual newsgroups
within one hierarchy. It is assumed, for the purposes of this
standard, that agencies with varying degrees of authority to
establish such policies will exist, and that where they do not,
policy will be established by mutual agreement. For the benefit of
News Article Format April 2003
networks and hierarchies without such established agencies, and to
provide a basis upon which all agencies can build, this present
standard often provides default policy parameters, usually
introducing them by a phrase such as "As a matter of policy ...".
1.2. Objectives 1.2. Objectives
The purpose of this present standard is to define the format of The purpose of this present standard is to define the format of
articles and the protocols to be used for Netnews in general, and for articles and the protocols to be used for Netnews in general, and for
Usenet in particular, and to set standards to be followed by software Usenet in particular, and to set standards to be followed by software
that implements those protocols. that implements those protocols.
It is NOT the purpose of this standard to define how the authority of It is NOT the purpose of this standard to settle matters of policy,
various agencies to exercise control or oversight of the various nor aspects of software behaviour which do not impinge upon the
parts of Usenet is established (that is itself a matter of policy). generation, transmission, storate and reception of articles, nor how
Nevertheless, it is assumed that such authorities will exist, and the authority of various agencies to exercise control or oversight of
tools are provided within the protocols for their use. the various parts of Usenet is established. For these purposes, a
separate informational document [USEAGE] is being provided.
News Article Format June 2003
Nevertheless, it is assumed that agencies with the necessary
authority will exist, and tools are provided within the protocols for
their use.
1.3. Historical Outline 1.3. Historical Outline
Network news originated as the medium of communication for Usenet, Network news originated as the medium of communication for Usenet,
circa 1980. Since then, Usenet has grown explosively, and many circa 1980. Since then, Usenet has grown explosively, and many
Internet and non-Internet sites participate in it. In addition, the Internet and non-Internet sites participate in it. In addition, the
news technology is now in widespread use for other purposes, on the news technology is now in widespread use for other purposes, on the
Internet and elsewhere. Internet and elsewhere.
The earliest news interchange used the so-called "A News" article The earliest news interchange used the so-called "A News" article
skipping to change at page 8, line 5 skipping to change at page 7, line 47
1.4. Transport 1.4. Transport
As in this standard's predecessors, the exact means used to transmit As in this standard's predecessors, the exact means used to transmit
articles from one host to another is not specified. NNTP [NNTP] is articles from one host to another is not specified. NNTP [NNTP] is
the most common transmission method on the Internet, but much the most common transmission method on the Internet, but much
transmission takes place entirely independent of the Internet. Other transmission takes place entirely independent of the Internet. Other
methods in use include the UUCP protocol [RFC 976] extensively used methods in use include the UUCP protocol [RFC 976] extensively used
in the early days of Usenet, FTP, downloading via satellite, tape in the early days of Usenet, FTP, downloading via satellite, tape
archives, and physically delivered magnetic and optical media. archives, and physically delivered magnetic and optical media.
News Article Format April 2003
2. Definitions, Notations and Conventions 2. Definitions, Notations and Conventions
2.1. Definitions 2.1. Definitions
An "article" is the unit of news, analogous to an [RFC 2822] An "article" is the unit of news, analogous to an [RFC 2822]
"message". A "proto-article" is one that has not yet been injected "message". A "proto-article" is one that has not yet been injected
into the news system. into the news system.
A "message identifier" (5.3) is a unique identifier for an article, A "message identifier" (5.3) is a unique identifier for an article,
usually supplied by the "posting agent" which posted it or, failing usually supplied by the "posting agent" which posted it or, failing
that, by the "injecting agent". It distinguishes the article from that, by the "injecting agent". It distinguishes the article from
every other article ever posted anywhere. Articles with the same every other article ever posted anywhere. Articles with the same
message identifier are treated as if they are the same article message identifier are treated as if they are the same article
regardless of any differences in the body or headers. regardless of any differences in the body or headers.
News Article Format June 2003
A "newsgroup" is a single news forum, a logical bulletin board, A "newsgroup" is a single news forum, a logical bulletin board,
having a name and nominally intended for articles on a specific having a name and nominally intended for articles on a specific
topic. An article is "posted to" a single newsgroup or several topic. An article is "posted to" a single newsgroup or several
newsgroups. When an article is posted to more than one newsgroup, it newsgroups. When an article is posted to more than one newsgroup, it
is said to be "crossposted"; note that this differs from posting the is said to be "crossposted"; note that this differs from posting the
same text as part of each of several articles, one per newsgroup. same text as part of each of several articles, one per newsgroup.
A newsgroup may be "moderated", in which case submissions are not A newsgroup may be "moderated", in which case submissions are not
posted directly, but mailed to a "moderator" for consideration and posted directly, but mailed to a "moderator" for consideration and
possible posting. Moderators are typically human but may be possible posting. Moderators are typically human but may be
skipping to change at page 9, line 5 skipping to change at page 8, line 44
A "reader" is the person or software reading news articles. A "reader" is the person or software reading news articles.
A "reading agent" is software which presents articles to a reader. A "reading agent" is software which presents articles to a reader.
A "followup" is an article containing a response to the contents of A "followup" is an article containing a response to the contents of
an earlier article (the followup's "precursor"). an earlier article (the followup's "precursor").
A "followup agent" is a combination of reading agent and posting A "followup agent" is a combination of reading agent and posting
agent that aids in the preparation and posting of a followup. agent that aids in the preparation and posting of a followup.
News Article Format April 2003
An (email) "address" is the mailbox [RFC 2822] (or more particularly An (email) "address" is the mailbox [RFC 2822] (or more particularly
the addr-spec within that mailbox) which directs the delivery of an the addr-spec within that mailbox) which directs the delivery of an
email to its intended recipient, who is said to "own" that address. email to its intended recipient, who is said to "own" that address.
An article's "reply address" is the address to which mailed replies An article's "reply address" is the address to which mailed replies
should be sent. This is the address specified in the article's From- should be sent. This is the address specified in the article's From-
header (5.2), unless it also has a Reply-To-header (6.1). header (5.2), unless it also has a Reply-To-header (6.1).
A "sender" is the person or software (usually, but not always, the A "sender" is the person or software (usually, but not always, the
same as the poster) responsible for the operation of the posting same as the poster) responsible for the operation of the posting
agent or, which amounts to the same thing, for passing the article to agent or, which amounts to the same thing, for passing the article to
the injecting agent. The sender is analogous to [RFC 2822]'s sender. the injecting agent. The sender is analogous to [RFC 2822]'s sender.
An "injecting agent" takes the finished article from the posting An "injecting agent" takes the finished article from the posting
agent (often via the NNTP "post" command) performs some final checks agent (often via the NNTP "post" command) performs some final checks
and passes it on to a relaying agent for general distribution. and passes it on to a relaying agent for general distribution.
News Article Format June 2003
A "relaying agent" is software which receives allegedly compliant A "relaying agent" is software which receives allegedly compliant
articles from injecting agents and/or other relaying agents, and articles from injecting agents and/or other relaying agents, and
possibly passes copies on to other relaying agents and serving possibly passes copies on to other relaying agents and serving
agents. agents.
A "news database" is the set of articles and related structural A "news database" is the set of articles and related structural
information stored by a serving agent and made available for access information stored by a serving agent and made available for access
by reading agents. by reading agents.
A "serving agent" receives an article from a relaying agent and files A "serving agent" receives an article from a relaying agent and files
skipping to change at page 10, line 5 skipping to change at page 9, line 42
and those using other formats. and those using other formats.
2.2. Textual Notations 2.2. Textual Notations
This standard contains explanatory NOTEs using the following format. This standard contains explanatory NOTEs using the following format.
These may be skipped by persons interested solely in the content of These may be skipped by persons interested solely in the content of
the specification. The purpose of the notes is to explain why choices the specification. The purpose of the notes is to explain why choices
were made, to place them in context, or to suggest possible were made, to place them in context, or to suggest possible
implementation techniques. implementation techniques.
News Article Format April 2003
NOTE: While such explanatory notes may seem superfluous in NOTE: While such explanatory notes may seem superfluous in
principle, they often help the less-than-omniscient reader grasp principle, they often help the less-than-omniscient reader grasp
the purpose of the specification and the constraints involved. the purpose of the specification and the constraints involved.
Given the limitations of natural language for descriptive Given the limitations of natural language for descriptive
purposes, this improves the probability that implementors and purposes, this improves the probability that implementors and
users will understand the true intent of the specification in users will understand the true intent of the specification in
cases where the wording is not entirely clear. cases where the wording is not entirely clear.
"US-ASCII" is short for "the ANSI X3.4 character set" [ANSI X3.4]. "US-ASCII" is short for "the ANSI X3.4 character set" [ANSI X3.4].
While "ASCII" is often misused to refer to various character sets While "ASCII" is often misused to refer to various character sets
somewhat similar to X3.4, in this standard "US-ASCII" is used to mean somewhat similar to X3.4, in this standard "US-ASCII" is used to mean
X3.4 and only X3.4. US-ASCII is a 7 bit character set. Please note X3.4 and only X3.4. US-ASCII is a 7 bit character set. Please note
that this standard requires that all agents be 8 bit clean; that is, that this standard requires that all agents be 8 bit clean; that is,
they must accept and transmit data without changing or omitting the they must accept and transmit data without changing or omitting the
8th bit. 8th bit.
Certain words, when capitalized, are used to define the significance Certain words, when capitalized, are used to define the significance
of individual requirements. The key words "MUST", "REQUIRED", of individual requirements. The key words "MUST", "REQUIRED",
"SHOULD", "RECOMMENDED", "MAY" and "OPTIONAL", and any of those words "SHOULD", "RECOMMENDED", "MAY" and "OPTIONAL", and any of those words
News Article Format June 2003
associated with the word "NOT", are to be interpreted as described in associated with the word "NOT", are to be interpreted as described in
[RFC 2119]. [RFC 2119].
In addition, the word "Ought", when applied to a poster, or to
actions of posting and similar agents which a poster may easily
override, indicates a recommendation whose violation would do no more
than breach established policy, or accepted best practice.
NOTE: The use of "MUST" or "SHOULD" implies a requirement that NOTE: The use of "MUST" or "SHOULD" implies a requirement that
would or could lead to interoperability problems if not would or could lead to interoperability problems if not
followed. Although not following an "Ought" recommendation might followed.
do no worse than cause extreme irritation to other readers,
particularly in the case of the publicly distributed Usenet,
that is no reason not to take it seriously. The essential
distinction is that enforcement of a "MUST" or "SHOULD" is a
matter of ensuring correct implementation, whereas enforcement
of an "Ought" is more a matter of sensible design or of social
pressure (whose effectiveness should not be underestimated, even
though it cannot be prescribed by this standard).
NOTE: A requirement imposed on a relaying or serving agent NOTE: A requirement imposed on a relaying or serving agent
regarding some particular article should be understood as regarding some particular article should be understood as
applying only if that article is actually accepted for applying only if that article is actually accepted for
processing (since any agent may always reject any article processing (since any agent may always reject any article
entirely, for reasons of site policy). entirely, for reasons of site policy).
Wherever the context permits, use of the masculine includes the Wherever the context permits, use of the masculine includes the
feminine and use of the singular includes the plural, and vice versa. feminine and use of the singular includes the plural, and vice versa.
Throughout this standard we will give examples of various Throughout this standard we will give examples of various
definitions, headers and other specifications. It needs to be definitions, headers and other specifications. It needs to be
remembered that these samples are for the aid of the reader only and remembered that these samples are for the aid of the reader only and
do NOT define any specification themselves. In order to prevent do NOT define any specification themselves. In order to prevent
possible conflict with "Real World" entities and people the top level possible conflict with "Real World" entities and people the top level
domain ".example" is used in all sample domains and addresses. The domain ".example" is used in all sample domains and addresses. The
News Article Format April 2003
hierarchy "example.*" is also used as a sample hierarchy. hierarchy "example.*" is also used as a sample hierarchy.
Information on the ".example" top level domain is in [RFC 2606]. Information on the ".example" top level domain is in [RFC 2606].
2.3. Relation To Email and MIME 2.3. Relation To Email and MIME
The primary intent of this standard is to describe the news article The primary intent of this standard is to describe the news article
format. Insofar as news articles are a subset of the email message format. Insofar as news articles are a subset of the email message
format augmented by some new headers, this standard incorporates many format augmented by some new headers, this standard incorporates many
(though not all) of the provisions of [RFC 2822], with the aim of (though not all) of the provisions of [RFC 2822], with the aim of
enabling news articles to pass through email systems and vice versa, enabling news articles to pass through email systems and vice versa,
provided only that they contain the minimum headers required for the provided only that they contain the minimum headers required for the
mode of transport being used. Unfortunately, the match is not mode of transport being used. Unfortunately, the match is not
perfect, but it is the intention of this standard that gateways perfect, but it is the intention of this standard that gateways
between Email and Netnews should be able to operate with the minimum between Email and Netnews should be able to operate with the minimum
of tinkering. of tinkering.
Likewise, this standard incorporates many (though not all) of the Likewise, this standard incorporates (see section 6.21) many, though
provisions of the MIME standards [RFC 2045] et seq which, though not all, of the provisions of the MIME standards [RFC 2045] et seq
designed with Email in mind, are mostly applicable to Netnews. which, though designed with Email in mind, are mostly applicable to
Netnews.
2.4. Syntax 2.4. Syntax
The complete syntax defined in this standard is repeated, for The complete syntax defined in this standard is repeated, for
convenience, in Appendix B. convenience, in Appendix B.
2.4.1. Syntax Notation 2.4.1. Syntax Notation
This standard uses the Augmented Backus Naur Form described in [RFC This standard uses the Augmented Backus Naur Form described in [RFC
2234]. 2234].
News Article Format June 2003
In particular, it makes significant use of the "incremental In particular, it makes significant use of the "incremental
alternative" feature of that notation. For example, the two rules alternative" feature of that notation. For example, the two rules
header = other-header header = other-header
header =/ Date-header header =/ Date-header
are equivalent to the single rule are equivalent to the single rule
header = other-header / Date-header header = other-header / Date-header
2.4.2. Syntax adapted from Email and MIME 2.4.2. Syntax adapted from Email and MIME
Much of the syntax of Netnews Articles is based on the corresponding Much of the syntax of Netnews Articles is based on the corresponding
syntax defined in [RFC 2822] or in the MIME specifications [RFC 2045] syntax defined in [RFC 2822]. Therefore, wherever in this standard
et seq, which are deemed to have been incorporated into this standard the syntax is stated to be taken from [RFC 2822], it is to be
as required. However, there are some differences arising from some understood, unless explicitly stated to the contrary, as the syntax
special requirements of Netnews and the fact that [RFC 2822] includes defined by [RFC 2822], but NOT including any syntax defined in
much syntax described as "obsolete" (which is excluded from this section 4 ("Obsolete syntax") of [RFC 2822]. Software compliant with
standard, as detailed below). this standard MUST NOT generate any of the syntactic forms defined in
that Obsolete Syntax, although it MAY accept such syntactic forms.
Likewise, certain syntax from the MIME specifications [RFC 2045] et
seq is also considered to have been incorporated into this standard
(see 6.21).
However, there are some differences arising from some special
requirements of Netnews, and the following syntactic rules therefore
supersede the corresponding rules given in [RFC 2822].
NOTE: Netnews parsers historically have been much less NOTE: Netnews parsers historically have been much less
permissive than Email parsers, and this is reflected in the permissive than Email parsers, and this is reflected in the
modifications referred to, and in some further specific rules. modifications referred to, and in some further specific rules.
The following syntactic rules therefore supersede the corresponding In contradistinction to [RFC 2822], an unstructured header (e.g. a
rules given in [RFC 2822] and [RFC 2045]. Subject-header) MUST contain at least one non-whitespace character
(see also remarks about empty headers in 4.2.6).
News Article Format April 2003
unstructured = 1*( [FWS] ( utext / encoded-word ) ) [FWS] unstructured = 1*( [FWS] ( utext / encoded-word ) ) [FWS]
[The one rule might not seem much of a difference, but there are likely
to be others brought into here later as part of this reorganization. So
the existing structure is left alone for now.]
Observe, in contradistinction to [RFC 2822], that an unstructured Extended-phrases (known somewhat confusingly in [RFC 2822] as obs-
header MUST contain at least one non-whitespace character (see also phrases) are introduced to allow headers such as
remarks about empty headers in 4.2.6). From: Joe Q. Public <joe@public.example>
without the necessity of using a quoted-string. They MUST be accepted
by compliant software, but they SHOULD NOT be generated until
software capable of accepting them has become widely deployed.
Wherever in this standard the syntax is stated to be taken from [RFC phrase = 1*( [CFWS] encoded-word [CFWS] / word ) /
2822], it is to be understood as the syntax defined by [RFC 2822] extended-phrase
after making the above change(s), but NOT including any syntax extended-phrase = ( [CFWS] encoded-word [CFWS] / word )
defined in section 4 ("Obsolete syntax") of [RFC 2822]. Software *( [CFWS] encoded-word [CFWS] / word /
compliant with this standard MUST NOT generate any of the syntactic [CFWS] "." [CFWS] )
forms defined in that Obsolete Syntax, although it MAY accept such [ [RFC 2822] had
syntactic forms. Certain syntax from the MIME specifications [RFC obs-phrase = word *( word / "." / CFWS )
2045] et seq is also considered a part of this standard (see 6.21). Please can Pete check that what I have is equivalent?]
News Article Format June 2003
Within a date-time, two of the obs-zones from [RFC 2822] are retained
because of current widespread usage.
zone = (( "+" / "-" ) 4DIGIT) / "UT" / "GMT"
The forms "UT" and "GMT" (indicating universal time) are to be
regarded as obsolete synonyms for "+0000". They MUST be accepted, and
passed on unchanged, by all agents, but they MUST NOT be generated as
part of new articles by posting and injecting agents.
Msg-ids are redefined to be a "normalized" subset of those defined by
[RFC 2822], ensuring that no string of characters is quoted unless
strictly necessary (it must contain at least one mqspecial) and no
single character is prefixed by a "\" in the form of a quoted-pair
unless strictly necessary, and moreover there is no possibility for
">" or WSP to occur inside a msg-id, whether quoted or not. Thus,
whereas under [RFC 2822]
<abcd@example.com>
<"abcd"@example.com>
<"ab\cd"@example.com>
would be considered semantically equivalent, only the first of them
is syntactically permitted by this standard, and hence a simple
comparison of octets will always suffice to determine the identity of
two msg-ids.
msg-id = "<" id-left "@" id-right ">"
id-left = dot-atom-text / no-fold-quote
id-right = dot-atom-text / no-fold-literal
no-fold-quote = DQUOTE
*( mqtext / "\\" / "\" DQUOTE )
mqspecial
*( mqtext / "\\" / "\" DQUOTE )
DQUOTE
mqtext = NO-WS-CTL / ; all of <text> except
%d33 / ; SP, HTAB, "\", ">"
%d35-61 / ; and DQUOTE
%d63-91 /
%d93-126
mqspecial = "(" / ")" / ; same as specials except
"<" / ; "\" and DQUOTE quoted
"[" / "]" / ; and ">" omitted
":" / ";" /
"@" / "\\" /
"," / "." /
"\" DQUOTE
no-fold-literal = "[" *( mdtext / "\[" / "\]" / "\\" ) "]"
mdtext = NO-WS-CTL / ; Non white space controls
%d33-61 / ; The rest of the US-ASCII
%d63-90 / ; characters not including
%d94-126 ; ">", "[", "]", or "\"
News Article Format June 2003
2.4.3. Syntax copied from other standards 2.4.3. Syntax copied from other standards
The following syntactic forms, taken from [RFC 2234] or from [RFC The following syntactic forms, taken from [RFC 2234] or from [RFC
2822] and adapted to incorporate variations introduced in [RFC 2047], 2822] and adapted to incorporate variations introduced in [RFC 2047],
are repeated here for convenience only: are repeated here for convenience only:
ALPHA = %x41-5A / ; A-Z ALPHA = %x41-5A / ; A-Z
%x61-7A ; a-z %x61-7A ; a-z
CR = %x0D ; carriage return CR = %x0D ; carriage return
skipping to change at page 13, line 4 skipping to change at page 13, line 39
"@" / "\" / "@" / "\" /
"," / "." / "," / "." /
DQUOTE DQUOTE
WSP = SP / HTAB ; whitespace characters WSP = SP / HTAB ; whitespace characters
FWS = ([*WSP CRLF] 1*WSP); folding whitespace FWS = ([*WSP CRLF] 1*WSP); folding whitespace
ccontent = ctext / quoted-pair / comment / encoded-word ccontent = ctext / quoted-pair / comment / encoded-word
comment = "(" *([FWS] ccontent) [FWS] ")" comment = "(" *([FWS] ccontent) [FWS] ")"
CFWS = *([FWS] comment) ( ([FWS] comment) / FWS ) CFWS = *([FWS] comment) ( ([FWS] comment) / FWS )
DQUOTE = %d34 ; quote mark DQUOTE = %d34 ; quote mark
quoted-pair = "\" text quoted-pair = "\" text
News Article Format April 2003
atext = ALPHA / DIGIT / atext = ALPHA / DIGIT /
"!" / "#" / ; Any US-ASCII character except "!" / "#" / ; Any US-ASCII character except
"$" / "%" / ; controls, SP, and specials. "$" / "%" / ; controls, SP, and specials.
"&" / "'" / ; Used for atoms "&" / "'" / ; Used for atoms
"*" / "+" / "*" / "+" /
"-" / "/" / "-" / "/" /
"=" / "?" / "=" / "?" /
"^" / "_" / "^" / "_" /
"`" / "{" / "`" / "{" /
"|" / "}" / "|" / "}" /
"~" "~"
atom = [CFWS] 1*atext [CFWS] atom = [CFWS] 1*atext [CFWS]
dot-atom = [CFWS] dot-atom-text [CFWS] dot-atom = [CFWS] dot-atom-text [CFWS]
dot-atom-text = 1*atext *( "." 1*atext ) dot-atom-text = 1*atext *( "." 1*atext )
qcontent = qtext / quoted-pair qcontent = qtext / quoted-pair
quoted-string = [CFWS] DQUOTE quoted-string = [CFWS] DQUOTE
*( [FWS] qcontent ) [FWS] *( [FWS] qcontent ) [FWS]
DQUOTE [CFWS] DQUOTE [CFWS]
word = atom / quoted-string word = atom / quoted-string
phrase = 1*( [CFWS] encoded-word [CFWS] / word )
The following are taken from [RFC 2045] and [RFC 2231] adapted to use The following are taken from [RFC 2045] and [RFC 2231] adapted to use
News Article Format June 2003
the folding syntax from [RFC 2822]: the folding syntax from [RFC 2822]:
charset = <registered character set name> charset = <registered character set name>
; [RFC 2978] ; [RFC 2978]
language = <registered language tag> language = <registered language tag>
; [RFC 3066] ; [RFC 3066]
encoded-word = "=?" charset ["*" language] "?" encoding encoded-word = "=?" charset ["*" language] "?" encoding
"?" encoded-text "?=" "?" encoded-text "?="
parameter = regular-parameter / extended-parameter parameter = regular-parameter / extended-parameter
regular-parameter = [CFWS] regular-parameter-name [CFWS] regular-parameter = [CFWS] regular-parameter-name [CFWS]
skipping to change at page 14, line 4 skipping to change at page 14, line 38
"=" extended-other-values ) "=" extended-other-values )
value = [CFWS] token [CFWS] / quoted-string value = [CFWS] token [CFWS] / quoted-string
token = 1*<any (US-ASCII) CHAR except SP, CTLs, token = 1*<any (US-ASCII) CHAR except SP, CTLs,
or tspecials> or tspecials>
NOTE: Following [RFC 2234], literal text included in the syntax NOTE: Following [RFC 2234], literal text included in the syntax
is to be regarded as case-insensitive. However, in is to be regarded as case-insensitive. However, in
contradistinction to [RFC 2822], the Netnews protocols are contradistinction to [RFC 2822], the Netnews protocols are
sensitive to case in some instances (as in newsgroup-names, some sensitive to case in some instances (as in newsgroup-names, some
header parameters, etc.). Care has been taken to indicate this header parameters, etc.). Care has been taken to indicate this
News Article Format April 2003
explicitly where required. explicitly where required.
As in [RFC 2822], where any quoted-pair appears it is to be As in [RFC 2822], where any quoted-pair appears it is to be
interpreted as its text character alone. That is to say, the "\" interpreted as its text character alone. That is to say, the "\"
character that appears as part of a quoted-pair is semantically character that appears as part of a quoted-pair is semantically
"invisible". "invisible".
Again, as in [RFC 2822], strings of characters that include Again, as in [RFC 2822], strings of characters that include
characters not syntactically allowed in some particular context may characters not syntactically allowed in some particular context may
be incorporated into a quoted-string by "encapsulating" them between be incorporated into a quoted-string by "encapsulating" them between
skipping to change at page 14, line 28 skipping to change at page 15, line 5
as to form a quoted-pair, and possibly introducing folding by as to form a quoted-pair, and possibly introducing folding by
prefixing some WSP with CRLF. prefixing some WSP with CRLF.
The semantic value of a quoted-string (i.e. the result of reversing The semantic value of a quoted-string (i.e. the result of reversing
the encapsulation) is a string of characters which includes neither the encapsulation) is a string of characters which includes neither
the optional CFWS outside of the quote characters, nor the quote the optional CFWS outside of the quote characters, nor the quote
characters themselves, nor any CRLF contained within any FWS between characters themselves, nor any CRLF contained within any FWS between
the two quote characters, nor the "\" which introduces any quoted- the two quote characters, nor the "\" which introduces any quoted-
pair. pair.
News Article Format June 2003
For the purposes of section 5 of [RFC 2047] all headers (4.1) defined For the purposes of section 5 of [RFC 2047] all headers (4.1) defined
in this standard are to be considered as "extension message header in this standard are to be considered as "extension message header
fields" (insofar as they are not already so considered under the fields" (insofar as they are not already so considered under the
existing Email standards), permitting the use of [RFC 2047] encodings existing Email standards), permitting the use of [RFC 2047] encodings
within any unstructured header, or within any comment or phrase within any unstructured header, or within any comment or phrase
permitted within any structured header. The syntax of encoded-text permitted within any structured header.
and of encoding can be found in [RFC 2047], and there are
restrictions on the characters that may occur within an encoded-text, The syntax of encoded-text and of encoding can be found in [RFC
depending on its context. These restrictions MUST be observed, as 2047], and there are restrictions on the characters that may occur
must the restrictions on the overall length of an encoded-word. within an encoded-text, depending on its context. There are also
restrictions on the overall length of an encoded-word and of headers
containing encoded-words and requirements for encoded-words to have
FWS on either side of them in most contexts. All these restrictions
and requirements MUST be observed.
2.5. Language 2.5. Language
Various constant strings in this standard, such as header names and Various constant strings in this standard, such as header-names and
month names, are derived from English words. Despite their month names, are derived from English words. Despite their
derivation, these words do NOT change when the poster or reader derivation, these words do NOT change when the poster or reader
employing them is interacting in a language other than English. employing them is interacting in a language other than English.
Posting and reading agents MAY translate as appropriate in their Posting and reading agents MAY translate as appropriate in their
interaction with the poster or reader, but the forms that actually interaction with the poster or reader, but the forms that actually
appear in articles as transmitted MUST be the English-derived ones appear in articles as transmitted MUST be the English-derived ones
defined in this standard. defined in this standard.
3. Changes to the existing protocols 3. Changes to the existing protocols
This standard prescribes many changes, clarifications and new This standard prescribes many changes, clarifications and new
features since the protocols described in [RFC 1036] and [Son-of- features since the protocols described in [RFC 1036] and [Son-of-
1036]. It is the intention that they can be assimilated into Usenet 1036]. It is the intention that they can be assimilated into Usenet
as it presently operates without major interruption to the service, as it presently operates without major interruption to the service,
though some of the new features may not begin to show benefit until though some of the new features may not begin to show benefit until
they become widely implemented. This section summarizes the main they become widely implemented. This section summarizes the main
changes, and comments on some features of the transition. changes, and comments on some features of the transition.
News Article Format April 2003
3.1. Principal Changes 3.1. Principal Changes
o The [RFC 2822] conventions for parenthesis-enclosed comments in o The [RFC 2822] conventions for parenthesis-enclosed comments in
headers are supported. headers are supported.
o Whitespace is permitted in Newsgroups-headers, permitting folding o Whitespace is permitted in Newsgroups-headers, permitting folding
of such headers. Indeed, all headers can now be folded. of such headers. Indeed, all headers can now be folded.
o An enhanced syntax for the Path-header enables the injection o An enhanced syntax for the Path-header enables the injection
point of and the route taken by an article to be determined with point of and the route taken by an article to be determined with
certainty. certainty.
o Large parts of MIME are recognized as an integral part of o Large parts of MIME are recognized as an integral part of
Netnews. Netnews.
o There is a new Control message 'mvgroup' to facilitate moving a o There is a new Control message 'mvgroup' to facilitate moving a
group to a different place (name) in a hierarchy. group to a different place (name) in a hierarchy.
o There are several new headers defined, notably Archive, o There are several new headers defined, notably Archive,
Complaints-To, Injector-Info, Mail-Copies-To, Posted-And-Mailed Complaints-To, Injector-Info, Mail-Copies-To, Posted-And-Mailed
and User-Agent, leading to increased functionality. and User-Agent, leading to increased functionality.
o Provision has been made for almost all headers to have MIME-style o Provision has been made for almost all headers to have MIME-style
parameters (to be ignored if not recognized), thus facilitating parameters (to be ignored if not recognized), thus facilitating
News Article Format June 2003
extension of those headers in future standards. extension of those headers in future standards.
o Certain headers and Control messages (Appendix A.3 and Appendix o Certain headers and Control messages (Appendix A.3 and Appendix
A.4) have been made obsolete. A.4) have been made obsolete.
o Distributions are expected to be checked at the receiving end, as o Distributions are expected to be checked at the receiving end, as
well as the sending end, of a relaying link. well as the sending end, of a relaying link.
o There are numerous other small changes, clarifications and o There are numerous other small changes, clarifications and
enhancements. enhancements.
3.2. Transitional Arrangements 3.2. Transitional Arrangements
skipping to change at page 16, line 4 skipping to change at page 16, line 42
implications for both kinds of agent. implications for both kinds of agent.
o [RFC 2822] style comments in headers do not affect serving and o [RFC 2822] style comments in headers do not affect serving and
relaying agents (note that the Message-ID-, Newsgroups-, relaying agents (note that the Message-ID-, Newsgroups-,
Distribution- and Path-headers do not contain them). They are Distribution- and Path-headers do not contain them). They are
unlikely to hinder their proper display in existing reading unlikely to hinder their proper display in existing reading
agents except in the case of the References-header in agents agents except in the case of the References-header in agents
which thread articles. Therefore, it is provided that they SHOULD which thread articles. Therefore, it is provided that they SHOULD
NOT be generated except where permitted by the previous NOT be generated except where permitted by the previous
standards. standards.
News Article Format April 2003
o Because of its importance to all serving agents, the extension o Because of its importance to all serving agents, the extension
permitting whitespace and folding in Newsgroups-headers SHOULD permitting whitespace and folding in Newsgroups-headers SHOULD
NOT be used until it has been widely deployed amongst relaying NOT be used until it has been widely deployed amongst relaying
agents. User agents are unaffected. agents. User agents are unaffected.
o The new style of Path-header is already consistent with the o The new style of Path-header is already consistent with the
previous standards. However, the intention is that relaying previous standards. However, the intention is that relaying
agents should eventually reject articles in the old style, and so agents should eventually reject articles in the old style, and so
this possibility should be offered as a configurable option in this possibility should be offered as a configurable option in
relaying agents. User agents are unaffected. relaying agents. User agents are unaffected.
o The introduction of MIME reflects a practice that is already o The introduction of MIME reflects a practice that is already
widespread. Articles in strict compliance with the previous widespread. Articles in strict compliance with the previous
standards (using strict US-ASCII) will be unaffected. Many user standards (using strict US-ASCII) will be unaffected. Many user
agents already support it, at least to the extent of widely used agents already support it, at least to the extent of widely used
charsets such as ISO-8859-1. Users expecting to read articles charsets such as ISO-8859-1. Users expecting to read articles
using other charsets will need to acquire suitable reading using other charsets will need to acquire suitable reading
agents. It is not intended, in general, that any single user agents. It is not intended, in general, that any single user
agent will be able to display every charset known to IANA, but agent will be able to display every charset known to IANA, but
all such agents MUST support US-ASCII. Serving and relaying all such agents MUST support US-ASCII. Serving and relaying
News Article Format June 2003
agents are not affected. agents are not affected.
o The new Control: mvgroup command will need to be implemented in o The new Control: mvgroup command will need to be implemented in
serving agents. For the benefit of older serving agents it is serving agents. For the benefit of older serving agents it is
therefore RECOMMENDED that it be followed shortly by a therefore RECOMMENDED that it be followed shortly by a
corresponding newgroup command and it MUST always be followed by corresponding newgroup command and it MUST always be followed by
a rmgroup command for the old group after a reasonable overlap a rmgroup command for the old group after a reasonable overlap
period. An implementation of the mvgroup command as an alias for period. An implementation of the mvgroup command as an alias for
the newgroup command would thus be minimally conforming. User the newgroup command would thus be minimally conforming. User
agents are unaffected. agents are unaffected.
o All the headers newly introduced by this standard can safely be o All the headers newly introduced by this standard can safely be
skipping to change at page 16, line 58 skipping to change at page 17, line 39
name-character = ALPHA / DIGIT name-character = ALPHA / DIGIT
other-content = <the content of a header defined by some other-content = <the content of a header defined by some
other standard> other standard>
separator = CRLF separator = CRLF
body = *( *998text CRLF ) body = *( *998text CRLF )
However, the rule given above for header is incomplete. Further However, the rule given above for header is incomplete. Further
alternatives will be added incrementally as the various Netnews alternatives will be added incrementally as the various Netnews
headers are introduced in this standard (or in future extensions), headers are introduced in this standard (or in future extensions),
using the "=/" notation defined in [RFC 2234]. For example, a using the "=/" notation defined in [RFC 2234]. For example, a
typical USENET-header would be defined as follows: typical Usenet-header would be defined as follows:
News Article Format April 2003
header =/ USENET-header header =/ Usenet-header
USENET-header = "USENET" ":" SP USENET-content Usenet-header = "Usenet" ":" SP Usenet-content
*( ";" ( USENET-parameter / *( ";" ( Usenet-parameter /
extension-parameter ) ) extension-parameter ) )
USENET-content = <syntax specific to that USENET-header> Usenet-content = <syntax specific to that Usenet-header>
USENET-parameter = <a parameter specific to that USENET-header> Usenet-parameter = <a parameter specific to that Usenet-header>
where the USENET-parameter, which MUST always be of the same where the Usenet-parameter, which MUST always be of the same
syntactic form as an extension-parameter (see below), is not provided syntactic form as a parameter, is not provided in all headers, and
in all headers, and even the extension-parameter is omitted in some even the extension-parameter is omitted in some cases (see 4.2.2).
cases (see 4.2.2). Observe that "USENET" is (and MUST be) of the Observe that "Usenet" is (and MUST be) of the syntactic form of a
syntactic form of a header-name. header-name.
extension-parameter= <a parameter not defined by this standard> extension-parameter
= <a parameter not defined by this standard>
x-attribute = "x-" attribute x-attribute = "x-" attribute
News Article Format June 2003
An article consists of some headers followed by a body. An empty line An article consists of some headers followed by a body. An empty line
separates the two. The headers contain structured information about separates the two. The headers contain structured information about
the article and its transmission. A header begins with a header-name the article and its transmission. A header begins with a header-name
identifying it, and can be continued onto subsequent lines as identifying it, and can be continued onto subsequent lines as
described in section 4.2.3. The body is largely unstructured text described in section 4.2.3. The body is largely unstructured text
significant only to the poster and the readers. significant only to the poster and the readers.
NOTE: Terminology here follows the current custom in the news NOTE: Terminology here follows the current custom in the news
community, rather than the [RFC 2822] convention of referring to community, rather than the [RFC 2822] convention of referring to
skipping to change at page 18, line 5 skipping to change at page 18, line 44
extensions. Relaying agents MUST NOT change the order of the headers extensions. Relaying agents MUST NOT change the order of the headers
in an article. in an article.
4.2.1. Naming of Headers 4.2.1. Naming of Headers
Despite the restrictions on header-name syntax imposed by the Despite the restrictions on header-name syntax imposed by the
grammar, relaying, serving and reading agents SHOULD tolerate grammar, relaying, serving and reading agents SHOULD tolerate
header-names containing any US-ASCII printable character other than header-names containing any US-ASCII printable character other than
colon (":", US-ASCII 58). colon (":", US-ASCII 58).
News Article Format April 2003
Whilst relaying agents MUST accept, and pass on unaltered, any non- Whilst relaying agents MUST accept, and pass on unaltered, any non-
variant header whose header-name is syntactically correct, and variant header whose header-name is syntactically correct, and
reading agents MUST enable them to be displayed, at least optionally, reading agents MUST enable them to be displayed, at least optionally,
posting and injecting agents SHOULD NOT generate headers other than posting and injecting agents SHOULD NOT generate headers other than
o headers established by this standard or any extension to it; o headers established by this standard or any extension to it;
o those recognized by other IETF-established standards, notably the o those recognized by other IETF-established standards, notably the
Email standard [RFC 2822] and its extensions, excluding any Email standard [RFC 2822] and its extensions, excluding any
explicitly deprecated for Netnews (e.g. see section 9.2.1 for the explicitly deprecated for Netnews (e.g. see section 9.2.1 for the
deprecated Disposition-Notification-To-header); or, deprecated Disposition-Notification-To-header); or,
alternatively, those listed in some future IANA registry of alternatively, those listed in some future IANA registry of
recognized headers; recognized headers;
o experimental headers beginning with "X-" (as defined in 4.2.5.1); o experimental headers beginning with "X-" (as defined in 4.2.5.1);
o on a provisional basis only, headers related to new protocols o on a provisional basis only, headers related to new protocols
under development which are the subject of (or intended to be the under development which are the subject of (or intended to be the
subject of) some IETF-approved RFC (whether Informational, subject of) some IETF-approved RFC (whether Informational,
Experimental or Standards-Track). Experimental or Standards-Track).
News Article Format June 2003
However, software SHOULD NOT attempt to interpret headers not However, software SHOULD NOT attempt to interpret headers not
specifically intended to be meaningful in the Netnews environment. specifically intended to be meaningful in the Netnews environment.
[However, if [KLYNE], which defines an IANA registry of recognized [However, if [KLYNE], which defines an IANA registry of recognized
headers, becomes accepted before we are done (which is likely), then headers, becomes accepted before we are done (which is likely), then
that paragraph can be simplified very considerably.] that paragraph can be simplified very considerably.]
Header-names are case-insensitive. There is a preferred case Header-names are case-insensitive. There is a preferred case
convention, which posters and posting agents Ought to use: each convention set out in [USEAGE], and which is used in the various
hyphen-separated "word" has its initial letter (if any) in uppercase rules defining headers in this standard. Relaying and reading agents
and the rest in lowercase, except that some abbreviations have all MUST, however, tolerate header-names in any case.
letters uppercase (e.g. "Message-ID" and "MIME-Version"). The forms
given in the various rules defining headers in this standard are the
preferred forms for them. Relaying and reading agents MUST, however,
tolerate articles not obeying this convention.
4.2.2. MIME-style Parameters 4.2.2. MIME-style Parameters
A few header-specific MIME-style parameters are defined in this A few header-specific MIME-style parameters are defined in this
standard, but there is also provision for generic extension- standard, but there is also provision for generic extension-
parameters to appear in most headers for the purpose of allowing parameters to appear in most headers for the purpose of allowing
future extensions to those headers. Observe that such parameters do future extensions to those headers. Observe that such parameters do
not, in general, occur in headers defined in other standards, except not, in general, occur in headers defined in other standards, except
for the MIME standards [RFC 2045] et seq. and their extensions. for the MIME standards [RFC 2045] et seq. and their extensions.
skipping to change at page 19, line 4 skipping to change at page 19, line 41
development which are the subject of (or intended to be the subject development which are the subject of (or intended to be the subject
of) some such IETF-approved RFC. They MUST ONLY be defined for use in of) some such IETF-approved RFC. They MUST ONLY be defined for use in
those headers where the syntax of this standard so allows. They those headers where the syntax of this standard so allows. They
SHOULD NOT, at present, be defined for use in headers in widespread SHOULD NOT, at present, be defined for use in headers in widespread
use prior to the introduction of this standard (this restriction is use prior to the introduction of this standard (this restriction is
likely to be removed in a future version of this standard). likely to be removed in a future version of this standard).
Nevertheless, compliant software MUST accept such parameters wherever Nevertheless, compliant software MUST accept such parameters wherever
syntactically allowed in this standard (ignoring them if their syntactically allowed in this standard (ignoring them if their
meaning is unknown) and SHOULD accept (and ignore) them in all meaning is unknown) and SHOULD accept (and ignore) them in all
structured headers wherever defined. structured headers wherever defined.
News Article Format April 2003
[We could go further, and establish an IANA registry for these [We could go further, and establish an IANA registry for these
parameters, preloaded with the ones already defined in this standard. A parameters, preloaded with the ones already defined in this standard. A
good model for setting up such a registry is to be found in RFC 2183 good model for setting up such a registry is to be found in RFC 2183
(Content-Disposition).] (Content-Disposition).]
NOTE: The syntax does not permit extension-parameters in NOTE: The syntax does not permit extension-parameters in
unstructured headers (where they are unnecessary) or in certain unstructured headers (where they are unnecessary) or in certain
headers (notably the Date-, From-, Message-ID-, Reply-To-, headers (notably the Date-, From-, Message-ID-, Reply-To-,
Sender-, Keywords-, Mail-Copies-To-, References-, Supersedes- Sender-, Keywords-, Mail-Copies-To-, References-, Supersedes-
and Complaints-To-headers) which are the same (or similar to) and Complaints-To-headers) which are the same (or similar to)
skipping to change at page 19, line 28 skipping to change at page 20, line 5
Each header-specific MIME-style parameter introduced in this standard Each header-specific MIME-style parameter introduced in this standard
is described by specifying is described by specifying
(a) its attribute, and (a) its attribute, and
(b) the syntax rule(s) defining the object(s) permitted in its (b) the syntax rule(s) defining the object(s) permitted in its
value. value.
Any parameter, or set of parameters with numbered sections, which, Any parameter, or set of parameters with numbered sections, which,
according to [RFC 2231], is semantically equivalent to an unnumbered according to [RFC 2231], is semantically equivalent to an unnumbered
regular-parameter with that attribute and value may be used. regular-parameter with that attribute and value may be used.
News Article Format June 2003
NOTE: If the value is not of the syntactic form of a token and NOTE: If the value is not of the syntactic form of a token and
is not encoded as an extended-value, it is necessary to is not encoded as an extended-value, it is necessary to
encapsulate it within a quoted-string (see 2.4.3). Observe that encapsulate it within a quoted-string (see 2.4.3). Observe that
the syntax of a parameter also allows additional WSP, folding the syntax of a parameter also allows additional WSP, folding
and comments. and comments.
The semantics of a parameter is always to associate its attribute The semantics of a parameter is always to associate its attribute
with the object represented by the token, or the semantic value with the object represented by the token, or the semantic value
(2.4.3) of the quoted-string, contained in its value. (2.4.3) of the quoted-string, contained in its value.
skipping to change at page 20, line 4 skipping to change at page 20, line 40
Each header is logically a single line of characters comprising the Each header is logically a single line of characters comprising the
header-name, the colon with its following SP, the content, and any header-name, the colon with its following SP, the content, and any
parameters. For convenience, however, the content and parameters can parameters. For convenience, however, the content and parameters can
be "folded" into a multiple line representation by inserting a CRLF be "folded" into a multiple line representation by inserting a CRLF
before any WSP contained within any FWS or CFWS (but not any other SP before any WSP contained within any FWS or CFWS (but not any other SP
or HTAB) allowed by this standard. For example, the header: or HTAB) allowed by this standard. For example, the header:
Approved: modname@modsite.example (Moderator of example.foo.bar) Approved: modname@modsite.example (Moderator of example.foo.bar)
can be represented as: can be represented as:
Approved: modname@modsite.example Approved: modname@modsite.example
(Moderator of example.foo.bar) (Moderator of example.foo.bar)
News Article Format April 2003
FWS occurs at many places in the syntax (usually within a CFWS) in FWS occurs at many places in the syntax (usually within a CFWS) in
order to allow the inclusion of comments, whitespace and folding. The order to allow the inclusion of comments, whitespace and folding. The
syntax is in fact ambiguous insofar as it sometimes allows two syntax is in fact ambiguous insofar as it sometimes allows two
consecutive instantiations of FWS (as least one of which is always consecutive instantiations of FWS (as least one of which is always
optional), or of an optional FWS followed by an explicit CRLF. optional), or of an optional FWS followed by an explicit CRLF.
However, all such cases MUST be treated as if the optional However, all such cases MUST be treated as if the optional
instantiation (or one of them) had not been allowed. It is thus instantiation (or one of them) had not been allowed. It is thus
precluded that any line of a header should be made up of whitespace precluded that any line of a header should be made up of whitespace
characters and nothing else (for such a line might otherwise have characters and nothing else (for such a line might otherwise have
been interpreted by a non-compliant agent as the separator between been interpreted by a non-compliant agent as the separator between
the headers and the body of the article). the headers and the body of the article).
NOTE: This does not lead to semantic ambiguity because, unless NOTE: This does not lead to semantic ambiguity because, unless
specifically stated otherwise, the presence or absence of specifically stated otherwise, the presence or absence of
folding, a comment or additional WSP has no semantic meaning folding, a comment or additional WSP has no semantic meaning
and, in particular, it is a matter of indifference whether it and, in particular, it is a matter of indifference whether it
forms a part of the syntactic construct preceding it or the one forms a part of the syntactic construct preceding it or the one
following it. following it.
News Article Format June 2003
NOTE: It may be observed that the content part of every header NOTE: It may be observed that the content part of every header
begins and ends with an optional CFWS (or FWS in the case of a begins and ends with an optional CFWS (or FWS in the case of a
few headers). Moreover, every parameter also begins and ends few headers). Moreover, every parameter also begins and ends
with an optional CFWS. with an optional CFWS.
NOTE: Although contents are defined in such a way that folding
can take place between many of the lexical tokens (and even
within some of them), folding should be limited to placing the
CRLF at higher-level syntactic breaks, and should also avoid
leaving trailing WSP on the preceding line. For instance, if a
header-content is defined as comma-separated values, it is
recommended that folding occur after the comma separating the
values, even if it is allowed elsewhere.
In accordance with the syntax, the header-name on the first line MUST In accordance with the syntax, the header-name on the first line MUST
be followed by a SP (even if the rest of the header is empty, but see be followed by a SP (even if the rest of the header is empty, but see
4.2.6). Even though the syntax allows otherwise, at least some of 4.2.6). Even though the syntax allows otherwise, at least some of
the content MUST appear on that first line (to avoid the possibility the content MUST appear on that first line (to avoid the possibility
of harm by any non-compliant agent that might eliminate a trailing of harm by any non-compliant agent that might eliminate a trailing
WSP). Although posting agents are REQUIRED to enforce these WSP). Although posting agents are REQUIRED to enforce these
restrictions, relaying and serving agents SHOULD accept articles that restrictions, relaying and serving agents SHOULD accept articles that
violate them. violate them.
NOTE: This standard differs from [RFC 2822] in requiring that SP NOTE: This standard differs from [RFC 2822] in requiring that SP
following the colon (it was also an [RFC 1036] requirement). following the colon (it was also an [RFC 1036] requirement).
Posters and posting agents SHOULD use SP, not HTAB, where white space Posters and posting agents SHOULD use SP, not HTAB, where white space
is desired in headers (some existing software expects this). Relaying is desired in headers (some existing software expects this). Relaying
and serving agents SHOULD accept HTAB in all such cases, however. and serving agents SHOULD accept HTAB in all such cases, however.
Relaying and serving agents MUST NOT refold headers (i.e. they must
pass on the folding as received).
4.2.4. Comments 4.2.4. Comments
Strings of characters which are treated as comments may be included Strings of characters which are treated as comments may be included
in headers wherever the syntactic element CFWS occurs. They consist in headers wherever the syntactic element CFWS occurs. They consist
of characters enclosed in parentheses. Comments may be nested. of characters enclosed in parentheses. Comments may be nested.
News Article Format April 2003
NOTE: Although CFWS occurs wherever whitespace is allowed in NOTE: Although CFWS occurs wherever whitespace is allowed in
almost all headers, there are exceptions where only FWS is almost all headers, there are exceptions where only FWS is
permitted (hence folding but no comments). Notably, this happens permitted (hence folding but no comments). Notably, this happens
in the case of the Message-ID-, Newsgroups-, Distribution-, in the case of the Message-ID-, Newsgroups-, Distribution-,
Path- and Followup-To-headers, and within the Date-header except Path- and Followup-To-headers, and within the Date-header except
right at the end. right at the end.
A comment is normally used to provide some human readable
informational text, except at the end of a mailbox which contains no
phrase, as in
fred@foo.bar.example (Fred Bloggs)
as opposed to
"Fred Bloggs" <fred@foo.bar.example> .
The former is a deprecated, but commonly encountered, usage and
reading agents SHOULD take special note of such comments as
indicating the name of the person whose mailbox it is. In all other
situations a comment is semantically interpreted as a single SP.
Since a comment is allowed to contain FWS, folding is permitted Since a comment is allowed to contain FWS, folding is permitted
within it as well as immediately preceding and immediately following within it as well as immediately preceding and immediately following
it. Also note that, since quoted-pair is allowed in a comment, the it. Also note that, since quoted-pair is allowed in a comment, the
parenthesis and backslash characters may appear in a comment so long parenthesis and backslash characters may appear in a comment so long
as they appear as a quoted-pair. Semantically, the enclosing as they appear as a quoted-pair. Semantically, the enclosing
parentheses are not part of the content of the comment; the content parentheses are not part of the content of the comment; the content
is what is contained between the two parentheses. is what is contained between the two parentheses.
Since comments have not hitherto been permitted in news articles, Since comments have not hitherto been permitted in news articles,
except in a few specified places, posters and posting-agents SHOULD except in a few specified places, posters and posting-agents SHOULD
NOT insert them except in those places, namely following addresses in NOT insert them except in those places, namely following mailboxes in
From and similar headers, and to indicate the name of the timezone in From and similar headers (a now deprecated convention for indicating
Date-headers. However, compliant software MUST accept them in all the owner of that mailbox), and to indicate the name of the timezone
in Date-headers. However, compliant software MUST accept them in all
places where they are syntactically allowed. places where they are syntactically allowed.
News Article Format June 2003
4.2.5. Header Properties 4.2.5. Header Properties
There are three special properties that may apply to particular There are three special properties that may apply to particular
headers, namely: "experimental", "inheritable", and "variant". When a headers, namely: "experimental", "inheritable", and "variant". When a
header is defined, in this (or any future) standard, as having one header is defined, in this (or any future) standard, as having one
(or possibly more) of these properties, it is subject to special (or possibly more) of these properties, it is subject to special
treatment, as indicated below. treatment, as indicated below.
4.2.5.1. Experimental Headers 4.2.5.1. Experimental Headers
skipping to change at page 22, line 5 skipping to change at page 22, line 28
They are to be used for experimental Netnews features, or for They are to be used for experimental Netnews features, or for
enabling additional material to be propagated with an article. They enabling additional material to be propagated with an article. They
are not (and will not be) defined by this, or any, standard. are not (and will not be) defined by this, or any, standard.
NOTE: Experimental headers are suitable for situations where NOTE: Experimental headers are suitable for situations where
they need only to be human readable. They are not intended to be they need only to be human readable. They are not intended to be
recognized by widely deployed Netnews software and, should such recognized by widely deployed Netnews software and, should such
a requirement be envisaged, it is preferable to use a normal a requirement be envisaged, it is preferable to use a normal
header on the provisional basis set out in section 4.2.1. header on the provisional basis set out in section 4.2.1.
News Article Format April 2003
4.2.5.2. Inheritable Headers 4.2.5.2. Inheritable Headers
Subject only to the overriding ability of the poster to determine the Subject only to the overriding ability of the poster to determine the
contents of the headers in a proto-article, headers with the contents of the headers in a proto-article, headers with the
inheritable property MUST be copied by followup agents (perhaps with inheritable property MUST be copied by followup agents (perhaps with
some modification) into the followup article, and headers without some modification) into the followup article, and headers without
that property MUST NOT be so copied. Examples include: that property MUST NOT be so copied. Examples include:
o Newsgroups (5.5) - copied from the precursor, subject to any o Newsgroups (5.5) - copied from the precursor, subject to any
Followup-To-header. Followup-To-header.
o Subject (5.4) - modified by prefixing with "Re: ", but otherwise o Subject (5.4) - modified by prefixing with "Re: ", but otherwise
skipping to change at page 22, line 40 skipping to change at page 23, line 4
absence) MUST be as specified in this (or any future) standard. absence) MUST be as specified in this (or any future) standard.
Typically, these headers are modified as articles are propagated, or Typically, these headers are modified as articles are propagated, or
they reflect the status of the article on a particular serving agent, they reflect the status of the article on a particular serving agent,
or cooperating group of such agents. The variant header MAY be placed or cooperating group of such agents. The variant header MAY be placed
anywhere within the headers (though placing it first is recommended). anywhere within the headers (though placing it first is recommended).
The principal examples are: The principal examples are:
o Path (5.6) - augmented at each relaying agent that an article o Path (5.6) - augmented at each relaying agent that an article
passes through. passes through.
o Xref (6.16) - used to keep track of the article locators of o Xref (6.16) - used to keep track of the article locators of
crossposted articles so that newsreaders serviced by a particular crossposted articles so that newsreaders serviced by a particular
News Article Format June 2003
serving agent can mark such articles as read. serving agent can mark such articles as read.
4.2.6. Undesirable Headers 4.2.6. Undesirable Headers
A header whose content is empty is said to be an empty header (in A header whose content is empty is said to be an empty header (in
fact, no such headers are defined by this standard). Relaying and fact, no such headers are defined by this standard). Relaying and
reading agents SHOULD NOT consider presence or absence of an empty reading agents SHOULD NOT consider presence or absence of an empty
header to alter the semantics of an article (although syntactic header to alter the semantics of an article (although syntactic
rules, such as requirements that certain header-names appear at most rules, such as requirements that certain header-names appear at most
once, MUST still be satisfied). Posting and injecting agents SHOULD once, MUST still be satisfied). Posting and injecting agents SHOULD
delete empty headers from articles before posting them; relaying delete empty headers from articles before posting them; relaying
agents MUST pass them untouched. agents MUST pass them untouched.
Headers that merely state defaults explicitly (e.g., a Followup-To-
header with the same content as the Newsgroups-header, or a MIME
Content-Type-header with contents "text/plain; charset=us-ascii") or
state information that reading agents can typically determine easily
themselves (e.g. the length of the body in octets) are redundant and
posters and posting agents Ought Not to include them.
News Article Format April 2003
4.3. Body 4.3. Body
4.3.1. Body Format Issues 4.3.1. Body Format Issues
The body of an article SHOULD NOT be empty. A posting or injecting The body of an article SHOULD NOT be empty. A posting or injecting
agent which does not reject such an article entirely SHOULD at least agent which does not reject such an article entirely SHOULD at least
issue a warning message to the poster and supply a non-empty body. issue a warning message to the poster and supply a non-empty body.
Note that the separator line MUST be present even if the body is Note that the separator line MUST be present even if the body is
empty. empty.
skipping to change at page 23, line 31 skipping to change at page 23, line 43
traditionally been used in this situation. traditionally been used in this situation.
Note that an article body is a sequence of lines terminated by CRLFs, Note that an article body is a sequence of lines terminated by CRLFs,
not arbitrary binary data, and in particular it MUST end with a CRLF. not arbitrary binary data, and in particular it MUST end with a CRLF.
However, relaying and serving agents SHOULD treat the body of an However, relaying and serving agents SHOULD treat the body of an
article as an uninterpreted sequence of octets (except as mandated by article as an uninterpreted sequence of octets (except as mandated by
changes of CRLF representation and by control message processing, as changes of CRLF representation and by control message processing, as
in 7.2.4) and SHOULD avoid imposing constraints on it. See also in 7.2.4) and SHOULD avoid imposing constraints on it. See also
section 4.5. section 4.5.
Posters SHOULD avoid using control characters and escape sequences
except for tab (US-ASCII 9), formfeed (US-ASCII 12) and, possibly,
backspace (US-ASCII 8). Tab signifies sufficient horizontal white
space to reach the next of a set of fixed positions; posters are
warned that there is no standard set of positions, so tabs should be
avoided if precise spacing is essential. Formfeed (which is sometimes
referred to as the "spoiler character") signifies a point at which a
reading agent Ought to pause and await reader interaction before
displaying further text.
NOTE: Passing other control characters or escape sequences
unaltered to a display or printing device is likely to have
unpredictable results, except in the case of a device adapted to
the special needs of some particular character set.
NOTE: Backspace was historically used for underlining, done by
an underscore (US-ASCII 95), a backspace, and a character,
repeated for each character that should be underlined. Posters
are warned that underlining is not available on all output
devices or supported by all reading agents and is best not
relied on for essential meaning.
4.3.2. Body Conventions 4.3.2. Body Conventions
A body is by default an uninterpreted sequence of octets for most of A body is by default an uninterpreted sequence of octets for most of
the purposes of this standard. However, a MIME Content-Type-header the purposes of this standard. However, a MIME Content-Type-header
may impose some structure or intended interpretation upon it, and may may impose some structure or intended interpretation upon it, and may
also specify the character set in accordance with which the octets also specify the character set in accordance with which the octets
are to be interpreted. are to be interpreted.
News Article Format April 2003
The following conventions for quotations, attributions and
signatures, although not mandated by this standard, describe widely
used practices. They are documented here in order to establish their
correct usage, and the use of the words "MUST", "SHOULD", etc. is to
be understood in that context.
It is conventional for followup agents to enable the incorporation of
the followed-up article (the "precursor") as a quotation. This SHOULD
be done by prefacing each line of the quoted text (even if it is
empty) with the character ">" (or perhaps with "> " in the case of a
previously unquoted line). This will result in multiple levels of ">"
when quoted content itself contains quoted content, and it will also
facilitate the automatic analysis of articles.
NOTE: Posters should edit quoted context to trim it down to the
minimum necessary. However, followup agents Ought Not to attempt
to enforce this beyond issuing a warning (past attempts to do so
have been found to be notably counter-productive).
The followup agent SHOULD also precede the quoted content by an
"attribution line" (however, readers are warned not to assume that
they are accurate, especially within multiply nested quotations). The
following convention for such lines is intended to facilitate their
automatic recognition and processing by sophisticated reading agents.
The attribution SHOULD contain the name and/or the email address of
the precursor's poster, as in
Joe D. Bloggs <jdbloggs@foo.example> wrote:
or
Helmut Schmidt <helmut@bar.example> schrieb:
The attribution MAY contain also a single newsgroup-name (the one
from which the followup is being made), the precursor's Message-ID
and/or the precursor's Date and Time. Any of these that are present,
SHOULD precede the name and/or email address. However, the inclusion
or not of such fields Ought always to be under the control of the
poster.
To enable this line, and the Message-ID and the email address within
it, to be recognized (for example to enable suitable reading agents
to retrieve the precursor or email its poster by clicking on them),
the following conventions SHOULD be observed:
o The precursor's Message-ID SHOULD be enclosed within <...> or
<news:...>
o The precursor's poster's email address SHOULD be enclosed within
<...>
o The various fields may be separated by arbitrary text and they
may be folded in the same way as headers, but attributions SHOULD
always be terminated by a ":" followed by CRLF.
Further examples:
On comp.foo in <1234@bar.example> on 24 Dec 2001 16:40:20 +0000,
Joe D. Bloggs <jdbloggs@bar.example> wrote:
News Article Format April 2003
Am 24. Dez 2001 schrieb Helmut Schmidt <helmut@bar.example>:
A "personal signature" is a short closing text automatically added to
the end of articles by posting agents, identifying the poster and
giving his network addresses, etc. Whenever a poster or posting agent
appends such a signature to an article, it MUST be preceded with a
delimiter line containing (only) two hyphens (US-ASCII 45) followed
by one SP (US-ASCII 32). The signature is considered to extend from
the last occurrence of that delimiter up to the end of the article
(or up to the end of the part in the case of a multipart MIME body).
Followup agents, when incorporating quoted text from a precursor,
Ought Not to include the signature in the quotation. Posting agents
Ought to discourage (at least with a warning) signatures of excessive
length (4 lines is a commonly accepted limit).
4.4. Characters and Character Sets 4.4. Characters and Character Sets
Transmission paths for news articles MUST treat news articles as Transmission paths for news articles MUST treat news articles as
uninterpreted sequences of octets, excluding the values 0 (US-ASCII uninterpreted sequences of octets, excluding the values 0 (US-ASCII
NUL) and 13 and 10 (US-ASCII CR and LF, which MUST ONLY appear in the NUL) and 13 and 10 (US-ASCII CR and LF, which MUST ONLY appear in the
combination CRLF which denotes a line separator). combination CRLF which denotes a line separator).
News Article Format June 2003
NOTE: this corresponds to the range of octets permitted for MIME NOTE: this corresponds to the range of octets permitted for MIME
"8bit data" [RFC 2045]. Thus raw binary data cannot be "8bit data" [RFC 2045]. Thus raw binary data cannot be
transmitted in an article body except by the use of a Content- transmitted in an article body except by the use of a Content-
Transfer-Encoding such as base64. Transfer-Encoding such as base64.
In particular, transmission paths MUST convey all headers (including In particular, transmission paths MUST convey all headers (including
body part headers and headers within message/rfc822 objects) intact, body part headers and headers within message/rfc822 objects) intact,
even if they contain octets representing non-ASCII charsets. These even if they contain octets representing non-ASCII charsets. These
requirements include the transmissiom paths between posting agents, requirements include the transmissiom paths between posting agents,
injecting agents, relaying agents, serving agents and reading agents, injecting agents, relaying agents, serving agents and reading agents,
skipping to change at page 26, line 5 skipping to change at page 24, line 38
relaying agent that does not support it, it SHOULD report this error relaying agent that does not support it, it SHOULD report this error
to its administrator. It MUST refuse to pass the article and MUST NOT to its administrator. It MUST refuse to pass the article and MUST NOT
re-encode it with different MIME encodings. re-encode it with different MIME encodings.
NOTE: This strategy will do little harm. The target relaying NOTE: This strategy will do little harm. The target relaying
agent is unlikely to be able to make use of the article on its agent is unlikely to be able to make use of the article on its
own servers, and the usual flooding algorithm will likely find own servers, and the usual flooding algorithm will likely find
some alternative route to get the article to destinations where some alternative route to get the article to destinations where
it is needed. it is needed.
News Article Format April 2003
4.4.1. Character Sets within Article Headers 4.4.1. Character Sets within Article Headers
Where the use of non-ASCII characters is required, they MUST be Where the use of non-ASCII characters is required, they MUST be
encoded using the MIME mechanisms defined in [RFC 2047] and [RFC encoded using the MIME mechanisms defined in [RFC 2047] and [RFC
2231]. 2231].
Examples: Examples:
Organization: Technische =?iso-8859-1?Q?Universit=E4t_M=FCnchen?= Organization: Technische =?iso-8859-1?Q?Universit=E4t_M=FCnchen?=
Approved: =?iso-8859-1?Q?Fran=E7ois_Faur=E9?= <ff@modsite.example> Approved: =?iso-8859-1?Q?Fran=E7ois_Faur=E9?= <ff@modsite.example>
(=?iso-8859-1?Q*fr?Mod=E9rateur_autoris=E9?=) (=?iso-8859-1?Q*fr?Mod=E9rateur_autoris=E9?=)
skipping to change at page 26, line 29 skipping to change at page 25, line 5
NOTE: The raw use of non-ASCII character sets or of encodings NOTE: The raw use of non-ASCII character sets or of encodings
other than those described above is not compliant with this other than those described above is not compliant with this
standard, even though such usage has been seen in some standard, even though such usage has been seen in some
hierarchies (with no indication of which character set has been hierarchies (with no indication of which character set has been
used beyond the user's ability to guess based upon other clues used beyond the user's ability to guess based upon other clues
in the article, or custom within the newsgroup). Future in the article, or custom within the newsgroup). Future
extensions to this standard may make provision for other extensions to this standard may make provision for other
character sets, hence the requirement that octets beyond the character sets, hence the requirement that octets beyond the
US-ASCII range be transported without error. US-ASCII range be transported without error.
News Article Format June 2003
4.4.2. Character Sets within Article Bodies 4.4.2. Character Sets within Article Bodies
Within article bodies, characters are represented as octets according Within article bodies, characters are represented as octets according
to the encoding scheme implied by any Content-Transfer-Encoding- and to the encoding scheme implied by any Content-Transfer-Encoding- and
Content-Type-headers [RFC 2045]. In the absence of such headers, Content-Type-headers [RFC 2045]. In the absence of such headers,
reading agents cannot be relied upon to display correctly more than reading agents cannot be relied upon to display correctly more than
the US-ASCII characters, though they MUST display at least those. the US-ASCII characters, though they MUST display at least those.
NOTE: The use of non-ASCII characters in the absence of an NOTE: The use of non-ASCII characters in the absence of an
appropriate Content-Type-header is not compliant with this appropriate Content-Type-header is not compliant with this
standard, even though such usage has been seen in some standard, even though such usage has been seen in some
hierarchies (with no indication of which character set has been hierarchies (with no indication of which character set has been
used beyond the user's ability to guess based upon other clues used beyond the user's ability to guess based upon other clues
in the article, or custom within the newsgroup). in the article, or custom within the newsgroup).
NOTE: It is not expected that reading agents will necessarily be
able to present characters in all possible character sets. For
example, a reading agent might be able to present only the ISO-
8859-1 (Latin 1) characters [ISO 8859], in which case it Ought
to present undisplayable characters using some distinctive
glyph, or by exhibiting a suitable warning.
Followup agents MUST be careful to apply appropriate encodings to the Followup agents MUST be careful to apply appropriate encodings to the
outbound followup. A followup to an article containing non-ASCII outbound followup. A followup to an article containing non-ASCII
material is very likely to contain non-ASCII material itself. material is very likely to contain non-ASCII material itself.
4.5. Size Limits 4.5. Size Limits
Posting agents SHOULD endeavour to keep all header lines, so far as Compliant software MUST support headers of at least 998 octets, and
is possible, within 79 characters by folding them at suitable places that is the only limit on the length of a header line prescribed by
(see 4.2.3). However, posting agents MUST permit the poster to this standard. However, specific rules to the contrary may apply in
include longer headers if he so insists, and compliant software MUST particular cases (for example, according to [RFC 2047] header lines
News Article Format April 2003 containing encoded-words are limited to 76 octets).
support headers of at least 998 octets. Likewise, injecting agents
SHOULD fold any headers generated automatically by themselves.
Relaying agents MUST NOT fold headers (i.e. they must pass on the
folding as received).
NOTE: There is NO restriction on the number of lines into which NOTE: There is NO restriction on the number of lines into which
a header may be split, and hence there is NO restriction on the a header may be split, and hence there is NO restriction on the
total length of a header (in particular it may, by suitable total length of a header (in particular it may, by suitable
folding, be made to exceed the 998 octets restriction pertaining folding, be made to exceed the 998 octets restriction pertaining
to a single header line). to a single header line).
The syntax provides for the lines of a body to be up to 998 octets in The syntax provides for the lines of a body to be up to 998 octets in
length, not including the CRLF. All software compliant with this length, not including the CRLF. All software compliant with this
standard MUST support lines of at least that length, both in headers standard MUST support lines of at least that length, both in headers
and in bodies, and all such software SHOULD support lines of and in bodies, and all such software SHOULD support lines of
arbitrary length. In particular, relaying agents MUST transmit lines arbitrary length. In particular, relaying agents MUST transmit lines
of arbitrary length without truncation or any other modification. of arbitrary length without truncation or any other modification.
NOTE: The limit of 998 octets is consistent with the NOTE: The limit of 998 octets is consistent with the
corresponding limit in [RFC 2822]. corresponding limit in [RFC 2822].
In plain-text messages (those with no MIME headers, or those with a
MIME Content-Type of text/plain) posting agents Ought to endeavour to
keep the length of body lines within some reasonable limit. The size
of this limit is a matter of policy, the default being to keep within
79 characters at most, and preferably within 72 characters (to allow
room for quoting in followups). Exceptionally, posting agents Ought
Not to adjust the length of quoted lines in followups unless they are
able to reformat them in a consistent manner. Moreover, posting
agents MUST permit the poster to include longer lines if he so
insists.
NOTE: Plain-text messages are intended to be displayed "as-is"
without any special action (such as automatic line splitting) on
the part of the recipient. The policy limit (e.g. 72 or 79)
should be expressed as a number of characters (as they will be
displayed by a reading agent) rather than as the number of
octets used to encode them.
NOTE: This standard provides no upper bound on the overall size NOTE: This standard provides no upper bound on the overall size
of a single article, but neither does it forbid relaying agents of a single article, but neither does it forbid relaying agents
from dropping articles of excessive length. It is, however, from dropping articles of excessive length. It is, however,
suggested that any limits thought appropriate by particular suggested that any limits thought appropriate by particular
agents would be more appropriately expressed in megabytes than agents would be more appropriately expressed in megabytes than
in kilobytes. in kilobytes.
News Article Format June 2003
4.6. Example 4.6. Example
Here is a sample article: Here is a sample article:
Path: server.example/unknown.site2.example@site2.example/ Path: server.example/unknown.site2.example@site2.example/
relay.site.example/site.example/injector.site.example%jsmith relay.site.example/site.example/injector.site.example%jsmith
Newsgroups: example.announce,example.chat Newsgroups: example.announce,example.chat
Message-ID: <9urrt98y53@site1.example> Message-ID: <9urrt98y53@site1.example>
News Article Format April 2003
From: Ann Example <a.example@site1.example> From: Ann Example <a.example@site1.example>
Subject: Announcing a new sample article. Subject: Announcing a new sample article.
Date: Wed, 27 Mar 2002 12:12:50 +0300 Date: Wed, 27 Mar 2002 12:12:50 +0300
Approved: example.announce moderator <jsmith@site.example> Approved: example.announce moderator <jsmith@site.example>
Followup-To: example.chat Followup-To: example.chat
Reply-To: Ann Example <a.example+replies@site1.example> Reply-To: Ann Example <a.example+replies@site1.example>
Expires: Mon, 22 Apr 2002 12:12:50 +0300 Expires: Mon, 22 Apr 2002 12:12:50 +0300
Organization: Site1, The Number one site for examples. Organization: Site1, The Number one site for examples.
User-Agent: ExampleNews/3.14 (Unix) User-Agent: ExampleNews/3.14 (Unix)
Keywords: example, announcement, standards, RFC 1036, Usefor Keywords: example, announcement, standards, RFC 1036, Usefor
skipping to change at page 28, line 49 skipping to change at page 26, line 58
certain headers. certain headers.
A proto-article (see 8.2.1) may lack some of these mandatory headers, A proto-article (see 8.2.1) may lack some of these mandatory headers,
but they MUST then be supplied by the injecting agent. but they MUST then be supplied by the injecting agent.
5.1. Date 5.1. Date
The Date-header contains the date and time that the article was The Date-header contains the date and time that the article was
prepared by the poster ready for transmission and SHOULD express the prepared by the poster ready for transmission and SHOULD express the
poster's local time. The content syntax makes use of syntax defined poster's local time. The content syntax makes use of syntax defined
in [RFC 2822], subject to the following revised definition of zone. in [RFC 2822] (but see the revised definition of zone in section
2.4.2).
News Article Format June 2003
header =/ Date-header header =/ Date-header
Date-header = "Date" ":" SP Date-content Date-header = "Date" ":" SP Date-content
Date-content = date-time Date-content = date-time
zone = (( "+" / "-" ) 4DIGIT) / "UT" / "GMT"
The forms "UT" and "GMT" (indicating universal time) are to be The date-time MUST be semantically valid as required by [RFC 2822].
regarded as obsolete synonyms for "+0000". They MUST be accepted, and Although folding white space is permitted throughout the date-time
passed on unchanged, by all agents, but they MUST NOT be generated as syntax, it is RECOMMENDED that a single space be used in each place
News Article Format April 2003 that FWS appears (whether it is required or optional).
part of new articles by posting and injecting agents. The date-time
MUST be semantically valid as required by [RFC 2822]. Although
folding white space is permitted throughout the date-time syntax, it
is RECOMMENDED that a single space be used in each place that FWS
appears (whether it is required or optional).
NOTE: A convention that is sometimes followed is to add a
comment, after the date-time, containing the time zone in
human-readable form, but many of the abbreviations commonly used
for this purpose are ambiguous. The value given by the <zone> is
the only definitive form.
In order to prevent the reinjection of expired articles into the news In order to prevent the reinjection of expired articles into the news
stream, relaying and serving agents MUST refuse "stale" articles stream, relaying and serving agents MUST refuse "stale" articles
whose Date-header predates the earliest articles of which they whose Date-header predates the earliest articles of which they
normally keep record, or which is more than 24 hours into the future normally keep record, or which is more than 24 hours into the future
(though they MAY use a margin less than that 24 hours). Relaying (though they MAY use a margin less than that 24 hours). Relaying
agents MUST NOT modify the Date-header in transit. agents MUST NOT modify the Date-header in transit.
5.1.1. Examples 5.1.1. Examples
Date: Sat, 26 May 2001 11:13:00 -0500 (EST) Date: Sat, 26 May 2001 11:13:00 -0500 (EST)
Date: 26 May 2001 16:13 +0000 Date: 26 May 2001 16:13 +0000
Date: 26 May 2001 16:13 GMT (Obsolete) Date: 26 May 2001 16:13 GMT (Obsolete)
5.2. From 5.2. From
The From-header contains the email address(es), possibly including The From-header contains the email address(es), possibly including
the full name(s), of the article's poster(s). The content syntax the full name(s), of the article's poster(s), or of the person or
makes use of syntax defined in [RFC 2822]. agent on whose behalf the article is posted (see the Sender-header,
6.2). The content syntax makes use of syntax defined in [RFC 2822].
header =/ From-header header =/ From-header
From-header = "From" ":" SP From-content From-header = "From" ":" SP From-content
From-content = mailbox-list From-content = mailbox-list
Observe that there is no provision for parameters in this NOTE: Observe that there is no provision for parameters in this
header, or in other headers containing addresses likely to be header, or in other headers containing addresses likely to be
used for sending email (see 4.2.2). used for sending email (see 4.2.2). When, for whatever reason,
a poster does not wish to use a valid address, the mailbox
Each mailbox in the From-content SHOULD be a valid address, belonging concerned SHOULD end in the top level domain ".invalid" [RFC
to the poster(s) of the article, or person or agent on whose behalf 2606].
the post is being sent (see the Sender-header, 6.2). When, for
whatever reason, the poster does not wish to include such an address,
the From-content SHOULD then be an address which ends in the top
level domain of ".invalid" [RFC 2606].
NOTE: Since such addresses ending in ".invalid" are
undeliverable, user agents Ought to warn any user attempting to
reply to them and Ought Not, in any case, to attempt to deliver
to them (since that would be pointless anyway). Whether or not
a valid address can subsequently be extracted from such an
address falls outside the scope of this standard (obviously,
posters wishing to disguise their address need to do more than
just add ".invalid" to it).
News Article Format April 2003
Be warned, however, that some injecting agents which are unable
to detect that the address belongs to the poster may choose to
insert a Sender-header (but see 8.2.2) or some entry in an
Injector-Info-header (6.19) which discloses some valid address
for the poster.
5.2.1. Examples: 5.2.1. Examples:
From: John Smith <jsmith@site.example> From: John Smith <jsmith@site.example>
From: "John Smith" <jsmith@site.example>, dave@isp.example From: "John Smith" <jsmith@site.example>, dave@isp.example
From: "John D. Smith" <jsmith@site.example>, andrew@isp.example, From: "John D. Smith" <jsmith@site.example>, andrew@isp.example,
fred@site2.example fred@site2.example
From: Jan Jones <jan@please_setup_your_system_correctly.invalid> From: Jan Jones <jan@please_setup_your_system_correctly.invalid>
From: Jan Jones <joe@guess-where.invalid> From: Jan Jones <joe@guess-where.invalid>
From: dave@isp.example (Dave Smith) From: dave@isp.example (Dave Smith)
NOTE: the last example shows a now deprecated convention of NOTE: the last example shows a now deprecated convention of
putting a poster's full name in a comment following the mailbox, putting a poster's full name in a comment following the mailbox,
rather than in a phrase at the start of it. Observe also the use rather than in a phrase at the start of it. Observe also the use
of the quoted-string "John D. Smith" which is required on of the quoted-string "John D. Smith" which is required on
News Article Format June 2003
account of presence of the '.' character. account of presence of the '.' character.
5.3. Message-ID 5.3. Message-ID
The Message-ID-header contains the article's message identifier, a The Message-ID-header contains the article's message identifier, a
unique identifier distinguishing the article from every other unique identifier distinguishing the article from every other
article. The content syntax makes use of syntax defined in [RFC article. The content syntax makes use of syntax defined in [RFC 2822]
2822], subject to the following revised definitions of msg-id, no- (but see the revised definition of msg-id in section 2.4.2).
fold-quote and no-fold-literal.
header =/ Message-ID-header header =/ Message-ID-header
Message-ID-header = "Message-ID" ":" SP Message-ID-content Message-ID-header = "Message-ID" ":" SP Message-ID-content
Message-ID-content = [FWS] msg-id [FWS] Message-ID-content = [FWS] msg-id [FWS]
msg-id = "<" id-left "@" id-right ">"
id-left = dot-atom-text / no-fold-quote
id-right = dot-atom-text / no-fold-literal
no-fold-quote = DQUOTE
*( qtext / "\\" / "\" DQUOTE )
qspecial
*( qtext / "\\" / "\" DQUOTE )
DQUOTE
qspecial = "(" / ")" / ; same as specials except
"<" / ">" / ; "\" and DQUOTE quoted
"[" / "]" /
":" / ";" /
"@" / "\\" /
"," / "." /
"\" DQUOTE
no-fold-literal = "[" *( dtext / "\[" / "\]" / "\\" ) "]"
[I think we need to ensure that '<' and '>' are excluded from id-left
and id-right.]
News Article Format April 2003
The msg-id MUST NOT be more than 250 octets in length. The msg-id MUST NOT be more than 250 octets in length.
NOTE: Observe that, in contrast to the corresponding header in NOTE: The length restriction ensures that systems which accept
[RFC 2822], the syntax does not allow comments within the message identifiers as a parameter when retrieving an article
Message-ID-header; this is to simplify processing by relaying (e.g. [NNTP]) can rely on a bounded length. Observe that msg-id
and serving agents and to ensure interoperability with existing
implementations.
Msg-ids as defined here are a "normalized" subset of those
defined by [RFC 2822], ensuring that no string of characters is
quoted unless strictly necessary (it must contain at least one
qspecial) and no single character is prefixed by a "\" in the
form of a quoted-pair unless strictly necessary, and moreover
there is no possibility for WSP to occur, whether quoted or not.
The length restriction ensures that systems which accept message
identifiers as a parameter when retrieving an article (e.g.
[NNTP]) can rely on a bounded length. Observe that msg-id
includes the '<' and '>'. includes the '<' and '>'.
Observe that, in contrast to the corresponding header in [RFC
2822], the syntax does not allow comments within the Message-
ID-header; this is to simplify processing by relaying and
serving agents and to ensure interoperability with existing
implementations.
An agent generating an article's message identifier MUST ensure that An agent generating an article's message identifier MUST ensure that
it is unique (as also required in [RFC 2822]) and that it is chosen it is unique (as also required in [RFC 2822]) and that it is chosen
in such a way that it will NEVER be applied to any other Netnews in such a way that it will NEVER be applied to any other Netnews
article or Email message. However, an article emailed (without article or Email message. However, an article emailed (without
encapsulation) to a moderator (8.2.2 and 8.7) or gatewayed into some encapsulation) to a moderator (8.2.2 and 8.7) or gatewayed into some
other medium (8.8.1) SHOULD retain the same message identifier other medium (8.8.1) SHOULD retain the same message identifier
throughout its travels so long as it remains recognizably the same throughout its travels so long as it remains recognizably the same
article. article.
Even though commonly derived from the domain name of the originating Even though commonly derived from the domain name of the originating
skipping to change at page 31, line 51 skipping to change at page 29, line 5
NOTE: These requirements are to be contrasted with those of the NOTE: These requirements are to be contrasted with those of the
un-normalized msg-ids defined by [RFC 2822], which may perfectly un-normalized msg-ids defined by [RFC 2822], which may perfectly
legitimately become normalized (or vice versa) during transport legitimately become normalized (or vice versa) during transport
or copying in email systems. or copying in email systems.
NOTE: Some old software may treat message identifiers that NOTE: Some old software may treat message identifiers that
differ only in case within their id-right part as equivalent, differ only in case within their id-right part as equivalent,
and implementors of agents that generate message identifiers and implementors of agents that generate message identifiers
should be aware of this. should be aware of this.
News Article Format June 2003
5.4. Subject 5.4. Subject
The Subject-header contains a short string identifying the topic of The Subject-header contains a short string identifying the topic of
the message. This is an inheritable header (4.2.5.2) to be copied the message. This is an inheritable header (4.2.5.2), normally to be
into the Subject-header of any followup, in which case the new copied into the Subject-header of any followup with the possible
Subject-content SHOULD then default to the string "Re: " (a "back addition of a back-reference as described in B.6.
reference") followed by the contents of the pure-subject of the
precursor. Any leading "Re: " in that pure-subject MUST be stripped.
News Article Format April 2003
header =/ Subject-header header =/ Subject-header
Subject-header = "Subject" ":" SP Subject-content Subject-header = "Subject" ":" SP Subject-content
Subject-content = [ [FWS] back-reference ] pure-subject Subject-content = unstructured
pure-subject = unstructured
back-reference = %x52.65.3A.20
; which is a case-sensitive "Re: "
The pure-subject MUST NOT begin with "Re: ".
NOTE: The syntax of unstructured differs from that prescribed in NOTE: The syntax of unstructured differs from that prescribed in
[RFC 2822], so ensuring that the Subject-content is not [RFC 2822], so ensuring that the Subject-content is not
permitted to be completely empty, or to consist of WSP only (see permitted to be completely empty, or to consist of WSP only (see
remarks in 4.2.6 concerning undesirable headers). remarks in 4.2.6 concerning undesirable headers).
Followup agents MAY remove strings that are known to be used
erroneously as back-reference (such as "Re(2): ", "Re:", "RE: ", or
"Sv: ") from the Subject-content when composing the subject of a
followup, and add a correct back-reference in front of the result.
NOTE: that would be "SHOULD remove instances" except that we
cannot find a sufficiently robust and simple algorithm to do the
necessary natural language processing.
Followup agents MUST NOT use any other string except "Re: " as a back
reference. Specifically, a translation of "Re: " into a local
language or usage MUST NOT be used.
NOTE: "Re" is an abbreviation for the Latin "In re", meaning "in
the matter of", and not an abbreviation of "Reference" as is
sometimes erroneously supposed.
Agents SHOULD NOT depend on nor enforce the use of back references by
followup agents.
For compatibility with legacy news software, the Subject-content of a
control message (i.e. an article that also contains a Control-header)
MAY start with the string "cmsg ", and non-control messages MUST NOT
start with the string "cmsg ". See also section 6.13.
5.4.1. Examples
In the following examples, please note that only "Re: " is mandated
by this standard. "was: " is a convention used by many English-
speaking posters to signal a change in subject matter. Software can
always recognize such changes from the References-header.
Subject: Film at 11
Subject: Re: Film at 11
Subject: Godwin's law considered harmful (was: Film at 11)
Subject: Godwin's law (was: Film at 11)
Subject: Re: Godwin's law (was: Film at 11)
Subject: Re: Godwin's law
News Article Format April 2003
5.5. Newsgroups 5.5. Newsgroups
The Newsgroups-header's content specifies the newsgroup(s) in which The Newsgroups-header's content specifies the newsgroup(s) in which
the article is intended to appear. It is an inheritable header the article is intended to appear. It is an inheritable header
(4.2.5.2) which then becomes the default Newsgroups-header of any (4.2.5.2) which then becomes the default Newsgroups-header of any
followup, unless a Followup-To-header is present to prescribe followup, unless a Followup-To-header is present to prescribe
otherwise. Articles MUST NOT be passed between relaying agents or to otherwise (see 8.6). Articles MUST NOT be passed between relaying
serving agents unless the sending agent has been configured to supply agents or to serving agents unless the sending agent has been
and the receiving agent to receive at least one of the newsgroup- configured to supply and the receiving agent to receive at least one
names in the Newsgroups-header. of the newsgroup-names in the Newsgroups-header.
header =/ Newsgroups-header header =/ Newsgroups-header
Newsgroups-header = "Newsgroups" ":" SP Newsgroups-content Newsgroups-header = "Newsgroups" ":" SP Newsgroups-content
*( ";" extension-parameter ) *( ";" extension-parameter )
Newsgroups-content = [FWS] newsgroup-name Newsgroups-content = [FWS] newsgroup-name
*( [FWS] ng-delim [FWS] newsgroup-name ) *( [FWS] ng-delim [FWS] newsgroup-name )
[FWS] [FWS]
newsgroup-name = component *( "." component ) newsgroup-name = component *( "." component )
component = 1*component-grapheme component = 1*component-grapheme
ng-delim = "," ng-delim = ","
component-grapheme = DIGIT / ALPHA / "+" / "-" / "_" component-grapheme = DIGIT / ALPHA / "+" / "-" / "_"
[Maybe some better word for 'grapheme'.]
NOTE: Observe that the syntax does not allow comments within the
Newsgroups-header; this is to simplify processing by relaying
and serving agents which have a requirement to process this
header extremely rapidly.
Components beginning with underline ("_") are reserved for use by Components beginning with underline ("_") are reserved for use by
future versions of this standard and MUST NOT occur in newsgroup- future versions of this standard and MUST NOT occur in newsgroup-
names (whether in Newsgroups-headers or in newgroup control messages names (whether in Newsgroups-headers or in newgroup control messages
(7.2.1)). However, such names MUST be accepted. (7.2.1)). However, such names MUST be accepted.
Components beginning with "+" or "-" are reserved for use by Components beginning with "+" or "-" are reserved for use by
implementations and MUST NOT occur in newsgroup-names (whether in implementations and MUST NOT occur in newsgroup-names (whether in
Newsgroups-headers or in newgroup control messages). Implementors may Newsgroups-headers or in newgroup control messages). Implementors may
assume that this rule will not change in any future version of this assume that this rule will not change in any future version of this
standard. standard.
News Article Format June 2003
NOTE: For example, implementors may safely use leading "+" and NOTE: For example, implementors may safely use leading "+" and
"-" to "escape" other entities within something that looks like "-" to "escape" other entities within something that looks like
a newsgroup-name. a newsgroup-name.
Agencies responsible for the administration of particular hierarchies The format of newsgroup-names is ultimately determined by the
MAY place additional restrictions on the newsgroup-names they allow policies of those administrative agencies which have the
within those hierarchies. Where there is no such specific policy, the responsibility for creating new newsgroups within the various
following restrictions SHOULD be applied to newsgroup-names. hierarchies of Usenet. There are traditional, social and technical
arguments why there should be restrictions on these formats (and the
NOTE: These restrictions are intended to reflect existing force of the technical ones changes over time with developments in
practice, with some additions to accommodate foreseeable computers and operating systems) Therefore, such administrative
enhancements, and are intended both to avoid certain technical agencies SHOULD establish and promulgate the restrictions they intend
difficulties and to avoid unnecessary confusion. It may well be to apply within their own hierarchies.
that experience will allow future extensions to this standard to
relax some or all of these restrictions.
The specific restrictions (to be applied in the absence of
established policies to the contrary) are:
News Article Format April 2003 NOTE: These issues are discussed more fully in [USEAGE]. The
following policy restrictions represent what is considered safe
and appropriate at the present time. Although purely advisory,
hierarchy administrators should consider the consequences
carefully before allowing them to be exceeded. They could also
be taken as the defaults in unmanaged hierarchies.
1. Uppercase letters are forbidden. Traditionally, newsgroup-names 1. Uppercase letters are forbidden.
have been written in lowercase. Posting agents Ought Not to
convert uppercase characters to the corresponding lowercase forms
except under the explicit instructions of the poster.
2. A component name is forbidden to consist entirely of digits. 2. A component name is forbidden to consist entirely of digits.
NOTE: This requirement was in [RFC 1036] but nevertheless 3. A component is limited to 30 component-graphemes and a
several such groups have appeared in practice and implementors newsgroup-name to 71 component-graphemes (counting also the
should be prepared for them. A common implementation technique '.'s separating the components).
uses each component as the name of a directory and uses numeric [There was a suggestion to reduce that 71 to 66 in order to allow such a
filenames for each article within a group. Such an newsgoup-name to fit in the on the first line of a Followup-To-header
implementation needs to be careful when this could cause a clash without exceeding 79 characters.]
(e.g. between article 123 of group xxx.yyy and the directory for
group xxx.yyy.123).
3. A component is limited to 30 component-graphemes and a newsgroup-
name to 71 component-graphemes (counting also the '.'s separating
the components). Whilst there is no longer any technical reason
to limit the length of a component (formerly, it was limited to 14
octets) nor of a newsgroup-name, it should be noted that these
names are also used in the newsgroups-line (7.2.1.2) where an
overall policy limit applies and, moreover, excessively long names
can be exceedingly inconvenient in practical use.
Serving and relaying agents MUST accept any newsgroup-name that meets
the above requirements, even if it violates one or more of the policy
restrictions. Posting and injecting agents MAY reject articles
containing newsgroup-names that do not meet these restrictions, and
posting agents MAY attempt to correct them (but only with the
explicit agreement of the poster).
Since future extensions to this standard plus any relaxations of the
default restrictions introduced by specific hierarchies might
invalidate some such checks, warnings, and adjustments,
implementations MUST incorporate means to disable them.
NOTE: Observe that the syntax does not allow comments within the Serving and relaying agents MUST accept any syntactially correct
Newsgroups-header; this is to simplify processing by relaying and newsgroup-name even if it would violate whatever policy restrictions
serving agents which have a requirement to process this header may be in place. Posting and injecting agents MAY enforce them (but
extremely rapidly. only with the explicit agreement of the poster).
The inclusion of folding white space within a Newsgroups-content is a The inclusion of folding white space within a Newsgroups-content is a
newly introduced feature in this standard. It MUST be accepted by all newly introduced feature in this standard. It MUST be accepted by all
conforming implementations (relaying agents, serving agents and conforming implementations (relaying agents, serving agents and
reading agents). Posting agents should be aware that such postings reading agents). Posting agents should be aware that such postings
may be rejected by overly-critical old-style relaying agents. When a may be rejected by overly-critical old-style relaying agents. When a
sufficient number of relaying agents are in conformance, posting sufficient number of relaying agents are in conformance, posting
agents SHOULD generate such whitespace in the form of <CRLF WSP> so agents SHOULD generate such whitespace in the form of <CRLF WSP> so
as to keep the length of lines in the relevant headers (notably as to keep the length of lines in the relevant headers (notably
Newsgroups and Followup-To) to no more than than 79 characters (or Newsgroups and Followup-To) to a reasonable length (such as 79
other agreed policy limit - see 4.5). Before such critical mass characters, which is likely to be displayed satisfactorily by most
occurs, injecting agents MAY reformat such headers by removing current reading agents). Before such critical mass occurs, injecting
whitespace inserted by the posting agent, but relaying agents MUST agents MAY reformat such headers by removing whitespace inserted by
News Article Format April 2003 the posting agent, but relaying agents MUST NOT do so.
NOT do so.
Posters SHOULD use only the names of existing newsgroups in the Posters SHOULD use only the names of existing newsgroups in the
Newsgroups-header. However, it is legitimate to cross-post to Newsgroups-header. However, it is legitimate to cross-post to
newsgroups which do not exist on the posting agent's host, provided newsgroups which do not exist on the posting agent's host, provided
that at least one of the newsgroups DOES exist there, and followup News Article Format June 2003
agents SHOULD accept this (posting agents MAY accept it, but Ought at
least to alert the poster to the situation and request confirmation). that at least one of the newsgroups DOES exist there. Relaying agents
Relaying agents MUST NOT rewrite Newsgroups-headers in any way, even MUST NOT rewrite Newsgroups-headers in any way, even if some or all
if some or all of the newsgroups do not exist on the relaying agent's of the newsgroups do not exist on the relaying agent's host. Serving
host. Serving agents MUST NOT create new newsgroups simply because an agents MUST NOT create new newsgroups simply because an unrecognized
unrecognized newsgroup-name occurs in a Newsgroups-header (see 7.2.1 newsgroup-name occurs in a Newsgroups-header (see 7.2.1 for the
for the correct method of newsgroup creation). correct method of newsgroup creation).
The Newsgroups-header is intended for use in Netnews articles rather The Newsgroups-header is intended for use in Netnews articles rather
than in email messages. It MAY be used in an email message to than in email messages. It MAY be used in an email message to
indicate that it is a copy also posted to the listed newsgroups, in indicate that it is a copy also posted to the listed newsgroups, in
which case the inclusion of a Posted-And-Mailed header (6.9) would which case the inclusion of a Posted-And-Mailed header (6.9) would
also be appropriate. However, it SHOULD NOT be used in an email-only also be appropriate. However, it SHOULD NOT be used in an email-only
reply to a Netnews article (thus the "inheritable" property of this reply to a Netnews article (thus the "inheritable" property of this
header applies only to followups to a newsgroup, and not to followups header applies only to followups to a newsgroup, and not to followups
to the poster). to the poster).
skipping to change at page 36, line 4 skipping to change at page 31, line 53
A newsgroup-name SHOULD NOT appear more than once in the Newsgroups- A newsgroup-name SHOULD NOT appear more than once in the Newsgroups-
header. The order of newsgroup-names in the Newsgroups-header is not header. The order of newsgroup-names in the Newsgroups-header is not
significant, except for determining which moderator to send the significant, except for determining which moderator to send the
article to if more than one of the groups is moderated (see 8.2). article to if more than one of the groups is moderated (see 8.2).
5.6. Path 5.6. Path
The Path-header shows the route taken by a message since its entry The Path-header shows the route taken by a message since its entry
into the Netnews system. It is a variant header (4.2.5.3), each agent into the Netnews system. It is a variant header (4.2.5.3), each agent
that processes an article being required to add one (or more) entries that processes an article being required to add one (or more) entries
News Article Format April 2003
to it. This is primarily to enable relaying agents to avoid sending to it. This is primarily to enable relaying agents to avoid sending
articles to sites already known to have them, in particular the site articles to sites already known to have them, in particular the site
they came from, and additionally to permit tracing the route articles they came from, and additionally to permit tracing the route articles
take in moving over the network, and for gathering Usenet statistics. take in moving over the network, and for gathering Usenet statistics.
Finally the presence of a '%' path-delimiter in the Path-header can Finally the presence of a '%' path-delimiter in the Path-header can
be used to identify an article injected in conformance with this be used to identify an article injected in conformance with this
standard. standard.
News Article Format June 2003
5.6.1. Format 5.6.1. Format
header =/ Path-header header =/ Path-header
Path-header = "Path" ":" SP Path-content Path-header = "Path" ":" SP Path-content
*( ";" extension-parameter ) *( ";" extension-parameter )
Path-content = [FWS] Path-content = [FWS]
*( path-identity [FWS] path-delimiter [FWS] ) *( path-identity [FWS] path-delimiter [FWS] )
tail-entry [FWS] tail-entry [FWS]
path-identity = ( ALPHA / DIGIT ) path-identity = ( ALPHA / DIGIT )
*( ALPHA / DIGIT / "-" / "." / ":" / "_" ) *( ALPHA / DIGIT / "-" / "." / ":" / "_" )
skipping to change at page 37, line 5 skipping to change at page 32, line 53
sites not wishing to act upon them. sites not wishing to act upon them.
5.6.2. Adding a path-identity to the Path-header 5.6.2. Adding a path-identity to the Path-header
When an injecting, relaying or serving agent receives an article, it When an injecting, relaying or serving agent receives an article, it
MUST prepend its own path-identity followed by a path-delimiter to MUST prepend its own path-identity followed by a path-delimiter to
the beginning of the Path-content. In addition, it SHOULD then add the beginning of the Path-content. In addition, it SHOULD then add
CRLF and WSP if it would otherwise result in a line longer than 79 CRLF and WSP if it would otherwise result in a line longer than 79
characters. characters.
News Article Format April 2003
The path-identity added MUST be unique to that agent. To this end it The path-identity added MUST be unique to that agent. To this end it
SHOULD be one of: SHOULD be one of:
1. A fully qualified domain name (FQDN) associated (by the Internet 1. A fully qualified domain name (FQDN) associated (by the Internet
DNS service [RFC 1034]) with an A record, which SHOULD identify DNS service [RFC 1034]) with an A record, which SHOULD identify
the actual machine prepending this path-identity. Ideally, this the actual machine prepending this path-identity. Ideally, this
FQDN should also be "mailable" (see below). FQDN should also be "mailable" (see below).
News Article Format June 2003
2. A fully qualified domain name (FQDN) associated (by the Internet 2. A fully qualified domain name (FQDN) associated (by the Internet
DNS service) with an MX record, which MUST be "mailable". DNS service) with an MX record, which MUST be "mailable".
3. An arbitrary name believed to be unique and registered at least 3. An arbitrary name believed to be unique and registered at least
with all sites immediately downstream from the given site. with all sites immediately downstream from the given site.
4. An encoding of an IP address - <IPv4address> or <IPv6address> [RFC 4. An encoding of an IP address - <IPv4address> or <IPv6address> [RFC
2373] (the requirement to be able to use an <IPv6address> is the 2373] (the requirement to be able to use an <IPv6address> is the
reason for including ':' as an allowed character within a path- reason for including ':' as an allowed character within a path-
identity). identity).
skipping to change at page 38, line 5 skipping to change at page 33, line 51
entries to the Path-content; firstly the true established path- entries to the Path-content; firstly the true established path-
identity of the source followed by a '?' path-delimiter, and then, identity of the source followed by a '?' path-delimiter, and then,
to the left of that, the agent's own path-identity followed by a '/' to the left of that, the agent's own path-identity followed by a '/'
path-delimiter as usual. This prepending of two entries SHOULD NOT path-delimiter as usual. This prepending of two entries SHOULD NOT
be done if the provided and established identities match. be done if the provided and established identities match.
Any method of establishing the identity of the source may be used Any method of establishing the identity of the source may be used
(but see 5.6.5 below), with the consideration that, in the event of (but see 5.6.5 below), with the consideration that, in the event of
problems, the agent concerned may be called upon to justify it. problems, the agent concerned may be called upon to justify it.
News Article Format April 2003
NOTE: The use of the '%' path-delimiter marks the position of NOTE: The use of the '%' path-delimiter marks the position of
the injecting agent in the chain. In normal circumstances there the injecting agent in the chain. In normal circumstances there
should therefore be only one '%' path-delimiter present, and should therefore be only one '%' path-delimiter present, and
injecting agents MAY choose to reject proto-articles with a '%' injecting agents MAY choose to reject proto-articles with a '%'
already in them. If, for whatever reason, more than one '%' is already in them. If, for whatever reason, more than one '%' is
found, then the path-identity in front of the leftmost '%' is to found, then the path-identity in front of the leftmost '%' is to
be regarded as the true injecting agent. be regarded as the true injecting agent.
News Article Format June 2003
5.6.3. The tail-entry 5.6.3. The tail-entry
For historical reasons, the tail-entry (i.e. the rightmost entry in For historical reasons, the tail-entry (i.e. the rightmost entry in
the Path-content) is regarded as a "user name", and therefore MUST the Path-content) is regarded as a "user name", and therefore MUST
NOT be interpreted as a site through which the article has already NOT be interpreted as a site through which the article has already
passed. Moreover, the Path-content as a whole is not an email address passed. Moreover, the Path-content as a whole is not an email address
and MUST NOT be used to contact the poster. Posting and/or injecting and MUST NOT be used to contact the poster. Posting and/or injecting
agents MAY place any string here. When it is not an actual user agents MAY place any string here. When it is not an actual user
name, the string "not-for-mail" is often used, but in fact a simple name, the string "not-for-mail" is often used, but in fact a simple
"x" would be sufficient. "x" would be sufficient.
skipping to change at page 39, line 5 skipping to change at page 34, line 51
'?' The name immediately to the right is the claimed identity of the '?' The name immediately to the right is the claimed identity of the
machine from which the article was received, but we were unable machine from which the article was received, but we were unable
to verify it (and have prepended our own view of where it came to verify it (and have prepended our own view of where it came
from, and then a '/'). from, and then a '/').
'%' Everything to the right is the pre-injection region followed by '%' Everything to the right is the pre-injection region followed by
the tail-entry. The name on the left is the FQDN of the the tail-entry. The name on the left is the FQDN of the
injecting agent. The presence of two '%'s in a path indicates a injecting agent. The presence of two '%'s in a path indicates a
double-injection (see 8.2.2). double-injection (see 8.2.2).
News Article Format April 2003
'!' The name immediately to the right is unverified. The presence of '!' The name immediately to the right is unverified. The presence of
a '!' to the left of the '%' indicates that the identity to the a '!' to the left of the '%' indicates that the identity to the
left is that of an old-style system not conformant with this left is that of an old-style system not conformant with this
standard. standard.
',' Reserved for future use, treat as '/'. ',' Reserved for future use, treat as '/'.
Other Other
Old software may possibly use other path-delimiters, which should Old software may possibly use other path-delimiters, which should
be treated as '!'. But note in particular that ':', '-' and '_' be treated as '!'. But note in particular that ':', '-' and '_'
News Article Format June 2003
are components of names, not path-delimiters, and FWS on its own are components of names, not path-delimiters, and FWS on its own
MUST NOT be used as the sole path-delimiter. MUST NOT be used as the sole path-delimiter.
NOTE: Old Netnews relaying and injecting agents almost all NOTE: Old Netnews relaying and injecting agents almost all
delimit Path entries with a '!', and these entries are not delimit Path entries with a '!', and these entries are not
verified. The presence of '%' indicates that the article was verified. The presence of '%' indicates that the article was
injected by software conforming to this standard, and the injected by software conforming to this standard, and the
presence of '!' to the left of a '%' indicates that the message presence of '!' to the left of a '%' indicates that the message
passed through systems developed prior to this standard. It is passed through systems developed prior to this standard. It is
anticipated that relaying agents will reject articles in the old anticipated that relaying agents will reject articles in the old
style once this new standard has been widely adopted. style once this new standard has been widely adopted.
5.6.5. Suggested Verification Methods 5.6.5. Suggested Verification Methods
It is preferable to verify the claimed path-identity against the [Section now omitted.]
source than to make routine use of the '?' path-delimiter, with
consequential wasteful double-entry Path additions.
If the incoming article arrives through some TCP/IP protocol such as
NNTP, the IP address of the source will be known, and will likely
already have been checked against a list of known FQDNs, IP
addresses, or other registered aliases that the receiving site has
agreed to peer with.
Since the source host may have several IP addresses, checking the
claimed FQDN or IP address against the source IP, or finding a
suitable FQDN to report with a '?' path-delimiter, may involve
several DNS lookups, following CNAME chains as required. Note that
any reverse DNS lookup that is involved needs to be confirmed by a
forward one.
If the incoming article arrives through some other protocol, such as
UUCP, that protocol MUST include a means of verifying the source
site. In UUCP implementations, commonly each incoming connection has
a unique login name and password, and that login name (or some alias
registered for it) would be expected as the path-identity.
5.6.6. Example 5.6.6. Example
Path: foo.isp.example/ Path: foo.isp.example/
foo-server/bar.isp.example?10.123.12.2/old.site.example! foo-server/bar.isp.example?10.123.12.2/old.site.example!
barbaz/baz.isp.example%dialup123.baz.isp.example!x barbaz/baz.isp.example%dialup123.baz.isp.example!x
News Article Format April 2003
NOTE: That article was injected into the news stream by NOTE: That article was injected into the news stream by
baz.isp.example (complaints may be addressed to baz.isp.example (complaints may be addressed to
abuse@baz.isp.example). The injector has taken care to record abuse@baz.isp.example). The injector has taken care to record
that it got it from dialup123.baz.isp.example. "x" is a dummy that it got it from dialup123.baz.isp.example. "x" is a dummy
tail-entry, though sometimes a real userid is put there. tail-entry, though sometimes a real userid is put there.
The article was relayed, perhaps by UUCP, to the machine known, The article was relayed, perhaps by UUCP, to the machine known,
at least to its downstream, as "barbaz". at least to its downstream, as "barbaz".
skipping to change at page 40, line 37 skipping to change at page 36, line 5
correct IP address for bar.isp.example, but simply that that correct IP address for bar.isp.example, but simply that that
connection could not be substantiated by foo-server). Observe connection could not be substantiated by foo-server). Observe
that foo-server has now added two entries to the Path. that foo-server has now added two entries to the Path.
"foo-server" is a locally significant name within the complex "foo-server" is a locally significant name within the complex
site of many machines run by foo.isp.example, so the latter site of many machines run by foo.isp.example, so the latter
should have no problem recognizing foo-server and using a '/' should have no problem recognizing foo-server and using a '/'
path-delimiter. Presumably foo.isp.example then delivered the path-delimiter. Presumably foo.isp.example then delivered the
article to its direct clients. article to its direct clients.
News Article Format June 2003
It appears that foo.isp.example and old.site.example decided to It appears that foo.isp.example and old.site.example decided to
fold the line, on the grounds that it seemed to be getting a fold the line, on the grounds that it seemed to be getting a
little too long. little too long.
6. Optional Headers 6. Optional Headers
None of the headers appearing in this section is required to appear None of the headers appearing in this section is required to appear
in every article but some of them are required in certain types of in every article but some of them are required in certain types of
article, such as followups. Any header defined in this (or any other) article, such as followups. Any header defined in this (or any other)
standard MUST NOT appear more than once in an article unless standard MUST NOT appear more than once in an article unless
skipping to change at page 41, line 5 skipping to change at page 36, line 29
requirement. See section 8 "Duties of Various Agents" for the full requirement. See section 8 "Duties of Various Agents" for the full
picture. picture.
6.1. Reply-To 6.1. Reply-To
The Reply-To-header specifies a reply address(es) to be used for The Reply-To-header specifies a reply address(es) to be used for
personal replies for the poster(s) of the article when this is personal replies for the poster(s) of the article when this is
different from the poster's address(es) given in the From-header. The different from the poster's address(es) given in the From-header. The
content syntax makes use of syntax defined in [RFC 2822]. content syntax makes use of syntax defined in [RFC 2822].
News Article Format April 2003
header =/ Reply-To-header header =/ Reply-To-header
Reply-To-header = "Reply-To" ":" SP Reply-To-content Reply-To-header = "Reply-To" ":" SP Reply-To-content
Reply-To-content = address-list Reply-To-content = address-list
In the absence of Reply-To, the reply address(es) is the address(es) In the absence of Reply-To, the reply address(es) is the address(es)
in the From-header. For this reason a Reply-To SHOULD NOT be included in the From-header.
if it just duplicates the From-header.
NOTE: Use of a Reply-To-header is preferable to including a
similar request in the article body, because replying agents can
take account of Reply-To automatically.
6.1.1. Examples 6.1.1. Examples
Reply-To: John Smith <jsmith@site.example> Reply-To: John Smith <jsmith@site.example>
Reply-To: John Smith <jsmith@site.example>, dave@isp.example Reply-To: John Smith <jsmith@site.example>, dave@isp.example
Reply-To: John Smith <jsmith@site.example>,andrew@isp.example, Reply-To: John Smith <jsmith@site.example>,andrew@isp.example,
fred@site2.example fred@site2.example
6.2. Sender 6.2. Sender
skipping to change at page 41, line 39 skipping to change at page 37, line 4
caused this article to be posted (and hence injected), if that person caused this article to be posted (and hence injected), if that person
or entity is different from that given in the From-header or if more or entity is different from that given in the From-header or if more
than one mailbox appears in the From-header. This header SHOULD NOT than one mailbox appears in the From-header. This header SHOULD NOT
appear in an article unless the sender is different from the poster. appear in an article unless the sender is different from the poster.
This header is appropriate for use by automatic article posters. The This header is appropriate for use by automatic article posters. The
content syntax makes use of syntax defined in [RFC 2822]. content syntax makes use of syntax defined in [RFC 2822].
header =/ Sender-header header =/ Sender-header
Sender-header = "Sender" ":" SP Sender-content Sender-header = "Sender" ":" SP Sender-content
Sender-content = mailbox Sender-content = mailbox
News Article Format June 2003
6.3. Organization 6.3. Organization
The Organization-header is a short phrase identifying the poster's The Organization-header is a short phrase identifying the poster's
organization. organization.
header =/ Organization-header header =/ Organization-header
Organization-header = "Organization" ":" SP Organization-content Organization-header = "Organization" ":" SP Organization-content
Organization-content= unstructured Organization-content= unstructured
NOTE: Posting and injecting agents are discouraged from
providing a default value for this header unless it is
acceptable to all posters using those agents. Unless this header
contains useful information (including some indication of the
posters physical location) posters are discouraged from
including it.
6.4. Keywords 6.4. Keywords
The Keywords field contains a comma separated list of important words The Keywords field contains a comma separated list of important words
and phrases intended to describe some aspect of the content of the and phrases intended to describe some aspect of the content of the
article. The content syntax makes use of syntax defined in [RFC article. The content syntax makes use of syntax defined in [RFC
News Article Format April 2003
2822]. 2822].
header =/ Keywords-header header =/ Keywords-header
Keywords-header = "Keywords" ":" SP Keywords-content Keywords-header = "Keywords" ":" SP Keywords-content
Keywords-content = phrase *( "," phrase ) Keywords-content = phrase *( "," phrase )
NOTE: The list is comma separated, NOT space separated. NOTE: The list is comma separated, NOT space separated.
NOTE: Contrary to the usage defined in [RFC 2822], this standard NOTE: Contrary to the usage defined in [RFC 2822], this standard
does not permit multiple occurrences of this header. does not permit multiple occurrences of this header.
6.5. Summary 6.5. Summary
The Summary-header is a short phrase summarizing the article's The Summary-header is a short phrase summarizing the article's
content. content.
header =/ Summary-header header =/ Summary-header
Summary-header = "Summary" ":" SP Summary-content Summary-header = "Summary" ":" SP Summary-content
Summary-content = unstructured Summary-content = unstructured
The summary should be terse. Authors Ought to avoid trying to cram
their entire article into the headers; even the simplest query
usually benefits from a sentence or two of elaboration and context,
and not all reading agents display all headers. On the other hand the
summary should give more detail than the Subject.
6.6. Distribution 6.6. Distribution
The Distribution-header is an inheritable header (see 4.2.5.2) which The Distribution-header is an inheritable header (see 4.2.5.2) which
specifies geographical or organizational limits to an article's specifies geographical or organizational limits to an article's
propagation. propagation.
header =/ Distribution-header header =/ Distribution-header
Distribution-header = "Distribution" ":" SP Distribution-content Distribution-header = "Distribution" ":" SP Distribution-content
*( ";" extension-parameter ) *( ";" extension-parameter )
Distribution-content= distribution *( dist-delim distribution ) Distribution-content= distribution *( dist-delim distribution )
skipping to change at page 42, line 53 skipping to change at page 38, line 5
distribution = [FWS] distribution-name [FWS] distribution = [FWS] distribution-name [FWS]
distribution-name = ALPHA 1*distribution-rest distribution-name = ALPHA 1*distribution-rest
distribution-rest = ALPHA / "+" / "-" / "_" distribution-rest = ALPHA / "+" / "-" / "_"
Articles MUST NOT be passed between relaying agents or to serving Articles MUST NOT be passed between relaying agents or to serving
agents unless the sending agent has been configured to supply and the agents unless the sending agent has been configured to supply and the
receiving agent to receive at least one of the distributions in the receiving agent to receive at least one of the distributions in the
Distribution-header. Additionally, reading agents MAY also be Distribution-header. Additionally, reading agents MAY also be
configured so that unwanted distributions do not get displayed. configured so that unwanted distributions do not get displayed.
News Article Format June 2003
NOTE: Although it would seem redundant to filter out unwanted NOTE: Although it would seem redundant to filter out unwanted
distributions at both ends of a relaying link (and it is clearly distributions at both ends of a relaying link (and it is clearly
more efficient to do so at the sending end), many sending sites more efficient to do so at the sending end), many sending sites
have been reluctant, historically speaking, to apply such have been reluctant, historically speaking, to apply such
filters (except to ensure that distributions local to their own filters (except to ensure that distributions local to their own
site or cooperating subnet did not escape); moreover they tended site or cooperating subnet did not escape); moreover they tended
to configure their filters on an "all but those listed" basis, to configure their filters on an "all but those listed" basis,
News Article Format April 2003
so that new and hitherto unheard of distributions would not be so that new and hitherto unheard of distributions would not be
caught. Indeed many "hub" sites actually wanted to receive all caught. Indeed many "hub" sites actually wanted to receive all
possible distributions so that they could feed on to their possible distributions so that they could feed on to their
clients in all possible geographical (or organizational) clients in all possible geographical (or organizational)
regions. regions.
Therefore, it is desirable to provide facilities for rejecting Therefore, it is desirable to provide facilities for rejecting
unwanted distributions at the receiving end. Indeed, it may be unwanted distributions at the receiving end. Indeed, it may be
simpler to do so locally than to inform each sending site of simpler to do so locally than to inform each sending site of
what is required, especially in the case of specialized what is required, especially in the case of specialized
skipping to change at page 43, line 31 skipping to change at page 38, line 39
Exceptionally, ALL relaying agents are deemed willing to supply or Exceptionally, ALL relaying agents are deemed willing to supply or
accept the distribution "world", and NO relaying agent should supply accept the distribution "world", and NO relaying agent should supply
or accept the distribution "local". However, "world" SHOULD NEVER be or accept the distribution "local". However, "world" SHOULD NEVER be
mentioned explicitly since it is the default when the Distribution- mentioned explicitly since it is the default when the Distribution-
header is absent entirely. "All" MUST NOT be used as a header is absent entirely. "All" MUST NOT be used as a
distribution-name. Distribution-names SHOULD contain at least three distribution-name. Distribution-names SHOULD contain at least three
characters, except when they are two-letter country names as in [ISO characters, except when they are two-letter country names as in [ISO
3166]. Distribution-names are case-insensitive (i.e. "US", "Us" and 3166]. Distribution-names are case-insensitive (i.e. "US", "Us" and
"us" all specify the same distribution). "us" all specify the same distribution).
Posting agents Ought Not to provide a default Distribution-header Followup agents SHOULD initially supply the same Distribution-header
without giving the poster an opportunity to override it. Followup as found in the precursor.
agents SHOULD initially supply the same Distribution-header as found
in the precursor.
6.7. Followup-To 6.7. Followup-To
The Followup-To-header specifies which newsgroup(s) followups should The Followup-To-header specifies which newsgroup(s) followups should
be posted to. be posted to.
header =/ Followup-To-header header =/ Followup-To-header
Followup-To-header = "Followup-To" ":" SP Followup-To-content Followup-To-header = "Followup-To" ":" SP Followup-To-content
*( ";" extension-parameter ) *( ";" extension-parameter )
Followup-To-content = Newsgroups-content / Followup-To-content = Newsgroups-content /
[FWS] %x70.6F.73.74.65.72 [FWS] [FWS] %x70.6F.73.74.65.72 [FWS]
; which is a case-sensitive "poster" ; which is a case-sensitive "poster"
The syntax is the same as that of the Newsgroups-content, with the The syntax is the same as that of the Newsgroups-content, with the
addition that the keyword "poster" is allowed. In the absence of a addition that the keyword "poster" is allowed. In the absence of a
Followup-To-content, the default newsgroup(s) for a followup are Followup-To-content, the default newsgroup(s) for a followup are
those in the Newsgroups-header, and for this reason the Followup-To- those in the Newsgroups-header.
header SHOULD NOT be included if it just duplicates the Newsgroups-
header. News Article Format June 2003
A Followup-To-header consisting of the keyword "poster" indicates A Followup-To-header consisting of the keyword "poster" indicates
that the poster requests no followups to be sent in response to this that the poster requests no followups to be sent in response to this
article, only personal replies to the article's reply address. article, only personal replies to the article's reply address.
Although the keyword "poster" is case-sensitive, followup agents MAY Although the keyword "poster" is case-sensitive, followup agents MAY
choose to regognize case insensitive forms such as "Poster". choose to regognize case insensitive forms such as "Poster".
News Article Format April 2003
NOTE: A poster who wishes both a personal reply and a followup NOTE: A poster who wishes both a personal reply and a followup
post should include an appropriate Mail-Copies-To-header (6.8). post should include an appropriate Mail-Copies-To-header (6.8).
6.8. Mail-Copies-To 6.8. Mail-Copies-To
The Mail-Copies-To-header indicates whether or not the poster wishes The Mail-Copies-To-header indicates whether or not the poster wishes
to have followups to an article emailed in addition to being posted to have followups to an article emailed in addition to being posted
to Netnews and, if so, establishes the address to which they should to Netnews and, if so, establishes the address to which they should
be sent. be sent.
skipping to change at page 44, line 39 skipping to change at page 39, line 45
this header is absent. this header is absent.
The keyword "poster" indicates that the poster wishes a copy of any The keyword "poster" indicates that the poster wishes a copy of any
followup postings to be emailed to him. followup postings to be emailed to him.
Otherwise, this header contains a copy-addr to which the poster Otherwise, this header contains a copy-addr to which the poster
wishes a copy of any followup postings to be sent. wishes a copy of any followup postings to be sent.
NOTE: Some existing practice uses the keyword "never" in place NOTE: Some existing practice uses the keyword "never" in place
of "nobody" and "always" in place of "poster". These usages are of "nobody" and "always" in place of "poster". These usages are
deprecated, but followup agents MAY observe them. deprecated, but followup agents MAY observe them. The actions
to be taken by by followup agent when following up to an article
The automatic actions of a followup agent in the various cases containing a Mail-Copies-To header are set out in section 8.6.
(subject to manual override by the user) are as follows:
nobody (or when the header is absent)
The followup agent SHOULD NOT, by default, email such a copy and
Ought, especially when there is an explicit "nobody", to issue a
warning and ask for confirmation if the user attempts to do so.
poster
The followup agent Ought, by default, to email a copy, which MUST
then be sent to the address(es) in the Reply-To-header, and in the
absence of that to the address(es) in the From-header.
copy-addr
The followup agent Ought, by default, to email a copy, which MUST
then be sent to the copy-addr.
NOTE: This header is only relevant when posting followups to
Netnews articles, and is to be ignored when sending pure email
replies to the poster, which are handled as prescribed under the
News Article Format April 2003
Reply-To-header (6.1). Whether or not this header will also
find similar usage for replies to messages sent to mailing lists
falls outside the scope of this standard.
When emailing a copy, the followup agent SHOULD also include a
"Posted-And-Mailed: yes" header (6.9).
NOTE: In addition to the Posted-And-Mailed-header, some followup Whether or not this header will also find similar usage for replies
agents also include within the body a mention that the article to messages sent to mailing lists falls outside the scope of this
is both posted and mailed, for the benefit of reading agents standard.
that do not normally show that header.
6.9. Posted-And-Mailed 6.9. Posted-And-Mailed
header =/ Posted-And-Mailed-header header =/ Posted-And-Mailed-header
Posted-And-Mailed-header Posted-And-Mailed-header
= "Posted-And-Mailed" ":" SP Posted-And-Mailed-content = "Posted-And-Mailed" ":" SP Posted-And-Mailed-content
*( ";" extension-parameter ) *( ";" extension-parameter )
Posted-And-Mailed-content Posted-And-Mailed-content
= [CFWS] ( "yes" / "no" ) [CFWS] = [CFWS] ( "yes" / "no" ) [CFWS]
News Article Format June 2003
This header, when used with the "yes" keyword, indicates that the This header, when used with the "yes" keyword, indicates that the
article has been both posted to the specified newsgroups and emailed. article has been both posted to the specified newsgroups and emailed.
It SHOULD be used when replying to the poster of an article to which It SHOULD be used when replying to the poster of an article to which
this one is a followup (see the Mail-Copies-To-header in section 6.8) this one is a followup (see the Mail-Copies-To-header in section 6.8)
and it MAY be used when any article is also mailed to a recipient(s) and it MAY be used when any article is also mailed to a recipient(s)
identified in a To- and/or Cc-header that is also present. The "no" identified in a To- and/or Cc-header that is also present. The "no"
keyword is included for the sake of completeness; it MAY be used to keyword is included for the sake of completeness; it MAY be used to
indicate the opposite state, but is redundant insofar as it only indicate the opposite state, but is redundant insofar as it only
describes the default state when this header is absent. describes the default state when this header is absent.
skipping to change at page 45, line 52 skipping to change at page 40, line 31
versions of the article. The bodies MUST be identical in both, apart versions of the article. The bodies MUST be identical in both, apart
from a possible change of Content-Transfer-Encoding. from a possible change of Content-Transfer-Encoding.
NOTE: This leaves open the question of whether a To- or a Cc- NOTE: This leaves open the question of whether a To- or a Cc-
header should appear in the posted version. Naturally, a Bcc- header should appear in the posted version. Naturally, a Bcc-
header should not appear, except in a form which indicates that header should not appear, except in a form which indicates that
there are additional unspecified recipients. there are additional unspecified recipients.
6.10. References 6.10. References
The References-header lists CFWS-separated message identifiers of The References-header is an inheritable header (see 4.2.5.2) which
precursors. The content syntax makes use of syntax defined in [RFC lists CFWS-separated message identifiers of the article's precursors,
2822], subject to the same revisions as in section 5.3. as described in 8.6. The content syntax makes use of syntax defined
in [RFC 2822] (but see the revised definition of msg-id in section
2.4.2).
header =/ References-header header =/ References-header
References-header = "References" ":" SP References-content References-header = "References" ":" SP References-content
References-content = [CFWS] msg-id *( CFWS msg-id ) [CFWS] References-content = [CFWS] msg-id *( CFWS msg-id ) [CFWS]
News Article Format April 2003
NOTE: This differs from the syntax of [RFC 2822] by requiring at NOTE: This differs from the syntax of [RFC 2822] by requiring at
least one CFWS between the msg-ids (a SP at this point was an least one CFWS between the msg-ids (a SP at this point was an
[RFC 1036] requirement). [RFC 1036] requirement).
A followup MUST have a References-header, and an article that is not A followup MUST have a References-header, and an article that is not
a followup MUST NOT have a References-header. In a followup, if the a followup MUST NOT have a References-header.
precursor did not have a References-header, the followup's
References-content MUST be formed by the message identifier of the
precursor. A followup to an article which had a References-header
MUST have a References-header containing the precursor's References-
content (subject to trimming as described below) plus the precursor's
message identifier appended to the end of the list (separated from it
by CFWS).
Followup agents SHOULD NOT trim message identifiers out of a
References-header unless the number of message identifiers exceeds
21, at which time trimming SHOULD be done by removing sufficient
identifiers starting with the second so as to bring the total down to
21 (but the first message identifier MUST NOT be trimmed). However,
it would be wrong to assume that References-headers containing more
than 21 message identifiers will not occur.
6.10.1. Examples 6.10.1. Examples
References: <i4g587y@site1.example> References: <i4g587y@site1.example>
References: <i4g587y@site1.example> <kgb2231+ee@site2.example> References: <i4g587y@site1.example> <kgb2231+ee@site2.example>
References: <i4g587y@site1.example> <kgb2231+ee@site2.example> References: <i4g587y@site1.example> <kgb2231+ee@site2.example>
<222@site1.example> <87tfbyv@site7.example> <222@site1.example> <87tfbyv@site7.example>
<67jimf@site666.example> <67jimf@site666.example>
References: <i4g587y@site1.example> <kgb2231+ee@site2.example> References: <i4g587y@site1.example> <kgb2231+ee@site2.example>
<tisjits@smeghead.example> <tisjits@smeghead.example>
News Article Format June 2003
6.11. Expires 6.11. Expires
The Expires-header specifies a date and time when the article is The Expires-header specifies a date and time when the article is
deemed to be no longer relevant and could usefully be removed deemed to be no longer relevant and could usefully be removed
("expired"). The content syntax makes use of syntax defined in [RFC ("expired"). The content syntax makes use of syntax defined in [RFC
2822]. 2822].
header =/ Expires-header header =/ Expires-header
Expires-header = "Expires" ":" SP Expires-content Expires-header = "Expires" ":" SP Expires-content
*( ";" extension-parameter ) *( ";" extension-parameter )
Expires-content = date-time Expires-content = date-time
An Expires-header should only be used in an article if the requested NOTE: This header is suitable for specifying both unusually
expiry time is earlier or later than the time typically to be short and unusually long expiry times; there is little point in
expected for such articles. Local policy for each serving agent will using it in other circumstances.
dictate whether and when this header is obeyed and posters SHOULD NOT
depend on it being completely followed.
News Article Format April 2003
6.12. Archive 6.12. Archive
This optional header provides an indication of the poster's intent This optional header provides an indication of the poster's intent
regarding preservation of the article in publicly accessible long- regarding preservation of the article in publicly accessible long-
term or permanent storage. term or permanent storage.
header =/ Archive-header header =/ Archive-header
Archive-header = "Archive" ":" SP Archive-content Archive-header = "Archive" ":" SP Archive-content
*( ";" ( Archive-parameter / *( ";" ( Archive-parameter /
skipping to change at page 47, line 43 skipping to change at page 42, line 5
policies established for particular newsgroups or hierarchies. policies established for particular newsgroups or hierarchies.
NOTE: Posters are cautioned that some sites may not implement NOTE: Posters are cautioned that some sites may not implement
the "no" option of the Archive-header correctly. In some the "no" option of the Archive-header correctly. In some
jurisdictions non-compliance with this header may constitute a jurisdictions non-compliance with this header may constitute a
breach of copyright or of other legal provisions. Moreover, breach of copyright or of other legal provisions. Moreover,
even if this header prevents the poster's words from being even if this header prevents the poster's words from being
archived publicly, it does nothing to prevent the archiving of a archived publicly, it does nothing to prevent the archiving of a
followup in which those words are quoted. followup in which those words are quoted.
News Article Format June 2003
6.13. Control 6.13. Control
The Control-header marks the article as a control message, and The Control-header marks the article as a control message, and
specifies the desired actions (additional to the usual ones of specifies the desired actions (additional to the usual ones of
storing and/or relaying the article). storing and/or relaying the article).
header =/ Control-header header =/ Control-header
Control-header = "Control" ":" SP Control-content Control-header = "Control" ":" SP Control-content
*( ";" extension-parameter ) *( ";" extension-parameter )
Control-content = [CFWS] control-message [CFWS] Control-content = [CFWS] control-message [CFWS]
control-message = <empty> control-message = <empty>
However, the rule given above for control-message is incomplete. However, the rule given above for control-message is incomplete.
Further alternatives will be added incrementally as the various Further alternatives will be added incrementally as the various
control-messages are introduced in section 7, or in extensions to control-messages are introduced in section 7, or in extensions to
this standard, using the "=/" notation defined in [RFC 2234]. For this standard, using the "=/" notation defined in [RFC 2234]. For
example, a typical CONTROL-message would be defined as follows: example, a putative Control-message would be defined as follows:
News Article Format April 2003
control-message =/ CONTROL-message control-message =/ Control-message
CONTROL-message = "CONTROL" CONTROL-arguments Control-message = "Control" Control-arguments
CONTROL-arguments = <the argument(s) specific to that Control-arguments = <the argument(s) specific to that
CONTROL-message> Control-message>
where "CONTROL" is a "verb" which is (and MUST be) of the syntactic where "Control" is a "verb" which is (and MUST be) of the syntactic
form of a token and CONTROL-arguments MUST be of the syntactic form form of a token and Control-arguments MUST be of the syntactic form
of a CFWS-separated list of values (which may require the use of of a CFWS-separated list of values (which may require the use of
quoted-strings if any tspecials or non-ASCII characters are quoted-strings if any tspecials or non-ASCII characters are
involved). involved).
The verb indicates what action should be taken, and the argument(s) The verb indicates what action should be taken, and the argument(s)
(if any) supply details. In some cases, the body of the article may (if any) supply details. In some cases, the body of the article may
also contain details. also contain details.
An article with a Control-header MUST NOT also have a Supersedes- An article with a Control-header MUST NOT also have a Supersedes-
header. header.
NOTE: The presence of a Subject-header starting with the string NOTE: The presence of a Subject-header starting with the string
"cmsg " and followed by a Control-message MUST NOT be construed, "cmsg " and followed by a Control-message MUST NOT be construed,
in the absence of a proper Control-header, as a request to in the absence of a proper Control-header, as a request to
perform that control action (as may have occurred in some legacy perform that control action (as may have occurred in some legacy
software). See also section 5.4. software).
6.14. Approved 6.14. Approved
The Approved-header indicates the mailing addresses (possibly The Approved-header indicates the mailing addresses (possibly
including the full names) of the persons or entities approving the including the full names) of the persons or entities approving the
article for posting. article for posting.
header =/ Approved-header header =/ Approved-header
Approved-header = "Approved" ":" SP Approved-content Approved-header = "Approved" ":" SP Approved-content
*( ";" extension-parameter ) *( ";" extension-parameter )
Approved-content = From-content ; see 5.2 Approved-content = From-content ; see 5.2
News Article Format June 2003
Each mailbox contained in the Approved-content MUST be that of one of Each mailbox contained in the Approved-content MUST be that of one of
the person(s) or entity(ies) in question, and one of those mailboxes the person(s) or entity(ies) in question, and one of those mailboxes
MUST be that of the actual injector of the article. MUST be that of the actual injector of the article.
An Approved-header is required in all postings to moderated An Approved-header is required in all postings to moderated
newsgroups. If this header is not present in such postings, then newsgroups. If this header is not present in such postings, then
serving agents MUST (and relaying agents MAY) reject the article. serving agents MUST (and relaying agents MAY) reject the article.
Please see section 8.2.2 for how injecting agents should treat Please see section 8.2.2 for how injecting agents should treat
postings to moderated groups that do not contain this header. postings to moderated groups that do not contain this header.
An Approved-header is also required in certain control messages, to An Approved-header is also required in certain control messages, to
reduce the risks of accidental or unauthorized posting of same. reduce the risks of accidental or unauthorized posting of same.
NOTE: The presence of an Approved-header indicates that the NOTE: The presence of an Approved-header indicates that the
person or entity identified claims to have the necessary person or entity identified claims to have the necessary
authority to post the article in question, thus enabling sites authority to post the article in question, thus enabling sites
that dispute that authority to refuse to accept or to act upon that dispute that authority to refuse to accept or to act upon
it. However, the mere presence of the header is insufficient to it. However, the mere presence of the header is insufficient to
provide assurance that it indeed originated from that person or provide assurance that it indeed originated from that person or
News Article Format April 2003
entity, and it is therefore desirable that it be included within entity, and it is therefore desirable that it be included within
some digital signature scheme (see 7.1), especially in the case some digital signature scheme (see 7.1), especially in the case
of control messages (section 7). of control messages (section 7).
6.15. Supersedes 6.15. Supersedes
The Supersedes-header contains a message identifier specifying an The Supersedes-header contains a message identifier specifying an
article to be superseded upon the arrival of this one. The specified article to be superseded upon the arrival of this one. The specified
article MUST be treated as though a "cancel" control message had article MUST be treated as though a "cancel" control message had
arrived for the article (but observe that a site MAY choose not to arrived for the article (but observe that a site MAY choose not to
honour a "cancel" message, especially if its authenticity is in honour a "cancel" message, especially if its authenticity is in
doubt). The content syntax makes use of syntax defined in [RFC 2822], doubt). The content syntax makes use of syntax defined in [RFC 2822]
subject to the same revisions as in 5.3. (but see the revised definition of msg-id in section 2.4.2).
header =/ Supersedes-header header =/ Supersedes-header
Supersedes-header = "Supersedes" ":" SP Supersedes-content Supersedes-header = "Supersedes" ":" SP Supersedes-content
Supersedes-content = [CFWS] msg-id [CFWS] Supersedes-content = [CFWS] msg-id [CFWS]
NOTE: There is no "c" in "Supersedes". NOTE: There is no "c" in "Supersedes".
NOTE: The Supersedes-header defined here has no connection with NOTE: The Supersedes-header defined here has no connection with
the Supersedes-header that sometimes appears in Email messages the Supersedes-header that sometimes appears in Email messages
converted from X.400 according to [RFC 2156]; in particular, the converted from X.400 according to [RFC 2156]; in particular, the
skipping to change at page 49, line 41 skipping to change at page 44, line 4
Thus when an article contains a Supersedes-header, the old article Thus when an article contains a Supersedes-header, the old article
mentioned SHOULD be withdrawn from circulation or access, as in a mentioned SHOULD be withdrawn from circulation or access, as in a
cancel message (7.3), and the new article inserted into the system as cancel message (7.3), and the new article inserted into the system as
any other new article would have been. any other new article would have been.
Whatever security or authentication checks are normally applied to a Whatever security or authentication checks are normally applied to a
Control cancel message (or may be prescribed for such messages by Control cancel message (or may be prescribed for such messages by
some extension to this standard - see the remarks in 7.1 and 7.3) some extension to this standard - see the remarks in 7.1 and 7.3)
MUST also be applied to an article with a Supersedes-header. In the MUST also be applied to an article with a Supersedes-header. In the
News Article Format June 2003
event of the failure of such checks, the article SHOULD be discarded, event of the failure of such checks, the article SHOULD be discarded,
or at most stored as an ordinary article. or at most stored as an ordinary article.
6.16. Xref 6.16. Xref
The Xref-header is a variant header (4.2.5.3) which indicates where The Xref-header is a variant header (4.2.5.3) which indicates where
an article was filed by the last serving agent to process it. an article was filed by the last serving agent to process it.
header =/ Xref-header header =/ Xref-header
Xref-header = "Xref" ":" SP Xref-content Xref-header = "Xref" ":" SP Xref-content
*( ";" extension-parameter ) *( ";" extension-parameter )
Xref-content = [CFWS] server-name 1*( CFWS location ) [CFWS] Xref-content = [CFWS] server-name 1*( CFWS location ) [CFWS]
server-name = path-identity ; see 5.6.1 server-name = path-identity ; see 5.6.1
location = newsgroup-name ":" article-locator location = newsgroup-name ":" article-locator
article-locator = 1*( %x21-27 / %x29-3A / %x3C-7E ) article-locator = 1*( %x21-27 / %x29-3A / %x3C-7E )
; US-ASCII printable characters ; US-ASCII printable characters
; except '(' and ';' ; except '(' and ';'
News Article Format April 2003
The server-name is included so that software can determine which The server-name is included so that software can determine which
serving agent generated the header. The locations specify what serving agent generated the header. The locations specify what
newsgroups the article was filed under (which may differ from those newsgroups the article was filed under (which may differ from those
in the Newsgroups-header) and where it was filed under them. The in the Newsgroups-header) and where it was filed under them. The
exact form of an article-locator is implementation-specific. exact form of an article-locator is implementation-specific.
NOTE: The traditional form of an article-locator is a decimal NOTE: The traditional form of an article-locator is a decimal
number, with articles in each newsgroup numbered consecutively number, with articles in each newsgroup numbered consecutively
starting from 1. NNTP demands that such a model be provided, and starting from 1. NNTP demands that such a model be provided, and
skipping to change at page 50, line 42 skipping to change at page 45, line 4
header =/ Lines-header header =/ Lines-header
Lines-header = "Lines" ":" SP Lines-content Lines-header = "Lines" ":" SP Lines-content
*( ";" extension-parameter ) *( ";" extension-parameter )
Lines-content = [CFWS] 1*DIGIT [CFWS] Lines-content = [CFWS] 1*DIGIT [CFWS]
The line count includes all body lines, including the signature if The line count includes all body lines, including the signature if
any, including empty lines (if any) at the beginning or end of the any, including empty lines (if any) at the beginning or end of the
body, and including the whole of all MIME message and multipart parts body, and including the whole of all MIME message and multipart parts
contained in the body (the single empty separator line between the contained in the body (the single empty separator line between the
News Article Format June 2003
headers and the body is not part of the body). The "body" here is the headers and the body is not part of the body). The "body" here is the
body as found in the posted article as transmitted by the posting body as found in the posted article as transmitted by the posting
agent. agent.
This header is to be regarded as obsolete, and it will likely be This header is to be regarded as obsolete, and it will likely be
removed entirely in a future version of this standard. In the removed entirely in a future version of this standard. In the
meantime, its use is deprecated. meantime, its use is deprecated.
6.18. User-Agent 6.18. User-Agent
The User-Agent-header contains information about the user agent The User-Agent-header contains information about the user agent
(typically a newsreader) generating the article, for statistical (typically a newsreader) generating the article, for statistical
purposes and tracing of standards violations to specific software purposes and tracing of standards violations to specific software
needing correction. Although not one of the mandatory headers, needing correction. Although not one of the mandatory headers,
posting agents SHOULD normally include it. It is also intended that posting agents SHOULD normally include it. It is also intended that
this header be suitable for use in Email. this header be suitable for use in Email.
News Article Format April 2003
header =/ User-Agent-header header =/ User-Agent-header
User-Agent-header = "User-Agent" ":" SP User-Agent-content User-Agent-header = "User-Agent" ":" SP User-Agent-content
*( ";" extension-parameter ) *( ";" extension-parameter )
User-Agent-content = product *( CFWS product ) User-Agent-content = product *( CFWS product )
product = [CFWS] token [CFWS] [ "/" product-version ] product = [CFWS] token [CFWS] [ "/" product-version ]
product-version = [CFWS] token [CFWS] product-version = [CFWS] token [CFWS]
This header MAY contain multiple product-tokens identifying the agent This header MAY contain multiple product-tokens identifying the agent
and any subproducts which form a significant part of the posting and any subproducts which form a significant part of the posting
agent, listed in order of their significance for identifying the agent, listed in order of their significance for identifying the
skipping to change at page 51, line 32 skipping to change at page 45, line 48
themselves. themselves.
NOTE: Minor variations from [RFC 2616] which describes a similar NOTE: Minor variations from [RFC 2616] which describes a similar
facility for the HTTP protocol: facility for the HTTP protocol:
1. "{" and "}" are allowed in a token (product and product- 1. "{" and "}" are allowed in a token (product and product-
version) in Netnews, version) in Netnews,
2. Comments are permitted wherever whitespace is allowed. 2. Comments are permitted wherever whitespace is allowed.
NOTE: Comments should be restricted to information regarding the NOTE: This header supersedes the role performed redundantly by
product named to their left, such as its full name or platform experimental headers such as X-Newsreader, X-Mailer, X-Posting-
information, and should be concise. Use as an advertising medium Agent, X-Http-User-Agent, and other headers previously used on
(in the mundane sense) is discouraged. Usenet and in Email for this purpose. Use of these experimental
headers SHOULD be discontinued in favor of the single, standard
User-Agent-header.
6.18.1. Examples 6.18.1. Examples
User-Agent: tin/1.2-PL2
User-Agent: tin/1.3-950621beta-PL0 (Unix) User-Agent: tin/1.3-950621beta-PL0 (Unix)
User-Agent: tin/unoff-1.3-BETA-970813 (UNIX) (Linux/2.0.30 (i486))
User-Agent: tin/pre-1.4-971106 (UNIX) (Linux/2.0.30 (i486)) User-Agent: tin/pre-1.4-971106 (UNIX) (Linux/2.0.30 (i486))
User-Agent: Mozilla/4.02b7 (X11; I; en; HP-UX B.10.20 9000/712) User-Agent: Mozilla/4.02b7 (X11; I; en; HP-UX B.10.20 9000/712)
News Article Format June 2003
User-Agent: Microsoft-Internet-News/4.70.1161 User-Agent: Microsoft-Internet-News/4.70.1161
User-Agent: Gnus/5.4.64 XEmacs/20.3beta17 ("Bucharest") User-Agent: Gnus/5.4.64 XEmacs/20.3beta17 ("Bucharest")
User-Agent: Pluto/1.05h (RISC-OS/3.1) NewsHound/1.30
User-Agent: inn/1.7.2 User-Agent: inn/1.7.2
User-Agent: telnet User-Agent: telnet
NOTE: This header supersedes the role performed redundantly by
experimental headers such as X-Newsreader, X-Mailer, X-Posting-
Agent, X-Http-User-Agent, and other headers previously used on
Usenet and in Email for this purpose. Use of these experimental
headers SHOULD be discontinued in favor of the single, standard
User-Agent-header.
News Article Format April 2003
6.19. Injector-Info 6.19. Injector-Info
The Injector-Info-header SHOULD be added to each article by the The Injector-Info-header SHOULD be added to each article by the
injecting agent in order to provide information as to how that injecting agent in order to provide information as to how that
article entered the Netnews system and to assist in tracing its true article entered the Netnews system and to assist in tracing its true
origin. origin.
header =/ Injector-Info-header header =/ Injector-Info-header
Injector-Info-header Injector-Info-header
= "Injector-Info" ":" SP Injector-Info-content = "Injector-Info" ":" SP Injector-Info-content
skipping to change at page 52, line 55 skipping to change at page 47, line 5
= <a parameter with attribute "posting-date" = <a parameter with attribute "posting-date"
and value some date-time> and value some date-time>
An Injector-Info-header MUST NOT be added to an article by any agent An Injector-Info-header MUST NOT be added to an article by any agent
other than an injecting agent. Any Injector-Info-header present when other than an injecting agent. Any Injector-Info-header present when
an article arrives at an injecting agent MUST be removed. In an article arrives at an injecting agent MUST be removed. In
particular if, for some exceptional reason (8.2.2), an article gets particular if, for some exceptional reason (8.2.2), an article gets
injected twice, the Injector-Info-header will always relate to the injected twice, the Injector-Info-header will always relate to the
second injection. second injection.
News Article Format June 2003
The path-identity MUST be the same as the path-identity prepended to The path-identity MUST be the same as the path-identity prepended to
the Path-header by that same injecting agent which, following section the Path-header by that same injecting agent which, following section
5.6.2, MUST therefore be a fully qualified domain name (FQDN) 5.6.2, MUST therefore be a fully qualified domain name (FQDN)
mailable address. mailable address.
News Article Format April 2003
Although comments and folding of white space are permitted throughout Although comments and folding of white space are permitted throughout
the Injector-Info-content specification, it is RECOMMENDED that the Injector-Info-content specification, it is RECOMMENDED that
folding is not used within any parameter (but only before or after folding is not used within any parameter (but only before or after
the ";" separating those parameters), and that comments are only used the ";" separating those parameters), and that comments are only used
following the last parameter. It is also RECOMMENDED that such following the last parameter. It is also RECOMMENDED that such
parameters as are present are included in the order in which they parameters as are present are included in the order in which they
have been defined in the syntax above. An injecting agent SHOULD use have been defined in the syntax above. An injecting agent SHOULD use
a consistent form of this header for all articles emanating from the a consistent form of this header for all articles emanating from the
same or similar origins. same or similar origins.
skipping to change at page 53, line 41 skipping to change at page 47, line 46
but nowhere-documented headers such as "NNTP-Posting-Host", but nowhere-documented headers such as "NNTP-Posting-Host",
"NNTP-Posting-Date" and "X-Trace". These headers are now "NNTP-Posting-Date" and "X-Trace". These headers are now
deprecated, and any of them present when an article arrives at deprecated, and any of them present when an article arrives at
an injecting agent SHOULD also be removed as above. an injecting agent SHOULD also be removed as above.
6.19.1. Usage of Injector-Info-parameters 6.19.1. Usage of Injector-Info-parameters
The purpose of these parameters is to enable the injecting agent to The purpose of these parameters is to enable the injecting agent to
make assertions about the origin of the article, in fulfilment of its make assertions about the origin of the article, in fulfilment of its
responsibilities towards the rest of the network as set out in responsibilities towards the rest of the network as set out in
section 8.2. These assertions can then be utilized as follows: section 8.2.
1. To enable the administrator of the injecting agent to respond to
complaints and queries concerning the article. For this purpose,
the parameters included SHOULD be sufficient to enable the
administrator to identify its true origin (which parameters are
best suited to this purpose will vary with the nature of the
injecting site and of its relationship to the posters who use it -
there is no benefit in including parameters which contribute
nothing to this aim). An administrator MAY, with those parameters
where the syntax so allows, use cryptic notations interpretable
only by himself if he considers it appropriate to protect the
privacy of that origin.
2. To enable relaying, serving and reading agents to recognize
articles from origins which they might wish to reject, divert, or
otherwise handle specially, for reasons of site policy.
News Article Format April 2003
3. To enable the timely identification of spews of articles arising
from a common origin.
An injecting agent MUST NOT include any Injector-Info-parameter An injecting agent MUST NOT include any Injector-Info-parameter
unless it has positive evidence of its correctness. An injecting unless it has positive evidence of its correctness. An injecting
agent MAY also include extension-parameters with x-attributes which agent MAY also include extension-parameters with x-attributes which
will assist in identifying the origin of the article. will assist in identifying the origin of the article.
NOTE: Administrators of injecting agents can choose which
selection of the following parameters best enables them to fulfil
their responsibilities. Some of these parameters identify the
source of the article explicitly whereas others do so indirectly,
thus affording more privacy to posters who value their anonymity,
but also making harder the tracking of malicious disruption of the
network, especially so if the administrators choose not to
cooperate. There is thus a balance to be struck between the needs
of privacy on the one hand and the good order of Usenet on the
other, and administrators need to be aware of this when
formulating their policies.
6.19.1.1. The posting-host-parameter 6.19.1.1. The posting-host-parameter
If a dot-atom is present, it MUST be a FQDN identifying the specific If a dot-atom is present, it MUST be a FQDN identifying the specific
host from which the injecting agent received the article. host from which the injecting agent received the article.
Alternatively, an IP address (IPv4address or IPv6address) identifies Alternatively, an IP address (IPv4address or IPv6address) identifies
that host. If both forms are present, then they MUST identify the that host. If both forms are present, then they MUST identify the
same host, or at least have done so at the time the article was same host, or at least have done so at the time the article was
injected. injected.
News Article Format June 2003
NOTE: It is commonly the case that this parameter identifies a NOTE: It is commonly the case that this parameter identifies a
dial-up point-of-presence, in which case a posting-account or dial-up point-of-presence, in which case a posting-account or
logging-data may need to be consulted to find the true origin of logging-data may need to be consulted to find the true origin of
the article. the article.
6.19.1.2. The posting-account-parameter 6.19.1.2. The posting-account-parameter
This parameter identifies the source from which the injecting agent This parameter identifies the source from which the injecting agent
received the article. It SHOULD be in a cryptic notation received the article. It SHOULD be in a cryptic notation
understandable only by the administrator of the injecting agent, but understandable only by the administrator of the injecting agent, but
skipping to change at page 55, line 4 skipping to change at page 48, line 32
6.19.1.3. The posting-sender-parameter 6.19.1.3. The posting-sender-parameter
This parameter identifies the mailbox of the verified sender of the This parameter identifies the mailbox of the verified sender of the
article (alternatively, it uses the token "verified" to indicate that article (alternatively, it uses the token "verified" to indicate that
at least any addr-spec in the Sender-header of the article, or in the at least any addr-spec in the Sender-header of the article, or in the
From-header if the Sender-header is absent, is correct). From-header if the Sender-header is absent, is correct).
NOTE: An injecting agent is unlikely to be able to make use of NOTE: An injecting agent is unlikely to be able to make use of
this parameter except in cases where it is running on a machine this parameter except in cases where it is running on a machine
which is aware of the user-space in which the posting agent is which is aware of the user-space in which the posting agent is
News Article Format April 2003
operating. This parameter should be used in preference to a operating. This parameter should be used in preference to a
posting-account-parameter in such situations. posting-account-parameter in such situations.
6.19.1.4. The posting-logging-parameter 6.19.1.4. The posting-logging-parameter
This parameter contains information (typically a session number or This parameter contains information (typically a session number or
other non-persistent means of identifying a posting account) which other non-persistent means of identifying a posting account) which
will enable the true origin of the article to be determined by will enable the true origin of the article to be determined by
reference to logging information kept by the injecting agent. reference to logging information kept by the injecting agent.
6.19.1.5. The posting-date-parameter 6.19.1.5. The posting-date-parameter
This parameter identifies the time at which the article was injected This parameter identifies the time at which the article was injected
(as distinct from the Date-header, which indicates when it was (as distinct from the Date-header, which indicates when it was
written). written).
6.19.2. Example 6.19.2. Example
Injector-Info: news2.isp.net; posting-host=modem-15.pop.isp.net; Injector-Info: news2.isp.net; posting-host=modem-15.pop.isp.net;
posting-account=client0002623; logging-data=2427; posting-account=client0002623; logging-data=2427;
posting-date="Wed, 2 Aug 2000 20:05:33 -0100 (BST)" posting-date="Wed, 2 Aug 2000 20:05:33 +0100 (BST)"
6.20. Complaints-To 6.20. Complaints-To
The Complaints-To-header is added to an article by an injecting agent The Complaints-To-header is added to an article by an injecting agent
in order to indicate the mailbox to which complaints concerning the in order to indicate the mailbox to which complaints concerning the
poster of the article may be sent. poster of the article may be sent. The content syntax makes use of
syntax defined in [RFC 2822].
News Article Format June 2003
header =/ Complaints-To-header header =/ Complaints-To-header
Complaints-To-header Complaints-To-header
= "Complaints-To" ":" SP Complaints-To-content = "Complaints-To" ":" SP Complaints-To-content
Complaints-To-content Complaints-To-content
= address-list = address-list
A Complaints-To-header MUST NOT be added to an article by any agent A Complaints-To-header MUST NOT be added to an article by any agent
other than an injecting agent. Any Complaints-To-header present when other than an injecting agent. Any Complaints-To-header present when
an article arrives at an injecting agent MUST be removed. In an article arrives at an injecting agent MUST be removed. In
skipping to change at page 56, line 5 skipping to change at page 49, line 31
behaviour of the poster of the article; it SHOULD NOT be used for behaviour of the poster of the article; it SHOULD NOT be used for
matters concerning propagation, protocol problems, etc. which should matters concerning propagation, protocol problems, etc. which should
be addressed to "usenet@" or "news@" the path-identity which was be addressed to "usenet@" or "news@" the path-identity which was
prepended to the Path-header by the injecting agent, in accordance prepended to the Path-header by the injecting agent, in accordance
with section 5.6.2. In the absence of this header, complaints with section 5.6.2. In the absence of this header, complaints
concerning a poster's behaviour MAY be addressed to "abuse@" that concerning a poster's behaviour MAY be addressed to "abuse@" that
path-identity (although section 5.6.2 provides no obligation for that path-identity (although section 5.6.2 provides no obligation for that
address to be mailable at an injecting agent that is not provided for address to be mailable at an injecting agent that is not provided for
the use of the general public). the use of the general public).
News Article Format April 2003
6.21. MIME headers 6.21. MIME headers
6.21.1. Syntax 6.21.1. Syntax
The following headers may be used within articles conforming to this The following headers may be used within articles conforming to this
standard. standard.
MIME-Version: [RFC 2045] MIME-Version: [RFC 2045]
Content-Type: [RFC 2045],[RFC 2046] Content-Type: [RFC 2045],[RFC 2046]
Content-Transfer-Encoding: [RFC 2045] Content-Transfer-Encoding: [RFC 2045]
skipping to change at page 56, line 37 skipping to change at page 50, line 4
sections. Moreover, extensions to those standards registered in sections. Moreover, extensions to those standards registered in
accordance with [RFC 2048] are also available for use within Netnews, accordance with [RFC 2048] are also available for use within Netnews,
as indeed is any other header in the Content-* series which has a as indeed is any other header in the Content-* series which has a
sensible interpretation within Netnews. sensible interpretation within Netnews.
Insofar as the syntax for these headers, as given in those RFCs does Insofar as the syntax for these headers, as given in those RFCs does
not specify precisely where whitespace and comments may occur not specify precisely where whitespace and comments may occur
(whether in the form of WSP, FWS or CFWS), the usage defined in this (whether in the form of WSP, FWS or CFWS), the usage defined in this
standard, and failing that in [RFC 2822], and failing that in [RFC standard, and failing that in [RFC 2822], and failing that in [RFC
822] MUST be followed. In particular, there MUST NOT be any WSP 822] MUST be followed. In particular, there MUST NOT be any WSP
News Article Format June 2003
between a header-name and the following colon and there MUST be a SP between a header-name and the following colon and there MUST be a SP
following that colon. following that colon.
6.21.2. Content-Type 6.21.2. Content-Type
If the contents of an article is something other than plain text in If the contents of an article is something other than plain text in
the US-ASCII charset (these being the default assumptions), an the US-ASCII charset (these being the default assumptions), an
appropriate Content-Type-header MUST be included. appropriate Content-Type-header MUST be included.
When the Content-Type is "text/plain", the recommendations and limits
on line lengths set out in section 4.5 Ought to be observed.
The acceptability of other subtypes of Content-Type: "text" (such as
"text/html") is a matter of policy (see 1.1), and posters Ought Not
to use them unless established policy or custom in the particular
hierarchies or groups involved so allows. Moreover, even in those
cases, for the benefit of readers who see it only in its transmitted
form, the material SHOULD be "pretty-printed" (for example by
restricting its line length as above and by keeping sequences which
control its layout or style separate from the meaningful text).
In the same way, Content-Types requiring special processing for their
display, such as "application", "image", "audio", "video" and
"multipart/related" are discouraged except in groups specifically
News Article Format April 2003
intended (by policy or custom) to include them. Exceptionally, those
application types defined in [RFC 1847] and [RFC 3156] for use within
"multipart/signed" articles, and the type "application/pgp-keys" (or
other similar types containing digital certificates) may be used
freely.
Reading agents SHOULD NOT, unless explicitly configured otherwise, Reading agents SHOULD NOT, unless explicitly configured otherwise,
act automatically on Application types which could change the state act automatically on Application types which could change the state
of that agent (e.g. by writing or modifying files), except in the of that agent (e.g. by writing or modifying files), except in the
case of those prescribed for use in control messages (7.2.1.2 and case of those prescribed for use in control messages (7.2.1.2 and
7.2.4.1). 7.2.4.1).
6.21.2.1. Message/partial
The Content-Type "message/partial" MAY be used to split a long news The Content-Type "message/partial" MAY be used to split a long news
article into several smaller ones. article into several smaller ones. However, breaking long texts into
several parts is usually unnecessary, since modern transport agents
NOTE: This Content-Type is not recommended for textual articles should have no difficulty in handling articles of arbitrary length,
because the Content-Type, and in particular the charset, of the although it may be useful to break long binaries.
complete article cannot be determined by examination of the
second and subsequent parts, and hence it is not possible to
read them as separate articles (except when they are written in
pure US-ASCII). Moreover, for full compliance with [RFC 2046] it
would be necessary to use the "quoted-printable" encoding to
ensure the material was 7bit-safe. In any case, breaking such
long texts into several parts is usually unnecessary, since
modern transport agents should have no difficulty in handling
articles of arbitrary length.
On the other hand, "message/partial" may be useful for binaries
of excessive length, since reading of the individual parts on
their own is not required and they would likely be encoded in a
manner that was 7bit-safe.
IF this Content-Type is used, then the "id" parameter SHOULD be in
the form of a unique message identifier (but different from that in
the Message-ID-header of any of the parts). The second and subsequent
parts SHOULD contain References-headers referring to all the previous
parts, thus enabling reading agents with threading capabilities to
present them in the correct order. Reading agents MAY then provide a
facility to recombine the parts into a single article (but this
standard does not require them to do so).
6.21.2.2. Message/rfc822 IF the Content-Type "message/partial" is used, then the "id"
parameter SHOULD be in the form of a unique message identifier (but
different from that in the Message-ID-header of any of the parts).
The second and subsequent parts SHOULD contain References-headers
referring to all the previous parts, thus enabling reading agents
with threading capabilities to present them in the correct order.
Reading agents MAY then provide a facility to recombine the parts
into a single article (but this standard does not require them to do
so).
The Content-Type "message/rfc822" should be used for the The Content-Type "message/rfc822" should be used for the
encapsulation (whether as part of another news article or, more encapsulation (whether as part of another news article or, more
usually, as part of an email message) of complete news articles which usually, as part of an email message) of complete news articles which
have already been posted to Netnews and which are for the information have already been posted to Netnews and which are for the information
of the recipient, and do not constitute a request to repost them of the recipient, and do not constitute a request to repost them
(refer to 6.21.6.2 for the now obsolete "message/news" formerly (refer to 6.21.6.2 for the now obsolete "message/news" formerly
intended for this purpose). intended for this purpose).
News Article Format April 2003
In the case where such an encapsulated news article is to be
transported by email and it has Content-Transfer-Encoding "8bit", the
Content-Transfer-Encoding may need to be changed, although there
should be no problems if the email transport supports 8BITMIME [RFC
2821].
6.21.2.3. Message/external-body
The Content-Type "message/external-body" could be appropriate for
texts which it would be uneconomic (in view of the likely readership)
to distribute to the entire network.
6.21.2.4. Multipart types
The Content-Types "multipart/mixed", "multipart/parallel" and
"multipart/signed" may be used freely in news articles. However,
except where policy or custom so allows, the Content-Type:
"multipart/alternative" SHOULD NOT be used, on account of the extra
bandwidth consumed and the difficulty of quoting in followups, but
reading agents MUST accept it.
The Content-Type: "multipart/digest" is commended for any article
composed of multiple messages more conveniently viewed as separate
entities, thus enabling reading agents to move rapidly between them.
The "boundary" should be composed of 28 hyphens (US-ASCII 45) (which
makes each boundary delimiter 30 hyphens, or 32 for the final one) so
as to enable reading agents which currently support the digest usage
described in [RFC 1153] to continue to operate correctly.
NOTE: The various recommendations given above regarding the
usage of particular Content-Types apply also to the individual
parts of these multiparts.
6.21.3. Content-Transfer-Encoding 6.21.3. Content-Transfer-Encoding
"Content-Transfer-Encoding: 7bit" is sufficient for article bodies "Content-Transfer-Encoding: 7bit" is sufficient for article bodies
(or parts of multiparts) written in pure US-ASCII (or most other (or parts of multiparts) written in pure US-ASCII (or most other
material representable in 7 bits). Posting agents SHOULD specify material representable in 7 bits). Posting agents SHOULD specify
"Content-Transfer-Encoding: 8bit" for all other cases unless there "Content-Transfer-Encoding: 8bit" for all other cases except where
are pressing reasons to do otherwise. They MAY use "8bit" encoding the content is (or might be) "8bit-unsafe", or where some protocol
even when "7bit" encoding would have sufficed. Examples of such explicitly disallows it. They MAY use "8bit" encoding even when
pressing reasons are the following: "7bit" encoding would have sufficed.
1. The content type implies that the content is (or may be) "8bit-
unsafe"; i.e. it may contain octets equivalent to the US-ASCII
characters CR or LF (other than in the combination CRLF) or NUL.
In that case one of the Content-Transfer-Encodings "base64" or
"quoted-printable" MUST be used, and reading agents MUST be able
to handle both of them. Encoding "binary" MUST NOT be used (except
in cooperating subnets with alternative transport arrangements)
because this standard does not mandate a transport mechanism that
could support it.
News Article Format April 2003
NOTE: If a future extension to the MIME standards were to
provide a more compact encoding of binary suited to transport
over an 8bit channel, it could be considered as an alternative
to base64 once it had gained widespread acceptance.
2. It is often the case that "application" Content-Types are textual
in nature, and intelligible to humans as well as to machines, and
where this state can be recognized by the posting agent (either
through knowledge of the particular application type or by
testing) the material SHOULD NOT be treated as 8bit-unsafe; this
has the added benefit, where the posting agent uses other than
CRLF for line endings internally, of automatically ensuring that
line endings are processed correctly during transport.
If, on the other hand, the posting agent recognizes that the
material is not textual, or cannot reasonably determine it to be
so, then the material MUST be encoded as for 8bit-unsafe (however,
in that case, it is the responsibility of the agent generating the
material to ensure that lines endings, if any, are represented
correctly).
NOTE: All the application types defined by this standard, namely
"application/news-transmission", "application/news-groupinfo"
and "application/news-checkgroups" are textual, and indeed
designed for human reading.
3. Although the "text" Content-Types should normally be encoded as
8bit (or 7bit), if the character set specified by the "charset="
parameter can include the 3 disallowed octets, then the material
MUST be encoded as for 8bit-unsafe. This is most likely to arise
in the case of 16-bit character sets such as UTF-16 ([UNICODE 3.2]
or [ISO/IEC 10646]). In addition, where it is known that the
material is subsequently to be gatewayed from Netnews to Email
(8.8), the encoding "quoted-printable" MAY be used (otherwise the
gateway might have to re-encode it itself).
4. Some protocols REQUIRE the use of a particular Content-Transfer- Content is "8bit-unsafe" if it contains octets equivalent to the US-
Encoding. In particular, the authentication protocol based on ASCII characters CR or LF (other than in the combination CRLF) or
OpenPGP defined in [RFC 3156] mandates the use of one of the NUL. This is often the case with application types (though in many
encodings "quoted-printable" or "base64". Whilst posters might be cases application types are intended to be human readable, in which
tempted to risk the use of "8bit" or "7bit" encodings (and indeed case they will usually be 8bit-safe). It also arises with certain
the referenced standard recommends that signed messages using News Article Format June 2003
those encodings be accepted and interpreted), they should be
warned that differences in the treatment of trailing whitespace
between OpenPGP [RFC 2440] and earlier versions of PGP may render
signatures written with the one unverifiable by the other; and,
moreover, Usenet articles are very likely to include trailing
whitespace in the form of a personal signature (4.3.2).
5. The Content-Type message/partial [RFC 2046] is required to use charsets (as indicated in the Content-Type-header), particularly in
encoding "7bit" (the encapsulated complete message may itself use the case of 16-bit charsets such as UTF-16 ([UNICODE 3.2] or [ISO/IEC
encoding "quoted-printable" or "base64", but that information is 10646]).
only conveyed along with the first of the partial parts).
News Article Format April 2003 Examples of protocols REQUIRING particular Content-Transfer-Encodings
include the Content-Type "application/pgp-signature" [RFC 3156], and
the Content-Type "message/partial" which itself MUST use "Content-
Transfer-Encoding: 7bit" (though the encapsulated complete message
may itself use encoding "quoted-printable" or "base64", but that
information is only conveyed along with the first of the partial
parts).
NOTE: Although there would actually be no problem using encoding Encoding "binary" MUST NOT be used (except in cooperating subnets
"8bit" in a pure Netnews (as opposed to Email) environment, this with alternative transport arrangements) because this standard does
standard discourages (see 6.21.2.1) the use of "message/partial" not mandate a transport mechanism that could support it.
except for binary material, which will likely be encoded to pass
through "7bit" in any case.
Injecting and relaying agents MUST NOT change the encoding of Injecting and relaying agents MUST NOT change the encoding of
articles passed to them. Gateways SHOULD NOT change the encoding articles passed to them. Gateways SHOULD NOT change the encoding
unless absolutely necessary. unless absolutely necessary.
6.21.4. Character Sets 6.21.4. Character Sets
In principle, any character set may be specified in the "charset=" [This section to be removed]
parameter of a content type. However, only those character sets (and
the corresponding parts of character sets based on [UNICODE 3.2] such
UTF-8) should be used which are appropriate for the customary
language(s) of the hierarchy or newsgroup concerned (whose readers
could be expected to possess agents capable of displaying them).
6.21.5. Content Disposition 6.21.5. Content Disposition
Reading agents Ought to honour any Content-Disposition-header that is [This section to be removed]
provided (in particular, they Ought to display any part of a
multipart for which the disposition is "inline", possibly
distinguished from adjacent parts by some suitable separator). In the
absence of such a header, the body of an article or any part of a
multipart with Content-Type "text" Ought to be displayed inline.
Followup agents which quote parts of a precursor (see 4.3.2) Ought
initially to include all parts of the precursor that were displayed
inline, as if they were a single part.
6.21.6. Definition of some new Content-Types 6.21.6. Definition of some new Content-Types
This standard defines (or redefines) several new Content-Types, which This standard defines (or redefines) several new Content-Types, which
require to be registered with IANA as provided for in [RFC 2048]. require to be registered with IANA as provided for in [RFC 2048].
For "application/news-groupinfo" see 7.2.1.2, for "application/news- For "application/news-groupinfo" see 7.2.1.2, for "application/news-
checkgroups" see 7.2.4.1, and for "application/news-transmission" see checkgroups" see 7.2.4.1, and for "application/news-transmission" see
the following section. the following section.
6.21.6.1. Application/news-transmission 6.21.6.1. Application/news-transmission
skipping to change at page 61, line 5 skipping to change at page 51, line 56
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 8.2.2) and it is also the preferred method when sending to an (see 8.2.2) and it is also the preferred method when sending to an
email-to-news gateway (see 8.8.2). email-to-news gateway (see 8.8.2).
NOTE: The benefit of such encapsulation is that it removes NOTE: The benefit of such encapsulation is that it removes
possible conflict between news and email headers and it provides possible conflict between news and email headers and it provides
a convenient way of "tunnelling" a news article through a a convenient way of "tunnelling" a news article through a
transport medium that does not support 8bit characters. transport medium that does not support 8bit characters.
News Article Format April 2003
The MIME content type definition of "application/news-transmission" The MIME content type definition of "application/news-transmission"
is: is:
MIME type name: application MIME type name: application
News Article Format June 2003
MIME subtype name: news-transmission MIME subtype name: news-transmission
Required parameters: none Required parameters: none
Optional parameters: usage=moderate Optional parameters: usage=moderate
usage=inject usage=inject
usage=relay usage=relay
Encoding considerations: A transfer-encoding (such as Quoted- Encoding considerations: A transfer-encoding (such as Quoted-
Printable or Base64) different from that of Printable or Base64) different from that of
the article transmitted MAY be supplied the article transmitted MAY be supplied
(perhaps en route) to ensure correct (perhaps en route) to ensure correct
transmission over some 7bit transport transmission over some 7bit transport
skipping to change at page 62, line 4 skipping to change at page 52, line 56
Thus a batch is a sequence of articles, each prefixed by a header Thus a batch is a sequence of articles, each prefixed by a header
line that includes its size. The article-size is a decimal count of line that includes its size. The article-size is a decimal count of
the octets in the article, counting each CRLF as one octet regardless the octets in the article, counting each CRLF as one octet regardless
of how it is actually represented. of how it is actually represented.
NOTE: Despite the similarity of this format to an executable NOTE: Despite the similarity of this format to an executable
UNIX script, it is EXTREMELY unwise to feed such a batch into a UNIX script, it is EXTREMELY unwise to feed such a batch into a
command interpreter in anticipation of it running a command command interpreter in anticipation of it running a command
named "rnews"; the security implications of so doing would be named "rnews"; the security implications of so doing would be
News Article Format April 2003
disastrous. disastrous.
News Article Format June 2003
6.21.6.2. Message/news obsoleted 6.21.6.2. Message/news obsoleted
The Content-Type "message/news", as previously registered with IANA, The Content-Type "message/news", as previously registered with IANA,
is hereby declared obsolete. It was never widely implemented, and its is hereby declared obsolete. It was never widely implemented, and its
default treatment as "application/octet-stream" by agents that did default treatment as "application/octet-stream" by agents that did
not recognize it was counter productive. The Content-Type not recognize it was counter productive. The Content-Type
"message/rfc822" SHOULD be used in its place, as already described "message/rfc822" SHOULD be used in its place, as already described
above. above.
6.22. Obsolete Headers 6.22. Obsolete Headers
skipping to change at page 62, line 48 skipping to change at page 53, line 47
newsgroup-names so as to improve propagation (but this practice may newsgroup-names so as to improve propagation (but this practice may
cause the control message to propagate also to places where it is cause the control message to propagate also to places where it is
unwanted, or even cause it not to propagate where it should, so it unwanted, or even cause it not to propagate where it should, so it
should not be used without good reason). should not be used without good reason).
The descriptions below set out REQUIREMENTS to be followed by sites The descriptions below set out REQUIREMENTS to be followed by sites
that receive control messages and choose to honour them. However, that receive control messages and choose to honour them. However,
nothing in these descriptions should be taken as overriding the right nothing in these descriptions should be taken as overriding the right
of any such site, in accordance with its local policy, to deny any of any such site, in accordance with its local policy, to deny any
particular control message, or to refer it to an administrator for particular control message, or to refer it to an administrator for
approval (either as a class or on a case-by-case basis). In approval (either as a class or on a case-by-case basis).
particular, sites Ought to deny messages not issued by the
appropriate administrative agencies, and therefore SHOULD take such
steps as are reasonably practicable to validate their authenticity
(see, for example, section 7.1 below).
Relaying Agents MUST propagate even control messages that they do not Relaying Agents MUST propagate even control messages that they do not
recognize. recognize.
In the following sections, each type of control message is defined In the following sections, each type of control message is defined
syntactically by defining its verb, its arguments, and possibly its syntactically by defining its verb, its arguments, and possibly its
body. body.
News Article Format April 2003
7.1. Digital Signature of Headers 7.1. Digital Signature of Headers
It is most desirable that group control messages (7.2) in particular It is most desirable that group control messages (7.2) in particular
be authenticated by incorporating them within some digital signature be authenticated by incorporating them within some digital signature
scheme that encompasses other headers closely associated with them scheme that encompasses other headers closely associated with them
News Article Format June 2003
(including at least the Approved-, Message-ID- and Date-headers). At (including at least the Approved-, Message-ID- and Date-headers). At
the time of writing, this is usually done by means of a protocol the time of writing, this is usually done by means of a protocol
known as "PGPverify" ([PGPVERIFY]), and continued usage of this is known as "PGPverify" ([PGPVERIFY]), and continued usage of this is
encouraged at least as an interim measure. encouraged at least as an interim measure.
However, PGPverify is not considered suitable for standardization in However, PGPverify is not considered suitable for standardization in
its present form, for various technical reasons. It is therefore its present form, for various technical reasons. It is therefore
expected that an early extension to this standard will provide a expected that an early extension to this standard will provide a
robust and general purpose digital authentication mechanism with robust and general purpose digital authentication mechanism with
applicability to all situations requiring protection against applicability to all situations requiring protection against
skipping to change at page 63, line 34 skipping to change at page 54, line 28
7.2. Group Control Messages 7.2. Group Control Messages
"Group control messages" are the sub-class of control messages that "Group control messages" are the sub-class of control messages that
request some update to the configuration of the groups known to a request some update to the configuration of the groups known to a
serving agent, namely "newgroup". "rmgroup", "mvgroup" and serving agent, namely "newgroup". "rmgroup", "mvgroup" and
"checkgroups", plus any others created by extensions to this "checkgroups", plus any others created by extensions to this
standard. standard.
All of the group control messages MUST have an Approved-header All of the group control messages MUST have an Approved-header
(6.14). Moreover, in those hierarchies where appropriate (6.14) which, in those hierarchies where appropriate administrative
administrative agencies exist (see 1.1), group control messages Ought agencies exist (see 1.1), identifies the appropriate person or entity
Not to be issued except as authorized by those agencies. as authorized by those agencies. The authorized person or entity
SHOULD adhere to the conventions and restrictions on the format of
newsgroup-names established for those hierarchies (see 5.5).
7.2.1. The 'newgroup' Control Message 7.2.1. The 'newgroup' Control Message
control-message =/ Newgroup-message control-message =/ Newgroup-message
Newgroup-message = "newgroup" Newgroup-arguments Newgroup-message = "newgroup" Newgroup-arguments
Newgroup-arguments = CFWS newsgroup-name [ CFWS newgroup-flag ] Newgroup-arguments = CFWS newsgroup-name [ CFWS newgroup-flag ]
newgroup-flag = "moderated" newgroup-flag = "moderated"
The "newgroup" control message requests that the specified group be The "newgroup" control message requests that the specified group be
created or changed. If the request is honoured, or if the group created or changed. If the request is honoured, or if the group
skipping to change at page 64, line 5 skipping to change at page 55, line 5
those subnets. those subnets.
NOTE: Specifically, some alternative flags such as "y" and "m", NOTE: Specifically, some alternative flags such as "y" and "m",
which are sent and recognized by some current software, are NOT which are sent and recognized by some current software, are NOT
part of this standard. Moreover, some existing implementations part of this standard. Moreover, some existing implementations
treat any flag other than "moderated" as indicating an treat any flag other than "moderated" as indicating an
unmoderated newsgroup. Both of these usages are contrary to this unmoderated newsgroup. Both of these usages are contrary to this
standard and control messages with such non-standard flags standard and control messages with such non-standard flags
should be ignored. should be ignored.
News Article Format April 2003 News Article Format June 2003
The message body comprises or includes an "application/news- The message body comprises or includes an "application/news-
groupinfo" (7.2.1.2) part containing machine- and human-readable groupinfo" (7.2.1.2) part containing machine- and human-readable
information about the group. information about the group.
The newsgroup-name Ought to conform to whatever policies have been
established by the administrative agency, if any, for that hierarchy.
Serving agents SHOULD, insofar as they are conveniently able to
detect them, reject all newgroup messages not meeting those
requirements.
The newgroup command is also used to update the newsgroups-line or The newgroup command is also used to update the newsgroups-line or
the moderation status of a group. the moderation status of a group.
7.2.1.1. The Body of the 'newgroup' Control Message 7.2.1.1. The Body of the 'newgroup' Control Message
The body of the newgroup message contains the following subparts, The body of the newgroup message contains the following subparts,
preferably in the order shown: preferably in the order shown:
1. An "application/news-groupinfo" part (7.2.1.2) containing the name 1. An "application/news-groupinfo" part (7.2.1.2) containing the name
and newsgroups-line of the group(s). This part MUST be present. and newsgroups-line of the group(s). This part MUST be present.
skipping to change at page 65, line 4 skipping to change at page 55, line 55
The MIME content type definition of "application/news-groupinfo" is: The MIME content type definition of "application/news-groupinfo" is:
MIME type name: application MIME type name: application
MIME subtype name: news-groupinfo MIME subtype name: news-groupinfo
Required parameters: none Required parameters: none
Disposition: by default, inline Disposition: by default, inline
Encoding considerations: "7bit" or "8bit" is sufficient and MUST be Encoding considerations: "7bit" or "8bit" is sufficient and MUST be
used to maintain compatibility. used to maintain compatibility.
Security considerations: this type MUST NOT be used except as part Security considerations: this type MUST NOT be used except as part
of a control message for the creation or of a control message for the creation or
News Article Format April 2003
modification of a Netnews newsgroup modification of a Netnews newsgroup
Published specification: [USEFOR] Published specification: [USEFOR]
The content of the "application/news-groupinfo" body part is defined The content of the "application/news-groupinfo" body part is defined
as: as:
News Article Format June 2003
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
; 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 ]
[ 1*WSP moderation-flag ] [ 1*WSP moderation-flag ]
skipping to change at page 65, line 53 skipping to change at page 56, line 48
NOTE: There is no provision for the use of charsets other than NOTE: There is no provision for the use of charsets other than
US-ASCII within a newsgroup-description. Such a facility may be US-ASCII within a newsgroup-description. Such a facility may be
provided in a future extension to this standard. provided in a future extension to this standard.
[That may seem harsh, but if we make any such provision now, it will [That may seem harsh, but if we make any such provision now, it will
make life more complicated and restrict our freedom when it comes to the make life more complicated and restrict our freedom when it comes to the
proposed I18N extension. Therefore I resisted the temptation to include proposed I18N extension. Therefore I resisted the temptation to include
any charset parameter with this Content-Type. Note that this also any charset parameter with this Content-Type. Note that this also
applies to the checkgroups message further on.] applies to the checkgroups message further on.]
Although, in accordance with [RFC 2822] and section 4.5 of this
standard, a newsgroups-line could have a maximum length of 998
octets, as a matter of policy a far lower limit, expressed in
characters, Ought to be set. The current convention is to limit its
length so that the newsgroup-name, the HTAB(s) (interpreted as 8-
character tabs that takes one at least to column 24) and the
newsgroup-description (excluding any moderation-flag) fit into 79
News Article Format April 2003
characters. However, this standard does not seek to enforce any such
rule, and reading agents SHOULD therefore enable a newsgroups-line of
any length to be displayed, e.g. by wrapping it as required.
7.2.1.3. Initial Articles 7.2.1.3. Initial Articles
Some subparts of a "newgroup" or "mvgroup" control message MAY Some subparts of a "newgroup" or "mvgroup" control message MAY
contain an initial set of articles to be posted to the affected contain an initial set of articles to be posted to the affected
newsgroup(s) as soon as it has been created or modified. These parts newsgroup(s) as soon as it has been created or modified. These parts
are identified by having the Content-Type "application/news- are identified by having the Content-Type "application/news-
transmission", possibly with the parameter "usage=inject". The body transmission", possibly with the parameter "usage=inject". The body
of each such part should be a complete proto-article, ready for of each such part should be a complete proto-article, ready for
posting. This feature is intended for the posting of charters, posting. This feature is intended for the posting of charters,
initial FAQs and the like to the newly formed group(s). initial FAQs and the like to the newly formed group(s).
News Article Format June 2003
The Newsgroups-header of the proto-article MUST include the The Newsgroups-header of the proto-article MUST include the
newsgroup-name of the newly created or modified group. It MAY include newsgroup-name of the newly created or modified group. It MAY include
other newsgroup-names. If the proto-article includes a Message-ID- other newsgroup-names. If the proto-article includes a Message-ID-
header, the message identifier in it MUST be different from that of header, the message identifier in it MUST be different from that of
any existing article and from that of the control message as a whole. any existing article and from that of the control message as a whole.
Alternatively such a message identifier MAY be derived by the Alternatively such a message identifier MAY be derived by the
injecting agent when the proto-article is posted. The proto-article injecting agent when the proto-article is posted. The proto-article
SHOULD include the header "Distribution: local". SHOULD include the header "Distribution: local".
The proto-article SHOULD be injected at the serving agent that The proto-article SHOULD be injected at the serving agent that
skipping to change at page 67, line 4 skipping to change at page 57, line 44
A "newgroup" with its charter: A "newgroup" with its charter:
From: "example.all Administrator" <admin@noc.example> From: "example.all Administrator" <admin@noc.example>
Newsgroups: example.admin.info,example.admin.announce Newsgroups: example.admin.info,example.admin.announce
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
News Article Format April 2003
Content-Type: multipart/mixed; boundary="nxtprt" Content-Type: multipart/mixed; boundary="nxtprt"
Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit
This is a MIME control message. This is a MIME control message.
--nxtprt --nxtprt
Content-Type: application/news-groupinfo Content-Type: application/news-groupinfo
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: application/news-transmission Content-Type: application/news-transmission
Newsgroups: example.admin.info Newsgroups: example.admin.info
From: "example.all Administrator" <admin@noc.example> From: "example.all Administrator" <admin@noc.example>
Subject: Charter for example.admin.info Subject: Charter for example.admin.info
Message-ID: <charter-example.admin.info-20020227@noc.example> Message-ID: <charter-example.admin.info-20020227@noc.example>
News Article Format June 2003
Distribution: local Distribution: local
Content-Type: text/plain; charset=us-ascii Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit
The group example.admin.info contains regularly posted The group example.admin.info contains regularly posted
information on the example.* hierarchy. information on the example.* hierarchy.
--nxtprt-- --nxtprt--
7.2.2. The 'rmgroup' Control Message 7.2.2. The 'rmgroup' Control Message
skipping to change at page 68, line 5 skipping to change at page 58, line 44
Newsgroups: example.admin.obsolete, example.admin.announce Newsgroups: example.admin.obsolete, example.admin.announce
Date: 4 Apr 2002 22:04 -0900 (PST) Date: 4 Apr 2002 22:04 -0900 (PST)
Subject: cmsg rmgroup example.admin.obsolete Subject: cmsg rmgroup example.admin.obsolete
Message-ID: <rm-example.admin.obsolete-20020404@noc.example> Message-ID: <rm-example.admin.obsolete-20020404@noc.example>
Approved: admin@noc.example Approved: admin@noc.example
Control: rmgroup example.admin.obsolete Control: rmgroup example.admin.obsolete
The group example.admin.obsolete is obsolete. Please remove it The group example.admin.obsolete is obsolete. Please remove it
from your system. from your system.
News Article Format April 2003
7.2.3. The 'mvgroup' Control Message 7.2.3. The 'mvgroup' Control Message
control-message =/ Mvgroup-message control-message =/ Mvgroup-message
Mvgroup-message = "mvgroup" Mvgroup-arguments Mvgroup-message = "mvgroup" Mvgroup-arguments
Mvgroup-arguments = CFWS newsgroup-name CFWS newsgroup-name Mvgroup-arguments = CFWS newsgroup-name CFWS newsgroup-name
[ CFWS newgroup-flag ] [ CFWS newgroup-flag ]
The "mvgroup" control message requests that the group specified by The "mvgroup" control message requests that the group specified by
the first (old-)newsgroup-name be moved to that specified by the the first (old-)newsgroup-name be moved to that specified by the
second (new-)newsgroup-name. Thus it is broadly equivalent to a second (new-)newsgroup-name. Thus it is broadly equivalent to a
"newgroup" control message for the second group followed by a "newgroup" control message for the second group followed by a
"rmgroup" control message for the first group. "rmgroup" control message for the first group.
The second (new-)newsgroup-name Ought to conform to any established The message body contains an "application/news-groupinfo" part
policies of the hierarchy. The message body contains an (7.2.1.2) containing machine- and human-readable information about
"application/news-groupinfo" part (7.2.1.2) containing machine- and the new group, and possibly other subparts as for a "newgroup"
human-readable information about the new group, and possibly other News Article Format June 2003
subparts as for a "newgroup" control message. The information
conveyed in the "application/news-groupinfo" body part, notably its control message. The information conveyed in the "application/news-
newsgroups-line (7.2.1.2), is applied to the new group. groupinfo" body part, notably its newsgroups-line (7.2.1.2), is
applied to the new group.
When this message is received, the new group is created (if it does When this message is received, the new group is created (if it does
not exist already) as for a "newgroup" control message, and MUST in not exist already) as for a "newgroup" control message, and MUST in
any case be made moderated if a newgroup-flag "moderated" is present, any case be made moderated if a newgroup-flag "moderated" is present,
and vice versa. At the same time, arrangements SHOULD be made to and vice versa. At the same time, arrangements SHOULD be made to
remove the old group (as with a "rmgroup" control message), but only remove the old group (as with a "rmgroup" control message), but only
after a suitable overlap period to allow the network to adjust to the after a suitable overlap period to allow the network to adjust to the
new arrangement. new arrangement.
At the same time as a serving agent acts upon this message, all At the same time as a serving agent acts upon this message, all
skipping to change at page 69, line 5 skipping to change at page 59, line 44
inhibition of injection of new articles to the old group may inhibition of injection of new articles to the old group may
seem draconian, but it is the surest way to prevent the seem draconian, but it is the surest way to prevent the
changeover from dragging on indefinitely. changeover from dragging on indefinitely.
Since the "mvgroup" control message is newly introduced in this Since the "mvgroup" control message is newly introduced in this
standard and may not be widely implemented initially, it SHOULD be standard and may not be widely implemented initially, it SHOULD be
followed shortly afterwards by a corresponding "newgroup" control followed shortly afterwards by a corresponding "newgroup" control
message; and again, after a reasonable overlap period, it MUST be message; and again, after a reasonable overlap period, it MUST be
followed by a "rmgroup" control message for the old group. followed by a "rmgroup" control message for the old group.
News Article Format April 2003
In order to facilitate a smooth changeover, serving agents MAY In order to facilitate a smooth changeover, serving agents MAY
arrange to service requests for access to the old group by providing arrange to service requests for access to the old group by providing
access to the new group, which would then contain, or appear to access to the new group, which would then contain, or appear to
contain, all articles posted to either group (including, ideally, the contain, all articles posted to either group (including, ideally, the
pre-changeover articles from the old one). Nevertheless, if this pre-changeover articles from the old one). Nevertheless, if this
feature is implemented, the articles themselves, as supplied to feature is implemented, the articles themselves, as supplied to
reading agents, MUST NOT be altered in any way (and, in particular, reading agents, MUST NOT be altered in any way (and, in particular,
their Newsgroups-headers MUST contain exactly those newsgroups their Newsgroups-headers MUST contain exactly those newsgroups
present when they were injected). On the other hand, the Xref-header present when they were injected). On the other hand, the Xref-header
MAY contain entries for either group (or even both). MAY contain entries for either group (or even both).
NOTE: Some serving agents that use an "active" file permit an NOTE: Some serving agents that use an "active" file permit an
entry of the form "oldgroup xxx yyy =newgroup", which enables entry of the form "oldgroup xxx yyy =newgroup", which enables
any articles arriving for oldgroup to be diverted to newgroup, any articles arriving for oldgroup to be diverted to newgroup,
thus providing a simple implementation of this feature. However, thus providing a simple implementation of this feature. However,
it is known that not all current serving agents will find it is known that not all current serving agents will find
News Article Format June 2003
implementation so easy (especially in the short term) which is implementation so easy (especially in the short term) which is
why it is not mandated by this standard. Nevertheless, its why it is not mandated by this standard. Nevertheless, its
eventual implementation in all serving agents is to be eventual implementation in all serving agents is to be
considered highly desirable. considered highly desirable.
On the other hand, it is recognized that this feature would On the other hand, it is recognized that this feature would
likely not be implementable if the new group was already in likely not be implementable if the new group was already in
existence with existing articles in it. This situation should existence with existing articles in it. This situation should
not normally arise except when there is already some confusion not normally arise except when there is already some confusion
as to which groups are, or are not, supposed to exist in that as to which groups are, or are not, supposed to exist in that
skipping to change at page 70, line 4 skipping to change at page 60, line 41
--nxt --nxt
Content-Type: application/news-groupinfo Content-Type: application/news-groupinfo
For your newsgroups file: For your newsgroups file:
example.newgroup The new replacement group (Moderated) example.newgroup The new replacement group (Moderated)
--nxt --nxt
The moderated group example.oldgroup is replaced by The moderated group example.oldgroup is replaced by
example.newgroup. Please update your configuration, and please, example.newgroup. Please update your configuration, and please,
News Article Format April 2003
if possible, arrange to file articles arriving for if possible, arrange to file articles arriving for
example.oldgroup as if they were in example.newgroup. example.oldgroup as if they were in example.newgroup.
--nxt-- --nxt--
7.2.4. The 'checkgroups' Control Message 7.2.4. 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 complete hierarchy. groups in a complete hierarchy.
control-message =/ Checkgroup-message control-message =/ Checkgroup-message
Checkgroup-message = "checkgroups" Checkgroup-arguments Checkgroup-message = "checkgroups" Checkgroup-arguments
Checkgroup-arguments= [ chkscope ] [ chksernr ] Checkgroup-arguments= [ chkscope ] [ chksernr ]
chkscope = 1*( CFWS ["!"] newsgroup-name ) chkscope = 1*( CFWS ["!"] newsgroup-name )
chksernr = CFWS "#" 1*DIGIT chksernr = CFWS "#" 1*DIGIT
A "checkgroups" message applies to any (sub-)hierarchy with a prefix A "checkgroups" message applies to any (sub-)hierarchy with a prefix
listed in the chkscope parameter, provided that the rightmost listed in the chkscope parameter, provided that the rightmost
matching newsgroup-name in the list is not immediately preceded by a matching newsgroup-name in the list is not immediately preceded by a
News Article Format June 2003
"!". If no chkscope parameter is given, it applies to all "!". If no chkscope parameter is given, it applies to all
hierarchies for which group statements appear in the message. hierarchies for which group statements appear in the message.
NOTE: Some existing software does not support the "chkscope" NOTE: Some existing software does not support the "chkscope"
parameter. Thus a "checkgroups" message SHOULD also contain the parameter. Thus a "checkgroups" message SHOULD also contain the
groups of other subhierarchies the sender is not responsible groups of other subhierarchies the sender is not responsible
for. "New" software MUST ignore groups which do not fall within for. "New" software MUST ignore groups which do not fall within
the chkscope parameter of the "checkgroups" message. the chkscope parameter of the "checkgroups" message.
The chksernr parameter is a serial number, which can be any positive The chksernr parameter is a serial number, which can be any positive
skipping to change at page 71, line 5 skipping to change at page 61, line 42
newsgroups in the specified hierarchies. newsgroups in the specified hierarchies.
NOTE: The checkgroups message is intended to synchronize the NOTE: The checkgroups message is intended to synchronize the
list of newsgroups stored by a serving agent, and their list of newsgroups stored by a serving agent, and their
newsgroup-descriptions, with the lists stored by other serving newsgroup-descriptions, with the lists stored by other serving
agents throughout the network. However, it might be inadvisable agents throughout the network. However, it might be inadvisable
for the serving agent actually to create or delete any for the serving agent actually to create or delete any
newsgroups without first obtaining the approval of its newsgroups without first obtaining the approval of its
administrators for such proposed actions. administrators for such proposed actions.
News Article Format April 2003
7.2.4.1. Application/news-checkgroups 7.2.4.1. Application/news-checkgroups
The "application/news-checkgroups" body part contains a complete list The "application/news-checkgroups" body part contains a complete list
of all the newsgroups in a hierarchy, their newsgroup-descriptions of all the newsgroups in a hierarchy, their newsgroup-descriptions
and their moderation status. and their moderation status.
The MIME content type definition of "application/news-checkgroups" The MIME content type definition of "application/news-checkgroups"
is: 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
Disposition: by default, inline Disposition: by default, inline
Encoding considerations: "7bit" or "8bit" is sufficient and MUST be Encoding considerations: "7bit" or "8bit" is sufficient and MUST be
used to maintain compatibility. used to maintain compatibility.
Security considerations: this type MUST NOT be used except as part Security considerations: this type MUST NOT be used except as part
of a checkgroups control message of a checkgroups control message
News Article Format June 2003
The content of the "application/news-checkgroups" body part is The content of the "application/news-checkgroups" body part is
defined as: defined as:
checkgroups-body = *( valid-group CRLF ) checkgroups-body = *( valid-group CRLF )
valid-group = newsgroups-line ; see 7.2.1.2 valid-group = newsgroups-line ; see 7.2.1.2
The "application/news-checkgroups" content type is used in The "application/news-checkgroups" content type is used in
conjunction with the "checkgroups" control message (7.2.4). conjunction with the "checkgroups" control message (7.2.4).
skipping to change at page 71, line 45 skipping to change at page 62, line 26
of an "invalidation" line beginning with a '!' is no longer of an "invalidation" line beginning with a '!' is no longer
provided by this standard. The intent of the feature was widely provided by this standard. The intent of the feature was widely
misunderstood and it was misused more often than it was used misunderstood and it was misused more often than it was used
correctly. The same effect, if required, can now be obtained by correctly. The same effect, if required, can now be obtained by
the use of an appropriate chkscope argument in conjunction with the use of an appropriate chkscope argument in conjunction with
an empty checkgroups-body. an empty checkgroups-body.
7.3. Cancel 7.3. Cancel
The cancel message requests that a target article be "canceled" i.e. The cancel message requests that a target article be "canceled" i.e.
be withdrawn from circulation or access. A cancel message may be be withdrawn from circulation or access.
issued in the following circumstances.
1. The poster of an article (or, more specifically, any entity
mentioned in the From-header or the Sender-header, whether or not
that entity was the actual poster) is always entitled to issue a
cancel message for that article, and serving agents SHOULD honour
such requests. Posting agents SHOULD facilitate the issuing of
cancel messages by posters fulfilling these criteria.
2. The agent which injected the article onto the network (more
specifically, the entity identified by the path-identity in front
of the leftmost '%' delimiter in the Path-header (5.6) or in the
Injector-Info-header (6.19) and, where appropriate, the moderator
(more specifically, any entity mentioned in the Approved-header)
is always entitled to issue a cancel message for that article, and
News Article Format April 2003
serving agents SHOULD honour such requests.
3. Other entities MAY be entitled to issue a cancel message for that
article, in circumstances where established policy for any
hierarchy or group in the Newsgroup-header, or established custom
within Usenet, so allows (such policies and customs are not
defined by this standard). Such cancel messages MUST include an
Approved-header identifying the responsible entity. Serving agents
MAY honour such requests, but SHOULD first take steps to verify
their appropriateness.
control-message =/ Cancel-message control-message =/ Cancel-message
Cancel-message = "cancel" Cancel-arguments Cancel-message = "cancel" Cancel-arguments
Cancel-arguments = CFWS msg-id [CFWS] Cancel-arguments = CFWS msg-id [CFWS]
The argument identifies the article to be cancelled by its message The argument identifies the article to be cancelled by its message
identifier. The body SHOULD contain an indication of why the identifier. The body SHOULD contain an indication of why the
cancellation was requested. The cancel message SHOULD be posted to cancellation was requested. The cancel message SHOULD be posted to
the same newsgroup, with the same distribution, as the article it is the same newsgroup, with the same distribution, as the article it is
attempting to cancel. attempting to cancel.
skipping to change at page 72, line 38 skipping to change at page 62, line 49
the article unavailable for relaying or serving (perhaps by deleting the article unavailable for relaying or serving (perhaps by deleting
it completely). If the target article is unavailable, and the it completely). If the target article is unavailable, and the
acceptability of the cancel message cannot be established without it, acceptability of the cancel message cannot be established without it,
activation of the cancel message SHOULD be delayed until the target activation of the cancel message SHOULD be delayed until the target
article has been seen. See also sections 8.3 and 8.4. article has been seen. See also sections 8.3 and 8.4.
NOTE: It is expected that the security extension envisaged in NOTE: It is expected that the security extension envisaged in
section 7.1 will make more detailed provisions for establishing section 7.1 will make more detailed provisions for establishing
whether honouring a particular cancel message is in order. In whether honouring a particular cancel message is in order. In
particular, it is likely that there will be provision for the particular, it is likely that there will be provision for the
digital signature of 3rd party cancels. digital signature of 3rd party cancels (i.e. those issued other
than by the sender, the moderator, or the injector).
NOTE: A cancel submitted by the poster for an article in a NOTE: A cancel submitted by the poster for an article in a
moderated group will be forwarded to the moderator of that moderated group will be forwarded to the moderator of that
group, and it is up to that moderator to act upon it (8.7). group, and it is up to that moderator to act upon it (8.7).
NOTE: The former requirement [RFC 1036] that the From and/or NOTE: The former requirement [RFC 1036] that the From and/or
Sender-headers of the cancel message should match those of the Sender-headers of the cancel message should match those of the
original article has been removed from this standard, since it original article has been removed from this standard, since it
News Article Format June 2003
only encouraged cancel issuers to conceal their true identity, only encouraged cancel issuers to conceal their true identity,
and it was not usually checked or enforced by canceling and it was not usually checked or enforced by canceling
software. Therefore, both the From and/or Sender-headers and software. Therefore, both the From and/or Sender-headers and
any Approved-header should now relate to the entity responsible any Approved-header should now relate to the entity responsible
for issuing the cancel message. for issuing the cancel message.
7.4. Ihave, sendme 7.4. Ihave, sendme
The "ihave" and "sendme" control messages implement a crude batched The "ihave" and "sendme" control messages implement a crude batched
predecessor of the NNTP [NNTP] protocol. They are largely obsolete on predecessor of the NNTP [NNTP] protocol. They are largely obsolete on
the Internet, but still see use in conjunction with some transport the Internet, but still see use in conjunction with some transport
protocols such as UUCP, especially for backup feeds that normally are protocols such as UUCP, especially for backup feeds that normally are
News Article Format April 2003
active only when a primary feed path has failed. There is no active only when a primary feed path has failed. There is no
requirement for relaying agents that do not support such transport requirement for relaying agents that do not support such transport
protocols to implement them. protocols to implement them.
NOTE: The ihave and sendme messages defined here have ABSOLUTELY NOTE: The ihave and sendme messages defined here have ABSOLUTELY
NOTHING TO DO WITH NNTP, despite similarities of terminology. NOTHING TO DO WITH NNTP, despite similarities of terminology.
The two messages share the same syntax: The two messages share the same syntax:
control-message =/ Ihave-message control-message =/ Ihave-message
skipping to change at page 73, line 48 skipping to change at page 64, line 4
These control messages are normally sent essentially as point-to- These control messages are normally sent essentially as point-to-
point messages, by using newsgroup-names in the Newsgroups-header of point messages, by using newsgroup-names in the Newsgroups-header of
the form "to." followed by one (or possibly more) components in the the form "to." followed by one (or possibly more) components in the
form of a relayer-name (see section 5.5.1 which forbids "to" as the form of a relayer-name (see section 5.5.1 which forbids "to" as the
first component of a newsgroup-name). The control message SHOULD then first component of a newsgroup-name). The control message SHOULD then
be delivered ONLY to the relaying agent(s) identified by that be delivered ONLY to the relaying agent(s) identified by that
relayer-name, and any relaying agent receiving such a message which relayer-name, and any relaying agent receiving such a message which
includes its own relayer-name MUST NOT propagate it further. Each includes its own relayer-name MUST NOT propagate it further. Each
pair of relaying agent(s) sending and receiving these messages MUST pair of relaying agent(s) sending and receiving these messages MUST
be immediate neighbors, exchanging news directly with each other. be immediate neighbors, exchanging news directly with each other.
News Article Format June 2003
Each relaying agent advertises its new arrivals to the other using Each relaying agent advertises its new arrivals to the other using
ihave messages, and each uses sendme messages to request the articles ihave messages, and each uses sendme messages to request the articles
it lacks. it lacks.
To reduce overhead, ihave and sendme messages SHOULD be sent To reduce overhead, ihave and sendme messages SHOULD be sent
relatively infrequently and SHOULD contain reasonable numbers of relatively infrequently and SHOULD contain reasonable numbers of
message IDs. If ihave and sendme are being used to implement a backup message IDs. If ihave and sendme are being used to implement a backup
feed, it may be desirable to insert a delay between reception of an feed, it may be desirable to insert a delay between reception of an
ihave and generation of a sendme, so that a slightly slow primary ihave and generation of a sendme, so that a slightly slow primary
feed will not cause large numbers of articles to be requested feed will not cause large numbers of articles to be requested
unnecessarily via sendme. unnecessarily via sendme.
News Article Format April 2003
7.5. Obsolete control messages. 7.5. Obsolete control messages.
The following control messages are declared obsolete by this The following control messages are declared obsolete by this
standard: standard:
sendsys sendsys
version version
whogets whogets
senduuname senduuname
skipping to change at page 74, line 49 skipping to change at page 65, line 5
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 Be liberal in what you accept, and conservative in what you
send. send.
However, in the case of news there is an even more important However, in the case of news there is an even more important
principle, derived from a much older code of practice, the principle, derived from a much older code of practice, the
Hippocratic Oath (we may thus call this the Hippocratic Principle): Hippocratic Oath (we may thus call this the Hippocratic Principle):
News Article Format June 2003
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 which might be merely
suboptimal in a smaller context can become devastating mistakes when suboptimal in a smaller context can become devastating mistakes when
amplified by the actions of thousands of hosts within a few minutes. amplified by the actions of thousands of hosts within a few minutes.
In the case of gateways, the primary corollary to this is: In the case of gateways, the primary corollary to this is:
Cause no loops. Cause no loops.
News Article Format April 2003
8.2. Duties of an Injecting Agent 8.2. Duties of an Injecting Agent
An Injecting Agent is responsible for taking a proto-article from a An Injecting Agent is responsible for taking a proto-article from a
posting agent and either forwarding it to a moderator or injecting it posting agent and either forwarding it to a moderator or injecting it
into the relaying system for access by readers. into the relaying system for access by readers.
As such, an injecting agent is considered responsible for ensuring As such, an injecting agent is considered responsible for ensuring
that any article it injects conforms with the rules of this standard that any article it injects conforms with the rules of this standard.
and the policies of any newsgroups or hierarchies that the article is It is also expected to bear some responsibility towards the rest of
posted to. It is also expected to bear some responsibility towards the network for the behaviour of its posters (and provision is
the rest of the network for the behaviour of its posters (and therefore made for it to be easily contactable by email).
provision is therefore made for it to be easily contactable by
email).
To this end injecting agents MAY cancel articles which they have
previously injected (see 7.3).
8.2.1. Proto-articles 8.2.1. Proto-articles
A proto-article is one that has been created by a posting agent and A proto-article is one that has been created by a posting agent and
has not yet been injected into the news system by an injecting agent. has not yet been injected into the news system by an injecting agent.
It SHOULD NOT be propagated in that form to other than injecting It SHOULD NOT be propagated in that form to other than injecting
agents. A proto-article has the same format as a normal article agents. A proto-article has the same format as a normal article
except that some of the following mandatory headers MAY be omitted: except that some of the following mandatory headers MAY be omitted:
Message-Id-header, Date-header, Path-header (and even From-header if Message-Id-header, Date-header, Path-header (and even From-header if
the particular injecting agent can derive that information from other the particular injecting agent can derive that information from other
skipping to change at page 75, line 56 skipping to change at page 66, line 5
serving or relaying agents. serving or relaying agents.
If an injecting agent receives an otherwise valid article that has If an injecting agent receives an otherwise valid article that has
already been injected it SHOULD either act as if it is a relaying already been injected it SHOULD either act as if it is a relaying
agent or else pass the article on to a relaying agent completely agent or else pass the article on to a relaying agent completely
unaltered. Exceptionally, it MAY reinject the article, perhaps as a unaltered. Exceptionally, it MAY reinject the article, perhaps as a
part of some complex gatewaying process (in which case it will add a part of some complex gatewaying process (in which case it will add a
second '%' path-delimiter to the Path-header). It MUST NOT forward second '%' path-delimiter to the Path-header). It MUST NOT forward
an already injected article to a moderator. an already injected article to a moderator.
News Article Format June 2003
An injecting agent processes articles as follows: An injecting agent processes articles as follows:
1. It MUST remove any Injector-Info- or Complaints-To-header already 1. It MUST remove any Injector-Info- or Complaints-To-header already
present (though it might be useful to copy them to suitable X- present (though it might be useful to copy them to suitable X-
headers). It SHOULD likewise remove any NNTP-Posting-Host or other headers). It SHOULD likewise remove any NNTP-Posting-Host or other
News Article Format April 2003
undocumented tracing header. undocumented tracing header.
2. It SHOULD verify that the article is from a trusted source. 2. It SHOULD verify that the article is from a trusted source.
However, it MAY allow articles in which headers contain "forged" However, it MAY allow articles in which headers contain "forged"
email addresses, that is, addresses which are not valid for the email addresses, that is, addresses which are not valid for the
known and trusted source, especially if they end in ".invalid". known and trusted source, especially if they end in ".invalid".
3. It MUST reject any article whose Date-header is more than 24 hours 3. It MUST reject any article whose Date-header is more than 24 hours
into the past or into the future (cf. 5.1). into the past or into the future (cf. 5.1).
skipping to change at page 76, line 50 skipping to change at page 66, line 56
trusted source of the article, and a suitable Complaints-To-header trusted source of the article, and a suitable Complaints-To-header
(6.20) MAY be added (except that these two headers MUST NOT be (6.20) MAY be added (except that these two headers MUST NOT be
added if the article is to be forwarded to a moderator). added if the article is to be forwarded to a moderator).
10.The injecting agent MUST NOT alter the body of the article in any 10.The injecting agent MUST NOT alter the body of the article in any
way. It MAY add other headers not already provided by the poster, way. It MAY add other headers not already provided by the poster,
but SHOULD NOT alter, delete, or reorder any existing header, with but SHOULD NOT alter, delete, or reorder any existing header, with
the specific exception of "tracing" headers such as Injector-Info the specific exception of "tracing" headers such as Injector-Info
and Complaints-To, which are to be removed as already mentioned. and Complaints-To, which are to be removed as already mentioned.
NOTE: The addition of non-mandatory headers by the injecting
agent may alter the posting agent's preferred presentation of
information. In particular, adding a Sender-header that exposes
a sender's mailbox has privacy implications; where the main or
only purpose for doing so is as tracing information, it is
preferable to use instead one of the options provided for the
Injector-Info header (6.19.1).
News Article Format April 2003
11.If the Newsgroups-header contains no moderated groups, or if it 11.If the Newsgroups-header contains no moderated groups, or if it
contains an Approved-header, the injecting agent forwards the contains an Approved-header, the injecting agent forwards the
article to one or more relaying or serving agents. article to one or more relaying or serving agents.
News Article Format June 2003
12.Otherwise, when the Newsgroups-header contains one or more 12.Otherwise, when the Newsgroups-header contains one or more
moderated groups and the article does NOT contain an Approved- moderated groups and the article does NOT contain an Approved-
header, the injecting agent MUST forward it to the moderator of header, the injecting agent MUST forward it to the moderator of
the first (leftmost) moderated group listed in the Newsgroups- the first (leftmost) moderated group listed in the Newsgroups-
header via email. There are two possibilities for doing this: header via email. There are two possibilities for doing this:
(a) The complete article is encapsulated (headers and all) within (a) The complete article is encapsulated (headers and all) within
the email, preferably using the Content-Type the email, preferably using the Content-Type
"application/news-transmission" (6.21.6.1) with any usage "application/news-transmission" (6.21.6.1) with any usage
parameter set to "moderate". Moreover, there SHOULD NOT be parameter set to "moderate". Moreover, there SHOULD NOT be
skipping to change at page 78, line 5 skipping to change at page 67, line 55
8.3. Duties of a Relaying Agent 8.3. 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 relaying agents and passes them on to relaying or serving agents
according to mutually agreed policy. Relaying agents SHOULD accept according to mutually agreed policy. Relaying agents SHOULD accept
articles ONLY from trusted agents. articles ONLY from trusted agents.
A relaying agent processes articles as follows: A relaying agent processes articles as follows:
News Article Format April 2003
1. It MUST verify the leftmost entry in the Path-header and then 1. It MUST verify the leftmost entry in the Path-header and then
prepend its own path-identity with a '/' path-delimiter, and prepend its own path-identity with a '/' path-delimiter, and
possibly also the verified path-identity of its source with a '?' possibly also the verified path-identity of its source with a '?'
path-delimiter (5.6.2). path-delimiter (5.6.2).
News Article Format June 2003
2. It MUST reject any article whose Date-header is stale (see 5.1). 2. It MUST reject any article whose Date-header is stale (see 5.1).
3. It MUST reject any article that does not have the correct 3. It MUST reject any article that does not have the correct
mandatory headers (section 5) present with legal contents. mandatory headers (section 5) present with legal contents.
4. It SHOULD reject any article whose optional headers (section 6) do 4. It SHOULD reject any article whose optional headers (section 6) do
not have legal contents. not have legal contents.
5. It SHOULD reject any article that has already been sent to it (a 5. It SHOULD reject any article that has already been sent to it (a
database of message identifiers of recent messages is usually kept database of message identifiers of recent messages is usually kept
skipping to change at page 79, line 5 skipping to change at page 68, line 53
entity has explicitly requested that it be informed of such errors. entity has explicitly requested that it be informed of such errors.
NOTE: In order to prevent overloading, relaying agents should NOTE: In order to prevent overloading, relaying agents should
not routinely query an external entity (such as a DNS-server) in not routinely query an external entity (such as a DNS-server) in
order to verify an article (though a local cache of the required order to verify an article (though a local cache of the required
information might usefully be consulted). information might usefully be consulted).
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 expect for headers designated as variant (4.2.5.3). article expect for headers designated as variant (4.2.5.3).
News Article Format April 2003
8.4. Duties of a Serving Agent 8.4. Duties of a Serving Agent
A Serving Agent takes an article from a relaying or injecting agent A Serving Agent takes an article from a relaying or injecting agent
and files it in a "news database". It also provides an interface for and files it in a "news database". It also provides an interface for
reading agents to access the news database. This database is normally reading agents to access the news database. This database is normally
indexed by newsgroup with articles in each newsgroup identified by an indexed by newsgroup with articles in each newsgroup identified by an
article-locater (usually in the form of a decimal number - see 6.16). article-locater (usually in the form of a decimal number - see 6.16).
News Article Format June 2003
NOTE: Since control messages are often of interest, but should NOTE: Since control messages are often of interest, but should
not be displayed as normal articles in regular newsgroups, it is not be displayed as normal articles in regular newsgroups, it is
common for serving agents to make them available in a pseudo- common for serving agents to make them available in a pseudo-
newsgroup named "control" or in a pseudo-newsgroup in a sub- newsgroup named "control" or in a pseudo-newsgroup in a sub-
hierarchy under "control." (e.g. "control.cancel"). hierarchy under "control." (e.g. "control.cancel").
A serving agent processes articles as follows: A serving agent processes articles as follows:
1. It MUST verify the leftmost entry in the Path-header and then 1. It MUST verify the leftmost entry in the Path-header and then
prepend its own path-identity with a '/' path-delimiter, and prepend its own path-identity with a '/' path-delimiter, and
skipping to change at page 79, line 44 skipping to change at page 69, line 36
4. It SHOULD reject any article that has already been sent to it (a 4. It SHOULD reject any article that has already been sent to it (a
database of message identifiers of recent messages is usually kept database of message identifiers of recent messages is usually kept
and matched against). and matched against).
5. It SHOULD reject any article that matches an already received 5. It SHOULD reject any article that matches an already received
cancel message (or an equivalent Supersedes-header) issued by its cancel message (or an equivalent Supersedes-header) issued by its
poster or by some other trusted entity. poster or by some other trusted entity.
6. It MUST reject any article without an Approved-header posted to 6. It MUST reject any article without an Approved-header posted to
any moderated newsgroup which it is configured to receive, and it any moderated newsgroup which it is configured to receive, and it
MAY reject such articles for any newsgroup it knows be moderated. MAY reject such articles for any newsgroup it knows to be
moderated.
7. It MUST remove any Xref-header (6.16) from each article. It then 7. It MUST remove any Xref-header (6.16) from each article. It then
MAY (and usually will) generate a fresh Xref-header. MAY (and usually will) generate a fresh Xref-header.
8. Finally, it stores the article in its news database. 8. Finally, it stores the article in its news database.
8.5. Duties of a Posting Agent 8.5. Duties of a Posting Agent
A Posting Agent is used to assist the poster in creating a valid A Posting Agent is used to assist the poster in creating a valid
proto-article and forwarding it to an injecting agent. proto-article and forwarding it to an injecting agent.
Postings agents SHOULD ensure that proto-articles they create are Postings agents SHOULD ensure that proto-articles they create are
valid news articles according to this standard and other applicable valid news articles according to this standard and other applicable
policies. policies.
News Article Format April 2003
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 which cancels or Supersedes another
article of which the poster is not the author. article of which the poster is not the author.
News Article Format June 2003
8.6. Duties of a Followup Agent 8.6. Duties of a Followup Agent
A Followup Agent is a special case of a posting agent and as such is A Followup Agent is a special case of a posting agent and as such is
bound by all the posting agent's requirements plus additional ones. bound by all the posting agent's requirements. Followup agents MUST
Followup agents MUST create valid followups, in particular by create valid followups and are subject to the following special
providing correctly adjusted forms of those headers described as requirements involving certain inheritable (4.2.5.2) and other
inheritable (4.2.5.2), notably the Newsgroups-header (5.5), the headers.
Subject-header (5.4) and the References-header (6.10), and they Ought
to observe appropriate quoting conventions in the body (see 4.3.2).
Followup agents SHOULD initialize the Newsgroups-header from the 1. The Newsgroups-header (5.5) SHOULD be initialized from the
precursor's Followup-To-header, if present, when preparing a precursor's Followup-To-header, if present, when preparing a
followup; however posters MAY then change this before posting if they followup; however posters MAY then change this before posting if
wish. they wish.
Followup agents MUST NOT attempt to send email to any address ending 2. The Subject-content (5.4) of the precursor MAY (and usually will)
in ".invalid". Followup agents SHOULD NOT email copies of the be prepended with the back-reference "Re: " (which is case
followup to the poster of the precursor unless this has been sensitive), unless that precursor is itself a followup with "Re: "
explicitly requested by means of a Mail-Copies-To-header (6.8), but already present in its Subject-content; however posters MAY then
they SHOULD include a Posted-And-Mailed-header (6.9) whenever a copy change this before posting if they wish.
is so emailed.
Followup agents MUST NOT use any other string except "Re: " as a
back-reference, and specifically NOT a translation of "Re: " into
a local language, and they MUST NOT prepend a "Re: " if one is
already present.
[The provision of back-references and their allowed forms are still
under discussion in the Usefor Working Group.
The matter of a "Re: " occurring within an encoded-word needs to be
clarified.]
NOTE: "Re" is an abbreviation for the Latin "In re", meaning "in
the matter of", and not an abbreviation of "Reference" as is
sometimes erroneously supposed. Reading agents often take note
of a single "Re: " at the beginning of a Subject-content (for
example, in order to display a list of articles sorted by
Subject). These restrictions ensure that reading agents have no
need to recognize more than a single occurrence of "Re: ".
3. The Distribution-header (6.6) SHOULD be initialized from the
precursor's Distribution-header, if any; however posters MAY then
change this before posting if they wish.
4. If the precursor did not have a References-header (6.10), the
followup's References-content MUST be formed by the message
identifier of the precursor. A followup to an article which had a
References-header MUST have a References-header containing the
precursor's References-content (subject to trimming as described
below) plus the precursor's message identifier appended to the end
of the list (separated from it by CFWS).
Followup agents MAY trim References-headers which have grown to
excessive length, but the first and last message identifiers from
the precursor MUST NOT be removed.
News Article Format June 2003
5. If the precursor contains a Mail-Copies-To-header (6.8), The
actions to be taken, in accordance with the Mail-Copies-To-
content, (and subject to manual override by the poster) are as
follows:
"nobody" (or when the header is absent)
The followup agent SHOULD NOT email a copy of the followup
to the poster of the precursor.
"poster"
The followup agent SHOULD (if it has the necessary
capability) email a copy of the followup, which MUST then be
sent to the address(es) in the Reply-To-header, and in the
absence of that to the address(es) in the From-header.
a copy-addr
The followup agent SHOULD likewise email a copy of the
followup, which MUST then be sent to the copy-addr.
When emailing a copy, the followup agent SHOULD also include a
"Posted-And-Mailed: yes" header (6.9).
Followup agents MUST NOT attempt to send email to any address
ending in ".invalid".
8.7. Duties of a Moderator 8.7. Duties of a Moderator
A Moderator receives news articles by email, decides whether to A Moderator receives news articles by email, decides whether to
accept them and, if so, either injects them into the news stream or accept them and, if so, either injects them into the news stream or
forwards them to further moderators. forwards them to further moderators.
Articles will be received by the moderator either encapsulated as an Articles will be received by the moderator either encapsulated as an
object of Content-Type application/news-transmission (or possibly object of Content-Type application/news-transmission (or possibly
encapsulated but without an explicit Content-Type-header), or else encapsulated but without an explicit Content-Type-header), or else
skipping to change at page 80, line 54 skipping to change at page 71, line 53
accept articles in either format. accept articles in either format.
A moderator processes an article, as submitted to any newsgroup that A moderator processes an article, as submitted to any newsgroup that
he moderates, as follows: he moderates, as follows:
1. He decides, on the basis of whatever moderation policy applies to 1. He decides, on the basis of whatever moderation policy applies to
his group, whether to accept or reject the article. He MAY do this his group, whether to accept or reject the article. He MAY do this
manually, or else partially or wholly with the aid of appropriate manually, or else partially or wholly with the aid of appropriate
software for whose operation he is then responsible. If the software for whose operation he is then responsible. If the
article is a cancel nessage (7.3) issued by the poster of an article is a cancel nessage (7.3) issued by the poster of an
earlier article, then he Ought to cancel it (in which case there earlier article, then he is expected to cancel that earlier
is no more to be done). He MAY modify the article if that is in article (in which case there is no more to be done). He MAY
accordance with the applicable moderation policy (and in modify the article if that is in accordance with the applicable
particular he MAY remove redundant headers and add Comments and moderation policy (and in particular he MAY remove redundant
other informational headers). He also needs to be aware if any headers and add Comments and other informational headers). He
change he makes to the article will invalidate some authentication also needs to be aware if any change he makes to the article will
check provided by the poster or by an earlier moderator. invalidate some authentication check provided by the poster or by
an earlier moderator.
News Article Format April 2003 News Article Format June 2003
He MAY inform the poster if the article is accepted, and he Ought If the article is rejected, then it normally fails for all the
to inform the poster if it is rejected. If it is rejected, then newsgroups for which it was intended. If it is accepted, the
it normally fails for all the newsgroups for which it was moderator proceeds with the following steps.
intended. If it is accepted, the moderator proceeds with the
following steps.
2. If the Newsgroups-header contains further moderated newsgroups for 2. If the Newsgroups-header contains further moderated newsgroups for
which approval has not already been given, he adds an indication which approval has not already been given, he adds an indication
(identifying both himself and the name of the group) that he (identifying both himself and the name of the group) that he
approves the article, and then forwards it to the moderator of the approves the article, and then forwards it to the moderator of the
leftmost unapproved group (which, if this standard has been leftmost unapproved group (which, if this standard has been
followed correctly, will generally be the next moderated group to followed correctly, will generally be the next moderated group to
the right of his own). There are two ways to do this: the right of his own). There are two ways to do this:
(a) He emails it to the submission address of the next moderator (a) He emails it to the submission address of the next moderator
skipping to change at page 81, line 47 skipping to change at page 72, line 45
is sometimes used for this purpose). The approval may also be is sometimes used for this purpose). The approval may also be
confirmed with some form of digital signature (7.1). confirmed with some form of digital signature (7.1).
3. If the Newsgroups-header contains no further unapproved moderated 3. If the Newsgroups-header contains no further unapproved moderated
groups, he adds an Approved-header (6.14) identifying himself and, groups, he adds an Approved-header (6.14) identifying himself and,
insofar as is possible, all the other moderators who have approved insofar as is possible, all the other moderators who have approved
the article. He thus assumes responsibility for having ensured the article. He thus assumes responsibility for having ensured
that the article was acceptable to the moderators of all the that the article was acceptable to the moderators of all the
moderated groups involved. moderated groups involved.
4. A moderator Ought Not (absent any established and widely 4. The Date-header SHOULD be retained, except that if it is stale
promulgated policy to the contrary) to remove any newsgroup-name
from the Newsgroups-header, nor split an article into two versions
with disjoint Newsgroups-headers. These are matters more usually
within the prerogative of the poster; moreover splitting can lead
to fragmentation of threads.
5. The Date-header SHOULD be retained, except that if it is stale
(5.1) for reasons understood by the moderator (e.g. delays in the (5.1) for reasons understood by the moderator (e.g. delays in the
moderation process) he MAY substitute the current date (but must moderation process) he MAY substitute the current date (but must
then take responsibility for any loops that ensue). The Message- then take responsibility for any loops that ensue). The Message-
ID-header SHOULD also be retained unless it is obviously non- ID-header SHOULD also be retained unless it is obviously non-
compliant with this standard. compliant with this standard.
News Article Format April 2003
NOTE: A message identifier created by a conforming posting or NOTE: A message identifier created by a conforming posting or
injecting agent, or even by a mail user agent conforming to [RFC injecting agent, or even by a mail user agent conforming to [RFC
2822], may reasonably be supposed to be conformant (and will, in 2822], may reasonably be supposed to be conformant (and will, in
any case, be caught by the injecting agent if it is not). any case, be caught by the injecting agent if it is not).
6. Any variant headers (4.2.5.3) MUST be removed, except that a 5. Any variant headers (4.2.5.3) MUST be removed, except that a
Path-header MAY be truncated to only its pre-injection region Path-header MAY be truncated to only its pre-injection region
(5.6.3). Any Injector-Info-header (6.19) or Complaints-To-header (5.6.3). Any Injector-Info-header (6.19) or Complaints-To-header
(6.20) MUST be removed. (6.20) MUST be removed.
7. He then causes the article to be injected, having first observed News Article Format June 2003
6. He then causes the article to be injected, having first observed
all the duties of a posting agent. all the duties of a posting agent.
NOTE: This standard does not prescribe how the moderator or NOTE: This standard does not prescribe how the moderator or
moderation policy for each newsgroup is established; rather it moderation policy for each newsgroup is established; rather it
assumes that whatever agencies are responsible for the relevant assumes that whatever agencies are responsible for the relevant
network or hierarchy (1.1) will have made appropriate network or hierarchy (1.1) will have made appropriate
arrangements in that regard. arrangements in that regard.
8.8. Duties of a Gateway 8.8. Duties of a Gateway
skipping to change at page 83, line 5 skipping to change at page 73, line 51
below. below.
If bidirectional gatewaying (both an incoming and an outgoing If bidirectional gatewaying (both an incoming and an outgoing
gateway) is being set up between Netnews and some other medium, the gateway) is being set up between Netnews and some other medium, the
incoming and outgoing gateways SHOULD be coordinated to avoid incoming and outgoing gateways SHOULD be coordinated to avoid
reinjection of gated articles. Circular gatewaying (gatewaying a reinjection of gated articles. Circular gatewaying (gatewaying a
message into another medium and then back into Netnews) SHOULD NOT be message into another medium and then back into Netnews) SHOULD NOT be
done; encapsulation of the article SHOULD be used instead where this done; encapsulation of the article SHOULD be used instead where this
is necessary. is necessary.
News Article Format April 2003
A second general principal of gatewaying is that the transformations A second general principal of gatewaying is that the transformations
applied to the message SHOULD be as minimal as possible while still applied to the message SHOULD be as minimal as possible while still
accomplishing the gatewaying. Every change made by a gateway accomplishing the gatewaying. Every change made by a gateway
potentially breaks a property of one of the media or loses potentially breaks a property of one of the media or loses
information, and therefore only those transformations made necessary information, and therefore only those transformations made necessary
by the differences between the media should be applied. by the differences between the media should be applied.
It is worth noting that safe bidirectional gatewaying between a It is worth noting that safe bidirectional gatewaying between a
mailing list and a newsgroup is far easier if the newsgroup is mailing list and a newsgroup is far easier if the newsgroup is
moderated. Posts to the moderated group and submissions to the moderated. Posts to the moderated group and submissions to the
News Article Format June 2003
mailing list can then go through a single point that does the mailing list can then go through a single point that does the
necessary gatewaying and then sends the message out to both the necessary gatewaying and then sends the message out to both the
newsgroup and the mailing list at the same time, eliminating most of newsgroup and the mailing list at the same time, eliminating most of
the possibility of loops. Bidirectional gatewaying between a mailing the possibility of loops. Bidirectional gatewaying between a mailing
list and an unmoderated newsgroup, in contrast, is difficult to do list and an unmoderated newsgroup, in contrast, is difficult to do
correctly and is far more fragile. 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
is a simple gateway and injecting agent that correctly handles is a simple gateway and injecting agent that correctly handles
skipping to change at page 84, line 5 skipping to change at page 74, line 49
2. The Date of the news article should also be preserved if possible, 2. The Date of the news article should also be preserved if possible,
for similar reasons. 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, a to provide some indication even if not successful; at the least, a
human-readable indication that the article should not be gated 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.
News Article Format April 2003
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.
8.8.2. Duties of an Incoming Gateway 8.8.2. Duties of an Incoming Gateway
The incoming gateway has the serious responsibility of ensuring that The incoming gateway has the serious responsibility of ensuring that
all of the requirements of this standard are met by the articles that all of the requirements of this standard are met by the articles that
it forms. In addition to its special duties as a gateway, it bears it forms. In addition to its special duties as a gateway, it bears
all of the duties and responsibilities of an injecting agent as well, all of the duties and responsibilities of an injecting agent as well,
and additionally has the same responsibility of a relaying agent to and additionally has the same responsibility of a relaying agent to
reject articles that it has already gatewayed. reject articles that it has already gatewayed.
News Article Format June 2003
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 headers (like message it has already gated identical except for trace headers (like
Received in Email or Path in Netnews) MUST NOT gate the message Received in Email or Path in Netnews) MUST NOT gate the message
again. An incoming gateway SHOULD take precautions against having again. An incoming gateway SHOULD take precautions against having
this rule bypassed by modifications of the message that can be this rule bypassed by modifications of the message that can be
anticipated. anticipated.
News articles prepared by gateways MUST be legal news articles. In News articles prepared by gateways MUST be legal news articles. In
skipping to change at page 85, line 5 skipping to change at page 75, line 49
to post control messages, but encapsulation should be used for to post control messages, but encapsulation should be used for
these cases instead. Gateways by their very nature are these cases instead. Gateways by their very nature are
particularly prone to loops. Spews of normal articles are bad particularly prone to loops. Spews of normal articles are bad
enough; spews of control messages with special significance to enough; spews of control messages with special significance to
the news system, possibly resulting in high processing load or the news system, possibly resulting in high processing load or
even email sent for every message received, are catastrophic. It even email sent for every message received, are catastrophic. It
is far preferable to construct a system specifically for posting is far preferable to construct a system specifically for posting
control messages that can do appropriate consistency checks and control messages that can do appropriate consistency checks and
authentication of the originator of the message. authentication of the originator of the message.
News Article Format April 2003
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 in news, it SHOULD be used in the formation of the Message-ID-header in news, it SHOULD be used in the formation of
the message identifier of the news article, perhaps with 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 5.3. Such transformations SHOULD be designed so syntax in section 5.3. Such transformations SHOULD be designed so
that two messages with the same identifier generate the same that two messages with the same identifier generate the same
Message-ID-header. Message-ID-header.
NOTE: Message identifiers play a central role in the prevention NOTE: Message identifiers play a central role in the prevention
of duplicates, and their correct use by gateways will do much to of 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
News Article Format June 2003
identifiers be unique, and therefore message identifiers from identifiers be unique, and therefore message identifiers from
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. Each one SHOULD generate a message identifier unique to that gateway. Each
incoming gateway nonetheless MUST ensure that it does not gate the incoming gateway nonetheless MUST ensure that it does not gate the
skipping to change at page 86, line 5 skipping to change at page 76, line 44
reinjection of old messages. reinjection of old messages.
An incoming gateway MUST add a Sender-header to the news article it An incoming gateway MUST add a Sender-header to the news article it
forms containing the mailbox of the administrator of the gateway. forms containing the mailbox of the administrator of the gateway.
Problems with the gateway may be reported to this mailbox. The Problems with the gateway may be reported to this mailbox. The
display-name portion of this mailbox SHOULD indicate that the entity display-name portion of this mailbox SHOULD indicate that the entity
responsible for injection of the message is a gateway. If the responsible for injection of the message is a gateway. If the
original message already had a Sender-header, it SHOULD be renamed so original message already had a Sender-header, it SHOULD be renamed so
that its contents can be preserved. that its contents can be preserved.
News Article Format April 2003
8.8.3. Example 8.8.3. 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 at Stanford combination of mail-to-news and news-to-mail gateways at Stanford
University designed to handle bidirectional gatewaying between University designed to handle bidirectional gatewaying between
mailing lists and unmoderated groups. mailing lists and unmoderated 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.
News Article Format June 2003
2. The news-to-mail gateway adds an X-Gateway-header to all messages 2. The news-to-mail gateway adds an X-Gateway-header 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. This is robust against mailing messages containing this header. This is robust against mailing
list managers that replace the message identifier, and against any list managers that replace the message identifier, and against any
number of email hops, provided that the other message headers are number of email hops, provided that the other message headers are
preserved. preserved.
3. The mail-to-news gateway inserts the host name from which it 3. The mail-to-news gateway inserts the host name from which it
received the email message in the pre-injection region of the Path received the email message in the pre-injection region of the Path
(5.6.3). The news-to-mail gateway refuses to gateway any message (5.6.3). The news-to-mail gateway refuses to gateway any message
skipping to change at page 87, line 5 skipping to change at page 77, line 43
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. which is in turn gated to a different newsgroup.
9. Security and Related Considerations 9. Security and Related Considerations
There is no security. Don't fool yourself. Usenet is a prime example There is no security. Don't fool yourself. Usenet is a prime example
of an Internet Adhocratic-Anarchy; that is, an environment in which of an Internet Adhocratic-Anarchy; that is, an environment in which
trust forms the basis of all agreements. It works. trust forms the basis of all agreements. It works.
News Article Format April 2003
9.1. Leakage 9.1. Leakage
Articles which are intended to have restricted distribution are Articles which are intended to have restricted distribution are
dependent on the goodwill of every site receiving them. The dependent on the goodwill of every site receiving them. The
"Archive: no" header (6.12) is available as a signal to automated "Archive: no" header (6.12) is available as a signal to automated
archivers not to file an article, but that cannot be guaranteed. archivers not to file an article, but that cannot be guaranteed.
The Distribution-header makes provision for articles which should not The Distribution-header makes provision for articles which should not
be propagated beyond a cooperating subnet. The key security word here be propagated beyond a cooperating subnet. The key security word here
is "cooperating". When a machine is not configured properly, it may is "cooperating". When a machine is not configured properly, it may
become uncooperative and tend to distribute all articles. become uncooperative and tend to distribute all articles.
The flooding algorithm is extremely good at finding any path by which The flooding algorithm is extremely good at finding any path by which
articles can leave a subnet with supposedly restrictive boundaries, articles can leave a subnet with supposedly restrictive boundaries,
and substantial administrative effort is required to avoid this. and substantial administrative effort is required to avoid this.
Organizations wishing to control such leakage are strongly advised to Organizations wishing to control such leakage are strongly advised to
designate a small number of official gateways to handle all news designate a small number of official gateways to handle all news
exchange with the outside world (however, making such gateways too exchange with the outside world (however, making such gateways too
News Article Format June 2003