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.
この文書では、ネットニュースシステムのアーキテクチャを定義し、発信するソフトウェアによって正しい操作やネットニュースの記事の解釈を指定し、配布、保存、およびそれらを表示します。また、輸送やネットニュース記事を提供するために使用されるすべてのプロトコルによって満たされなければならない要件を指定します。
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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクション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
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.
「ユーズネットは、」ネットニュースプロトコルに基づいて、特定の世界的に、公的にアクセス可能なネットワークです。それは、唯一のそのような可能なネットワークです。 （例えば、特定の組織内部のものなど）ユーズネット以外のネットニュースプロトコルの展開があります。この文書では、より一般的なネットニュースアーキテクチャとプロトコルについて説明します。
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.
この文書では、ネットニュースシステムのアーキテクチャを定義し、発信するソフトウェアによって正しい操作やネットニュースの記事の解釈を指定し、配布、保存、およびそれらを表示します。このようなネットワークニュース転送プロトコル（NNTP）[RFC3977]などのトランスポートプロトコルから独立しているプロトコルの問題に対処し、それらの基礎となるトランスポートプロトコルに要件ネットニュースの場所を指定します。また、制御メッセージの処理を指定します。
The format and syntax of Netnews articles are specified in [RFC5536], which should be read in conjunction with this document.
ネットニュース記事の形式と構文は、この文書と併せて読まれるべきである[RFC5536]で指定されています。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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].
この文書で定義された構文は、拡張バッカス・ナウアフォーム（ABNF）[RFC5234]で定義された（コアルールを含む）の表記及び構築物[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>
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>
引数= <参照[RFC5536]セクション3.2.3>物品ロケータ= <参照[RFC5536]セクション3.2.14>成分= <参照[RFC5536]セクション3.1.4>制御コマンド= <参照[RFC5536]セクション3.2。 3>ダイアグキーワード= <参照[RFC5536]セクション3.1.5> DIAGマッチ= <参照[RFC5536]セクション3.1.5>ダイアグ他= <参照[RFC5536]セクション3.1.5> DIST-NAME = <参照[RFC5536]セクション3.2.4> MSG-ID = <参照[RFC5536]セクション3.1.3>ニュースグループ名= <参照[RFC5536]セクション3.1.4>パス診断= <参照[RFC5536]セクション3.1.5>パス・アイデンティティ= <参照[RFC5536]セクション3.1.5>パス-nodot = <参照[RFC5536]セクション3.1.5>テール・エントリ= <参照[RFC5536]セクション3.1.5>動詞= <参照[RFC5536]セクション3.2.3>
display-name = <see [RFC5322] Section 3.4> local-part = <see [RFC5322] Section 3.4.1> mailbox = <see [RFC5322] Section 3.4>
表示名= <参照[RFC5322]セクション3.4>ローカル一部= <参照[RFC5322]セクション3.4.1>メールボックス= <参照[RFC5322]セクション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.
「階層」は、名前（[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.
物品が注入剤による原資料の処理である「注入」。通常、このアクションは、指定された記事のために一度だけ行われます。 「複数の注射は、」1つまたはいくつかの転記剤によって、直列または並列に、複数の注入剤に同じ記事を通過します。
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間コピープロトコル[UUCP]（広範囲にユーズネットの黎明期に使用される）が含まれ、物理的、磁気や光メディアを配信します。いずれのメカニズムは、それがここで指定された要件を満たすことができれば、このプロトコルに関連して使用することができます。
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.
ネットニュースの記事は、オクテットの未解釈のシーケンスとしてニュース記事を扱わなければならないためだけの順にペアとしてネットニュースの記事に表示される必要がある値（ネットニュースの記事では発生しない）％のD00、％のD13、および％のD10を（除く、輸送し、これは、一緒に、行区切りを表します）。これらのオクテットは、それぞれ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の8ビットデータに許容オクテットの範囲[RFC2045]に相当します。ネットニュースのためのトランスポートは、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.
具体的には、トランスポートは、彼らがさらに255に128の範囲内のオクテットを含む場合であっても、薬をしなければならない中継となるため輸送、及びため輸送、（記事体におけるメッセージ/ RFC822オブジェクト内のヘッダフィールドを含む）未修飾のすべてのヘッダフィールドを搬送しなければなりません彼らは長さが998文字を超えた場合でも、他の薬剤は、特に記事のボディに、ラインを伝えるべきです。 （この要件は、MIME 8ビットのデータよりも厳しい。）これらの要件は、エージェントを投稿剤を注入し、エージェントにサービスを提供し、エージェントを読み取る間の輸送経路を含みます。
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.
多くのニュースサーバーは、エージェントを中継し、薬剤を注入する機能を組み合わせて、単一のソフトウェアパッケージでエージェントサービスを提供しています。本明細書の目的のために、そのような組み合わせ剤は、概念的に中継エージェントに、必要に応じて、配信エージェントに記事を送信し、注射剤として扱われるべきです。ニュースサーバは、これらの薬剤の機能を実行しているときにすべての3つのエージェントの要件がまだ満たされなければなりません。
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:
ニュースの実装と管理者は心に留めておく必要がある2つの重要な原則があります。最初は、よく知られているインターネット頑健性の原理です。
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]の両方の応用に最大限厳密でなければならず、読み取りエージェントが可能であればネットニュース記事フォーマット違反の存在下でロバストであるべきで注入。
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.
ネットニュースプロトコルの主な目的は、すべての読者は、トレースヘッダとローカルメタデータに許容発散別に、（一意のメッセージ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.
物品を処理するときに、すべてのニュースサーバー・コンポーネント（、薬剤を注入剤を中継、およびエージェントをサービング）がパスヘッダフィールドに（[RFC5536]のセクション3.1.5で定義された）それらの<パスアイデンティティ>を付加することで、自分自身を識別しなければなりません。注射剤はまた、彼らは追加注入-Infoヘッダーフィールドに同じIDを使用しなければならない、とサービングと中継エージェントは、追加するすべての外部参照ヘッダフィールドに同じIDを使用すべきです。
The <path-identity> used by an agent may be chosen via one of the following methods (in decreasing order of preference):
エージェントによって使用される<パス同一性>（優先順に）次のいずれかの方法を介して選択することができます。
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 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.
2. A完全修飾ドメイン名（FQDN）エージェントの管理者と提携し、そのドメインの管理者が一意であることが保証ドメイン内。例えば、server.example.orgの一意性は、それ自体をserver.example.orgためのDNSレコードが存在しない場合でも、example.orgの管理者が保証することができます。
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.ユニークであると考えられ、他のすべてのニュースサーバで少なくとも登録<パス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.
いくつかの既存の実装は、大文字と小文字を区別し、大文字と小文字を区別しないなど、いくつかのように、<パスアイデンティティを>扱います。 <パス同一性>したがって、すべて小文字でなければならず、実装は、大文字と小文字を区別せずに識別子を比較する必要があります。
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.
中継またはサービングエージェントが同じニュースサーバの一部であり、注入またはサービングエージェントからの物品を受け取った場合、それは変わらず、物品のパスヘッダフィールドを離れることができます。そうでなければ、すべての中継、注入、又は以下のような物品を受け入れるエージェントにサービスを提供するパスヘッダフィールドを更新する必要があります。パスヘッダフィールドの内容は、要素を付加することによって、右から左に構成されていることに留意されたいです。
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.
前記注入剤は、必要に応じて、続いて<パス診断>「！.POSTED」を先頭に追加すべきです「」そして、パスヘッダフィールドのコンテンツソースの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.中継または薬剤が、以下のように、<パス診断>が選択されているパスヘッダフィールドの内容に<パス診断>を前に付加すべきである働きます。
* 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.
* 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.
*記事の源の期待<パスアイデンティティ>は一致し、使用していない場合は「！.MISMATCH。」ソースまたはそのIPアドレスの期待<パスアイデンティティ>が続きます。
* 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.
*中継またはサービング剤「！.SEEN。」を使用し、<パスアイデンティティ>をチェックして喜んでまたはできない場合FQDN、IPアドレスに続いて、または<パスアイデンティティ>ソースに期待。
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.
物品があった介して接続の特性によって決定<パスアイデンティティ>で注入するか、この中継またはサービング薬剤に記事を渡されたエージェントを中継する、「記事のソースの期待<パスアイデンティティ>」受信された（例えば、認証IDまたはピアIPアドレス）。 [RFC1036]は、<パス診断>含まれていないことに注意してください。この仕様に先行実装は一つだけ追加されます「！」 <パスアイデンティティ>文字列の間の文字。
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ヘッダーフィールドの内容に先頭に追加してもよい（MAY）「！」または "！！"その主なものとは、それ自体のための他の追加の<パス同一>が続きます。 「!!」を使用し、それによって、<パス同一>のではっきり確認され、推奨される<DIAGマッチ>を追加します。このステップは、任意の回数繰り返すことができます。これは、（例えば、1から他への遷移時など）は、複数の<パスアイデンティティ> Sを有する薬剤に許容されます。これらの<path-アイデンティティ>の各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ヘッダフィールドの内容にそのプライマリ<パスアイデンティティ>を付加する必要があり。プライマリ<パスIDが> <パスアイデンティティ>は、それは、通常、<パス診断> 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).
パスヘッダフィールドを変更する任意の薬剤を直ちに<パスアイデンティティ>後（空白折りたたみ）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
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>.
<DIAG-キーワード>「掲示」によって示されるように、この記事では、baz.isp.exampleで注入しました。インジェクタは、それがdialup123.baz.isp.exampleから記事を受け取ったことを記録しています。 「ではない - のためのメール」の共通<テール-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>.
記事は、「barbaz」として、少なくともold.site.exampleすることが、知られている中継エージェントに中継されました。その中継エージェントは「baz.isp.exampleが」<パスアイデンティティ>その<パス診断>のために<DIAG-試合を>（「！」）中古品のソースのため、予想されたことをその満足度を確認しました。
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は<DIAG-キーワード>をサポートしていない、それはold.site.exampleに中継し、したがって、古い使用しました「！」デリミタ。これは、「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の<パスアイデンティティ>を使用して、ニュースサーバーに中継され、それがold.siteから来たことを確認したために（「！」<パス診断を>使用して）と主張します。例。
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のニュースすることが本当に、bar.isp.exampleから来た<DIAG-キーワード>「ミスマッチ」を挿入することを確信していない、それを中継し、それはIPv6アドレスからの記事を受け取ったことを述べました[2001：DB8：0：0：8：800：200C：417A]。 （これは、bar.isp.exampleは、そのソースの正しい<パスアイデンティティ>はなかったが、身元がfoo-ニュースの期待と一致しなかっただけでと言っているわけではありません。）
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-ニュースは、その<パスアイデンティティ>を検証するために拒否しfoo.isp.exampleに記事を、渡され、代わりにそれはisp.exampleとして記事のソースを知って示すために、「SEEN」<DIAG-キーワード>を追加しました。これは、予想される<パス同一>または記事を受信するシステムの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-ニュースは、Pathヘッダフィールドを折ら。
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.
ネットニュースでは、通常、各ニュースサーバが複数のピアへの受け入れの記事を提供し、各ニュースサーバは、複数の他のニュースサーバーから同じ記事を提供することができる、記事の伝播のためのフラッドフィルアルゴリズムを使用しています。したがって、重複抑制が鍵となります。ニュース・サーバは、それが提供されたすべての記事を受け入れた場合、それはすべての記事のコピーの数十を不承諾（そして潜在的に再送信）があります。
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エージェントは、カットオフ期間を選択して、遠くそのカットオフ期間よりも過去の日付のいずれかの記事を拒否することがあります。この間隔は、それがネットワークを介して伝播する記事のために要する時間よりも短い場合、エージェントはまだ見ていないので、それは積極的に短くするべきではないの記事を拒否することがあります。ユーズネットの場合は、例えば、劣らず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.
これらは、最も一般的なものとはいえ、記事履歴のちょうど2つの実装方法です。リレーおよびサービス提供エージェントにのみ複数回の記事を受け付けないの要件を満たすために、これらの戦略を使用する必要はありません。しかし、これらの戦略は、彼らがネットニュースとそのフラッドフィルアルゴリズムの微妙な影響を持つ豊富な経験を持っていない場合は特に、安全で、広く普及しており、実装者はそれらのいずれかを使用することをお勧めします。
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]、およびその他の適用ポリシーに従って、彼らが作ることがproto-記事が有効であることを確認すべきです。彼らはすべての射出-Infoヘッダーフィールドを作成してはいけません。このヘッダーフィールドは、注入剤によって添加してもよいです。
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.
プロト記事がすでに両方のMessage-IDとDateヘッダフィールドが含まれている場合は、投稿の薬剤は、すぐに注射エージェントにそのプロト記事を渡す前に、そのプロト記事への注入-Dateヘッダフィールドを追加するかもしれません。 （プロト品の組成時刻を表す）Dateヘッダーフィールドは、注射の際に、過去に一日以上であれば、彼らはそうするべきです。プロト記事が複数の注入エージェントに提出されている場合、彼らはそうしなければなりません。 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.
射出日付ヘッダフィールドは、ネットニュースプロトコルのこのリビジョンに新規であり、（[RFC5322]のセクション3.6.1で推奨されるように）組成の日付を保持する日付ヘッダーフィールドを可能にするように設計され、プロト物品である場合であってもその組成後しばらくの間に注入してはなりません。しかし、この仕様より以前のすべての実装は、射出Dateヘッダーフィールドを無視し、そのカットオフより古い記事を拒絶するために、その代わりにDateヘッダフィールドを使用します（3.3節を参照）、この仕様より以前の注入物質が射出を追加しないことに注意してくださいDateヘッダー。実質的に過去の日付ヘッダフィールドを持つ物品はまだかかわらず、射出日ヘッダフィールドの、本明細書をより以前の実装によって拒絶され、従って悪い伝播を受けることができます。
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].
Fromヘッダフィールド内のメールボックスまたはメールボックスがポスターやポスターのようであるべき、どんな理由であれ、自分のメールボックスを使用したくないポスターはで終わる任意のメールボックスを使用できることを意味し、[RFC5322]、に反してトップレベルドメイン ".invalid" [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.
プロト記事は、インジェクション・インフォメーションおよび外部参照のヘッダーフィールドが存在してはならないこと以外は、通常の記事と同じフォーマットを持って、Pathヘッダの「掲示」<DIAG-キーワード>を含むべきではないフィールド、および次の必須のいずれかのヘッダフィールドは省略されるかもしれません：メッセージID、日付、およびパス。他のすべての点では、原記事は、有効なネットニュースの記事でなければなりません。具体的には、省略することができるヘッダーフィールドに無効な内容に存在してはなりません。
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をフィールド、日付、および射出日付がproto-記事のすべてのコピーに存在し、同じでなければなりません。 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.
（複数、おそらく互いに素、ネットワークに投稿するときに、たとえば、むらの接続で注入剤を使用するとき、または追加の冗長性を希望する場合）状況によっては、投稿・エージェントは、複数の注入エージェントに同じ記事を提供することを望むかもしれません。この異常な場合には、目標は、複数の独立した記事を作成するのではなく、複数のポイントで同じ記事を注入し、ネットニュースの正常な複製抑制機能をさせないことである（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.
いくつかのケースでは、すべての注入のエージェントに同じプロト品を提供すること（例えば、別のおそらく未接続のいずれかに1つのネットニュースネットワーク上で見つかったゲートウェイ処理、注射後、記事のように）できない場合があります。この場合、投稿のエージェントは、任意の外部参照ヘッダフィールドを削除する必要がありますし、別の注入エージェントに渡す前に、任意の射出情報、パス、およびその他のトレースヘッダフィールドの名前を変更または削除します。 （これはバックプロト物品に物品を変換する。）これは、メッセージID、日付、及び射出日付ヘッダフィールド修飾されていない保持しなければなりません。それは、既存品から欠落している場合には、射出Dateヘッダフィールドを追加してはなりません。
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.
そのニュースグループヘッダフィールド内の1つまたは複数のモデレートニュースグループを一覧表示し、物品の複数の注入はモデレータによって行われるべきであるとプロト記事はそれが掲示されるべきすべてのモデレートグループのためにと後に承認された後にのみ実行されなければなりません承認ヘッダーフィールド（セクション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、フォローはデフォルトで掲載させてはならず、デフォルトでは、前駆体の返信先やから、ヘッダフィールドに指定されたアドレスに電子メールで送信します電子メールの返信[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.ニュースグループヘッダフィールドは、デフォルトでは、前駆体のフォロー-Toヘッダーフィールドから存在している場合は継承されるべきです。それ以外の場合は、前駆体のニュースグループヘッダフィールドから継承されます。
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.件名ヘッダフィールドは、デフォルトでは、前駆体のものから継承されるべきです。大文字と小文字を区別し、文字列「再：」それは既にその文字列で始まる場合を除き（コロンの後のスペースを含む）は、その件名ヘッダフィールドの内容の前に付加されるかもしれません。
NOTE: Prepending "Re: " serves no protocol function and hence
is not required, but it is widely expected and not doing so
would be surprising.
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ヘッダフィールドの内容に続いて、ヘッダーフィールド。親が参照はヘッダていた場合、[RFC5536]で定義されるようFWSは、そのコンテンツおよびメッセージIDヘッダフィールドの内容との間に追加されなければなりません。
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.
得られた参照フィールドは、展開後、（そのフィールド名ではなく、最終的なCRLFを含む）長さが998文字を超えるヘッダ場合は、トリミングされなければならない（そうでなければトリミングすることができます）。最初のメッセージ識別子と最後の二つが除去されてはならないことを除いて、そのコンテンツからのメッセージ識別子の任意の数を除去する手段をトリミング。
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.
上記の手順とREQUIREDによって保証参照ヘッダフィールドの本質的な特性は、このプロトコルへの拡張によって維持されるように、記事では、その両親のいずれかを先行してはならないということです。
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.
注入剤としては、モデレータに投稿・エージェントとのいずれかに転送、それからプロト記事を取るか、またはサービング中継エージェントまたはエージェントに渡します。注射薬は、それが注入どんな記事がネットニュース基準のルールに適合することを確保するための主要な責任を負います。注入物質の管理者は、それが注入エージェントが受け入れるの記事のために接続されたネットニュースネットワークの他の部分へのいくつかの責任を負担することが期待されます。
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:
次のように注射薬がproto-記事を処理します。
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.それは「掲示」<DIAG-キーワード>を含むPathヘッダーフィールドを持つ射出情報または外部参照のヘッダーフィールドを持っているプロト品のための適切な必須ヘッダフィールドを持たない原始の記事を、拒絶しなければなりません[RFC5536]で定義されるように、またはそれは、構文的に有効ではありません。それはネットニュースのために非推奨ヘッダフィールドを含む任意の原始資料を拒否すべきである（参照、例えば、[RFC3798]）。それはそれはすでにインジェクション-情報や射出日付を追加しませんでした注入剤を注射したことを示す痕跡ヘッダフィールド（例えば、NNTP-ポスティング - ホスト）を含む任意のプロト記事を拒否することがあります。
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 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.
3.これは、その射出日付または日付のヘッダフィールド将来に24時間以上である（未満、24時間未満のマージンを使用するかもしれ）任意の物品を拒絶すべきです。それは、その射出-Dateヘッダフィールド（注射剤としては、例えば、使用している中継エージェントのカットオフ期間よりも古い）過去にあまりにも遠い任意の物品を拒否すべきです。いないすべてのニュースサーバのサポート射出日付のみ注入剤としては、ポスティングエージェントに便利なエラーメッセージを提供することができますので、それは同様に、その日付ヘッダフィールドすぎて、過去の任意の記事を拒否すべきです。いずれの場合も、この間隔は、過去に任意のより短い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.これは、ニュースグループヘッダフィールドは、有効なグループのための少なくとも一つの<ニュースグループ名>を含まない任意の原始資料を拒否すべきである、またはそれは、[RFC5536のセクション3.1.4によって特定の目的のために予約<ニュースグループ名>を含みますその具体的な目的や地元の合意がプロト品にも適用されない限り]処理されています。未知のニュースグループにクロスポストは、ニュースグループヘッダ内のニュースグループのうちの少なくとも一つが有効であることを条件とする除外されません。
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.注入剤としては、（コンテンツ転送エンコードの変更を含む）どのような方法で記事の本文を変更してはいけません。それはすでに、ポスターによって提供されていない他のヘッダフィールドを追加してもよい（MAY）が、注射剤には、そのような情報のための射出-Infoヘッダーを使用し、他のヘッダの追加を最小限にすることをお勧めします。これは、変更、削除、またはパスヘッダフィールド以外の任意の既存のヘッダーフィールドの順序を変更すべきではありません。これは、既存のMessage-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.ニュースグループヘッダーが1つまたは複数のモデレート基を含み、プロト記事が承認されたヘッダフィールドが含まれていない場合はそれが不可能な場合は、セクション3.5.1で指定されたかのように、注入エージェントは司会者に転送しなければならないのいずれか、それを拒否。この転送は、必要に応じてメッセージIDおよび日付ヘッダを追加した後、射出-情報および射出日付ヘッダを追加する前に行う必要があります。
8. Otherwise, a Path header field with a <tail-entry> MUST be added if not already present.
8.そうでない場合は、<テールエントリ>とパスヘッダフィールドを追加する必要がある場合はない既に存在します。
9. The injecting agent MUST then update the Path header field as described in Section 3.2.1.
セクション3.2.1に記載したように9注射剤は、パスヘッダフィールドを更新する必要があります。
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.注射-Infoヘッダフィールドは、[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 predates this standard. Otherwise, the injecting agent MUST add an Injection-Date header field containing the current date and time.
プロト記事はすでにインジェクション-Dateヘッダフィールドを持っていた場合は11、それは修正または交換してはなりません。プロト記事がMessage-IDヘッダフィールドとDateヘッダフィールドの両方を持っていた場合プロト記事は乗算、この規格に先行掲載エージェントによって注入された可能性があるため、射出Dateヘッダフィールドは、追加されてはなりません。それ以外の場合は、注入剤としては、現在の日付と時刻を含むインジェクション-Dateヘッダフィールドを追加しなければなりません。
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:
注射薬は、通常、電子メールを経由して、ニュースグループヘッダフィールドにリストされている左端のモデレートグループのモデレータにプロト記事を転送する必要があります。それがこれを行う可能性のある2つの標準的な方法があります。
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.完全プロト物品は、電子メール内で、ヘッダフィールドと全てをカプセル化されます。これは、「中等度」に設定し、使用パラメータを使用してアプリケーション/ニュース送信のContent-Typeの持つ電子メールメッセージを作成することによって行われるべきです。ボディは、メッセージ以外の任意のコンテンツを含めることはできません。この方法は、電子メールを介して輸送中にネットニュースや電子メールのヘッダフィールドとそれらのフィールドへの変更の間の任意の可能な衝突を除去するという利点を有します。
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.
注：グループのモデレータの電子メールアドレスを導出は、この文書の範囲外です。これは、一般的な方法は、多くのモデレートグループのために提出を扱う転送サービスを利用することであること、しかし、言及する価値があります。既存のニュースサーバーとの最大の互換性のために、そのような転送サービスは、一般的に、それぞれ置き換えることによって、モデレートグループの提出アドレスを形成します「」 「 - 」の<ニュースグループ名>にした後、設定されたドメインを付加することにより形成された<メールボックス>の<ローカル部分>としてその値を使用。
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).
送信エージェントを供給するように構成されていない限り、物品は、中継されるべきではなく、受信エージェントはそのニュースグループヘッダフィールドに、Sを<ニュースグループ名>の少なくとも一方を受信するとする<DIST名>の少なくとも一方その分布のヘッダフィールドに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.
不要中継試みを回避するために、物品は、受信エージェントの<パスアイデンティティ>（またはそのいくつかの既知のエイリアス）<テールエントリ>内除く（<パスアイデンティティ>として表示される場合に中継又はれるべきではありませんその経路ヘッダーフィールドに）<ダイアグキーワード>「掲示」以下。
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.これは、ニュースグループヘッダフィールドまたはMessage-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.これは、射出Dateヘッダフィールドを調べたり、不在の場合は、Dateヘッダフィールドを、その日付が将来に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.
セクション3.2.1に記載したように7はパスヘッダフィールドを更新する必要があります。
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.
サービス提供エージェントは中継エージェントから物品を受け入れるか、薬を注入し、それらを格納し、読み取りエージェントで利用できるようにします。物品は、通常、通常進数の形式で、ニュースグループと<物品ロケータ>（[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.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.これは、射出Dateヘッダフィールドを調べたり、不在の場合は、Dateヘッダフィールドを、その日付が将来に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.
セクション3.2.1に記載したように6なお、パスヘッダフィールドを更新する必要があります。
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.それは（特に送信サイトによって設定された■<物品ロケータ>を保存するように構成された場合を除く）各物品から任意の外部参照ヘッダフィールドを削除する必要があります。またその後、MAY新しい外部参照ヘッダフィールドを追加します（ただし、[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).
認識されていない<ニュースグループ名>は、ニュースグループのヘッダーフィールドで発生したというだけの理由サービング剤には、新しいニュースグループを作成してはいけません。ニュースグループは、通常、制御メッセージ（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.
読み取り剤がネットニュースネットワークでのみ受動的に参加しているので、その上に配置された特別なプロトコル要件は存在しません。ベストプラクティスの推奨事項については、[USEAGE]を参照してください。
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.
記事は通常のContent-Typeアプリケーション/ニュース送信の対象としてカプセル化（あるいはカプセル化されますが、明示的にContent-Typeヘッダフィールドなし）のいずれか、電子メールで司会者が受信したか、他に直接、既にすべてのヘッダフィールドを含む電子メールなどされていますネットニュースの記事のための適切な（セクション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.
メッセージを受け入れるか、拒否、またはモデレータがそれを注入する前に、メッセージ（ヘッダ・フィールドと本体の両方）を行うことができる改良部ものに使用されるどのような基準にないプロトコルの制限がありません。推奨されるベストプラクティスは、しかし、必要最小限の変更を行うことがあります。モデレータは記事に加えられた変更は、ポスターや、前のモデレーターによって作成された署名を無効にする可能性があることに注意する必要があります。さらにベストプラクティスの推奨事項については、[USEAGE]を参照してください。
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.彼らは、承認またはプロト記事を拒否し、承認された場合、注射のためのプロト記事を準備するかどうかを決定します。プロト記事が封入されていない電子メールメッセージとして受信された場合、これは有効なネットニュースプロト記事に戻ってそれを変換する必要があります。記事が拒否された場合、それは通常、それが投稿されましたし、さらに何もしていないすべてのニュースグループのために拒否されます。それが承認された場合、モデレータは、次の手順に進みます。
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項の手順に従って行われるべきです。これは、一番左の未承認のニュースグループは、そのフィールドの左端のモデレートニュースグループになるように、ニュースグループヘッダフィールドに<ニュースグループ名> 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.任意のパスヘッダフィールドを除去しなければならないのいずれか、またはもしあれば、その「掲示」<DIAGキーワード>次のエントリのみに切り捨て。
6. The moderator then passes the article to an injecting agent, having first observed all the duties of a posting agent.
6.モデレータは、第1の転記剤のすべての義務を観察有する、注入剤に物品を渡します。
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.
ゲートウェイは、別の媒体のネイティブメッセージフォーマットに記事を変換し、又はニュース記事に別の媒体のメッセージを変換し、または別個のネットニュースネットワークに注入するためのプロト物品に物品を変換します。 MIMEタイプapplication /ニュース送信、またはそのカプセルのその後の取り消しのメッセージにニュース記事のカプセル化、それが物品のない変換を伴わないので、ゲートウェイされません。
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.
ゲートウェイの2つの基本的なタイプ、メッセージの異なるタイプにニュース記事、およびニュース原資料に別のネットワークからのメッセージを変換し、ネットニュースネットワークにそれを注入着信ゲートウェイを変換発信ゲートウェイがあります。これらは、以下に別々に処理されます。
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.
双方向ゲートウェイが（着信と発信のゲートウェイの両方）ネットニュースおよびいくつかの他の媒体との間に設定されている場合、着信および発信ゲートウェイは、ゲート物品の意図しない再注入を回避するために調整されるべきです。円形のゲートウェイ（別の媒体にメッセージをゲートウェイ、次いでバックネットニュースへ）が行われるべきではありません。これが必要な場合、物品のカプセル化が代わりに使用する必要があります。
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.
ネットニュースの観点から、発信ゲートウェイは、読取剤のちょうど特別なタイプです。発信側ゲートウェイが記事に行う必要があります何の正確な性質は、記事がゲーティングされているかにメディアに依存します。それにより、ネットニュースに戻って、その媒体からの着信ゲートウェイを対応する1つまたは複数の可能性ループの危険性を上昇させるので、発信ゲートウェイの動作は、追加の制約を受けます。
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.
ネットニュースへの再注入を防止するように前記メッセージは、何らかの方法でタグ付けされるべきです。これは、潜在的な、着信ゲートウェイの知識なしに行うことは不可能かもしれないが、いくつかの兆候にも成功していない場合を提供しようとする方がよいです。少なくとも、記事では、バックネットニュースにゲートされるべきではない、人間が読み取り可能な表示は人間の問題を見つけることができます。
4. Netnews control messages should not be gated to another medium unless they would somehow be meaningful in that medium.
彼らは何とかその中で意味がない限り4.ネットニュースの制御メッセージは、他のメディアにゲートされるべきではありません。
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.
入ってくるゲートウェイは、二度のゲートに同じメッセージをしてはなりません。マングリングまたはメッセージの変更の面でこれを確保することが可能であるが、非常に少なくともゲートウェイ、（それがすでにゲートされたメッセージのコピーが与えられ、そのトレースヘッダフィールドを除いて同一である場合などではないかもしれネットニュースでメールまたはパスで）受け、再びMUST NOTゲートメッセージを。着信ゲートウェイを図ることができるメッセージの変更によってバイパスこのルールを有するに対する予防措置を取るべきです。
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.
着信ゲートウェイは、そのヘッダフィールドを削除するか名前を変更することなく、制御メッセージ（Controlまたは取って代わるヘッダフィールドを含む物品）を渡してはいけません。ゲートウェイは、しかし、彼らはゲートウェイたメッセージのための制御メッセージをキャンセル発生するかもしれません。ゲートウェイは、それが決定することができるメッセージは、それがゲートウェイされる媒体中に制御をキャンセルメッセージの有効等価で受信した場合、それをゲートウェイなく、そのメッセージを破棄すべきである、独自のキャンセル対応する制御メッセージを生成し、そのキャンセル制御を注入メッセージ。
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ヘッダフィールドと同様の役割を満たすメッセージ識別子がある場合、それはおそらく、ネットニュースの一意性要件を満たすために必要な変換で、ニュース記事のメッセージ識別子の形成に使用されてくださいそして、コメントの除去と[RFC5536]のセクション3.1.3で構文に準拠するようになっています。同じ識別子を持つ2つのメッセージが同じメッセージ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 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.
注：メッセージIDは重複の予防に中心的な役割を果たし、およびゲートウェイによるそれらの正しい使用は、ループを防ぐために多くを行います。ネットニュースは、しかし、そのメッセージの識別子が一意である必要はなく、したがって、他のメディアからのメッセージ識別子をそのまま使用するのに適しないかもしれません。バランスは、ループを防止するために使用される情報を保存し、一意のメッセージ識別子を生成する間のゲートウェイに打たなければなりません。
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.
注：電子メールメッセージの識別子を保持し、どちらも2つの別々のUsenetニュースグループ、に与えられたメーリングリストの2つのゲートウェイの例を考えてみましょう。各ニュースグループは、その後、メッセージ（異なる部分を見る異なる部位）の一部を受け取ることができます。誰も「公式」ゲートウェイが存在しない場合、これらのケースでは、メッセージ識別子を生成する他の方法は、衝突を回避するために使用されなければなりません。クロスポストだけつのゲートウェイが存在することが明らかに好ましいであろうが、これは調整することが可能ではないかもしれません。
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.
何の日付情報が利用できない場合、ゲートウェイは、ゲートウェイの現在の日付をDateヘッダフィールドを供給することができます。部分的にしか情報が入手可能な場合（たとえば、日付ではなく、時間など）、これはデフォルト値を追加することではなく、この情報を廃棄することにより、完全な日に肉付けされるべきである（SHOULD）。それは古いメッセージの再注入を防止する上で重要な役割を果たしているとして、ごく例外的な状況では、廃棄された情報を日付べきです。
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.
入ってくるゲートウェイは、それが<メールボックス>ゲートウェイの管理者を含むことにより形成したニュース記事へのSenderヘッダフィールドを追加しなければなりません。ゲートウェイの問題は、この<メールボックス>に報告することができます。 <表示名>この部分<メールボックス>メッセージの注入を担うエンティティがゲートウェイであることを示すべきです。元のメッセージがすでに送信者ヘッダフィールドを持っていた場合、その内容を保存することができるように、それはオリジナル-Senderに改名されるべきです。そのヘッダフィールドの仕様については、セクション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
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
ヘッダフィールド名：オリジナル-送信者適用プロトコル：ネットニュースのステータス：標準著者/変更コントローラ：IETF仕様書（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.ニュース・ツー・メールゲートウェイは、生成された電子メールメッセージ内のニュース記事のメッセージ識別子を保持します。メール・ツー・ニュースゲートウェイは、同様に、それはネットニュースのための構文的に有効であることを提供し、電子メールメッセージの識別子を保持します。これは、重複のニュースシステムの内蔵抑制は、ループに対する防御の第一線として機能することができます。
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.メール・ツー・ニュースゲートウェイは、それがパスヘッダフィールドの内容に電子メールメッセージを受信したホスト名を付加します。ニュースへのメールゲートウェイは、（テール部分を含む）のPathヘッダフィールドでリストのサーバー名が含まれている任意のメッセージをゲートウェイを拒否します。これは、電子メールが一つだけのホップを通過することを提供し、メーリングリストによるメッセージのヘッダフィールドのいじるの任意の量に対してロバストです。
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に登録されたメディアタイプのメッセージ/ニュースは、ここに廃止されたと宣言されます。このメディアタイプの意図は、人間の読書のためのメールニュース記事を送信する標準的な方法を定義することでした。しかし、それは広く実装されません、それは逆効果だった認識していなかったエージェントによるアプリケーション/オクテットストリームとしてそのデフォルト治療んでした。 （[RFC2046]のセクション5.2.1で定義された）メディアタイプメッセージ/ RFC822は、その場所で使用されるべきです。
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
エンコードの考慮事項：メッセージ/ 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
意図している用法：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.
メディアタイプapplication /ニュース-送信は意図は、受信者が、その後ネットニュースにそれらを注入しなければならないことである完全なニュース記事をカプセル化するためのものです。このアプリケーションタイプは、モデレータに記事を郵送する方法の一つを提供しています（セクション3.5.1を参照）、注入エージェントにメッセージを伝えるために使用することができます。このカプセル化は、ネットニュースのプロト記事に電子メールメッセージを変換する必要性を除去して、8ビットのデータをサポートしていない輸送媒体を介してMIMEを使用してネットニュースの記事を送信する方法を提供します。
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".
オプションのパラメータ：Oneと「利用=中等度」、「利用=ジェクト」、または「利用=リレー」の一つだけ。
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.
ボディ部：ネットニュースや記事への注入の準備ができて完全なプロト記事は、別のエージェントに中継されます。
Applications that use this media type: Injecting agents, Netnews moderators.
注入薬、ネットニュースモデレーター：このメディアタイプを使用するアプリケーション。
Intended usage: COMMON
意図している用法：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.
使用=中等度は注入剤のための注入、および中継エージェントの使用=リレー=使用、物品がモデレータのために意図されていることを示します。物品を受信エンティティは、パラメータを省略することができる場合には、エージェントの一種を実装することができます。
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.
アプリケーション/ニュースGROUPINFOメディアタイプをnewgroup制御メッセージに関連して使用される（セクション5.2.1参照）。ニュースグループ名、説明、およびその節度状況：その体の一部は、ニュースグループについての簡単な情報が含まれています。
The MIME media type definition of application/news-groupinfo is:
アプリケーション/ニュース-GROUPINFOのMIMEメディアタイプの定義は次のとおりです。
MIME type name: application
MIMEタイプ名：アプリケーション
MIME subtype name: news-groupinfo
MIMEサブタイプ名：ニュース-GROUPINFO
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
意図している用法：COMMON
Change controller: IETF
変更コントローラ：IETF
The content of the application/news-groupinfo body part is defined as:
アプリケーション/ニュース-GROUPINFOボディ部の内容は次のように定義されています。
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 +大文字と小文字を区別 "（モデレート）" eightbitテキスト= VARCHAR /％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制御メッセージの本体の走査との下位互換性があります。オプションが、<ニュースグループタグ>は下位互換性のために含まれるべきです。
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.
<ニュースグループ-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.
charsetパラメータは、このメディアタイプのために定義されている間、ほとんどの既存のソフトウェアは、MIMEヘッダフィールドを理解したり、正しく文字セットの様々な記述を処理しません。したがって、推奨される可能性US-ASCIIの文字セットを使用します。可能でない場合、UTF-8 [RFC3629]は使用されるべきです。関係なく使用文字セットの、上記の文法の制約が満たされなければならないと<ニュースグループ名> 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).
アプリケーション/ニュース-checkgroupsメディアタイプは、その説明と節度のステータスを含む階層または階層内のニュースグループのリストが含まれています。これは、主にcheckgroups制御メッセージ（5.2.3項を参照）と共に使用するためのものです。
The MIME media type definition of application/news-checkgroups is:
アプリケーション/ニュース-checkgroupsのMIMEメディアタイプの定義は次のとおりです。
MIME type name: application
MIMEタイプ名：アプリケーション
MIME subtype name: news-checkgroups
MIMEサブタイプ名：ニュース-checkgroups
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
意図している用法：COMMON
Change controller: IETF
変更コントローラ：IETF
The content of the application/news-checkgroups body part is defined as:
アプリケーション/ニュース-checkgroupsボディ部の内容は次のように定義されています。
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.
同じ文字セットの制限、<ニュースグループ名>、および<ニュースグループ記述>アプリケーション/ニュース-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
一つのアプリケーション/ニュース-checkgroupsメッセージは、1つ以上の階層のための情報が含まれていてもよいし、（そのように<chkscope>パラメータとして、その範囲を限定する外部の情報を伴わない限り、それは、<有効なグループが>含まれている任意の階層の完了したと見なされます5.2.3項で説明したようにcheckgroups制御メッセージ）。つまり、アプリケーション/ニュース-checkgroups本体部分は、以下からなります
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 that exist in that hierarchy MUST be listed unless its scope is limited by external information, in which case all groups SHOULD be listed.
声明は、一例ということである。*階層は2つのニュースグループ、example.moderatedとexample.test、無他人が含まれています。このメディアタイプは、したがって、階層に関する部分的な情報を搬送するために使用してはいけません。所定の階層のグループが存在する場合、その範囲は、すべてのグループが表示される必要があり、その場合、外部情報によって制限されない限り、その階層に存在するすべてのグループがリストされなければなりません。
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.
スペースは、フォーマット上の理由から、この例で使用されています。実際のメッセージでは、ニュースグループの名前と説明は、1つ以上のタブ（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ヘッダフィールドの<制御コマンドが>取るべき行動を示し、その詳細を供給する1つ以上の<引数>値は、その<動詞>を含みます。いくつかの制御メッセージについては、記事の本文も重要です。各認識<動詞>（制御メッセージタイプ）は、以下の別のセクションに記載されています。エージェントは、以下の指定されている以外の制御メッセージの種類を受け入れることができ、どちらか無視するか認識できない種類の制御メッセージを拒絶しなければなりません。有効な<引数>の値と制御メッセージ本文に制約の構文定義は、各制御メッセージタイプのセクションに記載されています。
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」で始まる件名ヘッダフィールドの存在は、制御メッセージとして解釈されるべき物品を引き起こしてはなりません。剤は、件名ヘッダフィールドを有している物品とのようなあいまいな無制御ヘッダフィールドを拒否することがあります。同様に、ニュースグループヘッダフィールド、あるいはまた-Controlヘッダーフィールドの存在下で「.CTL」で終わる<ニュースグループ名>の存在は、物品は制御メッセージとして解釈されるべき引き起こしてはなりません。
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.
エージェントは、制御メッセージが尊重されるために独自のローカル認可ポリシーを有することが期待されます。いいえネットニュース・エージェントは、これまで任意の制御メッセージに基づいて行動する必要はありません。以下の説明では、制御メッセージが要求するアクションを指定しますが、エージェントは、常に任意の制御メッセージに作用するように低下する可能性があります。
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制御メッセージ）特定のグループに影響を与えるグループ制御メッセージは、それらのニュースグループヘッダフィールドに影響を受けるグループまたはグループのための<ニュースグループ名>を含むべきです。制御メッセージがより多くのニュースサーバーに到達するよう他のニュースグループは、ニュースグループヘッダフィールドに含まれてもよいが、原因グループ制御メッセージのための特別な中継ルール（セクション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
[ 1*WSP newgroup-flag ] newgroup-flag = "moderated"
[1 * WSP newgroupフラグ] newgroup-フラグ= "緩和します"
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フラグ>の有無に応じて設定されるべきです。 「緩和」は、このプロトコルによって定義された唯一のフラグです。他のフラグは、このプロトコルの拡張によって定義され、エージェントによって受け入れられます。エージェントはnewgroup制御メッセージの<newgroupフラグ>を認識しない場合、その制御メッセージを無視すべきです。
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メッセージの本体は、本体全体としてまたは混合/マルチオブジェクト[RFC2046]内のエンティティのいずれかと、ニュースグループの説明を指定するタイプapplication /ニュースGROUPINFOのエンティティを含むべきです。そのようなエンティティが存在する場合、その中に指定された節度のステータス<newgroupフラグ>によって指定された節度の状態と一致しなければなりません。 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.
「あなたのニュースグループファイルの場合：」アプリケーション/ニュース-GROUPINFO実体がない場合には、ニュース・サーバは、ラインのためのメッセージの本文を検索することができ、および<ニュースグループライン>として次の行を取ります。アプリケーション/ニュース-GROUPINFOの標準化に先立ち、これはニュースグループの説明を提供するための慣例でした。
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の作成を要求するnewgroup制御メッセージ。
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制御メッセージです。 --nxtprtのContent-Type：アプリケーション/ニュースGROUPINFO。文字セット= US-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の。文字セット= US-ASCII
A moderated newsgroup for announcements about new newsgroups in the example.* hierarchy.
例の新しいニュースグループについての発表のためのモデレートニュースグループ。*階層。
--nxtprt--
--nxtprt--
Spaces are used in this example for formatting reasons. In an actual message, the newsgroup name and description MUST be separated by one or more tabs (HTAB, ASCII %d09), not spaces.
スペースは、フォーマット上の理由から、この例で使用されています。実際のメッセージでは、ニュースグループの名前と説明は、1つ以上のタブ（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ヘッダフィールドの構文は次のとおりです。
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ヘッダフィールドの構文は次のとおりです。
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>引数を持つ複雑なケースでは、グループの空のリストから開始し、「！」なし<chkscope>引数に一致するcheckgroups制御メッセージ内のすべてのグループを含めます接頭辞、その後、「！」で<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>引数が指定されていない場合、それはグループ文は、メッセージの本文に表示されているすべての階層に適用されます。
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>小さいと同じ階層または副階層のための後続checkgroups制御メッセージを称えるために、特定の階層または副階層と衰退のために光栄以前checkgroups制御メッセージの<chksernr>値を忘れてはなりません値、あるいは全く<chksernr>の値を持ちます。
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>の長さに上限は存在しません。実装は、したがって、ゼロパディング左の2つの<chksernr>値の短い方をしてからではなく、<chksernr>が数値として操作することができると仮定より、文字列の比較を行うことによって、比較を行うことをお勧めします。
For example, the following Control header field
例えば、以下のような制御ヘッダフィールド
Control: checkgroups de !de.alt #2009021301
コントロール：de.alt番号2009021301のcheckgroups！
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制御メッセージが以前に受賞した場合に表彰されるべきではありません。この例では、シリアル番号がその日以内に2桁のシーケンス番号に続く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 /ニュース-checkgroupsの実体です。これは、適切なMIMEヘッダをそのように宣言する必要がありますが、ニュース・サーバは、体が下位互換性のためにタイプのアプリケーション/ニュース-checkgroupsであったかのように、適切なMIMEヘッダを持たない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ヘッダフィールドの構文は次のとおりです。
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.
キャンセルメッセージを尊重することを選択したサービング剤は、（おそらくそれを完全に削除することにより）、読み取りエージェントに物品が使用できなくするべきです。キャンセル制御メッセージは、記事のそれのターゲットの前に到着した場合、それを尊重することを選択ニュースサーバーは、キャンセルされたメッセージIDを忘れてはならないし、それが到着したときにキャンセルの記事を拒否します。
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]、取消制御メッセージに反して、ターゲット・メッセージに一致するからとSenderヘッダフィールドを含む必要はありません。この要件は、自分のアイデンティティを隠すために発行者をキャンセル奨励し、何のセキュリティを提供しません。
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
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>は、1行につき1つのリストからなります。メッセージ識別子はありませんControlヘッダフィールドに、記事の本文に配置する必要がありますが、ニュース・サーバは、下位互換性のためにControlヘッダフィールドにメッセージ識別子を認識して処理することができます。彼らは、制御メッセージの体内に存在している場合、メッセージ識別子は、Controlヘッダフィールドに入れてはなりません。
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>.
これらの制御メッセージは、通常、他のサイトへ送信される二つのサイトではなく、その後の間のポイントツーポイントの記事として送信されます。始まるニュースグループ「へ。」このようなポイント・ツー・ポイント通信のために予約されており、前に付加することによって形成される「に」。 <中継器名>に<ニュースグループ名>を形成します。そのニュースグループヘッダフィールドで、このようなグループとの記事は、<中継器名>で識別されるもの以外の任意のニュースサーバに送るべきではありません。
The following control message types are declared obsolete by this document and SHOULD NOT be sent or honored:
以下の制御メッセージの種類は、この文書によって廃止されたと宣言され、送信されるべきではないか、光栄：
sendsys version whogets senduuname
sendsysバージョンwhogets 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.
ネットニュースは公共のメッセージの幅広い普及のために設計されており、セキュリティの方法で少しを提供しています。虐待や偽装が基礎となるトランスポート層によって主に提供さに対して何の保護ネットニュースがあります。ニュースサーバは、トランスポート層での認証と承認の要件を強制するために頼ることができない大規模なネットニュースネットワークでは、記事は自明鍛造と広く読まれ、記事の送信者の身元や記事のプライバシーを確保することができないことがあります。
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 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.1節で述べたように、制御メッセージの信頼性を確認するための措置をとるべきです。優先さヘッダーフィールドを含む物品を効果的に制御メッセージをキャンセルされ、セクション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.
すべてのエージェントは、すべての記事の内容は、最も顕著なのControlヘッダフィールドの内容を含め、潜在的に信頼できないと、悪意のあるであることを認識する必要があります。記事は、内部バッファをオーバーフロー隠された仮定に違反し、または実装の弱点を悪用しようとすると文法的に間違った方法で構築することができます。例えば、いくつかのニュースサーバー実装は正常コントロールヘッダフィールドにUnixシェルコードの包含を介して攻撃されています。すべての記事の内容、特に制御メッセージの内容は、取り扱いに注意し、何らかのアクションが記事の内容に基づいて行われる前に厳密に検証する必要があります。
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.
悪意のあるポスターはモデレートニュースグループの緩和プロセスをバイパスする承認ヘッダフィールドを追加することができます。注入剤は、モデレートニュースグループのために承認されたメッセージは、基礎となるトランスポートからの認証情報又はモデレータに配置いくつかの他の認証メカニズムを使用して、モデレータによって注入されていることを確認する必要があります。このような【PGPMOOSE]のようないくつかの標準化されていない認証方法が一般的に使用されているがモデレートグループにメッセージの承認を認証する標準化方法は、現在、存在しません。
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.
ネットニュースネットワークに参加悪意のあるニュースサーバーは、薬剤を注入することによって実行されるチェックを迂回パスヘッダフィールドと、（例えば、注射-Infoヘッダフィールドのような）他のトレース情報を偽造し、そうでない場合はネットニュースネットワークの認可要件を損なうことができます。ニュースサーバは、そのピアを認証し、このプロトコルやネットニュースネットワークの要件に従わない薬を注入し、中継から記事を拒絶する基礎となる交通機関の施設を使用すべきです。
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.
悪意のあるポスターは、そのサイトの原資料<パス同一>のパスヘッダフィールドに含めることによって、特定の部位で見られるから物品を防止することができます。 <DIAG-キーワード>を使用すると、この攻撃を防ぐことができます注入点をマークするための薬剤を注入することによって、「掲示しました」。
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.
このような攻撃を防ぐための主要な責任は、基礎となるトランスポートを経由して認証と認可のチェックを適用し、メッセージを投稿しようからそれらのサービス拒否攻撃を防ぐことができます注入剤です。特定の注入剤には、自分の責任まで生きるために失敗した場合、彼らは彼らから発信記事を拒絶するように中継エージェントを構成することにより、ネットニュースネットワークから除外することができます。
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.
悪質な不平を言う人は、その記事の作者を信用しようとする試みに注入エージェントの管理者に（例えば、変更された射出Infoヘッダーフィールドに）記事の修正されたコピーを提出することができるとさえ彼の投稿権限を削除することを。したがって、管理者は、このような苦情に応じてアクションをとる前に、独自のサービス提供エージェントからの物品の正規のコピーを入手する必要があります。
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]として輸送記事は、おそらく制限境界にサブネットを残すことができ、実質的な管理作業はこれを回避するために必要とされることにより、任意のパスを見つけることで、非常に良いです。そのような漏れを制御したい組織は、外の世界とすべてのニュース交換を処理するためにゲートウェイの小さな数を指定することをお勧めします。
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ツリーにおいて、Content-Typeヘッダフィールドで使用するために、本文書の他の箇所に記載、次のメディアタイプを登録しました。
application/news-transmission (4.1)
application/news-groupinfo (4.2)
application/news-checkgroups (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は、メッセージ/ニュースメディアタイプに「OBSOLETE」のステータスを変更しました。メッセージ/ 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ビットASCII）のための7ビットの米国標準コード」、ANSI X3.4、1986。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート2：メディアタイプ"、RFC 2046、1996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]解放され、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]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、STD 68、RFC 5234、2008年1月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]レズニック、P.、エド。、 "インターネットメッセージ形式"、RFC 5322、2008年10月。
[RFC5536] Murchison, K., Ed., Lindsey, C., and D. Kohn, "Netnews Article Format", RFC 5536, November 2009.
[RFC5536]マーチソン、K.、エド。、リンジー、C.、およびD.コーン、 "ネットニュース記事のフォーマット"、RFC 5536、2009年11月。
[PGPMOOSE] Rose, G., "PGP Moose", November 1998.
[PGPMOOSE]ローズ、G.、 "PGPムース"、1998年11月。
[PGPVERIFY] Lawrence, D., "Signing Control Messages", August 2001, <ftp://ftp.isc.org/pub/pgpcontrol/FORMAT>.
[PGPVERIFY]ローレンス、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.
、RFC 1036、1987年12月 "USENETメッセージの交換のための標準的な" [RFC1036]ホートン、M.およびR.アダムス。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.
[RFC2606]イーストレイク、D.とA. Panitz、 "予約トップレベルDNS名"、BCP 32、RFC 2606、1999年6月。
[RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition Notification", RFC 3798, May 2004.
[RFC3798]ハンセン、T.およびG.ボードルイ、 "メッセージ気質通知"、RFC 3798、2004年5月。
[RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", RFC 3977, October 2006.
[RFC3977]フェザー、C.、 "ネットワークニュース転送プロトコル（NNTP）"、RFC 3977、2006年10月。
[SON-OF-1036] Spencer, H., "News Article Format and Transmission", Work in Progress, May 2009.
[SON-OF-1036]スペンサー、H.、 "ニュース記事のフォーマットと伝送"、進歩、2009年5月での作業。
[USEAGE] Lindsey, C., "Usenet Best Practice", Work in Progress, March 2005.
[USEAGE]リンジー、C.、 "Usenetのベストプラクティス"、進歩、2005年3月に作業。
[UUCP] O'Reilly, T. and G. Todino, "Managing UUCP and Usenet", O'Reilly & Associates Ltd., January 1992.
[UUCP]オライリー、T.およびG. Todino、 "管理UUCPとユーズネット"、オライリー＆アソシエイツ株式会社、1992年1月。
Appendix A. Changes to the Existing Protocols
付録A.既存のプロトコルへの変更します
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節を参照してください。 Pathヘッダの折り畳みが許可されます。
o Trimming of the References header field is REQUIRED, and a mechanism for doing so is defined.
参照のトリミングoをフィールドが必要とされるヘッダと、そうするためのメカニズムが定義されています。
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新しいインジェクション-Dateヘッダーフィールドの追加は、エージェント（3.4.2項）及び注入薬（3.5節）を投稿するため、いくつかの状況で必要とされ、日付チェック（セクション3.6）のためのニュースサーバによって使用されなければなりません。注射剤も強く、新たなインジェクション-Infoヘッダーフィールド内のすべてのローカルトレース情報を入れることが奨励されています。
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取消制御メッセージはもはや、ターゲットメッセージのものと一致するからとSenderヘッダフィールドを持つことが必要とされません。
o The relayer-name parameter in the Control header field of ihave and sendme control messages is now required.
O IHAVEとSENDMEコントロールメッセージのコントロールヘッダフィールドに中継器-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.
加えて、多くのプロトコルステップとunmentionedまたは[RFC1036]で曖昧残っているが、広くネットニュースサーバーによって実装されている物品の検証要件を詳細に標準化し、指定されています。
Appendix B. Acknowledgements
付録B.謝辞
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年の努力とその内容に貢献した人の数の結果を個別に枚挙にいとまがないですです。多くのおかげでは、Internet Engineering Task Force（IETF）のUSEFORワーキンググループとそれに付随するメーリング・リストのすべての過去と現在のメンバーに出かけます。
Special thanks are due to Henry Spencer, whose [SON-OF-1036] draft served as the initial basis for this document.
特別な感謝は、その[SON-OF-1036]ドラフトこの文書の初期の基礎を務めたヘンリー・スペンサー、によるものです。
Authors' Addresses
著者のアドレス
Russ Allbery (editor) Stanford University P.O. Box 20066 Stanford, CA 94309 US
ラスAllbery（エディタ）スタンフォード大学の私書箱20066スタンフォード、CA 94309米国箱
EMail: rra@stanford.edu URI: http://www.eyrie.org/~eagle/
電子メール：rra@stanford.edu URI：http://www.eyrie.org/~eagle/
Charles H. Lindsey 5 Clerewood Avenue Heald Green Cheadle Cheshire SK8 3JU United Kingdom
チャールズH.リンジー5 ClerewoodアベニューヒールドグリーンチードルチェシャーSK8 3JUイギリス
Phone: +44 161 436 6131 EMail: chl@clerew.man.ac.uk
電話：+44 161 436 6131 Eメール：chl@clerew.man.ac.uk