In this very loaded topic, I’ll be walking through the question:
How do you get an email address on your user account in UWWI, or the NETID domain?
and I’ll also be touching a few other email address related points along the way.
My colleague, James Morris, is responsible for the UW’s “edge infrastructure” (among many other things), and he may have a follow-up post in the future to fill in some additional details which complement this post.
When most folks at the UW get a UW NetID, they are also eligible for a couple other mail related services. These include the deskmail service (what webpine points at, and the vast majority of UW folks use), and the “UW Email forwarding” service.
Outside of the deskmail service, there are many other email services provided both at the UW and elsewhere which UW folks might be using. So for any given UW person, the email address they might be actively using could be almost anything. And to be clear, some people have more than one active email address.
In general, there is an assumption that <uwnetid>@u.washington.edu will end up at the person’s active email address. However, this is an assumption which may or may not be valid.
To accomodate this assumption, UW Technologies runs the “UW Email forwarding” service, which takes email destined for <uwnetid>@u.washington.edu (or @washington.edu) and forwards it along to an email address that the user may set.
This setting is exposed at https://uwnetid.washington.edu/manage/?forward.
That data is stored in a special-limited use LDAP directory. In other words, this is not the whitepages directory (directory.washington.edu), nor PDS (eds.washington.edu), nor GDS (groups.u.washington.edu), nor UWWI (netid.washington.edu).
This enables UW folks to use something like gmail but maintain the appearance of a UW email account, and also benefit from other UW email services like those provided at the edge (i.e. virus and spam checking).
Additionally, there’s a way for people to “publish” their email address to others. This published email address information comes from the primary sources of enterprise data, two of which are the Student database (SDB) and the HR system. Assuming the person has allowed it, this published email address is put in both the whitepages directory and PDS. There is a special scenario for people who are both student and employee, but who have chosen to publish only one of their related email addresses–but I won’t go into that scenario here.
Fortunately, there’s a way for folks to edit their information in those systems. For employees you can go to https://prp.admin.washington.edu/ess/uwnetid/address.aspx
and within the Campus Address section choose to edit the Email field.
Note that both of these sources of data are user editable. Users can make mistakes. There is no input validation, nor anyone looking for typos. And there also is no logic validation, so folks might be publishing an email address which is not:
This latter scenario is highly relevant to the UW Exchange service, so keep it in mind.
That’s the landscape and background that UWWI has to work with.
As you know if you’ve read past blog posts, there has been an evolution in the quality and quantity of directory information on user objects in UWWI.
At account creation time (and any other kiwi event), we grab relevant directory information from PDS (assuming it’s marked as published). However, the mail attribute is not included in the information taken from PDS at account creation (more on this below). We also use Identity Lifecycle Manager (ILM) to synchronize directory information from PDS roughly every 2 hours. However, neither of these actions is a direct 1:1 synchronization. There are a variety of reasons for this including differences in schema between the directories, and differing use cases.
For the mail attribute on UWWI user objects, there is a combo of interesting logic, primarily because of the presence of the UW Exchange service within UWWI. The logic each of those events follows is different. The account creation and kiwi events set the mail address to <uwnetid>@u.washington.edu. This logic is limited because it was written early in the service’s life, and we knew something better would come along. The ILM logic synchronizes the “published” email address info in PDS (using official business logic if the person is both a student and employee), but only if that user does not have an Exchange mailbox. If the user has an Exchange mailbox, it does nothing.
Before I explain that, I want to step back. You’ll note that the “published” email address was chosen instead of the “uw forwarding” address or the general assumption of <uwnetid>@u.washington.edu. There are differing opinions about this choice, but when all is said and done, using the published email address permits the widest amount of flexibility–which is why it was chosen. Obviously there are potential problems with this choice, including the possibility of bad data (not true with the general <email@example.com>) and the possibility that the value is not actually the address the user is actively using (see my comments above about logic validation), but the rationale behind the choice is good. Bad data or choices can be refined, and user education should improve to help avoid them.
Now … back to our story. Why would we stop synchronizing the mail attribute when a user gets an Exchange mailbox? This is because Exchange links some of it’s basic functionality to that attribute. The mail attribute must agree with another Exchange-centric attribute or else there will be Exchange problems for that user. Since the “published” email address has no logic validation upon which we might restrict user choices to agree with Exchange, once a user gets an Exchange mailbox, we must stop paying attention to the published email address for that user.
Currently, this means that Exchange users must ask us to manually modify their email address if they desire a change. In the future we may have a solution for this.
Also note that some uw netids have no published email address for a variety of possible reasons. In that case, the kiwi account creation code covers this case by setting <uwnetid>@u.washington.edu. And there’s no way for those uw netids to change their email address at this time either.
That’s probably enough on this topic for now. I’m sure I’ve neglected some portion of this which I’ll have to add later.