要約

  • message/partialの各断片は、それぞれ独立したメールとして運ばれた。idが集合を示し、numberが順序を示し、totalが期待される個数を示して、受信ユーザーエージェントがローカルに再構成した。
  • 再構成後の意味は内側のMIME実体に従った。第1断片の外側ヘッダーと内側の特定ヘッダーが規則どおりに統合され、第2断片以降の外側ヘッダーは派生結果から除かれた。
  • 同じ識別子と連続番号は、送信者認証、内容ハッシュ、重複の同一性、表示完了を証明しない。書式は検証可能な候補集合を記述し、実際のオブジェクトは受信側の実行結果として成立した。

一つのメールにも経路ごとの上限があった

送信者にとって一つの文書でも、ストア・アンド・フォワードの経路では複数の容量判断を受ける。最初のサーバーが受け入れ、次がキューに置いても、その先のゲートウェイが自分の上限を理由に拒否できた。SMTPには全経路に共通する最大サイズがなかった。

1989年の RFC 1123 は、メールソフトウェアに少なくとも64Kバイトの送受信能力を求め、さらに大きな上限を強く望ましいとした。同時に、実装上の制限が残る一方で、すでに1メガバイト以上の文書がメールで送られていると記録した。これは最低能力を定める規則であり、経路全体の受領保証ではない。

すべての中継機に一斉の上限引き上げを命じる方法は、異質なインターネットには合わなかった。MIMEは、既存の配送単位であるメッセージを維持しながら、一つの意味上の実体を複数の配送単位に載せる方法を選んだ。全体は途中で宣言されず、断片を持つ受信側で初めて検証できた。

外側では一通、内側では未完成

1992年6月の RFC 1341 は、最初のMIME仕様にmessage/partialを置いた。この型の本文は、より大きなメッセージの断片である。しかし外側のメッセージは不完全な配送ではない。固有のMessage-ID、Receivedヘッダー、到着時刻、配送成否を持ちうる一通のメールだった。

multipart/mixedと混同すると構造が逆になる。multipartは一通の中に複数の部分を包む。partialは複数の通が一つの内側実体を構成すると主張する。したがって番号3が先に届き、番号1だけ別のゲートウェイを通ってもよい。配送の履歴が別でも、本文の順序は別の規則で保てる。

SMTPが一断片を受け入れた事実は、その断片についての記録にすぎない。メールボックスに二片ある事実も、内側の実体を作り出さない。部分的な証拠は現実を記述するが、全体を宣言する権限を持たない。

三つのパラメーターは小さな共通法だった

idは同じ集合に属するという主張を担い、可能な限り世界的に一意になるよう生成された。numberは位置を表し、1から始まった。totalは総断片数を表した。Content-Type上での記述順序に意味はなかった。

最終断片にはtotalが必須で、それ以前では任意だった。ただし後の仕様は早い段階での記載を勧めた。送信者は最終個数をまだ知らなくても分割を始められ、最後を名乗る時点では受信者に終端条件を渡す。

1993年の RFC 1521 はこの仕組みを引き継ぎ、運用条件を明確にした。それでもidはダイジェストにならなかった。同じ番号の二片が異なる本文を含むことも、異なる集合が同じ値を誤用することもありうる。totalは期待値であって、全番号の到着証明ではない。

受信側は1から総数までの連続性、重複の整合性、総数の矛盾、サイズ、期限を自分で検査し、連結結果がMIME実体として解析できるかを確かめる。標準が与えたのは共通の検査項目であり、信頼を代行する中央判定ではなかった。

再構成後は内側の型が前面に戻った

断片をつなぐと、結果は独自のContent-Typeを持つ完全なMIME実体になった。内側が音声なら音声として扱われ、「メッセージの中にメッセージがあり、その中に音声がある」という外装を恒久的に表示しない。この透明性により、分割は配送上の手段にとどまった。

ここには二種類のMessage-IDがありうる。各外側メッセージの識別子は、独立した配送を指す。内側のMessage-IDは、再構成されたメッセージを指す。外側の値をそのまま内側の同一性と見なせば、経路の出来事と意味上のオブジェクトが混ざる。

