第 17 章メールのフィルタリングとアクセス制御

この章では、メールをソース (差出人、IP アドレスなど) やヘッダー文字列に基づいてフィルタリングする方法について説明します。メールフィルタリングには、MTA へのアクセスを制御するため、マッピングテーブルを使う方法と、Sieve サーバー側ルール (SSR) を使う方法の 2 つがあります。

マッピングテーブルを使って MTA へのアクセスを制限すると、From: アドレスと To: アドレス、IP アドレス、ポート番号、およびソースまたは宛先チャネルに基づいてメッセージをフィルタリングできます。マッピングテーブルを使うと、SMTP リレーの有効または無効を切り替えることができます。Sieve はメールフィルタリングスクリプトであり、これを使うと、ヘッダーで見つかった文字列に基づいてメッセージをフィルタリングできます。これは、メッセージ本文に対しては機能しません。

エンベロープレベルの制御が望ましい場合には、マッピングテーブルを使ってメールをフィルタリングします。ヘッダーベースの制御が望ましい場合には、Sieve サーバー側ルールを使います。

第 1 部マッピングテーブル: 管理者は、特定のマッピングテーブルを設定することによって MTA サービスへのアクセスを制御できます。管理者は、Messaging Server によるメールの送信または受信をどのユーザーに許可するか、あるいは許可しないかを制御できます。

第 2 部メールボックスフィルタ: ユーザーと管理者は、メッセージをフィルタリングし、メッセージヘッダーで見つかった文字列に基づいて、フィルタ済みのメッセージに対するアクションを指定できます。Sieve フィルタ言語を使用します。フィルタリングは、MTA レベルまたはユーザーレベルのチャネルで実行できます。

第 1 部マッピングテーブル

マッピングテーブルを使ってアクセスを制御する

メールサービスへのアクセスを制御するには、一定のマッピングテーブルを使用します。マッピングテーブル (表 17-1) を使用することにより、だれがメールを送信または受信できるのか、あるいは送受信できるのかを制御することができます。マッピングファイルの形式と使用方法についての一般的な情報は、「マッピングファイル」を参照してください。


注	mappings ファイルを変更した場合は、必ず設定をコンパイルしなおしてください (『Sun Java System Messaging Server Administration Reference』の imsimta refresh コマンドを参照)。

表 17-1 に、この節で説明するマッピングテーブルの一覧を示します。

表 17-1 アクセス制御マッピングテーブル
マッピングテーブル	説明
SEND_ACCESS (508を参照)	エンベロープ From アドレス、エンベロープ To アドレス、ソースおよび宛先チャネルに基づいて、受信接続をブロックする場合に使用する。書き換えやエイリアス展開などの処理が行われてから、To アドレスが調べられる
ORIG_SEND_ACCESS (508を参照)	エンベロープ From アドレス、エンベロープ To アドレス、ソースおよび宛先チャネルに基づいて、受信接続をブロックする場合に使用する。書き換え後、エイリアス展開の前に To アドレスが調べられる
MAIL_ACCESS (510を参照)	SEND_ACCESS テーブルと PORT_ACCESS テーブルを組み合わせた情報に基づいて受信接続をブロックする場合に使用する。SEND_ACCESS のチャネルとアドレス、および PORT_ACCESS の IP アドレスとポート番号に関する情報が基準となる
ORIG_MAIL_ACCESS (510を参照)	ORIG_SEND_ACCESS テーブルと PORT_ACCESS テーブルを組み合わせた情報に基づいて受信接続をブロックする場合に使用する。ORIG_SEND_ACCESS のチャネルとアドレス、および PORT_ACCESS の IP アドレスとポート番号に関する情報が基準となる
FROM_ACCESS (512を参照)	エンベロープ From アドレスに基づいてメールをフィルタリングする場合に使用する。このテーブルは、To アドレスが不適切な場合に使用する
PORT_ACCESS (514を参照)	IP 番号に基づいて受信接続をブロックする場合に使用する

もっとも一般的なのは、MAIL_ACCESS および ORIG_MAIL_ACCESS によるマッピングで、SEND_ACCESS および ORIG_SEND_ACCESS に使用できるアドレスおよびチャネル情報のほか、IP アドレスやポート番号などの PORT_ACCESS マッピングテーブルを介して得られるような情報も得ることができます。

SEND_ACCESS テーブルと ORIG_SEND_ACCESS テーブル

SEND_ACCESS マッピングテーブルと ORIG_SEND_ACCESS マッピングテーブルを使用して、だれがメールを送信または受信できるのか、あるいは送受信できるのかを制御することができます。アクセスチェックは、メッセージエンベロープの From: アドレスおよびエンベロープの To: アドレス、メッセージがどのチャネルから入ってきたか、どのチャネルから出ていくのかという情報に基づいて行われます。

SEND_ACCESS または ORIG_SEND_ACCESS のマッピングテーブルが存在する場合、MTA を通過するメッセージの各受取人を調べるために、MTA は以下のフォーマットの文字列が記述されているテーブルをスキャンします。縦棒文字「|」の用法に注意してください。

src-channel はメッセージをキューに入れるチャネル、from-address はメッセージの作成者アドレス、dst-channel はキューに入れられたメッセージの宛先となるチャネル、to-address はメッセージの宛先アドレスです。これらの 4 つのフィールド内でアスタリスクを使用すると、そのフィールドの情報 (チャネルやアドレスなど) が任意のデータと一致するようになります。

この場合のアドレスは、エンベロープの From: アドレスとエンベロープの To: アドレスを指しています。SEND_ACCESS の場合は、書き換えやエイリアス展開などの処理が行われてから、エンベロープの To: アドレスが調べられます。ORIG_SEND_ACCESS の場合は、書き換え後、エイリアス展開の前に、メッセージ作成者により指定されたエンベロープの To: アドレスが調べられます。

検索文字列のパターン (テーブルの左側にあるエントリ) が一致すると、そのマッピングの結果出力が調べられます。出力に「$Y」または「$y」フラグが含まれている場合は、その特定の To: アドレスに対しメッセージをキューに入れることが許可されます。出力に「$N」、「$n」、「$F」、または「$f」フラグが含まれている場合は、その特定のアドレスに対しメッセージをキューに入れることが拒否されます。拒否された場合は、オプションの拒否通知テキストをマッピング出力に与えることができます。その文字列は、MTA が発行する拒否通知エラーメッセージに含まれることになります。「$N」、「$n」、「$F」、「$f」以外に文字列が出力されない場合は、デフォルトの拒否通知テキストが使用されます。その他のフラグの説明については、「アクセス制御マッピングテーブルのフラグ」を参照してください。

