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: inboundproxy@inboundproxy.com
- 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 inboundproxy@contoso.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: 82.98.86.172 PS C:\> nslookup 82.98.86.172 Name: www172.sedoparking.com Address: 82.98.86.172
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 inboundproxy@inboundproxy.com 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 82.98.86.172: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.
If i delete any INBOUND PROXY message, Getting any problem?
In my Exchange CU13 I’ve got:
FrontendTransport health set unhealthy (OnPremisesInboundProxyMonitor) – The inbound proxy probe failed 3 times over 15 minutes.
The inbound proxy probe failed 3 times over 15 minutes. Server 127.0.0.1 on port 25 did not respond with expected response (OK). The actual response was: 550 5.7.1 Message rejected as spam by Content Filtering. . Probe Exception: ‘System.Exception: Server 127.0.0.1 on port 25 did not respond with expected response (OK). The actual response was: 550 5.7.1 Message rejected as spam by Content Filtering. .
Check:
1. Get-MessageTrackingLog -Sender inboundproxy@contoso.com
RecipientStatus : {[{LRT=};{LED=550 5.7.1 Message rejected as spam by Content Filtering.};{FQDN=};{IP=}]}
2. C:Program FilesMicrosoftExchange ServerV15TransportRolesLogsHubProtocolLogSmtpReceive
2016-11-25T11:04:17.554Z,EXCH01Default EXCH01,my.ip.add.res:2525,my.ip.add.res:62873,<,MAIL FROM: SIZE=0 AUTH=,
2016-11-25T11:04:17.554Z,EXCH01Default EXCH01,my.ip.add.res:2525,my.ip.add.res:62873,*,;2016-11-25T10:59:21.597Z;17,receiving message
2016-11-25T11:04:17.554Z,EXCH01Default EXCH01,my.ip.add.res:2525,my.ip.add.res:62873,<,RCPT TO:,
2016-11-25T11:04:17.570Z,EXCH01Default EXCH01,my.ip.add.res:2525,my.ip.add.res:62873,>,250 2.1.0 Sender OK,
2016-11-25T11:04:17.570Z,EXCH01Default EXCH01,my.ip.add.res:2525,my.ip.add.res:62873,>,250 2.1.5 Recipient OK,
2016-11-25T11:04:17.570Z,EXCH01Default EXCH01,my.ip.add.res:2525,my.ip.add.res:62873,,354 Start mail input; end with .,
2016-11-25T11:04:17.570Z,EXCH01Default EXCH01,my.ip.add.res:2525,my.ip.add.res:62873,*,,receiving message with InternetMessageId
2016-11-25T11:04:17.648Z,EXCH01Default EXCH01,my.ip.add.res:2525,my.ip.add.res:62873,*,,Rejected by agent:
2016-11-25T11:04:17.648Z,EXCH01Default EXCH01,my.ip.add.res:2525,my.ip.add.res:62873,>,550 5.7.1 Message rejected as spam by Content Filtering.,
Solution:
Set-ContentFilterConfig -BypassedSenders inboundproxy@contoso.com
I Hope it’ll help to someone.
Pingback: Confluence: New Accounts
I constantly receive errors:
Execution Context: ‘220 server.mydomain.net Microsoft ESMTP MAIL Service ready at Tue, 25 Feb 2014 14:33:03 +0000EHLO InboundProxyProbe 250-server.endava.net Hello [127.0.0.1]MAIL FROM: inboundproxy@contoso.com 530 5.7.1 Client was not authenticated ‘
Is it possible that this cause any Outlook disconnections due to considering FrontEndService unhealthy and restarting it from time to time?
I’ve created receive connector and let’s see if it help.
Pingback: The UC Architects » Episode 24: So many things….
Pingback: Exchange Server 2013 RTM Cumulative Update 2 (CU2) Released
The Real Person!
The Real Person!
CU2 has changed this behavior. The probes are now sent from inboundproxy@contoso.com instead.
They did change it but my spam filter is still catching it.
I suspect because 127.0.0.1 does not match contoso.com on any mx record.
The Real Person!
The Real Person!
Yeah, the change is only better in the sense that at least Microsoft actually owns the contoso.com domain.
Is the CU2 allready public? The only update my exchange servers are asking for is the anti-spam filter update.
Today I saw this:
2014-03-15T18:37:48.580Z,Inbound Proxy Internal Send Connector,08D0FFCB1CB4018C,50,192.168.2.111:49526,192.168.2.110:25,>,MAIL FROM: SIZE=0 AUTH=,
2014-03-15T18:37:48.580Z,Inbound Proxy Internal Send Connector,08D0FFCB1CB4018C,51,192.168.2.111:49526,192.168.2.110:25,>,RCPT TO:,
2014-03-15T18:37:48.580Z,Inbound Proxy Internal Send Connector,08D0FFCB1CB4018C,52,192.168.2.111:49526,192.168.2.110:25,<,250 2.1.0 Sender OK,
2014-03-15T18:37:48.580Z,Inbound Proxy Internal Send Connector,08D0FFCB1CB4018C,53,192.168.2.111:49526,192.168.2.110:25,,DATA,
2014-03-15T18:37:48.596Z,Inbound Proxy Internal Send Connector,08D0FFCB1CB4018C,55,192.168.2.111:49526,192.168.2.110:25,<,354 Start mail input; end with .,
2014-03-15T18:37:48.659Z,Inbound Proxy Internal Send Connector,08D0FFCB1CB4018C,56,192.168.2.111:49526,192.168.2.110:25,<,550 5.7.1 Message rejected as spam by Content Filtering.,
the mail was sent by inboundproxy @ inboundproxy.com
The Real Person!
The Real Person!
CU2 was released some time ago. In fact CU3 and now SP1 (equivalent to CU4) have also been released, so you’re a few builds behind now if you’re still on CU2.
I just remembered, I actually had to wait for a CU to even be able to install it (cause of a existing Exchange 2010 Server).
My Exchange Servers are updated with the latest patches. But for some reason the domain for those emails still seems to be inboundproxy.com.
Did you hear of anyone else reporting this behaviour with a current installation of Exchange 2013?
I wonder if it could be cause by having an active Exchange 2010. I just removed the last Exchange 2010 Server a few days ago.
The Real Person!
The Real Person!
Have you deployed CU2 (or later)?
I just checked the Version. Seems the Installation is not updated with the CUs. I was expecting them to be delivered over microsoft update. The direct microsoft update and the WSUS, both didn’t report any missing exchange 2013 updates. I always expected exchange updates to be delivered that way. Did this behaviour change?
The Real Person!
The Real Person!
Exchange 2013 CUs and Service Packs are not delivered via Windows Update.
Exchange 2010 Update Rollups sometimes are if they contain critical security fixes. Service Packs never.
Could you not also set up inboundproxy.com as an authoritative domain so that Exchange will try to deliver locally?
The Real Person!
The Real Person!
Perhaps. But I don’t know what impact that might have on the overall operation of Managed Availability.
Plus, adding a domain you don’t own as an authoritative domain is a bit of a hack job.
Adding it as an domain on Exchange is a workaround. It does not help you find the reason why your HealthMailboxes are rejecting the probe emails. Also, as the probes are sending the messages and not the mailbox that you would create if you added inboundproxy.com domain to Exchange, you might cause the probes to stop sending or receiving as they expect to be able to, and so Managed Availablity will start to “fix” services as it would believe they are not working. The cure is to fix the NDR’s as documented at http://blog.c7solutions.com/2013/06/queues-building-to-inboundproxycom.html
well MS can take a look at IBM Domino monitoring an see how it is done.
Hi Paul
I read jeff’s post afew months ago
but what I don’t get is why is it generating NDR if the heal mailboxes are there and active/working right?
I mean:
◾From: inboundproxy@inboundproxy.com
◾To: HealthMailbox@
◾Subject: Inbound proxy probe
it will only go there if it cant deliver to “HealthMailbox@” and try to generate NDR to sender(inboundproxy@inboundproxy.com)
no?
The Real Person!
The Real Person!
So it would appear yes. So the issue then is how many scenarios might exist where that can happen?
Some of the people who have contacted me have confirmed they had an issue at the time, such as a database being offline. So what happens when a whole DAG goes down for a larger organization? What happens if a big slice of Office 365 goes down?
These are things we don’t really know at this stage.