DANE – Autenticação Baseada em DNS para Nomes de Entidades

Hoje tive minha primeira ocorrência de mensagem não recebida por erro de DANE: uma conta de um domínio hospedado no outlook.com da Miscrosoft nos enviou várias mensagens que nunca chegavam. Sem recebimento do meu lado e sem mensagem de erro do lado deles, as mensagens simplesmente sumiam.

DANE – DNS-based Authentication of Named Entities é um nome longo, mas o conceito é simples: como garantir que o certificado usado para a conexão TLS com seu servidor é, de fato, o certificado correto?

Seguindo a mesma lógica do SPF e DKIM, onde um registro DNS avaliza a autenticidade ou origem do e-mail, o DANE se utiliza desse registro publicado para validar a autinticidade do certificado utilizado na coxão SMTP.

A diferença é que a validação do DANE é utilizada durante o envio da mensagem, ou seja, o servidor de envio, ao conectar no seu servidor avalia se existe um registro DNS do tipo TLSA e se não tiver, ou se for inválido, ele simplesmente não faz estabelece a conexão, e portanto, não há envio.

O sinistro é que ao não estabelecer a conexão, o destino não tem logs do contato e não tem como saber o que está acontecendo. E a origem também fica às cegas, pois na maioria dos casos o erro não é retornado para o emissor.

Sem logs de ambos os lados e com o servidor do emissor sem acusar erros paira a dúvida sobre onde esta o problema e como resolver.

Diagnóstico

Como não tínhamos logs do nosso lado, solicitamos ao domínio hospedado no outlook.com que aciona-se o suporte e pedisse pelos logs de erros de envio. Bingo!

Server at RO1P152MB3787.LAMP152.PROD.OUTLOOK.COM returned ‘550 5.7.323 tlsa-invalid: The domain failed DANE validation(450 4.7.323 tlsa-invalid: The domain failed DANE validation)’
Server at dominio.com.br(111.111.11.11) returned ‘450 4.7.323 tlsa-invalid: The domain failed DANE validation [Message=450 4.7.323 tlsa-invalid: The domain failed DANE validation] [LastAttemptedServerName=dominio.com.br] [LastAttemptedIP=111.111.11.11:25] [BN8NAM12FT054.eop-nam12.prod.protection.outlook.com](450 4.7.323 tlsa-invalid: The domain failed DANE validation)’

Veja as parte em negrito onde o diagnóstico dexa clara a falha na validação DANE.

Como resolver?

O problema se resolve com uma simples entrada TLSA no DNS. Mas esse registro é extraído do seu certificado, portanto, sempre que seu certificado for renovado, esse registro DNS tem que ser gerado de novo e publicado de novo.

Sugerimos publicar dois registros TLSA: um para o dominio puro e outro para o hostname do MX.

Abaixo esta o comando para extrair o registro DAME para o certificado gerado usando Lets Encrypt, supondo que o primeiro domínio de sua lista seja webmail.dominio.com.br e seu MX seja mail.dominio.com.br

printf '_25._tcp.%s. IN TLSA 3 1 1 %s\n' mail.dominio.com.br $(openssl x509 -in /etc/letsencrypt/live/webmail.dominio.com.br/cert.pem -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256 -binary | hexdump -ve '/1 "%02x"')

printf '_25._tcp.%s. IN TLSA 3 1 1 %s\n' dominio.com.br $(openssl x509 -in /etc/letsencrypt/live/webmail.dominio.com.br/cert.pem -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256 -binary | hexdump -ve '/1 "%02x"')

Você deverá opter resultados parecidos com estes:

_25._tcp.mail.dominio.com.br. IN TLSA 3 1 1 6713df4659ea22c26d27fe539bffeecc3ece4500e6e992feff2a208af2d9607b

_25._tcp.dominio.com.br. IN TLSA 3 1 1 6713df4659ea22c26d27fe539bffeecc3ece4500e6e992feff2a208af2d9607b

Publique os dois no seu DNS

Validando as configurações

Depois de publicar no DNS é importante testar se esta tudo correto.

