185662 - In SMTP prefs, make it clear what "use secure connection (SSL)" really means

Status: VERIFIED FIXED

(MailNews Core :: Security, enhancement)

Description

[Michael T. Babcock]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130

There should be an additional option on the prefs window for Mail/News w.r.t
Server Settings, "Use STARTTLS method".  Only after the user clicks 'Use Secure
Connection' should this option be selectable.  It would change the port back to
the unencrypted port (143 for IMAP, 110 for POP3) instead of the TLS port and
change the (default) connection method.

This option becomes more useful with bug 185631 (auto-detect security options on
server).

Also: I recommend not using "Use STARTTLS method" as stated above, but rather
something slightly more meaningful to the user like "Use alternate connection
method" with help information to describe the difference.

Reproducible: Always

Steps to Reproduce:
N/A
Actual Results:  
N/A

Expected Results:  
N/A

Comment 1

[John Unruh]

Enhancement

Comment 2

[Kai Engert (:KaiE:)]

I think this bug report is confusing, I beg your pardon :)

In the summary of this bug report you talk about SMTP. You say "use STARTTLS"
instead of "SMTP over SSL".

I believe you misunderstood, and this might be caused by unclear wording in the
mail SMTP preferences window.

Mozilla does not use or support "SMTP over SSL", which is usually going over
port 465, which is the plaintext SMTP protocol encapsulated in SSL.

Mozilla does already use the STARTTLS method when the SMTP settings are
configured to do a secure connection (SSL).


In your detailed bug description you also talk about automatically changing the
ports used for IMAP or POP3, but I don't see the reason why to do that. SMTP,
IMAP, POP3 are all going over separate ports, using separate protocols, using
security independently. Currently the security configuration for all of those is
separate in the config, and I believe we should keep it that way. It is common
practice that an email provider gives details to the users about the prefered
mail client configuration. Please let's separate a discussion about
automatically changing ports into a separate bug.

Comment 3

[Michael T. Babcock]

First off, it bears mentionning that this is a feature request and therefore the
fact that something relating to it does not yet exist (SMTP over SSL, for
example) is not as relevant as being clear and concise in what I'm requesting.

As for the changing of ports, running Mozilla 1.2.1, if you change an IMAP
account from normal to secure connection, it changes the port number for you
automatically to the default IMAP-over-SSL port or the IMAP port.  This is why I
considered it as part of my proposal.

I hope that it is clear that what I want is the ability to specify either
{protocol} or {protocol over ssl} or {protocol then starttls} and not be
guessing about which Mozilla is doing.  The fact that Mozilla does not support
one or more of these features would simply make that option unavailable (and a
seperate feature request).

Also note that how Mozilla handles SMTP and STARTTLS (at the very least) is
already broken.  See bug 98399 (STARTTLS deal with wrong) and bug 60377 (Support
IMAP STARTTLS).

Comment 4

[Kai Engert (:KaiE:)]

Thanks for explaining in more detail.

I'm rewording the summary to express your request more clearly.

I suggest this bug should be about removing the confusion, which I agree we have.
A simple way to remove the confusion would be to reword the prefs UI to say
something like "Use secure connection (SSL/STARTTLS)".

Comment 5

[Michael T. Babcock]

As per out-of-band discussions with Kai Engert, I believe we should aim for
rewording the current option to say either "Enable a secure connection
(STARTTLS)" or "Enable a secure connection using STARTTLS".

We had discussed that help topics on these options could describe what in fact
STARTTLS is (as opposed to the as-of-yet unimplemented SMTP over SSL/TLS), but
that is probably a seperate bug subject.

Comment 6

[Jan Braun]

Attachment: patch: display "starttls" and smtp-over-ssl" instead of "tls" and "ssl"

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 162322 [details] [diff] [review]
patch: display "starttls" and smtp-over-ssl" instead of "tls" and "ssl"

Jan Brown,

Your patch is a significant improvement over the original UI, in my opinion.

I believe the text in the UI could be improved slightly more than this patch
does, and I will explain that below.  But I hasten to emphasize that I would
not object to this patch just because additional improvements can be made.  
I'd *MUCH* rather than this patch's improvement than no improvement at all.

