NetNewsの仕組み (技術的なきまり編)

ほり としお(toshi@etl.go.jp)
さいとう のぼる(j0315@cocoa.ocn.ne.jp)

NetNewsには、いろいろな国、いろいろな環境のユーザが投稿しています。 もし、このユーザたちが自分たちの自由気ままに、でたらめな方法で記事を送ったら、送った人が意図しない、意図不明な文字ばかりになったりとか、きちんと届かないとかだけでなく、最悪の場合は相手のシステムに何らかの障害を与えるかもしれません。 (そういうのは、そもそもはその程度で停止するようなシステム設計やセキュリティ上の欠陥かもしれませんが、だからといって相手に迷惑を与えるのは好ましくないでしょう。)

そのため、NetNewsの記事は、公開されているさまざまな技術的なきまりに従ったかたちになっていなければなりません。 ここでは、技術的なきまりについてざっと説明してみます。


インターネットにおける技術的な標準や、データフォーマットなどを定めているRFC(Request For Comment)[1]では、NetNewsに関するものもRFC1036としてまとめてあります。 この原文は英語ですが、日本語訳をおいているサイトが存在するので検索エンジンなどで調べてみるとよいでしょう。 この文章では下記に述べるデータフォーマットやメッセージID、用語などを定義しています。 記事の投稿や返信などのときに、「レス」などの俗語ではなく、この文書で定義されている言葉を使うと誤解のないやりとりができます。 ちなみにNetNews 上の記事に対して NetNews 上で返信することを「フォローアップ(Followup)」といい、電子メールで返信することを「リプライ(Reply)」 といいます。

このRFC1036の改訂版としていくつかの草案(Draft)が出されていますが、合意のとれないまま現在まで来ています。 なお、RFC1036自体はそれ以前のRFC850をObsolete、つまり廃止して置きかえたものとなっています。 そのため、現在は(それなりに問題を含んでいても)この1987年に決められたルールに従うこととなっています。 この方法が気にくわない、という方は、RFC1036をObsoleteする新たなRFCを提案するか[2]、NetNewsににているけど、それとは違う別のものを、別のものとして新たなRFCで提案するか[3]、気にくわないなりに従うか、使うのをやめるかすることができます。 こういう場合に「私はこういうのに従いたくないからルールを破る」という対応はよろしくないでしょう。


とはいえ、実装としてはRFC1036の中で指定されているRFC822(STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES、電子メールのフォーマットを規定するRFC)だけではなく、最近はRFC2046などで規定されているMIME(Multipurpose Internet Mail Extensions)[4]が当然使えるものとしている例も多く見受けられます。 なお、MIMEという仕組みについて、詳しくは最後の方にちょっと解説を書いていますので興味がある方はご覧ください。

たとえば、Subject: などのヘッダに、漢字などのus-ascii以外の文字を使っても相手に伝わるというのは、ニュースリーダ側で伝送経路上ではus-asciiの文字列になるように変換(MIMEエンコード) し、受け側のニュースリーダで複号(デコード)して日本語として表示しているためです。

といっても、相手がMIMEに対応していないニュースリーダなりサーバなりを利用している場合はその部分は読めないわけです。 そのため、当然対応しているだろうということを前提にした、MIMEに多く依存した記事では、思った以上に多くの人が読めなかったり、記事の意図をとれなくなってしまうかもしれません。


また、NetNewsの伝送に使われるNNTP(NetNews Transfer Protocol)はRFC977、news:形式を定義しているURI(Universal Resource Identifiers)はRFC1630にて規定されています。

もし必要であれば、これらを読んでみるとより深い理解を得られると思います。


さて、RFC1036では、いくつかの必須なヘッダについて定義してあります。 いわゆる、"From"、"Date"、"Newsgroups"、"Subject"、"Message-ID"、そして"Path" です。 ここではこれらについてざっと述べます。


"From"は投稿者の電子メールアドレスを書く部分です。 最近はspamをうけたくない、という理由でこの部分に無効なメールアドレスを入力してしまう人もいるようです。 (残念なことに、複数のコンピュータ雑誌でもその損得の「得」の方しか書かずに、無効なメールアドレスを書くことを勧めていたりするのも見かけます。) それについては"Invalidなメールアドレス"として別の文章でまとめていますので、あわせてご覧ください。


