Without any (known) changes in the configuration, a few weeks ago the queue at Protocols -> SMTP -> Default SMTP Virtual Server -> Current Sessions, start to accumulate 'sessions' with "Connected time" well over the default 10 minutes time-out. Once the session exceed the default "100" , theserver start rejecting the calls with Event ID: 402 I can manually "Terminate" or "Terminate All" the sessions, however I'm looking to find the reason and/or the fix for this problem. The setup for the "Default Virtual Server Properties" are "Limit number of cennections" to 100 "Connection Time-out ( Minutes)" to10 Thanks,

the increase in connection can have many causes, spammers or evil people on the net, bad applications trying to send mail., increase in mail flow or a TCP connections problem. if you look under the SMTP virtual server you can see live connections. you can cut down on the connection timeout to 5 min and see if this helps you.

Lasse, This is not the situation. Thecommon display looks like the following screenshot: http://www.wtrade.com/images/ExchangeSmtp.jpgas you can notice, it's spammer activity in one case comming from 209.222.*.* and another from 67.219.*.*,with fake domain names. Probably my serveris rejecting the call, however there is no reason to keep the connection up for more than 320,000 seconds!!! I'm using Connection Filtering, blocking using RBLs and Intelligent Message Filtering rejecting the call. NETSTAT show anopen connection with the remote server in "Close_wait" state. ..... partial NBTSTAT displayTCP sombrero:54271 CORAL:ldap CLOSE_WAITTCP sombrero:smtp ip-67-219-110-164.razorservers.com:48983 CLOSE_WAITTCP sombrero:smtp ip-67-219-117-26.razorservers.com:47675 CLOSE_WAITTCP sombrero:smtp ip-67-219-117-137.razorservers.com:56035 CLOSE_WAITTCP sombrero:smtp 209.222.72.42:36653 CLOSE_WAITTCP sombrero:smtp 209.222.72.220:38425 CLOSE_WAITTCP sombrero:smtp 209.222.72.233:39794 CLOSE_WAITTCP sombrero:smtp 209.222.81.245:47603 CLOSE_WAITTCP sombrero:smtp 218.23.82.150:14128 TIME_WAITTCP sombrero:http c-66-229-28-74.hsd1.fl.comcast.net:24410 ESTABLISHEDTCP sombrero:http 157.238.184.163:53926 ESTABLISHEDTCP sombrero:epmap Sombrero:48765 ESTABLISHEDTCP sombrero:netbios-ssn mail.wtrade.com:40107 ESTABLISHED .... Again, I can force the close with a right and "terminate". I need manually check the server and 'clean' the queue, otherwise, the number of active connection will exceed the limit and SMTP will rejectfuture requests.

Looks like your server is trying to tear down the TCP connection but it does not get any response from the other end. Could be an issue with your FW or a combination with your FW and Exchange box. I would get a netmon trace of one the mail sessions and investigate in detail. is your server allowing unlimited number of mail per session?

It's hard if not impossible to get a Netmon, this unclosed connections showup without any pattern, at any time of the day (or night) and from random IPs. The solution I'm using now is to recycle the SMPT service, however,sometimes the SMTP shutdown is so slow that timeout the service manager, then the option is to recycle the IIS... Not sure where to set the number of mail per session, most likely I have the default value. Any method to get a better log from the SMTP service directly?

Have you tried to stop AV and/or anti-spam on your Exchange server if you have any installed.

This is 100% microsoft shop..... no third party software. For anti-spam we areusing RBL's with connection filtering, antivirusare on the desktops not server (too many issues in the past). We also use the best protection method: you get a virusyou are fired. Today the queue show two connections open for about 4 hrs. I restarted SMTP this morning.

some wild guesses. have you enabled tarpit http://support.microsoft.com/kb/842851/en-us and if so, how long timeout have you set? tarpit is a good thing but a very long timeout is not good. What is the "limit number of messages per connection", properties on the virtual SMTP server and messages tab. the default value is 20.

No, no Tar Pit here... I have the server oiled. Actually, only some domain get stuck in the queue; once found my Internet vendor stuck there!!! Another symptom: if I have one or more connectionsin errorand I force the SMTP to stop (...Protocols -> SMTP -> Default SMTP Virtual Server , right click "Stop") thestop process "timeout". Then, the option is to recycle IIS, and usually takes less time. Thanks for your time, regards,

have you enabled senderID checks http://support.microsoft.com/kb/927478/en-us could also be the receiving domains using greylisting http://support.microsoft.com/default.aspx/kb/934709/en-us could be solved with editing theGlitchRetrySeconds http://technet.microsoft.com/en-us/library/aa998772.aspxyou have to try this setting with different values, but 60 or 120 usually does the trick

Lasse, I appreciate you continuous help and cooperation on this issue. KB 934709 refers to outgoing messages in queue, I do not have this issue. KB 927478, also make reference to outgoing queue, however,sender-id is not enabled on the server, I have "Accept" selected. During lastfew days, no incoming message has being stuckas"connected mode" in the SMTP Virtual Server, I think that this is just "good luck" or my RBL (zen.spamhaus.org) is blocking more malformed SMTP servers... Francisco

If you run a network sniffer and filterto show only traffic between Exchange and one of the hanging IP's, is there any traffic going back or forth or is it just silent? Run this for more than 15 minutes

Lars, Thank you very much for your help. During the last two weeks no more unusual events were detected on the queue. As before: no changes, manual patches or even reboot. I will keep the SMTP service under observation and let you know if happen again. sincerely, francisco