Cisco IronPort AsyncOS 7.3 for Email コンフィギュレーション ガイド

エンタープライズ ゲートウェイ構成

この構成では、エンタープライズ ゲートウェイ構成はインターネットからの電子メールを許可し、ゲートウェイ サーバ、POP/IMAP サーバ、またはその他の MTA に電子メールを中継します。エンタープライズ ゲートウェイは、それと同時に、グループウェア サーバおよびその他の電子メール サーバからの SMTP メッセージを受け付け、インターネット上の受信者に中継します。

図 5-2 エンタープライズ ゲートウェイとしての IronPort アプライアンスの使用

この構成では、少なくとも次の 2 つのリスナーが必要です。

• インターネット から のメールを受け付けるために専用に設定されたリスナー

• 内部のグループウェアおよび電子メール サーバ（POP/IMAP） から のメールを受け付けるために専用に設定されたリスナー

パブリック リスナーとプライベート リスナー

最初のリスナーを「パブリック リスナー」、2 番めのリスナーを「プライベート リスナー」と考えます。IronPort AsyncOS は、デフォルトでインターネットから電子メールを受信する特性を持つパブリック リスナーと、内部（グループウェア、POP/IMAP などのメッセージ生成）システムからだけの電子メールの受け入れを目的としたプライベート リスナーを区別します。パブリック リスナーとプライベート リスナーは、デフォルトでは、利用できる機能やデフォルト設定が異なっています。異なるパブリック ネットワークとプライベート ネットワーク用に個別のパブリック リスナーとプライベート リスナーを作成することで、セキュリティ、ポリシー強制、レポーティング、管理用に電子メールを区別できます。たとえば、パブリック リスナーで受信した電子メールは、デフォルトでは設定されたアンチスパム エンジンとアンチウイルス スキャン エンジンでスキャンされますが、プライベート リスナーで受信した電子メールはスキャンされません。リスナーがある同じ図を図 3-3 に示します。

図 5-3 エンタープライズ ゲートウェイ用のパブリックおよびプライベート リスナー

図 3-3 で、1 つのパブリック リスナー（A）と 1 つのプライベート リスナー（B）が、このエンタープライズ ゲートウェイ構成のアプライアンス上で構成されています。

さらに図 3-4 は、パブリック リスナーとプライベート リスナーのデフォルト設定の違いを示しています。パブリック リスナーは、インターネットからの電子メールを受信することを意図しています。パブリック リスナーは 多数の ホストからの接続を受信し、 限られた 数の受信者にメッセージを渡します。これとは逆に、プライベート リスナーは、内部ネットワークからの電子メールを受信することを意図しています。プライベート リスナーは限られた（既知の）数のホストからの接続を受信し、メッセージを 多数の 受信者に渡します。

C150/160 カスタマー：System Setup Wizard では、デフォルトで、インターネットからの電子メールの受信と内部ネットワークからの電子メールの中継の両方を行うための、1 つのパブリック リスナーを順を追って設定します。つまり、1 つのリスナーが両方の機能を実行できます。

それぞれの種類のリスナーの、ホスト アクセス テーブルと受信者アクセス テーブルでの違いについては後述します。

図 5-4 パブリック リスナーとプライベート リスナー

図 5-5 に、IronPort X1000/1050/1060, C60/600/650/660、および C30/300/350/360 アプライアンス上で System Setup Wizard（または CLI の systemsetup コマンド）によって作成される一般的な電子メール ゲートウェイ構成を示します。2 つのリスナーが作成されます。あるインターフェイス上でインバウンド接続を使用可能にするためのパブリック リスナーと、別の IP インターフェイス上でアウトバウンド接続を使用可能にするためのプライベート リスナーです。

図 5-6 に、IronPort C150/160 アプライアンス上で System Setup Wizard（または CLI の systemsetup コマンド）によって作成される一般的な電子メール ゲートウェイ構成を示します。1 つの IP インターフェイス上の 1 つのパブリック リスナーが、インバウンド接続とアウトバウンド接続の両方を使用可能にするために作成されます。

図 5-5 X1000/1050/1060、C60/600/650/660、C30/300/350/360 アプライアンス上のパブリック リスナーとプライベート リスナー

図 5-6 C150 アプライアンス上のパブリック リスナー

デフォルト HAT エントリ

作成するすべてのパブリック リスナーについて、デフォルトでは、 すべての ホストからの電子メールを 許可する ように HAT が設定されます。作成するすべてのプライベート リスナーについて、デフォルトでは、 指定したホストからの電子メールを中継し、その他 すべての ホストを拒否するように HAT が設定されます。

（注） 指定したホスト以外のすべてのホストを拒否することで、listenerconfig コマンドと systemsetup コマンドでは、意図せずシステムを「オープン リレー」として設定することが防止されます。オープン リレー（「セキュアでないリレー」または「サード パーティ」リレーとも呼びます）は、第三者による電子メール メッセージのリレーを許す SMTP 電子メール サーバです。オープン リレーがあると、ローカル ユーザ向けでもローカル ユーザからでもない電子メールを処理することにより、非良心的な送信者がゲートウェイを通じて大量のスパムを送信することが可能になります。

メール フロー ポリシー：アクセス ルールとパラメータ

HAT のメール フロー ポリシーを使用すると、リスナーがリモート ホストからメールを受信する速度を制御または制限できます。また、SMTP カンバセーションの間でやりとりされる SMTP コードと応答も変更できます。

HAT には、リモート ホストからの接続に作用する次の 4 つの基本的なアクセス ルールがあります。

ステップ 1 ACCEPT

接続が許可された後、電子メールの許可がさらに受信者アクセス テーブル（パブリック リスナーの場合）などのリスナーの設定によって制限されます。

ステップ 2 REJECT

接続は最初に許可されますが、接続しようとしているクライアントに 4XX または 5XX のグリーティングが送信されます。電子メールは許可されません。

（注） SMTP カンバセーションの開始時ではなく、メッセージ受信レベル（RCPT TO）でこの拒否を実行するように AsyncOS を設定することもできます。この方法でメッセージを拒否することで、メッセージの拒否が遅延されメッセージがバウンスするため、AsyncOS は拒否されたメッセージに関するより詳細な情報を取得できます。この設定は、CLI の listenerconfig --> setup コマンドで設定します。詳細については、『Cisco IronPort AsyncOS for Email Advanced Configuration Guide』の「Customizing Listeners」を参照してください。

ステップ 3 TCPREFUSE

接続は TCP レベルで拒否されます。

ステップ 4 RELAY

接続は受け付けられます。すべての受信者について受信が許可され、受信者アクセス テーブルで制約されません。

• CONTINUE

HAT 内のマッピングが無視され、HAT の処理が継続されます。着信接続が、CONTINUE でない後続のエントリに一致する場合、代わりにそのエントリが使用されます。CONTINUE ルールは、Graphical User Interface（GUI; グラフィカル ユーザ インターフェイス）で HAT を容易に編集できるようにするために使用します。詳細については、「新しい送信者グループの追加」を参照してください。

これらの基本的なアクセス コントロール パラメータに加え、作成するリスナーで次のパラメータを使用できます。アクセス ルール（ACCEPT または REJECT）と組み合わされたパラメータは、 メール フロー ポリシー と呼ばれます。メール フロー ポリシーは、HAT パラメータのグループ（アクセス ルールの後に、接続パラメータ、レート制限パラメータ、カスタム SMTP コードと応答、およびアンチスパム、アンチウイルス、暗号化、認証パラメータを続けたもの）を表現するための 1 つの方法です。

その後メール フロー ポリシーは、リスナーの HAT 内のエントリとして送信者グループにマップされます。

デフォルトでは、これらのパラメータは、アプライアンス上の各リスナーについて、 表 5-5 および 表 5-6 に示すデフォルト値に設定されます。

（注） アンチスパムまたはアンチウイルス スキャンが HAT でグローバルにイネーブルになっている場合、メッセージが IronPort アプライアンスによって許可されるときに、アンチスパムまたはアンチウイルス スキャン用にフラグ設定されます。メッセージを許可した後にアンチスパムまたはアンチウイルス スキャンがディセーブルにされた場合、メッセージは、ワーク キューを出るときに引き続きスキャン対象になります。

HAT 変数の構文

表 5-4 では、メール フロー ポリシーに対して定義されるカスタム SMTP およびレート制限バナーと組み合わせることでも使用できる変数のセットを定義します。変数名の大文字と小文字は区別されません（つまり、 $group と $Group は同じです）。

HAT 変数の使用

