前へ     目次     索引     DocHome     次へ     
iPlanet Messaging Server 5.2 管理者ガイド



第 13 章   ログ記録とログ解析


iPlanet Messaging Server では、ログファイルを作成して、管理に関連するサーバのイベント、サーバでサポートされているプロトコル (SMTP、POP、IMAP、HTTP) を使用した通信関連のイベント、およびサーバで処理されるその他のプロセスに関するイベントを記録できます。このログファイルを調べれば、サーバのアクションをさまざまな観点からモニタすることができます。

MTA は他のサービスとは異なるログ機構を使用しているため、iPlanet Console を使ってログサービスを設定したりログを表示することはできません。その代わり、設定ファイルに情報を指定することで、MTA のログ機能を設定します。この章は、以下のように 3 部構成になっています。第 1 部では概要について、第 2 部ではメッセージストアおよび管理サービスのログ、第 3 部では MTA サービスのログについて説明します。

「第 1 部 : 概要」

「第 2 部 : サービスログ (メッセージストア、Administration Server、MTA)」

「第 3 部 : サービスログ (MTA)」



第 1 部 : 概要


Messaging Server ログファイルの作成と管理のためにポリシーをカスタマイズすることができます。この章では、ログファイルの種類と構造、およびログファイルの管理と表示方法について説明します。この章には、以下の節があります。


ログ記録されるサービス

Messaging Server は、サポートしている主なプロトコル (サービス) ごとに一連のログファイルを作成します。各種類のログファイルは、個別にカスタマイズしたり表示することができます。表 13-1 に、ログ記録が可能なサービスのリストとそれぞれのログファイルに関する説明を示します。


表 13-1    ログ記録されるサービス

サービス

ログファイルの説明

Admin  

Administration Server を介した iPlanet Console と Messaging Server 間の通信 (大半は複数の CGI プロセスを経る) に関連するログイベントが記録されます。  

SMTP  

サーバの SMTP アクティビティに関連するログイベントが記録されます。  

IMAP  

サーバの IMAP4 アクティビティに関連するログイベントが記録されます。  

POP  

サーバの POP3 アクティビティに関連するログイベントが記録されます。  

HTTP  

サーバの HTTP アクティビティに関連するログイベントが記録されます。  

デフォルト  

サーバのその他のアクティビティ (コマンドラインユーティリティやその他のプロセスなど) に関連するログイベントが記録されます。  


サードパーティ製のツールを使ってログを解析する

iPlanet Messaging Server ではサポートされていないログ解析やレポート生成を行うには、別のツールを使用する必要があります。ログファイルは、テキストエディタや標準のシステムツールで操作できます。

正規表現による構文解析をサポートするスクリプト可能なテキストエディタを使用すると、この章で説明しているような特定の条件に基づくログエントリの検索や抽出を行い、その結果を並べ替えたり、集計や統計を行うこともできます。

UNIX 環境では、UNIX のsyslog ファイルを操作するために開発された既存のレポート生成ツールを変更して使用することもできます。パブリックドメインの syslog 操作ツールを使用する場合は、そのツールにおいて、日付/時刻形式と、Messaging Server のログエントリにはあって syslog エントリにはない 2 つの特殊コンポーネント (facility と logLevel) の変更が必要になる場合があります。



第 2 部 : サービスログ (メッセージストア、Administration Server、MTA)


ここでは、POP、IMAP、HTTP、MTA、Admin、および Default (表 13-1 を参照) の各サービスのログについて説明します。

これらのサービスの場合、iPlanet Console を使用してログの設定と表示を行うことができます。設定内容は、どのイベントを何件まで記録するかに影響します。これらの設定とその他の特徴を使用して、ログファイル解析時のログイベントの検索条件を微調整することができます。MTA のサービスログの詳細は、「第 3 部 : サービスログ (MTA)」を参照してください。

第 2 部には以下の節があります。


ログの特徴

ここでは、メッセージストアと管理サービスに関するログの特徴 (ログレベル、ログイベントのカテゴリ、ログファイル名の命名規則、ログファイルのディレクトリ) について説明します。


ログレベル

ログのレベル (優先順位) は、ログのアクティビティの詳細度を定義します。優先順位レベルが高いほど、詳細度は低くなります。優先順位 (重要度) の高いイベントだけがログに記録されるためです。レベルを下げると、ログは詳細なものとなり、より多くのイベントがログファイルに記録されます。

ログレベルは、logfile.service.loglevel 設定パラメータを設定することによって、POP、IMAP、HTTP、Admin、および Default の各サービスごとに個別に設定できます (「ログオプションを定義、設定する」 を参照)。また、ログレベルを使用して、ログイベントを検索するときにフィルタリングすることもできます。表 13-2 に、利用可能なレベルを示します。これらのログレベルは、UNIX の syslog 機構で定義されるログレベルのサブセットです。


表 13-2    メッセージストアと管理サービスのログレベル 

レベル

説明

Critical  

もっとも詳細度の低いログ。メールボックスや実行に必要なライブラリにサーバがアクセスできない場合など、サーバに重大な問題や致命的な状態が発生したときに、イベントがログに記録されます。  

Error  

クライアントまたは他のサーバへの接続試行に失敗した場合など、エラー状態が発生したときに、イベントがログに記録されます。  

Warning  

サーバがクライアントから送られた通信を解釈できない場合など、警告状態が発生したときに、イベントがログに記録されます。  

