Como funciona um e-mail

e acima de tudo porque acaba em spam

Por ser um assunto complexo e que se presta a extensas discussões técnicas, para que seja compreendido pelo público "normal" tento simplificar. Vamos fingir que temos dois amigos que se escrevem, o remetente A se chama ARENA e o destinatário B é chamado BUGO.

Coso escreve um e-mail para Bugo. O que acontece nos bastidores?
Coso Server A envia um email para Bugo Server B.
Em termos simples, cosi@vattelapesca.it escreve para bugo@nonmissassare.com.

Está tudo bem para você. Onde está o problema? Na realidade, este não é realmente o caso. Isso acontece muito. Deixo de fora os detalhes de como o e-mail é "packetizado" e enviado em pacotes por vários caminhos diferentes pelo universo da internet para ser recomposto pelo servidor de e-mail Bugo porque fica uma coisa muito longa e sairíamos do caminho.

Vamos voltar para cosi@vattelapesca.it para quem escreve bugo@nonmissassare.com.

Coso não recebe resposta. Os dias passam e ainda não obtive resposta. No entanto, é uma comunicação importante! Então ele liga para Bugo no telefone e Bugo responde que nunca recebeu o e-mail!

Geralmente, Bugo liga para seu gerente de TI ou para o gerente de hospedagem e, em seguida, aquele que fornece as caixas de correio e o servidor de correio começa a reclamar: “Aqui! Devolva meu dinheiro, ladrão! Os e-mails não funcionam!!! não recebo emails de cosi@vattelapesca.it.

Todos vocês tiveram um pouco desse problema. A questão é que depois que tudo passou, hoje com os problemas de segurança que existem, as coisas mudaram, graças também a vocês que são grandes trapalhões.

Quando o Coso envia um e-mail para o Bugo, o servidor de e-mail do Bugo verifica, faz como o salmão e refaz o caminho inverso do e-mail recebido. E verifique algumas coisas:

A primeira coisa que verifica é se o remetente é realmente quem diz ser. Pode parecer trivial para você, mas não é! O fato de você ser cosi@vattelapesca.it não significa absolutamente nada.

Na verdade, o servidor de correio Bugo verifica se o IP do host do remetente, ou seja, "vattelapesca.com” neste caso, corresponde ao IP do servidor de correio. Banal? Não! Muitas vezes é o primeiro problema encontrado. Os gerentes de TI internos das empresas geralmente cometem o erro simples de configurar incorretamente a zona DNS do domínio e não atribuir corretamente o IP do servidor de e-mail. Isso é especialmente verdadeiro se houver vários domínios diferentes em um servidor. Muitas vezes, no caso de quem vende serviços de hospedagem particionando o servidor que gerenciam, eles se enganam nesse ponto. Os grandes provedores lidam com esse problema de maneira sistêmica e, portanto, o problema quase nunca é encontrado. Mas em grandes/médias empresas, com gerentes de TI não tão à altura, que gerenciam seus próprios servidores de e-mail internamente, esse problema se torna frequente.

Basicamente, o servidor de e-mail Bugo arquiva o e-mail como spam porque não entende quem é o remetente. Nesses casos, até mesmo o e-mail é totalmente queimado e nem mesmo é recuperável da pasta de spam.

Em vez disso, vamos garantir que a configuração do servidor de correio do remetente esteja correta e que o servidor de correio Bugo, fazendo o inverso, certifique que o IP está correto e, portanto, o remetente é quem diz ser.

Mas o correio ainda não chega ao seu destino. Novamente a ligação de Bugo para seu gerente de TI, etc... O gerente de TI verifica e verifica se a marcação SPF está faltando. Ai! O que é a marcação SPF?

