134238 - Changing the port for POP with SSL server to 110 has no effect

Status: RESOLVED FIXED

(MailNews Core :: Networking: POP, defect)

Description

[Tim Meader]

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461)
BuildID:    2002032803

When trying to change the default port to access POP with SSL from 995 default 
to 110, change has no effect. It DOES WORK without SSL though. Meaning it WILL 
let you change the port number if you aren't using POP with SSL.

Reproducible: Always
Steps to Reproduce:
1.Go into Mail/News->Edit->Mail & Newsgroups Account Settings...
2.Choose a POP account from the list and then click on Server Settings.
3.Check "use secure connection (SSL)" on the right.
4.Change the Port to anything else, but I use 110, the POP standard.
5.Hit OK and then try to check your mail. Assuming you DON'T have your POP SSL 
server running on port 995, you'll get a connection refused message.
6.Go back in and check the Port setting and you'll see that it's still set to 
995.

Actual Results:  Mozilla attempted to connect on port 995 no matter what port 
you changed it to.

Expected Results:  It should have retained the new port setting and attempted 
to connect on that instead.

Strangely, changing the port does work fine if "use secure connection (SSL)" 
isn't checked.

I feel this is a rather major oversight, since, while 995 is what Outlook 
defaults to for POPw/SSL, Eudora defaults to 110 for both, and since that is 
the vast majority of our installed base, we would  have to run a second 
listener for POP connections on 995 just for our people using Mozilla, and go 
around to all installed Eudora clients and change the port number to 995.

Just as a heads up, QPopper is MUCH easier to configure for SSL on 110, and 
all sysadmins I know who have enabled it simply leave it listening on that 
port too. No real advantage to 995.

Comment 1

[Navin Gupta]

Can you give a test acct ? 

Comment 2

[Navin Gupta]

I am seeing that the port value is not preserved when using SSL.

Comment 3

[Michael Buckland]

Discussed in Mail News bug meeting.  Decided to minus this bug.

Comment 4

[Tim Meader]

Sorry to see this has gotten brushed off I must say. Regardless, would it AT 
LEAST be possible to make it so that the Port Number field is NOT editable once 
you select SSL? This would make things much easier for others in the future I 
think, and could potentially save other people some major time trying to figure 
out why it's not working for them.

At the very least a message to let them know of this bug till it's fixed.

Much appreciated.

Comment 5

[Olav Vitters]

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

Comment 6

[Olav Vitters]

Related: bug 128390 (same issue, but IMAP)

Fixing summary. Port number is stored when it is NOT 110. Only when using 110 as
port number it changes back to 995.

Comment 7

[Olav Vitters]

Attachment: Patch v1

Note: This is the first time I've used C++

1. nsMsgIncomingServer::SetPort did not use isSecure (SSL) for
GetDefaultServerPort and port=110 was never saved. When isSecure is true,
SetPort doesn't save port=110 and GetPort happily returns the default port 995.


2. After making sure SetPort uses isSecure, I've noticed Mail & Newsgroup
Account Settings -> Server Settings saves the preference server.port before
server.isSecure. This causes the changes in #1 to fail when isSecure is
changed.
Bug example:
- Current port=110; SetPort saves PORT_NOT_SET
- Current isSecure=false
- User checks SSL. Javascript changes port to 995.
- User changes port to 110.
- User clicks Ok
- Preference port=110 is saved; SetPort saves PORT_NOT_SET because isSecure is
false
- Preference isSecure is saved -- and GetPort would still return 995

I've avoided #2 by (hopefully) making sure server.isSecure is saved before
server.port. This allows #1 to still do the right thing when only isSecure is
changed and port = PORT_NOT_SET.

Comment 8

[Todd Cohn]

Now that the trunk is open again can someone take a look at this bug?  We have a
patch here in danger of bit-rot, if it hasn't already, and this bug has become
very bothersome to me recently.  I'm begging here!  :-)

Comment 9

[(not reading, please use [e-mail] instead)]

mass re-assign.

Comment 10

[Frank Wein [:mcsmurf]]

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

Comment 11

[Carl A. Dunham]

This is annoying, and you already have a patch for it. Wassup? 
 

Comment 12

[Max Alekseyev]

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

Comment 13

[Scott MacGregor]

fix checked in. 

Comment 14

[Jo Hermans]

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