第 12 章 LMTP 配信

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


注	LMTP は多層展開での使用を目的として設計されています。LMTP を単一システム展開で使用することはできません。

LMTP 配信の特徴

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

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

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

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

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

次に、メールメッセージは ims_ms プロセスに引き継がれ、ストアへの配信が試行されます。

ここでは、キューに入れる処理が 2 回実行されています。また各 MTA はそれぞれ LDAP 検索を実行しています。

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

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

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

ディレクトリ内のユーザーを検索する

ユーザーがこの電子メール展開でホストされるドメインに属しているかどうかを判断する

ユーザーがそのドメインで有効なユーザーであるかどうかを判断する

ユーザーのメールボックスをホストしているバックエンドメッセージストアのマシンを特定する

@mailhost:uid@domain.LMTP または @mailhost:uid@domain.LMTPNATIVE という形式にアドレスを書き換える

メールホストに配信するためにメッセージをキューに入れる

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 ダイアログのサンプルを使用して、そこで示される内容を説明します。リレー上の 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 クライアントに返します。たとえば、メッセージの配信が成功した場合の応答は次のようになります。

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

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

表 12-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

LMTP 配信の設定

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

リレーを設定する

デフォルトの設定は、MTA とメッセージストアが同一のシステム上にあるサーバーに適しています。この場合、ユーザーのメッセージストアのメールボックスに定義された配信方法で userid とホストしているドメインからアドレスが作成され、ims_ms チャネルにメールがルーティングされます。LMTP バックエンドストアとのリレーの場合、ほかのシステムにプロビジョンされているユーザーへのメールであっても処理できるようにリレーを設定する必要があります。これは、ほとんどすべてのルールの前に # を付けることで実現されます。これ以外に必要な変更は、LMTP 上のプロキシによってメールストアシステムに実行される必要のあるメソッドに関係します。そのメソッドとは、メッセージストアのメールボックス、ネイティブ (したがって UNIX も)、およびファイルです。

DELIVERY_OPTIONS の値を変更する必要があります。配信オプションの現在のデフォルトは次のとおりです。

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

これにより、メッセージは sourceroute に基づいてルーティングされますが、リモートマシンに提示されるアドレスはそのルーティングから独立したものになります。$X 置換によって、ユーザーの mailhost 属性の値が挿入されます。生成されたソースルートである mailhost.lmtp または mailhost.lmtpn は、imta.cnf ファイルに追加する必要のある .lmtp または .lmtpn ルールのどちらかと一致します。これらによって、2 つの LMTP チャネル (1 つはメッセージストア配信、もう 1 つはネイティブ配信) のどちらかにメッセージが運ばれます。これらの書き換えルールによって、ソースルートで指定されたドメイン名の .lmtp または .lmtpn コンポーネントが取り除かれ、メッセージが正しい LMTP チャネルで正しいメールホストに配信されるようになります。LMTP サーバーに送信されるアドレスは、ソースルーティングアドレスの右側 (つまり「:」の後) にある置換パターンによって定義されます。メールボックスのパターンの場合、これは $M$_+$2S$¥@$2I です。これが userid になり、元のアドレスにフォルダ名がある場合は「+」およびフォルダ名が続きます。ドメインがメール展開の原則的なドメインでない場合は「@」およびホストしているドメインが続きます。ファイルメソッドでは lmtpnative チャネルが使用されますが、プログラム配信メソッドではリレーマシン上での配信が行われることに注意してください。これが適切でない場合は、バックエンドサーバーの MTA を設定する必要があります。このことは LMTP の使用を妨げるものではありませんが、オプションの 1 つなので、後で説明します。

メールボックス配信オプションのパターンが変更されることに注意してください。また、自動返信配信オプションの前に # が付けられていることに注意してください。これはリレーマシン上で強制的にアクションを実行するために付けられています。さらに、ネイティブと UNIX ファイル、およびプログラム配信メソッドを有効にするには、MTA はターゲットマシン上で実行される必要があることに注意してください。

imta.cnf ファイルの書き換えルールセクションに .lmtp* 書き換えルールが含まれるように、imta.cnf ファイルを変更する必要があります。たとえば、次のようになります。

デフォルトでは、LMTP 書き換えルールはコメントアウトされています。LMTP を使用するには、それらのコメントを解除する必要があります。

また、imta.cnf ファイルのチャネル定義セクションに lmtp および lmtpn チャネルの定義を含める必要もあります。たとえば、次のようになります。

デフォルトでは、LMTP チャネル定義はコメントアウトされています。LMTP を使用するには、それらのコメントを解除する必要があります。


注	LMTP チャネルに lmtp チャネルキーワードを必ず使用してください。LMTP チャネルに smtp チャネルキーワードと lmtp チャネルキーワードを一緒に使用しないでください。

最後に、service.http.smtphost configutil パラメータを設定します。これによって、デフォルトは localhost (LMTP ホストのマシン名) に設定されます。また、alarm.msgalarmnoticehost configutil パラメータも設定する必要があります。これによって、メッセージをポストマスターに送信する場合のデフォルトは localhost (LMTP ホストのマシン名) に設定されます。

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 ONE Messaging Server リレーとバックエンドストア間のプライベートプロトコルとして機能します。PORT_ACCESS マッピングを使用してこのようなリレーがこれらのサービスに確実に接続できるようにする必要があります。マッピングファイルは次のようになります。

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

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

デフォルトでは、LMTP チャネル定義はコメントアウトされています。LMTP を使用するには、それらのコメントを解除する必要があります。

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

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

唯一の違いは、# (このマシンで評価) プレフィックスが一部のルールから除かれていることです。members および members_offline に関しては、ロジックが古いロジックに戻されることになります。それによって、メーリングリストに mailhost 属性が定義されていない場合に限り、リレー上のメーリングリストが拡大されます。hold に関しては、.HELD 状態のユーザーへのメッセージが複数のリレーではなくバックエンドストアの保留キューに保管されることになります。プログラムに関しては、要求されたプログラムがユーザーのメールホストで実行されることになります。

ストアシステムで完全な MTA に加えて、SMTP と LMTP の両方を使用している場合の DELIVERY_OPTIONS 設定を次に示します。

完全な 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 マッピングも必要です。