After creating news account through clicking news URL Account Wizard is broken (skips account type selection, bound to invalid news account)

ASSIGNED
Assigned to

Status

defect
--
major
ASSIGNED
10 years ago
4 months ago

People

(Reporter: InvisibleSmiley, Assigned: frg, NeedInfo)

Tracking

({relnote})

SeaMonkey Tracking Flags

(seamonkey2.39 affected)

Details

(URL)

Attachments

(4 attachments, 3 obsolete attachments)

(Reporter)

Description

10 years ago
As Susanne Jaeger reported in the German MailNews newsgroup, after following a news:// URL you'll be unable to select the account type (mail, feeds, news) when opening the Account Wizard (either from the File menu or Account Settings). Instead you'll be taken directly to the Identity wizard page and from there to the Server Information wizard page. At least the Server Information page will show the account data matching the newsgroup subscribed to through the news:// URL. You will not be able to finish the wizard without changing the Newsgroup Server name. However, even finishing the wizard won't solve the problem.

Problem source: The account is declared invalid, i.e. the mail.server.serverX.valid pref is set to false (where X is the matching account).

Root cause: unknown, yet to be determined. Accounts created in the way described above are either missing a validation step or the corresponding function is broken.

Workarounds: Set mail.server.serverX.valid to true or delete invalid news account.

Backtrace:
1. AccountWizard.js: checkForInvalidAccounts() calls GetPageData() which sets gPageData
2. aw-accounttype.js: also calls GetPageData() which returns the created news server's data because gPageData is still pointing to that.

Comment 1

10 years ago
The faulty behaviour in the Account Wizard is similar to bug 521627.
(Reporter)

Updated

10 years ago
Duplicate of this bug: 521627
Found this problem myself on SeaMonkey 2.0.1. It is somewhat nasty, because there is no clue about the reason why suddenly the account manager stops working right.

Is there something we (users) could do to help fixing this problem (providing a fixed set of steps, activating mail debugging logs, etc.)?

