メールサーバーの動作チェックのポイント

メールサーバー は多くの サーバー アプリケーション が連携しています。

従って例えば、 「メールが送信できない」 という単純なトラブルでも、 MUA 、 MTA 、 DNS の三つのアプリケーションの他、 SMTP AUTH を利用している場合は更にsaslauthd を、 POP/IMAP before SMTP を利用している場合には、更に drac や Pop-before-smtp 及び MRA までチェック対象にしなければなりません。

そう考えると、メールサーバーのトラブルの解消は「ちょっと面倒」と思えるかもしれません。

ただ、個々のアプリケーションにはそれほど複雑な設定を行っているわけではなく、動作そのものも単純ですので、仕組みさえきちんと理解できていればむしろ httpd のように大量の設定項目がある単一のアプリケーションよりもやさしいはずです。

このパートではメールサーバーに不具合が起こったときのチェックのポイントを挙げてみましょう。

関連セクション・ Sendmailの設定

関連セクション・ Postfixの設定

サーバーからメールが受信できない

意外に勘違いしている人が多いのですが、 MUA からの要求でメールを受信する場合、 Sendmail や Postfix などの MTA は全く無関係です。

必要になるのは、 UW IMAP の POP3 または IMAP などの MRA デーモン と、 構築中のLinuxサーバー に対する DNSサーバー の 名前解決 情報です。

LAN内のホストから受信できない場合

LAN 内の ホスト機 から 構築中のLinuxサーバー 上のメールが受信できない場合は、

１．必要なMRAデーモンが稼動していない。

２．MUAの「受信メールサーバー」で設定されている FQDN "mail.obenri.com"が、そのホスト機で"192.168.100.11"に名前解決されていない。

のいずれかが原因です。

まずは を参考に、必要なMRAデーモンが稼動可能な状態になっているかどうかを確認してください。特に、 POP/IMAP before SMTP の設定などを行うときは、一時的にデーモンを停止してしまうことがあるかもしれませんから、設定が停止のままになってしまっているかもしれません。

これらのデーモンは xinetd 依存型ですので、通常の単独起動型デーモンと扱いが異なります。有効化の方法を間違えないように気をつけてください。

名前解決の問題については、とりあえずMUAに設定している「受信メールサーバー」の項目を一時的に、

と変更して受信を行ってみてください。

これできちんと受信ができるようであれば、原因は間違いなく名前解決にあることになります。

試しにお使いのホスト機から、"mail.obenri.com"に対して ping コマンド で、きちんと"192.168.100.11"から応答が返ってくるかどうかを確認してみてください。

きっと別の IPアドレス に名前解決されてしまったり、あるいは名前解決が行われずにpingに対する応答が返って来ないはずです。

この場合は、お使いのホスト機に設定している hostsファイル の記述か、 構築中のLinuxサーバー で稼動しているDNSサーバー の設定に誤りがありますので、これをもう一度見直す必要があります。

LAN外のホストから受信できない場合

UW IMAP は、受信を要求する MUA の ノード を区別せずに動作しますから、 ルーター に対して ポートフォワーディング がきちんと設定され、 WAN 空間で "mail.obenri.com" が正しく名前解決されていれば、間違いなく受信することができます。

まずは、お使いのMUAが利用するメール受信 プロトコル ( POP3 の場合は "110" 、 IMAP の場合は "143" ) に対してきちんとポートフォワーディングが設定されているかどうかをチェックしてください 。

また、この コンテンツ ではWAN空間で ドメイン名 "obenri.com" に関する名前解決を行うのに ダイナミックDNS を利用することを前提にしていますから、もちろんこれが正常に動作しているかどうかを確認すればOKです。

テストの方法は、 構築中のLinuxサーバー 上の シェル プロンプト から host コマンドを使って行うのが簡単です。

まず、 SSHクライアント から適当な ユーザーアカウント で 構築中のLinuxサーバー に ログイン します。

それから "mail.obenri.com" に対して名前解決のテストを行いますが、既に 構築中のLinuxサーバー 上で LAN 用のDNSサーバーを設置している場合には、コマンドの実行時に明示的にWAN空間用のDNSサーバー(自分が契約している ISP のDNSサーバーが適当でしょう。) を指定します。

ここで得られた [サブネットのWAN側のIPアドレス] と、実際に自宅の ルーター の WAN側に割り当てられているIPアドレス が一致していることを確認してください。

もしもこの説明どおりの名前解決結果が得られない場合は、ダイナミックDNSに関する設定 、あるいはダイナミックDNSの自動更新に関する設定 に誤りがあるのか、それともダイナミックDNSのサーバー自身に問題があって、名前解決情報がきちんと発信されてないか、のどちらかということになります。