（注） これらの変数は、『Cisco IronPort AsyncOS for Email Advanced Configuration Guide』の「Customizing Listeners」の章の表 1-3 に示されている高度な HAT パラメータ smtp_banner_text および max_rcpts_per_hour_text とともに使用できます。

これらの変数を使用し、$TRUSTED ポリシー内で許可された接続のカスタム SMTP バナー応答テキストを GUI で編集できます。

図 5-7 HAT 変数の使用

または、CLI で次のように入力します。

HAT 変数のテスト

これらの変数をテストするには、既知の信頼できるマシンの IP アドレスを、IronPort アプライアンス上のリスナーの $WHITELIST 送信者グループに追加します。その後、そのマシンから telnet で接続します。SMTP 応答中で変数の置き換えを確認できます。次の例を参考にしてください。

デフォルト メール フロー ポリシーの参照

図 5-8 に、パブリック リスナーのデフォルト ポリシー パラメータを示します。

リスナーのデフォルト ポリシー パラメータを表示するには、次の手順を実行します。

ステップ 1 GUI にアクセスします（「GUI へのアクセス」を参照）。

ステップ 2 [Mail Policies] > [Mail Flow Policies] の順にクリックします。

[Mail Flow Policies] ページが表示されます。リスナーが設定されている場合、アルファベット順で最初のリスナーに対して定義されているメール フロー ポリシーが表示されます。

図 5-8 [Mail Flow Policies] ページ

ステップ 3 [Default Policy Parameters] リンクをクリックします。

[Default Policy Parameters] ページが表示されます。図 5-9を参照してください。

図 5-9 パブリック リスナーのデフォルト ポリシー パラメータ（1/2）

図 5-10 パブリック リスナーのデフォルト ポリシー パラメータ（2/2）

リスナーのデフォルト ポリシー パラメータ

次の表に、パブリック リスナーのデフォルト パラメータの一覧を示します。

次の表に、プライベート リスナーのデフォルト パラメータの一覧を示します。

送信者グループ

HAT パラメータをアクセス ルールと組み合わせることで、メール フロー ポリシーが作成されます（「メール フロー ポリシー：アクセス ルールとパラメータ」 を参照）。異なる HAT パラメータをグループ化して名前を割り当てると、送信者のグループに適用できるメール フロー ポリシーが定義されます。

送信者グループ は、単に、複数の送信者からの電子メールを同じ方法で扱う（つまり、送信者のグループにメール フロー ポリシーを適用する）ために集められた送信者のリストです。送信者グループは、次のもので識別される送信者のリストです。

• IP アドレス

• IP 範囲

• 具体的なホスト名またはドメイン名

• SenderBase 評価サービスの「組織」分類

• SenderBase Reputation Score（SBRS; SenderBase 評価スコア）の範囲（またはスコアの欠如）

• DNS リスト クエリー応答

送信者グループを構成するリモート ホスト（送信者エントリ）を定義するための構文については、 表 5-7 を参照してください。これらの送信者エントリは、リスナーの HAT 内でカンマで区切られます。メール フロー ポリシーと同様に、送信者グループに名前を割り当てます。

送信者グループおよびメール フロー ポリシーは合わせて、リスナーの HAT で定義されます。IronPort アプライアンスでは、デフォルトで、「パブリック リスナー向けの定義済みのメール フロー ポリシー」に示すメール フロー ポリシーと送信者グループがあらかじめ定義されています。

では、定義済みの送信者グループとメール フロー ポリシーを使用して、ゲートウェイを通過するメールをすばやく高性能に分類し、リスナーの HAT に対するリアルタイムな変更を行うことができます。

（注） 二重 DNS ルックアップを実行することで、システムはリモート ホストの IP アドレスの正当性を確保および検証します。これは、接続元ホストの IP アドレスに対する逆引き DNS（PTR）ルックアップと、それに続く PTR ルックアップ結果に対する正引き DNS（A）ルックアップからなります。その後、システムは A ルックアップの結果が PTR ルックアップの結果と一致するかどうかをチェックします。結果が一致しない場合、または A レコードが存在しない場合は、システムは IP アドレスのみを使用して HAT 内のエントリと照合します。

送信者グループの構文

ネットワーク オーナー、ドメイン、IP アドレスで定義される送信者グループ

SMTP プロトコルには電子メールの送信者を認証するための方法が組み込まれていないため、大量の迷惑メールの送信者は、その身元を隠すためのいくつかの戦略を採用することに成功してきました。たとえば、メッセージのエンベロープ送信者アドレスのスプーフィング、偽造した HELO アドレスの使用、単なる異なるドメイン名のローテーションなどがあります。これにより、多数のメール管理者は、「この大量の電子メールは誰が送信しているのか」という基本的な質問を自問することになります。この質問に答えるために、SenderBase 評価サービスは、接続元ホストの IP アドレスに基づいて身元ベースの情報を集約するための固有の階層を開発してきました。IP アドレスは、メッセージ中で偽造することがほとんど不可能な情報の 1 つです。

IP Address は、送信元メール ホストの IP アドレスとして定義します。

Domain は、指定した第 2 レベル ドメイン名（たとえば yahoo.com）を持つホスト名を使用するエンティティとして定義され、IP アドレスに対する逆引き（PTR）ルックアップによって決定されます。

Network Owner は、IP アドレスのブロックを管理するエンティティ（通常は会社）として定義され、American Registry for Internet Numbers（ARIN）などのグローバル レジストリやその他のソースからの IP アドレス空間の割り当てに基づいて決定されます。

Organization は、ネットワーク オーナーの IP ブロック内のメール ゲートウェイの特定のグループを最も詳細に管理するエンティティとして定義され、SenderBase によって決定されます。Organization は Network Owner、Network Owner 内の部門、その Network Owner の顧客のいずれかになります。

HAT に基づくポリシーの設定

表 5-8 に、ネットワーク オーナーと組織の例をいくつか示します。

ネットワーク オーナーの規模にはかなりの幅があるため、メール フロー ポリシーの基にする適切なエンティティは組織です。SenderBase 評価サービスは、電子メールの送信元について組織レベルまで独自に理解しており、IronPort アプライアンスはそれを利用して、組織に基づいてポリシーを自動的に適用します。上の例で、ユーザが Host Access Table（HAT; ホスト アクセス テーブル）で「Level 3 Communications」を送信者グループとして指定した場合、SenderBase はそのネットワーク オーナーによって管理される個別の組織に基づいてポリシーを適用します。

たとえば、上記の表 3-7 で、ユーザが Level 3 に対して時間あたりの受信者数の制限を 10 と入力した場合、IronPort アプライアンスは、Macromedia Inc.、Alloutdeals.com、 および Greatoffers.com に対して最大 10 個の受信者を許可します（Level 3 ネットワーク オーナーに対しては時間あたり合計 30 個の受信者になります）。このアプローチの利点は、これらの組織のいずれかがスパムを送信し始めても、Level 3 によって管理されているその他の組織には影響がないことです。これを、ネットワーク オーナー「The Motley Fool」の例と対比します。ユーザがレート制限を時間あたり 10 個の受信者に設定した場合、ネットワーク オーナー Motley Fool の合計の制限は、時間あたり 10 個の受信者になります。

IronPort メール フロー モニタ機能は、送信者を定義する方法の 1 つであり、送信者に関するメール フロー ポリシーの決定を作成するためのモニタリング ツールとなります。特定の送信者に関するメール フロー ポリシーの決定を作成するには、次のことを質問します。

ステップ 1 この送信者によって、どの IP アドレスが制御されているか。

インバウンド電子メールの処理を制御するためのメール フロー モニタ機能が使用する最初の情報が、この質問に対する答えになります。この答えは、SenderBase 評価サービスにクエリーを実行することで得られます。SenderBase 評価サービスは、送信者の相対的な規模に関する情報を提供します（SenderBase ネットワーク オーナーまたは SenderBase 組織）。この質問に答えるにあたり、次のことが仮定されます。

– 大規模な組織は、より多くの IP アドレスを管理し、より厳格な電子メールを送信する傾向があります。

ステップ 2 その規模に応じて、この送信者に接続数を全体でいくつ割り当てるべきか。

– 大規模な組織は、より多くの IP アドレスを管理し、より厳格な電子メールを送信する傾向があります。そのため、アプライアンスへの接続をより多く割り当てる必要があります。

– 多くの場合、大量の電子メールの送信元は、ISP、NSP、アウトソーシングされた電子メールの配信を管理する企業、迷惑メールの送信元です。ISP、NSP、アウトソーシングされた電子メールの配信を管理する企業は、多数の IP アドレスを管理する組織の例であり、アプライアンスへの接続をより多く割り当てる必要があります。通常、迷惑メールの送信者は、多数の IP アドレスを管理せず、少数の IP アドレスを通じて大量のメールを送信します。このような送信者には、アプライアンスへの接続をより少なく割り当てる必要があります。

