Should we remove that line from mailnews.js? Before PSM 2.0 (if I understand the chronology right), SMTP over SSL was controlled by: pref("mail.smtp.ssl", 0); // 0 = no, 1 = try, 2 = must use SSL This was the pref in Navigator if I understand what I've been reading. This UI was removed in bug 46393. When SMTP over SSL was re-implemented, it was using new pref: pref("mail.smtpserver.default.try_ssl", 1); This feature and prefs UI are described in bug 30321. -- I'm mentioning this because I think that confusion over this feature "Send SMTP over SSL" and it's multiple attempts at implementation, has lead to a lot of confusion, which in turn opened the door for these "sending mail breaks when (mail.smtpserver.default.try_ssl = 1)" problems. There were two problems: Sending silently died w/o an error: 58761 and 78856. More popular, sending dies and returns an error: 74387 I'm starting to think that if you connect to a server with SSL, then you had the second problem. If you did not get what I'm going to vaguely assume was a TLS handshake (58761's server probably did not support this, and 78856 is a failure to connect), then you get data loss. I also searched the entire bugzilla database and surfed the mozilla site, I could not find any explaination of why we are switching prefs in the PSM code.
-> default owner
Mozilla build: Linux/i686, 2001110708 Behavior: "Unable to connect to SMTP Server" when SMTP-over-SSL enabled "When available". What's New: Behavior DOES NOT GO AWAY when SMTP preferences UI is reset to SMTP-over-SSL "Never". Steps to reproduce: 1) Change directories to Mozilla preferences dir: /usr/home/goodmanj/.mozilla/goodmanj/j747v8qq.slt 2) Make a backup copy of prefs.js: cp prefs.js prefs_start.js 3) Start Mozilla ~/mozilla/mozilla 4) Send an e-mail message to self. Result: successful 5) Open "Mail & Newsgroup Account Settings..." dialog 6) Choose "Outgoing Server (SMTP)" 7) Change "Use secure connection (SSL)" from "Never" to "When Available" 8) Send an e-mail message to self. Result: "Unable to connect to SMTP Server"' 9) Open Mail & News account settings, reset "Use secure connection" to "Never". 10) Send an e-mail message to self. Result: STILL "Unable to connect to SMTP Server" 11) Quit Mozilla 12) Find out what preferences have changed: % diff prefs.js prefs_start.js 127a128 > user_pref("mail.identity.id2.smtpServer", ""); 13) Restore the old prefs file % cp prefs_start.js prefs.js 14) Restart Mozilla, and send a new test message. Result: successful Comments: It's not just that the "Use SSL" pref is broken, it's also that the pref *stays* broken until you delete the above line from the prefs.js file. (And it took me hours and hours to figure out that was what was wrong.) Other notes: I appear to have two completely redundant (and potentially incompatible) sets of SMTP information in the prefs.js file. This seems to relate to the pre/post-PSM changes discussed here: % grep 'smtp' prefs.js user_pref("mail.identity.id2.smtpServer", ""); user_pref("mail.smtp.defaultserver", "smtp1"); user_pref("mail.smtp.ssl", 1); user_pref("mail.smtp_name", "goodmanj"); user_pref("mail.smtpserver.smtp1.auth_method", 0); user_pref("mail.smtpserver.smtp1.hostname", "nsit-email.uchicago.edu"); user_pref("mail.smtpserver.smtp1.try_ssl", 0); user_pref("mail.smtpserver.smtp1.username", ""); user_pref("mail.smtpservers", "smtp1"); user_pref("network.hosts.smtp_server", "midway.uchicago.edu"); Note the presence of both "mail.smtp.ssl" and "mail.smtpserver.smtp1.try_ssl", and both "network.hosts.smtp_server" and "mail.smtpserver.smtp1.hostname". Both of these pairs can have different values. The "old" pref names (mail.smtp.ssl and network.hosts.smtp_server) appear to be carried over from my old Netscape 4.7 prefs file -- they do not appear if I delete prefs.js and reconfigure Mozilla from scratch. However, the "sticky prefs" problem is independent of the "redundant prefs" problem.
Jason: What you report here is a duplicate of bug 108912, actually fixed yesterday (11/8). Please use a fresher build. Take note that I descruibed identical way of triggering the problem in bug 109115 (a dup of 108912).