要約

  • RFC 9979は$istrustedを、配送時にサーバーが設定する共有かつ助言的なIMAP/JMAPキーワードとして登録した。表示名とメールアドレスの双方を高い確度で確認したという判断であり、SPF、DKIM、DMARCの通常の成功だけでは設定してはならない。
  • 対応クライアントは確認済み表示に使えるが、その状態は本文の安全性、リンクの正当性、行動の権限、UI表現の正確さ、将来も変わらない有効性を証明しない。RFCは侵害されたサーバーがキーワードを操作して利用者を欺けるとも警告する。
  • Daniel Kadeは、本文や秘密を保存せずに、サーバーの証拠区分とポリシー世代、キーワード状態、クライアント表示、重要な依存、後日の訂正を結ぶ最小限の訂正記録を提案する。

配送時の一判断が、複数の画面で別々の寿命を持つ

メール事業者が自社のアカウント通知を利用者へ送る場面を考える。受信側のサービスは、表示された名前とアドレスが本当に事業者のものだと強く判断できる材料を持ち、配送時に$istrustedを付ける。ブラウザーには小さな印、スマートフォンには「送信者を確認済み」という文言が現れる。利用者には内部の根拠が見えなくても、サービス自身がその身元を特別に保証していると受け取るだろう。

後日、その判断が誤りだったと分かったらどうなるか。証拠源の適用範囲が広すぎた、古いルールが残っていた、あるいはサーバーの完全性が損なわれていたかもしれない。サーバー上の状態を消すだけでは、過去は復元できない。どのメッセージが対象で、どのルールが決め、どのクライアントがどんな強さで示し、その表示中に重要な操作が始まったのかが必要になる。

RFC 9979は2026年5月、IETFストリームのInformational RFCとして公開された。異なる実装で使われてきた17個のメッセージキーワードと3個のメールボックス名属性を定義し、名前の衝突を避けるために登録している。これは語彙の統治である。設定主体、共有範囲、助言か自動動作か、想定用途を明らかにし、サーバーとクライアントが同じ印を同じ意味で扱えるようにする。

$istrustedの意味は軽くない。サーバーが送信者の名前とアドレスの真正性を高い確度で確認したことを示す。典型例は、メール事業者が顧客に送った自社メッセージを認識する場合だ。クライアントは確認表示を出し、事業者になりすましたフィッシングとの見分けを助けられる。

だからこそRFCは慎重さを要求する。誤って設定すれば、利用者が詐欺メッセージを信じる原因になる。さらに、SPF、DKIM、DMARCという標準的な認証機構を通過しただけのメッセージに使ってはならない。それぞれの結果には固有の意味があるが、表示名とアドレスを強く信頼するという結論へ自動変換はできない。

登録された印は、判断の理由書ではない

IANAのIMAP/JMAPキーワード登録簿では、$istrustedはSHARED、COMMON、BOTHに分類される。RFCの登録項目は助言的なキーワードとし、配送時にサーバーが設定すると定める。これにより、発言者はサーバーであり、複数クライアントが共有でき、状態そのものが自動処理命令ではないと分かる。

しかし、クライアントが受け取るのは結論であって証拠一式ではない。どの証拠区分を採用したか、どの版のルールか、材料をいつ観測したか、誰が再審査したか、なぜ後に結論が変わったかは一ビットから読めない。反対にサーバーも、各クライアントがどう表現したかを当然には知らない。控えめな印と「安全なメール」という強い文言では、同じ状態でも利用者への約束が違う。

同じRFCに並ぶ他のキーワードを見ると、境界がさらに明確になる。$newは注意を促す助言で、利用者の操作後に消せる。$notifyは通知につながり得る。$mutedはクライアントが設定し、スレッドの新着をサーバーが目立たなくする契機になり得る。$unsubscribedは解除を試みた記録であり、成功証明ではない。一つの語は一つの状態境界を整えるのであって、結果全体を保証しない。

メールボックス属性も同じ教訓を持つ。Snoozedは延期したメッセージの格納場所を識別するが、RFCはスヌーズ機構やUIそのものを定義しないと説明する。IANAのメールボックス名属性登録簿は場所の役割を発見可能にしても、時刻管理の全工程にはならない。$istrustedも判断を運べるようにするが、監査と訂正の全工程にはならない。

送信者確認を「依頼どおり行動してよい」に広げない