STARTTLS is a feature of some of the IETF's "Simple" protocols (e.g. Simple
Mail Transfer Protocol, SMTP) that allows the use of TLS (or SSL) to be 
negotiated after the Simple protocol has begun.  The point of StartTLS is 
NOT that it uses TLS (instead of SSL3).  In fact, StartTLS can (and in many
cases does) negotiate SSL 3.0 rather than TLS (which is SSL 3.1).  The point
of StartTLS is that the use of SSL3/TLS is negotiated AFTER the simple 
protocol has begun, not BEFORE.  

Likewise, the SMTP-over-SSL feature may use SSL 3.0 or SSL 3.1 (TLS).  

The difference between STARTTLS and SMTP-over-SSL/TLS is ONLY,
- the order of events, and 
- the server port numbers being used.
It is NOT the case that one uses TLS and the other uses SSL.

So, in explaining the difference between STARTTLS and SMTP-OVER-TLS, the 
text should not suggest that one uses TLS and the other uses SSL.  The text 
should emphasize that STARTTLS uses a normal SMTP port, and negotiates the 
use of TLS (or SSL 3.0) after SMTP has begun, while the other option uses a 
special port that uses SSL or TLS first, and then starts to talk SMTP over 
the SSL/TLS connection that has been established.  

I would suggest that the descriptive text should name both SSL and TLS for 
both options, to make it clear that these options do NOT choose between SSL
and TLS (and their names formerly suggested).  The choice is between using
a special port that always does SSL3/TLS FIRST, and using an "ordinary" 
Simple protocol port that optionally negotiates SSL3/TLS AFTER starting the 
Simple protocol.

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

Sorry for the typo on your name, Jan.  Didn't intend to misspell it. :-(

Comment 9

[Jan Braun]

Attachment: updated version of STARTTLS/SMTP-over-SSL patch

Thanks for pointing that out! You're certainly right. I've reworded the text to
fix the incorrect SSL/TLS references, but did not explain the SMTPS/STARTTLS
difference in detail, since IMO that won't help the user decide the proper
method; he just needs to pick the one listed in his server's specs.
I'd like to add a notice that both methods will lead to the same SSL/TLS
protocol negotiation, so neither offers better encryption or has other
technical merits over the other. However, I couldn't find a wording where it
was clear that it would help rather than hinder understanding. Suggestions
appreciated.

Oh, and don't worry about the name :)

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 162528 [details] [diff] [review]
updated version of STARTTLS/SMTP-over-SSL patch

I like it.  Others with more UI expertise should also weigh in, but overall I
think this is a big improvement!

Comment 11

[Nelson Bolyard (seldom reads bugmail)]

This PSM patch was reviewed 21 months ago.  
What can I do to get it on the radar for near term checkin?

See also bug 258540 (which may be a dup of this one).

Comment 12

[Tomas]

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

Comment 13

[Tomas]

Same issue applies to IMAP and POP3 options.

"2004-10-18 17:17 PDT" patch covers only SMTP options.

Comment 14

[Magnus Melin [:mkmelin]]

