前へ    目次    索引    次へ
iPlanet Messaging Server 5.1 管理者ガイド

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


この章では、メールサービスへのアクセス制御方法、およびマッピングテーブルと SSR （サーバ側規則） を使ったメールのフィルタリング方法について説明します。

システムレベルで特定の差出人または宛先のメールを拒否したり、特定のユーザ間のメッセージトラフィックに複雑な規制を設けたり、あるいはユーザ自身が受信メッセージのフィルタリング（メッセージヘッダの内容に基づくメッセージ拒否など）を設定したいことがあります。

エンベロープレベルの制御が望ましい場合には、マッピングテーブルを使ってメールをフィルタリングできます。ヘッダベースの制御が望ましい場合、またはユーザによる独自の制御設定には、サーバ側規則を使った一般的なメールのフィルタリングアプローチが適切です。

この章は、以下の 2 つの部分から構成されています。

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

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


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


第 1 部には、以下の節があります。


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

メールサービスへのアクセスを制御するには、マッピングテーブルを使用します。マッピングテーブルを使用することにより、誰がメールを送信または受信できるのか、あるいは送受信できるのかを制御することができます。マッピングファイルの一般的な情報および使用方法については、『Messaging Server リファレンスマニュアル』を参照してください。

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

表 9-1 マッピングテーブル


マッピングテーブル

説明

SEND_ACCESS

エンベロープの From アドレス、エンベロープの To アドレス、ソースチャネルと宛先チャネルに基づいて受信接続をブロックする場合に使用します。書き換え、エイリアス展開などの処理が行われてから To アドレスを調べます。

「SEND_ACCESS テーブルと ORIG_SEND_ACCESS テーブル」を参照。

ORIG_SEND_ACCESS

エンベロープの From アドレス、エンベロープの To アドレス、ソースチャネルと宛先チャネルに基づいて受信接続をブロックする場合に使用します。書き換えの後、エイリアス展開の前に To アドレスを調べます。

「SEND_ACCESS テーブルと ORIG_SEND_ACCESS テーブル」を参照。

MAIL_ACCESS

SEND_ACCESS テーブルと PORT_ACCESS テーブルを組み合せた情報に基づいて受信接続をブロックする場合に使用します。SEND_ACCESS のチャネルとアドレス、および PORT_ACCESS の IP アドレスとポート番号に関する情報が基準となります。

「MAIL_ACCESS マッピングテーブルと ORIG_MAIL_ACCESS マッピングテーブル」を参照。

ORIG_MAIL_ACCESS

ORIG_SEND_ACCESS テーブルと PORT_ACCESS テーブルを組み合せた情報に基づいて受信接続をブロックする場合に使用します。ORIG_SEND_ACCESS のチャネルとアドレス、および PORT_ACCESS の IP アドレスとポート番号に関する情報が基準となります。

「MAIL_ACCESS マッピングテーブルと ORIG_MAIL_ACCESS マッピングテーブル」を参照。

FROM_ACCESS

エンベロープの From アドレスに基づいてメールをフィルタリングする場合に使用します。To アドレスとは無関係に処理を行うときにこのテーブルを使用します。

「FROM_ACCESS マッピングテーブル」を参照。

PORT_ACCESS

IP 番号に基づいて受信接続をブロックする場合に使用します。

「PORT_ACCESS マッピングテーブル」を参照。

最も一般的なのは、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

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 などのチャネルからメッセージをインターネットに出力するケースを示すものです。postmaster 以外のローカルユーザは、インターネットからメールを受信できても送信は許可されていないと仮定します。そのような制御を行う 1 つの手段として、図 9-1に示している SEND_ACCESS マッピングテーブルの使用があります。このマッピングテーブルの例では、ローカルのホスト名が sesta.com であると想定しています。チャネル名「tcp_*」ではワイルドカードを使って任意の TCP/IP チャネル名 （たとえば tcp_local） と一致するようにしています。

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

図 9-1 SEND_ACCESS マッピングテーブル
SEND_ACCESS

  *|postmaster@sesta.com|*|*    $Y
  *|*|*|postmaster@sesta.com    $Y
  l|*@sesta.com|tcp_*|*         $NInternet$ postings$ are$ not$ \
    permitted


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



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

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

