Google Apps – Panacea or Headache?

The email on ebrahim.org is currently hosted on pair Networks, a great webhost, but one whose email solutions are lacking in flexibility. I want to move to a solution where I can sync Email/Contacts/Calendar over multiple devices, for a domain with 7 mailboxes.

I’m considering two options:

Rackspace
Pros: Has all the features I’d ever need, excellent support, even for small customers.
Cons: Relatively small quota, and completely out of budget (at least US$13/user/month), email migration into Rackspace is difficult for large datasets.

As Rackspace is out of budget, I didn’t really spend much time looking into it in too much detail.

Google Apps Premier
Pros: Within budget (US$50/user/year), wide ranging feature set.
Cons: Technical support lacking (mainly DIY), doesn’t care about small customers, only compatible with old software, and import into Google Apps is a nightmare scenario due to lack of compatibility of migration tools.

However, there are significant issues which block my migration to Google Apps at the moment, most of which are shocking, given Google’s desire to capture the enterprise messaging/collaboration market.

Let’s make a list of missing features:

  • Google Apps Sync does not support Outlook 2010
  • Google Apps Migration for Microsoft Outlook does not support Outlook 2010
  • Google Apps Migration for Microsoft Outlook does not support Windows 7
  • There is no supported way to import a mbox format mailbox into Google Apps (there is a workaround where you can use third-party software to import the mbox into Outlook, and then use the Google Apps Migration for Microsoft Outlook, but then the Google migration tool doesn’t support Windows 7 or Outlook 2010, so you’re back to square one)

Sales of Windows 7 began in October 2009, and Office 2010 was made available to volume licensing customers in April 2010. When everybody else already supports Windows 7/Outlook 2010, Google lags far behind and lose all credibility when they claim they are the best solution for enterprise customers.

Enterprise customers rely on predictability, but yet, when asked for a timeline for when the above configurations will be supported, Google replied “we do not have a release date as yet”.

I’m ready to spend money with Google, if only they’d deliver support for modern software. A year in the software world is an eternity, and for Google to not support Windows 7 is akin to a wannabe top-tier airport telling pilots to land using VFR because they’ve not installed an ILS yet.

Mailing Lists and Email Deliverability

I subscribe to a number of moderated lists, and one of the poor practices that I see is untimely moderation of email. When list messages are not moderated quickly, there are two major pitfalls that end users can experience of which many list moderators may not even be aware.

The first of these is that most users sort their mailboxes by the Date: header, not the date that the message was received at the user’s inbox. This means that messages which are a few days old and have just been let through the moderation queue may show up a couple of pages above the newest messages in the user’s email client or webmail. This means that if a message that is 3 days old is approved, it shows up near other messages that are 3 days old that have already been read, not near the most recent messages. It is very easy to miss these messages and not read them, especially if the user’ unread mail count is consistently greater than zero.

Second, and perhaps more significantly, if the Date: header on mail is significantly (usually 24 hours or more) older than the current time, this can actually affect deliverability of email because spam filters use the difference between the Date: header and the current time as a criteria to evaluate the likelihood that a message is spam. A common characteristic of spam messages is that the Date: header is incorrect. Here is a real world example:

X-Spam-Status: No, hits=2.3 required=3.5 tests=DATE_IN_PAST_96_XX autolearn=disabled version=3.002004

The above message was moderated more than 4 days after it was sent into the queue, and you can see that SpamAssassin gave it a score of 2.3 (out of a required 3.5 to categorise as spam). Another single rule triggered could have caused the message to get sent to the spam folder. Here’s an example of where that happened:

X-Spam-Status: Yes, hits=4.4 required=3.5 tests=DATE_IN_PAST_96_XX,HTML_IMAGE_ONLY_32,HTML_IMAGE_RATIO_06,HTML_MESSAGE,HTML_TAG_BALANCE_BODY autolearn=disabled version=3.002004

Had this message been moderated quickly, it would not have incurred a point score of 2.3 for being so old, and would have been below the threshold of 3.5 required to classify it as spam.

In short, the lesson to mailing list administrators is that it is crucial to moderate messages in a timely manner so that users can easily notice the mail, and also so that the mail actually gets delivered to an inbox rather than to a spam folder.