Search Google Appliance

Nexus Email Routing

1. Executive Summary

The introduction of the Nexus service and the difference in the way this new system routes email, compared to the existing Herald system, has created the possibility that some email addresses may end up with a split routing. We intend to implement an automated system that puts email forwarding in place for affected address. This will prevent email targeted to one address ending up in two locations dependant on where it was sent from and ensure full access to Nexus facilities, including SharePoint, for those whose primary email is not held on Nexus.

2. The Problem

The University's email routing is handled by the IT Services oxmail service. For most email addresses these systems can lookup a mailbox on a specific server within the University to which email should be delivered. For a few sets of email addresses they have a blanket rule which routes any address in a specific domain to a specified server (known as direct deliver).

The introduction of Nexus, combined with the fact that Herald accounts have always been provisioned, even for those with local mail services, has left us with an issue to resolve, due to a "clash" between the way emails are routed. The rotuing mechanism in Nexus is significantly different to that in the Herald system and leaves a number of issues to be resolved.

The current email routing occurs as such:


Herald Routing
Figure 1. Herald Routing

Each mailbox in Nexus has an entry in Active Directory. This entry identifies the email address associated with the mailbox and all outgoing email sent from the account has the sender set to this address. Nexus also has a Global Address List (GAL) which is built from Active Directory. Each mailbox in Nexus appears in the GAL (unless it has been marked as ex-directory) and thus users can search for their colleagues across the University, and click on their name to send them email (in Outlook Web Access, Outlook and Entourage for Web Services).

On Herald, each mailbox has a "" address assigned to it. All incoming email is routed via the oxmails, which re-route email for "" to the appropriate "" mailbox. Outgoing email sent via webmail could be sent with any email address, but the addresses known to match the mailbox are supplied as a set of defaults. All outgoing mail from Webmail is sent using the oxmails. Similarly those connected to Herald via IMAP send mail using which then uses the oxmails, so all email gets routed by the oxmails.

On Nexus, although there is a "" address associated with each account, we also have to associate a user's main email address with the mailbox. This is for two reasons. First, it allows the user to send email using their "" address rather than just "" from Outlook Web Access and Outlook/Entourage (configured for a direct Exchange connection). Second, this address appears in the GAL assigned to the user, and would be selected by others searching for them.

This difference between the Herald account only logically owning "", compared to the Nexus account logically owning "" and one of the user's "" addresses, gives rise to issues with email routing for those who route their "" address to a local (department/college) mail server. As Nexus believes it can accept email for "", it will internally route any email sent to the address direct to the associated mailbox. This means the "" address ends up with two logical mailboxes, the first in the local mail server and the second on Nexus. This creates a split routing scenario where email can arrive in different mailboxes depending on where it was sent from. Email sent within Nexus will end up in the Nexus mailbox. Email sent outside Nexus will end up in the intended target mailbox.

Obviously this change in behaviour is highly undesirable. However, for an organization of our size and complexity there is no viable, let alone supported, method to force all email sent via Nexus, including emails sent between addresses within Nexus, to the oxmails so that email routing can be performed there. This means an alternative way of handling mail routing must be found.

It is important to note that any solution must be compatible with the whole of the Nexus service, not just the Exchange component. A fundamental part of the Nexus service offering will be SharePoint and any solution incompatible with SharePoint is a non-starter.

3. Outline Requirements

