要約
draft-ietf-mailmaint-expires-06はメールのExpiresを一般化するが、「有効性を失う」の意味を一つに固定しない。日時は作成者の申告であって、検証済みの事実ではない。- メールソフトはその項目だけを理由に拒否・破棄してはならず、メールボックス所有者が意図的に設定しない限り削除すべきでもない。
- 画面から薄くすること、保存場所を移すこと、証拠として保持すること、最後に消去することは別の状態である。一語の「期限切れ」で統合してはいけない。
読む価値が終わっても、記録の価値は始まる
イベント開始後に届いた案内は、参加判断には遅い。しかし、主催者が何時にどの条件を通知したかを示す記録にはなる。ワンタイムコードの利用期限が終わっても、不正アクセス調査では送信時刻と宛先が重要だ。情報の鮮度と記録の寿命は同じではない。
Mail Maintenance WGの第06版は、X.400変換由来の Expires を一般のインターネットメールへ広げる。構文は日時一つで、同じ項目を複数入れてはならない。作成者は、その時刻を過ぎるとメールが「有効性を失う」と示す。
しかし草案は、有効性をそれ以上厳密に定義しない。既存用途を横断する合意がないからだ。販促、予定、定期通知、短命な認証情報では、期限が指す業務結果が異なる。
文書はProposed Standardを目指す有効なInternet-Draftで、RFC Editor queueにある。まだ公開RFCではなく、実装普及率の証明でもない。
拒否、非表示、削除は同じ操作ではない
草案は、期限後のメールを目立たなくしたり、通常表示から外したり、利用者に整理機能を提供したりする余地を残す。その一方で、Expires だけを根拠に拒否または破棄してはならないと定める。過去日時のメールも、所有者が意図的に設定していなければ削除すべきではない。
配送拒否なら受信自体が成立しない。破棄なら受け取った後に見えなくなる場合がある。非表示は画面の状態で、移動は保存場所の変更だ。主コピーを削除してもジャーナルやバックアップは残り得る。最終消去だけが復元可能性を断つかもしれない。
したがって監査記録は「期限処理済み」では足りない。実行部品、ローカル規則、所有者の同意、可逆性、残存コピーを区別する必要がある。
署名された日付にも命令権はない
DKIMは、署名対象の内容について責任を負うドメインを確認する助けになる。日時が正確か、善意か、受信側を拘束するかまでは証明しない。真正な発信元も時計を誤り、別の利害を持つ。
草案が挙げる攻撃は、その利害を示す。過去日付を付けて迷惑メールの可視性と通報を減らし、学習データを歪める。極端に近い日時で焦りを作り、後の苦情を難しくする。遠い未来にして受信箱に長く残そうとする。
送信者が値を選ぶ以上、詐欺判定や証拠破棄のトリガーにはできない。本人確認と処分権限は別である。
受信者側には四つの台帳が要る
第一は申告で、元の値、解析結果、送信者・署名の証拠を持つ。第二は表示で、通常、降格、まとめ、非表示を記録する。第三は保存で、現用、復元可能領域、アーカイブ、バックアップ、最終消去を区別する。第四は証拠用途で、取引、契約、セキュリティ、迷惑行為、法的保全を扱う。
ある層の変化を別の層へ転記してはいけない。見えないメールは検索可能かもしれない。箱から削除されても監査ジャーナルにあるかもしれない。業務上の期限切れでも事件記録として保持される。
実際の業務期限との比較も必要だ。ヘッダーの時刻と、予約システム、決済台帳、会議管理、認証サーバーが持つ期限は一致するとは限らない。前者はメッセージ作成者が選んだ表示上の手掛かりであり、後者は別のシステムが実行する状態遷移である。メールが期限内と表示されても申込みが既に閉じている場合があり、メールが期限切れでも返金請求期間は続いている場合がある。受信側の自動化は、ヘッダーを業務システムの状態証明として再利用してはならない。
時刻の解析にも観測点が要る。元のタイムゾーン、正規化した時刻、解析ライブラリの版、受信側時計との差を残せば、境界付近の判断を再現できる。値が不正なら「期限切れ」に丸めず、解析不能として扱う。曖昧さを捨てることは、正確さを得ることではない。
こうした分離は利用者にも説明しやすい。「表示を整理する日時」と「自動的に復元不能になる日時」を同じラベルで示さず、それぞれの根拠と変更方法を見せるべきだ。利用者が理解できない既定値は、意図的な設定とは呼べない。
管理者向け画面でも同じ区別を保ち、件数だけでなく結果別の内訳を示す必要がある。便利さの指標が証拠喪失を覆い隠してはならない。
最小限のローカル受領記録には、メッセージIDまたはダイジェスト、受信時刻、元の値と解析時刻、利用できる送信者証拠、規則版、所有者同意、表示操作、保存操作、復元期限、最終消去結果を置ける。これは運用提案であり、新しいメールプロトコルではない。
既定値の選び方も重要になる。販促メールなら、まず優先度を下げ、次に利用者が確認できる復元領域へ移す設計が合理的だ。アカウント警告、決済、契約、苦情では保存を既定にする方がよい。誤って残すコストと誤って消すコストが非対称だからである。
規則が送信ドメイン、フォルダー、メッセージ種別ごとに異なるなら、受領記録には実際に一致した条件も必要だ。「自動整理規則を実行した」という名前だけでは、なぜその一通が対象になったか説明できない。利用者が後から自動処理を無効にしたとき、過去に移動したもの、まだ戻せるもの、既に消去されたものを一覧できなければ、ローカルな選択は実質的に取り消せない。
さらに、同じメッセージがウェブ画面では期限切れ、携帯では通常表示、監査ゲートウェイでは長期保存となることがある。この差は直ちに不具合ではない。それぞれが異なる役割と規則を持つからだ。危険なのは、各製品が自分の結果を説明せず、どこかに一つの世界的な「メール状態」があるように見せることである。
相互運用は小さく、将来判断はローカルに
RFC 1327の Expiry-Date、RFC 2156の写像、RFC 4021の「not for general use」という登録を経て、第06版は一般利用へ進める。系譜は項目を説明するが、送信者へ継続的な支配権を与えない。
共通仕様は名前、構文、限定的意味を揃えればよい。表示や保存方針は利用者と実装が選べる。採用しない実装を無効扱いする必要はない。
結果を示すのは動くコードだ。受理したか、隠したか、保存したか、復元できたか。仕様書の状態、項目の存在、署名成功のどれも、その結果そのものではない。
Sources
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加