February 2008

Generally we keep ExchangeDefender maintenance on the NOC site but due to the extent of the maintenance done we felt it was important to place it here as well. Over the past 12 hours we have conducted urgent maintenance on the following systems:

  1. ExchangeDefender reporting servers (ongoing, 8-10 hours remaining)
  2. ExchangeDefender antispam engine (ongoing, up to 99.2% efficiency)
  3. ExchangeDefender outbound network (complete)
  4. ExchangeDefender global load balancing (complete)
  5. ExchangeDefender cluster upgrades (complete)

It will take another 2-3 hours for the latency across the network to go down. The email reports will resume later today. The new outbound network hardware is online and active. The new reporting servers will go online this weekend along with the global network upgrade to Microsoft Exchange 2007 Service Pack 1.

We apologize for the inconvenience the additional mail latency has caused you and your clients, this will be the last major network upgrade for quite some time and the last major maintenance before the start of the ExchangeDefender 4.0. Most of the engine underneath of ExchangeDefender is running 4.x code already.

For updates on the ExchangeDefender maintenance please keep an eye on our NOC site at www.ownwebnow.com/noc

Over the weekend we deployed a few enhancements to the antispam engine and hopefully starting tomorrow you should see far less junk in your Inbox. We have been testing this engine in parallel and have not seen a significant increase in false positives so we are positive this will be an improvement in overall performance and filtering rates.

As usual, if anything slips please forward it to spam@ownwebnow.com

Note on the forwards:

In the event that an obvious SPAM message gets through ExchangeDefender and into your mailbox, you can forward it to us at spam@ownwebnow.com for further inspection. There are times that the SPAM you received was from a source that is not known for spamming or that the message just did not contain enough obvious junk content to be filtered through. We also ask that you forward inline SMTP headers (in Outlook right click on the message in the listing, select Message Options and copy Internet headers) to us so we can verify that the message indeed passed through our network and that it was not released by one of your coworkers that it was cc’ed to (this happens all the time, someone releases the message from a familiar looking sender/subject and its a SPAM that was either cc’ed or bcc’ed to everyone in the organization). For 4.0, we are working on an Outlook addin.

If you are one of our partners and would like to hide the ownwebnow.com domain name, you can have messages sent to spam@exchangedefender.com. If you would rather give your customers your own address just create a mail enabled contact in your organization and forward it to either alias. Be advised that we may sometimes reply from that address in which case they will see our company name and our contact information – however, this is very infrequent! (mostly when people forward a few dozen identical items to which they have obviously subscribed to, such as popular newsletters, shopping sites, etc)

As mentioned previously, we are starting to tighten up the network backend before the UI overhaul of ExchangeDefender 4.0 takes place. In preparing for it we are trying to adjust our network to help reduce load as well as improve the quality of service and transparency.

First the problem: Message sent to user XYZ was not received, can you please check?

There are three possible outcomes to the question above:

1. Almost always the message was delivered properly but the remote users server either discarded it as SPAM or the user outright deleted it and just did not want to fess up to it. We have invested thousands of man hours with our partners where the message from customer A went to customer B and can be backed up with transaction logs of the sending server, ExchangeDefender and recipients mail server. It made it to the mailbox. Then it disappeared. That we can’t do much about but with LiveArchive we have made it possible for our own customers to retrieve those mysteriously undeliverable items.

2. The message was delivered but discarded at some point in the process (ExchangeDefender, third party mailer, broken DNS, etc)

3. Something that we aim to fix: Message was delivered to ExchangeDefender but did not get delivered to the remote server because the remote server uses greylisting, callbacks, long delays, internal content blacklists, guy in the basement writing SpamAssassin rules.

The Solution: Less time in the queue, faster alerts to the user that there is a problem.

Our current settings will retry to deliver the outgoing message for up to five days. Error reports are sent within 24 hours. That is clearly too long as the users complain of issues within hours of sending the email. We will be generating errors sooner than later to help the IT staff and IT Solution Provider explain to the customer that the issue is on the remote recipients server, not on their own or ExchangeDefender which will help with the endless troubleshooting requests over the proven infrastructure just to find out that the recipients server has a poorly configured mail server.

This change in policy will only affect outbound mail, inbound mail will remain the same.

Going forward we will be issuing non-delivery alerts within 3 hours. We will return the message to the sender if the message is not delivered within 24 hours. Based upon the advice of our IT Solution partners and our internal testing, we have concluded that this is an adequate amount of time to attempt to deliver the message and if the delivery fails this gives the sender an option of contacting the recipient through other means until their mail problems have been solved.

ExchangeDefender 4.0 will feature full access to the ExchangeDefender transaction logs both inbound and outbound but in the meantime we felt it was important to introduce this change due to the growing number of hosts that are without protection and just unable to properly handle the amount of inbound mail sent to them. Each undeliverable and unreported issue with the remote server unfortunately increases the cost of support and reduces the satisfaction with the mail delivery because users tend to start blaming their own IT staff first. We hope these errors help the users see where the issue is sooner than later so they can continue to communicate with the remote party through other means.

We are implementing two new policies and processes for ExchangeDefender activations and billing. Some of these have been with the service for a while but since we didn’t enforce them we have opened ourselves and our partners to abuse.

One of our long standing policies is to have a 1-to-1 mapping of all valid e-mail addresses. Every e-mail address on your server that receives email must be on ExchangeDefender as well. This allows us to lock down your server to valid recipients only and thereby reduce a lot of traffic that really shouldn’t exist in the first place.

Going forward, all new ExchangeDefender accounts will be locked down to valid recipients only. Messages sent to non-existent accounts will be rejected with the following error:  “550 ExchangeDefender does not protect this email address (directory harvesting attack rejected)”. If a valid recipient notices this error, make sure you add their account to ExchangeDefender.

Every 20th of the month a new accounts summary will be sent to you so you can adjust your billing for the new accounts that have been created that month. This will allow us all to be in sync with the accounting.

New domains will have their activations provisioned and created within four hours (previously 24). If you choose to do your activations yourself please keep in mind that your ExchangeDefender deployment will be locked down immediately, so do not point the MX record until you have created your users accounts.

In ExchangeDefender 4.0 slated for 2nd Q of 2008, the activations will be immediate and we are also working on a server agent that will keep the server in sync with the ExchangeDefender network eliminating double data entry.