Controle de conteúdo em SMTP

José de Paula Eufrásio, Júnior

Atribuição-Uso Não-Comercial-Compatilhamento pela mesma licença 2.0 Brasil

Você pode:

  • copiar, distribuir, exibir e executar a obra

  • criar obras derivadas

Sob as seguintes Condições:

  • Você deve dar crédito ao autor original

  • Você não pode utilizar esta obra com finalidades comerciais.

  • Se você alterar, transformar, ou criar outra obra com base nesta, você somente poderá distribuir a obra resultante sob uma licença idêntica a esta.

  • Para cada novo uso ou distribuição, você deve deixar claro para outros os termos da licença desta obra.

  • Qualquer uma destas condições podem ser renunciadas, desde que Você obtenha permissão do autor.

Qualquer direito de uso legítimo (ou "fair use") concedido por lei, ou qualquer outro direito protegido pela legislação local, não são em hipótese alguma afetados pelo disposto acima.

Este é um sumário para leigos da Licença Jurídica disponível em http://creativecommons.org/licenses/by-nc-sa/2.0/br/legalcode .

Histórico de Revisões
Revisão 1.007/03/2005jpej
Rascunho para Comentários
Revisão 1.112/03/2005jpej
Inclusão de Teergrubing (Tarpit/Poço de Piche)
Revisão 1.231/03/2005jpej
Clarificação do Copyright e Nota Legal
Revisão 1.324/05/2005jpej
Adoção da Creative Commons 2.0. Revisões no texto.
Revisão 1.408/06/2005jpej
Atualização na informação sobre DKIM e DomainKeys.

Resumo

Este documento tem como intenção descrever o problema com E-Mails Comerciais Não Solicitados (ECNS) ou SPAM, fraudes e programas mal-intecionados (vírus, worms, etc..), todos relacionados ao protocolo SMTP. Além disso existe uma explicação e discussão sobre os métodos atuais de controle e combate a estas pragas virtuais e sobre os prós e contras de cada uma.

As opiniões são pessoais ao autor, e abertas a discussões e alterações devido a mudança de tecnologias ou resultados no uso prático. A versão mais recente deste documento pode ser encontrada em http://coredump.osimortais.com.br


Índice

1. Introdução
2. Vírus, Trojans e Worms
2.1. Definições
2.2. Modus Operandi
2.3. Antivírus e servidores de email
3. SPAM ou Emails Comerciais Não Solicitados
3.1. Problemas Atuais
3.2. Métodos de Prevenção
3.2.1. Verificações de Servidores
3.2.2. Verificação de Remetentes
3.2.3. Filtros "inteligentes"
3.2.4. Criptografia
3.2.5. Outros Métodos
4. Conclusão
Bibliografia

1. Introdução

O Email é, sem dúvida alguma, o segundo uso mais popular da Internet,atrás apenas dos sítios e homepages. O Eletronic Mail, ou Correio Eletrônico, foi um dos primeiros usos da rede e, atualmente, é uma forma crucial em várias organizações como forma de comunicação e negociação.

Emails utilizam o protocolo SMTP para serem transferidos em sua maioria, SMTP é a sigla para Simple Mail Transport Protocol, ou seja, Protocolo Simples para Transporte de Correio. Este protocolo foi inicialmente descrito na RFC 821, de 1982, mas já estava presente desde os primórdios da Internet como forma de troca de mensagens

Depois disso, o uso da internet começou a se popularizar, e o tráfego de mensagens começou a aumentar consideravelmente. O protocolo sofreu algumas poucas modificações relacionadas a segurança e privacidade como autenticação e uma versão encriptada do protocolo.

Em algum ponto da história, alguém teve a infeliz idéia de enviar uma mensagem para várias pessoas informando de algum serviço ou produto. Historicamente, em 1978, um funcionário da DEC enviou o que se considera o primeiro SPAM. Depois disso, os Emails Comerciais Não Solicitados, SPAM, começaram a se tornar uma praga comum da Internet.

Seguindo a onda de SPAMs, que começaram a ficar cada vez mais elaborados, apareceram as fraudes via email. Desde filhos de presidentes depostos pedindo ajuda em repatriar quantias de dinheiro até crianças em algum país africano pedindo ajuda, tudo foi usado para tentar conseguir dados sigilosos e pessoais de vítimas desavisadas. Numa nova evolução, vírus e worms começaram a ser programados e utilizados usando o SMTP, mensagens e falhas em clientes de Email para se propagar pelas redes.

