O e-mail enviado a mim é endereçado a MAIL@MAIL.COM. Como isso é feito?

Recentemente, recebi um e-mail fraudulento e, para rir, abri-o para ler. Muito simples e sem muito esforço.

Eu notei algo peculiar; este email não foi endereçado a mim. No começo, eu suspeitava de um CC ou BCC, mas em nenhum lugar ele tem meu endereço no correio. Eu forneci uma imagem abaixo. Como isso é feito?

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

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

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 Received:cabeçalhos trace ( ), dados DKIM e assim por diante; bem como os exibidos endereços do remetente e do destinatário (o que você vê na From, Toe Cccampos em seu cliente de email).

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

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

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

Quando a mensagem atinge seu destino final, os dados do envelope são jogados fora ou retidos nos cabeçalhos detalhados da mensagem. Essa é uma parte do motivo pelo qual a Spittin 'IT solicitou os cabeçalhos completos da mensagem em um comentário à sua pergunta.

Além disso, com o email da Internet, é possível conversar diretamente com um servidor de email e, assim, injetar uma mensagem que não corresponda entre os dados do envelope e os dados da mensagem que um cliente de email normal e bem comportado não deixe você compor. Além disso, os servidores de correio realizam vários graus de verificação no endereço do remetente que são fornecidos nos dados do envelope; alguns mal o verificam além de garantir que seja um endereço de email sintaticamente válido. O cabeçalho De dos dados da mensagem está sujeito a ainda menos escrutínio.

Como o cliente de email de recebimento exibe o que há nos cabeçalhos De, Para e Cc, e não os dados de endereço do envelope, é possível colocar o que você quiser lá e o cliente de email de recebimento 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, seres humanos, o remetente e o destinatário do envelope correspondem ao endereço de retorno e ao endereço do destinatário, respectivamente, que você escreve na parte externa do envelope; e os cabeçalhos From:e To:/ Cc:correspondem ao que você coloca como endereço do seu e do destinatário, respectivamente, na carta que você coloca no envelope.

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 correio. O servidor SMTP normalmente se preocupa apenas com informações e dados de roteamento. Esta é uma distinção importante, porque sem essa capacidade, o BCC não poderia existir. Como uma comunicação BCC legítima, 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, neste caso, o Anonymous recebeu uma mensagem sobre esta reunião. No entanto, esta versão do email não foi roteada para Jane Doe; ela não sabe nada sobre o Anonymous ser notificado. Em contraste, Jane Doe receberá a mensagem com um corpo e 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 para Jane Doe não incluía a lista de destinatários do BCC. Devido à convenção BCC, o envelope de email 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 da mensagem.

Como mencionado por @JonasWielicki , que eu também pretendia incluir, é que o MUA (Mail User Agent) normalmente é responsável por enviar os vários emails necessários para implementar o BCC. Os servidores de email não sabem nada sobre o BCC e, portanto, o MUA deve implementá-lo enviando vários emails com rotas de email diferentes especificadas nos cabeçalhos do envelope. Por esse motivo, os BCCs normalmente levam mais tempo 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 email pode ter regras configuradas para enviar automaticamente um servidor de arquivamento para Cco (todos os emails enviados a ele também são arquivados); nesse caso, o servidor de email talvez nem seja 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 não é totalmente revelada a nenhum dos destinatários ou mesmo ao remetente. Esse é um recurso do protocolo, normalmente usado na retransmissão ou arquivamento de mensagens.

O que essa mensagem de spam fez foi tirar proveito desse comportamento. É uma brecha padrão que tecnicamente deve funcionar com qualquer servidor de email compatível. Obviamente, muitos servidores atualizados usam "extensões" como o DKIM para verificar se um email é autêntico, mas ainda existem muitos servidores de correio antigos que não se importam, simplesmente porque é tentador não consertar coisas que não estão quebradas.

Observe também como eu especifiquei um cabeçalho de data. Pode ser qualquer valor arbitrário (mas bem formatado); muitos clientes exibirão com prazer qualquer intervalo de datas legal, do passado distante ao futuro distante. Eu pessoalmente enviei um e-mail para mim mesmo anos atrás, que permanecerá no topo da minha caixa de correio por muito tempo após a minha expectativa de vida, bem como um e-mail que antecede minha conta de e-mail e meu próprio nascimento.

tl; dr

Portanto, em resumo, o remetente falsificou um email, o servidor de email de origem aceitou / retransmitiu, seu servidor de email aceitou e armazenou na sua caixa de entrada, e seu cliente exibiu fielmente os dados que estavam na sua caixa de entrada para você, tudo sem contornar qualquer segurança. A segurança de "envio" geralmente é muito menos restrita do que a segurança de "recebimento" nessa perspectiva, pois o POP3 quase sempre exige um nome de usuário e senha antes de você poder acessar uma caixa de correio (teoricamente, você pode contornar isso, mas não conheço nenhum legítimo serviços de correio que fazem).

SMTP e email são serviços de Internet muito antigos de uma época 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 garante que o correio seja entregue.

O email é transmitido através do protocolo SMTP. O protocolo SMTP é relativamente idiota; fornece uma facilidade para transmitir texto sem formatação para um endereço de e-mail e muito pouco mais. A estrutura deste texto sem formatação é definida pelo RFC 5322 . A ideia geral é que o texto do email tenha metadados chamados de cabeçalho e o corpo do texto real da mensagem. Este cabeçalho do email é gerado pelo remetente (nada disso pode ser confiável) e contém campos como "para:", "de:", "assunto:", etc ...

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

Quase tudo em uma mensagem de email pode ser falso.

Hoje, a única coisa que é remotamente confiável no conteúdo de e-mail são as assinaturas DKIM, que provam que o e-mail foi processado por meio de um servidor de e-mail sancionado pelo registrante do domínio. Indo mais fundo, você descobriria que esse email fraudulento não possui assinatura DKIM.

O endereço Tono cabeçalho do email é para fins informativos e é mostrado pelo cliente de email. O endereço real do destinatário é fornecido RCPT TOno SMTP. É o mesmo se você escrever uma carta, colocar um envelope, escrever o Endereço 1 no envelope. Então vá ao correio, dê outro Endereço-2. O correio coloca seu envelope em um envelope maior com o Endereço-2 e a remessa vai para lá. Sua secretária (software cliente de email) 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.

Essa é uma aparência um pouco diferente, com base no exame de cabeçalhos. As outras respostas lidam melhor com os detalhes do SMTP do que eu.

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

Meu provedor de email também usa o Delivered-Tocampo, mas 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 servidor Exchange), por outro lado, não inclui nos cabeçalhos um único campo com o endereço de email do destinatário se você estiver listado como Cco.