"Date"は、現在では"Wdy, DD Mon YYYY HH:MM:SS TIMEZONE"というかたちがほとんどとなっています。 (RFC1036では"Wdy, DD Mon YY HH:MM:SS TIMEZONE"と、年が 2 桁表記として書かれていますが、そのままでは2000年問題を引き起こす実装です。) 注意すべきなのは、(多くはクライアント側、つまりあなたのコンピュータで"Date"を付与する場合) TIMEZONE、つまりGMT(グリニッジ標準時)からの時差(日本では+9時間)が正しく設定されていないことがあることです。 もしこの部分が正しく設定されてないと、あなたの記事は他の人から見ると「未来から」届いたように見えるかもしれません。 この場合は、たとえばWindows95以降を使用されている場合は"時刻のプロパティ"を確認すればいいでしょう。 同じくUnixを使用されている方は、シェルでDateを確認し、もしおかしいようであればシステムの管理者に問い合わせましょう。


"Newsgroups"には投稿するニュースグループを指定します。 ニュースグループは、興味のある話題を簡単に選べるように、細かく分類わけされています。 しかし、記事によっては複数のニュースグループに関する話題が含まれているかもしれません。 そういう場合、クロスポスト(crosspost)という方法を使うと、たとえば同じ内容の記事を複数のニュースグループへ別々に投稿するいわゆるマルチポストと違い、投稿する手間も一度ですみますし、実際のデータ量も分けて投稿した場合と違って少しの増加ですみます。 クロスポストの方法は、"Newsgroups: fj.foo,fj.bar"のように、各ニュースグループ名の間を開けずに複数併記することでできます。 お使いのニュースリーダによっては、ニュースグループを指定するメニューで複数並べることによってできるものもあります。 たとえばNetscape Messengerでは"Groups:"というメニューで複数指定しても同じことになります。


"Subject"(日本語では「題名」とか「表題」とか訳されているかもしれません)には、RFC1036という主に技術的なものを定めたRFCですらわざわざそういっているように、「サブジェクトだけで読者に読むかどうかを決めさせる程度に、十分に本文の内容を暗示するものであるべき」です。 たとえば「教えてください」とかだと、何かを教えてほしいらしい、ということは確かに伝わりますが、「何を」教えてほしいのかは本文を読まないと伝わりません。

たとえば、「教えてください」というのと、「[Q] 水曜どうでしょうの放送エリア」とを比べると、(水曜どうでしょうが何なのかはともかく)後者だと水曜どうでしょうの放送エリアに関するということが、サブジェクトだけで伝わるでしょう。 もしあなたが水曜どうでしょうを知らないとか興味がない場合は読み飛ばせばいいわけですし、興味があれば読んでみるといい、というわけです。 前者の場合だと本文を読まないと何が何だかわからないでしょうし、たとえばあとでフォローしようとしたときに、「教えてください」からその記事を探すのは後者よりも面倒なことになるかもしれません。 もし相手が何か情報を持っていても、面倒になってフォローするのをやめたら答えは得られなくなる、というわけです。

また、ときどきWebの掲示板などで見かけられるように、サブジェクトと本文をあわせて読まないと意図のとれない記事を書くような例が見かけられます。 具体的には、サブジェクトに「○×のことを」と書いてあり、本文に「分かる人教えて」というような使い方です。 このような使い方はネットニュースでは好ましくありません。 なぜなら、普通の記事にはサブジェクトと本文の間にいろいろなヘッダがはさまることが多いので、相手にとって意味をとりにくいものになる場合があるからです。 一部のニュースリーダではヘッダの一部や多くを表示しなかったり、サブジェクトを強調表示したりするものがあるので、その環境では偶然見やすいのかもしれません。 しかし、ネットニュースを使う人すべてがそういう環境を使用しているわけではない、というのを理解して使いましょう。 なお、上記の例ではMIMEエンコードに対応していないニュースリーダだと、そもそも本文だけでは文章を成さないので、答えてもらえる可能性も減るかもしれません。


メッセージIDは<unique@full_domain_name>という形で表されます。 ここで、uniqueの部分には重複しないようにつけられることが(たとえば投稿に使ったサーバで)期待される[5]文字列、full_domain_nameの部分には投稿した環境のドメインを含む文字列が入ります。 たとえば、<9cvfai$n5l$1@nn-tk105.ocn.ad.jp>は、サーバで付帯した文字列「9cvfai$n5l$1」と、サーバの「ocn.ad.jp」を含む文字列からなっています。 これは、ニュースサーバと同程度の一意性を保証さえできれば、クライアント側でつけてもかまいません。 また、始めと終わりの<>は、メッセージIDとしてあげる際には省いてはいけません。 面倒なことに、URI表示としてnews:形式を使う、つまりRFC1630での指定を行う場合は逆に<>を取り除くこととなっています。

ですので、

  Message-ID: <9cvfai$n5l$1@nn-tk105.ocn.ad.jp>
  news:9cvfai$n5l$1@nn-tk105.ocn.ad.jp

という場合は正しいのですけど、

  Message-ID は 9cvfai$n5l$1@nn-tk105.ocn.ad.jp です
  news:<9cvfai$n5l$1@nn-tk105.ocn.ad.jp> をご覧ください

と説明したりとか、

  news:9cvfai$n5l$1@nn-tk105.ocn.ad.jp...
というのを生成するのは(最後の例は、とあるニュースリーダがそう実装してしまっていますが)間違いになってしまいます。 気をつけましょう。

ところで、メッセージIDは他の用途に使われることもあります。 もしあなたがある情報について質問したとき「その解答は<hoge@foo.bar.baz>という記事をごらんください」といわれるかもしれません。 そのときはそのメッセージIDが指し示す記事を自分のサーバなり、ネットニュースアーカイブサイトなりで調べるとよいでしょう。 これはたとえば、「確かあのグループに、ピエールという名前で昨日の10時頃投稿した記事」とか、「このグループの○×△番目の記事」と表す場合と違い、間違いなくその記事を指定できる便利な方法です。


"Path"は、記事が配送された経路を表しているものです。 こちらについては、「NetNewsの仕組み (配送編)」にまとめてありますので、よろしければこちらをご覧ください。


また、オプショナルな(必ずしもなくてよい)ヘッダとして、 "Followup-To"、"Expires"、"Reply-To"、"Sender"、"References"、"Control"、"Distribution"、"Keywords"、"Summary"、"Approved"、"Lines"、"Xref"、そして "Organization"があります。 このうち、いくつかよく使われるものや時々話題になるものを説明します。


"Followup-To"は、たとえばクロスポストをしていた記事が、フォローアップがつくうちに内容的に他のニュースグループへ移った方がそろそろよさそう、と判断したときに、その以降の記事がふさわしいと思われるニュースグループを指定するものです。 たとえば、"fj.rec.spas,fj.life.hometown.hokkaido"というクロスポストをしていた記事で内容が「温泉について」に限られてきたときには、"Followup-To: fj.rec.spas"と指定します。 注意すべきなのは、まずその記事の内容がもともと限られているときはクロスポストをすべきではなく、はじめからふさわしいニュースグループのみへ投稿した方がよいこと、一部のニュースリーダ(アウトルックエクスプレスなど)はこの行を初期状態では表示しない設定になっていること(フルヘッダー表示を行う必要があるようです)、そして相手がその指定に従う必要は必ずしもないことです。

なお、Followup-Toをするときは、本文中にもその旨書いておくと親切に思われるかもしれません。 しかし、Followup-Toをするときは必ずしもそうしなければならない、というものでもありません。なぜなら投稿先を選択し、確認するのは投稿者の責任だからです。 ときおりFollowup-To:を表示していないニュースリーダと相まって、「投稿先をこそっとかえるようにしておくのは不親切だ」とか、「他のニュースグループを指定されているのがわからなかったから多重投稿してしまった、そのことを本文中に書いていないお前のせいだ」とかいう主張をする人もいますけど、残念ながらそれは同意を得られないでしょう。


"Expires"は記事の中で明示的に指定することもありますし、ニュースサーバの方で自動的にする場合もあります。

記事をすべて保存していると、そのうちHDDなどの記憶容量があふれてしまうかもしれません。 そのためNetNewsの記事は、ほとんどの場合でサーバごとに決められたある一定期間を過ぎた記事は自動的に削除されます。 これをエクスパイア(expire)といいます。 これは環境依存の話で、あなたのサーバではもうエクスパイアされて見えなくなった記事でも、他の人のサーバではまだ残っている、ということもよくあります。 また、ヘッダで「Expires: 15 Jun 2001 04:00:00 +0900」のように指定することによって、それに従うサーバなら、その日付にエクスパイアさせることができます。 もしエクスパイアされた記事をまた読みたい場合は、エクスパイアに従わずに記事をとっておく設定になっているニュースサーバなり、ネットニュースアーカイブサイトなりを使用することにより記事を確認することができます。

いくつかの例外をのぞき、たいていのニュースグループでは、大きなデータを投稿することは嫌われる原因となります。これは、その大きなデータが普通の記事と一緒に全世界へ流れ、そして全世界で(一定期間、あるいは半永久的に)保存されるためです。 もしその負荷が大きければ、普段のデータ量では問題のないニュースサーバや経路に、予期しない記憶容量の不足や停止などの問題を起こすかもしれません。 あなたがたとえば画像などの大きなデータを流したいと思ったときは、本当にそれが必要か、具体的にはどこかのWebサイトにそのデータを置いて、記事の中でURIを示すなどで十分ではないかを考えてみた方がよいでしょう。 特に、現在fjにおいては画像などのバイナリデータを配送するためのニュースグループは存在しません。 (他の、たとえばjapanなどには存在します。)