Atualmente, uma das lutas diárias de vários administradores de rede é identificar e bloquear o SPAM que chega, e desenvolver formas de automatizar o processo. Existem atualmente várias técnicas e programas disponíveis, mas num ambiente relativo como o das mensagens de email o número de falsos positivos e falsos negativos são as vezes desastrosos. Mesmo assim, com o conjunto correto de ferramentas e técnicas é possível reduzir o número de SPAM e a ameaça de problemas que podem chegar, via email, aos usuários.

2. Vírus, Trojans e Worms

2.1. Definições

A definição para vírus, trojans e worms é um pouco confusa. Inicialmente, todos eram colocados mais ou menos na mesma categoria. Atualmente, a área de Segurança da Informação classifica os mesmos de acordo com sua forma de funcionamento e reprodução.

Vírus

Programas auto-reprodutor que utilizam os recursos da máquina hospedeira para se replicarem e se espalharem, sem ação específica do operador.

Trojans

Nome derivado de Trojan Horse (Cavalo de Tróia). Programa que simula possuir, ou é descrito como possuir um conjunto de funções mas que em adição, ou ao contrário de, possui uma carga danosa. Normalmente utilizado para explorar as autorizações legítimas e colocando em risco a integridade e disponibilidade das informações.

Worms

Programa auto-reprodutor que se distingue do vírus por se copiar sem ser ligado a um arquivo executável, ou que se propaga por redes, particularmente via email.

Malware

Termo coletivo para descrever programas com intenções maliciosas. Incluem vírus, worms, trojans, zumbis para DDOS, bombas lógicas etc...

Phishing

Phishing é um ataque onde um indivíduo criminoso envia uma mensagem clamando ser de algum site importante como vendas online ou bancos. Fazendo uma manipulação sutil do formato e conteúdo do email ele consegue que o usuário, desavisado, forneça dados pessoais e sensíveis pra o criminoso, que usa estes dados depois em fraudes e roubos de identidade.

2.2. Modus Operandi

Os malwares que se propagam pela rede e emails são de maior interesse para este artigo. Normalmente, estes programas vão se aproveitar de elos fracos da corrente de funcionamento do Email, principalmente da ingenuidade e desinformação de usuários e de problemas (bugs) e falhas em programas ou dispositivos de rede.

As maiores infecções por malwares na Internet aconteceram por exploração de erros em software de leitura de Emails e por se aproveitar da curiosidade e desconhecimento dos usuários. Assim, worms se replicaram e começaram a se propagar pela rede enviando a membros do catálogo de endereço do computador infectado cópias de si mesmo, com assuntos genéricos e normalmente anexos com nomes "interessantes". Assim, a curiosidade dos próprios usuários os faziam abrir o arquivo, sem imaginar que ele era, na verdade, um programa mal intencionado.

Uma nova geração de malwares começaram então a se propagar usando arquivos compactados e encriptados com senha. Isso funcionava como uma prevenção a qualquer tipo de antivírus automático colocado em servidores. Com o arquivo encriptado o antivírus não consegue acessar seu conteúdo para procurar por vírus. Na mensagem enviada para a vítima, era incluída a senha para se abrir o arquivo, exigindo um nível a mais de ingenuidade da parte do usuário.

Malwares que utilizam o email como forma de contaminação utilizam normalmente o catálogo local de endereços para enviar as cópias, normalmente usando estes mesmos endereços para designar o remetente da mensagem. Este é um comportamento importante a se notar nos malwares atuais.

2.3. Antivírus e servidores de email

A solução mais utilizada em servidores de Email é a instação de filtragem de conteúdo de arquivos anexos antes da mensagem chegar ao usuário. Esta filtragem pode ser feita antes ou depois da recepção do email pelo servidor. As soluções daí partem para várias formas de resposta: invariavelmente o email vai ser descartado e não vai ser entregue ao usuário, alguns servidores gostam também de enviar uma mensagem de notificação para o remetente avisando da infecção.

