体験したことありませんか？ メール運用のヒヤリハット（前編）（1/2 ページ）

今や欠かせないコミュニケーションツールとなった電子メール。それだけに安定運用が欠かせないのだが、意外な落とし穴があちこちに待ち受けている。

[佐藤潔、内田雅生、衣笠茂浩、加藤雅彦，ITmedia]

　今や、仕事でもプライベートでも欠かせないツールになったと言っても過言ではない電子メール。コミュニケーションの手段として、またビジネスツールとして一般的に使われるようになり、「すぐ確実に届くのが当たり前」の存在になってきた。昔は電子メールが届くのに数時間掛かることも珍しくなかったものだが……。

　そのような時代ゆえ、電子メールシステムの安定運用は欠かせない。ところがどっこい、これが案外手間の掛かるもので、日々どこかでトラブルが起こっているのが実情である。

　電子メール関係のトラブルの特徴は、意外と気付きにくいことだ。エンドユーザーからの通報を受けたり、問題が大きくなってから慌ててトラブル対応に走るといった具合に、一度や二度は「どきっ」とした経験を持つ人も結構いるのではないだろうか。

　そこで今回は、現役管理者から聞き書きする形で、電子メールシステムの運用の中で発生したさまざまな「ヒヤリハット」体験をまとめてみた。発見の経緯や原因に加え、対策を含めた形で紹介しよう。

メールでCD-ROMを送らないで！

　ある日突然「メールサーバ全体の負荷が上がった」との連絡が顧客から届いた。状況を見てみると、確かにメールの送受信があり得ないほどに遅い。メール受信が完了する前にタイムアウトしてしまう始末である。

　調査を開始したところ、sendmailプロセスが700MBのキューファイル（サーバ側の一時格納ファイル）をMBOXに配送しようとして何度も失敗していたことを発見！　これはすぐに対応が必要だと判断し、キューファイルの中身をのぞいてみたら……どうやら誰かがCD-ROMのイメージをそのまま添付して送ろうとした模様である。トホホ。

　顧客に事情を確認したところ、あるユーザーが友人のAさんに、画像ファイルを保存したCD-ROMを、丸ごとそのままメールで送ってくれと依頼したらしい。「それはさすがに無理です」と伝え、Aさんに即刻配送を止めてもらうように依頼した。とはいえ、配送されてしまったメールは管理者が手動で消すしかない。顧客に承認をもらった上で、そのキューを手動で削除した。

　が、その後、またもやAさんから懲りずにCD-ROMイメージが、それも連続して送られてきた。しょうがないので目視で監視し、そのつど削除を行って、何とか事なきを得た。

●原因

　sendmailでは、システムの32ビットの限界のため、2GB以上のデータをMBOXにためることができず、配送に失敗した場合は再送を繰り返す。このケースでは、計算上3通目のCD-ROM配送（2.1GB）でMBOXがいっぱいとなり、配送に失敗した。それ以降も何十回も再配送が繰り返され、ディスクに多大な負荷を与えていたことが、メールシステム全体の負荷を上げた原因だった。

●対策

　それまでこの会社では、メールサイズに制限が設けられていなかった。この事件を機に、10MB以上のメールを受け取らないようにメールサイズ制限を実施した。また、メールサイズ制限だけでは、MBOXが2GBを超えるまでメールをため込むユーザーもいるため、一定期間経過後に古いメールを削除することで、MBOXがあふれないようにした。

ユーザーへのお願い

あまり大きなサイズのメールは送らないで！　サーバにメールをため込みすぎるのも禁物！

大量のバウンスメールでメール配送に遅延発生

　やはりある日、顧客から「メールが遅延しているのではないか」との連絡を受けた。試しにメールを配送してみると、確かに外部配送だけが妙に遅いときがある。

　サーバにログインし、プロセスを調査したところ、通常ならば数秒から数十秒程度で終了するはずのqmailプロセスが、このときは数分から数十分単位で起動し続けていた。この結果、少量のメール配送であっても、qmailプロセスがなかなか終了しないため、qmailプロセス起動数の制限に引っ掛かってしまい、外部に配送できない状態になっていたのである。

　引き続き、なぜこんなに配送に時間が掛かるのかを調査してみた。その結果、メールの宛先が「接続できない」メールサーバだったため、先方がタイムアウトするまで処理を待ち続けていたことが発覚。このまま放置していてはまずいため、qmailプロセス起動数を一時的に3倍に変更し、メールを配送し終えるまで目視監視を行った。

　また偶然か否か、このケースでは配送元IPアドレスとエンベロープFrom（SMTPでの送信元情報）を特定できるパターンだった。そこで、このIPアドレスとエンベロープFrom情報に基づいてレーティング（流量制限）を実施し、システムに大量のメールが入り込まないように対策した。

●原因

　実は、スパマーからの大量の「User Unknownメール」を受け取ってしまい、それに対し大量のバウンスメールを発生させてしまったことが原因だった。また、一般ユーザーのメール配送とバウンスメールの配送を同一MTAで配送させていたことも、一般ユーザーのメール配送遅延につながった。

●対策

1. 一般ユーザーのメール配送とバウンスメールの配送を別MTAにすることで、大量のバウンスメールが発生しても通常の配送には影響が出ない構成とする。
2. ホワイトリスト機能を実装し、不用意なバウンスメールを発生させないようにする。ただ、そのまま実装するとアドレスハーベスティング（DHA）攻撃を受け、メールアドレスを取得される恐れがあるため、インターネットに面したフロントのMTAの下にホワイトリスト用MTAを設置した。ここで、バウンスが発生したメールは専用MTAに振り分け、通常のメール配送に影響が出ないようにする。