...

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

Yale University advertises to the world (through MX records in the DNS system) that the email domain “@yale.edu” is managed by a group of computers we call the Mail Relays. The world sends all “@yale.edu” mail to the Mail Relays and they forward the mail to the computer or mail system associated with the MAILBOX field of the Email Alias. If the MAILBOX ends appropriate other system that actually has mailboxes in which to deposit the mail.

The Mail Relays process mail through a SPAM/security scan. It then looks up the destination mail address in tables created from the Yale Email Alias table. If it finds a match, it forwards the mail to the account identified in the MAILBOX field of the matching Alias entry. There are three possibilities:

1. A MAILBOX value ending in “@connect.yale.edu”

...

1. (or any other domain associated with O365 mail) is sent to the Microsoft Exchange Online service.

2. A MAILBOX value ending in “@bulldogs.yale.

...

1. edu' is sent to Google.

...

2. Any other MAILBOX value is the DNS name of a computer service. The service may provide email mailboxes for users, or it may read and process the mail (when Service Now turns mail to specific destinations into tickets), or it may forward the mail to a different address.

If we remove replace the Mail Relays , all with Exchange Online, then we change the DNS server MX record so that the “@yale.edu” mail will go domain goes directly to Exchange Online. Exchange will deliver mail to its own mail accounts first. Then for every address it does not match to an internal destination, it will search tables built from Azure AD to decide where to forward that piece of mail.

The configuration of external mail aliases in Exchange Online is done through two properties in the Azure AD. The TargetAddress property of a Azure AD object contains the MAILBOX value from a row of the Email Alias table. The ProxyAddresses property contains a list of Email Addresses that are to be forwarded on to the account in the TargetAddress.

The Azure AD object that contains these two properties can be a User or a Contact. Exchange doesn’t care, but it makes sense to us to reuse existing User objects of students whose Primary Email Alias points to an Eliapps account and who have no O365 account. In this case the ProxyAddresses list contains the Primary Alias name and any Secondary Alias names that resolve to the same MAILBOX value. Everything else generates a Contact.

These Contacts are strictly for internal routing configuration purposes. They are not published in any directory and are used only by Exchange Online to forward mail. While we could create one Contact object from each row of the Email Alias table that is not represented by a ProxyAddress/TargetAddress pair in a User object, we have decided to group all the Alias Table entries that resolve to the same MAILBOX value as entries in the list of ProxyAddresses of a single Contact object named for the common MAILBOX.

Except for the aliases that resolve to servicenow@bulldogs.yale.edu. There is a limit of 400 entries in the ProxyAddresses list of an object, and currently 111 aliases resolve to that MAILBOX. While there is clearly some room for expansion, this policy could lead at any time to someone creating 300 new aliases for servicenow, and then any code we wrote would break. So these aliases have to be handled specially, as would any new system that wants to create a similar arrangement.

Exchange Online requires that entries in any ProxyAddresses list must be unique. This process generates them from the ALIAS_NAME column of the Email Alias table which is constrained to be unique.

Because the Azure AD already has to be properly configured for O365 personal and shared mailbox accounts (or Exchange would not be able to deliver mail to these destinations), there is no need to make any changes for Email Alias Table entries that resolve to the “@connect.yale.edu” mail domain or any other domain that is an alias of Exchange itself.

For a year, we have been populating the TargetAddress field of the User object of 15000 current active or new students with an Eliapps mail account. There are approximately 1000 additional User objects for what appear to be former students who still have active mail whose User objects will now be populated.

Previously it was unnecessary to update the TargetAddress when a student changes their name. Technically this is still not necessary (because the old name remains an alias of the Eliapps account) but it seems to be better if this field is updated when the MAILBOX of the Primary Email Alias is changed. In addition, we were not previously adding Secondary Aliases to the ProxyAddresses list but will add them now. It may be unlikely that anyone will receive mail under an old name changed three years ago, but as long as the old name remains in the Alias Table, this project must configure Exchange Online to deliver mail to all currently valid Aliases no matter how unlikely it is that they are actually in use.

