要約

  • RFC 5259 では保存中の元データを変更せず、クライアント指定またはサーバー選択の派生物を返す。表示できたことは、同一バイト、署名の真正性、原本の置換を意味しない。
  • 最終 OK に項目単位の失敗が含まれうる。既定変換は細部削除や文字置換も行えるため、コマンド状態ではなく各出力の証跡が必要である。

読めた瞬間に、署名対象との距離が見えなくなった

現場端末は元の契約書形式を開けなかった。サーバーは画像を縮小して別形式へ変換し、画面には整った文書と署名の図柄が現れた。担当者は「署名済み文書を確認した」と記録した。

しかし RFC 5259 は、署名された本文部分をサーバーで変換した場合、クライアントがその署名で変換後コンテンツを真正と検証する方法はないとする。信頼しないなら、署名対象をダウンロードして検証し、その後でローカル変換する。

表示成功と認証成功は異なる層だ。派生物が役に立つことと、原本の権威を継承することを混同してはならない。

保存原本は動かず、返却表現だけが変わる

変換が影響するのはクライアントへ送るデータだけであり、メッセージストアの原データは変更してはならない。この要件により、別クライアントは原本を取得でき、返信・転送、BODYSTRUCTURE、署名検証も元の対象を使える。

一方の出力は MIME 型、構造、符号化、寸法、文字集合、サイズが異なりうる。一回の要求に属する実行結果である。派生物だけを保存しても原本が変わった証拠にはならない。

源のメールボックス、UID、部分番号、ハッシュと、出力側の要求、方針、版、ハッシュを別々に識別する必要がある。

可能性の一覧は実行結果ではない

サーバーは CONVERT と BINARY を広告し、CONVERSIONS は変換可能な MIME 組とパラメータ、AVAILABLECONVERSIONS は特定部分の候補を返す。

それは能力の地図であり、後の実行に資源があったこと、同じ変換器が動いたこと、全パラメータが守られたこと、端末が正しく描画したことを示さない。サービス停止や無効値、未対応形式で失敗しうる。

能力発見と実行には別の時刻と受領記録を与える。対応形式名だけから出力バイトは再現できない。

NIL は表現選択をサーバーへ渡す

クライアントは目標型を指定するか、NIL で既定変換を求める。サーバーは端末特性、利用者・管理者の好み、設定、一般的形式の判断から選ぶ。正確な選択アルゴリズムは規定されない。

端末能力を超える細部も削除できる。画像縮小が典型だ。品質損失を抑えるべきだとしても、無損失同等性の保証ではない。

能力を伝えなければサーバーが誤推測しうるため、RFC は安易な既定変換を避けるよう促す。これは計算だけでなく、人が見る表現の選択を委ねる行為である。

正常終了の中に情報欠落がありうる

文字変換では目標 charset が必要になる。表現できない文字に unknown-character-replacement を指定すれば、有効な結果の中で元の文字が置き換わる。名前、金額、記号の差が消えてもプロトコル上は要求どおりになりうる。

ヘッダーの encoded-word や MIME パラメータも再符号化される。意味が近くても元オクテットは同じでない。忠実度はバイト、意味、レイアウト、寸法、除去箇所ごとに見るべきだ。

部分 CONVERT BINARY の範囲は、変換・復号後データ上の位置である。原本の位置ではない。派生物のオフセットを原本証拠へ持ち込んではならない。

OK は全項目成功の集計ではない

CONVERTED には TEMPFAIL、BADPARAMETERS、MISSINGPARAMETERS が入りうる。一つの要求が複数項目を扱う場合、少なくとも一つ成功すれば最終結果は OK でなければならない。全失敗でも OK または NO が許される。

従ってコマンドの緑表示だけでは不十分だ。ある部分は成功し、別の部分は失敗しうる。構造だけ返り、バイトがない場合もある。要求項目ごとに値またはエラーを照合する。

BODYPARTSTRUCTURE は通常、要求が正確に満たされたかを示すが、理由をすべて説明するとは限らない。パラメータと出力ハッシュに結び付けるべき証跡である。

既読にも新しい正本にもならない

CONVERT は \Seen を立てない。既読化には別の STORE が必要だ。派生バイトが生成された事実から、人が見たこともメール状態も推定できない。

サーバーは効率のため変換をキャッシュできるが、DoS 対策として数を制限する。キャッシュは一時状態で、恒久的な別原本ではない。同じ要求でも変換器、フォント、方針、外部サービスの更新で結果が変わる。

判断に使った出力は、その場で保存しなければならない。

変換器は独立したセキュリティ境界である

細工したメッセージを APPEND 後に CONVERT すれば、脆弱な codec や parser を攻撃できる。極端な拡大は資源を消費し、危険な変換は実行形式を生みうる。高負荷・危険な処理の拒否、出力検査、認証主体の記録、特権ストアからの分離が推奨される。

外部変換サーバーは保管経路を一つ増やす。同一信頼領域でも、どこへ源が渡り何が返ったかは記録する。

SASL/TLS は相手と経路を守るが、変換後バイトを元署名の対象にはしない。

源から派生物までの実行証跡

メールボックス、UIDVALIDITY/UID、源部分、MIME、サイズ、ハッシュ、要求型と全パラメータ、明示/既定選択、端末能力、利用者・管理者設定、サーバー方針、変換器版、時刻、安全領域を保存する。

さらに各 CONVERTED 項目、エラー、最終状態、出力構造・サイズ・ハッシュ、削除詳細、置換文字、キャッシュ、原署名検証、派生物がその検証を継承しないこと、描画結果、\Seen、後続判断を結ぶ。

「この要求からこの派生バイトが返った」は検証できる。「署名済み添付である」には新しいバイトを覆う認証が要る。「成功した」は全項目の結果が揃って初めて言える。

RFC 5259 は制約端末に実用的な適応を与えた。組織はその価値を守るため、読みやすい表現が認証済み源を名乗らないようにしなければならない。

出典