My email client was working fine and suddenly it’s acting like my password is wrong, but I know it isn’t.
OR
I was setting up my email client for the first time and it acts like my password is wrong, but I know it isn’t.
My email client was working fine and suddenly it’s acting like my password is wrong, but I know it isn’t.
OR
I was setting up my email client for the first time and it acts like my password is wrong, but I know it isn’t.
We semi-frequently (as often as once every 2 days, as little as once a week) receive contacts about login failures from email clients like Outlook or Thunderbird, which state that the login failed, password was incorrect, whatever the error. Sometimes the clients claim that the email client has been working fine before, and that nothing changed on their side. They are insistent that the password is correct in their email client, and that it works when testing it in webmail.
It is important not to overthink this issue, as it can lead you to desire a resolution that we can’t offer (as it doesn’t exist). If your email client is failing to log in with an authentication error, it means either your mail client is misconfigured or that it’s submitting the wrong password to us. If you’re absolutely certain that you’ve entered the password correctly and that your email client is configured properly, you’ve not identified an issue with our service, you’ve either identified an error in your logic or that your email client is not functioning properly. I’ll explain:
When you create an email account or change the password for one, it writes the hashed password to a shadow file (much like the standard Linux authentication system). That file is read by Dovecot to authenticate the user. Whether you use Outlook, Thunderbird, Apple Mail, Webmail, or any other email client, Dovecot reads that same file. If it works from any location (you should test with webmail to rule out external factors), then the shadow file is not corrupted and Dovecot is able to read it. We’ve never actually witnessed a corrupted shadow file, to add that note.
So what do you do if all of this sounds like you, and you still get authentication errors from your email client? Truthfully, I don’t know. When customers come to us with this same story there is not any server side correlation, and their insistence that they’ve done everything right really doesn’t give us anything to go on. The only correlation we’ve seen is Windows.
Maybe there’s a virus out there that breaks your passwords in email clients. Maybe there’s a Windows update going around that breaks some systems in some unexpected way that applies to the way email clients send passwords over outbound connections. Maybe there’s some user error that is so easily made but so difficult to identify that people are just making the same mistake repeatedly.
The only thing we know for sure is that this scenario is not a server side event, and that we can’t identify the cause.
When configuring your email client, we use universal standards. These are ports and how you should use them:
IMAP:
SSL: 993
Non-SSL: 143
POP3:
SSL: 995
Non-SSL: 110
SMTP:
SSL: 465
Non-SSL: 25
STARTTLS: 587
Typically the default port/SSL settings in your email client are fine, you just change the hostnames and login information.