メール フロー モニタ機能は、SenderBase ネットワーク オーナーと SenderBase 組織の差別化を使用して、SenderBase 内のロジックに基づき、送信者あたりに接続を割り当てる方法を決定します。メール フロー モニタ機能の使用方法の詳細については、『 Cisco IronPort AsyncOS for Email Daily Management Guide 』の「Using Email Security Monitor」の章を参照してください。

SenderBase 評価スコアによって定義された送信者グループ

IronPort アプライアンスは、SenderBase 評価サービスに対してクエリーを実行して、送信者の評価スコア（SBRS）を特定できます。SBRS は、SenderBase 評価サービスからの情報に基づき、IP アドレス、ドメイン、または組織に割り当てられた数値です。スコアの範囲は、 表 5-9 に示すように、-10.0～+10.0 です。

SBRS を使用して、信頼性に基づいてメール フロー ポリシーを送信者に適用するように IronPort アプライアンスを設定します。たとえば、スコアが -7.5 未満のすべての送信者を拒否することが考えられます。これは、GUI を使用して実現するのが最も簡単です。「SenderBase 評価スコアを使用した送信者グループの作成」を参照してください。エクスポートした HAT をテキスト ファイルで編集する場合、SenderBase 評価スコアを含めるための構文については 表 5-10 を参照してください。『 Cisco IronPort AsyncOS for Email Advanced Configuration Guide 』の「Customizing Listeners」を参照してください。

（注） GUI を通じて HAT に追加されるネットワーク オーナーは、SBO:n という構文を使用します。ここで n は、SenderBase 評価サービス内のネットワーク オーナーの一意の識別番号です。

SenderBase 評価サービスにクエリーを実行するようにリスナーを設定するには、[Network] > [Listeners] ページを使用するか、CLI で listenerconfig -> setup コマンドを使用します。また、アプライアンスが SenderBase 評価サービスにクエリーを実行するときに待つタイムアウト値を定義することもできます。その後、GUI の [Mail Policies] ページの値を使用するか、CLI の listenerconfig -> edit -> hostaccess コマンドを使用して、SenderBase 評価サービスに対するルックアップを使用するさまざまなポリシーを設定できます。

（注） また、SenderBase 評価スコアの「しきい値」を指定するメッセージ フィルタを作成し、システムによって処理されたメッセージをさらに操作することもできます。詳細については、『Cisco IronPort AsyncOS for Email Advanced Configuration Guide』の「SenderBase Reputation Rule」、「Bypass Anti-Spam System Action」、および「Bypass Anti-Virus System Action」を参照してください。

HAT 内の DNS リストにクエリーを実行することで定義された送信者グループ

リスナーの HAT では、特定の DNS リスト サーバに対するクエリーに一致するものとして送信者グループを定義することもできます。クエリーは、リモート クライアントの接続時に DNS を通じて実行されます。リモート リストにクエリーを実行する機能は、現在メッセージ フィルタ ルールとしても存在しますが（『 Cisco IronPort AsyncOS for Email Advanced Configuration Guide 』の「DNS List Rule」を参照）、メッセージの内容全体が受信されるのは一度だけです。

このメカニズムにより、グループ内で、DNS リストにクエリーを実行する送信者を設定し、それに応じてメール フロー ポリシーを調整できます。たとえば、接続を拒否したり、接続元ドメインの振る舞いを制限したりできます。

（注） いくつかの DNS リストは、可変の応答（たとえば「127.0.0.1」、「127.0.0.2」、「127.0.0.3」）を使用して、クエリー対象の IP アドレスに関するさまざまな事実を示すことができます。メッセージ フィルタ DNS リスト ルール（『Cisco IronPort AsyncOS for Email Advanced Configuration Guide』の「DNS List Rule」を参照）を使用すると、クエリーの結果をさまざまな値と比較できます。しかし、HAT 内で DNS リスト サーバにクエリーを実行する指定では、簡潔にするためにブール演算のみがサポートされています（つまり、IP アドレスがリストに現れるかどうか）。

（注） CLI のクエリーでは必ず角カッコを含めます。GUI で DNS リスト クエリーを指定する場合には角カッコは不要です。クエリーのテスト、DNS クエリーの一般的な設定、または現在の DNS リスト キャッシュのフラッシュを行うには、CLI で dnslistconfig コマンドを使用します。

このメカニズムは、「異常な」接続に加えて、「正常な」接続を識別するためにも使用できます。たとえば、query.bondedsender.org に対してクエリーを実行すると、その電子メール キャンペーンの健全性を保証するために IronPort Systems 社の Bonded Sender™ プログラムに供託金を積んだ接続元ホストが照合されます。デフォルトの WHITELIST の送信者グループを修正して Bonded Sender プログラムの DNS サーバにクエリーを実行し（積極的に供託金を拠出したこれら正規の電子メール送信者が一覧表示されます）、それに応じてメール フロー ポリシーを調整することもできます。

パブリック リスナー向けの定義済みのメール フロー ポリシー

アクセス ルール（ACCEPT または REJECT）と組み合わせた場合、表 5-3 に示すパラメータが、作成する各 パブリック リスナーの次の 4 つのメール フロー ポリシーとして事前に定義されています。

• $ACCEPTED

• $BLOCKED

• $THROTTLED

• $TRUSTED

リスナーの定義済みのメール フロー ポリシーにアクセスするには、次の手順を実行します。

ステップ 1 GUI にアクセスします（「GUI へのアクセス」を参照）。

ステップ 2 [Mail Policies] > [HAT Overview] の順にクリックします。

[Overview] ページが表示されます。リスナーが設定されている場合、アルファベット順で最初のリスナーに対して定義されている [Host Access Table overview] ページが表示されます。[Listener] リストから目的のリスナーを選択します。

図 5-11 パブリック リスナー向けの定義済みのメール フロー ポリシー

ステップ 3 メール フロー ポリシーの名前をクリックして、そのポリシーの接続動作とパラメータを表示します。

（注） デフォルトでは、C150/160 のユーザは、systemsetup コマンドの実行中に 1 つのパブリック リスナーのみを作成するように求められます。IronPort C150/160 アプライアンスで作成されたパブリック リスナーにも、内部システム用にメールを中継するために使用されるメール フロー ポリシー $RELAYED が含まれています（図 5-12 を参照）。詳細については、「RELAYLIST」を参照してください。$RELAYLIST ポリシーは、IronPort X1050/1060/1070、C650/660/670、および C350/360/370 アプライアンス上のプライベート リスナーのみで表示されます。

図 5-12 単一リスナー向けの定義済みのメール フロー ポリシー

この表で、「デフォルト」は、リスナーで定義されているデフォルト値が使用されることを意味します。

* イネーブルな場合

$ACCEPTED は名前付きポリシーであり、パブリック リスナーのデフォルトの HAT 設定と同じです。$ACCEPTED ポリシーは作成するどの送信者グループにも割り当てることができます（「新しい送信者グループの追加」および「[Connections]」を参照してください。また、「HAT の操作」も参照してください）。

パブリック リスナー用の HAT 内の最後の ALL エントリも、主な動作として $ACCEPTED ポリシーを使用します。

各パブリック リスナーには、 表 5-12 に示す送信者グループと対応するメール フロー ポリシーがデフォルトで定義されています。

これら 4 つの基本的な送信者グループとメール フロー ポリシーを使用することで、パブリック リスナー上でゲートウェイに流れ込む電子メールの分類を開始するためのフレームワークが得られます。『 Cisco IronPort AsyncOS for Email Daily Management Guide 』の「Using Email Security Monitor」では、ゲートウェイに流れ込む電子メールのリアルタイム フローを確認し、リスナーの HAT をリアルタイムで変更できます（IP アドレス、ドメイン、または組織の既存の送信者グループへの追加、既存のポリシーまたは定義済みのポリシーの編集、新しいメール フロー ポリシーの作成）を行うことができます。

WHITELIST

信頼する送信者を WHITELIST の送信者グループに追加します。メール フロー ポリシー $TRUSTED は、信頼できる送信者からの電子メールのレート制限をイネーブルにせず、それらの送信者からの内容をアンチスパムまたはアンチウイルス ソフトウェアでスキャンしない場合に設定します。

BLACKLIST

BLACKLIST 送信者グループ内の送信者は拒否されます（メール フロー ポリシー $BLOCKED で設定されたパラメータにより）。このグループに送信者を追加すると、SMTP HELO コマンドで 5XX SMTP 応答が返され、それらのホストからの接続が拒否されます。

