5. As técnicas ANTISPAM

            As chamadas técnicas ANTISPAM surgiram quase ao mesmo tempo que os primeiros problemas relacionados as praticas de SPAM começaram a serem verificados. Tais técnicas não estão relacionadas a nenhuma RFC ou norma oficial, muito embora o desenvolvimento do SPAM tenha impulsionado uma melhoria nas RFC-821 e RFC-822, que se evoluíram para as RFC-2821 e RFC-2822, que introduziram formas de melhorar a identificação nos cabeçalhos das mensagens e de autenticação.

            As técnicas ANTISPAM destinaram-se a preencher as lacunas que a simplificação do protocolo SMTP deixou evidente e que em muito acabaram facilitando o surgimento e o desenvolvimento das técnicas SPAMMERS.

            Apesar de não terem um caráter ou uma norma oficial, as regras ANTISPAM existentes hoje surgiram como uma reação a cada nova modalidade de SPAM que surgia e são aceitas por grande maioria dos administradores e usuários de redes na Internet. Muitas delas podem ser implementadas dentro dos próprios servidores SMTP (MTA), através de bibliotecas em C/C++, ou a partir de plugins externos a eles, desta forma podem apresentar pequenas nuances entre diferentes servidores SMTP e plugins.

            As regras ANTISPAM podem ser comparadas a três linhas de defesa que um SPAM deve tentar passar antes de chegar a um usuário final de uma rede. Podemos enumerar essas 3 linhas de defesa da seguinte forma:

 
Fig.1 - As três linhas de defesa Antispam

1.      Regras, filtros internos ou técnicas ANTISPAM que são implementadas dentro do código-fonte do servidor SMTP, podendo ou não usar bibliotecas externas C/C++, com as implementações de tais técnicas, que são adicionadas ao código binário resultante durante a compilação do código executável.

2.      Uso de plugins (programas externos) que não são compilados dentro do servidor SMTP, mas são aplicativos separados rodando em paralelo e interconectando-se com o mesmo.

3.      Uso de programas ANTISPAM a nível do próprio usuário, que é o destinatário final da mensagem.

As regras ou técnicas da 1ª linha de defesa tem por função tentar resguardar a largura de banda do canal de comunicação externo da rede e os recursos do sistema, alem do usuário final, tentando para isso se antecipar em deduzir se uma mensagem pode ser um SPAM ou não. O uso de programas plugins externos a nível do servidor SMTP, que são a 2ª linha de defesa, destinam-se a resguardar os recursos do sistema (disco, tempo de CPU e/ou custo homem/hora para ler e apagar mensagens de SPAM) e o usuário final. Por fim, os próprios programas ANTISPAM a nível de usuário, a 3ª linha de defesa, procuram resguardar o usuário em si da situação inconveniente causada pelo recebimento de SPAMs.

            Antes de começarmos a discorrer sobre cada modalidade de técnicas ANTISPAM, devemos analisar sucintamente como funcionavam os servidores SMTP antes e depois do fenômeno do SPAM surgir para podermos ter uma boa idéia de como tal fenômeno provocou uma mudança radical de se tratar comunicações SMTP na Internet.

            Após isto, trataremos das técnicas ANTISPAM propriamente ditas, primeiro a nível da administração de redes e depois a nível dos usuários de redes.

5.1. Os servidores SMTP (MTA) antes e depois do SPAM

            Até o início de 1996 já existiam bastantes servidores SMTP funcionando na Internet, a sua imensa maioria rodando Sendmail, existindo outros como o Smail do Linux e o Mercury das Novell Netware (embora esse último recebesse conexões SMTP, ele necessitava do Sendmail ou do Smail de um Unix como host-relay para enviar os E-mails). O Sendmail ainda continua sendo o mais utilizado nos dias de hoje devido a sua grande portabilidade para diversos tipos de sistemas operacionais diferentes, especialmente os chamados “Unix-like” (Linux, FreeBSD, etc). Atualmente se encontra em desenvolvimento a versão alpha do novo Sendmail-X, que inclui conceitos de modularização em suas funcionalidades.

            Tais servidores SMTP funcionavam baseados no protocolo SMTP como descrito na RFC-821datada de 1981 e as características deles eram as seguintes:

·        Funcionavam seguindo o protocolo SMTP da RFC-821, sem restrições;

·        Possuíam relay aberto por default, ou seja, aceitavam receber e fazer relay de E-mails de quaisquer origens para quaisquer destinos;

·        Praticamente não possuíam nenhuma regra de filtragem para conexões SMTP, quando muito limitavam o tamanho total de uma mensagem;

·        Não possuíam possibilidade de funcionamento com plugins de terceiros;

·        Alguns eram Open-Source, como o Sendmail e o Smail, outros como o Mercury eram proprietários;

·        Não possuíam a habilidade de fazer autenticação para permitir relay de mensagens;

·        Apesar de não serem bem projetados, trabalhavam bem porque o trafego de E-mails não era pesado, não exigindo processamento excessivo.

·        Eram mais difíceis de serem configurados, especialmente o Sendmail, o que fatalmente não incentivava os administradores de redes a alterarem as configurações defaults.

Após a primeira metade de 1997, já na da 2ª fase do SPAM, quando as máquinas com relay aberto começaram a serem exploradas para o reenvio das mensagens de SPAM, várias características foram alteradas nos servidores SMTP para cobrirem as “fragilidades” do protocolo SMTP, que foram as seguintes:

·        Passaram a funcionar ainda seguindo o protocolo SMTP da RFC-821 (e posteriormente da RFC-2821), agora fazendo restrições porém respeitando a norma do protocolo SMTP (utilizando os códigos de errors e avisos da mesma);

·        Passaram a trabalhar com relay fechado por default, ou seja, faziam algumas verificações de IP ou domínio da máquina de origem antes de permitir ou não o relay de uma mensagem;

·        Passaram a fazer filtragem das mensagens de diversas formas, de forma a identificar se as mesmas era ou não SPAM de forma razoável;

·        Passaram a permitir o funcionamento com plugins de anti-virús e anti-spam de terceiros;

