Sun Java System Messaging Server 6.3 Administration Guide

25.3 Managing MTA Message and Connection Logs

The MTA provides facilities for logging each message as it is enqueued and dequeued. It also provides dispatcher error and debugging output.

This section consists of the following subsections:

You can control logging on a per-channel basis or you can specify that message activity on all channels be logged. In the initial configuration, logging is disabled on all channels.

See 25.3.2 Enabling MTA Logging for more information.

Enabling logging causes the MTA to write an entry to the msg-svr-base/data/log/mail* file each time a message passes through an MTA channel. Such log entries can be useful for gathering statistics on how many messages are passing through the MTA (or through particular channels). You can also use these log entries to investigate other issues, such as whether and when a message was sent or delivered.

The message return job, which runs every night around midnight, appends any existing mail.log_yesterday to the cumulative log file, mail.log, renames the current mail.log_current file to mail.log_yesterday, and then begins a new mail.log_current file. The message return job also performs the analogous operations for any connection.log* files.

While the MTA performs automatic rollovers to maintain the current file, you must manage the cumulative mail.log file by determining policies for tasks such as backing up the file, truncating the file, deleting the file, and so on.

When considering how to manage the log files, note that the MTA periodic return job will execute a site-supplied msg-svr-base/bin/daily_cleanup procedure, if one exists. Thus some sites might choose to supply their own cleanup procedure that, for instance, renames the old mail.log file once a week (or once a month), and so on.

Note –

With logging is enabled, the mail.log file steadily grows and, if left unchecked, consumes all available disk space. Monitor the size of this file and periodically delete unnecessary contents. You can also delete the entire file as another version will be created as needed.

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:

The date and time the entry was made (in the example, 16-Feb-2007 14:54:13.72).
The channel name for the source channel (in the example, tcp_local).
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.)
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:

<action_code><zero or more optional modifiers>

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.
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.
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.
The original form of the envelope To: address (in the example, marlowe@siroe.com).
The active (current) form of the envelope To: address (in the example, marlowe@ims-ms-daemon).
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:

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.
The NOTARY (delivery receipt request) flags for the message, expressed as an integer (in the example, 20).
The file name in the MTA queue area (in the example, /opt/SUNWmsgsr/data/queue/ims-ms/000/ZZf0r2i0HIaY1.01).
The message ID (in the example, <0JDJ00803FAON200@mailstore.siroe.com>).
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).
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.

25.3.2 Enabling MTA Logging

To gather statistics for just a few particular MTA channels, enable the logging channel keyword on just those MTA channels of interest. Many sites prefer to enable logging on all MTA channels. In particular, if you are trying to track down problems, the first step in diagnosing some problems is to notice that messages are not going to the channel you expected or intended, and having logging enabled for all channels can help you investigate such problems.

To Enable MTA Logging on a Specific Channel

Edit the imta.cnf file.

The file is located in the /opt/SUNWmsgsr/config directory.

To enable logging for a particular channel, add the logging keyword to the channel definition. For example:
channel-name keyword1 keyword2 logging
In addition, you can also set a number of configuration parameters such as directory path for log files, log levels, an so on. See 25.4 Managing Message Store, Admin, and Default Service Logs

Note –
The message return job, which runs every night around midnight, appends any existing mail.log_yesterday to the cumulative log file, mail.log, renames the current mail.log_current file to mail.log_yesterday, and then begins a new mail.log_current file. It also performs the analogous operations for any connection.log* files. It is possible that mail.log_yesterday contains time stamps which have already passed over rotation time.

To Enable MTA Logging on All Channels

Edit the imta.cnf file.

The file is located in the /opt/SUNWmsgsr/config directory.

Add the logging keyword to your defaults channel configuration file (see 12.1 Configuring Channel Defaults). For example:

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 Specifying Additional MTA Logging Options

In addition to the basic information always provided when logging is enabled, you can specify that additional, optional information fields be included by setting various LOG_* MTA options in the MTA Option file. The file specified with the IMTA_OPTION_FILE option in the IMTA tailor file (msg-svr-base/config/imta_tailor) specifies the MTA Option file. By default, this is the msg-svr-base/config/option.dat file.

For complete details about the MTA Option file, see the Option File in Sun Java System Messaging Server 6.3 Administration Reference.

This section consists of the following subsections:

To Send MTA Logs to syslog

Edit the MTA Option file.

Set the LOG_MESSAGES_SYSLOG option to 1.

