Replies not honoring reply-to: header



Message Compose Window
4 years ago
2 months ago


(Reporter: TAG, Unassigned)


24 Branch
Windows 7

Firefox Tracking Flags

(Not tracked)




4 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release)
Build ID: 20130910160258

Steps to reproduce:

Upgraded from 17.0.8 to 24.0 (two separate computers)
Hit reply to an email from our ticketing system that has a reply-to: header, but the recipient was set to the To: header.

Went to another system and tried with 17.0.8 and it worked fine.  Upgraded to 24.0 and had the same problem.

Actual results:


Return-Path: <>
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on
X-Spam-Status: No, score=-4.1 required=4.5 tests=AWL,FROM_CS_UTAH,FROM_UTAH,
	RP_MATCHES_RCVD autolearn=ham version=3.3.2
Received: from (localhost [])
	by (Postfix) with ESMTP id 509B3650123;
	Fri, 20 Sep 2013 10:43:15 -0600 (MDT)
Received: from (localhost [])
	by (Postfix) with ESMTP;
	Fri, 20 Sep 2013 10:43:15 -0600 (MDT)
Received: from (localhost [])
	by (Postfix) with ESMTP id 676916500D0;
	Fri, 20 Sep 2013 10:43:13 -0600 (MDT)
Received: from ( [])
	by (Postfix) with ESMTP;
	Fri, 20 Sep 2013 10:43:13 -0600 (MDT)
Received: by (Postfix, from userid 30)
	id 4F6298C05C; Fri, 20 Sep 2013 10:43:13 -0600 (MDT)
MIME-Version: 1.0
In-Reply-To: <>
X-Mailer: Perl5 Mail::Internet v1.60
References: <> <>
Content-Type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
Managed-BY: RT 3.4.4 (
Subject: [ #17665] Windows Activation on DSLWIN machines...
RT-Ticket: #17665
Message-Id: <>
Precedence: bulk
Content-Transfer-Encoding: 8bit
From: "XXX via RT" <>
Date: Fri, 20 Sep 2013 10:43:13 -0600 (MDT)
X-Mailman-Version: 2.1.7
List-Id: Resource Tracker Internal  List <>
List-Unsubscribe: <>, 
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>,

Mail sent to

Expected results:

Mail should be sent to (Partially redacted)

Comment 1

4 years ago
After replying to more emails, sometimes the To: header is blank, other times it has (remove XXX), and other times it has what was in the To: header.  Never had this issue before upgrading to 24.0.

Comment 2

4 years ago
this was noticed before in bug 912683

Comment 3

4 years ago
Surprised this isn't getting more attention.  In my case, when customers try to contact us through a form on our website, it gets mailed to sales@...  This is a forwarding address that goes to a couple of people include myself.

Clicking Reply ends up replaying to sales@...  It does not honor the Reply-To: header which happens to have the customer's email in it.

Comment 4

4 years ago
It appears to me that the Reply-To header is ignored when the From address matches one of my accounts. Otherwise the Reply-To is used.

We get email from our Web site for various reasons, including support requests. In such cases the headers are like this:

From: info@company.example
To: support@company.example
Reply-To: customer@customer-domain.example

I have <info@company.example> set up as one of my accounts, but not <support@company.example>.

As of TB 24, if I click Reply on such a message, the To field is set to <support@company.example> instead of <customer@customer-domain.example>.

It's as if TB thinks that this was a copy-to-self message because the From address matches one of my accounts. It's behaving as if I were replying to a message in my Sent folder. In this case, however, the message is sitting in my inbox.
Same problem as bug 933555?
If different, what is diference of your problem from that bug? (not original case of that bug only. any case referred or found in that bug)

Comment 6

4 years ago
The difference is that this bug was filed a month before that bug, so it'd be hard to refer to it since it didn't exist.  However, it would appear to be the same bug and they could probably be merged.
(In reply to tag-bugzilla from comment #6)
> The difference is that this bug was filed a month before that bug, so it'd
> be hard to refer to it since it didn't exist.  However, it would appear to
> be the same bug and they could probably be merged.

Actually same problem as bug 933555?

Your case :
 Replied maii :   
  From: abc@a.a.a  :  This is identity in your Tb defintion, according to your explanation.
  Reply-To: def@d.d.d  :  "Ientity in your Tb defintion or not" is not described by you.
  To:       ghi@g.g.g  :  This is never identity in your Tb defintion.
In this case, this mail is "From: abc@a.a.a which is your identity-X " to "To: ghi@g.g.g which is not your identiy".
So, in reply mail, "pre-set From: == abc@a.a.a which is a your idetity" is pretty normal and "pre-set To: == ghi@g.g.g" is pretty normal, if "Reply-To-Self featute of Tb" is applied.

What is your expectation or your request?
Even when "From: is your identity but To: is not your identity in replied mail", "To: of reply mail" should be "Reply-To: mail address in replied mail"?
What is your expectatin on "pre-filled From;/To: in reply mail"?

Comment 8

4 years ago
My expectation is that that To: header in a reply is filled out with the value of the Reply-To: header.  It is not.  It is set to one of three values.  1) From: header 2) do-not-reply 3) left blank.  I don't know what causes it to pick which of the 3 values.  It is consistent within an email, but as I reply to various messages, it "randomly" sets the To: header to one of the aforementioned three options. 

