test

Sun Java System Messaging Server 6.3 管理ガイド

25.3 MTA メッセージおよび接続のログの管理

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

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

詳細は、「25.3.2 MTA ログを有効にする」を参照してください。

ログを有効にすると、メッセージが MTA チャネルを通過するたびに msg-svr-base/data/log/mail* ファイルにエントリが書き込まれます。そのようなログエントリは、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 回) 変更するなどです。

注 –

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

25.3.1 MTA ログエントリの形式について

MTA ログファイルは、ASCII テキストとして記述されます。デフォルトでは、次に示すように、各ログファイルエントリには 8 個または 9 個のフィールドがあります。

16-Feb-2007 14:54:13.72 tcp_local ims-ms EE 1 adam@sesta.com rfc822;marlowe@siroe.com marlowe@ims-ms-daemon

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

  1. エントリが記録された日付と時刻 (上の例では 16-Feb-2007 14:54:13.72)。

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

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

  4. エントリのタイプ (上の例では EE)。エントリは、単一のアクションコード (表 25–2 を参照)、またはアクションコードと 1 つ以上の修飾子コード (表 25–3 を参照) で構成できます。エントリの形式は次のとおりです。

    <action_code> <ゼロまたはそれ以上の省略可能な修飾子>

    たとえば、EEC のログエントリコードは、電子メールが、ESMTP (修飾子 E) と SMTP チャンク化 (修飾子 C) を使用してキューに入れられた (アクションコード E) ことを示します。現在使用されているアクションコードと修飾子コードの詳細は、下の表を参照してください。

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

  6. エンベロープ From: アドレス (上の例では adam@sesta.com)。通知メッセージのようにエンベロープ From: アドレスが空のメッセージの場合、このフィールドは空白文字であることに注意してください。

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

  8. エンベロープ To: アドレスのアクティブな (現在の) 形式 (上の例では marlowe@ims-ms-daemon)。

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

次の 3 つの表に、ログエントリコードの説明を示します。

表 25–2 ログエントリのアクションコード

エントリ 

説明 

B 

不良コマンドが SMTP サーバーに送信されました。受取人アドレスフィールドには拒否されたコマンドが、診断フィールドには SMTP サーバーからの応答が含まれます。MTA チャネルオプションの MAX_B_ENTRIES は、特定のセッションでログされる不良コマンドの数を制御します。デフォルトは 10 です。 

D 

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

E 

キューに入れます 

J 

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

K 

受取メッセージが拒否されました。差出人が NOTIFY=NEVER DSN フラグの設定を要求した場合、メッセージがタイムアウトになった場合、またはメッセージが手動で返された場合です。たとえば、imsimta qm “delete” コマ ンドは常に各受取人の「K」レコードを生成しますが、qm “return” コマ ンドが「R」レコードではなく「K」レコードを生成する場合です。これは、差出人自身の要求によって、通知が差出人に送信されなかったことを示します。

これは、同じ種類の拒否またはタイムアウトである「R」レコードと比較できますが、「R」レコードでは、この失敗したメッセージに関して、元の差出人に戻される新しい通知メッセージも生成されます。 

Q 

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

R 

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

V 

トランザクションが異常終了したときに表示される警告メッセージです。キューに入れられた受取人アドレスごとに、V レコードは 1 つになります。 

W 

メッセージはまだ配信されていませんが、キューに残っていて再配信が試行されていることを元の差出人に通知するために送信された警告メッセージです。 

Z 

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

次の表に、ログエントリ修飾子コードの説明を示します。

表 25–3 ログエントリ修飾子コード

エントリ 

説明 

A 

SASL 認証が使用されました。 

C 

チャンク化が使用されました。チャンク化が機能するためには ESMTP を使用する必要があるため、通常は、EEC や DEC のようなフィールド値に着目します。

E 

EHLO コマンドが発行され、受け入れられたため、ESMTP が使用されました。 

L 

LMTP が使用されました。 

P 

MMP を介した POP before SMTP が使用されました。E レコードに P が追加されました。 

S 

TLS/SSL が使用されました。S トランザクションログエントリによって、チャネルに関連付けられた各種の送信済みメッセージカウンタが増えるようになっています。 

LOG_CONNECTION が有効になっている場合 (『Sun Java System Messaging Server 6.3 Administration Reference』の「Option File Format and Available Options」を参照) は、アクションコードの追加のセットが使用されます。これらについて以下に説明します。