A checagem de anexos após o recebimento é feita em sua maioria após o email ter sido aceito pelo servidor. Para o servidor que enviou a mensagem, ela foi entregue corretamente. Depois disso, uma configuração interna no servidor vai verificar a mensagem utilizando um ou mais antivírus, e caso algum acuse contaminação esta mensagem vai ser tratada de acordo com a configuração feita pelo administrador. Isso inclui tentativas de descontaminação ou quarentena da mensagem, muito raro nos dias de hoje, ou descarte da mensagem. Adicionalmente, o servidor pode enviar mensagens para o remetente e para o destinatário com relatórios ou avisos sobre a contaminação.

A checagem antes do recebimento do email consiste em negar a mensagem com um erro no SMTP logo após a conclusão do comando DATA durante a sequência de envio da mensagem. Esta checagem impossibilita envio de mensagens de notificação, mas o servidor remetente receberá um erro que, se configurado apropriadamente, vai devolver o aviso ao remetente da mensagem. Nesta forma de verificação, o servidor remetente vai saber que a mensagem não foi entregue corretamente e vai reagir como configurado ao erro.

Ambas as formas de checagem tem suas vantagens e desvantagens. Algumas considerações:

  • Atualmente, manter a mensagem em quarentena ou tentar descontaminá-la caiu em desuso, visto que praticamente 100% dos emails que acusam contaminação consistem exclusivamente de vírus, sem outro conteúdo que possa ser aproveitado;

  • Como destacado na seção anterior, malwares utilizam emails do catálogo de endereços tanto para definir o destinatário como o remetente. Assim, uma pessoa pode receber as mesmas cópias dos emails como se viessem de várias pessoas diferentes. Isso faz com que os emails de notificação se tornem desnecessários e até ofensivos. Uma máquina infectada pode enviar centenas ou milhares de emails, e nenhum chegar aos remetentes como sendo enviados pela pessoa realmente infectada. Isso gera um tráfego desnecessário e várias pessoas recebendo mensagens informando uma infecção que não existe;

  • Quanto mais rápido um servidor se livrar da carga de uma mensagem a ser verificada, melhor. Barrar a mensagem assim que ela acaba de ser transferida, antes de qualquer outra operação, diminui o tempo e o gasto de recursos para cada mensagem;

  • Limites de mensagem devem ser configurados nos servidores. No caso da checagem enquanto a mensagem está sendo enviada uma mensagem grande demais pode fazer o servidor gastar tempo demais e gerar, dependendo do número de mensagens, uma espécie de ataque de Denial of Service - Negação de Serviço.

Dica

Com os novos vírus usando arquivos encriptados para se retransmitir, bloquear este tipo de anexo se torna uma best practice, visto que existe métodos menos inseguros de se enviar uma mensagem e arquivos confidenciais.

A velocidade com que os vírus de email se propagam é muito alta, e é necessário munir o servidor de um antivírus com uma boa velocidade de resposta e com atualizações frequentes e rápidas. Além disso, deve existir um programa de conscientização de usuários, como sites locais e um bom suporte técnico capaz de prover informações sobre vírus, formas de infecção e notícias descrevendo as novas pragas. Se os usuários entenderem que não devem abrir arquivos desconhecidos antes de conferir o mesmo, o risco de um ataque destes diminui bastante.

É aconselhável também que as máquinas do ambiente possuam antivírus locais preparados para lidar com vírus que por algum motivo não tenham sido identificados pelo servidor, ou ainda mensagens que tenham sido recolhidas de forma externa da organização, via protocolos como POP3, IMAP ou sistemas de Correio gratuitos com baixa segurança.

3. SPAM ou Emails Comerciais Não Solicitados

3.1. Problemas Atuais

Os SPAM são mensagens válidas. Na maioria das vezes, elas vão se parecer com um email qualquer, fazendo uma propaganda. O problema do SPAM, na verdade, é o fato de ele ser enviado em massa, para pessoas que não pediram para receber e quase sempre sem uma forma de requerer a exclusão destas listas. As formas de obtenção de emails para estas listas incluem roubo de dados de máquinas, worms e programas que baixam sites e páginas a procura de emails. O "mercado negro" do SPAM inclui venda de listas de endereços e programas especializados em enviar mensagens em massa e tentativas de anonimizar as mesmas e dificultar o rastreamento.

SPAM é uma invasão de privacidade, além uma terrível falta de atenção, que fomenta problemas de segurança e servem como pano de fundo para fraudes e delitos dos mais leves até grandes golpes bancários. Quase sempre, as vítimas são pessoas que pensam ingenuamente que estão fazendo um grande negócio ou uma grande boa ação.