A value of 0 disables generation of the syslog notices. A non-zero value enables generation of the syslog notices, with the absolute value controlling the syslog priority and facility mask. (Positive values mean syslog notices and the regular mail.log* entries; negative values, which are not recommended, mean syslog notices only, disabling the regular mail.log* entries. A value of 0 is the default and indicates that syslog (event log) logging is not performed.

To Control Formatting of Log Entries

Edit the MTA option.dat file.

Set the LOG_FORMAT option.

1 (default) the standard format.
2 requests non-null formatting: empty address fields are converted to the string “<>.”
3 requests counted formatting: all variable length fields are preceded by N, where N is a count of the number of characters in the field.

4 causes log entries to be written in an XML-compatible format. Entry log entry appears as a single XML element containing multiple attributes and no sub-elements. Three elements are currently defined, en for enqueue/dequeue entries, co for connection entries, and he for header entries.

Enqueue/dequeue (en) elements can have the following attributes:

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)
qt - the amount of time a message has spent in the queue (LOG_QUEUE_TIME=1)

Here is a sample en entry:

<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"/>

Note that this entry has been wrapped for clarity; actual log file entries always appear on a single line.

Connection (co) entries can have the following attributes:

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)
ct - the amount of time a message has spent in the queue (LOG_QUEUE_TIME=1, 
also used in en entries)

Here is a sample co entry:

<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"/>

Header (he) entries have the following attributes:

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)

Here is a sample he entry:

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

To Correlate Log Message Entries

Edit the MTA Option file.

Set the LOG_MESSAGE_ID option to 1.

A value of 0 is the default and indicates that message IDs are not saved in the mail.log file.

To Log Amount of Time Messages Have Spent in the Queue

Edit the MTA Option file.

Set the LOG_QUEUE_TIME option to 1.

This option logs the amount of time a message has spent in the queue. The queue time is logged as an integer value in seconds. It appears immediately after the application information string in non-XML format logs. The attribute name in XML formatted logs for this value is qt.

To Identify Message Delivery Retries

Edit the MTA Option file.

Set the LOG_FILENAME option to 1.

This option makes it easier to immediately spot how many times the delivery of a particular message file has been retried. This option can also be useful in understanding when the MTA does or does not split a message to multiple recipients into separate message file copies on disk.

To Log TCP/IP Connections

Edit the MTA Option file.

Set the LOG_CONNECTION option.

This option causes the MTA to log TCP/IP connections, as well as message traffic. The connection log entries are written to the mail.log* files by default. Optionally, the connection log entries can be written to connection.log* files. See the SEPARATE_CONNECTION_LOG option for more information.

To Write Entries to the connection.log File

Edit the MTA Option file.

Set the SEPARATE_CONNECTION_LOG option to 1.

Use this option to specify that connection log entries instead be written to connection.log files. The default value of 0 causes the connection logging to be stored in the MTA log files.

To Correlate Log Messages by Process ID

Edit the MTA Option file.

Set the LOG_PROCESS option.

When used in conjunction with LOG_CONNECTION, this option enables correlation by process ID of which connection entries correspond to which message entries.

To Save User Names Associated with a Process That Enqueues Mail to the mail.log File

Edit the MTA Option file.

Set the LOG_USERNAME option.

This option controls whether or not the user name associated with a process that enqueues mail is saved in the mail.log file. For SMTP submissions where SASL (SMTP AUTH) is used, the user name field will be the authenticated user name (prefixed with an asterisk character).

25.3.4 MTA Message Logging Examples

The exact field format and list of fields logged in the MTA message files vary according to the logging options set. This section shows a few examples of interpreting typical sorts of log entries. This section consists of the following subsections:

For a description of additional, optional fields, see 25.3.3 Specifying Additional MTA Logging Options.

Note –

For typographic reasons, log file entries will be shown folded onto multiple lines—actual log file entries are one line per entry.

When reviewing a log file, keep in mind that on a typical system many messages are being handled at once. Typically, the entries relating to a particular message will be interspersed among entries relating to other messages being processed during that same time. The basic logging information is suitable for gathering a sense of the overall numbers of messages moving through the MTA.

If you wish to correlate particular entries relating to the same message to the same recipient(s), enable LOG_MESSAGE_ID. To correlate particular messages with particular files in the MTA queue area, or to see from the entries how many times a particular not-yet-successfully-dequeued message has had delivery attempted, enable LOG_FILENAME. For SMTP messages (handled via a TCP/IP channel), if you want to correlate TCP connections to and from remote systems with the messages sent, enable LOG_PROCESS and some level of LOG_CONNECTION.

