Office 365 SMTP - 535 5.7.3 Authentication unsuccessful

[d3mad]

@funyjoker

5.7.57 SMTP; Client was not authenticated to send anonymous mail during MAIL FROM

In one of the manager upgrades recently, there was a dot net upgrade as well. I have been investigating this from another angle and for linux and sometimes OS X there does seem to be a tls issue. But all tests that I have seen this usually isn’t a problem on windows systems. That’s because the implementation in Windows uses the native dot net and is likely to have a greater version installed anyway, whereas OS X and Linux use mono and whatever lubos incorporates into the package. I haven’t got to the bottom of it yet and hence I haven’t posted my research on it, it’s not complete. However, you can verify it yourself if you can capture packets between the manager computer and your router/the outside world. A browser isn’t sufficient, you need something like wireshark to get to the bottom of it and if it is a tls issue it will show it’s ugly head in the packet captures. The issue stems from the fact in the version of dot net that manager uses, the default credentials are not set correctly. It was fixed one or two subversions later (from 4.7).

There is a workaround that MS suggests and it is possible that option 3 might be an option, but requires a little but of effort on your part. I’d be more hopeful that lubos can look into setting a default value, posted below.

I started posting about it here, but never really finished getting to the bottom of it:

Message could not be sent error on Ubuntu install

Ok, so my installation is using TLSv1.0. [Screen Shot 2020-09-02 at 5.43.33 pm] And it appears gmail supports it and my router is obviously allowing it to pass (I used packet capture in my router to grab this). For giggles I downloaded the AppImage for 20.8.93 and it also is using TLS 1.0 So I’m not sure if that is manager related, mono related or some other OS component related. Is it the WSL and Synology boxes that are blocking the TLSv1.0 transfer?

So it’s only partly a manager fault, the other part is a security requirement at the other end on your mail server, it is not allowing TLSv1 and enforces TLSv1.2 or higher, but dot net less than 4.7 not defaulting to a more secure connection. From what I understand of the handshake (this is a very laymans paraphrasing from a guy who doesn’t fully understand: ME!), the server accepts the v1 handshake enough for it to then reject the certificate because it wants a more secure connection.

The reason why the security protocol did not default to TLS 1.2 is because there is no default value for this in .NET Framework 4.6.1. Sorry if this is reiterating what’s already been said but I wanted to elaborate and I don’t have enough reputation to comment.

from:

.Net Framework 4.6.1 not defaulting to TLS 1.2

@lubos, I don’t know if this is the answer, but something like this line of code may help:

System.Net.ServicePointManager.SecurityProtocol =  System.Net.SecurityProtocolType.Tls12

I don’t know if that is the precise line, you’ll need to look into further. You might want to start here:

Transport Layer Security (TLS) best practices with the .NET Framework - .NET...

Is TLS 1.1 and TLS 1.2 enabled by default for .NET 4.5 and .NET 4.5.1?

Cannot connect to a server by using the ServicePointManager or SslStream APIs...

this looks VERY pertinent, I’m not sure what version @lubos upgraded NET4.6.1 from, but previously it wasn’t an issue, it seems only 4.6, 4.6.1 and possibly 4.6.2:

Starting with the .NET Framework 4.7, the default value of this property is SecurityProtocolType.SystemDefault. This allows .NET Framework networking APIs based on SslStream (such as FTP, HTTP, and SMTP) to inherit the default security protocols from the operating system or from any custom configurations performed by a system administrator. For information about which SSL/TLS protocols are enabled by default on each version of the Windows operating system, see Protocols in TLS/SSL (Schannel SSP).

For versions of the .NET Framework through the .NET Framework 4.6.2, no default value is listed for this property. The security landscape changes constantly, and default protocols and protection levels are changed over time in order to avoid known weaknesses. Defaults vary depending on individual machine configuration, installed software, and applied patches.

Your code should never implicitly depend on using a particular protection level, or on the assumption that a given security level is used by default. If your app depends on the use of a particular security level, you must explicitly specify that level and then check to be sure that it is actually in use on the established connection. Further, your code should be designed to be robust in the face of changes to which protocols are supported, as such changes are often made with little advance notice in order to mitigate emerging threats.

The .NET Framework 4.6 includes a new security feature that blocks insecure cipher and hashing algorithms for connections. Applications using TLS/SSL through APIs such as HttpClient, HttpWebRequest, FTPClient, SmtpClient, SslStream, etc. and targeting .NET Framework 4.6 get the more-secure behavior by default.

Developers may want to opt out of this behavior in order to maintain interoperability with their existing SSL3 services OR TLS w/ RC4 services. This article explains how to modify your code so that the new behavior is disabled.

ServicePointManager.SecurityProtocol Property

so it seems to me this is the pertinent value:

• prior to 4.6 everything worked, was probably using SSL3
• at 4.6 SSL3 was dropped, the most secure was preferred (we’re not on this)
• at 4.6.1 (not sure)
• at 4.6.2 nodefault set and so what applications sets as default, minimum, and doesn’t take into consideration what the server wants because as far as it’s concerned starttls worked, it thinks???
• at 4.7 system default set

ServicePointManager.SecurityProtocol Property (System.Net)

Anyway, most dotNet stuff is beyond me, lubos is going to have to look into it further if mail servers are going to reject TLSv1 connections, which appear to be happening more and more, and anything less than NET4.7 requires developers to take action.