If you would like to read the first part of this article series please go to Remote Domains in Exchange 2013 (Part 1).
Introduction
This is the second and final part of an article looking at remote domains in Exchange 2013. In part one, the purpose of remote domains was discussed along with understanding the default remote domain. A review of the Exchange Management Shell commands that are used when configuring remote domains was also covered, and part one concluded with a look at controlling Out of Office responses to remote domains. Here in part two the following topic areas will be discussed:
- Controlling delivery / non-delivery reports
- Controlling automatic replies and forwards
- Controlling display name sending
- Controlling message formats and their per-user settings
Controlling Delivery / Non-Delivery Reports
Delivery and non-delivery reports can contain information about the recipients that are referenced in that report. Perhaps due to security, privacy or other reasons, organizations may desire to prevent this information from being sent to one or more remote domains. With the remote domain configuration, organizations have the ability to prevent delivery and non-delivery reports, and hence the information they contain, from being sent to recipients that are not part of the local Exchange organization. The remote domain parameters that control these settings are:
- DeliveryReportEnabled
- NDREnabled
Both of these parameters are enabled by default and hence both delivery and non-delivery reports will be sent to remote domain recipients. To disable either delivery or non-delivery reports from being sent to remote domain recipients, the Exchange administrator simply sets the required parameter to a value of $false. For example, to disable sending non-delivery reports to a remote domain for neilhobson.com recipients the Exchange administrator could use the following command:
Set-RemoteDomain -Identity neilhobson.com -NDREnabled $false
This example assumes that the actual name of the remote domain object is neilhobson.com, in addition to neilhobson.com being the value of the RemoteDomain parameter.
As well as preventing the sending of non-delivery reports to remote domain recipients, Exchange 2013 permits another level of configuration on remote domains. There is another remote domain parameter that is useful for those organizations that want to continue to send non-delivery reports but want to restrict the amount of diagnostic information sent with those reports. This parameter is called NDRDiagnosticInfoEnabled and is enabled by default.
For example, consider the non-delivery report shown below. As can be seen at the bottom of the non-delivery report, the start of the diagnostic information is shown. This information includes details such as the original message headers. If the NDRDiagnosticInfoEnabled parameter is set to $false for that remote domain, Exchange limits the amount of diagnostic information sent with the non-delivery report. Specifically, although the ‘received’ message headers are still present in the non-delivery report, the elements of the headers that can contain details such as server names and IP addresses are stripped.
Controlling Automatic Replies and Forwards
Not to be confused with Out of Office messages, remote domains can also be used to control automatic replies sent by clients in the local Exchange organization. In addition, remote domains also support the ability to control automatic forwarding of messages to remote domain recipients.
Sometimes an organization may choose to send automatic replies to messages, perhaps from a shared mailbox such as a customer enquiry mailbox for example. Typically, the requirement is to send an automated response to customer messages to acknowledge the request and perhaps state an expected response time to the enquiry. One way of configuring these automatic replies is to use Outlook rules with the ‘have server reply with a specific message’ action applied to incoming messages. However, there may also be a requirement to prevent automatic replies from being sent to one or more remote domains. These options can be controlled via the AutoReplyEnabled parameter of the remote domain object. Like many parameters already discussed in this article, this parameter has a simple Boolean value, hence an example command to disable automatic replies to the neilhobson.com remote domain could be:
Set-RemoteDomain -Identity neilhobson.com -AutoReplyEnabled $false
Also, an organization may choose to disable automatic forwards for one or more remote domains, perhaps to prevent users from automatically forwarding messages outside of the organization’s messaging system. Interestingly, it was noted that the AutoForwardEnabled parameter is set to $false by default for the default remote domain, yet is set to $true by default when creating a new remote domain as shown below.
Exchange administrators may need to watch for this when creating a new remote domain as it could produce unexpected results. For example, consider the scenario where an Exchange administrator has previously used the default remote domain’s AutoForwardEnabled parameter value of $false to prevent automatic forwards from being sent to any remote domain. The administrator may discover that automatic forwards are now sent to specific remote domain recipients after creation of that remote domain object in Exchange, unless the administrator remembers that the AutoForwardEnabled parameter for that specific remote domain must also be set to $false.
Controlling Display Name Sending
Another interesting aspect of remote domain configuration is the ability to control sending display names to recipients in remote domains. The display name is the recipient name that is seen in the Global Address List (GAL). The two configuration options for remote domain recipients are either to send the user’s display name as seen in the GAL, together with the SMTP address or just send a ‘simple’ display name. The simple display name option actually means remote domain recipients will only see the sender’s SMTP address rather than the SMTP address and GAL display name. Why might an organization need to disable sending display names to remote domain recipients? If an organization uses sensitive or private information in user’s display names, there may be a requirement for preventing that sensitive or private information from being sent externally.
The ability to disable the sending of display names to remote domain recipients is controlled by the UseSimpleDisplayName parameter on the remote domain settings. Display names are sent externally by default whereas simple display names are not, meaning that the default value of the UseSimpleDisplayName parameter is $false. Therefore, the alternative is to enable simple display names by setting the UseSimpleDisplayName parameter to a value of $true. An example of doing this is shown below, where it can be seen that the ‘simple’ display name is just the sender’s SMTP address rather than the full display name and SMTP address.
Controlling Message Formats and Their Per-User Settings
Remote domains permit the configuration of a wide variety of message format and encoding options, as well as Transport Neutral Encapsulation Format (TNEF) conversion options. This is a complex area that likely warrants a dedicated article, but a brief description of the options available follows. However, the administrator should take the time to research these configuration options further if they are not familiar with them.
The ContentType parameter of the Set-RemoteDomain cmdlet controls whether messages for remote domain recipients are converted to text or HTML formatted MIME messages and hence it’s possible that an administrator may need to configure a specific remote domain for MIME messages that use text formatting only. The CharacterSet parameter controls MIME message character sets used for messages that do not already have a character set applied, while the NonMimeCharacterSet parameter controls character sets for messages that do not have a MIME character set applied.
One key configuration area that an Exchange administrator should be aware of with regards to remote domains and message formats is that several message format configuration elements can be applied on a per-user basis. In these cases, these per-user settings override the corresponding values that are applied to the remote domain. When the term ‘per-user’ is used here, it means settings that are configured against mail-enabled contacts or mail-enabled user objects.
For example, when examining the properties of a mail-enabled contact by using the Get-MailContact cmdlet, it can be seen that there are four parameters that deal with the application of message formatting options for that contact. These parameters are MacAttachmentFormat, MessageBodyFormat, MessageFormat and UsePreferMessageFormat. It’s the UsePreferMessageFormat Boolean value parameter that specifies whether the message format settings to be used should be those specified in the remote domain ($false) or those specified in the mail-enabled contact ($true). The MessageBodyFormat parameter controls whether text, HTML or both can be used to send to the remote recipient. Therefore, if the administrator wants to ensure that messages to a particular remote recipient are always sent using text rather than HTML, the administrator would set the following two configuration options using the Set-MailContact cmdlet:
- UsePreferMessageFormat to $true
- MessageBodyFormat to ‘text’
The MessageFormat parameter is used to control whether text or MIME is used as the message format, while the MacAttachmentFormat is used to control the attachment format of messages in the Apple Mac operating system. For full details of all parameter settings, see the Set-MailContact documentation on TechNet.
Summary
That completes this look at remote domains in Exchange 2013. Remote domains are one of those essential configuration elements for Exchange 2013 that administrators may need to review and/or change from time to time. Not all configuration options will necessarily be used but nevertheless, administrators should be fully aware of the available options for possible future use.
