User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52) Gecko/20060909 Firefox/184.108.40.206
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:220.127.116.11) Gecko/20060909 Firefox/18.104.22.168
Immediately after I upgraded to version 22.214.171.124 the top account keeps asking for password "please enter a new password" most of the times the automatic "check for new messages every..." works.
This only occurs on the top of many accounts.
Tried to set mail.remember_password to true, it does not circumvent the problem.
If I manually check the mail, the problem does not happen. I tried to put the automatic check time at 1 minute (had it at 10) and surprisingly (don't know if it is a coincidence) it happens less now...
Steps to Reproduce:
1. None, it is an automatic process
*** Bug 352916 has been marked as a duplicate of this bug. ***
*** Bug 352880 has been marked as a duplicate of this bug. ***
It seems that there was a coincidence on the fact that our mail server was timing-out, but this only happened on the main account, most of the others were in the same state, so this should be investigated. It is connected with pop server timeout. I saw something on the faqs concerning this, but asking for a password when the server times out may not be the best way of handling the issue. The behavior seems to have disapeered now that the server is responding normally.
I want to correct my comment#3. The behavior is still there with the server working normally and the observed periodicity is 10 minutes, with "check new messages" set at one minute.
With "check new messages every..." turned off the described behavior continues with the same periodicity.
Can the people who can reproduce this each give us more details on how your account is set up? For example: is this pop only or does it occur in imap as well? Do you have use secure connection set to anything other than Never? Do you have Use secure authentication set?
****is this pop only or does it occur in imap as well?
got 12 accounts, one is imap, but this occurs only on the default account.
**** Do you have use secure connection set to anything other than Never?
**** Do you have Use secure authentication set?
****is this pop only or does it occur in imap as well?
got 12 accounts, one is imap, but this occurs only on the default account (pop).
**** Do you have use secure connection set to anything other than Never?
**** Do you have Use secure authentication set?
is this pop only or does it occur in imap as well?
POP only, 2 accounts. Problem occured only for the top account.
Do you have use secure connection set to anything other than Never?
I've tried 'Never' and 'TLS if available'. Problem occured in both occasions.
Do you have Use secure authentication set?
Confirmed through dupage -- *something* real is going on.
Since Tbird 2.0 contains the 126.96.36.199 security fixes, this may affect that release as well. We should definitely consider this for 188.8.131.52
Mine stopped doing it for some reason yesterday. I am POP only. Use only "never," do not use secure auth.
Do the people experiencing this happen to have special chars (or dots) in their username/password?
And are you able to try out 2.0b1pre builds? Is the problem present there also?
Just alpha-numerics in mine.
I have an @ in the default account password, no dots and I will try a 2.0 prebuild, but first I need to know:
What will happen with next upgrade, or can I go back to the previous one just by erasing the stuff and rpm a new one in just as I'm used to do under Linux?
Yes, you can install the 2.0b1pre build to another folder and have both installed (and uninstall 2.0b1pre afterwards if you like). It will work with the same profile, but of course, it's always good to make a backup of the profile before you install - just in case.
Restoring lost blocking flag
Hi, I installed version 2 beta 1 (20060919). The problem continues. Removed the Crossover theme, I was seeing triple icon rows on the toolbar and that was unfit for starting a new day... Then I observed the behavior again (you never know) but it remained the same.
What can I do more? If you want my help, I have some background on plain C and 386 assembler in spite that is not what I normally do (I'm more on hardware and dsp assembler code), but I may try to debug under your direction, because if you can't reproduce the issues you can't correct those.
I tried to withdraw all extensions from the beta version, to see what happened. The same, no behavior change.
Ok, it seems to me the pattern is that everyone who sees this problem as a pop account as the default account. If that is not correct, please say so.
If someone who sees this problem and who also has an imap account as a non-default account could set their imap account to default and see if the problem still exists that would be nice.
Finally, (I'll shut up after this), what kind of settings do the people who can reproduce this have for their SMTP servers? Do you have just one that all accounts use or do you have multiple SMTP servers for your different accounts? Do you use multiple identities support in any way?
Ok, it seems to me the pattern is that everyone who sees this problem as a pop
account as the default account. If that is not correct, please say so.
->It was correct, not anymore ;-) ...
If someone who sees this problem and who also has an imap account as a
non-default account could set their imap account to default and see if the
problem still exists that would be nice.
->I just did it, and the problem continues...
Finally, (I'll shut up after this), what kind of settings do the people who can
reproduce this have for their SMTP servers? Do you have just one that all
accounts use or do you have multiple SMTP servers for your different accounts?
Do you use multiple identities support in any way?
Got multiple pop servers (3 to be more precise) and one imap, with a total of 12 accounts. No multiple identities support is used. About "shutting up after this", well, you don't want us to install the previous version and shut up automatic updates, or do you ? :-)
(In reply to comment #20)
> Got multiple pop servers (3 to be more precise) and one imap, with a total of
> 12 accounts. No multiple identities support is used. About "shutting up after
> this", well, you don't want us to install the previous version and shut up
> automatic updates, or do you ? :-)
I was talking about myself since I am not that well informed about Thunderbird and am grasping at configuration issues to see what the differences are between people who see this problem and those who don't.
You didn't say how you have your SMTP servers configured for the different accounts.
Ok, ok, here goes a typical pop account:
use secure connection->never
check for new messages at startup->yes
check for new messages every 5 minutes
automatically download new message->yes
fetch headers only->no
leave messages on server->no
empty trash on exit->yes
copies and folders
place a copy->sent folder->accdir
keep message drafts->drafts folder on->accdir
keep message templates on->templates folder on->accdir
composition and addressing
compose messages in html->no
automatically quote->yes, above
messages larger than->no
do't delete any messages->yes
always delete read->no
imap accounts are much the same...
want me to try some different settings?
A pop3 protocol log of a session where this happens might be helpful:
I did make some changes in 184.108.40.206 w.r.t. password handling, but the main extent of it was to pass in the previously tried password whenever we prompt for a password, but I didn't intend to prompt for a password at times we didn't use to prompt for a password. When doing an automatic check for new mail, we used to just ignore errors, not put up a password prompt, and not tell the user about errors. I'm very surprised that's changed. We used to simply check if the url we run to get the new mail has a null msg window, and if so, we assumed it was an automatic check for new mail, iirc.
OK, I did it, no output at all from the log, nothing...tried to look at it before closing and after closing, the file is created and that's it...
Where did I go wrong?
Here is the batch file content
(In reply to comment #24)
Created attachment 239359 [details]
Two capture files
yeah, high-speed copy/paste and cross-reading ;-) sorry...
here you have the stuff
logme1.txt is with the AVG anti-virus proxy
logme2.txt is without.
Capture was stopped after the first occurrence of the problem
Hope it will help
it looks to me like both those logs have the AVG proxy stuff turned on. But that's not relevant, I don't think (unless it's causing your problem :-) ) In any case, I was able to reproduce this by starting up TB, leave it running, with the automatic check for new mail set for every minute, and then changed my pop3 password via web-mail. We did indeed prompt for the pop3 password, even though the msgWindow was null. I'm still not convinced that this has changed in 220.127.116.11, since the code that looks broken was not changed, but maybe somehow we never got to this code in this situation before...
it looks to me like both those logs have the AVG proxy stuff turned on.
->interesting behavior, for most of the log#2 it was off, and then you're right, it activated itself, but that's off scope (probably)...
But that's not relevant, I don't think (unless it's causing your problem :-) ) In
any case, I was able to reproduce this by starting up TB, leave it running,
with the automatic check for new mail set for every minute, and then changed my
pop3 password via web-mail.
->good to know! :-)
We did indeed prompt for the pop3 password, even
though the msgWindow was null.
->so you test the window handler and don't pop it up when it's null?
I'm still not convinced that this has changed in
18.104.22.168, since the code that looks broken was not changed, but maybe somehow we
never got to this code in this situation before...
->don't tell me you left the cat sleeping on the keyboard at night :-) Not again... ;-)
well, if I can do anything just let me know! Tracing back a bug is most often no easy burden...Good luck! :-)
Ah, I think when I fixed the problem where we would loop around trying to logon forever with a bad password, I exposed this problem. We should not be prompting for a password when there's no msg window, but we never got to this code until that other fix, I guess.
If I simply disable the password prompt on automatic check for new mail, automatic check for new mail will just silently stop working, until you click get new mail manually, and then it will start working again, once you enter your password. That would be at least as bad as the current behavior.
So I need to figure out a way to keep the potentially bad password and use it for automatic check for new mail, but prompt the user for a new password in the manual check case, if the previous attempt failed...this shouldn't be this hard but the pop3 protocol code is challenging.
Do you have just one that all accounts use or do you have multiple SMTP servers for your different accounts?
2 SMTP accounts.
Do you use multiple identities support in any way?
"So I need to figure out a way to keep the potentially bad password and use it
for automatic check for new mail, but prompt the user for a new password in the
manual check case, if the previous attempt failed...this shouldn't be this hard
but the pop3 protocol code is challenging."
->1. there is no bad password in this particular case, simulating things this way might be misleading. I will arrange you an account on our server immediately for you to test anyway, will send you the account details by private mail. This however shouldn't happen, a pop server is a pop server, and that's it...
->2. there was an annoying issue with previous TB versions, if a password was saved , if the server password was changed, the only way of regaining access to the password entry screen was to go to Options/Password/View saved passwords and delete the password corresponding to that particular account. If that could be avoided, for example re-prompting for password at the second consecutive failure, it would be a good idea.
Created attachment 239491 [details]
raw socket capture on port 110
OK, I got a clue at last, using a socket trace with a filter on port 110 (check attachment). What happened was that login is of the form:
on all but the problematic times TB sends the above (check what happened on 10:33:53.717). On failure the server sent (10:38:53:718):
and that made the password fail.
passwords are grabled, of course... ;-)
I hope that modified behavior may direct you to the bug.
"and that made the password fail."
"and that made the login fail."
As a final suggestion, it seems that we have two bugs, one leading to the other. Login should always be right, and the login window should never pop-up on automatic operation.
While there 11 or more reports pertaining to Thunderbird "losing passwords", this report (https://bugzilla.mozilla.org/show_bug.cgi?id=352801) describes exactly what I'm seeing in the 22.214.171.124 release of Thunderbird.
I have a (relatively) simple mail server setup: I have two POP accounts on the same server, and both are set to check for new mail, once every minute. Manually checking for mail (by clicking "Get Mail") always succeeds. And the automatic check for new mail succeeds every time for 9 of 10 minutes.
But every TEN minutes, when Thunderbird automatically checks for new mail, I get a pop up dialog window asking me to "Please enter a new password for user...". The password offered is correct, since if I just hit "OK", TB successfully checks for new mail. Note that the "Use Password Manager..." box is NOT checked.
This problem started when I upgraded to Thunderbird 126.96.36.199 (20060909). Also, I don't have this problem if I use the mail client that's part of Mozilla 1.7.13 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060414.
I think it's a very important clue that the problem occurs precisely every every 10 minutes, even though both accounts are set to check every ONE minute. Changing the check mail interval does not affect the 10 minute failure interval.
So, what is significant about "10 minutes"? Note that stopping and restarting Thunderbird a few minutes later changes the wall clock time of the failure event, but the 10 minute period of the failure remains the same.
If I can do anything further to help you folks track down this bug, please let me know. I'm a C/C++/Java programmer with more years of experience than I care to remember, and am willing to help however I can!
Clues gleaned from http://forums.mozillazine.org/viewtopic.php?t=465640
it asks for a password every ten or eleven minutes - even with automatic mail collection disabled
I have a hunch where problem might be.
It believe that Thunderbird 188.8.131.52 uses the wrong key in the prefs.js file when it reads the password to access the mail server the second and following times. It appears to me that TB uses the keys
the first time it accesses the mailbox, but the keys
when it tries to access the mail server the second time, or when you ask it to remember the password.
I could use the TB GUI to delete passwords without affecting the timestamp on anything in the applications or data folders. It looks as though the mechanism for storing passwords is broken, but that doesn't explain why it started bleating for passwords in the first place. The passwords I had worked perfectly well for months previously.
If I start TB it asks me for a password. I give it one and I don't check the remember box. After that, it doesn't nag me every ten minutes, only when I next start it.
Mark, can you send me your prefs.js? I can't think of any reason we'd ask for passwords other than automatic check for new mail.
I started "cleaning up" my prefs.js so I could post a simplified prefs.js that still showed the problem. But in the process of doing so, I stumbled onto what I think may be the problem: I believe that Thunderbird is using a default 10 minute interval to try to download email for inactive/deleted email accounts that still have partial entries in the prefs.js!
Many users have a prefs.js that's the product of years updates, and as such have data pertaining to email accounts that have been long ago deleted by the user. And while the user may not even know that data still exists pertaining to those old accounts (since partial account info isn't sufficient to make the account appear in the TBird's GUI), Thunderbird DOES know about them.
And in the case of this bug, Thunderbird will try to download new email for those deleted accounts as often as is specified in the prefs.js. But since there's no period specified in the prefs.js for the "deleted" account, Thunderbird uses the default, and tries to check for new mail every 10 minutes!
I'll try to post a simple prefs.js example tomorrow.
Mark, if you have the original prefs.js, that would be interesting to see. As far as I know, we don't use partial entries in the way you describe. The account, e.g., account11, has to be in the account list pref, and then the account has to point to the corresponding server, before we'll do anything with that server. If the account uses the global inbox, it won't show up in the GUI (at least the folder pane).
#34 mimics much of what I'm seeing, everything was fine until 184.108.40.206. I dont' know if this is a datapoint or a red herring: I changed providers recently and when I look at the saved passwords, I see this:
directnic is my old provider (and I have mail stored in various directnic folders in the thunderbird document&settings folder).
When I used 1.5.07, the problems immediately showed up. It would ask the password and would retrieve my mail, but when it had the directnic line in there, it would later ask again. I turned to the nightly build, which I'm now running and it started storing the smtp line. the directnic line periodically disappears. I have my accounts configured with secureserver.net, so I don't know where it is getting the directnic address.
I have cleared the password, deleted the .rdf files as I've seen mentioned on support forums. I've also deleted prefs.js but when resurrected, has references to directnic.com
Created attachment 240172 [details] [diff] [review]
biff shouldn't ever forget password
Biff shouldn't forget passwords, so check for null msg window before forgetting the password.
This patch also fixes a bug where if you have logon fallback turned off, we would loop around infinitely trying to logon, because we never incremented the logon failure count in the non-fallback case.
This doesn't fix the possible underlying issue that some people are seeing with the username vs realusername - I need to figure out if that's the real issue or not.
(In reply to comment #40)
David, did you checked the attachment on comment #32. I might give you a clue, because it induces the fault you discovered (passw window popping with null). 1 of the 2 mentioned things changed btw 1.5.05 and 220.127.116.11, either the wrong username or the wrong win behavior.
Antonio, did you send me your prefs.js? I can't remember...In particular, I'd like to look through it for the user names you mentioned in comment #32
I don't think the way we get username/passwords has changed between 18.104.22.168 and 22.214.171.124 - what changed was that we'd forget pop3 passwords in situations we didn't before.
I've checked in the fix onto the trunk and 1.8.1/2.0 branch so if anyone wants to try tomorrows trunk or 2.0a builds, they could see if the problem is fixed there.
I'll keep investigating the username vs realusername issue, when I get some more data from folks.
(In reply to comment #42)
> Antonio, did you send me your prefs.js? I can't remember...In particular, I'd
> like to look through it for the user names you mentioned in comment #32
> I don't think the way we get username/passwords has changed between 126.96.36.199 and
> 188.8.131.52 - what changed was that we'd forget pop3 passwords in situations we
> didn't before.
Hoho, I just returned from a 1kkm trip by car, by priv mail you will have the stuff, never asked before, sorry, tomorrow I will be available to discuss the stuff At first sigt there are some strange str...Cheers!
Comment on attachment 240172 [details] [diff] [review]
biff shouldn't ever forget password
approved for 1.8.0 branch, a=dveditz for drivers
Remember my comment #32? I had 2 accounts, one with login
and another with login
I had noticed that when TB asked for password was after a login with <name>. So I altered the second login to another name and the situation is still there. I can confirm that in my case what triggers the problem every 10 minutes is a bad login on the default account, by omission of the @domain. Interesting is the fact that even if I change the default account, the problem continues.
I would like to know if the other individuals experiencing the bug have the
<name@domain> login as well as me.
and not only
(In reply to comment #36)
> Mark, can you send me your prefs.js?
David, though it now may be moot, per your request I've sent my original and modified prefs.js to your mailbox.
For those of you playing along at home...
Although this particular problem may be fixed by the patch checked in by David, those of you with a morbid curiosity might be interested in my experience with problem: Thunderbird 184.108.40.206's 10-minute interval password prompts can be caused by partial email account data in the prefs.js file.
In my case, the partial email account data was from an email account I'd deleted a while ago that (for unknown reasons) didn't quite get deleted. And while some of that account data was retained in my prefs.js, I never saw any evidence of it in Mozilla, or Thunderbird's GUI, and it didn't seem to cause any problems.
But for some reason, in 220.127.116.11, Thunderbird decided to start trying to get new mail for this (partially) deleted account. Since this account was (supposed to be) deleted, there was no "check_time" entry in my prefs.js for that account, which is normally specified like this: user_pref("mail.server.server3.check_time", 60). So I'm guessing that Thunderbird used a hard-coded default of 10 minutes. And since likewise there was also no password for this "deleted" account, Thunderbird needed to pop up a password prompt. Every 10 freakin' minutes! :-)
In my case, changing one line in my prefs.js was enough to bring the problem to light. By chance, I changed
user_pref("mail.server.server3.userName", "anything_but_NONAME"). I guess that "NONAME" is some sort of flag that tells TBird to (mostly) ignore an account?
When I changed that entry, the dreaded 10-minute interval password prompt still appeared. But now it showed an account name, which then made it clear that it wasn't prompting for my active account password, but rather was asking for the inactive "deleted" account's password! And all the better, the "deleted" account now showed up in the GUI's account display, along with a "Check for new messages" interval listed as, you guessed it, every *10* minutes!
So, I just clicked to delete the damn account, again, and the dreaded password prompt was seen no more.
I'd like to note that this isn't the first time I've reported a bug related to supposedly deleted accounts that don't appear in the GUI display, yet still have data in the prefs.js: In https://bugzilla.mozilla.org/show_bug.cgi?id=322738, I reported that I couldn't add a new account because both Mozilla (suite) and Thunderbird said "...user name and server name already exists". The GUI did not list it, so I had to use "vi" to remove references to it from the prefs.js before Mozilla/TBird would then let me create the "new" account.
Mark, your suggestion helped, I was mislead by the fact that I had found incomplete logins, and those were due to account changes. The problem was that Thunderbird was mixing accounts, corruption was different from your case, I had tons of hidden accounts. Deleting accounts has to be done in several places, you also have an account list, and I didn't find the "noname" tag. I simply deleted prefs.js and entered the data again to get a really clean file. Fortunately for me I had all my mail data on a specific location, so I can see the same mail from Windows and Linux sessions, with proper directory names. I suggest that to delete prefs.js you go to:
C:\Documents and Settings\<username>\Application Data\Thunderbird\Profiles\default\i9043bvd.slt\Mail
and note the directories you find there so as to be able to provide those to the Server/Local Directory settings. You won't lose mail, and if you save your prefs.js file you can always go back. I did it on 12 accounts.
However, I do think an internal checker MUST to be incorporated on Thunderbird to purge prefs.js from trash. That will be the real solution.
OK, Mark's problem was triggered by the fact that he had two pop3 servers with the same user name and hostname - server1 and server3, which correspond to account 1 and account 3. This effectively hid server3 from the UI, which can only display unique server uri's because of RDF. So I think the corruption was that somehow we allowed the duplicate account to get created. But the code that checks for new mail has no such restriction - it's happy to check server3 for new mail, but since the password is keyed on the server uri, we'll try to use server1's password for server 3, since they have the same uri.
Antonio's case is harder to figure out, because his account setup is much more complicated. My guess is that it was server8 (see the prefs.js you sent me, Antonio) that was causing the grief, but I don't think there were any duplicate accounts or anything like that - I suspect that there was just a bad password for that account, or some sort of legitimate failure to logon...Is that still a valid account on the server?
I put in comment #39. I'm still having trouble after getting the latest update. I cleared the passwords and .rdf files again. It asks me for a password, I provide it and it stores it under my previous provider (directnic as in comment #39). I can then retrieve mail consecutively without being prompted.
I go away and later I'm asked for the password again, and it comes up in the box *'d out but it's the proper one. Looking in saved password I notice that the password has been lost again and only the smtp entry is left.
Should we (and hot to do it?) eliminate the references to the old provider in the prefs.js file and in the folders within the thunderbird folder in documents&settings? This is a quick fix question I realize and won't help someone who isn't a bug tester should they encounter this problem.
Thanks for your comments David, I looked at my prefs.js, my head started spinning and I decided to kill it completely. server 17 or server8 could be causing the behavior, but the password TB was using to log with the wrong username from an hidden account was the very latest one on the default account, I had duplicate local forders as well, so be it, deleting.... Definitely server8 was not a valid account any more.
I will assume that from my point of view the best thing to do inside TB is to parse prefs.js, obtaining a working copy and from the working copy replace prefs.js by a new one at each start or at each time-stamp modification, because the user may want to fiddle with it. That's what we do on our switching systems which have text file configs. Get the file, convert it to an internal database wiping out all non-understandable stuff, then write a new text file.
Just forgot to tell:
I didn't install any fix, and am now running version 3.0 alpha1, which had exactly the same behavior, without any noticeable annoyance.
I've landed the patch on the 18.104.22.168 branch, though I think there are still issues with some account setups...
flag cleanup for a patch that already landed for thunderbird 2.
Antonio: Can you download a build from ftp://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/22.214.171.124-candidates/rc1 and help QA verify this fix? Thanks.
Tested with my old preferences file and 126.96.36.199 20061107, the bug does not show up.
adding verified keyword per reporter's comment.
verified fixed 188.8.131.52 using Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:184.108.40.206) Gecko/20070326 Thunderbird/220.127.116.11 Mnenhy/0.7.5.0 ID:2007032620 (Thunderbird 2 RC1).
I apparently encountered this problem *again* in 31.1.0, this time while trying to add an IMAP account. According to bug 322738 this "user name and server already exists" thing is caused by the same improper handling of partial account information. Given that no new bug was filed on this matter in the new version, I will assume the update did not fix it. I will warn however that this seems to be a bit of a mandelbug (http://catb.org/jargon/html/M/mandelbug.html), and as such may be hard to reproduce. Mucking around with prefs.js manually, such as to leave partial account information, might suffice, though I do not have the time to try it myself.
ipatrol: If there is to be any action on this, you would need to start from scratch with a fresh bug, or find an existing open bug that matches your experience. It does not make sense to reopen discussion in such an old bug.