Prized Season software

Detesto blogs, mas às vezes dá-me jeito ser narciso, e escrever o que vou fazendo ao longo do tempo. Podem crer que arruma as ideias; isto de a gente escrever para a blogosfera, sem preconceitos, e falar livremente do que vai fazendo, embora fútil, dá-nos a noção de contribuirmos para o bem comum... e afectarmos um bocadinho o ambiente. Sim, porque isto de escrever uns quantos parágrafos é engraçado, mas ocupa espaço em disco, e os discos não são 100% renováveis. Mas para o que eu escrevo, vale bem o esforço. Não gosto de falsas modéstias, assim é que é!

Dizia eu no título, um aperitivo para o que é o anti-spam cooperativo, em português: para quem se der ao trabalho de ler isto, basicamente significa que várias máquinas amigas, de amigos, ou melhor, de pessoas de confiança, geridas por gajos competentes, podem ser uma mais valia em nos reportar anomalias de ratos. Ratos é o vulgo termo rat, que significa quem propaga o spam.
Traduzindo, spam, é lixo que vos chega à caixa de correio electrónico, ou no sentido mais lato, que vos chega à vossa caixa de correio. Fazer anti-spam cooperativo, mal comparado, é vocês terem uma rede no vosso correio: quando o carteiro lá chega, tem que perguntar a alguém se pode deixar lá os folhetos do Continente. Mas pergunta a quem? Aí está o truque: imaginem lá.
Ao vosso gestor de conta? Não. Ao vosso pai? Não. É mais ou menos à porteira do prédio ao lado, que é uma senhora decente, curiosa, e que espiolha tudo o que lhe passa nas mãos. É mesmo a alcoviteira lá do vosso sítio, está a par de tudo e é muito criteriosa na seleção do lixo, ou melhor, do correio que vos pode chegar. Se for lixo, então o bijagós (http://pt.wikipedia.org/...bijagós) que queria lá despejar a propaganda recebe um 5NN (desculpem lá a linguagem, mas é que estou um bocado viciado no SMTP - códigos de retorno entre 500 e 599 são rejeições mandatórias, por exemplo "permanently rejected messages") no caso de se ligar ao Spamassassin durante a transação de "DATA" (o conteúdo do email propriamente dito), ou no caso que eu acho, pessoalmente, mais interessante, 451 (temporary failure, please retry).

Seguindo o nosso exemplo, a vossa caixa de correio é o MTA que está a gerir os vossos mails, o bijagós é o rato, e a porteira é o servidor de pecados. A cooperação entre a vossa máquina que corre o MTA e o "servidor de pecados" estabelece-se usando blowfish-streaming (para encriptar a comunicação de forma segura - desculpem o incómodo, mas não posso revelar estea variante de encriptação do blowfish, porque quero tornar este método num RFC); o servidor geralmente corre algo que elimina 90% a 95% do spam, o melhor exemplo que conheço actualmente é o Greylistd (http://en.wikipedia.org/...Greylist), e o vosso MTA limita-se a papaguear os triplets que recebeu para o servidor de pecados. Embora o nome pareça religioso, o algoritmo usado pelo dito servidor não tem nada de transcendente: no caso linear de se usar Greylist no servidor ele actua como o master de todos os triplets, conectando-se ao socket do greylistd directamente. Há outras formas mais poderosas, e ainda mais simples, de como o master pode actuar - mas estas formas não podem ser tornadas públicas para já.

Na realidade o vosso MTA (a correr em modo gsinlistd proxy) pode ser moderadamente estúpido: se for o Exim, por exemplo, terá apenas umas linhas de configuração do género apresentado em baixo, na secção acl_check_rcpt.


Pode parecer complicado, mas se conhecerem o Exim isto é canja: antes de aceitar o destinatário, escrever no Unix (Stream) socket e ficar à espera, durante um máximo de 3 minutos, pela resposta. Na realidade quem está à escuta (ou mais precisamente, quem faz o bind do socket) é o gsinlistd, que re-envia o pedido encriptado para o servidor de pecados, na nossa analogia, a ciosa porteira.

Qual a vantagem de centralizar os pedidos de vários MTAs numa porteira, é uma pergunta interessante. Para o mesmo triplet ({ip, from, to}) a resposta não depende de qual o MTA que serve o pedido, conquanto os MTAs sejam MX-backups uns dos outros.

Um exemplo mais elucidativo: o mail do Google tem vários servidores MX. Vejam o comando seguinte:

% dig mx google.pt | grep MX
google.pt. 1777 IN MX 10 smtp1.google.com.
google.pt. 1777 IN MX 20 smtp2.google.com.
google.pt. 1777 IN MX 30 smtp3.google.com.

Estes 3 MXes certamente actuam contra spam independentemente. O modus-operandi dos ratos medianamente inteligentes presta-se a tentar em cada um destes rapidamente. Se o primeiro MX for a porteira, e os dois seguintes duas caixas de correio adicionais, usando-se o greylist como veículo para a cooperação, o rato bate na trave três vezes seguidas. A porteira (neste caso o smtp1.google.com) passa a ter 3 hits, quantos mais hits tiver, mais tempo demorará a mensagem a ser aceite. O princípio do greylist é precisamente o de recomeçar o tempo dos 60 minutos a partir de todos os hits inferiores a um periodo de 60 minutos.
Para abrilhantar o mecanismo, as respostas das transações com o servidor de pecados abrandam quanto maior for o número de hits, mantendo como dogma cerca de 160 segundos como máximo tempo de resposta (para haver congruência do protocolo SMTP, conforme recomendações dos RFCs.)

Quando dantes eu tinha uma média de 30 mails de spam no meu servidor dedicado, agora tenho zero, e acreditem ou não, nem sequer uso esquemas de detecção de spam através do conteúdo (como é o caso do Spamassassin).

Claro que tenho que ser intelectualmente honesto e referir que há servidores legítimos erroneamente configurados, mas isso é um tema da discussão das white-lists no âmbito do Greylist, não o anti-spam cooperativo em si.

Para não pensarem que isto é conversa fiada, apresento-lhes uma imagem, essa sim, definitivamente, como aperitivo... para o produto que não posso ainda divulgar completamente.