Therefore, there is a simple test to verify that the configuration required by this project is complete. Run through all the rows in the Email Alias Table (DIR_ONLINE_INFO). If the MAILBOX is one of the Exchange Online domains, ignore it. Otherwise, look for a ProxyAddresses entry matching the ALIAS_NAME value in some AD User or Contact object. The TargetAddress property of that object must match the MAILBOX value of the Alias.

Contacts are created for Aliases that are not Exchange accounts and are not Primary Aliases of Eliapps students. It is not necessary to say what these accounts are, but in case you want to know, they are mostly:

• Eliapps accounts of people who also have an O365 mail account. These are mostly ITS people.

• Elilists (a type of mailing list managed by Eliapps instead of Exchange)

• Student groups (example: yale.spizzwinks@bulldogs.yale.edu)

• Departmental shared mailboxes (example: thechildlab@bulldogs.yale.edu)

• The 111 aliases of servicenow@bulldogs.yale.edu

• Mail for specific department servers (invest.yale.edu, aya.yale.edu)

• Everything else. Sometimes this is recognizable junk left over from machines that have not existed since 1995 (gopher.cis.yale.edu) but it is not necessary to clean this up and that is not part of this project.

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.

Transition

After these changes are made to the ProxyAddresses and TargetAddress of existing User objects and new Contacts are created but before the Mail Relays are retired, the only change in behavior is that mail sent from an O365 mail account will now go directly from Exchange Online to Google or any other external service referenced by a TargetAddress. Previously the mail would go from Exchange Online to the Mail Relays and then be forwarded to Google or other services. The generated AD entries must be correct for this mail to be delivered properly.

Then later on we turn off the Mail Relays. Now the generated AD configuration must be complete for the mail to be delivered properly.

Fine Tuning

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.

Source of Problems (History)

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.

However, SMTP is a service that you could run on any mainframe, Unix, or Windows NT computer. At one point, main departments ran their own mail servers. The original design of the Email Alias system allowed a user to create an Alias that pointed to the computer under there desk. (So many of these machines were compromised by spammers that this became a violation of Yale security policy, but it was too late to change the Alias system).

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 unique 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.

Example of Problems

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 Alias MAILBOX value 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. So frequently enough we get:

...

ALIAS_NAME

...

MAILBOX

...

Type

...

john.doe

...

john.doe@bulldogs.yale.edu

...

Primary

...

johnathan.doe

...

johnathan.doe@bulldogs.yale.edu

...

Secondary

Google makes it unreasonably inefficient to query them and determine that “john.doe@yale.edu” and “johanthan.doe@yale.edu” are two names for the same Eliapps account, and we do not maintain a local table that remembers that we renamed the account. So from what information we have locally on which we can build code, there is no way to know that these are two entries for the same account. That means that the Secondary Alias will generate a Contact object. This is not a problem because this user probably only wants the current Primary alias listed in the directory and the only need for the secondary alias to to make sure that any mail for old addresses also gets delivered.

Technical Information

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.

Testing the Change

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 Alias Table

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 - The type can be Primary (value “person”) or Secondary (value “alias”). Each alias is owned by a Netid. A Netid can own one Primary alias, and that is the personal email account of that Netid. A Netid can own any number of Secondary Aliases, and an alias owned by one Netid can point to an email account owned by a different netid. It is fairly common for a person to own Secondary email aliases pointing to email accounts owned by one of his Dependent Netids, although this is a bad practice and the alias should be owned by the Dependent Netid. Occasionally one Netid will own an alias pointing to the personal mail account of another individual. . We do none of the preprocessing done by the Relays and send all the mail to destination 1 in the previous list.

To make this work, we require that Exchange Online be configured to do two things:

• The Mail Relays converted the “@yale.edu” address into a replacement “@connect.yale.edu” address by looking the original address up in the Alias Table data and replacing it with the MAILBOX. Exchange must be configured with all the “@yale.edu” email names (all the Alias Names in the Alias Table) that it does not already know about.