Notice  

ユーザがログインに失敗したり、セッションが終了した場合など、通知 (通常の状態だが重要な状況) が発生したときに、イベントがログに記録されます。  

Information  

ユーザがログオンやログオフを行ったり、メールボックスを作成したり名前を変更した場合など、重要なアクションが行われたときに、イベントがログに記録されます。  

Debug  

もっとも詳細度の高いログ。デバッグを行う場合のみ役立ちます。各プロセスまたはタスク内の個々のステップごとにイベントがログに記録されるため、問題の箇所を正確に突き止めることができます。  

特定のログレベルを選択すると、そのレベルのイベントとそれ以上のレベル (詳細度の低い) のイベントがログに記録されます。デフォルトのログレベルは、Notice です。

注

より詳細なログを指定するほど、ログファイルがより多くのディスク容量を占有することになります。ガイドラインについては、「ログオプションを定義、設定する」を参照してください。



ログイベントのカテゴリ

サポートされているサービスまたはプロトコル内で、Messaging Server は、どの機能領域で発生したかに基づいて、ログイベントをより細かくカテゴリに分類します。各ログイベントには、それを生成した機能領域の名前が含まれています。これらのカテゴリは、イベントを検索する際のフィルタリングに使用できます。表 13-3 に、Messaging Server がログのために認識するカテゴリのリストを示します。


表 13-3    ログイベントの発生場所のカテゴリ 

機能領域

説明

General  

プロトコルまたはサービスに関連するアクション全般  

LDAP  

LDAP ディレクトリデータベースにアクセスする Messaging Server に関連するアクション  

Network  

ネットワークの接続に関連するアクション (ソケットエラーはこのカテゴリに分類される)  

Account  

ユーザアカウントに関連するアクション (ユーザログインはこのカテゴリに分類される)  

Protocol  

プロトコル固有のコマンドに関連するプロトコルレベルのアクション (POP、IMAP、または HTTP 機能によって返されるエラーはこのカテゴリに分類される)  

Stats  

サーバの統計収集に関連するアクション  

Store  

メッセージストアへのアクセスに関連する低レベルのアクション (読み取り/書き込みエラーはこのカテゴリに分類される)  

ログ検索でカテゴリをフィルタとして使用する場合の例については、「ログを検索、表示する」を参照してください。


メッセージストアと管理サービスのログファイル名の命名規則

POP、IMAP、HTTP、Admin、および Default サービスのログファイルには、同一の命名規則が適用されます。各ログファイル名の形式は、以下のとおりです。

service.sequenceNum.timeStamp

表 13-4 に、メッセージストアのログファイル名の命名規則を示します。


表 13-4    メッセージストアと管理サービスのログファイル名の命名規則

コンポーネント

定義

service  

ログ対象のサービス : POP、IMAP、HTTP、Admin、Default。  

sequenceNum  

ログファイルディレクトリ内に作成されたログファイルの順番を表す整数。新しいログファイルほど、値が大きくなります。シーケンス番号はロールオーバーすることはなく、サーバのインストール時に始まり、そのサーバを使用している限り常に増え続けます。  

timeStamp  

ファイルが作成された日付と時刻を示す整数。この値は UNIX 標準の時刻形式で表されます。つまり、1970 年 1 月 1 日午前 0 時から経過した秒数です。  

たとえば、imap.63.915107696 という名前のログファイルは、IMAP ログファイルのディレクトリで 63 番目に作成されたログファイルであり、1998 年 12 月 31 日午後 12 時 34 分 56 秒に作成されたログファイルです。

無制限のシーケンス番号をタイムスタンプと組み合わせることによって、解析するファイルのローテーション、有効期間、および選択がより柔軟になります。詳細については、「ログオプションを定義、設定する」を参照してください。


ログファイルのディレクトリ

ログ記録される各サービスごとに、1 つのディレクトリが割り当てられ、ログファイルはそこに保存されます。IMAP ログファイルや POP ログファイルなどの各サービスのログファイルは、それぞれのディレクトリ内に一緒に保存されます。各ディレクトリの場所、そのディレクトリ内に保存できるログファイルの数、およびファイルのサイズを設定することができます。

すべてのログファイルを保存するのに十分な容量があることを確認してください。ログレベルが低い (詳細度が高い) ほど、ログファイルのサイズは大きくなります。

ログレベル、ログローテーション、ログの有効期間、およびサーバのバックアップポリシーを正しく定義することが重要です。ログファイルディレクトリのすべてがバックアップされ、また、過負荷にならないようにするためです。これらを正しく定義しないと、情報を失ってしまうことがあります。「ログオプションを定義、設定する」を参照してください。


ログファイルの形式

Messaging Server によって作成されたメッセージストアおよび管理サービスのログファイルのコンテンツの形式は、すべて同じです。ログファイルは複数行のテキストファイルであり、各行に 1 つのログイベントが記述されています。サポートされている各サービスに対するすべてのイベントは、通常は以下のような形式で記述されています。

dateTime hostName processName[pid]: category logLevel: eventMessage

表 13-5 に、ログファイルのコンポーネントを示します。このイベント記述形式は、日付/時刻形式が異なることと追加コンポーネント (category と logLevel) があることを除けば、UNIX の syslog 機構で定義されているものと同じです。


表 13-5    メッセージストアと管理サービスのログファイルのコンポーネント 