port-access-probe-info|app-info|submit-type|send_access-probe-info

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

port-access-probe-info|app-info|submit-type|orig_send_access-probe-info

上記の port-access-probe-info は、受信 SMTP メッセージの場合、PORT_ACCESS マッピング テーブルプローブに通常含まれているすべての情報から成ります。それ以外の場合は空白です。app-info は、SMTP 経由で送信されたメッセージの場合は通常 SMTP となり、それ以外の場合は空白です。submit-type は、MAIL、SEND、SAML、あるいは SOML のいずれかであり、メッセージが Messaging Server に送られてきた方法に対応します。通常、この値は、メッセージとして送信されたことを表す MAIL です。SEND、SAML、または SOML は、ブロードキャストリクエスト （あるいはブロードキャストとメッセージを組み合せたリクエスト） が SMTP サーバに送信された場合の値です。MAIL_ACCESS マッピングの send-access-probe-info は、SEND_ACCESS マッピングテーブル プローブに通常含まれているすべての情報から成ります。同様に、ORIG_MAIL_ACCESS マッピングの orig-send-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 を表示するようなサイトでは、図 9-2に示すMAIL_ACCESS マッピング テーブルを使用します。

図 9-2 MAIL_ACCESS マッピングテーブル
MAIL_ACCESS

  ! Entries for vip's two systems
  !
  TCP|*|25|1.2.3.1|*|SMTP|MAIL|tcp_*|vip@siroe.com|*|* $Y
  TCP|*|25|1.2.3.2|*|SMTP|MAIL|tcp_*|vip@siroe.com|*|* $Y
  !
  ! Disallow attempts to use vip's From: address from other
  ! systems
  !
  TCP|*|25|*|*|SMTP|MAIL|tcp_*|vip@siroe.com|*|* \
      $N500$ Not$ authorized$ to$ use$ this$ From:$ address
  !
  ! Allow sending from within our subnet with siroe.com From:
  ! addresses
  !
  TCP|*|25|1.2.*.*|*|SMTP|MAIL|tcp_*|*@siroe.com|*|* $Y
  !
  ! Allow notifications through
  !
  TCP|*|25|1.2.*.*|*|SMTP|MAIL|tcp_*||*|* $Y
  !
  ! Block sending from within our subnet with non-siroe.com
  ! addresses
  !
  TCP|*|25|1.2.*.*|*|SMTP|MAIL|tcp_*|*|*|* \
      $NOnly$ siroe.com$ From:$ addresses$ authorized


FROM_ACCESS マッピングテーブル

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

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

port-access-probe-info|app-info|submit-type|src-channel|from-address|auth-from

この場合の port-access-probe-info は、受信 SMTP メッセージの場合、PORT_ACCESS マッピングテーブルプローブに通常含まれているすべての情報から成ります。それ以外の場合は空白です。app-info は、SMTP 経由で送信されたメッセージの場合は通常 SMTP となり、それ以外の場合は空白です。submit-type は、MAIL、SEND、SAML、あるいは SOML のいずれかであり、メッセージが 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 アドレスを最初のものから認証アドレスに置き換えることができます。
FROM_ACCESS

  *|SMTP|*|tcp_local|*|       $Y
  *|SMTP|*|tcp_local|*|*      $Y$J$3

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

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

  *|SMTP|*|tcp_local|*|     $Y
  *|SMTP|*|tcp_local|*|*    $Y$K$3

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

図 9-3 FROM_ACCESS マッピングテーブル
FROM_ACCESS

  ! If no authenticated address is available, do nothing
  *|SMTP|*|tcp_local|*| $Y
  ! If authenticated address matches envelope From:, do nothing
  *|SMTP|*|tcp_local|*|$2* $Y
  ! If authenticated address matches envelope From: sans
  ! subaddress, do nothing
  *|SMTP|*|tcp_local|*+*@*|$2*@$4* $Y
  ! Fall though to...
  ! ...authenticated address present, but didn't match, so force
  ! Sender: header
  *|SMTP|*|tcp_local|*|* $Y$K$3


PORT_ACCESS マッピングテーブル

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

