252103 - When selecting reply/forward the default identity of the downloading account is used.

Status: VERIFIED FIXED

(Thunderbird :: Message Compose Window, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

version 0.7+ (20040707)

I'm using different mail addresses over one pop3 account and manage 3 pop3 boxes
inside one global inbox. When I want to reply/forward a message which has an
additional identity for one pop3 account, the default identity for this account
is used. We shouldn't only look for the account to use but also for the identity
of that account.

It seems that it only appears when using a global inbox. 

Could someone confirm that on SeaMonkey?

Comment 1

[Christian Eyrich]

Dupe of bug 228593?

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+2]]

No, this isn't a dupe. The identities I created aren't shared between different
accounts. I have only identities which belongs to exactly one account. 

When I compose a mail the standard identity is used - that's ok. But when I
reply/forward a mail which was received by another identity, the standard
identity is selected.

identities:
[e-mail]
[e-mail]

New mails to [e-mail] were successfully moved with a filter to a
special folder within the same account. Answering this mail the identity
[e-mail] is selected and I have to reselect the right identity.

Comment 3

[Christian Eyrich]

Ah yes, the other bug was a special case, sorry.

I can confirm that always the From: of the first identity of the standard
account is chosen for the reply. That's the case for message not residing in an
accounts subfolder, e.g. moved to Local Folders, and answered there.

I can't confirm the first identity of the account that received the mail is
chosen. And I can't confirm the problem if I activate the new Global Inbox
feature (Advanced in POP Server Settings) and reply to a message in Local
Folders then.

So it looks to me like bug 229817.

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Ok, the global inbox isn't the problem. Here at home i doesn't use it and it
still appears also. 

I have following scenario...

The first account is using gmx.de (email address [e-mail] - not needed
locally) and has the default identity foo-private@foo. The second account
receives all other mails and these one which are addressed to foo-private@...
are forwarded to the inbox of the first account.

Replying a mail which was received over gmx.de uses foo-private@foo as sender
address. But replying a mail which was moved by a message filter from the second
to the first account the default identity of account two is used. This only
happens when moving mail accross different accounts. Otherwise the right adress
is used. Additionally one further information: the second account isn't the
standard mail account.

Comment 5

[Christian Eyrich]

Ok, now I see. What you expirience is a feature, introduced as part of bug 30057
(mailCommands.js rev 1.87).

It only applies to mails that are moved by filter, not by hand.
Maybe accountKey should only be used in ComposeMessage() if defering is
activated for the accountKey's account.
This should help for most cases although it won't if defering is activated but
you nevertheless want the original accounts identities to be searched.

David, any other ideas?

Comment 6

[David :Bienvenu]

We always use the account for the server that downloaded the message, no matter
where the message is moved to, or how it's moved. Moving via filter vs. moving
by hand should not be an issue. However, before the global inbox feature landed,
we did not know which server downloaded the message, so if you move a message
downloaded with a version of thunderbird which did not remember the downloading
server, then we would just use the account the message is currently in.

I thought this would be a useful behaviour in general, e.g., when you move
messages into local folders from different accounts, even w/o deferring. But
there are always people who want it to work differently - I guess that's why we
have prefs :-) We could, as Christian says, only use the originating account if
the originating account is a deferred account, but it sounds like even that
would not give Henrik what he wants, which is to always use search the
identities of the account the message is currently in. It sounds to me like we
could just have a global pref - for reply/forward, search identities of
originating account, or of current account. Do you think that would handle most
cases? Do you think we need a per-account pref? I hope not...

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Perhaps i missunderstood you David but what i mean is following: When i reply to
a messages which is located on another account now, the original (downloaded)
account should be used. You said that we know the originating account since the
global inbox was implemented. So we also have a list of identities assigned to
this account. Why don't we search it's identities and use the first matching
entry for replying? I dont wanna have the default identity of the current
account where the message is located now. This solution should only be used if
the identity of the originating account (or the account itself) was deleted and
isn't accessible anymore.

Comment 8

[David :Bienvenu]

oh, you want what we are doing, then, or at least what I thought we were
doing...if you add the original account column to the thread pane (click on the
column picker icon to the right of the right most column header to add that
account), does it look like we know what the original account is?

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Yes, because the default identity of the originating account is already used at
the moment. So we just have to add a function which tells us the right identity,
which we will use to send the message?

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Mmh this problem also appears within SeaMonkey right? We should update the
product and component boxes...

Comment 11

[David :Bienvenu]

