Cry Exchange 2010 How To...

---

How to turn on recipient filtering to prevent RNDR spam

---

Why might you want to turn on recipient filtering?

When an email is sent to the Exchange server, if the recipient email address does not exist then a Non-Delivery Report (NDR) is generated by Exchange and sent to the sender. This behaviour is useful as it lets the sender know that their email has not been delivered.

Unfortunately some spammers can use this feature to use your server to send spam. The technique works by sending an email to your Exchange server for a bogus email address, but with the return address of the target the spammer wants to send their email to. The exchange server duly generates a NDR, and sends it to the return address - which is the address not of the spammer but the target the spammer wants to spam. The end result is that an unfortunate victim receives a NDR which when they open contains spam that your server has delivered on behalf of the spammer. A symptom of your server being used in this way is a large number of NDRs queued up for delivery. This spammer technique is known as Reverse NDR attack.

To avoid allowing your Exchange server to be taken advantage in this way by spammers, you can change the way Exchange processes emails. The out-of-the-box configuration for Exchange is for it to receive all emails, queue them for delivery and only when it fails to deliver an email does it generate an NDR. An alternative configuration forces Exchange to check the recipient email address when it first receives the email, returning an error to the sending server if the address is not recognized. Genuine senders will still receive an NDR but the responsibility for generating this shifts to the sending server. This configuration is known as "Recipient Filtering".

If you have an Edge Transport Server

My understanding is that if you use an edge transport server then that will have recipient filtering enabled by default. So no action should be necessary. However, I do not have an edge transport server so I cannot check this.

Install the necessary Anti-Spam features

Unless your server is an edge transport server then you probably don't have the necessary anti-spam features installed.

As a quick test to see whether you need to install these open Exchange Management Console and navigate to: Microsoft Exchange > Microsoft Exchange On-Premises (server name) > Organization Configuration > Hub Transport. Do you have a tab called "Anti-spam"? If this tab exists then you already have the necessary anti-spam features installed.

If you don't have the anti-spam features installed then you can install them using the Exchange Management Shell:

1. Open a new Exchange Management Shell
2. Enter:
   cd "C:\Program Files\Microsoft\Exchange Server\V14\Scripts"
3. Enter:
   .\install-AntiSpamAgents.ps1
4. Finally, to restart the Microsoft Exchange Transport service enter:
   restart-service MSExchangeTransport

You can now close the Exchange Management Shell. If you reopen the Exchange Management Console you should now see the Anti-spam tab is now available.

The entire dialog should look like this (this is copied from my server):

To enable recipient filtering

To enable recipient filtering:

1. Open Exchange Management Console
2. Navigate to: Microsoft Exchange > Microsoft Exchange On-Premises (server name) > Organization Configuration > Hub Transport.
3. Select the tab "Anti-spam".

   If you don't see the tab "Anti-spam" then refer to "Install the necessary Anti-Spam features" above.

   The feature of interest is "Recipient Filtering". Whilst this is probably listed with the status of "Enabled", this does not actually mean that recipient filtering is being used.

4. Open the properties for "Recipient Filtering".
5. On the "Blocked Recipients", ensure that "Block messages sent to recipients that do not exist in the directory" is checked. Then close the dialog.

Recipient filtering is now enabled.

Down sides to recipient filtering

Whilst personally I would always use recipient filtering, there are some down sides to using it.

1. All incoming emails are now checked as soon as they are received, which means that there is an additional processing overhead when emails are being delivered. Normally this won't be noticeable, but might cause a problem for a very busy server. If it does become a problem then the logical step would be to deploy one or more edge servers.

2. In theory someone could work out what email addresses exist by trying different combinations of email addresses to see which ones get rejected and which do not. Exchange 2010 uses "Tar Pitting", which means that by default there is a 5 second delay before the server responds with a "User unknown" response. This makes it impractical for someone to try to brute force work work out what email addresses are likely to be valid.

To see what the current Tar-Pit delay is use Exchange Management Console and enter:

which will show the tar-pit delay for each receive connector, or to show the delay for a specific receive connector:

If you feel the need to change the delay (and personally I'd leave it at the default of 5 seconds) the use:

---

These notes have been tested with Exchange Server 2010.