707165 - Wrong/misleading/useless info in column 'Account'

Status: NEW

(Thunderbird :: Folder and Message Lists, defect)

Description

[Ulf Zibis]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Build ID: 20110928134238

Steps to reproduce:

Preconditions:
account1.server1.name a@a.a
account2.server2.name b@b.b
account3.server3.name Local Folder
Inbox of a@a.a:
message1: X-Account-Key: account1
message2: X-Account-Key: account2
message3: X-Account-Key: account3
message4: X-Account-Key: account4
message5: <no X-Account-Key:>

In the list of messages:
- set focus on Inbox of a@a.a
- enable 'Account' column





Actual results:

Column 'Account' in the list of messages:
message1: a@a.a
message2: b@b.b
message3: a@a.a
message4: a@a.a
message5: a@a.a

IMO, displaying 'a@a.a' is wrong, or at least misleading/useless


Expected results:

Column 'Account' in the list of messages:
message1: a@a.a
message2: b@b.b
message3: <invalid (3)>
message4: <unknown (4)>
message5: <none>

Comment 1

[Thomas D. (:thomas8)]

Hmm. I don't understand. If all the messages, albeit originating from different accounts, are now located in account a@a.a's inbox, then all of them should have X-account-key: account1, or not? Anything else would cause confusion of known bugs where we use the wrong identity when replying to messages located in one account!

If my understanding is right, then this would be invalid.

Comment 2

[Ulf Zibis]

OK, I understand, I should have explained more detailed.
Imagine, the Inbox a@a.a is in use since 10 years, where no X-account-key was used, so there are some old messages without it.
Later messages got the X-Account-Key: account4, as a@a.a was the 4th account.
Some time later, TB was installed new on another machine, where a@a.a is account3, and the existing Inbox was reused, so then received messages got X-Account-Key: account3.
Then later another change for a@a.a to account2 and account1 ...

A similar scenario could be observed, if those messages have been moved to a local folder.

Such kind of scenarios really happened to me, so today I'm facing bug 704613.
Having account column behaving like 'expected', would ease to 'repair' my mbox files manually, see: https://bugzilla.mozilla.org/show_bug.cgi?id=704613#c10 bug 704613#c10

Comment 3

[WADA:World Anti-bad-Duping Agency]

