test

Sun Java System Messaging Server 6 2005Q4 管理ガイド

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

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

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

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

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

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

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

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

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

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

メールサービスへのアクセスを制御するには、一定のマッピングテーブルを使用します。これらのマッピングテーブルを使用すると、メールの送信、受信、またはその両方をどのユーザーに許可するか、あるいは許可しないかを制御できます。表 17–1 に、この節で説明するマッピングテーブルのリストを示します。FROM_ACCESS、MAIL_ACCESS、ORIG_MAIL_ACCESS の各マッピングテーブルに与えられているアプリケーション情報の文字列には、HELO/EHLO SMTP コマンドで要求されるシステム名が含まれます。この名前は文字列の最後に表示されて、文字列 (通常は「SMTP」) のほかの部分とはスラッシュで区切られています。要求されるシステム名は、ある種のワームやウィルスのブロックに役立つ場合があります。

アクセス制御マッピングテーブル — 操作

アクセス制御マッピングテーブルの形式は、ほかのマッピングテーブルと同じ一般的なものです (「マッピングファイル」を参照)。マッピングテーブル名の後ろに改行が入り、そのあとに 1 つまたは複数のマッピングエントリが続きます。マッピングエントリは、左側の検索パターンと右側のテンプレートから構成されています。検索パターンは特定のメッセージをフィルタリングし、テンプレートはメッセージに対して実行するアクションを指定します。例: 

SEND_ACCESS

 *|Elvis1@sesta.com|*|*      $Y
 *|Nelson7@sesta.com|*|*     $Y
 *|AkiraK@sesta.com|*|*      $Y
 *|*@sesta.com|*|*           $NMail$ Blocked

この例では、ドメイン Elvis1、Nelson、および AkiraK を除き、ドメイン sesta.com からのすべての電子メールをブロックしています。

アクセス制御マッピングエントリの検索パターンは多数の検索条件から構成され、個々の検索条件は縦棒 (|) で区切られています。検索条件の順序はアクセスマッピングテーブルによって決定されます。これについてはあとの節で説明します。例として、SEND_ACCESS マッピングテーブルの検索形式を次に示します。

src-channel|from-address|dst-channel|to-address

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

注 –

mappings ファイルを変更した場合は、必ず設定をコンパイルしなおしてください (「MTA 設定をコンパイルする」を参照)。

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

マッピングテーブル 

説明 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

引数を伴うフラグの場合、引数がテーブルに表示される読み取り順に並んでいる必要があります。例: 

ORIG_SEND_ACCESS

  tcp_local|*|tcp_local|*     $N$D30|Relaying$ not$ allowed

この場合、遅延期間の後ろに拒否文字列が来るのが正しい順序です。フラグ自体は、どのような順序で指定してもかまいません。したがって、次のエントリはいずれも同じ結果になります。


30|Relaying$ not$ allowed$D$N
$N30|Relaying$ not$ allowed$D
30|$N$DRelaying$ not$ allowed
表 17–2 アクセスマッピングフラグ

フラグ 

説明 

$A

SASL が使用されている場合に設定されます。「特殊なフラグの確認」を参照してください。

$B

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

$D

配信遅延の確認が要求された場合に設定されます (FROM_ACCESS では指定できない)。「特殊なフラグの確認」を参照してください。

$F

配信失敗の確認が要求された場合に設定されます (FROM_ACCESS では指定できない)。「特殊なフラグの確認」を参照してください。

$H

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

$S

配信成功の確認が要求された場合に設定されます (FROM_ACCESS では指定できない)。「特殊なフラグの確認」を参照してください。

$T

TLS が使用されている場合に設定されます。「特殊なフラグの確認」を参照してください。

$U 

ORIG_SEND_ACCESS、SEND_ACCESS、ORIG_MAIL_ACCESS、および MAIL_ACCESS で使用された場合、マッピング開始時から 1 つの整数引数をとり、MM_DEBUG の値をそれに応じて設定します。また、このフラグが設定されていると、チャネルレベルのデバッグも有効になります。その結果、ソース IP アドレス、元のアドレス、受取人アドレスなどに基づいてデバッグを有効化できるようになります。

$Y

アクセスを許可します。 

$V

すべての受取人について強制破棄が実行されるようにします。 

$Z

すべての受取人について強制破棄が実行されるようにします。 