SUSPECTLIST

送信者グループ SUSPECTLIST には、着信メールの速度をスロットリングする（低下させる）メール フロー ポリシーが含まれています。送信者が疑わしい場合、送信者グループ SUSPECTLIST に追加することで、メール フロー ポリシーにより次のことが指示されます。

• レート制限により、セッションあたりの最大メッセージ数、メッセージあたりの最大受信者数、最大メッセージ サイズ、リモート ホストから受け付ける最大同時接続数が制限されます。

• リモート ホストからの時間あたりの最大受信者数は 20 に設定されます。この設定は、使用可能な最大のスロットリングであることに注意してください。このパラメータが厳しすぎる場合は、時間あたりの受信者数を増やすことができます。

• メッセージの内容はアンチスパム スキャン エンジンとアンチウイルス スキャン エンジンによってスキャンされます（これらの機能がシステムでイネーブルになっている場合）。

• 送信者に関する詳細情報を得るために、IronPort SenderBase 評価サービスに対してクエリーが実行されます。

UNKNOWNLIST

送信者グループ UNKNOWNLIST は、特定の送信者に対して使用するメール フロー ポリシーが決まっていない場合に便利です。このグループのメール フロー ポリシーでは、このグループの送信者についてメールが許可されますが、IronPort Anti-Spam ソフトウェア（システムでイネーブルになっている場合）、アンチウイルス スキャン エンジン、および IronPort SenderBase 評価サービスをすべて使用して、送信者とメッセージの内容に関する詳細情報を取得することが指示されます。このグループに属する送信者に対するレート制限もデフォルト値を使用してイネーブルになります。ウイルス スキャン エンジンの詳細については、「アンチウイルス スキャン」を参照してください。SenderBase 評価サービスの詳細については、「評価フィルタリング」を参照してください。

プライベート リスナー用の定義済みのメール フロー ポリシー

表 5-3 に定義されているパラメータを、アクセス ルール（RELAY または REJECT）と組み合わせた場合、作成する各 プライベート リスナーの次の 2 つのメール フロー ポリシーとして事前に定義されます。

• $RELAYED

• $BLOCKED

これらのポリシーの要約を 表 5-13 に示します。

図 5-13 プライベート リスナー用の定義済みのメール フロー ポリシー

$BLOCKED は名前付きポリシーであり、プライベート リスナーのデフォルトの HAT 設定と同じです。プライベート リスナー用の HAT 内の最後の ALL エントリも、デフォルトの動作として $BLOCKED ポリシーを使用します。

各プライベート リスナーには、 表 5-14 に示す送信者グループと対応するメール フロー ポリシーがデフォルトで定義されています。

この基本的な送信者グループとメール フロー ポリシーを使用することで、プライベート リスナー上でゲートウェイから出て行く電子メールの分類を開始するためのフレームワークが得られます。

RELAYLIST

中継を許可する必要があることがわかっている送信者を RELAYLIST 送信者グループに追加します。メール フロー ポリシー $RELAYED は、中継を許可する送信者からの電子メールのレート制限を行わず、それらの送信者からの内容をアンチスパム スキャン エンジンまたはアンチウイルス ソフトウェアでスキャンしない場合に設定します。

（注） GUI の System Setup Wizard（または CLI の systemsetup コマンド）でアウトバウンド（プライベート）リスナーを作成するときに、IronPort アプライアンスを通じた電子メールの中継を許可したシステムは、送信者グループ RELAYLIST に自動的に追加されます。を参照してください。

（注） デフォルトでは、C150/160 のユーザは、systemsetup コマンドの実行中に 1 つのパブリック リスナーのみを作成するように求められます。IronPort C150/160 アプライアンス上で作成されたパブリック リスナーにも、内部システム用にメールを中継するために使用されるメール フロー ポリシー $RELAYED が含まれます。

GUI による送信者グループとメール フロー ポリシーの管理

[Mail Policies] > [HAT Overview] ページと [Mail Flow Policy] ページでは、リスナーの HAT 設定を行うことができます。これらのページでは、次のことが可能です。

• 送信者グループからメール フロー ポリシーへのマッピングの参照

• 送信者グループの作成、編集、削除

• メール フロー ポリシーの作成、編集、削除

• リスナーの HAT エントリの順序変更

[Mail Policies] > [HAT Overview] リンクをクリックします。図 5-14を参照してください。[Listener:] ドロップダウン リストから設定するリスナーを選択します。

図 5-14 [Host Access Table Overview] ページ

[HAT Overview] ページでは、送信者グループの追加やリスナーのメール フロー ポリシーの編集を行うことができます。

新しい送信者グループの追加

新規送信者グループを追加するには、次の手順を実行します。

ステップ 1 [HAT Overview] ページで、[Add Sender Group] をクリックします。

図 5-15 [Add Sender Group] ページ

ステップ 2 各フィールドに、送信者グループの名前を入力し、送信者グループのリストに配置する順序を選択し、コメントを入力します（任意）。

ステップ 3 このグループに適用すべきメール フロー ポリシーがわからない場合（またはまだメール フロー ポリシーが存在しない場合）は、デフォルトの「CONTINUE (no policy)」メール フロー ポリシーを使用します。そうでない場合は、ドロップダウン リストからメール フロー ポリシーを選択します。

ステップ 4 SBRS の範囲と DNS リストを選択します（任意）。また、SBRS に情報がない送信者を含めるためのチェックボックスをオンにすることもできます。これは「none」と呼ばれ、一般に疑いがあることを意味します。

ステップ 5 ホストの DNS 検証の設定を行います（「送信者検証の実装 -- 設定例」を参照）。

ステップ 6 [Submit] をクリックして送信者グループを保存し [Host Access Table] ページに戻るか、[Submit and Add Senders] をクリックしてグループを作成し、送信者のグループへの追加を開始します。

ステップ 7 変更を確定します。

（注） 1 つの送信者グループに重複するエントリ（同じドメインまたは IP アドレス）を入力すると、重複は廃棄されます。

送信者グループの編集

送信者グループを編集するには、次の手順を実行します。

ステップ 1 [HAT Overview] ページで、既存の送信者グループの名前をクリックします。選択した送信者グループが表示されます。

図 5-16 [Sender Group Detail] ページ

ステップ 2 [Edit Settings] をクリックします。[Edit Sender Group] ページが表示されます。

図 5-17 [Edit Sender Group] ページ

ステップ 3 送信者グループを変更し、[Submit] をクリックします。

ステップ 4 変更を確定します。

送信者グループの削除

送信者グループを削除するには、次の手順を実行します。

ステップ 1 [HAT Overview] ページで、削除する送信者グループの [Delete] 列にあるゴミ箱のアイコンをクリックします。削除を確認するよう求められます。

ステップ 2 [Yes] をクリックして送信者グループを削除するか、[No] をクリックしてキャンセルします。

ステップ 3 変更を確定します。

新しいメール フロー ポリシーの追加

新しいメール フロー ポリシーを追加するには、次の手順を実行します。

ステップ 1 [Mail Policies] > [Mail Flow Policies] リンクをクリックします。[Mail Flow Policies] ページが表示されます。

ステップ 2 [Add Policy] をクリックします。[Mail Flow Policies Add Policy] ページが表示されます。

ステップ 3 メール フロー ポリシーの情報を入力します。

ステップ 4 エンベロープ送信者の DNS 検証を設定します（「送信者検証の実装 -- 設定例」を参照）。

ステップ 5 変更を送信して確定します。

（注） [Use Default] オプション ボタンがオンの場合、ポリシーのデフォルト値はグレー表示されます。デフォルト値を上書きするには、[On] オプション ボタンを選択して機能または設定をイネーブルにし、新たにアクセス可能になった値を変更します。

（注） [Custom SMTP Banner Text] および [Max. Recipients Per Hour] テキスト文字列フィールドは、「HAT 変数の構文」で説明した HAT 変数をサポートしています。

（注） 一部のパラメータは特定の事前設定値に依存します（たとえば、ディレクトリ獲得攻撃の設定を行うには、LDAP 許可クエリーを設定しておく必要があります）。

メール フロー ポリシーの編集

メール フロー ポリシーを編集するには、次の手順を実行します。

ステップ 1 [Mail Flow Policy overview] ページで、ポリシーの名前をクリックします。[Mail Flow Policy Edit Policy] ページが表示されます。

ステップ 2 ポリシーを変更します。

ステップ 3 変更を送信して確定します。

メール フロー ポリシーの削除

メール フロー ポリシーを削除するには、次の手順を実行します。

