As usual, they aren't detailed enough.  The last line for each transaction
simply shows that there was the start of data transmission.  At this point I
suspect a network issue and will be working with my datacenter staff to
check port speed/duplex matching and go from there. 

    >   -----Original Message-----
    >   From: [EMAIL PROTECTED] 
    >   [mailto:[EMAIL PROTECTED] On Behalf 
    >   Of Len Conrad
    >   Sent: Thursday, August 25, 2005 8:37 PM
    >   To: [email protected]
    >   Subject: Re: [IMail Forum] T* and D* files left in spool
    >   
    >   
    >   >"When the message is fully received, the T* file is 
    >   renamed to be a Q* 
    >   >file and the system attempts to deliver the message. 
    >   If you happen to 
    >   >reboot your system while a message is being received, 
    >   IMail MAY leave 
    >   >behind the T* and the D* files. These files are not 
    >   cleaned up automatically."
    >   
    >   Marc,
    >   
    >   As eternally is the case, you're gonna have to hope 
    >   Imail's logging is sufficiently detailed to help out.
    >   
    >   I'd try to match up some most recent T files with SMTPD 
    >   log sessions, then study the SMTPD log lines to see how 
    >   those sessions ended.  you "should" be able to match a 
    >   T file with SMTPD dialog, to confirm the dialog is 
    >   terminating before IMail sends OK to the SMTP client's 
    >   end-of-msg.
    >   
    >   With IMGate's great logging, I see a bunch of "lost 
    >   connection" or "timed out while sending DATA. Some 
    >   servers accept all the DATA command from IMGate, but 
    >   then are way too slow in writing the msg to their 
    >   disks, and returning "2xx OK" to confirm reception. So 
    >   IMGate times out, re-q's the msg and tries later.
    >   
    >   If Imail SMTPD is very slow in returning "2xx OK" after 
    >   DATA reception, that could indicate screwed up disk 
    >   system. Imail "should" 
    >   log a reason why the SMTPD session terminated abnormally.
    >   
    >   If Imail is ok, then zombies could be messing up by 
    >   sending theit DATA command, but hen dropping TCP 
    >   immediately (to go fast) without waiting for IMail 2xx 
    >   msg.  In that case, look in the T files to see if they 
    >   are legit msgs or spam.
    >   
    >   If the Imail logging shows these T files are happening 
    >   with a variety of legit servers, then you are forced to 
    >   conclude your end is screwed up.
    >   
    >   Len
    >   
    >   
    >   
    >   To Unsubscribe: 
    >   http://www.ipswitch.com/support/mailing-lists.html
    >   List Archive: 
    >   http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
    >   Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
    >   


To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html
List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/

Reply via email to