7/17/07-Next steps/plan

1. Migrate Active users starting July 31
2. Migrate all accounts attached to class of 1997 & forward
3. Archive all other accounts and shut down alumni email server

• Need a script to hijack the wesnet signup and put accounts into Active Directory (soon)
• Need a script for the wesnet signup that will create a mailbox for anyone who signs up that does not already have one (later)

We've been tracking alumni email users since 2/12/07.

These numbers represent alumni email users, with a class year prior to 2005.

• Since then, we have 3918 alumni who have checked their email.

• In the past 60 days 2650 alumni have checked their email.

• In the past 30 days 2184 alumni have checked their email.

• In the past 7 days 1562 alumni have checked their email.

• Yesterday 1087 alumni checked their email.

jjylkka - history

Students who graduated 1997 forward, kept their email accounts 2003 we generated email accounts for all alumni who did not already have one (@alumni.wesleyan.edu) 2005 forward are in active directory

2/8/07 jjylkka Some stats:

• Between people who have signed up for WesNet, and people who have logged into their email account(they do not have to go through WesNet to look at their mail), that number is approximately 9200.
• 4100 of those people are forwarding their email to another address.
• Since 1/19/2007 there have been 23,011 checks of alumni email (single count by user by day). That number represents 2,245 alumns from the classes of 1937-2006

—-

Matt here - please fill this in as best you can, I don't want to dominate what's written here because I admit to having more of a personal investment in this (what with the whole pesky alumni thing) and opinions which are those of an extreme minority. As an example of my insanity, I don't consider Gmail to be useful email service to me at all – I see it more as an amusing toy.

And actually, we should probably reorganize this thing, as well.

The UID matching for alumni accounts is happening now as part of a general AD fix-me-up, my recommended rough path is as follows:

1. UID/GID matching
2. Make sure password changes happen only through us and that our scripts synch AD as well (the scripts do, as far as I know)
3. Shift @alumni.wesleyan.edu → @wesleyan.edu. We cannot support both at once without considerable work, however.
4. Force password change.
5. Migrate to Cyrus if Crippled Pine Not Problem.

This needs to be filled in, but here's what I see the major problems are:

• Performance of email (webmail in particular)
• Maintenance/support of email (harder to support, machinery getting worse, @alumni/@wesleyan confusion, different email system alltogether, alumni accounts are not in our central authentication directory, etc)
  • Some of this results in spam filtering not functioning for alumni, performance woes, and a number of other negatives.
• Costs associated with lifetime email vs. benefits gained - is it worth to keep email as it is?
• Changes in student email is resulting in possible rougher path to migration to alumni mail.

Here's basically a list of what I see as some of the popular options discussed with positive/negatives put in. Obviously a mixture of some of them is a possibility, as well as making some optional or contingent on other factors.

3/7/2007–We met today and decided to follow this plan:

Move all alumni to Cyrus and give them the 100mgs that students currently get.
There will be some alumni (after 2008 graduating class) that will have gmail, because that became gmail users while at Wesleyan.
We will follow the instructions noted in Phase2: Force alumni resets below.
Matt will work with Jane to make sure this can all be done
James will talk to Ravi about the plan and it's monetary impact
Adrian will work with Jane for the strategy to inform the alumni of the changes
Mark will work with Jane on outlining the policies

5/10/2007

 Jane will build a table so that Matt can log everyone's who changing their passwords
 Adrian will work on the communication that will go to users
 Matt will work on the portfolio app that will move the users to Cyrus
 We are concentrating on the people who we know are currently using email
 Matt will also work on a way to 'hijack' the users that are currently logging into portfolio, to get them off the alumni email server

Jane suggests a breakdown of this further.

The positives of this system seem to be:

• Keeps basically what we have now, just with acceptable performance/scalability.
• Same amount of control as we exert now.
• Full featured email service.
• Brings alumni in line with student mail system, as opposed to being odd man out.

The negatives seem to be:

• The hardware (specifically storage) is not free, and requirements always rise.
• There are support costs associated with offering this service.
• Even in a best case, takes resources that may not be worth the benefit. Looking like 30k for overestimated startup, additional costs of ~$2500-$5000 a year as students graduate assuming increase of quota to 200MB; reducing quota would significantly reduces costs.

I'm going to pretend this is only GMAIL until someone gives me the name of someone else we're working with.

The positives:

• Gmail is a known, popular entity for people's email.
• Eliminates most of our support costs.
• Requires less resources from us.
• Larger quota.

The negatives:

