220818 - Implement UI support for SMTPS, and simplify the SMTP UI at the same time (Secure SMTP port 465 protocol, using SSL, not STARTTLS)

Status: RESOLVED WONTFIX

(MailNews Core :: Networking: SMTP, defect)

Description

[Matthew Elvey]

Offshoot of Bug 135357, which is to add the feature but not add the UI.

Let's move all UI work (and discussion) here.  Bug 135357's comments are 10%
relevant, tops.

John Gerth's UI idea: a good new start:
http://bugzilla.mozilla.org/show_bug.cgi?id=135357#c133 says IN PART:

It seems to me that if "host:port" is available to override the
default port, then Gerv's minimal UI could, for the 99.44%, case be
reduced to a checkbox labelled "Require Secure Connection" since this 
function is logically independent of the port specification anyway.

Mozilla would then behave as follows:

Port
   Use 25 unless specifically overridden by host:port

Encryption 
<snip>
The above would result in encrypted connections whenever they
were available whether asked for or not.  At one time this was
objected to because of the expense of encryption, but that might
no longer be an issue.  The user still has the ability to send
mail through an insecure server and even, however unwise it
might be, to send an id and password over an unencrypted connection,
but as long as "Require Secure Connection" had been checked, 
this algorithm would never send an unencrypted id or password.

My comments:

Re. SMTPS (port 465 protocol: Perhaps it should be the first/only thing tried if
port 465 is specified. (And if port 465 is not specified, then SMTPS is ONLY
tried if a manual prefs (about:prefs / user.js) edit is made.  Anyone who needs
to do so will be sufficiently advanced a user (able to set up tunneling) that
discovering the need for and performing such editing would be a non-issue.) 
Programmatically: setting the port to 465 will enable SMTPS; changing it from
465 will disabe SMTPS.

I HAD thought the simplest UI could be was Always/Sometimes/Never (the current
UI), but I think John's is a workable further simplification.  Is making 'Never'
still available via a manual prefs edit a good idea?  I like it.  There are a
LOT of rarely used settings available only via a manual prefs edit, and I think
it's good that way.

Using STARTTLS if it's available doesn't need to slow down the process when it's
not available, so this auto-probing is OK.  (And this is the current default
setting!) The ehlo will always be run anyway, and if ehlo reports STARTTLS is
available, STARTTLS is used (else it depends on the "Require Secure Connection"
setting).

--

Thought experiment showing we must have a security setting (long):
If the user were just to give a server name and
username, Mozilla could simultaneously query the server on multiple connections
to find out what it supports(assuming the server supports simultaneous
connections), and just use the best one?  Should this happen just when the SMTP
settings are viewed/altered?  Well, that woudn't make much sense - when a laptop
changes networks, SMTP could easily just stop working - e.g. if just the new
network had port 25 blocking.  Having "open and close a window without changing
anything" being the way to make something work isn't good UI design, IMO. 
Checking every time a send is attempted would be significant overhead. 
(Timeouts: How long would the timeouts be?  Would they be adjustable for
impatient or poorly-connected users?  (Mozilla's SMTP currently has no timeout,
IIRC - Oh, NO! - I'm opening another can of worms: should it have timeouts?)
Last but not least, John G. Myers' comment #119 proves this is a security no-no
anyway.

--

Re. Port 587: If no port is specified, should 587 be attempted?  Well, having
some sort of auto-probing means we run into some of the same problems as the
thought experiment above: when does it make sense to probe? timeouts?  I don't
see a way for auto-probing to work well WRT port 587.

Comment 1

[John Gerth]

...Making port 465 special
   I'm hesitant to endorse that sort of behavior if only because
   it's so magical.  Ironically, I spent a lot of time debugging
   Outlook which, if you specify a port other than 25 *and* ask
   for a secure connection will *only* do SMTPS so, at least the
   last time I looked Outlook couldn't be used to get a secure
   connection to 587.

...on autoprobing
   I guess I think that trying an SSL handshake first isn't
   very expensive and no more auto really than the recognition
   of STARTTLS in response to EHLO

...trying 587 if no port specified.
   I don't think it should be the default (yet) and if you
   mean in addition to 25, I think that it really complicates
   reporting a sensible error back to the user since the 
   current 99.44% case has to be a server on 25 and nothing
   on 587. It does have the attraction of perhaps automatically
   compensating for a notebook which is taken behind an
   ISP blocking 25, but since it's the *server* that has
   to offer 587,  then I expect that the client would already
   be configured there to begin with.
   

Comment 2

[Matthew Elvey]

....Making 465 Special:
http://bugzilla.mozilla.org/show_bug.cgi?id=135357#c49 ,  
http://bugzilla.mozilla.org/show_bug.cgi?id=135357#c26 ,
http://bugzilla.mozilla.org/show_bug.cgi?id=135357#c57 ,
http://bugzilla.mozilla.org/show_bug.cgi?id=135357#c59 are relevant.
Key:
http://bugzilla.mozilla.org/show_bug.cgi?id=135357#c53 .

   I don't see how we can simplify the UI to fewer than 4 choices without such
'magical' behaviour.  Do you?  I don't know how get Gerv and Kai (or John and I)
to consensus on the 'best' solution.  I can say I'm OK with 4 well-worded
choices, but prefer the 'magic' UI.

It seems to me that the balancing to do is to weigh the difficulty of a user
figuring out which of those 4 choices to pick, vs the difficulty of dealing with
the magical behaviour being a problem, factoring in the frequency of such
difficulties cropping up.  

I think the frequencies with which SMTPS travels over ports other than 465 and
non-SMTPS traffic travels over port 465 are both *extremely* low. 

Interestingly, the patch #3 (including UI changes to support the new
functionality) to Bug 135357 was just checked in! (Yay!)  Perhaps I should
change the Summary to just "Simplify the SMTPS UI (Secure SMTP port 465
protocol, using SSL, not STARTTLS)"

Oh, and an FYI to anyone new to this bug, there is a workaround: use a build
from wamcom.org

Comment 3

[Denis Vlasenko]

I like this:
http://bugzilla.mozilla.org/attachment.cgi?id=125970&action=view

Users tend to configure this once with admin assistance and then copy
between themself. And if they do call me, I would not have slightest
problem to tell them 'choose SMTP/SSL' over the phone.

Comment 4

[Gervase Markham [:gerv]]

Not all users have admin assistance at the end of a phone... and saying "someone
who knows can explain it to them" is not a good excuse for having jargon-filled
and complex UI.

Gerv

Comment 5

[Denis Vlasenko]

I don't like designing interface which even a fool can use.
Because only fool will use it.

If user don't have a clue, (s)he can try each of those four
alternatives in turn, using only default ports. Eventually (s)he
will find one that works. No need for magic rules.

Comment 6

[Denis Vlasenko]

Attachment: KMail smtp config (part 1)

I think you guys might want to see how KMail crowd did it.

Comment 7

[Denis Vlasenko]

Attachment: KMail smtp config (part 2)

This is the security tab. Note: there is [Check what server supports] btn! ;)

