The Grinch that stole Quarantine Reports

No boys and girls, The Grinch didn’t steal the Christmas Quarantine Reports from Santa ExchangeDefender. They were just delayed while we ran some final tests on the new reporting engine. All OK.

The quarantine reports were sent out at 5:00 PM GMT on Monday, December 25th, 2006. Tonight they will resume their regularly scheduled reporting time of 8:00 AM GMT. The new reporting engine has already improved the performance of ExchangeDefender and opens up possibilities to integrate many features you have been asking for in 2006. We will soon publish our product roadmap for Q1/2007 and welcome input and suggestions from all of you.

Now back to killing SPAM.

ExchangeDefender Report Management Updates

For Christmas this year Santa (Pablo Averbuj) Claus will be bringing our customers a new report system management update. We expect to start on Christmas eve, December 24th at 6 PM GMT and be done by midnight.

There will be no downtime associated with this upgrade and no mail will be delayed. The upgrade will however make some sections of the system inaccessible while your particular domain is being upgraded. Because the upgrade requires us to migrate large collections of data from one database to another we do not want to give you incomplete information during the switch – so if you get your timing just right you might see “We’re moving, come back in 5 minutes” banner when you access your queue reports.

And yes, we’re really doing this on Christmas eve.

ExchangeDefender Begins Managed Tar-Pitting & Back-Scatter

Brilliant title, I know. But give me a chance to explain. Tar pitting and back scatter protection are two technologies that we have been working on for quite some time and in all current tests believe them to be ready for production. First the definitions:

Tar-pitting — The process of selectively delaying a HELO/EHLO response to an open SMTP connection.

Back-scatter — The bounce notifications of messages you never sent to begin with.

Tar-Pitting Protection

Tar pitting is simply a flow control mechanism. By default, SMTP servers answer and handle all connections at full speed. When a remote mail server connects on port 25 the destination mail server responds with its welcome banner and waits for the SMTP dialog to start, eventually leading to message delivery. Because SMTP is unaware of any reputation scoring it accepts communication from anyone in its access list and works as fast as the network and system resources allow. Because all SMTP servers by default work as fast as they possibly can it stands to reason they would become perfect spam targets for spammers that rely on sending as many messages in as little time as possible.

Enter tar-pitting. This mechanism is not new but until now presented significant shortcomings in terms of reputation. For example, your standard tar-pitting mechanisms either had a pre-configured timeout or timed out depending on how many connections the remote server opened. System administrators could configure their own tar-pitting settings which usually ended up in two unforeseen circumstances:

• The server would wildly fork and keep open processes listening on port 25 until all system resources were exhausted.
• The server would not recognize whitelists or reputation – applying the same throttling process to all mail server. So a large AOL mail exchanger that likely delivers thousands of messages a day to your organization would be greeted with the same delay as the SBS server that only delivered a few every other week.

Both approaches were faulty and resulted in a significant mail delay as well as performance degradation.

ExchangeDefender Tar-pitting

ExchangeDefender approach adapts our scoring and reputation technology. Servers become trusted over time and in real-time. Our research indicated that there are two polar types of mail servers out there: massive mail gateways and low volume mail servers. Massive mail gateways can be evaluated and over time trusted or whitelisted to get immediate service and reduce the amount of time they would have to wait for delivery. It stands to reason that a high activity mail server legitimately sends large volumes of mail over time.

However, if a low volume mail server started attempting thousands of connections per minute to our network we would get suspicious. Enter tar-pitting. By throttling low volume mail servers we can reduce overall network load and allow our spam filters to catch up in case these low volume mail servers were compromised to send malware, viruses, trojans or spam.

Back-scatter Protection

Back-scatter is simply the returned message (“bounce”) from a mail server that replied to a message you never sent. This threat has been around since the early days of commercial Internet in form of Joe Job attacks. In a Joe Job attack a spammer would assume identity and forge (“spoof”) a message to a remote recipient. The remote recipient would get upset at the “forged” identity and spammer would be in the clear.

Many faulty spam control mechanisms and Microsoft Outlook / Outlook Express exploits over the years created the environment in which trust was used to implicitly bypass spam filtering. Today when a computer is compromised by a virus or a trojan it can access files on the computer, mailboxes, email messages and more. By scanning the system for email addresses the trojan can build an impressive mailing list and then start spreading itself to those remote systems. The trojan assumes an identity of one of the email addresses on the system and uses it to reach another.

Think of all the email addresses stored on your computer in your address books, text files, accounting packages, etc. Most of them are outdated or gone, some may have their mailboxes overflowing, others have been disabled or have autoresponders on them. Viruses, trojans and other automatically generated content for the sake of spreading around the Internet does not care to validate the existence of the email – it only cares about getting as wide of a distribution as possible.

Thats where back-scatter comes into picture. All those bounced messages can come back into your mailbox to clog it with NDRs or even worse, infected messages that can compromise your security.

ExchangeDefender Back-scatter

Because our mail servers track where you send your messages we can also validate all the back scatter as legitimate or not. Typical non-delivery receipt (“NDR”) lists the subject, time, date, recipient email address and other information that is only known by the sending system and the recipient system. Considering that we control that sending mechanism, we can validate whether the NDR was caused by a message sent from our network or if it is simply a spoof.

Either way, we keep your mailbox clean. 

Implementation

We will begin the wide-spread implementation of tar-pitting and back-scatter protection this week. We have already tested the system adequately and believe that the reduced mail load over the holiday break will allow us to adapt the new processes while the network has more than its usual amount of spare resources.

No change will be required on your mail server and your users and customers will not see a change in the way that mail is being delivered our routed.