test

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

メッセージの処理と配信を設定する

サーバーが特定の条件に基づいてメッセージの配信を試みるように指定できます。また、サービスジョブの処理制限や、新しい SMTP チャネルスレッドを作成するタイミングなど、ジョブ処理に関するパラメータを指定することも可能です。この項では、次の内容について説明します。

メッセージの処理と配信の詳細については、表 12–24 を参照してください。

「メッセージの処理と配信を設定する」に、この節で説明されているキーワードのリストを示します。

表 12–24 メッセージの処理と配信のキーワード

キーワード 

定義 

即時配信

メッセージの即時配信に関する設定を定義します。

immnonurgent

優先度にかかわらず、送信後すべてのメッセージの配信を即座に開始します。 

チャネルの方向性

チャネルを処理するプログラムの種類を指定します。

bidirectional 

チャネルはマスターとスレーブの両方のプログラムによって処理されます。 

master 

チャネルはマスタープログラム (master) によって処理されます。

slave 

チャネルはスレーブプログラム (slave) によって処理されます。

遅延配信

遅延ジョブの配信に関する設定を定義します。

backoff

遅延メッセージの配信試行頻度を指定します。normalbackoff、nonurgentbackoff、urgentbackoff で置き換え可能。

deferred

Deferred-delivery: ヘッダー行の認識と処理を行います。

nodeferred

デフォルト。Deferred-delivery: ヘッダー行が許可されないように指定します。

nonurgentbackoff

優先度が低いメッセージの配信試行頻度。 

normalbackoff

優先度が標準であるメッセージの配信試行頻度。 

urgentbackoff

優先度が高いメッセージの配信試行頻度。 

サイズに基づくメッセージの優先度

サイズに基づいてメッセージの優先度を定義します。

nonurgentblocklimit

指定値以上のサイズを持つメッセージの優先度を「低」以下 (2 番目の優先度) に設定します。該当するメッセージは次の定期ジョブまで処理されません。 

normalblocklimit

指定値以上のサイズを持つメッセージの優先度を「低」に設定します。 

urgentblocklimit

指定値以上のサイズを持つメッセージの優先度を「標準」に設定します。 

チャネル実行ジョブの処理プール

優先度やジョブ期日が異なる処理プールを指定します。

pool

チャネルが動作するプールを指定します。 

after

チャネルが動作するまでの遅延時間を指定します。 

サービスジョブの制限

サービスジョブ数、および 1 つのジョブで処理できるメッセージファイルの最大数を指定します。

maxjobs

1 つのチャネルに対して同時実行できるジョブの最大数を指定します。 

filesperjob

1 つのジョブで処理できるキューエントリの数を指定します。 

SMTP チャネルスレッド

 

threaddepth

マルチスレッド SMTP クライアントに対して新しいスレッドをトリガするために必要なメッセージ数。 

複数アドレス拡張

複数の受取人を持つメッセージ処理を定義します。

expandlimit

アドレスの数がこの制限を超えた場合、着信メッセージを「オフライン」で処理します。 

expandchannel

expandlimit の適用による遅延拡張を実行するチャネルを指定します。 

holdlimit

アドレスの数がこの制限を越えた場合、着信メッセージを保留します。 

トランザクションの制限

接続トランザクションの制限を指定します。

transactionlimit 

1 つの接続について許されるメッセージの数を制限します。 

配信不能メッセージ通知

配信不能メッセージ通知を送るタイミングを指定します。

notices

通知を送り、メッセージを返すまでの時間を指定します。 

nonurgentnotices

優先度が低いメッセージを配信できない場合に通知を送り、そのメッセージを返送するまでの時間を指定します。 

normalnotices

優先度が標準のメッセージを配信できない場合に通知を送り、そのメッセージを返送するまでの時間を指定します。 

urgentnotices

優先度が高いメッセージを配信できない場合に通知を送り、そのメッセージを返送するまでの時間を指定します。 

チャネルの方向性を設定する

キーワード: master、slave、bidirectional

