...
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”).
...
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.
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.
The Alias Table
...
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:
...
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 - Each person has one Primary Alias and may have additional Secondary Aliases. Every Alias has a Netid that owns it. The Primary Alias points to the personal mailbox of the owning Netid, and any Secondary aliases that point to the same mailbox are regarded as alternate names for the personal account. When the Primary MAILBOX is an Eliapps account (ends in “@bulldogs.yale.edu”) that is the only way to find the Eliapps account for that netid (because the Eliapps account does not have the netid as any part of the account name or directory contents). When a Secondary Alias does not point to the Primary MAILBOX, we really don’t know what it is used for. Sometimes it is a mail account of a dependent Netid, and in a few cases it is the personal mailbox of someone else. Sometimes it is the name of an Exchange object (a shared mailbox, distribution list, shared calendar, etc.).
Observation: After the Mail Relays are retired, the only purpose of an Email Aliases for Exchange Objects (shared mailboxes, distribution lists, etc.) is to reserve the name and mark it “in use”. No generated configuration will be needed for these objects to receive mail (that is, the MAILBOX value of such objects is irrelevant). However, the ProxyAddresses list of AD User objects for people with O365 personal mail accounts must continue to be updated with Primary and Secondary Aliases for these accounts.
Responsibility: IAM generates Birthright Email accounts. We make Email addresses visible in the phonebook. We have inherited a part of the AD Daily Updater that checks for missing ProxyAddresses list entries for Aliases with an “@connect.yale.edu” MAILBOX value, but this has just been an excuse for the scripts that manually create and move mail accounts to be sloppy and ignore required changes to the AD. We should consider correcting mail account manipulation tools rather than auditing every few hours for oversights. If Alias changes are immediately reflected in updates to AD objects, then only “biographical” data (name, department, etc.) has to be updated in AD.
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:
...
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 Relays Relay computer programs are internally configured with files generated from the Alias Table. The program that generates the 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. Then the MAILBOX for that alias entry 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. In the MAILBOX value, the part after “@” has its own MX record 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 bulldogsthe MX records for “bulldogs.yale.edu is associated withedu” 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 |
...
.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”).
...