表 25–4 SMTP チャネルの LOG_CONNECTION アクションコードの + または - のエントリ

エントリ 

説明 

C 

接続が終了しました。診断フィールドがあとに続きます。connection.log_current (ログファイルが 1 つしか使用されない場合は mail.log_current) に書き込まれます。接続が終了した理由を記録するために使用されます。特に、なんらかのセッション切断制限に達したために接続が終了した場合は、その情報が診断フィールドに表示されます。 

O 

接続が開始しました 

U 

ログの SMTP 認証が成功および失敗しました。形式はほかの O エントリや C エントリと同じです。特に、同じアプリケーションや転送情報のフィールドが同じ順序で表示されます。ユーザー名が明らかな場合は、ユーザー名フィールドに記録されます。このエントリは、LOG_CONNECTION MTA オプションのビット 7 (値は 128) によって制御されます。 

X 

接続が拒否されました 

Y 

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

I 

ETRN コマンドを受信しました 

LOG_CONNECTION、LOG_FILENAME、LOG_MESSAGE_ID、LOG_NOTARY、LOG_PROCESS、および LOG_USERNAME がすべて MTA オプションファイルで有効になっている場合、形式は次に示されているようになります。この例のログエントリ行は改行されて表示されていますが、実際のログエントリは 1 行で記述されます。


16-Feb-2007 15:04:01.14 2bbe.5.3 tcp_local ims-ms
EE 1 service@siroe.com rfc822;adam@sesta.com
adam@ims-ms-daemon 20 /opt/SUNWmsgsr/data/queue/ims-ms/000/ZZf0r2i0HIaY1.01
<0JDJ00803FAON200@mailstore.siroe.com> mailsrv
siroe.com (siroe.com [192.160.253.66])

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

  1. プロセス ID (16 進数) と、その後ろに続くピリオド (ドット) 文字と数。これがマルチスレッドチャネルエントリ (つまり、tcp_* チャネルエントリ) であった場合、プロセス ID と数の間にスレッド ID も存在します。この例では、プロセス ID は 2bbe.5.3 です。

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

  3. MTA キュー領域内のファイル名 (例では /opt/SUNWmsgsr/data/queue/ims-ms/000/ZZf0r2i0HIaY1.01)。

  4. メッセージ ID (例では <0JDJ00803FAON200@mailstore.siroe.com>)。

  5. 実行プロセスの名前 (例では mailsrv)。UNIX での SMTP サーバーなどのディスパッチャープロセスの場合、通常は mailsrv になります (SASL を使用しなかった場合。使用した場合は、たとえば *service@siroe.com などの、認証されたユーザー名になる)。

  6. 接続情報 (例では siroe.com (siroe.com [192.160.253.66]))。接続情報は、送信システムが HELO/EHLO 行に示す名前 (着信 SMTP メッセージの場合) や、チャネルの正規のホスト名 (ほかの種類のチャネルの場合) など、送信システムまたはチャネル名で構成されています。TCP/IP チャネルの場合、送信システムの実際の名前、つまり、DNS リバース検索によってレポートされるシンボリック名や IP アドレスは、ident* チャネルキーワードを使用して括弧内にレポートすることもできます。DNS によって見つかった名前と IP アドレスの両方を表示するように指定するデフォルトの identnone キーワードの例については、「12.4.3.4 IDENT 検索」を参照してください。

25.3.2 MTA ログを有効にする

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

Procedure特定のチャネルの MTA のログを有効にする

  1. imta.cnf ファイルを編集します。

    このファイルは /opt/SUNWmsgsr/config ディレクトリにあります。

  2. 特定のチャネルに対してログの作成を有効にするには、チャネル定義で logging キーワードを追加します。次に例を示します。


    channel-name keyword1 keyword2 logging

    また、ログファイルやログレベルなどのディレクトリパスのような設定パラメータの数も、設定することができます。「25.4 メッセージストア、管理、およびデフォルトのサービスログの管理」を参照してください。

Procedureすべてのチャネルの MTA ログを有効にする

  1. imta.cnf ファイルを編集します。

    このファイルは /opt/SUNWmsgsr/config ディレクトリにあります。

  2. defaults チャネルの設定ファイルにログキーワードを追加します (「12.1 チャネルのデフォルトを設定する」を参照)。次に例を示します。


    defaults logging notices 1 2 4 7 copywarnpost copysendpost postheadonly 