ステップ 1 削除するメール フロー ポリシーの [Delete] 列にあるゴミ箱のアイコンをクリックします。削除を確認するよう求められます。

ステップ 2 [Yes] をクリックしてメール フロー ポリシーを削除するか、[No] をクリックしてキャンセルします。

ステップ 3 変更を確定します。

送信者グループへの送信者の追加

既存の送信者グループに送信者を追加するには、次の手順を実行します。

ステップ 1 ドメイン、IP、またはネットワーク オーナー プロファイル ページで、[Add to Sender Group] リンクをクリックします。

図 5-18 [Profile] ページの [Add to Sender Group] リンク

[Add to Sender Group] ページが表示されます。図 5-19を参照してください。

図 5-19 [Add to Sender Group] ページ

ステップ 2 各リスナーに対して定義されているリストから送信者グループを選択します。

ステップ 3 [Submit] をクリックして選択した送信者グループにドメインを追加するか、[Cancel] をクリックします。

ステップ 4 変更を確定します。

（注） ドメインを送信者グループに追加すると、実際には 2 つのドメインが GUI に表示されます。たとえば、ドメイン example.net を追加した場合、[Add to Sender Group] ページには、example.net と .example.net が追加されます。2 つめのエントリがあることで、example.net のサブドメイン内のすべてのホストが送信者グループに追加されます。詳細については、「送信者グループの構文」を参照してください。

（注） 送信者グループに追加しようとしている送信者の 1 つ以上がその送信者グループにすでに存在する送信者と重複する場合、重複する送信者は追加されず、確認メッセージが表示されます。

ステップ 5 [Save] をクリックして送信者を追加し、[Incoming Mail Overview] ページに戻ります。

新しい送信者グループへの送信者の追加

新しい送信者グループに送信者を追加するには、次の手順を実行します。

ステップ 1 新しい送信者グループを作成する場合、[Submit and Add Senders] をクリックします。[Add Sender] ページが表示されます。

ステップ 2 送信者を入力します。

ステップ 3 オプションで送信者のコメントを入力します。

ステップ 4 [Submit] をクリックして送信者グループにドメインを追加するか、[Cancel] をクリックします。

ステップ 5 変更を確定します。

SenderBase 評価スコアを使用した送信者グループの作成

SenderBase 評価スコアに基づいて送信者グループを作成するには、次の手順を実行します。

ステップ 1 [HAT Overview] ページで [Add Sender Group] をクリックします。

ステップ 2 [Add Sender Group] ページで、送信者グループの名前とオプションのコメントを入力します。

ステップ 3 リストからメール フロー ポリシーを選択します。

ステップ 4 [Senders] セクションで、ドロップダウン リストから [SBRS] を選択し、[Add Sender] をクリックします。

ページがリフレッシュされます。

ステップ 5 SBRS の [from:] フィールドと [to:] フィールドに範囲を入力し、オプションのコメントを入力します。

図 5-20 で、SenderBase 評価スコアが -7.5 未満の送信者は、BLOCKED メール フロー ポリシーを使用してブロックされます。

図 5-20 SenderBase 評価スコアを使用した送信者グループの作成（1）

図 5-21 で、SenderBase 評価スコアが 8.0 を超えている送信者はリスナーのアンチスパム スキャンをバイパスします。

図 5-21 SenderBase 評価スコアを使用した送信者グループの作成（2）

（注） これらの同じパラメータを使用し、SenderBase 評価スコアに基づいて送信者を含めるように、TRUSTED および BLOCKED のデフォルト ポリシーを変更することもできます。詳細については、「SenderBase 評価フィルタの実装」を参照してください。

ステップ 6 [Submit] をクリックし、SenderBase 評価スコアに基づいて送信者グループを作成します。

ステップ 7 変更を確定します。

図 5-22 SenderBase 評価スコアを使用したホスト アクセス テーブル

HAT の順序変更

HAT 内のエントリの順序は重要です。リスナーに接続しようとする各ホストについて、HAT が上から下に向かって読み込まれることを思い出してください。接続元ホストにルールが一致する場合、その接続に対してすぐにアクションが実行されます。

たとえば、CIDR ブロックを送信者グループ A で指定し（ポリシー 1 を使用）、その CIDR ブロック内の IP アドレスに対して送信者グループ B を作成すると、送信者グループ B のポリシーは適用されません。

HAT 内のエントリの順序を編集するには、次の手順を実行します。

ステップ 1 [HAT Overview] ページで、[Edit Order] をクリックします。[Edit Sender Group Order] ページが表示されます。

ステップ 2 HAT の既存の行の新しい順序を入力します。

ステップ 3 変更を送信して確定します。

[HAT Overview] ページがリフレッシュされ、新しい順序で表示されます。

図 5-23 に示す次の例では、信頼できる送信者が最初に処理され、ブロックされる送信者が次に処理され、不明または疑いのある送信者が最後に処理されるように順序を変更しています。

図 5-23 HAT 内のエントリの順序の変更

送信者の検索

[HAT Overview] ページの上部にある [Find Senders] フィールドにテキストを入力することで送信者を検索できます。検索するテキストを入力し [Find] をクリックします。

HAT の操作

HAT のエクスポート

HAT をエクスポートするには、次の手順を実行します。

ステップ 1 [Export HAT] をクリックします。[Export Host Access Table] ページが表示されます。

図 5-25 HAT のエクスポート

ステップ 2 エクスポートする HAT のファイル名を入力します。これは、アプライアンスの設定ディレクトリに作成されるファイルの名前になります。

ステップ 3 変更を送信して確定します。

HAT のインポート

HAT をインポートすると、既存のすべての HAT エントリが現在の HAT から削除されます。

HAT をファイルからインポートするには、次の手順を実行します。

ステップ 1 [Import HAT] をクリックします。[Import Host Access Table] ページが表示されます。

図 5-26 HAT のインポート

ステップ 2 リストからファイルを選択します。

（注） インポートするファイルは、アプライアンスのコンフィギュレーション ディレクトリに存在する必要があります。

ステップ 3 [Submit] をクリックします。既存のすべての HAT エントリを削除することを確認する警告メッセージが表示されます。

ステップ 4 [Import] をクリックします。

ステップ 5 変更を確定します。

ファイルには「コメント」を格納できます。文字「#」で始まる行はコメントと見なされ、AsyncOS によって無視されます。次の例を参考にしてください。

送信者検証：ホスト

送信者が未検証となる理由にはさまざまなものがあります。たとえば、DNS サーバが「ダウン」または応答しないか、ドメインが存在しないことが考えられます。送信者グループのホスト DNS 検証設定では、SMTP カンバセーションの前に未検証の送信者を分類し、さまざまな種類の未検証の送信者をさまざまな送信者グループに含めることができます。

IronPort アプライアンスは、着信メールについて、DNS を通じて接続元ホストの送信元ドメインを検証しようとします。この検証は、SMTP カンバセーションの前に実行されます。システムは、 二重の DNS ルックアップ を実行することで、リモート ホストの IP アドレス（つまりドメイン）の有効性を取得および検証します。二重の DNS ルックアップは、接続元ホストの IP アドレスに対する逆引き DNS（PTR）ルックアップと、その後の PTR ルックアップの結果に対する正引き DNS（A）ルックアップからなります。その後、アプライアンスは A ルックアップの結果が PTR ルックアップの結果と一致するかどうかをチェックします。PTR ルックアップまたは A ルックアップが失敗するか、結果が一致しない場合、システムは IP アドレスのみを使用して HAT 内のエントリを照合し、送信者は未検証と見なされます。

未検証の送信者は次の 3 つのカテゴリに分類されます。

• 接続元ホストの PTR レコードが DNS に存在しない。

• DNS の一時的な障害により接続元ホストの PTR レコードのルックアップに失敗した。

• 接続元ホストの逆引き DNS ルックアップ（PTR）が正引き DNS ルックアップ（A）に一致しない。

送信者グループの [Connecting Host DNS Verification] 設定を使用して、未検証の送信者に対する動作を指定できます（「送信者グループ SUSPECTLIST に対するホスト送信者検証の実装」を参照）。

すべての送信者グループの送信者グループ設定でホスト DNS 検証をイネーブルにできますが、ホスト DNS 検証設定を送信者グループに追加するということは、そのグループに未検証の送信者を 含める ことになるという点に注意してください。つまり、スパムやその他の無用なメールが含まれることになります。そのため、これらの設定は、送信者を拒否またはスロットリングする送信者グループに対してのみイネーブルにすることを推奨します。たとえば、送信者グループ WHITELIST に対して DNS 検証をイネーブルにすると、未検証の送信者からのメールが、WHITELIST 内の信頼できる送信者からのメールと同じように扱われることを意味します（メール フロー ポリシーの設定内容に応じて、アンチスパムまたはアンチウイルス チェック、レート制限などのバイパスを含みます）。

