Questão O e-mail enviado para mim está endereçado para MAIL@MAIL.COM. Como isso é feito?


Recentemente eu recebi um email fraudulento e, para risos, abri-o para lê-lo. Muito simples e sem muito esforço.

Notei algo peculiar; Este e-mail não foi enviado para mim. No começo, suspeitei de um CC, ou de um BCC, mas em nenhum lugar ele tem meu endereço no correio. Eu forneci uma imagem abaixo. Como isso é feito?

enter image description here


103


origem


Poste os cabeçalhos das mensagens completas ... você também pode ter um endereço SMTP secundário no servidor de e-mail para o qual isso foi enviado, talvez. Os administradores do servidor de e-mail devem ser capazes de ajudar a aconselhá-lo sobre isso, mas editar você responde e publica também os detalhes do cabeçalho completo da mensagem. - Pimp Juice IT
Você provavelmente estava no cópia oculta campo do email. - Mokubai♦
Você não verá a lista de BCC, essa é a parte "B" lind. ;) - Ƭᴇcʜιᴇ007
@tuskiomi Não, não no Outlook. Gmail mostra bcc: me, talvez outros também o façam ... Mas se você olhar os cabeçalhos completos das mensagens, verá o seu e-mail lá - wysiwyg
@tuskiomi - Não, você nunca verá ninguém listado na BCC, nem mesmo você mesmo. Além disso, se for spam, pode até não haver uma lista BCC verdadeira; O spamware pode gerenciar a lista de destinatários da maneira que quiser, e o que importa é o diálogo do spamware com o servidor de email - não o conteúdo do email. A única maneira de ver o seu endereço de e-mail é ver os cabeçalhos da Internet. - Jeff Zeitlin


Respostas:


Uma mensagem de email da Internet consiste em duas partes. Podemos nos referir a eles como o envelope e a mensagem de carga útil ou simplesmente mensagem.

O envelope tem dados de roteamento: principalmente, é o endereço do remetente e um ou mais endereços de destinatários.