noswitchchannel immnonurgent maxjobs 7 defaulthost siroe.com siroe.com

!
! delivery channel to local /var/mail store
l subdirs 20 viaaliasrequired maxjobs 7 pool LOCAL_POOL
mailhost.siroe.com

25.3.3 その他の MTA ログオプションの指定

ログが有効になっているときに与えられる基本的な情報のほかにも、MTA オプションファイルにさまざまな LOG_*MTAオプションを設定することにより、オプションの情報フィールドを含めることができます。IMTA テイラーファイル (msg-svr-base/config/imta_tailor) の IMTA_OPTION_FILE オプションで指定されたファイルで、MTA オプションファイルを指定します。デフォルトでは、これは msg-svr-base/config/option.dat ファイルです。

MTA オプションファイルの詳細は、『Sun Java System Messaging Server 6.3 Administration Reference』の「Option File」を参照してください。

ProcedureMTA ログを syslog へ送信する

  1. MTA オプションファイルを編集します。

  2. LOG_MESSAGES_SYSLOG オプションを 1 に設定します。

    0 の値はデフォルトであり、syslog (イベントログ) のログが実行されなかったことを示します。

Procedureログエントリの書式設定を制御する

  1. MTA option.dat ファイルを編集します。

  2. LOG_FORMAT オプションを設定します。

    • 1 (デフォルト) は、標準の書式設定です。

    • 2 は、NULL 以外の書式設定を要求します。空のアドレスフィールドは、文字列 "<>" に変換されます。

    • 3 は、カウントされた書式設定を要求します。すべての可変長フィールドの前に N が置かれます。N は、フィールド内の文字数のカウントです。

    • 4 は、ログエントリが XML と互換性のある形式で書き込まれるようにします。ログエントリは、複数の属性を含むが、サブ要素は含まない単一の XML 要素として表示されます。現在定義されている要素には、キュー出し入れエントリに対する en、接続エントリに対する co、およびヘッダーエントリに対する he の 3 つがあります。

      キュー出し入れ (en) 要素は、次の属性を含むことができます。


      ts - time stamp (always present)
no - node name (present if LOG_NODE=1)
pi - process id (present if LOG_PROCESS=1)
sc - source channel (always present)
dc - destination channel (always present)
ac - action (always present)
sz - size (always present)
so - source address (always present)
od - original destination address (always present)
de - destination address (always present)
rf - recipient flags (present if LOG_NOTARY=1)
fi - filename (present if LOG_FILENAME=1)
ei - envelope id (present if LOG_ENVELOPE_ID=1)
mi - message id (present if LOG_MESSAGE_ID=1)
us - username (present if LOG_USERNAME=1)
ss - source system (present if bit 0 of LOG_CONNECTION
     is set and source system information is available)
se - sensitivity (present if LOG_SENSITIVITY=1)
pr - priority (present if LOG_PRIORITY=1)
in - intermediate address (present if LOG_INTERMEDIATE=1)
ia - initial address (present if bit 0 of LOG_INTERMEDIATE
     is set and intermediate address information is available)
fl - filter (present if LOG_FILTER=1 and filter information
     is available)     
re - reason (present if LOG_REASON=1 and reason string is set)
di - diagnostic (present if diagnostic info available)
tr - transport information (present if bit 5 of LOG_CONNECTION
     is set and transport information is available)
ap - application information (present if bit 6 of LOG_CONNECTION
     is set and application information is available)

      サンプルの en エントリを次に示します。


      <en ts="2004-12-08T00:40:26.70" pi="0d3730.10.43" sc="tcp_local"
dc="l" ac="E" sz="12" so="info-E8944AE8D033CB92C2241E@whittlesong.com"
od="rfc822;ned+2Bcharsets@mauve.sun.com"
de="ned+charsets@mauve.sun.com" rf="22"
fi="/path/ZZ01LI4XPX0DTM00IKA8.00" ei="01LI4XPQR2EU00IKA8@mauve.sun.com"
mi="<11a3b401c4dd01$7c1c1ee0$1906fad0@elara>" us=""
ss="elara.whittlesong.com ([208.250.6.25])"
in="ned+charsets@mauve.sun.com" ia="ietf-charsets@innosoft.com"
fl="spamfilter1:rvLiXh158xWdQKa9iJ0d7Q==, addheader, keep"/>

      このエントリは見やすくするために改行されていますが、実際のログファイルエントリは常に 1 行で表示されることに注意してください。

      接続 (co) エントリは、次の属性を含むことができます。


       ts - time stamp (always present, also used in en entries)