25.3.4.1 MTA Logging Example: User Sends an Outgoing Message

The example below shows a fairly basic example of the sort of log entries one might see if a local user sends a message out an outgoing TCP/IP channel, for example, to the Internet. In this example, LOG_CONNECTION is enabled. The lines marked with (1) and (2) are one entry—they would appear on one physical line in an actual log file. Similarly, the lines marked with (3) - (7) are one entry and would appear on one physical line.

Example 25–1 MTA Logging: A Local User Sends An Outgoing Message

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)

This line shows the date and time of an enqueue with ESMTP (EE) from the tcp_intranet channel to the tcp_local channel of a one (1) block message.
This is part of the same physical line of the log file as (1), presented here as a separate line for typographical convenience. It shows the envelope From: address, in this case adam@sesta.com, and the original version and current version of the envelope To: address, in this case marlowe@siroe.com.
This shows the date and time of a dequeue with ESMTP (DE) from the tcp_local channel of a one (1) block message that is, a successful send by the tcp_local channel to some remote SMTP server.
This shows the envelope From: address, the original envelope To: address, and the current form of the envelope To: address.
This shows that the actual system to which the connection was made is named thor.siroe.com in the DNS, that the local sending system has IP address 206.184.139.12 and is sending from port 2788, that the remote destination system has IP address 192.160.253.66 and the connection port on the remote destination system is port 25.
This shows the SMTP banner line of the remote SMTP server.
This shows the SMTP status code returned for this address; 250 is the basic SMTP success code and in addition, this remote SMTP server responds with extended SMTP status codes and some additional text.

25.3.4.2 MTA Logging Example: Including Optional Logging Fields

This example shows a logging entry similar to that shown in Example 25–3 with LOG_FILENAME=1 and LOG_MESSAGE_ID=1 showing the file name (1 and 3 below) and message ID (2 and 4 below). . The message ID in particular can be used to correlate which entries relate to which message.

Example 25–2 MTA Logging – Including Optional Logging Fields

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 Logging Example – Sending to a List

This example illustrates sending to multiple recipients with LOG_FILENAME=1, LOG_MESSAGE_ID=1, and LOG_CONNECTION=1 enabled. Here user adam@sesta.com has sent to the MTA mailing list test-list@sesta.com, which expanded to bob@sesta.com, carol@varrius.com, and david@varrius.com. Note that the original envelope To: address is test-list@sesta.com for each recipient, though the current envelope To: address is each respective address. Note how the message ID is the same throughout, though two separate files (one for the l channel and one going out the tcp_local channel) are involved.

Example 25–3 MTA Logging – Sending to a List

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 Logging – Sending to a Nonexistent Domain

This example illustrates an attempt to send to a nonexistent domain (here very.bogus.com); that is, sending to a domain name that is not noticed as nonexistent by the MTA's rewrite rules and that the MTA matches to an outgoing TCP/IP channel. This example assumes the MTA option settings of LOG_FILENAME=1 and LOG_MESSAGE_ID=1.

When the TCP/IP channel runs and checks for the domain name in the DNS, the DNS returns an error that no such name exists. Note the “rejection” entry (R), as seen in (5), with the DNS returning an error that this is not a legal domain name, as seen in (6).

Because the address is rejected after the message has been submitted, the MTA generates a bounce message to the original sender. The MTA enqueues the new rejection message to the original sender (1), and sends a copy to the postmaster (4) before deleting the original outbound message (the R entry shown in (5)).

Notification messages, such as bounce messages, have an empty envelope From: address—as seen, for instance, in (2) and (8)—in which the envelope From: field is shown as an empty space. The initial enqueue of a bounce message generated by the MTA shows the message ID for the new notification message followed by the message ID for the original message (3). (Such information is not always available to the MTA, but when it is available to be logged, it allows correlation of the log entries corresponding to the outbound failed message with the log entries corresponding to the resulting notification message.) Such notification messages are enqueued to the process channel, which in turn enqueues them to an appropriate destination channel (7).

Example 25–4 MTA Logging – Sending to a Nonexistent Domain

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 Logging Example – Sending to a Nonexistent Remote User

