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.
26-Feb-2007 14:38:16.27 tcp_intranet tcp_local EE 1 (1) email@example.com rfc822;firstname.lastname@example.org email@example.com /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) firstname.lastname@example.org rfc822;email@example.com firstname.lastname@example.org /opt/SUNWmsgsr/data/queue/tcp_local/001/ZZf0s690kN_y0.00 (3) <0JE100L05WRJIC00@sesta.com> TCP active open: Failed connect() 126.96.36.199:25 Error: no route to host (4) ...several hours worth of entries... 26-Feb-2007 16:58:11.20 tcp_local Q 1 (5) email@example.com rfc822;firstname.lastname@example.org email@example.com /opt/SUNWmsgsr/data/queue/tcp_local/001/ZYf0s690kN_y0.01 (6) <0JE100L05WRJIC00@sesta.com> TCP active open: Failed connect() 188.8.131.52:25 Error: no route to host ...several hours worth of entries... 26-Feb-2007 19:15:12.11 tcp_local Q 1 firstname.lastname@example.org rfc822;email@example.com firstname.lastname@example.org /opt/SUNWmsgsr/data/queue/tcp_local/001/ZXf0s690kN_y0.00 (7) <0JE100L05WRJIC00@sesta.com> TCP active open: Failed connect() 184.108.40.206:25 Error: Connection refused (8) ...several hours worth of entries... 26-Feb-2007 22:41:12.63 tcp_local DE 1 (9) email@example.com rfc822;firstname.lastname@example.org email@example.com /opt/SUNWmsgsr/data/queue/tcp_local/001/ZXf0s690kN_y0.00 <0JE100L05WRJIC00@sesta.com> host.some.org dns;host.some.org (TCP|220.127.116.11|2788|18.104.22.168|25) (All set, fire away) smtp;250 2.1.5 <firstname.lastname@example.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.