Introduction
If you are running Exchange Server 2010 (and Exchange Server 2007 with the latest Service Pack), you might have configured automatic delivery of out-of-office messages or any other automatic notification, and find out that users outside your organization are not getting this email. This article will explain the reason for that, and in addition will discuss two workarounds to mitigate this problem.
Technical Background
With Exchange Server 2010 (and 2007’s latest Service Pack) Microsoft has changed the behavior of automatic server based notifications, especially “Out of Office” replies to rely on RFC 2298. As per RFC 2298 Message Disposition Notification (MDN) messages should be sent with a blank sender. The OOF reply messages are Message Disposition Notifications. This means that the HUB Server in your organization replaces the senders name with a blank one while transferring it to the internet. The detailed description of this behavior can be found here.
Behavior and Circumstances
If you are running a native Exchange Server 2010 based email infrastructure you might have never heard of this issue. Native Exchange Server 2010 means you are running the Exchange Edge Server Role for mailbox delivery and acceptance. Exchange Edge Role has been designed to support this specific behavior and to interact as expected.
If you are running an Exchange Server 2010 Organization and are using Email Relay Servers of other vendors or as “Software as a Service” delivered from a cloud provider, your users might face this behavior. And if you read correctly I wrote “might”, this means that in one configuration it might work properly and in another one, it does not work at all.
This behavior occurred at one of my customers after the migration from Exchange Server 2007 to 2010 without changing the routing infrastructure and relay design infrastructure.
Troubleshooting the Behavior
If your users are requesting to troubleshoot this issue, you should analyze the:
Configuration of Exchange Server “Out of Office”
Configuration of Anti-Virus Mail Scanners
Configuration of Exchange Server Transport Rules
Exchange Server Log Files
Configuration of Exchange Server “Out of Office”
To configure the default behavior for automatic system notifications, you would have to configure the following setting:
Figure 1: Configuration of Out-of-Office Behavior
This setting needs to be configured per remote domain you are supporting. If you have chosen “Allow external out-of-office Message only”, the “out of office” MDN should leave your Exchange Organization.
The configuration from the PowerShell is as follows:
Set-RemoteDomain -AllowedOOFType ‘External’ -Identity ‘Default’
Configuration of Anti-Virus Mail Scanners
Nearly every edition of Anti-Virus Mail Scanner has on option to disallow any emails with an “empty sender or return path”. So, depending on what scanner you are using, the option might be in a different location, but in general it is available.
Configuration of Exchange Server Transport Rules
Another configuration that might kill your MDNs is an Exchange Server Transport Rule. To check out if that is the case, then you should disable all of them and afterwards enable one by one with tests in between.
The general configuration can be found here:
Figure 2: How to configure Transport Rules
Exchange Server Log Files
If you still have not found a solution; you should have a look at your log file configuration. If it is still disabled to log incoming and outgoing traffic on your Hub Server, you should enable it as follows:
Set-ReceiveConnector “Connector Name” -ProtocolLoggingLevel verbose
To configure the same setting in the GUI, you should use the following:
Figure 3: Enable SMTP Logging
When analyzing the log files, you should look for the following layout:
23T10:50:22.735Z,external,08CDB56C9D00D84A,19,z.y.x.w:20630,w.x.y.z:25,<,550 Requested action not taken: mailbox unavailable
The above clearly indicates that you are running into the same issue of RFC2298.
Typical Workarounds
If you encounter this issue, you have some good workarounds for it:
Use Outlook “out of office”
Switch Relay Provider
Implement Exchange Server Edge Roles
Use Outlook “Out of Office”
One quite simple workaround is not to use the Exchange Server based “Out of Office” functionality. You might instruct your users to configure the “Automatic Reply” function instead.
Switch Relay Provider
Another – perhaps more complex – solution will be to switch to a SMTP relay provider that supports “Out of Office” messages to the Internet.
Implement Exchange Server Edge Roles
The third – perhaps most complex – solution is to switch you currently existing Relay Servers to Exchange Edge Servers. As per technical call, the Exchange Team in Redmond promises that “Out Of Office” replies are being transferred to the Internet in a successful way. And it is not only a promise; a configuration change in the existing Network Infrastructure at one of my customers did solve the issue, too.
The statement of a Customer Call to Microsoft’s Product Support ended as follows:
“The Exchange edge server will not reject the OOF message as the edge server will be incorporated into the Exchange organization. The HUB server will transfer the OFF messages in the address of OFF mailbox to the edge server and the edge server will then send the messages with empty return path e.g. blank sender, MAIL FROM: <> “null” to Internet.”
Conclusion
As you have seen here, dealing with the problem of MDNs is not quite easy, but if you fulfill all technical requirements, then you will not run into this problem at all. If you do not like running Exchange Edge Servers, you should switch to a software or hardware solution supporting MDNs to the Internet or switch your Cloud Provider to another one supporting this functionality.
If you still encounter any problems, please do not hesitate to contact me.