This example illustrates an attempt to send to a bad address on a remote system. This example assumes MTA option settings of LOG_FILENAME=1 and LOG_MESSAGE_ID=1, and channel option settings of LOG_BANNER=1 and LOG_TRANSPORTINFO=1. Note the rejection entry (R), seen in (1). But in contrast to the rejection entry in Example 25–4, note that the rejection entry here shows that a connection to a remote system was made, and shows the SMTP error code issued by the remote SMTP server, (2) and (3). The inclusion of the information shown in (2) is due to setting the channel options LOG_BANNER=1 and LOG_TRANSPORTINFO=1.

Example 25–5 MTA Logging – Sending to a Nonexistent Remote User

26-Feb-2007 13:56:35.16 tcp_intranet tcp_local    EE 1 
adam@sesta.com rfc822;nonesuch@siroe.com nonesuch@siroe.com 
/opt/SUNWmsgsr/data/queue/tcp_local/000/ZZf0s690a3mf2.01 
<0JE100J08UU24H00@sesta.com> 
siroe.com (siroe.com [192.160.253.66])

26-Feb-2007 13:56:35.19 tcp_local    process      E 1  
rfc822;adam@sesta.com adam@sesta.com 
/opt/SUNWmsgsr/data/queue/process/ZZf0s690a3ml2.00 
<0JE100J09UUB4N00@sesta.com>,<0JE100J08UU24H00@sesta.com> 
tcp-daemon.mailhost.sesta.com

26-Feb-2007 13:56:35.20 tcp_local    process      E 1  
rfc822;postmaster@sesta.com postmaster@sesta.com 
/opt/SUNWmsgsr/data/queue/process/ZZf0s690a3ml3.00 
<0JE100J0BUUB4N00@sesta.com>,<0JE100J08UU24H00@sesta.com>
tcp-daemon.mailhost.sesta.com

26-Feb-2007 13:56:35.20 tcp_local                 RE 1          (1)
adam@sesta.com rfc822;nonesuch@siroe.com nonesuch@siroe.com 
/opt/SUNWmsgsr/data/queue/tcp_local/000/ZZf0s690a3mf2.01 
<0JE100J08UU24H00@sesta.com> 
thor.siroe.com dns;thor.siroe.com 
(TCP|206.184.139.12|2788|192.160.253.66|25)                     (2)
(thor.siroe.com -- Server ESMTP [Sun Java System Messaging 
Server 6.2-8.01 [built Feb 16 2007]]) 
smtp;550 5.1.1 unknown or illegal alias: nonesuch@siroe.com     (3)

26-Feb-2007 13:56:35.62 process      ims-ms       E 4  
rfc822;adam@sesta.com adam@ims-ms-daemon 
/opt/SUNWmsgsr/data/queue/ims-ms/003/ZZf0s690a3mm5.00 
<0JE100J09UUB4N00@sesta.com> 
process-daemon.mailhost.sesta.com

26-Feb-2007 13:56:36.07 process      ims-ms       E 4  
rfc822;postmaster@sesta.com postmaster@ims-ms-daemon 
/opt/SUNWmsgsr/data/queue/ims-ms/016/ZZf0s690a3nm7.01 
<0JE100J0BUUB4N00@sesta.com> 
process-daemon.mailhost.sesta.com

26-Feb-2007 13:56:35.83 ims-ms                    D 4  
rfc822;adam@sesta.com adam@ims-ms-daemon 
/opt/SUNWmsgsr/data/queue/ims-ms/003/ZZf0s690a3mm5.00 
<0JE100J09UUB4N00@sesta.com>

26-Feb-2007 13:56:36.08 ims-ms                    D 4  
rfc822;postmaster@sesta.com postmaster@ims-ms-daemon 
/opt/SUNWmsgsr/data/queue/ims-ms/016/ZZf0s690a3nm7.01 
<0JE100J0BUUB4N00@sesta.com>

25.3.4.6 MTA Logging Example – Rejecting a Remote Side's Attempt to Submit a Message

This example illustrates the sort of log file entry resulting when the MTA rejects a remote side’s attempt to submit a message. (This example assumes that no optional LOG_* options are enabled, so only the basic fields are logged in the entry. Note that enabling the LOG_CONNECTION option, in particular, would result in additional informative fields in such J entries.) In this case, the example is for an MTA that has set up SMTP relay blocking (see 18.7 Configuring SMTP Relay Blocking) with an ORIG_SEND_ACCESS mapping, including:

ORIG_SEND_ACCESS

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

and where alan@very.bogus.com is not an internal address. Hence the attempt of the remote user harold@varrius.com to relay through the MTA system to the remote user alan@very.bogus.com is rejected.

