The Symantec Brightmail Gateway 8.0 release had three main goals:
1. Re-architect our core MTA infrastructure.
2. Increase antispam effectiveness.
3. Increase message throughput.
In this article, you'll find out how the new architecture brings greater flexibility and great performance gains.
Arguably the biggest changes in Symantec Brightmail Gateway 8.0 is the underlying Message Transport Agent (MTA) architecture.
Rebuilt from the ground up and designed specifically for antispam and content filtering. The MTA has been completely replaced (Postfix is gone) and everything has been simplified and streamlined for performance.
As a bit of a primer, let's quickly explain over the architecture in the previous releases up to Brightmail Gateway 7.7.
Previously, there were 3 instances of Postfix running on the appliance; Inbound, Outbound and Delivery.
Each of these instances consumed memory, CPU resources and wrote messages to disk and read from disk.
Additionally, using Postfix kept our developers hands a little tied when it came to developing and improving features.
With the 8.0 release, these 3 MTA instances have been replaced with one single MTA instance. This MTA instance deals with message in memory, only writing to disk once (incase the system loses power during message processing). Straightaway, even assuming the new MTA provides the same performance as Postfix gave us, there is a pretty cool reduction in resources and increase in performance.
Before I go further on about performance, I want to call out some of the new MTA based features.
Since so much of the new antispam effectiveness (which will be discussed in the next post) comes from reputation based technology, it was important to make sure that each Brightmail Gateway instance could handle a HUGE number of concurrent connections. Improvements to the connection management system mean that the number of concurrent connections the MTA can accept has risen to well above ten thousand connections.
You are now able to specify multiple downstream (internal) MTAs to route local mail to. So to provide some fault tolerance, you could specify your multiple Exchange 2003 Front End servers. Then if your main server goes down, Brightmail Gateway will use the preference value to choose the next server to deliver to.
You can even use this new feature to round-robin load balance across the downstream MTAs.
The 8.0 release includes flexible IP address bindings. You can configure which IPs bound to Brightmail Gateway will be used to deliver: Local messages, Non-local messages (see page 89 of the Administration Guide for an explanation of local and non-local domains), Dynamically routed messages and Messages destined for the control center.
The new queue architecture allows a lot more flexibility. You can limit the maximum number of connections, connections from a specific IP, recipients per message and total number of messages on a per queue basis.
We’ve also introduced the ability to have individual delivery profiles for each domain you accept mail for and deliver to.
One last feature to call out before we finish up on performance is the addition of FastPass to Symantec Brightmail Gateway 8.0.
FastPass was originally developed for our Symantec Brightmail Message Filter product and was designed to provide our Service Provider customers with a way to increase message throughput without compromising the effectiveness of the Brightmail solution.
We know that messages that contain no 'threats' take the most CPU resource to process as we have to use every single rule to prove that it is not a spam message. Whereas a spam verdict is returned as soon as an anti-spam rule is fired.
Using a combination of global reputation and local reputation we are able to see the patterns in mailflow unique to your environments.
There are usually a large small number of IP addresses sending nothing but good, clean, non-threat email to you. Our Global Intelligence Network research shows that around 99% of all good mail comes from only 2% of all connections that send 100% legitimate mail.
With Fastpass enabled, most email messages from verified good senders bypass spam filtering, thus freeing up resources to be better spent elsewhere. Not only that but, because we’re not doing as much antispam processing on known good senders, we lower our already incredibly small rate of False Positives (legitimate mail marked as spam).
Of course, getting a FastPass in the first place requires the sender to be squeaky clean when we sample mail. Additionally, a senders FastPass is revoked as soon as our ongoing sampling picks up anything from them that is marked as spam.
FastPass is just one part of our Adaptive Reputation Management (ARM) system, new to 8.0. ARM will be discussed further in my next post.
PERFORMANCE
First, the disclaimers; :-)
You should be aware that throughput is something that can be measured in a number of ways and information can be somewhat misleading, so let me make sure we are clear on what is being discussed here. When I talk about message throughput, I am talking purely about messages that are accepted and processed by Brightmail Gateway with FastPass enabled.
Also, these numbers are run against our 2nd tier hardware appliances, the 8360 model. I decided to use these as opposed to our top spec servers because I wanted to give a middle line indication of performance. We also used one particular mail corpus, which was used against each version to benchmark the performance increases.
I will explain how the throughput numbers can be affected (for the better) by IP reputation in the next post covering Adaptive Reputation Management.
Our target for this hardware was to achieve a 30% improvement in throughput over the 7.7 release.
Throughout our beta testing phase and regular builds, our QA and Engineering teams have been taking snapshots of system performance which show that we’ve actually hit a 76% increase in throughput over 7.7!
If you are still running the 7.6 release, we see an increase of 185%!!
If you are still running the 7.5 release (seriously, upgrade), we see an increase of 196%!!!
The other great thing is that this number is achieved without maxing out the CPU. We actually hit around 80% utilisation.
Remember, this is the number of messages accepted and processed by Brightmail Gateway.
In the next post, you'll hear about our Adaptive Reputation Management and how this is pushing further performance and accuracy gains in the Symantec Brightmail Gateway 8.0 release.