送信者検証：エンベロープ送信者

エンベロープ送信者検証を使用すると、エンベロープ送信者のドメイン部分が DNS で検証されます（エンベロープ送信者のドメインが解決されるか。エンベロープ送信者のドメインの A レコードまたは MX レコードが DNS に存在するか）。タイムアウトや DNS サーバの障害など、DNS でのルックアップで一時的なエラー条件が発生した場合、ドメインは解決されません。これに対し、ドメインをルックアップしようとしたときに明確な「domain does not exist」ステータスが返された場合、ドメインは存在しません。この検証が SMTP カンバセーションの中で実行されるのに対し、ホスト DNS 検証はカンバセーションが開始される前に実行され、接続元 SMTP サーバの IP アドレスに適用されます。

詳細：AsyncOS は、送信者のアドレスのドメインに対して MX レコード クエリーを実行します。次に AsyncOS は、MX レコードのルックアップの結果に基づいて、A レコードのルックアップを行います。DNS サーバが「NXDOMAIN」（このドメインのレコードがない）を返した場合、AsyncOS はそのドメインが存在しないものとして扱います。これは「Envelope Senders whose domain does not exist」のカテゴリに分類されます。NXDOMAIN は、ルート ネーム サーバがこのドメインの権威ネームサーバを提供していないことを意味する場合があります。

しかし、DNS サーバが「SERVFAIL」を返した場合、「Envelope Senders whose domain does not resolve」として分類されます。SERVFAIL は、ドメインが存在するものの、DNS にレコードのルックアップで一時的な問題があることを意味します。

スパマーなどの不法なメール送信者が使用する一般的な手法は、MAIL FROM 情報（エンベロープ送信者内）を偽造し、受け付けられた未検証の送信者からのメールが処理されるようにすることです。これにより、MAIL FROM アドレスに送信されたバウンス メッセージが配信不能になるため、問題が生じる可能性があります。エンベロープ送信者検証を使用すると、不正な形式の（ただし空白ではない）MAIL FROM を拒否するように IronPort アプライアンスを設定できます。

各メール フロー ポリシーで、次のことが可能です。

• エンベロープ送信者の DNS 検証をイネーブルにする。

• 不正な形式のエンベロープ送信者に対し、カスタム SMTP コードと応答を渡す。エンベロープ送信者の DNS 検証をイネーブルにした場合、不正な形式のエンベロープ送信者はブロックされます。

• 解決されないエンベロープ送信者ドメインに対しカスタム応答を渡す。

• DNS に存在しないエンベロープ送信者ドメインに対しカスタム応答を渡す。

送信者検証例外テーブルを使用して、ドメインまたはアドレスのリストを格納し、そこからのメールを自動的に許可または拒否することができます（「送信者検証例外テーブル」を参照）。送信者検証例外テーブルは、エンベロープ送信者検証とは独立してイネーブルにできます。そのため、たとえば、例外テーブルで指定した特別なアドレスやドメインを、エンベロープ送信者検証をイネーブルにすることなく拒否できます。また、内部ドメインまたはテスト ドメインからのメールを、他の方法で検証されない場合でも常に許可することもできます。

ほとんどのスパムは未検証の送信者から受信されますが、未検証の送信者からのメールを受け付けることが必要な理由があります。たとえば、すべての正規の電子メールを DNS ルックアップで検証できるわけではありません。一時的な DNS サーバの問題により送信者を検証できないことがあります。

未検証の送信者からのメール送信が試みられた場合、送信者検証例外テーブルとメール フロー ポリシーのエンベロープ送信者 DNS 検証設定を使用して、SMTP カンバセーション中にエンベロープ送信者が分類されます。たとえば、DNS に存在しないために検証されない送信元ドメインからのメールを受け付けてスロットリングすることができます。いったんそのメールを受け付けた後、MAIL FROM の形式が不正なメッセージは、カスタマイズ可能な SMTP コードと応答で拒否されます。これは SMTP カンバセーションの中で実行されます。

任意のメール フロー ポリシーに対し、メール フロー ポリシー設定中で、エンベロープ送信者の DNS 検証（ドメイン例外テーブルを含む）をイネーブルにできます。これには、GUI または CLI（ listenerconfig -> edit -> hostaccess -> < policy > ）を使用します。

部分ドメイン、デフォルト ドメイン、不正な形式の MAIL FROM

エンベロープ送信者検証をイネーブルにするか、リスナーの SMTP アドレス解析オプションで部分ドメインの許可をディセーブルにすると（『 Cisco IronPort AsyncOS for Email Advanced Configuration Guide 』の「Customizing Listeners」の章の「SMTP Address Parsing Options」の項を参照）、そのリスナーのデフォルト ドメイン設定は使用されなくなります。

これらの機能は互いに排他的です。

カスタム SMTP コードと応答

エンベロープ送信者の形式が不正なメッセージ、DNS に存在しないエンベロープ送信者、DNS クエリーで解決できない（DNS サーバがダウンしているなど）エンベロープ送信者に対し、SMTP コードと応答メッセージを指定できます。

SMTP 応答には変数 $EnvelopeSender を含めることができます。これは、カスタム応答を送信するときにエンベロープ送信者の値に展開されます。

一般には「Domain does not exist」結果は永続的ですが、これを一時的な状態にすることができます。そのようなケースを扱うために、「保守的な」ユーザは、エラー コードをデフォルトの 5XX から 4XX に変更できます。

送信者検証例外テーブル

送信者検証例外テーブルは、SMTP カンバセーション中に自動的に許可または拒否されるドメインまたは電子メール アドレスのリストです。また、拒否されるドメインについて、オプションの SMTP コードと拒否応答を指定することもできます。IronPort アプライアンスあたりの送信者検証例外テーブルは 1 つのみであり、メール フロー ポリシーごとにイネーブルにされます。

送信者検証例外テーブルは、明らかに偽物であるものの、形式が正しいドメインまたは電子メール アドレスをリストし、そこからのメールを拒否するために使用できます。たとえば、形式が正しい MAIL FROM pres@whitehouse.gov を送信者検証例外テーブルに格納し、自動的に拒否するように設定できます。また、内部ドメインやテスト ドメインなど、自動的に許可するドメインをリストすることもできます。これは、Recipient Access Table（RAT; 受信者アクセス テーブル）で行われるエンベロープ受信者（SMTP RCPT TO コマンド）処理に似ています。

送信者検証例外テーブルは、GUI の [Mail Policies] > [Exception Table] ページ（または CLI の exceptionconfig コマンド）で定義された後、GUI（「メール フロー ポリシー ACCEPTED に対する送信者検証の実装」を参照）または CLI（『 Cisco IronPort AsyncOS CLI Reference Guide 』 を参照）でポリシーごとにイネーブルにされます。

送信者検証例外テーブルのエントリの構文は次のとおりです。

図 5-27 例外テーブルのリスト

例外テーブルの変更については「GUI での送信者検証例外テーブルの作成」を参照してください。

送信者検証の実装 -- 設定例

ここでは、ホストとエンベロープ送信者検証の典型的で保守的な実装の例を示します。

この例では、ホスト送信者検証を実装するときに、既存の送信者グループ SUSPECTLIST とメール フロー ポリシー THROTTLED により、逆引き DNS ルックアップが一致しない接続元ホストからのメールがスロットリングされます。

新しい送信者グループ（UNVERIFIED）と新しいメール フロー ポリシー（THROTTLEMORE）が作成されます。検証されない接続元ホストからのメールは、SMTP カンバセーションの前にスロットリングされます（送信者グループ UNVERIFIED とより積極的なメール フロー ポリシー THROTTLEMORE が使用されます）。

メール フロー ポリシー ACCEPTED に対してエンベロープ送信者検証がイネーブルにされます。

表 5-15 に、送信者検証を実装するための推奨される設定を示します。

送信者グループ SUSPECTLIST に対するホスト送信者検証の実装

GUI で、[Mail Policies] タブの [HAT Overview] をクリックします。既存の送信者グループの一覧が表示されます。送信者グループ SUSPECTLIST に対するホスト DNS 検証をイネーブルにして設定するには、次の手順を実行します。

ステップ 1 [HAT Overview] ページで、送信者グループのリスト中の [SUSPECTLIST] をクリックします。

図 5-28 [HAT Overview] ページ

ステップ 2 [Sender Group: SUSPECTLIST] ページが表示されます。

図 5-29 Sender Group: SUSPECTLIST

