要約

  • RFC 2369が標準化したのは、メールソフトがリスト操作の入口を見つける方法であり、登録や解除が完了したことの証明ではない。
  • 優先順を持つ複数URL、利用者確認、入れ子リストでのヘッダー差し替えは、告知された経路、選択、権限、送信、サーバー更新、後続配信を別々に検証すべきことを示す。

同じ画面の背後に異なる管理系

当時のメーリングリストには、それぞれ固有の命令作法があった。-request 宛てにメールを送るもの、件名に特定の語を書くもの、本文を解析するもの、ウェブフォームを使うもの。利用者から見れば目的は同じでも、操作は一覧ごとに再学習しなければならなかった。

RFC 2369は管理システムを一つに統合しようとはしなかった。代わりに、配信メールへ List-Help、List-Unsubscribe、List-Subscribe、List-Post、List-Owner、List-Archive を載せ、既存システムへの案内を共通化した。対応するメールソフトはメニューやボタンを作り、非対応のソフトは従来どおりメールを扱える。動いている実装を止めず、任意導入で表面だけを揃える設計である。

ただし、その表面が持つ証言力は限定されていた。解除ヘッダーが示すのは、リスト処理系が解除用として広告したURLである。利用者が同意したことも、要求が送られたことも、会員データが書き換わったことも、そのヘッダー単独では分からない。UIは経路の投影であり、台帳の読出しではない。

URLの順序が語るもの

一つのフィールドには、山括弧で囲んだURLを複数並べられた。左から右が優先順で、クライアントは最初に対応できる方式を選び、それが失敗したときに次を試す。ウェブを先に置き、メールだけを使える人のために mailto を残す、といった構成が可能だった。

この順序は、処理結果ではなく入口選択の方針である。ブラウザーがページを開けても、認証や追加確認が必要かもしれない。メール草稿が作られても送信されないかもしれない。リスト管理サーバーへ届いても、送信元アドレスの相違、確認待ち、既に変化した状態によって拒まれ得る。代替URLは障害時の探索路であって、取引記録ではない。

仕様が変数置換を認めなかった点も重要だ。利用者のアドレスなどをクライアントが埋め込まなければ成立しない命令は表現せず、ヘルプやフォームに委ねた。多機能な命令言語より、多くの普通のクライアントが安全に実装できる最小機能を選んだのである。

mailto が止めた自動実行

同じ月のRFC 2368によれば、mailto URLは対象へ即時通信するのではなく、宛先や件名、本文を埋めた編集可能なメッセージを作る。利用者は修正して送ってもよいし、送らずに破棄してもよい。

RFC 2369はこの挙動を人間の権限境界にした。クライアントは動作前に利用者へ確認機会を与え、メールによる命令では正しい形式の草稿を用意しても自動送信しないことが推奨された。メタデータが意図を準備することと、本人が権限を行使することは分離された。

したがって証拠は段階ごとに読む必要がある。フィールドを解釈できた、草稿を生成した、利用者が送信した、配送系が受理した、リスト管理系が適用した、その後に配信が止まった――これらは同じ出来事の別名ではない。

入れ子のリストが経路を差し替える

入れ子構成では、サブリストは親のヘルプ、登録、解除、管理者フィールドを取り除き、自身のものへ置き換える。一方、アーカイブや投稿には異なる継承規則がある。最終受信者が見るメッセージは複数のリスト処理系を通っており、表示された解除入口が配送全体のどの層を制御するかは自明ではない。

エンドユーザーがこれらのフィールドを生成してはならず、リスト処理系は利用者由来のものを通過させない、という規定もあった。これは偽装の余地を減らすが、認証そのものではない。仕様はメールヘッダーの偽造や重複を前提に注意を促していた。クライアントが受け取るのは配送経路からの入力であって、運営者の独立した身元証明ではない。

同じ理由で、名称を成果と取り違えてはいけない。List-Post は投稿経路を示しても配信を約束せず、NO なら投稿不能である。List-Archive は所在を示しても完全性を証明しない。List-Owner は連絡経路であって応答保証ではない。登録と解除も、状態ではなく要求の入口である。

自動取得が突きつけた後年の教訓

2017年のRFC 8058はRFC 2369を更新してはいないが、境界の意味を鮮明にした。セキュリティー用スキャナーがURLを自動取得するようになると、リンクを読むだけで意図せぬ解除が起き得た。そこで後の仕様は専用のHTTPS POSTシグナルを定め、利用者の同意、対象ヘッダーへのDKIM保護、限定された要求条件を求めた。

人に便利な入口が自動化にも触れられるようになると、「見つけた」「開いた」「実行を許可した」の区別が再び必要になる。RFC 2369のボタンは役立つ表示だったが、受領証ではなかった。

小さな標準が残した大きな規律

RFC 2369は、互換性のないリスト管理系を壊さず、操作の発見可能性を高めた。メールだけの利用者を残し、部分実装を許し、困ったときのヘルプを共通の逃げ道にした。公開面を最小限に規定し、最終処理を各稼働システムへ残したからこそ採用できた。

正確な証拠列は、使用可能なフィールド、配送中の保全、対応方式の選択、利用者確認、要求送信、対象サービスの受理と適用、その後の会員・配信状態へと続く。クライアントは方式を選べた時点で「解除操作あり」と表示できる。しかし「解除済み」と言えるのは、権限を持つリスト管理系の結果を得た後だけである。