User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0 (Beta/Release) Build ID: 20131025151332 Steps to reproduce: In Thunderbird 24.1.0, open an incoming message with (at least) these two lines in its header: From: user1@domain1.net Reply-to: user2@domain2.net While reading it, click on "reply" Actual results: Observe that a composition window is opened with "To: user1@domain1.net" Expected results: The composition window should have used "To: user2@domain2.net" as the Reply-to: tag intended.

Same problem here; on Linux (Fedora).

I am having the same problem on one email account but not on the other.

I found my above description of the bug to be inadequate to reliably reproduce it. A better statement seems to be: If the "From:" address is an identity of mine, then the "Reply-to:" address is ignored and the "To: address is used instead. How this is a problem for me: My web site has a "contact me" form, which sends me an e-mail with my own address in its "From:" line (so the message is accepted without mis-classification as spam) and the visitor's e-mail address in the "Reply-to:" line (so that I can reply to him). This worked perfectly with prior versions of Thunderbird, but recently my replies are sent to my address, to which the original message was delivered.

Same prob here after upgrade

Same issues (Windows 7). If it makes a difference, the account it is pulling from is a gmail account via imap.

I'm seeing the same problem under Windows and Linux. Windows version of Thunderbird 24.1 uses the "from" address instead of "reply-to" address when replying to messages. We have a contact form on our website that uses our own address as the "from" address ( so that customers get a copy of the email ) and the customers address as the "reply-to" address. Until version 24.1 when hitting reply Thunderbird would use the customers address i.e. the "reply-to" address, since upgrading to Thunderbird 24.1 ( on Windows and Linux ) when hitting reply it uses our address i.e. the "from" address. These are the same issues being seen by Rich Pasco.

I believe this is a duplicate of Bug 932774 - Clicking reply does not obey reply-to header in source message https://bugzilla.mozilla.org/show_bug.cgi?id=932774 I have made a comment to that effect on the bug, comment #3.

Yes, as the submitter of 933555 I agree it is a duplicate. The important things to realize are that 1) The condition which triggers the bug, Thunderbird to ignore "Reply-to:" is that the "From:" address is in the user's address book. If it is not, then "Reply-to:" is handled correctly. 2) If condition (1) is met, then the address which is erroneously used instead of "Reply-to:" is not "From:" as was stated above, but in fact "To:". That subtlety is not noticed in cases where "From:" and "To:" are the same. I hope this sheds some light on this problem.

(In reply to Rich Pasco from comment #8) > 1) The condition which triggers the bug, Thunderbird to ignore "Reply-to:" > is that the "From:" address is in the user's address book. If it is not, > then "Reply-to:" is handled correctly. Unfortunately I did not find this to be the case. Although the 'from' address was originally in the 'collected addresses' address book, deleting the entry and restarting Thunderbird was not a workaround for me. (Thunderbird 24.1.0 on Windows 7 64 bit)

Excuse me, apparently I mis-stated condition 1 when I wrote: > 1) The condition which triggers the bug, Thunderbird to ignore "Reply-to:" > is that the "From:" address is in the user's address book. If it is not, > then "Reply-to:" is handled correctly. I believe that I stated it correctly above, "If the "From:" address is an identity of mine..." Based on thomas@gtsquare.com's observation, its presence (or absence) in my address book is irrelevant. - Rich

I stumbled upon the same bug and I have additional information. If the reply-to content is YOUR email/identity then TB too does not fill in the information when you press reply. So reply-to works IF: a) the reply-to is no identity of yourself AND b) the from is no identity of yourself otherwise it seems to be broken and if you click reply, you simply get an empty "to" line in the compose window. There might be other conditions that trigger it but these should be easily testable.

What about of some "votings" for this bug. This hopefully increase the chance of a fast fix. ;)

Just voted, This issue is driving me NUTS!

