要約

  • RFC 2049 は、増え続けるすべての media subtype の実装を求めず、未知を処理する共通の下限を定めた。
  • 未知の転送符号化、文字集合、非テキスト型は application/octet-stream へ退き、非テキストの生バイトを文字として画面に出すことを避ける。
  • 文中の “safe” は、既知の RFC 821/822 適合系を通過でき、意図されないバイト表示を防ぐという限定語であり、内容、送信者、完全性、表示成功、許可、普及を証明しない。

新しい形式より先に必要だった未知の作法

拡張可能な型体系では、受信側が知らない名前が必ず現れる。全 subtype の理解を適合条件にすれば、新しい登録のたびに既存実装が不適合になる。未知の扱いを自由にすれば、同じバイトが端末に印字されたり、実行されたり、推測で別形式に渡されたりする。

RFC 2049 は万能な理解ではなく、最低限の振る舞いを選んだ。適合する mail user agent は MIME-Version: 1.0 を生成し、Content-Transfer-Encoding を認識し、quoted-printable と base64 を復号し、7bit、8bit、binary も区別する。下位の輸送が 8bit や binary を運べないなら、送信者が適切に符号化し、その事実を表示する。

この設計で重要なのは、ラベルが欠損したバイトを修復しないことだ。ラベルはどの逆変換を試すべきかを示すだけで、その実行結果は別の証拠になる。

符号化が未知なら型の名前を信用しない

未知の Content-Transfer-Encoding に出会うと、実際の Content-Type を知っていても、その MIME entity は application/octet-stream として扱われる。復号方法を知らない段階では、画像や文字列として解釈すべき octet 列をまだ得ていないからである。

Errata EID 5470 は、原文が文法上 Content-Transfer-Encoding 自体に Content-Type があるように読める点を指摘し、主語を “MIME entity with” と明示する案を示す。ただし状態は Held for Document Update であり、訂正文として確定したかのように扱えない。

ここには二つの検証がある。期待された octet 列を復元したか。その後で、media declaration を理解できるか。後者の名前が既知でも、前者を飛ばす根拠にはならない。

最上位の型が教えるのはわずかだった

text では US-ASCII を表示し、他の charset については少なくとも利用者に名称を知らせる。charset が既知なら、未知の text subtype を canonical form から local form に戻したうえで raw 表示として提示できる。charset も未知なら octet-stream へ退く。text という語だけで未復号のバイトを表示してよいわけではない。

未知の image、audio、video subtype も最低限 octet-stream とする。application では quoted-printable や base64 を除去し、結果を利用者のファイルへ置けることが必要だった。しかし保存能力は実行許可ではない。RFC 2046 は、汎用 viewer が対応する最も危険な形式の問題を引き継ぐと警告している。

複合型には別の退路がある。mixed、alternative、digest を認識し、未知の multipart subtype は mixed とみなす。message/rfc822 は再帰構造を保って扱い、未知の message subtype は octet-stream とする。Content-Type 自体が未知なら parameter のない octet-stream となる。ファイル保存やプログラム選択は候補であって、自動実行命令ではない。

“safe” の範囲は画面の手前まで

RFC 2049 が MIME-conformant を “safe” と呼ぶ理由は限定されている。正しく印を付けたデータは、少なくとも無差別な binary として扱われ、何も知らない利用者の画面にそのまま撒かれない。もう一つは、RFC 821 と RFC 822 に適合する既知の系を壊さず、それらにも壊されないという意味である。

不透明なファイルは悪意を持ち得る。選ばれた handler には脆弱性があり得る。復号成功は送信者の本人性、改ざん不在、閲覧許可、正しい描画、利用者の注意を証明しない。未知 charset の名称を知らせるだけでも最低線を満たし、未知 subtype は保存だけでもよい。拒否できることが互換性の一部だった。

壊れた MTA は現実であって規則ではない

同じ文書は、当時広く配備された非適合 MTA がローカル保存形式に合わせて message を変更し、あるいは単純に壊していたと記す。NUL、TAB、行末空白、長い行、非 invariant 文字、単独のピリオド、行頭 From などが失われ得た。base64 は最小の可搬文字集合と行長条件を満たし、quoted-printable は多くの gateway を越えるが、すべてではない。

しかし RFC は、これを MTA への推奨事項ではないと明記した。RFC 821 は空白変更や行の折り返しを禁じていた。BAD で invalid な既存動作に耐える工夫と、その動作を正当化することは別である。

したがって、規範上の義務、適合システムへの仮定、非適合システムへの防御、実際の配備は同じ証拠ではない。

出版状態も実装結果ではない

RFC Editor の現在の情報ページは RFC 2049 を Draft Standard と表示し、本文は Standards Track、日付は1996年11月である。この記録は文書の地位を示すが、製品の適合率を示さない。

Verified の EID 3933 は要件10の参照を直す。encoded-word の認識は RFC 822 の word grammar と RFC 2047 Section 6 を指すべきで、RFC 2049 Section 4 ではない。これは構文上の修正であり、表示語を送信者 ID や配送先に変えない。

RFC 2049 の成果は、知らないことを規律化した点にある。理解できる層だけを戻し、理解できない内容を隔離し、binary custody を textual understanding と呼ばない。その小さな約束が、すべての実装の同時更新なしに MIME を拡張可能にした。

情報源