test

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

第 15 章 LMTP 配信

Sun Java System Messaging Server の MTA では、LMTP (Local Mail Transfer Protocol、RFC 2033 で定義) を使用して、複数層のメッセージングサーバーが展開されている環境でメッセージストアに配信できます。受信リレーとバックエンドメッセージストアが使用されるこのような環境では、メーリングリストの拡大などのアドレス拡張と自動返信や転送などの配信方法に関してリレーが重要な役割を果たします。バックエンドストアへの配信はこれまで SMTP 上で行われてきました。SMTP では、バックエンドシステムで LDAP ディレクトリの受取人アドレスを再度調べる必要があるため、MTA の全機能が使用されます。速度と効率性を向上するために、MTA では SMTP ではなく LMTP を使用してバックエンドストアにメッセージを配信できます。Sun Java System Messaging Server の LMTP サーバーは、汎用 LMTP サーバーとしてではなく、リレーとバックエンドメッセージストア間のプライベートプロトコルとして機能します。説明をわかりやすくするために、2 層展開を例にとっています。

注 –

LMTP は多層展開での使用を目的として設計されています。LMTP を単一システム展開で使用することはできません。また、Messaging Server の LMTP サービスは、そのままでは LMTP サーバーまたはほかの LMTP クライアントで動作するように設計されていません。

この章には、次の節があります。

LMTP 配信の特徴

MTA の LMTP サーバーがバックエンドメッセージストアへの配信に関して効率性が高い理由は次のとおりです。

LMTP を使用しない 2 層展開でのメッセージ処理

図 15–1 に、次のような LMTP を使用しない 2 層展開でのメッセージ処理を示します。

図 15–1 LMTP を使用しない 2 層展開

図は、LMTP を使用しない 2 層展開でのメッセージ処理を示します。

LMTP を使用しない場合で、ストアシステムの前にリレーを配備した 2 層展開では、受信メッセージの処理は、リレーマシンのディスパッチャーによってピックアップされ、tcp_smtp_server プロセスにハンドオフされた SMTP ポートの接続から始まります。このプロセスでは、受信メッセージに対して次のような処理が行われます。

次に、メールメッセージはキューから smtp_client プロセスに引き継がれ、メール ホストに送信されます。メールホスト上では、非常によく似た処理が行われます。SMTP ポートへの接続がディスパッチャーによってピックアップされ、tcp_smtp_server プロセスにハンドオフされます。このプロセスでは、メッセージに対して次のような処理が行われます。

次に、メールメッセージは ims_ms プロセスに引き継がれ、ストアへの配信が試行されます。ここでは、キューに入れる処理が 2 回実行されています。また各 MTA はそれぞれ LDAP 検索を実行しています。

LMTP を使用する 2 層展開でのメッセージ処理

「LMTP を使用する 2 層展開でのメッセージ処理」 に、次のような LMTP を使用する 2 層展開でのメッセージ処理を示します。

図 15–2 LMTP を使用する 2 層展開

図は、LMTP を使用する 2 層展開でのメッセージ処理を示します。

LMTP が配備されている場合、リレーマシンの SMTP ポートへの接続がディスパッチャーによってピックアップされ、tcp_smtp_server プロセスにハンドオフされます。このプロセスでは、受信メッセージに対して次のような処理が行われます。

ストアマシンでは、LMTP ポートへの接続がディスパッチャーに受信され、lmtp_server プロセスにハンドオフされます。次に、LMTP サーバーによってメッセージがユーザーのメールボックスまたは UNIX のネイティブメールボックスに挿入されます。メッセージの配信が成功すると、そのメッセージはリレーマシン上でキューから取り出されます。成功しなかった場合は、メッセージはリレーマシンに残ります。メッセージストアの LMTP プロセスでは、アドレスやメッセージの処理に MTA の機能は使用されません。

LMTP の概要

ほとんどの場合、MTA 自体は基本的にバックエンドサーバーで使用されることはありません。必要な MTA コンポーネントは次のとおりです。

