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
We have seen numerous server not comply to the RFC covering this. This is
the main cause of the duplicate messages we are seeing lately
RFC 2821 4.5.3.2 Timeouts
DATA Termination: 10 minutes.
This is while awaiting the "250 OK" reply. When the receiver gets
the final period terminating the message data, it typically
performs processing to deliver the message to a user mailbox. A
spurious timeout at this point would be very wasteful and would
typically result in delivery of multiple copies of the message,
since it has been successfully sent and the server has accepted
responsibility for delivery. See section 6.1 for additional
discussion.
An SMTP server SHOULD have a timeout of at least 5 minutes while it
is awaiting the next command from the sender.
Eric S
----- Original Message -----
From: "Len Conrad" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, August 25, 2005 8:37 PM
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.
.
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/
