Network Working Group M. Horton Request for Comments: 1036 AT&T Bell Laboratories Obsoletes: RFC-850 R. Adams Center for Seismic Studies December 1987 USENET メッセージ交換のためのスタンダード このメモの位置づけ 本稿は USENET ホスト間において、ネットワークニュースのメッセージ交換を行うた めの標準フォーマットを定義する。本稿はニュースプログラムバージョン B2.11 を反映 しており、RFC-850 を更新、置換するものである。このメモはインターネットコミュニ ティが入手しやすいように、RFC として配布される。本稿はインターネット標準を規定 しない。このメモの配布は無制限である。 1. はじめに 本稿は USENET ホスト間において、ネットワークニュースのメッセージ交換を行うた めの標準フォーマットを定義する。メッセージそれ自体のフォーマットを記述し、 ニュース伝達に関する部分的な標準を与えるものである。ニュース伝達は、ホストに伝 達ハードウェア、ソフトウェアを選択したり、バッチ処理をさせる等の相当な柔軟性を 与えるという目的のために、完全ではない。 本稿は 5 つのセクションから構成される。セクション 2 ではフォーマットを定義す る。セクション 3 では有効な制御メッセージを定義する。セクション 4 では幾つかの 有効な伝達手法を規定する。セクション 5 ではニュースの伝播アルゴリズム全体につい て述べる。 2. メッセージフォーマット メッセージフォーマット選択に際して主に考慮すべきことは、現存するツールに出来 るだけ適合させることである。現存するツールは、メールとニュース双方の実装を含 む。(イリノイ大学の notefiles system は、ニュースの実装と考えられる)。メール メッセージの標準フォーマットは長年にわたりインターネット上に存在しており、また USENET の要求をほぼ全て満たしている。インターネットフォーマットは拡張性があるの で、USENET の追加要求を満たすための拡張はインターネット標準の範囲内で容易になさ れる。そのため、全ての USENET ニュースメッセージは RFC822 にしたがった正当なイ ンターネットメールメッセージとしてフォーマットされなければならない、という規則 が採択された。USENET ニュース標準はインターネット標準よりも制約が厳しく、各メッ セージにおいて付加的な必要項目を設定したり、幾つかのインターネット特性の使用を 禁じている。しかし、ニュースメッセージ処理のために、インターネットメッセージを 期待するツールは常に使用可能であるべきである。本標準とインターネット標準が衝突 する場合は、常に RFC822 が正しく、本標準にエラーがあると考えるべきである。 以下は、フィールドを説明するための USENET メッセージ例である。 From: jerry@eagle.ATT.COM (Jerry Schwarz) Path: cbosgd!mhuxj!mhuxt!eagle!jerry Newsgroups: news.announce Subject: Usenet Etiquette -- Please Read Message-ID: <642@eagle.ATT.COM> Date: Fri, 19 Nov 82 16:14:55 GMT Followup-To: news.misc Expires: Sat, 1 Jan 83 00:00:00 -0500 Organization: AT&T Bell Laboratories, Murray Hill 空行後、メッセージのボディがここに入る。 以下は、旧フォーマット (本標準規定前) のメッセージ例である。上位への変換を容 易にするために、実装ではこのフォーマットのメッセージも受理することを推奨する。 From: cbosgd!mhuxj!mhuxt!eagle!jerry (Jerry Schwarz) Newsgroups: news.misc Title: Usenet Etiquette -- Please Read Article-I.D.: eagle.642 Posted: Fri Nov 19 16:14:55 1982 Received: Fri Nov 19 16:59:30 1982 Expires: Mon Jan 1 00:00:00 1990 空行後、メッセージのボディがここに入る。 幾つかのニュースシステムは、ニュースを A フォーマットで伝達する。 A フォー マットとは、以下のようなものである。 Aeagle.642 news.misc cbosgd!mhuxj!mhuxt!eagle!jerry Fri Nov 19 16:14:55 1982 Usenet Etiquette - Please Read 空行無しでメッセージのボディがここに入る。 標準 USENET メッセージは数行のヘッダラインとそれに続く空行、その後に続くメッ セージのボディから構成される。各ヘッダラインはキーワード、ブランク、幾つかの付 加的情報から成る。これはインターネット標準のサブセットであり、ソフトウェアがよ り簡易に扱えるよう、簡単化したものである。"From" 行には、上述のフォーマットか、 インターネット標準の"( )"文法を用いて、フルネームを含めても良い。実装を簡潔なま ま保つために、他のフォーマット (例えば、閉じ括弧の後にマシンアドレスの一部を載 せるなど) は禁止されている。ヘッダ行の連結 (ブランク、タブで始まる) のインター ネット上の慣習は認められている。 幾つかのヘッダ行は必須であり、別の幾つかはオプショナルである。どのような理解 されないヘッダでも許されており、変更されることなく通過する。必須のヘッダ行は、 "From"、"Date"、"Newsgroups"、"Subject"、"Message-ID"、"Path" である。オプショ ナルなヘッダ行は "Followup-To"、"Expires"、"Reply-To"、"Sender"、 "References"、"Control"、"Distribution"、"Keywords"、"Summary"、"Approved"、 "Lines"、"Xref"、"Organization" である。ヘッダ行それぞれについて、以下に記述す る。 2.1 必須のヘッダ行 2.1.1 From "From" 行はメッセージを送信した人物の電子メールアドレスをインターネットの文法 で表記したものを含む。また、電子メールアドレスに続けて、オプショナルに、丸括弧 内にフルネームを含めることができる。電子メールアドレスは "Sender" 行が無けれ ば、そのメッセージを生成したレスポンシブルな実体と同じである。 "Sender" 行があ る場合には、"From" 行は検証されなくとも良い。ここで、全てのホスト名、ドメイン名 は、大文字、小文字の区別がされないことに注意してほしい。つまり "mark@cbosgd.ATT.COM" と "mark@cbosgd.att.com"、"mark@CBosgD.ATt.COm" は全て等 価である。ユーザ名は大文字、小文字の区別がある場合と無い場合がある。例えば、 "Billy@cbosgd.ATT.COM" は、"BillY@cbosgd.ATT.COM" とは異なるかもしれない。プロ グラムはニュース、メール配送時に大文字、小文字の変換を避けるべきである。 RFC822 は、丸括弧内のテキストは全てコメントとして翻訳されると規定している。イ ンターネットメールでは、普通 "From" 行の最後にユーザのフルネームを置く。本標準 では、より厳格な文法を規定する。フルネームはコメントとは見なされず、ヘッダ行の オプショナルな一部であると考える。フルネームは省略されているか、またはメッセー ジを投稿した人物の電子メールアドレス後に丸括弧内に書かれるか、カギ括弧に囲まれ た電子メールアドレスの前に書かれるか、どれかである。以上より許可されている 3 つ の形式は以下のとおりとなる。 From: mark@cbosgd.ATT.COM From: mark@cbosgd.ATT.COM (Mark Horton) From: Mark Horton フルネームは、"("、")"、"<"、">" を除く、ブランクからチルダまでの printing ASCII キャラクタを含む。メールの標準により、付加的な制約がなされる。特に、 ","、":"、"@"、"!"、"/"、"="、";" をフルネームに含めることは奨められない。 2.1.2 Date "Date" 行 (旧 "Posted") は、メッセージが初めてネットワークに投稿された日付で ある。このフォーマットは、RFC822 と USENET ソフトウェアによって提供される getdate(3) 両方に容認されるものでなければならない。date はメッセージがネット ワークを伝播する際にも変更されない。どちらにも容認されるフォーマットの 1 つとし て、以下のものがある。 Wdy, DD Mon YY HH:MM:SS TIMEZONE 幾つかの有効な日付の例を先に示したメッセージ例に見ることが出来る。注意すべき は、ctime(3)のフォーマット、すなわち Wdy Mon DD HH:MM:SS YYYY は RFC822 date で有効ではないため、容認されないということである。しかし、旧いソ フトウェアは依然としてこのフォーマットで日付を生成するため、ニュースの実装で は、このフォーマットを受理し、容認できるフォーマットに変換することが奨励され る。 完全なタイムゾーンのリストを持つ見込みは全くない。万国標準時 (GMT)、北米のタ イムゾーン (PST、PDT、MST、MDT、CST、CDT、EST、EDT)、RFC822 で規定されている +/- hhmm のオフセットがサポートされるべきである。メッセージヘッダに現れる時刻は GMT に変換され、ローカルなタイムゾーンで表示することを推奨する。 2.1.3 Newsgroups "Newsgroups" 行は、そのメッセージが属する 1つまたは複数のニュースグループを指 定する。複数のニュースグループはカンマで区切って指定する。指定するニュースグ ループは、全て存在するニュースグループ名でなければならない。単に (存在しない ニュースグループに) 投稿しても、新しいニュースグループが作成されるわけではない からである。 ワイルドカード (例えば "all" という語) は "Newsgroups" 行では絶対に容認されな い。例えば、ニュースグループ rec.sport.football は許されても、comp.all は違反で ある。 "Newsgroups" 行に幾つかの有効なニュースグループ名、幾つかの無効なニュースグ ループ名がリストされたメッセージを受信した場合、ホストは無効なニュースグループ を削除すべきではない。無視すべきである。例えば、ホスト A は comp.*、 btl.* を購 読しており、ホスト B とニュースメッセージの交換をしているとする。ホスト B は comp.* は購読しているが、btl.* は購読していないとする。ここで、ホスト A が Newsgroups: comp.unix, btl.general というヘッダを持つメッセージを受信したと仮定 する。 このメッセージは B に渡される。B は comp.unix を受け取るからである。しかし、 B は btl.general を受け取らない。A は "Newsgroups" 行を変更せずに残さなければな らない。btl.general が削除された場合、編集されたヘッダ行には btl 全てを再記入し ないと btl.general を購読しているユーザからは見えなくなってしまうからである。ま た、btl.* 外からのフォローも読めなくなってしまう。 2.1.4 Subject "Subject" 行 (旧 "Title") はメッセージが何に関するものかを示す。読者が Subject だけを見て、このメッセージを読むかどうか判断できるようにするため、メッ セージの内容を十分に暗示させるものであるべきである。メッセージが別のメッセージ に応じた提示物 (例えば、フォローアップ) の場合、default の subject は "Re:" の 4 文字で始まるべきである。また、"References" 行が必要とされる。フォローアップで は、"Summary" 行を使用することが奨励される。 2.1.5 Message-ID "Message-ID" 行はメッセージに唯一の identifier を与える。Message-ID は、以前 使用した同じ Message-ID を持つメッセージの寿命が尽きるまでは再使用してはいけな い。(少なくとも 2 年間は、どんな Message-ID も再使用しないことを推奨する)。 Message-ID は以下のような文法を持つ。 <空白、">" を含まない文字列> RFC822 にしたがうよう、Message-ID は以下のフォーマットでなければならない。 ここで、full_domain_name とはメッセージをネットワークに送信したホストのフルネー ムであり、ホストが存在するドメインまでを含めたものである。unique は "<"、">"、 "@" を除く、任意の printing ASCII キャラクタである。 例えば、unique 部はネットワークにメッセージを送信したシーケンス番号や、メッ セージが作成された日時から導き出される短い文字列である。"Berkeley.EDU" ドメイン のホスト "ucbvax" から送出されるメッセージの有効な Message-ID は、 "<4123@ucbvax.Berkeley.EDU>" である。プログラマ達は、他のホストから受理した Message-ID の内容について、何も仮定せず、unknown な文字列として扱うよう求められ る。例えば、Message-ID は 14 文字以下だと仮定したり、最初の 14 文字は unique で あると仮定したり、"/" は含まれないと仮定することは危険である。 カギ括弧は Message-ID の一部と考えられる。したがって、ihave/sendme、cancel 制 御メッセージなど、Message-ID が参照される際にはカギ括弧までが含まれる。空白、タ ブ等のキャラクタは Message-ID では許されない。スラッシュ ("/") は強く反対され る。カギ括弧内に含まれる文字列は、全て printing ASCII キャラクタでなければなら ない。 2.1.6 Path この行は、メッセージが現在のシステムにたどり着くまでに通過した経路を示す。シ ステムがメッセージをフォワードする際、"Path" 行のシステムのリストに自身の名前を 追加すべきである。名前は句読点のどれか、あるいは数種類の句読点によって区切られ る。("." は例外で、ホスト名の一部と考えられる)。したがって、以下は有効なエント リである。 cbosgd!mhuxj!mhuxt cbosgd, mhuxj, mhuxt @cbosgd.ATT.COM,@mhuxj.ATT.COM,@mhuxt.ATT.COM teklabs, zehntel, sri-unix@cca!decvax (最後のエントリは、メッセージが decvax、cca、sri-unix、zehntel、teklabs という 順に通過してきたという経路を示している)。追加される名前は、左から追加される。例 えば、4 番目の例では最も最近付け加えられた名前は teklabs である。英文字、数字、 ピリオド、ハイフンはホスト名の一部と考えられる。他の句読点、空白はセパレータと 考えられる。 普通、最右翼にある名前はメッセージを生成したシステムの名前である。しかし、特 別なエントリ、すなわち送信者名を右に含めることも認められている。これは旧いシス テムと上位互換を保つためである。 "Path" 行は reply には使用されない。また、メールアドレスとして受け取られるべ きではない。メッセージがローカルホストに到達するまでに通ってきた経路を示すこと が目的である。この情報には、幾つかの使い方がある。1 つは、パフォーマンス的理由 で USENET の経路制御をモニタすることである。もう 1 つは、新しいホストに到達する 経路を選択することである。おそらく、最も重要な使い方は、既にそのメッセージを受 信したことがわかっているホストには送信しないことにより、冗長な USENET トラ フィックを削減することである。特に、ホスト A が B にメッセージを送信すると、 "Path" 行には A が含まれる。したがって、B は A に直接メッセージを送り返さない。 各ホストが自身を識別するために使用する名前は、最適化を可能にするため、隣接ホス トが知っているのと同じ名前であるべきである。 ホストは、メッセージを他のホストから受信すると、自身の名前を path の先頭に追 加する。したがって、path "A!X!Y!Z" を持つメッセージがホスト A からホスト B に通 過すると、B は A からメッセージを受信したときに自分の名前を path に追加する。す なわち、"B!A!X!Y!Z" となる。その後、B が C にメッセージを渡すと、C に渡される メッセージは path "B!A!X!Y!Z" を含む。C がそれを受信すると、C は "C!B!A!X!Y!Z" へと変更する。 特別な上位互換に関する注意: "From"、"Sender"、"Reply-To" がインターネット フォーマットにあり、また多くの USENET ホストはインターネットフォーマットを理解 するメーラを持たない。したがって、"Path" ヘッダと reply 機能を完全に切り離さ れ、 reply 機能を使用できなくするかもしれない。古い実装では、 path は必ずしも有 効な reply 文字列でないことがわかっており、この問題を解決するための必要項目は存 在しない。しかし、path の前にホスト名と "!" を置き、path はホスト名、"!"、ユー ザ名で始める現在の慣習は、可能ならば維持されるべきである。 2.2 オプショナルなヘッダ行 2.2.1 Reply-To この行は "From" 行と同じフォーマットである。この行があると、著者へのメール reply はここで与えられたところに配送される。そうでない場合 (=この行が無い場 合)、reply は "From" 行の名前に配送される。(送信者から replier によって示された 受信者、もしくは "To"、"Cc" 行に示された受信者への付加的なコピーを妨げるもので はない)。フルネームは "From" 行のように、丸括弧内にオプショナルに与えられる。 2.2.2 Sender このフィールドは、メッセージ提出者が手動で "From" 行を入力した場合にのみ存在 する。これは、ネットワークに送信されようとしているメッセージに対する、レスポン シブルな実体を記録することを意図しているので、メッセージ提出ホストにおいて、ソ フトウェアによって検証がされるべきである。 例えば、John Smith が CCA を訪れ、友人 Sarah Jones のアカウントを用いてネット ワークへのメッセージ投稿を希望したとすると、そのメッセージは以下のようになる。 From: smith@ucbvax.Berkeley.EDU (John Smith) Sender: jones@cca.COM (Sarah Jones) ゲートウェイプログラムが unix.SRI.COM 上でメールメッセージをネットワークに流 したとすると、この行は以下のようになる。 From: John.Doe@A.CS.CMU.EDU Sender: network@unix.SRI.COM このフィールドの主な目的は、メッセージがどのようにしてネットワークに送信され たかを追跡可能にすることにある。フルネームは "From" 行のように、丸括弧内にオプ ショナルに与えられる。 2.2.3 Followup-To この行は "Newsgroups" 行と同じフォーマットである。この行が存在すると、フォ ローアップメッセージはここにリストされた 1 つまたは複数のニュースグループに投稿 される。この行が無ければ、フォローアップは "Newsgroups" 行にリストされたニュー スグループに投稿される。 "poster" というキーワードが存在する場合は、フォローアップメッセージは許可され ない。メッセージはメールによって、メッセージの submitter に送られるべきである。 2.2.4 Expires この行がある場合、適切な USENET date フォーマットで記述される。これは、 (著者 の提案する) メッセージの廃棄 (expiration) 日時を指定する。この行が無い場合、 ローカルに設定された default の廃棄日時が使用される。このフィールドは限られた期 間だけ有用なメッセージを消去したり、重要なメッセージを通常より長く保存すること を目的とする。例えば、近日中に開催されるセミナーをアナウンスするメッセージは、 セミナー終了後の日時を廃棄日時として設定することが考えられる。そのメッセージは セミナー終了後には無用となるからである。ローカルなホストは、ニュースの廃棄に関 してローカルなポリシ (使用可能なディスク領域に依存するような) を持っているか ら、あるトピックに関して自然な廃棄日時が存在しないならば、ユーザが廃棄日時を提 供することは推奨されない。システムソフトウェアはほとんどの場合、default の "Expire" 行を提供しない。特別な理由が無い限り、その行を省略し、ローカルなポリシ を用いることを許している。 2.2.5 References このフィールドには、メッセージの提案を促した全メッセージの Message-ID がリス トされる。この行は全てのフォローアップメッセージにおいて必要とされ、新しい Subject を興す際には使用が禁止される。実装では、ユーザにフォローアップメッセー ジの投稿を許すような、follow-up コマンドを提供するべきである。このコマンドは、 オリジナルメッセージの "Subject" 行が "Re:"、"re:" ではじまっていないならば、 subject の前に "Re:" の 4 文字を挿入した "Subject" 行を生成すべきである。また、 オリジナルに "References" 行が無いならば、"Reference" はオリジナルメッセージの Message-ID (カギ括弧を含む) を含めるべきである。オリジナルメッセージが "Reference" 行を持っている場合には、フォローアップメッセージの "References" 行 にはオリジナルの "References"、空白、オリジナルメッセージの Message-ID が含めら れるべきである。 "Reference" ヘッダの目的は、ユーザインタフェースプログラムによって、メッセージ を会話単位にグループ化することにある。これにより、あるニュースグループ内の会話 を共に保存でき、潜在的にはユーザがニュースグループの購読を止めることなしに、あ る会話全体を隔離することができる。ユーザインタフェースはこのヘッダを使用する必 要はないが、自動的に生成される全てのフォローアップメッセージは、それを使用する システムの利益のために "References" 行を生成すべきである。手動で作成されたフォ ローアップ (オリジナルのメッセージをプリントした後にタイプされたもの) も同様に "References" 行を含めることが推奨される。 オリジナルの "References" 行が長すぎる場合、完全に含めなくても許される。合理 的な後方参照数が含められるよう、試行がなされるべきである。 2.2.6 Control メッセージが "Control" 行を含む場合、そのメッセージは制御メッセージである。制 御メッセージは USENET ホストマシン間の連絡に用いられるものであり、ユーザに読ま れるものではない。制御メッセージは普通のメッセージと同様に newsgroup の機構を用 いて配布される。"Control" ヘッダ行の body は、ホストへのメッセージである。 上位互換のために、"all.all.ctl" というニュースグループのパターンにマッチする メッセージは、制御メッセージとして翻訳される。"Control" ヘッダが存在しなけれ ば、subject が制御メッセージとして使用される。しかし、このパターンにマッチする ニュースグループのメッセージは、本標準にしたがうものではない。 これとは別に、上位互換のために "Subject:" 行の最初の 4 文字が "cmsg" である場 合、残りの "Subject:" 行は制御メッセージとして翻訳される。 2.2.7 Distribution この行はメッセージの配布範囲を変更するために用いられる。"Newsgroups" 行と同じ ように、カンマで区切られたリストである。ユーザの投稿先は依然として "Newsgroups" 行に制御されるが、メッセージは "Distribution" 行に記載された (範囲にある)、その ニュースグループを購読している全システムに配送される。配送されようとしている メッセージにとって、受け取るサイトは指定したニュースグループの 1 つを受け取り、 かつまた指定した distribution の 1 つを受けとらなければならない。したがって、 ニュージャージー州の車の売買に関するメッセージは、以下のようなヘッダを含んでい よう。 Newsgroups: rec.auto,misc.forsale Distribution: nj,ny このヘッダのため、このメッセージはニュージャージー、ニューヨーク内にある、 rec.auto か misc.forsale を購読している者のところにだけ配送される。このヘッダの 目的はニュースグループの配布をより制限することであり、広げることではない。 nj.crazy-eddie のようなローカルニュースグループは、そのニュースグループを有効と 見なさないニュージャージー外のホストには伝播されない。フォローアップメッセージ は default でオリジナルの "Distribution" 行と同じになる。しかし、ユーザはこれを 変更することができる。より制限することも可能であり、広範囲な reply が適切だと判 断したならば配布範囲をオリジナルより拡大できる。 2.2.8 Organization この行のテキストは、送信者もしくはマシンが属している組織を記述する短いフレー ズである。この行の目的は、メッセージ投稿者の識別を助けることにある。時として、 ホスト名が暗号のようで、電子アドレスから組織を認識することが困難な場合があるか らである。 2.2.9 Keywords メッセージを識別する、充分に吟味された二、三語のキーワードがこの行に記載され るべきである。これは、読者にこのメッセージは興味あるものかどうかを判断させるた めの補助として用いられる。 2.2.10 Summary この行はメッセージの簡潔な概略を含むべきである。通常、他のメッセージへのフォ ローアップの一部として用いられる。繰り返すが、これは読者がメッセージを読むかど うか判断するのに大変便利である。 2.2.11 Approved この行は moderated なニュースグループに投稿される全てのメッセージで必要とされ る。moderator によって追加され、moderator のメールアドレスによって構成されるべ きである。また、ある種の制御メッセージでも必要とされることがある。 2.2.12 Lines この行にはメッセージのボディの行数が含まれる。 2.2.13 Xref この行は、ドメインを省略されたホスト名、空白、コロンで区切られたニュースグ ループ名とメッセージ番号のペアを含む。これらは "Newsgrups" 行にリストされている ニュースグループと、スプールディレクトリから得られた対応するメッセージ番号であ る。 これはローカルシステムだけの値であるので、転送されるべきではない。例えば、 Path: seismo!lll-crg!lll-lcc!pyramid!decwrl!reid From: reid@decwrl.DEC.COM (Brian Reid) Newsgroups: news.lists,news.groups Subject: USENET READERSHIP SUMMARY REPORT FOR SEP 86 Message-ID: <5658@decwrl.DEC.COM> Date: 1 Oct 86 11:26:15 GMT Organization: DEC Western Research Laboratory Lines: 441 Approved: reid@decwrl.UUCP Xref: seismo news.lists:461 news.groups:6378 "Xref" 行は、ホスト seismo において、このメッセージは news.lists ではメッセージ 番号 461 が与えられ、news.groups ではメッセージ番号 6378 が与えられていることを 示している。この情報は、ある種のユーザインタフェースに用いられる。 3. 制御メッセージ 本セクションでは、現在定義されている制御メッセージをリストする。"Control" ヘッダ行のボディが制御メッセージである。メッセージは何も無いか、数語を空白 (ブ ランクかタブ) で区切って並べたものである。最初の語は制御メッセージの名前であ り、残りはメッセージのパラメータである。ヘッダ行の残部や、メッセージのボディも 潜在的なパラメータである。例えば、"From" 行はレスポンスがメールされるアドレスを 提示している。 実装者と管理者は、制御メッセージが自動的に実行されることを許すか、待ち行列に 入れて年一度の処理を行うかを選択することができる。しかし、手動で処理されるメッ セージは即座に処理されるべきである。 失敗した制御メッセージは生成者に決してメールされるべきではなく、ローカルな "usenet" アカウントにメールされるべきである。 3.1 Cancel cancel ローカルシステム上に与えられた Message-ID のメッセージがある場合、そのメッ セージはキャンセルされる。この機構は、既にネットワーク上に配布されてしまった メッセージをユーザがキャンセルすることを許している。 システムがリクエストされたメッセージをキャンセルできない出来ない場合、キャン セルのリクエストは隣接したシステムに送られるべきではない。 メッセージの著者か、ローカルなニュース管理者だけがこのメッセージを送信するこ とが許されている。通常のメッセージの検証された送信者は、"Sender" 行か、 "Sender" 行が無ければ "From" 行である。キャンセルメッセージの検証された送信者 は、オリジナルメッセージの "Sender" か "From" フィールドのどちらかと同じでなけ ればならない。キャンセルメッセージの検証された送信者は、オリジナルメッセージの 検証されていない "From" と一致することが許されている。 3.2 Ihave/Sendme ihave [] sendme [] このメッセージは ihave/sendme プロトコルの一部であり、あるホスト (Aとする) が 別のホスト (Bとする) に向けて、Aが受信した特定のメッセージを教えることを許すも のである。ホスト A がメッセージ "<1234@ucbvax.Berkeley.edu>" を受信し、そのメッ セージをホスト B に転送したいと仮定する。 その場合、A は制御メッセージ "ihave <1234@ucbvax.Berkeley.edu> A" をホスト B に送信する (ニュースグループ to.B に投稿することによってなされる)。B は、その メッセージをまだ受信していなければ、"sendme <1234@ucbvax.Berkeley.edu> B" とい う制御メッセージを以って応える (ニュースグループ to.A に投稿することによってな される)。sendme メッセージを受け取ると、A は B に所定のメッセージを送信する。 このプロトコルは、ホスト間の冗長なトラフィックを削減するために用いることがで きる。これはオプショナルなもので、特定の状況において、その価値がある場合にだけ 用いられるべきである。これが頻繁になされると、ほとんどのオリジナルメッセージは 短いものであり、また UUCP 経由で新しいメッセージを送信することはオーバヘッドが 大きいので、ihave を送信するコストが所定のメッセージそのものを送信するコストと 同じくらいになってしまうからである。 このオーバヘッド問題の考えられる解決策の 1 つとして、リクエストをまとめること が挙げられる。幾つかの Message-ID が 1 つのメッセージ内でアナウンス、リクエスト される。制御メッセージ内に Message-ID が 1 つも無い場合、そのメッセージのボディ を一行ずつスキャンし、Message-ID を探す。 3.3 Newgroup newgroup [moderated] この制御メッセージは、与えられた名前の新しいニュースグループを作成する。 ニュースグループが作成されるまで (そのニュースグループに属する) メッセージは投 稿も転送もされないので、このメッセージはニュースグループが利用可能になる前に必 要とされる。メッセージのボディには、ニュースグループの用途を記した短い文章が期 待される。 2 番目の引数が存在し、それがキーワード moderated である場合、そのグループは default の unmoderated ではなく、moderated として作成される。同じメッセージの ヘッダ内に "Approved" 行が無い場合、newgroup メッセージは無視される。 3.4 Rmgroup rmgroup この制御メッセージは、与えられた名前の新しいニュースグループを削除する。ネッ トワーク上の全ホストから所定のニュースグループが削除されてしまうので、レスポン シブルな管理者の手によって、慎重に用いられるべきである。rmgroup メッセージは、 同じメッセージヘッダ内に "Approved:" 行が無い場合は無視されるべきである。 3.5 Sendsys sendsys (no arguments) 全隣接ホストと、各ホストに送信されるニュースグループを記述した sys ファイル が、このメッセージの著者にメールされる ("Reply-To" がある場合にはそのアドレス に、無い場合には "From" のアドレスに送られる)。この情報は、パブリックなものと考 えられており、この情報を要求に応じて提供することは USENET 会員の必要条件であ る。提供の方法は、この制御メッセージに自動的に応答するか、メッセージの著者に向 けて、手動で要求項目をメールするかのどちらかである。この情報は、 USENET のマッ プを最新の状態に保つため、またネットニュースが配送されている場所を決定するため に用いられる。 著者にメールで返信されるファイルのフォーマットは、sys ファイルと同じものにす べきである。このフォーマットは、 1 つの隣接ホストにつき、1 行あり (また、ローカ ルホストのために 1 行ある)、コロンで区切られた 4 つのフィールドを含んでいる。第 1 フィールドは隣接ホストのホスト名で、第 2 フィールドは、隣接ホストに送信される ニュースグループを記述したニュースグループパターンである。第 3、第 4 フィールド については、本標準では定義しない。sys ファイルは、UUCP の L.sys ファイルとは異 なるものである。レスポンス例は以下のようになる。 From: cbosgd!mark (Mark Horton) Date: Sun, 27 Mar 83 20:39:37 -0500 Subject: response to your sendsys request To: mark@cbosgd.ATT.COM Responding-System: cbosgd.ATT.COM cbosgd:osg,cb,btl,bell,world,comp,sci,rec,talk,misc,news,soc,to, test ucbvax:world,comp,to.ucbvax:L: cbosg:world,comp,bell,btl,cb,osg,to.cbosg:F:/usr/spool/outnews /cbosg cbosgb:osg,to.cbosgb:F:/usr/spool/outnews/cbosgb sescent:world,comp,bell,btl,cb,to.sescent:F:/usr/spool/outnews /sescent npois:world,comp,bell,btl,ug,to.npois:F:/usr/spool/outnews/npois mhuxi:world,comp,bell,btl,ug,to.mhuxi:F:/usr/spool/outnews/mhuxi 3.6 Version version (no arguments) ローカルシステム上で動作しているソフトウエアの名称とバージョンがメッセージの 著者にメールで返信される ("Reply-To" がある場合にはそのアドレスに、無い場合には "From" のアドレスに送られる)。 3.7 Checkgroups メッセージのボディは、"オフィシャルな" ニュースグループと、そのグループに関す る記述が 1 行に 1 グループずつリストになっているものである。これらは、現在のホ ストのアクティブなニュースグループのリストと比較される。廃止されたニュースグ ループ名、新しく作成されたニュースグループ名がユーザ "usenet" に送信され、新し いニュースグループに関する記述が、ニュース投稿時に用いられるヘルプファイルに追 加される。 4. ニュースの伝達法 USENET は物理的ネットワークではなく、むしろ現存する幾つかの物理ネットワークに 基づく論理的なネットワークである。これらのネットワークは UUCP、 Internet、イー サネット、BLICN ネットワーク、NSC ハイパーチャネル、BERKNET を含むが、それに限 定されるわけではない。重要なことは、USENET 上にある 2 台の隣接しているシステム は、新しいメッセージを得る幾つかの方法を持つこと、ここでリストしたフォーマット にしたがって、あるホストから別のホストへ、受信システム上のネットニュースソフト ウェアによって一度処理されてから送信されることである。(UNIX システムでは、これ は通常標準入力のメッセージと共に動作する rnews プログラムを意味する<1>)。 USENET ホストがインターネットメールの文法を理解するようなメールシステムの能力 を持つことは必須条件ではないが、強く推奨される。"Reply-To"、"From"、 "Sender" 行はインターネットの文法を使用しているので、インターネットメーラが無いと、返信 は困難であるか、不可能である。インターネットメーラを持たないホストは "Path" 行 を返信に用いようと試みるが、このフィールドは返信のための working path である保 証がない。いずれにしても、ニュースメッセージを生成するか、もしくは転送する全て のホストは、インターネットメーラを用いたホストからのメールを受信できるように、 インターネットアドレスを持たなければならない。また、そのインターネットアドレス は "From" 行に含まれなければならない。 4.1 リモートの実行 あるネットワークでは、直接リモートコマンドを実行させることを許している。その ようなネットワークでは、ニュースは標準入力上で rnews とメッセージをスプールする ことによって転送されてもよい。例えば、リモートシステムが remote と呼ばれるとす ると、ニュースは以下のコマンドを用いることによって UUCP リンク上を送信される。 uux - remote!rnews Berknet では、 net -mremote rnews で送信される。 4.2 メールによる配送 あるシステムでは、直接リモートにスプールされているコマンドを実行することはで きない。しかし、ほとんどのシステムでは電子メールがサポートされているので、 ニュースメッセージはメールとして送信することができる。アプローチの 1 つは、 ニュースメッセージと全く同じメールメッセージを送信することである。すなわち、 メールヘッダはニュースヘッダになり、メールのボディはニュースのボディとなる。慣 習により、このメールはリモートマシンのユーザ newsmail に送信される。 この手法の問題点の 1 つとして、メッセージに含まれる "From" 行の正当性をメール システムが確信できないことが挙げられる。メールメッセージはニュースメッセージの ソースとは異なるシステム上で、プログラムによって作成されたものだからである。も う 1 つの問題は、メールの転送によって生じるエラーメッセージがニュースメッセージ の作成者に送られてしまうことである。メッセージ作成者は協力関係にあるホスト間の ニュース転送に関して何の権限も無く、コンタクト先もわからない。転送エラーメッ セージは送信マシンのレスポンシブルなコンタクト先に直接送られるべきである。 この問題の解決策として、全ニュースメッセージ (ヘッダとボディ) をメールメッ セージのボディの一部にするようにして、ニュースメッセージをメールメッセージにカ プセル化することが考えられる。このようなメールは、リモートシステムのユーザ rnews に送られるのが慣わしになっている。メールメッセージのボディをニュースメッ セージの各行の先頭に文字 N を付加することによって生成する。その後メールヘッダを 簡潔に生成し、アタッチする。N はメールの転送を妨げないように、ニュースメッセー ジ内のどのような特殊な行の前にもアタッチされる。これは、メーラによって挿入され る特別な行 (ヘッダ、ブランク行等) がニュースメッセージの一部となってしまうこと を防止するものでもある。受信マシン上のプログラムが rnews に向けたメールを受信す ると、メッセージ自身を展開し、rnews プログラムを発行する。このフォーマットの例 は以下のようになる。 Date: Mon, 3 Jan 83 08:33:47 MST From: news@cbosgd.ATT.COM Subject: network news message To: rnews@npois.ATT.COM NPath: cbosgd!mhuxj!harpo!utah-cs!sask!derek NFrom: derek@sask.UUCP (Derek Andrew) NNewsgroups: misc.test NSubject: necessary test NMessage-ID: <176@sask.UUCP> NDate: Mon, 3 Jan 83 00:59:15 MST N NThis really is a test. If anyone out there more than 6 Nhops away would kindly confirm this note I would Nappreciate it. We suspect that our news postings Nare not getting out into the world. N メールを用いることにより、スプーリング問題は解決する。送信先ホストがダウンし ている場合、メールは常にスプールされるからである。しかし、この手法は転送処理に 更なるオーバヘッドを加え (メッセージのカプセル化、展開)、ソフトウェアにニュース とメールに異なる優先度を与えることを困難にする。 4.3 バッチ処理 ニュースメッセージは通常短いものであり、また大量のメッセージがしばしば 1 日の うちに 2 台のホスト間で送信されるので、ニュースメッセージをまとめることが意味を 持つことがある。幾つかのメッセージは、ニュース交換を行う 2 台のホストがあらかじ め取り決めた協定を用いることによって、1 つの大きなメッセージに結合することがで きる。ここでは、このようなメッセージバッチの仕組について記述する。これを用いる ことは強く推奨される。 ニュースメッセージは、以下のような形式のヘッダによって分割することにより、ス クリプトとして結合することができる。 #! rnews 1234 ここで、1234 はメッセージの長さをバイトで表したものである。このような行にはそれ ぞれ与えられたバイト数のメッセージが続く。(メッセージの各行末にある改行は 1 バ イトと数えられる。このカウントの目的に即するために、たとえの形で保存さ れていたとしても 1 バイトでカウントされる)。例として、メッセージのバッチは以下 のようになる。 #! rnews 239 From: jerry@eagle.ATT.COM (Jerry Schwarz) Path: cbosgd!mhuxj!mhuxt!eagle!jerry Newsgroups: news.announce Subject: Usenet Etiquette -- Please Read Message-ID: <642@eagle.ATT.COM> Date: Fri, 19 Nov 82 16:14:55 EST Approved: mark@cbosgd.ATT.COM Here is an important message about USENET Etiquette. #! rnews 234 From: jerry@eagle.ATT.COM (Jerry Schwarz) Path: cbosgd!mhuxj!mhuxt!eagle!jerry Newsgroups: news.announce Subject: Notes on Etiquette message Message-ID: <643@eagle.ATT.COM> Date: Fri, 19 Nov 82 17:24:12 EST Approved: mark@cbosgd.ATT.COM There was something I forgot to mention in the last message. バッチされたニュースはそれとわかる。なぜなら、メッセージの最初の文字が # だか らである。このメッセージは、翻訳のために、バッチ解除にまわされる。 (この例における rnews の) 2 番目の引数は使用されているバッチ構造を判定する。 協調関係にあるホストは、彼らにとって適切であればどのようなものを用いても構わな い。 5. ニュース伝播アルゴリズム 本セクションでは、USENET 全体の構造と、ロジカルなネットワーク全体へのニュース 伝播処理における、ホストのアルゴリズムを記述する。全てのホストが不正なフォー マットのメッセージや伝播エラーに影響を受けるので、手法を標準化しておくことが重 要である。 USENET は有向グラフである。グラフの各ノードはホストコンピュータであり、弧はあ るホストから別のホストへの伝達経路である。弧にはそれぞれ、ニュースグループパ ターンがラベルされる。これは、そのリンク上でどのニュースグループが転送されてい るかを指定する。ほとんどの弧は双方向である。つまり、ホスト A がホスト B にある 種類のニュースグループを送信しているとすると、ホスト B は通常ホスト A に同じ種 類のニュースグループを送信している。ただし、この双方向性は必須ではない。 USENET は多くのサブネットから構成される。サブネットはそれぞれ、comp、btlと いった名前を持つ。各サブネットは連続したグラフである。すなわち、サブネット内に おいて、あるノードから他の全ノードに対してそれぞれ経路が存在する。更に、グラフ 全体が (論理的に) 接続される。(実際には、幾つかの政治的な理由により、あるホスト はネットワークに到達するメッセージを投稿できない)。 メッセージは 1 台のマシン上でニュースグループをリストして投稿される。そのマシ ンはメッセージをローカルに受理し、その後メッセージが属するニュースグループのう ち、少なくとも 1 つに興味を示す全ての隣接ホストに転送される。 (サイト A から ホ スト B への弧上にラベルされたパターンにニュースグループが一致するとき、A は B がそのニュースグループに "興味を持っている" と見なす)。新規メッセージを受信した ホストは、本当にそのメッセージが欲しているものかを確認し、一度ローカルに受信 し、その後その記事に興味を持つホスト全てに順次転送する。この処理はネットワーク 全体にメッセージが行き渡るまで続けられる。 アルゴリズムの重要な部分は、ループの防止である。上の処理は、あるメッセージを サイクリックに永久にループさせてしまうかもしれない。特に、ホスト A がホスト B にメッセージを送信し、B がそのメッセージを A に送り返し、それがまたホスト B に 送られ・・といった具合である。この解決策の 1 つが履歴のメカニズムである。各ホス トは、今までに見たメッセージの足跡を (Message-ID によって) たどり、既知のメッ セージを受信したら、そのメッセージを破棄する。この解でもループの防止には十分だ が、単に破棄されるだけのメッセージはホストに送信しないような、更なる幾つかの最 適解が開発された。 最適解の 1 つは、ヘッダの "Path" 行にリストされているマシンには、メッセージを 送らないというものである。マシン名が "Path" 行にあるなら、メッセージはそのマシ ンを経て届いているからである。もう 1 つの最適解はメッセージがホスト A で生成さ れたならば、ホスト A はそのメッセージを既に見ている。したがって、そのメッセージ が misc.misc に投稿されたならば、パターン misc.* に一致し、misc.* を購読する全 ホスト (隣接ホストが送信するものによって決定される) に送信するというものであ る。これらのホストは misc サブネットを形成する。btl.general に投稿されたメッ セージは btl.* を受信する全ホストに到達するが、btl.* を受信しないホストには到達 しない。要するに、メッセージは btl サブネットに到達するのである。ニュースグルー プ misc.misc, btl.general に投稿されたメッセージはどちらかの種類のニュースグ ループを購読している全ホストに到達する。 注 <1> UNIX は AT&T の登録商標である。