·        Surgiram novos servidores SMTP Open-Source como o Postfix, o Qmail e o Exim (atualmente a maioria dos servidores SMTP são de código-aberto), e outros proprietários, como o Microsoft Exchange (que até hoje é o mais deficiente, provavelmente por falta de habilidade dos administradores de redes em configurá-lo, para evitar SPAM). As redes Novell Netware sofreram grande recuo no mercado e com isso a utilização do Mercury diminuiu;

·        Passaram a permitir a possibilidade do uso de autenticação para permitir relay de mensagens;

·        Passaram a ser projetados melhor para poderem trabalhar com mais eficiência devido ao SPAM tornar o trafego de E-mails consideravelmente pesado, exigindo um processamento maior.

·        Passaram a serem mais fáceis de serem configurados, com uma melhor documentação das configurações, o que facilitou e incentivou os administradores a fazerem configurações personalizadas para cada realidade de rede diferente.

Como pode ser notado, praticamente houve uma mudança de 180º na mentalidade da construção e da operação dos servidores SMTP. Claro que tal mudança não seria bastante para conter os problemas relacionados com SPAM, desta forma, foram sendo criadas técnicas extras chamadas de técnicas ANTISPAM, que aos poucos passaram a ser aceitas de formas mais ou menos homogêneas.

5.2. Técnicas ANTISPAM em nível de administração de redes

            As primeiras técnicas ANTISPAM surgiram em nível de administração de redes, especialmente porque não existiam softwares ou plugins que permitissem aos usuários terem regras individualizadas para a prevenção de SPAM.

            Como tais regras são globais, ou seja, afetam invariavelmente TODOS os usuários de uma rede, elas devem ser elaboradas e aplicadas com o máximo cuidado possível de forma a bloquear a maior quantidade de SPAM possível e reduzir ao mínimo o risco dos chamados casos de “falso positivo” para SPAM.

            A seguir descreveremos as principais técnicas ANTISPAM em nível de administração de redes, ou seja, configuradas diretamente ou via configuração de plugin, em um servidor SMTP, discorrendo sobre suas vantagens e desvantagens.

            Dos tópicos abaixo discorridos, os que vão de 5.2.1 até 5.2.6 são referentes a chamada 1ª linha de defesa contra SPAM. A analise dos conteúdo de E-mails pelo servidor SMTP usando plugin, em 5.2.7, é referente a chamada 2ª linha de defesa contra SPAM.

5.2.1. Regras de filtragem interna dos servidores SMTP

            As regras de filtragem interna dos servidores SMTP (MTA) são geralmente bastante básicas e remontam a época da 2ª fase do SPAM, quando os servidores SMTP começaram a serem modificados pelos próprios desenvolvedores para se fazer frente as práticas SPAMMERS mais básicas.

            Em geral são regras bastante simples e fáceis de serem configuradas:

·        Bloqueio de mensagens oriundas de um numero IP ou de uma faixa de números IP;

Exemplo: 192.168.0.0/24              REJECT

·        Bloqueio de mensagens oriundas de um determinado FQDN (Fully Qualified Domain Name);

Exemplo: sexhot.com                     REJECT

·        Bloqueio de mensagens oriundas de domínios inexistentes;

Exemplo:  MAIL FROM: diabo@wsjdhgstevsrftrs.uuu

                 550 5.7.1 Rejected. Invalid domain wsjdhgstevsrftrs.uuu

·        Bloqueio de mensagens com domínio inexistente ou inconsistente quando do comando SMTP HELO (OBS.: Pouco utilizada devido ao fato do comando HELO ser costumeiramente preenchido com informações sem consistência nenhuma);

Exemplo:  HELO wsjdhgstevsrftrs.uuu

                 550 5.7.1 Rejected. Bad domain in HELO

·        Mensagens oriundas de um determinado endereço;

Exemplo:  MAIL FROM: ocarteiro@correio.com.br

                 550 5.7.1 Rejected. Bad remote user address

·        Bloqueio de mensagens para um determinado usuário local;

Exemplo:  RCPT TO: local-list@mydomain.com

                 550 5.7.1 Rejected. Local user don’t receive messages

·        Relay incondicional de mensagens restrito a rede local;

Exemplo:  146.164.48.0/26           RELAY

                 ALL                             REJECT