I tried 28a2 (Windows) (the 27 beta download link is broken) and it is still broken.  The To: line is as above and it just adds a Reply-To: header matching the header in the message you received.
(In reply to TAG from comment #8)
> My expectation is that that To: header in a reply is filled out with the
> value of the Reply-To: header.  It is not.

What is your expectation on pre-set "From:" of reply mail for following mail?
 Replied maii :   
  From: abc@a.a.a  :  This is identity in your Tb defintion, according to your explanation.
  Reply-To: def@d.d.d  :  "Ientity in your Tb defintion or not" is not described by you.
  To:       ghi@g.g.g  :  This is never identity in your Tb defintion.
If "From: abc@a.a.a" is chosen as pre-set "From:" of reply mail, pre-set "To: ghi@g.g.g" of reply mail is pretty natual for reply mail, isn't it?
Why should "To: def@d.d.d" be set enen though reply mail is "from abc@a.a.a to ghi@g.g.g"?
Mening of "Reply-To: def@d.d.d in replied mail" is "reply to def@d.d.d instead of abc@a.a.a if you want to reply to abc@a.a.a which is set in From: of replied mail", isn't it?

Comment 10

4 years ago
Maybe I could understand what you want to say if there where less spelling mistakes - and I'm not a native English speaker myself.

But if a "Reply-To" was given, it should be honored by a Reply, as well as a Reply To All - that is: the reply will got to def@d.d.d.

If there was no Reply-To, a Reply will go the the From address abc@a.a.a.

If you want a Reply To All and no Reply To is given, then the Reply would be addressed To/Cc: abc@a.a.a and ghi@g.g.g. I'd have to check whether any RfC would specifiy whether to use ghi@g.g.g as a second To or as a Cc.

And if Reply-To was given, a Reply To All would go to def@d.d.d and to ghi@g.g.g. Further thoughts would be required whether abc@a.a.a should be included - I'd say no, the Reply-To does override the original From.

The TB version in question does not honor a Reply-To header as it should do.
Do you still consider this to be the same as bug 912683
Flags: needinfo?(traut)

Comment 12

6 months ago
Hard to say now. Thunderbird 45 is ok, as were the latest versions for some time now.

What I consider as a minor bug: Reply-To is always respected, always, always. 

But from my daily use I'd want that my own action on "Reply to All" (Cmd-Shift R) should not use the Reply-To only, but really All, from
* Reply-To
* From
* To
* Cc

Currently it does use Reply-To only, both for the command Reply and Reply to All. So there is no benefit from the Reply to All command here.

However, this would be a bug (or wish) of its own, wouldn't it?
Flags: needinfo?(traut)

Comment 13

3 months ago
FWIW, I just found out that ThunderBird 52.1.1 (Linux 64-bit) ignores the Reply-To header. I subscribe to a couple of lists where Reply-To is always set to the list address. Hitting "Reply" on any message from these lists will in fact reply to the original sender, disregarding the Reply-to header entirely.
"Reply to List" works as expected so I'm going to use that as a workaround.
Not sure if this warrants opening a new bug, the symptoms are exactly the same so I thought I'd update this one first.

Comment 14

3 months ago
I'm experiencing the same behavior with (Windows 32bit).

Comment 15

3 months ago
(In reply to David Gibbs from comment #14)
> I'm experiencing the same behavior with (Windows 32bit).

Sorry, make that 52.1.1 :(

Comment 16

2 months ago
See also Bug 933555

Can we reopen these bugs.  This is a pain in the butt.  I have a support mailing list which is configured correctly to set the Reply-to header to: LIST and sender, so all email goes both to the list and also to the original sender.  The List, so other support volunteers know the thread is being answered, and the sender because they are not subscribed as a volunteer on the support list-- only a user who wants support.

Last version of Thunderbird Smart Reply button has:

"Reply List" (default, but I'd rather Reply-to be the default if it is included as a header) which replies only to the list;
"Reply All" which sends to everyone, including the list TWICE because an alias 'support@...' was used by the original sender which ended up on 'company-support@...' list.
"Reply" which only goes to the sender.

No choices honor the Reply-to header.  Please fix this regression.

Thank you for a great email client!
bug 933555 was an issue fixed long ago and will not be reopened. For unresolved issues, this current bug  report or  bug 912683 should suffice. If they do not match your issue then please open a new bug report

Comment 18

2 months ago
TB 52.2.1 (32-bit), Win 10

I can confirm the problem with replying to lists. I've been using several google groups for years. All have set "To the entire group" in their Settings > Email options > Post replies. When I pressed Reply in TB, the To field was correctly set to the group address. Now, an incorrect address taken from the original From field is used. It started about a month ago.

The email from the group seems to contain all needed headers:
From: <>
To: <>
Precedence: list
Mailing-list: list; contact

When I press Reply on this email, the To is set to instead of expected

On the other hand, the Reply-To field is not ignored for emails that don't come from a list. If I receive the following:
From: <>
To: <my@email.address>

Pressing the Reply button sets the correct receiver -

It seems that only mailing lists cause the problem. You can create a google group to reproduce the issue.

Comment 19

2 months ago
One more note. This is not caused by any extension. I disabled all my extensions and the issue was still there.

Comment 20

2 months ago
The bug I filed for this has never been fixed. I'm currently using 52.2.1 and can reproduce it at will.  This has been the case in every version since I filed this bug years ago.  I gave up on it ever being fixed.

To repeat you have an email with a Reply-To: header set (in our case from a mailman list that is part of our ticketing system that sets it to support@[redacted], but the list is do-not-reply@[redacted].  If you have support@[redacted] as one of your identities then the Reply-To: header is not used.  It instead sets a Reply-To: header to support@[redacted], but has a To: header that is either "randomly" the list, do-not-reply@[redacted] in our case, or the sender of the email. 

So my workaround is that when I need to send email from support@, I create the identity and send the email, then delete the identity.  As soon as the identity is deleted, then the Reply-To: header works as you'd expect.  This is a PITA, but luckily I don't have to send out email that often as support@.

Still would be nice if it got fixed.

Comment 21

2 months ago
These latest issues with reply-to on mailing lists are currently in bug 1309486. There have been a lot of duplicate reports of this issue, but if you want it fixed then I'd suggest contributing to the now-primary bug report for it.
You need to log in before you can comment on or make changes to this bug.