この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
SE時代のある夜、クライアントのメールサーバーを担当していた私は、この状況に直面しました。
「なぜ自分のサーバーからスパムが出ているんだ」と血の気が引いたのを、今でも覚えています。
この記事では、20年以上Linux/Unixサーバーを運用してきた経験から、Postfixのオープンリレー設定ミスがなぜ起きるのか、そして今も続けているmynetworksの確認習慣についてお話しします。メールサーバーを構築したことがある方、これから構築しようとしている方に読んでいただきたい内容です。
この記事のポイント
・Postfixのオープンリレーは「mynetworksの設定ミス」が主な原因
・設定後は必ずオープンリレーテストを実施することが鉄則
・IPブラックリスト入りは修復に時間がかかるため予防が最重要
・postqueue -p とメールログの確認を習慣化する
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
あの夜、Postfixキューに何が起きていたか
SE時代、私はクライアント企業の社内メールサーバーをLinux(当時はRedHat系ディストリビューション)上のPostfixで構築・運用していました。設定作業を終えた数日後の夜、サーバー監視のアラートが上がりました。CPUとネットワークの負荷が急上昇しています。ログインして状況を確認すると、Postfixのキューに大量のメールが積み上がっていました。
# postqueue -p で確認 $ postqueue -p -Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient------- 8F3B42A1C4C 824 Thu May 15 02:14:31 unknown@somewhere.example victim1@external-domain.com 9A1B33B2D5D 1024 Thu May 15 02:14:33 unknown@somewhere2.example victim2@another-domain.com ...(数千件続く)
そこですぐに分かりました。このサーバーはオープンリレーになっていたのです。外部の誰かがこのサーバーを踏み台にして、スパムを大量に送信していました。
オープンリレーとは何か、なぜ起きたのか
オープンリレー(open relay)とは、本来そのメールサーバーが担当すべきではないメールまで、外部から持ち込まれて中継(リレー)してしまう状態のことです。スパム業者にとって、オープンリレーは格好のターゲットです。他人のサーバーを使って大量のスパムを送り続けます。当然、被害を受けた受信側の管理者は、そのIPをブラックリストに登録します。
私の場合、原因はPostfixのmynetworks設定でした。
# /etc/postfix/main.cf の問題のある設定 # テスト中に「とりあえず通るように」と広げてしまった設定 mynetworks = 0.0.0.0/0
注意してほしいのは、Postfixは設定が広すぎても「警告」を出してくれない点です。設定した本人が意識して確認しない限り、この状態のまま動き続けます。
トラブル対処:その夜に緊急でやったこと
1. まず中継を止める
まずPostfixを止めて、キューを凍結しました。その後、mynetworksを正しい値に修正しました。# mynetworks を正しい値に修正(自社のネットワークだけを指定) # /etc/postfix/main.cf mynetworks = 127.0.0.0/8, 192.168.1.0/24 # 設定を反映してPostfixを再起動 # postfix reload
2. キューの不正メールを削除する
積み上がったスパムのキューは、削除する必要がありました。大量のキューをそのまま送らせると、今度は正規のメール送信にも影響が出ます。3. IPブラックリストの確認と解除申請
翌朝、クライアントから「外部へのメールが届かない」と連絡が入りました。MXToolboxなどでIPを確認すると、すでに複数のブラックリスト(RBL)に登録されていました。各ブラックリストへの解除申請には、数日から数週間かかることもあります。私にとっては、ここがいちばんこたえました。設定はもう直したのに、メールが届かない状態がしばらく続くわけです。
この経験から続けている3つの確認習慣
1. mynetworksを設定したらすぐオープンリレーテストを実施する
Postfixを設定したら、必ず「外部からメールを中継できてしまわないか」をテストしてください。オンラインのオープンリレーテストツールを使うのが手軽です。・MXToolbox(https://mxtoolbox.com/)の「Open Relay Test」を使う
・または外部ネットワークからtelnetでSMTP接続を試みる
「中継できなかった」という結果を自分の目で確認してから本番稼働に移る。これを鉄則にしています。
2. テスト段階で使った設定は必ず元に戻す(リスト化する)
テスト中に広げた設定を「あとで戻す」と言ったまま忘れてしまうのは、私だけではないと思います。あの一件以来、設定変更はメモ(チェックリスト)に残して、本番移行前に元へ戻したことを確認するステップを必ず入れるようにしています。3. メールキューとログを定期的に確認する
セミナーで3,100名以上を指導してきましたが、「メールサーバーを設定したつもりが、実は動いていなかった」というケースは意外と多いです。逆に「動きすぎていた(オープンリレー)」というケースもあります。どちらも、キューとメールログを定期的に見ていれば早い段階で気づけます。
・
postqueue -p:メールキューの状態確認・
/var/log/maillog や journalctl -u postfix:ログの確認Postfixのログ確認については、Postfixのバージョン確認と基本設定の記事も参考にしてみてください。
本記事のまとめ
Postfixのオープンリレーは、今でも世界中で起きています。設定そのものは簡単なだけに、うっかりミスが起きやすい箇所でもあります。| 確認ポイント | 内容 |
|---|---|
| mynetworksの設定 | 自社のIPアドレス範囲のみを指定する(0.0.0.0/0は絶対に禁止) |
| オープンリレーテスト | 設定後・本番稼働前に必ず外部からのリレーを試みて「拒否」を確認する |
| キュー・ログの定期確認 | postqueue -pとメールログを定期的に確認する習慣を持つ |
Postfixの詳細な設定については、PostfixのMynetworks設定方法の記事も参考にしてみてください。
メールサーバーだけでなく、Linuxサーバー構築の「型」を身につけませんか?
設定ミスが大きな障害につながる経験は、メールサーバーに限りません。サーバー構築全体の「型」を知っていれば、今日のような事故を未然に防げます。
ネットの切れ端の情報をコピペするだけでなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル(図解60P)』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら
- 前のページへ:Linuxでバッチ処理がSSH切断で止まった話|nohupを知らなかったSE時代の失敗と現役講師が今も守る長時間処理の鉄則
- この記事の属するカテゴリ:Linux学習ガイドへ戻る

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます