Postfix e Dovecot dominados, hora de avançar com os outros dois serviços que compõem o nosso servidor de email.

O DKIM provê um serviço para assinar mensagens de modo a prover uma garantia de autenticidade da origem. Precisamos disso para não sermos tratados como spammers. Não somos spammers, certo?

O SpamAssassin é o nosso guerreiro antispam. A vida dele é abrir todas as mensagens que recebemos e determinar se ela é spam ou não. É uma vida dura e ele começa burro, mas ao longo do tempo ele vai aprendendo porque dispõe de inteligência artificial que podemos ensinar. Rá! Você não esperava por isso, né? Nosso servidorzinho é esperto! ;)

Vamos finalizar essa monte de explicação das coisas com esses dois. Depois disso a série volta a ficar interessante.

DKIMproxy

O DKIMproxy é um serviço que faz um negócio muito complicado de um jeito que, felizmente para nós, é simples. A melhor forma de entender o que ele faz é ler essa introdução do nic.br.

Aqui vamos entender como DKIMproxy é configurado para assinar as mensagens que nós e nossos usuários enviarão para o mundo através do nosso servidor. Lembre-se que não usamos o DKIMproxy para verificar as assinaturas de mensagens que recebemos, uma vez que o SpamAssassin já faz isso. Duplicar essa função é desperdício de recursos computacionais escassos.

A configuração que nos interessa do DKIMproxy está em apenas um arquivo, /etc/dkimproxy/dkimproxy_out.conf.

# specify what address/port DKIMproxy should listen on
listen    127.0.0.1:10027

# specify what address/port DKIMproxy forwards mail to
relay     127.0.0.1:10028

# specify signature rules file
sender_map /etc/dkimproxy/sender_map

# specify action on error
reject_error 1

Para entendê-lo, precisamos recapitular dois pedacinhos do master.cf. Primeiro o submission e depois a parte do spam do Postfix. Vai lá que eu espero.

Você deve ter visto que o serviço submission do Postfix usa um filtro de conteúdo. Esse filtro aponta exatamente para dksign:[127.0.0.1]:10027. Agora veja onde o DKIMproxy está ouvindo: 127.0.0.1:10027.

Mais abaixo no master.cf é definido o serviço dksign. Esse serviço do Postfix pega o DKIMproxy ouvindo na porta 10027 do endereço 127.0.0.1, nosso localhost, e o conecta a um arquivo de socket, especificamente o /var/spool/postfix/private/dksign=. Pronto, o Postfix tem tudo que precisa para enviar uma mensagem que queremos mandar para ser assinada pelo DKIMproxy.

Agora o caminho de volta, que é mais fácil. Veja que o DKIMproxy faz a devolução da mensagem para a porta 10028 do localhost (relay 127.0.0.1:10028). Agora veja no master.cf que existe um serviço que usa o smtpd que ouve exatamente na porta 10028 do localhost. É assim que o Postix recebe de volta a mensagem assinada pelo DKIMproxy.

A configuração sender_map aponta para o arquivo que faz o mapeamento dos domínios e os seus respectivos parâmetros para assinatura de mensagem. Esse é o arquivo que aponta que o domínio exemplo.com terá suas mensagens assinadas com a chave privada /etc/dkimproxy/exemplo.com_dkim_private.key. Essa chave foi a que geramos na configuração dos serviços.

A parte pública da chave usada pelos servidores externos para verificar se nossas mensagens são de fato nossas ficam no DNS. Veremos como é isso quando formos configurá-lo, o que será a última coisa que faremos nesta série. Isso expõe de modo definitivo o nosso servidor à internet. Precisamos de mais preparação antes 'virar' o DNS.

A configuração do DKIMproxy é arrematada com o tratamento que daremos aos erros, com reject_error 1. Isto diz ao DKIMproxy que se ele encontrar um erro ao tentar assinar uma mensagem, ele retornará uma rejeição temporária para o smtpd e o Postfix vai tentar mais tarde assinar a mensagem novamente. Não haverá envio sem assinatura. Se reject_error for igual a 0 ou não estiver presente, caso o DKIMproxy falhe ao tentar assinar uma mensagem, ela será enviada assim mesmo, sem assinatura.

De DKIMproxy é só isso. Bem simples.

SpamAssassin

É chegada a hora de entender o último componente do nosso servidor de emails. Ele é o nosso empalador de spammers filhos da puta.