no - node name (present if LOG_NODE=1, also used in en entries)
pi - process id (present if LOG_PROCESS=1, also used in en entries)
sc - source channel (always present, also used in en entries)
dr - direction (always present)
ac - action (always present, also used in en entries)
tr - transport information (always present, also used in en entries)
ap - application information (always present, also used in en entries)
mi - message id (present only if message id info available,
     also used in en entries)
us - username (present only if username information available, also
     used in en entries)
di - diagnostic (present only if diagnostic information available,
     also used in en entries)

      サンプルの co エントリを次に示します。


      <co ts="2004-12-08T00:38:28.41" pi="1074b3.61.281" sc="tcp_local" dr="+"
ac="O" tr="TCP|209.55.107.55|25|209.55.107.104|33469" ap="SMTP"/>

      ヘッダー (he) エントリには次の属性が含まれます。


      ts - time stamp (always present, also used in en entries)
no - node name (present if LOG_NODE=1, also used in en entries)
pi - process id (present if LOG_PROCESS=1, also used in en entries)
va - header line value (always present)

      サンプルの he エントリを次に示します。


      <he ts="2004-12-08T00:38:31.41" pi="1074b3.61.281" va="Subject: foo"/>

Procedureログメッセージエントリを関連付ける

  1. MTA オプションファイルを編集します。

  2. LOG_MESSAGE_ID オプションを 1 に設定します。

    0 の値はデフォルトであり、メッセージ ID が mail.log ファイルに保存されなかったことを示します。

Procedureメッセージがキューに入れられていた時間をログに記録する

  1. MTA オプションファイルを編集します。

  2. LOG_QUEUE_TIME オプションを 1 に設定します。

    このオプションによって、メッセージがキューに入れられていた時間がログに記録されます。キュー時間は秒数を表す整数値として記録されます。この記録は、XML 形式でないログの、アプリケーション情報文字列の直後に出力されます。XML 形式のログでは、この値の属性名は qt です。

Procedureメッセージの配信再試行を確認する

  1. MTA オプションファイルを編集します。

  2. LOG_FILENAME オプションを 1 に設定します。

    このオプションを使用すると、特定のメッセージファイルの配信が何回再試行されたかを即座に簡単に確認できます。このオプションは、MTA が複数の受信者へのメッセージをディスク上で別々のメッセージファイルコピーに分割する場合としない場合を把握するのにも役立ちます。

ProcedureTCP/IP 接続のログを記録する

  1. MTA オプションファイルを編集します。

  2. LOG_CONNECTION オプションを設定します。

    このオプションを使用すると、MTA は TCP/IP 接続とメッセージトラフィックのログを記録します。接続ログエントリは、デフォルトで mail.log* ファイルに書き込まれます。さらに、接続ログエントリを connection.log* ファイルに書き込むことも可能です。詳細は、SEPARATE_CONNECTION_LOG オプションを参照してください。

Procedureconnection.log ファイルにエントリを書き込む

  1. MTA オプションファイルを編集します。

  2. SEPARATE_CONNECTION_LOG オプションを 1 に設定します。

    このオプションを使用して、ログエントリを connection.log ファイルに代わりに書き込むことを指定できます。デフォルト値の 0 は、接続ログを MTA ログファイルに格納します。

Procedureプロセス ID でログメッセージを関連付ける

  1. MTA オプションファイルを編集します。

  2. LOG_PROCESS オプションを設定します。

    LOG_CONNECTION とともに使用すると、このオプションは接続エントリとそれに対応するメッセージエントリの相関関係をプロセス ID によって示すことができます。

Procedureメールを mail.log ファイルのキューに入れるプロセスに関連付けられたユーザー名を保存する

  1. MTA オプションファイルを編集します。

  2. LOG_USERNAME オプションを設定します。

    このオプションは、メールをキューに入れるプロセスに関連付けられたユーザー名を mail.log ファイルに保存するかどうかを制御します。SASL (SMTP AUTH) を使用している SMTP 送信の場合は、ユーザー名フィールドが認証ユーザー名 (プレフィックスとしてアスタリスクが付いたもの) になります。