ディスパッチャーには MTA 設定ファイルが必要ですが、ファイルは非常に短くすることができます。ディスパッチャーの下で実行する LMTP サーバーを起動できるようにするため、ディスパッチャーはバックエンドサーバーで実行する必要があります。ディスパッチャーと LMTP サーバーは libimta のさまざまな機能を使用するので、これもバックエンドサーバーに存在する必要があります。

LMTP サーバーでは、通常ならば実行される MTA のキューの出し入れ機能、ヘッダー処理、またはアドレス変換が実行されません。メッセージの内容とアドレスについての処理は、すべてリレーシステムで実行されます。処理後は、メッセージストアに送信される正確な形式で、メッセージストアが必要とする形式の配信アドレスがすでに付けられたメッセージが LMTP サーバーに提示されます。ユーザーの制限容量など、メッセージがストアに配信される際に通常使用可能な追加受取人情報は、受取人アドレスとともに LMTP パラメータとして提示されます。配信試行が失敗した場合は、メッセージはリレーシステムの LMTP キューに残ります。

LMTP 配信の設定

LMTP 配信メカニズムを設定するには、リレーマシンの両方とバックエンドストア上での設定が必要です。リレー上では、DELIVERY_OPTIONS MTA オプション (option.dat にある) を変更して、ストアに配信されるメッセージが LMTP チャネルに渡されるようにする必要があります。バックエンドストアはディスパッチャーを使って設定する必要がありますが、ジョブコントローラは必要ありません。LMTP サーバーを実行するには、このディスパッチャーを設定する必要があります。

通常の多層配備では、ユーザーはさまざまなバックエンドメッセージストアのマシン上にプロビジョニングされます。これらのバックエンドマシンの 1 つ以上で LMTP が有効でない場合もあるため、フロントエンドリレーは、どのストアマシンが LMTP を認識するかに注意を払う必要があります。これを行うには、汎用データベース機能を使って、LMTP 配信を受け入れるように設定されているメッセージストアの名前を明示的に指定します。

ProcedureLMTP を使って受信 MTA リレーを設定するには、次の手順に従います。

LMTP を使うように受信 MTA リレーを設定するには、次の手順に従います。

手順

  1. imta.cnf ファイルを変更し、LMTP の書き換えルールを次のように変更します。


    ! lmtp
.lmtp   $E$F$U%$H.lmtp@lmtpcs-daemon
.lmtp   $B$F$U%$H@$H@lmtpcs-daemon
!
! lmtp ネイティブ
.lmtpn  $E$F$U%$H.lmtpn@lmtpcn-daemon
.lmtpn  $B$F$U%$H@$H@lmtpcn-daemon
!

  2. メールボックスの DELIVERY_OPTIONS を次のように変更します。


    #*mailbox=@$X.LMTP:$M%$\$2I$_+$2S@lmtpcs-daemon

  3. ネイティブの DELIVERY_OPTIONS 句を次のように変更します。


    #*native=@$X.LMTPN:$M+$2S@native-daemon

  4. チャネルキーワード multigate connectcanonical を tcp_lmtp* チャネルブロックのそれぞれに追加します。

  5. 次のチャネルキーワードを tcp_lmtpcs チャネルに追加します。


    fileinto @$4O:$U+$S@$D

    上記のキーワード中、「O」は大文字のオー (O) であり、数字のゼロ (0) ではありません。

  6. 受信 MTA リレー設定は、次のようになります。

    DELIVERY_OPTIONS に関する option.dat のエントリは、次のようになります。


    !------------------------------------------
! DELIVERY_OPTIONS を変更し、フロントエンドから
! バックエンドストアへの LMTP 配信をアクティブにする
!--------------------------------------------
!
DELIVERY_OPTIONS=\
    #*mailbox=@$X.LMTP:$M%$\$2I$_+$2S@lmtpcs-daemon,\
    #&members=*,\
    #*native=@$X.LMTPN:$M+$2S@native-daemon,\
    #*unix=@$X.LMTPN:$M,\
    #*file=@$X.LMTPN:+$F,\
    #&@members_offline=*,\
    #/hold=@hold-daemon:$A,\
    #program=$M%$P@pipe-daemon,\
    #forward=**,\
    #*^!autoreply=$M+$D@bitbucket
