要約

  • RFC 733以来、識別子を作るホストが一意性を保証した。改訂には新しいIDが要る一方、配送経路が追跡フィールドを追加しても元の同一性は保てる。
  • In-Reply-To と References はIDを会話グラフの辺にした。Netnewsでは各サーバーが既見IDを記憶し、再来した記事を捨てることで分散配送のループを止めた。
  • 名前は署名でも本文ハッシュでもない。Netnewsは本文が異なっても同じIDを同一記事として扱うため、予測可能なIDは先取りされ、正規の記事を局所的に排除しうる。

バイトは変わっても、メッセージは変わらない

メールが転送に入ると、次の中継は上部に Received を加える。保存されたバイトは投入時と一致しない。しかし中継が新しい主張を作ったわけではなく、元の Message-ID は残る。

反対に、作者が伝える命題を改め、新しい版として送り出せば、大半の文が同じでもIDは替わるべきである。1977年の RFC 733 は、識別子が特定メッセージの一つの版・実体だけを指し、後の改訂には新しい識別子を与えると定めた。一意性を保証するのは生成ホストだった。

RFC 822 も1982年にこの責任を引き継いだ。値は機械可読で、人間に意味がある必要はない。件名の要約でも人物証明でもなく、一つの宣言されたメッセージ版を参照するための取っ手である。

世界名を各地で組み立てる

RFC 5322 は、msg-idが世界で一意でなければならず、生成者がそれを保証するとする。しかし一通ごとに番号を払い出す中央サービスはない。

推奨される構成は責任の分割である。@ の右側にドメイン識別子を置き、左側にはその範囲で重複させない値を置く。時刻と連番やプロセス固有値の組合せが例になる。世界で区別できる範囲とローカルな台帳を接続し、世界名を世界的トランザクションなしで作る。

形はアドレスに似るが、メールボックスではない。右側は一意性の責任範囲を助けるだけで、現在のDNS解決、送信者のドメイン支配、著者本人性を証明しない。左側の文字にも業務上の意味を読み込むべきではない。

同RFCは同一性が意味で決まるとも説明する。追跡や再送フィールドの追加は見た目を変えても別メッセージを作らないことがある。IDを替えるかは、送信者が同じメッセージを意図するか別のものを意図するかで決まり、バイト差では決まらない。だからMessage-IDはチェックサムでもSMTPエンベロープの取引番号でもない。

返信が辺になった

In-Reply-To は親メッセージのIDを持つ。References は親が持っていた祖先列を引き継ぎ、その末尾に親IDを足す。異なる経路と時刻に届いたメールでも、ソフトウェアは会話を再構成できる。

この利用は新しいUIの発明ではない。1983年の RFC 850 はUsenetのfollow-upにReferencesの延長を求め、読者ソフトが記事を会話としてまとめ、ニュースグループを退会せず会話単位で隠せることを目的に挙げた。RFC 1036 もこの形を保った。

ただし宣言された祖先は因果の証明ではない。RFC 5322 は、多くの実装が単一の親を仮定して後ろ向きにたどるため、複数親の組立てを十分には定義していない。Referencesは著者の同一性や理解を認証しない。

各サーバーがIDを記憶に変えた

Usenetのピア間配送では、同じ記事が複数方向から到着する。すべてを再転送すれば環状経路を回り続ける。RFC 1036 のhistory機構は、各ホストが見た記事をMessage-IDで記録し、同じIDが来れば直ちに捨てる。Path は無駄な送信をさらに減らすが、既見IDのローカル記憶だけでもループを終わらせられる。

中央サーバーが「配送完了」を宣言するのではない。各サイトが名前を自分の履歴と比べ、同じ論理記事を既に受け入れたと判断する。人が会話をたどるフィールドが、分散複製を収束させる鍵にもなった。

同じ名前は違う本文より強かった

RFC 5536 では、本文やヘッダーが違っても、同じMessage-IDの記事は同一記事として扱われる。高速で一貫した比較のため構文と長さを狭め、大文字小文字を保存し、単純なオクテット比較でidentityを決められるようにした。一意性はメールとNetnewsをまたぐ。

その効率は衝突に権力を与える。攻撃者が将来の記事IDを予測し、別の記事を先に投入すると、本来の記事は「既見」として拒否されうる。RFC 5536が予測困難なIDを勧める理由である。壊れたのは内容ハッシュではない。内容ハッシュではなく、分散名簿の先着順だった。

名前が証明しなかったもの

Message-IDは参照を解決するが、信頼を解決しない。本文に署名せず、From を認証せず、SMTP取引を名付けず、閲覧を証明せず、同じIDのコピーが同じバイトだとも保証しない。同じIDが衝突を隠し、違うIDが同じ文章を運ぶこともある。

設計が長く残ったのは権限が狭いからである。起点は命名し、配送は改名せず追跡証拠を足し、メールソフトは返信辺を作り、ニュースサーバーはローカル履歴を管理する。暗号学的証明は別層の仕事である。

資料と限界

根拠は RFC 733、RFC 822、RFC 850、RFC 1036、RFC 2822、RFC 5322、RFC 5536 である。現在の衝突率、事業者の生成アルゴリズム、実装比率、history保存期間は測定しない。