Shunichi.Hosono.com
個人的メモから始めるインターネット活用の足跡
| Personal | Business | ||||||
|
|
個人的メモから始めるインターネット活用の足跡
|
|
@niftyを利用するようになってから、スパムメールに煩わされることがほぼ皆無になった。受信するスパムメールの数は相変わらず増え続けているので、それだけ振り分ける量が増えているということになる。
将来的には、スパムメール自体が絶滅して０件になることが望ましいのだが、毎日大量に来ているはずのスパムメールが突然来なくなってしまうと困る場合もある。
実は先日、スパムメールが突然来なくなったので、おかしいなぁと思った。
そしてよくよく調べて見ると、メールサーバーのスプールが一時的に膨れあがって、配送処理に遅延が生じていたことに気付いたのである。
その原因になったのがスパムメールであることには間違いないのだけれども、スパムメールが定期的に来るということは逆に言えば、メールが無事に受信できているという意味でもあり、安心につながっていたのだった。
たしかに今は、メールの受信ログのような意味でスパムメールを取り扱っているが、スパムメールをありがたく考えることだけは絶対に避けたい。
せいぜい、ほどほどの量で無害ならば、少しは役立つこともあるのだと感じる程度である。
このブログには以前、何度か、私のスパムメール対策について書いたことがある。
私のメールアドレスには毎日数千件のスパムメールが送信されてきていて、
それは今でも続いていて、増えることはあっても減ることはない。
もう十四年近く使っているドメインで、昔はいろんな場所でアドレスを
公開していたから、今さらどうすることもできない。
それでも、何もしないわけにもいかないので、
・受信するＩＤを限定し使い分ける
・スパムフィルタを使う
・アンチスパムソフトを使う
・spamcopのアカウントを使う。
等、いろいろ試行錯誤して、数年前に何とか、
一日二百通程に減らすことができたが、それでも苦痛だった。
ところでその後について、このブログに書くのをすっかり忘れていたが、
今はもう、スパムメールの悩みはすっかりなくなっている。
数年前、ソニーの向け法人向けプロバイダ bit-driveの
アンチスパム機能を利用する機会があって、試してみたところ、
理想の性能だったのである。
スパムメールが高確率でフィルタされることも大切だけど、
受信したいメールが誤ってスパムに振り分けられることがない、
という点において、素晴らしい成績だった。
そこで採用されているシステムが、シマンテックの Brightmail という
ものであることを知ったので、これを採用している身近なプロバイダを
探してみたところ、@nifty が該当しているようなので、
さっそく申し込んでこれをメインにした。
これ以来、スパムメールの悩みはすっかり消えた。
今までで、誤判定は２～３件くらいはあったが、べつに受信しなくても困らない
メルマガだったので、実質、問題は発生していない。
スパムフィルタについても、もちろん完璧ではなく、スパムメールを
完全に０にすることまではできていないが、@niftyのウェブメール上での
迷惑メール対策機能を併用することによって、良い結果が出ている。
というわけで、スパムメールに悩む方は、@nifty のメールアドレスを
メインにすることを試してみると良いだろう。
Windowsサーバーで突然、外部からのインターネット接続ができなくなった。
ローカルではＷＥＢも閲覧できていて問題ないのに、外部のＰＣから接続するとＰＩＮＧすら通らない。
サーバーを何回再起動しても、状況は変わらない。
これは絶対に、ファイヤーウォール関連の問題だと思って、ウィルス対策ソフトやファイヤーウォールソフトを片っ端からアンインストールしてみたのだが、状況が改善されない。
インターネットサービスマネージャーを開いてみると、
「スナップインを初期化できませんでした」というエラーが出るので、何かおかしいと思った。
結局、システムファイルチェッカーを実行して、再起動したら、すべてが直ったのだが、
こんな便利なツールがあったことをすっかり忘れていた。
ちなみにこれは、スタートメニューから「ファイルを指定して実行」で、
sfc /scannow [Enter]
と入力するだけで、実行できる。
途中、WindowsＸＰのＣＤ－ＲＯＭのマウント要求が来たら、
システムファイルが壊れていたので修復されたことになる。
今日は、１０回くらいマウント要求が来たので、
システムファイルがいくつか壊れていたために、
何かのサービスが正常に起動していなくて、
それに依存していたインターネット関連のサービスが
正常に動作していなかったのだろうと思う。
遠回りしたけど、解決してよかった。
マイティサーバーという会社の専用サーバーを使い始めたが、使い始めて間もなく、ディスクエラーらしきメッセージが頻発するようになった。
RAID構成になっているので問題なく動作しているけれども、サポートセンターに問い合わせたところ、筐体のマシンを変更してくれることになった。
このサーバーにはPLESKというコントロールパネルが搭載されていて、既にいくつかのサイトを設定していた。このサイトもそのうちの一つだけど、一から移行するのは面倒だ。
そこで、サンプルとしてついていたスクリプトを使って、旧マシンの内容をバックアップして、それをそのまま新マシンの方にリストアしてみることにした。
新マシンでリストアを行なって問題なく終了したので、再起動をしたところ、当然のことながら起動しなくなってしまった。いや、起動しているのかもしれないけど、ネットワークで接続できないので、どういう状態になっているのか、さっぱり分からない。
仕方がないので、OSの再インストールを依頼して、最初からやり直すことにした。
恥ずかしい話だけど、初心者的ミスをおかしてしまったようだ。
別のマシンに全ファイルを戻して、うまくいくはずがない。
ところが、マイティサーバーは、すごかった。
シリアルコンソールという機能が標準装備されていて、サーバーのネットワークが切断されていても、サーバー画面を見ることができて、どんなエラーが表示されているのかが分かるようになっているのだ。
サーバーを再起動すると、サーバー起動時に表示されるBIOSのメッセージも含めて、プロンプトが表示されるまでのすべてのメッセージが表示されるので、どこでどんなエラーが出ているのかを調べることができるようになっている。
今回の場合、サーバーは起動されているけれどもネットワークが有効になっていなかった。起動時のメッセージを見ると、IPアドレスが同じネットワーク上で重複しているので［NG］という表示だった。さっそく、
/etc/sysconfig/network 内のゲートウェイアドレスと、
/etc/sysconfig/network-scripts/ifcfg-eth0 内のIPアドレス等
の設定を変更して、再起動したら、ネットワークは復旧した。
さて、続いて PLESK を起動してみたところ、ログインパスワードは元のサーバーに設定していたものを入力したら、うまくいった。
IPアドレスの変更については、コントロールパネルの操作で変えることができたけど、こればかりは１ドメインずつ手動で行なった。
これでうまくいったかと思ったけど、いくつかのメニューでエラーが表示された。
新旧料サーバーを徹底的に比較してみたところ、いくつかファイルの所有者やパーミッションが異なっている部分があったので、それを直してみた。
また、新マシンのファイルの中身をすべて検索して、旧ＩＰアドレスを参照している部分を新ＩＰアドレスに置き換える等の処置を行なった。
それでも直らないので、基本に帰って、障害調査をしてみることにした。
PLESKの操作時に記録されるエラーはどこに格納されているか？ を調べてみたら、
/usr/local/psa/admin/logs/httpsd_error_log
にあることが分かった。
その中身を見ると、
というふうになっていた。これはつまり、libgcc_s_plesk.so.1 がないというエラーのようなので、ファイルを検索してみると、旧マシンでは見つかったが、新マシンでは見つからない。さっそくこのファイルをコピーしてみたところ、見事に解決した。
でも、こうなる前にいくつか余計なログファイルを見て、余計な調べ物をしていた。Cobaltサーバーに比べると、PLESKに関する技術情報は少ない。
SWsoft社 の knowledgebase (http://kb.swsoft.com/) か。
エントリープラン（専用レンタルサーバー）
スタンダードプラン（専用レンタルサーバー）
ここ４ヶ月の間、スパムメールの数はますます増加し、厳しいフィルタリングを施しているにも関わらず、１日５００通を下回ることはなくなった。
フィルタリングをしなければ１日５０００通を超えているので、効果はあるけれども、これ以上減ることはなさそうである。フィルタリングをさらに厳しくすると、誤判定が増えるので、さらに手間がかかる。
私の場合、フィルタリングは３段階で行なっている。
１段階目は、ＰＯＰサーバーの段階でのブロック
２段階目は、Spamcop.net のメールボックスでのフィルタリング＆ウィルス駆除
３段階目は、メールクライアント側での振り分け
最近増加したスパムメールを分析してみると、メールアドレスの＠マークの前のＩＤ名をでたらめにつけて、大量に送りつけてくるものが大半で、同じ内容のものが大量に届く。
Spamcop.net もかなりの確率で振り分けてくれるけれども、絶対量が増えれば、それに比例して数が増えていくので、やはり第１段階目でのフィルタリングが重要になってくる。
今までは、フィルタリングをくぐりぬけて受信したスパムメールを時々分析して、＠マークの前のＩＤ名を狙い撃ちしてブロックしていたけど、それも限界だ。毎日のように新しい名前に変わって、同じ文面のメールが大量に送りつけられるのだから、いくらやってもきりがない。
やはり、使うアドレスを決めておくというのが最も有効な対策だ。
今までに受信したメールボックスから分析してみると、私の場合は約２００種類のＩＤを使っていたので多すぎるかなと思ったけど、これ以外をすべて受信時に消去してまえば、Spamcop.net での処理も減る。
というわけで、数日前から、受け取るスパムメールの数は５０通以下に減った。
スパム退治をゲームのように楽しめるようになったら、これでビジネスを始めるかもしれない。
４ヶ月ぶりに、このブログを再開する。
MovableTypeをバージョンアップしようとして、エラーが出るようになってからずっと放置していた。
更新はできなかったけど表示はできたので、特に切羽詰った状態ではなかったので、ついつい後回しになってしまったというのが本音である。
実は年末年始も、復旧を何度か試みたけど、どうしてもうまくいかなくて一時的に諦めていた。
このブログは、バークレーＤＢを使っていたので、/db フォルダ内のデータベースさえ保持していれば、うまく修復できると簡単に考えていたけど、それが甘かった。
ソフトウェアを再インストールして正しく設定したはずなのに、「Invalid login. 」と表示されて、ログインができなくなってしまったのである。データベースへのアクセスが失敗していることが原因なのだけど、最新のバックアップを戻しても状況が改善されないのだから仕方がない。
行き詰ってしまったので、他のサーバーにも移転してみたけど、同じところでつまづき、結局、バークレーＤＢのバージョンの問題らしいというところまで進んだ。
今日は、「db_upgrade」コマンドや「dumpdb_dump」コマンド等によるデータベース修復も試してみたけど結局うまくいかず、最終的には、残されたhtmlファイルから修復するしかないという結論に達して、サーチエンジンで探しまくった。
「html2mt」というキーワードで Yahoo Japan! で検索した時に、スクリプトが直接ヒットしたので開いてみたら、「指定されたページが見つかりません。」の画面が出たけど、キャッシュの方を開いてみたら、スクリプトが画面に表示された。
http://cache.yahoofs.jp/search/cache?p=html2mt&ei=UTF-8&fl=0&meta=vc%3D&u=yusukebe.com/archives/pic/040428/html2mt.pl&w=html2mt&d=Nhc72Q0DMIMb&icp=1&.intl=jp
というページである。
残されているhtmlファイルを１つのフォルダに集めて、順番どおりになるようにファイル名を変更して、同じフォルダ内で html2mt.pl スクリプトを実行したら、インポート用のテキストファイルが作成された。
あとはテキストファイルで修正を加えて、インポートしたら、あっけなく成功した。
ファイルのバックアップだけでなく、ブログのバックアップは「エントリーの書き出し」で、時々保管しておくようにしよう。
ここ数日間、頭を悩ませていたRaq550サーバーの cce の障害がやっと解決した。
直接的な原因は、 /usr/sausalito/schemas/base/am/am.schema ファイルが壊れていたことだった。なぜ壊れたのかは分からないけど、このファイル１つが壊れただけで、ネットワークもＨＴＴＰサーバーも正常動作しなくなってしまったことは事実である。
原因が分かったので、ファイルを修復して再起動したら、何事もなかったかのようにサーバーが順調に稼動を始めた。
諦めてＯＳをリストアしてしまえばそれで解決するけれども、それでは何のノウハウも得られないし、経験値も稼げない。今回の障害は、管理画面が開けないことを除けば他のサービスに実害はないので、できるところまで頑張ってみるだけの価値はある。
経験豊富でスキルの高いシステム管理者ならばおそらく、この障害はすぐに解決できるレベルのものだと思う。私の場合、原因分析にかなり遠回りをしたあげくに、偶然のひらめきで解決できたという状況だったので、単にラッキーなだけだった。
このまま終わってしまえば、再発した時にも同じように頭を悩ますことになるはずなので、どうやって解決したのか、少し分析してみようと思う。
「今日こそは絶対に解決するぞ！」と決心したのが昨日の夜だった。
まずは定石どおり、システムログ（"/var/log/messages"）を分析して、最初に出たエラーを分析してみることにした。
------------------------------------------------------------------------------------------- Sep 2 00:44:23 www cced[278]: Cobalt Configuration Engine (CCE) version 0.80.2 Sep 2 00:44:23 www cced[278]: Copyright (c) 1999,2000 Cobalt Networks, Inc. Sep 2 00:44:23 www cced[278]: starting up (pid 278) Sep 2 00:44:23 www logger: cce_construct started Sep 2 00:44:23 www CONSTRUCTOR: ----- constructing ----- Sep 2 00:44:23 www CONSTRUCTOR: /usr/sausalito/constructor/base/system/10_addSystem.pl Sep 2 00:44:23 www logger: ***** cce_construct: /usr/sausalito/constructor/base/system/10_addSystem.pl Sep 2 00:44:26 www cced(smd)[278]: Invalid type "amstate" for "ActiveMonitor.ECC.currentState" Sep 2 00:44:26 www cced(smd)[278]: Removing class "ActiveMonitor", namespace "ECC" Sep 2 00:44:27 www CONSTRUCTOR: Use of uninitialized value in scalar assignment at /usr/sausalito/perl/I18n.pm line 120. Sep 2 00:44:27 www CONSTRUCTOR: /usr/sausalito/constructor/base/alpine/11_configureSystem.pl Sep 2 00:44:27 www logger: ***** cce_construct: /usr/sausalito/constructor/base/alpine/11_configureSystem.pl -------------------------------------------------------------------------------------------
この中で最初にエラーらしきメッセージが出ているのは、次の８行目である。
Sep 2 00:44:26 www cced(smd)[278]: Invalid type "amstate" for "ActiveMonitor.ECC.currentState"
この行に含まれるキーワードを Yahoo と Google を使って検索してみたら、満足な答えは見つからなかった。特に、"amstate"って何だ？ という問題が気になって、これを調べるのに無駄なエネルギーを使った。これが分かればすべて解決すると思ったので、ここにエネルギーを割くのは間違いではないと思ったからである。辞書を引いても出てこないので、何かの略語だろうか？ アメリカンステートの略か？ アムステルダムの関係か？ 等を推測したが、どれも関係なさそうだ。
結局分からず、「ActiveMonitor」「ECC」「currentState」のキーワードで、インターネット上を探してみたら、やはり Cobalt のソフトウェアである、いくつかの Perl モジュールでエラーを吐いているらしいということは推測できた。最悪の場合、Perl モジュールを順番に追う覚悟でいたけれども、とりあえずこの３つのキーワードを含むモジュールだけを調べれば良いと考えて、解決に一歩近づいたような気がした。
その時に突然ひらめいたのが、amstate は、「ActiveMonitorのcurrentState」の略ではないか？というものだった。だから、 am という名前がつくディレクトリだけに的を絞れば解決できそうだと考えた。
さっそく am の名が付くモジュールを開いて中身を見てみたが、プログラムを見たところでますます分からなくなるだけである。プログラムが突然壊れることは考えにくいので、設定ファイルか状態ファイルが壊れたのだろうと思って、Perlモジュールの中に書かれているファイルの パス名とファイル名 をピックアップして見るようにした。でも順番に解析していくと時間がかかりそうで疲れてくるので、途中でやめた。
とりあえず、am の名を含むディレクトリを探して、その中から拡張子が .pl 以外のファイルを調べてみることにした。すると、次のようなディレクトリが該当した。
/usr/sausalito/perl/AM
/usr/sausalito/conf/base/am/
/usr/sausalito/confconstructor/base/am
/usr/sausalito/handlers/base/am/
/usr/sausalito/schemas/base/am/
最初に見たのは、/usr/sausalito/conf/base/am/am.conf ファイルである。この中身を見ると、「ActiveMonitor.ECC.」というキーワードが見つかったけど、特におかしな様子はなかった。
次の３つのディレクトリ内は .pl のファイルしか入っていなかった。
そして /usr/sausalito/schemas/base/am/ のディレクトリを見たら、 .pl 以外のファイルがいくつかあったので、ここを徹底して調べてみることにした。
できれば全部印刷してみて、正常に動作している Raq550サーバーと比べてみたいので、ＦＴＰを使ってこのディレクトリをローカルＰＣのハードディスクにダウンロードを始めた。
ところが、最初の am.schema というファイルのダウンロードに異常に時間がかかることに気が付いた。ダウンロードのサイズが１００ＭＢを超えてもまだ終わりそうにない。さすがにおかしいと思ってダウンロードを中止し、ＳＳＨで 「ls -l」コマンドを入力してみたところ、次のように表示された。
------------------------------------------------------------------------------- [root am]# ls -l 合計 24 -rw-r--r-- 1 root root 2892176555428481344 2月 19 1953 am.schema -rw-r--r-- 1 root root 2359 4月 12 2002 am_base.schema -rw-r--r-- 1 root root 1371 4月 12 2002 ecc-am.schema -rw-r--r-- 1 root root 1633 4月 12 2002 fans-am.schema -rw-r--r-- 1 root root 1863 4月 12 2002 temperature-am.schema [root am]# -------------------------------------------------------------------------------
何だ、このファイルサイズは！？ と思って、正常な Raq550サーバーの方を見てみると、やはり異常な状況になっていることが明らかに分かった。この瞬間に、この問題は解決したと確信できた。
さっそくこのファイルを削除して、正常な Raq550サーバーからＦＴＰでダウンロードしたら、ファイルサイズは次のように正常に戻った。
-rw-r--r-- 1 root root 2359 Apr 12 2002 am_base.schema
さっそく 「/etc/rc.d/init.d/cced.init start」 コマンドで cced を起動したら、こんどはシステムログにエラーを吐かなくなった。「/etc/rc.d/init.d/cced.init status」コマンドで状態を確認すると、
cced (pid 278) is running...
と表示されたので、サーバーを再起動してみた。
そうしてすべて元に戻ったことが確認できた。
今回はＦＴＰによって異常ファイルサイズを発見できたけど、実はもっと前に発見できたはずである。この障害が発生した当初、 /usr/sausalito/ ディレクトリ内を全部ローカルＰＣにダウンロードするために tar コマンドでアーカイブしようとしたら異常に時間がかかって中断したことがある。思えばこの時に気づいてもよかったのである。
今後は、予期しないことが起こったら、まずはすべてのディレクトリ一覧の詳細をテキストファイルに落として、正常動作のRaq550サーバーと比較してみることを試すようにしたいと思う。
サーバー起動時に CCE（Cobalt Configuration Engine）の起動が失敗しているようで、ＷＥＢサーバーが正しく起動しない。
/etc/rc.d/init.d/cced.init status コマンドを入力すると、
cced dead but subsys locked と表示される。
/etc/rc.d/init.d/cced.init start コマンドを入力すると、
Starting cced: cced
Running CCE constructors:
という２行が表示されて、しばらく時間がかかるが、
やはり起動はしていない。
システムログを見てみると、次のようなエラーが発生していた。
-------------------------------------------------------------------------------- ug 30 23:04:40 www 8月 30 23:04:40 CONSTRUCTOR: Could not connect to /usr/sausalito/cced.socket: 不正なファイルデスクリプタです Aug 30 23:04:40 www 8月 30 23:04:40 CONSTRUCTOR: /usr/sausalito/constructor/base/ftp/syncFTP.pl Aug 30 23:04:40 www 8月 30 23:04:40 admin: ***** cce_construct: /usr/sausalito/constructor/base/ftp/syncFTP.pl Aug 30 23:04:41 www 8月 30 23:04:41 CONSTRUCTOR: Could not connect to /usr/sausalito/cced.socket: 不正なファイルデスクリプタです Aug 30 23:04:41 www 8月 30 23:04:41 CONSTRUCTOR: /usr/sausalito/constructor/base/power/syncWakemode.pl Aug 30 23:04:41 www 8月 30 23:04:41 admin: ***** cce_construct: /usr/sausalito/constructor/base/power/syncWakemode.pl Aug 30 23:04:41 www 8月 30 23:04:41 CONSTRUCTOR: Could not connect to /usr/sausalito/cced.socket: 不正なファイルデスクリプタです Aug 30 23:04:41 www 8月 30 23:04:41 admin: ***** cce_construct finished Aug 30 23:04:41 www 8月 30 23:04:41 CONSTRUCTOR: Aug 30 23:04:41 www 8月 30 23:04:41 CONSTRUCTOR: ----- done ----- --------------------------------------------------------------------------------
スクリプトを１つずつ追って調べていくしかないかもしれない。
いろいろ調べたけど、見当がつかない。
最悪の場合、BlueQuartzをインストールして一から分析する。
先週、Raq550サーバーに突然アクセスできなくなった。
サーバー障害なので、業者さんに再起動を依頼したら、迅速に対応してくれたようなのだが、状況は改善されず、しつこく再起動の依頼を繰り返した。
ところが返事は、「サーバーは無事に稼動していてオンライン上にある」ということだったので、それ以上の対応をしてくれる見込みはない。実際、ＰＩＮＧも通らず、あらゆるサービスが利用不可能だったのでそのことを伝えても、返事は変わらなかった。
もしかしてと思って、以前のトラブルの時に放棄した同じネットワーク上にあるサーバーにtelnetでログインして、ＰＩＮＧを試してみたら、サーバーが生きていることを確認することができた。
そこで、telnet上でさらにtelnetコマンドを入力して接続してみて、接続に成功した。
さっそく、「netstat -rn」コマンドでルーティングを表示して、２つのサーバーの設定を見比べてみたら、問題のサーバーにはデフォルトゲートウェイとローカルループバックの２つの行が消えていることに気づいた。
とりあえず、デフォルトゲートウェイのコマンドを入力してみたところ、インターネット上でＰＩＮＧが通り、普通にＳＳＨでログインできる状態になった。
でもそれで解決ではなかった。ＷＥＢサーバーが起動しないのである。業者さんによれば、このサーバーはもともと「Perl 5.6」なのに「Perl 5.8」がインストールされたために動作しなくなっているのでＯＳをリストアした方がよいとのことだった。
でもそれは違う。きちんとＰｅｒｌのパスは元に戻しているのでもともと問題なかったのである。もう業者のサポートを期待できず、自力で解決するしかないと悟った。
まず、「 /etc/rc.d/init.d/httpd restart 」のコマンドを起動して、ＷＥＢサーバーを再起動したところ、httpd.conf の 410行で syntax error が出ていた。
その行には
#
という記述があった。
オリジナルの設定ファイルと見比べてみると、ここにコメントがあることが間違いであることが分かった。どうやら、業者さんが設定をいろいろ変えてコメントアウトして試行錯誤してくれたらしく、httpd.conf ファイルのコピーがいくつかあった。でもとうとう諦めて、コメントをつけたままにしてしまったらしい。
結局、httpd.conf ファイルの中の、
とりあえず仮復旧はしたが、まだ前途多難である。
・再起動するとデフォルトゲートウェイの設定が消える
（/etc/sysconfig/network の設定は問題ない）
・ｃｃｅが起動しないので、管理画面が開けない
・１５分に１回、「システムの状態に関するお知らせ」の警告メールが来る
掲示板に英語のスパム書き込みがあまりにも多いので、日本語を含まない投稿をエラーにするようにした。
これで楽勝かと思ったら、甘かった。英語のスパムコメントは、それでも来る。
もしかして、わざわざ２バイト文字を入れて投稿してくるのかもしれないし、偶然かもしれない。たとえば、次のような書き込みである。
文字化けかもしれないけど、たしかに漢字が２文字ほど含まれている。ｈｔｍｌタグは除去してある。早く退治しよう。
---------------------------------------------------------------------------
投稿者 casino casino for casino 4 online best cheats hoyle 日時 2005 年 6 月 25 日 19:43:21:
casino casino for casino 4 online best cheats hoyle
document.write("body {display:none;}http://enter.want-gay-sex.com?cas");document.links("cl").click();
muckleshoot casino grand casino in tunica mississippi casino game rule las vegas paris casino vegas casino stardust casino las vegas grand casino mill lacs aladdin hotel and casino paris hotel and casino in las vegas caesars palace hotel casino online casino black jack circus circus casino las vegas online sportsbook and online casino games star city casino casino online online internet casino grand casino gulf port hollywood casino tunica online strip poker poker software online games casino casino buffalo new york sporting club casino de la coru羈acreek casino colorado gambling terribles casino las vegas casino berlin club online casino amp sportsbooks mgm grand hotel and casino las vegas new york new york hotel casino casino gambling game new york hotel and casino las vegas indian casino strip poker 2 gold eagle casino grand casino milacs grand victoria casino indiana casino magic mississippi palace casino cass lake casino clay chips american poker hollywood casino tunica mississippi grand casino de gen羣ve alladin hotel and casino las vegas casino chips buy grand casino boloxi nouveau casino de paris le casino de paris sahara las vegas hotel and casino tropicana casino las vegas hollywood casino tunica ms san felipe casino hollywood paris las vegas hotel and casino grand casino hotel gulfport crazy vegas casino 7 sultans casino com isle of capri casino biloxi mississippi casino online game gambling websites diablo 2 gambling riviera hotel and casino las vegas best best online casino bonus online hoyle best online casino bonuses 4 casino best casino online payout hoyle for best online casino payouts hoyle
---------------------------------------------------------------------------
掲示板に英語のスパム書き込みがあまりにも多いので、日本語を含まない投稿をエラーにするようにした。
このブログも、スパムコメントの嵐にあってからはコメント書き込みを禁止にしていたが、今日からはコメントを書き込みできるように変更した。
「エントリーを書き出す」の処理で一旦テキストファイルにしてから、
"ALLOW COMMENTS: 1" を "ALLOW COMMENTS: 2" に置き換えて、
/import フォルダ内にアップロードし、
「エントリーの読み込み」を行なった。
ところがそのまま読み込みをしたら、どうやら追加になってしまったらしく、エントリーがすべて２個ずつになってしまったので、一旦すべて削除してから、再度実行したらうまくいった。
問題は、mt-comments.cgi ファイルの改造である。
まだうまくいっていない。
私のメールアドレス宛に届くスパムメールの数は、１日あたり約４０００通のレベルになってきた。
最近の傾向としては、エラー返信メールが多いことである。
でたらめの名前の後に、＠マークと私のドメイン名をつけたスパムメールが大量に送信されているらしく、それのエラーメールがまともに返ってくるのである。
ウィルスによるものがほとんどだと思う。
さて、spamcop.net のメールボックスのおかげで、それらのスパムメールのうちの大半は自動的に振り分けてもらっているが、それでも１日あたり約２００通程度は受信してしまう。
条件をきびしくすればもっと減るのだが、そうするとまともなメールまでスパム扱いになってしまうので、かえって使いづらくなる。
私が使っているメールソフト Eudora Pro でもスパムメールを振り分けてくれるけど、誤認識があまりにも多く、あまり役に立っていない。
メールの文面を見てスパムを判定する方式のものは、誤認識を覚悟しなければならない。htmlメールで来るメルマガの類はたいてい、スパムとして認識されることが多い。
スパムメール対策で一番大切なことは、正常なメールがスパムとして認識されてしまった場合に、いかに迅速にリカバリーできるか、ということである。
メールソフト等のように自分のＰＣ上で自動的に振り分けられた場合は復旧が容易だけど、メールボックス着信時に自動的に振り分けられた場合は、気づくのが難しい。
spamcop.net の場合は、スパムとして振り分けたメールは保存されているので、手動復旧が可能である。とりあえずは、日本語のメールだけを抽出して、必要なものだけを復元すればよい。
ところが最近は、それでは済まなくなってきた。日本語のスパムメールが急増したことと、スパムメールの数が増えて spamcop.net サーバーの処理許容量を超えてきたことである。検索を実行しても、タイムアウトになってしまうので、使い物にならない。そうなると、正常なメールがスパムに振り分けられてしまった場合でも、復元することができなくなってしまう。スパムの保存データを削除せずに５日間くらい溜めてしまうと、もう検索も復元も機能しなくなってしまう。
そこで、spamcop.net のサーバーから１日に１回送信されてくる「Held Mail Report」というメールを自動的に分析して、日本語のメールだけをチェックするようにしてみることにした。
Eudora Pro のフィルタ機能を利用して、「Held Mail Report」が届いたら自動的に「Held Mail」というメールボックスに移動するとともに、次のスクリプトを実行させる。
Subject に「iso-2022-jp」の文字が含まれていれば日本語メールだろうと判断して抽出し、一覧を見て目視チェックするのである。大切なメールが含まれていれば、直ちに復元手続きに入ることができる。これでしばらく様子を見てみよう。
--------------------------------------------------------------------------
Set fs = CreateObject("Scripting.FileSystemObject")
Set WSHShell = WScript.CreateObject("Wscript.Shell")
EudoraFolder = "D:\eudora\"
HeldLogFile1 = "Held Mail.mbx"
HeldLogFile2 = "Held Mail.txt"
Set fso1 = fs.OpenTextFile(EudoraFolder & HeldLogFile1, 1, 0)
Do While not fso1.AtEndOfStream
TempLine1 = TempLine0
TempLine0 = fso1.ReadLine
If Instr(TempLine0, "Subject") and Instr(TempLine0, "-2022-") Then
Msg = Msg & TempLine1 & vbCrLf
End If
Loop
Set fso2 = fs.CreateTextFile(EudoraFolder & HeldLogFile2)
fso2.write Msg
fso1.close
fso2.close
Set WSHShell = WScript.CreateObject("WScript.Shell")
WSHShell.Run "C:\Windows\notepad.exe " & EudoraFolder & HeldLogFile2
--------------------------------------------------------------------------
spamcop.net のメールボックス（$30／月）を使い始めてから、大量のスパムメールの処理に悩まされることがなくなって喜んでいたのもつかの間、再び問題が起きている。
４ヶ月前は、１日に受信するスパムメールの数が約１２００通くらいだったけど、今はそれが２０００通を越えているようだ。とはいっても、きちんと自動的にフィルタリングがかかっているので、それほど意識することもない。
問題なのは、正常なメールも時々フィルタリングにかかってしまうことである。
これは残念ながら完璧に防ぐことはできないので、フィルタリング済みの膨大な数のメールの中から救い出してやらなければならない。
救い出す基準はとりあえずは、日本語が含まれているものということで、「iso-2022-jp」が含まれているものとすると、ヒット率が高い。英語やタイ語で書かれた重要なメールはこの方法ではヒットしないので、差出人アドレスをあらかじめホワイトリストに入れておくしかない。
さて、問題は、spamcop.net のデータベースが軟弱なため、フィルタリングしたメールの数が多いとタイムアウトのエラーが出てしまうことである。
１万通を超えてくると、データベース検索が成功することはほとんどなく、もうどうしようもなくなる。
以前は１週間に１度、メールの整理をすればよかったのが、こんどは４～５日で１万通を超えてくる。このままのペースでいけば、１日のスパムメールの数が１万通を超えてくるのも時間の問題のような気がする。悪夢である。
そうなってきたら、このままの状態では spamcop.net は卒業しなければならなくなるだろうと思う。
ところで先日、まともなメールがスパムメールのフィルタリングにかかってしまっていたことに気づいた。
フィルタリングの理由を見たら、dnsbl.sorbs.net というブラックリストに引っかかっていたということだったが、調べてみたら、メールの経路の中の「222.13.249.88」という KDDI DION のＩＰアドレスがこのデータベースに登録されていた。
その他、yahooメールやhotmail等の無料メールアドレスが時々、マイナーなブラックリストに登録されていることもある。
スパムの判定基準を甘くすればそれだけ受信する数も増えるけど、厳しくすると誤判定した場合に救い出すのがたいへんである。
今後は、フィルタリング済みのメールを検索しやすいメールボックスに振り分けて、誤判断のメールをすぐに救い出せるようにしておこうと思う。
このブログのサーチ機能で今までエラーが出ていたのが、やっと解決した。
旧サーバー（Cobalt Raq3）では動いていたものが新しいサーバー（Cobalt Raq550)では動かなくなったので、その違いを調べれば簡単に解決するはずだと簡単に考えていたけど、解決までに時間がかかってしまった。
Perlのバージョンが 5.6 に上がっているので、それが原因ではないかというところまで推測できていて、エラーの場所もほぼ特定できていたけど、商用サーバーなので、うかつに設定をいじってことも許されないのでなかなか手をつけられなかった。
シェル上で、mt-search.cgi を実行してみると、次のようなエラーが出ていた。
[root cgi-bin]# ./mt-search.cgi
Use of uninitialized value in substitution (s///) at lib/MT/App.pm line 507.
Use of uninitialized value in split at lib/MT/App.pm line 508.
Use of uninitialized value in concatenation (.) at lib/MT/App.pm line 512.
Use of uninitialized value in subroutine entry at /usr/lib/perl5/5.6.0/i386-linux/DB_File.pm line 259.
他にも同じトラブルを経験している人がいるかもしれないので、サーチエンジンでこれらのエラーメッセージをそのまま入れて検索してみたけれども、役に立つ情報はさほど得られなかった。
DB_File.pm のバージョンを古いのに戻すと動作するという情報はあったけど、これを試してみたら、サーバーの管理画面が動作しなくなってしまったので、この方法はダメだった。
ちなみに、旧サーバー（raq3）にインストールされていた DB_File のバージョンは 1.65 で、このサーバーにインストールされているのは 1.72 だった。タイムスタンプを見ると、このファイルだけ新しかったので、後からアップグレードされた可能性はある。どうやら上位互換が保たれていないらしい。
原因は DB_File.pm のバージョンにあることにほぼ特定できたので、1.66 から 1.71 までのバージョンを１つずつ試してみて両者が動作するものにすれば解決するのでは？と考えたけど、根本から原因が特定できていないので、リスクがあった。やはり、どこの部分が原因で動かないのか？ を調べないと気持ちが悪い。
そこで今日は、DB_File の 1.65 と 1.72 を徹底的に見比べてみたところ、修正は１箇所だけで済むことが分かった。エラーが発生した付近を見比べてみると、バージョン 1.72 は、250行目に次の１行がつけ加えられていた。この行は1.65 にはなかった
$arg[3] = 0666 unless defined $arg[3];
この行をコメントアウトしたところ、ＣＧＩエラーは出なくなった。
とりあえず、めでたしめでたし、なのだけど、根本的な解決ではない。
今後、別のサーバーに移したときにまた引っかかる可能性があるからである。
結局、Movable Type の Search.pm を分析してみないと詳しい原因は分からない。
他の人にはこういうエラーが出ていないとすれば、インストールか設定に何か間違いがある可能性もあるので、まずはそこから確認してみる必要がある。
とりあえず、今回はこれで解決ということにしておこうと思う。
Cobaltサーバーは、仮想サイトのホスト名やドメイン名を変更すると何らかの不具合が発生するリスクがあるので、できれば避けた方がよい。Raq3 の時にはメール設定がおかしくなった時もあった（パッチ対応済み）。
raq550の場合は、ホスト名を変更したら、ウェブサーバの別名（ServerAlias）の設定が無効になってしまった。
ホスト名 ： www ドメイン名を ： usemanage.net ウェブサーバの別名： usemanage.net
というふうに設定しておくと、
http://www.usemanage.net/
http://usemanage.net/
のどちらのＵＲＬでも使えるはずなのだが、ホスト名を変更すると、ウェブサーバの別名で指定した後者のＵＲＬが使えなくなってしまい、同じＩＰアドレスを使っている別の仮想サイトのＵＲＬにすりかわって表示されてしまう。
/etc/httpd/conf/vhosts/ 内の設定ファイルを見ると、ServerAlias の１行が消えていることが分かる。
この場合の対処法は、ウェブサーバの別名の欄を一旦クリアしてから［保存］し、再び入力して［保存］するという手順でＯＫである。
Cobaltサーバーの場合、設定内容を一旦データベースに保存して、そこから各種設定ファイルに書き出しているので、何らかの変更を加えてわざわざ上書きされるようにすればたいていは解決できるようになる。
今日は、このブログを新しいサーバーに移した。
が、苦労しつつも、まだうまくいっていない。
途中経過を記しておこうと思う。
まず、Movable type 3.0 のファイルを新サーバーに移した。
ファイルがたくさんあるので、zip圧縮でアップロードして展開したが、これだとどういうわけかブラウザでエラーが出てしまう。
CGIでエラーが出るならともかく、普通のhtmlファイルもエラーが出る。
シェル上から unzip した後に、所有者名とグループはきちんと書き換えたのに、なぜだろうと思ったが、考えてみても始まらないので、圧縮しないで１ファイルずつＦＴＰでアップロードし直した。
それでも結果は変わらない。仕方ないので原因を分析することにした。
新サーバーは改造版Raq550で、今までのサーバーは Raq3 である。
どこが違うかを調べたら、httpdの初期設定が若干異なっているらしい。
Raq3 までは、ユーザーサイトでの .htaccess がすべて許可されていたのに、Raq550 では制限されているらしい。
私のブログは .htaccess ファイルを追加していたので、ここで引っかかっていたことが分かった。さっそく access.conf の設定を変更した。
さっそく、mt-check.cgi を実行してみると、MySQL が使える状態になっていないことに気づいた。
Raq550 は標準で MySQL がインストールされているけれども、標準では使えるようになっておらず、最初にいくつかの設定が必要とのことである。
（１）サーバー起動時に自動起動するように、次のコマンドをシェル上から実行
/sbin/chkconfig mysql on
（２）ＰＨＰから使用できるように、php.iniファイルを変更
/etc/httpd/php.ini のファイルに
extension=mysql.so
の1行を追加
（３）次のようにシンボリックリンクを作成する。
ln -s /var/lib/mysql/mysql.sock /tmp/mysql.sock
（４）サーバーを再起動 （httpd と MySQL も自動的に再起動）
これで MySQL が使えるようになったので、DBの設定をした。
でもまだ、MySQL が使える状態にならない。
DBD::mysql というのが入っていないのが原因のようである。
Perl から MySQL を使うのにはこれが必要とのことで、今までのサーバーには確かに入っていた。
さっそくインストールするのだが、できるだけ簡単にやりたいので、CPAN という、Perlモジュールのインストールツールを使うことにした。
最初に DBI もインストール必要があるそうなので、次の２つのコマンドを１個ずつ実行した。プロンプトの質問がたくさんきて［ENTER］キーを押し続けた。
/usr/bin/perl -MCPAN -e'install DBI'
/usr/bin/perl -MCPAN -e'install DBD::mysql'
この２つのインストールが終わると、MySQLが使えるようになった。
さっそく、 mt-load.cgi を実行したら、次のようなエラーが出た。
Insertion test failed on SQL error Column 'author_type' cannot be null
考えてみればこの mt-load.cgi は、アップグレード版だったことに気づいた。
とりあえず無視して、ログインしようとしたけど、ユーザー名 Melody、パスワード Nelson でログインすることができなかった。
仕方ないので、今までのサーバーのMySQLデータベースをそのまま上書きすることを思いついた。
/var/lib/mysql/ の中にデータベースの中身が入っているので、その中のファイルをすべて新サーバーの同じ場所に上書き保存して、パーミッションや所有者名等を元と同じにした。
これは成功だったようで、見事に Movable Type にログインすることができた。
ひととおり動作確認してみたら、サーチ機能（mt-search.cgi）でエラーが出ることに気づいた。
シェル上で、mt-search.cgi を実行してみると、次のようなエラーが出る。
[root cgi-bin]# ./mt-search.cgi
Use of uninitialized value in substitution (s///) at lib/MT/App.pm line 507.
Use of uninitialized value in split at lib/MT/App.pm line 508.
Use of uninitialized value in concatenation (.) at lib/MT/App.pm line 512.
Use of uninitialized value in subroutine entry at /usr/lib/perl5/5.6.0/i386-linux/DB_File.pm line 259.
インターネット上で調べたら、どうやら DB_File.pm のバージョンを調べてみる必要があるとのことらしい。
さっそくサーバー内の DB_File.pm のバージョンを調べたら、1.75 となっていた。このファイルだけタイムスタンプが新しかったので、後から入れたアプリケーションがこれを上書きしたのだと思う。
今まで動いていた方のサーバーでは、それが 1.65 になっているので、これを上書きしてみたら、エラーが出なくなった。
これでめでたし、と思いきや、今度はサーバーの管理画面が機能しなくなってしまった。
このままではサーバーの管理ができなくなってしまうので、DB_File.pm のバージョン再び 1.75 に戻すことにした。
当然のことながら、サーチ機能（mt-search.cgi）でエラーがでるので、検索が使えなくなってしまった。
今日はここで終了。原因調査中。
インターネットが普及し始めた頃は、アメリカのサーバーの方が安くて回線も早かったので良く使ったし、リセールもした。
その後、国内のインフラが整ってからは海外サーバーに回線の遅さを感じるようになって、海外サーバーのメリットはあまり感じなくなった。
でもどういうわけかまた、海外サーバーを物色したい気分になっている。価格のディスカウントとサービス競争がここにきて再び加速してきているように感じるからである。
やはりｂｌｏｇ等の影響なのかもしれないけど、専用サーバーの価格競争が今年になってから加速してきているようで、回線よりもサーバースペックが重要視されるようになっているようだ。共用サーバーの方もマルチドメインがあたり前になりつつあって、ＶＰＳ（バーチャルプライベートサーバー）がメインになりつつある。
XOOPSやosCommerce等のアプリケーションが標準で付くようになると、レンタルサーバーもだんだんとＡＳＰされてくるのかもしれない。
それはともかく、海外サーバーの動向を知るために、いくつか試用してみた。
海外サーバーはやっぱりスピードは遅い。Web閲覧では全く問題なくても、FTPを使うと速度を実感する。共用サーバーの場合は制限がかかっているケースもあるけど、専用サーバーであまりにも遅いようだったらバックボーン環境の問題になる。
先月申し込んだ SuperB というサーバーは、ダウンロードは早いけどアップロードがものすごく遅く、FTPが途切れることが多かった。
今日は、cobaltracs.com というとことで、Cobalt Raq4 サーバーに Raq550 のソフトを入れたサーバーを $39.95／月 で申し込んだ。
探すと、もっと安い専用サーバーがどんどん見つかりそうだ。$29 が今のところ最安値だった。
XOOPS と OsCommerce の動作を自サーバーで実験してみるために、PHPをインストールした。
Windows＆IIS環境でPHPをインストールするのは初めてだ。
＜経過＞
手がかりとしてまず最初に、サーチエンジンで「PHP」のキーワードで検索した。
PHPに関するホームページがたくさんリストアップされるので、とりあえずは「日本PHPユーザ会」というホームページを開いてみた。
最新バージョンは PHP 5.0.0 らしいけれども、安定性を考えて、PHP 4.3.8 を使うことに決める。 4.3.7 以下は、セキュルティホールがあるらしい。
そして、ダウンロードのページに行った。
今回は Windowsサーバーなので、「PHP 4.3.8」の「Windows Binaries」のところから選ぶと見当をつけたが、「PHP 4.3.8 zip package [6,874Kb]」と「PHP 4.3.8 installer [1,048Kb] 」の２つのファイルがあるが、どちらにすればよいのか迷った。
大は小を兼ねると思って、「PHP 4.3.8 zip package [6,874Kb]」をクリッ
クして、ダウンロードサイトを選択し、ダウンロードを行なった。
ダウンロードしたファイル「php-4.3.8-Win32.zip」を c:\temp フォルダに展開させた。
インストール方法が全く分からないので、日本PHPユーザ会のページを再び開き、マニュアルの日本語訳を読むことにした。
第3章インストールの「Windowsシステムへのインストール」のページを読む。
これを読んで、次のことをやった。
（１）c:\temp フォルダ内に展開したフォルダを C:\php フォルダにリネームして移動。
（２）php.ini-recommended ファイルを php.ini にリネームして、 C:\winnt フォルダにコピー。
（３）php4ts.dll ファイルを C:\winnt\system32 フォルダにコピー。
（４）sapiフォルダ内の pws-php4isapi.reg ファイルをダブルクリック。
（５）IISのサービスマネージャーを開いて「既定のWebサイト」のプロパティを開き、「ホームディレクトリ」タブの「構成」ボタンをクリック。
（６）「マッピング」タブで「追加」ボタンをクリックし、実行ファイルに「C:\php\sapi\php4isapi.dll」を、拡張子に「.php」を入力。
（７）「ドキュメント」タブで既定のドキュメントに「index.php」を追加。
とりあえずこれで、PHPが動くようになった。
SpamCop のメールアカウントを申し込むと、ウェブメールシステムも使えるようになる。
メニュー等に表示される言語を選ぶことができ、日本語で表示することも可能である。
が、受信メールを見ると、日本語は化けてしまっていて、表示することができない。
メッセージを個別に表示して、「メールソース」を選んで別ウィンドウで表示すれば、日本語はエンコードされるけれども、基本画面の中にエンコード機能がないようなので、これは使えない。
もちろん普段は通常のメールソフト（Eudora）で受信することが多いけど、外出先等ではウェブメールを使うことになる。
今までは So-net のウェブメールを使っていたけれども、今度は別なウェブメールシステムを使うしかない。
ちなみに携帯電話からは、リモートメール を使っているので、アカウントを追加するだけで使える。
ウェブメールシステムは以前、自宅サーバーで、ＢＡＳＰ２１を使って自作したことがあるけれども、大量メール用に最適化していないので、使えない。
Personi Office というフリーのグループウェアを以前使ったことがあって、これのウェブメールシステムは良くできていたけれども、中国の方から来るある種のメールを受信すると途中で画面表示がおかしくなって、設定も壊れてしまうという難点があったので、これも使えない。
そこで今日はあらためて、いくつか探してみた。
Vectorで探してみたら、「ウェブメーラー(Windowsサーバー向け)0.954」というフリーウェアのがまっさきに見つかったので、それをインストールしてみた。
これで問題なく使えるけど、 SpamCop のメールアカウントのユーザー名は、＠マークを含んでいるので、１箇所だけ修正が必要だった。
「pop3.pl」ファイルの中の32行目をコメントアウトにしたら、うまく動作した。
これでやっと、SpamCop をメインのメールアカウントとして使うことができる。
今週からメインのメールボックスを So-net から SpamCop に変更してみた。
SpamCop http://www.spamcop.net/
まだ５日間しか検証していないけれども、１日約１２００通来ていたスパムメールの９割が自動的に振り分けられたので、結果は満足している。
でもまだ課題がある。
スパムではない正当なメールを誤って削除してしまうことだけは、絶対にあってはならないけど、残念ながらいくつかあった。
自分のサーバーから発信された管理メールがスパムに振り分けれられていたのと、次の２つのニューズレターがスパムに入ってしまった。
-------------------------------------------------------------------------
●アップルの「Apple eNews - Japan : 8/3/2004 」
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on blade1
X-Spam-Level: *****
X-Spam-Status: hits=5.4 tests=HTML_40_50,HTML_FONT_FACE_BAD,HTML_IMAGE_AREA_07,HTML_MESSAGE,HTML_SHOUTING7,HTML_TAG_BALANCE_A,J_CHICKENPOX_75 version=2.63
X-SpamCop-Checked: 192.168.1.101 211.125.88.237 216.35.62.50
X-SpamCop-Disposition: Blocked SpamAssassin=5
●Ｅトレードの「★コムストックローン・Ｅ＊トレード★キャンペーン実施中！【Ｅ＊トレード証券】」
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on blade4
X-Spam-Level: *****
X-Spam-Status: hits=5.7 tests=GAPPY_SUBJECT,J_BACKHAIR_36,NO_REAL_NAME,SUBJ_ILLEGAL_CHARS,WEIRD_QUOTING version=2.63
X-SpamCop-Checked: 192.168.1.101 216.194.66.184 210.136.165.104
X-SpamCop-Disposition: Blocked SpamAssassin=5
-------------------------------------------------------------------------
この２つのメールがはじかれた理由は、「Blocked SpamAssassin=5」なので、もう少し基準を緩くしてあげればよい。
SpamCop のウェブメールの画面から、
「オプション(I)」 -> 「SpamCop Tools(C)」 -> 「Select your email filtering blacklists.(C) 」
というメニューを選ぶと、 SpamAssassin の判定基準を設定する項目があるので、それを５より上にすればよい。１０くらいにしておけば、安心だと思う。
-----------------------------------------------------------------
ところが、この指定が有効になっているのかどうか疑問だ。
SpamAssassinを１０にしたのに、５で弾いてしまっているらしいので。
-----------------------------------------------------------------
これでも自動的に削除しきれないスパムメールがある場合は、スパムメールの差出人（From:）、宛先（To:）、題名（Subject:）の傾向を調べて、個別にルール登録しておいた方がよい。
差出人はいくら登録してもキリがないので、宛先（To:）を登録する方が効率がよいと思う。
最近は差出人をでたらめにつけて無差別送信するウィルスが増えているので、それのエラーメールが増える傾向にあるけど、この相手は正常なサーバーであることが多いので、ブラックリストに登録するわけにはいかない。
これはスパムメールではないので、ルールを設定して自動削除する。
私の場合は、 メインで使うメールアドレスのドメイン（@usemanage.com）宛に帰ってくるエラーメールは無条件に削除するようにしている。
ＳＭＴＰサーバーは、自分がメインで使用するドメインのサーバーを使うのではなく、必ず別のサーバー（例えばアクセスプロバイダーのＳＭＴＰサーバー）を使用することをおすすめしたい。
この方が差出人を偽るウィルスメールの対策がしやすくなる。
ところで、フィルタリングのルールを登録する方法は、SpamCop のウェブメールの画面から、
「フィルタ(B) 」 -> ［フィルタルールを編集］
という項目を選んで、［New Rule］ボタンを押して、追加する。
指定できる条件項目は、次の１７個である。
To
Subject
Sender
From
Cc
Bcc
Resent-from
Resent-to
List-Id
Received
X-Spam-Level
X-Spam-Score
X-Spam-Status
X-Priority
Size
Body
Self-Defined Header
ルールを追加しながら、しばらく、様子を見てみよう。
私が１日に受け取るスパムメールは約１２００通。
ほとんどが海外からのもので、最近は中国語とロシア語のものが増えている。
いずれも、SpamCop のブラックリストに載っているものが大半だ。
どこからメールアドレスが流通したかを調べてみると、ドメインのＷＨＯＩＳ情報に公開されていたものが大半を占めている。
レンタルサーバーのお客様のドメインを登録する際に、自社のドメイン（ ?????@usemanage.com ）に固有の名前を割り当てたものを使用するようにしていたので、このメールアドレス宛に来たスパムメールは、ＷＨＯＩＳ情報から漏れたものだと特定することができる。
でも実際には、ＷＨＯＩＳ情報に登録されているメールアドレス宛に無差別に送られてきているのではなく、特定のドメインのものに集中しているところから見ると、サイトの内容からＷＨＯＩＳ情報を辿ってスパムリストに流れるのかもしれない。
インターネットの黎明期にいくつかのアダルトサイトのドメインを登録したことがあるけれども、もうそのドメインは廃止済みなのにもかかわらず、そこで登録していたメールアドレス宛に未だにスパムメールが送られてくる。
いくらエラーメールを返しても、そのメールアドレスのドメインが生きていれば、全く効果がない。
やってくるスパムメールの数はどんどん増加していって、減る気配は全くない。
このままいって、１日１万通を超えるようになったら、スパムメール退治が一種のゲームになるかもしれない。
スパムメールはそのうち、電話の発信番号通知と同じように、メールサーバー（ＳＭＴＰサーバー）のＩＰアドレス等を認証することで、ある程度は防げるようにはなるだろう。
次に問題になりそうなのは、ｂｌｏｇのスパムコメント対策である。
Movable Type 3.0 でスパムコメントを一括削除しようとして操作するとブラウザの左下に「ページでエラーが発生しました」と表示されて、動かなかった。
「ページでエラーが発生しました」の左の黄色いアイコンをクリックしたらエラー内容がポップアップで表示されて、エラー箇所の行番号を知ることが出来る。
ページのソースを見てみたら、対応するスクリプトがないことが分かった。
それはともかく、ページのソースを表示させて、ヘッダー部を見てみたら、
という記述があった。 mt.js ファイルが存在しないのでエラーになったらしい。
さっそくこのファイルを /mt フォルダにアップロードしてみたら、解決した。
今日はようやく、スパムコメントを一括削除することができた。
今日からメインのメールボックスを SpamCop のメールアカウントに変更してみた。
SpamCopは非常に有効なブラックリストを提供していて、今まで使っていたソフト「MailGate」でも、これのおかげでかなりの数のスパムを退治してくれた。
今回、このSpamCopのメールアカウントを取得してみた。コストは年間＄３０である。メールの転送先をこのアドレスにしておけば、メールボックスに届いた瞬間にフィルタをかけてくれる。
このメールアカウントは、ウェブメールが使える。メニュー等は日本語でも表示されるようになっているので、なかなか気が利いているが、肝心のメッセージが文字化けして使い物にならない。
とりあえず今日１日で、１１３３通のメールを退治した。
でも退治しきれなかったメールも１２０通くらいあった。
とりあえず１次的なフィルタリングはこれで十分だと思う。
これに２次フィルタリングをかければ、より完璧に近づくと思う。
とりあえずこれでしばらく様子を見てみよう。
Movable Type のバージョンを 3.0 にアップグレードしてみた。
upgrade版をダウンロードして、
ファイルを上書きして、
mt-upgrade30.cgi を実行するだけで、
特に問題なく完了した。
新しいバージョンでは、コメント管理機能が充実したというので、
ここに山のように書き込まれているスパムコメントを一気に
削除しようというのがアップグレードの目的である。
さっそく、管理画面にログインして、
スパムコメントを一括削除しようとしたら、
「ページでエラーが発生しました」と出て、うまくいかない。
というわけで、今日の時点ではまだ
スパムコメントをぶらさげたままだ。
スパムメールがどんどん増えていく。
１時間で１００通以上は来る。
消しても消してもゾンビのように新着のジャンクメールが現れる。
今は、MailGateというソフトを使って、３０分ごとにフィルタをかけているが、ぜんぜん追いつかない。
スピードが遅いのと、メモリを大量に消費するのが災いして、途中でハングしてしまうことが多くなってきたのである。
こういうソフトはやはり米国の方が進んでいる。
今日はいくつか探したが、まだ理想のものは現れていない。
本当はメールサーバー側でフィルタリングするのが理想だけど、セットアップするのが面倒だ。
サーバー側ではあくまでも一次フィルタリングをかけて、最終的なフィルタはクライアント側で行なった方がリカバーもしやすいので、安全だと思う。
私は１９９７年頃からジャンクメールの嵐に耐えてきているけど、以前のサーバーでは procmail を使って、一次フィルタリングをかけた。でも今は数が非常に増えていて、しかもルールが特定できないパターンが増えているので、この方法も限界がある。やはり、専門のサービスやソフトウェアを使わざるを得ない。
今日、いくつか探してみた。
SpamBouncer → procmailと連携して使う
www.spamelimination.com → 専用アカウントを使う
今のところまだ納得できない。
とりあえず一次フィルタリングとして、
spamcop.net を試してみるつもりである。
ここのブラックリストは、なかなか使える。
これをメインのメールアドレスとして使うことも検討してみよう。
毎日々々、スパムコメントが書き込まれる。
ＩＰアドレスはその都度違っているけど、タイトルが penis という文字で始まっていて、開くとそのような画像が出てくる。
削除が面倒なので、コメント書き込みを禁止に設定した。
ところで昨日、ロリポップの会社が運営する JUGEM という無料ブログサービスが始まったので、さっそく申し込んでみた。
まだ何も書き込んでいないけど、これから読書メモでも気楽に書き込んでいこうと思う。
いくつかの無料ブログサービスを申し込んで比較してみるつもりだけど、
ブログは、自サーバーで運営するよりも既成のＡＳＰサービスを使った方が良さそうだ。
一昨日、172.23.0.* というＩＰアドレスから送られてくるメールをすべてスパムと判断するように設定した。
スパムメールをほぼ完全に除去できたと得意顔になっていたら、何だかいつもと調子がおかしいことに気づいた。メールがこんなに来ないわけはないのだが．．．
そうしたら、大変なことに気が付いた。正常なメールも含めて全てをスパムと判断して自動削除していたのである。削除したメールのログを見たら、お客様からいただいているメールもあり、冷や汗モノだった。
昨日１日で数件、大切なメールを誤って削除してしまったことになる。
幸い、ログが残っていたので、お客様にはメールの再送をお願いすることができた。
あらためて原因を分析してみたら、正常メールのヘッダーにも 172.23.0.* というＩＰアドレスが含まれていたことに気づいた。
172.23.0.* というＩＰアドレスはすなわち、私がメインで使用している so-net のＩＰアドレスだったのである。とんでもない失敗だった。
スパムの設定を解除したので、今日からまたスパムメールの嵐に立ち向かわなければならなくなった。有料のブラックリストサーバーの利用も検討してみよう。
今月はスパムメールの受信量が倍増した。
宛先アドレスが私のメールアドレスと同じドメインになっていて、＠マークの前にでたらめの名前がくっついているものがほとんどだ。
差出人も件名もすべてでたらめになっているものが大量に送られてくるので、スパムメールの除去ルールを決めるのは難しい。
そこで今日、もういちどスパムメールのヘッダーの中身を分析してみることにした。
メールヘッダーの欄を見ると、172.23.0.* というＩＰアドレスから送られてきているものがほとんどだった。
さっそくスパムメールのメール除去ルールに設定してみたら、このパターンのものはほとんど退治することができた。
今後はスパムメールをＩＰアドレスで判定する方法が一般的になってくるだろうと思う。電話番号の発信者番号通知で認証するのと同じように、メールについても差出人のＩＰアドレスで認証する方が確実だからである。
でもそうすると、ＩＰアドレス自体を偽造する手法が広まるかもしれない。
また、バーチャルＩＰを使っている場合はたまたま同じＩＰを使うユーザーがブラックリストに登録されると、他のユーザーが迷惑するケースも考えられる。
いずれにしてもしばらくの間は、複合的に判断せざるをえないだろうと思う。
大切なメールを誤って削除することのないように、しっかり管理しておきたい。
このホームページで、カテゴリのアーカイブファイルがうまく作られていないことに気がついた。カテゴリが７つあったはずなのに４つしか作られない。
ここで使っている MovableType というソフトはもともと英語版なので、カテゴリ名が日本語だとファイル名が化けてしまってうまくいかないらしい。
どこで調べたか忘れたけど、問題はファイル名の部分だけなので、
［BLOGの設定］－［アーカイブの設定］の画面の中の、「アーカイブ・ファイルのテンプレート 」のCategoryの部分に
cat_<$MTCategoryID$>.html
というふうに入れてあげたら、見事に解決した。
デフォルトだとここにカテゴリ名が含まれた名前になるので、カテゴリではなくカテゴリ番号を入れれば、とりあえずは区別される。
CGIかテンプレートの内容を書き換えるしかないかと考えていたところに、こんな単純な解決法が見つかったので、救われた。
何かを解決しようとしてインターネット検索する時は、遠慮なくストレートに近道を探してみることが重要だと、あらためて感じた。
友人のウェブデザイナーが、Windowsサーバーのことで苦労していたようなので、ちょっとだけお手伝いすることになった。話を聞いてみたら簡単そうだと思ったのですぐに解決するかと思ったのだが、久しぶりに苦労する結果となった。
ＵＮＩＸサーバーで動いていたはずのフォームメールのＣＧＩがＷｉｎｄｏｗｓサーバーで動かなくて困っているとのことだった。
当然のことながら、perl + sendmail を使ったＣＧＩになっていたが、Windowsサーバーには perl は入っていたけど sendmail が入っていないのでスクリプトを修正しないと動かないという話である。
sendmail の代わりに入っていたのは BlatJ というソフトだということだが、スクリプトの記述方法も異なるので、どこをどう変えれば動くようになるのか検討つかない。さぁ、どうするか？
Windowsサーバーでメール送信しようと思ったら、ASP + BASP21 を使うのが一番簡単で応用範囲も広い。ActivePerl を使えば Perl から BASP21 も使える。
でも今回は BlatJ で動かすのが必須条件ということで、一から調べることになった。
まずは BlatJ をVectorからダウンロードして、サーバーにインストールした。バージョンは1.7だった。
sendmail との記述の違いを調べてみると、BlatJの場合は To や Subject 等のパラメータをつけて起動してあげなければならないということなので、そういう記述に変えれば動くものだと思っていた。sendmail のものを BASP21 に変える時は、いつもそれでうまくいっている。
メールを送るところまではうまくいったのだが、添付ファイルをつけて送らなければならないということだったので、そこで手詰まりになった。
たしか添付ファイルには、
Content-Disposition: attachment; filename=ファイル名
という記述が入っていたはずなので、それをつけて送ってみたけど、本文に入ってしまって添付にならない。
実際に送信＆受信が成功たメールと失敗したメールを比べてみると、ヘッダーの部分に決定的な相違点があることに気づいた。添付ファイルにするためには、ヘッダー情報に、
Content-Type: Multipart/Mixed; boundary=[区切り文字列]
という記述がなければならないのだった。とすると、BlatJ では無理なのではないか？という疑問が頭をよぎったのだが、サーチエンジンで検索してみると、BlatJ で添付ファイル付きメールを送るには、 -attach オプションを付けることで可能になるということが分かった。
ところが先にインストールした BlatJ のヘルプを見ると、-attach オプションがなかったので、そこで初めて「もしかしたらバージョンが古いのではないか？」ということに気づいた。
-attach オプションに対応しているバージョンは 1.8以上だということだったので、それに入れ替えて試してみたら、ヘッダーに Content-Type: Multipart/Mixed が付くようになった。でも結果は同じで添付ファイル化にはならなかった。
よくよくヘッダーを見てみると、 Content-Type: Multipart/Mixed の他にもうひとつ、 Content-type: text/plain というのがあったので、それが原因ではないかと思った。
さらに調べてみると、それは BlatJ のバグであることが分かり、そしてとうとう最新版（1.8.2+J2.5）を見つけてダウンロードしたら、うまくいった。
今回は、最新バージョンの確認を怠ったという初歩的なミスで、遠回りしてしまった。Vector にそんな古いバージョンのものがアップされていたとは知らず、やはり常に最新バージョンと変更履歴を調べることを怠ってはいけなかったのだ。
＜今回の教訓＞
・面倒でも必ず、最新版と変更履歴をダウンロードすること。
・ウェブデザイナーやウェブプログラマー向けに、動作確認用としてのレンタルサーバーサービス（アドバイス付き）を追加すること。
・何度もトライ＆エラーを繰り返す前に、Mandal-Art等を使って実現のための条件を書き出してみてから始めること。
MovableTypeを使っているユーザーから、今使っているサーバーは遅いので、なんとかならないか？ という声を聞いた。
たしかにサーバーそのものの処理速度の問題もあるけれど、データ量が増えてくるとBerkeleyDBだとだんだん遅くなってくるそうなので、この際なので MySQL に移行することにした。
既にBerkeleyDBで使い続けてしまった人の場合は、どうやってデータを移行すればいいのだろうか？ サーチエンジンで探すと、経験者の体験談がたくさん出てきたので、これは何とかなるだろうと思った。
データ移行には、「mt-db2sql.cgi」というプログラムを使うらしい。
でもどうやって手に入れれば良いのだろうか？
「mt-db2sql.cgi 入手」という２つのキーワードで探すと、答えが出てきた。
http://www.movabletype.org/ の本家から、UPGRADE版をダウンロードすると、そこに含まれているとのことだった。
BerkeleyDB 版を使っていたサーバーの /db フォルダ（つまり移行前データ）を、新しいサーバーにアップロードしなければいけないが、どこに配置すればよいのか分からないので、とりあえず /cgi-bin フォルダの中に「mt-db2sql.cgi」とともにアップロードしてみた。
そして早速、これをブラウザから実行してみると、エラーが出た。
Table 'mt_author' already exists at [絶対パス名]/mt-db2sql.cgi line 55.
エラーメッセージの通り、テーブルが既に存在していたのが原因だと思ったので、データベースを初期化した。さて、その方法は、
Telnet で MySQL データベースにログインし、テーブル一覧を取得する。（show tables; コマンド）
そのテーブル一覧を秀丸エディタに貼り付けて、次の１５行のコマンドを作って、Telnetで貼り付ければ、一括でテーブル削除する。
drop table mt_author;
drop table mt_blog;
drop table mt_category;
drop table mt_comment;
drop table mt_entry;
drop table mt_ipbanlist;
drop table mt_log;
drop table mt_notification;
drop table mt_permission;
drop table mt_placement;
drop table mt_plugindata;
drop table mt_tbping;
drop table mt_template;
drop table mt_templatemap;
drop table mt_trackback;
そして、さきほどのコマンドをもう一度ブラウザから実行したら、今度は成功した。
テーブル一覧を取得してみたら、元のファイルと同じだったので、無事に変換できたらしい。
私がレンタルサーバー業を始めた時は、海外サーバーのリセールをしていた。１９９６年の話である。当時はレンタルサーバーが非常に高価で、数もそれほど多くなかった。
リセールを始めたきっかけは、私が初めて独自ドメイン（usemanage.com）を取得するのに米国のサーバーを申し込んだ時に、そのサーバー業者から「これからホスティング事業を始めるので、ぜひ日本のお客様を紹介してほしい」と頼まれたことに始まる。
その業者の名前は Infoboard Inc. 。残念ながら既に解散してしまったが、非常に思い出深い。社長の Richard Frenkel氏と、創業メンバーの John Miker氏は、私の片言英語に対してとても親切に受け答えしてくれるだけでなく、細かなテクニックや最新のインターネット技術動向等をとても親切に教えてくれた。
当時、私は WindowsNT サーバーの知識はあったけど、UNIX サーバーの知識やノウハウがほとんどなくて、お客様からの質問がチンプンカンプンだった。procmailとかaliasとかいう知らないキーワードが出てくると、夜のうちに John Miker氏に直訳英語で質問メールを出しておくと、朝（米国では夕方）までにはきちんど回答をくれるのである。最初の２年間は、ほとんど毎日のようにメールのやりとりをしていた。
私は、Infoboard社の名前を、申し込む前に知っていた。
『はじめてのＣＧＩ』（大塚恵太）
『バーチャルカンパニー―インターネットでビジネスを立ち上げる!』（佐藤尚規）
の２冊の本の中で紹介されていたが、Infoboard社も当時は The Sphere という会社のサーバーをリセールしていて、私が申し込んだ usemanage.com も The Sphere 社のサーバーだった。
この後、Infoboard社は自社サーバーを使ってのホスティングを開始した。
月額料金は、 Economy Plan $25、 Standard Plan $40、 Senior Plan $150 であり、リセラーの条件は、２アカウント目からは２割引になるということだけだった。
Infoboard社はその後、規模を拡大してスタッフも増えたが、１９９９年の秋に BiznessOnline.com社と合併した。もちろん Infoboardブランドはそのまま継続していたのだが、だんだんとサポート対応が悪くなってきた。John Miker氏に直接連絡すればきちんと対応してくれたけど、サーバーが落ちても週明けまで対応してくれないことが何度かあった。
そして２００１年７月、Infoboard社のいくつかのサーバーが完全に停止した。今まではｗｗｗがダウンしていてもメールは大丈夫だったけど、その時はＤＮＳから何から全滅で、Infoboard社と連絡がとれなくなっていた。
結局、数日後に完全復旧したけど、それから間もなく BiznessOnline.com社のサーバーに切り替えるという連絡が来た。Infoboard社の方はおそらく、一括解約と金銭的ペナルティ等によって継続不可能になったと予想される。
私の方はといえば、Infoboard社がそろそろ危ないと感づいていたので、２００１年６月に国内に専用サーバーを２台ほど確保していたので、７月のトラブルがきっかけで国内サーバーへの移行が加速し、それほど大きな混乱はなかった。
Infoboard解散後も 元社長の Richard Frenkel氏はサーバーの移行について親身になってサポートしてくれたので、とてもうれしかった。彼からの最後のメールには、こう書かれていた。
I no longer work for Biz (the Infoboard office was closed for various reasons mostly related to finances).
ちなみにBiznessOnline.com社はいつの間にか Vera net Solutions に変わっていた。
今までの担当者と連絡がとれなくなった時は、黄色信号である。
ここに入っていた最後のユーザーを脱出させるのにちょっと手こずった。
ドメインの Technical Contact のメールアドレスが BiznessOnline.com 社のものになっていたからである。ドメインのパスワードを誰も知らず、ネームサーバー変更に応じてもらえる見込みがなかったので、１１月、レジストラ変更で対応して、脱出完了である。
ホームページ転送サービスを提供していて、お客様から次のような質問を受けていたが、実現できる方法を模索せずに単なる思い込みで「できません」と回答していたことに気づき、反省している。
「サブディレクトリをぶら下げて転送することはできますか？」
「http://独自ドメイン/abc/def/ghi.txt のオープンで、
http://転送先プロバイダのドメイン/abc/def/ghi.txt が表示されるか？」
サブディレクトリをぶら下げて転送させる方法は知っている。
IISでは「サイト設定」で簡単に設定できるし、Apacheでは httpd.confで VirtualHost毎に Redirect設定を加えるだけなので、別に難しい話ではない。
ではなぜ「できません」と回答したのかというと、今メインで使っている Cobalt サーバーはブラウザベースで管理するので、httpd.confファイルを直接変更しないと実現できないような機能は提供しないと決めていたからである。ほとんどのお客様が「フレーム転送」の方を希望するので、リダイレクト方式はあまり重視していなかったのも確かである。
「リダクレクト設定はhttpd.confファイルを変更しないと実現できない」
↓
「httpd.confファイルを変更しなくても実現できる方法はないだろうか？」
このように冷静に考えたら、「 .htaccess 」ファイルを使えばいいということに気づくことができた。 .htaccess ファイルは今までアクセス制御やMIMEタイプ変更でよく使用していたが、お恥ずかしながら、これで Ridirectの設定ができることを知らなかった。
あらためて .htaccess について調べて、自分のサイト上で実験したら、すべて実現できることが分かった。
昨日は、今年１年間で「できません」と回答してしまったお客様に対して、「できるようになりました」と連絡した。そうしたら、もともとできてあたりまえの機能だったので本来はお詫びすべきだったのに「ありがとう」の連絡を受け取ってしまった。
今年は「できない」を「できる」に変えるための仕組みを考えて、１つでも多く実現させていきたい。ＩＴ等の新しい技術は、そのために使わないと損だ。
まずは「自分の思い込み」をリストアップしてみよう。
今までは個人的メモだけでクローズしていたけど、これからはそれを自分のサイト（私の場合は Shunichi.Hosono.com サイト）にもできるだけ蓄積していこう。
そうして、サーチエンジンで検索しまくってみよう。
「できる」ための手段やヒントを知っている人に巡り会えるまで徹底的に、蓄積と検索を繰り返せば、「できない」が「できる」に変わるかもしれない。
５ヶ月くらい前の話になるが、サーバー管理で苦労した件について記録を残しておこうと思う。もっと高いスキルを持つ人ならば簡単に解決できる問題だろうが、私の場合はまだまだ１つずつ苦労しながら覚えていく段階である。
で、その苦労した話というのが、Cobalt RAQ2J サーバーで突然、ユーザーの追加・修正が一切できなくなってしまったことである。
「3017 バニラ unix からシャドウ パスワードに変換できません。」
こういう意味不明なメッセージが表示されて、前に進まない。ユーザーフォルダはきちんと作成されているが、etc/passwd ファイルは暗号化されたパスワードがそのまま格納されていたので、処理の一番最後の、シャドウパスワード変換の段階で失敗しているのだろうと見当をつけた。
Cobaltサーバーで何か分からないことがあると、まずは、
http://cobaltqube.org/index-j.html 等のページをあたってみるのだが、今回は見つからなかった。
さっそく、Yahoo Japan! で、「バニラ unix シャドウ パスワード」等のキーワードを入れて検索してみたのだが、何を入れてもヒットしない。
他の情報源をあたっても解決しない場合、自分の力で解決するしかない。
Cobalt サーバーの管理画面はどうせ、Perl等のスクリプトで動いているだろうと思うので、ソースプログラムから解析していくしかない。
探してみたら、 commit_passwd.al というファイルにそのPerlスクリプトが記述してあって、「バニラunix ～～」のメッセージを表示している部分が見つかった。
/usr/sbin/pwconv コマンドが失敗した時に、このメッセージが表示されるらしい。
ちなみに、英語版の RAQ サーバーで同じスクリプトを調べてみたら、
「3017 user_cant_pwconv」
というメッセージになっていた。どうしてこのメッセージが「バニラUNIX ～～」の意味になるのか、翻訳の意図がよく分からない。
/usr/sbin/pwconv コマンドを手動で実行してみると、「Can't lock passwd file」というエラーメッセージが出た。これを何度か試行錯誤しながら実行していたら、Cobaltサーバーのメモリ不足の警告が出始めてきた。
「ps aux 」コマンドで状況を見て、原因がよく分かった。pwconv （プロセスID 9360）がループしていてメモリをどんどん食っていたのである。
原因が分かったので、「kill -9 9360」のコマンドを発行して、再度 Cobaltサーバーの管理画面からユーザー追加・修正をしてみたら、こんどはうまくいった。
最初から ps コマンドでサーバーの状況を確認していればこんな遠回りをしなくても済んだかもしれないけど、おかげでCobaltサーバートラブルについて、少しだけ自信がついた。仕組みを理解すれば、順序よく解決していけるものなのだ。
Cobalt Raq3 サーバーのメール転送設定が突然、おかしくなった。
新しいユーザーを追加したのに、メールが転送されずエラーで戻ってしまう。
今まで設定してあったものについては特に影響は出ていない。
レンタルサーバー業をやっていると、こういう時はピンチである。
幸いこのサーバーは予備用なので、一部のユーザーしか使っていないものだったので大きな影響は出なかったが、管理の易しいCobalt サーバーでも時々このようなおかしな事象が起こるので、気が抜けない。
結局この件は、サーバーの管理ソフトの不具合だったということで、あっけなく解決したが、解決できるまでの経過を書いておこうと思う。
・ＦＴＰで /etc フォルダ内のメール関連の設定ファイルをチェック
（alias, sendamail.cf, virtusertable 等）
・Yahoo Japan! で、「RAQ3 virtusertable」の２つのキーワードで検索し、
一発で「Cobalt RaQ3J メール配信設定不具合のご連絡」のページがヒット
http://jp.sun.com/service/support/news/01_raq3letter.html
今回の事象がこれであることを確認。このサイト（shunichi.hosono.com）を作るために、仮想サーバーのホスト名等を変更したのが原因だったらしい。
ところが、事象は確認したけど、問題のパッチをどこからダウンロードすればいいのかがまだ分からなかったので、それを探さなければならない。
・ＳＵＮのトップページからパッチのダウンロード画面を開いたが、該当するものは特に掲載されていなかった。さらによく探してみると、「サポート ＆ トレーニング」ページの中の「サン・コバルト・サポート・サービス」というページを開いてみると、下の方に「Cobalt RaQ3J メール配信設定不具合の修正パッチのご案内」というページが見つかったので、早速ダウンロードして、適用した。
http://jp.sun.com/service/support/news/03_raq3letter.html
Yahoo Japan! で、前回ヒットしたページタイトルの一部である「RaQ3J メール配信設定不具合」のキーワードで探せば、一発で探し出せたことになるので、次からはそのように検索するようにしょう。
今日から この「Movable Type」というブログツールを使ってホームページを再開しようと思う。この方が更新が楽で、扱いやすそうだからである。
自分で使ってみて良ければ、ユースマネージメントのサービスメニューにぜひ加えたい。
というわけで、ノウハウを得るためにも、とりあえずは２つのサーバーでインストールを実験してみた。レンタルサーバーで使用している Cobalt Raq3 サーバーと、自宅サーバーの WindowsXP サーバーである。
幸いなことにインターネット上の情報が充実していたので、さほど苦労なく進めることができたが、WindowsXP サーバーの方は相対的に情報が少なく、試行錯誤があった。
インストールする際にとても役に立ったのは、公式なドキュメントよりもむしろ、インターネット上の検索で見つけた個人的な体験談の話だった。予想外のエラーメッセージが出た場合などは、そのメッセージをサーチエンジンで検索すると、同じことで悩んだ人の体験談が出てきたりして、そこで解決策を得られることも多い。
今回、「Movable Type」というブログツールのインストールについて、インターネット上の情報にお世話になったわけだが、そこで見つけたホームページがどれも皆「Movable Type」で作られていたので驚いた。
私はこれから、自分が体験したもの、苦労したもの、試行錯誤したものをどんどん載せていきたい。誰かの役に立つか立たないかは分からないけど、そうすることが自然であり、喜びにつながっていくように思えるからである。
「自分がしてほしいことを他人にせよ」
「自分がしてほしくないことを他人にするな」
商売の基本は、昔から語り継がれてきたこれらの鉄則と同じである。
ブログツールの登場によって、さらに多くの人が自分または他人の体験を共有し、よりよい生き方ができるようになれば幸いである。