• Exchange automatically knows what to do with mail associated with a MAILBOX that ends in “@connect.yale.edu”. It must be configured with MAILBOX values for Eliapps (case 2 above) and the DNS name of email processing service machines (case 3 above).

Exchange does not need to distinguish Eliapps from “Case 3” addresses, but we choose to configure Eliapps accounts for students differently from the way we handle Case 3 addresses for other Yale business reasons.

Exchange requires us to configure all the information about addresses delivered to a personal birthright O365 mail account belonging to a Netid in the AD User object associated with that Netid. Specifically, all Email Addresses (including “@yale.edu” aliases) have to be in the list of Email Addresses in the ProxyAddresses property of that User object.

We have decided to provide Exchange with information about student personal birthright Eliapps mail accounts by putting the corresponding Email Address list in the same ProxyAddresses property of the AD User object for the student Netid. That is, Exchange Online did not REQUIRE us to do the same thing in exactly the same way for Google mail accounts, but Yale choose to do it because it is obvious and can be used to solve other problems associated with creating class mailing lists of enrolled students.

Everything else goes into a MailContact we create in AD and AzureAD to point all the remaining Yale Mail Aliases to their corresponding MAILBOX values.

Exchange Online Configuration

Every Email address Exchange Online is configured to process is a “MailRecipient”. Anyone with a Netid can find all the MailRecipients known to Exchange by installing the ExchangeOnlineManagement Powershell module and entering the Powershell statement:

$recipients=get-exorecipient -ResultSize unlimited -Properties ExternalEmailAddress

(If you don’t specify -ResultSize unlimited, you get the first 1000 objects. If you don’t specify -Properties ExternalEmailAddress then you don’t get the TargetAddress for Eliapps and other non-O365 mail accounts).

Now go do something else for a few minutes and when you come back $recipients will be a variable with about 106126 objects. These objects consist of MailUser, UserMailbox, MailContacts, and a list of special objects manually configured to Exchange (that we don’t have to worry about):

MailUniversalSecurityGroup
SharedMailbox
GroupMailbox
GuestMailUser
RoomMailbox
MailUniversalDistributionGroup
EquipmentMailbox
SchedulingMailbox
DynamicDistributionGroup
DiscoveryMailbox
PublicFolder
TeamMailbox

The reason why we don’t worry about these things is that they are manually created in response to a user request by the Help Desk or Email Management groups, are created in Exchange so Exchange knows how to deliver mail to them, and are not within the scope of identities managed by IAM. Currently they may have Email Aliases so that the Mail Relays know to forward mail to these destinations through Exchange Online, but if the mail went directly to Exchange Online without going through the Mail Relays that would be fine. Everything needed to deliver mail to these types of destinations is already correct and no data or procedures need to be changed or added.

So mostly we need to worry about the configuration that Exchange Online gets (from Azure AD and therefore from the Yale local AD) about:

• Personal O365 mail accounts

• Personal Eliapps mail accounts

• Shared Eliapps mail accounts (ends in “@bulldogs.yale.edu” but is not the personal birthright primary mail account of a student)

• Everything else (the “Case 3” stuff described above).

A personal O365 Email Account is a “UserMailbox” that Exchange Online connects to the Azure AD User object created from the Local AD User object created from the Netid. Exchange Online has an Inbox for this User, so all mail sent to an address associated (by a matching Email Address in the ProxyAddresses list) with this account is delivered locally to that Inbox.

External Mail (student Eliapps accounts and all the other stuff) cannot be configured in any User object that is a UserMailbox and is therefore connected to an Exchange Inbox. As long as the AD User object doesn’t have any O365 mail account attached to it, then the MAILBOX value (first.last@bulldogs.yale.edu or any other Mail Address of an external system) can be stored in the TargetAddress field of the User object and then, just as in the previous case) all the Email Addresses associated with that MAILBOX (first.last@yale.edu) can go in the ProxyAddresses list.

