Google Apps Mail - Initial Thoughts so far...

Following on my my previous post about our migration from Rackspace Email to Google Apps Mail, here's what I've I found so far.

Labels rock!

Labels work like folders, except with Gmail - you have put multiple labels on a message and it will appear in multiple folders whilst the message itself is only stored once.

I desperately needed to have a big tidy-up of my mailbox and using the Gmail interface and using Lables, this allowed me to do this really quickly compared to attempting the same with IMAP and folders.

I created an Archives tree using the Labels like this:

• Archives
• 2010
• 2011
• 2012
• 2013
• 2014

I used the search "(after:2010/01/01 and before:2011/01/01)" to find all mail for received in 2010.  Then I clicked 'Select' and 'Select all conversations' to select every message that matched.   Then I clicked Labels and removed any other labels by making sure everything else was unticked whilst I ticked Archives/2010 and clicked 'Apply'.   Then I selected all conversations again and clicked 'Archive' to prevent them appearing in the Inbox as well.   I repeated this for each year from 2010 to 2014.

I now have a much more manageable Inbox!

Plus Addressing disappointment

As I mentioned previously - I'd come to rely quite heavily on plus addressing when we used Rackspace.   This allows you to send a message to user+detail@domain.com and the message will be delivered to the 'user' mailbox and placed in the 'detail' folder.   Very useful to keep your Inbox uncluttered.

It's also useful use plus addressing to 'tag' your sign-ups, so you can tell if a company has sold your details or had their database compromised. e.g. You could tell Amazon that your email address is 'user+amazon@domain.com'.  If you start getting lots of spam to a plus address, it's then really easy just to blacklist it completely and reject any mail sent to it.

Nearly all UNIX mailers support plus addressing (e.g. Exim, Postfix, Sendmail), unfortunately it's not available on Microsoft Exchange.

BUT.

That isn't how Google implements it.

Google simply delivers any plus addresses directly to the Inbox, no modifications, no Labels, nothing!  And no options to change that behaviour.

You have to manually create a filter which uses the search "Includes the words" and uses the deliveredto: attribute to match each plus address individually.   And to make matters worse, I found that I couldn't use this to match with a wildcard e.g. deliveredto:*+list@domain.com doesn't work, so I have to create one filter for every alias I have!

So I thought - no problem, I'll write a Google Apps Script to do it...  except there appears to be no way to run a script based on an event e.g. when a new message is received.  If anyone knows how to do this, then please comment below and let me know!

If by some remote chance someone from Google reads this, you're missing potentially great feature here!  You could at least have an option that automatically labels a message with the plus address if one is used.  e.g. user+foobar@domain.com would automatically have the Label 'foobar' and optionally Archive the message at the same time so it doesn't appear in the Inbox.

For now though, I'm using a lot of filters...

Enabling IMAP

One minor annoyance I have found is that Google does not allow IMAP access to mailboxes by default and do not provide a way to enable IMAP for all users via the Administration Interface (you can only disable it and prevent users from enabling it).

Clearly, they want you to use their Webmail interface rather than an IMAP client, but not being able to enable IMAP globally is a pain.  Each user has to go to 'Settings' in Gmail and enable it.

Migration to Rackspace Email to Google Apps Gmail

For quite some time now, we've hosted all of our company email with Rackspace Email and used our mail security software in front of it.  However we've had some annoyances with it and as we've been using Google Apps increasingly, we decided to make the switch over to Google Apps Mail and to learn about the process as we did it so we can assist our customers should they decide to make the switch.

Annoyances with Rackspace Email:

The good:

• Supports plus addressing (this allows you to send mail to email+folder@domain.com which is delivered to email@domain.com and placed in 'folder' in the mailbox, instead of in the Inbox).  This is really useful to bring some order in to your Inbox and make it for person-to-person traffic only with things like helpdesk notifications going directly to a sub-folder.

The bad:

• Not designed to have any 3rd-party spam filtering in front of it.
• You can disable some, but not all of the filtering.   This caused us some problems receiving spam/virus samples from our customers.
• Quite aggressive rate limits.   This would normally be fine, but you can't tell the service about your MXes - so you get the same limits as everyone else and that means that we were occasionally queuing inbound mail up to Rackspace from our MX which caused some delays in receiving the messages.  Not great.
• All messages from external hosts with a null return-path are silently discarded.  
• This is a particularly bad practice that I'm surprised doesn't get them a lot of complaints from their other users.
• It means that if you send a message to an invalid email address which subsequently bounces, you won't receive the bounce and you therefore think that the message was received.  Not good at all.
• This is related to the use of our own outbound SMTP servers, however this policy will still affect other Rackspace Email users should the message be bounced after delivery (e.g. if your recipient uses Microsoft Exchange which by default does not filter users not in the directory, it accepts all the SMTP recipients and bounces them on delivery).

The Migration

Rackspace Email uses IMAP, so I decided to use the Google Apps Data Migration Service.

My first mistake was not to radically tidy-up my mailbox and archive old stuff first.  The result was that it took >4 days to migrate 1.8Gb of work email to Gmail.   Either this was because of Rackspace rate limiting, or because the migration tool and API is slow, I'm not really sure.  Increasing the migration speed in the tool made no difference at all.

My second mistake was not to start delivering all new mail to both Rackspace and Google at the same time whilst the migrations were being done.   There are various ways to achieve this but as we were alpha testing our new DefenderMX software on our MXes - it was as easy as adding a Map rule:

Key	Sub-key	Value
to:fsl.com	bcc	$1@fsl.com.test-google-a.com

What this does is match any message with an SMTP recipient ending @fsl.com and will automatically add an additional SMTP recipient of $1@fsl.com.test-google-a.com where $1 is the what appears on the left-hand side of the @ in the address.  e.g. testuser@fsl.com would cause testuser@fsl.com.test-google-a.com to be added as an additional recipient which allows me to deliver mail for our domain to both Rackspace and Google at the same time.

The <domain name>.test-google-a.com sub-domain is automatically created by Google for all Apps domains when they are initially created specifically for purposes like this.   You can deactivate it at any time via the Apps administrator.

Before I added this rule I had to make sure that all email addresses that are valid on our Rackspace account were valid on Google, otherwise a message to an email address that didn't exist on Google would have caused the sender to receive a bounce message saying that their message couldn't be delivered to the added recipient.

I had two colleagues that used Microsoft Outlook, so we used the Google Apps Sync for Microsoft Outlook tool to migrate their mail which was much faster than using the Data Migration Service.

I'll post a follow-up on our experience with Google Apps Mail once we've spent a few days on it.