I don't even have the monitor service running. :(( John
On Wed, 22 Sep 2004 20:13:49 -0400, Matt wrote: >�Let me chime in on this issue. �Someone that I work with had the >�same >�issue spring up last week and we seem to have resolved it fairly >�easily, >�although not necessarily in an optimal situation. >�We found that by turning off the restart function in IMail Monitor >�for >�the SMTP server, the problem went away. �With this on, his SMTP >�service >�would stop functioning in a permanant-type fashion, but with it >�off, it >�instantly stopped crashing. �He has separate monitoring that shows >�under >�very heavy load (dictionary attack in progress from multiple nodes >�simultaneously), the SMTP server doesn't answer the connection in >�time. >�I believe that IMail Monitor looks for the connection and not the >�status >�of the service, and then it restarts the service if it gets no >�response. �I believe that it was trying to restart the SMTP service >�while under heavy load and merely when the SMTP service wasn't >�willing >�or maybe able to open additional connections, and restarting the >�service >�at this time caused it to hang. �Now that IMail Monitor isn't >�restarting >�the service, it has stayed up without needing to be restarted for >�over a >�week instead of just a few hours at a time. >�I'm not sure about the capabilities of IMail Monitor, nor the logic >�in >�restarting a service after a single failure. �I wouldn't be >�surprised to >�see a single attempt fail to connect, but it would be best to retry >�multiple times as I would imagine E-mail clients do. �So momentary >�failures might go completely unnoticed in the real world >�conditions, but >�IMail Monitor may be overreacting and SMTP might be too unstable to >�restart during heavy load. �This could have all come out of nowhere >�to >�affect multiple versions of IMail due to a change in the way that a >�single dictionary attacker pounds on a server, and they are most >�definitely capable of taking any server down that they choose with >�their >�thousands of zombies doing their dirty work. >�So my suggestion would be for you to turn off the restart feature in >�IMail monitoring and maybe instead use Windows to monitor the >�service >�instead of the connection. �This did work with an 8.13 >�installation. �My >�own server on a prior 8.x release with the restart feature in IMail >�monitor has not caused me any issues and my server is quite busy, >�so I'm >�not quite sure what is triggering this, but it came out of the blue >�with >�a vengeance on this other server. >�I have also noticed on my server that there are locked spool files >�that >�remain that way for over 15 minutes, possibly 30 minutes. �It could >�be >�that IMail is hanging on to failed connections for way too long and >�recycling them more frequently would prevent some of the SMTP time- >�outs >�(just guessing of course). �Spamware isn't generally well written, >�and >�if IMail is expecting the connecting server to ACK before >�disconnect and >�will otherwise wait 15-30 minutes to close the connection or >�release the >�lock on the spool file, that would seem to be a mistake. �Take this >�paragraph with a grain of salt because the conditions might be due >�to >�something else. >�Matt ColdFusion ASP ActiveState PERL Hosting Includes 10 Domains - 100% Browser Based Administration http://www.cybersmarts.net LogFileManager - IIS LogFile Management Tool WebPageChecker - Helps Maintain Server UpTime http://www.serverautomationtools.com 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/