A mensagem tem o conteúdo da mensagem: linha de assunto, corpo da mensagem, anexos e assim por diante. Ele também carrega algumas informações técnicas, como rastreamento (Received:cabeçalhos, dados DKIM e assim por diante; assim como o exibido remetente e destinatário (o que você vê no From, To e Cc campos no seu cliente de e-mail).

Aqui está o ponto crucial: Os dois não precisam concordar!

Um servidor de e-mail examinará os dados do envelope para determinar como enviar a mensagem. Por outro lado, com poucas exceções, a mensagem em si será tratada apenas como dados. Particularmente, um servidor de correio bem comportado não olhe para a To: e Cc: campos da própria mensagem para determinar a lista de destinatários, nem olha para o From: campo para determinar o endereço do remetente.

Quando você redige e envia um e-mail, seu cliente de e-mail pega o que você digitou nos campos Para, Cc e Cco e traduz isso em informações de roteamento de envelope. Isso é feito principalmente removendo todos os nomes completos (deixando apenas endereços de e-mail), mas também pode envolver coisas como reconfiguração de endereço, expansão de alias e assim por diante. O resultado é uma lista de endereços de e-mail que são fornecidos ao servidor de e-mail com o qual seu cliente de e-mail está falando como a lista de destinatários. As listas Para e Cc são mantidas no e-mail, mas o Cco não é passado para o servidor, tornando-o invisível para os destinatários da mensagem. O endereço do remetente funciona de maneira muito semelhante.

Quando a mensagem chega ao seu destino final, os dados do envelope são descartados ou retidos nos cabeçalhos detalhados da mensagem. Essa é uma parte da razão pela qual o Spittin 'IT solicitou os cabeçalhos completos das mensagens em um comentário à sua pergunta.

Além disso, com o e-mail da Internet, é possível falar diretamente com um servidor de e-mail e, assim, injetar uma mensagem que tenha uma incompatibilidade entre os dados do envelope e os dados da mensagem. bem comportado cliente de e-mail não deixaria você compor. Além disso, servidores de e-mail fazem vários graus de verificação no endereço do remetente que são fornecidos nos dados do envelope; alguns mal verificá-lo em tudo além de ter certeza que é um sintaticamente Endereço de Email Válido. O cabeçalho From dos dados da mensagem está sujeito a um exame ainda menos detalhado.

Como o cliente de email de recebimento exibe o que está nos cabeçalhos De, Para e Cc, não os dados de endereço do envelope, é possível colocar o que quiser lá e o cliente de e-mail receptor não terá outro recurso senão confiar que é razoavelmente preciso. Para correio legítimo, geralmente é preciso o suficiente; para spam, quase nunca é.

No mundo dos objetos físicos tangíveis habitados por nós meros humanos, a remetente envelope e destinatário do envelope corresponde ao endereço de retorno e endereço do destinatário, respectivamente, que você escreve na parte externa do envelope; e a From: e To:/Cc: os cabeçalhos correspondem ao que você coloca como seu e os endereços do destinatário, respectivamente, na carta que você colocou no envelope.


154



Eu gostaria que as pessoas fizessem mais analogias do mundo real para que os outros entendessem qual é o equivalente físico. O "remetente" de um email é como a pessoa que entrega o envelope ao carteiro; o endereço "de" é aquele do qual se pretende que seja. Como se você pudesse ser uma secretária enviando em nome de outra pessoa, etc. - Mehrdad
@ Mehrdad Não; o (SMTP) remetente envelope endereço é como o endereço de retorno na parte externa do envelope (onde é enviado se não puder ser entregue), enquanto o endereço no From cabeçalho é tudo o que você escreve no pedaço de papel que você furar dentro o envelope e que o carteiro nem conhece. - Michael Kjörling
Eu estava pensando no cabeçalho Sender: quando escrevi isso, e foi apenas um exemplo. Basta dizer que seria bom adicionar um exemplo como este à sua resposta. - Mehrdad
o quantidade de negrito aqui é realmente desnecessário na melhor das hipóteses. E isso é apenas minha opinião. - JakeGould
@SupremeGrandRuler Porque o recebedor informações (em contraste com um possível Sender ou Return-Path) não estão contidas no email. Imagine que a lista completa de destinatários foi incluída, incluindo os endereços que o MUA obteve do campo Cco (lembre-se: SMTP (o protocolo do envelope) não sabe sobre Bcc, só sabe sobre destinatários) ... Isso seria uma questão de privacidade (e grande desperdício de espaço) não apenas em grandes listas de correio (operando pelo mesmo princípio que o Bcc). - Jonas Wielicki


tl; dr na parte inferior.

O protocolo SMTP não tem a noção de destinatários CC ou BCC; esta é uma convenção realizada por clientes de email. O servidor SMTP normalmente só se preocupa com informações e dados de roteamento. Essa é uma distinção importante, porque sem essa capacidade, o BCC não poderia existir. Como uma comunicação legítima da BCC, considere a seguinte transcrição do cliente:

HELO from-mail-server.com
MAIL FROM:<john.smith@from-mail-server.com>
RCPT TO:<anonymous@another-mail-server.com>
DATA
From: "John Smith" <john.smith@from-mail-server.com>
To: "Jane Doe" <jane.doe@to-mail-server.com>
BCC: "Anonymous" <anonymous@another-mail-server.com>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM

This is an important meeting notice. We'll meet tomorrow.

.

Agora, nesse caso, o Anonymous recebeu uma mensagem sobre essa reunião. No entanto, esta versão do email foi não encaminhado para Jane Doe; ela não sabe nada sobre o Anonymous ser notificado. Em contraste, Jane Doe receberá a mensagem com um corpo e um cabeçalho diferentes:

HELO from-mail-server.com
MAIL FROM:<john.smith@from-mail-server.com>
RCPT TO:<jane.doe@to-mail-server.com>
DATA
From: "John Smith" <john.smith@from-mail-server.com>
To: "Jane Doe" <jane.doe@to-mail-server.com>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM

This is an important meeting notice. We'll meet tomorrow.

.

Aqui, como o Anonymous estava no BCC, a mensagem enviada a Jane Doe não incluía a lista de destinatários do BCC. Por causa da convenção BCC, o envelope de e-mail pode não incluir destinatários que realmente receberam a mensagem e também pode incluir destinatários que não aparecem nos cabeçalhos das mensagens.

Como mencionado por @JonasWielicki, que eu também pretendia incluir, é que o MUA (Mail User Agent) é normalmente responsável por enviar os vários e-mails necessários para implementar o BCC. Servidores de e-mail não sabem nada sobre o BCC e, portanto, o MUA deve implementar o BCC enviando vários e-mails com diferentes rotas de e-mail especificadas nos cabeçalhos do envelope. Por esse motivo, os BCCs normalmente demoram mais para enviar do que os e-mails normais, porque diferentes corpos de mensagens devem ser construídos e enviados individualmente.

Isso também ajuda com algumas regras de conformidade de email. Por exemplo, um servidor de e-mail pode ter regras configuradas para automatizar automaticamente um servidor de e-mail de arquivamento (todos os e-mails enviados a ele também são arquivados), caso em que o servidor de e-mail pode nem ser um destinatário real.

HELO from-mail-server.com
MAIL FROM:<john.smith@from-mail-server.com>
RCPT TO:<mail-archive@archive-server.com>
DATA
From: "John Smith" <john.smith@from-mail-server.com>
To: "Jane Doe" <jane.doe@to-mail-server.com>
BCC: "Anonymous" <anonymous@another-mail-server.com>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM

This is an important meeting notice. We'll meet tomorrow.

.

Aqui, o destinatário é outra parte que é completamente reservada para qualquer um dos destinatários ou até mesmo o remetente. Esse é um recurso do protocolo, normalmente usado na retransmissão ou no arquivamento de mensagens.

O que essa mensagem de spam fez é aproveitar esse comportamento. É uma lacuna padrão que tecnicamente deve funcionar com qualquer servidor de email compatível. É claro que muitos servidores atualizados usam "extensões" como o DKIM para verificar se esse e-mail é autêntico, mas ainda existem muitos servidores de e-mail antigos que não se importam, simplesmente porque é tentador não consertar as coisas que não estão quebradas.

Observe também como eu especifiquei um cabeçalho de data. Isso pode ser qualquer valor arbitrário (mas bem formatado); Muitos clientes terão todo o prazer em exibir qualquer período legal, desde o passado distante até o futuro distante. Eu pessoalmente enviei um e-mail para mim anos atrás, que permanecerá no topo da minha caixa de correio, muito depois da minha expectativa de vida, bem como um e-mail que antecede a minha conta de e-mail e meu próprio nascimento.

tl; dr

Então, em resumo, o remetente falsificou um e-mail, o servidor de e-mail de origem aceitou / retransmitiu, seu servidor de e-mail aceitou e armazenou na sua caixa de entrada, e seu cliente exibiu fielmente os dados que estavam na sua caixa de entrada, sem contornar qualquer segurança. A segurança "Envio" é muitas vezes muito menos restrita do que "receber" segurança nessa perspectiva, já que o POP3 quase sempre requer um nome de usuário e senha antes que você possa acessar uma caixa de correio (você poderia teoricamente contornar isso, mas não sei serviços de correio que o fazem).


23



Você deve observar que a remoção de Bcc é tipicamente não manipulados por servidores de correio (a transcrição SMTP que você forneceu sugere o contrário, porque o HELO soa como um servidor de e-mail e não como um MUA). Fornecer uma cópia com o cabeçalho Bcc à pessoa endereçada nesse cabeçalho requer trabalho extra pelo MUA enviando dois e-mails separados. - Jonas Wielicki
@JonasWielicki Esse é um bom ponto. Eu adicionei uma edição para esse efeito. - phyrfox
Se você adicionar uma linha Cco a um e-mail entregue, não será mais cego :) - eckes
Na verdade, exigir que o cliente envie várias mensagens no caso de BCC está incorreto. É perfeitamente correto enviar apenas uma única mensagem. O cliente SMTP pode listar vários RCPT TO instruções. O único requisito é que o servidor SMTP de recebimento seja o servidor autoritativo para ambos os destinatários ou esteja disposto a retransmitir para qualquer um que não seja. - Patrick