5.2.2. O uso das BlackLists

            A técnica da BlackList ou RBL (Realtime Black List) ou mais modernamente DNSBL (Domain Name Service Black List) é uma técnica ANTISPAM surgida na época da 2ª Fase do SPAM, quando eram mais exploradas as máquinas com relay aberto.

            Esta técnica foi concebida por Paul Vixie, que mais tarde fundaria uma entidade chamada de MAPS (Mail Abuse Prevention System) [2], que teve o brilhantismo de utilizar a própria base instalada dos servidores de DNS (Domain Name Service) [26] e [27] mundiais para propagar a informação das BlackLists por ele criada.

            Mas como funciona em si a técnica da BlackLists ou DNSBL? Existem alguns sites na Internet que explicam de forma mais detalhada esta técnica, um deles é o site da ANTISPAM-UFRJ [15], de onde se baseou a explicação desta técnica.

            Supondo que, por algum método, uma entidade mapeou servidores de SPAMMERS, servidores SMTP com relay aberto e/ou faixas de IPs temporários e queira disponibilizar essa informação pela Internet, ela pode fazer uso de uma tabela de DNS direto de um subdomínio dela.

            Vamos tomar de exemplo a base de dados de relay aberto, supondo que a entidade se chama antispam.foo, ela cria um subdomínio chamado open-relays.antispam.foo. Neste subdomínio ela indexará os IPs 10.0.0.1, 10.0.0.5, 10.0.0.7 e 10.0.0.15. Para indexá-los, ela simplesmente coloca os octetos na ordem reversa e acrescenta o subdomínio neles, apontado-os para um IP da classe A 127.0.0.0/8, com exceção do 127.0.0.1 (LoopBack IPv4). Abaixo um fragmento de tabela de DNS exemplifica o que foi aqui escrito:

            1.0.0.10.open-relays.antispam.foo       IN        A         127.0.0.2

            5.0.0.10.open-relays.antispam.foo       IN        A         127.0.0.2

            7.0.0.10.open-relays.antispam.foo       IN        A         127.0.0.2

            15.0.0.10.open-relays.antispam.foo     IN        A         127.0.0.2

            Suponhamos agora que um servidor SMTP consulta a BlackList de relays abertos da antispam.foo. Neste servidor deverá ter configurado a lista a ser consultada, que no caso se traduz pelo subdomínio open-relays.antispam.foo.

            Se a máquina 10.0.0.5 conectar neste servidor SMTP, o mesmo fará uma consulta ao DNS da rede dele para saber qual o IP de 5.0.0.10.open-relays.antispam.foo. Obviamente o IP será 127.0.0.2, o que indica que a máquina 10.0.0.5 está na tabela de máquinas com servidor SMTP com relay aberto, e o servidor SMTP deve retornar uma mensagem de erro explicativa e terminar a conexão SMTP sem que a mensagem vinda daquela máquina seja recebida.

            Como se pode ver o funcionamento e a consulta de um DNSBL é muito simples. Devido a isso é que existem milhares de redes em todo o mundo que fazem consultas as várias entidades mundiais que mantém DNSBLs ativos. Dentre estas entidades, as que mantêm as listas mais famosas (e mais consultadas) são o MAPS-RBL [2], o SpamCop [7] e o SpamHaus [4].

            Os DNSBLs são bastante práticos, porém um problema relativo a eles é derivado do fato que a consulta a eles é através dos mecanismos de resolução de nomes, que utiliza o protocolo UDP, ou seja, não há garantia do retorno da solicitação da consulta.

            Isto gera o problema dos “falsos negativos” em redes com conexões externas lentas ou quando se consulta listas com poucos servidores DNS secundários. Por “falso negativo” entenda-se o fato da consulta ser feita e não haver resposta, geralmente neste caso é retornado um host not found ou host unknow, o que para o mecanismo de BlackList significa que a máquina não esta indexada na lista consultada, mesmo que esteja, e neste caso um SPAM poderá passar livremente até o seu destinatário.

            Para diminuir a possibilidade de “falsos negativos”, as entidades que mantêm DNSBLs costumam ter alguns DNS secundários “espalhados” na Internet, o que previne da informação não estar disponível por quaisquer motivos de queda em suas conexões externas com a Internet.

            Outra forma de diminuir a ocorrência de “falsos negativos” e o servidor SMTP fazer consultas a mais de uma entidade, partindo do pressuposto que a máquina SPAMMER possa estar indexada em mais de uma lista, porém consultar um número grande de BlackLists pode diminuir sensivelmente a performance do mesmo.

5.2.3. O uso da técnica de GrayListing

            A técnica de GrayListing [17] é uma técnica relativamente recente, surgiu por volta de 2001, é baseia-se em fazer uma lista de bloqueios temporários em tempo real. Ela foi criada para combater em maior grau o SPAM-SPOOFING e em grau intermediário o WEB-SPAM e o SPAM-ROUTING, sendo porém aplicada a outras modalidades de SPAM.

            O princípio de funcionamento do GrayListing é o de rejeitar a primeira conexão de um cliente remoto e esperar um determinado tempo antes de liberar o recebimento da mensagem na conexão seguinte.

            Suponhamos que a máquina 192.168.0.2 conecte em um servidor SMTP que esta configurado para utilizar a técnica da GrayListing. Supondo ser a primeira conexão dela para enviar aquela determinada mensagem, o servidor SMTP irá copiar numa lista o número IP da máquina remota, o remetente passado no comando SMTP MAIL FROM e o destinatário passando no comando SMTP RCPT TO. Imediatamente após isso, ele retorna uma mensagem SMTP com o código de erro temporário (451 4.1.8), o que instrui o cliente (se ele for um servidor SMTP) a tentar conectar novamente mais tarde (tipicamente 1 minuto) e encerra a conexão.

            A idéia do uso do GrayListing é que os SPAMMERS usam engenhos (robots) para enviar SPAMs e não servidores SMTP normais, pois não querem receber avisos de erros e nem reclamações por SPAMs por eles enviados e querem enviar o maior número de mensagens o mais rapidamente possível. Geralmente esses robots são programas muito simples e rústicos, sendo que enviam E-mails de forma seqüencial e não gerenciam filas de saída, para serem bastante rápidos. Logo, a possibilidade do robots tentar enviar novamente o SPAM será pequena, pois muitas vezes eles tem que enviar milhares ou milhões de E-mails, o que leva horas ou até dias.

            Desta forma, após passado um certo tempo (um 1 minuto), se a máquina 192.168.0.2 conectar novamente, provavelmente estará rodando um servidor SMTP e a possibilidade da mensagem ser um SPAM será menor. Assim, a entrada relativa aquele E-mail inicialmente rejeitado será removida da GrayListing do sistema e a mensagem poderá ser entregue.

            A técnica do GrayListing foi muito eficaz quando foi lançada, e muitos achavam que isso iria ser eternamente eficaz contra o SPAM. Infelizmente tem-se observado nos últimos tempos que novos tipos de robots SPAM estão trabalhando com gerenciamento de filas e listas menores, para tentarem assim poderem burlar a técnica da GrayListing.

            Um outro problema que se tem notado com GrayListing é quando um pessoa envia vários E-mails para outra cujo servidor SMTP implemente GrayListing. O tempo de espera imposto pelo servidor SMTP pode fazer com que as mensagens cheguem ao destinatário fora de ordem, caso o usuário esteja lendo as mensagens num horário próximo ao do envios das mensagens.

            Há ainda o fato que alguns poucos ISP, por terem trafego de E-mails muito elevados ou por inexperiência de seus administradores de rede, costumam programar seus servidores SMTP para retornarem as mensagens para os usuários após quaisquer erros (mesmo que temporários) sem tentar reenviá-las, logo após a primeira tentativa.