the way the code works, I believe, is as follows:

1. We get the incoming server for the folder the message is in.
2. If the message has an x-account-key, we get the incoming server for the
corresponding account instead.

3. Using the server calculated above, we get the best identity for that server
and the recipients of the current msg.

I understand that it's not doing the right thing for you, but doesn't the above
describe what you think it should do? I believe in your case we will search
through the identities for the originating account's server to try to find the
first one that matches the recipients of the message. So I guess I don't
understand why it's not doing the right thing.

http://lxr.mozilla.org/mozilla/source/mail/base/content/mailCommands.js#228

I also am confused about whether you have multiple identities for a given
server. You say this:

"So we also have a list of identities assigned to this account..."

but earlier you say: "I have only identities which belongs to exactly one account."

Has this bug morphed somewhat?

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+2]]

There was no change of my identities. The originating account has different
identities (private, job, bugzilla, mozilla europe etc). Messages of the last
four identities are moved to a folder within the same account. The private
messages i move with the help of the message filter to my other accounts inbox
(where the private address is also used by the default identity). 

I followed your link and found my failure. My originating server doesn't have
any identity with the private address. In that case getBestIdentity(..) can't
find any match for these identities and the default identity is used. 

So you was right, David. But how should we handle such messages? Should the
default identity of the current account (if this are not local folders) should
be used before the default identity of the originating server is inserted?

I don't know if we run in trouble with the global inboxes when using this way.
But when i move a message to another account then i know what i do and the
current account should be used before recoil to the originating accounts default
identity?

Comment 13

[David :Bienvenu]

yeah, maybe we should look for an exact match from the current account if we
can't find one for the original account, before using the default identity. I
guess it's not too hard to check if the identity we find contains the recipient...

Comment 14

[Christian Eyrich]

