要約

  • IESG は 2026 年 5 月 8 日、draft-ietf-mailmaint-expires-06 を Proposed Standard として承認した。作成者はメッセージが有効性を失う日時を示せるが、その後の処理を一つに固定する仕様ではない。
  • メールソフトは Expires だけを理由に受信拒否や破棄をしてはならず、所有者が意図して設定していない限り、過去の日付を持つメッセージを削除すべきではない。表示変更と恒久削除の間には、受信側の判断が残る。

期限は事実ではなく、発信者の主張である

Expires の構文は簡潔だ。RFC 5322 の date-time を一つ置き、メッセージ作成者は同じフィールドを複数入れてはならない。期間限定の販売、イベント告知、ソーシャル通知、定期的な案内などが想定されている。

こうした情報に時間の境界があることは自然だ。終了した催しを新着と同じ強さで見せ続ける必要はない。古い週報を現在の指示と同列に並べれば、読者の注意を浪費する。期限情報は、画面の優先順位を整える材料になり得る。

ただし、その日時を選ぶのは発信者だ。案内を目立たなくしたい組織も、苦情が検索で見つからない方が都合のよい相手も、フィールドを書ける側にいる。したがって、値が構文上正しいことと、受信者にとって妥当であることを混同できない。

承認された文書は、期限を過ぎたメッセージが「有効性を失う」と定める。それ以上の精密な規範的意味は加えていない。削除、非表示、拒否、撤回のどれか一つに結び付けられるだけの合意も、実装の一様性もないからだ。この曖昧さは欠陥ではなく、権限を作り過ぎないための境界である。

長い実装史を一つの命令に塗り替えない

IESG の承認通知は 2026 年 5 月 8 日 22:11 UTC に出された。文書は Mail Maintenance Working Group の成果で、Standards Track の Proposed Standard を意図している。本稿の証拠凍結時点では、第 06 版が RFC Editor queue に入り、最初の編集者を待ち、IANA の処理状態は RFC-Ed-Ack だった。

IANA の Message Headers registry は、メール用 Expires を standard として掲載し、この Internet-Draft を参照している。Netnews 用の同名フィールドは別の項目だ。名前が同じでも、異なるメッセージ環境の意味を無条件に移植できるわけではない。

歴史的には、X.400 との写像や過去のメールヘッダー登録にも期限の概念が現れる。既存製品が採った挙動は同じではなかった。今回の仕様は、その差を後から一つの正解に見せかけない。交換可能な最小の意味を定め、危険な既定動作を禁止する。

標準の役割は、すべての製品に同じ画面を作らせることではない。共通部分を狭く定義し、その先の決定を、結果を引き受ける場所に残すことだ。実装は薄く表示しても、検索対象から一時的に外しても、所有者向けの整理機能を提供してもよい。だが、その自由は送信者の支配権を意味しない。

読み手の処理を四つに分ける

メールアーキテクチャの用語では、送信側は Message Creator、受信側の処理主体は Message Reader とされる。Reader はストレージエージェントの場合も、ユーザーエージェントの場合もある。

ここで少なくとも四つの出来事を分ける必要がある。第一はフィールドの解析、第二は表示の抑制、第三は削除状態への移行、第四はデータの恒久的な除去だ。最初の二つは同じ瞬間に起き得るが、だからといって後半まで自動的に正当化されない。

仕様は、Expires だけを理由にメッセージを拒絶または破棄してはならないとする。過去の日付が入っていても、メールボックス所有者が意図的に設定していない限り削除すべきではない。

IMAP4rev2 では、この区分が操作として見える。メッセージに \Deleted フラグが付き、その後の EXPUNGE が該当メッセージを恒久的に取り除く。UID EXPUNGE は UID で対象を絞れる。すべての保存基盤が IMAP とは限らないが、同等の意思決定と結果は追跡可能でなければならない。

「期限切れなので一覧で弱めた」と「期限切れなので記録を消した」の間には、所有者の方針が必要だ。その方針を省略すると、可逆的な注意配分と不可逆的な証拠処分が一つの便利機能に隠れてしまう。

DKIM が証明する範囲

DKIM 署名は、署名ドメインが選択されたメッセージ素材について一定の責任を引き受けたことを検証する手段になる。Expires が署名対象なら、条件を満たす改変の検出にも役立つ。

しかし、署名は日時の適切さを証明しない。受信者の保管目的に合うことも、法的な保存要件も、削除への同意も証明しない。発言者を確かめる仕組みが、その発言者の権限まで拡大するわけではない。

ここには、インターネット運用で繰り返される誤りがある。機械可読な値や暗号的に帰属できる値は、しばしば「実行してよい命令」に見える。実際には、証拠が示す事実、判断を行う主体、結果を負担する主体を別々に確認しなければならない。

期限フィールドを自動化に使うなら、どの規則が作動したかを残すべきだ。送信者の日時を読んだこと、ローカルな表示方針を適用したこと、所有者の整理設定が削除を選んだことは、それぞれ別の証跡である。

悪意ある日時も構文上は正しい

脅威分析は、作成者が過去、近い将来、遠い将来のどの日時でも選べる点を直視する。受信側に追加知識がなければ、その値が正確か、善意かを推定できない。

過去の日付は、迷惑メールを通報される前に見えにくくするために使われ得る。ごく近い期限は、相手が行動した後で苦情や指示を探しにくくするかもしれない。遠い将来は、受信トレイでの長期的な注目を狙う材料になり得る。そのため、Expires 単独で「望まれたメール」や「詐欺メール」を判定するのは不適切だ。

有用な表示は可能である。「メッセージが申告した期限を過ぎた」と示せばよい。これは観測した証拠の説明だ。「削除して安全」と表示するなら、別のローカル判断と、その責任主体が要る。

送信者の時刻は入力であって、結論ではない。受信者側の履歴、認証、メッセージ種別、所有者設定を組み合わせても、最後の権限がどこにあるかは変わらない。

情報源