5.2.4. A regra da verificação da consistência do DNS reverso (RFC-1912)

            A técnica da consistência do DNS reverso [39] e [40] tem por base interpretar ao pé da letra a RFC-1912 [28]. Esta RFC informativa instrui que quando um FQDN é atribuído a um número IP no DNS, este numero IP deve apontar para esse FQDN no DNS reverso, independentemente de existirem ou não outros FQDNs apontando para esse mesmo numero IP. Está técnica ANTISPAM é considerada uma das mais agressivas.

            Desta forma, está técnica pressupõem que a maioria dos SPAMMERS preferem tacitamente o anonimato e assim eles preferirão usar as faixas de IPs dinâmicos de ISPs que, por comodidade ou ignorância dos administradores de redes dos ISP, não sigam o que esta escrito na RFC-1912. Na verdade, poucos ISPs configuram DNS reverso para as próprias faixas de IPs dinâmicos e quando o fazem, geralmente o fazem com denominações bem sugestivas com ppp, dialup, users, etc, para a comodidade deles.

            Da mesma forma, os SPAMMERS que possuem linhas dedicadas tipo ADSL não fazem nenhuma questão de pedir aos ISPs que estes apontem corretamente o DNS reverso do número IP, que eles estão usando na linha dedicada, para o nome do domínio na Internet da pessoa jurídica (empresa) que eles, os SPAMMERS, utilizam para dar suporte as atividades SPAMMERS que eles praticam.

            Realmente, já se verificou em muitas ocasiões que a maior parte dos SPAM recebidos por muitos usuários provêem de IPs sem DNS reverso ou com DNS reverso inconsistente, o que significa, neste último caso, que o IP aponta para um FQDN que não aponta de volta para esse mesmo IP.

            O ponto fraco desta técnica de verificação de consistência do DNS reverso é que a possibilidade de ocorrerem os chamados “falso positivos” não é desprezível, principalmente porque existem administradores de rede desleixados ou ignorantes que não configuram o DNS reverso para os servidores SMTP das suas respectivas redes. Muitos deles ficam até insistindo que a configuração das suas redes estão perfeitas e que eles não irão modificar nada nelas, numa total demonstração de ignorância das normas requeridas para o bom funcionamento da Internet.

            É recomendável, porém, o uso desta técnica quando a quantidade de SPAMs recebidos semanalmente por um usuário for grande, pois fatalmente o endereço do dele já devera estar indexado em centenas ou até milhares de listas SPAMMERS de todo o mundo. Porém é recomendável deixar esse tipo de decisão nas mãos do próprio usuário e não por conta apenas do administrador da rede, para se evitar possíveis atritos entre ambos

5.2.5. A regra da verificação das strings do DNS reverso

            Está técnica é semelhante a anterior, porém ela se baseia apenas em verificar, caso o DNS reverso do IP da maquina remota esteja configurado, as strings que compõem o FQDN apontado pelo DNS reverso. Está técnica ANTISPAM é também considerada uma das mais agressivas, tal qual a anterior.

A idéia desta técnica é procurar achar strings (cadeias de caracteres) típicas que identifiquem o tipo de conexão usada pela maquina remota e supor se á máquina está usando um IP temporário ou uma conexão dedicada de IP fixo e, neste último caso, se a máquina com IP fixo é uma máquina que pode enviar E-mails de SPAMs ou não.

Já se verificou, como na técnica anterior, que grande parte dos SPAMs também vem de maquinas cujos números IPs apontam para FQDN com strings típicas de conexões de IPs temporários, como ppp, dial, dialup, users, dip, etc.

Também usa-se essa técnica para partir do principio que, se uma empresa séria compra uma conexão dedicada e quer enviar E-mails seriamente e não como SPAMMERS, ela irá exigir que o DNS reverso do ISP aponte para o FQDN dela.

Exemplo:

   Fragmento de tabela de DNS direto:

   mail.minhaempresa.com            IN        A         192.168.254.8

   Fragmento de tabela de DNS reverso:

   8.254.168.192                             IN        PTR      mail.minhaempresa.com

Caso o contrario, sendo uma empresa que trabalha com E-mail marketing (ou seja, SPAM), ela ira querer anonimato e não ser identificada com facilidade por quem recebe o SPAM, logo não irá exigir nada disso ao ISP.

O ponto fraco dessa técnica é que algumas empresas, geralmente por desconhecimento ou ignorância das RFC pelos seus administradores de rede, não fazem nada disso. Logo a ocorrência de “falsos positivos” nesta técnica também não poderá ser considerada desprezível.

Tal qual a regra anterior, está é recomendável quando a quantidade de SPAM recebidos por um usuário diariamente é muito elevada, pois ele possivelmente esta indexado em centenas ou milhares de listas SPAMMERS. De todo modo, a decisão de fazer-se isso ou não deve se deixada por conta do próprio usuário, também para evitar atritos desnecessários com o administrador de redes.

Apesar da agressividade dessas duas regras ANTISPAM, já verificou-se que, na pratica, é com o uso de ambas que se consegue barrar a maior parte do SPAM atualmente, pois usando-se elas os SPAMMERS, que em sua imensa maioria são covardes atrás de um computador, tem de escolher entre continuar não conseguindo enviar os E-mails de SPAM ou terem que identificar corretamente os números IP nos DNS direto e reverso de suas redes e correrem o risco de serem identificados e de terem os respectivos domínios na Internet colocados em listas negras, alem de outras sanções penais poderem ser-lhes imputadas mais facilmente.

5.2.6. Verificação da consistência do comando MAIL FROM

            A técnica da verificação da consistência do comando SMTP MAIL FROM é uma técnica surgida durante a 3ª fase do SPAM.

            Esta técnica pressupõem que o SPAMMER procurara na maioria das vezes mascarar sua identidade colocando um endereço inconsistente durante o comando SMTP MAIL FROM.

            Uma verificação de consistência já é feita atualmente pelos servidores SMTP, que checam se o domínio do endereço passado no comando SMTP MAIL FROM é válido. Isto foi implementado primeiro no Sendmail no final da 3ª fase dos SPAM, pois verificou-se que a maioria dos SPAMs na época colocavam domínios inexistentes nos endereços passados durante do comando SMTP MAIL FROM. Eles faziam isso para que o E-mail não tivesse retorno e acabassem parando o endereço do postmaster do sistema.

