idnits 2.17.1 draft-allbery-usefor-usepro-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1850. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1861. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1868. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1874. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 5 instances of lines with non-RFC2606-compliant FQDNs in the document. -- The draft header indicates that this document obsoletes RFC1036, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 30, 2006) is 6356 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'FWS' is mentioned on line 1490, but not defined == Missing Reference: 'Ihave-argument' is mentioned on line 1538, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) -- Possible downref: Non-RFC (?) normative reference: ref. 'USEFOR' -- Obsolete informational reference (is this intentional?): RFC 1036 (Obsoleted by RFC 5536, RFC 5537) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Usenet Format Working Group R. Allbery, Ed. 3 Internet-Draft Stanford University 4 Obsoletes: 1036 (if approved) C. Lindsey 5 Intended status: Standards Track University of Manchester 6 Expires: June 3, 2007 November 30, 2006 8 Netnews Architecture and Protocols 9 draft-allbery-usefor-usepro-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on June 3, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document defines the architecture of Netnews systems and 43 specifies the correct manipulation and interpretation of Netnews 44 articles by software which originates, distributes, stores, and 45 displays them. It also specifies the requirements that must be met 46 by any protocol used to transport and serve Netnews articles. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 1.1. Basic Concepts . . . . . . . . . . . . . . . . . . . . . . 4 52 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 1.3. Requirements Notation . . . . . . . . . . . . . . . . . . 4 54 1.4. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 3. Duties of Agents . . . . . . . . . . . . . . . . . . . . . . . 7 57 3.1. General Principles . . . . . . . . . . . . . . . . . . . . 7 58 3.2. Path Identities . . . . . . . . . . . . . . . . . . . . . 8 59 3.3. Duties of a Posting Agent . . . . . . . . . . . . . . . . 9 60 3.3.1. Proto-articles . . . . . . . . . . . . . . . . . . . . 9 61 3.3.2. Reinjection of Articles . . . . . . . . . . . . . . . 10 62 3.3.3. Followups . . . . . . . . . . . . . . . . . . . . . . 10 63 3.3.4. Construction of the References Header Field . . . . . 11 64 3.4. Duties of an Injecting Agent . . . . . . . . . . . . . . . 12 65 3.4.1. Forwarding Messages to a Moderator . . . . . . . . . . 14 66 3.5. Duties of a Relaying Agent . . . . . . . . . . . . . . . . 15 67 3.5.1. Path Header Field Example . . . . . . . . . . . . . . 17 68 3.6. Duties of a Serving Agent . . . . . . . . . . . . . . . . 18 69 3.7. Duties of a Reading Agent . . . . . . . . . . . . . . . . 19 70 3.8. Duties of a Moderator . . . . . . . . . . . . . . . . . . 19 71 3.9. Duties of a Gateway . . . . . . . . . . . . . . . . . . . 21 72 3.9.1. Duties of an Outgoing Gateway . . . . . . . . . . . . 22 73 3.9.2. Duties of an Incoming Gateway . . . . . . . . . . . . 23 74 3.9.3. Gateway Example . . . . . . . . . . . . . . . . . . . 25 75 4. Media Types . . . . . . . . . . . . . . . . . . . . . . . . . 26 76 4.1. application/news-transmission . . . . . . . . . . . . . . 26 77 4.2. application/news-groupinfo . . . . . . . . . . . . . . . . 27 78 4.3. application/news-checkgroups . . . . . . . . . . . . . . . 28 79 5. Control Messages . . . . . . . . . . . . . . . . . . . . . . . 30 80 5.1. Authentication and Authorization . . . . . . . . . . . . . 30 81 5.2. Group Control Messages . . . . . . . . . . . . . . . . . . 31 82 5.2.1. The newgroup Control Message . . . . . . . . . . . . . 31 83 5.2.2. The rmgroup Control Message . . . . . . . . . . . . . 33 84 5.2.3. The checkgroups Control Message . . . . . . . . . . . 33 85 5.3. The cancel Control Message . . . . . . . . . . . . . . . . 34 86 5.4. The Supersedes Header Field . . . . . . . . . . . . . . . 35 87 5.5. The ihave and sendme Control Messages . . . . . . . . . . 35 88 5.6. Obsolete Control Messages . . . . . . . . . . . . . . . . 36 89 6. Security Considerations . . . . . . . . . . . . . . . . . . . 37 90 6.1. Compromise of System Integrity . . . . . . . . . . . . . . 37 91 6.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 38 92 6.3. Leakage . . . . . . . . . . . . . . . . . . . . . . . . . 39 93 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 94 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 95 8.1. Normative References . . . . . . . . . . . . . . . . . . . 41 96 8.2. Informative References . . . . . . . . . . . . . . . . . . 41 97 Appendix A. Changes to the Existing Protocols . . . . . . . . . . 42 98 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 43 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 100 Intellectual Property and Copyright Statements . . . . . . . . . . 45 102 1. Introduction 104 1.1. Basic Concepts 106 "Netnews" is a set of protocols for generating, storing and 107 retrieving news "articles" whose format is defined in [USEFOR], and 108 for exchanging them amongst a readership that is potentially widely 109 distributed. It is organized around "newsgroups", with the 110 expectation that each reader will be able to see all articles posted 111 to each newsgroup in which he participates. These protocols most 112 commonly use a flooding algorithm which propagates copies throughout 113 a network of participating servers. Typically, only one copy is 114 stored per server, and each server makes it available on demand to 115 readers able to access that server. 117 "Usenet" is a particular worldwide publicly accessible network based 118 on the Netnews protocols. It is only one such possible network; 119 there are deployments of the Netnews protocols other than Usenet 120 (such as ones internal to particular organizations). This document 121 discusses the more general Netnews architecture and protocols. 123 1.2. Scope 125 This document defines the architecture of Netnews systems and 126 specifies the correct manipulation and interpretation of Netnews 127 articles by software which originates, distributes, stores, and 128 displays them. It addresses protocol issues that are independent of 129 transport protocols such as NNTP [RFC3977] and specifies the 130 requirements Netnews places on those underlying transport protocols. 131 It also specifies the handling of control messages. 133 The format and syntax of Netnews articles are specified in [USEFOR], 134 which should be read in conjunction with this document. 136 Comments are solicited and should be addressed to the Usenet Format 137 Working Group at ietf-usefor@imc.org or to the editor. 139 1.3. Requirements Notation 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in [RFC2119]. 145 1.4. Definitions 147 Any term used in this document that is defined in Section 1.5 of 148 [USEFOR] is used with the definition given there. In addition, the 149 following terms will be used: 151 A "hierarchy" is the set of all newsgroups whose names share a first 152 (as defined in Section 3.1.4 of [USEFOR]). A "sub- 153 hierarchy" is the set of all newsgroups whose names share several 154 initial components. 156 A "news server" is further distinguished into the roles of "injecting 157 agent", "relaying agent", and "serving agent". An "injecting agent" 158 accepts a proto-article with the goal of distributing it to relaying 159 and serving agents and hence to readers. A "relaying agent" accepts 160 articles from other relaying agents or injecting agents and 161 distributes them to other relaying agents or serving agents. A 162 "serving agent" receives an article from a relaying agent or 163 injecting agent and makes it available to readers. 165 A "user agent" is further distinguished into the roles of "posting 166 agent" and "reading agent". A "posting agent" is software which 167 assists in the preparation of a proto-article and then passes it to 168 an injecting agent. A "reading agent" is software which retrieves 169 articles from a serving agent for presentation to a reader. 171 "Injecting" an article is the processing of a proto-article by an 172 injecting agent. Normally this action is done once and only once for 173 a given article. "Reinjecting" an article is passing an already- 174 injected article to an injection agent. 176 A "gateway" is software which receives news articles and converts 177 them to messages of some other kind (such as [RFC2822] mail 178 messages), receives messages of some other kind and converts them to 179 news articles, or conveys articles between two separate Netnews 180 networks. 182 2. Transport 184 The exact means used to transmit articles from one agent to another 185 is not specified. NNTP [RFC3977] is the most common transport 186 mechanism for Netnews networks. Other methods in use include the 187 UUCP protocol [RFC0976] (extensively used in the early days of 188 Usenet) and physically delivered magnetic and optical media. Any 189 mechanism may be used in conjunction with this protocol provided that 190 it can meet the requirements specified here. 192 Transports for Netnews articles MUST treat news articles as 193 uninterpreted sequences of octets, excluding the values 0 (which may 194 not occur in Netnews articles) and 13 and 10 (which MUST only appear 195 in Netnews articles as a pair in that order and which together denote 196 a line separator). These octets are the US-ASCII [ASCII] characters 197 NUL, CR, and LF respectively. 199 NOTE: This corresponds to the range of octets permitted in MIME 200 8bit data [RFC2045]. Transports for Netnews are not required to 201 support transmission of MIME binary data. 203 In particular, transports MUST convey all header fields (including 204 header fields within message/rfc822 objects in article bodies) 205 unmodified even if they contain octets in the range 128 to 255. 206 Furthermore, transports for relaying and serving agents MUST, and 207 transports for other agents SHOULD, convey lines even if they exceed 208 998 characters in length, especially in article bodies. (This 209 requirement is stricter than MIME 8bit data.) These requirements 210 include the transport paths between posting agents, injecting agents, 211 serving agents, and reading agents. 213 3. Duties of Agents 215 The following section specifies the duties of the agents involved in 216 the creation, relaying, and serving of Netnews articles. This 217 protocol is described by following the life of a typical Usenet 218 article: it is prepared by a posting agent, given to an injecting 219 agent, transferred through one or more relaying agents, accepted by a 220 serving agent, and finally retrieved by a reading agent. Articles 221 submitted to moderated groups go through an additional process, which 222 is described separately. Finally, the additional duties and 223 requirements of a gateway are discussed. 225 At each step, each agent has a set of checks and transformations of 226 the article that it is required to perform. These are described as 227 sequences of steps to be followed, but it should be understood that 228 it is the effect of these sequences that is important, and 229 implementations may use any method that gives rise to the same 230 effect. 232 Many news servers combine the functions of injecting agent, relaying 233 agent, and serving agent in a single software package. For the 234 purposes of this specification, such combined agents should 235 conceptually be treated as an injecting agent which sends articles to 236 a serving agent and optionally a relaying agent. The requirements of 237 all three agents MUST be still met when the news server is performing 238 the functions of those agents. 240 Control messages may have additional effects than those described 241 below on news servers which accept them. Those effects are described 242 in Section 5. 244 3.1. General Principles 246 There are two important principles that news implementors and 247 administrators need to keep in mind. The first is the well-known 248 Internet Robustness Principle: 250 Be liberal in what you accept, and conservative in what you send. 252 As applied to Netnews, this primarily means that unwanted or non- 253 compliant articles SHOULD be rejected as early as possible, but once 254 they are in general circulation, relaying and serving agents may wish 255 to accept them where possible rather than lose information. Posting 256 agents and injecting agents SHOULD therefore be maximally strict in 257 their application of both this protocol and [USEFOR], and reading 258 agents SHOULD be robust in the presence of violations of the Netnews 259 article format where possible. 261 In the case of Netnews, there is an even more important principle, 262 derived from a much older code of practice, the Hippocratic Oath (we 263 may thus call this the Hippocratic Principle): 265 First, do no harm. 267 It is vital to realize that decisions which might be merely 268 suboptimal in a smaller context can become devastating mistakes when 269 amplified by the actions of thousands of hosts within a few minutes. 271 No Netnews agent is ever required to accept any article. It is 272 common for injecting, relaying, and serving agents to reject well- 273 formed articles for reasons of local policy (such as not wishing to 274 carry a particular newsgroup or attempting to filter out unwanted 275 articles). This document specifies how articles are to be treated if 276 they are accepted and specifies some cases where they must be 277 rejected, but an agent MAY always reject any article for other 278 reasons than those stated here. 280 A primary goal of the Netnews protocol is to ensure that all readers 281 receiving a particular article (as uniquely identified by the content 282 of its Message-ID header field) see the identical article, apart from 283 allowable divergence in trace headers and local metadata. 284 Accordingly, agents (other than moderators) MUST NOT modify articles 285 in ways other than described here. Unacceptable articles MUST be 286 rejected rather than corrected. 288 3.2. Path Identities 290 All news server components (injecting agents, relaying agents, and 291 serving agents) MUST identify themselves, when processing an article, 292 by prepending their (defined in Section 3.1.5 of 293 [USEFOR]) to the Path header field. Injecting agents MUST also use 294 the same identity in Injection-Info header fields they add, and 295 serving and relaying agents SHOULD use the same identity in any Xref 296 header fields they add. 298 The used by an agent may be chosen via one of the 299 following methods (in decreasing order of preference): 301 1. The fully-qualified domain name (FQDN) of the system on which the 302 agent is running. 304 2. A fully-qualified domain name (FQDN) within a domain affiliated 305 with the administrators of the agent and guaranteed to be unique 306 by the administrators of that domain. For example, the 307 uniqueness of server.example.org could be guaranteed by the 308 administrator of example.org even if there is no DNS record for 309 server.example.org itself. 311 3. Some other (arbitrary) name in the form believed to 312 be unique and registered at least with all the other news servers 313 to which that relaying agent or injecting agent sends articles. 314 This option SHOULD NOT be used unless the earlier options are 315 unavailable or unless the name is of longstanding usage. 317 Path identities are case sensitive. To avoid unintentional variation 318 in a news server's identity, the SHOULD be all 319 lowercase. 321 3.3. Duties of a Posting Agent 323 A posting agent is the component of a user agent that assists a 324 poster in creating a valid proto-article and forwarding it to an 325 injecting agent. 327 Posting agents SHOULD ensure that proto-articles they create are 328 valid according to [USEFOR] and any other applicable policies. They 329 MUST NOT create any Injection-Date or Injection-Info header fields; 330 these headers will be added by the injecting agent. 332 Contrary to [RFC2822], which implies that the mailbox or mailboxes in 333 the From header field should be that of the poster or posters, a 334 poster who does not, for whatever reason, wish to use his own mailbox 335 MAY use any mailbox ending in the top level domain ".invalid" 336 [RFC2606]. 338 Posting agents meant for use by ordinary posters SHOULD reject any 339 attempt to post an article which cancels or Supersedes another 340 article of which the poster is not the author or sender. 342 3.3.1. Proto-articles 344 A proto-article is an article in the format used by a posting agent 345 for offering to an injecting agent. It may omit certain header 346 fields which can be better-supplied by the injecting agent and will 347 not contain header fields that are added by the injecting agent. A 348 proto-article is only for transmission to an injecting agent and 349 SHOULD NOT be transmitted to any other agent. 351 A proto-article has the same format as a normal article except that 352 the Injection-Date, Injection-Info, and Xref header fields MUST NOT 353 be present; the Path header field MUST NOT contain a "POSTED" ; and any of the following mandatory header fields MAY be 355 omitted: Message-ID, Date, and Path. In all other respects, a proto- 356 article MUST be a valid Netnews article. In particular, the header 357 fields which may be omitted MUST NOT be present with invalid content. 359 If a posting agent intends to offer the same proto-article to 360 multiple injecting agents, the header fields Message-ID and Date MUST 361 be present and identical in all copies of the proto-article. 363 3.3.2. Reinjection of Articles 365 A given article SHOULD be processed by an injecting agent once and 366 only once. The Injection-Date or Injection-Info header fields are 367 added by an injecting agent and are not permitted in a proto-article. 368 Their presence (or the presence of other unstandardized or obsolete 369 trace headers such as NNTP-Posting-Host, NNTP-Posting-Date, or 370 X-Trace) indicates that the proto-article is instead an article and 371 has already been processed by an injecting agent. A posting agent 372 SHOULD normally reject such articles. 374 In the exceptional case that an article needs to be reinjected for 375 some reason (such as transferring an article from one Netnews to 376 another where those networks have no relaying agreement), the posting 377 agent doing the reinjection MUST convert the article back into a 378 proto-article before passing it to an injecting agent (such as by 379 renaming the Injection-Info and Injection-Date header fields and 380 removing any Xref header field) and MUST perform the date checks on 381 the existing Injection-Date or Date header fields that would 382 otherwise be done by the injecting agent. 384 Reinjecting articles may cause loops, loss of trace information, and 385 other problems and should only be done with care and when there is no 386 available alternative. A posting agent that does reinjection is a 387 limited type of gateway and as such is subject to all of the 388 requirements of an incoming gateway in addition to the requirements 389 of a posting agent. 391 3.3.3. Followups 393 A followup is an article that contains a response to the contents of 394 an earlier article, its precursor. In addition to its normal duties, 395 a posting agent preparing a followup is also subject to the following 396 requirements. Wherever in the following it is stated that by default 397 a header field is said to be inherited from one of those header 398 fields in the precursor, it means that its initial content is to be a 399 copy of the content of that precursor header field (with changes in 400 folding permitted). However, posters MAY then override that default 401 before posting. 403 Despite the historic practice of some posting agents, the Keywords 404 header field SHOULD NOT be inherited by default from the precursor 405 article. 407 1. If the Followup-To header field of the precursor article consists 408 of "poster", the followup MUST NOT be posted by default but by 409 default is to be emailed to the address given in the precursor's 410 Reply-To or From header field following the rules for an email 411 reply [RFC2822]. This action MAY be overridden by the poster, in 412 which case the posting agent should continue as if the 413 Followup-To header field in the precursor did not exist. 415 2. The Newsgroups header field SHOULD by default be inherited from 416 the precursor's Followup-To header field if present, and 417 otherwise from the precursor's Newsgroups header field. 419 3. The Subject header field SHOULD by default be inherited from that 420 of the precursor. The case-sensitive string "Re: " (including 421 the space after the colon) MAY be prepended to the content of its 422 Subject header field unless it already begins with that string. 424 NOTE: Prepending "Re: " serves no protocol function and hence 425 is not required, but it is widely expected and not doing so 426 would be surprising. 428 4. The Distribution header field SHOULD by default be inherited from 429 the precursor's Distribution header field, if present. 431 5. The followup MUST have a References header field referring to its 432 precursor constructed in accordance with Section 3.3.4. 434 3.3.4. Construction of the References Header Field 436 The following procedure is to be used whenever some previous article 437 (the "parent") is to be referred to in the References header field of 438 a new article, whether because the new article is a followup and the 439 parent is its precursor or for some other reason. 441 The content of the new article's References header field MUST be 442 formed from the content of the parent's References header field if 443 present and the content of the Message-ID header field of the parent. 444 If the parent had a References header, FWS as defined in [USEFOR] 445 MUST be added between its content and the Message-ID header field 446 content. 448 If the resulting References header field would, after unfolding, 449 exceed 998 characters in length (including its field name but not the 450 final CRLF), it SHOULD be trimmed (and otherwise MAY be trimmed). 451 Trimming means removing any number of message identifiers from its 452 content, except that the first message identifier and the last two 453 MUST NOT be removed. 455 An essential property of the References header field, guaranteed by 456 the above procedure and REQUIRED to be maintained by any extensions 457 to this protocol, is that an article MUST NOT precede one of its 458 parents. 460 3.4. Duties of an Injecting Agent 462 An injecting agent takes a proto-article from a posting agent and 463 either forwards it to a moderator or passes it to a relaying or 464 serving agent or agents. An injecting agent bears the primary 465 responsibility for ensuring that any article it injects conforms with 466 the rules of the Netnews standards. The administrator of an 467 injecting agent is also expected to bear some responsibility towards 468 the rest of the Netnews network to which it is connected for the 469 articles the injecting agent accepts. 471 Injecting agents, when rejecting articles, are encouraged to 472 communicate the reason for rejection to the posting agent using 473 whatever facility is provided by the underlying transport. The 474 injecting agent is in a unique position to communicate the reason for 475 rejection; relaying agents and serving agents normally have to reject 476 messages silently. The injecting agent therefore bears much of the 477 burden of diagnosing broken posting agents or communicating policy 478 violations to posters. 480 An injecting agent MUST have available a list (possibly empty) of 481 moderated groups for which it accepts articles and the corresponding 482 submission addresses. It SHOULD have available a list of valid 483 newsgroups to catch articles not posted to a valid newsgroup and 484 therefore likely to be silently discarded by relaying and serving 485 agents. Usually, an injecting agent is deployed in conjunction with 486 a serving agent and maintains these lists based on control messages 487 received by the serving agent. 489 An injecting agent processes proto-articles as follows: 491 1. It SHOULD verify that the article is from a trusted source (by, 492 for example, relying on the authorization capability of the 493 underlying transport used to talk to the posting agent). 495 2. It MUST reject any proto-article that does not have the proper 496 mandatory header fields for a proto-article; that has Injection- 497 Date, Injection-Info, or Xref header fields; that has a Path 498 header field containing the "POSTED" ; or that is 499 not syntactically valid as defined by [USEFOR]. It SHOULD 500 reject any proto-article which contains a header field 501 deprecated for Netnews. It MAY reject any proto-article that 502 contains trace header fields indicating that it was already 503 injected by an injecting agent that did not add Injection-Info 504 or Injection-Date. 506 3. It SHOULD reject any article whose Date header field is more 507 than 24 hours into the future (and MAY use a margin less than 24 508 hours). It SHOULD reject any article whose Date header appears 509 to be stale (more than 72 hours into the past, for example, or 510 too old to still be recorded in the database of a relaying agent 511 the injecting agent will be using) since not all news servers 512 support Injection-Date. 514 4. It SHOULD reject any proto-article whose Newsgroups header field 515 does not contain at least one for a valid 516 group, or containing a reserved for specific 517 purposes by Section 3.1.4 of [USEFOR] unless that specific 518 purpose or local agreement applies to the proto-article being 519 processed. Crossposting to unknown newsgroups is not precluded 520 provided that at least one of the newsgroups in the Newsgroups 521 header is valid. 523 5. The Message-ID and Date header fields with appropriate contents 524 MUST be added when not present in the proto-article. 526 6. The injecting agent MUST NOT alter the body of the article in 527 any way (including any change of Content-Transfer-Encoding). It 528 MAY add other header fields not already provided by the poster, 529 but injecting agents are encouraged to use the Injection-Info 530 header for such information and to minimize the addition of 531 other headers. It SHOULD NOT alter, delete, or reorder any 532 existing header field except the Path header. 534 7. If the Newsgroups header contains one or more moderated groups 535 and the proto-article does not contain an Approved header field, 536 the injecting agent SHOULD forward it to a moderator as 537 specified in Section 3.4.1. If the article cannot be forwarded 538 to a moderator for some reason, it MUST be rejected. This 539 forwarding MUST be done after adding the Message-ID and Date 540 headers if required, and before adding the Injection-Info and 541 Injection-Date headers. 543 8. Otherwise, a Path header field with a MUST be added 544 if not already present. 546 9. The injecting agent SHOULD then prepend the of 547 the injecting agent followed by "!.POSTED", optionally "." and 548 the FQDN or IP address of the source, and a further "!" to the 549 content of the Path header field. If the injecting agent does 550 not support the use of , it MUST instead prepend 551 its followed by "!"; one or the other of these 552 mechanisms MUST be used. 554 10. The relaying agent MAY fold the Path header field by inserting 555 FWS immediately after the it added. 557 11. An Injection-Info header field SHOULD be added identifying the 558 source of the article and possibly other trace information as 559 described in Section 3.2.8 of [USEFOR]. 561 12. The injecting agent MUST then add an Injection-Date header field 562 containing the current date and time. 564 13. Finally, the injecting agent forwards the article to one or more 565 relaying agents, and the injection process is complete. 567 3.4.1. Forwarding Messages to a Moderator 569 An injecting agent MUST forward the proto-article to the moderator of 570 the leftmost moderated group listed in the Newsgroups header field, 571 customarily via email. There are two standard ways in which it may 572 do this: 574 1. The complete proto-article is encapsulated, header fields and 575 all, within the email. This SHOULD be done by creating an email 576 message with a Content-Type of application/news-transmission with 577 the usage parameter set to "moderate". The body SHOULD NOT 578 contain any content other than the message. This method has the 579 advantage of removing any possible conflict between Netnews and 580 email header fields and any changes to those fields during 581 transport through email. 583 2. The proto-article is sent as an email with the addition of any 584 header fields (such as a To header field) required for an email. 585 The existing Message-ID header field SHOULD be retained. 587 Although both of these methods have been used in the past and the 588 first has clear technical advantages, the second is in more common 589 use and many moderators are not prepared to deal with messages in the 590 first format. Accordingly, the first method SHOULD NOT be used 591 unless the moderator to which it is being forwarded is known to be 592 able to handle this method. 594 NOTE: Deriving the email address of the moderator of a group is 595 outside the scope of this document. It is worth mentioning, 596 however, that a common method is to use a forwarding service that 597 handles submissions for many moderated groups. For maximum 598 compatibility with existing news servers, such forwarding services 599 generally form the submission address for a moderated group by 600 replacing each "." in the with "-" and then using 601 that value as the of a formed by appending 602 a set domain. 604 Forwarding proto-articles to moderators via email is the most general 605 method and most common in large Netnews networks such as Usenet, but 606 any means of forwarding the article that preserves it without 607 injecting it MAY be used. For example, if the injecting agent has 608 access to a database used by the moderator to store proto-articles 609 awaiting processing, it may place the proto-article directly into 610 that database. Such methods may be more appropriate for smaller 611 Netnews networks. 613 3.5. Duties of a Relaying Agent 615 A relaying agent accepts injected articles from injecting and other 616 relaying agents and passes them on to relaying or serving agents. To 617 avoid bypass of injecting agent policies and forgery of Path and 618 Injector-Info headers, relaying agents SHOULD accept articles only 619 from trusted agents. 621 An article SHOULD NOT be relayed unless the sending agent has been 622 configured to supply and the receiving agent to receive at least one 623 of the s in its Newsgroups header field and at least 624 one of the s in its Distribution header field (if 625 present). Exceptionally, control messages creating new newsgroups 626 (newgroup control messages) SHOULD be relayed if the sending agent 627 has been configured to supply and the receiving agent to receive the 628 newsgroup affected by the control message, even if that newsgroup 629 does not currently exist and even if the control message does not 630 contain that group in its Newsgroups header field. 632 In order to avoid unnecessary relaying attempts, an article SHOULD 633 NOT be relayed if the of the receiving agent (or some 634 known alias thereof) appears as a (excluding within 635 the or following a "POSTED" ) in its Path 636 header field. 638 A relaying agent processes an article as follows: 640 1. It MUST reject any article without a Newsgroups header field or 641 Message-ID header field, or without either an Injection-Date or 642 Date header field. 644 2. It MUST reject any article that has already been successfully 645 sent to it, based on the Message-ID header field of the article. 646 To satisfy this requirement, a relaying agent normally keeps a 647 database of message identifiers it has already accepted. 649 3. It MUST examine the Injection-Date header field or, if absent, 650 the Date header field, and reject the article if that date 651 predates the earliest articles of which it keeps record or if 652 that date is more than 24 hours into the future. It MAY reject 653 articles with dates in the future with a smaller margin than 24 654 hours. 656 4. It SHOULD reject any article that does not include all the 657 mandatory header fields. It MAY reject any article that 658 contains header fields that do not have valid contents. 660 5. It SHOULD reject any article that matches an already-received 661 cancel control message or the contents of the Supersedes header 662 field of an accepted article, provided that the relaying agent 663 chose (on the basis of local site policy) to honor that cancel 664 control message or Supersedes header field. 666 6. It MAY reject any article without an Approved header field 667 posted to a newsgroup known to be moderated. This practice is 668 strongly encouraged but the information necessary to do so is 669 not required to be maintained by a relaying agent. 671 7. If the relaying agent is processing an article from an injecting 672 agent that is part of the same news server, it MAY leave the 673 Path header field unmodified. 675 Otherwise, it SHOULD compare the expected of the 676 source of the article with the leftmost of the 677 Path header field's content. If those identities match, it 678 SHOULD then prepend "!!" to that content. If those identities 679 do not match, it SHOULD instead prepend "!.MISMATCH.", the true 680 established of the source or its IP address, and 681 a further "!". If the relaying agent is not able or willing to 682 verify the path identity of the source of the article, it MUST 683 prepend "!" to the Path header field's content, optionally 684 preceded by "!.SEEN." and the FQDN, IP address, or expected 685 of the source. Regardless of which method it 686 used, the relaying agent MUST then prepend its own to the Path header field content. 689 8. If it added a , the relaying agent MAY fold the 690 Path header field by inserting FWS immediately after the final 691 (rightmost) it added. 693 9. It MAY delete any Xref header field present and MAY add a new 694 Xref header field with any valid content. The Xref header field 695 is not used by relaying agents, but relaying agents that are 696 also serving agents may generate Xref header fields for their 697 own internal purposes. 699 10. Finally, it passes the article on to other relaying and serving 700 agents to which it is configured to send articles. 702 Relaying agents SHOULD, where possible in the underlying transport, 703 inform the agent that passed the article to the relaying agent if the 704 article was rejected. Relaying agents MUST NOT inform any other 705 external entity of the rejection of an article unless that external 706 entity has explicitly requested that it be informed of such errors. 708 Relaying agents MUST NOT alter, delete, or rearrange any part of an 709 article except for the Path and Xref header fields. They MUST NOT 710 modify the body of articles in any way. If an article is not 711 acceptable as-is, the article MUST be rejected rather than modified. 713 3.5.1. Path Header Field Example 715 Here is an example of a Path header field created following the rules 716 for injecting and relaying agents. 718 Path: foo.isp.example!.SEEN.isp.example!!foo-news 719 !.MISMATCH.2001:DB:0:0:8:800:200C:417A!bar.isp.example 720 !!old.site.example!barbaz!!baz.isp.example 721 !.POSTED.dialup123.baz.isp.example!not-for-mail 723 This article was injected by baz.isp.example as indicated by the 724 "POSTED". The injector has recorded that it received 725 the article from dialup123.baz.isp.example. "not-for-mail is a common 726 . 728 The article was relayed to the relaying agent known, at least to 729 old.site.example, as "barbaz". 731 barbaz relayed it to old.site.example, which does not support and therefore used the old "!" delimiter. This indicates 733 that the identity of "barbaz" was not verified and may have been 734 forged. 736 old.site.example relayed it to a news server using the of bar.isp.example and claiming (by using the "!!" ) to have verified that it came from old.site.example. 740 bar.isp.example relayed it to foo-news which, not being convinced 741 that it truly came from bar.isp.example, inserted the 742 "MISMATCH" and then stated that it received the article from the IPv6 743 address [2001:DB8:0:0:8:800:200C:417A]. (This is not to say that 744 bar.isp.example was not a correct for that source but 745 simply that that identity did not match the expectations of foo-news. 747 foo-news then passed the article to foo.isp.example, which declined 748 to validate its and instead appended the "SEEN" to indicate it knows the source of the article as 750 isp.example. This may be either an expected or the 751 FQDN of the system from which it received the article. Presumably 752 foo.isp.example is a serving agent that then delivered the article to 753 a reading agent. 755 baz.isp.example, bar.isp.example, and foo-news folded the Path header 756 field. 758 3.6. Duties of a Serving Agent 760 A serving agent accepts articles from a relaying agent or injecting 761 agent, stores it, and makes it available to reading agents. Articles 762 are normally indexed by newsgroup and (Section 763 3.2.14 of [USEFOR]), usually in the form of a decimal number. 765 If the serving agent stores articles by newsgroup, control messages 766 SHOULD NOT be stored in the newsgroups listed in the control 767 message's Newsgroups header field. Instead, they SHOULD be stored in 768 a newsgroup in the hierarchy "control", which is reserved for this 769 purpose. Conventionally, control messages are stored in newsgroups 770 named for the type of control message (such as "control.cancel" for 771 cancel control messages). 773 A serving agent MUST have available a list (possibly empty) of 774 moderated groups for which it accepts articles so that it can reject 775 unapproved articles posted to moderated groups. Frequently a serving 776 agent is deployed in combination with an injecting agent and can use 777 the same list as the injecting agent. 779 A serving agent processes articles as follows: 781 1. It MUST reject any article that does not include all the 782 mandatory header fields or any article which contains header 783 fields that do not have valid contents. 785 2. It MUST examine the Injection-Date header field or, if absent, 786 the Date header field, and reject the article if that date 787 predates the earliest articles of which it keeps record or if 788 that date is more than 24 hours into the future. It MAY reject 789 articles with dates in the future with a smaller margin than 24 790 hours. 792 3. It SHOULD reject any article that has already been successfully 793 sent to it or that matches an already-received and honored cancel 794 message or Supersedes header field following the same rules as a 795 relaying agent (Section 3.5). 797 4. It MUST reject any article without an Approved header field 798 posted to any newsgroup listed as moderated. 800 5. It MUST modify the Path header field following the same rules as 801 for a relaying agent (Section 3.5). 803 6. It MUST (except when specially configured to preserve the 804 s set by the sending site) remove any Xref 805 header field from each article. It then MAY (and usually will) 806 generate a fresh Xref header field. 808 7. Finally, it stores the article and makes it available for reading 809 agents. 811 Serving agents MUST NOT create new newsgroups simply because an 812 unrecognized occurs in a Newsgroups header field. 813 Newsgroups are normally created via control messages (Section 5.2.1). 815 Serving agents MUST NOT alter, delete, or rearrange any part of an 816 article except for the Path and Xref header fields. They MUST NOT 817 modify the body of the articles in any way. If an article is not 818 acceptable as-is, the article MUST be rejected rather than modified. 820 3.7. Duties of a Reading Agent 822 Since a reading agent is only a passive participant in a Netnews 823 network, there are no specific protocol requirements placed on it. 824 See [USEAGE] for best-practice recommendations. 826 3.8. Duties of a Moderator 828 A moderator receives news articles, customarily by email, decides 829 whether to approve them and, if so, either passes them to an 830 injecting agent or forwards them to further moderators. 832 Articles are normally received by the moderator in email either 833 encapsulated as an object of Content-Type application/ 834 news-transmission (or possibly encapsulated but without an explicit 835 Content-Type header field), or else directly as an email already 836 containing all the header fields appropriate for a Netnews article 837 (see Section 3.4.1). Moderators who may receive articles via email 838 SHOULD be prepared to accept articles in either format. 840 Moderators are entirely free within the Netnews protocol to accept or 841 reject messages based on any criteria and to make arbitrary 842 modifications to articles (both header fields and body). See 843 [USEAGE] for best-practice recommendations. Moderators need to be 844 aware that modifications made to articles may invalidate signatures 845 created by the poster or previous moderators. 847 Moderators process articles as follows: 849 1. They decide whether to approve or reject an article, and if 850 approved, make whatever modifications to the article (if any) 851 they choose. If the article is rejected, it is normally rejected 852 for all newsgroups to which it was posted and nothing further is 853 done. If it is approved, the moderator proceeds with the 854 following steps. 856 2. If the Newsgroups header field contains further moderated 857 newsgroups for which approval has not already been given, they 858 may either reach some agreement with the other moderators on the 859 disposition of the article or, more generally, add an indication 860 (identifying both the moderator and the name of the newsgroup) 861 that they approve the article and then forward it to the 862 moderator of the leftmost unapproved newsgroup. This forwarding 863 SHOULD be done following the procedure in Section 3.4.1 and MAY 864 be done by rotating the s in the Newsgroups 865 header field so that the leftmost unapproved newsgroup is is the 866 leftmost moderated newsgroup in that field and then posting it, 867 letting the injecting agent do the forwarding. However, if using 868 this mechanism, they MUST first ensure that the article contains 869 no Approved header field. 871 3. If the Newsgroups header field contains no further unapproved 872 moderated groups, they add an Approved header field (see Section 873 3.2.1 of [USEFOR]) identifying the moderator and, insofar as is 874 possible, all the other moderators who have approved the article. 875 The moderator who takes this step assumes responsibility for 876 ensuring that the article was approved by the moderators of all 877 moderated newsgroups to which it was posted. 879 4. Moderators are encouraged to retain the Message-ID header field 880 if it is valid, and also retain the Date header field unless it 881 appears to be stale (72 hours or more in the past) for reasons 882 understood by the moderator (such as delays in the moderation 883 process) in which case they MAY substitute the current date. Any 884 Injection-Date, Injection-Info, or Xref header fields already 885 present (though there should be none) MUST be removed. 887 5. Any Path header field MUST either be removed or truncated to only 888 those entries following its "POSTED" , if any. 890 6. The moderator then passes the article to an injecting agent, 891 having first observed all the duties of a posting agent. 893 3.9. Duties of a Gateway 895 A gateway transforms an article into the native message format of 896 another medium, or translates the messages of another medium into 897 news articles, or transforms articles into proto-articles for 898 injection into a separate Netnews network. Encapsulation of a news 899 article into a message of MIME type application/news-transmission, or 900 the subsequent undoing of that encapsulation, is not gatewaying, 901 since it involves no transformation of the article. 903 There are two basic types of gateway, the outgoing gateway that 904 transforms a news article into a different type of message, and the 905 incoming gateway that transforms a message from another network into 906 a news proto-article and injects it into a Netnews network. These 907 are handled separately below. 909 Transformation of an article into another medium stands a very high 910 chance of discarding or interfering with the protection inherent in 911 the news system against duplicate articles. The most common problem 912 caused by gateways is loops that repeatedly reinject previously 913 posted articles. To prevent this, a gateway MUST take precautions 914 against loops, as detailed below. 916 The transformations applied to the message SHOULD be as minimal as 917 possible while still accomplishing the gatewaying. Every change made 918 by a gateway potentially breaks a property of one of the media or 919 loses information, and therefore only those transformations made 920 necessary by the differences between the media should be applied. 922 If bidirectional gatewaying (both an incoming and an outgoing 923 gateway) is being set up between Netnews and some other medium, the 924 incoming and outgoing gateways SHOULD be coordinated to avoid 925 unintended reinjection of gated articles. Circular gatewaying 926 (gatewaying a message into another medium and then back into Netnews) 927 SHOULD NOT be done; encapsulation of the article SHOULD be used 928 instead where this is necessary. 930 Safe bidirectional gatewaying between a mailing list and a newsgroup 931 is far easier if the newsgroup is moderated. Posts to the moderated 932 group and submissions to the mailing list can then go through a 933 single point that does the necessary gatewaying and then sends the 934 message out to both the newsgroup and the mailing list at the same 935 time, eliminating most of the possibility of loops. Bidirectional 936 gatewaying between a mailing list and an unmoderated newsgroup, in 937 contrast, is difficult to do correctly and is far more fragile. 938 Newsgroups intended to be bidirectionally gated to a mailing list 939 SHOULD therefore be moderated where possible, even if the moderator 940 is a simple gateway and injecting agent that correctly handles 941 crossposting to other moderated groups and otherwise passes all 942 traffic. 944 3.9.1. Duties of an Outgoing Gateway 946 From the perspective of Netnews, an outgoing gateway is just a 947 special type of reading agent. The exact nature of what the outgoing 948 gateway will need to do to articles depends on the medium to which 949 the articles are being gated. The operation of the outgoing gateway 950 is subject to additional constraints due to the possibility of one or 951 more corresponding incoming gateways back from that medium to 952 Netnews, since this raises the danger of loops. 954 The following practices are encouraged for all outgoing gateways, 955 regardless of whether there is known to be a related incoming 956 gateway, both as precautionary measures and as a guideline to quality 957 of implementation: 959 1. The message identifier of the news article should be preserved if 960 at all possible, preferably as or within the corresponding unique 961 identifier of the other medium, but if not at least as a comment 962 in the message. This helps greatly with preventing loops. 964 2. The Date and Injection-Date of the news article should also be 965 preserved if possible, for similar reasons. 967 3. The message should be tagged in some way so as to prevent its 968 reinjection into Netnews. This may be impossible to do without 969 knowledge of potential incoming gateways, but it is better to try 970 to provide some indication even if not successful; at the least, 971 a human-readable indication that the article should not be gated 972 back to Netnews can help locate a human problem. 974 4. Netnews control messages should not be gated to another medium 975 unless they would somehow be meaningful in that medium. 977 3.9.2. Duties of an Incoming Gateway 979 The incoming gateway has the responsibility of ensuring that all of 980 the requirements of this protocol are met by the articles that it 981 forms. In addition to its special duties as a gateway, it bears all 982 of the duties and responsibilities of a posting agent as well, and 983 additionally has the same responsibility of a relaying agent to 984 reject articles that it has already gatewayed. 986 An incoming gateway MUST NOT gate the same message twice. It may not 987 be possible to ensure this in the face of mangling or modification of 988 the message, but at the very least a gateway, when given a copy of a 989 message it has already gated identical except for trace header fields 990 (like Received in Email or Path in Netnews) MUST NOT gate the message 991 again. An incoming gateway SHOULD take precautions against having 992 this rule bypassed by modifications of the message that can be 993 anticipated. 995 News articles prepared by gateways MUST be valid news proto-articles 996 (see Section 3.3.1). This often requires the gateway to synthesize a 997 conforming article from non-conforming input. The gateway MUST then 998 pass the article to an injecting agent, not directly to a relaying 999 agent. 1001 Incoming gateways MUST NOT pass control messages (articles containing 1002 a Control or Supersedes header field) without removing or renaming 1003 that header field. Gateways MAY, however, generate cancel control 1004 messages for messages they have gatewayed. If a gateway receives a 1005 message that it can determine is a valid equivalent of a cancel 1006 control message in the medium it is gatewaying, it SHOULD discard 1007 that message without gatewaying it, generate a corresponding cancel 1008 control message of its own, and inject that cancel control message. 1010 NOTE: It is not unheard of for mail-to-news gateways to be used to 1011 post control messages, but encapsulation should be used for these 1012 cases instead. Gateways by their very nature are particularly 1013 prone to loops. Spews of normal articles are bad enough; spews of 1014 control messages with special significance to the news system, 1015 possibly resulting in high processing load or even email sent for 1016 every message received, are catastrophic. It is far preferable to 1017 construct a system specifically for posting control messages that 1018 can do appropriate consistency checks and authentication of the 1019 originator of the message. 1021 If there is a message identifier that fills a role similar to that of 1022 the Message-ID header field in news, it SHOULD be used in the 1023 formation of the message identifier of the news article, perhaps with 1024 transformations required to meet the uniqueness requirement of 1025 Netnews and with the removal of any comments so as to comply with the 1026 syntax in Section 3.1.3 of [USEFOR]. Such transformations SHOULD be 1027 designed so that two messages with the same identifier generate the 1028 same Message-ID header field. 1030 NOTE: Message identifiers play a central role in the prevention of 1031 duplicates, and their correct use by gateways will do much to 1032 prevent loops. Netnews does, however, require that message 1033 identifiers be unique, and therefore message identifiers from 1034 other media may not be suitable for use without modification. A 1035 balance must be struck by the gateway between preserving 1036 information used to prevent loops and generating unique message 1037 identifiers. 1039 Exceptionally, if there are multiple incoming gateways for a 1040 particular set of messages, each to a different newsgroup(s), each 1041 one SHOULD generate a message identifier unique to that gateway. 1042 Each incoming gateway nonetheless MUST ensure that it does not gate 1043 the same message twice. 1045 NOTE: Consider the example of two gateways of a given mailing list 1046 into two separate Usenet newsgroups, both of which preserve the 1047 email message identifier. Each newsgroup may then receive a 1048 portion of the messages (different sites seeing different 1049 portions). In these cases, where there is no one "official" 1050 gateway, some other method of generating message identifiers has 1051 to be used to avoid collisions. It would obviously be preferable 1052 for there to be only one gateway which crossposts, but this may 1053 not be possible to coordinate. 1055 If no date information is available, the gateway MAY supply a Date 1056 header field with the gateway's current date. If only partial 1057 information is available (such as date but not time), this SHOULD be 1058 fleshed out to a full Date by adding default values rather than 1059 discarding this information. Only in very exceptional circumstances 1060 should Date information be discarded, as it plays an important role 1061 in preventing reinjection of old messages. 1063 An incoming gateway MUST add a Sender header field to the news 1064 article it forms containing the of the administrator of the 1065 gateway. Problems with the gateway may be reported to this 1066 . The portion of this SHOULD 1067 indicate that the entity responsible for injection of the message is 1068 a gateway. If the original message already had a Sender header 1069 field, it SHOULD be renamed so that its contents can be preserved. 1071 3.9.3. Gateway Example 1073 To illustrate the type of precautions that should be taken against 1074 loops, here is an example of the measures taken by one particular 1075 combination of mail-to-news and news-to-mail gateways designed to 1076 handle bidirectional gatewaying between mailing lists and unmoderated 1077 groups: 1079 1. The news-to-mail gateway preserves the message identifier of the 1080 news article in the generated email message. The mail-to-news 1081 gateway likewise preserves the email message identifier provided 1082 that it is syntactically valid for Netnews. This allows the news 1083 system's built-in suppression of duplicates to serve as the first 1084 line of defense against loops. 1086 2. The news-to-mail gateway adds an X-Gateway header field to all 1087 messages it generates. The mail-to-news gateway discards any 1088 incoming messages containing this header field. This is robust 1089 against mailing list managers that replace the message 1090 identifier, and against any number of email hops, provided that 1091 the other message header fields are preserved. 1093 3. The mail-to-news gateway prepends the host name from which it 1094 received the email message to the content of the Path header 1095 field. The news-to-mail gateway refuses to gateway any message 1096 that contains the list server name in its Path header field 1097 (including in the tail section). This is robust against any 1098 amount of munging of the message header fields by the mailing 1099 list, provided that the email only goes through one hop. 1101 4. The mail-to-news gateway is designed never to generate bounces to 1102 the envelope sender. Instead, articles that are rejected by the 1103 news server (for reasons not warranting silent discarding of the 1104 message) result in a bounce message sent to an errors address 1105 known not to forward to any mailing lists, so that they can be 1106 handled by the news administrators. 1108 These precautions have proven effective in practice at preventing 1109 loops for this particular application (bidirectional gatewaying 1110 between mailing lists and locally distributed newsgroups where both 1111 gateways can be designed together). General gatewaying to world-wide 1112 newsgroups poses additional difficulties; one must be very wary of 1113 strange configurations, such as a newsgroup gated to a mailing list 1114 which is in turn gated to a different newsgroup. 1116 4. Media Types 1118 This document defines several media types, which shall be registered 1119 with IANA as provided for in [RFC4288]. 1121 The media type message/news, as previously registered with IANA, is 1122 hereby declared obsolete. It was never widely implemented, and its 1123 default treatment as application/octet-stream by agents that did not 1124 recognize it was counter-productive. The media type message/rfc822 1125 SHOULD be used in its place. 1127 4.1. application/news-transmission 1129 The media type application/news-transmission is intended for the 1130 encapsulation of complete news articles where the intention is that 1131 the recipient should then inject them into Netnews. This application 1132 type provides one of the methods for mailing articles to moderators 1133 (see Section 3.4.1) and may be used to convey messages to an 1134 injecting agent. This encapsulation removes the need to transform an 1135 email message into a Netnews proto-article and provides a way to send 1136 a Netnews article using MIME through a transport medium that does not 1137 support 8bit data. 1139 The MIME media type definition of application/news-transmission is: 1141 MIME type name: application 1142 MIME subtype name: news-transmission 1143 Required parameters: none 1144 Optional parameters: One and only one of "usage=moderate", 1145 "usage=inject", or "usage=relay". 1146 Encoding considerations: A transfer-encoding different from that of 1147 the article transmitted MAY be supplied to 1148 ensure correct transmission over some 7bit 1149 transport medium. 1150 Security considerations: A news article may be a control message, 1151 which if processed could have effects on 1152 the recipient host's system beyond just 1153 storage of the article. 1154 Published specification: This specification. 1155 Body part: A complete proto-article ready for 1156 injection into Netnews or an article being 1157 relayed to another agent 1159 usage=moderate indicates the article is intended for a moderator, 1160 usage=inject for an injecting agent, and usage=relay for a relaying 1161 agent. The entity receiving the article may only implement one type 1162 of agent, in which case the parameter MAY be omitted. 1164 4.2. application/news-groupinfo 1166 The application/news-groupinfo media type is used in conjunction with 1167 the newgroup control message (see Section 5.2.1). Its body part 1168 contains brief information about a newsgroup: the newsgroup name, its 1169 description, and its moderation status. 1171 The MIME media type definition of application/news-transmission is: 1173 MIME type name: application 1174 MIME subtype name: news-groupinfo 1175 Required parameters: none 1176 Optional parameters: charset, which MUST be a charset registered 1177 for use with MIME text types and has the 1178 same syntax as the parameter defined for 1179 text/plain [RFC2046]. Specifies the 1180 charset of the body part. If not given, 1181 the charset defaults to US-ASCII [ASCII]. 1182 Disposition: by default, inline 1183 Encoding considerations: 7bit or 8bit MUST be used to maintain 1184 compatibility. 1185 Security considerations: None. 1186 Published specification: This specification. 1188 The content of the application/news-groupinfo body part is defined 1189 as: 1191 groupinfo-body = [ newsgroups-tag CRLF ] 1192 newsgroups-line CRLF 1193 newsgroups-tag = %x46.6F.72 SP %x79.6F.75.72 SP 1194 %x6E.65.77.73.67.72.6F.75.70.73 SP 1195 %x66.69.6C.65.3A 1196 ; case sensitive 1197 ; "For your newsgroups file:" 1198 newsgroups-line = newsgroup-name 1199 [ 1*HTAB newsgroup-description ] 1200 [ 1*WSP moderation-flag ] 1201 newsgroup-description 1202 = utext *( *WSP utext ) 1203 moderation-flag = %x28.4D.6F.64.65.72.61.74.65.64.29 1204 ; case sensitive "(Moderated)" 1206 This unusual format is backward-compatible with the scanning of the 1207 body of newgroup control messages for descriptions done by Netnews 1208 implementations that predate this specification. Although optional, 1209 the SHOULD be included for backward compatibility. 1211 The MUST NOT contain any occurrence of the 1212 string "(Moderated)" within it. Moderated newsgroups MUST be marked 1213 by appending the case sensitive text " (Moderated)" at the end. 1215 While a charset parameter is defined for this media type, most 1216 existing software does not correctly handle descriptions in a variety 1217 of charsets. Using a charset of US-ASCII where possible is therefore 1218 RECOMMENDED. 1220 4.3. application/news-checkgroups 1222 The application/news-checkgroups media type contains a list of 1223 newsgroups within a hierarchy or hierarchies, including their 1224 descriptions and moderation status. It is primarily for use with the 1225 checkgroups control message (see Section 5.2.3). 1227 The MIME media type definition of application/news-checkgroups is: 1229 MIME type name: application 1230 MIME subtype name: news-checkgroups 1231 Required parameters: none 1232 Optional parameters: charset, which MUST be a charset registered 1233 for use with MIME text types and has the 1234 same syntax as the parameter defined for 1235 text/plain [RFC2046]. Specifies the 1236 charset of the body part. If not given, 1237 the charset defaults to US-ASCII [ASCII]. 1238 Disposition: by default, inline 1239 Encoding considerations: 7bit or 8bit MUST be used to maintain 1240 compatibility. 1241 Security considerations: This media type provides only a means for 1242 conveying a list of newsgroups and does not 1243 provide any information indicating whether 1244 the sender is authorized to state which 1245 newsgroups should exist within a hierarchy. 1246 Such authorization must be accomplished by 1247 other means. 1248 Published specification: This specification. 1250 The content of the application/news-groupinfo body part is defined 1251 as: 1253 checkgroups-body = *( valid-group CRLF ) 1254 valid-group = newsgroups-line ; see 4.2 1256 The same restrictions on apply for this media 1257 type as for application/news-groupinfo. 1259 One application/news-checkgroups message may contain information for 1260 one or more hierarchies and is considered complete for any hierarchy 1261 for which it contains a . In other words, an 1262 application/news-checkgroups body part consisting of: 1264 example.moderated A moderated newsgroup (Moderated) 1265 example.test An unmoderated test group 1267 is a statement that the example.* hierarchy contains two newsgroups, 1268 example.moderated and example.test, and no others. This media type 1269 therefore MUST NOT be used for conveying partial information about a 1270 hierarchy; if a group from a given hierarchy is present, all groups 1271 that exist in that hierarchy MUST be listed. 1273 5. Control Messages 1275 A control message is an article which contains a Control header field 1276 and thereby indicates that some action should be taken by an agent 1277 other than distribution and display. Any article containing a 1278 Control header field (defined in Section 3.2.3 of [USEFOR]) is a 1279 control message. Additionally, the action of an article containing a 1280 Supersedes header field is described here; while such an article is 1281 not a control message, it specifies an action similar to the cancel 1282 control message. 1284 The of a Control header field comprises a , 1285 which indicates the action to be taken, and one or more 1286 values, which supply the details. For some control messages, the 1287 body of the article is also significant. Each recognized (the 1288 control message type) is described in a separate section below. 1289 Agents MAY accept other control message types than those specified 1290 below, and MUST either ignore or reject control messages with 1291 unrecognized types. Syntactic definitions of valid values 1292 and restrictions on control message bodies are given in the section 1293 for each control message type. 1295 Contrary to [RFC1036], the presence of a Subject header field 1296 starting with the string "cmsg " MUST NOT cause an article to 1297 interpreted as a control message. Agents MAY reject an article with 1298 no Control header field and such a Subject header field as ambiguous. 1299 Likewise, the presence of a ending in ".ctl" in the 1300 Newsgroups header field or the presence of an Also-Control header 1301 field MUST NOT cause the article to be interpreted as a control 1302 message. 1304 5.1. Authentication and Authorization 1306 Control messages specify actions above and beyond the normal 1307 processing of an article and are therefore potential vectors of abuse 1308 and unauthorized action. There is, at present, no standardized means 1309 of authenticating the sender of a control message or verifying that 1310 the contents of a control message were sent by the claimed sender. 1311 There are, however, some unstandardized authentication mechanisms in 1312 common use. 1314 Agents acting on control messages SHOULD take steps to authenticate 1315 control messages before acting on them, as determined by local 1316 authorization policy. Whether this is done via the use of an 1317 unstandardized authentication protocol, by comparison with 1318 information obtained through another protocol, by human review, or by 1319 some other means is left unspecified by this document. Further 1320 extensions or revisions of this protocol are expected to standardize 1321 a digital signature mechanism. 1323 Agents are expected to have their own local authorization policies 1324 for which control messages will be honored. No Netnews agent is ever 1325 required to act on any control message. The following descriptions 1326 specify the actions that a control message requests, but an agent MAY 1327 always decline to act on any given control message. 1329 5.2. Group Control Messages 1331 A group control message is any control message type that requests 1332 some update to the list of newsgroups known to a news server. The 1333 standard group control message types are "newgroup", "rmgroup", and 1334 "checkgroups". 1336 Before honoring any group control message, an agent MUST check the 1337 newsgroup or newsgroups affected by that control message and decline 1338 to create any newsgroups not in conformance with the restrictions in 1339 Section 3.1.4 of [USEFOR]. 1341 All of the group control messages MUST have an Approved header field 1342 (Section 3.2.1 of [USEFOR]). Group control messages without an 1343 Approved header field SHOULD NOT be honored. 1345 5.2.1. The newgroup Control Message 1347 The newgroup control message requests the specified group be created 1348 or, if already existing, have its moderation status or description 1349 changed. The syntax of its Control header field is: 1351 control-command =/ Newgroup-command 1352 Newgroup-command = "newgroup" Newgroup-arguments 1353 Newgroup-arguments = 1*WSP newsgroup-name [ 1*WSP newgroup-flag ] 1354 newgroup-flag = "moderated" 1356 If the request is honored, the moderation status of the group SHOULD 1357 be set in accordance with the presence or absence of the "moderated". "moderated" is the only flag defined by this 1359 protocol. Other flags MAY be defined by extensions to this protocol 1360 and accepted by agents. If an agent does not recognize the 1361 of a newgroup control message, it SHOULD ignore that 1362 control message. 1364 The body of a newgroup message SHOULD contain an entity of type 1365 application/news-groupinfo specifying the description of the 1366 newsgroup, either as the entire body or as an entity within a 1367 multipart/related object [RFC2046]. If such an entity is present, 1368 the moderation status specified therein MUST match the moderation 1369 status specified by the . The body of a newgroup 1370 message MAY contain other entities (encapsulated in multipart/ 1371 related) that provide additional information about the newsgroup or 1372 the circumstances of the control message. 1374 In the absence of an application/news-groupinfo entity, a news server 1375 MAY search the body of the message for the line "For your newsgroups 1376 file:" and take the following line as a . Prior to 1377 the standardization of application/news-groupinfo, this was the 1378 convention for providing a newsgroup description. 1380 If the request is honored and contains a newsgroup description, and 1381 if the news server honoring it stores newsgroup descriptions, the 1382 stored newsgroup description SHOULD be updated to the description 1383 specified in the control message, even if no other property of the 1384 group has changed. 1386 5.2.1.1. newgroup Control Message Example 1388 A newgroup control message requesting creation of the moderated 1389 newsgroup example.admin.info. 1391 From: "example.* Administrator" 1392 Newsgroups: example.admin.info 1393 Date: 27 Feb 2002 12:50:22 +0200 1394 Subject: cmsg newgroup example.admin.info moderated 1395 Approved: admin@noc.example 1396 Control: newgroup example.admin.info moderated 1397 Message-ID: 1398 MIME-Version: 1.0 1399 Content-Type: multipart/mixed; boundary="nxtprt" 1400 Content-Transfer-Encoding: 8bit 1402 This is a MIME control message. 1403 --nxtprt 1404 Content-Type: application/news-groupinfo 1406 For your newsgroups file: 1407 example.admin.info About the example.* groups (Moderated) 1409 --nxtprt 1410 Content-Type: text/plain 1412 A moderated newsgroup for announcements about new newsgroups in 1413 the example.* hierarchy. 1415 --nxtprt-- 1417 5.2.2. The rmgroup Control Message 1419 The rmgroup control message requests the specified group be removed 1420 from a news server's list of valid groups. The syntax of its Control 1421 header field is: 1423 control-command =/ Rmgroup-command 1424 Rmgroup-command = "rmgroup" Rmgroup-arguments 1425 Rmgroup-arguments = 1*WSP newsgroup-name 1427 The body of the control message MAY contain anything, usually an 1428 explanatory text. 1430 5.2.3. The checkgroups Control Message 1432 The checkgroups control message contains a list of all the valid 1433 groups in a hierarchy with descriptions and moderation status. It 1434 requests a news server update its valid newsgroup list for that 1435 hierarchy to include the groups specified, remove any groups not 1436 specified, and update group descriptions to match those given in the 1437 checkgroups control message. The syntax of its Control header field 1438 is: 1440 control-command =/ Checkgroup-command 1441 Checkgroup-command = "checkgroups" Checkgroup-arguments 1442 Checkgroup-arguments= [ chkscope ] [ chksernr ] 1443 chkscope = 1*( FWS ["!"] newsgroup-name ) 1444 chksernr = FWS "#" 1*DIGIT 1446 A checkgroups message is interpreted as an exhaustive list of the 1447 valid groups in all hierarchies or sub-hierarchies with a prefix 1448 listed in the argument, excluding any sub-hierarchy where 1449 the argument is prefixed by "!". If no 1450 argument is given, it applies to all hierarchies for which group 1451 statements appear in the body of the message. Since much existing 1452 software does not honor the argument, the body of the 1453 checkgroups control message MUST NOT contain group statements for 1454 newsgroups outside the intended scope and SHOULD contain a correct 1455 newsgroup list even for sub-hierarchies excluded with "!" 1456 terms. News servers, however, MUST honor as specified 1457 here. 1459 The argument may be any positive integer. If present, it 1460 MUST increase with every change to the newsgroup list and MUST NOT 1461 ever decrease. If provided, news servers SHOULD remember the 1462 value of the previous checkgroups control message honored 1463 for a particular hierarchy or sub-hierarchy and decline to honor any 1464 subsequent checkgroups control message for the same hierarchy or sub- 1465 hierarchy with a smaller value. 1467 For example, the following Control header field 1469 Control: checkgroups de !de.alt #248 1471 indicates the body of the message will list every newsgroup in the 1472 de.* hierarchy, excepting the de.alt.* sub-hierarchy, and should not 1473 be honored if a checkgroups control message with a serial number 1474 greater than 248 was previously honored. 1476 The body of the message is an entity of type application/ 1477 news-checkgroups. It SHOULD be declared as such with appropriate 1478 MIME headers, but news servers SHOULD interpret checkgroups messages 1479 that lack the appropriate MIME headers as if the body were of type 1480 application/news-checkgroups for backward compatibility. 1482 5.3. The cancel Control Message 1484 The cancel control message requests that a target article be 1485 withdrawn from circulation and access. The syntax of its Control 1486 header field is: 1488 control-command =/ Cancel-command 1489 Cancel-command = "cancel" Cancel-arguments 1490 Cancel-arguments = FWS msg-id [FWS] 1492 The argument identifies the article to be cancelled by its message 1493 identifier. The body of the control message MAY contain anything, 1494 usually an explanatory text. 1496 A serving agent that elects to honor a cancel message SHOULD make the 1497 article unavailable to reading agents (perhaps by deleting it 1498 completely). If the cancel control message arrives before the 1499 article it targets, news servers choosing to honor it SHOULD remember 1500 the message identifier that was cancelled and reject the cancelled 1501 article when it arrives. 1503 Cancel control messages listing moderated newsgroups in their 1504 Newsgroups header field MUST contain an Approved header field like 1505 any other article in a moderated newsgroup. This means that cancels 1506 posted to a moderated newsgroup will normally be sent to the 1507 moderator first for approval. Outside of moderated newsgroups, 1508 cancel messages are not required to contain an Approved header field. 1510 Contrary to [RFC1036], cancel control messages are not required to 1511 contain From and Sender header fields matching the target message. 1512 This requirement only encouraged cancel issuers to conceal their 1513 identity and provided no security. 1515 5.4. The Supersedes Header Field 1517 The presence of a Supersedes header field in an article requests that 1518 the message identifier given in that header field be withdrawn in 1519 exactly the same manner as if it were the target of a cancel control 1520 message. Accordingly, news servers SHOULD use the same 1521 authentication and authorization checks for deciding whether to honor 1522 a Supersedes header field as they use for cancel control messages. 1523 If the Supersedes header field is honored, the news server SHOULD 1524 take the same actions as it would take when honoring a cancel control 1525 message for the given target article. 1527 5.5. The ihave and sendme Control Messages 1529 The ihave and sendme control messages implement a predecessor of the 1530 NNTP [RFC3977] protocol. They are largely obsolete on the Internet 1531 but still see use in conjunction with some transport protocols such 1532 as UUCP. News servers are not required to support them. 1534 ihave and sendme control messages share similar syntax for their 1535 Control header fields and bodies: 1537 control-command =/ Ihave-command 1538 Ihave-command = "ihave" [Ihave-argument] 1539 Ihave-argument = 1*WSP *( msg-id 1*WSP ) [relayer-name] 1540 control-command =/ Sendme-command 1541 Sendme-command = "sendme" Sendme-argument 1542 Sendme-argument = Ihave-argument 1543 relayer-name = path-identity ; see 3.1.5 of [USEFOR] 1544 ihave-body = *( msg-id CRLF ) 1545 sendme-body = ihave-body 1547 The body of the article consists of a list of s, one per 1548 line. The message identifiers SHOULD be put in the body of the 1549 article, not in the Control header field, but news servers MAY 1550 recognize and process message identifiers in the Control header field 1551 for backward compatibility. 1553 The ihave message states that the named relaying agent has received 1554 articles with the specified message identifiers, which may be of 1555 interest to the relaying agents receiving the ihave message. The 1556 sendme message requests that the agent receiving it send the articles 1557 having the specified message identifiers to the named relaying agent. 1558 If is not given, it is determined from the origin of 1559 the control message. 1561 Upon receipt of the sendme message (and a decision to honor it), the 1562 receiving agent sends the article or articles requested. The 1563 mechanism for this transmission is unspecified by this document and 1564 is arranged between the sites involved. 1566 These control messages are normally sent as point-to-point articles 1567 between two sites and not then sent on to other sites. Newsgroups 1568 beginning with "to." are reserved for such point-to-point 1569 communications. 1571 5.6. Obsolete Control Messages 1573 The following control message types are declared obsolete by this 1574 document and SHOULD NOT be sent or honored: 1576 sendsys 1577 version 1578 whogets 1579 senduuname 1581 6. Security Considerations 1583 Netnews is designed for broad dissemination of public messages and 1584 offers little in the way of security. What protection Netnews has 1585 against abuse and impersonation is provided primarily by the 1586 underlying transport layer. In large Netnews networks where news 1587 servers cannot be relied upon to enforce authentication and 1588 authorization requirements at the transport layer, articles may be 1589 trivially forged and widely read, and the identities of article 1590 senders and privacy of articles cannot be assured. 1592 See Section 5 of [USEFOR] for further security considerations related 1593 to the format of articles. 1595 6.1. Compromise of System Integrity 1597 Control messages pose a particular security concern since acting on 1598 unauthorized control messages may cause newsgroups to be removed, 1599 articles to be deleted, and unwanted newsgroups to be created. 1600 Administrators of news servers SHOULD therefore take steps to verify 1601 the authenticity of control messages as discussed in Section 5.1. 1602 Articles containing Supersedes header fields are effectively cancel 1603 control messages and SHOULD be subject to the same checks as 1604 discussed in Section 5.4. Currently, many sites are ignoring all 1605 cancel control messages and Supersedes header fields due to the 1606 difficulty of authenticating them and their widespread abuse. 1608 All agents should be aware that all article content, most notably 1609 including the content of the Control header field, is potentially 1610 untrusted and malicious. Articles may be constructed in 1611 syntactically invalid ways to attempt to overflow internal buffers, 1612 violate hidden assumptions, or exploit implementation weaknesses. 1613 For example, some news server implementations have been successfully 1614 attacked via inclusion of Unix shell code in the Control header 1615 field. All article contents, and particularly control message 1616 contents, SHOULD be handled with care and rigorously verified before 1617 any action is taken on the basis of the contents of the article. 1619 A malicious poster may add an Approved header field to bypass the 1620 moderation process of a moderated newsgroup. Injecting agents SHOULD 1621 verify that messages approved for a moderated newsgroup are being 1622 injected by the moderator using authentication information from the 1623 underlying transport or some other authentication mechanism arranged 1624 with the moderator. 1626 A malicious news server participating in a Netnews network may bypass 1627 checks performed by injecting agents, forge Path header fields and 1628 other trace information (such as Injection-Info header fields), and 1629 otherwise compromise the authorization requirements of a Netnews 1630 network. News servers SHOULD use the facilities of the underlying 1631 transport to authenticate their peers and reject articles from 1632 injecting and relaying agents that do not follow the requirements of 1633 this protocol or the Netnews network. 1635 6.2. Denial of Service 1637 The proper functioning of individual newsgroups can be disrupted by 1638 the excessive posting of unwanted articles; by the repeated posting 1639 of identical or near identical articles; by posting followups 1640 unrelated to their precursors or which quote their precursors in full 1641 with the addition of minimal extra material (especially if this 1642 process is iterated); by crossposting to, or requesting followups to, 1643 totally unrelated newsgroups; and by abusing control messages and the 1644 Supersedes header field to delete articles or newsgroups. 1646 Such articles intended to deny service, or other articles of an 1647 inflammatory nature, may also have their From or Reply-To addresses 1648 set to valid but incorrect email addresses, thus causing large 1649 volumes of email to descend on the true owners of those addresses. 1650 Users and agents should always be aware that identifying information 1651 in articles may be forged. 1653 A malicious poster may prevent an article from being seen at a 1654 particular site by including in the Path header field of the proto- 1655 article the of that site. Use of the 1656 "POSTED" by injecting agents to mark the point of injection can 1657 prevent this attack. 1659 Primary responsibility for preventing such attacks lies with 1660 injecting agents, which can apply authentication and authorization 1661 checks via the underlying transport and prevent those attempting 1662 denial of service attacks from posting messages. If specific 1663 injecting agents fail to live up to their responsibilities, they may 1664 be excluded from the Netnews network by configuring relaying agents 1665 to reject articles originating from them. 1667 A malicious complainer may submit a modified copy of an article (with 1668 an altered Injection-Info header field, for instance) to the 1669 administrator of an injecting agent in an attempt to discredit the 1670 author of that article and even to have his posting privileges 1671 removed. Administrators SHOULD therefore obtain a genuine copy of 1672 the article from their own serving agent before taking action in 1673 response to such a complaint. 1675 6.3. Leakage 1677 Articles which are intended to have restricted distribution are 1678 dependent on the goodwill of every site receiving them. Restrictions 1679 on dissemination and retention of articles may be requested via the 1680 Archive and Distribution header fields, but such requests cannot be 1681 enforced by the protocol. 1683 The flooding algorithm used by Netnews transports such as NNTP 1684 [RFC3977] is extremely good at finding any path by which articles can 1685 leave a subnet with supposedly restrictive boundaries, and 1686 substantial administrative effort is required to avoid this. 1687 Organizations wishing to control such leakage are advised to 1688 designate a small number of gateways to handle all news exchange with 1689 the outside world. 1691 The sendme control message Section 5.5, insofar as it is still used, 1692 can be used to request articles the requester should not have access 1693 to. 1695 7. IANA Considerations 1697 IANA is requested to register the following media types, described 1698 elsewhere in this document, for use with the Content-Type header 1699 field, in the IETF tree in accordance with the procedures set out in 1700 [RFC4288]. 1702 application/news-transmission (4.1) 1703 application/news-groupinfo (4.2) 1704 application/news-checkgroups (4.3) 1706 IANA is also requested to change the status of the following media 1707 type to "OBSOLETE". 1709 message/news 1711 message/rfc822 should be used instead. 1713 8. References 1715 8.1. Normative References 1717 [ASCII] "American National Standard for Information Systems - 1718 Coded Character Sets - 7-Bit American National Standard 1719 Code for Information Interchange (7-Bit ASCII)", 1720 ANSI X3.4, 1986. 1722 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1723 Extensions (MIME) Part Two: Media Types", RFC 2046, 1724 November 1996. 1726 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1727 Requirement Levels", BCP 14, RFC 2119, March 1997. 1729 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 1730 April 2001. 1732 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 1733 Registration Procedures", BCP 13, RFC 4288, December 2005. 1735 [USEFOR] Murchison, K., Ed., Lindsey, C., and D. Kohn, "Netnews 1736 Article Format". 1738 8.2. Informative References 1740 [RFC0976] Horton, M., "UUCP mail interchange format standard", 1741 RFC 976, February 1986. 1743 [RFC1036] Horton, M. and R. Adams, "Standard for interchange of 1744 USENET messages", RFC 1036, December 1987. 1746 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1747 Extensions (MIME) Part One: Format of Internet Message 1748 Bodies", RFC 2045, November 1996. 1750 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 1751 Names", BCP 32, RFC 2606, June 1999. 1753 [RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", 1754 RFC 3977, October 2006. 1756 [USEAGE] Lindsey, C., "Usenet Best Practice". 1758 Appendix A. Changes to the Existing Protocols 1760 This document prescribes many changes, clarifications, and new 1761 features since the protocol described in [RFC1036]. Most notably: 1763 o A new, backward-compatible Path header field format that permits 1764 standardized embedding of additional trace and authentication 1765 information is now RECOMMENDED. See Section 3.4 and Section 3.5. 1766 Folding of the Path header is permitted. 1768 o Trimming of the References header field is permitted and a 1769 mechanism for doing so is defined. 1771 o Addition of the new Injection-Date header field is required for 1772 injecting agents (Section 3.4) and must be used by news servers 1773 for date checks (Section 3.5). Injecting agents are strongly 1774 encouraged to put all local trace information in the new 1775 Injection-Info header field. 1777 o A new media type is defined for transmitting Netnews articles 1778 through other media (Section 4.1), and moderators should prepare 1779 to receive submissions in that format (Section 3.4.1). 1781 o Certain control messages (Section 5.6) are declared obsolete, and 1782 the special significance of "cmsg" at the start of a Subject 1783 header field is removed. 1785 o Additional media types are defined for improved structuring, 1786 specification, and automated processing of control messages 1787 (Section 4.2 and Section 4.3). 1789 o Two new optional parameters are added to the checkgroups control 1790 message. 1792 o The message/news media type is declared obsolete. 1794 o Cancel control messages are no longer required to have From and 1795 Sender header fields matching those of the target message, as this 1796 requirement added no real security. 1798 In addition, many protocol steps and article verification 1799 requirements unmentioned or left ambiguous by [RFC1036] but widely 1800 implemented by Netnews servers have been standardized and specified 1801 in detail. 1803 Appendix B. Acknowledgements 1805 This document is the result of a ten year effort and the number of 1806 people that have contributed to its content are too numerous to 1807 mention individually. Many thanks go out to all past and present 1808 members of the USEFOR Working Group of the Internet Engineering Task 1809 Force (IETF) and the accompanying mailing list. 1811 Special thanks are due to Henry Spencer, whose Son-of-1036 draft 1812 served as the initial basis for this document. 1814 Authors' Addresses 1816 Russ Allbery (editor) 1817 Stanford University 1818 P.O. Box 20066 1819 Stanford, CA 94309 1820 US 1822 Email: rra@stanford.edu 1823 URI: http://www.eyrie.org/~eagle/ 1825 Charles H. Lindsey 1826 University of Manchester 1827 5 Clerewood Avenue 1828 Heald Green 1829 Cheadle 1830 Cheshire SK8 3JU 1831 United Kingdom 1833 Phone: +44 161 436 6131 1834 Email: chl@clerew.man.ac.uk 1836 Full Copyright Statement 1838 Copyright (C) The Internet Society (2006). 1840 This document is subject to the rights, licenses and restrictions 1841 contained in BCP 78, and except as set forth therein, the authors 1842 retain all their rights. 1844 This document and the information contained herein are provided on an 1845 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1846 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1847 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1848 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1849 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1850 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1852 Intellectual Property 1854 The IETF takes no position regarding the validity or scope of any 1855 Intellectual Property Rights or other rights that might be claimed to 1856 pertain to the implementation or use of the technology described in 1857 this document or the extent to which any license under such rights 1858 might or might not be available; nor does it represent that it has 1859 made any independent effort to identify any such rights. Information 1860 on the procedures with respect to rights in RFC documents can be 1861 found in BCP 78 and BCP 79. 1863 Copies of IPR disclosures made to the IETF Secretariat and any 1864 assurances of licenses to be made available, or the result of an 1865 attempt made to obtain a general license or permission for the use of 1866 such proprietary rights by implementers or users of this 1867 specification can be obtained from the IETF on-line IPR repository at 1868 http://www.ietf.org/ipr. 1870 The IETF invites any interested party to bring to its attention any 1871 copyrights, patents or patent applications, or other proprietary 1872 rights that may cover technology that may be required to implement 1873 this standard. Please address the information to the IETF at 1874 ietf-ipr@ietf.org. 1876 Acknowledgment 1878 Funding for the RFC Editor function is provided by the IETF 1879 Administrative Support Activity (IASA).