Example 25–6 MTA Logging – Rejecting a Remote Side's Attempt to Submit a Message

26-Feb-2007 14:10:06.89 tcp_local                 JE 0  (1)
harold@varrius.com rfc822; alan@very.bogus.com                 (2)
530 5.7.1 Relaying not allowed: alan@very.bogus.com            (3)

This log shows the date and time the MTA rejects a remote side’s attempt to submit a message. The rejection is indicated by a J record. (Cases where an MTA channel is attempting to send a message which is rejected is indicated by R records, as shown in Example 25–4 and Example 25–5).

Note –
The last J record written to the log will have an indication stating that it is the last for a given session. Also, the current version of Messaging Server does not place a limit on the number of J records.
The attempted envelope From: and To: addresses are shown. In this case, no original envelope To: information was available so that field is empty.
The entry includes the SMTP error message the MTA issued to the remote (attempted sender) side.

25.3.4.7 MTA Logging Example – Multiple Delivery Attempts

This example illustrates the sort of log file entries resulting when a message cannot be delivered upon the first attempt, so the MTA attempts to send the message several times. This example assumes option settings of LOG_FILENAME=1 and LOG_MESSAGE_ID=1.

Example 25–7 MTA Logging – Multiple Delivery Attempts

26-Feb-2007 14:38:16.27 tcp_intranet tcp_local    EE 1           (1)
adam@sesta.com rfc822;user@some.org user@some.org 
/opt/SUNWmsgsr/data/queue/tcp_local/001/ZZf0s690kN_y0.00 
<0JE100L05WRJIC00@sesta.com>

26-Feb-2007 14:38:16.70 tcp_local                 Q 1                    (2)
adam@sesta.com rfc822;user@some.org user@some.org
/opt/SUNWmsgsr/data/queue/tcp_local/001/ZZf0s690kN_y0.00                 (3)
<0JE100L05WRJIC00@sesta.com> 
TCP active open: Failed connect() 192.1.1.1:25  Error: no route to host  (4)

...several hours worth of entries...

26-Feb-2007 16:58:11.20 tcp_local                 Q 1                    (5)
adam@sesta.com rfc822;user@some.org user@some.org
/opt/SUNWmsgsr/data/queue/tcp_local/001/ZYf0s690kN_y0.01                 (6)
<0JE100L05WRJIC00@sesta.com> 
TCP active open: Failed connect() 192.1.1.1:25    Error: no route to host

...several hours worth of entries...

26-Feb-2007 19:15:12.11 tcp_local                 Q 1     
adam@sesta.com rfc822;user@some.org user@some.org
/opt/SUNWmsgsr/data/queue/tcp_local/001/ZXf0s690kN_y0.00                  (7)
<0JE100L05WRJIC00@sesta.com> 
TCP active open: Failed connect() 192.1.1.1:25  Error: Connection refused (8)

...several hours worth of entries...

26-Feb-2007 22:41:12.63 tcp_local                 DE 1                     (9)
adam@sesta.com rfc822;user@some.org user@some.org
/opt/SUNWmsgsr/data/queue/tcp_local/001/ZXf0s690kN_y0.00                 
<0JE100L05WRJIC00@sesta.com> 
host.some.org dns;host.some.org (TCP|206.184.139.12|2788|192.1.1.1|25)
(All set, fire away)
smtp;250 2.1.5 <user@some.org >... Recipient ok

The message comes in the tcp_internal channel—perhaps from a POP or IMAP client, or perhaps from another host within the organization using the MTA as an SMTP relay; the MTA enqueues it to the outgoing tcp_local channel.
The first delivery attempt fails, as indicated by the Q entry.
That this is a first delivery attempt can be seen from the ZZ* filename.
This delivery attempt failed when the TCP/IP package could not find a route to the remote side. As opposed to Example 25–4, the DNS did not object to the destination domain name, some.org; rather, the “no route to host” error indicates that there is some network problem between the sending and receiving side.
The next time the MTA periodic job runs it reattempts delivery, again unsuccessfully.
The file name is now ZY*, indicating that this is a second attempt.
The file name is ZX* for this third unsuccessful attempt.
The next time the periodic job reattempts delivery the delivery fails, though this time the TCP/IP package is not complaining that it cannot get through to the remote SMTP server, but rather the remote SMTP server is not accepting connections. (Perhaps the remote side fixed their network problem, but has not yet brought their SMTP server back up—or their SMTP server is swamped handling other messages and hence was not accepting connections at the moment the MTA tried to connect.)
Finally the message is dequeued.

