要約

  • 旧式のメールソフトに渡す代替版は、読めても返信先や一部のヘッダー情報を失っている場合がある。表示できることと、原本を完全に保存したことは別の成果だ。
  • ソフトの更新後も古い代替版がキャッシュに残る可能性がある。サーバー上の最後の原本を削除していれば、更新だけでは失われた情報を回復できない。

新しいソフトにテスト用のアカウントを設定し、国際化されたメールを受信する。文字は崩れず、本文も添付ファイルも開く。この実演は新規受信の能力を示す。しかし、以前から使っていた端末の中に何が残っているかまでは示さない。

古いソフトがかつて受け取ったものは、元のメールそのものではなく、そのソフトで扱えるように変換された代替版だったかもしれない。更新後のソフトがそれを再利用すれば、利用者は新しい機能を持つプログラムで古い制約のあるコピーを読み続ける。これは特定製品で確認した障害の報告ではなく、仕様に明記された条件から組み立てた場面である。

RFC 9755 は、UTF8=ACCEPT を理解しない状態から対応する状態へ更新されたクライアントに対し、ダウンロード済みメッセージのキャッシュを破棄するよう求めている。能力の更新と、保存済み表現の更新は同じ処理ではないからだ。

読めるようにする変換には限界がある

国際化メールは、本文に日本語が含まれるかどうかだけで決まるものではない。RFC 6532 は、アドレスを含むヘッダーの値に UTF-8 を直接使うことを認め、message/global を定義した。そうした構造には、返信先の指定や添付物の説明など、実際の操作に関わる役割がある。

未対応のクライアントを使い続ける場合、サーバーは代替メッセージを作って渡すことができる。RFC 6858 の簡略化方式は、忠実さより実装の簡単さを優先する。表現できない国際化アドレスは、意図的に無効なアドレスや空のグループへ置き換えられる。他人のものになり得るアドレスを作り出してはならない。

返信できないことを明確にするのは、もっともらしい宛先へ誤送信するより安全な選択である。ただし、それによって失われた返信機能が復活するわけではない。表示名に事情が書かれていても、その説明がメールの届く宛先になることはない。

表現できない MIME パラメーターや、その他のヘッダーフィールドが取り除かれる場合もある。添付ファイルを開けることは、その説明情報がすべて残った証拠ではない。本文を読めるという実演は本当に一つの能力を証明しているが、保管物としての完全性までは証明していない。

ここで「別形式で保存しただけ」と説明すると、いつでも元に戻せるかのような印象を与える。簡略化された代替版には、そもそも残されていない情報があり得る。復元可能性は名称ではなく、実際に何が保存されたかで決まる。

詳細な保存用フィールドも、返信の権限ではない

RFC 6857 は、より多くの情報を残すための複雑な方式を定めている。それでも、一般に情報を失わず返信できることまでは保証しない。さらに、Downgraded-* フィールドには悪意ある内容が挿入される可能性も記されている。保存用らしい名前の欄にあるというだけで、その内容が真正になるわけではない。

復旧時に見つかった文字列を、見た目がアドレスに似ているからという理由で返信先として採用するのは適切ではない。手掛かりを保持することと、送信を任せられる情報を確かめることを区別する必要がある。これは本稿の運用上の提案であり、新たなプロトコル要件ではない。

署名についても単純化は禁物だ。署名の対象を変えれば検証に失敗することがある一方、変更を受けない部分だけを対象とする署名は検証できる場合がある。一部の署名が通ったことを、削除されたヘッダーまで保全されている証拠として扱うことはできない。

RFC 6858 は、変換によって検証が困難になりそうだからといって署名を削除することを勧めていない。原本が残っていれば、代替版ではできない確認を後から行える余地がある。エラー表示を減らすために手掛かりを捨てれば、その余地まで狭くしてしまう。

会話の能力と、端末の記憶を分ける

2025 年 3 月の RFC 9755 が拡張するのは IMAP4rev1 である。IMAP4rev2 には対象となる能力がすでに含まれている。rev1 の拡張では、サーバーによる UTF8=ACCEPT の告知と、認証済みクライアントによる有効化を区別する。UTF8=ONLY が告知されても、有効化に用いるのは ENABLE UTF8=ACCEPT だ。

この明示的な境界はセッションの動作を整理する。しかし、更新前に端末へ取り込まれたデータを原本だと認定するものではない。新しい接続が正しくても、画面が古いキャッシュを参照していれば、利用者は更新の恩恵を受けていない可能性がある。

RFC 9051 が定める UID は、メールボックスと有効性の世代に結び付いている。本件は、メールボックスを作り直して番号の意味が変わる問題だけではない。クライアントの能力が変わっても、UIDVALIDITY が変わらず、以前の代替版が残る場合を考えなければならない。

したがって受入試験は、実行ファイルの版や新規アカウントだけで終わらせられない。原本を保存した試験環境で旧クライアントの取得内容を確認し、更新後に新しく取得した内容を比較する必要がある。利用者の実データを削除する実験ではなく、戻せる環境で回復経路を示すための試験である。

成功件数に含まれないもの

RFC 6858 では、IMAP の代替版について報告するサイズを原本のサイズとしてもよい。そのため、報告された大きさが一致しても、受け取った内容が同じだとはいえない。サイズは便利な運用情報だが、完全な同一性の証明ではない。

DOWNGRADED も、国際化メールすべての一覧を示すわけではない。対象となる取得要求で何を求めたかに左右される。一部のフィールドだけなら変換を要しなくても、同じメールの別のフィールドは変換を要する場合がある。要求範囲を記録せず警告だけを数えれば、見えている範囲を全体と取り違える。

さらに重大なのは、ダウンロード後にサーバーの原本を消す経路だ。RFC 6858 は、代替版だけが残ることで情報の損失が恒久化する危険を指摘している。この時点を越えれば、優れた新ソフトでも、どこにも残っていない情報を再取得できない。

規格から言えること、言えないこと

これらの資料は仕様上の仕組みを示すもので、現在の市場占有率や特定製品の損失率を測ったものではない。2013 年の文書にある製品例を、そのまま 2026 年の評価として扱うことはできない。保存に関する法的期限も、本稿は定めない。

編集上の視点は、Heng Lu による象徴的な表示と実際の機能条件の区別 に基づく。技術的な根拠をこの議論で置き換えるものではない。RFC 9755 は、第 6 節の型を message/rfc822 に訂正する検証済み正誤表 8697 も踏まえて読んでいる。

更新で問うべき成果は、新しい受信箱の見栄えだけではない。旧来の保管物について、何が残り、何を再取得でき、どの条件で回復できなくなるのか。それが分からなければ、ソフトの更新完了と記録の引継ぎ完了を同じ日付で扱う根拠はない。