Infelizmente essa verificação logo foi burlada, passando-se a colocar no comando SMTP MAIL FROM endereços validos, na maioria dos caso, ou aos menos com domínios existentes, o que acabou acarretando que, fatalmente, algum postmaster iria acabar recebendo o SPAM que havia sido enviado, o que só fez aumentar o trafego SMTP, ao invés de diminuí-lo.

Alem da verificação de consistência acima, outras três podem ser feitas: O uso do null-reverse path (<>), o uso do domínio local, a verificação de “caracteres proibidos” e a verificação se o servidor remoto aceita receber conexões SMTP.

Verificação do null-reverse path: O uso do null-reverse path (quando se coloca <> após o comando SMTP MAIL FROM) é previsto desde a RFC-821 (atualmente RFC-2821). Ele foi criado como uma forma do próprio servidor SMTP enviar E-mails de erros ou avisos evitando a ocorrência dos chamados mails-loops. Um mail-loop pode ser gerado em condições especiais, por exemplo, por um alias mal configurado, que provoque que o mesmo E-mail passe continuamente pelo servidor SMTP (como se você andasse em círculos) infinitas vezes. Antigamente isso provocava um uso excessivo da CPU pelo servidor SMTP, provocando muitas vezes a queda do sistema. Atualmente os servidores SMTP possuem artifícios mais ou menos eficazes para evitar o mail-loop infinito.

Porém, a RFC-821 não restringiu o uso do null-reverse path apenas ao servidor SMTP da rede local. Devido a isso, ele se tornou muito prático para os SPAMMERS e para os criadores de vírus, pois o servidor SMTP muitas vezes mascara o null-reverse path com o nome MAILER-DAEMON, e o usuário incauto pensa tratar-se de um E-mail de erro do sistema e o abre pensando tratar-se de algo muito importante.

Restringir-se o uso do null-reverse path apenas a rede local e as “redes amigas” é uma excelente pratica que evita uma boa quantidade dos SPAMs que se receberia normalmente.

Verificação do uso do domínio local: Consiste em permitir que somente as máquinas da rede local e de “redes amigas” possam colocar um endereço com o domínio da própria rede local durante o comando SMTP MAIL FROM. Muitos SPAMs são geralmente recebidos contendo a informação que ele veio a partir do próprio endereço do usuário ou de outros usuários da rede, de forma a tentar enganar o usuário local que queira descobrir como isso aconteceu.

Apesar de ser uma boa prática fazer esse tipo de restrição, ela tem o inconveniente que o usuário não poderá mais enviar E-mails para outros endereços na rede local, contendo como endereço de origem o seu próprio endereço na rede local, a partir de outras redes que não sejam a própria rede local ou as “rede amiga”.

Exemplificando: Se a rede local é 10.0.0.0/24, com domínio foo.org, e ele quiser enviar um E-mail a partir de 192.168.0.0/24, usando no comando SMTP MAIL FROM o endereço dele, por exemplo ele@fog.org. Se a rede 192.168.0.0/24 não for configurada como “rede amiga” no servidor SMTP da rede 10.0.0.0/24, a conexão SMTP será rejeitada.

Verificação de caracteres “proibidos”: Consiste em rejeitar conexões SMTP quando, durante o comando SMTP MAIL FROM, o endereço passado contiver caracteres considerados “proibidos”. Entende-se por isto caracteres não usuais em endereços SMTP passados no comando SMTP MAIL FROM, como &, #, !, ~, _, (, ), ^, *, etc. Uma grande parte dos SPAMs possuem caracteres “proibidos” para mascarar ainda mais a identidade do remetente. Robots também costumam usar esses caracteres no gerador de nomes aleatórios de usuários.

O problema desta verificação é que vários ISP permitem o uso de alguns caracteres que seriam considerados “proibidos”, tais como o _ e o & (os mais utilizados pelos SPAMMERS) nos endereços de origem das mensagens de seus usuários.

Verificação se o servidor remoto aceita conexão SMTP: É realizada por alguns servidores SMTP como o Postfix (mas não como configuração default) após o comando SMTP MAIL FROM. Eles verificam se a máquina que fez a conexão aceita receber conexões SMTP (principio da bi-direcionalidade).

O problema principal desta técnica é que muitos ISP costumam configurar os chamados MAILHUBS, que são máquinas que apenas enviam E-mails de dentro para fora da rede, e os MAILHOSTS, que são máquinas que só recebem conexões de dentro para fora da rede. Logo a possibilidade de “falsos positivos” é alta. Alem disso, existe o tempo de delay que é criado para liberar ou não a mensagem, que no pior caso será o tempo de timeout da conexão SMTP para o servidor remoto.

5.2.7. Análise do conteúdo de E-mails pelo servidor SMTP usando plugin

            O uso de plugins nos servidores SMTP está muito em voga atualmente. Alguns plugins são para a prevenção de E-mails contendo vírus, outros para a prevenção de SPAMs.

            Para a prevenção de SPAM, alguns plugins como o Spam-Assassin [41], oferecem suporte a análise do conteúdo de um E-mail, geralmente pelo método da pontuação, que será descrito mais adiante, pois ela pode também ser utilizada por programas próprios dos usuários.

            Existem três problemas relacionados com o uso de plugins para a analise do conteúdo de E-mails para a verificação da ocorrência de SPAM:

1.      Eles não impedem a degradação da largura de banda do canal de conexão externo das redes, pois tem que receber toda a mensagem para analisá-la.

2.      Dependendo da configuração feita pelo administrador da rede, eles não impedem o usuário de receber o SPAM, apenas colocam um aviso no subject (título) da mensagem avisando que provavelmente se tratar de um SPAM, ficando a análise final do conteúdo e a remoção do E-mail por conta do destinatário final da mensagem. Desta forma os problemas ao sistema, causado pelo acumulo de mensagens inúteis, continuam.