O365 mailboxes must be associated with a User object (that has a password and can login). External mail that comes into Exchange, is matched to a ProxyAddress, and is then forwarded to the TargetAddress does not require a User object and can also be configured in a Contact.

It is a business decision that we store external mail forwarding information in the User object of students with Eliapps mail accounts, but store all other external mail forwarding information in Contact objects.

The term “Contact” was created decades ago to represent an object normally put in a directory of external people that you frequently send mail to. However, these Contact objects are stored in a separate OU and are not visible to anyone. Unlike real Contacts used for the original purpose, they will not show up in Outlook as someone you can add to your “To:” list in a new Email message. They exist only to configure Exchange Online with the information it needs to map every Email Alias (every “@yale.edu” address) to some external destination.

There is the AD Name, the Exchange Name, and the Yale Name

Unfortunately, the same thing has different names in different contexts.

Contacts are created for Aliases that are not Exchange accounts and are not Primary Aliases of Eliapps students. It is not necessary to say what these accounts are, but in case you want to know, they are mostly:

• Eliapps accounts of people who also have an O365 mail account. These are mostly ITS people.

• Elilists (a type of mailing list managed by Eliapps instead of Exchange)

• Student groups (example: yale.spizzwinks@bulldogs.yale.edu)

• Departmental shared mailboxes (example: thechildlab@bulldogs.yale.edu)

• The 111 aliases of servicenow@bulldogs.yale.edu

• Mail for specific department servers (invest.yale.edu, aya.yale.edu)

• Everything else. Sometimes this is recognizable junk left over from machines that have not existed since 1995 (gopher.cis.yale.edu) but it is not necessary to clean this up and that is not part of this project.

Is It Right and Is It Complete

Yale has an Email Alias database table. It has an ALIAS_NAME column and a MAILBOX column. The ALIAS_NAME is unique (it appears only once in the table).

Every ALIAS_NAME has to be configured so that Exchange Online delivers mail to a local mailbox or else forwards mail to the correct external mailbox.

The first rule is that there should not be duplicate ProxyAddresses entries in more than one AD object. At this time, there are some duplicate ProxyAddresses for some SharedMailbox objects, but although incorrect this is not a problem that has to be solved in order to replace the Mail Relays since SharedMailboxes and all the other room and group resources manage by Exchange are already configured and removing the Mail Relays does not affect them. At some time in the future we should fix this.

Currently, if a secondary ALIAS_NAME is associated with an O365 personal mail account (that is, if the MAILBOX value is “netid@connect.yale.edu” or “first.last@connect.yale.edu”) and because of an error in our systems there is no ProxyAddress in the User object for that Netid matching the ALIAS_NAME, then Exchange sends the mail to the Mail Relays who look up the Alias in the table to find the MAILBOX and then send the mail back to Exchange with the MAILBOX information. Exchange delivers the mail correctly today but would not deliver it if the Mail Relays did not correct the configuration error. So we must make sure that all Aliases that match a “@connect.yale.edu” MAILBOX are in the ProxyAddresses list. This requires fixing or replacing the AD Updater process (work in progress now).

Students with a Primary Email Alias whose MAILBOX value ends in “@bulldogs.yale.edu” have an AD User object whose TargetAddress is the MAILBOX value and must have in the ProxyAddresses list all the ALIAS_NAMES that had the same MAILBOX value as the Primary Alias MAILBOX.

Once you remove the previous three cases (Aliases of SharedMailboxes, of Personal O365 accounts, or of Personal Eliapps accounts) then all remaining ALIAS_NAMES must be a ProxyAddress of a Contact whose TargetAddress is the MAILBOX value of that Alias. We could have created a Contact for every Alias (there is no requirement that TargetAddresses be unique) but it is convenient to collect all Aliases of the same MAILBOX in the same Contact.

At this point, every Alias has been mapped, and it should be mapped to its MAILBOX.

