要約

  • Netnews の各代理は自分の path identity を左端へ追加したため、最新の処理者ほど左に並ぶ逆向きの履歴ができた。
  • 送信側は、受信予定の隣接代理がすでに Path にあれば転送を省けた。Message-ID を使う履歴データベースは、別経路から来た重複を拒む独立した防線だった。
  • !! は隣接身份の検証、単独の ! は検証主張なしを示す。MISMATCH や SEEN は観測の限界を残し、末尾の not-for-mail は中継代理ではなかった。

返ってきた記事を捨てるだけでは遅い

A、B、C のニュースサーバーが互いに記事を流す場面を考える。A から受け取った記事を B が再び A に送れば、A は Message-ID を履歴と照合して捨てる。無限ループは成立しない。それでも A と B の間では、結果が決まっていた記事をもう一度運んでしまう。

このため Netnews は二種類の記憶を必要とした。サーバー内の履歴は「この論理的な記事をすでに見たか」を判断する。記事内の Path は「この転送候補はすでに旅程に含まれるか」を判断する。前者は洪水型配送を収束させ、後者は収束するまでの無駄を減らす。

RFC 1036 は、Message-ID による履歴だけでループを止められると説明したうえで、Path を追加の最適化として置く。A の名が記事にあれば、B は A へ直ちに返さない。既存の Message-ID 記事が扱ったのは記事の同一性と重複抑止であり、ここで扱うのはその一段前の転送判断である。

新しい一歩ほど左に来た

B が A!X!Y!Z を受け取ると、先頭に自分を加えて B!A!X!Y!Z にする。読む向きでは左が現在、右が過去になる。中継でフィールドが変わっても、記事の Message-ID を変える必要はない。Path は固定された本文ではなく、処理者が更新してよい追跡情報だった。

1983 年の RFC 850 には、すでにこの左側追加方式がある。当時の形式はさまざまな区切りを許し、UUCP の bang path と似ていた。しかし仕様は、Path を返信に使わず、メールアドレスと見なしてはならないと明記した。

見た目が経路でも、ニュースの経路とメールの経路は一致しない。隣接ニュースサーバー同士だけが知る短い名前を、メール配送系が理解する保証もない。古い実装で返信できた例があっても、それはフィールドの権限ではなかった。

RFC 1849 は、初期 1990 年代に事実上の実装資料として広まった草案を、2010 年に歴史資料として残したものだ。現行実装の規範として使う文書ではないが、実務の収束点をよく示す。中継名を ! で並べ、末尾にローカル部を置き、各中継は自分の名を追加して、すでに名のある隣接先へ送らない。

同文書は帯域の問題を率直に述べる。返送された記事は相手の履歴で拒否されるとしても、名前の不整合があれば全記事がリンクを一往復余計に通る。集合としての正しさと、運用コストの正しさは同じではない。

一番右は「最後に通ったサーバー」ではない

古い Path の右端には、投稿者に由来するローカル部が置かれることがあった。それは path list の一員ではない。単に ! で分割し、すべてを「通過サーバー」として扱えば、同名の正当な中継先を誤って除外できてしまう。

RFC 5536 は path-list と tail-entry を文法上分離した。末尾には not-for-mail を置ける。この語は障害でもホスト名でもなく、古い返信アドレスの名残をメール配送に使わないことを明示する境界標識である。

したがって、文字列より位置が重要になる。path list 内の identity は転送除外に使える。POSTED の後ろにある投稿元情報や tail は、同じ見た目でもその資格を持たない。

NNTP の接続列ではなかった

RFC 977 は 1986 年、TCP などの信頼できるストリーム上でニュースを配送、検索、投稿する NNTP を定めた。RFC 3977 は 2006 年にその契約を更新した。これらは相手との会話を定めるが、記事の Path を TCP セッション履歴にはしない。

RFC 5537 の Netnews アーキテクチャは、基礎となる転送プロトコルから独立している。記事は複数セッションをまたぎ、一台の内部にある注入、転送、提供の各コンポーネントを通り、ゲートウェイで別媒体へ移ることもある。

Path が記すのはアプリケーション層のニュース代理であり、IP パケットが通ったルーターではない。次の配送先も文字列が決めるのではない。運用者が持つ feed 関係、Newsgroups、Distribution、受入方針が先にあり、Path は「この相手はすでに現れる」という一つの否定材料を与える。

記号は確信の差を保存した

2009 年の仕様では、処理するニュースコンポーネントが path identity を前置する。完全修飾ドメイン名が望ましいが、関係する相手の範囲で一意性を保証できる別名も使える。中央の命名機関より、隣接運用者が同じ名と alias を認識することが実用上の条件になる。

連続した !! は、左側の代理が右隣の identity を自ら満足できる方法で検証したことを示す。単独の ! は、その主張をしない。正規化の過程で両者を同じにすれば、存在しない検証を作り出す。

POSTED は注入地点を示す。MISMATCH は、接続から期待した送信元 identity と記事の左端が一致しないことを残す。SEEN は送信元を観測したものの、主張された identity として検証できない、または検証しない場合に使う。期待値は peer の認証 identity や接続元 IP から得られる。

これらは隣接する一観測者の記録だ。MISMATCH は詐称だけでなく、alias の更新漏れ、移行、proxy、大小文字の差でも起こる。!! が連なってもエンドツーエンド署名にはならない。各印は一つ右隣への局所的な判断で、記事全体を暗号学的に固定しない。

RFC 5537 が Path と Injection-Info の偽造を避けるため、信頼する代理からのみ受け入れるよう勧めるのもこのためだ。信頼はフィールドの外にある接続関係から供給される。

Path にいないことは通行証ではない

転送候補の identity、または既知 alias が有効な path list にあれば、その相手へは送らない。tail や POSTED の送信元部分は判定から除く。だが、名がない相手へ必ず送るという規則ではない。

グループと Distribution の合致、記事の妥当性、容量、peer 信頼、ローカル方針が別々に残る。Message-ID 履歴も、別方向から来る複製や Path 最適化を無視する相手のために必要だ。別媒体とのゲートウェイは trace を失って再注入しうるので、さらに独自のループ対策を要する。

Path は、小さな権限のまま役に立った。実行中の中継網が、明らかな送り返しを一つ省くために必要な履歴だけを記事へ加えた。投稿者本人、保存、読者への到達、世界的な経路まで証明しようとはしなかった。

RFC が確定するのは、この仕様上の役割と限界である。現在のサービスがどの診断を使うか、特定の identity が正しいか、記事が保存または閲覧されたかは、接続、転送、履歴、保存の実データなしには分からない。