アクセス制御

アクセス制御を使用して、特定のユーザーから (へ) のメッセージをシステムレベルで拒否できます。また、特定のユーザー間でより複雑なメッセージトラフィックの制限を構成することもできます。さらに、ユーザーに独自の受信メッセージのフィルタ設定を許可し、メッセージヘッダの内容に基づいてメッセージを拒否することなどができます。

エンベロープレベルでアクセス制御を行うときは、マッピングテーブルを使用してメールのフィルタリングを行います。ヘッダベースでアクセス制御を行う場合、またはユーザー独自の制御を行う場合は、サーバー側の規則とともに一般的なメールボックスフィルタを使用します。

マッピングテーブルの概要

特定の「マッピングテーブル」を設定することにより、メールサービスへのアクセスを制御できます。MTA の多くのコンポーネントでは、テーブル検索指向の情報を利用しています。この種類のテーブルは、変換、すなわち入力文字列を出力文字列へ「マップ」するのに使用されます。マッピングテーブルは通常、2 つの列として表示されます。1 列目 (左側) には、マッチングの対象となる可能性のある入力文字列 (パターン)、2 列目 (右側) には入力文字列のマッピングの結果である出力文字列 (テンプレート) が表示されます。

次の表で、マッピングテーブルの使用により、だれがメールを送信または受信できるのか、あるいは送受信ともにできるのかを制御する方法を説明します。詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』を参照してください。

図 13–1 は、メール受信プロセスの中でマッピングテーブルが使用される場所を示したものです。

図 13–1 マッピングテーブルとメール受信プロセス

MTA サービスディスパッチャーが制御するすべてのネットワークポートで、PORT_ACCESS 拒否応答が保証されている場合は、リモートホストから最初の接続が行われた時点で、それが実行されます。FROM_ACCESS による拒否は、送信側が受信者情報またはメッセージデータを送信する前に、MAIL FROM: コマンドへの応答として行われます。SEND_ACCESS または MAIL_ACCESS による拒否は、送信側がメッセージデータを送信する前に、RCPT TO: コマンドへの応答として行われます。SMTP メッセージが拒否された場合は、Messaging Server がメッセージデータを受信せずメッセージデータを確認しないため、そのような拒否を処理するためのオーバーヘッドが最小になります。複数のアクセス制御マッピングテーブルが存在する場合、Messaging Server はそれらをすべて調べます。

メッセージが受け入れられた場合は、さらに変換チャネルとユーザー定義のフィルタによりフィルタリングされます。

マッピングテーブルによるリレー防止設定

アクセス制御マップを使うことによって、Messaging Server システムが SMTP メールのリレーに利用されるのを防ぐことができます。たとえば、あるユーザーが迷惑メールのリレーにメールシステムを使用して、システム上の多数のメールボックスに送信しようとするような場合です。

Messaging Server のデフォルトでは、ローカルの POP メールクライアントおよび IMAP メールクライアントによるリレーを含むすべての SMTP リレー操作が防止されます。「認証された SMTP を有効にする」で説明しているように、クライアントが SMTP AUTH を使用して認証せず、Messaging Server の SMTP サーバーを介して外部アドレスにメッセージを送信しようとした場合、その送信は拒否されます。このため、内部システムとリレーを許可するサブネットを認識するように設定を変更した方がよいでしょう。

外部ホストからのリレーを防止するには

ドメイン外にあるホストからドメイン外の別のホストにメッセージがリレーされるのを防ぐには、次の方法を取ります。

手順

1. 受信メールをいくつかのチャネルに分けます。例:

   • ドメイン内の IP アドレスは tcp_internal チャネルに送られます。

   • 認証されたセッションは tcp_auth チャネルに送られます。

   • その他のすべてのメールは、tcp_local チャネルに送られます。

2. 『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の「メールのフィルタリングとアクセス制御」の章で詳しく説明されているように、INTERNAL_IP マッピングテーブルを使用して、POP クライアントと IMAP クライアントからのメールを識別し、処理を許可します。