Primeiro uso o dig para ter certeza de que a publicação do novo registro TLSA foi feita com os comandos abaixo:

dig _25._tcp.dominio.com.br TLSA

dig _25._tcp.mail.dominio.com.br TLSA

Em seguida use o link abaixo para testar

DANE/TLSA validator for inbound SMTP services

Observações importantes

Ao que tudo parece a exigência do DAME é seletiva. Temos vários servidores e domínios sem DAME que funcionam muito bem recebendo mensagens do hotmail.com e de todos os outros provedores.

Suspeito que o DAME esta sendo exigidi dos dompinios que já tem DNSSEC, incluíndo, portanto todos os órgãos públicos e aqueles domínios comerciais e pessoais que já tenham o DNSSEC ativado.

Acredito que é apenas uma questão de tempo até que o DNSSEC e o DAME façam parte da lista de registros DNS obrigatórios para se ter um servidor de e-mail compatível com os grandes provedores.

Links importantes

Recomendo demais a leitura dos materiais abaixo para ter uma clareza maior sobre o que é o DAME e como ele funciona.

What is DANE – da Infoblox

Como funciona a autenticação baseada em DNS SMTP de entidades nomeadas (DANE) – da Microsoft

Zimbra – Caixas Postais grandes… mas grandes quanto?

20 Gb, apenas 20Gb e nada mais que 20Gb.

Se você ficou surpreso com a resposta seca e direta, então é hora de ler o artigo. Vou tentar explicar como cheguei a esse “número mágico”.

Toda mensagem é importante e desde que os grandes players do mercado criaram as “caixas infinitas” há a percepção de que ela é ilimitada e que não é mais necessário se preocupar com o seu tamanho, mas essa premissa não é correta.

Os sistemas de gerenciamento dos grandes players subdivide a “caixa infinita” em caixas menores para garantir sua integridade e isso é feito de maneira imperceptível para o usuário. Pelo menos esse é o meu palpite porque não temos acessos detalhados às tecnologias que eles utilizam.

O fato é que caixas postais grandes degradam o sistema e deixam o ambiente lento e propenso a falhas graves. O armazenamento de mensagens é feito utilizando índices de posicionamento e bases de dados que se tornam mais propensos a falhas à medida que crescem. Assim, quanto maior uma caixa postal maior o risco de corrupção das tabelas de índices e, portanto, de haver perda de dados.

É importante entender que perder os índices implica, na maioria dos casos, perder a caixa postal completa e não apenas algumas mensagens. Assim começa a ficar claro o tamanho do risco envolvido.

Quando as mensagens são armazenadas localmente em clientes de e-mail são utilizados arquivos PST e similares que são, na verdade, bancos de dados locais. Gerenciar arquivos de dados com 30, 40, 100Gb de tamanho exige muito do computador.

Quando as mensagens são armazenadas no servidor e acessadas via IMAP ou webmail elas são organizadas utilizando tecnologias próprias e que diferem entre os Softwares de servidores de e-mail disponíveis no mercado.

O Zimbra utiliza uma base de dados MySQL para manter o caminho de armazenamento do arquivo da mensagem no disco. Além disso é armazenada na base MySQL o assunto e a parte inicial da mensagem. O objetivo é utilizar essas informações para “montar” a tela inicial do usuário sem precisar ler as mensagens diretamente do disco. O acesso à base de dados é centenas de vezes mais rápido do que o acesso ao disco, evitando assim, sobrecarga de I/O no disco e tornando o ambiente todo mais rápido e eficiente.

Sempre que a caixa postal é acessada às mensagens da INBOX são indexadas e apresentadas ao cliente, significando, no caso do Zimbra, uma consulta na base de dados MySQL. Quanto mais mensagens na INBOX mais carga sobre o servidor e mais lentidão. Dica de ouro: estimule seus usuários a manter uma caixa de entrada minimalista.

Em uma matéria publicada em 2005 no blog Techno Community da Microsoft eles falam sobre o tamanho recomendado de uma caixa de e-mail. Depois de várias explicações eles sugerem que as caixas não devem ter mais de 5000 mensagens para poder garantir sua integridade geral. É curioso que eles foquem na quantidade de mensagens e não no tamanho da caixa como um todo, mas faz sentido: o que importa mesmo é a quantidade de itens nos índices e isso não tem haver com o tamanho das mensagens.