BTW, this bug affects SeaMonkey 2.0 branch, so maybe the version field should be changed?
(In reply to comment #3)
> Found this problem myself on SeaMonkey 2.0.1.


BTW, in my case clicking in a news:// link didn't CREATE a fake news account; instead, MODIFIED one of my newsgroup accounts, renaming it and changing the From: e-mail address associated to it.

Comment 5

9 years ago
Do you have the prefs.js files before and after this step? I.e. could you please post an anonymized diff?
(In reply to comment #5)
> Do you have the prefs.js files before and after this step? I.e. could you
> please post an anonymized diff?


I'll take a look (I have two synchronized machines through an external hard disk, and it could be that one of them still have the previous version).
(Reporter)

Updated

9 years ago
Severity: normal → major
(Reporter)

Comment 8

9 years ago
Today I took the time to find a regression window for this. Result:
Last known good: 2009-01-09
Broken since: 2009-01-10
Note that "good" here means that "New > Account" fails the first time after trying to subscribe to a newsgroup and canceling in the following dialog, but afterward the account wizard works again, whereas "broken" means that the account wizard stays broken even if you try "New > Account" again.

Probable causing changeset:
http://hg.mozilla.org/comm-central/rev/b78eb7642489 (bug 538414)

My test case was:
1. create a new profile
2. create a Feed account (or any other, but it's fast to do it this way)
3. subscribe to a newsgroup, but cancel the dialog
4. try to create a different account (check the first screen)
5. cancel the dialog and repeat step 4.

Updated

8 years ago
Duplicate of this bug: 636622

Updated

8 years ago
Blocks: 538414
(Reporter)

Comment 10

8 years ago
Relnoted, see bug 656719 comment 25.
Keywords: relnote
This could be a security issue.

I tried to create a new email account, but could not because it was defaulting to a news account, so I gave up and switched to a standalone copy of Thunderbird to set up the mail. However, I now find that when replying to a Newsgroup item, it has picked up the private email address that I was trying to set up. This has exposed a personal email address that I do not use for newsgroups ( to avoid spam etc).

Since this problem has been known about for nearly three years, it should have been fixed by now.

Comment 12

7 years ago
I'm having this problem with adding news servers, but not through an URL, through the settings in SM 2.8.  I can't add but one news server now, because it's really badly broken now.  Sometimes what I add doesn't show up at all in SM.  Other times it will, but it has changed the original account that I had.  It has given me too many invalid responses to list.  Does no one care that they have rendered a core function of SM unusable?

Updated

6 years ago
Duplicate of this bug: 680003

Comment 14

6 years ago
I've just run into this issue in SM 2.22.1 on OS X 10.7.5. Nasty!

Comment 15

4 years ago
REPRODUCIBLE with  SeaMonkey 2.39a1 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:42.0 from official download area)  Gecko/20100101  Firefox/42.0 (Classic Theme) on German WIN7 64bit

1. Launch SeaMonkey via Profile manager from command line
2. Create blank new profile "Newsgroupstest2" → Launch SeaMonkey →
    confirm default client for all applications → confirm changes requiring 
    WIN admin permissions
3. on <http://www.seamonkey-project.org/dev/get-involved> in left selection pane
   click "Communitiy and support" for <http://www.seamonkey-project.org/community>
4. Click Link Newsgroup: mozilla.support.seamonkey → confirm confirm 'would
   you like to subscribe' with [ok]
   » "Identity" dialog appears instead of account type selection dialog
5. [Cancel] will create account and subscribe "mozilla.support.seamonkey" with 
   invalid identity entries, but postings will be downloaded.

I changed "Version" to ease recognition of appearance

therube asked me to test this one in "Bug 1179680 - Lost ability to add new mail/news accounts". Effects here look similar, but my problem there did not appear in 2009
See Also: → 1179680
Version: Trunk → SeaMonkey 2.0 Branch

Updated

4 years ago
Version: SeaMonkey 2.0 Branch → Trunk

Comment 16

4 years ago
@Hb: May be you can explain your Version modification?
(Reporter)

Comment 17

4 years ago
While I'm not :Hb, here's the reasoning:
* The 2.0 branch is long gone, it has been discontinued years ago. "SeaMonkey 2.0 Branch" is not including all 2.x versions as you might think, but only the 2.0.x ones.
* Version should show the latest affected version. Until this bug gets fixed, all versions are affected, i.e. Trunk is the correct value for the field for the time being. For the same reason, setting any of the status tracking flags is pointless, too, since you might then as well set those for all past and future versions, too.

Updated

4 years ago
Duplicate of this bug: 1179680

Updated

4 years ago
Duplicate of this bug: 1209211

Updated

4 years ago
See Also: → 1209859
(Assignee)

Comment 20

3 years ago
Posted image Clipboard.jpg
I stumbled again over this bug when I tried to add a mail account today. 

I think the problem is the leftover valid setting for the news server. Usually you can see the pref for a short time when you create an account manually. It's the string pref in the lower half of the picture. 

When you cancel the subscription in the way Rainer did it in Comment 15 you end up with a mail.server.serverX.valid boolean pref set to false. This seems to confuse the heck out of the account wizard. The simple solution seems just to delete the pref. The not so simple solution would be to make sure that every mail.server.serverX has such a valid pref regardless of it's setting. This seems to work too.
(Assignee)

Comment 21

3 years ago
Simple patch which just deletes the pref during startup. 

I do not think it's reviewable yet because I am not sure it should be in the migrate js. Was just convenient there because all servers are read here. Any comments where it should be or if this is even the right approach?

Works fine btw. Tested it with a private build.

FRG

Comment 22

3 years ago
(In reply to Frank-Rainer Grahl from comment #20)
> Created attachment 8707885 [details]
> Clipboard.jpg
> 
> I stumbled again over this bug when I tried to add a mail account today. 
> 
> I think the problem is the leftover valid setting for the news server.
> Usually you can see the pref for a short time when you create an account
> manually. It's the string pref in the lower half of the picture. 
> 
> When you cancel the subscription in the way Rainer did it in Comment 15 you
> end up with a mail.server.serverX.valid boolean pref set to false. This
> seems to confuse the heck out of the account wizard. The simple solution
> seems just to delete the pref. The not so simple solution would be to make
> sure that every mail.server.serverX has such a valid pref regardless of it's
> setting. This seems to work too.

Let's ask mkmelin

I think one possible place would be nsMsgAccountManager::LoadAccounts()

http://mxr.mozilla.org/comm-central/source/mailnews/base/src/nsMsgAccountManager.cpp?rev=1cb65d027ed4&mark=1188-1192#1188
Flags: needinfo?(mkmelin+mozilla)
Yeah that looks like a good spot to me.
Flags: needinfo?(mkmelin+mozilla)

Comment 24

3 years ago
(In reply to Magnus Melin from comment #23)
> Yeah that looks like a good spot to me.
Frg: do you want to try moving your patch to?:

http://mxr.mozilla.org/comm-central/source/mailnews/base/src/nsMsgAccountManager.cpp?rev=1cb65d027ed4&mark=1209-1210#1207
Flags: needinfo?(frgrahl)
(Assignee)

Comment 25

3 years ago
Ratty,

sure can do. Not this week but with a bug from 2009 it can eventually wait a little longer :)

But not sure if it fixes all the instances. This one might have been a different one:

http://forums.mozillazine.org/viewtopic.php?f=40&t=2995769

Did anyone else who did run into the problem checked if it's caused by the .valid prefs?
Flags: needinfo?(frgrahl)
(Assignee)

Comment 26

3 years ago
Posted patch 521861-Account_Creation.patch (obsolete) — Splinter Review
Attachment #8753546 - Flags: feedback?(philip.chee)
Attachment #8753546 - Flags: feedback?(mkmelin+mozilla)
(Assignee)

Comment 27

3 years ago
Pressed Enter too fast. I moved the half baked patch to nsMsgAccountManager. 

It works but not sure if I am happy with it so a two questions. 

There seems to be no way to check which mail.server prefs do exists. You can get the accounts list via mail.accountmanager.accounts and the servers via mail.account.accountx.server but if there is a stale server you will not get it. I implemented it by just going over the first 99 server entries which seems to be a bit excessive but sure cleans stuff out. Should this be changed back to go via the accounts?

This is not javascript. Should the pref be checked that it exists before it is to be cleared.

If the valid pref is cleared might this cause problems with invalid server entries?

The root cause why the accounts manager is stuck will not be fixed by this. It's just a workaround so I think the bug should not be closed if the patch is to be accepted.
Comment on attachment 8753546 [details] [diff] [review]
521861-Account_Creation.patch

Review of attachment 8753546 [details] [diff] [review]:
-----------------------------------------------------------------

::: mailnews/base/src/nsMsgAccountManager.cpp
@@ +367,5 @@
>    }
>  }
>  
> +void
> +nsMsgAccountManager::CleanServerValidState()

nsresult is usually used even if we might not care too much about the return value atm.

@@ +376,5 @@
> +  if (NS_FAILED(rv))
> +    return;
> +
> +  nsCOMPtr<nsIPrefBranch> prefServer;
> +  if (prefService)

you already know you have a prefService since rv succeeded. Or if you're paranoid, check it where you check the rv code

@@ +385,5 @@
> +  }
> +
> +  nsAutoCString serverKey;
> +
> +  // Loop over first 99 mail.server.server* entried and delete .valid entries.