• Not full featured mail service - though arguably enough for most people.
• Complicates support needs probably.
• a gmail account may not have any particular value (one current student was like - err.. what's the point of that? I already have two gmail accounts)
• No known solution for POP authentication (mentioned only because a significant percentage seemed to use POP).
• Privacy concerns?
• Getting mail off…
• Presence of advertisements.
• Loss of control.

Positives:

• Minimal resources
  • Spam filtering - yes? No? - this adds costs.
• The @wesleyan.edu is more valuable than the email service in most cases.

Negatives:

• No longer would be “lifetime email” arguably.
• Least control of the options.

?(jjylkka)

 How do we enforce this, and how does it impact portfolio login?

• Right now portfolio login basically works as per the following.
  1. If the user is in AD, authenticate via AD.
  2. Else, go to the mail server for authentication.

Thus, once they are in AD, we don't need the mailserver for anything portfolio related. For all current members of Wesleyan, the mailserver's only necessary if you've got an email account and are receiving email. — Matthew Elson 2007/01/22 10:56

• To enforce it, we simply don't create mailboxes/accounts and/or don't route mail to anywhere.

Let's take a hypothetical jwhedon@wesleyan.edu - until he forwards, attempts to send to this address result in a “user not found”. After graduation, we simply delete student mailboxes off the bat and/or stop delivering mail If they setup forwarding, it becomes a valid email which gets pushed off to wherever they choose, but otherwise, it's simply an invalid address. Again, existing accounts would have to be grandfathered in or deleted. It's puzzling, because I can't think of any technical reason whey an email address would *have* to be given to alumni, even under the old system!— Matthew Elson 2007/01/22 10:56

This more or less is required for smooth functioning, no matter what system we turn to. The necessary steps are:

1. Fill AD with information to make accounts “whole” and make sure accounts exist!
2. Hijack password mechanisms to change password in AD and the local email server now
   • This will require an enforced password change at some point.
   • After this is done, we can eventually deprecate the local password without interfering with the user's experience.
3. Disable password mechanisms we can't hijack so that they have to go through our systems.
   • Disable passwd on Unix machines, poppassd if it's running, attempts to change password through Windows interface (? may not be necessary)

This will be a place to jot down what data we've gathered together to help provide the relevant people with the information they need.

Really hard to find something that's one to one, but here's some that are somewhat close to what we currently offer in functionality (in Cyrus at laest):

• FastMail - Pricing Comparison
  • They use Cyrus as well (though with more custom patches for speed), but similar performance
  • There's a great more they offer - filespace, larger quotas, additional aliases, etc..
  • I'd say what Cyrus offers would be roughly between their member and full, leaning more towards full though still below that.
  • We'd probably fall at ~$15/year assuming their pricing schemes.
  • I've heard nothing but good things about them (to be fair, there's a bias).

• BlueBottle - Pricing List
  • Not sure of its underlying architecture unfortunately
  • We seem to be between Premium and Access ($10 - $25/year)

More will be added, but by my rough assessment, the going rate of IMAP/Webmail/SSH/POP3 access of the storage/support/like we would provide would probably be ~$10-$15 a year. Might be worth looking to see what Yale charges for their email addresses (apparently they do this?) for a point of comparison too; the fact of the matter is these places make their business selling email and can offer them at exceedingly low prices; looking at a fellow educational institution might be helpful.

Just some rough data so far.

Keep in mind that an alumni can use both POP and Webmail, which is why some numbers may not total s planned. This is ignoring '05,'06, and special case alumni who are on a server called “facstaff”. Adding those in is possible, but it becomes more difficult.

Based on the preliminary data, it would seem that the Webmail & POP are the primary ways alumni access their mail ¹⁾. This is not so coincidentally what Gmail offers (note: POP implementation does not behave the way most do, but I suspect this affects only a small percentage of users) as well as other free services.

The hope is to have much more sophisticated data soon (so cross reference this with specific class years, etc - I can get IPs for all usage except webmail - if we want this, I can get it, but I need to know now to add the appropriate plugin to webmail).

1. Phase 1 Step 3 (Matt)
2. Phase 1 Step 4 (Matt)
3. Phase 2 Step 1 (Matt with Mary)
4. Phase 2 Step 2 (Matt will look into this and execute if feasible)

1. Create script that disables specified accounts
2. Modify password reset script so that it has the logic to reenable accounts
3. Test new scripts with test accounts
4. Get list of inactive users from Jane and execute disable script
5. For a subcategory of inactive users (probably pre 1997 and over quota), also archive data

1. Make sure an AD account exists for all alumni. Audit UID/GID values
2. Configure password change script to synch local and AD passwords
3. Require (in stages) alumni to change passwords, thereby synching all active alumni accounts with AD
4. Implement script that will lock out local and AD accounts after alotted time
5. Disable accounts of alumni who do not change passwords within alotted time (disable needs to be modified to handle local and AD account)

1. MISC:
   1. Need to make sure that Pine does not allow users to change their passwords
   2. Password reset is working, it does not need to be addressed
   3. @alumni.wesleyan.edu accounts need to be able to be accessed with @wesleyan.edu

 5/18/2006
    Matt, James, Dave C., and Jane discussed a new approach
    Dave C. is leaving Wesleyan, so we are not sure of the timing to complete phase 2
    We thought that we could still disable the accounts.  But we would migrate the AD accounts over to Cyrus and
    leave the non-AD accounts on solaris.  In a few months when things have settled out with Dave's replacement, 
    we could complete phase 2, and get everyone on AD.

Detailed steps to come.