Archive for July, 2011

Let us talk about SMTP connectors configured in the routing group in Exchange Server 2003.

Whenever Exchange Server 2003 setup in your environment relies on a third party email firewall protection to work as a middle layer between Exchange Server and the internet. you may have different aspects to consider to ensure Exchange behavior to deliver and receive email from these third party email firewalls.

The first point to consider is the placements of your Email Firewall. as this will be your facing point to the internet (bi directional) so you have to consider the placements in a secure network segment which usually we call it Demilitarized Zone (DMZ).

Exchange Server by design and best practices must be located somewhere in your internal network segments. Why? the fact is the heavy integration and dependencies between Exchange and you Active directory is unlimited. so putting Exchange Server in the internal network and/or in the same subnet where your DC’s operations maters holders is the best practice. still you can place it any where you want like DMZ. but why this is not recommended by any Exchange Architect?

Exchange integration with Active Directory is one of the highest twin integration in comparison to any other products. let us consider putting Exchange in a DMZ (for security reasons) then the amount of rules, protocols and ports you will open in your firewall is something beyond what you can expect. which is for the first look give you the impression you don’t have a firewall anymore. LDAP, LDAP/SSL, IMAP4, NNTP, NNTP/SSL, HTTP, HTTP/SSL, SMTP, SMTP/SSL, SMTP/LSA, RPC, DNS … etc. all are protocols used by Exchange and not only that, they are using different ports range. which will lead you to have a heavy work on your firewall in addition to a lot of risks aligned with that.

Now, as we agreed. Exchange will be placed somewhere in the internal network where the communication with Active Directory will be seamless.

Now, how will email firewall communication with Exchange will take place? and how you can ensure that this email firewall will not be a single point of failure (Assuming your Exchange Server is already high available/Clustered).

Sure you will need a email firewall technology with will offer a high availability on the technology itself. in case one failed the second will take over. and this will be aligned with your internal and external MX Records. usually providing the same MX records cost is the best scenario to do in case of high availability as you will ensure a balanced external email hits both your email firewalls (both = minimum high availability).

By doing this you will ensure a minimum high availability requirements to keep you email system alive and visible to the outside world in case any point of failure occurs in your email firewall system.

the question now is, how you will ensure the Exchange server email delivery to these email firewall whenever these emails are marked for external delivery. how you will ensure the email flow delivery to be aligned with email firewall design.

A lot of Exchange Servers designs I have seen was depending in putting a smart host IP address of the email firewall in the Exchange Server configured at the SMTP Virtual Server settings. which is logically reasonable. but why this practice is not the best thing to do?

First, assigning the SMTP virtual server this task considered an overhead in Exchange Server. as the external emails marked for external delivery will go first to the local delivery queue. then marked by the Virtual Server to be forwarded to another on spot created queue using the DNS query name (Let us say the domain address is and then the delivery will take place to the smart host (Email Firewall). now this process is not the best thing you can do as you are overwhelming the SMTP virtual server for multiple decisions to be taken which will case queue to react slow and will increase a noticeable deterioration in Exchange Performance.

Second, the Smart Host name will be used, which one? remember you have two email firewalls for high availability? and you cannot put two smart hosts in the same SMTP Virtual Server. then you are limited to use only one Smart Host. now consider this Smart Host refers to the one of the Emails Firewalls failed? then no Exchange delivery for external emails will take place. and your system will face an outage for external delivery.


Looking at the two reasons above. in addition to more security and performance aspects you don’t want to go with smart host assigned in the SMTP virtual server.

So the best solution, keep in mind when u plan to deliver any email outside your internal Exchange Organization is to use Routing Groups. Routing Groups designed specifically to help your current Exchange Org. to communicate with external email services or another Exchange Org. outside your domain hierarchy.

Routing Groups will be used as an SMTP Connector to specify a name or IP to where you want your Exchange Organization to communicate emails with.

The beauty of this solution is you can have as multiple as connectors to communicate with different email gateways/firewalls. as the most important is the ability to have load balanced connectors pointing to load balanced/ high available email firewalls/gateways.

This can be accomplished by creating more than one connector to point to a specific domain OR * which indicates all domains and give both connectors the same cost. this will ensure at least if one connector or its destination device failed. your email system will keep routing the external emails using the second connector to the second alive emails firewall/gateway. the same scenario can be applicable in case of more than two gateways exists.


The step by step guide for the above to implement is easy and can be found

There is a lot of hidden advantages apart from what mentioned above. apart from ensuring high availability and so on. this action will improve Exchange performance and the queue delivery as exchange will be aware about a dedicated external queue delivery which will decrease the decision making overhead on the internal SMTP Virtual Server. in addition to securing the communication in the right way as you are segregating the SMTP engine for External Delivery from the local delivery (This topic of securing Exchange is another story which we will talk about in a different topic).