Email at OSU Physics
Problems
From a client-side perspective, there are several long festering problems with email service at OSU Physics. This is an attempt to organize a report of the problems I’ve observed.
There is no single mail stop for Physics. There is confusion over the mail stop for any given user at Physics. Given a username, a correct mail stop for that user can be induced from several clues available to the support staff, but these clues are not available to the user community. When a new user applies for an account, there is agnosticism among the support staff; we hesitate to advise a new user that they should use either one of the two mail servers available at Physics. Unfortunately, for most users this only leads to confusion. Forwarding is not by default provided during account creation; even the item on the account form is usually interpreted by the user to refer to forwarding to or from accounts outside of Physics. After all, if any one of us were to start a job at a new organization, would we expect to have to manually set up forwarding inside that organization, (or maybe more dramatically, inside our new department at that organization)? It seems a strange arrangement, even though we the staff understand the etymology of names like xxx@mps.ohio-state.edu, xxx@ohstpy.mps.ohio-state.edu, xxx@pacific.mps.ohio-state.edu, or xxx@campbell.mps.ohio-state.edu. While we can understand and excuse this arrangement, can our users?
There is a dearth of useful and/or bug-free mail clients available to users at Physics. Let me list the clients available, and observations on their individual faults:
Eudora. The most obvious problem is that Eudora must be coaxed into storing mail and settings on a central server. If that were the only problem, Eudora would be an acceptable option. However, as Eudora has moved away from its dependable version 3 days, it’s become both more capable, (IMAP ready, etc), and more buggy. A user’s settings can become so corrupted that the initialization and other settings files must be re-created. I’ve had to address this problem with perhaps 5 users over the last year. Not an epidemic, but the lack of tech support aggravates the problem. Occasionally, access violations occur when starting Eudora, with subsequent failure of Eudora for all users of a particular NT workstation. Eudora works with the IMAP protocol, but users must be carefully educated about the dangers of choosing the wrong directory folder icon, or risk, by a single undocumented mouse-click, starting a folder synchronization which might take hours to complete. There’s also the nuisance value of the “Remote Instance” problem. In addition, Qualcomm, the makers of Eudora, seem to take the tech support approach that, if a problem is not admitted to, then it does not exist. I’ve found their online support to be almost useless.
Outlook Express. One problem with OE on a PC is that it wants to store all data in the user’s NT profile. Therefore only IMAP is practical. I use OE, and I do find it to be a fairly reliable client. If OE were available on Unix platforms, it would be my recommended client for new users. Since it’s a MS product, there is almost zero probability that it will be ported to any Unix platform.
Pine, et al PC/Mac Clients. Per se, Pine is a very reliable program. However, Pine et al share a problem common to all clients in use at Physics: No one of these will run on all platforms. We investigated Pine for Windows last year, with the hope that it might be the one client common to all platforms, but it didn’t seem to be a very finished product. Eudora is a PC/Mac product, the same is true of OE. So we don’t have a single mail client that we can recommend to our users for all three of PC, Mac, and Unix, (I won’t even bother adding VMS to the list, even though there remains a small VMS "interactive user" clientele).
PMDF MAIL, Emacs rmail. These are very reliable. Given an ssh client, these server-resident clients can be used anywhere, with no danger of loss of settings, or misplacement of mail data. However, these clients are showing their age. Even though I still prefer PMDF MAIL because I’ve used it or something like it for 17 years, my favorite mail client can’t (directly) process about 20-30% of the mail I receive. In an x window environment with appropriate viewers PMDF MAIL will do anything that the PC/Mac clients will do; however, by the time I get all that started from my PC, I might as well start Outlook Express or Eudora and process the attachments from within the mail client itself.
Solutions
I don’t administer either of the servers at Physics. These ideas might therefore be naïve or impractical.
Create physics.ohio-state.edu and use it. In fact, it already exists. However, in the sense that it could be used as a mail domain, we might either leave it pointing at PHYAS1, or we might re-point it to another server which would become the first stop for any user wishing to receive mail at Physics. Then we’d have to advertise this as the mail domain at Physics, (though the other mail servers would still receive mail addressed to them). Initial setup would be a pain, but having a known primary Physics mail domain would solve several problems:
There would be one mail domain name for all users at OSU Physics. This wouldn’t be fully “fuzzy”, but it would allow a mail sender to have a good first assumption about what a member of OSU Physics might have for a mail address, (e.g., lastname@physics.ohio-state.edu). At least they’d get the mail domain right.
There would be a reduction of mail forwarding loops. With a hierarchy to mail delivery, we could have a rule (for humans) stating something like “For mail forwarding within Physics, forwarding must occur at physics.ohio-state.edu. Mail forwarding from accounts at Physics to servers outside Physics can occur on any Physics mail server. “
Deploy browser-based client(s). There are clients available, (Rutgers showed me one running at Caltech), which store settings and data on the server, but which allow management, mail browsing, and mail composing via an HTML interface. This would be unlike Netscape Messenger, where settings and mail tend to stay on the client. This would be more akin to, say, Yahoo Mail. However, new software, (e.g. www.stalker.com ) would have to be installed on “the server”… Ok, that would be Campbell. Nothing equivalent exists on VMS.
Ok, we want the browser-based client, so just install the server software someplace other than Campbell. Another approach might be to install something like Communigate Pro on an NT server, and then do the hard processing, (that John has worked out over years of effort), on the VMS server. The advantage is that we’d be able to deploy a server which could offer clients web-based services. The disadvantage is that we’d introduce yet another mail server and hence another mail domain name. I don’t know if that’s wise. If we could mask the existence of the server itself from the user, (e.g., “Just point the browser at this URL, type in your NT username and password, and get your mail”), then another server might be ok. Regardless, adding another server, using the hard-won processing rules available on OHSTPY, would (a) “leverage” John’s knowledge, and (b) avoid adding yet another work item to BD.
Unfortunately, even if we mask this imagined new server and make the user think they’re just connecting to a cool new client, we still have the mail domain name problem for incoming mail. One idea would be to assign the new mail domain name physics.ohio-state.edu to the new server. Then for all existing users, we could farm out mail flow to the servers they already use, via forwarding from physics.ohio-state.edu. For new users, there would be a default action of using the new server to handle mail. Any user who chooses to could have mail forwarded to one of the legacy servers, (I use that adjective with trepidation). Mind you, the legacy servers would still do the bulk of the work, but for new users there might be a slow migration to the new server for all mail processing, (with the exception of the extensive rules-based handling on the old servers to which the new server would indefinitely look for guidance).
User Education. Even with the existing arrangement, we probably shouldn’t let a new user out the door without (a) setting up forwarding for them internally, (i.e., OHSTPY to Campbell or the reverse); (b) helping them decide, based on their usage patterns, what client from those available they would like to use to read mail, and then helping them set things up correctly. For instance, I know a user who on their own initiative started using Outlook Express, with OHSTPY as the server, and with POP3 as the protocol. We don’t want anyone for any reason using OE on the public NT machines with POP3, because their profile will become even more unwieldy than it would otherwise be. Another example would be using Netscape Messenger on NT when the Netscape settings don’t point to the “right” place, (the user’s private network share). This is an extremely common defect of Netscape on the WinTel platform, even after I’ve prepped it during initial install.