いや、大した話ではないんだけど。
Tools/sequencer を使うと、メーリングリストに投稿したメールの本文に、
Message for test-ml
Sender: owner-test-ml
Precedence: bulk
みたいなものが付いてしまう。
設定で出す出さないが出来ると思うのだが調べている時間がなかったので、Tools/sequencer の該当箇所をコメントにして対応。
199行 print OUT $subject, "\n";
202行 print OUT "Sender: $sender\n";
204行 print OUT "Precedence: $opt_p\n";
あたりね。
Perl で書かれているので楽勝。
ところで、唐突に話は変わるが、UNIX の世界では Perl で書かれたツールも多いので、やっぱ、Perl の習得はインターネットの世界を商売のネタにしている者には必須条件だろう。
よく、「Perl vs PHP」みたいな図式で話をしたがる人もいるが、そもそもそれは同列に並べて比較することが間違っているだろう。
Perl を「普通自動車」とすれば、PHP は「小型自動二輪」じゃないか？
どっちが良いとか悪いとかじゃなく、「やっぱ、普通免許は取っておいたほうが良いよな」の世界ってことだ。
その上で、「二輪免許もあると便利だよな」ということだと思う。
ただ、PHP は「普通二輪」や「大型二輪」ではないと思うけどね。（笑）
まあ、もし、単なる「Web プログラマ」の世界から一歩踏みだしたいと思っているのなら、「俺は Perl なんか嫌いじゃけんね。Perl 覚えるのなら Java 勉強するよ」なんて言ってないで、素直に「Perl を習得することを次のステップに進むための最初の一歩にする」と考えたほうがいいよ。
Majordomo のセットアップなんか、ほんまに10数年ぶりだ。確か、1997年頃だったか、一度だけ自社サーバにセットアップしたことがあって、それも入れてはみたけどあまり使わなかったので、どういう設定をしたかなどもまったく記憶にない。(^^;
某社のレンタルサーバは、Majordomo を使ったメーリングリストのサービスが標準で（メニュー化されて）用意されているのだが、既に諸々の事情で、MTA を sendmail から qmail に変更したり、Virtual Domain な環境でのメール運用であったりして、標準のサービスは使えない状況になっている。
ということで、標準セットアップされている Majordomo とは別に、手動によるインストールを行ったのである。
何せ、Majordomo は設計の古いシステムなので、手作業で作ったり直したりするファイルがたくさんある。
当初、セットアップだけの作業で工数を見積もっていたのだが、別のサーバで運用されている既存のメーリングリストを移行しないといけなくて、「その工数でついでにやりますよお」と軽く回答してたら、その作業こそ大変だった。(^^;
特に、qmail 環境で Majordomo を使おうとすると、Permission 関係はけっこう引っかかるねえ。
が、Majordomo は Log ファイルに分かり易いログを吐いてくれているので、そこを見て対処療法していけば解決する。
例えば、subscribe のメール送ったら
>>>> approve password subscribe test_ml hogehoge@exsample.jp
>>> Sorry, an error has occurred while processing your request
>>> The caretaker of Majordomo ( Majordomo-Owner@exsample.jp ) has been notified
>>> of the problem.
なエラーが返ってきちゃった・・・というときも、Log ファイルに
Jul 01 11:20:16 exsample.jp majordomo[22441] {ML Master<ml_admin@exsample.com>} approve PASSWORD subscribe test_ml hogehoge@exsample.jp
Jul 01 11:20:16 exsample.jp majordomo[22441] {ML Master<ml_admin@exsample.com>} ABORT Can't append to /var/majordomo/lists/mltest: Permission denied
なんてログが残っているので、「ああ、さっきファイルを FTP で PUT するときに、一時的にファイルオーナーを変更してたんだった」とか思い当たる。
Log ファイルの場所も、Majordomo をインストールしたディレクトリ直下なので分かり易い。
設計が古いなんて言ってごめん。
さすが歴史あるソフトは、こういう基本的なところがちゃんと作ってあるなあ。
ログファイルが分かり易い場所にあると「セキュリティ的にまずい」と思ってる低脳技術者も結構いるからなあ。そういう考え方は MS-Windows のものであって、UNIX の世界には持ち込まないでほしいな。設定ファイルもログファイルも分かり易い場所に置く。そして、適切な Permission 設定をすればいいのだ。
（Permission 管理機能が脆弱で、触られたくないファイルは隠すしかなかった）MS-Windows 文化に（のみ）どっぷり浸かった技術者は、その辺のところがなかなか理解できないのだろうなあ。
