Como funciona o email?

Primeiro, você usa um agente de usuário de email ou MUA para ler e enviar email do seu dispositivo (como o gmail ou o aplicativo de email nos dispositivos Apple). Esses programas estão ativos apenas quando você os utiliza. Geralmente, eles se comunicam com um agente de transferência de mensagens ou MTA (também conhecido como servidor de email, host MX e trocador de mensagens), que serve para receber e armazenar seus emails. Os e-mails são armazenados remotamente até você abrir o MUA para verificar seu e-mail. Os emails são entregues pelos agentes de entrega de email (MDA), que geralmente são fornecidos com o MTA.

O correio costumava ser enviado para um servidor de correio usando SMTP ou Simple Mail Transfer Protocol. SMTP é um protocolo de comunicação para email. Mesmo agora, embora muitos sistemas proprietários como o Microsoft Exchange e programas de webmail como o Gmail usem seus próprios protocolos internamente, eles usam SMTP para transferir mensagens para fora de seus sistemas (por exemplo, se um usuário do Gmail quiser enviar um email para um cliente do Outlook).

O correio seria então baixado do servidor usando o POP3 (Protocolo da Agência Postal) O POP3 é um protocolo da camada de aplicativo que fornece acesso através de uma rede IP (Internet Protocol) para que um aplicativo de usuário entre em contato com uma caixa de correio em um servidor de correio. Ele pode conectar, recuperar mensagens, armazená-las no computador do cliente e excluí-las ou retê-las no servidor. Ele foi projetado para poder gerenciar conexões de Internet temporárias, como discagem (para conectar e recuperar e-mails quando conectado, além de permitir que você visualize as mensagens quando estiver offline). Isso era mais popular quando o acesso discado era mais amplo.

Agora, o IMAP, Internet Message Access Protocol, substituiu principalmente o POP3. O IMAP pode permitir que vários clientes gerenciem a mesma caixa de correio (para que você possa ler seu e-mail na área de trabalho, laptop e telefone, etc., e todas as suas mensagens estarão lá, organizadas da mesma maneira). Eventualmente, o webmail substituiu ambos. O Webmail permite que você faça login em um site e receba mensagens de qualquer lugar ou dispositivo (sim!), No entanto, você precisa estar conectado à Internet enquanto o usa. Se o site (como o gmail) for o seu MUA, você não precisará conhecer as configurações do servidor SMTP ou IMAP.

Como o email é protegido?

Infelizmente, a segurança não foi realmente incorporada aos protocolos de email desde o início (como a maioria dos protocolos iniciais da Internet). Os servidores esperavam receber qualquer mensagem de qualquer pessoa e passá-la para qualquer outro servidor, o que poderia ajudar a rotear a mensagem para seu destino final (o destinatário no campo para:). Sem surpresa, isso se tornou um problema quando a Internet se expandiu de alguns grupos governamentais e de pesquisa para algo que a maior parte do mundo usa para fazer basicamente tudo. Logo, os e-mails de spam e phishing se tornaram (e permanecem) um grande problema para todos. Em resposta, tentamos coletivamente implementar várias medidas que impedem as pessoas de lerem as mensagens de outros (criptografia) e validar que as mensagens realmente vieram do suposto remetente (autenticação).

A maioria dos locais usa TLS (segurança da camada de transporte, a substituição do SSL, secure sockets layer), um protocolo criptográfico que fornece criptografia em trânsito (quando a mensagem está sendo transmitida, mas não quando os dados estão em repouso (por exemplo, sendo armazenados no seu computador)). Isso garante que uma mensagem não seja alterada ou bisbilhotada enquanto viaja do MTA para o MTA. No entanto, isso não verifica se a mensagem não foi modificada durante a viagem. Por exemplo, se o email passar por vários servidores de email antes de atingir seu destino final, o uso do TLS garantirá que ele seja criptografado entre os servidores, mas cada servidor poderá alterar o conteúdo da mensagem. Para resolver isso, criamos SPF, DKIM e DMARC.

SPF (Sender Policy Framework)

O SPF permite que o proprietário de um domínio (como google.com) defina um registro TXT em seu DNS, que declara quais servidores têm permissão para enviar email desse domínio (para obter instruções sobre como fazer isso para vários provedores de hospedagem, confira esse site)

Como é que isso funciona?

Este registro lista os dispositivos (geralmente por IP) que são permitidos e podem terminar em uma das seguintes opções:

-all = Se a verificação falhar (a origem do email não é um dos dispositivos listados), o resultado será um HardFail. A maioria dos sistemas de correio marcará essas mensagens como spam.

? all = = Se a verificação falhar (a origem do email não é um dos dispositivos listados), o resultado será neutro. Isso geralmente é usado para teste, não para domínios de produção.

~ all = Se a verificação falhar (a origem do email não é um dos dispositivos listados), o resultado será um SoftFail. Isso significa que esta mensagem é suspeita, mas não é necessariamente um problema conhecido. Alguns sistemas de correio marcam essas mensagens como spam, mas a maioria não.

Os cabeçalhos SPF podem ser úteis para os próprios servidores, pois estão processando mensagens. Por exemplo, se um servidor estiver na borda de uma rede, ele saberá que as mensagens recebidas devem vir dos servidores no registro SPF do remetente. Isso ajuda os servidores a se livrar do spam mais rapidamente. Embora isso pareça ótimo, infelizmente, existem alguns problemas importantes com o SPF.

1. O SPF não informa ao servidor de email o que fazer com a mensagem – o que significa que uma mensagem pode falhar em uma verificação do SPF e ainda ser entregue.