Segue o link para quem quiser ler o tal artigo: Recommended Mailbox Size Limits

Apesar do artigo ser de 2005 os seus princípios não mudaram: quanto mais mensagens, maiores os índices e portanto mais carga no servidor ao entregar as mensagens aos clientes. Se por um lado os computadores e discos melhoraram de desempenho, por outro lado o aumento no uso do IMAP e de usuários de Webmail forçam o sistema. Por isso as premissas do artigo da Microsoft são válidas até hoje.

É muito importante configurar o Zimbra para o “index” dos volumes em um disco de alto desempenho. Mas cuidar do tamanho das caixas postais é essencial, assim como educar os usuários a manter suas pastas INBOX com poucas mensagens.

Tendo em mente essa quantidade máxima de 5000 mensagens podemos dizer com segurança que uma caixa postal de 20Gb de tamanho armazenará muito mais do que isso, permitindo assim uma folga na quantidade de mensagens que um usuário pode manter sem correr maiores riscos. O ajuste de quantidade para tamanho se baseia na facilidade de entendimento do usuário e de controle por parte dos administradores do serviço de e-mail.

Apesar da orientação e das boas práticas, muitas vezes nos deparamos com situações onde a quantidade de mensagens que precisam ser armazenadas é uma condição obrigatória. Caixas postais corporativas que são compartilhadas por muitos usuários, como “vendas”, “financeiro” ou “contato”, caixas postais de tribunais e juízes ou de departamentos jurídicos das organizações, são bons exemplos.

Essas caixas costumam armazenar muito conteúdo por prazos de tempo muito longos para permitir que acordos legais e/ou comerciais possam ser resgatados ao longo do tempo quando necessário.

Entende-se o motivo pelo qual essa caixas postais terminam sendo usadas como arquivo de mensagens antigas ao mesmo tempo que continuam em produção, sendo utilizadas cotidianamente. Mas essa é a receita para um desastre anunciado: haverá corrupção de dados e perdas que poderão ser irrecuperáveis. Como diz o ditado, não é “se”, mas “quando” isso vai acontecer.

Há outros três momentos críticos em que as caixas postais grandes costumam sofrer perdas irreparáveis: queda súbita de energia, restauração de backup e migrações.

Quando acontece uma interrupção súbita de energia todos os índices que estava em memória são perdidos e precisam ser gerados do zero quando o sistema é inicializado. As caixas postais grandes tem índices maiores e portanto mais propensas a corrupção permanente, o que significa que não será mais possível ler a caixa postal. É possível fazer uma recuperação forense das mensagens mas trata-se de um processo altamente especializado, demorado, caro e com resultados imperfeitos.

O processo de restauração de backup é similar ao processo de migração: faz-se o “dump” das caixas postais para restauração local no caso do backup, ou para restauração no novo servidor no caso da migração. O “dump” resulta em um arquivo compactado que tem todo conteúdo da caixa, como mensagens, contatos, compromissos… e quanto maior a caixa, maior é o arquivo resultante. Em geral não há problemas para fazer o backup ou “dump”, mas sim no momento de restaurá-lo.

Importar um arquivo de 5, 10 ou 20Gb é um procedimento corriqueiro, mas fazer o mesmo com um arquivo de 80 ou 100Gb tem implicações graves sobre o desempenho do servidor, impacto sobre a base de dados e tempo de escrita em disco. Na prática o que acontece é a leitura e descompactação desse arquivo pelo Zimbra que depois vai importar cada registro, mensagem, compromisso via SOAP. Quanto maior a caixa postal, maior o risco do processo ser abortado durante a importação por erros de leitura, timeout e/ou esgotamento de memória. O resultado é uma restauração parcial apenas da parte que se conseguiu ler antes do erro.