次の例は、mail や Pine などの UNIX ユーザーエージェントから送られてきたメール、ローカル l チャネルからの入力、および TCP/IP などのチャネルからメッセージをインターネットに出力するケースを示すものです。ポストマスター以外のローカルユーザーは、インターネットからメールを受信できても送信は許可されていないと仮定します。そのような制御を行う 1 つの手段として、次の例に示す SEND_ACCESS マッピングテーブルの使用があります。このマッピングテーブルの例では、ローカルのホスト名が sesta.com であると想定しています。チャネル名「tcp_*」では、ワイルドカードを使って任意の TCP/IP チャネル名 (たとえば tcp_loal) と一致するようにしています。

拒否通知メッセージでは、メッセージ内の空白文字の引用符としてドル記号が使われています。ドル記号を使用しないと、拒否通知メッセージが「Internet postings are not permitted」とならずに「Internet」だけで終わってしまいます。この例では、ローカルのポスティングに関するほかのソース (PC ベースのメールシステムであるのか、POP または IMAP クライアントであるのかなど) は無視されていることに注意してください。

MAIL_ACCESS マッピングテーブルと ORIG_MAIL_ACCESS マッピングテーブル


注	MTA による拒否通知エラーテキストが、メッセージの差出人であるユーザーに対して実際に提示されるかどうかは、メッセージの送信を試行するクライアントにより異なります。受信 SMTP メッセージを拒否するために SEND_ACCESS を使用した場合、オプションの拒否通知テキストを含む SMTP 拒否通知コードを MTA が発行することはほとんどありません。その情報に基づいてバウンスメッセージを構築し、元の差出人に戻すかどうかは、送信 SMTP クライアントによって決まります。

MAIL_ACCESS マッピングテーブルは、SEND_ACCESS マッピングテーブルと PORT_ACCESS マッピングテーブルのスーパーセットです。つまり、SEND_ACCESS のチャネルとアドレス、およびPORT_ACCESS の IP アドレスとポート番号の情報を組み合わせたものです。同様に、ORIG_MAIL_ACCESS マッピングテーブルは、ORIG_SEND_ACCESS マッピングテーブルと PORT_ACCESS マッピングテーブルのスーパーセットです。MAIL_ACCESS のプローブ文字列フォーマットは以下のとおりです。

同様に、ORIG_MAIL_ACCESS のプローブ文字列フォーマットは以下のとおりです。

上記の port-access-probe-info は、受信 SMTP メッセージの場合、PORT_ACCESS マッピングテーブルプローブに通常含まれているすべての情報から成ります。それ以外の場合は空白になります。app-info は、SMTP 経由で送信されたメッセージの場合、通常は SMTP です。それ以外の場合は空白になります。submit-type は MAIL、SEND、SAML、または SOML のいずれか 1 つで、メッセージが Messaging Server へ送信されてきた方法に対応します。通常、この値は、メッセージとして送信されたことを表す MAIL です。SEND、SAML、または SOML は、ブロードキャスト要求 (またはブロードキャストとメッセージを組み合わせた要求) が SMTP サーバーに送信された場合の値です。MAIL_ACCESS マッピングの send-access-probe-info は、SEND_ACCESS マッピングテーブルプローブに通常含まれているすべての情報から成ります。同様に、ORIG_MAIL_ACCESS マッピングの orig-access-probe-info は、ORIG_SEND_ACCESS マッピングテーブルプローブに通常含まれているすべての情報から成ります。

受信 TCP/IP 接続情報が、チャネルおよびアドレスの情報と同じマッピングテーブルにあると、特定の IP アドレスからのメッセージにどのエンベロープの From: アドレスを表示させるのかなど、何らかの制御を課す場合に便利です。電子メールの偽造を規制したり、ユーザーに対し POP および IMAP クライアントの From: アドレス設定を正しく行うように奨励する効果もあります。たとえば、IP アドレス 1.2.3.1 および 1.2.3.2 から送信されたメッセージに対してのみエンベロープの From: アドレスに vip@siroe.com を表示し、1.2.0.0 サブネット内のシステムから送信されるメッセージにはエンベロープの From: アドレスに siroe.com を表示するようなサイトでは、次の例に示す MAIL_ACCESS マッピングテーブルを使用します。

FROM_ACCESS マッピングテーブル

FROM_ACCESS マッピングテーブルは、だれがメールを送信できるのか、まただれが From: アドレスを認証アドレスに書き換えることができるのかを制御するのに使用します。

FROM_ACCESS マッピングテーブルへの入力プローブ文字列は、MAIL_ACCESS マッピングテーブルのものと似ています。違いは、宛先チャネルとアドレスがないこと、場合によっては認証済み差出人情報があることです。したがって、FROM_ACCESS マッピングテーブルが存在する場合は、メッセージが送信されるたびに Messaging Server によって以下のフォーマットで文字列が記述されているテーブルの検索が行われます。縦棒文字「|」の用法に注意してください。

上記の port-access-probe-info は、受信 SMTP メッセージの場合、PORT_ACCESS マッピングテーブルプローブに通常含まれているすべての情報から成ります。それ以外の場合は空白になります。app-info は、SMTP 経由で送信されたメッセージの場合、通常は SMTP です。それ以外の場合は空白になります。submit-type は MAIL、SEND、SAML、または SOML のいずれか 1 つで、メッセージが MTA に送られてきた方法に対応します。通常、この値は、メッセージとして送信されたことを表す MAIL です。SEND、SAML、または SOML は、ブロードキャスト要求 (またはブロードキャストとメッセージを組み合わせた要求) が SMTP サーバーに送信された場合の値です。src-channel はメッセージを発する (メッセージをキューに入れる) チャネル、from-address はメッセージの作成者アドレスです。auth-from は認証済み作成者アドレスですが、その情報がない場合は空白になります。

プローブ文字列のパターン (テーブルの左側にあるエントリ) が一致した場合は、そのマッピングの結果出力が調べられます。出力に「$Y」または「$y」フラグが含まれている場合は、その特定の To: アドレスに対しメッセージをキューに入れることが許可されます。出力に「$N」、「$n」、「$F」、または「$f」フラグが含まれている場合は、その特定のアドレスに対しメッセージをキューに入れることが拒否されます。拒否された場合は、オプションの拒否通知テキストをマッピング出力に与えることができます。この文字列は、Messaging Server が発行する拒否通知エラーメッセージに含まれることになります。「$N」、「$n」、「$F」、「$f」以外に文字列が出力されない場合は、デフォルトの拒否通知テキストが使用されます。その他のフラグの説明については、「アクセス制御マッピングテーブルのフラグ」を参照してください。

