26

How can I unmask the e-mail addresses in a Bcc field when I am just a recipient?

Need very simple, step-by-step instructions for someone who doesn't code. I have received a group e-mail and would really like to see the others who got it.

user
  • 152
  • 9
Jenny B
  • 289
  • 1
  • 3
  • 4
  • 230
    Not being able to do this is the exact point of Bcc. – chrylis -cautiouslyoptimistic- Mar 25 '19 at 06:22
  • 98
    I have a feeling there's a followup question coming on workplace.SE – Hatted Rooster Mar 25 '19 at 11:39
  • 1
    You can't. But I know cheeky ads/spam/analytics company embed HTML code with web-beacon to track recipient geolocation. – mootmoot Mar 25 '19 at 12:25
  • 7
    You would have to hack into the SMTP server that sent you the email and decipher the incoming logs to see the BCC. You, as an average person will most likely have a tough time achieving this... – MonkeyZeus Mar 25 '19 at 15:26
  • 40
    @chrylis To be fair, there are so many cases where information that shouldn't be accessible is merely hidden, that I can understand how a person would think it might be possible. – David Z Mar 25 '19 at 17:58
  • 20
    Nothing easier. Sue the sender then use a subpoena to compel disclosure of the original message. – Harper - Reinstate Monica Mar 25 '19 at 21:38
  • 1
    To add to the top comment, even if Bcc was somehow masked in the header, then the sender could circumvent this entirely by just copying the email and sending it separately to the other people. Bcc just achieves this to make it easier for that purpose. – QuickishFM Mar 25 '19 at 22:21
  • 1
    If you have control over the receiving MTA and the sending MTA batches per domain or server you might see in the logfiles who else of that domain or server was addressed in the transmission. But you normally not see it in the mail headers. – eckes Mar 26 '19 at 05:13
  • 1
    I hate when OP posts a question then never comments or replies to anyone. Really curious what their thinking is here! – user91988 Mar 26 '19 at 15:57
  • Within legal limits, skulduggery. – kayleeFrye_onDeck Mar 26 '19 at 16:09

3 Answers3

128

You can't. You simply won't have any information about the Bcc header when you receive the mail, so you there's nothing to "unmask".

The way Bcc is designed is specified in RFC 2822, under section 3.6.3. To quote the specification:

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.

When a message is a reply to another message, the mailboxes of the authors of the original message (the mailboxes in the "From:" field) or mailboxes specified in the "Reply-To:" field (if it exists) MAY appear in the "To:" field of the reply since these would normally be the primary recipients of the reply. If a reply is sent to a message that has destination fields, it is often desirable to send a copy of the reply to all of the recipients of the message, in addition to the author. When such a reply is formed, addresses in the "To:" and "Cc:" fields of the original message MAY appear in the "Cc:" field of the reply, since these are normally secondary recipients of the reply. If a "Bcc:" field is present in the original message, addresses in that field MAY appear in the "Bcc:" field of the reply, but SHOULD NOT appear in the "To:" or "Cc:" fields.

Note: Some mail applications have automatic reply commands that include the destination addresses of the original message in the destination addresses of the reply. How those reply commands behave is implementation dependent and is beyond the scope of this document. In particular, whether or not to include the original destination addresses when the original message had a "Reply-To:" field is not addressed here.

In practice the case where To and Cc recipients receive no Bcc line, but each Bcc'ed address receives a Bcc line containing only their email address, is most common. This provides no indication of a Bcc to the To and Cc recipients, and indicates to the Bcc'ed recipients that they were sent the email via the use of Bcc without revealing other Bcc recipients.

Community
  • 1
