Masoquismo virtual 101 : mantendo lixo fora de sua caixa-postal (the cheap way)

Com exceção das pessoas que não estão ligadas a área de tecnlogia e, por isso, para as quais não consigo explicar o que faço, a maioria absoluta das pessoas com as quais comento sobre o fato de eu gostar de lidar com implantação e configuração de servidores de e-mail me acham no mínimo ligeiramente lesado mentalmente.

Eu posso entender o que elas sentem. Hoje em dia, com serviços de múltiplos gigabytes de espaço sendo oferecidos gratuitamente (caramba, mais de 4GB no Gmail é um bom espaço só para mensagens), a utilização cada vez maior de webmails e a complexidade de se manter um servidor de e-mail próprio saudável devido as inúmeras pragas virtuais que se propagam como, bem … pragas, ninguém em sã consciência optaria por manter seu próprio servidor de e-mails.

Isso pode ser material para análise futura, quando quiserem identificar quando meus problemas mentais começaram a me afetar de forma mais intensa, mas eu tenho que dizer : eu mantenho meu próprio servidor de e-mails. E, pasmem, eu me divirto fazendo isso. Na verdade, estava dias desses mesmo pensando sobre como diminuir meus gastos com hospedagem de meu servidor virtual, mas quando cheguei a conclusão de que teria que abrir mão de ter meu próprio servidor de e-mails, tive que adiar a decisão para um futuro distante, lá para perto da época em que eu tiver que fazer a renovação de meu plano de hospedagem, só no próximo ano.

Uma das coisas mais interessantes em manter servidores de e-mails (eu mantenho alguns além do meu próprio, principalmente servidores de diversos clientes) é ter que sempre se atualizar para estar por dentro das técnicas e ferramentas que podem ser utilizadas para combater a sempre crescente mania de malucos que acham que você está interessado em adquirir viagra diariamente tem de tentar lhe convencer a comprar alguma coisa inútil.

Uma das formais mais fáceis e eficientes (por enquanto, isso pode mudar rápido) de se evitar receber muito lixo virtual é usando alguma solução de greylisting, em adição a outras técnicas de combate a lixo eletrônico circulando via e-mail.

A técnica de greylisting se aproveita do fato de que uma grande parcela dos spammers não tentam reenviar as mensagens após a primeira tentativa de envio ter gerado uma falha de entrega. Logicamente, eles vão aprender a fazer isso mais cedo ou mais tarde e alguns com menor índice de dislexia mental já aprenderam. Mas, até que a maioria aprenda, é um boa técnica que, em meu caso, chega a evitar que eu sequer repasse spam legítimo para meu sistema antispam checar, o que também auxilia na economia de recursos de processamento e memória.

Como utilizo o famoso MTA Postfix, utilizo também uma solução que se integra facilmente ao mesmo : o Postgrey, sendo executado como um servidor de políticas.

A teoria é simples : o Postgrey fica em execução constantemente como um daemon, ouvindo em uma porta TCP local específica, através da qual o Postfix irá se comunicar com o mesmo. Sempre que uma mensagem nova chegar, antes de decidir entregá-la, o Postfix irá consultar o Postgrey, que irá checar se a mensagem pode ou não ser entregue. Para isso, ele pode checar sua whitelist própria (o que lhe permite excluir servidores ou endereços de destinatários dessa checagem) ou verificar se o destinatário já recebeu alguma mensagem do remetente ou do servidor remoto em questão.

Caso o mesmo já tenho recebido, o Postgrey não rejeita a mensagem e a devolve para o Postfix, para que o mesmo possa fazer o que for necessário com a mesma : geralmente entregá-la ao usuário final, mas, dependendo de como seu servidor está configurado, também seria possível repassá-la a qualquer outro sistema antispam que você possua já configurado (o meu caso).

Caso seja a primeira vez que a mensagem em questão esteja sendo recebida do remetente ou do servidor remoto em questão, a mensagem é temporariamente rejeitada. Mas a rejeição se dá devido ao Postfix responder com um código de retorno do protocolo SMTP que indica que a mensagem foi rejeitada temporariamente e não permanemtemente.

Para qualquer MTA minimamente bem configurado, isso signifca : ok, o servidor na outra ponta parece estar impossibilitado de receber minhas mensagens neste exato momento, então depois tento novamente. E, logicamente, quando a nova tentativa é feita, a mensagem é aceita. Lógico, você pode configurar o tempo necessário para aceitar uma nova tentativa, de forma que somente após esse tempo passado a mensagem seja aceita. Geralmente, são utilizados apenas alguns minutos (5 minutos, por exemplo), o que não implica em um atraso tão grande na entrega das mensagens e, mesmo assim, esse atraso só acontece no primeiro envio.

