I'm not sure that stopping queuemanager will prevent deliver to remote
peer. It's a smtpd32.exe service task. So if you just stop and restart
the queuemanager you just claim to redeliver all spool to the intendent
recipients. In fact, when peer-to-peer connection established and D file
being downloaded the Q file is already know by the server, since the
connection filtering doing before downloading the mail content. But I
don't know the reason why server create q file after downloading the
appropriate d, so the situation is quite possible if the connection is
broken.

Regards,
Dmitri Elgin,
http://imailzip.com


-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rick Davidson
Sent: Tuesday, September 21, 2004 10:02 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: [IMail Forum] D files with no Q files - Queuemanager crashes
with unreachable peer (again)


Is there a way to send orphaned D files that have no associated Q file
other 
than manually creating a Q file?

Does anyone have a utility that will read through a directory of D files
and 
create the Q files? Sure would be handy.

As I have posted many times in the past and submitted to Ipswitch, the 
problem with Imail Peering when a peer is unreachable (like during a 
hurricane) the master peer (the one behind the mail gateways) queue
service 
will eventually fail with a buffer problem causing mail to not be
delivered. 
A netstat reveals all the allocated ports in the TIME_WAIT state. I run 
seven peers across the country and occasionally an internet connection
goes 
down making the peer unreachable. I was running a batch file to stop and

restart the queuemanager service once an hour (and recommended by
Ipswitch 
support to work around the problem) I now realize that this is causing
files 
to be orphaned due to the delivery process being stopped by my batch
file, 
thus the D files without Q files.

Ipswitch claims the fault is with the MS TCP/IP Stack, hopefully the 
following info can generate some answers and some ideas from the brains
on 
this list and at Ipswitch.

I found that the default application port allocation is from 1024 to
5000, 
when Imail attempts to reach a down peer and the queue is building up 
messages destined for the down peer these ports get used up sitting in
the 
TIME_WAIT state. The busier the server the quicker the situation
manifests 
itself.

The MS default TIME_WAIT is four minutes and there are 4076 ports
available 
for Imail SMTP and Queue processes. I found the following MSKB articles 
showing reg hacks to modify the TIME_WAIT length and the default
application 
port allocation.

I set the TIME_WAIT or Maximum Segment Life (MSL) (TcpTimedWaitDelay) to

half of the default time to two minutes.

I set the port allocation to 65534 (MaxUserPort)

http://support.microsoft.com/default.aspx?scid=kb;EN-US;196271
http://support.microsoft.com/default.aspx?scid=kb;EN-US;149532
http://support.microsoft.com/default.aspx?scid=kb;en-us;319504&Product=w
in2000

I haven't had the buffer problem since but we haven't had a lengthy
downtime 
to really see what happens and of course the last thing I want to do is
hope 
for another hurricane to hit Florida just to test this :-) I will probly

have to setup a dummy peer and see what happens and that if it isn't
fixed I 
catch it before the phones light up.

Any comments about these reg hacks would be welcomed especially if you
know 
reasons why I should be doing this. Also it would seem to me that a mail

system should be able to grab more ports if it wants to be capable of 
extremely high loads without hitting a low port allocation wall and
choking. 
It also makes me wonder if this is related to other queuemanager
problems if 
the solution is to rake files out of the queue so it can catch up
without 
stopping.

Rick Davidson
National Systems Manager
North American Title Group
- 



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