要約

  • RFC 1524 は、複数のメール閲覧ソフトが共有できる mailcap を提案した。メッセージは MIME Content-Type を示すが、表示・作成・編集・印刷の動作はローカル規則の探索順と適用条件が選ぶ。
  • UNIX では、選ばれた規則は Bourne shell のコマンド行となり、型の値や一時ファイル名が代入された。型一致、環境テスト成功、正常終了のいずれも、内容の真正性、安全性、利用者の同意、正しい理解を証明しない。

本文の渡し方までローカルだった

MIME によって、メールの一部は画像や音声、多数の部分からなる構造として名付けられるようになった。しかし、名前を理解できても、受信機に適切なソフトや表示装置があるとは限らない。各メールソフトが独自に全形式を抱えれば、新しい形式のたびに改修が必要になる。

RFC 1524 の答えは外部設定だった。未知の非テキスト型に出会ったユーザーエージェントは、ローカルにインストールされた処理手段を記す mailcap を参照できる。バイナリを一つ導入し、一行追加すれば、異なるメールソフトへ同じ能力を渡せる。

ここで共有されたのはプログラムではなく、型とローカル動作を結ぶ記述方式だった。送信者は相手の OS を知らなくてよい。代わりに、どのプログラムへ権限を渡すかは受信側に残った。

最初に適用できた規則が勝つ

有効な設定は複数 mailcap ファイルの仮想的な連結である。Content-Type が一致し、要求された動作に必要な情報を持ち、任意の test= に通る最初のエントリーが選ばれる。

したがって順序は監査対象である。UNIX 付録の既定経路では利用者のファイルがサイト側の場所より先に置かれ、MAILCAPS 環境変数は経路全体を置換できた。管理者の標準と個人の上書き・追加が共存する。同じメールでも、アカウントごとの有効経路が違えば別のプログラムが起動する。

必須なのは型パターンと表示コマンドだった。作成、型付き作成、編集、印刷、テストは別フィールドである。needsterminal は対話端末を要求し、copiousoutput はスクロール等が必要な長い出力を知らせた。ある形式を「サポートする」という一語では、どの操作を許すか説明できない。

test= はウィンドウシステム、機種、音声装置などの外部条件を調べるプログラムである。終了値ゼロは、その環境で当該規則を使えるという意味に限られる。受信本文を安全と判定したわけではない。

規則はシェルへ渡る実行文になった

RFC の UNIX セマンティクスでは、動作フィールドは Bourne shell 向けの完全なコマンド行で、事実上 /bin/sh -c が前置される。%t はメディア型、%{名前} は Content-Type パラメーター、%n は multipart の部分数、%F は型とファイル名を交互に並べた引数、%s は本文ファイルへ置換される。

これは静的なアプリ関連付けではない。ヘッダーを解析し、規則を選択し、引用を解釈し、値を展開し、引数を組み立て、OS に実行文を渡す。それぞれが独立した証拠点である。構文上正しいパラメーターでも、意図した一引数になるとは限らない。プロセス起動は適切な表示の証明にならない。

%s の有無は本文の経路も変えた。なければ表示・編集プログラムは標準入力から読む。あればメールソフトが一時ファイルを作る場合がある。RFC はコマンド終了後の存続を前提にできないとし、バックグラウンド処理を続けるプログラムに必要な保存を求めた。

nametemplate.gif のような拡張子を要求するプログラムに合わせて一時名を作る。名前の互換性は得られるが、中身の検査、送信者の認証、安全性の保証は得られない。

作成側にも別の受け渡しがあった

compose はデータを生成し、呼び出したメールソフトが規則の型を付ける。composetyped は Content-Type 等を自ら出力できる。配送に必要な転送符号化は、型付き作成側が明示しない限り呼び出し側の責任だった。

ローカル作成でも、選択規則、生成プロセス、出力バイト、型宣言、転送符号化、最終メッセージは別々である。エディターの終了だけでは後段を証明できない。

拡張性は信頼を配布しない

RFC 1524 は、自動実行するプログラムの選択に注意するよう実装者と管理者へ警告した。特定の攻撃や製品欠陥を報告した文書ではない。証明できるのは設計境界である。遠隔のラベルがローカル動作になるのは、誰かが管理する規則が両者を結んだからだ。

後続の MIME 文書は形式、符号化、型、登録手続きを整え、RFC 6838 は登録枠組みを更新した。登録済みの名前は共有しやすいが、受信側にハンドラーを導入せず、優先規則や実行許可も証明しない。

履歴として残すべき鎖は、受信バイトと宣言型、有効な mailcap 群と順序、要求動作、選択規則とテスト、展開後コマンド、標準入力または一時ファイル、プロセス結果、表示、利用者判断である。「添付を開いた」だけでは、記述が権限へ変わった場所が見えない。

情報源