User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0 Build ID: 20160916101415 Steps to reproduce: I use the add-on "Use BCC Instead" but the problem also occurs if I manually use BCC myself. I sent messages to multiple BCC addresses. (Thunderbird 45.2.0) Actual results: The "Envelope-to" field in the header shows "all" of the recipients addresses, making BCC totally ineffective. Expected results: Individual copies of the message should have been sent; one for each BCC addressee, plus one for any "To" or "CC" entries fi they exist.
RFC 5322 has this to say about BCC: " The "Bcc:" field (where the "Bcc" means "Blind Carbon Copy") contains addresses of recipients of the message whose addresses are not to be revealed to other recipients of the message. There are three ways in which the "Bcc:" field is used. In the first case, when a message containing a "Bcc:" field is prepared to be sent, the "Bcc:" line is removed even though all of the recipients (including those specified in the "Bcc:" field) are sent a copy of the message. In the second case, recipients specified in the "To:" and "Cc:" lines each are sent a copy of the message with the "Bcc:" line removed as above, but the recipients on the "Bcc:" line get a separate copy of the message containing a "Bcc:" line. (When there are multiple recipient addresses in the "Bcc:" field, some implementations actually send a separate copy of the message to each recipient with a "Bcc:" containing only the address of that particular recipient.) Finally, since a "Bcc:" field may contain no addresses, a "Bcc:" field can be sent without any addresses indicating to the recipients that blind copies were sent to someone. Which method to use with "Bcc:" fields is implementation dependent, but refer to the "Security Considerations" section of this document for a discussion of each." Thunderbird currently implements the first case above. I believe you are requesting that we implement the second case instead.
Thanks for response, Kent, Actually, the problem I am seeing happens for both of your examples 1 and 2. The problem is that there is an "Envelope-to" line in the header that shows all of the recipients, even the Bcc ones. BTW, I tried GMail, and the same error occurred, but when I tried HotMail, it worked properly.
For as much as I know, TB doesn't add the "Envelope-to" header, this is added by the MTA at the mail provider. I did an experiment and sent a message to person1, BCC to person2 and person3. Looking at the message received by person2, it has "Envelope-to person2@..." added. No reference to person3 in that e-mail. So if it doesn't work for Gmail, complain to Google.
I may not have made it clear in the first note. It fails in Thunderbird, which is why I entered the bug report. It was only on subsequent testing that I found it also failed in GMail but not in HotMail. The fact that it works in HotMail should indicate that it isn't anything related to my ISP. I have seen other accounts that report the same tning: TBird and GMail both fail, but HotMail doesn't. Also, someone suggested using IncrediMail which works, but I treat that as just something "cute" because it is missing some things a good email program like TBird has.
(In reply to jeth from comment #4) > It fails in Thunderbird, which is why I entered the bug report. As I said, TB doesn't add the header, your mail provider does. I tested with my mail provider and you can read the result in comment #3. The Envelope-to header only contains the recipient that receives the message.
Envelope-To is not a header that is being inserted by Thunderbird, it is being inserted by your email service provider. My provider (fastmail) does not insert this header, and IMHO it is a bad idea for your provider to be inserting the full header. From Thunderbird's perspective, I am under the assumption that when the email is being sent, it is using a single email for all recipients, and that would include the BCC recipients, so the TO in the ENVELOPE includes BCC (this is the first case) (this is part of the SMTP protocol, not part of the email headers). The solution to this is to send a separate email for each BCC recipient, so that the envelope TOs for the emails sent to the non-BCC recipients do not include the BCC recipients, and each BCC recipient gets a separate email (which is case 2). The important thing to remember is that the people who receive the email are determined by the TOs in the envelope in the SMTP protocol, but what shows in the email are the various headers (To, From, CC, etc.) that are part of the message itself. Yes this is confusing. So I dispute your comment 2 both in the idea that both case 1 and case 2 would have the issue, and that one is "correct" and the other is different. The current method is "correct" it is just not what you want for your case.
Jorg, INVALID is not quite right since the OP has a legitimate request for us to switch to single message sending for BCCs to prevent what the OP is seeing. If we believed in BCC security that would be a more appropriate thing to to, though it increases the internet traffic and so there is a tradeoff.
From what I saw elsewhere, some people consider the RFC 5322 spec unclear, but I'm not sure I can figure out why. Here's what it says: ================= The "Bcc:" field (where the "Bcc" means "Blind Carbon Copy") contains addresses of recipients of the message whose addresses are not to be revealed to other recipients of the message. There are three ways in which the "Bcc:" field is used. In the first case, when a message containing a "Bcc:" field is prepared to be sent, the "Bcc:" line is removed even though all of the recipients (including those specified in the "Bcc:" field) are sent a copy of the message. In the second case, recipients specified in the "To:" and "Cc:" lines each are sent a copy of the message with the "Bcc:" line removed as above, but the recipients on the "Bcc:" line get a separate copy of the message containing a "Bcc:" line. (When there are multiple recipient addresses in the "Bcc:" field, some implementations actually send a separate copy of the message to each recipient with a "Bcc:" containing only the address of that particular recipient.) Finally, since a "Bcc:" field may contain no addresses, a "Bcc:" field can be sent without any addresses indicating to the recipients that blind copies were sent to someone. Which method to use with "Bcc:" fields is implementation dependent, but refer to the "Security Considerations" section of this document for a discussion of each. ==================
Kent, if you believe that this is a valid bug, please change the summary accordingly. This is at best an enhancement. The testing with my hosting provider shows that a BCC recipient receives an Envelope-to header showing that particular recipient but not any other. The whole idea of BCC is *not* to disclose the recipients to each other, so adding the header as described in the bug is just plain crazy and I don't think we have resources to prevent craziness in the world. Besides, many mail provider ban people who are sending messages in quick succession, so unless we implemented some delayed send, this would just be a catastrophe.
I tested sending from Gmail myself like in comment #3. Each BCC recipient receives the Envelope-to for himself and not any other BCC'ed person. It can't be any other way. Next I tested sending e-mail to two Gmail accounts as BCC: Result, no disclosure of other BCC recipients. Reporter: Please attach the full message where a BCC received a message with an Evelope-to that contained more than just that recipient.
IMHO this is unnecessary and completely unfeasible (see comment #9). And I'm pretty convinced that the whole bug is based on some misunderstanding since Gmail is doing the right thing despite the reporter claiming that it doesn't. Kent, feel free to reopen, but I don't think we have time for this and it's not even desired.
OK, it took me a while to set up a new test. The sequence was: I had two addresses in the "To" field. "Use BCC instead" notified me that it was converting them to BCC (I have my threshold set to 2). For some reason, only one message was received (this may or may not be a result of something my mail provider is doing) and it contained both recipients addresses in the "Envelope-to" field. Ther is no BCC header line, only the Envelope-to one. Message and headers follows (BTW TBird didn't copy the headers when I tried, so I copied them from a mail preview program) =================== Return-Path: <SRS0=z9GAA0=VLemail@example.com> Received: from walmailscan07.int.bizland.net by walmailscan07.int.bizland.net (Dovecot) with LMTP id mVR8BoWr5VcxZAAA9wVnTQ ; Fri, 23 Sep 2016 18:25:22 -0400 Return-path: <SRS0=z9GAA0=VLfirstname.lastname@example.org> Envelope-to: BCCa@hunters-online.net, BCCb@hunters-online.net Delivery-date: Fri, 23 Sep 2016 18:25:22 -0400 Received: from [10.114.3.33] (helo=walimpout13) by walmailscan07.yourhostingaccount.com with esmtp (Exim) id 1bnYuI-0001R4-FY; Fri, 23 Sep 2016 18:25:22 -0400 Received: from walauthsmtp02.yourhostingaccount.com ([10.1.18.2]) by walimpout13 with id nARK1t00602goRm01ARNZV; Fri, 23 Sep 2016 18:25:22 -0400 X-Authority-Analysis: v=2.1 cv=fagjyigF c=1 sm=1 tr=0 a=x/Hyyyp0PjmVEO0KwK8auA==:117 a=poAjPqQwPb/t3RUxEwvQCg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=wVCaUX_kyA0A:10 a=IkcTkHD0fZMA:10 a=GW1xBdLrtEIA:10 a=_6GpL_ENAAAA:8 a=3pfoXPgmLRG-25sUmTkA:9 a=QEXdDO2ut3YA:10 a=8DS-ehr1woAA:10 a=xupg4knwUDYA:10 a=HPItUfg3-W5T9FFxMdBG:22 Received: from ool-43529f17.dyn.optonline.net ([184.108.40.206]:11944 helo=[127.0.0.1]) by walauthsmtp02.yourhostingaccount.com with esmtpa (Exim) id 1bnYuF-0003Ae-CJ; Fri, 23 Sep 2016 18:25:19 -0400 From: Joe Hunter <email@example.com> Subject: BCC test 5 Reply-To: firstname.lastname@example.org Message-ID: <email@example.com> Date: Fri, 23 Sep 2016 18:25:17 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 160923-1, 09/23/2016), Outbound message X-Antivirus-Status: Clean X-EN-UserInfo: 45bc3495b77df12b9012afd3e3668aad:931c98230c6409dcc37fa7e93b490c27 X-EN-AuthUser: firstname.lastname@example.org Sender: Joe Hunter <email@example.com> X-EN-OrigIP: 220.127.116.11 X-EN-OrigHost: ool-43529f17.dyn.optonline.net X-Antivirus: avast! (VPS 160923-1, 09/23/2016), Inbound message X-Antivirus-Status: Clean BCC test 5 --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
I don't think you test is valid since I bet you a beer that BCCa@hunters-online.net and BCCb@hunters-online.net are the same mailbox. You're provider only delivers the e-mail once but with both in the Envelope-to. You even confirmed that. I tried the same, sent e-mail to myself and two BCCs which are different addresses but go to the same mailbox at the mail hoster. I got one e-mail and all three addresses in the Envelope-to. You've send us onto a wild goose chase here. There is no problem in TB, there isn't even a problem with your provider or Gmail, only that when you repeat the same final recipient with two different e-mails both hosted a the same "smart" provider, the Envelope-to contains both. Just do a real test. Do a do a message with BCC to a Gmail address with BCC to a Hotmail address at the same time and then check. You won't find a problem.
I've changed the summary back to match the truly invalid status. Kent, the reporter never asked to individual messages for BCCs, so really no bug here.
Jorg, Thanks for staying with this....... It does appear that the problem may be with my mail provider. However, those are not the same mailbox, and the mail provider shouldn't have combined them. The two addresses could well have been used by two different people. HotMail (which works) and GMail (which doesn't) are really irrelevant, since my tests with them were done using their webmail access. The other post I saw from someone who suggested using IncrediMail, which he claimed worked, could also be irrelevant in my case if he is using a different type of mail provider. So it looks like the only solution would be to send multiple copies as suggested in the second parenthetical statement in RFC 5322. However, as you mentioned to Kent, this could cause problems if the mail provider enforced some ban on multiple messages being sent too fast. So the provider (PowWeb) should not be combining anything because their service is supposed to allow one customer to assign different addresses to different prople, and each should be getting their own copy of the message. But that's now a TBird problem. Thanks for sticking with this and helping me figure out what was happening and where.
Jorg, I did the "real test you suggested (almost). I sent a message with two BCCs. one to a PowWeb address, and one to my GMail address. And the problem doesn't exist there. There was one odd thing though....the message received at the PowWeb address had the Envelope-to line with just one address. But even though I expanded the message to show the entire header, it didn't contain either a BCC or an Envelope-to line. Strange but not really a problem. I'm going to have to go over the PowWeb's community forums to see if anyone has reported on these things. Thanks again...............
I omitted one important part.....it was the GMail recipient that had neither a BCC or Envelope-to line.
Final comment: Some e-mail providers put the final recipient into Envelope-to, and if multiple recipients addresses just receive one copy, the provider sticks all the addresses into Envelope-to. My provider glues recipients together where the e-mail would go into the same final mailbox. Maybe your provider goes further and glues all e-mail accounts of one customer together. That would be strange. GMail doesn't seem to add Envelope-To (but they add other stuff).
If I ever figure out what is really happening, I can apply for my Philadelphia law degree. ;-) (Since you're not at GMT-5 you probably don't understand the expression.) ;-) As for GMail.....it's strange, too. That address was a recipient, not a sender, but there were a lot more header lines in what GMail displayed. Unless of course they are the correct one, and incoming mail to PowWeb has some lines stripped off. I can understand why an SMTP server would manipulate the headers as it was deciding how to send all copies of the messages, but not why a POP sever would have any reason to do so. To quote from Lewis Carroll's Alice in Wonderland: It gets “Curiouser and curiouser!”
Gmail inserts Delivered-To: