要約

  • LIST ACTIVE の y/n/m は、サーバーがそのグループへの投稿を通常どう扱うかを示し、利用者別の認可結果ではなかった。
  • y でも現在のクライアントは拒否され得る一方、特別な権限を持つクライアントは n のグループへ投稿できる場合がある。
  • 一覧、認証、資源別認可、記事受理、読者への公開は、それぞれ別の証拠として観測する必要がある。

緑から始まる失敗

古いニュースリーダーを想像してみる。サーバーから取得した一覧には、あるグループが y と表示されている。ソフトウェアは投稿画面を開き、利用者は原稿を完成させる。しかし POST に返ったのは 440 で、本文の送信すら始まらない。

一覧が嘘をついたわけではない。ソフトウェアが答えの主語を取り違えたのである。「このグループでは通常、投稿を受け付ける」という説明を、「この接続のあなたには投稿権限がある」という判定に変えてしまった。

逆向きのずれも仕様に含まれる。RFC 3977 は、状態が n のグループでも、仕様外で与えられた特別な権限を持つクライアントなら投稿できる可能性を述べる。基準方針と例外認可を同じ一文字に詰め込まなかったからこそ、このケースを表現できた。

最初のLISTにも限定条件があった

1986年の RFC 977 は、LIST の各行をグループ名、最大記事番号、最小記事番号、そして y または n の投稿フラグで構成した。短い形式は多数のグループを低コストで案内するために適していた。

同じ節はすぐに注意を置いた。一覧で投稿可能とされても、特定クライアントの投稿が禁止されることはある。フラグは、通常グループ、moderated group、digest group といったグループ側の扱いを表すために存在し、サーバーがクライアントへ与える投稿権限とは独立していた。

個別判断は POST に残された。サーバーが本文を受け取る準備をした場合は 340、配置依存の理由で禁止する場合は 440 を返す。接続時の応答も、そのクライアントが投稿可能かどうかを示した。つまり初期NNTPから、カタログ方針と接続権限は別々の観測点だった。

ACTIVEの一行が実際に証明すること

RFC 3977では、この一覧は LIST ACTIVE と整理された。フィルターがなければ、現在のクライアントが GROUP で選択できるグループをサーバーが列挙する。この時点で、それは世界共通のUsenet台帳ではなく、特定サーバーが接続へ見せる局所的な表である。

各行にはグループ名、高低のウォーターマーク、サーバー上の現在状態が入る。標準的な値は y（投稿を許す）、n（許さない）、m（モデレーターへ転送）である。未知の値を見たクライアントは「情報なし」と扱うべきで、都合のよい意味を推測してはならない。

そして仕様は、状態が投稿の「通常の処理」を示すだけで、必ずしも特定クライアント向けに調整されていないと明記する。y は全員への権利付与ではなく、n はあらゆる例外の否定でもない。

ここでの normally は曖昧さではなくスコープ指定である。一つの簡潔な表がグループの性質を案内しつつ、アカウント、接続元、保護状態、運用例外の判断を独立した仕組みに委ねる。

投稿の成否は段階ごとに残る

RFC 3977の POST は、本文の前に 340 または 440 を返す。本文を受け取った後には 240 または 441 が返る。前段の拒否と後段の失敗は同じではない。前者なら原稿はまだリンクを渡っておらず、後者ならサーバーが内容を受信した後で受理しなかった。

さらに 240 も、読者が直ちに記事を取得できる保証ではない。モデレーション、追加処理、別サーバーへの転送が残り得る。グループ状態、提出資格、受理、可視性は四つの別の問いである。

この分離は監査だけでなく秘匿性にも効く。UIが y だけを根拠に機密の原稿を先送りし、本文送信後に権限不足が分かれば、誤ったスコープ解釈は取り消せない情報開示になる。

AUTHINFO後も万能券は生まれない

RFC 4643 の 480 は、コマンドまたは資源を利用する前に認証および／または認可が必要だと伝える。AUTHINFOが成功すれば、接続が表す主体が変わり、広告される能力も変化し得る。

しかし認証成功後にも、サーバーは一部または全部の資源を 502 で拒否できる。認証は主体を確立し、サイト方針がその主体の行為を決める。したがって、LIST ACTIVE、AUTHINFOの結果、実際のコマンド応答は互いの代用品にならない。

グループ名と y/n/m だけで認可をキャッシュする実装は、TLS状態、利用者、接続先、方針変更を取り逃がす。セキュリティやIDの遷移後には能力を再取得し、現在の命令に現在の判断を求める必要がある。

m は経路を示し、権威を証明しない

m は投稿がモデレーターへ転送される通常経路を示すが、モデレーターの本人性も承認結果も保証しない。RFC 5537 は posting、injecting、relaying、serving、reading の各agentとmoderatorを分け、記事の段階ごとに責任主体が異なることを示した。

Sofia Renの既刊記事は Approved とモデレーター権威を扱っている。本稿はそこを繰り返さない。m はあくまで、活動一覧が通常処理の説明であることを補強する証拠だ。投稿できることは著者性の証明でも、流通や可視性の保証でもない。

別々の能力名が残した設計

IANAのNNTP Parameters は LIST、POST、AUTHINFO、READER を別々の能力として登録する。登録自体は現在の実装状況を測定しないが、発見、提出、ID、閲覧を独立して合意する語彙を与える。

一覧は大量の対象を効率よく説明するから価値がある。危険になるのは、その説明を利用者別の許可へ昇格させたときだ。NNTPの緑は本物だった。ただし、あなた個人に点灯した緑ではなかった。

出典