A Roadmap for Email @ Wesleyan
Jun. 25, 2008 by ravishan
Over the years that I have been here, I have participated in several E-mail transitions both in the front end as well as back end. I can assure you that given the complexity of E-mail systems, we have done extremely well and we have always done things that have been leading edge and very creative and out of the box. However, the system has gotten too complicated and harder to maintain (I am sure there are varied opinions on how hard!). I want to make it absolutely clear that this is not a criticism of anyone. The reason for this is the evolutionary path we took over the years and the fact that handling email has gotten extremely complex in recent years. We need to develop a plan that simplifies the E-mail operation. Here is a proposal and I would like to hear opinion on this.
Currently, we have E-mail accounts for faculty, staff, current undergraduate students, all undergraduate students who graduated after 2001, current graduate and GLSP students, Emeriti faculty, retired staff, alumni who graduated prior to 2001, and many “guest” accounts. All administrative staff and a few faculty members have their mailboxes managed by Exchange and all others are on Unix servers and accessed using POP or IMAP protocols. Many of our email users also forward their emails elsewhere. Incoming emails pass through intermediate software for virus scanning and spam processing. This is a very simplified view of the Email world at Wesleyan.
The ever increasing SPAM, phishing attacks, the appetite for increased space for storing emails on the server are all putting a lot of stress on our systems. Sudden increases in SPAM routinely delay the delivery of emails causing disruptions to many of our users; carefully formatted phishing emails are trusted by users who share their passwords with unknown hackers who then use it to attack our systems or worse, get access to the data belonging to the users; increased storage means increased backup times and backup storage; increased mailbox sizes means slower mail performance (this is relevant only to certain technologies we use). And we tend to be very reactive to many of these issues – someone reports a delay in email, then we go look in the complex maze of backend to locate where the problem could be and then fix it. We do a great job in all of this, but it is typically too late.
So, I propose a major overhaul of the way we deal with email. The goal here is simplicity.
- Outsource all email handling for faculty and staff prior to their arrival on our system to Google/Postini (You can read about an offering from Google here). Refer to the middle column called Message security. It is not free, but ignore the number you see in this page. Google/Potini combination is what is used for GMail and it is very powerful and they know this business as well as anyone else. Also, given that over 90% of email is typically rejected either because they are SPAM or phishing attacks, we will save a lot of bandwidth (which will be balanced by some of the proposals below). This system scans for messages in memory, and service level agreements assure that there are no data mining happens on the email (to be carefully read by the General Counsel). However, all files that are quarantined are saved on their servers.
- Move all student email to Google Apps for Education. As mentioned in my previous post, several colleges in our space have already done it and many more large institutions have done it. WSA conducted a survey of students in 2007 and the results indicated that the students would favor such a move. Due to lack of resources we were not able to follow up. By doing this, students will still retain user@wesleyan.edu email address, no ads while reading email, will get access to calendar and Google Docs, 6.5 GB of email storage. All of this for free and we will implement the single sign on, so they can use Wesleyan password to access their email. Upon graduation, students will begin seeing the ads on the right.
- Propose to UR to move all the alumni accounts over to Google Apps for Education as well.
- Move all accounts other than the faculty email accounts also to Google Apps.
- Move all faculty emails to Exchange servers. However, this will be transparent to the end users and they do not have to change their clients to outlook for this to work.
At the end of this, we would have basically outsourced all emails except for the faculty and staff over to Google Apps (pending UR accepting to move Alumni email over to Google). All faculty and staff email will be managed through Exchange servers.
Obviously, getting to something like this is not trivial and will take time. The good news is, several others have done it and some in record time. They are willing to help us. For example, the single sign on code for Google Apps that ties into LDAP is widely available now, unlike before.
Just like all technologies, this has its risks. For example, when the network is down for any reason, email access is affected. It is true that when the network is down, our internal email will also be affected (but not in the same way). Based on past experience, our network has been up a fair amount. It is also the case that we need to make sure to implement all of this in a way to cause least disruption for the end users. That is the name of the game. As I said, we have other institutions who have done this before and are willing to talk to us and help us.