!

    変更後の imta.cnf 書き換えルールは、次のようになります。


    ! lmtp
.lmtp   $E$F$U%$H.lmtp@lmtpcs-daemon
.lmtp   $B$F$U%$H@$H@lmtpcs-daemon
!
! lmtp ネイティブ
.lmtpn  $E$F$U%$H.lmtpn@lmtpcn-daemon
.lmtpn  $B$F$U%$H@$H@lmtpcn-daemon
!

    変更後のチャネルブロックは、次のようになります。


    !
! tcp_lmtpcs (LMTP クライアント - ストア)
tcp_lmtpcs defragment lmtp  multigate connectcanonical \
   fileinto @$4O:$U+$S@$D port 225 nodns single_sys \
   subdirs 20 maxjobs 7 pool SMTP_POOL dequeue_removeroute
lmtpcs-daemon

!
! tcp_lmtpcn (LMTP クライアント - ネイティブ)
tcp_lmtpcn defragment lmtp multigate connectcanonical port 226 \
   nodns single_sys subdirs 20 maxjobs 7 pool SMTP_POOL 
   dequeue_removeroute
lmtpcn-daemon

MTA を使用せずに LMTP を使用するバックエンドストアを設定するには

バックエンドストアは、LMTP を使用してメッセージを受信する場合、MTA は不要です。つまり、バックエンドストアは、ジョブコントローラも MTA に関連するアドレス書き換え機能も持ちません。ただし、ディスパッチャーと簡単な MTA 設定は必要です。具体的には、dispatcher.cnf ファイルと mappings ファイルが必要です。これらは、MTA 設定の重要な部分のみを含んでいます。

dispatcher.cnf ファイルには、次の内容が含まれている必要があります。


! rfc 2033 LMTP サーバー - ストア
!
[SERVICE=LMTPSS]
PORT=225
IMAGE=IMTA_BIN:tcp_lmtp_server
LOGFILE=IMTA_LOG:tcp_lmtpss_server.log
PARAMETER=CHANNEL=tcp_lmtpss
STACKSIZE=2048000
! 次の行のコメントを解除し、ディスパッチャーが特定のインタフェース
! (HA 環境など) で待機する必要がある場合は、INTERFACE_ADDRESS を
! 適切なホスト IP (ドットで 4 つに区切られた形式) に設定する。
! INTERFACE_ADDRESS=!
! rfc 2033 LMTP サーバー - ネイティブ
!
[SERVICE=LMTPSN]
PORT=226
IMAGE=IMTA_BIN:tcp_lmtpn_server
LOGFILE=IMTA_LOG:tcp_lmtpsn_server.log
PARAMETER=CHANNEL=tcp_lmtpsn
STACKSIZE=2048000
! 次の行のコメントを解除し、ディスパッチャーが特定のインタフェース
! (HA 環境など) で待機する必要がある場合は、INTERFACE_ADDRESS を
! 適切なホスト IP (ドットで 4 つに区切られた形式) に設定する。
!INTERFACE_ADDRESS=

デフォルトでは、dispatcher.cnf ファイルの LMTP サービスはコメントアウトされています。LMTP を使用するには、それらのコメントを解除する必要があります。

通常のディスパッチャーオプションである MAX_CONNS、MAX_PROCS、MAX_LIFE_CONNS、および MAX_LIFE_TIME も設定できますが、使用しているハードウェアに適した設定にする必要があります。

PORT_ACCESS マッピングは重要です。バックエンドサーバーへの LMTP の実装は、Sun Java System Messaging Server リレーとバックエンドストア間のプライベートプロトコルとして機能します。PORT_ACCESS マッピングを使用してこのようなリレーがこれらのサービスに確実に接続できるようにする必要があります。マッピングファイルは次のようになります。


PORT_ACCESS

  TCP|*|225|1.2.3.4|* $Y
  TCP|*|226|1.2.3.4|* $Y
  TCP|*|225|1.2.3.5|* $Y
  TCP|*|226|1.2.3.5|* $Y
  TCP|*|*|*|*   $N500$ Do$ not$ connect$ to$ this$ machine

