Bug 1224160

I debugged this and found that alpine already deletes the credentials from .pinepw before prompting for the password in step 2.

Then I asked upstream and got the answer that this behavior is intentional:

--- snip ---
  this appears documented in the release notes in version 2.25:

 *  Alpine deletes, from its internal memory and external cache, passwords
    that do not work, even if they were saved by the user.

This is because the problem that is being addressed is to have servers that disconnect after the first failure, make the user have a chance to enter the password during the second attempt. I can see that other models could be used in this case, but that is the reason why this was implemented.
--- snap ---

The question now is: How do your server hickups look like and would it be possible for alpine to distinguish them from authentication failures due to invalid credentials?

(In reply to Reinhard Max from comment #1)
> I debugged this and found that alpine already deletes the credentials from
> .pinepw before prompting for the password in step 2.
> 
> Then I asked upstream and got the answer that this behavior is intentional:
> 
> --- snip ---
>   this appears documented in the release notes in version 2.25:
> 
>  *  Alpine deletes, from its internal memory and external cache, passwords
>     that do not work, even if they were saved by the user.
> 
> This is because the problem that is being addressed is to have servers that
> disconnect after the first failure, make the user have a chance to enter the
> password during the second attempt. I can see that other models could be
> used in this case, but that is the reason why this was implemented.

It sounds like the issue is that there is no way to prompt for a password
for the second attempt without deleting the password from the external cache?
I don't see a particular reason do scrap the external cache - if the second
manual password entry succeeds pine can always aks whether it should remember
the password (and then override) or if the user answers no, remove.  But
I do not think removing the password from the external cache when the
second attempt is interrupted (Ctrl-C) or when it also fails (user
simply entering <enter>).

For the actual failure what I'd ideally like to see is at the point
pine asks me for the password on the 2nd try to be able to tell it
"try later with the stored password".

That said, the only workaround for me at the moment is probably keeping
a backup of the .pinepw file and copying it back and re-start pine?

> --- snap ---
> 
> The question now is: How do your server hickups look like and would it be
> possible for alpine to distinguish them from authentication failures due to
> invalid credentials?

It's the usual imap.suse.de "hickups" when the userdb vanishes.  apine doesn't
tell me any details about the authentication failure.  I suppose it's
not a timeout or some sort but instead a "true" authentication failure
(aka wrong username/password).  It's the servers fault (misconfiguration)
of course and only temporary.

(In reply to Richard Biener from comment #2)

> It sounds like the issue is that there is no way to prompt for a password
> for the second attempt without deleting the password from the external cache?

Yes, if I understood alpine's architecture correctly the only way for the lower layer that detects an authentication failure to communicate to the upper layer that the credentials didn't work is to delete them, so that the upper layer has to query the user again instead of reading it from the caches.

> I don't see a particular reason do scrap the external cache - if the second
> manual password entry succeeds pine can always aks whether it should remember
> the password (and then override) or if the user answers no, remove.

Yes, that would probably be better from a user perspective, but I guess the current solution was less intrusive to implement.

> But
> I do not think removing the password from the external cache when the
> second attempt is interrupted (Ctrl-C) or when it also fails (user
> simply entering <enter>).

At that point in time the password is already gone as it gets deleted immediately when the first attempt fails.

> For the actual failure what I'd ideally like to see is at the point
> pine asks me for the password on the 2nd try to be able to tell it
> "try later with the stored password".

I agree that this behavior would be preferable, similar to the dialogs that browsers have for using and replacing stored passwords.

> That said, the only workaround for me at the moment is probably keeping
> a backup of the .pinepw file and copying it back and re-start pine?

Yes, but reopening the respective mail folder might even be enough in case you prefer that over a full restart.

> It's the usual imap.suse.de "hickups" when the userdb vanishes.

I am not sure if I ever experienced such a hickup, as I wasn't using imap.suse.de until recently, and now I use it with the web mailer rather than through a local IMAP client.

> apine doesn't tell me any details about the authentication failure.

Please run alpine with "-d 9" and send me ~/.pine‐debug1 when the hickup has happened again. FYI: Up to and including debug level 9 no secrets get logged, but stuff like the IMAP host and user name.

> It's the servers fault (misconfiguration) of course and only temporary.

Sure, but let's see if these faults are distinguishable from mistyped credentials, so that we can work around the misconfiguration from our side.

Created attachment 875182 [details]
pine debug log

Happened (maint window) again.

Thanks, it contains what I was hoping for (and I also got similar errors trying to access my email via roundcube):

08:36:55.151365
IMAP DEBUG 08:36:55.151365: 00000000 NO [UNAVAILABLE] Account is temporarily unavailable.

So, it is a temporary error that alpine should be able to distinguish from errors due to invalid or expired credentials.

(In reply to Reinhard Max from comment #5)
> Thanks, it contains what I was hoping for (and I also got similar errors
> trying to access my email via roundcube):
> 
> 08:36:55.151365
> IMAP DEBUG 08:36:55.151365: 00000000 NO [UNAVAILABLE] Account is temporarily
> unavailable.
> 
> So, it is a temporary error that alpine should be able to distinguish from
> errors due to invalid or expired credentials.

Agreed.  I'm not sure todays outage was the same as the last - I'll see if
it's another reason when it happens the next time and keep you updated.