Hide Forgot
Description of problem: Hit reply-all on an upstream mail list email, check the list of recipients and see that all of them are there, write email, hit send, wait for email to show up in list. On random occasions, it never appears. Go to sent mail folder, and email now has a different list of recipients than what it did when you hit send. Version-Release number of selected component (if applicable): 45.0-4.fc23 How reproducible: Random, but has bit me at least 7 or 8 times today. Steps to Reproduce: 1. Hit reply-all 2. Hit send 3. Check sent folder Actual results: Email send completes successfully Expected results: All recipients should get an email or I should get an error on send. It should not send only a portion and complete as though there was success. Additional info: Trying to track this down, I checked my Error Console. There were too many messages to sort though from the beginning of time, so I cleared the console and did a few more emails. Once I had one that I could confirm had not gone to all recipients, I checked the Error Console again, and the timestamp of when I sent the email with partial recipients and this error message were close enough to be considered at the same time, so this is likely what is causing the recipients to get dropped silently: Timestamp: 05/25/2016 04:07:57 PM Error: DEPRECATION WARNING: Encoding to non-UTF-8 values is obsolete You may find more details about this deprecation at: http://bugzilla.mozilla.org/show_bug.cgi?id=790855 resource://gre/components/mimeJSComponents.js 438 MimeConverter.prototype.encodeMimePartIIStr_UTF8 chrome://messenger/content/messengercompose/MsgComposeCommands.js 2849 GenericSendMessage chrome://messenger/content/messengercompose/MsgComposeCommands.js 2930 SendMessage chrome://messenger/content/messengercompose/MsgComposeCommands.js 590 defaultController.commands.cmd_sendButton.doCommand chrome://messenger/content/messengercompose/MsgComposeCommands.js 762 defaultController.doCommand chrome://global/content/globalOverlay.js 100 goDoCommand chrome://messenger/content/messengercompose/messengercompose.xul 1 oncommand Source File: resource://gre/modules/Deprecated.jsm Line: 79
Is it reproducable with particular message? Could you attach affected message?
There isn't a particular message that I'm aware of. However, here is another clue. This is an email I expected to go to the list, and it didn't. The recipient (who is aware of my mailer problems and has already been discussing things with me), noticed that my Cc: list didn't look right. In particular, once he got it, the Cc: list had a funny entry, so he sent me this email: Doug, I think the problem with the recipient list may be your mailer bug. Note your reply only went to me and Dean. I added the list back in mine when I noticed it doing that funky thing with the CC list. Here is a snippet from the header of your reply: . . Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5D99480099; Thu, 26 May 2016 16:17:18 +0000 (UTC) Received: from linux-ws.xsintricity.com (ovpn-116-44.rdu2.redhat.com [10.10.116.44]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u4QGHH63016623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 May 2016 12:17:18 -0400 Subject: Re: [PATCH 07/10] IB/hfi1: Add a retry for the first-time QSFP access To: Dennis Dalessandro <dennis.dalessandro@intel.com> References: <20160524194746.19706.42976.stgit@scvm10.sc.intel.com> <20160524195052.19706.43009.stgit@scvm10.sc.intel.com> CC: "linux-rdma@vger.kernel.org Dean Luick" <dean.luick@intel.com> <--- HERE From: Doug Ledford <dledford@redhat.com> Openpgp: id=AE6B1BDA122B23B4265B1274B826A3330E572FDD; url=pgp.mit.edu X-Enigmail-Draft-Status: N1110 Organization: Red Hat, Inc. Message-ID: <6395227d-617c-bd70-2822-6b53843f8611@redhat.com> Date: Thu, 26 May 2016 12:17:16 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20160524195052.19706.43009.stgit@scvm10.sc.intel.com> So I went to my sent folder, found that email, and the email display only Dean on the Cc list. When I moused over Dean's name, it showed his email address. So, it seems that the outgoing recipient is being concatenated with the list address in some cases, and when it happens, the display name is used to display the address so I don't see the concatenation unless I look at the source of the sent message. I have two machines I send email from, one Linux->Thunderbird + CardBook for CardDav server access, the other Windows->Thunderbird, no CardBook extension. It might be just my linux machine causing the problems and it might be a new incompatibility between CardDAV and Thunderbird as I think F23 *just* went to 45.0 (or at least I just got around to installing that particular update) and this problem just started.
Thanks for the info. There can be error in any addon (like CardBook). Please try to disable them if possible and check if this issue will reappear.
This is definitely related to the CardDAV addon. I managed to get an email where both of the addresses were failing the CardDAV check, so when I clicked send it would remove both addresses silently and I would get an error that there are no recipients. I saved the message to Drafts, then restart TB with CardDAV disabled, and the same message would then send. The issue can be predicted somewhat via CardDAV's address autofill behavior. If the address in the To: or Cc: is in all red, as you would expect for an unknown address, but it really should be known by CardDAV, then those are the ones that seem to get removed during send.
Since this is cause by an addon, I'm closing this bug out.