要約

  • RFC 9755 は、サーバーがUTF-8能力を広告することと、認証済みクライアントがそのセッションで明示的に有効化することを分けている。
  • 受入試験の終点は、対象利用者がテストメールを一覧、検索、取得、解釈し、必要な操作を行えるという観察結果である。

成功ログの直後に、実務上の失敗が現れることがある。国際化ヘッダーを持つメッセージをAPPENDし、サーバーはOKを返した。それでも受信者は送信者名で検索できず、添付されたメールを開けず、あるいは対応対象の端末で存在さえ確認できない。APPENDの記録は正しい。ただし、証明した範囲が狭い。

RFC 9755 は2025年3月発行のStandards Track文書で、RFC 6855を置き換えた。対象はIMAP4rev1であり、IMAP4rev2は概ね同等の機能を既に含む。UTF8=ACCEPT は国際化メッセージを含むメールボックスのオープンとUTF-8名の応答を示す。UTF8=ONLY はそれを含み、従来のmodified UTF-7を受け付けない。

広告とセッション状態を混同しない

クライアントは認証後に ENABLE UTF8=ACCEPT を送る。UTF8=ONLY のサーバーでも同じで、ENABLE UTF8=ONLY ではない。RFC 5161 の ENABLED 応答が、実際に有効になった拡張を記録する。CAPABILITYはENABLE後も変わらず、セッションの受領証にはならない。

必要なのは、サーバービルドとプロトコル版の記録、そして実際のクライアントごとのコマンドと応答である。接続と結び付かない設定画面だけでは、どちらも確認できない。

認証構文はアカウントを作らない

RFC 9755 はLOGINをUTF-8のユーザー名やパスワードへ拡張しない。必要な場合はAUTHENTICATEを使う。しかし文字列を合法的に運べることは、背後のプロビジョニングがその本人を許可する保証ではない。

権威あるID基盤への登録、実運用方式での認証、正しいメールボックスへの対応、各アクセス経路での権限を別々に確認すべきである。そうしなければ、構文解析器が文字列を受け付けただけで、サービスが利用者を受け入れたことにはならない。

APPENDの後から保存の証明が始まる

ENABLE後、対応サーバーはUTF-8ヘッダーを含むAPPENDを受理し、未有効化の状態では8ビットヘッダーを拒否する。この正負試験は重要だが、索引や表示までは保証しない。

新RFCは旧 APPEND UTF8 データ項目を廃止し、IMAP4rev1、IMAP4rev2、JMAPには、その旧項目で保存されたかをメッセージ単位で信頼して知る方法がないと説明する。したがって、原本テストデータとハッシュ、応答、利用可能ならUIDを保存し、その識別子から同じメッセージを再取得する必要がある。

メールボックス名にも固有の試験が要る。RFC 9755はNet-Unicodeへの適合と制御文字等の排除を求める。RFC 5198 は正規等価な列をNFCへそろえる意味を説明し、RFC 6532 もヘッダーにNFCを勧め、綴りの情報を失い得るNFKCを避ける。見た目、オクテット列、検索一致は同じ約束ではない。

Dovecotの現行文書 では、メールボックス名をUTF-8でディスク保存する設定は独立しており、変更すると既存の非ASCII名が壊れると警告する。これは一実装の境界であって業界調査ではない。プロトコル更新と保存形式移行が別案件であることを示す例だ。

正しいBODYSTRUCTUREは一形態とは限らない

RFC 6532の message/global を知らないソフトウェアは、未知の添付として扱う可能性がある。UTF-8を有効化したIMAP4rev1ではRFC 9755が二つのBODYSTRUCTURE表現を認め、クライアントに両方の受理を求める。IMAP4rev2はRFC 9051に従う。erratum 8697 は該当語を message/rfc822 に訂正した。

試験データには二つのrev1形、rev2形、入れ子の国際化ヘッダー、未解釈部品の取得を含めるべきだ。画面に添付アイコンが出たことは、保存された構造を正しく解釈した証拠ではない。

取得と発見は別の機能である

UTF-8有効化後のSEARCHはcharset引数を付けず、SORTやTHREADではUTF-8を使う。古いクライアントはLISTとFETCHに成功しても、検索要求だけが不適合になり得る。合成・分解文字列、ヘッダー、メールボックス名、本文について、実際の検索式と返却UIDを残す必要がある。

同じメールストアはIMAP、POP、ウェブメール、能力の異なる端末から使われ得る。拒否、通知、非表示、標準化された代替メッセージはそれぞれ異なる方針であり、同等性の証明ではない。既刊記事が扱った「代替の原本を誰が保持するか」は本稿の主題にしない。ここでは、正式対応する各経路が同じテストメールについて宣言済みの結果を出すかを問う。

最後の証拠は利用者の行動だ。メールボックスを見て、対象を探し、送受信者を識別し、各部を開き、方針の範囲で返信・転送できるか。資料が証明するのは標準の意味と一つの実装上の境界であり、製品普及率やベンダー品質ではない。Heng Luが区別する象徴的表現と実行可能な現実に照らせば、能力名は表現であり、使えるメールが観察すべき現実である。 標準の連鎖には、SMTP国際化、ダウングレード変換、対応する簡略POP動作、IMAP4rev2基準も含まれる。これらは相互運用性の境界を定めるが、一経路の成功を普遍的な可視性には変えない。