コンポーネント

定義

dateTime  

イベントがログ記録された日付と時刻。dd/mm/yyyy hh:mm:ss の形式で表記されます。時間帯フィールドは GMT を基準とした +/-hhmm で表記されます。たとえば、以下のようになります。
02/Jan/1999:13:08:21 -0700  

hostName  

サーバが動作しているホストマシンの名前。たとえば、showshoe。

注 : ホスト上に複数の Messaging Server インスタンスがある場合は、プロセス ID (pid) を使用して、ログイベントのインスタンスを区別することができます。  

processName  

イベントを生成したプロセスの名前。たとえば、cgi_store。  

pid  

イベントを生成したプロセスのプロセス ID。たとえば、18753。  

category  

イベントが属するカテゴリ。たとえば、General (表 13-3 を参照)。  

logLevel  

イベントのログレベル。たとえば、Notice (表 13-2 を参照)  

eventMessage  

イベント固有の説明メッセージで、長さは任意。たとえば、 Log created (894305624)  

以下に、iPlanet Console を使って表示したログイベントの例を示します。

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 connect

03/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 0

IMAP および POP のイベントエントリの末尾は、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 バイトの合計ログ容量を設定することをお勧めします(ここに示した設定はあくまでも一般例であり、実際の条件はこれとはかなり異なる場合があります)。


ログオプションを設定するには

メッセージストアのログ設定を制御するオプションは、iPlanet Console またはコマンドラインを使用して設定することができます。

これらのオプションの最適な設定は、ログデータの累積される頻度によって異なります。1M バイトの保存領域には、約 4,000 〜 10,000 件のログエントリを記録できます。適度にビジー状態のサーバでは、ログレベルが低い場合 (Noticeなど)、週に何百メガバイトものログデータが記録されることもあります。以下の設定を参考にしてください。

  • 使用可能な保存領域の上限に合わせてログレベルを設定します。つまり、使用可能な保存領域の上限に基づき、ログデータの累積頻度を考慮してログレベルを判断します。

  • 検索処理に影響が出ないように、ログファイルのサイズを設定します。ローテーションのスケジュールと合計保存容量の上限を考慮して調整します。ログエントリの累積頻度に基づいて、最大値を設定してもかまいません。この最大値は、ローテーションが自動的に発生するまでに蓄積されるサイズよりも少し大きめのサイズに設定します。最大ファイルサイズとファイルの最大数を掛けて得られる値が、合計保存領域の上限とほぼ等しくなります。

    たとえば、IMAP ログローテーションが毎日、1 日当たりに累積される IMAP ログデータが 3M バイト、IMAP ログの合計保存領域の上限が 25M バイトの場合、IMAP ログファイルの最大サイズは 3.5M バイトに設定します(この例では、すべてのログファイルが最大サイズと最大ファイル数に達してしまうほど急速にログデータが累積された場合は、いくつかのログデータが失われる可能性があります)。

  • サーバのバックアップを週 1 回行い、IMP ログファイルを毎日ローテーションする場合、IMAP ログファイルの最大数を約 10 個 (個々のログサイズの上限を超える場合のローテーション頻度を考慮) と指定し、最長保存期間を 7 日または 8 日に指定します。

  • ハードウェアの容量とサーバに対して計画したバックアップスケジュールに基づいて、合計保存領域の上限を設定します。ログデータの累積頻度を予測し、サーバのバックアップ周期を超えないように合計保存容量の上限を少し大きめに設定します。

    たとえば、IMAP ログファイルデータの累積が 1 日平均 3M バイト、サーバのバックアップが週 1 回の場合、ディスクの保存領域が十分にあることを前提として、IMAP ログの記憶領域の上限は 25 〜 30M バイトに設定します。

  • 安全性を確保するため、ログファイルを保存するボリュームに、最小空きディスク容量を設定します。ログファイルサイズ以外の要因によってボリュームがいっぱいになった場合は、いっぱいになったディスクにログデータを書き込もうとして障害が発生する前に、古いログファイルが削除されます。

ログ情報は、サーバが提供するログファイルではなく、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 ログファイルが使用されます。

コンソール:  iPlanet Console を使用してログオプションを設定するには、以下の手順に従います。

  1. ログファイルオプションを設定する Messaging Server を開きます。

  2. 「環境設定」タブをクリックし、左側のパネルで「ログファイル」フォルダを開き、サービス (IMAP、HTTP、Admin など) のログファイルを選択します。

  3. 「詳細レベル」ドロップダウンリストからログレベルを選択します。

  4. 「ログファイルのディレクトリパス」フィールドに、ログファイルの保存先となるディレクトリの名前を入力します。

  5. 「各ログのファイルサイズ」フィールドに、ログファイルの最大サイズを入力します。

  6. 「新規アクセスログ作成」フィールドに、ログローテーションのスケジュールの値を入力します。

  7. 「ディレクトリ当たりのログ数」および「ログが次の日付よりも古い場合」フィールドに、バックアップスケジュールを考慮に入れて、最大ログファイル数と期限を示す値を入力します。

  8. 「ログサイズの合計が次の値を超えたとき」フィールドに、合計保存領域の上限を入力します。

  9. 「残りディスク容量が次の値以下になった場合」フィールドに、確保しておく空きディスク容量の最小値を入力します。