(In reply to comment #11)
> This PSM patch was reviewed 21 months ago.  
> What can I do to get it on the radar for near term checkin?

It still needs sr, no?

Comment 15

[David :Bienvenu]

Comment on attachment 162528 [details] [diff] [review]
updated version of STARTTLS/SMTP-over-SSL patch

we need to make sure this doesn't overflow the dialog because of the longer string (STARTTLS vs TLS)

Comment 16

[Tomas]

Currently ThunderBird uses four radio buttons. How about using dropdown box?

Comment 17

[Magnus Melin [:mkmelin]]

Attachment: screenshot of the stmp server dialog with new strings

Actually it would look quite good, imo.

Comment 18

[Magnus Melin [:mkmelin]]

Attachment: Jan Braun's patch, unbitrotted and including thunderbird (not just seamonkey)

This does the same thing as the patch that already got r,sr. Only now it includes not seamonkey only. I also updated the entity names so localizer will notice.

Comment 19

[David :Bienvenu]

Comment on attachment 245106 [details] [diff] [review]
Jan Braun's patch, unbitrotted and including thunderbird (not just seamonkey)

ok, thx, guys.

Comment 20

[:Gavin Sharp [email: [e-mail]]]

mozilla/mail/locales/en-US/chrome/messenger/smtpEditOverlay.dtd 	1.4
mozilla/mailnews/base/prefs/resources/content/smtpEditOverlay.xul 	1.29
mozilla/mailnews/base/prefs/resources/locale/en-US/smtpEditOverlay.dtd 	1.11
mozilla/suite/locales/en-US/chrome/common/help/mail_help.xhtml 	1.78

Comment 21

[Magnus Melin [:mkmelin]]

Comment on attachment 245106 [details] [diff] [review]
Jan Braun's patch, unbitrotted and including thunderbird (not just seamonkey)

Low risk patch, only string changes.

Comment 22

[Daniel Veditz [:dveditz]]

Comment on attachment 245106 [details] [diff] [review]
Jan Braun's patch, unbitrotted and including thunderbird (not just seamonkey)

This needs tbird approval, not sure what the localization freeze is for that one.

Comment 23

[Scott MacGregor]

Comment on attachment 245106 [details] [diff] [review]
Jan Braun's patch, unbitrotted and including thunderbird (not just seamonkey)

my apologies, but I didn't notice this approval until after the l10n freeze so we can't take this on the branch anymore.

Comment 24

[Christian Eyrich]

As mentioned in comment #13, the UI for POP&IMAP now differs from the SMTP one despite it are the same options. I'd create a new bug to fix that but am not sure if one already exists. If noone objects, I'll create one.

Comment 25

[Nelson Bolyard (seldom reads bugmail)]

Attachment: The old wrong strings still appear here

I think perhaps this bug is only half fixed.  In Seamonkey, it seems to 
be fixed in the dialog where the user SETS these settings.

But there is another prefs pane that shows the current settings for an
outgoing SMTP server, and it still reports the security setting using 
the old strings.  It still shows "TLS (if available)", "TLS", and "SSL" 
instead of  "STARTTLS (if available)", "STARTTLS", and "SMTP-over-SSL".

Comment 26

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #24)
> As mentioned in comment #13, the UI for POP&IMAP now differs from the SMTP one
> despite it are the same options.

I've re-opened Bug 350314 for remaining POP3&IMAP case. 

Comment 27

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #25)
> The old wrong strings still appear here

Probably string in following lines for Seamonkey.
http://lxr.mozilla.org/seamonkey/source/suite/locales/en-US/chrome/mailnews/messenger.properties#136
> 136 # Used in the SMTP Account Settings panel when a server value has no properties
> 137 smtpServerList-NotSpecified=<not specified>
> 138 smtpServer-SecureConnection-Type-0=None
> 139 smtpServer-SecureConnection-Type-1=TLS (if available)
> 140 smtpServer-SecureConnection-Type-2=TLS
> 141 smtpServer-SecureConnection-Type-3=SSL

Comment 28

[Nelson Bolyard (seldom reads bugmail)]

Thanks, WADA.  

Note that bug 258540 is apparently a duplicate of this bug.
This bug is a "core" bug, that one is a Seamonkey bug.  
Please duplicate one or the other as you see appropriate.

Comment 29

[Magnus Melin [:mkmelin]]

Attachment: proposed additional fix

Fix the displayed smtp info also...

Comment 31

[Phil Ringnalda (:philor)]

Without a change in the property name, to let localizers see that there's a change they need to notice, that'll leave them stuck in the same state en-US is in now.

Comment 32

[Magnus Melin [:mkmelin]]

Phil: the property names are changed (was xx-y, now xx_y). Or did I miss something?

Comment 33

[Phil Ringnalda (:philor)]

No, you didn't miss a thing, but I sure did.

Comment 34

[Phil Ringnalda (:philor)]

mail/locales/en-US/chrome/messenger/messenger.properties 1.47
mailnews/base/prefs/resources/content/am-smtp.js 1.17
suite/locales/en-US/chrome/mailnews/messenger.properties 1.140

Comment 35

[Worcester12345]

(In reply to comment #25)
> Created an attachment (id=266903) [details]
> The old wrong strings still appear here
> 
> I think perhaps this bug is only half fixed.  In Seamonkey, it seems to 
> be fixed in the dialog where the user SETS these settings.
> 
> But there is another prefs pane that shows the current settings for an
> outgoing SMTP server...

To REALLY make it clear to users, it would be nice if all the server settings were on one page. Too many small choices and it gets confusing on where to set things, and if settings might be in conflict.

Comment 36

[WADA:World Anti-bad-Duping Agency]

Changing to VERIFIED, based on Bug 384188 Comment #1 and attachment 268146 [details] of "Screen shot of Bug 185662 is resolved" in it. (evidence of remained problem of Comment #25 after initial FIXED is really resolved)