要約

  • RFC 2017はmessage/external-bodyにURLアクセス型を加えた。メッセージが運ぶのは取得記述で、対象のバイト列は外部に残る。
  • 分割と符号化はヘッダー内で取得先を保つが、到達性、恒久的な同一性、真正性、取得許可までは証明しない。
  • 型の一致、明示的同意、Content-MD5による完全性確認は別々の制御であり、公式資料は広範な実装を示していない。

MIMEには、本文をメッセージの外に置く発想がすでにあった。RFC 1521はFTP、匿名FTP、TFTP、ローカルファイル、メールサーバーというアクセス方法を挙げた。RFC 2017が足したのはURLである。必須のURLパラメーターが取得先を示し、内側のエンティティヘッダーが期待するメディア型を宣言する。

ただし、URLの形をしたものなら何でもよいわけではない。仕様は、実際にオブジェクトを取得する方式だけを認め、mailtoを明示的に外した。mailtoが示すのはメールボックスと送信動作であって、external-bodyとなるデータを直接得る経路ではない。表記の仲間であることと、操作の意味が同じであることは別だ。

長い取得先をメールヘッダーで壊さず運ぶため、値は引用符内のURL-word列として表現された。各断片は40文字以下で、線形空白で区切られる。受信側は引用符とその空白を取り除いて復元する。分割前には、生の空白、制御文字、引用符、バックスラッシュ、上位ビットを含むオクテットを、当時のRFC 1738の規則で符号化する。

ここで保証されるのは表現だけである。完全に復元されたURLでも、対象が消えている、資格情報が足りない、別の場所へ転送される、時刻によって異なるバイトを返す、といったことは起こり得る。場所を運べたことは、対象を受領した証拠にならない。

バイトを見る前に型が選ばれる

内側のヘッダーは取得予定のメディア型を先に宣言する。RFC 2017は、アプリケーションが実際に使う取得版と宣言型の一致を求めた。すでに取り消せない判断をしている可能性があるからだ。デコーダーやハンドラーの選択は、検証より先に実行権を渡すことになり得る。

URL方式では「phantom body」は使わず、空にすべきとされた。この空白は、メッセージ内に対象の代用品がないことを示す。コマンドをそこに置くmail-server方式との違いも明瞭になる。

翌月、RFC 1521を置き換えたRFC 2046はexternal-bodyの考え方を維持し、キャッシュや後の受領通知を結び付けるためContent-IDを要求した。そして重要な注意を加える。外部本文の解決は、送信者が指定した操作を受信者側で行わせる。利用者エージェントは動作を説明し、明示的な許可を得るべきだ。

従って、構文の正しさは同意ではない。ダイジェストの一致も署名ではない。RFC 2017はContent-MD5を、取得したバイトの完全性と送信者が意図した対象との一致を確かめる助けとして認める一方、デジタル署名ではないと明記する。RFC 1864も同じ限界を置く。

メッセージと外部オブジェクトは、異なる証拠の鎖に属する。前者を認証しても、別プロトコルで後から得たバイトまで自動的に認証されない。取得経路は変えられ、対象も変化し得る。URLは取得方法の記述であって、内容の不変な識別子ではない。

RFC 2017の現在の記録はProposed Standardのままで、確認時のエラッタ検索に該当項目はなかった。参照されたRFC 1738は現在obsoleteで、RFC 3986は後の一般URI構文を示す。これらは文書史を位置づけるが、普及率、運用成果、現代製品への直系関係を裏付けない。

歴史的な要点は、空白を空白のまま扱ったことにある。メールが持つのは取得先で、対象はまだ外にある。その距離を埋めるには、許可、解決、転送、型確認、完全性確認という別々の判断が必要だった。

情報源