IIS SMTP server queue filling up and allowing rogue or unauthorized connections
Posted on 2010-09-13
My overall configuration is this: 2 Windows Server 2003 systems. Server #1 runs Exchange 2003 which receives mail for the entire domain and also sends mail for users in the office who connect to the server with Outlook in Exchange mode. Server #2 is just Server 2003 with SMTP installed in IIS. This server is for sending only, it is used by field workers who connect via Outlook with POP3 (to server #1) and SMTP to server #2.
On server #2 the SMTP settings are as follows: On the Access tab of the SMTP server Properties under Authentication the server is setup to require basic authentication. Under Relay it is set to relay for 'Only the list below' (the list is blank) and then it is set to 'Allow all computers which successfully authenticate to relay, regardless of the list above.'
A barracuda protects all incoming mail.
The server has been setup this way for a LONG time. In the last month I have been having problems with the smtp queue folder filling up, I currently have 60,000 emails in the queue. I can see connections under 'Current Sessions' in IIS from IPs in China, Nigeria, Russia and a few others. All of the connections show in the following format:
User 188.8.131.52 34 seconds
I don't have a user called 'User.' Usually with legit connection, the user portion is either the user's actual computer name or the local IP they are using.
Any ideas how to make this stop? I forced all of the field users to change their passwords and that seemed to work for a day and half or so. I only forced the field users because the only server with issues was #2 which only serves the field workers. My thought is that a user's computer is infected with something that is stealing the password so the password change only worked for a short while. I have encouraged them all to scan their computers but I have no direct control to force that to happen.
I have used various tools on the Internet to check my system for an open relay or other issue but everything seems to be OK. At one point I assumed that this was an NDR attack because most outgoing messages were from email@example.com. But now the queue has emails from external domains to other external domains. Our domain is not part of the process at all!