Cisco Secure Eメールゲートウェイでメッセージが受信されなかった理由をトラブルシューティングするにはどうすればよいですか。

概要

このドキュメントでは、メッセージがCisco Secure Email Gatewayで受信されない理由と、この問題をトラブルシューティングするためのオプションについて説明します。

Cisco Secure Eメールゲートウェイでメッセージが受信されなかった理由をトラブルシューティングするにはどうすればよいですか。

メッセージの受信をトラブルシューティングするには、メールを送信した組織がメールを送信するために使用するIPアドレスを知っている必要があります。通常、この情報を取得する最も正確な方法は、送信者組織のメール管理者に問い合せることです。このリソースがない場合は、次のいずれかのオプションを使用できます。

• SenderBase:http://www.senderbase.orgの検索ボックスにドメインを入力すると、そのドメインの既知の送信IPアドレスのリストが表示されます。
• メールログ：以前にドメインから正常にメールを受信した場合は、メールログで正常な配信の1つを探すことができます。
• ドメインネームシステム(DNS)：ドメインのメールエクスチェンジャー(MX)レコードを検索できます。ほとんどの小規模な組織では、同じ着信サーバと発信サーバが使用されます。セグメント化された組織の規模が大きくなっても、このオプションは必要な情報を明らかにしません。

IPアドレスがわかったら、メールログを検索する必要があります。grepユーティリティはこの目的に適したツールです。Microsoft Windowsを実行している場合は、[ワードパッドで検索]または[メモ帳]を使用するか、インターネットからgrepユーティリティをダウンロードできます。UnixとMac OSXにはgrepが組み込まれており、シェルからアクセスできます。grepコマンドラインは次のようになります。「10.2.3.4」は検索するIPアドレスです。

host> grep '10.2.3.4' file.log

送信者のサーバが正常にサーバに接続すると、IPアドレスを検索するときに、次の例のような行が表示されます。

Wed Feb  2 23:43:11 2008 Info: New SMTP ICID 6 interface Management (10.0.0.1)
 address 10.2.3.4 reverse dns host test.ironport.com verified no

その後、着信接続ID(ICID)を含むすべての回線を検索できます。 見つかった行は、From情報を送信したか、To情報を送信したか、および接続にリンクされたメッセージID(MID)を送信したかを示します。MIDで検索を実行すると、メッセージがシステムで受け入れられたかどうか、スキャン結果、配信が試行されたかどうかを確認できます。

もう1つのトラブルシューティングツールとして、インジェクションデバッグログがあります。最初に、送信側サーバのIPアドレスが必要です。これを取得したら、 logconfig コマンドを使用して、このログタイプを選択します。ログの設定とコミットが完了したら、ユーザにテストメッセージを送信させ（サーバがCisco Secure Email Gatewayに接続されていると仮定）、Cisco Secure Email GatewayがSMTPメッセージ全体を記録します。これにより、通信の内訳を確認できます。

まだ接続がなく、メッセージが受信されない場合は、次のステップとして、送信側サーバの管理者にログを確認してもらうか、telnetを使用してメールサーバからのメッセージの送信を手動でテストします。これは、Cisco Secure Eメールゲートウェイに配信しようとしているサーバを模倣し、Cisco Secure Eメールゲートウェイは、送信サーバアプリケーションが送信した場合と同じように動作します。

テストが終了しても、サーバアプリケーションがメールを送信しようとすると失敗する場合は、リモートサーバでの配信の問題を示します。リモートサーバ管理者は、エラーを診断するためにログを確認する必要があります。

メッセージの受信の遅延または失敗の一般的な原因の1つは、送信側サーバのIPアドレスに正しく設定された逆DNSがないことです。これにより、Cisco Secure Email GatewayがSMTPバナーを提供するために長い遅延（30秒以上）が発生します。一部のサーバアプリケーションは、設定されたタイムアウトに達し、遅延バナーが原因でメールを送信する前にセッションを閉じます。この場合の解決策は、タイムアウトを延長するか、逆DNSを実装することです。他のインターネットメールサーバに配信するすべてのメールサーバに対してリバースDNSを実装することを推奨します。これは適切なインターネットエチケットと見なされ、メールサーバはサーバのアイデンティティを非常に基本的なレベルで確認できます。