メールボックスフィルタの使用

フィルタは、メッセージに適用される 1 つ以上の条件付き処理で構成されています。Messaging Server フィルタはサーバーに保存され、サーバーによって評価されます。そのため、それらはサーバー側規則 (SSR) と呼ばれることもあります。

チャネルレベルのフィルタと MTA 全体のフィルタを作成し、不正メールの配信を防止できます。また、フィルタテンプレートを作成し、Messenger Express を使用してそれをエンドユーザーに使わせることもできます。エンドユーザーはテンプレートを使用して個人のメールボックスフィルタを構築し、不要なメールメッセージが自分のメールボックスに配送されないようにすることができます。サーバーは、次の優先順位に従ってフィルタを適用します。詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』を参照してください。

1. ユーザー単位のフィルタ

   ユーザー単位のフィルタは、特定ユーザーのメールボックスに送信されるメッセージに適用されます。フィルタテンプレートを作成し、Messenger Express クライアントを使用してそれをエンドユーザーに使わせることができます。エンドユーザーはテンプレートを使用して個人のサーバーフィルタを構築し、自分のメールボックスへのメールメッセージの配送を管理できます。フィルタにより、不要なメッセージ、リダイレクトメールなどの拒否や、メールボックスフォルダに配信されるメッセージのフィルタリングなどが行われます。

   個人用メールボックスフィルタにメッセージの許可あるいは拒否が定義されている場合は、メッセージに対してそのフィルタ処理が行われます。

   フィルタテンプレートは、Sieve スクリプトの「ハードコード」された要素をプロンプトと入力フィールドに置き換えることで、Sieve スクリプトを一般化します。Java サーブレットは、Sieve テンプレートを解析し、ブラウザ内でユーザーインタフェースを生成するのに使用されます。エンドユーザーが入力フィールドに値を入力すると、サーブレットがその値を取得して、ユーザーのディレクトリにあるプロファイルエントリ内の Sieve スクリプトに保存します。Messenger Express インタフェースを通じて、プロンプトと入力フィールドがエンドユーザーに提示されます。

   しかし、受取人がメールボックスフィルタを設定していない場合、またはユーザーのメールボックスフィルタが明示的に適用されないメッセージの場合、Messaging Server によってチャネルレベルのフィルタが適用されます。

2. チャネルレベルのフィルタ

   チャネルレベルのフィルタは、チャネルのキューに入った各メッセージに適用されます。この種のフィルタの一般的な用途は、特定のチャネルから入ってくるメッセージをブロックすることです。

   チャネルレベルのフィルタを作成するには、Sieve を使用してフィルタを書く必要があります。Sieve を使用してフィルタを作成する場合の指示の詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の第 17 章「メールのフィルタリングとアクセス制御」を参照してください。

   チャネルレベルのフィルタにメッセージの許可あるいは拒否が定義されている場合は、メッセージに対してそのフィルタ処理が行われます。それ以外の場合は、Messaging Server によって MTA 全体のフィルタが適用されます (該当する場合)。

3. MTA 全体のフィルタ

   MTA 全体のフィルタは、MTA のキューに入るすべてのメッセージに適用されます。この種のフィルタの一般的な用途は、メッセージの送信先とは関係なく、ダイレクトメールや受信したくないメッセージをブロックすることです。

   MTA 全体のフィルタを作成するには、Sieve を使用してフィルタを書く必要があります。Sieve を使用してフィルタを作成する場合の指示の詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の第 17 章「メールのフィルタリングとアクセス制御」を参照してください。

   デフォルト設定を使用した場合、それぞれのユーザーはメールボックスフィルタを所有していません。ユーザーが Messenger Express インタフェースにアクセスして 1 つまたは複数のフィルタを作成すると、そのフィルタが LDAP ディレクトリに保存されます。