O hardware envolvido, a carga geral do sistema, o tamanho da caixa e o desempenho do disco contarão como variáveis que poderão influenciar no sucesso ou não da importação de caixas postais grandes, seja para restauração de backup, seja para migrações.

Sabendo de tudo isso qual é a forma sugerida de se lidar com caixas postais grandes? Dividi-las em caixas de até 20Gb compartilhando-as com a caixa principal através do recurso de compartilhamento de caixas postais do Zimbra. Uma ideia é criar caixas postais auxiliares com nomes contendo anos, assim:

juridico@organizacao.org.br = 20Gb
juridico_2018@organizacao.org.br = 20Gb
juridico_2019@organizacao.org.br = 20Gb
juridico_2020@organizacao.org.br = 20Gb
juridico_2021@organizacao.org.br = 20Gb

As contas com “_ANO” são compartilhadas com a conta principal, ficando disponíveis de forma fácil pois aparecem no cliente de e-mail como uma pasta extra. Fica evidente que a ideia é separar as mensagens por ano de envio.

Dessa forma o conteúdo fica disponível, porém armazenado em caixas postais menores de fácil mobilidade, reindexação e restauração em caso de necessidade.

Existe um zimlet administrativo feito pelo Barry de Graaf que implementa o compartilhamento de caixas via interface administrativa: Zimbra Shared Mailbox Toolkit

Esperamos que este conteúdo ajude administradores de servidores de e-mail e usuários a chegarem a um consenso no uso racional dos recursos computacionais, para melhorar o desempenho geral do ambiente, garantir integridade e portanto evitar perdas de dados importantes.

Quem sabe em um futuro o limite seguro do tamanho de caixas aumenta. Ainda me lembro da época em que a recomendação era de no máximo 10Mb… sim Megas =)

Saudações Livres!

Z-Push no Zimbra: o jeito mais fácil!

A implementação do protocolo Exchange/ActiveSync feito pelo pessoal do Zarafa é sensacional! o Z-Push é desenvolvido em php e funciona super bem mas integrar ele no Zimbra sempre foi trabalhoso, especialmente depois que eles não disponibilizaram mais o tgz e a instalação passou a ser feita via repositórios de forma obrigatória.

Se você dispuser de um segundo servidor então a instalação é simples, mas nem todos tem um segundo servidor disponível para isso, então resta integrar com o Zimbra no mesmo servidor e isso pode ser um desafio: adicionar repositórios, alterar configurações, instalar o php-fpm local e colocar tudo junto para rodar como usuário Zimbra.

Funciona bem, mas é um procedimento tão cheio de passos que eu nunca me animei para escrever um tutorial.

Felizmente, estes dias no nosso grupo Zimbrasil no Telegram alguém postou um link para um container do z-push em Docker. Isso facilita demais o procedimento todo e me animou a escrever este tutorial.

Considerações

a) Esse container Docker usa uma versão mais antiga do Z-Push;

b) Por ser um container, ela é monolítica, ou seja tem uma certa quantidade fixa de instâncias do Apache para aguentar as requisições. Pode ser que essa quantidade não seja suficiente para o seu cenário;

c) Pode ser que o Docker e o Z-Push no container consumam muitos dos recursos do seu servidor

Apesar dessas considerações, acho que vale a pena e deve atender a grande maioria dos casos.

Então vamos nessa!

Pré-requisito

O servidor TEM que aceitar instalar e rodar containers com Docker e talvez você esteja se perguntando se isso não é óbvio? Não é: muitos servidores Zimbra estão rodando em containers LXC, por exemplo. Rodar Docker dentro de LXC ou Openvz pode ser um desafio, então só prossiga depois de ter certeza de que o Docker roda.

Instalando o Docker

Para instalar o docker use o seu gerenciador de pacotes: apt ou yum

apt install docker.io

ou

yum install docker.io

Testando o Docker

docker run hello-world

Instalando o z-push em docker

Essa instalação exige a declaração de duas URL’s: a do Zimbra e a do Z-Push. Neste cenário será sempre a mesma URL que é nome principal do servidor.

docker run -d -p 9443:80 --restart=always -e ZIMBRA_URL=nome_do_servidor -e ZPUSH_URL=nome_do_servidor --name zpush darkjeff/zpush-zimbra