もちろんその場合は、この部分の問題を解決しなければなりませんから、利用しているダイナミックDNSの設定をもう一度確認してください。

また、お使いのホスト機に セキュリティ 対策用のアンチウイルスソフトやファイヤーウォールソフトがインストールされている場合には、過度の設定によってメールの受信がブロックされている可能性があります。

この場合はお使いの対策ソフトの問題ですので、自力で解決するより他はありません。

関連セクション・ Sendmailの設定

関連セクション・ Postfixの設定

ホスト情報の表示　 　全ページリストへ　 　お便利用語リスト

メールの受信に時間がかかる

確かにメールの受信はできるものの、 MUA で受信作業を行ってから実際にメールが ダウンロード されるまでに十数秒、あるいは一分近く時間を要することがあります。

これは間違いなくMUAを使っている ホスト機 の問題で、 セキュリティ 対策用のアンチウイルスソフトやファイヤーウォールソフトが、受信すべきメールのチェックなどで受信が遅くなってしまっているに過ぎません。

もちろんこの場合はお使いの対策ソフトの問題ですので、自力で解決するより他はありません。

関連セクション・ Sendmailの設定

関連セクション・ Postfixの設定

ホスト情報の表示　 　全ページリストへ　 　お便利用語リスト

メールをサーバーに送信できない

LAN 内の ホスト機 で 構築中のLinuxサーバー からのメールの受信はできるのに送信はできないという場合、問題は少し複雑になります。

この コンテンツ 推奨の方法、つまり Sendmail の場合は、

１． "/etc/mail/sendmail.mc" で、

という書き換えを行って「全てのノードからの送信を許可」して、 "/etc/mail/sendmail.cf" を作成 。

２． "/etc/mail/access" で、

と設定して、「自ホストとLAN内のホストに対して、転送を伴うメールの送信許可」を与え、 "/etc/mail/access.db" を作成 。

３． "/etc/mail/local-host-names を、

と記述して、「 デフォルト の"xxxxx@web1.obenri.com"宛てに加えて "xxxxx@obenri.com"宛てのメールを自ホスト宛として 構築中のLinuxサーバー 上のメールボックスに保存」と設定 。

Postfix の場合は、 "/etc/postfix/main.cf" で、

１． "inet_interfaces" ディレクティブ を、

と修正して「全てのノードからの送信を許可」に設定 。

２． "mynetworks_style" ディレクティブをデフォルトである、

のまま使用して "mynetworks_style = subnet" を有効にし、「自ホストとLAN内のホストに対して、転送を伴うメールの送信許可」と設定 。

３． "mydestination" ディレクティブを、

と設定して、「 デフォルト の"xxxxx@web1.obenri.com"宛てと "xxxxx@obenri.com"宛てのメールを自ホスト宛として 構築中のLinuxサーバー 上のメールボックスに保存」と設定 。

と設定していれば、任意の MUA または 構築中のLinuxサーバー 以外の MTA (例えば ISP などが運営しているMTAなど)から送られてくるメールは、 構築中のLinuxサーバー 上では、次の二つのアクションパターンのいずれかで処理されます。

つまり、「メールが送信できない」という場合にはそのメールが、

「どこのMUAから送信されているのか」

「宛先が"xxxxx@obenri.comなのか、そうでないのか。」

という違いで対処方法が変わってきますから、まずは上に挙げた部分の設定をもう一度きちんと確認してその 設定を有効化する作業 を行い、以下の説明の中から該当する項目を参照してください。

LAN内のホストから"xxxxx@obenri.com"に送信できない

転送を伴わない一番単純な動作ですから、これができないということは、 MTA の設定の問題というより、それ以前の部分に問題があります。この場合原因は、

１．必要なMTAデーモンが稼動していない。

２． MUA の「送信メールサーバー」で設定されている FQDN "mail.obenri.com"が、その ホスト で"192.168.100.11"に名前解決されていない。

３．送信先の アカウント が存在しない。

のいずれかが原因と考えられます。

まずは または を参考に、必要なMTAデーモンが稼動しているかどうかを確認してください。もちろん、 Sendmail と Postfix を同時に稼動させてはいけないことはいうまでもありません。

名前解決の問題については、とりあえずMUAに設定している「送信メールサーバー」の項目を一時的に、

と変更して送信を行ってみてください。

これできちんとメールが送信ができるようであれば、原因は間違いなく名前解決にあることになります。

試しにお使いのホスト機から、"mail.obenri.com"に対して ping コマンド で、きちんと"192.168.100.11"から応答が返ってくるかどうかを確認してみてください。