フラグと引数、引数の読み取り順序 + (このリストはアルファベット順にしないこと)

$Uinteger

マッピング開始時から 1 つの整数引数をとり、MM_DEBUG をそれに応じて設定します。また、このフラグが設定されていると、チャネルレベルのデバッグも有効になります。その結果、ソース IP アドレス、元のアドレス、受取人アドレスなどに基づいてデバッグを有効化できるようになります。 

$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 を追加します。

$Gconversion_tag

ORIG_SEND_ACCESS、SEND_ACCESS、ORIG_MAIL_ACCESS、および MAIL_ACCESS で使用された場合、マッピングの結果の値を読み込んで、現在の受取人に適用される変換タグの集合として処理します。FROM_ACCESS とともに使用された場合、変換タグはすべての受取人に適用されます。マッピングから読み取られる一連の引数の中で、$G は $A (ヘッダーアドレス) のあとに配置されます。「メール変換タグ」を参照してください。

$Sx,y,z

* マッピングの結果から、追加および別々の引数がマッピング結果から読み取られるようにします。この引数は、カンマで区切られた 1 個 〜 3 個の整数値から構成されます。最初の値は、トランザクション用の新しい最小の blocklimit を設定します。2 番目の値は新しい最小の recipientlimit を設定し、3 番目の値は新しい最小の recipientcutoff を設定します。いずれかの取得引数が読み込まれると、マッピングの結果から引数が読み込まれます。「絶対的なメッセージサイズ制限を指定する」を参照してください。

$Xerror-code

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

$,spamadjust_arg

アクセスマッピングテーブルから Sieve spamadjust 処理を実行可能にします。引数は、spamadjust 引数と同じ形式をとります。また、上のマッピングの一部は受取人単位で適用されます。実行されるすべての spamadjust 処理はすべての受取人に適用されます。

$Nstring

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

$Fstring

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

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

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

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

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

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」以外に文字列が出力されない場合は、デフォルトの拒否通知テキストが使用されます。その他のフラグの説明については、「アクセス制御マッピングテーブルのフラグ」を参照してください。

MTA オプション ACCESS_ORCPT を 1 に設定すると、SEND_ACCESS、ORIG_SEND_ACCESS、MAIL_ACCESS、および ORIG_MAIL_ACCESS マッピングテーブルに渡されるプローブ値に縦棒で区切られたフィールドが付加されます。このフィールドには、元の受取人 (ORCPT) アドレスが入ります。メッセージに ORCPT アドレスが含まれない場合は、変更されていない元の RCPT TO: アドレスが代わりに使用されます。デフォルトは 0 であり、プローブ値で終わります。

src-channel|from-address|dst-channel|to-address|ORCPT_address

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

例 17–1 SEND_ACCESS マッピングテーブル


SEND_ACCESS

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

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

注 –

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 には、HELO/EHLO SMTP コマンドで要求されるシステム名が含まれます。この名前は文字列の最後に表示されて、文字列 (通常は「SMTP」) のほかの部分とはスラッシュで区切られています。要求されるシステム名は、ある種のワームやウィルスのブロックに役立つ場合があります。submit-type は、メッセージが Messaging Server にどのように送信されたかに応じて、MAIL、SEND、SAML、または SOML のいずれかになります。通常、この値は、メッセージとして送信されたことを表す MAIL です。SEND、SAML、または SOML は、ブロードキャスト要求 (またはブロードキャストとメッセージを組み合わせた要求) が SMTP サーバーに送信された場合の値です。MAIL_ACCESS マッピングの send-access-probe-info は、SEND_ACCESS マッピングテーブルプローブに通常含まれているすべての情報から成ります。同様に、ORIG_MAIL_ACCESS マッピングの orig-access-probe-info は、ORIG_SEND_ACCESS マッピングテーブルプローブに通常含まれているすべての情報から成ります。

MTA オプション ACCESS_ORCPT を 1 に設定すると、SEND_ACCESS、ORIG_SEND_ACCESS、MAIL_ACCESS、および ORIG_MAIL_ACCESS マッピングテーブルに渡されるプローブ値に縦棒で区切られたフィールドが付加されます。このフィールドには、元の受取人 (ORCPT) アドレスが入ります。メッセージに ORCPT アドレスが含まれない場合は、変更されていない元の RCPT TO: アドレスが代わりに使用されます。デフォルトは 0 であり、プローブ値で終わります。次に例を示します。


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

