Exchange Recipient Validation

Exchange server has a recipient filter that prevents mail submissions to accounts that are not in the GAL (Global Address List).

First, let’s locate this configuration and then we’ll talk about how it works followed by thoughts about relay domains.

How to enable this feature

To enable this filter in Exchange 2003 you would visit the Message Delivery Properties screen, and select the checkbox next to Filter recipients who are not in the Directory. You would also need to enable it on each SMTP connection.

clip_image001

 

Exchange 2007 and 2010 also have this feature, though the name has changed and so has the location of the controls. It is now considered an Anti-spam technology, therefore navigate to the Anti-spam tab on your Edge Transport server, and select Recipient Filtering. Within you’ll find Block messages sent to recipients that do not exist in the directory on the Blocked Recipients tab.

clip_image003 

You can also use EMS and type:
Set-RecipientFilterConfig -RecipientValidationEnabled $True

If you are not using an Edge Transport server you can still leverage this feature, however you must first install the Anti-spam agents on your internet-facing Hub Transport server(s). Once you have done this, visit the Anti-spam tab within Organizational Hub Transport Configuration or use the PowerShell cmdlet.

  

How does it work?

Let me describe how this feature works by comparing behavior with it turned off versus when it is turned on.

Below is an example of an SMTP session under both conditions. Assume there IS NOT a valid mailbox (or contact, folder, etc) for “NOTrealuser@DemoLab.local”

RecipientValidationEnabled $False (default)  RecipientValidationEnabled $True
220 server1.demolab.local Microsoft ESMTP MAIL Service ready at Fri, 4 Jun 2010 13:32:33 –0400
ehlo
250-Server1.demolab.local Hello [::1]
250-SIZE
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-X-ANONYMOUSTLS
250-AUTH NTLM
250-X-EXPS GSSAPI NTLM
250-8BITMIME
250-BINARYMIME
250-CHUNKING
250-XEXCH50
250-XRDST
250 XSHADOW
mail from:externalperson@somewhere.com
250 2.1.0 Sender OK
rcpt to:NOTrealuser@demolab.local
250 2.1.5 Recipient OK
220 server1.demolab.local Microsoft ESMTP MAIL Service ready at Fri, 4 Jun 2010 13:35:52 -0400
ehlo
250-Server1.demolab.local Hello [::1]
250-SIZE
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-X-ANONYMOUSTLS
250-AUTH NTLM
250-X-EXPS GSSAPI NTLM
250-8BITMIME
250-BINARYMIME
250-CHUNKING
250-XEXCH50
250-XRDST
250 XSHADOW
mail from:externalperson@somewhere.com
250 2.1.0 Sender OK
rcpt to:NOTrealuser@demolab.local
550 5.1.1 User unknown

What we see is that with RecipientValidationEnabled set to False, Exchange accepts the email even though the user is not valid! This of course means more overhead on the Exchange server because it has to process the message, only to later realize there is no account for the address. Once Exchange comes to this realization it will send a bounce back message (NDR). This NDR is not only even more processing, but this can contribute to backscatter.

Now let’s take a look at the 2nd column, where we have RecipientValidationEnabled set to True. We see that Exchange immediately rejects the message because the user is unknown. This cuts down on processing as well as is a step in preventing the abovementioned backscatter. This also results in faster bounce back messages because they are generated by the sending server, not the receiving (our end) server.

If this feature is so great, why isn’t it enabled by default!? Good question. I have two potential answers:

  1. If the sending server does not know to generate an NDR, the sending user may be unaware their message did not reach its destination.
  2. This could aid a “hacker” in a directory harvesting attack. Because Exchange quickly reports on the validity of email addresses, it could be used to learn what accounts are valid and what are not.

Despite the abovementioned risks, I usually DO enable this feature.

It is worth noting that being “hidden” from the GAL or other address lists has no impact on this feature.  They still receive their mail just fine.

 

Relay Domains

I was not able to find documentation about how this feature works in conjunction with Internal-Relay and External-Relay Accepted Domains. The natural question that comes from this area is:

Will enabling this feature cause Exchange to reject mail for recipients in shared address spaces or address spaces not handled by Exchange mailbox servers at all?

This is a good question, because recipients in internal or external domains will NOT be in your Global Address List, and therefore it sounds like the feature will block mail sent to them.

The good news is, this is not true. Exchange will accept mail for any account in an Internal or External relay domain! While this is good news for those users, remember this reduces the effectiveness of the feature itself.

Consider a scenario where I share @mikecrowley.us across 2 mail systems. In this case, some of my users would have exchange mailboxes, and others would not. Even if I set RecipientValidationEnabled to True, Exchange would accept mail for all users in the @mikecrowley.us namespace. This is because it has no way of knowing what mailboxes might exist on the other system.

The way to leverage a shared namespace WITH this feature is to create contacts or mail-users for each remote user, and set the Accepted Domain type to Authoritative.

7 thoughts on “Exchange Recipient Validation

  1. Excellent. Just what the doctor ordered. A method for notifying senders of non-delivery (assuming their mail server supports this functionality) and an effective way of staying off of backscatterer.org’s extortion list. 🙂

    • If that is accomplished by a service mailbox, it would be included. If however you are talking about receive connectors, that is not a “recipient” per se and not on this report.

  2. We can block on the “rcpt to:” area no doubt, but, how about in the “mail from:” area? Do you have any idea how to block fake senders? Most of the spammers are using that method.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s