TCP|サーバ-アドレス|サーバ-ポート|クライアント-アドレス|クライアント-ポート

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

「$<」フラグにオプションの文字列が続いており、マッピングプローブが一致しなかった場合は、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 つと適切なテキストを挿入します。表 9-2 に、使用可能なフラグを示します。


表 9-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

  TCP|*|25|192.123.10.70|*  $N500
  TCP|*|25|192.123.10.*|*   $Y
  TCP|*|25|*|*              $N500$ Bzzzt$ thank$ you$ for$ \
     playing.

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 接続を制限するためのものです。以下に示すように、設定オプションはすべて、接続スロットル共有ライブラリ (conn_throttle.so) に対するパラメータとして指定します。

$[<server-root>/lib/conn_throttle.so,throttle,IP-address,max-rate]

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

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

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

1 分当たりの最大接続数を超過した場合、共有ライブラリのコールアウトは成功しますが、値は返されません。この動作は $C と $E の組み合わせによって制御されます。以下に、その例を示します。

PORT_ACCESS

  TCP|*|25|*|* \
$C$[<server-root>/lib/conn_throttle.so,throttle,$1,10] \
$N421$ Connection$ not$ accepted$ at$ this$ time$E

説明:

$C は、次のテーブルエントリからマッピングプロセスを続行させます。つまり、現在のエントリの出力文字列を、マッピングプロセスの新しい入力文字列として使用します。

$[<server-root>/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 オプション) は、アクセス制御マッピングのテストに役立ちます。例として、図 9-4 に、サンプルの SEND_ACCESS マッピングテーブルとその結果としてのプローブを示します。

図 9-4 サンプルの SEND_ACCESS マッピングテーブルおよびプローブ
マッピングテーブル

SEND_ACCESS

  tcp_local|friendly@siroe.com|l|User@sesta.com     $Y
  tcp_local|unwelcome@varrius.com|l|User@sesta.com  $NGo$ away!

プローブ

$ TEST/REWRITE/FROM="friendly@siroe.com" -
_$ /SOURCE=tcp_local/DESTINATION=l User@sesta.com
...
Submitted address list:
l
    User (SESTA.COM) *NOTIFY FAILURES* *NOTIFY DELAYS* Submitted notifications list:


$ TEST/REWRITE/FROM="unwelcome@varrius.com" -
_$ /SOURCE=tcp_local/DESTINATION=l User@sesta.com
...
Submitted address list:
Address list error -- 5.7.1 Go away! User@sesta.com

Submitted notifications list:


SMTP リレーを追加する


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

IMAP クライアントと POP クライアントが システムの SMTP サーバを経由して外部アドレス宛てのメッセージを送信しようとしても、SMTP AUTH (SASL) を使って認証を受けていない場合は、そのメッセージ送信は拒否されます。このため、自分の内部システムや内部サブネットが外部システムとみなされないように (そこからのリレーが必ず許可されるように)、設定を変更した方がよいでしょう。

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

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

   $(123.45.67.89/32)   $Y
   127.0.0.1   $Y
   *   $N

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

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

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

   $(123.45.67.89/24)   $Y
   127.0.0.1   $Y
   *   $N

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

! Match IP addresses in the range 123.45.67.80-123.45.67.95
   $(123.45.67.80/28)   $Y
! Match IP addresses in the range 123.45.67.96-123.45.67.99
   $(123.45.67.96/30)   $Y
   127.0.0.1   $Y
   *   $N

IP アドレスが特定の $(.../...) テストの条件に一致するかどうかを検査するには、<InstanceRoot>/imsimta test -match ユーティリティが便利です。このユーティリティは、さまざまな IP アドレス入力に対して、INTERNAL_IP マッピングテーブルが望ましい結果を返すかどうかを検査したいときに役立ちます。

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

ファイルのマッピングと一般的なマッピングテーブルの形式および imsimta コマンドラインユーティリティの詳細については、『iPlanet Messaging Server リファレンスマニュアル』を参照してください。


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

前の項で説明したように、内部 IP アドレスはすべて INTERNAL_IP マッピングテーブルに追加しなければなりません。同一組織内または信用できるシステムやサイトがあり、そこからのSMTP リレーを許可したい場合は、そのシステムやサイトを自分の内部 IP アドレスとともに INTERNAL_IP マッピングテーブルに指定する方法が最も簡単です。

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

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

