Paying it forward…
Paying it forward…
Well, not really, just plain old IT email forwarding.
We all (Messaging Admins) have used forwarding extensively, but it struck me that there are several ways to achieve the same thing. Most often the forwarding scenario comes up during the following scenarios:
- Coexistence (mergers / acquisitions / divestitures)
- Upgrades (migrating to a later version of Exchange in a new Forest) and
- The leavers scenario when email for a terminated user should be sent to another employee
This leaver situation can be dealt with many ways of course, either by granting the remaining employee full access to the Leaver Mailbox, converting the Leaver Mailbox to Shared, and adding the leaver’s email address to the remaining employee proxyAddresses.
Forwarding email outside the organisation is more often than not frowned upon and usually there is an explicit IT policy forbidding it, after all, it’s the most basic form of Data Leakage, right? In fact, Microsoft Office 365 even has built in reports for it now.
Creation of forwarding/redirect rule
Generates an alert when someone in your organization creates an inbox rule for their mailbox that forwards or redirects messages to another email account. This policy only tracks inbox rules that are created using Outlook Web App or Exchange Online PowerShell. This policy has a Low severity setting. For more information using inbox rules to forward and redirect email in Outlook Web App
So on to the various methods.
3rd Party Tools
At the perimeter clients can use any number of tools like EOP, SendMail, MIMECast, MailMarshall, IronPort, EDGE, Barracuda, TrendMicro, Symantec, Sophos, Cisco, Clearswift, McAfee, WebSense, Proofpoint, Fortinet, AND SO ON!! to manage email forwarding before it even hits the On-Premise Mailbox. These can be configured to journal and forward amongst the plethora of features they all offer like malware, phishing attacks, anti-spam etc.
Transport Rules
To set a global forwarding rule it may make sense to use a blanket Mail flow rule (Transport Rule) to catch all, or individual emails for forwarding. Setting up Microsoft Exchange Transport Rules is relatively straight forward and can be gone at the GUI or via PowerShell. There is always a heap of options and exceptions to go with eth Rule itself. However, you don’t want to overload your messaging environment with too many transport rules as the cumulative effect very quickly has a serious performance impact on mail delivery times. Even adding 1 second per message processing to a Transport Server will have noticeable adverse impact.
targetAddress
The targetAddress seems like the obvious one, but actually the targetAddress attribute should only be used on Mail-Enabled Users (MEUs) or Mail-Contacts.
targetAddress – string value of the object’s real email address in the remote mail system. The AD attribute name is targetAddress; from inside Exchange Management Shell, it is referenced as either ExternalEmailAddress (if the object is a MailUser) or RemoteRoutingAddress (if the object is a RemoteUserMailbox).
This value serves two purposes:
- For mail routing, is serves as the next-hop address for mail delivery
- For Outlook clients, it is the value Outlook references during an Autodiscover lookup.
Mailboxes should not be configured to use the targetAddress for forwarding and in fact, inside Exchange Online (Office 365) you can’t use the targetAddress on a mailbox.
targetAddress on a Mailbox?
When can you? Well in Exchange On-Premise you can and actually there did used to be a valid use-case for it. During a staged Exchange Migration, you may want to pre-stage the Target mailbox due to size and network constraints but keep the user working in the Source until you are ready to cut them over. So, in the Target any active migrated user could email the non-migrated users in the source by seeing their mailbox in the GAL and let the targetAddress forward it.
- Could also be hidden from the GAL and just be replying to old email etc
- Pre-staging data is not without its issues and limitations. Pre-staged data is not touched again, so any email migrated over that is deleted in the source, filed, categorized, marked as read/unread will never be reflected in the target
Once the user is migrated you would then flip the routing by adding the targetAddress to the Source mailbox and remove it from the Target. (A better solution was of course be to convert the source Mailbox to an MEU ala New-MoveRequest).
Calendar Sync
In the days of Exchange 2003 migrations Quest had a Coexistence solution of sorts that used to perform a Calendar Sync from Source to Target. You needed the Calendar populated in both the Source and Target for Free Busy requests. This was because this data used to make its way into the SCHEDULE+ Public Folder used for Free Busy / Availability look-ups. Because the mailbox was created you therefore HAD to use the targetAddress to forward the emails.
With modern versions of Exchange (2007 onwards) we have the availabilityService that looks directly into the other mail system to get the Availability Info, so there is no need to pre-stage the calendar and therefore no need to use the targetAddress. Just provision the object as an MEU and set the targetAddress correctly.
ForwardingAddress
ForwardingAddress is used in the GUI and often referred to as “Store and Forward” because that is the options available. With the ForwardingAddress attribute you can only forward to a user in your own GAL. This can of course be a Distribution Group, Mail-Contact as well as a Mail-Enabled Users or Mailbox Enabled User. It is basically the “internal” forwarding option.
If you use PowerShell to Set-Mailbox -Identity “Joe User” – ForwardingAddress the default is also to set “Store and Forward” to enabled. You can set this to False with the -DeliverToMailboxAndForward $FALSE parameter.
ForwardingSMTPAddress
ForwardingSMTPAddress is the external version of ForwardingAddress and can be set to forward emails externally. This can only be set using PowerShell.
You may see this warning if you have set a ForwardingAddress previously.
WARNING: Before your forwarding settings can take effect, you need to contact your helpdesk and ask them to turn off the forwarding your administrator previously set.
Obviously, that is very straight forward (pardon the pun). The internal one will take precedence over the external one, so you need to remove the ForwardingAddress for the ForwardingSMTPAddress to take effect.
We use the ForwardingSMTPAddress when doing a divestiture typically. The source organisation wants to keep the users in their GAL and the Mailbox intact for Audit and Compliance reasons, but still have forwarding occurring for old emails.
Again, they could of course rename the mailboxes, convert them to shared hide them from the GAL. Then create Mail-Contacts for the users that have divested and use the ForwardingAddress option from above. Using a Mail-Contact (or MEU) would actually allow for the use of the targetAddress which would in turn allow for Availability look-ups in a Coex world – assuming it is not a hostile divestiture of course!
If you use PowerShell to Set-Mailbox -Identity “Joe User” – ForwardingSMTPAddress the default is FALSE for “Store and Forward” You can set this to $TRUE with the -DeliverToMailboxAndForward $True parameter.
RemoteRoutingAddress
RemoteRoutingAddress is only used On-Premises. It makes a Mail-Enabled User look like a Remote-Mailbox i.e. a Mailbox in Office 365. You can only use the RemoteRoutingAddress if you have configured a RemoteDomain for it, but you do NOT need to be set-up in Exchange / Office 365 Hybrid mode. The beauty of using this option, as opposed to targetAddress is that the Recipient looks nice inside the Exchange Admin Centre inside the On-Premise Server.
We have used this in the past where our client has migrated from IBM Domino and has built an On-Premise Exchange Server purely SMTP relay routing to Exchange Online and for object management i.e setting proxyAddresses and changing names/email addresses. It was especially good for Groups as Domino was the source of the Groups flowing to AD and then to AAD/ They are using AAD Connect for DirSync and being able to manage Groups in AD was preferable rather than converting them to Cloud only.
Client Rules aka Mailbox Rules
End users themselves can of course set up Rules in Outlook. https://support.office.com/en-gb/article/use-rules-in-outlook-web-app-to-automatically-forward-messages-to-another-account-1433e3a0-7fb0-4999-b536-50e05cb67fed
This is often discouraged, but none the less, when troubleshooting it is worth bearing in mind a user may have done this. Get-InboxRule is a good place to start. https://docs.microsoft.com/en-us/powershell/module/exchange/mailboxes/get-inboxrule?view=exchange-ps
As I said earlier, there is a default alert policy in Office 365 for this now:
Creation of forwarding/redirect rule
Generates an alert when someone in your organization creates an inbox rule for their mailbox that forwards or redirects messages to another email account. This policy only tracks inbox rules that are created using Outlook Web App or Exchange Online PowerShell. This policy has a Low severity setting. For more information using inbox rules to forward and redirect email in Outlook Web App
In closing, use the right forwarding method for the right job!
