213513 - Infinite retry loop after APOP support when server setting mismatch

Status: VERIFIED FIXED

(MailNews Core :: Networking: POP, defect)

Description

[WADA:World Anti-bad-Duping Agency]

User-Agent:       Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.5b) Gecko/20030722
Build Identifier: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.5b) Gecko/20030722

After APOP support (bug 43923), 2003070224-trunk/Win-Me, infinite error retry
loop occurred if user failed to set "Use Secure Authentication" correctly.

(case-1)
 APOP is enabled and Usual Authentication is disabled at POP server.
 User did NOT check "Use Secure Authentication".
 =>
 Infinite retry loop with following dialog;
 Sending of password did not succeed. 
 Mail Server pop.xxx.yyy.zzz responded:
 [AUTH] USER/PASS authorization is disabled.

(case-2)
 Usual authentication is enabled and APOP is disabled at POP server 
 User checked "Use Secure Authentication".
 =>
 Infinite retry loop with following dialog;
 Mail Server pop.xxx.yyy.zzz responded: [AUTH] APOP Authorization is disabled

Reproducible: Always

Steps to Reproduce:
1-1. Enable APOP Authentication service/Disable Usual Authentication service.
1-2. Uncheck "Use Secure Authentication"
1-3. Get Message => Error retry loop

2-1. Diable APOP Authentication service/Enabel Usual Authentication service.
2-2. Check "Use Secure Authentication"
2-3. Get Message => Error retry loop

Actual Results:  
Infinite loop of dialog message.

Expected Results:  
No unneceassary retry and appropriate message. 

If both APOP and Usual Authentication service are enabled at POP server, no
problem occurrs.

Note: My provider permits user to enable/disable APOP authentication and usual
authentication independently.

Comment 1

[WADA:World Anti-bad-Duping Agency]

Attachment: NSPR POP3 protocol log

Comment 2

[Christian Eyrich]

Phew, that's true, but it's no issue of APOP itself.

My question is, what do you want to happen?
Mozilla doesn't know why the password action failed and assumes wrong password.
So he asks you for the correct one again and again. If you don't want this and
correct the options, click cancel on the password question.

Hm, ok, there might be a problem if you saved the password in previous sessions
and then switched to an incompatible authentication. This might lead to a
situation where Mozilla loops in the background and doesn't ask for the
passwords and thus no chance to cancel. Is this the case?

Two remarks:
1. To send the APOP-Banner (<[e-mail]>) if APOP is
disabled is at least bad behaviour.
2. The checkin for APOP support contained an error (see bug 213685) what lead to
an unappropriate error message if APOP login failed. That should be corrected in
the next days.

Comment 3

[WADA:World Anti-bad-Duping Agency]

Yes, it's the case.
I already saved proper password.

My wants to happen is as follows.

(1) If Mozilla can detect next 2 errors on password action, password retry is
stopped by Mozilla automatically.
> 0[781c70]: RECV: -ERR [AUTH] USER/PASS authentication is disabled.
> 0[781c70]: RECV: -ERR [AUTH] APOP authentication is disabled.
These error message indicates following password retry will always fail.

(2) If Mozilla can NOT know reason of error on password action, or if reason
described in the error message is server dependent, means to avoid loop is required.
I think "CANCEL" button on dialog is sufficient in this case.
User can read above error message on the dialog box and can know the reason of
failure.

> 1. To send the APOP-Banner (<[e-mail]>)
>  if APOP is disabled is at least bad behaviour.

Sorry for my confusing log.
At the step of [e-mail], I already enabled APOP and
disabled USER/PASS for case-1.
I changed to APOP=disabled and USER/PASS=enabled for case-2 in the middle of the
test.
I should have separated protocol log of 2 test cases.

Comment 4

[Christian Eyrich]

> (2) If Mozilla can NOT know reason of error on password action, or if reason
> described in the error message is server dependent,

Yes, because the error messages aren't standardized and only sometimes
descriptive we can't watch out for a the messages.
What's standardized is the [AUTH] part which says, that the authentication
failed. Unfortunately this is an optional addition and not presented by each server.

> means to avoid loop is required. I think "CANCEL" button on dialog is
> sufficient in this case.
> User can read above error message on the dialog box and can know the reason
> of failure.

Hm, so the password dialog doesn't appear, but the alert with the servers reply
does?
So a cancel button would be ok, I agree. The problem is that the standard alert
function doesn't have a second button. So that's not that easy to do.

I can't think of a situation where looping without asking for a new password is
good anyway.
I'll see what's possible.

Comment 5

[WADA:World Anti-bad-Duping Agency]

> I can't think of a situation where looping without asking for a new password
is good anyway.

I agree with you.

> The problem is that the standard alert function doesn't have a second button.

Even if password promting will be implemented on this bug's case,
canceling on current "-ERR [AUTH]" alert dialog is more appropriate, I think,
than canceling on password prompt dialog because user can cancel when the cause
of error is displayed.
Are'nt there any simple prompting Mozilla function like JavaScript's
window.prompt() or window.comfirm()?
If not, displaying error description on new password promt is desirable. 

Comment 6

[Matthias Versen [:Matti]]

An alert should not have a cancel button.
Mozilla should abort after 3 failed Logins...

Comment 7

[Christian Eyrich]

WADA, please test this again with a nightly 20030731 or newer.
Fix for bug 214217 reenabled Mailnews code to delete the password after failed
login.
Todays build passed my tests, so if you can confirm, please close this bug.

Comment 8

[WADA:World Anti-bad-Duping Agency]

2003073110-trunk/Win-Me resolved the problem and worked well.
Thanks.

However, this new build appended "@" and pop_server_name to registrated Username.
Userid displayed in alert message was <registrated_User_Name> + @ +
<pop_server_name> and login failed due to invalid user-id.
Previous build did not appended "@+<pop_server_name>" automatically.
Since my real userid is fortunately xxxx + @ + pop_server_name format, I could
login by specifying only "xxxx" part of my real userid as Username in account
settings.
Is't this a regression by fix for bug 214217? 
 
 

Comment 9

[Christian Eyrich]

It's a old problem that users think, we append @pop_server to the username.
But this is only a string displayed in the dialog and has nothing to do with the
string sent (ugly, I know).

But it's interesting, you say your problem just started with this nightly and
the workaround is to remove @pop_server from your username.
So let's close this bug as it's issue has been fixed and continue discussion of
your new problem in bug 212937. Please attach there a log using your current
nightly first with your previous username and then with your now cropped - so we
can it compare to the one from 2003-07-23.

Comment 10

[WADA:World Anti-bad-Duping Agency]

I see, Christian.
I change to verified since this bug itself has been apparantly fixed and resolved.
Thanks.