maybe mail.account.lastKey + some?
Attachment #8753546 - Flags: feedback?(mkmelin+mozilla) → feedback+

Comment 29

3 years ago
Comment on attachment 8753546 [details] [diff] [review]
521861-Account_Creation.patch

> +  nsresult rv;
> +  nsCOMPtr<nsIPrefService> prefService(do_GetService(NS_PREFSERVICE_CONTRACTID,
> +                                       &rv));
If you want to wrap at 80cols:

nsCOMPtr<nsIPrefService> prefService =
  do_GetService(NS_PREFSERVICE_CONTRACTID, &rv);

> +  if (NS_FAILED(rv))
> +    return;
> +
> +  nsCOMPtr<nsIPrefBranch> prefServer;
nsCOMPtr<nsIPrefBranch> prefBranch;

> +  if (prefService)
You don't need to check for prefService if you have already done NS_FAILED

> +  nsAutoCString serverKey;
> +
> +  // Loop over first 99 mail.server.server* entried and delete .valid entries.
prefBranch->GetChildList(...)

+    serverKey.AppendInt(lastKey);
+    serverKey.AppendLiteral(".valid");
+    // Just delete the 'valid' pref. Don't check if it exists.
+    prefServer->ClearUserPref(serverKey.get());

StringEndsWith(.. ".valid")

Reference: http://mxr.mozilla.org/comm-central/source/mailnews/base/src/nsMsgTagService.cpp?rev=ff603e79f92a#160
Attachment #8753546 - Flags: feedback?(philip.chee) → feedback-
(Assignee)

Updated

2 years ago
Duplicate of this bug: 1322197
(Assignee)

Comment 31

