要約

  • Approvedは記事の掲載を承認した個人や組織を示す。著者を置き換えるものでも、記載されたメールボックスの持ち主が欄を付けたと証明するものでもない。
  • proto-articleの宛先に一つでもmoderated groupがあり、Approvedがなければ、注入エージェントは記事全体を左端のモデレーターへ転送するか拒否する。通常グループだけを先に公開してはならない。
  • 複数のmoderated groupでは承認が順送りされ得る。最後のモデレーターが全承認に責任を負って欄を追加し、注入エージェントは記事の外にある通信認証でそのモデレーターを確かめる。

三つの宛先があっても、先に一つだけ出さない

一つのproto-articleが、通常投稿できる技術グループと二つのmoderated groupをNewsgroupsに並べている。著者が投稿操作をした時点ではApprovedがない。

処理は三つのコピーへ分かれない。通常グループにだけ掲載し、残りを審査待ちにするのではなく、注入エージェントは記事全体を止め、左端にあるmoderated groupのモデレーターへ送る。転送できなければ拒否する。

最初のモデレーターが承認し、必要なら次のモデレーターへ渡す。すべての承認がそろうと、最後の担当者がApprovedを加え、記事を注入経路へ戻す。その後初めて、同じ記事が三つの宛先へ入る。

部分公開を避けるこの順序は、著者が文章を作る行為、モデレーターが掲載を許す行為、注入エージェントがネットワークへ受け入れる行為を分離していた。

初期仕様から著者とモデレーターは別欄だった

RFC 1036は、moderated newsgroupへ掲載するメッセージにApprovedを必須とし、モデレーターが自身のメールアドレスを入れるものとした。特定の制御メッセージにも同じ欄が必要だった。

それでも記事のFromは著者を示し続ける。モデレーターのアドレスは、文章の出所を書き換えるためではなく、別の判断である掲載許可を帰属させるために加わった。

本人が書いた記事であっても、moderated groupへ直接掲載する権限が当然に生じるわけではない。反対に、モデレーターが承認しても、その人が本文の作者になるわけではない。二つの責任は一つの送信者へ畳み込まれなかった。

mは通常の処理経路であって個人の権利ではない

RFC 3977のNNTP LIST ACTIVEは、サーバー上のグループ状態を返す。yは投稿可、nは投稿不可、mは投稿がモデレーターへ転送されることを通常意味する。

ただし、その状態は現在のクライアント向けに個別化されているとは限らない。投稿を禁じられた利用者がyによって権利を得るわけではなく、特別な権限を持つクライアントがnのグループで別の処理を受ける場合もある。

従ってmは、編集権限を経由する通常ルートの表示である。誰がモデレーターか、どう認証するか、今回の記事が通るかを決める資格証ではない。

Approvedが運んだのは承認者のリストだった

RFC 5536はApprovedをmailbox-listとして定義する。アドレスと、場合によっては氏名が、掲載を承認した個人または主体を表す。主な用途はmoderated articleとgroup control messageである。

複数のメールボックスを記録できるため、複数のmoderated groupにまたがるcrosspostにも使える。しかし文法が答えるのは「記事が誰の承認を主張しているか」までだ。

メールボックスが実在するか、所有者が記事を審査したか、そのアドレスが現在もモデレーターか、受信サイトが権限を認めるかは証明しない。正しい形式のリストは構造化された帰属表示であり、暗号的な証明ではない。

モデレーターへ送る時点ではまだ注入されていない

RFC 5537はモデレーションを注入手順の中に置く。受管グループが一つでもあり、proto-articleにApprovedがなければ、注入エージェントは転送または拒否しなければならない。必要なMessage-IDとDateは先に加えるが、Injection-InfoやInjection-Dateなど通常の注入痕跡を付ける前に引き渡す。

これにより、記事は審査中の同一性を保てる一方、既にニュースへ注入されたようには見えない。application/news-transmissionとしてメールに封入する方法、newsのヘッダーを残したメールとして送る方法、注入せずにproto-articleを保存するデータベースへ置く方法などが認められる。

最初の宛先をNewsgroups中の左端のmoderated groupと定めるのは、複数承認の開始点を決定するためである。左端の担当者に全グループを代表する権限を与える規則ではない。

最後に欄を加える者が全承認を引き受ける

未承認のmoderated groupが残る場合、モデレーター同士で合意してもよいし、中間の承認を示して次の担当者へ送ってもよい。記事は公開コピーへ分裂せず、一つの審査対象として進む。

すべての必要な承認がそろった時、最後のモデレーターがApprovedを追加し、自身と、可能な範囲で他の承認者を示す。RFC 5537は、その人物が記事の全moderated groupについて承認済みであることを保証する責任を負うとする。

つまり欄はワークフローの結論だが、ワークフローそのものではない。採否基準、調整方法、変更内容、最後の担当者が確認した証拠までは見えない。モデレーターはヘッダーや本文を変更できるが、投稿者や前のモデレーターの署名を壊し得るため、変更を最小限にすることが推奨される。

正しい文法の偽造は簡単だった

RFC 5537のセキュリティ節は、悪意ある投稿者がApprovedを自分で加えてモデレーションを迂回できると警告する。mailbox-listの文法には、それを防ぐ力がない。

そこで注入エージェントは、承認済み記事が本当にモデレーターによって注入されているか確認すべきだとされる。証拠は基盤となる通信の認証情報、またはモデレーターと別途取り決めた仕組みから得る。当時、moderated groupの承認を認証する標準方式は存在しないとも明記された。

システムは二層になっている。記事は「誰が承認したと主張されているか」を持ち運ぶ。注入境界は「認可されたモデレーター経路から本当に戻ったか」をローカルに検証する。前者だけなら帰属を偽造でき、後者だけなら下流へ承認者を伝えられない。

IANAが登録したのは欄であって信頼名簿ではない

IANA Message Headers RegistryはApprovedをRFC 5536に基づく標準Netnewsフィールドとして登録する。実装は名称、対象プロトコル、規範的参照を共有できる。

レジストリはモデレーターを任命せず、現在の名簿を公開せず、メールボックスの所有権を検証せず、特定の承認者を全サーバーに信頼させない。公式資料から現在のUsenet事業者の実装状況を推定することもできない。

編集権限は移動できても著者性にはならなかった

Approvedが解いたのは、分散した中継網へ「審査済み」という事実とその帰属を運びながら、著者を上書きしないという問題だった。メールボックスのリストは、その主張を運ぶには十分だった。

主張を守るには十分ではない。安全性は、注入エージェントがモデレーターを知り、記事が認証された経路で戻ることに依存した。欄が門を開けたように見えても、門が信じる相手はローカルな境界で先に決まっていた。

承認は著者性ではなく、読める識別子は認証済み識別子でもない。著者が書き、モデレーターが掲載先を許可し、注入エージェントがその権限を信じるに足るか判断する。この三つを分けたことが、Approvedの歴史的な意味である。