コマンドライン:  コマンドラインでログオプションを設定するには、以下の例のように configutil コマンドを使用します。

ログレベルを設定するには、以下のように指定します。

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 には秒数を指定します。


ログを検索、表示する

iPlanet Console には、メッセージストアおよび管理サービスに関するログデータを表示するための基本的なインタフェースがあります。個々のログファイルを選択したり、それらのファイル内で柔軟なフィルタリングによる検索を行うことができます。

ログファイルはサービスごとに分かれており、それぞれ作成順に一覧表示されます。検索するログファイルを選択したら、検索パラメータを指定して検索対象を個々のイベントに限定することができます。


検索パラメータ

以下に、表示するログデータを指定するための検索パラメータを示します。

  • 期間 : イベントを検索する期間の開始と終了を指定するか、検索する日数 (現時点からさかのぼる日数) を指定します。サーバのクラッシュやその他の問題の原因となったログイベントを調べるために、通常は期間の範囲を指定します。また、現在のログファイルの中で今日のイベントだけを見る場合は、期間を 1 日に指定することもできます。

  • ログのレベル : ログレベルを指定できます (「ログレベル」を参照)。特定の問題を検出するために該当するレベルを選択します。たとえば、サーバがダウンした原因を調べる場合は Critical、失敗したプロトコルコールを検出する場合は Error を選択します。

  • 機能領域: 機能領域を指定できます (「ログイベントのカテゴリ」を参照)。問題が含まれている機能領域がわかっている場合は、その機能領域を選択することができます。たとえば、サーバのクラッシュにディスクエラーが関連していると思われる場合は Store、問題が IMAP プロトコルコマンドエラーにあると思われる場合は Protocol を選択します。

  • テキスト検索パターン: テキスト検索パターンを指定して検索対象を絞ることができます。検索するイベントについてすでにわかっている、イベント時刻、プロセス名、プロセス ID、およびイベントメッセージの一部 (リモートホスト名、関数名、エラー番号など) などのイベントコンポーネント (「ログファイルの形式」を参照) を、ワイルドカードを使用して検索することができます。

    検索パターンには、以下の特殊文字およびワイルドカード文字を使用することができます。

    * 任意の文字セット (例 : *.com)
    ? 任意の 1 文字 (例 : 199?)
    [nnn] nnn の中の任意の文字 (例 : [aeiou])
    [^nnn] nnn 以外の任意の文字 (例 : [^aeiou])
    [n-m] n-m の範囲内の任意の文字 (例 : [A-Z])
    [^n-m] n-m の範囲外の任意の文字 (例 : [^0-9])
    ¥ エスケープ文字 : *、?、[、または ] の前に配置してそれらを文字として使用

注 : 検索では大文字と小文字が区別されます。

以下に、ログレベルと機能領域を組み合わせた、表示するログの検索例を示します。

  • 失敗したログインを表示するには、Account 機能領域 (および Notice レベル) を指定します。これは、潜在的なセキュリティ違反を調べるときに役立ちます。

  • 接続に関する問題を調べるには、Network 機能 (およびすべてのログレベル) を指定します。

  • サーバの機能に関する基本的な問題を調べるには、すべての機能 (および Critical ログレベル) を指定します。


検索対象を指定し、結果を表示するには

指定したサービスに属する固有の特徴を持つログイベントを検索するには、以下の手順に従います。

  1. iPlanet Console で、調べるログファイルがある Messaging Server を開きます。

  2. 以下のいずれかの方法で、指定したサービスログの「ログファイルの内容」タブを表示します。

    • 「タスク」タブをクリックしてから、「サービスログの表示」をクリックします。サービスは、ログに記録されているサービスの名前 (「IMAP サービス」や「管理」など) です。

    • 「環境設定」タブをクリックし、左側のパネルで「ログファイル」フォルダを開き、サービス (IMAP や Admin など) のログファイルを選択します。次に、右側のパネルの「コンテンツ」タブを選択します。

  3. ログに記録されたサービスの「コンテンツ」タブが表示されます。

  4. 「ログファイル名」フィールドで、調べたいログファイルを選択します。

  5. 「選択したログの表示」ボタンをクリックして「ログビューア」ウィンドウを開きます。

  6. 「ログビューア」ウィンドウで、検索パラメータを指定します (前述の「検索パラメータ」を参照)。

  7. 「更新」をクリックして検索を実行し、「ログエントリ」フィールドに結果を表示します。



第 3 部 : サービスログ (MTA)

MTA は、メッセージがキューに出し入れされるたびにログを作成することができます。また、ディスパッチャエラーとデバッグ出力も生成できます。第 3 部には以下の節があります。

チャネルごとにログを制御したり、すべてのチャネル上のメッセージアクティビティのログを記録するよう指定することができます。初期設定では、すべてのチャネルでのログ記録が無効になっています。

ログを有効にすると、メッセージが MTA チャネルを通過するたびに mail.log* ファイルにエントリが書き込まれます。これらのログエントリは、MTA (または特定のチャネル) を通過するメッセージの数の統計を取ったり、メッセージが送信または配信されたかどうか、いつ送信または配信されたかを調べるときに役立ちます。

