Exchange to Domino Routing Rules specifically relating to Binary Tree Coexistence Solutions

Introduction

This document seeks to identify the potential pitfalls of Inbound SMTP routing to Domino in a Coexistence environment, particularly when using a static targetAddress that is built by a Directory Synchronisation solution.

Routing from Exchange/Office 365 to Domino

In a Binary Tree Coexistence scenario Microsoft Exchange will use the targetAddress value of an AD Contact or Mail-Enabled User.  The targetAddress is typically added by Binary Tree SMART DirSync software.

Typically this will look something like: firstname.lastname@domino.contoso.com

When Binary Tree SMART DirSync is set to use the scalar function dbo.ReplaceDomain (as opposed to dbo.UpdateInternetAddress) it will always statically be @domino.contoso.com

This therefore requires the Domino Global Domain Document to list on the Alternate Internet domain aliases: section the entry domino.contoso.com (much like an Accepted Domain in Exchange)

Routing processing order in Domino

Take an email to user Conrad Murray from Microsoft Exchange (or Office 365) it will route to the targetAddress of: conrad.murray@domino.contoso.com

First the router task will look for explicit entry of conrad.murray@domino.contoso.com in  any email field e.g. InternetAddress, Fullname Field, Shortname Field

Next, will look for localpart @ Local primary internet domain, conrad.murray@contoso.com in this case again explicit entries in on an explicit match on: InternetAddress, Fullname Field, Shortname Field

Success on conrad.murray@contoso.com

Localpart Look-up/Matching

If there is no match there, and assuming Domino is configured to do address look-up on Fullname then localpart on the Server Configuration Document,

then it will lastly fall back to Local Part of internet address – but only when the Internet Address domain of the recipient’s inbound email is a match to aPrimary Domain of a Global Domain Document.

LocalPart matching is NOT used when the recipients Internet Address Domain is one of the alternates only. See example later. 

The gotcha here is that the ($Users) view does NOT actually include the left part of Internet Addresses in the view.  It implies that it does, but actually it only (mainly) includes:

That’s great, but what about neil.langston@tailspintoys.com?

This email from Exchange will look like neil.langston@domino.contoso.com

1. Look-up Explicit email address neil.langston@domino.contoso.com  = FAIL
2. Look-Up localpart + primary GDD Domain neil.langston@contoso.com = FAIL
3. Lookup Localpart only neil.langston  = FAIL

Part 3 fails, (even though neil.langston is a valid local part), because the router did NOT drop back to option 3 – Localpart look-up because tailspintoys.com is NOT a primary Domain on a Global Domain Document.

For Localpart look-ups to succeed the users’ SMTP Domain Name entry must be it’s own Global Domain Document Local primary internet domain. In our example @tailspintoys.com is ONLY listed in a Global Domain Document as an Alternate Internet Domain alias

What about this user: Twan van Beers

This email from Exchange will look like tvb@domino.contoso.com

1. Look-up Explicit email address tvb@domino.contoso.com = FAIL
2. Look-Up localpart + primary GDD Domain tvb@contoso.com = FAIL
3. Lookup Localpart only tvb = FAIL

Part 3 fails for two reasons:

widgets.com is NOT a primary Domain on a Global Domain Document and therefore localpart look-up is not initiated by the router, and
well, obviously TVB doesn’t exist as a localpart anyway!

 ($Users) view will only have

• Twan van Beers/London/IT/UK
• Twan van Beers
• TvanBeer
• tvb@widgets.com

but not just tvb

Localpart look-up successes

This email from Exchange will look like gmeister@domino.contoso.com

1. Look-up Explicit email address gmeister@domino.contoso.com  = FAIL
2. Look-Up localpart + primary GDD Domain gmeister@contoso.com = FAIL
3. Lookup Localpart only gmeister = SUCCESS!

Mail-In Databases and Rooms & Resources

Let’s just assume explicit routing and fall back explicit routing successes for such Mail-In Databases and Rooms like:

• IT.Support@contoso.com  ( IT.Support@domino.contoso.com  )
• GroundFloor.ConferenceRoom@contoso.com ( GroundFloor.ConferenceRoom@domino.contoso.com )

But what about these examples:

This email from Exchange will look like sales@domino.contoso.com

1. Look-up Explicit email address sales@domino.contoso.com = FAIL
2. Look-Up localpart + primary GDD Domain sales@contoso.com = FAIL
3. Lookup Localpart only sales = FAIL

In the ($Users) view only London Sales Office will be present (along with sales@tailspintoys.co.uk )

Rooms

 This email from Exchange will look like GF1.Room@domino.contoso.com

1. Look-up Explicit email address GF1.Room@domino.contoso.com = FAIL
2. Look-Up localpart + primary GDD Domain GF1.Room@contoso.com = FAIL
3. Lookup Localpart only sales = FAIL

In the ($Users) view only:

• Ground Floor Presentation Room 1
• Ground Floor Presentation Room 1/More London Place  and
• GF1.Room@acme.com

will be present.

The solution is to either:

A) Use the use the scalar function dbo.UpdateInternetAddress but that then requires significantly more configuration for Coexistence including:

• Multiple DNS entries for autodiscover A records
• Multiple Exchange AvailabilityAddressSpace
• Multiple Exchange Remote Domains
• SAN Certificate on BT Free Busy IIS
• Multiple MAPs in the Application Settings of IIS
• Multiple Global Domain Documents – see APPENDIX A

B) Stamp the full targetAddress values on ALL Users, Mail-In Database and Rooms & Resources  in the Fullname field. 

Appendix A

 The Global Domain Document will not resolve an alternate to an alternate within itself i.e.

John.smith@domino.acme.com will not then look also to john.smith@acme.com

John.smith@domino.acme.com  will only ever try next John.smith@contoso.com and john.smith (John Smith / John_Smith)

To prevent the Router from using domain aliases when looking up addresses, do not include alternate Internet domain aliases in a Global
domain document. Instead, create multiple Global Domain documents, each specifying a different primary Internet domain.

e.g.

 NOTE:

Remember to only set ONE Global Domain Document to Use as default Global Domain (for use with all Internet protocols except HTTP):