! Do mapping lookup for internal IP addresses []
$E$R${INTERNAL_IP,$L}$U%[$L]@tcp_intranet-daemon

次の新しい書き換え規則を追加します。

! Do mapping lookup for "friendly", non-internal IP addresses []
$E$R${FRIENDLY_IP,$L}$U%[$L]@tcp_friendly-daemon

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

  tcp_local|*@siroe.com|tcp_local|*    $Y

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 リレーを可能にするには、INTERVAL_IP マッピングテーブルに内部 IP アドレスまたはサブネットを追加します。


内部メールと外部メールを識別する

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

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

以下の手順では、サーバが内部と外部のメッセージトラフィックを識別できるように MTA 設定を変更する方法について説明します。

  1. 設定ファイルで、ローカルストアチャネルを見つけます。次の例のように、ローカルチャネルの直前に defaults チャネルを追加し、noswitchchannel キーワードを挿入します。

    ! final rewrite rules
    defaults noswitchchannel
    ! Local store
    ims-ms ...

    既に設定ファイルの該当位置に defaults チャネルがある場合は、そこにキーワード noswitchchannel だけを挿入します。

  2. 受信 TCP/IP チャネルを変更し、switchchannel および remotehost キーワードを指定します。例：

    tcp_local smtp single_sys mx switchchannel remotehost
    TCP-DAEMON

  3. 受信 TCP/IP チャネル定義の後に、同様の新しいチャネルを別の名前で追加します。以下に例を示します。

    tcp_internal smtp single_sys mx allowswitchchannel routelocal
    TCP-INTERNAL

    routelocal チャネルキーワードは、ソースルートアドレスを短絡的に書き換えるために使用されます。これにより、明示されたソースルートアドレスを経由した内部 SMTP ホストのループによるリレー試行がブロックされます。

  4. ドメインのルートホストと IP アドレスの書き換え規則を tcp_internal チャネルに追加します。たとえば、ドメイン名が sesta.com で、ドメインの IP 番号が [a.b.subnet] の範囲である場合は、設定ファイルの冒頭に以下の書き換え規則を追加します。

    .sesta.com      $U%$H$D@TCP-INTERNAL
    [a.b.]           $U%[a.b.$L]@TCP-INTERNAL$E$R

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

さて、この設定はどのように機能するのでしょうか。ここで最も重要な要素は switchchannel キーワードです。手順 2 で、このキーワードが tcp_local チャネルに適用されています。このキーワードにより、SMTP サーバにメッセージが入ってくると、サーバが受信接続のソース IP アドレスを調べるようになります。サーバは、受信接続のリテラル IP アドレスのリバースポインティングのエンベロープ書き換えを試行し、関連するチャネルを探します。その書き換えがローカルホストと一致する場合は、手順 4 で追加した書き換え規則に従って、手順 3 で追加された tcp_internal チャネルに書き換えられます。

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

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



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

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

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

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

  1. 設定ファイルに新しい TCP/IP チャネル定義を別の名前で追加します。以下に例を示します。

    tcp_auth smtp single_sys mx mustsaslserver noswitchchannel
    TCP-INTERNAL

    このチャネルでは、通常のチャネル切り替えは行われません。それよりも前のデフォルト行で、noswitchchannel が明示あるいは暗黙に指定されているはずです。このチャネルには mustsaslserver が必要です。

  2. 次の例のように、maysaslserver と saslswitchchannel tcp_auth を追加することにより、tcp_local チャネルを変更します。

    tcp_local smtp mx single_sys maysaslserver saslswitchchannel tcp_auth \
    switchchannel
    |TCP-DAEMON

この設定では、ローカルのパスワードによって認証が可能なユーザが送信した 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 マッピングテーブルで実現できます。

ORIG_SEND_ACCESS

   tcp_local|*|tcp_local|*        $NRelaying$ not$ permitted

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

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


SMTP ポートへのローカルホスト送信を許可する

ここでは、前述の SMTP リレーブロック手法をさらに追求します。

