Closed Bug 134238 Opened 23 years ago Closed 21 years ago

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


(MailNews Core :: Networking: POP, defect)

Not set


(Not tracked)



(Reporter: tmeader, Assigned: sspitzer)




(1 file)

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 

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.
Can you give a test acct ? 

I am seeing that the port value is not preserved when using SSL.
Ever confirmed: true
Keywords: nsbeta1
Discussed in Mail News bug meeting.  Decided to minus this bug.
Keywords: nsbeta1nsbeta1-
Target Milestone: --- → mozilla1.2alpha
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.
*** Bug 161089 has been marked as a duplicate of this bug. ***
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.
Summary: Changing the port for POP with SSL server has no effect → Changing the port for POP with SSL server to 110 has no effect
QA Contact: sheelar → esther
Attached patch Patch v1Splinter Review
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
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
- 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.
Attachment #110664 - Flags: review?(naving)
Blocks: 128390
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!  :-)
mass re-assign.
Assignee: naving → sspitzer
Attachment #110664 - Flags: superreview?(sspitzer)
*** Bug 162180 has been marked as a duplicate of this bug. ***
This is annoying, and you already have a patch for it. Wassup? 
*** Bug 218730 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla1.2alpha → ---
Attachment #110664 - Flags: review?(naving) → review?(mscott)
Attachment #110664 - Flags: superreview?(sspitzer)
Attachment #110664 - Flags: superreview+
Attachment #110664 - Flags: review?(mscott)
Attachment #110664 - Flags: review?(ch.ey)
Attachment #110664 - Flags: review?(ch.ey) → review+
fix checked in. 
Closed: 21 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.7beta
*** Bug 240882 has been marked as a duplicate of this bug. ***
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.