After install of 2.0.1 RC with "build2", SM tries to go to http://www.seamonkey-project.org/releases/seamonkey2.0.1/ on first start. It can't.
It's not even available on the beta channel yet - and we usually only traget to have the relnotes up for when the update is actually released.
I just added a page there, but it really doesn't contain anything specific to 2.0.1 yet, just a copy of the 2.0 relnotes with changes replaced with a TBD.
For the Known Issues list, bug 522633 is fixed for the stated GSSAPI case prompting "Use secure authentication" to be checked, but there is still bug 524868 for migrating "Use name and password" causing an error message.
I did basic updates for the relnotes, but comment #3 still has to be handled. Also, the changes page is probably not ideal yet.
Updated http://www.seamonkey-project.org/releases/seamonkey2.0.1/changes through a bug categorization tools I wrote to assist with that job.
After setting the fixed-seamonkey2.0.1 keyword on the affected MailNews Core bugs, I could use my categorization tool to update the changes page with those as well. We now have 137 bugs fixed between 2.0 and 2.0.1, 115 of which are public at this moment (security bugs will be opened after release, will update changes page according to that later). For bug 524868 (comment #3), I couldn't completely make out what is set wrongly when migrating exactly what cases from 1.x with a 2.0.1 build, so I did a somewhat vague entry in "Known Issues", to be made more specific when I get more crisp information. With that, I consider the 2.0.1 relnotes done. Feel free to suggest further entries for Known Issues or other changes to relnotes here, though, I'll get bugmail and look at it.
> Migrating a SeaMonkey 1.x profile may set "Use username and password" > and/or a different setting than "None" for "Connection Security" in > the Outgoing Server (SMTP) settings, even for servers that don't need > any authentication or security. Unchecking the option and seeting > security to "None" resolves the issue in those cases. (Bug 524868) The reference to connection security is wrong here, secure authentication has nothing to do with connection security. The issue in bug 534158 relates to the removed "TLS, if available" setting, which is a different story, though it may cause similar problems within a trusted/untrusted network environment.
rsx11m: I just analyzed what I could read out of that bug, but it was unclear enough which setting was wrong and needed to be corrected. Can you give me a good sentence/description to use for that point in the "Known Issues" section?
I was afraid of that request coming, ;-) but I'll give it a try: Settings for the Outgoing Server (SMTP) are now applied stricter. An error is reported if "Use name and password" is set but not requested by the server, or if "Use secure authentication" is set but not offered by the server. Thus, SMTP settings which worked with SeaMonkey 1.x may prompt an error in 2.0 and need to be adjusted in the Account Settings. I don't know if you want to specifically address the trusted/untrusted mix as this is a rather specific use case.
Thanks, updated the entry with your message. It's always better if someone how knows the issue writes it up instead of me just trying to make up "something", because "something" was requested to be mentioned ;-)
This is looking very "filled-in" now. However, I note the following missing/dead links: "Security fixes" is a bad link - not just in the sense of the 2.0.1-specific content not being present, but the base page itself (http://www.mozilla.org/security/known-vulnerabilities/seamonkey20.html) appears to be missing. "relative to SeaMonkey 2.0" also doesn't actually go anywhere. Both of the above are either "bad" addresses, or else the SM 2.0 pages themselves were never created(?).
(In reply to comment #11) > "Security fixes" is a bad link Will be corrected by the Mozilla security team - the .1 version is usually when this page gets created. > "relative to SeaMonkey 2.0" also doesn't actually go anywhere. Thanks, was a bad link (using 1.x relnote style), corrected that.