Sender Policy Framework (SPF) é um sistema de validação de e-mail projetado para detectar tentativas de falsificação de e-mail. O sistema oferece aos administradores de um domínio de e-mail um mecanismo para definir os hosts autorizados a enviar mensagens desse domínio, permitindo que o destinatário verifique sua validade.[ A lista de hosts autorizados a enviar e-mails para um determinado domínio é publicada no Domain Name System (DNS) para esse domínio, na forma de registros TXT especialmente formatados. O phishing e, às vezes, até o spam, usam endereços de remetentes falsos, portanto, postar e verificar os registros SPF pode ser considerado, em parte, uma técnica anti-spam.

Traduzido, o servidor de correio Bugo verifica se o servidor de correio Coso tem autorização para enviar e-mails do host Coso, ou seja, cosi@vattelapesca.it, verificando assim a validade do remetente e a lista de hosts autorizados. Se faltar a marcação SPF, muitos servidores de e-mail, pelo menos os sérios hoje, queimam o e-mail, muitas vezes você nem encontra mais na caixa de spam.

Finalizado? Não!

Vamos fingir que cosi@vattelapesca.it também tem a marcação SPF configurada corretamente.

O e-mail ainda não chega. Novamente a ligação do Bugo para seu gerente de TI e o gerente de TI que controla. E o que ele encontra?

Falta a marcação DKIM Appero! E o que é isso? O que é essa diabrura?

DomainKeys Identified Mail (DKIM): permite que os gerentes de domínio adicionem uma assinatura digital via chave privada às mensagens de e-mail. O DKIM, portanto, adiciona mais uma ferramenta para verificar a correspondência entre o remetente e seu domínio pertencente.

Novamente, para simplificar, com o e-mail, cosi@vattelapesca.it ele também envia uma chave privada aleatória vinculada a uma chave pública que reside na zona DNS do domínio vattelapesca.it e o servidor de email do destinatário verifica se as chaves estão vinculadas. Se não forem, o e-mail acaba em spam.

O controle perfeito é apenas Reverse+SPF+DKIM. Se um e-mail não passar nessa verificação, o e-mail será queimado.

Muitas vezes, alguns clientes me pedem para colocar na lista de permissões, por exemplo, o domínio vattelapesca.it mas se fazendo o inverso o IP ainda não estiver correto, a Whitelist não serve para nada. Além disso, é um pedido incorreto por um motivo simples: não é possível saber se o remetente em questão está “de boa fé” porque, às vezes, nem o próprio remetente sabe que o está. É como se você tivesse um amigo que mora perto de um acampamento nômade e lhe pedisse para manter a porta da frente aberta, “de boa fé”.

Mas vamos prosseguir.

Na verificação, vamos fingir que a criptografia DKIM também está correta. Ou talvez nem seja necessário. Mas o e-mail não chega.

Mais uma vez, a ligação de Bugo para seu gerente de TI já esgotado. O pedido é definitivo: coloque cosi@vattelapesca.it lista de permissões.

Mas você não pode. Você viola os protocolos de segurança colocando toda a empresa em sério perigo. O gerente de TI verifica e…

O domínio vattelapesca está em vários RBLs/DNSBLs. Ah! Alcaparras! Mas o que são eles?

Uma Lista de Blackhole baseada em DNS (também DNSBL, Real-time Blackhole List ou RBL) é um meio pelo qual é possível publicar uma lista de endereços IP, em um formato especial que pode ser facilmente "consultado" pela Internet. Como o nome sugere, o mecanismo de trabalho é baseado no DNS (Domain Name System). DNSBLs são usados ​​principalmente para publicar endereços IP relacionados a spammers de alguma forma. A maioria dos servidores de correio pode ser configurada para rejeitar ou sinalizar mensagens enviadas de hosts em uma ou mais listas.

Mas nesse ponto o Gerente de TI do Bugo responde ao seu empregador e diz: “Pessoal, se eles estão cadastrados em uma RBL, não somos nós que temos que entender o porquê e resolver o problema, o Gerente de TI do remetente tem que pensar nisso”.

E o e-mail acaba no lixo.

Haveria muito mais a acrescentar, mas quero parar por aqui. Porém, digamos que tudo isso é o mínimo indispensável, que não basta bloquear os bandidos, que se acrescentem outros controles e também problemas inerentes aos protocolos DKIM que são protocolos abertos e interpretáveis ​​e portanto não há uniformidade, então tanto que muitas vezes há problemas para enviar/receber de/para caixas de correio no Libero, Virgilio, Gmail etc…. e são problemas muito difíceis de resolver. Somam-se a isso problemas relativos ao comportamento de indivíduos muitas vezes contrários à netiqueta, como o uso incorreto de cabeçalhos de e-mail, o envio simultâneo a vários usuários diferentes sem criptografia e assim por diante.

Abre-se um mundo onde técnicos, informáticos, engenheiros, matemáticos, físicos se confrontam sem no entanto terem conseguido por princípio encontrar uma solução (e na minha opinião nunca a vão encontrar).

O que posso dizer é que a escolha de um bom serviço de hosting deve passar por vários fatores que nunca são o preço e acima de tudo deve responder a necessidades de segurança que deve ser o ABC de toda empresa que hoje se expõe na internet nos diversos formas e de várias maneiras.

treinamento