特定のサイトでは、クライアントが動作しているシステムから SMTP ポートへの送信を禁止したいことがあります。たとえば、正当な手段でそのような処理が行われない場合は、その送信をブロックすることで、偽造電子メールの経路を遮断できます。

しかし、他のサイトでは、システムの SMTP ポートに TCP/IP 接続を確立することによりメッセージの送信を許可している場合があるかもしれません。たとえば、サードパーティによるメーリングリストエクスパンション （Messaging Server 独自のメーリングリストエクスパンション以外） の中には、そのような方法で機能するものがあります。

さらに、そのような応用では設定を簡素化するために、システムのドメイン名ではなく、LOCALHOST や [127.0.0.1] などのようなループバック名やアドレスを使って接続することがあります。基礎となる TCP/IP パッケージによっては、受信接続が、システムで特定されているドメイン名や IP アドレスから入ってくるのではなく、LOCALHOST や [127.0.0.1] から入ってくるように見えることもあります。

単に内部と外部の接続を識別する方法 (前述) では、ホストシステム上のクライアントからの SMTP 送信は tcp_local チャネルから入ってくるようになります。したがって、tcp_local から tcp_local へのメッセージトラフィックが禁止されると、そのような方法でメッセージを送信しようとするユーザやアプリケーションは外部アドレス宛にメッセージを送信できなくなります。

そのような送信を「内部」送信として処理するには （たとえば、SMTP リレーブロッキングが適用されたにもかかわらず、サードパーティによるメーリングリストアプリケーションの実行を許可する場合）、さらに設定を追加しなければなりません。

MTA 設定ファイルの冒頭に、ローカルホスト名 （基礎となる TCP/IP パッケージが接続ソースのどこを見るかによって異なるが、LOCALHOST または [127.0.0.1]） の書き換え規則を以下の形式で追加します。
localhostname           $E$R$U%localhostname@TCP-INTERNAL
[localhostipnumber]     $E$R$U%localhostname@TCP-INTERNAL
LOCALHOST               $E$R$U%localhostname@TCP-INTERNAL
[127.0.0.1]             $E$R$U%localhostname@TCP-INTERNAL

localhostname は ims-ms チャネルの正式なホスト名です。

これらの書き換え規則内の「$E」および「$R」コントロールシーケンスは、エンベロープの From: アドレス書き換えの効果を制限するもので、ローカルシステム宛のアドレスには標準の書き換え規則が適用されることを意味します。しかし、switchchannel 書き換えもこれらの規則を使用するため、メッセージをシステムからそのシステム自体の SMTP ポートに送る内部送信が可能となります。


SMTP リレーブロッキングに対する RBL 検査を含む DNS 検索を使用する

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

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

  TCP|*|*|*|*|SMTP|MAIL|*|*@*|*|*    \
     $[<server-root>/bin/msg/imta/lib/dns_verify,     \
    dns_verify,$6|$$y|$$NInvalid$ host:$ $$6$ -$ %e]

上の例に示されている改行は、このようなマッピングエントリの構文では非常に重要な意味を持ちます。バックスラッシュ (または円記号) は、その行が次の行に続いていることを意味しています。

もう 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
! ...rest of normal options...
DNS_VERIFY_DOMAIN=rbl.maps.vix.com
DNS_VERIFY_DOMAIN=dul.maps.vix.com
!...etc...

この方法の短所は、内部ユーザからのメッセージを含む、通常の SMTP 受信メッセージすべてに対して検査が行われるということです。このため効率が下がり、インターネット接続が切断された場合に問題が発生することがあります。この他の方法として、PORT_ACCESS マッピングテーブル、または ORIG_MAIL_ACCESS マッピングテーブルから dns_verify をコールアウトする方法があります。PORT_ACCESS マッピングテーブルでは、先頭から数えていくつかのエントリでは、ローカルの内部 IP アドレスまたはメッセージ送信者の検査を行わないようにし、それ以降のエントリではすべての項目について検査を行うようにすることができます。また、ORIG_MAIL_ACCESS マッピングテーブルでは、tcp_local チャネルに着信したメッセージのみを検査することにした場合、内部システムまたはクライアントからのメッセージに対する検査を省略することになります。以下に、dns_verify へのエントリポイントを使用した例を示します。

