I have 2 POP3 accounts on a server that is plagued by intermittent authentication failures: a POP3 login attempt with correct credentials will just randomly fail once in ten attempts or so. Whenever this happens during a periodic mail check, akonadi re-prompts me for password. This is very distracting because the password dialog pops up out of the blue every 20 minutes or so, interrupting work and thought. Reproducible: Always Expected Results: I would expect akonadi to use a more robust strategy: - upon first failure, silently retry the same password a configurable number of times. - if these attempts fail, *skip* one periodic check or *wait* a configured amount of time, whichever will result in retrying sooner. - only show the password dialog if the known password still fails after the retries *and* the wait. I believe that "intermittent network or server problem" is generally a much more likely cause of authentication failures than "user has actually changed the account password". The design of strategies for dealing with POP3 login failures should be guided by this assumption.
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.
If the bug is still present, it WILL manifest in this scenario with 100% certainty, but setting up this scenario (i.e. setting up a dummy POP3 server that can be instructed to fail authentication attempts on demand, configuring the accounts etc.) is not something you should expect a bug reporter (and end user) to do. That's test team's job.