Closed Bug 529763 Opened 15 years ago Closed 13 years ago

new account wizard makes poor decisions and doesn't let you recover an account

Categories

(Thunderbird :: Account Manager, defect)

x86
Windows Vista
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: emoore, Unassigned)

References

Details

(Keywords: dataloss)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.5) Gecko/20091117 Thunderbird/3.0 I'm using build 2 of Thunderbird 3.0RC1. I had two IMAP Gmail accounts, a IMAP Google Apps account with DslExtreme (my ISP) and a POP Gmail account. I deleted the Gmail POP account and then tried to add it again using the new account wizard. It defaulted to a IMAP account. The first time I tried it I accidentally entered the wrong password. It never got rid of the red "username or password invalid" even after having it successfully test a POP configuration. . It chose GoogleMail mail servers despite my being in the USA , having multiple existing accounts using Gmail servers, and using a gmail.com address. It actually used my existing Dslextreme SMTP server (thus wrong username) when I selected smtp.gmail.com:587. The Outgoing list box is not long enough to fully display the server name and there is no SSL/TLS list box for it like there is with the incoming mail server. The layout of the incoming and outgoing servers should be as consistent as possible. The second time it defaulted to a IMAP account and imap.googlemail.com as the mail server. I changed that to POP and it did not update the mail server name or provide a list box to let me chose a different mail server. Outgoing defaulted to smtp.gmail.com:587 this time. Still no SSL/TLS list box or a port number field like the incoming server has. I changed the incoming server to pop.gmail.com using the edit field and told it to retest the configuration. That succeeded. The outgoing server is listed as smtp.gmail.com:5.. I pressed the create account button. The account settings says it uses Gmail -smtp.gmail.com as the SMTP server. This is not a unique name. It should have picked one that used my username since I have other Gmail SMTP servers. It turns out its actually the SMTP server used for one of my IMAP Gmail accounts (wrong username). It didn't create one for the POP account. I logged into the POP accounts webmail and looked at the forwarding and POP/IMAP settings. Both POP and IMAP are enabled. Perhaps that caused some confusion. I checked for new mail. My inbox doesn't show any messages despite Gmail webmail showing 5 unread messages and several read messages. I sent myself a new message and it showed up. Looking in my profile I see that ..\Mail\pop.gmail.com still exists and it created a ..\Mail\pop.gmail-1.com which it used. That explains why I didn't see any of the old messages. I expected it to reuse the old account directory like it has in the past when you delete an account and then add it again. I've helped several people who accidentally deleted their account and got their messages etc. back by adding it again. Thunderbird used to always reuse the account directory for the deleted account when you added the account again as long as you used the same mail server. Not being able to do that anymore will cause a major problem for users who don't know how to import folders etc. Is there a web page that documents how the new account wizard works? I like what the new account wizard tries to do and assume this would have worked much better if I was adding a Gmail account to a new profile but from my viewpoint the user interface needs work, it makes poor decisions, its not backwards compatible, and it never configures the correct SMTP server. Reproducible: Always
Blocks: qa-tb3.0rc1
trusting Eric's report and confirming. Perhaps the real solution is whenever "add account" is selected, and before it gets to the account create process, to inform the user what other account files thunderbird thinks is still in the profile? I don't know if we can blame the new account mgr if what has been exploited to recover accounts previously was a kludge. Still, elevating severity with dataloss because this impacts helping people recover lost data. I suspect solution will want to be delivered in 3.0.1
Severity: major → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: dataloss
Version: unspecified → 3.0
Confirming that the decisions are poor. For an IMAP account, it seems to be OK. Preferring port 143 with STARTTLS, over SSL on 993. For SMTP, though, it's bad. My server offers SSL on port 465 (only to support bad MS clients), and ports 587 and 25 with STARTTLS. Port 587 is the standard message submission port, defined in RFC 4409. It should be preferred to port 465 (not allocated for SMTP) and port 25 (often blocked by ISPs). As regards POP/IMAP, well I'd think IMAP should be preferred because it's a superior protocol. However, users may differ in this, so they should be offered an informed choice if both IMAP and POP3 servers are found.
This bug may be caused by bug 538809 - It seems that port 587 is tested first without any encryption protocol. Since password authentication is required on port 587 (in most cases), STARTTLS is almost always going to be required, too.
Port 587 (Submission), should advertise with requiring authentication the capability of 'STARTTLS'. Thunderbird should then attempt to authenticate using the supplied credentials. There are cases where Submission may be setup to assume that people with a specific IP address are authorised to access the server without requiring encryption.
Restoring deleted accounts by creating them in the same account directory might be a kludge, but its a well known, old and documented one. See http://kb.mozillazine.org/Recovering_deleted_mail_accounts for example.
It's true that an IP address might be enough to authenticate submission, but the point of using port 587 is to allow access through third party firewalls that block port 25, ie from unauthenticated IP addresses. Therefore, there's no point using 587 without offering authentication facilities and STARTTLS. Given that the user may be configuring Thunderbird on a mobile device, with variable IP address, it should default to use STARTTLS if available.
is "new account wizard" really a necessary component of this bug?
Summary: new account wizard makes poor decisions and doesn't let you restore an account → new account wizard makes poor decisions and doesn't let you recover an account
Preferring SSL with 465 vs. 587 with STARTTLS is intentional. > it defaulted to a IMAP account and imap.googlemail.com as the mail server. > I changed that to POP and it did not update the mail server name or > provide a list box to let me chose a different mail server. This should be fixed now, as well as many other UI bugs.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
(In reply to comment #8) > Preferring SSL with 465 vs. 587 with STARTTLS is intentional. Why? To which extent are SSL/TLS and STARTTLS different from a security point of view? I sure agree to take 465 if 587 doesn't provide STARTTLS. (In reply to comment #2) > Port 587 is the standard message submission port, defined in RFC 4409. It > should be preferred to port 465 (not allocated for SMTP) The lack of a proper registration of 465/tcp for SMTP would be one reason to choose 587 with applicable protocols...
rsx, 465 SSL and 587 STARTTLS (forced) are the same security-wise. Still, if both are offered, we have to choose one of them. It's a close call. We choose SSL over STARTTLS, because it has less overhead - the SSL connection is built immediately, and there's no second CAPS call etc. to be made, so it should be marginally faster and more efficient. Basically, this is not a bug.
(In reply to comment #8) > Preferring SSL with 465 vs. 587 with STARTTLS is intentional. Are you serious? As a MUA - Thunderbird should be preferring 587, 465 and then 25. 587 is set aside for MUA - SMTP (i.e. the SUBMISSION protocol, RFC4409) which is the category Thunderbird fits best. For those environments which have not had a chance to upgrade in the last decade or so, then 465 and 25 are useful fallbacks.
You need to log in before you can comment on or make changes to this bug.