チャネルを処理するプログラムは、マスタープログラム (master)、スレーブプログラム (slave)、あるいは両方のプログラム (bidirectional ) という 3 つのキーワードで指定されます。これらのどのキーワードも指定されていない場合のデフォルトは bidirectional です。これらのキーワードによって、チャネルのキューにメッセージが入れられたときに MTA が配信活動を開始するかどうかが決まります。

これらのキーワードを使用すると、対応するチャネルプログラムの特徴が反映されるようになります。これらのキーワードをいつ、どこで使用すべきかについては、MTA がサポートする各種チャネルの説明を参照してください。

指定配信日を実行する

キーワード: deferred、nodeferred、immnonurgent

deferred チャネルキーワードは、Deferred-delivery: ヘッダー行の認識と処理を行います。未来の deferred 指定配信日が付いているメッセージは、有効期限が切れて返されるか、あるいは指定配信日がくるまでチャネルのキューに保管されます。Deferred-delivery: ヘッダー行の形式と操作の詳細については、RFC 1327 を参照してください。

デフォルトのキーワードは nodeferred です。RFC 1327 では配信日指定によるメッセージ処理のサポートが義務付けられていますが、実際にそれを効果的に行えば、人々がディスク制限容量の拡張手段としてメールシステムを使用できるようになります。

immnonurgent キーワードは、優先度にかかわらず、送信後すべてのメッセージの配信を即座に開始します。

配信失敗メッセージの再配信回数を指定する

キーワード: backoff、nonurgentbackoff、normalbackoff、urgentbackoff、notices

デフォルトでは、配信に失敗したメッセージの再配信回数はメッセージの優先度によって異なります。次にデフォルトの再配信間隔を分単位で示します。優先度に続いて数字が示されていますが、最初の数字は最初に配信に失敗してから再配信を試みるまでの時間 (分) です。

緊急: 30, 60, 60, 120, 120, 120, 240
標準: 60, 120, 120, 240, 240, 240, 480
緊急ではない: 120, 240, 240, 480, 480, 480, 960

優先度が「緊急」のメッセージの場合、最初の配信失敗から 30 分後に再度の配信を試み、再配信から 60 分後に次の再配信、その 60 分後に次の再配信、さらに 120 分後に次の再配信が続きます。最後に示した配信後は同じ間隔で再配信が試みられます。優先度が高いメッセージの場合では 240 分ごとに再配信が試みられます。

再配信が行われるのは、notices、nonurgentnotices、normalnotices、または urgentnotices キーワードで指定された期間内です。期間内に配信が成功しなければ、配信失敗通知が作成され、メッセージは差出人に返送されます。notices キーワードの詳細については、「通知メッセージの配信間隔を設定するには」を参照してください。

backoff キーワードを使うと、優先度ごとにメッセージ再配信間隔を設定することができます。nonurgentbackoff は優先度が低いメッセージの再配信間隔を指定します。normalbackoff は優先度が標準のメッセージの再配信間隔を指定します。urgentbackoff は優先度が高いメッセージの再配信間隔を指定します。backoff のどのキーワードも指定されていなければ、優先度とは無関係に再配信間隔が指定されます。

次に例を示します。

urgentbackoff "pt30m" "pt1h" "pt2h" "pt3h" "pt4h" "pt5h" "pt8h" "pt16h"

これは優先度の高いメッセージの再配信の場合です。最初の配信失敗から 30 分後に再度の配信を試み、再配信から1 時間後 (最初の配信失敗から 1 時間半後) に 2 回目の再配信、その 2 時間後に 3 回目、その 3 時間後に 4 回目、その 4 時間後に 5 回目、その 5 時間後に 6 回目、その 8 時間後に 7 回目、その 16 時間後に 8 回目の再配信をそれぞれ試みます。その後は notices キーワードで指定した期間内まで 16 時間ごとに再配信を試みます。配信が失敗すると、配信失敗の通知が生成され、差出人にメッセージが返されます。間隔の構文は ISO 8601P に記述されており、『Sun Java System Messaging Server Administration Reference』でも説明されています。

次に、優先度が標準のメッセージの例を示します。

normalbackoff "pt30m" "pt1h" "pt8h" "p1d" "p2d” "p1w"

