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.
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.
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:
- If the sending server does not know to generate an NDR, the sending user may be unaware their message did not reach its destination.
- 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 setRecipientValidationEnabled 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.