|
| |
| Sun Java System Messaging Server 6 2004Q2 管理ガイド | |
第 15 章
LMTP 配信SunTM ONE 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 配信の特徴MTA の LMTP サーバーがバックエンドメッセージストアへの配信に関して効率性が高い理由は次のとおりです。
LMTP を使用しない 2 層展開でのメッセージ処理図 15-1 に、LMTP を使用しない 2 層展開でのメッセージ処理を示します。
図 15-1 LMTP を使用しない 2 層展開
LMTP を使用しない場合で、ストアシステムの前にリレーを配備した 2 層展開では、受信メッセージの処理は、リレーマシンのディスパッチャによってピックアップされ、tcp_smtp_server プロセスにハンドオフされた SMTP ポートの接続から始まります。このプロセスでは、受信メッセージに対して次のような処理が行われます。
次に、メールメッセージはキューから smtp_client プロセスに引き継がれ、メールホストに送信されます。メールホスト上では、非常によく似た処理が行われます。SMTP ポートへの接続がディスパッチャによってピックアップされ、tcp_smtp_server プロセスにハンドオフされます。このプロセスでは、メッセージに対して次のような処理が行われます。
次に、メールメッセージは ims_ms プロセスに引き継がれ、ストアへの配信が試行されます。
ここでは、キューに入れる処理が 2 回実行されています。また各 MTA はそれぞれ LDAP 検索を実行しています。
LMTP を使用する 2 層展開でのメッセージ処理図 15-2 に、LMTP を使用する 2 層展開でのメッセージ処理を示します。
図 15-2 LMTP を使用する 2 層展開
LMTP が配備されている場合、リレーマシンの SMTP ポートへの接続がディスパッチャによってピックアップされ、tcp_smtp_server プロセスにハンドオフされます。このプロセスでは、受信メッセージに対して次のような処理が行われます。
user@domain.LMTP および user@domain.LMTPNATIVE という形式のアドレスは、前者は tcp_lmtp チャネル、後者は tcp_lmtpnative チャネルを介してメッセージストアシステムにルーティングされます。これらのチャネルは、SMTP ではなく LMTP を使用してバックエンドメッセージストアと通信します。ストアマシンでは、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 配信を受け入れるように設定されているメッセージストアの名前を明示的に指定します。
LMTP を使って受信 MTA リレーを設定するには、次の手順に従います。
LMTP を使うように受信 MTA リレーを設定するには、次の手順に従います。
- option.dat. に次の行を追加して、テキストデータベースを有効にします。
USE_TEXT_DATABASES=1
この手順では、汎用データベースの平文テキストファイルの使用が MTA で有効になっています。すでに汎用データベースを使用している場合は、この手順を飛ばしてもかまいません。
- 汎用データベースのテキストファイルを作成または変更します。
ご覧のとおり、2 つのタイプのエントリがあります。1 つは lmtpnative に対するユーザー固有の配信を処理するためのものであり、もう 1 つは、tcp_lmtpcs チャネル経由の配信のストア全体での設定を処理するためのものです。
- LMTP 書き換え規則を imta.cnf file に追加します。
# cd /opt/SUNWmsgsr/config/
# cp imta.cnf imta.cnf.orig
# vi imta.cnf
!
! pipe
.pipe-daemon $U%$H.pipe-daemon@pipe-daemon
!
! tcp_local
! Rules for top level internet domains
<IMTA_TABLE:internet.rules
!
! Do mapping lookup for internal IP addresses
[] $E$R${INTERNAL_IP,$L}$U%[$L]@tcp_intranet-daemon
!
! Do general.txt lookup for lmtp hosts
.domain-name.com $S$U%$H$D@$(LMTP_CN|$U@$H$D)
.domain-name.com $S$U%$H$D@$(LMTP_CS|$H$D)
!
! tcp_intranet
! Do mapping lookup for internal IP addresses
[] $E$R${INTERNAL_IP,$L}$U%[$L]@tcp_intranet-daemon
.domain-name.com $U%$H.domain-name.com@tcp_intranet-daemon
この手順では、1 組の書き換え規則により、アドレスの発信元経路指定部分が LMTP 配信のためのエントリと一致するかどうかを確認するため、汎用データベースのタグ付けのプローブが実行されます。手順 2 で作成した general.txt ファイルには、適切なチャネルを経由してバックエンドメッセージストアに配信を指定する、タグ付きエントリがあります。ここで、書き換え規則にある $S は、アドレスに発信元経路指定が含まれているときのみ適用されることを意味します。汎用データベース内のエントリに一致するものがあれば、書き換え規則は成功し、メッセージは、LMTP 経由で配信を行う tcp_lmtpX チャネル経由で、発信元経路指定のバックエンドホストに送信されます。
一致するものがなければ、その他の書き換え規則で一致するものが見つかるまで、書き換えプロセスが継続します。ほとんどの場合、汎用データベースのプローブを介して一致するものが見つからない場合、メッセージは SMTP 経由で配信を行う tcp_intranet チャネルを経由して経路指定されます。
- imta.cnf に新しいチャネルブロックを追加します。
また、imta.cnf ファイルのチャネル定義セクションにある lmtp および lmtpn チャネルにチャネル定義を組み込む必要もあります。
例 :
! tcp_lmtpcs (LMTP client - store)
tcp_lmtpcs defragment lmtp port 225 nomx single_sys subdirs 20 maxjobs 7 pool SMTP_POOL dequeue_removeroute
lmtpcs-daemon
!
! tcp_lmtpcn (LMTP client - native)
tcp_lmtpcn defragment lmtp port 226 nomx 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 subdirs 20
tcp_lmtpss-daemon
!
! tcp_lmtpsn (LMTP サーバー - ネイティブ)
tcp_lmtpsn lmtp subdirs 20
tcp_lmtpsn-daemon
デフォルトでは、LMTP チャネル定義はコメントアウトされています。LMTP を機能させたい場合は、コメント行を解除する必要があります。
LMTP を使用してメッセージをメッセージストアと完全な MTA のあるバックエンドシステムに送信するためのリレーを設定する
バックエンドストアに全機能を備えた MTA を配備しながら、LMTP を使用して負荷を抑えたい場合があります。たとえば、バックエンドストアでプログラム配信を行う場合です。この場合、上記の説明に従って、LMTP を使用してバックエンドストアに配信するリレーを設定する必要があります。
完全な 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 です。
差出人のアドレスに対するチェックまたは変換は行われません。size= パラメータにより配信されるメッセージのサイズがバイト単位で指定されます。これは、プロトコルで記述されているサイズと同じサイズです。必ずしもメッセージの正確なサイズではありませんが、実際のサイズがこれを超えることはありません。LMTP サーバーによって、メッセージの受信に必要な、このサイズのメモリバッファが割り当てられます。
受信される際に受取人のアドレスのチェックは行われませんが、受取人の一覧が後で使用するために作成されます。プライマリドメインの uids では、アドレスの @domain の部分は省略されます。また、+folder の部分はオプションです。これは MTA のメッセージストアチャネルで使用されるものと同じアドレス形式です。
xquota= パラメータでは、最大合計サイズと最大メッセージ数で構成されるユーザーのメッセージ制限容量が指定されます。この情報は、アドレス変換を実行するためにユーザーについての LDAP 検索を実行している間に取得されたもので、MTA によって提供されます。また、この情報は、ディレクトリと同期化されたメッセージストアで制限容量の情報を保持するために使用されます。制限容量の情報を取得しても、パフォーマンスヒットが追加で発生することはありません。
xdflg= パラメータではビットフィールドとして解釈される数値が指定されます。このビットによってメッセージの配信方法が制御されます。たとえば、値が 2 であるビットが設定されている場合、ユーザーが制限容量を超えていてもメッセージの配信が保証されます。
この対話は何度も繰り返されます (受取人ごとに 1 回実行)。
次に、SMTP の場合と同じように、LMTP クライアントからメッセージ全体がドット付きで送信されます。行にある単独のドット (.) でメッセージは終わります。メッセージサイズが超過している場合、LMTP サーバーは次の内容を送信します。
その後接続を終了します。
メッセージが正しく受信された場合、LMTP サーバーは RCPT TO: 行で指定されている各受取人のステータスを LMTP クライアントに返します。たとえば、メッセージの配信が成功した場合の応答は次のようになります。
この address は RCPT TO: 行に表示されたアドレスです。
交信は別の MAIL FROM: 行と繰り返されるか、あるいは次の対話で終了します。
表 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 チャネルを介してバックエンドサーバーに送信されるアドレスを生成することです。生成されたアドレスは、次の形式のソースルートされたアドレスになります。
