Header info of Bcc shows full email address of recipient instead of showing showing as undisclosed-recipient;
Categories
(Thunderbird :: General, defect)
Tracking
(Not tracked)
People
(Reporter: thee.chicago.wolf, Unassigned)
Details
Attachments
(2 files)
bcc-populated.png
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:86.0) Gecko/20100101 Firefox/86.0
Steps to reproduce:
Nothing really, checked my Inbox for a new message and clicked on it.
Actual results:
I received a work email from a person at my org. The email arrived showing in the header of the To: field as "undisclosed-recipients;" and the Bcc: field shows my full work email address instead of "undisclosed recipient;" as, I think, it should. Or at least that's how I've always remembered it.
As a test, I drafted an email message from one of three GMail IMAP accounts I have on TB. Let's call them Account 1, Account 2 and Account 3. I drafted an email using Account 2 and sent and email to Account 1 using the To: field and Bcc'ed Account 2 and Account 3.
Results:
-
The email that arrived to Account 1 shows From: as coming from Account 2. It does not display any Bcc field or info. That seems odd.
-
The email that arrived to Account 2 shows From: as coming From: Account 2. It does display in the Bcc field the full email address for Account 2 and Account 3 and not Undisclosed-recipients;.
-
The email that arrived to Account 3 shows From: as coming From: Account 2. It does not display any Bcc field or info. That seems odd.
Expected results:
I think any Bcc field/header info isn't supposed to display the full email address of Bcc recipients. That's why it's called blind carbon copy, no?
|
Reporter | |
Comment 1•5 years ago
|
||
|
||
Comment 2•5 years ago
|
||
I thought a message header wasn't supposed to show a Bcc address at all?
I don't see one in the messages I get with those addresses for me, or in the source of the message using 86.0b2 on Fedora 33.
|
||
Comment 3•5 years ago
|
||
Is the image what you received? Or what you sent?
Walt is correct, if the sender's SMTP worked correctly, then anything sent with BCC would not be revealed to you, not even a BCC header.
|
|
Reporter | |
Comment 4•5 years ago
|
||
(In reply to Wayne Mery (:wsmwk) from comment #3)
Is the image what you received? Or what you sent?
Walt is correct, if the sender's SMTP worked correctly, then anything sent with BCC would not be revealed to you, not even a BCC header.
What's in the pic is what I received. And I agree, Bcc should not reveal anything or even be shown. The standard is, I think, to strip it from the header.
Being that my org farms out our email to Google/GMail, does this imply something configured on the Google/GMail side could be amiss for our org? Could our email admin have configured something up wrong?
I might have to bring this to his attention so he can investigate. It definitely doesn't look correct, yes?
|
|
Reporter | |
Comment 5•5 years ago
|
||
Here's a test email I just sent from myself to myself using the Bcc field. If you guys say this is normal, then I'll close this as WFM.
|
|
||
Updated•5 years ago
|
|
|
||
Comment 6•5 years ago
|
||
Using the 86.0b3 release candidate on Fedora 33 Workstation.
I tested bug 1692484 by sending attachments from one account to other accounts using Bcc (no To: addresses) and received them as Undisclosed Recipient.
|
|
Reporter | |
Comment 7•5 years ago
|
||
(In reply to WaltS48 [:walts48] from comment #6)
Using the 86.0b3 release candidate on Fedora 33 Workstation.
I tested bug 1692484 by sending attachments from one account to other accounts using Bcc (no To: addresses) and received them as Undisclosed Recipient.
Same. My To: field shows Undisclosed Recipient; but Delivered-To shows the actual email address. Is that normal or not?
|
|
||
Comment 8•5 years ago
|
||
I don't know where to find Delivered-To. It isn't in the received or sent mails source.
I can't reproduce your issue.
|
|
Reporter | |
Comment 9•5 years ago
|
||
(In reply to WaltS48 [:walts48] from comment #8)
I don't know where to find Delivered-To. It isn't in the received or sent mails source.
I can't reproduce your issue.
It's in the header field, just scroll down a bit. Make sure you have headers set to View > Headers >All. Deliverted-To is shown in the header info.
|
|
||
Comment 10•5 years ago
|
||
I still don't see Bcc: with any email address in safe mode with headers set to All.
My Gmail IMAP account does have a Delivered-To, my Verizon POP3 account has a X-Apparently-To entry.
Good luck.
|
||
Comment 11•5 years ago
|
||
(In reply to Arthur K. [He/Him] from comment #0)
Steps to reproduce:
Nothing really, checked my Inbox for a new message and clicked on it.
"Nothing" is not a step!
@everyone:
Please let's avoid wasting time doing guesswork on bugs without clear STR and everything mixed up in comment 0. We really need to insist on proper STR, and I'm sure that Arthur knows better. It may not matter how you met the bug first time, but you have to bite the bullet and try to come up with a bulleted list of crystal-clear steps to reproduce, separate from actual results and expected results.
There is no bug here, and it's quite impossible for this to be a Thunderbird bug even if there was a bug: Thunderbird just hands over a message with full and explicit BCC headers to the SMTP server, and it's the SMTP server that is then responsible for eliminating (or not) those BCC headers while distributing the message. Correct me if I'm wrong. So even if any BCC's were leaking (which they are not), there's nothing TB could do about that.
I'll roll this out cleanly in my next comment.
|
|
Reporter | |
Comment 12•5 years ago
|
||
I guess STR would be receiving a an email BCC but, if there's no bug here, then closing as INVALID. Sorry for any confusion.
|
|
||
Comment 13•5 years ago
•
|
||
STR
- compose new message using gmail IMAP account on TB (in brackets: Account names per comment 0)
From: sender@gmail.com (A2)
To: opento@gmail.com (A1)
BCC: sender@gmail.com (A2), blind1@gmail.com (A3) - Send
- check resulting sent/incoming messages if there's any BCC leakage to other parties
a) check received message in Inbox of other party opento@gmail.com
b) check received message in Inbox of other party blind1@gmail.com
c) check received message in your own Inbox (sender@gmail.com) from bcc to self
d) check your own sent message in Sent of sender@gmail.com
Actual result
- TLDR; There is no leakage of BCC recipients to any other party. Only the sender will know all BCC recipients.
- The message sent via BCC to self and "received" in sender's inbox (From: sender@gmail, BCC: sender@gmail) shows all BCC recipients. This may differ from other providers, but it does not constitute Bcc leakage as the sender already knows all the BCC recipients from composing the message. Technically, iirc (and the source seems to confirm that), Google does not even bother sending the bcc-to-sender/self message through the net, but just labels the sent message also as inbox, keeping only one physical message.
- Obviously the sent message in sender's sent folder has all BCC recipients.
a) received message in inbox of opento@gmail.com:
Delivered-To: opento@gmail.com
To: opento@gmail.com
No Bcc header.
b) received message in inbox of blind1@gmail.com:
Delivered-To: blind1@gmail.com
To: opento@gmail.com
No Bcc header.
c) received message in inbox of sender@gmail.com (bcc to self)
Delivered-To: sender@gmail.com
To: opento@gmail.com
BCC: sender@gmail.com, blind1@gmail.com (no leakage, this is the sender's inbox, see explanation above).
Expected Result (same as Actual Result)
- Do not leak Bcc recipients to any other party who is not the sender.
|
|
||
Comment 14•5 years ago
•
|
||
(In reply to Arthur K. [He/Him] from comment #12)
I guess STR would be receiving a an email BCC but, if there's no bug here, then closing as INVALID. Sorry for any confusion.
"receiving an email Bcc" is clearly not STR. STR means "steps to reproduce", which requires(!) a numbered list of steps for another person to reproduce the problem. Steps should be phrased in imperative form (you're telling the other person what to do):
- do this
- then do that
- then look at this aspect of the result (optional step for focusing reproducer's attention, especially if result is volatile)
Don't get me wrong Arthur, your contributions are appreciated!
Forcing oneself to use numbered steps and to observe the sections (STR/Actual/Expected) will automatically improve the quality of any bug report, reduce the time needed for triage, and increase the chances of the bug being resolved one way or another.
Even for RFE's (requests for feature enhancement), using the same structure will help to nail down the problem which the RFE is trying to solve, and avoid conflation of problem and different possible solutions.
|
|
||
Comment 15•5 years ago
|
||
(In reply to Arthur K. [He/Him] from comment #0)
Results:
- The email that arrived to Account 1 shows From: as coming from Account 2. It does not display any Bcc field or info. That seems odd.
Why is it odd that other Bcc recipients are hidden from To recipient? That's 100% correct. There should be no trace that the message had other bcc recipients. You'll only get "To: Undisclosed-recipients: ;" if the To and CC fields were both empty, in which case you're one of the Bcc recipients so again you'll already know that there's at least one Bcc recipient.
- The email that arrived to Account 2 shows From: as coming From: Account 2. It does display in the Bcc field the full email address for Account 2 and Account 3 and not Undisclosed-recipients;.
This is the message from sender to sender via BCC to self.
It's a gmail peculiarity that there's full disclosure of Bcc recipients even in inbox, but no Bcc leakage here as the sender already knows. See comment 13 for details.
- The email that arrived to Account 3 shows From: as coming From: Account 2. It does not display any Bcc field or info. That seems odd.
See 1. Nothing odd here.
Description
•