要約

  • RFC 2919 は、投稿アドレスや処理ホストが変わっても論理的なリストを追える識別子を定義した。
  • List-Id の操作は大文字小文字を区別しない一致だけである。所属を示すが、真正性、会員資格、投稿権限は証明しない。
  • RFC 2369 の操作フィールドと RFC 8058 のワンクリック解除は別系統であり、状態変更には署名、推測困難な状態、利用者の同意が要る。

壊れたのはフィルターだった

運用者の議論リストが新しい管理基盤へ移る。アーカイブも主題も続くが、投稿の入口は変わる。旧アドレスで選別していたクライアントだけが、同じリストを見失う。

入口を主体と誤認したからである。表示名は模倣でき、件名の接頭辞は編集できる。RFC 2919 は、ホスト、処理ソフトウェア、投稿ポリシーの変更で投稿先が変わると指摘し、実際の配送機械から独立したキーを求めた。

動作の語彙と名前は別だった

RFC 2369 は、ヘルプ、購読、解除、投稿、管理者、アーカイブを別々の URL フィールドにした。代替 URL には優先順があり、投稿不能なリストも表現できる。

それらは「何をどう実行するか」を示す。長く存続する対象の名前ではない。投稿窓口がモデレーターに移っても、解除サービスが更新されても、直ちに新しい共同体が生まれるわけではない。RFC 4021 が List-ID と操作フィールドを別々に登録したのは、この区別を固定するためだった。

ドメインは命名権を委譲した

RFC 2919 の管理された識別子はドメイン名前空間を基礎にする。ドメインまたはサブドメインの権利者だけが、その空間で識別子を作れる。

ただしホスト名に似た形は配送命令ではない。識別子はリストを処理する機械と無関係でよい。接尾部が示すのは作成権限であり、DNS レコード、SMTP の行先、受信フィールドの真正性ではない。

ドメインを持たない所有者には localhost の非管理空間がある。日時と乱数は衝突を減らすが、世界的な一意性は保証しない。参加の余地と権威の保証を混同しない設計である。

変わらないものを一つの比較に限定した

フィールドには説明文と区切られた識別子を置ける。比較対象は識別子だけで、大文字小文字を区別しない。説明を直しても同じリストとして扱える。

識別子を変えれば、クライアントは別のリストとみなすべきである。処理ホストの交換では維持し、非管理空間から管理空間への移行や目的の大幅な変更では退役を検討する。標準は合併や改組の正当性を判断せず、管理者の選択を観測可能にする。

配布メールと明確に関係するコマンド応答にはフィールドを入れるべきで、一通に一つだけ、生成者は利用者でなくリストソフトウェアである。所有者、会員、現行投稿先を問い合わせる機能は定義されていない。

入れ子はマーカーの保管を試した

親子関係を理解する下位リストは、親の List-Id を置き換えてはならない。予期しない送信元から来たフィールドは通過させるべきでない。再配布後にどのリストを表すかを守る規則である。

それでも署名ではない。設定は誤り得るし、フィールドは偽造できる。RFC 2919 は偽造が自動処理を壊し得るため、真正性の指標にしてはならないと明記する。

状態変更は別の証拠を要求した

RFC 8058 は、スキャナーの自動アクセスが誤解除を起こし得るため、ワンクリック解除を HTTPS POST として区別した。送信者は二つの解除フィールドを、それらを覆う有効な DKIM 署名とともに提供する。

URL は対象リストと受信者を選ぶ状態を持ち、推測困難な要素を含むべきである。受信側は cookie や既存の Web 認可を付けず、利用者の同意なしに POST しない。

List-Id は分類、署名は操作指示、状態は購読、同意は変更権限を担当する。識別子が削除キーへ昇格したのではない。

狭い権限が継続性を作った

現在の IANA メッセージヘッダーレジストリ も、識別、RFC 2369 の操作、ワンクリック信号を別の恒久フィールドとして掲載する。

List-Id の功績は、リスト全体を一つのヘッダーで支配したことではない。ホスト移転を越えて一属性だけを安定させたことにある。公式資料は現在の普及率を示さない。同じ識別子は所有者や目的の不変を証明せず、新しい識別子も退役、移行、転換、誤りのいずれかである。継続性の主張は見えるが、正当性は別途必要だ。