要約

  • RFC 9698は、認証済みIMAPクライアントに、同じ全メッセージ集合へ到達するJMAPの入口を知らせる。
  • JMAPACCESSの通知には、認証情報がJMAPでも足りるという推論と、両プロトコルで共通するオブジェクト識別子の約束が伴う。
  • 識別子の一致は、後の認証成功、メッセージの存続、表示や可変状態の一致を一括して証明しない。

メールの移行確認で、二つの画面を並べる。件名は同じなのに、送信者のアドレスが違って見える。この差をすぐに「別のメール」と判定すると、問題の所在を取り違えることがある。

RFC 9698は、旧来のIMAP環境に関する具体例を示す。クライアントがUTF8=ACCEPTを有効にしていない場合などには、IMAP側が国際化アドレスを縮退した表現で返し、JMAP側は正確なフィールドを返す可能性がある。同じ対象を見ていることと、同じ表現を受け取ることは別である。

RFC 6855が説明する代替表現は、元のメッセージと完全に交換可能ではない。返信や署名検証に影響する場合もある。これは同文書が扱う従来型クライアントとの境界であり、すべてのIMAP4rev2接続に一律の問題があるという主張ではない。

何を共通にし、何を観測し直すのか

2025年1月に公表され、RFC EditorでProposed StandardとされるRFC 9698は、段階的な移行や、IMAPクライアント内でJMAP拡張を使う場合を想定する。既にある認証済み接続を利用して、新しいアクセス先を知らせる仕組みだ。利用者に設定やデータ取得を最初からやり直させる負担を減らす狙いはあるが、本文書だけから実測の節約量は出せない。

サーバーがJMAPACCESSを通知する際の約束は明確である。両プロトコルから同じメッセージ集合にアクセスできること。あるmailboxまたはmessageが持つobject IDが、他方でも同じ対象に対する同じIDであること。対応は一部だけでなく、完全な等価性を前提とする。

そのため、サーバーはRFC 8474のOBJECTIDも通知しなければならない。通常のIMAP UIDを、そのままプロトコルをまたぐ識別子と考えてはいけない。同RFCのEMAILIDは不変の内容を識別する一方、同じEMAILIDを持つインスタンスのキーワードが異なることはあり得る。

JMAP MailのRFC 8621では、メールの所属mailboxが変わってもEmail IDは変わらず、複数のmailboxへの所属も可能である。RFC 9698自体はmailbox名の一致を要求せず、flagsなどは可能な限りそろえるよう促す。ただし名前やroleにはJMAP Mail固有の規則がある。「同じIDだから全フィールド一致」も「違っていても何でもよい」も、正しい検証方法ではない。

ログインの経路が判断を変える

IMAPのLOGINまたはAUTHENTICATEが成功すると、サーバーはクライアントの認証方法を検討する。その情報からJMAPにも十分な資格情報があると推論できれば、その後に送る能力一覧へJMAPACCESSを含める必要がある。

共有OAuth基盤や共通パスワードデータベースは、RFCに記載された例である。一方、古いクライアント向けにIMAPではパスワードを残し、JMAPでは無効にしている運用も例示される。この場合はIMAPログインが成功しても能力が現れない。したがって、能力の欠如だけでJMAPサービスそのものが存在しないとは断定できない。

入口はGETJMAPACCESSで問い合わせる。対応するJMAPサービスを知っているサーバーは、一つのSession URLを含むタグなしJMAPACCESS応答と、タグ付きOKを返す。知らなければBADとなり、能力を通知してはならない。

確認済み技術訂正8635は、元の例2にあったコマンド名JMAPACCESSをGETJMAPACCESSへ直した。確認日は2025年11月21日である。これは記述例の修正であり、認証方式の変更や実際の攻撃事例を示すものではない。

URLの先にも境界がある

RFC 8620では、Session resourceへの認証付きGETが成功すると、その資格情報で利用できるアカウントや能力を示すSessionオブジェクトが返る。URLを得ることは、この成功を先取りしない。JMAPACCESSは新しい資格情報を発行せず、JMAPでの実際の認証を省略させるものでもない。

同じRFCは、レコードIDの一意性をアカウント内の同一データ型に限定している。照合表には裸のIDだけでなくアカウントと型を残すべきだ。また、IMAPで読んでから半秒後のJMAPアクセスまでに削除される可能性をRFC 9698は明記する。二度の読み取りは一つの固定された時点を共有しない。

安全性の説明にも過大な意味を与えないことが必要だ。RFC 9698の著者らは、クライアントが既に有効な資格情報を持ち、JMAPの既存探索でもURLを得られるため、追加の情報開示による攻撃上の利益は限定的だと論じる。この評価は個々の運用環境を試験した結果ではなく、通常の伝送保護や認証上の要件を取り除かない。

Lu Hengの最小初期仕様と動作するコードの優先、現実の階層に関する論考を編集上の視点とすると、この小さな拡張の価値が見えやすい。共通の約束は狭く定め、実際の採用と結果は運用者が確かめる。

本稿は特定事業者の実装、障害、普及率、性能を測定していない。能力、住所、認証、対象、現在の状態、利用者の操作結果を分けて記録するという提案は、標準に新たな義務を追加するものでもない。移行の完了を、観測できる段階まで引き戻すための方法である。