Sun Java System Messaging Server 6 2005Q4 Administration Guide

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 21–7 MTA Logging – Multiple Delivery Attempts


15-Jan-1998 10:31:05.18 tcp_internal   tcp_local   E 3          (1)
 adam@hosta.sesta.com rfc822;user@some.org user@some.org
 imta/queue/tcp_local/ZZ01IS3D2ZP7FQ9UN54R.00 
 <01IRUD7SVA3Q9UN2D4@sesta.com>
 
15-Jan-1998 10:31:10.37 tcp_local                  Q 3          (2)
 adam@hosta.sesta.com rfc822;user@some.org user@some.org
 imta/queue/tcp_local/ZZ01IS3D2ZP7FQ9UN54R.00                   (3)
 <01IRUD7SVA3Q9UN2D4@sesta.com>
 TCP active open: Failed connect()    Error: no route to host   (4)
 
     ...several hours worth of entries...

15-Jan-1998 12:45:39.48 tcp_local                  Q 3          (5)
  adam@hosta.sesta.com rfc822;user@some.org user@some.org
  imta/queue/tcp_local/ZY01IS3D2ZP7FQ9UN54R.00                  (6)
  <01IRUD7SVA3Q9UN2D4@sesta.com>
  TCP active open: Failed connect()    Error: no route to host
 
  ...several hours worth of entries...

 15-Jan-1998 16:45:24.72 tcp_local                  Q 3
  adam@hosta.sesta.com rfc822;user@some.org user@some.org
  imta/queue/tcp_local/ZX01IS67NY4RRK9UN7GP.00                  (7)
                   <01IRUD7SVA3Q9UN2D4@sesta.com>
  TCP active open: Failed connect() Error: connection refused   (8)

  ...several hours worth of entries...

 15-Jan-1998 20:45:51.55 tcp_local                  D 3         (9)
  adam@hosta.sesta.com rfc822;user@some.org user@some.org
  imta/queue/tcp_local/ZX01IS67NY4RRK9UN7GP.00
  <01IRUD7SVA3Q9UN2D4@sesta.com>
  dns;host.some.org (TCP|206.184.139.12|2788|192.1.1.1|25)
  (All set, fire away)
  smtp; 250 Ok
  1. 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.

  2. The first delivery attempt fails, as indicated by the Q entry.

  3. That this is a first delivery attempt can be seen from the ZZ* filename.

  4. This delivery attempt failed when the TCP/IP package could not find a route to the remote side. As opposed to Example 21–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.

  5. The next time the MTA periodic job runs it reattempts delivery, again unsuccessfully.

  6. The file name is now ZY*, indicating that this is a second attempt.

  7. The file name is ZX* for this third unsuccessful attempt.

  8. 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.)

  9. Finally the message is dequeued.