メーリングリスト（mailing list）とは、元々「郵送先名簿」の意味です。電子メールの用語としては、同報メールの仕組みを意味します。郵送先名簿を識別する一つの電子メールアドレスに宛てれば、そこに登録された人たちすべてに電子メールが配信されるという仕組みです。グループでの情報交換や、問い合わせ窓口宛のメールを複数の人たちで受ける場合に利用されます。
　UNIX系のOSを使ったメールサーバでは、/etc/aliasesファイルで

workshop:       :include:/var/mlist/workshop.list

のように別名定義をして、アドレスリストファイル（この例では/var/mlist/workshop.list）にメンバーの電子メールアドレスを一行に1個ずつ記述しておくことにより、簡単なメーリングリストを実現できます。これで、宛先を

workshop@example.co.jp

のようにして送信すれば、登録されたメンバー全員にメールが配信されます。
　大規模なメーリングリストでは本格的なメーリングリストサーバプログラムが使われますが、そこまでする必要がない場合や、サーバ管理者がシステム管理にさほど熟達していない場合は、この簡単な方法が使われます。
　私も、かつて会社で技術検討会のメーリングリストを運用していた時、あまり技術力がなかったので（今も大したことありませんが(^^);）、当初はこの簡単な方法を使っていました。しかし、いくつかの問題が生じたので、メンバーの一人であるWさんが、スクリプト（文字列のまま解釈・実行されるプログラム）でメールヘッダを加工する方法を提案してくれました。そして、別のメンバーのYさんが、メールヘッダの加工を完璧に行うためにテキスト処理用スクリプト言語GAWKを使う方法を教えてくれました。ここから私の工夫の歴史が始まります。

1. Receivedヘッダを削除する

   　Receivedヘッダとは、中継郵便局ごとに押されるスタンプのようなものです。メールの堂堂巡りを防ぐために、メールサーバは、Receivedヘッダがおおむね25個を超えたら「ホップカウントオーバー」としてエラー差し戻しを行います。
   　メーリングリストでは、送信者からメーリングリストサーバを通って受信者に至るまでに多くのメール中継サーバを経由するため、ホップカウントオーバーが起こりやすくなることがあります。私がかつて運用していたメーリングリストでは、受信者が転勤先などへ転送をかけているとホップカウントオーバーが起こることがありました。そこで、Wさんの提言により、送信者からメーリングリストサーバまでの経路で付けられたReceivedヘッダを削除するようにしました。

2. Errors-Toヘッダを付ける

   　Errors-Toヘッダは、インターネットで最も広く使われているメール配送プログラムsendmail（UNIX対応）の独自仕様で、エラー差し戻し先を指定するものです。
   　別名定義だけによる単純なメーリングリストでは、アドレス登録誤りなど、メーリングリストの責任によるエラー差し戻しも送信者へ行ってしまい、メーリングリスト管理者が気付きにくいという問題があります。そこで、これもWさんの提言により、Errors-Toヘッダを付けるようにしました。
   　なお、すでにErrors-Toヘッダが付いていたらそれを無効にするようにしました。メーリングリストの責任によるエラー差し戻しをほかの人へ行かせないためです。

3. Reply-Toヘッダを付ける

   　Reply-Toヘッダは、返信先を指定するものです。これがなければFromヘッダに示されたアドレスが返信先になりますが、これがあれば、返信先はFromヘッダのアドレスよりも優先されます。
   　別名定義だけによる単純なメーリングリストでは、これが付かないため、返信先は元の送信者になります。受信者がメーラーで「全員に返信」の操作をすると、元の送信者には、その人に宛てられた分とメーリングリストから配信される分とで、同じメールが2通行ってしまうことになります。メーリングリストのアドレスを返信先に指定するReply-Toヘッダを付けると、受信者が返信をメーリングリスト宛にするのが楽になります。これもWさんの提言で採用しました。
   　なお、Yさんの助言により、すでにReply-Toヘッダがあればそのまま残すことにしました。こうすれば、送信者が自分だけに返信をほしい場合に、自分のアドレスを指定したReply-Toヘッダを付けて送信すればよいことになります。

4. サブジェクトに連番を付ける

   　本格的なメーリングリストサーバプログラムを使ったメーリングリストでは、多くの場合、サブジェクトにメーリングリスト名と連番が付くようにしています。たとえば

   [workshop 123] 技術動向

   のような具合です。これは便利なので、スクリプトに機能追加して実現しました。

5. 「返信は私だけに」モードを別に設ける

   　このスクリプトをエンジニアリング関係の研究会のメーリングリストに使っていたら、会合案内に対する出欠の返答がたくさんメーリングリストに流れるという事態になり、「返答をいちいち全員に流さないでほしい」という声が上がりました。
   　送信者が自分のアドレスを指定したReply-Toヘッダを付けて送信してくれればよいのですが、電子メールの利用にさほど熟達していない人が多いグループなので、それを要請するのはちょっと酷です。そこで、Reply-Toヘッダを付けない（すでに付いていればそのままにする）スクリプトも用意し、

   • workshop：返信はメーリングリスト宛
   • workshop-rmo：返信は元の送信者宛（「rmo」は「Reply to Me Only」の意味）

   という二つのアドレスで運用することにしました（メーリングリスト名は仮称です）。
   　電子メールの利用に熟達していない人にとって、返信を自分だけにほしい時、Reply-Toヘッダを付けて送信するよりも、送信先アドレスを変える方が楽です。これは私独自の工夫で、一つのメーリングリストで二つのアドレスを使うという仕様は、商用のメーリングリストサービスには見当たりません。