PORT_ACCESS マッピングテーブルで指定されているサンプルの IP アドレスは、バックエンドストアに接続しているネットワーク上にあるリレーの IP アドレスに置き換える必要があります。

imta.cnf ファイルが存在する必要がありますが、このファイルは設定を完全なものにするためにのみ存在します。もっとも小さい imta.cnf ファイルは、次のチャネル定義で構成されています。

! tcp_lmtpss (LMTP サーバー - ストア)
tcp_lmtpss lmtp 
tcp_lmtpss-daemon

!
! tcp_lmtpsn (LMTP サーバー - ネイティブ)
tcp_lmtpsn lmtp 
tcp_lmtpsn-daemon

デフォルトでは、LMTP チャネル定義はコメントアウトされています。LMTP を機能させたい場合は、コメント行を解除する必要があります。

LMTP を使用してメッセージをメッセージストアと完全な MTA のあるバックエンドシステムに送信するためのリレーを設定する

バックエンドストアに全機能を備えた MTA を配備しながら、LMTP を使用して負荷を抑えたい場合があります。たとえば、バックエンドストアでプログラム配信を行う場合です。この場合、「LMTP を使って受信 MTA リレーを設定するには、次の手順に従います。」の説明に従って、リレーを設定する必要があります。

完全な MTA を備えたバックエンドメッセージストアシステムに LMTP を設定する

バックエンドストアのメッセージングシステムの設定から LMTP によるストアへの直接配信の設定に変更する場合、必要なのは dispatcher.cnf ファイルの最後に次の行を追加することだけです。


! rfc 2033 LMTP サーバー - ストア
![SERVICE=LMTPSS]
PORT=225
IMAGE=IMTA_BIN:tcp_lmtp_server
LOGFILE=IMTA_LOG:tcp_lmtpss_server.log
PARAMETER=CHANNEL=tcp_lmtpss
STACKSIZE=2048000
! 次の行のコメントを解除し、ディスパッチャーが特定のインタフェース 
! (HA 環境など) で待機する必要がある場合は、INTERFACE_ADDRESS を
! 適切なホスト IP (ドットで 4 つに区切られた形式 ) に設定する。
!INTERFACE_ADDRESS=
!
! rfc 2033 LMTP サーバー - ネイティブ
!
[SERVICE=LMTPSN]
PORT=226
IMAGE=IMTA_BIN:tcp_lmtpn_server
LOGFILE=IMTA_LOG:tcp_lmtpsn_server.log
PARAMETER=CHANNEL=tcp_lmtpsn
STACKSIZE=2048000
! 次の行のコメントを解除し、ディスパッチャーが特定のインタフェース
! (HA 環境など ) で待機する必要がある場合は、INTERFACE_ADDRESS を
! 適切なホスト IP (ドットで 4 つに区切られた形式 ) に設定する。
!INTERFACE_ADDRESS=
!

デフォルトでは、dispatcher.cnf ファイルの LMTP サービスはコメントアウトされています。LMTP を使用するには、それらのコメントを解除する必要があります。また、LMTP ポート番号は単なる例であり、任意の番号を選択できます。

これは、LMTP のみに関してバックエンドストアを設定する場合について前述した際の dispatcher.cnf ファイル全体と同じです。LMTP のみのバックエンドストアで説明したように、このマッピングファイルには、PORT_ACCESS マッピングも必要です。

LMTP プロトコルの実装例

この節では、LMTP ダイアログのサンプルを使用して、そこで示される内容を説明します。リレー上の LMTP クライアントでは、標準の LMTP プロトコルを使用してバックエンドストア上の LMTP サーバーと交信します。ただし、このプロトコルは特定の方法で使用されます。例: 


---> LHLO
<--- 250 OK

LHLO メッセージに対してアクションは実行されません。返信は常に 250 OK です。


---> MAIL FROM: address size=messageSizeInBytes
<--- 250 OK

