Closed Bug 470067 Opened 16 years ago Closed 16 years ago

Thunderbird 3.0b1 changes IMAP TLS port 143 to 993 when upgrading from v2 (when no mail.server.serverN.port entry in prefs.js)

Categories

(Thunderbird :: Account Manager, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 3.0b2

People

(Reporter: lawmay, Assigned: mkmelin)

References

Details

(Keywords: regression)

Attachments

(1 file)

User-Agent:       Opera/10.00 (Windows NT 5.2; U; en) Presto/2.2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1b3pre) Gecko/20081204 Thunderbird/3.0b1

When upgrading Thunderbird from v2.0.0.18 to v3.0b1, all IMAP accounts set to "TLS" port 143 under v2.0.0.18 are changed to port 993 under v3.0b1. All such accounts must be manually changed back to port 143 in order to connect to IMAP servers.

Reproducible: Always

Steps to Reproduce:
1. Under Thunderbird v2.0.0.18 Set up multiple IMAP accounts set to "TLS" port 143
2. Upgrade Thunderbird from v2.0.0.18 to v3.0b1 manually: by unpacking installer and copying in new files, not by running installer
3. Run Thunderbird v3.0b1
Actual Results:  
Under Thunderbird v3.0b1, all TLS IMAP accounts are now mistakenly set to port 993. That makes it impossible to connect to these IMAP servers until ports are manually reset to port 143.

Expected Results:  
All TLS IMAP accounts should have remained set to port 143 as they were set up under Thunderbird v2.0.0.18.
Component: Migration → Account Manager
QA Contact: migration → account-manager
Flags: blocking-thunderbird3+
Target Milestone: --- → Thunderbird 3.0b2
did we screw up isSecure or something like that?
Tb's behabiour relates to following entries looks to be different between Tb 2 and Tb trunk.
> user_pref("mail.server.serverN.port",xxx);
> user_pref("mail.server.serverN.socketType",y); (y=0: Never, y=2: TLS)
> user_pref("mail.server.serverN.type","imap");  (IMAP server) 

(1) When mail.server.serverN.port entry doesn't exist, displayed Port is:
(1-A) Tb 2.0.0.18
      When Never(0), Port: 143 (Default: 143)
      When TLS(2),   Port: 143 (Default: 143)
(1-B) Tb trunk(2008/12/14 build)
      When Never(0), Port: 143 (Default: 143)
      When TLS(2),   Port: 993 (Default: 143)
Internal default port number when TLS looks to be changed to 993 by Tb trunk.

(2) When IMAP account creation, mail.server.serverN.port is not generated.
    ("Never" is set initially)

(3) When "Use secure connection" setting is changed(Never->TLS, or TLS->Never),
    Tb doesn't change Port: number display at Server Settings panel.
    (If change to SSL is done, mail.server.serverN.port is generated,) 
    (then problem won't occur.                                       )
     
(4) When Port: number field is not altered at Server Settings panel.
(4-1) Tb doesn't generate serverN.port entry, when serverN.port doesn't exist.
(4-2) Tb doesn't alter    serverN.port entry, when serverN.port already exists.

(2), (3) and (4) were applicable to both Tb 2.0.0.18 and Tb trunk.

Due to combination of above, funny phenomenon can be observed with Tb trunk, by changing between None and TLS when no serverN.port entry.
(a) Never->TLS : Port: 143 is still displayed. serverN.port is not generated.
    => When Server Setting panel is opened again, Port: 993 is displayed.
(b) TLS->Never : Port: 993 is still displayed. serverN.port is not generated.
    => When Server Setting panel is opened again, Port: 143 is displayed.

To lawmay@mailinator.com(bug opener):

Because you altered Port: number field manually, I think following entry is already created. Is it right?
> user_pref("mail.server.serverN.port",143);
If yes, I think you can't observe problem any more, unless you manually delete mail.server.serverN.port entry in prefs.js. Is it right?
I've seen this on trunk too
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20081210 Shredder/3.0b2pre
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #3)
> I've seen this on trunk too

New phenomenon is found.
(5) When mail.server.serverN.port doesn't exists,
    and when problem of (1-B) occurred with Tb trunk (993/TLS is displayed),
    Tb trunk doesn't generate mail.server.serverN.port entry 
    when Port number is change from 993 to 143 via UI.
    So, when Tb trunk is restarted, 993/TLS is displayed again(problem of 1-B).
You are probably looking this phenomenon.

Workaround of phenomenon (5).
  Check SSL => Port: 993 (Default: 993) is displayed.
  Check TLS again(still Port:993), and Change port number to to Port: 143.
  => Tb trunk generated mail.server.serverN.port with 143.

Nikolay Shopik, can you see problem after above workaround?
No problem at all after I manually change port number.
(In reply to comment #2)
> To lawmay@mailinator.com(bug opener):
> 
> Because you altered Port: number field manually, I think following entry is
> already created. Is it right?
> > user_pref("mail.server.serverN.port",143);
> If yes, I think you can't observe problem any more, unless you manually delete
> mail.server.serverN.port entry in prefs.js. Is it right?

I can confirm that this is correct; if I delete the "mail.server.serverN.port" pref, the TLS port is (incorrectly) set to 993 the next time I start Thunderbird.

Changing it to 143 creates that preference and so works fine on subsequent runs.
Adding mail.server.serverN.port in summary, for ease of search.
Summary: Thunderbird 3.0b1 changes IMAP TLS port 143 to 993 when upgrading from v2 → Thunderbird 3.0b1 changes IMAP TLS port 143 to 993 when upgrading from v2 (when no mail.server.serverN.port entry in prefs.js)
This bug occurs not only when upgrading to TB 3.0b1 but also within TB 3.0b1 when adding a new IMAP account set to "TLS" port 143.

Reproducible: Always

Steps to Reproduce:
1. Under TB 3.0b1 add a new IMAP account set to "TLS" port 143
2. Complete new account setup and close account manager.
3. Select Inbox of new account in order to login and check mail.

Actual Results:  
Login fails. Reopen account manager. The new account has been mistakenly changed to port 993. That makes it impossible to connect to IMAP server until port is manually reset to port 143.

Expected Results:  
The newly created TLS IMAP account should have remained set to port 143 as it was set up.
I can confirm the behaviour mentioned in comment 8. This looks like a regression from bug 462045 that changed how nsMsgIncomingServer::IsSecure works.

The issue is that setting the server to always using TLS now flags the server as "secure". Unfortunately all the cases I've looked at seem to use the isSecure flag to determine whether or not to use the secure port or the non-secure port as default.
Blocks: 462045
Keywords: regression
Assignee: nobody → mkmelin+mozilla
OS: Windows Server 2003 → All
Hardware: x86 → All
Attached patch proposed fixSplinter Review
A few isSecure misuses - only ssl uses the secure port. 

(The removed js is an old hack, and not needed - i verified I can manually set SSL IMAP to port 143 with this patch.)
Attachment #353990 - Flags: superreview?(neil)
Attachment #353990 - Flags: review?(bugzilla)
Status: NEW → ASSIGNED
Attachment #353990 - Flags: superreview?(neil) → superreview+
Attachment #353990 - Flags: review?(bugzilla) → review+
changeset:   1485:476f13748f3c
http://hg.mozilla.org/comm-central/rev/476f13748f3c
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Version: unspecified → Trunk
You need to log in before you can comment on or make changes to this bug.