要約

  • RFC 9979が登録するScheduledは、将来送信する予定のメッセージを保管するメールボックスを識別する。そこに存在することは、送信処理、リレーの受理、配送完了の証拠ではない。
  • $istrustedはサーバーの高信頼度判断、$unsubscribedは試行記録、$newは注意を向ける指示である。共通語彙を外部結果へ昇格させないため、設定主体と実行履歴を併記する必要がある。

午前九時に送るはずのメッセージが、八時五十五分にはScheduledメールボックスに入っていた。監査画面はその件数を「予約送信」と表示し、別の集計表は九時を過ぎると「送信済み」に振り替えた。しかし送信ジョブは停止していた。メッセージは正しい場所にあり、どこにも送られていなかった。

これは実在する製品や障害を述べたものではない。境界は2026年5月のIETF Informational文書、RFC 9979から導かれる。同RFCは複数実装ですでに使われていた17個のIMAP/JMAPメッセージキーワードと3個のメールボックス名属性について、意図する意味を定め、名前の衝突を避けるため登録した。共通語彙は相互運用性を作るが、個々の状態を認証しない。

IANAのIMAP/JMAP Keywordsレジストリには、名前、共有・私有の別、用途、範囲、参照仕様が並ぶ。IMAP Mailbox Name AttributesにはMemos、Scheduled、Snoozedが加わった。登録行は名前を誰が使っても同じ意味にするための台帳であり、あるサーバーが正しく判定したという認定書ではない。

RFC 9979の状態は、発生主体も効力も一様ではない。配送時にサーバーが設定するもの、利用者の操作を受けてクライアントが設定・解除するもの、表示上の助言にとどまるもの、自動処理を起こし得るものがある。トークンだけを同期すると、結果は共有されても、誰のどの判断だったかが消える。

土台となる契約も狭く設計されている。RFC 5788はキーワード登録制度を作り、RFC 8457は$Importantと特別用途属性の先例を示した。RFC 9051はIMAP4rev2を、RFC 8621はJMAP Mailを定める。二つのプロトコルで同じ状態が見えることは整合性であり、分類根拠の独立検証ではない。

添付ファイルの二つのキーワードは、欠落と否定の違いを明確にする。$hasattachmentと$hasnoattachmentは同時に成立してはならない。だが前者がないだけでは、添付がないとは言えない。解析そのものが未実施かもしれないからだ。「あり」「解析してなし」「不明」の三値を、紙クリップの有無だけで二値化してはいけない。

JMAPのhasAttachmentは同じ情報を反映しなければならない。IMAPとJMAPの値が一致すれば、同期の一貫性は確認できる。それでも、どのMIMEパーサーがどの版をいつ調べたか、後の変更で判定が古くなったかは別の記録である。同じ誤りが全クライアントに広がれば、表示は完全に一致する。

メモ機能は二者関係を持つ。$memoはノート自身のメッセージに付き、$hasmemoは注釈対象のメッセージに付く。作成と削除では両方を更新する。RFC 8474のオブジェクト識別は関係を安定させるが、二つの書き込みの途中で失敗すれば片側だけ残り得る。現在値から途中の失敗は復元できない。

$istrustedは利用者の判断に直結する。RFC 9979は、表示名とメールアドレスをサーバーが高い確度で検証したという助言的な印として定義する。誤って付与すれば詐欺メールを信じさせるため慎重さが必要であり、SPF、DKIM、DMARCが通っただけで設定してはならない、と明記する。

これは既存の認証を否定する規則ではない。RFC 7208のSPFはエンベロープ識別子に対するホストの許可を扱う。RFC 6376のDKIMはドメイン署名と選択されたメッセージ内容を結ぶ。RFC 9989のDMARCは可視のFromドメインとの整合と受信側への方針要求を扱う。いずれも表示名の人物、業務権限、リンクの安全、内容の真実までは自動的に証明しない。

「高い確度」の共通アルゴリズムや数値閾値は定められていない。各サービスが追加の知識を使える代わりに、断定の来歴を持つべきである。判定サーバー、ルール版、証拠種別、信頼度、時刻、有効期限、撤回条件を保護された台帳に残す。画面の印は簡潔でもよいが、その視覚的な強さは証拠範囲を超えてはならない。

セキュリティ節は信頼の根をIMAPサーバーに置く。サーバーが侵害され、または悪意を持てば、キーワードを操作して利用者を誤導できる。五台の端末が同じ$istrustedを表示しても、五つの独立観測ではない。一つの主張が忠実に複製されたにすぎない。

購読解除では、能力、試行、完了が分かれる。$canunsubscribeは、準拠したList-Unsubscribeが存在し、サーバー固有の評判確認を通ったため操作を提示できる、という状態である。RFC 8058はワンクリックの信号方式を定める。ボタンを安全に出せることと、解除が終わったことは別だ。

$unsubscribedは利用者が解除を試みた記録であり、成功確認がなくても設定できる。ただし明確に失敗した場合は設定できない。したがって必要なのは「実行可能」「試行」「確定失敗」「結果不明」「完了確認」という状態列である。日常語として完了形に見える名前を、そのまま法的・業務的な完了に使うべきではない。

$newは時刻ではなく注意の状態だ。古いメッセージがsnoozeから戻ったとき、再び目立たせるため設定できる。$notifyは利用者設定が許す場合に通知を提示するようクライアントへ求める。要求、実画面、閲覧、反応は四つの異なるイベントである。

Snoozedは一時的に注意から外したメッセージの保管場所を示すだけで、目覚まし機構や画面を定義しない。Scheduledも将来送信予定の置き場所を示すにすぎない。そこから先には、スケジュールの発火、送信試行、リレー応答、最終配送という別々の受領証がある。

$followedと$mutedは排他的で、両方あればfollowedを優先する。この規則は実装の挙動を収束させるが、矛盾の原因は説明しない。RFC 9979は、侵害されたアカウントで攻撃者が重要な会話をmuteできる点を挙げ、正当なアクセスを回復した際にmute操作を確認または戻すよう促す。

パスワードの再設定だけでは、攻撃者が同期済み状態に残した意思を消せない。復旧作業はアカウント所有権だけでなく、通知、mute、follow、ルールの履歴も対象にしなければならない。

RFC Editorの情報ページとerrata検索は文書の版と状態を確かめる資料であり、実装、導入、メッセージ判定、事故、配送結果の証明ではない。著者の所属も採用実績にはならない。

Heng LuのReality Layersに沿えば、登録上の意味、ローカル規則、サーバー主張、同期状態、クライアント表示、人の理解、自動処理、外部結果を分けられる。Running-Code Primacyは名前より実行された判定と効果を優先する。Minimum Initial Specificationは、共通部分を名前と決定的な衝突規則に抑え、その先を責任あるローカル判断として残す。

補助台帳には、メッセージ・スレッド・メールボックスの識別、正確なキーワード、設定・解除できる主体、サーバーとクライアント、プロトコル、前後値、規則または利用者操作、証拠参照と信頼度、時刻と期限、同期、実際の表示、利用者設定、実行した処理、外部応答、訂正を残す。機密な判定材料を公開せずとも、方法の存在と責任者は証明できる。

RFC 9979は、状態を小さな語で運ぶ。その小ささを守ることが、結果を捏造しないための条件である。

出典