FROM_ACCESS は、作成者の情報に基づいてメッセージの送信を許可するかどうかを決定できるだけでなく、エンベロープの From: アドレスを $J フラグで許可したり、authrewrite チャネルキーワードの効果を $K フラグで変更 (受理したメッセージに Sender: ヘッダーアドレスを追加) できます。たとえば、以下のマッピングテーブルを使用し、エンベロープの From: アドレスを最初のものから認証アドレスに置き換えることができます。

特定のソースチャネルの authrewrite をゼロ以外の値に設定する効果を変更するために FROM_ACCESS マッピングテーブルを使用する場合、認証アドレスが文字どおりである限り FROM_ACCESS を使用する必要はありません。

たとえば、tcp_local チャネルに authrewrite 2 を設定する場合は、authrewrite だけでこの効果 (文字どおりの認証済みアドレス) を得るのに十分なため、次の FROM_ACCESS マッピングテーブルは不要です。

ただし、FROM_ACCESS の本来の目的は、次の例に示すように、より複雑で微妙な変更を行うことにあります。受信メッセージに Sender: ヘッダー行を追加 (SMTP AUTH 認証済み送信者アドレスを表示) したい場合は、authrewrite キーワードだけでも十分です。ただし、SMTP AUTH 認証済み送信者アドレスがエンベロープの From: アドレスと異なる場合にのみ、受信メッセージに Sender: ヘッダー行を強制的に追加したいとします (つまり、アドレスが一致した場合には、Sender: ヘッダー行を追加しない)。さらに、エンベロープの From: にオプションのサブアドレス情報が含まれているというだけでは、SMTP AUTH およびエンベロープの From: アドレスが異なるとみなさないとします。

PORT_ACCESS マッピングテーブル

ディスパッチャは、IP アドレスおよびポート番号に基づいて、受信接続を許可するかどうかを選択できます。ディスパッチャは、起動時に PORT_ACCESS という名前のマッピングテーブルを探します。このファイルが見つかると、ディスパッチャは接続情報を以下のようにフォーマットします。

ディスパッチャは、すべての PORT_ACCESS マッピングエントリを照合します。マッピングの結果に「$N」または「$F」が含まれている場合には、接続を即座に終了します。それ以外の場合は、接続を許可します。「$N」または「$F」の後ろに拒否通知メッセージが続くことがあります。メッセージがある場合には、接続を断つ前にそのメッセージが送り返されます。メッセージが送り返される前に、その文字列には CRLF ターミネータが追加されることに注意してください。


注	MMP は PORT_ACCESS マッピングテーブルを使用しません。特定の IP アドレスからの SMTP 接続を拒否して、MMP を使用する場合は、TCPAccess オプションを使用する必要があります。「MMP を使ったメールアクセスを設定するには」を参照してください。マッピングテーブルを使って SMTP 接続を制御する場合は、INTERNAL_IP マッピングテーブルを使用します (「外部サイトの SMTP リレーを許可する」を参照)。

$< フラグにオプションの文字列が続いており、マッピングプローブが一致しなかった場合は、Messaging Server が文字列を syslog (UNIX) またはイベントログ (NT) に送ります。$> フラグにオプションの文字列が続いており、アクセスが拒否された場合は、Messaging Server が文字列を syslog (UNIX) またはイベントログ (NT) に送ります。LOG_CONNECTION MTA オプションのビット 1 が設定されており、かつ「$N」フラグが設定されて接続が拒否されている場合は、「$T」フラグを指定することにより「T」エントリが接続ログに書き込まれるようになります。LOG_CONNECTION MTA オプションのビット 4 が設定されている場合は、サイト提供のテキストを PORT_ACCESS エントリに提供し、「C」接続ログエントリに含めることが可能です。そのようなテキストを指定するには、エントリの右側に縦棒「|」を 2 つと適切なテキストを挿入します。表 17-2 に使用可能なフラグを表示します。

表 17-2 PORT_ACCESS マッピングフラグ
フラグ	説明
$Y	アクセスを許可する
フラグと引数 (引数の読み取り順序 +)
$< 文字列	プローブが一致する場合、文字列を syslog (UNIX) またはイベントログ (NT) に送る
$> 文字列	アクセスが拒否された場合、文字列を syslog (UNIX) またはイベントログ (NT) に送る
$N 文字列	アクセスを拒否し、オプションのエラーテキスト文字列を送る
$F 文字列	「$N 文字列」と同じ。アクセスを拒否し、オプションのエラーテキスト文字列を送る
$T テキスト	LOG_CONNECTION MTA オプションのビット 1 が設定されており、かつ「$N」フラグが設定されて接続が拒否されている場合、「$T」フラグを指定することにより、「T」エントリが接続ログに書き込まれるようになる。オプションのテキスト (2 つの縦棒「\|」に続けて挿入) は、接続ログエントリに含めることができる
+ 引数を伴うフラグを複数個使用する場合は、引数を縦棒文字「\|」で区切り、この表に示されている順序で配置します。

たとえば、次のマッピングは、単一のネットワークからポート 25 (標準の SMTP ポート) への SMTP 接続だけを許可します。説明テキストは送らずに特定のホストを拒否します。

PORT_ACCESS マッピングテーブルを変更した場合、その変更内容を適用するためにディスパッチャを再起動する必要があります。コンパイルした MTA 設定ファイルを使用している場合は、変更内容を適用するために、先に設定ファイルをコンパイルしなおしてください。

PORT_ACCESS マッピングテーブルは、特に IP ベースの拒否通知を処理するためのものです。電子メールアドレスレベルでの一般的な制御には、SEND_ACCESS または MAIL_ACCESS マッピングテーブルが適しています。

MTA への指定 IP アドレス接続を制限するには

PORT_ACCESS マッピングテーブルの conn_throttle.so 共有ライブラリを使用すると、特定の IP アドレスが MTA に接続する頻度を制限することができます。特定の IP アドレスによる接続の制限は、サービス拒否による過剰な接続を防ぐ場合などに便利です。

conn_throttle.so は PORT_ACCESS マッピングテーブルで使用されるライブラリで、特定の IP アドレスからの過度の MTA 接続を制限するために使用されます。以下に示すように、設定オプションはすべて接続スロットル共有ライブラリに対するパラメータとして指定されます。

IP-address は、ピリオドで区切られた数字によるリモートシステムのアドレスです。max-rate はこの IP アドレスに対して許可される 1 分当たりの最大接続数です。

throttle の代わりに throttle_p をルーチン名として使用すると、ペナルティが適用されます。throttle_p を使用すると、過去に過度の接続があった場合、接続が拒否されます。たとえば、最大接続数が 100 で、過去 1 分間に 250 の接続が試みられた場合、リモートサイトはその 1 分間における最初の 100 個の接続のあとブロックされるだけでなく、次の 1 分間もブロックされます。つまり、1 分が経過するごとに、その 1 分間に試行された接続数と 1 分当たりの許容最大接続数とが比較され、試行接続数が許容最大接続数より大きいと判断された場合、そのリモートシステムはブロックされます。