"Reply-To"には、リプライをしてほしいときに、"From"に書かれたメールアドレスではないところへ返信してほしい場合に書きます。 たとえば、職場のメールアドレスで投稿したけど、返事は自分の家でつかっているメールアドレスにほしい、といった場合です。


"References"は、たとえばあなたが誰かの記事に返信したときに、誰のどの記事についてなのかを示すために、そのフォローした記事のメッセージIDを示すものです。 多くのニュースリーダではフォローの際に対象記事のメッセージIDを自動的に入れてくれますが、もしつかっている環境の都合などの何らかの理由によって自動入力できない場合でも、引用もとをはっきりさせるために、文字列をコピーするなどしてその対象記事のメッセージIDを書いておいた方がよいでしょう。


"Control"は、記事の削除やニュースグループ自体の改廃の情報を、ある特定の様式(フォーマット)に従った記事として流すためのものです。 なお、その記事をコントロールメッセージといいます。

とはいえ、もし自分でニュースサーバを管理していない限り、扱うのは自分の記事の削除(キャンセル)を行う場合だけかもしれません。 この記事によって、たとえばもう使われていないグループを削除したり、自分の記事の訂正を出す時に以前の記事を削除したりすることができます。

コントロールメッセージは本来誰でも流すことができますが、むやみな他人の記事のキャンセルや、合意のとれていないグループの乱立を防ぐため、多くのトップカテゴリ(net、comp、talk など)では合意のとれた決まりがあります。 fjではNGMPに従い、fjニュースグループ管理委員会がニュースグループの改廃についてのコントロールメッセージを取り扱っています。 これは、fj内固有のルールです。 fjニュースグループ管理委員会では、自らの文責による記事以外に関しては、いかなる権限もおいません。そのため、たとえば誰かの記事を代理で削除してもらうなどのことを行う義務や権限はないことをお知りおきください。


"Xref"は、その記事が「あなたの使用しているサーバ」の、記事を保存している領域のいくつ目にあたるかを示しているものです。 注意すべきなのは、それはあくまでも「あなたの」使用しているサーバで、であり、他の人の使用している他のサーバでは、また別の番号が割り振られている場合がほとんどだということです。 たとえば、昔のパソコン通信やWebの掲示板のような、同じサーバを参加者全員が使用しているような場合においては番号での指定でも通じますが、世界中にサーバがちらばっているネットニュースの場合はそうはいきません。 もしあなたがある記事について指し示したいときは、Xrefの番号ではなく、メッセージIDで指定しましょう。


配送の仕組み、慣習的なきまりについては、また別の章で。

[1] http://www.rfc-editor.org/ などを参照のこと。

[2] RFC1036をおきかえるのを目ざす、draft-ietf-usefor-article-07.txtが'02 5月に出ています。

[3] RFC1036自体も、RFC822にいくつかの(しかし重要な固有の)機能を加えたかたちとなっています。

[4] MIMEは、それ自体ではUS-ASCIIという、主にアルファベットと記号で表される文字セットを伝送することを意図していた(RFC822に従う)電子メールの書式に対し、

ために、書式を追加して、RFC822のみの環境でも問題なく伝送しつつ、対応している環境ではそれらのサービスをうけられるように定義しているものです。 詳しくはRFC2045〜2049や用語辞典などをお読みください。

[5] RFC1036では、「メッセージIDはメッセージに固有の識別子を与える。 メッセージIDは、同じメッセージIDを持つ以前の記事が残っている間は再利用されるべきではない。 (すべてのメッセージIDは少なくとも2年は再利用されないことが推奨される。)」 とあります。 しかし、記事の寿命は多くの場合環境依存であり、あなたのサーバでエクスパイアされたあなたの記事でも、他のサーバには残っていることも考えられます。 このことから、uniqueの部分は2年といわず、原則的には可能な限り重複しないようにすべきでしょう。 なお、(まだ正式にRFCとしては合意されていないものの)draft-ietf-usefor-article-07.txtでは「RFC2822の記載に従い、エージェントの生成する記事のメッセージIDはそれが固有であること、そして(ネットニュースにおいても電子メールにおいても)決して再利用されないということを保証しなければならない」と記載されています。


fjの歩き方メーリングリストトップに戻る