Posso recuperar endereços de e-mail do BCC?

Você não pode. Você simplesmente não terá nenhuma informação sobre o cabeçalho Bcc quando receber o e-mail, então não há nada para “desmascarar”.

A maneira como o Bcc é projetado é especificada em RFC 2822 , na seção 3.6.3. Para citar a especificação:

O campo “Cco:” (onde “Cco” significa “Cópia oculta”) contém endereços de destinatários da mensagem cujos endereços não devem ser revelados a outros destinatários da mensagem. Existem três maneiras de usar o campo “Cco:”. No primeiro caso, quando uma mensagem contendo um campo “Cco:” é preparada para ser enviada, a linha “Cco:” é removida mesmo que todos os destinatários (incluindo aqueles especificados no campo “Cco:”) sejam enviados um cópia da mensagem. No segundo caso, os destinatários especificados nas linhas “Para:” e “Cc:” recebem uma cópia da mensagem com a linha “Cco:” removida como acima, mas os destinatários na linha “Cco:” recebem um cópia separada da mensagem contendo uma linha “Bcc:”. (Quando há vários endereços de destinatário no campo “Cco:”, algumas implementações realmente enviam uma cópia separada da mensagem para cada destinatário com um “Cco:” contendo apenas o endereço desse destinatário específico.) Por fim, como um “Cco : “o campo não pode conter endereços, um campo” Cco: “pode ser enviado sem endereços indicando aos destinatários que cópias ocultas foram enviadas para alguém. O método a ser usado com os campos “Cco:” depende da implementação, mas consulte a seção “Considerações de segurança” deste documento para uma discussão de cada um.

Quando uma mensagem é uma resposta a outra mensagem, o caixas de correio dos autores da mensagem original (as caixas de correio no campo “De:”) ou caixas de correio especificadas no campo “Responder para:” (se existir) PODEM aparecer no campo “Para:” da resposta, visto que estes normalmente seriam os destinatários principais da resposta. Se uma resposta for enviada a uma mensagem com campos de destino, geralmente é desejável enviar uma cópia da resposta a todos os destinatários da mensagem, além do autor. Quando tal resposta é formada, os endereços nos campos “Para:” e “Cc:” da mensagem original PODEM aparecer no campo “Cc:” da resposta, uma vez que normalmente são destinatários secundários da resposta. Se um campo “Bcc:” estiver presente na mensagem original, os endereços nesse campo PODEM aparecer no campo “Bcc:” da resposta, mas NÃO DEVEM aparecer nos campos “Para:” ou “Cc:”.

Nota: Alguns aplicativos de e-mail possuem comandos de resposta automática que incluem os endereços de destino da mensagem original nos endereços de destino da resposta. O comportamento desses comandos de resposta depende da implementação e está além do escopo deste documento. Em particular, a inclusão ou não dos endereços de destino originais quando a mensagem original tinha um campo “Responder para:” não é abordada aqui.

Em Pratique o caso em que os destinatários Para e Cc não recebem nenhuma linha Cco, mas cada endereço Cco recebe uma linha Cco contendo apenas seu endereço de e-mail, é mais comum. Isso não fornece nenhuma indicação de Cco para os destinatários Para e Cc e indica os destinatários Bcc “ed que o e-mail foi enviado para eles por meio do uso de Bcc sem revelar outros destinatários Bcc.

Comentários

• each Bcc'ed address receives a Bcc line containing only their email address, is most common. É? Isso exigiria o envio da mensagem várias vezes em vez de uma única mensagem com vários comandos RCPT TO:. Qual MUA faria isso?
• @EsaJokinen Que outra escolha o MUA tem quando os destinatários estão em domínios diferentes? O BCC simplesmente força esse comportamento.
• O MUA o envia apenas uma vez para o MTA, e o MTA começa a entregá-lo separadamente para todos os domínios diferentes.O fato é que os MTAs não ‘ geralmente se incomodam em adicionar RCPT TO como Bcc:. É ‘ mais provável em um Received: cabeçalho como for <[email protected]>.
• Isso ‘ é verdade: você sabe que era Bcc ‘ d (ou não divulgado) por não estar no To & Cc cabeçalhos. O MUA apenas salva o Bcc ao salvar o e-mail na pasta de envio do remetente, mas ‘ não faz parte da mensagem enviada via SMTP .
• @EsaJokinen Gmail faz isso – na verdade, inclui o cabeçalho Bcc na mensagem. Eu não ‘ não sei de improviso de qualquer outra pessoa que o faça.

O padrão Request For Comments (RFC) (publicado pela The Internet Engineering Task Force (IETF)) especifica que os destinatários de um e-mail, enviado a destinatários especificados no cabeçalho “BCC”, podem receber o e-mail, mas não ter conhecimento de nenhum outro destinatários mencionados no cabeçalho. Especificamente, “os endereços não devem ser revelados a outros destinatários da mensagem”.

É uma solicitação (não é um mandato) aos servidores SMTP para refletir a prática atual (protocolo) para a comunidade da Internet b y A Internet Society.

No entanto, aqueles considerados não compatíveis pode ser segregado e, se for considerado desonesto, será banido / colocado na lista negra e até mesmo processado quando considerado por conduzir atividades em violação das leis da jurisdição.

Portanto, se você for o destinatário de um e-mail de um servidor compatível (de e-mail), não receberá outro e-mails de destinatários mencionados no campo “BCC”, a menos que você “esteja no controle do servidor de envio (SMTP), do servidor de entrada (POP, IMAP etc.) e de todos os servidores de retransmissão que rotearam os pacotes IP.

Comentários

• ” Aqueles que não estiverem em conformidade podem ser segregados e, se forem considerados invasores, será banido / colocado na lista negra e até mesmo processado quando for descoberto que conduza atividades em violação das leis da jurisdição. ” – Eu suporia ggest este é um resultado extremamente improvável para um servidor que vazou endereços BCC. Além disso, se uma mensagem for BCC ‘ d para [email protected] e [email protected], e foo.com e y.com tiverem servidores SMTP diferentes, bar.com irá nem mesmo receber o endereço [email protected] ‘ s para vazar, então não haveria nenhum ponto em ” segregar ” já que seus vazamentos afetam apenas seus próprios usuários.
• Existem leis que exigem conformidade com RFC da IETF para sistemas de e-mail agora?
• @grawity: Você ‘ d estar procurando por leis que proíbam a aplicação de melhores práticas , métodos geralmente aceitos e declarações genéricas semelhantes. Cf. GDPR 5.1 (f) ” medidas técnicas ou organizacionais apropriadas ”
• @MSalters supostamente significavam prescrever em vez de seu oposto, proscrever …
• @grawity não diretamente, mas um servidor que divulgou informações, apesar dos padrões dizerem o contrário, faria seu operador violar várias leis de privacidade como GDPR ou CCPA)