指定した IP アドレスの接続が 1 分当たりの最大接続数を超えなかった場合、共有ライブラリの呼び出しに失敗します。

1 分当たりの最大接続数を超過した場合は、共有ライブラリの呼び出しに成功しますが、値が返されることはありません。これは $C/$E の組み合わせで行われます。以下に、その例を示します。

PORT_ACCESS

TCP|*|25|*|* ¥
$C$[msg_svr_base/lib/conn_throttle.so,throttle,$1,10] ¥
$N421$ Connection$ not$ accepted$ at$ this$ time$E

$C により、次のテーブルエントリからマッピングプロセスが続行されます。このエントリの出力文字列が、マッピングプロセスの新しい入力文字列として使用されます。

$[msg_svr_base/lib/conn_throttle.so,throttle,$1,10] はライブラリの呼び出しで、throttle はライブラリルーチン、$1 はサーバーの IP アドレス、10 は 1 分当たりの接続数のしきい値です。

$N421$ Connection$ not$ accepted$ at$ this$ time により、アクセスが拒否され、421 SMTP コード (一時的な接続拒否) とともに、「現在接続は受け付けられません」という旨のメッセージが返されます。

$E により、マッピングプロセスが即時に終了します。このエントリからの出力文字列がマッピングプロセスの最終結果として使用されます。

アクセス制御はいつ適用されるのか

Messaging Server は、可能な限り早い段階でアクセス制御マッピングを調べます。実際にどの時点で行われるかは、使用する電子メールプロトコルによって異なります。

これは、必要な情報をいつ読み取れるのかという点に依存しているためです。SMTP プロトコルの場合、FROM_ACCESS による拒否は、送信側が受取人情報やメッセージデータを送信する前に、MAIL FROM: コマンドへの応答として行われます。SEND_ACCESS または MAIL_ACCESS による拒否は、送信側がメッセージデータを送信する前に、RCPT TO: コマンドへの応答として行われます。SMTP メッセージが拒否された場合は、Messaging Server がメッセージデータを受信せずメッセージデータを確認しないため、そのような拒否を処理するためのオーバーヘッドが最小になります。

複数のアクセス制御マッピングテーブルが存在する場合、Messaging Server はそれらをすべて調べます。したがって、FROM_ACCESS、SEND_ACCESS、ORIG_SEND_ACCESS、MAIL_ACCESS、および ORIG_MAIL_ACCESS マッピングテーブルがすべて使用されることがあります。

アクセス制御マッピングをテストするには

imsimta test -rewrite ユーティリティ (特に -from、-source_channel、および -destination_channel オプション) は、アクセス制御マッピングのテストに役立ちます。次の例で、サンプルの SEND_ACCESS マッピングテーブルとその結果としてのプローブを示します。

SMTP リレーを追加するには

Messaging Server は、デフォルトで、試行された SMTP リレーをブロックするように設定されています。つまり、認証されていない外部ソースから外部アドレスへのメッセージの送信は拒否されます。外部システムとは、サーバーがあるホスト以外のシステムです。ほかのシステムはすべて外部システムとみなされることから、SMTP リレーをブロックするこのデフォルト設定はかなり厳しいものだといえます。

IMAP クライアントと POP クライアントが Messaging Server システムの SMTP サーバーを通じて外部アドレス宛てのメッセージを送信し、SMTP AUTH (SASL) を使って承認を行わない場合、メッセージの送信は拒否されます。このため、内部システムとリレーを許可するサブネットを認識するように設定を変更した方がよいでしょう。

どのシステムとサブネットを内部とみなすかは、通常 INTERNAL_IP マッピングテーブルで制御されます。このテーブルはmsg_svr_baset/config/mappings にあります。

たとえば、IP アドレスが 123.45.67.89 の Messaging Server システムの場合、デフォルトの INTERNAL_IP マッピングテーブルは次のようになります。

この例の最初のエントリでは、$(IP-pattern/signicant-prefix-bits) 構文を使用して、32 ビットの 123.45.67.89 すべてに一致する IP アドレスが内部として認識されるように指定しています。2 番目のエントリでは、ループバック IP アドレス 127.0.0.1 が内部として認識されます。最後のエントリは、その他のすべての IP アドレスが外部として認識されるように指定しています。すべてのエントリの先頭に、少なくとも 1 つのスペースが必要なことに注意してください。

最後の $N エントリの前に別の IP アドレスやサブネットを指定して、エントリを追加することもできます。これらのエントリには、IP アドレスまたはサブネット (サブネットの指定には $(.../...) 構文を使用) を左側に、$Y を右側に指定する必要があります。また、既存の $(.../...) エントリを変更して、より広範囲のサブネットを受け入れるようにすることもできます。

たとえば、このサンプルのサイトにクラス C ネットワークがあり、すべての 123.45.67.0 サブネットを所有する場合は、アドレス照合に使用されるビット数を変更することにより初期エントリを変更できます。次に示すマッピングテーブルでは、32 ビットが 24 ビットに変更されています。これにより、クラス C ネットワークのすべてのクライアントが、SMTP リレーサーバーを通してメールをリレーできるようになります。

また、サイトが 123.45.67.80 ～ 123.45.67.99 の範囲の IP アドレスだけを持つ場合は、次のようにします。

IP アドレスが特定の $(.../...) テストの条件に一致するかどうかを確認するには、/imsimta test -match ユーティリティが便利です。imsimta test -mapping ユーティリティは、さまざまな IP アドレス入力に対し、INTERNAL_IP マッピングテーブルが望ましい結果を返すかどうかを確認するのにも便利です。

INTERNAL_IP マッピングテーブルを編集したら、必ず imsimta restart コマンド (コンパイルされた設定で実行していない場合) またはimsimta refresh コマンド (コンパイルされた設定で実行している場合) を実行して、変更が適用されるようにします。

ファイルのマッピングと一般的なマッピングテーブルの形式、および imsimta コマンド行ユーティリティについては、『Messaging Server Reference Manual』を参照してください。

外部サイトの SMTP リレーを許可する

前の項で説明したように、内部 IP アドレスはすべて INTERNAL_IP マッピングテーブルに追加しなければなりません。お使いのシステムまたはサイトで SMTP リレーを許可する場合は、SMTP リレーを許可する外部アドレスを内部アドレスとともに INTERNAL_IP マッピングテーブルに指定する方法がもっとも簡単です。

ただし、これらの外部システムを実際の内部システムやサイトと区別したい場合、たとえば、ログやほかの目的のために実際の内部システムとリレーを許可する外部システムを区別する場合は、ほかの方法でシステムを設定します。