RFCが扱うのはFromの名前とアドレスの真正性だ。本文中の全主張、リンク先、添付ファイル、支払いの必要性、受信者の権限までは保証しない。本物の組織から来たメールでも、内容が間違っていたり、内部不正に使われたり、受信者が実行すべきでない依頼を含んだりする。

UIの言葉はこの差を守ることも消すこともできる。「サーバーが送信者の身元を確認」は範囲を保つ。「このメールは安全」は本文と行動まで保証を広げる。確認印を送金ボタンの横に置けば、利用者は身元情報を取引承認のように感じるかもしれない。キーワードには、その画面設計の選択は残らない。

全クライアントにサーバーの検証を繰り返させる必要はない。集中した判断には効率と一貫性があり、端末から届かない証拠も扱える。必要なのは責任の区分だ。サーバーは身元判断、クライアントは説明方法、利用者または後段の仕組みは行動判断を担う。前の判定を後の権限へすり替えてはならない。

Why BTW Media Existsが求めるのは、観測事実と魅力的な物語を分ける姿勢だ。ここで観測できるのは、特定のサーバーが特定のポリシーの下で特定のメッセージに印を付けたということ。「メール全体が安全」は追加の証明を要する解釈である。

サーバーを信頼できるかどうかも、判断内容に含まれる

RFC 9979のセキュリティ節は、サーバーを透明な背景にしていない。これらのキーワードと属性の利用・解釈は、クライアントと利用者がIMAPサーバーを信頼できることに依存する。侵害された、または悪意あるサーバーは状態を誤って設定し、利用者を欺ける。つまり$istrustedは、発行主体から独立した証人ではない。

画面写真が証明するのは、ある時点で何かが表示されたことまでだ。真正性を検討するには、表示を受信状態、状態を出したサーバー、判断エンジンの版、採用した証拠区分へつなぐ必要がある。サーバー侵害を調べているなら、その期間の印は独立証明ではなく争われる資料として扱うべきだ。

共有状態には配送遅延もある。サーバーで削除され、接続中の端末は更新し、オフライン端末は古いキャッシュを持ち、既出の通知は人の記憶に残る。RFC 9979は各実装のキャッシュや表示寿命を約束しない。「サーバー状態を直した」と「全ての可視表示が消えた」は別々に確かめなければならない。

The Policy Mirrorの視点では、ポリシーは実際の制御面を映す必要がある。結論を制御するサーバー、伝播を制御する同期とキャッシュ、表現を制御する製品、行動を決める人または後段システム。この四つを一つの緑色表示に畳むと、訂正時の責任者が見えなくなる。

訂正記録は本文の複製でなく、判断の移動を残す

必要なのは監視用の巨大アーカイブではない。本文、認証情報、鍵、完全な認証ログ、細かな閲覧行動を集めれば、新たな高価値データベースになる。問いは限定できる。サーバー判断はどの画面に届き、判断が変わったとき何が訂正されたか。

記録は六つの面に分けられる。第一に、メールボックス内だけで通用するオブジェクトIDまたはソルト付きダイジェスト、配送時刻、アカウント範囲でメッセージを指す。本文は複製しない。第二に、判断サービス、証拠区分、ポリシー世代、時刻、信頼度帯を残し、生の秘密は除く。

第三に、$istrustedを誰がいつ設定したか、状態版、同期範囲、後の削除・置換と理由区分を残す。第四に、クライアントの系統と版、使った意味ラベル、アクセシビリティ上の表現、既知の初回・最終表示時刻、説明を開けたかを粗粒度で残す。

第五に、運用者が正当に把握できる重要な結果だけを区分で記録する。たとえば表示中に高リスク手順が始まったかであり、本文や無関係な行動は記録しない。第六に、調査主体、変更後の結論、影響した状態期間、通知先、是正、異議申立て、完了責任者を残す。

記録は不明点を不明のまま保てなければならない。サーバーはビットを消しただけで画面の消去を断言しない。クライアントはキャッシュした印から証拠を捏造しない。事故対応者は時刻と表示を結べないのに因果を断言しない。滑らかな物語より、検証可能な境界が重要だ。

これはDaniel Kadeの運用提案であり、RFC 9979の必須フィールドではない。プロトコルの意味を変えず、その意味が現実を移動した履歴を見えるようにする。

情報源