Sun Java System Messaging Server 6 2004Q2 管理ガイド |
第 20 章
ログ記録とログ解析Messaging Server では、ログファイルを作成して、管理に関連するサーバーのイベント、サーバーでサポートされているプロトコル (SMTP、POP、IMAP、HTTP) を使用した通信関連のイベント、およびサーバーで処理されるその他のプロセスに関するイベントを記録できます。このログファイルを調べれば、サーバーのアクションをさまざまな観点からモニターすることができます。
MTA は他のサービスとは異なるログ機能を使用しているため、コンソールを使ってログサービスを設定したり、ログを表示したりすることはできません。その代わり、設定ファイルに情報を指定することで、MTA のログ機能を設定します。この章は、以下のように 3 部構成になっています。第 1 部では概要について、第 2 部ではメッセージストアおよび管理サービスのログ、第 3 部では MTA サービスのログについて説明します。
「第 2 部 : サービスログ (メッセージストア、管理サーバー、MTA)」
第 1 部: 概要Messaging Server ログファイルの作成と管理のためにポリシーをカスタマイズすることができます。この章では、ログファイルの種類と構造、およびログファイルの管理と表示方法について説明します。この章には、以下の節があります。
ログ記録されるサービス
Messaging Server は、サポートしている主なプロトコル (サービス) ごとに一連のログファイルを作成します。ログファイルは、msg_svr_base/data/log にあります。各種類のログファイルは、個別にカスタマイズしたり表示したりすることができます。表 20-1 に、ログ記録が可能なサービスのリストとそれぞれのログファイルに関する説明を示します。
サードパーティ製のツールを使ってログを解析する
Messaging Server ではサポートされていないログ解析やレポート生成を行うには、別のツールを使用する必要があります。ログファイルは、テキストエディタや標準のシステムツールで操作できます。
正規表現による構文解析をサポートするスクリプト可能なテキストエディタを使用すると、この章で説明しているような特定の条件に基づくログエントリの検索や抽出を行い、その結果を並べ替えたり、集計や統計を行うこともできます。
UNIX 環境では、UNIX のsyslog ファイルを操作するために開発された既存のレポート生成ツールを変更して使用することもできます。パブリックドメインの syslog 操作ツールを使用する場合は、そのツールにおいて、日付 / 時刻形式と、Messaging Server のログエントリにはあって syslog エントリにはない 2 つの特殊コンポーネント (facility と logLevel) の変更が必要になる場合があります。
第 2 部 : サービスログ (メッセージストア、管理サーバー、MTA)この節では、以下のサービスのログについて説明します。POP、IMAP、HTTP、MTA、Admin、および Default (表 20-1 を参照)。
これらのサービスの場合、コンソールを使用してログの設定と表示を行うことができます。設定内容は、どのイベントを何件まで記録するかに影響します。これらの設定とその他の特徴を使用して、ログファイル解析時のログイベントの検索条件を微調整することができます。MTA のサービスログの詳細については、「第 3 部 : サービスログ (MTA)」を参照してください。
第 2 部には以下の節があります。
ログの特徴
ここでは、メッセージストアと管理サービスに関するログの特徴 (ログレベル、ログイベントのカテゴリ、ログファイル名の命名ルール、ログファイルのディレクトリ) について説明します。
ログレベル
ログのレベル (優先順位) は、ログのアクティビティの詳細度を定義します。優先順位レベルが高いほど、詳細度は低くなります。優先順位 (重要度) の高いイベントだけがログに記録されるためです。レベルを下げると、ログは詳細なものとなり、より多くのイベントがログファイルに記録されます。
ログレベルは、logfile.service.loglevel 設定パラメータを設定することによって、POP、IMAP、HTTP、Admin、およびデフォルトの各サービスごとに個別に設定できます (「ログオプションを定義、設定する」を参照)。また、ログレベルを使用して、ログイベントを検索するときにフィルタリングすることもできます。表 20-2 に、利用可能なレベルを示します。これらのログレベルは、UNIX の syslog 機構で定義されるログレベルのサブセットです。
特定のログレベルを選択すると、そのレベルのイベントとそれ以上のレベル (詳細度の低い) のイベントがログに記録されます。デフォルトのログレベルは、Notice です。
注
より詳細なログを指定するほど、ログファイルがより多くのディスク容量を占有することになります。ガイドラインについては、「ログオプションを定義、設定する」を参照してください。
ログイベントのカテゴリ
サポートされているサービスまたはプロトコル内で、Messaging Server は、どの機能領域で発生したかに基づいて、ログイベントをより細かくカテゴリに分類します。各ログイベントには、それを生成した機能領域の名前が含まれています。これらのカテゴリは、イベントを検索する際のフィルタリングに使用できます。表 20-3 に、Messaging Server がログのために認識するカテゴリのリストを示します。
ログ検索でカテゴリをフィルタとして使用する場合の例については、「ログを検索、表示する」を参照してください。
メッセージストアと管理サービスのログファイル名の命名ルール
POP、IMAP、HTTP、Admin、および Default サービスのログファイルには、同一のネーミングルールが適用されます。各ログファイル名の形式は、以下のとおりです。
service.sequenceNum.timeStamp
表 20-4 に、メッセージストアのログファイル名の命名ルールを示します。
たとえば、imap.63.915107696 という名前のログファイルは、IMAP ログファイルのディレクトリで 63 番目に作成されたログファイルであり、1998 年 12 月 31 日午後 12 時 34 分 56 秒に作成されたログファイルです。
無制限のシーケンス番号をタイムスタンプと組み合わせることによって、解析するファイルのローテーション、有効期間、および選択がより柔軟になります。詳細は、「ログオプションを定義、設定する」を参照してください。
ログファイルのディレクトリ
ログ記録される各サービスごとに、1 つのディレクトリが割り当てられ、ログファイルはそこに保存されます。IMAP ログファイルや POP ログファイルなどの各サービスのログファイルは、それぞれのディレクトリ内に一緒に保存されます。各ディレクトリの場所、そのディレクトリ内に保存できるログファイルの数、およびファイルのサイズを設定することができます。
すべてのログファイルを保存するのに十分な容量があることを確認してください。ログレベルが低い (詳細度が高い) ほど、ログファイルのサイズは大きくなります。
ログレベル、ログローテーション、ログの有効期間、およびサーバーのバックアップポリシーを正しく定義することが重要です。ログファイルディレクトリのすべてがバックアップされ、また、過負荷にならないようにするためです。これらを正しく定義しないと、情報を失ってしまうことがあります。「ログオプションを定義、設定する」を参照してください。
ログファイルの形式
Messaging Server によって作成されたメッセージストアおよび管理サービスのログファイルのコンテンツの形式は、すべて同じです。ログファイルは複数行のテキストファイルであり、各行に 1 つのログイベントが記述されています。サポートされている各サービスに対するすべてのイベントは、通常は以下のような形式で記述されています。
dateTime hostName processName[pid]: category logLevel:eventMessage
表 20-5 に、ログファイルのコンポーネントを示します。このイベント記述形式は、日付 / 時刻形式が異なることと追加コンポーネント (category と logLevel) があることを除けば、UNIX の syslog 機構で定義されているものと同じです。
表 20-5 メッセージストアと管理サービスのログファイルのコンポーネント
コンポーネント
定義
dateTime
イベントがログ記録された日付と時刻。dd/mm/yyyy hh:mm:ss の形式で表記される。時間帯フィールドは GMT を基準とした +/-hhmm で表記される
例 : 02/Jan/1999:13:08:21 -0700hostName
サーバーが動作しているホストマシンの名前。たとえば、showshoe
注 : ホスト上に複数の Messaging Server インスタンスがある場合は、プロセス ID (pid) を使用して、ログイベントのインスタンスを区別することができる
processName
イベントを生成したプロセスの名前。たとえば、cgi_store
pid
イベントを生成したプロセスのプロセス ID。たとえば、18753
category
イベントが属するカテゴリ。たとえば、General (表 20-3 を参照)
logLevel
イベントのログレベル。たとえば、Notice (表 20-2 を参照)
eventMessage
イベント固有の説明メッセージで、長さは任意。たとえば、Log created (894305624)
以下に、コンソールを使って表示したログイベントの例を示します。
02/May/1998:17:37:32 -0700 showshoe cgi_store[18753]:
General Notice:
Log created (894155852)04/May/1998:11:07:44 -0400 xyzmail cgi_service[343]: General Error:
function=getserverhello|port=2500|error=failed to connect03/Dec/1998:06:54:32 +0200 SiroePost imapd[232]: Account Notice:
close [127.0.0.1] [unauthenticated] 1998/12/3 6:54:32
0:00:00 0 115 0IMAP および POP のイベントエントリの末尾は、3 つの数になることがあります。上記の例では次の 3 つの数です。
0 115 0。最初の数字はクライアントによって送信されたバイト数、2 番目の数字はサーバーによって送信されたバイト数、3 番目の数字は選択されたメールボックス (POP の場合は常に 1) です。ログファイルを「ログビューア」ウィンドウに表示するときは、特定のログレベルやカテゴリ、または特定のプロセス ID などのイベント内の特定のコンポーネントを検索することによって、表示するイベントを制限することができます 詳細は、「ログを検索、表示する」を参照してください。
各ログエントリのイベントメッセージは、記録されるイベントのタイプに固有の形式です。つまり、各サービスのイベントメッセージに表示される内容は、各サービスによって定義されています。多くのイベントメッセージは単純で明白なものですが、複雑なものもあります。
ログオプションを定義、設定する
メッセージストアおよび管理サービスのログ設定は、管理者のニーズに合わせて定義することができます。ここでは、最適な設定とポリシーを決定するために役立つ情報と、それらの適用方法を説明します。
柔軟なログ構造
ログファイルのネーミングの形式 (service.sequenceNum.timeStamp) により、柔軟なログローテーションとバックアップポリシーを設計することができます。イベントはサービスごとに別のファイルに記録されるため、問題をすばやく簡単に隔離することができます。また、ファイル名の中のシーケンス番号は常に増え続け、タイムスタンプは常に一意であるため、指定したシーケンス番号の限界に達しても、新しいログファイルが古いログファイルを単純に上書きしてしまうことはありません。古いログファイルの上書きや削除が行われるのは、ログファイルの保存期間や最大数、合計ログ容量など、より柔軟性のある制限がその限界に達したときだけです。
Messaging Server では、管理やバックアップを簡素化できるように、ログファイルの自動ローテーションがサポートされています。後続のログイベントを記録するために、手動で現在のログファイルを回収して新しいログファイルを作成する必要はありません。現在のログファイル以外、ディレクトリ内にあるものはすべて、サーバーを停止したり、新しいログファイルの作成をサーバーに手動で指定しなくても、いつでもバックアップすることができます。
ログポリシーを設定する際に、合計ログ容量、ログファイルの最大数、個々のファイルサイズ、ファイルの最長保存期間、およびログファイルローテーションの頻度といったオプションを、サービスごとに設定することができます。
適切なオプションを決定する
複数の制限を設定する必要があることと、それらの中にはログファイルのローテーションや削除を引き起こすものがあることを理解しておいてください。最初に限界に達する制限が、制御の中心となります。たとえば、ログファイルの最大サイズを 3.5M バイトに設定し、毎日新しいログを作成するように設定したとします。しかし、24 時間以内に 3.5M バイト以上のデータが記録される場合は、1 日に複数のログファイルが作成されることになります。このため、ログファイルの最大数が 10 個、最長保存期間が 8 日に設定されている場合でも、ログのローテーションが早いため、8 日間経過する前に 10 個のファイルが作成され、最長保存期間まで達することはありません。
以下は Messaging Server の管理ログに備えられているデフォルト値であり、適切なオプションを決定する際に役立ちます。
ディレクトリ内のログファイルの最大数 : 10
ログファイルの最大サイズ : 2M バイト
全ログファイルの合計最大サイズ : 20M バイト
最小空きディスク容量 : 5M バイト
ログロールオーバー時間 : 1 日
最長有効期間 : 7 日
ログのレベル : Noticeこの設定の場合、サーバー管理ログのデータは 1 日当たり約 2M バイト蓄積され、バックアップは週 1 回作成され、管理ログの保存に割り当てられている合計容量は最低 25M バイトです。ログレベルがより詳細な場合、これらの設定では不十分なことがあります。
POP、IMAP、または HTTP のログの場合も、同様の設定から始めるとよいでしょう。すべてのサービスのログ容量要件が上記のデフォルト値とほとんど同じである場合、最初は約 150M バイトの合計ログ容量を設定することをお勧めします。ここに示した設定はあくまでも一般例であり、実際の条件はこれとかなり異なる場合があります。
ログオプションを設定するには
メッセージストアのログ設定を制御するオプションは、コンソールまたはコマンド行を使用して設定することができます。
これらのオプションの最適な設定は、ログデータの累積される頻度によって異なります。1M バイトの保存領域には、約 4,000 〜 10,000 件のログエントリを記録できます。適度にビジー状態のサーバーでは、ログレベルが低い場合 (Notice など)、週に何百メガバイトものログデータが記録されることもあります。以下の設定を参考にしてください。
ログ情報は、サーバーが提供するログファイルではなく、syslog 機構に送るように選択することもできます。ログ情報を syslog に送るには、syslogfacility オプションを以下のように設定します。
configutil -o logfile.service.syslogfacility -v value
ここで、service は admin、pop、imap、imta、または http で、value は user、mail、daemon、local0 から local7、または none です。
値が設定されると、設定値に対応する syslog 機構のログにメッセージが記録され、その他のすべてのログファイルサービスオプションが無視されます。オプションが設定されていない場合、または値が none の場合、Messaging Server ログファイルが使用されます。
コンソール コンソールを使用してログオプションを設定するには、以下の手順に従います。
- ログファイルオプションを設定する Messaging Server を開きます。
- 「設定」タブをクリックし、左側のパネルで「ログファイル」フォルダを開き、サービス (IMAP、HTTP、Admin など) のログファイルを選択します。
- 「詳細レベル」ドロップダウンリストからログレベルを選択します。
- 「ログファイルのディレクトリパス」フィールドに、ログファイルの保存先となるディレクトリの名前を入力します。
- 「各ログのファイルサイズ」フィールドに、ログファイルの最大サイズを入力します。
- 「新規ログエントリの作成」フィールドに、ログローテーションのスケジュールの値を入力します。
- 「ディレクトリ当たりのログ数」および「ログが次の日付よりも古い場合」フィールドに、バックアップスケジュールを考慮に入れて、最大ログファイル数と期限を示す値を入力します。
- 「ログサイズの合計が次の値を超えたとき」フィールドに、合計保存領域の上限を入力します。
- 「残りディスク容量が次の値以下になった場合」フィールドに、確保しておく空きディスク容量の最小値を入力します。
コマンド行 コマンド行でログオプションを設定するには、以下の例のように configutil コマンドを使用します。
使用しているシステムが HTTP メッセージアクセス (Web メール) をサポートしていない場合は、次の変数を設定して HTTP のログを無効にできます。システムに Web メールサポート (たとえば、Messenger Express) が必要な場合は、これらの変数を設定しないでください。
configutil -o service.http.enable -v noconfigutil -o service.http.enablesslport -v no
ログレベルを設定するには、以下のように指定します。
configutil -o logfile.service.loglevel -v level
ここで、service は admin、pop、imap、imta、または http で、loglevel は Nolog、Critical、Error、Warning、Notice、Information、または Debug です。
ログファイルのディレクトリパスは、以下のように指定します。
configutil -o logfile.service.logdir -v dirpath
各ログの最大ファイルサイズは、以下のように指定します。
configutil -o logfile.service.maxlogfilesize -v size
size にはバイト数を指定します。
ログローテーションのスケジュールは、以下のように指定します。
configutil -o logfile.service.rollovertime -v number
number には秒数を指定します。
ディレクトリ内の最大ログファイル数は、以下のように指定します。
configutil -o logfile.service.maxlogfiles -v number
保存容量の上限は、以下のように指定します。
configutil -o logfile.service.maxlogsize -v number
number にはバイト数を指定します。
確保しておく空きディスク容量の最小値は、以下のように指定します。
configutil -o logfile.service.minfreediskspace -v number
number にはバイト数を指定します。
ログの保存期間は、以下のように指定します。
configutil -o logfile.service.expirytime -v number
number には秒数を指定します。
ログを検索、表示する
コンソールには、メッセージストアおよび管理サービスに関するログデータを表示するための基本的なインタフェースがあります。個々のログファイルを選択したり、それらのファイル内で柔軟なフィルタリングによる検索を行うことができます。
ログファイルはサービスごとに分かれており、それぞれ作成順に一覧表示されます。検索するログファイルを選択したら、検索パラメータを指定して検索対象を個々のイベントに限定することができます。
検索パラメータ
以下に、表示するログデータを指定するための検索パラメータを示します。
- 期間 : イベントを検索する期間の開始と終了を指定するか、検索する日数 (現時点からさかのぼる日数) を指定する。サーバーのクラッシュやその他の問題の原因となったログイベントを調べるために、通常は期間の範囲を指定する。また、現在のログファイルの中で今日のイベントだけを見る場合は、期間を 1 日に指定することもできる
- ログのレベル : ログレベルを指定できる (「ログレベル」を参照)。特定の問題を検出するために該当するレベルを選択する。たとえば、サーバーがダウンした原因を調べる場合は Critical、失敗したプロトコルコールを検出する場合は Error を選択する
- 機能領域 : 機能領域を指定できる (「ログイベントのカテゴリ」を参照)。問題が含まれている機能領域がわかっている場合は、その機能領域を選択することができる。たとえば、サーバーのクラッシュにディスクエラーが関連していると思われる場合は Store、問題が IMAP プロトコルコマンドエラーにあると思われる場合は Protocol を選択する
- テキスト検索パターン : テキスト検索パターンを指定して検索対象を絞ることができる。検索するイベントについてすでにわかっている、イベント時刻、プロセス名、プロセス ID、およびイベントメッセージの一部 (リモートホスト名、関数名、エラー番号など) などのイベントコンポーネント (「ログファイルの形式」を参照) を、ワイルドカードを使用して検索することができる
注 : 検索では大文字と小文字が区別されます。
以下に、ログレベルと機能領域を組み合わせた、表示するログの検索例を示します。
検索対象を指定し、結果を表示するには
指定したサービスに属する固有の特徴を持つログイベントを検索するには、以下の手順に従います。
- コンソールで、調べるログファイルがある Messaging Server を開きます。
- 以下のいずれかの方法で、指定したサービスログの「ログファイルの内容」タブを表示します。
- ログに記録されたサービスの「目次」タブが表示されます。
- 「ログファイル名」フィールドで、調べたいログファイルを選択します。
- 「選択したログの表示」ボタンをクリックして「ログビューア」ウィンドウを開きます。
- 「ログビューア」ウィンドウで、検索パラメータを指定します (前述の「検索パラメータ」を参照)。
- 「更新」をクリックして検索を実行し、「ログエントリ」フィールドに結果を表示します。
第 3 部 : サービスログ (MTA)MTA は、メッセージがキューに出し入れされるたびにログを作成することができます。また、ディスパッチャエラーとデバッグ出力も生成できます。第 3 部には以下の節があります。
チャネルごとにログを制御したり、すべてのチャネル上のメッセージアクティビティのログを記録するよう指定することができます。初期設定では、すべてのチャネルでのログ記録が無効になっています。
ログを有効にすると、メッセージが MTA チャネルを通過するたびに mail.log* ファイルにエントリが書き込まれます。これらのログエントリは、MTA (または特定のチャネル) を通過するメッセージの数の統計を取ったり、メッセージが送信または配信されたかどうか、いつ送信または配信されたかを調べるときに役立ちます。
特定の MTA チャネルを通過するメッセージの数の統計をとるだけであれば、その該当する MTA チャネルだけでログチャネルキーワードを有効にしてもかまいません。ほとんどのサイトでは、すべての MTA チャネルでのログを有効にしています。特に、問題を突き止める場合、問題を診断する最初のステップは、メッセージが意図していたチャネルに送られているかどうかに注目することです。すべてのチャネルに対してログを有効にしておくと、このような問題を調べる際に役立ちます。
警告
ログが有効になっている場合は、mail.log が大きくなり続けるため、そのままにしておくと利用可能なディスク容量がなくなってしまいます。このファイルのサイズをモニターし、定期的に不要なコンテンツを削除してください。ファイル全体を削除することもできます。この場合、必要に応じて新しいファイルが作成されます。
MTA のログを有効にするには
特定のチャネルのログを有効にするには、以下のように MTA 設定ファイルのチャネル定義に logging キーワードを追加します。
channel-name keyword1 keyword2 logging
また、ログファイルやログレベルなどのディレクトリパスのような設定パラメータの数も、設定することができます。「第 2 部 : サービスログ (メッセージストア、管理サーバー、MTA)」を参照してください。
すべてのチャネルのメッセージアクティビティをログファイルに記録する場合は、MTA 設定ファイルのチャネルブロックセクションの defaults チャネルに、logging キーワードを (「チャネルのデフォルトを設定する」を参照) 追加します。
例 :defaults logging notices 1 2 4 7 copywarnpost copysendpost postheadonly noswitchchannel immnonurgent maxjobs 7 defaulthost siroe.com
l defragment charset7 us-ascii charset8 iso-8859-01
siroe.comメッセージがキューに入ったりキューから取り出されるたびに、メッセージがログに記録されます。ログエントリはすべて msg_svr_base/data/logmail.log_current に記録されます。
毎晩午前 0 時頃に実行されるメッセージ返送ジョブは、累積されたログファイル mail.log に既存の mail.log_yesterday を追加し、現在の mail.log_current ファイルの名前を mail.log_yesterday に変更してから、新しい mail.log_current ファイルを開始します。connection.log* ファイルに対しても同様の処理が行われます。
LOG_MESSAGES_SYSLOG オプションを 1 に設定すると、MTA ログメッセージを syslog (UNIX) に送ることができます。0 はデフォルトで、syslog (イベントログ) ログを実行しないことを示します。
その他の MTA ログオプションを指定するには
ログが有効になっているときに与えられる基本的な情報のほかにも、MTA オプションファイルにさまざまな LOG_* MTA オプションを設定することにより、オプションの情報フィールドを含めることができます。オプションファイルの詳細については、『Messaging Server Reference Manual』を参照してください。
- LOG_MESSAGE_ID : エントリとメッセージの相関関係を示すことができる
- LOG_FILENAME : 特定のメッセージファイルの配信試行回数を、即座に確認しやすくなります。また、MTA が複数の受取人宛のメッセージを、どのような場合に別々のメッセージファイルに分割してディスク上に保存するのかを知る際にも役立つ
- LOG_CONNECTION : TCP/IP 接続とメッセージトラフィックのログが記録される。接続のログエントリは、デフォルトでは mail.log* ファイルに書き込まれるが、connection.log* ファイルに書き込むこともできます。SEPARATE_CONNECTION_LOG オプションを参照
- SEPARATE_CONNECTION_LOG : 接続のログエントリを connection.log ファイルに書き込むように指定する際に使用する
- LOG_PROCESS : LOG_CONNECTION とともに使用すると、接続エントリとそれに対応するメッセージエントリの相関関係をプロセス ID によって示すことができる
- LOG_USERNAME : メールをキューに入れるプロセスに関連付けられたユーザー名を mail.log ファイルに保存するかどうかを制御します。SASL (SMTP AUTH) を使用している SMTP 送信の場合は、ユーザー名フィールドが認証ユーザー名 (プレフィックスとしてアスタリスクが付いたもの) になる
MTA ログエントリの形式
MTA ログファイルは、ASCII テキストとして記述されます。デフォルトでは、次に示すように、各ログファイルエントリには 8 個または 9 個のフィールドがあります。
19-Jan-1998 19:16:57.64 l tcp_local E 1 adam@sesta.com
rfc822;marlowe@siroe.com marlowe@siroe.com
ログエントリには以下の情報が含まれています。
- エントリが記録された日付と時刻 (例 : 19-Jan-1998 19:16:57.64)。
- ソースチャネルのチャネル名 (上の例では l)。
- 宛先チャネルのチャネル名 (上の例では tcp_local)。SMTP チャネルの場合、LOG_CONNECTION が有効になっているときは、プラス記号「+」が SMTP サーバーの受信を示し、マイナス記号「-」が SMTP クライアント経由の送信を示します。
- エントリのタイプ (E)。表 20-6 を参照。
- メッセージのサイズ (1)。デフォルトではキロバイト単位で表されますが、MTA オプションファイルで BLOCK_SIZE キーワードを使用して単位を変更することもできます。
- エンベロープ From: アドレス (adam@sesta.com)。通知メッセージのようにエンベロープ From: アドレスが空のメッセージの場合、このフィールドは空白になります。
- エンベロープ To: アドレスの元の形式 (marlowe@siroe.com)。
- エンベロープ To: アドレスのアクティブな (現在の) 形式 (marlowe@siroe.com)。
- 配信ステータス (SMTP チャネルのみ)。
表 20-6 に、ログエントリのコードを示します。
LOG_CONNECTION、LOG_FILENAME、LOG_MESSAGE_ID、LOG_NOTARY、LOG_PROCESS、および LOG_USERNAME がすべて有効になっている場合、形式は次に示されているようになります。この例のログエントリ行は改行されて表示されていますが、実際のログエントリは 1 行で記述されます。
前述の説明に含まれていない追加のフィールドは、以下のとおりです。
- チャネルプロセスを実行しているノードの名前 (例では HOSTA)。
- プロセス ID (16 進数) と、その後ろに続くピリオド (ドット) 文字とカウント。マルチスレッドのチャネルエントリ (tcp_* チャネルエントリなど) の場合は、プロセス ID とカウントの間にスレッド ID も挿入されています (例ではプロセス ID は 2e2d.2.1)。
- メッセージの NOTARY (配達証明書要求) フラグ。整数値で表記 (例では 276) します。
- MTA キュー領域内のファイル名 (例では /imta/queue/l/ZZ01IWFY9ELGWM00094D.00)。
- メッセージ ID (例では <01IWFVYLGTS499EC9Y@siroe.com>)。
- 実行プロセスの名前 (例では inetmail)。UNIX での SMTP サーバーなどのディスパッチャプロセスの場合、通常は inetmail (SASL を使用しなかった場合) になります。
- 接続情報 (例では siroe.com (siroe.com [192.160.253.66])。接続情報は、送信システムが HELO/EHLO 行に示す名前 (受信 SMTP メッセージの場合) や、チャネルの正規のホスト名 (他の種類のチャネルの場合) など、送信システムまたはチャネル名で構成されています。TCP/IP チャネルの場合、送信システムの「実際の」名前、つまり、DNS リバース検索によってレポートされるシンボリック名や IP アドレスは、ident* チャネルキーワードを使用して括弧内にレポートすることもできます。「IDENT 検索」を参照してください。この例では、DNS によって見つかった名前と IP アドレスの両方を表示するように指定するキーワードの 1 つ (たとえば、デフォルトの identnone キーワード) が使用されていると仮定しています。
MTA ログファイルを管理する
毎晩午前 0 時頃に実行されるメッセージ返送ジョブは、累積されたログファイル mail.log に既存の mail.log_yesterday を追加し、現在の mail.log_current ファイルの名前を mail.log_yesterday に変更してから、新しい mail.log_current ファイルを開始します。connection.log* ファイルに対しても同様の処理が行われます。
MTA は自動的にロールオーバーを実行して現在のファイルを維持しますが、エントリが累積される mail.log ファイルは、ファイルのバックアップ、切り捨て、削除などのタスクのポリシーを決めて管理する必要があります。
ログファイルの管理方法を検討するときは、MTA の定期的な返送ジョブが、サイトが提供するmsg_svr_base/bin/daily_cleanup プロシージャ (存在する場合) を実行することに注意してください。このため、サイトによっては独自のクリーンアップ方法を提供していることもあります。たとえば、古い mail.log ファイルの名前を週に 1 回 (または月に 1 回) 変更するなどです。
MTA メッセージログの例
MTA メッセージファイルにログ記録されるフィールドの形式とフィールドのリストは、設定したログオプションによって異なります。ここでは、いくつかの典型的なログエントリの解釈の例を示します。その他のオプションのフィールドについては、「その他の MTA ログオプションを指定するには」を参照してください。
ログファイルを確認するときは、通常のシステムでは一度に多くのメッセージが処理されていることに留意してください。通常、特定のメッセージに関連するエントリは、同時に処理されているその他のメッセージに関連するエントリの間に散らばっています。基本的なログ情報は、MTA を通過するメッセージの数が全部でいくつあるかを把握するのに役立ちます。
同じ受取人への同じメッセージに関連する特定のエントリを関連付ける場合は、LOG_MESSAGE_ID を有効にします。特定のメッセージを MTA キュー領域にある特定のファイルと関連付けたり、エントリを見てキューからの取り出しに成功していない特定のメッセージの配信を何回試行したかを確認する場合は、LOG_FILENAME を有効にします。SMTP メッセージ (TCP/IP チャネル経由で処理されるメッセージ) の場合、リモートシステムとの TCP 接続を送信メッセージと関連付けるには、LOG_PROCESS と何らかのレベルの LOG_CONNECTION を有効にします。
ローカルユーザーが送信 TCP/IP チャネルからインターネットなどにメッセージを送信する場合に見られる、基本的なログエントリの例を次に示します。この例では、LOG_CONNECTION が有効になっています。(1) と (2) の行は 1 つのエントリで、実際のログファイルでは 1 行で記述されます。同様に、(3) 〜 (7) の行も 1 つのエントリで、実際のログファイルでは 1 行で記述されます。
コード例 20-1 ログ : ローカルユーザーが送信メッセージを送った場合
19-Jan-1998 19:16:57.64 l tcp_local E 1 (1)
adam@sesta.com rfc822;marlowe@siroe.com marlowe@siroe.com (2)
19-Jan-1998 19:17:01.16 tcp_local D 1 (3)
adam@sesta.com rfc822;marlowe@siroe.com marlowe@siroe.com (4)
dns;thor.siroe.com
(TCP|206.184.139.12|2788|192.160.253.66|25) (5)
(THOR.SIROE.COM -- Server ESMTP [iMS V5.0 #8694]) (6)
smtp;250 2.1.5 marlowe@siroe.com and options OK. (7)
- この行は、ブロックメッセージ (1) をチャネル 1 からチャネル tcp_local のキューに入れたときの日付と時刻 (E) を示します。
- この部分は、実際にはログファイルでは (1) と同じ行に表示されます。エンベロープ From: アドレス (この例では adam@sesta.com) と、エンベロープ To: アドレスの元のバージョンと現在のバージョン (この例では marlowe@siroe.com) を示しています。
- ブロックメッセージ (1) を tcp_local チャネルのキューから取り出したときの日付と時刻 (D) を示しています。つまり、tcp_local チャネルがリモートの SMTP サーバーへの送信に成功したことを示しています。
- エンベロープ From: アドレス、元のエンベロープ To: アドレス、および現在の形式のエンベロープ To: アドレスを示しています。
- 接続先の実際のシステムの名前が DNS で thor.siroe.com であること、ローカルの送信システムの IP アドレスが 206.184.139.12 で、ポート 2788 から送信されていること、リモートの宛先システムの IP アドレスが 192.160.253.66 で、接続ポートが 25 であることを示しています。
- リモートの SMTP サーバーの SMTP 見出し行を示しています。
- このアドレスに返された SMTP ステータスコードを示しています。250 は基本的な SMTP 成功コードであり、このリモート SMTP サーバーは拡張 SMTP ステータスコードと追加テキストで応答しています。
コード例 20-2 はコード例 20-3 に示されているログエントリと似ていますが、LOG_FILENAME=1 および LOG_MESSAGE_ID=1 を設定することによって、ファイル名とメッセージ ID を含む追加の情報もログ記録されています。(1) と (2) を参照してください。特に、メッセージ ID は、エントリとそれに関連するメッセージの相関関係を示すために使われます。
コード例 20-2 ログ: オプションのログフィールドを含む場合
19-Jan-1998 19:16:57.64 l tcp_local E 1
adam@sesta.com rfc822;marlowe@siroe.com marlowe@siroe.com
/imta/queue/tcp_local/ZZ01ISKLSKLZLI90N15M.00
<01ISKLSKC2QC90N15M@sesta.com> (1)
19-Jan-1998 19:17:01.16 tcp_local D 1
adam@sesta.com rfc822;marlowe@siroe.com marlowe@siroe.com
/imta/queue/tcp_local/Z01ISKLSKLZLI90N15M.00
<01ISKLSKC2QC90N15M@sesta.com> (2)
dns;thor.siroe.com (TCP|206.184.139.12|2788|192.160.253.66|25)
(THOR.SIROE.COM -- Server ESMTP [iMS V5.0 #8694])
smtp;250 2.1.5 marlowe@siroe.com and options OK.
コード例 20-3 は、LOG_FILENAME=1、LOG_MESSAGE_ID=1、および LOG_CONNECTION=1 を有効にして、複数の受取人に送信する例を示しています。ここでは、ユーザー adam@sesta.com が MTA メーリングリスト test-list@sesta.com に送信し、それが bob@sesta.com、carol@varrius.com、および david@varrius.com に展開されています。それぞれの受取人の元のエンベロープ To: アドレスはすべて test-list@sesta.com ですが、現在のエンベロープ To: アドレスはそれぞれの受取人ごとに異なるアドレスであることに注意してください。2 つのファイル (チャネル l と送信チャネル tcp_local 用) がありますが、メッセージ ID は同じです。
コード例 20-3 ログ : リストに送信する場合
19-Jan-1998 20:01:44.10 l l E 1
adam@sesta.com rfc822;test-list@sesta.com bob
imta/queue/l/ZZ01ISKND3DE1K90N15M.00
<01ISKND2H8MS90N15M@sesta.com>
19-Jan-1998 20:01:44.81 l tcp_local E 1
adam@sesta.com rfc822;test-list@sesta.com carol@varrius.com
imta/queue/tcp_local/ZZ01ISKND2WS1I90N15M.00
<01ISKND2H8MS90N15M@sesta.com>
19-Jan-1998 20:01:44.81 l tcp_local E 1
adam@sesta.com rfc822;test-list@sesta.com david@varrius.com
imta/queue/tcp_local/ZZ01ISKND2WS1I90N15M.00
<01ISKND2H8MS90N15M@sesta.com>
19-Jan-1998 20:01:50.69 l D 1
adam@sesta.com rfc822;test-list@sesta.com bob
imta/queue/l/ZZ01ISKND3DE1K90N15M.00
<01ISKND2H8MS90N15M@sesta.com>
19-Jan-1998 20:01:57.36 tcp_local D 1
adam@sesta.com rfc822;test-list@sesta.com carol@varrius.com
imta/queue/tcp_local/ZZ01ISKND2WS1I90N15M.00
<01ISKND2H8MS90N15M@sesta.com>
dns;gw.varrius.com (TCP|206.184.139.12|2788|192.160.253.66|25)
(gw.varrius.com -- SMTP Sendmail)
smtp;250 OK.
19-Jan-1998 20:02:06.14 tcp_local D 1
adam@sesta.com rfc822;test-list@sesta.com david@varrius.com
imta/queue/tcp_local/ZZ01ISKND2WS1I90N15M.00
<01ISKND2H8MS90N15M@sesta.com>
dns;gw.varrius.com (TCP|206.184.139.12|2788|192.160.253.66|25)
(gw.varrius.com -- SMTP Sendmail)
smtp;250 OK.
コード例 20-4 は、存在しないドメイン (ここでは very.bogus.com) に送信しようとしたことを示しています。つまり、存在しないことが MTA の書き換えルールによって通知されないドメイン名であり、また、送信 TCP/IP チャネルに一致するドメイン名に送信しようとしました。この例では、LOG_FILENAME=1 と LOG_MESSAGE_ID=1 という MTA オプションが設定されていると仮定しています。
TCP/IP チャネルが作動していて、DNS のドメイン名をチェックしているとき、DNS はそのような名前は存在しないというエラーを返します。(5) の「拒否」エントリ (R) のように DNS はエラーを返し、(6) のようにドメイン名が不正であることを示します。
メッセージが発行されたあとでアドレスが拒否されたため、MTA は元の差出人への返送メッセージを生成します。MTA は新しい拒否メッセージを元の差出人のキューに入れ (1)、元の送信メッセージを削除する ((5) の R エントリ) 前にポストマスターにコピーを送信します (4)。
(2) と (8) に示すように、返送メッセージなどの通知メッセージには空のエンベロープ From: アドレスがあります。エンベロープ From: フィールドは空白で示されています。MTA が生成した返送メッセージが最初にキューに入れられることにより、新しい通知メッセージのメッセージ ID の後ろに元のメッセージのメッセージ ID が表示されます (3)。(この情報は MTA で常に利用できるわけではないが、利用できる場合は、失敗した送信メッセージに対応するログエントリを、通知メッセージに対応するログエントリに関連付けることができる。この通知メッセージは、プロセスチャネルのキューに入れられたあと、該当する宛先チャネルのキューに入れられます (7)。
コード例 20-4 ログ : 存在しないドメインに送信する場合
19-JAN-1998 20:49:04 l tcp_local E 1
adam@sesta.com rfc822;user@very.bogus.com user@very.bogus.com
imta/queue/tcp_local/ZZ01ISKP0S0LVQ94DU0K.00
<01ISKP0RYMAS94DU0K@SESTA.COM>
19-JAN-1998 20:49:33 tcp_local process E 1 (1)
rfc822;adam@sesta.com adam@sesta.com (2)
imta/queue/process/ZZ01ISKP0S0LVQ94DTZB.00
<01ISKP22MW8894DTAS@SESTA.COM>,<01ISKP0RYMAS94DU0K@SESTA.COM> (3)
19-JAN-1998 20:49:33 tcp_local process E 1 (4)
rfc822;postmaster@sesta.com postmaster@sesta.com
imta/queue/process/ZZ01ISKP0S0LVQ94DTZB.00
<01ISKP22MW8894DTAS@SESTA.COM>,<01ISKP0RYMAS94DU0K@SESTA.COM>
19-JAN-1998 20:50:07 tcp_local R 1 (5)
adam@sesta.com rfc822;user@very.bogus.com user@very.bogus.com
imta/queue/tcp_local/ZZ01ISKP0S0LVQ94DU0K.00
<01ISKP0RYMAS94DU0K@SESTA.COM>
Illegal host/domain name found (6)
19-JAN-1998 20:50:08 process l E 3 (7)
rfc822;adam@sesta.com adam (8)
imta/queue/l/ZZ01ISKP23BUQS94DTYL.00
<01ISKP22MW8894DTAS@SESTA.COM>
19-JAN-1998 20:50:08 process l E 3
rfc822;postmaster@sesta.com postmaster
imta/queue/l/ZZ01ISKP23BUQS94DTYL.00
<01ISKP22MW8894DTAS@SESTA.COM>
19-JAN-1998 20:50:12 l D 3
rfc822;adam@sesta.com adam
imta/queue/l/ZZ01ISKP23BUQS94DTYL.00
<01ISKP22MW8894DTAS@SESTA.COM>
19-JAN-1998 20:50:12 l D 3
rfc822;postmaster@sesta.com postmaster
imta/queue/l/ZZ01ISKP23BUQS94DTYL.00
<01ISKP22MW8894DTAS@SIROE.COM>
コード例 20-5 は、リモートシステムの不正アドレスに送信しようとした場合の例を示しています。この例では、LOG_FILENAME=1 および LOG_MESSAGE_ID=1 という MTA オプションと、LOG_BANNER=1 および LOG_TRANSPORTINFO=1 というチャネルオプションが設定されていると仮定しています。(1) の拒否エントリ (R) に注意してください。コード例 20-4 の拒否エントリとは異なり、この例の拒否エントリではリモートシステムに接続されたことが示されており、また、(2)、(3) にリモート SMTP サーバーが発行した SMTP エラーコードが示されています。(2) に示されている情報は、LOG_BANNER=1 および LOG_TRANSPORTINFO=1 というチャネルオプションが設定されていることを前提としています。
コード例 20-5 ログ : 存在しないリモートユーザーに送信する場合
20-JAN-1998 13:11:05 l tcp_local E 1
adam@sesta.com rfc822;nonesuch@siroe.com nonesuch@siroe.com
imta/queue/tcp_local/ZZ01ISLNBB1JOE94DUWH.00
<01ISLNBAWV3094DUWH@sesta.com>
20-JAN-1998 13:11:08 tcp_local process E 1
rfc822;adam@sesta.com adam@sesta.com
imta/queue/process/ZZ01ISLNBB1JOE94DSGB.00
<01ISLNBFKIDS94DUJ8@sesta.com>,<01ISLNBAWV3094DUWH@sesta.com>
20-JAN-1998 13:11:08 tcp_local process E 1
rfc822;postmaster@sesta.com postmaster@sesta.com
imta/queue/process/ZZ01ISLNBB1JOE94DSGB.00
<01ISLNBFKIDS94DUJ8@sesta.com>,<01ISLNBAWV3094DUWH@sesta.com>
20-JAN-1998 13:11:11 tcp_local R 1 (1)
adam@sesta.com rfc822;nonesuch@siroe.com nonesuch@siroe.com
imta/queue/tcp_local/ZZ01ISLNBB1JOE94DUWH.00
<01ISLNBAWV3094DUWH@sesta.com>
dns;thor.siroe.com
(TCP|206.184.139.12|2788|192.160.253.66|25) (2)
(THOR.SIROE.COM -- Server ESMTP [iMS V5.0 #8694])
smtp; 553 unknown or illegal user: nonesuch@siroe.com (3)
20-JAN-1998 13:11:12 process l E 3
rfc822;adam@sesta.com adam
imta/queue/l/ZZ01ISLNBGND1094DQDP.00
<01ISLNBFKIDS94DUJ8@sesta.com>
20-JAN-1998 13:11:12 process l E 3
rfc822;postmaster@sesta.com postmaster
imta/queue/l/ZZ01ISLNBGND1094DQDP.00
<01ISLNBFKIDS94DUJ8@sesta.com>
20-JAN-1998 13:11:13 l D 3
rfc822;adam@sesta.com adam@sesta.com
imta/queue/l/ZZ01ISLNBGND1094DQDP.00
<01ISLNBFKIDS94DUJ8@sesta.com>
20-JAN-1998 13:11:13 l D 3
rfc822;postmaster@sesta.com postmaster@sesta.com
imta/queue/l/ZZ01ISLNBGND1094DQDP.00
<01ISLNBFKIDS94DUJ8@sesta.com>
コード例 20-6 に、MTA リモート側のメッセージ送信の試行を拒否した場合のログエントリを示します。この例では、有効になっている LOG_* オプションがないと仮定されているため、基本的なフィールドだけがエントリにログ記録されています。LOG_CONNECTION オプションを有効にすると、J エントリなどにその他の情報フィールドが追加されます。この例は、ORIG_SEND_ACCESS マッピングを使って SMTP リレーブロッキング (「SMTP リレーブロッキングを設定する」を参照) が設定されている MTA の場合の例です。
ORIG_SEND_ACCESS
! ...多数のエントリを省略...
!
tcp_local|*|tcp_local|* $NRelaying$ not$ permittedalan@very.bogus.com は内部アドレスではありません。したがって、リモートユーザー harold@varrius.com が MTA システムを介してリモートユーザー alan@very.bogus.com にリレーしようとしても、拒否されます。
コード例 20-6 ログ : リモート側のメッセージ送信試行が拒否される場合
28-May-1998 12:02:23 tcp_local J 0 (1)
harold@varrius.com rfc822; alan@very.bogus.com (2)
550 5.7.1 Relaying not permitted: alan@very.bogus.com (3)
コード例 20-7 に、メッセージを最初の試行で配信できなかったために、MTA が何度もメッセージを送信しようとする場合のログエントリの例を示します。この例では、LOG_FILENAME=1 と LOG_MESSAGE_ID=1 というオプションが設定されていると仮定しています。
コード例 20-7 ログ : 配信試行が複数回行われた場合
15-Jan-1998 10:31:05.18 tcp_internal tcp_local E 3 (1)
adam@hosta.sesta.com rfc822;user@some.org user@some.org
imta/queue/tcp_local/ZZ01IS3D2ZP7FQ9UN54R.00
<01IRUD7SVA3Q9UN2D4@sesta.com>
15-Jan-1998 10:31:10.37 tcp_local Q 3 (2)
adam@hosta.sesta.com rfc822;user@some.org user@some.org
imta/queue/tcp_local/ZZ01IS3D2ZP7FQ9UN54R.00 (3)
<01IRUD7SVA3Q9UN2D4@sesta.com>
TCP active open: Failed connect() Error: no route to host (4)
...several hours worth of entries...
15-Jan-1998 12:45:39.48 tcp_local Q 3 (5)
adam@hosta.sesta.com rfc822;user@some.org user@some.org
imta/queue/tcp_local/ZY01IS3D2ZP7FQ9UN54R.00 (6)
<01IRUD7SVA3Q9UN2D4@sesta.com>
TCP active open: Failed connect() Error:no route to host
...several hours worth of entries...
15-Jan-1998 16:45:24.72 tcp_local Q 3
adam@hosta.sesta.com rfc822;user@some.org user@some.org
imta/queue/tcp_local/ZX01IS67NY4RRK9UN7GP.00 (7)
<01IRUD7SVA3Q9UN2D4@sesta.com>
TCP active open: Failed connect() Error: connection refused (8)
...several hours worth of entries...
15-Jan-1998 20:45:51.55 tcp_local D 3 (9)
adam@hosta.sesta.com rfc822;user@some.org user@some.org
imta/queue/tcp_local/ZX01IS67NY4RRK9UN7GP.00
<01IRUD7SVA3Q9UN2D4@sesta.com>
dns;host.some.org (TCP|206.184.139.12|2788|192.1.1.1|25)
(All set, fire away)
smtp; 250 Ok
- メッセージは tcp_internal チャネルに入ります。これは、おそらく POP または IMAP クライアント、または SMTP リレーとして MTA を使用している組織内の別のホストから来たものです。MTA はこれを、送信 tcp_local チャネルのキューに入れます。
- 最初の配信試行に失敗しています。これは Q エントリで示されています。
- これが最初の配信試行であることは、ZZ* ファイル名からわかります。
- この配信試行は、TCP/IP パッケージがリモート側への経路を見つけられなかったために失敗しました。コード例 20-4 とは異なり、DNS は宛先ドメイン名 some.org を否定しません。「no route to host」というエラーは、送信側と受信側の間にネットワーク上の問題があることを示しています。
- MTA の定期的なジョブの次の実行時に、配信が再試行され、再び失敗しています。
- ここでファイル名が ZY* になり、2 回目の試行であることを示しています。
- ファイル名が ZX* になり、3 回目の失敗した試行であることを示しています。
- 定期的なジョブが配信を再試行し、再び失敗しています。ただし、ここでは TCP/IP パッケージがリモートの SMTP サーバーに接続できなかったことが示されているのではなく、リモートの SMTP サーバーが接続を受け入れないことを示しています。リモート側のネットワーク上の問題は解決されても、SMTP サーバーをまだ起動していない、またはその SMTP サーバーのメッセージ処理が追いつかないなどの理由で、MTA が接続しようとした時点で接続が受け入れられなかったことが考えられます。
- メッセージがキューから取り出されています。
コード例 20-8 に、メッセージが変換チャネルを通過する場合の例を示します。このサイトには、以下のような CONVERSIONS マッピングテーブルがあると仮定しています。
CONVERSIONS
IN-CHAN=tcp_local;OUT-CHAN=l;CONVERT Yes
この例では、LOG_FILENAME=1 と LOG_MESSAGE_ID=1 というオプションが設定されていると仮定しています。
コード例 20-8 ログ : 変換チャネルを通過する受信 SMTP メッセージ
04-Feb-1998 00:06:26.72 tcp_local conversion E 9 (1)
amy@siroe.edu rfc822;bert@sesta.com bert@sesta.com
imta/queue/conversion/ZZ01IT5UAMZ4QW98518O.00
<01IT5UALL14498518O@siroe.edu>
04-Feb-1998 00:06:29.06 conversion l E 9 (2)
amy@siroe.edu rfc822;bert@sesta.com bert
imta/queue/l/ZZ01IT5UAOXLDW98509E.00 <01IT5STUMUFO984Z8L@siroe.edu>
04-Feb-1998 00:06:29.31 conversion D 9 (3)
amy@siroe.edu rfc822;bert@sesta.com bert
imta/queue/conversion/ZZ01IT5UAMZ4QW98518O.00
<01IT5UALL14498518O@siroe.edu>
04-Feb-1998 00:06:32.62 l D 9 (4)
amy@siroe.edu rfc822;bert@siroe.com bert
imta/queue/l/ZZ01IT5UAOXLDW98509E.00
<01IT5STUMUFO984Z8L@siroe.edu>
コード例 20-9 に、LOG_CONNECTION=3 によって接続ログが有効になっているときの送信メッセージのログ出力を示します。この例では、LOG_PROCESS=1、LOG_MESSAGE_ID=1、および LOG_FILENAME=1 も設定されていると仮定されています。この例は、ユーザー adam@sesta.com が 3 人の受取人 (bobby@hosta.sesta.com、carl@hosta.sesta.com、および dave@hostb.sesta.com) に同じメッセージ (各メッセージコピーのメッセージ ID は同じ) を送信している場合を示しています。この例では、メッセージが single_sys チャネルキーワードで示された tcp_local チャネル (普段使用しているチャネル) から送信されていると仮定しています。したがって、(1)、(2)、(3) で示されているように、それぞれの受取人に対して、別々のメッセージファイルが別々のホスト名のディスク上に作成されます。bobby@hosta.sesta.com と carl@hosta.sesta.com の受取人は同じメッセージファイルに保存されますが、dave@hostb.sesta.com の受取人は別のメッセージファイルに保存されます。
コード例 20-9 ログ : 送信接続ログ
19-Feb-1998 10:52:05.41 1e488.0 l tcp_local E 1
adam@sesta.com rfc822;bobby@hosta.sesta.com bobby@hosta.sesta.com
imta/queue/tcp_local/ZZ01ITRF7BO388000FCN.00 (1)
<01ITRF7BDHS6000FCN@SESTA.COM>
19-Feb-1998 10:52:05.41 1e488.0 l tcp_local E 1
adam@sesta.com rfc822;carl@hosta.sesta.com carl@hosta.sesta.com
imta/queue/tcp_local/ZZ01ITRF7BO388000FCN.00 (2)
<01ITRF7BDHS6000FCN@SESTA.COM>
19-Feb-1998 10:52:05.74 1e488.1 l tcp_local E 1
adam@sesta.com rfc822;dave@hostb.sesta.com dave@hostb.sesta.com
imta/queue/tcp_local/ZZ01ITRF7C11FU000FCN.00 (3)
<01ITRF7BDHS6000FCN@SESTA.COM>
19-Feb-1998 10:52:10.79 1f625.2.0 tcp_local - O (4)
TCP|206.184.139.12|5900|206.184.139.66|25
SMTP/hostb.sesta.com/mailhub.sesta.com (5)
19-Feb-1998 10:52:10.87 1f625.3.0 tcp_local - O (6)
TCP|206.184.139.12|5901|206.184.139.70|25
SMTP/hosta.sesta.com/hosta.sesta.com (7)
19-Feb-1998 10:52:12.28 1f625.3.1 tcp_local D 1
adam@sesta.com rfc822;bobby@hosta.sesta.com bobby@hosta.sesta.com
imta/queue/tcp_local/ZZ01ITRF7BO388000FCN.00
<01ITRF7BDHS6000FCN@SESTA.COM>
hosta.sesta.com dns;hosta.sesta.com (8)
(TCP|206.184.139.12|5901|206.184.139.70|25)
(hosta.sesta.com -- Server ESMTP [iMS V5.0 #8790])
(TCP|206.184.139.12|5901|206.184.139.70|25)
smtp;250 2.1.5 bobby@hosta.sesta.com and options OK.
19-Feb-1998 10:52:12.28 1f625.3.1 tcp_local D 1
adam@sesta.com rfc822;carl@hosta.sesta.com carl@hosta.sesta.com
imta/queue/tcp_local/ZZ01ITRF7BO388000FCN.00
<01ITRF7BDHS6000FCN@SESTA.COM>
hosta.sesta.com dns;hosta.sesta.com
(TCP|206.184.139.12|5901|206.184.139.70|25)
(hosta.sesta.com -- Server ESMTP [iMS V5.0 #8790])
(TCP|206.184.139.12|5901|206.184.139.70|25)
smtp;250 2.1.5 carl@hosta.sesta.com and options OK.
19-Feb-1998 10:52:12.40 1f625.3.2 tcp_local - C (9)
TCP|206.184.139.12|5901|206.184.139.70|25
SMTP/hosta.sesta.com/hosta.sesta.com
19-Feb-1998 10:52:13.01 1f625.2.1 tcp_local D 1
adam@sesta.com rfc822;dave@hostb.sesta.com dave@hostb.sesta.com
imta/queue/tcp_local/ZZ01ITRF7C11FU000FCN.00
<01ITRF7BDHS6000FCN@SESTA.COM>
mailhub.sesta.com dns;mailhub.sesta.com
(TCP|206.184.139.12|5900|206.184.139.66|25)
(MAILHUB.SESTA.COM -- Server ESMTP [iMS V5.0 #8694])
(TCP|206.184.139.12|5900|206.184.139.66|25)
smtp;250 2.1.5 dave@hostb.sesta.com and options OK.
19-Feb-1998 10:52:13.05 1f625.2.2 tcp_local - C (10)
TCP|206.184.139.12|5900|206.184.139.66|25
SMTP/hostb.sesta.com/mailhub.sesta.com
- 1 人目の受取人へのメッセージがキューに入れられます。
- 次に、2 人目の受取人へのメッセージがキューに入れられます。
- 最後に、3 人目の受取人へのメッセージがキューに入れられます。
- LOG_CONNECTION=3 が設定されているため、MTA がこのエントリを書き込みます。マイナス記号「-」は、このエントリが送信接続であることを示しています。「O」は、このエントリが接続開始に対応することを意味しています。この接続開始はスレッド 2 とスレッド 3 によって実行されていますが、これらの接続開始に対するマルチスレッド TCP/IP チャネルに同じプロセスが使用されているため、プロセス ID は同じ (1f625) であることに注意してください。
- 2 つの異なるリモートシステムに接続するため、別々のスレッドにあるマルチスレッド SMTP クライアントがそれぞれの接続を開いています。最初の接続はこのエントリで、2 番目の接続は 7 に示されています。エントリのこの部分には、送信側と受信側の IP 番号とポート番号、および最初のホスト名と DNS 検索で見つかったホスト名の両方が示されています。SMTP/initial-host/dns-host には、最初のホスト名と、DNS MX レコード検索を実行したあとで使用されるホスト名が表示されています。mailhub.sesta.com は、hostb.sesta.com の MX サーバーであることがわかります。
- マルチスレッド SMTP クライアントが、別のスレッドで 2 番目のシステムとの接続を開いています (プロセスは同じ)。
- 2 つの異なるリモートシステムに接続するため、別々のスレッドにあるマルチスレッド SMTP クライアントがそれぞれの接続を開いています。2 番目の接続はこのエントリで、最初の接続は上記の 5 に示されています。エントリのこの部分には、送信側と受信側の IP 番号とポート番号、および最初のホスト名と DNS 検索で見つかったホスト名の両方が示されています。この例では、hosta.sesta.com というシステムがメールを直接受信することがわかります。
- この例に示されているように、特定の接続エントリのほか、LOG_CONNECTION=3 によって接続に関連する情報が標準のメッセージエントリに組み込まれます。
- LOG_CONNECTION=3 が設定されているため、MTA がこのエントリを書き込みます。メッセージ (この例では bobby と carl のメッセージ) がキューから取り出されたあと、接続が終了します。このエントリでは C で示されています。
- LOG_CONNECTION=3 が設定されているため、MTA がこのエントリを書き込みます。メッセージ (この例では dave のメッセージ) がキューから取り出されたあと、接続が終了します。このエントリでは C で示されています。
コード例 20-10 に、LOG_CONNECTION=3 によって接続ログが有効になっているときの受信 SMTP メッセージのログ出力を示します。
コード例 20-10 ログ : 受信接続ログ
19-Feb-1998 17:02:08.70 tcp_local + O (1)
TCP|206.184.139.12|25|192.160.253.66|1244 SMTP (2)
19-Feb-1998 17:02:26.65 tcp_local l E 1
service@siroe.com rfc822;adam@sesta.com adam
THOR.SIROE.COM (THOR.SIROE.COM [192.160.253.66]) (3)
19-Feb-1998 17:02:27.05 tcp_local + C (4)
TCP|206.184.139.12|25|192.160.253.66|1244 SMTP
19-Feb-1998 17:02:31.73 l D 1
service@siroe.com rfc822;adam@sesta.com adam
- リモートシステムが接続を開きます。「O」は、このエントリが接続開始に対応したものであることを示しています。「+」は、このエントリが受信接続であることを示しています。
- 接続の IP 番号とポートが示されています。このエントリでは、受信システム (ログファイルエントリを記録しているシステム) の IP アドレスは 206.184.139.12、ポート番号は 25、送信システムの IP アドレスは 192.160.253.66、ポートは 1244 です。
- このエントリは、受信 TCP/IP チャネル (tcp_local) からチャネル l の受取人に送られるメッセージがキューに入っていることを示しています。LOG_CONNECTION=3 が有効になっているため、デフォルト以外の情報も含まれています。特に、送信システムがその HELO または EHLO 行に示す名前、接続 IP 番号の DNS リバース検索で見つかった送信システムの名前、および送信システムの IP アドレスが、すべてログに記録されます。この動作に影響するチャネルキーワードについては、第 12 章「チャネル定義を設定する」を参照してください。
- 受信接続が閉じています。「O」は、このエントリが接続終了に対応したものであることを示しています。「+」は、このエントリが受信接続であることを示しています。
ディスパッチャのデバッグとログファイル
ディスパッチャエラーとデバッグ出力 (有効になっている場合) は、MTA ログディレクトリ内の dispatcher.log ファイルに書き込まれます。
デバッグ出力は、ディスパッチャ設定ファイルの DEBUG オプションを使って有効にするか、または IMTA_DISPATCHER_DEBUG 環境変数 (UNIX) を使ってプロセスレベルで有効にすることができます。
DEBUG オプションまたは IMTA_DISPATCHER_DEBUG 環境変数 (UNIX) は、16 進数で 32 ビットのデバッグマスクを定義するものです。すべてのデバッグ機能を有効にするには、オプションを -1 に設定するか、またはシステム全体で論理 / 環境変数を FFFFFFFF に定義します。表 20-7 に、各ビットの説明を示します。
表 20-7 ディスパッチャデバッグビット
ビット
16 進数の値
10 進数の値
使用目的
0
x 00001
1
サービスディスパッチャのメインモジュールの基本的なデバッグ
1
x 00002
2
サービスディスパッチャのメインモジュールの特別なデバッグ
2
x 00004
4
サービスディスパッチャ設定ファイルのログ処理
3
x 00008
8
サービスディスパッチャに関するその他の基本的なデバッグ
4
x 00010
16
サービスの基本的なデバッグ
5
x 00020
32
サービスの特別なデバッグ
6
x 00040
64
プロセスに関連するサービスのデバッグ
7
x 00080
128
使用されていない
8
x 00100
256
サービスディスパッチャとプロセス通信の基本的なデバッグ
9
x 00200
512
サービスディスパッチャとプロセス通信の特別なデバッグ
10
x 00400
1024
パケットレベル通信のデバッグ
11
x 00800
2048
使用されていない
12
x 01000
4096
ワーカープロセスの基本的なデバッグ
13
x 02000
8192
ワーカープロセスの特別なデバッグ
14
x 04000
16384
その他のワーカープロセスのデバッグ (特に接続ハンドオフ)
15
x 08000
32768
使用されていない
16
x 10000
65536
サービスディスパッチャ I/O に対するワーカープロセスの基本的なデバッグ
17
x 20000
131072
サービスディスパッチャ I/O に対するワーカープロセスの特別なデバッグ
20
x 100000
1048576
統計の基本的なデバッグ
21
x 200000
2097152
統計の特別なデバッグ
24
x 1000000
16777216
PORT_ACCESS 拒否を dispatcher.log ファイルにログ
Solaris のシステムパラメータ
システムのヒープサイズ (datasize) は、ディスパッチャによるスレッドスタックの使用を考慮して十分なサイズに設定する必要があります。各ディスパッチャサービスに対して、STACKSIZE*MAX_CONNS を計算し、それらの計算値を合計します。システムのヒープサイズは、この合計値の 2 倍以上でなければなりません。
ディスパッチャ設定ファイルで提供されるディスパッチャサービスは、さまざまなシステムパラメータの必要要件に影響を与えます。
ヒープサイズ (すなわち、デフォルトの datasize) を表示するには、以下の csh コマンドを使用します。
# limit
または、以下のksh コマンドを使用します。
# ulimit -a
または、以下のユーティリティを使用します。
# sysdef