着信 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 マッピングテーブルを使用します。

例 17–2 MAIL_ACCESS マッピングテーブル


MAIL_ACCESS
 
! vip の 2 つのシステムのエントリ
!
  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
!
! ほかのシステムのアドレスから vip の From: アドレスを使用することを
! 許可しない
!
  TCP|*|25|*|*|SMTP|MAIL|tcp_*|vip@siroe.com|*|*  \
      $N500$ Not$ authorized$ to$ use$ this$ From:$ address
!
! siroe.com の From: アドレスを持つサブネット内からの送信を
! 許可する
!
  TCP|*|25|1.2.*.*|*|SMTP|MAIL|tcp_*|*@siroe.com|*|*  $Y
!
! 通知を許可する
!
  TCP|*|25|1.2.*.*|*|SMTP|MAIL|tcp_*||*|*  $Y
!
! non-siroe.com アドレスを持つサブネット内からの送信を
! ブロックする
!
  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 には、HELO/EHLO SMTP コマンドで要求されるシステム名が含まれます。この名前は文字列の最後に表示されて、文字列 (通常は「SMTP」) のほかの部分とはスラッシュで区切られています。要求されるシステム名は、ある種のワームやウィルスのブロックに役立つ場合があります。submit-type は、メッセージが MTA にどのように送信されたかに応じて、MAIL、SEND、SAML、または SOML のいずれかになります。通常、この値は、メッセージとして送信されたことを表す 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: アドレスを最初のものから認証アドレスに置き換えることができます。

例 17–3 FROM_ACCESS マッピングテーブル


FROM_ACCESS

  *|SMTP|*|tcp_auth|*|       $Y
  *|SMTP|*|tcp_auth|*|*      $Y$J$3

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

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


FROM_ACCESS

   *|SMTP|*|tcp_auth|*|     $Y
   *|SMTP|*|tcp_auth|*|*    $Y$K$3

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


FROM_ACCESS
 
! 認証済みのアドレスが使用できない場合、何もしない
  *|SMTP|*|tcp_auth|*|              $Y
! 認証済みのアドレスがエンベロープの From: に一致する場合は、何もしない
  *|SMTP|*|tcp_auth|*|$2*           $Y
! 認証済みのアドレスが From: sans 
! サブアドレスに一致する場合は、何もしない
   *|SMTP|*|tcp_auth|*+*@*|$2*@$4*    $Y
! ただし、認証済みアドレスは存在しているが
! 一致しない場合は、
! Sender: ヘッダー
  *|SMTP|*|tcp_auth|*|*              $Y$K$3

PORT_ACCESS マッピングテーブル

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

TCP|server-address|server-port|client-address|client-port

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

注 –

MMP は PORT_ACCESS マッピングテーブルを使用しません。MMP を使用している場合、特定の IP アドレスからの SMTP 接続を拒否するには、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–3 に、使用可能なフラグを表示します。

表 17–3 PORT_ACCESS マッピングフラグ

フラグ 

説明 

$Y 

アクセスを許可します。 

フラグと引数 (引数の読み取り順序 +) 

$< 文字列 

プローブが一致する場合、文字列を syslog (UNIX) またはイベントログ (NT) に送ります。 

$> 文字列 

アクセスが拒否された場合、文字列を syslog (UNIX) またはイベントログ (NT) に送ります。 

$N 文字列 

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

$F 文字列 

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

$T テキスト 

LOG_CONNECTION MTA オプションのビット 1 (値 2) が設定されており、かつ「$N」フラグが設定されて接続が拒否されている場合は、「$T」により「T」エントリが接続ログに書き込まれます。「T」ログエントリにはマッピング結果文字列全体 ($N とその文字列) が含まれることになります。

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

たとえば、次のマッピングは、単一のネットワークからポート 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 接続を制限するために使用されます。次に示すように、設定オプションはすべて接続スロットル共有ライブラリに対するパラメータとして指定されます。