Além disso, o Brasil tem milhares de servidores mal configurados, administradores irresponsáveis e provedores de conexão banda-larga sem controle de seus clientes. Desobediência a RFCs e servidores abertos - open relay - fazem com que o Brasil seja considerado, junto com a Ásia, um ninho de SPAM, diminuindo a credibilidade e bloqueando emails legítimos. Nas últimas pesquisas, o Brasil aparece entre as dez maiores fontes de SPAM mundial, e um dos provedores mais famosos de conexão banda-larga do Brasil aparece numa inglória quarta posição como fonte individual de envio de SPAM.

3.2. Métodos de Prevenção

Os métodos para se evitar são diversos, e em várias partes do tratamento da mensagem. O bloqueio da mensagem pode ser feito desde o momento do recebimento no servidor até na máquina do cliente. A curva de risco aumenta exponencialmente de acordo com a proximidade com o cliente, o que torna imperativo a identificação o quanto mais rápida.

3.2.1. Verificações de Servidores

Uma das primeiras barreiras contra o SPAM é negar mensagens e conexões de servidores que reconhecidamente enviem SPAMs. Nesta categoria de testes temos as RBL (Realtime Blackhole Lists), SPF (Sender Policy Framework) e testes de IP Reverso

A checagem de IP Reverso é um teste simples conferindo se o host enviado pelo comando HELO no SMTP é consistente com o endereço IP do servidor. É um teste que se aproveita de uma falha de programas que enviam SPAM: estes programas geralmente utilizam muitos endereços e conexões para enviar suas mensagens, mas utilizam um HELO padrão que não tem consistência com o endereço IP da conexão.

As RBL são listas que mantém um banco de dados de servidores que já enviaram SPAM alguma vez. Existe uma infinidade destas listas, cada uma utilizando um método diferente para classificar e categorizar os servidores. Essas listas disponibilizam uma checagem usando testes simples de DNS, sendo checadas usando o endereço IP do servidor remetente na consulta. Existem também destas listas especializadas em servidores que não seguem as normas das RFCs e serviços de banda-larga ou conexão discada reconhecidos como problemáticos.

Ambos os testes utilizam checagens derivadas do endereço IP de onde vem a conexão que envia a mensagem. Este tipo de teste é normalmente bem sucedido, mas atualmente vários problemas têm surgido:

  • Os programas de envio de SPAM são atualizados constantemente para driblar os testes de IP Reverso;

  • Vários servidores "sérios" são mal configurados e enviam um HELO inválido ou não têm configuração de IP Reverso.

As RBL atualmente sofrem sérias críticas com relação ao funcionamento e administração das mesmas. Os maiores problemas apontados são o Dano Colateral, Geopolitica, Autoridade Invisível e Dificuldade de Apelação.

Dano Colateral

Imagine um provedor de tamanho nacional com milhares de assinantes. Imagine que por algum motivo um email deste provedor é considerado SPAM, ou mesmo alguém envia centenas de mensagens de SPAM usando um endereço deste provedor. Este provedor pode acabar sendo bloqueado em alguma RBL e, junto com o autor do SPAM, todos os outros assinantes tem seus emails bloqueados por servidores usando aquela RBL. Este Dano Colateral é comum no Brasil e gera problemas até mesmo com orgãos do governo e grandes provedores.

Geopolítica

Várias listas, principalmente internacionais, utilizam técnicas que podem considerar países inteiros como inválidos. Isto porque grande parte do SPAM está sendo enviado da Ásia e da América do Sul, o que faz servidores legítimos de países destas regiões serem banidos.

Autoridade Invisível

Uma das maiores preocupações, o fato de que existe um controle de mensagens sendo aplicado por um agente externo. Já existiram casos de cadastros em RBLs para censurar ou cercear a informação de empresas cadastrando-as erroneamente ou por má fé.

Dificuldade de Apelação

O contato com as RBL pode ser complicado. É extremamente fácil de entrar para uma das listas, mas em algumas é virtualmente impossível ser removido. Além disso, existem listas que bloqueiam blocos inteiros de IPs, algumas vezes bloqueando servidores que são de alguma outra empresa, mas tem a infelicidade de estarem logicamente próximos aos verdadeiros culpados.

