131176 - realhostname and realuserName is updated instead of hostname and userName

Status: NEW

(SeaMonkey :: MailNews: Account Configuration, defect)

Description

[Jonas Jørgensen]

Build 2002031103, Win2k.

Some really weird shit is going on here. When I update the mail server and/or
mail user name, Account Manager updates mail.server.serverX.realhostname and
.realuserName in prefs.js instead of mail.server.serverX.hostname and .userName.

I just discovered that my mail account seems to be corrupted (it refuses to save
copies of outgoing mails in Sent -- probably a known bug or something). No
problem, I thought, I'll just delete the account and recreate it. On second
thought, no, I don't want to lose the email that I have in that account. Okay,
I'll just turn off the automatic message checking for that account and create a
new account which I can start using instead, then.

So I tried to do so. But I was told that there was already another account with
the same server and user name. Okay then, back to the other account and change
the user name to something random, and then try again. But no, I wasn't allowed
to do so, as the userName pref still contained my real user name.

If the seperate hostname/userName and realhostname/realuserName prefs are needed
for some reason, at least make it so that they don't result in corrupting your
mail account information.

I'm setting severity to critical as this could prevent users from being able to
check their mail.

Comment 1

[Jonas Jørgensen]

Two corrections:

1) "But no, I wasn't allowed to do so, as the userName pref still contained my
real user name" should have been "But no, I still wasn't allowed to create the
new account, as the [...etc.]".

2) "I just discovered that my mail account seems to be corrupted" and "so that
they don't result in corrupting your mail account information" -- I just have
specified more clearly that these two "corruptions" is not related.

Comment 2

[Cavin Song]

If you change the server and user names the new values will be stored in
realhostname and realuserName prefs. This is by design and see bug 14295 for
more info. realhostname and realuserName are used in making connection to the
(new) server, and hostname and userName are used for internal url, directory
purpose.

> But no, I wasn't allowed to do so, as the userName pref still contained my real 
> user name.
>
Can you be more specific on this? For example, do you get an error dialog and if
so can you spell it out? What are the old and new username did you try to
change? etc. More info will help us to resolve the problem quickly. Thanks.

Comment 3

[Jonas Jørgensen]

Sorry for being such a terrible bug reporter -- that happens some times. :-)

Okay, so here's some steps to reproduce: First, I create a blank profile. Then 
I add this mail account:

Host name: first.server
User name: username-for-first-server

The relevant lines which are added to prefs.js are these:

user_pref("mail.server.server1.hostname", "first.server");
user_pref("mail.server.server1.userName", "username-for-first-server");

Now I go to account settings and change the host name to second.server and the 
username to username-for-second-server. The relevant lines in prefs.js now look 
like this:

user_pref("mail.server.server1.hostname", "first.server");
user_pref("mail.server.server1.realhostname", "second.server");
user_pref("mail.server.server1.realuserName", "username-for-second-server");
user_pref("mail.server.server1.userName", "username-for-first-server");

Then I go to account settings again and add a new account, with server 
first.server and username username-for-first-server. Naturally, I assume that 
this server/username combination is not used anywhere anymore, since I just 
changed the server and username for the first account.

It now tells me that the account has been added, but it doesn't show up in the 
account list! Not in the server pane, not in account manager -- not anywhere! 
But my prefs.js now contain some more lines:

user_pref("mail.server.server3.hostname", "first.server");
user_pref("mail.server.server3.userName", "username-for-first-server");

If I then try to add that account again, I get the following error message:

"A mail or newsgroup account with the same user name and server name already 
exists. Click Back and enter a different server name, or click Cancel"

But that is, of course, the correct behavior, as the account already exists. 
The problem here is that the account isn't displayed.

