バウンス検証と宛先制御のベストプラクティスガイド

はじめに

大量のメール配信が制御できなければ、受信者のドメインが圧迫される可能性があります。AsyncOSでは、Eメールセキュリティサービスで開く接続数、または各宛先ドメインに送信するメッセージ数を定義することで、メッセージ配信を完全に制御できます。

このドキュメントでは、次の内容について説明します。

1. バウンス攻撃から組織を保護するためのバウンス検証の設定
2. 宛先制御テーブルを使用した適切なネイバーポリシーの実行
3. SMTP DNSベースの名前付きエンティティ認証(DANE)を展開して、メッセージを安全に配信する

バウンス検証

バウンス検証を有効にすると、バックスキャッタ/バウンス攻撃に効果的に対処できます。 バウンス検証の背後にある概念はシンプルです。最初に、メッセージをマークアップして ESA.すべてのバウンスメッセージでそのマークアップを探します。マークアップが存在する場合は、 これは、環境内で発信されたメッセージのバウンスです。マークアップが見つからない場合、 バウンスは不正であり、拒否または廃棄される可能性があります。

たとえば、MAIL FROM: joe@example.com メール送信者： prvs=joe=123ABCDEFG@example.com.この例では、123...という文字列がバウンスです esaアプライアンスによって送信されたときにエンベロープ送信者に追加される検証タグ。もし メッセージがバウンスすると、バウンスされたメッセージのエンベロープ受信者アドレスには次のものが含まれます バウンス検証タグ：ESAに正規のバウンスであることを通知します。 メッセージに応答します。

デフォルトではシステム全体でバウンス検証タギングを有効または無効にできます。次のことが可能です また、特定のドメインに対するバウンス検証タギングを有効または無効にします。ほとんどの デフォルトでは、すべてのドメインで有効になっています。

ESA の設定

• Mail Policies > Bounce Verificationに移動し、New Keyをクリックします

• 任意のテキストを入力して、アドレスタグの符号化と復号化のキーとして使用します。たとえば、「Cisco_key」と入力します。

• Submitをクリックし、新しいアドレスタギングキーを確認します

次に、「デフォルト」ドメインのバウンス検証を有効にします。

• Mail Policies > Destination Controlsの順に移動し、Defaultをクリックします。
• バウンス検証の設定：アドレスタギングの実行：あり

宛先制御テーブルの使用

制御されない電子メール配信は、受信者ドメインを圧迫する可能性があります。ESAでは、次の項目を完全に制御できます アプライアンスが開く接続の数または アプライアンスが各宛先ドメインに送信するメッセージ。 宛先制御テーブルには、ESAが接続を確立したときの接続レートとメッセージレートの設定が リモート接続先への配信また、これらの宛先に対してTLSの使用を試行または強制するための設定も提供します。ESAは、宛先制御テーブルのデフォルト設定で設定されます。

このドキュメントでは、デフォルトが適さない宛先に対する制御を管理および設定する方法について説明します。たとえば、Googleには、Gmailユーザーが従うべき一連の受信ルールがあります。そうでないと、SMTP 4XX応答コードと、送信が速すぎるというメッセージを返信したり、受信者のメールボックスが容量制限を超えたりするおそれがあります。Gmailドメインを宛先制御テーブルに追加し、以下のGmail受信者に送信するメッセージの量を制限します。

宛先制御テーブルへの新しいドメインの追加

前述のように、GoogleにはGmailに送信する送信者に関する制限があります。受信制限は、https://support.google.com/a/answer/1366776?hl=enに掲載されているGmail送信者の制限を参照して確認できます。

Gmailの宛先ドメインを、優れたネイバーポリシーの例として設定してみましょう。

• Mail Policies > Destination Controlsの順に移動し、Add Destinationをクリックし、次のパラメータを使用して新しいプロファイルを作成します。
  1. 宛先:gmail.com
  2. IPアドレスプリファレンス：IPv4を優先
  3. 同時接続：最大20
  4. 接続あたりの最大メッセージ数：5
  5. 受信者：1分あたり最大180人
  6. バウンス検証：アドレスタギングの実行：デフォルト(Yes)

• [Submit] をクリックし、変更を確定します。 ドメインを追加した後の宛先制御テーブルは次のようになります。

次の図の「宛先制限」と「バウンス検証」の変更に注意してください。

名前付きエンティティのSMTP DNSベース認証の展開(DANE)

SMTPのDNSベースの名前付きエンティティ認証(DANE)プロトコルは、DNSサーバー上で構成されたドメインネームシステムセキュリティ(DNSSEC)拡張とDNSリソースレコード（TLSAレコードとも呼ばれる）を使用して、DNS名を持つX.509証明書を検証します。

TLSAレコードは、認証局(CA)、エンドエンティティ証明書、またはRFC 6698で説明されているDNS名に使用されるトラストアンカーのいずれかの詳細を含む証明書に追加されます。ドメインネームシステムセキュリティ(DNSSEC)拡張は、DNSセキュリティの脆弱性に対処することで、DNSのセキュリティを強化します。暗号キーとデジタル署名を使用したDNSSECにより、ルックアップデータが正しく、正当なサーバに接続されます。

発信TLS接続にSMTP DANEを使用する利点は次のとおりです。

• 中間者(MITM)ダウングレード攻撃、盗聴、およびDNSキャッシュポイズニング攻撃を防ぐことで、メッセージの安全な配信を実現します。
• DNSSECによって保護されている場合、TLS証明書とDNS情報の信頼性を提供します。

ESA の設定

ESAでDANEの設定を開始する前に、エンベロープ送信者とTLSAリソースレコードがDNSSECで検証され、受信側ドメインがDANEで保護されていることを確認してください。これは、ESAでCLIコマンドdaneverifyを使用して行うことができます。

• Mail Policies > Destination Controlsの順に移動し、Add Destinationをクリックし、次のパラメータを使用して新しいプロファイルを作成します。
  1. 宛先：dane_protected.com
  2. TLSサポート：推奨
  3. DANEサポート：機会

• [Submit] をクリックし、変更を確定します。