5 months ago
Posted patch 521861-Account_Creation.patch (obsolete) — Splinter Review
Before we celebrate another aniversary :) Workaround patch redone and hopefully all comments addressed. Tested with SeaMonkey 2.53 and compiled with Thunderbird 65.
Attachment #8753546 - Attachment is obsolete: true
Attachment #9027332 - Flags: review?(mkmelin+mozilla)
Comment on attachment 9027332 [details] [diff] [review]
521861-Account_Creation.patch

Review of attachment 9027332 [details] [diff] [review]:
-----------------------------------------------------------------

I guess this is ok. r=mkmelin

::: mailnews/base/src/nsMsgAccountManager.cpp
@@ +376,5 @@
> +}
> +
> +nsresult
> +nsMsgAccountManager::CleanServerValidState()
> +{

Please add documentation here on what it's solves (why it exists)
Attachment #9027332 - Flags: review?(mkmelin+mozilla) → review+
(Assignee)

Comment 33

5 months ago
Posted patch 521861-Account_Creation.patch (obsolete) — Splinter Review
Comment added per review. r+ from mkmelin retained.

Jorg, I wonder if I shouldn't change it one more time and pref it off for compiling with SeaMonkey only. Seems to not add any visible overhead but if it is not also a TB problem might be better to leave it out there.
Assignee: nobody → frgrahl
Attachment #9027332 - Attachment is obsolete: true
Flags: needinfo?(jorgk)
Attachment #9029141 - Flags: review+

Comment 34

5 months ago
Comment on attachment 9029141 [details] [diff] [review]
521861-Account_Creation.patch

Review of attachment 9029141 [details] [diff] [review]:
-----------------------------------------------------------------

Well, I'd like this in TB if it fixes a problem in TB. Are there STR to reproduce this in TB? I don't see any server. ... . valid prefs. If it doesn't apply to TB, please use #ifdef MOZ_SUITE.

::: mailnews/base/src/nsMsgAccountManager.cpp
@@ +369,5 @@
>  }
>  
> +template<size_t N>
> +static bool
> +StartsWith(const std::string& haystack, const char (&needle)[N])

What is this? Why not use regular StringBeginsWith()?

