Can I Retrieve Email Addresses from BCC?
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.
New contributor
|
show 5 more comments
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.
New contributor
224
Not being able to do this is the exact point of Bcc.
– chrylis
Mar 25 at 6:22
97
I have a feeling there's a followup question coming on workplace.SE
– Sombrero Chicken
Mar 25 at 11:39
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 at 15:26
37
@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 at 17:58
19
Nothing easier. Sue the sender then use a subpoena to compel disclosure of the original message.
– Harper
Mar 25 at 21:38
|
show 5 more comments
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.
New contributor
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.
New contributor
New contributor
edited Mar 25 at 17:02
Fermi paradox
1257
1257
New contributor
asked Mar 25 at 0:06
Jenny BJenny B
156123
156123
New contributor
New contributor
224
Not being able to do this is the exact point of Bcc.
– chrylis
Mar 25 at 6:22
97
I have a feeling there's a followup question coming on workplace.SE
– Sombrero Chicken
Mar 25 at 11:39
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 at 15:26
37
@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 at 17:58
19
Nothing easier. Sue the sender then use a subpoena to compel disclosure of the original message.
– Harper
Mar 25 at 21:38
|
show 5 more comments
224
Not being able to do this is the exact point of Bcc.
– chrylis
Mar 25 at 6:22
97
I have a feeling there's a followup question coming on workplace.SE
– Sombrero Chicken
Mar 25 at 11:39
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 at 15:26
37
@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 at 17:58
19
Nothing easier. Sue the sender then use a subpoena to compel disclosure of the original message.
– Harper
Mar 25 at 21:38
224
224
Not being able to do this is the exact point of Bcc.
– chrylis
Mar 25 at 6:22
Not being able to do this is the exact point of Bcc.
– chrylis
Mar 25 at 6:22
97
97
I have a feeling there's a followup question coming on workplace.SE
– Sombrero Chicken
Mar 25 at 11:39
I have a feeling there's a followup question coming on workplace.SE
– Sombrero Chicken
Mar 25 at 11:39
7
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 at 15:26
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 at 15:26
37
37
@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 at 17:58
@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 at 17:58
19
19
Nothing easier. Sue the sender then use a subpoena to compel disclosure of the original message.
– Harper
Mar 25 at 21:38
Nothing easier. Sue the sender then use a subpoena to compel disclosure of the original message.
– Harper
Mar 25 at 21:38
|
show 5 more comments
3 Answers
3
active
oldest
votes
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.
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 multipleRCPT TO:
commands. What MUA would do that?
– Esa Jokinen
Mar 25 at 3:57
@EsaJokinen What other choice does the MUA have when the recipients are on different domains? BCC simply forces that behaviour.
– Selcuk
Mar 25 at 5: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 addRCPT TO
asBcc:
. It's more likely in aReceived:
header asfor <user@example.com>
.
– Esa Jokinen
Mar 25 at 5:41
4
That's true: you know that you were Bcc'd (or otherwise undisclosed) from not being on theTo
&Cc
headers. MUA just saves theBcc
when saving the mail to the senders Sent-folder, but it's not part of the message sent via SMTP.
– Esa Jokinen
Mar 25 at 11:39
1
@EsaJokinen Gmail does this - it actually includes theBcc
header in the message. I don't know offhand of any others that do it.
– Moshe Katz
2 days ago
|
show 7 more comments
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.
add a comment |
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 to SMTP servers to reflect current practice (protocol) for the Internet community by The Internet Society.
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.
New contributor
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 at 6:16
2
Are there laws requiring IETF RFC compliance for email systems now?
– grawity
Mar 26 at 6: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 at 9:37
2
@MSalters presumably meant prescribe rather than its opposite, proscribe...
– Toby Speight
Mar 26 at 16:38
@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
yesterday
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "162"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Jenny B is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f206003%2fcan-i-retrieve-email-addresses-from-bcc%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
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 multipleRCPT TO:
commands. What MUA would do that?
– Esa Jokinen
Mar 25 at 3:57
@EsaJokinen What other choice does the MUA have when the recipients are on different domains? BCC simply forces that behaviour.
– Selcuk
Mar 25 at 5: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 addRCPT TO
asBcc:
. It's more likely in aReceived:
header asfor <user@example.com>
.
– Esa Jokinen
Mar 25 at 5:41
4
That's true: you know that you were Bcc'd (or otherwise undisclosed) from not being on theTo
&Cc
headers. MUA just saves theBcc
when saving the mail to the senders Sent-folder, but it's not part of the message sent via SMTP.
– Esa Jokinen
Mar 25 at 11:39
1
@EsaJokinen Gmail does this - it actually includes theBcc
header in the message. I don't know offhand of any others that do it.
– Moshe Katz
2 days ago
|
show 7 more comments
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.
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 multipleRCPT TO:
commands. What MUA would do that?
– Esa Jokinen
Mar 25 at 3:57
@EsaJokinen What other choice does the MUA have when the recipients are on different domains? BCC simply forces that behaviour.
– Selcuk
Mar 25 at 5: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 addRCPT TO
asBcc:
. It's more likely in aReceived:
header asfor <user@example.com>
.
– Esa Jokinen
Mar 25 at 5:41
4
That's true: you know that you were Bcc'd (or otherwise undisclosed) from not being on theTo
&Cc
headers. MUA just saves theBcc
when saving the mail to the senders Sent-folder, but it's not part of the message sent via SMTP.
– Esa Jokinen
Mar 25 at 11:39
1
@EsaJokinen Gmail does this - it actually includes theBcc
header in the message. I don't know offhand of any others that do it.
– Moshe Katz
2 days ago
|
show 7 more comments
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.
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.
answered Mar 25 at 0:20
PolynomialPolynomial
101k34249342
101k34249342
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 multipleRCPT TO:
commands. What MUA would do that?
– Esa Jokinen
Mar 25 at 3:57
@EsaJokinen What other choice does the MUA have when the recipients are on different domains? BCC simply forces that behaviour.
– Selcuk
Mar 25 at 5: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 addRCPT TO
asBcc:
. It's more likely in aReceived:
header asfor <user@example.com>
.
– Esa Jokinen
Mar 25 at 5:41
4
That's true: you know that you were Bcc'd (or otherwise undisclosed) from not being on theTo
&Cc
headers. MUA just saves theBcc
when saving the mail to the senders Sent-folder, but it's not part of the message sent via SMTP.
– Esa Jokinen
Mar 25 at 11:39
1
@EsaJokinen Gmail does this - it actually includes theBcc
header in the message. I don't know offhand of any others that do it.
– Moshe Katz
2 days ago
|
show 7 more comments
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 multipleRCPT TO:
commands. What MUA would do that?
– Esa Jokinen
Mar 25 at 3:57
@EsaJokinen What other choice does the MUA have when the recipients are on different domains? BCC simply forces that behaviour.
– Selcuk
Mar 25 at 5: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 addRCPT TO
asBcc:
. It's more likely in aReceived:
header asfor <user@example.com>
.
– Esa Jokinen
Mar 25 at 5:41
4
That's true: you know that you were Bcc'd (or otherwise undisclosed) from not being on theTo
&Cc
headers. MUA just saves theBcc
when saving the mail to the senders Sent-folder, but it's not part of the message sent via SMTP.
– Esa Jokinen
Mar 25 at 11:39
1
@EsaJokinen Gmail does this - it actually includes theBcc
header in the message. I don't know offhand of any others that do it.
– Moshe Katz
2 days ago
9
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 at 3:57
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 at 3:57
@EsaJokinen What other choice does the MUA have when the recipients are on different domains? BCC simply forces that behaviour.
– Selcuk
Mar 25 at 5:12
@EsaJokinen What other choice does the MUA have when the recipients are on different domains? BCC simply forces that behaviour.
– Selcuk
Mar 25 at 5:12
9
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 at 5:41
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 at 5:41
4
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 at 11:39
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 at 11:39
1
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
2 days ago
@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
2 days ago
|
show 7 more comments
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.
add a comment |
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.
add a comment |
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.
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.
answered Mar 25 at 0:09
NaoyNaoy
43133
43133
add a comment |
add a comment |
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 to SMTP servers to reflect current practice (protocol) for the Internet community by The Internet Society.
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.
New contributor
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 at 6:16
2
Are there laws requiring IETF RFC compliance for email systems now?
– grawity
Mar 26 at 6: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 at 9:37
2
@MSalters presumably meant prescribe rather than its opposite, proscribe...
– Toby Speight
Mar 26 at 16:38
@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
yesterday
add a comment |
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 to SMTP servers to reflect current practice (protocol) for the Internet community by The Internet Society.
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.
New contributor
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 at 6:16
2
Are there laws requiring IETF RFC compliance for email systems now?
– grawity
Mar 26 at 6: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 at 9:37
2
@MSalters presumably meant prescribe rather than its opposite, proscribe...
– Toby Speight
Mar 26 at 16:38
@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
yesterday
add a comment |
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 to SMTP servers to reflect current practice (protocol) for the Internet community by The Internet Society.
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.
New contributor
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 to SMTP servers to reflect current practice (protocol) for the Internet community by The Internet Society.
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.
New contributor
New contributor
answered Mar 25 at 11:37
ZimbaZimba
671
671
New contributor
New contributor
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 at 6:16
2
Are there laws requiring IETF RFC compliance for email systems now?
– grawity
Mar 26 at 6: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 at 9:37
2
@MSalters presumably meant prescribe rather than its opposite, proscribe...
– Toby Speight
Mar 26 at 16:38
@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
yesterday
add a comment |
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 at 6:16
2
Are there laws requiring IETF RFC compliance for email systems now?
– grawity
Mar 26 at 6: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 at 9:37
2
@MSalters presumably meant prescribe rather than its opposite, proscribe...
– Toby Speight
Mar 26 at 16:38
@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
yesterday
3
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 at 6:16
"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 at 6:16
2
2
Are there laws requiring IETF RFC compliance for email systems now?
– grawity
Mar 26 at 6:35
Are there laws requiring IETF RFC compliance for email systems now?
– grawity
Mar 26 at 6:35
1
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 at 9:37
@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 at 9:37
2
2
@MSalters presumably meant prescribe rather than its opposite, proscribe...
– Toby Speight
Mar 26 at 16:38
@MSalters presumably meant prescribe rather than its opposite, proscribe...
– Toby Speight
Mar 26 at 16:38
@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
yesterday
@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
yesterday
add a comment |
Jenny B is a new contributor. Be nice, and check out our Code of Conduct.
Jenny B is a new contributor. Be nice, and check out our Code of Conduct.
Jenny B is a new contributor. Be nice, and check out our Code of Conduct.
Jenny B is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Information Security Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f206003%2fcan-i-retrieve-email-addresses-from-bcc%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
224
Not being able to do this is the exact point of Bcc.
– chrylis
Mar 25 at 6:22
97
I have a feeling there's a followup question coming on workplace.SE
– Sombrero Chicken
Mar 25 at 11:39
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 at 15:26
37
@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 at 17:58
19
Nothing easier. Sue the sender then use a subpoena to compel disclosure of the original message.
– Harper
Mar 25 at 21:38