Ok, explicada a utilidade, vamos botar a mão na massa. Antes de mais nada, instale o Postgrey em seu servidor de e-mails baseado no Postfix. Não vou citar aqui como fazê-lo porque cada Unix ou mesmo cada distribuição Linux possui sua própria forma de instalação de software, mas posso citar que, usando Debian, o software está apenas a um aptitude de distância.

Software instalado e o daemon em execução (o que é o padrão após a instalação do pacote Debian), nos resta apenas configurar a integração do Postfix com o mesmo. Para isso, simplesmente vamos inserir a chamada ao uso do Postgrey como um servidor de políticas como um dos valores do parâmetro smtpd_recipient_restrictions no arquivo de configuração principal do Postfix, o main.cf (em Debian, ficam em /etc/postfix/main.cf).

Mnha configuração básica para esse parâmetro era a seguinte :

smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

Após a inserção do parâmetro para a integração com o Postgrey, esse parâmetro ficou da seguinte forma :

smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, check_policy_service inet:127.0.0.1:60000, reject_unauth_destination

Por último, simplesmente fiz um reload no Postfix para que a nova configuração passasse a ser válida :

# postfix reload

Pronto! Deste ponto em diante, todas as mensagens que chegaram em seu servidor passaram pela checagem feita pelo Postgrey, a solucáo de greylisting pela qual eu optei. Venho usando o Postgrey há mais de um ano e meio com sucesso e posso dizer que, empiricamente falando, algo entre 80% e 90% dos spam legítimos são parados por esse sistema antes mesmo de meu servidor ter que gastar ciclos de processador e memória tentando checar esse lixo todo para classificá-lo como spam.

O que vocês acharam deste post ? Devo começar a postar conteúdo mais técnico como esse ou devo me ater estritamente ao formato anterior do blog, com análise de diversos acontecimentos ocorridos na cena de software livre mundial e expressar minha opinião sobre os mesmos ? Você, leitor, é o chefe. O que manda ?

Anúncios