最初の配信失敗から 30 分後に再度の配信を試み、その 1 時間後に 2 回目の再配信、その 8 時間後に 3 回目、その 1 日後に 4 回目、その 2 日後に 5 回目、その 1 週間後に 6 回目の再配信をそれぞれ試みます。その後は notices キーワードで指定した期間内まで毎週、再配信を試みます。配信が失敗すると、配信失敗の通知が生成され、差出人にメッセージが返されます。

最後に、優先度によらない、すべての配信失敗メッセージの例を示します。

backoff "pt30m" "pt120m" "pt16h" "pt36h" "p3d"

nonurgentbackoff、normalbackoff、または urgentbackoff で置き換えなければ、どのメッセージも、最初の配信失敗から 30 分後に再度の配信を試み、その 2 時間後に 2 回目の再配信、その 16 時間後に 3 回目、その 36 時間後に 4 回目、その 3 日後に 5 回目の再配信をそれぞれ試みます。その後は notices キーワードで指定した期間内まで 3 日ごとに再配信を試みます。配信が失敗すると、配信失敗の通知が生成され、差出人にメッセージが返されます。

チャネル実行ジョブの処理プール

キーワード: pool

複数のチャネルが 1 つのプール内で動作するように設定すると、複数のチャネルが同じプールのリソースを共有できるようになります。特定のチャネル専用に指定されているプール内でほかのチャネルが動作するように設定することも可能です。各プール内のメッセージは優先度に基づいて自動的に適切な処理キューに割り当てられます。優先度の高いメッセージは優先度が低いメッセージよりも先に処理されます。(「サイズに基づくメッセージの優先度」を参照。)

pool キーワードを使用すると、ジョブが作成されるプールをチャネルごとに指定できます。pool キーワードの後ろには、現在のチャネルの配信ジョブのプール先となるプール名を指定する必要があります。プール名の長さの上限は 12 バイトです。

ジョブコントローラの概念と設定については、「ジョブコントローラファイル」、「ジョブコントローラファイル」、および 「サービスジョブの制限」を参照してください。

サービスジョブの制限

キーワード: maxjobs、filesperjob

メッセージがチャネルキューに入れられるたびに、ジョブコントローラはメッセージを配信するためのジョブが実行されていることを確認します。これには、新規ジョブプロセスの開始、スレッドの追加、実行中のジョブの確認などの操作が含まれます。しかし、1 つのサービスジョブではすべてのメッセージを手際よく配信できない場合もあります。ジョブコントローラの概念と設定については、「ジョブコントローラファイル」、「チャネル実行ジョブの処理プール」、および 「ジョブコントローラ」を参照してください。

メッセージ配信のために開始されるプロセスやスレッドの数には、妥当な制限があります。このプロセスやスレッド数の上限は、プロセッサの数、ディスクの速度、接続の性質などによって決定されます。MTA 設定ファイルでは、次のものを制御することができます。

1 つのチャネルに対して開始されるプロセス数の上限は、そのチャネルに対して設定されている maxjobs、またはチャネルが動作しているプールに対して設定されている JOB_LIMIT の最小値に当たります。

あるメッセージに処理が必要だとします。一般に、ジョブコントローラは次の場合に新しい処理を開始します。

特に、SMTP チャネルに対しては、異なるホスト宛のメッセージがキューに入るにつれて新しいスレッドやプロセスを開始します。ジョブコントローラは、SMTP チャネルに対し、次に示す基準に基づいて新しいプロセスを開始します。あるメッセージに処理が必要だとします。

「SMTP チャネルスレッド」も参照してください。

filesperjob キーワードを使うと、MTA に追加のサービスジョブを作成するよう指示することもできます。このキーワードには、正の整数を 1 つパラメータとして設定する必要があります。この整数は、チャネルへ送られるべきキューエントリ (ファイル) の数を指定するもので、その後それらのファイルを処理するために複数のサービスジョブが作成されます。パラメータに 0 またはそれ以下の値を指定した場合は、1 つのサービスジョブだけがキューに入れられます。キーワードを指定しないと、パラメータの値は 0 に指定されます。このキーワードの影響は最大化されます。すなわち、算出された大きな方の数値が実際に作成されるサービスジョブの数となります。

