清藤＠HOKKAI
(この対策は、majordomo-1.93に対してのものです。 最新版では同様の処置が可能かどうかはわかりませんし、 そもそも必要ないかもしれません。)
「WHOやらWHICHコマンドを止めてね」
突然、そんな命令が上からふってきた。
「止めるってその・・・今でも止める事は可能ですが」
「いや、今だと、″ML参加者″になれば誰でも実行できるだろ？
そうじゃなくて、管理者しか使えないようにして欲しいんだ。
あと、いらないコマンドもあるし」
「は、はぁ・・・(困惑)」
えーと、ちょっとここで、背景など説明してみます。(笑)
そもそも、私はＣＧＩ書きのバイトなどやってた人間です。 まぁ副業であり、本業は農家／農協専門のフリーターで、 北海道は富良野農協あたりを本拠にしてました。 Windowsで遊んだ事もあるんですが、 もともと「メインフレームにFORTRAN」なんつー世代で、 紙テープで授業中、ASCII文字を組み合わせたミンキーモモ打ち込んでて 怒られたとか、そーゆー、ほのぼのした青春を過ごした奴で(おいおい)、 マウスでクリックとか、「それは企業秘密」ばっかの Windowsはどうも なじめない(--;;)
「ばっきゃろー、何が秘密だぁ、バラエティ番組じゃねぇぞ！！(謎)」
そんなわけで、ＵＮＩＸな世界にどっぷりとハマっていったのです。
しかし、FORTRAN至上世代には、どうもＣの感覚というものもダメなわけで。 「アルゴリズム」って奴を、極力そのまま書ける言語が理想なんですが、 Ｃというのはずいぶん電算機寄りで、そういう風にはできてないみたい。 システムを書くには面白そうだという印象を受けたんですが、 簡単にメールを振り分けたり、定型業務をやるような用途にちょっと・・・。 私は古い人間なんで、システムそのものには興味がないわけで、 自分の解きたい課題が解ければ、何でもいいわけです。 で、UNIXとperlはまさにドンピシャであり、私の用途に合っていたのです。
「ベストではない。しかし、ベターではあった。」ってとこですか(^^)
まぁそんな私なんですが、Perlに触れてからの日数があまりにも浅かった。
まともな実装も作った事ないのに、いきなりmajordomoの改造は ちょーっと荷が重すぎた(;_;)。
それに、ネットワークの事やＵＮＩＸの事を知らなさすぎた。 メールのやりとりは、一種の「通信」なわけで、 無線をやるのには電波の事だけでなく、無線運用上の慣習も知らなくちゃ ならないのと同じで、ネット上の通信にも「規則」「慣習」が あるだろうと思ったのです。 UNIX等の知識も必要だけど、それだけでは絶対ダメ。
で、友人に聞いてみたら、 rfcとか Net Newsを見ればだいだい、おぼろげな とこがわかるのでは？という事だったので、 (さすがに賢明な彼は、「参考にはなる」程度にしか言わなかった) それを調べる事にしました。
そこで「無知な初心者」であった私が学んだのは、こんなとこでした。
ヘッダーに個人情報が乗っかってしまう。
改変して隠す事もできるし、転送ホストなどという
便利なものもあるが、それらはネット上では嫌われている。
最大の理由は、本名を名乗らずに馬鹿をやらかす人間がいるからだ。
(他にも、転送不良になりやすいなど色々あるが、最大のものはコレ)
一部では、本名を語らぬものは信用しない、という慣習もある。
つまるとこ、「人間の本性は悪である。だから、備えねばならない」
というわけなのだろう。
けっこう虚しいものを感じたが、それが現実なのかもしれない。
だが、たとえそうであったとしても、個人情報を隠したいという
要望は多い。
過去にイタズラされたとか、立場を明かすとモノが言いにくい、
などの人々が存在するからである。
全て匿名で討議というと、何やらうさんくさい感じもするが、 閉鎖的環境では、これが有効な事もある。 全然しゃべらないような奴が突然饒舌になったり、 小心者から大胆なアイデアを引き出したりする事ができるのだ。
たとえば、何人かの人間で討議する時、 「いいだしっぺの法則」とか、「提案」と「実行」、 「問題提起」と「解決策」などをセットにする場合がよくある。
しかし、企業等においては、この方法は効率が悪い。 くだらなくても実現不可能でも何でもいいから、 提案でも不満でも、まずはとことん吐き出させる。 で、それをつきあわせて、みんなで対策を考える方が合理的である。 いわゆる、「ブレインストーミング」な発想なのだが、これを いろいろな立場の人間が集まってやる場合、 「おれの提案だとわかったら、あいつは気を悪くするかな」とか 「社内の立場が悪くなるかもなぁ」とか、いろいろ障害が出る 事がある。
そんな時、匿名な環境はたしかに有効なのである。
２．メールやニュースのインターフェイスは、いたずらの対象になりやすい。
簡単だし普遍なので、よいターゲットである。 また、一つ間違えると「穴」になったり、メールループの 発生要因になりうる。
注意は万全にしなくてはならない。
３．通信を円滑にするための規定がいろいろあるが、守られていない
RFCの基準は「こうすれば？」であり拘束力はないが、
通信というものは規格があってはじめて成立するものであり、 その意味でRFCを一つの基準とするのは、有効な方法である。
まぁ、間違っても、 単一メーカーが既存の規格を破壊し、健全な通信を 妨害するようなムチャクチャをやってはならない。 そんなメーカーに通信ソフトを設計する資格はない。
しかし、現実にはそれを堂々とやっているメーカーがある。 ユーザーとしては、そんなものは排除してしまえばいいのだが、 管理者はそういうわけにもいかない。
意図して変なメールを飛ばしてくるようなユーザーは 排除するべきかもしれないが、 自分が変なメールを打っていると知らずにやっている者まで 排除してはならないからである。
これらを考えつつ、実装にこれを反映する事を考えてみました。
ａ．秘匿性の向上
要望が多い以上、ＭＬそのものの存在は隠さねばならない。 間違っても、サーバー上のＭＬ一覧を吐き出したり 参加すらしてないＭＬのメンバー一覧を返してはいけない。 参加している場合も、普通のメンバーは一覧を得る事ができず、 管理者がパスワードを打った場合のみ、情報を得られるように 実装を変更する必要すらあった。
「議長以外は、誰も互いの存在すら知らない」環境さえ 構築できるようにする。
なお、デフォルトでは「議長」ですら、メール配送先一覧に 名前がないと閲覧できないようになっている。 「参加者である事」があくまで前提である。
ｂ．ヘッダの加工
subjectに通し番号が付かないので、付ける事にした。 普通ならここで、distribution等を使うのだろうが、 ちょっとワケがあって、できればmajordomoだけでやりたかった。
そこで、ａでの作業ついでに、雑誌を参考にしながらmajordomoの ソースをいじって、通し番号を付加できるようにした。 通常は不要な改造だろうし、最新のmajordomoではどうなっているのか 知らないので、ここには書かない。 実際、わりと不細工な実装で、同一人物からの投稿がダブると タマに誤解して番号がダブるという、情けない不具合もある。 これにはさすがに弱ったが、窓の杜ＭＬなみの流量でもないと なかなか発生しないので、うちのニーズでは問題がほとんど 起きてない。 (もちろん、放っておくわけにはいかないので対策準備はしている。)
また、配送関係でちょっと独特の問題があって対処したが、 (特殊なサーバーを使っている顧客がいて、それらとの接続のために sendmailまわりの設定をいじったり、いろいろ配送上の工夫をした) これの対処ミスで、NIFTYで弾かれたメールがループするという ろくでもない不具合も一度、発生してしまった。 幸い、発見がけっこう早かったのと、 該当ＭＬのオーナーが知人だったので、なんとか許していただいたが、 本当ならえらい事である。情けない話である。
ｃ．ダイジェストの日本語Subject問題
ＭＬによっていろいろあるだろうが、日本人なのだから、 日本語のSubjectくらい使いたいではないか。 うちでは迷わず採用となった。
ところが、ダイジェストではMIME化されたままになってしまう。 最初のヘッダーでは問題ないが、二通め以降はダメ。 単に追記しているのだから当然といえば当然なので、 これをdecodeする事にした。
しかし、この対処が意外にも時間がかかってしまった。 原因は、テスト用に動かしていたＭＬで、全文文字化けが発生した事。 調査してみると、対象メーラーが生の半角カナつきシフトＪＩＳを 投げている事が判明したのであるが、さて、 これをどうするかでケンケンガクガクの討議になった。 趣味のシステムなら単に排除すればいいのだが、 商用システムでは何とか対応すべきではないか、と。
だが結局、このままの形で導入する事になった。 シフトJIS「にも」対応する事はできる・・・しかし、 それをするのはなかなか面倒であり、現在のシステムでは これ以上負荷をかけたくない事、 また、負荷をかけずに対応する方法もあるにはあるが、 それをやると今度は、現在組み込まれている、半角カナよけの トラップ処理とか、いろいろ入っているものに影響の出る 可能性がないか、という事があった。
-- ようするに、どの処理も「ＭＳ対策」だったりする(笑) --
幸いな事に、うちの顧客やＭＬ参加者には、ＭＳのメーラーの ユーザーがほとんどいない。 ひとつには、うちそのものが「おすすめできません」ときっぱり 明言しているというのもあるだろう。
初心者は繁雑な設定を嫌がるものなので、たとえMSのメーラーで 妙ちくりんな設定になっていても、仲間うちでは問題ないからといって そのまま使っていたりするのだ。 それではまずい。イントラネットならいいが、インターネット上なのだ。
・・・というので、「ならばメーラーごと非推奨にしちゃえ」と とりあえず商用のEudora Proを筆頭に、いくつかのメーラーを 推奨している。 それが幸いしてか、ほとんどのＭＬオーナーは、メーラーの選定や 設定について考えてくれるようになった。
そうでないＭＬでも、仲間うちでのメールの やりとりで不具合が発生したら、メーラーの変更や設定の見直しを 仲間どうしでやっているらしい。
そのため、「問題が出たらオーナーと相談する」という 形式で運用しているが、今のところ問題の発生は確認されていない。
あと、「技術はあるがUNIXの文化を知らない管理者」が jcode.plやnkfを駆使した私の仕事に不信を持ったとか 情けない問題もあったりしますが、それはここで言う問題では ないと思うので別の機会に譲るとしましょう。
さて、実装であります。 といっても、最新バージョンの話ではないし、お手本になるような 実装でもないので、だいたいのところをかいつまんでお話するに とどめたいところです。
まず、コマンド機能の抑制。 majordomoのコマンドメール処理は、 受け付け判定と実行部が完全に分離していて、 しかも、受け付け部は 管理者コマンドと一般向けコマンドの処理が、 これまた完全に分離しています。 よって、コマンドを使用不能にするには、そのコマンドのエントリーを見つけて そこの判定文をコメントにするだけでいい。 また、あるコマンドに管理者権限をつけるには、一般コマンド側のエントリーを 削除して、そのif文をそのまま管理者用のところに追加するだけでいいです。
これだけで、たとえばwho hoge-mlで使えていたコマンドを、 who パスワード hoge-mlにする事ができてしまうのです。
見つけ方は、 ||がいっぱい並んでいる部分を探すだけ(笑) 特にテーブルなど作らず、if文の軍団で片付けているから発見しやすい。
次に、ヘッダの加工・・・これはいささか面倒です。 当初から、ユーザーの要望に応じてかなり改造して 運用していた・・・が、某氏の公開型の公式ＭＬが移動 してきたとたんに、問題が発生して元に戻しました。 エラーメールに対する考慮が足りなくて、あるタイミングで NIFTYで弾かれたメールがループしてしまったのでした(泣)。 なんとも情けない大失敗です、事実ではあります。
まぁ加工といっても、Reply-To等の行き先が変だったので、 これを修正しただけではあります。 当初、MS Internet MailとEudora Proユーザーの混在するＭＬで 両者でFrom:やReply先の表示方法が違っていたのに対応しようと あれこれいじっていたのが原因だった・・・が、 今にして思えば、MS絡みだし、sendmail.cfも少しおかしかった頃でして、 そこらへんに何か原因があったのかも・・・。 現在は元に戻しているが問題は確認されていない・・・。
Subjectの通し番号は、UNIX Magazineの記事を参考にしました。 これは、現在は売り切れになっている号のため、仕方なく 知人に見せてもらいました。
また、うちのＭＬシステムは、デフォルト設定はクローズドで、 Private Get等も全てオンになっています。 これを必要に応じて修正します。 「おろ、変じゃない？コマンドメールでいじれるじゃん」って、 たしかにそうなのですが、あれって、まるまる上書きみたいなので けっこう、まるごと*.configを飛ばしちゃって初期設定になっちゃう 人が続出したため、コマンド一覧から除外したんです。 もっとも、使用方法を知っていれば使う事は可能なんですが・・・。
だから、うちのＭＬは、知らない人が契約すると「オープンで」 「クローズドで」とかいろいろ縛られてしまうんですが、 知っている人ならゴリゴリいぢりまくれるようになっているのです(笑)。 でも、これは正解だと思います。たとえば、ＷＷＷで全てのパラメータを 設定可能にしたとしても、現状のＭＬのオーナーのほとんどは、これを 自由にいじる知識なんてないんですから。 (もちろん例外もいますが・・・「Subjectってなーに？」と聞かれると、 やっぱり私は「うーん」と思ってしまうのです(--;;) ) むしろ、変にいじってグチャグチャにしてトラブルの元になるより、 この方がいいだろうと思ったしだいです。 いじれる人なら、メールコマンドでもやっちゃいますし、質問がくれば ちゃんと応えるようにもしております。
ちょっと長くなりましたが、そんなこんなでmajordomoをいじくって 独自の方法で運営しています。 現在もまだ、バージョンは1.93です。なお、バージョンアップは 検討中ですが、しばらくはこのままでしょう。
また、うちはmajordomoインストール時のデフォルト設定はほとんど使って いません。たとえば、インストールするディレクトリも変だし(笑)。 ここらへんはいろいろ理由がありますが、最大の理由は「ディスクに 余裕のある区画に入れた」というのがあったりします(笑)。 最近、アーカイブとかが増えてけっこう、アレな状況なんですが・・・。
では、夏の「寒さ*(1)」にもめげず、楽しいＭＬライフを・・・。
*(1) サーバーのそばはクーラーがガンガンなので(;_;)
私、冷房が苦手なんです〜(T_T)
Copyright 1997 by 清藤＠HOKKAI