06 September 2012

For quite a few years, we utilized Postini as an inbound SMTP proxy and virus/spam filter. The virus and spam filtering capabilities were very nice, but similar functionality was easily available on-premise using a plugin for Icewarp (our email server software). However, the proxy/spooling functionality was at least as important for us, and having the filtering occur off-premise provided several performance and stability benefits.

Advantages to the Old Postini Setup

Even though we did not take full advantage of the Postini feature set, it still did a good job providing us with security, stability and performance.

  1. Postini took care of all spam and virus filter updates.
  2. We were able to restrict SMTP traffic to Postini using our hardware firewall to avoid dealing with automated attacks against port 25. That firewall restriction also ensured that all email had passed through Postini's virus and spam filters.
  3. Postini's spooling eliminated the primary downside to Internet connection volatility. When our email server became unreachable due to a server restart, power outage, or Internet connection issue, Postini simply held the email until it became available again. There are various services that specialize in this.
  4. Using their blatant spam blocking, 10-30% of the emails sent to our domain never hit our networks or affected our resources.

The Obvious Choice?

Google acquired Postini in 2007. Now, Google is working to transition all of the Postini users to Google Apps by 2013. Given that Google has integrated most of the features into Google Apps, it is the obvious choice for us to move to. I say "obvious" because it might not be the best choice. For instance, Google does not provide a static list of IP addresses that you can use for a firewall configuration, which immediately eliminates some of the benefits. There are other vendors that could provide the exact same configuration at a very low cost (e.g., SpamHero). However, we are leveraging various Google tools already such that using Google Apps does provide some potential synergies down the line. So we stick with Google.

Adjusting the Email Server Filters

The basic flow of the email filters was:

  1. Apply basic whitelisting and blacklisting
  2. Process postini headers to handle spam as we see fit based on scores
  3. Allow other emails (non-spam and trusted local sources) through

Since we can no longer rely on firewall rules to guarantee that email has been filtered (especially for viruses), the flow has to be updated:

  1. Apply basic whitelisting and blacklisting
  2. Accept emails from a local trusted source
  3. Reject anything else that did not go through Google Apps
  4. Process the X-Gm-Spam header (required online configuration too) and handle the spam as we see fit
  5. Accept any remaining emails

In my case, the vast majority of the email filters had to be adjusted to some degree.

Did It Hit Google Apps Email Filters?

The trick now is to determine whether an email hit Google Apps before coming to our email server. Simply checking for the X-Gm-Spam header is inadequate since that will likely become a standard extra header in hack attempts. The solution I settled on is to have Google Apps pass an access key as a header.

  1. In Google Apps, add a Receiving routing setting with a custom header.
  2. Set the custom header name and value to something random and private. On Linux, you might just type `uuidgen` to get a good string.
  3. In Icewarp (or your email program), add a filter that checks the custom header name and value. After it has been verified, have your server software remove the header so that it is not exposed to any users - this will prolong the usefulness of the access key.

This is an imperfectly secure system since there is no private key. The email header is passed in plain text through any intermediary servers. Of course, if one of those intermediaries is evil, then you are already in trouble. If there is a sudden spike in SPAM, or on a predetermined schedule, the access key header value should be changed.


  1. The official feature comparison page of Postini vs Google Apps Email
  2. Email routing is available to Google Apps for Business
  3. Approved sender lists are buried deep, but they are available
  4. Blocked sender lists are easier to find
  5. Restricting SMTP connections to Google IPs is much trickier than with Postini
  6. X-Gm-Spam provides a 0/1 spam flag, similar to the general spam score in Postini headers (almost a direct map of X-pstn-xfilter: y/n)

blog comments powered by Disqus