This is the nearly incredible story of how one of Canada’s great universities has become such a buttress of the Microsoft monopoly that it cannot even provide for a new faculty member the normal ability to send and receive email.
I will shortly arrive as a new faculty member at McGill University. In academia, email is still a primary form of communication and collaboration. I feel that a university email address is part of my professional face in representing the university. Nevertheless, I don’t demand much from the university in the way of email support.
In fact, all I want is
- to be able to receive email, in a timely and reliable manner, sent to my university email address
- to be able to send email through a university server, so that I appear to my email recipients to be sending email from my university
I don’t even need the university to store my email or do anything else. There is lots of software and many commercial services that can handle the details well. There are open, globally-accepted standards for how those software and services talk to each other that make this all easy.
Here is the central, bizarre policy that has stumped me in choosing from McGill’s options:
Unless I choose and am able to interface with a Microsoft Exchange server for getting my mail (receiving), I am not allowed to use McGill’s secure SMTP server (sending). This is absurd, since these services should be totally separate, but presumably Microsoft has a hand in setting things up to frustrate all users of other software, other operating systems, and other email services, ie who want their mail forwarded (e.g. to GMail) but still want to have their outgoing mail look like it is coming from the more professional-looking mcgill.ca server.
McGill offers an option to have one’s mail forwarded directly to some other off-campus email address. However, if you choose that, they actually delete (any existing mail and settings you have on their server, plus) your credentials that allow you to use smtp.mcgill.ca, their secure server that can send mail. Thus, if you want to read your mail on GMail, you may not send mail from McGill. You can always have your client, including GMail, set your “From” address to your McGill address, but it will still look to recipients as though it came from Google and it will reveal to them your GMail username. (You may not care, but I do; I’d like to send my mail from my university and I’d like to keep my GMail username hidden.)
If you want to keep the credentials which allow you to use McGill’s secure SMTP server for your outgoing mail, the IT department suggests another way to get your mail out from the clutches of Microsoft Exchange. They have instructions (currently at http://kb.mcgill.ca/kb/article?ArticleId=1139&source=Article&c=12&cid=2) that are entirely incomplete in (a) context; they fail to tell you that there is a major downfall of this method, (b) meta-knowledge: they don’t tell you that you need a very recent version of Microsoft IE for the task to be possible at all, or for the instructions to resemble what one will see in reality, and (c) content: they describe only half of what needs to be done. This is characteristic of McGill IT’s documentation, and I find it rather hard to comprehend how such a poor standard could be in force. In addition, two months after I mentioned some of these problems, nothing has changed.
So, the method that should be described at that link is to create inbox rules in one’s Exchange account which (1) forward out any incoming mail, and (2) delete any incoming mail. You need two rules, not just one as described in the instructions, otherwise the mail will all pile up in the Exchange Server account, and it will eventually stop working due to a quota limit. In fact, even if you implement two rules, the messages just get moved to the “Trash”, which needs regular emptying, otherwise the same quota limit will lead to a loss of all incoming email to one’s professional account as, say, faculty at McGill. Incroyable? Presque.
Were I to pursue this absurd kludge as my permanent solution for email at McGill, the good news is that as a GNU/Linux user, my non-IE browser can in fact empty the Trash in the Exchange account online interface, even though it cannot set up the rules described above.
There is one other option I came up with for people who want their mail in GMail. You can have GMail use the POP3 protocol to grab (and remove) mail from McGill’s Microsoft Exchange server. However, it only does this once in a while, with a frequency (e.g. every 30 minutes) of its own choosing, so if you want to read mail when it comes in, or within a reliable amount of time of its arrival, this is no use either.
So what am I to do? I don’t trust Microsoft Exchange and its regular “upgrades” to work reliably (see below for an example of bugs in it described to me already by McGill IT), and I do not want to lose important messages just for forgetting to log on once in a while to empty the Trash in a system I never otherwise visit.
Solution number one: Combining the methods above, I can avoid having to visit the Microsoft Exchange website ever again by (1) removing the “delete” rule described above, and (2) setting up some daemon somewhere to grab and delete mail from the Exchange box. For instance, in GMail, in the POP3 import settings (under “accounts and imports” in “Mail settings”), take the option to label incoming messages from the Exchange server. So I have them labeled as “delete-mcgill-exchange”. Then set up a separate filter that permanently deletes all messages with that label.
Update: This solution fails on two counts: (a) Using the “forwarding” filter option on the Exchange server has a terrible flaw: if you receive a large file (>20 MB?), Exchange refuses to forward it. Yes, it accepts the message, but refuses to obey the forwarding filter. It does issue an email message to you to tell you that a message cannot be forwarded. But that message does not, itself, get forwarded!! That’s right, Microsoft’s Exchange server fails to send on its own warning that it’s not sending on your incoming message. (b) The POP3 trick I devised, above, to delete messages from the server does not work. The messages just end up in the “trash” folder in the Exchange account, and therefore count towards your quota.
The problems don’t stop there. Even if you decide to trust Microsoft Exchange and are willing to log on periodically to empty your Trash, McGill’s secure SMTP server does not support the age-old, open standards that the Internet is built on. As a result, many email clients, including mine, cannot use it even if their users have jumped through the hoops above in order to retain their login credentials for the Microsoft Exchange system.
This is truly ghastly. To quote a McGill IT support person from my endless email exchanges with them before arriving here:
We guarantee that [smtp.mcgill.ca] will work on Outlook 2003 and higher, Mac Mail 4.2 (and higher), Entourage 2008 (Web Services Edition), Outlook 2011 for Mac and some version of Outlook express. This configuration will not work on many of the other email clients that is not listed, believe me I have tried.
(Recall from above that there is absolutely no reason, except Microsoft’s malice, for access to the SMTP server to be tied to usage of the Exchange account! The username and password for both are the same as everywhere else in the McGill online faculty/staff system, yet things are rigged so that if you don’t choose to have an Exchange account your ID will not be recognized by the SMTP server. The problem above is in addition to that one: a presumably-Microsoft implementation of an SMTP server is rigged only to work with select clients.)
Solution number two: Run your own SMTP server and just use the direct forwarding (bypassing Exchange altogether) option for your mcgill email address. There are many people on campus who use better software than what McGill is wedded to. One reason that there is not stronger pressure for reform is likely that the departments where many of these people reside — where people know about more options or have less tolerance for bad software (CS, physics, …) — tend to have already shielded themselves from McGill IT by hiring full-time IT administrators of their own and running their own servers. That is, they give their faculty the ability to send mail that truly originates from a mcgill.ca subdomain by running their own SMTP server, since the University’s server is tied to Microsoft and its buggy and restrictive server. Clearly, both my “solutions”, and especially this one, are fairly intricate if not drastic.
I’m sad to report that this bumbling marriage to, and manipulation by, Microsoft, along with a low quality of available information about what is and isn’t supported, characterises my new employer’s infrastructure at every turn that I’ve seen so far. For instance, consider the campus-wide system for administration of all course material, assignments, grades, etc that most professors and their students are to use. It only works with a narrow set of browsers, and primarily on Microsoft Internet Explorer under Windows. Indeed, this fact wasn’t even mentioned (until brought up in questions) in a presentation for this year’s new faculty hires. In the same presentation, a demonstration of the campus-wide system for classroom “clickers” (an instant student response transceiver system for lecture halls), which apparently work (only??) through integration with Microsoft Powerpoint, failed when Powerpoint repeatedly crashed every time the clickers were activated.
In my experience at five major universities, this one has by far the most ignorance of diversity in computing software, lack of adherence to internationally accepted open standards, and — worst of all — a lack of meta-knowledge and accuracy in its documentation. By meta-knowledge, I mean that there is no awareness or explicit specification of the limits of IT support. Instructions for setting things up do not mention that you need to be using a particular subset of (Microsoft) operating systems. Similarly, support staff have not asked whether I’m using a Microsoft, Macintosh, or other system before launching into instructions by phone.
As arriving faculty I was kindly contacted by the IT department and offered a personal visit in my department for some set-up support for any computing needs I might have. When it came up that, like countless others on campus and around the world, I was using GNU/Linux as my operating system, the offer of help dissolved and the visit was cancelled.
I’m thrilled about McGill overall, but so far the quality of the IT culture on campus seems to have only one direction it can move: away from its bondage to the standards-destroying, cost-externalizing monopoly of Microsoft.
Update: 2012 February. Ryan Ortiz and Brian Arsenault, of McGill IT, kindly met with me to discuss my experiences and McGill’s strategy. There is lots of proprietary software that I love, but when a major buyer like McGill chooses suppliers, I hope it will make “external interfaces” or standards-compliance more of a selection criterion, or requirement, rather than continuing to buttress its status quo.
So after the meeting, I have to correct bits of bad information, above. I can’t apologize for passing on what was told to me by their staff or written on their web site, but some of what’s above is out of date or wrong, and I’ll try to correct it, whether or not it was my own error. (I was on the front lines of a university IT help desk in 1995, and had to deal with questions about UNIX, Apple, and Microsoft, and know that it can be tough dealing with questions beyond one’s primary competence.) Anyway, from memory from the meeting:
- Faculty and staff no longer have debilitating quotas on their Exchange boxes… though mail gets shuttled off to some archive when it’s old or you hit a quota.
- I can, actually, use McGill’s central SMTP server without having an Exchange account. Here’s the syntax for .pinerc, for example (this is standard; not sure why it didn’t work earlier):
However, (a) it will not allow any sender email address other than one’s McGill one(s). (b) It’s really slow. It takes several (5?) seconds to send an empty message, while it takes an imperceptibly small fraction of a second to send one through my alternative (another SMTP server on campus). Nevertheless, it’s not the case that McGill is not reasonably providing me the ability to send email from my institution. So thanks for that, and I’m sorry for claiming otherwise (though it was their very explicit claim that I could not use SMTP without an Exchange account).
- There is the same limit for all email messages of 30MB, whether one’s address is redirected outside McGill or goes to/through the Exchange box. So why do my colleagues tell me that large messages only bounce from me? Probably because they’re sending ones just under 30MB and within Exchange the binary attachments never get encoded, while as soon as they are to be sent by SMTP they grow slightly in size when they are text-encoded. Brian thought GMail’s quota is 25MB, so if they increase their offsite-forwarding quota by 20% to allow for internal-30MB messages to go through, it may be that Google starts rejecting them…
I would have thought that most students would just set up their McGill mail to forward to Google or another Mail service. It would be helpful to see statistics on this, and other aspects of their user base, on the McGill ITS website.