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
-- ===================================================== MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ =====================================================
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/