きっと別の IPアドレス に名前解決されてしまったり、あるいは名前解決が行われずにpingに対する応答が返って来ないはずです。

この場合は、お使いのホスト機に設定している hostsファイル の記述か、 構築中のLinuxサーバー で稼動しているDNSサーバー の設定に誤りがありますので、これをもう一度見直す必要があります。

また、お使いのホスト機に セキュリティ 対策用のアンチウイルスソフトやファイヤーウォールソフトがインストールされている場合には、過度の設定によってメールの受信がブロックされている可能性があります。

この場合はお使いの対策ソフトの問題ですので、自力で解決するより他はありません。

また、意外にうっかりやってしまうのが、 ３． の「存在しないアカウントにメールを送信してしまう。」というミスです。

メールサーバー の構築中は、送信テスト用のアカウントを作ったり、削除したりを繰り返すことが多いので、こういうミスが起こりやすくなります。

もちろん、存在しないアカウント宛にメールを送ることはできません。

とにかく、 LAN 内の ホスト から "xxxxx@obenri.com" 宛てのメールが送信できることが、その他のケースでのメール送信の成否を検討する場合の前提となりますから、最低限これだけは確実に行えるようにしてください。

LAN内のホストから"xxxxx@obenri.com"以外に送信できない

「送信メールサーバー」として "mail.obenri.com" が設定された MUA の アカウント から、例えば "xxxxx@ispdomain.com" 宛てのメールの送信を行うような場合です。

このとき、送信指示を受けた "mail(web1).obenri.com" は、 "ispdomain.com" について DNS による 名前解決 を行い、転送先のMTAの IPアドレス を探して転送を試みることになります。

従って、もしも前に説明した「LAN内のホストから"mail.obenri.com"を使用して"xxxxx@obenri.com"に送信できない」という問題が既に解消しているのであれば、

１．"xxxxx@ispdomain.com"の転送先のMTAがダウンしている。

２．送信先のMTAのメールボックスの受信容量などが制限を越えている。

３． 構築中のLinuxサーバー が、 WAN 空間の名前解決を正常にできていない。

４．"mail.obenri.com"が、WAN空間で正常に名前解決されていない。

つまり、 １．２． のような「相手側のMTAに問題がある」ケースを除くと、問題の中心は名前解決にあるということになります。

まず、 SSHクライアント から適当な ユーザーアカウント で 構築中のLinuxサーバー に ログイン し、 プロンプト から host コマンド などを利用して、WAN空間に存在するの適当な FQDN に対して名前解決を試してみてください。

テストは www.yahoo.co.jp でも www.asahi.com でも、実在するFQDNであれば何でも構いません。どれかひとつだけでもエラーなく名前解決できればそれでOKです。

これが確認できれば、 ３． の問題はクリアされていることになりますが、もしもこの部分でエラーが出る場合は、 構築中のLinuxサーバー が参照するDNSサーバーの設定 を、また独自にDNSサーバーを稼動させている場合は を、もう一度確認してみてください。

また、世の中のMTAの多くは、 FQDN 情報を持たないMTAからのメールの転送を受け付けませんから、 "mail.obenri.com" がWAN空間できちんと グローバルIPアドレス に名前解決されない場合は、受け取りを拒否されてしまうのが普通です。

この コンテンツ ではWAN空間で ドメイン名 "obenri.com" に関する名前解決を行うのに ダイナミックDNS を利用することを前提にしていますから、もちろんこれが正常に動作しているかどうかを確認すればOKです。

テストの方法は、上の場合と同じくhostコマンドを使いますが、既に 構築中のLinuxサーバー 上で LAN 用のDNSサーバーを設置している場合には、コマンドの実行時に明示的にWAN空間用のDNSサーバー(自分が契約している ISP のDNSサーバーが適当でしょう。) を指定します。

ここで得られた [サブネットのWAN側のIPアドレス] と、実際に自宅の ルーター の WAN側に割り当てられているIPアドレス が一致していれば、 ４． の問題はクリアされていることになります。

もしもこの説明どおりの名前解決結果が得られない場合は、ダイナミックDNSに関する設定 、あるいはダイナミックDNSの自動更新に関する設定 、のいずれかに誤りがあるのか、それともダイナミックDNSのサーバー自身に問題があって、名前解決情報がきちんと発信されてないか、のどれらかということになります。

もちろんその場合は、この部分の問題を解決しなければなりません。

ここまで確認できれば、通常は "mail.obenri.com" を送信メールサーバーとした 外部へのメール転送を間違いなくうまくいくはずです。

