Yale intends to decommission the Mail Relay machines and replace their function with the Exchange Online component of Azure/O365. The Mail Relays are configured with data from the Email Alias system. They receive mail with a destination address ending “@yale.edu”, process the mail through SPAM/security scans, then forward the mail to the computer or mail system associated with the MAILBOX field of the Email Alias.
If we replace the Mail Relays with Exchange Online, we have to create configuration for Exchange (in Azure AD) that provides to Exchange a mapping from the the Email Alias table ALIAS_NAME field to the MAILBOX field. This means creating some AD object where the ALIAS_NAME is in the ProxyAddresses property list and the MAILBOX is the TargetAddress property.
No changes are required to the configuration of email addresses for mailboxes already managed by Exchange, including personal O365 mail accounts, distribution lists, shared mailboxes, and mail addresses in any mail domain managed by or aliased to Exchange Online. By definition, Exchange Online must already be configured to deliver such mail to the right mailbox, and that existing mapping will work the same for mail sent directly to Exchange Online as it does when the mail passes through the Mail Relays and then goes to Exchange Online.
The most common required configuration is for personal Eliapps Email accounts belonging to students. They have a Primary Email Alias where the MAILBOX is ALIAS_NAME@bulldogs.yale.edu. It is a Yale practice to put students enrolled in any class into an Exchange Distribution List for that class. We therefore needed an AD object with the TargetAddress equal to the Eliapps MAILBOX to add to the Distribution List Group. About a year ago this TargetAddress property was added to the AD User object for current active student Netids, and the Primary ALIAS_NAME was added to the ProxyAddresses list of the User object.
However, for the purpose of Canvas class distribution lists, it was not necessary to maintain these User objects across name changes. Since then, 52 students have changed their name and their Email Alias, and for this project we should begin to reflect Alias changes to the AD User object.
The changes made last year for Students highlights an important point about the Mail Relay retirement project. We can add correct mail routing information to the AD at any time before the Mail Relays are removed. When we do that, Exchange Online now knows to send mail from an O365 user directly to an Eliapps mailbox without going through the Relays. We can test a configuration change by sending mail from O365 to a reconfigured alias to verify it arrives correctly. After Exchange has been configured with every external alias, then at any time after that we can change “@yale.edu” to go to Exchange instead of the Mail Relays as the final step.
We did not add secondary Email aliases to the ProxyAddresses list. The most common source of secondary aliases is that they are the old name of a student after a name change. In addition to the 52 student who changed their name in the last year, there were more students who had already changed their name before the AD User objects were populated with Eliapps student account information. As long as the old alias remained in the Alias Table, the Mail Relays would forward mail for that old name to the Eliapps account, and if we are going to replace the Relays then we have to duplicate that function by adding all the ALIAS_NAME values (Primary and Secondary) to the ProxyAddresses list of the student’s User object.
Every Email Alias in the table has to be handled. Once you remove the Exchange Online MAILBOX values and the personal student Eliapps accounts that are already in the AD, there are a few common patterns that fall through the cracks:
There are Eliapps accounts belonging to students who were not taking classes last year but who still have active mail. Remember, last year we were looking for anyone who could go into a Canvas class distribution list. Now we have to replace the Mail Relay routing function, and there are about 1000 more Eliapps student mail accounts that need to be inserted into the AD User object of those Netids.
There are Eliapps accounts belonging to people (mostly in ITS) who have both O365 and Eliapps mail. The O365 mail account occupies their User object, so we cannot put the Eliapps mail routing in that object as we do for student Eliapps users, so we need to create a Contact object for these accounts.
There are Eliapps accounts for mailing lists and departmental shared mailboxes. These are “@elilists.yale.edu”, Yale student groups like “yale.spizzwinks@bulldogs.yale.edu”, and research projects like “thechildlab@bulldogs.yale.edu”. They also get Contacts.
In the end, for every row in the Email Alias Table (DIR_ONLINE_INFO in ACS1) one of two things must be true:
The MAILBOX is a special object like a Distribution List of Shared Mailbox configured to Exchange Online.
There is an object (User or Contact) for which the ALIAS_NAME is an entry in the ProxyAddresses list of the object and the MAILBOX is the TargetAddress.
After we make the various changes to AD User and Contact objects, a program will run through the table and verify that every Alias maps the same way through AD as it did through the Aliases (and therefore Mail Relays).
We cannot preserve the behavior of a handful of personal aliases where a user has created mailboxes with the same name in both O365 and Eliapps and has set the Primary Alias to point to Eliapps. With the Mail Relays, mail sent by O365 users goes to the O365 mailbox and all other mail goes to Eliapps. When the Relays are retired, all mail will go to O365. The old behavior cannot be duplicated, but this configuration violates Yale policy so we will simply inform the affected users before the change.
This project has to refine the list of email domains that are inherently associated with Exchange Online. We know that “@expectwithme.org” is actually an O365 alias, but while ayalists.yale.edu is in Exchange, elilists.yale.edu is in Google, and “lists.architecture.yale.edu” is uncertain. This is not just an IAM problem, because Linux Systems has to fix the MX records for each of these domains.
There are data errors in the Alias Table that will generate unnecessary Contacts. It is not necessary to fix them at this time, but if we don’t do it now, there will be no better time in the future.
Originally Yale did not think of Email as a single topic. There was the problem of Student Mail, addressed by the Instructional Support group of ITS. Then there was Employee mail decided by the business focused groups. Once a system was selected, there was some involvement by Unix or Windows groups for technical support.
IAM became involved for three reasons.
Historically, there was a time when we charged back mail accounts to departments, and IAM inherited the systems that were created for that purpose even after we stopped charging for mail accounts.
IAM creates basic resources like a Netid and AD object for new students, employees, and sponsored identities. Students and employees automatically get mail accounts, and it was efficient for IAM to create these “birthright mail” accounts when a new identity is created.
What people think of as the Email Address is also a login string (a “principal” name) for the non-mail functions like OneDrive, Google Drive, and Box. IAM has to manage it as a login name and, among other things, lock and unlock it along with the Netid.
However, other groups make changes to Email accounts. The Help Desk changes the Aliases and the Eliapps account when a user changes their name. The current Email support group creates O365 and Eliapps accounts for non-birthright users, and helps to change accounts when someone changes their Yale association.
IAM is involved with Mail, but we did not set the original rules (remember, Instructional Support decided how Eliapps accounts would be named), nor are we involved in all updates. We own the DIR_ONLINE_INFO table of Mail Aliases even though the Help Desk changes the aliases in it, and we know enough about the rest of the mail system to implement this change.
A student named Johnathan Doe is initially assigned a Primary Alias of “johnathan.doe” and an Eliapps account name of “johnathon.doe@yale.edu” which means the MAILBOX is “johnathon.doe@bulldogs.yale.edu”. Then he changes his name to “John” and requests his Email get “fixed”.
A new Alias of “john.doe” is created initially as a secondary alias, but it is then promoted to Primary and the old johnathan.doe becomes a Secondary Alias. The same thing happens to the Eliapps account, which is renamed “john.doe@yale.edu” but has an alternate Email address of the old “johnathan.doe@yale.edu”.
If this is done correctly, then both the new Primary “john.doe” and the secondary old “johnathan.doe” Alias Table entries have a MAILBOX of “john.doe@bulldogs.yale.edu”. Then we know that these are two aliases of the same account. However, because both the new and old names are in the Eliapps User Directory, mail does get delivered correctly if someone is sloppy and does not change the MAILBOX on the old now Secondary Alias.
If Primary ALIAS_NAME “john.doe” has MAILBOX “john.doe@bulldogs.yale.edu” and Secondary ALIAS_NAME “jonathan.doe“ has MAILBOX “jonathan.doe@yale.edu”, there is no way in the current system to plausibly realize that they are the same mail account. Google does not like us to programmatically do a lot of queries to the User Directory, so for a large number of users we cannot verify that the two MAILBOX values point to the same Eliapps account. We will put the Primary account in the AD User object of this Netid, but if the old name has a different MAILBOX value, it is going to look like a second mail account and it will generate a Contact.
The mail is delivered properly, but the AD has an unnecessary object caused by poor procedures or a lack of specific tools to perform common operations in a standard manner.
There is a TEST instance of O365 (“yalelab.onmicrosoft.com”) and Eliapps (“gtst.yale.edu”).
There has never been a functional TEST version of the Mail Relays, but we don’t have to test the thing we are getting rid of. We only need to test what is left.
Unfortunately, there has never been a TEST philosophy for Email Aliases. There is a TEST DIR_ONLINE_INFO table in ACS2, but once or twice a year the DBAs copy the PROD table from ACS1 to ACS2. We can temporarily create TEST aliases that map firstname.lastname@yale.net to connect.yale.net.
Fortunately, all the changes we have to make for this project go in the AD, and we do have a functioning TEST AD. What is not clear, however, is if when I go to TEST something, the TargetAddress I put in the TEST AD should be a pointer to a TEST O365 or Eliapps account, or should it be a pointer to the PROD account. We are testing if the mail gets delivered correctly, and the only way to be sure is to see if someone receives it. Users do not have TEST mail accounts, and if they did they would not know how to login to them. We have learned that TEST systems frequently have to point to PROD Netids and mail accounts when users are involved.
The following can be read by anyone, but it is directed to technical staff who have to maintain this stuff in the future. You should decide if you want to know more about how mail is delivered.
Every hour a program reads the Email Alias Table (SMART.DIR_ONLINE_INFO in ACS1) and generates configuration files for the Mail Relays. That table contains a lot of housekeeping data (when last changed, who last changed, and there is a history table), but the important fields for mail routing are:
ALIAS_NAME - The part of the Email Address in front of the “@yale.edu”. Because of the MX records configured into DNS, any mail system outside Yale believes that “@yale.edu” as a mail destination goes through the mail relays. You should note, however, that both Exchange Online and Google G Suite are each configured to believe that they are the mail system named “@yale.edu”.
MAILBOX - The “native” mail address of an account in some Yale Mail system or server that should receive mail addressed to this “@yale.edu” alias. Originally this was the name of a mailbox on a server computer (connect.yale.edu was the DNS name of the first Windows NT machine that ran Exchange and maybe PC Mail before it), but today it is most commonly the name of a mail account in either O365 or Google. The most commonly followed Yale convention is to use “netid@connect.yale.edu” for a personal O365 account or “ALIAS_NAME@bulldogs.yale.edu” for Eliapps accounts (with the difference caused by assigning different groups to make that decision in the past). We ensure that the MAILBOX value is a valid Email Address, but discourage anyone from using it normally because it will deliver mail directly bypassing the Relays and any SPAM or security filters.
TYPE and NETID - Each person has one Primary Alias and may have additional Secondary Aliases. Every Alias has a Netid that owns it. The Primary Alias points to the personal mailbox of the owning Netid, and any Secondary aliases that point to the same mailbox are regarded as alternate names for the personal account. When the Primary MAILBOX is an Eliapps account (ends in “@bulldogs.yale.edu”) that is the only way to find the Eliapps account for that netid (because the Eliapps account does not have the netid as any part of the account name or directory contents). When a Secondary Alias does not point to the Primary MAILBOX, we really don’t know what it is used for. Sometimes it is a mail account of a dependent Netid, and in a few cases it is the personal mailbox of someone else. Sometimes it is the name of an Exchange object (a shared mailbox, distribution list, shared calendar, etc.).
Observation: After the Mail Relays are retired, the only purpose of an Email Aliases for Exchange Objects (shared mailboxes, distribution lists, etc.) is to reserve the name and mark it “in use”. No generated configuration will be needed for these objects to receive mail (that is, the MAILBOX value of such objects is irrelevant). However, the ProxyAddresses list of AD User objects for people with O365 personal mail accounts must continue to be updated with Primary and Secondary Aliases for these accounts.
Responsibility: IAM generates Birthright Email accounts. We make Email addresses visible in the phonebook. We have inherited a part of the AD Daily Updater that checks for missing ProxyAddresses list entries for Aliases with an “@connect.yale.edu” MAILBOX value, but this has just been an excuse for the scripts that manually create and move mail accounts to be sloppy and ignore required changes to the AD. We should consider correcting mail account manipulation tools rather than auditing every few hours for oversights. If Alias changes are immediately reflected in updates to AD objects, then only “biographical” data (name, department, etc.) has to be updated in AD.
Someone sends mail to “john.doe@yale.edu” or “gravitywaveastronomy@yale.edu”. The sending system does a DNS search for an MX type record associated with the name “yale.edu” and gets back the following:
yale.edu MX preference = 10, mail exchanger = oolong.mail.yale.edu yale.edu MX preference = 10, mail exchanger = chamomile.mail.yale.edu yale.edu MX preference = 10, mail exchanger = jasmine.mail.yale.edu yale.edu MX preference = 10, mail exchanger = earlgrey.mail.yale.edu yale.edu MX preference = 10, mail exchanger = darjeeling.mail.yale.edu yale.edu MX preference = 10, mail exchanger = chai.mail.yale.edu yale.edu MX preference = 10, mail exchanger = rosehip.mail.yale.edu |
This is a list of the Mail Relay machines (informally known as the “teas”). The mail is sent to one of these machines.
The Mail Relays are configured from the Alias Table. The program that generates the configuration looks at each ALIAS_NAME and MAILBOX value. When an incoming Email address ends in “@yale.edu”, then the part in front of “@” must match an ALIAS_NAME. Then the MAILBOX for that alias entry tells the Mail Relay where to forward the mail. In the MAILBOX value, the part after “@” has its own MX record in the DNS system (although the Mail Relays may already have a copy of this data in memory). Looking up the “connect.yale.edu” suffix finds:
connect.yale.edu MX preference = 10, mail exchanger = connect-yale-edu.mail.protection.outlook.com |
while bulldogs.yale.edu is associated with
bulldogs.yale.edu MX preference = 20, mail exchanger = alt1.aspmx.l.google.com bulldogs.yale.edu MX preference = 30, mail exchanger = aspmx3.googlemail.com bulldogs.yale.edu MX preference = 30, mail exchanger = aspmx5.googlemail.com bulldogs.yale.edu MX preference = 20, mail exchanger = alt2.aspmx.l.google.com bulldogs.yale.edu MX preference = 10, mail exchanger = aspmx.l.google.com bulldogs.yale.edu MX preference = 30, mail exchanger = aspmx4.googlemail.com bulldogs.yale.edu MX preference = 30, mail exchanger = aspmx2.googlemail.com |
If there is no MX record, then the suffix must be the DNS name of a single computer that runs some SMTP service and some local mail account. Yale doesn’t allow a MAILBOX to point to any external mail system, but as long as the MAILBOX ends in “.yale.edu” then it is allowed even if it is the name of a machine under someone’s desk in a physics lab.
If we replace the Mail Relays with Exchange Online, then the previous step doesn’t happen. We change the original MX record for “yale.edu” to point to “connect-yale-edu.mail.protection.outlook.com” and we take the teas and dump them in Boston harbor (we can have a party to celebrate the success of the project, but dressing up as native Americans is no longer appropriate because it is “cultural appropriation”).
Exchange Online will behave the same whether mail is sent to it directly or comes through the Mail Relays. So any mail that Exchange already processes correctly will work the same and we do not need to make changes.
The largest block of mail that will be processed differently are the student Eliapps accounts. Previously they would be sent from the Mail Relay to Google directly. Now the mail goes to Exchange. Because Exchange believes that it is “@yale.edu”, it initially expects that mail addressed to a user named “john.doe@yale.edu” is a personal O365 mailbox or a group object named “gravitywaveastronomy@yale.edu” is a shared mailbox or distribution list. However, it will find that the Azure AD User object for “john.doe@yale.edu” has no O365 account and will find no configured DL named “gravitywaveastronomy@yale.edu”.
It has always been possible to add configurations to Exchange and AD for mail accounts that belong to a university or company but which are hosted on another mail system. Originally Microsoft designed this when each department in a company had its own departmental mail server, but it works with any kind of server.
We already have the information we need in the Alias Table. Just as the current system uses the Alias Table to generate configuration for the Mail Relays, we can generate configuration in AD that Exchange will recognize as a pointer to a Yale University mail account on an external server. There has to be an AD object. The AD object cannot be a User with an O365 account (or the mail would be delivered to that mailbox). The object must be have a TargetAddress property.
The value of TargetAddress is essentially the MAILBOX column value in the Alias Table.
The AD Object can be a User or a Contact. Since every student with an Eliapps account already has an AD User object (and Yale Policy is that Eliapps mail users don’t also have an O365 mailbox), we have adopted the simplifying rule to put a TargetAddress in the existing User object for these students, but create a Contact for shared mailbox groups and everyone else.
The ALIAS_NAME must match one entry in the ProxyAddresses list property for the AD Object.
If we do this, then Exchange Online has the information it needs to forward mail for every Alias in the Alias Table that does not have an “@connect.yale.edu” MAILBOX, and therefore it can replace the existing Mail Relay function.
Exchange does not care how many objects you scatter into the AD, but it would certainly be a bad idea to create extra objects for the secondary Aliases of a student Eliapps account. So the student’s AD User object should contain ProxyAddresses for both the Primary Alias name and all secondary Alias names that point to the same “bulldogs” MAILBOX account.
We propose to also group Contact objects by MAILBOX value. More that one Alias can point to the same MAILBOX value, but if we group by MAILBOX value, we can then generate one Contact object for that value and add a ProxyAddresses entry for every ALIAS_NAME in the table with that MAILBOX.
Alias names change if a person chooses to change their First or Last name or if they enable and disable privacy. This is an IAM function.
Currently the old AD Daily Updater generates ProxyAddresses from Primary and Secondary Aliases of Exchange (@connect.yale.edu) MAILBOX values, although the old code gets confused unless the Netid owning the Alias is also the netid in the “netid@connect.yale.edu” value (which isn’t always true). The replacement code in IIQ (which has been written and tested but has not gone into production) fixes the incorrect assumptions by ignoring alias ownership, and it also generates the correct ProxyAddresses entries for primary and secondary Eliapps accounts (@bulldogs.yale.edu).
However, to address the “Canvas Contact” problem we have created ProxyAddresses and TargetAddress fields in the AD and Azure AD User objects of current students with Eliapps accounts. This is done only when the mailbox is created, so if a student generates Secondary Aliases or changes the Primary Alias, the ProxyAddresses list would have to be changed manually.
Work to Do: Populate the ProxyAddresses list of student Eliapps users with any Secondary Aliases that have a MAILBOX that points to their Eliapps account.
Work to Do: There may be Eliapps accounts that are the Primary Email Alias of people who are not current students and were not configured as part of the student class distribution list fix. Their Primary and Secondary aliases should be configured in their User objects if possible, or in a Contact if they also have an O365 account occupying the User object.
Work to Do: All remaining Email Aliases (excluding aliases pointing to some sort of Exchange account or a Primary Eliapps account) get turned into Contacts. We do not create or look for User objects for them. A new Contact is created in some new OU, and the MAILBOX becomes its TargetAddress and all the ALIAS_NAMEs with that MAILBOX value become entries in its ProxyAddresses list.
Decision Point: The personal O365 and Eliapps accounts are plausibly related to IAM, although we are not in the business of creating Secondary Aliases. It may be decided that it is useful to continue to audit the Alias Table and the ProxyAddresses list to see if somehow personal Alias changes slipped in without generating the required ProxyAddress changes. However, the creation and modification of shared mailboxes and departmental accounts is not an IAM function and because these objects have no information in Identity tables, we are not in a position to audit them properly. We should consider this a one time conversion of Alias information into AD objects and properties that configure Exchange Online. Going forward, all scripts, tools, and procedures used to generate departmental accounts and create their aliases should also manage their Contacts with the mail routing information.
Cleanup: If tools are created or converted to manage non-personal mail accounts, then we should consider establishing some proper rules and converting existing entries to match these rules. In particular, the practice of creating an Email Alias and a Dependent Netid and assigning ownership of the Alias to the person who owns the dependent Netid causes serious problems. People leave the university without transferring both the alias and the Dependent Netid to someone else. Then when their personal mail gets deprovisioned, the Secondary Alias for the group account remains attached to the inactive AD User object. The correct thing to do is the assign ownership of the Alias to the Dependent Netid that represents the shared mail account. The account can then stand alone, and if the owner fails to transfer the Dependent Netid to someone else, well the Dependent Netid is still active even if the former owner is inactive. This fix is not technically part of the Mail Relay project, but if we are fixing all the tools for this type of account we should fix this at the same time.