706451 - Extend X-Account-Key: information in mbox files

Status: RESOLVED DUPLICATE of bug 394216

(Thunderbird :: Migration, defect)

Description

[Ulf Zibis]

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

Steps to reproduce:

Imported mbox files/Mail folder from old/different profiles.



Actual results:

Wrong identities on "Reply"


Expected results:

TB should provide some intelligence (at least some info in the behind), to detect such inconsistencies. Suggestion:
Extend X-Account-Key with it's id list, default first, like:
X-Account-Key: accountX a@b.c,d@e.f,g@h.i

Comment 1

[Ulf Zibis]

(In reply to Ulf.Zibis from comment #0)
> Extend X-Account-Key with it's id list, default first, like:
> X-Account-Key: accountX a@b.c,d@e.f,g@h.i
Thinking again, I think, only the id + actual email(default or alias), to where a message was send, should be used:
X-Account-Key: accountX default@b.c
X-Account-Key: accountX alias@b.c

If the email in 'To:' field(s) is not a valid id of the target account, try to interpret other fields like CC:, BCC:, Return-Path:, Delivered-To:.
On no success use the email from default id of the target accountX.

Comment 2

[Ulf Zibis]

See also: bug 707165 comment #5, last paragraph.

Comment 3

[Wayne Mery (:wsmwk)]

rkent, would this be reasonable?

Comment 4

[Kent James (:rkent)]

The account key introduces of level of abstraction between email address and account information, so that the information on the account (such as email address) can be changed without causing the connection between the account and the email to be lost.

Unfortunately, as the OP points out, this causes issues in account migration and reuse of existing mail stores in new profiles, where the account key may have changed meaning.

The question that I would have concerning the approach proposed in this bug is, how do you distinguish between a valid and invalid account key? So if I find a message with account key "account2" and there exists an "account2" in the profile, but the values of the emails in the identities from the extended X-ACCOUNT-KEY differ from that of the account in the current profile, how do I distinguish between a migrated profile (where I should trust the identities in the extended X-ACCOUNT-KEY) versus a change in email address in an existing identity (where I should trust whatever is in "account2" in the current profile?

Comment 5

[Ulf Zibis]

(In reply to Kent James (:rkent) from comment #4)
> The question that I would have concerning the approach proposed in this bug
> is, how do you distinguish between a valid and invalid account key? So if I
> find a message with account key "account2" and there exists an "account2" in
> the profile, but the values of the emails in the identities from the
> extended X-ACCOUNT-KEY differ from that of the account in the current
> profile, how do I distinguish between a migrated profile (where I should
> trust the identities in the extended X-ACCOUNT-KEY) versus a change in email
> address in an existing identity (where I should trust whatever is in
> "account2" in the current profile?

Maybe you could remember known folders in the profile somewhere, e.g. panacea.dat. If a new folder is detected, TB will know, that this folder must have been added by external migration. 
Solution 1:
In that case, if there are not matching accountx - email pairs, a dialogue should automatically pop up to ask the user for the correct assignment, e.g.: "This email seens from another account, choose a correct assignment." + checkbox: "Correct for all emails in this folder?"
Solution 2:
Upon "Reply" ask user for the correct assignment.

Anyway, if email of accountx was changed, the old email from extended X-ACCOUNT-KEY is likely no more existing, so using it would cause an error after "Send".

Comment 6

[:aceman]

Please see if bug 394216 has solved any of the problems of choosing wrong identity when replying to old messages.

Comment 7

[Wayne Mery (:wsmwk)]

This blocks bugs which are privacy related, so setting sev=major

(In reply to :aceman from comment #6)

Please see if bug 394216 has solved any of the problems of choosing wrong identity when replying to old messages.

Ulf?

Also info in bug 707165 comment 7

Comment 8

[Ulf Zibis]

(In reply to :aceman from comment #6)

Please see if bug 394216 has solved any of the problems of choosing wrong identity when replying to old messages.

Unfortunately I currently don't have old messages to test with. And as it is so long time ago, I have problems to follow all the details.
When I have old messages again, I will check that out.

Comment 9

[Wayne Mery (:wsmwk)]

Aceman if you believe in comment 6 we can close this?

Comment 10

[:aceman]

I believe that we implemented some logic to find the proper identity on reply, in the other bug.
We need further info if not all cases were covered.
Until then, yes, let's try to close this.