それでもメールが送信できない場合は、極めて稀なケースですが、

５．"mail.obenri.com"が、転送先のMTAから受信制限を受けている。

という可能性を疑ってください。

世の中のMTAには、スパムメールを阻止するための自動プログラムが設置されている場合があります。

この自動プログラムは、過去に多数のスパムメールを転送してきた ノード に対して、自動的にメールの受信拒否、あるいは隔離を行いますから、そういうブラックリストに挙がっているグローバルIPアドレスを利用するような場合には、特定のMTAから受信拒否を受けることがあります。

「mail.obenri.comは、スパムメールなんか配信したことはない！。」

と思われるかもしれませんが、現在の通信契約が非固定のグローバルIPアドレスを利用するものである以上 、過去にそういった犯罪歴を持つグローバルIPアドレスが、たまたま割り当てられる可能性はゼロとはいえません。

もしも、ここまでの全ての対策と設定の見直しをおこなってもなおかつ外部のMTAへのメールの送信を行うことができない場合には、 ルーター のリセットなどを行って意図的にグローバルIPアドレスを変えてしまうのも一つの対処方法を思ってください。

LAN外のホストから"xxxxx@obenri.com"に送信できない

「送信メールサーバー」として "mail.obenri.com" を設定した MUA の アカウント を外出先などから利用して、 "xxxxx@obenri.com" 宛てにメールを送るケースです。

ここまでのメール送信がきちんと行われているのであれば、これがうまくいかない理由は一つしかありません。すなわち、

ルーター に SMTP の ポートフォワーディング が適切に設定されていない。

という一点につきます。

他に原因はありませんから、もう一度ルーターの設定を確認してください 。

LAN外のホストから"xxxxx@obenri.com"以外に送信できない

これは セキュリティ 上、通常行うことができない作業です。

これが常に可能であるとしたら、 構築中のLinuxサーバー は不正中継を許している「危険な メールサーバー 」ということになります。

ですから、これは「送信できない」のが正しく、逆にこれが可能であることのほうが問題ということになります。

ただし、 SMTP AUTH を利用している場合は、SMTP AUTHの設定が行われている特定のクライアントからのメール送信は、任意の場所から可能となります。

また、 POP/IMAP before SMTP を稼動させている場合は、一時的に外部からのメール送信が可能となります。

POP/IMAP before SMTP関連プログラムの動作確認については、 を参考にしてください。

関連セクション・ Sendmailの設定

関連セクション・ Postfixの設定

ホスト情報の表示　 　全ページリストへ　 　お便利用語リスト

他のMTAからのメールを受信できない

"web1..obenri.com" 上の MTA は、メールを他のMTAへ転送するだけではなく、その逆の動作も担います。つまり他のMTAから転送されるメールの受信です。

例えば、外部のMTAを「送信メールサーバー」として利用している友人や知人などから "xxxxx@obenri.com" 宛てに送られてくるメールの扱いを指します。

ただ、この動作はMTAの仕組み上、前に説明した「LAN外のホストからxxxxx@obenri.com宛てのメールの送信。」と全く同じパターンになります。

もちろん、うまくいかない場合の対処方法も全く同じですので、そちらの説明を参考にしてください。

関連セクション・ Sendmailの設定

関連セクション・ Postfixの設定

ホスト情報の表示　 　全ページリストへ　 　お便利用語リスト

MTAの不正中継のチェック方法

この コンテンツ で紹介しているような、単独の 公開サーバー による メールサーバー では、余程大きな間違いをしない限りは、スパムメールの配信に利用されるような不正中継を行うことはないでしょう。

ところがシステムが大掛かりになって、複数のメールサーバーで転送を行ったり、バックアップメールサーバーを設置したりするようになると、設定そのものが複雑になって予期せぬ不正中継を許してしまうことにもなりかねません。

もちろん、メールサーバーの動作パターンを一つずつチェックするのが不正中継防止の最も確実な方法ですが、例えばホームページ上で不正中継テストを行ってくれる、以下のようなサイトを利用させてもらうのが簡単で確実です。

あなたが設置したメールサーバーが不正使用された場合、実はあなた自身が被害者ではなく、実際にスパムメールが送りつけられた人たちが被害者となります。

不注意とはいえ、むしろスパムメールの蔓延に手を貸したあなた自身は、間接的には加害者といわれても仕方がないでしょう。

メールサーバーを設置する場合には、不正中継にはくれぐれもご注意ください。

関連セクション・ Sendmailの設定

関連セクション・ Postfixの設定

ホスト情報の表示　 　全ページリストへ　 　お便利用語リスト