5.7.1 Client was not authenticated error using Exchange mail

For general questions and discussions specific to the AbleCommerce GOLD ASP.Net shopping cart software.
Post Reply
User avatar
AbleMods
Master Yoda
Master Yoda
Posts: 5170
Joined: Wed Sep 26, 2007 5:47 am
Location: Fort Myers, Florida USA

5.7.1 Client was not authenticated error using Exchange mail

Post by AbleMods » Tue May 08, 2018 6:41 am

A client recently (this morning) started seeing this error on every email the Able store tries to send. For years they've been using a hosted Exchange Server solution for their email hosting.

As of this morning, all emails from the server result in the 5.7.1 Client was not authenticated error.

I've seen this before, specifically when an Able store tries to use an Office365 account to send emails. However I have never found a solution.

Has anyone ever researched the issue? Is there a solution possible that doesn't involve changing where the email is hosted?

I believe I might have found the root cause. There are two ways to authenticate an SMTP server. One is to authenticate on Port 25 (unencrypted) and then send the actual email content as encrypted. The other is to do the authentication encrypted starting from the very first SMTP command sent. System.Net.Mail only supports unencrypted authentication. So if the Exchange Server is configured to require SSL for authentication, any .Net application using System.Net.Mail for SMTP will not be able to authenticate.
System.Net.Mail only supports “Explicit SSL”.

Explicit SSL
System.Net.Mail only supports “Explicit SSL”. Explicit SSL starts as unencrypted on port 25, then issues a STARTTLS and switches to an Encrypted connection. See RFC 2228.

Explicit SLL would go something like:
Connect on 25 -> StartTLS (starts to encrypt) -> authenticate -> send data

If the SMTP server expects SSL/TLS connection right from the start then this will not work. If you see "530 Must issue a STARTTLS command first" being returned while trying to send a message, then Explicit SSL is what is being expected.

Implicit SSL
There is no way to use Implicit SSL (SMTPS) with System.Net.Mail. Implicit SSL would have the entire connection is wrapped in an SSL layer. A specific port would be used (port 465 is common). There is no formal RFC covering Implicit SSL.

Implicit SLL would go something like: Start SSL (start encryption) -> Connect -> Authenticate -> send data

This is not considered a bug, it’s by design. There are two types of SSL authentication for SMTP, and we only support one with System.Net.Mail (by design) – Explicit SSL.
Joe Payne
AbleCommerce Custom Programming and Modules http://www.AbleMods.com/
AbleCommerce Hosting http://www.AbleModsHosting.com/
Precise Fishing and Hunting Time Tables http://www.Solunar.com

User avatar
AbleMods
Master Yoda
Master Yoda
Posts: 5170
Joined: Wed Sep 26, 2007 5:47 am
Location: Fort Myers, Florida USA

Re: 5.7.1 Client was not authenticated error using Exchange mail

Post by AbleMods » Thu May 10, 2018 1:41 am

Ok, some more information that might prove useful to folks. And for my own sake when I forget and need to find this again :)

The SSL issue was only part of the problem. That was resolved, but then we couldn't overcome a more challenging error:
Error 5.7.60 Client does not have permissions to send as this sender
Here's the deal:
Certain hosted email solutions utilize Microsoft Exchange Server as the mail server. Most notably Office365, but there are many others out there reselling Exchange Server mail services.

In older flavors of Exchange Server, specifically Exchange 2010 and Exchange 2013, there was a lax security setting. Once you authenticated SMTP with valid mailbox credentials, you could send an email to anyone and make the FROM address be anything you want. This proved especially beneficial when you wanted an Able install to use the store email credentials to log into the server, but needed the FROM address to represent something else like 'sales', or 'service' or even the actual admin user performing the action.

in Exchange 2016, this security setting is now disabled. Once you authenticate SMTP with credentials, any emails you send must have the FROM value match the email of the credentials you used to authenticate. I get why it was done. This helps stop spammers from spoofing the FROM address when an email account gets compromised. However, it also breaks certain store setups. For example, you might have your SMTP set to log in as 'tracking@yourdomain.com' but want all the store emails to appear from 'sales@yourdomain.com'.

With this new security, that is no longer possible. You will get errors like described above on every store email that tries to go out the door.

The simple solution: The store default email FROM address must match the email for the SMTP credentials you are using the authenticate the mail server. So if you're logging into SMTP with 'sales@yourdomain.com', then the default FROM addresses in the Able store MUST ALL BE 'sales@yourdomain.com'.

Alternatively, there is a "send-as" permission in Exchange Server that will permit using a different FROM address. The gotcha is that FROM address must be in the same domain and an actual mailbox configured on that same mail server. And you need to be lucky enough to get a support tech on the phone that knows what the hell they're doing. We were not :(

This all came about because the client's email provider upgraded their mailboxes from Exchange 2010 to Exchange 2016 without announcing anything to the client. So the client had no reason to suspect any changes were made. It took two days of back-and-forth with various technical resources before it was finally learned "Oh yea, we migrated those boxes to 2016 the other day." Ugh.
Joe Payne
AbleCommerce Custom Programming and Modules http://www.AbleMods.com/
AbleCommerce Hosting http://www.AbleModsHosting.com/
Precise Fishing and Hunting Time Tables http://www.Solunar.com

Post Reply