...
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 that an O365 mail account be configured in a single User object. Every personal O365 mail account belonging is attached to a Netid in the AD User object associated with for that Netid. Specifically, all Email Addresses (including “@yale.edu” aliases) so all the aliases pointing to that account have to be in added to the ProxyAddresses list of Email Addresses in the ProxyAddresses property of that User objectthat User Object. The Primary Email Alias is there already. We have to make sure that all secondary aliases that have the same MAILBOX value are also in the list, realizing that it is possible at Yale for an alias to one personal Email account to be “owned” by someone other than the person who owns the account the alias points to.
We have decided to provide Exchange with information about configure student personal birthright Eliapps mail accounts by putting the corresponding Email Address list in the same ProxyAddresses property of the AD User object for of 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 studentsAgain, all the secondary aliases that point to the account have to go in the ProxyAddresses list of the student who owns the mail, but since this is an external account we also have to store the MAILBOX value in the TargetAddress field of the User object.
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.
...
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 valuesstrings. 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.
...