ステップ 3 [Edit Settings] をクリックします。[Edit Settings] ダイアログが表示されます。

図 5-30 Sender Group: SUSPECTLIST: Edit Settings

ステップ 4 リストから [THROTTLED] ポリシーを選択します。

ステップ 5 [Connecting Host DNS Verification] の中の [Connecting host reverse DNS lookup (PTR) does not match the forward DNS lookup (A)] チェックボックスをオンにします。

ステップ 6 変更を送信して確定します。

逆引き DNS ルックアップが失敗した送信者は送信者グループ SUSPECTLIST に一致し、メール フロー ポリシー THROTTLED のデフォルト アクションが実行されます。

（注） また、CLI でホスト DNS 検証を設定することもできます。詳細については、「CLI でのホスト DNS 検証のイネーブル化」を参照してください。

送信者検証の実装

まず、新しいメール フロー ポリシーを作成し（この例では THROTTLEMORE という名前を付けます）、より厳格なスロットリング設定を行います。

ステップ 1 [Mail Flow Policies] ページで [Add Policy] をクリックします。

ステップ 2 メール フロー ポリシーの名前を入力し、[Connection Behavior] として [Accept] を選択します。

ステップ 3 メールをスロットリングするようにポリシーを設定します。

ステップ 4 変更を送信して確定します。

次に、新しい送信者グループを作成し（この例では、UNVERIFIED という名前を付けます）、THROTTLEMORE ポリシーを使用するように設定します。

ステップ 1 [HAT Overview] ページで [Add Sender Group] をクリックします。

図 5-31 Add Sender Group: THROTTLEMORE

ステップ 2 リストから [THROTTLEMORE] ポリシーを選択します。

ステップ 3 [Connecting Host DNS Verification] 中の [Connecting host PTR record does not exist in DNS] チェックボックスをオンにします。

ステップ 4 変更を送信して確定します。これで [HAT Overview] ページは次のようになります。

図 5-32 [HAT Overview]

次の手順では、未検証の送信者を扱うようにメール フロー ポリシー ACCEPTED を設定します。

メール フロー ポリシー ACCEPTED に対する送信者検証の実装

GUI で、[Mail Policies] タブの [Mail Flow Policies] をクリックします。既存のメール フロー ポリシーの一覧が表示されます。メール フロー ポリシー ACCEPTED に対してエンベロープ送信者の DNS 検証をイネーブルにするには、次の手順を実行します。

ステップ 1 [Mail Flow Policies] ページで、メール フロー ポリシー [ACCEPTED] をクリックします。

ステップ 2 メール フロー ポリシーの最後にスクロールします。

図 5-33 メール フロー ポリシー ACCEPTED のエンベロープ送信者の DNS 検証の設定

ステップ 3 [On] を選択し、このメール フロー ポリシーに対するエンベロープ送信者の DNS 検証をイネーブルにします。

ステップ 4 カスタム SMTP コードと応答を定義することもできます。

ステップ 5 [Use Domain Exception Table] で [On] を選択することで、ドメイン例外テーブルをイネーブルにします。

ステップ 6 変更を送信して確定します。

最後の手順として、送信者検証例外テーブルを作成し、送信者検証設定に対する例外を列挙します。

GUI での送信者検証例外テーブルの作成

[Mail Policies] > [Exception Table] ページを使用して、送信者検証例外テーブルを設定します。例外テーブルは、[Use Exception Table] がオンになっているすべてのメール フロー ポリシーにグローバルに適用されることに注意してください。

ステップ 1 [Mail Policies] > [Exception Table] ページで [Add Domain Exception] をクリックします。[Add Domain Exception] ページが表示されます。

図 5-34 例外テーブルへのアドレスの追加

ステップ 2 電子メール アドレスを入力します。具体的なアドレス（pres@whitehouse.gov）、名前（user@）、ドメイン（@example.com または @.example.com）、または IP アドレスを角カッコで囲んだアドレス（user@[192.168.23.1]）を入力できます。

ステップ 3 そのアドレスからのメッセージを許可するか拒否するかを指定します。メールを拒否する場合、SMTP コードとカスタム応答を指定することもできます。

ステップ 4 変更を送信して確定します。

送信者検証例外テーブル内でのアドレスの検索

特定のアドレスが例外テーブルのいずれかのエントリに一致するかどうかを判定するには、次の手順を実行します。

ステップ 1 [Exception Table] ページの [Find Domain Exception] セクションに電子メール アドレスを入力し、[Find] をクリックします。

図 5-35 例外テーブル中の一致エントリの検索

ステップ 2 テーブル中のいずれかのエントリにアドレスが一致した場合、最初に一致したエントリが表示されます。

図 5-36 例外テーブル中の一致エントリの一覧表示

送信者検証設定のテスト

これで送信者検証設定を完了したため、IronPort アプライアンスの動作を確認できます。

DNS 関連の設定のテストは、本書の範囲を超えていることに注意してください。

エンベロープ送信者検証の設定のテスト

THROTTLED ポリシーのさまざまな DNS 関連の設定をテストすることは難しい場合がありますが、形式が不正な MAIL FROM 設定をテストできます。

ステップ 1 IronPort アプライアンスへの Telnet セッションを開きます。

ステップ 2 SMTP コマンドを使用して、形式が不正な MAIL FROM（ドメインなしの「admin」など）を使用したテスト メッセージを送信します。

（注） デフォルト ドメインを使用するか、メールを送受信するときに部分ドメインを明示的に許可するように IronPort アプライアンスを設定した場合や、アドレス解析をイネーブルにした場合は（『Cisco IronPort AsyncOS for Email Advanced Configuration Guide』の「Customizing Listeners」を参照）、ドメインがないかドメインの形式が正しくない電子メールを作成、送信、受信できない場合があります。

ステップ 3 メッセージが拒否されることを確認します。

SMTP コードと応答が、メール フロー ポリシー THROTTLED のエンベロープ送信者検証設定で設定したものになっていることを確認します。

送信者検証例外テーブルのテスト

送信者検証例外テーブルに列挙されている電子メール アドレスからのメールに対し、エンベロープ送信者検証が実行されないことを確認するには、次の手順を実行します。

ステップ 1 アドレス admin@zzzaaazzz.com を、例外テーブルに動作「Allow」で追加します。

ステップ 2 変更を確定します。

ステップ 3 IronPort アプライアンスへの Telnet セッションを開きます。

ステップ 4 SMTP コマンドを使用して、送信者検証例外テーブルに入力した電子メール アドレス（admin@zzzaaazzz.com）からテスト メッセージを送信します。

ステップ 5 メッセージが許可されることを確認します。

その電子メール アドレスを送信者検証例外テーブルから削除すると、エンベロープ送信者のドメイン部分が DNS で検証されないため、その送信者からのメールが拒否されます。

送信者検証とロギング

次のログ エントリは、送信者検証の判断例を示します。

エンベロープ送信者検証

形式が不正なエンベロープ送信者

ドメインが存在しない（NXDOMAIN）

ドメインが解決されない（SERVFAIL）

CLI でのホスト DNS 検証のイネーブル化

CLI でホスト DNS 検証をイネーブルにするには、 listenerconfig->edit->hostaccess コマンドを使用します（詳細については、『 Cisco IronPort AsyncOS CLI Reference Guide 』 を参照してください）。

表 5-16 に、未検証の送信者の種類と対応する CLI 設定を示します。

受信者アクセス テーブル（RAT）

受信者アクセス テーブルは、パブリック リスナーが許可する受信者を定義します。このテーブルでは、アドレス（部分アドレス、ユーザ名、ドメイン、またはホスト名）と、それを許可するか拒否するかを指定します。オプションで、その受信者の RCPT TO コマンドに対する SMTP 応答を含めたり、特定のエントリでスロットリング制御をバイパスしたりできます。

RAT エントリは次の基本的な構文によって定義されます。

ルール

RAT には、SMTP カンバセーションの中でやりとりするときに受信者に対して実行する、次の 2 つの基本的な動作があります。

受信者の定義

RAT では、受信者または受信者のグループを定義できます。受信者は、完全な電子メール アドレス、ドメイン、部分ドメイン、またはユーザ名で定義できます。

（注） GUI の System Setup Wizard の手順 4 でドメインを受信者アクセス テーブルに追加する場合（を参照）、サブドメインを指定するための別のエントリを追加することを検討してください。たとえば、ドメイン example.net を入力する場合、.example.net も入力したほうがよい場合があります。第 2 のエントリにより、example.net のすべてのサブドメイン宛のメールが受信者アクセス テーブルに一致するようになります。RAT で .example.com のみを指定した場合、.example.com のすべてのサブドメイン宛のメールを許可しますが、サブドメインがない完全な電子メール アドレス受信者（たとえば joe@example.com）宛のメールは許可されません。

