Sun Java System Messaging Server (Logs entry Format)

25.3.1 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.
16-Feb-2007 14:54:13.72 tcp_local ims-ms EE 1 adam@sesta.com rfc822;marlowe@siroe.com marlowe@ims-ms-daemon
The log entry shows:

1. The date and time the entry was made (in the example, 16-Feb-2007 14:54:13.72).
   
2. The channel name for the source channel (in the example, tcp_local).
   
3. The channel name for the destination channel (in the example, ims-ms). (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, EE). Entries can consist of a single action code (see Table 25–2) or an action code and one or more modifier codes (see Table 25–3). The format for entries is as follows:
   
   For example a logging entry code of EEC means that the email was Enqueued (action-code E) using ESMTP (modifier E) and SMTP Chunking (modifier C). Please refer to the tables below for details on the currently used action and modifier codes.
   
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. The SMS channel can be configured to log a page count rather than file size in this field. See LOG_PAGE_COUNT.
   
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@ims-ms-daemon).
   
9. The delivery status (SMTP channels only).
   

The following three tables describe the logging entry codes.
Table 25–2 Logging Entry Action 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.
D	Successful dequeue
E	Enqueue
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

The following table describes the logging entry modifier codes.
Table 25–3 Logging Entry Modifier Codes

Entry	Description
A	SASL authentication used.
C	Chunking was used. Note that ESMTP has to be used for chunking to work, so you'll typically see field values like EEC or DEC.
E	An EHLO command was issued/accepted and therefore ESMTP was used.
L	LMTP was used.
S	TLS/SSL used. S transaction log entries now increment the various submitted message counters associated with the channel.

If LOG_CONNECTION is enabled (see Option File Format and Available Options in Sun Java System Messaging Server 6.3 Administration Reference), then an additional set of action codes will be used. These are described below.
Table 25–4 SMTP Channel's LOG_CONNECTION Action Codes + or - Entries

Entry	Description
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.)

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

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

1. 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 2bbe.5.3.
   
2. The NOTARY (delivery receipt request) flags for the message, expressed as an integer (in the example, 20).
   
3. The file name in the MTA queue area (in the example, /opt/SUNWmsgsr/data/queue/ims-ms/000/ZZf0r2i0HIaY1.01).
   
4. The message ID (in the example, <0jdj00803faon200 mailstore.siroe.com="">).
   
5. The name of the executing process (in the example, mailsrv). On UNIX, for dispatcher processes such as the SMTP server, this will usually be mailsrv (unless SASL was used, in which case it will be the authenticated user name, for example, *service@siroe.com).
   
6. 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 12.4.3.4 IDENT Lookups for an instance of the default identnone keyword, that selects display of both the name found from the DNS and IP address.