Up to this point, we have verified the configuration in terms of the local AD, which is the mechanism we have to configure Exchange Online. We can doublecheck the configuration from the Exchange Online point of view. This gives us a separate validation, but through a Read-Only mechanism. If we find a problem, we have to go back to the AD and figure out how to fix it.

Remember the Powershell command:

$recipients=get-exorecipient -ResultSize unlimited -Properties ExternalEmailAddress

This gives you a set of objects that includes all the recipients (SharedMailboxes, O365 accounts, Eliapps users, and Contacts) from the point of view of Exchange Online. Remember, we configure Local AD, which is then used to configure Azure AD, which is then used to configure Exchange Online. So now we skip to the final end result and see if the stuff we put in at the beginning ended up where we wanted it to be.

Each Recipient object has an EmailAddresses list. Every Email Alias should be found in one EmailAddresses entry of one Recipient object. The advantage of this check is that you don’t have to distinguish different types of users or mail or aliases. Every ALIAS_NAME should match one Recipient and the ExternalEmailAddress should match the MAILBOX value.

AD Management

Exchange Online requires that entries in any ProxyAddresses list must be unique. This process generates them from the ALIAS_NAME column of the Email Alias table which is constrained to be unique.

Because the Azure AD already has to be properly configured for O365 personal and shared mailbox accounts (or Exchange would not be able to deliver mail to these destinations), there is no need to make any changes for Email Alias Table entries that resolve to the “@connect.yale.edu” mail domain or any other domain that is an alias of Exchange itself.

For a year, we have been populating the TargetAddress field of the User object of 15000 current active or new students with an Eliapps mail account. There are approximately 1000 additional User objects for what appear to be former students who still have active mail whose User objects will now be populated.

Previously it was unnecessary to update the TargetAddress when a student changes their name. Technically this is still not necessary (because the old name remains an alias of the Eliapps account) but it seems to be better if this field is updated when the MAILBOX of the Primary Email Alias is changed. In addition, we were not previously adding Secondary Aliases to the ProxyAddresses list but will add them now. It may be unlikely that anyone will receive mail under an old name changed three years ago, but as long as the old name remains in the Alias Table, this project must configure Exchange Online to deliver mail to all currently valid Aliases no matter how unlikely it is that they are actually in use.

Therefore, there is a simple test to verify that the configuration required by this project is complete. Run through all the rows in the Email Alias Table (DIR_ONLINE_INFO). If the MAILBOX is one of the Exchange Online domains, ignore it. Otherwise, look for a ProxyAddresses entry matching the ALIAS_NAME value in some AD User or Contact object. The TargetAddress property of that object must match the MAILBOX value of the Alias.

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.

Fine Tuning

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.

Source of Problems (History)

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.

However, SMTP is a service that you could run on any mainframe, Unix, or Windows NT computer. At one point, main departments ran their own mail servers. The original design of the Email Alias system allowed a user to create an Alias that pointed to the computer under there desk. (So many of these machines were compromised by spammers that this became a violation of Yale security policy, but it was too late to change the Alias system).

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 unique 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.

Example of Problems

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 Alias MAILBOX value 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. So frequently enough we get:

Google makes it unreasonably inefficient to query them and determine that “john.doe@yale.edu” and “johanthan.doe@yale.edu” are two names for the same Eliapps account, and we do not maintain a local table that remembers that we renamed the account. So from what information we have locally on which we can build code, there is no way to know that these are two entries for the same account. That means that the Secondary Alias will generate a Contact object. This is not a problem because this user probably only wants the current Primary alias listed in the directory and the only need for the secondary alias to to make sure that any mail for old addresses also gets delivered.

There is an O365 version of this problem that does have to be solved somehow. If John Doe was an O365 user, there are about 150 case of:

If you read through the ADDailyUpdater source code you encounter a long comment beginning with “This is a hack for exchange and this is why...” followed by a long explanation that makes no sense at all. The upshot of this is that for 20 years we have added “first.last@connect.yale.edu” to the ProxyAddresses list for no apparent reason I can understand except to make it possible for a hundred or so Exchange users to have a working but inherently defective pair of MAILBOX values that point to the same O365 account using different values. Again, the problem here is that you cannot tell they are the same account and have to go in the same User object based only on the values in the Email Alias table. You have to go to the AD and search for the ProxyAddresses to see that both values are ProxyAddresses of the same User object. This is a data error and may have to be fixed because you cannot code around it without wasting too much time.

The Alias Table

ToDo Eventually: Some IAM tools display and operate only on the collection of aliases owned by the same Netid, but to migrate the Mail Relay function to Exchange, all Aliases pointing to a personal mailbox have to be listed in the ProxyAddresses list of the AD User object that owns the O365 mailbox or that points to the Eliapps account. Netid is significant for Primary Aliases, but Secondary aliases should be managed by the MAILBOX they point to and not the Netid that owns them. This will be a change to ODMT.

Shared Mailboxes: A shared mailbox has one or more configured account names. If any mail goes through Exchange addressed to one of these account names, it will be delivered to the mailbox. However, while the Mail Relays are running, if the shared mailbox is to have an “@yale.edu” email address, it needs a Email Alias for that name with a MAILBOX value that points to any domain associated with Exchange (typically “connect.yale.edu”). When the Mail Relays go away, the need for this alias goes away too. If all “@yale.edu” mail goes directly to Exchange, the Exchange configuration of the shared mailbox is enough to deliver the mail. However, for now it is a current bad practice to make the shared mailbox alias a Secondary owned by the Netid that generated the ticket to set the mailbox up, and then half of a better practice to create a Dependent Netid for the shared mailbox with a ProxyAddresses entry for the various names of the shared mailbox account. If this was done right, the Dependent Netid would also own the alias. Unfortunately, leaving the alias owned by the person causes trouble when eventually the owner leaves Yale without bothering to transfer ownership of the alias and Dependent Netid to someone else. It gets worse after this person is partially deprovisioned, which cleans up his personal mailbox but leaves the alias and dependent netid of a still active shared mailbox in a zombie state. Getting rid of the Mail Relays means we no longer need either the Aliases or the ProxyAddresses or the Dependent Netid. We still should know who is currently responsible for the Shared Mailbox, but that is an administrative problem and not a mail routing problemThe Help Desk and Email Managers create Shared Mailboxes for someone (the “owner”) by a sequence of steps.

They create a Dependent Netid for the owner.

They create an Alias for the shared mailbox, with a topical ALIAS_NAME like “blackhole.astronomy”, a MAILBOX that points to “dependentnetid@connect.yale.edu”, and then for some reason they assign ownership of the alias to the owner of the dependent netid instead of to the dependent netid itself.

Then they create the shared mailbox in Exchange.

Now a decade goes by and the owner leaves or retires without transferring either the Alias or the Dependent Netid to someone else. When his personal mailbox is deprovisioned, we do not know what to do with them and leave them attached to his now disabled User object.

At this point we have violated a bunch of original design points of the system, and various pieces of code do the wrong thing creating duplicate ProxyAddresses and other bad stuff.

To fix it, the Alias should be owned by the Dependent Netid. Then at least we would not be breaking the rules and the various programs would do the right thing. However, since this is a SharedMailbox even though we do a bunch of bad things to AD, the Exchange Online configuration continues to work correctly, so this is not the time to fix this.

Right the First Time: If mail accounts (Birthright and Manual, O365 and Eliapps) are generated with correct AD ProxyAddresses and TargetAddress values, and if they are updated when aliases change or an Eliapps account is renamed, then it should not be necessary to run the “AD Daily Updater” function. It was created to allow sloppy tools to do only part of the work and then go back once a day to fix the mistakes. We can do better than that.

...

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 DoDone: Populate the ProxyAddresses list of student Eliapps users with any Secondary Aliases that have a MAILBOX that points to their Eliapps account.

Work to DoDone: 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 DoDone: 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.

...