$[msg_svr_base/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$[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、-sender 、および -destination_channel オプション) は、アクセス制御マッピングのテストに役立ちます。詳細は、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の「imsimta test」を参照してください。次の例で、サンプルの 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 リレーを追加するには

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 マッピングテーブルは次のようになります。


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 

! IP アドレスを 123.45.67.80 〜 123.45.67.95 の範囲に一致させる
   $(123.45.67.80/28) $Y
! IP アドレスを 123.45.67.96 〜 123.45.67.99 の範囲に一致させる
   $(123.45.67.96/30) $Y 
   127.0.0.1 $Y 
   * $N

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

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

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

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

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

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 設定では、デフォルトで、サーバーが内部と外部のメッセージトラフィックを識別できるように設定されています。

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

Procedure認証ユーザーによる送信であるかどうかを識別するには

手順

  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 検索を使用するには

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

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

ORIG_MAIL_ACCESS

  TCP|*|*|*|*|SMTP|MAIL|*|*@*|*|*  \
$[msg_svr_base/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
! ...通常のオプションの残りの部分...
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
 
! ユーザーはインターネットへの接続を許可されている
!
  *|adam@siroe.com|tcp_local|*    $Y
  *|betty@siroe.com|tcp_local|*   $Y
! ...など...
!
! ユーザーはインターネットへの接続を許可されていない
!
  *|norman@siroe.com|tcp_local|*  $NInternet$ access$ not$ permitted
  *|opal@siroe.com|tcp_local|*    $NInternet$ access$ not$ permitted
! ...など...
!
! ユーザーはインターネットからの受信を許可されている
!
  tcp_*|*|*|adam@siroe.com        $Y
  tcp_*|*|*|betty@siroe.com       $Y
! ...など...
!
! ユーザーはインターネットからの受信を許可されていない
!
  tcp_*|*|*|norman@siroe.com      $NInternet$ e-mail$ not$ accepted
  tcp_*|*|*|opal@siroe.com        $NInternet$ e-mail$ not$ accepted
! ...など...

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

% imsimta crdb input-file-spec output-database-spec

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


データベースエントリ

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


マッピングテーブル

ORIG_SEND_ACCESS

! インターネットに送信する場合はチェックする
!
  *|*|*|tcp_local       $C${SEND|$1}$E
!
! インターネットから受信する場合はチェックする
!
  tcp_*|*|*|*           $C${RECV|$3}$E

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

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

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

メールボックスフィルタは、Sieve フィルタとも呼ばれ、メッセージヘッダー内に指定の文字列を含んだメッセージをフィルタし、これらのメッセージに指定のアクションを適用します。管理者は、チャネルや MTA を介して、ユーザーに送信されるメールストリームをフィルタすることができます。Messaging Server のフィルタはサーバー上に保存されてサーバーによって評価されるため、サーバー側ルール (SSR) と呼ばれることがあります。

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

Sieve フィルタのサポート

Messaging Server のフィルタは、Sieve Internet Draft の Draft 9 である Sieve フィルタリング言語に基づいています。Sieve の構文およびセマンティクスの詳細については、RFC3028 を参照してください。また、Messaging Server では次の Sieve 拡張機能もサポートしています。

Sieve フィルタリングの概要

Sieve フィルタは、メッセージヘッダーにある文字列に基づいてメールメッセージに適用される 1 つまたは複数の条件付きアクションで構成されています。管理者は、チャネルレベルのフィルタと MTA 全体のフィルタを作成し、不正メールの配信を防止できます。ユーザーは Messenger Express を使用して、自分のメールボックスにユーザー単位のフィルタを作成できます。この具体的な手順については、Messenger Express のオンラインヘルプを参照してください。

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

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

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

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

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

  3. MTA 全体のフィルタ

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

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

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

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

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

表 17–4 filter チャネルキーワードの URL-pattern の置換タグ (大文字と小文字の区別なし)

タグ 

意味 

* 

グループの拡張を実行します。 

** 

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 

現在のアドレスのメールボックス部分を挿入します。@ マークの左側のアドレス全体、またはその中でサブアドレス区切りの + より前の部分のいずれかが挿入されます。 

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

手順

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

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

    ../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 から派生する文字列に置き換えられます。表 17–4 に、これらの置換のシーケンスを示します。

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


    fileinto $U+$S@$D

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

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

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

手順

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

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

    ../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 などのユーティリティーを使ってバウンスを要求することによって、システムから削除されるだけです。

Messaging Server 6 2004Q2 より前の Messaging Server では、jettison Sieve アクションによる filter_discard チャネルの使用は、MTA オプション FILTER_DISCARD よって制御されていました。これは現在では、FILTER_JETTISON オプションによって制御されるようになり、このオプションは FILTER_DISCARD の設定からデフォルト値を取得します。FILTER_DISCARD のデフォルト値は 1 です (破棄されたメッセージは bitbucket チャネルに送られる)。

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

ユーザーから Sieve フィルタが期待通りに動作しないという苦情が寄せられた場合、フィルタをデバッグするために実行できるいくつかの手順があります。これらの手順を次に示します。

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

手順

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

    fileinto $u+$s@$d

  2. ユーザーの LDAP エントリからユーザーレベルのフィルタを取得します。

    ユーザーレベルのフィルタは、MailSieveRuleSource 属性の下のそれぞれの LDAP エントリに保存されています。ldapsearch コマンドを使用してこのフィルタを検索する際には、これらが base64 でエンコードされているため -Bo スイッチで出力をデコードする必要があることに注意してください。


    ./ldapsearch -D "cn=directory manager" -w password -b 
"o=alcatraz.sesta.com,o=isp" -Bo uid=test

    次の手順で説明している imsimta test -rewrite コマンドも、自動的にフィルタをデコードします。

  3. ユーザーのフィルタが MTA から見えることを確認します。

    次のコマンドを発行します。

    # imsimta test -rewrite -filter -debug user@sesta.com

    これにより、前の手順で取得したユーザーの Sieve フィルタが出力されます。フィルタが見つからない場合は、LDAP エントリがそれらを返さない理由を調べる必要があります。imsimta test -rewrite の出力にフィルタが表示されていたら、ユーザーのフィルタが MTA から見えているということです。次に必要な処理は、imsimta test -expression コマンドを使用してフィルタの解釈をテストすることです。

  4. imsimta test -exp を使用して、ユーザーのフィルタをデバッグします。次に示す情報が必要です。

    1. ユーザーの mailSieveRuleSource 属性からの Sieve 言語ステートメント。前述の手順を参照してください。

    2. フィルタをトリガするはずだった rfc2822 メッセージ。

    3. フィルタがメッセージに対してどのような処理を行うべきだったかという説明。

  5. テキストファイルを作成します (temp.filter など)。このファイルには、ユーザーの mailSieveRuleSource: の値に基づいた Sieve 言語ステートメントを格納します。次に例を示します。

    require "fileinto";
if anyof(header :contains
["To","Cc","Bcc","Resent-to","Resent-cc", 
   "Resent-bcc"] "commsqa"){ 
   fileinto "QMSG";
}

    期待される結果: commsqa がこのメッセージの受取人である場合は、メッセージを QMSG というフォルダにファイリングします。

  6. ユーザーによって指定される rfc2822 メッセージファイルの内容を含む、test.msg という名前のテキストファイルを作成します。

    ユーザーのメッセージストア領域から .msg ファイルを使用するか、あるいはユーザーによって指定される rfc2822 メッセージファイルの内容を含む test_rfc2822.msg というテキストファイルを作成することができます。

  7. imsimta test -exp コマンドを使用します。


    # imsimta test -exp -mm -block -input=temp.filter -message=test_rfc2822.msg

  8. 出力を確認します。

    imsimta test -exp コマンドの最後の行は、Sieve 解釈の結果を示します。結果は次のようになります。


    Sieve Result: [] 
または 
Sieve Result: [action]

    action は、Sieve フィルタを適用した結果としてこのメッセージに実行されたアクションです。

    フィルタの条件に一致した場合、結果としていくつかのアクションが表示されます。一致するものがない場合、Sieve 結果は空白となり、Sieve フィルタに論理上のエラーがあるか、または .msg ファイルに一致する情報が含まれていないかのどちらかです。ほかのエラーが発生している場合は、Sieve スクリプトファイルに構文エラーがあるので、デバッグする必要があります。

    出力の詳細については、「imsimta test -exp Output」を参照してください。

  9. フィルタが構文的に有効で結果が正しい場合、次に必要な処理は tcp_local_slave.log デバッグログファイルを調べることです。

    テストしたメッセージファイルと送信されているメッセージファイルが同一でない可能性があります。受信しているメッセージを確認する唯一の方法は、tcp_local_slave.log ファイルを調べることです。このログには、MTA に送信されている正確なメッセージと、メッセージに対してフィルタがどのように適用されているかが表示されます。

    tcp_local_slave.log デバッグファイルの入手の詳細については、「デバッグのキーワード」の slave_debug キーワードを参照してください。

imsimta test -exp Output

imsimta test -exp の完全なコマンドは、次のとおりです。

# imsimta test -exp -mm -block -input=temp.filter -message=rfc2822.msg

出力の例を次に示します。

例 17–4 imsimta test -exp の出力


# imsimta test -exp -mm -block -input tmp.filter -message=rfc2822.msg
Expression: if header :contains ["to"] ["pamw"]       (1)
Expression: {
Expression: redirect "usr3@sesta.com";
Expression: keep;
Expression: }
Expression:
Expression: Dump: header:2000114;0  3  1  :contains  1  "to"  1
"pamw"  if  8  ;
Dump: redirect:2000121;0  1  1  "usr3@sesta.com"  ;  keep:2000117;0 (2)
Dump: 0
Result: 0
Filter result: [ redirect "usr3@sesta.com" keep ]    (3)

1) Expression: 出力行は、tmp.filter テキストファイルから読み取られ、解析されるフィルタを示します。これらは、スクリプトのデバッグにはあまり関係がありません。

2) Dump: 出力行は、Sieve ステートメントを解釈しているコンピュータの結果を示します。ここにエラーが表示されないようにしてください。出力は入力と一致しているように見えなければなりません。たとえば、ダンプには、フィルタファイル内の行 redirect "usr3@sesta.com"; とよく似た redirect, usr3@sesta.com という語が表示されます。

