not clearing wrong password
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
VM |
Fix Released
|
Low
|
Uday Reddy |
Bug Description
trunk rev 1242
My password changes on an upstream imap server. When I tried to 'g' mail from that server (configured in vm-spool-files), vm never cleared the bad password from vm-imap-passwords. I expected to get ...
IMAP password for user@server [inbox] incorrect
... once, but got it every time I hit 'g' to get mail from that server. It seems that in the past, I've had this happen, but the second 'g' caused a new prompt for password.
Side note: it also takes a _long_ time (two+ minutes) to return control to me when 'incorrect password' happens [1]. This may be an old bug. I recall impatiently using multiple C-g's to break out of this situation in the past at some point.
Related bugs:
bug 729568 (doesn't apply - not a read only folder)
bug 822578 - looks very similar - maybe that fix was not committed to the trunk?
After turning on imap logging, I see about 20-25 of these trace buffers...
=======
Starting IMAP session Fri Nov 4 14:26:21 2011^M
-- connecting to fb8:1143^M
* OK [CAPABILITY IMAP4REV1 AUTH=LOGIN IDLE] IMAP4rev1 DavMail 3.9.4-trunk server ready^M
-- connected for movemail^M
VM CAPABILITY^M
* CAPABILITY IMAP4REV1 AUTH=LOGIN IDLE^M
VM OK CAPABILITY completed^M
VM LOGIN <parameters omitted>^M
VM NO LOGIN failed^M
VM LOGOUT^M
* BYE Closing connection^M
VM OK LOGOUT completed^M
Process IMAP connection broken by remote peer
ending IMAP session Fri Nov 4 14:26:24 2011^M
=======
[1] The 20-25 attempts explains the two+ minutes.
And a report in the mini-buffer...
Variable binding depth exceeds max-specpdl-size
And that probably explains why I only get 20-25 attempts - it would probably go on forever otherwise.
Related branches
Changed in vm: | |
status: | Fix Committed → Fix Released |
workarounds when you know you've changed your password(s):
- kill/restart emacs (is there a way to unload all of vm without killing emacs?)
- (setq vm-imap-passwords nil) to clear the cached passwords
(I have not yet tried using the .authinfo.gpg feature yet - that will likely avoid this problem, too?)