Apesar dele ser muito importante para nossas vidas diárias, não vou perder muito tempo explicando todas as suas configurações como fiz com os demais componentes. A maioria delas referem-se apenas a habilitar plugins que, uma vez habilitados, simplesmente funcionam. É claro que isso só ocorre porque instalamos os componentes necessários antes.

Então, vamos direto aos pontos importantes do SpamAssassin.

Todos os componentes que vimos até aqui funcionam com a arquitetura cliente/servidor. O SpamAssassin não é diferente. O arquivo que controla os parâmetros de inicialização de seu servidor, o spamd é o /etc/spamassassin.conf.

O que o spamd vai fazer na hora de analisar mensagens é configurado em outro ludar. Esses arquivos de configuração ficam em /etc/mail/spamassassin. Nesse diretório, a primeira mudança relativa ao modo que o SpamAssassin analisa mensagem está no arquivo /etc/mail/spamassassin/init.pre, onde habilitamos loadplugin Mail::SpamAssassin::Plugin::SPF. Esse plugin verifica o cabeçalho SPF das mensagens. Nós falaremos do SPF mais tarde, quando formos configurar o DNS.

Depois vem o arquivo /etc/mail/spamassassin/local.cf. Aqui são várias alterações.

Primeiro alteramos o prefixo que o SpamAssassin coloca no assunto das mensagens identificadas como spam para [***SPAM***]. Eu acho esse rótulo mais fácil de identificar no olho.

Depois dizemos quais as redes que consideramos confiáveis com o parâmetro trusted_networks 172.16.1. Qualquer mensagem enviada a partir de uma máquina dentro dessa rede vai passar direto pelo filtro de spam, uma vez que elas são consideradas seguras e não-spam.

Em seguida diminuímos a nota para que uma mensagem seja considerada spam, required_score 3.0. O padrão é 5, mas seremos mais rigorosos.

E então chegamos na inteligência artificial do SpamAssassin. Essa 'inteligência' é implementada pelo Teorema de Bayes, logo tudo que se refere a ela é configurado com parâmetros que remetem a esse nome. Esse recurso é habilitado por padrão no SpamAssassin.

A primeira coisa que modificamos em relação ao comportamento original do SpamAssassin em relação ao bayes é excluir de sua capacidade de aprendizado alguns cabeçalhos que podem gerar falsos positivos. Isso é feito com os múltiplos parâmetros bayes_ignore_header.

O filtro bayes é um processo muito caro em termos de processamento, uma vez que ele é baseado em estatísticas cujos cálculos são complexos. O que pudermos fazer para evitar usá-lo sem que mensagens de spam passem é bem vindo. Conseguimos isso com o plugin de curto-circuíto. Esse plugin interrompe os cálculos estatísticos ao menor sinal de confirmação de que uma mensagem é ou não spam. Ele é habilitado com loadplugin Mail::SpamAssassin::Plugin::Shortcircuit, que é a única mudança que fizemos no arquivo /etc/mail/spamassassin/v320.pre.

Todas as condições listadas dentro do bloco ifplugin Mail::SpamAssassin::Plugin::Shortcircuit [...] endif do local.pre provocarão a saída prematura das análises estatísticas que poderiam ser feitas, o que economiza os ciclos de processamento já escassos em nosso diminuto servidor.

Em seguida informamos ao spamd que o banco de dados do bayes é global e definimos suas permissões. Por padrão, o SpamAssassin gera um banco de dados por usuário. Mas como a administração do nosso servidor é centralizada, queremos que o aprendizado do bayes seja comum a todos. As opções para isso são bayes_path e bayes_file_mode.

Por fim, definimos os parâmetros de operação dos filtros auxiliares utilizados pelo SpamAssassin, o Razor e o Pyzor. Esses dois são filtros colaborativos para spam e são bastante úteis ao nosso propósito.

E é isso com relação ao SpamAssassin. Depois teremos que ensinar essa inteligência artificial dele para que ela produza resultados práticos. Mas como isso é assunto relativo ao carinho que teremos que dar ao nosso servidor de emails depois que ele entrar em produção, falaremos disso em outro momento.

Isso encerra essa chatice de explicações. Você deve estar cansado de ler, e eu de escrever. Mas vejamos o lado bom: aprendemos um montão sobre um serviço de email seguro e eficiente, e também sobre os diversos componentes desse serviço. Aprender é sempre uma coisa boa. Eu acho!