25.3.4.8 MTA Logging – Incoming SMTP Message Routed Through the Conversion Channel

This example illustrates the case of a message routed through the conversion channel. The site is assumed to have a CONVERSIONS mapping table such as:

CONVERSIONS
   IN-CHAN=tcp_local;OUT-CHAN=ims-ms;CONVERT Yes

This example assumes option settings of LOG_FILENAME=1 and LOG_MESSAGE_ID=1.

Example 25–8 MTA Logging – Incoming SMTP Message Routed Through the Conversion Channel

26-Feb-2007 15:31:04.17 tcp_local    conversion   EE 1   (1)
amy@siroe.edu rfc822;bert@sesta.com bert@ims-ms-daemon 
/opt/SUNWmsgsr/data/queue/conversion/ZZf0s090wFwx2.01 
<0JE100206Z7J5F00@siroe.edu>

26-Feb-2007 15:31:04.73 conversion   ims-ms       E 1           (2)
amy@siroe.edu rfc822;bert@sesta.com bert@ims-ms-daemon 
/opt/SUNWmsgsr/data/queue/ims-ms/007/ZZf0s090wMwq1.00 
<0JE100206Z7J5F00@siroe.edu>

26-Feb-2007 15:31:04.73 conversion                D 1           (3)
amy@siroe.edu rfc822;bert@sesta.com bert@ims-ms-daemon 
/opt/SUNWmsgsr/data/queue/conversion/ZZf0s090wFwx2.01 
<0JE100206Z7J5F00@siroe.edu>

26-Feb-2007 15:31:04.73 ims-ms                    D 1           (4)
amy@siroe.edu rfc822;bert@sesta.com bert@ims-ms-daemon 
/opt/SUNWmsgsr/data/queue/ims-ms/007/ZZf0s090wMwq1.00 
<0JE100206Z7J5F00@siroe.edu>

The message from external user amy@siroe.edu comes in addressed to the ims-ms channel recipient bert@sesta.com. The CONVERSIONS mapping entry, however, causes the message to be initially enqueued to the conversion channel (rather than directly to the ims-ms channel).
The conversion channel runs and enqueues the message to the ims-ms channel.
Then the conversion channel can dequeue the message (delete the old message file).
And finally the ims-ms channel dequeues (delivers) the message.

25.3.4.9 MTA Logging Example: Outbound Connection Logging

This example illustrates log output for an outgoing message when connection logging is enabled, via LOG_CONNECTION=3. LOG_PROCESS=1, LOG_MESSAGE_ID=1 and LOG_FILENAME=1 are also assumed in this example. The example shows the case of user adam@sesta.com sending the same message (note that the message ID is the same for each message copy) to three recipients, bobby@hosta.sesta.com, carl@hosta.sesta.com, and dave@hostb.sesta.com. This example assumes that the message is going out a tcp_local channel marked (as such channels usually are) with the single_sys channel keyword. Therefore, a separate message file on disk will be created for each set of recipients to a separate host name, as seen in (1), (2), and (3), where the bobby@hosta.sesta.com and carl@hosta.sesta.com recipients are stored in the same message file, but the dave@hostb.sesta.com recipient is stored in a different message file.

Example 25–9 MTA Logging: Outbound Connection Logging

28-Feb-2007 09:13:19.18 409f.3.1 tcp_intranet tcp_local    EE 1 
adam@sesta.com rfc822;bobby@hosta.sesta.com bobby@hosta.sesta.com
/opt/SUNWmsgsr/data/queue/tcp_local/000/ZZf0s4g0G2Zt0.00            (1)
<0JE500C0371HRJ00@sesta.com> 
siroe.com (siroe.com [192.160.253.66])

28-Feb-2007 09:13:19.18 409f.3.1 tcp_intranet tcp_local    EE 1 
adam@sesta.com rfc822;carl@hosta.sesta.com carl@hosta.sesta.com
/opt/SUNWmsgsr/data/queue/tcp_local/000/ZZf0s4g0G2Zt0.00            (2)
<0JE500C0371HRJ00@sesta.com> 
siroe.com (siroe.com [192.160.253.66])

28-Feb-2007 09:13:19.19 409f.3.2 tcp_intranet tcp_local    EE 1 
adam@sesta.com rfc822;dave@hostb.sesta.com dave@hostb.sesta.com
/opt/SUNWmsgsr/data/queue/tcp_local/004/ZZf0s4g0G2Zt1.00            (3)
<0JE500C0371HRJ00@sesta.com> 
siroe.com (siroe.com [192.160.253.66])