Comment 8

[Matthias Wimmer]

It seems that Mozilla now adopted the KMail prefs where STARTTLS is called "TLS"
and smtps is called "SSL". I don't think that this was a good idea.
On the one hand this usage of SSL and TLS is just wrong. TLS is nothing more
then the IETF standardized version 3.1 of the SSL protocol and SSL is the name
of this protocol up to version 3.0. Most SMTPS connections actually use TLS and
not SSL. Also you can have a connection using the STARTTLS extension that uses
the older versions 2.0 or 3.0 of SSL.
On the other hand it increased the support work I have with my users. They all
try to switch from "TLS" (which they don't know what it stands for) to "SSL"
because that is something they know. But I guess there are much more cases where
the user has to use STARTTLS than SMTPS. Therefore it is very bad if the UI is
designed so that users prefere SMTPS.

Comment 9

[Christian Eyrich]

Matthias, we know all this. And if you look through bug 135357 you'll see that
we gone through all the considerations.

> On the other hand it increased the support work I have with my users. They
> all try to switch from "TLS" (which they don't know what it stands for) to
> "SSL" because that is something they know.

And it would have been better if we had called "TLS" "STARTTLS" and "SSL"
"SMTPS" oder "SMTP over SSL", yes?

> Therefore it is very bad if the UI is designed so that users prefere SMTPS.

Oh, it's all so bad. Where have you been 9 months before?

To be serious, I (and a few others) made a patch with the current UI to
implement SMTPS and checked it in without big consensus. Without this arbitrary
act the discussion would still go on and noone would use the feature at all.

If you've the ultimative UI, make a patch (or a sketch of the UI) and we'll see.
BTW, my drafts are still available at
http://www.eyrich-net.org/mozilla/pref_panels.php.

Comment 10

[Matthew Elvey]

 Bug 135357 was fixed a while ago.  I'm not strongly in favor of simplifying the
UI (because of comments like Gerth's).  I am not in favor of a UI war.  The
decision has been made and implemented.  So I'm closing my bug as wontfix.  I
doubt any change is likely to get checked in.  (I wonder if current Netscape has
the same UI.)  Thanks, all.