3.      Atualmente eles são ineficazes para verificar SPAMs que se valem da técnica do SPAM COM IMAGENS, o que será visto mais adiante também.

Por isso, o uso de plugins para combate a SPAM deve ser encarado como uma ferramenta auxiliar as regras ANTISPAM vistas anteriormente, ou seja como uma 2ª linha de defesa contra SPAM, e não como única alternativa para elas.

5.2.8. Comentários sobre uma técnica “nati-morta”, o MARID

            O MARID (MTA Authorization Record in DNS) [29] era uma técnica de autorização com certificação proposta pela Microsoft, no início de 2004, junto a IETF e que faria uso da base instalada de servidores DNS (tal qual a técnica da BlackLists, porém através da resolução de uma entrada nova na tabela do DNS, que seria adicionada por uma nova RFC específica) para a certificação digital de servidores SMTP, com intuito de combater o SPAM. Essa técnica, se tivesse vingado, seria mais uma técnica da chamada 1ª linha de defesa contra SPAM.

            Era a essa técnica inclusive que o fundador da Microsoft, Bill Gates, se referiu bastante no ano de 2004 quando afirmou que o SPAM duraria no máximo mais dois anos.

            Nesta técnica, o servidor SMTP, ao receber uma conexão remota, poderia receber ou não um certificado (o uso desta técnica de certificação não seria obrigatório, para se manter a compatibilidade com os sistemas mais antigos).

Se recebesse o certificado, ele procuraria autenticá-lo fazendo uma resolução de DNS. Caso a autenticação fosse confirmada, ele permitiria a passagem da mensagem sem a necessidade de verificação de quaisquer regras ANTISPAM, pois a autoridade certificadora garantiria que o cliente remoto não é um SPAMMER.

Embora na teoria essa técnica parecesse boa, algumas indagações ficam. Quem seria a autoridade certificadora? Como seriam os certificados? Quanto custariam? Qual seria o tempo de validade dos certificados? Como saber se um SPAMMER não iria adquirir um certificado? (Lembrando-se que se pressupõem que a atividade SPAM seja altamente lucrativa, por que os SPAMMERS não comprariam certificados).

Infelizmente essas questões ficarão sem respostas, pois o IETF descontinuou o desenvolvimento do MARID [30] ainda no final de 2004 devido a exigências relativas a patentes feitas pela Microsoft a IETF [31], ou seja, a Microsoft “vendeu” a idéia do MARID para o IETF, que trabalhou muito para fazê-lo um padrão aberto e sem pagamento de patentes, e depois, no meio do caminho, “mudou” de idéia. Assim, o MARID acabou sendo abandonado pela IETF, que não queria impor um padrão de certificação, num protocolo aberto, que implicaria no pagamento de direitos de patentes para terceiros.

            O MARID está sendo aqui citado porque, alem do ter sido bastante comentado no passado recente, ele foi a primeira tentativa de se introduzir certificação na troca de mensagens eletrônicas. Infelizmente não foi adiante e por enquanto ainda não há uma nova proposta satisfatória para certificação na troca de mensagens eletrônicas.

5.3. Técnicas ANTISPAM em nível de usuários de redes

            As técnicas ANTISPAM em nível de usuários de rede são aquelas implementadas a nível das aplicações que os usuários utilizam para ler seus E-mails ou, de modo mais geral, a nível de programas auxiliares externos (plugins) para tais aplicações.

            Tais técnicas começaram a surgir no final da 3ª fase do SPAM e constituem-se na 3ª linha de defesa antes de um SPAM conseguir alcançar um usuário, muito embora na verdade o SPAM chegue na caixa de entradas do usuário, pois o aplicativo apenas irá marcar a mensagem como um SPAM ou irá mover a mensagem para uma caixa de mensagens especial para o usuário posteriormente examinar ou apagar sem ler nada.

            Nota-se que ao chegar neste ponto, o SPAM já prejudicou a largura de banda do canal de comunicação externo da rede e os recursos do sistema (disco e tempo de CPU). Dependendo da situação, poderá ou não afetar ainda o custo homem/hora para ler ou não as mensagens e apagá-las.

            O tópico 5.3.5, cuidados especiais para evitar de entrar em listas de SPAMMERS, discorre sobre conselhos importantes para evitar que um endereço eletrônico seja indexado em listas de SPAMMERS. Tais conselhos ajudarão em muito em evitar que a quantidade de SPAMs recebidos cheguem a níveis insuportáveis.

5.3.1. A análise dos cabeçalhos das mensagens

            A técnica de análise dos cabeçalhos de uma mensagem consiste em verificar os campos principais que formam a parte da mensagem responsável pela identificação do remetente (From:), do destinatário (To:), o assunto da mensagem (Subject:), os servidores SMTP por onde a mensagem passou antes de chegar em seu destino (campos Received:), etc. Os campos dos cabeçalhos de uma mensagem foram descritos inicialmente na RFC-753 (1979), RFC-822 (1981) e atualmente são descritos pela RFC-2822 (2001). Abaixo segue um exemplo típico de um cabeçalho de um E-mail SPAM originado de uma máquina com um servidor SMTP bem arcaico e possivelmente aberto (relay aberto ou open relay):

            Muito embora na maioria dos casos se repita os endereços dos comandos SMTP MAIL FROM e RCPT TO respectivamente nos campos From: e To: das mensagens, isto não é obrigatório. Logo pela análise dos cabeçalhos de uma mensagem pode-se filtrar E-mails com um determinado campo From: que se repita em muitos SPAMs. Também pode-se filtrar campos To: que não contenham o endereço real do destinatário de uma mensagem (técnica muito usado pelos SPAMMERS) e pode-se filtrar ainda, no campo Subject:, um determinado assunto que seja repetido em muitos E-mails.

            Outro tipo de filtragem feito pela análise dos cabeçalhos é através dos campos Received: de uma mensagem, onde pode-se filtrar mensagens que tenham se originado ou passado por um determinado servidor que esteja enviando SPAM (o que atualmente é impossível de ser feito em tempo real pelos servidores SMTP).

            Existe ainda o campo Date, que indica a data e hora do remetente. É pratica bastante corrente dos SPAMMERS colocarem informações de data e hora no campo Date totalmente fora do especificado na RFC-2822 como, por exemplo, Date: Domingo, 15 de Maio 2005, 01:00 Horário oficial da América do Sul, quando o correto seria Date: Sun, 15 May 2005 01:00:00 -0300. Muitos SPAMMERS também costumam colocar o campo date com uma data e/ou hora futura porque muitos clientes de E-mails colocam os E-mail com data e/ou mais recente no inicio da listagem da caixa de entrada.

            Como se pode ver, muitos SPAMs podem ser descartados por um aplicativo que faça uma simples analise de cabeçalhos de mensagem, desde que corretamente configurado.

