FISL 11: Postfix Passado Presente Futuro


A palestra Postfix - Past, Present and Future, do Wietse Venama, foi a melhor do FISL na minha opinião. O criador do Postfix e funcionário da IBM destrinchou a arquitetura do software, explicou porque tomou algumas decisões ao longo do seu desenvolvimento, como a incorporação no "núcleo" do produto somente de recursos que já estivessem sedimentados no mercado e estáveis (SMTP, TLS, etc), deixando para os plugins lidarem com coisas que ainda não estivessem maduras o suficiente ou sofressem mudanças frequentes (SPF, Antivírus, Antispam, etc).


Novas funcionalidades implicam novos programas, garantindo assim a interferência mínima no código, e com a idéia de plugins, o software fica ainda mais seguro e estável. Uma arquitetura muito inteligente, sem dúvida, pois limita os efeitos de erros no código a programas específicos, não afetando (em princípio) outros módulos.


A figura acima ilustra esta arquitetura, onde somente os processos em vermelho são executados no contexto do root, pois são os processos responsáveis pelo armazenamento das mensagens e outras atividades que só podem ser executadas pelo root. A entrega e recebimento de mensagens SMTP, por exemplo, é feita por processos que não são executados no contexto do root.


Uma coisa que achei muito legal foi o fato de que o Wietse foi premiado várias vezes, uma delas por melhorias num componente do sendmail que ele integrou ao Postfix, uma clara demonstração dos resultados que se pode alcançar com as liberdades do software livre. Ou seja, ele fez algo diferente do que já existia, mas aproveitou (e melhorou) algo que já existia e que ele considerou que tinha qualidade.


Outro ponto que vale destacar na palestra foi o impacto para o desenvolvimento do Postfix do vírus Melissa, em 1999, que exigiu mudança no Postfix, já que o meio de transmissão do vírus era o SMTP, embora somente o Windows fosse vulnerável. Curioso, não ?


Confesso que me senti fazendo parte da história, assistindo ao criador discorrer sobre sua criatura (filosofei pesado agora, hein ?). O fato é que o Postfix é um dos melhores softwares livres que já existiu, e ver a palestra do Wietse foi especial pra mim, pois ajudou a entender melhor como é possível transformar uma boa idéia num produto de muita qualidade. E é importante salientar também o papel da IBM, que manteve o Wietse durante muito tempo dedicado exclusivamente ao desenvolvimendo do Postfix. É deste tipo de apoio que o software livre precisa!


Outros pontos que vale a pena destacar sobre a palestra:


  • Comparativamente, o QMail tem muito menos linhas de código (aparentemente), pelo fato de que muitas de suas funcionalidades dependem de patches. Por isso é difícil dizer se o QMail seria ou não mais seguro pelo fato de ter menos código. Sendmail e Postfix têm quantidades semelhantes de linha de código, o que diferencia é a arquitetura.
  • O Postix teve 3 bugs identificados em 2004 (se não me engano), enquanto o PHP teve 200, embora o PHP tenha aproximadamente o dobro de linhas de código do Postfix. É um sinal inegável de qualidade do produto.
  • "Paradoxo: software bugado funciona!". Esta foi uma afirmação curiosa do Wietse, pontuando que apenas parte do código de uma aplicação é realmente testada pra valer, pois se refere às funcionalidades mais utilizadas, e o código "periférico" acaba sendo o alvo preferido de intrusos, já que este código não seria tão confiável, pois se refere a funcionalidades menos utilizadas. Interessante, não ?
  • O desenvolvimento do Postfix sofreu influência de vários outros softwares, utilizados como modelo de arquitetura a ser seguida (ou não): Sendmail, QMail, TIS Firewall Toolkit e Apache.
  • A utilização de buffers de tamanho fixo e smart buffers foi uma tentativa de minimizar os problemas com buffer overflow.
  • A arquitetura de filtragem de mensagens foi modificada algumas vezes, uma delas para atender à legislação de países da Europa onde uma mensagem recebida (SMTP) não pode ser descartada, o que obrigava o Postfix a realizar todas as verificações na mensagem antes de aceitá-la do ponto de vista do SMTP, caso contrário o SPAM teria que ser entregue na caixa do usuário.
  • Wietse destacou a proliferação de tecnologias de autenticação (SPF, SenderID, DomainKeys, DKIM, SRS, ADSP e outras) foi algo que motivou o suporte a plugins.
  • Foi exibido um gráfico do Google Trends para demonstrar o (des)interesse das pessoas por software de correio eletrônico, ilustrado com as seguintes afirmações, em tradução livre:
    • "Lições de soberba:
      • Uma minoria dos usuários está interessada em servidores de correio
      • Esta minoria está diminuindo firmemente."
  • Foram destacados os desenvolvimentos mais recentes no produto, como o "workaround" para sobrecarga temporária, verificação de IP de remetente e suporte a múltiplas instâncias.
  • Foi exibido um gráfico mostrando que 90% das mensagens é SPAM, e 84% do SPAM é enviado por botnets.
  • Como identificar se o postfix está sobrecarregado por SPAM: atraso na entrega de mensagens, registro de perdas de conexão e avisos "all servers ports busy".
  • Desobedecer a RFC foi a solução encontrada para evitar a sobrecarga, já que o timeout padrão de 5 minutos fazia com que o servidor "perdesse tempo" esperando por confirmações que não viriam, e a solução foi (simplificando) embutir um código na mensagem SMTP e verificar este código depois. Como as botnets não verificam as respostas do SMTP, as mensagens chegam sem o código e parte do SPAM é evitado.
  • Mas a novidade mais interessante mesmo é o Postscreen, que implementa alguns filtros interessantes e um esquema inteligente de "pre-greeting", ou seja, uma técnica que envia o EHLO com múltiplas linhas, fazendo com que muitos bots respondam antes da hora tentando enviar o SPAM, o que permite identificá-los. Claro que é uma questão de tempo até as botnets ficarem mais inteligentes, mas por enquanto vai resolver parte do problema. E há ainda a perspectiva de desenvolver controles para bloquear requisições de acordo com o horário e localização geográfica, que tal ?
Ufa! Esta palestra foi realmente muito, muito legal, do jeito que eu gosto, sem muito blá blá blá e com muita informação técnica, como vocês puderam ver. Espero que as informações tenham sido úteis, e continuem acompanhando a série de posts sobre FISL 11.

Christian Guerreiro

Professor por vocação, blogueiro e servidor público por opção, amante da tecnologia e viciado em informação.


Ensino a distância em Tecnologia da Informação: Virtualização com VMware, Big Data com Hadoop, Certificação ITIL 2011 Foundations e muito mais.


Suporte o Tecnologia que Interessa!

Você acha que as informações compartilhadas aqui são úteis?
Então me ajude a produzir ainda mais e melhores conteúdos!


É muito fácil. Basta divulgar nossos treinamentos pra alguém que conheça!


E se for de Salvador, podemos estruturar um curso presencial para sua empresa!

Eu vou ficar muito grato (e quem fizer os curso também :)!