--------------------------------------- Same issue here with following source: --------------------------------------- Return-Path: <order@aquariumbemesting.nl> Delivered-To: order@aquariumbemesting.nl Received: from localhost (localhost [127.0.0.1]) by mx0.webunity.nl (Postfix) with ESMTP id 24F421C062 for <order@aquariumbemesting.nl>; Mon, 18 Nov 2013 19:53:59 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at fragaria.db.webunity.nl Received: from mx0.webunity.nl ([127.0.0.1]) by localhost (fragaria.db.webunity.nl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Vt9OcaA2Bzph for <order@aquariumbemesting.nl>; Mon, 18 Nov 2013 19:53:53 +0100 (CET) Received: from [127.0.0.1] (j30124.upc-j.chello.nl [24.132.30.124]) by mx0.webunity.nl (Postfix) with ESMTPSA id C2B1B1C009 for <order@aquariumbemesting.nl>; Mon, 18 Nov 2013 19:53:53 +0100 (CET) Message-ID: <528A64EB.70902@aquariumbemesting.nl> Date: Mon, 18 Nov 2013 20:05:15 +0100 From: "Aquariumbemesting.nl" <order@aquariumbemesting.nl> Reply-To: gilles@webunity.nl User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: order@aquariumbemesting.nl Subject: test Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit test message --------------------------------------- Worked correctly in webmail, reply-to was accepted; thunderbird ignores it.

p.s. re-installing Thunderbird 24.0 solved the problem for me, so something changed in between those version which 'broke' the reply-to functionality.

Thanks for the update Gilles, Just want to clarify before I install the previous version, was that was 24.0 or 24.0.1? Cheers

Update, Ive installed previous version 24.0. and the issue seems to be fixed except for there still being no option for the "Reply To" address to take priority over the "from" address when replying to emails where the "from" address is not one of the clients accounts. It would be good to have the option to set either and/or both. I am also now reminded why I updated to TB25: the signature html is always greyed out and ignores style color settings. Seems that the Moz group are not fully testing the releases before offering the upgrades. One bug fixed another bug introduced!

Wondering if I should have down-dated to v24.0.1 instead?

Updated to version 24.1.1 and the error still remains

If Reply-To-Self is cause, following may be a workaround. - mailnews.reply_to_self_check_all_ident = false (default=false) - Define all used identities at outside of actually used mail account in Tb. To force it, followng procdure is perhaps usable. 0. Keep mailnews.reply_to_self_check_all_ident = false 1. Create dummy POP3 account, call AccountX, with non-existent server, for example, z.z.z, via "Manual Config" of account creation panel. 2. Define all required mail addresses as "identity of the dummy AccountX". 3. Change mail address in identity of existent account to dummy mail address. 4. Change account number/server number of AccountX in prefs.js to account1/server1, in order to place mail addr of AccountX at next to current account's one at From: selection list in mail composition window. 5. "Setting AccountX as default account" may be needed. Another possible workaround. Add-on of "Correct Identity" (Read meta bug 699681 and bug 327713 comment #53, please.) Will the add-on help you?

Just to let anyone following this bug know I have replied to WADA under bug: https://bugzilla.mozilla.org/show_bug.cgi?id=932774#c10 ( which seems to be a duplicate of this and 933377 ) trying to clarify what I understand to be the problem we are all seeing.

WADA, no the problem here is not reply-to self. It's when the From: address is one of my identities, the Reply-to: field (containing the address of a stranger) is ignored, and the reply is instead addressed to the To: field of the original message. This is occurs when the message comes from a website "contact us" form, which puts my own address in its From: and To: fields and the customer's address (from the web form) into the Reply-to: field.

Further reply to WADA related to this and bug 932774 and 933377 https://bugzilla.mozilla.org/show_bug.cgi?id=932774#c13

(In reply to Rich Pasco from comment #22) > WADA, no the problem here is not reply-to self. > It's when the From: address is one of my identities, > the Reply-to: field (containing the address of a stranger) is ignored, (snip) Symptom is "Reply-to-self feature ignores Reply-To: header", isn't it? Do you see your problem with following? (A) Move the identty to other account. - Keep mailnews.reply_to_self_check_all_ident = false (default=false) - Change mail address in identity definition of the relevant account to dummy one. - Define the mail address as identity of other existent account. (B) No X-Account-Key: header, and mail is held in different accout's folder. - Save the mail as .eml, edit .eml file by Text Editor, remove X-Account-Key header:. (kill X-Acount-Key: based identity selection) - Drag&Drop the .eml file to thread pane of a mail folder of other account. (import of .eml file by Drag&Drop) - Keep mailnews.reply_to_self_check_all_ident = false (default=false) - Try to reply at the different account's mail folder.

(In reply to Rich Pasco from comment #22) > WADA, no the problem here is not reply-to self. (1) mailnews.reply_to_self_check_all_ident, X-Acount-Key, are checked here. http://mxr.mozilla.org/comm-central/source/mailnews/compose/src/nsMsgCompose.cpp#2517 (2) "reply-to-self or not" is determined at here, based on From: and To:/CC:. http://mxr.mozilla.org/comm-central/source/mailnews/compose/src/nsMsgCompose.cpp#2548 (3) Reply-To: header is used only when isReplyToSelf is false when ReplyToSender or Reply. http://mxr.mozilla.org/comm-central/source/mailnews/compose/src/nsMsgCompose.cpp#2599 This code doesn't look altered from initial implemetation of reply-to-self feature. Change made around this code seems done on "Reply to All". http://hg.mozilla.org/comm-central/annotate/47f09564338a/mailnews/compose/src/nsMsgCompose.cpp#l2599 Rich Pasco, new problem from Tb 24? (I can't think so.)

(In reply to Rich Pasco from comment #22) > WADA, no the problem here is not reply-to self. In Tb 24.1.1, if From: != To: (i.e. mail between different identities), Reply-to-Self of Tb uses Reply-To: header as expected. Reply-To: is ignored only when From: == To: (i.e. mail between same identity). So, problem can be called ; Reply-To: is ignored when absolutely "Reply-to-Self", where "Self" == "mail address defined as identity in Tb". (In reply to Rich Pasco from comment #0) > From: user1@domain1.net > Reply-to: user2@domain2.net Why hide To:, CC:, Delivered-To:, Sender:, etc. which is usually relevant and important... To Rich Pasco(bug opener): Mail sent to user1@domain1.net, and the user1@domain1.net is defined as identity of this account in Tb(if mailnews.reply_to_self_check_all_ident = false) or as identity of other account in Tb(if mailnews.reply_to_self_check_all_ident = true)? What s set in To: or CC: or Delivered-To:? FYI. Comment #14 case. (bug 932774 is also report on From:=To: case) From: "Aquariumbemesting.nl" <order@aquariumbemesting.nl> To: order@aquariumbemesting.nl Reply-To: gilles@webunity.nl Anyway, confirming.

I believe Reply-To: header must have higher priority than Reply-To-Self in Tb. I think "check !replyTo.IsEmpty() first(existence check of Reply-To:header), check isReplyToSelf second" is proper and simplest solution. I don't know about !mailReplyTo.IsEmpty() which is for Mail-Followup-To and Mail-Reply-To. But I think that its use is not appropriate when ReplyToSender/Reply and it's better limited in "Reply to author" or "Follow up". > http://mxr.mozilla.org/comm-central/source/mailnews/compose/src/nsMsgCompose.cpp#2599 > 2599 if (type == nsIMsgCompType::ReplyToSender || type == nsIMsgCompType::Reply) > 2600 { > 2601 if (isReplyToSelf) > 2602 { > 2603 compFields->SetTo(to); > 2604 } > 2605 else if (!mailReplyTo.IsEmpty()) > 2606 { > 2607 // handle Mail-Reply-To (http://cr.yp.to/proto/replyto.html) > 2608 compFields->SetTo(mailReplyTo); > 2609 needToRemoveDup = true; > 2610 } > 2611 else if (!replyTo.IsEmpty()) > 2612 { > 2613 // default behaviour for messages without Mail-Reply-To > 2614 compFields->SetTo(replyTo); > 2615 needToRemoveDup = true; > 2616 }

FYI. If multiple identities are placed in To:, problem is not reproduced. > d1@d.d.d, d2@d.d.d, d3@d.d.d are defined as identity. > (case-A) preset addres by Reply was : From: d1@d.d.d To: r1@r.r.r > From: d2@d.d.d > To: d1@d.d.d, d2@d.d.d, d3@d.d.d > Reply-To: r1@r.r.r > (case-B) preset addres by Reply was : From: d2@d.d.d To: r1@r.r.r > From: d2@d.d.d > To: d2@d.d.d, d1@d.d.d, d3@d.d.d (order is changed) > Reply-To: r1@r.r.r It looks that Tb doesn't consider "multiple identities in recipient list" as "Reply-to-Self", and it looks that Tb selects "first found identity in recipients" for From: as done in non mail-between-identities case. Problem looks to occur only when "true Reply-to-Self" case. ( == current definition of "Reply-to-Self" in Tb ) ( which is not altered from initial implementton of Reply-to-Self feature ) ( == "mail between same/single identity" == "only one identity is involved" )

Correction. Mail-Reply-To: was for mailing list. Check should be done in following order. !mailReplyTo.IsEmpty() -> !replyTo.IsEmpty() -> isReplyToSelf There is no reason to ignore Mail-Reply-To: and Reply-To: when isReplyToSelf==true(i.e. mail between same/single identity, true Reply-to-Self in Tb).

WADA, no this has nothing to do with "Reply-to-Self" Please read carefully every one of my posts, including the one which started this thread. You may have a different agenda, in which case you need to file a separate bug report separately.

Change like next may be better, because excess "needToRemoveDup = true;" is not needed when isReplyToSelf==true. > 2601 if (isReplyToSelf) > 2602 { > 2603 compFields->SetTo(to); > 2604 } > => > if ( isReplyToSelf && !mailReplyTo.IsEmpty() ) compFields->SetTo(mailReplyTo); > else if ( isReplyToSelf && !replyTo.IsEmpty() ) compFields->SetTo(replyTo); > else if ( isReplyToSelf ) compFields->SetTo(to);

(In reply to Rich Pasco from comment #30) > WADA, no this has nothing to do with "Reply-to-Self" Please read carefully > every one of my posts, including the one which started this thread. You may > have a different agenda, in which case you need to file a separate bug > report separately. However, comment #14 case, and bug 932774 case which you say "same problem", are obviously for next case. "From:=To:" && "Single identity only in recipient list(all is To: case)" && "the mail address is defined as identity in Tb". And, following is prety easily observed. When a1@.a.a, a2@a.a.a are defined as identity, by Reply, (i) From: a1@a.a.a To: a1@a.a.a Reply-To: rr@r.r.r => From: a1@a.a.a To: a1@a.a.a (ii) From: a1@a.a.a To: a2@a.a.a Reply-To: rr@r.r.r => From: a2@a.a.a To: rr@r.r.r (iii) From: a1@a.a.a To: a1@a.a.a, a2@a.a.a Reply-To: rr@r.r.r => From: a1@a.a.a To: rr@r.r.r (iv) From: a1@a.a.a To: a2@a.a.a, a1@a.a.a Reply-To: rr@r.r.r => From: a2@a.a.a To: rr@r.r.r (Note: X-Account-Key: is removed for ease of test and to avoid confusion) Further, as known by source code, Tb's logic obviously skips Reply-To: header use if isReplyToSelf=true. Who has discoverd "If the From: address is an identity of mine..." is you, isn't it? Please note that "Reply-to-Self" is feature name in Tb, and isReplyToSelf==true/false is *definition* in Tb, and it never means "You are trying to reply to mail address owned by you" or "You are trying to reply to mail address which is placed in Reply-To: header". As known by source code, identity selection is affected by Delivered-To: header in addition to X-Account-Key: header, and if no To: or CC:, Tb uses Delivere-To: also as "recipient list". What is difference of your case from comment #14 and bug 932774 which are for next case? "From:=To:" && "Single identity only in recipient list(all is To: case)" && "the mail address is defined as identity in Tb". No To: or CC:? (sent via BCC:, server may put Delivered-To:) Mail is moved to mail folder of different account then owner of mail folder!=X-Account-Key:? Or Inbox of Local Folders is used as Global Inbox so identity selection is based on X-Account-Key:, then it confuses you? Or mailnews.reply_to_self_check_all_ident=true is used so "identity defined in other account" is relevant to your case?

Hi Wada, this case describes exactly my "problem": (i) From: a1@a.a.a To: a1@a.a.a Reply-To: rr@r.r.r => From: a1@a.a.a To: a1@a.a.a What I would expect is: (i) From: a1@a.a.a To: a1@a.a.a Reply-To: rr@r.r.r => From: a1@a.a.a To: rr@r.r.r > > if ( isReplyToSelf && !mailReplyTo.IsEmpty() ) compFields->SetTo(mailReplyTo); > > else if ( isReplyToSelf && !replyTo.IsEmpty() ) compFields->SetTo(replyTo); > > else if ( isReplyToSelf ) compFields->SetTo(to); So your second line should handle this case, doesn't it?

4 test mails are contained in file. Note: - From:, To:, Reply-To: is also put in Subject: for ease of test. - There is no X-Account-Key: in test mail, for ease of test and to avoid confusion. Problem occurs(Reply-To: is not used) only when ; case-1-a: From: z1, To: z1, Reply-To: rr Problem doesn't occur when ; case-1-b: From: z1, To: z1, z2, Reply-To: rr case-2-a: From: z1, To: z2 Reply-To: rr case-2-b: From: z1, To: z2, z1, Reply-To: rr In any case, "First identity in recipint list"(=first mail address in To: header) is used for From: mail address of reply mail. If case-1-a, To: of replied mail is set in To: of reply mail by Reply-To-Self. In all other cases, Reply-To-Self is not applied, then Reply-To: of replied mail is set in To: of reply mail as expected. [Steps to reproduce] 0. Keep mailnews.reply_to_self_check_all_ident=false 1. Copy the file under mail directory of an POP3 ccount, restart Tb. 2-1. Define z1@z.z.Z and z2@z.z.z as identity of the account. 2-2. Do Reply for 4 test mails. => problem is observed. 3-1. Copy 4 mails to local mail folder of other account 3-2. Do Reply for 4 test mails at other account. => problem is NOT observed. 4-1. Change to mailnews.reply_to_self_check_all_ident=true 4-2. Do Reply for 4 test mails at other account. => problem is observed.

(In reply to mike from comment #33) > this case describes exactly my "problem": > (i) From: a1@a.a.a To: a1@a.a.a Reply-To: rr@r.r.r => From: a1@a.a.a To: a1@a.a.a "All cases which is reported with message header data in this bug and bug 932774" is this case, except this bug's opener case and bug 933377 case(recipient list data , To:, CC:, Delivered-To:, is not provided yet, so it's still unclear in these two cases). > So your second line should handle this case, doesn't it? Yes, you are right. Because isReplyToSelf looks set to true only when "From: == To:" and "single mail address only in To:", "blindly use Mail-Reply-To: or Reply-To: for To: when ReplyToSender/Reply" is proper action in both isReplyToSelf=true case and isReplyToSelf=false case, as far as current rule for "setting isReplyToSelf=true" is kept.

Sorry, my assumption was wrong. Term of "Reply-To-Self" == "Reply to my-identity", and isReplyToSelf=true is set in following case(considerd "true Reply-To-Self"). (a) From: my-identity, To: non-identity (b) From: my-identity, To: single identity and same my-identity as From: In following case, isReplyToSelf=false is set, because "Reply betweeen different identities" is not considered "true Reply-To-Self". (c) From: my-identity, To: multiple identities Current "use To: in replied mail for To: of reply mail always if isReplyToSelf=true" is for above (a), and it is absolurely proper when (a). Problem of this bug was: When (b), because "To: in replied mail" is used as "To: in reply mail", Reply-To: is ignored if Reply-To: is set by mail sender. This is done by isReplyToSelf=true in case (b). As seen in case (c), current code has logic to remove "non true Reply-To-Self". Why isReplyToSelf=true is set when case (b) even though isReplyToSelf=false is set when case(c)? As seen in above (c), even when "same mail address as From: in replied mail" is chosen as "To: mail address", Reply-To: is correctly used as expected. This is because isReplyToSelf=false is set when (c). Proper solution of this bug is: Consider (b) as "Non true Reply-To-Self", as done in (c). Set isReplyToSelf=false if "mail addr in From:" == "only one identity in recipients".

14 test mails are contained in file. "No To: headers with CC: or Delivered-To:" case, "To: non-identity" case are added to original "To: identity(or identities)" case of comment #34. See comment #34 for [Steps to reproduce]. > Note: > - From:, To:(or CC:, or Delivered-To:), Reply-To: is also put in Subject: for ease of test. > - There is no X-Account-Key: in test mail, for ease of test and to avoid confusion. > > Test mails : > > (A) test-type-A : HDR-XX1 (B) test-tyep-B : HDR-XX1-XX2 > From: z1 HDR: XX1 Reply-To: rr From: z1 HDR: XX1, XX2 Reply-To: rr > > Case-1-a : HDR = CC: XX1 = z1 HDR = CC: XX1 = z1 XX2 = z2 > Case-1-b : HDR = CC: XX1 = z2 HDR = CC: XX1 = z2 XX2 = z1 > Case-2-a : HDR = Delivered-To: XX1 = z1 N/A > Case-2-b : HDR = Delivered-To: XX1 = z2 N/A > Case-3-a : HDR = To: XX1 = someone1 HDR = To: XX1 = someone1 XX2 = someone2 > Case-3-b : HDR = To: XX1 = someone2 HDR = To: XX1 = someone2 XX2 = someone1 > Case-4-a : HDR = To: XX1 = z1 HDR = To: XX1 = z1 XX2 = z2 > Case-4-b : HDR = To: XX1 = z2 HDR = To: XX1 = z2 XX2 = z1 > > Case-3-? : no identity in recipients > (for #=1,2,4) > Case-#-a : identity of From: == first identity in recipients > Case-#-b : identity of From: != first identity in recipients > test-type-A : multiple identities(or non-identities) in recipients > test-type-B : only one identitity(or non-identity) in recipients > > Where > HDR = CC:, Delivered-To:, or To: > XX = someone or z > XX1 = z1 or z2, or someone1 or someone2 > XX2 = z2 or z1 > z1 = z1@z.z.z, z2 = z2@z.z.z, > someone1 = someone1@z.z.z, someone2 = someone2@z.z.z > rr = rr@e.r.r > z1@z.z.z, z2@z.z.z : defined as identity > someone1@z.z.z, someone2 : NOT defined as identity If no To: header with CC: or Delivered-To:, phenomenon of "Tb tries to use To: header" is clearly seen than To: case, because Tb can't find To: header. "To: non-identity" case was merely referrence for test of "To: identity" case. However, in the "To: non-identity" case == True Reply-To-Self cases, inconsistent "From: identity selection" was observed with intentional but absolutely-valid / never-impossible identity definition. mail.account.accountN.identities = id33,id32,id31 <= reversed order mail.identity.id31.useremail = z2@z.z.z <= smallest identity number mail.identity.id32.useremail = z1@z.z.z <= From: mail address in test mail mail.identity.id33.useremail = z999@z.z.z <= default identity Even though always "From: z1@z.z.z To: one non-identity or two non-identitities", z2@z.z.z is used in some cases, z999@z.z.z is used in some casess, and z1@z.z.z is used in other cases.

Problems observed by above test cases. (problem-1) Reply-To: in Case-4 (To: identity) From: is set as expected. Reply-To: is not used only when Case-4-a/test-type-A. Reply-To: is used as expected in other Case-4-X/test-type-Y. (problem-2) Reply-To: in Case-1 (no To: header, CC: identity) From: is set as expected in all Case-1-X/test-type-Y However, To: is not set only when Case-1-a/test-type-A. This is same problem as (problem-1). Tb tries to use To:, but To: doesn't exist. (problem-3) Reply-To: in Case-2 (no To: header, Delivered-To: identity) From: is set as expected in all Case-2-X/test-type-Y However, To: is not set only when Case-2-a/test-type-A. This is same problem as (problem-1). Tb tries to use To:, but To: doesn't exist. In Case-3("To: non-ientity" case == True Reply-To-Self), inconsistent "From: identity selection" was observed. intentional identity definition. mail.account.accountN.identities = id33,id32,id31 <= reversed order mail.identity.id31.useremail = z2@z.z.z <= smallest identity number mail.identity.id32.useremail = z1@z.z.z <= smallest identity number mail.identity.id33.useremail = z999@z.z.z <= default identity (problem-4) From: selection by Reply-To-Self is inconsistent. Case-3-a/test-type-A : From: z999@z.z.z To: someone1@z.z.z Case-3-b/test-type-A : From: z999@z.z.z To: someone2@z.z.z Default identity is used as From: Default identity(may be called Primary or Main) == First identity in identity definition for account == First identity number weitten in mail.account.accountN.identities=idA1,idA2, ... Case-3-a/test-type-B : From: z2@z.z.z To: rr@r.r.r Smallest identity number in mail.account.accountN.identities=id33,id32,id31 is used. Case-3-b/test-type-B : From: z1@z.z.z To: someone2@z.z.z, z1@z.z.z Identity of From: in replied mail is used as From: of reply msil. Reply is executed to From: mail address in replied mail.

Sorry, "To: multiple non idtentities" case in prviou verion was "To: a non-identity, an identity(same as From:, or different from From:)" case. So, observed result was never bad. This error in test mails is now corrected. When "To: non-identity(multi or single)", chosen identity for From: was always "default identity", as implemented or designed. This "always default identity" may be a cause of many bug open about symptom of "preset From: is different from user's expectation".

Hi Wada, I'm not shure, that I can follow all of your ideas here ;) But your Mails for the unit tests should also have the same subject: I have a contact form. If a user uses this contact form, I got a mail like this: Subject: [example.com] Contact form From: z1@z.z.z To: z1@z.z.z Reply-To: someone1@z.z.z So I have several mails with the same subject, from and to fields. Only the reply-to is different. Thanks for your work, Mike

(In reply to mike from comment #40) > But your Mails for the unit tests should also have the same subject: Why "same subject" is needed? Required conditions is; (i) From: mail address is identity-X (ii) There is only one identity-Y in recipients(To:, CC:, Delivered-To:. BCC:?) (iii) identity-Y == identity-X (iv) Mail-Reply-To: or Reply-To: exists i.e. If From: is not identity, Reply-To: is correctly used as expected. If there is no identity in recipent(s), or if multiple identities are involved in recipients, Reply-To: is correctly used as expected. If identity-Y != idntity-X, Reply-To: is correctly used as expected. If no Mail-Reply-To: and no Reply-To:, user can't be aware of this bug. > I have a contact form. If a user uses this contact form, I got a mail like this: > Subject: [example.com] Contact form > From: z1@z.z.z > To: z1@z.z.z > Reply-To: someone1@z.z.z If it's "Form", why From: == To:? User needs to change From: to his own mail address, doesn't it? If so, "Form with From: Your-Mail-Address@z.z.z" is better for "Form", isn't it? Order in "From:, Reply-To:, To:" is better for understanding or using as Form, isn't it? If it's passed to your system via Web system instead of via mail system, and if "From: and To:" is merely an indicator of form or keyword or for ease of "processing contact from user", "From: != To: in Form" is a simplest and easiest workaround of this bug. FYI. Similar/relevant to this bug but different problem(perhaps partially same) is already reported for "From:, Sender:, Reply-To:" combination. In the Sender: relivant case, both of problem in From: mail address selection(which of From: or Sender: is used? What is definition of Reply-To-Self?) and problem in To: mail address selection(what is correct To: in reply mail when Reply-To-Self?, and Reply-To: is perhaps ignored as done in this bug) should be resolved. Please be careful if you have plan to use Sender: in template mails.

(In reply to WADA from comment #41) > (In reply to mike from comment #40) > > But your Mails for the unit tests should also have the same subject: > Why "same subject" is needed? I have a similar form to mike although the subjects of mine vary slight, subject lines are in the form: Subject: Cameras Underwater Ltd: %customers question% I see no reason why "same subject" is required since I don't see why this would effect the Reply-to handling. > > Required conditions is; > (i) From: mail address is identity-X > (ii) There is only one identity-Y in recipients(To:, CC:, Delivered-To:. > BCC:?) > (iii) identity-Y == identity-X > (iv) Mail-Reply-To: or Reply-To: exists > i.e. > If From: is not identity, Reply-To: is correctly used as expected. > If there is no identity in recipent(s), or if multiple identities are > involved in recipients, Reply-To: is correctly used as expected. > If identity-Y != idntity-X, Reply-To: is correctly used as expected. > If no Mail-Reply-To: and no Reply-To:, user can't be aware of this bug. This seems correct to me based on what I'm seeing. > > > I have a contact form. If a user uses this contact form, I got a mail like this: > > Subject: [example.com] Contact form > > From: z1@z.z.z > > To: z1@z.z.z > > Reply-To: someone1@z.z.z > If it's "Form", why From: == To:? User needs to change From: to his own mail > address, doesn't it? > If so, "Form with From: Your-Mail-Address@z.z.z" is better for "Form", isn't > it? > Order in "From:, Reply-To:, To:" is better for understanding or using as > Form, isn't it? My form also has From: == To: the reason for this is that a copy of the email is sent to the customer who submitted the question. If the email had the customers email in the From: header it may not arrive in the customers mailbox as it may be rejected by their incoming mail servers as SPAM. By using our own email address in the From: the customers mail server can check the validity of the email since our SPF records confirm that the sending server ( our web server ) is valid to send email for our domain. > If it's passed to your system via Web system instead of via mail system, and > if "From: and To:" is merely an indicator of form or keyword or for ease of > "processing contact from user", "From: != To: in Form" is a simplest and > easiest workaround of this bug. In my case the "From: and To:" are not indicators of the form or keyword for ease of "processing contact from user". The "Subject:" is the indicator. I agree that "From: != To: in Form" should be a work around, I will look at creating a mail alias on our mail server in order to test this and report back on results here. > > FYI. > Similar/relevant to this bug but different problem(perhaps partially same) > is already reported for "From:, Sender:, Reply-To:" combination. In the > Sender: relivant case, both of problem in From: mail address selection(which > of From: or Sender: is used? What is definition of Reply-To-Self?) and > problem in To: mail address selection(what is correct To: in reply mail when > Reply-To-Self?, and Reply-To: is perhaps ignored as done in this bug) should > be resolved. > Please be careful if you have plan to use Sender: in template mails. Thank you for your work on this. Adrian

(In reply to Adrian Portway from comment #42) Good catch! Adrian Portway, thanks a lot for your understanding my intention. I think this kind of discussion is better avoided in bug 932774. I wanted to keep bug 932774 for resolving actual problem only. Because bug opener of this bug already agreed on "this bug's problem is dup of bug 932774", I believe that bug opener of this bug will accept our use of this bug for try&error or helping users(fidning workaround and providing to users about information to work aound problem in his environment), instead of for resolving actual bug in Tb(==flaw in code of Tb).

(In reply to WADA from comment #41) > Why "same subject" is needed? Maybe not yet needed. Just to make sure, that there is no actual / future code in Tb that makes some "guesses" what a user might want ;)

And I tested your workaround now: Using an alias mail address for the "FROM" like contact@example.com works! The FROM and TO are different now and the reply-to will be used again ...

I have also tested the work around and agree with mike@xantiva.de. Using a different address as the "FROM" of the web form ( i.e. using an alias ) works. From: != TO: Reply-to works as expected. Headers from test mail: Return-Path: <website@camerasunderwater.co.uk> X-Original-To: sales@camerasunderwater.co.uk Delivered-To: sales@camerasunderwater.co.uk To: sales@camerasunderwater.co.uk Subject: Cameras Underwater Ltd: Test 3 From: Cameras Underwater Ltd <website@camerasunderwater.co.uk> Reply-To: Adrian Portway <adrian.portway@gmail.com> When user hits reply resulting email is addressed to adrian.portway@gmail.com

Cause of this bug is perhaps in recipients check step in order to detect "mail between identities". (i) From:identity-X, different identity-Y from identity-X is involved in recipients == Non True Reply-To-Self (reply between two different identities) -> isReplyToSelf=false (correct) (ii) From:identity-X, no identity is involved in recipients == True Reply-To-Self -> isReplyToSelf=true (correct) (iii) From:identity-X, identity in recipients is identity-X only Because this case is not (i), considered as (ii), then isReplyToSelf=true is set. (iii) works correctly as expected, as far as Mail-Reply-To: and Reply-To: doesn't exist. However, to support Mail-Reply-To: and Reply-To: correctly in Reply-To-Self feature of Tb, isReplyToSelf=false should be set when condition (iii).

Hi Wada, (In reply to WADA from comment #47) > Cause of this bug is perhaps in recipients check step in order to detect > "mail between identities". > (i) From:identity-X, different identity-Y from identity-X is involved in > recipients > == Non True Reply-To-Self (reply between two different identities) > -> isReplyToSelf=false (correct) > (ii) From:identity-X, no identity is involved in recipients > == True Reply-To-Self > -> isReplyToSelf=true (correct) > (iii) From:identity-X, identity in recipients is identity-X only > Because this case is not (i), considered as (ii), > then isReplyToSelf=true is set. > (iii) works correctly as expected, as far as Mail-Reply-To: and Reply-To: > doesn't exist. > However, to support Mail-Reply-To: and Reply-To: correctly in Reply-To-Self > feature of Tb, isReplyToSelf=false should be set when condition (iii). Your logic seems correct to me, in example (iii) isReplyToSelf=false should be set in order to correctly support addresses in the Mail-Reply-To: and Reply-To: headers.

Not sure i follow the analysis, but i can't reproduce this. If i create a mail From: magnus@example.com To: magnus@example.com Reply-To: foo@example.com ... replying to that mail go to foo@example.com like it should. (magnus@example.com is an email identity of mine) So what am I missing?

Magnus, you seem to understand the problem correctly, and I am at a loss to explain why you can't reproduce it. What version of Thunderbird are you using? I just now reproduced the bug with 24.1.1 for Windows.

I've tried both 24.1.1 and latest nightly builds. On linux, but i wouldn't expect this to be platform dependent. There's likely some other factor we're missing. Is the To-address one of your identities? Do you have one identity, or many?

Magnus, I have reproduced the bug both when the "To:" address is the same as the "From:" address (one of my identities) and when it is something entirely different. In other words, if the "From:" address is one of my identities, then Thunderbird always ignores the "Reply-to:" address and sends the reply to the "To:" address, whether or not it is one of my identities.

Can you reproduce in safe-mode? (Help | Restart with Add-ons disabled)

(In reply to Magnus Melin from comment #51) > I've tried both 24.1.1 and latest nightly builds. On linux, but i wouldn't > expect this to be platform dependent. There's likely some other factor we're > missing. > > Is the To-address one of your identities? Do you have one identity, or many? Hi Magnus, I have had this problem on Linux ( my everyday work machine ) and on staff Windows machines so I don't think the bug is platform dependent. It does seem odd that you don't have the problem. One thing I note is that at least some of us reporting the bug are being sent the original email from a web form, perhaps something about the way our servers produce the email is different from what you are doing to test. I am away from my computer at the moment but will test with Thunderbird in safe mode as soon as I'm able and let you know what happens.

(In reply to Magnus Melin from comment #51) > Is the To-address one of your identities? Do you read comment #47? From:identity, To: == From: => How can To: mail address be not identity? > Do you have one identity, or many? To see phenomenon in "reply from Identity-X to different identity-Y" case, multiple identities are defined by [Steps to reproduce]. However, it's irrevant condition. If "one identity only(defined identity is z1@z.z.z only), problem can be observed on any test mail of "From:z1@z.z.z(only one identity), To: contains z1@z.z.z(contains only one identity)". It's simply "To: in replied mail is used for To: of replied mail because of isReplyToSelf==true". But it looks for user as if "From: in replied mail, instead of Reply-To: in replied mail which is associated to the From:" is used for "To: of replied mail", because of "To: mail address in reply mail" == "From: mail address in replied mail" == z1@z.z.z == identity. (In reply to Magnus Melin from comment #49) > Not sure i follow the analysis, but i can't reproduce this. > If i create a mail > From: magnus@example.com > To: magnus@example.com > Reply-To: foo@example.com > ... replying to that mail go to foo@example.com like it should. > (magnus@example.com is an email identity of mine) > So what am I missing? Do you define mail address in From: of replid mail as identity of assciated account which is deined in X-Account-Key: of the replied mail? If no, did you check with mailnews.reply_to_self_check_all_ident=true instead of false which is default? Have you tried with no add-on(-safe-mode), or with new profile/"Local Folders" only? "Correct identity" add-on perhaps hides this bug as expected. Have you tried attached test mails(no X-Account-Key: for ease of test, and to avoid confusion) with [Steps to reproduce] written in comment #34?

If following replied mail, From: identity-X, To: someone1@z.z.z, (non identity), identity-Y, (identity, different from From:) identity-X (identity, same as From:) Reply-To: rr@r.r.r (identity, or non-identity) following is currently generate by Reply, because isRplyToSelf=true is set and "To: in replied mail" is used for "To: in reply mail" as-is by isReplyToSelf==true. From: identity-X (from From: in replied mail) (a) To: someone1 (from To: in replied mail) (b) To: identity-Y (from To: in replied mail. != From: in replied mail) (c) To: identity-X (from To: in replied mail. == From: in replied mail) This is a variant of this bug. This case is not critically funny, because of "To: != identity-X in From: only. If isReplyToSelf=false is set in this case, following is set by curreｎt logic. From: identity-X (from From: in replied mail) (d) To: rr@r.r.r (from Reply-To: in replied mail) So, if isReplyToSelf=false is set in this case, new problem will be produced. User's expectation may be following in this case. From: identity-X (from From: in replied mail) (a) To: someone1 (from To: in replied mail) (b) To: identity-Y (from To: in replied mail. != From: in replied mail) (c') To: rr@r.r.r (identity-X in To: == From: ---> Reply-To: in replied mail) Following is correct solution? (1) Keep current isRepltToSelf setting logic. (2) Change To: setting logic when isRepltToSelf==true. if(isReplyToSelf){ Use To: header in replied as-is for To: of reply mail ; } => if(isReplyToSelf){ for(mail_addr in To: header of replied mail){ if(mail_addr == From: mail address) Use Mail-Reply-To: or Reply-To: for To: ; else Use mail_addr for To: ; } } I think this is a direct/natual solution of this bug and is applicable to "an identity in To: of reply mail" == "identity of From: of replied mail with Mail-Reply-To:/Reply-To:" case. What is correct "pre-set From:/pre-set To: by Reply" when following conditions are met? - From: mail address in replied mail == an identity-X - the "identity-X in From:" is selected as pre-set From: by Reply - the "identity-X in From:" is contained in "To: of reply mail" which is chosen by Reply - Mail-Reply-To: / Reply-To: is set by mail sender in replied mail How about "pre-set CC: mail address(es)" upon Reply-To-All? No chance that "From: in replied mail(==identity)" is placed in CC: mail addresses which is set by Reply All? If "CC:(or BCC:) by Reply actions", there is no need to use Mail-reply-To:/Reply-To:? How about "auto-CC:/auto-BCC: mail address" which is pre-set upon Reply/Reply-All? What is user's expectation in such cases?

(In reply to WADA from comment #55) I've tried your attached mails without success. Also could not reproduce on windows. Can someone who can reproduce this in safe-mode try to send them selves an email, and set the Reply-To to something else. (Note you can choose Reply-To where you choose To/Cc etc.) If replying to the mail from yourself doesn't reply to the Reply-To address, please save that mail (as .eml) and send it to me, or attach it to this bug.

(In reply to Magnus Melin from comment #57) > (In reply to WADA from comment #55) > I've tried your attached mails without success. Also could not reproduce on windows. With which version of Tb? With -safe-mode of Tb? Reply? Reply-All? If trunk && without "Correct Identiy" add-on, should I check with trunk nightly? (I checked only with Tb 24/without "Correct Identiy" add-on, because my purpose of testing was "problem recreation"/"duplication test" only.) > Can someone who can reproduce this in safe-mode try to send them selves an > email, and set the Reply-To to something else. (Note you can choose Reply-To > where you choose To/Cc etc.) If replying to the mail from yourself doesn't > reply to the Reply-To address, please save that mail (as .eml) and send it > to me, or attach it to this bug. Save following mail in my test mails as .eml file by yourself, please. > From - Sat Sep 14 09:43:36 2013 > X-Mozilla-Status: 0001 > X-Mozilla-Status2: 00000000 > Mozilla-Keys: > Message-ID: <tesr-01-to.528FF887.1070606@z.z.z-001> > Date: Sat, 23 Nov 2013 09:36:23 +0900 > User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 > MIME-Version: 1.0 > Content-Type: text/plain; charset=ISO-8859-1 > From: z1@z.z.z > To: z1@z.z.z > Reply-To: rr@r.r.r > Subject: From: z1@z.z.z > To: z1@z.z.z > Reply-To: rr@r.r.r > > zzz If you can do following correctly, and If Tb 24.1.0 or Tb 24.1.1, I believe you can see problem of this bug. 1. Create new Tb profile, create a dummy POP3 account, with email addr=z1@z.z.z Only one POP3 account(account1/server1) + Local Folders(account2/server2) Only one identity, id1, for z1@z.z.z, which is associated to account1 default account=account1, local folders server=server2 2. Drag&Drop the saved .eml file to thread pane of Inbox of dummy POP3 account (import of .eml file by Drag&Drop) 3. Reply => From: z1@z.z.z To: z1@z.z.z User's normal expectation is "To: rr@r.r.r.r" in reply mail, because "To: z1@z.z.z in reply mail" == "From: z1@z.z.z in replied mail to which Reply-To: rr@r.r.r is associated". Tb's behavior is; because no X-Account-Key: header and relevant account is account1 who has identity, identities of account1(id1 only) is checked. because of mailnews.reply_to_self_check_all_ident=false, (and because account who has associated identity is account1 only in this test,) identities of other accounts is irrelevant to identity selection and identity check. Reply-To-Self case, so isReplyToSelf=true is set. (obviously not "mail from an identity to other different identity". ) (so this is not "mail between identities" nor "reply between identities". ) (therefore, this case is not "Not True-Reply-To-Self" => isReplyToSelf=true) and "identity.id1 for z1@z.z.z in From: of replied mail" is selected for pre-set From: => From: z1@z.z.z is set from selected identity.id1 because isReplyToSelf==true, "To: in replied mail" is used as "To: of reply mail". because used header for "To: of reply mail" by Tb is "To: header in replied mail", "Reply-To: header in replied mail" is irrelevant to "To: header of reply mail" 4. If "To: in replied mail" is changed to CC: or Delivered-To:(no To: header), you can see "From: z1@z.z.z To: blank" by Reply. ("To: blank by Reply" is phenomenon produced by "Tb tries to use To:, but no To:".) These two cases are also contained in my test mails.

(In reply to Magnus Melin from comment #57) > (In reply to WADA from comment #55) > I've tried your attached mails without success. Also could not reproduce on > windows. > > Can someone who can reproduce this in safe-mode try to send them selves an > email, and set the Reply-To to something else. (Note you can choose Reply-To > where you choose To/Cc etc.) If replying to the mail from yourself doesn't > reply to the Reply-To address, please save that mail (as .eml) and send it > to me, or attach it to this bug. Hi Magnus, I have attached an email saved as adpExample.eml. This email was sent from a form on my company's website as per mine and other bug reporters previous comments regarding this and bug #932774 ( which is a duplicate ). I tested the email by replying using Thunderbird 24.1.1 ( 1:24.1.1+build1-0ubuntu0.13.10.1 from Ubuntu saucy-updates run in safe mode ). I'm providing this email as a real world example although I believe WADA's test mail should be an equally good test.

Ok, got it reproduced now. Having multiple identities with same email but different settings (like I do), makes this bug not show!

(In reply to Magnus Melin from comment #61) > Having multiple identities with same email but different settings (like I do), makes this bug not show! Have you read Comment #41? It surely corresponds to "If identity-Y != identity-X" in Comment #41, if "single mail address only in To: header && To: mail address==From: mail address" case. > i.e. (my typo is corrected :-) > If From: is not identity, Reply-To: is correctly used as expected. > If there is no identity in recipient(s), or if multiple identities are > involved in recipients, Reply-To: is correctly used as expected. > If identity-Y != identity-X, Reply-To: is correctly used as expected. > If no Mail-Reply-To: and no Reply-To:, user can't be aware of this bug. I wrote "define identity for z1@.z.z.z and z2@z.z.z". I should have written "define one and only one identity for z1@.z.z.z, and define one and only one identity for z2@z.z.z"... :-) And, I should have clearly isolated "Header: mail-address" in message source, "idN of identity.idN", "identity.idN.username value", "Header: identity" which is derived from header data and identity definition, in explanation or instruction...

Another workaround of this bug was dicovered by Magnus. Two identities, idP and idQ, are defined for MailAddr-A. From: MailAddr-A (=> identity.idP) To: MailAddr-A (=> identity.idQ, idQ != idP) Reply-To: rr@r.r.r (any mail address) This is mail from identity.idP to identity.idQ, so isReplyToSelf=false is set. Because isReplyToSelf==false, Reply-To: is used for To: of reply mail. "From: MailAddr-A" is perhaps set from identity.idQ in recipients. From: MailAddr-A To: rr@r.r.r However, new issue is exposed by the new workaround. Two identities, idP and idQ, are defined for MailAddr-A. From: MailAddr-A (=> first found identity.idP of this account or X-Account-Key:) To: someone1@z.z.z, (non identity) someone2@z.z.z, (non identity) MailAddr-A (=> identity.idQ, idQ != idP) Reply-To: rr@r.r.r (any address. usually other than MailAddr-A, but can be MailAddr-A) Because this is "mail between different identities", "From: MailAddr-A" is set from selected identity(perhaps identity.idQ cotained in recipients), and isReplyToSelf=false is set. Because isReplyToSelf==false, only "To: rr@r.r.r" is generated from Reply-To: by Reply. From: MailAddr-A To: rr@r.r.r This issue is pretty easily reproduced. This is perhaps far different from user's expectation, if he loves Reply-To-Self feature. This is pretty normal for user who thinks "Reply should be sent to From: always". I believe both of following are needed in order to avoid unwanted bug open. - Improve Reply-To: handling in Reply-To-Self feature. - Make Reply-To-Self feature optional. Note: I like Reply-To-Self in many situations because mail to same peoples can be easily created from my mail by simply doing "Reply", but I hate Reply-To-Self in some situations because "To: in reply mail" != "From: in replied mail" :-)

This fixes this issue, which is fallout from bug 932774. For reply-to-self case I also added code to keep the original Reply-To, as that was one of the confusing things trying to figure this issue out. For reply list, there isn't really a reply-to-self case, as we would not have the list header in the local message. Replying to a list message from yourself is almost the same anyways. If you have yourself in auto-cc we can't really detect if it's a reply-to-self or not, so let's just treat that as a normal reply.

For easier review.

For those of us having this issue with mails sent through a website contact form, a work-around appears to be to modify your contact form to use the Sender header for your mail account, then use From for the details of the person sending the message. Then no Reply-To is needed, and TB will address the reply to the From address.

There are no workarounds we'd accept for this crazy bug driving us nuts by constantly replying to ourselves and missing potential customers by not really replying to them but to us?! We are at 24.2.0 and still not fixed. Please fix this in the next release. I wouldn't start modifying many web forms backend code just to accomodate buggy TB, which has been working working fine for years up until 24.0. Please.

Comment 61 is a workaround, but yes, I'd like to have this landed for the next point release.

This is so much of a critical issue for us that we are searching for alternative email client software. Its good to have advice about the work-around, but such a fundamental and critical function as this bug effects surely deserves immediate attention and repair. Our contact and other forms are coded in php and Im not about to go changing core code to workaround a TB bug. Anyway, Ive winged enough, Im wondering if there is a planned update that includes the bug-fix before I spent days researching an alternative client.

(In reply to hobo jo from comment #70) > This is so much of a critical issue for us that we are searching for > alternative email client software. Are you looking for Tb side workaround? If so, have you read thru this bug well before posting comment? As written in Comment #63, "adding second identity for mail address in From:==To:==Identity of Tb" is an already discovered workaround, if "new issue" in the comment is not critical problem in your environment. Or mail client which is used by your customers, which is supported by your system? If so, why "preset From:==To: in in your form" === Identity in Tb can occur in customer's Tb? You are forcing customers to define the From:To: mail address in customer's Tb? > Im not about to go changing core code to workaround a TB bug. I believe From:==To: is not so well design as a "mail form", because this is "mail form" which is sent as actual e-mail. It's a good chance to transfer to well-designed mail form, I think. Is "From:==To:==Identity of Tb in replied mail or form" a keyword or identifier of something in your application? Is "From: a, To: x of reply mail to following mail" a keyword or identifier of something in your application? From: a, To: a, Reply-To: x

Please don't try to diminish the effects of this bug. Many users were/are just set up this way for years. I must admit TB has no alternatives even in the shareware area. That's why this can have big impact on users. Switching clients can be a big PITA. I also think this deserves its own urgent x0.1 fix asap. No workaround proposed here is close to elegant. Keeping two identical identities?! This has the potential to confuse even more.

(In reply to Teodor from comment #72) Do you mean this bug is regression by Tb 24? i.e. (Didn't occur in Tb 17) I thought, started to use "From:==To:", started to define "mail address in From:==To:" as identity, started to use Reply-To:, ...,　then this bug was exposed. i.e. not new problem. > Keeping two identical identities?! "Multiple identities for an mail address" itself is pretty normal use of identity in Tb. - different "Name" part for same addr, for examle, English name, Japanese name - different SMTP server choice in case of server down - different SMTP server for home use and office use And, ordinal people is not so confused merely by "two identities for same mail address". I believe ordinal people sets at least "different name in different identity for same addr" in order to avoid his confusion, if it's done as "workaround of such critical problem". > No workaround proposed here is close to elegant. Even if so, if this bug is so critical for you, I believe that "you should do first" is never "write complaints to bug at B.M.O where to resolve bug or to help resolving bug". It's "avoid so critical problem for you by already found workaround(s)".

Yes, I admit, this was a complaint, I'm sorry. I wanted to point out that this is a serious bug, and because we don't update TB regularly, it started doing this just recently as we updated to 24.2.0. Then I found this bug report where it has not been treated as being serious to an extent. I'm being told elsewhere that this is the main place where bugs are taken seriously AND by developers. Complaining in other places proved to be pointless, and some bugs persist for many months, I'm a patient person otherwise. Many things can be called "normal" for different users. In this case it is a workaround and involves work on our side that can confuse users even more, that's it. No need to list use-cases where multiple identities are sensible. Multiple identical identities can have other implications you are not aware of right now, so no need to discuss this. It's critical enough for me/us. I'll hope for a quick fix to come soon. Thanks.

Bugzilla is for discussing specific bugs and their fixes; please can those who wish to discuss other issues, such as the priorities of the developers, take their discussions to the appropriate mailing lists? Everyone CC-ed to this bug is free to express their desire for an urgent fix by a) voting and b) hiring someone to work on it for them. Beyond that, time is not a free resource, so please let's all respect that developers whom you or I have not personally hired (and I am not a Thunderbird or Mozilla developer) are free to make their own choices, and let's express that respect by letting them do so.

Comment on attachment 8343008 [details] [diff] [review] proposed fix Looks good. r=Standard8. Given the visibility of this issues, please land on the CLOSED TREE with a=Standard8. Also land on Aurora as well. Once nightlies are generated, please post links on this bug so that folks can test them before the next esr builds are generated.

https://hg.mozilla.org/comm-central/rev/0a5498810947 -> FIXED on trunk Do you want to land it on aurora for me? (Haven't tried that yet.)

Nightlies for now out - http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-central/thunderbird-29.0a1.en-US.win64-x86_64.installer.exe - http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-central/thunderbird-29.0a1.en-US.linux-i686.tar.bz2 - http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-central/thunderbird-29.0a1.en-US.mac.dmg

Comment on attachment 8343008 [details] [diff] [review] proposed fix Assuming we've not heard any issues from this. I think we should take this on esr for the next cycle given the significance.

BUG IS NOT FIXED NOR CLOSED in ff 52.2.1 the problem is still present

(In reply to paultt from comment #83) > BUG IS NOT FIXED NOR CLOSED > > in ff 52.2.1 the problem is still present to be more precise, it is still present, when replying to lists... sorry for my lack of informations it seems to work correctly only with simple accounts, i'm attaching a sample email, which makes thunderbird to not work correctly: From - Mon Jul 24 16:12:15 2017 X-Account-Key: account5 X-UIDL: 0001419e43de3828 X-Mozilla-Status: 0003 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: <linux-bounces@list.bilug.it> Delivered-To: exampler_list_user@bilug.it To: Mailing List del Biella Linux User group <linux@list.bilug.it> From: EXAMPLE USER <example_sender_user@bilug.it> Message-ID: <444429f1-0d8e-1111-64c5-bc5cbasdfasc75@bilug.it> Date: Mon, 24 Jul 2017 16:10:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Language: it-IT X-AV-Checked: ClamAV Subject: [Linux-Biella] test bug reply to list X-BeenThere: linux@list.bilug.it X-Mailman-Version: 2.1.15 Precedence: list Reply-To: linux@list.bilug.it List-Id: Mailing List del Biella Linux User group <linux.list.bilug.it> List-Unsubscribe: <https://list.bilug.it/options/linux>, <mailto:linux-request@list.bilug.it?subject=unsubscribe> List-Archive: <http://list.bilug.it/pipermail/linux/> List-Post: <mailto:linux@list.bilug.it> List-Help: <mailto:linux-request@list.bilug.it?subject=help> List-Subscribe: <https://list.bilug.it/listinfo/linux>, <mailto:linux-request@list.bilug.it?subject=subscribe> Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Errors-To: linux-bounces@list.bilug.it Sender: "Linux" <linux-bounces@list.bilug.it> X-AV-Checked: ClamAV -- = _______________________________________________ Linux mailing list Linux@list.bilug.it https://list.bilug.it/listinfo/linux

This bug is present in a beand new installation of Thunderbird I made yesterday too. it is for normal emails(=any email addresses are missing not only lists or anything else) Version 52.2.1 on a Windows 10 machine. All what is said above is present no need to replicate it.

This bug is existent as of Thunderbird 52.2.1 (32 bit) in Windows 10. TBird is ignoring the Reply-To: header on mailing list emails and directing the response back to the individual sender in the From: field. 90% of the time this is undesirable. I do not know if the sender being in my address book or not is relevant.

Please file new bugs if there are issues in the current versions of Thunderbird. We fixed something here, several years ago, it may or may not be exactly the same as what you are seeing, it may have been regressed by something else. In any case, commenting on long-closed bugs will generally not get the issue resolved.

Please see https://bugzilla.mozilla.org/show_bug.cgi?id=1385839