28-Feb-2007 09:13:19.87 40a5.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)

28-Feb-2007 09:13:20.23 40a5.3.4 tcp_local    -  O                  (6)
TCP|206.184.139.12|5901|206.184.139.70|25
SMTP/hosta.sesta.com/hosta.sesta.com                                (7)

28-Feb-2007 09:13:20.50 40a5.2.5 tcp_local                 DE 1 
adam@sesta.com rfc822;bobby@hosta.sesta.com bobby@hosta.sesta.com
/opt/SUNWmsgsr/data/queue/tcp_local/000/ZZf0s4g0G2Zt0.00 
<0JE500C0371HRJ00@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 [Sun Java System Messaging Server 
6.2-8.01 [built Feb 16 2007]]) 
smtp;250 2.1.5 bobby@hosta.sesta.com and options OK.

28-Feb-2007 09:13:20.50 40a5.2.5 tcp_local                 DE 1 
adam@sesta.com rfc822;carl@hosta.sesta.com carl@hosta.sesta.com
/opt/SUNWmsgsr/data/queue/tcp_local/000/ZZf0s4g0G2Zt0.00 
<0JE500C0371HRJ00@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 [Sun Java System Messaging Server 
6.2-8.01 [built Feb 16 2007]]) 
smtp;250 2.1.5 carl@hosta.sesta.com and options OK.

28-Feb-2007 09:13:20.50 40a5.2.6 tcp_local    -  C                  (9)
TCP|206.184.139.12|5901|206.184.139.70|25
SMTP/hosta.sesta.com/hosta.sesta.com

28-Feb-2007 09:13:21.13 40a5.3.7 tcp_local                 DE 1 
adam@sesta.com rfc822;dave@hostb.sesta.com dave@hostb.sesta.com
/opt/SUNWmsgsr/data/queue/tcp_local/004/ZZf0s4g0G2Zt1.00 
<0JE500C0371HRJ00@sesta.com> 
mailhub.sesta.com dns;mailhub.sesta.com
(TCP|206.184.139.12|5900|206.184.139.66|25)
(mailhub.sesta.com ESMTP Sendmail ready at Tue, 27 Feb 2007 22:19:40 GMT) 
smtp;250 2.1.5 <dave@hostb.sesta.com>... Recipient ok

28-Feb-2007 09:13:21.33 40a5.3.8 tcp_local    -  C                  (10)
TCP|206.184.139.12|5900|206.184.139.66|25
SMTP/hostb.sesta.com/mailhub.sesta.com

The message is enqueued to the first recipient...
....and to the second recipient...
....and to the third recipient.
Having LOG_CONNECTION=3 set causes the MTA to write this entry. The minus, -, indicates that this entry refers to an outgoing connection. The O means that this entry corresponds to the opening of the connection. Also note that the process ID here is the same, 40a5, since the same process is used for the multithreaded TCP/IP channel for these separate connection opens, though this open is being performed by thread 2 vs. thread 3.
As there are two separate remote systems to which to connect, the multithreaded SMTP client in separate threads opens up a connection to each—the first in this entry, and the second shown in 7. This part of the entry shows the sending and destination IP numbers and port numbers, and shows both the initial host name, and the host name found by doing a DNS lookup. In the SMTP/initial-host/dns-host clauses, note the display of both the initial host name, and that used after performing a DNS MX record lookup on the initial host name: mailhub.sesta.com is apparently an MX server for hostb.sesta.com.
The multithreaded SMTP client opens up a connection to the second system in a separate thread (though the same process).
As there are two separate remote systems to which to connect, the multithreaded SMTP client in separate threads opens up a connection to each—the second in this entry, and the first shown above in 5. This part of the entry shows the sending and destination IP numbers and port numbers, and shows both the initial host name, and the host name found by doing a DNS lookup. In this example, the system hosta.sesta.com apparently receives mail directly itself.
Besides resulting in specific connection entries, LOG_CONNECTION=3 also causes inclusion of connection related information in the regular message entries, as seen here for instance.
Having LOG_CONNECTION=3 causes the MTA to write this entry. After any messages are dequeued, (the bobby and carl messages in this example), the connection is closed, as indicated by the C in this entry.
The connection mailhub.sesta.com is closed now that the delivery of the message (dave in this example) is complete.

25.3.4.10 MTA Logging Example: Inbound Connection Logging