1 つのアプローチとして、これらの外部システムからメッセージを受信する特別のチャネルを設定する方法があります。この設定を行うには、既存の tcp_internal チャネルに類似した tcp_friendly チャネルを tcp_friendly-daemon という正式のホスト名を使って作成します。また、リレーを許可する外部システムの IP アドレスをリストした、INTERNAL_IP マッピングテーブルと同類の FRIENDLY_IP マッピングテーブルを作成します。そして、現在の書き換えルールのすぐあとに新しい書き換えルールを追加します。現在の書き換えルールは次のようになっています。

! マッピング検索を内部 IP アドレスに対して実行する
[] $E$R${INTERNAL_IP,$L}$U%[$L]@tcp_intranet-daemon

! マッピング検索を外部 IP アドレスに対して実行する []
$E$R${FRIENDLY_IP,$L}$U%[$L]@tcp_friendly-daemon

もう 1 つのアプローチとして、ORIG_SEND_ACCESS マッピングテーブルの最後にある $N エントリの前に、次の形式の新しいエントリを追加する方法があります。

siroe.com は外部アドレスのドメインです。また、次に示すように、ORIG_MAIL_ACCESS マッピングテーブルにエントリを追加します。

ORIG_MAIL_ACCESS

   TCP|*|25|$(match-siroe.com-IP-addresses)|*|SMTP|MAIL|    ¥
tcp_local|*@siroe.com|tcp_local|*     $Y
   TCP|*|*|*|*|SMTP|MAIL|tcp_local|*|tcp_local|*    $N

$(...) の IP アドレスには、前の項で説明した構文を使用します。ORIG_SEND_ACCESS によるチェックは、アドレスが正常であれば完了します。このため、より厳密なチェック、つまり IP アドレスが siroe.com の IP アドレスに一致した場合にのみ成功する ORIG_MAIL_ACCESS によるチェックを行います。

SMTP リレーブロッキングを設定する

アクセス制御マップを使うことによって、Messaging Server システムが SMTP メールのリレーに利用されるのを防ぐことができます。たとえば、ユーザーのメールシステムを利用して何百、何千ものインターネットメールボックスにジャンクメールをリレーしようとする不正操作を阻止できます。

Messaging Server のデフォルトでは、ローカルの POP ユーザーおよび IMAP ユーザーによるリレーを含むすべての SMTP リレー操作が防止されます。

不正なリレーをブロックする一方、正しいローカルユーザーによるリレーを許可するには、2 つのクラスのユーザーを識別するように Messaging Server を設定する必要があります。たとえば、POP または IMAP を使用するローカルユーザーの場合、SMTP リレー操作は Messaging Server に依存しています。

SMTP リレーを阻止するには、以下のいずれかの操作を行う必要があります。

内部のホストとクライアントによる SMTP リレーを可能にするには、INTERNAL_IP マッピングテーブルに内部 IP アドレスまたはサブネットを追加します。

MTA による内部メールと外部メールの識別方法

メールのリレーアクティビティをブロックするためには、まず、メールが同じサイトで発信された内部メールなのか、インターネットからシステムを経由して再びインターネットに戻っていく外部メールなのかを MTA が識別できなければなりません。そして、前述のクラスを許可し、後述のクラスをブロックする必要があります。この識別は、受信用 SMTP チャネルに switchchannel キーワードを使うことで実現できます。通常、このチャネルは tcp_local であり、デフォルトで設定されています。

switchchannel キーワードは、SMTP サーバーが受信 SMTP 接続の実際の IP アドレスを調べるようにするものです。この IP アドレスは、Messaging Server によって、ドメイン内の SMTP 接続とドメイン外の接続とを識別するために書き換えルールとともに使用されます。その後、この情報は、内部と外部のメッセージトラフィックを分離するために使用されます。

以下で説明している MTA 設定では、デフォルトで、サーバーが内部と外部のメッセージトラフィックを識別できるように設定されています。

上記の設定により、ドメイン内で生成された SMTP メールは tcp_internal チャネルから入ってくるようになります。それ以外の SMTP メールは、tcp_local チャネルから入ってきます。したがって、メールが入ってくるチャネルに基づいて内部と外部のメールが識別されます。

この設定はどのように機能するのでしょうか。ここでもっとも重要な要素は switchchannel キーワードです。キーワードは、tcp_local チャネルに適用されます。このキーワードにより、SMTP サーバーにメッセージが入ってくると、サーバーが受信接続のソース IP アドレスを調べるようになります。サーバーは、受信接続のリテラル IP アドレスのリバースポインティングのエンベロープ書き換えを試行し、関連するチャネルを探します。ソース IP アドレスが INTERNAL_IP マッピングテーブル内の IP アドレスまたはサブネットと一致する場合は、そのマッピングテーブルを呼び出す書き換えルールによってアドレスが tcp_intranet チャネルに書き換えられます。

tcp_internal チャネルは allowswitchchannel キーワードでマークされているため、メッセージは tcp_internal チャネルに切り替えられて、そのチャネルから入ってきます。IP アドレスが INTERNAL_IP マッピングテーブルにないシステムからメッセージが入ってくる場合、リバースポインティングのエンベロープ書き換えは、tcp_local チャネルあるいはその他のチャネルに対して書き換えを行います。ただし、tcp_internal チャネルに対する書き換えは行われません。それ以外のチャネルはデフォルトで noswitchchannel とマークされているため、メッセージは別のチャネルに切り替えられず、tcp_local チャネルのまま処理されます。

認証ユーザーのメールを識別する


注	「tcp_local」という文字列を使用するマッピングテーブルまたは変換ファイルのエントリは、必要に応じて「tcp_*」または「tcp_intranet」に変更する必要があるかもしれないことに注意してください。

サイトには、物理的にネットワークの一部ではない「ローカル」のクライアントユーザーが存在することがあります。これらのユーザーがメールを送信すると、メッセージの送信は外部 IP アドレス (任意のインターネットサービスプロバイダ (ISP) など) から入ってきます。ユーザーが SASL 認証を処理できるメールクライアントを使用している場合には、外部接続と認証接続とを識別できます。その結果に基づいて、認証ユーザーによる送信を許可し、認証されていないユーザーによるリレー送信試行を拒否できます。認証されているかどうかに基づく接続の識別は、受信用 SMTP チャネル (通常、tcp_local チャネル) に saslswitchchannel キーワードを使うことで実現できます。

saslswitchchannel キーワードはチャネルの切り替え先を示す引数をとり、SMTP の差出人が認証されると、送信メッセージが指定した切り替え先チャネルから入ってくるようになります。

認証ユーザーによる送信であるかどうかを識別するには、以下のようにします。

