ExchangeDefender LiveArchive

ExchangeDefender LiveArchive is easilly the most popular feature we have introduced in years. Simple to understand why, its a part disaster recovery part business continuity solution that doesn’t cost you anything and works without any maintenance whatsoever. The idea is simple: mail servers and Internet connections tend to be unreliable. Hard drives fill up, Internet connections go down, Outlook profiles or Exchange mailboxes/stores become corrupted our dismount, you name it — we’ve seen it. But the solutions for Exchange business continuity and disaster recovery are very expensive, require appliances and still do nothing when those Internet connections go down.

We have an answer in ExchangeDefender LiveArchive: Your mail, in addition to being delivered if the server is up or queued/mailbagged in case it’s down, is also simultaneously delivered to a separate mail system on our network. We keep a realtime storage of past seven days of your inbound mail along with your profile settings “Vlad Mazek <vlad@ownwebnow.com>” along with all your other mail identities. When you can’t connect to your mail server, you’ll be able to connect to ExchangeDefender LiveArchive server just by going to this web site:

https://archive.exchangedefender.com

Username: your email address

Password: your exchangedefender password

Both should be easy to remember and are even easier to enable. To get started with ExchangeDefender LiveArchive you have to enable it. As a Domain Administrator go to Configuration, scroll down to LiveArchive and select Enabled. If you want this new setting to apply to all the users in the domain just select the checkbox that says “Make this the default setting for all existing users.” and you are set. By default, without this box checked, only new accounts created within this domain will have ExchangeDefender LiveArchive enabled so making sure this box is checked is important. As the ExchangeDefender Service Provider you can accomplish the same by going to Management, selecting the domain to manage and clicking on Change Configuration. Same screen, same configuration.

That is all you need to do and all you need to know. It is important to recognize that this is a true live mail system that you can read all incoming mail, respond to it, delete it, forward it or whatever you wish and can do with your Outlook, Notes or Groupwise clients. The site is always on and always has the latest 7 days of email available. Email is delivered in realtime, meaning that you can communicate with people even while your mail server or Internet connections are down, it does not stop delivering to LiveArchive just because it cannot reach your mail server.

Finally, reading and managing mail here does not mean we start bouncing or redirecting mail – the mail will still be delivered to your server  once it or the Internet connection are back online.

We did everything we could to make Exchange LiveArchive an easy deployment and as easy to use as your own mail client. However, trick to properly executing business continuity is in making sure your employees know this exists and training them on how to access it before they need to do it in an emergency so here are a few checks you need to do:

[ x ] Make sure your employees know and remember the address of https://archive.exchangedefender.com

[ x ] Make sure your users know and remember their email address and password to be used with https://archive.exchangedefender.com – for security purposes this should be different than their server password.

[ x ] Make sure your users are aware of the dangers of using insecure Internet connections, computer kiosks and third party equipment that could be keylogging their usernames and passwords.

[ x ] Consult a lawyer for mandatory legalese in case you have to disclose that your infrastructure is temporarily down. Work on the customer service skills so employees properly notify their contacts that response times may be lagging due to an emergency.

There is a lot more to business continuity but I hope that the ExchangeDefender team at least makes it less of a burgen to communicate in an emergency and gives you the time and resources to deal with high priority problems and not fixing the email.

Unusually high amounts of SPAM in reports today

Due to the recent high-end changes in the ExchangeDefender product (v3.1, NDR handling, archving) we had to rebuild the way we currently manage and process whitelists, trusted senders and outbound mail trusts.

Because this was an urgent modification due to the number of mail servers relaying mail without RDNS, we had to make the change during peak hours yesterday. It in turn affected our ability to properly whitelist incoming messages so if anything seemed like spam, it ended up in the SPAM folders. Yesterday’s report (Monday) contained a large amount of messages that would otherwise been delivered. You can request a release of those messages but you do not need to trust those senders as they are already likely in our whitelists.

NDRs – We spoke too soon

The process we implemented to reject mail from mail servers that have no valid reverse DNS over the last few weeks was unfortunately very short lived one. Unfortunately, we’ll start accepting mail from servers with no reverse DNS entries, allowing our customers to accept mail from mail servers that should not exist on the Internet at all.

After a flurry of complaints we had no choice but to shut down the service that handled the rejections. Instead, we will allow them but will automatically assign a score high enough to qualify the host as SPAM. If this is a legitimate sender to whom you have sent mail in the past, or if you have them on your whitelist, they will get by our SPAM scanners and the host will thus have a better reputation which will keep it out of our internal blacklists. As for others, once they hit that treshold we will place them in our internal RBL and reject mail with the standard disclaimer giving them an option to remove themselves from or RBL’s.

This is not what we would have prefered to do but business is business, email is vital to it and when you complain about how much SPAM is out there remember that you amplify it by doing business with customers and partners that do not have a properly deployed and managed IT infrastructure.

