394487 - Thunderbird should attempt SSL and TLS by default when creating new accounts.

Status: RESOLVED DUPLICATE of bug 387421

(Thunderbird :: Security, defect)

Description

[Brian Bennett]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en) AppleWebKit/419.3 (KHTML, like Gecko) Safari/419.3
Build Identifier: 2.0.0.4

It is now 2007, and this willy-nilly disregard for users' security is shameful.  Most people are unaware of wether or not their provider support SSL/TLS connections and have no clue as to why one might want to enable it.

For the incoming server Thunderbird should attempt to contact the account's POP3/IMAP server on the default port (110 and 243 respectively) and check for STARTTLS capability.  If STARTTLS is unavailable it should check on the appropriate default SSL port (995 and 993 respectively).  Only if this also fails should Thunderbird fall back to using unencrypted connections.

Additionally, for the outgoing server Thunderbird should first try using the Submission port (587) and check for STARTTLS capability.  If this fails try SMTP over SSL on port 465.  If this fails try SMTP on port 25 for STARTTLS. If this fails try port 587 unencrypted and if that also fails finally port 25 unencrypted.

Reproducible: Always

Steps to Reproduce:
1. Run Thunderbird
2. Create a new account
3. There's no step 3! Ha ha...there's no step 3.
Actual Results:  
Thunderbird is insecure.

Expected Results:  
Thunderbird is secure.

The following should be checked in order:
POP3:
110/STARTTLS
995/SSL
110 unencrypted

IMAP:
143/STARTTLS
993/SSL
143 unencrypted

SMTP:
587/STARTTLS
465/SSL
25/STARTTLS
587 unencrypted
25 unencrypted

Comment 1

[rsx11m]

In general, this appears to be a good suggestion. The feedback on MZ forums indicates that a lot of users have problems setting up their e-mail correctly, as a steadily increasing number of providers require encryption to protect their customers' authentication information (and themselves from spamming). The message itself will still go unencrypted between providers, thus the security argument is somewhat weakened here as for protecting the content. There are some arguments against encryption on the client's side too, e.g., to allow virus-scanning of incoming and outgoing e-mails, thus it may depend on the user's preferences. Also, while ports 993 and 995 are registered on http://www.iana.org/ as IMAP and POP over SSL, the definitions of ports 465 and 587 for secure SMTP are less clearly established. Nevertheless, taking the parameter guesswork out of the e-mail setup and ensuring that encryption is used by default if available would certainly make the initial account setup less painful for many users. Rather frequently, not even the support staff of a provider is able to give correct information on the connection settings of their own services.

This proposal would go beyond bug 221030 and bug 80919 for extending the account wizard user interface, and beyond bug 270483 which is merely asking for making "try TLS" the default setting. The question is where and when the port scanning should be performed. The account wizard currently only sets the parameters for the servers, thus scanning at the first time a connection is opened may be a good solution. The proposed account wizard redesign in bug 221030 attachment 186131 [details] could be extended by a port number (if known), along with a "don't know" or "scan" option. If the latter was selected, the parameters are set accordingly after the scan was conclusive.

Also, ports 110 / 143 and 25 / 587 would have to be scanned only once, as the presence of STARTTLS or the lack thereof would indicate whether or not TLS is supported. Ports 993 / 995 and 465 should imply SSL encryption and would only have to be tested if STARTTLS is not present on the respective other ports.

Comment 2

[Brian Bennett]

I guess in at the end where I said "the following should be checked in order" should rather read "the following should be preferred in order", because you're right, you'd only have to check a port once to know if it was capable of supporting TLS.

Comment 3

[Magnus Melin [:mkmelin]]

Dupe of bug 387421, or bug 185631.