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