25.3.4 MTA メッセージログの例

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

注 –

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

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

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

25.3.4.1 MTA ログの例: ユーザーがメッセージを送信する場合

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

例 25–1 MTA ログ: ローカルユーザーが送信メッセージを送った場合


16-Feb-2007 15:41:32.36 tcp_intranet tcp_local    EE 1    (1)
adam@sesta.com rfc822;marlowe@siroe.com marlowe@siroe.com (2)
siroe.com (siroe.com [192.160.253.66])

16-Feb-2007 15:41:34.73 tcp_local                 DE 1    (3)
adam@sesta.com rfc822;marlowe@siroe.com marlowe@siroe.com (4)
thor.siroe.com dns;thor.siroe.com

(TCP|206.184.139.12|2788|192.160.253.66|25)               (5)

(thor.siroe.com ESMTP Sendmail ready Thu 15 Feb 2007 21:37:29 -0700 [MST]) (6)

smtp;250 2.1.5 <marlowe@siroe.com>... Receipt ok           (7)

  1. この行は、ESMTP (EE) を使用して、1 ブロック (1) メッセージをチャネル tcp_intranet からチャネル tcp_local のキューに入れたときの日付と時刻を示します。

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

  3. ESMTP (DE) を使用して、1 ブロック (1) メッセージを tcp_local チャネルのキューから取り出したときの日付と時刻を示しています。つまり、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 ステータスコードと追加テキストで応答しています。

25.3.4.2 MTA ログの例: オプションのログフィールドを含む場合

この例は、例 25–3 に示されているログエントリと似ていますが、LOG_FILENAME=1 と LOG_MESSAGE_ID=1 を設定することによりファイル名 (下の 1 と 3) とメッセージ ID (下の 2 と 4) も表示しています。 特に、メッセージ ID は、エントリとそれに関連するメッセージの相関関係を示すために使われます。

例 25–2 MTA ログ: オプションのログフィールドを含む場合


16-Feb-2007 15:41:32.36 tcp_intranet tcp_local    EE 1   
adam@sesta.com rfc822;marlowe@siroe.com marlowe@siroe.com
/opt/SUNWmsgsr/data/queue/tcp_local/002/ZZf0r4i0Wdy51.01  (1)
<0JDJ00D02IBWDX00@sesta.com>                              (2)
siroe.com (siroe.com [192.160.253.66])

16-Feb-2007 15:41:34.73 tcp_local                 DE 1
adam@sesta.com rfc822;marlowe@siroe.com marlowe@siroe.com 
/opt/SUNWmsgsr/data/queue/tcp_local/002/ZZf0r4i0Wdy51.01  (3)
<0JDJ00D02IBWDX00@sesta.com>                              (4)
thor.siroe.com dns;thor.siroe.com
(TCP|206.184.139.12|2788|192.160.253.66|25)
(thor.siroe.com ESMTP Sendmail ready at Thu, 15 Feb 2007 21:37:29 -0700 [MST])
smtp;250 2.1.5 <marlowe@siroe.com>... Recipient ok

25.3.4.3 MTA ログの例: リストに送信する場合

この例は、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 は同じです。

例 25–3 MTA ログ: リストに送信する場合


20-Feb-2007 14:00:16.46 tcp_local    tcp_local    EE 1
adam@sesta.com rfc822;test-list@sesta.com carol@varrius.com 
/opt/SUNWmsgsr/data/queue/tcp_local/004/ZZf0r2D0yuej4.01 
<0JDQ00706R0FX100@sesta.com> 
siroe.com (siroe.com [192.160.253.66])

20-Feb-2007 14:00:16.47 tcp_local    tcp_local    EE 1
adam@sesta.com rfc822;test-list@sesta.com david@varrius.com
/opt/SUNWmsgsr/data/queue/tcp_local/004/ZZf0r2D0yuej4.01 
<0JDQ00706R0FX100@sesta.com> 
siroe.com (siroe.com [192.160.253.66])

20-Feb-2007 14:00:16.48 tcp_local    ims-ms       EE 1 
adam@sesta.com rfc822;test-list@sesta.com bob@ims-ms-daemon 
/opt/SUNWmsgsr/data/queue/ims-ms/008/ZZf0r2D0yuej6.01 
<0JDQ00706R0FX100@sesta.com>
siroe.com (siroe.com [192.160.253.66])