6. Reply-Toヘッダを強制的に書き換える

   　「返信は私だけに」モードの提供と同時に、一般の情報交換用のスクリプトでは、Reply-Toヘッダを強制的にメーリングリスト宛に書き換えるようにしました。自分宛のReply-Toヘッダをいつも付けるようにメーラーを設定している人がいて（Fromヘッダと同じアドレスのReply-Toヘッダは無意味なのですが）、その人からのメールへの返信がメーリングリストに流れないということになりかねないからです。
   　アドレスは一つで送信者がReply-Toヘッダを指定できるという仕様はメールに熟達したグループ向けで、Reply-Toヘッダの強制書き換えと「返信は私だけに」モードとの併用はメールの初心者が多いグループ向けだと思います。

7. Errors-Toヘッダの付加をやめる

   　エラー差し戻し先をメーリングリスト管理者にするためのつもりで付加していたErrors-Toヘッダですが、無意味と判断してやめました。スクリプトからsendmailを起動する時に、メーリングリスト管理者名で配信するようにしているので、これで差し戻し先はメーリングリスト管理者になるのです。ただ、すでにErrors-Toヘッダがあれば削除するようにはしています。
   　今ではErrors-Toヘッダは廃れつつあり、最近のsendmailではこれを無視するようにするのが標準的な設定になっているようです。

8. Return-Receipt-Toヘッダを削除する

   　Return-Receipt-Toヘッダとは、sendmailの独自仕様で、受信者のメールサーバから受け取り通知を自動的に返送するよう要求するものです（受信者が読んだことの通知ではありません）。かつては、これをいつも付けるようにメーラーを設定している人がかなりいました。メーリングリストでこれをやられると、受け取り通知メールが大量発生してネットワークを混雑させることになります。
   　また、このヘッダの意味を曲解して、受信者が読むと「開封」というサブジェクトのメールを、Reply-Toヘッダに指定されたメーリングリストに投げるという馬鹿げたメーラーがありました。まったく迷惑なメーラーです。
   　私は「受け取り通知要求は必ずオフにしてください」と呼びかけていたのですが、ずいぶんたってからふと気付きました。「なんだ、スクリプトで削除してやればいいんじゃないか」。(^^)
   　なお、今ではReturn-Receipt-Toヘッダはほとんど廃れており、付けても宛先のメールサーバから受け取り通知が返らないことが多くなっています。

9. サブジェクトの連番の書き換えを改善する

   　返信の際にサブジェクトがたとえば

   Re: [workshop 123] 技術動向

   となれば、

   [workshop 124] Re: 技術動向

   と書き換えられるようにしていました。ところが、時として

   [workshop 124] RE: [workshop 123] 技術動向

   のように連番が連なってしまうことがあります。決まって、マイクロソフトのメーラーからの返信でこうなります。
   　これは、マイクロソフトのメーラーが、サブジェクトに一部でも日本語文字が含まれていると全体をMIME (Multipurpose Internet Mail Extensions)符号化してしまうからです。たとえば「技術動向」という日本語文字をMIME符号化すると

   =?ISO-2022-JP?B?GyRCNTs9UUYwOH4bKEI=?=

   となります。MIME符号化する必要のない連番の部分もMIME符号の中に入れてしまうので、スクリプトが連番の部分を連番と認識できないのです。あえてこれを解決しようとすれば、MIME符号をいったん解きほぐして処理してからMIME符号化をやり直すことですが、それをスクリプトでやるのはめちゃくちゃ大変。せめてBecky!のようなまともなメーラーが連番の部分をASCII符号にして送信した場合には、

   Re: [workshop 124] RE: [workshop 123] 技術動向

   と連番がいくつ連なっていても

   [workshop 125] Re: 技術動向

   という具合に整理するようにしました。
   　マイクロソフトのメーラーは、メーリングリストで連番の付与や書き換えが行われる場合があるということを考慮していないんですね。受信者のメーラーが日本語文字のMIME符号化に対応していないかもしれない場合にサブジェクトを英・日二ヶ国語で書くという心遣いも無意味にしてしまいます。ほかにも、設定を変えなければHTMLメールを送信してしまうなど、インターネットメールのルールや慣習を尊重していないのには困ったものです（詳しくはこちらをご覧ください）。

10. Receivedヘッダの削除をやめる

    　ホップカウントオーバーを防ぐためにReceivedヘッダを削除していましたが、実はこれにはリスクが伴います。もしメンバーがまかり間違って受信メールをメーリングリストに自動転送したりすると、同じメールが次から次へと配信されるという大変な事態になります。Receivedヘッダを削除しなければ、いずれホップカウントオーバーが起こって止まることが期待できます。
    　また、送信者からメーリングリストサーバまでで付けられたReceivedヘッダを削除すると、不正なメールが投げられた時に送信者を追跡することが困難になります。
    　最近では、多くのネットワークでメールの中継段数が少なくなっているので、正常な配送でホップカウントオーバーが起こることはあまりなくなっています。むしろ、より重大な危険を回避するために、Receivedヘッダを残すように直しました。

　このような工夫で、私は、本格的なメーリングリストサーバプログラムを使わずにメーリングリストを運用しています。いろんな工夫を盛り込めるという点では、自作のスクリプトの方がやりやすいのではないかと思っています。
　私のスクリプトはこちらで提供しています。別名定義だけによる単純なメーリングリストをもう少し便利にしたいとお思いの方には使いやすいと思います。よろしかったらご利用ください。