Alterando o Zimbra

O Z-Push vai rodar na porta 9443 e precisamos configurar o Zimbra para usar o z-push nessa porta. Isso é feito alterando o template do Nginx que o Zimbra usa como proxy.

É importante lembrar que essa alteração será sobrescrita na próxima atualização do Zimbra. Se esse for o caso, basta refazer os passos abaixo:

1 – Edite o template do Nginx do Zimbra

vim /opt/zimbra/conf/nginx/templates/nginx.conf.web.https.default.template

2 – Procure por “set $mailhostport” na seção do Microsoft-Server-ActiveSync, ao redor da linha 197 do arquivo e ajuste para ficar com a porta do z-push, assim:

set $mailhostport 9443;

3 – Localize, um pouco mais abaixo, por volta da linha 207 a opção “proxy_pass” e altere para ficar com o nome do seu servidor em http, assim:

proxy_pass          http://nome_do_servidor:9443;

4 – Finalmente reinicie o proxy

su - zimbra -c "zmproxyctl restart"

Testando a instalação

Acesse a URL do seu servidor com o path completo do protocolo, assim:

https://nome_do_servidor/Microsoft-Server-ActiveSync

E faça login com um usuário e senha válidos.

Saudações!

SPFBL local com Zimbra – Parte II – KyaFilter

Antes de começar a ler o artigo, que tal fazer parte de nosso grupo no Telegram @kyafilter ?

Na parte I vimos como instalar, configurar e integrar o SPFBL ao Zimbra. Neste artigo vamos levar a integração entre o SPFBL e o Zimbra muito mais adiante utilizando o KyaFilter, um programa criado para funcionar como “content filter” do postfix permitindo muita flexibilidade ao lidar com as mensagens e os comportamentos desejados.

A primeira integração é feita fazendo os botões “Spam” e “Não Spam” do webmail do Zimbra, interagirem com o SPFBL, dessa forma as ações dos usuários vai afinando o comportamento do anti-spam e tornando-o cada vez mais eficiente. Essa interação é feita de forma granular e individual, permitindo que o bloqueio de uma mensagem seja feito apenas para o usuário que desejar bloquear aquele remetente.

Outra ação é o “autowhite”, ou seja, todos os endereços de e-mail para os quais se envia mensagens são inseridos na whitelist do SPFBL minimizando os falsos positivos, afinal de contas, faz sentido querer receber a resposta dos endereços para os quais se enviam mensagens.

As mensagens que passarem pelo primeira checagem de envelope do SPFBL terão seu conteúdo analisado e, de acordo com a pontuação recebida a mesnagem será então marcada como Spam para ser entregue na pasta de Spam ou não.

Fluxo

A mensagem ao chegar no servidor é recebido pelo Postfix que faz uma checagem de envelope com o SPFBL, em seguida encaminha para o Amavis que faz as checagens no Clamav e no SpamAssassin. Com a instalação do KyaFilter, o Amavis entregará a mensagem para o KyaFilter que ao finalizar faz a entrega de volta ao Postfix. Desenhando:

Postfix –> SPFBL –> Amavis –> KyaFilter + SPFBL –> Postfix

Pré requisitos

O KyaFilter exige SPFBL V3 ou superior para funcionar como esperado, além do python 2.7 e ncat

Baixando o KyaFilter

Você pode fazer o download do KyaFilter aqui

Instalando

1 – Copie o arquivo kyafilter.tgz para o diretório /opt ou baixe diretamente com o comando abaixo:

wget https://www.anahuac.eu/kyafilter.tgz

2 – Descompacte o arquivo com o comando abaixo:

tar zxvf kyafilter.tgz

3 – Crio o diretório /opt/kyafilter e copie o conteúdo para ele

mkdir /opt/kyafilter
cp kyafilter /opt/ -Rf

4 – Entre no diretório criado e execute o instalador:

cd /opt/kyafilter
./install

O instalador solicita algumas informações:

Default installation dir [/opt/kyafilter]: 
* apenas pressione enter