@@ +378,5 @@
> +/*
> + * Sometimes you are unable to add a new mail account to SeaMonkey. The account
> + * manager will only allow adding a news account.
> + * One reason identified are stale mail.server.serverx.valid prefs. Until the
> + * account manager is fully fixed in Bug 521861 remove them during startup.

I don't understand this comment. This *is* bug 521861, so do you intend to land more fixes?

@@ +389,5 @@
> +    do_GetService(NS_PREFSERVICE_CONTRACTID, &rv);
> +  NS_ENSURE_SUCCESS(rv, rv);
> +
> +  nsCOMPtr<nsIPrefBranch> prefBranch;
> +

Lose empty line.

@@ +405,5 @@
> +  for (uint32_t i = count; i--;) {
> +    // Check if it is a server*.valid key and if yes delete it.
> +    nsDependentCString prefName(prefList[i]);
> +    if (StringEndsWith(prefName, NS_LITERAL_CSTRING(".valid")) &&
> +        StartsWith(prefName.get(), "server")) {

Why is this so inconsistent?
One uses .get(), the other one NS_LITERAL_CSTRING(). Please fix, ah, I see, home-grown function.

@@ +1194,5 @@
>    // It is ok to return null accounts like when we create new profile.
>    m_accountsLoaded = true;
>    m_haveShutdown = false;
>  
> +  // Clean up servers. Necessary for later account creation see bug 511861.

We usually don't mention bug numbers in code. It's already mentioned above in the function (although I don't understand that comment).
Attachment #9029141 - Flags: review-

Comment 35

5 months ago
Aceman, is this problem reproducible in TB?
Flags: needinfo?(jorgk)
(Assignee)

Comment 36

4 months ago
This hopefully fixes all the remaining issues. Thanks for pointing out StringBeginsWith(). I actually looked and didn't find it before. Makes for a much cleaner patch.

I didn't find a similar bug report for Thunderbird. Seems to be the account wizard does a better job than the SM account manager so I enclosed it in ifdef suite. Needed in esr60 and also in our next release still based on 52 (sigh).
Attachment #9029141 - Attachment is obsolete: true
Attachment #9032927 - Flags: review?(jorgk)
Attachment #9032927 - Flags: review?(iann_bugzilla)
Attachment #9032927 - Flags: approval-comm-esr60?
Attachment #9032927 - Flags: approval-comm-esr52?

Comment 37

4 months ago
Comment on attachment 9032927 [details] [diff] [review]
521861-Account_Creation.patch

Review of attachment 9032927 [details] [diff] [review]:
-----------------------------------------------------------------

::: mailnews/base/src/nsMsgAccountManager.cpp
@@ +390,5 @@
> +  NS_ENSURE_SUCCESS(rv, rv);
> +
> +  uint32_t count;
> +  char **prefList;
> +  rv = prefBranch->GetChildList("", &count, &prefList);

Does prefList need free'ing?

@@ +394,5 @@
> +  rv = prefBranch->GetChildList("", &count, &prefList);
> +  NS_ENSURE_SUCCESS(rv, rv);
> +
> +  // Traverse the list, and look for .valid prefs.
> +  for (uint32_t i = count; i--;) {

This looks really ugly. And it's wrong as well. The look will stop at i==0, so you don't check that pref. Unlikely it will need processing, but for correctness please use:
for (i = count - 1, i >=0; i--).

Oh, you also cause a crash by starting at count, no?

Unless I'm mistaken, that would be an r- :-(

@@ +397,5 @@
> +  // Traverse the list, and look for .valid prefs.
> +  for (uint32_t i = count; i--;) {
> +    // Check if it is a server*.valid key and if yes delete it.
> +    nsAutoCString prefName;
> +    prefName.Assign(prefList[i]);

Won't that crash for i==count?

@@ +1191,5 @@
>    m_haveShutdown = false;
>  
> +#ifdef MOZ_SUITE
> +  // Clean up servers so that account creation always works.
> +  rv = CleanServerValidState();

Why are assigning to rv if you ignore it?
Attachment #9032927 - Flags: review?(jorgk)

Comment 38

4 months ago
Comment on attachment 9032927 [details] [diff] [review]
521861-Account_Creation.patch

>+ * Sometimes you are unable to add a new mail account to SeaMonkey. The
>+ * account manager will only allow adding a news account.
>+ * One reason identified are stale mail.server.serverx.valid prefs. Until the
Nit: is rather than are
>+ * account manager is fully fixed in Bug 521861 remove these prefs during
>+ * startup.

>+  uint32_t count;
Nit: you could define i here too

>+  // Traverse the list, and look for .valid prefs.
>+  for (uint32_t i = count; i--;) {
Any reason this cannot be done as an incremental loop?
for (i = 0; i < count; ++i)

>+    // Check if it is a server*.valid key and if yes delete it.
>+    nsAutoCString prefName;
Move this outside of the for loop

>+    prefName.Assign(prefList[i]);
>+    if (StringEndsWith(prefName, NS_LITERAL_CSTRING(".valid")) &&
>+        StringBeginsWith(prefName, NS_LITERAL_CSTRING("server"))) {
>+      prefBranch->ClearUserPref(prefName.get());
>+    }
>+  }
>+
NS_FREE_XPCOM_ALLOCATED_POINTER_ARRAY(count, prefList);

>+  return NS_OK;
>+}

> 
>+#ifdef MOZ_SUITE
>+  // Clean up servers so that account creation always works.
>+  rv = CleanServerValidState();
Do we need here:
NS_ENSURE_SUCCESS(rv,rv);

f+ for the moment
Attachment #9032927 - Flags: review?(iann_bugzilla)
Attachment #9032927 - Flags: feedback+
Attachment #9032927 - Flags: approval-comm-esr60?
Attachment #9032927 - Flags: approval-comm-esr52?

Updated

4 months ago
Status: NEW → ASSIGNED

Comment 39

4 months ago
(In reply to Rainer Bielefeld from comment #15)
> <http://www.seamonkey-project.org/community>

The link is:
<news://news.mozilla.org/mozilla.support.seamonkey>

> 4. Click Link Newsgroup: mozilla.support.seamonkey → confirm confirm 'would
>    you like to subscribe' with [ok]

(In reply to Jorg K (GMT+1) (urgent reviews and bustage fix only, Dec 22nd to Jan 1st) from comment #35)
> Aceman, is this problem reproducible in TB?

Only till step 4. Noting else happens after that. (see also: Bug 745856).
In the folderpane no new account is shown, but: In "Account Settings" the new account is there. And after a restart of TB it is shown in the folderpane.

Comment 40

4 months ago
(In reply to Alfred Peters from comment #39)
> Only till step 4. Noting else happens after that. (see also: Bug 745856).
> In the folderpane no new account is shown, but: In "Account Settings" the
> new account is there. And after a restart of TB it is shown in the
> folderpane.
So we should take the patch in general without the #ifdef MOZ_SUITE?

Comment 41

4 months ago
(In reply to Jorg K (GMT+1) (urgent reviews and bustage fix only, Dec 22nd to Jan 1st) from comment #40)
>(In reply to Alfred Peters from comment #39)
>> Only till step 4. Noting else happens after that. (see also: Bug 745856).

> So we should take the patch in general without the #ifdef MOZ_SUITE?

I have no idea what the pref is good for in TB.

If I cancel step 4, I get also the pref with value false.
The pref has no obvious consequences in TB. She seams just to stay forever. ;-)

So yes, it makes sense to delete the pref also in TB.
(Assignee)

Comment 42

4 months ago
Just let me know the verdict and I will remove the ifdefs. When I find some time I will look over the review comments and put up a new patch. Hopefully the last one needed :)

Comment 43

4 months ago
Sigh, I meant to NI Aceman in comment #35 but didn't :-( - Since he's not CC'ed he won't answer.

Aceman, given comment #39 and comment #41, should we take this in TB?

Which preference are we talking about exactly? Something mail.server.serverNN.valid? I wanted to try it, but I don't even understand the STR (quoting):

===
My test case was:
1. create a new profile
2. create a Feed account (or any other, but it's fast to do it this way)
3. subscribe to a newsgroup, but cancel the dialog
4. try to create a different account (check the first screen)
5. cancel the dialog and repeat step 4.
===

Well, after you added an empty Feed account, you can subscribe to *feeds*, not newsgroups. So is there a step missing where you also create an "Other Account", which is a news account and then try to add the news server, and then cancel? Which panel do cancel exactly? Or do you add the news account and cancel the subscribe panel?

All I tried, I haven't seen any  mail.server.serverNN.valid preference, there are only mail.identity.idNN.valid.

Comment 44

4 months ago
(In reply to Jorg K (GMT+1) (urgent reviews and bustage fix only, Dec 22nd to Jan 1st) from comment #43)
 
> Which preference are we talking about exactly? Something
> mail.server.serverNN.valid?

correct.

>  I wanted to try it, but I don't even understand
> the STR (quoting):
> 
> ===
> My test case was:
> 1. create a new profile
> 2. create a Feed account (or any other, but it's fast to do it this way)

You need to click to:
<news://news.mozilla.org/mozilla.support.seamonkey>
I wrote me a mail with that link and subscribed to that account first.

> 3. subscribe to a newsgroup, but cancel the dialog

No. The account will be created automatically after you click that link.
Then a Dialog asks you, if you want to subscribe to "mozilla.support.seamonkey".
That is "step 4"

If you click OK, you'll get the group after you restart TB.
If you click CANCEL, you'll get only the empty new account with the "mail.server.serverNN.valid" pref.

Comment 45

4 months ago
- I wrote me a mail with that link and subscribed to that account first.

+ I wrote me a mail with that link and subscribed to the mail account (containing these mail) first.

Comment 46

4 months ago
Thanks Alfred, I could reproduce it now easily. I exported that bugmail to the new profile and after clicking and cancelling I get the "mail.server.serverNN.valid" pref. Thanks for your help and all your work in 2018, I hope the excellent cooperation will continue in 2019.

So now the question goes back to Aceman. Do we care about this preference. Again the clarified STR:
1. create a new profile
2. create a Feed account (or any other, but it's fast to do it this way)
3. Create draft or import e-mail with <news://news.mozilla.org/mozilla.support.seamonkey> in the body.
4. Click that link, on the dialogue that asks you to subscribe, click cancel.

mail.server.server3.valid pref is set to false. 1 and 2 are the feed and local folder accounts. The news account is in fact created, even if you cancel, and that pref hangs around without negative side effects as far as I can see.
 The news account is in fact created, even if you
> cancel, and that pref hangs around without negative side effects as far as I
> can see.

As I mentioned in Comment #11 ( some 7 years ago), one side effect that I found at the time was that one of my real email addresses  was picked up in replies to the Newsgroup postings. I have a specific address (fake) used for Newsgroup postings to reduce spam. It appeared that the accounts database had somehow corrupted. I never got to the bottom of why this happened, and I do not know whether subsequent changes would have altered this undesirable side effect. You may want to try creating an email and a NG posting to see if the appropriate addresses are shown.

Updated

4 months ago
Flags: needinfo?(acelists)
You need to log in before you can comment on or make changes to this bug.