メール管理者の「ヒヤリハット」レポート

−不用意なセキュリティ対策がトラブルの種に−

この記事では、現役のメールサーバ管理者が体験したさまざまな「ヒヤリハット体験」を紹介していく。中には「トホホ」な事例も含まれているが、セキュアで安定したメールサーバの運用を実現していく際の手助けになれば幸いだ。

佐藤潔、内田雅生、飯村直弘、加藤雅彦
2008/3/3

　子供から高齢者まで、ありとあらゆる人が普通に使うコミュニケーションメディアとなった感のある電子メールだが、それを配送するメールサーバの運用についていえば、やはりプロの仕事であり、そう間単な作業ではない。そこには、利用者からはうかがい知れない、涙ぐましい努力が隠れていたりするのだ。

　この記事では、現役のメールサーバ管理者が体験したさまざまな「ヒヤリハット体験」を紹介していく。中には、原因が分かってみればあっけないトラブルやケアレスミスに起因する「とほほ」な事例もあるが、それだけに、現場の管理者の皆さんには身近な話と感じてもらえるのではないだろうか？　これらのトラブル事例を他山の石として生かしていただければ幸いである。

【関連記事】 http://www.itmedia.co.jp/enterprise/articles/0703/19/news010.html 体験したことありませんか？　メール運用のヒヤリハット（前編）（ITmediaエンタープライズ） http://www.itmedia.co.jp/enterprise/articles/0703/20/news003.html 体験したことありませんか？　メール運用のヒヤリハット（後編）（ITmediaエンタープライズ）

メーリングリストサーバの名前を変更したら……

　リプレース時などの利便性を考え、DNSのAレコードで定義するサーバの本名（例：SERVER01.example.com）とは別に、業務や機能を表す名前（例：DNS.example.com、SMTP.example.com）をCNAMEで定義し、ユーザーにはこのCNAMEを利用してもらう運用をしていたシステムがあった。

【関連記事】 http://www.atmarkit.co.jp/flinux/rensai/bind02/bind02.html 名前解決の仕組みとゾーンファイルの設定

　あるとき訳あって、メールハブ兼社内メーリングリストサーバの本名を「SERVER01.example.com」から「NEWSERVER01.example.com」に変更した。その際、CNAME定義の変更（ML.example.com＝NEWSERVER01.example.com）も確認。さらに、クライアントPCからメーリングリストあてにメールが配信できること、そしてメールハブとしての機能がきちんと動作していることを確認してから本番化した。

　その後、問題なくメーリングリストを運用できていた……はずだった。しかし半年ほど経ち、サーバ名を変更したことなど忘れてしまったある日、とあるメーリングリスト経由で「ユーザーが作成したPHPアプリケーションから自動配信したメールが届いていない」というクレームが来た。しかし、ほかのメーリングリストは正常に運用できているし、クライアントPCから当該メーリングリストあてにテストメールを送っても、正常に届く。

　まずアプリケーションの開発者にデバッグを指示したが、その結果は「メーリングリスト以外であればメールが届く。それに、そもそも当該アプリケーションの本番化後はきちんと届いていて、その時から何も変更していない」とのことだった。メール管理者としては、完全にアプリケーションのバグを疑っていたのだ。

　しかしMTAのログを見れば、その予測が外れていたことは一目瞭然。「アプリケーションが出すメールのEnvelope Toが『NEWSERVER01』であり、これはメーリングリストサーバ側のMTAで受け取るべきあて先ではないからrejectした」と、ちゃんと理由が書いてあったのだ。

【関連記事】 http://www.atmarkit.co.jp/flinux/rensai/qmail04/qmail04d.html 実用qmailサーバ運用・管理術　第4回　メーリングリストの構築と運用

　postfixやsendmailなどの一般的なMTAのデフォルト設定では、中継すべきメールについて、「Envelope To」のドメイン名をAレコードの左辺になるまで解決し、書き換える。このPHPアプリケーションはlocalhostのMTA経由でメールを送っていたため、別名であるところの「ML.example.com」あてだったものは、この動作によって本名、すなわちかつての「SERVER01」、現在は「NEWSERVER01」あてに書き換えられる。

図1　サーバの本名変更をMTAに反映していなかったことが敗因（クリックすると拡大します）

　しかし、この本名変更の前後で、MTAの設定を一切変更していなかった。このため、「MTAが受け取るべき自サーバの名前」が古い本名（SERVER01）のまま残っており、新しい本名（NEWSERVER01）あてのメールを受け付けてくれなかったのである（図1）。

　なお、社内PCのMUAは送信時に名前解決など行わず、メールハブ＝メーリングリストサーバへ直接送信するため、正常に届いていた。このため、一連のテストおよび通常運用では障害が発覚しなかった。

　さらに悪いことに、当該システムから送信されたメールのEnvelope Fromは、人が見ていないアドレスに設定されていた。rejectされた結果を示すエラーメールが送られていたにもかかわらず、誰の目にも触れることがなかったのである。

　ちなみに、その後詳細に調査したところ、「システム発かつMTA経由でメーリングリストあてメール」については、同様の理由からほかにも未着が発生していた。その一部には、社内上層部発着の経営上重要なメールがあったため大問題に……。

■教訓 　メールの運用においては、DNS上の設定とメールサーバ側の設定が合っているかどうかが大変重要なので、ちゃんと確認しよう。また、せめてトラブル時くらいはMTAのログをちゃんと読もう。たとえシステム（アプリケーション）発でも、エラーメールは人が見るようにしておくべき。

アーカイブからのメール抽出、一晩じゃ終わらない！