特定の MTA チャネルを通過するメッセージの数の統計をとるだけであれば、その該当する MTA チャネルだけでログチャネルキーワードを有効にしてもかまいません。ほとんどのサイトでは、すべての MTA チャネルでのログを有効にしています。特に、問題を突き止める場合、問題を診断する最初のステップは、メッセージが意図していたチャネルに送られているかどうかに注目することです。すべてのチャネルに対してログを有効にしておくと、このような問題を調べる際に役立ちます。

警告

ログが有効になっている場合は、mail.log が大きくなり続けるため、そのままにしておくと利用可能なディスク容量がなくなってしまいます。このファイルのサイズをモニタし、定期的に不要なコンテンツを削除してください。ファイル全体を削除することもできます。この場合、必要に応じて新しいファイルが作成されます。



MTA のログを有効にするには

特定のチャネルのログを有効にするには、以下のように MTA 設定ファイルのチャネル定義に logging キーワードを追加します。

channel-name keyword1 keyword2 logging

また、ログファイルやログレベルなどのディレクトリパスのような設定パラメータの数も、設定することができます。「第 2 部 : サービスログ (メッセージストア、Administration Server、MTA)」を参照してください。

すべてのチャネルのメッセージアクティビティをログファイルに記録する場合は、MTA 設定ファイルのチャネルブロックセクションの先頭に、defaults チャネルブロックを追加します。たとえば、以下のようになります。

defaults logging

l defragment charset7 us-ascii charset8 iso-8859-01
siroe.com

defaults チャネルは、MTA 設定ファイルの最初の空白行のすぐ後ろにあります。defaults logging 行の前後に空白行を指定することが重要です。

メッセージがキューに入ったりキューから取り出されるたびに、メッセージがログに記録されます。ログエントリはすべて、MTA ログディレクトリ (msg-instance/log/imta/mail.log_current) にある mail.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) またはイベントログ (Windows NT) に送ることができます。0 はデフォルトで、syslog (イベントログ) ログを実行しないことを示します。


その他の MTA ログオプションを指定するには

ログが有効になっているときに与えられる基本的な情報のほかにも、MTA オプションファイルにさまざまな LOG_* MTA オプションを設定することにより、オプションの情報フィールドを含めることができます。オプションファイルの詳細については、『iPlanet Messaging Server リファレンスマニュアル』を参照してください。

  • 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 テキストとして記述されます。デフォルトでは、図 13-1 に示すように、各ログファイルエントリに 8 個または 9 個のフィールドがあります。

図 13-1    MTA ログエントリの形式
19-Jan-1998 19:16:57.64 l tcp_local E 1 adam@sesta.com
 rfc822;marlowe@siroe.com marlowe@siroe.com

ログエントリには以下の情報が含まれています。

  1. エントリが記録された日付と時刻。

  2. ソースチャネルのチャネル名 (上の例では l)。

  3. 宛先チャネルのチャネル名 (上の例では tcp_local)。SMTP チャネルの場合、LOG_CONNECTION が有効になっているときは、プラス記号「+」が SMTP サーバの受信を示し、マイナス記号「-」が SMTP クライアント経由の送信を示します。

  4. エントリのタイプ (E)。表 13-6 を参照。

  5. メッセージのサイズ (1)。デフォルトではキロバイト単位で表されますが、MTA オプションファイルで BLOCK_SIZE キーワードを使用して単位を変更することもできます。

  6. エンベロープ From: アドレス (adam@sesta.com)。通知メッセージのようにエンベロープ From: アドレスが空のメッセージの場合、このフィールドは空白になります。

  7. エンベロープ To: アドレスの元の形式 (marlowe@siroe.com)。

  8. エンベロープ To: アドレスのアクティブな (現在の) 形式 (marlowe@siroe.com)。

  9. 配信ステータス (SMTP チャネルのみ)。

表 13-6 に、ログエントリのコードを示します。

表 13-6    ログエントリのコード 

エントリ

説明

D  

キューからの取り出しに成功  

DA  

SASL (認証) でのキューからの取り出しに成功  

DS  

TLS (セキュリティ) でのキューからの取り出しに成功  

DSA  

TLS および SASL (セキュリティと認証) でのキューからの取り出しに成功  

E  

エンキュー  

EA  

SASL (認証) でキューに入れることに成功  

ES  

TLS (セキュリティ) でキューに入れることに成功  

ESA  

TLS および SASL (セキュリティと認証) でキューに入れることに成功  

J  

キューに入れる試行の拒否 (スレーブチャネルプログラムによる拒否)  

Q  

キューからの取り出しで一時的な失敗  

R  

キューからの取り出し試行で受取人アドレスの拒否 (マスターチャネルプログラムによる拒否)、または失敗/差し戻しメッセージの生成  

W  

未配信メッセージに関する警告メッセージの生成  

Z  

数人の受取人に対しては成功したが、この受取人に対しては一時的に失敗。すべての受取人の元のメッセージファイルはキューから取り出され、それに代わって新しいメッセージファイルが入れられ、その他の失敗した受取人がすぐにキューに入れられます。  

SMTP チャネルの LOG_CONNECTION + または − エントリ

C  

接続終了  

O  

接続開始  

X  

接続拒否  

Y  

接続が確立される前に試行に失敗  

I  

ETRN コマンド受信  

LOG_CONNECTION、LOG_FILENAME、LOG_MESSAGE_ID、LOG_NOTARY、LOG_PROCESS、および LOG_USERNAME がすべて有効になっている場合、形式は図 13-2 に示されているようになります。この例のログエントリ行は改行されて表示されていますが、実際のログエントリは 1 行で記述されます。

