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

Enhancement

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.

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).

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)".

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 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.

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

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 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!

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).

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

Same issue applies to IMAP and POP3 options. "2004-10-18 17:17 PDT" patch covers only SMTP options.

(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 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)

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

Actually it would look quite good, imo.

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 on attachment 245106 [details] [diff] [review] Jan Braun's patch, unbitrotted and including thunderbird (not just seamonkey) ok, thx, guys.

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 on attachment 245106 [details] [diff] [review] Jan Braun's patch, unbitrotted and including thunderbird (not just seamonkey) Low risk patch, only string changes.

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 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.

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.

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".

(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.

(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

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.

Fix the displayed smtp info also...

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.

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

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

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

(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.

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)