Email Domain mapped to Network Service
When an Email client program or service sends mail, it collects the list of email domain names (the part of each destination email address following the “@”). It does a DNS lookup of the domain name requesting an “MX record” response. You can do the same lookup yourself with a command:
>nslookup > set type=mx > yale.edu Non-authoritative answer: yale.edu MX preference = 10, mail exchanger = yale-edu.mail.protection.outlook.com
The yale.edu domain is associated with a network destination of yale-edu.mail.protection.outlook.com which is a Microsoft address. A copy of the email is sent to that network address.
While individuals can subscribe to Office 365 with individual, family, or small business accounts, large enterprises like Yale contract for a single bulk service. We have a “tenant” account associated with our mail domain, and we manage the creation of individual accounts within that tenant. We have a similar arrangement with Google.
The user sees the Microsoft mail service as Office 365 or Outlook, just as they see the Google service as Gmail. The yale-edu.mail.protection.outlook.com address is associated with a network service technically known as ExchangeOnline (EXO). Yale defines Email addresses for each user in its own yale.edu mail domain, while Microsoft also assigns an address in its own Microsoft mail domain (@mail.onmicrosoft.com) for the same account.
Although most mail goes to “@yale.edu”, Yale also owns a number of other mail domain names. Some have been created for special uses, and some are historical artifacts. We do not create separate Microsoft tenants for them, so our one tenant treats them all as alternate domains for the same pool of accounts.
An administrator can list all of them:
> get-accepteddomain Name DomainName DomainType Default ---- ---------- ---------- ------- yale.edu yale.edu InternalRelay True net.yale.edu net.yale.edu InternalRelay False cs.yale.edu cs.yale.edu InternalRelay False yaleedu.mail.onmicrosoft.com yaleedu.mail.onmicrosoft.com Authoritative False testayalists.yale.edu testayalists.yale.edu InternalRelay False dc4-uscn84162-yale.teamsna.pu… dc4-uscn84162-yale.teamsna.pu… Authoritative False yaleedu.onmicrosoft.com yaleedu.onmicrosoft.com Authoritative False sv2-uscn84162-yale.teamsna.pu… sv2-uscn84162-yale.teamsna.pu… Authoritative False lists.architecture.yale.edu lists.architecture.yale.edu InternalRelay False mail.som.yale.edu mail.som.yale.edu Authoritative False sysc.eng.yale.edu sysc.eng.yale.edu InternalRelay False som.yale.edu som.yale.edu Authoritative False yu.yale.edu yu.yale.edu Authoritative False lotis.yale.edu lotis.yale.edu Authoritative False YaleMedicine.org YaleMedicine.org Authoritative False eps.yale.edu eps.yale.edu Authoritative False gruber.yale.edu gruber.yale.edu Authoritative False advancedmanagement.net advancedmanagement.net Authoritative False detroit.expectwithme.org detroit.expectwithme.org Authoritative False vanderbilt.expectwithme.org vanderbilt.expectwithme.org Authoritative False marchofdimes.expectwithme.org marchofdimes.expectwithme.org Authoritative False expectwithme.org expectwithme.org Authoritative False alerts.yale.edu alerts.yale.edu Authoritative False haskinslabs.org haskinslabs.org Authoritative False globalnetwork.io globalnetwork.io Authoritative False lso.yale.edu lso.yale.edu Authoritative False inclusivegrowthnh.org inclusivegrowthnh.org Authoritative False wu.its.yale.edu wu.its.yale.edu InternalRelay False inclusivegrowthnewhaven.org inclusivegrowthnewhaven.org Authoritative False collaborate.library.yale.edu collaborate.library.yale.edu InternalRelay False geology.yale.edu geology.yale.edu InternalRelay False cowgill.ling.yale.edu cowgill.ling.yale.edu InternalRelay False mysite.library.yale.edu mysite.library.yale.edu InternalRelay False earth.geology.yale.edu earth.geology.yale.edu InternalRelay False ayalists.yale.edu ayalists.yale.edu InternalRelay False gcp.yale.edu gcp.yale.edu Authoritative False azure.yale.edu azure.yale.edu Authoritative False analytics.yale.edu analytics.yale.edu Authoritative False connect.yale.edu connect.yale.edu InternalRelay False aws.yale.edu aws.yale.edu Authoritative False canvas.yale.edu canvas.yale.edu Authoritative False yge.yale.edu yge.yale.edu Authoritative False haskins.yale.edu haskins.yale.edu Authoritative False atp.yale.edu atp.yale.edu InternalRelay False mailman.yale.edu mailman.yale.edu InternalRelay False classesv2.yale.edu classesv2.yale.edu InternalRelay False
When the DomainType is “Authoritative”, then mail sent to that domain must be delivered to an account in the yaleedu tenant. For DomainType “InternalRelay” the mail may end up in a mailbox in the yaleedu tenance of EXO, but it may also be forwarded to an external mail account also owned by Yale, but on a different server. For example, the mail domain “@yale.edu” receives mail for both O365 and Google/Eliapps mail users, so ExchangeOnline has to look up the account name and decide if the mailbox is local or if the mail should be forwarded on to Google.
Mail may be processed by one or more filters to block phishing, spam, malware, or other undesirable content. This is outside the scope of this document.
Recipients (Mailboxes or forwarding addresses)
Some email addresses are configured in ExchangeOnline by an administrator. Generally EXO refers to such addresses and any mailboxes associated with them as types of Recipients (the generic term for a mail address that EXO will process).
Distribution Groups logically replace a single email address with a set of configured member email addresses, and then the mail has to be delivered or forwarded to each member.
A Shared Mailbox has a single local mail account that can be read by a group of configured owners. There are mailboxes associated with rooms and equipment that can be reserved.
There are also Aliases defined in Exchange that receive mail addressed to an “@yale.edu” account and forward it to another Email address in some other system.
These administratively defined accounts exist only in ExchangeOnline. They are not necessarily Identities and are not associated with AD or AzureAD/EntraID. However, things would get confusing if any of these addresses ended up as a duplicate of one generated by IAM following standard Yale procedures. Therefore, any Email account name that consists of no more than 14 alphameric characters overlaps the Netid space and cannot be created unless a Dependent Netid is also created to reserve that name. Other names should be registered as a Secondary Email Alias owned by someone. Reserving Netids and Aliases is part of the normal procedure followed by the Help Desk and Mail Admins.
There are three types of Recipients associated with Identities. Their EXO names are:
UserMailbox - This is a Yale Exchange (“O365”) mail account connected to an AD User Object. The Mailbox is created after the AzureAD Object associated with the AD object is assigned an “exchange” License.
MailUser - Students with an Eliapps (Google) mail account are MailUsers. They have an AD User object that does not have an “exchange” license, but has what EXO calls a RemoteEmailAddress (also known in AD as the “targetAddress” LDAP property). When EXO receives mail and the address resolves to this type of AD User, then it substitutes the RemoteEmailAddress for the original address and starts over with this substitute address. Because ExchangeOnline currently receives and processes all incoming mail, students with an Eliapps mail account have a RemoteEmailAddress/targetAddress value of “SMTP:PrimaryEmailAlias@bulldogs.yale.edu”
MailContact - This is an AD Contact object with a targetAddress property. A Contact is not a user and cannot login, but the targetAddress provides an alias destination that can forward mail sent to an “@yale.edu” address to an external mail system. Currently ITS staff who have both Microsoft and Eliapps mail accounts have an AD User object associated with their Exchange account and a Contact object that points to their Eliapps account. Contacts are manually created by an Admin.
These three Recipient types differ in the type of AD Object (User or Contact) and the disposition of the email (deliver to a local mailbox or forward to a substitute email address). An AD User Object without an exchange license or a targetAddress and a Contact Object without a targetAddress are not Recipients and can be ignored by Exchange.
Configure Email Addresses to Recipients
The Mail Admins manage the objects that are defined in ExchangeOnline (Shared mailboxes, rooms, equipment, distribution lists, administrative aliases) and assign them an Email Address. Someone authorized to create objects in AD can create Contacts, and if they are in a container or OU that synchronizes to AzureAd, then any Contact with a targetAddress will create a MailContact in EXO. These are manual one-time operations.
The dynamic part of Email Address assignment responds to changes in the Yale Email Alias database table. These changes may be made by Help Desk or DSP use of the ODMT tool. Any addition or modification to the Aliases implicitly creates or changes an “@yale.edu” Email Address that has to be reflected to ExchangeOnline by changes made to an AD User object that is subsequently synchronized to AzureAD.
During the synchronization, Microsoft detects changes to attributes important to ExchangeOnline:
mailNickName
proxyAddresses
targetAddress
ExchangeOnline is called to approve these changes and to update its own tables.
There are three views of this configuration.
We can look at the Email Aliases and then describe the way that changes to the Aliases generate changes in these fields of AD that in turn affect EXO.
Alternately we can continue viewing things from the way that ExchangeOnline processes incoming mail, and then work back from that to the way that Aliases must be defined in order for inbound Mail processing to work correctly.
In the middle we have the IIQ Email Routing task that reads data from views in the Email Alias table and generates changes to the AD properties.
ExchangeOnline processing of Received Mail
ExchangeOnline receives a piece of mail with a set of destination Email Addresses that it is supposed to process. Normally these are addresses in the “@yale.edu” domain which is the only mail domain we consider when designing our IAM systems.
There must be an EXO internal table of Email Addresses. Each such address is associated with a Recipient. If the Recipient is one of the administratively defined types (like shared mailbox, room, or distribution list), then that is up to the mail admins and outside our scope of concern.
Each Recipient has a list of EmailAddresses for which it should receive mail. Recipients have more than one EmaiAddress, but each EmailAddress can only be associated with one Recipient. EXO will reject any attempt to add an entry to the EmailAddresses list of an object if that entry is a duplicate of an existing EmailAddress in another object.
The Local AD on campus has User objects that have a proxyAddresses property that contains a list of Email Addresses that are supposed to be associated with this User, However, the Local AD is under our control and does not know about ExchangeOnline admin objects. The Local AD was not as careful as EXO about rejecting duplicate entries.
Therefore, proxyAddresses can at best be described as a suggested list of Email Addresses that EXO should add to the list of EmailAddresses for the Recipient associated with this User, but EXO will check the list more carefully when the AD is synchronized and will reject duplicates we did not catch. It will also add entries that are missing.
Notably, EXO believes that the UserPrincipalName (UPN) must be an EmailAddress of any UserMailbox and will add it to the EmailAddresses even if it is not in the proxyAddresses list. IAM is aware of this behavior and has programmed the IIQ AD Update function to populate proxyAddresses with all the values that EXO requires, so the Local AD should always match the cloud.
Yale Email Aliases to ProxyAddresses
The dynamic part of the proxyAddresses/EmailAddresses list is associated with the Yale Email Alias system (the ODMT tool, the Manageusers page, and IIQ) represented by the SMART.DIR_ONLINE_INFO table. This system was created when individual departments at Yale each had their own mail servers, some on Unix computers and some on Windows NT Servers. It is still useful today while we have both Microsoft and Google cloud based mail systems.
Since it was originally designed to route all the mail received by Yale to many different servers, the Email Alias system is designed like the ExchangeOnline mail routing function. Each ALIASNAME is an EmailAddress, but without the implied “@yale.edu” suffix (although to waste some space, the full “AliasName@yale.edu” is also in the table in the EMAIL_TO column. Since the Alias system has no mail servers of its own, each Email Alias is mapped to an ExternalEmailAddress contained in the MAILBOX column.
Three times a day the Email Routing task of the Email Provisioning IIQ reads data from views of this table, generates the proxyAddresses lists for all the active Identities at Yale, compares the generated proxyAddresses to the list in the Local AD, and updates the Local AD if there have been any changes. That in turn is synchronized out to AzureAD.
Part of this processing incorporated into the database views is the distinction between how Exchange and Google Email accounts are represented in AD.
By Yale convention, a Microsoft mail account in the Alias table has a MAILBOX value of “Netid@connect.yale.edu”. A Google email account has a MAILBOX of “AliasName@bulldogs.yale.edu”.
While the AliasName is the unique key that one would lookup to decide where to deliver a piece of mail, to build a proxyAddresses list we need to gather together all the Email Aliases that have the same MAILBOX value. That MAILBOX value then is mapped to a Netid that identifies an AD User Object. Each ALIASNAME is then converted to an Email Address that must be in the proxyAddresses list of the User Object.
If a user simply adds a new Secondary Email Alias, then just that one new Email Address will be added to the proxyAddresses list. If the user changes the Primary Email Alias, then the prefix of the old primary address has to be changed from “SMTP:” to “smtp:” and the prefix of the new primary address has to be changed from “smtp:” to “SMTP:”.
The Primary Email Alias also sets the value of the mailNickName field in AD which is managed by the Mail Routing Task in the Email Provisioning IIQ. It also determines the UserPrincipalName (UPN) and “mail” attribute of the User object, but those are set in the Identity Management IIQ. Whatever view that ExchangeOnline may have that the UPN and “mail” attribute must be in the EmailAddresses list is addressed because a Yale that list and those attributes all come from the same source and must have the same value (eventually, although for a few hours after a change they may be updated at different times).
Separate from the Email Alias table, there are some entries added to the proxyAddresses list by IIQ because they should be there:
The address “smtp:netid@yale.edu” is usually set, but we do not recommend using it in mail unless the netid is also the Email Alias.
The “smtp:netid@connect.yale.edu” is added for Microsoft accounts because it is a Yale-only convention and there is no other way to get Exchange to do the right thing with that address.
The “smtp:aliasname@mail.onmicrosoft.com” native Microsoft address if necessary because EXO will add it to the EmailAddresses list in the cloud and we don’t want the LocalAD and AzureAD to have differences.
The native Eliapps mail address “aliasname@bulldogs.yale.edu” is not added to the proxyAddress list because the bulldogs.yale.edu Mail Domain has an MX record pointing directly to Google and external mail for such an address does not pass through EXO. When an Outlook user sends mail to such an address, Exchange has no special outbound processing, looks up the MX record as if it were any non-Yale address, and sends the mail to Google.
However, “SMTP:aliasname@bulldogs.yale.edu” is added to the targetAddress property of the AD User object for Eliapps mail owners. Therefore, external mail for “aliasname@yale.edu” is received by ExchangeOnline, is processed by mail filters, and is then forwarded to Google using the targetAddress/ExternalEmailAddress because Eliapps accounts are MailUser Recipients.
The MailNickName
Once upon a time each department could have its own local mail server. With a small number of users, it made sense to address mail “to: Fred” and then the mail would go to user “Fred” in the department.
PC Mail became Exchange, then Exchange because an Enterprise Cloud Service. However, to maintain compatibility Microsoft preserves the ability to give a short MailNickName to every user. The MailNickName is a required field, so if you have a hundred thousand users, the unique mail nickname can no longer be short. We set the MailNickName field to the Primary AliasName, which is guaranteed to be unique.