14 comentários sobre “Masoquismo virtual 101 : mantendo lixo fora de sua caixa-postal (the cheap way)

  1. Pingback: André Luís via Rec6 ~
  2. Eu também tenho meu próprio servidor de e-mails e é bom! Também uso Postgrey e futuramente vou colocar TMDA e brincar com seus recursos! 😉

  3. Uso o postgrey faz um bom tempo em diversos servidores, e ele realmente bloqueia muitos spams mesmo. Muito bom o seu post.

  4. Olá,

    Respondendo ao semente :

    E não é realmente divertido ter seu próprio servidor e gerenciar tudo você mesmo ? Além de ser divertido, é bastante educativo, visto que você tem uma plataforma para experimentação “live” 🙂

    Eu já fiz alguns experimentos com TMDA, mas não em meu servidor pessoal. Fiz em ambiente de laboratório para poder realizar os testes necessários para uma futura implantação em um cliente com essa necessidade e, ao menos em meus testes, parece ter funcionado bem.

    De qualquer forma, eu, particularmente, não gosto muito de TMDA. É exatamente a mesma coisa que aquelas mensagens de confirmação do UOL, por exemplo, algo que a maioria das pessoas que conheço abomina.

    Obrigado pelo comentário.

    Rspondendo ao Xurumy :

    Obrigado pelo comentário e pelo feedback. Eu realmente estava pensando em empregar um esquema misto de posts técnicos e posts com opiniões sobre assuntos relacionados a software livre e afins.

    Sua resposta parece confirmar minha preferência 🙂

    Respondendo ao Hugo :

    Obrigado pelo comentário. Realmente o postgrey é um achado. Soluções de greylisting de uma forma geral, ao menos por enquanto, valem a pena.

    O postgrey especifcamente é interessante por ser bastante simples de configurar e se integrar muito bem com o Postfix. Nunca tive problemas com ele.

  5. André, eu também mantenho meu próprio servidor de email e pretendo continuar fazendo. Estes dias havia lido sobre o Postgrey e seu post me esclareceu um pouco mais. Vou implementá-lo. Penso que deve manter este nível nos seus posts, esclarece quem tem menos conhecimento e ajuda quem precisa dos detalhes sórdidos, desculpe, técnicos.

    Aproveitando a viagem, eu uso o Evolution no desktop/notebook e SquirrelMail por falta de uma opção melhor, tem alguma sugestão? Outra coisa que gostaria de implementar, mas não sei como, é fazer com que ao mover um email para a pasta de mensagens indesejadas do webmail ou do evolution, isto “ensine” as ferramentas antispam. Você tem experiência com isto?

    Minha experiência é menor que a sua neste assunto, porém, me disporia a colaborar numa tarefa que considero importante: criar um tutorial de instalação de um servidor de e-mail, que contemple estes recursos, de preferência com scripts para automatizar a maior parte do processo.

    Obrigado!

  6. Muito bom o post, me interessei bastante por essa solução anti-spam. Na empresa em que trabalho usamos openwebmail + procmail + spamassassin e tem funcionado muito bem, mas algo a mais é sempre bem vindo. Vou procurar se há algo de greylisting que possa ser integrado nesse ambiente. =]

  7. Ola,

    Respondendo ao Efraim :

    Que bom que o post ajudou a clarear seus pensamentos e lhe ajudou a decidir implementar greylisting em seu servidor. Obrigado por opinar sobre que tipo de conteúdo deve ser adicionado ao blog também.

    Sobre você usar Evolution no desktop e Squirrelmail no servidor, não vejo problema algum. Eu uso IMAP (IMAPS, na verdade) em vários clientes de e-mail diferentes (dependendo de que máquina estiver usando) e Webmail também quando estou em uma máquina pública, mas mesmo o acesso ao Webmail é feito via HTTPS, por questões de segurança.

    Sobre a questão de ensinar o sistema antispam sobre o que é e o que não é spam (ham, na verdade), eu tenho isso funcionando em meu servidor pessoal e tenha subpastas IMAP onde movo os falsos positivos (para que o sistema aprenda quando identificar uma mensagem como spam sem que ela seja realmente um spam) e os falsos negativos (para que o sistema aprenda que a mensagem é spam).

    O detalhe é que tenho isso implementado usando DSPAM + Postfix, sem o uso de amavisd-new nem mesmo do SpamAssassin. Foi um pouco demorado configurar e não acredito que seja uma boa solução para usuários comuns, porque a maioria deles não vai aceitar o fato de ter que ensinar o sistema para que ele comece a funcionar bem somente após algum tempo de aprendizado.

    Tentei implementá-lo em clientes com usuários iniciantes (a grande maioria dos usuários) e não obtive sucesso não pelo DSPAM, mas exatamente por esse fato da necessidade de ensinar o sistema. Os usuários tinham a impressão de que o sistema não estava funcionando porque eles é que estavam ensinando a ele o que é e o que não é spam manualmente, mesmo eu explicando que isso seria um passo trabalhoso inicial, mas que compensaria em longo prazo.

    Nesse cliente, acabei usando SpamAssassin com amavisd-new mesmo, que exigiu mais do servidor, mas que atendeu a necessidade desse cliente sem que fosse necessário existir a funcionalidade de aprendizado, algo que foi solicitado inicialmente pelo cliente, mas ao que o mesmo não se acostumou na prática.

    Eu, pessoalmente, uso e me dou bem com o esquema de aprendizado, mas tenho que me atentar a sempre ensinar ao sistema o que é e o que não é spam através da movimentação das mensagens para as pastas IMAP corretas, dependendo do caso. É fácil notar que se eu simplesmente apagar as mensagens e não alimentar o sistema com as mesmas, em pouco tempo o sistema começa a apresentar uma taxa de acertos mais baixa.

    Sobre a documentação, eu tenho documentação de boa parte do processo escrita, mas é de uso interno da empresa onde trabalho prestando suporte e administração de servidores de clientes e, como foi documentação criada em meu tempo de trabalho, não posso liberar para uso público, infelizmente.

    Eu comecei a escrever sobre Postfix há muitos anos atrás, mas só escrevi algo bem básico e inicial e nunca tive tempo de finalizar com tópicos mais avançados e atuais.

    Se quiser verificar, dê uma lida no conteúdo, já bem antigo e talvez não mais aplicável a realidade dos dias atuais aqui.

    Por último, obrigado pelo comentário e continue comentando. O retorno dos leitores é o que me move 🙂

    Respondendo ao Antonio :

    Obrigado pelo comentário, antes de mais nada. Eu cheguei a usar o OpenWebmail há algum tempo atrás, mas migrei todos os meus clientes para outras soluções de Webmail quando o Debian para de fornecer pacotes do OpenWebmail devido a ter encontrado diversas falhas de segurança no código do OpenWebmail e ninguém estar disposto a corrigí-los.

    Também uso (e bastante) procmail em meu servidor pessoal, mas uso DSPAM nele e SpamAssassin em servidores de clientes, o qual integra ao Postfix através do amavisd-new. Muito bom.

    Acredito que seja bastante tranquilo integrar o postgrey ao seu ambiente e o resultado, com certeza, será bastante satisfatório.

    Por favor, continue comentando sempre que possível. Dependo dos comentários para saber se não estou escrevendo besteiras 🙂

  8. Parabéns pelas ótimas dicas, mas estou com problemas na liberação da porta 60000 que faz a ligação com postgrey, utilizo o iptables no Debian
    Obrigado, Geraldo

  9. Ótimo post, além de rir muito pela forma que foi escrito o artigo é muito bom. Também tenho meu próprio servidor de email, 2 na verdade com mais de 70 domínios, uso postfix + clamav + spamassassin + amavis, posso implementar o postgrey mesmo usando o amavis que ja utiliza uma chamada de socket no postfix?

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s