(In reply to Ulf.Zibis from comment #0)
> Steps to reproduce:
> Preconditions:
> account1.server1.name a@a.a
> account2.server2.name b@b.b
> account3.server3.name Local Folder
> Inbox of a@a.a:
> message1: X-Account-Key: account1
> message2: X-Account-Key: account2
> message3: X-Account-Key: account3
> message4: X-Account-Key: account4
> message5: <no X-Account-Key:>
> 
> Actual results:
> Column 'Account' in the list of messages:
> message1: a@a.a
> message2: b@b.b
> message3: a@a.a
> message4: a@a.a
> message5: a@a.a

Unable to reproduce next combination.
> account3.server3.name Local Folder
> message3: X-Account-Key: account3
> message3: a@a.a

Tb 8 on Win-XP showed next in Account column.

account1/server1 to account8 is defined. No Global Inbox is used.
  account1/server1 : POP3, not default account
  account2/server2 : POP3, default account
  account3/server3 : Unified Folders
  accountP/serverP : POP3, not default account
  accountS/serverS : IMAP account
  accountL/serverL : Local Folders  
Checked at POP3 accountP/serverP(not server1, not default account, not Local Folders, not Unified Folders), Local Folders, and IMAP account.

                            accountP         accountL         accountS
                            serverP          serverL          serverS
 X-Account-Key: of mail     POP3 folder      Local Folders    IMAP folder 
 
 mail-X : accountN          accountN         accountN         serverS.name of    
   (accountN is defined)    -> serverN.name  -> serverN.name  this IMAP account
   (non Local Folders  )

 mail-Y : accountL          accountL         accountL         serverS.name of    
   (accountL is defined)    -> serverL.name  -> serverL.name  this IMAP account
   (as Local Folders   )    ==Local Folders  ==Local Folders   

 mail-Z : accountC          serverP.name of  serverL.name of  serverS.name of    
   (accountC is        )    this account     this account     this IMAP account
   (  not defined      )                     ==Local Folders   

 mail-W : no X-Account-Key  server1.name of  server1.name of  serverS.name of    
                            account1         account1         this account
     
Note:
Even if existent accountN is hidden account for Unified Folders(smart mail boxes), corresponding serverN.name is used and "Unified Folders" is shown.

> Expected results:
> Column 'Account' in the list of messages:
> message3: <invalid (3)>
Why showning "Local Folders" is wrong even though account3 is defined as "Local Folders"?
I agree with you on account number of "Unified Folders" case.

Current account column for local mail folder is for Global Inbox, and shown account is account used for identity selection upon reply when Global Inbox. And if associated identity is not defined for chosen account(Local Folders, Unified Folders), main identity of default account is selected.
So, I don't think "Useless" or "Misleading" except next cases.
(a) "Unified Folders" is shown.
(b) account1 or accountX for server1 is always used when no X-Account-Key: header.
I wasn't aware of this (b) until I execute above check. (b) is possibly one of big causes of phenomenon of "preselected reply address is far from user's expectation".

Comment 4

[Ulf Zibis]

(In reply to WADA from comment #3)
Wow, you did much work!

> Unable to reproduce next combination.
> > account3.server3.name Local Folder
> > message3: X-Account-Key: account3
> > message3: a@a.a
Actually I did my test on a local folder, so I assumed
    message3: a@a.a
because on local folder it was
    message3: Local Folders
Sorry for my error.

> Tb 8 on Win-XP showed next in Account column.
> 
> account1/server1 to account8 is defined. No Global Inbox is used.
>   account1/server1 : POP3, not default account
>   account2/server2 : POP3, default account
>   account3/server3 : Unified Folders
>   accountP/serverP : POP3, not default account
>   accountS/serverS : IMAP account
>   accountL/serverL : Local Folders  
> Checked at POP3 accountP/serverP(not server1, not default account, not Local
> Folders, not Unified Folders), Local Folders, and IMAP account.
> 
>                             accountP         accountL         accountS
>                             serverP          serverL          serverS
>  X-Account-Key: of mail     POP3 folder      Local Folders    IMAP folder 
>  
>  mail-X : accountN          accountN         accountN         serverS.name
> of    
>    (accountN is defined)    -> serverN.name  -> serverN.name  this IMAP
> account
>    (non Local Folders  )
Expected(IMO):                serverN.name     serverN.name     serverN.name

>  mail-Y : accountL          accountL         accountL         serverS.name
> of    
>    (accountL is defined)    -> serverL.name  -> serverL.name  this IMAP
> account
>    (as Local Folders   )    ==Local Folders  ==Local Folders   
Expected(IMO):                Local F(invalid) Local F(invalid) Local F(invalid)
Alternative:                  serverL.name     serverL.name     serverL.name

>  mail-Z : accountC          serverP.name of  serverL.name of  serverS.name
> of    
>    (accountC is        )    this account     this account     this IMAP
> account
>    (  not defined      )                     ==Local Folders   
Expected(IMO):                <unknown (C)>    <unknown (C)>    <unknown (C)>    
Alternative:                  <invalid (C)>    <invalid (C)>    <invalid (C)>    

>  mail-W : no X-Account-Key  server1.name of  server1.name of  serverS.name
> of    
Expected(IMO):                <none>           <none>           <none>
Alternative:                  <unknown>        <unknown>        <unknown>    

> > Expected results:
> > Column 'Account' in the list of messages:
> > message3: <invalid (3)>
> Why showning "Local Folders" is wrong even though account3 is defined as
> "Local Folders"?
As local folder can not be an account to where a message was received from the server, it is invalid as input account.
But yes, it may be more descriptive to show "Local Folders (invalid)" or "<invalid (Local Folders)>"

> Current account column for local mail folder is for Global Inbox, and shown
> account is account used for identity selection upon reply when Global Inbox.
> And if associated identity is not defined for chosen account(Local Folders,
> Unified Folders), main identity of default account is selected.
> So, I don't think "Useless" or "Misleading" except next cases.
> (a) "Unified Folders" is shown.
> (b) account1 or accountX for server1 is always used when no X-Account-Key:
> header.
Agreed.

> I wasn't aware of this (b) until I execute above check. (b) is possibly one
> of big causes of phenomenon of "preselected reply address is far from user's
> expectation".
Because of all this problems I've opened bug 706451.

Additionally, if a message is copied/moved from an IMAP (or very old untagged POP3) account to any local/POP3/IMAP folder, I think, "X-Account-Key: accountS" should be added to the message's header.

Comment 5

[WADA:World Anti-bad-Duping Agency]

(In reply to Ulf.Zibis from comment #4)
> Additionally, if a message is copied/moved from an IMAP (or very old
> untagged POP3) account to any local/POP3/IMAP folder, I think,
> "X-Account-Key: accountS" should be added to the message's header.

If you think X-Account-Key: and X-UIDL: is better kept upon copy of mail from POP3 mail folder to IMAP folder, add comment to bug 426651, which is request of removal of such headers upon copy to IMAP folder, please.
I imagined use case of "upload of mail to IMAP for account transfer".
But for use case like "IMAP folder as central mail data repository for other account's mail data"(for example, utilizing of large free disk space of Gmail, Global Inbox like use of Gmail IMAP folder), they are better kept.

However, to be torelant with "different account number on different Tb" and "account number change by delete/re-define of same POP3 account in single Tb", X-Account-Key: need to be enhanced or changed; change to X-Account-Key: accountN abc@x.y.z(main identity's mail address of accountN) like one is needed for required setting of preset From: upon reply, if X-Account-Key: based identity selection upon reply will be used continuously for other than Global Inbox.
I think these kind of issue needs to be cared in your bug 706451.

Comment 6

[Wayne Mery (:wsmwk)]

so dup of, or dependent on bug 706451?

Comment 7

[:aceman]

I thought "Account" column shows in which account the message is currently stored and has nothing to do with the raw X-Account-Key header value. And this info would be used when using Unified folders so that you can see from which account any particular message was aggregated. But if "message2" shows "b@b.b" while still residing in Inbox of Account "a@a.a", then it may show something different.

The code for the value of that column seems to be here:
https://searchfox.org/comm-central/source/mailnews/base/src/nsMsgDBView.cpp#448
So really, it first finds the account by the account key found in the message, and only if there is none found it checks in which folder the message is in and queries its contain server (account).

So that looks weird.

Ulf is correct that the X-Account-Key may be outdated and e.g. account3 in an old message copied across a few TB profiles, may have nothing to do with the account3 that may by chance also exist in the current message.
I'm not sure for how critical operations the X-Account-Key header is useful, but I'd think it should only be used for short-lived hints about the originating account in the local profile, not for inferring anything from 10 years old messages.
We've seen in bug 394216 that even "short-lived" is a myth as the same message can be shared from multiple profiles even before it is finalized from its draft form.

My suggestion would be to always show the account containing the message and just ignore the account key in the message.

Comment 8

[Richard Marti (:Paenglab)]

Only checking the account containing the message is what I expected.

Comment 9

[Ulf Zibis]

I too share the suggestion of aceman.