In 2005, we decided to bring email in-house. Prior to that, our email was handled by our ITC, a consortium of school districts that provides many technology services like student records, fiscal services, library automation, and Internet access to its member schools. But they were ill-equipped at the time to handle email. Accounts and settings were confusing and inconsistent, there was no usable webmail system, and with a POP-only service, mobility was a problem.

When we were talking about setting up our own system, our network consultant commented, “you know, you’re going to need another person to manage this.” I knew. But I also knew I wasn’t going to get another person. We’d just have to make it work with the resources we had. It’s just email. It’s been around for 30 years. How hard could it be?

Five years later, we have a much better answer to that question. Email falls somewhere between oxygen and water on the basic needs hierarchy of a school. If there’s a problem with the mail server, it rarely takes more than a couple minutes before everyone knows it. If an email outage lasts longer than a few minutes, the incoming messages really start to pile up, and it can take days for the server to catch up.  Scanning for viruses and spam takes a lot of processing resources, and we had to move those functions onto a different server to keep them from overloading the mail server. With more than 90% of incoming messages being classified as spam, we’re sorting through a lot of chaff to get to the few kernels of wheat.

The biggest headache, though, comes from traffic spikes. A well-meaning staff member might send a 10 MB attachment to 500 users, for example. That’s 5 GB of data that has to be processed. Or, sometimes we’ll be flooded by hundreds of connections from spammers performing dictionary attacks against our domain. “No, you don’t have an account called ‘aaa@bbhcsd.org’? Well, then, how about ‘aaB@bbhcsd.org’?” Invariably, these types of things lead to service slowdowns and interruptions, annoyed users, and grumpy tech staff.

This spring, it became clear that something needs to be done. It’s doubtful that we’d be able to get through another year without significant upgrades to our email infrastructure. The growth in email volume alone, which has quadrupled to 20,000 messages a day since we switched to our own server, means we need to replace our mail server. And with that, we need faster, more robust solutions for anti-spam and anti-virus scanning, email archiving, and backups. To add to all of this, we really need to start providing email accounts to students, so they can collaborate with one another using tools like Google Docs. To provide email accounts to all 5-12th graders, we’d be increasing the number of accounts we’re managing five-fold. I don’t have the resources — either hardware or human — to do that.

Wait.

Google.

What was that about Google?

Google will handle our email for us. For free. Through the Google Apps for Education program, they’ll give us as many accounts as we want. We can have 7 gb of email storage space per user. Since I’m looking at about 3500 users, that’s more than 25 TB of data storage, just for email. Plus, we get Google’s spam and virus filtering technologies (which are among the best I’ve seen). Our webmail client (which is currently the functional but none-too-sexy Squirrelmail) becomes Gmail. If we want to (and we do), we can even enable IMAP access, so our staff members can continue to use the same email program they’ve used all along. So from their perspective, very little has to change. And with the API tools, creating and managing accounts can all be tied into our existing user management tools.

If only they did email archiving.

Our first thought was to continue to archive email ourselves. After all, how hard can it be? Basically, we’re talking about saving a copy of every email message. The archive goes on its own server, separated from the rest of the network, over in a dark corner of the data center. It quietly saves all of the data, just waiting for us to need it.

But that means that all email must flow through the archive. So the workflow would look something like this:

1. A staff member composes an email and sends it to another staff member.
2. The message goes to Google, because that’s where the sender’s account is.
3. The message gets forwarded to the archive server, so it can be logged as sent mail.
4. The message is sent out by our local server.
5. The message goes to Google, because that’s where the recipient’s account is.
6. A copy of the message gets forwarded to the archive server, so it can be logged as received mail.
7. The message is delivered to the recipient’s inbox.
8. The recipient’s computer connects to Google to retrieve the message from the inbox.

So that message goes across our Internet connection five times. Plus, we have to maintain our own server to archive it. And, we have to have our own server to send out email, effectively funneling all of our mail through our own mail server. Additionally, we have to have backups of all of this. And there’s no guarantee that all incoming email would be archived. In the event of a problem with our server, the message would still get delivered to the recipient’s Google account, even though it hasn’t been archived yet.

Enter Postini. Google will do the archiving for us. This service isn’t free, but considering the benefits, it’s worth the money. The email’s not bouncing around from server to server. It’s being archived off-site. They’ll keep each message for up to ten years (we only require five). And I don’t have to have any mail servers. Sign me up.

There have been few technology “no-brainer” decisions. I remember finding out in 1996 that we could get Internet access from our cable company at 5 mbps for $5 less per month than a dialup account and dedicated phone line. That was a no-brainer. I also remember finding out in 2005 that we could transfer our home phone number to a cell phone for $5 per month instead of the $20 we were paying, and get free long distance. That was a no-brainer.

This is another one of those situations.