Network Working Group R. Allbery, Ed.
Request for Comments: 5537 Stanford University
Obsoletes: 1036 C. Lindsey
Category: Standards Track November 2009
Network Working Group R. Allbery, Ed.
Request for Comments: 5537 Stanford University
Obsoletes: 1036 C. Lindsey
Category: Standards Track November 2009
Netnews Architecture and Protocols
网络新闻体系结构和协议
Abstract
摘要
This document defines the architecture of Netnews systems and specifies the correct manipulation and interpretation of Netnews articles by software that originates, distributes, stores, and displays them. It also specifies the requirements that must be met by any protocol used to transport and serve Netnews articles.
本文档定义了Netnews系统的体系结构，并规定了通过软件对Netnews文章进行正确的操作和解释，这些软件可以生成、分发、存储和显示这些文章。它还规定了用于传输和服务Netnews文章的任何协议必须满足的要求。
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括《信托法律条款》第4.e节中所述的简化BSD许可文本，并且提供BSD许可中所述的代码组件时不提供任何担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Basic Concepts .............................................3
1.2. Scope ......................................................3
1.3. Requirements Notation ......................................3
1.4. Syntax Notation ............................................3
1.5. Definitions ................................................4
2. Transport .......................................................5
1. Introduction ....................................................3
1.1. Basic Concepts .............................................3
1.2. Scope ......................................................3
1.3. Requirements Notation ......................................3
1.4. Syntax Notation ............................................3
1.5. Definitions ................................................4
2. Transport .......................................................5
3. Duties of Agents ................................................6
3.1. General Principles .........................................6
3.2. The Path Header Field ......................................7
3.2.1. Constructing the Path Header Field ..................8
3.2.2. Path Header Field Example ...........................9
3.3. Article History and Duplicate Suppression .................10
3.4. Duties of a Posting Agent .................................11
3.4.1. Proto-Articles .....................................12
3.4.2. Multiple Injection of Articles .....................13
3.4.3. Followups ..........................................14
3.4.4. Construction of the References Header Field ........15
3.5. Duties of an Injecting Agent ..............................15
3.5.1. Forwarding Messages to a Moderator .................18
3.6. Duties of a Relaying Agent ................................19
3.7. Duties of a Serving Agent .................................21
3.8. Duties of a Reading Agent .................................22
3.9. Duties of a Moderator .....................................22
3.10. Duties of a Gateway ......................................24
3.10.1. Duties of an Outgoing Gateway .....................25
3.10.2. Duties of an Incoming Gateway .....................25
3.10.3. Original-Sender Header Field ......................27
3.10.4. Gateway Example ...................................28
4. Media Types ....................................................29
4.1. application/news-transmission .............................30
4.2. application/news-groupinfo ................................31
4.3. application/news-checkgroups ..............................33
5. Control Messages ...............................................35
5.1. Authentication and Authorization ..........................35
5.2. Group Control Messages ....................................36
5.2.1. The newgroup Control Message .......................36
5.2.1.1. newgroup Control Message Example ..........37
5.2.2. The rmgroup Control Message ........................38
5.2.3. The checkgroups Control Message ....................38
5.3. The cancel Control Message ................................40
5.4. The Supersedes Header Field ...............................40
5.5. The ihave and sendme Control Messages .....................41
5.6. Obsolete Control Messages .................................42
6. Security Considerations ........................................42
6.1. Compromise of System Integrity ............................42
6.2. Denial of Service .........................................44
6.3. Leakage ...................................................44
7. IANA Considerations ............................................45
8. References .....................................................45
8.1. Normative References ......................................45
8.2. Informative References ....................................46
Appendix A. Changes to the Existing Protocols ....................47
Appendix B. Acknowledgements .....................................48
3. Duties of Agents ................................................6
3.1. General Principles .........................................6
3.2. The Path Header Field ......................................7
3.2.1. Constructing the Path Header Field ..................8
3.2.2. Path Header Field Example ...........................9
3.3. Article History and Duplicate Suppression .................10
3.4. Duties of a Posting Agent .................................11
3.4.1. Proto-Articles .....................................12
3.4.2. Multiple Injection of Articles .....................13
3.4.3. Followups ..........................................14
3.4.4. Construction of the References Header Field ........15
3.5. Duties of an Injecting Agent ..............................15
3.5.1. Forwarding Messages to a Moderator .................18
3.6. Duties of a Relaying Agent ................................19
3.7. Duties of a Serving Agent .................................21
3.8. Duties of a Reading Agent .................................22
3.9. Duties of a Moderator .....................................22
3.10. Duties of a Gateway ......................................24
3.10.1. Duties of an Outgoing Gateway .....................25
3.10.2. Duties of an Incoming Gateway .....................25
3.10.3. Original-Sender Header Field ......................27
3.10.4. Gateway Example ...................................28
4. Media Types ....................................................29
4.1. application/news-transmission .............................30
4.2. application/news-groupinfo ................................31
4.3. application/news-checkgroups ..............................33
5. Control Messages ...............................................35
5.1. Authentication and Authorization ..........................35
5.2. Group Control Messages ....................................36
5.2.1. The newgroup Control Message .......................36
5.2.1.1. newgroup Control Message Example ..........37
5.2.2. The rmgroup Control Message ........................38
5.2.3. The checkgroups Control Message ....................38
5.3. The cancel Control Message ................................40
5.4. The Supersedes Header Field ...............................40
5.5. The ihave and sendme Control Messages .....................41
5.6. Obsolete Control Messages .................................42
6. Security Considerations ........................................42
6.1. Compromise of System Integrity ............................42
6.2. Denial of Service .........................................44
6.3. Leakage ...................................................44
7. IANA Considerations ............................................45
8. References .....................................................45
8.1. Normative References ......................................45
8.2. Informative References ....................................46
Appendix A. Changes to the Existing Protocols ....................47
Appendix B. Acknowledgements .....................................48
"Netnews" is a set of protocols for generating, storing, and retrieving news "articles" whose format is defined in [RFC5536], and for exchanging them amongst a readership that is potentially widely distributed. It is organized around "newsgroups", with the expectation that each reader will be able to see all articles posted to each newsgroup in which he participates. These protocols most commonly use a flooding algorithm that propagates copies throughout a network of participating servers. Typically, only one copy is stored per server, and each server makes it available on demand to readers able to access that server.
“网络新闻”是一套协议，用于生成、存储和检索格式在[RFC5536]中定义的新闻“文章”，以及在可能广泛分布的读者群之间交换新闻。它是围绕“新闻组”组织的，期望每个读者都能看到他所参与的每个新闻组的所有文章。这些协议通常使用泛洪算法，在参与服务器的网络中传播副本。通常，每台服务器只存储一个副本，并且每台服务器都使能够访问该服务器的读者可以根据需要使用该副本。
"Usenet" is a particular worldwide, publicly accessible network based on the Netnews protocols. It is only one such possible network; there are deployments of the Netnews protocols other than Usenet (such as ones internal to particular organizations). This document discusses the more general Netnews architecture and protocols.
“Usenet”是一个基于Netnews协议的特定全球公共访问网络。这只是一个这样的可能网络；除了Usenet之外，还有Netnews协议的部署（例如特定组织内部的协议）。本文档讨论更通用的Netnews体系结构和协议。
This document defines the architecture of Netnews systems and specifies the correct manipulation and interpretation of Netnews articles by software that originates, distributes, stores, and displays them. It addresses protocol issues that are independent of transport protocols such as the Network News Transfer Protocol (NNTP) [RFC3977], and specifies the requirements Netnews places on those underlying transport protocols. It also specifies the handling of control messages.
本文档定义了Netnews系统的体系结构，并规定了通过软件对Netnews文章进行正确的操作和解释，这些软件可以生成、分发、存储和显示这些文章。它解决了独立于传输协议（如网络新闻传输协议（NNTP）[RFC3977]）的协议问题，并指定了Netnews对这些底层传输协议的要求。它还指定控制消息的处理。
The format and syntax of Netnews articles are specified in [RFC5536], which should be read in conjunction with this document.
[RFC5536]中规定了Netnews文章的格式和语法，应结合本文档阅读。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Syntax defined in this document uses the Augmented Backus-Naur Form (ABNF) notation (including the Core Rules) defined in [RFC5234] and constructs defined in [RFC5536] and [RFC5322].
本文档中定义的语法使用[RFC5234]中定义的增广巴科斯诺尔形式（ABNF）符号（包括核心规则），以及[RFC5536]和[RFC5322]中定义的结构。
The ABNF rules defined elsewhere and used in this document are:
其他地方定义并在本文件中使用的ABNF规则为：
CRLF = <see [RFC5234] Appendix B.1>
DIGIT = <see [RFC5234] Appendix B.1>
HTAB = <see [RFC5234] Appendix B.1>
SP = <see [RFC5234] Appendix B.1>
WSP = <see [RFC5234] Appendix B.1>
VCHAR = <see [RFC5234] Appendix B.1>
CRLF = <see [RFC5234] Appendix B.1>
DIGIT = <see [RFC5234] Appendix B.1>
HTAB = <see [RFC5234] Appendix B.1>
SP = <see [RFC5234] Appendix B.1>
WSP = <see [RFC5234] Appendix B.1>
VCHAR = <see [RFC5234] Appendix B.1>
argument = <see [RFC5536] Section 3.2.3>
article-locator = <see [RFC5536] Section 3.2.14>
component = <see [RFC5536] Section 3.1.4>
control-command = <see [RFC5536] Section 3.2.3>
diag-keyword = <see [RFC5536] Section 3.1.5>
diag-match = <see [RFC5536] Section 3.1.5>
diag-other = <see [RFC5536] Section 3.1.5>
dist-name = <see [RFC5536] Section 3.2.4>
msg-id = <see [RFC5536] Section 3.1.3>
newsgroup-name = <see [RFC5536] Section 3.1.4>
path-diagnostic = <see [RFC5536] Section 3.1.5>
path-identity = <see [RFC5536] Section 3.1.5>
path-nodot = <see [RFC5536] Section 3.1.5>
tail-entry = <see [RFC5536] Section 3.1.5>
verb = <see [RFC5536] Section 3.2.3>
argument = <see [RFC5536] Section 3.2.3>
article-locator = <see [RFC5536] Section 3.2.14>
component = <see [RFC5536] Section 3.1.4>
control-command = <see [RFC5536] Section 3.2.3>
diag-keyword = <see [RFC5536] Section 3.1.5>
diag-match = <see [RFC5536] Section 3.1.5>
diag-other = <see [RFC5536] Section 3.1.5>
dist-name = <see [RFC5536] Section 3.2.4>
msg-id = <see [RFC5536] Section 3.1.3>
newsgroup-name = <see [RFC5536] Section 3.1.4>
path-diagnostic = <see [RFC5536] Section 3.1.5>
path-identity = <see [RFC5536] Section 3.1.5>
path-nodot = <see [RFC5536] Section 3.1.5>
tail-entry = <see [RFC5536] Section 3.1.5>
verb = <see [RFC5536] Section 3.2.3>
display-name = <see [RFC5322] Section 3.4>
local-part = <see [RFC5322] Section 3.4.1>
mailbox = <see [RFC5322] Section 3.4>
display-name = <see [RFC5322] Section 3.4>
local-part = <see [RFC5322] Section 3.4.1>
mailbox = <see [RFC5322] Section 3.4>
Any term used in this document that is defined in Section 1.5 of [RFC5536] is used with the definition given there. In addition, the following terms will be used:
[RFC5536]第1.5节中定义的本文件中使用的任何术语均与此处给出的定义一起使用。此外，将使用以下术语：
A "hierarchy" is the set of all newsgroups whose names share a first <component> (as defined in Section 3.1.4 of [RFC5536]). A "sub-hierarchy" is the set of all newsgroups whose names share several initial components.
“层次结构”是名称共享第一个<component>（如[RFC5536]第3.1.4节所定义）的所有新闻组的集合。“子层次结构”是名称共享多个初始组件的所有新闻组的集合。
A "news server" is further distinguished into the roles of "injecting agent", "relaying agent", and "serving agent". An "injecting agent" accepts a proto-article with the goal of distributing it to relaying and serving agents and hence to readers. A "relaying agent" accepts articles from other relaying agents or injecting agents and distributes them to other relaying agents or serving agents. A "serving agent" receives an article from a relaying agent or injecting agent and makes it available to readers.
“新闻服务器”被进一步区分为“注入代理”、“中继代理”和“服务代理”。“注入代理”接受原型文章，目的是将其分发给中继代理和服务代理，从而分发给读者。“中继代理”接受其他中继代理或注射代理的物品，并将其分发给其他中继代理或服务代理。“服务代理”从中继代理或注入代理接收文章，并将其提供给读者。
A "user agent" is further distinguished into the roles of "posting agent" and "reading agent". A "posting agent" is software that assists in the preparation of a proto-article and then passes it to an injecting agent. A "reading agent" is software that retrieves articles from a serving agent for presentation to a reader.
“用户代理”进一步分为“发布代理”和“阅读代理”两种角色。“发帖代理”是一种软件，它帮助准备一个原型文章，然后将其传递给一个注射代理。“阅读代理”是一种从服务代理检索文章以呈现给读者的软件。
"Injecting" an article is the processing of a proto-article by an injecting agent. Normally, this action is done once and only once for a given article. "Multiple injection" is passing the same article to multiple injecting agents, either serially or in parallel, by one or several posting agents.
“注射”物品是指通过注射剂对原型物品进行加工。通常，对于给定的项目，此操作只执行一次。“多次投递”是指通过一个或多个投递代理将同一篇文章以串行或并行方式传递给多个投递代理。
A "gateway" is software that receives news articles and converts them to messages of some other kind (such as [RFC5322] mail messages), receives messages of some other kind and converts them to news articles, or conveys articles between two separate Netnews networks.
“网关”是一种软件，用于接收新闻文章并将其转换为其他类型的消息（如[RFC5322]邮件消息），接收其他类型的消息并将其转换为新闻文章，或在两个独立的网络新闻网络之间传送文章。
The exact means used to transmit articles from one agent to another is not specified. NNTP [RFC3977] is the most common transport mechanism for Netnews networks. Other methods in use include the Unix-to-Unix Copy Protocol [UUCP] (extensively used in the early days of Usenet) and physically delivered magnetic and optical media. Any mechanism may be used in conjunction with this protocol provided that it can meet the requirements specified here.
未指定将物品从一个代理传送到另一个代理的确切方式。NNTP[RFC3977]是网络新闻网络最常见的传输机制。其他正在使用的方法包括Unix到Unix复制协议[UUCP]（在Usenet早期广泛使用）和物理传输的磁性和光学介质。任何机制均可与本协议结合使用，前提是其能够满足此处规定的要求。
Transports for Netnews articles MUST treat news articles as uninterpreted sequences of octets, excluding the values %d00 (which may not occur in Netnews articles), %d13, and %d10 (which MUST only appear in Netnews articles as a pair in that order and which, together, denote a line separator). These octets are the US-ASCII [ASCII] characters NUL, CR, and LF respectively.
Netnews文章的传输必须将新闻文章视为未解释的八位字节序列，不包括值%d00（可能不会出现在Netnews文章中）、%d13和%d10（只能以该顺序成对出现在Netnews文章中，并一起表示行分隔符）。这些八位字节分别是US-ASCII[ASCII]字符NUL、CR和LF。
NOTE: This corresponds to the range of octets permitted in MIME 8bit data [RFC2045]. Transports for Netnews are not required to support transmission of MIME binary data.
注：这对应于MIME 8bit数据[RFC2045]中允许的八位字节范围。Netnews的传输不需要支持MIME二进制数据的传输。
In particular, transports MUST convey all header fields unmodified (including header fields within message/rfc822 objects in article bodies), even if they contain octets in the range of 128 to 255. Furthermore, transports for relaying and serving agents MUST, and transports for other agents SHOULD, convey lines even if they exceed 998 characters in length, especially in article bodies. (This requirement is stricter than MIME 8bit data.) These requirements include the transport paths between posting agents, injecting agents, serving agents, and reading agents.
特别是，传输必须传输未修改的所有头字段（包括文章正文中message/rfc822对象中的头字段），即使它们包含128到255之间的八位字节。此外，中继和服务代理的传输必须传输线路，而其他代理的传输应该传输线路，即使线路长度超过998个字符，尤其是在文章正文中。（此要求比MIME 8bit数据更严格。）这些要求包括投递代理、注入代理、服务代理和阅读代理之间的传输路径。
The following section specifies the duties of the agents involved in the creation, relaying, and serving of Netnews articles. This protocol is described by following the life of a typical Usenet article: it is prepared by a posting agent, given to an injecting agent, transferred through one or more relaying agents, accepted by a serving agent, and finally retrieved by a reading agent. Articles submitted to moderated groups go through an additional process, which is described separately (see Section 3.5.1 and Step 7 of Section 3.5). Finally, the additional duties and requirements of a gateway are discussed.
下一节规定了网络新闻文章的创作、转载和服务所涉及的代理人的职责。该协议按照典型的Usenet文章的生命周期进行描述：它由发布代理准备，提供给注入代理，通过一个或多个中继代理传输，由服务代理接受，最后由阅读代理检索。提交给主持人组的文章需要经过一个额外的过程，这一过程将单独描述（参见第3.5.1节和第3.5节的步骤7）。最后，讨论了网关的附加职责和要求。
At each step, each agent has a set of checks and transformations of the article that it is required to perform. These are described as sequences of steps to be followed, but it should be understood that it is the effect of these sequences that is important, and implementations may use any method that produces the same effect.
在每个步骤中，每个代理都有一组它需要执行的对文章的检查和转换。这些被描述为要遵循的步骤序列，但是应该理解，这些序列的效果才是重要的，并且实现可以使用产生相同效果的任何方法。
Many news servers combine the functions of injecting agent, relaying agent, and serving agent in a single software package. For the purposes of this specification, such combined agents should conceptually be treated as an injecting agent that sends articles to a serving agent and, optionally, to a relaying agent. The requirements of all three agents MUST still be met when the news server is performing the functions of those agents.
许多新闻服务器在单个软件包中结合了注入代理、中继代理和服务代理的功能。出于本规范的目的，此类组合代理在概念上应被视为向服务代理和（可选）中继代理发送物品的注射代理。当新闻服务器执行这三个代理的功能时，仍然必须满足这三个代理的要求。
On news servers that accept them, control messages may have additional effects than those described below. Those effects are described in Section 5.
在接受控制消息的新闻服务器上，控制消息可能具有比下面描述的效果更多的效果。第5节描述了这些影响。
There are two important principles that news implementors and administrators need to keep in mind. The first is the well-known Internet Robustness Principle:
新闻实施者和管理员需要记住两个重要原则。第一个是众所周知的互联网稳健性原则：
Be liberal in what you accept, and conservative in what you send.
在你接受的东西上要自由，在你发送的东西上要保守。
As applied to Netnews, this primarily means that unwanted or non-compliant articles SHOULD be rejected as early as possible, but once they are in general circulation, relaying and serving agents may wish to accept them where possible rather than lose information. Posting agents and injecting agents SHOULD therefore be maximally strict in their application of both this protocol and [RFC5536], and reading agents SHOULD be robust in the presence of violations of the Netnews article format where possible.
对于网络新闻而言，这主要意味着不需要的或不符合要求的文章应尽早被拒绝，但一旦它们在大众传播中，中继和服务代理可能希望在可能的情况下接受它们，而不是丢失信息。因此，发帖代理和注射代理在应用本协议和[RFC5536]时应最大限度地严格，阅读代理应在可能的情况下，在存在违反Netnews文章格式的情况下保持稳健。
In the case of Netnews, there is an even more important principle, derived from a much older code of practice, the Hippocratic Oath (we may thus call this the Hippocratic Principle):
就网络新闻而言，还有一个更为重要的原则，源自一个更为古老的实践准则，即希波克拉底誓言（我们因此可以称之为希波克拉底原则）：
First, do no harm.
首先，不要伤害别人。
It is vital to realize that decisions that might be merely suboptimal in a smaller context can become devastating mistakes when amplified by the actions of thousands of hosts within a few minutes.
重要的是要认识到，在较小的环境中可能只是次优的决策，如果在几分钟内被数千名主机的行为放大，可能会成为灾难性的错误。
No Netnews agent is ever required to accept any article. It is common for injecting, relaying, and serving agents to reject well-formed articles for reasons of local policy (such as not wishing to carry a particular newsgroup or attempting to filter out unwanted articles). This document specifies how articles are to be treated if they are accepted and specifies some cases where they must be rejected, but an agent MAY always reject any article for other reasons than those stated here.
任何网络新闻代理都不需要接受任何文章。由于当地政策的原因（例如不希望携带特定新闻组或试图过滤掉不需要的文章），注射、转送和服务代理拒绝格式良好的文章是很常见的。本文件规定了接受物品时应如何处理物品，并规定了必须拒收物品的一些情况，但代理人可出于此处所述以外的其他原因拒收任何物品。
A primary goal of the Netnews protocol is to ensure that all readers receiving a particular article (as uniquely identified by the content of its Message-ID header field) see the identical article, apart from allowable divergence in trace headers and local metadata. Accordingly, agents (other than moderators) MUST NOT modify articles in ways other than described here. Unacceptable articles MUST be rejected rather than corrected.
Netnews协议的一个主要目标是，除了跟踪头和本地元数据中允许的差异外，确保接收特定文章（由其消息ID头字段的内容唯一标识）的所有读者都能看到相同的文章。因此，代理（版主除外）不得以本文所述以外的方式修改文章。不合格品必须拒收，而不是纠正。
All news server components (injecting agents, relaying agents, and serving agents) MUST identify themselves, when processing an article, by prepending their <path-identity> (defined in Section 3.1.5 of [RFC5536]) to the Path header field. Injecting agents MUST also use the same identity in Injection-Info header fields that they add, and serving and relaying agents SHOULD use the same identity in any Xref header fields they add.
在处理文章时，所有新闻服务器组件（注入代理、中继代理和服务代理）必须通过在路径头字段前加上<path identity>（在[RFC5536]第3.1.5节中定义）来标识自己。注入代理还必须在其添加的注入信息头字段中使用相同的标识，服务代理和中继代理在其添加的任何外部参照头字段中都应使用相同的标识。
The <path-identity> used by an agent may be chosen via one of the following methods (in decreasing order of preference):
代理使用的<path identity>可通过以下方法之一选择（按优先顺序递减）：
1. The fully qualified domain name (FQDN) of the system on which the agent is running.
1. 运行代理的系统的完全限定域名（FQDN）。
2. A fully qualified domain name (FQDN) within a domain affiliated with the administrators of the agent and guaranteed to be unique by the administrators of that domain. For example, the
2. 与代理的管理员关联的域中的完全限定域名（FQDN），并由该域的管理员保证其唯一性。例如
uniqueness of server.example.org could be guaranteed by the administrator of example.org even if there is no DNS record for server.example.org itself.
example.org的管理员可以保证server.example.org的唯一性，即使server.example.org本身没有DNS记录。
3. Some other (arbitrary) name in the form of a <path-nodot>, believed to be unique and registered at least with all the other news servers to which that relaying agent or injecting agent sends articles. This option SHOULD NOT be used unless the earlier options are unavailable or unless the name is of longstanding usage.
3. 以<path nodot>形式出现的一些其他（任意）名称，被认为是唯一的，并且至少在中继代理或注入代理向其发送文章的所有其他新闻服务器上注册。除非先前的选项不可用或名称长期使用，否则不应使用此选项。
Some existing implementations treat <path-identity> as case-sensitive, some as case-insensitive. The <path-identity> therefore SHOULD be all lowercase and implementations SHOULD compare identities case-insensitively.
有些现有实现将<path identity>视为区分大小写，有些则视为不区分大小写。因此，<path identity>应该都是小写的，实现应该不敏感地比较identity的大小写。
If a relaying or serving agent receives an article from an injecting or serving agent that is part of the same news server, it MAY leave the Path header field of the article unchanged. Otherwise, every injecting, relaying, or serving agent that accepts an article MUST update the Path header field as follows. Note that the Path header field content is constructed from right to left by prepending elements.
如果中继代理或服务代理从属于同一新闻服务器的注入代理或服务代理接收文章，它可能会保持文章的路径头字段不变。否则，接受项目的每个注入、中继或服务代理必须更新路径头字段，如下所示。请注意，路径头字段内容是通过预先添加元素从右向左构造的。
1. The agent MUST prepend "!" to the Path header field content.
1. 代理必须在路径头字段内容前加“！”。
2. An injecting agent SHOULD prepend the <path-diagnostic> "!.POSTED", optionally followed by "." and the FQDN or IP address of the source, to the Path header field content.
2. 注入代理应将<path diagnostic>“！.post”和源的FQDN或IP地址加在路径头字段内容的前面（可选）。
3. A relaying or serving agent SHOULD prepend a <path-diagnostic> to the Path header field content, where the <path-diagnostic> is chosen as follows:
3. 中继或服务代理应在路径头字段内容前添加<path diagnostic>，其中<path diagnostic>的选择如下：
* If the expected <path-identity> of the source of the article matches the leftmost <path-identity> of the Path header field's content, use "!" (<diag-match>), resulting in two consecutive "!"s.
* 如果文章源的预期<path identity>与路径标题字段内容最左边的<path identity>匹配，请使用“！”（<diag match>），从而产生两个连续的“！”s。
* If the expected <path-identity> of the source of the article does not match, use "!.MISMATCH." followed by the expected <path-identity> of the source or its IP address.
* 如果文章源的预期<path identity>不匹配，请使用“！.MISMATCH.”后跟源或其IP地址的预期<path identity>。
* If the relaying or serving agent is not willing or able to check the <path-identity>, use "!.SEEN." followed by the FQDN, IP address, or expected <path-identity> of the source.
* 如果中继或服务代理不愿意或无法检查<path identity>，请使用“！.SEEN.”后跟源的FQDN、IP地址或预期的<path identity>。
The "expected <path-identity> of the source of the article" is a <path-identity> for the injecting or relaying agent that passed the article to this relaying or serving agent, determined by properties of the connection via which the article was received (for example, an authentication identity or a peer IP address). Be aware that [RFC1036] did not include <path-diagnostic>. Implementations that predate this specification will add only single "!" characters between <path-identity> strings.
“文章源的预期<path identity>”是将文章传递给该中继或服务代理的注入或中继代理的<path identity>，由接收文章的连接的属性（例如，身份验证标识或对等IP地址）确定。请注意，[RFC1036]不包括<path diagnostic>。早于此规范的实现将只在<path identity>字符串之间添加单个“！”字符。
4. The agent MAY then prepend to the Path header field content "!" or "!!" followed by an additional <path-identity> for itself other than its primary one. Using "!!", and thereby adding a <diag-match> since the <path-identity> clearly is verified, is RECOMMENDED. This step may be repeated any number of times. This is permitted for agents that have multiple <path-identity>s (such as during a transition from one to another). Each of these <path-identity>s MUST meet the requirements set out in Section 3.2.
4. 然后，代理可以在路径头字段内容“！”或“！！”前面加上一个除其主字段外的附加<Path identity>。建议使用“！！”，从而添加一个<diag match>，因为<path identity>已明确验证。此步骤可重复任意次数。这对于具有多个<path identity>s的代理是允许的（例如在从一个到另一个的转换期间）。每个<path identity>s必须满足第3.2节中规定的要求。
5. Finally, the agent MUST prepend its primary <path-identity> to the Path header field content. The primary <path-identity> is the <path-identity> it normally advertises to its peers for their use in generating <path-diagnostic>s as described above.
5. 最后，代理必须将其主<path identity>前置到路径头字段内容。主要的<path identity>是<path identity>，它通常向其对等方发出通告，以供其用于生成如上所述的<path diagnostic>s。
Any agent that modifies the Path header field MAY fold it by inserting FWS (folding white space) immediately after any <path-identity> or <diag-other> it added (see Section 3.1.5 of [RFC5536] for allowable locations for FWS).
修改路径头字段的任何代理都可以通过在添加的任何<Path identity>或<diag other>之后立即插入FWS（折叠空白）将其折叠（FWS的允许位置见[RFC5536]第3.1.5节）。
Here is an example of a Path header field created by following the rules for injecting and relaying agents.
下面是通过遵循注入和中继代理的规则创建的路径头字段的示例。
Path: foo.isp.example!.SEEN.isp.example!foo-news
!.MISMATCH.2001:DB8:0:0:8:800:200C:417A!bar.isp.example
!!old.site.example!barbaz!!baz.isp.example
!.POSTED.dialup123.baz.isp.example!not-for-mail
Path: foo.isp.example!.SEEN.isp.example!foo-news
!.MISMATCH.2001:DB8:0:0:8:800:200C:417A!bar.isp.example
!!old.site.example!barbaz!!baz.isp.example
!.POSTED.dialup123.baz.isp.example!not-for-mail
This article was injected by baz.isp.example as indicated by the <diag-keyword> "POSTED". The injector has recorded that it received the article from dialup123.baz.isp.example. "not-for-mail" is a common <tail-entry>.
本文由baz.isp.example注入，如<diag关键字>“post”所示。喷油器已记录从dialup123.baz.isp.example收到物品。“不用于邮件”是常见的<tail entry>。
The article was relayed to the relaying agent known, at least to old.site.example, as "barbaz". That relaying agent confirmed to its satisfaction that "baz.isp.example" was an expected <path-identity> for the source of the article and therefore used <diag-match> ("!") for its <path-diagnostic>.
文章被转发给已知的中继代理，至少是old.site.example，称为“barbaz”。该中继代理满意地确认，“baz.isp.example”是本文源的预期<path identity>，因此在其<path diagnostic>中使用<diag match>（“！”）。
barbaz relayed it to old.site.example, which does not support <diag-keyword> and therefore used the old "!" delimiter. This indicates that the identity of "barbaz" was not verified and may have been forged.
barbaz将其转发到old.site.example，它不支持<diag keyword>，因此使用了旧的“！”分隔符。这表明“barbaz”的身份未经核实，可能是伪造的。
old.site.example relayed it to a news server using the <path-identity> of bar.isp.example and claiming (by using the "!" <path-diagnostic>) to have verified that it came from old.site.example.
old.site.example使用bar.isp.example的<path identity>将其转发到新闻服务器，并声称（通过使用“！”<path diagnostic>）已验证其来自old.site.example。
bar.isp.example relayed it to foo-news, which, not being convinced that it truly came from bar.isp.example, inserted the <diag-keyword> "MISMATCH" and then stated that it received the article from the IPv6 address [2001:DB8:0:0:8:800:200C:417A]. (This is not to say that bar.isp.example was not a correct <path-identity> for that source but simply that the identity did not match the expectations of foo-news.)
bar.isp.example将其转发给foo news，foo news不确信它确实来自bar.isp.example，因此插入了<diag关键字>“不匹配”，然后声明它从IPv6地址收到了文章[2001:DB8:0:0:8:800:200C:417A]。（这并不是说bar.isp.example对于该来源来说不是正确的<path identity>，而是说该标识与foo news的预期不符。）
foo-news then passed the article to foo.isp.example, which declined to validate its <path-identity> and instead appended the <diag-keyword> "SEEN" to indicate it knows the source of the article as isp.example. This may be either an expected <path-identity> or the FQDN of the system from which it received the article. Presumably, foo.isp.example is a serving agent that then delivered the article to a reading agent.
foo news随后将文章传递给foo.isp.example，后者拒绝验证其<path identity>，而是添加了<diag keyword>“SEEN”，表示它知道文章的来源为isp.example。这可能是预期的<path identity>，也可能是接收文章的系统的FQDN。假定foo.isp.example是一个服务代理，然后将文章交付给阅读代理。
baz.isp.example, bar.isp.example, and foo-news folded the Path header field.
baz.isp.example、bar.isp.example和foo news折叠了路径头字段。
Netnews normally uses a flood-fill algorithm for propagation of articles in which each news server offers the articles it accepts to multiple peers, and each news server may be offered the same article from multiple other news servers. Accordingly, duplicate suppression is key; if a news server accepted every article it was offered, it may needlessly accept (and then potentially retransmit) dozens of copies of every article.
Netnews通常使用泛洪填充算法来传播文章，其中每个新闻服务器向多个对等方提供它接受的文章，并且每个新闻服务器可以从多个其他新闻服务器提供相同的文章。因此，重复抑制是关键；如果一个新闻服务器接受了它提供的每一篇文章，它可能不必要地接受（然后可能重新传输）每一篇文章的几十份副本。
Relaying and serving agents therefore MUST keep a record of articles they have already seen and use that record to reject additional offers of the same article. This record is called the "history" file or database.
因此，中继和服务代理必须保留他们已经看到的物品的记录，并使用该记录拒绝同一物品的额外报价。该记录称为“历史”文件或数据库。
Each article is uniquely identified by its message identifier, so a relaying or serving agent could satisfy this requirement by storing a record of every message identifier that agent has ever seen. Such a history database would grow without bound, however, so it is common and permitted to optimize based on the Injection-Date or Date header field of an article as follows. (In the following discussion, the "date" of an article is defined to be the date represented by its Injection-Date header field, if present; otherwise, by its Date header field.)
每个项目都由其消息标识符唯一标识，因此中继或服务代理可以通过存储代理所见过的每个消息标识符的记录来满足这一要求。然而，这样的历史数据库将不受限制地增长，因此它是常见的，并且允许根据文章的注入日期或日期标题字段进行优化，如下所示。（在下面的讨论中，文章的“日期”定义为注入日期标题字段（如果存在）表示的日期；否则，定义为日期标题字段表示的日期。）
o Agents MAY select a cutoff interval and reject any article with a date farther in the past than that cutoff interval. If this interval is shorter than the time it takes for an article to propagate through the network, the agent might reject an article it had not yet seen, so it ought not to be aggressively short. For Usenet, for example, a cutoff interval of no less than seven days is conventional.
o 代理商可以选择截止时间间隔，并拒绝任何日期超过该截止时间间隔的物品。如果此时间间隔短于文章在网络中传播所需的时间，则代理可能会拒绝它尚未看到的文章，因此不应过短。例如，对于Usenet，不少于7天的截止时间间隔是常规的。
o Agents that enforce such a cutoff MAY then drop records of articles that had dates older than the cutoff from their history databases. If such an article were offered to the agent again, it would be rejected due to the cutoff date, so the history record is no longer required to suppress the duplicate.
o 执行这种切断的代理可能会从其历史数据库中删除日期早于切断日期的文章记录。如果此类物品再次提供给代理商，则会因截止日期而被拒绝，因此不再需要历史记录来抑制副本。
o Alternatively, agents MAY drop history records according to the date when the article was first seen by that agent rather than the date of the article. In this case, the history retention interval MUST be at least 24 hours longer than the cutoff interval to allow for articles dated in the future. This interval matches the allowable error in the date of the article (see Section 3.5).
o 或者，代理可以根据该代理首次看到文章的日期而不是文章的日期删除历史记录。在这种情况下，历史记录保留时间间隔必须至少比截止时间间隔长24小时，以允许在将来记录日期。该间隔与文章日期的允许误差相匹配（见第3.5节）。
These are just two implementation strategies for article history, albeit the most common ones. Relaying and serving agents are not required to use these strategies, only to meet the requirement of not accepting an article more than once. However, these strategies are safe and widely deployed, and implementors are encouraged to use one of them, especially if they do not have extensive experience with Netnews and the subtle effects of its flood-fill algorithm.
这只是文章历史的两种实现策略，尽管是最常见的。中继和服务代理不需要使用这些策略，只需要满足不接受一个项目多次的要求。但是，这些策略是安全且广泛部署的，并且鼓励实施者使用其中一种策略，特别是如果他们没有Netnews及其洪水填充算法的丰富经验的话。
A posting agent is the component of a user agent that assists a poster in creating a valid proto-article and forwarding it to an injecting agent.
发帖代理是用户代理的组件，它帮助海报创建有效的原型文章并将其转发给用户代理。
Posting agents SHOULD ensure that proto-articles they create are valid according to [RFC5536] and any other applicable policies. They MUST NOT create any Injection-Info header field; this header field may only be added by the injecting agent.
根据[RFC5536]和任何其他适用政策，邮局代理应确保他们创建的原始文章有效。不得创建任何注入信息标题字段；此标题字段只能由注射剂添加。
If the proto-article already contains both Message-ID and Date header fields, posting agents MAY add an Injection-Date header field to that proto-article immediately before passing that proto-article to an injection agent. They SHOULD do so if the Date header field (representing the composition time of the proto-article) is more than a day in the past at the time of injection. They MUST do so if the proto-article is being submitted to more than one injecting agent; see Section 3.4.2.
如果原型文章已经包含消息ID和日期头字段，则过帐代理可以在将原型文章传递给注入代理之前立即向该原型文章添加注入日期头字段。如果日期标题字段（表示原型文章的合成时间）在注入时超过了一天，则应该这样做。如果原型物品被提交给多个注射剂，他们必须这样做；见第3.4.2节。
The Injection-Date header field is new in this revision of the Netnews protocol and is designed to allow the Date header field to hold the composition date (as recommended in Section 3.6.1 of [RFC5322]), even if the proto-article is not to be injected for some time after its composition. However, note that all implementations predating this specification ignore the Injection-Date header field and use the Date header field in its stead for rejecting articles older than their cutoff (see Section 3.3), and injecting agents predating this specification do not add an Injection-Date header. Articles with a Date header field substantially in the past will still be rejected by implementations predating this specification, regardless of the Injection-Date header field, and hence may suffer poorer propagation.
注入日期标题字段在本次Netnews协议修订版中是新的，其设计允许日期标题字段保存合成日期（如[RFC5322]第3.6.1节所建议），即使在合成后一段时间内不注入原型文章。但是，请注意，本规范之前的所有实施都会忽略注射日期标头字段，并使用日期标头字段代替拒绝早于截止日期的物品（参见第3.3节），并且本规范之前的注射剂不会添加注射日期标头。无论注入日期头字段是什么，在过去基本上带有日期头字段的文章仍然会被本规范之前的实现拒绝，因此可能会受到传播不良的影响。
Contrary to [RFC5322], which implies that the mailbox or mailboxes in the From header field should be that of the poster or posters, a poster who does not, for whatever reason, wish to use his own mailbox MAY use any mailbox ending in the top-level domain ".invalid" [RFC2606].
与[RFC5322]相反，这意味着发件人标头字段中的邮箱应该是海报的邮箱，无论出于何种原因，不希望使用自己邮箱的海报可以使用以顶级域结尾的任何邮箱。无效“[RFC2606]。
Posting agents meant for use by ordinary posters SHOULD reject any attempt to post an article that cancels or supersedes (via the Supersedes header field) another article of which the poster is not the author or sender.
供普通海报使用的投递代理应拒绝投递取消或取代（通过“取代标题”字段）海报不是作者或发件人的另一篇文章的任何尝试。
A proto-article is an article in the format used by a posting agent when offering that article to an injecting agent. It may omit certain header fields that can be better supplied by the injecting agent and will not contain header fields that are added by the injecting agent. A proto-article is only for transmission to an injecting agent and SHOULD NOT be transmitted to any other agent.
原型文章是一篇文章，其格式为投递代理在向投递代理提供该文章时所使用的格式。它可以省略某些可以由注入代理更好地提供的头字段，并且不包含由注入代理添加的头字段。原型物品仅用于传输至注射剂，不应传输至任何其他制剂。
A proto-article has the same format as a normal article except that the Injection-Info and Xref header fields MUST NOT be present, the Path header field SHOULD NOT contain a "POSTED" <diag-keyword>, and any of the following mandatory header fields MAY be omitted: Message-ID, Date, and Path. In all other respects, a proto-article MUST be a valid Netnews article. In particular, the header fields that may be omitted MUST NOT be present with invalid content.
原型文章的格式与普通文章相同，不同之处在于注入信息和外部参照标题字段不得存在，路径标题字段不应包含“POSTED”<diag keyword>，并且可以省略以下任何必填标题字段：消息ID、日期和路径。在所有其他方面，原型文章必须是有效的Netnews文章。特别是，可能被忽略的标题字段不得包含无效内容。
If a posting agent intends to offer the same proto-article to multiple injecting agents, the header fields Message-ID, Date, and Injection-Date MUST be present and identical in all copies of the proto-article. See Section 3.4.2.
如果过帐代理打算向多个注入代理提供相同的原型文章，则在原型文章的所有副本中，邮件ID、日期和注入日期的标题字段必须存在且相同。见第3.4.2节。
Under some circumstances (for example, when posting to multiple, supposedly disjoint, networks, when using injecting agents with spotty connectivity, or when desiring additional redundancy), a posting agent may wish to offer the same article to multiple injecting agents. In this unusual case, the goal is not to create multiple independent articles but rather to inject the same article at multiple points and let the normal duplicate suppression facility of Netnews (see Section 3.3) ensure that any given agent accepts the article only once, even if supposedly disjoint networks have unexpected links.
在某些情况下（例如，当投递到多个假定不相交的网络时，当使用连接不稳定的注入代理时，或当需要额外冗余时），投递代理可能希望向多个注入代理提供相同的文章。在这种不寻常的情况下，目标不是创建多个独立的文章，而是在多个点注入相同的文章，并让Netnews的正常重复抑制功能（参见第3.3节）确保任何给定代理只接受一次文章，即使假定不相交的网络具有意外链接。
Whenever possible, multiple injection SHOULD be done by offering the same proto-article to multiple injecting agents. The posting agent MUST supply the Message-ID, Date, and Injection-Date header fields, and the proto-article as offered to each injecting agent MUST be identical.
只要有可能，应通过向多个注射剂提供相同的原稿来进行多次注射。过帐代理必须提供消息ID、日期和注入日期标题字段，并且提供给每个注入代理的原型文章必须相同。
In some cases, offering the same proto-article to all injecting agents may not be possible (such as when gatewaying, after injection, articles found on one Netnews network to another supposedly unconnected one). In this case, the posting agent MUST remove any Xref header field and rename or remove any Injection-Info, Path, and other trace header fields before passing it to another injecting agent. (This converts the article back into a proto-article.) It MUST retain unmodified the Message-ID, Date, and Injection-Date header fields. It MUST NOT add an Injection-Date header field if it is missing from the existing article.
在某些情况下，可能不可能向所有注入代理提供相同的原始文章（例如，在注入后，将一个Netnews网络上的文章传送到另一个假定未连接的网络上）。在这种情况下，过帐代理必须删除任何外部参照标头字段，并重命名或删除任何注入信息、路径和其他跟踪标头字段，然后才能将其传递给其他注入代理。（这会将文章转换回原型文章。）它必须保留未修改的消息ID、日期和注入日期标头字段。如果现有文章中缺少注入日期标题字段，则不能添加该字段。
NOTE: Multiple injection inherently risks duplicating articles. Multiple injection after injection, by converting an article back to a proto-article and injecting it again, additionally risks loops, loss of trace information, unintended repeat injection into the same network, and other problems. It should be done with care
注：多次注射存在复制物品的固有风险。一次又一次的多次注入，通过将一篇文章转换回原型文章并再次注入，还存在循环、跟踪信息丢失、意外重复注入到同一网络以及其他问题的风险。这件事要小心
and only when there is no alternative. The requirement to retain Message-ID, Date, and Injection-Date header fields minimizes the possibility of a loop and ensures that the newly injected article is not treated as a new, separate article.
只有在别无选择的时候。保留消息ID、日期和注入日期头字段的要求将循环的可能性降至最低，并确保新注入的项目不会被视为新的、单独的项目。
Multiple injection of an article that lists one or more moderated newsgroups in its Newsgroups header field SHOULD only be done by a moderator and MUST only be done after the proto-article has been approved for all moderated groups to which it is to be posted and after an Approved header field has been added (see Section 3.9). Multiple injection of an unapproved article intended for moderated newsgroups will normally only result in the moderator receiving multiple copies, and if the newsgroup status is not consistent across all injecting agents, may result in duplication of the article or other problems.
在其新闻组标题字段中列出一个或多个版主新闻组的文章的多次注入只能由版主完成，并且必须在所有版主新闻组的原始文章被批准后以及在批准的标题字段被添加后才能完成（见第3.9节）。多次注入一篇未经批准的文章以供版主新闻组使用，通常只会导致版主收到多份副本，如果所有注入代理的新闻组状态不一致，则可能会导致文章重复或其他问题。
A followup is an article that contains a response to the contents of an earlier article, its precursor. In addition to its normal duties, a posting agent preparing a followup is also subject to the following requirements. Wherever in the following it is stated that, by default, a header field is said to be inherited from one of those header fields in the precursor, it means that its initial content is to be a copy of the content of that precursor header field (with changes in folding permitted). However, posters MAY then override that default before posting.
后续文章是一篇包含对早期文章（其前身）内容的响应的文章。除正常职责外，准备跟进的邮寄代理还需遵守以下要求。在下文中，无论何处规定，默认情况下，报头字段被称为继承自前体中的其中一个报头字段，这意味着其初始内容将是该前体报头字段内容的副本（允许更改折叠）。然而，海报可能会在发布之前覆盖默认设置。
Despite the historic practice of some posting agents, the Keywords header field SHOULD NOT be inherited by default from the precursor article.
尽管有一些过账代理的历史惯例，默认情况下，关键字标题字段不应从前体文章继承。
1. If the Followup-To header field of the precursor article consists of "poster", the followup MUST NOT be posted by default but, by default, is to be emailed to the address given in the precursor's Reply-To or From header field following the rules for an email reply [RFC5322]. This action MAY be overridden by the poster, in which case the posting agent should continue as if the Followup-To header field in the precursor did not exist.
1. 如果前体文章的Followup To header字段由“poster”组成，则默认情况下不得发布后续内容，而是按照电子邮件回复规则[RFC5322]通过电子邮件发送至前体回复至或来自标题字段中给出的地址。海报可能会覆盖此操作，在这种情况下，过帐代理应继续，就像前体中不存在标题字段的后续内容一样。
2. The Newsgroups header field SHOULD, by default, be inherited from the precursor's Followup-To header field if present; otherwise, it is inherited from the precursor's Newsgroups header field.
2. 默认情况下，新闻组标题字段应继承前体的后续标题字段（如果存在）；否则，它将从Premiser的新闻组标题字段继承。
3. The Subject header field SHOULD, by default, be inherited from that of the precursor. The case-sensitive string "Re: " (including the space after the colon) MAY be prepended to the content of its Subject header field unless it already begins with that string.
3. 默认情况下，主题标题字段应从前体字段继承。区分大小写的字符串“Re:”（包括冒号后的空格）可以在其主题标题字段的内容前面，除非它已经以该字符串开头。
NOTE: Prepending "Re: " serves no protocol function and hence is not required, but it is widely expected and not doing so would be surprising.
注：前缀“Re:”不提供协议功能，因此不需要，但这是普遍预期的，不这样做会令人惊讶。
4. The Distribution header field SHOULD, by default, be inherited from the precursor's Distribution header field, if present.
4. 默认情况下，分发标题字段应继承前体的分发标题字段（如果存在）。
5. The followup MUST have a References header field referring to its precursor, constructed in accordance with Section 3.4.4.
5. 后续必须有一个引用其前体的引用标题字段，按照第3.4.4节构造。
The following procedure is to be used whenever some previous article (the "parent") is to be referred to in the References header field of a new article, whether because the new article is a followup and the parent is its precursor or for some other reason.
无论是因为新文章是后续文章，且父文章是其前身，还是出于其他原因，只要在新文章的引用标题字段中引用某篇先前的文章（“父文章”），都将使用以下程序。
The content of the new article's References header field MUST be formed from the content of the parent's References header field if present, followed by the content of the Message-ID header field of the parent. If the parent had a References header, FWS as defined in [RFC5536] MUST be added between its content and the Message-ID header field content.
新项目的引用标头字段的内容必须由父项目的引用标头字段（如果存在）的内容构成，后跟父项目的消息ID标头字段的内容。如果父项具有引用标头，则必须在其内容和消息ID标头字段内容之间添加[RFC5536]中定义的FWS。
If the resulting References header field would, after unfolding, exceed 998 characters in length (including its field name but not the final CRLF), it MUST be trimmed (and otherwise MAY be trimmed). Trimming means removing any number of message identifiers from its content, except that the first message identifier and the last two MUST NOT be removed.
如果展开后生成的引用标头字段长度超过998个字符（包括其字段名，但不包括最终的CRLF），则必须对其进行修剪（否则可能会进行修剪）。修剪意味着从其内容中删除任意数量的消息标识符，但不能删除第一个消息标识符和最后两个消息标识符。
An essential property of the References header field, guaranteed by the above procedure and REQUIRED to be maintained by any extensions to this protocol, is that an article MUST NOT precede one of its parents.
引用头字段的一个基本属性（由上述过程保证，并且需要由本协议的任何扩展维护）是，一个项目不得位于其父项之一之前。
An injecting agent takes a proto-article from a posting agent and either forwards it to a moderator or passes it to a relaying or serving agent or agents. An injecting agent bears the primary responsibility for ensuring that any article it injects conforms with
注入代理从发布代理获取原型文章，然后将其转发给版主，或者将其传递给中继代理或服务代理。注射剂对确保其注射的任何物品符合规定负有主要责任
the rules of the Netnews standards. The administrator of an injecting agent is also expected to bear some responsibility towards the rest of the Netnews network to which it is connected for the articles the injecting agent accepts.
网络新闻标准的规则。注入代理的管理员还需要对其所连接的Netnews网络的其余部分承担一些责任，以获取注入代理接受的文章。
Injecting agents, when rejecting articles, are encouraged to communicate the reason for rejection to the posting agent by using whatever facility is provided by the underlying transport. The injecting agent is in a unique position to communicate the reason for rejection; relaying agents and serving agents normally have to reject messages silently. The injecting agent therefore bears much of the burden of diagnosing broken posting agents or communicating policy violations to posters.
当拒收物品时，鼓励注射代理商使用基础运输提供的任何设施将拒收原因告知邮寄代理商。注射剂处于传达拒绝原因的独特位置；中继代理和服务代理通常必须以静默方式拒绝消息。因此，注射剂承担了诊断损坏的投递剂或向海报传达违反政策的信息的大部分责任。
An injecting agent MUST have available a list (possibly empty) of moderated groups for which it accepts articles and the corresponding submission addresses. It SHOULD have available a list of valid newsgroups to catch articles not posted to a valid newsgroup and therefore likely to be silently discarded by relaying and serving agents. Usually, an injecting agent is deployed in conjunction with a serving agent and maintains these lists based on control messages received by the serving agent.
注入代理必须有一个可用的版主组列表（可能为空），它接受文章和相应的提交地址。它应该有一个有效新闻组列表，用于捕获未发布到有效新闻组的文章，因此可能会被中继和服务代理默默丢弃。通常，注入代理与服务代理一起部署，并基于服务代理接收的控制消息维护这些列表。
An injecting agent processes proto-articles as follows:
注射剂按如下方式处理原型物品：
1. It SHOULD verify that the article is from a trusted source (for example, by relying on the authorization capability of the underlying transport used to talk to the posting agent).
1. 它应该验证文章是否来自可信来源（例如，通过依赖用于与发布代理对话的底层传输的授权功能）。
2. It MUST reject any proto-article that does not have the proper mandatory header fields for a proto-article, that has Injection-Info or Xref header fields, that has a Path header field containing the "POSTED" <diag-keyword>, or that is not syntactically valid as defined by [RFC5536]. It SHOULD reject any proto-article that contains a header field deprecated for Netnews (see, for example, [RFC3798]). It MAY reject any proto-article that contains trace header fields (e.g., NNTP-Posting-Host) indicating that it was already injected by an injecting agent that did not add Injection-Info or Injection-Date.
2. 它必须拒绝任何原型项目，这些原型项目没有原型项目的适当强制标题字段、具有注入信息或外部参照标题字段、具有包含“POSTED”<diag keyword>的路径标题字段，或者按照[RFC5536]的定义语法无效。它应该拒绝任何包含Netnews不推荐使用的标题字段的原型文章（例如，请参见[RFC3798]）。它可能会拒绝任何包含跟踪头字段（例如，NNTP POST Host）的原型文章，该字段指示它已被未添加注入信息或注入日期的注入代理注入。
3. It SHOULD reject any article whose Injection-Date or Date header field is more than 24 hours into the future (and MAY use a margin less than 24 hours). It SHOULD reject any article whose Injection-Date header field is too far in the past (older than the cutoff interval of a relaying agent that the injecting agent is using, for example). It SHOULD similarly reject any article whose Date header field is too far in the past, since not all news servers support Injection-Date and only the injecting agent
3. 它应该拒绝任何注入日期或日期标题字段在未来超过24小时的文章（并且可以使用小于24小时的边距）。它应该拒绝任何其注入日期标题字段在过去太远的项目（例如，早于注入代理正在使用的中继代理的截止时间间隔）。同样，它应该拒绝任何日期标题字段在过去太远的文章，因为不是所有新闻服务器都支持注入日期，只有注入代理
can provide a useful error message to the posting agent. In either case, this interval SHOULD NOT be any shorter than 72 hours into the past.
可以向过帐代理提供有用的错误消息。在任何一种情况下，这段时间间隔都不应短于过去的72小时。
4. It SHOULD reject any proto-article whose Newsgroups header field does not contain at least one <newsgroup-name> for a valid group, or that contains a <newsgroup-name> reserved for specific purposes by Section 3.1.4 of [RFC5536] unless that specific purpose or local agreement applies to the proto-article being processed. Crossposting to unknown newsgroups is not precluded provided that at least one of the newsgroups in the Newsgroups header is valid.
4. 除非特定目的或本地协议适用于正在处理的原型文章，否则应拒绝其新闻组标题字段不包含至少一个有效组的<newsgroup name>，或包含[RFC5536]第3.1.4节为特定目的保留的<newsgroup name>。如果新闻组标题中至少有一个新闻组有效，则不排除交叉发布到未知新闻组。
5. The Message-ID and Date header fields with appropriate contents MUST be added when not present in the proto-article.
5. 当原始文章中不存在时，必须添加具有适当内容的消息ID和日期标题字段。
6. The injecting agent MUST NOT alter the body of the article in any way (including any change of Content-Transfer-Encoding). It MAY add other header fields not already provided by the poster, but injecting agents are encouraged to use the Injection-Info header for such information and to minimize the addition of other headers. It SHOULD NOT alter, delete, or reorder any existing header field except the Path header field. It MUST NOT alter or delete any existing Message-ID header field.
6. 注射剂不得以任何方式改变文章正文（包括内容传输编码的任何更改）。它可以添加海报尚未提供的其他标题字段，但鼓励注射代理使用注射信息标题获取此类信息，并尽量减少添加其他标题。它不应更改、删除或重新排序除路径标头字段外的任何现有标头字段。它不能更改或删除任何现有的消息ID头字段。
7. If the Newsgroups header contains one or more moderated groups and the proto-article does not contain an Approved header field, the injecting agent MUST either forward it to a moderator as specified in Section 3.5.1 or, if that is not possible, reject it. This forwarding MUST be done after adding the Message-ID and Date headers if required, and before adding the Injection-Info and Injection-Date headers.
7. 如果新闻组标题包含一个或多个版主组，并且原型文章不包含批准的标题字段，则注射代理必须按照第3.5.1节的规定将其转发给版主，或者，如果不可能，则拒绝该版主。此转发必须在添加消息ID和日期头（如果需要）之后以及添加注入信息和注入日期头之前完成。
8. Otherwise, a Path header field with a <tail-entry> MUST be added if not already present.
8. 否则，如果尚未存在，则必须添加带有<tail entry>的路径头字段。
9. The injecting agent MUST then update the Path header field as described in Section 3.2.1.
9. 然后，注入剂必须按照第3.2.1节所述更新路径头字段。
10. An Injection-Info header field SHOULD be added that identifies the source of the article and possibly other trace information as described in Section 3.2.8 of [RFC5536].
10. 应添加一个注入信息标题字段，用于标识物品的来源以及[RFC5536]第3.2.8节所述的可能的其他跟踪信息。
11. If the proto-article already had an Injection-Date header field, it MUST NOT be modified or replaced. If the proto-article had both a Message-ID header field and a Date header field, an Injection-Date header field MUST NOT be added, since the proto-article may have been multiply injected by a posting agent that
11. 如果原型文章已经有注入日期标题字段，则不能对其进行修改或替换。如果原型文章同时具有消息ID标题字段和日期标题字段，则不得添加注入日期标题字段，因为原型文章可能已由发布代理多次注入，该代理
predates this standard. Otherwise, the injecting agent MUST add an Injection-Date header field containing the current date and time.
早于此标准。否则，注入代理必须添加包含当前日期和时间的注入日期标题字段。
12. Finally, the injecting agent forwards the article to one or more relaying agents, and the injection process is complete.
12. 最后，注射代理将物品转发给一个或多个中继代理，注射过程完成。
An injecting agent MUST forward the proto-article to the moderator of the leftmost moderated group listed in the Newsgroups header field, customarily via email. There are two standard ways in which it may do this:
注入代理必须将原型文章转发给新闻组标题字段中列出的最左侧受版主组的版主，通常通过电子邮件发送。有两种标准的方法可以做到这一点：
1. The complete proto-article is encapsulated, header fields and all, within the email. This SHOULD be done by creating an email message with a Content-Type of application/news-transmission with the usage parameter set to "moderate". The body SHOULD NOT contain any content other than the message. This method has the advantage of removing any possible conflict between Netnews and email header fields and any changes to those fields during transport through email.
1. 完整的原型文章封装在电子邮件中，包括标题字段和所有内容。这应该通过创建一封内容类型为应用程序/新闻传输且使用参数设置为“中等”的电子邮件来实现。正文不应包含消息以外的任何内容。此方法的优点是可以消除Netnews和电子邮件标题字段之间的任何可能冲突，以及在通过电子邮件传输期间对这些字段所做的任何更改。
2. The proto-article is sent as an email with the addition of any header fields required for an email as defined in [RFC5322], and possibly with the addition of other header fields conventional in email, such as To and Received. The existing Message-ID header field SHOULD be retained.
2. 原型文章作为电子邮件发送，添加了[RFC5322]中定义的电子邮件所需的任何标题字段，可能还添加了电子邮件中常规的其他标题字段，如“收件人”和“收到”。应保留现有的邮件ID标头字段。
Although both of these methods have been used in the past and the first has clear technical advantages, the second is in more common use and many moderators are not prepared to deal with messages in the first format. Accordingly, the first method SHOULD NOT be used unless the moderator to which it is being forwarded is known to be able to handle this method.
虽然这两种方法过去都曾使用过，而且第一种方法具有明显的技术优势，但第二种方法更为常用，许多版主不准备处理第一种格式的消息。因此，不应使用第一种方法，除非已知其转发到的主持人能够处理该方法。
NOTE: Deriving the email address of the moderator of a group is outside the scope of this document. It is worth mentioning, however, that a common method is to use a forwarding service that handles submissions for many moderated groups. For maximum compatibility with existing news servers, such forwarding services generally form the submission address for a moderated group by replacing each "." in the <newsgroup-name> with "-" and then using that value as the <local-part> of a <mailbox> formed by appending a set domain.
注意：获取组主持人的电子邮件地址超出了本文档的范围。然而，值得一提的是，一种常见的方法是使用转发服务来处理许多受审核组的提交。为了最大限度地与现有新闻服务器兼容，此类转发服务通常通过将<newsgroup name>中的每个“.”替换为“-”，然后将该值用作通过附加一个设置域而形成的<mailbox>的<local part>，来形成受主持组的提交地址。
Forwarding proto-articles to moderators via email is the most general method and the most common in large Netnews networks such as Usenet, but any means of forwarding the article that preserves it without injecting it MAY be used. For example, if the injecting agent has access to a database used by the moderator to store proto-articles awaiting processing, it may place the proto-article directly into that database. Such methods may be more appropriate for smaller Netnews networks.
通过电子邮件将原始文章转发给版主是最普遍的方法，也是在大型网络新闻网络（如Usenet）中最常见的方法，但是可以使用任何不注入内容而保留原始文章的转发方法。例如，如果注入代理可以访问主持人用来存储等待处理的原型文章的数据库，那么它可以将原型文章直接放入该数据库中。这种方法可能更适合较小的网络新闻网络。
A relaying agent accepts injected articles from injecting and other relaying agents and passes them on to relaying or serving agents. To avoid bypass of injecting agent policies and forgery of Path and Injection-Info headers, relaying agents SHOULD accept articles only from trusted agents.
中继代理接受来自注射和其他中继代理的注射物品，并将其传递给中继代理或服务代理。为了避免绕过注入代理策略以及伪造路径和注入信息头，中继代理应该只接受来自受信任代理的项目。
An article SHOULD NOT be relayed unless the sending agent has been configured to supply, and the receiving agent to receive, at least one of the <newsgroup-name>s in its Newsgroups header field and at least one of the <dist-name>s in its Distribution header field (if present). Exceptionally, control messages creating or removing newsgroups (newgroup or rmgroup control messages, for example) SHOULD be relayed if the affected group appears in its Newsgroups header field and both the sending and receiving relaying agents are configured to relay a newsgroup of that name (whether or not such a newsgroup exists).
除非发送代理已配置为在其新闻组标题字段中提供至少一个<newsgroup name>s，并且在其分发标题字段中提供至少一个<dist name>s（如果存在），否则不应中继文章。例外情况下，如果受影响的组出现在其新闻组标题字段中，并且发送和接收中继代理都配置为中继该名称的新闻组（无论是否存在此类新闻组），则应中继创建或删除新闻组的控制消息（例如，newgroup或rmgroup控制消息）。
In order to avoid unnecessary relaying attempts, an article SHOULD NOT be relayed if the <path-identity> of the receiving agent (or some known alias thereof) appears as a <path-identity> (excluding within the <tail-entry> or following a "POSTED" <diag-keyword>) in its Path header field.
为了避免不必要的中继尝试，如果接收代理（或其某些已知别名）的<path identity>在其路径头字段中显示为<path identity>（不包括在<tail entry>内或在“POSTED”<diag keyword>之后），则不应中继文章。
A relaying agent processes an article as follows:
中继代理按如下方式处理物品：
1. It MUST reject any article without a Newsgroups header field or Message-ID header field, or without either an Injection-Date or Date header field.
1. 它必须拒绝任何没有新闻组标题字段或消息ID标题字段，或没有注入日期或日期标题字段的文章。
2. It MUST examine the Injection-Date header field or, if absent, the Date header field, and reject the article if that date is more than 24 hours into the future. It MAY reject articles with dates in the future with a smaller margin than 24 hours.
2. 它必须检查注入日期标题字段，如果没有，则检查日期标题字段，如果该日期超过24小时，则拒绝该文章。它可能会拒绝日期在未来小于24小时的文章。
3. It MUST reject any article that has already been accepted. If it implements one of the mechanisms described in Section 3.3, this means that it MUST reject any article whose date falls outside the cutoff interval since it won't know whether or not such articles had been accepted previously.
3. 它必须拒绝任何已经被接受的物品。如果它实现了第3.3节中描述的机制之一，这意味着它必须拒绝任何日期超出截止时间间隔的物品，因为它不知道之前是否接受过此类物品。
4. It SHOULD reject any article that does not include all the mandatory header fields. It MAY reject any article that contains header fields that do not have valid contents.
4. 它应该拒绝任何不包含所有必需标题字段的文章。它可能会拒绝包含没有有效内容的标题字段的任何文章。
5. It SHOULD reject any article that matches an already-received cancel control message or the contents of the Supersedes header field of an accepted article, provided that the relaying agent has chosen (on the basis of local site policy) to honor that cancel control message or Supersedes header field.
5. 如果中继代理选择（根据本地站点策略）接受取消控制消息或取代标题字段，则应拒绝任何与已接收的取消控制消息或已接受文章的取代标题字段内容相匹配的文章。
6. It MAY reject any article without an Approved header field posted to a newsgroup known to be moderated. This practice is strongly encouraged, but the information necessary to do so is not required to be maintained by a relaying agent.
6. 它可能会拒绝任何未经批准的标题字段发布到已知被主持的新闻组的文章。强烈鼓励这种做法，但不要求中继代理维护这样做所需的信息。
7. It MUST update the Path header field as described in Section 3.2.1.
7. 它必须按照第3.2.1节所述更新路径头字段。
8. It MAY delete any Xref header field already present. It MAY add a new Xref header field for its own use (but recall that [RFC5536] permits at most one such header field).
8. 它可以删除任何已存在的外部参照标题字段。它可以添加一个新的外部参照标头字段供自己使用（但请记住，[RFC5536]最多允许一个这样的标头字段）。
9. Finally, it passes the article on to other relaying and serving agents to which it is configured to send articles.
9. 最后，它将文章传递给其他中继和服务代理，并将其配置为向其发送文章。
Relaying agents SHOULD, where possible in the underlying transport, inform the agent that passed the article to the relaying agent if the article was rejected. Relaying agents MUST NOT inform any other external entity of the rejection of an article unless that external entity has explicitly requested that it be informed of such errors.
如果物品被拒绝，中继代理应尽可能在基础运输中通知将物品传递给中继代理的代理。中继代理不得将物品拒收通知任何其他外部实体，除非该外部实体明确要求将此类错误通知其。
Relaying agents MUST NOT alter, delete, or rearrange any part of an article except for the Path and Xref header fields. They MUST NOT modify the body of articles in any way. If an article is not acceptable as is, the article MUST be rejected rather than modified.
中继代理不得更改、删除或重新排列项目的任何部分，路径和外部参照标题字段除外。他们不得以任何方式修改文章正文。如果某一条款不能被接受，则该条款必须被拒绝，而不是修改。
A serving agent accepts articles from a relaying agent or injecting agent, stores them, and makes them available to reading agents. Articles are normally indexed by newsgroup and <article-locator> (Section 3.2.14 of [RFC5536]), usually in the form of a decimal number.
服务代理从中继代理或注射代理接收文章，存储它们，并使它们可供阅读代理使用。文章通常由新闻组和<article locator>（RFC5536第3.2.14节）编制索引，通常以十进制数字的形式。
If the serving agent stores articles by newsgroup, control messages SHOULD NOT be stored in the newsgroups listed in the control message's Newsgroups header field. Instead, they SHOULD be stored in a newsgroup in the hierarchy "control", which is reserved for this purpose. Conventionally, control messages are stored in newsgroups named for the type of control message (such as "control.cancel" for cancel control messages).
如果服务代理按新闻组存储文章，则控制消息不应存储在控制消息的新闻组标题字段中列出的新闻组中。相反，它们应该存储在层次结构“control”中的新闻组中，该层次结构是为此而保留的。按照惯例，控制消息存储在以控制消息类型命名的新闻组中（例如，取消控制消息的“control.cancel”）。
A serving agent MUST have available a list (possibly empty) of moderated groups for which it accepts articles so that it can reject unapproved articles posted to moderated groups. Frequently, a serving agent is deployed in combination with an injecting agent and can use the same list as the injecting agent.
服务代理必须有一个可用的版主组列表（可能为空），以便它可以拒绝发布到版主组的未经批准的文章。通常，服务代理与注入代理一起部署，并且可以使用与注入代理相同的列表。
A serving agent processes articles as follows:
服务代理按如下方式处理物品：
1. It MUST reject any article that does not include all the mandatory header fields or any article that contains header fields that do not have valid contents.
1. 它必须拒绝任何不包含所有必需标题字段的文章，或拒绝任何包含没有有效内容的标题字段的文章。
2. It MUST examine the Injection-Date header field or, if absent, the Date header field, and reject the article if that date is more than 24 hours into the future. It MAY reject articles with dates in the future with a smaller margin than 24 hours.
2. 它必须检查注入日期标题字段，如果没有，则检查日期标题字段，如果该日期超过24小时，则拒绝该文章。它可能会拒绝日期在未来小于24小时的文章。
3. It MUST reject any article that has already been accepted. If it implements one of the mechanisms described in Section 3.3, this means that it MUST reject any article whose date falls outside the cutoff interval since it won't know whether or not such articles had been accepted previously.
3. 它必须拒绝任何已经被接受的物品。如果它实现了第3.3节中描述的机制之一，这意味着它必须拒绝任何日期超出截止时间间隔的物品，因为它不知道之前是否接受过此类物品。
4. It SHOULD reject any article that matches an already-received and honored cancel message or Supersedes header field, following the same rules as a relaying agent (Section 3.6).
4. 它应该拒绝任何与已接收和接收的取消消息相匹配的文章，或者取代标题字段，遵循与中继代理相同的规则（第3.6节）。
5. It MUST reject any article without an Approved header field posted to any newsgroup listed as moderated.
5. 它必须拒绝任何未经批准的标题字段发布到任何列为版主的新闻组的文章。
6. It MUST update the Path header field as described in Section 3.2.1.
6. 它必须按照第3.2.1节所述更新路径头字段。
7. It MUST remove any Xref header field from each article (except when specially configured to preserve the <article-locator>s set by the sending site). It then MAY (and usually will) add a new Xref header field (but recall that [RFC5536] permits at most one such header field).
7. 它必须从每篇文章中删除任何外部参照标题字段（除非专门配置为保留发送站点设置的<article locator>s）。然后，它可能（并且通常会）添加一个新的外部参照标头字段（但请记住，[RFC5536]最多允许一个这样的标头字段）。
8. Finally, it stores the article and makes it available for reading agents.
8. 最后，它存储文章并使其可供阅读代理使用。
Serving agents MUST NOT create new newsgroups simply because an unrecognized <newsgroup-name> occurs in a Newsgroups header field. Newsgroups are normally created via control messages (Section 5.2.1).
服务代理不能仅仅因为在新闻组标题字段中出现无法识别的<newsgroup name>而创建新的新闻组。新闻组通常通过控制消息创建（第5.2.1节）。
Serving agents MUST NOT alter, delete, or rearrange any part of an article except for the Path and Xref header fields. They MUST NOT modify the body of the articles in any way. If an article is not acceptable as is, the article MUST be rejected rather than modified.
服务代理不得更改、删除或重新排列文章的任何部分，路径和外部参照标题字段除外。他们不得以任何方式修改条款正文。如果某一条款不能被接受，则该条款必须被拒绝，而不是修改。
Since a reading agent is only a passive participant in a Netnews network, there are no specific protocol requirements placed on it. See [USEAGE] for best-practice recommendations.
由于阅读代理只是Netnews网络中的被动参与者，因此对其没有特定的协议要求。有关最佳实践建议，请参见[使用]。
A moderator receives news articles, customarily by email, decides whether to approve them and, if so, either passes them to an injecting agent or forwards them to further moderators.
版主通常通过电子邮件接收新闻文章，决定是否批准这些文章，如果批准，则将其传递给注射剂或转发给其他版主。
Articles are normally received by the moderator in email, either encapsulated as an object of Content-Type application/ news-transmission (or possibly encapsulated but without an explicit Content-Type header field) or else directly as an email already containing all the header fields appropriate for a Netnews article (see Section 3.5.1). Moderators who may receive articles via email SHOULD be prepared to accept articles in either format.
文章通常由主持人通过电子邮件接收，或者封装为内容类型应用程序/新闻传输的对象（或者可能封装但没有明确的内容类型标题字段），或者直接作为电子邮件接收，该电子邮件已经包含适用于Netnews文章的所有标题字段（参见第3.5.1节）。可能通过电子邮件接收文章的版主应准备接受任何一种格式的文章。
There are no protocol restrictions on what criteria are used for accepting or rejecting messages or on what modifications a moderator may make to a message (both header fields and body) before injecting it. Recommended best practice, however, is to make the minimal required changes. Moderators need to be aware that modifications made to articles may invalidate signatures created by the poster or previous moderators. See [USEAGE] for further best-practice recommendations.
对于接受或拒绝消息所使用的标准，或者在注入消息之前主持人可能对消息（头字段和正文）进行的修改，没有协议限制。然而，推荐的最佳实践是进行所需的最小更改。版主需要注意，对文章的修改可能会使海报或以前版主创建的签名无效。有关进一步的最佳实践建议，请参见[使用]。
Moderators process articles as follows:
版主按如下方式处理文章：
1. They decide whether to approve or reject a proto-article and, if approved, prepare the proto-article for injection. If the proto-article was received as an unencapsulated email message, this will require converting it back to a valid Netnews proto-article. If the article is rejected, it is normally rejected for all newsgroups to which it was posted and nothing further is done. If it is approved, the moderator proceeds with the following steps.
1. 他们决定是否批准或拒绝原型物品，如果批准，则准备用于注射的原型物品。如果原始文章作为未封装的电子邮件收到，则需要将其转换回有效的Netnews原始文章。如果文章被拒绝，它通常会被发布到的所有新闻组拒绝，并且不会做任何进一步的操作。如果获得批准，主持人将继续执行以下步骤。
2. If the Newsgroups header field contains further moderated newsgroups for which approval has not already been given, they may either reach some agreement with the other moderators on the disposition of the article or, more generally, add an indication (identifying both the moderator and the name of the newsgroup) that they approve the article and then forward it to the moderator of the leftmost unapproved newsgroup. This forwarding SHOULD be done following the procedure in Section 3.5.1. It MAY be done by rotating the <newsgroup-name>s in the Newsgroups header field so that the leftmost unapproved newsgroup is the leftmost moderated newsgroup in that field and then posting it, letting the injecting agent do the forwarding. However, when using this mechanism, they MUST first ensure that the article contains no Approved header field.
2. 如果“新闻组标题”字段包含尚未获得批准的其他主持人新闻组，则他们可以与其他主持人就文章的处理达成某种协议，或者更一般地说，添加一个指示（标识主持人和新闻组的名称）他们批准该文章，然后将其转发给最左边未经批准的新闻组的主持人。该转发应按照第3.5.1节中的程序进行。可以通过旋转新闻组标题字段中的<newsgroup name>s来完成，这样最左边的未批准新闻组就是该字段中最左边的受限制新闻组，然后将其发布，让注入代理进行转发。但是，在使用此机制时，他们必须首先确保文章不包含已批准的标题字段。
3. If the Newsgroups header field contains no further unapproved moderated groups, they add an Approved header field (see Section 3.2.1 of [RFC5536]) identifying the moderator and, insofar as is possible, all the other moderators who have approved the article. The moderator who takes this step assumes responsibility for ensuring that the article was approved by the moderators of all moderated newsgroups to which it was posted.
3. 如果新闻组标题字段不包含其他未经批准的版主组，则新闻组会添加一个已批准的标题字段（见[RFC5536]第3.2.1节），以识别版主，并尽可能识别已批准文章的所有其他版主。采取这一步骤的版主负责确保文章被发布到的所有版主新闻组的版主批准。
4. Moderators are encouraged to retain the Message-ID header field unless it is invalid or the article was significantly changed from its original form. Moderators are also encouraged to retain the Date header field unless it appears to be stale (72 hours or more in the past) for reasons understood by the moderator (such as delays in the moderation process), in which case they MAY substitute the current date. Any Injection-Date, Injection-Info, or Xref header fields already present MUST be removed.
4. 建议版主保留消息ID标题字段，除非该字段无效或文章与原始形式相比发生了重大变化。还鼓励版主保留日期标题字段，除非该字段因版主理解的原因（如版主过程中的延迟）而过时（过去为72小时或更长），在这种情况下，版主可以替换当前日期。必须删除已存在的任何注入日期、注入信息或外部参照标题字段。
5. Any Path header field MUST either be removed or truncated to only those entries following its "POSTED" <diag-keyword>, if any.
5. 必须删除或截断任何路径头字段，使其仅包含“POSTED”<diag keyword>后面的条目（如果有）。
6. The moderator then passes the article to an injecting agent, having first observed all the duties of a posting agent.
6. 然后，版主将文章传递给一个注射剂，首先观察了发帖剂的所有职责。
A gateway transforms an article into the native message format of another medium, or translates the messages of another medium into news articles, or transforms articles into proto-articles for injection into a separate Netnews network. Encapsulation of a news article into a message of MIME type application/news-transmission, or the subsequent undoing of that encapsulation, is not gatewaying since it involves no transformation of the article.
网关将文章转换为另一种媒体的本机消息格式，或将另一种媒体的消息转换为新闻文章，或将文章转换为原型文章，以便注入到单独的Netnews网络中。将新闻文章封装到MIME类型的消息应用程序/新闻传输中，或随后撤销该封装，不是网关，因为它不涉及文章的转换。
There are two basic types of gateway, the outgoing gateway that transforms a news article into a different type of message, and the incoming gateway that transforms a message from another network into a news proto-article and injects it into a Netnews network. These are handled separately below.
网关有两种基本类型，一种是将新闻文章转换为不同类型消息的传出网关，另一种是将来自另一个网络的消息转换为新闻原型文章并将其注入Netnews网络的传入网关。下面分别处理这些问题。
Transformation of an article into another medium stands a very high chance of discarding or interfering with the protection inherent in the news system against duplicate articles. The most common problem caused by gateways is loops that repeatedly reinject previously posted articles. To prevent this, a gateway MUST take precautions against loops, as detailed below.
将一篇文章转换成另一种媒体很有可能会放弃或干扰新闻系统对重复文章的固有保护。网关引起的最常见问题是循环，它会重复地重新注入以前发布的文章。为了防止这种情况发生，网关必须对环路采取预防措施，如下所述。
The transformations applied to the message SHOULD be as minimal as possible while still accomplishing the gatewaying. Every change made by a gateway potentially breaks a property of one of the media or loses information, and therefore only those transformations made necessary by the differences between the media should be applied.
应用于消息的转换应该尽可能少，同时仍然完成网关。网关所做的每一次更改都可能会破坏其中一种媒体的属性或丢失信息，因此只应应用因媒体之间的差异而进行的必要转换。
If bidirectional gatewaying (both an incoming and an outgoing gateway) is being set up between Netnews and some other medium, the incoming and outgoing gateways SHOULD be coordinated to avoid unintended reinjection of gated articles. Circular gatewaying (gatewaying a message into another medium and then back into Netnews) SHOULD NOT be done; encapsulation of the article SHOULD be used instead where this is necessary.
如果在Netnews和某些其他媒体之间设置双向网关（传入和传出网关），则应协调传入和传出网关，以避免意外地重新注入被屏蔽的文章。不应进行循环网关（将消息网关到另一种媒体，然后再返回到Netnews）；在必要的情况下，应该使用文章的封装。
Safe bidirectional gatewaying between a mailing list and a newsgroup is far easier if the newsgroup is moderated. Posts to the moderated group and submissions to the mailing list can then go through a single point that does the necessary gatewaying and then sends the message out to both the newsgroup and the mailing list at the same time, eliminating most of the possibility of loops. Bidirectional gatewaying between a mailing list and an unmoderated newsgroup, in contrast, is difficult to do correctly and is far more fragile. Newsgroups intended to be bidirectionally gated to a mailing list SHOULD therefore be moderated where possible, even if the moderator
如果对新闻组进行调节，邮件列表和新闻组之间的安全双向网关就容易得多。然后，向受主持组发送的帖子和向邮件列表提交的内容可以通过一个点进行必要的网关，然后同时将消息发送到新闻组和邮件列表，从而消除了大部分循环的可能性。相比之下，邮件列表和未减额新闻组之间的双向网关很难正确实现，而且要脆弱得多。因此，在可能的情况下，应该对双向进入邮件列表的新闻组进行审核，即使审核人
is a simple gateway and injecting agent that correctly handles crossposting to other moderated groups and otherwise passes all traffic.
是一个简单的网关和注入代理，可以正确处理到其他受控制组的交叉发布，并以其他方式传递所有流量。
From the perspective of Netnews, an outgoing gateway is just a special type of reading agent. The exact nature of what the outgoing gateway will need to do to articles depends on the medium to which the articles are being gated. Because it raises the danger of loops due to the possibility of one or more corresponding incoming gateways back from that medium to Netnews, the operation of the outgoing gateway is subject to additional constraints.
从Netnews的角度来看，传出网关只是一种特殊类型的阅读代理。传出网关需要对文章执行的操作的确切性质取决于文章被选入的媒介。由于可能有一个或多个对应的传入网关从该媒体返回到Netnews，这会增加循环的危险，因此传出网关的操作受到其他限制。
The following practices are encouraged for all outgoing gateways, regardless of whether there is known to be a related incoming gateway, both as precautionary measures and as guidelines to quality of implementation:
鼓励所有传出网关采用以下做法，无论是否已知存在相关的传入网关，作为预防措施和实施质量指南：
1. The message identifier of the news article should be preserved if at all possible, preferably as or within the corresponding unique identifier of the other medium. However, if it is not preserved in this way, then at least it should be preserved as a comment in the message. This helps greatly with preventing loops.
1. 新闻文章的消息标识符应尽可能保留，最好作为或在另一媒体的相应唯一标识符内。但是，如果它不是以这种方式保留的，那么至少应该将它作为注释保留在消息中。这大大有助于防止循环。
2. The Date and Injection-Date of the news article should also be preserved if possible, for similar reasons.
2. 出于类似原因，如果可能，新闻文章的日期和注入日期也应保留。
3. The message should be tagged in some way so as to prevent its reinjection into Netnews. This may be impossible to do without knowledge of potential incoming gateways, but it is better to try to provide some indication even if not successful; at the least, a human-readable indication that the article should not be gated back to Netnews can help locate a human problem.
3. 应该以某种方式对消息进行标记，以防止其重新注入Netnews。如果不了解潜在的传入网关，这可能是不可能的，但最好尝试提供一些指示，即使不成功；至少，一个人类可读的指示，即该文章不应被限制回Netnews，可以帮助定位人类问题。
4. Netnews control messages should not be gated to another medium unless they would somehow be meaningful in that medium.
4. Netnews控制消息不应被选通到其他媒体，除非它们在该媒体中有意义。
The incoming gateway has the responsibility of ensuring that all of the requirements of this protocol are met by the articles that it forms. In addition to its special duties as a gateway, it bears all of the duties and responsibilities of a posting agent, and it has the same responsibility of a relaying agent to reject articles that it has already gatewayed.
传入网关有责任确保其形成的条款满足本协议的所有要求。除了作为网关的特殊职责外，它还承担邮寄代理的所有职责和责任，并且它与中转代理有相同的责任拒绝它已经通过网关的物品。
An incoming gateway MUST NOT gate the same message twice. It may not be possible to ensure this in the face of mangling or modification of the message, but at the very least a gateway, when given a copy of a message that it has already gated and that is identical except for trace header fields (like Received in Email or Path in Netnews), MUST NOT gate the message again. An incoming gateway SHOULD take precautions against having this rule bypassed by modifications of the message that can be anticipated.
传入网关不能对同一消息进行两次选通。在邮件被损坏或修改时，可能无法确保这一点，但至少网关在收到一份已被屏蔽的邮件副本时，除了跟踪头字段（如电子邮件中接收的邮件或Netnews中的路径）外，不得再次屏蔽邮件。传入网关应采取预防措施，防止由于可能预期的消息修改而绕过此规则。
News articles prepared by gateways MUST be valid news proto-articles (see Section 3.4.1). This often requires the gateway to synthesize a conforming article from non-conforming input. The gateway MUST then pass the article to an injecting agent, not directly to a relaying agent.
网关准备的新闻文章必须是有效的新闻原型文章（见第3.4.1节）。这通常需要网关从不一致的输入合成一致的物品。然后，网关必须将文章传递给注入代理，而不是直接传递给中继代理。
Incoming gateways MUST NOT pass control messages (articles containing a Control or Supersedes header field) without removing or renaming that header field. Gateways MAY, however, generate cancel control messages for messages they have gatewayed. If a gateway receives a message that it can determine is a valid equivalent of a cancel control message in the medium it is gatewaying, it SHOULD discard that message without gatewaying it, generate a corresponding cancel control message of its own, and inject that cancel control message.
传入网关在未删除或重命名该标头字段的情况下，不得传递控制消息（包含控件或取代标头字段的项目）。但是，网关可能会为其已网关化的消息生成取消控制消息。如果网关接收到一条消息，它可以确定该消息在它正在网关化的介质中是有效的取消控制消息等价物，那么它应该放弃该消息而不网关化它，生成自己的相应取消控制消息，并注入该取消控制消息。
NOTE: It is not unheard of for mail-to-news gateways to be used to post control messages, but encapsulation should be used for these cases instead. Gateways by their very nature are particularly prone to loops. Spews of normal articles are bad enough; spews of control messages with special significance to the news system, possibly resulting in high processing load or even in emails being sent for every message received, are catastrophic. It is far preferable to construct a system specifically for posting control messages that can do appropriate consistency checks and authentication of the originator of the message.
注意：邮件到新闻网关用于发布控制消息并非闻所未闻，但在这些情况下应该使用封装。网关就其本质而言，特别容易出现环路。正常物品的喷溅已经够糟糕的了；对新闻系统具有特殊意义的控制消息的喷发，可能会导致高处理负载，甚至每收到一条消息都会发送电子邮件，这是灾难性的。最好是构建一个专门用于发布控制消息的系统，该系统可以对消息的发起人进行适当的一致性检查和身份验证。
If there is a message identifier that fills a role similar to that of the Message-ID header field in news, it SHOULD be used in the formation of the message identifier of the news article, perhaps with transformations required to meet the uniqueness requirement of Netnews and with the removal of any comments so as to comply with the syntax in Section 3.1.3 of [RFC5536]. Such transformations SHOULD be designed so that two messages with the same identifier generate the same Message-ID header field.
如果有一个消息标识符填充了一个类似于新闻中消息ID头字段的角色，则应在形成新闻文章的消息标识符时使用该标识符，可能需要进行转换以满足Netnews的唯一性要求，并删除任何注释，以符合[RFC5536]第3.1.3节中的语法。此类转换的设计应确保具有相同标识符的两条消息生成相同的消息ID头字段。
NOTE: Message identifiers play a central role in the prevention of duplicates, and their correct use by gateways will do much to prevent loops. Netnews does, however, require that message identifiers be unique, and therefore message identifiers from
注意：消息标识符在防止重复中起着核心作用，网关正确使用它们将大大防止循环。然而，Netnews确实要求消息标识符是唯一的，因此消息标识符来自
other media may not be suitable for use without modification. A balance must be struck by the gateway between preserving information used to prevent loops and generating unique message identifiers.
未经修改，其他介质可能不适合使用。网关必须在保留用于防止循环的信息和生成唯一消息标识符之间取得平衡。
Exceptionally, if there are multiple incoming gateways for a particular set of messages, each to a different newsgroup(s), each one SHOULD generate a message identifier unique to that gateway. Each incoming gateway nonetheless MUST ensure that it does not gate the same message twice.
例外情况下，如果一组特定消息有多个传入网关，每个网关指向不同的新闻组，则每个网关都应生成该网关唯一的消息标识符。然而，每个传入网关必须确保它不会对同一消息进行两次网关。
NOTE: Consider the example of two gateways of a given mailing list into two separate Usenet newsgroups, both of which preserve the email message identifier. Each newsgroup may then receive a portion of the messages (different sites seeing different portions). In these cases, where there is no one "official" gateway, some other method of generating message identifiers has to be used to avoid collisions. It would obviously be preferable for there to be only one gateway that crossposts, but this may not be possible to coordinate.
注意：将给定邮件列表中的两个网关的示例考虑为两个单独的USENET新闻组，它们都保存电子邮件消息标识符。然后，每个新闻组可以接收部分消息（不同的站点看到不同的部分）。在这些情况下，如果没有一个“官方”网关，则必须使用其他生成消息标识符的方法来避免冲突。显然，最好只有一个网关可以跨越，但这可能无法协调。
If no date information is available, the gateway MAY supply a Date header field with the gateway's current date. If only partial information is available (such as date but not time), this SHOULD be fleshed out to a full Date by adding default values rather than by discarding this information. Only in very exceptional circumstances should Date information be discarded, as it plays an important role in preventing reinjection of old messages.
如果没有可用的日期信息，网关可能会提供带有网关当前日期的日期标题字段。如果只有部分信息可用（例如日期而不是时间），则应通过添加默认值而不是放弃此信息来充实到完整日期。只有在非常特殊的情况下才应丢弃日期信息，因为它在防止旧消息重新注入方面起着重要作用。
An incoming gateway MUST add a Sender header field to the news article it forms by containing the <mailbox> of the administrator of the gateway. Problems with the gateway may be reported to this <mailbox>. The <display-name> portion of this <mailbox> SHOULD indicate that the entity responsible for injection of the message is a gateway. If the original message already had a Sender header field, it SHOULD be renamed to Original-Sender so that its contents can be preserved. See Section 3.10.3 for the specification of that header field.
传入网关必须通过包含网关管理员的<mailbox>向其形成的新闻文章添加发件人标题字段。网关问题可能会报告到此<mailbox>。此<mailbox>的<display name>部分应指示负责消息注入的实体是网关。如果原始邮件已有发件人标头字段，则应将其重命名为原始发件人，以便保留其内容。有关该标题字段的规范，请参见第3.10.3节。
The Original-Sender header field holds the content of a Sender header field in an original message received by an incoming gateway, preserving it while the incoming gateway adds its own Sender header field. The content syntax makes use of syntax defined in [RFC5536] and [RFC5322].
原始发件人标头字段保存传入网关接收的原始邮件中发件人标头字段的内容，在传入网关添加自己的发件人标头字段时保留该字段。内容语法使用[RFC5536]和[RFC5322]中定义的语法。
header =/ Original-Sender-header Original-Sender-header = "Original-Sender" ":" SP Original-Sender-content Original-Sender-content = mailbox
header=/Original Sender header Original Sender header=“Original Sender”“：“SP Original Sender content Original Sender content=邮箱
The Permanent Message Header Field Repository entry for this header field is:
此标头字段的永久邮件标头字段存储库条目为：
Header field name: Original-Sender
Applicable protocol: Netnews
Status: standard
Author/Change controller: IETF
Specification document(s): RFC 5537
Header field name: Original-Sender
Applicable protocol: Netnews
Status: standard
Author/Change controller: IETF
Specification document(s): RFC 5537
To illustrate the type of precautions that should be taken against loops, here is an example of the measures taken by one particular combination of mail-to-news and news-to-mail gateways designed to handle bidirectional gatewaying between mailing lists and unmoderated groups:
为了说明针对循环应采取的预防措施类型，以下是邮件到新闻和新闻到邮件网关的一个特定组合所采取的措施示例，该组合旨在处理邮件列表和未减额组之间的双向网关：
1. The news-to-mail gateway preserves the message identifier of the news article in the generated email message. The mail-to-news gateway likewise preserves the email message identifier, provided that it is syntactically valid for Netnews. This allows the news system's built-in suppression of duplicates to serve as the first line of defense against loops.
1. “新闻到邮件”网关在生成的电子邮件中保留新闻文章的消息标识符。邮件到新闻网关同样保留电子邮件消息标识符，前提是它在语法上对Netnews有效。这使得新闻系统内置的复制抑制功能可以作为抵御循环的第一道防线。
2. The news-to-mail gateway adds an X-* header field to all messages it generates. The mail-to-news gateway discards any incoming messages containing this header field. This is robust against mailing list managers that replace the message identifier and against any number of email hops, provided that the other message header fields are preserved.
2. “新闻到邮件”网关将X-*标题字段添加到它生成的所有邮件中。邮件到新闻网关将丢弃包含此标头字段的任何传入邮件。这对于替换消息标识符的邮件列表管理器和任意数量的电子邮件跃点都很有效，前提是保留了其他消息头字段。
3. The mail-to-news gateway prepends the host name from which it received the email message to the content of the Path header field. The news-to-mail gateway refuses to gateway any message that contains the list server name in its Path header field (including in the tail section). This is robust against any amount of munging of the message header fields by the mailing list, provided that the email only goes through one hop.
3. 邮件到新闻网关将接收电子邮件的主机名前置到路径头字段的内容中。“新闻到邮件”网关拒绝将任何在其路径头字段（包括在尾部）中包含列表服务器名称的邮件作为网关。如果电子邮件只经过一个跃点，那么这对于邮件列表对消息头字段的任意数量的咀嚼都是健壮的。
4. The mail-to-news gateway is designed never to generate bounces to the envelope sender. Instead, articles that are rejected by the news server (for reasons not warranting silent discarding of the message) result in a bounce message sent to an errors address that is known not to forward to any mailing lists. In this way, they can be handled by the news administrators.
4. “邮件到新闻”网关的设计决不会向信封发送者产生回跳。相反，新闻服务器拒绝的文章（由于不保证无提示丢弃邮件的原因）会导致跳转邮件发送到错误地址，而已知该地址不会转发到任何邮件列表。这样，新闻管理员就可以处理它们。
These precautions have proven effective in practice at preventing loops for this particular application (bidirectional gatewaying between mailing lists and locally distributed newsgroups where both gateways can be designed together). General gatewaying to world-wide newsgroups poses additional difficulties; one must be very wary of strange configurations, such as a newsgroup gated to a mailing list that is in turn gated to a different newsgroup.
实践证明，这些预防措施在防止此特定应用程序的循环方面是有效的（邮件列表和本地分发的新闻组之间的双向网关，其中两个网关可以一起设计）。通往全球新闻组的一般网关带来了额外的困难；人们必须非常小心奇怪的配置，例如，一个被封入邮件列表的新闻组又被封入另一个新闻组。
This document defines several media types, which have been registered with IANA as provided for in [RFC4288].
本文件定义了几种媒体类型，这些媒体类型已按照[RFC4288]的规定在IANA注册。
The media type message/news, as previously registered with IANA, is hereby declared obsolete. The intent of this media type was to define a standard way of transmitting news articles via mail for human reading. However, it was never widely implemented, and its default treatment as application/octet-stream by agents that did not recognize it was counter-productive. The media type message/rfc822 (defined in Section 5.2.1 of [RFC2046]) SHOULD be used in its place.
先前在IANA注册的媒体类型消息/新闻在此宣布作废。这种媒体类型的目的是定义一种通过邮件发送新闻文章供人阅读的标准方式。然而，它从未被广泛地实现过，不认识它的代理将其默认处理为application/octet流会适得其反。应使用媒体类型消息/rfc822（在[RFC2046]第5.2.1节中定义）代替它。
The updated MIME media type definition of message/news is:
消息/新闻的更新MIME媒体类型定义为：
MIME type name: message
MIME类型名称：消息
MIME subtype name: news
MIME子类型名称：新闻
Required parameters: none
所需参数：无
Optional parameters: none
可选参数：无
Encoding considerations: same as message/rfc822
编码注意事项：与message/rfc822相同
Security considerations: News articles may constitute "control messages", which can have effects on a host's news system beyond just addition of information. Since control messages may occur in normal news flow, most hosts are suitably defended against undesired effects already, but transmission of news articles via mail may bypass
安全注意事项：新闻文章可能构成“控制消息”，除了添加信息外，还可能对主持人的新闻系统产生影响。由于控制消息可能发生在正常的新闻流中，因此大多数主机已经能够适当地抵御不希望出现的影响，但通过邮件传输新闻文章可能会绕过
firewall-type defenses. Reading a news article transmitted by mail involves no hazards beyond those of mail, but submitting it to news software for processing should be done with care.
防火墙类型的防御。阅读通过邮件发送的新闻文章除了邮件之外没有其他危险，但将其提交给新闻软件进行处理时应小心。
Interoperability considerations: Rarely used, and therefore often handled as application/octet-stream. Disposition should by default be inline.
互操作性注意事项：很少使用，因此通常作为应用程序/八位字节流处理。默认情况下，处置应该是内联的。
Published specification: RFC 5537
已发布规范：RFC 5537
Applications that use this media type: Some old mail and news user agents.
使用此媒体类型的应用程序：一些旧的邮件和新闻用户代理。
Intended usage: OBSOLETE
预期用途：过时
Author: Henry Spencer
作者：亨利·斯宾塞
Change controller: IETF
更改控制器：IETF
The media type application/news-transmission is intended for the encapsulation of complete news articles where the intention is that the recipient should then inject them into Netnews. This application type provides one of the methods for mailing articles to moderators (see Section 3.5.1) and may be used to convey messages to an injecting agent. This encapsulation removes the need to transform an email message into a Netnews proto-article and provides a way to send a Netnews article using MIME through a transport medium that does not support 8bit data.
媒体类型应用程序/新闻传输旨在封装完整的新闻文章，目的是接收者随后将其注入Netnews。此应用程序类型提供了将文章邮寄给版主的方法之一（见第3.5.1节），并可用于将消息传递给注入代理。这种封装消除了将电子邮件转换为Netnews原型文章的需要，并提供了通过不支持8位数据的传输介质使用MIME发送Netnews文章的方法。
The MIME media type definition of application/news-transmission is:
应用程序/新闻传输的MIME媒体类型定义为：
MIME type name: application
MIME类型名称：应用程序
MIME subtype name: news-transmission
MIME子类型名称：新闻传输
Required parameters: none
所需参数：无
Optional parameters: One and only one of "usage=moderate", "usage=inject", or "usage=relay".
可选参数：“使用=中等”、“使用=注入”或“使用=中继”中的一个且仅一个。
Encoding considerations: A transfer-encoding different from that of the article transmitted MAY be supplied to ensure correct transmission over some 7bit transport medium.
编码注意事项：可提供不同于所传输物品的传输编码，以确保在某些7比特传输介质上正确传输。
Security considerations: News articles may constitute "control messages", which can have effects on a host's news system beyond just addition of information. Since control messages may occur in normal news flow, most hosts are suitably defended against undesired effects already, but transmission of news articles via mail may bypass firewall-type defenses.
安全注意事项：新闻文章可能构成“控制消息”，除了添加信息外，还可能对主持人的新闻系统产生影响。由于控制消息可能发生在正常的新闻流中，因此大多数主机都已经针对不希望的影响进行了适当的防御，但通过邮件传输新闻文章可能会绕过防火墙类型的防御。
Published specification: RFC 5537
已发布规范：RFC 5537
Body part: A complete proto-article ready for injection into Netnews or an article being relayed to another agent.
正文部分：一篇完整的原型文章，准备注入Netnews或一篇转发给另一个代理的文章。
Applications that use this media type: Injecting agents, Netnews moderators.
使用此媒体类型的应用程序：注入代理、Netnews版主。
Intended usage: COMMON
预期用途：普通
Change controller: IETF
更改控制器：IETF
usage=moderate indicates the article is intended for a moderator, usage=inject for an injecting agent, and usage=relay for a relaying agent. The entity receiving the article may only implement one type of agent, in which case the parameter MAY be omitted.
usage=mediate表示文章是针对版主的，usage=inject表示注入代理，usage=relay表示中继代理。接收物品的实体只能实现一种类型的代理，在这种情况下，可以省略参数。
Contrary to the prior registration of this media type, article batches are not permitted as a body part. Multiple messages or a message with multiple application/news-transmission parts may be used instead.
与此介质类型的事先注册相反，不允许将物品批次作为主体部分。可以使用多条消息或具有多个应用程序/新闻传输部分的消息。
The application/news-groupinfo media type is used in conjunction with the newgroup control message (see Section 5.2.1). Its body part contains brief information about a newsgroup: the newsgroup name, its description, and its moderation status.
应用程序/新闻组信息媒体类型与新组控制消息一起使用（参见第5.2.1节）。它的主体部分包含关于新闻组的简要信息：新闻组名称、描述及其审核状态。
The MIME media type definition of application/news-groupinfo is:
application/news groupinfo的MIME媒体类型定义为：
MIME type name: application
MIME类型名称：应用程序
MIME subtype name: news-groupinfo
MIME子类型名称：新闻组信息
Required parameters: none
所需参数：无
Optional parameters: charset, which MUST be a charset registered for use with MIME text types. It has the same syntax as the parameter defined for text/plain [RFC2046]. Specifies the charset of the body part. If not given, the charset defaults to US-ASCII [ASCII].
可选参数：字符集，必须是注册用于MIME文本类型的字符集。它的语法与为text/plain[RFC2046]定义的参数相同。指定主体部分的字符集。如果未给出，字符集默认为US-ASCII[ASCII]。
Encoding considerations: 7bit or 8bit encoding MUST be used to maintain compatibility.
编码注意事项：必须使用7位或8位编码来保持兼容性。
Security considerations: None.
安全考虑：无。
Interoperability considerations: Disposition should by default be inline.
互操作性注意事项：默认情况下，处置应该是内联的。
Applications that use this media type: Control message issuers, relaying agents, serving agents.
使用此媒体类型的应用程序：控制消息发布者、中继代理、服务代理。
Published specification: RFC 5537
已发布规范：RFC 5537
Intended usage: COMMON
预期用途：普通
Change controller: IETF
更改控制器：IETF
The content of the application/news-groupinfo body part is defined as:
应用程序/新闻组信息正文部分的内容定义如下：
groupinfo-body = [ newsgroups-tag CRLF ]
newsgroups-line CRLF
newsgroups-tag = %x46.6F.72 SP %x79.6F.75.72 SP
%x6E.65.77.73.67.72.6F.75.70.73 SP
%x66.69.6C.65.3A
; case sensitive
; "For your newsgroups file:"
newsgroups-line = newsgroup-name
[ 1*HTAB newsgroup-description ]
[ *WSP moderation-flag ]
newsgroup-description
= eightbit-utext *( *WSP eightbit-utext )
moderation-flag = SP "(" %x4D.6F.64.65.72.61.74.65.64 ")"
groupinfo-body = [ newsgroups-tag CRLF ]
newsgroups-line CRLF
newsgroups-tag = %x46.6F.72 SP %x79.6F.75.72 SP
%x6E.65.77.73.67.72.6F.75.70.73 SP
%x66.69.6C.65.3A
; case sensitive
; "For your newsgroups file:"
newsgroups-line = newsgroup-name
[ 1*HTAB newsgroup-description ]
[ *WSP moderation-flag ]
newsgroup-description
= eightbit-utext *( *WSP eightbit-utext )
moderation-flag = SP "(" %x4D.6F.64.65.72.61.74.65.64 ")"
; SPACE + case sensitive "(Moderated)"
eightbit-utext = VCHAR / %d127-255
; SPACE + case sensitive "(Moderated)"
eightbit-utext = VCHAR / %d127-255
This unusual format is backward-compatible with the scanning of the body of newgroup control messages for descriptions done by Netnews implementations that predate this specification. Although optional, the <newsgroups-tag> SHOULD be included for backward compatibility.
这种不寻常的格式与扫描newgroup控制消息体以查找在本规范之前由Netnews实现完成的描述时向后兼容。尽管是可选的，<newsgroups标签>，但为了向后兼容，应该包括在内。
The <newsgroup-description> MUST NOT contain any occurrence of the string "(Moderated)" within it. Moderated newsgroups MUST be marked by appending the case-sensitive text " (Moderated)" at the end.
<newsgroup description>中不得出现字符串“（已缓和）”。必须通过在末尾添加区分大小写的文本“（版主）”来标记版主新闻组。
While a charset parameter is defined for this media type, most existing software does not understand MIME header fields or correctly handle descriptions in a variety of charsets. Using a charset of US-ASCII where possible is therefore RECOMMENDED; if not possible, UTF-8 [RFC3629] SHOULD be used. Regardless of the charset used, the constraints of the above grammar MUST be met and the <newsgroup-name> MUST be represented in that charset using the same octets as would be used with a charset of US-ASCII.
虽然为此媒体类型定义了字符集参数，但大多数现有软件不理解MIME头字段，也不能正确处理各种字符集中的描述。因此，建议尽可能使用US-ASCII字符集；如果不可能，则应使用UTF-8[RFC3629]。无论使用何种字符集，都必须满足上述语法的约束，并且<newsgroup name>必须在该字符集中使用与US-ASCII字符集相同的八位字节来表示。
The application/news-checkgroups media type contains a list of newsgroups within a hierarchy or hierarchies, including their descriptions and moderation status. It is primarily for use with the checkgroups control message (see Section 5.2.3).
应用程序/新闻检查组媒体类型包含一个或多个层次结构中的新闻组列表，包括其描述和审核状态。它主要用于检查组控制信息（见第5.2.3节）。
The MIME media type definition of application/news-checkgroups is:
应用程序/新闻检查组的MIME媒体类型定义为：
MIME type name: application
MIME类型名称：应用程序
MIME subtype name: news-checkgroups
MIME子类型名称：新闻检查组
Required parameters: none
所需参数：无
Optional parameters: charset, which MUST be a charset registered for use with MIME text types. It has the same syntax as the parameter defined for text/plain [RFC2046]. Specifies the charset of the body part. If not given, the charset defaults to US-ASCII [ASCII].
可选参数：字符集，必须是注册用于MIME文本类型的字符集。它的语法与为text/plain[RFC2046]定义的参数相同。指定主体部分的字符集。如果未给出，字符集默认为US-ASCII[ASCII]。
Encoding considerations: 7bit or 8bit encoding MUST be used to maintain compatibility.
编码注意事项：必须使用7位或8位编码来保持兼容性。
Security considerations: This media type provides only a means for conveying a list of newsgroups and does not provide any information indicating whether the sender is authorized to state which newsgroups should exist within a hierarchy. Such authorization must be accomplished by other means.
安全注意事项：此媒体类型仅提供传递新闻组列表的方法，不提供任何信息，指示发件人是否有权声明层次结构中应存在哪些新闻组。这种授权必须通过其他方式完成。
Interoperability considerations: Disposition should by default be inline.
互操作性注意事项：默认情况下，处置应该是内联的。
Applications that use this media type: Control message issuers, relaying agents, serving agents.
使用此媒体类型的应用程序：控制消息发布者、中继代理、服务代理。
Published specification: RFC 5537
已发布规范：RFC 5537
Intended usage: COMMON
预期用途：普通
Change controller: IETF
更改控制器：IETF
The content of the application/news-checkgroups body part is defined as:
应用程序/新闻检查组正文部分的内容定义为：
checkgroups-body = *( valid-group CRLF )
valid-group = newsgroups-line ; see Section 4.2
checkgroups-body = *( valid-group CRLF )
valid-group = newsgroups-line ; see Section 4.2
The same restrictions on charset, <newsgroup-name>, and <newsgroup-description> apply for this media type as for application/ news-groupinfo.
对字符集、<newsgroup name>和<newsgroup description>的限制与对application/news groupinfo同样适用于此媒体类型。
One application/news-checkgroups message may contain information for one or more hierarchies and is considered complete for any hierarchy for which it contains a <valid-group> unless accompanied by external information limiting its scope (such as a <chkscope> parameter to a checkgroups control message, as described in Section 5.2.3). In other words, an application/news-checkgroups body part consisting of
一条应用程序/新闻检查组消息可能包含一个或多个层次结构的信息，并且对于包含<有效组>的任何层次结构，都被认为是完整的，除非附带限制其范围的外部信息（如第5.2.3节中所述的检查组控制消息的<chkscope>参数）。换句话说，应用程序/新闻检查组主体部分由
example.moderated A moderated newsgroup (Moderated) example.test An unmoderated test group
示例。主持了主持的新闻组（主持的）示例。测试未降级的测试组
is a statement that the example.* hierarchy contains two newsgroups, example.moderated and example.test, and no others. This media type therefore MUST NOT be used for conveying partial information about a hierarchy; if a group from a given hierarchy is present, all groups
是一条语句，说明example.*层次结构包含两个新闻组example.moderated和example.test，而不包含其他新闻组。因此，此媒体类型不得用于传递有关层次结构的部分信息；如果存在给定层次结构中的组，则所有组
that exist in that hierarchy MUST be listed unless its scope is limited by external information, in which case all groups SHOULD be listed.
必须列出该层次结构中存在的组，除非其范围受到外部信息的限制，在这种情况下，应列出所有组。
Spaces are used in this example for formatting reasons. In an actual message, the newsgroup name and description MUST be separated by one or more tabs (HTAB, ASCII %d09), not spaces.
本例中使用空格是出于格式原因。在实际邮件中，新闻组名称和说明必须由一个或多个选项卡（HTAB，ASCII%d09）分隔，而不是空格。
A control message is an article that contains a Control header field and thereby indicates that some action should be taken by an agent other than distribution and display. Any article containing a Control header field (defined in Section 3.2.3 of [RFC5536]) is a control message. Additionally, the action of an article containing a Supersedes header field is described here; while such an article is not a control message, it specifies an action similar to the cancel control message.
控制消息是一个包含控制头字段的项目，因此指示代理应执行某些操作，而不是分发和显示。任何包含控制标题字段（在[RFC5536]第3.2.3节中定义）的项目都是控制消息。此外，本文还描述了包含取代标题字段的文章的操作；虽然这样的项目不是控制消息，但它指定了类似于取消控制消息的操作。
The <control-command> of a Control header field comprises a <verb>, which indicates the action to be taken, and one or more <argument> values, which supply the details. For some control messages, the body of the article is also significant. Each recognized <verb> (the control message type) is described in a separate section below. Agents MAY accept other control message types than those specified below, and MUST either ignore or reject control messages with unrecognized types. Syntactic definitions of valid <argument> values and restrictions on control message bodies are given in the section for each control message type.
控件标题字段的<control command>包括一个<verb>（表示要采取的操作）和一个或多个<argument>值（提供详细信息）。对于某些控制消息，本文的正文也很重要。每个已识别的<verb>（控制消息类型）在下面单独的一节中描述。代理可以接受除下面指定的控制消息类型以外的其他控制消息类型，并且必须忽略或拒绝具有无法识别类型的控制消息。有效<argument>值的语法定义和控制消息体的限制在每种控制消息类型的部分中给出。
Contrary to [RFC1036], the presence of a Subject header field starting with the string "cmsg " MUST NOT cause an article to be interpreted as a control message. Agents MAY reject an article that has such a Subject header field and no Control header field as ambiguous. Likewise, the presence of a <newsgroup-name> ending in ".ctl" in the Newsgroups header field or the presence of an Also-Control header field MUST NOT cause the article to be interpreted as a control message.
与[RFC1036]相反，以字符串“cmsg”开头的主题标题字段的存在不得导致文章被解释为控制消息。代理可以拒绝具有主题标题字段且没有控制标题字段的文章，因为该字段不明确。同样，新闻组标题字段中出现以“.ctl”结尾的<newsgroup name>或同时出现控制标题字段不得导致文章被解释为控制消息。
Control messages specify actions above and beyond the normal processing of an article and are therefore potential vectors of abuse and unauthorized action. There is, at present, no standardized means of authenticating the sender of a control message or verifying that the contents of a control message were sent by the claimed sender. There are, however, some unstandardized authentication mechanisms in common use, such as [PGPVERIFY].
控制消息指定了超出物品正常处理范围的操作，因此是滥用和未经授权操作的潜在载体。目前，没有标准化的方法来认证控制消息的发送者或验证控制消息的内容是否由声称的发送者发送。但是，有一些常用的非标准身份验证机制，如[PGPVERIFY]。
Agents acting on control messages SHOULD take steps to authenticate control messages before acting on them, as determined by local authorization policy. Whether this is done via the use of an unstandardized authentication protocol, by comparison with information obtained through another protocol, by human review, or by some other means is left unspecified by this document. Further extensions or revisions of this protocol are expected to standardize a digital signature mechanism.
根据本地授权策略的确定，对控制消息进行操作的代理应在对控制消息进行操作之前采取步骤对其进行身份验证。是否通过使用非标准认证协议、通过与通过另一协议获得的信息进行比较、通过人工审查或通过其他方式来实现，本文件未予明确。该协议的进一步扩展或修订有望使数字签名机制标准化。
Agents are expected to have their own local authorization policies for which control messages will be honored. No Netnews agent is ever required to act on any control message. The following descriptions specify the actions that a control message requests, but an agent MAY always decline to act on any given control message.
代理应该有自己的本地授权策略，控制消息将遵守这些策略。不需要Netnews代理对任何控制消息进行操作。以下描述指定了控制消息请求的操作，但代理可能始终拒绝对任何给定的控制消息执行操作。
A group control message is any control message type that requests some update to the list of newsgroups known to a news server. The standard group control message types are "newgroup", "rmgroup", and "checkgroups".
组控制消息是请求对新闻服务器已知的新闻组列表进行某些更新的任何控制消息类型。标准组控制消息类型为“newgroup”、“rmgroup”和“checkgroups”。
Before honoring any group control message, an agent MUST check the newsgroup or newsgroups affected by that control message and decline to create any newsgroups not in conformance with the restrictions in Section 3.1.4 of [RFC5536].
在接受任何组控制消息之前，代理必须检查受该控制消息影响的一个或多个新闻组，并拒绝创建不符合[RFC5536]第3.1.4节限制的任何新闻组。
All of the group control messages MUST have an Approved header field (Section 3.2.1 of [RFC5536]). Group control messages without an Approved header field SHOULD NOT be honored.
所有集团控制信息必须具有批准的标题字段（RFC5536第3.2.1节）。不应接受没有批准的标题字段的组控制邮件。
Group control messages affecting specific groups (newgroup and rmgroup control messages, for example) SHOULD include the <newsgroup-name> for the group or groups affected in their Newsgroups header field. Other newsgroups MAY be included in the Newsgroups header field so that the control message will reach more news servers, but due to the special relaying rules for group control messages (see Section 3.6) this is normally unnecessary and may be excessive.
影响特定组的组控制消息（例如，newgroup和rmgroup控制消息）应在其新闻组标题字段中包含受影响组的<newsgroup name>。其他新闻组可能包含在新闻组标题字段中，以便控制消息将到达更多的新闻服务器，但由于组控制消息的特殊中继规则（参见第3.6节），这通常是不必要的，并且可能过多。
The newgroup control message requests that the specified group be created or, if already existing, that its moderation status or description be changed. The syntax of its Control header field is:
newgroup control消息请求创建指定的组，或者，如果已经存在，则请求更改其调节状态或描述。其控件标头字段的语法为：
control-command =/ Newgroup-command
Newgroup-command = "newgroup" Newgroup-arguments
Newgroup-arguments = 1*WSP newsgroup-name
control-command =/ Newgroup-command
Newgroup-command = "newgroup" Newgroup-arguments
Newgroup-arguments = 1*WSP newsgroup-name
[ 1*WSP newgroup-flag ] newgroup-flag = "moderated"
[1*WSP newgroup flag]newgroup flag=“已审核”
If the request is honored, the moderation status of the group SHOULD be set in accordance with the presence or absence of the <newgroup-flag> "moderated". "moderated" is the only flag defined by this protocol. Other flags MAY be defined by extensions to this protocol and accepted by agents. If an agent does not recognize the <newgroup-flag> of a newgroup control message, it SHOULD ignore that control message.
如果请求得到满足，则应根据是否存在<newgroup flag>“已审核”设置组的审核状态。“缓和”是本协议定义的唯一标志。其他标志可由本协议的扩展定义，并由代理接受。如果代理无法识别新组控制消息的<newgroup flag>，则应忽略该控制消息。
The body of a newgroup message SHOULD contain an entity of type application/news-groupinfo specifying the description of the newsgroup, either as the entire body or as an entity within a multipart/mixed object [RFC2046]. If such an entity is present, the moderation status specified therein MUST match the moderation status specified by the <newgroup-flag>. The body of a newgroup message MAY contain other entities (encapsulated in multipart/mixed) that provide additional information about the newsgroup or the circumstances of the control message.
newgroup消息的正文应包含类型为application/news groupinfo的实体，该实体指定新闻组的描述，可以是整个正文，也可以是多部分/混合对象中的实体[RFC2046]。如果存在这样的实体，则其中指定的审核状态必须与<newgroup flag>指定的审核状态匹配。newgroup消息的正文可能包含其他实体（封装在多部分/混合中），这些实体提供有关新闻组或控制消息情况的附加信息。
In the absence of an application/news-groupinfo entity, a news server MAY search the body of the message for the line "For your newsgroups file:" and take the following line as a <newsgroups-line>. Prior to the standardization of application/news-groupinfo, this was the convention for providing a newsgroup description.
如果没有应用程序/新闻组信息实体，新闻服务器可能会在邮件正文中搜索“for your news groups file:”一行，并将以下一行作为<newsgroups line>。在应用程序/新闻组信息标准化之前，这是提供新闻组描述的惯例。
If the request is honored and contains a newsgroup description, and if the news server honoring it stores newsgroup descriptions, the stored newsgroup description SHOULD be updated to the description specified in the control message, even if no other property of the group has changed.
如果请求被接受并包含新闻组描述，并且接受请求的新闻服务器存储新闻组描述，则存储的新闻组描述应更新为控制消息中指定的描述，即使组的其他属性没有更改。
A newgroup control message requesting creation of the moderated newsgroup example.admin.info.
一条新的组控制消息，请求创建主持新闻组example.admin.info。
From: "example.* Administrator" <admin@noc.example>
Newsgroups: example.admin.info
Date: 27 Feb 2002 12:50:22 +0200
Subject: cmsg newgroup example.admin.info moderated
Approved: admin@noc.example
Control: newgroup example.admin.info moderated
Message-ID: <ng-example.admin.info-20020227@noc.example>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="nxtprt"
Content-Transfer-Encoding: 8bit
From: "example.* Administrator" <admin@noc.example>
Newsgroups: example.admin.info
Date: 27 Feb 2002 12:50:22 +0200
Subject: cmsg newgroup example.admin.info moderated
Approved: admin@noc.example
Control: newgroup example.admin.info moderated
Message-ID: <ng-example.admin.info-20020227@noc.example>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="nxtprt"
Content-Transfer-Encoding: 8bit
This is a MIME control message. --nxtprt Content-Type: application/news-groupinfo; charset=us-ascii
这是一条MIME控制消息--NXTPT内容类型：应用程序/新闻组信息；字符集=美国ascii码
For your newsgroups file: example.admin.info About the example.* groups (Moderated)
对于您的新闻组文件：example.admin.info关于示例。*组（已审核）
--nxtprt
Content-Type: text/plain; charset=us-ascii
--nxtprt
Content-Type: text/plain; charset=us-ascii
A moderated newsgroup for announcements about new newsgroups in the example.* hierarchy.
示例。*层次结构中有关新新闻组的公告的受限制新闻组。
--nxtprt--
--NXTPT--
Spaces are used in this example for formatting reasons. In an actual message, the newsgroup name and description MUST be separated by one or more tabs (HTAB, ASCII %d09), not spaces.
本例中使用空格是出于格式原因。在实际邮件中，新闻组名称和说明必须由一个或多个选项卡（HTAB，ASCII%d09）分隔，而不是空格。
The rmgroup control message requests that the specified group be removed from a news server's list of valid groups. The syntax of its Control header field is:
rmgroup控制消息请求从新闻服务器的有效组列表中删除指定的组。其控件标头字段的语法为：
control-command =/ Rmgroup-command
Rmgroup-command = "rmgroup" Rmgroup-arguments
Rmgroup-arguments = 1*WSP newsgroup-name
control-command =/ Rmgroup-command
Rmgroup-command = "rmgroup" Rmgroup-arguments
Rmgroup-arguments = 1*WSP newsgroup-name
The body of the control message MAY contain anything, usually an explanatory text.
控制消息的正文可以包含任何内容，通常是解释性文本。
The checkgroups control message contains a list of all the valid groups in a hierarchy with descriptions and moderation status. It requests that a news server update its valid newsgroup list for that hierarchy to include the groups specified, remove any groups not specified, and update group descriptions and moderation status to match those given in the checkgroups control message. The syntax of its Control header field is:
checkgroups控制消息包含层次结构中所有有效组的列表，其中包含说明和审核状态。它要求新闻服务器更新该层次结构的有效新闻组列表，以包括指定的组，删除任何未指定的组，并更新组说明和审核状态，以匹配checkgroups控制消息中给出的组。其控件标头字段的语法为：
control-command =/ Checkgroup-command
Checkgroup-command = "checkgroups" Checkgroup-arguments
Checkgroup-arguments= [ chkscope ] [ chksernr ]
chkscope = 1*( 1*WSP ["!"] newsgroup-name )
chksernr = 1*WSP "#" 1*DIGIT
control-command =/ Checkgroup-command
Checkgroup-command = "checkgroups" Checkgroup-arguments
Checkgroup-arguments= [ chkscope ] [ chksernr ]
chkscope = 1*( 1*WSP ["!"] newsgroup-name )
chksernr = 1*WSP "#" 1*DIGIT
A checkgroups message is interpreted as an exhaustive list of the valid groups in all hierarchies or sub-hierarchies with a prefix listed in the <chkscope> argument, excluding any sub-hierarchy where the <chkscope> argument is prefixed by "!". For complex cases with multiple <chkscope> arguments, start from an empty list of groups, include all groups in the checkgroups control message matching <chkscope> arguments without a "!" prefix, and then exclude all groups matching <chkscope> arguments with a "!" prefix. Follow this method regardless of the order of the <chkscope> arguments in the Control header field.
checkgroups消息被解释为所有层次结构或子层次结构中的有效组的详尽列表，前缀列在<chkscope>参数中，不包括<chkscope>参数前缀为“！”的任何子层次结构。对于具有多个<chkscope>参数的复杂情况，请从组的空列表开始，在checkgroups控制消息matching<chkscope>参数中包括所有组，但不带“！”前缀，然后排除所有与<chkscope>参数匹配且带有“！”前缀的组。无论控件标头字段中参数的顺序如何，都应遵循此方法。
If no <chkscope> argument is given, it applies to all hierarchies for which group statements appear in the body of the message.
如果未给出<chkscope>参数，则该参数适用于消息体中出现group语句的所有层次结构。
Since much existing software does not honor the <chkscope> argument, the body of the checkgroups control message MUST NOT contain group statements for newsgroups outside the intended scope and SHOULD contain a correct newsgroup list even for sub-hierarchies excluded with "!" <chkscope> terms. News servers, however, MUST honor <chkscope> as specified here.
由于许多现有软件不支持<chkscope>参数，checkgroups控制消息的正文不能包含预期范围之外的新闻组的组语句，并且应该包含正确的新闻组列表，即使对于被“！”<chkscope>术语排除的子层次结构也是如此。但是，新闻服务器必须遵守此处指定的<chkscope>。
The <chksernr> argument may be any positive integer. If present, it MUST increase with every change to the newsgroup list, MUST NOT ever decrease, and MUST be included in all subsequent checkgroups control messages with the same scope. If provided, news servers SHOULD remember the <chksernr> value of the previous checkgroups control message honored for a particular hierarchy or sub-hierarchy and decline to honor any subsequent checkgroups control message for the same hierarchy or sub-hierarchy with a smaller <chksernr> value or with no <chksernr> value.
<chksernr>参数可以是任何正整数。如果存在，它必须随着新闻组列表的每次更改而增加，不能减少，并且必须包含在具有相同范围的所有后续检查组控制消息中。如果提供，新闻服务器应记住为特定层次结构或子层次结构执行的先前checkgroups控制消息的<chksernr>值，并拒绝使用较小的<chksernr>值或没有<chksernr>值为同一层次结构或子层次结构执行任何后续checkgroups控制消息。
There is no upper limit on the length of <chksernr>, other than the limitation on the length of header fields. Implementations may therefore want to do comparisons by zero-padding the shorter of two <chksernr> values on the left and then doing a string comparison, rather than assuming <chksernr> can be manipulated as a number.
除了头字段的长度限制外，<chksernr>的长度没有上限。因此，实现可能希望通过对左侧两个<chksernr>值中较短的值进行零填充，然后进行字符串比较来进行比较，而不是假设<chksernr>可以作为一个数字进行操作。
For example, the following Control header field
例如，以下控件标题字段
Control: checkgroups de !de.alt #2009021301
Control: checkgroups de !de.alt #2009021301
indicates that the body of the message will list every newsgroup in the de.* hierarchy, excepting the de.alt.* sub-hierarchy, and should not be honored if a checkgroups control message with a serial number greater than 2009021301 was previously honored. The serial number in this example was formed from the date in YYYYMMDD format, followed by a two-digit sequence number within that date.
指示邮件正文将列出de.*层次结构中的每个新闻组（de.alt.*子层次结构除外），并且如果序列号大于2009021301的checkgroups控制邮件先前已被接受，则不应接受。本例中的序列号由YYYYMMDD格式的日期构成，后跟该日期内的两位数序列号。
The body of the message is an entity of type application/ news-checkgroups. It SHOULD be declared as such with appropriate MIME headers, but news servers SHOULD interpret checkgroups messages that lack the appropriate MIME headers as if the body were of type application/news-checkgroups for backward compatibility.
消息体是类型为application/news checkgroups的实体。应该使用适当的MIME头声明它，但是新闻服务器应该解释缺少适当MIME头的checkgroups消息，就好像正文是application/news checkgroups类型的，以便向后兼容。
The cancel control message requests that a target article be withdrawn from circulation and access. The syntax of its Control header field is:
“取消控制”消息请求从流通和访问中撤回目标物品。其控件标头字段的语法为：
control-command =/ Cancel-command
Cancel-command = "cancel" Cancel-arguments
Cancel-arguments = 1*WSP msg-id
control-command =/ Cancel-command
Cancel-command = "cancel" Cancel-arguments
Cancel-arguments = 1*WSP msg-id
The argument identifies the article to be cancelled by its message identifier. The body of the control message MAY contain anything, usually an explanatory text.
参数通过其消息标识符标识要取消的项目。控制消息的正文可以包含任何内容，通常是解释性文本。
A serving agent that elects to honor a cancel message SHOULD make the article unavailable to reading agents (perhaps by deleting it completely). If the cancel control message arrives before the article it targets, news servers choosing to honor it SHOULD remember the message identifier that was cancelled and reject the cancelled article when it arrives.
选择接受取消消息的服务代理应使阅读代理无法访问该文章（可能是完全删除）。如果取消控制消息在其目标文章之前到达，则选择接受该消息的新闻服务器应记住已取消的消息标识符，并在其到达时拒绝已取消的文章。
To best ensure that it will be relayed to the same news servers as the original message, a cancel control message SHOULD have the same Newsgroups header field as the message it is cancelling.
为了最好地确保将其中继到与原始消息相同的新闻服务器，取消控制消息应具有与其取消的消息相同的新闻组标题字段。
Cancel control messages listing moderated newsgroups in their Newsgroups header field MUST contain an Approved header field like any other article in a moderated newsgroup. This means that cancels posted to a moderated newsgroup will normally be sent to the moderator first for approval. Outside of moderated newsgroups, cancel messages are not required to contain an Approved header field.
“取消控制”消息在其“新闻组标题”字段中列出了受主持的新闻组，与受主持的新闻组中的任何其他文章一样，这些消息必须包含“批准的标题”字段。这意味着，发布到受版主控制的新闻组的取消通常会首先发送给版主进行批准。在受主持的新闻组之外，取消消息不需要包含批准的标题字段。
Contrary to [RFC1036], cancel control messages are not required to contain From and Sender header fields matching the target message. This requirement only encouraged cancel issuers to conceal their identity and provided no security.
与[RFC1036]相反，取消控制消息不需要包含与目标消息匹配的发件人和发件人标头字段。这一要求只鼓励取消发行人隐藏其身份，不提供任何安全性。
The presence of a Supersedes header field in an article requests that the message identifier given in that header field be withdrawn in exactly the same manner as if it were the target of a cancel control
如果项目中存在“取代”标头字段，则要求以与取消控件的目标完全相同的方式撤销该标头字段中给定的消息标识符
message. Accordingly, news servers SHOULD apply to a Supersedes header field the same authentication and authorization checks as they would apply to cancel control messages. If the Supersedes header field is honored, the news server SHOULD take the same actions as it would take when honoring a cancel control message for the given target article.
消息因此，新闻服务器应用于取代标头字段的身份验证和授权检查应与应用于取消控制消息的身份验证和授权检查相同。如果接受“取代标题”字段，则新闻服务器应采取与接受给定目标文章的取消控制消息时相同的操作。
The article containing the Supersedes header field, whether or not the Supersedes header field is honored, SHOULD be handled as a normal article and SHOULD NOT receive the special treatment of control messages described in Section 3.7.
包含取代标题字段的文章，无论是否遵守取代标题字段，都应作为普通文章处理，并且不应接受第3.7节中所述的控制消息的特殊处理。
The ihave and sendme control messages implement a predecessor of the NNTP [RFC3977] protocol. They are largely obsolete on the Internet but still see use in conjunction with some transport protocols such as UUCP [UUCP]. News servers are not required to support them.
ihave和sendme控制消息实现NNTP[RFC3977]协议的前身。它们在互联网上基本上已经过时，但仍然可以与一些传输协议（如UUCP[UUCP]）结合使用。新闻服务器不需要支持它们。
ihave and sendme control messages share similar syntax for their Control header fields and bodies:
ihave和sendme控制消息的控制头字段和正文具有相似的语法：
control-command =/ Ihave-command
Ihave-command = "ihave" Ihave-arguments
Ihave-arguments = 1*WSP *( msg-id 1*WSP ) relayer-name
control-command =/ Sendme-command
Sendme-command = "sendme" Sendme-arguments
Sendme-arguments = Ihave-arguments
relayer-name = path-identity ; see 3.1.5 of [RFC5536]
ihave-body = *( msg-id CRLF )
sendme-body = ihave-body
control-command =/ Ihave-command
Ihave-command = "ihave" Ihave-arguments
Ihave-arguments = 1*WSP *( msg-id 1*WSP ) relayer-name
control-command =/ Sendme-command
Sendme-command = "sendme" Sendme-arguments
Sendme-arguments = Ihave-arguments
relayer-name = path-identity ; see 3.1.5 of [RFC5536]
ihave-body = *( msg-id CRLF )
sendme-body = ihave-body
The body of the article consists of a list of <msg-id>s, one per line. The message identifiers SHOULD be put in the body of the article, not in the Control header field, but news servers MAY recognize and process message identifiers in the Control header field for backward compatibility. Message identifiers MUST NOT be put in the Control header field if they are present in the body of the control message.
文章的正文包括一个<msg id>列表，每行一个。消息标识符应该放在文章的正文中，而不是控制头字段中，但是新闻服务器可以识别和处理控制头字段中的消息标识符，以实现向后兼容性。如果消息标识符出现在控制消息正文中，则不能将其放入控制头字段中。
The ihave message states that the named relaying agent has received articles with the specified message identifiers, which may be of interest to the relaying agents receiving the ihave message. The sendme message requests that the agent receiving it send the articles having the specified message identifiers to the named relaying agent. Contrary to [RFC1036], the relayer-name MUST be given as the last argument in the Control header field.
ihave消息声明，指定的中继代理已接收到具有指定消息标识符的项目，接收ihave消息的中继代理可能感兴趣。sendme消息请求接收它的代理将具有指定消息标识符的项目发送给指定的中继代理。与[RFC1036]相反，中继层名称必须作为控件标头字段中的最后一个参数提供。
Upon receipt of the sendme message (and a decision to honor it), the receiving agent sends the article or articles requested. The mechanism for this transmission is unspecified by this document and is arranged between the sites involved.
在收到sendme消息（并决定接受该消息）后，接收代理将发送所请求的一篇或多篇文章。本文件未说明这种传播的机制，并安排在相关站点之间。
These control messages are normally sent as point-to-point articles between two sites and not then sent on to other sites. Newsgroups beginning with "to." are reserved for such point-to-point communications and are formed by prepending "to." to a <relayer-name> to form a <newsgroup-name>. Articles with such a group in their Newsgroups header fields SHOULD NOT be sent to any news server other than the one identified by <relayer-name>.
这些控制消息通常在两个站点之间以点对点文章的形式发送，然后不发送到其他站点。以“to.”开头的新闻组是为这种点对点通信保留的，通过在<relayer name>前面加上“to.”来形成<newsgroup name>。在其新闻组标题字段中包含此类组的文章不应发送到由<relayer name>标识的新闻服务器以外的任何新闻服务器。
The following control message types are declared obsolete by this document and SHOULD NOT be sent or honored:
本文档声明以下控制消息类型已过时，不应发送或接受：
sendsys version whogets senduuname
sendsys版本谁获取senduuname
Netnews is designed for broad dissemination of public messages and offers little in the way of security. What protection Netnews has against abuse and impersonation is provided primarily by the underlying transport layer. In large Netnews networks where news servers cannot be relied upon to enforce authentication and authorization requirements at the transport layer, articles may be trivially forged and widely read, and the identities of article senders and the privacy of articles cannot be assured.
网络新闻是为广泛传播公共信息而设计的，在安全方面几乎没有提供什么。Netnews针对滥用和假冒的保护主要由底层传输层提供。在大型Netnews网络中，无法依靠新闻服务器在传输层强制执行身份验证和授权要求，文章可能会被轻微伪造和广泛阅读，文章发送者的身份和文章的隐私无法得到保证。
See Section 5 of [RFC5536] for further security considerations related to the format of articles.
有关条款格式的更多安全注意事项，请参见[RFC5536]第5节。
Control messages pose a particular security concern since acting on unauthorized control messages may cause newsgroups to be removed, articles to be deleted, and unwanted newsgroups to be created. Administrators of news servers SHOULD therefore take steps to verify the authenticity of control messages as discussed in Section 5.1. Articles containing Supersedes header fields are effectively cancel control messages and SHOULD be subject to the same checks as
控制消息带来了一个特别的安全问题，因为对未经授权的控制消息执行操作可能会导致删除新闻组、删除文章和创建不需要的新闻组。因此，新闻服务器的管理员应采取步骤验证控制消息的真实性，如第5.1节所述。包含“取代”标题字段的项目实际上是取消控制消息，应接受与相同的检查
discussed in Section 5.4. Currently, many sites are ignoring all cancel control messages and Supersedes header fields due to the difficulty of authenticating them and their widespread abuse.
在第5.4节中讨论。目前，许多站点都忽略了所有取消控制消息，并取代了标题字段，这是因为很难对它们进行身份验证，而且它们被广泛滥用。
Cancel control messages are not required to have the same Newsgroups header field as the messages they are cancelling. Since they are sometimes processed before the original message is received, it may not be possible to check that the Newsgroup header fields match. This allows a malicious poster to inject a cancel control message for an article in a moderated newsgroup without adding an Approved header field to the control message, and to hide malicious cancel control messages from some reading agents by using a different Newsgroups header field so that the cancel control message is not accepted by all news servers that accepted the original message.
取消控制邮件不需要与要取消的邮件具有相同的新闻组标题字段。由于有时会在收到原始消息之前对其进行处理，因此可能无法检查新闻组标题字段是否匹配。这允许恶意海报在未向控制消息中添加批准的标题字段的情况下，为受主持的新闻组中的文章插入取消控制消息，以及通过使用不同的新闻组标题字段隐藏来自某些阅读代理的恶意取消控制消息，以便接受原始消息的所有新闻服务器都不会接受取消控制消息。
All agents should be aware that all article content, most notably including the content of the Control header field, is potentially untrustworthy and malicious. Articles may be constructed in syntactically invalid ways to attempt to overflow internal buffers, violate hidden assumptions, or exploit implementation weaknesses. For example, some news server implementations have been successfully attacked via inclusion of Unix shell code in the Control header field. All article contents, and particularly control message contents, SHOULD be handled with care and rigorously verified before any action is taken on the basis of the contents of the article.
所有代理都应该意识到，所有文章内容，尤其是包括控件头字段的内容，都可能是不可信和恶意的。项目可能以语法无效的方式构造，以试图溢出内部缓冲区、违反隐藏的假设或利用实现弱点。例如，一些新闻服务器实现已通过在控制头字段中包含Unix shell代码成功受到攻击。在根据文章内容采取任何行动之前，应谨慎处理所有文章内容，尤其是控制消息内容，并严格验证。
A malicious poster may add an Approved header field to bypass the moderation process of a moderated newsgroup. Injecting agents SHOULD verify that messages approved for a moderated newsgroup are being injected by the moderator using authentication information from the underlying transport or some other authentication mechanism arranged with the moderator. There is, at present, no standardized method of authenticating approval of messages to moderated groups, although some unstandardized authentication methods such as [PGPMOOSE] are in common use.
恶意海报可能会添加批准的标题字段，以绕过已审核新闻组的审核过程。注入代理应验证版主是否正在使用来自底层传输的身份验证信息或与版主一起安排的其他身份验证机制注入为版主新闻组批准的消息。目前，没有标准化的方法来验证对受审核组的消息的批准，尽管一些非标准化的身份验证方法（如[PGPMOSE]）已被普遍使用。
A malicious news server participating in a Netnews network may bypass checks performed by injecting agents, forge Path header fields and other trace information (such as Injection-Info header fields), and otherwise compromise the authorization requirements of a Netnews network. News servers SHOULD use the facilities of the underlying transport to authenticate their peers and reject articles from injecting and relaying agents that do not follow the requirements of this protocol or the Netnews network.
参与Netnews网络的恶意新闻服务器可能会绕过注入代理执行的检查，伪造路径头字段和其他跟踪信息（例如注入信息头字段），并以其他方式破坏Netnews网络的授权要求。新闻服务器应使用底层传输的设施对其对等方进行身份验证，并拒绝来自不符合本协议或Netnews网络要求的注入和中继代理的文章。
The proper functioning of individual newsgroups can be disrupted by the excessive posting of unwanted articles; by the repeated posting of identical or near identical articles; by posting followups that either are unrelated to their precursors or that quote their precursors in full with the addition of minimal extra material (especially if this process is iterated); by crossposting to, or requesting followups to, totally unrelated newsgroups; and by abusing control messages and the Supersedes header field to delete articles or newsgroups.
个别新闻组的正常运作可能会因过度发布不需要的文章而中断；通过重复张贴相同或接近相同的物品；通过发布与其前体无关的后续信息，或通过添加最少的额外材料（尤其是在重复此过程的情况下）完整引用其前体信息；通过向完全无关的新闻组交叉发布或请求跟进；并通过滥用控制消息和取代标题字段来删除文章或新闻组。
Such articles intended to deny service, or other articles of an inflammatory nature, may also have their From or Reply-To addresses set to valid but incorrect email addresses, thus causing large volumes of email to descend on the true owners of those addresses. Users and agents should always be aware that identifying information in articles may be forged.
此类旨在拒绝服务的文章或其他具有煽动性的文章也可能将其发件人或回复地址设置为有效但不正确的电子邮件地址，从而导致大量电子邮件落到这些地址的真正所有者身上。用户和代理人应始终意识到物品中的识别信息可能是伪造的。
A malicious poster may prevent an article from being seen at a particular site by including in the Path header field of the proto-article the <path-identity> of that site. Use of the <diag-keyword> "POSTED" by injecting agents to mark the point of injection can prevent this attack.
恶意海报可以通过在原型文章的路径头字段中包含该站点的<Path identity>来防止在特定站点上看到文章。注射代理使用<diag关键字>“post”标记注射点可以防止此攻击。
Primary responsibility for preventing such attacks lies with injecting agents, which can apply authentication and authorization checks via the underlying transport and prevent those attempting denial-of-service attacks from posting messages. If specific injecting agents fail to live up to their responsibilities, they may be excluded from the Netnews network by configuring relaying agents to reject articles originating from them.
防止此类攻击的主要责任在于注入代理，它可以通过底层传输应用身份验证和授权检查，并防止那些试图拒绝服务攻击的人发布消息。如果特定的注射代理未能履行其职责，则可以通过配置中继代理拒绝来自他们的文章，将他们排除在Netnews网络之外。
A malicious complainer may submit a modified copy of an article (with an altered Injection-Info header field, for instance) to the administrator of an injecting agent in an attempt to discredit the author of that article and even to have his posting privileges removed. Administrators SHOULD therefore obtain a genuine copy of the article from their own serving agent before taking action in response to such a complaint.
恶意投诉人可能会向注射代理的管理员提交文章的修改副本（例如，带有修改过的注射信息标题字段），试图诋毁该文章的作者，甚至取消其发布权限。因此，管理员应在对此类投诉采取行动之前，从自己的服务代理人处获得文章的真实副本。
Articles that are intended to have restricted distribution are dependent on the goodwill of every site receiving them. Restrictions on dissemination and retention of articles may be requested via the Archive and Distribution header fields, but such requests cannot be enforced by the protocol.
拟限制分销的物品取决于接收物品的每个场所的商誉。可以通过存档和分发标题字段请求对文章的分发和保留进行限制，但协议无法强制执行此类请求。
The flooding algorithm used by Netnews transports such as NNTP [RFC3977] is extremely good at finding any path by which articles can leave a subnet with supposedly restrictive boundaries, and substantial administrative effort is required to avoid this. Organizations wishing to control such leakage are advised to designate a small number of gateways to handle all news exchanges with the outside world.
诸如NNTP[RFC3977]之类的Netnews传输所使用的泛洪算法非常善于找到文章可以离开具有假定限制边界的子网的任何路径，并且需要大量的管理工作来避免这种情况。希望控制此类泄漏的组织应指定少量网关来处理与外部世界的所有新闻交流。
The sendme control message (Section 5.5), insofar as it is still used, can be used to request articles that the requester should not have access to.
sendme控制消息（第5.5节）在仍然使用的情况下，可用于请求请求者无权访问的项目。
IANA has registered the following media types, described elsewhere in this document, for use with the Content-Type header field, in the IETF tree in accordance with the procedures set out in [RFC4288].
IANA已根据[RFC4288]中规定的程序，在IETF目录树中注册了以下媒体类型（本文件其他地方描述），以与内容类型标题字段一起使用。
application/news-transmission (4.1) application/news-groupinfo (4.2) application/news-checkgroups (4.3)
应用程序/新闻传输（4.1）应用程序/新闻组信息（4.2）应用程序/新闻检查组（4.3）
application/news-transmission is a change to a previous registration.
申请/新闻传输是对先前注册的更改。
IANA has registered the new header field, Original-Sender, in the Permanent Message Header Field Repository, using the template in Section 3.10.3.
IANA已使用第3.10.3节中的模板在永久邮件标题字段存储库中注册了新标题字段“原始发件人”。
IANA has changed the status of the message/news media type to "OBSOLETE". message/rfc822 should be used instead. An updated template is included in Section 4.
IANA已将消息/新闻媒体类型的状态更改为“过时”。应改用message/rfc822。更新的模板包含在第4节中。
[ASCII] American National Standard for Information Systems, "Coded Character Sets - 7-Bit American National Standard Code for Information Interchange (7-Bit ASCII)", ANSI X3.4, 1986.
[ASCII]美国信息系统国家标准，“编码字符集-7位美国信息交换国家标准代码（7位ASCII）”，ANSI X3.41986。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288]Freed，N.和J.Klensin，“介质类型规范和注册程序”，BCP 13，RFC 4288，2005年12月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]Resnick，P.，Ed.“互联网信息格式”，RFC5222008年10月。
[RFC5536] Murchison, K., Ed., Lindsey, C., and D. Kohn, "Netnews Article Format", RFC 5536, November 2009.
[RFC5536]Murchison，K.，Ed.，Lindsey，C.，和D.Kohn，“网络新闻文章格式”，RFC5362009年11月。
[PGPMOOSE] Rose, G., "PGP Moose", November 1998.
[PGPMOOSE]Rose，G.，“PGP麋鹿”，1998年11月。
[PGPVERIFY] Lawrence, D., "Signing Control Messages", August 2001, <ftp://ftp.isc.org/pub/pgpcontrol/FORMAT>.
[PGPVERIFY]Lawrence，D.，“签署控制消息”，2001年8月<ftp://ftp.isc.org/pub/pgpcontrol/FORMAT>.
[RFC1036] Horton, M. and R. Adams, "Standard for interchange of USENET messages", RFC 1036, December 1987.
[RFC1036]霍顿，M.和R.亚当斯，“USENET消息交换标准”，RFC1036，1987年12月。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.
[RFC2606]Eastlake，D.和A.Panitz，“保留顶级DNS名称”，BCP 32，RFC 26061999年6月。
[RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition Notification", RFC 3798, May 2004.
[RFC3798]Hansen，T.和G.Vaudreuil，“消息处置通知”，RFC 3798，2004年5月。
[RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", RFC 3977, October 2006.
[RFC3977]Feather，C.，“网络新闻传输协议（NNTP）”，RFC3977，2006年10月。
[SON-OF-1036] Spencer, H., "News Article Format and Transmission", Work in Progress, May 2009.
[SON-OF-1036]Spencer，H.，“新闻文章格式和传播”，正在进行的工作，2009年5月。
[USEAGE] Lindsey, C., "Usenet Best Practice", Work in Progress, March 2005.
[USEAGE]Lindsey，C.，“Usenet最佳实践”，正在进行的工作，2005年3月。
[UUCP] O'Reilly, T. and G. Todino, "Managing UUCP and Usenet", O'Reilly & Associates Ltd., January 1992.
[UUCP]O'Reilly，T.和G.Todino，“管理UUCP和Usenet”，O'Reilly&Associates Ltd.，1992年1月。
This document prescribes many changes, clarifications, and new features since the protocol described in [RFC1036]. Most notably:
本文件规定了自[RFC1036]中所述协议以来的许多变更、澄清和新功能。最值得注意的是：
o A new, backward-compatible Path header field format that permits standardized embedding of additional trace and authentication information is now RECOMMENDED. See Section 3.2. Folding of the Path header is permitted.
o 现在推荐一种新的向后兼容的路径头字段格式，该格式允许标准化嵌入额外的跟踪和身份验证信息。见第3.2节。允许折叠路径标题。
o Trimming of the References header field is REQUIRED, and a mechanism for doing so is defined.
o 需要修剪References头字段，并定义了一种这样做的机制。
o Addition of the new Injection-Date header field is required in some circumstances for posting agents (Section 3.4.2) and injecting agents (Section 3.5), and MUST be used by news servers for date checks (Section 3.6). Injecting agents are also strongly encouraged to put all local trace information in the new Injection-Info header field.
o 在某些情况下，过帐代理（第3.4.2节）和注入代理（第3.5节）需要添加新的注入日期标题字段，新闻服务器必须使用该字段进行日期检查（第3.6节）。强烈建议注射代理将所有本地跟踪信息放在新的注射信息标题字段中。
o A new media type is defined for transmitting Netnews articles through other media (Section 4.1), and moderators SHOULD prepare to receive submissions in that format (Section 3.5.1).
o 定义了一种新的媒体类型，用于通过其他媒体传输网络新闻文章（第4.1节），版主应准备接收该格式的提交（第3.5.1节）。
o Certain control messages (Section 5.6) are declared obsolete, and the special significance of "cmsg" at the start of a Subject header field is removed.
o 某些控制消息（第5.6节）被宣布为过时，主题标题字段开头的“cmsg”的特殊意义被删除。
o Additional media types are defined for improved structuring, specification, and automated processing of control messages (Sections 4.2 and 4.3).
o 为改进控制消息的结构、规范和自动化处理，定义了其他媒体类型（第4.2节和第4.3节）。
o Two new optional parameters are added to the checkgroups control message.
o 两个新的可选参数添加到checkgroups控制消息中。
o The message/news media type is declared obsolete.
o 消息/新闻媒体类型被声明为已过时。
o Cancel control messages are no longer required to have From and Sender header fields matching those of the target message, as this requirement added no real security.
o 取消控制消息不再需要具有与目标消息匹配的发件人和发件人标头字段，因为这一要求没有增加真正的安全性。
o The relayer-name parameter in the Control header field of ihave and sendme control messages is now required.
o ihave和sendme控制消息的控制头字段中的relayer name参数现在是必需的。
In addition, many protocol steps and article verification requirements that are unmentioned or left ambiguous by [RFC1036] but are widely implemented by Netnews servers have been standardized and specified in detail.
此外，[RFC1036]未提及或模棱两可，但Netnews服务器广泛实施的许多协议步骤和条款验证要求已被标准化并详细规定。
This document is the result of a twelve-year effort and the number of people that have contributed to its content are too numerous to mention individually. Many thanks go out to all past and present members of the USEFOR Working Group of the Internet Engineering Task Force (IETF) and the accompanying mailing list.
本文件是12年努力的结果，对其内容作出贡献的人数之多，无法单独提及。非常感谢互联网工程任务组（IETF）USEFOR工作组的所有过去和现在的成员以及随附的邮件列表。
Special thanks are due to Henry Spencer, whose [SON-OF-1036] draft served as the initial basis for this document.
特别感谢亨利·斯宾塞（Henry Spencer），他的[1036之子]草稿是本文件的初始基础。
Authors' Addresses
作者地址
Russ Allbery (editor) Stanford University P.O. Box 20066 Stanford, CA 94309 US
Russ Allbery（编辑）斯坦福大学邮政信箱20066美国加利福尼亚州斯坦福94309
EMail: rra@stanford.edu
URI: http://www.eyrie.org/~eagle/
EMail: rra@stanford.edu
URI: http://www.eyrie.org/~eagle/
Charles H. Lindsey 5 Clerewood Avenue Heald Green Cheadle Cheshire SK8 3JU United Kingdom
Charles H.Lindsey 5 Clerwood Avenue Heald Green柴郡柴郡SK8 3JU英国
Phone: +44 161 436 6131
EMail: chl@clerew.man.ac.uk
Phone: +44 161 436 6131
EMail: chl@clerew.man.ac.uk