O SMTP e o email são serviços de Internet muito antigos, de uma era em que a segurança e a autenticação eram levadas muito menos a sério (o DNS é outro exemplo). O design do protocolo não faz nenhum esforço para verificar a autenticidade do endereço do remetente e apenas valida o endereço do destinatário na medida em que ele garante que o e-mail seja entregue.

O email é transmitido através do protocolo SMTP. O protocolo SMTP é relativamente burro; Ele fornece um recurso para transmitir texto simples para um endereço de e-mail e muito pouco mais. A estrutura deste texto simples é definida por RFC 5322. A idéia geral é que o texto do email tem metadados chamados de cabeçalho e o corpo real da mensagem. Este cabeçalho de e-mail é gerado pelo remetente (nenhum deles pode ser confiável) e contém campos como "para:", "de:", "assunto:", etc ...

O protocolo SMTP não (e não deve) validar se os cabeçalhos de email correspondem a algumas poucas coisas definidas no protocolo SMTP, que são essencialmente seu endereço de email e um endereço de email do remetente que nunca é validado de forma alguma.

Quase tudo em uma mensagem de email pode ser falso.

A única coisa remotamente confiável sobre o conteúdo do email hoje são as assinaturas DKIM, que provam que o email foi processado através de um servidor de email sancionado pelo registrante do domínio. Indo mais a fundo, você descobriria que esse e-mail de esquema não tem assinatura DKIM.


