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



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


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

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

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

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

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

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



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


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



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

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

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

表 10-1    アクセス制御マッピングテーブル 

マッピングテーブル

説明

SEND_ACCESS
(307を参照)
 

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

ORIG_SEND_ACCESS
(307を参照)
 

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

MAIL_ACCESS
(309を参照)
 

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

ORIG_MAIL_ACCESS
(309を参照)
 

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

FROM_ACCESS
(310を参照)
 

エンベロープ From アドレスに基づいてメールをフィルタリングする。このテーブルは、To アドレスが不適切な場合に使用する  

PORT_ACCESS
(313を参照)
 

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

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 つの手段として、図 10-1 に示している SEND_ACCESS マッピングテーブルの使用があります。このマッピングテーブルの例では、ローカルのホスト名が sesta.com であると想定しています。チャネル名「tcp_*」では、ワイルドカードを使って任意の TCP/IP チャネル名 (たとえば tcp_loal) と一致するようにしています。

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

図 10-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 のいずれか 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 を表示するようなサイトでは、図 10-2 に示す MAIL_ACCESS マッピングテーブルを使用します。

図 10-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 のいずれか 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: アドレスを最初のものから認証アドレスに置き換えることができます。
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 の本来の目的は、図 10-3 に示すように、より複雑で微妙な変更を行うことにあります。受信メッセージに Sender: ヘッダー行を追加 (SMTP AUTH 認証済み送信者アドレスを表示) したい場合は、authrewrite キーワードだけでも十分です。ただし、SMTP AUTH 認証済み送信者アドレスがエンベロープの From: アドレスと異なる場合にのみ、受信メッセージに Sender: ヘッダー行を強制的に追加したいとします (つまり、アドレスが一致した場合には、Sender: ヘッダー行を追加しません)。さらに、エンベロープの From: にオプションのサブアドレスが含まれているというだけで SMTP AUTH およびエンベロープの From: アドレスを異なるとみなしたいとします。

図 10-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|server-address|server-port|client-address|client-port

ディスパッチャは、すべての 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 つと適切なテキストを挿入します。表 10-2 に使用可能なサービスを表示します。


表 10-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 接続を制限するために使用されます。以下に示すように、設定オプションはすべて接続スロットル共有ライブラリに対するパラメータとして指定されます。

$[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 の接続が試みられた場合、リモートサイトはその 1 分間における最初の 100 個の接続のあとブロックされるだけでなく、次の 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 オプション) は、アクセス制御マッピングのテストに役立ちます。例として、図 10-4 に、サンプルの SEND_ACCESS マッピングテーブルとその結果としてのプローブを示します。

図 10-4    SEND_ACCESS マッピングテーブルとプローブの例
MAPPING TABLE:

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

PROBE:

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

どのシステムとサブネットを内部とみなすかは、通常 INTERNAL_IP マッピングテーブルで制御されます。このテーブルは<InstanceRoot>/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) シンタックスを使った初期エントリにより、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 リレーサーバを通してメールをリレーできるようになります。
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.670.96/30)   $Y
   127.0.0.1   $Y
   *   $N

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

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

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


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

前の項で説明したように、内部 IP アドレスはすべて INTERNAL_IP マッピングテーブルに追加しなければなりません。お使いのシステムやサイトで SMTP リレーを許可する場合は、SMTP リレーを許可する外部アドレスを内部アドレスとともに 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 リレーを可能にするには、INTERNAL_IP マッピングテーブルに内部 IP アドレスまたはサブネットを追加します。


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

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

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

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

  • この設定ファイルでは、ローカルチャネルの直前に defaults チャネルおよび noswitchchannel キーワードを追加します。

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

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

    tcp_local smtp single_sys mx switchchannel remotehost
    TCP-DAEMON

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

    tcp_intranet smtp single_sys mx allowswitchchannel routelocal
    tcp_intranet-daemon

    routelocal チャネルキーワードを指定すると、アドレスをチャネルに書き換える際に、MTA はこのチャネルを介してアドレスのすべての明示的ルーティングを短絡化しようとします。これにより、明示されたソースルートアドレスを経由した内部 SMTP ホストのループによるリレー試行がブロックされます。

上記の設定により、ドメイン内で生成された 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 の差出人が認証されると、送信メッセージが指定した切り替え先チャネルから入ってくるようになります。

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

  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 リレーブロッキングの RBL チェックを含む DNS 検索を使用するには

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

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

  TCP|*|*|*|*|SMTP|MAIL|*|*@*|*|*¥
$[<server_root>/bin/msg/imta/lib/dns_verify.so,¥
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 マッピングテーブルでは、最初の 1 つまたは複数のエントリに対してローカルの内部 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.so,¥
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_verify.so,¥
dns_verify_domain,$1,rbl.maps.vix.com.]$E


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

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