部長	内部統制がうんぬん……。J-SOX法がどうこう……。で、社内で流通するメールをすべて保存しておかねばならなくなった。社長命令だ。何とかしておいてくれたまえ。
俺	分かりました。全社のメールサーバのpostfixで、always_bccとか使って、コピーしたのを別サーバに投げりゃいいんでしょ？ 楽勝っすよ。

　……てな具合で、深く考えずにメールアーカイブシステムを内製で構築し、本番化して数カ月。メールのハンドリングを考えて、mbox形式ではなく、1メール1ファイルのMaildir形式とし、スプール先を月ごとに切り替える設計にした。

　だが、社内では1日当たり数千件を超えるメールが飛び交っていたのだ。

部長	実はxxxの疑いがある件で、本社が内偵を進めているのだ。このたび社長から直々に要請があったので、こないだ本番化したメールアーカイブのデータから、K氏が送受信したメールを明日の朝までに抽出しておいてくれたまえ。
俺	分かりました。1メール1ファイルですから、'grep -l "From: K氏" *' とかで出てきたファイルをお渡ししますんで……。

　……って、いざ作業してみると、あれ？ "argument too long"？ そういや1日当たり数千件×1カ月だったな……って"ls" すら返ってくるのに数分かかる……。じゃあxargs（注1）を使ってgrepすれば……、ダメだ。朝までに終わらねぇ！！！

注1： xargs：grepの出力を分割し、小出しにしてくれるコマンド

　解説すると、このシステムでは、「1メール1ファイル」にする発想まではよかったものの、1ディレクトリに数十万ファイルを収めた場合のファイルシステムの挙動を想定できなかったことと、昨今のメールには巨大な添付ファイルが付いている場合も多いにもかかわらず、ファイル全体を見にいくgrepを利用するところに無理があったのだ。

■後日談

　「メールは基本、テキストだから、gzipなどを使えば圧縮率が高くなる」という思い込みでバックアップ設計をしていたところ、実際に圧縮してみると、gzipでも圧縮率は50％程度にしかならなかった。メールの添付ファイル容量の制限がきつくて圧縮しなければやっていけないためか、「添付ファイルは圧縮して送るべし」との情報システム部のいい付けを忠実に守るユーザーが多いためか……。

■教訓 メールも積もれば山となる！ 事前に山になった状態を想定して設計すべし。アーカイブを構築する際には、普段どのくらいのメールがやりとりされているのか、流量などを測定し、ゆとりを持って設計しておく。

【関連記事】 http://www.atmarkit.co.jp/fsecurity/rensai/mailsec03/mailsec01.html 電子メールセキュリティの基礎知識 第3回 情報漏えい対策――保存と検閲で「もしも」に備えよ

アーカイブサーバの停止が全社のメール停止に拡大

部長	例のメールアーカイブだが、障害対策は万全かね？ 障害でデータを失うのはまずいし、アーカイブサーバの障害が原因で本来のメール流通に支障を来すようなことはないようにしてくれたまえ。
俺	分かりました。実は、そのためにアーカイブサーバを別に立てたんです。障害があってもアーカイブされるべきデータは、1つ手前のメールハブでスプールされます。SMTPは基本的に非同期ですから、大丈夫です。

　果たして実際にメールアーカイブサーバで障害が発生し、その復旧に手間取っていたところ、いつの間にか全社でメールが送受信できなくなってしまっていた。「本来のメール流通に支障を来す」事態になってしまったのだ！

　賢明な読者はもうお気付きであろう。メールハブでスプールがたまり過ぎて、/var/spoolを圧迫し、それ以上新規のメールを受け付けることができなくなってしまったのだ。これまではせいぜい部署ごとのサーバあてのメールをスプールできていればよかったのだが、アーカイブサーバにつながる以上、全社のメールトラフィックのコピーをスプールできるだけの容量が今後は必要なのである。

■教訓 設計は計画的に。用途変更やトラフィック増大があらかじめ分かっているならば、設計を再検討しよう。

1/3

Index メール管理者の「ヒヤリハット」レポート 　不用意なセキュリティ対策がトラブルの種に

Page 1 　メーリングリストサーバの名前を変更したら…… 　アーカイブからのメール抽出、一晩じゃ終わらない！ 　アーカイブサーバの停止が全社のメール停止に拡大 　 Page 2 　スパム対策を導入したらメールが遅延？ 　再起動したらSMTP認証でメール送信ができない！   Page 3 　送信ドメイン認証の運用は慎重に 　携帯に大量のメールを出したら…… 　放置していた古いCGIの穴を突かれて 　複雑化するにつれ難易度高まるメール管理

Linux Square全記事インデックス

---

Linux Squareフォーラム Linux導入事例関連記事

	オープンソースで情報システムを刷新した嘉悦大学 嘉悦大学は情報システムのインフラを、CentOSやOpenLDAP、Sambaといったオープンソースソフトウェアで刷新した
	日米大手銀行がLinuxを採用したそれぞれのワケ バンク・オブ・アメリカと三菱東京UFJという日米を代表する大手銀行は、なぜLinuxとその上で動作するオープンソースソフトウェアを導入したのか
	特集：謎のOracleトラブルに挑む（前編） わずかな手掛かりから障害を解決した事例をとおして、トラブルシューティングのあり方や技法、困難さが見えてくる
	特集：謎のOracleトラブルに挑む（後編） 編で障害再現に成功したが、原因が特定されたわけではない。彼らはどのようにして問題を切り分けていったのだろうか？
	3年間無停止でNTTグループを支えるLinux 国内で最初期にLinuxで業務システムを構築したNTTコムウェア。このシステムはNTTグループ全体にも導入され、3年間無停止で稼働し続けている
	Linux Squareフォーラム全記事インデックス

MONOist組み込み開発フォーラムの中から、Linux関連記事を紹介します

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）