== Evolving our mail system: the overview and our goals Way back in the beginning of time, or at least when I arrived [[here http://www.cs.toronto.edu/]], we had a rather [[old mail system configuration OldMailerConfiguration]] that was very much an artifact of its time. In other words, it desperately needed to be modernized and replaced. And replace it we did, winding up with [[our current mail system CurrentMailerConfiguration]]. There are two ways to describe how we planned the migration from the old system to the new one. Let me write up the nice one first: There are at least two possible approaches you can take in a migration like this; you can go for a big bang migration, where one day you yank out the old system and drop in the new one, or you can migrate from the old system to the new one incrementally, replacing bits and pieces of the old system until it's been completely eliminated. After considering the issues, we decided to take an incremental approach to our upgrades. (This is not a straightforward decision in general. An incremental upgrade is more work and more complexity than a big bang upgrade; you'll probably need to build a number of intermediate pieces that you'll throw away later, and you have to figure out how to wedge your new pieces into the old system with as few changes as possible.) There were several advantages to the incremental approach for us. One is that it would let us start improving things for our users almost immediately, instead of forcing them to wait until we had completely designed, implemented, and tested all of the new mail system; since our users were unhappy with our mail system, this was quite important. Another was that a series of incremental upgrades struck us as a less risky way to tackle changing a mail system that no one really understood any more, because we'd only have to understand a limited area and get it correct for each change. This set our overall goal and our approach: we wanted to completely migrate our mail system to a new and modernized design while having the users notice as little as possible. This dictated a fundamental approach of basically nibbling around the edges of the old system to steal bits of functionality from it without it noticing; the plan was that over time, the old system would handle less and less mail and pieces of the new one would handle more and more. (Since the change involved an operating system and CPU architecture change (from Solaris 8 on SPARC to Linux on x86), users that ran programs from their _.forward_s would have to take action, but we didn't want other users to have to care about the changes.) All right, that was the nice, orderly description. The *honest* description is that we decided on this approach (and planned out how to steal bits of functionality from the old mail system) only after we had made our first major change. While the first change did fit in with the plan, it was made for other reasons; we were in a state where we had to do something to improve several aspects of the mail system and make our users happier with it, so we made the quickest, easiest fix that we could by introducing [[some spam filtering ../spam/CSLabSpamFiltering]]. (At that it was not entirely quick or easy, but that's because it involved building a bunch of infrastructure.)