5.3.2. A análise do conteúdo das mensagens

            A filtragem de conteúdos de mensagens é uma das técnicas ANTISPAM mais usadas a nível de usuário. A lógica desta técnica é que, geralmente, as mensagens SPAMs costumam repetir com muita freqüência as mesmas expressões, frases ou períodos.

            Um bom exemplo disso é o texto sobre o “105º Congresso Internacional de Bases Normativas sobre SPAM” ou ainda o texto “Esta mensagem não pode ser considerada SPAM se contiver um meio do destinatário ser removido da lista”. Se usarmos alguns aplicativos simples, como o filter do Unix, podemos jogar na lixeira todas as mensagens que vierem com estes textos. Geralmente, como os textos sofrem pequenas variações, inclusive na língua em que são escritos, convêm ter as várias versões deles e colocar-se apenas fragmentos e não o texto completo para filtar.

            Muitos usuários costumam configurar alguns softwares de análise de texto de mensagens, como o filter do Unix, para filtrarem mensagens que contenham um certo conjunto de palavras.

            Pode-se ainda filtrar conteúdos de mensagens pelos campos CONTENT-<*> delas. Onde o <*> representa os diversos tipos de conteúdos que podem compor a mensagem, como HTML, TYPE (que engloba arquivos executáveis, arquivos DOC, PDF, etc). Desta forma pode-se inclusive descartar aquelas mensagens fraudadas do SPC, SERASA, etc e com um executável anexado apenas procurando-se pela existência do campo CONTENT-TYPE e examinando o seu conteúdo. Um exemplo:

            Com exceção da filtragem pelos campos CONTENT-<*>, a técnica da filtragem por conteúdo tem a deficiência de não conseguir filtrar mensagens de texto escrita dentro de imagens gráficas, pois atualmente não existem softwares capazes de ler um texto escrito dentro de uma imagem gráfica. Dada a quantidade gigantesca de formatos gráficos existente atualmente (jpeg, gif, tiff, png, etc), é muito complexo se desenvolver um programa para esse fim e não será tão cedo que um surgira. Logo essa técnica é vulnerável ao SPAM COM IMAGENS.

            Uma solução seria filtrar todos os campos CONTENT-TYPE apontando para imagens, porém ainda assim haveriam problemas com os E-mails não-SPAMs. Alem disso, teria que se filtrar E-mails com tags HTML apontando para imagens em sites remotos, o que seria inviável atualmente, uma vez que uma grande parte dos E-mails são escritos atualmente utilizando-se HTML.

5.3.3. A técnica da confirmação da autenticidade do remetente

            Esta é uma técnica oferecida por alguns ISP, como AntispamUOL do Universo OnLine (UOL) [42], e por alguns aplicativos, como o SafestMail [43]. Ela tem pequenas variações, mas o principio de todas elas é que um remetente desconhecido pelo destinatário deve se identificar junto a este antes que a mensagem possa ser liberada para leitura.

            Esta técnica serve para barrar os E-mails enviados por robots (softwares) SPAMMERS automáticos, pois estes não possuem a lógica humana para agir quando uma mensagem pede para eles se identificarem (quando existem E-mail de retorno valido para o SPAM enviado).

            No engenho do AntispamUOL, quando um E-mail é recebido e o usuário do UOL não tem o endereço do remetente na sua relação de liberados, um E-mail é enviado pelo sistema para o endereço do remetente (obtido no campo To:) informando que o mesmo deve entrar no link informado no corpo do E-mail para liberar a mensagem.

            Tal link leva a uma página onde uma imagem com um texto (caracteres alfanuméricos) é gerada em tempo real e a pessoa deve escrever o texto que lê na imagem. Como já foi dito, nenhum software atualmente consegue ler textos dentro de imagens, isto vale para os robots SPAMMERS também.

Fig.2 - Exemplo de texto em imagem gerado por software

            O software SafestMail, funciona de modo semelhante ao AntispamUOL, porém como não é um sistema corporativo para vários usuários, mas um aplicativo de usuário, este envia um E-mail automático (quando o usuário for usar o cliente de E-mail dele) em que o remetente deverá informar o assunto que ele quer tratar com o destinatário da mensagem. Por assunto estenda-se uma strings de tamanho limitado, para evitar que uma string contendo um endereço com propaganda seja enviada.

            Ambos, os sistemas e os softwares, são excelentes para o bloqueio de SPAMs originados dos robots SPAMMERS (ou spambots, como também são conhecidos). Porém existem alguns problemas relacionados ao funcionamento dessa técnica, alguns que necessitam da correta configuração dos sistemas ou softwares pelo usuário para evitá-los, outros que não haverão de como serem evitados. São eles:

·        O usuário deve colocar todos os remetentes autorizados, e todos os endereços de destinatários autorizados utilizados por ele. Por exemplo, ele deve colocar todos os endereços das listas de discussão, que ele assine e que venham preenchido no campo To: do cabeçalho da mensagem, senão o sistema ou o software irá disparar E-mails automáticos para as listas de discussão, o que irritará muitos usuários de tais listas.

·        Ainda sobre o que foi falado acima, se a lista de discussão não tiver proteção contra SPAM, quaisquer SPAMs enviados para a lista serão recebidos pelo usuário.

