Open Bug 1076964 Opened 6 years ago Updated 5 years ago
Wrong 'From:' address selected for Reply to listserver
. Identity issue?
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:32.0) Gecko/20100101 Firefox/32.0 Build ID: 20140923175406 Steps to reproduce: Issue began with update to 31.1.2. 'Reply' or 'Reply All' to email from various listservers. Replying to other emails is unaffected. Not all listservers trigger this misbehavior. No consistency found among listserver product: some Mailman lists do, others don't. Some LISTSERV lists do, others don't. If a particular listserver list exhibits the failure, it does is consistently. Many examples can be provided on request. One failing email has the following headers: From - Wed Oct 01 07:33:16 2014 X-Account-Key: account8 X-UIDL: UID88792-1329907048 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Envelope-to: firstname.lastname@example.org Received: from ... by ... with ... for email@example.com; Tue, 30 Sep 2014 21:41:54 -0400 X-Mailman-Version: 2.1.18-1 Here are some config settings: mail.accountmanager.accounts;account1,account3,account7,account12,account4,account8 mail.accountmanager.defaultaccount;account8 Full config gladly supplied on request. Actual results: 'From:' field is populated with the wrong Identity, which is associated with a different email address. (Therefore the reply is rejected by the listserver as "not subscribed".) The incorrect Identity is: Chip Davis <firstname.lastname@example.org> mail.account.account3.identities;id5 mail.identity.id5.fullName;Chip Davis mail.identity.id5.useremail;email@example.com mail.identity.id5.valid;true Expected results: The correct Identity should be: Chip Davis <firstname.lastname@example.org> mail.account.account8.identities;id18,id20,id23,id24,id8 mail.identity.id18.fullName;Chip Davis mail.identity.id18.useremail;email@example.com mail.identity.id18.valid;true
I guess the To: is not set -> tb doesn't know what identity to choose. We do use the Delivered-To header if that is set - which it probably is for some lists, and some not. Hence the difference.
(In reply to Magnus Melin from comment #1) > I guess the To: is not set -> tb doesn't know what identity to choose. > We do use the Delivered-To header if that is set - which it probably is for > some lists, and some not. Hence the difference. I didn't think anyone would appreciate it if I included the entire set of (mostly irrelevant) headers in the problem description. Of course the 'To:' is set, but it is not guaranteed to contain the recipient's email address in the first place. And as it simply points to the listserver, it is not probative: To: "firstname.lastname@example.org" <email@example.com> If TB was depending on the 'To:' header to determine the proper 'From:' address to use in a reply, it would have been exhibiting this (mis)behavior before 31.1.2. I suspect that TB has used the 'Envelope-to:' header (which DOES contain the delivery address) to figure out the recipient's email address. For some reason and under certain circumstances, this seems to be broken. I have attached the full headers of an example email where TB put the wrong 'From:' identity in a 'Reply' compose.
I don't think envelope-to was ever used. FWIW, the code is here: http://mxr.mozilla.org/comm-central/source/mail/base/content/mailCommands.js#110
OK, let's take another tack: Q1: Who put the header 'X-Account-Key: account8' in the file? Q2: Who ignored it and used a different account for the Reply? Q3: Why was this changed? It DID NOT do this prior to the upgrade to TB 31.1.2. One new datapoint: this (mis)behavior is not confined to listservers. I just saw it with a reply to an email sent 'To: undisclosed-recipients:;'.
Thunderbird sets the X-Account-Key when the message is downloaded from the POP server. Of course it's not supposed to be ignored.
Are you using a global inbox or not? (Or not==every pop server has its own Inbox.)
Because I can't find a definitive description of "Global Inbox", I will report that "Tools>Account Settings>Server Settings>Advanced Server Settings>Inbox for different account" is set to "Local Folders" for all my accounts, all of which are POP. I just found [Meta]Bug 699681 and cross-posted there. Feel free to link if appropriate.
As others have said... not just mailing lists, but also messages that are BC'd. In the past if a message was B'Cd to me Thunderbird would put the appropriate address in the "from" line if it was set up in the account. Since the last upgrade it's been putting the main account address - so it's obviously no longer looking in the right place. Here, as an example, is an email that was BC'd to one of my additional addresses today (I've replaced the real address by "additional-address@mydomain". When I replied to hit my main address appeared in the "from" line, and I had to manually select the correct address from the pull-down menu. Received: from Postfix-filter-42a77884ce2a0a03efc6bb50a6dcdb21 (localhost.localdomain [127.0.0.1]) by smtp-in-78.livemail.co.uk (Postfix) with SMTP id E4E39D8211 for <additional-address@mydomain>; Wed, 8 Oct 2014 13:00:08 +0100 (BST) Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [126.96.36.199]) by smtp-in-78.livemail.co.uk (Postfix) with ESMTP id 2B7CED8211 for <additional-address@mydomain>; Wed, 8 Oct 2014 13:00:05 +0100 (BST) Received: by mail-la0-f48.google.com with SMTP id gi9so8141315lab.7 for <additional-address@mydomain>; Wed, 08 Oct 2014 05:00:05 -0700 (PDT)
Component: Untriaged → Message Compose Window
Summary: Wrong 'From:' address selected for Reply to listserver → Wrong 'From:' address selected for Reply to listserver. Identity issue?
Issue reported by Thunderbird user in support forum. I'm reporting on behalf of: https://support.mozilla.org/en-US/questions/1047126?utm_campaign=questions-reply&utm_medium=email&utm_source=notification Linux using TB 31.4.0 Pop mail accounts set up as Global Inbox(Localfolders) Receives emails from subscribed mailing lists. Emails are received into Local Folders Inbox and assigned the correct X-Account-Key header for the pop mail account.eg: X-Account-Key: account3 In email source the 'Delivered-TO' header is not this persons email address as they are on a subscribed mailinglist. eg: Delivered-To: firstname.lastname@example.org To: Python-Win32 List <email@example.com> When person selects to 'Reply to list': TB correctly, cannot use the 'Delivered-to' header data. So it would be expected to use the 'X-account-key' - account3 email address in FROM field. However, this is not being found because the default mail account - account2 email address is being inserted into the FROM field.
On Thunderbird 31.7.0 the problem happens again. When answering to mailing list, my first identity is always used (and should not be since I subscribed and received mails via another identity).
Hi, is there a time-line for this bug ?
May be I (Thb. 38.2.0, Win 7,64) have the same problem. I get mails from various list server (LibreOffice, Luga.at) and if I press "Reply to List" or just "Reply" Thunderbird does not use my email-address under witch I have got the emails from the list but chooses an address from my second account as From and the first of my email addresses of my first account. Of course my email address under which I get the list-emails cannot be found in the To field but it is mentioned several times in the email header even Envelope-To and it is the only email address that belongs to me. I really would appreciate if this can be solved sooner than later as a solution doesn't look to complicated. Thanks for your effort Gooly
I have probably the same or a similar issue. When I use the 'Reply List' button, the From field in the email looks correct. But the message get rejected by the email list with this message: "Your posting to this list has been rejected, because you are not subscribed. Only subscribed members can post (be sure to use the same address in your subscription and to send mails from)." And this return message is indeed delivered to another account as the one that was in the From field when sending the email.
Regarding comment #14: I found out that the described behavior was caused by using smtp.gmail.com as the outgoing SMTP server. Apparently using Google for SMTP will replace the from address with your gmail address.
You need to log in before you can comment on or make changes to this bug.