...
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 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.
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.
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.
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 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.
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.
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 problem.
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.
The Mail Relays
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:
| Code Block |
|---|
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 Relay computer programs are internally configured with files generated from the Alias Table. The program that generates these configuration files 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 in the Alias Table or the mail bounces as undeliverable. If an ALIAS_NAME is matched, then in that row the email domain (the part after “@”) in the MAILBOX value tells the Mail Relay where to forward the mail. The association of mail domain suffix values to the DNS name of one or more server machines is also published as MX records 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:
| Code Block |
|---|
connect.yale.edu MX preference = 10, mail exchanger = connect-yale-edu.mail.protection.outlook.com |
while the MX records for “bulldogs.yale.edu” are:
| Code Block |
|---|
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 |
However, the MAILBOX value of an entry in the Alias Table can contain a suffix that is not an MX record. In this case, the suffix is the name of a computer that runs some type of mail server software. Then the relay does an ordinary DNS lookup for the machine and forwards the mail to that computer. The problem of poorly managed mail server software (which could get compromised or abused by SPAM senders) was mostly addressed a decade ago, and we discourage these configurations, but this option was never removed from the Alias system.
Exchange Online
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 timeappropriate 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:
A MAILBOX value ending in “@connect.yale.edu” (or any other domain associated with O365 mail) is sent to the Microsoft Exchange Online service.
A MAILBOX value ending in “@bulldogs.yale.edu' is sent to Google.
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 replace the Mail Relays with Exchange Online, then we change the DNS server MX record so that the “@yale.edu” domain goes directly to Exchange. 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 three things:
While Exchange has always been configured with Primary Email Aliases for O365 accounts, it has not been configured with all the secondary aliases. Sometimes Exchange depended on the Mail Relays to translate Aliases it did not know into specific accounts. We must add all Aliases to the Exchange configuration.
Exchange was originally configured with only O365 accounts. A year ago we added the Primary Email Aliases of students with an Eliapps account. We need to add in the secondary aliases.
Every other Email Alias not configured in the previous two steps has to be configured to Exchange Online as a Contact object in AD. The Alias Name is a ProxyAddress and the MAILBOX is a Target Address.
To be sure everything is configured correctly, the following things must be true:
Every Email Alias of a personal O365 mail account must be in the ProxyAddresses list of the AD object associated with that account.
Every Email Alias of an Eliapps or other non-O365 mail account must be in the ProxyAddresses list of some AD object (User or Contact) whose TargetAddress is equal to the MAILBOX value of the Alias.
A given Alias must be unique in the AD (it must be in only one ProxyAddresses list of one object).
Every AD object (User or Contact) involved in Mail Routing must have a unique Mail Box value, which is the Primary Alias Name of User objects and the first ProxyAddress of Contacts.
We can run through the Email Alias table and make sure that every row is associated with some object and that the fields match up. However, fixing errors that exist in the Alias Table or existing AD objects is an ongoing function. Most of these errors are not related to the Mail Relay function and need not be fixed in order to retire the Mail Relays.
Exchange Online Configuration
The only way to know for sure if a user has an Exchange mail account or if an email address is known to it is to ask Exchange Online directly. The easiest way to do this is with Powershell.
Exchange has what it calls MailRecipients. There are three primary types of Recipients: O365 personal mail accounts (called a UserMailbox), external mail accounts (mostly Eliapps) that Exchange knows about, and “resources” like SharedMailboxes and Distribution Lists.
It turns out that anyone with a Netid can download code and ask Exchange to provide information on all Recpients:
$recipients=get-exorecipient -ResultSize unlimited -Properties ExternalEmailAddress
If you are patient, you will get back something around 106126 objects. There is an UserMailbox object for every Netid who has a personal O365 mail account. There are a set of more specific object types for the native Exchange objects created by Exchange administrators that receive mail but are not people:
MailUniversalSecurityGroup
SharedMailbox
GroupMailbox
GuestMailUser
RoomMailbox
MailUniversalDistributionGroup
EquipmentMailbox
SchedulingMailbox
DynamicDistributionGroup
DiscoveryMailbox
PublicFolder
TeamMailbox
Eliapps and other external (non-Exchange) mail addresses can be configured in a User object (a MailUser) or else a MailContact. Exchange doesn’t really care if you put external mail accounts in Users or Contacts, but a Yale we have decided to put aliases to personal student Eliapps mail accounts in the student’s User object, and put everything else in a Contact.
IAM has responsibility for User objects, whether the User has an O365 mail account or an Eliapps mail account. This information is affected by changes to the personal information that IAM manages. For example, when a student changes a First or Last name, this frequently changes the Primary Email Alias, and that in turn changes both the mail routing functions we are talking about here, but also the login values like UserPrincipalName presented by the user to get access to his O365 applications.
Contacts are generally created for accounts that are manually created on request. Sometimes they are associated with a specific identity of a real person known to IAM, but who for business reasons chooses not to use either the standard O365 or Eliapps mail systems. Sometimes there are special security requirements that require special accounts. Such a person will still have a Netid and an AD User object and a non-Mail O365 account. The Primary Email Alias will create a UPN and will be the “mail” attribute of the AD User object, so subject to privacy the user’s Email can appear in the directory. However, the routing information will be in a separate Contact object and we expect that the Contact object will be updated manually when the manually created Email account is manually changed. If these accounts are important enough to have their own mail system, IAM cannot assume they are subject to the ordinary behavior of student and regular staff accounts.
There is the AD Name, the Exchange Name, and the Yale Name
Unfortunately, the same thing has different names in different contexts.
AD | Exchange | Yale |
|---|---|---|
User | UserMailbox | O365 User |
User | MailUser | Eliapps User |
Contact | MailContact | other alias mapping |
ProxyAddresses | EmailAddresses | ALIAS_NAME@yale.edu |
TargetAddress | ExternalEmailAddress | MAILBOX |
MailNickName | Alias | Primary ALIAS_NAME (first.last) |
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:
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.
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:
ALIAS_NAME | MAILBOX | Type |
|---|---|---|
john.doe | jd1234@connect.yale.edu | Primary |
johnathan.doe | johnathon.doe@connect.yale.edu | Secondary |
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 strings. 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: The 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.
The Mail Relays
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:
| Code Block |
|---|
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 Relay computer programs are internally configured with files generated from the Alias Table. The program that generates these configuration files 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 in the Alias Table or the mail bounces as undeliverable. If an ALIAS_NAME is matched, then in that row the email domain (the part after “@”) in the MAILBOX value tells the Mail Relay where to forward the mail. The association of mail domain suffix values to the DNS name of one or more server machines is also published as MX records 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:
| Code Block |
|---|
connect.yale.edu MX preference = 10, mail exchanger = connect-yale-edu.mail.protection.outlook.com |
while the MX records for “bulldogs.yale.edu” are:
| Code Block |
|---|
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 |
However, the MAILBOX value of an entry in the Alias Table can contain a suffix that is not an MX record. In this case, the suffix is the name of a computer that runs some type of mail server software. Then the relay does an ordinary DNS lookup for the machine and forwards the mail to that computer. The problem of poorly managed mail server software (which could get compromised or abused by SPAM senders) was mostly addressed a decade ago, and we discourage these configurations, but this option was never removed from the Alias system.
Exchange Online
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 receive the original address in the mail without any translation through the Alias table. This means that Exchange has to understand “howard.gilbert@yale.edu”, while if the Mail Relays had preprocessed this alias they would have forwarded it as “gilbert@connect.yale.edu”.
In practice, this means that every Alias name has to be mapped to a Recipient (as explained above). In the past, some Aliases were not recognized by Exchange, so it would forward that message to the Mail Relays who in turn would translate the alias to a MAILBOX value and send it back. To get rid of the Mail Relays, Exchange has to recognize every alias immediately.
Done: Populate the ProxyAddresses list of student Eliapps users with any Secondary Aliases that have a MAILBOX that points to their Eliapps account.
Done: 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.
Done: 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.
ToDo: The Legacy ADDailyUpdater is deleting Secondary Email Aliases from the ProxyAddresses list. This must be fixed.
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.
People with an Eliapps Primary Alias and a Personal O365 Secondary Alias
A Personal O365 Email Alias has a MAILBOX of “netid@connect.yale.edu”. By a “personal” account, I am not including Secondary Aliases owned by a person that point to Email accounts owned by a Dependent Netid (typically used for shared mailboxes for groups or departments).
IAM code that only has access to databases, like the ACS1 tables, has to regard the MAILBOX in the alias as authoritative. A more direct check, but one available only to Powershell, is to call the ExchangeOnlineManagement Get-Recipient command to determine if a User object is a “UserMailbox” type of recipient. This directly determines if Exchange Online has an O365 mail account associated with the object. Without this check, there can be Aliases for a mail account that doesn’t exist, and mail accounts that in violation of Yale Policy have no Alias associated with them. These are errors that should be found and fixed manually. These errors arise from mismanagement of accounts by admins and not by normal changes to Identity status. The IAM functions in IIQ cannot be expected to fix them.
However, this type of error does not result in misdelivered Email because in neither case should anyone have an expectation that mail will be delivered to either a non-existent account or to an account with no Alias. There is some small chance of errors when someone who left Yale years ago and currently has such errors in their configuration were to try to return to the university and get a new mail account.
However, a small number of people violate Yale Policy by having a Primary Email Alias that points to Eliapps while also having an O365 mail account. This creates an ambiguity. Currently the Mail Relays deliver incoming mail to Eliapps, while mail sent from Exchange Online to the same address goes to the O365 mailbox.
However, the real problem is that this will try to generate duplicate ProxyAddresses. The Primary Email Alias (no matter what MAILBOX value it has) sets the UPN and MailNickName, and Exchange Online will always insert the UPN into the list of ProxyAddresses even if it is not in the Local AD list. Meanwhile, a secondary Eliapps account belonging to someone who owns an O365 mail account will generate a Contact object, and the ProxyAddresses list in the Contact will include the Aliases pointing to that account, and the first (primary) email address in that list will be the Primary Alias address.
Exchange Online will refuse to add the ProxyAddress to the second object it processes, which will generally be the Contact. The following list of Primary Aliases seem to have this problem, but only 5 of them represent current users. If nothing is done, then they will cease to get mail in their Eliapps account through the Primary Alias. All of them need to be rechecked before the Mail Relays are retired.
| Code Block |
|---|
ALIAS_NAME TYPE MAILBOX NETID
---------- ---- ------- -----
morrow.long person morrow.long@bulldogs.yale.edu long
jason.ignatius person jason.ignatius@bulldogs.yale.edu jsi3
kcm.campbell person kcm.campbell@bulldogs.yale.edu cjc243 (not a UserMailbox)
stuart.teal person stuart.teal@bulldogs.yale.edu sbt3
yanick-noelle.aigbedion person yanick-noelle.aigbedion@bulldogs.yale.edu yoa4 (not a UserMailbox)
samira.ataei person samira.ataei@bulldogs.yale.edu fa292
jeff.mandell person jeff.mandell@bulldogs.yale.edu jm3353
sam.seiff person sam.seiff@bulldogs.yale.edu sbs79 (delete alias samantha.seiff)
bernardo.eilerttrevisan person bernardo.eilerttrevisan@bulldogs.yale.edu be244 (not a UserMailbox)
elena.adasheva-klein person elena.adasheva-klein@bulldogs.yale.edu ea479 (not a UserMailbox)
georgios.vasilopoulos person georgios.vasilopoulos@bulldogs.yale.edu vg284 (not a UserMailbox) |
People with Eliapps Primary Alias, No O365 Secondary Alias, but are “UserMailbox” Recipents (have a mailbox) in Exchange
Exchange reported on the day the list was created that the following users have an O365 mailbox (their Recipient Type was “UserMailbox”). However, no Alias points to this mailbox. The Alias instead points to their Eliapps account.
Lets take cav7. The Primary Alias is claudia.villano with a MAILBOX of claudia.villano@bulldogs.yale.edu. Current affiliation is Staff, but you only get Eliapps if you were a student, so this is a former student who became Staff and was given an O365 account manually but the alias was never changed. Delivery here is the same as for Morrow. The Relays follow the Alias and deliver external mail to Eliapps, while O365 discovers that SMTP:claudia.villano@yale.edu is a ProxyAddress of a UserMailbox Recipient and delvers mail with the same address to O365. When the Mail Relays go away, external mail will start being delivered to O365.
This list is a lot longer than the five people with aliases, and each account has to be examined manually if we are to provide exact notification. Alternately, we could just bulk mail all the @bulldogs.yale.edu mailbox addresses in the list and tell the user that after the Mail Relay retirement date, all their mail will start arriving in O365 and if they don’t want that they should contact the Help Desk to delete their O365 account.
| Code Block |
|---|
ALIAS_NAME TYPE MAILBOX NETID
---------- ---- ------- -----
travis.zadeh person travis.zadeh@bulldogs.yale.edu tz237
thomas.langford person thomas.langford@bulldogs.yale.edu tl397
ben.kiernan person ben.kiernan@bulldogs.yale.edu magpie
carol.hwang person carol.hwang@bulldogs.yale.edu chwang
cynthia.farrar person cynthia.farrar@bulldogs.yale.edu cfarrar
albert.laguna person albert.laguna@bulldogs.yale.edu al757
wayne.zhang person wayne.zhang@bulldogs.yale.edu wwz3
mark.gerstein person mark.gerstein@bulldogs.yale.edu mg269
richard.lalli person richard.lalli@bulldogs.yale.edu rl3
ivan.szelenyi person ivan.szelenyi@bulldogs.yale.edu is66
kusal.samarasinghe person kusal.samarasinghe@bulldogs.yale.edu kts34
victoria.misenti person victoria.misenti@bulldogs.yale.edu vlg8
william.hawkins person william.hawkins@bulldogs.yale.edu wbh24
richard.walser person richard.walser@bulldogs.yale.edu rwalser
keith.corbino person keith.corbino@bulldogs.yale.edu kac64
jesus.yanez person jesus.yanez@bulldogs.yale.edu jy384
yong.xiong person yong.xiong@bulldogs.yale.edu yx44
wasim.sayyad person wasim.sayyad@bulldogs.yale.edu was35
rohan.gurram person rohan.gurram@bulldogs.yale.edu rkg33
nirag.kadakia person nirag.kadakia@bulldogs.yale.edu nk479
aman.khanuja person aman.khanuja@bulldogs.yale.edu ak2385
nicholas.ryan person nicholas.ryan@bulldogs.yale.edu njr33
j.zhang person j.zhang@bulldogs.yale.edu jz435
claudia.villano person claudia.villano@bulldogs.yale.edu cav7
kyle.vanderwerf person kyle.vanderwerf@bulldogs.yale.edu krv8
paul.wolfram person paul.wolfram@bulldogs.yale.edu pw379
kas.tebbetts person kas.tebbetts@bulldogs.yale.edu kt522
soumya.james person soumya.james@bulldogs.yale.edu sj484
megan.eckerle person megan.eckerle@bulldogs.yale.edu mme28
ronald.tricoche person ronald.tricoche@bulldogs.yale.edu rt347
craig.luekens person craig.luekens@bulldogs.yale.edu cal65
andrea.darif person andrea.darif@bulldogs.yale.edu ad566
saul.jaime-figueroa person saul.jaime-figueroa@bulldogs.yale.edu sj396
omer.mano person omer.mano@bulldogs.yale.edu om55
xinglin.lu person xinglin.lu@bulldogs.yale.edu xl294
mahmut.demir person mahmut.demir@bulldogs.yale.edu md762
andrew.currie person andrew.currie@bulldogs.yale.edu ajc82
libby.didomizio person libby.didomizio@bulldogs.yale.edu eed37
nathan.chang person nathan.chang@bulldogs.yale.edu nac53
ting.zhou person ting.zhou@bulldogs.yale.edu tz232
debra.houle person debra.houle@bulldogs.yale.edu dh462
daifeng.wang person daifeng.wang@bulldogs.yale.edu dw396
yotam.hadar person yotam.hadar@bulldogs.yale.edu ymh4
paul.berkowitz person paul.berkowitz@bulldogs.yale.edu phb8
fatih.celikbas person fatih.celikbas@bulldogs.yale.edu fc359
luyao.jiang person luyao.jiang@bulldogs.yale.edu lj275
michelle.yuen person michelle.yuen@bulldogs.yale.edu mcy6
jonathan.warrell person jonathan.warrell@bulldogs.yale.edu jw2394
timur.galeev person timur.galeev@bulldogs.yale.edu tg397
sara.smith person sara.smith@bulldogs.yale.edu sks25
melissa.lu person melissa.lu@bulldogs.yale.edu ml2453
jaeeun.song person jaeeun.song@bulldogs.yale.edu js2894
vishal.patel person vishal.patel@bulldogs.yale.edu vp276
wenjun.hu person wenjun.hu@bulldogs.yale.edu wh288
j.zhuang person j.zhuang@bulldogs.yale.edu jz472
tianliuyun.gao person tianliuyun.gao@bulldogs.yale.edu tg344
nat.irwin person nat.irwin@bulldogs.yale.edu nsi4
declan.clarke person declan.clarke@bulldogs.yale.edu dc547
arthur.lau person arthur.lau@bulldogs.yale.edu ajl74
kevin.lopez person kevin.lopez@bulldogs.yale.edu kl533
raymond.simpson person raymond.simpson@bulldogs.yale.edu rgs45
roger.desravines person roger.desravines@bulldogs.yale.edu rd557
rachel.renne person rachel.renne@bulldogs.yale.edu rr687
claudia.valeggia person claudia.valeggia@bulldogs.yale.edu crv7
eduardo.fernandez-duque person eduardo.fernandez-duque@bulldogs.yale.edu ef344
farren.isaacs person farren.isaacs@bulldogs.yale.edu fji2
sahand.negahban person sahand.negahban@bulldogs.yale.edu snn7
karihenkelmann.keyl person karihenkelmann.keyl@bulldogs.yale.edu kk544
john.henderson person john.henderson@bulldogs.yale.edu jh925
antonio.fonseca person antonio.fonseca@bulldogs.yale.edu ahf38
xing.wu person xing.wu@bulldogs.yale.edu xw358
tianxiao.li person tianxiao.li@bulldogs.yale.edu tl444
clinton.wang person clinton.wang@bulldogs.yale.edu cjw46
hatice.erten person hatice.erten@bulldogs.yale.edu hne2
lewis.golove person lewis.golove@bulldogs.yale.edu lg432
laurel.german person laurel.german@bulldogs.yale.edu lag48
mela.toro person mela.toro@bulldogs.yale.edu at549
andres.munozrojas person andres.munozrojas@bulldogs.yale.edu arm92
alberto.urcia person alberto.urcia@bulldogs.yale.edu au45
clare.staib-kaufman person clare.staib-kaufman@bulldogs.yale.edu cs2528
damon.clark person damon.clark@bulldogs.yale.edu dac77
jennifer.wu person jennifer.wu@bulldogs.yale.edu jw2282
jennifer.raab person jennifer.raab@bulldogs.yale.edu jcr42
marcus.alexander person marcus.alexander@bulldogs.yale.edu mam96
noah.planavsky person noah.planavsky@bulldogs.yale.edu np363
dhanusha.nalawansha person dhanusha.nalawansha@bulldogs.yale.edu dan44
leonidas.salichos person leonidas.salichos@bulldogs.yale.edu ls926
isaac.nakhimovsky person isaac.nakhimovsky@bulldogs.yale.edu isn2
chitra.ramalingam person chitra.ramalingam@bulldogs.yale.edu cr537
robyn.creswell person robyn.creswell@bulldogs.yale.edu rc698
basile.njei person basile.njei@bulldogs.yale.edu bn72
jacqueline.kisa person jacqueline.kisa@bulldogs.yale.edu jkk35
benjamin.schwartz person benjamin.schwartz@bulldogs.yale.edu bs843
shaoke.lou person shaoke.lou@bulldogs.yale.edu sl2373
steven.chou person steven.chou@bulldogs.yale.edu sc2493
sarah.luckart person sarah.luckart@bulldogs.yale.edu srl54
jacob.e.miller person jacob.e.miller@bulldogs.yale.edu jem263
joseph.goode person joseph.goode@bulldogs.yale.edu jbg66
ran.gu person ran.gu@bulldogs.yale.edu rg684
marilyn.mossien person marilyn.mossien@bulldogs.yale.edu mrm95
nikhil.malvankar person nikhil.malvankar@bulldogs.yale.edu nm563
terence.renaud person terence.renaud@bulldogs.yale.edu tr369
test2.infoed.ti7 person test2.infoed.ti7@bulldogs.yale.edu ti7
david.breslow person david.breslow@bulldogs.yale.edu dkb27
yannick.jacob person yannick.jacob@bulldogs.yale.edu yj242
susan.choi person susan.choi@bulldogs.yale.edu sc385
alyssa.dechiaro person alyssa.dechiaro@bulldogs.yale.edu ad949
imad.rizvi person ir99@bulldogs.yale.edu ir99
yat.wong person yat.wong@bulldogs.yale.edu yw629
xinyi.zhang.xz476 person xinyi.zhang.xz476@bulldogs.yale.edu xz476
rachael.roettenbacher person rachael.roettenbacher@bulldogs.yale.edu rmr79
killian.mcloughlin person killian.mcloughlin@bulldogs.yale.edu km2345
jennifer.nulsen person jennifer.nulsen@bulldogs.yale.edu jn535
a.scott person a.scott@bulldogs.yale.edu aas228
chenziyi.mi person chenziyi.mi@bulldogs.yale.edu cm2523
sebastian.lordadumont person sebastian.lordadumont@bulldogs.yale.edu ssl57
haoran.cao person haoran.cao@bulldogs.yale.edu hc685
jack.berry person jack.berry@bulldogs.yale.edu jrb248
mark.lisi person mark.lisi@bulldogs.yale.edu ml2622
brian.koopman person brian.koopman@bulldogs.yale.edu bjk49
avi.cohen person avi.cohen@bulldogs.yale.edu ajc259
ishan.negi person ishan.negi@bulldogs.yale.edu in49
yinan.chen person yinan.chen@bulldogs.yale.edu yc778
pranavateja.surukuchi person pranavateja.surukuchi@bulldogs.yale.edu ps938
yue.hu person yue.hu@bulldogs.yale.edu yh567
gabe.petrov person gabe.petrov@bulldogs.yale.edu gpp8
haven.herrin person haven.herrin@bulldogs.yale.edu hmh47
yixuan.tan person yixuan.tan@bulldogs.yale.edu yt355
yakun.zhou person yakun.zhou@bulldogs.yale.edu yz883
jacques.saarbach person jacques.saarbach@bulldogs.yale.edu js3973
emma.mckinney person emma.mckinney@bulldogs.yale.edu em873
michael.rader person michael.rader@bulldogs.yale.edu mr2542
ashley.arthur person ashley.arthur@bulldogs.yale.edu ala72
andy.knauer person ajk83@bulldogs.yale.edu ajk83
xiangyu.zhang person xiangyu.zhang@bulldogs.yale.edu xz527
ben.crair person ben.crair@bulldogs.yale.edu bec32
nicolas.maffey person nicolas.maffey@bulldogs.yale.edu nam87
charalampos.papamanthou person charalampos.papamanthou@bulldogs.yale.edu cp936
xuqiang.qin person xuqiang.qin@bulldogs.yale.edu xq43
sunny.yang person sunny.yang@bulldogs.yale.edu gy88
alison.sweeney person alison.sweeney@bulldogs.yale.edu as3822
chungsuk.choi person chungsuk.choi@bulldogs.yale.edu cc2858
makenna.hamilton person makenna.hamilton@bulldogs.yale.edu mh2539
chaofan.xu person chaofan.xu@bulldogs.yale.edu cx78
david.goerger person david.goerger@bulldogs.yale.edu deg38
ruifeng.sun person ruifeng.sun@bulldogs.yale.edu rs2623
juan.gambetta person juan.gambetta@bulldogs.yale.edu jpg68
caroline.chen person caroline.chen@bulldogs.yale.edu cc2766
junqi.wang person junqi.wang@bulldogs.yale.edu jw2675
fl428 person fl428@bulldogs.yale.edu fl428
ar2483 person ar2483@bulldogs.yale.edu ar2483 |
AD Daily Updater Bug Entries
The Legacy ADDailyUpdater code adds two ProxyAddresses “netid@connect.yale.edu” and “first.last@connect.yale.edu” to the 17,000 student Primary Eliapps User objects. These entries are misleading when viewed, but they have no affect on any actual mail processing and do not have to be fixed.
Exchange Online first looks at the type of User before looking at the ProxyAddresses. It discovers these users are of type “MailUser” (meaning they have no O365 mailbox and so mail passes through Exchange and is forwarded to what Exchange calls the ExternalEmailAddress (called a TargetAddress in AD).
This only confuses administrators and any Powershell script that makes decisions based on the presence of a “connect.yale.edu” ProxyAddress in the AD. We have had this problem for over a month and no ITS staff have noticed and complained, so it doesn’t have to be fixed now.
This cannot be fixed while the Legacy ADDailyUpdater is running because it will just put the bad data back in. After it is fixed or retired, a one time Powershell script should delete all these unnecessary ProxyAddresses.