Can I Retrieve Email Addresses from BCC?












22















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.










share|improve this question









New contributor




Jenny B is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
















  • 129





    Not being able to do this is the exact point of Bcc.

    – chrylis
    yesterday






  • 52





    I have a feeling there's a followup question coming on workplace.SE

    – Sombrero Chicken
    20 hours ago






  • 2





    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
    16 hours ago






  • 10





    @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
    14 hours ago






  • 4





    Nothing easier. Sue the sender then use a subpoena to compel disclosure of the original message.

    – Harper
    10 hours ago
















22















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.










share|improve this question









New contributor




Jenny B is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
















  • 129





    Not being able to do this is the exact point of Bcc.

    – chrylis
    yesterday






  • 52





    I have a feeling there's a followup question coming on workplace.SE

    – Sombrero Chicken
    20 hours ago






  • 2





    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
    16 hours ago






  • 10





    @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
    14 hours ago






  • 4





    Nothing easier. Sue the sender then use a subpoena to compel disclosure of the original message.

    – Harper
    10 hours ago














22












22








22


1






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.










share|improve this question









New contributor




Jenny B is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.












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.







email






share|improve this question









New contributor




Jenny B is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question









New contributor




Jenny B is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question








edited 15 hours ago









Fermi paradox

1257




1257






New contributor




Jenny B is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked yesterday









Jenny BJenny B

12913




12913




New contributor




Jenny B is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





Jenny B is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






Jenny B is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.








  • 129





    Not being able to do this is the exact point of Bcc.

    – chrylis
    yesterday






  • 52





    I have a feeling there's a followup question coming on workplace.SE

    – Sombrero Chicken
    20 hours ago






  • 2





    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
    16 hours ago






  • 10





    @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
    14 hours ago






  • 4





    Nothing easier. Sue the sender then use a subpoena to compel disclosure of the original message.

    – Harper
    10 hours ago














  • 129





    Not being able to do this is the exact point of Bcc.

    – chrylis
    yesterday






  • 52





    I have a feeling there's a followup question coming on workplace.SE

    – Sombrero Chicken
    20 hours ago






  • 2





    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
    16 hours ago






  • 10





    @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
    14 hours ago






  • 4





    Nothing easier. Sue the sender then use a subpoena to compel disclosure of the original message.

    – Harper
    10 hours ago








129




129





Not being able to do this is the exact point of Bcc.

– chrylis
yesterday





Not being able to do this is the exact point of Bcc.

– chrylis
yesterday




52




52





I have a feeling there's a followup question coming on workplace.SE

– Sombrero Chicken
20 hours ago





I have a feeling there's a followup question coming on workplace.SE

– Sombrero Chicken
20 hours ago




2




2





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
16 hours ago





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
16 hours ago




10




10





@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
14 hours ago





@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
14 hours ago




4




4





Nothing easier. Sue the sender then use a subpoena to compel disclosure of the original message.

– Harper
10 hours ago





Nothing easier. Sue the sender then use a subpoena to compel disclosure of the original message.

– Harper
10 hours ago










3 Answers
3






active

oldest

votes


















79














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.






share|improve this answer



















  • 8





    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
    yesterday













  • @EsaJokinen What other choice does the MUA have when the recipients are on different domains? BCC simply forces that behaviour.

    – Selcuk
    yesterday






  • 3





    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
    yesterday













  • @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
    20 hours ago






  • 2





    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
    20 hours ago





















21














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.






