Suponhamos que alguém (Mario) queira enviar um e-mail para outra pessoa (vamos chamá-lo de Nicolas). A caixa de correio de Nicolas é preenchida por um servidor exclusivo, digamos smtp.gouv.fr (esse é um exemplo fictício). Portanto, faça o que fizer o Mario, o email terá que passar por aquele servidor, transmitido com o protocolo SMTP (aquele com o comando 'RCPT'). Mario gostaria que a linha From fosse: From: angela@bundestag.de . Observe que, na verdade, existem dois endereços "de": aquele no cabeçalho De: (que o destinatário vê com seu aplicativo de leitura de e-mail normal) e aquele que é fornecido por meio do comando MAIL FROM SMTP (o último aparecerá no cabeçalho Return-Path: ).

Agora, embora o e-mail tenha que passar pelo servidor SMTP de Nicolas, ele pode fazer alguns saltos. A situação normal de envio de email é que o remetente usa o servidor SMTP de seu ISP e esse servidor se comunicará com o servidor SMTP de destino. O servidor ISP de Mario é smtp.governo.it . Mario pode decidir fazer seu telnet (ou equivalente, mas sempre SMTP no final) para smtp.governo.it , smtp.gouv.fr ou algum outro servidor, por exemplo smtp.bundestag.de (o servidor SMTP do ISP de Angela) ou algum outro servidor ( smtp.buckingham.uk ).

Existem vários coisas que podem impedir Mario de fazer isso:

• O ISP de Mario pode impedir qualquer conexão de saída de sua máquina para qualquer servidor SMTP (ou seja, qualquer conexão TCP que almeja porta 25) exceto se a máquina de destino for smtp.governo.it . Muitos ISP fazem isso, principalmente para evitar que a máquina zumbi faça spam amplamente sem qualquer controle.

• smtp.governo.it pode rejeitar a tentativa porque o endereço "de" anunciado não é um endereço que termina com " @ governo.it ". O servidor pode aplicar tal filtro no cabeçalho " From: " ou no comando MAIL FROM , ou em ambos. Alguns (não todos) ISP aplicam essas regras.

• Se Mario contatar smtp.buckingham.uk , esse servidor pode rejeitar a tentativa porque o e-mail é nem destinado a um endereço em buckingham.uk , nem enviado com um endereço "de" em " @ buckingham.uk ". Servidores que encaminham e-mails arbitrários de e para fora são chamados de "retransmissões abertas" e geralmente são malvistos, principalmente porque os spammers simplesmente os adoram.

• Se Mario contatar smtp .bundestag.de , esse servidor também pode rejeitar a tentativa, embora o e-mail seja de fato anunciado como sendo enviado por Angela, porque smtp.bundestag.de sabe que Angela usaria uma conexão vinda de um dos endereços IP que realmente fazem parte da rede gerenciada por bundestag.de . Se smtp.bundestag.de não estivesse fazendo isso, também seria considerado uma "retransmissão aberta" (embora menos aberta do que a instância anterior, mas parcialmente aberta).

• Se Mario encontrar um servidor SMTP ( não smtp.bundestag.de ) que aceite encaminhar o e-mail ou se Mario se conectar diretamente a smtp.gouv.fr , então a tentativa ainda pode ser rejeitada se o domínio bundestag.de usar SPF. O SPF é uma forma de um domínio anunciar, por meio do DNS, algumas políticas de envio de email. Aqui, bundestag.de publicaria com SPF a informação de que emails normais enviados de pessoas @ bundestag.de deveriam se originar de smtp. bundestag.de e em nenhum outro lugar. smtp.gouv.fr , ao ver a conexão de Mario (ou a conexão do servidor SMTP ingênuo que Mario encontrou), pode então procurar nos registros SPF bundestag.de , e detectar a anomalia. Obviamente, o SPF não é usado em todos os lugares e, como é baseado em DNS, é vulnerável a ataques de DNS coordenados ("envenenamento de DNS" e coisas assim).

• Algumas mensagens grandes provedores impõem limitações obscuras arbitrárias, que podem ter o mesmo efeito que o SPF, mas de uma forma não documentada e às vezes oficialmente negada.

Portanto, a melhor aposta para Mario seria: conecte-se com telnet a smtp.gouv.fr (assumindo que seu ISP permite que ele faça isso, e que bundestag.de não usa SPF, ou que smtp. gouv.fr ignora as informações SPF); ou ele poderia tentar encontrar alguma máquina hackável ou complacente em algum lugar do bundestag.de e usá-la como uma retransmissão aberta para enviar o e-mail através de smtp.bundestag.de (o que teria a vantagem adicional de tornar todos os cabeçalhos "realistas", como se Angela tivesse feito isso sozinha).

Em alguns servidores de e-mail é possível, já que geralmente eles só validam seu login e domínio, mas não o endereço de e-mail.

Portanto, se você quiser falsificar um @ mailserver, poderá para fazer o login como b @ mailserver e enviar um e-mail de um @ mailserver. O servidor valida o login e se o remetente é de seu domínio e envia um e-mail, que é indistinguível.

Muitos provedores fazem coisas para evitar isso. Alguns adicionam o login como um cabeçalho de e-mail ou pelo menos algum ID exclusivo (por exemplo, gmail) para o usuário. Outros apenas filtram o endereço completo do remetente se ele tiver permissão para usá-lo. Muitos outros estão apenas abertos a este tipo de ataque.

Isso, é claro, só funciona se você conseguir uma conta própria no servidor correspondente.