25.3.4 MTA Message Logging Examples (Sun Java System Messaging Server 6.3 Administration Guide)

Sun Java System Messaging Server 6.3 Administration Guide

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.