時刻にも同じ境界がある。番号4が最初に届いたことはキューや経路の観測として重要だが、本文の先頭にはならない。連結を支配するのはnumberである。早さは証拠であって、順序を決める権威ではない。

第1断片はヘッダーの基盤も運んだ

本文を番号順に並べるだけでは足りない。外側の各メールにはFrom、Date、Subjectなどがあり、全部を残せば再構成後のヘッダーが競合する。そこでMIMEは、行境界でのみ分割することと、ヘッダーの統合規則を定めた。

最初の外側メッセージからは通常のヘッダーをコピーするが、Content-*とSubject、Message-ID、Encrypted、MIME-Versionを除く。内側からはContent-*と、その四種類の選択されたヘッダーを追加する。その他の内側ヘッダーは落とす。第2以降の外側ヘッダーは再構成結果からすべて捨てる。

1996年の RFC 2046 は、この責任分担を確定した。number=1の外装が残る外側文脈を提供し、内側がメディア型と選択された意味上のフィールドを提供する。後続外装は別配送の証拠として有用でも、最終ヘッダーの多数決には参加しない。

したがって第1断片を失うことは、単なる最初のバイト範囲の欠落以上の意味を持つ。本文断片だけを保存して外装を消したシステムは、データ区間を揃えても規定どおりのヘッダーを作れないことがある。最初に到着した外装を選ぶ実装も、番号と到着時刻を取り違えている。

監査可能なシステムは、元の外側メールと派生した内側実体を別々に残す。前者は配送、遅延、重複、認証差を説明し、後者はローカルな構成結果を示す。派生物だけを残せば、選択の履歴が配送事実に見せかけられる。

断片ごとに別のゲートウェイを通れることが制約を決めた

8bitやbinaryの内側データは難題だった。message型の外側は、単純にbase64やquoted-printableで包み直せない。二進データを分ければ各断片が二進配送を必要とし、7bit環境のゲートウェイは一片だけを見ても変換できない。残りが別経路なら、全体を待つことさえできない。

そのためmessage/partialの転送符号化は7bitに限定され、内側も8bitやbinaryに依存できなかった。RFC 2045 が一般のMIME転送符号化を定め、RFC 2046がpartialにこの厳しい条件を課した。

これは中央の再構成ゲートウェイを仮定しない設計である。送信側が、独立した経路の共通最低能力に合う表現を用意する。制約は増えるが、どこか一者が全断片を見るという架空の権限を作らない。

中継点ごとにサイズ閾値が違えば、再構成した結果がさらにmessage/partialになることもある。仕様は入れ子の断片化を明示的に認めた。受信側は層を認識して手続きを繰り返す一方、深さと計算資源の上限は自分で持つ必要がある。

SIZEは入口を知らせても、内側を組み立てない

1995年の RFC 1870 はSMTP SIZE拡張を定めた。サーバーは固定上限を広告でき、クライアントは本文送信前に推定サイズを申告できる。明らかな超過なら、全本文を送る前に拒否できた。

しかしSIZEとmessage/partialは別の問いに答える。前者は一つのSMTP接続で一通を受け入れるかという判断である。後者は複数の配送後にユーザーエージェントが一実体を作れるかという表現規則である。SIZEへの肯定応答も最終配送の絶対保証ではなく、再構成機能を示さない。

一方は局所的な上限を早く可視化し、もう一方は異なる上限を越えて意味を保つ。技術の年代を単純な置き換えとして読むより、この権限分離を見るほうが重要である。

三つの台帳が一つの成功表示を吟味する

外側台帳には、生の各メッセージ、外側Message-ID、Received、到着時刻、処理結果を置く。集合台帳には、正規化したid、番号、総数、欠番、衝突重複、期限を置く。再構成台帳には、各番号で採用した片、連結順、ヘッダー統合、解析結果、型、入れ子の次層を置く。

送信元認証、完全性、安全性はその後の別判定である。番号が揃っていても危険な内容はありうる。外側ごとに認証結果が違うこともある。MIME解析に成功しても署名、表示、閲覧を証明しない。

この仕組みが示した一般原則は、識別子の効用を狭く保つことだった。共通ラベルは独立参加者を調整できるが、オブジェクトも信頼も結果も創造しない。最小の決定規則を実装した受信側が、手元の証拠から実際の状態を作る。