MTA ログエントリの形式について (Sun Java System Messaging Server 6 2005Q4 管理ガイド)

Sun Java System Messaging Server 6 2005Q4 管理ガイド

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)。表 21–2 を参照。
メッセージのサイズ (上の例では 1)。デフォルトでは K バイト単位で表されますが、MTA オプションファイルで BLOCK_SIZE キーワードを使用して単位を変更することもできます。
エンベロープ From: アドレス (上の例では adam@sesta.com)。通知メッセージのようにエンベロープ From: アドレスが空のメッセージの場合、このフィールドは空白です。
エンベロープ To: アドレスの元の形式 (上の例では marlowe@siroe.com)。
エンベロープ To: アドレスの元の形式 (上の例では marlowe@siroe.com)。
配信ステータス (SMTP チャネルのみ)。

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

表 21–2 ログエントリのコード


エントリ	説明
B	不良コマンドが SMTP サーバーに送信されました。受取人アドレスフィールドには拒否されたコマンドが、診断フィールドには SMTP サーバーからの応答が含まれます。MTA チャネルオプションの MAX_B_ENTRIES は、特定のセッションでログされる不良コマンドの数を制御します。デフォルトは 10 です。
BA	トランザクションの前の方で認証が成功したあとの不良コマンドです。
BS	TLS の起動に成功したあとの不良コマンドです。
BSA	TLS や AUTH での不良コマンドです。
D	キューからの取り出しに成功しました
DA	SASL (認証) でのキューからの取り出しに成功しました
DS	TLS (セキュリティー) でのキューからの取り出しに成功しました
DSA	TLS および SASL (セキュリティーと認証) でのキューからの取り出しに成功しました
E	キューに入れます
EA	SASL (認証) でキューに入れることに成功しました
ES	TLS (セキュリティー) でキューに入れることに成功しました
ESA	TLS および SASL (セキュリティーと認証) でキューに入れることに成功しました
J	キューに入れる試行が拒否されました (スレーブチャネルプログラムによる拒否)
K	受取メッセージが拒否されました。差出人が `NOTIFY=NEVER` DSN フラグの設定を要求した場合、メッセージがタイムアウトになった場合、またはメッセージが手動で返された場合です。たとえば、`imsimta qm` “delete” コマンドは常に各受取人の「K」レコードを生成しますが、qm “return” コマンドが「R」レコードではなく「K」レコードを生成する場合です。これは、差出人自身の要求によって、通知が差出人に送信されなかったことを示します。これは、同じ種類の拒否またはタイムアウトである「R」レコードと比較できますが、「R」レコードでは、この失敗したメッセージに関して、元の差出人に戻される新しい通知メッセージも生成されます。
Q	キューからの取り出しで一時的に失敗しました
R	キューからの取り出し試行で受取人アドレスが拒否され (マスターチャネルプログラムによる拒否)、失敗またはバウンスメッセージが生成されました
V	トランザクションが異常終了したときに表示される警告メッセージです。キューに入れられた受取人アドレスごとに、V レコードは 1 つになります。
W	メッセージはまだ配信されていませんが、キューに残っていて再配信が試行されていることを元の差出人に通知するために送信された警告メッセージです。
Z	数人の受取人に対しては成功しましたが、この受取人に対しては一時的に失敗しました。すべての受取人の元のメッセージファイルはキューから取り出され、それに代わって新しいメッセージファイルが入れられ、その他の失敗した受取人がすぐにキューに入れられます
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 行で記述されます。

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])

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

チャネルプロセスを実行しているノードの名前 (例では 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 キーワード) が使用されていると仮定しています。