一般的なEメールセキュリティアプライアンスエラーのトラブルシューティング
はじめに
このドキュメントでは、Cisco Eメールセキュリティアプライアンス(ESA)の一般的な設定エラーについて説明します。
環境
- 製品:Cisco Eメールセキュリティアプライアンス(ESA)
- ソフトウェア:AsyncOS for ESA（バージョンは導入によって異なる）
- 範囲：必要に応じて、このガイダンスを受信メールポリシーと送信メールポリシーに適用します。変更を行う前に各セクションを確認してください。
前提条件
- ESAへの管理アクセス（GUIまたはCLI）
- メールログとメッセージトラッキングを検証のために確認する機能
- レピュテーションサービスSenderBaseレピュテーションスコアSBRSベースの送信者グループを使用している場合はSBRSが有効
- Host Access Table(HAT)は、メールポリシーを評価する前に接続しているホストを分類し、後で制御を適用する方法に影響を与えることを認識
一般的な検証
- Monitor > Overviewおよびメッセージトラッキングを使用して、変更後に予想される送信者グループの分類、ポリシーの一致、および配信結果を確認します。成功とは、変更後に予想される送信者グループ、ポリシー、および配信結果が表示されることを意味します。
- レピュテーションまたはフィルタリング設定を強化した後、7 ～ 144日間にわたって隔離および誤検出を監視し、必要に応じて既知のビジネスパートナー向けに調整します。
Eメールセキュリティアプライアンス(ESA)の一般的な設定エラー
これらのチェックを使用して、Eメールセキュリティアプライアンス(ESA)の一般的な設定エラーを特定して修正します。 各サブセクションでは、問題を迅速に診断して修正できるように、一貫した問題、原因、解決、および検証パターンを使用します。
ホストアクセステーブル(HAT)
症状
- レピュテーションベースの送信者グループが過度に許容されているため、スパムは受け入れられます。
- 正規のメールは、過度に厳密な接続制御のためにスロットリングまたはブロックされます。
原因
- 送信者グループが、不適切なSenderBase評価スコア(SBRS)範囲またはドメインネームシステム(DNS)検証設定で構成されています。
解決策
- 許可リストに正のSBRS値（+5や+7など）を追加しないでください。SBRSベースの許可リストの場合、9.0 ～ 10.0のスコアのみを使用し、メッセージ追跡で検証します。
- 必要な場合にのみ、不明な送信者のリストとDNS検証機能を設定します。不要な場合は、UNKNOWNLIST、Envelope SenderDNS Verification、およびConnecting HostDNS Verificationを無効にします。
注：ESAのユーザインターフェイスでは、不明な送信者のリストに対して従来のtermUNKNOWNLISTが使用されます。
- ポリシーごとの設定の不整合を回避するには、グローバルなデフォルトを設定します。それには、Mail Policies > Mail Flow Policies > Default Policy Parametersの順に選択し、メッセージサイズとその他のデフォルトパラメータを設定します。
- ほとんどの送信者（3など）に適切なデフォルトの最大接続数を設定し、それを新しいメールフローポリシーのデフォルトとして適用します。必要に応じて、既知の大量の送信者に合わせて調整します。
- リスク許容度に基づいてブロックリストのSBRS範囲を設定します。多くの導入では、SBRS -10.0 ～ -2.0をブロックすると、誤検出率が低くなる可能性があります。メッセージトラッキングによる検証と、ビジネスパートナー向けの調整
ポリシー
症状/影響
- デフォルト以外のメールポリシーによってグローバルなデフォルトが上書きされるため、メールが予期せずスキャンまたは検疫される。
- 送信メールは不必要なスパム対策/アウトブレイクフィルタのアクションをトリガーするため、処理時間が長くなり、誤検出が増加します。
- 感染した添付ファイルは削除され、メッセージ本文には削除されたコンテンツのみが含まれるため、メッセージは空白で表示されます。
原因
- デフォルト以外のポリシーは、特定の要件なしで、デフォルトのアンチスパム、アンチウイルス、コンテンツフィルタ、またはアウトブレイクフィルタ設定を複製または上書きします。
- アウトバウンドポリシーは、インバウンドに重点を置いたスキャン機能を適用します。
解決策
- 適用する受信者のメールポリシーに名前を付け（例：Inbound_Executives）、コンテンツフィルタで実行するアクションに名前を付けます（例：Q_basic_attachments、Dspooferss）。
- デフォルト以外のポリシーの場合は、ドキュメント化された例外が必要でない限り、アンチスパム、アンチウイルス、コンテンツフィルタ、およびアウトブレイクフィルタに対してデフォルト設定の使用を選択します。
- Drop infected attachmentsのチェックボックスをオフにして、欠落した内容が空白に見えるメッセージが配信されないようにします。
- アウトバウンドウイルス対策のアクションについては、受信者ではなく送信者に通知します。
- 明示的なアウトバウンドユースケースが存在しない限り、アウトバウンドメールポリシーのアウトブレイクフィルタおよびスパム対策を無効にします。
確認
- メッセージトラッキングを使用して、目的のメールポリシーが一致し、予期される場所にデフォルトのスキャン設定が継承されることを確認します。
- 制御された発信テストメッセージを送信し、例外によって設定されていない限り、スパム対策/アウトブレイクフィルタが適用されていないことを確認します。
着信リレー
症状
- 内部メールサーバは外部送信者として扱われるため、予期しないスロットリング、フィルタリング、またはレピュテーションベースのアクションが発生する可能性があります。
原因
- 内部メールサーバのIPアドレスまたはネットワークが着信リレーとして設定されていないか、着信リレー機能が無効になっています。
- 内部リレーホストは専用のHAT送信者グループに分類されないため、意図しない接続制限やDirectory Harvest Attack Prevention(DHAP)動作が発生する可能性があります。
解決策
- GUIでMail Policies > Incoming Relaysの順に選択し、内部メールサーバのIPアドレスまたはネットワークを追加します。
- 着信リレー機能が有効になっていることを確認します（テーブルにエントリを追加するだけでなく）。
- 前のリストの許可リストにリストされている内部リレーの専用のホストアクセステーブル(HAT)送信者グループを、レポート用に作成します。必要に応じてスパム対策とウイルス対策スキャンを有効にしたまま、レート制限なしおよびディレクトリ獲得攻撃防御(DHAP)なしを設定してください。DHAPは、Simple Mail Transfer Protocol(SMTP)カンバセーション中の無効な受信者の列挙を制限します。
- 中継されていないトラフィックのレピュテーションに基づいてメールをドロップする場合は、必要に応じて、中継されたメールと同等の処理を適用するメッセージフィルタを追加します。例：
Drop_Low_Reputation_Relayed_Mail:
if reputation <= -2.0
{ drop(); }
確認
- Monitor > Overviewで、内部サーバが信頼できない外部送信者として表示されなくなったことを確認します。
- メッセージトラッキング/メールログで、想定される送信者グループが適用されていることを確認します（たとえば、内部は送信者グループをリレーします）。
注：メールが再注入される場合（たとえば、加入者間メールがインバウンドポリシーによって再処理される場合）、必要に応じてフィルタの注入インターフェイスを免除します。再注入ではポリシー評価によってメッセージが返送されるため、インターフェイスが除外されない限り、フィルタは同じメッセージに再度一致できます。
DNS
症状
- DNSリゾルバの選択または分割：DNS設定により、配信の失敗、SMTPトランザクションの遅延、レピュテーションの失敗が発生します。DNSベースのチェックに失敗します。
環境
- パブリックDNS解決、内部のみのDNS解決、または内部ドメインとサービスのsplit-horizonDNSを必要とする展開に適用されます。
症状
- メッセージトラッキングは、MX、AAA、PTRR、またはレピュテーション関連のクエリに対するDNSlookupの失敗とタイムアウトを示します。
- DNSの再試行が繰り返されているため、メール配信が遅延しています。
原因
- ESAは、必要なパブリックレコード、必要な内部レコード、またはその両方を解決できないリゾルバを使用するように設定されています。
- 送信元ネットワークに基づいて同じドメインに対して異なる解答を返すSplit-horizonDNSが必要ですが、内部ドメインまたはサービスには実装されていません。
解決策
ESAがレコードを解決する場所（パブリックインターネット、内部専用ドメイン、またはその両方）に基づいて、ドメインネームシステム(DNS)解決を設定します。
1. ESAが主にパブリックDNSレコードを必要とし、ポリシーで許可されている場合は、パブリック再帰リゾルバを使用します。
2. ESAが内部のみのゾーン、内部メール交換(MXX)レコード、Lightweight Directory Access Protocol(LDAPP)レコード、またはその他のプライベートサービスを解決する必要がある場合は、internalDNSまたはスプリットホライズンDNSを使用します。
3. パブリックDNSは、アプライアンスが主にインターネットメールレコードを解決し、内部専用ゾーンやポリシー制限が適用されない場合に適しています。
必要に応じてInternalDNSまたはsplitDNSを使用
- 内部専用ドメイン
- InternalMXXレコード
- スプリットホライズンDNS（送信元ネットワークに基づいて同じドメインに対して異なる解答）
- コンプライアンスまたはセキュリティポリシーには、内部の再帰リゾルバが必要
- ルーティングに必要なPrivateDNSゾーン
- Lightweight Directory Access Protocol(LDAP)に必要なPrivateDNSゾーン
- ESAで使用される内部サービスに必要なPrivateDNSゾーン
確認
- ESAが必要なパブリックおよび内部ホスト名（該当する場合）を解決できること、およびメール配信とレピュテーションDNSベースのチェックがメッセージトラッキングで成功することを確認します。
メッセージ フィルタとコンテンツ フィルタ
最も一般的なエラーは、不要な場合にフィルタに一致条件を追加することです。
- 空の条件：特定のメールポリシーのすべてのメッセージに対してフィルタを実行する必要がある場合は、条件を空白のままにします。
- 評価動作：asyncOSメッセージフィルタでは、空白の条件はtrueと評価されるため、フィルタは到達するすべてのメッセージで実行されます。
- 範囲：適切な受信または送信メールポリシーにフィルタを適用して範囲を制御します。
- 順序：メッセージフィルタは、メッセージ属性とアクションを順番に評価します。コンテンツフィルタは、通常、それらを呼び出すメールポリシーによってスコープが設定されます。
例:
- 特定のユーザまたはグループを対象とする場合は、通常、メッセージフィルタでrcpt-to条件を使用する必要はありません。受信者ベースの受信メールポリシーを優先し、要件が受信者または受信者グループに明確にマッピングされている場合は、そのポリシーにコンテンツフィルタを適用します。ポリシー照合では要件を満たすことができない例外に対しては、rcpt-to条件を予約します。
- 特定の種類の添付ファイルをブロックする目的で添付ファイルをドロップする前に添付ファイルの有無をテストすることは、通常、冗長です。フィルタを設定して、ターゲットの接続タイプを直接削除します。接続の有無に応じて異なるアクションが必要な場合にのみ、接続プレゼンステストを使用します。
- deliver()は、メッセージが残りのフィルタをバイパスする必要がある場合にのみ使用してください。deliver()アクションはそれ以上のフィルタ処理を停止し、メッセージを配信します。残りのフィルタをスキップせずにメールを配信するには、明示的なdeliver()アクションを設定しないでください（暗黙的な配信が適用されます）。
オープン リレーの防止
症状/影響
- サードパーティのリレーテストでは、不正な形式または危険な受信者アドレスがアプライアンスで受け入れられることが報告されています。
- SMTPアドレス解析では、オープンリレーの検証によく使用されるパターンが許可されるため、パブリックブロックリストにsendingIPPがリストされます。
原因
- Simple Mail Transfer Protocol(SMTP)のSMTPアドレス解析と文字処理によって、ドメイン名の代わりにアドレスに直接書き込まれるIPアドレスである無効なアドレス形式（たとえば、二重の@記号）またはアドレスリテラルが許可されます。
解決策
一部のサービスは、Message Transfer Agent（MTA；メッセージ転送エージェント）が、オープンリレー状態を示す可能性がある不正なアドレスを受け入れるかどうかをテストします。ESAがSMTPカンバセーション中にこれらのアドレスを拒否するように、厳密な解析および拒否の動作を設定します。
- レポート用のALLOWLISTの前に、リレーテストの送信元の専用HAT送信者グループを追加します。必要に応じて、スパム対策とウイルス対策を有効にしたまま、レート制限やディレクトリ獲得攻撃防御(DHAP)を設定しないでください。
- アドレス内での二重の@記号を防ぐには、厳密なアドレス解析（Looseはデフォルト）を有効にします。
- 不正なアドレスが受け入れられるのを防ぐために、無効な文字を拒否（削除しない）します。
- アドレスリテラルを拒否（受け付けない）し、次の文字を入力します： *%!\\/?
確認
- 外部リレーテストを実行し、SMTPカンバセーション中にESAが不正な受信者アドレスを拒否することを確認します。
- メッセージトラッキングを使用して、リレーテストの送信者グループが一致していること、および目的のスキャン設定でメールが処理されていることを確認します。
関連情報
- テクニカルサポートとドキュメントの入手
- ReviewAsyncOSS forESAユーザガイド
- Eメールセキュリティアプライアンス(ESA)のインストールおよび設定ガイド（HAT、メールポリシー、およびメッセージフィルタ）
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
3.0 |
01-Sep-2026
|
再認定 |
1.0 |
13-Oct-2014
|
初版 |
フィードバック