Rationalising email: Gmail, IMAP and Mail.app

The current setup

Over the years, I’ve accumulated a lot of email addresses… and a proportionately large amount of spam to go with them.

For the past five or so years, my mail processing system has looked like this:

1. Linux server running fetchmail which fetches from a total of… um… 8 (!)POP3 accounts.
2. All mail run through SpamAssassin which catches probably 90% of the junk, and scripts run every month that clear down and learn from the spam.
3. SquirrelMail on the same server to provide web access.
4. Dovecot IMAP on the same server to let me manage the aggregated mail from Thunderbird on various laptops at home.

This has worked well, but it has also meant that I’ve had to maintain a Linux server at home, and I’ve not opened up IMAP access to it over the Internet. So, with Google’s announcement of IMAP support in Gmail, I thought I’d give it another go.

How am I using Gmail now?

It took about a week for Gmail IMAP to appear on my account, as those who followed my increasingly–frustrated Twitterings will confirm.

It’s a progressive process, but I’ve decided to try to use Gmail’s ability to suck mail from my other accounts. The problem is that I have 7 of them (the eighth is Gmail itself), and Gmail will only let me pull down mail from 5. That actually turns out to be OK, since a couple of them were essentially unused or spam-only accounts, so I’m cutting down on those too.

Using Gmail as the front-end to all of my mail is good for a couple of reasons, and bad for another:

Good – I will eventually be able to decommission the Linux server.

Good – Gmail has good spam filtering, labels and all that good stuff around search, and is mostly accessible.

Bad – it isn’t accessible from everywhere, and my last client actually blocked access to Gmail explicitly, whilst I could still get to my home server very easily. I think this is likely to be the greatest annoyance.

I was pleasantly surprised with how easy it was to configure Gmail to pull my other POP3 accounts… generally I only had to name the provider and my account details, not enter all of the server information manually. Good stuff.

Changing mail clients

I was listening to the MacFormat weekly podcast the other day and discovered that the new version of Apple’s Mail.app has some very interesting features. Amongst them are some very cool data scraping capabilities (called Data Detectors) that allow todos, addresses and iCal entries to be intelligently created from analysis of the message body. Here’s an example, featuring Roo’s IET lecture next week:-)

[viddler id=d4b3d273&h=437&w=370]

My default mail client up until now on the MacBook Pro has been Thunderbird, but that has been largely a matter of familiarity… I decided that it was time to give the Apple alternative a try.

So far, it has been an intriguing experience. I can’t say I’ve found Mail to be the most intuitive application. For a start, configuration for Gmail IMAP was not very easy (here is some useful additional information that wasn’t on the Gmail FAQ). Not only that, but in Thunderbird and Gmail, I’m used to hitting a key for the next unread email, but Mail inexplicably doesn’t allow this. Two solutions:

1. An Applescript that causes Mail.app to jump to the next unread. I used Quicksilver to bind this to Option-` and it now pops up Mail and switches to the relevant Space as well as moving to the right message.
2. Probably an even simpler option, that Andrew Webb suggested via Twitter: a Smart Folder which only shows the Unread messages.

Now that I’m getting used to it, I’m quite liking Mail… particularly the ability to jump straight into Quick Look to view images and documents.

Trials and tribulations will be reported as the experiment continues.

Technorati tags: Gmail, IMAP, Google, Apple Mail, Mail.app, Thunderbird, SpamAssassin, SquirrelMail, email