User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:18.104.22.168) Gecko/20100317 SeaMonkey/2.0.4 Build Identifier: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:22.214.171.124) Gecko/20100317 SeaMonkey/2.0.4 With SeaMonkey 2.0.4, both Windows (32-bit) and Linux (both 32-bit and 64-bit), the Secure Authentication keeps defaulting to "yes" at each launch, even after the checkbox is cleared for the default e-mail account and sometimes others. When this is set to "yes", SM cannot send e-mail and displays an error about it being set. Once the checkbox is cleared, e-mail can then be sent. Then, on the next launch of SM, the Secure Authentication setting changes back to "yes" by itself. It's quite annoying. Reproducible: Always Windows - Vista Home Edition (32-bit pre-installed on 64-bit platform) Linux - Ubuntu 9.04 (64-bit installed on 64-bit platform and 32-bit installed on 32-bit platform)
Are changes to other preferences persist after a relaunch ?
Any other changes made to the preferences, will stay as they are. It is only the "Secure Authentication" item that changes to yes (or checkbox becomes checked) at each new launch.
This works for me with Seamonkey trunk on win32. This is either an issue only in 2.0.4 or something else. The smtp settings can be found in about:config (or as prefs.js in the profile) under "mail.smtpserver......" You didn't created a user.js file in your profile to override the settings ? Do you created the Accounts with 2.0.4 or are that older Accounts ?
The user.js file is the original and the accounts were originally created with an earlier version of SM. What I noticed in about:config is that for the two accounts this happens to, there are lines: mail.smtpserver1.smtp1.trySecAuth (set to false) mail.smtpserver1.smtp1.useSecAuth (set to true) mail.smtpserver2.smtp2.trySecAuth (set to false) mail.smtpserver2.smtp2.useSecAuth (set to true) but these same lines are not present for another account. The line for the third account only has: mail.smtpserver3.smtp3.auth_method (set to 1) Would removing the above four trySecAuth/useSecAuth lines fix this?
Sounds like bug 580270, which was only fixed for SM 2.1. But AFAICS, that only affected profile migration. edward, can you please try to reproduce with SM 2.1b1? Otherwise we'll probably close this bug as WFM (according to comment 3). (In reply to comment #4) > Would removing the above four trySecAuth/useSecAuth lines fix this? You could first try toggling them (true->false and vice-versa) individually, e.g. in about:config. But it would surely be interesting to know whether that helps.
Whiteboard: [CLOSEME 2011-02-01 WFM]
I'm going to close this as WFM, as this problem has not reappeared in a LONG time. :)
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.