The Edge Transport server role in Exchange Server 2007 performs messaging hygiene functions such as Connection Filtering, Sender & Recipient Filtering, Content Filtering, and SenderID Filtering. (You can also install antispam agents on the Hub Transport server role— for topologies without an Edge server. See ‘HOW TO: Install anti-spam agents on Hub Transport server‘.)
In Exchange Server 2003, Recipient Filtering has an option to “Filter recipients who are not in the directory“. In Exchange Server 2007, this is called Recipient Validation. In a topology with Edge Transport server(s) deployed, Hub Transport servers transmit a list of valid SMTP addresses to the Edge. This is not required in environments without Edge servers – HT servers can look-up AD directly and drop messages for non-existent recipients.
The Exchange Management Console (in Exchange 2007 RTM) does not have the option to turn on Recipient Validation. Use the following command to turn it on:
Set-RecipientFilterConfig -RecipientValidationEnabled:$true
To check your Recipient Filtering configuration:
Get-RecipientFilterConfig | fl
In the above example, results from the Get-RecipientFilteringConfig cmdlet are piped to the Format-List cmdlet. fl is an alias for Format-List. See Using the Exchange Management Shell for some helpful information on Exchange shell.
{ 3 comments… read them below or add one }
Have you looked at the performance impact of this yet in Exchange 2007? I would imagine it’s not noticeable on low volume systems…. but on higher volume systems this may be a consideration.
http://joshmaher.wordpress.com/
That’s the first reaction I had years ago when such features were introduced (in other MTAs) and implemented!
There will be some performance impact, but that’s negated by the fact that you’re not accepting messages for recipients that don’t exist.
If you start accepting these messages, you would end up spending processing cycles for anti-spam filtering, and at some point the system responsible for delivery (if it’s not the host accepting the message) will have to look up a list of users (AD) and determine that the recipient doesn’t exist.
Finally a NDR would need to be generated for such messages. With a very high probability of the sender being invalid as well, the NDRs would sit in your queues and delivery attempted till the messages time out. This also leaves you vulnerable to a reverse NDR attack.
The same argument can also be made for RBL lookups – each connection blocked potentially stops 10s/100s/1000s of messages (depending on your SMTP VS configuration.. ) from entering your system and going through similar processing cycles.
Comparatively, even in high volume environments, adding more resources (scaling up or scaling out gateway boxes) is a better idea, imo.
yes this is true, and in theory there should be no issues, most appliance (ironmail, ironport, etc) do this with no performance issues if they are sized properly. The same should be true of exchange, of course that all depends on the number of recipients, the number and size of servers you have, and the amount of mail you receive.
I was just curious if anyone has done any work yet to find where the sweet spot was for these things.
Thanks!!
{ 1 trackback }