Version 5.1
システム |
|---|
| ||||||||||
|
|
Version 5.1 |
||||||||||||||||||||||||||||||||
|
|
スパムメールを数千、ときには何百万のユーザーに送りつける場合、スパムメール送信者は、イン ターネット上のSMTP メールサーバーをリレーサーバーとして使います。つまり、一つのメールをイ ンターネット上の複数のメールサーバーに送り、そのメールサーバーを介してメールを別のサーバー にルートさせ、多数のメールアドレスに配信するという方法を使います。その結果、サーバーリソースがオーバーロードするばかりでなく、ユーザーは、自分がスパムメール の送信者として見なされるというリスクを負うことになります（スパムメールが自分のサーバーから送られるためです）
CommuniGate Pro サーバーにはアンチスパム（スパム防御） 機能が搭載されており、この機能により スパムメール対策が可能です。
サーバーのSMTP モジュールで受信TCP 接続を受け付ける機能がある場合、スパムメール送信者に よってサーバーがリレーエンジンとして利用される可能性があります。つまり、スパムメール送信者 は、そのサーバーをオープンリレーとして使用して世界中のユーザーにスパムメールを送信するとい う操作が可能です。
サイトをスパムメールから保護したい場合、使用しているサーバーのリレー機能を制限するという操 作が必要です。つまり、基本的に現在のサーバーのユーザーだけが、サーバーを介してインターネッ ト上の別のアドレスにメールを送信できる、という仕組みにします。また、外部のサーバーから送ら れたメッセージ（ メール） は、送信先のアカウントでだけ受信され、他のインターネットサイトへの リレーは、明示的にリレーを許可したサーバーでだけ実行されるようにします。
受信SMTP メッセージが、正規のユーザーから送られてきたかどうかは、送信元のネットワークアド レス（IP アドレス） で分かります。この性質を利用し、ユーザーがすべてLAN から接続を行ってい る場合、LAN のユーザーからのメッセージだけが「クライアント（正規のユーザー） からのメッセー ジ」として処理され、こうしたメッセージだけがインターネットに送信されるように設定できます。 この方法で、スパムメールを排除できます。
上記の設定を行う場合、WebAdmin インターフェイスの［Settings］ セクションの［Protection］ ページ を開きます。その後、［Client IP Addresses］ リンクをクリックします。
［Client IP Addresses］ リストに、正規のユーザーが使用しているLAN のIP アドレスを入力します。ま た、外部のシステムのうち、サーバー（CommuniGate Pro） をメールリレーサーバーとして使用させ てもよいシステムがある場合、そのシステム（例えば支社のサーバー） のIP アドレスも入力します。
クライアントIP アドレスは、複数行で入力できます。フォーマットについては、詳しくは「システム 管理」のセクションのシステム管理者の説明を参照してください。
ダイアルアップサービスをサポートしている場合、ダイアルアップユーザーに割り当てているIP アド レスをIP アドレス範囲で指定します（上記のリストの2 行目を参照）。
クライアントIP アドレスは、実際のIP アドレスの代わりに「逆ルックアップドメイン名（IP アドレ スから変換されたドメイン名）」を使って指定することもできます。
逆ルックアップドメイン名を使ってクライアントIP アドレスを指定する場合、［Detect Clients by DNS Name］ チェックボックスをチェックします。また、チェックボックスの下のテーブルに、正規 のLAN やシステムの名前を入力しておきます。ドメイン名には、ワイルドカード（*） も使えます。 この設定にしておくと、クライアントから接続が実行され、そのクライアントのIP アドレスが ［Client IP Addresses］ リストに登録されていなかったときには、サーバーにより、そのIP アドレスに 対応するドメイン名が取得されます（例えば、IP アドレスがaa.bb.cc.dd だったときには、 dd.cc.dd.aa.in-addr.arpa 名のPTR レコードが取得されます）。PTR レコード（ ドメイン名） の取得に 成功した場合、そのドメイン名がテーブルに入力されているドメイン名の中にないかどうかがチェッ クされます。ドメイン名がテーブルのドメイン名の中にあった場合、そのドメイン名のDNS A レコードが取り出 され、続いて、クライアントのIP アドレスがDNS A レコードのIP アドレスの中に存在するかどうか がチェックされます。クライアントのIP アドレスがDNS A レコードのIP アドレスの中に存在してい るときには、そのIP アドレスは「クライアントIP アドレス」と解釈されます。つまり、そのIP ア ドレスは、［Client IP Addresses］ リストに登録済みのIP アドレスと同じく、正規のLAN やシステム のIP アドレスとして処理されることになります。
注意: 上記の手法は、従来のメールサーバーでもよく使われています。ただし、大規模なシステムの 場合には負荷が大幅に増加します。この手法では、受信接続が発生し、その接続のIP アドレスが登録 済みのクライアントIP アドレスの中になかった場合、DNS トランザクションが2 つ実行されます。こ のトランザクションはどちらも処理に非常に時間がかかります。したがって、この手法は、必要不可 欠なときに限って使うのが得策です。例えば、サーバーで、大学などの大きな組織ネットワークをサ ポートする必要があるが、そのサブネットワークの構成が不明であり、ただし、サブネットワークの IP アドレスを「逆リゾルブ」してサブドメイン名に変換することはできる、といった場合、この手法 を使うようにします。その場合でも、少なくても分かっているIPアドレスはすべて［Client IP Addresses］ リストに登録しておきます。このようにすることで「逆リゾルブ」処理の数が減少し、負荷を減らす ことができます。
上記のように［Client IP Addresses］ リストにクライアントIP アドレスを登録した場合、メッセージ がSMTP モジュールで受信され、そのメッセージの送信元のIP アドレスが［Client IP Addresses］ リ ストになかったときには、そのメッセージに「第三者からのメッセージ」というマークが付けられま す。さらに、そのメッセージがインターネット上の別のホストにリレーされるメッセージであり、リ レー先のホスト（システム） のIP アドレスが［Client IP Addresses］ リストに登録されていなかった 場合には、そのメッセージは拒否されます。
結局、［Client Addresses］ リストに登録されているサーバーやワークステーションからのメッセージ に限って、CommuniGate Pro サーバーで受け付けられ、インターネット上の別のメールサーバーに送 信（ リレー） されます。一方、リストに登録されていないIP アドレス（サーバーやワークステーショ ン） から送信されたメッセージは拒否されます。同様に、メッセージがリレーメッセージであり、そ のサーバーのIP アドレスがリストに登録されていない場合、メッセージはすべて拒否されます。この ようにして、スパムメール送信者がCommuniGate Pro サーバーを「オープンメールリレー」サーバー として使用することを防止できます。
なお、正規のユーザーであっても、そのIP アドレスを［Client Addresses］ リストに間違って登録して いたり、登録が抜けていたりすることもあります。その場合、そのユーザーは送信（ リレー） ができ なくなります。そういったケースを考慮して、［SMTP Settings］ ページに［Relay to any IP Address］ オ プションが用意されています。
［Relay to any IP Address］ オプションを［if received from Clients］ に設定しておくと、クライアント （正規のユーザー） から受信したメールだけがリレーされ、一方、「第三者対第三者」のリレーは拒否 されます。
前述のように、［Client IP Addresses］ リストには、必要であればCommuniGate Pro サーバー以外のメー ルサーバーを登録しておくこともできます。その場合、任意のユーザーからメールが受信され、その メールの送信先のサーバーが［Client IP Addresses］ リストに登録されているときには、そのサーバー にメールが通常どおりにリレーされます。ただし、問題が起こることもあるため（例えば、下記の2 サーバーリレー）、メッセージのアドレスが「単純」アドレスかどうかをチェックする機能も搭載され ています。
［SMTP Settings］ページには［Relay to Client IP Addresses］ オプションがあります。このオプション を［simple］ に設定しておくと、メールが受信され、そのメールアドレスが「複雑なアドレス」（形式 は、ユーザー名% ホスト名@ 他のサーバー） だったときには、送信先が［Client IP Addresses］ リスト に登録されているメールサーバーであっても、メールの自動リレーは拒否されます。この方法を使うことで、スパムメール送信者がCommuniGate Pro サーバーを介して「2 サーバーリレー」（two-server relay ＝ 2 つのサーバーを介してメールを送信すること） を実行することを防止できます。
下は、2 サーバーリレーの例です。ここでは、サーバー2 のIP アドレスがサーバー1 の［Client IP Addresses］ リストに、サーバー1 のIP アドレスがサーバー2 の［Client IP Addresses］ リストに登録 されているとします。なお、古いメールサーバーによっては、アドレス中の引用符が無視され、メールが正常に届かないこ ともあります。そのため、［simple］ オプションを選択している場合、メールのローカル部に引用符が 使われているときには、送信先が［Client IP Addresses］ リストに登録されているサーバーであり、ま たメールが「単純なメールアドレス」のメールであっても、リレーは行われません。
［Relay to Client IP Addresses］ オプションを［no］ に設定しておくと、複雑なメールアドレスであるか どうかはチェックされません。したがって［Client IP Addresses］ リストに登録されているメールサー バーに通常どおりリレーされます。
サーバーでモバイルユーザーをサポートする予定がないときには、［Reject all Logins from Non-Client IP Addresses］ オプションを選択しておきます。この設定で、［Client IP Addresses］ リストに登録され ている（LAN の） ユーザー以外はログインできなくなります。この場合でも、モバイルユーザーなど、 他のユーザーからの接続は受け付けられ、他のユーザーは「ログイン処理」が必要ないサービスは利 用することができます。例えば、SMTP メール転送、パーソナルWeb サイトの表示、メーリングリス トの閲覧などは可能です。
注意:このオプションを選択する場合、あらかじめ、［Client IP Addresses］ リストをチェックし、必 要なユーザーのLAN アドレス（IP アドレス） がすべて登録されているかどうかを確認してください。 また、このオプションを使用する前に、「セキュリティ」のセクションのセキュリティの説明をお読 みください。
ユーザーの中には出先で仕事をしたり出張が多かったりする人も少なくありません。出先などでは、 通常、ISP を介してインターネットに接続しますが、その結果、いろいろなIP アドレスでサーバー （CommuniGate Pro） に接続することになります。こうしたモバイルユーザーにとっては、サーバーを SMTP メールリレーサーバーとして使用し、メールを送信（自分のメールボックスにアクセス） する 必要が出てくることもあります。その場合、モバイルユーザーが［Client IP Addresses］ リストに登録 されていないときにはリレーは制限され、したがって、CommuniGate Pro サーバーをリレーサーバー として使ってメールを送信することはできません。
サーバーでモバイルユーザーをサポートする場合、［Reject all Logins from Non-Client IP Addresses］ オ プションの代わりに［Allow Mobile Users to Login］ オプションを選択します。これで、［Client IP Addresses］ リストに登録されていなくても、モバイルユーザーはログインできるようになります。以下、［Allow Mobile Users to Login］ オプションを選択した場合に使われるユーザー認証方式について説 明します。
現在、多くの電子メールクライアントでは（例えば、Microsoft Outlook Express、Netscape Messenger、 Qualcomm Eudora ほか多数）、"SMTP AUTH" がサポートされています。こうした電子メールクライア ントをモバイルユーザーが使用しているときには、SMTP AUTH を使ってユーザー（送信者） の認証 が行われます。この方式では、SMTP モジュールでメッセージが受信され、そのメッセージが正規 ユーザーからのメッセージだったときには、「ローカルアカウントから提出」とマークされます。そ の後、メッセージがインターネットにリレー（送信） されます。
モバイルユーザーによっては古い電子メールクライアント（SMTP AUTH がサポートされていないア プリケーション） を使っていることもあります。モバイルユーザーが、古い電子メールクライアント でCommuniGate Pro サーバーを介してメッセージを送信した場合、そのメッセージの送信元のIP アド レスは［Client IP Addresses］ リストに登録されていないものの、そのユーザーが正規ユーザーである かどうかがチェックされます。正規ユーザーだった場合、POP/IMAP セッション中、また、セッション終了後の一定時間の間、送信 元のIP アドレスは「クライアントアドレス（正規のユーザーのIP アドレス）」として解釈され、この 間、ユーザーはメールの送信をできるようになります。セッション終了後の一定時間は、［Process as a Cliane IP Address for］ オプションで指定できます。また、ユーザーは、厳密にはCommuniGate Pro サーバーの自分のメールボックスをチェックした直後から、CommuniGate Pro サーバーを介したメー ルの送信が可能になります。
上記のセッション終了後の一定時間、送信が可能というオプションは、大半のISP で「動的IP アドレ ス」が使われている関係で用意されています。つまり、動的IP アドレスでは、モバイルユーザーが ISP モデムから接続を切断した後、そのISP で別のユーザーがインターネットに接続した場合、モバイ ルユーザーに割り当てられていたIP アドレスが、そのユーザーに割り当てられることがあります。そ のため、IP アドレスを確保しておく必要があります。
上記のセッション終了後の一定時間（送信が可能な時間） は、モバイルユーザーに知らせておく必要 があります。また、モバイルユーザーには、できるだけメッセージをオフラインで作成するように説 明します。さらに、作成後、ISP を介してインターネットに接続し、CommuniGate Pro サーバー上の自 分のメールボックスをチェックし、その後、作成したメッセージを実際に送信するように伝えておき ます。そのほか、モバイルユーザーが自分のメールボックスからメッセージを取り出し、その返事を 書いた場合、その後、もう一度「受信」操作をして初めて返事の送信が可能になります。このことも 説明します。
メーラーアプリケーション（電子メールクライアント） では、通常、キューされているメッセージが 先に送信されますが、その場合、SMTP モジュールによってリターンパス（SMTP プロトコルコマンド のMail From に格納されるアドレス） がチェックされます。このアドレス（差出人アドレス） が登録 ユーザーのアドレスだった場合には、送信に問題が発生したときでも、「永続的障害」エラーコードで はなく「一時障害」エラーコード（「認証が必要」） というコメントが付きます） が出力されます。「一 時障害」が発生した場合でも、メーラーの多くでは、通常はメールセッションが中止されることはな く、その後、ユーザー認証、メールの取り出し、キューされているメッセージの再送信という順で処 理を続けることができます。ユーザー認証が正常に完了すれば、メッセージの送信は問題なく実行さ れます。
SMTP セッション（ メッセージの送信） は、POP セッションまたはIMAP セッションの最中、もしく はPOP/IMAP セッションの終了後の一定時間（上記を参照） 内に開始されます。開始されたSMTP セッションは、キューされているメッセージのサイズが大きかったりリンク速度が遅かったりしたと きには、その後、長時間（数時間） にわたって継続することがあります。
サーバーでサポートしているモバイルユーザーは、アカウント（ユーザー） を指定して、またはドメ インを単位としてサポートを無効にすることができます。サポートを無効にしたい場合、［Enabled Services］ （現在有効のサービス） セクションの［Mobile］ オプションをオフにします。このセクショ ンは、［Account Settings］ ページ（アカウントを指定して無効にする場合） または［Domain Settings］ ページ（ ドメインを単位として無効にする場合） にあります。ユーザーを指定してサービスを無効に した場合、［Client IP Addresses］ リストに登録されていないインターネットアドレス（ISP） から自分 のアカウントに接続できなくなります。
モバイルユーザーによるメールのリレーも、同様にアカウント（ユーザー） を指定して、またはドメ インを単位として無効にできます。リレーのサポートを無効にしたい場合、［Enabled Services］ セク ションの［Relay］ オプションをオフにします。このセクションは、［Account Settings］ ページ（アカ ウントを指定して無効にする場合） または［Domain Settings］ ページ（ ドメインを単位として無効に する場合） にあります。モバイルユーザーの場合、ログインで使用されているIP アドレスは「暫定 クライアントIP」として記憶されますが、リレーを無効にすると（ユーザー単位、ドメイン単位の 両方）、「暫定クライアントIP」は失われます。
また、SMTP 認証で認証されないため、モバイルユーザーはSMTP モジュールを介してメッセージを リレーすることができなくなります。モバイルユーザーのうち、SMTP モジュール（CommuniGate Pro） を経由したリレーを許可したくないモバイルユーザーがいる場合、この設定を使います（ リ レーを無効にした場合、モバイルユーザーは、WebUser インターフェイスなどの非SMTP インター フェイスを使ってメッセージを送信しなければなりません）。
サーバーのSMTP モジュールでTCP 接続が受け付けられるようになっている場合、スパムメール送信 者によってサーバーがリレーエンジンとして使われる可能性があります。リレーエンジンとして使用 された場合、サーバーを介して世界中にスパムメールが配信される恐れがあります。この問題を防ぐ ため、SMTP モジュールにはリターンパスアドレス（SMTP プロトコルコマンドMail From で指定され ているアドレス） を検証する機能があります。
TCP 接続が発生した場合、SMTP モジュールによってメッセージのリターンパスアドレス（Mail From） が解析されます。その後、次のようなメッセージは拒否されます。上記の解析後、SMTP モジュールでルータを使って処理が実行されます。処理では、リターンパスア ドレスがローカルユーザーのアドレスだった場合、またはリターンパスアドレスがルータで記憶され ているアドレス（ リルートされたアドレス） だった場合、そのリターンパスアドレスは正常なアドレ スとして受け入れられます。いずれも、サーバーにとって「既知」であるアドレスであり、したがっ てドメインネームシステムに対する呼び出しは実行されません。
一方、ERROR アドレスとしてルートされたリターンパスアドレスのメッセージは、拒否されます。こ うしたメッセージは、そのリターンパスアドレスをルータで「不正アドレス/ ドメイン名」として指 定することで、拒否することができます。
一方、offenderdomain.com ドメインからのメッセージのうち、リターンパスアドレスが"promo"
で始まるメッセージは受信したいとします。この場合、次のように定義します。
<promo*@offenderdomain.com> = error
なお、ドメインネームシステムにリターンパスのドメイン名は登録されているものの、そのドメイン ネームシステムが使用できないときには、リターンパスのドメイン名の検証ではできません。その場 合、SMTP モジュールによって、そうしたリターンパスアドレスのメッセージは拒否されます。同時 に、「永続」エラーコードではなく「暫定」エラーコードがメッセージの送信元のシステムに対して出 力されます。この後、送信元のシステムでは、メッセージの再送信が実行されます。
また、SPF DNS レコードを使って、メッセージのリターンパスが、本当に送信者のシステムのネット ワーク（IP） アドレスに対応したものであるかどうかをチェックすることもできます。
You can tell the SMTP module to use the Reverse Connect method:サーバーのSMTP モジュールでTCP 接続を受け付けるようしている場合、スパムメール送信者によっ てサーバーがリレーエンジンとして使われる可能性があります。その場合、サーバーを介して世界中 にスパムメールが配信される恐れがあります。また、CommuniGate Pro サーバーのユーザーに不要な メッセージを大量に送りつけてくる可能性もあります。
スパムメール送信者のサイトの中には、ホストのIP アドレスが分かっているものもあります。 CommuniGate Pro では、判明しているホストのIP アドレスのブラックリストを作成し、CommuniGate Pro サーバーシステムを保護することができます。
ブラックリストに登録したホストからCommuniGate Pro サーバーに接続が試行され、SMTP を介して メッセージが送信された場合、SMTP モジュールからエラーメッセージが出力されます。また、その ホストからのメールは拒否されます。
ブラックリストに不正ホストを登録する場合、WebAdmin インターフェイスで［Settings］ セクショ ンの［Protection］ ページを開きます。
行の終わりには、セミコロン（;） を付加してコメントを入力できます。また、行の最初にセミコロ ンを入力し、その後、コメントを記述することもできます。この行は無視されます。
不正ホストは多数あり、IP アドレスが頻繁に変わることもあるため、不正ホストのブラックリストを 最新の状態にしておくのは簡単ではありません。こういったことから、リアルタイムブラックホール リスト（RBL） というサービスが提供されており、このサービスを利用することで既知の不正ホスト のIP アドレスを効率よく登録できます。
ISP によってはRBL サービスを提供していることもありますが、 CommuniGate Pro サーバーでは、任 意のRBL サービスを利用でき、その中から正確なブラックリストのRBL サービスを探して利用する のが効率的です。RBL サーバーについては、詳しくはISP に問い合わせてください。
使用するRBL サービスが決まれば、［Use Blacklisting DNS Sefvers (RBLs)］ チェックボックスをチェッ クし、下のフィールドにRBL サービスのドメイン名（IP アドレスではなくドメイン名） を正確に入 力します。このように設定しておくと、その後、SMTP モジュールで何らかのIP アドレス（例えば、 aaa.bbb.ccc.ddd） から接続が受信され、そのIP アドレスが［Blacklisted IP Addresses］ または ［UnBlacklistable (White Hole) IP Addresses］ リストのどちらにも登録されていない場合、SMTP モ ジュールによって架空のドメイン名（つまりddd.ccc.bbb.aaa.rbl-server-name、rbl-servername は指定済みのRBL サーバー） が作成されます。
続いて、SMTP モジュールにより、架空のドメイン名がIP アドレスに「リゾルブ」されます。この処 理が成功し、そのIP アドレスが127.0.0.2 から127.1.255.255 の範囲のIP アドレスだったときには、 aaa.bbb.ccc.ddd というアドレスが不正ホストのIP アドレスとして登録されます。
注意:上の場合、DNS （ ドメインネームシステム） 処理が発生し、その結果、受信接続の処理速度が 低下することがあります。
RBL サーバーのリストには、RBL サーバー（のドメイン名） を複数指定できます。リストのRBL サー バーを削除したい場合、そのフィールドを空白にします。なお、RBL サーバーを複数指定すると、そ の分、受信接続の処理速度が低下します。RBL サーバーが複数必要であり、しかも接続の処理速度を 落としたくないときには、DNS サーバーを使って複数のRBL サーバーからRBL 情報を取り出し（デ イリーゾーンアップデートを使用します）、DNS サーバーをRBL サーバーとして使用するという方法 を使います。
注意:RBL サーバーに障害が起こると、受信接続の処理速度が非常に遅くなることがあります。こ の問題を回避するため、RBL サーバーに対する要求は最大で2 回にし、また、各要求のタイムアウ トを最低に設定します。
上記のRBL サーバーによる方法のほか、［Blacklist by DNS Name］ オプションを使って、不正ホスト をドメイン名を使って登録することもできます。この方法を使う場合、［Blacklist by DNS Name］ チェックボックスをチェックし、下のフィールドに不正ホストと思われるホストのドメイン名を入力 しておきます（ ワイルドカード（*） を使用でき、ドメイン名は複数指定できます）。これで、何らか のIP アドレスから接続が実行され、そのIP アドレスが［Blacklisted IP Addresses］ リストに登録され ていないときには、そのIP アドレスのドメイン名が取得されます（例えば、IP アドレスが aa.bb.cc.dd の場合、dd.cc.dd.aa.in-addr.arpa 名のPTR レコードが取得されます）。PTR レコードの取得に成功すると、そのレコード（ ドメイン名） が ［Blacklist by DNS Name］ チェックボックスの下のフィールドに入力されているドメイン名と照合されます。そのドメイン名と フィールドのいずれかのドメイン名とが一致した場合、そのIP アドレスは、不正ホストのIP アドレ スとして記憶、登録されます。
注意:Blacklist by DNS Name］ オプションを有効にしておくと、逆ルックアップDNS 処理が実行され ます（ただし、［Detect Clients by DNS Name］ オプションが有効になっているときは逆ルックアップ DNS 処理は実行されません）。逆ルックアップDNS 処理が発生すると、受信SMTP 接続の処理速度が 低下することがあります。そのため、このオプションは、本当に必要な場合、または、何らかの理由 により不正ホストのIP アドレスを［Blacklisted IP Addresses］ リストに直接登録できない場合に限っ て使用するようにします。
注意:逆ルックアップDNS 処理が失敗すると、逆ルックアップDNS 処理の結果（DNS 名） が入るコ ンテナにDNR エラーコードが格納されます。コンテナーの中のエラーコードは、カッコで括られま す。逆ルックアップDNS 処理に失敗することが多い場合、つまり逆DNS レコードがないネットワー クアドレスが多い場合、" (host name is unknown)" という文字列をフィールドに入力しておきます。 これで、逆DNS レコードがないネットワークアドレスをすべて、不正ホストのIP アドレスとして登 録できます。
RBL サーバーまたはドメイン名を使って不正ホストの登録を行っている場合（上記の2 種類の方法）、ホストによってはブラックリストから除外する必要が出てくることもあります。例えば、問題 のないホストが誤ってRBL サーバーに登録されているときには、除外が必要です。
その場合、除外したいホストのIP アドレス（ホワイトホールアドレス） を［UnBlacklistable (White Hole) IP Addresses］ リストに入力します。入力フォーマットは、［Blacklisted IP Address］ リストと同 じです。
注意:RBL サーバーまたはドメイン名による不正ホストの登録の際には、［Client IP Addresses］ リス トのIP アドレスが不正ホストのアドレスとして登録されることは一切ありません（デフォルトで、 正規ユーザーのIP アドレスと扱われるためです）。そのため、［Client IP Addresses］ リストのIP アド レスを［UnBlacklistable (White Hole) IP Addresses］ リストに入力して、除外する必要はありません。
IP アドレスではなく、DNS （PTR） 名を使ってホストを除外したい場合、次のようにします。
［UnBlacklist by DNS Name］ チェックボックスをチェックし、下のフィールドに除外したいホストの DNS ドメイン名を入力します。このオプションは、とくにRBL サーバーを使って登録してあるホス トを除外したいときに利用できます。
注意:［UnBlacklist by DNS Name］ オプションでは、［Blacklisted IP Addresses］ リストに登録されてい る不正ホストは除外できません。このリストに登録されている不正ホストを除外する場合、 ［UnBlacklistable (White Hole) IP Addresses］ リストを使います。
場合によっては、ブラックリストに登録してある不正ホストからメッセージが送信されてくることも ありますが、その場合のSMTP モジュールの応答処理を変更することができます。例えば、メッセー ジの受信を拒否（受信アドレスに@blacklisted という接尾辞を追加） する代わりに、メッセージ を受信してヘッダフィールドを追加するという処理に変更できます。
CommuniGate Pro には専用の「暫定ブラックリスト」があり、このリストを使って自動的に不正ホス トが登録されます。なお、このリストによる不正ホストの登録は、一定期間に限って有効です。詳し くは、SMTPモジュールの説明を参照してください。
［Client IP Addresses］ （正規のホスト/ ユーザー） リストのIP アドレス、また［Blacklisted IP Addresses］ （不正ホスト） リストのIP アドレスはどちらも、サーバーを使用しているうちに次第に 数が増えます。そのため、現在、どのリストにどんなIP アドレスが登録されているのか、確認する のが難しくなります。
このような場合、［Test Address］ パネルを使ってIP アドレスを効率よく検索できます。このパネル は、［Client IP Addresses］ ページと［Blacklisted IP Addresses］ ページにあります。
パネルのフィールドに検索したいIP アドレスを入力し、［Test］ ボタンをクリックします。クリック 後、そのIP アドレスに関する情報（ステータス） が表示されます。
ステータスとしては、まず、IP アドレスがローカルのIP アドレスだった場合、先頭にLocal という 接頭辞が付加されます。一方、LAN IP アドレスリストに記録されているアドレスだったときには、 先頭にLAN という接頭辞が付加されます。
また、そのIP アドレスが、以前の登録時に逆リゾルブDNS 処理を使って取得されたものだった場 合、逆リゾルブ名（ ドメイン名） が表示されます。
上記のIP アドレスまたはドメイン名の後に次のステータスが表示されます。
送信されてくるスパムからサイトを保護したい場合、スパムトラップ（電子メールアドレス） をいく つか作成し、アドバタイズ（公開） するという方法を使います。スパムトラップは特殊なローカル電 子メールアドレスで、CommuniGate Pro のルータで捕捉が可能です。この方法により、サーバーで何 らかのメッセージが受信され、その受信アドレス（送信先アドレス） がいずれかのスパムトラップ （spamtrap@ ホストの形式） だった場合、またはメッセージがスパムトラップにルートされた場合、 そのメッセージはサーバーにより拒否されます。
スパムトラップには、エイリアス（単一もしくは複数） を作成できます。エイリアスは架空の名前と し、作成したエイリアスは、スパムトラップに割り当てておきます。下は例です。
<misterX> = spamtrap <johnsmith@subdomain.com> = spamtrap
なお、架空のアカウントは作成する必要はありません。ルータエイリアスレコードを作成するだけで 十分です。
スパムトラップのエイリアス（misterX@yoursite.com、johnsmith@subdomain.com など） が作成できれば、エイリアスをできるだけ、スパムメール送信者が使っているメーリングリストに登 録されやすいようにします。例えば、スパムメール送信者が使うメーリングリストは、ほとんどの場 合、Web ページやUsenet ニュースグループをロボットスキャンして得られた情報で構成されています。
そのため、スパムトラップのエイリアスをWeb ページに置いておいたり、また、Usenet メッセージ をポスティングする場合、シグネチャーに挿入しておくという方法が効果的です。ただし、一般の ユーザーの混乱を避けるため、スパムトラップのエイリアスは、Web ページ上では見えなくしてお くか、その旨を記載しておくようにします。
スパムメールのメーリングリストは、通常、ドメイン名を基準にソートされています。その結果、ス パムメールは、一般にサイトの複数のユーザーに送られてきます。つまり、こうしたユーザーの電子 メールアドレスがスパム送信者に知られていることになります。上のようにして、スパムトラップ電 子メールアドレス（エイリアス） を作成し、アドバイズ（公開） することで、エイリアスが徐々にス パム送信者のメーリングリストに登録されます。また、時間がたつにつれて、ほとんどのスパムメッ セージで、スパムトラップ電子メールアドレスが送信先アドレスとして記録されます。このようなス パムメールはすべてサーバーによって拒否され、サイトの実際のユーザーに届くことがなくなりま す。
あらかじめヘッダと本文を指定しておき、そのヘッダと本文と、スパムメールのヘッダと本文を比較 することで、スパムメールを検出できます。設定しておくと、RFC822 フォーマットのメールがサー バーで受信された場合（ SMTP、RPOP、POP XTND XMIT、PIPEの各モジュールを介して受信）、指定 したヘッダと本文とメールのヘッダと本文が照合されます。照合で文字列が一致した場合、そのメー ルは拒否されます。
ヘッダまたは本文を指定する場合、ワイルドカード（*） も使用できます。ただし、ワイルドカード は、通常は使用する必要はありません。ワイルドカードを使う代わりに、これまで受信されたスパム メールのヘッダまたは本文をコピーして入力でき、このほうが効率的です。
本文は、［Banned Body Lines］ リストに入力します。文字列は、ケースセンシティブ（大文字と小文字 を区別） です。
ヘッダは、［Banned Header Lines］ リストに入力します。文字列が長く改行されているヘッダをコピー した場合、場合、行末記号もコピーされます。
メッセージのヘッダまたは本文がエンコード（MIME またはUU） されているときには、文字列はデ コードされないまま、指定したヘッダまたは本文と照合されます。
ヘッダと本文を指定する場合、WebAdmin インターフェイスの［Settings］ セクションの［Protection］ ページを開きます。その後、［RFC822 Receiver］ リンクをクリックします。
ヘッダまたは本文を追加したい場合、空のフィールドに入力し、［Update］ ボタンをクリックします。
ヘッダまたは本文を削除したい場合、文字列を削除し、［Update］ ボタンをクリックします。
サーバーでメッセージが受信されると、自動的にサーバーワイドルール（サーバー全体で有効なルー ル） が適用されます。このサーバーワイドルールを使って、不要なメールの拒否、削除、リダイレク トが可能です。
例えば、メッセージのうち、To: フィールドまたはCc: フィールド、もしくは両方が存在しないメッ セージをすべて拒否したい場合、次のルール（フィルタリングルール） を使います。
フィルタリングルールは、CommuniGate Pro の自動メール処理機能を使って必要に応じて作成できま す。また、外部フィルタプログラムをExecute ルールアクションを使って起動させることもできま す。
以下、CommuniGate Pro サーバーの特殊リレー機能について説明します。
ルータ（Router） テーブルには、エイリアスレコードを指定することができます。例えば、次のエイ リアスレコードを指定したとします。
この場合、指定したユーザー（user） に対して第三者（user@other.host） からメールが送られてきた ときには、そのメールは送信元のホスト（other.host） にリルートされます（つまりリレーは実行さ れません）。また、送信元のサーバーのIP アドレスが［Client IP Addresses］ リストに登録されていな い場合、その送信元からのメールはすべて「第三者対第三者」のメールとして処理されます。さら に、［Relay for Clients Only］ オプションが有効になっているときには、この種のメールはすべて拒否 されます。上記のリレーの禁止を解除したい場合、接頭辞としてRelay を使います。または、何も付 加しないでおきます（デフォルトでRelay）。下記は、例です。
アドレスにルータレコードがある場合、そのアドレスが変換されるときには、そのアドレスへのメー ルのリレーを許可するマーカーが設定されます。一方、ルータレコードに接頭辞としてNoRelay が 指定されている場合、リレーを許可するマーカーは設定されません。このマーカーは、その後に再設 定（ リレーを許可） されることもありません（下の例を参照）。
いずれかのドメインのメールをすべて別のホストにリルート（例えば、ホストをバックアップ） しよ うとし、その別のホストが［Client IP Addresses］ リストに登録されていないときもマーカーの処理 は同じです。
アドレスに通常のルータレコード（Relay 接頭辞のレコード） があり、そのアドレスが「単純なア ドレス」でなかったとき、つまりuser%host1@host2 や<@host2:user@host1> など、複数の ルート（ ドメイン） で構成されているときには、通常と異なり、メッセージのリレーを許可するフラ グ（マーカー） は設定されません。これは、リルートされるメッセージのリレー先のホスト（2 番目 のホスト） によって、最初のホストからのメールがすべて「信頼」されるというケースがあるためで す。つまり、複数のルートで構成されるアドレス（複雑なアドレス） のメールのリレーを許可した場 合、最初のホストと2 番目のホストを介して第三者が第三者に対してメールを送信できるというケー スが発生するためです。
サーバーの保護が十分な場合には、ルータレコードを介してリルートされるアドレスがすべてリレー されるように設定することもできます。その場合、接頭辞RelayAll を使います。
上記のように、ルータレコードを使ってリレーを実行または許可できます。ただし、ルータレコード を介して第三者がリレーを実行すると問題が起こるため、通常、正規のユーザーだけがリレーを実行 できるようにします。その場合、NoRelay 接頭辞を使ってアドレス/ ドメインを指定します。例え ば、ユーザーがrelay3.com をリレーサーバーとして使用してメールをbigprovdier.com に送信 できるようにしたいとします。この場合、ルータテーブルに次のレコードを定義します。
上で、NoRelay 接頭辞がないときには、インターネット上の任意のホストからサーバー （CommuniGate Pro） を介してbigprovdier.com にメールを送ることができます。一方、NoRelay がある場合、bigprovdier.com ドメインのアドレスにはマーカーは設定されず、したがってサーバーの 正規ユーザー（ クライアント） だけがサーバーを介してbigprovdier.com にメールを送信できる ようになります。
注意: ルータテーブルにはエイリアスレコードを定義できます。
上の場合、サーバーで受信されたメールのうち、送信先がjoe@mydomain.com であるメールがす べてjoe5@bigprovdier.com に送られます。このレコードにはデフォルトでRelay 接頭辞が付加 されており、そのため世界中の任意のユーザーがjoe@mydomain.com にメールを送信でき、また メールはbigprovdier.com にリレーされます。アドレスjoe5@bigprovdier.com は joe5%bigprovdier.com@relay3.com.smtp に変換され、relay3.com を介してメールが送信され ます。最初の変換では「リレー許可」マーカーが設定されます。2 回目の変換では、「リレー許可」 マーカーは設定されず、また、最初の変換で設定された「リレー許可」マーカーが再設定されることはありません。
| 実行される処理 | アドレス | マー |
|---|---|---|
| （オリジナルの）アドレス を受信 | joe@mydomain.com | なし |
| メインドメイン （mydomain.com）を削除 | joe | なし |
| ルータレコード： <joe> = joe5@bigprovdier.com |
joe5@bigprovdier.com | あり |
| ルータレコード： NoRelay:bigprovdier.com = bigprovdier.com@relay3.com.via |
joe5%bigprovdier.com@relay3.com.via | あり |
| SMTP モジュール： ホストrelay3.comに関する処理を実行 |
joe5@bigprovdier.com | あり |
サーバーがダイナミッククラスタのメンバーの場合（サーバーがダイナミッククラスタ環境で動作し ている場合）、WebAdmin ネットワークとキュー設定のページにはリンクが表示され、このリンクを 使ってローカル（サーバーワイド）とクラスタワイドの切り替えが可能です。
クラスタワイドの各アドレステーブル（Client IP Addresses、Blacklisted IP Addresses、Unblacklistable IP Addresses の3 つのリスト） は、サーバーワイドの各アドレステーブルの拡張テーブルとして処理 されます。つまり、何らかのアドレス（IP アドレス） があり、そのアドレスがサーバーワイドの テーブルまたはクラスタワイドのテーブルのどちらかに存在する場合、そのアドレスは登録されてい ると解釈されます。
クラスタワイドの［Client By DNS Name］ リストは、各サーバーのサーバーワイドの［client IP domains］ リストの延長として処理されます（ クラスタワイドのページで［Detect Clients by DNS Name］ オプションが有効に設定されている場合）。
クラスタワイドの［Blacklist By DNS Name］ リストは、各サーバーのサーバーワイドの［blacklisted IP domains］ リストの延長として処理されます（ クラスタワイドのページで［Blacklist by DNS Name］ オプションが有効に設定されている場合）。
クラスタワイドのRBL サーバーリストは、各サーバーのサーバーワイドのRBL サーバーリストの延 長として処理されます。各サーバーでRBL サーバーへのアクセスが必要になったときには、まず、 そのサーバーのローカル（サーバーワイド） のRBL サーバーリストがチェックされます。その後、 クラスタワイドの設定で指定されているRBL サーバーがチェックされます。
クラスタワイドの［Banned Header/Body Lines］ オプション（ヘッダと本文を指定してメールを拒否） の設定は、サーバーワイドの［Banned Header/Body Lines］ オプションの設定の延長として処理され ます。つまり、メッセージは、サーバーワイドの設定とクラスタワイドの設定のどちらかを使って拒 否されます。