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

compartilhar

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!

compartilhar

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

compartilhar

O SPFBL é mais conhecido pelo seu serviço de DNSBL, que diga-se, é sensacional. MAs ele também pode ser instalado localmente e integrado ao Zimbra.

Trata-se de um poderoso anti-spam livre e gratuito, com gestão independente por domínio via interface web. O índice de acerto do SPFBL é muito bom mesmo e tem tornado a luta contra o spam muito mais fácil.

Apesar de tudo de bom, há algumas limitações que eu gostaria d frisar para evitar decepções:

1 – Ele não faz retenção de mensagens bloqueadas, ou seja, o reenvio fica a cargo do respeito à RFC pelo servidor de envio;
2 – A interface web, chamada de painel de controle é bastante limitada e tem um visual bem superado;

Mas esses são detalhes menores em uma ferramenta sensacional. Fica aqui meus parabéns ao Leandro que é o criador e mantenedor do SPFBL.

Neste tutorial vamos ver como fazer a instalação, integração e configuração para trabalhar em ambiente com um ou mais domínios usando a versão GNU Ubuntu 18.04, Zimbra 15.8.8 e instalando o SPFBL no mesmo servidor do Zimbra.

Em todas as configurações vou usar o domínio testes.com.br e você deverá substituí-lo pelo seu domínio.

Conheça e colabore com o SPFBL acessando o repositório deles no github

Então vamos lá!

Pré requisitos

O SPFBL está feito em Java e para poder funcionar precisa do openjdk e de mais alguns utilitários.

ATENÇÃO: a partir da versão 3 o SPFBL exige java 17.
Instale assim:

apt install openjdk-17-jre nmap bc ncat

Baixando o SPFBL

Você deve baixar a última versão do SPBL do site deles no Github. Claro que você pode usar o comando git, mas aqui eu vou usar o bom e velho wget mesmo.

Seguem os comandos:

cd /opt
wget https://github.com/leonamp/SPFBL/archive/master.zip
unzip master.zip

Instalando o SPFBL

Depois de descompactar com o comando unzip acima, será criado o diretório SPFBL-master. Será necessário criar um diretório de instalação de sua escolha e vários arquivos e diretórios precisam ser copiados.

Eu escolhi instalar o SPFBL em /opt/spfbl. Então seguem os comandos:

cd /opt
mkdir spfbl
cp -a SPFBL-master/dist/SPFBL.jar spfbl/
cp -a SPFBL-master/run/spfbl.conf spfbl/
cp -a SPFBL-master/lib spfbl/
cp -a SPFBL-master/data spfbl/
cp -a SPFBL-master/web spfbl/
cp -a SPFBL-master/client/spfblpostfix.pl spfbl/
chmod +x spfbl/spfblpostfix.pl
mkdir spfbl/history
mkdir /var/log/spfbl
cp SPFBL-master/client/spfbl.sh /sbin/spfbl
chmod +x /sbin/spfbl
cp SPFBL-master/run/spfbl-init.sh /etc/init.d/spfbl-init
chmod 755 /etc/init.d/spfbl-init
update-rc.d spfbl-init defaults

Configurando o SPFBL

Hora de fazer os ajustes necessários na configuração do spfbl. O primeiro passo é criar um e-mail exclusivo no Zimbra para a gerência e uso do SPFBL.

su - zimbra -c"zmprov ca spfbl@testes.com.br sua_senha_aqui"

Agora edite o arquivo /opt/spfbl/spfbl.conf e ajuste as seguintes opções como descrito abaixo:

dns_provider_primary=8.8.8.8
hostname=mail.testes.com.br
interface=eth0
http_port=8001
peer_limit=127
dnsbl_limit=127
spfbl_limit=127
admin_email=spfbl@testes.com.br
smtp_auth=true
smtp_starttls=yes
smtp_host=mail.testes.com.br
smtp_port=587
smtp_user=spfbl@testes.com.br
smtp_password=sua_senha_aqui
defer_time_softfail=0
defer_time_yellow=0
cache_time_store=120

As opções são bem auto explicativas e estão documentadas no site do SPFBL então eu não vou repeti-las aqui. Apenas tenha o cuidado de ajustar o nome de seu domínio e hostname do servidor de email.

Agora edite o arquivo /sbin/spfbl e modifique a opção IP_SERVIDOR para o endereço IP ou nome do seu servidor. Pessoalmente eu uso o endereço IP do loopback, assim:

IP_SERVIDOR=127.0.0.1

Iniciando o SPFBL

Hora de iniciar ele ver os logs. Execute:

/etc/init.d/spfbl-init start

E verifique os logs em /var/log/spfbl

Armazenando as alterações periodicamente

o SPFBL mantém todas as alterações em memória, portanto uma queda de energia ou reset podem causar a perda delas. Por isso é importante programar no cron para que elas sejam salvas periodicamente.

Insira a seguinte linha no arquivo /etc/crontab para fazê-lo:

0 1 * * * root /sbin/spfbl store

Essa linha salvará todas as alterações, todo dia às 01 da manhã.

