Home > Exchange > Exchange 2010 Recipient Filtering on a Hub Transport Server

Exchange 2010 Recipient Filtering on a Hub Transport Server

September 23rd, 2010 Leave a comment Go to comments

I have a sound understanding of Exchange server 2003 but skipped a whole generation by never really testing/playing with Exchange 2007. However, I recently undertook a server migration where I deployed Exchange 2010 and decommissioned an old Exchange 2003 server. I replaced the server like-for-like and so the Exchange 2010 server was also a single server operating in the domain.

Before hand, I decided to try a deployment on a test server just to see if I had any issues. The server is a single box that is also a Domain Controller. For testing purposes I also installed Exchange 2010 onto the same server. Initial installation and configuration was a breeze and I was soon sending and receiving email internally and externally. Upon investigation of some of the more granular Exchange configuration I soon had an issue when I tried to enable Recipient Filtering, there was simply no option to do so.

Recipient Filtering can be used for a couple of reasons. The first is to filter/prevent emails from being sent to specific email addresses that do exist within your organisation. The second is to prevent your email server from processing emails sent into your organisation to email addresses that do not exist. This typically happens in a couple of different situations when:

Scenario 1. A spammer targets 1000's of email addresses

  • Spammer sends 1000's of emails with different FROM addresses (victim's addresses)
  • Spammer sets the TO address as xxxx@yourdomain.com (non existent address in your organisation)
  • Your email server receives and processes the emails but cannot deliver them to a mailbox
  • Your email server replies to the 1000's of FROM addresses sending each 1 piece of NDR spam

Scenario 2. A spammer targets 1 email address 1000's of times

  • Spammer sends 1000's of emails with a common FROM addresses (victim's address)
  • Spammer sets the TO address as xxxx@yourdomain.com (non existent address in your organisation)
  • Your email server receives and processes the emails but cannot deliver them to a mailbox
  • Your email server replies to the FROM address sending it 1000's of pieces of NDR spam

Scenario 3. A spammer targets your email server

  • Spammer sends 1000's of emails with different TO addresses (which won't exist in some organisations)
  • Spammer sets the FROM address as xxxx@yourdomain.com (non existent address in your organisation)
  • Recipient email servers send an NDR to the FROM address (non existent address in your organisation)
  • Your server receives 1000's of pieces of NDR spam it then attempts to process and deliver

By enabling Recipient Filtering you make sure that if your email server does receive an email for an address that does not exist within your organisation it is blocked during initial SMTP communication. Recipient Filtering is by far faster and more efficient than evaluating the mail after it is received and already in the mail queue. This means that:

  • Your server can no longer be used to send NDR spam to other email servers (Scenario 1 & 2)
  • Your server will experience a reduced load if it comes under an NDR spam attack (Scenario 3)

The problem I had with Exchange 2010 was that I could not find where to configure Recipient Filtering! In Exchange 2003 it was configured under Global Settings --> Message Delivery. You then had to configure Advanced options on the SMTP Virtual Server and ensure the option for Apply Recipient Filter was applied. My Exchange 2010 installation did not have any such option(s) out of the box. It turns out the reason for this is that features of this nature are usually best suited to Exchange 2010 servers with the Edge Transport role installed. I attempted to modify the Exchange 2010 installation through Control Panel --> Programs and Features but the Edge Transport role was greyed out. An Exchange 2010 server with the Edge Transport role configured cannot have any other Exchange 2010 components installed, and since everything else was installed on my test server there was no way to enable the Edge Transport role.

Exchange 2010 setup screen

After some searching around I found out that Recipient Filtering and a few other options like Sender ID are labelled as being Anti-spam features within Exchange 2010. I discovered that it is possible to install the Anti-spam feature (through the use of a PowerShell script) on an Exchange 2010 server configured with the Hub Transport role. This can be accomplished by:

  • Open the Exchange Management Shell on the Exchange 2010 server
  • Change directory into:

    C:\Program Files\Microsoft\Exchange Server\V14\Scripts

  • Run the following to install the Anti-spam option:

    .\install-AntispamAgents.ps1

  • Run the following to restart the Microsoft Exchange Transport service:

    restart-service msexchangetransport

  • Open the Exchange Management Console and check that the Anti-Spam tab is available under Organization Configuration --> Hub Transport

Exchange Management Console Hub Transport Anti-spam

Now that the Anti-spam features are available and enabled for use, I needed to make sure that the Recipient Filtering was configured. By opening the properties on the Recipient Filtering feature I could see that the option to 'Block messages set to recipients that do not exist in the directory' was not enabled. I checked this option to enable it as required.

Recipient Filtering Properties

A quick test using Telnet and the server was no longer receiving emails for addresses that do not exist in my organisation. Of course, doing this has a drawback. There would be nothing to stop a malicious user from using an automated tool harvest legitimate addresses within my organisation by sending email to random email addresses until successful. Fortunately, Exchange 2010 has Tar Pitting functionality enabled out of the box. Tar Pitting is the practice of artificially delaying server responses for specific SMTP communication patterns that indicate high volumes of spam or other unwelcome messages. By default Exchange 2010 delays the response sent to an email server (where an attempt is made to send to an address that does not exist in your organisation) by 5 seconds. Tar Pitting therefore makes directory harvest attacks too costly to automate efficiently. I personally think a 5 second delay is sufficient to thwart most directory harvest attacks, although the delay can be adjusted as necessary through the Exchange Management Shell on the Exchange 2010 server.

Run the following to retrieve the current Tar Pit interval in seconds:
Get-ReceiveConnector "Your Conector Name" | select tarpitinterval

Run the following to change the current Tar Pit interval (to 10 seconds in this case):
Set-ReceiveConnector "Your Conector Name" -TarpitInterval 00:00:10

Run the following to disable Tar Pitting:
Set-ReceiveConnector "Your Conector Name" -TarpitInterval 00:00:00

  1. aaron
    October 13th, 2010 at 15:05 | #1

    nice one, how on earth did you find that beauty out!!

  2. RedMango
    October 18th, 2010 at 12:58 | #2

    Very nice post!

  3. Mathiau
    August 12th, 2011 at 18:14 | #3

    awsome info!

  4. January 6th, 2012 at 12:15 | #4

    Clem,

    This is a fantastic post, good job.

    George

  5. Garen Hagopian
    December 17th, 2012 at 18:07 | #5

    great info, you saved me a lot of hassle
    those annoying queues have been driving me crazy.

    thanks again.

  6. Billy Becker
    December 27th, 2012 at 22:06 | #6

    Great post, very much appreciated. We use Google's Postini for our Spam/Virus protection for emails coming in to the organization, but this would be great for the rest that are forwarded on through. I do have one question, with using the Postini for inbound, are there any other drawbacks other than what is listed in the post about harvesting email addresses? I don't see any but maybe someone has come across an issue. Also, we use one server for all our services. Thank you in advance.

  7. September 26th, 2013 at 12:40 | #7

    Also, you can use SenderID to block non existent domains. Extremely powerful trick. Check out this http://wp.me/p1eUZH-87

  8. baya
    December 13th, 2013 at 09:53 | #8

    This helps a lot!!!!

    Greetings from Croatian.

  9. Vikas
    May 21st, 2014 at 11:04 | #9

    Excellent! Info cheers, it helped me a lot in my test setup, great job

*