(In reply to comment #6)
> We always use the account for the server that downloaded the message, no
> matter where the message is moved to, or how it's moved. Moving via filter vs.
> moving by hand should not be an issue.

No, the Account-Key header line isn't written upon receive or by moving the
message by hand. It's written to the mail when moved by a filter (at least when
run on receive, didn't test when running a filter manually).

Comment 15

[Christian Eyrich]

(In reply to comment #7)
> When i reply to a messages which is located on another account now, the
> original (downloaded) account should be used.

Before you wrote

> But replying a mail which was moved by a message filter from the second
> to the first account the default identity of account two is used.

I missunderstood it the way that you didn't want the identities of the
originating account to be used. But you only don't like the *default* identity
of the originating account to be used.

Comment 16

[Christian Eyrich]

(In reply to comment #13)
> yeah, maybe we should look for an exact match from the current account if we
> can't find one for the original account, before using the default identity. I
> guess it's not too hard to check if the identity we find contains the
> recipient...

Like this?

  if (server)
    identity = getIdentityForServer(server, hintForIdentity);

  if (hintForIdentity.search(identity.email) < 0)
  {
    server = folder.server;
    if (server)
      identity = getIdentityForServer(server, hintForIdentity);
  }

Problem would be that if the first getIdentityForServer() found a not exact
match in a mailing list, we'd discard this. So either another approach or a more
complicated match (like in the second loop in getBestIdentity()) to see if we
already found the right identity.

Comment 17

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to comment #14)
> No, the Account-Key header line isn't written upon receive or by moving the
> message by hand. It's written to the mail when moved by a filter (at least when
> run on receive, didn't test when running a filter manually).

X-Account-Key seems to be written when finished downloading the message. Every
message inside the inbox of different accounts which are moved or not moved
contains this header.

> I missunderstood it the way that you didn't want the identities of the
> originating account to be used. But you only don't like the *default* identity
> of the originating account to be used.

Yes, we should use the most suitable identity for replying. If the originating
account doesn't have such an identity we should use the current account, except
the local folders. In such a case the default identity of the originating
account should be used. 

Sorry that it was a little bit unclear but i checked the current behavior after
looking at the source code.

Comment 18

[Christian Eyrich]

(In reply to comment #17)

> X-Account-Key seems to be written when finished downloading the message. Every
> message inside the inbox of different accounts which are moved or not moved
> contains this header.

Blind, blind, blind. Yesterday I didn't saw them - on three different
installations. Today every (reasonably new) mail has this header line.
Sorry.

Comment 19

[David :Bienvenu]

the original account key is written when we download the message from the pop3
server. That account key is maintained when messages are moved, no matter where
they are moved, or how. I may be confused about what you're saying, but filters
vs. manually moving messages seems irrelevant.

Comment 20

[David :Bienvenu]

sorry, should have read all the comments first. We're all on the same page now.

Re how to not lose an original partial match, I'd just expand on your code to
use a temp var:

  if (server)
    identity = getIdentityForServer(server, hintForIdentity);

  if (hintForIdentity.search(identity.email) < 0)
  {
    server = folder.server;
    if (server)
    {
      var tmpIdentity = getIdentityForServer(server, hintForIdentity);
      if (hintForIdentity.search(tmpIdentity.email) >= 0)
          identity = tmpIdentity;
    }
  }

Comment 21

[Christian Eyrich]

Yep, without having tested it it looks reasonable.

Comment 22

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Do we have any news about this one? 

Comment 23

[Christian Eyrich]

Attachment: proposed patch variant 1

This is a patch that uses the code from comment #20 with two modifications to
catch the case where identity resp. tmpIdentity is null.

Comment 24

[Christian Eyrich]

Attachment: proposed patch variant 2

This patch first looks up the identities from the current folder and if no
match, it uses the identities of the original account.
So which patch to use is a question of
a) which identity to prefer if identities from both accounts would match and
b) which scenario is more likely, the match in the folder.server's identity or
the account.incomingServer's

Comment 25

[David :Bienvenu]

Comment on attachment 159309 [details] [diff] [review]
proposed patch variant 2

I guess we want the same patch for tbird...

Comment 26

[Christian Eyrich]

(In reply to comment #25)
> (From update of attachment 159309 [details] [diff] [review])
> I guess we want the same patch for tbird...

Yes of course. I just wanted to ask first which variant to use.
I can attach a patch for mail/base/content/mailCommands.js if variant 2 is ok
for Scott too.

Comment 27

[Scott MacGregor]

Comment on attachment 159309 [details] [diff] [review]
proposed patch variant 2

this variant sounds correct

Comment 28

[Christian Eyrich]

Attachment: proposed patch

Combined patch for Mozilla and TB.
It contains an additional statement
  if(folder) server = folder.server;
My initial thought was that this isn't necessary since it's already assigned on
line 178. But I overlooked that since we're in a loop, it's lost after the
first pass.

Comment 29

[Scott MacGregor]

thanks Christian. I checked your patch into the aviary branch (the 9/28 one).
I'll let you land it on the trunk at your leisure.

Comment 30

[Hadrien Nilsson]

I am experiencing this bug with the 0.8 milestone of Thunderbird, not with
previous versions. Here is a description.

I've got a primary account, the one given by my Internet access provider, with
it's own pop and smtp server : [e-mail]

I've got a secondary account : [e-mail].

I've got a catch-all for *@psydk.org, so when a mail is sent to [e-mail],
it is :
- bounced to [e-mail] ;
- then it is poped by my primary account ;
- finally a filter rule puts the mail in the inbox of the my secondary account
([e-mail]).

When I reply to this mail, here are the behaviours :

1) Before 0.8 : the From field is set to [e-mail]. This is what I expect.
2) With 0.8 : the From field is set to [e-mail]. I'm unhappy
with that.
3) Since the 20041001 build : the From field is set with [e-mail] when the
mail was sent to [e-mail], otherwise the field is set with
[e-mail]. Still a small annoyance here.

I didn't look at the code there, but maybe the simpliest thing to do is to
select the mail address assigned to the account where the mail eventually landed ?

Comment 31

[David :Bienvenu]

fixed on trunk.

Comment 32

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Hadrien, we need a consitent behavior and that is not assured when using the
default identity of the current location. Message filters can move mail messages
to every folder including "local folders". There is none identity assigned and
we have to use the best identity of the downloading account. In your case it
will be '[e-mail]'. We can't use two different ways to fetch
the right identity. 

When you add an additional identity to the downloading account this wanted
identity isn't used?

Comment 33

[Hadrien Nilsson]

Thank you Henrik, I followed your piece of advice, and added [e-mail] as an
additional identity for my main account ([e-mail]). So now
when I reply to *@psydk.org I get [e-mail] in the From field :)

Comment 34

[Mike Cowperthwaite]

*** Bug 254209 has been marked as a duplicate of this bug. ***

Comment 35

[Bill Schmitt]

*** Bug 263658 has been marked as a duplicate of this bug. ***

Comment 36

[Jo Hermans]

*** Bug 308375 has been marked as a duplicate of this bug. ***