[要約] RFC 5537は、Netnewsのアーキテクチャとプロトコルに関する情報を提供する。その目的は、Netnewsシステムの設計と実装に関するガイドラインを提供し、インターネット上でのニュースグループの配信と交換を効率的に行うための基盤を提供することである。
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
NetNewsアーキテクチャとプロトコル
Abstract
概要
This document defines the architecture of Netnews systems and specifies the correct manipulation and interpretation of Netnews articles by software that originates, distributes, stores, and displays them. It also specifies the requirements that must be met by any protocol used to transport and serve Netnews articles.
このドキュメントでは、NetNewsシステムのアーキテクチャを定義し、NetNewsの記事の正しい操作と解釈を指定します。また、NetNewsの記事を輸送および提供するために使用されるプロトコルによって満たされなければならない要件を指定します。
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
「NetNews」は、[RFC5536]で形式が定義されているニュース「記事」を生成、保存、および取得するためのプロトコルのセットであり、潜在的に広く配布される読者とそれらを交換するためのものです。「ニュースグループ」を中心に編成されており、各読者が彼が参加している各ニュースグループに投稿されたすべての記事を見ることができると期待しています。これらのプロトコルは、参加サーバーのネットワーク全体にコピーを伝播する洪水アルゴリズムを最も一般的に使用しています。通常、サーバーごとに1つのコピーのみが保存され、各サーバーにより、そのサーバーにアクセスできる読者が利用できるようにします。
"Usenet" is a particular worldwide, publicly accessible network based on the Netnews protocols. It is only one such possible network; there are deployments of the Netnews protocols other than Usenet (such as ones internal to particular organizations). This document discusses the more general Netnews architecture and protocols.
「USENET」は、NetNewsプロトコルに基づいて、世界中で公開可能なネットワークです。そのような可能なネットワークの1つにすぎません。Usenet以外のNetNewsプロトコル（特定の組織内の内部など）の展開があります。このドキュメントでは、より一般的なNetNewsアーキテクチャとプロトコルについて説明します。
This document defines the architecture of Netnews systems and specifies the correct manipulation and interpretation of Netnews articles by software that originates, distributes, stores, and displays them. It addresses protocol issues that are independent of transport protocols such as the Network News Transfer Protocol (NNTP) [RFC3977], and specifies the requirements Netnews places on those underlying transport protocols. It also specifies the handling of control messages.
このドキュメントでは、NetNewsシステムのアーキテクチャを定義し、NetNewsの記事の正しい操作と解釈を指定します。ネットワークニュース転送プロトコル（NNTP）[RFC3977]などの輸送プロトコルに依存しないプロトコルの問題に対処し、それらの基礎となる輸送プロトコルにNetNewsが配置する要件を指定します。また、制御メッセージの処理も指定します。
The format and syntax of Netnews articles are specified in [RFC5536], which should be read in conjunction with this document.
NetNewsの記事の形式と構文は[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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
Syntax defined in this document uses the Augmented Backus-Naur Form (ABNF) notation (including the Core Rules) defined in [RFC5234] and constructs defined in [RFC5536] and [RFC5322].
このドキュメントで定義されている構文は、[RFC5234]で定義されている拡張されたBackus-NAURフォーム（ABNF）表記（COREルールを含む）を使用し、[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>
display-name = <see [RFC5322] Section 3.4>
local-part = <see [RFC5322] Section 3.4.1>
mailbox = <see [RFC5322] Section 3.4>
Any term used in this document that is defined in Section 1.5 of [RFC5536] is used with the definition given there. In addition, the following terms will be used:
[RFC5536]のセクション1.5で定義されているこのドキュメントで使用される用語は、そこに与えられた定義とともに使用されます。さらに、次の用語が使用されます。
A "hierarchy" is the set of all newsgroups whose names share a first <component> (as defined in Section 3.1.4 of [RFC5536]). A "sub-hierarchy" is the set of all newsgroups whose names share several initial components.
「階層」は、名前が最初の<コンポーネント>を共有するすべてのニュースグループのセットです（[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回だけ行われます。「複数の注入」は、同じ記事を、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]メールメッセージなど）のメッセージに変換するソフトウェア、他の種類のメッセージを受信してニュース記事に変換するか、2つの別々のNetNewsネットワーク間で記事を伝えます。。
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]は、NetNewsネットワークの最も一般的な輸送メカニズムです。使用中のその他の方法には、UNIX-to-Unixコピープロトコル[UUCP]（USENETの初期に広く使用されています）および物理的に提供された磁気および光学媒体が含まれます。ここで指定された要件を満たすことができれば、このプロトコルと併せて使用することができます。
Transports for Netnews articles MUST treat news articles as uninterpreted sequences of octets, excluding the values %d00 (which may not occur in Netnews articles), %d13, and %d10 (which MUST only appear in Netnews articles as a pair in that order and which, together, denote a line separator). These octets are the US-ASCII [ASCII] characters NUL, CR, and LF respectively.
NetNewsの記事のトランスポートは、ニュース記事をオクテットの解釈されていないシーケンスとして扱う必要があります。一緒に、ラインセパレーターを示します）。これらのオクテットは、それぞれ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]で許可されているオクテットの範囲に対応しています。NetNewsのトランスポートは、MIMEバイナリデータの送信をサポートする必要はありません。
In particular, transports MUST convey all header fields unmodified (including header fields within message/rfc822 objects in article bodies), even if they contain octets in the range of 128 to 255. Furthermore, transports for relaying and serving agents MUST, and transports for other agents SHOULD, convey lines even if they exceed 998 characters in length, especially in article bodies. (This requirement is stricter than MIME 8bit data.) These requirements include the transport paths between posting agents, injecting agents, serving agents, and reading agents.
特に、トランスポートは、128〜255の範囲にオクテットが含まれていても、すべてのヘッダーフィールドを変更していないすべてのヘッダーフィールド（記事本体内のメッセージ/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.
次のセクションでは、NetNewsの記事の作成、中継、提供に関与するエージェントの義務を指定します。このプロトコルは、典型的なUSENETの記事の寿命に従うことによって説明されています。注入剤に与えられ、1人以上の中継剤を介して転送され、サービングエージェントに受け入れられ、最終的にリーディングエージェントによって回収されたポストエージェントによって作成されます。モデレートグループに提出された記事は、追加のプロセスを通過します。これについては、個別に説明します（セクション3.5のセクション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つの重要な原則があります。1つ目は、よく知られているインターネットの堅牢性の原則です。
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.
NetNewsに適用されるように、これは主に望ましくないまたは非準拠していない記事をできるだけ早く拒否する必要があることを意味しますが、それらが一般的に流通していると、情報を失うのではなく、可能な限りそれらを受け入れることを望む場合があります。したがって、投稿剤と注射剤の注射剤は、このプロトコルと[RFC5536]の両方の適用に最大限に厳しくする必要があり、読み取り剤は、可能であればNetNewsの記事形式の違反が存在する場合は堅牢である必要があります。
In the case of Netnews, there is an even more important principle, derived from a much older code of practice, the Hippocratic Oath (we may thus call this the Hippocratic Principle):
NetNewsの場合、はるかに古い実践規範であるヒポクラテスの誓いから派生したさらに重要な原則があります（これをヒポクラテスの原則と呼ぶことができます）。
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.
NetNewsエージェントは、記事を受け入れる必要はありません。ローカルポリシーの理由で、エージェントを注射、中継、およびサービスを提供することは一般的です（特定のニュースグループを運びたくない、不要な記事を除外しようとするなど）。このドキュメントは、記事が受け入れられた場合にどのように扱われるかを指定し、拒否されなければならない場合の一部を指定しますが、エージェントは常にここに記載されている理由以外の理由で記事を拒否することができます。
A primary goal of the Netnews protocol is to ensure that all readers receiving a particular article (as uniquely identified by the content of its Message-ID header field) see the identical article, apart from allowable divergence in trace headers and local metadata. Accordingly, agents (other than moderators) MUST NOT modify articles in ways other than described here. Unacceptable articles MUST be rejected rather than corrected.
NetNewsプロトコルの主な目標は、特定の記事を受け取るすべての読者（メッセージIDヘッダーフィールドの内容によって一意に識別されるように）を確実に確認することです。したがって、エージェント（モデレーター以外）は、ここで説明する以外の方法で記事を変更してはなりません。容認できない記事は、修正されるのではなく拒否されなければなりません。
All news server components (injecting agents, relaying agents, and serving agents) MUST identify themselves, when processing an article, by prepending their <path-identity> (defined in Section 3.1.5 of [RFC5536]) to the Path header field. Injecting agents MUST also use the same identity in Injection-Info header fields that they add, and serving and relaying agents SHOULD use the same identity in any Xref header fields they add.
すべてのニュースサーバーコンポーネント（注入エージェント、リレーエージェント、およびサービングエージェント）は、記事を処理するときに、<パスアイデンティティ>（[RFC5536]のセクション3.1.5で定義）をパスヘッダーフィールドに準備することにより、自分自身を識別する必要があります。注射剤は、追加するインジェクションインフォヘッダーフィールドで同じアイデンティティを使用する必要があり、エージェントにサービスを提供してリレーする必要があります。
The <path-identity> used by an agent may be chosen via one of the following methods (in decreasing order of preference):
エージェントが使用する<パスアイデンティティ>は、次の方法のいずれかを介して選択できます（優先順位の減少）：
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. エージェントの管理者に所属するドメイン内の完全に適格なドメイン名（FQDN）は、そのドメインの管理者によって一意であることが保証されています。たとえば、server.example.orgの管理者がserver.example.org自体にdnsレコードがない場合でも、server.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. A <Path-Nodot>の形式の他の（任意の）名前は、ユニークであると考えられており、少なくともその中継エージェントまたは注射剤が記事を送信する他のすべてのニュースサーバーに登録されています。このオプションは、以前のオプションが利用できない場合、または名前が長年の使用法でない限り、使用しないでください。
Some existing implementations treat <path-identity> as case-sensitive, some as case-insensitive. The <path-identity> therefore SHOULD be all lowercase and implementations SHOULD compare identities case-insensitively.
一部の既存の実装は、<sath-Identity>をケースに敏感なものとして扱い、一部はケースに依存しないものとして扱います。したがって、<パスアイデンティティ>はすべて小文字である必要があり、実装はケースインスセンシックでアイデンティティを比較する必要があります。
If a relaying or serving agent receives an article from an injecting or serving agent that is part of the same news server, it MAY leave the Path header field of the article unchanged. Otherwise, every injecting, relaying, or serving agent that accepts an article MUST update the Path header field as follows. Note that the Path header field content is constructed from right to left by prepending elements.
リレーまたはサービングエージェントが、同じニュースサーバーの一部である注射またはサービングエージェントから記事を受け取った場合、記事のパスヘッダーフィールドを変更しておくことができます。それ以外の場合は、記事を受け入れるすべての注入、中継、またはサービングエージェントは、次のようにパスヘッダーフィールドを更新する必要があります。パスヘッダーフィールドコンテンツは、要素を準備することにより、右から左に構築されていることに注意してください。
1. The agent MUST prepend "!" to the Path header field content.
1. エージェントは「！」を準備する必要があります。パスヘッダーフィールドコンテンツへ。
2. An injecting agent SHOULD prepend the <path-diagnostic> "!.POSTED", optionally followed by "." and the FQDN or IP address of the source, to the Path header field content.
2. 注入剤は、<path-diagnostic> "！.posted"をpreatend "、ottional" "。ソースの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. 中継またはサービングエージェントは、<sath-diagnostic>が次のように選択されるパスヘッダーフィールドコンテンツに<path-diagnostic>を準備する必要があります。
* If the expected <path-identity> of the source of the article matches the leftmost <path-identity> of the Path header field's content, use "!" (<diag-match>), resulting in two consecutive "!"s.
* 記事のソースの予想される<パスアイデンティティ>が、パスヘッダーフィールドのコンテンツの左端<パスアイデンティティ>と一致する場合、「！」（<diag-match>）、2つの連続した「！」
* 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.
* 中継またはサービングエージェントが<sath-Identity>をチェックする意思がないか、または確認できない場合は、「！.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.
記事のソースの「予想される<パスアイデンティティ>」は、記事をこの中継またはサービングエージェントに渡した注入または中継エージェントの<パスアイデンティティ>です。受信（たとえば、認証アイデンティティまたはピアIPアドレス）。[rfc1036]には<path-diagnostic>が含まれていないことに注意してください。この仕様より前の実装では、単一の「！」のみが追加されます。<sath-identity>文字列の間の文字。
4. The agent MAY then prepend to the Path header field content "!" or "!!" followed by an additional <path-identity> for itself other than its primary one. Using "!!", and thereby adding a <diag-match> since the <path-identity> clearly is verified, is RECOMMENDED. This step may be repeated any number of times. This is permitted for agents that have multiple <path-identity>s (such as during a transition from one to another). Each of these <path-identity>s MUST meet the requirements set out in Section 3.2.
4. エージェントは、パスヘッダーフィールドコンテンツ「！」にプレイエンドすることができます。また "！！"その後、その主要なもの以外の追加<パスアイデンティティ>が続きます。「!!」を使用して、<sath-Identity>が明確に検証されるため、<diag-match>を追加することをお勧めします。このステップは、何度も繰り返される場合があります。これは、複数の<パスアイデンティティ> sを持つエージェントで許可されています（1つから別のものへの移行中など）。これらのそれぞれ<パスアイデンティティ>は、セクション3.2に記載されている要件を満たす必要があります。
5. Finally, the agent MUST prepend its primary <path-identity> to the Path header field content. The primary <path-identity> is the <path-identity> it normally advertises to its peers for their use in generating <path-diagnostic>s as described above.
5. 最後に、エージェントは、プライマリ<Path-Identity>をパスヘッダーフィールドコンテンツにプレップする必要があります。プライマリ<パスアイデンティティ>は、上記のように<sath-diagnostic> sを生成する際に使用するために通常、同僚に宣伝する<パスアイデンティティ>です。
Any agent that modifies the Path header field MAY fold it by inserting FWS (folding white space) immediately after any <path-identity> or <diag-other> it added (see Section 3.1.5 of [RFC5536] for allowable locations for FWS).
パスヘッダーフィールドを変更するエージェントは、FWSの許容場所については[RFC5536]のセクション3.1.5を参照して、<パスアイデンティティ>または<diag-other>の直後にFWS（折りたたみホワイトスペース）を挿入することで折りたたむことができます。）。
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-keyword>「投稿」で示されているように、baz.isp.exampleによって注入されました。インジェクターは、dialup123.baz.isp.exampleから記事を受け取ったことを記録しました。「Not-for-mail」は一般的な<tail-entry>です。
The article was relayed to the relaying agent known, at least to old.site.example, as "barbaz". That relaying agent confirmed to its satisfaction that "baz.isp.example" was an expected <path-identity> for the source of the article and therefore used <diag-match> ("!") for its <path-diagnostic>.
この記事は、少なくともold.site.exampleに、「barbaz」として知られている中継剤に中継されました。その中継エージェントは、「baz.isp.example」が記事のソースに対して予想される<パスアイデンティティ>であり、したがって<path-dianostic>に<diag-match>（ "！"）を使用したことを満足させたことを確認しました。
barbaz relayed it to old.site.example, which does not support <diag-keyword> and therefore used the old "!" delimiter. This indicates that the identity of "barbaz" was not verified and may have been forged.
BarbazはそれをOld.site.exampleに中継しました。これは<diag-keyword>をサポートせず、したがって古い「！」を使用しました。デリミタ。これは、「バルバズ」のアイデンティティが検証されておらず、偽造された可能性があることを示しています。
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の<sath-identity>を使用してニュースサーバーに中継し、（ "<path-diagnostic>を使用して）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-newsに中継しましたが、それは本当にbar.isp.exampleから来たと確信していません。[2001：db8：0：0：8：800：200c：417a]。（これは、bar.isp.exampleがそのソースにとって正しい<パスアイデンティティ>ではなく、単にアイデンティティがfoo-newsの期待と一致しなかったということではありません。）
foo-news then passed the article to foo.isp.example, which declined to validate its <path-identity> and instead appended the <diag-keyword> "SEEN" to indicate it knows the source of the article as isp.example. This may be either an expected <path-identity> or the FQDN of the system from which it received the article. Presumably, foo.isp.example is a serving agent that then delivered the article to a reading agent.
その後、Foo-newsは記事をfoo.isp.exampleに渡しました。これはその<path-Identity>の検証を拒否し、代わりに<diag-keyword> "seed"を掲載して、記事のソースをisp.exampleとして知っていることを示しました。これは、記事を受け取ったシステムの予想される<パスアイデンティティ>またはFQDNのいずれかです。おそらく、foo.isp.exampleはサービングエージェントであり、その後、読み取りエージェントに記事を届けました。
baz.isp.example, bar.isp.example, and foo-news folded the Path header field.
baz.isp.example、bar.isp.example、およびfoo-newsがパスヘッダーフィールドを折りたたみました。
Netnews normally uses a flood-fill algorithm for propagation of articles in which each news server offers the articles it accepts to multiple peers, and each news server may be offered the same article from multiple other news servers. Accordingly, duplicate suppression is key; if a news server accepted every article it was offered, it may needlessly accept (and then potentially retransmit) dozens of copies of every article.
NetNewsは通常、各ニュースサーバーが複数のピアに受け入れる記事を提供し、各ニュースサーバーに他の複数のニュースサーバーから同じ記事を提供できる記事の伝播に洪水充填アルゴリズムを使用します。したがって、重複抑制が重要です。ニュースサーバーが提供されたすべての記事を受け入れた場合、すべての記事の数十部のコピーを不必要に受け入れる（そして潜在的に再送信する）可能性があります。
Relaying and serving agents therefore MUST keep a record of articles they have already seen and use that record to reject additional offers of the same article. This record is called the "history" file or database.
したがって、エージェントを中継およびサービングすることで、彼らがすでに見た記事の記録を保持し、その記録を使用して、同じ記事の追加オファーを拒否する必要があります。このレコードは、「履歴」ファイルまたはデータベースと呼ばれます。
Each article is uniquely identified by its message identifier, so a relaying or serving agent could satisfy this requirement by storing a record of every message identifier that agent has ever seen. Such a history database would grow without bound, however, so it is common and permitted to optimize based on the Injection-Date or Date header field of an article as follows. (In the following discussion, the "date" of an article is defined to be the date represented by its Injection-Date header field, if present; otherwise, by its Date header field.)
各記事はメッセージ識別子によって一意に識別されるため、エージェントがこれまでに見たすべてのメッセージ識別子のレコードを保存することにより、リレーまたはサービングエージェントがこの要件を満たすことができます。ただし、このような履歴データベースは拘束されずに成長するため、次のように記事の注入日または日付ヘッダーフィールドに基づいて最適化することが一般的であり、最適化することが許可されています。（次の議論では、記事の「日付」は、存在する場合、その注入日ヘッダーフィールドで表される日付であると定義されています。
o Agents MAY select a cutoff interval and reject any article with a date farther in the past than that cutoff interval. If this interval is shorter than the time it takes for an article to propagate through the network, the agent might reject an article it had not yet seen, so it ought not to be aggressively short. For Usenet, for example, a cutoff interval of no less than seven days is conventional.
o エージェントは、カットオフ間隔を選択し、そのカットオフ間隔よりも過去の日付の記事を拒否することができます。この間隔が、記事がネットワークを介して伝播するのにかかる時間よりも短い場合、エージェントはまだ見たことのない記事を拒否する可能性があるため、積極的に短くするべきではありません。たとえば、Usenetの場合、7日以上のカットオフ間隔は従来です。
o Agents that enforce such a cutoff MAY then drop records of articles that had dates older than the cutoff from their history databases. If such an article were offered to the agent again, it would be rejected due to the cutoff date, so the history record is no longer required to suppress the duplicate.
o そのようなカットオフを強制するエージェントは、履歴データベースからカットオフよりも古い記事の記録を削除する可能性があります。そのような記事が再びエージェントに提供された場合、それはカットオフ日のために拒否されるため、履歴記録は重複を抑制するためにもはや必要ありません。
o Alternatively, agents MAY drop history records according to the date when the article was first seen by that agent rather than the date of the article. In this case, the history retention interval MUST be at least 24 hours longer than the cutoff interval to allow for articles dated in the future. This interval matches the allowable error in the date of the article (see Section 3.5).
o あるいは、エージェントは、記事が記事の日付ではなく、そのエージェントによって最初に見られた日付に応じて履歴記録を削除する場合があります。この場合、将来の記事を可能にするために、履歴保持間隔はカットオフ間隔より24時間以上長くなければなりません。この間隔は、記事の日付の許容エラーと一致します（セクション3.5を参照）。
These are just two implementation strategies for article history, albeit the most common ones. Relaying and serving agents are not required to use these strategies, only to meet the requirement of not accepting an article more than once. However, these strategies are safe and widely deployed, and implementors are encouraged to use one of them, especially if they do not have extensive experience with Netnews and the subtle effects of its flood-fill algorithm.
これらは、最も一般的なものではありますが、記事履歴の2つの実装戦略にすぎません。エージェントの中継とサービングは、これらの戦略を使用する必要はなく、記事を複数回受け入れないという要件を満たすためだけに使用する必要はありません。ただし、これらの戦略は安全で広く展開されており、実装者はそのいずれかを使用することが奨励されています。特に、NetNewsとその洪水充填アルゴリズムの微妙な効果に関する豊富な経験がない場合。
A posting agent is the component of a user agent that assists a poster in creating a valid proto-article and forwarding it to an injecting agent.
投稿エージェントは、有効なプロトアーティクルの作成を支援し、注入剤に転送するユーザーエージェントのコンポーネントです。
Posting agents SHOULD ensure that proto-articles they create are valid according to [RFC5536] and any other applicable policies. They MUST NOT create any Injection-Info header field; this header field may only be added by the injecting agent.
投稿エージェントは、作成したプロトアーティクルが[RFC5536]およびその他の適用可能なポリシーに従って有効であることを確認する必要があります。注入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.
Proto-Articleが既にメッセージ-IDヘッダーフィールドと日付ヘッダーフィールドの両方を含んでいる場合、投稿するエージェントは、そのプロトアーティクルを注入剤に渡す直前に、そのプロトアーティクルに注入日付ヘッダーフィールドを追加する場合があります。日付ヘッダーフィールド（プロトアーティクルの組成時間を表す）が、注射時の過去の1日以上の場合、そうする必要があります。プロトアーティクルが複数の注入剤に提出されている場合、彼らはそうしなければなりません。セクション3.4.2を参照してください。
The Injection-Date header field is new in this revision of the Netnews protocol and is designed to allow the Date header field to hold the composition date (as recommended in Section 3.6.1 of [RFC5322]), even if the proto-article is not to be injected for some time after its composition. However, note that all implementations predating this specification ignore the Injection-Date header field and use the Date header field in its stead for rejecting articles older than their cutoff (see Section 3.3), and injecting agents predating this specification do not add an Injection-Date header. Articles with a Date header field substantially in the past will still be rejected by implementations predating this specification, regardless of the Injection-Date header field, and hence may suffer poorer propagation.
インジェクションデートヘッダーフィールドは、NetNewsプロトコルのこの改訂版で新しく、日付ヘッダーフィールドが構成日を保持できるように設計されています（[RFC5322]のセクション3.6.1で推奨されているように）。組成後しばらく注入されないようにします。ただし、この仕様に先行するすべての実装は、注入日付ヘッダーフィールドを無視し、その代わりに日付ヘッダーフィールドを使用して、カットオフよりも古い記事を拒否し（セクション3.3を参照）、この仕様に先立つ注入剤を注入剤は追加しないことに注意してください。日付ヘッダー。日付ヘッダーフィールドのある記事は、注入日付ヘッダーフィールドに関係なく、この仕様に先行する実装によって依然として拒否され、したがって繁殖が悪化する可能性があります。
Contrary to [RFC5322], which implies that the mailbox or mailboxes in the From header field should be that of the poster or posters, a poster who does not, for whatever reason, wish to use his own mailbox MAY use any mailbox ending in the top-level domain ".invalid" [RFC2606].
[RFC5322]に反して、これは、ヘッダーフィールドのメールボックスまたはメールボックスがポスターまたはポスターのメールボックスである必要があることを意味します。トップレベルのドメイン ".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.
通常のポスターが使用することを目的とした投稿エージェントは、ポスターが著者または送信者ではない別の記事をキャンセルまたはスーパーデス（Supersedes Headerフィールドを介して）キャンセルまたはスーパーデスを投稿する試みを拒否する必要があります。
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.
Proto-Articleは、注入剤にその記事を提供する際に、投稿エージェントが使用する形式の記事です。注入剤によってよりよく供給される可能性のある特定のヘッダーフィールドを省略することができ、注入剤によって追加されるヘッダーフィールドは含まれません。プロトアーティクルは、注入剤への伝送専用であり、他の剤に送信するべきではありません。
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.
プロトアーティクルは、注入INFOおよびXREFヘッダーフィールドが存在してはならないことを除いて、通常の記事と同じ形式を持っています。パスヘッダーフィールドには「投稿」<diag-keyword>、および次のいずれかが必須のいずれかを含めるべきではありません。ヘッダーフィールドは省略できます：メッセージ-ID、日付、およびパス。他のすべての点において、プロトアーティクルは有効なNetNewsの記事でなければなりません。特に、省略される可能性のあるヘッダーフィールドに、無効なコンテンツが存在しないでください。
If a posting agent intends to offer the same proto-article to multiple injecting agents, the header fields Message-ID, Date, and Injection-Date MUST be present and identical in all copies of the proto-article. See Section 3.4.2.
投稿エージェントが複数の注入剤に同じプロトアーティクルを提供する場合、ヘッダーフィールドメッセージメッセージ、日付、および注入日は、プロトアーティクルのすべてのコピーに存在し、同一でなければなりません。セクション3.4.2を参照してください。
Under some circumstances (for example, when posting to multiple, supposedly disjoint, networks, when using injecting agents with spotty connectivity, or when desiring additional redundancy), a posting agent may wish to offer the same article to multiple injecting agents. In this unusual case, the goal is not to create multiple independent articles but rather to inject the same article at multiple points and let the normal duplicate suppression facility of Netnews (see Section 3.3) ensure that any given agent accepts the article only once, even if supposedly disjoint networks have unexpected links.
状況によっては（たとえば、むらのある接続性の注入剤を使用する場合、または追加の冗長性を希望する場合、複数の、おそらくばらばらのネットワークに投稿する場合）。この異常なケースでは、目標は複数の独立した記事を作成するのではなく、複数のポイントで同じ記事を注入し、NetNewsの通常の複製抑制施設（セクション3.3を参照）に、特定のエージェントが記事を一度だけ受け入れるようにすることです。おそらく分離ネットワークに予期しないリンクがある場合。
Whenever possible, multiple injection SHOULD be done by offering the same proto-article to multiple injecting agents. The posting agent MUST supply the Message-ID, Date, and Injection-Date header fields, and the proto-article as offered to each injecting agent MUST be identical.
可能な場合はいつでも、複数の注射剤に同じプロトアーティクルを提供することにより、複数の注入を行う必要があります。投稿エージェントは、メッセージ-ID、日付、および噴射期のヘッダーフィールドを提供する必要があり、各注入剤に提供されるプロトアーティクルは同一でなければなりません。
In some cases, offering the same proto-article to all injecting agents may not be possible (such as when gatewaying, after injection, articles found on one Netnews network to another supposedly unconnected one). In this case, the posting agent MUST remove any Xref header field and rename or remove any Injection-Info, Path, and other trace header fields before passing it to another injecting agent. (This converts the article back into a proto-article.) It MUST retain unmodified the Message-ID, Date, and Injection-Date header fields. It MUST NOT add an Injection-Date header field if it is missing from the existing article.
場合によっては、すべての注入剤に同じプロトアーティクルを提供することは不可能かもしれません（注射後、ゲートウェイングの場合、あるNetNewsネットワークにある記事が別のネットワークに含まれていないと思われるものにあります）。この場合、投稿エージェントはXREFヘッダーフィールドを削除し、別の注入エージェントに渡す前に、INFO、PATH、およびその他のトレースヘッダーフィールドを変更または削除する必要があります。（これにより、記事をプロトアーティクルに変換します。）メッセージ-ID、日付、およびインジェクションデートのヘッダーフィールドを修正していないことを保持する必要があります。既存の記事から欠落している場合、インジェクションデートのヘッダーフィールドを追加してはなりません。
NOTE: Multiple injection inherently risks duplicating articles. Multiple injection after injection, by converting an article back to a proto-article and injecting it again, additionally risks loops, loss of trace information, unintended repeat injection into the same network, and other problems. It should be done with care and only when there is no alternative. The requirement to retain Message-ID, Date, and Injection-Date header fields minimizes the possibility of a loop and ensures that the newly injected article is not treated as a new, separate article.
注：複数の注入は、本質的に記事の複製リスクを負います。注射後の複数の注入、記事を原始粒子に戻し、再び注入することにより、さらにループのリスク、痕跡情報の喪失、意図しない繰り返し注入、および同じネットワークへの繰り返し注入、およびその他の問題。代替手段がない場合にのみ、注意して行う必要があります。メッセージ-ID、日付、およびインジェクションデートのヘッダーフィールドを保持するための要件は、ループの可能性を最小限に抑え、新しく注入された記事が新しい別の記事として扱われないことを保証します。
Multiple injection of an article that lists one or more moderated newsgroups in its Newsgroups header field SHOULD only be done by a moderator and MUST only be done after the proto-article has been approved for all moderated groups to which it is to be posted and after an Approved header field has been added (see Section 3.9). Multiple injection of an unapproved article intended for moderated newsgroups will normally only result in the moderator receiving multiple copies, and if the newsgroup status is not consistent across all injecting agents, may result in duplication of the article or other problems.
ニュースグループヘッダーフィールドに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.
フォローアップは、以前の記事の内容であるその前駆体に対する回答を含む記事です。通常の義務に加えて、フォローアップを準備する投稿エージェントには、以下の要件も適用されます。以下の場合は、デフォルトでは、ヘッダーフィールドは前駆体のヘッダーフィールドの1つから継承されていると言われていると言われています。これは、その初期コンテンツがその前駆体ヘッダーフィールドのコンテンツのコピーであることを意味します。折りたたみの変更が許可されています）。ただし、ポスターは投稿する前にそのデフォルトをオーバーライドする場合があります。
Despite the historic practice of some posting agents, the Keywords header field SHOULD NOT be inherited by default from the precursor article.
一部の投稿エージェントの歴史的な慣行にもかかわらず、キーワードヘッダーフィールドは、Precursorの記事からデフォルトで継承されるべきではありません。
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. NewsGroups Headerフィールドは、デフォルトでは、存在する場合はPrecursorのフォローアップヘッダーフィールドから継承する必要があります。それ以外の場合は、PrecursorのNewsGroups Headerフィールドから継承されます。
3. The Subject header field SHOULD, by default, be inherited from that of the precursor. The case-sensitive string "Re: " (including the space after the colon) MAY be prepended to the content of its Subject header field unless it already begins with that string.
3. サブジェクトヘッダーフィールドは、デフォルトでは、前駆体のフィールドから継承する必要があります。ケースに敏感な文字列「Re：」（コロンの後のスペースを含む）は、すでにその文字列で始まっていない限り、サブジェクトヘッダーフィールドの内容に加えられる場合があります。
NOTE: Prepending "Re: " serves no protocol function and hence is not required, but it is widely expected and not doing so would be surprising.
注：「Re：」の準備はプロトコル機能を提供しないため、必要ありませんが、広く期待されており、そうしないと驚くべきことです。
4. The Distribution header field SHOULD, by default, be inherited from the precursor's Distribution header field, if present.
4. ディストリビューションヘッダーフィールドは、デフォルトでは、存在する場合は、前駆体の配布ヘッダーフィールドから継承する必要があります。
5. The followup MUST have a References header field referring to its precursor, constructed in accordance with Section 3.4.4.
5. フォローアップには、セクション3.4.4に従って構築された、その前駆体を参照する参照ヘッダーフィールドが必要です。
The following procedure is to be used whenever some previous article (the "parent") is to be referred to in the References header field of a new article, whether because the new article is a followup and the parent is its precursor or for some other reason.
新しい記事が新しい記事の参照ヘッダーフィールドで、新しい記事がフォローアップであり、親がその前駆体であるか他のいくつかのために、以前の記事（「親」）が新しい記事の参照ヘッダーフィールドで参照される場合はいつでも、次の手順を使用します。理由。
The content of the new article's References header field MUST be formed from the content of the parent's References header field if present, followed by the content of the Message-ID header field of the parent. If the parent had a References header, FWS as defined in [RFC5536] MUST be added between its content and the Message-ID header field content.
新しい記事の参照ヘッダーフィールドの内容は、存在する場合は親の参照ヘッダーフィールドのコンテンツから形成する必要があり、その後、親のメッセージ-IDヘッダーフィールドのコンテンツが続きます。親が参照ヘッダーを持っていた場合、[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.
結果の参照ヘッダーフィールドが、展開後、長さ998文字を超える場合（そのフィールド名を含むが最終的なCRLFを含む）、トリミングする必要があります（そうでなければトリミングすることができます）。トリミングとは、最初のメッセージ識別子と最後の2つを削除してはならないことを除いて、コンテンツから任意の数のメッセージ識別子を削除することを意味します。
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.
上記の手順によって保証され、このプロトコルの拡張によって維持される必要がある参照ヘッダーフィールドの重要なプロパティは、記事がその親の1人の前に先行してはならないということです。
An injecting agent takes a proto-article from a posting agent and either forwards it to a moderator or passes it to a relaying or serving agent or agents. An injecting agent bears the primary responsibility for ensuring that any article it injects conforms with the rules of the Netnews standards. The administrator of an injecting agent is also expected to bear some responsibility towards the rest of the Netnews network to which it is connected for the articles the injecting agent accepts.
注入剤は、ポジションエージェントからプロトアーティクルを取り、モデレーターに転送するか、リレーまたはサービングエージェントまたはエージェントに渡します。注射剤は、注入する記事がNetNews規格の規則に準拠することを保証するための主要な責任を負います。注入剤の管理者は、注射剤が受け入れる記事に接続されているNetNewsネットワークの残りの部分に対して何らかの責任を負うことが期待されています。
Injecting agents, when rejecting articles, are encouraged to communicate the reason for rejection to the posting agent by using whatever facility is provided by the underlying transport. The injecting agent is in a unique position to communicate the reason for rejection; relaying agents and serving agents normally have to reject messages silently. The injecting agent therefore bears much of the burden of diagnosing broken posting agents or communicating policy violations to posters.
噴射剤は、記事を拒否する場合、基礎となる輸送によって提供される施設を使用して、郵便局に拒否の理由を伝えることをお勧めします。注入剤は、拒絶の理由を伝えるためのユニークな立場にあります。通常、エージェントとサービングエージェントを中継する必要があります。通常、メッセージを静かに拒否する必要があります。したがって、注射剤は、壊れた投稿剤を診断したり、ポスター違反をポスターに伝えたりするという負担の多くを負担します。
An injecting agent MUST have available a list (possibly empty) of moderated groups for which it accepts articles and the corresponding submission addresses. It SHOULD have available a list of valid newsgroups to catch articles not posted to a valid newsgroup and therefore likely to be silently discarded by relaying and serving agents. Usually, an injecting agent is deployed in conjunction with a serving agent and maintains these lists based on control messages received by the serving agent.
注入剤には、記事と対応する提出アドレスを受け入れるモデレートグループのリスト（おそらく空）が必要です。有効なニュースグループに投稿されていない記事をキャッチするために、有効なニュースグループのリストが利用可能である必要があります。通常、注入剤はサービングエージェントと併せて展開され、サービングエージェントが受信したコントロールメッセージに基づいてこれらのリストを維持します。
An injecting agent processes proto-articles as follows:
注射剤は次のように原articlic角を処理します：
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. プロトアルティクルの適切な必須ヘッダーフィールド、インジェクションインフォまたはXREFヘッダーフィールドがある、「投稿された」<Diag-keorword>、または「diag-keyword>」を含むパスヘッダーフィールドがあるプロトーティクルを拒否する必要があります。これは、[RFC5536]で定義されているように構文的に有効ではありません。NetNewsが非推奨されているヘッダーフィールドを含むプロトアーティクルを拒否する必要があります（たとえば[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時間以内にマージンを使用する可能性がある）記事を拒否する必要があります。注入日付のヘッダーフィールドが過去に遠すぎる記事（たとえば、注入剤が使用している中継剤のカットオフ間隔よりも古い記事を拒否する必要があります。すべてのニュースサーバーがインジェクション日付をサポートしているわけではなく、注入剤のみが投稿エージェントに有用なエラーメッセージを提供できるため、日付ヘッダーフィールドが過去に遠すぎる記事を同様に拒否する必要があります。どちらの場合でも、この間隔は過去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. ニュースグループヘッダーフィールドに有効なグループに少なくとも1つの<NewsGroup-Name>が含まれていないか、[RFC5536]のセクション3.1.4によって特定の目的のために予約されている<NewsGroup-Name>が含まれているプロトーチクルを拒否する必要があります。その特定の目的またはローカル契約は、処理されているプロトアーティクルに適用されます。不明なニュースグループへのクロスポストは、NewsGroupsヘッダーのニュースグループの少なくとも1つが有効であることを条件に排除されていません。
5. The Message-ID and Date header fields with appropriate contents MUST be added when not present in the proto-article.
5. Proto-Articleに存在しない場合、適切なコンテンツを持つメッセージ-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. 注入剤は、記事の本文をいかなる方法でも変更してはなりません（コンテンツ移動エンコードの変更を含む）。ポスターによってまだ提供されていない他のヘッダーフィールドを追加する可能性がありますが、注入剤は、そのような情報に注入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. NewsGroups Headerに1つ以上のモデレートグループが含まれており、Proto-Articleには承認されたヘッダーフィールドが含まれていない場合、注入剤はセクション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.
9. 注入剤は、セクション3.2.1で説明されているように、パスヘッダーフィールドを更新する必要があります。
10. An Injection-Info header field SHOULD be added that identifies the source of the article and possibly other trace information as described in Section 3.2.8 of [RFC5536].
10. [RFC5536]のセクション3.2.8で説明されているように、記事のソースと、おそらく他のトレース情報を識別する注入INFOヘッダーフィールドを追加する必要があります。
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.
11. Proto-Articleに既に注入日付ヘッダーフィールドがある場合は、変更または交換してはなりません。Proto-Articleにメッセージ-IDヘッダーフィールドと日付ヘッダーフィールドの両方がある場合、この基準に先行するポストエージェントによってプロトアティクルが増殖した可能性があるため、注入日付ヘッダーフィールドを追加してはなりません。それ以外の場合、注射剤は、現在の日付と時刻を含むインジェクションデートヘッダーフィールドを追加する必要があります。
12. Finally, the injecting agent forwards the article to one or more relaying agents, and the injection process is complete.
12. 最後に、注入剤は記事を1つ以上の中継剤に転送し、注入プロセスが完了します。
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:
注射剤は、慣習的に電子メールで、NewsGroups Headerフィールドにリストされている左端のモデレートグループのモデレーターに、プロトアーティクルを転送する必要があります。これを行うには、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. 完全なプロトアーティクルは、電子メール内でカプセル化されたヘッダーフィールドなどです。これは、[Moderate]に設定されている使用パラメーターを使用して、コンテンツタイプのアプリケーション/ニューストランスミッションを使用して電子メールメッセージを作成することで実行する必要があります。ボディには、メッセージ以外のコンテンツを含めるべきではありません。この方法には、NetNewsと電子メールヘッダーフィールドの間の競合を削除し、電子メールによる輸送中のフィールドへの変更を削除するという利点があります。
2. The proto-article is sent as an email with the addition of any header fields required for an email as defined in [RFC5322], and possibly with the addition of other header fields conventional in email, such as To and Received. The existing Message-ID header field SHOULD be retained.
2. Proto-Articleは、[RFC5322]で定義されている電子メールに必要なヘッダーフィールドを追加した電子メールとして送信され、場合によっては電子メールで従来の他のヘッダーフィールドが追加されています。既存のMessage-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.
これらの方法は両方とも過去に使用されており、最初の方法には明確な技術的利点がありますが、2番目はより一般的な使用であり、多くのモデレーターは最初の形式でメッセージを処理する準備ができていません。したがって、転送されているモデレーターがこの方法を処理できることが知られていない限り、最初の方法は使用しないでください。
NOTE: Deriving the email address of the moderator of a group is outside the scope of this document. It is worth mentioning, however, that a common method is to use a forwarding service that handles submissions for many moderated groups. For maximum compatibility with existing news servers, such forwarding services generally form the submission address for a moderated group by replacing each "." in the <newsgroup-name> with "-" and then using that value as the <local-part> of a <mailbox> formed by appending a set domain.
注：グループのモデレーターの電子メールアドレスを導き出すことは、このドキュメントの範囲外です。ただし、一般的な方法は、多くの緩和グループの提出物を処理する転送サービスを使用することであることに言及する価値があります。既存のニュースサーバーとの最大限の互換性のために、そのような転送サービスは一般に、それぞれを置き換えることにより、モデレートグループの提出アドレスを形成します。「 - 」を備えた<NewsGroup-Name>で、その値を使用して、設定ドメインを追加することによって形成された<mailbox>の<local-part>として使用します。
Forwarding proto-articles to moderators via email is the most general method and the most common in large Netnews networks such as Usenet, but any means of forwarding the article that preserves it without injecting it MAY be used. For example, if the injecting agent has access to a database used by the moderator to store proto-articles awaiting processing, it may place the proto-article directly into that database. Such methods may be more appropriate for smaller Netnews networks.
電子メールを介してプロトーティクルをモデレーターに転送することが最も一般的な方法であり、USENETなどの大型ネットネットワークで最も一般的ですが、注入せずに保存する記事を転送する手段を使用できます。たとえば、注入剤がモデレーターがプロトアーティクルを保存するために使用するデータベースにアクセスして処理を待っている場合、そのデータベースにプロトアーティクルを直接配置する可能性があります。このような方法は、小規模なネットネットネットワークに適している場合があります。
A relaying agent accepts injected articles from injecting and other relaying agents and passes them on to relaying or serving agents. To avoid bypass of injecting agent policies and forgery of Path and Injection-Info headers, relaying agents SHOULD accept articles only from trusted agents.
中継剤は、注入された記事を注入剤やその他の中継剤から受け入れ、それらを中継またはサービス剤に渡します。注入剤のポリシーのバイパスとパスと注入INFOヘッダーの偽造を回避するために、中継エージェントは信頼できるエージェントからのみ記事を受け入れる必要があります。
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分布ヘッダーフィールド（存在する場合）。例外的に、ニュースグループの作成または削除のコントロールメッセージ（たとえば、NewGroupまたはRMGroup Controlメッセージなど）は、影響を受けるグループがNewsGroupヘッダーフィールドに表示され、送信および受信エージェントの両方がその名前のニュースグループを中継するように構成されている場合（そのようなニュースグループが存在しない）。
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.
不必要な中継試行を避けるために、受信エージェント（またはその既知のエイリアス）の<パスアイデンティティ>が<パスアイデンティティ>（<テールエントリ>または<<tail-entry>または除外）として表示される場合、記事を中継する必要はありません。パスヘッダーフィールドに「susts」<diag-keyword>）に続きます。
A relaying agent processes an article as follows:
中継エージェントは、次のように記事を処理します。
1. It MUST reject any article without a Newsgroups header field or Message-ID header field, or without either an Injection-Date or Date header field.
1. ニュースグループヘッダーフィールドまたはメッセージIDヘッダーフィールド、または噴射日または日付ヘッダーフィールドのいずれかなしで記事を拒否する必要があります。
2. It MUST examine the Injection-Date header field or, if absent, the Date header field, and reject the article if that date is more than 24 hours into the future. It MAY reject articles with dates in the future with a smaller margin than 24 hours.
2. 注入日付ヘッダーフィールドまたは不在の場合は、日付ヘッダーフィールドを調べ、その日付が将来24時間以上経過している場合は記事を拒否する必要があります。将来の日付の記事を24時間より少ないマージンで拒否する可能性があります。
3. It MUST reject any article that has already been accepted. If it implements one of the mechanisms described in Section 3.3, this means that it MUST reject any article whose date falls outside the cutoff interval since it won't know whether or not such articles had been accepted previously.
3. すでに受け入れられている記事を拒否する必要があります。セクション3.3で説明されているメカニズムの1つを実装した場合、これは、そのような記事が以前に受け入れられていたかどうかがわからないため、日付がカットオフ間隔の外側にある記事を拒否しなければならないことを意味します。
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. 既に推奨されているキャンセルコントロールメッセージまたは受け入れられた記事のスーパーデスヘッダーフィールドのコンテンツに一致する記事を拒否する必要があります。Supersedesヘッダーフィールド。
6. It MAY reject any article without an Approved header field posted to a newsgroup known to be moderated. This practice is strongly encouraged, but the information necessary to do so is not required to be maintained by a relaying agent.
6. 承認されたヘッダーフィールドがモデレートされていることが知られているニュースグループに投稿されていない記事を拒否する場合があります。この慣行は強く奨励されていますが、そうするために必要な情報は、中継剤によって維持される必要はありません。
7. It MUST update the Path header field as described in Section 3.2.1.
7. セクション3.2.1で説明されているように、パスヘッダーフィールドを更新する必要があります。
8. It MAY delete any Xref header field already present. It MAY add a new Xref header field for its own use (but recall that [RFC5536] permits at most one such header field).
8. すでに存在するXrefヘッダーフィールドを削除する場合があります。それは、独自の使用のために新しいXREFヘッダーフィールドを追加する可能性があります（ただし、[RFC5536]はそのようなヘッダーフィールドのせいぜい1つを許可することを思い出してください）。
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.
中継エージェントは、パスおよびXREFヘッダーフィールドを除く記事の一部を変更、削除、または再配置してはなりません。彼らは一連の記事を決して変更してはなりません。記事がそのまま受け入れられない場合、記事は変更されるのではなく拒否されなければなりません。
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.
サービングエージェントは、中継エージェントまたは注射剤から記事を受け入れ、それらを保存し、読み取りエージェントが利用できるようにします。記事は通常、NewsGroupと<Article-Locator>（[RFC5536]のセクション3.2.14）によってインデックス付けされ、通常は小数点の形式です。
If the serving agent stores articles by newsgroup, control messages SHOULD NOT be stored in the newsgroups listed in the control message's Newsgroups header field. Instead, they SHOULD be stored in a newsgroup in the hierarchy "control", which is reserved for this purpose. Conventionally, control messages are stored in newsgroups named for the type of control message (such as "control.cancel" for cancel control messages).
サービングエージェントがニュースグループごとに記事を保存している場合、コントロールメッセージをコントロールメッセージのニュースグループヘッダーフィールドにリストしたニュースグループに保存しないでください。代わりに、この目的のために予約されている階層「コントロール」のニュースグループに保存する必要があります。従来、コントロールメッセージは、コントロールメッセージの種類（Control.Cancel」などのコントロールメッセージなど）にちなんで名付けられたニュースグループに保存されています。
A serving agent MUST have available a list (possibly empty) of moderated groups for which it accepts articles so that it can reject unapproved articles posted to moderated groups. Frequently, a serving agent is deployed in combination with an injecting agent and can use the same list as the injecting agent.
サービングエージェントには、モデレートグループに投稿された未承認の記事を拒否できるように、記事を受け入れるモデレートグループのリスト（おそらく空）が必要です。多くの場合、サービングエージェントは注入剤と組み合わせて展開され、注入剤と同じリストを使用できます。
A serving agent processes articles as follows:
サービングエージェントは次のように記事を処理します。
1. It MUST reject any article that does not include all the mandatory header fields or any article that contains header fields that do not have valid contents.
1. すべての必須ヘッダーフィールドを含めない記事または有効なコンテンツがないヘッダーフィールドを含む記事を拒否する必要があります。
2. It MUST examine the Injection-Date header field or, if absent, the Date header field, and reject the article if that date is more than 24 hours into the future. It MAY reject articles with dates in the future with a smaller margin than 24 hours.
2. 注入日付ヘッダーフィールドまたは不在の場合は、日付ヘッダーフィールドを調べ、その日付が将来24時間以上経過している場合は記事を拒否する必要があります。将来の日付の記事を24時間より少ないマージンで拒否する可能性があります。
3. It MUST reject any article that has already been accepted. If it implements one of the mechanisms described in Section 3.3, this means that it MUST reject any article whose date falls outside the cutoff interval since it won't know whether or not such articles had been accepted previously.
3. すでに受け入れられている記事を拒否する必要があります。セクション3.3で説明されているメカニズムの1つを実装した場合、これは、そのような記事が以前に受け入れられていたかどうかがわからないため、日付がカットオフ間隔の外側にある記事を拒否しなければならないことを意味します。
4. It SHOULD reject any article that matches an already-received and honored cancel message or Supersedes header field, following the same rules as a relaying agent (Section 3.6).
4. リレーするエージェントと同じルールに従って、既に尊敬され、栄誉あるキャンセルメッセージまたは上手ヘッダーフィールドに一致する記事を拒否する必要があります（セクション3.6）。
5. It MUST reject any article without an Approved header field posted to any newsgroup listed as moderated.
5. モデレートとしてリストされているニュースグループに投稿された承認されたヘッダーフィールドなしでは、記事を拒否する必要があります。
6. It MUST update the Path header field as described in Section 3.2.1.
6. セクション3.2.1で説明されているように、パスヘッダーフィールドを更新する必要があります。
7. It MUST remove any Xref header field from each article (except when specially configured to preserve the <article-locator>s set by the sending site). It then MAY (and usually will) add a new Xref header field (but recall that [RFC5536] permits at most one such header field).
7. 各記事からXREFヘッダーフィールドを削除する必要があります（送信サイトで設定された<Article-Locator> sを保存するように特別に構成されている場合を除きます）。その後、新しいXREFヘッダーフィールドを追加する可能性があります（通常はそうするでしょう）（ただし、[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).
サービングエージェントは、NewsGroupsヘッダーフィールドで認識されていない<newsGroup-Name>が発生しているという理由だけで、新しいニュースグループを作成してはなりません。ニュースグループは通常、制御メッセージを介して作成されます（セクション5.2.1）。
Serving agents MUST NOT alter, delete, or rearrange any part of an article except for the Path and Xref header fields. They MUST NOT modify the body of the articles in any way. If an article is not acceptable as is, the article MUST be rejected rather than modified.
サービングエージェントは、パスおよびXREFヘッダーフィールドを除く記事の一部を変更、削除、または再配置してはなりません。記事の本文を決して変更してはなりません。記事がそのまま受け入れられない場合、記事は変更されるのではなく拒否されなければなりません。
Since a reading agent is only a passive participant in a Netnews network, there are no specific protocol requirements placed on it. See [USEAGE] for best-practice recommendations.
リーディングエージェントはNetNewsネットワークの受動的参加者にすぎないため、特定のプロトコル要件はありません。ベストプラクティスの推奨については、[ユーザー]を参照してください。
A moderator receives news articles, customarily by email, decides whether to approve them and, if so, either passes them to an injecting agent or forwards them to further moderators.
モデレーターは、通常、電子メールでニュース記事を受け取り、それらを承認するかどうかを決定し、もしそうなら、それらを注入剤に渡すか、それらをさらなるモデレーターに転送します。
Articles are normally received by the moderator in email, either encapsulated as an object of Content-Type application/ news-transmission (or possibly encapsulated but without an explicit Content-Type header field) or else directly as an email already containing all the header fields appropriate for a Netnews article (see Section 3.5.1). Moderators who may receive articles via email SHOULD be prepared to accept articles in either format.
記事は通常、モデレーターが電子メールで受信し、コンテンツタイプのアプリケーション/ニューストランスミッションのオブジェクトとしてカプセル化されている（またはカプセル化されているが、明示的なコンテンツタイプのヘッダーフィールドなし）またはすべてのヘッダーフィールドを既に含む電子メールとして直接NetNewsの記事に適しています（セクション3.5.1を参照）。電子メールで記事を受け取る可能性のあるモデレーターは、どちらの形式でも記事を受け入れるように準備する必要があります。
There are no protocol restrictions on what criteria are used for accepting or rejecting messages or on what modifications a moderator may make to a message (both header fields and body) before injecting it. Recommended best practice, however, is to make the minimal required changes. Moderators need to be aware that modifications made to articles may invalidate signatures created by the poster or previous moderators. See [USEAGE] for further best-practice recommendations.
メッセージを受け入れるか拒否するために使用される基準や、モデレーターがメッセージ（ヘッダーフィールドとボディの両方）に加える前にどのような変更を加えるかについて、プロトコル制限はありません。ただし、推奨されるベストプラクティスは、必要な変更を最小限に抑えることです。モデレーターは、記事に加えられた変更がポスターまたは以前のモデレーターによって作成された署名を無効にする可能性があることに注意する必要があります。さらにベストプラクティスの推奨については、[ユーザー]を参照してください。
Moderators process articles as follows:
モデレーターは次のように記事を処理します：
1. They decide whether to approve or reject a proto-article and, if approved, prepare the proto-article for injection. If the proto-article was received as an unencapsulated email message, this will require converting it back to a valid Netnews proto-article. If the article is rejected, it is normally rejected for all newsgroups to which it was posted and nothing further is done. If it is approved, the moderator proceeds with the following steps.
1. 彼らは、筋肉を承認するか拒否するかを決定し、承認された場合、注射のためにプロトティクルを準備します。プロトアーティクルがカプセル化されていない電子メールメッセージとして受信された場合、これには有効なNetNewsプロトアーティクルに戻す必要があります。記事が拒否された場合、それは通常、それが投稿されたすべてのニュースグループに対して拒否され、それ以上は何も行われません。承認されている場合、モデレーターは次の手順を進めます。
2. If the Newsgroups header field contains further moderated newsgroups for which approval has not already been given, they may either reach some agreement with the other moderators on the disposition of the article or, more generally, add an indication (identifying both the moderator and the name of the newsgroup) that they approve the article and then forward it to the moderator of the leftmost unapproved newsgroup. This forwarding SHOULD be done following the procedure in Section 3.5.1. It MAY be done by rotating the <newsgroup-name>s in the Newsgroups header field so that the leftmost unapproved newsgroup is the leftmost moderated newsgroup in that field and then posting it, letting the injecting agent do the forwarding. However, when using this mechanism, they MUST first ensure that the article contains no Approved header field.
2. NewsGroups Headerフィールドに、承認がまだ与えられていないさらなるモデレートニュースグループが含まれている場合、記事の処分に関する他のモデレーターと何らかの合意に達するか、より一般的には、兆候を追加します（モデレーターと名前の両方を識別します。ニュースグループの）彼らは記事を承認し、それを左端の未承認のニュースグループのモデレーターに転送します。この転送は、セクション3.5.1の手順に従って行う必要があります。NewsGroupsヘッダーフィールドで<NewsGroup-Name> sを回転させることで行うことができます。これにより、左端の未承認のニュースグループがそのフィールドの左端のモデレートニュースグループになり、それを投稿し、注入剤に転送を行わせます。ただし、このメカニズムを使用する場合、最初に記事に承認されたヘッダーフィールドが含まれていないことを確認する必要があります。
3. If the Newsgroups header field contains no further unapproved moderated groups, they add an Approved header field (see Section 3.2.1 of [RFC5536]) identifying the moderator and, insofar as is possible, all the other moderators who have approved the article. The moderator who takes this step assumes responsibility for ensuring that the article was approved by the moderators of all moderated newsgroups to which it was posted.
3. NewsGroups Headerフィールドに承認されていないモデレートグループが含まれていない場合、承認されたヘッダーフィールド（[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ヘッダーフィールドを保持することをお勧めします。モデレーターは、モデレーター（モデレートプロセスの遅延など）が理解した理由により、古くなっていると思われない限り、日付ヘッダーフィールドを保持することも奨励されています。。既に存在する注入日、注入INFO、またはXREFヘッダーフィールドは削除する必要があります。
5. Any Path header field MUST either be removed or truncated to only those entries following its "POSTED" <diag-keyword>, if any.
5. パスヘッダーフィールドは、「投稿された」<diag-keyword>に続くエントリのみに削除または切り捨てられる必要があります。
6. The moderator then passes the article to an injecting agent, having first observed all the duties of a posting agent.
6. 次に、モデレーターは記事を注入剤に渡し、最初に投稿エージェントのすべての義務を観察しました。
A gateway transforms an article into the native message format of another medium, or translates the messages of another medium into news articles, or transforms articles into proto-articles for injection into a separate Netnews network. Encapsulation of a news article into a message of MIME type application/news-transmission, or the subsequent undoing of that encapsulation, is not gatewaying since it involves no transformation of the article.
ゲートウェイは、記事を別のメディアのネイティブメッセージ形式に変換するか、別のメディアのメッセージをニュース記事に変換するか、記事をインジェクションのために別のNetNewsネットワークに変換します。MIMEタイプのアプリケーション/ニューストランスミッションのメッセージへのニュース記事のカプセル化、またはそのカプセル化のその後の元に戻すことは、記事の変換が含まれないためゲートウェイではありません。
There are two basic types of gateway, the outgoing gateway that transforms a news article into a different type of message, and the incoming gateway that transforms a message from another network into a news proto-article and injects it into a Netnews network. These are handled separately below.
ゲートウェイには、ニュース記事を異なるタイプのメッセージに変換する発信ゲートウェイと、メッセージを別のネットワークからニュースプロトアーティクルに変換し、それをNetNewsネットワークに挿入する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.
メッセージに適用される変換は、ゲートウェイを達成しながら、できるだけ最小限である必要があります。ゲートウェイによって行われたすべての変更は、メディアの1つのプロパティを破壊する可能性があるか、情報を失う可能性があるため、メディア間の違いによって必要な変換のみを適用する必要があります。
If bidirectional gatewaying (both an incoming and an outgoing gateway) is being set up between Netnews and some other medium, the incoming and outgoing gateways SHOULD be coordinated to avoid unintended reinjection of gated articles. Circular gatewaying (gatewaying a message into another medium and then back into Netnews) SHOULD NOT be done; encapsulation of the article SHOULD be used instead where this is necessary.
双方向ゲートウェイ（入ってくるゲートウェイと発信ゲートウェイの両方）がNetNewsと他の媒体の間に設置されている場合、ゲートされた記事の意図しない再注入を避けるために、着信と発信のゲートウェイを調整する必要があります。円形のゲートウェイング（メッセージを別の媒体にゲートウェイしてからNetNewsに戻る）は、実行しないでください。これが必要な場合は、代わりに記事のカプセル化を使用する必要があります。
Safe bidirectional gatewaying between a mailing list and a newsgroup is far easier if the newsgroup is moderated. Posts to the moderated group and submissions to the mailing list can then go through a single point that does the necessary gatewaying and then sends the message out to both the newsgroup and the mailing list at the same time, eliminating most of the possibility of loops. Bidirectional gatewaying between a mailing list and an unmoderated newsgroup, in contrast, is difficult to do correctly and is far more fragile. Newsgroups intended to be bidirectionally gated to a mailing list SHOULD therefore be moderated where possible, even if the moderator is a simple gateway and injecting agent that correctly handles crossposting to other moderated groups and otherwise passes all traffic.
ニュースグループがモデレートされている場合、メーリングリストとニュースグループの間の安全な双方向ゲートウェイははるかに簡単です。モデレートグループへの投稿とメーリングリストへの提出は、必要なゲートウェイを行う単一のポイントを通過し、ニュースグループとメーリングリストの両方に同時にメッセージを送信し、ループのほとんどの可能性を排除できます。対照的に、メーリングリストとモデレートされていないニュースグループの間の双方向ゲートウェイは、正しく行うのが難しく、はるかに脆弱です。したがって、モデレーターが単純なゲートウェイであり、他のモデレートグループへのクロスポストを正しく処理し、その他のすべてのトラフィックを渡す単純なゲートウェイおよび注入エージェントであっても、可能な限り双方向にゲート化することを目的としたニュースグループは、可能な限りモデレートする必要があります。
From the perspective of Netnews, an outgoing gateway is just a special type of reading agent. The exact nature of what the outgoing gateway will need to do to articles depends on the medium to which the articles are being gated. Because it raises the danger of loops due to the possibility of one or more corresponding incoming gateways back from that medium to Netnews, the operation of the outgoing gateway is subject to additional constraints.
NetNewsの観点から見ると、発信ゲートウェイは単なる特別なタイプのリーディングエージェントです。発信ゲートウェイが記事に必要なことの正確な性質は、記事がゲートされている媒体に依存します。そのメディアからネットネーワに戻る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.
3. メッセージは、NetNewsへの再注入を防ぐために、何らかの方法でタグ付けする必要があります。これは、潜在的な入ってくるゲートウェイの知識なしに行うことは不可能かもしれませんが、成功しなくても何らかの兆候を提供しようとする方が良いです。少なくとも、記事をNetNewsに戻すべきではないという人間の読み取り可能な兆候は、人間の問題を見つけるのに役立ちます。
4. Netnews control messages should not be gated to another medium unless they would somehow be meaningful in that medium.
4. NetNewsコントロールメッセージは、その媒体で何らかの形で意味のあるものでない限り、別の媒体にゲートするべきではありません。
The incoming gateway has the responsibility of ensuring that all of the requirements of this protocol are met by the articles that it forms. In addition to its special duties as a gateway, it bears all of the duties and responsibilities of a posting agent, and it has the same responsibility of a relaying agent to reject articles that it has already gatewayed.
着信ゲートウェイには、このプロトコルのすべての要件が形成される記事によって満たされることを保証する責任があります。ゲートウェイとしての特別な義務に加えて、ポストエージェントのすべての義務と責任を負い、既にゲートウェイで記事を拒否することは、中継エージェントの責任を負います。
An incoming gateway MUST NOT gate the same message twice. It may not be possible to ensure this in the face of mangling or modification of the message, but at the very least a gateway, when given a copy of a message that it has already gated and that is identical except for trace header fields (like Received in Email or Path in Netnews), MUST NOT gate the message again. An incoming gateway SHOULD take precautions against having this rule bypassed by modifications of the message that can be anticipated.
着信ゲートウェイは、同じメッセージを2回ゲートしてはなりません。メッセージのマングルまたは変更に直面してこれを確実にすることはできないかもしれませんが、少なくともゲートウェイは、すでにゲートしており、トレースヘッダーフィールドを除いて同一のメッセージのコピーが与えられた場合です（netnewsの電子メールまたはパスで受信してください）、メッセージに再度ゲートをゲートしてはなりません。入ってくるゲートウェイは、予想されるメッセージの変更によってこのルールをバイパスすることに対して予防策を講じる必要があります。
News articles prepared by gateways MUST be valid news proto-articles (see Section 3.4.1). This often requires the gateway to synthesize a conforming article from non-conforming input. The gateway MUST then pass the article to an injecting agent, not directly to a relaying agent.
ゲートウェイが作成したニュース記事は、有効なニュースプロトアーティクルでなければなりません（セクション3.4.1を参照）。これには、不適合な入力からの適合物を合成するためのゲートウェイが必要です。その後、ゲートウェイは、リレー剤に直接ではなく、注入剤に記事を渡す必要があります。
Incoming gateways MUST NOT pass control messages (articles containing a Control or Supersedes header field) without removing or renaming that header field. Gateways MAY, however, generate cancel control messages for messages they have gatewayed. If a gateway receives a message that it can determine is a valid equivalent of a cancel control message in the medium it is gatewaying, it SHOULD discard that message without gatewaying it, generate a corresponding cancel control message of its own, and inject that cancel control message.
着信ゲートウェイは、そのヘッダーフィールドを削除または名前変更せずに、コントロールメッセージ（コントロールまたはSuperSedesヘッダーフィールドを含む記事）を渡すべきではありません。ただし、ゲートウェイでは、ゲートウェイがあるメッセージのコントロールメッセージをキャンセルする場合があります。ゲートウェイが判断できるメッセージを受信した場合、メディアのキャンセルコントロールメッセージに相当する有効なゲートウェイがゲートウェイである場合は、ゲートウェイを行わずにそのメッセージを破棄し、独自の対応するキャンセルコントロールメッセージを生成し、コントロールをキャンセルする必要があります。メッセージ。
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.
注：メッセージ識別子は、重複の予防において中心的な役割を果たし、ゲートウェイによる正しい使用はループを防ぐために多くのことを行います。ただし、NetNewsはメッセージ識別子が一意であることを要求するため、他のメディアからのメッセージ識別子は、変更なしで使用するのに適していない場合があります。ループを防ぐために使用される情報を保存し、一意のメッセージ識別子を生成するために使用される情報の保存との間のゲートウェイによってバランスをとる必要があります。
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.
例外的には、特定のメッセージのセットに複数の着信ゲートウェイがある場合、それぞれが異なるニュースグループに、それぞれがそのゲートウェイに固有のメッセージ識別子を生成する必要があります。それにもかかわらず、各着信ゲートウェイは、同じメッセージを2回ゲートしないようにする必要があります。
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つのゲートウェイの例を、2つの独立したUSENETニュースグループに検討します。どちらも電子メールメッセージ識別子を保持します。各ニュースグループは、メッセージの一部を受け取る場合があります（さまざまな部分が異なるサイトを見る）。これらの場合、「公式」ゲートウェイがない場合、衝突を避けるためにメッセージ識別子を生成する他の方法を使用する必要があります。クロスポストが1つのゲートウェイしかないことは明らかに望ましいでしょうが、これは調整することはできないかもしれません。
If no date information is available, the gateway MAY supply a Date header field with the gateway's current date. If only partial information is available (such as date but not time), this SHOULD be fleshed out to a full Date by adding default values rather than by discarding this information. Only in very exceptional circumstances should Date information be discarded, as it plays an important role in preventing reinjection of old messages.
日付情報が利用できない場合、ゲートウェイはゲートウェイの現在の日付で日付ヘッダーフィールドを提供する場合があります。部分情報のみが利用可能である場合（日付など）、これは、この情報を破棄するのではなく、デフォルト値を追加することにより、完全な日付に肉付けする必要があります。非常に例外的な状況でのみ、日付情報を破棄する必要があります。これは、古いメッセージの再注入を防ぐ上で重要な役割を果たしているためです。
An incoming gateway MUST add a Sender header field to the news article it forms by containing the <mailbox> of the administrator of the gateway. Problems with the gateway may be reported to this <mailbox>. The <display-name> portion of this <mailbox> SHOULD indicate that the entity responsible for injection of the message is a gateway. If the original message already had a Sender header field, it SHOULD be renamed to Original-Sender so that its contents can be preserved. See Section 3.10.3 for the specification of that header field.
着信ゲートウェイは、ゲートウェイの管理者の<メールボックス>を含むことにより、フォームのニュース記事に送信者ヘッダーフィールドを追加する必要があります。ゲートウェイの問題は、この<メールボックス>に報告される場合があります。この<メールボックス>の<display-name>部分は、メッセージの注入の責任者エンティティがゲートウェイであることを示す必要があります。元のメッセージに既に送信者ヘッダーフィールドがある場合、その内容を保存できるように、元のセンダーに名前が変更される必要があります。そのヘッダーフィールドの仕様については、セクション3.10.3を参照してください。
The Original-Sender header field holds the content of a Sender header field in an original message received by an incoming gateway, preserving it while the incoming gateway adds its own Sender header field. The content syntax makes use of syntax defined in [RFC5536] and [RFC5322].
元のセンダーヘッダーフィールドは、着信ゲートウェイが受信した元のメッセージに送信者ヘッダーフィールドのコンテンツを保持し、着信ゲートウェイが独自の送信者ヘッダーフィールドを追加している間に保存します。コンテンツ構文は、[RFC5536]および[RFC5322]で定義された構文を使用します。
header =/ Original-Sender-header
Original-Sender-header
= "Original-Sender" ":" SP
Original-Sender-content
Original-Sender-content
= mailbox
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
ヘッダーフィールド名：元のセンダー適用プロトコル：NetNewsステータス：標準著者/変更コントローラー：IETF仕様文書：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. ニュース間ゲートウェイは、生成された電子メールメッセージにニュース記事のメッセージ識別子を保存します。同様に、Mail-to-Newsゲートウェイは、NetNewsに対して構文的に有効であることを条件に、電子メールメッセージ識別子を保存します。これにより、ニュースシステムの重複の抑制が組み込まれ、ループに対する第一の防御線として機能することができます。
2. The news-to-mail gateway adds an X-* header field to all messages it generates. The mail-to-news gateway discards any incoming messages containing this header field. This is robust against mailing list managers that replace the message identifier and against any number of email hops, provided that the other message header fields are preserved.
2. ニュースからメールへのゲートウェイは、生成するすべてのメッセージにx-*ヘッダーフィールドを追加します。メールツーニュースゲートウェイは、このヘッダーフィールドを含む着信メッセージを破棄します。これは、他のメッセージヘッダーフィールドが保存されていれば、メッセージ識別子を交換し、任意の数のメールホップに対してメーリングリストマネージャーに対して堅牢です。
3. The mail-to-news gateway prepends the host name from which it received the email message to the content of the Path header field. The news-to-mail gateway refuses to gateway any message that contains the list server name in its Path header field (including in the tail section). This is robust against any amount of munging of the message header fields by the mailing list, provided that the email only goes through one hop.
3. Mail-to-Newsのゲートウェイは、パスヘッダーフィールドのコンテンツへの電子メールメッセージを受け取ったホスト名を事前に予約します。News-to-Mail Gatewayは、パスヘッダーフィールド（テールセクションを含む）にリストサーバー名を含むメッセージをゲートウェイすることを拒否します。これは、メールが1つのホップのみを通過する場合、メーリングリストによるメッセージヘッダーフィールドのムンギングの量に対して堅牢です。
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. Mail-to-Newsゲートウェイは、封筒の送信者へのバウンスを生成するように設計されています。代わりに、ニュースサーバーによって拒否された記事（メッセージのサイレント廃棄を保証しない理由で）の結果、メーリングリストに転送しないことが知られているエラーアドレスに送信されたバウンスメッセージが表示されます。このようにして、それらはニュース管理者によって処理できます。
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に登録されていたメディアタイプのメッセージ/ニュースは、これにより時代遅れと宣言されています。このメディアタイプの意図は、人間の読書のためにメールでニュース記事を送信する標準的な方法を定義することでした。しかし、それは決して広く実装されておらず、そのデフォルトの治療は、それが逆効果であると認識していなかったエージェントによるアプリケーション/オクテットストリームとしての治療です。メディアタイプメッセージ/RFC822（[RFC2046]のセクション5.2.1で定義）は、その代わりに使用する必要があります。
The updated MIME media type definition of message/news is:
メッセージ/ニュースの更新されたMIMEメディアタイプの定義は次のとおりです。
MIME type name: message
mimeタイプ名：メッセージ
MIME subtype name: news
MIMEサブタイプ名：ニュース
Required parameters: none
必要なパラメーター：なし
Optional parameters: none
オプションのパラメーター：なし
Encoding considerations: same as message/rfc822
考慮事項のエンコード：メッセージ/RFC822と同じ
Security considerations: News articles may constitute "control messages", which can have effects on a host's news system beyond just addition of information. Since control messages may occur in normal news flow, most hosts are suitably defended against undesired effects already, but transmission of news articles via mail may bypass firewall-type defenses. Reading a news article transmitted by mail involves no hazards beyond those of mail, but submitting it to news software for processing should be done with care.
セキュリティ上の考慮事項：ニュース記事は「コントロールメッセージ」を構成する場合があります。これは、情報の追加だけでなく、ホストのニュースシステムに影響を与える可能性があります。コントロールメッセージは通常のニュースフローで発生する可能性があるため、ほとんどのホストはすでに望ましくない効果に対して適切に防御されていますが、メールによるニュース記事の送信により、ファイアウォールタイプの防御がバイパスされる場合があります。メールで送信されたニュース記事を読むには、メールの危険はありませんが、処理のためにニュースソフトウェアに送信することは注意して行う必要があります。
Interoperability considerations: Rarely used, and therefore often handled as application/octet-stream. Disposition should by default be inline.
相互運用性の考慮事項：めったに使用されず、したがって、アプリケーション/オクテットストリームとして処理されることがよくあります。処分はデフォルトでインラインでなければなりません。
Published specification: RFC 5537
公開された仕様：RFC 5537
Applications that use this media type: Some old mail and news user agents.
このメディアタイプを使用するアプリケーション：いくつかの古いメールおよびニュースユーザーエージェント。
Intended usage: OBSOLETE
意図された使用法：時代遅れ
Author: Henry Spencer
著者：ヘンリー・スペンサー
Change controller: IETF
Change Controller：IETF
The media type application/news-transmission is intended for the encapsulation of complete news articles where the intention is that the recipient should then inject them into Netnews. This application type provides one of the methods for mailing articles to moderators (see Section 3.5.1) and may be used to convey messages to an injecting agent. This encapsulation removes the need to transform an email message into a Netnews proto-article and provides a way to send a Netnews article using MIME through a transport medium that does not support 8bit data.
メディアタイプのアプリケーション/ニューストランスミッションは、受信者がそれらをNetNewsに注入する必要があるという意図である完全なニュース記事のカプセル化を目的としています。このアプリケーションタイプは、記事をモデレーターに郵送する方法の1つを提供し（セクション3.5.1を参照）、注入剤にメッセージを伝えるために使用できます。このカプセル化により、電子メールメッセージをNetNews Proto-Articleに変換する必要性が削除され、8ビットデータをサポートしていないトランスポートメディアを使用してMIMEを使用してNetNewsの記事を送信する方法が提供されます。
The MIME media type definition of application/news-transmission is:
アプリケーション/ニューストランスミッションのMIMEメディアタイプの定義は次のとおりです。
MIME type name: application
MIMEタイプ名：アプリケーション
MIME subtype name: news-transmission
MIMEサブタイプ名：ニューストランスミッション
Required parameters: none
必要なパラメーター：なし
Optional parameters: One and only one of "usage=moderate", "usage=inject", or "usage=relay".
オプションのパラメーター：「使用法=中程度」、「使用型=インジェクション」、または「usage = reay」の1つと唯一のパラメーター。
Encoding considerations: A transfer-encoding different from that of the article transmitted MAY be supplied to ensure correct transmission over some 7bit transport medium.
エンコーディングの考慮事項：送信された記事のそれとは異なる転送エンコードを提供して、約7ビット輸送媒体を介した正しい伝送を確保することができます。
Security considerations: News articles may constitute "control messages", which can have effects on a host's news system beyond just addition of information. Since control messages may occur in normal news flow, most hosts are suitably defended against undesired effects already, but transmission of news articles via mail may bypass firewall-type defenses.
セキュリティ上の考慮事項：ニュース記事は「コントロールメッセージ」を構成する場合があります。これは、情報の追加だけでなく、ホストのニュースシステムに影響を与える可能性があります。コントロールメッセージは通常のニュースフローで発生する可能性があるため、ほとんどのホストはすでに望ましくない効果に対して適切に防御されていますが、メールによるニュース記事の送信により、ファイアウォールタイプの防御がバイパスされる場合があります。
Published specification: RFC 5537
公開された仕様：RFC 5537
Body part: A complete proto-article ready for injection into Netnews or an article being relayed to another agent.
ボディパート：NetNewsまたは別のエージェントに中継される記事への注入の準備ができている完全なプロトアーティクル。
Applications that use this media type: Injecting agents, Netnews moderators.
このメディアタイプを使用するアプリケーション：注入エージェント、NetNewsモデレーター。
Intended usage: COMMON
意図された使用法：共通
Change controller: IETF
Change Controller：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.
使用法=中程度は、記事がモデレーター用、使用量=注入エージェントの使用、リレー剤の使用=リレーを対象としていることを示します。記事を受け取るエンティティは、1つのタイプのエージェントのみを実装できます。この場合、パラメーターは省略できます。
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.
Application/News-Groupinfoメディアタイプは、NewGroup Controlメッセージと組み合わせて使用されます（セクション5.2.1を参照）。その身体部分には、ニュースグループに関する簡単な情報が含まれています：ニュースグループ名、その説明、およびそのモデレートステータス。
The MIME media type definition of application/news-groupinfo is:
アプリケーション/ニュースグループのMIMEメディアタイプの定義は次のとおりです。
MIME type name: application
MIMEタイプ名：アプリケーション
MIME subtype name: news-groupinfo
MIMEサブタイプ名：News-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].
オプションのパラメーター：CHARSET。これは、MIMEテキストタイプで使用するために登録されているCharSetでなければなりません。テキスト/プレーン[RFC2046]に対して定義されたパラメーターと同じ構文を持っています。身体部分のチャーセットを指定します。与えられない場合、charsetはus-ascii [ascii]のデフォルトです。
Encoding considerations: 7bit or 8bit encoding MUST be used to maintain compatibility.
考慮事項のエンコーディング：7ビットまたは8ビットのエンコードを使用して、互換性を維持する必要があります。
Security considerations: None.
セキュリティ上の考慮事項：なし。
Interoperability considerations: Disposition should by default be inline.
相互運用性の考慮事項：処分はデフォルトでインラインでなければなりません。
Applications that use this media type: Control message issuers, relaying agents, serving agents.
このメディアタイプを使用するアプリケーション：コントロールメッセージ発行者、エージェントの中継、サービングエージェント。
Published specification: RFC 5537
公開された仕様：RFC 5537
Intended usage: COMMON
意図された使用法：共通
Change controller: IETF
Change Controller：IETF
The content of the application/news-groupinfo body part is defined as:
アプリケーション/News-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
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.
この異常な形式は、この仕様よりも前のNetNews実装によって行われた説明のために、NewGroup Controlメッセージの本文をスキャンすることと、後方互換性があります。オプションですが、<NewsGroups-Tag>は、後方互換性のために含める必要があります。
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.
<NewsGroupDescription>には、文字列の発生を含めてはなりません。モデレートされたニュースグループは、最後にケースに敏感なテキスト「（モデレート）」を追加することによってマークされなければなりません。
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ヘッダーフィールドを理解していないか、さまざまなcharセットの説明を正しく処理しません。したがって、可能であれば、US-ASCIIのcharsetを使用することをお勧めします。不可能な場合は、UTF-8 [RFC3629]を使用する必要があります。使用されるcharsetに関係なく、上記の文法の制約を満たす必要があり、<newsgroup-name>は、us-asciiのcharsetで使用されるのと同じオクテットを使用してそのcharsetで表現する必要があります。
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).
Application/News-Checkgroupsメディアタイプには、説明や緩和ステータスなど、階層または階層内のニュースグループのリストが含まれています。これは主にCheckGroups Controlメッセージで使用するためです（セクション5.2.3を参照）。
The MIME media type definition of application/news-checkgroups is:
アプリケーション/ニュースチェックグループのMIMEメディアタイプの定義は次のとおりです。
MIME type name: application
MIMEタイプ名：アプリケーション
MIME subtype name: news-checkgroups
MIMEサブタイプ名：ニュースチェックグループ
Required parameters: none
必要なパラメーター：なし
Optional parameters: charset, which MUST be a charset registered for use with MIME text types. It has the same syntax as the parameter defined for text/plain [RFC2046]. Specifies the charset of the body part. If not given, the charset defaults to US-ASCII [ASCII].
オプションのパラメーター：CHARSET。これは、MIMEテキストタイプで使用するために登録されているCharSetでなければなりません。テキスト/プレーン[RFC2046]に対して定義されたパラメーターと同じ構文を持っています。身体部分のチャーセットを指定します。与えられない場合、charsetはus-ascii [ascii]のデフォルトです。
Encoding considerations: 7bit or 8bit encoding MUST be used to maintain compatibility.
考慮事項のエンコーディング：7ビットまたは8ビットのエンコードを使用して、互換性を維持する必要があります。
Security considerations: This media type provides only a means for conveying a list of newsgroups and does not provide any information indicating whether the sender is authorized to state which newsgroups should exist within a hierarchy. Such authorization must be accomplished by other means.
セキュリティ上の考慮事項：このメディアタイプは、ニュースグループのリストを伝えるための手段のみを提供し、送信者がどのニュースグループが階層内に存在するべきかを述べることを認められているかどうかを示す情報を提供しません。そのような許可は、他の手段によって達成されなければなりません。
Interoperability considerations: Disposition should by default be inline.
相互運用性の考慮事項：処分はデフォルトでインラインでなければなりません。
Applications that use this media type: Control message issuers, relaying agents, serving agents.
このメディアタイプを使用するアプリケーション：コントロールメッセージ発行者、エージェントの中継、サービングエージェント。
Published specification: RFC 5537
公開された仕様：RFC 5537
Intended usage: COMMON
意図された使用法：共通
Change controller: IETF
Change Controller：IETF
The content of the application/news-checkgroups body part is defined as:
アプリケーション/News-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.
Charset、<newsgroup-name>、および<newsgroup-description>の同じ制限は、アプリケーション/ニュースグループの場合と同じメディアタイプに適用されます。
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
1つのアプリケーション/ニュースチェックグループメッセージには、1つ以上の階層の情報が含まれている場合があり、その範囲を制限する外部情報を添付しない限り（<chkscope>パラメーターなどを伴わない限り、<有効なグループ>を含む階層の完全なものと見なされます。セクション5.2.3で説明されているように、GroupsコントロールメッセージをCheckGroupsコントロールします）。言い換えれば、アプリケーション/ニュースチェックグループの本体の部分
example.moderated A moderated newsgroup (Moderated) example.test An unmoderated test group
example.moderated moderated newsgroup（moderated）exlames。
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つのニュースグループが含まれています。例。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で定義されている）を含む記事は、コントロールメッセージです。さらに、SuperSedesヘッダーフィールドを含む記事のアクションについて説明します。このような記事はコントロールメッセージではありませんが、キャンセルコントロールメッセージと同様のアクションを指定します。
The <control-command> of a Control header field comprises a <verb>, which indicates the action to be taken, and one or more <argument> values, which supply the details. For some control messages, the body of the article is also significant. Each recognized <verb> (the control message type) is described in a separate section below. Agents MAY accept other control message types than those specified below, and MUST either ignore or reject control messages with unrecognized types. Syntactic definitions of valid <argument> values and restrictions on control message bodies are given in the section for each control message type.
コントロールヘッダーフィールドの<Control-Command>は、<動詞>で構成されています。これは、取得するアクションを示し、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」から始まるサブジェクトヘッダーフィールドの存在は、記事をコントロールメッセージとして解釈してはなりません。エージェントは、このようなサブジェクトヘッダーフィールドを備えており、コントロールヘッダーフィールドが曖昧でない記事を拒否する場合があります。同様に、NewsGroupsヘッダーフィールドで「.CTL」で終了する<NewsGroup-Name>の存在またはまた、コントロールヘッダーフィールドの存在は、記事をコントロールメッセージとして解釈してはなりません。
Control messages specify actions above and beyond the normal processing of an article and are therefore potential vectors of abuse and unauthorized action. There is, at present, no standardized means of authenticating the sender of a control message or verifying that the contents of a control message were sent by the claimed sender. There are, however, some unstandardized authentication mechanisms in common use, such as [PGPVERIFY].
コントロールメッセージは、記事の通常の処理を超えてアクションを指定するため、乱用と不正アクションの潜在的なベクトルです。現在、コントロールメッセージの送信者を認証する標準化された手段や、請求された送信者によってコントロールメッセージの内容が送信されたことを確認する標準化された手段はありません。ただし、[pgpverify]など、一般的な使用において標準化されていない認証メカニズムがいくつかあります。
Agents acting on control messages SHOULD take steps to authenticate control messages before acting on them, as determined by local authorization policy. Whether this is done via the use of an unstandardized authentication protocol, by comparison with information obtained through another protocol, by human review, or by some other means is left unspecified by this document. Further extensions or revisions of this protocol are expected to standardize a digital signature mechanism.
コントロールメッセージに作用するエージェントは、ローカル認可ポリシーで決定されたように、コントロールメッセージにアクションする前にコントロールメッセージを認証するための措置を講じる必要があります。これは、標準化されていない認証プロトコルの使用によって行われるかどうか、別のプロトコル、人間のレビュー、または他の手段によって得られた情報と比較して、このドキュメントによって不明確なままになります。このプロトコルのさらなる拡張または改訂は、デジタル署名メカニズムを標準化することが期待されています。
Agents are expected to have their own local authorization policies for which control messages will be honored. No Netnews agent is ever required to act on any control message. The following descriptions specify the actions that a control message requests, but an agent MAY always decline to act on any given control message.
エージェントには、制御メッセージが尊重される独自のローカル認可ポリシーがあることが期待されています。NetNewsエージェントは、制御メッセージに基づいて行動する必要はありません。次の説明は、コントロールメッセージが要求するアクションを指定しますが、エージェントは常に特定のコントロールメッセージに基づいて行動することを拒否する場合があります。
A group control message is any control message type that requests some update to the list of newsgroups known to a news server. The standard group control message types are "newgroup", "rmgroup", and "checkgroups".
グループ制御メッセージは、ニュースサーバーに知られているニュースグループのリストの更新を要求するコントロールメッセージタイプです。標準のグループコントロールメッセージタイプは、「NewGroup」、「RMGroup」、および「CheckGroups」です。
Before honoring any group control message, an agent MUST check the newsgroup or newsgroups affected by that control message and decline to create any newsgroups not in conformance with the restrictions in Section 3.1.4 of [RFC5536].
グループ制御メッセージを尊重する前に、エージェントはそのコントロールメッセージの影響を受けたニュースグループまたはニュースグループをチェックし、[RFC5536]のセクション3.1.4の制限に準拠していないニュースグループの作成を拒否する必要があります。
All of the group control messages MUST have an Approved header field (Section 3.2.1 of [RFC5536]). Group control messages without an Approved header field SHOULD NOT be honored.
すべてのグループ制御メッセージには、承認されたヘッダーフィールドが必要です（[RFC5536]のセクション3.2.1）。承認されたヘッダーフィールドのないグループ制御メッセージは尊重されるべきではありません。
Group control messages affecting specific groups (newgroup and rmgroup control messages, for example) SHOULD include the <newsgroup-name> for the group or groups affected in their Newsgroups header field. Other newsgroups MAY be included in the Newsgroups header field so that the control message will reach more news servers, but due to the special relaying rules for group control messages (see Section 3.6) this is normally unnecessary and may be excessive.
特定のグループ（たとえば、NewGroupおよびRMGroup Controlメッセージ）に影響を与えるグループ制御メッセージには、NewsGroupヘッダーフィールドに影響を受けるグループまたはグループの<sutegroup-name>を含める必要があります。他のニュースグループは、コントロールメッセージがより多くのニュースサーバーに到達するようにニュースグループヘッダーフィールドに含まれる場合がありますが、グループ制御メッセージの特別な中継ルールのため（セクション3.6を参照）、これは通常不要であり、過剰である可能性があります。
The newgroup control message requests that the specified group be created or, if already existing, that its moderation status or description be changed. The syntax of its Control header field is:
NewGroup Controlメッセージは、指定されたグループが作成されるか、既に存在している場合、そのモデレートステータスまたは説明が変更されることを要求します。制御ヘッダーフィールドの構文は次のとおりです。
control-command =/ Newgroup-command
Newgroup-command = "newgroup" Newgroup-arguments
Newgroup-arguments = 1*WSP newsgroup-name
[ 1*WSP newgroup-flag ] newgroup-flag = "moderated"
[1*wsp newgroup-flag] newGroup-flag = "Moderated"
If the request is honored, the moderation status of the group SHOULD be set in accordance with the presence or absence of the <newgroup-flag> "moderated". "moderated" is the only flag defined by this protocol. Other flags MAY be defined by extensions to this protocol and accepted by agents. If an agent does not recognize the <newgroup-flag> of a newgroup control message, it SHOULD ignore that control message.
リクエストが尊重されている場合、グループのモデレートステータスは、<NewGroup-Flag>「Moderated」の存在または不在に従って設定する必要があります。「モデレート」は、このプロトコルで定義される唯一のフラグです。他のフラグは、このプロトコルへの拡張機能によって定義され、エージェントによって受け入れられる場合があります。エージェントがNewGroup Controlメッセージの<NewGroup-Flag>を認識していない場合、そのコントロールメッセージを無視する必要があります。
The body of a newgroup message SHOULD contain an entity of type application/news-groupinfo specifying the description of the newsgroup, either as the entire body or as an entity within a multipart/mixed object [RFC2046]. If such an entity is present, the moderation status specified therein MUST match the moderation status specified by the <newgroup-flag>. The body of a newgroup message MAY contain other entities (encapsulated in multipart/mixed) that provide additional information about the newsgroup or the circumstances of the control message.
新しいグループメッセージの本文には、ニュースグループの説明を指定するタイプアプリケーション/ニュースグループのエンティティを含む必要があります。そのようなエンティティが存在する場合、そこに指定されたモデレートステータスは、<NewGroup-Flag>で指定されたモデレートステータスと一致する必要があります。新しいグループメッセージの本文には、ニュースグループまたはコントロールメッセージの状況に関する追加情報を提供する他のエンティティ（MultiPart/Mixedにカプセル化された）が含まれる場合があります。
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.
アプリケーション/News-Groupinfoエンティティがない場合、ニュースサーバーは、「NewsGroups File：」という行のメッセージの本文を検索し、次の行を<newsgroups-line>として使用できます。アプリケーション/ニュースグループの標準化の前に、これはニュースグループの説明を提供するための慣習でした。
If the request is honored and contains a newsgroup description, and if the news server honoring it stores newsgroup descriptions, the stored newsgroup description SHOULD be updated to the description specified in the control message, even if no other property of the group has changed.
リクエストが尊重され、ニュースグループの説明が含まれている場合、およびそれを称えるニュースサーバーがニュースグループの説明を尊重している場合、グループの他のプロパティが変更されていなくても、保存されたニュースグループの説明をコントロールメッセージで指定した説明に更新する必要があります。
A newgroup control message requesting creation of the moderated newsgroup example.admin.info.
モデレートされたNewsGroup Example.admin.infoの作成を要求する新しいグループ制御メッセージ。
From: "example.* Administrator" <admin@noc.example>
Newsgroups: example.admin.info
Date: 27 Feb 2002 12:50:22 +0200
Subject: cmsg newgroup example.admin.info moderated
Approved: admin@noc.example
Control: newgroup example.admin.info moderated
Message-ID: <ng-example.admin.info-20020227@noc.example>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="nxtprt"
Content-Transfer-Encoding: 8bit
This is a MIME control message.
--nxtprt
Content-Type: application/news-groupinfo; charset=us-ascii
For your newsgroups file: example.admin.info About the example.* groups (Moderated)
NewsGroupsファイルについて：example.admin.info例について。*グループ（モデレート）
--nxtprt
Content-Type: text/plain; charset=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-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 Controlメッセージには、説明と緩和ステータスを備えた階層内のすべての有効なグループのリストが含まれています。ニュースサーバーは、その階層の有効なNewsGroupリストを更新して、指定されたグループを含め、指定されていないグループを削除し、グループの説明とモデレートステータスを更新して、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>引数の順序に関係なく、この方法に従ってください。
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 Controlメッセージの本文には、意図した範囲外のニュースグループのグループステートメントが含まれていてはなりません。<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>引数は、任意の正の整数である場合があります。存在する場合は、ニュースグループリストへの変更ごとに増加する必要があり、減少することはなく、同じ範囲でその後のすべてのチェックグループ制御メッセージに含める必要があります。提供された場合、ニュースサーバーは、特定の階層またはサブヒーラルキーに尊敬されている以前のチェックグループ制御メッセージの<ChkSernr>値を覚えておき、その後のチェックグループ制御メッセージを拒否し、同じ階層またはサブヒエラルキーを尊重します<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>の長さに上限はありません。したがって、<chksernr>を数字として操作できると仮定するのではなく、左側の2つの<chksernr>値の短い方をゼロパッジングして、左側の2つの<chksernr>値の短い値をゼロパッジングして比較することをお勧めします。
For example, the following Control header field
たとえば、次のコントロールヘッダーフィールド
Control: checkgroups de !de.alt #2009021301
indicates that the body of the message will list every newsgroup in the de.* hierarchy, excepting the de.alt.* sub-hierarchy, and should not be honored if a checkgroups control message with a serial number greater than 2009021301 was previously honored. The serial number in this example was formed from the date in YYYYMMDD format, followed by a two-digit sequence number within that date.
メッセージの本文は、de.alt。*サブヒーラルキーを除くすべてのニュースグループがde。*階層のすべてのニュースグループをリストすることを示し、2009021301を超えるシリアル番号を持つチェックグループ制御メッセージが以前に尊重された場合、尊重されるべきではありません。この例のシリアル番号は、yyyymmdd形式の日付から形成され、その後にその日に2桁のシーケンス番号が続きました。
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.
メッセージの本文は、タイプアプリケーション/ニュースチェックグループのエンティティです。適切なMIMEヘッダーを使用してそのように宣言する必要がありますが、ニュースサーバーは、ボディが後方互換性のためのタイプアプリケーション/ニュースチェックグループであるかのように、適切なMIMEヘッダーを欠くチェックグループメッセージを解釈する必要があります。
The cancel control message requests that a target article be withdrawn from circulation and access. The syntax of its Control header field is:
キャンセルコントロールメッセージは、ターゲットの記事を流通とアクセスから撤回することを要求します。制御ヘッダーフィールドの構文は次のとおりです。
control-command =/ Cancel-command
Cancel-command = "cancel" Cancel-arguments
Cancel-arguments = 1*WSP msg-id
The argument identifies the article to be cancelled by its message identifier. The body of the control message MAY contain anything, usually an explanatory text.
この引数は、メッセージ識別子によってキャンセルされる記事を識別します。コントロールメッセージの本文には、通常説明的なテキストが含まれている場合があります。
A serving agent that elects to honor a cancel message SHOULD make the article unavailable to reading agents (perhaps by deleting it completely). If the cancel control message arrives before the article it targets, news servers choosing to honor it SHOULD remember the message identifier that was cancelled and reject the cancelled article when it arrives.
キャンセルメッセージを尊重することを選択したサービングエージェントは、読み取りエージェントが（おそらく完全に削除することにより）記事を利用できないようにする必要があります。キャンセルコントロールメッセージがターゲットになる前に届く場合、それを尊重することを選択するニュースサーバーは、キャンセルされたメッセージ識別子を覚えておく必要があります。
To best ensure that it will be relayed to the same news servers as the original message, a cancel control message SHOULD have the same Newsgroups header field as the message it is cancelling.
元のメッセージと同じニュースサーバーに中継されるようにするために、キャンセルコントロールメッセージは、キャンセルしているメッセージと同じニュースグループヘッダーフィールドを持つ必要があります。
Cancel control messages listing moderated newsgroups in their Newsgroups header field MUST contain an Approved header field like any other article in a moderated newsgroup. This means that cancels posted to a moderated newsgroup will normally be sent to the moderator first for approval. Outside of moderated newsgroups, cancel messages are not required to contain an Approved header field.
NewsGroups Headerフィールドの緩和されたニュースグループをリストするコントロールメッセージをキャンセルする必要があります。これは、モデレートされたニュースグループに投稿されたキャンセルが通常、承認のために最初にモデレーターに送信されることを意味します。モデレートされたニュースグループ以外では、キャンセルメッセージは承認されたヘッダーフィールドを含める必要はありません。
Contrary to [RFC1036], cancel control messages are not required to contain From and Sender header fields matching the target message. This requirement only encouraged cancel issuers to conceal their identity and provided no security.
[RFC1036]とは反対に、ターゲットメッセージに一致する送信者ヘッダーフィールドを内容する必要はありません。この要件は、キャンセル発行者が自分の身元を隠すことを奨励し、セキュリティを提供しませんでした。
The presence of a Supersedes header field in an article requests that the message identifier given in that header field be withdrawn in exactly the same manner as if it were the target of a cancel control message. Accordingly, news servers SHOULD apply to a Supersedes header field the same authentication and authorization checks as they would apply to cancel control messages. If the Supersedes header field is honored, the news server SHOULD take the same actions as it would take when honoring a cancel control message for the given target article.
記事にSuperSedesヘッダーフィールドの存在は、そのヘッダーフィールドに与えられたメッセージの識別子が、キャンセルコントロールメッセージのターゲットであるとまったく同じ方法で撤回されることを要求します。したがって、ニュースサーバーは、コントロールメッセージのキャンセルに適用されるのと同じ認証と承認チェックをSuperSedesヘッダーフィールドに適用する必要があります。SuperSedesヘッダーフィールドが尊重されている場合、ニュースサーバーは、指定されたターゲット記事のキャンセルコントロールメッセージを尊重するときと同じアクションを実行する必要があります。
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.
Supersedesヘッダーフィールドを含む記事は、Supersedesヘッダーフィールドが尊重されるかどうかにかかわらず、通常の記事として処理されるべきであり、セクション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.
記事の本文は、1行あたり1つの<sg-id>のリストで構成されています。メッセージ識別子は、コントロールヘッダーフィールドではなく記事の本文に配置する必要がありますが、ニュースサーバーは、後方互換性のためにコントロールヘッダーフィールドのメッセージ識別子を認識して処理する場合があります。コントロールメッセージの本文に存在する場合、メッセージ識別子をコントロールヘッダーフィールドに入れてはなりません。
The ihave message states that the named relaying agent has received articles with the specified message identifiers, which may be of interest to the relaying agents receiving the ihave message. The sendme message requests that the agent receiving it send the articles having the specified message identifiers to the named relaying agent. Contrary to [RFC1036], the relayer-name MUST be given as the last argument in the Control header field.
iHaveメッセージは、指定された中継エージェントが指定されたメッセージ識別子を含む記事を受け取ったことを示しています。sendmeメッセージは、指定されたメッセージ識別子を持つ記事を指定された中継エージェントに送信することを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>.
これらの制御メッセージは通常、2つのサイト間でポイントツーポイントの記事として送信され、他のサイトに送信されません。「to」で始まるニュースグループ。このようなポイントツーポイント通信のために予約されており、「to」を準備することによって形成されます。<relayer-name>に<newsgroup-name>を形成します。ニュースグループのヘッダーフィールドにそのようなグループがある記事は、<lirayer-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.
NetNewsは、パブリックメッセージの広範な普及のために設計されており、セキュリティの方法ではほとんど提供されていません。Netnewsが虐待やなりすましに対して持っている保護は、主に基礎となる輸送層によって提供されます。輸送層で認証と承認の要件を強制するためにニュースサーバーを信頼できない大規模なNetNewsネットワークでは、記事は簡単に偽造され、広く読まれ、記事送信者のアイデンティティと記事のプライバシーを保証することはできません。
See Section 5 of [RFC5536] for further security considerations related to the format of articles.
記事の形式に関連するさらなるセキュリティ上の考慮事項については、[RFC5536]のセクション5を参照してください。
Control messages pose a particular security concern since acting on unauthorized control messages may cause newsgroups to be removed, articles to be deleted, and unwanted newsgroups to be created. Administrators of news servers SHOULD therefore take steps to verify the authenticity of control messages as discussed in Section 5.1. Articles containing Supersedes header fields are effectively cancel control messages and SHOULD be subject to the same checks as 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で説明したように、制御メッセージの信頼性を確認するための措置を講じる必要があります。Supersedesヘッダーフィールドを含む記事は、制御メッセージを効果的にキャンセルし、セクション5.4で説明したのと同じチェックの対象となるはずです。現在、多くのサイトは、認証とその広範な虐待を認証することの難しさにより、すべての制御メッセージとSuperSedesヘッダーフィールドを無視しています。
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.
キャンセルコントロールメッセージは、キャンセルしているメッセージと同じニュースグループヘッダーフィールドを持つ必要はありません。元のメッセージを受信する前に処理されることがあるため、NewsGroupヘッダーフィールドが一致することを確認することはできない場合があります。これにより、悪意のあるポスターは、承認されたヘッダーフィールドをコントロールメッセージに追加せずに、モデレートニュースグループの記事のキャンセルコントロールメッセージを挿入し、別のニュースグループヘッダーフィールドを使用していくつかの読み取りエージェントからの悪意のあるキャンセルメッセージを非表示にすることができます。キャンセルコントロールメッセージは、元のメッセージを受け入れたすべてのニュースサーバーによって受け入れられません。
All agents should be aware that all article content, most notably including the content of the Control header field, is potentially untrustworthy and malicious. Articles may be constructed in syntactically invalid ways to attempt to overflow internal buffers, violate hidden assumptions, or exploit implementation weaknesses. For example, some news server implementations have been successfully attacked via inclusion of Unix shell code in the Control header field. All article contents, and particularly control message contents, SHOULD be handled with care and rigorously verified before any action is taken on the basis of the contents of the article.
すべてのエージェントは、すべての記事コンテンツ、特にコントロールヘッダーフィールドのコンテンツを含めることは、信頼できず、悪意がある可能性があることに注意する必要があります。記事は、内部バッファーのオーバーフロー、隠された仮定に違反する、または実装の弱点を活用しようとする構文的に無効な方法で構築される場合があります。たとえば、一部のニュースサーバーの実装は、コントロールヘッダーフィールドにUNIXシェルコードを含めることで正常に攻撃されています。すべての記事の内容、特にコントロールメッセージの内容は、記事の内容に基づいてアクションが取得される前に、注意して厳密に検証する必要があります。
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.
NetNewsネットワークに参加している悪意のあるニュースサーバーは、注射剤、Forge Path Headerフィールド、およびその他のトレース情報（噴射INFOヘッダーフィールドなど）によって実行されるチェックをバイパスする場合があり、その他の場合はNetNewsネットワークの承認要件を侵害します。ニュースサーバーは、基礎となる輸送の施設を使用して、同僚を認証し、このプロトコルまたはNetNewsネットワークの要件に従わないエージェントの注入と中継を拒否する必要があります。
The proper functioning of individual newsgroups can be disrupted by the excessive posting of unwanted articles; by the repeated posting of identical or near identical articles; by posting followups that either are unrelated to their precursors or that quote their precursors in full with the addition of minimal extra material (especially if this process is iterated); by crossposting to, or requesting followups to, totally unrelated newsgroups; and by abusing control messages and the Supersedes header field to delete articles or newsgroups.
個々のニュースグループの適切な機能は、不要な記事の過度の投稿によって混乱する可能性があります。同一またはほぼ同一の記事の繰り返しの投稿によって。前駆体とは関係のないフォローアップを投稿するか、最小限の余分な材料を追加して前駆体を完全に引用することにより（特にこのプロセスが反復されている場合）。まったく無関係なニュースグループにクロスポストするか、フォローアップを要求することにより。また、コントロールメッセージとSupersedesヘッダーフィールドを乱用して、記事やニュースグループを削除します。
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.
サービスを拒否することを目的としたこのような記事、または炎症性の性質の他の記事には、FromまたはReply-to Addressが有効だが誤ったメールアドレスに設定されている可能性があり、そのため、これらのアドレスの真の所有者に大量の電子メールが降りてきます。ユーザーとエージェントは、記事で情報を特定することが偽造される可能性があることに常に注意する必要があります。
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-keyword>「投稿」の使用は、この攻撃を防ぐことができます。
Primary responsibility for preventing such attacks lies with injecting agents, which can apply authentication and authorization checks via the underlying transport and prevent those attempting denial-of-service attacks from posting messages. If specific injecting agents fail to live up to their responsibilities, they may be excluded from the Netnews network by configuring relaying agents to reject articles originating from them.
そのような攻撃を防ぐための主な責任は、注入エージェントにあります。これは、基礎となる輸送を介して認証と承認チェックを適用し、サービス拒否攻撃がメッセージを投稿するのを防ぐことができます。特定の注入剤が責任に耐えられない場合、リレーを拒否するようにリレーを構成することにより、NetNewsネットワークから除外される可能性があります。
A malicious complainer may submit a modified copy of an article (with an altered Injection-Info header field, for instance) to the administrator of an injecting agent in an attempt to discredit the author of that article and even to have his posting privileges removed. Administrators SHOULD therefore obtain a genuine copy of the article from their own serving agent before taking action in response to such a complaint.
悪意のある申立人は、その記事の著者を信用したり、投稿の特権を削除したりするために、注射剤の管理者に記事の修正コピー（たとえば変更されたインジェクションインフォヘッダーフィールド）を提出する場合があります。したがって、管理者は、そのような苦情に応じて行動を起こす前に、自分のサービングエージェントから記事の本物のコピーを取得する必要があります。
Articles that are intended to have restricted distribution are dependent on the goodwill of every site receiving them. Restrictions on dissemination and retention of articles may be requested via the Archive and Distribution header fields, but such requests cannot be enforced by the protocol.
分布が制限されることを目的とした記事は、それらを受け取るすべてのサイトののれんに依存します。記事の普及と保持の制限は、アーカイブおよび配布ヘッダーフィールドを介して要求される場合がありますが、そのような要求はプロトコルによって施行されることはできません。
The flooding algorithm used by Netnews transports such as NNTP [RFC3977] is extremely good at finding any path by which articles can leave a subnet with supposedly restrictive boundaries, and substantial administrative effort is required to avoid this. Organizations wishing to control such leakage are advised to designate a small number of gateways to handle all news exchanges with the outside world.
NNTP [RFC3977]などのNetNews輸送で使用される洪水アルゴリズムは、記事がおそらく制限的な境界を持つサブネットを残すことができるパスを見つけるのに非常に優れており、これを回避するために実質的な管理努力が必要です。このような漏れを制御したい組織は、外の世界とのすべてのニュース交換を処理するために、少数のゲートウェイを指定することをお勧めします。
The sendme control message (Section 5.5), insofar as it is still used, can be used to request articles that the requester should not have access to.
SendMe Controlメッセージ（セクション5.5）は、まだ使用されている限り、要求者がアクセスできない記事を要求するために使用できます。
IANA has registered the following media types, described elsewhere in this document, for use with the Content-Type header field, in the IETF tree in accordance with the procedures set out in [RFC4288].
IANAは、[RFC4288]に記載されている手順に従って、IETFツリーで、コンテンツタイプのヘッダーフィールドで使用するために、このドキュメントの他の場所で説明されている次のメディアタイプを登録しました。
application/news-transmission (4.1) application/news-groupinfo (4.2) application/news-checkgroups (4.3)
アプリケーション/ニューストランスミッション（4.1）アプリケーション/ニュースグループ（4.2）アプリケーション/ニュースチェックグループ（4.3）
application/news-transmission is a change to a previous registration.
アプリケーション/ニューストランスミッションは、以前の登録の変更です。
IANA has registered the new header field, Original-Sender, in the Permanent Message Header Field Repository, using the template in Section 3.10.3.
IANAは、セクション3.10.3のテンプレートを使用して、永続的なメッセージヘッダーフィールドリポジトリに新しいヘッダーフィールドであるオリジナルセンダーを登録しています。
IANA has changed the status of the message/news media type to "OBSOLETE". message/rfc822 should be used instead. An updated template is included in Section 4.
IANAは、メッセージ/ニュースメディアタイプのステータスを「時代遅れ」に変更しました。メッセージ/RFC822を代わりに使用する必要があります。更新されたテンプレートはセクション4に含まれています。
[ASCII] American National Standard for Information Systems, "Coded Character Sets - 7-Bit American National Standard Code for Information Interchange (7-Bit ASCII)", ANSI X3.4, 1986.
[ASCII]情報システムのためのアメリカ国家標準、「コード化された文字セット-7ビットの情報インターチェンジのためのアメリカ国家標準コード（7ビットASCII）」、ANSI X3.4、1986。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046] Freed、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288] Freed、N。およびJ. Klensin、「メディアタイプの仕様と登録手順」、BCP 13、RFC 4288、2005年12月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強」、STD 68、RFC 5234、2008年1月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322] Resnick、P.、ed。、「インターネットメッセージ形式」、RFC 5322、2008年10月。
[RFC5536] Murchison, K., Ed., Lindsey, C., and D. Kohn, "Netnews Article Format", RFC 5536, November 2009.
[RFC5536] Murchison、K.、Ed。、Lindsey、C。、およびD. Kohn、「Netnews Article Format」、RFC 5536、2009年11月。
[PGPMOOSE] Rose, G., "PGP Moose", November 1998.
[PGPMOOSE] ROSE、G。、「PGP Moose」、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.
[RFC1036] Horton、M。およびR. Adams、「Usenetメッセージの交換の標準」、RFC 1036、1987年12月。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.
[RFC2606] Eastlake、D。およびA. Panitz、「予約されたトップレベルDNS名」、BCP 32、RFC 2606、1999年6月。
[RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition Notification", RFC 3798, May 2004.
[RFC3798] Hansen、T。およびG. Vaudreuil、「メッセージ処分通知」、RFC 3798、2004年5月。
[RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", RFC 3977, October 2006.
[RFC3977]フェザー、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.
[使用] Lindsey、C。、「Usenet Best Practice」、2005年3月、進行中の作業。
[UUCP] O'Reilly, T. and G. Todino, "Managing UUCP and Usenet", O'Reilly & Associates Ltd., January 1992.
[UUCP] O'Reilly、T。およびG. Todino、「UUCPとUSENETの管理」、O'Reilly＆Associates Ltd.、1992年1月。
This document prescribes many changes, clarifications, and new features since the protocol described in [RFC1036]. Most notably:
この文書は、[RFC1036]で説明されているプロトコル以来、多くの変更、説明、新機能を規定しています。最も注目すべき：
o A new, backward-compatible Path header field format that permits standardized embedding of additional trace and authentication information is now RECOMMENDED. See Section 3.2. Folding of the Path header is permitted.
o 追加のトレースおよび認証情報の標準化された埋め込みを許可する新しい、後方互換性のあるパスヘッダーフィールド形式が推奨されます。セクション3.2を参照してください。パスヘッダーの折りたたみが許可されています。
o Trimming of the References header field is REQUIRED, and a mechanism for doing so is defined.
o 参照ヘッダーフィールドのトリミングが必要であり、そうするためのメカニズムが定義されています。
o Addition of the new Injection-Date header field is required in some circumstances for posting agents (Section 3.4.2) and injecting agents (Section 3.5), and MUST be used by news servers for date checks (Section 3.6). Injecting agents are also strongly encouraged to put all local trace information in the new Injection-Info header field.
o 状況によっては、新しい注入日付ヘッダーフィールドの追加が必要です（セクション3.4.2）および注入剤（セクション3.5）の射出剤（セクション3.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）を介してNetNewsの記事を送信するために定義されており、モデレーターはその形式の提出物を受け取る準備をする必要があります（セクション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 Controlメッセージに2つの新しいオプションパラメーターが追加されます。
o The message/news media type is declared obsolete.
o メッセージ/ニュースメディアタイプは時代遅れと宣言されています。
o Cancel control messages are no longer required to have From and Sender header fields matching those of the target message, as this requirement added no real security.
o この要件は実際のセキュリティを追加しなかったため、ターゲットメッセージのものと一致する送信者ヘッダーフィールドをキャンセルする必要はありません。
o The relayer-name parameter in the Control header field of ihave and sendme control messages is now required.
o iHaveおよびsendMeコントロールメッセージのコントロールヘッダーフィールドの中継パラメーターが必要になりました。
In addition, many protocol steps and article verification requirements that are unmentioned or left ambiguous by [RFC1036] but are widely implemented by Netnews servers have been standardized and specified in detail.
さらに、[RFC1036]によって言及されていない、または曖昧なものであるが、NetNewsサーバーによって広く実装されている多くのプロトコルの手順と記事検証要件が標準化および詳細に指定されています。
This document is the result of a twelve-year effort and the number of people that have contributed to its content are too numerous to mention individually. Many thanks go out to all past and present members of the USEFOR Working Group of the Internet Engineering Task Force (IETF) and the accompanying mailing list.
この文書は、12年の努力の結果であり、その内容に貢献した人の数は個別に言及するには多すぎます。インターネットエンジニアリングタスクフォース（IETF）と付随するメーリングリストのワーキンググループの過去と現在のすべてのメンバーに感謝します。
Special thanks are due to Henry Spencer, whose [SON-OF-1036] draft served as the initial basis for this document.
ヘンリー・スペンサーに感謝します。ヘンリー・スペンサーの[息子]ドラフトがこの文書の初期基盤として機能しました。
Authors' Addresses
著者のアドレス
Russ Allbery (editor) Stanford University P.O. Box 20066 Stanford, CA 94309 US
Russ Allbery（編集者）スタンフォード大学P.O.Box 20066 Stanford、CA 94309 US
EMail: 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クレアウッドアベニューヒールグリーンチードルチェシャーSK8 3JUイギリス
Phone: +44 161 436 6131
EMail: chl@clerew.man.ac.uk