"Sending of password for user XXXX failed..."
I'm running Ubuntu 18.04. Would update to latest Ubuntu LTS but our internet is really slow and it's capped. Thunderbird version 91.9.1. I use TB to retrieve/send emails from two Gmail accounts. Both are set up as POP. This morning TB failed to get email from the second email account. First error message is "Sending of password for user XXX did not succeed. Mail server pop.googlemail.com responded: Username and password not accepted." I clicked OK, got second message. "Login to server pop.googlemail.com with username XXX not accepted."
Fortunately our main email account is still working.
Looking at Password Mgr in TB, I have 5 entries. There are two "mailbox://pop.gmail" entries, one for each email account. There are two "smtp://smtp.googlemail.com" entries, again one for each email account. There's one "oauth://accounts.google.com entry. This one has an extremely long password. 40 or 50 characters?
I read some stuff about OAuth but it's confusing. Read some instructions for tweaking TB to use OAuth but I don't want to break one or both accounts!
Alle antwurden (12)
You need to remove all entries in the password manager that contain your accounts' actual passwords. See https://support.mozilla.org/questions/1378697
All passwords? Even the oauth2 entry? I've been reading up on this and some people seem to think that the oauth password is stored in TB's Password Mgr.
I'm confused about that part of the larger problem. Trying something when there's conflicting (or at least unclear) advice hasn't worked out too well in the past.
Another question - does it have to be IMAP instead of POP? Isn't POP more efficient for poor connections? I've always thought that POP is better for us because it gets new messages one time instead of every time I log in. Is that wrong?
OK, this is weird. My experience was - um - "similar" to advice given in the above link but differed in some ways too.
First off, cookies were enabled in TB so I left that alone.
I went to TB Server Settings. Looked at the data for the primary email account. The one that's working. The first field, "Server Settings", showed Server type as POP. Looked below to "Security Settings", then "Authentication Method". The main email account was already set to OAuth2. That was a surprise. When did that happen?
The "Outgoing Server" was set to "Gmail - smtp.gmail.com (Default)". Below this were "Details of selected server:" The authentication method was OAuth2. I was expecting to find separate outgoing server settings for each account but there was only the one.
I clicked on the secondary email account, the one that failed this last week. Set up as POP, just like the primary account. The Authentication Method was set to "Normal Password". Changed it to "OAuth2".
Did not close out of the Server Settings window. While writing down some notes a window popped up from Google saying that Thunderbird wanted access to the secondary gmail account. It asked for the password. I typed the Google password in. Clicked the button. Gmail came back with another window. Don't recall the exact message but something about access. I clicked "Allow".
At this point it seemed like the thing to do was close TB and restart it. The secondary account, the one that had not been working, got new mail!
I didn't have to change to IMAP. I didn't have to clear the TB Password Manager. All I did was change the Authentication Method of the secondary gmail account to "OAuth2". I didn't even close out of the TB Server Settings before Google was asking about allowing TB to access the account.
Thanks, and have a great day!
Bewurke troch Telkwa op
I don't know if this helps at all, but this is what worked for me today. My Gmail POP and SMTP stopped working. I updated to Thunderbird 91 and changed the following settings. First I deleted my pop.gmail.com entry in the password manager. Then:
1. Select the `Account Settings` menu item from the `Tools` menu.
2. Click on your Gmail account and choose `Server Settings`.
3. Change the `Authentication method` pop-up menu to `OAuth2`.
4. Click on your `Outgoing Server`. Click the `Edit` button and change the `Authentication method` pop-up menu to `OAuth2`.
I did not change any other settings. That solved the problem for me.
Hi, arandor - Thanks for sharing what worked. Glad you got it fixed.
Your message prompted me to go back and look at the "Outgoing Server" settings. Now I see how to change the authentication by clicking on the "Edit" button. Yesterday I didn't put it together even though it was right there.
I assume you're using Windows? Accessing the settings in the Ubuntu version of TB is a little bit different than Windows.
Both of my accounts got mail this morning, so it's still working. Even though I did not delete any of the entries in TB's Password Manager. Odd.
Telkwa said
Both of my accounts got mail this morning, so it's still working. Even though I did not delete any of the entries in TB's Password Manager. Odd.
Deleting the old password entries from Tbird's password vault is not absolutely necessary, but in some cases the authentication process fetches and uses those entries even after the authentication method has been changed in Account Settings. Sometimes this happens even without a change in authentication method. One of my Gmail accounts, despite having an OAuth2 entry in the vault dated 2019, suddenly failed to authenticate and fetch mail weeks ago, and when I opened the vault, I noticed an old password entry dated 2016 had been last accessed that same day while the OAuth2 entry had not been accessed for days. I had to delete the OAuth2 entry and the old password entry to force it to authenticate afresh. Other Gmail accounts also had old password entries in the vault, but Tbird was correctly using their OAuth2 entries instead. I deleted the old entries just to avert the off-chance of Tbird trying to use them down the line. I don't know what causes it. It's probably a bug, but since there is the workaround of manually managing them, I don't think reporting it will bear much fruit. Fortunately, it's not something you have to tinker with frequently.
There are several threads here in which users have had to manually update password entries in the vault after they've changed their account's passwords because the password prompt wouldn't save the new password in the vault despite the remember option being checked.
Stans - Thanks for your reply with more details.
I do have a question - you mentioned that you could see an old password dated 2016 had been accessed recently. How could you tell when it'd been accessed? I've got Password Mgr. pulled up right now. There's a column for "Last Changed" but I don't see anything re: "last accessed".
The Password Manager has two "oauth:/" entries now. One for the primary email account, which was already there, and a new one for the secondary email account. The new entry shows "Last Changed" Jun 7, 2022. I guess that's as it should be.
I'm nervous about deleting the other four entries in Password Mgr. There are two for the primary email account. One is "mailbox://pop.gmail.com" and the second is "smtp://gmail.com".
The secondary email account also has two entries but they're not quite the same. One is "mailbox://pop.googlemail.com" and the other is "smtp://googlemail.com". I have no idea why that would be.
I set up the primary account in 2007 and the secondary account in 2015. Maybe that has something to do with it?
If everything keeps working for a few weeks, would you suggest leaving Password Mgr. alone? Or deleting the four old passwords? I think what you and others have been saying is once TB is using oauth correctly there's no need for the old passwords?
To the right of the Last Changed column, there is a tiny icon that when clicked, drops down a list of the columns availabe in the vault so that you can enable/disable them as you wish. One of them is the Last Used column.
I think what you and others have been saying is once TB is using oauth correctly there's no need for the old passwords?
That's right.
If everything keeps working for a few weeks, would you suggest leaving Password Mgr. alone? Or deleting the four old passwords?I would delete them sooner rather than later, so that Thunderbird doesn't somehow fall back to trying to use them.
The secondary email account also has two entries but they're not quite the same. One is "mailbox://pop.googlemail.com" and the other is "smtp://googlemail.com". I have no idea why that would be.
pop.googlemail.com and pop.gmail.com are both valid Gmail servers. The former server name has been around for longer. I don't know how the younger account ended up using a different server name, but that shouldn't be a cause for concern. They both resolve to Gmail servers and your accounts should be accessible regardless of the Gmail server names Thunderbird uses.
Thanks again for your replies.
I saw that tiny icon you described. I thought maybe clicking that icon would rearrange the entries by date, or name, or etc. so I just left it alone.
I was tempted to click the "problem solved" button although your latest reply didn't provide the breakthrough. All of your replies were helpful and provided details that helped me wrap my arms around the problem.
I hope your input will help others who find this thread.
This is a drive by comment. I have not read everything. So please excuse if I repeat.
Access your account settings and change the googlemail server names to gmail. oauth appears to have issues with old settings using googlemail server names for some reason.
I feel fortunate that I haven't broken something yet.
I'm sure what you suggest is valid but it's working for now. Reluctant to just start changing server names.
Umm, don't delete your old manually created passwords after getting OAuth to work.
I recently moved on from Ubuntu 18.04 to 22.04. I didn't overwrite 18.04. I installed 22.04 to a different PC and left the 18.04 PC untouched. While trying to get everything working on the "new" 22.04 PC like it was on the 18.04 PC, Thunderbird asked for passwords for our two gmail addresses. Well, which passwords? The ridiculously long OAuth passwords? Or the old ones that are supposedly safe to delete?
I entered the old manual passwords and TB started to get the mail on the 22.04 PC. Good thing those passwords were written down in other places, because I'd deleted them from TB Password Manager.