PORT_ACCESS

! Allow internal connections in unconditionally
  *|*|*|*|* $C$|INTERNAL_IP;$3|$Y$E
! Check other connections against RBL list
  TCP|*|25|*|*    \
      $C$[<server-root>/bin/msg/imta/lib/dns_verify,  \
dns_verify_domain_port,$1,rbl.maps.vix.com]EXTERNAL$E

ORIG_MAIL_ACCESS

  TCP|*|25|*|*|SMTP|*|tcp_local|*@*|*|*    \
      $C$[<server-root>/bin/msg/imta/lib/dns_verif,    \
      dns_verify_domain,$1,rbl.maps.vix.com]$E


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


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

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

たとえば、図 9-5 のマッピングテーブルを見てください。

図 9-5 ORIG_SEND_ACCESS マッピングテーブル
ORIG_SEND_ACCESS

  ! Users allowed to send to Internet
  !
  *|adam@siroe.com|*|tcp_local $Y
  *|betty@siroe.com|*|tcp_local $Y
  ! ...etc...
  !
  ! Users not allowed to send to Internet
  !
  *|norman@siroe.com|*|tcp_local $NInternet$ access$ not$
      permitted
  *|opal@siroe.com|*|tcp_local $NInternet$ access$ not$
      permitted
  ! ...etc...
  !
  ! Users allowed to receive from the Internet
  !
  tcp_*|*|*|adam@siroe.com $Y
  tcp_*|*|*|betty@siroe.com $Y
  ! ...etc...
  !
  ! Users not allowed to receive from the Internet
  !
  tcp_*|*|*|norman@siroe.com $NInternet$ e-mail$ not$
      accepted
  tcp_*|*|*|opal@siroe.com $NInternet$ e-mail$ not$
      accepted
  ! ...etc...


このように、ユーザごとに個々のエントリを記述したマッピングテーブルを使用するのではなく、より効率的な設定 （何百、何千件ものユーザを効率的に処理できる設定） を次の 図 9-6 に示します。この図には、一般的なデータベースエントリと ORIG_SEND_ACCESSマッピングテーブルが示されています。

図 9-6 データベースエントリとマッピングテーブルの例
データベースエントリ

SEND|adam@domain.com $Y
SEND|betty@domain.com $Y
! ...etc...
SEND|norman@domain.com $NInternet$ access$ not$ permitted
SEND|opal@domain.com $NInternet$ access$ not$ permitted
! ...etc...
RECV|adam@domain.com $Y
RECV|betty@domain.com $Y
! ...etc...
RECV|norman@domain.com $NInternet$ e-mail$ not$ accepted
RECV|opal@domain.com $NInternet$ e-mail$ not$ accepted


マッピングテーブル

ORIG_SEND_ACCESS

  ! Check if may send to Internet
  !
  *|*|*|tcp_local $C${SEND|$1}$E
  !
  ! Check if may receive from Internet
  !
  tcp_*|*|*|* $C${RECV|$3}$E

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

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


マッピングテーブルのフラグ


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

表 9-3 アクセスマッピングフラグ


フラグ

説明

$B

ビットバケットにメッセージをリダイレクトします。

$H

.HELD ファイルとしてメッセージを保留します。

$Y

アクセスを許可します。

フラグと引数（引数の読み取り順序+）

$Jアドレス

元のエンベロープ From: アドレスを指定のアドレスに置換します。*

$Kアドレス

元の Sender: アドレスを指定のアドレスに置換します。* ++

$Iユーザ|識別子

特定のユーザのグループ IDを調べます。

$<文字列

プローブが一致する場合に、文字列を システムログ （UNIX） またはイベント ログ （NT） に送ります。+++

$>文字列

アクセスが拒否された場合に、文字列を システムログ （UNIX） またはイベントログ （NT） に送ります。+++

$D遅延

応答を遅らせます （100 分の 1 秒）。正の値はトランザクションの各コマンドごとに遅らせ、負の値は、アドレスの引き渡し時 （FROM_ACCESS テーブルの SMTP MAIL FROM: コマンド、その他のテーブルの SMTP RCPT TO: コマンド） にのみ遅らせます。

$Tタグ

