After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 524497 - Wrong "From" value if multiple accounts configured
Wrong "From" value if multiple accounts configured
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Mailer
2.12.x (obsolete)
Other All
: Normal normal
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2008-03-26 15:14 UTC by Pascal Kreyer
Modified: 2010-03-11 13:40 UTC
See Also:
GNOME target: ---
GNOME version: 2.19/2.20


Attachments
Change the order getting an account (1.15 KB, patch)
2009-04-09 11:44 UTC, Jeff Cai
committed Details | Review

Description Pascal Kreyer 2008-03-26 15:14:18 UTC
Please describe the problem:
If you receive the same email on your both emails account, take a "reply to all" from your second account, the "from" value is the first account !

Steps to reproduce:
1. configure two accounts : alpha and beta
2. send a email directly to alpha and beta, in this order, from an another email account
3. open this mail on beta account
4. click on "reply to all" button


Actual results:
"from" is set to alpha account

Expected results:
The mailer should use the right account and not the first found in the "to :" list

Does this happen every time?
yes

Other information:
Evolution select the first account found in the "To:" list to set the "from:".
Comment 1 Jeff Cai 2009-04-09 09:54:06 UTC
The reply function checks all "To" value in the email as sending account and then use the first found as the sending account.
Comment 2 Jeff Cai 2009-04-09 11:44:29 UTC
Created attachment 132405 [details] [review]
Change the order getting an account

The original order is:
1. The account in 'To' of the message.
2. The account of the message source.
3. The account of the folder source.

The new order is:
1. The account of the folder source.
2. The account of the message source.
3. The account in "To' of the message
Comment 3 Milan Crha 2009-04-20 10:28:17 UTC
Looks good, just test and commit to trunk.
Comment 4 Nick Jenkins 2009-05-01 05:24:51 UTC
I would be great to see this fix commited for 2.28. I think I'm being affected by this, I was going to log a new bug, but will just put the details in here because I suspect it's the same problem.

-----------------------------------
Wrong account sometimes used to reply to email.

In Evolution 2.26.1, I have 3 accounts defined under Edit -> Preferences -> Mail accounts, namely:
1) Local mail on his computer (with the email address formatted like: Nick@companyName.com ). This account has under "receiving email" the "server type" set to none, and the "sending email" server set to SMTP.
2) I have a work IMAP account (with the email address using the same Nick@companyName.com address as for the local mail account described above). This account can both send and receive mail (using SMTP and IMAP respectively). This account is marked as the default account.
3) I have another IMAP account (gmail) for non-work-related mail.

The problem is this:
When I read email sent to the IMAP work account, in the IMAP account's inbox, and reply to that email, it incorrectly uses the "Local mail on this computer" account to reply, but only if the "To" address was Nick@companyName.com ; if the "To" address was someAlias@companyName.com , then it works as expected, and uses the work IMAP account. I.e. it seems to be matching the email address for the Local mail account before the currently active account or the default account, and so it picks the wrong account to use when replying.

What should happen:
It should reply from the work IMAP account instead. Reasons for this: 
* It is the account that I have selected in the tree of accounts/folders (i.e. the mail is in the IMAP account's inbox)
* It is the default account.
* It is the account that the email was sent to and received by (i.e. no filters have moved the mail item).
Comment 5 Jeff Cai 2009-05-06 09:57:27 UTC
Committed to HEAD.
Comment 6 Oded Arbel 2010-03-11 09:53:52 UTC
Sorry to bring up obscure past bugs, but there is something seriously broken here:

(In reply to comment #2)
> Change the order getting an account
> The new order is:
> 1. The account of the folder source.
> 2. The account of the message source.
> 3. The account in "To' of the message

The new order makes no sense - Evolution will now never select the account in "To" of the message because a message is always read from some folder that has an account associated with. 

In my use case, I have two accounts, alpha and beta, where beta forwards all emails to the alpha inbox (so I don't have to actually check two inboxes). When I receive an email that was sent only to alpha, I want to reply as "alpha" and when I receive an email that was sent only to beta, I want to replay as "beta". This worked very well with the old order but with the new order Evolution always wrongly selects "alpha" when reading email that was sent to "beta".

I understand the original bug report, but I think the fix is very heavy handed towards always selecting the folder's owner account and never do auto detection based on the receiver's address.

The solution should be to change the selection heuristics to:
1. Select all accounts whose email address appears in the "To" field.
2. If none found, select all accounts whose email address appears in the "Cc" field.
3. If none found select the default account.
4. If more then one account is found in step 2 or 3, check if one of them is the folder source account and if so select that.
5. If 4 failed, select the first account in the list.
Comment 7 Matthew Barnes 2010-03-11 12:21:14 UTC
The account selection heuristics were corrected for 2.29.  See bug #533333 comment #36.
Comment 8 Matthew Barnes 2010-03-11 12:22:09 UTC
Correction: bug #588833 comment #36
Comment 9 Oded Arbel 2010-03-11 13:40:18 UTC
Thanks, I've just seen it.