filesperjob キーワードは、実際のキューエントリ (ファイル) 数を与えられた値で割って、作成するジョブ数を算出します。各メッセージのキューエントリ数は、single や single_sys キーワード、メーリングリストのヘッダー修正アクション、そのほかさまざまな要素によって決定されます。

maxjobs キーワードは、同時実行可能な合計サービスジョブ数を制限します。このキーワードの後ろには、整数値を指定する必要があります。算出されたサービスジョブ数がこの値より大きい場合には、maxjobs ジョブだけが作成されます。maxjobs が使用されていない場合のデフォルト値は 100 に設定されています。通常、maxjobs には、そのチャネルが使用する 1 つまたは複数のサービスプールで同時実行が可能な合計ジョブ数と同じ値、またはそれ以下の値を使用します。

接続トランザクションの制限を設定する

キーワード: transactionlimit

transactionlimit は、1 つの接続について許されるメッセージの数を制限します。これを使用して、次のように攻撃を阻止できます。

攻撃者が SMTP を介して接続し、正しい電子メールアドレスを推測しようとして多数の RCPT TO コマンドを送信するとします。このような攻撃は、1 つのトランザクションで許可される無効な RCPT TO の回数を制限することによって阻止できます。これに対抗して攻撃者が複数のトランザクションを使用したとしても、1 つの SMTP セッションで許可されるトランザクション数を transactionlimit で制限できます。攻撃者は複数のセッションを使用することはできますが、多大な負担がかかることになります。接続抑制を使用してさまざまな方法でセッション数を制限することで、ほとんどの場合負担を非常に大きくできます。

ただし、阻止する側にも負担はかかります。受取人制限やトランザクション制限、あるいはその両方にうまく対応できない SMTP クライアントもあります。このようなクライアントのために例外をもうける必要があります。ただし、TCP チャネルオプションは無条件で SMTP サーバーに適用されます。これを解決するには、チャネルキーワードと switchchannel を使って、問題になるエージェントをより制限値の高いチャネルにルーティングします。

サイズに基づくメッセージの優先度

キーワード: urgentblocklimit、normalblocklimit、nonurgentblocklimit

urgentblocklimit、normalblocklimit、および nonurgentblocklimit キーワードは、サイズに基づいてメッセージの優先度を下げるように MTA に指定するためのものです。これらのキーワードは、ジョブコントローラがメッセージ処理時に適用する優先度に影響を及ぼします。

SMTP チャネルスレッド

キーワード: threaddepth

マルチスレッドの SMTP クライアントは、メッセージを宛先ごとにそれぞれ異なるスレッドに割り当てるために、送信メッセージを並べ替えます。threaddepth キーワードは、マルチスレッドの SMTP クライアントが 1 つのスレッドに割り当てられるメッセージの数を制限し、それ以上のメッセージがある場合には別のスレッドに割り当てるよう指定します。通常、同じ宛先へのメッセージはすべて 1 つのスレッドによって処理されますが、このキーワードを指定すると、それらのメッセージが複数のスレッドによって処理されるようになります。このキーワードのデフォルト値は 10 です。

チャネルに対するバックログが threaddepth で指定されている以上の数に達すると、ジョブコントローラはより多くのリソースをそのチャネルのキューにあるメッセージの処理に割り当てようとします。チャネルがマルチスレッドの場合、ジョブコントローラはメッセージを処理するジョブがそのチャネルに対して新しくスレッドを開始するように指示し、すべてのジョブのスレッド数がそのチャネルの制限に達している場合 (tcp_* チャネルの MAX_CLIENT_THREADS オプション) は、新しいプロセスを開始するように指示します。シングルスレッドのチャネルに対しては、新しいプロセスを開始するように指示します。ただし、チャネルのジョブ数 (maxjobs) またはプールのジョブ数 (JOB_LIMIT) が制限に達している場合、新しいジョブは開始されません。

基本的に、threaddepth はジョブがどのくらい集中してスケジューリングされるかを制御します。次の 2 つの状況を考えてみましょう。

(1) 標準 (送信) SMTP チャネル

