This bug is in part for deciding when mailnews should forget passwords and when it should not. Bug 286628 changed some backend code in NNTP that prompted the latter comments of bug 285664 with respect to forgetting passwords; the latter commenter disagreed with forgetting passwords on one failure. So, should passwords be forgotten after one failure? Two? Ever?

(In reply to comment #0) > So, should passwords be forgotten after one failure? Two? Ever? So what I would like to know is: 1) When are we forgetting passwords? - is it because we don't have a connection (its been dropped), or is it because the server has explicitly said its not a valid password. 2) If we don't have a connection, why are we reading that as an auth failure? 3) Is this consistently wrong across all protocols?

With NNTP there are several modes of failure, some of which are not an explicit ID/PW invalid case. While major USENET hosters have very high reliability through mirrors, etc., the private single server cases can be prone to an assortment of transient server side connection request rejections. A case is news.annexcafe.com which migrated to all users being required to use ID/PW verification. A second case is news.westelcom.com which dropped it's own servers and switched to leasing two connections to newshosting.com. For case #1 the past problems have been mitigated with more accurate use of NNTP error codes and more robust authentication rules. So server configuration plays into PWM reactions to what replys it gets. For case #2 I see frequent instances of the news host rejecting a message retrieval request because the "Server is too busy" when the bandwidth of the limited connections is fully consumed. With both of these cases I have had to deal with restoring my entries into PWM under conditions where problems were other than invalid ID/PW causes. In recent days I read a comment regarding Fx/core where a user ID/PW should be tested, and with a valid logon the PWM would then save the data. This would preventing saving of a bad ID/PW pair. Given that connecting to a NNTP server is significantly less risk than a modem dialer calling a phone connection, We have less justification for persisting ID/PW than a dialer. I presented a view that PWM could behave like a dialer, have a timer and a retry preference setting. Case: If {protocol=NNTP, true;} do (retry-loop,2,20); Else do (one-retry); End Case: The retry loop subroutine would incorporate a BIF style popup status alert it was running a retry, count down to zero, ending with "Try again later". Bottom line, I believe We should special case the NNTP protocol to enhance user experience as long as the perceived security risk is low. The use of ID/PW authentication with NNTP is all about keeping out the spammers and services theft, not security of subscribers personal data. The benefit of such a revision is we then have an in place solution for any new cases where a protocol needs enhanced connection support.

Correction to comment #3 have less justification for not persisting ID/PW than a dialer. ^ A clarification of the numerical values I used. The 2 is number of retries and 20 is the retry delay to deal with server side congestion induced errors. If the decision is to go with a concept like this, the a bug will be needed for the UI work. The implementation of supporting UI could be placed in the Account Settings manager in the server settings tab where We have lots of white space available. That the inputs are account centric to NNTP, they should only display if the user selects New Account News radio button.

Is this bug for NNTP only? Or common request for NNTP/POP3/IMAP/SMTP? Bug 423354 Comment #41 is an IMAP case (BYE just after greeting by Gmail IMAP, perhaps due to maintenance). Many bugs are seen for POP3/SMTP too, with "password is forgotten". (Note:) When POP3/IMAP/SMTP, retry with wrong password can cause "Disabling of Account by ISP". So "retry count limit" can't be a solution when POP3/IMAP/SMTP. So password is currently cleared after failure in Tb's "Login related process". As I wrote in the comment, I think password shouldn't be cleared at least when non-authentication-failure, even if the failure occurred during Tb's "Login related process". I think it's common issue of POP3/IMAP/SMTP/NNTP.

(In reply to comment #6) > Is this bug for NNTP only? Or common request for NNTP/POP3/IMAP/SMTP? No, it's for all cases. A good summary of this would be "When should we forget passwords?" The IMAP and POP problems (mentioned in bug 423354) stem from the inability to distinguish between "Can't connect" and "Authentication failure." NNTP's most major problem stems from "We ignore the difference between connection and authentication failure."

As a user, I don't want passwords ever to be forgotten. If there is a failure during authentication, just pop up that dialog requesting the authentication credentials with the existing password as '***'. If the user presses OK AND the authentication passes, then replace the stored credentials with the new ones. All other cases, if the user closes or cancels that dialog or the authentication fails, please just leave the stored password alone. Thanks

I'm probably way off-base here, not knowing the internals of "MailNews Core", but here goes: Don't each of those protocols (NNTP/POP3/IMAP/SMTP) have mechanisms/messages for indicating command failures? Is "MailNews Core" designed to represent communication errors by ignoring basic state information (i.e. what client-initiated command the network/server response is in relation to)? From my experiences, at least the POP3, SMTP, and IMAP protocols is that messages are returned that indicate success or failure of the preceding command. My thought is that, if not already the case (and from reading the comments above, it sure seems not to be the case) "MailNews Core" should be returning unique status messages that depend on, and are tied to, what operation was attempted (specific command/response status). For example (just brainstorming): 1. Most, if not all successful operations: SUCCESS 2. Connection Failure: CONN-FAILED 3. Authentication failure AUTH-FAILED 4. Data transmission failure: DATA-SEND-FAILED 5. Data reception failure: DATA-RECV-FAILED Or use numbers or something to demonstrate a unique relationship between what was attempted and what the outcome was. No flames please {dons flame-retardant suit, just in case}. :-)

(In reply to comment #10) > Don't each of those protocols (NNTP/POP3/IMAP/SMTP) have mechanisms/messages > for indicating command failures? Is "MailNews Core" designed to represent > communication errors by ignoring basic state information (i.e. what > client-initiated command the network/server response is in relation to)? > > From my experiences, at least the POP3, SMTP, and IMAP protocols is that > messages are returned that indicate success or failure of the preceding > command. The problem is that "authentication failure" is ill-distinguished. IMAP, for example, has only one error code (well, two if you include "your command was malformed"): the command failed. This is used for "authentication failed because your password is incorrect", "authentication failed because you have too many connections", and "this command failed because I dumped core." POP and SMTP are similar. NNTP--the only of the protocols to have meaningfully different response codes--is also plagued because the standard auth failed response code, 502, also means that the connection should be closed. And part of the problem with forgetting passwords right now is that we are more or less assuming what the error code means based on which command we set (i.e., error on authentication = password's bad), and that assumption is wrong (too many connections).

(In reply to comment #11) > And part of the problem with forgetting passwords right now is that we are more > or less assuming what the error code means based on which command we set (i.e., > error on authentication = password's bad), and that assumption is wrong (too > many connections). POP3 and SMTP should be very doable. When I manually interact with a server, I get very distinguishable messages. IMAP would take a bit more work. If I get a chance, I will write a script to bounce commands off my server, in various states, and see how accurately it logs the reasons for failure.

I have now completed investigating this matter and it should be relatively easy to distinguish between connectivity, server non-authentication and server authentication-related issues. 1. CONNECTIVITY --------------- In my experience, connectivity issues (unknown factors) are often managed using timers. Use two timers: (1) a connection timeout timer; (2) a server busy / request timeout timer. The first timer (usually less than 10 seconds) should help immediately determine whether the server is reachable or not. This is for the TCP connection. The second timer (usually a minimum of 30 seconds) is for the POP3/SMTP/IMAP/NNTP server response. 2. AUTHENTICATION ----------------- With network/server connectivity-related issues detectable with timers, now a look at authentication. After observing the client/server responses for POP3, IMAP, SMTP, and NNTP, I see no problem with being able to distinguish between operations. Some servers may send slightly different messages for some events; however, in general, their messages should contain common elements or have limited variance. Therefore it should be trivial to determine whether a command succeeded or failed. Is the problem that the devs are looking for server response messages that say something like "Authentication Successful" vs silence, instead of coding for something like: IF {I am authenticating} AND {Server response contains "[some delimiter]OK "} THEN {Return AUTH_SUCCESS} ELSE IF {Server response does not contain "[some delimiter]OK " (or look for the explicit error)} THEN {Return AUTH_FAILED}. The server response timer, initiated upon sending the request, would then be reset immediately upon receiving the response from the server. In this manner, MailNews Core can easily make the distinction between: host unreachable, server busy/unavailable, request successful, and request failed. MailNews Core needs to make an explicit link between what it sent and what it received. My guess is that MailNews Core is currently coded to interpret the situation like: IF {I am authenticating} AND {Server response contains "[some delimiter]OK "} THEN {Return AUTH_SUCCESS} ELSE {Return AUTH_FAILED}. This wrongly assumes that, absent "[some delimiter]OK ", the command failed, when in fact it could have been a communications error. Now before anyone flames me, if I have in any way misrepresented the facts about MailNews Core, please understand that I do not have M4D H4X0R 5K1LLZ and am not competent enough to pear at the code to determine what exactly is going on. I'm basing my analysis on comments in the immediate discussion. If I'm sounding like an 00B3R N00B, that's because I am. :-)

(In reply to comment #0) > So, should passwords be forgotten after one failure? Two? Ever? As I said in comment #25 on bug 286628 "I think it should never remove user names and passwords without [explicit] user authorization. If there is an authentication problem, I want to try to authenticate with the old username and password (without having to retype them) as long as I'm not persuaded it is not a temporary problem but they are really wrong." Could somebody show me an example when automatically deleting a previously saved password without user confirmation could be useful? I can't figure it.

(In reply to comment #11) > The problem is that "authentication failure" is ill-distinguished. IMAP, for > example, has only one error code (well, two if you include "your command was > malformed"): the command failed. This is used for "authentication failed > because your password is incorrect", "authentication failed because you have > too many connections", and "this command failed because I dumped core." POP and > SMTP are similar. > Are those error messages you've quoted generated by MailNews Core or some mail server you are testing against? After looking at three different IMAP servers, I don't see such ambiguity, so I'm assuming that the ambiguity is introduced by MailNews Core itself.

Now I have completely reversed situation. :) Shredder started asking for Gmail password, but not accepted it. After restart it do not asks it and do not login to gmail at all... Selecting gmail inbox let the cursor change to hourglases in folder and subj views.

I just "fixed" it by selecting other than inbox folder, then SH asked for password. SH 20080925

just wondering if there is any progress on this issue? It's happened to me three times in the last week with gmail and is getting rather annoying. Can we get Thunderbird to never forget an authentication password please?

The gmail issue is resolved on trunk, bug 423354.

It feels like the summary of this bug could be wrong. I agree that TB shouldn't ever forget a password, until someone can explain why, although it shouldn't keep trying w/ an old password unbidden if it has information suggesting it's wrong ( It does seem like the bigger issue is that we need to detect the difference between "wrong password" and "failed connection", and act accordingly -- and if we can't tell the difference, then act accordingly there as well. Joshua, can you clarify? This also looks like a dupe of bug 121647.

(In reply to comment #20) > if it has information suggesting it's wrong There is no response code for "incorrect password"(mainly security reason, I think), although some(not-so-secure, I guess) servers add comment string like "incorrect password" to response code. David Ascher, Bug 121647 is applicable to NNTP & SMTP too?

I still don't see where forgetting passwords might be helpful. Can we please change this default behaviour, or at least allow for a governing preference setting. Migrating programs for family members is hard enough without silly little niggles like this making life difficult. The mailbox being locked (because Thunderbird doesn't disconnect gracefully on an abrupt user-exit) seems to bring about this issue. The strange thing is that, for all this discussion, the change should amount to just a single line in the source code. Is this the only avenue for requesting change?

We basically fixed this in Thunderbird 3.0 by providing a new dialog which gives the user the choice of retrying the connection, cancelling or entering a new password. Hence passwords now won't be forgotten without user confirmation. Cases where the new dialog is inappropriately brought up, should be filed as separate bugs with logging (https://wiki.mozilla.org/MailNews:Logging) so that they can be tracked and hopefully resolved. Given the above, marking this bug as fixed by bug 121647.