Exchange Server 2013 has a new feature called Managed Availability. MVP Jeff Guillet has a nice, easy to understand write-up of the feature here. A far more detailed explanation exists on the Exchange team blog if you really want to dive into the topic.
One of the health monitor messages that Managed Availability sends has the following message characteristics:
- From: firstname.lastname@example.org
- To: HealthMailbox<a big long GUID>@<yourdomain>
- Subject: Inbound proxy probe
If the problem isn’t immediately apparent to you let me get straight to it – Microsoft doesn’t own the inboundproxy.com domain (as far as I can tell from WHOIS records, as of the time of this writing).
Update: As of Cumulative Update 2 this probe email is now sent from email@example.com instead of @inboundproxy.com.
In fact, the domain was registered several months after Exchange 2013 reached RTM. It is currently “parked” on a fairly common domain parking service called SEDO.
PS C:\> nslookup inboundproxy.com Non-authoritative answer: Name: inboundproxy.com Address: 188.8.131.52 PS C:\> nslookup 184.108.40.206 Name: www172.sedoparking.com Address: 220.127.116.11
This in itself is not harmful to your Exchange 2013 servers. They’ll continue to operate just fine, and Managed Availability will likely work as it is designed to work.
But what you may begin to notice, as several Exchange 2013 customers are asking me about lately, is a number of messages leaving your organization sent to the firstname.lastname@example.org address.
So far everyone that has shown me an example of the issue is seeing NDRs being sent to that email address. I’ve seen them as well in my test lab, and I’ve also observed entries in my servers’ Frontend Transport protocol logs such as:
“A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 18.104.22.168:25″
In other words, my server is attempting SMTP connections to the IP address of the SEDO parking server.
Again, I don’t see any specific, proven risk at this stage for any Exchange 2013 servers. At the moment the worst issue I can see is that it reveals the email addresses of your health mailboxes. Whether this can be used for nefarious purposes is unknown to me at this stage.
But in addition to that, it is not very polite to use someone else’s domain name in your product’s code, and may irritate the SEDO server admins if the volume of SMTP connection attempts from Exchange 2013 servers grows too large.
The main purpose of this article at the moment is to shed some light on the matter for those of you out there who begin to notice these types of messages or log entries on your own servers.
As far as I can see there is no remediation for this issue. I suppose configuring a remote domain and disabling NDRs to inboundproxy.com may work, but I don’t know what impact that may have on Managed Availability.
Ideally Microsoft will either acquire the domain (if they haven’t already) or change their code to stop using that domain for health probes. Maybe we’ll see such a change in an upcoming cumulative update release.
Update: Brian Reid has a post with an example on how to find the health issue that is causing the NDRs.