20-Feb-2007 14:00:16.68 ims-ms                    D 1 
adam@sesta.com rfc822;test-list@sesta.com bob@ims-ms-daemon 
/opt/SUNWmsgsr/data/queue/ims-ms/008/ZZf0r2D0yuej6.01 
<0JDQ00706R0FX100@sesta.com>

20-Feb-2007 14:00:17.73 tcp_local                 DE 1 
adam@sesta.com rfc822;test-list@sesta.com carol@varrius.com 
/opt/SUNWmsgsr/data/queue/tcp_local/004/ZZf0r2D0yuej4.01 
<0JDQ00706R0FX100@sesta.com> 
gw.varrius.com dns;gw.varrius.com (TCP|206.184.139.12|2788|192.160.253.66|25)
(gw.varrius.com -- SMTP Sendmail)
smtp;250 2.1.5 <carol@varrius.com >... Recipient ok

20-Feb-2007 14:00:17.75 tcp_local                 DE 1 
adam@sesta.com rfc822;test-list@sesta.com david@varrius.com 
/opt/SUNWmsgsr/data/queue/tcp_local/004/ZZf0r2D0yuej4.01 
<0JDQ00706R0FX100@sesta.com> 
gw.varrius.com dns;gw.varrius.com (TCP|206.184.139.12|2788|192.160.253.66|25)
(gw.varrius.com -- SMTP Sendmail)
smtp;250 2.1.5 <david@varrius.com>... Recipient ok

25.3.4.4 MTA ログ: 存在しないドメインに送信する場合

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

例 25–4 MTA ログ: 存在しないドメインに送信する場合


20-Feb-2007 14:17:07.77 tcp_intranet tcp_local    E 1 
adam@sesta.com rfc822;user@very.bogus.com user@very.bogus.com 
/opt/SUNWmsgsr/data/queue/tcp_local/008/ZZf0r2D0CVaL0.00 
<0JDQ00903RS89T00@sesta.com>
siroe.com (siroe.com [192.160.253.66])

20-Feb-2007 14:17:08.24 tcp_local    process      E 1       (1)
rfc822;adam@sesta.com adam@sesta.com                        (2)
/opt/SUNWmsgsr/data/queue/process/ZZf0r2D0CVbR0.00 
<0JDQ00904RSK9Z00@sesta.com>,<0JDQ00903RS89T00@sesta.com>   (3)
tcp-daemon.mailhost.sesta.com

20-Feb-2007 14:17:08.46 tcp_local    process      E 1       (4)
rfc822;postmaster@sesta.com postmaster@sesta.com 
/opt/SUNWmsgsr/data/queue/process/ZZf0r2D0CVbR1.00 
<0JDQ00906RSK9Z00@sesta.com>,<0JDQ00903RS89T00@sesta.com> 
tcp-daemon.mailhost.sesta.com

20-Feb-2007 14:17:08.46 tcp_local                 R 1       (5)
adam@sesta.com rfc822;user@very.bogus.com user@very.bogus.com 
/opt/SUNWmsgsr/data/queue/tcp_local/008/ZZf0r2D0CVaL0.00
<0JDQ00903RS89T00@sesta.com>  
Illegal host/domain name found                              (6)
(TCP active open: Failed gethostbyname() on very.bogus.com, resolver errno = 1)

20-Feb-2007 14:17:09.21 process      ims-ms       E 3       (7)
rfc822;adam@sesta.com adam@ims-ms-daemon                    (8)
/opt/SUNWmsgsr/data/queue/ims-ms/018/ZZf0r2D0CVbS1.00 
<0JDQ00904RSK9Z00@sesta.com> 
process-daemon.mailhost.sesta.com

20-Feb-2007 14:17:09.72 process      ims-ms       E 3  
rfc822;postmaster@sesta.com postmaster@ims-ms-daemon
/opt/SUNWmsgsr/data/queue/ims-ms/014/ZZf0r2D0CVbS2.00 
<0JDQ00906RSK9Z00@sesta.com> 
process-daemon.mailhost.sesta.com