タグを前に付けます。

$Aヘッダ

メッセージにヘッダ行を追加します。

$Xエラーコード

メッセージを拒否した場合に、指定したエラーコードを含む拡張 SMTP エラーコードを発行します。

$N文字列

アクセスを拒否し、オプションのエラーテキスト文字列を渡します。

$F文字列

$N 文字列と同じで、アクセスを拒否し、オプションのエラーテキスト文字列を渡します。

* FROM_ACCESS テーブルでのみ使用できます。

+ 引数を伴うフラグを複数個使用する場合は、引数を縦棒文字「|」で区切り、この表に示されている順序で配置します。

++「$K」フラグを FROM_ACCESS マッピング テーブルで有効にするには、ソース チャネルに authrewrite キーワードが含まれていなければなりません。

+++ 問題のある差出人によるサービス アタックを防ぐには「$D」フラグを使用するとよいでしょう。特に、$> エントリまたはアクセスを拒否する $< エントリで「$D」フラグを使用します。


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


第 2 部には、以下の項目があります。


概要

フィルタは、メールメッセージに適用する 1 つまたは複数の条件から構成されています。Messaging Server フィルタはサーバに保存され、サーバによって評価されます。そのため、それらは SSR （サーバ側規則） と呼ばれることもあります。Messaging Server のフィルタは、Sieve Internet Draft の Draft 9 である Sieve フィルタリング言語に基づいています。

管理者は、チャネルレベルのフィルタと MTA 全体のフィルタを作成し、不正メールの配信を防止できます。また、フィルタテンプレートを作成し、Delegated Administrator for Messaging のインターフェースを介してエンドユーザが利用できるようにすることも可能です。エンドユーザは、テンプレートを利用して個人用のメールボックスフィルタを構築し、受け取りたくないメールメッセージの受信を拒否できます。

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

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

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

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

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

  3. MTA 全体のフィルタ

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


ユーザ単位のフィルタを作成する


ユーザ単位のフィルタは、特定ユーザのメールボックスに送信されるメッセージに適用されます。管理者は、フィルタテンプレートを作成し、Delegated Administrator for Messaging のインターフェースを介してそのテンプレートをエンド ユーザに提供できます。エンドユーザはテンプレートを利用して個人用サーバフィルタを構築し、メールボックスへのメールメッセージ配信を制御できます。つまり、特定のメールメッセージの受信を拒否したり、メールをリダイレクトしたり、あるいはメールボックスフォルダに入れるメッセージをフィルタリングすることができます。

フィルタテンプレートは、Sieve スクリプトのハードコード要素をプロンプトや入力フィールドに置換することで、Sieve スクリプトを一般化したものです。Java servlet は、Sieve テンプレートを解析し、ブラウザで UI ページを生成するために使用されます。エンドユーザが入力フィールドに値を入力すると、Servlet によってそれらの値が読み取られ、ユーザのディレクトリプロフィール エントリ内の Sieve スクリプトに保存されます。プロンプトおよび入力フィールドは、Delegated Administrator のインターフェースを介してエンドユーザに提示されます。

Delegated Administrator には、サンプルのテンプレートセットが用意されています。これらのテンプレートファイルは、次のディレクトリにあります。