(2) スマートホスト宛転送の SMTP チャネル

ジョブコントローラは、宛先ホストによって特定のチャネルに送信されるメッセージを分類し、それらの宛先ホストのバックログに基づいてメッセージが処理されるようにジョブをスケジューリングします。

(1) の場合は、多数の宛先ホストが存在し、それらのほとんどのバックログは少量になります。多数のスレッドが動作していて、aol、yahoo、hotmail などの大量のトラフィックが存在する宛先ホストを除いて、すべてが良好に機能している必要があります。スレッドの深さが 128 の場合、バックログが 128 に達すると yahoo への配信を行う 2 番目のスレッドだけが取得できます。これは適切な状態とはいえません。

(2) の場合は、1 つの宛先ホストだけが存在し、多数のスレッドがそのホストへの配信を行なっていて、理想的な状態です。あえていうなら、10 というデフォルト値は小さすぎます。

threaddepth キーワードは、チャネルの接続先の SMTP サーバーが複数の接続を同時に処理できる場合に、デーモンルーター TCP/IP チャネル (ある特定の SMTP サーバーに接続する TCP/IP チャネル) 上でマルチスレッドを確立する際に便利です。

複数アドレスの拡張

キーワード: expandlimit、expandchannel、holdlimit

ほとんどのチャネルでは、複数の受取人アドレスを持つメッセージの転送がサポートされています。ただし、1 つのメッセージに多くの受取人アドレスが指定されていると、メッセージ転送処理に遅延 (オンライン遅延) が生じる場合があります。遅延時間が長いとネットワークのタイムアウトが発生し、メッセージの重複送信やその他の問題が発生する可能性があります。

MTA は、1 つのメッセージに特定数以上のアドレスが指定されている場合に配信を遅らせて処理 (オフライン処理) することができます。この方法によって、オンライン遅延を大きく軽減することが可能です。処理のオーバーヘッドを遅らせることはできますが、遅延を完全に回避することはできません。

この機能を有効にするには、たとえば一般的な reprocessing チャネルと expandlimit キーワードを使用します。expandlimit キーワードは、オフライン処理を開始するまでにチャネルから受け入れることのできるメッセージのアドレス数の上限を示す整数の引数をとります。expandlimit キーワードが設定されていない場合のデフォルトは無限大です。引数の値を 0 にすると、そのチャネルで着信したすべてのメッセージがオフラインで処理されます。

expandlimit キーワードは、ローカルチャネルおよび reprocessing チャネルには使用できません。使用すると、予測できない事態が発生する可能性があります。

オフライン処理を行うチャネルを指定するには、expandchannel キーワードを使用します。特に設定を変更しないかぎり、expandchannel が設定されていない場合は reprocessing チャネルが使用されますが、特別な目的のためにはその他の reprocessing チャネルまたは processing チャネルを設定することもできます。expandchannel を使ってオフライン処理を行うチャネルを指定する場合、reprocessing チャネルまたは processing チャネル以外のチャネルを使用することはできません。その他のチャネルを使用すると、予測できない事態が発生する可能性があります。

expandlimit キーワードを適切に機能させるには、reprocessing チャネル (またはオフライン処理を実行するその他のチャネル) を MTA 設定ファイルに追加する必要があります。ただし、MTA 設定ユーティリティーによって生成された設定ファイルを使用しているのであれば、その必要はありません。

非常に多くの宛先アドレスが指定されているのは、不特定多数宛メールの特徴です。holdlimit キーワードは、MTA が特定数以上の宛先アドレスを持つメッセージを受信した場合、そのメッセージを .HELD メッセージとして reprocess チャネル (または expandchannel キーワードが指定するチャネル) のキューに入れるように指示します。メッセージは MTA ポストマスターが手動で介入するまで reprocess キュー内で未処理のまま待機します。

サービス変換を有効にする

キーワード: service、noservice

service キーワードは、CHARSET-CONVERSION エントリにかかわらず、無条件でサービス変換を有効にします。noservice キーワードが設定されている場合、チャネルで受信するメッセージのサービス変換は、CHARSET-CONVERSION で有効にします。