20-Feb-2007 14:17:09.73 ims-ms                    D 3  
rfc822;adam@sesta.com adam@ims-ms-daemon 
/opt/SUNWmsgsr/data/queue/ims-ms/018/ZZf0r2D0CVbS1.00 
<0JDQ00904RSK9Z00@sesta.com>

20-Feb-2007 14:17:09.84 ims-ms                    D 3 
rfc822;postmaster@sesta.com postmaster@ims-ms-daemon
/opt/SUNWmsgsr/data/queue/ims-ms/014/ZZf0r2D0CVbS2.00 
<0JDQ00906RSK9Z00@sesta.com>

25.3.4.5 MTA ログの例: 存在しないリモートユーザーに送信する場合

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

例 25–5 MTA ログ: 存在しないリモートユーザーに送信する場合


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>

25.3.4.6 MTA ログの例: リモート側のメッセージ送信試行が拒否される場合

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

ORIG_SEND_ACCESS

! ...多数のエントリを省略...
!
   tcp_local|*|tcp_local|*   $NRelaying$ not$ permitted

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

例 25–6 MTA ログ: リモート側のメッセージ送信試行が拒否される場合


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 レコードで示されています。MTA チャネルが拒否されるメッセージを送信しようとすると、例 25–4 と例 25–5 で示されているように R レコードで示されます。

    注 –

    ログに書き込まれた最後の J レコードは、特定のセッションの最後のレコードであることを示します。また、Messaging Server の現在のバージョンは J レコードの数を制限しません。

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

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

25.3.4.7 MTA ログの例: 配信試行が複数回行われた場合

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

例 25–7 MTA ログ: 配信試行が複数回行われた場合


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

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

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

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

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

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

25.3.4.8 MTA ログ: 変換チャネルを通過する着信 SMTP メッセージ

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

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

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

例 25–8 MTA ログ: 変換チャネルを通過する着信 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 のキューからメッセージが取り出され (配信され) ています。

25.3.4.9 MTA ログの例: 送信接続ログ

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

例 25–9 MTA ログ: 送信接続ログ


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 で示されています。

25.3.4.10 MTA ログの例: 受信接続ログ

この例では、LOG_CONNECTION=3 によって接続ログが有効になっているときの着信 SMTP メッセージのログ出力を示します。

例 25–10 MTA ログ: 受信接続ログ


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 アドレスが、すべてログに記録されます。この動作に影響するチャネルキーワードについては、第 12 章「チャネル定義を設定する」を参照してください。

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

25.3.5 ディスパッチャーのデバッグを有効にする

ディスパッチャーエラーとデバッグ出力 (有効になっている場合) は、MTA ログディレクトリ内の dispatcher.log ファイルに書き込まれます。ディスパッチャーの設定情報は、msg-svr-base/config/dispatcher.cnf ファイルに指定されます。インストール時に作成されたデフォルトの設定ファイルをそのまま使用することができます。ただし、セキュリティーやパフォーマンスなどの理由でデフォルトの設定ファイルを変更する場合は、dispatcher.cnf ファイルを編集することができます。

表 25–5 ディスパッチャーデバッグビット

ビット 

 

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 ファイルへのログ。 

Procedureディスパッチャーのエラーデバッグ出力を有効にする

  1. dispatcher.cnf ファイルを編集します。

  2. DEBUG オプションを -1 に設定します。

    論理または環境変数の IMTA_DISPATCHER_DEBUG (UNIX) を設定することもできます。この変数は、32 ビットのデバッグマスクに 16 進数の FFFFFFFF の値を定義します。上の表には、各ビットの意味の説明があります。

Procedureディスパッチャーパラメータを設定する (Solaris)

ディスパッチャー設定ファイルで提供されるディスパッチャーサービスは、さまざまなシステムパラメータの必要要件に影響を与えます。システムのヒープサイズ (datasize) は、ディスパッチャーによるスレッドスタックの使用を考慮して十分なサイズに設定する必要があります。

  1. ヒープサイズ (つまり、デフォルトの datasize) を表示するには、次のいずれかを使用します。

    csh コマンド: 


    # limit

    ksh コマンド


    # ulimit -a

    Solaris ユーティリティー


    # sysdef

  2. 各ディスパッチャーサービスに対して、STACKSIZE*MAX_CONNS を計算し、それらの計算値を合計します。システムのヒープサイズは、この合計値の 2 倍以上でなければなりません。