I have follow this setting and it is working few months back after I enable the SMTP Authentication in Office 365, and also with app password generate in Office365 page. Here is the setting from managerio I use: Microsoft Office 365
I have tested regenerate the app password but no luck. Please help.
The settings you have for manager are correct. Here is an example of a company using 365 and all works OK. What you may need to do is tell 365 to OK a third party app, a little like what needs to be done with GMail smtp. Usually your Microsoft cloud reseller can assist with this as they would manage your domain / tenant.
Another quick test to confirm you have the correct credentials for your mail settings is to login to you 365 webmail using the credentials in your Manager System. If it works for Webmail login then you know that you have the correct account information at least.
no worries the path I would have investigated isn’t a problem for win10, if you have an issue there, you’re better off diagnosing it as per other’s suggestions. I don’t use office365, but I do believe it’s possibly tied to the email address.
In your case, try your real email address and not the alias. good luck
Thanks all for the information. Tested with port 25 also the same. I confirm that the setting for office365 smtp is correct because it is working fine last few months after I enable the SMTP Authentication in office365 admin page. Just recently this happen may be there is chances in O365 which I also log a case to Microsoft. is there anyone who is using O365 SMTP with “app password” (using app password because my account using MFA), which is working fine out there? Or may be managerio cannot support latest TLS?
I tested also in Win10 with latest ManagerIO. and here is the error: The SMTP server requires a secure connection or the client was not authenticated. The server response was: 5.7.57 SMTP; Client was not authenticated to send anonymous mail during MAIL FROM [SG2PR06CA0174.apcprd06.prod.outlook.com]
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:
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.
@lubos, I don’t know if this is the answer, but something like this line of code may help:
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:
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
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.
Thanks d3mad and Patch for detail information. Windows and mac received different errors.
Windows is using the .net v4.8, here is the error msg: The SMTP server requires a secure connection or the client was not authenticated. The server response was: 5.7.57 SMTP; Client was not authenticated to send anonymous mail during MAIL FROM [SG2PR06CA0174.apcprd06.prod.outlook.com]
Since the old TLS going to be retired on October, I believe they are still using the old TLS now. So I also log a case to Microsoft to clarify this. There is no changes in ManagerIO version when this issue happen, so I think there should be some changes in O365.
@lubos, what does manager default to? I think that is the pertinent question. If you haven’t set the default to v1.2 or you are not using the system default, then manager doesn’t support servers that reject v1.0 since dotNet4.6.61 uses the wrong one. It has been extensively reported on.
Since lubos has indicated Manager supports the required TLS, and at any rate you’re on Net4.8, there is obviously an issue with the credentials.
You need to work out at what layer it’s happening, since the mail server doesn’t usually indicate TLS errors you’re going to have to look at packet captures. Having said that, you are getting explicitly not authenticated for anonymous mail Which to me does sound like a login issue. Perhaps that may be the same error with TLS, I’m not sure.
I think @lubos and @d3mad is right. Gmail smtp is working in both mac and windows. My O365 is using MFA so I generate an app password for the Manager IO smtp email. I have been changing few app password to test but all failed. I think i need to check with Microsoft regarding this.
I have read on a few posts (stack exchange, reddit and others) that sometimes it does take multiple password changes, and attempts to login, change password again, attempt again, rinse and repeat. There’s no indication what’s wrong with the password or the process, but eventually it may work and you can then revert back to your original credentials. However, I think that is more an issue with their load balancing and that not all servers are configured the same.
I also found several articles stating MS was deprecating TLS1 and 1.1 from 2018 and 2020.