Noodlings

As I’ve mentioned before, Noodlesoft’s online operations are happily hosted on Slicehost. A while back, I migrated my site and databases from DreamHost to Slicehost and haven’t looked back. Ok, well, not exactly. I didn’t migrate my email hosting over. There were several reasons for this:

• Setting up and maintaining email software with all the features you want is a bit of a pain.
• I wanted redundant MX servers. Getting another slice to do that is a bit costly.
• I didn’t want email service to go down with my web site.

For the time being I left email on DreamHost. It’s a hard habit to kick. They provide tons of bandwidth and disk space for cheap. Of course, given enough time, DreamHost will disappoint you and disappoint they did. They changed the MX servers on me without notifying me. Since I have my DNS hosted elsewhere, I need to be warned ahead of time so I can do the proper DNS change. Not only that, there didn’t seem to be an overlap so mail going to the old MX was being bounced. Not acceptable. It was at this point I decided to get all my business operations off of DreamHost. It only drilled the point home when DreamHost would sporadically fail to resolve some mail aliases for a while afterwards.

What was I looking for in an email hosting provider? Several things:

1. Reliability. This is where DreamHost seems to falter time and time again. With DreamHost, not only do things seem to go wrong more often, but their handling of the situation is unprofessional.
2. Easy migration. This seems to be a bit more commonplace now. Providers now have a way where you can point their server at yours and have it suck out all the mail and folders. Even better if you can do it incrementally after the initial run to catch the extra emails that end up going to your old MX during the DNS transition.
3. Support. I expect support to be accessible, responsive, competent and diligent. This is one of those times where I want to pay. With free, you have no leverage to get them to fix a problem in a timely fashion. This is my business here and I can’t afford to have unresponsive and unhelpful support if the service goes down.
4. Features. This will be different for everyone but for me, I just need basic things like SSL for inbound (IMAP) and outbound (SMTP) and server-side rules/filtering.
5. Reasonable resource limits. Some providers limit your bandwidth (both inbound and outbound) and all put limits on disk storage. The limits should be high enough that I don’t notice them.

Google Apps is an obvious choice but frankly, I don’t like how Gmail does IMAP. In addition, I was very unimpressed with Google’s support with Google Checkout and expected the same type of thing with their other services. See point 3 above.

I decided to try FuseMail. I heard some good things about them and pre-sales support was responsive so I signed up for a trial. Unfortunately, it didn’t work out. There were some odd problems here and there but ultimately it was because of unspoken usage limits. They flagged my account when I tried to do a full IMAP sync to my desktop mail client. Their claim was that I was using too many connections and suggested I should set Apple Mail to not download all messages. They violated point 5 in my list so I cancelled my account. Also, while their support was responsive, they weren’t actually always helpful. They seemed to be oriented towards getting a response out quickly instead of actually solving my problem.

I considered FastMail. Poking around on their site, it seemed to be a good fit for features but it felt like they were trying very hard to discourage you from contacting them. Even if you have a ticket system in place, not everyone that needs to talk to you is already a customer. I was turned off by their support pages and put them on the backburner.

I then poked around the Slicehost forums seeing what other people may be using. I discovered that Slicehost has a special deal with Rackspace (who own Slicehost now). I went to their site and was able to have actually useful conversations with sales and support people. I started my trial.

The migration seemed to go smoothly, albeit a bit slower than Fusemail’s migration tool. After the migration was done, I found a problem: all the dates on my messages were set to the migration date and not the actual original date received. After contacting support, I learned that their tool was resetting the IMAP INTERNALDATE which Apple Mail uses as “Date Received” (most other clients use the sent date in the mail header). After some tests with them, they finally fixed the problem internally. They performed a special migration for me and then I pointed my DNS at Rackspace’s servers. It’s unclear to me if/when this fix will get into the main migration tool; if you are considering signing up with them, I suggest contacting their support and asking first.

The verdict: I’m quite satisfied. After the setup hump, things seem to be running smoothly plus the Rackspace servers seem noticeably faster than DreamHost. A recent DreamHost-wide outage made me feel like I jumped ship just in time. I’ll probably keep my DreamHost account around in the short term for some random personal projects (which are expendable) but I’m glad that no part of my business is hosted with them anymore.

And before I go, I thought I’d share a procedure for those looking to migrate mail servers. Unfortunately, some of these points I came up with after a screw up or two on my part but now you get to benefit from my mistakes:

1. If you are hosting DNS, turn down the TTL on your MX records. The TTL (time to live) is an indicator as to how long clients can cache this record. You want to turn it down so that when you switch to the new server, the cache won’t be stale for as long.
2. On your new server, set up all accounts.
3. On your new server, set up all aliases. Make sure they point to a valid address.
4. On your new server, if the option is available, set up a catch-all address. This address will receive emails that are addressed to non-existent mailboxes/aliases. If possible, route it to a folder or account that is not used for anything else. Even if you don’t want this on normally, turn it on now until you are sure that all mailboxes and aliases are set up properly.
5. Test locally. Check with your provider but some should shunt local mail without going to an external MX server (so you can do this before switching DNS). Make sure none of your aliases bounce.
6. Do the migration. Depending on the size of your mailboxes, this may take some time (letting it run overnight is a good idea). Make sure to verify afterwards. Remember to check those dates!
7. Update your MX records to point to the new server(s).
8. When you feel comfortable that things are working ok on the new server, do a final migration to pick up any messages that arrived during the overlap period.
9. Cancel old account.
10. Pour yourself a scotch.

Note that steps #1-9 are optional.

Update (Dec. 18, 2009): Oh the irony. A day after I posted this, Rackspace had an outage. One the email hosting side, it seemed to only affect clients connecting to access their accounts. Their mail servers were still able to accept messages during this time which was the more important thing for me. Of course, I’d prefer stuff like this not to happen and time will tell how often it does happen. In the end, it was handled well and support was very quick to answer my follow-up questions after things settled down.