test

Sun Java System Messaging Server 6 2005Q4 Administration Guide

Understanding the MTA Log Entry Format

The MTA log file is written as ASCII text. By default, each log file entry contains eight or nine fields as shown in the example below.

19-Jan-1998 19:16:57.64 l tcp_local E 1 adam@sesta.com rfc822;marlowe@siroe.com marlowe@siroe.com

The log entry shows:

  1. The date and time the entry was made (in the example, 19-Jan-1998 19:16:57.64).

  2. The channel name for the source channel (in the example, l).

  3. The channel name for the destination channel (in the example, tcp_local). (For SMTP channels, when LOG_CONNECTION is enabled, a plus (+) indicates inbound to the SMTP server; a minus (-) indicates outbound via the SMTP client.)

  4. The type of entry (in the example, E); see Table 21–2.

  5. The size of the message (in the example, 1). This is expressed in kilobytes by default, although this default can be changed by using the BLOCK_SIZE keyword in the MTA option file.

  6. The envelope From: address (in the example, adam@sesta.com). Note that for messages with an empty envelope From: address, such as notification messages, this field is blank.

  7. The original form of the envelope To: address (in the example, marlowe@siroe.com).

  8. The active (current) form of the envelope To: address (in the example, marlowe@siroe.com).

  9. The delivery status (SMTP channels only).

The following table describes the logging entry codes.

Table 21–2 Logging Entry Codes

Entry 

Description 

B 

Bad command sent to the SMTP server. The recipient address field will contain the command that was rejected while the diagnostic field will contain the response the SMTP server gave. MTA channel option, MAX_B_ENTRIES, controls how many bad commands will be logged in a given session. Default is 10. 

BA 

Bad command after authentication successfully performed earlier in transaction. 

BS 

Bad command after TLS successfully started up. 

BSA 

Bad command with TLS and AUTH. 

D 

Successful dequeue 

DA 

Successful dequeue with SASL (authentication) 

DS 

Successful dequeue with TLS (security) 

DSA 

Successful dequeue with TLS and SASL (security and authentication) 

E 

Enqueue 

EA 

Successful enqueue with SASL (authentication) 

ES 

Successful enqueue with TLS (security) 

ESA 

Successful enqueue with TLS and SASL (security and authentication) 

J 

Rejection of attempted enqueue (rejection by slave channel program) 

K 

Recipient message rejected. If the sender requests NOTIFY=NEVER DSN flag set or if the message times out or if the message is manually returned (for example: imsimta qm “delete” command always generates a “K” record for each recipient, while a qm “return” command will generate a “K” record rather than an “R” record). This indicates that there was no notification sent to the sender per the sender’s own request.

This can be compared with “R” records, which are the same sort of rejection/time-out, but where a new notification message (back to the original sender) is also generated regarding this failed message. 

Q 

Temporary failure to dequeue 

R 

Recipient address rejected on attempted dequeue (rejection by master channel program), or generation of a failure/bounce message 

V 

Warning message that will appear whenever a transaction is abnormally aborted. There will be one "V" record per enqueued recipient address. 

W 

Warning message sent to notify original sender that the message has not been delivered yet, but it is still in the queue being retried. 

Z 

Some successful recipients, but this recipient was temporarily unsuccessful; the original message file of all recipients was dequeued, and in its place a new message file for this and other unsuccessful recipients will be immediately enqueued 

SMTP channels' LOG_CONNECTION + or - entries  

C 

Connection closed. A diagnostic field will follow. Written to connection.log_current (or mail.log_current if a single log file is being used). Used to record the reason why the connection was closed. In particular, if the connection was closed due to some session disconnect limit being reached, that fact will show up in the diagnostics field. 

O 

Connection opened 

U 

Logs SMTP authentication successes and failures. Format is the same as other O and C entries. In particular, the same application and transport information fields appear in same order. The username will be logged in the username field if it is known. Bit 7 (value 128) of the LOG_CONNECTION MTA option controls this. 

X 

Connection rejected 

Y 

Connection attempt failed before being established 

I 

ETRN command received 

With LOG_CONNECTION, LOG_FILENAME, LOG_MESSAGE_ID, LOG_NOTARY, LOG_PROCESS, and LOG_USERNAME all enabled in the MTA Option file, the format becomes as shown in the example below. (The sample log entry line has been wrapped for typographic reasons; the actual log entry would appear on one physical line.)


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

Where the additional fields, beyond those already discussed above, are:

  1. The name of the node on which the channel process is running (in the example, HOSTA).

  2. The process ID (expressed in hexadecimal), followed by a period (dot) character and a count. If this had been a multithreaded channel entry (that is, a tcp_* channel entry), there would also be a thread ID present between the process ID and the count. In the example, the process ID is 2e2d.2.1.

  3. The NOTARY (delivery receipt request) flags for the message, expressed as an integer (in the example, 276).

  4. The file name in the MTA queue area (in the example, /imta/queue/l/ZZ01IWFY9ELGWM00094D.00).

  5. The message ID (in the example, <01IWFVYLGTS499EC9Y@siroe.com>).

  6. The name of the executing process (in the example, inetmail). On UNIX, for dispatcher processes such as the SMTP server, this will usually be inetmail (unless SASL was used).

  7. The connection information (in the example, siroe.com (siroe.com [192.160.253.66]). The connection information consists of the sending system or channel name, such as the name presented by the sending system on the HELO/EHLO line (for incoming SMTP messages), or the enqueuing channel's official host name (for other sorts of channels). In the case of TCP/IP channels, the sending system's “real” name, that is, the symbolic name as reported by a DNS reverse lookup and/or the IP address, can also be reported within parentheses as controlled by the ident* channel keywords; see IDENT Lookups instance us of the default identnone keyword, that selects display of both the name found from the DNS and IP address.