ある日偶然、アウトバウンドへの再配送を試みる「defer queue」が妙に多いことに気が付いた。そこで中を見てみると、社内には存在していないアカウントへ送信されたメールに対するバウンスメール(メールサーバが返信するエラーメール)だった。
●対策
これを放置しているとMTA側のリソースの浪費が無視できないため、以下の対策を試みた。
ただし、現在は使用されていないアカウントでも、将来にわたって使用されないという保証はない。そのため、存在しないアカウントを十把一絡げにREJECT(拒否)する手段は使うことができない。1つめの対策も、DHA攻撃が2回目に来たときに拒否する、といった程度の対策となった。
とある初夏の日の午後、「社内宛のメールが数時間経っても届かない」とのクレームが殺到した。そこでメールサーバを調べてみると、すべての社内メールが通過するメールハブのスプールが一杯に! ここでの処理が追いつかないため、全社でメールがストップしていることが判明した。
●原因
調査の結果、スプール内のメールのほぼすべてが、社内で開発中のあるWebシステムから送信されたものであることが判明。この開発中のプログラムがメール送信部分で無限ループに入ったため、システムの性能限界までメールを送信し続けていたのだった。この結果、平日日中の4時間にわたり、社外からのメールはもちろん、全社で部門間のメールが流通しなかった。
●一時的な対処
という対処を取り、とりあえずメールの流通を再開させた。
●対策
メール運用担当者としては、「開発中はテスト用の環境を使え!」と言いたいところだが、すべてにおいて完全に閉じた環境を用意するのは非現実的である。メールの流量を制限できる「throttling(スロットリング)」を社内で実装できれば、こういった事故だけでなく、ワーム感染などによるメール大量送信にも有効であると考えられる。
システム運用作業を少しでも楽にしようと、フリーの監視ツール「nagios」を用いて各メールサーバのSMTPポートの死活を監視し、異常時は携帯メールに通報するように設定してみた。
これで完璧かと思いきや……この方法、末端のMTAのダウンには有効なのだが、幹線やアウトバウンドのMTAがダウンした時は無力である。まあ、当たり前といえば当たり前なのであるが……。
●対策
以上、2回にわたって、実際に発生したメールシステムをめぐるさまざまなトラブルやその種を紹介してみた。これらの事例が、現場で運用に携わっている皆さんのトラブル発見の参考になれば幸いである。
またエンドユーザーの皆さんも、管理者は毎日、このように汗(冷や汗?)を流しながらメールの安定運用に努めていることをぜひ理解していただければ、そしてたまにはちょっぴりリスペクトしていただければ幸いである。
Copyright © ITmedia, Inc. All Rights Reserved.