205571 - Create UI for mail pref mail.server.server*.useSecAuth

Status: RESOLVED FIXED

(MailNews Core :: Networking: POP, defect)

Description

[Christian Eyrich]

Spin of from bug 205003 on the implementation of a UI for the new introduced
pref useSecAuth in Mozilla 1.5.

Comment 1

[Christian Eyrich]

*** Bug 205641 has been marked as a duplicate of this bug. ***

Comment 2

[Christian Eyrich]

Attachment: patch adding the UI

This patch adds the UI for the useSecAuth pref named "Use secure
authentification".
Additionally it adds the right alert if the user doesn't support secAuth but
the user wants to use it and improved strings for POP3_USERNAME_FAILURE and
POP3_PASSWORD_FAILURE.

useSecAuth is enabled by default. This will produce the same errors by the
affected users as seen in bug 205003 and dupes. I'm convinced that the great
majority will have no problems so this is ok.
But the help page should not only describe the new feature but mention this
possible problem too.

Comment 3

[Christian Eyrich]

Comment on attachment 123497 [details] [diff] [review]
patch adding the UI

I think it's time to get this in.
And I need this for creating the patch to bug 43923 ...

Comment 4

[David :Bienvenu]

Comment on attachment 123497 [details] [diff] [review]
patch adding the UI

r=bienvenu

except I think we use "username" or "user name"
+4004=Sending of Username did not succeed.

this comment perhaps should be - secure authentication failed?
+# user required to use secure authentication

Comment 5

[Christian Eyrich]

Attachment: patch v2

> except I think we use "username" or "user name"
I took username like in 4014 (also "password" now).

> this comment perhaps should be - secure authentication failed?
Yeah right, copy/paste ...

r=bienvenu as per comment 4

Comment 6

[Marc Mongenet]

IMHO, from a user point of view, it would be better if Mozilla automatically
tried (say from most secure to less secure) all available login methods.
Maybe a UI could allow paranoid users to disable unsecure methods?

Comment 7

[David :Bienvenu]

I'll bring this to Seth's attention. One of the reasons we have this UI is that
secure authentication is simply broken on some servers and having a ui will
allow them to disable the attempt. The servers' behaviour is so unfriendly
(e.g., just silently dropping the connection) that this pref makes our lives a
lot easier.

Comment 8

[(not reading, please use [e-mail] instead)]

this looks like a good start, but I have some comments.

1)

+  <checkbox iscontrolcontainer="true" wsm_persist="true" id="server.useSecAuth"
+            label="&useSecAuth.label;" hidable="true" hidefor="nntp"
+            prefattribute="value"
+            prefstring="mail.server.%serverkey%.useSecAuth"/>

I think we might want hidefor="nntp,movemail" here.


2)

 <!ENTITY isSecure.label "Use secure connection (SSL)">
+<!ENTITY useSecAuth.label "Use secure authentication">

Is our secure authentication always Cram-MD5?

If so, just like we specify SSL, why not do this:

"Use secure authentication (Cram-MD5)

3)

+4030=Mail server does not support secure authentication.\n

Why the newline?

4)

we should ask [e-mail] to review the properties changes

5)

david, I think we'll need some changes to:
a) check the redirector type, to override the default
b) check the redirector type, and in am-server.js, hide this new UI

Comment 9

[David :Bienvenu]

I'll attach a new patch since I need to test this before I check it in anyway...

Comment 10

[(not reading, please use [e-mail] instead)]

Comment on attachment 124170 [details] [diff] [review]
patch v2

discussed with bienvenu and:

> 2) Is our secure authentication always Cram-MD5?

he tells me it's not aways cram-md5, so ignore this suggestion.

> david, I think we'll need some changes to:
> a) check the redirector type, to override the default
> b) check the redirector type, and in am-server.js, hide this new UI

not blocking this, so we'll log a netscape internal bug about this issue.

we'll still need a final patch for the movemail / newline issue.

i'll sr the final patch.

Comment 11

[David :Bienvenu]

Attachment: patch v3

this addresses Seth's comments (I haven't included the mailnews.js changes,
which remain the same)

Comment 12

[Christian Eyrich]

Ok, movemail is new to me.
I think the newline had a reason, but I can't remember now.

No change to mailnews.js means mailnews defaults to the same behaviour like 1.4
and before: try only unsecure. Do you want this?

What's the issue of 5 a/b?

Comment 13

[David :Bienvenu]

fix checked in. I think RobinF should make a pass through all our messages and
determine one true way to display user name and password.

Comment 14

[(not reading, please use [e-mail] instead)]

Comment on attachment 124840 [details] [diff] [review]
patch v3

r/sr=sspitzer for the trunk.

thanks david / christian.

note, we aren't taking this for 1.4

Comment 15

[(not reading, please use [e-mail] instead)]

> Ok, movemail is new to me.
isn't linux only. see http://www.mozilla.org/mailnews/movemail/

> I think the newline had a reason, but I can't remember now.
david didn't check it in, so if you remember or discover the reason (like it
made the alert UI look better?), please log a new bug.

> No change to mailnews.js means mailnews defaults to the same behaviour 
>like 1.4 and before: try only unsecure. Do you want this?

looking at the checkins (And not the final patch, which didn't include the
change to mailnews.js, which was checked in), the default for 1.5 alpha is to do
secure auth default, but since there is UI, people can disable it.

>What's the issue of 5 a/b?
imap servers can have a redirector.  for example, netscape 7.02, when you have
aol or netscape webmail accounts, we key off that redirector type.
I was concerned that trying cram-md5 auth would break those, but david doesn't
think they will, since the server will not say it supports it.

but, for netscape, there is still a UI issue, which is we want to hide this new
"use secure authentication" checkbox for certain redirector types.  but that's a
netscape only bug, which I'll log on myself on a bug database behind the
firewall, since it doesn't concern mozilla.

of course, mozilla distributors might be using redirector types (like ISPs could
be clever and using it), and they might care. 

Comment 16

[(not reading, please use [e-mail] instead)]

logged bug #208175 on the redirector issue, as the eventual fix will be to
mozilla code.

Comment 17

[David :Bienvenu]

OK, I had to turn this off by default in mailnews.js - I'm not sure if this was
intended or not, but we always try it for pop, and if it fails, we just don't
get new mail, and there's no fallback to other authentication mechanisms. Since
few pop servers support secure auth, this seems like the wrong default. I'll
leave it to Christian to say what the intended behaviour is.

Comment 18

[(not reading, please use [e-mail] instead)]

from http://bugzilla.mozilla.org/show_bug.cgi?id=205571#c12

christian wrote:

"No change to mailnews.js means mailnews defaults to the same behaviour like 1.4
and before: try only unsecure. Do you want this?"

based on bienvenu's last checkin, we're going with off by default.

from bienvenu last comment, sounds like we *can't* turn it on by default.

let's get a bug started on that.

Comment 19

[Christian Eyrich]

David, you're right since secure is exclusive and not additional.

I can't see the use of a bug on this. Ok, letting this pref add the secure
mechanisms would probably work. But the user couldn't be sure that the login was
really secure or if not plain text was used because of lacking sec auth
mechanism on server side.