このように一致するテキストが表示されない場合は調べてみる必要があります。表示された場合、これらもスクリプトのデバッグとはあまり関係がありません。

3) 出力の一番下の行に、Filter result: ステートメントが表示されます。前述したように、次の 2 とおりの結果が考えられます。

Sieve Result: [] または Sieve Result: [ action]

action は、Sieve スクリプトによって実行されるアクションです。結果が空白になる場合もあるので注意してください。たとえば、破棄フィルタの場合、そのフィルタが常に、テストの対象となるすべての .msg ファイルを破棄しているのではないことをテストする必要があります。角括弧の間に何らかのアクションが含まれる場合、次のようになります。

Filter result: [ fileinto "QMSG" keep]

これは、rfc2822.msg ファイルのテキストがフィルタ条件に一致していることを示しています。この例では、フィルタはメールを QMSG フォルダにファイリングして、コピーを受信箱に保存します。この場合、結果として実行されるアクションは、fileinto および keep です。

フィルタをテストする際には、両方の結果について、各種の .msg ファイルをテストする必要があります。常に、使用するフィルタに一致するメッセージがフィルタ処理されていること、また、一致させたくないメッセージがフィルタ処理されていないことをテストする必要があります。

ワイルドカードとの照合の場合は、:contains テストではなく :matches テストを行う必要があることを理解しておいてください。たとえば、from=*@sesta.com と一致さる場合は :matches を使用してください。そうしないと、テストの条件が満たされないためテストは失敗します。

