メーリングリストは、プロジェクト内でのコミュニケーションに必要不可欠なものです。 ウェブページ以外にユーザーに見せるものがあるとすれば、 まず最初はそのプロジェクトのメーリングリストとなるでしょう。 しかし、メーリングリストに参加する前に、 ユーザーはまずそのメーリングリストのインターフェイス (たとえば "メーリングリストに参加する" など) に出会うことになります。 ここから、次の「メーリングリスト第一法則」が得られます。
メーリングリストの管理は、手作業で行うのではなく、 専用のソフトウェアを使用すること。
いきなりそんなことを言われても驚きますよね。 メーリングリストの管理用にわざわざソフトウェアをセットアップするなんて、 ちょっとやりすぎのように感じられるかもしれません。 小規模で流量の少ないメーリングリストは手動で管理するほうが楽に見えます。 参加申し込み用のアドレスをひとつ作成してそれをあなた宛てに転送されるようにしておき、 届いたメールの内容を見て、アドレス一覧 (おそらく単なるテキストファイル) に追加したり削除したりするだけです。 これ以上にシンプルなやりかたなんてないでしょう?
みんなが満足するレベルでメーリングリストの管理を行うということは、 思っているほど簡単なことではありません。 メーリングリストの管理というのは、 単にユーザーを登録したり削除したりするだけの話ではありません。 スパムよけのために投稿内容をモデレートするようにしたり、 複数の投稿をひとまとめにした形式でメールを配信するようにしたり、 メーリングリストやプロジェクトに関する情報を自動返信するようにしたり といったさまざまな内容があります。 参加用のアドレスを人手でチェックするというだけでは、 最小限の機能しか提供することができません。 そしてその最小限の機能でさえ、ソフトウェアに任せるのに比べると 信頼性や即時性に欠けるものとなるでしょう。
いまどきのメーリングリスト管理用ソフトウェアなら、 少なくとも次のような機能が搭載されているはずです。
ユーザーがメーリングリストへの参加を申し込むと、 すぐに自動返信のメッセージを受け取ります。 そこには、参加しようとしているメーリングリストの情報や メーリングリストソフトウェアへの指示の出し方、そして (最も重要な項目として) リストからの退会のしかたなどが書かれています。 この自動返信の内容はカスタマイズすることが可能です。 ここにはプロジェクトのウェブサイトや FAQ の場所といった情報を含めることができます。
ダイジェストモード (「まとめて配信」モード) にすると、参加者が受け取るメールは１日に１通となります。 その日に投稿されたすべてのメールの内容が１通にまとめて送信されるわけです。 積極的に参加するわけではないが、 大まかな話の流れは追いかけておきたいといった人たちには ダイジェストモードがお勧めです。 これを使用すると、頻繁にやってくるメールに気を散らされることなく その日のメールの内容をゆっくり見渡せるからです。
「モデレート」とは、 投稿の内容をいったんチェックし、 a) スパムでないこと、そして b) メーリングリストで扱うのにふさわしい内容であること を確認してから一般向けに配信する作業のことです。 モデレート処理は、必ずしも人間が行わなければならないというものではありません。 ソフトウェアに任せることで、より簡単に行えるようになります。 モデレートについては、後でもういちど取り上げます。
これは特に、使われなくなったアドレスを簡単に削除するために有用です。 メーリングリストの参加者のアドレスから 「このアドレスはもう存在しません」といった自動返信メッセージが毎回届くようになったら、 即刻対応しなければなりません (メーリングリストソフトウェアによっては、 これを自動検出して該当者を自動的にメンバーから外すようにできるものもあります)。
多くの人は、メールソフトの仕分け機能などを活用していることでしょう。 メーリングリストソフトウェアを使用すると、 特定のヘッダをメールに付加することで これらの機能を使いやすいようにします (詳細は後で説明します)。
メーリングリストへのすべての投稿は、 保存されたうえでウェブから閲覧可能になります。 あるいは、メーリングリストソフトウェアによっては MHonArc (http://www.mhonarc.org/) のような外部のアーカイブツールへのプラグインインターフェイスを持っているものもあります。 6章コミュニケーション の 「アーカイブを目に付きやすくする方法」 で説明するように、 アーカイブは重要な作業です。
このようにひとつひとつ挙げてみると、 メーリングリストの管理というものが思いのほか複雑な作業であることがお分かりでしょう。 そして、それらの作業の多くがソフトウェアで自動化できることもわかります。 決してこれらのソフトウェアのエキスパートになる必要はありません。 しかし、まだまだ常に学ぶ余地があるということ、 そしてフリーソフトウェアプロジェクトを運営するにあたって メーリングリストの管理作業は避けて通れないものであることは心においておきましょう。 これ以降では、メーリングリストの設定に関するよくある問題についてみていきます。
今、この文章を書いている時点と実際に本書が出版された時点を比べても、 スパムに関する問題の深刻度は倍増していることでしょう。 少なくとも、そう感じるくらいのレベルにはなっているはずです。 つい最近までは、スパム対策をまったく行わなくても メーリングリストを普通に運営できていました。 ごくまれに変な投稿が行われることもありましたが、気になるほどのものではなかったのです。 しかし、そんな時代はとっくに終わってしまいました。 現在では、スパム対策をまったくしていないメーリングリストは あっという間にゴミメールの山となってしまいます。 そんなメーリングリストは使い物にならないでしょう。 スパムは決して野放しにしてはいけません。
本書では、スパム対策を２種類に分けて考えます。 ひとつはメーリングリストにスパムが配信されないようにすること。 もうひとつは、メーリングリストの参加者のメールアドレスを スパム業者に収集されないようにすることです。 前者の方がより大事なので、まずはそちらから考えていきましょう。
スパム投稿を防ぐ基本的な方法は、次の３つです。 ほとんどのメーリングリストソフトウェアは、これらの機能をすべて提供しています。 また、これらの方法は、どれかひとつだけを使うのではなく 組み合わせて使うと有効です。
メーリングリストのメンバーからの投稿のみを自動配信する
これはある程度は有効で、管理者にはほとんど負担がかかりません。というのも、 これを行うには単にメーリングリストソフトウェアの設定を変更するだけだからです。 しかし、自動承認されなかった投稿を単に捨ててしまってはいけません。 そうではなく、自動承認されなかった投稿は管理者がいったんチェックするようにしましょう。 そうする理由は次の２つです。まず第一に、 メーリングリストのメンバー以外からの投稿も受け付けたいからです。 ちょっとした質問や提案がある人が、 いちいちメーリングリストに参加しなければメールを投稿できないというのは不便です。 もうひとつ、メーリングリストのメンバーであっても、 登録しているアドレス以外のメールアドレスから投稿することがあるかもしれません。 メールアドレスは、人を識別する手段としてはあまり信頼できるものではありません。 メールアドレスにあまり頼りすぎないようにしましょう。
投稿を、いったんスパムフィルタリングソフトウェアにかける
メーリングリストソフトウェアが対応していれば (ほとんどは対応しています)、 投稿内容をスパムフィルタリングソフトウェアに渡すことができます。 自動スパムフィルタリングは完璧なものではありません。 また、今後も決して完璧なものにはならないでしょう。 スパムの送信者とフィルタの作者との戦いは永遠に続くのです。 しかし、フィルタリングソフトを使用することで、 管理者が手作業で処理すべきスパムを激減させることができます。 人手で処理すべき内容が多くなればなるほど、 自動フィルタリングは有用です。
ここでは、スパムフィルタの設定方法については説明しません。 ご利用のメーリングリストソフトウェアのドキュメントを参照してください (本章の後半の 「ソフトウェア」 で詳しく説明します)。 メーリングリストソフトウェアにはたいてい、 自前のスパム対策機能が組み込まれています。 しかし、サードパーティのフィルタを使いたいこともあるでしょう。 私がよく利用しているのは、SpamAssassin (http://spamassassin.apache.org/) と SpamProbe (http://spamprobe.sourceforge.net/) です。もちろんこれら以外にも オープンソースのスパムフィルタはたくさんありますし、 その中にはすばらしいものもあるでしょう。 私はたまたまこの２つで満足しているので、 他のものをあまり調べていないというだけのことです。
モデレートする
登録されているメールアドレスからの投稿ではないので 自動配信はされませんでした。 また、スパムフィルタを通した結果、スパムではないと判断されました。 そのような投稿に対する最後の手段は モデレート です。 メールの内容が特別なアドレスに送られ、 人間がその内容をチェックしたうえで承認するか却下するかを決めるのです。
投稿を承認する場合は、「その投稿だけを承認する」 あるいは「その投稿を承認し、 今後同じアドレスからの投稿があった場合は自動的に配信する」 のいずれかの方式となります。 ほとんどの場合は後者の方式をとることになるでしょう。 そうすれば、将来のモデレートの負荷を下げることができます。 投稿の承認方法は、システムによってことなります。 よくある方式は、特別なアドレスに対してコマンドを返信することです。 たとえば "accept" (この投稿だけを承認する) あるいは "allow" (この投稿および今後のすべての投稿を承認する) などのようになります。
却下する場合は、通常は単に何もせずにモデレートメールを無視します。 メーリングリストソフトウェアは、 その投稿を承認するという確認を受け取らない限り 投稿を配信することはありません。 つまり、単にモデレートメールを無視しておけば それで用が満たされるのです。 あるいは、"reject" や "deny" といったコマンドを明示的に返信することもあります。 そうすると、同じアドレスから今後投稿があった場合に モデレート処理の前に自動的に却下してくれるようになります。 しかし、そんなことをしてもあまり意味はないでしょう。 モデレートの主要な目的はスパムの防止であり、 スパマーが同じアドレスからメールを何度も送るなんてありえないでしょうから。
モデレートを乱用しすぎないようにしましょう。 スパムを防ぐことと、まったく的外れな投稿 (投稿するメーリングリストを間違えたなど) を防ぐことだけに限るべきです。 モデレートシステムを使用すると、 投稿者にだけ直接返信を返すことができますが、 それを使ってメーリングリストに関する質問に答えてはいけません。 たとえ即答できるようなものであったとしてもです。 そんなことをすると、どんな質問があったのかがコミュニティーに伝わりません。 また、その質問に対してより適切に答えられる人がコミュニティーにいたとしても、 答えるチャンスがなくなってしまいます。他の人が答えた内容も見ることができません。 メーリングリストのモデレートは、 ゴミメールや場違いなメールばかりにすることを防ぐためのものでしかありません。 それ以上の何者でもありません。
メーリングリスト参加者のアドレスをスパマーに抜き取られないようにするには、 アーカイブする際にメールアドレスをぼかすのが一般的です。 たとえば、
jrandom@somedomain.com
のようなアドレスを
jrandom_AT_somedomain.com
あるいは
jrandomNOSPAM@somedomain.com
あるいはそれと同様な (人間には理解できるような) 形式に変換します。 ありがちなメールアドレス収集ソフトは、 メーリングリストのアーカイブのウェブページを読み込んで "@" を含む文字列を探します。したがって、 アドレスをこのように変換しておけば収集ソフト用の対策になります。 これは、メーリングリストに直接送られてくるようなスパムには無意味です。 そうではなく、リストの参加者のアドレスに直接スパムが送られるのを防ぐための仕組みです。
このようにアドレスを隠すことには賛否両論があります。 この機能を気に入っている人は、アーカイブではそうするのが当然だと思っており、 もしそうなっていなければ非常に驚きます。 しかし、中にはちょっとそれはやりすぎだと考える人もいます。 いくら人間にとっては理解できる形式であるとはいえ、 いったん頭の中で変換しないと正しいアドレスがわからないからです。 また、まったく無意味だという人もいます。 いくらしっかりした符号化を行ったとしても、 アドレス収集ソフトはそれを理論上は理解できるはずだからです。 しかし、アドレスの変換が有用であるということは実証されています。 http://www.cdt.org/speech/spam/030319spamreport.shtml を参照してください。
理想を言えば、このような処理は 個々の好みで切り替えられるようにしておくべきでしょう。 つまり、メーリングリストの参加者の個人設定ページで 「自分のメールアドレスを符号化する/しない」 を切り替えられるようにしておけばいいのです。 しかし、そのように投稿者ごとや投稿ごとに設定を切り替えられる ソフトウェアを見たことはありません。現状では、 メーリングリストの管理者が全員の設定を一括で決めなければならないのです (アーカイブツールがメールアドレスの変換処理に対応していることを 前提としていますが、中にはその機能がないものもあります)。 私は、個人的にはどちらかというと変換処理を行うほうが好きです。 自分のメールアドレスをウェブページなどに表記する際に、 アドレス収集用ソフト対策に非常に気を使っている人たちもいます。 そのような人たちの努力が メーリングリストのアーカイブによって台無しになってしまうと、 きっと非常に悲しむことでしょう。 一方、アドレスが変換されていることによって アーカイブの利用者に多少不便を感じさせたとしても、 そんなにたいしたものではないでしょう。 しょせん、必要なたった一人のアドレスを正しい形式に戻すだけのことなのですから。 ところで、メールアドレスの変換作業もまた、 終わりのない戦いであることを覚えておきましょう。 あなたがこれを読んでいる今まさにこの間にも、 アドレス収集ソフトウェアは進化し続けています。 ありがちなアドレス変換方法はすでに破られており、 私たちはまた別の方法を考えなければならないのです。
メーリングリストの参加者の中には、メーリングリストに投稿されたメールを 別のフォルダにわけて管理したいと考える人もいることでしょう。 メールソフトの多くは、ヘッダ の内容によって自動的にメールを仕分ける機能を持っています。 ヘッダとはメールの先頭にあるフィールドのことで、 送信者や受信者、件名、日付、その他メッセージに関するさまざまな情報を保持しています。 以下にあげるヘッダはよく知られているものであり、 事実上必須であるといえます。
From: ... To: ... Subject: ... Date: ...
その他にも標準的なヘッダはありますが、 これらは省略してもかまいません。たとえば、
Reply-to: sender@email.address.here
ヘッダは省略することもできます。しかし大半のメッセージにはこのヘッダがついています。 なぜなら、これを使用すると送信元のアドレスを確実に知ることができるからです (ふだんメールを受け取っているアドレス以外からメールを送信する場合などに特に便利です)。
メールソフトの中には、Subject ヘッダの内容をもとにした 簡単な仕分け機能を持っているものもあります。 このようなソフトを使っている人たちからは、 メールの件名の先頭に自動的にプレフィックスをつけてほしい という要望があるかもしれません。それを利用すれば、 簡単に仕分けを行えるからです。 どういうことかというと、次のような件名のメール
Subject: Making the 2.5 release.
が投稿されたときに、実際にメーリングリストに配信されるメールは 次のようになるということです。
Subject: [discuss@lists.example.org] Making the 2.5 release.
多くのメーリングリスト管理用ソフトウェアにはこの機能がついていますが、 このオプションは使わないことをお勧めします。 このオプションによって解決できるであろう問題は、 もっと控えめな方法で解決することができるものです。 一方、件名欄が無意味に長くなってしまうという点は無視できません。 メーリングリストに慣れたユーザーは、 まずその日にやってきたメールの件名をざっと眺め、 どれを読んでどれに返信するのかを判断するのです。 件名の先頭にメーリングリストの名前をつけてしまうと、 件名の後半が画面からはみ出てしまい、見えなくなってしまいます。 どのメールを処理するのかを決めるための情報が少なくなってしまうわけで、 結果としてメーリングリストの使い勝手が悪くなってしまいます。
Subject ヘッダに手を加えるのではなく、 もっと別の方法で仕分けをする方法を教えてあげるようにしましょう。 たとえば To ヘッダなどがお勧めです。 これはメーリングリスト名そのものとなっています。
To: <discuss@lists.example.org>
Subject による仕分けができるメールソフトなら、 まず間違いなく To による仕分けもできるはずです。
これ以外にも必須ではないけれどメーリングリストではよく使われているヘッダがいくつかあります。 これらのヘッダをもとにして仕分けをしたほうが、"To" や "Cc" に頼るよりも確実です。以下のようなヘッダは メーリングリスト管理ソフトウェアが直接追加するので、 これを使用した仕分けをしている人もいることでしょう。
list-help: <mailto:discuss-help@lists.example.org> list-unsubscribe: <mailto:discuss-unsubscribe@lists.example.org> list-post: <mailto:discuss@lists.example.org> Delivered-To: mailing list discuss@lists.example.org Mailing-List: contact discuss-help@lists.example.org; run by ezmlm
これらのヘッダは、それぞれ文字通りの意味を持っています。 詳しくは http://www.nisto.com/listspec/list-manager-intro.html をご覧ください。あるいはもっと詳しい厳密な仕様が知りたいのなら、 http://www.faqs.org/rfcs/rfc2369.html を見るといいでしょう。
これらのヘッダを見ると、"list" というメーリングリストの管理用アドレスとして "list-help" と "list-unsubscribe" があることが何となくわかるでしょう。 これらに加えて、通常は参加用のアドレスとして "list-subscribe"、 管理者への連絡用アドレスとして "list-owner" があるようです。 使用するソフトウェアによっては、 これら以外にもさまざまな管理用アドレスが設定されるかもしれません。 詳細はドキュメントを参照してください。 通常、これらの特別なアドレスの一覧は、 メーリングリストへの参加時に自動送信される 「ようこそ」メールにまとめられています。 あなた自身もこのメールの内容を見ることができるでしょうが、 もし見られないようなら、メーリングリストのメンバーの誰かに見せてもらってください。 この「ようこそ」メールの内容は、常に手元においておきましょう。 メーリングリストの使い方に関する問い合わせに答えたり、 ウェブページに情報をのせたりする際に役立ちます。 メーリングリストのメンバーから「退会するにはどうしたらいいのですか?」 という質問を受けたら、そのウェブページの URL を教えてあげればいいのです。
中には、すべての投稿の末尾に退会用の手順を載せられるようになっているソフトウェアもあります。 もしそのようなオプションがあるのなら、有効にしておきましょう。 これは、メッセージの目立たない場所にほんの数行の内容を追加するだけです。 たったそれだけで、あなたの手間は激減するでしょう。 「退会方法を教えて!」というメールがあなた宛てに (もっとひどいことには、メーリングリスト宛てに!) 届くことも減ります。
先ほど 「個人的な議論を避ける」 で、 議論は公開の場で行うということの重要性を強調しました。 できるだけそのように心がけておかないと、 議論はどんどん個人的なメールのやりとりに収束してしまいます。 また、本章で扱っている内容は、 ソフトウェアを用いていかにプロジェクト内のコミュニケーションを 円滑にするかということです。 もし議論をメーリングリスト上で続けされるような機能が メーリングリスト管理ソフトウェアに搭載されているのなら、 それを使用しない手はありません。
……とは一概に言い切れないのです。 実際そのような機能はあるのですが、 無視できない問題点もいくつかあります。 この機能を有効にするかどうかについては、 メーリングリスト管理に関する議論の中でも最も白熱するものです。 ７時のニュースで取り上げられるような内容ではありませんが、 フリーソフトウェアプロジェクトにおいては何度となく議論されてきました。 ここでは、まずその機能について説明し、 双方の立場の主張を並べたうえで、 個人的にお勧めの方式を示します。
機能そのものは非常にシンプルです。 メーリングリストへのすべての投稿に対して自動で Reply-to ヘッダを設定し、返信先をメーリングリストのアドレスにするというものです。 もとの送信者がどんな Reply-to ヘッダをつけていたとしても (あるいはつけていなかったとしても)、 メーリングリストの参加者に配信されるときには Reply-to がメーリングリストのアドレスに変わっています。
Reply-to: discuss@lists.example.org
一見これはよさげな機能に見えるかもしれません。 たいていのメールソフトは Reply-to ヘッダの内容を考慮するので、 投稿に対して返信しようとすると、 自動的にメーリングリスト宛てに送信するようになります。 もちろん返信する人の意思で宛先を変更することはできますが、 デフォルトで メーリングリスト宛てになるということが大事なのです。 テクノロジーの力で協調作業をやりやすくする。 まさに完璧な例じゃないですか。
ところが残念なことに、この方法にはいくつか欠点があるのです。 欠点としてまず最初にあげられるのが、いわゆる Can't Find My Way Back Home (おうちに帰れない) 問題です。何らかの理由で普段とは異なるアドレスからメールを送信する際など、 「本当の」アドレスを Reply-to フィールドに指定しておくこともあります。 常に同じ場所でメールの読み書きを行うのなら、この問題は起こりません。 もしかしたら、そんな問題があることにすら気づいていないかもしれません。 しかし、普段とは異なる設定でメールを送信する人や メールの From アドレスを変更できない状況 (職場から送信しており、IT 部門に対する権限がない状況) の人にとっては、返信を自分で受け取るための唯一の手段が Reply-to となるわけです。 そのような人たちにとって、メーリングリストに参加しているのとは別のアドレスで投稿する際には Reply-to 設定は必要不可欠な情報となります。 メーリングリストソフトウェアがそれを上書きしてしまうと、 その人は自分の投稿に対する返信を見ることができなくなってしまいます。
もうひとつの問題は、期待に反する動作をしてしまうということです。 個人的には、Reply-to の変更に反対する人が最も強く主張しているのがこの問題だと思います。 メールの処理に慣れている人は、reply-to-all (全員に返信) と reply-to-author (送信者に対して返信) の２通りの返信方法を使い分けています。 最近のメールソフトは、これらの操作に対して それぞれ別のショートカットキーを割り当てています。 全員 (メーリングリストも含む) に返信したい場合は 「全員に返信」を、そして送信者に対して個人的に返信したい場合は 単なる「返信」を使えばいいということを知っているのです。 あなたとしては返信は可能な限りメーリングリストに送信してほしいでしょうが、 返信するほうには個人的に返信する権利があります。たとえば、 元のメッセージに対して何か機密情報を含む内容を返信したい場合などは、 それが公開のメーリングリストに流れてしまってはまずいでしょう。
さて、メーリングリスト側で送信者の Reply-to 設定を書き換えてしまったらどうなるのかを考えてみましょう。 そのメールに対して「送信者に返信」のキーを押したとしたら、 当然その人はそのメールが送信者に対してのみ届くものと期待することでしょう。 ごく当たり前のことなので、いちいちあて先を確認することもないかもしれません。 返信メールの中で個人的な内緒のメッセージ (もしかしたら他のメンバーの悪口かも……) を書き、送信ボタンを押します。 予想に反して、数分後には彼の書いた返信が メーリングリストに流れることになるでしょう! ええ、もちろん送信前にあて先をしっかり確認しなかった彼が悪いのです…… 理屈上は。でも、普通は Reply-to は送信者のアドレスに設定されているもの (メールソフトがそう設定しているはず) なので、 長年メールを使っている人ほどそう信じ込んでしまう傾向があります。 実際、もし意図的に他のアドレス (たとえばメーリングリストなど) を Reply-to に設定した場合は、通常はそれをメッセージの中で明記するものです。
この予期せぬ振る舞いの影響は無視できないため、 個人的にはソフトウェア側での Reply-to ヘッダの変更は行わないことをお勧めします。 確かにこの機能は共同作業の際には便利でしょうが、 私にとってはその副作用の影響のほうが重大に感じます。 しかし、もう一方の立場の人たちにもそれなりの言い分があります。 どちらを選択したとしても、「どうして○○にしなかったの?」 という質問がたびたびメーリングリストに投稿されることになるでしょう。 これはきっと、そのメーリングリストで本来扱いたいと思っているテーマとは異なるはずです。 そんな場合用に、この問題に関する議論をうまくしずめるような お決まりの返答を用意しておくといいでしょう。ここで大切なのは、 あなたがどちらの設定を選んだとしても、決して それが唯一の正解なんだと主張しないようにすることです (たとえ内心ではそう思っていたとしても)。 そうではなく、次のように説明するようにしましょう。 「この問題については昔から議論が繰り返されています。 どちらの立場の主張にもそれなりの言い分があり、 みんなが納得するようにすることは困難です。 だから、私は自分がよりよいと思う設定にしたのです。」 そして、(まったくの新入りさんが質問してくる場合は別として) もうこの話題はメーリングリスト上で話すのはやめるよう丁寧にお願いし、 あとはそのスレッドを放置しておきます。 そうすれば、そのスレッドの議論は自然に収まるでしょう。
もしかしたら、誰かが「どっちがいいか投票で決めよう」なんて言い出すかもしれません。 あなたさえかまわなければそれでもいいのですが、 個人的には、この問題は多数決で決めるような類のものではないと思います。 予期せぬ挙動のせいで受ける被害 (個人的なメールを 間違ってメーリングリストに送ってしまう) は甚大ですが、 Reply-to を書き換えないことで参加者が受ける不利益はたかが知れています (たまに間違って個人宛に返信してしまった人に対して、 メーリングリストに返信するよう伝えるくらいです)。 個人的なメールをメーリングリストに送ってしまうような人は ほんの一握りかもしれません。でも、たとえそうであっても 彼らにそのようなリスクを負わせることが許されるでしょうか?
この問題に関するすべての議論を取り上げることはしません。 ここでは、最も重要だと思われるものだけを示しておきます。 詳細な議論の内容は、以下の文書でご確認ください。 どちらも、この問題が持ち上がるたびに多くの人が引用するものです。
Reply-to はそのままにしておくべきだという主張, by Chip Rosenthal
Reply-to をメーリングリスト宛に変更すべきだという主張, by Simon Hill
先ほど私の個人的な好みを軽く述べましたが、決してそれが "正解" だと確信しているわけではありません。実際、私は Reply-to を 書き換えている メーリングリストにも多数参加しています。 大事なことは、どちらにするのかを早めに決めておくこと。 そして、後々この件についての議論に巻き込まれないようにすることです。
いつの日か、どこかの誰かが reply-to-list 機能をメールソフトに組み込んでくれるかもしれません。これを使用すると、 先ほど説明したメーリングリスト独特のヘッダの内容をうまく読み取り、 メーリングリスト宛てに適切に返信してくれるのです。 それ以外の相手にはメールは送られません。 だってその人たちほほとんどはメーリングリストにも加入しているんですから。 結局のところ、メールソフト側でこのような機能を実装してしまえば、 こんな議論をせずにすむようになるわけです (実際、Mutt というメールソフトはこの機能を持っています [16] )。
よりよい対応法は、Reply-to を変更するかしないかを 各メンバーが個別に設定できるようにすることでしょう。 メーリングリスト宛ての投稿は (自分の投稿も他人の投稿も含めて) Reply-to をメーリングリストのアドレスにしてほしいという人はそのオプションを指定し、 Reply-to をそのままにしておいてほしい人はそのように指定します。 残念ながら現時点では、 これを各参加者ごとに設定できるメーリングリスト管理ソフトは存在しないようです。 現状は、全員共通の設定で我慢するしかありません。 [17]
メーリングリストのアーカイブを設定する技術的な方法は、 使用するメーリングリスト管理ソフトによって異なるので、 本書では詳しくは取り上げません。 アーカイブツールを選択したり設定したりする際には、 以下のような点に注意しましょう。
少なくとも、実際に投稿があってから１時間後くらいには その投稿がアーカイブされていてほしいものです。 可能なら、実際に投稿があった瞬間にアーカイブ処理も同時に行なうべきです。 そうすれば、その投稿がメンバーに配信されたときには既に アーカイブにも同じ内容が存在するということになります。 それが無理だとしても、少なくとも１時間おきくらいの頻度でアーカイブの更新を行ないましょう (アーカイブソフトによっては、デフォルトでは １日に１回しかアーカイブを行なわないものもあります。 しかし、メーリングリストのアーカイブ処理としては、 事実上これでは使い物にならないでしょう)。
メッセージがいったんある URL にアーカイブされたら、 その後ずっと同じ URL でそのアーカイブにアクセスできるようにすべきです。 アーカイブを再構築したりバックアップから復旧したり、 あるいはその他何らかの修正を加えたときにも、 いったん公開した URL はそのまま変わらないことが望ましいでしょう。 同じ URL を保つようにしておけば、サーチエンジンに捕捉されやすくなります。 これは、利用者にとって大きな利点となるでしょう。 URL を保ち続けるよう心がけるもうひとつの理由としては、 メーリングリストの投稿やスレッドがバグ追跡システム (本章の後半の 「バグ追跡システム」 を参照してください) や他のプロジェクトのドキュメントからリンクされることが多いということもあります。
理想を言えば、メールをメンバーに配信する際に、 そのメッセージがアーカイブされている URL をヘッダに含められるようになっていればなおよいでしょう。 そうすれば、そのメールを受け取った人は わざわざアーカイブサイトを訪れなくても そのメッセージがアーカイブされている場所を知ることができます。 ブラウザを開いて何らかの操作をするというのは時間のかかる作業なので、 それが省けるだけでも非常に便利です。 このような機能を持つメーリングリスト管理ソフトウェアがあるかどうかは、 私は知りません。残念ながら、 私が今使っているソフトウェアにはそのような機能はないようです。 しかし、どこかにそんなソフトウェアがあるのではと期待しています (もしあなたが新たにメーリングリスト管理ソフトウェアを開発するのなら、 ぜひこの機能を実装してください。お願いします)。
当然、アーカイブのバックアップとバックアップからの復旧の方法は 簡単なほうがよいでしょう。いいかえれば、 アーカイブソフトがブラックボックス化してしまってはいけないということです。 あなた (もしくはプロジェクト内の誰か) はメッセージが実際にどのように保存されているかを知っている必要があり、また、 必要になったときにはそこからアーカイブを復元できるようにしておかなければなりません。 プロジェクトにとって、アーカイブの内容は宝物です。 万一アーカイブを失ってしまうことがあれば、 貴重な記録を失ってしまうことになります。
個々のメッセージから、そのメッセージが属する スレッド (関連するメッセージのまとまり) へ移動できるようにしておく必要があります。 また、各メッセージ個別の URL とは別に、 スレッドを表す URL もあるとよいでしょう。
メッセージの本文や送信者、件名などによる検索機能を サポートしていないアーカイブソフトなんて、使い物にならないといっていいでしょう。 アーカイブソフトの中には、単に Google などの外部のサーチエンジンに処理をまかせているだけのものもあります。 機能がないよりはましですが、検索機能を自前で実装しているほうが よりきめ細やかな処理ができます。 たとえば、タイトルだけを対象に検索したり、 本文も含めて検索したりといったこともできるでしょう。
上にあげたのは、アーカイブソフトを選択する際に注意する点として 技術的な面にしぼった一覧です。 実際にみんなにアーカイブソフトを利用 してもらうことにどのような利点があるのかについては、 「アーカイブを目に付きやすくする方法」でとりあげます。
メーリングリストの管理やアーカイブの作成用に、 さまざまなツールがオープンソースで公開されています。 あなたのプロジェクトを公開しているサイトで何かのツールが用意されているのなら、 それを使えばいいでしょう。しかし、もし自分で新たにインストールする必要があるのなら、 いくつかの選択肢があります。私が実際に使用したことがあるのは Mailman、Ezmlm、MHonArc、そして Hypermail です。 しかし、それ以外のソフトウェアが劣っているというわけではありません (また、当然のことですが、私が知っているソフトウェアだけがすべてではありません。 それ以外にもさまざまなものがあるはずなので、 これを完全なリストとはとらえないでください)。
メーリングリスト管理ソフトウェア
Mailman — http://www.list.org/
(Pipermail というアーカイバが組み込まれていますが、 プラグイン形式で外部のアーカイバを使用することもできます。 Mailman は標準の座を長年維持しています。 その管理インターフェイス、特にスパムのモデレーションや 購読のモデレーションに関してはさすがに時代を感じさせ、 よりモダンなインターフェイスに慣れた人にとっては もどかしさを感じることがあるかもしれません)
GroupServer — http://www.groupserver.org/
(アーカイバが組み込まれており、ウェブベースのインターフェイスも統合されています。 GroupServer は Mailman に比べて少し導入が難しく、 2012 年はじめの時点では前提条件もかなり厳しいものです。 しかし、ひとたび動き出せば、より使いやすさを実感できるでしょう)
Sympa — http://www.sympa.org/
(開発と保守はフランスの大学のコンソーシアムが担当しており、 700000 人を超える大規模なメーリングリストを扱えるように設計されています。 また、メーリングリストの数が多くなっても対応できます。 依存するツールはさまざまなものが選べ、 たとえば sendmail や postfix、qmail、そして exim などをメッセージ配送エージェントとして利用できます。 ウェブベースのアーカイブ機能が組み込まれています)
SmartList — http://www.procmail.org/
(メール処理システム Procmail と組み合わせて使用するためのものです)
Ecartis — http://www.ecartis.org/
ListProc — http://listproc.sourceforge.net/
Ezmlm — http://cr.yp.to/ezmlm.html
(メール配送システム Qmail と組み合わせて使用するように設計されています)
Dada — http://mojo.skazat.com/
(なぜかサイト上では隠そうとしているようですが、 これはフリーソフトウェアで、GNU General Public License のもとで公開されています。また、アーカイバも組み込まれています)
メーリングリストのアーカイブ用ソフトウェア
MHonArc — http://www.mhonarc.org/
Hypermail — http://www.hypermail.org/
Procmail — http://www.procmail.org/
(SmartList に同梱されているソフトウェアです。 通常のメール処理システムなのですが、 アーカイバとしても使えるようです)
[16] 本書の出版直後に Michael Bernstein が教えてくれました。"Mutt 以外にも、 reply-to-list 機能を実装しているメールソフトがあります。 たとえば Evolution では、キーボードショートカット (Ctrl+L) でこの機能を使用できます。でもボタンはありません。"
[17] その後、この機能をサポートするメーリングリスト管理ソフトがあることを知りました。 Siesta というものです。 http://www.perl.com/pub/a/2004/02/05/siesta.html の記事も参考になるでしょう。