ExchangeDefender Delivery Alert
Over the past 24 hours we have received a lot of complaints about the non-delivery of email to random recipients from random hosts on the Internet. At this point we have been able to narrow it down to Microsoft Exchange 2003 servers running IMF v2 and Microsoft Exchange 2007 servers also running IMF. In all instances the mail was acknowledged by ExchangeDefender, processed and delivered to the target mail server. In several instances mail disappeared completely. In others only certain recipients “didn’t get” the message.
We cannot stress this strongly enough: Turn OFF any SPAM filtering enabled on your servers, along with any SPF checking, validation or firewall port 25 data inspections.
The only rules that should be enabled are those described in previous posts dealing with port 25 restrictions.
How come an email was received by one user but not on the other if they were cc’ed?
Frequent question asked today in our support portal. For example, two users in the same organization were receiving an email. Or perhaps a distribution list where a single email address delivers to Outlook/mbox and other relays externally to a Blackberry address. If one gets it and the other doesn’t thats ExchangeDefender’s fault, no?
No. ExchangeDefender does not modify/alter the message body nor does it split the message that is being delivered. The message is delivered in a single direct stream at which point Exchange further processes the message and delivers it to the delivery agent (which further relays the message or forwards it depending on local rules.) Exchange also uses technology called single instance storage, allowing a single message to be stored in the database if it is received for multiple recipients.
So, if a message was received by one user it must have been received by the other. Why can one see it while the other can’t? Turn up message tracking and see. However, we are currently seeing this as an issue related to Outlook Junk Filters and IMF, both of which need to be disabled for reliable mail delivery.
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.
ExchangeDefender v3.1 Live
ExchangeDefender v3.1 core is now live.
Over the next five days we will go through the core aspects of ExchangeDefender and all the new features. We will provide ample screenshots and feature details so you can best implement ExchangeDefender in your day-to-day email management.
Keep an eye on our blog at http://www.ownwebnow.com/blog
Setting up IP restrictions for ExchangeDefender
The following guide helps you setup IP restrictions to allow only ExchangeDefender mail servers to connect to your network. We encourage all customers to configure IP restrictions because spammers and hackers should not be allowed to connect to your server directly without going through us. As a matter of fact, nearly all direct server SMTP connections after the MX records have been switched over to ExchangeDefender should be considered as hostile. Hackers and worms often scan entire networks to find vulnerable mail servers to be exploited. By only allowing access to the ExchangeDefender network you can reduce your exposure of critical services on the Internet.
This guide applies to Microsoft Exchange 2003 which is also a part of Microsoft Small Business Server 2003. To get started login as the Administrator and click on Start > All Programs > Microsoft Exchange > System Manager.
You will see the Exchange System Manager screen shown below. Please expand the Servers folder, expand Your server folder, expand Protocols folder, SMTP folder and finally right-click on the Default SMTP Virtual Server and select properties.
Click on the Access tab and then on the Connection button. This is where you will setup your IP restrictions. Note: You can also setup IP restrictions on your firewall.
Select Only the list below to restrict access to your SMTP server to ExchangeDefender networks only. Click on Add to start adding IP address ranges.
Select Group of Computers radio button and type in the subnet address and the subnet mask. There are several:
65.99.192.0 / 255.255.255.0
65.99.255.0 / 255.255.255.0
64.182.164.0 / 255.255.255.0
64.182.133.0 / 255.255.255.0
70.84.106.0 /255.255.255.0
72.29.99.0 / 255.255.255.0
216.123.109.0 / 255.255.255.0
64.182.140.0 / 255.255.255.0
64.182.139.0 / 255.255.255.0
After you have entered all the IP address ranges click on Ok. Click on Apply.
That is all! If you have any questions or if you would like us to assist you in the process described above please open up a support request at https://support.ownwebnow.com or just give us a call at (877) 546–0316
ExchangeDefender LiveArchive launches on Monday!
We are very excited to announce that after months of development and beta testing, ExchangeDefender LiveArchive is officially launching this Monday, August 6th, 2007.
What is LiveArchive you ask? LiveArchive is a provision for business continuity – to allow your business to stay in business and keep on communicating even if your mail server, Internet connection or other means interfere with the mail flow to your mailbox. As e-mail is being processed by ExchangeDefender it is copied to a live mail server. The original message is delivered to your corporate mail server or sits in the queue if your mail server is down. At any time you have access to the past seven days of email via secure, web based interface available from anywhere you can browse the web. The connection is secured using commerce-grade SSL, the logins and access are audited for compliance purposes and even on-disk encryption is supported.
The best part? Well, it’s free. Yes, free as in each mailbox you currently have protected by ExchangeDefender can have a LiveArchive feature enabled through the control panel at no additional cost to you. As an additional show of appreciation for our community, LiveArchive is offered free of charge to the Florida government organizations and emergency operations during the hurricane season and has been in beta testing since March.
ExchangeDefender v3.1 Core Rollout
We are comencing with our ExchangeDefender router core rollout. This piece of software/hardware manages the flow of messages through the ExchangeDefender network.
We anticipate the work to be complete by 9 PM EST today. Between 5 PM EST and 9 PM EST no mail will be dropped but may be delayed slightly (in most situations not at all, in some situations it could take up to 10 minutes)
Thank you for your patience.