The Edge Transport server role in Exchange Server 2007 performs messaging hygiene functions like connection filtering, sender filtering, et al.
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 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 lookup AD directly and drop messages for invalid recipients.
Exchange Management Console 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
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 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 lookup AD directly and drop messages for invalid recipients.
Exchange Management Console 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
Labels: Anti-Spam, Exchange Server 2007

Exchangepedia Blog is read by visitors from all 50 US States and 150 countries world-wide

3 Comments:
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!!
Post a Comment
Links to this post:
Create a Link
<< Home