376001 - RFE Mail / ImapMail account folders named based on the server vs the account

Status: UNCONFIRMED

(Thunderbird :: Account Manager, enhancement)

Description

[Michael Lueck]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Build Identifier: version 2.0.0.0 (20070326)

Thunderbird seems to by default name the directory structure under the Mail or ImapMail folder based on the server it is connecting to for that account verses the email address the directory is for.

Hosting providers can be changed, servers can be used for more than one account, etc...

I propose that the standard be changed to directories one level under Mail or ImapMail be changed from the hostname to the email address, in the format [e-mail]

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[idgreenwald]

I agree that current naming of mail folders is inappropriate.  However, I suggest that naming the folders with the account name is more natural than using the email address. Thus account "Home" has mail folder "Home" and account "Work" has mail folder "Work". 

In addition, my suggested naming convention makes for easier switching when one's ISP (e.g., Adelphia) is taken over by a competitor (e.g., Time Warner). The account and folder names remain the same and only the server names need be changed.

Comment 2

[Michael Lueck]

So maybe just accept a string for the directory name, allowing it to be the actual email address, or some string like "Home" or "Work".

I suggest defaulting to the full email address, and allow the user to specify an alternate to that default in the "new account wizard".

Comment 3

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #0)
> Thunderbird seems to by default name the directory structure under the Mail or
> ImapMail folder based on the server it is connecting to for that account verses
> the email address the directory is for.

Rough current logic is as follows.
1. Tb saves string in server / username field on account definition in
   - mail.server.serverN.hostname (say xxx.yyy.zzz)
   - mail.server.serverN.userName (say p@q.r)
   And Tb creates directory named xxx.yyy.zzz, and uses xxx.yyy.zzz & p@q.r for
   internal mail folder path representation.
   These two values can not be changed once account is defined.
   Internal mail folder path is seen in msgFilterRules.dat file.
2. When user changed(touched) server name or user name via UI, it is saved in
   - mail.server.serverN.realhostname
   - mail.server.serverN.realuserName
3. On server connection;
   If serverN.realhostname exists, it is used. Else, serverN.hostname is used.
   If serverN.realuserName exists, it is used. Else, serverN.userName is used.
   (Sorry but I don't know why "n" when host but "N" when user)

So, next can be a workaround of directory name issue.
  Specify dummy server name and user name on account definition and save it.
  Then change server name / user name to proper one via UI.
Although dummy server name is restricted to Work.at.NY format and a@b.c.d format can not be used, user can use better directory name than real server name.

I hope that isolation of server name & directory name, isolation of mail folder name & mail folder file name, etc. will be implemented.

Comment 4

[Michael Lueck]

(In reply to comment #3)
> Although dummy server name is restricted to Work.at.NY format and a@b.c.d
> format can not be used, user can use better directory name than real server
> name.

a@b.c.d format worked for us if we changed it via the UI.

What sort of issues do you foresee using that format?

We even successfully restored the TB profile created with the Win32 build onto a system with the Linux build of TB and it did not miss a beat!

Comment 5

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #4)
> a@b.c.d format worked for us if we changed it via the UI.
> What sort of issues do you foresee using that format?

Does your "worked" mean "successful connection to server a@b.c.d"?  

Tb trunk said "Please enter a valid host name" when I entered p@q.r in "Incoming server"(both POP3 and IMAP) field of "Account Wizard". As far as I rember, this was true even when Mozilla M17. This is the reason why I said "restricted to xxx.yyy.zzz format".
But, as you say, change of server name to p@q.r via Account Settings/Server Setting was not rejected. It seems to be no format check(or looser check), because taken action is "save it in serverN.realhostname" only.
This is different and minor problem. Simply, if incorrect server name is specified by user and saved in serverN.realhostname, connection request fails.

Please note that above problem has no relation to workaround of directory name issue of this bug, because sever name change via Account Settings/Server Setting has no relation to directory name.

Comment 6

[Michael Lueck]

(In reply to comment #5)
> Does your "worked" mean "successful connection to server a@b.c.d"?  

While selected on a POP email account:
Go to Tools > Account Settings > Server Settings > Local Directory

THAT is what I am talking about in this RFE.

Yes, I can successfully use a@b.c.d for the directory name, instead of server.isp.com as it defaults to.

Comment 7

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #6)
> While selected on a POP email account:
> Go to Tools > Account Settings > Server Settings > Local Directory
> THAT is what I am talking about in this RFE.

As you say, it is another workaround for directory name (only) issue.
But it changes following entries only.
> user_pref("mail.server.serverN.directory", ... )
> user_pref("mail.server.serverN.directory-rel", ... )
> user_pref("mail.server.server410.spamActionTargetAccount", 
It can not change internal path representation such as next.
> user_pref("mail.server.serverN.spamActionTargetFolder", "mailbox://<initial_username>@<initial_servername>/Junk");
This kind of mismatch sometimes causes user's confusion.
It is the reason why I recommend "dummy server name" on account definition only  as workaround of this bug.

Other reasons why I didn't refer to "Local Directory" setting change as workaround of this bug.
(1) Bug 2654 – localPath(change of Server Settings/Local directory)
               does not take effect until restart
    Many DUP bugs were opened.
(2) Local Directry change requires manual copy(or move) of mail directory.
    And at least one people reported loss of mail data, because he changed
    Local Directry setting and deleted directory at old locations
    without manual copy(or move).
    Enhancement of "automatic copy/move when Local Directory setting change"
    is already request by other bug.

Comment 8

[Michael Lueck]

(In reply to comment #7)
> (1) Bug 2654 – localPath(change of Server Settings/Local directory)
>                does not take effect until restart

ROTFLOL!!! You bet it takes a restart to do that! ;-) I have... 15 email accounts at present!

Compound that with needing to run a Perl script to migrate email from PMMail to Thunderbird. The Perl script was written to move all PMMail accounts to one Thunderbird account, yuck! So, more steps. Alas, PMMail was not the hot chicken it once was... Served me well for 11 years, so no complaints.

> (2) Local Directry change requires manual copy(or move) of mail directory.
> ...
>     Enhancement of "automatic copy/move when Local Directory setting change"
>     is already request by other bug.
 
Sounds indeed better.

Hey, I am happy with Thunderbird. And it is cross platform as well! Maybe (soon) I will be able to use Ubuntu as my main OS, an legacy apps via Parallels and a copy of Win2K. All-in-all Thunderbird is a great system... I am just looking to make it even better.

Comment 9

[WADA:World Anti-bad-Duping Agency]

(Note on my comment #3)
> So, next can be a workaround of directory name issue.
>   Specify dummy server name and user name on account definition and save it.
>   Then change server name / user name to proper one via UI.

If same "dummy server name(hostname) & dummy user name(userName)" is used in additional account definition, Bug 303542 occurs, because flaw exists in duplicate check with hostname+userName and duplicate check with realhostname/realuserName.
Please be careful when you specify dummy server name/dummy user name as an workaround of this bug.