図 13-2    その他のフィールドを含むログ形式
19-Jan-1998 13:13:27.10 HOSTA   2e2d.2.1 tcp_local   l
 E 1 service@siroe.com rfc822;adam@sesta.com
 adam 276 /imta/queue/l/ZZ01IWFY9ELGWM00094D.00
 <01IWFVYLGTS499EC9Y@siroe.com> inetmail
 siroe.com (siroe.com [192.160.253.66])

前述の説明に含まれていない追加のフィールドは、以下のとおりです。

  1. チャネルプロセスを実行しているノードの名前 (例では HOSTA)。

  2. プロセス ID (16 進数) と、その後ろに続くピリオド (ドット) 文字とカウント。マルチスレッドのチャネルエントリ (tcp_* チャネルエントリなど) の場合は、プロセス ID とカウントの間にスレッド ID も挿入されています。上の例では、プロセス ID は 2e2d.2.1 です。

  3. メッセージの NOTARY (配達証明書要求) フラグ。整数値で表記 (例では 276)。

  4. MTA キュー領域内のファイル名 (例では /imta/queue/l/ZZ01IWFY9ELGWM00094D.00)。

  5. メッセージ ID (例では <01IWFVYLGTS499EC9Y@siroe.com>)。

  6. 実行プロセスの名前 (例では inetmail)。UNIX での SMTP サーバなどのディスパッチャプロセスの場合、通常は inetmail (SASL を使用しなかった場合)。

  7. 接続情報 (例では 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 の定期的な返送ジョブが、サイトが提供するserver-instance/imta/bin/daily_cleanup プロシージャ (存在する場合) を実行することに注意してください。このため、サイトによっては独自のクリーンアップ方法を提供していることもあります。たとえば、古い mail.log ファイルの名前を週に 1 回 (または月に 1 回) 変更するなどです。


MTA メッセージログの例

MTA メッセージファイルにログ記録されるフィールドの形式とフィールドのリストは、設定したログオプションによって異なります。ここでは、いくつかの典型的なログエントリの解釈の例を示します。その他のオプションのフィールドについては、「その他の MTA ログオプションを指定するには」を参照してください。

注

ここではログファイルエントリが複数行にわたって表示されていますが、実際のログファイルエントリは 1 行で記述されます。


ログファイルを確認するときは、通常のシステムでは一度に多くのメッセージが処理されていることに留意してください。通常、特定のメッセージに関連するエントリは、同時に処理されているその他のメッセージに関連するエントリの間に散らばっています。基本的なログ情報は、MTA を通過するメッセージの数が全部でいくつあるかを把握するのに役立ちます。

同じ受取人への同じメッセージに関連する特定のエントリを関連付ける場合は、LOG_MESSAGE_ID を有効にします。特定のメッセージを MTA キュー領域にある特定のファイルと関連付けたり、エントリを見てキューからの取り出しに成功していない特定のメッセージの配信を何回試行したかを確認する場合は、LOG_FILENAME を有効にします。SMTP メッセージ (TCP/IP チャネル経由で処理されるメッセージ) の場合、リモートシステムとの TCP 接続を送信メッセージと関連付けるには、LOG_PROCESS と何らかのレベルの LOG_CONNECTION を有効にします。

図 13-3 に、ローカルユーザが送信 TCP/IP チャネルからインターネットなどにメッセージを送信する場合に見られる、基本的なログエントリの例を示します。この例では、LOG_CONNECTION が有効になっています。(1) と (2) の行は 1 つのエントリで、実際のログファイルでは 1 行で記述されます。同様に、(3) 〜 (7) の行も 1 つのエントリで、実際のログファイルでは 1 行で記述されます。

図 13-3    ログ : ローカルユーザが送信メッセージを送った場合
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) をチャネル 1 からチャネル tcp_local のキューに入れたときの日付と時刻 (E) を示します。

  2. この部分は、実際にはログファイルでは (1) と同じ行に表示されます。ここでは印刷上の理由から改行されています。エンベロープ From: アドレス (この例では adam@sesta.com) と、エンベロープ To: アドレスの元のバージョンと現在のバージョン (この例では marlowe@siroe.com) を示しています。

  3. ブロックメッセージ (1) を tcp_local チャネルのキューから取り出したときの日付と時刻 (D) を示しています。つまり、tcp_local チャネルがリモートの SMTP サーバへの送信に成功したことを示しています。

  4. エンベロープ From: アドレス、元のエンベロープ To: アドレス、および現在の形式のエンベロープ To: アドレスを示しています。

  5. 接続先の実際のシステムの名前が DNS で thor.siroe.com であること、ローカルの送信システムの IP アドレスが 206.184.139.12 で、ポート 2788 から送信されていること、リモートの宛先システムの IP アドレスが 192.160.253.66 で、接続ポートが 25 であることを示しています。

  6. リモートの SMTP サーバの SMTP 見出し行を示しています。

  7. このアドレスに返された SMTP ステータスコードを示しています。250 は基本的な SMTP 成功コードであり、このリモート SMTP サーバは拡張 SMTP ステータスコードと追加テキストで応答しています。

図 13-4 は図 13-3 に示されているログエントリと似ていますが、LOG_FILENAME=1 および LOG_MESSAGE_ID=1 を設定することによって、ファイル名とメッセージ ID を含む追加の情報もログ記録されています。(1) と (2) を参照してください。特に、メッセージ ID は、エントリとそれに関連するメッセージの相関関係を示すために使われます。

