質問:
SMTP バナーの遅延の原因としてどのようなものがありますか
一般にメール サーバのポート 25 に対して Telnet 接続すると、SMTP バナーを迅速に取得できます。SMTP バナーの例を次に示します。
220 host.example.com ESMTP
554 host.example.com
遅延が発生し、表示される内容が接続情報だけであることがあります。ランダム データの例は次のとおりです。
host.example.com> telnet 10.92.152.18 25
Trying 10.92.152.18...
Connected to host.example.com.
Escape character is '^]'.
この例にはバナーがないことに注意してください。ある程度の時間が経過すると、バナーが最終的に次の行に表示されます。この記事では特定の状況について説明します。ここで説明する一般的な原因は、DNSの問題、高いCPU使用率、リソース節約モード、ファイアウォールの4つです。
DNS の問題
SMTP バナーが遅延する原因として最も一般的なのは、DNS ルックアップに通常よりも長い時間がかかっているか、DNS ルックアップがタイムアウトしていることです。接続とバナー表示の間には、逆引きDNS(またはPTRレコード)ルックアップ、PTRレコードで指定されたホスト名の前方(またはAレコード)ルックアップ、接続ホストのSBRS(SenderBaseレピュテーションスコア)を取得するためのSenderBaseルックアップの3つのルックアップが行われます。
これらのルックアップは、接続ホストが属する送信者グループを確認するために使用されます。これにより、使用するメール フロー ポリシーと、このホストからのメールが受け入れられるかどうかが決まります。これは、メール バナーがある場合にどのメール バナーが送信されるかに影響します。このため、バナーが指定される前にこれらのルックアップが実行されることが重要です。
問題が DNS に関連するものであるかどうかを判別するには、ESA のコマンド ライン(CLI)にログインし、nslookup コマンドを使用する必要があります。アプライアンス自体からこの操作を実行し、アプライアンスの観点から作業することが重要です。まず、接続しようとしている IP アドレスを把握する必要があります。この IP アドレスを取得するには、mail_logs または Message Tracking を使用できます。
IP が判明したら、nslookup を使用してテストを開始できます。各 DNS ルックアップにかかる秒数を
計測してください。最初に逆引き DNS ルックアップを実行します。
host.example.com> nslookup 10.92.152.18
PTR= host.example.com TTL=2h 35m 43s
次に、逆引き DNS ルックアップで戻されたホスト名に対して次のようにルックアップを実行します。
host.example.com> nslookup host.example.com
A=10.92.152.18 TTL=2h 34m 16s
この 2 つのルックアップにかかった時間の合計がバナーの遅延時間とほぼ一致する場合には、原因が判明しました。さらに DNS の状況を確認できます。次のステップでは、異なるネットワークの他の IP アドレスをテストできます。これにより、問題が特定のホストまたはネットワークに切り分けられるものであるかどうか、またはより一般的な DNS の問題が発生しているかどうかを確認できます。
高い CPU 使用率
SMTP バナーの遅延の原因となる可能性があるもう 1 つの状況として、非常に高い CPU 使用率があります。
システムの負荷が高くなると、すべての処理に時間がかかります。これを確認するには、[Monitor] タブの [System Status] ページに移動するか、または CLI コマンド「status detail」を使用します。どちらの方法でも、[Gages] セクションに CPU 使用率統計情報が示されます。ランダム データの例は次のとおりです。
CPU Utilization
Total 67%
MGA 16%
CASE 46%
Brightmail AntiSpam 0%
AntiVirus 0%
Reporting 4%
Quarantine 0%
[Total] が非常に高く(95% 以上)、数分間にわたりこの高い状態が続く場合、CPU の使用率が
SMTP バナーの遅延の原因である可能性があります。
リソース節約モード
SMTP バナーの遅延の原因となる可能性があるもう 1 つの状況として、システムがリソース節約モードになっていることがあります。このモードでは、システムはメール受け入れフローを低速化することでシステム自体を保護します。このため、システムは送信する各 SMTP 応答を意図的に遅らせます。システムがリソース節約モードであるかどうかを確認するには、[Monitor] タブの [System Status] ページに移動するか、または CLI コマンド「status detail」を使用します。[Gages] セクションの [Resource Conservation] 行を確認します。
ランダム データの例は次のとおりです。
Resource Conservation 0
ゼロ以外の数値が示されている場合、システムが SMTP 応答を遅延させることでシステム自体を保護しようとしています。リソース節約の詳細については、
「リソース保護モードについて」を参照してください。
ファイアウォール
最後に説明する SMTP バナーの遅延の一般的な原因は、SMTP 対応ファイアウォールです。これには、「SMTP fixup」の実行や、すべての SMTP コンテンツに対するセキュリティ スキャンの実行といった機能があります。ファイアウォールが SMTP バナーの内容をスキャンし、その内容を変更する可能性がある場合に、バナーの遅延が発生することがあります。一般的なファイアウォールによる SMTP バナーの変更の例を次に示します。
220
*****02***********************************************************0****0****
0 ***************2******200**0*********0*00