この設定では、ローカルのパスワードによって認証が可能なユーザーが送信した SMTP メールは tcp_auth チャネルから入ってくるようになります。認証されていない SMTP メールが内部ホストから送信された場合、そのメールは tcp_internal から入ってきます。それ以外の SMTP メールは、すべて tcp_local から入ってきます。

メールのリレーを防止する

次の例では、無許可のユーザーが送信した SMTP メールのリレーをシステムが中継しないように設定しています。まず、ローカルユーザーによる SMTP メールのリレーは許可することを念頭におきます。たとえば、POP ユーザーおよび IMAP ユーザーは、メールの送信に Messaging Server を使います。ローカルユーザーには、メッセージが内部 IP アドレスから入ってくる物理的なローカルユーザーのほか、ローカルユーザーとして認証され得るリモートユーザーも含まれます。

サーバーにおけるリレーを阻止しなければならないのは、不特定多数のインターネット利用者からのメッセージです。以下の節で説明する設定では、これらのユーザークラスを識別して特定のクラスだけをブロックできます。特に、tcp_local チャネルから入り、同一のチャネルから出るメールをブロックします。そのためには、ORIG_SEND_ACCESS マッピングテーブルを使用します。

ORIG_SEND_ACCESS マッピングテーブルは、ソースチャネルと宛先チャネルに基づいてトラフィックをブロックするために使用できます。ここでは、tcp_local チャネルから入り、同一チャネルから出るトラフィックをブロックします。これは、次の ORIG_SEND_ACCESS マッピングテーブルで実現できます。

この例では、メッセージが tcp_local チャネルから入り、同一のチャネルから出ることは許可されないことを示しています。つまり、このエントリを使用すると、外部からのメールを SMTP サーバーで中継してインターネットに転送する処理を禁じることができます。

SEND_ACCESS マッピングテーブルではなく ORIG_SEND_ACCESS マッピングテーブルを使用するのは、ims-ms チャネルに元々一致するアドレスにブロックを適用するのではないからです (アドレスは、エイリアスまたはメーリングリストの定義を介して展開し、外部アドレスとなることがあるため)。SEND_ACCESS マッピングテーブルでは、外部の利用者が外部ユーザーに展開するメーリングリストにメールを送信したり、外部アドレスにメッセージを転送するユーザーにメールを送信できるようにするのは困難です。

SMTP リレーブロッキングの RBL チェックを含む DNS 検索を使用するには

Messaging Server には、配信や転送のために受け入れたすべてのメールが、有効な DNS 名を持つアドレスから送信されたものであるかどうかを確認するさまざまな方法があります。もっとも簡単な方法は、tcp_local チャネルに mailfromdnsverify チャネルキーワードを割り当てることです。

また Messaging Server には、dns_verify というプログラムが用意されています。このプログラムを使うと、配信や転送のために受け入れたすべてのメールが、次に示す ORIG_MAIL_ACCESS のルールを使った有効な DNS 名を持つアドレスから送信されたものであるかどうかを確認することができます。

上の例に示されている改行記号は、このようなマッピングエントリの構文において非常に重要なものです。円記号は、その行が次の行に続いていることを意味しています。

また、もう 1 つの UBE 対策として、dns_verify イメージを使用し、受信接続を RBL (Realtime Blackhole List)、MAPS (Mail Abuse Prevention System)、DUL (Dial-up User List)、ORBS (Open Relay Behavior-modification System) などのリストに対してチェックすることができます。また、新しい mailfromdnsverify キーワードの場合と同じように、dns_verify 呼び出しを行わなくてもこれらのチェックを実行できる簡単な方法があります。それは dispatcher.cnf ファイルで DNS_VERIFY_DOMAIN オプションを使用する方法です。たとえば、[SERVICE=SMTP] セクションで、オプションのインスタンスをチェック対象のリストに設定します。

[SERVICE=SMTP]
PORT=25
! ..通常のオプションの残りの部分...
DNS_VERIFY_DOMAIN=rbl.maps.vix.com
DNS_VERIFY_DOMAIN=dul.maps.vix.com
!...など...

この場合、メッセージは SMTP レベルで拒否されます。つまり、メッセージは SMTP ダイアログの間に拒否されることになり、MTA に送信されることはありません。この方法の短所は、内部ユーザーからのメッセージを含む、通常の SMTP 受信メッセージすべてに対してチェックが行われるということです。このため効率が下がり、インターネット接続が切断された場合に問題が発生することがあります。別の方法として、PORT_ACCESS マッピングテーブル、または ORIG_MAIL_ACCESS マッピングテーブルから dns_verify を呼び出す方法があります。PORT_ACCESS マッピングテーブルでは、最初の 1 つまたは複数のエントリに対してローカルの内部 IP アドレスまたはメッセージ送信者のチェックを行わないようにし、あとの方のエントリでほかのすべてに対して目的のチェックを行うようにすることができます。また、ORIG_MAIL_ACCESS マッピングテーブルでは、tcp_local チャネルで受信するメッセージのみをチェックする場合、内部システムやクライアントからのメッセージに対するチェックを省略することになります。以下に、dns_verify へのエントリポイントを使用した例を示します。

PORT_ACCESS

! 内部接続を無条件で許可する
*|*|*|*|* $C$|INTERNAL_IP;$3|$Y$E
! RBL リストに対するほかの接続をチェックする
TCP|*|25|*|* ¥
$C$[msg_svr_base/lib/dns_verify.so, ¥
dns_verify_domain_port,$1,rbl.maps.vix.com.]EXTERNAL$E

ORIG_MAIL_ACCESS

TCP|*|25|*|*|SMTP|*|tcp_local|*@*|*|* ¥
$C$[msg_svr_base/lib/dns_verify.so, ¥
dns_verify_domain,$1,rbl.maps.vix.com.]$E

DNS ベースデータベースのサポート

dns_verify プログラムは DNS ベースのデータベースをサポートします。このデータベースは、不特定多数宛のメールを送る可能性のある受信 SMTP 接続を判別するために使われます。一般に利用可能な DNS データベースの一部には、通常はこの目的のために使われる TXT レコードが含まれていません。その代わりに、A レコードが含まれています。

標準の設定では、特定の IP アドレスの DNS にある TXT レコードには、メッセージを拒否するときに SMTP クライアントに返すためのエラーメッセージが含まれています。しかし、TXT レコードがなく、A レコードがある場合、Messaging Server 5.2 より前のバージョンの dns_verify は「No error text available」というメッセージを返しました。

現在、dns_verify は、TXT レコードを利用できないイベントで使われるデフォルトのテキストを指定するオプションをサポートしています。たとえば、以下の PORT_ACCESS マッピングテーブルは、このオプションを有効にする方法を示しています。

