0

There are 2 websites running on 2 different servers. Both websites send emails out to internal and external addresses. When the websites were using Exchange 2003, they both worked fine. The client then migrated from Exchange 2003 to Exchange 2010. Now only one of the websites is still able to send out emails. The other one keeps failing with the error

The SMTP server requires a secure connection or the client was not authenticated. The server response was: 5.7.1 Client was not authenticated

The failing website is passing the credentials through just fine and it uses the same code as the working website. Even when I switch the failing website to use the working websites email login it fails with the same error. The working website does not use SSL, and it still works. The SMTP server shouldn't require a secure connection.

I have a windows application I use for testing email sending. From the failing webserver the application is able to use both sets of logins to send emails just fine. It only seems to be sending through the website that it fails with this error.

I am not that familiar with Exchange servers and I don't have direct access to the Exchange server, so is there anything that should be checked that would cause the second webserver to be unable to send emails through a website, but able to send through a windows application?

Brandon
  • 451
  • 7
  • 22

3 Answers3

2

Personally, I'd take a sniff of the traffic between the "working" web server and the Exchange Server and compare it to the non-working web server's conversation. You can fight with changing settings all you want, but nothing beats just seeing what's being said on the wire.

Evan Anderson
  • 141,881
  • 20
  • 196
  • 331
  • thanks for the suggestion. Any tools that you'd recommend for this? And anything I should be looking for specifically? – Brandon Dec 03 '10 at 18:00
  • @Brandon: Wireshark (http://www.wireshark.org) is your friend, as is Microsoft's Network Monitor (if you prefer to use MSFT tools). I'd simply start by comparing the conversations to see what differs. My guess is that something will stick out rather apparently. – Evan Anderson Dec 03 '10 at 18:08
1

(I'm basing this on Exchange 2007, so apologies if it has changed significantly, I haven't looked at 2010).

  • In Exchange System Manager, pull up Server Configuration -> Hub Transport -> Receive Connectors Tab.
  • Check the Authentication tab. There's a few settings there that deal with the types of auth the server requires.

For testing, set up a new receive connector on a different port to experiment with the settings. Make the failing server use that, instead.

And + 1 to Evan for Wireshark. If you're not using SSL, you can watch the entire SMTP conversation between the web app and the receive connector. It's the best way of finding where the too are diverging in their behaviour.

SmallClanger
  • 9,127
  • 1
  • 32
  • 47
1

I'd lay money down it's due to a misconfigured Receive Connector.

Exchange On-Premises -> Server Configuration -> Hub Transport

Under the "Receive Connectors" area for the server in question, look through each of the Properties pages under the Network tab for the server that works. It's probably set to "Externally Secured" under the Authentication tab, which is what's making it work properly. You should just be able to add the IP of the failing server there under the "Receive mail from remote servers that have these IP addresses:" area.

Jeff McJunkin
  • 1,372
  • 1
  • 8
  • 16