図 13-4    ログ : オプションのログフィールドを含む場合
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.

図 13-5 は、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 は同じです。

図 13-5    ログ : リストに送信する場合
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.

図 13-6 は、存在しないドメイン (ここでは 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)。

図 13-6    ログ : 存在しないドメインに送信する場合
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>

図 13-7 は、リモートシステムの不正アドレスに送信しようとした場合の例を示しています。この例では、LOG_FILENAME=1 および LOG_MESSAGE_ID=1 という MTA オプションと、LOG_BANNER=1 および LOG_TRANSPORTINFO=1 というチャネルオプションが設定されていると仮定しています。(1) の拒否エントリ (R) に注意してください。図 13-6 の拒否エントリとは異なり、この例の拒否エントリではリモートシステムに接続されたことが示されており、また、(2)、(3) にリモート SMTP サーバが発行した SMTP エラーコードが示されています。(2) に示されている情報は、LOG_BANNER=1 および LOG_TRANSPORTINFO=1 というチャネルオプションが設定されていることを前提としています。

図 13-7    ログ : 存在しないリモートユーザに送信する場合
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>

図 13-8 は、MTA がリモート側のメッセージ送信の試行を拒否した場合のログエントリを示しています。 (この例では、有効になっている LOG_* オプションがないと仮定されているため、基本的なフィールドだけがエントリにログ記録されています。LOG_CONNECTION オプションを有効にすると、J エントリなどにその他の情報フィールドが追加されます。)この例は、ORIG_SEND_ACCESS マッピングを使って SMTP リレーブロッキング (「SMTP リレーブロッキングを設定する」を参照) が設定されている MTA の場合の例です。

ORIG_SEND_ACCESS

! ...numerous entries omitted...
!
   tcp_local|*|tcp_local|*   $NRelaying$ not$ permitted

alan@very.bogus.com は内部アドレスではありません。したがって、リモートユーザ harold@varrius.com が MTA システムを介してリモートユーザ alan@very.bogus.com にリレーしようとしても、拒否されます。

図 13-8    ログ : リモート側のメッセージ送信試行が拒否される場合
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)

  1. このログは、MTA がリモート側のメッセージ送信の試行を拒否した日付と時刻を示しています。拒否は J レコードで示されています。(図 13-6 と図 13-7 で示されているように、MTA チャネルがメッセージを送信しようとして拒否され、それが R レコードで示されています。)

  2. 試行されたエンベロープ From: アドレスと To: アドレスが示されています。この場合、利用できる元のエンベロープ To: 情報がなかったため、フィールドは空です。

  3. このエントリには、MTA がリモート (試行した差出人) 側に発行した SMTP エラーメッセージが含まれています。

図 13-9 に、メッセージを最初の試行で配信できなかったために、MTA が何度もメッセージを送信しようとする場合のログエントリの例を示します。この例では、LOG_FILENAME=1 と LOG_MESSAGE_ID=1 というオプションが設定されていると仮定しています。

図 13-9    ログ : 配信試行が複数回行われた場合
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

  1. メッセージは tcp_internal チャネルに入ります。これは、おそらく POP または IMAP クライアント、または SMTP リレーとして MTA を使用している組織内の別のホストから来たものです。MTA はこれを、送信 tcp_local チャネルのキューに入れます。

  2. 最初の配信試行に失敗しています。これは Q エントリで示されています。

  3. これが最初の配信試行であることは、ZZ* ファイル名からわかります。

  4. この配信試行は、TCP/IP パッケージがリモート側への経路を見つけられなかったために失敗しました。図 13-6 とは異なり、DNS は宛先ドメイン名 some.org を否定しません。「no route to host」というエラーは、送信側と受信側の間にネットワーク上の問題があることを示しています。

  5. MTA の定期的なジョブの次の実行時に、配信が再試行され、再び失敗しています。

  6. ここでファイル名が ZY* になり、2 回目の試行であることを示しています。

  7. ファイル名が ZX* になり、3 回目の失敗した試行であることを示しています。

  8. 定期的なジョブが配信を再試行し、再び失敗しています。ただし、ここでは TCP/IP パッケージがリモートの SMTP サーバに接続できなかったことが示されているのではなく、リモートの SMTP サーバが接続を受け入れないことを示しています。(リモート側のネットワーク上の問題は解決されても、SMTP サーバをまだ起動していない、またはその SMTP サーバのメッセージ処理が追いつかないなどの理由で、MTA が接続しようとした時点で接続が受け入れられなかったことが考えられます。)

  9. メッセージがキューから取り出されています。

図 13-10 に、メッセージが変換チャネルを通過する場合の例を示します。このサイトには、以下のような CONVERSIONS マッピングテーブルがあると仮定しています。

CONVERSIONS

  IN-CHAN=tcp_local;OUT-CHAN=l;CONVERT Yes

この例では、LOG_FILENAME=1 と LOG_MESSAGE_ID=1 というオプションが設定されていると仮定しています。

