Thunderbird 78, OAuth2 and non-OAuth2 issue
I raised this question before but still could not find a good answer (thanks to the person that answered my question, although it did not work for me)
I have 2 email accounts, say A and B:
A: IMAP and SMTP (auth) under a mail server without OAuth2 support (ie. normal password authentication)
B: IMAP and SMTP (auth) under a mail server with OAuth2 support. To be specific, it is a Microsoft365 server.
I have got Thunderbird (tried 78.11.0) with 2 accounts A & B set.
- Logon to account A, OK with IMAP access, OK with SMTP auth
- Switch to account B. OK with IMAP access, tried SMTP auth and it is OK
But everytime after sending emails (with SMTP auth) with account B, when I switch to account A and try sending emails, it asks for SMTP auth password. After typing password for SMTP auth and get the mail sent, when I click 'Get Mail' button under account A, Thunderbird asks for password (for IMAP of A). Typing these passwords (actually same password) twice and it is OK for account A.
However, everytime after sending emails with account B, when I try sendmail emails with account A, Thunderbird *must* ask for password for both SMTP-auth and IMAP under account A. Note that I did not choose 'save password' for account A.
I have checked cookie-setting, and it should be accepting all Third-party sites cookies.
So, I wonder if there are issues with OAuth2 under Thunderbird which affects my non-OAuth2 profile. Note that account B (OAuth2) works perfectly. Thanks.
P.S. : probably I should write down the exact steps to produce the problem
(assume that both accounts A and B are set)
1. Logon account A (non-OAuth2). Thunderbird asks for password. Type in password (without saving password). 2. OK with email ready. 3. Trying sending emails under account A. It asks for password. Type in password and mail could be sent. 4. Click 'Get Mail' under account A. OK (without asking for password, assuming that Thunderbird is remembering my password until I quit Thunderbird) 5. Send another email under account A. OK without asking for password again. 6. Choose account B (OAuth2). Thunderbird does not ask for password because I did the OAuth2 enrollment with Microsoft365. 7. Click 'Get Mail' under account B, OK (no password asked). 8. Send email under account B, OK (no password asked). 9. Then choose account A. When try sending emails under account A, Thunderbird asks for password! 10. After typing password and get the mail sent. When I click 'Get Mail' under account A, Thunderbird again asks for password. 11. After typing passwords twice for both (9) and (10), Thunderbird works ok by 'remembering my password'. 12. But everytime after doing (8), it would end up (9) and (10) that Thunderbird seems to forget my account A password.
Note that during steps 1-12, I do not quit Thunderbird...
Modified by domcylai
All Replies (8)
everytime after doing (8), it would end up (9) and (10) that Thunderbird seems to forget my account A password.
If you don't want to enter your password repeatedly for account A, then tell Thunderbird to remember the password. It's as simple as that. There is no relation between accounts A and B wrt the password prompt. After all, it's the provider's server requesting the password (or not), not Thunderbird.
christ1 said
everytime after doing (8), it would end up (9) and (10) that Thunderbird seems to forget my account A password.If you don't want to enter your password repeatedly for account A, then tell Thunderbird to remember the password. It's as simple as that. There is no relation between accounts A and B wrt the password prompt. After all, it's the provider's server requesting the password (or not), not Thunderbird.
I don't understand what you are talking about. If I type in the password of account A, doesn't Thunderbird cache the password under some process memory (even without clicking 'save password' during login dialog box) until I quit Thunderbird program? At least it is the default behaviour when only having account A as profile under Thunderbird. You DO NOT NEED to type the password over and over again when you click 'Get Mail' button (of course, once you quit Thunderbird and start it again, you need to type in the password again).
Modified by domcylai
Thunderbird does not do any password caching, unless you tell it to remember the password. When you get a password prompt, then this is the server requesting the password from the client (Thunderbird).
christ1 said
Thunderbird does not do any password caching, unless you tell it to remember the password. When you get a password prompt, then this is the server requesting the password from the client (Thunderbird).
I have been using Thunderbird since version 1.0. I have been having no problems accessing account A under Thunderbird for over 10+ years. It is until recently when I attempt to add account B which is under OAuth2. Surprisingly account B works but it makes account A profile that keeps on being asked for password. While I agree that it is the server which asks for password, I doubt if it is because Thunderbird presents a wrong password. Will look at some server log on tomorrow.
In fact by briefly looking at the source code (I haven't got intensive workout on this though), Thunderbird indeed remembers the password until it is quitted.
Source code file: comm/mailnews/imap/src/nsImapProtocol.cpp Under the function nsImapProtocol::GetPassword(...):
/**
* Get password from RAM, disk (password manager) or user (dialog) * @return NS_MSG_PASSWORD_PROMPT_CANCELLED * (which is NS_SUCCEEDED!) when user cancelled * NS_FAILED(rv) for other errors */
nsresult nsImapProtocol::GetPassword(nsString& password,
bool newPasswordRequested) {
// we are in the imap thread so *NEVER* try to extract the password with UI
NS_ENSURE_TRUE(m_imapServerSink, NS_ERROR_NULL_POINTER);
NS_ENSURE_TRUE(m_server, NS_ERROR_NULL_POINTER);
nsresult rv;
// Get the password already stored in mem rv = m_imapServerSink->GetServerPassword(password); .........
One interesting thing which I have found is (under a non-OAuth2 account): 1. when one connects to IMAP server, there is a connection made between Thunderbird and the IMAP server. I choose to set "maximum number of server connections to cache" as 1, in order to better picture the issue. 2. This IMAP connection is persistent - same source tcp port and same destination tcp port (993 for dest). It stays the same no matter how many clicks on 'Get Messages' button. 3. Send an email by SMTP auth. After typing in password for SMTP-auth, the mail is sent. 4. The 'persistent' connection in (2) terminates. When one clicks 'Get Messages', another new IMAP connection is made between Thunderbird and the IMAP server. As Thunderbird has already cached or memorized the password, it does not ask for password and it makes a new connection. Note that I do not have 'save password' option on: the password is being memorized until I quit Thunderbird.
But after adding another account B which is an OAuth2 account, after sending emails by using account B, when I am back to account A to send an email, it asks for password. It looks like that Thunderbird forgets the password of A. So, what I doubt is if:
- when sending emails with OAuth2, the oauth2 code clears up all memorized passwords under RAM.
- since it is obvious that after sending emails (SMTP-auth), the existing IMAP connections must be terminated and Thunderbird will establish new IMAP connections. If the password is being 'forgotten', it is obvious that it asks for password again. It is not that the IMAP server asks for password. It is Thunderbird which finds that the 'password' is empty! (password.IsEmpty())
I am trying to write some debug flags to assert my hypothesis, but the compilation goes slow. If my assertion is correct, this means that there are issues with oauth2 codes...
Modified by domcylai
This issue about not remembering unsaved password for the session has been raised in bugzilla. https://bugzilla.mozilla.org/show_bug.cgi?id=1673446
Thanks for the pointer. Glad to hear that I am not the only victim. In fact, I made some debug flag and verified that when Thunderbird asks for password, it is due to "Password.isEmpty() == true"...
I am surprised that this issue still hasn't been fixed for a pretty long time...
I too have this problem, including with 91.0.3