...
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”. This does not include people with a Primary Eliapps Alias who also are the owners of an Alias to an Exchange account belonging to a group or dependent Netid (although such Aliases should be owned by the Dependent Netid). As an additional check, their Exchange Online status will be “UserMailbox” if they really have an O365 mail account, but if not then the alias “points” to an non-existant O365 mailbox.
When a Secondary Alias has a MAILBOX that appears to be O365 (“netid@connect.yale.edu”) but there is no actual O365 mail account (so the Exchange status is MailUser instead of UserMailbox), then Exchange is not confused by the “connect.yale.edu” mail domain. We administrators use this domain exclusively for O365 mail, and Exchange knows that it is a mail domain that it handles, but it still delivers mail based on the type of Recipient and not the domain name. Since this Recipient is a MailUser with an ExternalEmailAddress ending in “@bulldogs.yale.edu”, Exchange will correctly forward this mail to the Eliapps account even through the MAILBOX is “connect” instead of “bulldogs”. While it would be better to fix the MAILBOX, we should not Delete the Alias thinking that it “points to a non-existant O365 account”. While it looks that way to people, the algorithm delivers mail to the Alias just as if it were a proper Eliapps alias.
Under Yale Policy, an O365 Mail account should always be primary, but that policy is not enforced. Because of this configuration and the Mail Relays, mail sent to “morrow.long@yale.edu” from any O365 user goes to his O365 inbox, while mail from outside Yale or from Eliapps goes through the Relays to his Eliapps mailbox. When the Mail Relays go awayare replaced by Exchange Online, all mail will be delivered to O365. These users should be notified of the change.
| 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 bernardo.eilerttrevisan person bernardo.eilerttrevisan@bulldogs.yale.edu be244 elena.adasheva-klein person elena.adasheva-klein@bulldogs.yale.edu ea479 georgios.vasilopoulos person georgios.vasilopoulos@bulldogs.yale.edu vg284 |
...