Zimbra Spam Account:
* Essa conta será criada pelo instalador

Zimbra Ham Account:
*Essa conta será criada pelo instalador

SPFBL IP address:
* Se no SPFBL está tudo como 127.0.0.1, deixe assim mesmo.

SPFBL runs in a multi domain admins server? (N/y): 
* Se seu SPFBL tiver um usuário por domínio responda "y", se não apenas pressione enter

Messages too big will have only headers scanned? [yes]:
* Esta opção vai entregar apenas os cabeçalhos das mensagens grandes para o SPFBL.

How big a message nees to be to have only it's header scanned? [1048576] 1Mb in bytes:
* Qual é o tamanho da mensagem grande?

Ele cria as contas de HAM e SPAM para as quais o integrador do Zimbra vai envias as mensagens quando se usam os botões de Spam e Não Spam no webmail do Zimbra.

4 – Alterando o master.cf.in do Zimbra

Esse passo exige um pouco mais de cuidado, portanto atenção:

a) Edite /opt/zimbra/common/conf/master.cf.in

b) Adicione o trecho abaixo, no final do aquivo, respeitando a tabulação:

# Kya Filter
kyafilter unix -      -       n       -       10 smtp
        -o smtp_data_done_timeout=5800
        -o smtp_send_xforward_command=yes
        -o disable_dns_lookups=yes
        -o smtpd_sasl_auth_enable=no
        -o max_use=20
[127.0.0.1]:20024 inet n  -       n       -       -  smtpd
        -o content_filter=
        -o local_recipient_maps=
        -o virtual_mailbox_maps=
        -o virtual_alias_maps=
        -o relay_recipient_maps=
        -o smtpd_restriction_classes=
        -o smtpd_delay_reject=no
        -o smtpd_client_restrictions=permit_mynetworks,reject
        -o smtpd_data_restrictions=
        -o smtpd_end_of_data_restrictions=
        -o smtpd_helo_restrictions=
        -o smtpd_milters=
        -o smtpd_sender_restrictions=
        -o smtpd_reject_unlisted_sender=no
        -o smtpd_relay_restrictions=
        -o smtpd_recipient_restrictions=permit_mynetworks,reject
        -o smtpd_sasl_auth_enable=no
        -o mynetworks_style=host
        -o mynetworks=127.0.0.0/8,[::1]/128
        -o strict_rfc821_envelopes=yes
        -o smtpd_error_sleep_time=0
        -o smtpd_soft_error_limit=1001
        -o smtpd_hard_error_limit=1000
        -o smtpd_client_connection_count_limit=0
        -o smtpd_client_connection_rate_limit=0
        -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_address_mappings
        -o local_header_rewrite_clients=
        -o syslog_name=postfix/kyafilter

c) Ainda dentro de master.cf.in procure pela linha abaixo:

[%%zimbraLocalBindAddress%%]:10025 inet n  -       n       -       -  smtpd
        -o content_filter=

Altere para ficar assim:

[%%zimbraLocalBindAddress%%]:10025 inet n  -       n       -       -  smtpd
        -o content_filter=kyafilter:[127.0.0.1]:20025

5 – Reiniciando os serviços

Com o KyaFilter instalado e o Zimbra configurado, é hora de reiniciar os serviços.

Primeiro o KyaFilter, execute:

/etc/init.d/kyafilter restart
/etc/init.d/kyafilter status

Em seguida basta reiniciar o MTA do Zimbra, assim:

su - zimbra -c "/opt/zimbra/bin/zmmtactl restart"

6 – Acompanhe os logs:

Cada comando abaixo em um terminal diferente. Particularmente prefiro usar o screen para isso

tail -f /var/log/mail.log | grep kya
tail -f /var/log/kyafilter.log

E assim a integração entre Zimbra e SPFBL usando o KyaFilter está completa.

Atualizando o SPFBL + KyaFilter de qualquer versão anterior a 1 para a versão 1.0 ou posterior

Se você já tinha um SFPBL com KyaFilter instalado e esta atualizando então vai precisar tomar alguns cuidados extras, pois as atualizações foram tão grandes que exigem cuidados extras.