特別な受信者でのスロットリングのバイパス

受信者エントリで、リスナーでイネーブルになっているスロットリング制御メカニズムを受信者がバイパスすることを指定できます。

この機能は、特定の受信者のメッセージを制限しない場合に便利です。たとえば、多くのユーザは、メール フロー ポリシーで定義されている受信制御に基づいて送信元ドメインがスロットリングされている場合でも、リスナー上でアドレス「 postmaster@domain 」の電子メールを受信します。リスナーの RAT 中で受信制御をバイパスするようにこの受信者を指定することで、同じドメイン中の他の受信者用のメール フロー ポリシーを保持しつつ、リスナーは受信者「 postmaster@domain 」の無制限のメッセージを受信できます。受信者は、送信元ドメインが制限されている場合に、システムが保持している時間あたりの受信者のカウンタでカウントされません。

GUI で特定の受信者が受信制御をバイパスするように指定するには、RAT エントリを追加または編集するときに、[Bypass Receiving Control] で [Yes] を選択します。

図 5-37 受信制御のバイパス

CLI で特定の受信者が受信制御をバイパスするように指定するには、 listenerconfig -> edit -> rcptaccess コマンドを使用して受信者を入力するときに、次の質問に「yes」と答えます。

特別な受信者での LDAP 許可のバイパス

LDAP 許可クエリーを設定する場合、特定の受信者について許可クエリーをバイパスすることが必要な場合があります。この機能は、 customercare@example.com のように、ある受信者宛に受信した電子メールについて、LDAP クエリーの中で遅延させたりキューに格納したりしないことが望ましい場合に便利です。

LDAP 許可クエリーの前にワーク キュー内で受信者アドレスを書き換えるように設定した場合（エイリアシングまたはドメイン マップの使用など）、書き換えられたアドレスは LDAP 許可クエリーをバイパスしません）。たとえば、エイリアス テーブルを使用して customercare@example.com を bob@example.com および sue@example.com にマップします。 customercare@example.com について LDAP 許可のバイパスを設定した場合、エイリアシングが実行された後に、 bob@example.com および sue@example.com に対して LDAP 許可クエリーが実行されます。

GUI で LDAP 許可をバイパスするように設定するには、RAT エントリを追加または編集するときに [Bypass LDAP Accept Queries for this Recipient] を選択します。

CLI で LDAP 許可クエリーをバイパスするように設定するには、 listenerconfig -> edit -> rcptaccess コマンドを使用して受信者を入力するときに、次の質問に「yes」と答えます。

LDAP 許可をバイパスするように RAT エントリを設定する場合、RAT エントリの順序が、受信者アドレスの一致のしかたに影響を与えることに注意してください。条件を満たす最初の RAT エントリを使用して受信者アドレスが一致します。たとえば、RAT エントリ postmaster@ironport.com と ironport.com があるとします。postmaster@ironport.com のエントリについては LDAP 許可クエリーをバイパスするように設定し、ironport.com のエントリを ACCEPT に設定します。postmaster@ironport.com 宛のメールを受信した場合、LDAP 許可がバイパスされるのは、postmaster@ironport.com のエントリが ironport.com のエントリよりも前にある場合のみです。ironport.com のエントリが postmaster@ironport.com のエントリの前にある場合、RAT はこのエントリを介して受信者アドレスと一致し、ACCEPT アクションが適用されます。

デフォルト RAT エントリ

作成するすべてのパブリック リスナーについて、デフォルトでは、 すべての 受信者からの電子メールを 拒否 するように RAT が設定されます。

[Recipient Access Table Overview] リストでは、デフォルト エントリの名前は [All Other Recipients] になります。

（注） デフォルトでは、RAT はすべての受信者を拒否し、誤ってインターネット上にオープン リレーが作成されないようにします。オープンリレー（「セキュアでないリレー」または「サードパーティ リレー」とも呼びます）は、第三者による電子メール メッセージのリレーを許す SMTP 電子メール サーバです。オープン リレーがあると、ローカル ユーザ向けでもローカル ユーザからでもないメールを処理することにより、非良心的な送信者がゲートウェイを通じて大量のスパムを送信することが可能になります。作成するパブリック リスナーの受信者アクセス テーブルのデフォルト値を変更するときには注意してください。

デフォルトの「ALL」エントリを RAT から削除してはなりません。

テキスト ファイルとしてテキスト リソースをインポートおよびエクスポートする方法

アプライアンスのコンフィギュレーション ディレクトリにアクセスする必要があります。インポートするテキスト ファイルは、アプライアンス上のコンフィギュレーション ディレクトリに存在する必要があります。エクスポートされたテキスト ファイルは、コンフィギュレーション ディレクトリに配置されます。

コンフィギュレーション ディレクトリへのアクセスの詳細については、 付録 A「アプライアンスへのアクセス」 を参照してください。

新しい RAT エントリの追加

RAT にエントリを追加するには、次の手順を実行します。

ステップ 1 [Add Recipient] をクリックします。[Add to Recipient Access Table] ページが表示されます。

図 5-39 RAT エントリの追加

ステップ 2 エントリの順序を選択します。

ステップ 3 受信者アドレスを入力します（有効なエントリの詳細については、「受信者の定義」を参照してください）。

ステップ 4 受信者を許可するか拒否するかを選択します。

ステップ 5 オプションで、受信者に対する LDAP 許可クエリーをバイパスすることを選択できます（「特別な受信者での LDAP 許可のバイパス」を参照）。

ステップ 6 このエントリに対してカスタム SMTP 応答を使用する場合は、[Custom SMTP Response] で [Yes] を選択します。応答コードとテキストを入力します。

ステップ 7 オプションで、スロットリングをバイパスすることを設定できます（「特別な受信者でのスロットリングのバイパス」を参照）。そのためには、[Bypass Receiving Control] で [Yes] を選択します。

ステップ 8 変更を送信して確定します。

RAT エントリの削除

RAT エントリを削除するには、次の手順を実行します。

ステップ 1 削除する各エントリの [Delete] 列のチェックボックスをオンにします。

ステップ 2 [Delete] をクリックします。

ステップ 3 チェックボックスをオンにしたエントリが RAT から削除されます。

ステップ 4 変更を確定します。

RAT エントリの変更

RAT エントリを変更するには、次の手順を実行します。

ステップ 1 [Recipient Access Table Overview] で RAT エントリをクリックします。[Edit Recipient Access Table] ページが表示されます。

ステップ 2 エントリを変更します。

ステップ 3 変更を確定します。

RAT エントリの順序の変更

RAT 内のエントリの順序を変更するには、次の手順を実行します。

ステップ 1 [Edit Order] をクリックします。[Edit Recipient Access Table Order] ページが表示されます。

図 5-40 RAT エントリの順序の変更

ステップ 2 [Order] 列の値を調整して順序を変更します。

ステップ 3 変更を確定します。

RAT エントリのエクスポート

RAT エントリをエクスポートするには、次の手順を実行します。

ステップ 1 [Export RAT] をクリックします。[Export Recipient Access Table] ページが表示されます。

図 5-41 RAT エントリのエクスポート

ステップ 2 エクスポートするエントリのファイル名を入力します。これは、アプライアンスの設定ディレクトリに作成されるファイルの名前になります。

ステップ 3 変更を送信して確定します。

RAT エントリのインポート

RAT をインポートすると、既存のすべての RAT エントリが RAT から削除されます。

一連の RAT エントリをインポートするには、次の手順を実行します。

ステップ 1 [Import RAT] をクリックします。[Import Recipient Access Table] ページが表示されます。

図 5-42 RAT エントリのインポート

ステップ 2 リストからファイルを選択します。

（注） インポートするファイルは、アプライアンスのコンフィギュレーション ディレクトリに存在する必要があります。

ステップ 3 [Submit] をクリックします。既存の RAT エントリをすべて削除することを確認する警告メッセージが表示されます。

ステップ 4 [Import] をクリックします。

ステップ 5 変更を確定します。

ファイルには「コメント」を格納できます。文字「#」で始まる行はコメントと見なされ、AsyncOS によって無視されます。次の例を参考にしてください。

この時点で、電子メール ゲートウェイの設定は次のようになります。

図 5-43 パブリック リスナーの RAT の編集

図 5-44 は、図 5-4 に示した図を展開したものであり、リスナーの HAT（該当する場合）と RAT の処理シーケンスと、それぞれのデフォルト値が含まれています。

図 5-44 パブリック リスナーとプライベート リスナー