標準の設定では、特定の IP アドレスの DNS にある TXT レコードには、メッセージを拒否するときに SMTP クライアントに返すためのエラーメッセージが含まれています。しかし、TXT レコードがなく、A レコードがある場合、iPlanet 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$[/export/home/iplanet/server51/msg/bin/imta/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 などのアクセスマッピングテーブルを使って簡単に適用できます。この場合、一般的なデータベースに特定の情報 (たとえば特定のアドレスなど) をまとめて保存し、マッピングテーブルのエントリで呼び出すように設定すれば、効率と性能がかなり向上します。

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

図 10-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...


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

図 10-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」フラグで囲むのは、マッピングテーブルから一般的なデータベース呼び出しに特有の方法です。

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



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


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

表 10-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 行を追加する  

$X error-code  

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

$Nstring  

アクセスを拒否し、オプションのエラーテキスト string を送る  

$Fstring  

$N string と同じ。アクセスを拒否し、オプションのエラーテキスト string を送る  

* 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 サーブレットは、Sieve テンプレートを解析し、ブラウザで UI ページを生成するために使用されます。エンドユーザが入力フィールドに値を入力すると、サーブレットによってそれらの値が読み取られ、ユーザのディレクトリプロフィールエントリ内の 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

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

図 10-7    Seive テンプレートの例
     #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 がその値を見つけて置換します。各トークンは、その入力値の質問とデータタイプをマッッピングします。

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

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

図 10-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 属性に保存されます。

テンプレートのシンタックスには、以下の規則があります。

  • #RULE 行は、その他の行よりも前に記述され、$Template を定義する必要がある

  • #PRE で始まるコメント行は、GUI ページの入力フィールドよりも前に表示される

    #PRE 文は、二重引用符で囲まれていなければならない

  • #POST で始まるコメント行は、GUI ページの最後に表示される

    #POST 文は、二重引用符で囲まれていなければならない

  • その他のコメント行は、GUI ページには表示されない

  • トークンは ASCII 文字列で、大文字と小文字の区別はない。トークンに空白を挿入することはできない

  • データタイプ変数は、コメント行のトークン文字列の後ろに記述する。大文字と小文字の区別はない

  • 実際の質問は、データタイプ変数のすぐ後ろのコメント行に定義されており、二重引用符で囲まれている

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

  • header - GUI に表示される際には、リストボックスが使用され、Subject、To、From の各値が表示される

    Sieve 規則がユーザエントリに保存されると、Subject の値が Subject、Comments、Keywords に展開され、From の値は From、Sender、Resent-from、Resent-sender、Return-path に、さらに To の値は To、Cc、Bcc、Resent-to、Resent-cc、Reset-bcc に展開される

  • value - テキストフィールドを使って値を示す

  • address - テキストフィールドを使って値を示す。アドレスのシンタックスが RFC 822 のメールアドレス形式に準拠しているかどうかが調べられる

  • folder - テキストフィールドを使って値を示す

  • size - ユーザは「キロバイト」または「メガバイト」の中から選択するか、または任意の数値を指定できる

  • message - テキストフィールドを使って値を示す



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

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

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

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

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

    msg-instance/imta/config/file.filter

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

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

    destinationfilter file:IMTA_TABLE:file.filter

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

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

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

destinationfilter チャネルキーワードのシンタックスは以下のとおりです。

destinationfilter URL-pattern

sourcefilter チャネルキーワードのシンタックスは以下のとおりです。

sourcefilter URL-pattern

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

destinationfilter file:///usr/tmp/filters/channel-name.filter

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

filter チャネルキーワードのシンタックスは以下のとおりです。

filter URL-pattern

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

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

fileinto $U+$S@$D


表 10-4    置換タグ (大文字小文字を区別します) 

タグ

意味

*  

グループの拡張を実行する。「グループエントリを処理する」を参照  

**  

mailForwardingAddress 属性を拡張する。複数の値を持つ属性を設定して複数の配信先アドレスを生成できる  

$$  

$ 文字に置き換える  

$¥  

後続のテキストを小文字にする  

$^  

後続のテキストを大文字にする  

$_  

代替テキストで大文字と小文字を変換しない  

$~  

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

$1S  

$S と同じだが、サブアドレスがない場合は何も行わない  

$2S  

$S と同じだが、サブアドレスがない場合は何も挿入せず前の文字を削除する  

$3S  

$S と同じだが、サブアドレスがない場合は何も挿入せず後続の文字を無視する  

$A  

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

$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 全体のフィルタを作成するには次のようにします。

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

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

    msg-instance/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 プロセスによってデータベースが更新されるまで、ユーザフィルタの変更内容は認識されません。

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

  • imta.cnf ファイル内で、ims-ms チャネルが次のようにマークされていることを確認します。

    filter ssrd:$a fileinto $u+$s@$d

  • dirsync プロセスが configutil コマンドを使ってフィルタ情報を同期するようになっていることを確認します。

    configutil -l -o service.imta.ssrenabled -v true

    OK SET

    configutil | fgrep ssr

    service.imta.ssrenabled = true

  • フィルタをテストするには、次のようにimsimta test コマンドを使用します。

    imsimta test -rewrite -debug -filter user@domain

    出力で、以下の情報を探します。

    mmc_open_url called to open ssrd:user@ims-ms
       URL with quotes stripped:ssrd:user@ims-ms
    Determined to be an SSRD URL.
       Identifier:user@ims-ms-daemon
    Filter successfully obtained.

  • フィルタのシンタックスに問題がある場合は、以下の情報を探します。

    Error parsing filter expression:...

    このエラーからフィルタに関する問題の詳細がわかります。

  • フィルタに問題がない場合は、test コマンドによって、出力の最後にフィルタが表示されます。

  • フィルタに問題がある場合は、test コマンドによって、出力の最後に次の情報が表示されます。

    Address list error -- 4.7.1 Filter syntax error:user@siroe.com

    また、次に示すように、SMTP RCPT TO コマンドによって一時的なエラー応答コードが返されます。

    RCPT TO:<user@siroe.com>
    452 4.7.1 Filter syntax error

  • ユーザアドレスの最終的な書き換え形式がわかっている場合には、imsimta test -url コマンドを使って MTA がそのユーザ用に使っているフィルタを確認できます。

    imsimta test -url ssrd:user@ims-ms-daemon

    imsimta test -rewrite コマンドを使用すると、ユーザアドレスの最終的な書き換え形式を見つけることができます。


前へ     目次     索引     DocHome     次へ     
Copyright © 2002 Sun Microsystems, Inc. All rights reserved.

最新更新日 2002 年 2 月 27 日