·        Se a lista de remetentes autorizados for descoberta o usuário ficará vulnerável, porque o sistema ou software somente analisará o campo From da mensagem (será inviável o sistema ou software tentar analisar a origem do E-mail, pois poderá cair em muitos resultados “falso-positivos”.

·        A proteção pressupõem que se trata de um spambot (software) que possui “inteligência” limitada, mas muitos SPAMMERS contratam pessoas para a tarefa de burlarem esses casos “excepcionais”, o que significa autorizar manualmente em sistemas como o AntispamUOL, ou tentar enganar habilmente o destinatário, como no caso do SafestMail.

·        Está-se começando a desenvolver uma nova geração de vírus, worms e Trojans que, ao invadirem a máquina de um usuário, irão exportar as listas de endereços (bookmarks) do mesmo para máquinas SPAMMERS, e desta forma os usuários de tais sistemas ou softwares poderão passar a ficarem vulneráveis novamente a SPAMs originados de spambots que poderão mascarar-se como remetentes autorizados.

Pode-se dizer ainda que embora tenham resultados bastante satisfatórios para os usuários finais, esses sistemas e softwares acarretam um aumento do trafego SMTP, o que prejudica mais a largura de banda do canal de comunicação externo das redes, alem de exigirem mais dos recursos dos sistemas, pois os E-mails, independentes de serem SPAMs ou não, devem ser armazenados por um certo período de tempo, a espera do contato do remetente (normalmente e 3 a 5 dias, conforme a configuração do sistema ou do software).

Disto que foi discorrido acima, surge mais uma vulnerabilidade grave: Os sistemas ficam muito vulneráveis a ataques de DDoS (Deny of Service), pois vários SPAM-SPOOFING poderiam simplesmente acabar com o espaço em disco disponível, pressupondo que todos os endereços de remetentes estejam corretos. Nos ISP isso é prevenido prevendo-se de ante-mão sistemas com discos de altíssima capacidade. Nos computadores pessoais dos usuários, a alternativa é trabalhar com períodos de armazenamento menores ou discos de capacidades maiores, mas nunca rodar tais softwares com pouco espaço em disco.

Ainda que tais problemas talvez tenham uma possibilidade remota de acontecer, se deve ter em mente que eles podem acontecer realmente. Porém o usuário não deve ficar temeroso em usar sistemas ou softwares que implementem essa técnica apenas por causa de tais problemas.

5.3.4. A técnica da pontuação da mensagem

            A técnica da pontuação da mensagem é utilizada por alguns plugins de MTA, como o Spam-Assassin (2ª linha de defesa), porém é mais utilizada por softwares finais de usuários (3ª linha de defesa), por isto está aqui descrita.

            A técnica da pontuação da mensagem é inspirada na técnica da analise do conteúdo da mensagem, porém com uma pequena nuance que difere uma da outra:

·        A técnica da analise do conteúdo procura por palavras especificas ou conjunto de palavras.

·        A técnica da pontuação atribui valores para cada palavra encontrada e lhe atribui um valor, palavras relacionada a SPAMs recebem valores elevados. No final, os valores são somados e, a partir de um patamar atingido ou ultrapassado, a mensagem pode ser descartada ou marcada como SPAM no subject, como faz o Spam-Assassin.

Para um exemplo simples da técnica da pontuação, vamos imaginar uma mensagem contendo apenas a frase “Acesse e veja as garotas fazendo sexo anal”, vamos dizer que o patamar seja 100 e atribuímos os valores 40 para a palavra sexo, 30 para a palavra garotas, 40 para a palavra anal e 0 para as demais palavras. O software totalizaria 110 e adicionaria ao titulo (subject) da mensagem um aviso como “[SPAM Suspected]”.

É claro que este é um exemplo muito simplificador, mas descreve bem a metodologia desta técnica.

A fraqueza desta técnica é que ela é vulnerável ao SPAM COM IMAGENS, uma vez que, como já foi visto, não existe nenhum software atualmente que leia textos escritos dentro de imagens gráficas.

5.3.5. Cuidados especiais para evitar de entrar em listas de SPAMMERS

            O velho ditado já dizia: “Melhor prevenir do que remediar”. A seguir algumas dicas úteis para evitar de entrar em listas de SPAMMERS:

·        NUNCA divulgue teu E-mail abertamente em paginas HTML na Internet, pois fatalmente os robots WEB-SPAM irão catalogá-lo.

·        Se tiver que colocar teu E-mail em páginas HTML na Internet, procure usar scripts (Javascript, Java, etc) que irão gerá-los dinamicamente num browser com suporte a Javascript, Java, etc. Uma alternativa é colocar o teu E-mail em uma imagem gráfica, tipo jpeg ou gif, assim somente um ser humano poderá lê-lo.  No código HTML do resumo (página de abertura inicial da versão HTML deste trabalho) há um Javascript que gera dinamicamente os dois E-mails lá mostrados.

·        Crie páginas que geram links e E-mails falsos antes do teu E-mail. Isso ira enganar e diminuir a performace dos WEB-SPAM. O uso de alguns scripts CGI em perl são muito bons para criar E-mails falsos e os disponibilizar. Por exemplo, o WPoison [14].

·        Se receber um SPAM, nunca o responda nem clique em link nenhum que informe que clicando ali o teu E-mail será removido. Provavelmente você estará confirmando a validade do teu E-mail para o SPAMMER.

·        Use softwares ANTISPAM e peça que o administrador da tua rede que configure o servidor SMTP dela com configurações ANTISPAM e plugins antivírus.

·        Rode sempre um antivírus atualizado na tua máquina, isto ajudará a evitar worms ou trojans que enviem as tuas listas de endereços (bookmarks) para os SPAMMERS.

·        Apenas repasse os teus E-mails pessoais para pessoas confiáveis.

·        Tenha sempre mais de um E-mail. Um para as coisas sérias, outro para as coisas pessoais e outro para o resto. Se tiver que divulgar, divulgue o último.

·        Cuidado quando preencher formulários que, entre os campos obrigatórios, exigem um E-mail de contato.

·        Cuidado quando acessar páginas na Internet, principalmente as estranhas que você nunca tenha acessado. Utilize um browser (navegador) seguro para isso.