Thunderbird won't accept correct password for outgoing email

[wmgo...@gmail.com]

About a week ago I was suddenly unable to send any email out from my one email account with Cox. The regular dialog box came up instead asking me to "Retry" or
"Enter a new Password". To test that I wasn't entering the wrong email, I put my password on Notepad (Windows 7), logged into my account on Cox and copy & pasted the password into the login dialog box. It worked fine. Still the same copied text would not let me send email from Thunderbird. I checked the Password in Options menu and it is exactly correct.

Any ideas as to why it is not working?

Bill

[T]

Hi Bill,

My notes on the subject/ Let us
know the result

-T

Thunderbird constantly loses saved passwords:


Reference:
http://forums-test.mozillazine.org/viewtopic.php?f=39&t=2902343
https://bugzilla.mozilla.org/show_bug.cgi?id=441889#c28


1) exit Thunderbird

2) Rename key3.db and logins.json from the user's Thunderbird profile
directory

3) Restart Thunderbird and re-enter passwords


Note: as of Mozilla 32, the correct file to be removed was
changed from signons.sqlite to logins.json.

[Grant Taylor]

I don't think I've ever had the simple situation where the correct
password did not work.

I have had situation where something else was wrong and the dialog box
kept popping up and acting as if the wrong password was used.

This was frequently a problem with (lack of) encryption or some other
aspect of the SMTP server.

My go to tool for something like this is a traffic sniffer and mail
server logs.



--
Grant. . . .
unix || die

[T]

On 02/06/2018 07:24 PM, Grant Taylor wrote:
> I don't think I've ever had the simple situation where the correct
> password did not work.

Check out this bug report I filed on the issue:

https://bugzilla.mozilla.org/show_bug.cgi?id=1170331

[rol...@logikalsolutions.com]

Sorry,

using different keyboard this morning and hit something I shouldn't.

I would suggest you first visit the COX site which gives instructions for setting up your email client. These _should_ have changed. If they still match what you have, don't assume they are correct. Most email providers/services have dropped plain text and other low security connections in recent months. This is all part of combating identity theft, terrorism, hacking, insert-whatever-you-like-here.

Oh, the other 10% of the time this happens, your problem is that their server is down. I used to run into this with justhost.com and 1and1.com a lot. The Web portal would work, but my client couldn't get in, sometimes for days. After spending __oceans__ of time on hold either via phone or their "chat window" I would get a technical support person who only checked the Web interface. After a virtual screaming match they would escalate the problem. Eventually they would be forced to admit that a server controlling access to the email server was having a problem and needed to be rebooted.

rebooted = the Microsoft solution to everything

[rol...@logikalsolutions.com]

On Tuesday, February 6, 2018 at 2:54:03 PM UTC-6, wmgo...@gmail.com wrote:

While I haven't used Windows in roughly a decade, this is not an unusual scenario. The Web portal uses a different interface.

90 percent of the time this happens when your email host decides to increase security. The IMAP/POP server gets switched from plain text to TLS or some other encrypted communication. They are _supposed_ to change the port. Usually they do set this up on the traditional port, but the other one is left in a zombie state. Logins are disabled but connections not refused.

[NFN Smith]

rol...@logikalsolutions.com wrote:
>
> 90 percent of the time this happens when your email host decides to
> increase security. The IMAP/POP server gets switched from plain text

> to TLS or some other encrypted communication. They are_supposed_ to

> change the port. Usually they do set this up on the traditional port,
> but the other one is left in a zombie state. Logins are disabled but
> connections not refused.

I just walked a user through this scenario about an hour ago. It was a
quirky situation, where her connectivity provider had changed. (the
provider killed her email account with the connectivity account -- she
reestablished the mail account but couldn't connect). On further
inspection (and comparison with the provider's instructions for mail
client configs), I found that they're specifying SSL and port 993, and
her settings were open text and port 143. When I changed the settings
to the provider's preferences, connection was reestablished.

Normally, there's only 5 settings for a POP or IMAP connection: host
name, port number, encryption methodology, user id and password. If the
server is refusing connections, and assuming that the account is valid,
then it means that one of those settings is incorrect. Unfortunately,
the error messages don't do much to establish the reason for a failed
connection.

One exception to that rule -- if the server admin has had reason to lock
the account, that will prevent the user from logging in, and the error
message that's normally shown to a user indicates an authentication
error. It's actually the server that's refusing the connection, rather
than user specifying wrong credentials, but the error shown implies a
credentials problem.


Smith

[rol...@logikalsolutions.com]

On Wednesday, February 7, 2018 at 12:38:17 PM UTC-6, NFN Smith wrote:

> One exception to that rule -- if the server admin has had reason to lock
> the account, that will prevent the user from logging in, and the error
> message that's normally shown to a user indicates an authentication
> error. It's actually the server that's refusing the connection, rather
> than user specifying wrong credentials, but the error shown implies a
> credentials problem.
>

A locked account wouldn't let them log in from the Web interface though. Most likely their email provider switched to port 993 with TLS and they still have Thunderbird configured for plain text on a different port.

[NFN Smith]

I implied that, but didn't state it specifically. If the user can
connect through webmail, then it's not a locked account. It's just that
if an account is locked, then the error response the same, where the
server is rejecting the connection because of failed credentials
exchange. It doesn't explain *what* the failure is, whether it's a
mismatch of user ID and password, wrong port, or that the provider has
locked the account.

From my description, I did suggest that I agree that the likely problem
is that the user is not using port 993 and/or not using the correct
encryption setting.

Smith