Polynomial
  • 135,049
  • 43
  • 306
  • 382
  • 9
    each Bcc'ed address receives a Bcc line containing only their email address, is most common. Is it? That would require sending the message multiple times instead of a single message with multiple RCPT TO: commands. What MUA would do that? – Esa Jokinen Mar 25 '19 at 03:57
  • @EsaJokinen What other choice does the MUA have when the recipients are on different domains? BCC simply forces that behaviour. – Selcuk Mar 25 '19 at 05:12
  • 9
    The MUA sends it only once to the MTA, and the MTA starts delivering it separately to all the different domains. The thing is that MTAs won't usually bother to add RCPT TO as Bcc:. It's more likely in a Received: header as for <user@example.com>. – Esa Jokinen Mar 25 '19 at 05:41
  • @EsaJokinen I am somewhat unfamiliar with the underlying process between MUAs and MTAs, but ultimately the effect is the same - you receive an email with some indication that you were Bcc'ed (not in the To or Cc lines) and no information about other Bcc recipients. – Polynomial Mar 25 '19 at 11:35
  • 4
    That's true: you know that you were Bcc'd (or otherwise undisclosed) from not being on the To & Cc headers. MUA just saves the Bcc when saving the mail to the senders Sent-folder, but it's not part of the message sent via SMTP. – Esa Jokinen Mar 25 '19 at 11:39
  • Some email systems do behave as described with regards to the Bcc field, Lotus Notes being one of them (at least, the last time I used it, four years ago): you see yourself (and only yourself) in the Bcc field if that’s how you the email. – Stephen Kitt Mar 25 '19 at 16:32
  • @StephenKitt that may just be how it's displayed when you receive it, rather than how it was actually sent. – OrangeDog Mar 25 '19 at 18:19
  • @OrangeDog indeed, the client could be using the same heuristic as in Esa’s comment. – Stephen Kitt Mar 25 '19 at 18:54
  • @EsaJokinen If you received the email through a forwarding you'd also find your own email address to be absent from To and Cc just like you would if it was due to a Bcc. – kasperd Mar 26 '19 at 00:42
  • 1
    @EsaJokinen Gmail does this - it actually includes the Bcc header in the message. I don't know offhand of any others that do it. – Moshe Katz Mar 26 '19 at 23:34
  • @MosheKatz: I tried and reproduced this behavior by sending a single mail from Gmail to two different Bcc addresses. Strange enough: BCC: header gets added for one recipient (Office 365) but not for the other (Postfix). – Esa Jokinen Mar 28 '19 at 06:07
  • Gmail added the feature in 2011 and Office/Exchange added it in 2014. I don't know whether Gmail only sends the headers if it knows the recipient will keep them, or if Postfix is stripping them. – Moshe Katz Mar 28 '19 at 15:25
32

Typically not possible if you don't have control over the sender SMTP server since this field is not transmitted to the recipient SMTP server.

When sending a mail, the sender SMTP server checks the BCC field and creates a copy for each recipient listed, removing the list of other recipients. That is the whole point of BCC functionality.

Naoy
  • 431
  • 3
  • 4
5

Request For Comments (RFC) standard (published by The Internet Engineering Task Force (IETF)) specifies that recipients of an email, sent to recipients specified in "BCC" header may receive the email but not be aware of any other recipients mentioned in the header. Specifically, "addresses are not to be revealed to other recipients of the message".

It's a request (not a mandate) to SMTP servers to reflect current practice (protocol) for the Internet community by The Internet Society.

However, those found to be not compliant may be segregated and if found to be rogue, will be banned/blacklisted, and even prosecuted when found to conduct activities in contravention of laws in the jurisdiction.

So if you're a recipient of an email from a compliant (mail) server, you won't receive other recipients emails mentioned in the "BCC" field, unless you're in control of the sending (SMTP) server, the incoming (POP,IMAP, etc) server, and all the relay servers that routed the IP packets.

Zimba
  • 191
  • 5
  • 3
    "Those found to be not compliant may be segregated and if found to be rogue, will be banned/blacklisted, and even prosecuted when found to conduct activities in contravention of laws in the jurisdiction." - I would suggest this is an extremely unlikely outcome for a server that leaked BCC addresses. Moreover, if a message is BCC'd to x@foo.com and y@bar.com, and foo.com and y.com have different SMTP servers, bar.com will not even receive the x@foo.com's address to leak, so there would be no point in "segregating" it as its leaks only affect its own users. – abligh Mar 26 '19 at 06:16
  • 2
    Are there laws requiring IETF RFC compliance for email systems now? – grawity Mar 26 '19 at 06:35
  • 1
    @grawity: You'd be looking for laws that proscribe applying best practices, generally accepted methods and similar generic statements. Cf. GDPR 5.1(f) "appropriate technical or organisational measures" – MSalters Mar 26 '19 at 09:37
  • 2
    @MSalters presumably meant prescribe rather than its opposite, proscribe... – Toby Speight Mar 26 '19 at 16:38
  • 1
    @grawity not directly but a server which disclosed information despite standards say otherwise would cause its operator to violate various privacy laws (like GDPR or CCPA) – eckes Mar 28 '19 at 02:12
  • @grawity: There doesn't seem to be any laws mandating RFC compliance (internet protocols) since they (in turn) are generally based on prevailing legislation & best practice (netiquette) anyway. – Zimba Apr 10 '19 at 13:10