Source Guru

A few months ago, my company made the decision to switch from our previous mail provider, to use Google Apps. It was a no-brainer really, most of the company were using it already, for the calendars, and Documents, and well – we were a bit fed up with our previous mail provider.

So we made the move. As an online retailer, we obviously get a lot of Financial related emails, and our Accountancy Department has an email address setup as a group, where the group sends to all the members in the Accounts Team. A pretty simple setup.

However, for the last 2 months, I’ve been fighting an uphill battle to get this to work properly. When an email gets delivered to a Google Group, it stops there, and then Google re-sends the email to the people in the group. Somehow, this triggers the receiving account to believe that it’s originated from the Google Groups servers, rather than the actual originating server.

Google Apps emails have a pretty nifty spam filtering service. For those well-known services on the web, it’ll check whether it actually came from them (I think through some combination of DKIM and SPF), and bounce it if not.

Can you see where I’m going yet?

Google Groups has a nifty feature to stop it attempting to send emails to addresses that don’t exist. If an email address bounces at a certain rate, it’ll flag it as undeliverable. If all the emails in a group are flagged as undeliverable, it’ll bounce that email to the original party, so that they know no-one received it.

The Accounts team are setup to receive information regarding Paypal Payments, Disputes, etc etc.

A couple of days in, I had our Financial controller tell us that the Accounts team had stopped receiving emails. Well, being who I am – I sent a test email out – guess what I got back?

Hello <redacted>,

*sigh* – time to play with the group. I change the members of the group to use one of our alias domains instead of the @mobilefun.co.uk – this gets emails working again.

2 days later…. our Financial Controller comes to me and complains that clients are complaining that they’re receiving bounce emails when sending to his team… I check, and once again, get the same message.

Time to open a support ticket.

That was in October… since then – we’ve tried everything… Changing to user-defined groups and switching off the spam filters, whitelisting the groups, setting up DKIM on our domain, changing the spam levels, clearing bounce statuses… all to no avail… I’ve been back and forthing with Google Enterprise Support for 2 months – and have still not found a suitable solution … *sigh*. I must say however, that the person dealing with the case at Google (Josephine H) – has been professional and helpful all the way along, even with my rising frustration at the issue.

Today I ended up calling their service unusable number, after having tried a couple of times to change the groups so that the Accounts Team could receive emails again… and finding that none of my previous tricks worked. While on hold, I found that I could use a local part extension to an email address, and the group would recognise it as a new email address – and therefore have no bounce status. I’ve now made a script using the Provisioning APIs, and a bit of python-fu that will generate a local part extension based on the current date/time, and replace the users in the group for the Accounts team with those. Say for example, the primary email address for a user was test@example.com – it’d add a user of test+20101221235641@example.com.

This is set to run each day – so it’s pretty much the same as “resetting the bounce status” (which fixes things for a short while) on a daily basis.

According to my latest email from Google Enterprise support:-

At the moment there is an incentive going on to fix this outright as messages from Paypal etc have been causing bounce’s for other domains. This fix is supposedly due very early in the New Year and will solve this problem indefinitely.

I wait with baited breath – but for now, I’m happy with my hack.