If you have been the target of an NDR attack* attempt or made an error when configuring your Exchange server and have left yourself an open relay, then you may find that your queues on the Exchange server have a large number of invalid email messages.
Other symptoms include hard disk space is dropping rapidly and the server has become unresponsive. The Exchange logs are much larger than normal.
* An NDR Attack is where messages are sent to your server with an invalid email address on purpose. Your server then attempts to bounce them back to the sender. The only problem is that the sender has been spoofed and it is that address that is the intended target of the message. These attacks can be avoided with Exchange 2003 and Windows 2003 Service Pack 1 and higher using a new option - more info.
If you are looking for help with dealing with general spam, then start with our article on Exchange 2003 Intelligent Message Filter - here.
This article is based on the MS KB 324958 which was written for Small Business Server and MSKB 909005 which is for the full version of Exchange. Some of the techniques have been adjusted based on our experience with following the guides. Original articles:
Before you start cleaning up the server, you need to find the source of the problem and deal with it.
A Telnet test involves establishing a Telnet session from a computer that is not located on the local network to the external (public) IP address of the Exchange server. You need to carry out the test from a machine at home, or from another office. Doing the test from a machine on your own network will produce useless results.
There are two parts of the Exchange that can make your Exchange server an open relay, the Default SMTP Virtual Server and SMTP connectors. You need to check both to ensure that you haven't configured them wrongly and turned your machine in to a spammers target.
To check or correct the configuration of the Default SMTP Virtual Server:
Once you have made the changes, restart the SMTP server service and then repeat the telnet test above to ensure that you have closed everything.
This technique requires the Windows Event Viewer to determine whether a user is trying to use the SMTP service in Exchange to send email. If you have disabled the authenticated user option already then this isn't an issue. (more info)
You now need to watch the Event Logs on the Exchange server. In the application log you will see something similar to the following which can indicate that a user is trying to send email through the SMTP interface.
Event Type: Information
Event Source: MSExchangeTransport
Event Category: SMTP Protocol
Event ID: 1708
Description: SMTP Authentication was performed successfully with client test-pc1. The authentication method was LOGIN and the username was domain\username.
If the account being used is "Guest" then you need to disable the Guest account.
If it is another account then you need to either change the password or disable the account.
Ideally you do not want any kind of relaying going on. The best option if this is happening is to disable the feature altogether. If this isn't practical for business reasons, then you need to secure it as best you can - see this page for more details on how you can do that.
Note that the most common account that is used for this type of attack is the Administrator account. Therefore if you suspect that that the administrator account is being abused, then change its password and restart the SMTP Server Service to ensure that the new credentials are used. The administrator account is attacked because it doesn't lock out.
If you are under an NDR attack, then you will find lots of messages in the queues of the server. These messages have special characteristics which make them easy to spot.
Note: If you are using an SMTP Connector to route email through your ISP using a smart host, then you cannot detect this type of attack. The messages are sent straight out to the ISP by your server. If your ISP has alerted you that there may be a problem, you will need to use message tracking and the SMTP log to detect the cause of the attack.
If you are on Exchange 2003 with Windows 2003 then you can stop an NDR attack by using recipient filtering and the tar pit option in Windows 2003. You will still need to clean the queues using the techniques outlined, but it will stop further traffic.
If you are on Exchange 2003 on Windows 2000 then you should NOT enable recipient filtering as this exposes your server to a directory harvest attack.
Exchange 2000 users do not have any kind of recipient filtering options available to them.
Therefore you should look at a third party tool that can do the filtering for you, often referred to as an LDAP lookup. Vamsoft ORF has Active Directory filtering and has a 30 day trial version.
Once you have found out the cause of the problem and dealt with it, then you need to clean up the server.
Block port 25 on your firewall/router so that SMTP traffic is not coming in while you cleaning the server. This stops new messages, both spam and valid messages and also ensures that nothing you want is lost while you clean up the server. As long as you do not leave the port closed for longer than 48 hours then genuine inbound email will still be delivered.
When following this procedure you should note that it can take NUMEROUS ATTEMPTS OVER MANY HOURS before the queues are clear. Exchange System Manager is notorious for being unable to show the true extent of the queues when it has been abused in this way, so messages can continue to appear even after you think you have cleaned the queues.
Warning: This process will delete all email that is due to go to external recipients. Internal messages are not affected, neither are new inbound messages from the Internet unless they are from the spammer continuing to try and abuse your server.
This process requires an SMTP connector for all addresses. If you don't already have one (with a * on the namespace tab) then you need to create one using the instructions below.
If you already have an SMTP Connector with a * on the namespace tab, then you can use it for this process. You will need to adjust the settings as appropriate. You may wish to just make a note of the settings, delete the connector and create a new one for this process. When complete recreate your live connector.
The Exchange SMTP virtual server is now processing all the messages and placing them in to a single queue for your SMTP connector. This can take some time. You may want to wait until the number of messages in the queue stays constant before attempting the next stage.
Exchange 2000: The queues can be found in Servers, <your server>, Protocols, SMTP.
Exchange 2003: The queues can be found in Servers, <your server>, Queues.
You may also find the Servers listed under an administrative group.
To locate the required queue, look for a small red clock on the yellow icon. This indicates that it is on a timed delivery.
Now that the messages are in one queue, it is quite easy to delete them
Once the messages have been deleted, which could take some time, refresh the queues to ensure that they don't continue to build. If they do then Exchange is still processing the messages. You will need to repeat the procedure to delete more messages until the queues are completely clear and stay at zero.
Once you have flushed out the messages, undo the changes that you have made.
If it was a new SMTP connector, delete it.
If you adjusted an existing connector, put the settings back how they were. Don't forget the time on the "Delivery Options" tab. it should be "Always Run".
Finally restart SMTP virtual server to get Exchange to start using the new settings.
If you closed port 25 during this process, then remember to open it up again.
If you have a very large number of messages, then there is a command line tool that you can get from Microsoft.
Then go in to the folders: Exchange Support Tools / Aqadmcli
(Due to the use of spaces in the folder names, a direct link isn't possible)
After downloading the utility use the following command to clear all the queues.
aqadmcli delmsg flags=all
Messages that have been stuck in the queue but cannot deliver will usually end up in the "badmail" folder. This folder can take up a lot of space. You should remove the content of this folder to free up some valuable space.
Exchange 2003 SP1 and higher does not use the Badmail folder unless you specifically enable it via registry hack.
There are various techniques for dealing with the badmail folder. This blog posting outlines a useful script that you can use to do it for you: http://hellomate.typepad.com/exchange/2003/07/dealing_with_ba.html
If you were an open relay then you may have ended up on some of the blacklists. When the message bounces back you will get a reason code which should include which blacklist has rejected you.
To get off the blacklist you will have to find their web site and follow their procedure.
As a short term measure, setup an SMTP connector to send all your email via your ISPs SMTP server. You can find more details on how to do this here.
If you want to use an Email Blacklist yourself, then you will need to setup filtering. This article at MS tells you how:
Those of you using an older version of Exchange will have to use a third party tool - whether this is commercial or open source. Vamsoft's ORF has blacklist support.
A number of related articles can be found elsewhere.
One morning you find that there is spam in the queues, your server has been blacklisted etc... (blog - opens in new window)
This blog posting explains what is likely to have happened if your Exchange server has lots of messages in the queues, or your server has been blacklisted. Once you know what has happened, you can deal with it.
Did the Spam Originate Inside Your Network? (blog - opens in new window)
This blog posting will help you identify whether the spam messages that you see in the queues originated inside your network, or not.
© Sembee Ltd. 1998 - 2015.
Reproduction of any content on this web site is prohibited without express written consent. Use of this web site is subject to our terms and conditions.
All trademarks and registered trademarks are property of their respective owners. This site is not endorsed or recommended by any company or organisation mentioned within and is to provide guidance only and as such we cannot be held responsible for any consequences of following the advice given.
Sembee Ltd. is registered in England and Wales at 33 Scrivens Mead, Thatcham, Berkshire, RG19 4FQ.
Registered company number: 4704428. VAT Number GB 904 5603 43.
Sembee is a registered trademark of Simon Butler and is used under licence.