There are three types of email routing carried out by the oxmails:

  • E1. Standard - Direct to Nexus/Herald
  • E2. Personal - Remap "" to "" and send to relevant target machine
  • E3. Direct Deliver - Hand off a complete subdomain to a known target mailserver (all "" addresses routed directly to "" with no interpretation/routing

There are also several typical configurations desired by end-users that arise from these:

  • T1. Users who are unaware of their Nexus account and for whom mail is routed to a local mail server
  • T2. Users whose mail is routed to an local mailserver but use their Nexus account as a second account with "username@herald"
  • T3. Users whose mail is routed to a local mailserver but wish to use their Nexus account with their correct address to occasionally send messages via the web client (replies go to the local mail server)
  • T4. Users whose mail is routed to a local server which then routes it back to Nexus
  • T5. Users with two or more addresses, one routes to Nexus and another to a local server
  • T6. Users who use Nexus exclusively, and all their email is routed to Nexus

NB: T2 uses an email address ("username@herald") that has never been supported by IT Services, but is still usable

Any solution to the split routing problem should also meet as many of these general requirements as possible:

  • R1. The Global Address List (GAL) has an entry for everyone showing an appropriate email address (unless ex-directory)
  • R2. There is no end-user perceptable difference in email routing between the oxmails and Nexus
  • R3. The accidental setup of a split routing is inhibited where possible and if found it is approprately fixed
  • R4. The solution must work with all Nexus service elements, including SharePoint

4. Intended Solution

In brief, the solution involves automatically maintaining email forwarding out of Nexus and onto their unit mailserver where appropriate.

The main driver to this solution over a contact/hidden account based solution was the behaviour of SharePoint when the "Alert Me" and workflow functionality was used. SharePoint uses the email address of the user account and does not allow the use of Exchange contacts in workflows. This would mean that any SharePoint-generated email would end up in the Nexus mailbox even if the owner used an email account elsewhere.

This solution covers the user classes above as follows:

  • T1. Mail sent to the Nexus account will be forwarded to the local mailserver
  • T2. The Nexus account will have an automatically maintained forward to the local mail server and an additional account will need to be provisioned to keep two different mailboxes, or the email will be merged ending up at the local mailserver
  • T3. Mail can be sent from OWA with the correct email address and responses end up at the local mailserver (as with Herald now)
  • T4. The user/ITSS need to inform the Nexus team so a special flag can be applied to stop the Nexus forwarding creating a mail loop
  • T5. Nexus will only allow an email address that routes to it to be applied to the account. At migration time, unless forwarding has already been setup on Herald, the account's address will be selected from those that are known to route to Nexus. If an attempt is made to change the address assigned to the account, it will be limited to the addresses routed to Nexus.
  • T6. These users have their preferred address from Herald migrated (if appropriate) and can select from any of the addresses Nexus knows belong to them

It also attempts to meet the other requirements by:

  • R1. The GAL entry will have one of the user's valid addresses
  • R2. Forwarding will ensure all email ends up in one place for one address and the forwarding will be checked for accuracy with each oxmail update
  • R3. If a split routing is found, forwarding will be put in or a change of address to a Nexus routed address will occur. Any attempt to change the email address associated with the account will also be validated
  • R4. The solution works with SharePoint by ensuring the address is held against the user account and not a contact

For the three types of routing performed by the oxmails the solution can be visualized as:


Standard Routing
Figure 2. Standard Routing


Personal Routing
Figure 3. Personal Routing


Direct Deliver Routing
Figure 4. Direct Deliver Routing

5. Other Considerations

5.1. Direct Deliver Routings

Direct deliver routings are addresses where the oxmails pass on the whole subdomain to a target server. As we do not have a record of the true target mailbox we will be unable to setup forwarding as for personal routings.

For this handful of domains, we need either of the following:

  1. An algorithm for determing the target address (for example with "" addresses we know that every account has a second address tied to it of the form "{nexususername}", so the target is easily determined)
  2. A list which can be gathered by an automated process mapping email addresses to target mailboxes
  3. The domain commits to becoming routed via the oxmails (personal routing) rather than direct deliver

We are also investigating more central solutions involving forwarding emails to a dummy domain and then rewriting their addresses. However this solution is difficult and may not come to fruition.

If no viable central solution is found and none of the three options above are taken, then in order to migrate the data currently held on Herald for these accounts, they will have their associated email address changed to "", will be hidden from the GAL, and the email functionaility in SharePoint will not be able to send email onto the correct destination mailbox.

We will be contacting the departments whose mail is routed in this way to discuss their options.

5.2. Project Accounts

Project accounts will be catered for if the address assigned to them routes directly to Nexus. Any account that uses a more indirect route (generic addresses etc) may not be catered for appropriately if the account's email is not hosted on Herald/Nexus. This is because it is difficult for us to follow the chain of addresses to determine where mail ends up, especially if it routes via an alternative server/mailing lists etc. Please note there is a difference between project accounts and generic addresses. Generic addresses are just a routing, project accounts imply the existance of a Herald account unless IT Services has been told specifically not to create one.


Service area: 

Written by IT Services. Latest revision 18 October 2017