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.

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.

ExchangeDefender Policy Engine Bugfix

We recently started receiving complaints about certain users not having their SPAM and SURESPAM filtering policies applied correctly. For example, user would select to quarantine their SPAM and delete their SURESPAM but mail would still arrive in the inbox with the subject modified as [SPAM] or [SURESPAM].

As of 10 AM EST this bug has been fixed. If you have your mail set to quarantine on either of the SPAM presets the rules will be applied correctly. If that does not happen consistently and correctly please open up a support ticket at https://support.ownwebnow.com

Note: The issue was related to the legacy network policy server not syncronizing filtering rule tables in correct order. It would treat its local database as the most up-to-date one and would never apply the newer policies. This issue has been fixed.

Addressing recent increase in PDF SPAM

As you may have noticed over the last few days, there has been a huge increase in PDF SPAM. This spam is generally identified as a single message, with attached PDF containing JPEG image SPAM. This pattern easilly bypasses most appliances that have no ability to handle the processing power needed to decode images, much less those encoded inside a PDF file. Not that we’re gloating, but there are only 24 hours in a day and its not enough to talk about how different ExchangeDefender behavior is compared to RandomSpamApplianceFromTaiwan.

At the moment, there are also several unique characteristics to these images:

• they are all 7bit encoded.
• they all use a single useragent associated with the Mozilla Thurderbird mail software.
• they are all blank messages with no text in the body.
• the attachment matches the filename mentioned in the subject.
• pdf file is a legitimate PDF file with no publishing information except for a single JPEG

Based on all that its relatively trivial to trap these messages, however, we expect the pattern to continue and to escalate into making these messages seem more legitimate. While these PDFs are not dangerous in nature they can be annoying and your users should be warned to never open any attachments from contacts they do not trust/know.

As always, thank you for your business and we’ll keep your mail clean for you.

ExchangeDefender gets tougher on NDR and Backscatter

Over the past year we have seen a steady increase in NDR traffic. We’ve done something about it previously but have since gotten far more aggressive on it to the point that virtually every fake bounce will be automatically quarantined.

It’s important to understand the motivation behind the spoofing and massive NDRs they produce. There are two ways in which spammers abuse the NDR system: one is to steal identity and the other is to diminish the confidence in the SPAM filtering solution. The first is quite easy, they want to use a legitimate sender address so that the remote servers will accept the mail. To combat this you can easilly enable SPF/SenderID on your domain and never worry about it. The second is a little more involved/contrived and involves systematically taking apart the ability of the “installed” SPAM filtering solution to adequately sort out mail. Most installed SPAM filtering solutions (the ones you install on your server) and appliances alike (that are devices on your network) build reputation models based on how often legitimate mail comes from certain addresses and IP blocks. They also build local bayesian databases that index known SPAM and non-SPAM; As such, by flooding the server with mail from all over the place those databases the reputation scores become increasingly less reliable – a process more commonly known as poisoning.

So what are we doing and how does it benefit you? Assuming you are using our outbound servers to relay messages, your messages will contain special tracking that will match up what we have in our internal databases. If an NDR is received with that tracking in tact, the message is allowed through. If the NDR is received without that tracking that means that the message didn’t come from you, from your server, that it was spoofed – and it adequately goes into the SPAM quarantine where you’ll likely let it die.

ExchangeDefender Conference Call: April 19 & 20

Dear Partners, Customers, Friends,

We are holding a conference call next Thursday and Friday to discuss the new services offered by ExchangeDefender. Major areas of discussion will focus the new Live Archive feature (simultaneous Exchange & secure webmail delivery with 7 days trailing archive) and ExchangeDefender Agent (desktop alerts so you don’t have to wait for daily email reports). As this will conclude the rollout of major v3 feature sets I will also briefly describe the upcoming changes of the stuff that’s out there and little incremental features we expect to be delivering during Spring & Summer 2007.

Two conference calls, same content, not mandatory, recorded:
April 19 – Thursday – 7PM EST (23  – 24 GMT)
April 20 – Friday – 9AM EST (13 – 14 GMT)

Conference dialin number and access code:
Conference Dial-in Number: (605) 990-0400
Participant Access Code: 684592#

No registration necessary, not confidential information, attendance is not required.