差出人のアドレスに対するチェックまたは変換は行われません。size= パラメータにより、配信されるメッセージのサイズがバイト単位で指定されます。これは、プロトコルで記述されているサイズと同じサイズです。必ずしもメッセージの正確なサイズではありませんが、実際のサイズがこれを超えることはありません。LMTP サーバーによって、メッセージの受信に必要な、このサイズのメモリバッファーが割り当てられます。


---> RCPT TO: uid+folder@domain xquota=size,number xdflg=xxx
<--- 250 OK

受信される際に受取人のアドレスのチェックは行われませんが、受取人の一覧が後で使用するために作成されます。プライマリドメインの uids では、アドレスの @domain の部分は省略されます。また、+folder の部分はオプションです。これは MTA のメッセージストアチャネルで使用されるものと同じアドレス形式です。

xquota= パラメータでは、最大合計サイズと最大メッセージ数で構成されるユーザーのメッセージ制限容量が指定されます。この情報は、アドレス変換を実行するためにユーザーについての LDAP 検索を実行している間に取得されたもので、MTA によって提供されます。また、この情報は、ディレクトリと同期化されたメッセージストアで制限容量の情報を保持するために使用されます。制限容量の情報を取得しても、パフォーマンスヒットが追加で発生することはありません。

xdflg= パラメータではビットフィールドとして解釈される数値が指定されます。このビットによってメッセージの配信方法が制御されます。たとえば、値が 2 であるビットが設定されている場合、ユーザーが制限容量を超えていてもメッセージの配信が保証されます。xdflg は内部パラメータであり、それに含まれるビットは予告なしに変更または追加されることがあるので注意してください。サーバーでこの拡張機能を使用してほかのクライアントをサポートしたり、ほかのサーバーでこのパラメータとともにクライアントを使用することはできません。

この対話は何度も繰り返されます (受取人ごとに 1 回実行)。


--->DATA
---> <メッセージテキスト>
--->.

次に、SMTP の場合と同じように、LMTP クライアントからメッセージ全体がドット付きで送信されます。行にある単独のドット (.) でメッセージは終わります。メッセージサイズが超過している場合、LMTP サーバーは次の内容を送信します。

<--- 500 message too big

その後接続を終了します。

メッセージが正しく受信された場合、LMTP サーバーは RCPT TO: 行で指定されている各受取人のステータスを LMTP クライアントに返します。たとえば、メッセージの配信が成功した場合の応答は次のようになります。

<--- 250 2.5.0 address OK

この address は RCPT TO: 行に表示されたアドレスです。

交信は別の MAIL FROM: 行と繰り返されるか、あるいは次の対話で終了します。


---> quit
<--- 221 OK

表 15–1 に、各受取人のステータスコードを示します。この表には 3 つの列があり、最初の列にショートコード、2 番目の列にそれと同義のロングコード、3 番目の列にステータステキストを示します。2.x.x ステータスコードは成功コード、4.x.x コードは再試行可能なエラー、5.x.x コードは再試行不能なエラーです。

表 15–1 受取人の LMTP ステータスコード

ショートコード 

ロングコード 

ステータステキスト 

250 

2.5.0 

OK 

420 

4.2.0 

Mailbox Locked 

422 

4.2.2 

Quota Exceeded 

420 

4.2.0 

Mailbox Bad Formats 

420 

4.2.0 

Mailbox not supported 

430 

4.3.0 

IMAP IOERROR 

522 

5.2.2 

Persistent Quota Exceeded 

523 

5.2.3 

Message too large 

511 

5.1.1 

mailbox nonexistent 

560 

5.6.0 

message contains null 

560 

5.6.0 

message contains nl 

560 

5.6.0 

message has bad header 

560 

5.6.0 

message has no blank line 

これ以外の場合は、メッセージストアのメールボックス、ネイティブ (したがって UNIX も)、およびファイルの配信オプションに変更があります。これらのルールの目的は、メッセージが適切な LMTP チャネルを介してバックエンドサーバーに送信されるアドレスを生成することです。生成されたアドレスは、次の形式のソースルートされたアドレスになります。


@sourceroute:localpart@domain