Exchange Server and Office 365 offer many different options for forwarding messages to different recipients. Some of these options exist for users and others are for administrators. Administrators can also control how forwarding is handled within the organization.
The forwarding options available to clients and administrators are described below. Each of these methods has both pros and cons when implemented:
- Users can create a forwarding rule within Outlook or Outlook Web App
- An administrator can create a client rule for forwarding
- An administrator can set the ForwardingSMTPAddress parameter on a mailbox
- Users can set the ForwardingSMTPAddress parameter on a mailbox
- An administrator can set the ForwardingAddress parameter on a mailbox
In this post, I’m going to review each of these methods, the pros and cons, and the administrator controls in place for these options.
Forwarding rule within Outlook and Outlook Web App:
Users can create Inbox rules in both Outlook and Outlook Web App (OWA). One of the options is a rule to forward messages to a different recipient, which can be an internal or external recipient. In the example below, a rule has been created that forwards all messages received in the mailbox to an external recipient.
Client-side rules allow a great deal of flexibility when establishing forwarding. For example, say you want to forward emails to another internal or external recipient based on who sent the messages. The rules wizard allows this level of granularity. From an administrative standpoint client-side rules can also be helpful since they can be managed by the user. This obviates the need for administrators to be involved in the day-to-day management of these rules.
Client-side rules though are not immediately obvious to administrators. This may cause issues in environments that want to control where their data is stored and how it is transmitted. No specific permissions are required for users to create rules and there exists no method to limit this type of rule. Messages received by the destination mailbox look like forwarded messages; they have the same presentation as if the end-user selected the forward option on the message and specified the recipient.
Message tracking also confirms that the sender is the mailbox with the forwarding rule enabled and the recipient is the address specified on the forwarding rule.
This may cause issues in message handling, as subsequent replies would go to the mailbox the message was forwarded from rather than the original sender of the message.
When a message is forwarded by a client-side rule an additional header is added to the message: X-MS-Exchange-Organization-AutoForwarded. When the value of this header is set to TRUE this signifies the message was created by auto-forwarding.
Forwarding rule created by the administrator:
In Exchange 2010 and Exchange 2013, administrators have the New-InboxRule cmdlet, which allows them to create client-side rules within a mailbox. To create a forwarding rule that matches the previous rules wizard example you would run a command similar to the following:
PS C:> New-InboxRule -Name ForwardSharon -Mailbox 2148 -ForwardTo:SHARON@domain.com
Name Enabled Priority RuleIdentity
—- ——- ——– ————
ForwardSharon True 1 11219471045587107842
When using the Outlook client and viewing the rules in this mailbox, the administrator-created rule is present.
This rule has the same considerations and outcomes as a rule created by a user in Outlook; the only difference is that an administrator added it to the mailbox.
Forwarding using the forwardingSMTPAddress parameter of a mailbox created by the administrator:
Each mailbox has a parameter named forwardingSMTPAddress. This parameter is set by the administrator using Set-Mailbox. Any SMTP address can be specified in this parameter.
PS C:> Set-Mailbox 2148 -ForwardingSmtpAddress sharon@domain.com
PS C:> Get-Mailbox 2148 | fl name,forwardingSMTPAddress,delivertomailboxandforward
Name : Tim McMichael
ForwardingSmtpAddress : smtp:sharon@domain.com
DeliverToMailboxAndForward : False
When this type of forwarding is used, the user has no control and the forwarding process must be administratively managed. In addition, there is no granularity with this implementation; all messages for the mailbox are forwarded to the specified SMTP address. Because the field allows any SMTP address to be specified there is no need to create a mail-enabled object within your directory to establish this type of forwarding.
Messaging handling is also different with this type of forwarding. When the message arrives in the destination mailbox it appears as if it was sent directly to this mailbox. The TO field of the message reflects the original recipient, and the FROM field reflects the original sender. The message does not appear as forwarded.
Message tracking shows that the sender of the message is the original sender and the recipient is the forwarding address.
This allows the recipient to reply to the message and have the message sent directly to the original sender. It is important to understand this behavior in scenarios where compliance or journaling is used, as subsequent replies will bypass the original organization thereby bypassing journaling and compliance processes.
The message header also has appended the X-MS-Exchange-Organization-AutoForwarded header. When the value of this header is set to TRUE, in indicates that the message was created by auto-forwarding.
Forwarding using the forwardingSMTPAddress parameter of a mailbox created by the user:
Individual users may set the forwardingSMTPAddress parameter by using Outlook Web Access. When logged into Outlook Web Access access to this feature is available under options.
When the options menu is displayed selecting accounts –> forwarding will present the dialog to establish a forwarding address. Note: As the options pane may be subject to modification this setting may move to different areas within options.
In the forwarding dialog the user may select to enable forwarding and enter any SMTP address.
When reviewing the settings of the user via powershell we can observe that the forwardingSMTPAddress property is set.
Get-Mailbox <ALIAS>| fl name,*forwarding*
Name : <NAME>
ForwardingAddress :
ForwardingSmtpAddress : smtp:bob@contoso.com
The user setting the forwarding address has the same considerations and concerns as if the administrator had set the property.
Forwarding using the forwardingAddress parameter of a mailbox:
The forwardingAddress parameter of a mailbox is also managed by an administrator using Set-Mailbox. Unlike forwardingSMTPAddress, the forwarding address parameter must be an object that is defined within the directory. Attempting to set this value to an object not within the directory returns an error.
PS C:> Set-Mailbox 2148 -ForwardingAddress sharon@domain.com
Couldn't find object "sharon@domain.com". Please make sure that it was spelled correctly or specify a different
object.
+ CategoryInfo : NotSpecified: (:) [Set-Mailbox], ManagementObjectNotFoundException
+ FullyQualifiedErrorId : [Server=BN1PR06MB101,RequestId=3374349c-1924-43b2-bb21-d2243774a1d4,TimeStamp=7/20/2014
5:37:29 PM] [FailureCategory=Cmdlet-ManagementObjectNotFoundException] F2A1EE0E,Microsoft.Exchange.Management.Reci
pientTasks.SetMailbox
+ PSComputerName : pod51043psh.outlook.com
The forwarding address parameter can be another mailbox-enabled object, a mail-enabled user, or a mail contact. In this example, I have created a mail contact for my external recipient.
PS C:> New-MailContact -Name Sharon -ExternalEmailAddress sharon@domain.com
Name Alias RecipientType
—- —– ————-
Sharon Sharon MailContact
I then enabled the forwardingAddress parameter on the mail contact.
PS C:> Set-Mailbox 2148 -ForwardingAddress Sharon
The setting was validated with Get-Mailbox.
PS C:> Get-Mailbox 2148 | fl name,forwardingAddress,delivertomailboxandforward
Name : Tim McMichael
ForwardingAddress : Sharon
DeliverToMailboxAndForward : False
Similar to the fowardingSMTPAdderss parameter the forwardingAddress parameter must be managed by the administrator. The end-user has no control over this specific parameter and the end-user will not know that forwarding is enabled. Unlike client rules, the use of the forwardingAddress parameter applies to all messages received to the destination mailbox; there is no way to allow this function to work on specific messages.
Messaging handling is also similar to using the fowardingSMTPAddress parameter. The message arrives in the destination mailbox as if it was addressed directly to that mailbox. The TO address shows the original recipient and the FROM address shows the original sender.
This allows the forwarded recipient to reply to the message and have it returned directly to the original sender. Messaging tracking also shows that the sender is the original sender and the recipient is the address configured for forwarding.
It is important to understand this behavior in scenarios where compliance or journaling is used as subsequent replies will bypass the original organization thereby bypassing journaling and compliance processes.
In this scenario the X-MS-Exchange-Organization-AutoForwarded header is not stamped on the message.
Autoforwarding and delivertoandforward:
Each mailbox also has a parameter called deliverToAndForward. This allows the administrator to specify if the message should also be delivered to the mailbox where forwarding is enabled. This setting applies ONLY to forwarding that is configured by using the forwardingAddress or forwardingSMTPAddress parameters. Client-side rules are unaware of this setting.
Autoforwarding and remoteDomains:
Within Exchange and Office 365, administrators can create remote domains. By default, every tenant leverages the ‘*’ domain. When a specific remote domain does not exist, the ‘*’ remote domain setting are applied to the message.
A property of a remote domain is autoForwardEnabled property. This allows administrators to define if auto-forwarding is allowed on messages destined to the domain specified.
PS C:> Get-RemoteDomain | fl name,domainname,autoForwardEnabled
Name : Default
DomainName : *
AutoForwardEnabled : True
By default auto-forwarding is allowed to all domains. Administrators can use the remote domain settings to control how forwarding outside their organization is handled. Please note: this does not change how forwarding is handled within the organization.
In this example, I am creating a specific remote domain rule and have disabled auto-forwarding.
PS C:> New-RemoteDomain -Name ExternalDomain -DomainName domain.com
Name DomainName AllowedOOFType
—- ———- ————–
ExternalDomain domain.com External
PS C:> Set-RemoteDomain -Identity ExternalDomain -AutoForwardEnabled:$FALSE
The settings can be verified with get-remoteDomain:
PS C:> Get-RemoteDomain ExternalDomain | fl domainname,autoforwardenabled
DomainName : domain.com
AutoForwardEnabled : False
To test this feature I set the forwardingAddress on the mailbox to a recipient in the domain.com domain. When a message is addressed to the mailbox where forwarding is enabled, it never makes it to the destination. The same behavior would occur if a client-side forwarding rule is used.
When a client-side rule or the forwardingSMTPAddress is used, the mail flow process stamps the X-MS-Exchange-Organization-AutoForwarded to TRUE. This header is not viewable on a message as the transport header firewall removes it. When the message is processed by the Transport service, if the remote domain specifically blocks auto-forwarding and the auto-forward header is present and set to TRUE, the message is turfed, and no NDR is generated. If no form of journaling is present and the deliverToAndForward setting of the mailbox is set to FALSE, the message is effectively lost.
When looking at message tracking we can see that the message failed to reach its destination. The message delivery status is NONE and no send events are noted.
Using the same remote domain, the mailbox is configured with a forwardingAddress instead. The mail contact used as the forwardingAddress object has an external email address in domain.com. When sending a message to the mailbox where forwarding is enabled, the mail is successfully delivered. This is also confirmed by message tracking.
In this example, the transport process does not use the X-MS-Exchange-Organization-AutoForwarded but instead adds the forwarded address as a recipient during a different stage of message processing. As the message traverses the transport stack it is not detected as a forwarded message and is therefore allowed to arrive at desired recipient.
Utilizing the forwardingAddress scenario is an excellent way for an administrator to bypass forwarding settings on remote domains while controlling when message forwarding is allowed.
We routinely receive requests on how to enable granular message forwarding or only allow specific users to use auto-forwarding capabilities. Unfortunately, with the forwarding settings being tied to remote domains it is very difficult to enable forwarding for only a subset of users or where granular forwarding on messages attributes is desired. To allow clients to create auto-forwarding rules would mean the remote domain would have to allow auto-forwarding for everyone. Administrators can attempt to discover and remove auto-forwarding rules using Get-InboxRule.
In my experience, in most scenarios forwarding is disallowed on remote domains and enabling of forwarding is restricted to administrator configuration using the forwardingAddress parameter.
TIMMCMIC 