SPF e SRS são tecnologias complementares de verificação de envio de mensagens. A tecnologia do SPF faz um teste utilizando uma busca DNS para conferir se o endereço IP do servidor que está enviando a mensagem é autorizado a enviar mensagens daquele determinado domínio. Este teste funciona da seguinte forma:

  1. A organização que está implementando o SPF adiciona ao seu DNS um registro do tipo TXT, que lista os endereços IP que podem enviar mensagens daquele domínio assim como a versão do SPF e o tratamento local. Depois da configuração, obtem-se um resultado similar a este:

    servidor:~# host -t TXT dominio.com.br
    dominio.com.br text "v=spf1 ip4:200.1.1.1/24 \
    ip4:200.2.1.1/24 ip4:200.3.1.1/24 -all"

    Onde servidores nas redes 200.1.1.1/24, 200.2.1.1/24 e 200.3.1.1/24 estão habilitados a enviar mensagens para o domínio dominio.com.br. A opção -all no final da linha significa que servidores fora destas faixas devem ser rejeitados. A resposta está em duas linhas por questões de espaço.

  2. O servidor destinatário faz uma busca no DNS do domínio da mensagem que está sendo recebida e confere se o endereço do servidor que está enviando a mensagem faz parte da lista recuperada do domínio.

  3. Caso o servidor não esteja listado, o administrador pode escolher as ações a serem executadas, levando em conta a configuração do domínio.