This example illustrates log output for an incoming SMTP message when connection logging is enabled, via LOG_CONNECTION=3.

Example 25–10 MTA Logging – Inbound Connection Logging

28-Feb-2007 11:50:59.10 tcp_local + O                  (1)
TCP|206.184.139.12|25|192.160.253.66|1244 SMTP         (2)

28-Feb-2007 11:51:15.12 tcp_local    ims-ms    EE 1 
service@siroe.com rfc822;adam@sesta.com adam@ims-ms-daemon 
THOR.SIROE.COM (THOR.SIROE.COM [192.160.253.66])       (3) 

28-Feb-2007 11:51:15.32 ims-ms                  D 1 
service@siroe.com rfc822;adam@sesta.com adam@ims-ms-daemon

28-Feb-2007 11:51:15.66 tcp_local + C                  (4)
TCP|206.184.139.12|25|192.160.253.66|1244 SMTP

The remote system opens a connection. The O character indicates that this entry regards the opening of a connection; the + character indicates that this entry regards an incoming connection.
The IP numbers and ports for the connection are shown. In this entry, the receiving system (the system making the log file entry) has IP address 206.184.139.12 and the connection is being made to port 25; the sending system has IP address 192.160.253.66 and is sending from port 1244.
In the entry for the enqueue of the message from the incoming TCP/IP channel (tcp_local) to the ims-ms channel recipient, note that information beyond the default is included since LOG_CONNECTION=3 is enabled. Specifically, the name that the sending system claimed on its HELO or EHLO line, the sending system’s name as found by a DNS reverse lookup on the connection IP number, and the sending system’s IP address are all logged; see Chapter 12, Configuring Channel Definitions behavior.
The inbound connection is closed. The C character indicates that this entry regards the closing of a connection; the + character indicates that this entry regards an incoming connection.

25.3.5 Enabling Dispatcher Debugging

Dispatcher error and debugging output (if enabled) are written to the file dispatcher.log in the MTA log directory. The dispatcher configuration information is specified in the msg-svr-base/config/dispatcher.cnf file. A default configuration file is created at installation time and can be used without any changes made. However, if you want to modify the default configuration file for security or performance reasons, you can do so by editing the dispatcher.cnf file.

Table 25–5 Dispatcher Debugging Bits


Bit	Hexadecimal value	Decimal value	Usage
0	x 00001	1	Basic Service Dispatcher main module debugging.
1	x 00002	2	Extra Service Dispatcher main module debugging.
2	x 00004	4	Service Dispatcher configuration file logging.
3	x 00008	8	Basic Service Dispatcher miscellaneous debugging.
4	x 00010	16	Basic service debugging.
5	x 00020	32	Extra service debugging.
6	x 00040	64	Process related service debugging.
7	x 00080	128	Not used.
8	x 00100	256	Basic Service Dispatcher and process communication debugging.
9	x 00200	512	Extra Service Dispatcher and process communication debugging.
10	x 00400	1024	Packet level communication debugging.
11	x 00800	2048	Not used.
12	x 01000	4096	Basic Worker Process debugging.
13	x 02000	8192	Extra Worker Process debugging.
14	x 04000	16384	Additional Worker Process debugging, particularly connection hand-offs.
15	x 08000	32768	Not used.
16	x 10000	65536	Basic Worker Process to Service Dispatcher I/O debugging.
17	x 20000	131072	Extra Worker Process to Service Dispatcher I/O debugging.
20	x 100000	1048576	Basic statistics debugging.
21	x 200000	2097152	Extra statistics debugging.
24	x 1000000	16777216	Log PORT_ACCESS denials to the dispatcher.log file.

To Enable Dispatcher Error Debugging Output

Edit the dispatcher.cnf file.

Set the DEBUG option to -1.

You can also set the logical or environmental variable IMTA_DISPATCHER_DEBUG (UNIX), which defines a 32-bit debug mask in hexadecimal, to the value FFFFFFFF. The table above describes the meaning of each bit.

To Set Dispatcher Parameters (Solaris)

The dispatcher services offered in the dispatcher configuration file affects requirements for various system parameters. The system’s heap size (datasize) must be enough to accommodate the dispatcher’s thread stack usage.

To display the heap size (that is, default datasize), use one of the following:

The csh command:
# limit
The ksh command
# ulimit -a
The Solaris utility
# sysdef

For each dispatcher service compute STACKSIZE*MAX_CONNS, and then add up the values computed for each service. The system’s heap size needs to be at least twice this number.