nda-path/nda/nda/default/lang/templates/enduser/ssr/*.txt

フィルタテンプレートは、Sieve 言語を使って変更したり新規作成することができます。新規のフィルタテンプレートを作成した場合は、それを前述の ssr ディレクトリにテキスト形式で保存しなければなりません。そのファイルが誰でも読み取り可能であることを確認し、以下の例に示すように、フィルタテンプレートに LDAP エントリを追加します。

dn: cn=Subject Discard,cn=ssrconf,cn=en,
              cn=domainConfiguration,ou=config,o=isp
objectclass: top
objectclass: nsValueItem
cn: Subject Discard
nsvaluetype: nsValueCIS
nsvaluecis: ../templates/enduser/ssr/subject-discard.txt

図 9-7 に、テンプレートの例を示します。

図 9-7 Sieve テンプレートの例
     #RULE: $Template="File To Folder"
require "fileinto";
if header :contains # Q1
# Q2
{
fileinto # Q3
;
}

#PRE: "This rule files messages into a folder."
#PRE: "Choose the header line to search on"
#PRE: "And specify the phrase you wish to search for"
#Q1: header "If the header line"
#Q2: value "Contains the phrase"
#Q3: folder "Then file into the folder"

上記の例で、Q1、Q2、および Q3 は入力される値のプレースフォルダであり、UI がその値を見つけて置換します。各トークンは、その入力値の質問とデータタイプをマッッピングします。

データタイプおよび関連する質問は、各トークンごとのコメント行に定義されています。それらは、トークン : データ-タイプ-変数の形式で定義され、続いて、引用符に囲まれた文字列に実際の質問が含まれています。上記の例で、header value、およびfolder は、いずれも、ドロップダウンリスト、編集ボックス、あるいはその他の要素を示すデータタイプです。これらのデータタイプ変数は、UI に対し、どのタイプの情報をユーザから取得するのかを指示するものです。

テンプレートが解析されると、ダイアログが生成され、図 9-8 の例のようにエンドユーザに表示されます。この例で、角括弧はドロップダウンリストを表しています。

図 9-8 テンプレート出力の例
+--------------------------------------------------------------+
| Template: File To Folder Name: _________________             |
+--------------------------------------------------------------+
|           This rule files messages to a folder               |
|           Choose the header line to search on                |
|       And specify the phrase you wish to search for          |
|                                                              |
|   If the header line: [From       ]                          |
|   Contains the phrase: _____________________________         |
|   Then file into the folder: _________________               |
+--------------------------------------------------------------+

ユーザがデータを入力すると、その規則がユーザの mailSieveRuleSource 属性に保存されます。

テンプレートの構文には、以下の規則があります。

Sieve テンプレートでは、以下のデータタイプ変数がサポートされています。


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

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

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

  1. Sieve を使ってフィルタを記述します。

  2. フィルタを、以下のディレクトリのファイルに保存します。

    msg-インスタンス/imta/config/file.filter

    ファイルは誰でも読み取り可能で、MTA の uid によって所有されていなければなりません。

  3. 以下のチャネル設定を定義します。

    destinationfilter file:IMTA_TABLE:file.filter

  4. 設定をリコンパイルし、ディスパッチャを再起動します。

    注意 : フィルタファイルへの変更を有効にするのに、リコンパイルやディスパッチャの再起動は不要です。

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

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

destinationfilter URL-パターン

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

sourcefilter URL-パターン

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

destinationfilter file:///imta/config/チャネル名.filter

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

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

filter URL-パターン

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

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

fileinto $U+$S@$D


表 9-4 置換シーケンス


シーケンス

代替文字列

$$

$ 文字に置き換えます。

$A, $a

アドレス (local-part@ host.domain) に置き換えます。

$D, $d

ホストドメインに置き換えます。

$H, $h

ホストに置き換えます。

$L, $l

ローカル部分に置き換えます。

$U, $u

下線 (_) やチルド (~) のプレフィックス、およびサブアドレスのポストフィックスを除くローカル部分に置き換えます。

$~

アドレスのローカル部分に関連付けられたホームディレクトリに対するファイルパスに置き換えます。


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


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

  1. Sieve を使ってフィルタを記述します。

  2. フィルタを、次のファイルに保存します。

    msg-インスタンス/imta/config/imta.filter

    このフィルタファイルは、誰でも読み取り可能でなければなりません。このファイルは自動的に使用されます。

  3. 設定をリコンパイルし、ディスパッチャを再起動します。

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


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

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

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

filter_discard notices 7
FILTER-DISCARD

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


ユーザフィルタをデバッグする


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

dirsync プロセスは、ユーザフィルタに関する MTA の SSR データベース情報を更新します。短いフィルタは、データベース内に保存されます。長いフィルタの場合は、データベースに LDAP dn が保存されます。dirsync プロセスによってデータベースが更新されるまで、ユーザフィルタの変更内容は認識されません。

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


前へ    目次    索引    次へ
Copyright (c) 2001 Sun Microsystems, Inc. 既存部分の一部: Copyright (c) 2001 Netscape Communications Corp. All rights reserved.

最終更新日 2001 年 5 月 24 日