O SPF é uma forma válida de combater fraudes de emails e a proliferação de malware. Num ambiente bem configurado, bancos e orgãos do governo podem publicar seus registros SPF. Com servidores configurados para negar violações, a chance de um email personificar outro servidor ou serviços originais são praticamente nulas. O SRS - Sender Rewrite Framework - é uma tecnologia complementar ao SPF, que define padrões para reescrever os endereços no caso de servidores SPF, que fazem repasse de mensagens (forward.

O SPF tem seus prós e contras, e não tem como objetivo principal parar o SPAM e sim as fraudes e personificações, assim como máquinas infectadas com vírus. Um problema que se observa no SPF é exatamente os servidores que repassam legitimamente as mensagens. Como essas mensagens a serem reenviadas podem ter um domínio diferente do qual está relacionado no IP do servidor que reenvia a mensagem. Por isso foi criado o SRS, para que servidores com SPF possam repassar legitimamente mensagens sem ter problemas com domínios não liberados. Outras críticas ao SPF incluem falta de universalidade, variação nas implementações e grandes servidores de email com implentações inúteis (como por exemplo permitir as redes inteiras a enviar email).

No Brasil, a aceitação e implantação do SPF tem aumentado nos últimos tempos, com a adoção em grandes provedores e servidores de hospedagem.

3.2.2. Verificação de Remetentes

Testar os remetentes da mensagem permite um controle mais fino no combate a SPAM do que servidores inteiros. Em contrapartida pode ser um pouco mais problemático de se implementar. Nesta categoria, temos Listas Internas de usuários, domínios, Listas Compartilhadas e Verificação de Remetentes. O SPF foi explicado no tópico anterior, e pode ser considerado um misto entre checagem de Remetente e de Servidores.

As Listas Internas podem ser implementadas de várias formas, desde utilização de bancos de dados até simples arquivos de texto, sempre com o mesmo objetivo: listar domínios ou endereços de email dos quais não devem ser aceitas mensagens. O cadastro nestas listas podem ser feitos pelos próprios usuários, relativos aos seus próprios emails, onde eles listarão os endereços de onde chegam as mensagens indesejadas ou um sistema automatizado de resposta a Abusos (instituições que possuem serviço de correio eletrônico devem responder ao endereço padrão para cuidar de problemas com abuso do serviço). O Administrador pode filtrar os dados destas listas pessoais e gerar uma lista única para o servidor como um todo.

Listas Compartilhadas funcionam como as listas internas, mas são listas feitas por vários administradores em conjunto, tentando cadastrar o máximo de emails que enviam SPAM em algum lugar, onde outros servidores possam checar ou atualizar suas listas locais. O funcionamento é similar ao das listas internas em conjunto com uma RBL.

Ambas as listas funcionam bem porque os próprios usuários podem fazer bloqueios de SPAMs que chegam somente para ele. Um problema deste sistema é que o SPAM tem de chegar antes de ser bloqueado e no intervalo entre a chegada e o cadastro na Lista muitas outras mensagens podem ter parado. Mesmo assim, é sempre interessante manter uma lista destas no servidor.

A Verificação de Remetentes é uma função disponível na maioria dos MTA atualmente. Consiste de um teste para verificar a existência do remetente de uma mensagem, usando uma sessão nula de email. Em um teste desta natureza o servidor destinatário irá durante a recepção da mensagem, se conectar ao servidor de email primário do domínio remetente e tentar enviar uma mensagem para o remetente usando um endereço nulo <>. Com este teste o servidor destinatário da mensagem poderá negar ou aceitar a mensagem dependendo da existência ou não da conta de envio. Esta é uma boa prática, pois muitos SPAMs são enviados com emails inválidos que falharão neste teste.

O teste para Verificação de Remetente, infelizmente, depende da boa configuração dos servidores envolvidos no teste. No Brasil, criou-se uma política de bloquear emails destinados ao endereço nulo <>, que causa transtornos não só nesta verificação como em mensagens de erro que dependem deste endereço para enviar mensagens. Este endereço é previsto como necessário em todas RFCs que definem o protocolo SMTP.

3.2.3. Filtros "inteligentes"

Os testes mais elaborados são, enfim, os que classificam as mensagens com base no conteúdo da mesma. Nesta categoria temos vários programas que fazem uma variedade de testes desta natureza, usando estatística bayesiana e classificação de conteúdos comuns em mensagens consideradas SPAM. Desta forma, também funcionam os filtros locais que estão em praticamente todos os bons programas de leitura de correio atualmente.

Estes filtros são úteis na medida que o usuário sempre mantenha uma vigilância e um controle de sua "sensibilidade", visto que por serem programas de computador podem classificar emails legítimos como SPAM. No caso de servidores, é sempre interessante manter dois níveis de proteção com relação aos resultados desta filtragem como, por exemplo, barrar mensagens com um número muito elevado de chance de ser SPAM e apenas adicionar um cabeçalho ou alterar o Assunto da mensagem caso a chance seja pouco maior que o padrão do sistema. Assim o usuário pode conferir se aquela mensagem é um SPAM ou apenas uma mensagem legítima mal escrita.

3.2.4. Criptografia

A criptografia é um método atualmente considerado para garantir a identidade de remetentes e servidores, evitando assim casos de phishing e algumas fraudes e vírus.

Este método consiste em assinar digitalmente alguns cabeçalhos e mesmo o corpo da mensagem usando criptografia, para que os servidores que recebem a mensagem possam confirmar a autenticidade da mesma quando receberem.

A pouco foi anunciado pela Cisco e pela Yahoo! que os padrões desenvolvidos para criptografia de mensagens pelas duas gigantes serão combinados em apenas um padrão aberto e livre de patentes, chamado DKIM (DomainKeys ou DK, da Yahoo!, e Identified Internet Mail ou IM da Cisco). Este padrão conta também com o apoio da comunidade e de visionários como Eric Allman do sendmail. Ele foi submetido a IETF no início de junho de 2005 e deve ser analisado e liberado como padrão dentro de alguns dias. A intenção é que até o meio de 2006 o DKIM seja o padrão mais utilizado de criptografia para verificação de mensagens de correio eletrônico.

O DKIM herda as melhores características de seus dois originadores, como a praticidade ao organizar os cabeçalhos do IIM da Cisco com a técnica de publicação de chaves públicas do DomainKeys, da Yahoo!, usando DNS.

3.2.5. Outros Métodos

Existem atualmente vários outros métodos de bloqueio e identificação de SPAM, verificação de remetentes e procedência de uma mensagem. Vários destes estão em fase de teste ou pesquisa, mesmo assim são bastante poderosos para os problemas atuais.

Domain Keys

Tecnologia desenvolvida pela Yahoo! e liberada como tecnologia livre. É um sistema parecido com o SPF em sua estrutura, mas com uma proposta diferente. Pelo sistema Domain Keys cada servidor irá gerar um par de chaves, uma privada e uma pública usando o algoritmo RSA, e usará a chave privada para assinar cada mensagem que enviar colocando a assinatura em um cabeçalho e a chave pública será disponibilizada em um registro DNS disponível publicamente. O servidor destinatário ao receber a mensagem então usará esta chave pública para conferir a assinatura da mensagem, estabelecendo assim a autenticidade da mensagem. Este método ajudaria a diminuir tanto SPAM quanto personificações de endereços e domínios.

Atualmente a maior resistência a este método é o grande dispêndio de poder computacional necessario para assinar as mensagens de saída em organizações que podem ter um número muito alto de emails sendo enviados diariamente. Além disso, o supracitado DKIM parece ser a implementação de fato para criptografia de emails.

Greylisting

É uma tecnologia relativamente nova. O conceito atrás dela é de que programas e servidores que enviam SPAM raramente tentam reenviar uma mensagem após uma tentativa com erro, mesmo um erro não fatal. Assim, Greylisting consiste em gerar um erro temporário para todo email que chegar, desde que seja a primeira vez que aquele email tenta ser entregue. Assim, se o endereço A nunca enviou email para o servidor B o servidor B vai responder a tentativa do endereço A com um erro não fatal. Se o endereço A for um servidor bem configurado e o email for válido a especificação é que a mensagem tente um novo envio algum tempo depois. Existem várias formas de implementar esta solução, entre elas o uso de MySQL ou configurar o MX mais alto do domínio para um IP que não exista.

Problemas apontados nas implementações de Greylisting envolvem demora para a recepção dos primeiros emails e, como sempre, servidores mal configurados que podem desistir de enviar uma mensagem após a primeira tentativa.

CSV - Certified Server Verification

O CSV - Verificação de Servidores Certificados - é uma tecnologia que inclui três testes para verificar a autenticidade do servidor e a permissão para se receber os emails. A verificação inicial seria um teste de Endereço Reverso como o descrito anteriormente. A parte indicada após o comando HELO ou EHLO seria testada por conformidade com o endereço IP que é associado ao mesmo e o que está sendo usado para a conexão. A segunda verificação seria um teste similar ao do SPF, usando uma busca, DNS mas por outro registro que não o TXT, para checar se o servidor enviando a mensagem tem permissão para enviar emails por aquele domínio. O último teste no CSV seria o de reputação, onde o servidor acessaria um banco de dados descrevendo quanto SPAM o domínio teria enviado e com base nesta "reputação" tratar a mensagem individualmente. Estes bancos de dados de reputação poderiam ser internos ou fornecidos por terceiros.

Atualmente o CSV ainda está se definindo. O formato das consultas e respostas DNS ainda não foi definitivamente resolvido e preocupações com ataques a serviços de reputação são constantes.

Teergrubing (ou Tarpiting)

A técnica tem vários nomes: Teergrub ou Tarpit, todos querendo dizer a mesma coisa: Poço de Piche (ou Pega-Moscas). Normalmente os servidores/programas que enviam SPAMs, enviam centenas de mensagens em um curto espaço de tempo. A abordagem do Poço de Piche consiste em fazer este processo dispendioso de tempo para os remetentes, utilizando para isso um atraso entre cada linha de resposta da sessão SMTP. Existem várias formas de se implementar o Poço de Piche, desde aplicando a técnica a servidores reconhecidos como fonte de SPAM até penalidades aplicadas dependendo da conformidade do servidor com as regras, ou seja, quanto mais ilegal o servidor remetente parece, maior a penalidade.

Poço de Piche tem como ponto positivo não parar o envio de mensagens legítimas (os emails continuam passando, só os SPAMs não são enviados com tanta velocidade). Por outro lado, a implementação errônea do Poço de Piche pode causar um ataque de Negação de Serviço (DOS) paralisando todo o serviço de email.

4. Conclusão

As tecnologias e técnicas descritas aqui neste artigo estão longe de serem perfeitas ou infalíveis. Existem também várias outras técnicas e formas que devem ser consideradas mas são pouco conhecidas ou limitadas.

Afinal o grande problema do SPAM, principalmente o SPAM brasileiro, é a quantidade de servidores que não respeitam as RFCs e tem configurações toscamente arrumadas que acabam fazendo mais mal do que bem, além de serviços de email que não possuem qualquer controle sobre o que sai de seus servidores, sem mesmo responder a problemas denunciados no sistema de ABUSE.

Bibliografia

Eric Allman - Fried Phish and SPAM (Palestra durante o FISL 6.0 em Porto Alegre, Junho de 2005)

Vários Autores - RFCs 821, 2821: SMTP - Simple Mail Transfer Protocol

Philip Jacob - The Spam Problem: Moving Beyond RBLs

Brad Templeton - Varios "Spam Essays" da EFF

Robert M. Slade - Glossary of Communications, Computer, Data, and Information Security Terms

Philip Hazel - Exim Specification Document

Wietse Venema - Postfix FAQ