6



Eu adicionaria a final Received: cabeçalho adicionado pelo seu próprio sistema para as partes confiáveis. - Hagen von Eitzen


Endereço To no cabeçalho do email é para fins informativos e é mostrado pelo cliente de email. O endereço do destinatário real é fornecido com RCPT TO no SMTP. É o mesmo se você escrever carta, colocar em envelope, escrever Endereço-1 no envelope. Então vá para courier, dê outro endereço-2. O correio coloca seu envelope em envelope maior com Address-2 e a remessa irá para lá. Sua secretária (software cliente de e-mail) coloca o envelope externo na lixeira e mostra o envelope interno com o endereço-1. Você pode ver isso com a visualização RAW da mensagem de email.


3





Este é um aspecto ligeiramente diferente, baseado no exame de cabeçalhos. As outras respostas lidam com os detalhes do SMTP melhor do que eu.

Se conseguir obter os cabeçalhos completos da sua mensagem, pesquise-os pelo seu endereço, você pode encontrá-lo em um campo chamado Envelope-to, Delivered-to ou X-Apparently-to. O primeiro é usado pelo meu provedor de e-mail, o segundo pelo Gmail; Eu vi o terceiro usado também. Estes são campos diferentes, mas para nossos propósitos tendem a significar a mesma coisa: a caixa de correio para entregar a mensagem. Eu testei enviando do outlook (versão desktop) com o destinatário BCCed.

Meu provedor de e-mail também usa o Delivered-To campo, mas para o nome da caixa de correio em seu servidor. Este não é o meu endereço de e-mail, embora pareça um (pense ChrisH-$ACCOUNTNAME@$SERVER.mail.com).

O Outlook (combinado com o Exchange Server), por outro lado, não inclui nos cabeçalhos um único campo com o endereço de e-mail do destinatário, se você estiver listado como BCC.


2