PORT_ACCESS

    *|*|*|*|* $C$|INTERNAL_IP;$3|$Y$E ¥
    TCP|*|25|*|* ¥
$C$[<msg_svr_base/lib/dns_verify.so ¥
,dns_verify_domain_port,$1,dnsblock.siroe.com,Your$ host$ ($1)$ ¥
found$ on$ dnsblock$ list]$E
    * $YEXTERNAL

この例では、リモートシステムがドメイン dnsblock.siroe.com 内のクエリーで見つかっても、TXT レコードが利用できない場合は、「Your host a.b.c.d found on dnsblock list」というメッセージが返されます。

多数のアクセスエントリを処理する

マッピングテーブルに非常に多くのエントリを使用するサイトでは、マッピングテーブルを組織化し、特定の参照に対して一般的なデータベースを呼び出す一般的なワイルドカードエントリを利用するとよいでしょう。特定の参照に対し、2 ～ 3 件のマッピングテーブルエントリから一般的なデータベースを呼び出すほうが、数多くのエントリを直接マッピングテーブルで処理するよりもはるかに効率的です。

その一例として、だれがインターネットの電子メールを送信または受信できるのかをユーザーごとに制御するサイトがあります。そのような制御は、ORIG_SEND_ACCESS などのアクセスマッピングテーブルを使って簡単に適用できます。この場合、一般的なデータベースに特定の情報 (たとえば特定のアドレスなど) をまとめて保存し、マッピングテーブルのエントリで呼び出すように設定すれば、効率と性能がかなり向上します。

たとえば、次に示す ORIG_SEND_ACCESS マッピングテーブルの場合を考えてみます。

このように、ユーザーごとに個々のエントリを記述したマッピングテーブルを使用するのではなく、より効率的な設定 (何百、何千件ものユーザーを効率的に処理できる設定) を次の例で示します。この例では、一般データベースのソーステキストファイルのサンプルおよび ORIG_SEND_ACCESS マッピングテーブルのサンプルを示します。このソースファイルをデータベースのフォーマットにコンパイルするには、imsimta crdb コマンドを実行します。

imsimta crdb ユーティリティの詳細については、『Sun Java System Messaging Server Administration Reference』を参照してください。

この例では、一般的なデータベースの左側に記述した文字列「SEND|」および「RECV|」を使用 (マッピングテーブルで生成される一般的なデータベースプローブ) することにより、2 種類のプローブを区別しています。一般的なデータベースプローブを「$C」および「$E」フラグで囲むのは、マッピングテーブルから一般的なデータベース呼び出しに特有の方法です。

この例では、単純なマッピングテーブルプローブが一般的なデータベースのエントリを参照するケースを示しています。より複雑なプローブのマッピングテーブルでも一般的なデータベースの使用による効果を得ることができます。

アクセス制御マッピングテーブルのフラグ

表 17-3 に、SEND_ACCESS、ORIG_SEND_ACCESS、MAIL_ACCESS、ORIG_MAIL_ACCESS、および FROM_ACCESS マッピングテーブルに関連するアクセスマッピングフラグを示します。PORT_ACCESS マッピングテーブルでは、少し異なるフラグがサポートされています (表 17-2 を参照)。

表 17-3 アクセスマッピングフラグ
フラグ	説明
$B	ビットバケットにメッセージをリダイレクトする
$H	.HELD ファイルとしてメッセージを保留する
$Y	アクセスを許可する
フラグと引数 (引数の読み取り順序 +)
$Jaddress	元のエンベロープの From: アドレスを指定の address に置換する*
$Kaddress	元のエンベロープの Sender: アドレスを指定の address に置換する* ++
$Iuser\|identifier	特定のユーザーのグループ ID を調べる
$<string	プローブが一致する場合、string を syslog (UNIX、user.notice 機能と重大度) またはイベントログ (NT) に送る +++
$>string	アクセスが拒否された場合、string を syslog (UNIX、user.notice 機能と重大度) またはイベントログ (NT) に送る +++ +++
$Ddelay	応答を delay (100 分の 1 秒) だけ遅らせる。正の値の場合、トランザクションでの各コマンド時にこの遅延が適用され、負の値の場合、アドレスの引き渡し時 (FROM_ACCESS テーブルの SMTP MAIL FROM: コマンド、その他のテーブルの SMTP RCPT TO: コマンド) にのみこの遅延が適用される
$Ttag	tag を前に付ける
$Aheader	メッセージにヘッダー行 header を追加する
$Xerror-code	メッセージを拒否した場合に、指定した error-code を含む拡張 SMTP エラーコードを発行する
$Nstring	アクセスを拒否し、オプションのエラーテキスト string を送る
$Fstring	$N string と同じ。アクセスを拒否し、オプションのエラーテキスト string を送る
FROM_ACCESS テーブルでのみ使用できます。 + 引数を伴うフラグを複数個使用する場合は、引数を縦棒文字「\|」で区切り、この表に示されている順序で配置します。 $K フラグを FROM_ACCESS マッピングテーブルで有効にするには、ソースチャネルに authrewrite キーワードが含まれていなければなりません。 +++ 問題のある差出人によるサービスアタックを防ぐには $D フラグを使用するとよいでしょう。特に、$> エントリまたはアクセスを拒否する $< エントリで $D フラグを使用します。

第 2 部メールボックスフィルタ

メールボックスフィルタは、メッセージヘッダーにある文字列に基づいてメールメッセージに適用する指定アクションのセットです。Messaging Server のフィルタはサーバー上に保存されてサーバーによって評価されるため、サーバー側ルール (SSR) と呼ばれることがあります。Messaging Server のフィルタは、SIEVE Internet Draft の Draft 9 である SIEVE フィルタリング言語に基づいています。SIEVE フィルタと呼ばれることもあります。

Sieve フィルタリングの概要

SIEVE フィルタは、メールメッセージに適用される 1 つまたは複数の (メッセージヘッダーにある文字列によって異なる) 条件付きアクションで構成されています。Messaging Server フィルタはサーバーに保存され、サーバーによって評価されます。そのため、それらは SSR (サーバー側ルール) と呼ばれることもあります。Messaging Server のフィルタは、SIEVE Internet Draft の Draft 9 である SIEVE フィルタリング言語に基づいています。

管理者は、チャネルレベルのフィルタと MTA 全体のフィルタを作成し、不正メールの配信を防止できます。ユーザーは Messenger Express を使用して、自分のメールボックスにユーザー単位のフィルタを作成できます。この具体的な手順については、Messenger Express のオンラインヘルプを参照してください。

サーバーは、次の優先順位に従ってフィルタを適用します。

ユーザーレベルのフィルタ

