Partager via

451 4.4.0 Primary target IP address responded with: "451 5.7.3 Cannot achieve Exchange Server authentication."

  • Article

 

So this is a quick post but worth mentioning as these cases seem to crop up every once in a while.

The error in the title usually occurs after creating a second receive connector dedicated for an app relay or some other anonymous type access.

So lets walk through the steps that usually get us here.-

You create a second connector for relay aptly titled “app relay” here-

image

Then check off anonymous since our app is not authenticating to Exchange (note since we want this app to not only submit mail to this connector but also relay off it to other destinations we would need to grant the anonymous security principle the ms-Exch-SMTP-Accept-Any-Recipient extended right on this connector as well. Another less preferred method is to select Externally Secured as a Authentication type but both get us into the same issue.).

image          

Finally we add the remote IP range for our app.

image

 

Now it is the last two steps that get us into trouble.  Exchange needs to have Exchange Server Authentication selected in order to send internal intra org mail flow. However for our relay to work we don’t need this set nor is it by default.

image

However the real aspect to remember here is when receiving email from a remote host Exchange will always use the more SPECIFICALLY scoped receive connector based on the remote IP range.

So all things being equal if we have two receive connectors and one has an remote IP range as such-

image

And the other is-

image

And we receive an incoming SMTP connection from a host with say an IP of 192.168.62.10 we will ALWAYS us the second connector. This is regardless of the authentication type or permissions groups defined on the connector itself

Now if our internal Exchange servers happen to fall within the 192.168.62.0 subnet then we will use the App Relay receive connector and since it does not have Exchange Servers defined as a permissions group and/or Exchange Server Authentication selected we get the error that is the title of this post.

 

The take away here is when creating a dedicated receive connector for app relay or some other purpose ensure that the remote IP range defined on the connector does not include any internal Exchange servers.

Comments

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    February 01, 2012
    I had this issue on an exchange 2003 to exchange 2010 migration, just anonymous was ticked on the 2003 SMPT virtual server I had to enable integrated.. www.techieshelp.com/exchange-2010-queue-451-4-4-0-primary-target-ip-address-responded-with-451-5-7-3-cannot-achieve-exchange-server-authentication

  • Anonymous
    August 06, 2012
    Great explanation, thanks. Had this issue during a migration due to an incorrectly scoped receive connector for external relay.

  • Anonymous
    January 10, 2013
    Thanks a mil for this post. It solved my issue. I previously had Backup Exec on the Exchange 2010 server and had added the IP into the receive connector on the next hop server - once removed all started working.

  • Anonymous
    February 13, 2013
    I also noticed that disabling the "app" connector will not solve the issue. It must be deleted or modified in a way that will allow authentication.

  • Anonymous
    February 16, 2013
    The comment has been removed

  • Anonymous
    June 27, 2013
    this just saved me so much time! Thanks for taking the time

  • Anonymous
    December 02, 2013
    Great! This saved me. I did the exact same thing as described. Rather than using a range, i simply inputted the specific IPs addresses in order to not include the exchange servers. Thank you.

  • Anonymous
    January 23, 2014
    I was running into a similar issue between Exchange 2007 and Exchange 2013. Exchange 2013 front end service has some issues and our gateways started routing mails through 2007 and these got stuck in the queue.I created an Internal receive connector on Exchange 2013 and mail started flowing again.

  • Anonymous
    March 11, 2014
    Thanks Dude! This helped

  • Anonymous
    June 02, 2014
    I faced the same error and run this command on my Cisco ASA
    no fixup protocol smtp 25

    and working fine

  • Anonymous
    July 21, 2014
    You just saved my life!!

  • Anonymous
    November 20, 2014
    I ran into similer issue and had sovled by restarting our sonic wall firewall , our EX2010 published throgh sonic wall , simply we check in mxtoolbox.com and all ports were blocked , so after restarting the sonic wall every thing worked well

  • Anonymous
    April 13, 2016
    Thanks! Very helpful