Ativando o Painel de Controle via web do SPFBL

O acesso ao Painel de Controle usando um usuário específico. Abaixo seguem os comandos para isso. Atenção para o hostname e o e-mail do admin

spfbl client add 127.0.0.1/32 mail.testes.com.br SPFBL spfbl@testes.com.br
spfbl user add spfbl@testes.com.br admin
spfbl user send-totp spfbl@testes.com.br

Se o envio falhar pode ser necessário liberar o envio local no master.cf.in do seu Zimbra. Revise as opções smtpd_relay_restrictions e smtpd_client_restrictions adicionando permit_mynetworks em cada uma delas. Depois, como usuário zimbra execute “postfix reload”

Hora de acessar o Painel de controle

A autenticação no Painel de Controle do SPFBL é feita em dois estágios, ou seja, primeiro você recebe uma chave e com ela você gera a senha para poder logar.

O último comando acima enviou para o e-mail spfbl@testes.com.br a chave TOTP com a qual se gera a senha de acesso. A chave é essa sequência de letras e números abaixo do QRcode.

Portanto os passos para acessar o painel são os seguintes:

1 – Tenha certeza de que a porta 8001 está liberada em seu firewall. Pode-se usar qualquer outra porta desejada, basta definir a opção http_port no arquivo de configuração do SPFBL e reiniciar o serviço;

2 – Acesse o link

http://mail.testes.com.br:8001/spfbl@testes.com.br

3 – A tela de login será como a de baixo, solicitando que você entre com a chave TOTP que lhe foi enviada por e-mail. Faça isso.

4 – Acesse https://totp.danhersam.com, insira sua chave TOTP no campo YOUR SECRET KEY e use a senha gerada na tela de login do Painel de Controle.

Feito!

Se o Painel de Controle estiver vazio, ou seja, sem nenhuma mensagem, aguarde alguns minutos que elas vão aparecer.

Adicionando gestão por domínio no SPFBL

O SPFBL permite gestão individualizada por domínio. Isso facilita demais a gestão do anti-spam, permitindo que cada domínio tenha suas próprias políticas de liberação e bloqueio.

Essa gestão é terceirizada, ou seja, cada domínio tem sua própria conta administrativa que gerencia apenas esse domínio.

A ativação desse recurso se dá através da criação de um usuário para cada domínio. Essas contas são do tipo “postmaster”. É assim que o SPFBL sabe que elas pertencem a um determinado domínio.

A criação dessas contas no SPFBL é feita assim:

spfbl user add postmaster@dominio1.org postmaster
spfbl user send-totp postmaster@dominio1.org

• Todas as mensagens para dominio1.org serão gerenciadas pela conta postmaster@dominio1.org
• Assim como na conta admin definida antes, o segundo comando envia a chave TOTP para que ela possa logar no Painel de Controle
• O acesso ao painel de controle é igual ao do admin, apenas trocando o usuário no fim, assim:

http://mail.testes.com.br:8001/postmaster@dominio1.org

Integrar o SPFBL com o Zimbra

A integração é bem simples. Essencialmente o SPFBL é adicionado como um content-filter no Zimbra, ou seja, a mensagem chega, é enviada para o SPFBL e este devolve um “status” de OK ou de erro e o Postfix do Zimbra barra ou deixa passar.

O content-filter é um belo script feito em Perl e que já foi copiado durante os passos da instalação.

Hora de alterar o master.cf.in adicionando as linhas abaixo no final do arquivo. Siga os passos:

1 – Edite o arquivo /opt/zimbra/common/conf/master.cf.in

2 – Adicione as seguintes linhas, cuidando da identação:

policy-spfbl unix - n n - - spawn
   user=nobody argv=/usr/bin/perl /opt/spfbl/spfblpostfix.pl

3 – Edite o arquivo /opt/spfbl/spfblpostfix.pl e altere a opção PeerHost para ficar assim:

PeerHost => '127.0.0.1'

4 – Altere o arquivo /opt/zimbra/conf/zmconfigd/smtpd_recipient_restrictions.cf adicionando a linha abaixo imediatamente abaixo da linha que tem reject_unknown_reverse_client_hostname:

check_policy_service unix:private/policy-spfbl

5 – Como usuário zimbra, reinicie os serviços específicos do Zimbra:

zmconfigdctl restart
zmmtactl stop
zmmtactl start

Conclusão

O SPFBL é um poderoso anti-spam baseado em reputação. Simples de instalar e administrar.

Recomendo fortemente ler a documentação para poder fazer bloqueios e liberações gerais via o cliente cli.

Comece executando spfbl sem nenhum argumento e olhe atentamente as opções que a ajuda imprime na tela.

Parte II

KyaFilter é um software desenvolvido por mim para melhorar a integração do SPFBL com o Zimbra:

1 – Ele cria o whitelist por envio. Isso significa que todos os endereços para os quais se enviam mensagens sçao adicionados no whitelist to SPFBL;

2 – Integração com o botão “Spam” do webmail do Zimbra para adicionar na blacklist do usuário o remetente dessa mensagem.

compartilhar