要約

  • RFC 2076 は情報提供の目録であり、すべての項目を標準化する文書ではない。メール、Usenet、X.400 ゲートウェイ、非標準慣行には別々の適用範囲が残った。
  • SMTP、UUCP、NNTP のエンベロープ属性と、PEM や MOSS 本文内部のフィールドは対象外だった。メッセージヘッダーは取引全体ではない。
  • 証拠は、出現、定義、プロトコル、状態、ローカル処理、観測結果の順に接続する。前段の受領証で後段を代用できない。

1997 年の RFC 2076 は新しいヘッダーを発明したのではなく、すでに流通していた名前に境界を付けた。標準、実験的、論争あり、非推奨、Usenet 限定、X.400 ゲートウェイ向け、単に一般的な非標準慣行という差を、同じ表の中で消さなかった。

同じ書式は同じ制度を意味しない

目録は RFC 822 のメール、RFC 1036 の Usenet、RFC 1327 の X.400 変換などを参照した。ニュース用フィールドがメールに混入しても、メールで標準化されたことにはならない。X400-Received や Alternate-Recipient も変換の文脈を伴う。

後の RFC 3864 は恒久・暫定レジストリを設け、同名に複数プロトコルの登録を許した。暫定登録は IETF や IANA の承認ではない。RFC 4021 と現在の IANA レジストリも、プロトコル、状態、参照を分離している。

対象外の項目が運用境界を示した

RFC 2076 は SMTP、UUCP、NNTP のエンベロープ、PEM/MOSS 本文内の属性、HTTP 専用ヘッダーを除外した。見える一行は、実際の宛先、返送経路、本文内の安全性主張の代わりにはならない。

調査では、元メッセージ、エンベロープ、リレー記録、ゲートウェイ変換、クライアント判断を分けて保存する必要がある。一つの正規化オブジェクトに潰すと、誰が何を決めたかが消える。

Apparently-To は推測のプライバシー費用を示した

一部の sendmail は To がないとき、エンベロープ宛先から Apparently-To を挿入した。RFC 2076 は非標準・非推奨とし、BCC 宛先を漏らし得ると警告した。搬送層だけが知る情報が読者向け内容へ変換されたのである。

Reply-To は標準でも用法が論争的だった。個人返信、全体返信、メーリングリスト方針は同じ意図ではない。Errors-To と Return-Receipt-To は非標準・非推奨で、要求の存在は配達や閲読の証明にならなかった。

結論は、出現 → 定義文書 → 文脈 → 状態 → 実装判断 → 結果という鎖からのみ得られる。

出典