Hello,
When selecting a custom email server, port 587 (submission), ticking “use SSL” and “server requires autentication” (typo that needs to be fixed BTW), the password is not correctly sent to the server (base64) which results in a login failure to the server.
Thank you,
Demetris Demetriou
deZillium LTD
email authentication failure happens because you may have enabled two-step authentication or any such feature with your email provider.
though this is not a problem with Manager, solutions have already been provided on the forum few many times. please search the forum.
No, email authentication (edit:) failure happens because Manager doesn’t’ send the password as it should send it.
No two-step authentication has been enabled, and I’m actually the email server administrator. Email authentication works in Outlook, Thunderbird, Roundcube, K9-mail (android), stock android email client, stock iOS email client.
which email service provider are you using?
have you checked allowing access on less secure apps?
Using a postfix server (I’m the service provider) which works for the few thousand emails going through it every single day (hence there are zero issues with the provider side of the equation, it’s all an issue with the client side of the equation (hence Manager)).
There are no additional security measures implemented (no 2FA, no gmail’s “less secure apps”, nothing of that sort). Just plain old username and password. Authentication fails at the password stage (with the base64 string as answered by the server (hence 100% password not sent correctly issue)).
if it was an issue with Manager all users including me who use custom server for sending emails would experience problems. but that is not the case. i personally have no issues at present.
Google, Microsoft and Yahoo don’t admit to using a testing policy for their SPF records for the past 12 years, with the same excuse of “if it was broken, we would have known by now”.
Just because something works, doesn’t mean that it is working correctly. You may be using custom email servers, but there are zero guarantees that they work as expected. They may not even be asking for authentication and could be open relays for all you know.
See above for the list of clients that correctly authenticate to the server. Every single client tested so far works correctly, manager doesn’t, and it’s somehow not an issue with manager? Doubtful.
Anyway, I’m adding this to the list of things people don’t bother fixing (ie Paypal’s email servers’ lack of ECC certificate support), all of them being in the “if it was broken, we would have known by now” category.
Going through the documentation, we find this “gem”:
Caution
Email settings cannot be tested until you have clicked Update.
Clicking on update, then clicking on testing correctly authenticates to the server. So the tested configuration wasn’t correct afterall, would you look at that! Turns out it wasn’t any 2FA, nor unsecure apps, it was a form not being correctly used by the program.
This is a bug that needs to be fixed, or the warning should be put right there on the settings form. Please correct the “autentication” text as well.
How is this a bug? You have entered information into your email settings. Until you click Update, those settings will continue to be used. When you update those settings, the new ones will be used. How else would you expect things to work? The test feature is so you don’t have to send an actual accounting document to verify things work.
This is a bug because it is not the expected behavior (ie the very definition of a bug).
A user looking at the form expects that when settings are changed and the test button is pressed, the new settings will be used. As I’ve said a number of times, THE NEW SETTINGS ARE NOT USED. The custom mail server is correctly used. Same as the port. Also the TLS setting. Yeap, authentication too. Username as well. THE PROGRAM DOES NOT USE THE PASSWORD ENTERED INTO THE PASSWORD FIELD, UNTIL you hit update. None of the OTHER settings need to be updated in order to be tested. You can use an installation to verify this, instead of arguing whether or not this is a bug.
I’ll restate it, just for clarity’s sake: UNLESS YOU HIT UPDATE, THE PASSWORD ENTERED INTO THE FORM IS NOT USED. EVERY OTHER SETTING IS USED (can be verified using a mail server as I’ve said, you’ll see the testing attempt fail at the password prompt (you’ll get a base64 encoded string from the server, which when translated will say “Password:”, which (as the original post shows) EXPECTS A DIFFERENT PASSWORD THAN THE ONE SUPPLIED INTO THE FORM. The mail server is correctly used (since you’ll see the client hitting the server), the ssl is correctly used (since it doesn’t fail at the connection attempt), the authentication required is correctly used (since the server proceeds to ask for a password, meaning that either the username was correct, or that the server doesn’t actually show which mailboxes are valid (a server setting to prevent address harvesting)) BUT the password is NOT used. Again, on a clean installation, just fill out the form and don’t save, just hit test.
Nobody said anything about sending an accounting document. The testing function sends a test email with no document.
Again, chose a new installation, set it up as I’ve said and verify that it is a bug. The expected behavior would be:
It appears that the “Test Email Settings” button should only appear after the “Update” button has been activated, then the natural / logical flow occurs.
Or put the that button to the right of Update so that it appears to be a subsequent step. Currently to click update prior to clicking the test seems to be counter intuitive.
The screen form should be able to be used without the need to read a caution buried in some documentation. Alternatively put a message on the screen form next to the test button - click update before testing.
That would eliminate a mass of forum topics.
This. Should have checked this forum before spending an hour trying to troubleshoot why my “test email settings” kept failing. Testing button should appear AFTER “updating.” sigh.