2. Um registro SPF não está olhando para o endereço ‘de’ que o usuário vê, mas para o ‘caminho de retorno’, que é basicamente o equivalente ao endereço de retorno que você escreve em uma carta. Ele informa aos servidores de email que lidam com a letra onde devolver a mensagem (e ela é armazenada nos cabeçalhos de email – essencialmente, os servidores de informações técnicas usam para processar email). Isso significa que eu posso colocar o que eu quiser no endereço from: e isso não afetará a verificação do SPF. De fato, esses dois endereços de email podem ser relativamente falsificados por um hacker. Como não há criptografia envolvida, os cabeçalhos SPF não podem ser totalmente confiáveis.

3. Os registros SPF precisam ser atualizados constantemente, o que pode ser difícil em organizações grandes e em constante mudança.

4. O encaminhamento interrompe o SPF. Isso ocorre porque, se um e-mail de, digamos google.com, for encaminhado por [email protected], o remetente do envelope permanecerá inalterado (o endereço de origem ainda indica google.com) e o servidor de e-mail receptor achar que está reivindicando ser do google .com, mas é proveniente de bobsburgers.com, portanto, falha na verificação do SPF (mesmo que o email seja proveniente de google.com).

Para mais informações sobre o SPF, confira these artigos. Você pode verificar se um domínio específico possui registros SPF e DMARC configurados aqui.

DKIM (DomainKeys Identified Mail)

DKIM é semelhante ao SPF. Ele também usa registros TXT no DNS do domínio de envio e fornece alguma autenticação da própria mensagem. Ele tenta verificar se as mensagens não foram alteradas em trânsito.

Como é que isso funciona?

O domínio de envio gera um par de chaves públicas / privadas e coloca a chave pública no registro DNS TXT do domínio (se você não souber o que é um par de chaves públicas / privadas, confira Este artigo criptografia). Em seguida, os servidores de email do domínio (no limite externo – os servidores que estão enviando emails para fora do domínio (por exemplo, de gmail.com para outlook.com)) usam a chave privada para gerar uma assinatura de todo o corpo da mensagem, incluindo cabeçalhos. A geração de uma assinatura geralmente requer que o texto seja hash e criptografado (para obter mais detalhes sobre esse processo, consulte Este artigo)

Os servidores de recebimento de email usam a chave pública no registro DNS TXT para descriptografar a assinatura e, em seguida, misturar a mensagem e os cabeçalhos relevantes (todos os cabeçalhos criados enquanto o email estava dentro da infraestrutura do remetente – por exemplo, se vários servidores do Gmail processassem o email antes dele. foi enviado externamente para outlook.com). O servidor verificará se os dois hashes correspondem. Se o fizerem, a mensagem provavelmente não será alterada (a menos que alguém tenha comprometido a chave privada do remetente) e legitimamente do suposto remetente. Se os hashes não corresponderem, a mensagem é não do remetente pretendido ou foi alterada por outro servidor em trânsito ou ambos.

O DKIM faz um trabalho muito bom em uma tarefa muito específica – respondendo à pergunta ‘este email foi alterado em trânsito ou não do suposto remetente?’. No entanto, é tudo o que faz. Ele não informa como lidar com os e-mails que falham neste teste, qual servidor pode ter alterado a mensagem ou quais alterações foram feitas. O DKIM também é usado por alguns ISPs, ou provedores de serviços de Internet, para determinar a reputação do seu domínio (você está enviando muito spam? Você tem pouco envolvimento? Com ​​que frequência os seus emails são devolvidos?)

Para mais informações sobre o DKIM, confira este artigo. Você pode validar um registro DKIM aqui.

DMARC (autenticação, relatório e conformidade de mensagens com base no domínio)

O DMARC é essencialmente instruções para servidores de correio sobre como lidar com registros SPF e DKIM. Ele não realiza nenhum teste próprio, mas informa aos servidores de email como lidar com as verificações realizadas pelo SPF e pelo DKIM.

Os ISPs participantes examinarão os registros DMARC publicados e os usarão para determinar como lidar com falhas de DKIM ou SPF. Por exemplo, uma marca comumente falsificada pode publicar um registro DMARC que diz que, se o DKIM ou o SPF falhar, descarte a mensagem. Freqüentemente, os ISPs também enviarão relatórios sobre a atividade do seu domínio para você com a origem do email e se foi aprovado / reprovado no DKIM / SPF. Isso significa que você poderá ver quando as pessoas estão falsificando (pretendendo enviar) seu domínio ou alterando suas mensagens.

Para implementar o DMARC, você precisa criar um registro DMARC, com base nas suas necessidades (do monitoramento do tráfego de e-mail para descobrir quais são todas as suas fontes de e-mail para solicitar ações, como rejeitar qualquer e-mail que falhe no DKIM ou no SPF). Você pode aprender mais sobre como fazer isso aqui e aqui.

Para mais informações sobre o DMARC, confira Este artigo. Você pode verificar se um domínio específico possui registros SPF e DMARC configurados aqui.

Nenhuma dessas medidas de segurança é perfeita, mas juntas elas fazem um trabalho decente ao nos ajudar a melhorar a segurança dos sistemas de email em todo o mundo. Quanto mais organizações adotarem essas medidas (usando implementações de código aberto ou pagando por um produto), melhor será para todos. A segurança adicionada após o desenvolvimento de um protocolo ou produto geralmente é mais cara, menos eficaz e mais difícil de implementar do que a segurança incorporada ao produto. No entanto, a maioria dos protocolos em que a Internet atual se baseia foram projetados para a Internet inicial – para um pequeno grupo de entusiastas, cientistas e membros do governo – não uma rede mundial na qual administramos prédios, dispositivos inteligentes, transporte público, usinas nucleares (!) etc. Assim, como a Internet continuou a se expandir, precisamos continuar adaptando e desenvolvendo novas maneiras de proteger os sistemas nos quais confiamos.