share|improve this answer































    2














    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.






    share|improve this answer








    New contributor




    Zimba is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.





















    • "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
      2 hours ago













    • Are there laws requiring IETF RFC compliance for email systems now?

      – grawity
      1 hour ago











    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.










    draft saved

    draft discarded


















    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









    79














    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.






    share|improve this answer



















    • 8





      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
      yesterday













    • @EsaJokinen What other choice does the MUA have when the recipients are on different domains? BCC simply forces that behaviour.

      – Selcuk
      yesterday






    • 3





      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
      yesterday













    • @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
      20 hours ago






    • 2





      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
      20 hours ago


















    79














    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.






    share|improve this answer



















    • 8





      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
      yesterday













    • @EsaJokinen What other choice does the MUA have when the recipients are on different domains? BCC simply forces that behaviour.

      – Selcuk
      yesterday






    • 3





      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
      yesterday













    • @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
      20 hours ago






    • 2





      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
      20 hours ago
















    79












    79








    79







    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.






    share|improve this answer













    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.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered yesterday









    PolynomialPolynomial

    101k32249342




    101k32249342








    • 8





      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
      yesterday













    • @EsaJokinen What other choice does the MUA have when the recipients are on different domains? BCC simply forces that behaviour.

      – Selcuk
      yesterday






    • 3





      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
      yesterday













    • @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
      20 hours ago






    • 2





      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
      20 hours ago
















    • 8





      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
      yesterday













    • @EsaJokinen What other choice does the MUA have when the recipients are on different domains? BCC simply forces that behaviour.

      – Selcuk
      yesterday






    • 3





      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
      yesterday













    • @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
      20 hours ago






    • 2





      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
      20 hours ago










    8




    8





    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
    yesterday







    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
    yesterday















    @EsaJokinen What other choice does the MUA have when the recipients are on different domains? BCC simply forces that behaviour.

    – Selcuk
    yesterday





    @EsaJokinen What other choice does the MUA have when the recipients are on different domains? BCC simply forces that behaviour.

    – Selcuk
    yesterday




    3




    3





    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
    yesterday







    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
    yesterday















    @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
    20 hours ago





    @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
    20 hours ago




    2




    2





    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
    20 hours ago







    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
    20 hours ago















    21














    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.






    share|improve this answer




























      21














      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.






      share|improve this answer


























        21












        21








        21







        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.






        share|improve this answer













        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.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered yesterday









        NaoyNaoy

        32113




        32113























            2














            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.






            share|improve this answer








            New contributor




            Zimba is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
            Check out our Code of Conduct.





















            • "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
              2 hours ago













            • Are there laws requiring IETF RFC compliance for email systems now?

              – grawity
              1 hour ago
















            2














            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.






            share|improve this answer








            New contributor




            Zimba is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
            Check out our Code of Conduct.





















            • "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
              2 hours ago













            • Are there laws requiring IETF RFC compliance for email systems now?

              – grawity
              1 hour ago














            2












            2








            2







            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.






            share|improve this answer








            New contributor




            Zimba is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
            Check out our Code of Conduct.










            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.







            share|improve this answer








            New contributor




            Zimba is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
            Check out our Code of Conduct.









            share|improve this answer



            share|improve this answer






            New contributor




            Zimba is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
            Check out our Code of Conduct.









            answered 20 hours ago









            ZimbaZimba

            471




            471




            New contributor




            Zimba is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
            Check out our Code of Conduct.





            New contributor





            Zimba is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
            Check out our Code of Conduct.






            Zimba is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
            Check out our Code of Conduct.













            • "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
              2 hours ago













            • Are there laws requiring IETF RFC compliance for email systems now?

              – grawity
              1 hour ago



















            • "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
              2 hours ago













            • Are there laws requiring IETF RFC compliance for email systems now?

              – grawity
              1 hour ago

















            "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
            2 hours ago







            "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
            2 hours ago















            Are there laws requiring IETF RFC compliance for email systems now?

            – grawity
            1 hour ago





            Are there laws requiring IETF RFC compliance for email systems now?

            – grawity
            1 hour ago










            Jenny B is a new contributor. Be nice, and check out our Code of Conduct.










            draft saved

            draft discarded


















            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.




            draft saved


            draft discarded














            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





















































            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







            Popular posts from this blog

            Færeyskur hestur Heimild | Tengill | Tilvísanir | LeiðsagnarvalRossið - síða um færeyska hrossið á færeyskuGott ár hjá færeyska hestinum

            He _____ here since 1970 . Answer needed [closed]What does “since he was so high” mean?Meaning of “catch birds for”?How do I ensure “since” takes the meaning I want?“Who cares here” meaningWhat does “right round toward” mean?the time tense (had now been detected)What does the phrase “ring around the roses” mean here?Correct usage of “visited upon”Meaning of “foiled rail sabotage bid”It was the third time I had gone to Rome or It is the third time I had been to Rome

            Slayer Innehåll Historia | Stil, komposition och lyrik | Bandets betydelse och framgångar | Sidoprojekt och samarbeten | Kontroverser | Medlemmar | Utmärkelser och nomineringar | Turnéer och festivaler | Diskografi | Referenser | Externa länkar | Navigeringsmenywww.slayer.net”Metal Massacre vol. 1””Metal Massacre vol. 3””Metal Massacre Volume III””Show No Mercy””Haunting the Chapel””Live Undead””Hell Awaits””Reign in Blood””Reign in Blood””Gold & Platinum – Reign in Blood””Golden Gods Awards Winners”originalet”Kerrang! Hall Of Fame””Slayer Looks Back On 37-Year Career In New Video Series: Part Two””South of Heaven””Gold & Platinum – South of Heaven””Seasons in the Abyss””Gold & Platinum - Seasons in the Abyss””Divine Intervention””Divine Intervention - Release group by Slayer””Gold & Platinum - Divine Intervention””Live Intrusion””Undisputed Attitude””Abolish Government/Superficial Love””Release “Slatanic Slaughter: A Tribute to Slayer” by Various Artists””Diabolus in Musica””Soundtrack to the Apocalypse””God Hates Us All””Systematic - Relationships””War at the Warfield””Gold & Platinum - War at the Warfield””Soundtrack to the Apocalypse””Gold & Platinum - Still Reigning””Metallica, Slayer, Iron Mauden Among Winners At Metal Hammer Awards””Eternal Pyre””Eternal Pyre - Slayer release group””Eternal Pyre””Metal Storm Awards 2006””Kerrang! Hall Of Fame””Slayer Wins 'Best Metal' Grammy Award””Slayer Guitarist Jeff Hanneman Dies””Bullet-For My Valentine booed at Metal Hammer Golden Gods Awards””Unholy Aliance””The End Of Slayer?””Slayer: We Could Thrash Out Two More Albums If We're Fast Enough...””'The Unholy Alliance: Chapter III' UK Dates Added”originalet”Megadeth And Slayer To Co-Headline 'Canadian Carnage' Trek”originalet”World Painted Blood””Release “World Painted Blood” by Slayer””Metallica Heading To Cinemas””Slayer, Megadeth To Join Forces For 'European Carnage' Tour - Dec. 18, 2010”originalet”Slayer's Hanneman Contracts Acute Infection; Band To Bring In Guest Guitarist””Cannibal Corpse's Pat O'Brien Will Step In As Slayer's Guest Guitarist”originalet”Slayer’s Jeff Hanneman Dead at 49””Dave Lombardo Says He Made Only $67,000 In 2011 While Touring With Slayer””Slayer: We Do Not Agree With Dave Lombardo's Substance Or Timeline Of Events””Slayer Welcomes Drummer Paul Bostaph Back To The Fold””Slayer Hope to Unveil Never-Before-Heard Jeff Hanneman Material on Next Album””Slayer Debut New Song 'Implode' During Surprise Golden Gods Appearance””Release group Repentless by Slayer””Repentless - Slayer - Credits””Slayer””Metal Storm Awards 2015””Slayer - to release comic book "Repentless #1"””Slayer To Release 'Repentless' 6.66" Vinyl Box Set””BREAKING NEWS: Slayer Announce Farewell Tour””Slayer Recruit Lamb of God, Anthrax, Behemoth + Testament for Final Tour””Slayer lägger ner efter 37 år””Slayer Announces Second North American Leg Of 'Final' Tour””Final World Tour””Slayer Announces Final European Tour With Lamb of God, Anthrax And Obituary””Slayer To Tour Europe With Lamb of God, Anthrax And Obituary””Slayer To Play 'Last French Show Ever' At Next Year's Hellfst””Slayer's Final World Tour Will Extend Into 2019””Death Angel's Rob Cavestany On Slayer's 'Farewell' Tour: 'Some Of Us Could See This Coming'””Testament Has No Plans To Retire Anytime Soon, Says Chuck Billy””Anthrax's Scott Ian On Slayer's 'Farewell' Tour Plans: 'I Was Surprised And I Wasn't Surprised'””Slayer””Slayer's Morbid Schlock””Review/Rock; For Slayer, the Mania Is the Message””Slayer - Biography””Slayer - Reign In Blood”originalet”Dave Lombardo””An exclusive oral history of Slayer”originalet”Exclusive! Interview With Slayer Guitarist Jeff Hanneman”originalet”Thinking Out Loud: Slayer's Kerry King on hair metal, Satan and being polite””Slayer Lyrics””Slayer - Biography””Most influential artists for extreme metal music””Slayer - Reign in Blood””Slayer guitarist Jeff Hanneman dies aged 49””Slatanic Slaughter: A Tribute to Slayer””Gateway to Hell: A Tribute to Slayer””Covered In Blood””Slayer: The Origins of Thrash in San Francisco, CA.””Why They Rule - #6 Slayer”originalet”Guitar World's 100 Greatest Heavy Metal Guitarists Of All Time”originalet”The fans have spoken: Slayer comes out on top in readers' polls”originalet”Tribute to Jeff Hanneman (1964-2013)””Lamb Of God Frontman: We Sound Like A Slayer Rip-Off””BEHEMOTH Frontman Pays Tribute To SLAYER's JEFF HANNEMAN””Slayer, Hatebreed Doing Double Duty On This Year's Ozzfest””System of a Down””Lacuna Coil’s Andrea Ferro Talks Influences, Skateboarding, Band Origins + More””Slayer - Reign in Blood””Into The Lungs of Hell””Slayer rules - en utställning om fans””Slayer and Their Fans Slashed Through a No-Holds-Barred Night at Gas Monkey””Home””Slayer””Gold & Platinum - The Big 4 Live from Sofia, Bulgaria””Exclusive! Interview With Slayer Guitarist Kerry King””2008-02-23: Wiltern, Los Angeles, CA, USA””Slayer's Kerry King To Perform With Megadeth Tonight! - Oct. 21, 2010”originalet”Dave Lombardo - Biography”Slayer Case DismissedArkiveradUltimate Classic Rock: Slayer guitarist Jeff Hanneman dead at 49.”Slayer: "We could never do any thing like Some Kind Of Monster..."””Cannibal Corpse'S Pat O'Brien Will Step In As Slayer'S Guest Guitarist | The Official Slayer Site”originalet”Slayer Wins 'Best Metal' Grammy Award””Slayer Guitarist Jeff Hanneman Dies””Kerrang! Awards 2006 Blog: Kerrang! Hall Of Fame””Kerrang! Awards 2013: Kerrang! Legend”originalet”Metallica, Slayer, Iron Maien Among Winners At Metal Hammer Awards””Metal Hammer Golden Gods Awards””Bullet For My Valentine Booed At Metal Hammer Golden Gods Awards””Metal Storm Awards 2006””Metal Storm Awards 2015””Slayer's Concert History””Slayer - Relationships””Slayer - Releases”Slayers officiella webbplatsSlayer på MusicBrainzOfficiell webbplatsSlayerSlayerr1373445760000 0001 1540 47353068615-5086262726cb13906545x(data)6033143kn20030215029