メーリングリストとは｜ネットミリしら

メーリングリストとは

メーリングリストは、一つの宛先へ送ったメールを登録者へ配信し、グループで情報共有する仕組みです。一般にmailing list（メーリング・リスト）、略してMLと呼ばれます。

投稿者が登録者全員のアドレスをToやCcへ並べるのではありません。リスト用アドレスへ一通を投稿し、list exploder（リスト・エクスプローダー）と呼ばれる機能が、登録者ごとの配送を作ります。

リスト用アドレスは「全員を表す別名」だけではありません。参加資格、投稿できる人、審査、件名加工、アーカイブ、配送失敗、解除を管理する仲介点です。

投稿を受け付ける入口、方針を適用する仲介機能、受信する登録者を分ける返信や配送失敗もリストの規則へ戻る

Poster投稿者

リスト用アドレスへ一通を送る。登録者だけ、承認済みの人だけなど投稿条件がある。

Moderatorモデレーター

保留された投稿を確認し、承認、拒否、差し戻しを行う。すべてのリストにいるとは限らない。

List Mediatorリスト仲介機能

名簿、投稿方針、ヘッダー付加、件名加工、配送、解除、失敗処理を担当する。

Subscriber登録者

配信を受ける人。投稿権限と購読権限は同じとは限らない。

Archiveアーカイブ

過去の投稿を保存・検索する。公開、登録者限定、保存しないなど方針が分かれる。

Bounce Handler配送失敗管理

無効宛先や一時失敗を追跡し、一定条件で配信停止や管理者通知を行う。

図2告知専用リストでは少数だけが投稿し、議論用リストでは登録者同士が返信を重ねます。用途で権限を変えます。

RFC 2919のList-IDヘッダーは、表示名や投稿アドレスが変わっても、リストを識別できる値を提供します。メールアプリの振り分け規則は、件名の接頭辞よりList-IDを使うと安定しやすくなります。

List-Post、List-Help、List-Subscribe、List-Unsubscribeなどのヘッダーは、投稿先や管理操作を示します。本文末の説明だけを機械で解析するより、メールアプリが安全な専用操作を提示しやすくなります。

「返信」が元の投稿者へ向くか、リスト全体へ向くかは、From、Reply-To、List-Postとメールアプリの実装で変わります。リストがReply-Toを書き換える場合もあります。画面のボタン名だけで送信範囲を決めず、送信前にToとCcを確認します。

個人宛ての内容、連絡先、未公開資料を全体へ返信する事故があります。反対に、議論の回答を投稿者だけへ返すと他の登録者には共有されません。目的が「個別連絡」か「議論の継続」かを先に選びます。

リストは件名へ接頭辞を付け、本文へ案内や解除情報を追加することがあります。これらの変更は、署名対象のヘッダーや本文を検証するDKIMを壊す場合があります。転送された配送ではSPFの接続元も元の送信者と異なります。

DMARCが厳格な送信ドメインでは、Fromとの整合が取れなくなり、登録者側で拒否されることがあります。リスト運営は、本文変更を抑える、適切な再署名を行う、Fromの扱いを方針化するなど、相互運用を設計します。

解除は、専用の管理画面、解除アドレス、List-Unsubscribeヘッダーなどから行います。投稿用アドレスへ「解除してください」と送ると、全登録者へ配信される場合があります。

RFC 8058のone-click解除は、対応する大量配信で、DKIM署名された所定のヘッダーを使ってメールアプリから解除要求を送る方法です。すべての議論用リストに同じ方式が必須という意味ではありません。

二つのリストを相互登録したり、自動返信がリストへ戻ったりすると、同じメールが繰り返されます。List-ID、配送済みを示す記録、Auto-Submittedなどを使い、重複と自動応答を抑えます。

バウンスメールは登録者へ再配信せず、専用のreturn-pathへ集めます。一時的失敗を直ちに退会扱いにせず、宛先ごとの失敗回数や期間を見て停止します。

投稿がWeb上で公開・検索されるリストでは、メールアドレス、署名、添付、引用した過去文も長期間残り得ます。登録前にアーカイブの公開範囲と保持期間を確認し、公開されて困る個人情報や機密を投稿しません。

メーリングリストは配送装置であると同時に共同体の記録です。誰が読めるか、誰が投稿できるか、どこへ残るかを一組の方針として確認します。