個人用メールボックスフィルタにメッセージの許可あるいは拒否が定義されている場合は、メッセージに対してそのフィルタ処理が行われます。しかし、受取人がメールボックスフィルタを設定していない場合、またはユーザーのメールボックスフィルタが適用されないメッセージの場合、Messaging Server によってチャネルレベルのフィルタが適用されます。ユーザー単位のフィルタが設定されます。

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

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

MTA 全体のフィルタ

デフォルト設定を使用した場合、それぞれのユーザーはメールボックスフィルタを所有していません。ユーザーが Messenger Express のインタフェースを使用して 1 つまたは複数のフィルタを作成すると、それらのフィルタがディレクトリに保存され、ディレクトリの同期処理時に MTA によって読み取られます。

ユーザーレベルのフィルタを作成するには

ユーザー単位のフィルタは、特定ユーザーのメールボックスに送信されるメッセージに適用されます。ユーザー単位のメールフィルタは、Messenger Express のみで作成できます。

チャネルレベルのフィルタを作成するには

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

チャネルレベルのフィルタを作成する手順を以下に示します。

destinationfilter チャネルキーワードは、対象チャネルのキューに入るメッセージのフィルタリングを有効にします。sourcefilter チャネルキーワードは、対象チャネルからキューに入るメッセージのフィルタリングを有効にします。これらのキーワードには、それぞれパラメータが 1 つ必要です。このパラメータは、そのチャネルに関連付けられたチャネルフィルタファイルへのパスを指定するものです。

destinationfilter チャネルキーワードの構文は以下のとおりです。

URL-pattern は、対象チャネルのフィルタファイルへのパスを示す URL です。次の例で、channel-name はチャネルの名前です。

filter チャネルキーワードは、対象チャネルにおけるメッセージのフィルタリングを有効にします。このキーワードには、パラメータが 1 つ必要です。このパラメータは、そのチャネルを介してメールを受信するエンベロープの各受取人に関連付けられたチャネルフィルタファイルへのパスを指定するものです。

URL-pattern は、特殊な置換シーケンスを処理したあとの URL で、指定した受取人アドレスに対するフィルタファイルへのパスを示します。URL-pattern には、特殊な置換シーケンスを含めることができます。このシーケンスは、受取人アドレス local-part@host.domain から派生する文字列に置き換えられます。表 17-4 に、これらの置換シーケンスを示します。

fileinto キーワードは、メールボックスフィルタの fileinto 演算子が適用されたときにアドレスをどのように変更するのかを指定するものです。次の例では、フォルダ名をサブアドレスとして元のアドレスに挿入して、元のサブアドレスを置き換えるように指定しています。

表 17-4 filter チャネルキーワードの URL パターン置換タグ (大文字と小文字の区別なし)
タグ	意味
*	グループの拡張を実行する
**	mailForwardingAddress 属性を拡張する。複数の値を持つ属性を設定して複数の配信先アドレスを生成できる
$$	$ 文字に置き換える
$¥	後続のテキストを小文字にする
$^	後続のテキストを大文字にする
$_	後続のテキストで大文字と小文字を変換しない
$~	アドレスのローカル部分に関連付けられたホームディレクトリに対するファイルパスに置き換える
$1S	$S と同じだが、サブアドレスがない場合は何も行わない
$2S	$S と同じだが、サブアドレスがない場合は何も挿入せず前の文字を削除する
$3S	$S と同じだが、サブアドレスがない場合は何も挿入せず後続の文字を無視する
$A	アドレス (ローカル部分 @ ホストドメイン) に置き換える
$D	ホストドメインに置き換える
$E	第 2 スペア属性の値 LDAP_SPARE_1 を挿入する
$F	配信ファイル名 (mailDeliveryFileURL 属性) を挿入する
$G	第 2 スペア属性の値 LDAP_SPARE_2 を挿入する
$H	ホストに置き換える
$I	ホストしているドメインを挿入する (domainUidSeparator で指定した区切り文字の右側に UID の一部を挿入)。ホストしているドメインがないと失敗する
$1I	$I と同じだが、ホストしているドメインがない場合は何も挿入しない
$2I	$I と同じだが、ホストしているドメインがない場合は何も挿入せず前の文字を削除する
$3I	$I と同じだが、ホストしているドメインがない場合は何も挿入せず後続の文字を無視する
$L	ローカル部分に置き換える
$M	UID を挿入し、ホストしているドメインを削除する
$P	メソッド名を挿入する (mailProgramDeliveryInfo 属性)
$S	現在のアドレスに関連づけられたサブアドレスを挿入する。サブアドレスは、元のアドレスでサブアドレス区切り (通常は +) に続くユーザー部分の該当する箇所。ただし、MTA オプションの SUBADDRESS_CHAR で指定することもできる。サブアドレスを指定しないと失敗する
$U	現在のアドレスのメールボックス部分を挿入する。@ マークの左側のアドレス全体、またはその中でサブアドレス区切りの + より前の部分のいずれかが挿入される

MTA 全体のフィルタを作成するには

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

コンパイルした設定を使用する場合、MTA 全体のフィルタファイルはコンパイルされた設定内に組み込まれています。

FILTER_DISCARD チャネルから破棄メッセージをルーティングする

デフォルトでは、メールボックスフィルタで破棄されたメッセージは、システムから即座に破棄 (削除) されます。しかし、ユーザーが最初にメールボックスフィルタを設定した場合 (設定が間違っている場合)、またはデバッグを目的とする場合には、削除処理を遅らせると便利です。

メールボックスフィルタによる破棄メッセージをシステム内に一時保存し、それをあとで削除できるようにするには、次の例に示すように、まず MTA 設定に filter_discard チャネルを追加し、notices チャネルキーワードでメッセージを削除するまでの保存期間 (通常は日数) を記述します。

次に MTA オプションファイルで FILTER_DISCARD=2 オプションを設定します。filter_discard キュー内のメッセージは、ユーザーの個人用ゴミ箱フォルダの延長と考えることができます。したがって、filter_discard キュー内のメッセージに対して警告メッセージが送られたり、バウンスやリターンの要求に応じてメッセージが差出人に戻されることもありません。これらのメッセージは、final notices 値の期限となるか、imsimta return などのユーティリティを使ってバウンスを要求することによって、システムから削除されるだけです。

ユーザーレベルのフィルタをデバッグするには

以下の情報は、システムのユーザーフィルタに関して問題が発生した場合に役に立ちます。

MTA の SSR データベースのユーザーフィルタに関する情報は自動的に更新されます。短いフィルタは、データベース内に保存されます。長いフィルタの場合は、データベースに LDAP dn が保存されます。

フィルタに関する問題を解決するには、以下の手順に従ってください。

前へ目次索引次へ
Sun Java System Messaging Server 6 2004Q2 管理ガイド