KyaFilter

A atualização do kyafilter é bem simples: apague o conteúdo de /opt/kyafilter e copie os novos aruqivos para lá. E em seguida ajuste o arquivo de configuração como dito abaixo:

Adicione estas duas novas opções no kyafilter.conf:

spfbl_port_aw = 9877

Se seu SPFBL delega domínios para usuários diferentes então a opção spfbl_port_aw deve ser definida para 9875.

Se seu SPFBL usa apenas um usuário para gerenciar todos os domínios, então basta deixar a opção spfbl_port_aw igual à opção spfbl_port, ou seja, 9877

spfbl_user = admin_do_spfbl

Nesta opção coloque o seu usuário admin do SPFBL.

Finalmente reinicie o KyaFilter

/etc/init.d/kyafilter restart

SPFBL

A atualização do SPFBL

SPFBL

Roteiro simplificado:

1) Exporte as listas de block e white

spfbl superwhite show all > whitelist.old
spfbl superblock show all > blocklist.old

2) Proceda com a atualização do SPFBL

A atualização do SPFBL é feita da mesma forma que uma instalação do zero, sobrescrevendo os arquivos descritos no tutorial de instalação do SPFBL. O único passo extra é criar o diretório “history”

3) Tratar as listas exportadas acima

A sintaxe das bases de white e block do SPFBL mudaram, portanto a sua base atual não servirá na nova versão do SPFBL.

Na versão atual a sintaxe é assim:

emaillocal@domlocal.foo>emailspam@domremote.bar

Na versão nova é exatamente invertido.

A outra mudança é que na versão nova do KyaFilter os registros no SPFBL são feitos usando explicitamente o usuário do SPFBL, aquele criado no momento da instalação do SPFBL e definido como admin.

Dessa forma a nova sintaxe é assim:

spfbladmin@domlocal.foo:emailspam@domremote.bar>emaillocal@domlocal.foo

Você pode fazer o seu script para corrigir isso, mas eu forneço dois aqui abaixo.

Blocklist

Script fix_block.sh

#! /bin/bash
  
# BLOCK
seudominio="dominio"
admin_do_spfbl="spfbl@dominio"
>blockadd
spfbl superblock show all | grep $seudominio | egrep -v "WHOIS|DNSBL|REGEX" | grep "@$seudominio$" > blockdel
for cada in `cat blockdel` ; do
        from=`echo $cada | cut -d\> -f1 | cut -d\; -f1`
        to=`echo $cada | cut -d\> -f2`

        echo "$admin_do_spfbl:$from>$to" >> blockadd
done

Depois de executar esse script você terá dois arquivos resultantes: blockdel e blockadd.

Como os nomes já dizem um serve para apagar as regras antigas e o outro para adicionar as regras novas. Confira os arquios para ver se eles foram gerados corretamente.

Tudo certo? arquivos conferidos?… então execute:

for cada in `cat blockdel` ; do ; spfbl superblock drop "$cada" ; done
for cada in `cat blockadd` ; do ; spfbl superblock add "$cada" ; done

Whitelist

Script fix_white.sh

#! /bin/bash
  
# WHITE
seudominio="dominio"
admin_do_spfbl="spfbl@dominio"
>whiteadd
spfbl superwhite show all | grep '@$seudominio;PASS' > whitedel
for cada in `cat whitedel` ; do
        to=`echo $cada | cut -d\> -f1 | cut -d\; -f1`
        from=`echo $cada | cut -d\> -f2`

        echo "$admin_do_spfbl:$from;PASS>$to" >> whiteadd
done

Depois de executar esse script você terá dois arquivos resultantes: whitedel e whiteadd.

Como os nomes já dizem um serve para apagar as regras antigas e o outro para adicionar as regras novas. Confira os arquios para ver se eles foram gerados corretamente.

Tudo certo? arquivos conferidos?… então execute:

for cada in `cat whitedel` ; do ; spfbl superwhite drop "$cada" ; done
for cada in `cat whiteadd` ; do ; spfbl superwhite add "$cada" ; done