ExchangeDefender activates the new IP range
Commencing at midnight, August 15th, 2007 we will start relaying mail using the two new subnets announced a few weeks ago. We have also provided a helpful guide to setting up IP restrictions with Exchange 2003. It is also recommended that you enforce IP restrictions on your firewall depending on your network topology.
Our scans indicate that over 80% of our customer base has the new IP ranges programmed in. If you have not programmed in these IP restrictions please do so now:
64.182.140.0/24 (64.182.140.0-255, or 64.182.140.0 / 255.255.255.0)
64.182.139.0/24 (64.182.139.0-255 or 64.182.139.0 / 255.255.255.0)
Several questions also came up during this recent change, I am posting them here in hopes that they may answer some of your questions:
Why are you adding more IP ranges instead of using load balancers?
Each network subnet has specific routing and providers that service it. If we used a load balancing appliance we would be restricted to a single gateway / network interface which does not always scale with the network availability in a given data center. Also, by using multiple IP addresses from different subnets we can use different network providers allowing us to have a more distributed network that is less prone to a single point of failure.
Why should I not use the *.exchangedefender.com as the restricting mechanism instead of IP addresses that always change?
Domain restriction question came up often. There are many reasons that we insist on using IP restriction policies but most relate to the most reliable deployment practices. We find that most of our customers do not have a reliable DNS system, so exposing customers and requiring them to run a massive amount of DNS queries could impact message delivery times, cause delays and even drops/rejections. PTR records can also be easily forged by anyone who has authoritative control over their IP address range, IP spoofing is a lot more difficult.
Why should I use Exchange access controls over the firewall access controls?
We recommend using firewall access policies to manage access lists to your servers. You should only allow connections via tcp port 25 for insecure SMTP and tcp ports 465/587 for secure SMTP/TLS connections from our range to your server and from your server to our outbound network. This is the most secure and the most effective way of locking down an SMTP server deployment.
However, such a deployment is often not practical for business use and causes a number of business issues that you may need to be aware of. For example, if you have external CRM deployments or external SMTP services (marketing, lists, subscriptions) that connect back to your network servers via port 25 restricting the connection via firewall would disable all those services. If you have authenticated users from remote servers connecting to your Exchange 2003/2007 server to relay mail via port 25 this deployment will also not be practical (remember that with authenticated connections you bypass IP restriction enforcement.)
I have programmed in the new restrictions, how do I know if it works?
We have enabled a subnet check wizard at http://check.exchangedefender.com
Just paste your IP address in the form and if your server accepts messages from that range you will get a green pass. If it fails, it will tell you so in bright red font.
If you experience any issues with this transition please open up a trouble ticket immediately and we will do whatever we can to help you with the issues that arise.
