要約

  • RFC 1496 は、X.400(84) が扱える本文は変換し、扱えない MIME 本文は IA5Text に包み、部分的な不一致のためにメッセージ全体を捨てないよう求めた。
  • 逆方向では MIME-Version が再構成候補を選ぶ印になったが、欠落したヘッダーや壊れた符号化まで取り戻すものではなかった。
  • 古い受信者は対象を保存して外部プログラムへ渡せた一方、その自動起動はトロイの木馬という別種の危険を持ち込んだ。

復元処理は、原物を知っている処理ではない。目の前の文字列から、かつて何が包まれたのかを推定する処理である。先頭の印、型の宣言、転送符号化、残存するデータがそろって初めて、元の MIME 本文へ戻す道が開く。

1993 年8月の RFC 1496 は、この非対称性を X.400(84) と MIME の境界で扱った。RFC 1328 全体を置き換えたのではなく、第6章だけを改訂した文書である。RFC Editor は現在これを Historic とし、Proposed Standard から状態が変更されたことを記録している。課題は万能なメール変換ではなく、旧世代の表現体系で未知の本文に出会ったとき、メッセージ全体を失わずに済ませることだった。

復路から見ると設計の限界がよく見える

HARPOON と呼ばれた方式である。この語に展開形はなく、単なる名称だった。方式は、X.400(84) と MIME の間に概念上 X.400(88) を置く「有用な錯覚」を採用した。すでにある X.400(88) と RFC 822/MIME 本文の対応を利用し、旧版へのダウングレードを整理するためである。

錯覚は責任の並べ方を簡潔にする。実ネットワーク上に X.400(88) の中継点が存在する証拠ではなく、X.400(84) の能力を増やすものでもない。行きのゲートウェイは元の構造を知っているが、帰りのゲートウェイが知るのは、旧環境を通って残った表現だけである。

そこで MIME-Version の位置が重要になる。IA5 本文がそのフィールドから始まれば、通常のテキストではなく HARPOON の包みとして解析する候補になる。しかし候補は証明ではない。本文が途中で切れ、符号化が壊れ、必要なフィールドが書き換えられれば、分岐しても復元は失敗する。普通のテキストが同じ形をまねる可能性も、分類の問題として残る。

行きの三原則は運搬を守った

RFC 1496 の原則は明快だった。変換可能なら変換する。変換できなければカプセル化する。一つの本文部分を変換できないという理由だけで、メッセージ全体を捨てない。

単純な IA5 テキスト、Group 3 Fax、旧システムでも扱える複数本文など、互換な形は余計に変えず通すことができた。X.400(88) の Extended Body Part では PARAMETERS と DATA が別に表現されるため、X.400(84) 向けには両方のオクテット列を所定の順序で結合して扱った。

対応する古い本文形式がない場合は、IA5Text が避難場所になった。MIME-Version、Content-Type、quoted-printable や Base64 などの転送符号化、その後に符号化済み内容を置く。旧い経路には運べる文字として見え、MIME を知る後段には構造を見つける材料が残る。

ここで守られるのは将来の選択肢である。Base64 はバイト列をテキスト経路から守れるが、その型を理解するソフトウェアを届けない。型名は扱い方の候補を示すが、宣言の正しさや送信者の信頼性を証明しない。

本文の生存とヘッダーの生存は別だった

「メッセージを捨てない」という規則を「全情報を捨てない」と読み替えることはできない。RFC 1496 は RFC 822 のヘッダー拡張を別に扱い、RFC 1328 の範囲にある他のヘッダー拡張は落とされる場合があった。

そのため、本文のハッシュが一致し、配送件数も合いながら、処理文脈を与える拡張情報だけが受信側にない、という状態が成立する。運搬の成功と意味の完全性は、同じ監視値からは導けない。

RFC 1328 の周辺規則にも同じ境界がある。アドレスの逆変換には限界があり、対応先のないエンベロープ項目は破棄され得た。ダウングレードは宛先側の設定に左右され、1988 年版のヘッダーが 1984 年版読者向けに除去されることもあった。ディレクトリ名の文字列が残っても、ディレクトリ上の意味まで保存されたとは限らない。

復路で本文を戻せても、行きで捨てたヘッダーは現れない。逆変換は時間を巻き戻す処理ではなく、残存情報から一部の構造を再構成する処理である。

保存できることは、使えることの手前にある

X.400(84) のメール閲覧ソフトがカプセル化された対象を直接表示できない場合、利用者はファイルに保存し、別のプログラムへ渡すことができた。mailcap に似た関連付けがあれば、MIME 型から適切な外部ツールを選び、機能の一部を補えた。

この記述は、配送の終点と利用の終点を区別している。メール基盤は対象を保管した。ローカル環境は、対応ソフトの有無、権限、信頼性、利用者の意図をまだ決めなければならない。保存可能なファイルは、理解可能な情報とは限らない。

さらに、自動化は便利さと同時に新しい制御経路を作る。RFC 1496 は、受信した対象に対してプログラムを自動起動すれば、トロイの木馬の危険があると注意した。相互運用のための型情報が、ローカルコードを選んで動かす入力へ変わるからである。

到着は実行同意ではない。型の認識はハンドラーへの権限付与ではない。プロセスの正常終了は無害な結果の証明でもない。各段階に別の受領証が必要になる。

小さい共通規則が現実を代行しないために

HARPOON が担ったのは、互換なものを保ち、未知のものを回収可能な形にし、不必要な全体廃棄を避けることだった。受信者の能力や外部プログラムの結果まで中央のゲートウェイが決めなかった点は、未完成ではなく境界設計である。

Heng Lu が述べる running code の優先、最小初期仕様、現実層と記号層の分離も、同じ証拠規律を要求する。実装可能な共通部分は薄く保ち、将来の選択はローカルに残す。測定できた配送状態に、理解や安全という未測定の意味を載せない。

歴史を検証可能にするには、元本文の型とハッシュ、選択された規則、ダウングレード後のバイト列、変換前後のヘッダー、復元判定、閲覧ソフトの能力、外部ハンドラーの起動と結果を別々に残す必要がある。MIME-Version は、その連鎖の途中にある有用な印であり、連鎖全体の保証書ではない。

出典