My opinion is that the current design is just broken. I certanly do *not* want 
any information about the old server/username stored in prefs.js if I change it 
to something new, even if it is only used internally. In some scenarios, that 
might actually be a severe privacy issue. Imagine if the CIA used Mozilla as 
their mail client on a computer in some top-secret place, and that place gets 
some new computers and all the old computers are moved to another department. 
There, they don't bother to delete the mail account, they just change the 
server name and user name. And now the people in that other, publically 
accessible department will be able to see the name of CIA's internal top-secret 
mail server.

Okay, I know that the CIA would completely wipe all disks a million times 
before allowing ANY computer department to leave their top-secret labs, but you 
get the idea. In addition, this can be very confusing if you're going through 
prefs.js or even just looking at the Local Directory field in account manager 
and suddenly notice that an old server/username which you haven't used for 
years is suddenly still mentioned somewhere.

For internal urls, why not just generate random garbage data or just use names 
like "server1", "server2", etc? That would be a much better solution IMO. A 
general principle that I try to follow when I'm programming is that I never 
ever use a username or something like that as a file name/directory 
name/whatever if I'm not renaming that file/dir/whatever if the user changes 
the user name. I find Moz's current behavior Bad. Changing it to use strings 
not related to the server name/username for internal strings will probably also 
fix this bug, BTW.

I'm really sorry for saying this, as I now how fscking annoying it is to hear 
stupid users say that they think that this or that bug should be fixed ASAP, 
but I think that this bug should be fixed ASAP. :-)

Comment 4

[Cavin Song]

OK, I see the problem. This used to work I think. Will investigate.

Comment 5

[Cavin Song]

Nominating nsbeta1.

Comment 6

[Cavin Song]

Seth, the backend seems to be doing the right thing (ie, it returns "Account Not 
Found" when you add back the account that was previously changed/modified) so I 
wonder if this is caused by the old account info still exists in RDF. In other 
words, the problem is that the backend says that it's ok to create the account 
but the front-end does not display the new account in the account list.

Comment 7

[Cavin Song]

Forgot to cc Seth.

Comment 8

[Michael Buckland]

Discussed at Mail News bug meeting with Engineering, QA Mktng and PjM.  Decided
to minus this bug.

Comment 9

[Jonas Jørgensen]

For the record: This bug makes it impossible to change the incoming server name
and username of a POP account without FUBARing your mail account information and
most likely losing your old mails unless you know how to edit prefs.js by hand.

Comment 10

[Jonas Jørgensen]

Renominating for nsbeta1; please see comment 9.

Comment 11

[Michael Buckland]

Discussed in Mail News bug meeting.  Decided to minus this bug.

Comment 12

[(not reading, please use [e-mail] instead)]

mass re-assign.

Comment 13

[Ferdinand]

*** Bug 213598 has been marked as a duplicate of this bug. ***

Comment 14

[Daed Lee]

Jonas Jørgensen's <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=131176#c3">comment</a> sums up the issue pretty well. I can confirm this bug on Mac OS X. <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=274027">Bug 274027</a> seems related to this.

Comment 15

[WADA:World Anti-bad-Duping Agency]

Tb version of Comment #3 is Bug 303542.

Comment 16

[WADA:World Anti-bad-Duping Agency]

For next bug summary.
> realhostname and realuserName is updated instead of hostname and userName

If your claim is hostname and userName should be updated instead of realhostname and realuserName, this bug is INVALID, because it's design and "updating of realhostname and realuserName" it self is working as designed.
If your comment #3 is real problem, I think DUPIng this bug to Bug 303542 is better after changing Bug 303542 to mailNews Core bug, because Bug 303542 has better bug  summary.

Comment 17

[WADA:World Anti-bad-Duping Agency]

Following is copy of mail from bug opener to me on 6, Mar, 2009.
> > Tb version of Comment #3 is Bug 303542.
> That would be the tb version of the whole bug then, not only of comment 3... 
> comment 3 was just my attempt to clarify what I meant in the original description,
> which wasn't very good... :-)

Comment 18

[:aceman]

Can this be resolved in any way?
This looks to be OK by design. Maybe there are more concrete bug filed about how to mitigate the user confusion.