imsimta test -exp の構文

imsimta test -exp は、指定した RFC2822 メッセージに対して Sieve 言語ステートメントをテストし、フィルタの結果を標準出力に送ります。

構文は次のとおりです。

imsimta test -exp -mm -block -input=Sieve_language_scriptfile -message=rfc2822_message_file

ここで、

-block は、単一の Sieve スクリプトとして完全な入力を示します。デフォルトでは、各行は別々のスクリプトとして処理され、別々に評価されます。Sieve は、ファイルの終わりに到達したときだけ評価されます。

-input=Sieve_file は、Sieve スクリプトを含むファイルです。デフォルトでは、stdin からテストスクリプト行またはスクリプトブロックが読み込まれます。

-message=message_file は、Sieve スクリプトのテストを実行する RFC 2822 メッセージを含むテキストファイルです。ここには、RFC 2822 メッセージのみが存在する必要があります。キューファイル (zz*.00 ファイル) ではありえません。

このコマンドを有効にすると、スクリプト情報を読み取り、それをテストメッセージと関連させて評価し、結果として出力します。結果には、実行すべきアクションと、スクリプトの最終ステートメントの評価結果が示されます。

このほかに、次のような修飾子が有効です。

-from=address は、エンベロープのテストに使用される from: アドレスを指定します。デフォルトでは、MTA オプション RETURN_ADDRESS によって指定された値が使用されます。

-output=file は、結果を file に書き込みます。デフォルトでは、スクリプトの評価結果が stdout に書き込まれます。