Loose e-mail in the cloud.. with diamonds (ExchangeDefender Mail Tracking)

One of the most frustrating calls you can ever receive from the user is the one that begins and ends with the words: “We are constantly, constantly not getting our mail” – and its your task to prove to the user that you are not at fault (by locating the message). Over 99.9996% of the time the messages end up getting lost through server or client deployed antispam software that should be turned off in the first place. But let’s assume you checked that. Let’s assume you disabled Outlook Junk Filters, Let’s assume there is no IMF on the server. Let’s assume there is no SMTP inspection enabled on the firewall. Let’s assume you have no “security” appliances in your way.

What then?

With ExchangeDefender v3.1 we are giving you full access to our logs, down to the SQL level (more on this to follow). Let’s assume that a user tells you they never received a piece of email, you’re sure everything on their end is working perfectly.. how do we find out if ExchangeDefender messed up? Pretty easy, let’s see where the message went.

Login as the Service Provider

Login with your service provider account to our portal at https://admin.exchangedefender.com

Head over to the new tab, Mail Log.

Select the domain name you wish to run the report on. Search Criteria window will drop down and allow you to put in some basic information (such as the senders email address, subject). Everything except the “To:” field is optional, if you leave both the subject and the from address empty you will see a report of all mail received for that user. All searches are also partial and case insensitive, so you can try to narrow it down if the user isn’t sure of what they were expecting.

Hit find and you will be presented with a list of messages that matched the search criteria. These messages include SPAM, SureSPAM, clean messages, infected messages – basically you see everything we processed.

If you have a question about what may have happened with the particular message you can just click on the Details link (hold CTRL down to open in a new window if you have a few messages) and you will get the following screen with message details:

It is important to note a few things here. First, you are seeing the message details because we accepted and processed the message. If we didn’t, there would be nothing to show. If you encounter that situation, find out who the sender is and open up a trouble ticket. We send rejection notices (as per RFC) to all mail we do not process so if there was an error on our side the user would have received the notice.

Second, it is important to understand that this shows ALL mail processed by us – spam, clean, infected. If it is SPAM it will show a score higher than 0.00. If it is infected, it would say that as well. Also, if you see this message it means it was accepted, processed, and delivered to the user (or dispatched to the delivery queue). Anotherwords, fire up Message Tracking on their Exchange system and dig using the message identifiers noted in the Message Details screen above.

We will have SQL access layer completed by the end of next week which will allow you to see the transaction log down to the SMTP connection and remote queue id signs.

Looose e-mail in the cloud… with diamonds… (its what rings in my head when people tell me they didn’t receive their email)

End of an era at ExchangeDefender

Dear Customers and Partners,

I have just signed off on an implementation that in my mind is long overdue. For years ExchangeDefender processed messages from senders that did not have legitimate reverse DNS entries for their mail servers. As a major supporter of small business and a small business ourselves, we understand that at times it is difficult to appropriate enough funds to properly manage a complex IT infrastructure. As such, we have accepted messages from hosts that do not have valid PTR/reverse DNS because we are aware of how many small businesses rely on the unreliable and poorly configured appliances that generate real business email. Everything from copiers down to portable scanners now generates email of some sort, not to mention the many web sites and services.

However, dealing with this problem over the past year has become impossible to sustain. The amount of worms and botnets launched from dialup, dynamic and even missing DNS has been on an exponential rise and we continue to receive a bulk of our mail from mail servers that would not be accepted as a relay anywhere else. While we want to do whatever we can to assure email delivery, it is simply not feasible to ignore the RFCs anymore.

So, starting today, ExchangeDefender will require a valid DNS entry before accepting your messages. The mail will never be rejected but we will defer accepting it until you (or your IT consultant or your ISP) provide a valid PTR record / reverse DNS for your mail server. Should a message come in from a server that does not have valid reverse DNS you will get the following error: 

4.7.1 Access temporarily denied. ExchangeDefender requires you to have valid reverse DNS PTR record in order to send mail from [IP]

This is a hard-coded network-wide setting that does not allow for any exceptions. The sender will be notified immediately and will have a chance to setup a PTR record and allow us to accept their mail. For help with how to setup and manage DNS please have the remote sender contact their ISP.

This move will reduce the amount of SPAM you have to review each day and will reduce the number of worms and annoying SPAM messages you have been seeing over the past year or so.

I again want to stress that we did not come to this decision lightly but based on the statistical breakdown of where most of the threats were emerging we had no choice but to defer connections from hosts that do not comply with the basic standards that govern the way mail is sent around the Internet.

As always, thank you for your business and trusting us to keep your mailbox clean.

Sincerely,

Vlad Mazek, CEO, Own Web Now Corp.

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.