図 13-10    ログ : 変換チャネルを通過する受信 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>

  1. 外部ユーザ amy@siroe.edu からのメッセージがチャネル l の受取人 bert@sesta.com に届きました。しかし、CONVERSIONS マッピングエントリにより、このメッセージは直接チャネル l には送られず、最初に変換チャネルのキューに入れられます。

  2. 変換チャネルが実行され、メッセージがチャネル l のキューに入れられます。

  3. 変換チャネルはメッセージをキューから取り出す (古いメッセージファイルを削除する) ことができます。

  4. 最後に、チャネル l のキューからメッセージが取り出され (配信され) ています。

図 13-11 に、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 の受取人は別のメッセージファイルに保存されます。

図 13-11    ログ : 送信接続ログ
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. 1 人目の受取人へのメッセージがキューに入れられます。

  2. 次に、2 人目の受取人へのメッセージがキューに入れられます。

  3. 最後に、3 人目の受取人へのメッセージがキューに入れられます。

  4. LOG_CONNECTION=3 が設定されているため、MTA がこのエントリを書き込みます。マイナス記号「-」は、このエントリが送信接続であることを示しています。「O」は、このエントリが接続開始に対応することを意味しています。この接続開始はスレッド 2 とスレッド 3 によって実行されていますが、これらの接続開始に対するマルチスレッド TCP/IP チャネルに同じプロセスが使用されているため、プロセス ID は同じ (1f625) であることに注意してください。

  5. 2 つの異なるリモートシステムに接続するため、別々のスレッドにあるマルチスレッド SMTP クライアントがそれぞれの接続を開いています。最初の接続はこのエントリで、2 番目の接続は 7 に示されています。エントリのこの部分には、送信側と受信側の IP 番号とポート番号、および最初のホスト名と DNS 検索で見つかったホスト名の両方が示されています。SMTP/initial-host/dns-host には、最初のホスト名と、DNS MX レコード検索を実行したあとで使用されるホスト名が表示されています。mailhub.sesta.com は、hostb.sesta.com の MX サーバであることがわかります。

  6. マルチスレッド SMTP クライアントが、別のスレッドで 2 番目のシステムとの接続を開いています (プロセスは同じ)。

  7. 2 つの異なるリモートシステムに接続するため、別々のスレッドにあるマルチスレッド SMTP クライアントがそれぞれの接続を開いています。2 番目の接続はこのエントリで、最初の接続は上記の 5 に示されています。エントリのこの部分には、送信側と受信側の IP 番号とポート番号、および最初のホスト名と DNS 検索で見つかったホスト名の両方が示されています。この例では、hosta.sesta.com というシステムがメールを直接受信することがわかります。

  8. この例に示されているように、特定の接続エントリのほか、LOG_CONNECTION=3 によって接続に関連する情報が標準のメッセージエントリに組み込まれます。

  9. LOG_CONNECTION=3 が設定されているため、MTA がこのエントリを書き込みます。メッセージ (この例では bobby と carl のメッセージ) がキューから取り出されたあと、接続が終了します。このエントリでは C で示されています。

  10. LOG_CONNECTION=3 が設定されているため、MTA がこのエントリを書き込みます。メッセージ (この例では dave のメッセージ) がキューから取り出されたあと、接続が終了します。このエントリでは C で示されています。

図 13-12 に、LOG_CONNECTION=3 によって接続ログが有効になっているときの受信 SMTP メッセージのログ出力を示します。

図 13-12    ログ : 受信接続ログ
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

  1. リモートシステムが接続を開きます。「O」は、このエントリが接続開始に対応したものであることを示しています。「+」は、このエントリが受信接続であることを示しています。

  2. 接続の IP 番号とポートが示されています。このエントリでは、受信システム (ログファイルエントリを記録しているシステム) の IP アドレスは 206.184.139.12、ポート番号は 25、送信システムの IP アドレスは 192.160.253.66、ポートは 1244 です。

  3. このエントリは、受信 TCP/IP チャネル (tcp_local) からチャネル l の受取人に送られるメッセージがキューに入っていることを示しています。LOG_CONNECTION=3 が有効になっているため、デフォルト以外の情報も含まれています。特に、送信システムがその HELO または EHLO 行に示す名前、接続 IP 番号の DNS リバース検索で見つかった送信システムの名前、および送信システムの IP アドレスが、すべてログに記録されます。この動作に影響するチャネルキーワードについては、第 8 章「チャネル定義を設定する」を参照してください。

  4. 受信接続が閉じています。「O」は、このエントリが接続終了に対応したものであることを示しています。「+」は、このエントリが受信接続であることを示しています。


ディスパッチャのデバッグとログファイル

ディスパッチャエラーとデバッグ出力 (有効になっている場合) は、MTA ログディレクトリ内の dispatcher.log ファイルに書き込まれます。

デバッグ出力は、ディスパッチャ設定ファイルの DEBUG オプションを使って有効にするか、または IMTA_DISPATCHER_DEBUG 環境変数 (UNIX) を使ってプロセスレベルで有効にすることができます。

DEBUG オプションまたは IMTA_DISPATCHER_DEBUG 環境変数 (UNIX) は、16 進数で 32 ビットのデバッグマスクを定義するものです。すべてのデバッグ機能を有効にするには、オプションを 1 に設定するか、またはシステム全体で論理/環境変数を FFFFFFFF に定義します。表 13-7 に、各ビットの説明を示します。

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


前へ     目次     索引     DocHome     次へ     
Copyright © 2002 Sun Microsystems, Inc. All rights reserved.

最新更新日 2002 年 2 月 27 日