要約

  • RFC 3462 は multipart/report を MIME 内容の最外層に置き、人が読む説明と機械が解析する型付き記録を、この順で必須とした。三番目には元メッセージまたは診断に必要な一部を任意で返せた。
  • report-type は第二パートの MIME サブタイプを外側から示したが、それは認識の仕組みであって認証ではない。正しい形の偽造報告でも、人や自動処理を誤らせる余地が残った。

一つの出来事を二つの読者へ渡す

配信失敗を自然文だけで説明すれば、送信者には親切でも、言語や表現の違いが自動処理を不安定にする。逆にコードと項目だけを返せば、プログラムには便利でも、利用者は何を直すべきか分からない。歴史的な課題は、どちらかを標準にして他方を捨てることではなかった。二つの表現を並べ、その役割を混同させない器が必要だった。

2003 年 1 月の RFC 3462 は、その器を定義した。プレーンテキスト、RFC Editor の記録、Datatracker、履歴、参照文書、後続文書からの参照、正誤情報が公開された規格記録を形作る。RFC 1892 を廃止しつつ、人向けと機械向けの証拠を一つの MIME 報告に共存させる発想を一般化した。

multipart/report はメッセージの最外側の MIME Content-Type でなければならない。RFC 2046 の multipart に必要な boundary に加え、report-type が必須だった。その値は第二パートの MIME サブタイプを指定する。処理系は本文をすべて読む前に外側のヘッダーを見て、報告であることと、内部に期待すべき機械記録の種類を判断できた。

順序そのものが意味を持った

第一パートは必須で、人に読ませる。標準で定義された MIME タイプなら選択でき、対象に合う文字集合と言語を使えた。multipart/alternative で複数の提示方法を用意することもできる。説明は受け手の状況に依存するため、この部分には表現の余地が残された。

第二パートも必須だが、機械処理のためにある。登録済みのメディアタイプでメッセージ処理イベントを記録し、専門家向けの詳細も含められた。配信状態通知では RFC 3464 の message/delivery-status が使われる。ただし、RFC 3462 は SMTP で通知を求める仕組みを定めた RFC 3461 や、拡張状態コードの RFC 3463 の代わりではない。これは機械記録の置き場所と型を決める規格であり、配信の事実を単独で作る規格ではない。

第三パートは任意で、元メッセージまたは診断と照合に役立つ部分を返す。返送量が指定されていなければ完全なメッセージを返すのが基本だったが、帯域を使い、内容の露出も増える。8 ビットまたはバイナリを安全に戻せるか不明な経路では、合法な 7 ビット MIME へ再符号化するか、text/rfc822-headers だけを返せた。RFC 822 の系譜にあるヘッダーは照合には有用だが、完全なメッセージではない。したがって message/rfc822 と称することはできない。

三つの位置は証拠の分業を示した。第一は説明し、第二は計算可能な主張を載せ、第三は文脈を戻す。読みやすい文章は状態項目ではなく、状態項目は元の通信そのものではない。ヘッダーだけの断片も完全な原本ではない。同じ封筒に入ることは、同じ重みを持つことではなかった。

検出できても、出所は証明できない

最外層に置くことで、自動処理は Content-Type から報告を早く選別できた。IANA メディアタイプ登録簿は共通のサブタイプ名を支えた。この構造は後に、RFC 3798 から RFC 8098 へ改訂された開封・処置通知や、RFC 6533 の国際化配信状態でも利用された。

しかし RFC 3462 は、この形が内容を認証しないと警告した。偽の否定的報告を自動処理すると、メーリングリストやディレクトリから正しいアドレスを削除し、保守機能がサービス拒否の手段になり得る。偽の肯定的報告なら、届いていないものを届いたと信じさせる。報告全体を署名すれば偽造を抑える助けになるが、その方法は規格の範囲外だった。

構文が示せるのは、バイト列が文法に合うことまでである。誰が生成したか、記述されたイベントが起きたか、人が説明を読んだかは別の問題だ。パース成功をそのままアドレス削除などの権限へ変換すると、見た目に運用上の力を与えてしまう。

Heng Lu が後に示した現実の層を分ける視点を使えば、届いた主張、パーサーの解釈、メールシステムの実際のイベント、管理上の決定を別々の受領証として扱える。実行されるコードを優先する議論は、実際の MIME 木、生成器、認証処理、結果を消費する自動化へ目を向けさせる。これらは後世の編集上の分析であり、RFC 執筆者の私的意図を断定するものではない。

RFC 3462 の価値は、報告を真実にしたことではない。人の説明、機械の主張、任意の返送資料を見つけやすい一つの構造に置きながら、それぞれの限界を残したことにある。信頼は、封筒の外から別途持ち込まなければならなかった。

情報源