要約

  • RFC 1344 は、同種のメール環境内で運ぶ transport と、異なる環境を接続して内容を変えうる gateway を分けた。内容を変更する relay は、透明な運搬者のままではいられない。
  • MIME は、理解できない原文を退信に丸ごと封入し、大きな本文を分割し、外部データを移し、壊れやすい文字を符号化できた。しかし保護と置換は同じ変換ではない。
  • 変換 trace と送信者の禁止指定は介入を見えるようにした。後の MIXER と DSN は、損失、元と最終の宛先、共通コードと固有コードを別々に残し、結果の上書きを防いだ。

MIME は運送業者に読解を要求しなかった

画像や音声をメールで送れるようにするため、すべての中継装置を一斉に入れ替える必要はなかった。MIME の本文は既存の配送経路を通れた。途中の MTA は、画像の意味を知らなくてもバイト列を次へ渡せた。

この性質があるからこそ、RFC 1344 の区別は厳しい。transport は概ね同質な電子メール環境で message を動かす。gateway は性質の異なる二つの環境を接続する。前者が内容を変えることは一般に許容されず、後者では変換が避けられない場合がある。

たとえば高価な大陸間回線を通すため、SMTP relay が GIF を小さな JPEG に変えたとする。帯域費用は下がるかもしれない。だが同時に、新しい形式を受信側が扱えると仮定し、細部を落とす可能性を選び、送信者とは別の表現を届ける。RFC はこの行為を単なる高速化とは呼ばなかった。relay は自らを gateway と再定義すべきだとした。

同じ筐体でも、何をしたかによって責任が変わる。受領と引き渡しの記録だけで足りる transport と、表現を選んだ理由と差分を残すべき gateway は、別の証拠を持つ。

読めない原文でも、壊さず返せる

退信を普通のテキストだけで作る慣行は、元の message もテキストなら大きな問題になりにくい。画像や音声のバイトを文字として並べれば、失敗理由も原物も扱いにくくなる。

RFC 1344 の例は、multipart の一方に人向けの説明を置き、もう一方に拒否された message 全体を message/rfc822 として封入した。配送ソフトウェアは中の画像を解釈しなくてよい。対象をそのまま保持し、拒否という別の出来事を添えればよい。

ただし、これは完成した退信標準ではなかった。文書自身が、多数ある形式の一例にすぎず、拒否と acknowledgement の標準化には別の IETF 作業が必要だと述べた。表現できることと、相互運用できることを混同していない。

後の RFC 3464 は Delivery Status Notification を機械可読にした。message 全体の情報と recipient ごとの結果を分け、転送や書換え前の original address と reporting MTA が見た final address を併記できた。外部システム固有の error code と、横断的に扱える status も両方残す。共通化で分類し、固有値で原因を再現する設計である。

同じ「変換」でも証明する対象が違う

ASCII と EBCDIC の境界で特定の文字が壊れるなら、base64 や quoted-printable を適用して transport form を安全にできる。受信後に復号すれば元のバイトを一般に回復できる。この処理は内容を別作品へ置き換えるのではなく、壊れやすい経路から守るためのものだった。

一方、GIF と JPEG の変換は新しい representation を作る。小さな形式は長距離配送に有利でも、同じ画素や視覚品質を保証しない。受信者が新形式を表示できるという根拠も必要になる。converter の終了コードは、表示成功や満足度ではない。

message/partial はサイズ制限に対する仕組みだった。送信側または受信側 gateway が、大きな message を分割あるいは再構成できる。しかし上流は下流の上限を正確に知らない場合がある。適切そうな大きさに切ったという記録は、すべての断片が揃った証拠ではない。

message/external-body では、メール本体に大きなデータを入れず、取得場所を示せる。遅い境界の gateway は、データを先に取得し、受信者に近い場所へ複製し、locator を変更できた。RFC は original reference と展開済みコピーを alternative として同時に残す案も示す。近さを得るために由来と将来の更新経路を消さない工夫だった。

Trace は変換主体の署名だった

format conversion を行う場合、RFC 1344 は、おそらく Received field に変換の trace を加えるよう強く勧めた。経路上のどこかで object が変わったなら、その判断を行った地点を配送履歴から消してはならない。

送信者の希望を表す案として Content-Conversion: prohibited と permitted も挙げた。これは Informational RFC の提案であり、全 Internet で標準化・実装されたという証拠ではない。指定がなければ許可を前提とする gateway も想定され、制御できるのは sender であって recipient ではなかった。

ここには権限の空白がある。gateway は回線費用とローカル storage を知る。sender は原文の意図を知る。recipient は自分の端末と用途を知る。どの当事者も全情報を持たない。だから trace は同意を代行するのではなく、誰の判断だったかを残す。

RFC 2156 の MIXER は、X.400 と RFC 822/MIME の間で、conversion prohibition、loss がある場合の禁止、unsupported media、loss を伴う変換、conversion failure を区別した。gateway 自身の conversion trace も追加した。RFC 3464 は original/final recipient と generic/native status を分離した。後世の設計は、1992年の提案が一様に普及したことを示さない。それでも gateway の現実が「forwarded」一語では足りないことを示している。

配送経路の最後には人の結果が残る

原文の生成、transport による受領、境界条件の発見、gateway の選択、変換後 object、次の MTA の受領、recipient ごとの配送、software の表示、そして人の利用は、それぞれ別の出来事である。

変換が正常終了しても decoder がないことがある。SMTP が受けても mailbox で失敗しうる。近いコピーは速くても古いかもしれない。DSN は配送を報告できても、誰かが読んだかは知らない。

RFC 1344 の Security Considerations は security issue を論じていない。したがって attack や侵害の史料としては使えない。残った教訓はより限定的で強い。representation を変更した機械は判断主体である。その行為を記録し、次の結果まで勝手に証明したことにしない。

出典

これらの資料は文書の位置付け、記述された仕組み、後の証拠構造を示す。特定の導入、攻撃、普及率、普遍的な変換方針、同等な表示、配送、同意、人の結果は証明しない。