Closed Bug 404393 Opened 15 years ago Closed 14 years ago

replying from local folder does not use default account if recipient of original is not a defined account

Categories

(Thunderbird :: Message Compose Window, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 464808

People

(Reporter: wsmwk, Unassigned)

Details

(Keywords: dogfood, regression)

Attachments

(1 file)

trunk ~20071103
"From:" should be default account

TB 2.0.0.7pre works fine with same profile
> last defined account, not default account

(Q1) Did you invoke mail compose window via "mailto:" HTML link?
(Q2) If yes, when Tb was already started? Or when Tb was not started?
(Q3) "last defined account" is "normal account(not 'Local Folders') of largest number", isn't it?
(Q4) When "last defined account" was used in compose for "Local Folders", was "default account" you previously set displayed at top of folder pane?
("Default account" was already reset to "last defined account", wasn't it?)

My account settings for Tb latest-trunk is as follows, and change of "Default Account" to account1-4(and account810001 also) works well.
But when mail compose window(of Tb trunk) was invoked by Firefox(both Fx 2.0.0.6 and trunk 2007/11/17 build), pre-selected From: became always mail address for id810001(probably identity for account of largest account number) even when default account of account1-4, and default account was always reset to account810001, account of the largest number.

(1) Make Tb trunk(2007/11/18 build) as Default Mailer on MS Win-XP
(2) Change default account to one of account1-4, and terminate Tb
(3) Restart Tb sometimes, and confirm that default is never be account810001
(4) Terminate Tb
(5) Click mailto: link in HTML by Firefox
(6) Profile manager is invoked(multiple prof exist). Choose a profile.
(7) Pre-selected From: is mail address for id810001
(8) Cancel compose
    => mail.accountmanager.defaultaccount=account810001 is set in prefs.js
(9) Restart Tb => Default account is changed to account 810001
Note-1: This reset of "default account" doesn't occur, if Tb is already started when click of mailto:
Note-2: This reset "default account" is not observed with Tb 2.0.0.6.

>prefs.js when account3 is default account
>Following changes are made by me, for ease of account definition check
>(1) "Local Folders" is changed to account999999/server999999
>(2) Largest number of normal account is 810001
>(3) Same N is set for accountN/idN/serverN for an account
>(4) Order of accounts is modified manually
>
> user_pref("mail.account.account1.identities", "id1");
> user_pref("mail.account.account1.server", "server1");
> user_pref("mail.account.account2.identities", "id2");
> user_pref("mail.account.account2.server", "server2");
> user_pref("mail.account.account3.identities", "id3");
> user_pref("mail.account.account3.server", "server3");
> user_pref("mail.account.account4.identities", "id4");
> user_pref("mail.account.account4.server", "server4");
> user_pref("mail.account.account810001.identities", "id810001");
> user_pref("mail.account.account810001.server", "server810001");
> user_pref("mail.account.account999999.server", "server999999"); <== Local Folders, no account.999999.identities
> user_pref("mail.accountmanager.accounts", "account999999,account810001,account1,account2,account3,account4");
> user_pref("mail.accountmanager.defaultaccount", "account3");
restating the problem, since I got it terribly wrong.

Regression of trunk between 2007-07-30 04:00 and 2007-07-31 10:00 - regression of bug 128996?

Replying from local folder does not use default account if recipient of original is not a defined account. (this has nothing to do with mailto: )

1. select message in local folder whose recipient is not in profile, i.e. not an account in thunderbird
2. reply

expected results: From: is set to default account

actual results: From: is set to a non-default account. The account used varies in some determinate way which I can't figure out but it is not random, but can vary from message to message - I'm guessing related in some way to the characters of the recipient address
Component: Account Manager → Message Compose Window
Keywords: regression
QA Contact: account-manager → message-compose
Summary: new message launched from local folder uses last defined account, not default account → replying from local folder does not use default account if recipient of original is not a defined account
As seen in Bug 327713, pre-selected From: depends on X-Account-Key:.
And as seen in Bug 377998, pre-selected From: depends also on identity definitions of mail addresses relate to From: and To:.
Because you say "recipient of original is not a defined account", your case sounds problem when "mail addresses in To:" is not defined in any identity.

Does X-Account-Key: header exist in mail try to reply?
(Only "mail downloaded by POP3" has this header, for Global Inbox support)
If exists, is accountN in X-Account-Key: defined account?
Is "mail address of defined identity" involved in From: or To: in the mail?

(Off-Topic)
By the way, "reset of default account" of my comment #1 looks to be different issue and it may be a result of my manual prefs.js modification. I'll try to figure out it.
My quick test result.
 Original mail : Both From: and To: are not defined in any identity
   From & Reply-To: aaa@bbb.ccc To: xxx@yyy.zzz (no CC: header)
 Pre-selected From: when reply
   (1) X-Account-Key: account1, account1 is defined
       => main identity of account1
   (2) X-Account-Key: account9, account9 is not defined
       => main identity of default account
   (3) No X-Account-Key: header
       => main identity of default account
These bugs may be related in some way, but not the sole cause as this is a trunk regression. Perhaps someone can determine which patch caused the regression.  
mailnews checkins:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=mozilla%2Fmailnews%2F&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-07-30+04%3A00&maxdate=2007-07-31+10%3A00&cvsroot=%2Fcvsroot
all checkins
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=mozilla%2F&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-07-30+04%3A00&maxdate=2007-07-31+10%3A00&cvsroot=%2Fcvsroot


(In reply to comment #3)
> As seen in Bug 327713, pre-selected From: depends on X-Account-Key:.
> And as seen in Bug 377998, pre-selected From: depends also on identity
> definitions of mail addresses relate to From: and To:.

I skimmed but haven't determined if they are directly related. 

> Because you say "recipient of original is not a defined account", your case
> sounds problem when "mail addresses in To:" is not defined in any identity.

Messages where I am cc: (of account 1 or 3) also work. Messages where it doesn't are me=sender.  

> Does X-Account-Key: header exist in mail try to reply?
> (Only "mail downloaded by POP3" has this header, for Global Inbox support)
> If exists, is accountN in X-Account-Key: defined account?
> Is "mail address of defined identity" involved in From: or To: in the mail?

No to all.  The only X headers, in the messages I checked
  X-Mozilla-Status: 
  X-Mozilla-Status2: 

The accounts in this profile numbered by order of appearance in folder pane:
* account 1 and 3 both imap 
* account 2 and 4 both pop
* 5 - one rss account
* 6... - several news accounts

prefs.js has 18 identity.idN
account 1, the default, is at the top of the list

local folder of the test has only imap messages, i.e. from accounts 1 & 3, copied (not filtered) from their respective imap inbox.

Failing replies have from: of either pop account, never account 1 or 3. And for a given message, every reply always gets the same from:, not randomly account 2 or 4 but always 2 or always 4.

Coincidence?  account 2 is identity.id1 in prefs.js and account 4 is the last identity, id18.
Problem has been observed at last. (Tb latest-trunk 2007/11/18, MS Win-XP)
My test result of comment #4 was when default account=account810001.
And, same result as comment #4 was obtained when default account=account3.
i.e.
When "Local Folders" (no identity is defined, so Bug 377998 can't occur),
and when no X-Account-Key: or when accountN in X-Account-Key: is not defined
(so Bug 327713 can't occur),
main identitiy of normal account(i.e. other than "Local Folders") of largest number(accout8100001 in my case) is used for pre-set From: for reply,
instead of main identity of "default account".

"Reset of default account to largest account when mailto: link click" may be a result of same root cause(such as miss-determination of "default account").
Status: UNCONFIRMED → NEW
Ever confirmed: true
Confirming.
Not sure I understood how to reproduce. If I take say a junk mail moved to Local Folders/test (no identity or account key) and reply - now I get the default account. What else do I have to do?
(In reply to comment #8)

Which profile is used? Same profile as one when problem was observed before?

When my manually modified profile of comment #1(Local Folders=account999999), following problem is re-produced always, 
  reset of default to "normal account with largest number"
  when mailto: link click while Tb is not running
except when default account is set to account2(==usually first normal account).
And, I can't reproduce the "reset of default account" problem with newly created profile/accounts;
 - account1 = Local Folders, No identity for this pseudo account
 - account2 to N = dummy POP3/IMAP accounts and a news account(news.mozilla.org)
 - No deletion of account. i.e. no hole in account numbers.

Further, Tb doesn't prohibit same mail address for different identities.
So mulitiple identities can have same mail address.
This may affect "Reply-to-self". So pre-set From: when Reply is affected.
Is this issue involved in your case?
WADA, is your question for me?  I don't know what to tell you, but I am willing to send you my prefs.js for your inspection.

Magnus, if you can't recreate the problem perhaps deletion of accounts and/or multiple identities are involved. I don't much/anything about identities because pay them no attention - I have several because of news servers, but all have same imap email addresses** - so WADA will know far me than me about identities.
** plus 2 pop defined for TB testing only
Test case contains following three mails.
Mail-1. Subject: test-001-X-Account-Key-account2
        X-Account-Key: account2
       (account2 is usually first defined account. Active account.)
Mail-2. Subject: test-002-X-Account-Key-account999
        X-Account-Key: account999
       (account999 is usually not defined. Removed account.)
Mail-3. Subject: test-003-No-X-Account-Key
        (No X-Account-Key: header. IMAP mail, sent mail, imported mail.)
All 3 mails have following From: & To:, which are usually never defined.
  From: from@from.from.from
  To: to@to.to.to
Save this text file under mail directory for "Local Folders", and restart Tb.

(In reply to comment #10)
> WADA, is your question for me?
Oh, sorry, comment #8 was by Magnus, not by you. Sorry for spam.
(I wrongly thought that you somehow couldn't re-produced problem any more...)
magnus, do you see symptoms using wada's testcase?

for all the messages in testcase my replies go to (drum roll) identity 1=account 2, not my default account=3 (account 3 are ident=2,5,11 server=3, with id=2 being my main identity/account).  FWIW I have 18 accounts and identities.
to reemphasize from summary, fails "if recipient of original is not a defined account" - specifically the default account

IOW if recipient of message I am replying to is my default account, then account OF THE REPLY is set to my default account.  If recipient of message I am replying to is another defined account, then the account/id of the reply is set to that defined account (but not the default).  Does this last condition mean I am hitting a preference setting?
Tried the testcase. When i put it under a (dedicated) pop account 002 and 003 uses the main identity of that account. 001 uses the default

With the testcase in Local folders (which I do not use for any account) I get the global default identity (the first one in the list).
Magnus, will it help to send you my profile and a sample message?

Is my regression range correct - 2007-07-30 04:00 and 2007-07-31 10:00 - and is bug 128996 / attachment 273674 [details] [diff] [review] the cause?
Keywords: dogfood
Flags: blocking-thunderbird3?
I am not sure I understand all of this; I am no computer geek, so I do not know if my problem is the same.  Sometimes, but not always when I send mail it with my name in the from and the recipient's name in the "to", the mail is sent to me instead of (presumably) the actual recipient.  When I right click on edit the received mail as a new message and send it again, it goes to the correct recipient.  This has only happened since I installed Thunderbird in a new Vista system.  Any ideas of what to do?
happens to me today when I double click draft message from my primary account - a behavior not seen before.  can't repro now - probably stopped after I restarted thunderbird.

offhand, comment 6 sounds different
Flags: wanted-thunderbird3+
Flags: blocking-thunderbird3?
Flags: blocking-thunderbird3-
just keeping track:
- (did not expect it to) bug 292643 which checked in did not help afaict
- (doesn't seem related) Bug 450113 sends via the non-default account until i delete all other smtp accounts except the intended one
Magnus, this is gone as of 2008-11-25's build.  Fixed IMO by bug 466660.  As further proof, it is still fixed with 2008-11-26 build but more importantly it doesn't happen on a build older than 2008-11-25 - which is consistent with what bug 466660 should accomplish, which is a persistent effect in prefs.js.

Yahoo!  And I hope we find that bug 466660 impacts other reported bugs.

Thanks for your attempts to help with this.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 466660
Glad it's working! Wrong bug # though? Bug 466660 doesn't even have a patch yet.
ga. good catch. bug 464808 is the one
Duplicate of bug: 464808
You need to log in before you can comment on or make changes to this bug.